SCIENTIFIC-LINUX-USERS Archives

March 2013

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Steven Haigh <[log in to unmask]>
Reply To:
Steven Haigh <[log in to unmask]>
Date:
Wed, 13 Mar 2013 19:27:48 +1100
Content-Type:
text/plain
Parts/Attachments:
text/plain (130 lines)
On 03/13/2013 10:40 AM, William of BHE wrote:
> Is your machine dropping the connection, or is your router's wireless
> crashing? From the log section you posted, it looks like your AP's radio
> is going offline.
>
> Ath9K wireless cards are known to cause problems when combined with
> certain linux-based routers --such as the Buffalo WHR* dd-wrt based
> routers-- also running Atheros chipsets.
>
> I ran into this problem about a year ago. It was real fun tracking the
> problem down as it was caused by a laptop I only use when my workstation
> is unavailable. I got snowed with work while rebuilding my workstation
> and switched to my laptop exclusively for several months; magically, the
> previously stable Buffalo WHR-HP-G300N router (with an Atheros chip)
> running DD-WRT began randomly dropping all wireless connections and
> required a power-cycle to turn the radio back on.
>
> Since nothing had changed from my perspective --I had used the laptop on
> the network before, but not as extensively-- it took some effort to
> pinpoint the problem. Replacing the laptop's ath9k wireless card with an
> inexpensive Intel, and throwing out most of my USB Wireless-N adapters
> (many are Atheros based) fixed the issue.
>
> I've only heard of the issue when the client machine is running MS Win
> 7x64 with the 'right' version of updated drivers combined an Atheros
> based router with the 'right' set of DDWRT firmware, and large file
> transfers by the client over the local wireless network. If you haven't
> updated the driver in your Windows 7 box to the problem driver version,
> and/or aren't transferring large files (DVD ISO's, etc) the router won't
> display the problem behavior.  I suppose the true moral of the story is:
> don't buy Qualcomm chips, and when possible replace devices that use them?
>
> Here's one of the links that helped me:
> http://kinglee.blogspot.com/2010/07/buffalo-whr-hp-g300n-wireless-drop-on.html
>
>
> Moving away from whatever firmware you're running on your router might
> fix the issue. I replaced my laptop's wireless nic with an intel, and
> tossed my Atheros based USB wireless adapters and am very happy. Best of
> all, the Intel wireless NIC has pretty good bluetooth built in.
>
> Can you send us sterilized sections of your router logs?

Ok, so I'm having a bit of a play... I installed the latest version of 
OpenWRT on the WRT54GS. It seems to have newer wireless tools etc - 
which is good.

On the AP, now I can also run 'iw event -t' to get a list of over the 
air events. This is a good thing.

So, I fire up the eeepc, then connect to wifi. I see:

PC: 1363162479.614010: wlan0 (phy #0): scan started
PC: 1363162480.658977: wlan0 (phy #0): scan finished: 2412 2417 2422 
2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, "www.crc.id.au" ""
PC: 1363162480.666425: wlan0: unknown event 19
PC: 1363162480.670090: wlan0 (phy #0): auth 00:0f:66:c5:2d:6b -> 
1c:4b:d6:98:14:48 status: 0: Successful
PC: 1363162480.681813: wlan0 (phy #0): assoc 00:0f:66:c5:2d:6b -> 
1c:4b:d6:98:14:48 status: 0: Successful
PC: 1363162480.681934: wlan0 (phy #0): connected to 00:0f:66:c5:2d:6b
PC: 1363162480.690984: phy #0: regulatory domain change: set to AU by a 
country IE request on phy0

AP: 1363162480.664628: wlan0: new station 1c:4b:d6:98:14:48

The connection is then up and running, everything is fine.

I see the occasional scan on the client to see what access points are 
available, but nothing out of the norm. When the scan happens, I see:

PC: 1363162775.007042: wlan0 (phy #0): scan started
PC: 1363162778.401944: wlan0 (phy #0): scan finished: 2412 2417 2422 
2427 2432 2437 2442 2447 2452 2457 2462 2467 2472, "www.crc.id.au" ""
PC: 1363162778.408917: wlan0 (phy #0): unknown event 64

AP: 1363162778.387831: wlan0 (phy #0): mgmt TX status (cookie 81aaf3a0): 
acked

Now I just started a ping flood to the default route to get some data 
transferring over the wifi connection... Then the drop happens:

PC: 1363163093.220730: wlan0: unknown event 20
PC: 1363163093.226083: wlan0 (phy #0): deauth 1c:4b:d6:98:14:48 -> 
00:0f:66:c5:2d:6b reason 3: Deauthenticated because sending station is 
leaving (or has left) the IBSS or ESS
PC: 1363163093.226269: wlan0 (phy #0): disconnected (local request)
PC: 1363163093.245360: phy #0: regulatory domain change: set to world 
roaming by the wireless core upon initialization request
PC: 1363163093.267507: regulatory domain change: set to AU by a user request
PC: 1363163096.118844: wlan0 (phy #0): scan started
PC: 1363163097.158025: wlan0 (phy #0): scan finished: 2412 2417 2422 
2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484, "www.crc.id.au" ""
PC: 1363163097.166270: wlan0: unknown event 19
PC: 1363163097.171232: wlan0 (phy #0): auth 00:0f:66:c5:2d:6b -> 
1c:4b:d6:98:14:48 status: 0: Successful
PC: 1363163097.178622: wlan0 (phy #0): assoc 00:0f:66:c5:2d:6b -> 
1c:4b:d6:98:14:48 status: 0: Successful
PC: 1363163097.178809: wlan0 (phy #0): connected to 00:0f:66:c5:2d:6b
PC: 1363163097.183989: phy #0: regulatory domain change: set to AU by a 
country IE request on phy0

AP: 1363163093.232867: wlan0: del station 1c:4b:d6:98:14:48
AP: 1363163096.218316: wlan0 (phy #0): mgmt TX status (cookie 80de90e0): 
acked
AP: 1363163096.285290: wlan0 (phy #0): mgmt TX status (cookie 80dff440): 
no ack
AP: 1363163096.342560: wlan0 (phy #0): mgmt TX status (cookie 80dff440): 
no ack
AP: 1363163097.172129: wlan0 (phy #0): mgmt TX status (cookie 80dcef00): 
acked
AP: 1363163097.179453: wlan0 (phy #0): mgmt TX status (cookie 80dcef00): 
acked
AP: 1363163097.222866: wlan0: new station 1c:4b:d6:98:14:48

So, as far as the access point goes, it seems the client disassociates 
itself, then associates again.

The PC seems think that the access point has gone away, and disconnects.

Strange.

-- 
Steven Haigh

Email: [log in to unmask]
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

ATOM RSS1 RSS2