Hi Dan, > > > did you say that the char device was protocol agnostic? What other > > > protocols might it speak here? > > > > Don't really know. Just observed the fact there's nothing preventing > > some other chipset vendor from putting their protocol in there. And > > guessing that if one vendor already did, then it's very likely that > > others will follow. > > > > But regarding the device naming, I agree that /dev/qmiX has a nicer look > > and feel. I could easily be convinced to change that. We can always use > > the "for historical reasons" argument when explaining this later. > > > > >> But I soon found out that this was too restrictive for protocol debug > > >> usage, so of you open the device read-only then you will get all > > >> packets. Including those sent by other clients, which again includes > > >> the internal one managing the wwanX network interface. > > > > > > I don't think that's a problem. > > > > So I made the driver copy all packets, both sent and received, to all > > clients. That simplified things quite a bit. > > > > Still haven't had a chance to look at a better buffering solution, and > > given the time on my hands I've concluded that I won't do that. The > > code I've got now is working, so let's just use it. > > > > Instead I looked at getting better response when the net device isn't > > running, and getting rid of the stupid read loops. The thing is that > > usbnet already handles status interrupts most of the time, but kills > > the status URB when it thinks it doesn't need it. So I steal the URB > > and submit it whenever it suits me. Hackish, but I don't know what > > else to do given that I do not want to copy all the usbnet code to > > make a few minor changes... > > > > Anyway, the new reading code is both simpler and much more responsive > > than before. As expected. The loops were never a great idea. > > > > While struggling with this I've also come over a few new firmware > > behavioural surprises. Like: Reconnecting immediately after an unwanted > > disconnect works fine, but IP packets are not forwarded until the > > address configuration is requested again either via DHCP or via QMI. > > OK, so I don't know how to trigger a DHCP RENEW from a driver (well, I > > do but you don't want to see that :-). So I send a QMI get runtime > > The answer here is you don't try to do anything with DHCP. That's a > total layer violation and needs to be left to userspace. At some point > you're not going to be able to keep putting this stuff in the kernel > because it really doesn't belong there :) It's really something stuff > in userspace should be doing. You're going to eventually have to run a > modem manager daemon anyway. > > Besides, the userspace daemon is the only thing that can actually make > the correct policy decision about unwanted disconnects; if you make the > driver reconnect automatically, that's a policy decision that shouldn't > be made in the kernel. A userspace daemon should be figuring out the > reason for the disconnect and either indicating that to the user, or > attempting to reconnect. If you're getting disconnected because, say, > you've run over your traffic quotas for the month, the driver shouldn't > be continuously reconnecting, but the userspace daemon might well have > more information about that because it can track data usage. > > The Intel WiMAX stack also wants a DHCP renew indication for when the > device comes out of idle mode. So it makes sense to do this > generically. About all I can think of (besides abusing IFF_DORMANT > which doesn't seem quite right) is a new netlink indication that clients > (including dhcp clients) could watch for and then perform the renew. to be fair to the Intel WiMAX stack it was not what this wanted, it is how WiMAX is defined. And from my point of view, that was pretty stupid idea in the first place. IPv6 would have solved their problem, but not every gets that and instead they hack around IPv4 ;) > > settings requests. Works fine, making disconnects barely noticable. > > But enter whacky firmware: If I send the QMI get runtime command > > immediately after the *first* connect, before the DHCP client has > > requested an address, then I end up receiving raw IP packets with no > > ethernet header. > > 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. > > Which makes me think that I'd better not touch this anymore as long as > > it is working. > > > > I've therefore sent an updated version of the driver to linux-usb and > > netdev, as you might already have noticed. I'm guessing that the > > character device driver will have a hard time being accepted on netdev, > > but I haven't got any other suggestions at the moment. It *is* really > > part of a CDC networking driver... sort of. > > Yeah, we'll see, but we really, really do need a way of handling this > sort of thing and if it's all using the same endpoints as the CDC ether > driver (which it is) and since they are both intimately related it's > hard to see how they really should be separated. Unfortunately that's > the mechanism Qualcomm chose instead of a separate USB interface for the > QMI stuff :(. 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. 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
