Dan Williams <dcbw@xxxxxxxxxx> writes: > 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". I believe this is an excellent summary of the situation. And I agree: Let's just pick one and keep it simple, and I'm hereby picking the ethernet mode. Rationale: It's already in linux-next. It makes DHCP work on Linux too. There are no addressing advantages to the raw IP mode after all. Ethernet mode has the simplest driver code. And it gives end users that warm fuzzy feeling. But we might consider using IFF_NOARP by default to avoid the unnecessary fake ARPs? > 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. Yes, that works. Guess Windows has native support for this? Unfortunately Linux DHCP clients use AF_PACKET or similar to create a full DHCP discover packet including L2 headers, so supporting DHCP on Linux with raw IP would either require a driver hack adding/stripping headers or a special DHCP client. I don't think either solution is acceptable. BTW, to the point that Windows does DHCPv4 before traffic flows: I believe the device requires either DHCP or QMI_WDS/Get Settings before it will forward any traffic. > 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) Did you get a chance to verify whether it works with the ethernet data format? > WDS/Set Event (Rates, Transfer stats, Bearer changes) > NAS/Get Serving System Info > DMS/Get IDs I assume these are just nice-to-have for a managing app and not really required. > 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) Thanks, so this is the proper way to start a dual stack interface? Looks like it can be done by the managing app without any additional driver changes. > 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 I started wondering about these netmasks after Marcel made me aware that all this is virtual. Ever wondered why you sometimes get these larger subnets? It's most likely because you were assigned the IP ending in 239, and to avoid that being the broadcast address the network had to be >16 addresses. > 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. Does the driver ever call WDS/Get Settings using client ID 0x04? > 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. So there is a global IPv6 address (or prefix?) assigned? And you can forward IPv6 traffic using it as a source address? Damn, I need an IPv6 enabled network. Think I know someone to poke... 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
