Netgear 340u
Bjørn Mork
bjorn at mork.no
Sun May 4 03:41:19 PDT 2014
Noah Taber <noahtaber at gmail.com> writes:
> Bjorn, I've been trying to get output that looks like your's but I can't
> seem to get it yet.
>
> Anyway, because I can't successfully get 'usbmon' to work, I started
> heading down a different path.
>
> I figured out how to send AT commands to the 340u via osx.
>
> Please see below:
>
> ati
> Manufacturer: Sierra Wireless, Incorporated
> Model: AirCard 340U
> Revision: SWI9X15C_01.05.11.52 r16619 ntgrbc-fwbuild1 2013/06/28 19:04:08
> IMEI: 013323000120510
> IMEI SV: 7
> FSN: EV310101160610
> +GCAP: +CGSM
>
>
> OK
>
> I also started looking into QMI vs MBIM:
>
> AT!UDUSBCOMP=?
> 0 - reserved NOT SUPPORTED
> 1 - reserved NOT SUPPORTED
> 2 - reserved NOT SUPPORTED
> 3 - reserved NOT SUPPORTED
> 4 - reserved NOT SUPPORTED
> 5 - reserved NOT SUPPORTED
> 6 - DM NMEA AT QMI SUPPORTED
> 7 - DM NMEA AT RMNET1 RMNET2 RMNET3 SUPPORTED
> 8 - DM NMEA AT MBIM SUPPORTED
> 9 - MBIM SUPPORTED
> 10 - NMEA MBIM SUPPORTED
> 11 - DM MBIM SUPPORTED
> 12 - DM NMEA MBIM SUPPORTED
> 13 - Config1: comp6 Config2: comp8 NOT SUPPORTED
> 14 - Config1: comp6 Config2: comp9 SUPPORTED
> 15 - Config1: comp6 Config2: comp10 NOT SUPPORTED
> 16 - Config1: comp6 Config2: comp11 NOT SUPPORTED
> 17 - Config1: comp6 Config2: comp12 NOT SUPPORTED
> 18 - Config1: comp7 Config2: comp8 NOT SUPPORTED
> 19 - Config1: comp7 Config2: comp9 SUPPORTED
> 20 - Config1: comp7 Config2: comp10 NOT SUPPORTED
> 21 - Config1: comp7 Config2: comp11 NOT SUPPORTED
> 22 - Config1: comp7 Config2: comp12 NOT SUPPORTED
>
> AT!UDUSBCOMP?
> !UDUSBCOMP: 6
That makes a lot of sense. Extremely interesting to see the
'NOT SUPPORTED' on so many of the dual configuration alternatives.
Those are the exact ones which will crash my MC7710 (where they are
claimed to be 'SUPPORTED'). I guess they might be disabled because they
just won't work (too few endpoints available maybe?).
I am current using 19, which gives cfg #1 with DM NMEA AT and 3 QMI
interfaces (but only 2 of them actually works) + cfg #2 with a single
MBIM function. Number 14 is also a good choice, being very similar but
with only 1 QMI interface. This is a commonly use default setting, I
believe.
> AT!UDPID?
> !UDPID:
> APP : 9051
> BOOT: 9051
>
> AT!UDPID=?
> APP BOOT
> 9041, 9040
> 9051, 9051
> 9053, 9053
> 9054, 9054
> 9056, 9056
> 68A2, 68A2
> 68B1, 68B0
Ah, interesting. Long list, but it seems to exclude all DirectIP PIDs.
Which match the 'reserved' output from UDUSBCOMP, where we'd expect to
see different DirectIP configurations.
I wonder if that list means that we should add all those PIDs to the
drivers? We miss quite a few of them at the moment. Looks like they all
are going to support some serial + QMI and/or MBIM configurations, which
means that they probably should be added to qmi_wwan and qcserial just
like 68a2 and 9051.
> Should I start playing with !UDPID and !UDUSBCOMP? What are your values?
I don't know if that will help anything. The QMI *should* work as it
is, so we have no reason to believe that any other setting will work
better.
In any case, I'd recommend leaving UDPID alone for now. It doesn't look
like it will make any difference for you, and there is a slight
possibility that these settings will brick your modem.
And I strongly advice against trying out any configuration without an AT
port, because we just don't know how to reconfigure a device like
that... This means that you should avoid UDUSBCOMP 9, 10, 11 an 12.
Personally I haven't dared trying 8 either, becuase I have bad
experiences with cfg #2 of UDUSBCOMP 13 and 18 (the firmware crashes
when I select this, which would have meant a bricked modem if it weren't
for cfg #1). But looking at your output above, it could be that
UDUSBCOMP 8 actually works. I don't know.
In any case: Be aware that the firmware is guaranteed to be buggy and
that the right combination of settings and bugs could leave it
permanently dysfunctional. For example by constantly crashing and
rebooting.
> The reason I started doing this is because David wrote that my
> bNumConfigurations looks different. Maybe this is why I am unable to
> connect through the raspberry pi.
> I am not able to perform the AT commands through linux for some reason.
> Let me know if there are any other AT commands I should run.
So bulk does in fact work. Then I have no idea what could prevent the
DHCP from working...
Too bad qmicli doesn't support dumping the IP configuration so that you
could try setting an address manually. But maybe you could do it the
really hard way?
Example:
1) connect:
bjorn at nemi:~/tmp$ qmicli -d /dev/cdc-wdm0 --wds-start-network=telenor --client-no-release-cid
[/dev/cdc-wdm0] Network started
Packet data handle: '41221944'
[/dev/cdc-wdm0] Client ID not released:
Service: 'wds'
CID: '3'
2) verify that you are connected:
bjorn at nemi:~/tmp$ qmicli -d /dev/cdc-wdm0 --client-cid=2 --client-no-release-cid --wds-get-packet-service-status
[/dev/cdc-wdm0] Connection status: 'connected'
[/dev/cdc-wdm0] Client ID not released:
Service: 'wds'
CID: '3'
3) optional: rerun the last command with '-v' to see what it looks like
in raw bytes. You'll see that we send something like
"01:0C:00:00:01:03:00:01:00:22:00:00:00"
this is the CID --^^
4) use hexdump or some other available tool to read the raw QMI received
from the modem in one terminal :
bjorn at nemi:~$ hexdump -C /dev/cdc-wdm0
5) while sending a "Get Current Settings" (0x002D) message in another.
You must replace the '03' here with whatever CID you got above:
perl -e 'print pack("C*", map { hex } split(/:/, shift))' 01:10:00:00:01:03:00:01:00:2D:00:04:00:01:01:00:01 >/dev/cdc-wdm0
6) try to make sense of the output. You may have to send the same
command twice to make sure that you see enough of the result, because
hexdump will buffer the data.
bjorn at nemi:~$ hexdump -C /dev/cdc-wdm0
00000000 01 88 00 80 01 03 02 01 00 2d 00 7c 00 02 04 00 |.........-.|....|
00000010 00 00 00 00 1e 04 00 bb 17 9c 2e 15 04 00 04 70 |...............p|
00000020 d5 c1 16 04 00 c6 0f 43 82 20 04 00 b9 17 9c 2e |.......C. ......|
00000030 21 04 00 f8 ff ff ff 24 01 00 00 23 01 00 00 1f |!......$...#....|
00000040 02 00 00 01 10 08 00 70 72 6f 66 69 6c 65 31 11 |.......profile1.|
00000050 01 00 00 14 07 00 74 65 6c 65 6e 6f 72 1d 01 00 |......telenor...|
00000060 00 17 21 00 00 00 00 00 00 00 00 00 00 00 00 00 |..!.............|
00000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
We are looking for these TLVs:
"IPv4 Address" (0x1e)
"Primary IPv4 DNS Address" (0x15)
"Secondary IPv4 DNS Address" (0x16)
"IPv4 Gateway Address" (0x20)
"IPv4 Gateway Subnet Mask" (0x21)
but we're primarily interested in 0x1e. The length of all these are 4
bytes, and the length field is 16 bit - little endian like everything
else in QMI. So you'll be looking for patterns like '1e 04 00' etc.
In the outout above, we see '1e 04 00 bb 17 9c 2e', which means that my
assigned IPv4 Address is 0x2e9c17bb (little endian, remember). Some
ping versions will convert that to a more readable format for you, so
you don't have to do it manually:
bjorn at nemi:~$ ping 0x2e9c17bb
PING 0x2e9c17bb (46.156.23.187) 56(84) bytes of data.
So my address is 46.156.23.187.
7) configure this address, with some reasonable netmask and gateway.
Both are fake and the exact values don't matter much as long as the
gateway end up in the same subnet as your address. This will work even
if it's not the same mask and gateway you can find in the output from
the modem:
ifconfig wwan0 46.156.23.187/24
ip route add default via 46.156.23.1
8) test your connectivity:
bjorn at nemi:~/tmp$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=44 time=327 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=44 time=31.4 ms
^C
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 31.495/179.250/327.005/147.755 ms
Looking at all I've written above, I get a feeling that it might be
easier to just add "Get Current Settings" support to qmicli :-)
Bjørn
More information about the libqmi-devel
mailing list