Date: Tue, 11 Mar 2014 10:54:46 -0700 From: Adrian Chadd <adrian@freebsd.org> To: curtis@ipv6.occnc.com, "freebsd-wireless@freebsd.org" <freebsd-wireless@freebsd.org> Subject: Re: iwn rtsol on stable/10 with merge from head Message-ID: <CAJ-VmomONU3E=jnsZu5ot8S5Fi=Fo2=OyiKq=9qnws-nS_%2BXJQ@mail.gmail.com> In-Reply-To: <201403111653.s2BGrN13026531@maildrop2.v6ds.occnc.com> References: <CAJ-VmomxwgsC8XBUw=g=C9Pb2C80=ZX-GE0u0xD=sYST65FGkA@mail.gmail.com> <201403111653.s2BGrN13026531@maildrop2.v6ds.occnc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hm. If the noise values start fluctuating wildly before it starts missing beacons, this could tell me that the receiver is getting confused. I should finish the "retune by doing a single channel scan" hack that iwlwifi does; maybe it'll help quieten things down a bit. Thanks, -a On 11 March 2014 09:53, Curtis Villamizar <curtis@ipv6.occnc.com> wrote: > > In message <CAJ-VmomxwgsC8XBUw=g=C9Pb2C80=ZX-GE0u0xD=sYST65FGkA@mail.gmail.com> > Adrian Chadd writes: > >> Hi! >> >> Thanks, >> >> Is it switching APs in the same BSS (ie, same SSID, different AP) or >> different BSS (different SSID) ? >> >> -a > > > I didn't check but it should be same SSID since my wpa_supplicant.conf > prefered the "ietf" SSID in part of the week and the "ietf-v6ONLY" > SSID later in the week. There were plenty of APs with the "ietf" SSID > and "ietf-v6ONLY" SSID. If jumping to a new AP it might have been due > to congestion, not signal strength. > > I also found that when using the "ietf-v6ONLY" SSID that no DNS server > or default route were provided in the IPv6 RA but the M bit was set. > IPv6 only would only work if the client saw the M bit and ran DHCPv6 > (or edited /etc/resolv.conf and added a default route by hand). > > Note that in http://www.occnc.com/iwn/iwn.scan.0306-13:59.plenary > there is a jump from bssid 00:17:df:aa:57:51 to status: no carrier > (despite many viable APs) at 13:54:53 then at 13:55:03 associated with > bssid 00:17:df:a9:c5:e1 . The scan entries are: > > ietf 00:17:df:aa:57:51 6 54M -76:-95 102 ES HTCAP WME > ietf 00:17:df:a9:c5:e1 1 54M -79:-95 102 ES HTCAP WME > > Both channel 1 and channel 6 are very crowded with 16 APs (2 with ietf > SSID) and 12 APs (1 with ietf SSID). There may be a hint in > http://www.occnc.com/iwn/iwnstats.0306-13:59.plenary as to why the > change in SSID but without timestamps it may be hard (for me) to find. > A hint might be that missed+beacons=0 up to a point where it starts > rising, then goes to zero, then rises and goes to zero a few times. > At the first transition to non-zero, there is also a big jump in > moise. Not much else I see in there. > > Perhaps useful things to add to the iwnstats would be timestamp, > channel, ssid, bssid and record a reason for most recent AP change. > Maybe the place to look for this is in the wpa_supplicant debug output > which I did not collect. btw- wpa_supplicant -f file doesn't work. > > On some related topics: > > Is there any detectable change that devd might notice associated > to/from no-carrier transitions or on switch to another AP? If so that > would help a lot in that we could put dhclient and rtsold entries in > devd.conf in case the AP changed and the subnet, dns, and default > route also chnage with the new AP. If not a hook in wpa_supplicant > would be needed to handle this. > > It would also help if rtsold had a hook that could be used to run > dhclient -6 when the M bit was set in the RA (and dhclient -6 -x > when/if M gets cleared, though it might kill both the -4 and -6 > instances or the wrong one). > > Curtis > > >> On 6 March 2014 06:10, Curtis Villamizar <curtis@ipv6.occnc.com> wrote: >> > >> > 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-uhQremhAMGTFYtg@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 <curtis@ipv6.occnc.com> wrote: >> >> > >> >> > In message <CAJ-VmokW4qXOP__JKOhC68AGvc1fxk6ihhUqGHFCj67NPsj80Q@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 <curtis@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomONU3E=jnsZu5ot8S5Fi=Fo2=OyiKq=9qnws-nS_%2BXJQ>