[ath9k-devel] No probe response from AP after 500ms, disconnecting.

[Cedric Sodhi <manday@gmx.net>]

Thank you for your replies. I did not reply to this thread so far
because the issue appears to have vanished. Which, by itsself, is
nothing interesting as it kept emerging sporadically and I could
sometimes go months without it. And since I do not recall having changed
anything I assume that this is the case right here.

So I'll get back to you either when it comes up again or I can concluded
that it is gone for good.

Thanks.

On Sat, May 28, 2011 at 07:00:02PM +0530, Mohammed Shafi wrote:
> On Fri, May 27, 2011 at 9:36 PM, Maciej Mrozowski <reavertm@gmail.com> wrote:
> > On Wednesday 25 of May 2011 08:58:53 Cedric Sodhi wrote:
> >> Dear list,
> >>
> >> I use a Atheros HTC USB Wireless Device TL-WN721N with 9271. This is
> >> basically a very new devices which received a lot of positive reviews.
> >> And linux people keep insisting that Atheros are one of the better Wifi
> >> choices to make on linux. But I'm not getting anywhere this device!
> >
> > While it may be apples vs oranges comparison but I have identical - "No probe
> > response" with my TL-WN821N V3 (AR9287+AR7010) USB device using recent
> > wireless testing (at 1e4541b73b33f9918255f36a60bdeacfae4fdb9d + htc_7010.fw
> > 1.3 firmware).
> >
> 
> I did try to recreate the issue but nothing helped. may be I can
> increase the range or test it under more noisy environment
> 
> 
> > On disconnect - no attempt to recover (my net.wlan script needs to be
> > restarted manually, maybe I jsut takes some time?) :
> > wlan0: detected beacon loss from AP - sending probe request
> > ieee80211 phy0: wlan0: No probe response from AP 68:7f:74:77:36:bc after
> > 500ms, try 1/5
> > ieee80211 phy0: wlan0: No probe response from AP 68:7f:74:77:36:bc after
> > 500ms, try 2/5
> > ieee80211 phy0: wlan0: No probe response from AP 68:7f:74:77:36:bc after
> > 500ms, try 3/5
> > ieee80211 phy0: wlan0: No probe response from AP 68:7f:74:77:36:bc after
> > 500ms, try 4/5
> > ieee80211 phy0: wlan0: No probe response from AP 68:7f:74:77:36:bc after
> > 500ms, disconnecting.
> > Tx BA session stop requested for 68:7f:74:77:36:bc tid 0
> > Rx BA session stop requested for 68:7f:74:77:36:bc tid 0
> > Rx BA session stop requested for 68:7f:74:77:36:bc tid 7
> > Tx BA session stop requested for 68:7f:74:77:36:bc tid 0
> > ieee80211 phy0: Removed STA 68:7f:74:77:36:bc
> > ieee80211 phy0: Destroyed STA 68:7f:74:77:36:bc
> > ieee80211 phy0: device now idle
> > Stopping Tx BA session for 68:7f:74:77:36:bc tid 0
> > Could not find station: 68:7f:74:77:36:bc
> > Stopping Tx BA session for 68:7f:74:77:36:bc tid 0
> > Could not find station: 68:7f:74:77:36:bc
> > cfg80211: All devices are disconnected, going to restore regulatory settings
> > cfg80211: Restoring regulatory settings
> > cfg80211: Adding request for country PL back into the queue
> > cfg80211: Kicking the queue
> > cfg80211: Calling CRDA for country: CN
> > ieee80211 phy0: device no longer idle - scanning
> > ieee80211 phy0: device now idle
> >
> > I do have a couple of related debug features in kernel (debugfs for mac80211
> > and ath9k_htc included) - what info exactly would you like me to provide? Or
> > maybe some test scenario?
> 
> anything... when the disconnection happen the prior mesgs will be useful
> 
> >
> > Also some other strange issue I observed with ath9k_htc (just for record, I'll
> > report details them when I run on them again):
> > - occasionally it happens I need to change USB port in order to get driver re-
> > initialized (as it occasionally happens that device enters some locked state -
> > 'net.wlan stop' hangs waiting for it and it needs to be removed from USB port
> > to go further. Also after such operation sometimes this USB port appears to be
> > useless and even rmmod && modprobe (also on mac80211 and cfg80211 just in any
> > case) + reinserting USB stick doesn't help (error loading firmware), but
> > plugging to a different USB port works.
> >
> > A bit earlier (before a set of driver and firmware patches was applied by
> > Sujith last week) driver was "broken" to the point that it was actually
> > causing my WiFi router Cisco LinkSys WRT120N to freeze completely (router cold
> > reset was required in order to restore router operability) - this one is fixed
> > so don't bother - just for reference.
> >
> > --
> > regards
> > MM
> >
> > _______________________________________________
> > ath9k-devel mailing list
> > ath9k-devel at lists.ath9k.org
> > https://lists.ath9k.org/mailman/listinfo/ath9k-devel
> >
> >
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel