Bjørn Mork <bj...@mork.no> writes:
> 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...
Hmm, reading RFC4861 I am wondering if the above dependency on IFF_NOARP
is allowed:
7.2.1. Interface Initialization
When a multicast-capable interface becomes enabled, the node MUST
join the all-nodes multicast address on that interface, as well as
the solicited-node multicast address corresponding to each of the IP
addresses assigned to the interface.
I'm going to test a patch on the netdev people to see if I have
misunderstood this completely...
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
