Adrian,

I compiled all of src from head and the problems went away except that
occasionally I get a long (or semi-permanent) lack of connectivity
after a switch in APs.  Often restarting dhclient fixes this, even
though I'm using IPv6.  Its possible that something is missing from
the RA messages, like DNS or default route.

I put a set of iwstats output on http://www.occnc.com/iwn/ .
The last plenary session dump may be the best.  I have ifconfig iwn0
and ifconfig iwn0 scan data to go along with it.  Everything worked
fine for most of the time, then a switch of AP happenned.

Curtis


In message <CAJ-Vmo=7rp7dafq5jjgm8ojjybjty6u2vp-uhqremhamgtf...@mail.gmail.com>
Adrian Chadd writes:
> 
> Maybe the whole cloned interfaces path isn't setting up the ipv6 flags
> correctly?
>  
>  
> -a
>  
>  
> On 1 March 2014 16:02, Curtis Villamizar <cur...@ipv6.occnc.com> wrote:
> >
> > In message 
> > <caj-vmokw4qxop__jkohc68agvc1fxk6ihhuqghfcj67npsj...@mail.gmail.com>
> > Adrian Chadd writes:
> >
> >> Hi,
> >>
> >> Please grab and try 'iwnstats' from head - tools/tools/iwn/iwnstats -
> >> it'll be interesting to see what stats are logged when you're in busy
> >> air.
> >
> > Typical WG sessions have 50-200 people.  The technical plenary (Monday
> > evening) and the administrative plenary (Thursday evening) typically
> > have around 1,000.  That's mostly geeks with wifi in their phones plus
> > their laptops.  I'll try to get stats in WG sessions and both plenaries.
> >
> >> I have no idea about rtsold, sorry. :(
> >
> > I'm not sure the cause but the cure has something to do with this:
> >
> > A little RTFC on rtsold/if.c reveals that ND6_IFF_ACCEPT_RTADV is not
> > set in nd.ndi.flags which comes from the lines:
> >
> >   if (ioctl(s, SIOCGIFINFO_IN6, (caddr_t)&nd) < 0) {
> >   [...]
> >   }
> >   if (!(nd.ndi.flags & ND6_IFF_ACCEPT_RTADV)) {
> >
> > A man ifconfig reveals:
> >
> >      accept_rtadv
> >              Set a flag to enable accepting ICMPv6 Router
> >              Advertisement messages.  The sysctl(8) variable
> >              net.inet6.ip6.accept_rtadv controls whether this flag is
> >              set by default or not.
> >
> > So the workaround is to add net.inet6.ip6.accept_rtadv=1 to
> > /etc/sysctl.conf.  A one time test using "ifconfig wlan0 inet6
> > accept_rtadv" and restarting rtsold also confirms this is the
> > problem.
> >
> > The mystery is really why this doesn't affect em0 and run0 on the same
> > machine.  I'll have to check and make sure they don't all behave the
> > same with the same kernel.  None of these driveres have the string
> > rtadv.  In sys/dev "grep -il rtadv */*.[hc]" yields nothing.  The
> > string ND6_IFF_ACCEPT_RTADV only appears in sys files in the netinet6
> > directory.  Reading the code, iwn seems to do what is right with
> > net.inet6.ip6.accept_rtadv clear and the others (em0, run0, plus msk0
> > on another machine, em0 on other machines) have ND6_IFF_ACCEPT_RTADV
> > set even though net.inet6.ip6.accept_rtadv is not set.
> >
> > The entire src/sys tree is from head but the rest of src is stable/10.
> >
> >> -a
> >
> > I'll try to get the stats next week but it looks like I'll need to
> > build the src distribution from head to get that done, pulling just
> > iwnstats from head.  Merging tools/tools/iwn/iwnstats into the
> > stable/10 tree didn't compile.  Not a big deal but pressed for time
> > between now and then.
> >
> > Curtis
> >
> >
> >> On 1 March 2014 09:11, Curtis Villamizar <cur...@ipv6.occnc.com> wrote:
> >> >
> >> > rtsol is not working for my kernel build with iwn but everything else
> >> > works.
> >> >
> >> > I'm running a very recent stable/10 (kernel is 262621) upgraded to
> >> > pick up iwn stuff from head:
> >> >
> >> >   svn merge \
> >> >     https://svn0.us-east.freebsd.org/base/head/sys/dev/iwn \
> >> >     dev/iwn
> >> >   svn merge \
> >> >     https://svn0.us-east.freebsd.org/base/head/sys/modules/iwnfw \
> >> >     modules/iwnfw
> >> >   svn merge
> >> >     https://svn0.us-east.freebsd.org/base/head/sys/contrib/dev/iwn \
> >> >     contrib/dev/iwn
> >> >
> >> > That was to get the Centrino 2000 support from the head branch.
> >> >
> >> > That works.
> >> >
> >> >   iwn0: <Intel(R) Centrino(R) Wireless-N 2200 BGN>
> >> >      mem 0xf1c00000-0xf1c01fff irq 17 at device 0.0 on pci3
> >> >
> >> > Everything works as far as I can tell except rtsol.
> >> >
> >> >   # rtsold -f -d -D wlan0
> >> >   checking if wlan0 is ready...
> >> >   wlan0 does not accept Router Advertisement.
> >> >   set timer for wlan0 to 1s
> >> >   New timer is 1s
> >> >   timer expiration on wlan0, state = 3
> >> >   checking if wlan0 is ready...
> >> >   wlan0 does not accept Router Advertisement.
> >> >   set timer for wlan0 to 1s
> >> >   New timer is 1s
> >> >   timer expiration on wlan0, state = 3
> >> >   checking if wlan0 is ready...
> >> >   wlan0 does not accept Router Advertisement.
> >> >   set timer for wlan0 to 1s
> >> >   New timer is 1s
> >> >   [ ... etc ... ]
> >> >
> >> > If I use rtsold -a it sees wlan0 as not ready and doesn't try to use
> >> > it but then it receives occasional RA anyway but ignores them because
> >> > it sees wlan0 as not ready.
> >> >
> >> > If I ifconfig inet6 ... alias I get an IPv6 address configured and
> >> > manually add a default route, then everything is fine.  This
> >> > workaround is OK for home but is not practical for roaming about (like
> >> > going to IETF) if I want IPv6 to work.
> >> >
> >> > Does anyone know why rtsold isn't seeing wlan0 as ready?  Is there any
> >> > info I could provide?  How likely is it that will a kernel built from
> >> > head this would just go away and rtsold would just work.
> >> >
> >> > btw- headed for IETF so I'll have a chance to test iwn in a very busy
> >> > environment and would be willing to help if anyone wants to do that
> >> > sort of debugging.  [I have a usb wlan (run0) as a fallback]
> >> >
> >> > Curtis
_______________________________________________
freebsd-wireless@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-wireless
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to