Date: Sun, 07 Sep 2014 10:16:06 -0700 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Adrian Chadd <adrian@freebsd.org> Cc: "freebsd-wireless@freebsd.org" <freebsd-wireless@freebsd.org> Subject: Re: Issues with urtwn Message-ID: <540C92D6.4030106@freebsd.org> In-Reply-To: <CAJ-VmokyPcS077wHiP4Mdetms=meqk47v29fKA1edidhorVQpg@mail.gmail.com> References: <540C751F.6050202@freebsd.org> <CAJ-VmokyPcS077wHiP4Mdetms=meqk47v29fKA1edidhorVQpg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/07/14 08:28, Adrian Chadd wrote: > On 7 September 2014 08:09, Nathan Whitehorn <nwhitehorn@freebsd.org> wrote: >> I've been having some issues with connection stability in urtwn for several >> months. The usual symptom is that after some period of time the connection >> will apparently stall. If I'm running ping continuously, for instance, it >> will at some point stop receiving replies. Then, sometime later, immediately >> if I use the "reassociate" command in wpa_cli, the connection will fix >> itself and all the packets I didn't get earlier get delivered at once: >> hundreds of ping replies, for instance, some with time stamps minutes in the >> past. No data is actually lost, though. >> >> I think the issue is that the driver does not actually support powersave >> mode (maybe it should?) but reports to the AP that it does: >> >>> ifconfig wlan0 list sta (this is on the AP) >> ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG >> 80:1f:02:cc:47:a9 1 11 11M 8.5 0 5526 55712 EPS AE RSN >> >> I don't know enough about wireless to fix this, but the AP waiting for a >> powersave poll and never getting one seems consistent with the problem. Is >> there a simple way just to disable advertising this? > When it next stalls, check ifconfig wlan0 and ifconfig urtwn0 - see if > OACTIVE is set. > > I know iwn and ath had problems in the past where OACTIVE handling was > plain broken (wasn't behind locks) and in an SMP, preemptive world > things got gunked up. > OACTIVE is not set when it stalls. It also appears that only the RX path is stalled: transmitted packets make it, at least some of the time, to their destination when this happens. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?540C92D6.4030106>