From dcbw at redhat.com  Tue Dec  1 03:19:37 2009
From: dcbw at redhat.com (Dan Williams)
Date: Tue, 01 Dec 2009 00:19:37 -0800
Subject: [PATCH] libertas: remove internal buffers from GSPI driver
In-Reply-To: <436f52800911301653q224bacceq4a14cbbfaa5cc0e2@mail.gmail.com>
References: <1256687501-8636-1-git-send-email-andrey@cozybit.com>
	<436f52800911301653q224bacceq4a14cbbfaa5cc0e2@mail.gmail.com>
Message-ID: <1259655577.13178.31.camel@localhost.localdomain>

On Mon, 2009-11-30 at 16:53 -0800, Colin McCabe wrote:
> On Tue, Oct 27, 2009 at 3:51 PM, Andrey Yurovsky <andrey at cozybit.com> wrote:
> > 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.
> 
> Hi all,
> 
> I'm glad to see you're improving stuff. Good catch with some of the
> recent bugfixes.
> 
> However... it seems like you are headed for a "scheduling while
> atomic" with this patch.
> 
> The original reason why if_spi_host_to_card copied the data into a
> buffer, rather than simply calling spu_write and being done with it,
> was that spu_write needed to sleep. spu_write invokes spi_sync, which
> has a big comment that says "This call may only be used from a context
> that may sleep."
> 
> Unfortunately, if_spi_host_to_card is called from contexts where we
> hold a spinlock. For example, lbs_main does
> 
> spin_lock_irq(&priv->driver_lock);
> if (!priv->dnld_sent && priv->tx_pending_len > 0) {
>     int ret = priv->hw_host_to_card(priv, MVMS_DAT,
> 
> priv->tx_pending_buf,
> 
> priv->tx_pending_len);
> ...etc...
> 
> Perhaps the easiest thing would be to get rid of this usage of hw_host_to_card?
> spu_write will always have to busy-wait from time to time because the
> SPU requires a delay between successive transactions. Busy-waiting
> under a spinlock, with interrupts disabled, just doesn't seem right.

I so want to kill dnld_sent.  That variable is pretty confusing and I
think it can be architected better.  That still leaves tx_pending_len;
the problem there is that we do have a TX queue and we need to protect
it against concurrent access.  Incoming packets to TX can be queued at
any time by the upper layers of the network stack.

The fix for this is to make tx_pending_buf a *pointer* to a chunk of
memory in lbs_private, say "u8 tx_buf_real[LBS_UPLD_SIZE]".  When there
is no packet to TX, tx_pending_buf points to tx_buf_real[].  Thus
incoming packets to lbs_hard_start_xmit() can be copied into that buffer
immediately, and the buffer is still protected by the lock.  When a
packet is currently being TXed, tx_pending_buf would be NULL, and
hard_start_xmit() would return NETDEV_TX_BUSY like it currently does.

When the transmit is triggered, the lock is taken, tx_pending_buf is set
to NULL, the lock is released, and the address tx_buf_real[] is sent to
hw_host_to_card().  Thus hw_host_to_card() doesn't have to be under the
lock anymore, because nothing will be writing to tx_buf_real[].

We need to keep tx_buf_real[] as a statically allocated array so that if
the module is removed during TX, we don't need to kfree() any buffers
(which the TX might be using).  Obviously we could just spin until the
TX was done and free the buffer, but it's already statically allocated
and keeping that way is just easier.

At least that's my 10 minute thought...  There might be other variables
that hw_host_to_card uses (like dnld_sent) that are protected by the
lock, but dnld_sent (and cur_cmd_retcode) needs to die die die.

Dan

> Also the comment in if_spi_c2h_cmd that "we need a buffer big enough
> to handle whatever people send to hw_host_to_card" should go away if
> the buffer is not used in hw_host_to_card.
> 
> > 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.
> 
> Threaded IRQs, cool. I'm waiting for that patch. :)
> 
> Colin
> 
> 
> >
> > 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.
> >
> > Signed-off-by: Andrey Yurovsky <andrey at 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
> >
> >
> > _______________________________________________
> > libertas-dev mailing list
> > libertas-dev at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/libertas-dev
> >
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev



From holgerschurig at gmail.com  Tue Dec  1 04:52:13 2009
From: holgerschurig at gmail.com (Holger Schurig)
Date: Tue, 1 Dec 2009 10:52:13 +0100
Subject: [PATCH] libertas: remove internal buffers from GSPI driver
In-Reply-To: <436f52800911301653q224bacceq4a14cbbfaa5cc0e2@mail.gmail.com>
References: <1256687501-8636-1-git-send-email-andrey@cozybit.com>
	<436f52800911301653q224bacceq4a14cbbfaa5cc0e2@mail.gmail.com>
Message-ID: <200912011052.13643.holgerschurig@gmail.com>

> Perhaps the easiest thing would be to get rid of this usage of
> hw_host_to_card? 

That would mean to rewrite this not only for SPI, but also for
USB and CS. If you come up with patches, I'm willing to test this
against USB and/or CS, in case you don't have this hardware.

-- 
http://www.holgerschurig.de


From jackylam.gsl at gmail.com  Sun Dec  6 22:12:20 2009
From: jackylam.gsl at gmail.com (Jacky Lam)
Date: Mon, 7 Dec 2009 11:12:20 +0800
Subject: Libertas driver problem with WPA
Message-ID: <39811fe10912061912y680c739fsb89eebf38aa70ab@mail.gmail.com>

Dear all,

	I have problem to associate with AP using WPA-PSK using Libertas driver
on SD8686 chip set, but no problem with WEP.

	I use wpa_supplicant-0.5.7 patched to work with Marvel's driver(which
is proven to work on our another platform using Marvell's SDIO driver
and Linux 2.4.20 kernel.) The following is the wpa_supplicant.conf:

ctrl_interface=/tmp/run/wpa_supplicant
ctrl_interface_group=0
eapol_version=1
ap_scan=1
fast_reauth=1
network={
ssid="WL_TEST"
proto=WPA RSN
key_mgmt=WPA-PSK
pairwise=CCMP TKIP
group=CCMP TKIP
psk="hellohello"
}

	Is there any changes on the way to connect WPA-PSK AP when transit from
Linux 2.4 to 2.6 or Marvell's driver to Libertas driver?

	Please help to give me some advice. Thanks.

BR,
Jacky


From jiujin.hong at mid-fun.com  Mon Dec  7 00:37:03 2009
From: jiujin.hong at mid-fun.com (tommy)
Date: Mon, 07 Dec 2009 13:37:03 +0800
Subject: Libertas driver problem with WPA
In-Reply-To: <39811fe10912061912y680c739fsb89eebf38aa70ab@mail.gmail.com>
References: <39811fe10912061912y680c739fsb89eebf38aa70ab@mail.gmail.com>
Message-ID: <1260164223.22149.1.camel@tommy-desktop>

please update your wpa_supplicant version to 0.6.x !
I have met wpa_supplicat old version can cause wpa association problem!


B.R
Tommy
On ?, 2009-12-07 at 11:12 +0800, Jacky Lam wrote:
> Dear all,
> 
> 	I have problem to associate with AP using WPA-PSK using Libertas driver
> on SD8686 chip set, but no problem with WEP.
> 
> 	I use wpa_supplicant-0.5.7 patched to work with Marvel's driver(which
> is proven to work on our another platform using Marvell's SDIO driver
> and Linux 2.4.20 kernel.) The following is the wpa_supplicant.conf:
> 
> ctrl_interface=/tmp/run/wpa_supplicant
> ctrl_interface_group=0
> eapol_version=1
> ap_scan=1
> fast_reauth=1
> network={
> ssid="WL_TEST"
> proto=WPA RSN
> key_mgmt=WPA-PSK
> pairwise=CCMP TKIP
> group=CCMP TKIP
> psk="hellohello"
> }
> 
> 	Is there any changes on the way to connect WPA-PSK AP when transit from
> Linux 2.4 to 2.6 or Marvell's driver to Libertas driver?
> 
> 	Please help to give me some advice. Thanks.
> 
> BR,
> Jacky
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev
> 



From dcbw at redhat.com  Sat Dec  5 02:33:54 2009
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 04 Dec 2009 23:33:54 -0800
Subject: Libertas driver problem with WPA
In-Reply-To: <39811fe10912061912y680c739fsb89eebf38aa70ab@mail.gmail.com>
References: <39811fe10912061912y680c739fsb89eebf38aa70ab@mail.gmail.com>
Message-ID: <1259998434.29387.12.camel@localhost.localdomain>

On Mon, 2009-12-07 at 11:12 +0800, Jacky Lam wrote:
> Dear all,
> 
> 	I have problem to associate with AP using WPA-PSK using Libertas driver
> on SD8686 chip set, but no problem with WEP.

What kernel version?  Also you shouldn't need to patch wpa_supplicant to
work with the Marvell driver.  Using the upstream kernel libertas driver
is supported with the generic wpa_supplicant "wext" driver, and I know
that driver works for WPA-PSK connections.

Dan

> 	I use wpa_supplicant-0.5.7 patched to work with Marvel's driver(which
> is proven to work on our another platform using Marvell's SDIO driver
> and Linux 2.4.20 kernel.) The following is the wpa_supplicant.conf:
> 
> ctrl_interface=/tmp/run/wpa_supplicant
> ctrl_interface_group=0
> eapol_version=1
> ap_scan=1
> fast_reauth=1
> network={
> ssid="WL_TEST"
> proto=WPA RSN
> key_mgmt=WPA-PSK
> pairwise=CCMP TKIP
> group=CCMP TKIP
> psk="hellohello"
> }
> 
> 	Is there any changes on the way to connect WPA-PSK AP when transit from
> Linux 2.4 to 2.6 or Marvell's driver to Libertas driver?
> 
> 	Please help to give me some advice. Thanks.
> 
> BR,
> Jacky
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev



From jackylam.gsl at gmail.com  Mon Dec  7 03:14:38 2009
From: jackylam.gsl at gmail.com (Jacky Lam)
Date: Mon, 7 Dec 2009 16:14:38 +0800
Subject: Libertas driver problem with WPA
Message-ID: <39811fe10912070014q1c01612dt29fe27db55974d6f@mail.gmail.com>

Dear Dan,

	The problem is gone when I upgrade my wpa_supplicant to 0.6.9. If there
is some way to tell the in-compatibility of driver and userland tools,
it will be much better.

	Anyway, thanks for your reply.

Best Regards,
Jacky

Dan Williams ??:
> On Mon, 2009-12-07 at 11:12 +0800, Jacky Lam wrote:
>> Dear all,
>>
>> 	I have problem to associate with AP using WPA-PSK using Libertas driver
>> on SD8686 chip set, but no problem with WEP.
>
> What kernel version?  Also you shouldn't need to patch wpa_supplicant to
> work with the Marvell driver.  Using the upstream kernel libertas driver
> is supported with the generic wpa_supplicant "wext" driver, and I know
> that driver works for WPA-PSK connections.
>
> Dan
>
>> 	I use wpa_supplicant-0.5.7 patched to work with Marvel's driver(which
>> is proven to work on our another platform using Marvell's SDIO driver
>> and Linux 2.4.20 kernel.) The following is the wpa_supplicant.conf:
>>
>> ctrl_interface=/tmp/run/wpa_supplicant
>> ctrl_interface_group=0
>> eapol_version=1
>> ap_scan=1
>> fast_reauth=1
>> network={
>> ssid="WL_TEST"
>> proto=WPA RSN
>> key_mgmt=WPA-PSK
>> pairwise=CCMP TKIP
>> group=CCMP TKIP
>> psk="hellohello"
>> }
>>
>> 	Is there any changes on the way to connect WPA-PSK AP when transit from
>> Linux 2.4 to 2.6 or Marvell's driver to Libertas driver?
>>
>> 	Please help to give me some advice. Thanks.
>>
>> BR,
>> Jacky
>>
>> _______________________________________________
>> libertas-dev mailing list
>> libertas-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/libertas-dev
>
>
>


From cmccabe at alumni.cmu.edu  Tue Dec  8 17:06:17 2009
From: cmccabe at alumni.cmu.edu (Colin McCabe)
Date: Tue, 8 Dec 2009 14:06:17 -0800
Subject: [PATCH] libertas: remove internal buffers from GSPI driver
In-Reply-To: <200912011052.13643.holgerschurig@gmail.com>
References: <1256687501-8636-1-git-send-email-andrey@cozybit.com>
	<436f52800911301653q224bacceq4a14cbbfaa5cc0e2@mail.gmail.com>
	<200912011052.13643.holgerschurig@gmail.com>
Message-ID: <436f52800912081406k5d94596dga8eb5a7de04d8e76@mail.gmail.com>

Yes, getting rid of the spinlock around hw_host_to_card would mean
that concurrent calls to hw_host_to_card could happen.

I don't _think_ this would be a problem in if_spi, at least. Now that
we've moved to using complete spi_message structures, each message
should be sent atomically by the SPI layer.

The only question is whether certain messages have to happen in
sequence. For example, in if_spi_c2h_cmd, we do spu_read_u16 from
scratch reg 2 to find out how many bytes to read. Then we read the
bytes from the RDWRPORT register. If someone else did some other SPU
operations between those two, would the module get confused? I don't
_think_ so, but I haven't tested it.

Colin


On Tue, Dec 1, 2009 at 1:52 AM, Holger Schurig <holgerschurig at gmail.com> wrote:
>> Perhaps the easiest thing would be to get rid of this usage of
>> hw_host_to_card?
>
> That would mean to rewrite this not only for SPI, but also for
> USB and CS. If you come up with patches, I'm willing to test this
> against USB and/or CS, in case you don't have this hardware.
>
> --
> http://www.holgerschurig.de
>


From noreply at vk.com  Fri Dec 11 00:44:17 2009
From: noreply at vk.com (VK)
Date: Fri, 11 Dec 2009 08:44:17 +0300
Subject: Vadim Blinov has added you as a friend on the website VK.com
Message-ID: <0d870507168ab921bd0fb84574bbad75@localhost.localdomain>

Hello,

Vadim Blinov has added you as a friend on the website VK.com

You can log in and view your friends` pages using your email and automatically created password: N84672zG

VK.com is a website that helps dozens of millions of people find their old friends, share photos and events and always stay in touch.

To log in, please follow this link:
http://vk.com/login.php?regemail=libertas-dev at lists.infradead.org#N84672zG

You can change your password in Settings.

Attention: If you ignore this invitation, your registration will not be activated.

Good luck!




From noticenotice49 at yahoo.com.hk  Fri Dec 11 11:20:34 2009
From: noticenotice49 at yahoo.com.hk (BRITISH FINANCE MONITORING UNIT)
Date: Sat, 12 Dec 2009 01:20:34 +0900
Subject: The  Director British finance monitoring unit'''
Message-ID: <200912111620.nBBGKYPi019753@ns2.tcar.co.kr>

THE BRITISH FINANCE MONITORING UNIT LONDON, 
ENGLAND.
TELEPHONE: +44-704-5755-352

From daniel at caiaq.de  Sat Dec 12 15:47:30 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Sun, 13 Dec 2009 04:47:30 +0800
Subject: [PATCH] wireless: wext: allocate space for NULL-termination for
	32byte SSIDs
Message-ID: <1260650850-16163-1-git-send-email-daniel@caiaq.de>

We've experienced a long standing bug when quickly switching from
ad-hoc to managed mode on a hardware using a Libertas chipset.

The effect is that after a number of mode transistions (sometimes as few
as two sufficed), the kernel will oops at very strange locations, mostly
in something like __kmem_alloc().

While the root cause turned out to be an issue with the wpa-supplicant
which feeds the kernel driver with garbage, this occasion pointed out a
bug in the wireless wext core when SSIDs with 32 byte lengths are passed
from userspace. In this case, the string is not properly NULL-terminated
which causes some other part to corrupt memory.

(In the particular case I observed, an SIOCSIWESSID was issued with
 bogus data in iwp->pointer but iwp->length=32).

I admitedly couldn't find where the actual corruption itself happens,
but with this trivial fix, I can't reproduce the bug anymore.

Signed-off-by: Daniel Mack <daniel at caiaq.de>
Cc: Dan Williams <dcbw at redhat.com>
Cc: Michael Hirsch <m.hirsch at raumfeld.com>
Cc: netdev at vger.kernel.org
Cc: libertas-dev at lists.infradead.org
Cc: stable at kernel.org
---
 net/wireless/wext.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
---
 net/wireless/wext-core.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/net/wireless/wext-core.c b/net/wireless/wext-core.c
index 5e1656b..3d8f4b0 100644
--- a/net/wireless/wext-core.c
+++ b/net/wireless/wext-core.c
@@ -759,8 +759,8 @@ static int ioctl_standard_iw_point(struct iw_point *iwp, unsigned int cmd,
 		}
 	}
 
-	/* kzalloc() ensures NULL-termination for essid_compat. */
-	extra = kzalloc(extra_size, GFP_KERNEL);
+	/* kzalloc() +1 ensures NULL-termination for essid_compat. */
+	extra = kzalloc(extra_size + 1, GFP_KERNEL);
 	if (!extra)
 		return -ENOMEM;
 
-- 
1.6.3.3



From davem at davemloft.net  Tue Dec 15 04:43:08 2009
From: davem at davemloft.net (David Miller)
Date: Tue, 15 Dec 2009 01:43:08 -0800 (PST)
Subject: [PATCH] wireless: wext: allocate space for NULL-termination
	for 32byte SSIDs
In-Reply-To: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
References: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
Message-ID: <20091215.014308.77044043.davem@davemloft.net>

From: Daniel Mack <daniel at caiaq.de>
Date: Sun, 13 Dec 2009 04:47:30 +0800

> We've experienced a long standing bug when quickly switching from
> ad-hoc to managed mode on a hardware using a Libertas chipset.

Can you please CC: linux-wireless for wireless patches?

Thanks.

> The effect is that after a number of mode transistions (sometimes as few
> as two sufficed), the kernel will oops at very strange locations, mostly
> in something like __kmem_alloc().
> 
> While the root cause turned out to be an issue with the wpa-supplicant
> which feeds the kernel driver with garbage, this occasion pointed out a
> bug in the wireless wext core when SSIDs with 32 byte lengths are passed
> from userspace. In this case, the string is not properly NULL-terminated
> which causes some other part to corrupt memory.
> 
> (In the particular case I observed, an SIOCSIWESSID was issued with
>  bogus data in iwp->pointer but iwp->length=32).
> 
> I admitedly couldn't find where the actual corruption itself happens,
> but with this trivial fix, I can't reproduce the bug anymore.
> 
> Signed-off-by: Daniel Mack <daniel at caiaq.de>
> Cc: Dan Williams <dcbw at redhat.com>
> Cc: Michael Hirsch <m.hirsch at raumfeld.com>
> Cc: netdev at vger.kernel.org
> Cc: libertas-dev at lists.infradead.org
> Cc: stable at kernel.org
> ---
>  net/wireless/wext.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> ---
>  net/wireless/wext-core.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/net/wireless/wext-core.c b/net/wireless/wext-core.c
> index 5e1656b..3d8f4b0 100644
> --- a/net/wireless/wext-core.c
> +++ b/net/wireless/wext-core.c
> @@ -759,8 +759,8 @@ static int ioctl_standard_iw_point(struct iw_point *iwp, unsigned int cmd,
>  		}
>  	}
>  
> -	/* kzalloc() ensures NULL-termination for essid_compat. */
> -	extra = kzalloc(extra_size, GFP_KERNEL);
> +	/* kzalloc() +1 ensures NULL-termination for essid_compat. */
> +	extra = kzalloc(extra_size + 1, GFP_KERNEL);
>  	if (!extra)
>  		return -ENOMEM;
>  
> -- 
> 1.6.3.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


From johannes at sipsolutions.net  Tue Dec 15 05:03:31 2009
From: johannes at sipsolutions.net (Johannes Berg)
Date: Tue, 15 Dec 2009 11:03:31 +0100
Subject: [PATCH] wireless: wext: allocate space for NULL-termination
	for 32byte SSIDs
In-Reply-To: <20091215.014308.77044043.davem@davemloft.net>
References: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
	<20091215.014308.77044043.davem@davemloft.net>
Message-ID: <1260871411.3692.4.camel@johannes.local>

On Tue, 2009-12-15 at 01:43 -0800, David Miller wrote:

> > The effect is that after a number of mode transistions (sometimes as few
> > as two sufficed), the kernel will oops at very strange locations, mostly
> > in something like __kmem_alloc().
> > 
> > While the root cause turned out to be an issue with the wpa-supplicant
> > which feeds the kernel driver with garbage, this occasion pointed out a
> > bug in the wireless wext core when SSIDs with 32 byte lengths are passed
> > from userspace. In this case, the string is not properly NULL-terminated
> > which causes some other part to corrupt memory.
> > 
> > (In the particular case I observed, an SIOCSIWESSID was issued with
> >  bogus data in iwp->pointer but iwp->length=32).
> > 
> > I admitedly couldn't find where the actual corruption itself happens,
> > but with this trivial fix, I can't reproduce the bug anymore.

Well you should try harder :)

> > -	/* kzalloc() ensures NULL-termination for essid_compat. */
> > -	extra = kzalloc(extra_size, GFP_KERNEL);
> > +	/* kzalloc() +1 ensures NULL-termination for essid_compat. */
> > +	extra = kzalloc(extra_size + 1, GFP_KERNEL);

That doesn't seem correct.

If this is used in a SET, then it is purely an in-kernel thing and
everything in the kernel is passed the length + data, and the kernel
MUST NEVER treat the SSID as a NUL-terminated string.

If this is used in a GET, then it will be filled up to 32 bytes by the
get handler, and the trailing \0 your patch reserves will never be
copied into userspace.

Since you indicate the kernel crashed, it is likely that libertas is
treating the buffer as a string, instead of an SSID.

That doesn't, however, make your fix and more valid. Whatever code uses
it as a string is clearly at fault, since this is a valid four-byte
SSID: "\x00\x01\x02\x03"

johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/libertas-dev/attachments/20091215/7fb1a712/attachment.sig>

From johannes at sipsolutions.net  Tue Dec 15 05:05:33 2009
From: johannes at sipsolutions.net (Johannes Berg)
Date: Tue, 15 Dec 2009 11:05:33 +0100
Subject: [PATCH] wireless: wext: allocate space for NULL-termination
	for 32byte SSIDs
In-Reply-To: <1260871411.3692.4.camel@johannes.local>
References: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
	<20091215.014308.77044043.davem@davemloft.net>
	<1260871411.3692.4.camel@johannes.local>
Message-ID: <1260871533.3692.5.camel@johannes.local>

On Tue, 2009-12-15 at 11:03 +0100, Johannes Berg wrote:
> On Tue, 2009-12-15 at 01:43 -0800, David Miller wrote:
> 
> > > The effect is that after a number of mode transistions (sometimes as few
> > > as two sufficed), the kernel will oops at very strange locations, mostly
> > > in something like __kmem_alloc().
> > > 
> > > While the root cause turned out to be an issue with the wpa-supplicant
> > > which feeds the kernel driver with garbage, this occasion pointed out a
> > > bug in the wireless wext core when SSIDs with 32 byte lengths are passed
> > > from userspace. In this case, the string is not properly NULL-terminated
> > > which causes some other part to corrupt memory.

And, I forgot to mention, this is in fact not an issue or the "root
cause" of any issues -- it's completely intentional that wpa_supplicant
feeds the kernel with a random, valid, 32-byte SSID.

johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/libertas-dev/attachments/20091215/9e5f6c47/attachment.sig>

From johannes at sipsolutions.net  Tue Dec 15 05:07:14 2009
From: johannes at sipsolutions.net (Johannes Berg)
Date: Tue, 15 Dec 2009 11:07:14 +0100
Subject: [PATCH] wireless: wext: allocate space for NULL-termination
	for 32byte SSIDs
In-Reply-To: <1260871411.3692.4.camel@johannes.local>
References: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
	<20091215.014308.77044043.davem@davemloft.net>
	<1260871411.3692.4.camel@johannes.local>
Message-ID: <1260871634.3692.6.camel@johannes.local>

On Tue, 2009-12-15 at 11:03 +0100, Johannes Berg wrote:

> Since you indicate the kernel crashed, it is likely that libertas is
> treating the buffer as a string, instead of an SSID.

drivers/net/wireless/libertas$ grep lbs_deb_ * | grep ssid|grep '%s'
assoc.c:	lbs_deb_join("current SSID '%s', ssid length %u\n",
assoc.c:	lbs_deb_join("requested ssid '%s', ssid length %u\n",
assoc.c:	lbs_deb_join("ADHOC_START: SSID '%s', ssid length %u\n",
scan.c:		lbs_deb_wext("set_scan, essid '%s'\n",

johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/libertas-dev/attachments/20091215/be36afd1/attachment.sig>

From acahalan at gmail.com  Tue Dec 15 05:16:56 2009
From: acahalan at gmail.com (Albert Cahalan)
Date: Tue, 15 Dec 2009 05:16:56 -0500
Subject: [PATCH] wireless: wext: allocate space for NULL-termination for 
	32byte SSIDs
In-Reply-To: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
References: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
Message-ID: <787b0d920912150216t58e817b2g64e8a19b0a1331bf@mail.gmail.com>

On Sat, Dec 12, 2009 at 3:47 PM, Daniel Mack <daniel at caiaq.de> wrote:

> While the root cause turned out to be an issue with the wpa-supplicant
> which feeds the kernel driver with garbage, this occasion pointed out a
> bug in the wireless wext core when SSIDs with 32 byte lengths are passed
> from userspace. In this case, the string is not properly NULL-terminated
> which causes some other part to corrupt memory.

This is the wrong fix.

These are not strings. They are 32 arbitrary bytes. It is perfectly
legitimate to have a NUL byte in the middle; the use of C string
functions will corrupt the data.

For your testing I suggest:

a. start the SSID with '-'
b. include "/../" in the SSID
c. include UTF-16 surrogates wrongly encoded as UTF-8
d. include "\r\n" in the SSID
e. include quote and backslash characters in the SSID
f. include bytes in the 0x80 to 0x9f range, surrounded by ASCII
g. include bytes in the 0xc0 to 0xff range, surrounded by ASCII
h. include the sequence 0xc0,0x80 (Java UTF-8 pseudo-NUL)
i. include the NUL byte
j. end the SSID with a plain ASCII letter

Verify that the whole stack, from driver to GUI, can handle this.
That includes config files, command lines, /proc and /sys, etc.


From daniel at caiaq.de  Tue Dec 15 05:20:35 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Tue, 15 Dec 2009 18:20:35 +0800
Subject: [PATCH] wireless: wext: allocate space for NULL-termination
	for 32byte SSIDs
In-Reply-To: <1260871634.3692.6.camel@johannes.local>
References: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
	<20091215.014308.77044043.davem@davemloft.net>
	<1260871411.3692.4.camel@johannes.local>
	<1260871634.3692.6.camel@johannes.local>
Message-ID: <20091215102035.GJ28375@buzzloop.caiaq.de>

On Tue, Dec 15, 2009 at 11:07:14AM +0100, Johannes Berg wrote:
> On Tue, 2009-12-15 at 11:03 +0100, Johannes Berg wrote:
> 
> > Since you indicate the kernel crashed, it is likely that libertas is
> > treating the buffer as a string, instead of an SSID.

Ok, I dodn't know that - thanks for pointing it out. In my setup here,
SSIDs are always valid alphanumeric strings, and I was mislead by the
comment that mentions the NULL-termination.

> drivers/net/wireless/libertas$ grep lbs_deb_ * | grep ssid|grep '%s'
> assoc.c:	lbs_deb_join("current SSID '%s', ssid length %u\n",
> assoc.c:	lbs_deb_join("requested ssid '%s', ssid length %u\n",
> assoc.c:	lbs_deb_join("ADHOC_START: SSID '%s', ssid length %u\n",
> scan.c:		lbs_deb_wext("set_scan, essid '%s'\n",

Those macros are stubbed out as nops in my setup, so they can
unfortunately not be the reason. I'll dig deeper :)

Thanks,
Daniel


From johannes at sipsolutions.net  Tue Dec 15 05:31:23 2009
From: johannes at sipsolutions.net (Johannes Berg)
Date: Tue, 15 Dec 2009 11:31:23 +0100
Subject: [PATCH] wireless: wext: allocate space for NULL-termination
	for 32byte SSIDs
In-Reply-To: <20091215102035.GJ28375@buzzloop.caiaq.de>
References: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
	<20091215.014308.77044043.davem@davemloft.net>
	<1260871411.3692.4.camel@johannes.local>
	<1260871634.3692.6.camel@johannes.local>
	<20091215102035.GJ28375@buzzloop.caiaq.de>
Message-ID: <1260873083.3692.8.camel@johannes.local>

On Tue, 2009-12-15 at 18:20 +0800, Daniel Mack wrote:

> > > Since you indicate the kernel crashed, it is likely that libertas is
> > > treating the buffer as a string, instead of an SSID.
> 
> Ok, I dodn't know that - thanks for pointing it out. In my setup here,
> SSIDs are always valid alphanumeric strings, and I was mislead by the
> comment that mentions the NULL-termination.

Yeah ... that's an unfortunate historic mistake in wireless extensions
that we try to fix up there. It cannot always be successfully fixed up,
but the NUL-termination is nothing that anything but this code should be
worried about or rely on.

> > drivers/net/wireless/libertas$ grep lbs_deb_ * | grep ssid|grep '%s'
> > assoc.c:	lbs_deb_join("current SSID '%s', ssid length %u\n",
> > assoc.c:	lbs_deb_join("requested ssid '%s', ssid length %u\n",
> > assoc.c:	lbs_deb_join("ADHOC_START: SSID '%s', ssid length %u\n",
> > scan.c:		lbs_deb_wext("set_scan, essid '%s'\n",
> 
> Those macros are stubbed out as nops in my setup, so they can
> unfortunately not be the reason. I'll dig deeper :)

Well, the stack trace ought to help.

johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/libertas-dev/attachments/20091215/a724c6db/attachment-0001.sig>

From holgerschurig at gmail.com  Tue Dec 15 05:30:58 2009
From: holgerschurig at gmail.com (Holger Schurig)
Date: Tue, 15 Dec 2009 11:30:58 +0100
Subject: [PATCH] wireless: wext: allocate space for NULL-termination for
	32byte SSIDs
In-Reply-To: <1260871634.3692.6.camel@johannes.local>
References: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
	<1260871411.3692.4.camel@johannes.local>
	<1260871634.3692.6.camel@johannes.local>
Message-ID: <200912151130.59103.holgerschurig@gmail.com>

> drivers/net/wireless/libertas$ grep lbs_deb_ * | grep ssid
> |grep '%s' 
> assoc.c:	lbs_deb_join("current SSID '%s', ssid length %u\n",
> assoc.c:	lbs_deb_join("requested ssid '%s', ssid length %u\n",
> assoc.c:	lbs_deb_join("ADHOC_START: SSID '%s', ssid
>               length %u\n", 
> scan.c:		lbs_deb_wext("set_scan, essid '%s'\n",

All those lines are gone once my cfg80211 lands.

Do you know any way to make sparse moan about them?


BTW: the libertas firmware sometimes treat an SSID as a 
zero-terminated string. There are some firmware commands that 
accept just an u8[32] bytes for the SSID, but not an ssid_len, 
e.g. in the CMD_802_11_AD_HOC_START command.

You therefore can't connect to the otherwise legitimate SSID of 
TEST\0\0\0.

-- 
http://www.holgerschurig.de


From johannes at sipsolutions.net  Tue Dec 15 05:35:07 2009
From: johannes at sipsolutions.net (Johannes Berg)
Date: Tue, 15 Dec 2009 11:35:07 +0100
Subject: [PATCH] wireless: wext: allocate space for NULL-termination
	for 32byte SSIDs
In-Reply-To: <200912151130.59103.holgerschurig@gmail.com>
References: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
	<1260871411.3692.4.camel@johannes.local>
	<1260871634.3692.6.camel@johannes.local>
	<200912151130.59103.holgerschurig@gmail.com>
Message-ID: <1260873307.3692.10.camel@johannes.local>

On Tue, 2009-12-15 at 11:30 +0100, Holger Schurig wrote:
> > drivers/net/wireless/libertas$ grep lbs_deb_ * | grep ssid
> > |grep '%s' 
> > assoc.c:	lbs_deb_join("current SSID '%s', ssid length %u\n",
> > assoc.c:	lbs_deb_join("requested ssid '%s', ssid length %u\n",
> > assoc.c:	lbs_deb_join("ADHOC_START: SSID '%s', ssid
> >               length %u\n", 
> > scan.c:		lbs_deb_wext("set_scan, essid '%s'\n",
> 
> All those lines are gone once my cfg80211 lands.
> 
> Do you know any way to make sparse moan about them?

Sorry, no, I don't think that's even possible unless you play dirty with
tricks like __iomem uses for instance but that'd require a lot of
casting in otherwise valid uses.

> BTW: the libertas firmware sometimes treat an SSID as a 
> zero-terminated string. There are some firmware commands that 
> accept just an u8[32] bytes for the SSID, but not an ssid_len, 
> e.g. in the CMD_802_11_AD_HOC_START command.
> 
> You therefore can't connect to the otherwise legitimate SSID of 
> TEST\0\0\0.

Ick! I guess your cfg80211 IBSS join handler needs to check for that
then and refuse such an SSID.

johannes

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/libertas-dev/attachments/20091215/e6187294/attachment.sig>

From daniel at caiaq.de  Tue Dec 15 05:37:14 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Tue, 15 Dec 2009 18:37:14 +0800
Subject: [PATCH] wireless: wext: allocate space for NULL-termination
	for 32byte SSIDs
In-Reply-To: <1260873083.3692.8.camel@johannes.local>
References: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
	<20091215.014308.77044043.davem@davemloft.net>
	<1260871411.3692.4.camel@johannes.local>
	<1260871634.3692.6.camel@johannes.local>
	<20091215102035.GJ28375@buzzloop.caiaq.de>
	<1260873083.3692.8.camel@johannes.local>
Message-ID: <20091215103714.GK28375@buzzloop.caiaq.de>

On Tue, Dec 15, 2009 at 11:31:23AM +0100, Johannes Berg wrote:
> On Tue, 2009-12-15 at 18:20 +0800, Daniel Mack wrote:
> 
> > > drivers/net/wireless/libertas$ grep lbs_deb_ * | grep ssid|grep '%s'
> > > assoc.c:	lbs_deb_join("current SSID '%s', ssid length %u\n",
> > > assoc.c:	lbs_deb_join("requested ssid '%s', ssid length %u\n",
> > > assoc.c:	lbs_deb_join("ADHOC_START: SSID '%s', ssid length %u\n",
> > > scan.c:		lbs_deb_wext("set_scan, essid '%s'\n",
> > 
> > Those macros are stubbed out as nops in my setup, so they can
> > unfortunately not be the reason. I'll dig deeper :)
> 
> Well, the stack trace ought to help.

It unfortunately doesn't. The site that causes the problem does not
crash itself. It just corrupts some memory, and the actual crash happens
much later, which makes it so evil.

Daniel


From marcel at holtmann.org  Tue Dec 15 11:29:23 2009
From: marcel at holtmann.org (Marcel Holtmann)
Date: Tue, 15 Dec 2009 08:29:23 -0800
Subject: [PATCH] wireless: wext: allocate space for NULL-termination
	for 32byte SSIDs
In-Reply-To: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
References: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
Message-ID: <1260894563.4041.31.camel@localhost.localdomain>

Hi Daniel,

> We've experienced a long standing bug when quickly switching from
> ad-hoc to managed mode on a hardware using a Libertas chipset.

I don't know where you get your list of mailing lists from, but not
sending it to linux-wireless at vger.kernel.org will not really get you
anywhere. Check MAINTAINERS file first since it has all information
about it.

NETWORKING [WIRELESS]
M:      "John W. Linville" <linville at tuxdriver.com>
L:      linux-wireless at vger.kernel.org
T:      git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
S:      Maintained
F:      net/mac80211/
F:      net/rfkill/
F:      net/wireless/
F:      include/net/ieee80211*
F:      include/linux/wireless.h
F:      drivers/net/wireless/

Regards

Marcel




From admin at vkontakte.ru  Tue Dec 15 07:04:47 2009
From: admin at vkontakte.ru (VK)
Date: Tue, 15 Dec 2009 15:04:47 +0300
Subject: =?UTF-8?Q?=D0=92=D0=B0=D0=B4=D0=B8=D0=BC_=D0=91=D0=BB=D0=B8=D0=BD=D0=BE?=
	=?UTF-8?Q?=D0=B2_has_added_you_as_a_friend_on_the_website_VK.com?=
Message-ID: <11d1334bcc8c30f3da656b464a43cd26@localhost.localdomain>

libertas-dev,

????? ?????? has added you as a friend on the website VK.com

You can log in and view your friends` pages using your email and automatically created password: nssNXl2l

VK.com is a website that helps dozens of millions of people find their old friends, share photos and events and always stay in touch.

To log in, please follow this link:
http://vkontakte.ru/login.php?regemail=libertas-dev at lists.infradead.org#nssNXl2l

You can change your password in Settings.

Attention: If you ignore this invitation, your registration will not be activated.

Good luck!Best regards,
VK Administration




From daniel at caiaq.de  Tue Dec 15 22:58:44 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Wed, 16 Dec 2009 11:58:44 +0800
Subject: [PATCH] wireless: wext: allocate space for NULL-termination
	for 32byte SSIDs
In-Reply-To: <1260871411.3692.4.camel@johannes.local>
References: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
	<20091215.014308.77044043.davem@davemloft.net>
	<1260871411.3692.4.camel@johannes.local>
Message-ID: <20091216035844.GN28375@buzzloop.caiaq.de>

On Tue, Dec 15, 2009 at 11:03:31AM +0100, Johannes Berg wrote:
> 
> > > -	/* kzalloc() ensures NULL-termination for essid_compat. */
> > > -	extra = kzalloc(extra_size, GFP_KERNEL);
> > > +	/* kzalloc() +1 ensures NULL-termination for essid_compat. */
> > > +	extra = kzalloc(extra_size + 1, GFP_KERNEL);
> 
> That doesn't seem correct.
> 
> If this is used in a SET, then it is purely an in-kernel thing and
> everything in the kernel is passed the length + data, and the kernel
> MUST NEVER treat the SSID as a NUL-terminated string.
> 
> If this is used in a GET, then it will be filled up to 32 bytes by the
> get handler, and the trailing \0 your patch reserves will never be
> copied into userspace.

The problem is the GET case. The libertas driver copies ssid_len
characters here and appends a trailing \0, which my patch caught now and
which caused memory corruption in before.


From info at dollmansion.net  Tue Dec 15 23:00:18 2009
From: info at dollmansion.net (dollmansion)
Date: Wed, 16 Dec 2009 04:00:18 -0000
Subject: Pre Christmas Sale, Ball Joint Doll Why wait? 78546568
Message-ID: <20070101.LCTTLHGREEYIUXOI@dollmansion.net>

If you have trouble viewing this email click here. 
[Doll mansion]
We are BJD (ball joint dolls) accessories Manufacturer in Hong Kong, China, Our brand [dollmansion]. Here are accessories like?Shoes, Clothing, Furniture, Rococo gorgeous bird cage, European-Style Tea set, Pocket watch, Musical instrument and so on.  

If you are not a member, or received this email from a friend, and would like to join our Rewards program, click here.

You've received this message because you've registered to receive email from dollmansion.net. If you no longer wish to receive email from us click here.

View our privacy policy.
 
Contact Us click here.
www.dollmansion.net
 
 
48765 56 43587 6 64 858658326 5876 7846578
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/libertas-dev/attachments/20091216/2adef83f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: girl1.gif
Type: image/gif
Size: 18123 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libertas-dev/attachments/20091216/2adef83f/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: girl1_2.gif
Type: image/gif
Size: 9216 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/libertas-dev/attachments/20091216/2adef83f/attachment-0001.gif>

From daniel at caiaq.de  Tue Dec 15 23:12:58 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Wed, 16 Dec 2009 05:12:58 +0100
Subject: [PATCH] Libertas: fix buffer overflow in lbs_get_essid()
Message-ID: <1260936778-2096-1-git-send-email-daniel@caiaq.de>

The libertas driver copies the SSID buffer back to the wireless core and
appends a trailing NULL character for termination. This is

a) unnecessary because the buffer is allocated with kzalloc and is hence
   already NULLed when this function is called, and

b) for priv->curbssparams.ssid_len == 32, it writes back one byte too
   much which causes memory corruptions.

Fix this by removing the extra write.

Signed-off-by: Daniel Mack <daniel at caiaq.de>
Cc: Dan Williams <dcbw at redhat.com>
Cc: Holger Schurig <holgerschurig at gmail.com>
Cc: John W. Linville <linville at tuxdriver.com>
Cc: Stephen Hemminger <shemminger at vyatta.com>
Cc: Maithili Hinge <maithili at marvell.com>
Cc: Kiran Divekar <dkiran at marvell.com>
Cc: Michael Hirsch <m.hirsch at raumfeld.com>
Cc: netdev at vger.kernel.org
Cc: libertas-dev at lists.infradead.org
Cc: linux-wireless at lists.infradead.org
Cc: stable at kernel.org
---
 drivers/net/wireless/libertas/wext.c |    2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/libertas/wext.c b/drivers/net/wireless/libertas/wext.c
index be837a0..01c738b 100644
--- a/drivers/net/wireless/libertas/wext.c
+++ b/drivers/net/wireless/libertas/wext.c
@@ -1953,10 +1953,8 @@ static int lbs_get_essid(struct net_device *dev, struct iw_request_info *info,
 	if (priv->connect_status == LBS_CONNECTED) {
 		memcpy(extra, priv->curbssparams.ssid,
 		       priv->curbssparams.ssid_len);
-		extra[priv->curbssparams.ssid_len] = '\0';
 	} else {
 		memset(extra, 0, 32);
-		extra[priv->curbssparams.ssid_len] = '\0';
 	}
 	/*
 	 * If none, we may want to get the one that was set
-- 
1.6.3.3



From daniel at caiaq.de  Tue Dec 15 23:18:06 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Wed, 16 Dec 2009 12:18:06 +0800
Subject: [PATCH] Libertas: fix buffer overflow in lbs_get_essid()
In-Reply-To: <1260936778-2096-1-git-send-email-daniel@caiaq.de>
References: <1260936778-2096-1-git-send-email-daniel@caiaq.de>
Message-ID: <20091216041805.GO28375@buzzloop.caiaq.de>

(Sorry, had a typo in the linux-wireless list address, corrected now).

On Wed, Dec 16, 2009 at 05:12:58AM +0100, Daniel Mack wrote:
> 
> The libertas driver copies the SSID buffer back to the wireless core and
> appends a trailing NULL character for termination. This is
> 
> a) unnecessary because the buffer is allocated with kzalloc and is hence
>    already NULLed when this function is called, and
> 
> b) for priv->curbssparams.ssid_len == 32, it writes back one byte too
>    much which causes memory corruptions.
> 
> Fix this by removing the extra write.
> 
> Signed-off-by: Daniel Mack <daniel at caiaq.de>
> Cc: Dan Williams <dcbw at redhat.com>
> Cc: Holger Schurig <holgerschurig at gmail.com>
> Cc: John W. Linville <linville at tuxdriver.com>
> Cc: Stephen Hemminger <shemminger at vyatta.com>
> Cc: Maithili Hinge <maithili at marvell.com>
> Cc: Kiran Divekar <dkiran at marvell.com>
> Cc: Michael Hirsch <m.hirsch at raumfeld.com>
> Cc: netdev at vger.kernel.org
> Cc: libertas-dev at lists.infradead.org
> Cc: linux-wireless at lists.infradead.org
> Cc: stable at kernel.org
> ---
>  drivers/net/wireless/libertas/wext.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/libertas/wext.c b/drivers/net/wireless/libertas/wext.c
> index be837a0..01c738b 100644
> --- a/drivers/net/wireless/libertas/wext.c
> +++ b/drivers/net/wireless/libertas/wext.c
> @@ -1953,10 +1953,8 @@ static int lbs_get_essid(struct net_device *dev, struct iw_request_info *info,
>  	if (priv->connect_status == LBS_CONNECTED) {
>  		memcpy(extra, priv->curbssparams.ssid,
>  		       priv->curbssparams.ssid_len);
> -		extra[priv->curbssparams.ssid_len] = '\0';
>  	} else {
>  		memset(extra, 0, 32);
> -		extra[priv->curbssparams.ssid_len] = '\0';
>  	}
>  	/*
>  	 * If none, we may want to get the one that was set
> -- 
> 1.6.3.3
> 


From acahalan at gmail.com  Wed Dec 16 01:54:26 2009
From: acahalan at gmail.com (Albert Cahalan)
Date: Wed, 16 Dec 2009 01:54:26 -0500
Subject: [PATCH] wireless: wext: allocate space for NULL-termination for 
	32byte SSIDs
In-Reply-To: <1260873307.3692.10.camel@johannes.local>
References: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
	<1260871411.3692.4.camel@johannes.local>
	<1260871634.3692.6.camel@johannes.local>
	<200912151130.59103.holgerschurig@gmail.com>
	<1260873307.3692.10.camel@johannes.local>
Message-ID: <787b0d920912152254r4bd3e1e2l14fbe7c1fdf42e60@mail.gmail.com>

On Tue, Dec 15, 2009 at 5:35 AM, Johannes Berg
<johannes at sipsolutions.net> wrote:
> On Tue, 2009-12-15 at 11:30 +0100, Holger Schurig wrote:
>> > drivers/net/wireless/libertas$ grep lbs_deb_ * | grep ssid
>> > |grep '%s'
>> > assoc.c:    lbs_deb_join("current SSID '%s', ssid length %u\n",
>> > assoc.c:    lbs_deb_join("requested ssid '%s', ssid length %u\n",
>> > assoc.c:    lbs_deb_join("ADHOC_START: SSID '%s', ssid
>> >               length %u\n",
>> > scan.c:             lbs_deb_wext("set_scan, essid '%s'\n",
>>
>> All those lines are gone once my cfg80211 lands.
>>
>> Do you know any way to make sparse moan about them?
>
> Sorry, no, I don't think that's even possible unless you play dirty with
> tricks like __iomem uses for instance but that'd require a lot of
> casting in otherwise valid uses.
>
>> BTW: the libertas firmware sometimes treat an SSID as a
>> zero-terminated string. There are some firmware commands that
>> accept just an u8[32] bytes for the SSID, but not an ssid_len,
>> e.g. in the CMD_802_11_AD_HOC_START command.
>>
>> You therefore can't connect to the otherwise legitimate SSID of
>> TEST\0\0\0.
>
> Ick! I guess your cfg80211 IBSS join handler needs to check for that
> then and refuse such an SSID.

No, pad the SSID out to 32 bytes and let the firmware try.

First of all, isn't TEST\0\0\0 simply the wrong length anyway?
(that is, a length other than 32 is nonsense AFAIK)

Second of all, even if that is valid, the firmware probably handles
at least one SSID that starts with TEST and has some number
of NUL bytes on the end. Since you can't tell what that would be
with a particular firmware version, you might as well just let the
firmware try. The worst case failure here is that there is more than
one SSID of this form and you connect to the wrong one. If you
have a problem with this kind of trouble then you need ethernet.


From holgerschurig at gmail.com  Wed Dec 16 03:15:35 2009
From: holgerschurig at gmail.com (Holger Schurig)
Date: Wed, 16 Dec 2009 09:15:35 +0100
Subject: [PATCH] Libertas: fix buffer overflow in lbs_get_essid()
In-Reply-To: <1260936778-2096-1-git-send-email-daniel@caiaq.de>
References: <1260936778-2096-1-git-send-email-daniel@caiaq.de>
Message-ID: <200912160915.35540.holgerschurig@gmail.com>

As Dan didn't answer:

Acked-by: Holger Schurig <holgerschurig at gmail.com>

-- 
http://www.holgerschurig.de


From johannes at sipsolutions.net  Wed Dec 16 03:19:37 2009
From: johannes at sipsolutions.net (Johannes Berg)
Date: Wed, 16 Dec 2009 09:19:37 +0100
Subject: [PATCH] wireless: wext: allocate space for NULL-termination
	for 32byte SSIDs
In-Reply-To: <787b0d920912152254r4bd3e1e2l14fbe7c1fdf42e60@mail.gmail.com>
References: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
	<1260871411.3692.4.camel@johannes.local>
	<1260871634.3692.6.camel@johannes.local>
	<200912151130.59103.holgerschurig@gmail.com>
	<1260873307.3692.10.camel@johannes.local>
	<787b0d920912152254r4bd3e1e2l14fbe7c1fdf42e60@mail.gmail.com>
Message-ID: <1260951577.10356.60.camel@johannes.local>

On Wed, 2009-12-16 at 01:54 -0500, Albert Cahalan wrote:

> >> You therefore can't connect to the otherwise legitimate SSID of
> >> TEST\0\0\0.
> >
> > Ick! I guess your cfg80211 IBSS join handler needs to check for that
> > then and refuse such an SSID.
> 
> No, pad the SSID out to 32 bytes and let the firmware try.

No, if we _know_ the firmware will try to connect to "TEST" instead of
"TEST\0\0\0" then refusing it is the right thing to do.

> First of all, isn't TEST\0\0\0 simply the wrong length anyway?
> (that is, a length other than 32 is nonsense AFAIK)

No.

> Second of all, even if that is valid, the firmware probably handles
> at least one SSID that starts with TEST and has some number
> of NUL bytes on the end. Since you can't tell what that would be
> with a particular firmware version, you might as well just let the
> firmware try. The worst case failure here is that there is more than
> one SSID of this form and you connect to the wrong one. If you
> have a problem with this kind of trouble then you need ethernet.

No. An SSID is a uniquely defined, 1-32 byte long byte bit pattern. It
doesn't treat \0 special in any way as your comments suggest. If the
firmware stops matching at \0, the firmware is broken and shouldn't be
given a choice.

johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/libertas-dev/attachments/20091216/4e388280/attachment.sig>

From holgerschurig at gmail.com  Wed Dec 16 03:26:13 2009
From: holgerschurig at gmail.com (Holger Schurig)
Date: Wed, 16 Dec 2009 09:26:13 +0100
Subject: [PATCH] wireless: wext: allocate space for NULL-termination for
	32byte SSIDs
In-Reply-To: <787b0d920912152254r4bd3e1e2l14fbe7c1fdf42e60@mail.gmail.com>
References: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
	<1260873307.3692.10.camel@johannes.local>
	<787b0d920912152254r4bd3e1e2l14fbe7c1fdf42e60@mail.gmail.com>
Message-ID: <200912160926.14062.holgerschurig@gmail.com>

> First of all, isn't TEST\0\0\0 simply the wrong length anyway?
> (that is, a length other than 32 is nonsense AFAIK)

No, the SSID IE in a beacon encodes also a length. So the beacons 
from SSID of TEST, TEST\0 and TEST\0\0\0 are different.

This is because in the beacon, the SSID is *NOT* an u8[32], but 
an IE, which is struct { u8 type, u8 length, u8 data[] };

-- 
http://www.holgerschurig.de


From johannes at sipsolutions.net  Wed Dec 16 03:20:33 2009
From: johannes at sipsolutions.net (Johannes Berg)
Date: Wed, 16 Dec 2009 09:20:33 +0100
Subject: [PATCH] wireless: wext: allocate space for NULL-termination
	for 32byte SSIDs
In-Reply-To: <20091216035844.GN28375@buzzloop.caiaq.de>
References: <1260650850-16163-1-git-send-email-daniel@caiaq.de>
	<20091215.014308.77044043.davem@davemloft.net>
	<1260871411.3692.4.camel@johannes.local>
	<20091216035844.GN28375@buzzloop.caiaq.de>
Message-ID: <1260951633.10356.61.camel@johannes.local>

On Wed, 2009-12-16 at 11:58 +0800, Daniel Mack wrote:

> > If this is used in a GET, then it will be filled up to 32 bytes by the
> > get handler, and the trailing \0 your patch reserves will never be
> > copied into userspace.
> 
> The problem is the GET case. The libertas driver copies ssid_len
> characters here and appends a trailing \0, which my patch caught now and
> which caused memory corruption in before.
> 
> From what I've seen, libertas _does_ treat the extra data correctly
> at all places, I checked it several times now. (Btw, the %s format
> string you pointed out all use print_ssid() to properly escape all
> non-printable characters, so they're rules out, too).

Oh, ok, print_ssid() is correct of course, it gets the length.

> I'll send a patch to fix the flaw in libertas.

Thanks.

johannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.infradead.org/pipermail/libertas-dev/attachments/20091216/83153cce/attachment-0001.sig>

From dcbw at redhat.com  Wed Dec 16 11:57:47 2009
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 16 Dec 2009 08:57:47 -0800
Subject: [PATCH] Libertas: fix buffer overflow in lbs_get_essid()
In-Reply-To: <1260936778-2096-1-git-send-email-daniel@caiaq.de>
References: <1260936778-2096-1-git-send-email-daniel@caiaq.de>
Message-ID: <1260982667.2179.9.camel@localhost.localdomain>

On Wed, 2009-12-16 at 05:12 +0100, Daniel Mack wrote:
> The libertas driver copies the SSID buffer back to the wireless core and
> appends a trailing NULL character for termination. This is
> 
> a) unnecessary because the buffer is allocated with kzalloc and is hence
>    already NULLed when this function is called, and
> 
> b) for priv->curbssparams.ssid_len == 32, it writes back one byte too
>    much which causes memory corruptions.
> 
> Fix this by removing the extra write.

Acked-by: Dan Williams <dcbw at redhat.com>

> Signed-off-by: Daniel Mack <daniel at caiaq.de>
> Cc: Dan Williams <dcbw at redhat.com>
> Cc: Holger Schurig <holgerschurig at gmail.com>
> Cc: John W. Linville <linville at tuxdriver.com>
> Cc: Stephen Hemminger <shemminger at vyatta.com>
> Cc: Maithili Hinge <maithili at marvell.com>
> Cc: Kiran Divekar <dkiran at marvell.com>
> Cc: Michael Hirsch <m.hirsch at raumfeld.com>
> Cc: netdev at vger.kernel.org
> Cc: libertas-dev at lists.infradead.org
> Cc: linux-wireless at lists.infradead.org
> Cc: stable at kernel.org
> ---
>  drivers/net/wireless/libertas/wext.c |    2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/libertas/wext.c b/drivers/net/wireless/libertas/wext.c
> index be837a0..01c738b 100644
> --- a/drivers/net/wireless/libertas/wext.c
> +++ b/drivers/net/wireless/libertas/wext.c
> @@ -1953,10 +1953,8 @@ static int lbs_get_essid(struct net_device *dev, struct iw_request_info *info,
>  	if (priv->connect_status == LBS_CONNECTED) {
>  		memcpy(extra, priv->curbssparams.ssid,
>  		       priv->curbssparams.ssid_len);
> -		extra[priv->curbssparams.ssid_len] = '\0';
>  	} else {
>  		memset(extra, 0, 32);
> -		extra[priv->curbssparams.ssid_len] = '\0';
>  	}
>  	/*
>  	 * If none, we may want to get the one that was set



From daniel at caiaq.de  Wed Dec 16 18:15:08 2009
From: daniel at caiaq.de (Daniel Mack)
Date: Thu, 17 Dec 2009 07:15:08 +0800
Subject: [PATCH] Libertas: fix buffer overflow in lbs_get_essid()
In-Reply-To: <1260982667.2179.9.camel@localhost.localdomain>
References: <1260936778-2096-1-git-send-email-daniel@caiaq.de>
	<1260982667.2179.9.camel@localhost.localdomain>
Message-ID: <20091216231508.GX28375@buzzloop.caiaq.de>

On Wed, Dec 16, 2009 at 08:57:47AM -0800, Dan Williams wrote:
> On Wed, 2009-12-16 at 05:12 +0100, Daniel Mack wrote:
> > The libertas driver copies the SSID buffer back to the wireless core and
> > appends a trailing NULL character for termination. This is
> > 
> > a) unnecessary because the buffer is allocated with kzalloc and is hence
> >    already NULLed when this function is called, and
> > 
> > b) for priv->curbssparams.ssid_len == 32, it writes back one byte too
> >    much which causes memory corruptions.
> > 
> > Fix this by removing the extra write.
> 
> Acked-by: Dan Williams <dcbw at redhat.com>

Thanks, everyone. Who will care to pick an queue this one?

Daniel


> > Signed-off-by: Daniel Mack <daniel at caiaq.de>
> > Cc: Dan Williams <dcbw at redhat.com>
> > Cc: Holger Schurig <holgerschurig at gmail.com>
> > Cc: John W. Linville <linville at tuxdriver.com>
> > Cc: Stephen Hemminger <shemminger at vyatta.com>
> > Cc: Maithili Hinge <maithili at marvell.com>
> > Cc: Kiran Divekar <dkiran at marvell.com>
> > Cc: Michael Hirsch <m.hirsch at raumfeld.com>
> > Cc: netdev at vger.kernel.org
> > Cc: libertas-dev at lists.infradead.org
> > Cc: linux-wireless at lists.infradead.org
> > Cc: stable at kernel.org
> > ---
> >  drivers/net/wireless/libertas/wext.c |    2 --
> >  1 files changed, 0 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/net/wireless/libertas/wext.c b/drivers/net/wireless/libertas/wext.c
> > index be837a0..01c738b 100644
> > --- a/drivers/net/wireless/libertas/wext.c
> > +++ b/drivers/net/wireless/libertas/wext.c
> > @@ -1953,10 +1953,8 @@ static int lbs_get_essid(struct net_device *dev, struct iw_request_info *info,
> >  	if (priv->connect_status == LBS_CONNECTED) {
> >  		memcpy(extra, priv->curbssparams.ssid,
> >  		       priv->curbssparams.ssid_len);
> > -		extra[priv->curbssparams.ssid_len] = '\0';
> >  	} else {
> >  		memset(extra, 0, 32);
> > -		extra[priv->curbssparams.ssid_len] = '\0';
> >  	}
> >  	/*
> >  	 * If none, we may want to get the one that was set
> 


From linville at tuxdriver.com  Wed Dec 16 20:01:15 2009
From: linville at tuxdriver.com (John W. Linville)
Date: Wed, 16 Dec 2009 20:01:15 -0500
Subject: [PATCH] Libertas: fix buffer overflow in lbs_get_essid()
In-Reply-To: <20091216231508.GX28375@buzzloop.caiaq.de>
References: <1260936778-2096-1-git-send-email-daniel@caiaq.de>
	<1260982667.2179.9.camel@localhost.localdomain>
	<20091216231508.GX28375@buzzloop.caiaq.de>
Message-ID: <20091217010114.GA2913@tuxdriver.com>

On Thu, Dec 17, 2009 at 07:15:08AM +0800, Daniel Mack wrote:
> On Wed, Dec 16, 2009 at 08:57:47AM -0800, Dan Williams wrote:
> > On Wed, 2009-12-16 at 05:12 +0100, Daniel Mack wrote:
> > > The libertas driver copies the SSID buffer back to the wireless core and
> > > appends a trailing NULL character for termination. This is
> > > 
> > > a) unnecessary because the buffer is allocated with kzalloc and is hence
> > >    already NULLed when this function is called, and
> > > 
> > > b) for priv->curbssparams.ssid_len == 32, it writes back one byte too
> > >    much which causes memory corruptions.
> > > 
> > > Fix this by removing the extra write.
> > 
> > Acked-by: Dan Williams <dcbw at redhat.com>
> 
> Thanks, everyone. Who will care to pick an queue this one?

Is there some reason it wouldn't be me?

John
-- 
John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you
linville at tuxdriver.com ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.


From dcbw at redhat.com  Wed Dec 16 20:19:12 2009
From: dcbw at redhat.com (Dan Williams)
Date: Wed, 16 Dec 2009 17:19:12 -0800
Subject: [PATCH] Libertas: fix buffer overflow in lbs_get_essid()
In-Reply-To: <20091217010114.GA2913@tuxdriver.com>
References: <1260936778-2096-1-git-send-email-daniel@caiaq.de>
	<1260982667.2179.9.camel@localhost.localdomain>
	<20091216231508.GX28375@buzzloop.caiaq.de>
	<20091217010114.GA2913@tuxdriver.com>
Message-ID: <1261012752.17721.8.camel@localhost.localdomain>

On Wed, 2009-12-16 at 20:01 -0500, John W. Linville wrote:
> On Thu, Dec 17, 2009 at 07:15:08AM +0800, Daniel Mack wrote:
> > On Wed, Dec 16, 2009 at 08:57:47AM -0800, Dan Williams wrote:
> > > On Wed, 2009-12-16 at 05:12 +0100, Daniel Mack wrote:
> > > > The libertas driver copies the SSID buffer back to the wireless core and
> > > > appends a trailing NULL character for termination. This is
> > > > 
> > > > a) unnecessary because the buffer is allocated with kzalloc and is hence
> > > >    already NULLed when this function is called, and
> > > > 
> > > > b) for priv->curbssparams.ssid_len == 32, it writes back one byte too
> > > >    much which causes memory corruptions.
> > > > 
> > > > Fix this by removing the extra write.
> > > 
> > > Acked-by: Dan Williams <dcbw at redhat.com>
> > 
> > Thanks, everyone. Who will care to pick an queue this one?
> 
> Is there some reason it wouldn't be me?

No, it should be you.  Please suck it into your 2.6.33 patchset and
we'll cc to stable when it hits linus I guess.

Dan




From dsaxena at laptop.org  Sat Dec 19 01:31:01 2009
From: dsaxena at laptop.org (Deepak Saxena)
Date: Fri, 18 Dec 2009 22:31:01 -0800
Subject: BUG() in if_sdio_handle_cmd()
Message-ID: <20091219063101.GA29952@plexity.net>



We (OLPC) are working on stress testing of the suspend/resume path and
in the process hit the "BUG_ON(priv->resp_len[i])" in if_sdio_handle_command().
This can easily be reproduced by  a suspend/resume loop while
running a ping from a host to the unit under test. From my reading
of this code, what this looks like some sort of race where we're getting 
response before we have completed processing the previous one (as
the driver can only handle 1 response at a time from my reading of 
the code). We first saw this issue when the host -> libertas ping 
was a flood but we can also reproduce it using a non-flood ping. 

If we change the debug level to 0x404000, this BUG() goes away,
though we then start seeing other issues (tx timeouts and
warnings due to list corruption when queueing commands). 
If we set the debug level to either 0x400000 or 0x4000 we
do hit the bug.

A bug like this was reported last year by Jeff Sutherland 
(http://lists.infradead.org/pipermail/libertas-dev/2008-October/001994.html)
and it appears that there was no resolution in terms of a fix to driver 
of firmware (at least not one that is publically posted). Was a
solution found and not posted or is this still an unresolved
issue? 

The OLPC bug can be seen at http://dev.laptop.org/ticket/9836.

[  164.040152] Kernel BUG at cb9c970f [verbose debug info unavailable]          
[  164.040152] invalid opcode: 0000 [#1] PREEMPT                                
[  164.040152] last sysfs file: /sys/power/state                                
[  164.040152] Modules linked in: fuse uinput videobuf_dma_contig videobuf_core 
mousedev psmouse serio_raw libertas_sdio libertas lib80211 [last unloaded: scsi_
wait_scan]                                                                      
[  164.040152]                                                                  
[  164.040152] Pid: 2649, comm: ksdioirqd/mmc1 Not tainted (2.6.31.6 #1) XO     
[  164.040152] EIP: 0060:[<cb9c970f>] EFLAGS: 00010002 CPU: 0                   
[  164.040152] EIP is at if_sdio_interrupt+0x3f7/0x7c8 [libertas_sdio]          
[  164.040152] EAX: 0000075d EBX: caf40000 ECX: ca78c340 EDX: 00000001          
[  164.040152] ESI: ca78c340 EDI: 0000004c EBP: ca3bdf78 ESP: ca3bdf50          
[  164.040152]  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068                    
[  164.040152] Process ksdioirqd/mmc1 (pid: 2649, ti=ca3bd000 task=cad30500 task
.ti=ca3bd000)                                                                   
[  164.040152] Stack:                                                           
[  164.040152]  00000000 00000286 ca78c340 0000004c 00000000 00000000 00000000 0
0000000                                                                         
[  164.040152] <0> c99a1318 7fffffff ca3bdfac b0674543 c99bc080 00000000 c99bc21
4 00000001                                                                      
[  164.040152] <0> c99a1318 00000001 00000001 02000000 cac83db4 c99bc080 b067445
f ca3bdfe0                                                                      
[  164.040152] Call Trace:                                                      
[  164.040152]  [<b0674543>] ? sdio_irq_thread+0xe4/0x1d1                       
[  164.040152]  [<b067445f>] ? sdio_irq_thread+0x0/0x1d1                        
[  164.040152]  [<b0432849>] ? kthread+0x6d/0x72                                
[  164.040152]  [<b04327dc>] ? kthread+0x0/0x72                                 
[  164.040152]  [<b0403103>] ? kernel_thread_helper+0x7/0x10                    
[  164.040152] Code: 98 1d 00 00 e8 46 1c d9 e4 31 d2 8b 4d e0 89 45 dc 8b 45 e0
 80 b8 68 0b 00 00 00 0f 94 c2 8d 82 5c 07 00 00 83 7c 81 0c 00 74 04 <0f> 0b eb
 fe 8b 75 e0 8b 4d e4 89 4c 86 0c 69 c2 08 09 00 00 8b                          
[  164.040152] EIP: [<cb9c970f>] if_sdio_interrupt+0x3f7/0x7c8 [libertas_sdio] S
S:ESP 0068:ca3bdf50   



From lijinlei1 at 163.com  Mon Dec 21 21:14:03 2009
From: lijinlei1 at 163.com (Ivan Li)
Date: Tue, 22 Dec 2009 10:14:03 +0800
Subject: How to keep sd8686 transmitting data using a fixed channel?
Message-ID: <396CBD798C84450E93516E0B7DBCDEB2@ivan>

Hi guys,

We are doing a test to find out the transmitting power of the sd8686, which is needed by SAR.
I am wondering if libertas has some programming interface to set the freqency (channel) and issue an infinite data Tx?

Thanks.

From norbert at nroos.de  Tue Dec 22 09:00:49 2009
From: norbert at nroos.de (Norbert Roos)
Date: Tue, 22 Dec 2009 15:00:49 +0100
Subject: High power consumption after suspending
Message-ID: <4B30D111.3070709@nroos.de>

Hello,

We are developing a mobile device here, using a 88W8686. We discovered a 
rather high power consumption during sleep with about 100mA more than 
when the driver is not loaded and the chip is powered down with pin PDn. 
We are using a 2.6.27.3 kernel and if_spi.

I would like to reduce this current now, but so far i didn't find any 
information about what has to be actually done for putting the chip into 
a low power mode. From the source code i see that the suspend function 
sends a CMD_802_11_HOST_SLEEP_ACTIVATE, which is obviously succesful 
(didn't return an error, and the callback function has also been called) 
but does not power down the chip.

So my overall question is, what should be done to power down the chip? 
Should the HOST_SLEEP_ACTIVATE command be sufficient and we have a 
different problem here with our device?

Or should do it the deep sleep command? I have already looked at the 
deep sleep patch from september, but i don't understand why there has to 
be a timer and an interface to user space; in my understanding the 
driver gets somewhen told "And now suspend yourself!" and that should be 
all... Anyway, i tried also to send the CMD_802_11_DEEP_SLEEP following 
the HOST_SLEEP_ACTIVATE, resulting in a completely dead device.

Or is setting the PDn pin the only way to power down the chip? Or is 
there another way applicable?

And another question: Will an established WLAN connection survive the 
power-down and power-up, or does it have to be reconnected (which will 
probably terminate a TCP connection running over the WLAN connection)?

Any help is appreciated, and thanks in advance!

Norbert


From dsd at laptop.org  Thu Dec 24 14:48:44 2009
From: dsd at laptop.org (Daniel Drake)
Date: Thu, 24 Dec 2009 19:48:44 +0000
Subject: slab corruption on XO-1 (mesh related?)
Message-ID: <1261684124.2140.16.camel@localhost.localdomain>

I think this is a 2.6.31 regression. I don't have time to investigate
right now.

To reproduce I just connected to the mesh on msh0, disconnect from the
mesh and connect to an access point on eth0.

Then things go a bit wrong and this appears in the logs, repeatedly:

[  310.921753] slab error in verify_redzone_free(): cache `size-32':
memory outside object was overwritten
[  310.921796] Pid: 1805, comm: wpa_supplicant Tainted: G        W
2.6.31_xo1-20091224.1735.1.olpc.bd1f1e9 #1
[  310.921821] Call Trace:
[  310.921871]  [<c06a7016>] ? printk+0xf/0x11
[  310.921917]  [<c047e552>] __slab_error+0x17/0x1c
[  310.921955]  [<c047eb7b>] cache_free_debugcheck+0x10a/0x1b8
[  310.921988]  [<c06a074b>] ? ioctl_standard_call+0x23e/0x280
[  310.922025]  [<c047eded>] kfree+0xc0/0xf0
[  310.922057]  [<c06a074b>] ioctl_standard_call+0x23e/0x280
[  310.922103]  [<c0621820>] ? __dev_get_by_name+0x6d/0x7a
[  310.922138]  [<c0621820>] ? __dev_get_by_name+0x6d/0x7a
[  310.922172]  [<c06a085b>] wext_handle_ioctl+0xce/0x157
[  310.922305]  [<cf8ffc6a>] ? lbs_get_essid+0x0/0xef [libertas]
[  310.922341]  [<c06254af>] dev_ioctl+0x567/0x587
[  310.922383]  [<c0617528>] ? sys_sendto+0xa1/0xc0
[  310.922419]  [<c0617f96>] ? sys_recvfrom+0x99/0xba
[  310.922454]  [<c056e11e>] ? copy_from_user+0x32/0x78
[  310.922489]  [<c06169d8>] sock_ioctl+0x1ef/0x1fb
[  310.922521]  [<c06167e9>] ? sock_ioctl+0x0/0x1fb
[  310.922557]  [<c048f86e>] vfs_ioctl+0x18/0x6f
[  310.922591]  [<c048fe6f>] do_vfs_ioctl+0x4ef/0x52d
[  310.922627]  [<c061755f>] ? sys_send+0x18/0x1a
[  310.922662]  [<c061832f>] ? sys_socketcall+0xc5/0x16b
[  310.922695]  [<c048feee>] sys_ioctl+0x41/0x61
[  310.922730]  [<c04033d4>] sysenter_do_call+0x12/0x26
[  310.922762] ccfaad30: redzone 1:0xd84156c5635688c0, redzone
2:0xd84156c563568800.

Running "iwconfig" causes the exact same trace.

Daniel




From dcbw at redhat.com  Fri Dec 25 14:33:13 2009
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 25 Dec 2009 13:33:13 -0600
Subject: BUG() in if_sdio_handle_cmd()
In-Reply-To: <20091219063101.GA29952@plexity.net>
References: <20091219063101.GA29952@plexity.net>
Message-ID: <1261769593.2138.35.camel@localhost.localdomain>

On Fri, 2009-12-18 at 22:31 -0800, Deepak Saxena wrote:
> 
> We (OLPC) are working on stress testing of the suspend/resume path and
> in the process hit the "BUG_ON(priv->resp_len[i])" in if_sdio_handle_command().
> This can easily be reproduced by  a suspend/resume loop while
> running a ping from a host to the unit under test. From my reading
> of this code, what this looks like some sort of race where we're getting 
> response before we have completed processing the previous one (as
> the driver can only handle 1 response at a time from my reading of 
> the code). We first saw this issue when the host -> libertas ping 
> was a flood but we can also reproduce it using a non-flood ping. 

The driver only handles one command at a time because the firmware spec
also says that the firmware only handles one command at a time.  But
this issue would indicate some issues in the driver lock somewhere.
Since priv->resp_len is supposed to be protected by the driver lock.

> If we change the debug level to 0x404000, this BUG() goes away,
> though we then start seeing other issues (tx timeouts and
> warnings due to list corruption when queueing commands). 
> If we set the debug level to either 0x400000 or 0x4000 we
> do hit the bug.
> 
> A bug like this was reported last year by Jeff Sutherland 
> (http://lists.infradead.org/pipermail/libertas-dev/2008-October/001994.html)
> and it appears that there was no resolution in terms of a fix to driver 
> of firmware (at least not one that is publically posted). Was a
> solution found and not posted or is this still an unresolved
> issue? 

I don't think a solution was found because I couldn't really reproduce
it, but that could be due to lack of heavy stress-testing of the driver
itself.  The SDIO code is also somewhat less stress-tested than the USB
code obviously since it's quite a bit newer and hasn't had millions of
deployed units :(

Can you take a quick look at the locking code around priv->resp_len and
see if anything jumps out at you?  The driver's locking and threading
structure could use a bit of a cleanup surely.

Dan


> The OLPC bug can be seen at http://dev.laptop.org/ticket/9836.
> 
> [  164.040152] Kernel BUG at cb9c970f [verbose debug info unavailable]          
> [  164.040152] invalid opcode: 0000 [#1] PREEMPT                                
> [  164.040152] last sysfs file: /sys/power/state                                
> [  164.040152] Modules linked in: fuse uinput videobuf_dma_contig videobuf_core 
> mousedev psmouse serio_raw libertas_sdio libertas lib80211 [last unloaded: scsi_
> wait_scan]                                                                      
> [  164.040152]                                                                  
> [  164.040152] Pid: 2649, comm: ksdioirqd/mmc1 Not tainted (2.6.31.6 #1) XO     
> [  164.040152] EIP: 0060:[<cb9c970f>] EFLAGS: 00010002 CPU: 0                   
> [  164.040152] EIP is at if_sdio_interrupt+0x3f7/0x7c8 [libertas_sdio]          
> [  164.040152] EAX: 0000075d EBX: caf40000 ECX: ca78c340 EDX: 00000001          
> [  164.040152] ESI: ca78c340 EDI: 0000004c EBP: ca3bdf78 ESP: ca3bdf50          
> [  164.040152]  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068                    
> [  164.040152] Process ksdioirqd/mmc1 (pid: 2649, ti=ca3bd000 task=cad30500 task
> .ti=ca3bd000)                                                                   
> [  164.040152] Stack:                                                           
> [  164.040152]  00000000 00000286 ca78c340 0000004c 00000000 00000000 00000000 0
> 0000000                                                                         
> [  164.040152] <0> c99a1318 7fffffff ca3bdfac b0674543 c99bc080 00000000 c99bc21
> 4 00000001                                                                      
> [  164.040152] <0> c99a1318 00000001 00000001 02000000 cac83db4 c99bc080 b067445
> f ca3bdfe0                                                                      
> [  164.040152] Call Trace:                                                      
> [  164.040152]  [<b0674543>] ? sdio_irq_thread+0xe4/0x1d1                       
> [  164.040152]  [<b067445f>] ? sdio_irq_thread+0x0/0x1d1                        
> [  164.040152]  [<b0432849>] ? kthread+0x6d/0x72                                
> [  164.040152]  [<b04327dc>] ? kthread+0x0/0x72                                 
> [  164.040152]  [<b0403103>] ? kernel_thread_helper+0x7/0x10                    
> [  164.040152] Code: 98 1d 00 00 e8 46 1c d9 e4 31 d2 8b 4d e0 89 45 dc 8b 45 e0
>  80 b8 68 0b 00 00 00 0f 94 c2 8d 82 5c 07 00 00 83 7c 81 0c 00 74 04 <0f> 0b eb
>  fe 8b 75 e0 8b 4d e4 89 4c 86 0c 69 c2 08 09 00 00 8b                          
> [  164.040152] EIP: [<cb9c970f>] if_sdio_interrupt+0x3f7/0x7c8 [libertas_sdio] S
> S:ESP 0068:ca3bdf50   
> 
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev



From dcbw at redhat.com  Fri Dec 25 15:01:12 2009
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 25 Dec 2009 14:01:12 -0600
Subject: High power consumption after suspending
In-Reply-To: <4B30D111.3070709@nroos.de>
References: <4B30D111.3070709@nroos.de>
Message-ID: <1261771272.2138.63.camel@localhost.localdomain>

On Tue, 2009-12-22 at 15:00 +0100, Norbert Roos wrote:
> Hello,
> 
> We are developing a mobile device here, using a 88W8686. We discovered a 
> rather high power consumption during sleep with about 100mA more than 
> when the driver is not loaded and the chip is powered down with pin PDn. 
> We are using a 2.6.27.3 kernel and if_spi.

So the 2.6.27 kernel, and the 2.6.27 *driver*?  The SDIO bits were only
merged in 2.6.27 so they are a bit old at that point.  SDIO deep sleep
support has recently been added to 2.6.31 or 2.6.32 and that's probably
what you're looking for.  Deep sleep actually puts the chip to sleep,
where previous sleep support was limited to USB bus suspends and
OLPC-style suspend/resume.

Any chance you can try to backport the 2.6.32 driver to your kernel (it
shouldn't be that hard actually, usually just backing out a few cleanup
patches and such as kernel interfaces change) and see if the deep sleep
support there will work for you?

> I would like to reduce this current now, but so far i didn't find any 
> information about what has to be actually done for putting the chip into 
> a low power mode. From the source code i see that the suspend function 
> sends a CMD_802_11_HOST_SLEEP_ACTIVATE, which is obviously succesful 
> (didn't return an error, and the callback function has also been called) 
> but does not power down the chip.

What firmware version?

HOST_SLEEP is used to tell the 8686 that the /host/ is going to sleep,
not to put the chip to sleep.  You really do want DEEP_SLEEP.  So it's
no wonder that HOST_SLEEP wasn't doing anything.  You use HOST_SLEEP_CFG
to set the conditions that the 8686 will use to wake up the host,
basically it's Wake-on-WLAN.

> So my overall question is, what should be done to power down the chip? 
> Should the HOST_SLEEP_ACTIVATE command be sufficient and we have a 
> different problem here with our device?

DEEP_SLEEP.

> Or should do it the deep sleep command? I have already looked at the 
> deep sleep patch from september, but i don't understand why there has to 
> be a timer and an interface to user space; in my understanding the 
> driver gets somewhen told "And now suspend yourself!" and that should be 
> all... Anyway, i tried also to send the CMD_802_11_DEEP_SLEEP following 
> the HOST_SLEEP_ACTIVATE, resulting in a completely dead device.
> 
> Or is setting the PDn pin the only way to power down the chip? Or is 
> there another way applicable?

DEEP_SLEEP should put the chip to sleep, but each bus type has a
different method of waking the chip up because the bus itself is
presumably in low-power mode or even off completely.  This is usually a
GPIO on your specific hardware device that is toggled by your CPU after
the CPU is awake to wake the SD8686 back up.  Not exactly sure how that
works on a SPI bus but I'd assume it's not much different than SDIO.

> And another question: Will an established WLAN connection survive the 
> power-down and power-up, or does it have to be reconnected (which will 
> probably terminate a TCP connection running over the WLAN connection)?

It's helpful to understand a bit how WiFi works here; the AP and STA (ie
the 8686) need to periodically ping each other, otherwise the AP will
disassociate the STA because the STA may have simply gone away.  The STA
also needs to keep track of the AP's beacons otherwise the STA will
assume that it has moved out of range of the AP and terminate the WLAN
connection itself.  So no, don't expect a connection to survive a deep
sleep unless the deep sleep lasts less than say 100 or 200ms.  But deep
sleep isn't really meant for that short of an interval.

There are really two power-saving mechanisms.  The first is 802.11 PS
which is probably what you want.  This allows the chip to go into a
low-power mode for about 50% - 75% of the time *between AP beacons* (so
for about 75ms or more assuming a standard beacon interval of 100ms) if
there is no traffic to send or receive.  This is configured in the
driver by CMD_802_11_PS_MODE.  IP connections will survive in this mode
because the chip is never completely powered down, and it wakes up often
enough so that it stays associated to the AP.

Then there's deep sleep mode where the chip really is mostly powered
off.  It takes a bit of time to wake up from deep sleep so you simply
can't keep the association with the AP.  That's also why there are
timers; it physically takes time for the chip's function blocks to power
up and stabilize, and for the firmware to come back from sleep.  But
this mode also provides the most power savings.  Of course you want to
use it when the device itself goes to sleep for longer periods of time.

Dan



From dcbw at redhat.com  Fri Dec 25 15:04:17 2009
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 25 Dec 2009 14:04:17 -0600
Subject: How to keep sd8686 transmitting data using a fixed channel?
In-Reply-To: <396CBD798C84450E93516E0B7DBCDEB2@ivan>
References: <396CBD798C84450E93516E0B7DBCDEB2@ivan>
Message-ID: <1261771457.2138.66.camel@localhost.localdomain>

On Tue, 2009-12-22 at 10:14 +0800, Ivan Li wrote:
> Hi guys,
> 
> We are doing a test to find out the transmitting power of the sd8686, which is needed by SAR.
> I am wondering if libertas has some programming interface to set the freqency (channel) and issue an infinite data Tx?

The channel can be set with standard WEXT commands and 'iwconfig'.  What
I'd do here is to set up an adhoc BSS where the 8686 is the only station
and then start pumping out packets of some type.  Flood pings perhaps.
You can get the device up on a channel by doing somethign like:

iwconfig eth1 mode adhoc essid foobar channel 6
<periodically run iwconfig and wait for the BSSID to become non-zero>

then start pumping the frames out.

Dan
 



From dcbw at redhat.com  Fri Dec 25 15:04:48 2009
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 25 Dec 2009 14:04:48 -0600
Subject: slab corruption on XO-1 (mesh related?)
In-Reply-To: <1261684124.2140.16.camel@localhost.localdomain>
References: <1261684124.2140.16.camel@localhost.localdomain>
Message-ID: <1261771488.2138.67.camel@localhost.localdomain>

On Thu, 2009-12-24 at 19:48 +0000, Daniel Drake wrote:
> I think this is a 2.6.31 regression. I don't have time to investigate
> right now.
> 
> To reproduce I just connected to the mesh on msh0, disconnect from the
> mesh and connect to an access point on eth0.
> 
> Then things go a bit wrong and this appears in the logs, repeatedly:

32-character SSID perhaps?

Dan


> [  310.921753] slab error in verify_redzone_free(): cache `size-32':
> memory outside object was overwritten
> [  310.921796] Pid: 1805, comm: wpa_supplicant Tainted: G        W
> 2.6.31_xo1-20091224.1735.1.olpc.bd1f1e9 #1
> [  310.921821] Call Trace:
> [  310.921871]  [<c06a7016>] ? printk+0xf/0x11
> [  310.921917]  [<c047e552>] __slab_error+0x17/0x1c
> [  310.921955]  [<c047eb7b>] cache_free_debugcheck+0x10a/0x1b8
> [  310.921988]  [<c06a074b>] ? ioctl_standard_call+0x23e/0x280
> [  310.922025]  [<c047eded>] kfree+0xc0/0xf0
> [  310.922057]  [<c06a074b>] ioctl_standard_call+0x23e/0x280
> [  310.922103]  [<c0621820>] ? __dev_get_by_name+0x6d/0x7a
> [  310.922138]  [<c0621820>] ? __dev_get_by_name+0x6d/0x7a
> [  310.922172]  [<c06a085b>] wext_handle_ioctl+0xce/0x157
> [  310.922305]  [<cf8ffc6a>] ? lbs_get_essid+0x0/0xef [libertas]
> [  310.922341]  [<c06254af>] dev_ioctl+0x567/0x587
> [  310.922383]  [<c0617528>] ? sys_sendto+0xa1/0xc0
> [  310.922419]  [<c0617f96>] ? sys_recvfrom+0x99/0xba
> [  310.922454]  [<c056e11e>] ? copy_from_user+0x32/0x78
> [  310.922489]  [<c06169d8>] sock_ioctl+0x1ef/0x1fb
> [  310.922521]  [<c06167e9>] ? sock_ioctl+0x0/0x1fb
> [  310.922557]  [<c048f86e>] vfs_ioctl+0x18/0x6f
> [  310.922591]  [<c048fe6f>] do_vfs_ioctl+0x4ef/0x52d
> [  310.922627]  [<c061755f>] ? sys_send+0x18/0x1a
> [  310.922662]  [<c061832f>] ? sys_socketcall+0xc5/0x16b
> [  310.922695]  [<c048feee>] sys_ioctl+0x41/0x61
> [  310.922730]  [<c04033d4>] sysenter_do_call+0x12/0x26
> [  310.922762] ccfaad30: redzone 1:0xd84156c5635688c0, redzone
> 2:0xd84156c563568800.
> 
> Running "iwconfig" causes the exact same trace.
> 
> Daniel
> 
> 
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev



From vbxdev at gmail.com  Fri Dec 25 18:21:35 2009
From: vbxdev at gmail.com (Vidur Bhargava)
Date: Fri, 25 Dec 2009 17:21:35 -0600
Subject: Marvell 88W8388 USB Development
Message-ID: <ce174ffa0912251521i2bc32b25qa3eb22200dd0208b@mail.gmail.com>

Hi. Sorry for the mass email.

OLPC XO-1 uses the?Marvell 88W8388 USB. I want to contribute to the
libertas driver for this chipset.

Could you please suggest any 88W8388 USB devices/prototypes that I
could use on my Linux laptop? Thanks.


From marek.vasut at gmail.com  Fri Dec 25 19:38:53 2009
From: marek.vasut at gmail.com (Marek Vasut)
Date: Sat, 26 Dec 2009 01:38:53 +0100
Subject: Marvell 88W8388 USB Development
In-Reply-To: <ce174ffa0912251521i2bc32b25qa3eb22200dd0208b@mail.gmail.com>
References: <ce174ffa0912251521i2bc32b25qa3eb22200dd0208b@mail.gmail.com>
Message-ID: <200912260138.53729.marek.vasut@gmail.com>

Dne So 26. prosince 2009 00:21:35 Vidur Bhargava napsal(a):
> Hi. Sorry for the mass email.
> 
> OLPC XO-1 uses the Marvell 88W8388 USB. I want to contribute to the
> libertas driver for this chipset.
> 
> Could you please suggest any 88W8388 USB devices/prototypes that I
> could use on my Linux laptop? Thanks.
Hi, there was an XBOX wifi dongle that had 88W8388. You can try buying that one.
> 
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev
> 


From dcbw at redhat.com  Fri Dec 25 18:15:35 2009
From: dcbw at redhat.com (Dan Williams)
Date: Fri, 25 Dec 2009 17:15:35 -0600
Subject: Marvell 88W8388 USB Development
In-Reply-To: <200912260138.53729.marek.vasut@gmail.com>
References: <ce174ffa0912251521i2bc32b25qa3eb22200dd0208b@mail.gmail.com>
	<200912260138.53729.marek.vasut@gmail.com>
Message-ID: <1261782935.32673.12.camel@localhost.localdomain>

On Sat, 2009-12-26 at 01:38 +0100, Marek Vasut wrote:
> Dne So 26. prosince 2009 00:21:35 Vidur Bhargava napsal(a):
> > Hi. Sorry for the mass email.
> > 
> > OLPC XO-1 uses the Marvell 88W8388 USB. I want to contribute to the
> > libertas driver for this chipset.
> > 
> > Could you please suggest any 88W8388 USB devices/prototypes that I
> > could use on my Linux laptop? Thanks.
> Hi, there was an XBOX wifi dongle that had 88W8388. You can try buying that one.

It has a custom firmware.  Don't bother; it won't actually work.

Unfortunately, there aren't any usb8388 dongles available to the general
public.  About the best you can do is ask OLPC to send you some of the
development dongles if they have any left.

But in any case, any help on the libertas fullmac driver would be much
appreciated.  There's a lot to do, starting mainly with ensuring that
Holger's cfg80211 conversion is solid and regression-free.  That
involves simply a lot of testing.

Dan




From marek.vasut at gmail.com  Fri Dec 25 23:27:46 2009
From: marek.vasut at gmail.com (Marek Vasut)
Date: Sat, 26 Dec 2009 05:27:46 +0100
Subject: Marvell 88W8388 USB Development
In-Reply-To: <ce174ffa0912251718l2677c426j4caad65b5a3ad1eb@mail.gmail.com>
References: <ce174ffa0912251521i2bc32b25qa3eb22200dd0208b@mail.gmail.com>
	<200912260138.53729.marek.vasut@gmail.com>
	<ce174ffa0912251718l2677c426j4caad65b5a3ad1eb@mail.gmail.com>
Message-ID: <200912260527.46861.marek.vasut@gmail.com>

Dne So 26. prosince 2009 02:18:16 vbx dev napsal(a):
> I bought it and tried it. It doesn't work with the libertas driver.

1) please reply to the list
2) stop top-posting
3) why doesn't it work ?
> 
> On Fri, Dec 25, 2009 at 6:38 PM, Marek Vasut <marek.vasut at gmail.com> wrote:
> > Dne So 26. prosince 2009 00:21:35 Vidur Bhargava napsal(a):
> >> Hi. Sorry for the mass email.
> >>
> >> OLPC XO-1 uses the Marvell 88W8388 USB. I want to contribute to the
> >> libertas driver for this chipset.
> >>
> >> Could you please suggest any 88W8388 USB devices/prototypes that I
> >> could use on my Linux laptop? Thanks.
> >
> > Hi, there was an XBOX wifi dongle that had 88W8388. You can try buying
> > that one.
> >
> >> _______________________________________________
> >> libertas-dev mailing list
> >> libertas-dev at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/libertas-dev
> 


From Johan.Adolfsson at axis.com  Sat Dec 26 05:17:51 2009
From: Johan.Adolfsson at axis.com (Johan Adolfsson)
Date: Sat, 26 Dec 2009 11:17:51 +0100
Subject: How to keep sd8686 transmitting data using a fixed channel?
In-Reply-To: <1261771457.2138.66.camel@localhost.localdomain>
References: <396CBD798C84450E93516E0B7DBCDEB2@ivan>
	<1261771457.2138.66.camel@localhost.localdomain>
Message-ID: <4BEA3FF3CAA35E408EA55C7BE2E61D0546A6AC12A8@xmail3.se.axis.com>



> -----Original Message-----
> From: libertas-dev-bounces at lists.infradead.org [mailto:libertas-dev-
> bounces at lists.infradead.org] On Behalf Of Dan Williams
> Sent: den 25 december 2009 21:04
> To: Ivan Li
> Cc: libertas-dev at lists.infradead.org
> Subject: Re: How to keep sd8686 transmitting data using a fixed
> channel?
> 
> On Tue, 2009-12-22 at 10:14 +0800, Ivan Li wrote:
> > Hi guys,
> >
> > We are doing a test to find out the transmitting power of the sd8686,
> which is needed by SAR.
> > I am wondering if libertas has some programming interface to set the
> freqency (channel) and issue an infinite data Tx?
> 
> The channel can be set with standard WEXT commands and 'iwconfig'.
> What
> I'd do here is to set up an adhoc BSS where the 8686 is the only
> station
> and then start pumping out packets of some type.  Flood pings perhaps.
> You can get the device up on a channel by doing somethign like:
> 
> iwconfig eth1 mode adhoc essid foobar channel 6
> <periodically run iwconfig and wait for the BSSID to become non-zero>
> 
> then start pumping the frames out.
> 
> Dan

Although this method may give a more "real case" value - it will 
probably not give the worst case.
Marvell has a special firmware that support setting bitrate, frequency and
a couple of different continuous transmit modes (and rx mode).
You should be able to get it from Marvell (if you have an account) or 
perhaps your module manufacturer.

Best regards
/Johan




From dsd at laptop.org  Sun Dec 27 06:32:59 2009
From: dsd at laptop.org (Daniel Drake)
Date: Sun, 27 Dec 2009 11:32:59 +0000
Subject: slab corruption on XO-1 (mesh related?)
In-Reply-To: <1261771488.2138.67.camel@localhost.localdomain>
References: <1261684124.2140.16.camel@localhost.localdomain>
	<1261771488.2138.67.camel@localhost.localdomain>
Message-ID: <1261913579.2129.1.camel@localhost.localdomain>

On Fri, 2009-12-25 at 14:04 -0600, Dan Williams wrote:
> On Thu, 2009-12-24 at 19:48 +0000, Daniel Drake wrote:
> > I think this is a 2.6.31 regression. I don't have time to investigate
> > right now.
> > 
> > To reproduce I just connected to the mesh on msh0, disconnect from the
> > mesh and connect to an access point on eth0.
> > 
> > Then things go a bit wrong and this appears in the logs, repeatedly:
> 
> 32-character SSID perhaps?

Yes, I think that was the case. Have you spotted something?

Daniel




From m.hirsch at raumfeld.com  Wed Dec 30 07:20:07 2009
From: m.hirsch at raumfeld.com (Michael Hirsch)
Date: Wed, 30 Dec 2009 13:20:07 +0100
Subject: setting country code in libertas
Message-ID: <4B3B4577.9030903@raumfeld.com>

hello all,

I'm trying to set the country code from user space in order to access 
channels > 11 using 2.6.32 kernel. I know there have been lot's of 
changes in the past, so I'm a little lost. What's currently the 
designated way to do it?

Thanks in advance

Michael


