Dan Williams <dcbw@xxxxxxxxxx> writes: > These device's won't always use actual cdc-ether or cdc-eem or standard > types; often they'll be custom interfaces. Yes, I know. But in this case, the inclusion og all three CDC class specific descriptors CDC ethernet uses made me optimistic. > >> 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. OK. >> 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 have only looked at the parts that apply to the specific device I've got, and there is not much difference from a standard cdc_ether.c there. Some additional debug output, a hardcoded mac address, and some weird qmi(?) code doing netif_carrier_on() if it detects a connection within the first 10 seconds after the driver was bound to the interface. Of course paired with defaulting to netif_carrier_off(). The only thing that achieves is that the driver fails unless the card is connected when it binds. Really strange piece of code to put in there. Oh, yeah, and it silently ignores any USB_CDC_NOTIFY_RESPONSE_AVAILABLE notfications, so that you don't get the harmless [941485.623422] eth3: CDC: unexpected notification 01! which cdc_ether will throw at you once(?) on startup. > 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. Huh, I would still expect them to implement DHCP for me so that it would be mostly plug and pray. But I understand that I'm spoiled with the Ericsson 3G card I've been using so far. I'm going to stop complaining about them now :-) > 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"... Yes, I understand this. But the returned mac address in the arp reply made med somewhat optimistic again. Google that one, and you will see Windows users struggling with their 3G cards. So I do not think it's the driver. Still doesn't mean that the firmware does what I hope it does, but it does something in response to the cdc_ether provided data. 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
