Hello,
I’ve been trying to use mc7304 on debian 7.4 running kernel 3.15.
I have been using the 7710 for some time using the sierra_net driver and i’m looking ot upgrade.
However i’ve been unable to use the modem. Although it is recognised by the qmi_wwan driver,usb ttys and a wwan interface are created, after initializing a pdp connection i cannot get an ip using the OS’s dhcp client.
From the at commands i can see i’m assigned an ip from the network but i cannot connect ever if i set is as astatic ip on the wan interface.
Is there something specific i’m overlooking?
I suggest you try the driver that Sierra provide(GobiNet and GobiSerial). Then you can either use AT command or the QMI SDK to setup the connection. The AT commnads that you need to use are
AT+CGDCONT
AT!SCACT
You should be able to get the driver and also the SDK from your FAE.
Is the AT!SCACT command supported in QMI mode on the newer modules? I believe I could only make that work in DirectIP mode with the MC7710.
I’m of course biased but I do not see how that would help this specific problem. AFAIK (but might be wrong) you have to use QMI commands to connect Sierra modems in QMI mode. Yes, the GobiNet with the Sierra QMI SDK will do that for you. But so will the qmi_wwan driver with the Debian libqmi-glib1 package, and installing the latter is so much easier…
If you use the qmi driver from Sierra(GobiNet) then you can use the AT!SCACT with the MC7304. The ETH interface will immediately get an IP. It is correct that this was not possible with MC7710.
Thanks. Then I do not see any reason why that shouldn’t work with qmi_wwan as well. There is no real difference between the data channel of these drivers, so they should work the same if you completely ignore QMI.
In any case, if the qmi_wwan driver does not work in this scenario then I’d really like to have that fixed. Maybe there are subtle differences I do not see, like the mac address selection? (which is quite arbitrary in the qmi_wwan driver).
Vasilakis, could you provide some more debug info? Testing the the GobiNet driver would also be good, but I wonder if that is so easy on a 3.15 kernel? Does it build on new kernels nowadays?
A few lines usbmon output showing all USB transmission from the point where the DHCP client brings up the network interface and until DHCP times out would also be very nice. See kernel.org/doc/Documentation/usb/usbmon.txt for instructions.
Hello there, following Vasilakis post, i have the exact same configuration as well as the same issue so using the usbmon i get the following: (dl5162, i hope it is the correct output that you requested)
f48a94c0 286962809 S Bi:6:002:7 -115 1514 <
f48a9100 286962840 S Bi:6:002:7 -115 1514 <
f48a9640 286962843 S Bi:6:002:7 -115 1514 <
f48a9580 286962845 S Bi:6:002:7 -115 1514 <
f48a97c0 286962847 S Bi:6:002:7 -115 1514 <
f48a9280 286962850 S Bi:6:002:7 -115 1514 <
f48a9400 286962852 S Bi:6:002:7 -115 1514 <
f6fd11c0 286962854 S Bi:6:002:7 -115 1514 <
f6fd1280 286962856 S Bi:6:002:7 -115 1514 <
f6fd1640 286962859 S Bi:6:002:7 -115 1514 <
f6fd1100 286962862 S Bi:6:002:7 -115 1514 <
f6fd1340 286962864 S Bi:6:002:7 -115 1514 <
f6fd1580 286962867 S Bi:6:002:7 -115 1514 <
f6fd1b80 286962869 S Bi:6:002:7 -115 1514 <
f48ab100 286962871 S Bi:6:002:7 -115 1514 <
f7680f40 286962878 S Bi:6:002:7 -115 1514 <
f7680e80 286962881 S Bi:6:002:7 -115 1514 <
f7680dc0 286962883 S Bi:6:002:7 -115 1514 <
f7680d00 286962918 S Bi:6:002:7 -115 1514 <
f7680c40 286962921 S Bi:6:002:7 -115 1514 <
f7680b80 286962932 S Bi:6:002:7 -115 1514 <
f7680ac0 286962935 S Bi:6:002:7 -115 1514 <
f7680a00 286962937 S Bi:6:002:7 -115 1514 <
f7680940 286962939 S Bi:6:002:7 -115 1514 <
f7680880 286962942 S Bi:6:002:7 -115 1514 <
f76807c0 286962944 S Bi:6:002:7 -115 1514 <
f7680700 286962953 S Bi:6:002:7 -115 1514 <
f7680640 286962955 S Bi:6:002:7 -115 1514 <
f7680580 286962957 S Bi:6:002:7 -115 1514 <
f76804c0 286962960 S Bi:6:002:7 -115 1514 <
f7680400 286962966 S Bi:6:002:7 -115 1514 <
f7680340 286962969 S Bi:6:002:7 -115 1514 <
f7680280 286962971 S Bi:6:002:7 -115 1514 <
f76801c0 286962978 S Bi:6:002:7 -115 1514 <
f7680100 286962980 S Bi:6:002:7 -115 1514 <
f7680040 286962982 S Bi:6:002:7 -115 1514 <
f4b66f40 286962988 S Bi:6:002:7 -115 1514 <
f4b66e80 286962990 S Bi:6:002:7 -115 1514 <
f4b66dc0 286962993 S Bi:6:002:7 -115 1514 <
f4b66d00 286962995 S Bi:6:002:7 -115 1514 <
f4b66c40 286962997 S Bi:6:002:7 -115 1514 <
f4b66b80 286962999 S Bi:6:002:7 -115 1514 <
f4b66ac0 286963001 S Bi:6:002:7 -115 1514 <
f4b66a00 286963003 S Bi:6:002:7 -115 1514 <
f4b66940 286963005 S Bi:6:002:7 -115 1514 <
f4b66880 286963007 S Bi:6:002:7 -115 1514 <
f4b667c0 286963009 S Bi:6:002:7 -115 1514 <
f4b66700 286963012 S Bi:6:002:7 -115 1514 <
f4b66640 286963014 S Bi:6:002:7 -115 1514 <
f4b66580 286963016 S Bi:6:002:7 -115 1514 <
f4b664c0 286963018 S Bi:6:002:7 -115 1514 <
f4b66400 286963027 S Bi:6:002:7 -115 1514 <
f4b66340 286963029 S Bi:6:002:7 -115 1514 <
f4b66280 286963031 S Bi:6:002:7 -115 1514 <
f4b661c0 286963035 S Bi:6:002:7 -115 1514 <
f4b66100 286963037 S Bi:6:002:7 -115 1514 <
f4b66040 286963039 S Bi:6:002:7 -115 1514 <
f6fd9f40 286963043 S Bi:6:002:7 -115 1514 <
f6fd9e80 286963045 S Bi:6:002:7 -115 1514 <
f6fd9dc0 286963047 S Bi:6:002:7 -115 1514 <
f6fd9d00 286971048 S Bo:6:002:5 -115 90 = 33330000 001626c4 78b77309 86dd6000 00000024 00010000 00000000 00000000
f6fd9d00 286971230 C Bo:6:002:5 0 90 >
f48a9940 286987807 S Bo:6:002:5 -115 342 = ffffffff ffff26c4 78b77309 08004510 01480000 00008011 39960000 0000ffff
f48a9940 286987973 C Bo:6:002:5 0 342 >
f6fd9c40 287327160 S Bo:6:002:5 -115 78 = 3333ffb7 730926c4 78b77309 86dd6000 00000018 3aff0000 00000000 00000000
f6fd9c40 287327288 C Bo:6:002:5 0 78 >
f6fd9b80 287855029 S Bo:6:002:5 -115 90 = 33330000 001626c4 78b77309 86dd6000 00000024 00010000 00000000 00000000
f6fd9b80 287855201 C Bo:6:002:5 0 90 >
f6fd9ac0 288327189 S Bo:6:002:5 -115 90 = 33330000 001626c4 78b77309 86dd6000 00000024 0001fe80 00000000 000024c4
f6fd9a00 288327241 S Bo:6:002:5 -115 70 = 33330000 000226c4 78b77309 86dd6000 00000010 3afffe80 00000000 000024c4
f6fd9ac0 288327313 C Bo:6:002:5 0 90 >
f6fd9a00 288327325 C Bo:6:002:5 0 70 >
f6fd9940 289067137 S Bo:6:002:5 -115 90 = 33330000 001626c4 78b77309 86dd6000 00000024 0001fe80 00000000 000024c4
f6fd9940 289067235 C Bo:6:002:5 0 90 >
f6fd9a00 292272174 S Bo:6:002:5 -115 342 = ffffffff ffff26c4 78b77309 08004510 01480000 00008011 39960000 0000ffff
f6fd9a00 292272305 C Bo:6:002:5 0 342 >
f6fd9940 292331142 S Bo:6:002:5 -115 70 = 33330000 000226c4 78b77309 86dd6000 00000010 3afffe80 00000000 000024c4
f6fd9940 292331275 C Bo:6:002:5 0 70 >
f6fd9880 296339090 S Bo:6:002:5 -115 70 = 33330000 000226c4 78b77309 86dd6000 00000010 3afffe80 00000000 000024c4
f6fd9880 296339260 C Bo:6:002:5 0 70 >
f6fd9880 298798645 S Bo:6:002:5 -115 342 = ffffffff ffff26c4 78b77309 08004510 01480000 00008011 39960000 0000ffff
f6fd9880 298798780 C Bo:6:002:5 0 342 >
f6fd9040 311686298 S Bo:6:002:5 -115 342 = ffffffff ffff26c4 78b77309 08004510 01480000 00008011 39960000 0000ffff
f6fd9040 311686449 C Bo:6:002:5 0 342 >
f6fd9040 319827070 S Bo:6:002:5 -115 342 = ffffffff ffff26c4 78b77309 08004510 01480000 00008011 39960000 0000ffff
f6fd9040 319827211 C Bo:6:002:5 0 342 >
f6fd9280 335643986 S Bo:6:002:5 -115 342 = ffffffff ffff26c4 78b77309 08004510 01480000 00008011 39960000 0000ffff
f6fd9280 335644114 C Bo:6:002:5 0 342 >
f6fd9c40 347867556 S Bo:6:002:5 -115 42 = ffffffff ffff26c4 78b77309 08060001 08000604 000126c4 78b77309 00000000
f6fd9c40 347867684 C Bo:6:002:5 0 42 >
f6fd9c40 349302346 S Bo:6:002:5 -115 42 = ffffffff ffff26c4 78b77309 08060001 08000604 000126c4 78b77309 00000000
f6fd9c40 349302447 C Bo:6:002:5 0 42 >
f6fd9c40 350855224 S Bo:6:002:5 -115 42 = ffffffff ffff26c4 78b77309 08060001 08000604 000126c4 78b77309 00000000
f6fd9c40 350855413 C Bo:6:002:5 0 42 >
f6fd9c40 352856781 S Bo:6:002:5 -115 42 = ffffffff ffff26c4 78b77309 08060001 08000604 000126c4 78b77309 a9fe06d3
f6fd9c40 352856939 C Bo:6:002:5 0 42 >
f6f45340 354858358 S Bo:6:002:5 -115 42 = ffffffff ffff26c4 78b77309 08060001 08000604 000126c4 78b77309 a9fe06d3
f6f45340 354858498 C Bo:6:002:5 0 42 >
In case there is any other information i can provide please let me know.
Yes, this is perfect. Thanks. However, I was too optimistic (as usual) wrt locating the problem this way. Anyway, we can look at what it tells us:
This is an outgoing IPv6 multicast packet with ethernet headers, as expected when the interface comes up. It is part of the IPv6 auto-configuration. There is no reply, but that is not necessarily an error. It is expected if your mobile session is IPv4 only.
This is an outgoing IPv4 broadcast packet with ethernet headers. It is truncated before the UDP header so we cannot verify that it is DHCP, but that is pretty likely based on the 0.0.0.0 source IP address (almost at the end of the line - the ffff at the end are the 2 first bytes of the IP destination).
And these two types of packets are repeated a few times. The important part to notice is that there are only “Bo” packets here, meaning “bulk out”. There are no replies whatsoever. Which doesn’t tell us much more than we already knew… Still, at least we know that there is no replies being misinterpreted or dropped. The problem is therefore most likely related to the packets we send. I have a strong feeling that this problem is the ethernet header. The modem is probably configured for raw IP packets, dropping the packets from the driver because of the ethernet header.
There was a recent discussion about similar problems on the libqmi list. See e.g. lists.freedesktop.org/archives/l … 00886.html on how to configure the modem to expect ethernet packets.
You’ll have to use QMI for that AFAIK. But it is a “sticky” setting, so it is a onetime thing if you want to continue to use AT commands to connect. At least until some other driver (e.g. a Windows driver) or utility (e.g. firmware upgrade) changes it - which is why I recommend always doing this configuration as part of the modem initialization.
The above debug trace was captured when executing DHCP on wwan1 interface which is supposed to be the 802-3 (wwan0 is the raw ip). Does this affect your speculation about the packet dropping?
Not really. It is still my best bet. Actually my only bet at the moment
There is nothing special about wwan0/wwan1. They are both capable of being configured as 802-3 or raw ip (and a few more header variants). So it is perfectly possible that both are configured for raw ip. I would rule that out first.
[/dev/cdc-wdm1] Successfully got data format
QoS flow header: no
Link layer protocol: ‘802-3’
Uplink data aggregation protocol: ‘disabled’
Downlink data aggregation protocol: ‘disabled’
NDP signature: ‘0’
Uplink data aggregation max size: ‘0’
Downlink data aggregation max size: ‘0’
As you can see wwan1 is 802-3. The thing is I can get an IP from the network but then dhclient wwan1 fails!
Let me explain my situation in a bit more detail.
Simply issuing:
AT+CGDCONT
AT!SCACT
I see I can connect to the network and get an IP assigned (I see that with: AT+CGCONTRDP).
Then I do:
ifconfig wwan1 up
but:
dhclient wwan1
fails to assign wwan1 an IP address.
Using: qmicli -d /dev/cdc-wdm1 --wds-start-network=[apn] --client-no-release-cid
I can connect and then dhclient wwan1 gives the interface an IP address.
However, I would still want to use AT commands instead of qmi. Is that somehow possible?
I’m trying to do basically the same thing (AT commands via GobiSerial to connect/start GobiNer) but using a MC7354 instead. I am getting the same almost works result. The target is an embedded ARM9 v5 device running Linux 3.3. I would like get this working using AT commands before trying to get QMI working.
I don’t think that’s possible, unless you switch the modem to DirectIP mode (i.e. handled via sierra_net). If in QMI mode, you’ll need QMI to handle the WWAN interface.
