[Dnsmasq-discuss] SLAAC fails with OS X (El Capitan) host unless neighbor table is cleared

John Hemmick John.Hemmick at silabs.com
Thu Jun 9 02:00:02 BST 2016


Hello

I have the following settings in my dnsmasq.conf, for dnsmasq running on Raspbian/raspberry pi, who has a static ipv6 address of bbbb::1

#dnsmasq.conf on raspberry pi

interface=wlan0


domain=mydomain

dhcp-fqdn

enable-ra

dhcp-option=option6:dns-server,[bbbb::1]

dhcp-range=bbbb::,ra-names,1h


server=8.8.8.8

dhcp-range=192.168.222.50,192.168.222.150,12h

dhcp-authoritative


#disable DNS

port=0


no-resolv


Here is the ifconfig of the pi:

wlan0     Link encap:Ethernet  HWaddr 74:da:38:42:58:85

          inet addr:192.168.222.1  Bcast:192.168.222.255  Mask:255.255.255.0

          inet6 addr: fe80::76da:38ff:fe42:5885/64 Scope:Link

          inet6 addr: bbbb::1/64 Scope:Global

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:72471 errors:0 dropped:6750 overruns:0 frame:0

          TX packets:21562 errors:0 dropped:25 overruns:0 carrier:0

          collisions:0 txqueuelen:1000

          RX bytes:5101364 (4.8 MiB)  TX bytes:4199484 (4.0 MiB)

I can see the following traffic on the interface wlan0 on the pi, when I execute ‘ping6 bbbb::1’ on the macintosh:


pi at raspberrypi ~/ndppd-master $ sudo tcpdump -i wlan0 icmp6

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes

00:39:38.523668 IP6 bbbb::1 > ff02::1:ff89:af6b: ICMP6, neighbor solicitation, who has bbbb::f65c:89ff:fe89:af6b, length 32

00:39:38.529666 IP6 bbbb::f65c:89ff:fe89:af6b > bbbb::1: ICMP6, echo request, seq 52, length 16

00:39:39.529612 IP6 bbbb::f65c:89ff:fe89:af6b > bbbb::1: ICMP6, echo request, seq 53, length 16

00:39:39.529984 IP6 bbbb::1 > ff02::1:ff89:af6b: ICMP6, neighbor solicitation, who has bbbb::f65c:89ff:fe89:af6b, length 32

00:39:40.523668 IP6 bbbb::1 > ff02::1:ff89:af6b: ICMP6, neighbor solicitation, who has bbbb::f65c:89ff:fe89:af6b, length 32

00:39:40.539558 IP6 bbbb::f65c:89ff:fe89:af6b > bbbb::1: ICMP6, echo request, seq 54, length 16

00:39:41.523674 IP6 bbbb::1 > ff02::1:ff89:af6b: ICMP6, neighbor solicitation, who has bbbb::f65c:89ff:fe89:af6b, length 32

00:39:41.531033 IP6 bbbb::f65c:89ff:fe89:af6b > bbbb::1: ICMP6, echo request, seq 55, length 16

00:39:42.530378 IP6 bbbb::f65c:89ff:fe89:af6b > bbbb::1: ICMP6, echo request, seq 56, length 16

00:39:42.530836 IP6 bbbb::1 > ff02::1:ff89:af6b: ICMP6, neighbor solicitation, who has bbbb::f65c:89ff:fe89:af6b, length 32

00:39:43.523661 IP6 bbbb::1 > ff02::1:ff89:af6b: ICMP6, neighbor solicitation, who has bbbb::f65c:89ff:fe89:af6b, length 32

00:39:43.530315 IP6 bbbb::f65c:89ff:fe89:af6b > bbbb::1: ICMP6, echo request, seq 57, length 16

00:39:44.523668 IP6 bbbb::1 > ff02::1:ff89:af6b: ICMP6, neighbor solicitation, who has bbbb::f65c:89ff:fe89:af6b, length 32

00:39:44.529358 IP6 bbbb::f65c:89ff:fe89:af6b > bbbb::1: ICMP6, echo request, seq 58, length 16

00:39:45.529469 IP6 bbbb::f65c:89ff:fe89:af6b > bbbb::1: ICMP6, echo request, seq 59, length 16

00:39:45.529828 IP6 bbbb::1 > ff02::1:ff89:af6b: ICMP6, neighbor solicitation, who has bbbb::f65c:89ff:fe89:af6b, length 32


It appears that my pi is soliciting a multicast address belonging to the mac (ff02::1:ff89:af6b) for the address that dnsmasq assigned to the mac (bbbb::f65c:89ff:fe89:af6b) but that the mac does not reply with a neighbor advertisement.


The neighbor table on the mac looks like this:


Neighbor                        Linklayer Address  Netif Expire    St Flgs Prbs

bbbb::8a:ae86:b5aa:d727         f4:5c:89:89:af:6b    en0 permanent R

bbbb::f65c:89ff:fe89:af6b       f4:5c:89:89:af:6b    en0 permanent R

fe80::1%lo0                     (incomplete)         lo0 permanent R

fe80::250:b6ff:fec9:79f7%en5    0:50:b6:c9:79:f7     en5 permanent R

fe80::76da:38ff:fe42:5885%en0   74:da:38:42:58:85    en0 34s       R  R

fe80::f65c:89ff:fe89:af6b%en0   f4:5c:89:89:af:6b    en0 permanent R

fe80::250:b6ff:fec9:79f7%vlan0  0:50:b6:c9:79:f7   vlan0 permanent R

fe80::9c75:74ff:fea1:861a%awdl0 9e:75:74:a1:86:1a  awdl0 permanent R

fe80::21b:17ff:fe00:130%vlan1   0:1b:17:0:1:30     vlan1 23h41m35s S  R

fe80::250:b6ff:fec9:79f7%vlan1  0:50:b6:c9:79:f7   vlan1 permanent R



Until the neighbor table is cleared, the mac will never send a neighbor advertisement to the raspberry pi, and thus, the raspberry pi never responds to the ICMP6 request:


MACINTOSH_EL_CAPITAN$ sudo ndp -cn

Password:

fe80::76da:38ff:fe42:5885%en0 (fe80::76da:38ff:fe42:5885%en0) deleted

fe80::21b:17ff:fe00:130%vlan1 (fe80::21b:17ff:fe00:130%vlan1) deleted

Why is the presence of these two neighbors in the table preventing my macintosh from notifying DNSMASQ on my pi that my mac has the bbbb address that DNSMASQ assigned to it?

Is the fact that en0 has an identical link-local address to the link-local on wlan0 that would be used for neighbor solicitation/advertisement a problem? (see tcpdump on wlan0 when the neighbor table is cleared on the mac):


00:50:20.803643 IP6 fe80::76da:38ff:fe42:5885 > bbbb::f65c:89ff:fe89:af6b: ICMP6, neighbor solicitation, who has bbbb::f65c:89ff:fe89:af6b, length 32

00:50:20.808954 IP6 fe80::f65c:89ff:fe89:af6b > fe80::76da:38ff:fe42:5885: ICMP6, neighbor advertisement, tgt is bbbb::f65c:89ff:fe89:af6b, length 24


Above, we see that the pi (fe80::76da:38ff:fe42:5885) solicits the address it gave to the mac on the same link-local neighbor entry deleted off of en0 (fe80::f65c:89ff:fe89:af6b)


What is dnsmasq doing? Why does it solicit the address that it handed out to my mac? What is it trying to do by soliciting an address that it handed out itself? NUD?  Is there a way to disable this solicitation in dnsmasq?  I have noticed that I do not have this problem with radvd — but I would much rather use dnsmasq, as I intend to add DNS services in the future.


Best Regards,

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20160609/15ed20be/attachment-0001.html>


More information about the Dnsmasq-discuss mailing list