MC7455 - diagnostics port under linux

How can I get infos from the device (like AT!LTEINFO or AT!GSTATUS) during a pppd connection?
Continously read from device with about 1Hz.

I have following interfaces under ubuntu 16.04: /dev/ttyUSB0, /dev/ttyUSB1, /dev/ttyUSB2
No modemmanager installed. No QMI SDK.

Communication via AT-cmds only works with ttyUSB2, same with pppd. So either pppd is working OR AT-cmds, not both at the same time. I guess the ttyUSB0 is the diagnostics port. How can I enable/use this port under linux for the required data?


The short answer is that if you are using a PPPd connection on /dev/ttyUSB2 then you cannot send AT commands to the unit at all, there is no way around this.

It is for this reason that people generally use the QMI interface to start/stop data sessions which routes data over the network interface or use RMNet with at!scact=1,1 which starts the network connection.



Thanks for the answer.

What is the easiest way to configure a data connection with QMI and in parallel the AT control via ttyUSB2?

I have installed libqmi but qmicli/qmi-network fail with “couldn’t create client for the wds service”
I have the devices /dev/cdc-wdm0 (wwp0s29u1u4u4i8) and /dev/cdc-wdm1 (wwan1).
What has to be configured in the MC7455 for this setup?


First step is to use the Sierra drivers, the open source ones will not work. Also make sure the system is actually using them as the two can live side by side on the system but Linux will always go for the open source ones if it can possibly find them.,-d-,31n2,-d-,50/

After that once the unit is correctly enumerated follow the attach document.

1aec569af75a1ab07c66bf85086071fc482f614b.docx (347.1 KB)



Which operating system or distribution do you use? You can either use MBIM/QMI to connect. There might be a way to get at!gstatus via QMI, but it certainly requires more effort.

First step is to use the Sierra drivers, the open source ones will not work.

Why do you claim that? libqmi/qmicli/qmi-network has been working with the MC7455 nicely for a very long time.


The open source drivers generically might work with a given system for you and I know they do for a lot of our customers but we do not support them at all (and the customers know this) so to start from a known working, supported point you need to use the Sierra developed drivers and not the open source ones.



This is fine and completely understandable.

Unsubstantiated claims that other solutions do not work, is not.

IMHO you are doing your customers a big disservice by continuing to make such claims. Many of the customers you “help” this way would obviously be much better off by being pointed to ModemManager, or other open source plug-and-play solutions, instead of messing with the QMI SDK.

It would be great if you started thinking obout what your customers need instead of what you want to push.


I do not want to get into an argument but as I have said, lots of our customers do use the open source drivers so I am sure it is fine most of the time but to get it working from a Sierra stand point using the drivers we have written is a pre requisite.

I do not understand your comment about ‘thinking about what our customers need’, they need a good reliable software tool set which we supply through the drivers.



Completely agreed. I just ask that you just stop spreading FUD about the other alternatives. As I’ve requested multiple times before: If you have an actual example of something not working, then please provide the details so we can fix it. If you cannot provide such examples then I’ll assume there are none. I do not see any alternatives. Do you?

This is very obvious to me, but I understand that it isn’t necessarily so to everyone else:

Different users have different needs. Some of them won’t know what to do with a tool set.

There are a number of end users asking questions in this forum which don’t work as embedded system integrators. Most of them are simply interested in getting an Internet connection up and running. Sometimes on a Linux desktop or an OpenWrt system. They ask here because they happen to own a Sierra Wireless modem, but that’s really irrelevant (except that it greatly increases the chances of success). I understand that you cannot support other software, and that these users probably don’t even qualify as customers of Sierra Wireless, as they most likely got their modem from some laptop vendor which is supposed to be handling all support. But anyway, they ask here and they get answers.

Pointing such users in the direction of your supported software is counter-productive. The QMI SDK is a great tool kit for the embedded system integrators. But it is a tool kit, and using it requires either some prior knowlegde or paid support, or both. The group of users I’m talking about have neither. Refusing to recognize that, and continuing to treat everyone as if they’re designing an embedded system, is not really helpful.

The best advice to anyone wanting to use a Sierra Wireless modem on Linux desktop system is to install ModemManager and NetworkManager from their distro. Anything else is a waste of time unless they have a special interest in building their own stuff from scratch.

Note that I don’t imply that there is something wrong with the QMI SDK. It does exactly what it is supposed to do., for the users it is targeted towards.


User hat on: The libqmi/ModemManager combination “just works™”. I don’t have to use a crappy vendor specific tool, one per vendor. I don’t have to compile kernel drivers. The few cases were it does not work is typically a module so new it is not supported yet, and thats IMHO Sierras fault.

Developer hat on: The SDK is:
a) an obfuscation (claimed “abstraction”) layer. On an embedded device, I don’t need this layer for 5 different generations of devices. It poorly wraps the QMI commands, but fails to give proper explanations for the returned values, or standard references where they apply.
b) an binary blob daemon. Architecture not supported - fail. Runtime environment not supported - fail (There is more than Linux/Windows/some RTOS out there, you know?).

If you really want to support your customers (both end users and OEMs), you should:

  • provide proper QMI documentation
  • provide samples to opensource developers (as an OEM developer, I get samples from our distributor).

From my own developer experience, I read the QMI definitions from libqmi, and just avoid the SDK completely.

I certainly agree that this would be nice, but I don’t think it’s up to Sierra Wireless. Qualcomm is the problem. They don’t allow distribution of any of the QMI docs.

FYI: Sierra Wireless do this occasionally. I don’t think there is a specific program, and they don’t brag about it. But they have certainly been among the more helpful modem vendors wrt samples for opensource developers.

I have the sierra qmi driver running but I get nothing at ttyUSB0. Connection via ttyUSB2 is ok.
I use the Is there anything to configure to enable the DM port?
What types of messages are logged here?

As previously mentioned I need infos in realtime during connection similar to the AT-commands AT+CREG,AT+CSQ,AT!LTEINFO,AT!GSTATUS.
The AT-commands are working via ttyUSB2 but are very delayed when modem connected.


The layer 3 logging coming out of /dev/ttyUSB0 is the platform logging which can show you anything and everything going on, however, again this is all a QC protocol which is not published, even to Sierra, we use certain tools such as QXDM to decode the raw log file that is recorded by the dmcpature script. As with most software you need a license from QC to run it.

FYI I have attached an exmple of how to run the dmcapture script.DMCapture Version5 filter file - Native system.txt (13.8 KB)



1 Like

What format does the raw have? Wireshark compatible or at least convertible?

1 Like

The .raw is just an extension I have given it, it can be anything. The file contents is literally a record of data from the DM port which the unit outputs according to the filter that you have specified in the command line. After this as I say you need to run it through tools to make it readable by the QC QXDM tools set. It is all QC proprietary, I agree it would be very nice if it was able to be opened/analysed in something standard like wireshark but I have never used/seen a chipset supplier who has this (ST/Mediatek/QC/Intel/Altair).

The only exception was Ericsson back in the day who had lots and lots of printf’s in their code base and it came out of a serial port, but it was far simpler then.