On Tue, Jan 27, 2009 at 09:17:02PM -0700, Mark Zimmerman wrote: > On Sun, Jan 25, 2009 at 09:56:50PM +0000, Stuart Henderson wrote: > > On 2009-01-24, Mark Zimmerman <[email protected]> wrote: > > > Greetings: > > > > > > I am trying to get ipv6 neighbor discovery working over a wpa wireless > > > link between two ral interfaces. I get nothing, and no error messages > > > from rtadvd on the router. The router is 4.4-current and the laptop is > > > a 4.3 snapshot that I really need to update. Ipv4 works fine. > > > > > > Before I spend too much time on this, I wanted to check if this might > > > not be a supported capability. Should it be possible to do this? > > > > ral/wpa/ipv6 works ok here with -current from the last week on the > > laptop and Dec 13 snap on the hostap box... > > > > if you really need to update the laptop, why not do that before > > spending any time on it. > > > > OK, I reinstalled the laptop with -current and it still does not work, > so here is the situation in more detail. > > The laptop (old thinkpad 560x) has a cardbus slot and I have xl > (wired) and ral (wireless) NICs. In both cases, the connection is made > to the same router, running 4.4-stable. When I boot the laptop with > the xl card plugged in, rtsol is successful in getting ipv6 > autoconfiguration. I ran rtadvd on the router in debug mode and saw a > single solicitation: > > RS received from fe80::200:86ff:fe5d:71af on vr1 > set timer to 0:183254. waiting for inputs or timeout > RA timer on vr1 is expired > send RA on vr1, # of waitings = 1 > > When I start the laptop with the wireless card plugged in, rtadvd on > the router shows three solicitations but nothing ever gets back to the > laptop: > > RS received from fe80::20e:3bff:fe04:9766 on ral0 > set timer to 0:70622. waiting for inputs or timeout > RA timer on ral0 is expired > send RA on ral0, # of waitings = 1 > RS received from fe80::20e:3bff:fe04:9766 on ral0 > set timer to 0:101601. waiting for inputs or timeout > RA timer on ral0 is expired > send RA on ral0, # of waitings = 1 > RS received from fe80::20e:3bff:fe04:9766 on ral0 > set timer to 0:161068. waiting for inputs or timeout > RA timer on ral0 is expired > send RA on ral0, # of waitings = 1 > > On the laptop, running rtsol -d: > > checking if ral0 is ready... > ral0 is ready > send RS on ral0, whose state is 2 > send RS on ral0, whose state is 2 > send RS on ral0, whose state is 2 > No answer after sending 3 RSs > stop timer for ral0 > there is no timer > > pf is not enabled on the laptop, and on the router both the wired and > wireless internal interfaces (vr1 and ral) are treated equally. > Nothing relevant is logged by pflogd, even though I log everything > that is blocked except for a few specific exceptions. I will paste the > pf.conf at the end once I finish rambling... > > ral0 on the laptop ends up like this: > > $ ifconfig ral0 > ral0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 > lladdr 00:0e:3b:04:97:66 > priority: 0 > groups: wlan egress > media: IEEE802.11 autoselect mode 11g (DS5 mode 11g) > status: active > ieee80211: nwid theJungle chan 9 bssid 00:0e:8e:20:9e:84 75dB wpapsk > <not displayed> wpaprotos wpa1,wpa2 wpaakms psk,802.1x wpaciphers tkip,ccmp > wpagroupcipher tkip 100dBm > inet6 fe80::20e:3bff:fe04:9766%ral0 prefixlen 64 scopeid 0x3 > inet 192.168.37.32 netmask 0xffffff00 broadcast 192.168.37.255 > > Anyone have any ideas on what I am missing?? > > Here is the pf.conf: > > ext_if="vr0" > int_if="vr1" > wif_if="ral0" > tun_if="gif0" > > udp_noise="{135,139,1026,1027,1028,1434}" > tcp_noise="{135,139,445,1433}" > icmp6_ok="{128, 129, 133, 134, 135, 136}" > > set skip on lo > > scrub in > > nat-anchor "ftp-proxy/*" > rdr-anchor "ftp-proxy/*" > nat on $ext_if from !($ext_if) -> ($ext_if:0) > rdr pass on $int_if proto tcp to port ftp -> 127.0.0.1 port 8021 > rdr pass on $wif_if proto tcp to port ftp -> 127.0.0.1 port 8021 > > anchor "ftp-proxy/*" > block in log > block in on $ext_if inet proto udp from any to any port $udp_noise > block in on $ext_if inet proto tcp from any to any port $tcp_noise > block in on $ext_if inet proto icmp from any to any icmp-type echoreq > pass in log on $ext_if inet proto ipv6 > pass in on $ext_if inet proto icmp from 216.17.128.0/17 to any icmp-type > echoreq > pass in on $ext_if inet proto icmp from 64.62.200.2 to any icmp-type echoreq > pass in on $tun_if inet6 proto ipv6-icmp all icmp6-type $icmp6_ok > pass in on $tun_if inet6 proto tcp from any to any port www > pass in on $tun_if inet6 proto tcp from any to any port smtp > pass in log on $tun_if inet6 proto tcp from any to any port domain > #pass in on $tun_if inet6 proto icmp6 from any to any > pass in log on $tun_if inet6 proto udp from any to any > pass out > > pass quick on $int_if no state > pass quick on $wif_if no state > antispoof quick for { lo $int_if $wif_if } >
Rather than infer what traffic is passing based on the lack of blocks, I decided to enable pf on the laptop and add some 'pass quick log' pf rules for icmp6 on both the laptop and the router to be sure of what is happening. I am now as certain as I can be that packet filtering is not the issue. Here are two tests; the first shows what happens when I boot the laptop with the wired interface. The second test is with the wireless. test 1. laptop using xl0: Jan 29 20:14:20.542323 rule 5/(match) pass out on xl0: fe80::200:86ff:fe5d:71af > ff02::2: icmp6: router solicitation Jan 29 20:14:20.830646 rule 4/(match) pass in on xl0: fe80::20d:b9ff:fe15:60fd > ff02::1: icmp6: router advertisement Jan 29 20:14:31.492936 rule 5/(match) pass out on xl0: fe80::200:86ff:fe5d:71af > ff02::2: icmp6: router solicitation Jan 29 20:14:31.542500 rule 4/(match) pass in on xl0: fe80::20d:b9ff:fe15:60fd > ff02::1: icmp6: router advertisement router: Jan 29 20:14:20.542821 rule 27/(match) pass in on vr1: fe80::200:86ff:fe5d:71af > ff02::2: icmp6: router solicitation Jan 29 20:14:20.830720 rule 28/(match) pass out on vr1: fe80::20d:b9ff:fe15:60fd > ff02::1: icmp6: router advertisement Jan 29 20:14:20.830746 rule 27/(match) pass in on vr1: fe80::20d:b9ff:fe15:60fd > ff02::1: icmp6: router advertisement Jan 29 20:14:31.493437 rule 27/(match) pass in on vr1: fe80::200:86ff:fe5d:71af > ff02::2: icmp6: router solicitation Jan 29 20:14:31.542557 rule 28/(match) pass out on vr1: fe80::20d:b9ff:fe15:60fd > ff02::1: icmp6: router advertisement Jan 29 20:14:31.542585 rule 27/(match) pass in on vr1: fe80::20d:b9ff:fe15:60fd > ff02::1: icmp6: router advertisement test 2. laptop using ral0: Jan 29 20:24:45.262725 rule 3/(match) pass out on ral0: fe80::20e:3bff:fe04:9766 > ff02::2: icmp6: router solicitation Jan 29 20:24:49.292774 rule 3/(match) pass out on ral0: fe80::20e:3bff:fe04:9766 > ff02::2: icmp6: router solicitation Jan 29 20:24:53.323035 rule 3/(match) pass out on ral0: fe80::20e:3bff:fe04:9766 > ff02::2: icmp6: router solicitation router: Jan 29 20:24:46.326773 rule 29/(match) pass in on ral0: fe80::20e:3bff:fe04:9766 > ff02::2: icmp6: router solicitation Jan 29 20:24:46.798012 rule 30/(match) pass out on ral0: fe80::20e:8eff:fe20:9e84 > ff02::1: icmp6: router advertisement Jan 29 20:24:46.798041 rule 29/(match) pass in on ral0: fe80::20e:8eff:fe20:9e84 > ff02::1: icmp6: router advertisement Jan 29 20:24:50.336762 rule 29/(match) pass in on ral0: fe80::20e:3bff:fe04:9766 > ff02::2: icmp6: router solicitation Jan 29 20:24:50.578645 rule 30/(match) pass out on ral0: fe80::20e:8eff:fe20:9e84 > ff02::1: icmp6: router advertisement Jan 29 20:24:50.578672 rule 29/(match) pass in on ral0: fe80::20e:8eff:fe20:9e84 > ff02::1: icmp6: router advertisement Jan 29 20:24:54.346963 rule 29/(match) pass in on ral0: fe80::20e:3bff:fe04:9766 > ff02::2: icmp6: router solicitation Jan 29 20:24:54.489318 rule 30/(match) pass out on ral0: fe80::20e:8eff:fe20:9e84 > ff02::1: icmp6: router advertisement Jan 29 20:24:54.489346 rule 29/(match) pass in on ral0: fe80::20e:8eff:fe20:9e84 > ff02::1: icmp6: router advertisement Clearly, when I use ral on the laptop, the router advertisements are permitted out of the router but do not arrive at the laptop. Have there been any post-4.4-stable changes that may have corrected this behavior? -- Mark
