* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 14:13 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <20091029.065336.119302168.davem@davemloft.net>
On Thursday 29 October 2009 14:53:36 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Thu, 29 Oct 2009 14:35:54 +0100
>
> > This is your responsibility to deal with your downstream maintainers,
> > not mine and since you have accepted John's patch I'm asking you to
> > revert rt2800pci patch from your tree.
>
> That's not how it works Bart. You should not be asking 'me' to do
> anything on wireless bits, there is absolutely no reason to bypass
> John in the workflow.
John has chosen to ignore my concerns and you are sending me back to him?
I like ping-pong but as a sport.
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 14:14 UTC (permalink / raw)
To: Pekka Enberg; +Cc: David Miller, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <84144f020910290652n2e75827dk698b238b6bd1cbed@mail.gmail.com>
Hi,
On Thursday 29 October 2009 14:52:50 Pekka Enberg wrote:
> Hi Bart,
>
> On Thu, Oct 29, 2009 at 3:35 PM, Bartlomiej Zolnierkiewicz
> <bzolnier@gmail.com> wrote:
> >> I'm saying that you should work with John to have him send a revert or
> >> whatever to me.
> >
> > This is your responsibility to deal with your downstream maintainers,
> > not mine and since you have accepted John's patch I'm asking you to
> > revert rt2800pci patch from your tree.
>
> So why don't you just send a patch to fix it up? I see you're doing
"git revert a9b3a9f"
done.
Dave, if you have problems with executing the command locally I'll be
happy to supply you with the patch.
> lots of cleanups to the staging drivers, why not direct some of that
> energy to the drivers/net/wireless ones?
When did we start to apply "fix it yourself" rule instead of "submitter
should fix it" one to the _new_ code..
rt2800 drivers have their maintainers and I would like to know what they
are doing besides complaining about users and staging tree..
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: David Miller @ 2009-10-29 14:20 UTC (permalink / raw)
To: bzolnier; +Cc: linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <200910291513.54326.bzolnier@gmail.com>
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Thu, 29 Oct 2009 15:13:54 +0100
> John has chosen to ignore my concerns and you are sending me back to him?
That's exactly why I won't overreach his maintainership role,
because you're inability to interact with and work with the
wireless maintainer isn't my problem.
In case you're concerned, I actually agree with John and others
on this issue, and disagree with your position.
So even if I felt it legitimate to overreach John, I still wouldn't
make the change you are requesting in this case.
Does it really eat you so hard when someone disagrees with you?
That's not going to work in the long term Bart, if John disagrees with
you he's the maintainer of wireless and that's it. You're going to
have to learn to work with people, and not just automatically go to a
"higher power" as soon as someone disagrees with you.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: David Miller @ 2009-10-29 14:21 UTC (permalink / raw)
To: bzolnier; +Cc: penberg, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <200910291514.40318.bzolnier@gmail.com>
From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Date: Thu, 29 Oct 2009 15:14:40 +0100
> Dave, if you have problems with executing the command locally I'll be
> happy to supply you with the patch.
This is not the issue.
The issue is that John disagrees with you can you can't handle
that.
So instead of continuing to discuss things with him and the
other wireless folks, you want me to just overreach everybody
and revert someone else's work.
I'm not going to do that sorry, learn how to work with the
wireless people instead.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Johannes Berg @ 2009-10-29 14:24 UTC (permalink / raw)
To: David Miller; +Cc: bzolnier, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <20091029.072001.153801635.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 392 bytes --]
On Thu, 2009-10-29 at 07:20 -0700, David Miller wrote:
> In case you're concerned, I actually agree with John and others
> on this issue, and disagree with your position.
In this particular case, I think it makes more sense to duplicate the
code _especially_ because it's not working yet. That frees people
hacking on it of having to worry about breaking other devices.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 14:34 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <20091029.072001.153801635.davem@davemloft.net>
On Thursday 29 October 2009 15:20:01 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Thu, 29 Oct 2009 15:13:54 +0100
>
> > John has chosen to ignore my concerns and you are sending me back to him?
>
> That's exactly why I won't overreach his maintainership role,
> because you're inability to interact with and work with the
> wireless maintainer isn't my problem.
>
> In case you're concerned, I actually agree with John and others
> on this issue, and disagree with your position.
>
> So even if I felt it legitimate to overreach John, I still wouldn't
> make the change you are requesting in this case.
Sorry but you are also wrong then and you are just in the way of progress.
> Does it really eat you so hard when someone disagrees with you?
>
> That's not going to work in the long term Bart, if John disagrees with
> you he's the maintainer of wireless and that's it. You're going to
> have to learn to work with people, and not just automatically go to a
> "higher power" as soon as someone disagrees with you.
I'm not going to waste my time on stupid or hopeless things just because you
or John like to call themselves "maintainers".
If Red Hat or some other company wants to hire me and pay me for spinning
inside networking bureaucracy than please contact me in private but as
long as it is my own time I'll just do what I think makes sense on technical
merits and not on who is the "maintainer" of this or that..
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Michael Buesch @ 2009-10-29 14:39 UTC (permalink / raw)
To: David Miller
Cc: bzolnier, penberg, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <20091029.072101.109209962.davem@davemloft.net>
On Thursday 29 October 2009 15:21:01 David Miller wrote:
> The issue is that John disagrees with you can you can't handle
> that.
>
> So instead of continuing to discuss things with him and the
> other wireless folks, you want me to just overreach everybody
> and revert someone else's work.
In the end this results in the driver maintainer being forced to maintain
code and handle bugreports for code that he disagrees with in the first place.
This is unacceptable and has to be resolved in some way.
If it's not possible to get it reverted through John (for whatever reason),
you're in charge to help the actual code maintainer out.
> I'm not going to do that sorry, learn how to work with the
> wireless people instead.
This is not the problem.
The problem is that stuff is merged without ack from the maintainer
and it's virtually impossible to get the stuff reverted. The only real
way for the maintainer to resolve this is 1) live with it or 2) fix it.
And that's bad, because it completely invalidates his priority queue.
Just like you must not bypass John, the driver maintainers must not be bypassed, too.
The quality control does _only_ work if nobody in the chain is bypassed.
But in this situation the quality control did already fail and it should be
tried hard to resolve (=revert) the situation instead of pointing at John.
--
Greetings, Michael.
^ permalink raw reply
* RE: [PATCH] libertas: remove internal buffers from GSPI driver
From: George Shore @ 2009-10-29 14:27 UTC (permalink / raw)
To: Andrey Yurovsky, linux-wireless; +Cc: libertas-dev, sebatian, dcbw
In-Reply-To: <1256687501-8636-1-git-send-email-andrey@cozybit.com>
> -----Original Message-----
> From: linux-wireless-owner@vger.kernel.org [mailto:linux-wireless-
> owner@vger.kernel.org] On Behalf Of Andrey Yurovsky
> Sent: 27 October 2009 23:52
> To: linux-wireless@vger.kernel.org
> Cc: libertas-dev@lists.infradead.org; sebatian@breakpoint.cc;
> dcbw@redhat.com; Andrey Yurovsky
> Subject: [PATCH] libertas: remove internal buffers from GSPI driver
>
> This patch removes the internal command and data buffers that the GSPI
> driver
> maintained and instead relies on the Libertas core to synchronize
access
> to the command and data ports as with the other interface drivers.
This
> cleanup reduces the GSPI driver's memory footprint and should improve
> performance by removing the need to copy to these internal buffers.
> This also simplifies the bottom half of the interrupt handler.
>
> This is an incremental cleanup: after removing the redundant buffers,
we
> can further improve the driver to use a threaded IRQ handler instead
of
> maintaining its own thread. However I would like a few folks to test
> the buffer removal first and make sure that I'm not introducing
> regressions.
>
> Tested on Blackfin BF527 with DMA disabled due to an issue with the
SPI
> host controller driver in the current bleeding-edge Blackfin kernel.
I
> would appreciate it if someone with working DMA could test this patch
> and provide feedback.
>
I've tested this on our in-house dev board with our in-house CPU, on the
8686 in GSPI mode. Everything works as expected :)
Tested-by: George Shore <george.shore@imgtec.com>
> Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
> ---
> drivers/net/wireless/libertas/if_spi.c | 136
++-------------------------
> -----
> 1 files changed, 6 insertions(+), 130 deletions(-)
>
> diff --git a/drivers/net/wireless/libertas/if_spi.c
> b/drivers/net/wireless/libertas/if_spi.c
> index 06df2e1..9e0096d 100644
> --- a/drivers/net/wireless/libertas/if_spi.c
> +++ b/drivers/net/wireless/libertas/if_spi.c
> @@ -32,12 +32,6 @@
> #include "dev.h"
> #include "if_spi.h"
>
> -struct if_spi_packet {
> - struct list_head list;
> - u16 blen;
> - u8 buffer[0]
__attribute__((aligned(4)));
> -};
> -
> struct if_spi_card {
> struct spi_device *spi;
> struct lbs_private *priv;
> @@ -66,33 +60,10 @@ struct if_spi_card {
> struct semaphore spi_thread_terminated;
>
> u8 cmd_buffer[IF_SPI_CMD_BUF_SIZE];
> -
> - /* A buffer of incoming packets from libertas core.
> - * Since we can't sleep in hw_host_to_card, we have to buffer
> - * them. */
> - struct list_head cmd_packet_list;
> - struct list_head data_packet_list;
> -
> - /* Protects cmd_packet_list and data_packet_list */
> - spinlock_t buffer_lock;
> };
>
> static void free_if_spi_card(struct if_spi_card *card)
> {
> - struct list_head *cursor, *next;
> - struct if_spi_packet *packet;
> -
> - BUG_ON(card->run_thread);
> - list_for_each_safe(cursor, next, &card->cmd_packet_list) {
> - packet = container_of(cursor, struct if_spi_packet,
list);
> - list_del(&packet->list);
> - kfree(packet);
> - }
> - list_for_each_safe(cursor, next, &card->data_packet_list) {
> - packet = container_of(cursor, struct if_spi_packet,
list);
> - list_del(&packet->list);
> - kfree(packet);
> - }
> spi_set_drvdata(card->spi, NULL);
> kfree(card);
> }
> @@ -774,40 +745,6 @@ out:
> return err;
> }
>
> -/* Move data or a command from the host to the card. */
> -static void if_spi_h2c(struct if_spi_card *card,
> - struct if_spi_packet *packet, int type)
> -{
> - int err = 0;
> - u16 int_type, port_reg;
> -
> - switch (type) {
> - case MVMS_DAT:
> - int_type = IF_SPI_CIC_TX_DOWNLOAD_OVER;
> - port_reg = IF_SPI_DATA_RDWRPORT_REG;
> - break;
> - case MVMS_CMD:
> - int_type = IF_SPI_CIC_CMD_DOWNLOAD_OVER;
> - port_reg = IF_SPI_CMD_RDWRPORT_REG;
> - break;
> - default:
> - lbs_pr_err("can't transfer buffer of type %d\n", type);
> - err = -EINVAL;
> - goto out;
> - }
> -
> - /* Write the data to the card */
> - err = spu_write(card, port_reg, packet->buffer, packet->blen);
> - if (err)
> - goto out;
> -
> -out:
> - kfree(packet);
> -
> - if (err)
> - lbs_pr_err("%s: error %d\n", __func__, err);
> -}
> -
> /* Inform the host about a card event */
> static void if_spi_e2h(struct if_spi_card *card)
> {
> @@ -837,8 +774,6 @@ static int lbs_spi_thread(void *data)
> int err;
> struct if_spi_card *card = data;
> u16 hiStatus;
> - unsigned long flags;
> - struct if_spi_packet *packet;
>
> while (1) {
> /* Wait to be woken up by one of two things. First, our
ISR
> @@ -877,43 +812,9 @@ static int lbs_spi_thread(void *data)
> if (hiStatus & IF_SPI_HIST_CMD_DOWNLOAD_RDY ||
> (card->priv->psstate != PS_STATE_FULL_POWER &&
> (hiStatus & IF_SPI_HIST_TX_DOWNLOAD_RDY))) {
> - /* This means two things. First of all,
> - * if there was a previous command sent, the
card has
> - * successfully received it.
> - * Secondly, it is now ready to download another
> - * command.
> - */
> lbs_host_to_card_done(card->priv);
> -
> - /* Do we have any command packets from the host
to
> - * send? */
> - packet = NULL;
> - spin_lock_irqsave(&card->buffer_lock, flags);
> - if (!list_empty(&card->cmd_packet_list)) {
> - packet = (struct if_spi_packet *)(card->
> - cmd_packet_list.next);
> - list_del(&packet->list);
> - }
> - spin_unlock_irqrestore(&card->buffer_lock,
flags);
> -
> - if (packet)
> - if_spi_h2c(card, packet, MVMS_CMD);
> }
> - if (hiStatus & IF_SPI_HIST_TX_DOWNLOAD_RDY) {
> - /* Do we have any data packets from the host to
> - * send? */
> - packet = NULL;
> - spin_lock_irqsave(&card->buffer_lock, flags);
> - if (!list_empty(&card->data_packet_list)) {
> - packet = (struct if_spi_packet *)(card->
> - data_packet_list.next);
> - list_del(&packet->list);
> - }
> - spin_unlock_irqrestore(&card->buffer_lock,
flags);
>
> - if (packet)
> - if_spi_h2c(card, packet, MVMS_DAT);
> - }
> if (hiStatus & IF_SPI_HIST_CARD_EVENT)
> if_spi_e2h(card);
>
> @@ -942,40 +843,18 @@ static int if_spi_host_to_card(struct
lbs_private
> *priv,
> u8 type, u8 *buf, u16 nb)
> {
> int err = 0;
> - unsigned long flags;
> struct if_spi_card *card = priv->card;
> - struct if_spi_packet *packet;
> - u16 blen;
>
> lbs_deb_enter_args(LBS_DEB_SPI, "type %d, bytes %d", type, nb);
>
> - if (nb == 0) {
> - lbs_pr_err("%s: invalid size requested: %d\n", __func__,
nb);
> - err = -EINVAL;
> - goto out;
> - }
> - blen = ALIGN(nb, 4);
> - packet = kzalloc(sizeof(struct if_spi_packet) + blen,
GFP_ATOMIC);
> - if (!packet) {
> - err = -ENOMEM;
> - goto out;
> - }
> - packet->blen = blen;
> - memcpy(packet->buffer, buf, nb);
> - memset(packet->buffer + nb, 0, blen - nb);
> + nb = ALIGN(nb, 4);
>
> switch (type) {
> case MVMS_CMD:
> - priv->dnld_sent = DNLD_CMD_SENT;
> - spin_lock_irqsave(&card->buffer_lock, flags);
> - list_add_tail(&packet->list, &card->cmd_packet_list);
> - spin_unlock_irqrestore(&card->buffer_lock, flags);
> + err = spu_write(card, IF_SPI_CMD_RDWRPORT_REG, buf, nb);
> break;
> case MVMS_DAT:
> - priv->dnld_sent = DNLD_DATA_SENT;
> - spin_lock_irqsave(&card->buffer_lock, flags);
> - list_add_tail(&packet->list, &card->data_packet_list);
> - spin_unlock_irqrestore(&card->buffer_lock, flags);
> + err = spu_write(card, IF_SPI_DATA_RDWRPORT_REG, buf,
nb);
> break;
> default:
> lbs_pr_err("can't transfer buffer of type %d", type);
> @@ -983,9 +862,6 @@ static int if_spi_host_to_card(struct lbs_private
> *priv,
> break;
> }
>
> - /* Wake up the spi thread */
> - up(&card->spi_ready);
> -out:
> lbs_deb_leave_args(LBS_DEB_SPI, "err=%d", err);
> return err;
> }
> @@ -1062,9 +938,6 @@ static int __devinit if_spi_probe(struct
spi_device
> *spi)
>
> sema_init(&card->spi_ready, 0);
> sema_init(&card->spi_thread_terminated, 0);
> - INIT_LIST_HEAD(&card->cmd_packet_list);
> - INIT_LIST_HEAD(&card->data_packet_list);
> - spin_lock_init(&card->buffer_lock);
>
> /* Initialize the SPI Interface Unit */
> err = spu_init(card, pdata->use_dummy_writes);
> @@ -1141,6 +1014,9 @@ static int __devinit if_spi_probe(struct
spi_device
> *spi)
> goto terminate_thread;
> }
>
> + /* poke the IRQ handler so that we don't miss the first
interrupt */
> + up(&card->spi_ready);
> +
> /* Start the card.
> * This will call register_netdev, and we'll start
> * getting interrupts... */
> --
> 1.5.6.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe
linux-wireless"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
-
This message is subject to Imagination Technologies' e-mail terms: http://www.imgtec.com/e-mail.htm
Imagination Technologies Ltd is a limited company registered in England No: 1306335
Registered Office: Imagination House, Home Park Estate, Kings Langley, Hertfordshire, WD4 8LZ.
Email to and from the company may be monitored for compliance and other administrative purposes.
-
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Gertjan van Wingerde @ 2009-10-29 14:44 UTC (permalink / raw)
To: Michael Buesch
Cc: David Miller, bzolnier, penberg, linux-wireless, netdev,
linux-kernel, linville
In-Reply-To: <200910291539.16476.mb@bu3sch.de>
On Thu, Oct 29, 2009 at 3:39 PM, Michael Buesch <mb@bu3sch.de> wrote:
> On Thursday 29 October 2009 15:21:01 David Miller wrote:
>> The issue is that John disagrees with you can you can't handle
>> that.
>>
>> So instead of continuing to discuss things with him and the
>> other wireless folks, you want me to just overreach everybody
>> and revert someone else's work.
>
> In the end this results in the driver maintainer being forced to maintain
> code and handle bugreports for code that he disagrees with in the first place.
> This is unacceptable and has to be resolved in some way.
> If it's not possible to get it reverted through John (for whatever reason),
> you're in charge to help the actual code maintainer out.
>
>> I'm not going to do that sorry, learn how to work with the
>> wireless people instead.
>
> This is not the problem.
> The problem is that stuff is merged without ack from the maintainer
> and it's virtually impossible to get the stuff reverted. The only real
> way for the maintainer to resolve this is 1) live with it or 2) fix it.
> And that's bad, because it completely invalidates his priority queue.
>
> Just like you must not bypass John, the driver maintainers must not be bypassed, too.
> The quality control does _only_ work if nobody in the chain is bypassed.
> But in this situation the quality control did already fail and it should be
> tried hard to resolve (=revert) the situation instead of pointing at John.
>
Hold on here. In this case it is the driver maintainer (i.e. Ivo for
the rt2x00 project) that
submitted this driver for inclusion, so the driver maintainer has not
been bypassed in
this case.
Apparently Bart has issues with the code submitted by the maintainers
and has been
unsuccessful in convincing others about these issues.
---
Gertjan.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Michael Buesch @ 2009-10-29 14:48 UTC (permalink / raw)
To: Gertjan van Wingerde
Cc: David Miller, bzolnier, penberg, linux-wireless, netdev,
linux-kernel, linville
In-Reply-To: <14add3d10910290744n3abd1cf8w42a6311108eb2fa7@mail.gmail.com>
On Thursday 29 October 2009 15:44:42 Gertjan van Wingerde wrote:
> Hold on here. In this case it is the driver maintainer (i.e. Ivo for
> the rt2x00 project) that
> submitted this driver for inclusion, so the driver maintainer has not
> been bypassed in
> this case.
>
> Apparently Bart has issues with the code submitted by the maintainers
> and has been
> unsuccessful in convincing others about these issues.
So Bart is not a maintainer? That of course changes the situation.
--
Greetings, Michael.
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Luis R. Rodriguez @ 2009-10-29 15:08 UTC (permalink / raw)
To: Michael Buesch
Cc: Gertjan van Wingerde, David Miller, bzolnier, penberg,
linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <200910291548.27235.mb@bu3sch.de>
On Thu, Oct 29, 2009 at 7:48 AM, Michael Buesch <mb@bu3sch.de> wrote:
> On Thursday 29 October 2009 15:44:42 Gertjan van Wingerde wrote:
>> Hold on here. In this case it is the driver maintainer (i.e. Ivo for
>> the rt2x00 project) that
>> submitted this driver for inclusion, so the driver maintainer has not
>> been bypassed in
>> this case.
>>
>> Apparently Bart has issues with the code submitted by the maintainers
>> and has been
>> unsuccessful in convincing others about these issues.
>
> So Bart is not a maintainer? That of course changes the situation.
But you were :-P
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: make align adjustment code support paged SKB
From: Luis R. Rodriguez @ 2009-10-29 16:18 UTC (permalink / raw)
To: Reinette Chatre; +Cc: johannes, linville, linux-wireless, Zhu Yi
In-Reply-To: <1256760832-29063-1-git-send-email-reinette.chatre@intel.com>
On Wed, Oct 28, 2009 at 1:13 PM, Reinette Chatre
<reinette.chatre@intel.com> wrote:
> From: Zhu Yi <yi.zhu@intel.com>
>
> This fixed a BUG_ON in __skb_trim() when paged rx is used in
> iwlwifi driver. Yes, the whole mac80211 stack doesn't support
> paged SKB yet. But let's start the work slowly from small
> code snippets.
So I just noticed ar9271 segments some frames upon RX. The current
implementation approach is to stitch them back together through a
newly allocated skb after all segments are received. How does iwlwifi
ues paged skbs? How do you keep track of which page is for what frame?
Can you elaborate on the planned paged skb support on mac80211 you
have. Do you have any queued up patches I can look at this point?
Luis
^ permalink raw reply
* Re: [PATCH] libertas: remove internal buffers from GSPI driver
From: Andrey Yurovsky @ 2009-10-29 17:29 UTC (permalink / raw)
To: George Shore; +Cc: linux-wireless, libertas-dev, sebatian, dcbw
In-Reply-To: <0D107966AF6D79418315B7C5549F4B5101150D82@lemail1.le.imgtec.org>
Thanks George,
On Thu, Oct 29, 2009 at 7:27 AM, George Shore <George.Shore@imgtec.com> wrote:
> I've tested this on our in-house dev board with our in-house CPU, on the
> 8686 in GSPI mode. Everything works as expected :)
>
> Tested-by: George Shore <george.shore@imgtec.com>
Can you please tell us what you were able to test? I'm curious about:
1) were you able to turn IEEE PS on and off?
2) were you able to use WPA2?
3) were you able to use WPA2 with IEEE PS at the same time?
(3) is really tricky and may need additional work. One issue that I'm
seeing is that the driver gets out of sync with the device, the way
I'm reproducing this is:
1) use wpa_supplicant to associate to an AP with WPA2 security.
2) iwconfig eth1 power on -- you should see the LED blinking to
indicate IEEE PS (the LED is off while the device is sleeping)
3) issue a command or two to temporarily take the device out of IEEE
PS mode (ex: iwconfig with no arguments to look at the configuration
and stats)
4) the LED should be temporarily solid-on and then return to blinking
after the driver re-enables IEEE PS mode
Thanks again,
-Andrey
^ permalink raw reply
* Re: mesh support for rt73
From: Andrey Yurovsky @ 2009-10-29 17:43 UTC (permalink / raw)
To: Dan Rosenqvist; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <209743CECB91EB4F84169A51F300410D97BA47DBF4@MAIL02.ug.kth.se>
Hi Dan,
On Thu, Oct 29, 2009 at 6:19 AM, Dan Rosenqvist <danro@kth.se> wrote:
> Hi,
>
> I'm currently trying to set up a small 802.11s mesh network. As I've come to understand there's no support for mesh networking at the moment for rt 73 based cards (using DWL-G122 C1).
>
> Is it possible to implement the changes mentioned in http://linuxwireless.org/en/developers/Documentation/mac80211/API to support mesh networks for rt 73 as well?
> Is there someone out there currently working on this? Otherwise, how could I contribute to make this work?
>
> Regards,
> Dan--
rt73 devices are driven by the rt2x00 driver, in my case the interface
driver is rt73usb and the core driver is rt2x00. That does support
mesh although there's an issue related to beaconing:
http://bugzilla.kernel.org/show_bug.cgi?id=13752
-Andrey
^ permalink raw reply
* Re: [PATCH] libertas: remove internal buffers from GSPI driver
From: Andrey Yurovsky @ 2009-10-29 17:48 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-wireless, libertas-dev, sebatian, george.shore
In-Reply-To: <1256749998.3850.45.camel@localhost.localdomain>
On Wed, Oct 28, 2009 at 10:13 AM, Dan Williams <dcbw@redhat.com> wrote:
> Looks OK to me, but I don't have any of the SPI hardware so when you get
> a Tested-by:, let me know and I'll ack.
Thanks Dan, by the way the issue with WPA2 and IEEE PS is unrelated to
this patch (that is, I can reproduce it without the patch applied) so
we'll need to address that separately. So at this point we have:
Tested-by: George Shore <george.shore@imgtec.com>
Signed-off-by: Andrey Yurovsky <andrey@cozybit.com>
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-10-29 17:49 UTC (permalink / raw)
To: David Miller; +Cc: penberg, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <20091029.072101.109209962.davem@davemloft.net>
On Thursday 29 October 2009 15:21:01 David Miller wrote:
> From: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
> Date: Thu, 29 Oct 2009 15:14:40 +0100
>
> > Dave, if you have problems with executing the command locally I'll be
> > happy to supply you with the patch.
>
> This is not the issue.
>
> The issue is that John disagrees with you can you can't handle
> that.
>
> So instead of continuing to discuss things with him and the
> other wireless folks, you want me to just overreach everybody
> and revert someone else's work.
Lets look at the technical merits of this work.
It is 5 KLOC of dead code and it should be 1-2 KLOC of working code
(we may turn the blink eye on "working" part but FFS at least fix other
parts)..
Hey, Linus. We have a new driver for ya. It doesn't work, has design
problems and is not even half-finished but most wireless folks are fine
with it!
I wonder when things went so wrong here..
> I'm not going to do that sorry, learn how to work with the
> wireless people instead.
This is a waste of time since technical merit doesn't find much love there.
Sorry Dave but you're making me go over your head now and go into unpleasant
mode again..
Looking on how you just reverted cmd64x change which you were so proud while
taking IDE over shows where the real problem is -- in subsystems supervised
by you loyalty and rank is everything while you are busy playing the pointy
haired boss everywhere from arm to ide.
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: [PATCH] mac80211: make align adjustment code support paged SKB
From: Johannes Berg @ 2009-10-29 18:32 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Reinette Chatre, linville, linux-wireless, Zhu Yi
In-Reply-To: <43e72e890910290918v1ca66bbdk4270eabcae6f5798@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1779 bytes --]
On Thu, 2009-10-29 at 09:18 -0700, Luis R. Rodriguez wrote:
> On Wed, Oct 28, 2009 at 1:13 PM, Reinette Chatre
> <reinette.chatre@intel.com> wrote:
> > From: Zhu Yi <yi.zhu@intel.com>
> >
> > This fixed a BUG_ON in __skb_trim() when paged rx is used in
> > iwlwifi driver. Yes, the whole mac80211 stack doesn't support
> > paged SKB yet. But let's start the work slowly from small
> > code snippets.
>
> So I just noticed ar9271 segments some frames upon RX. The current
> implementation approach is to stitch them back together through a
> newly allocated skb after all segments are received. How does iwlwifi
> ues paged skbs? How do you keep track of which page is for what frame?
>
> Can you elaborate on the planned paged skb support on mac80211 you
> have. Do you have any queued up patches I can look at this point?
Look at commit 924e103a665300f4f25538889bdd37b256d8f787 -- the magic is
in this bit of code:
+ /* mac80211 currently doesn't support paged SKB. Convert it to
+ * linear SKB for management frame and data frame requires
+ * software decryption or software defragementation. */
+ if (ieee80211_is_mgmt(hdr->frame_control) ||
+ ieee80211_has_protected(hdr->frame_control) ||
+ ieee80211_has_morefrags(hdr->frame_control) ||
+ le16_to_cpu(hdr->seq_ctrl) & IEEE80211_SCTL_FRAG)
+ ret = skb_linearize(skb);
+ else
+ ret = __pskb_pull_tail(skb, min_t(u16, IWL_LINK_HDR_MAX, len)) ?
+ 0 : -ENOMEM;
+
+ if (ret) {
+ kfree_skb(skb);
+ goto out;
+ }
I plan on moving that into mac80211 so that you can just pass an
arbitrarily fragmented frame into mac80211.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] mac80211: make align adjustment code support paged SKB
From: Luis R. Rodriguez @ 2009-10-29 18:52 UTC (permalink / raw)
To: Reinette Chatre; +Cc: johannes, linville, linux-wireless, Zhu Yi
In-Reply-To: <43e72e890910290918v1ca66bbdk4270eabcae6f5798@mail.gmail.com>
On Thu, Oct 29, 2009 at 9:18 AM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Wed, Oct 28, 2009 at 1:13 PM, Reinette Chatre
> <reinette.chatre@intel.com> wrote:
>> From: Zhu Yi <yi.zhu@intel.com>
>>
>> This fixed a BUG_ON in __skb_trim() when paged rx is used in
>> iwlwifi driver. Yes, the whole mac80211 stack doesn't support
>> paged SKB yet. But let's start the work slowly from small
>> code snippets.
>
> So I just noticed ar9271 segments some frames upon RX. The current
> implementation approach is to stitch them back together through a
> newly allocated skb after all segments are received. How does iwlwifi
> ues paged skbs? How do you keep track of which page is for what frame?
>
> Can you elaborate on the planned paged skb support on mac80211 you
> have. Do you have any queued up patches I can look at this point?
OK I see git show 924e10
Anyone taking the mac80211 paged skb support on? Any idea how long it
may take to complete?
Luis
^ permalink raw reply
* Re: [PATCH] mac80211: make align adjustment code support paged SKB
From: Johannes Berg @ 2009-10-29 18:58 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: Reinette Chatre, linville, linux-wireless, Zhu Yi
In-Reply-To: <43e72e890910291152g5325718ah1c55912e928896e3@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]
On Thu, 2009-10-29 at 11:52 -0700, Luis R. Rodriguez wrote:
> > Can you elaborate on the planned paged skb support on mac80211 you
> > have. Do you have any queued up patches I can look at this point?
>
> OK I see git show 924e10
>
> Anyone taking the mac80211 paged skb support on? Any idea how long it
> may take to complete?
It's not very hard.
Step 1)
fix a few corner cases other drivers might have, and stick the bit of
code iwlwifi has right before passing the frame to mac80211 into
mac80211 as the first thing it does with the frame
Step 2)
Look through rx.c and check how much stuff it really needs linearised,
and where. I suspect that most of the time it _only_ needs the first
two bytes, until it comes to actually passing the frame up.
Step 3)
After the audit, push down the linearizing to where needed, i.e.
management frames completely, other frames up to and including the
ethernet header, software decryption all of the frame
Step 4)
make software decryption aware of paged SKBs, and remove the
linearising in that case
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Pekka Enberg @ 2009-10-29 19:45 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: David Miller, linux-wireless, netdev, linux-kernel, linville
In-Reply-To: <200910291514.40318.bzolnier@gmail.com>
Hi Bart,
On Thu, Oct 29, 2009 at 4:14 PM, Bartlomiej Zolnierkiewicz
<bzolnier@gmail.com> wrote:
>> lots of cleanups to the staging drivers, why not direct some of that
>> energy to the drivers/net/wireless ones?
>
> When did we start to apply "fix it yourself" rule instead of "submitter
> should fix it" one to the _new_ code..
Don't be silly, I didn't say that.
I was simply pointing out that your time would probably be better
spent in improving the "proper" ralink wireless drivers but if you
_really_ prefer to spend your time in pointless arguments, go ahead.
It should be pretty obvious by now that the best way to improve things
is to work with the relevant maintainers, not against them. (Unless
you wish your work to be ignored, of course.)
Pekka
^ permalink raw reply
* [RFC] ath9k: fix listening to idle requests
From: Luis R. Rodriguez @ 2009-10-29 20:52 UTC (permalink / raw)
To: vasanth; +Cc: linux-wireless, ath9k-devel, Luis R. Rodriguez
The way idle configuration detection was implemented as
busted due to the fact that it assumed the ath9k virtual wiphy,
the aphy, would be marked as inactive if it was not used but
it turns out an aphy is always active if its the only wiphy
present. We need to distinguish between aphy activity and
idleness so we now add an idle bool for the aphy and mark
it as such based on the passed IEEE80211_CONF_CHANGE_IDLE
from mac80211.
Previous to all_wiphys_idle would never be true when using
only one device so we never really were using
IEEE80211_CONF_CHANGE_IDLE -- we never turned the radio
off or on upon IEEE80211_CONF_CHANGE_IDLE changes as radio
changes depended on all_wiphys_idle being true either to
turn the radio on or off. Since it was always false for
one device this code was doing nothing.
Reported-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>
---
Vasanth, what do you think?
drivers/net/wireless/ath/ath9k/ath9k.h | 2 +
drivers/net/wireless/ath/ath9k/main.c | 33 +++++++++++++++++++++++------
drivers/net/wireless/ath/ath9k/virtual.c | 17 ++++++++++++--
3 files changed, 42 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index 13dd020..da53578 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -620,6 +620,7 @@ struct ath_wiphy {
ATH_WIPHY_PAUSED,
ATH_WIPHY_SCAN,
} state;
+ bool idle;
int chan_idx;
int chan_is_ht;
};
@@ -691,6 +692,7 @@ void ath9k_wiphy_pause_all_forced(struct ath_softc *sc,
bool ath9k_wiphy_scanning(struct ath_softc *sc);
void ath9k_wiphy_work(struct work_struct *work);
bool ath9k_all_wiphys_idle(struct ath_softc *sc);
+void ath9k_set_wiphy_idle(struct ath_wiphy *aphy, bool idle);
int ath_tx_get_qnum(struct ath_softc *sc, int qtype, int haltype);
#endif /* ATH9K_H */
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 9fefc51..bdce0ab 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -2688,22 +2688,37 @@ static int ath9k_config(struct ieee80211_hw *hw, u32 changed)
struct ath_common *common = ath9k_hw_common(sc->sc_ah);
struct ieee80211_conf *conf = &hw->conf;
struct ath_hw *ah = sc->sc_ah;
- bool all_wiphys_idle = false, disable_radio = false;
+ bool disable_radio;
mutex_lock(&sc->mutex);
- /* Leave this as the first check */
+ /*
+ * Leave this as the first check because we need to turn on the
+ * radio if it was disabled before prior to processing the rest
+ * of the changes. Likewise we must only disable the radio towards
+ * the end.
+ */
if (changed & IEEE80211_CONF_CHANGE_IDLE) {
+ bool enable_radio;
+ bool all_wiphys_idle;
+ bool idle = !!(conf->flags & IEEE80211_CONF_IDLE);
spin_lock_bh(&sc->wiphy_lock);
all_wiphys_idle = ath9k_all_wiphys_idle(sc);
+ ath9k_set_wiphy_idle(aphy, idle);
+
+ if (!idle && all_wiphys_idle)
+ enable_radio = true;
+
+ /*
+ * After we unlock here its possible another wiphy
+ * can be re-renabled so to account for that we will
+ * only disable the radio toward the end of this routine
+ * if by then all wiphys are still idle.
+ */
spin_unlock_bh(&sc->wiphy_lock);
- if (conf->flags & IEEE80211_CONF_IDLE){
- if (all_wiphys_idle)
- disable_radio = true;
- }
- else if (all_wiphys_idle) {
+ if (enable_radio) {
ath_radio_enable(sc);
ath_print(common, ATH_DBG_CONFIG,
"not-idle: enabling radio\n");
@@ -2779,6 +2794,10 @@ skip_chan_change:
if (changed & IEEE80211_CONF_CHANGE_POWER)
sc->config.txpowlimit = 2 * conf->power_level;
+ spin_lock_bh(&sc->wiphy_lock);
+ disable_radio = ath9k_all_wiphys_idle(sc);
+ spin_unlock_bh(&sc->wiphy_lock);
+
if (disable_radio) {
ath_print(common, ATH_DBG_CONFIG, "idle: disabling radio\n");
ath_radio_disable(sc);
diff --git a/drivers/net/wireless/ath/ath9k/virtual.c b/drivers/net/wireless/ath/ath9k/virtual.c
index bc7d173..e6a50f3 100644
--- a/drivers/net/wireless/ath/ath9k/virtual.c
+++ b/drivers/net/wireless/ath/ath9k/virtual.c
@@ -668,15 +668,26 @@ void ath9k_wiphy_set_scheduler(struct ath_softc *sc, unsigned int msec_int)
bool ath9k_all_wiphys_idle(struct ath_softc *sc)
{
unsigned int i;
- if (sc->pri_wiphy->state != ATH_WIPHY_INACTIVE) {
+ if (!sc->pri_wiphy->idle)
return false;
- }
for (i = 0; i < sc->num_sec_wiphy; i++) {
struct ath_wiphy *aphy = sc->sec_wiphy[i];
if (!aphy)
continue;
- if (aphy->state != ATH_WIPHY_INACTIVE)
+ if (!aphy->idle)
return false;
}
return true;
}
+
+/* caller must hold wiphy_lock */
+void ath9k_set_wiphy_idle(struct ath_wiphy *aphy, bool idle)
+{
+ struct ath_softc *sc = aphy->sc;
+
+ aphy->idle = idle;
+ ath_print(ath9k_hw_common(sc->sc_ah), ATH_DBG_CONFIG,
+ "Marking %s as %s\n",
+ wiphy_name(aphy->hw->wiphy),
+ idle ? "idle" : "not-idle");
+}
--
1.6.0.4
^ permalink raw reply related
* Re: odd state reached when AP deauths you after assoc
From: Luis R. Rodriguez @ 2009-10-29 20:55 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Jouni.Malinen
In-Reply-To: <1256761485.4237.260.camel@johannes.local>
On Wed, Oct 28, 2009 at 1:24 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2009-10-28 at 11:37 -0700, Luis R. Rodriguez wrote:
>> I ran into this when ath5k with wpa_supplicant with config file with
>> a wrong password against a Cisco AP. It seems the Cisco AP auths you
>> and lets you assoc but later it deauths you -- I guess after it
>> determines you are auth credentials failed. When this happens I get:
>>
>> mcgrof@tux ~ $ iw dev wlan0 link
>> Authenticated with 00:0b:85:5b:8d:6c (on wlan0)
>> Not connected.
>
> I'm guessing that you're using -Dnl80211. You need this patch, or
> equivalent:
> http://johannes.sipsolutions.net/patches/hostap/all/2009-10-26-12%3a59/deauth-on-disassoc.patch
Indeed, it fixes my woes, thanks.
Luis
^ permalink raw reply
* Re: odd state reached when AP deauths you after assoc
From: Luis R. Rodriguez @ 2009-10-29 21:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Jouni.Malinen
In-Reply-To: <43e72e890910291355l5fc4ec2ctb9a777b6e8b07baa@mail.gmail.com>
On Thu, Oct 29, 2009 at 1:55 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Wed, Oct 28, 2009 at 1:24 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
>> On Wed, 2009-10-28 at 11:37 -0700, Luis R. Rodriguez wrote:
>>> I ran into this when ath5k with wpa_supplicant with config file with
>>> a wrong password against a Cisco AP. It seems the Cisco AP auths you
>>> and lets you assoc but later it deauths you -- I guess after it
>>> determines you are auth credentials failed. When this happens I get:
>>>
>>> mcgrof@tux ~ $ iw dev wlan0 link
>>> Authenticated with 00:0b:85:5b:8d:6c (on wlan0)
>>> Not connected.
>>
>> I'm guessing that you're using -Dnl80211. You need this patch, or
>> equivalent:
>> http://johannes.sipsolutions.net/patches/hostap/all/2009-10-26-12%3a59/deauth-on-disassoc.patch
>
> Indeed, it fixes my woes, thanks.
Well almost, after a while of being connected it then does this:
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-SCAN-RESULTS
Trying to authenticate with 00:0b:85:5b:8d:6c (SSID='ATH-GLOBAL' freq=2462 MHz)
Trying to associate with 00:0b:85:5b:8d:6c (SSID='ATH-GLOBAL' freq=2462 MHz)
Associated with 00:0b:85:5b:8d:6c
CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
CTRL-EVENT-SCAN-RESULTS
Trying to authenticate with 00:0b:85:5b:9a:bc (SSID='ATH-GLOBAL' freq=2412 MHz)
Trying to associate with 00:0b:85:5b:9a:bc (SSID='ATH-GLOBAL' freq=2412 MHz)
Associated with 00:0b:85:5b:9a:bc
CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
OpenSSL: tls_connection_handshake - Failed to read possible
Application Data error:00000000:lib(0):func(0):reason(0)
And I then end up with the same:
>>> mcgrof@tux ~ $ iw dev wlan0 link
>>> Authenticated with 00:0b:85:5b:8d:6c (on wlan0)
>>> Not connected.
But this time if I hit ctrl-c it gets cleared and I can auth/assoc
fine after that. But an issue is still present.
Luis
^ permalink raw reply
* Re: odd state reached when AP deauths you after assoc
From: Johannes Berg @ 2009-10-29 21:28 UTC (permalink / raw)
To: Luis R. Rodriguez; +Cc: linux-wireless, Jouni.Malinen
In-Reply-To: <43e72e890910291419j7feb7a3dg33cd5b02e064eeee@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2175 bytes --]
On Thu, 2009-10-29 at 14:19 -0700, Luis R. Rodriguez wrote:
> On Thu, Oct 29, 2009 at 1:55 PM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
> > On Wed, Oct 28, 2009 at 1:24 PM, Johannes Berg
> > <johannes@sipsolutions.net> wrote:
> >> On Wed, 2009-10-28 at 11:37 -0700, Luis R. Rodriguez wrote:
> >>> I ran into this when ath5k with wpa_supplicant with config file with
> >>> a wrong password against a Cisco AP. It seems the Cisco AP auths you
> >>> and lets you assoc but later it deauths you -- I guess after it
> >>> determines you are auth credentials failed. When this happens I get:
> >>>
> >>> mcgrof@tux ~ $ iw dev wlan0 link
> >>> Authenticated with 00:0b:85:5b:8d:6c (on wlan0)
> >>> Not connected.
> >>
> >> I'm guessing that you're using -Dnl80211. You need this patch, or
> >> equivalent:
> >> http://johannes.sipsolutions.net/patches/hostap/all/2009-10-26-12%3a59/deauth-on-disassoc.patch
> >
> > Indeed, it fixes my woes, thanks.
>
> Well almost, after a while of being connected it then does this:
>
> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
> CTRL-EVENT-SCAN-RESULTS
> Trying to authenticate with 00:0b:85:5b:8d:6c (SSID='ATH-GLOBAL' freq=2462 MHz)
> Trying to associate with 00:0b:85:5b:8d:6c (SSID='ATH-GLOBAL' freq=2462 MHz)
> Associated with 00:0b:85:5b:8d:6c
> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
> CTRL-EVENT-SCAN-RESULTS
> Trying to authenticate with 00:0b:85:5b:9a:bc (SSID='ATH-GLOBAL' freq=2412 MHz)
> Trying to associate with 00:0b:85:5b:9a:bc (SSID='ATH-GLOBAL' freq=2412 MHz)
> Associated with 00:0b:85:5b:9a:bc
> CTRL-EVENT-EAP-STARTED EAP authentication started
> CTRL-EVENT-EAP-STARTED EAP authentication started
> CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
> OpenSSL: tls_connection_handshake - Failed to read possible
> Application Data error:00000000:lib(0):func(0):reason(0)
>
> And I then end up with the same:
>
> >>> mcgrof@tux ~ $ iw dev wlan0 link
> >>> Authenticated with 00:0b:85:5b:8d:6c (on wlan0)
> >>> Not connected.
Might be due to that bssid_changed check I was unsure about -- try
removing that.
johannes
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: odd state reached when AP deauths you after assoc
From: Luis R. Rodriguez @ 2009-10-29 21:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, Jouni.Malinen
In-Reply-To: <1256851738.3865.149.camel@johannes.local>
On Thu, Oct 29, 2009 at 2:28 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2009-10-29 at 14:19 -0700, Luis R. Rodriguez wrote:
>> On Thu, Oct 29, 2009 at 1:55 PM, Luis R. Rodriguez
>> <lrodriguez@atheros.com> wrote:
>> > On Wed, Oct 28, 2009 at 1:24 PM, Johannes Berg
>> > <johannes@sipsolutions.net> wrote:
>> >> On Wed, 2009-10-28 at 11:37 -0700, Luis R. Rodriguez wrote:
>> >>> I ran into this when ath5k with wpa_supplicant with config file with
>> >>> a wrong password against a Cisco AP. It seems the Cisco AP auths you
>> >>> and lets you assoc but later it deauths you -- I guess after it
>> >>> determines you are auth credentials failed. When this happens I get:
>> >>>
>> >>> mcgrof@tux ~ $ iw dev wlan0 link
>> >>> Authenticated with 00:0b:85:5b:8d:6c (on wlan0)
>> >>> Not connected.
>> >>
>> >> I'm guessing that you're using -Dnl80211. You need this patch, or
>> >> equivalent:
>> >> http://johannes.sipsolutions.net/patches/hostap/all/2009-10-26-12%3a59/deauth-on-disassoc.patch
>> >
>> > Indeed, it fixes my woes, thanks.
>>
>> Well almost, after a while of being connected it then does this:
>>
>> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
>> CTRL-EVENT-SCAN-RESULTS
>> Trying to authenticate with 00:0b:85:5b:8d:6c (SSID='ATH-GLOBAL' freq=2462 MHz)
>> Trying to associate with 00:0b:85:5b:8d:6c (SSID='ATH-GLOBAL' freq=2462 MHz)
>> Associated with 00:0b:85:5b:8d:6c
>> CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys
>> CTRL-EVENT-SCAN-RESULTS
>> Trying to authenticate with 00:0b:85:5b:9a:bc (SSID='ATH-GLOBAL' freq=2412 MHz)
>> Trying to associate with 00:0b:85:5b:9a:bc (SSID='ATH-GLOBAL' freq=2412 MHz)
>> Associated with 00:0b:85:5b:9a:bc
>> CTRL-EVENT-EAP-STARTED EAP authentication started
>> CTRL-EVENT-EAP-STARTED EAP authentication started
>> CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
>> OpenSSL: tls_connection_handshake - Failed to read possible
>> Application Data error:00000000:lib(0):func(0):reason(0)
>>
>> And I then end up with the same:
>>
>> >>> mcgrof@tux ~ $ iw dev wlan0 link
>> >>> Authenticated with 00:0b:85:5b:8d:6c (on wlan0)
>> >>> Not connected.
>
> Might be due to that bssid_changed check I was unsure about -- try
> removing that.
OK will do -- it took a while to trigger so will wait and see if it
happens again, and if it happens often enough I can at least confirm
it would fix it. Otherwise not sure what triggered it. I failed to
check the logs to see what disconnect event exactly triggered.
Luis
^ 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