Hi Bjorn, > >> 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. > > I tend to agree. It's a stupid hack to avoid fixing the host/driver. > The ethernet header doesn't add any value to neither host nor device. > But I believe you will have to fix some issues like the IPv6 stack > expecting a mac address and such before you can make it fly. Or let the > driver add/strip the ethernet header. Might be easier, but doesn't > entirely get rid of the hack. Makes the device work in both modes > though, and it does avoid using USB bandwith and device CPU for useless > headers, so it is still a gain. I do not think we have a problem with the IPv6 stack. Maybe with some of the link-local configuration, but then that is fine since we will not use them on LTE or any 2G/3G network interface anyway. And this is not the first piece of hardware that does Raw IP handling. I worked on the Infineon modem and they do Raw IP over 27.010 multiplexer TTY port. Works fine as well. We just create a pure IP netdev device (or use TUN/TAP if we had to run it in userspace). > Doing something with the raw IP mode is definitely on my wishlist, but > it doesn't have high priority at the moment. I had a quick look at the > Android rmnet driver and believe most of what's needed is there already. > It's just a matter of splitting out the parts we need, and getting the > IP ARPHDR stuff integrated. Right... > > > 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. > > Yeah, and then we meet the question of whether the driver should "fix" > this or if that fix needs to go into every userspace app. I believe a > limited driver fix is better as it will make every legacy app just work. It was clearly a dhclient fault for being stupid and hard coded with ARPHRD_ values. The whole processing loop in dhclient is bad anyway. Running DHCP on an IP interface should not be a big deal. We have our own DHCP client+server library in ConnMan and you could use that for testing if you wanna compare. If you don't wanna deal with dhclient ;) > > Actually the USB CDC usage with USB_CDC_SEND_ENCAPSULATED_COMMAND and > > USB_CDC_GET_ENCAPSULATED_RESPONSE is pretty much a standard. It is just > > that bNotificationType with USB_CDC_NOTIFY_RESPONSE_AVAILABLE is a bit > > of funky way of doing things in the first place. > > > > However all not handled responses could be just forwarded to userspace > > as they are. And kernel drivers claiming some responses can just keep > > consuming them. For example USB_CDC_NOTIFY_NETWORK_CONNECTION can be > > still handled inside the driver. > > That is my working plan, and that is what cdc-wdm currently does as long > as the device exports a dedicated "device management" interface. The > only issue that needs to be fixed is making cdc-wdm share an usb > interface with a network driver. A little tricky as they must share the > interrupt endpoint, but not at all impossible. You could just register a callback notification after the network driver parsed the interrupt URB and decided it is not useful. I would also almost say it is fine to integrate cdc-wdm support directly into the network driver and activate it for certain VID:PID combinations. > I also intend to add the bare minimum of the embedded QMI to the driver > to allow "ip link set dev wwanX up" to Just Work(tm). I consider that > much the same as configuring the registers of your PCI ethernet device > to allow it to get link. > > You do *not* want to run a userspace app with detailed knowledge of your > PCI ethernet device just to get a link, do you? I would be against this. You get USB_CDC_NOTIFY_NETWORK_CONNECTION, but I prefer not to have ifconfig up execute any QMI commands. Can we please run all of that in userspace. Same happens for devices like MBM already. You need to drive the AT channel since otherwise you are not getting any connections. And the LOWER_UP just signals the link. We are not putting any AT commands into the kernel either, so I rather have QMI staying out of it. Especially since you will run into some resource allocation issues with QMI and its services. That makes this whole think even more complicated. At that point we need to put QMI as a socket family in the kernel (similar to Phonet or CAIF). If you don't want that, then lets leave all QMI out of the kernel. 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
