Dan Williams <dcbw@xxxxxxxxxx> writes:
>> AT^SETPORT=?
>> 1:MODEM
>> 2:PCUI
>> 3:DIAG
>> 4:PCSC
>> 5:GPS
>> 6:GPS CONTROL
>> 7:NDIS
>> A:BLUE TOOTH
>> B:FINGER PRINT
>> D:MMS
>> E:PC VOICE
>> A1:CDROM
>> A2:SD
>>
>>
>> OK
>> AT^SETPORT?
>> A1;1,2,3,7,A1,A2
>>
>> OK
>>
>>
>> Which matches up with protocol 0x08 being "NDIS". I assumed that would
>> be more than just a plain serial interface? I also note from my lsusb
>> output that there isn't a one-to-one mapping between SETPORT output and
>> protocol for "NDIS". It seems as if the "NDIS" port is using two
>> interfaces with protocols 8 and 9, and the protocol 9 one also has some
>> extra data (vendor specific descriptor of some sort?).
>
> If it's not an actual serial port for a serial protocol like AT,
> DIAG/DM, QMI, CnS, WMC, etc, then it shouldn't be driven by option. In
> this case, only USB interfaces 0, 1, and 2 (ie PCUI, MODEM, and DIAG)
> should be driven by option, and interface 3 (NDIS) should not.
>
> When in doubt, check the Windows .INF files for what kinds of ports it's
> supposed to be. They'll typically tell you exactly which USB interfaces
> are driven by a serial driver or custom NDIS or whatever.
Yes, the .INF files mostly confirms this: They install
1) modem:
Driver/Driver/X64/ewmdm2k.inf:%HUAWEI00% = Modem0, USB\VID_12d1&Subclass_01&Prot_01
2) PCUI and DIAG:
Driver/Driver/X64/ewser2k.inf:%QcomDevice00% = QportInstall00, USB\VID_12d1&Subclass_01&Prot_03
Driver/Driver/X64/ewser2k.inf:%QcomDevice01% = QportInstall01, USB\VID_12d1&Subclass_01&Prot_02
3) NDIS:
Driver/Driver/X64/ewnet.inf:%qcwwan.DeviceDesc00% = qcwwan.ndi, USB\VID_12d1&Subclass_01&Prot_07
However, I cannot really get the last one to match up with the
descriptors as seen in Linux. There I see protocol 9 for the master CDC
ethernet interface and protocol 8 for the slave interface. Odd.
Anyway, getting the NDIS interface to work as well would be fun too :-)
>From what I've gathered, the device uses a Qualcomm chipset called
MDM9200. The USB firmware is of course Huawei specific, but I assume
all the communication protocol implementations are not.
There is a Huawei "ndis" Linux driver which seems to be a mess of
usbnet.c, cdc_ether.c and cdc_ncm.c all mixed together in a single file,
with only a few Huawei device ids and some glue code added. It looks
like an attempt to support a large number of cards using very different
protocols in a single file, while ignoring the fact that they break all
other cards using any of the original Linux drivers...
I couldn't find any code that looks like it does anything exciting for
my card, so I tried to use the regulary cdc_ether instead. Since the
proper CDC class specific descriptors are there, it was mostly just
adding the device to the MODULE_DEVICE_TABLE. But this did of course
fail the test for the slave interface being USB_CLASS_CDC_DATA, so I had
to modify that as well.
And that does sort of nearly worked. It doesn't forward any IP packets
though. It just does ARP. Not very useful, but it is a start :-)
I have no idea how to properly use this, so that might be the reason.
Just for the record: I tried the Huawei driver as well, and couldn't get
that to work either. If anyone has any hints on how to use it, please
let me know.
Google led me to the following AT commands which look like part of the
solution at least:
at^dhcp?
+CME ERROR: no connection to phone
at^ndisdup=1,1,"myapn"
OK
at^dhcp?
^DHCP:7796124d,f0ffffff,7196124d,7196124d,470d5c1,c60f4382,236800,236800
OK
This looks like a successful connection to me. The ^DHCP output is a
set of ip addresses which match my expectations, followed by something
that looks like DHCP t1 and t2 timer values(?). The ip addresses are in
reverse byte order, as can be easily deduced from the netmask.
Converting the address to dotted quads to make them more readable:
bjorn@nemi:~$ perl -e 'print join(",",map { join(".", unpack("C4", pack("L", hex))) } split /,/, shift),"\n"' 7796124d,f0ffffff,7196124d,7196124d,470d5c1,c60f4382
77.18.150.119,255.255.255.240,77.18.150.113,77.18.150.113,193.213.112.4,130.67.15.198
The last two are definitely my ISPs DNS servers. I guess that the
repeated address is gateway and DHCP server. That leaves my address and
the netmask.
At this point I would expect that I could run dhclient on the interface
created by cdc_ether and things would just work. That failed. No reply
to the DHCP discover packets:
35.534312 0.0.0.0 -> 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0xf7214e3e
42.271768 0.0.0.0 -> 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0xf7214e3e
54.272867 0.0.0.0 -> 255.255.255.255 DHCP 342 DHCP Discover - Transaction ID 0xf7214e3e
But if I manually configure the interface with the address from the
^DHCP output:
eth3 Link encap:Ethernet HWaddr 00:a0:c6:00:00:00
inet addr:77.18.150.119 Bcast:77.18.150.127 Mask:255.255.255.240
inet6 addr: fe80::2a0:c6ff:fe00:0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:1729 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:28 (28.0 B) TX bytes:297286 (290.3 KiB)
and try to ping the gateway address, then I do see an ARP reply:
152.335257 00:a0:c6:00:00:00 -> ff:ff:ff:ff:ff:ff ARP 42 Who has 77.18.150.113? Tell 77.18.150.119
152.336178 02:50:f3:00:00:00 -> 00:a0:c6:00:00:00 ARP 42 77.18.150.113 is at 02:50:f3:00:00:00
but nothing more:
152.336193 77.18.150.119 -> 77.18.150.113 ICMP 98 Echo (ping) request id=0x4c6d, seq=1/256, ttl=64
153.331655 77.18.150.119 -> 77.18.150.113 ICMP 98 Echo (ping) request id=0x4c6d, seq=2/512, ttl=64
154.332752 77.18.150.119 -> 77.18.150.113 ICMP 98 Echo (ping) request id=0x4c6d, seq=3/768, ttl=64
Now I must admit that I have absolutely no idea how this is supposed to
work, and which entity is responsible for that ARP reply. But I do take
it as an indication that communication with the device firmware does in
fact "work", using the standard Linux cdc_ether class driver.
Just need to sort out the missing bits and pieces...
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
