Date: Fri, 2 May 2008 13:15:23 +0200 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: Sam Leffler <sam@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: Connection problems with wme enabled Message-ID: <20080502131523.58eec71a@fabiankeil.de> In-Reply-To: <481A2748.7080801@freebsd.org> References: <6b8e8f4f0804291900v521cde5cw1ad4eaba70244e9c@mail.gmail.com> <4817E52F.5070806@freebsd.org> <20080430121014.209beb00@fabiankeil.de> <48189577.4080109@freebsd.org> <48189871.2060005@freebsd.org> <20080501163943.4e8d102e@fabiankeil.de> <4819E367.3060306@freebsd.org> <20080501201135.4ff07fb4@fabiankeil.de> <481A2748.7080801@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/xEhFUVK0u.PKH3cx9JZ60LK
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Sam Leffler <sam@freebsd.org> wrote:
> Fabian Keil wrote:
> > Sam Leffler <sam@freebsd.org> wrote:
=20
> >> Fabian Keil wrote:
> >> =20
> >>> Sam Leffler <sam@freebsd.org> wrote:
> >> wlanstats 1 gives you a rolling display every second; that's usually=20
> >> more helpful in understanding what's happening. Unfortunately there a=
re=20
> >> more stats than can fit on a rolling display so sometimes the one(s) y=
ou=20
> >> want aren't shown. There is a column fmt mechanism a la ps to control=
=20
> >> output but it's not well developed (someone please take and improve). =
=20
> >> Also some stats are maintained by drivers and not yet counted in the=20
> >> net80211 layer (again, folks are welcome to help).
> >> =20
> >
> > While working:
> >
> > fk@TP51 ~ $wlanstats 1
> > input 2short rx_ucast bvers wrbss rxdup mecho wrdir
> > 14 0 14 0 1 29861 54 0
> > 19 0 19 0 0 0 0 0
> > 7 0 7 0 0 0 0 0
> > 15 0 15 0 0 0 0 0
> > 14 0 14 0 0 0 0 0
> > 4 0 4 0 0 0 0 0
> > 1 0 1 0 0 0 0 0
> > ^C
> >
> > While "hanging" ...
> >
> > fk@TP51 ~ $wlanstats 1
> > input 2short rx_ucast bvers wrbss rxdup mecho wrdir
> > 882 0 831 0 1 29859 50 0
> > 1 0 0 0 0 0 0 0
> > 0 0 0 0 0 0 0 0
> > 1 0 0 0 0 0 0 0
> > 0 0 0 0 0 0 0 0
> > 0 0 0 0 0 0 0 0
> > ^C
> Your code is out of date, I just imported some fixes yesterday :)
Indeed.
While "hanging":
fk@TP51 ~ $wlanstats 1
input mgmt output rxkid ascan bgscn bmiss rssi noise rate
113 591 207 0 10 0 3 42 0 54M
0 0 2 0 0 0 0 42 0 54M
0 0 1 0 0 0 0 42 0 54M
0 0 2 0 0 0 0 42 0 54M
0 0 2 0 0 0 0 42 0 54M
0 1 1 0 0 0 0 42 0 54M
0 0 1 0 0 0 0 42 0 54M
0 0 2 0 0 0 0 42 0 54M
0 0 1 0 0 0 0 42 0 54M
0 0 2 0 0 0 0 42 0 54M
1 1 3 0 0 0 0 43 0 54M
0 0 1 0 0 0 0 43 0 54M
0 0 2 0 0 0 0 43 0 54M
0 0 2 0 0 0 0 43 0 54M
0 0 2 0 0 0 0 43 0 54M
0 1 3 0 0 0 0 42 0 54M
0 0 1 0 0 0 0 42 0 54M
0 0 2 0 0 0 0 42 0 54M
^C
While working with wme enabled:
7 0 7 0 0 0 0 42 0 2M
4 0 4 0 0 0 0 42 0 11M
10 0 6 0 0 0 0 42 0 11M
5 0 4 0 0 0 0 43 0 12M
5 1 3 0 0 0 0 43 0 12M
3 0 4 0 0 0 0 43 0 18M
3 0 3 0 0 0 0 43 0 18M
4 0 3 0 0 0 0 43 0 18M
3 0 2 0 0 0 0 43 0 18M
3 1 4 0 0 0 0 43 0 24M
input mgmt output rxkid ascan bgscn bmiss rssi noise rate
80 756 67 0 17 0 3 43 0 36M
3 0 3 0 0 0 0 43 0 36M
4 0 4 0 0 0 0 43 0 48M
2 0 2 0 0 0 0 43 0 48M
3 1 5 0 0 0 0 43 0 48M
2 0 4 0 0 0 0 43 0 48M
1 0 4 0 0 0 0 43 0 54M
2 0 3 0 0 0 0 43 0 54M
3 0 5 0 0 0 0 43 0 54M
4 1 6 0 0 0 0 43 0 54M
2 0 4 0 0 0 0 43 0 54M
3 0 4 0 0 0 0 43 0 54M
2 0 4 0 0 0 0 43 0 54M
1 0 2 0 0 0 0 43 0 54M
^C
While working with wme disabled:
fk@TP51 ~ $wlanstats 1
input mgmt output rxkid ascan bgscn bmiss rssi noise rate
21 633 19 0 12 0 3 41 0 5M
4 0 3 0 0 0 0 41 0 5M
4 0 3 0 0 0 0 41 0 5M
2 1 2 0 0 0 0 42 0 5M
5 0 5 0 0 0 0 42 0 11M
4 0 7 0 0 0 0 42 0 11M
7 0 4 0 0 0 0 42 0 12M
7 0 7 0 0 0 0 42 0 12M
8 1 5 0 0 0 0 42 0 18M
7 0 5 0 0 0 0 42 0 18M
2 0 2 0 0 0 0 42 0 24M
4 0 3 0 0 0 0 42 0 24M
2 0 2 0 0 0 0 43 0 18M
3 1 3 0 0 0 0 42 0 18M
3 0 2 0 0 0 0 42 0 18M
2 0 2 0 0 0 0 42 0 18M
4 0 3 0 0 0 0 42 0 18M
2 0 2 0 0 0 0 42 0 18M
3 1 3 0 0 0 0 42 0 18M
7 0 6 0 0 0 0 42 0 18M
^C
> >>> It's interesting that with wme enabled the hangs
> >>> usually occur with the transmit rate at 54, while
> >>> it's usually a lot lower with wme disabled and the
> >>> device working.
> >>> =20
> >
> > =20
> >> iwi does tx rate control in the firmware so unlikely to be related. T=
he=20
> >> more likely issue is the beacon miss handling. The driver should=20
> >> recover and reconnect but it sounds like something didn't work. As a=
=20
> >> workaround you can try upping the bmiss count to see if this is a=20
> >> problem w/ the radio going deaf for a period of time--something I've=20
> >> seen on older Intel parts.
> >> =20
> >
> > Increasing bmiss to 250 (or decreasing it to 10)
> > doesn't seem to affect the problem.
> > =20
>=20
> Well if your beacon interval is 100 TU then the default setting of 24=20
> means you didn't see a beacon frame in 2400 TU (~2.4 seconds) which is a=
=20
> really long time even if the channel is way busy. The firmware handles=20
> this notification so it could be a firmware issue; if I were=20
> investigating I'd sniff packets to see.
>=20
> I've tested bmiss handling before (yesterday even) and it worked for me=20
> w/ and w/o wme enabled so not sure what to say. What I have noticed is=20
> the firmware some times delivers a slew of beacon miss notifications=20
> immediately after associating to an ap. I have some ideas why this=20
> might occur but Intel wouldn't answer when asked. However if you're=20
> seeing bmiss after lots of traffic has passed then it's unclear what's=20
> happening.
>=20
> I tested mostly with a 2915 card fwiw.
> >> See above. I ran tests yesterday w/ wme enabled in my environment but=
=20
> >> the signal was stronger so not an equivalent test. What you need to d=
o=20
> >> is get a log that captures the event of losing connectivity. This mus=
t=20
> >> include net80211 logging and probably needs to include some level of=20
> >> driver debugging as the problem is in the driver. Try:
> >>
> >> wlandebug state+scan+auth+assoc
> >> =20
> >
> > fk@TP51 ~ $sudo wlandebug state+scan+auth+assoc
> > wlandebug: sysctl-get(net.wlan.0.debug): No such file or directory
> >
> > fk@TP51 ~ $sysctl net.wlan =20
> > net.wlan.addba_maxtries: 3
> > net.wlan.addba_backoff: 10000
> > net.wlan.addba_timeout: 250
> > net.wlan.cac_timeout: 60
> > net.wlan.nol_timeout: 1800
> > net.wlan.recv_bar: 1
> > net.wlan.0.%parent: iwi0
> > net.wlan.0.driver_caps: 92307968
> > net.wlan.0.bmiss_max: 200 (increased by me, without noticeable effect)
> > net.wlan.0.inact_run: 300
> > net.wlan.0.inact_probe: 30
> > net.wlan.0.inact_auth: 180
> > net.wlan.0.inact_init: 30
> >
> > =20
> >> sysctl debug.iwi=3D5
> >> =20
> >
> > I'm not sure how useful it is without net80211 logging,
> > but I uploaded 160K of iwi0 messages at:
> >
> > http://www.fabiankeil.de/tmp/freebsd/iwi0-messages.txt
> Looks like I failed to include IEEE80211_DEBUG in the default kernel=20
> configs; you'll need that to get wlan debug msgs. I'll try to look at=20
> your log later.
I uploaded a log with IEEE80211_DEBUG enabled at:
http://www.fabiankeil.de/tmp/freebsd/wlan0+iwi0-messages.txt
Fabian
--Sig_/xEhFUVK0u.PKH3cx9JZ60LK
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEARECAAYFAkga98sACgkQBYqIVf93VJ27/gCdGx9+6CSD6Q5klBEHLoPez0Bb
LAoAoIHIaJ2F+ehJMOoAhEqc1ZWxGWXA
=0R0X
-----END PGP SIGNATURE-----
--Sig_/xEhFUVK0u.PKH3cx9JZ60LK--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080502131523.58eec71a>