* [RFC PATCH 0/17] zd1211rw: add support for AP mode
From: Jussi Kivilinna @ 2011-01-04 23:47 UTC (permalink / raw)
To: linux-wireless; +Cc: Daniel Drake, Ulrich Kunitz
Hello!
This ended up being much bigger task I expected. Anyway AP mode is now
usable and zd1211rw should be less crashy now. I'm still sending this
as RFC as it touches and adds a lot of code.
-Jussi
^ permalink raw reply
* Re: [rt2x00-users] Linksys WUSB600N v1 disconnecting from AP
From: Wolfgang Kufner @ 2011-01-04 22:31 UTC (permalink / raw)
To: Aleksandar Milivojevic
Cc: Luis Correia, Luis R. Rodriguez, linux-wireless, users
In-Reply-To: <AANLkTikCcgEiqeJLDn0Pes_2=usj6ZXo7hhL48MBnH_-@mail.gmail.com>
Hi Aleksandar,
I know just about nothing about regulatory domains but I think it
might be good to try with a current compat-wireless next. I notice
that the these log lines:
"cfg80211: Received country IE:"
"cfg80211: We intersect both of these and get:"
do not exist in linux-next anymore since this commit:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=4f366c5dabcb936dd5754a35188bd699181fe1ce
Maybe a fix for this issue is already in compat-wireless.
HTH,
Wolfgang
^ permalink raw reply
* Re: [PATCH] mac80211: Push idle state to driver before stop
From: Paul Stewart @ 2011-01-04 22:29 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Johannes Berg, linux-wireless@vger.kernel.org, Luis Rodriguez
In-Reply-To: <AANLkTinvrdj4jbzH3COVZ9gW8W0h0em7uD6DBWBEXUp=@mail.gmail.com>
On Tue, Jan 4, 2011 at 10:19 AM, Paul Stewart <pstew@google.com> wrote:
> On Thu, Dec 16, 2010 at 9:44 AM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
>> Try this:
>
> Happy new year. I've tried this patch, and the system continues to
> suspend and resume successfully (i.e, the fix from the earlier patches
> continues to alleviate the original problem), however the system
> continues to be "deaf" to beacons at resume time if the system
> suspends and resumes while associated. You don't need a ChromeOS
> system to reproduce this issue. Just associate to the network and
> suspend/resume. On resume the system believes it should be
> associated, but then the beacon loss timer kicks in and we
> disassociate, since we are never successful in receiving a response.
Whoops. I didn't apply that change correctly. Actually, I think this
change works. I think I may have spotted a couple of unrelated
anomalies I'll trace down and address separately.
--
Paul
^ permalink raw reply
* Re: [rt2x00-users] Linksys WUSB600N v1 disconnecting from AP
From: Aleksandar Milivojevic @ 2011-01-04 21:53 UTC (permalink / raw)
To: Luis Correia; +Cc: Helmut Schaa, linux-wireless, Luis R. Rodriguez, users
In-Reply-To: <AANLkTikREOFV+WGWgo9yh9bTrz346kF0muKE8gs5N+km@mail.gmail.com>
Searching around a bit more, I found an article saying that regulatory
domain in theory could be set from any beacon packet the wireless card
sees (even before it actually connects to any particular wireless
network), not only from beacon packets from my WiFi network. If this
is true (I don't know much about this topic, and even less about
internal workings of regulatory domain support in linux kernel), could
it be possible that one of my neighbors has illegal or misconfigured
AP? This would be a very long shot, as it sounds a bit strange that
regulatory domain could be set based on third network (not the one I'm
connected to), and also I haven't experienced any problems with other
operating systems (such as Mac OS X).
Anyhow, I still find that line in log files about switching regulatory
domain from "US" to "98" (at which point a bunch of frequencies are
permanently dropped) to be rather odd.
On Tue, Jan 4, 2011 at 12:54 PM, Aleksandar Milivojevic
<alex@milivojevic.org> wrote:
> On Tue, Jan 4, 2011 at 11:32 AM, Aleksandar Milivojevic
> <alex@milivojevic.org> wrote:
>>
>> On Tue, Jan 4, 2011 at 11:01 AM, Luis Correia <buga@loide.net> wrote:
>>>
>>> Hi all,
>>>
>>> On Tue, Jan 4, 2011 at 18:46, Helmut Schaa <helmut.schaa@googlemail.com>
>>> wrote:
>>> > Hi Aleksandar,
>>> >
>>> > looks like a somewhat strange regulatory handling. However, I'm not
>>> > really
>>> > familiar with the regulatory stuff. Maybe Luis can give us some
>>> > info/ideas
>>> > regarding this ...
>>> >
>>> > Luis, mind to have a look at the regulatory messages below?
>>> >
>>>
>>> Yes, there is something fishy with it.
>>>
>>> this is what is allowed for Ireland
>>>
>>> country IE:
>>> (2402 - 2482 @ 40), (N/A, 20)
>>> (5170 - 5250 @ 40), (N/A, 20)
>>> (5250 - 5330 @ 40), (N/A, 20), DFS
>>> (5490 - 5710 @ 40), (N/A, 27), DFS
>>>
>>>
>>> Apparently IE Ireland does allow 5Ghz channels, and something is
>>> really strange is going on.
>>>
>>> Maybe if the Airport Extreme was changed to a new channel, it would
>>> improve.
>>>
>>> But I'm not totally sure.
>>>
>>> We might also be looking at an old regulatory daemon or database.
>>
>> The way I read the debug log file was that IE was an empty string (I would
>> expect to see "Received country IE: XX", not "Received country IE:". Also,
>> my regulatory domain is US, not Ireland. I double-checked settings in my
>> Airport Extreme router, and it is correctly set to US there. Looking into
>> the messages log file, it correctly shows country as US as well ("cfg80211:
>> Regulatory domain: US").
>
> Looking at the two log snippets from my original email, I noticed something
> odd.
> The /var/log/messages shows two entries saying "cfg80211: Regulatory domain:
> US", followed by the line saying "cfg80211: Regulatory domain: 98".
> Whatever '98' is and wherever it comes from!? Bottom line, once bunch of
> frequencies are dropped (due to switching to reg. domain '98'), they don't
> seem to be re-added once reg. domain is switched back to US later in the
> logs (I found references on the web saying that framework doesn't allow for
> relaxing of restrictions).
> Searching the web, I found quite a bit of references to similar problems,
> and few hints. Many of the pages I found show similar thing as the one
> found in my log snippets (first setting regulatory domain to correct
> country, then the line setting to "98"). I'll try running stuff like 'iw
> reg get" to see what it reports when I get home later in the evening, and
> also check if there are any config files for passing options (such as
> setting local regulatory domain) for cfg80211 module (and its friends) in
> /etc/modprobe.d directory.
> One minor data point. All the hardware I'm using was purchased new in the
> US in normal retail stores, and used only in US. If there's anything hard
> coded regarding the regulatory domains in the devices themselves (both my
> Apple wireless router and Linksys wireless card), I would expect it to be
> set to US as well. As I wrote previously, my wireless router allows me to
> set country where the device is used, and it is set to US. I'll
> double-check if there's anything in /etc/modprobe.d on the Linux side.
>>>
>>> Luis Correia
>>> > Am Dienstag, 4. Januar 2011 schrieb Aleksandar Milivojevic:
>>> >> I've searched around a bit and haven't found much information that
>>> >> looks
>>> >> like the problem I'm experiencing with rt2x00 drivers.
>>> >>
>>> >> The hardware I have is Linksys WUSB600N USB stick, v1 hardware
>>> >> revision,
>>> >> which should have RT2870 chipset. The kernel used is from a generic
>>> >> Ubuntu
>>> >> 10.10 distribution (uname shows "Linux toporko 2.6.35-24-generic
>>> >> #42-Ubuntu
>>> >> SMP Thu Dec 2 01:41:57 UTC 2010 i686 GNU/Linux"). The output of lsusb
>>> >> identifies device as:
>>> >>
>>> >> Bus 001 Device 003: ID 1737:0071 Linksys WUSB600N Dual-Band Wireless-N
>>> >> USB
>>> >> Network Adapter
>>> >>
>>> >> The problem I'm experiencing is that I'm able to connect to my AP (an
>>> >> Apple
>>> >> Airport Extreme operating at 5GHZ) shortly after boot. However,
>>> >> shortly
>>> >> after connection is made (usually within few minutes), the connection
>>> >> is
>>> >> dropped, and all subsequent attempts to re-connect to AP fail.
>>> >> Reloading
>>> >> the driver helps to reconnect, but connection is again dropped after
>>> >> few
>>> >> minutes. I also have another AP (an old Linksys WRT54G) operating on
>>> >> 2.4GHz, and it seems same issue is present if I attempt to connect to
>>> >> it
>>> >> (haven't experimented with this other setup much, as I'm much more
>>> >> interested in connecting to my WiFi-N network).
>>> >>
>>> >> The list of relevant loaded drivers on the system shows (looking for
>>> >> anything starting with 'rt' in the name):
>>> >> rt2800usb 8367 0
>>> >> rt2800lib 28897 1 rt2800usb
>>> >> rt2x00usb 9779 2 rt2800usb,rt2800lib
>>> >> rt2x00lib 27275 2 rt2800lib,rt2x00usb
>>> >> led_class 2633 1 rt2x00lib
>>> >> mac80211 231541 2 rt2x00usb,rt2x00lib
>>> >> cfg80211 144470 2 rt2x00lib,mac80211
>>> >>
>>> >> I have rt2870sta driver blacklisted to prevent it from conflicting
>>> >> with
>>> >> rt2x00 drivers.
>>> >>
>>> >> Looking at the log files, it seems /var/log/messages and
>>> >> /var/log/debug
>>> >> contain most interesting logs.
>>> >>
>>> >> I found following snippet in /var/log/messages:
>>> >>
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.143600]
>>> >> ADDRCONF(NETDEV_CHANGE):
>>> >> wlan0: link becomes ready
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.143712] cfg80211: Calling CRDA
>>> >> for
>>> >> country: US
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219910] cfg80211: Regulatory
>>> >> domain:
>>> >> US
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219914] (start_freq -
>>> >> end_freq @
>>> >> bandwidth), (max_antenna_gain, max_eirp)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219918] (5170000 KHz -
>>> >> 5250000
>>> >> KHz @ 40000 KHz), (10000 mBi, 3000 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219923] (5735000 KHz -
>>> >> 5835000
>>> >> KHz @ 40000 KHz), (10000 mBi, 3000 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219928] cfg80211: Regulatory
>>> >> domain:
>>> >> US
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219930] (start_freq -
>>> >> end_freq @
>>> >> bandwidth), (max_antenna_gain, max_eirp)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219935] (2402000 KHz -
>>> >> 2472000
>>> >> KHz @ 40000 KHz), (300 mBi, 2700 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219939] (5170000 KHz -
>>> >> 5250000
>>> >> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219943] (5250000 KHz -
>>> >> 5330000
>>> >> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219947] (5490000 KHz -
>>> >> 5600000
>>> >> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219951] (5650000 KHz -
>>> >> 5710000
>>> >> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219955] (5735000 KHz -
>>> >> 5835000
>>> >> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219960] cfg80211: Regulatory
>>> >> domain:
>>> >> 98
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219962] (start_freq -
>>> >> end_freq @
>>> >> bandwidth), (max_antenna_gain, max_eirp)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219966] (5170000 KHz -
>>> >> 5250000
>>> >> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219971] (5735000 KHz -
>>> >> 5835000
>>> >> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220189] cfg80211: Current
>>> >> regulatory
>>> >> domain updated by AP to: US
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220192] (start_freq -
>>> >> end_freq @
>>> >> bandwidth), (max_antenna_gain, max_eirp)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220196] (5170000 KHz -
>>> >> 5250000
>>> >> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220200] (5735000 KHz -
>>> >> 5835000
>>> >> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.409801] padlock: VIA PadLock
>>> >> not
>>> >> detected.
>>> >> Jan 3 10:40:20 toporko kernel: [ 112.656632] lo: Disabled Privacy
>>> >> Extensions
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.593983] cfg80211: Calling CRDA
>>> >> to
>>> >> update world regulatory domain
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.625264] cfg80211: World
>>> >> regulatory
>>> >> domain updated:
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.625272] (start_freq -
>>> >> end_freq @
>>> >> bandwidth), (max_antenna_gain, max_eirp)
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.625277] (2402000 KHz -
>>> >> 2472000
>>> >> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.625282] (2457000 KHz -
>>> >> 2482000
>>> >> KHz @ 20000 KHz), (300 mBi, 2000 mBm)
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.625286] (2474000 KHz -
>>> >> 2494000
>>> >> KHz @ 20000 KHz), (300 mBi, 2000 mBm)
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.625290] (5170000 KHz -
>>> >> 5250000
>>> >> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.625294] (5735000 KHz -
>>> >> 5835000
>>> >> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>> >>
>>> >>
>>> >> I also found similar snippet in /var/log/debug. Interestingly, unlike
>>> >> the
>>> >> one above that lists IE as US (which is correct for my location, and
>>> >> corresponds to the settings in my AP), in debug log file IE is
>>> >> strangely
>>> >> blank with bunch of lines about disabled frequencies:
>>> >>
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.114337] wlan0: authenticate
>>> >> with
>>> >> 00:1e:52:79:e9:ff (try 1)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.114955] wlan0: authenticated
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.118103] wlan0: associate with
>>> >> 00:1e:52:79:e9:ff (try 1)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.119214] wlan0: RX AssocResp
>>> >> from
>>> >> 00:1e:52:79:e9:ff (capab=0x511 status=0 aid=1)
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.119220] wlan0: associated
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219901] cfg80211: Received
>>> >> country
>>> >> IE:
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219925] cfg80211: CRDA thinks
>>> >> this
>>> >> should applied:
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219957] cfg80211: We intersect
>>> >> both
>>> >> of these and get:
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219977] cfg80211: Leaving
>>> >> channel
>>> >> 2412 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219981] cfg80211: Leaving
>>> >> channel
>>> >> 2417 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219985] cfg80211: Leaving
>>> >> channel
>>> >> 2422 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219988] cfg80211: Leaving
>>> >> channel
>>> >> 2427 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.219992] cfg80211: Leaving
>>> >> channel
>>> >> 2432 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220044] cfg80211: Leaving
>>> >> channel
>>> >> 2437 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220048] cfg80211: Leaving
>>> >> channel
>>> >> 2442 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220052] cfg80211: Leaving
>>> >> channel
>>> >> 2447 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220056] cfg80211: Leaving
>>> >> channel
>>> >> 2452 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220059] cfg80211: Leaving
>>> >> channel
>>> >> 2457 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220063] cfg80211: Leaving
>>> >> channel
>>> >> 2462 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220066] cfg80211: Leaving
>>> >> channel
>>> >> 2467 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220070] cfg80211: Leaving
>>> >> channel
>>> >> 2472 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220073] cfg80211: Leaving
>>> >> channel
>>> >> 2484 MHz intact on phy0 - no rule found in band on Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220078] cfg80211: Disabling
>>> >> channel
>>> >> 5260 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220081] cfg80211: Disabling
>>> >> channel
>>> >> 5270 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220084] cfg80211: Disabling
>>> >> channel
>>> >> 5280 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220087] cfg80211: Disabling
>>> >> channel
>>> >> 5300 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220091] cfg80211: Disabling
>>> >> channel
>>> >> 5310 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220094] cfg80211: Disabling
>>> >> channel
>>> >> 5320 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220097] cfg80211: Disabling
>>> >> channel
>>> >> 5500 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220100] cfg80211: Disabling
>>> >> channel
>>> >> 5510 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220103] cfg80211: Disabling
>>> >> channel
>>> >> 5520 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220106] cfg80211: Disabling
>>> >> channel
>>> >> 5540 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220109] cfg80211: Disabling
>>> >> channel
>>> >> 5550 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220113] cfg80211: Disabling
>>> >> channel
>>> >> 5560 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220116] cfg80211: Disabling
>>> >> channel
>>> >> 5580 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220119] cfg80211: Disabling
>>> >> channel
>>> >> 5590 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220122] cfg80211: Disabling
>>> >> channel
>>> >> 5600 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220125] cfg80211: Disabling
>>> >> channel
>>> >> 5620 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220128] cfg80211: Disabling
>>> >> channel
>>> >> 5630 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220131] cfg80211: Disabling
>>> >> channel
>>> >> 5640 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220135] cfg80211: Disabling
>>> >> channel
>>> >> 5660 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220138] cfg80211: Disabling
>>> >> channel
>>> >> 5670 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220141] cfg80211: Disabling
>>> >> channel
>>> >> 5680 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220144] cfg80211: Disabling
>>> >> channel
>>> >> 5700 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220148] cfg80211: Disabling
>>> >> channel
>>> >> 5835 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220151] cfg80211: Disabling
>>> >> channel
>>> >> 5845 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220154] cfg80211: Disabling
>>> >> channel
>>> >> 5855 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220157] cfg80211: Disabling
>>> >> channel
>>> >> 5865 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220160] cfg80211: Disabling
>>> >> channel
>>> >> 5920 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220163] cfg80211: Disabling
>>> >> channel
>>> >> 5940 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220167] cfg80211: Disabling
>>> >> channel
>>> >> 5960 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220170] cfg80211: Disabling
>>> >> channel
>>> >> 5980 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220173] cfg80211: Disabling
>>> >> channel
>>> >> 6040 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220176] cfg80211: Disabling
>>> >> channel
>>> >> 6060 MHz on phy0 due to Country IE
>>> >> Jan 3 10:39:38 toporko kernel: [ 70.220179] cfg80211: Disabling
>>> >> channel
>>> >> 6080 MHz on phy0 due to Country IE
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.564046] No probe response from
>>> >> AP
>>> >> 00:1e:52:79:e9:ff after 500ms, disconnecting.
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.593968] cfg80211: All devices
>>> >> are
>>> >> disconnected, going to restore regulatory settings
>>> >> Jan 3 10:41:31 toporko kernel: [ 183.593977] cfg80211: Restoring
>>> >> regulatory settings
>>> >> Jan 3 10:41:34 toporko kernel: [ 186.856369] wlan0: authenticate
>>> >> with
>>> >> 00:1e:52:79:e9:ff (try 1)
>>> >> Jan 3 10:41:34 toporko kernel: [ 187.056156] wlan0: authenticate
>>> >> with
>>> >> 00:1e:52:79:e9:ff (try 2)
>>> >> Jan 3 10:41:35 toporko kernel: [ 187.256419] wlan0: authenticate
>>> >> with
>>> >> 00:1e:52:79:e9:ff (try 3)
>>> >> Jan 3 10:41:35 toporko kernel: [ 187.456054] wlan0: authentication
>>> >> with
>>> >> 00:1e:52:79:e9:ff timed out
>>> >> Jan 3 10:41:47 toporko kernel: [ 200.054031] wlan0: direct probe to
>>> >> 00:1e:52:79:e9:ff (try 1)
>>> >> Jan 3 10:41:48 toporko kernel: [ 200.252050] wlan0: direct probe to
>>> >> 00:1e:52:79:e9:ff (try 2)
>>> >> Jan 3 10:41:48 toporko kernel: [ 200.452085] wlan0: direct probe to
>>> >> 00:1e:52:79:e9:ff (try 3)
>>> >
>>> > We received an empty country IE and as a result disabled serveral 11a
>>> > channels.
>>> > Maybe even the one we are currently associated to?
>>> >
>>> > Thanks,
>>> > Helmut
>>> >
>>> > _______________________________________________
>>> > users mailing list
>>> > users@rt2x00.serialmonkey.com
>>> >
>>> > http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
>>> >
>>>
>>> _______________________________________________
>>> users mailing list
>>> users@rt2x00.serialmonkey.com
>>>
>>> http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
>>
>
>
^ permalink raw reply
* Re: Breakage in rtlwifi/base.c for 2010-12-24
From: Larry Finger @ 2011-01-04 21:05 UTC (permalink / raw)
To: Philip Prindeville; +Cc: linux-wireless
In-Reply-To: <4D237C41.70607@redfish-solutions.com>
On 01/04/2011 02:00 PM, Philip Prindeville wrote:
> Anyone else seeing the following breakage? I'm building the 2010-12-24
> snapshot against 2.6.27.49:
>
> CC [M]
> /home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.o
>
> /home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.c:
> In function '_rtl_init_deferred_work':
> /home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.c:229:
> error: implicit declaration of function 'alloc_workqueue'
> /home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.c:229:
> warning: assignment makes pointer from integer without a cast
The call create_workqueue() is obsolete and is being replaced by
alloc_workqueue(). Unfortunately, older kernels do not have the newer call. A
patch for compat-wireless has been submitted, but I don't think the package has
rebuilt successfully since then. You have two options: (1) if you do not need a
driver for the RTL8192CE/RTL8187CE cards, then deselect them from the build, or
(2) Find the line in drivers/net/wireless/rtlwifi/base.c that says
rtlpriv->works.rtl_wq = alloc_workqueue(rtlpriv->cfg->name, 0, 0);
and replace it with
rtlpriv->works.rtl_wq = create_workqueue(rtlpriv->cfg->name);
Larry
^ permalink raw reply
* Breakage in rtlwifi/base.c for 2010-12-24
From: Philip Prindeville @ 2011-01-04 20:00 UTC (permalink / raw)
To: linux-wireless
Anyone else seeing the following breakage? I'm building the 2010-12-24 snapshot against 2.6.27.49:
CC [M] /home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.o
/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.c: In function '_rtl_init_deferred_work':
/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.c:229: error: implicit declaration of function 'alloc_workqueue'
/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.c:229: warning: assignment makes pointer from integer without a cast
make[5]: *** [/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi/base.o] Error 1
make[4]: *** [/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless/rtlwifi] Error 2
make[3]: *** [/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/drivers/net/wireless] Error 2
make[2]: *** [_module_/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24] Error 2
make[2]: Leaving directory `/home/philipp/astlinux/build_i586/linux-2.6.27.49-astlinux'
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24'
make: *** [/home/philipp/astlinux/build_i586/compat-wireless-2010-12-24/net/wireless/lib80211.ko] Error 2
^ permalink raw reply
* Compat-wireless release for 2011-01-04 is baked
From: Compat-wireless cronjob account @ 2011-01-04 20:04 UTC (permalink / raw)
To: linux-wireless
>From git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next
9b210cb..959f374 history -> origin/history
+ bfa221f...924c697 master -> origin/master (forced update)
3643e0e..03ed6a3 stable -> origin/stable
* [new tag] next-20110104 -> next-20110104
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
cat: compat_base_tree: No such file or directory
cat: compat_base_tree_version: No such file or directory
cat: compat_version: No such file or directory
cat: /var/opt/compat/compat-wireless-2.6/compat_version: No such file or directory
scripts/Makefile.clean:17: /var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile: No such file or directory
make[4]: *** No rule to make target `/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap/Makefile'. Stop.
make[3]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless/hostap] Error 2
make[2]: *** [/var/opt/compat/compat-wireless-2.6/drivers/net/wireless] Error 2
make[1]: *** [_clean_/var/opt/compat/compat-wireless-2.6] Error 2
make: *** [clean] Error 2
/usr/bin/sha1sum: *.tar.bz2: No such file or directory
compat-wireless code metrics
774934 - Total upstream lines of code being pulled
^ permalink raw reply
* Re: [PATCH v2 1/6] ath9k_htc: Fix warning on device removal
From: Sujith @ 2011-01-04 19:51 UTC (permalink / raw)
To: John W. Linville; +Cc: Sujith, linux-wireless@vger.kernel.org
In-Reply-To: <20110104194337.GB13239@tuxdriver.com>
John W. Linville wrote:
> On Tue, Dec 28, 2010 at 02:27:52PM +0530, Sujith wrote:
> > From: Sujith Manoharan <Sujith.Manoharan@atheros.com>
> >
> > The commit "ath9k_hw: warn if we cannot change the power to the chip"
> > introduced a new warning to indicate chip powerup failures, but this
> > is not required for devices that have been removed. Handle USB device
> > removal properly by checking for unplugged status.
> >
> > For PCI devices, this warning will still be seen when the card is pulled
> > out, not sure how to check for card removal.
> >
> > Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
>
> This doesn't seem to apply cleanly?
Sent a rebased version. Thanks.
Sujith
^ permalink raw reply
* [PATCH v2] ath9k_htc: Fix warning on device removal
From: Sujith @ 2011-01-04 19:50 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Sujith.Manoharan
From: Sujith Manoharan <Sujith.Manoharan@atheros.com>
The commit "ath9k_hw: warn if we cannot change the power to the chip"
introduced a new warning to indicate chip powerup failures, but this
is not required for devices that have been removed. Handle USB device
removal properly by checking for unplugged status.
For PCI devices, this warning will still be seen when the card is pulled
out, not sure how to check for card removal.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/eeprom.h | 2 --
drivers/net/wireless/ath/ath9k/hif_usb.c | 6 +++---
drivers/net/wireless/ath/ath9k/htc.h | 5 ++---
drivers/net/wireless/ath/ath9k/htc_drv_init.c | 5 +----
drivers/net/wireless/ath/ath9k/hw.c | 4 +++-
drivers/net/wireless/ath/ath9k/hw.h | 4 ++++
drivers/net/wireless/ath/ath9k/wmi.c | 2 +-
7 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/eeprom.h b/drivers/net/wireless/ath/ath9k/eeprom.h
index f6f09d1..58e2ddc 100644
--- a/drivers/net/wireless/ath/ath9k/eeprom.h
+++ b/drivers/net/wireless/ath/ath9k/eeprom.h
@@ -23,8 +23,6 @@
#include <net/cfg80211.h>
#include "ar9003_eeprom.h"
-#define AH_USE_EEPROM 0x1
-
#ifdef __BIG_ENDIAN
#define AR5416_EEPROM_MAGIC 0x5aa5
#else
diff --git a/drivers/net/wireless/ath/ath9k/hif_usb.c b/drivers/net/wireless/ath/ath9k/hif_usb.c
index 22b68b3..c20c8c8 100644
--- a/drivers/net/wireless/ath/ath9k/hif_usb.c
+++ b/drivers/net/wireless/ath/ath9k/hif_usb.c
@@ -993,16 +993,16 @@ static void ath9k_hif_usb_disconnect(struct usb_interface *interface)
{
struct usb_device *udev = interface_to_usbdev(interface);
struct hif_device_usb *hif_dev = usb_get_intfdata(interface);
+ bool unplugged = (udev->state == USB_STATE_NOTATTACHED) ? true : false;
if (hif_dev) {
- ath9k_htc_hw_deinit(hif_dev->htc_handle,
- (udev->state == USB_STATE_NOTATTACHED) ? true : false);
+ ath9k_htc_hw_deinit(hif_dev->htc_handle, unplugged);
ath9k_htc_hw_free(hif_dev->htc_handle);
ath9k_hif_usb_dev_deinit(hif_dev);
usb_set_intfdata(interface, NULL);
}
- if (hif_dev->flags & HIF_USB_START)
+ if (!unplugged && (hif_dev->flags & HIF_USB_START))
ath9k_hif_usb_reboot(udev);
kfree(hif_dev);
diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index fdf9d5f..e6c2f0a 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -339,9 +339,8 @@ void ath_htc_cancel_btcoex_work(struct ath9k_htc_priv *priv);
#define OP_ASSOCIATED BIT(7)
#define OP_ENABLE_BEACON BIT(8)
#define OP_LED_DEINIT BIT(9)
-#define OP_UNPLUGGED BIT(10)
-#define OP_BT_PRIORITY_DETECTED BIT(11)
-#define OP_BT_SCAN BIT(12)
+#define OP_BT_PRIORITY_DETECTED BIT(10)
+#define OP_BT_SCAN BIT(11)
struct ath9k_htc_priv {
struct device *dev;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_init.c b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
index 0f6be35..724f545 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_init.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_init.c
@@ -851,9 +851,6 @@ int ath9k_htc_probe_device(struct htc_target *htc_handle, struct device *dev,
if (ret)
goto err_init;
- /* The device may have been unplugged earlier. */
- priv->op_flags &= ~OP_UNPLUGGED;
-
ret = ath9k_init_device(priv, devid, product, drv_info);
if (ret)
goto err_init;
@@ -873,7 +870,7 @@ void ath9k_htc_disconnect_device(struct htc_target *htc_handle, bool hotunplug)
/* Check if the device has been yanked out. */
if (hotunplug)
- htc_handle->drv_priv->op_flags |= OP_UNPLUGGED;
+ htc_handle->drv_priv->ah->ah_flags |= AH_UNPLUGGED;
ath9k_deinit_device(htc_handle->drv_priv);
ath9k_deinit_wmi(htc_handle->drv_priv);
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 4b51ed4..fde9786 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -1615,7 +1615,9 @@ bool ath9k_hw_setpower(struct ath_hw *ah, enum ath9k_power_mode mode)
* simply keep the ATH_DBG_WARN_ON_ONCE() but make
* ath9k_hw_setpower() return type void.
*/
- ATH_DBG_WARN_ON_ONCE(!status);
+
+ if (!(ah->ah_flags & AH_UNPLUGGED))
+ ATH_DBG_WARN_ON_ONCE(!status);
return status;
}
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index b8ffaa5..5a3dfec 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -646,6 +646,10 @@ struct ath_nf_limits {
s16 nominal;
};
+/* ah_flags */
+#define AH_USE_EEPROM 0x1
+#define AH_UNPLUGGED 0x2 /* The card has been physically removed. */
+
struct ath_hw {
struct ieee80211_hw *hw;
struct ath_common common;
diff --git a/drivers/net/wireless/ath/ath9k/wmi.c b/drivers/net/wireless/ath/ath9k/wmi.c
index 8f42ea7..573daca 100644
--- a/drivers/net/wireless/ath/ath9k/wmi.c
+++ b/drivers/net/wireless/ath/ath9k/wmi.c
@@ -250,7 +250,7 @@ int ath9k_wmi_cmd(struct wmi *wmi, enum wmi_cmd_id cmd_id,
int time_left, ret = 0;
unsigned long flags;
- if (wmi->drv_priv->op_flags & OP_UNPLUGGED)
+ if (ah->ah_flags & AH_UNPLUGGED)
return 0;
skb = alloc_skb(headroom + cmd_len, GFP_ATOMIC);
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH v2 1/6] ath9k_htc: Fix warning on device removal
From: John W. Linville @ 2011-01-04 19:43 UTC (permalink / raw)
To: Sujith; +Cc: linux-wireless, Sujith.Manoharan
In-Reply-To: <19737.42640.829281.50449@gargle.gargle.HOWL>
On Tue, Dec 28, 2010 at 02:27:52PM +0530, Sujith wrote:
> From: Sujith Manoharan <Sujith.Manoharan@atheros.com>
>
> The commit "ath9k_hw: warn if we cannot change the power to the chip"
> introduced a new warning to indicate chip powerup failures, but this
> is not required for devices that have been removed. Handle USB device
> removal properly by checking for unplugged status.
>
> For PCI devices, this warning will still be seen when the card is pulled
> out, not sure how to check for card removal.
>
> Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
This doesn't seem to apply cleanly?
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH] ath9k_htc: Really fix packet injection
From: Sujith @ 2011-01-04 19:36 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, Sujith.Manoharan
From: Sujith Manoharan <Sujith.Manoharan@atheros.com>
The chainmask value along with other configuration has to be set
on the target for packet injection. Fix this and also move the monitor
interface addition before the channel set segment to ensure that
the opmode is updated properly.
Signed-off-by: Sujith Manoharan <Sujith.Manoharan@atheros.com>
---
drivers/net/wireless/ath/ath9k/htc.h | 1 +
drivers/net/wireless/ath/ath9k/htc_drv_main.c | 37 +++++++++++++++++-------
2 files changed, 27 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/htc.h b/drivers/net/wireless/ath/ath9k/htc.h
index a099b3e..1ce506f 100644
--- a/drivers/net/wireless/ath/ath9k/htc.h
+++ b/drivers/net/wireless/ath/ath9k/htc.h
@@ -433,6 +433,7 @@ void ath9k_htc_txep(void *priv, struct sk_buff *skb, enum htc_endpoint_id ep_id,
void ath9k_htc_beaconep(void *drv_priv, struct sk_buff *skb,
enum htc_endpoint_id ep_id, bool txok);
+int ath9k_htc_update_cap_target(struct ath9k_htc_priv *priv);
void ath9k_htc_station_work(struct work_struct *work);
void ath9k_htc_aggr_work(struct work_struct *work);
void ath9k_ani_work(struct work_struct *work);;
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index 845b4c9..f4d576b 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -301,6 +301,16 @@ static int ath9k_htc_add_monitor_interface(struct ath9k_htc_priv *priv)
priv->nstations++;
+ /*
+ * Set chainmask etc. on the target.
+ */
+ ret = ath9k_htc_update_cap_target(priv);
+ if (ret)
+ ath_dbg(common, ATH_DBG_CONFIG,
+ "Failed to update capability in target\n");
+
+ priv->ah->is_monitoring = true;
+
return 0;
err_vif:
@@ -328,6 +338,7 @@ static int ath9k_htc_remove_monitor_interface(struct ath9k_htc_priv *priv)
}
priv->nstations--;
+ priv->ah->is_monitoring = false;
return 0;
}
@@ -419,7 +430,7 @@ static int ath9k_htc_remove_station(struct ath9k_htc_priv *priv,
return 0;
}
-static int ath9k_htc_update_cap_target(struct ath9k_htc_priv *priv)
+int ath9k_htc_update_cap_target(struct ath9k_htc_priv *priv)
{
struct ath9k_htc_cap_target tcap;
int ret;
@@ -1186,6 +1197,20 @@ static int ath9k_htc_config(struct ieee80211_hw *hw, u32 changed)
}
}
+ /*
+ * Monitor interface should be added before
+ * IEEE80211_CONF_CHANGE_CHANNEL is handled.
+ */
+ if (changed & IEEE80211_CONF_CHANGE_MONITOR) {
+ if (conf->flags & IEEE80211_CONF_MONITOR) {
+ if (ath9k_htc_add_monitor_interface(priv))
+ ath_err(common, "Failed to set monitor mode\n");
+ else
+ ath_dbg(common, ATH_DBG_CONFIG,
+ "HW opmode set to Monitor mode\n");
+ }
+ }
+
if (changed & IEEE80211_CONF_CHANGE_CHANNEL) {
struct ieee80211_channel *curchan = hw->conf.channel;
int pos = curchan->hw_value;
@@ -1221,16 +1246,6 @@ static int ath9k_htc_config(struct ieee80211_hw *hw, u32 changed)
ath_update_txpow(priv);
}
- if (changed & IEEE80211_CONF_CHANGE_MONITOR) {
- if (conf->flags & IEEE80211_CONF_MONITOR) {
- if (ath9k_htc_add_monitor_interface(priv))
- ath_err(common, "Failed to set monitor mode\n");
- else
- ath_dbg(common, ATH_DBG_CONFIG,
- "HW opmode set to Monitor mode\n");
- }
- }
-
if (changed & IEEE80211_CONF_CHANGE_IDLE) {
mutex_lock(&priv->htc_pm_lock);
if (!priv->ps_idle) {
--
1.7.3.4
^ permalink raw reply related
* Re: [rt2x00-users] Linksys WUSB600N v1 disconnecting from AP
From: Luis Correia @ 2011-01-04 19:01 UTC (permalink / raw)
To: Helmut Schaa; +Cc: users, Luis R. Rodriguez, linux-wireless
In-Reply-To: <201101041946.56978.helmut.schaa@googlemail.com>
Hi all,
On Tue, Jan 4, 2011 at 18:46, Helmut Schaa <helmut.schaa@googlemail.com> wrote:
> Hi Aleksandar,
>
> looks like a somewhat strange regulatory handling. However, I'm not really
> familiar with the regulatory stuff. Maybe Luis can give us some info/ideas
> regarding this ...
>
> Luis, mind to have a look at the regulatory messages below?
>
Yes, there is something fishy with it.
this is what is allowed for Ireland
country IE:
(2402 - 2482 @ 40), (N/A, 20)
(5170 - 5250 @ 40), (N/A, 20)
(5250 - 5330 @ 40), (N/A, 20), DFS
(5490 - 5710 @ 40), (N/A, 27), DFS
Apparently IE Ireland does allow 5Ghz channels, and something is
really strange is going on.
Maybe if the Airport Extreme was changed to a new channel, it would improve.
But I'm not totally sure.
We might also be looking at an old regulatory daemon or database.
Luis Correia
> Am Dienstag, 4. Januar 2011 schrieb Aleksandar Milivojevic:
>> I've searched around a bit and haven't found much information that looks
>> like the problem I'm experiencing with rt2x00 drivers.
>>
>> The hardware I have is Linksys WUSB600N USB stick, v1 hardware revision,
>> which should have RT2870 chipset. The kernel used is from a generic Ubuntu
>> 10.10 distribution (uname shows "Linux toporko 2.6.35-24-generic #42-Ubuntu
>> SMP Thu Dec 2 01:41:57 UTC 2010 i686 GNU/Linux"). The output of lsusb
>> identifies device as:
>>
>> Bus 001 Device 003: ID 1737:0071 Linksys WUSB600N Dual-Band Wireless-N USB
>> Network Adapter
>>
>> The problem I'm experiencing is that I'm able to connect to my AP (an Apple
>> Airport Extreme operating at 5GHZ) shortly after boot. However, shortly
>> after connection is made (usually within few minutes), the connection is
>> dropped, and all subsequent attempts to re-connect to AP fail. Reloading
>> the driver helps to reconnect, but connection is again dropped after few
>> minutes. I also have another AP (an old Linksys WRT54G) operating on
>> 2.4GHz, and it seems same issue is present if I attempt to connect to it
>> (haven't experimented with this other setup much, as I'm much more
>> interested in connecting to my WiFi-N network).
>>
>> The list of relevant loaded drivers on the system shows (looking for
>> anything starting with 'rt' in the name):
>> rt2800usb 8367 0
>> rt2800lib 28897 1 rt2800usb
>> rt2x00usb 9779 2 rt2800usb,rt2800lib
>> rt2x00lib 27275 2 rt2800lib,rt2x00usb
>> led_class 2633 1 rt2x00lib
>> mac80211 231541 2 rt2x00usb,rt2x00lib
>> cfg80211 144470 2 rt2x00lib,mac80211
>>
>> I have rt2870sta driver blacklisted to prevent it from conflicting with
>> rt2x00 drivers.
>>
>> Looking at the log files, it seems /var/log/messages and /var/log/debug
>> contain most interesting logs.
>>
>> I found following snippet in /var/log/messages:
>>
>> Jan 3 10:39:38 toporko kernel: [ 70.143600] ADDRCONF(NETDEV_CHANGE):
>> wlan0: link becomes ready
>> Jan 3 10:39:38 toporko kernel: [ 70.143712] cfg80211: Calling CRDA for
>> country: US
>> Jan 3 10:39:38 toporko kernel: [ 70.219910] cfg80211: Regulatory domain:
>> US
>> Jan 3 10:39:38 toporko kernel: [ 70.219914] (start_freq - end_freq @
>> bandwidth), (max_antenna_gain, max_eirp)
>> Jan 3 10:39:38 toporko kernel: [ 70.219918] (5170000 KHz - 5250000
>> KHz @ 40000 KHz), (10000 mBi, 3000 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219923] (5735000 KHz - 5835000
>> KHz @ 40000 KHz), (10000 mBi, 3000 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219928] cfg80211: Regulatory domain:
>> US
>> Jan 3 10:39:38 toporko kernel: [ 70.219930] (start_freq - end_freq @
>> bandwidth), (max_antenna_gain, max_eirp)
>> Jan 3 10:39:38 toporko kernel: [ 70.219935] (2402000 KHz - 2472000
>> KHz @ 40000 KHz), (300 mBi, 2700 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219939] (5170000 KHz - 5250000
>> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219943] (5250000 KHz - 5330000
>> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219947] (5490000 KHz - 5600000
>> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219951] (5650000 KHz - 5710000
>> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219955] (5735000 KHz - 5835000
>> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219960] cfg80211: Regulatory domain:
>> 98
>> Jan 3 10:39:38 toporko kernel: [ 70.219962] (start_freq - end_freq @
>> bandwidth), (max_antenna_gain, max_eirp)
>> Jan 3 10:39:38 toporko kernel: [ 70.219966] (5170000 KHz - 5250000
>> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.219971] (5735000 KHz - 5835000
>> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.220189] cfg80211: Current regulatory
>> domain updated by AP to: US
>> Jan 3 10:39:38 toporko kernel: [ 70.220192] (start_freq - end_freq @
>> bandwidth), (max_antenna_gain, max_eirp)
>> Jan 3 10:39:38 toporko kernel: [ 70.220196] (5170000 KHz - 5250000
>> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.220200] (5735000 KHz - 5835000
>> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
>> Jan 3 10:39:38 toporko kernel: [ 70.409801] padlock: VIA PadLock not
>> detected.
>> Jan 3 10:40:20 toporko kernel: [ 112.656632] lo: Disabled Privacy
>> Extensions
>> Jan 3 10:41:31 toporko kernel: [ 183.593983] cfg80211: Calling CRDA to
>> update world regulatory domain
>> Jan 3 10:41:31 toporko kernel: [ 183.625264] cfg80211: World regulatory
>> domain updated:
>> Jan 3 10:41:31 toporko kernel: [ 183.625272] (start_freq - end_freq @
>> bandwidth), (max_antenna_gain, max_eirp)
>> Jan 3 10:41:31 toporko kernel: [ 183.625277] (2402000 KHz - 2472000
>> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> Jan 3 10:41:31 toporko kernel: [ 183.625282] (2457000 KHz - 2482000
>> KHz @ 20000 KHz), (300 mBi, 2000 mBm)
>> Jan 3 10:41:31 toporko kernel: [ 183.625286] (2474000 KHz - 2494000
>> KHz @ 20000 KHz), (300 mBi, 2000 mBm)
>> Jan 3 10:41:31 toporko kernel: [ 183.625290] (5170000 KHz - 5250000
>> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>> Jan 3 10:41:31 toporko kernel: [ 183.625294] (5735000 KHz - 5835000
>> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>>
>>
>> I also found similar snippet in /var/log/debug. Interestingly, unlike the
>> one above that lists IE as US (which is correct for my location, and
>> corresponds to the settings in my AP), in debug log file IE is strangely
>> blank with bunch of lines about disabled frequencies:
>>
>> Jan 3 10:39:38 toporko kernel: [ 70.114337] wlan0: authenticate with
>> 00:1e:52:79:e9:ff (try 1)
>> Jan 3 10:39:38 toporko kernel: [ 70.114955] wlan0: authenticated
>> Jan 3 10:39:38 toporko kernel: [ 70.118103] wlan0: associate with
>> 00:1e:52:79:e9:ff (try 1)
>> Jan 3 10:39:38 toporko kernel: [ 70.119214] wlan0: RX AssocResp from
>> 00:1e:52:79:e9:ff (capab=0x511 status=0 aid=1)
>> Jan 3 10:39:38 toporko kernel: [ 70.119220] wlan0: associated
>> Jan 3 10:39:38 toporko kernel: [ 70.219901] cfg80211: Received country
>> IE:
>> Jan 3 10:39:38 toporko kernel: [ 70.219925] cfg80211: CRDA thinks this
>> should applied:
>> Jan 3 10:39:38 toporko kernel: [ 70.219957] cfg80211: We intersect both
>> of these and get:
>> Jan 3 10:39:38 toporko kernel: [ 70.219977] cfg80211: Leaving channel
>> 2412 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.219981] cfg80211: Leaving channel
>> 2417 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.219985] cfg80211: Leaving channel
>> 2422 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.219988] cfg80211: Leaving channel
>> 2427 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.219992] cfg80211: Leaving channel
>> 2432 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220044] cfg80211: Leaving channel
>> 2437 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220048] cfg80211: Leaving channel
>> 2442 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220052] cfg80211: Leaving channel
>> 2447 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220056] cfg80211: Leaving channel
>> 2452 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220059] cfg80211: Leaving channel
>> 2457 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220063] cfg80211: Leaving channel
>> 2462 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220066] cfg80211: Leaving channel
>> 2467 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220070] cfg80211: Leaving channel
>> 2472 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220073] cfg80211: Leaving channel
>> 2484 MHz intact on phy0 - no rule found in band on Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220078] cfg80211: Disabling channel
>> 5260 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220081] cfg80211: Disabling channel
>> 5270 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220084] cfg80211: Disabling channel
>> 5280 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220087] cfg80211: Disabling channel
>> 5300 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220091] cfg80211: Disabling channel
>> 5310 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220094] cfg80211: Disabling channel
>> 5320 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220097] cfg80211: Disabling channel
>> 5500 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220100] cfg80211: Disabling channel
>> 5510 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220103] cfg80211: Disabling channel
>> 5520 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220106] cfg80211: Disabling channel
>> 5540 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220109] cfg80211: Disabling channel
>> 5550 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220113] cfg80211: Disabling channel
>> 5560 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220116] cfg80211: Disabling channel
>> 5580 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220119] cfg80211: Disabling channel
>> 5590 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220122] cfg80211: Disabling channel
>> 5600 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220125] cfg80211: Disabling channel
>> 5620 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220128] cfg80211: Disabling channel
>> 5630 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220131] cfg80211: Disabling channel
>> 5640 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220135] cfg80211: Disabling channel
>> 5660 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220138] cfg80211: Disabling channel
>> 5670 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220141] cfg80211: Disabling channel
>> 5680 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220144] cfg80211: Disabling channel
>> 5700 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220148] cfg80211: Disabling channel
>> 5835 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220151] cfg80211: Disabling channel
>> 5845 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220154] cfg80211: Disabling channel
>> 5855 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220157] cfg80211: Disabling channel
>> 5865 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220160] cfg80211: Disabling channel
>> 5920 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220163] cfg80211: Disabling channel
>> 5940 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220167] cfg80211: Disabling channel
>> 5960 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220170] cfg80211: Disabling channel
>> 5980 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220173] cfg80211: Disabling channel
>> 6040 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220176] cfg80211: Disabling channel
>> 6060 MHz on phy0 due to Country IE
>> Jan 3 10:39:38 toporko kernel: [ 70.220179] cfg80211: Disabling channel
>> 6080 MHz on phy0 due to Country IE
>> Jan 3 10:41:31 toporko kernel: [ 183.564046] No probe response from AP
>> 00:1e:52:79:e9:ff after 500ms, disconnecting.
>> Jan 3 10:41:31 toporko kernel: [ 183.593968] cfg80211: All devices are
>> disconnected, going to restore regulatory settings
>> Jan 3 10:41:31 toporko kernel: [ 183.593977] cfg80211: Restoring
>> regulatory settings
>> Jan 3 10:41:34 toporko kernel: [ 186.856369] wlan0: authenticate with
>> 00:1e:52:79:e9:ff (try 1)
>> Jan 3 10:41:34 toporko kernel: [ 187.056156] wlan0: authenticate with
>> 00:1e:52:79:e9:ff (try 2)
>> Jan 3 10:41:35 toporko kernel: [ 187.256419] wlan0: authenticate with
>> 00:1e:52:79:e9:ff (try 3)
>> Jan 3 10:41:35 toporko kernel: [ 187.456054] wlan0: authentication with
>> 00:1e:52:79:e9:ff timed out
>> Jan 3 10:41:47 toporko kernel: [ 200.054031] wlan0: direct probe to
>> 00:1e:52:79:e9:ff (try 1)
>> Jan 3 10:41:48 toporko kernel: [ 200.252050] wlan0: direct probe to
>> 00:1e:52:79:e9:ff (try 2)
>> Jan 3 10:41:48 toporko kernel: [ 200.452085] wlan0: direct probe to
>> 00:1e:52:79:e9:ff (try 3)
>
> We received an empty country IE and as a result disabled serveral 11a channels.
> Maybe even the one we are currently associated to?
>
> Thanks,
> Helmut
>
> _______________________________________________
> users mailing list
> users@rt2x00.serialmonkey.com
> http://rt2x00.serialmonkey.com/mailman/listinfo/users_rt2x00.serialmonkey.com
>
^ permalink raw reply
* Re: [PATCH 0/8] wireless: DFS region support
From: John W. Linville @ 2011-01-04 18:49 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: kathy.giori, amod.bodas, david.quan, michael.green,
linux-wireless
In-Reply-To: <1292864555-28661-1-git-send-email-lrodriguez@atheros.com>
On Mon, Dec 20, 2010 at 12:02:26PM -0500, Luis R. Rodriguez wrote:
> This series has a list of changes to kernel and userspace to start addressing
> DFS region support. I've cheated and figured out a way to alter the current
> regulatory database in such a way that it remains backwards compatible with
> older databases so that no new CRDAs are required and we don't have to provide
> two releases for old kernels and newer kernels for wireless-regdb updates.
>
> In the end we end up passing the DFS region to the drivers. In terms of our DFS
> development roadmap this covers parts I and II as promissed that I would take care
> of by tomorrow, and leaves open now the chance for developers to start working
> on part III: "Where do we stuff DFS parameters for each region":
>
> http://wireless.kernel.org/en/developers/DFS
>
> In tomorrow's meeting we can cover who is going to work on part III. People who
> want to work on part III can start using these patches on their systems.
>
> John, lets wait to merge these until Wednesday, I post these in patch form as I
> think they are ready but tomorrow's discussions may push us to alter this a
> bit, not sure. I will also review what we have done here with Michael Green so
> he is on the same page.
Well, now there has been plenty of time to reflect...comments? :-)
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [rt2x00-users] Linksys WUSB600N v1 disconnecting from AP
From: Helmut Schaa @ 2011-01-04 18:46 UTC (permalink / raw)
To: users; +Cc: Aleksandar Milivojevic, linux-wireless, Luis R. Rodriguez
In-Reply-To: <AANLkTim0AM3=T=TMu79ZQi79+CKANamBcz620n2xm8bW@mail.gmail.com>
Hi Aleksandar,
looks like a somewhat strange regulatory handling. However, I'm not really
familiar with the regulatory stuff. Maybe Luis can give us some info/ideas
regarding this ...
Luis, mind to have a look at the regulatory messages below?
Am Dienstag, 4. Januar 2011 schrieb Aleksandar Milivojevic:
> I've searched around a bit and haven't found much information that looks
> like the problem I'm experiencing with rt2x00 drivers.
>
> The hardware I have is Linksys WUSB600N USB stick, v1 hardware revision,
> which should have RT2870 chipset. The kernel used is from a generic Ubuntu
> 10.10 distribution (uname shows "Linux toporko 2.6.35-24-generic #42-Ubuntu
> SMP Thu Dec 2 01:41:57 UTC 2010 i686 GNU/Linux"). The output of lsusb
> identifies device as:
>
> Bus 001 Device 003: ID 1737:0071 Linksys WUSB600N Dual-Band Wireless-N USB
> Network Adapter
>
> The problem I'm experiencing is that I'm able to connect to my AP (an Apple
> Airport Extreme operating at 5GHZ) shortly after boot. However, shortly
> after connection is made (usually within few minutes), the connection is
> dropped, and all subsequent attempts to re-connect to AP fail. Reloading
> the driver helps to reconnect, but connection is again dropped after few
> minutes. I also have another AP (an old Linksys WRT54G) operating on
> 2.4GHz, and it seems same issue is present if I attempt to connect to it
> (haven't experimented with this other setup much, as I'm much more
> interested in connecting to my WiFi-N network).
>
> The list of relevant loaded drivers on the system shows (looking for
> anything starting with 'rt' in the name):
> rt2800usb 8367 0
> rt2800lib 28897 1 rt2800usb
> rt2x00usb 9779 2 rt2800usb,rt2800lib
> rt2x00lib 27275 2 rt2800lib,rt2x00usb
> led_class 2633 1 rt2x00lib
> mac80211 231541 2 rt2x00usb,rt2x00lib
> cfg80211 144470 2 rt2x00lib,mac80211
>
> I have rt2870sta driver blacklisted to prevent it from conflicting with
> rt2x00 drivers.
>
> Looking at the log files, it seems /var/log/messages and /var/log/debug
> contain most interesting logs.
>
> I found following snippet in /var/log/messages:
>
> Jan 3 10:39:38 toporko kernel: [ 70.143600] ADDRCONF(NETDEV_CHANGE):
> wlan0: link becomes ready
> Jan 3 10:39:38 toporko kernel: [ 70.143712] cfg80211: Calling CRDA for
> country: US
> Jan 3 10:39:38 toporko kernel: [ 70.219910] cfg80211: Regulatory domain:
> US
> Jan 3 10:39:38 toporko kernel: [ 70.219914] (start_freq - end_freq @
> bandwidth), (max_antenna_gain, max_eirp)
> Jan 3 10:39:38 toporko kernel: [ 70.219918] (5170000 KHz - 5250000
> KHz @ 40000 KHz), (10000 mBi, 3000 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219923] (5735000 KHz - 5835000
> KHz @ 40000 KHz), (10000 mBi, 3000 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219928] cfg80211: Regulatory domain:
> US
> Jan 3 10:39:38 toporko kernel: [ 70.219930] (start_freq - end_freq @
> bandwidth), (max_antenna_gain, max_eirp)
> Jan 3 10:39:38 toporko kernel: [ 70.219935] (2402000 KHz - 2472000
> KHz @ 40000 KHz), (300 mBi, 2700 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219939] (5170000 KHz - 5250000
> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219943] (5250000 KHz - 5330000
> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219947] (5490000 KHz - 5600000
> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219951] (5650000 KHz - 5710000
> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219955] (5735000 KHz - 5835000
> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219960] cfg80211: Regulatory domain:
> 98
> Jan 3 10:39:38 toporko kernel: [ 70.219962] (start_freq - end_freq @
> bandwidth), (max_antenna_gain, max_eirp)
> Jan 3 10:39:38 toporko kernel: [ 70.219966] (5170000 KHz - 5250000
> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.219971] (5735000 KHz - 5835000
> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.220189] cfg80211: Current regulatory
> domain updated by AP to: US
> Jan 3 10:39:38 toporko kernel: [ 70.220192] (start_freq - end_freq @
> bandwidth), (max_antenna_gain, max_eirp)
> Jan 3 10:39:38 toporko kernel: [ 70.220196] (5170000 KHz - 5250000
> KHz @ 40000 KHz), (300 mBi, 1700 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.220200] (5735000 KHz - 5835000
> KHz @ 40000 KHz), (300 mBi, 3000 mBm)
> Jan 3 10:39:38 toporko kernel: [ 70.409801] padlock: VIA PadLock not
> detected.
> Jan 3 10:40:20 toporko kernel: [ 112.656632] lo: Disabled Privacy
> Extensions
> Jan 3 10:41:31 toporko kernel: [ 183.593983] cfg80211: Calling CRDA to
> update world regulatory domain
> Jan 3 10:41:31 toporko kernel: [ 183.625264] cfg80211: World regulatory
> domain updated:
> Jan 3 10:41:31 toporko kernel: [ 183.625272] (start_freq - end_freq @
> bandwidth), (max_antenna_gain, max_eirp)
> Jan 3 10:41:31 toporko kernel: [ 183.625277] (2402000 KHz - 2472000
> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Jan 3 10:41:31 toporko kernel: [ 183.625282] (2457000 KHz - 2482000
> KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> Jan 3 10:41:31 toporko kernel: [ 183.625286] (2474000 KHz - 2494000
> KHz @ 20000 KHz), (300 mBi, 2000 mBm)
> Jan 3 10:41:31 toporko kernel: [ 183.625290] (5170000 KHz - 5250000
> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
> Jan 3 10:41:31 toporko kernel: [ 183.625294] (5735000 KHz - 5835000
> KHz @ 40000 KHz), (300 mBi, 2000 mBm)
>
>
> I also found similar snippet in /var/log/debug. Interestingly, unlike the
> one above that lists IE as US (which is correct for my location, and
> corresponds to the settings in my AP), in debug log file IE is strangely
> blank with bunch of lines about disabled frequencies:
>
> Jan 3 10:39:38 toporko kernel: [ 70.114337] wlan0: authenticate with
> 00:1e:52:79:e9:ff (try 1)
> Jan 3 10:39:38 toporko kernel: [ 70.114955] wlan0: authenticated
> Jan 3 10:39:38 toporko kernel: [ 70.118103] wlan0: associate with
> 00:1e:52:79:e9:ff (try 1)
> Jan 3 10:39:38 toporko kernel: [ 70.119214] wlan0: RX AssocResp from
> 00:1e:52:79:e9:ff (capab=0x511 status=0 aid=1)
> Jan 3 10:39:38 toporko kernel: [ 70.119220] wlan0: associated
> Jan 3 10:39:38 toporko kernel: [ 70.219901] cfg80211: Received country
> IE:
> Jan 3 10:39:38 toporko kernel: [ 70.219925] cfg80211: CRDA thinks this
> should applied:
> Jan 3 10:39:38 toporko kernel: [ 70.219957] cfg80211: We intersect both
> of these and get:
> Jan 3 10:39:38 toporko kernel: [ 70.219977] cfg80211: Leaving channel
> 2412 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.219981] cfg80211: Leaving channel
> 2417 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.219985] cfg80211: Leaving channel
> 2422 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.219988] cfg80211: Leaving channel
> 2427 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.219992] cfg80211: Leaving channel
> 2432 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220044] cfg80211: Leaving channel
> 2437 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220048] cfg80211: Leaving channel
> 2442 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220052] cfg80211: Leaving channel
> 2447 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220056] cfg80211: Leaving channel
> 2452 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220059] cfg80211: Leaving channel
> 2457 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220063] cfg80211: Leaving channel
> 2462 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220066] cfg80211: Leaving channel
> 2467 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220070] cfg80211: Leaving channel
> 2472 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220073] cfg80211: Leaving channel
> 2484 MHz intact on phy0 - no rule found in band on Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220078] cfg80211: Disabling channel
> 5260 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220081] cfg80211: Disabling channel
> 5270 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220084] cfg80211: Disabling channel
> 5280 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220087] cfg80211: Disabling channel
> 5300 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220091] cfg80211: Disabling channel
> 5310 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220094] cfg80211: Disabling channel
> 5320 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220097] cfg80211: Disabling channel
> 5500 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220100] cfg80211: Disabling channel
> 5510 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220103] cfg80211: Disabling channel
> 5520 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220106] cfg80211: Disabling channel
> 5540 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220109] cfg80211: Disabling channel
> 5550 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220113] cfg80211: Disabling channel
> 5560 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220116] cfg80211: Disabling channel
> 5580 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220119] cfg80211: Disabling channel
> 5590 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220122] cfg80211: Disabling channel
> 5600 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220125] cfg80211: Disabling channel
> 5620 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220128] cfg80211: Disabling channel
> 5630 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220131] cfg80211: Disabling channel
> 5640 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220135] cfg80211: Disabling channel
> 5660 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220138] cfg80211: Disabling channel
> 5670 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220141] cfg80211: Disabling channel
> 5680 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220144] cfg80211: Disabling channel
> 5700 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220148] cfg80211: Disabling channel
> 5835 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220151] cfg80211: Disabling channel
> 5845 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220154] cfg80211: Disabling channel
> 5855 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220157] cfg80211: Disabling channel
> 5865 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220160] cfg80211: Disabling channel
> 5920 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220163] cfg80211: Disabling channel
> 5940 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220167] cfg80211: Disabling channel
> 5960 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220170] cfg80211: Disabling channel
> 5980 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220173] cfg80211: Disabling channel
> 6040 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220176] cfg80211: Disabling channel
> 6060 MHz on phy0 due to Country IE
> Jan 3 10:39:38 toporko kernel: [ 70.220179] cfg80211: Disabling channel
> 6080 MHz on phy0 due to Country IE
> Jan 3 10:41:31 toporko kernel: [ 183.564046] No probe response from AP
> 00:1e:52:79:e9:ff after 500ms, disconnecting.
> Jan 3 10:41:31 toporko kernel: [ 183.593968] cfg80211: All devices are
> disconnected, going to restore regulatory settings
> Jan 3 10:41:31 toporko kernel: [ 183.593977] cfg80211: Restoring
> regulatory settings
> Jan 3 10:41:34 toporko kernel: [ 186.856369] wlan0: authenticate with
> 00:1e:52:79:e9:ff (try 1)
> Jan 3 10:41:34 toporko kernel: [ 187.056156] wlan0: authenticate with
> 00:1e:52:79:e9:ff (try 2)
> Jan 3 10:41:35 toporko kernel: [ 187.256419] wlan0: authenticate with
> 00:1e:52:79:e9:ff (try 3)
> Jan 3 10:41:35 toporko kernel: [ 187.456054] wlan0: authentication with
> 00:1e:52:79:e9:ff timed out
> Jan 3 10:41:47 toporko kernel: [ 200.054031] wlan0: direct probe to
> 00:1e:52:79:e9:ff (try 1)
> Jan 3 10:41:48 toporko kernel: [ 200.252050] wlan0: direct probe to
> 00:1e:52:79:e9:ff (try 2)
> Jan 3 10:41:48 toporko kernel: [ 200.452085] wlan0: direct probe to
> 00:1e:52:79:e9:ff (try 3)
We received an empty country IE and as a result disabled serveral 11a channels.
Maybe even the one we are currently associated to?
Thanks,
Helmut
^ permalink raw reply
* Re: (rt61pci/hostapd) no packet activity when encryption is enabled and interface is bridged
From: Helmut Schaa @ 2011-01-04 18:36 UTC (permalink / raw)
To: C Anthony Risinger; +Cc: linux-wireless
In-Reply-To: <AANLkTimPmCZ3O0WKe4OH1z4+rmtUtAr2wqsrFOUCJg_Q@mail.gmail.com>
Am Dienstag, 4. Januar 2011 schrieb C Anthony Risinger:
> On Mon, Jan 3, 2011 at 10:30 PM, C Anthony Risinger <anthony@extof.me> wrote:
> >
> > problem summary: an rt61pci driven card does not seem to allow any
> > packets to enter/exit it's bridge ONLY WHEN ENCRYPTION is enabled;
> > without it, everything works perfectly.
>
> hmmmmm....
>
> it would seem:
>
> options rt61pci nohwcrypt=1
>
> solves the problem. what does this mean? do i have a bad chip?
I don't think so. Might be related to [1].
Helmut
[1] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=fa8b4b22d543b4052602b0c86065150613ed19e8
^ permalink raw reply
* Re: [PATCH] b43: N-PHY: enable support for PHYs rev 3 and higher
From: Larry Finger @ 2011-01-04 18:19 UTC (permalink / raw)
To: John W. Linville; +Cc: Rafał Miłecki, linux-wireless, b43-dev
In-Reply-To: <20110104181140.GC11333@tuxdriver.com>
On 01/04/2011 12:11 PM, John W. Linville wrote:
> On Tue, Jan 04, 2011 at 10:08:36AM -0600, Larry Finger wrote:
>> On 01/04/2011 09:50 AM, Rafał Miłecki wrote:
>>> W dniu 21 grudnia 2010 21:29 użytkownik Rafał Miłecki
>>> <zajec5@gmail.com> napisał:
>>>> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
>>>> ---
>>>> John: can we still make it for 2.6.38 merge? It was tested with 14e4:432b,
>>>> support seems to be on the same level as for PHYs 1 and 2.
>>>
>>> John, I dont see patches for rev3+ in wireless-testing. Any problems with them?
>>>
>>> It means:
>>> [PATCH 1/4] b43: use correct firmware for newer cores
>>> [PATCH 2/4 v2] b43: N-PHY: implement radio 2056 init steps
>>> [PATCH 3/4] b43: N-PHY: add init tables for 2056 radio
>>> [PATCH 4/4] b43: N-PHY: avoid PHY hangs for rev 3 and 4
>>>
>>> [PATCH 1/2] b43: N-PHY: use correct channel tables for rev4+
>>> [PATCH 2/2 v2] b43: N-PHY: update 2056 radio on channel switch on rev3+
>>> and this one.
>>
>> John,
>>
>> I have been testing these patches with a 14e4:432b device for at least two
>> weeks. With them, the driver still does not handle WPA/WPA2 encryption and falls
>> over with OFDM rates, but it is rock solid with WEP encryption and at 11 Mb/s.
>> Rafał and I have some ideas why the limitations, but the holidays have
>> interfered with debugging.
>>
>> Larry
>
> And with merging...
>
> I hope to get caught-up soon.
I hope there are some rtlwifi/rtl8192ce updates there as well. I'll wait for
some new merges before I bug you about the specific patches.
Larry
^ permalink raw reply
* Re: [PATCH] mac80211: Push idle state to driver before stop
From: Paul Stewart @ 2011-01-04 18:19 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: Johannes Berg, linux-wireless@vger.kernel.org, Luis Rodriguez
In-Reply-To: <20101216174410.GB5677@tux>
On Thu, Dec 16, 2010 at 9:44 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> Try this:
Happy new year. I've tried this patch, and the system continues to
suspend and resume successfully (i.e, the fix from the earlier patches
continues to alleviate the original problem), however the system
continues to be "deaf" to beacons at resume time if the system
suspends and resumes while associated. You don't need a ChromeOS
system to reproduce this issue. Just associate to the network and
suspend/resume. On resume the system believes it should be
associated, but then the beacon loss timer kicks in and we
disassociate, since we are never successful in receiving a response.
--
Paul
^ permalink raw reply
* Re: [PATCH] b43: N-PHY: enable support for PHYs rev 3 and higher
From: John W. Linville @ 2011-01-04 18:11 UTC (permalink / raw)
To: Larry Finger; +Cc: Rafał Miłecki, linux-wireless, b43-dev
In-Reply-To: <4D234604.8010602@lwfinger.net>
On Tue, Jan 04, 2011 at 10:08:36AM -0600, Larry Finger wrote:
> On 01/04/2011 09:50 AM, Rafał Miłecki wrote:
> > W dniu 21 grudnia 2010 21:29 użytkownik Rafał Miłecki
> > <zajec5@gmail.com> napisał:
> >> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
> >> ---
> >> John: can we still make it for 2.6.38 merge? It was tested with 14e4:432b,
> >> support seems to be on the same level as for PHYs 1 and 2.
> >
> > John, I dont see patches for rev3+ in wireless-testing. Any problems with them?
> >
> > It means:
> > [PATCH 1/4] b43: use correct firmware for newer cores
> > [PATCH 2/4 v2] b43: N-PHY: implement radio 2056 init steps
> > [PATCH 3/4] b43: N-PHY: add init tables for 2056 radio
> > [PATCH 4/4] b43: N-PHY: avoid PHY hangs for rev 3 and 4
> >
> > [PATCH 1/2] b43: N-PHY: use correct channel tables for rev4+
> > [PATCH 2/2 v2] b43: N-PHY: update 2056 radio on channel switch on rev3+
> > and this one.
>
> John,
>
> I have been testing these patches with a 14e4:432b device for at least two
> weeks. With them, the driver still does not handle WPA/WPA2 encryption and falls
> over with OFDM rates, but it is rock solid with WEP encryption and at 11 Mb/s.
> Rafał and I have some ideas why the limitations, but the holidays have
> interfered with debugging.
>
> Larry
And with merging...
I hope to get caught-up soon.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH 07/15]drivers:net:wireless:iwlwifi Typo change diable to disable.
From: John W. Linville @ 2011-01-04 17:56 UTC (permalink / raw)
To: Justin P. Mattock
Cc: trivial, linux-m68k, linux-kernel, netdev, ivtv-devel,
linux-media, linux-wireless, linux-scsi, spi-devel-general, devel,
linux-usb
In-Reply-To: <1293750484-1161-7-git-send-email-justinmattock@gmail.com>
On Thu, Dec 30, 2010 at 03:07:56PM -0800, Justin P. Mattock wrote:
> The below patch fixes a typo "diable" to "disable". Please let me know if this
> is correct or not.
>
> Signed-off-by: Justin P. Mattock <justinmattock@gmail.com>
Acked-by: John W. Linville <linville@tuxdriver.com>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: Tp-link wn7200nd - cannot associate
From: Helmut Schaa @ 2011-01-04 16:42 UTC (permalink / raw)
To: Chin Shi Hong; +Cc: Ming-Ching Tiew, linux-wireless
In-Reply-To: <AANLkTimk8pnx3F+pwVTZ6sA+=-_h+4u+i=YTzp05Qf=A@mail.gmail.com>
Am Montag, 3. Januar 2011 schrieb Chin Shi Hong:
> Good luck with you. My rt3090 also not work on 64 bit ubuntu but work
> on 32 bit ubuntu.
Might be fixed with [1].
Helmut
[1] http://git.kernel.org/?p=linux/kernel/git/linville/wireless-testing.git;a=commit;h=412b31334b831a8c2909afaca017c5a236ac2dd0
^ permalink raw reply
* Re: [PATCH] b43: N-PHY: enable support for PHYs rev 3 and higher
From: Larry Finger @ 2011-01-04 16:08 UTC (permalink / raw)
To: John W. Linville; +Cc: Rafał Miłecki, linux-wireless, b43-dev
In-Reply-To: <AANLkTikwKOLJ6A-DTEuVg43_g_cWgDg2xK4M6qQ0Lm4U@mail.gmail.com>
On 01/04/2011 09:50 AM, Rafał Miłecki wrote:
> W dniu 21 grudnia 2010 21:29 użytkownik Rafał Miłecki
> <zajec5@gmail.com> napisał:
>> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
>> ---
>> John: can we still make it for 2.6.38 merge? It was tested with 14e4:432b,
>> support seems to be on the same level as for PHYs 1 and 2.
>
> John, I dont see patches for rev3+ in wireless-testing. Any problems with them?
>
> It means:
> [PATCH 1/4] b43: use correct firmware for newer cores
> [PATCH 2/4 v2] b43: N-PHY: implement radio 2056 init steps
> [PATCH 3/4] b43: N-PHY: add init tables for 2056 radio
> [PATCH 4/4] b43: N-PHY: avoid PHY hangs for rev 3 and 4
>
> [PATCH 1/2] b43: N-PHY: use correct channel tables for rev4+
> [PATCH 2/2 v2] b43: N-PHY: update 2056 radio on channel switch on rev3+
> and this one.
John,
I have been testing these patches with a 14e4:432b device for at least two
weeks. With them, the driver still does not handle WPA/WPA2 encryption and falls
over with OFDM rates, but it is rock solid with WEP encryption and at 11 Mb/s.
Rafał and I have some ideas why the limitations, but the holidays have
interfered with debugging.
Larry
^ permalink raw reply
* Re: [PATCH] b43: N-PHY: enable support for PHYs rev 3 and higher
From: Rafał Miłecki @ 2011-01-04 15:50 UTC (permalink / raw)
To: linux-wireless, John W. Linville; +Cc: b43-dev, Rafał Miłecki
In-Reply-To: <1292963384-23684-1-git-send-email-zajec5@gmail.com>
W dniu 21 grudnia 2010 21:29 użytkownik Rafał Miłecki
<zajec5@gmail.com> napisał:
> Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
> ---
> John: can we still make it for 2.6.38 merge? It was tested with 14e4:432b,
> support seems to be on the same level as for PHYs 1 and 2.
John, I dont see patches for rev3+ in wireless-testing. Any problems with them?
It means:
[PATCH 1/4] b43: use correct firmware for newer cores
[PATCH 2/4 v2] b43: N-PHY: implement radio 2056 init steps
[PATCH 3/4] b43: N-PHY: add init tables for 2056 radio
[PATCH 4/4] b43: N-PHY: avoid PHY hangs for rev 3 and 4
[PATCH 1/2] b43: N-PHY: use correct channel tables for rev4+
[PATCH 2/2 v2] b43: N-PHY: update 2056 radio on channel switch on rev3+
and this one.
--
Rafał
^ permalink raw reply
* Re: [PATCH] wl12xx: don't join upon disassociation
From: Eliad Peller @ 2011-01-04 13:13 UTC (permalink / raw)
To: Juuso Oikarinen; +Cc: Luciano Coelho, linux-wireless
In-Reply-To: <1294145621.4166.118.camel@wimaxnb.nmp.nokia.com>
On Tue, Jan 4, 2011 at 2:53 PM, Juuso Oikarinen
<juuso.oikarinen@nokia.com> wrote:
> On Sun, 2010-12-26 at 10:27 +0200, ext Eliad Peller wrote:
>> wl12xx "rejoins" upon every BSS_CHANGED_BSSID notification.
>> However, there is no need to rejoin after disassociation, so just
>> filter out the case when the new bssid is 00:00:00:00:00:00.
>>
>> Signed-off-by: Eliad Peller <eliad@wizery.com>
>> ---
>> drivers/net/wireless/wl12xx/main.c | 24 ++++++++++++++----------
>> 1 files changed, 14 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
>> index 062247e..7aa783c 100644
>> --- a/drivers/net/wireless/wl12xx/main.c
>> +++ b/drivers/net/wireless/wl12xx/main.c
>> @@ -1944,19 +1944,23 @@ static void wl1271_op_bss_info_changed(struct ieee80211_hw *hw,
>> memcmp(wl->bssid, bss_conf->bssid, ETH_ALEN)) {
>> memcpy(wl->bssid, bss_conf->bssid, ETH_ALEN);
>>
>> - ret = wl1271_cmd_build_null_data(wl);
>> - if (ret < 0)
>> - goto out_sleep;
>> + if (!is_zero_ether_addr(wl->bssid)) {
>> + ret = wl1271_cmd_build_null_data(wl);
>> + if (ret < 0)
>> + goto out_sleep;
>>
>> - ret = wl1271_build_qos_null_data(wl);
>> - if (ret < 0)
>> - goto out_sleep;
>> + ret = wl1271_build_qos_null_data(wl);
>> + if (ret < 0)
>> + goto out_sleep;
>>
>> - /* filter out all packets not from this BSSID */
>> - wl1271_configure_filters(wl, 0);
>> + /* filter out all packets not from this BSSID */
>> + wl1271_configure_filters(wl, 0);
>>
>> - /* Need to update the BSSID (for filtering etc) */
>> - do_join = true;
>> + /*
>> + * Need to update the BSSID (for filtering etc)
>> + */
>> + do_join = true;
>> + }
>> }
>>
>> if (changed & BSS_CHANGED_ASSOC) {
>
> The device still stays joined after disassoc, right? I guess the device
> should be receiving/transmitting frames while not idle.
>
> That is why we did have a specific dummy-join in disassoc, and also the
> BSSID filters etc are cleared!
>
the patch doesn't unjoin, it just prevents rejoining (and some other
configurations) to an "empty" bssid, so it shouldn't affect the
current join state.
the actual unjoin will only be only executed when the device goes idle.
^ permalink raw reply
* Re: [PATCH] wl12xx: don't join upon disassociation
From: Juuso Oikarinen @ 2011-01-04 12:53 UTC (permalink / raw)
To: ext Eliad Peller; +Cc: Luciano Coelho, linux-wireless
In-Reply-To: <1293352070-17513-1-git-send-email-eliad@wizery.com>
On Sun, 2010-12-26 at 10:27 +0200, ext Eliad Peller wrote:
> wl12xx "rejoins" upon every BSS_CHANGED_BSSID notification.
> However, there is no need to rejoin after disassociation, so just
> filter out the case when the new bssid is 00:00:00:00:00:00.
>
> Signed-off-by: Eliad Peller <eliad@wizery.com>
> ---
> drivers/net/wireless/wl12xx/main.c | 24 ++++++++++++++----------
> 1 files changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
> index 062247e..7aa783c 100644
> --- a/drivers/net/wireless/wl12xx/main.c
> +++ b/drivers/net/wireless/wl12xx/main.c
> @@ -1944,19 +1944,23 @@ static void wl1271_op_bss_info_changed(struct ieee80211_hw *hw,
> memcmp(wl->bssid, bss_conf->bssid, ETH_ALEN)) {
> memcpy(wl->bssid, bss_conf->bssid, ETH_ALEN);
>
> - ret = wl1271_cmd_build_null_data(wl);
> - if (ret < 0)
> - goto out_sleep;
> + if (!is_zero_ether_addr(wl->bssid)) {
> + ret = wl1271_cmd_build_null_data(wl);
> + if (ret < 0)
> + goto out_sleep;
>
> - ret = wl1271_build_qos_null_data(wl);
> - if (ret < 0)
> - goto out_sleep;
> + ret = wl1271_build_qos_null_data(wl);
> + if (ret < 0)
> + goto out_sleep;
>
> - /* filter out all packets not from this BSSID */
> - wl1271_configure_filters(wl, 0);
> + /* filter out all packets not from this BSSID */
> + wl1271_configure_filters(wl, 0);
>
> - /* Need to update the BSSID (for filtering etc) */
> - do_join = true;
> + /*
> + * Need to update the BSSID (for filtering etc)
> + */
> + do_join = true;
> + }
> }
>
> if (changed & BSS_CHANGED_ASSOC) {
The device still stays joined after disassoc, right? I guess the device
should be receiving/transmitting frames while not idle.
That is why we did have a specific dummy-join in disassoc, and also the
BSSID filters etc are cleared!
-Juuso
^ permalink raw reply
* [PATCH] mac80211: add remain-on-channel docs
From: Johannes Berg @ 2011-01-04 12:02 UTC (permalink / raw)
To: John Linville; +Cc: linux-wireless@vger.kernel.org
From: Johannes Berg <johannes.berg@intel.com>
Add documentation for the new callbacks that I
forgot in the patch adding the callbacks.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
include/net/mac80211.h | 10 ++++++++++
1 file changed, 10 insertions(+)
--- wireless-testing.orig/include/net/mac80211.h 2011-01-04 12:58:16.000000000 +0100
+++ wireless-testing/include/net/mac80211.h 2011-01-04 13:01:20.000000000 +0100
@@ -1753,6 +1753,16 @@ enum ieee80211_ampdu_mlme_action {
* (also see nl80211.h @NL80211_ATTR_WIPHY_ANTENNA_TX).
*
* @get_antenna: Get current antenna configuration from device (tx_ant, rx_ant).
+ *
+ * @remain_on_channel: Starts an off-channel period on the given channel, must
+ * call back to ieee80211_ready_on_channel() when on that channel. Note
+ * that normal channel traffic is not stopped as this is intended for hw
+ * offload. Frames to transmit on the off-channel channel are transmitted
+ * normally except for the %IEEE80211_TX_CTL_TX_OFFCHAN flag. When the
+ * duration (which will always be non-zero) expires, the driver must call
+ * ieee80211_remain_on_channel_expired(). This callback may sleep.
+ * @cancel_remain_on_channel: Requests that an ongoing off-channel period is
+ * aborted before it expires. This callback may sleep.
*/
struct ieee80211_ops {
int (*tx)(struct ieee80211_hw *hw, struct sk_buff *skb);
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox