I have been reading whatever I could find in the forum, but have hit a few road blocks.
First of all, the library that is supplied in the SDK is built with the floating point feature to be done in software, which isn’t compatible with my kernel image doing it in the hardware. I read in other posts that it is possible to get hold of the source code for both full and lite SDK, with an NDA, which our company does have. Who can we contact for this?
I need to make use of the Multiple PDN support, I found the document 2174187-1.0 and found a few posts in this forum regarding this. One of the first things the document explains, is to enable the RMNET in the module’s USB composition, using AT!USBCOMP, however that fails on my modem with the message ERROR. I am using the latest Verizon image which might have locked this feature? From what I can read there is a special command which unlocks certain features in the modem, but it can brick the modem too in certain instances? What is the correct way of doing this, if there really is any? These modems are too expensive to kill
I got the Gobi drivers built and running on the modem, but since I can’t link against the provided library, I have been going the other way, updating my kernel to try to get the latest and greatest of the QMI_WWAN code.
There are a couple of other posts on other sites doing kind of the same thing, but I guess there is no support for this in this forum? I’m not getting much further than kernel 4.9.2, where as the later version of the QMI_WWAN driver has the MUX support that I guess is what I would really need.
I guess I either get the SDK up and running correctly, or abandon it altogether and use the implemented kernel stuff and spend the next few nights getting everything updated and running stable, but maybe it’s just waste of time. I’m hoping the SDK is the answer?
You should not need this command to enable muxing on the EM7565.
Older modems could be configured to multiplex two RMNET interfaces, exposing them as separate functions to the host. But this feature is deprecated and not supported at all on the EM7565 AFAIK. So you are right assuming that you need driver support for the relatively new host side muxing feature.
Just for the record.: AT!USBCOMP and other commands modifying modem NVRAM variables are password protected. But that doesn’t imply that there is any unconditional risk of bricking the modem. Just that the commands allow you to paint yourself into a corner, e.g by disabling the AT interface. Take an extra moment to make sure you enter sane values and there is no risk of bricking anything. The password is well known and posted in this forum several times:
AT!ENTERCND=“A710”
This makes sense. You should definitely try to get the SDK running on your hardware.
But if you want to explore the other alternatives, then I believe backporting a newer version of qmi_wwan to v4.9 should be relatively easy. There are probably a few kernel API changes you need to take care of, but I can’t think of any show stopper or dependency on any new kernel features. Might forget something. My memory is not very reliable
Note that you’ll probably need rather new userspace too for the muxing support. Don’t know… I haven’t actually tried the feature myself yet…
Another possible route you might consider is using MBIM, which has had muxing support built-in from the very beginning. The userspace interface is a bit awkward - using VLAN interfaces to map to the different IP sessions. You can find a brief description in the “Multiplexed IP sessions (IPS)” section here: https://www.kernel.org/doc/Documentation/networking/cdc_mbim.txt
Using MBIM will require changing the from QMI/RMNET to MBIM using AT!USBCOMP, though.
Thanks for your suggestion.
I was busy with something else, but got to spend some time on this over the weekend. I finally managed to find out how to make a new SDK for the whole package, so that I can link the Sierra Wireless library into a static package with the shipped settings.
MBIM vs QMAP - I think I will go for the QMAP for now, starting to back-port to the kernel is maybe “fun”, but that’s just adding time and effort and might not work either.
My SIM card at the moment, only has one APN that can be used for Internet. It’s the one that is listed when I do the AT+CGCONTRDP, so I guess that is being selected as default as well?
I have followed the example in the SDK light document, I get the 4 extra gobi-0-x interfaces, but the data session doesn’t seem to be initiated correctly. No IP address using DHCP, no RX only TX data counts on the network interfaces.
Honestly I’m not quite sure about the config file content and what the example actually is supposed to show? The first 4 lines, destination IP, what is meant by that? Profile ID, is that somehow linked to the APN?
Here’s a log of what happens, not quite sure what to think of it. trying_lite_sdk.txt (4.7 KB)
Tried a few things today, got a little closer today after fixing a permission issue.
I trimmed down the lite-qmi-demo so that it only does the data connection part.
First I verified it was working with the netnum=0, no problems. With the DHCP flag set I also get the correct address.
Then I changed the netnum setting to 4, QMAP is enabled and I get the virtual network interfaces gobi-0-0 to gobi 0-4. When I run the program again only trying to enable the first interface, it looks like everything is working, but it never receives any response on the DHCP requests. I tried then without the DHCP flag set, no IP address. The output text file contains a few lines where it gives the interface an IP address and adds routing to the system.
ifconfig gobi-0-0 100.67.54.1 netmask 255.255.255.252 up
ip route add 8.8.8.0/24 via 100.67.54.2 dev gobi-0-0
ifconfig gobi-0-0 mtu 1428
The IP address that the modem has gotten from the network is 100.67.54.1, so that’s ok. The gobi-0-0 now has an internal IP address, but still not working.
After a lot of trying this and that, I found a forum that said to disable the NetworkManager while working on this. Tried that and the connection was established with the correct IP addresses right away.
