* Re: [PATCH] net: Adjust softirq raising in __napi_schedule
From: Jarek Poplawski @ 2009-10-26 7:41 UTC (permalink / raw)
To: Johannes Berg
Cc: Tilman Schmidt, David Miller, hidave.darkstar, linux-kernel, tglx,
linux-wireless, linux-ppp, netdev, paulus, Michael Buesch,
Oliver Hartkopp
In-Reply-To: <1256309191.12174.51.camel@johannes.local>
On Fri, Oct 23, 2009 at 04:46:31PM +0200, Johannes Berg wrote:
> 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.
You wrote earlier:
> [...] the networking layer needs to have
> packets handed to it with softirqs disabled.
How disabling preemption can fix something which needs softirqs
disabled? Could you be more precise?
> > > 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.
This isn't a very precise description either.
Jarek P.
^ permalink raw reply
* Re: [PATCH] net: Adjust softirq raising in __napi_schedule
From: Johannes Berg @ 2009-10-26 7:44 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Tilman Schmidt, David Miller, hidave.darkstar, linux-kernel, tglx,
linux-wireless, linux-ppp, netdev, paulus, Michael Buesch,
Oliver Hartkopp
In-Reply-To: <20091026074126.GA6187@ff.dom.local>
[-- Attachment #1: Type: text/plain, Size: 474 bytes --]
On Mon, 2009-10-26 at 07:41 +0000, Jarek Poplawski wrote:
> > netif_rx_ni() disables preemption.
>
> You wrote earlier:
>
> > [...] the networking layer needs to have
> > packets handed to it with softirqs disabled.
>
> How disabling preemption can fix something which needs softirqs
> disabled? Could you be more precise?
No, I wrote that I didn't know. I suppose now that I looked at it I do
know, and only disabling preemption is required.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] net: Adjust softirq raising in __napi_schedule
From: Jarek Poplawski @ 2009-10-26 7:54 UTC (permalink / raw)
To: Johannes Berg
Cc: Tilman Schmidt, David Miller, hidave.darkstar, linux-kernel, tglx,
linux-wireless, linux-ppp, netdev, paulus, Michael Buesch,
Oliver Hartkopp
In-Reply-To: <1256543054.28230.6.camel@johannes.local>
On Mon, Oct 26, 2009 at 08:44:14AM +0100, Johannes Berg wrote:
> On Mon, 2009-10-26 at 07:41 +0000, Jarek Poplawski wrote:
>
> > > netif_rx_ni() disables preemption.
> >
> > You wrote earlier:
> >
> > > [...] the networking layer needs to have
> > > packets handed to it with softirqs disabled.
> >
> > How disabling preemption can fix something which needs softirqs
> > disabled? Could you be more precise?
>
> No, I wrote that I didn't know. I suppose now that I looked at it I do
> know, and only disabling preemption is required.
But netif_rx has preemption disabled most of the time (by hardirqs
disabling). So maybe disabling preemption isn't the main reason here
either?
Jarek P.
^ permalink raw reply
* Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211
From: Holger Schurig @ 2009-10-26 7:55 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-wireless
In-Reply-To: <1256315496.2164.47.camel@localhost.localdomain>
> Which should allow us to use cfg80211 by default, and then have
> only the LIBERTAS_MESH Kconfig option depend on WEXT. Maybe?
That would be a good idea. I always thought about a LIBERTAS_MESH
Kconfig right after persistcfg.c was added :-)
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH] net: Adjust softirq raising in __napi_schedule
From: Johannes Berg @ 2009-10-26 7:58 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Tilman Schmidt, David Miller, hidave.darkstar, linux-kernel, tglx,
linux-wireless, linux-ppp, netdev, paulus, Michael Buesch,
Oliver Hartkopp
In-Reply-To: <20091026075438.GB6187@ff.dom.local>
[-- Attachment #1: Type: text/plain, Size: 765 bytes --]
On Mon, 2009-10-26 at 07:54 +0000, Jarek Poplawski wrote:
> > No, I wrote that I didn't know. I suppose now that I looked at it I do
> > know, and only disabling preemption is required.
>
> But netif_rx has preemption disabled most of the time (by hardirqs
> disabling). So maybe disabling preemption isn't the main reason here
> either?
Not for netpoll though, which may or may not be relevant (if I were to
venture a guess I'd say it isn't and it disables preemption to be able
to do the softirq thing)
However, I lost track now of why we're discussing this.
Basically it boils down to using netif_rx() when in (soft)irq, and
netif_rx_ni() when in process context. That could just be an
optimisation, but it's a very valid one.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211
From: Holger Schurig @ 2009-10-26 7:59 UTC (permalink / raw)
To: Dan Williams; +Cc: Johannes Berg, linux-wireless, John Linville
In-Reply-To: <1256316179.2164.53.camel@localhost.localdomain>
> > Well if you want to push the mesh wext bits through to cfg80211
> > (temporarily) you wouldn't even need to depend on WEXT. I'd prefer,
> > however, to not do this, and just use the cfg80211 wext handlers in
> > libertas and depend on WEXT for now.
>
> Yeah, I think it's best to handle the mesh WEXT ioctls separately for
> now. There are really only 4 of them (get/set SSID, set channel, get
> mode) that matter for mesh. The rest of the ioctls that the mesh
> interface supports get redirected to the cfg80211 handlers because they
> aren't specific to mesh.
We can reduce this to 3, because get/set channel could
simply go via cfg80211.
I'm unsure if we still need an GIWRANGE for mesh, but probably not.
Dan, you once said that you converted the MESH firmware
calls to new style commands. Do you have those around? Maybe
I can re-work them if they don't apply anymore.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH 17/19] [RFC, v2] libertas: Kconfig entry for libertas+cfg80211
From: Holger Schurig @ 2009-10-26 8:04 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Dan Williams, Johannes Berg, linux-wireless, John Linville
In-Reply-To: <20091025033853.GA25873@infradead.org>
> How much does mesh actually get used? AFAICS it's a
> OLPC-specific one off.
A good question, I don't know no-one that uses mesh outside of
OLPC.
> So unless OLPC people come up and fix it why do people even
> bother with it?
In some way the OLPC people won't be bothered, they don't
follow linux-git or linux-wireless, they are stuck to some
old kernel (2.6.25 AFAIK). So they don't even notice :-)
However, they need MESH, so if I now rip MESH out completely
just because I change some configuration API, that would
bring more burden to them.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [RFC 1/3] mac80211: WIP - add operating BSSID to device configuration struct
From: Kalle Valo @ 2009-10-26 8:19 UTC (permalink / raw)
To: Luciano Coelho; +Cc: linux-wireless, juuso.oikarinen
In-Reply-To: <1255696042-28413-2-git-send-email-luciano.coelho@nokia.com>
Luciano Coelho <luciano.coelho@nokia.com> writes:
> Some chips need to know the BSSID that we are interested in before we start
> the association process. This patch adds an operating BSSID to the device
> configuration struct ieee80211_conf so that it can be passed to the driver
> when op_config is called.
>
> With this solution we also solve the problem of some chips that require
> an explicit disconnect command when disassociating.
You could explain here more how disconnection is possible. It's not
obvious from the commit log.
> + * @oper_bssid: BSSID on which we are operating; some chips need to know
> + * which BSSID we are "tuned" to in order to improve power management,
> + * coexistence with other technologies (such as Bluetooth) and other
> + * filtering issues.
"Tuned" is confusing here. Also I think it's enough to specify the
reasons in the commit log, and here just explain what the parameters
is used for. Maybe something like this:
* @oper_bssid: BSSID on which we are operating; some chips need to
* know the BSSID before association. If zero, there is no
* association established nor any requests of it.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC 1/3] mac80211: WIP - add operating BSSID to device configuration struct
From: Kalle Valo @ 2009-10-26 8:37 UTC (permalink / raw)
To: Luciano Coelho
Cc: ext Johannes Berg, linux-wireless@vger.kernel.org,
Oikarinen Juuso (Nokia-D/Tampere)
In-Reply-To: <4AE291DC.3010505@nokia.com>
Luciano Coelho <luciano.coelho@nokia.com> writes:
> ext Johannes Berg wrote:
>> On Fri, 2009-10-16 at 15:27 +0300, Luciano Coelho wrote:
>>
>>> + 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?
>
> As we discussed on IRC, it is really needed. We must always provide a
> BSSID when changing channels in preparation for an association.
I'm not sure about the must part here. Maybe we can workaround it by
using ff:ff:ff:ff:ff bssid during authentication and association and
send a new join command after association. But that's not a clean
solution.
> Also, I'm not 100% sure, but IIRC Kalle has mentioned that the
> at76c50x-usb card also needs this feature.
Yeah, at76c50x-usb also has a similar requirement. wl1251, wl1271 and
at76c50x-usb have these weird join/start commands which need bssid and
must be executed before any data transmission. I tried to workaround
the bssid requirement in at76c50x-usb a long time ago but failed. I
need to try it again.
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] net: Adjust softirq raising in __napi_schedule
From: Tilman Schmidt @ 2009-10-26 8:47 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: <1256543932.28230.9.camel@johannes.local>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Am 26.10.2009 09:58 schrieb Johannes Berg:
> On Mon, 2009-10-26 at 07:54 +0000, Jarek Poplawski wrote:
>
>>> No, I wrote that I didn't know. I suppose now that I looked at it I do
>>> know, and only disabling preemption is required.
>> But netif_rx has preemption disabled most of the time (by hardirqs
>> disabling). So maybe disabling preemption isn't the main reason here
>> either?
>
> Not for netpoll though, which may or may not be relevant (if I were to
> venture a guess I'd say it isn't and it disables preemption to be able
> to do the softirq thing)
>
> However, I lost track now of why we're discussing this.
The starting point were several reports of the kernel message:
NOHZ: local_softirq_pending 08
Originally most if not all of them came from wireless networking,
but I muddied the waters by adding to the mix a case involving ISDN.
You stated that all the solutions proposed so far were wrong, so
we're naturally turning to you for guidance on what the right
solution might be.
> Basically it boils down to using netif_rx() when in (soft)irq, and
> netif_rx_ni() when in process context. That could just be an
> optimisation, but it's a very valid one.
Hmmm. That seems to contradict your earlier statement to me that
simply replacing a call to netif_rx() by one to netif_rx_ni()
when not in interrupt context isn't a valid solution either.
What am I missing?
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
iD8DBQFK5WIXQ3+did9BuFsRAsj1AJ0e4VJ7Nsp69ROXCiT4oM/Q6lIpSwCfZvXS
4nV4tWTIzgk4IRlCt0CCF3Y=
=r15I
-----END PGP SIGNATURE-----
^ permalink raw reply
* Questions about cfg80211's cfg80211_connect_params->crypto settings
From: Holger Schurig @ 2009-10-26 8:47 UTC (permalink / raw)
To: linux-wireless
Hi,
I'm a but confused about what fields in "struct
cfg80211_connect_params" (now abbreviated as sme->)
are relevant for me.
sme->private
------------
Right now, my lbs_cfg_connect() code just tests
sme->crypto.cipher_group. It doesn't check or use sme->privacy.
and sme-> crypto.wpa_versions like they are redundant. Is this
correct?
Empirical it migth be correct, because I can successfully connect
to APs, but if "privacy" is redundant, should I prepare a patch
to get rid of it?
What is this? And how should my driver react to it's settings?
sme->crypto.wpa_versions
------------------------
Again I seems to be ok to ignore this variable and just check
sme->crypto.cipher_group. In practice this seems to work, but is
it correct?
What is this, what is the intented use of it? May I prepare a
patch to get rid of it?
sme->crypto.n_ciphers_pairwise, sme->crypto.ciphers_pairwise
------------------------------------------------------------
The same for sme->crypto.n_ciphers_pairwise. It is always 0 zero
for the WEP case and always 1 for the WPA/WPA2 case, so isn't it
redundant either? lbs_cfg_connect() ignores this, maybe it's
not needed at .connect() time anyway?
But what is it really, what is the intended use?
sme->crypto.n_akm_suites, sme->crypto.akm_suites
------------------------------------------------
In cfg80211.h, the kdoc help text for sme->crypo.akm_suites is
just "AKM suites" or "number of AKM suites", which keeps me as
confused as before.
What is this? And how should my driver react to it's settings?
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH] net: Adjust softirq raising in __napi_schedule
From: Johannes Berg @ 2009-10-26 8:56 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: <4AE56217.3040708@imap.cc>
[-- Attachment #1: Type: text/plain, Size: 1582 bytes --]
On Mon, 2009-10-26 at 10:47 +0200, Tilman Schmidt wrote:
> > However, I lost track now of why we're discussing this.
>
> The starting point were several reports of the kernel message:
>
> NOHZ: local_softirq_pending 08
>
> Originally most if not all of them came from wireless networking,
> but I muddied the waters by adding to the mix a case involving ISDN.
> You stated that all the solutions proposed so far were wrong, so
> we're naturally turning to you for guidance on what the right
> solution might be.
Right. Sorry about getting lost here.
> > Basically it boils down to using netif_rx() when in (soft)irq, and
> > netif_rx_ni() when in process context. That could just be an
> > optimisation, but it's a very valid one.
>
> Hmmm. That seems to contradict your earlier statement to me that
> simply replacing a call to netif_rx() by one to netif_rx_ni()
> when not in interrupt context isn't a valid solution either.
> What am I missing?
Well, I think you misunderstood me. It would be correct to do this, if
and only if the code that calls it doesn't need the extra guarantee.
Any code (say ISDN code) that calls netif_rx() is clearly assuming to
always be running in (soft)irq context, otherwise it couldn't call
netif_rx() unconditionally. Agree so far?
So now if you change the ISDN code to call netif_rx_ni(), you've changed
the assumption that the ISDN code makes -- that it is running in
(soft)irq context. Therefore, you need to verify that this is actually a
correct change, which is what I tried to say.
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: Luciano Coelho @ 2009-10-26 9:10 UTC (permalink / raw)
To: ext Kalle Valo
Cc: ext Johannes Berg, linux-wireless@vger.kernel.org,
Oikarinen Juuso (Nokia-D/Tampere)
In-Reply-To: <87pr8ah7pi.fsf@purkki.valot.fi>
ext Kalle Valo wrote:
> Luciano Coelho <luciano.coelho@nokia.com> writes:
>
>> ext Johannes Berg wrote:
>>> On Fri, 2009-10-16 at 15:27 +0300, Luciano Coelho wrote:
>>>
>>>> + 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?
>> As we discussed on IRC, it is really needed. We must always provide a
>> BSSID when changing channels in preparation for an association.
>
> I'm not sure about the must part here. Maybe we can workaround it by
> using ff:ff:ff:ff:ff bssid during authentication and association and
> send a new join command after association. But that's not a clean
> solution.
During one of our camps with TI, they told us that we must send the correct
BSSID, otherwise we are going to have some side-effects. At least BT coext will
be affected. And we have also seen the firmware send probe_reqs to
ff:ff:ff:ff:ff:ff, which was causing problems. The firmware is simply not
designed to do this. You probably also remember that we have recently removed
extra joins from the wl1251 code as well, because they were causing some
problems. So, from my point-of-view, this is unfortunately a must for wl1271. :(
--
Cheers,
Luca.
^ permalink raw reply
* Re: [RFC 1/3] mac80211: WIP - add operating BSSID to device configuration struct
From: Luciano Coelho @ 2009-10-26 9:11 UTC (permalink / raw)
To: ext Kalle Valo
Cc: linux-wireless@vger.kernel.org, Oikarinen Juuso (Nokia-D/Tampere)
In-Reply-To: <87tyxmh8i9.fsf@purkki.valot.fi>
ext Kalle Valo wrote:
> Luciano Coelho <luciano.coelho@nokia.com> writes:
>
>> Some chips need to know the BSSID that we are interested in before we start
>> the association process. This patch adds an operating BSSID to the device
>> configuration struct ieee80211_conf so that it can be passed to the driver
>> when op_config is called.
>>
>> With this solution we also solve the problem of some chips that require
>> an explicit disconnect command when disassociating.
>
> You could explain here more how disconnection is possible. It's not
> obvious from the commit log.
>
>> + * @oper_bssid: BSSID on which we are operating; some chips need to know
>> + * which BSSID we are "tuned" to in order to improve power management,
>> + * coexistence with other technologies (such as Bluetooth) and other
>> + * filtering issues.
>
> "Tuned" is confusing here. Also I think it's enough to specify the
> reasons in the commit log, and here just explain what the parameters
> is used for. Maybe something like this:
>
> * @oper_bssid: BSSID on which we are operating; some chips need to
> * know the BSSID before association. If zero, there is no
> * association established nor any requests of it.
>
Very good points. I'll fix this as part of my rework on these patches. Thanks
for your comments!
--
Cheers,
Luca.
^ permalink raw reply
* Re: Questions about cfg80211's cfg80211_connect_params->crypto settings
From: Johannes Berg @ 2009-10-26 9:22 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless
In-Reply-To: <200910260947.48365.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 778 bytes --]
On Mon, 2009-10-26 at 09:47 +0100, Holger Schurig wrote:
> I'm a but confused about what fields in "struct
> cfg80211_connect_params" (now abbreviated as sme->)
> are relevant for me.
>
>
> sme->private
> ------------
I think you mean "privacy". I'm not sure about it right now, would have
to dig, but maybe the answer to the others helps you?
> sme->crypto.wpa_versions
> sme->crypto.n_ciphers_pairwise, sme->crypto.ciphers_pairwise
> sme->crypto.n_akm_suites, sme->crypto.akm_suites
All these pretty much exist for hw that doesn't want to use the IE(s)
contained in the connect parameters. If you send an assoc request with
those IEs, you can safely ignore the parameters here. It's just there so
one doesn't have to parse the IEs.
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: Kalle Valo @ 2009-10-26 9:28 UTC (permalink / raw)
To: Luciano Coelho
Cc: ext Johannes Berg, linux-wireless@vger.kernel.org,
Oikarinen Juuso (Nokia-D/Tampere)
In-Reply-To: <4AE56792.8080401@nokia.com>
Luciano Coelho <luciano.coelho@nokia.com> writes:
>>> As we discussed on IRC, it is really needed. We must always provide a
>>> BSSID when changing channels in preparation for an association.
>>
>> I'm not sure about the must part here. Maybe we can workaround it by
>> using ff:ff:ff:ff:ff bssid during authentication and association and
>> send a new join command after association. But that's not a clean
>> solution.
>
> During one of our camps with TI, they told us that we must send the
> correct BSSID, otherwise we are going to have some side-effects. At
> least BT coext will be affected. And we have also seen the firmware
> send probe_reqs to ff:ff:ff:ff:ff:ff, which was causing problems.
> The firmware is simply not designed to do this.
So wl1271 sends a probe request in every join command?
> You probably also remember that we have recently removed extra joins
> from the wl1251 code as well, because they were causing some
> problems.
I think in wl1251 we would be able to workaround this with a careful
placement of join and disconnect commands, but it would be really
complicated. Having proper support in mac80211 is much better choice.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC 1/3] mac80211: WIP - add operating BSSID to device configuration struct
From: Luciano Coelho @ 2009-10-26 9:52 UTC (permalink / raw)
To: ext Kalle Valo
Cc: ext Johannes Berg, linux-wireless@vger.kernel.org,
Oikarinen Juuso (Nokia-D/Tampere)
In-Reply-To: <87ljiyh5bv.fsf@purkki.valot.fi>
ext Kalle Valo wrote:
> Luciano Coelho <luciano.coelho@nokia.com> writes:
>
>>>> As we discussed on IRC, it is really needed. We must always provide a
>>>> BSSID when changing channels in preparation for an association.
>>> I'm not sure about the must part here. Maybe we can workaround it by
>>> using ff:ff:ff:ff:ff bssid during authentication and association and
>>> send a new join command after association. But that's not a clean
>>> solution.
>> During one of our camps with TI, they told us that we must send the
>> correct BSSID, otherwise we are going to have some side-effects. At
>> least BT coext will be affected. And we have also seen the firmware
>> send probe_reqs to ff:ff:ff:ff:ff:ff, which was causing problems.
>> The firmware is simply not designed to do this.
>
> So wl1271 sends a probe request in every join command?
Not for every join command, but we observed some time ago, that the firmware was
sending broadcast probe_reqs on its own and we figured out that the issue was
related to the broadcast join commands. Again, we don't really know how the
firmware works, because we don't have access to the source, but according to TI
we can experience weird side-effects if we try to do it as you propose (and as
we were doing earlier).
>> You probably also remember that we have recently removed extra joins
>> from the wl1251 code as well, because they were causing some
>> problems.
>
> I think in wl1251 we would be able to workaround this with a careful
> placement of join and disconnect commands, but it would be really
> complicated. Having proper support in mac80211 is much better choice.
In wl1251 it *may* work. But not because the firmware supports it, but simply
because you may be lucky and not trigger any unexpected side-effect. In any
case, it would really be a workaround and I think it would be better to have
support for this on the stack, so we can do things as specified in the WiLink
firmware APIs. We probably have a slight chance of convincing TI to fix this in
future firmwares, but I'm almost sure it won't happen for the wl1251 and it is
very unlikely to happen for wl1271.
--
Cheers,
Luca.
^ permalink raw reply
* Re: Questions about cfg80211's cfg80211_connect_params->crypto settings
From: Holger Schurig @ 2009-10-26 12:11 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1256548953.28230.19.camel@johannes.local>
> > sme->crypto.wpa_versions
>
> > sme->crypto.n_ciphers_pairwise, sme->crypto.ciphers_pairwise
>
> > sme->crypto.n_akm_suites, sme->crypto.akm_suites
>
> All these pretty much exist for hw that doesn't want to use the
> IE(s) contained in the connect parameters. If you send an assoc
> request with those IEs, you can safely ignore the parameters
> here. It's just there so one doesn't have to parse the IEs.
Okay, then I conclude that it's save to ignore
sme->privacy
sme->crypto.wpa_versions
sme->crypto.n_ciphers_pairwise
sme->crypto.ciphers_pairwise
sme->crypto.n_akm_suites
sme->crypto.akm_suites
inside .connect() if I check sme->crypto.cipher_suite for
WLAN_CIPHER_SUITE_WEP40
WLAN_CIPHER_SUITE_WEP104
WLAN_CIPHER_SUITE_TKIP
WLAN_CIPHER_SUITE_CCMP
0 (meaning no encryption/WEP obfuscation)
lbs_cfg_connect() calls lbs_associate() which hands the complete
sme->ie to as a TLV to the firmware. However, I don't do any
parsing of sme->ie by myself.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: [PATCH] mac80211: fix for incorrect sequence number on hostapd injected frames
From: Michael Buesch @ 2009-10-26 12:18 UTC (permalink / raw)
To: Johannes Berg
Cc: Björn Smedman, linville, linux-wireless, Jouni Malinen,
Joerg Pommnitz, Will Dyson
In-Reply-To: <1256497156.28230.0.camel@johannes.local>
On Sunday 25 October 2009 19:59:16 Johannes Berg wrote:
> On Sat, 2009-10-24 at 20:55 +0200, Björn Smedman wrote:
> > When hostapd injects a frame, e.g. an authentication or association
> > response, mac80211 looks for a suitable access point virtual interface
> > to associate the frame with based on its source address. This makes it
> > possible e.g. to correctly assign sequence numbers to the frames.
> >
> > A small typo in the ethernet address comparison statement caused a
> > failure to find a suitable ap interface. Sequence numbers on such
> > frames where therefore left unassigned causing some clients
> > (especially windows-based 11b/g clients) to reject them and fail to
> > authenticate or associate with the access point. This patch fixes the
> > typo in the address comparison statement.
> >
> > Signed-off-by: Björn Smedman <bjorn.smedman@venatech.se>
>
> Reviewed-by: Johannes Berg <johannes@sipsolutions.net>
>
> and Cc: stable@kernel.org I think
>
> > ---
> > diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
> > index db4bda6..eaa4118 100644
> > --- a/net/mac80211/tx.c
> > +++ b/net/mac80211/tx.c
> > @@ -1445,7 +1445,7 @@ static void ieee80211_xmit(struct
> > ieee80211_sub_if_data *sdata,
> > 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;
> >
>
>
The following patch cleanly applies to 2.6.31.5-stable and is tested.
Index: linux-2.6.31/net/mac80211/tx.c
===================================================================
--- linux-2.6.31.orig/net/mac80211/tx.c 2009-10-26 09:15:20.000000000 +0100
+++ linux-2.6.31/net/mac80211/tx.c 2009-10-26 09:16:35.000000000 +0100
@@ -1478,7 +1478,7 @@
if (sdata->vif.type != NL80211_IFTYPE_AP)
continue;
if (compare_ether_addr(sdata->dev->dev_addr,
- hdr->addr2)) {
+ hdr->addr2) == 0) {
dev_hold(sdata->dev);
dev_put(odev);
osdata = sdata;
--
Greetings, Michael.
^ permalink raw reply
* Re: Questions about cfg80211's cfg80211_connect_params->crypto settings
From: Johannes Berg @ 2009-10-26 12:22 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless
In-Reply-To: <200910261311.47164.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
On Mon, 2009-10-26 at 13:11 +0100, Holger Schurig wrote:
> inside .connect() if I check sme->crypto.cipher_suite for
>
> WLAN_CIPHER_SUITE_WEP40
> WLAN_CIPHER_SUITE_WEP104
> WLAN_CIPHER_SUITE_TKIP
> WLAN_CIPHER_SUITE_CCMP
> 0 (meaning no encryption/WEP obfuscation)
But why would you look at that? It sounds like you want sme->privacy to
know whether to select an AP that advertises privacy or not?
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: Questions about cfg80211's cfg80211_connect_params->crypto settings
From: Holger Schurig @ 2009-10-26 12:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <1256559734.28230.23.camel@johannes.local>
> > inside .connect() if I check sme->crypto.cipher_suite for
> >
> > WLAN_CIPHER_SUITE_WEP40
> > WLAN_CIPHER_SUITE_WEP104
> > WLAN_CIPHER_SUITE_TKIP
> > WLAN_CIPHER_SUITE_CCMP
> > 0 (meaning no encryption/WEP obfuscation)
>
> But why would you look at that? It sounds like you want
sme->privacy to
> know whether to select an AP that advertises privacy or not?
Libertas' firmware doesn't have a capability of to "select an AP
that advertises privacy". So in practice it's wpa_supplicant that
selects this, because pure iw/cfg80211 can't select an AP for
me.
My connect method does this:
lbs_cfg_connect:
if (sme->bssid set) {
# I need a full cfg80211_bss entry, because I can only
# associate to a specific bss via CMD_802_11_ASSOCIATE
# and I need
# bss->capability
# bss->bssid
# bss->get_ie(WLAN_EID_SSID)
# bss->channel
# bss->rates
bss = cfg80211_get_bss()
} else {
error_out
}
clear_local_wep_key_copy
switch (sme->cryto.cipher_group) {
case WEP40, WEP104:
store_key_keyidx_locally
set_wep_keys
enable_wep_in_lbs_mac
disable_rsn
break;
case no_encryption:
case WPA, WPA2:
remove_wep_keys
disable_wep_in_lbs_mac
clear_wpa_wpa2_unicast_multicast_key
unless no_encryption:
enable_rsn
}
build_and_submit_set_authtype_command_for_the_firmware
build_and_submit_associate_command_for_the_firmware
You see, nowhere do I actually need sme->privacy, all info is in
sme->crypto.cipher_group.
However, this current setup makes "iw abc connect SSID"
non-working with libertas. It would work with libertas if I
would use the .auth/.assoc API, because then net/wireless/sme.c
would scan for me. But in the .connect API case, it doesn't do
this.
But information I get in the .connect() call aren't sufficuent
for the Libertas firmware interface, I need more data, which I
can get from a cfg80211_bss entry.
One possiblity is that net/wireless/sme.c get's more general and
does scan in the .connect() case, too.
Or I could substitute the "error_out" with a local scan, and then
select the "best" AP from the bss list. I fear however that such
a selection function might already be somewhere inside
net/wireless/*.c, I'll need to search for that.
--
http://www.holgerschurig.de
^ permalink raw reply
* Re: Questions about cfg80211's cfg80211_connect_params->crypto settings
From: Johannes Berg @ 2009-10-26 13:03 UTC (permalink / raw)
To: Holger Schurig; +Cc: linux-wireless
In-Reply-To: <200910261359.13658.hs4233@mail.mn-solutions.de>
[-- Attachment #1: Type: text/plain, Size: 1523 bytes --]
On Mon, 2009-10-26 at 13:59 +0100, Holger Schurig wrote:
> lbs_cfg_connect:
> if (sme->bssid set) {
> # I need a full cfg80211_bss entry, because I can only
> # associate to a specific bss via CMD_802_11_ASSOCIATE
> # and I need
> # bss->capability
> # bss->bssid
> # bss->get_ie(WLAN_EID_SSID)
> # bss->channel
> # bss->rates
> bss = cfg80211_get_bss()
You need sme->privacy here.
> However, this current setup makes "iw abc connect SSID"
> non-working with libertas. It would work with libertas if I
> would use the .auth/.assoc API, because then net/wireless/sme.c
> would scan for me. But in the .connect API case, it doesn't do
> this.
>
> But information I get in the .connect() call aren't sufficuent
> for the Libertas firmware interface, I need more data, which I
> can get from a cfg80211_bss entry.
>
> One possiblity is that net/wireless/sme.c get's more general and
> does scan in the .connect() case, too.
>
> Or I could substitute the "error_out" with a local scan, and then
> select the "best" AP from the bss list. I fear however that such
> a selection function might already be somewhere inside
> net/wireless/*.c, I'll need to search for that.
There isn't really. It _might_ be possible to further abstract this out,
but that means we need to _first_ be able to advertise device roaming
capabilities so that we _don't_ select a specific BSS for devices that
want to handle roaming like iwm.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Only device wlan1 but no connection Fritz!WLAN USB stick N2.4
From: Ed Vaessen @ 2009-10-26 13:17 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <4AE1FE7F.2090309@gmail.com>
I have a Fritz!Box Fon WLAN 7170 as router and try to connect wireless to
it with the Fritz!WLAN USB N2.4 stick using the compat-wireless software.
Without succes so far.
Software: yesterdays bleeding edge tarball: compat-wireless-2.6.tar.bz2
Kernel: Ubuntu 9.04 2.6.28-16-generic
PC: Athec L51A10
Firmware: ar9170.fw put in /lib/firmware
The software compiles without problem and installs the driver after reboot:
sudo lsmod | grep 9170 gives:
ar9170usb 63624 0
led_class 12036 1 ar9170usb
ath 17024 1 ar9170usb
mac80211 218160 1 ar9170usb
cfg80211 135240 3 ar9170usb,ath,mac80211
After inserting the usb stick, this is shown in /var/log/messages
Oct 25 15:37:00 vaessen-laptop kernel: [ 301.480049] usb 1-1: new high
speed USB device using ehci_hcd and address 5
Oct 25 15:37:00 vaessen-laptop kernel: [ 301.643507] usb 1-1:
configuration #1 chosen from 1 choice
Oct 25 15:37:00 vaessen-laptop kernel: [ 301.702461] Initializing USB Mass
Storage driver...
Oct 25 15:37:00 vaessen-laptop kernel: [ 301.702650] scsi4 : SCSI
emulation for USB Mass Storage devices
Oct 25 15:37:00 vaessen-laptop kernel: [ 301.702803] usbcore: registered
new interface driver usb-storage
Oct 25 15:37:00 vaessen-laptop kernel: [ 301.702808] USB Mass Storage
support registered.
Oct 25 15:37:05 vaessen-laptop kernel: [ 306.709252] scsi 4:0:0:0: CD-ROM
FRITZ! WLAN selfinstall 1.00 PQ: 0 ANSI: 0 CCS
Oct 25 15:37:05 vaessen-laptop kernel: [ 306.722276] sr1: scsi3-mmc drive:
52x/52x cd/rw xa/form2 cdda tray
Oct 25 15:37:05 vaessen-laptop kernel: [ 306.723067] sr 4:0:0:0: Attached
scsi generic sg2 type 5
Oct 25 15:38:38 vaessen-laptop kernel: [ 399.349605] usb 1-1: USB
disconnect, address 5
Oct 25 15:38:39 vaessen-laptop kernel: [ 400.608057] usb 1-1: new high
speed USB device using ehci_hcd and address 6
Oct 25 15:38:39 vaessen-laptop kernel: [ 400.771795] usb 1-1:
configuration #1 chosen from 1 choice
Oct 25 15:38:39 vaessen-laptop kernel: [ 400.888063] usb 1-1: reset high
speed USB device using ehci_hcd and address 6
Oct 25 15:38:40 vaessen-laptop kernel: [ 402.044043] usb 1-1: firmware:
requesting ar9170.fw
Oct 25 15:38:41 vaessen-laptop kernel: [ 402.465806] Registered led
device: ar9170-phy1::tx
Oct 25 15:38:41 vaessen-laptop kernel: [ 402.465846] Registered led
device: ar9170-phy1::assoc
Oct 25 15:38:41 vaessen-laptop kernel: [ 402.465851] usb 1-1: Atheros
AR9170 is registered as 'phy1'
Oct 25 15:38:41 vaessen-laptop kernel: [ 402.471136] udev: renamed network
interface wlan0 to wlan1
It seems the firmware is installed.
Command iwconfig:
lo no wireless extensions.
eth0 no wireless extensions.
pan0 no wireless extensions.
wlan1 IEEE 802.11bg Mode:Managed Access Point: Not-Associated
Tx-Power=0 dBm
Retry long limit:7 RTS thrff Fragment thrff
Power Managementff
Command sudo lshw -C network gives for the wireless this information:
*-network:1 DISABLED
description: Wireless interface
physical id: 2
bus info: usb@1:1
logical name: wlan1
serial: 00:1f:3f:09:2d:40
capabilities: ethernet physical wireless
configuration: broadcast=yes driver=ar9170usb
driverversion=2.6.28-16-generic firmware=N/A link=yes multicast=yes
wireless=IEEE 802.11bg
This 'firmware=N/A' puzzles me.
I used System->Administration->Network Tools but cannot ping the Fritz!Box
router
The interface information says that wireless interface wlan1 is inactive.
How do I make it active?
^ permalink raw reply
* Re: "Reserved instruction in kernel code" on ath9k insertion
From: Luis R. Rodriguez @ 2009-10-26 13:17 UTC (permalink / raw)
To: Tomasz Chmielewski; +Cc: linux-wireless
In-Reply-To: <4AE35A9E.8000507@wpkg.org>
On Sat, Oct 24, 2009 at 12:50 PM, Tomasz Chmielewski <mangoo@wpkg.org> wrote:
> When I do "modprobe ath9k" on ASUS-WL-500gP (MIPS) with _ath5k_ card (so, no
> ath9k hardware), it says "Reserved instruction in kernel code" - is it
> expected?
No.
> The kernel is 2.6.31.1.
>
>
> # modprobe ath9k
> [ 165.440000] Reserved instruction in kernel code[#1]:
> [ 165.440000] Cpu 0
> [ 165.440000] $ 0 : 00000000 1000dc00 00000000 00000000
> [ 165.440000] $ 4 : c1135b20 00000001 c044e69c ffffffff
> [ 165.440000] $ 8 : 0000000a 8101f6d8 ffffffe0 0000002b
> [ 165.440000] $12 : 00000e44 00000006 80333ae8 5f657361
> [ 165.440000] $16 : 00000001 c1135ca4 80370000 81418000
> [ 165.440000] $20 : 00000000 00000000 00000000 004fe008
> [ 165.440000] $24 : 00000010 c1115118
> [ 165.440000] $28 : 81da6000 81da7ea8 7febead8 81418014
> [ 165.440000] Hi : 00000000
> [ 165.440000] Lo : 00000000
> [ 165.440000] epc : c044e694 0xc044e694
> [ 165.440000] Not tainted
This says not tainted.
> [ 165.440000] ra : 81418014 ath9k_init+0x14/0xa4 [ath9k]
So ath9k_init() should run whether you have the hardware or not since
you modprobed' ath9k. For ath9k this consists of running:
ath_rate_control_register()
ath9k_debug_create_root()
ath_pci_init()
ath_ahb_init()
debugfs stuff should be a no-op unless you have enabled
CONFIG_ATH9k_DEBUG. So even ath_pci_init() should succeed even if you
do not have any of the claimed PCI devices, the only way that fails is
if pci_register_driver() fails.
More below.
> [ 165.440000] Status: 1000dc03 KERNEL EXL IE
> [ 165.440000] Cause : 80800028
> [ 165.440000] PrId : 00029006 (Broadcom BCM3302)
> [ 165.440000] Modules linked in: ath9k(+) aes_generic tun sch_sfq cls_fw
> sch_htb ipt_MASQUERADE iptable_nat nf_nat xt_MARK iptable_mangle ipt_ULOG
> xt_recent nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_tcpudp
> iptable_filter ip_tables x_tables arc4 ecb ath5k mac80211 ath ohci_hcd
> cfg80211 uhci_hcd
> [ 165.440000] Process modprobe (pid: 1285, threadinfo=81da6000,
> task=81dc0048, tls=2aad96f0)
> [ 165.440000] Stack : 00000000 00000000 c1049988 000002a0 00000001 8000cda4
> 80330000 c1135ca4
> [ 165.440000] 0041ee08 2ac50000 005021a8 00000000 8004d59c 0029e597
> 0041ee08 2ac50000
> [ 165.440000] 00000001 c1135ca4 0041ee08 2ac50000 005021a8 8005fc84
> 0029f000 00000002
> [ 165.440000] 00408228 00400de0 004f1400 2aad8f08 00408228 00400de0
> 004f1400 2aad8f08
> [ 165.440000] 800035f0 800035f0 005021a8 004ff648 004fe008 00000000
> 00401090 00000000
> [ 165.440000] ...
> [ 165.440000] Call Trace:
> [ 165.440000] [<8000cda4>] do_one_initcall+0x6c/0x204
> [ 165.440000] [<8004d59c>] blocking_notifier_call_chain+0x14/0x20
> [ 165.440000] [<8005fc84>] sys_init_module+0xe8/0x214
> [ 165.440000] [<800035f0>] stack_done+0x20/0x3c
> [ 165.440000] [<800035f0>] stack_done+0x20/0x3c
> [ 165.440000]
> [ 165.440000]
> [ 165.440000] Code: 00000000 00000000 00000000 <00003009> 005196a8
> 005196a8 00000002 00000000 005166b0
> [ 165.440000] Disabling lock debugging due to kernel taint
But this says kernel taint.
> Segmentation fault
> #
So I'm not 100% sure but I believe "Reserved instruction in kernel
code" means some instruction is trying to be run on your mips board
for which your actual CPU has no support for, which could happen if
you cross compiled code to your target with an incorrect toolchain. At
least that is how someone interpreted this on some old madwifi ticket
when someone ran into this [1]. The failure actually comes from the
mips do_ri() call [2] but cannot confirm whether or not the
interpretation is correct. To confirm you may want to check with the
linux-mips list.
[1] http://madwifi-project.org/ticket/994
[2] http://lxr.linux.no/#linux+v2.6.31/arch/mips/kernel/traps.c#L806
Luis
^ permalink raw reply
* Re: "Reserved instruction in kernel code" on ath9k insertion
From: Tomasz Chmielewski @ 2009-10-26 13:27 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless
In-Reply-To: <43e72e890910260617n6efbd260gcafbf5d1d2c84e23@mail.gmail.com>
Luis R. Rodriguez wrote:
> On Sat, Oct 24, 2009 at 12:50 PM, Tomasz Chmielewski <mangoo@wpkg.org> wrote:
>> When I do "modprobe ath9k" on ASUS-WL-500gP (MIPS) with _ath5k_ card (so, no
>> ath9k hardware), it says "Reserved instruction in kernel code" - is it
>> expected?
>
> No.
>
>> The kernel is 2.6.31.1.
>>
>>
>> # modprobe ath9k
>> [ 165.440000] Reserved instruction in kernel code[#1]:
>> [ 165.440000] Cpu 0
>> [ 165.440000] $ 0 : 00000000 1000dc00 00000000 00000000
>> [ 165.440000] $ 4 : c1135b20 00000001 c044e69c ffffffff
>> [ 165.440000] $ 8 : 0000000a 8101f6d8 ffffffe0 0000002b
>> [ 165.440000] $12 : 00000e44 00000006 80333ae8 5f657361
>> [ 165.440000] $16 : 00000001 c1135ca4 80370000 81418000
>> [ 165.440000] $20 : 00000000 00000000 00000000 004fe008
>> [ 165.440000] $24 : 00000010 c1115118
>> [ 165.440000] $28 : 81da6000 81da7ea8 7febead8 81418014
>> [ 165.440000] Hi : 00000000
>> [ 165.440000] Lo : 00000000
>> [ 165.440000] epc : c044e694 0xc044e694
>> [ 165.440000] Not tainted
>
> This says not tainted.
(...)
>> [ 165.440000] Disabling lock debugging due to kernel taint
>
> But this says kernel taint.
Yep, I saw this as well.
About every oops or panic on this hardware says "Disabling lock
debugging due to kernel taint", no idea why.
--
Tomasz Chmielewski
http://wpkg.org
^ 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