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 <cur...@ipv6.occnc.com> wrote:
>
> In message 
> <CAJ-VmomxwgsC8XBUw=g=C9Pb2C80=ZX-GE0u0xD=syst65f...@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 <cur...@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-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