search

openwrt / odhcpd

This repository is a mirror of https://git.openwrt.org/?p=project/odhcpd.git. Pull requests will be accepted which will be merged in odhcpd.git
GNU General Public License v2.0
163 stars 99 forks source link

Invalid Neighbor Solicitation for 6to4 address #32

Closed rfc2822 closed 9 years ago

rfc2822 commented 9 years ago

My general IPv6 configuration

WAN bridge:

          inet addr:83.191.117.55  P-t-P:62.218.4.126  Mask:255.255.255.255
          inet6 addr: ::83.191.117.55/128 Scope:Compat
          inet6 addr: 2002:53bf:7537::1/16 Scope:Global

LAN bridge:

          inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: 2002:53bf:7537::1/64 Scope:Global
          inet6 addr: fe80::c03f:eff:fe7c:186a/64 Scope:Link

Other details:

When I set "IPv6 Settings / Router Advertisement Service" to "server mode" in LuCI, it causes this odhcpd setup (/etc/dhcp):

config dhcp 'lan'
    option interface 'lan'
    option start '100'
    option limit '150'
    option leasetime '12h'
    option ra 'server'

which seems to be OK. However, as soon as it's up, it sends

1) a correct Router Advertisement (advertising the prefix 2002:53bf:7537::) 2) a correct Neighbor Solicitation for target 2002:53bf:7537:0:1e6f:65ff:fe86:102b 3) an invalid Neighbour Solicitiation for target 2002:53bf:752d::eb6 Note the prefix 2002:53bf:752d which is different from the correct 2002:53bf:7537 (last two digits).

This causes the other PC to add both those IPv6 addresses:

enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.11  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 2002:53bf:7537:0:1e6f:65ff:fe86:102b  prefixlen 64  scopeid 0x0<global>
        inet6 2002:53bf:752d::eb6  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::1e6f:65ff:fe86:102b  prefixlen 64  scopeid 0x20<link>

And of course, 2002:53bf:752d::eb6 won't work (100% packet loss). When I remove 2002:53bf:752d::eb6 manually, it works:

$ sudo ifconfig enp2s0 del 2002:53bf:752d::eb6
$ ping6 -v www.google.com
PING www.google.com(fra07s31-in-x12.1e100.net) 56 data bytes
64 bytes from fra07s31-in-x12.1e100.net: icmp_seq=1 ttl=58 time=65.8 ms
64 bytes from fra07s31-in-x12.1e100.net: icmp_seq=2 ttl=58 time=63.8 ms

I can't find the invalid address 2002:53bf:752d::eb6 or its invalid prefix 2002:53bf:752d ANYWHERE on the router (not in interface info and not in the routes) so I guess this prefix may be calculated and advertised incorrectly by ohdcpd.

Workaround

Disable odhcpd completely and use radvd. Only the correct IPv6 address (2002:53bf:7537:0:1e6f:65ff:fe86:102b) is sent via Neighbor Solicitation and will be used by the other PC.

I think it's an odhcpd-related issue because it works fine with radvd.

rfc2822 commented 9 years ago

Addition: 2002:53bf:752d::eb6 is sent to the network as IPv6 address even without IPv6, only with ULA defined (when odhcpd is in ra mode)…

sbyx commented 9 years ago

Do you by chance have a changing IPv4 address? It seems like this address might come from an earlier stateful dhcpv6 interaction when your ipv4 address and thus 6to4 prefix was different. In addition your client doesn't seem to support dhcpv6 reconfigure.

Workarounds here: use a low leasetime e.g. few minutes or set ra_management to 0 (stateless only) so dhcpv6 is not used statefully.

rfc2822 commented 9 years ago

Do you by chance have a changing IPv4 address?

Yes, but I have rebooted the router several times and in this time, I always had the same IPv4 address.

It seems like this address might come from an earlier stateful dhcpv6 interaction when your ipv4 address and thus 6to4 prefix was different. In addition your client doesn't seem to support dhcpv6 reconfigure.

I have indeed found the ::eb6 address in /tmp/hosts/odhcp (or something like that) and have removed it. However, my preferred setup is without DHCPv6 and RA only.

After a router reboot, there is no /tmp/hosts/odhcp or whatever file that contains the ::eb6 address. Also, I have now configured an additional IPv6 ULA network (fd0d:4bb3:ee6c::/48). RA is active, DHCPv6 is not.

On the other PC, I get (after reconfiguring the network interface) now:

enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.11  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 2002:53bf:7537:0:1e6f:65ff:fe86:102b  prefixlen 64  scopeid 0x0<global>
        inet6 fd0d:4bb3:ee6c::eb6  prefixlen 128  scopeid 0x0<global>
        inet6 fd0d:4bb3:ee6c:0:1e6f:65ff:fe86:102b  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::1e6f:65ff:fe86:102b  prefixlen 64  scopeid 0x20<link>
        ether 1c:6f:65:86:10:2b  txqueuelen 1000  (Ethernet)

So the 6to4 address is correct now, however, the strange ::eb6 is added to the private network now. Why? And where is the ::eb6 address coming from?

# find /etc /tmp -exec grep eb6 '{}' \;
grep: /etc/fstab: No such file or directory
grep: /etc/rc.d/S50radvd: No such file or directory
grep: /tmp/run/hostapd/wlan0-1: No such device or address
grep: /tmp/run/hostapd/wlan0: No such device or address
efeb603b604e292d214c6174ec575bfb  /var/run/config.check/wireless
grep: /tmp/run/ubus.sock: No such device or address
rfc2822 commented 9 years ago

Btw, thanks for your help, but I don't think this issue is resolved yet. Your workarounds are not applicable because I don't use DHCPv6 (the lease might by from a try where I tried to use it as a workaround, but I don't use it anymore).

sbyx commented 9 years ago

The eb6 comes from stateful dhcpv6. Have you set ra_management as I suggested?

rfc2822 commented 9 years ago

The eb6 comes from stateful dhcpv6.

I have disabled DHCPv6 completely and erased every trace of it that I have found. How comes that it's still active? Where is the ::eb6 stored? On the router or on the other PC?

Have you set ra_management as I suggested?

I had erroneously set it in config odhcpd instead of config dhcp lan previously, so that it didn't work. I have set it in config dhcp lan now and it now works :+1: Thanks!

However, I still don't understand why.

ra_management   integer 1           RA management mode
        0: no M-Flag but A-Flag, 1: both M and A, 2: M but not A

Ok, I have now seen that the default value is 1, meaing the M-Flag is set. According to RFC 4861, the M flag means that "addresses are available via DHCPv6". Why is this the default when "dhcp6" is "disabled"? Also, where comes the ::eb6 address from? It must be stored somewhere?