Marcel Holtmann <marcel@xxxxxxxxxxxx> writes: > Dan Williams: >> 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. 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
