* Re: 2.6.32-rc5-git1 -- INFO: possible circular locking dependency detected
From: Johannes Berg @ 2009-10-22 8:34 UTC (permalink / raw)
To: Miles Lane; +Cc: LKML, linux-wireless, Holger Schurig, Alan Jenkins
In-Reply-To: <4ADDBD2A.7070807@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1741 bytes --]
On Tue, 2009-10-20 at 09:37 -0400, Miles Lane wrote:
> Resending with wrapping off and time info removed:
Hey, thanks for that!
> [ INFO: possible circular locking dependency detected ]
> 2.6.32-rc5-git1 #1
> -------------------------------------------------------
> events/0/9 is trying to acquire lock:
> (&rfkill->sync_work){+.+.+.}, at: [<c1039083>]
> __cancel_work_timer+0x81/0x181
>
> but task is already holding lock:
> (&ehotk->hotplug_lock){+.+.+.}, at: [<f8587708>]
> eeepc_rfkill_hotplug+0x45/0xda [eeepc_laptop]
>
> which lock already depends on the new lock.
>
>
> the existing dependency chain (in reverse order) is:
>
> -> #2 (&ehotk->hotplug_lock){+.+.+.}:
> [<c129e5ee>] mutex_lock_nested+0x2b/0x33
> [<f8587708>] eeepc_rfkill_hotplug+0x45/0xda [eeepc_laptop]
> [<f858787c>] eeepc_rfkill_set+0x1d/0x2d [eeepc_laptop]
> [<f83f4a9f>] rfkill_set_block+0x6f/0xb1 [rfkill]
> [<f83f4b78>] __rfkill_switch_all+0x2e/0x51 [rfkill]
> [<f83f4c12>] rfkill_switch_all+0x33/0x41 [rfkill]
> [<f83f51b0>] rfkill_op_handler+0xf0/0x11e [rfkill]
> [<c1038965>] worker_thread+0x161/0x233
> [<c103b883>] kthread+0x5f/0x64
> [<c1003613>] kernel_thread_helper+0x7/0x10
>
> -> #1 (rfkill_global_mutex){+.+.+.}:
> [<c104ac60>] __lock_acquire+0x9fb/0xb6d
> [<c104ae2e>] lock_acquire+0x5c/0x73
> [<c129e223>] __mutex_lock_common+0x39/0x375
> [<c129e5ee>] mutex_lock_nested+0x2b/0x33
> [<f83f4c36>] rfkill_sync_work+0x16/0x35 [rfkill]
Hmm. It seems eeepc takes the hotplug lock in the set path, but also
elsewhere? Seems like a bug in eeepc, Alan?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: cfg80211 / libertas: an unusual race
From: Johannes Berg @ 2009-10-22 8:47 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless
In-Reply-To: <200910161403.37660.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 532 bytes --]
On Fri, 2009-10-16 at 14:03 +0200, Holger Schurig wrote:
> > I don't see this happening that way -- how are you even getting
> to
> > __cfg80211_disconnected() if not through _send_deauth()?
>
> See step 7a in the second table. We got there via
> _send_deauth().
>
> But later, step 3b in the second table (I kept the original
> numbers, so 3b happens after 7a time-wise!) we got into
> WARN_ON().
Still not making sense to me, since cfg80211_mlme_deauth() never does
anything after calling you.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC 1/3] mac80211: WIP - add operating BSSID to device configuration struct
From: Johannes Berg @ 2009-10-22 8:55 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless, kalle.valo, juuso.oikarinen
In-Reply-To: <1255696042-28413-2-git-send-email-luciano.coelho@nokia.com>
[-- Attachment #1: Type: text/plain, Size: 871 bytes --]
On Fri, 2009-10-16 at 15:27 +0300, Luciano Coelho wrote:
> @@ -2405,7 +2411,15 @@ int ieee80211_mgd_auth(struct ieee80211_sub_if_data *sdata,
> * to sleep and then change channel etc.
> */
> sdata->local->oper_channel = req->bss->channel;
> - ieee80211_hw_config(sdata->local, 0);
> +
> + if (memcmp(sdata->local->hw.conf.oper_bssid,
> + req->bss->bssid, ETH_ALEN)) {
> + config_changed |= IEEE80211_CONF_CHANGE_OPER_BSSID;
> + memcpy(sdata->local->hw.conf.oper_bssid,
> + req->bss->bssid, ETH_ALEN);
> + }
> +
> + ieee80211_hw_config(sdata->local, config_changed);
>
Is this really necessary before you can auth?
If it is, you're going to have to do a lot more work and go all the way
up to userspace so wpa_supplicant with -Dnl80211 knows about this too,
and doesn't try to authenticate twice or do FT-OTA.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: NOHZ: local_softirq_pending 08
From: Johannes Berg @ 2009-10-23 13:34 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Jarek Poplawski, David Miller, hidave.darkstar, linux-kernel,
tglx, linux-wireless, linux-ppp, netdev, paulus, isdn4linux,
i4ldeveloper, Karsten Keil
In-Reply-To: <4AE0ECCE.2020407@imap.cc>
[-- Attachment #1: Type: text/plain, Size: 566 bytes --]
On Fri, 2009-10-23 at 01:37 +0200, Tilman Schmidt wrote:
> --- a/drivers/isdn/i4l/isdn_ppp.c
> +++ b/drivers/isdn/i4l/isdn_ppp.c
> @@ -1174,7 +1174,10 @@ isdn_ppp_push_higher(isdn_net_dev * net_dev, isdn_net_local * lp, struct sk_buff
> #endif /* CONFIG_IPPP_FILTER */
> skb->dev = dev;
> skb_reset_mac_header(skb);
> - netif_rx(skb);
> + if (in_interrupt())
> + netif_rx(skb);
> + else
> + netif_rx_ni(skb);
So you've verified that the entire i4l stack can cope with being called
twice on the same CPU, from different contexts?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] cfg80211: sme: deauthenticate on assoc failure
From: Johannes Berg @ 2009-10-23 13:35 UTC (permalink / raw)
To: Jouni Malinen; +Cc: John Linville, linux-wireless, Luis R. Rodriguez
In-Reply-To: <20091023040623.GA8786@jm.kir.nu>
[-- Attachment #1: Type: text/plain, Size: 932 bytes --]
On Thu, 2009-10-22 at 21:07 -0700, Jouni Malinen wrote:
> On Tue, Oct 20, 2009 at 03:08:53PM +0900, Johannes Berg wrote:
> > When the in-kernel SME gets an association failure from
> > the AP we don't deauthenticate, and thus get into a very
> > confused state which will lead to warnings later on. Fix
> > this by actually deauthenticating when the AP indicates
> > an association failure.
>
> While this may be a reasonable change to resolve an issue now, this may
> not be the best long term solution. There are some association failure
> cases which should really be handled by trying association again instead
> of deauthenticating. The main example would be the association comeback
> time use in IEEE 802.11w. In general, association failure should not
> result in deauthentication in every case.
I'm pretty sure the issue should be fixed with the other two patches
Luis and I cooked up at KS.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] cfg80211: allow driver to signal noise level
From: Johannes Berg @ 2009-10-23 13:40 UTC (permalink / raw)
To: Holger Schurig; +Cc: John Linville, linux-wireless
In-Reply-To: <200910220913.19759.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 718 bytes --]
On Thu, 2009-10-22 at 09:13 +0200, Holger Schurig wrote:
> On Wednesday 21 October 2009 01:18:11 Johannes Berg wrote:
> > As discussed previously, noise is not a property of a station.
>
> URL?
At the wireless summit in Berlin, I think. I realise that not everybody
can be there, but still:
http://wireless.kernel.org/en/developers/Summits/Berlin-2009/notes
>
> Should I aim for an "iw dev XXX show noise", e.g. try to
> handle it as a property of the card? I could either add
> an .get_noise() to cfg80211_ops, or better an .get_card_status()
> with some bitmask of filled fields, like for the .get_station()
> call. What would you prefer?
It's really a property of the _channel_.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* D-link USB Wlan Adapter DWA 160A crashes after a while
From: Adhari @ 2009-10-23 14:00 UTC (permalink / raw)
To: linux-wireless
Hello Everybody
I´m usind a D-link USB Wlan Adapter DWA 160A (ar9170usb) under Debian (kernel 2.6.31)
First when I connect this device, everything is fine. I have to do some measurements concerning Mipv6 (I´m only using Ipv6 here)
after a while using this W-lan Adapter (30 to 60mn) the system is not be able to receive any packets.
The only solution is to plug the USB interface out and to connect it again.
ifconfig down and up has no effect and sometimes rebooting either don´t correct this.
Any idea what the problem could be?
iwconfig wlan0 ==>
wlan1 IEEE 802.11abgn ESSID:"homenet"
Mode:Managed Frequency:2.447 GHz Access Point: Not-Associated
Tx-Power=20 dBm
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Ifconfig wlan0 ==>
wlan1 Link encap:Ethernet HWaddr 00:22:b0:71:a0:f3
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:1604 errors:0 dropped:0 overruns:0 frame:0
TX packets:1886 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:212557 (207.5 KiB) TX bytes:296773 (289.8 KiB)
My message logs:
[ 1017.309330] device wlan1 entered promiscuous mode
[ 1057.151376] device wlan1 left promiscuous mode
[ 1069.824693] device wlan1 entered promiscuous mode
[ 1109.161762] device wlan1 left promiscuous mode
[ 1123.640991] device wlan1 entered promiscuous mode
[ 1130.289499] device wlan1 left promiscuous mode
[ 1270.206139] usb 5-2: kill pending tx urbs.
[ 1276.393756] ADDRCONF(NETDEV_UP): wlan1: link is not ready
[ 1276.396863] r8169: eth0: link up
Thx
Hakim
^ permalink raw reply
* ath5k: no further txbuf available, dropping packet
From: Michael Buesch @ 2009-10-23 14:08 UTC (permalink / raw)
To: Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, Bob Copeland
Cc: linux-wireless
ath5k breaks in AP mode after some operation time and keeps throwing
this message:
[2096249.446071] ath5k phy0: no further txbuf available, dropping packet
Driver is yesterday's compat-wireless on 2.6.31.1
--
Greetings, Michael.
^ permalink raw reply
* Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211
From: Johannes Berg @ 2009-10-23 14:19 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, John Linville, Dan Williams
In-Reply-To: <20091022133425.317619132@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
On Thu, 2009-10-22 at 15:31 +0200, Holger Schurig wrote:
> +#ifdef CONFIG_LIBERTAS_WEXT
> dev->ethtool_ops = &lbs_ethtool_ops;
> dev->wireless_handlers = &lbs_handler_def;
> #endif
So here you make the wireless_handlers optional.
I still don't understand why you can't just replace only some of the
handlers, i.e. instead of doing this, simply do
- (iw_handler) lbs_set_freq, /* SIOCSIWFREQ */
+ (iw_handler) cfg80211_wext_siwfreq,
etc.
That's why those exist and are exported. And that way you don't need the
Kconfig at all, and can remove most of the wext code.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: NOHZ: local_softirq_pending 08
From: Tilman Schmidt @ 2009-10-23 14:27 UTC (permalink / raw)
To: Johannes Berg
Cc: Jarek Poplawski, David Miller, hidave.darkstar, linux-kernel,
tglx, linux-wireless, linux-ppp, netdev, paulus, isdn4linux,
i4ldeveloper, Karsten Keil
In-Reply-To: <1256304869.12174.20.camel@johannes.local>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Johannes Berg schrieb:
> On Fri, 2009-10-23 at 01:37 +0200, Tilman Schmidt wrote:
>
>> --- a/drivers/isdn/i4l/isdn_ppp.c
>> +++ b/drivers/isdn/i4l/isdn_ppp.c
>> @@ -1174,7 +1174,10 @@ isdn_ppp_push_higher(isdn_net_dev * net_dev, isdn_net_local * lp, struct sk_buff
>> #endif /* CONFIG_IPPP_FILTER */
>> skb->dev = dev;
>> skb_reset_mac_header(skb);
>> - netif_rx(skb);
>> + if (in_interrupt())
>> + netif_rx(skb);
>> + else
>> + netif_rx_ni(skb);
>
> So you've verified that the entire i4l stack can cope with being called
> twice on the same CPU, from different contexts?
What makes you think so?
Better yet, what do you propose?
Thanks,
Tilman
- --
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFK4b09Q3+did9BuFsRAqBvAKCbRI0iXQEyK3ztxkGHcqpbcceqbACgkagX
JF7nYd152ihp2uemIs/cB54=
=YOin
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: NOHZ: local_softirq_pending 08
From: Johannes Berg @ 2009-10-23 14:31 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Jarek Poplawski, David Miller, hidave.darkstar, linux-kernel,
tglx, linux-wireless, linux-ppp, netdev, paulus, isdn4linux,
i4ldeveloper, Karsten Keil
In-Reply-To: <4AE1BD3D.3020007@imap.cc>
[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]
On Fri, 2009-10-23 at 16:27 +0200, Tilman Schmidt wrote:
> >> --- a/drivers/isdn/i4l/isdn_ppp.c
> >> +++ b/drivers/isdn/i4l/isdn_ppp.c
> >> @@ -1174,7 +1174,10 @@ isdn_ppp_push_higher(isdn_net_dev * net_dev, isdn_net_local * lp, struct sk_buff
> >> #endif /* CONFIG_IPPP_FILTER */
> >> skb->dev = dev;
> >> skb_reset_mac_header(skb);
> >> - netif_rx(skb);
> >> + if (in_interrupt())
> >> + netif_rx(skb);
> >> + else
> >> + netif_rx_ni(skb);
> >
> > So you've verified that the entire i4l stack can cope with being called
> > twice on the same CPU, from different contexts?
>
> What makes you think so?
I thought I'd explained this in my other email. *sigh*
You're squelching a warning, which comes from the fact that you're
calling something that calls into netif_rx() with softirqs enabled. That
would seem to imply that potentially a softirq could at the same time
call into that code too.
Basically, what happens now is this:
disable softirqs
call into i4l/ppp
i4l/ppp code
call netif_rx()
more code
enable softirqs
You're changing it to
call into i4l/ppp
i4l/ppp code
call netif_rx_ni()
more code
so the entire chunks "i4l/ppp code" and "more code" are now no longer
protected against being interrupted by a softirq that runs the same
code, maybe for a different device, on the same CPU.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: ath5k: no further txbuf available, dropping packet
From: Bob Copeland @ 2009-10-23 14:36 UTC (permalink / raw)
To: Michael Buesch
Cc: Jiri Slaby, Nick Kossifidis, Luis R. Rodriguez, linux-wireless
In-Reply-To: <200910231608.18676.mb@bu3sch.de>
On Fri, Oct 23, 2009 at 10:08 AM, Michael Buesch <mb@bu3sch.de> wrote:
> ath5k breaks in AP mode after some operation time and keeps throwing
> this message:
>
> [2096249.446071] ath5k phy0: no further txbuf available, dropping packet
>
> Driver is yesterday's compat-wireless on 2.6.31.1
Thanks, I think there's a buffer leak. Also I believe the
queues are stopped in this case and never re-enabled.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH] net: Adjust softirq raising in __napi_schedule
From: Tilman Schmidt @ 2009-10-23 14:39 UTC (permalink / raw)
To: Johannes Berg
Cc: Jarek Poplawski, David Miller, hidave.darkstar, linux-kernel,
tglx, linux-wireless, linux-ppp, netdev, paulus, Michael Buesch,
Oliver Hartkopp
In-Reply-To: <1256200021.12174.11.camel@johannes.local>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Johannes Berg schrieb:
> On Wed, 2009-10-21 at 23:39 +0200, Jarek Poplawski wrote:
>
>> I'm not sure I can understand your question. This patch is mainly to
>> avoid using netif_rx()/netif_rx_ni() pair as a test of proper process
>> context handling; IMHO there're better tools for this (lockdep,
>> WARN_ON's).
>
> I'm saying that it seems to me, as indicated by the API (and without
> proof otherwise that's how it is) the networking layer needs to have
> packets handed to it with softirqs disabled.
Strange. Then what are the two separate functions netif_rx() and
netif_rx_ni() for?
> This really should be obvious. You're fixing the warning at the source
> of the warning, rather than the source of the problem.
Good idea. So please do tell us where the source of the problem is.
Thanks,
Tilman
- --
Tilman Schmidt E-Mail: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFK4cALQ3+did9BuFsRAnW8AKCP4ey+gT2RZBYpzx91PaXd11A/PwCgh35g
fhEbJs++1BRIQ3encV8fIm4=
=SSaA
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] cfg80211: allow driver to signal noise level
From: Bob Copeland @ 2009-10-23 14:41 UTC (permalink / raw)
To: Holger Schurig; +Cc: John Linville, Johannes Berg, linux-wireless
In-Reply-To: <200910201413.29734.hs4233@mail.mn-solutions.de>
On Tue, Oct 20, 2009 at 8:13 AM, Holger Schurig
<hs4233@mail.mn-solutions.de> wrote:
> Allows a WLAN driver to signal current noise level:
>
If the patch does survive in some form, can you change
the patch description to use "indicate" instead of
"signal?" My internal parser kept searching for the
missing verb until I realized we were talking about
signalling the noise level instead of the signal [or]
noise level :)
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply
* Re: [PATCH] net: Adjust softirq raising in __napi_schedule
From: Johannes Berg @ 2009-10-23 14:46 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Jarek Poplawski, David Miller, hidave.darkstar, linux-kernel,
tglx, linux-wireless, linux-ppp, netdev, paulus, Michael Buesch,
Oliver Hartkopp
In-Reply-To: <4AE1C00B.5010008@imap.cc>
[-- Attachment #1: Type: text/plain, Size: 505 bytes --]
On Fri, 2009-10-23 at 16:39 +0200, Tilman Schmidt wrote:
> Strange. Then what are the two separate functions netif_rx() and
> netif_rx_ni() for?
netif_rx_ni() disables preemption.
> > This really should be obvious. You're fixing the warning at the source
> > of the warning, rather than the source of the problem.
>
> Good idea. So please do tell us where the source of the problem is.
You use netif_rx_ni() instead of netif_rx() at whatever place that
causes this problem.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [REGRESSION] EAPOL Key Timeout 1/4
From: Ben Gamari @ 2009-10-23 15:24 UTC (permalink / raw)
To: linux-wireless, hostap
In-Reply-To: <65691fa00910210001w150d3d9dx2c0eb530c423e18c@mail.gmail.com>
I can also reproduce this with kernel 2.6.31. Looks like a regression.
What could be done to localize the issue?
- Ben
Excerpts from Daniel Rönnqvist's message of Wed Oct 21 03:01:07 -0400 2009:
> Hi again,
>
> when running hostapd (nl80211/bcm4306 on a ppc mac) with kernel 2.6.30
> it works kind of ok. One of my two laptops at home can connect and
> that's the one usually having better connection to any AP (stronger
> signal). The other one can connect but will get disconnected after a
> few minutes. Both are WinXP.
>
> When running with kernel 2.6.31 it wont work at all, the EAPOL keys
> are only rarely seen going out on wlan0 when I use tshark. If they go
> out they are answered by the client (verified with wireshark on
> client) but the response is never seen on the AP side. This was my
> problem when I first posted this issue.
>
> With and 2.6.32-rc I get kernel scheduler errors in my dmesg and soon
> after starting to send traffic over the wlan the machine crashes, it's
> an RC after all.
>
> So going back to 2.6.30 kind of solves my problem, except for one of
> my XP machines but I can't really blame hostapd for that, can I? ;)
>
> Just thought I would let you know if there's anyone having the same problem.
>
> BR,
> Daniel
>
> Den 15 oktober 2009 11.18 skrev Daniel Rönnqvist <kdronnqvist@gmail.com>:
> > 2009/10/14 Jouni Malinen <j@w1.fi>:
> >> On Wed, Oct 14, 2009 at 09:11:00AM +0200, Daniel Rönnqvist wrote:
> >>
> >>> * Is hostapd from git supposed to work with nl80211 (with a bcm4306 rev3)?
> >>
> >> I don't know about bcm4306, but at least the current snapshot of hostapd
> >> seems to be working fine with the ath9k driver.
> >>
> >>> * What does "deauthenticated due to local death" mean?
> >>
> >> It means that hostapd requested a station to be deauthenticated (in this
> >> case, I would assume it happened due to the WPA 4-way handshake timing
> >> out).
> >>
> >>> * The only messages i see with tshark during the authentication
> >>> process is "EAPOL Key" and some "LLC" messages coming from the client
> >>> MAC. The hostapd log says EAPOL Key Timeout on handshake 1/4. Is this
> >>> enough to guess what ballpark my problem is in?
> >>
> >> Have you verified that your client is receiving the EAPOL-Key message
> >> 1/4 and replying with 2/4?
> >>
> >> --
> >> Jouni Malinen PGP id EFC895FA
> >
> > I see EAPOL key coming in on the client and it is answering to the
> > correct MAC address, but the AP is always just saying EAPOL key
> > timeout on 1/4. On the AP side i do "tshark -i wlan0" and see the
> > EAPOL key going out but nothing is coming back. However, I am reading
> > up on the subject because as of now I must admit that I do not know
> > how this works. I should be able to give a better description of my
> > problem in a week or so (after becoming junior guru of wifi) :) I did
> > get this setup to work before but after upgrading to Debian testing it
> > just wont.
> >
> > BR,
> > Daniel
> >
^ permalink raw reply
* Re: [ath9k-devel] mac80211/ath9k/hostapd: Some clients unable to associate with AP
From: Björn Smedman @ 2009-10-23 15:27 UTC (permalink / raw)
To: Joerg Pommnitz, Will Dyson, Jouni Malinen, ath9k-devel,
linux-wireless
In-Reply-To: <133e8d7e0910230346q176fca69y55d8fb66b61d3fbf@mail.gmail.com>
Hi all,
It seems the problem is a typo in net/mac80211/tx.c that causes
injected frames from hostapd not to be associated with the correct ap
interface before going into ieee80211_tx_h_sequence(). This tiny patch
solves my problems (and looks reasonable to me in any case):
diff -urN compat-wireless-2009-10-21-before_seqnum_fix/net/mac80211/tx.c
compat-wireless-2009-10-21/net/mac80211/tx.c
--- compat-wireless-2009-10-21-before_seqnum_fix/net/mac80211/tx.c
2009-10-23 17:20:52.000000000 +0200
+++ compat-wireless-2009-10-21/net/mac80211/tx.c 2009-10-23
17:21:28.000000000 +0200
@@ -1445,7 +1445,7 @@
if (tmp_sdata->vif.type != NL80211_IFTYPE_AP)
continue;
if (compare_ether_addr(tmp_sdata->dev->dev_addr,
- hdr->addr2)) {
+ hdr->addr2) == 0) {
dev_hold(tmp_sdata->dev);
dev_put(sdata->dev);
sdata = tmp_sdata;
/Björn
2009/10/23 Björn Smedman <bjorn.smedman@venatech.se>
>
> Hi all,
> Thanks for your help. I will also keep my tcpdumps to myself for now.
> Is anybody working on a fix? I suspect it's a misunderstanding between hostapd and mac80211 about who should set the sequence number on injected frames, correct? Could you describe the outlines of the appropriate patch so I could experiment and verify that this is my problem?
> /Björn
> On Fri, Oct 23, 2009 at 11:15 AM, Joerg Pommnitz <pommnitz@yahoo.com> wrote:
>>
>> Since Jouni has confirmed my suspicion about the invalid sequence number I will refrain from spamming the list with tcpdumps.
>> Will, thanks for bringing me into the loop of this discussion!
>>
>> --
>> Regards
>> Joerg
>>
>>
>>
>
>
>
> --
> Venatech AB
> Ideon Innovation
> Ole Römers väg 12
> SE-22370 LUND
> Sweden
>
> +46 (0) 46 286 86 20
> info@venatech.se
> http://www.venatech.se
^ permalink raw reply
* Re: [RFC] libertas: monster-patch to make CFG/WEXT configurable
From: Holger Schurig @ 2009-10-23 15:38 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Dan Williams
In-Reply-To: <1256200291.12174.14.camel@johannes.local>
Johannes,
Little forword: it might be the case that you still have my
RTF/WIP cfg80211 patch in your head that removes all of
WEXT/MESH for good. I abandoned that concept.
> On Tue, 2009-10-20 at 08:35 +0200, Holger Schurig wrote:
> > > I really don't understand the point. Can't you just use the
> > > cfg80211 hooks and keep both functional at the same time?
> > > Just like orinoco does it uses cfg80211 only partially.
> >
> > I think I can't do this in a sane way.
>
> I don't see why not.
So, from your point of view it's ok if two different code pieces
to the same and copete for each other?
You think it's ok that two different code paths
report "connection" lost, once via an
wireless_send_event(priv->dev, SIOCGIWAP ...) and once via
cfg80211_disconnected()
You think it's ok to keep a list of scanned APs both in
cfg80211's bss list and in libertas own bss list?
You think it's okay to have an association worker (which heavily
relies on libertas' internal bss list) in libertas and at the
same time a cfg80211_ops' .connect() function that might do the
same, but quite differently?
Maybe you'll need more japanese tee :-)
> > Oh, and please don't compare libertas all the time with
> > orinoco. Orinoco is FULLMAC, libertas is HALFMAC.
> >
> > Because libertas firmware doesn't roam, it has to be done in
> > software. Libertas does this in assoc.c, partly in scan.c,
> > cmd.c and wext.c and even main.c. For example, libertas keeps
> > its own list of BSS entries, has code to select the best
> > matching BSS when it comes to associating ... things like
> > this.
>
> None of this code is relevant to mesh.
Right, but where did I say that this.
> > cfg80211 has this code too.
>
> No, it has no roaming etc.
Did I write that? Whatever you understood: with the libertas'
firmware, there's *NO* firmware command where you just
say "associate to SSID xzy" and then wait till the firmware
scanned and associated. You've to do this by yourself.
But of course cfg80211 a code-path where you say "iw XXX connect
ssid BLAH" and it calls the right things behind the scenes. And
libertas has a similar codepath --- just not in the firmware.
> > Having two competing implementations running in one driver is
> > a way to havoc.
>
> I'm not saying you should keep the old _station_ code, I'm just
> saying you should hook it up in a way that doesn't make it
> exclusive with mesh.
I'm not sure that I understand what you mean. I'm not
making "station code" (whatever that is) "exclusive with mesh"
(whatever that means).
Both libertas+WEXT and libertas+CFG80211 have code that allows
the libertas card to be a station. The code however is *VERY*
different, and I'm going so far to say this is a necessity. I
cannot use "one station code" and hook this to both WEXT and
CFG80211. Or maybe I can, but it would then be far from elegant.
And if you insist on doing that, then you'll have to do it by
yourself: in that minute I'll stop working on Libertas +
cfg80211.
> I'm not saying you should do mesh. I'm saying that instead of
> ripping out _all_ wext code you should just redirect/rewrite
> the wext handlers and call the cfg80211 ones, so that for
> _managed_ mode you get the new stuff, but for _mesh_ mode you
> keep the old code.
If I redirect WEXT handler --- why should I do this in the
driver, there is net/wireless/wext-compat.c, or?
And if would do it: then I couldn't rip out WEXT, because stuff
goes via some WEXT handlers. But ripping out WEXT completely out
of libertas is my long-term goal.
I don't want such a frankenstein in the code for eternity. I want
to use cfg80211 for everything: Station, Adhoc, Mesh, Monitor.
That's the end-goal. It's quite do-able, and very much cleaner
than any WEXT hookiness.
> Otherwise you're not doing the driver any good at all, since
> your patch then just means that both versions need to be
> maintained.
There's not much maintenance in the WEXT part, isn't it?
Currently we have this situation (with my latest RFC patch):
CONFIG_LIBERTAS_WEXT defined:
* basic cfg80211 handler, if someone wants to add deep-sleep,
or other functions where we don't want to enhance WEXT
* station via WEXT
* monitor mode via sysfs-file
* mesh via WEXT
* addhoc via WEXT
* scanning via WEXT
* associating via WEXT
* disconnect notification via WEXT
CONFIG_LIBERTAS_CFG80211 defined:
* "full" cfg80211 handler
* station via CFG80211
* monitor mode partly done (no packet injection)
* mesh not done at all, should be implemented via
.add_virtual_intf() by someone how has mesh-capable
devices
* adhoc not done, but I'll do that once wireless-testing
and ath5k can do adhoc again
* scanning via cfg80211
* associating via cfg80211
* disconnect notification via cfg80211_disconnected()
So, functionality-wise Libertas + cfg80211 is inferior, but on
the same side it's future-proof. And because
CONFIG_LIBERTAS_WEXT exist, I'm not taking any functionality
away for people that need them.
On the other side, the implementation for libertas + cfg80211 is
much cleaner and smaller than the old WEXT stuff.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH] libertas: remove handling for CMD_802_11_LED_GPIO_CTRL
From: Dan Williams @ 2009-10-23 15:45 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, John Linville
In-Reply-To: <200910220953.17995.hs4233@mail.mn-solutions.de>
On Thu, 2009-10-22 at 09:53 +0200, Holger Schurig wrote:
> > It's actually used by the OLPC folks; but right now there's
> > simply no mechanism to configure that ability via WEXT. Is
> > there some way to do this via the kernel LED framework instead
> > that libertas should be using?
>
> They use it?
>
> No one did bother to send a patch for the in-kernel Libertas
> driver during the last year. Sigh.
>
> Also, if they use it, they need a patch on top of what is now in
> the kernel, because the current in-kernel libertas driver has no
> code to issue the CMD_802_11_LED_GPIO_CTRL. That's why I removed
> it in the first place.
Because it was a WEXT private ioctl and I ripped those all out and told
them no. They still patch that (because there wasn't a LED framework at
the time) into the OLPC Gen 1 kernel trees. Not sure they are ever
going to jump to 2.6.32 or anything though. Just letting you know.
There's quite a few commands that only the OLPC stuff uses, but because
there was no usable userland interface for it (because we said no to
IWPRIV, and because debugfs is for debugging only) they just stuck with
IWPRIV and patched that in.
> It's O.K. for me to keep this code in (it doesn't harm), but a
> better approach would be
>
> a) use a new-style commands, a.k.a. lbs_cmd_with_response()
I was working on that and had converted all but 7 of the old-style
commands before you started the cfg80211 work, and now I figure after
you're done I'd go back and clean them up if they still exist.
> b) use the in-kernel LED support (as you said)
Yeah, that's obviously what should be done.
Dan
^ permalink raw reply
* Re: [PATCH] libertas: remove some references to IW_MODE_abc
From: Dan Williams @ 2009-10-23 15:46 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless, John Linville
In-Reply-To: <200910221415.38459.hs4233@mail.mn-solutions.de>
On Thu, 2009-10-22 at 14:15 +0200, Holger Schurig wrote:
> [PATCH] libertas: remove some references to IW_MODE_abc
>
> ... in pursue to quaff the wide-spread references to WEXT constants.
>
> When setting SNMP_MIB_OID_BSS_TYPE, wext.c can directly calculate the value
> the firmware wants.
>
> Reading of SNMP_MIB_OID_BSS_TYPE doesn't happen anywhere, so no need to
> convert the firmware value into WEXT values anyway.
>
> Signed-off-by: Holger Schurig <hs4233@mail.mn-solutions.de>
Acked-by: Dan Williams <dcbw@redhat.com>
> --- linux-wl.orig/drivers/net/wireless/libertas/cmd.c
> +++ linux-wl/drivers/net/wireless/libertas/cmd.c
> @@ -390,7 +390,7 @@
> switch (oid) {
> case SNMP_MIB_OID_BSS_TYPE:
> cmd.bufsize = cpu_to_le16(sizeof(u8));
> - cmd.value[0] = (val == IW_MODE_ADHOC) ? 2 : 1;
> + cmd.value[0] = val;
> break;
> case SNMP_MIB_OID_11D_ENABLE:
> case SNMP_MIB_OID_FRAG_THRESHOLD:
> @@ -443,13 +443,7 @@
>
> switch (le16_to_cpu(cmd.bufsize)) {
> case sizeof(u8):
> - if (oid == SNMP_MIB_OID_BSS_TYPE) {
> - if (cmd.value[0] == 2)
> - *out_val = IW_MODE_ADHOC;
> - else
> - *out_val = IW_MODE_INFRA;
> - } else
> - *out_val = cmd.value[0];
> + *out_val = cmd.value[0];
> break;
> case sizeof(u16):
> *out_val = le16_to_cpu(*((__le16 *)(&cmd.value)));
> --- linux-wl.orig/drivers/net/wireless/libertas/assoc.c
> +++ linux-wl/drivers/net/wireless/libertas/assoc.c
> @@ -1567,7 +1567,8 @@
> }
>
> priv->mode = assoc_req->mode;
> - ret = lbs_set_snmp_mib(priv, SNMP_MIB_OID_BSS_TYPE, assoc_req->mode);
> + ret = lbs_set_snmp_mib(priv, SNMP_MIB_OID_BSS_TYPE,
> + assoc_req->mode == IW_MODE_ADHOC ? 2 : 1);
>
> done:
> lbs_deb_leave_args(LBS_DEB_ASSOC, "ret %d", ret);
>
^ permalink raw reply
* Re: [PATCH] cfg80211: allow driver to signal noise level
From: Holger Schurig @ 2009-10-23 15:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: John Linville, linux-wireless
In-Reply-To: <1256305214.12174.27.camel@johannes.local>
> It's really a property of the _channel_.
Please don't be so terse. That's not helpful. If you don't have
time, then don't answer at all :-)
How would like to see an interface to get the noise out of the
driver?
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211
From: Dan Williams @ 2009-10-23 15:49 UTC (permalink / raw)
To: Johannes Berg; +Cc: Holger Schurig, linux-wireless, John Linville
In-Reply-To: <1256307572.12174.33.camel@johannes.local>
On Fri, 2009-10-23 at 16:19 +0200, Johannes Berg wrote:
> On Thu, 2009-10-22 at 15:31 +0200, Holger Schurig wrote:
>
> > +#ifdef CONFIG_LIBERTAS_WEXT
> > dev->ethtool_ops = &lbs_ethtool_ops;
> > dev->wireless_handlers = &lbs_handler_def;
> > #endif
>
> So here you make the wireless_handlers optional.
>
> I still don't understand why you can't just replace only some of the
> handlers, i.e. instead of doing this, simply do
>
> - (iw_handler) lbs_set_freq, /* SIOCSIWFREQ */
> + (iw_handler) cfg80211_wext_siwfreq,
>
> etc.
>
> That's why those exist and are exported. And that way you don't need the
> Kconfig at all, and can remove most of the wext code.
I *think* because Holger is trying to keep WEXT around for a bit,
because cfg80211 won't be mature enough yet (IMHO, I could be wrong) by
2.6.33, and because it doesn't support the OLPC-style mesh stuff and the
libertas monitor interface code. There's a few loose-ends that need to
be tied up before a cfg80211 conversion would completely replace the
functionality of the WEXT code.
Dan
^ permalink raw reply
* Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211
From: Holger Schurig @ 2009-10-23 15:56 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Linville, Dan Williams
In-Reply-To: <1256307572.12174.33.camel@johannes.local>
On Friday 23 October 2009 16:19:31 Johannes Berg wrote:
> On Thu, 2009-10-22 at 15:31 +0200, Holger Schurig wrote:
>
> > +#ifdef CONFIG_LIBERTAS_WEXT
> > dev->ethtool_ops = &lbs_ethtool_ops;
> > dev->wireless_handlers = &lbs_handler_def;
> > #endif
>
> So here you make the wireless_handlers optional.
>
> I still don't understand why you can't just replace only some
of the
> handlers, i.e. instead of doing this, simply do
>
> - (iw_handler) lbs_set_freq, /* SIOCSIWFREQ */
> + (iw_handler) cfg80211_wext_siwfreq,
>
> etc.
>
> That's why those exist and are exported. And that way you don't
> need the Kconfig at all, and can remove most of the wext code.
The Kconfig has *NOTHING* to do with mesh.
MESH should be implemented via add_virtual_intf() /
change_virtual_intf(). This code isn't there yet, mesh_dev is
always NULL in the CONFIG_LIBERTAS_CFG80211 case, so there's no
need to export anything to ethtool or WEXT.
And having cfg80211 + (mesh_dev != NULL) is something that
I cannot program, due to (sigh) missing hardware, time,
testing ability. Repeat rinse wash, repeat rinse wash ...
Okay, I now stop talking about this. Please talk with Dan about
the matter. He knows cfg80211 and libertas probably better than
I. Once you two have found a decision, I'm looking if I'm still
interested.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211
From: Johannes Berg @ 2009-10-23 16:04 UTC (permalink / raw)
To: Dan Williams; +Cc: Holger Schurig, linux-wireless, John Linville
In-Reply-To: <1256312995.2164.7.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 989 bytes --]
On Fri, 2009-10-23 at 08:49 -0700, Dan Williams wrote:
> > - (iw_handler) lbs_set_freq, /* SIOCSIWFREQ */
> > + (iw_handler) cfg80211_wext_siwfreq,
> >
> > etc.
> >
> > That's why those exist and are exported. And that way you don't need the
> > Kconfig at all, and can remove most of the wext code.
>
> I *think* because Holger is trying to keep WEXT around for a bit,
> because cfg80211 won't be mature enough yet (IMHO, I could be wrong) by
> 2.6.33, and because it doesn't support the OLPC-style mesh stuff and the
> libertas monitor interface code. There's a few loose-ends that need to
> be tied up before a cfg80211 conversion would completely replace the
> functionality of the WEXT code.
I just don't understand why he thinks that wext and cfg80211 need to be
mutually exclusive. cfg80211 has exported its handlers for exactly this
purpose, so that you could have everything that cfg80211 supports via
it, and everything else directly.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: D-link USB Wlan Adapter DWA 160A crashes after a while
From: Christian Lamparter @ 2009-10-23 16:19 UTC (permalink / raw)
To: Adhari; +Cc: linux-wireless
In-Reply-To: <005001ca53e9$307bde30$91739a90$@de>
On Friday 23 October 2009 16:00:32 Adhari wrote:
> Hello Everybody
>
> I´m usind a D-link USB Wlan Adapter DWA 160A (ar9170usb) under Debian (kernel 2.6.31)
>
> First when I connect this device, everything is fine. I have to do some measurements concerning Mipv6 (I´m only using Ipv6 here)
> after a while using this W-lan Adapter (30 to 60mn) the system is not be able to receive any packets.
>
>
> The only solution is to plug the USB interface out and to connect it again.
> ifconfig down and up has no effect and sometimes rebooting either don´t correct this.
>
> Any idea what the problem could be?
> [ 1270.206139] usb 5-2: kill pending tx urbs.
Is this some sort of trick question? Because you gave
the correct answer already in the "Subject" line?!
my suggestion:
1. get & compile compat-wireless (this will give you
an updated ar9170usb.ko driver. http://linuxwireless.org/en/users/Download )
2. replace the old two-stage firmware files with one-stage ar9170.fw
(link: http://wireless.kernel.org/en/users/Drivers/ar9170 )
Regards,
Chr
^ 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