Thomas Schäfer <tschaefer@xxxxxxxxxxx> writes: > Hi, > > I have some news about this device. Under Windows 8.1 (6.3)(testversion) > with these IDs: > > USB\VID_12D1&PID_1F16&REV_0102&MI_00 > USB\VID_12D1&PID_1F16&MI_00 > > USB\Class_02&SubClass_0e&Prot_00 > USB\Class_02&SubClass_0e > USB\Class_02 > > > the device works as mobile broadband device with IPv6. > So I think the firmware is ok, or Microsoft has patched its driver a little > bit more. This is the device which sends NS messages to the host, isn't it? If the fact that Linux does not respond to these is the reason it doesn't work on Linux, then I'd say the firmware is far from OK. MBIM has no neighbour concept at all, and requiring a NA to work is so wrong it's not even funny. But we don't know if this is really the problem. Any chance you could snoop the Windows IPv6 session? I'm interesting in seeing the NS and NA messages. In particular any NA from Windows. Don't need many packets, only the part where the modem tries to discover the host "L2 address". Did you try any of the ND tuning controls on Linux? Turning on ARP before bringing up the interface might work on IPv6 (but fail for IPv4): ifconfig wwan0 arp Trying sysctl -w net.ipv6.conf.wwan0.ndisc_notify = 1 would also be interesting (although I have no idea what the effect would be in combination with IFF_NOARP). Another interesting test would be adding the solicited node multicast address manually, but I can't figure out how to do that using e.g. "ip maddr".... You can certainly do it with setsockopt(), but that's a bit more work than it should be. Anyway, after discussing the issue on netdev I am convinced that, although not formally correct, not joining this multicast group does give the wanted and expected result. We could make the behaviour absolutely correct by joining the group and add additional code to prevent responses to any received NS, but the net result would be the same. Responding to NS when we have disabled ARP (which has a dual IPv4/IPv6 neighbour discovery meaning here), would be wrong. And ARP is impossible on MBIM, so we cannot enable that (at least not with the typical modems fake dhcp server, which will configure a fake subnet). We can either add workaround code to make the driver fake NAs if necessary, or we can rewrite the ndisc code so that it's possible for a driver to fine tune the wanted response pattern. But I'd really like to confirm that this is necessary first. The first solution is simple but ugly. The second is more generic, but probably wasting netdevice flags for a single buggy firmware on a single device on a single driver... 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
