I would like to test MC7455 with QMI interface.
I use the driver SierraLinuxQMIdriversS2.23N2.31.
But when I insert the GobiNet, some messages appear as below. GobiNet: 2015-04-02/SWI_2.31
GobiNet 1-1.3:1.8: usb0: register ‘GobiNet’ at usb-rt3xxx-1.3, GobiNet Ethernet Device, 02:24:90:a2:37:d8
Ethernet mode
GobiNet 1-1.3:1.8: usb0: unregister ‘GobiNet’ usb-rt3xxx-1.3, GobiNet Ethernet Device
GobiNet: probe of 1-1.3:1.8 failed with error -14
usbcore: registered new interface driver GobiNet
No qcqmi interfaces be created.
I use the AT command !USBCOMP=? to query supported interfaces.
The list output as below. AT!USBCOMP=?
!USBCOMP:
AT!USBCOMP=,,
- configuration index to which the composition applies, should be 1
- 1:Generic, 2:USBIF-MBIM, 3:RNDIS
config type 2/3 should only be used for specific Sierra PIDs: 68B1, 9068
customized VID/PID should use config type 1
- DIAG - 0x00000001,
NMEA - 0x00000004,
MODEM - 0x00000008,
RMNET0 - 0x00000100,
RMNET1 - 0x00000400,
RMNET2 - 0x00000800,
MBIM - 0x00001000,
AUDIO - 0x00010000,
e.g.
10D - diag, nmea, modem, rmnet interfaces enabled
1009 - diag, modem, mbim interfaces enabled
The default configuration is:
at!usbcomp=1,1,10F
OK
No QMI interface specify in interface bitmask.
Is there anyone know if QMI is supported by MC7455 or not?
Yes.
The new driver correct generate qcqmi0 and usb0.
Thanks.
It seems this driver need to work with the last SDK SLQS03.03.10.
I tried to build a firmware to try with the last driver and SDK.
But, I can’t successful bring up the SDK.
It show messages as below while I run the sample code Connection_Manager. SWI API: SDK process startup failed
SWI API: SDK process startup failed
Failed to start SDK : Exiting App
Failure Code : 2
The command I used is /bin/connectionmgrmipsel /bin/slqssdk 0.
Do you ever saw such condition?
Very interesting! So they have dropped the fixed configuration sets in favour of a function bitmask. Seems like a good move.
“RMNETx” is QMI. You can select up to 3 QMI functions. I wonder if all combinations are valid though? Previous modules/firmwares have allowed 3 QMI functions, but not e.g QMI + MBIM in the same configuration (which doesn’t make sense either)
I found both driver of S2.23N2.31 and S2.24N2.33 can get MC7455 QMI interface work exactly.
But only when the driver is built to RawIP mode.
Under RawIP mode, I can connect my MC7455 to LTE network and ping to internet from my device.
But it gets problem when forward frames from internet to the hosts behind my device by NAT.
By capture the frames behind NAT, I found ping response send back from internet but the last 14 bytes in the frame data is changed. So the ping failed.
I guess it is because RawIP mode do not process Ethernet header.
It seems MC7455 do not support Ethernet mode?
Have anyone know if the Ethernet mode support by MC7455 or not?
Or how to configure it?
It’s not quite clear to me which frames and what sort of changes you see where. It would help if you posted some examples.
In general you should use L3 routing for any forwarding decisions. As you know, the ethernet headers are just made up, whether it is done in the modem firmware or in the driver. I haven’t looked at how this is implemented in Sierra’s driver, but I guess it doesn’t consider bridging.
If it is similar to previous Qualcomm chipsets, then you can set ethernet mode using the QMI_WDA “Set Data Format” message. I strongly recommend verifying the result using “Get Data Message” as well, because there might be restrictions preventing a change if other applications use the same channel.
Don’t know about QMI SDK support, but libqmi supports these messages:
bjorn@nemi:~$ qmicli --help-wda
Usage:
qmicli [OPTION...] - Control QMI devices
WDA options
--wda-set-data-format=[raw-ip|802-3] Set data format
--wda-get-data-format Get data format
--wda-noop Just allocate or release a WDA client. Use with `--client-no-release-cid' and/or `--client-cid'
Note that raw IP isn’t supported at all by the qmi_wwan driver, so we depend on being able to set ethernet mode for that one. If these new modems/chipsets really don’t support ethernet mode, then we’ll have to add the driver support. But it will be a mess, where userspace will have to tell the driver which mode to use. So there isn’t really any advantage for userspace as long as both modes are supported by the modem firmware. Which is why I have avoided adding the driver support so far.
Thanks a lot for your reply.
I take two snapshots of my Wireshark window as the attachments.
You can see the last 14 bytes in data field are different in ping and response, which results incorrect checksum in ICMP header.
Doe you have any idea for such condition?
Thanks.
Yes, I see now. Thanks for posting that. It really helped.
I took a quick look at the GobiNetDriverRxFixup() function in the S2.25N2.34 version of the driver. The implementation is best described as odd, open coding stuff instead of using the Linux kernel infrastructure made for this type of header mangling. It’s also allocating a temp buffer for each received packet, and copying the whole packet twice! In addition to being unnecessary inefficient, this is also very easy to get wrong. There are quite a few pointers from the skb metadata into the packet data, so you have to be real careful if you move stuff around. At least I wouldn’t attempt anything like that…
But I don’t know exactly where this blows up. For all I know, the cdc_mbim driver (which also do similar fake ethernet header addition, written by yours truly) might have the exact same problem. I haven’t tried. I know it doesn’t handle bridging, as it assumes the destination always is the local host.
Try to configure the device for ethernet mode using “set data format”. Looks like the GobiNet driver will do this in RegisterQMIDevice() if you build the driver for ethernet mode (see GobiNet/QMI.c) . Note that you may have to turn off any auto connect feature in the firmware for this to work, as that counts as another QMI client which might force raw IP.
Yes.
I can build the driver to Ethernet mode by define ‘DATA_MODE_RP’ in Makefile.
But, I get the error messages as below while I insert it to kernel.
GobiNet: 2015-08-27/SWI_2.34
GobiNet 1-1.3:1.8: usb0: register ‘GobiNet’ at usb-rt3xxx-1.3, GobiNet Ethernet Device, 86:c9:a2:d2:f0:b7
Ethernet mode
GobiNet 1-1.3:1.8: usb0: unregister ‘GobiNet’ usb-rt3xxx-1.3, GobiNet Ethernet Device
GobiNet: probe of 1-1.3:1.8 failed with error -14
GobiNet 1-1.3:1.10: usb0: register ‘GobiNet’ at usb-rt3xxx-1.3, GobiNet Ethernet Device, 86:c9:a2:d2:f0:b7
Ethernet mode
GobiNet 1-1.3:1.10: usb0: unregister ‘GobiNet’ usb-rt3xxx-1.3, GobiNet Ethernet Device
GobiNet: probe of 1-1.3:1.10 failed with error -14
usbcore: registered new interface driver GobiNet
I had tried driver S2.25N2.34, S2.24N2.33 and S2.23N2.31.
All of them get the same results.
Additionally, I have tried with other Sierria module like MC7304 or MC7354.
Both of them correct bring up usb0 interface and connect to LTE BS with the same Ethernet mode drivers of S2.23N2.31.
So I guess MC7455 does not support the Ethernet mode.
Do you have any idea for the error messages?
Or how to clarify if MC7455 support Ethernet mode or not?
BTW, it seems something wrong on GobiNet driver of S2.25N2.34.
It successful make my MC7304 connect to LTE BS, but fail to get IP.
The issue does not exist when I change the driver to S2.23N2.31.
The error code 14 is EFAULT. This is never returned directly by the probe, but must be propagated from RegisterQMIDevice() which is responsible for the initial QMI setup. The likely source is QMIWDASetDataFormatResp(), which will return -EFAULT on failure to set ethernet mode.
So it looks like you are correct: The WDA Set Data Format command fails on these devices if you attemt to set ethernet mode. It would be interesting to see the actual QMI error. Does the command fail, or doesn’t the mode change? Try to turn on debugging:
rmmod GobiNet
insmod GobiNet debug=1
You should then see it failing at either “EFAULT: Data Format Mode Bad Response\n”
or “EFAULT: Data Format Cannot be set to Ethernet Mode\n”
If it’s the first one, then it would be interesting to print the actual “result” from ValidQMIMessage(), because that will be the QMI error code.
EDIT: A light bulb just appeared: Did you try to load the Ethernet Mode driver as the very first thing after the modem was reset? There have been several reports (for older devices) that “Set Data Format” only is successful if it is one of the very first QMI commands sent to the modem.
WOW, you are something else.
I see the message EFAULT: Data Format Cannot be set to Ethernet Mode which print in QMIWDASetDataFormatResp.
According to the source code, it should be the response from MC7455 after call to QMIWDASetDataFormatReq. So, I can say the MC7455 do not support ethernet mode exactly now, is it?
Following are partial messages I captured for your reference.
GobiNet::QMIWDASetDataFormatReq Request Ethernet Data Format
GobiNet::FillQMUX pQMUXHeader->mLength = 0x1e, buffSize - 1 = 0x1e
GobiNet::WriteSync Actual Write:
GobiNet::PrintHex : 01 1E 00 00 1A 01 00 01 00 20 00 12 00 10 01 00 00 11 04 00 01 00 00 00 13 04 00 00 00 00 00
GobiNet::FindClientMem Found client’s 0x11a memory
GobiNet::PopFromReadMemList
GobiNet::FindClientMem Found client’s 0x11a memory
GobiNet::PopFromReadMemList *ppReadMemList = 0x(null) pDelReadMemList = 0x(null)
GobiNet::PopFromReadMemList No read memory to pop, Client 0x011A, TID = 1
GobiNet::AddToNotifyList
GobiNet::FindClientMem Found client’s 0x11a memory
GobiNet::IntCallback IntCallback: Encapsulated Response = 0x8000001a1
GobiNet::ReadCallback Read 91 bytes
GobiNet::PrintHex : 01 5A 00 80 1A 01 02 01 00 20 00 4E 00 02 04 00 00 00 00 00 10 01 00 00 11 04 00 02 00 00 00 12 04 00 00 00 00 00 13 04 00 00 00 00 00 14 04 00 00 00 00 00 15 04 00 00 00 00 00 16 04 00 00 00 00 00 17 04 00 01 00 00 00 18 04 00 FF FF FF FF 1A 04 00 00 00 00 00 1B 01 00 00
GobiNet::FindClientMem Found client’s 0x11a memory
GobiNet::ReadCallback Creating new readListEntry for client 0x011A, TID 1
GobiNet::FindClientMem Found client’s 0x11a memory
GobiNet::UpSem 0x011A
GobiNet::PopFromReadMemList
GobiNet::FindClientMem Found client’s 0x11a memory
GobiNet::PopFromReadMemList *ppReadMemList = 0x86006780 pDelReadMemList = 0x86006780
GobiNet::PopFromReadMemList *ppReadMemList = 0x86006780 pDelReadMemList = 0x86006780
GobiNet::PopFromReadMemList *ppData = 0x86bcc280 pDataSize = 91
GobiNet::QMIWDASetDataFormatResp EFAULT: Data Format Cannot be set to Ethernet Mode
GobiNet::QMIWDASetDataFormat Data Format Cannot be set
Additionally, I built the driver as module and insert to kernel manually after my device complete to boot up. I did a test to insert the driver right after reset the modem by AT command ‘!RESET’, but the results is the same.
Thanks a lot for your information.
It is more clear to me.
I guess the protocol communication are as below.
The driver try to set link layer protocol to Ethernet.
MC7455 receive the message and find it can’t set its link layer protocol to Ethernet mode by it only support RawIP or fail to set with some reason.
MC7455 reply it set the link layer protocol to RawIP mode.
Driver check TLV value and find MC7455 still use RawIP mode so print ‘Data Format Cannot be set to Ethernet Mode’.
Do you know where I can download the QMI protocol spec?
I try to search on internet and Qualcomm web site, but do not find it so far.
I guess that it is proprietary so Qualcomm do not release it?
You should really ask Qualcomm about this… It is a proprietary spec as you say, and only they can answer questions about the current distribution policy.
But here is what I do know:
Qualcomm used to provide parts of the QMI spec under NDA to registered developers on their Gobi developer site, but withdraw it all a while ago. The complete spec was never made available. One notable missing part is for example the QMI_CTL documentation. Redistribution of these documents was never allowed.
Qualcomm also support(ed?) the CodeAurora Gobi open source project. Significant parts of the QMI spec was released through this project in source code form. Not the actual spec, but enough source code to be able to deduce the protocol. The coverage was even less than the documents mentioned above, but not completely overlapping. This project is the source of all publicly known parts of e.g. QMI_CTL. We have not seen any update of this project in a couple of years, which means that new parts of the spec is missing. This is a problem wrt new firmware, and even more wrt new hardware.
The CodeAurora Gobi project is what the GobiNet and GobiSerial drivers are based on. And those are obviously still being updated and distributed by vendors, as you know, sometimes leaking small parts of information about newer QMI developement.
Sierra Wireless are also nice enough to maintain and provide a Linux QMI SDK. This is not open source, so it does not provide any QMI info we can use directly. But it documents what can be done in QMI. And that actually helps a lot. Knowing what commands and interfaces are there, sometimes enable us to guess undocumented parts of the spec. This is especially important wrt Sierra specific QMI extensions. But there are of course limits to guessing. Trying to figure out the meaning of a large set of undocumented TLVs without any recognisable patterns is impossible.
All the open QMI information, including the original CodeAurora source code, is collected in the open source libqmi project. Much of it is also converted into structured protocol definitions in JSON form. This project is therefore the recommended QMI information source. Unless you can cut a deal with Qualcomm
I real appreciate your helping and sharing.
I will try to get the answer by the other channel.
And will update to you if I can get the positive response.
Thanks again.
FWIW, I’ve now had the chance to experiment with an MC7455 myself, and I can only confirm the above findings: It does not seem to be possible to set the “Link Protocol” to 802.3. Meaning that the MC7455 will only work with drivers supporting the “raw IP” mode.
Unless someone has found a way to set it to “802.3”?
Try building the driver as RawIP. I was having the same problem that you described, but then I built the driver like this, and I got my QMI interfaces back.
make -C GobiNet RAWIP=1
This just defines DATA_MODE_RP in the Makefile. I am using driver version S2.25N2.36 by the way.
