Thread (5 messages) 5 messages, 2 authors, 2013-10-31

Re: [RFC] ipv6: always join solicited-node address

From: Bjørn Mork <bjorn@mork.no>
Date: 2013-10-31 15:01:32

Hannes Frederic Sowa [off-list ref] writes:
On Mon, Oct 14, 2013 at 09:09:59AM +0200, Bjørn Mork wrote:
quoted
Yes, but that would also make the IP layer try to resolve IP to link
layer addressess both for IPv4 and IPv6, which just won't work. At least
not for IPv4, where there just is no way to transport an ARP to the
modem.  And I assume it may fail for IPv6 too on any sane device.
I don't think that clearing the IFF_NOARP flag would kill connectivity
for either IPv4 or IPv6.
It does, because the neigbours cannot be resolved.
It may compromise security for IPv6 though
(no idea how the telco network behind the modem looks like).
quoted
quoted
Is this a specific bug of the modem you are using or are all devices
powered by this driver like this?
Unfortunately I have no IPv6 enabled SIM myself, so I have no
information about other devices.  This report was based on user
feedback.

I assume the bug is specific to this firmware implementation, probably
extending to all similar devices from the same vendor.  But it could be
more common than that.  The fact that the bug is there indicates that
this works just fine in Windows.

Yes, I realize that I am in ugly-hack-to-workaround-firmware-issues land
again... But it sure would be nice to have some way for a driver to
indicate that L2 neighbour tables are meaningless, but that any incoming
requests should still be answered.
L2 neighbour tables are resolved on demand and won't be queried for the
link you are talking about (at least for IPv6, but I assume IPv4, too).

A new flag should have clear semantics then:

* split IFF_NOARP to IFF_NOARP and IFF_NONDISC
* split IFF_NOARP to IFF_NOLLRESOLV_RESPONSE and IFF_NOLLRESOLV_MODIFY
  (each one flag which is applicable for both IPv4 and IPv6)

I tend to lean towards the last alternative but still wonder if this is
just overhead for this one buggy device.
Thanks a lot for your review and thoughts on this.  I do agree 100% with
your last comment here, and ended up with an in-driver workaround
instead.

It's not beautiful, but at least it doesn't add a lot of core code for
this very special purpose.



Bjørn
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help