On Thu, 2011-12-01 at 10:48 +0100, Bjørn Mork wrote:
> 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
Yeah, the "ser" and "mdm" in the INF file mostly give away the intent
that it's supposed to be driven by a serial driver like option. This is
true for almost all devices driven by Qualcomm chipsets. There's a
'mdm' INF file for the port that is supposed to be used for PPP if
you're using it that way (kinda pointless if there's a net interface
like cdc-ether or NDIS), and the others are low-bandwidth interfaces for
control and status.
> 3) NDIS:
> Driver/Driver/X64/ewnet.inf:%qcwwan.DeviceDesc00% = qcwwan.ndi, USB\VID_12d1&Subclass_01&Prot_07
Yup; if it says "net" in the INF file name it's almost certainly not
supposed to be driven by option. But obviously something else.
> 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.
These device's won't always use actual cdc-ether or cdc-eem or standard
types; often they'll be custom interfaces.
> 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.
I'd assume they are unless proved otherwise. Almost all of the "ndis"
devices I've run across are proprietary protocols, with the nice
exception of Ericsson modems that actually use standards.
> 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've seen that driver too, and it's pretty awful. It would take a lot
of work to figure out how to distill that down into a much smaller
driver that handled what was actually different instead of trying to
copy & modify existing drivers. But if somebody were to do that, it
would be great.
> 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 :-)
If you can pursue this path and see if you get any farther that would be
great. Aside from that other driver dump Huawei typically doesn't
participate in upstream kernel development except to periodically send
new device IDs to the option driver. Might be useful to find those
engineers and ask them about this device, though I wouldn't be too
optimistic about a response.
> 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
You shouldn't really expect DHCP to work; that's not how the air
interface operations. When a GSM/UMTS/LTE/1x/EVDO device "supports"
DHCP what's actually happening is that the firmware is setting up the
connection and requesting addressing information internally (*not* using
DHCP since there's no ethernet-framed link layer over the air), and then
either (a) providing IP/DNS info via AT commands like your Huawei
device, or (b) faking a DHCP server in firmware so that you can actually
use dhclient on the net interface.
> 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)
Yeah, for most any device that returns IP/DNS info via an AT command,
this is what you have to do. They won't typically support actual DHCP
on the network interface (except for Ericsson, Sierra, and a few other
devices).
> 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
At least you're talking to the driver, but it *might* just be the driver
and not the firmware. I haven't looked at the sources, but the driver
might just be short-circuiting the ARP requests internally. It could
also be that you're actually talking to the firmware, and the firmware
is responding.
> 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.
Basically, anything that's not IP or PPP doesn't go over the air. DHCP
is faked by the firmware if it's even supported. But there are many
different implementations of "pseudo ethernet" network interfaces that
modems use because everyone just wants it to be simple for the OS, so
they push the complexity down to drivers or the firmware. So the answer
to this all is "it depends, more investigation required"...
Dan
--
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
