On Tue, 2012-02-14 at 09:53 +0100, Bjørn Mork wrote: > Bjørn Mork <bjorn@xxxxxxx> writes: > > > grepping around I found that there are at least one example of a driver > > providing a headerless interface. From drivers/net/usb/hso.c : > > > > net->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST; > > net->type = ARPHRD_NONE; > > > > > > Do anyone of you know how this is used? Which tools support it? > > Never mind. I should google before asking. I found these excellent > instructions: http://www.switzernet.com/public/081001-alix-umts-debian/ > which demonstrate it nicely: > > 1) use vendor specific AT commands to connect and retrieve IP config > 2) ifconfig hso0 $PIP netmask 255.255.255.255 && route add default dev hso0 > > and I see that ModemManager also supports it. > > So, although I still do not see the point of this exercise, I could add > a mode like this to the driver. But that would be an additional mode > and not the default, as the device also typically defaults to ethernet > mode. And synchronizing device mode and driver mode would be up to the > managing userspace app (no way around that as long as the driver has no > knowledge of QMI). > > Then there is the question of switching modes. How should this be done? > I'm tempted to use ethtool to set a driver specific flag. That would > require a pretty recent ethtool (v3.2), but would have the advantage > that it is sort of a standard solution to a driver specific problem. > The other options would be private ioctls or module parameters, which > both are obviously inferior. Am I missing anything? I don't know that we really want a "mode switch". Private ioctls, really anything private like this, are usually bad, because clients have to special-case their behavior based on the *driver*. The upstream Qualcomm driver actually does what you propose, and allows switching between rawip and ethernet mode using a private ioctl. I'm really not sure what the point is. Why not just pick one and keep it simple? I don't really care whether or not it's DHCP or RawIP. RawIP is the "cleanest" method, while DHCP is the "most compatible". BTW, on Windows the UML290 is schizophrenic. The only place the IPv6 address appears is in WMC, *not* QMI. The IPv4 address appears in both QMI and WMC. But even in Raw IP mode, packet captures show that Windows is doing DHCPv4 requests as the first thing before traffic begins to flow. So we have basically this: CTL/Get Client ID (for WDS, response 0x03) CTL/Get Client ID (for WDS, response 0x04) CTL/Set Data Format (Raw IP, no QoS) WDS/Set Event (Rates, Transfer stats, Bearer changes) NAS/Get Serving System Info DMS/Get IDs WDS/Set IP Family (to IPv4, using client ID 0x03) WDS/Start Net (using client ID 0x03) WDS/Set IP Family (to IPv6, using client ID 0x04) WDS/Start Net (using client ID 0x04) WDS/Get Settings (using client ID 0x03) * IP: 10.178.0.239 * DNS1: 69.78.134.231 * DNS2: 69.78.80.231 * Gateway: 10.178.0.225 * Gateway Subnet Mask: 255.255.255.224 Then packets begin to flow via Raw IP. And wireshark says something like this: 1: 0.0.0.0 -> 255.255.255.255 DHCP Discover 2: 10.178.0.225 -> 10.178.0.239 DHCP Offer 3: 0.0.0.0 -> 255.255.255.255 DHCP Request 4: 10.178.0.225 -> 10.178.0.239 DHCP ACK 5: 10.178.0.239 -> 224.0.0.22 Multicast V3 Membership Report 6: 10.178.0.239 -> 10.178.0.255 NBNS Registration NB <computer name> ... <more NetBIOS junk> 20: 10.178.0.239-> 69.78.134.231 DNS Standard query A <dns name> The UML290 does not show anything IPv6 related in QMI besides the Start/Stop Net commands. I do see the IPv6 address in the WMC dumps from the WMC port though. I don't recall ever seeing the IPv6 addressing details happening over QMI, but I'd have to do another dump to be sure. Windows might actually be listenting for RAs on the interface, since ISTR that's officially supported in the 3GPP standards. It's certainly mentioned in the eHRPD stuff for handoff between LTE and EVDO. Dan -- 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
