Bjørn Mork <bjorn@xxxxxxx> writes:
> I see no answers to the NS there, so I assume that's the reason this
> does not work.
Stupid me. My testing was bogus because I switched on/off the IFF_NOARP
without adding/deleting addresses. Reading the code is better...
We are not supposed to answer these solictiations because we haven't
joined the solicited-node multicast address they are sent to:
void addrconf_join_solict(struct net_device *dev, const struct in6_addr *addr)
{
struct in6_addr maddr;
if (dev->flags&(IFF_LOOPBACK|IFF_NOARP))
return;
addrconf_addr_solict_mult(addr, &maddr);
ipv6_dev_mc_inc(dev, &maddr);
}
So this all works as expected. But the underlying assumptions in the
driver could very well be wrong. Seeing the NS from the firmware was
really surprising to me. I thought it should work anyway, but it seems I
was wrong. IFF_NOARP effectively disables all ND operations. So if we
have to support them, then we probably must add some additional driver
hack.
I am not exactly sure what to do. MAC addresses have no meaning in
MBIM, so IFF_NOARP is really appropriate in my opinion. We could maybe
make the driver recognize solicited-node addresses and blindly replace
them with something else (all-nodes for example). But that's dead
ugly...
Ideas are welcome.
For a start, you could try turning on ndisc_notify on the interface and
see if that is good enough for the device firmware:
sysctl -w net.ipv6.conf.wwan0.ndisc_notify=1
This will make Linux send unsolictied NAs every time an address is added
to the interface. You'll have change the setting before any IPv6
addresses are added. I.e. before connecting and receiving the RA.
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
