Hi Bjorn, > >> Try setting the data format then to make sure it's in 802.3 mode. See > >> the CTL/Set Data Format command: > >> > >> 26 00 09 00 01 01 00 00 10 02 00 01 00 > >> > >> Cmd: 0x0026 (SET_DATA_FORMAT) > >> Size: 0x0009 > >> > >> TLV: 0x01 (Format) > >> Size: 0x0001 > >> Data: 0x00 (0 = no QoS Header, 1 = include QoS header) > >> > >> TLV: 0x10 (Protocol) > >> Size: 0x0002 > >> Data[0]: 0x01 (1 = 802.3, 2 = raw IP mode) > >> Data[1]: 0x00 > >> > >> > Ugh. So I now send the QMI command only on reconnects. Seems to do the > >> > job. But I expect there are other weird issues like this... > >> > >> Try the data format thing. I don't think that's a firmware bug really, > >> but simply that you didn't set the format first. The UML290 sends this > >> command to ensure the data format is always [ no QoS, raw IP ]. > > > > I rather have these all running in raw IP mode. The 802.3 framing is > > utterly stupid. > > > > The only reason why people do 802.3, because that is the only way to > > make DHCP work in most operating system. And in Linux that is even true > > for dhclient. > > > > Since you mentioned WiMAX above, the original netdev was pure IP without > > any fake 802.3 framing. We could just make this fly with dhclient. > > > > The real lesson learned is that IP configuration has to come out of band > > anyway. Otherwise this all turns into insane stuff. > > I have now played a bit with the command Dan posted above, and it works > reliably as he documented it. The only issues to be aware of is that > you cannot change mode while a connection is active and that the mode is > reset to default when the device is reset. Both making sense. > > But I am starting to wonder whether supporting this mode makes any > sense... What do you expect from it? > > There are several possible approaches, all with drawbacks: > 1) define a new "raw IP" header format and don't touch the packets in > the driver > 2) use ARPHRD_NONE (which is correct AFAICS) and don't touch the packets > in the driver > 3) keep ARPHRD_ETHER and strip/add headers in the driver > > There is no doubt that alternative 3 works best. It makes every tool, > like any DHCP client, sniffer app or even IPv6 SLAAC just work. And the > driver changes are not much either: Add NOARP flag on open, > skb_pull(skb, ETH_HLEN) on tx, and skb_push(skb, ETH_HLEN) on rx (with a > few additional lines filling in some sane content). > > But why? The device already does this work for us. Saving 1% on the > USB link doesn't seem to matter much, does it? > > Alternative 1 or 2 could have made some sense if there were any tools > readily available to use such interfaces. But there are not. Like > DHCP, which is supported by the device in the raw IP mode as well. You'd > have to write your own client to use it. Or SLAAC, where you'd have to > add some workaround to net/ipv6/addrconf.c. This can of course be > fixed, but adding complexity to both driver and userspace tools should > require some justification. > > I just don't think any of this is worth bothering with, unless there are > some advantages to the raw IP mode. And I can't find any. I do not wanna run DHCP at all on these links. I assume we have a command that tells us what IP and DNS are used and then we just set it. Running DHCP is as stupid as using PPP for communication with the modem. Actually DHCP and an Ethernet card has the inherent disadvantage that you need a netmask and also have to deal with ARP. Why would you do that if your device is not an Ethernet card. Essentially you are blocking more than the one needed IP address and forcing extra overhead in just getting your packets over the network. The over the air links are IP and the kernel just exposing a Point-to-point network interface is perfectly fine. It can like any other device you create with TUN/TAP for example. It does not matter what type it is as long as you make it Point-to-point. Regards Marcel -- 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
