[ath9k-devel] ath9k constantly drops network connection

[ath9k-devel] ath9k constantly drops network connection

[Partha Bagchi]

Hi All,

I download compat-wireless-2.6-old and compiled and installed it on a
Fedora 9 box. Here are the details:

lspci > 06:00.0 Network controller: Atheros Communications Inc.
Unknown device 002a (rev 01)
uname -a > Linux Bordeaux 2.6.26.3-29.fc9.i686 #1 SMP Wed Sep 3
03:42:27 EDT 2008 i686 i686 i386 GNU/Linux

My problems is (as has been reported before) is that I cannot get a
connection with (dhclient) at all even if I am sitting next to the
AP. Strangely, NetworkManager is able to connect but drops connections
maybe after 5 or 10 minutes. I can reconnect but then the same story.

Also, I was getting a lot of ForceXPAon: 0. So I commented out the
debug printf in the source. So that has stopped.

I just saw a post that someone with a Sony has a similar problem and
is able to get a stabler connection by disconnecting bluetooth. I will
try that.

However, right now, I am not sure the driver is very stable. I am of
course happy to help in testing anyway I can.

Thanks in advance,
Partha

[ath9k-devel] ath9k constantly drops network connection

[Luis R. Rodriguez]

On Wed, Sep 17, 2008 at 03:05:59AM -0700, Partha Bagchi wrote:
> Hi All,
> 
> I download compat-wireless-2.6-old and compiled and installed it on a
> Fedora 9 box. Here are the details:
> 
> lspci > 06:00.0 Network controller: Atheros Communications Inc.
> Unknown device 002a (rev 01)
> uname -a > Linux Bordeaux 2.6.26.3-29.fc9.i686 #1 SMP Wed Sep 3
> 03:42:27 EDT 2008 i686 i686 i386 GNU/Linux

Please try appling the patch titled:

"[PATCH] ath9k: connectivity is lost after Group rekeying is done"

which was posted on linux-wireless. If that fixes your issue I can merge
this patch on compat-wireless-old. I've attached the patch for your
convenience, inline at the bottom and also as an attachment.

  Luis

[ath9k-devel] ath9k constantly drops network connection

[Partha Bagchi]

On Wed, Sep 17, 2008 at 3:10 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Wed, Sep 17, 2008 at 03:05:59AM -0700, Partha Bagchi wrote:
>> Hi All,
>>
>> I download compat-wireless-2.6-old and compiled and installed it on a
>> Fedora 9 box. Here are the details:
>>
>> lspci > 06:00.0 Network controller: Atheros Communications Inc.
>> Unknown device 002a (rev 01)
>> uname -a > Linux Bordeaux 2.6.26.3-29.fc9.i686 #1 SMP Wed Sep 3
>> 03:42:27 EDT 2008 i686 i686 i386 GNU/Linux
>
> Please try appling the patch titled:
>
> "[PATCH] ath9k: connectivity is lost after Group rekeying is done"
>
> which was posted on linux-wireless. If that fixes your issue I can merge
> this patch on compat-wireless-old. I've attached the patch for your
> convenience, inline at the bottom and also as an attachment.
>
>  Luis
>
>
> From Senthilkumar.Balasubramanian at Atheros.com Wed Sep 17 00:10:07 2008
>
> Connectivtiy is lost after Group rekeying is done. The keytype
> maintained by ath9k is reset when group key is updated. Though
> sc_keytype can be reset only for broadcast key the proper fix
> would be to use mac80211 provided key type from txinfo during
> xmit and get rid of sc_keytype from ath9k ath_softc.
>
> Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com>
> Signed-off-by: Senthil Balasubramanian <senthilkumar@atheros.com>
> ---
>  drivers/net/wireless/ath9k/core.h |    1 -
>  drivers/net/wireless/ath9k/main.c |    3 ---
>  drivers/net/wireless/ath9k/xmit.c |    6 +++---
>  3 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/ath9k/core.h b/drivers/net/wireless/ath9k=
> /core.h
> index b66de29..e8ccbe4 100644
> --- a/drivers/net/wireless/ath9k/core.h
> +++ b/drivers/net/wireless/ath9k/core.h
> @@ -976,7 +976,6 @@ struct ath_softc {
>        u32 sc_keymax;          /* size of key cache */
>        DECLARE_BITMAP(sc_keymap, ATH_KEYMAX);  /* key use bit map */
>        u8 sc_splitmic;         /* split TKIP MIC keys */
> -       int sc_keytype;
>
>        /* RX */
>        struct list_head sc_rxbuf;
> diff --git a/drivers/net/wireless/ath9k/main.c b/drivers/net/wireless/ath9k=
> /main.c
> index 1ba1800..aca893a 100644
> --- a/drivers/net/wireless/ath9k/main.c
> +++ b/drivers/net/wireless/ath9k/main.c
> @@ -204,8 +204,6 @@ static int ath_key_config(struct ath_softc *sc,
>        if (!ret)
>                return -EIO;
>
> -       if (mac)
> -               sc->sc_keytype =3D hk.kv_type;
>        return 0;
>  }
>
> @@ -1507,7 +1505,6 @@ static int ath9k_set_key(struct ieee80211_hw *hw,
>        case DISABLE_KEY:
>                ath_key_delete(sc, key);
>                clear_bit(key->keyidx, sc->sc_keymap);
> -               sc->sc_keytype =3D ATH9K_CIPHER_CLR;
>                break;
>        default:
>                ret =3D -EINVAL;
> diff --git a/drivers/net/wireless/ath9k/xmit.c b/drivers/net/wireless/ath9k=
> /xmit.c
> index 3fc6641..2592905 100644
> --- a/drivers/net/wireless/ath9k/xmit.c
> +++ b/drivers/net/wireless/ath9k/xmit.c
> @@ -239,11 +239,11 @@ static int ath_tx_prepare(struct ath_softc *sc,
>                txctl->keyix =3D tx_info->control.hw_key->hw_key_idx;
>                txctl->frmlen +=3D tx_info->control.icv_len;
>
> -               if (sc->sc_keytype =3D=3D ATH9K_CIPHER_WEP)
> +               if (tx_info->control.hw_key->alg =3D=3D ALG_WEP)
>                        txctl->keytype =3D ATH9K_KEY_TYPE_WEP;
> -               else if (sc->sc_keytype =3D=3D ATH9K_CIPHER_TKIP)
> +               else if (tx_info->control.hw_key->alg =3D=3D ALG_TKIP)
>                        txctl->keytype =3D ATH9K_KEY_TYPE_TKIP;
> -               else if (sc->sc_keytype =3D=3D ATH9K_CIPHER_AES_CCM)
> +               else if (tx_info->control.hw_key->alg =3D=3D ALG_CCMP)
>                        txctl->keytype =3D ATH9K_KEY_TYPE_AES;
>        }
>
> --
> 1.5.5
>
>
>

Luis,

Thanks for the patch.  The patch did not apply, I got all rejected
hunks when I applied it to the source
compat-wireless-2.6-old/drivers/net/wireless/ath9k

Here are the error messages:
Bordeaux >  patch -p1 < connectivity.patch
patching file drivers/net/wireless/ath9k/core.h
Hunk #1 FAILED at 976.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/net/wireless/ath9k/core.h.rej
patching file drivers/net/wireless/ath9k/main.c
Hunk #1 FAILED at 204.
Hunk #2 FAILED at 1505
2 out of 2 hunks FAILED -- saving rejects to file
drivers/net/wireless/ath9k/main.c.rej
patching file drivers/net/wireless/ath9k/xmit.c
Hunk #1 FAILED at 239.
1 out of 1 hunk FAILED -- saving rejects to file
drivers/net/wireless/ath9k/xmit.c.rej

When I looked@the source, I could see that the patch could not work
since the line numbers are not right. I even tried it on a freshly
downloaded source from
http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-old.tar.bz2

I am not sure what to do.

Thanks for your help!

Partha

[ath9k-devel] ath9k constantly drops network connection

[Luis R. Rodriguez]

On Wed, Sep 17, 2008 at 04:08:47PM -0700, Partha Bagchi wrote:
> Thanks for the patch.  The patch did not apply, I got all rejected
> hunks when I applied it to the source
> compat-wireless-2.6-old/drivers/net/wireless/ath9k
> 
> Here are the error messages:
> Bordeaux >  patch -p1 < connectivity.patch
> patching file drivers/net/wireless/ath9k/core.h
> Hunk #1 FAILED at 976.
> 1 out of 1 hunk FAILED -- saving rejects to file
> drivers/net/wireless/ath9k/core.h.rej
> patching file drivers/net/wireless/ath9k/main.c
> Hunk #1 FAILED at 204.
> Hunk #2 FAILED at 1505
> 2 out of 2 hunks FAILED -- saving rejects to file
> drivers/net/wireless/ath9k/main.c.rej
> patching file drivers/net/wireless/ath9k/xmit.c
> Hunk #1 FAILED at 239.
> 1 out of 1 hunk FAILED -- saving rejects to file
> drivers/net/wireless/ath9k/xmit.c.rej
> 
> When I looked at the source, I could see that the patch could not work
> since the line numbers are not right. I even tried it on a freshly
> downloaded source from
> http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-old.tar.bz2

Ah, well it seems we need to update ath9k on compat-wireless-old again.
You can try to replace the ath9k directory from compat-wireless (note,
not -old) with the onto compat-wireless-old and see if that compiles.
If it doesn't compile then you need to do some backport work on that
ath9k files to get it to compile on older kernels.

  Luis

[ath9k-devel] ath9k constantly drops network connection

[Partha Bagchi]

On Wed, Sep 17, 2008 at 7:20 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Wed, Sep 17, 2008 at 04:08:47PM -0700, Partha Bagchi wrote:
>> Thanks for the patch.  The patch did not apply, I got all rejected
>> hunks when I applied it to the source
>> compat-wireless-2.6-old/drivers/net/wireless/ath9k
>>
>> Here are the error messages:
>> Bordeaux >  patch -p1 < connectivity.patch
>> patching file drivers/net/wireless/ath9k/core.h
>> Hunk #1 FAILED at 976.
>> 1 out of 1 hunk FAILED -- saving rejects to file
>> drivers/net/wireless/ath9k/core.h.rej
>> patching file drivers/net/wireless/ath9k/main.c
>> Hunk #1 FAILED at 204.
>> Hunk #2 FAILED at 1505
>> 2 out of 2 hunks FAILED -- saving rejects to file
>> drivers/net/wireless/ath9k/main.c.rej
>> patching file drivers/net/wireless/ath9k/xmit.c
>> Hunk #1 FAILED at 239.
>> 1 out of 1 hunk FAILED -- saving rejects to file
>> drivers/net/wireless/ath9k/xmit.c.rej
>>
>> When I looked at the source, I could see that the patch could not work
>> since the line numbers are not right. I even tried it on a freshly
>> downloaded source from
>> http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-old.tar.bz2
>
> Ah, well it seems we need to update ath9k on compat-wireless-old again.
> You can try to replace the ath9k directory from compat-wireless (note,
> not -old) with the onto compat-wireless-old and see if that compiles.
> If it doesn't compile then you need to do some backport work on that
> ath9k files to get it to compile on older kernels.
>
>  Luis
>

Hi Luis,

I did what you suggested. I downloaded the latest compat-wireless-2.6.
I copied the ath9k subdirectory into compat-wireless-2.6.old
directory. I deleted that subdirectory prior to doing this. The
compilation went without a hitch. So, looks like the compilation is
not a problem.

I installed the drivers and activated my card. Next, I will test to
see how long the connection lasts.

One last questions though. I downloaded the latest compat-wireless-2.6
yesterday (EDT). Is it fair to say that the patch did not make it into
that varsion? Do I need to pull in the git version to have a stable
connection? (My guess is yes?)

Thanks,
Partha

[ath9k-devel] ath9k constantly drops network connection

[Luis R. Rodriguez]

On Thu, Sep 18, 2008 at 3:04 AM, Partha Bagchi <partha1b@gmail.com> wrote:
> On Wed, Sep 17, 2008 at 7:20 PM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
>> On Wed, Sep 17, 2008 at 04:08:47PM -0700, Partha Bagchi wrote:
>>> Thanks for the patch.  The patch did not apply, I got all rejected
>>> hunks when I applied it to the source
>>> compat-wireless-2.6-old/drivers/net/wireless/ath9k
>>>
>>> Here are the error messages:
>>> Bordeaux >  patch -p1 < connectivity.patch
>>> patching file drivers/net/wireless/ath9k/core.h
>>> Hunk #1 FAILED at 976.
>>> 1 out of 1 hunk FAILED -- saving rejects to file
>>> drivers/net/wireless/ath9k/core.h.rej
>>> patching file drivers/net/wireless/ath9k/main.c
>>> Hunk #1 FAILED at 204.
>>> Hunk #2 FAILED at 1505
>>> 2 out of 2 hunks FAILED -- saving rejects to file
>>> drivers/net/wireless/ath9k/main.c.rej
>>> patching file drivers/net/wireless/ath9k/xmit.c
>>> Hunk #1 FAILED at 239.
>>> 1 out of 1 hunk FAILED -- saving rejects to file
>>> drivers/net/wireless/ath9k/xmit.c.rej
>>>
>>> When I looked at the source, I could see that the patch could not work
>>> since the line numbers are not right. I even tried it on a freshly
>>> downloaded source from
>>> http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-old.tar.bz2
>>
>> Ah, well it seems we need to update ath9k on compat-wireless-old again.
>> You can try to replace the ath9k directory from compat-wireless (note,
>> not -old) with the onto compat-wireless-old and see if that compiles.
>> If it doesn't compile then you need to do some backport work on that
>> ath9k files to get it to compile on older kernels.
>>
>>  Luis
>>
>
> Hi Luis,
>
> I did what you suggested. I downloaded the latest compat-wireless-2.6.
> I copied the ath9k subdirectory into compat-wireless-2.6.old
> directory. I deleted that subdirectory prior to doing this. The
> compilation went without a hitch. So, looks like the compilation is
> not a problem.
>
> I installed the drivers and activated my card. Next, I will test to
> see how long the connection lasts.

Thanks for reporting this after this patch gets merged I'll update
compat-wireless-old to have ath9k with it then, just as you did.

> One last questions though. I downloaded the latest compat-wireless-2.6
> yesterday (EDT). Is it fair to say that the patch did not make it into
> that varsion? Do I need to pull in the git version to have a stable
> connection? (My guess is yes?)

You just need to apply the patch from inside compat-wireless-old
directory, you do not need to pull in anything git-wise.

patch -p1 < foo.patch

  Luis

[ath9k-devel] ath9k constantly drops network connection

[Partha Bagchi]

On Thu, Sep 18, 2008 at 6:09 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Thu, Sep 18, 2008 at 3:04 AM, Partha Bagchi <partha1b@gmail.com> wrote:
>> On Wed, Sep 17, 2008 at 7:20 PM, Luis R. Rodriguez
>> <lrodriguez@atheros.com> wrote:
>>> On Wed, Sep 17, 2008 at 04:08:47PM -0700, Partha Bagchi wrote:
>>>> Thanks for the patch.  The patch did not apply, I got all rejected
>>>> hunks when I applied it to the source
>>>> compat-wireless-2.6-old/drivers/net/wireless/ath9k
>>>>
>>>> Here are the error messages:
>>>> Bordeaux >  patch -p1 < connectivity.patch
>>>> patching file drivers/net/wireless/ath9k/core.h
>>>> Hunk #1 FAILED at 976.
>>>> 1 out of 1 hunk FAILED -- saving rejects to file
>>>> drivers/net/wireless/ath9k/core.h.rej
>>>> patching file drivers/net/wireless/ath9k/main.c
>>>> Hunk #1 FAILED at 204.
>>>> Hunk #2 FAILED at 1505
>>>> 2 out of 2 hunks FAILED -- saving rejects to file
>>>> drivers/net/wireless/ath9k/main.c.rej
>>>> patching file drivers/net/wireless/ath9k/xmit.c
>>>> Hunk #1 FAILED at 239.
>>>> 1 out of 1 hunk FAILED -- saving rejects to file
>>>> drivers/net/wireless/ath9k/xmit.c.rej
>>>>
>>>> When I looked at the source, I could see that the patch could not work
>>>> since the line numbers are not right. I even tried it on a freshly
>>>> downloaded source from
>>>> http://wireless.kernel.org/download/compat-wireless-2.6/compat-wireless-old.tar.bz2
>>>
>>> Ah, well it seems we need to update ath9k on compat-wireless-old again.
>>> You can try to replace the ath9k directory from compat-wireless (note,
>>> not -old) with the onto compat-wireless-old and see if that compiles.
>>> If it doesn't compile then you need to do some backport work on that
>>> ath9k files to get it to compile on older kernels.
>>>
>>>  Luis
>>>
>>
>> Hi Luis,
>>
>> I did what you suggested. I downloaded the latest compat-wireless-2.6.
>> I copied the ath9k subdirectory into compat-wireless-2.6.old
>> directory. I deleted that subdirectory prior to doing this. The
>> compilation went without a hitch. So, looks like the compilation is
>> not a problem.
>>
>> I installed the drivers and activated my card. Next, I will test to
>> see how long the connection lasts.
>
> Thanks for reporting this after this patch gets merged I'll update
> compat-wireless-old to have ath9k with it then, just as you did.
>
>> One last questions though. I downloaded the latest compat-wireless-2.6
>> yesterday (EDT). Is it fair to say that the patch did not make it into
>> that varsion? Do I need to pull in the git version to have a stable
>> connection? (My guess is yes?)
>
> You just need to apply the patch from inside compat-wireless-old
> directory, you do not need to pull in anything git-wise.
>
> patch -p1 < foo.patch
>
>  Luis
>

Well, the patch didn't apply again. I get failed hunks at the same
spots. I am using the patch you uploaded yesterday. Maybe I can pull
in compat-wireless after the patch has been applied as you asked
earlier. Right now, my connection lasted 30 minutes before
disconnecting.

I am also getting a lot of messages similar to the following in
/var/log/message:

Sep 18 06:39:17 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 3 -> 0
Sep 18 06:39:17 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 0 -> 2
Sep 18 06:39:18 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 2 -> 3
Sep 18 06:39:18 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 3 -> 4
Sep 18 06:39:18 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 4 -> 7

Thanks for all your help!

Partha

[ath9k-devel] ath9k constantly drops network connection

[Mats Johannesson]

On Thu, 18 Sep 2008 06:45:29 -0400 Partha Bagchi wrote:
[...]
> Well, the patch didn't apply again. I get failed hunks at the same
> spots. I am using the patch you uploaded yesterday. Maybe I can pull
> in compat-wireless after the patch has been applied as you asked
> earlier. Right now, my connection lasted 30 minutes before
> disconnecting.

Partha, the patch Luis posted is full of Mime(?) characters for tabs,
like this =3D=3D

You'll find a clean patch at:
http://marc.info/?l=linux-wireless&m=122163541519736&w=2

Click on [Download message RAW] just under the Message-ID line to
get a pure text file.

Mvh
Mats Johannesson

[ath9k-devel] ath9k constantly drops network connection

[Partha Bagchi]

On Thu, Sep 18, 2008 at 7:02 AM, Mats Johannesson <spamcan1@abrasax.se> wrote:
> On Thu, 18 Sep 2008 06:45:29 -0400 Partha Bagchi wrote:
> [...]
>> Well, the patch didn't apply again. I get failed hunks at the same
>> spots. I am using the patch you uploaded yesterday. Maybe I can pull
>> in compat-wireless after the patch has been applied as you asked
>> earlier. Right now, my connection lasted 30 minutes before
>> disconnecting.
>
> Partha, the patch Luis posted is full of Mime(?) characters for tabs,
> like this =3D=3D
>
> You'll find a clean patch at:
> http://marc.info/?l=linux-wireless&m=122163541519736&w=2
>
> Click on [Download message RAW] just under the Message-ID line to
> get a pure text file.
>
> Mvh
> Mats Johannesson
>

Hi Mats,

Thanks! I got the patch and applied it to the driver. I just made and
installed it. I am now going to test how long the connectivity lasts.

I will let the group know if this is stable.

Thanks again,
Partha

[ath9k-devel] ath9k constantly drops network connection

[Partha Bagchi]

On Thu, Sep 18, 2008 at 7:01 PM, Partha Bagchi <partha1b@gmail.com> wrote:
> On Thu, Sep 18, 2008 at 7:02 AM, Mats Johannesson <spamcan1@abrasax.se> wrote:
>> On Thu, 18 Sep 2008 06:45:29 -0400 Partha Bagchi wrote:
>> [...]
>>> Well, the patch didn't apply again. I get failed hunks at the same
>>> spots. I am using the patch you uploaded yesterday. Maybe I can pull
>>> in compat-wireless after the patch has been applied as you asked
>>> earlier. Right now, my connection lasted 30 minutes before
>>> disconnecting.
>>
>> Partha, the patch Luis posted is full of Mime(?) characters for tabs,
>> like this =3D=3D
>>
>> You'll find a clean patch at:
>> http://marc.info/?l=linux-wireless&m=122163541519736&w=2
>>
>> Click on [Download message RAW] just under the Message-ID line to
>> get a pure text file.
>>
>> Mvh
>> Mats Johannesson
>>
>
> Hi Mats,
>
> Thanks! I got the patch and applied it to the driver. I just made and
> installed it. I am now going to test how long the connectivity lasts.
>
> I will let the group know if this is stable.
>
> Thanks again,
> Partha
>

Update:

The new code actually more unstable on my machine which you may recall is:

Linux Bordeaux 2.6.26.3-29.fc9.i686 #1 SMP Wed Sep 3 03:42:27 EDT 2008
i686 i686 i386 GNU/Linux

Anyway, here is the output from /var/log/message:

Sep 19 05:49:28 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:49:28 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:49:28 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:49:29 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:50:05 Bordeaux NetworkManager: <info>  Activation (wlan1)
starting connection 'Auto linksys'
Sep 19 05:50:05 Bordeaux NetworkManager: <info>  (wlan1): device state
change: 3 -> 4
Sep 19 05:50:05 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 1 of 5 (Device Prepare) scheduled...
Sep 19 05:50:05 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 1 of 5 (Device Prepare) started...
Sep 19 05:50:05 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 2 of 5 (Device Configure) scheduled...
Sep 19 05:50:05 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 1 of 5 (Device Prepare) complete.
Sep 19 05:50:05 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 2 of 5 (Device Configure) starting...
Sep 19 05:50:05 Bordeaux NetworkManager: <info>  (wlan1): device state
change: 4 -> 5
Sep 19 05:50:05 Bordeaux NetworkManager: <info>  Activation
(wlan1/wireless): connection 'Auto linksys' requires no security.  No
secrets needed.
Sep 19 05:50:05 Bordeaux NetworkManager: <info>  Config: added 'ssid'
value 'linksys'
Sep 19 05:50:05 Bordeaux NetworkManager: <info>  Config: added
'scan_ssid' value '1'
Sep 19 05:50:05 Bordeaux NetworkManager: <info>  Config: added
'key_mgmt' value 'NONE'
Sep 19 05:50:05 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 2 of 5 (Device Configure) complete.
Sep 19 05:50:05 Bordeaux NetworkManager: <info>  Config: set interface
ap_scan to 1
Sep 19 05:50:05 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 1 -> 2
Sep 19 05:50:05 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:50:05 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:50:06 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:50:06 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:50:06 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 2 -> 3
Sep 19 05:50:06 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:50:26 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 3 -> 0
Sep 19 05:50:26 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 0 -> 2
Sep 19 05:50:26 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:50:26 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:50:26 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:50:27 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:50:27 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:50:27 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 2 -> 3
Sep 19 05:50:27 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:50:27 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 3 -> 4
Sep 19 05:50:27 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 4 -> 7
Sep 19 05:50:27 Bordeaux NetworkManager: <info>  Activation
(wlan1/wireless) Stage 2 of 5 (Device Configure) successful.
Connected to wireless network 'linksys'.
Sep 19 05:50:27 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 3 of 5 (IP Configure Start) scheduled.
Sep 19 05:50:27 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 3 of 5 (IP Configure Start) started...
Sep 19 05:50:27 Bordeaux NetworkManager: <info>  (wlan1): device state
change: 5 -> 7
Sep 19 05:50:27 Bordeaux NetworkManager: <info>  Activation (wlan1)
Beginning DHCP transaction.
Sep 19 05:50:27 Bordeaux NetworkManager: <info>  dhclient started with pid 4214
Sep 19 05:50:27 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 3 of 5 (IP Configure Start) complete.
Sep 19 05:50:27 Bordeaux dhclient: Internet Systems Consortium DHCP Client 4.0.0
Sep 19 05:50:27 Bordeaux dhclient: Copyright 2004-2007 Internet
Systems Consortium.
Sep 19 05:50:27 Bordeaux dhclient: All rights reserved.
Sep 19 05:50:27 Bordeaux dhclient: For info, please visit
http://www.isc.org/sw/dhcp/
Sep 19 05:50:27 Bordeaux dhclient:
Sep 19 05:50:27 Bordeaux NetworkManager: <info>  DHCP: device wlan1
state changed (null) -> preinit
Sep 19 05:50:27 Bordeaux dhclient: Listening on LPF/wlan1/00:1f:e2:ce:f1:64
Sep 19 05:50:27 Bordeaux dhclient: Sending on   LPF/wlan1/00:1f:e2:ce:f1:64
Sep 19 05:50:27 Bordeaux dhclient: Sending on   Socket/fallback
Sep 19 05:50:28 Bordeaux dhclient: DHCPDISCOVER on wlan1 to
255.255.255.255 port 67 interval 6
Sep 19 05:50:34 Bordeaux dhclient: DHCPDISCOVER on wlan1 to
255.255.255.255 port 67 interval 6
Sep 19 05:50:35 Bordeaux dhclient: DHCPOFFER from 192.168.1.1
Sep 19 05:50:35 Bordeaux dhclient: DHCPREQUEST on wlan1 to
255.255.255.255 port 67
Sep 19 05:50:35 Bordeaux dhclient: DHCPACK from 192.168.1.1
Sep 19 05:50:35 Bordeaux dhclient: bound to 192.168.1.102 -- renewal
in 36125 seconds.
Sep 19 05:50:35 Bordeaux NetworkManager: <info>  DHCP: device wlan1
state changed preinit -> bound
Sep 19 05:50:35 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 4 of 5 (IP Configure Get) scheduled...
Sep 19 05:50:35 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 4 of 5 (IP Configure Get) started...
Sep 19 05:50:35 Bordeaux NetworkManager: <info>    address 192.168.1.102
Sep 19 05:50:35 Bordeaux NetworkManager: <info>    netmask 255.255.255.0
Sep 19 05:50:35 Bordeaux NetworkManager: <info>    gateway 192.168.1.1
Sep 19 05:50:35 Bordeaux NetworkManager: <info>    hostname 'Bordeaux'
Sep 19 05:50:35 Bordeaux NetworkManager: <info>    nameserver '68.87.64.146'
Sep 19 05:50:35 Bordeaux NetworkManager: <info>    nameserver '68.87.75.194'
Sep 19 05:50:35 Bordeaux NetworkManager: <info>    nameserver '68.87.71.226'
Sep 19 05:50:35 Bordeaux NetworkManager: <info>    domain name
'hsd1.nj.comcast.net.'
Sep 19 05:50:35 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 5 of 5 (IP Configure Commit) scheduled...
Sep 19 05:50:35 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 4 of 5 (IP Configure Get) complete.
Sep 19 05:50:35 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 5 of 5 (IP Configure Commit) started...
Sep 19 05:50:35 Bordeaux avahi-daemon[2386]: Joining mDNS multicast
group on interface wlan1.IPv4 with address 192.168.1.102.
Sep 19 05:50:35 Bordeaux avahi-daemon[2386]: New relevant interface
wlan1.IPv4 for mDNS.
Sep 19 05:50:35 Bordeaux avahi-daemon[2386]: Registering new address
record for 192.168.1.102 on wlan1.IPv4.
Sep 19 05:50:36 Bordeaux NetworkManager: <info>  (wlan1): device state
change: 7 -> 8
Sep 19 05:50:36 Bordeaux NetworkManager: <info>  Policy set (wlan1) as
default device for routing and DNS.
Sep 19 05:50:36 Bordeaux NetworkManager: <info>  Activation (wlan1)
successful, device activated.
Sep 19 05:50:36 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 5 of 5 (IP Configure Commit) complete.
Sep 19 05:51:18 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:51:18 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:51:18 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:51:19 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:51:58 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:51:58 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:51:59 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:51:59 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:52:58 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:52:58 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:52:58 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:52:59 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:53:43 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 7 -> 0
Sep 19 05:53:43 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 0 -> 2
Sep 19 05:53:43 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:53:43 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:53:43 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:53:43 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:53:43 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 2 -> 3
Sep 19 05:53:43 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:53:58 Bordeaux NetworkManager: <info>  (wlan1): device state
change: 8 -> 3
Sep 19 05:53:58 Bordeaux NetworkManager: <info>  (wlan1): deactivating device.
Sep 19 05:53:58 Bordeaux NetworkManager: <info>  wlan1: canceled DHCP
transaction, dhclient pid 4214
Sep 19 05:53:58 Bordeaux avahi-daemon[2386]: Withdrawing address
record for 192.168.1.102 on wlan1.
Sep 19 05:53:58 Bordeaux avahi-daemon[2386]: Leaving mDNS multicast
group on interface wlan1.IPv4 with address 192.168.1.102.
Sep 19 05:53:58 Bordeaux avahi-daemon[2386]: Interface wlan1.IPv4 no
longer relevant for mDNS.
Sep 19 05:54:18 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:54:18 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:54:18 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:54:19 Bordeaux kernel: ForceXPAon: 0
Sep 19 05:54:19 Bordeaux kernel: ForceXPAon: 0

After the above, it refuses to connect for awhile. The message is:

Sep 19 05:56:50 Bordeaux NetworkManager: <info>  Activation
(wlan1/wireless): association took too long, failing activation.

So, I am stumped.

Thanks,
Partha

[ath9k-devel] ath9k constantly drops network connection

[Luis R. Rodriguez]

On Fri, Sep 19, 2008 at 2:59 AM, Partha Bagchi <partha1b@gmail.com> wrote:
> Update:
>
> The new code

Please elaborate on what new code is. Did you take
compat-wireless-old, upgrade to compat-wireless's ath9k and apply the
new group key patch posted?

> actually more unstable on my machine which you may recall is:
>
> Linux Bordeaux 2.6.26.3-29.fc9.i686 #1 SMP Wed Sep 3 03:42:27 EDT 2008
> i686 i686 i386 GNU/Linux

Oh you mean you're using compat-wireless-old.

  Luis

[ath9k-devel] ath9k constantly drops network connection

[Partha Bagchi]

On Fri, Sep 19, 2008 at 1:43 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> On Fri, Sep 19, 2008 at 2:59 AM, Partha Bagchi <partha1b@gmail.com> wrote:
>> Update:
>>
>> The new code
>
> Please elaborate on what new code is. Did you take
> compat-wireless-old, upgrade to compat-wireless's ath9k and apply the
> new group key patch posted?
>
>> actually more unstable on my machine which you may recall is:
>>
>> Linux Bordeaux 2.6.26.3-29.fc9.i686 #1 SMP Wed Sep 3 03:42:27 EDT 2008
>> i686 i686 i386 GNU/Linux
>
> Oh you mean you're using compat-wireless-old.
>
>  Luis
>

Hi Luis,

Sorry about the ambiguity. I downloaded
compat-wireless-2008-09-17.tar.bz2 from
http://linuxwireless.org/download/compat-wireless-2.6/

Then as you had suggested, I took the ath9k subdirectory from the
compat-wireless-2.6.tar.bz2 and replaced the original ath9k in the
compat-wireless-2.6-old directory. Then I applied the patch from Mats
email http://marc.info/?l=linux-wireless&m=122163541519736&q=raw.

The patch applied fine, compiled and installed fine. The output that I
posted was the result of using this new driver.

BTW, as a (sort of) comparison, I am using an USB d-link wireless card
with rt73 and the connection is rock solid.

Thanks for all your help!

Partha

[ath9k-devel] ath9k constantly drops network connection

[Luis R. Rodriguez]

On Fri, Sep 19, 2008 at 03:30:24PM -0700, Partha Bagchi wrote:
> On Fri, Sep 19, 2008 at 1:43 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
> > On Fri, Sep 19, 2008 at 2:59 AM, Partha Bagchi <partha1b@gmail.com> wrote:
> >> Update:
> >>
> >> The new code
> >
> > Please elaborate on what new code is. Did you take
> > compat-wireless-old, upgrade to compat-wireless's ath9k and apply the
> > new group key patch posted?
> >
> >> actually more unstable on my machine which you may recall is:
> >>
> >> Linux Bordeaux 2.6.26.3-29.fc9.i686 #1 SMP Wed Sep 3 03:42:27 EDT 2008
> >> i686 i686 i386 GNU/Linux
> >
> > Oh you mean you're using compat-wireless-old.
> >
> >  Luis
> >
> 
> Hi Luis,
> 
> Sorry about the ambiguity. I downloaded
> compat-wireless-2008-09-17.tar.bz2 from
> http://linuxwireless.org/download/compat-wireless-2.6/
> 
> Then as you had suggested, I took the ath9k subdirectory from the
> compat-wireless-2.6.tar.bz2 and replaced the original ath9k in the
> compat-wireless-2.6-old directory. Then I applied the patch from Mats
> email http://marc.info/?l=linux-wireless&m=122163541519736&q=raw.
> 
> The patch applied fine, compiled and installed fine. The output that I
> posted was the result of using this new driver.
> 
> BTW, as a (sort of) comparison, I am using an USB d-link wireless card
> with rt73 and the connection is rock solid.
> 
> Thanks for all your help!
> 
> Partha

Thanks for the clarification. Can you try disabling NetworkManager
completely and then try connecting manually?

Please see here how to completely stop Network Manager:

http://wireless.kernel.org/en/users/Reporting_bugs#ReportingbugsinNetworkManager

(this is how:

sudo /sbin/service NetworkMananger stop
sudo killall -TERM wpa_supplicant

)

Then, provide the logs of your session. What is your environment like?
WEP, WPA, WPA2, or no encryption? You will need to run wpa_supplicant manually
if you disable Network Manager and have encryption using WPA or WPA2. If
you just have WEP you can use iwconfig.

  Luis

[ath9k-devel] ath9k constantly drops network connection

[Partha Bagchi]

On Fri, Sep 19, 2008 at 7:49 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Fri, Sep 19, 2008 at 03:30:24PM -0700, Partha Bagchi wrote:
>> On Fri, Sep 19, 2008 at 1:43 PM, Luis R. Rodriguez <mcgrof@gmail.com> wrote:
>> > On Fri, Sep 19, 2008 at 2:59 AM, Partha Bagchi <partha1b@gmail.com> wrote:
>> >> Update:
>> >>
>> >> The new code
>> >
>> > Please elaborate on what new code is. Did you take
>> > compat-wireless-old, upgrade to compat-wireless's ath9k and apply the
>> > new group key patch posted?
>> >
>> >> actually more unstable on my machine which you may recall is:
>> >>
>> >> Linux Bordeaux 2.6.26.3-29.fc9.i686 #1 SMP Wed Sep 3 03:42:27 EDT 2008
>> >> i686 i686 i386 GNU/Linux
>> >
>> > Oh you mean you're using compat-wireless-old.
>> >
>> >  Luis
>> >
>>
>> Hi Luis,
>>
>> Sorry about the ambiguity. I downloaded
>> compat-wireless-2008-09-17.tar.bz2 from
>> http://linuxwireless.org/download/compat-wireless-2.6/
>>
>> Then as you had suggested, I took the ath9k subdirectory from the
>> compat-wireless-2.6.tar.bz2 and replaced the original ath9k in the
>> compat-wireless-2.6-old directory. Then I applied the patch from Mats
>> email http://marc.info/?l=linux-wireless&m=122163541519736&q=raw.
>>
>> The patch applied fine, compiled and installed fine. The output that I
>> posted was the result of using this new driver.
>>
>> BTW, as a (sort of) comparison, I am using an USB d-link wireless card
>> with rt73 and the connection is rock solid.
>>
>> Thanks for all your help!
>>
>> Partha
>
> Thanks for the clarification. Can you try disabling NetworkManager
> completely and then try connecting manually?
>
> Please see here how to completely stop Network Manager:
>
> http://wireless.kernel.org/en/users/Reporting_bugs#ReportingbugsinNetworkManager
>
> (this is how:
>
> sudo /sbin/service NetworkMananger stop
> sudo killall -TERM wpa_supplicant
>
> )
>
> Then, provide the logs of your session. What is your environment like?
> WEP, WPA, WPA2, or no encryption? You will need to run wpa_supplicant manually
> if you disable Network Manager and have encryption using WPA or WPA2. If
> you just have WEP you can use iwconfig.
>
>  Luis
>

Hi Luis,

My log is replayed below. In response to your questions, I am not
using any encyrptions.

Here are the steps I took and the log output:

Here is what I did:

service NetworkManager stop
service wpa_supplicant stop
dhclient wlan1

Output from /var/log/messages
---------
Sep 20 07:26:22 Bordeaux NetworkManager: <WARN>  nm_signal_handler():
Caught signal 15, shutting down normally.
Sep 20 07:26:22 Bordeaux NetworkManager: <info>  (wlan1): now unmanaged
Sep 20 07:26:22 Bordeaux NetworkManager: <info>  (wlan1): device state
change: 3 -> 1
Sep 20 07:26:22 Bordeaux NetworkManager: <info>  (wlan1): cleaning up...
Sep 20 07:26:22 Bordeaux NetworkManager: <info>  (wlan1): taking down device.
Sep 20 07:26:22 Bordeaux avahi-daemon[2381]: Withdrawing address
record for fe80::21f:e2ff:fece:f164 on wlan1.
Sep 20 07:26:54 Bordeaux kernel: ForceXPAon: 0
Sep 20 07:26:54 Bordeaux kernel: ADDRCONF(NETDEV_UP): wlan1: link is not ready
Sep 20 07:26:54 Bordeaux kernel: ForceXPAon: 0
Sep 20 07:26:54 Bordeaux kernel: ADDRCONF(NETDEV_CHANGE): wlan1: link
becomes ready
Sep 20 07:26:56 Bordeaux avahi-daemon[2381]: Registering new address
record for fe80::21f:e2ff:fece:f164 on wlan1.*.
Sep 20 07:26:58 Bordeaux dhclient: DHCPDISCOVER on wlan1 to
255.255.255.255 port 67 interval 7
Sep 20 07:26:59 Bordeaux dhclient: DHCPOFFER from 192.168.1.1
Sep 20 07:26:59 Bordeaux dhclient: DHCPREQUEST on wlan1 to
255.255.255.255 port 67
Sep 20 07:26:59 Bordeaux dhclient: DHCPACK from 192.168.1.1
Sep 20 07:26:59 Bordeaux avahi-daemon[2381]: Joining mDNS multicast
group on interface wlan1.IPv4 with address 192.168.1.102.
Sep 20 07:26:59 Bordeaux avahi-daemon[2381]: New relevant interface
wlan1.IPv4 for mDNS.
Sep 20 07:26:59 Bordeaux avahi-daemon[2381]: Registering new address
record for 192.168.1.102 on wlan1.IPv4.
Sep 20 07:26:59 Bordeaux NET[3878]: /sbin/dhclient-script : updated
/etc/resolv.conf
Sep 20 07:26:59 Bordeaux dhclient: bound to 192.168.1.102 -- renewal
in 39265 seconds.
---------

Then at 7:43 network dies silently without any output in /var/log/messages.

Then I kill dhclient. After that, I do dhclient wlan1 again:
---------

Sep 20 07:43:56 Bordeaux avahi-daemon[2381]: Withdrawing address
record for 192.168.1.102 on wlan1.
Sep 20 07:43:56 Bordeaux avahi-daemon[2381]: Leaving mDNS multicast
group on interface wlan1.IPv4 with address 192.168.1.102.
Sep 20 07:43:56 Bordeaux avahi-daemon[2381]: Interface wlan1.IPv4 no
longer relevant for mDNS.
Sep 20 07:43:57 Bordeaux dhclient: DHCPREQUEST on wlan1 to
255.255.255.255 port 67
Sep 20 07:44:00 Bordeaux dhclient: DHCPREQUEST on wlan1 to
255.255.255.255 port 67
Sep 20 07:44:06 Bordeaux dhclient: DHCPREQUEST on wlan1 to
255.255.255.255 port 67
Sep 20 07:44:13 Bordeaux dhclient: DHCPDISCOVER on wlan1 to
255.255.255.255 port 67 interval 5
Sep 20 07:44:18 Bordeaux dhclient: DHCPDISCOVER on wlan1 to
255.255.255.255 port 67 interval 8
Sep 20 07:44:26 Bordeaux dhclient: DHCPDISCOVER on wlan1 to
255.255.255.255 port 67 interval 8
Sep 20 07:44:34 Bordeaux dhclient: DHCPDISCOVER on wlan1 to
255.255.255.255 port 67 interval 11
Sep 20 07:44:45 Bordeaux dhclient: DHCPDISCOVER on wlan1 to
255.255.255.255 port 67 interval 12
Sep 20 07:44:57 Bordeaux dhclient: DHCPDISCOVER on wlan1 to
255.255.255.255 port 67 interval 11
Sep 20 07:45:08 Bordeaux dhclient: DHCPDISCOVER on wlan1 to
255.255.255.255 port 67 interval 6
Sep 20 07:45:14 Bordeaux dhclient: No DHCPOFFERS received.
Sep 20 07:45:14 Bordeaux dhclient: Trying recorded lease 192.168.1.102
Sep 20 07:45:14 Bordeaux avahi-daemon[2381]: Joining mDNS multicast
group on interface wlan1.IPv4 with address 192.168.1.102.
Sep 20 07:45:14 Bordeaux avahi-daemon[2381]: New relevant interface
wlan1.IPv4 for mDNS.
Sep 20 07:45:14 Bordeaux avahi-daemon[2381]: Registering new address
record for 192.168.1.102 on wlan1.IPv4.
Sep 20 07:45:17 Bordeaux avahi-daemon[2381]: Withdrawing address
record for 192.168.1.102 on wlan1.
Sep 20 07:45:17 Bordeaux avahi-daemon[2381]: Leaving mDNS multicast
group on interface wlan1.IPv4 with address 192.168.1.102.
Sep 20 07:45:17 Bordeaux dhclient: No working leases in persistent
database - sleeping.
Sep 20 07:45:17 Bordeaux avahi-daemon[2381]: Interface wlan1.IPv4 no
longer relevant for mDNS.
Sep 20 07:45:17 Bordeaux avahi-daemon[2381]: Withdrawing address
record for fe80::21f:e2ff:fece:f164 on wlan1.
Sep 20 07:45:17 Bordeaux NET[10791]: /sbin/dhclient-script : updated
/etc/resolv.conf
Sep 20 07:45:17 Bordeaux dhclient: receive_packet failed on wlan1:
Network is down
---------

Trying various combinations of unloading and reloading ath9k did not
revive the card or the network.

Finally, restarted Networkmanager and was able to restore connection.
---------
Sep 20 08:11:19 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:11:19 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:11:19 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:11:19 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:11:43 Bordeaux NetworkManager: <info>  Activation (wlan1)
starting connection 'Auto linksys'
Sep 20 08:11:43 Bordeaux NetworkManager: <info>  (wlan1): device state
change: 3 -> 4
Sep 20 08:11:43 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 1 of 5 (Device Prepare) scheduled...
Sep 20 08:11:43 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 1 of 5 (Device Prepare) started...
Sep 20 08:11:43 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 2 of 5 (Device Configure) scheduled...
Sep 20 08:11:43 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 1 of 5 (Device Prepare) complete.
Sep 20 08:11:43 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 2 of 5 (Device Configure) starting...
Sep 20 08:11:43 Bordeaux NetworkManager: <info>  (wlan1): device state
change: 4 -> 5
Sep 20 08:11:43 Bordeaux NetworkManager: <info>  Activation
(wlan1/wireless): connection 'Auto linksys' requires no security.  No
secrets needed.
Sep 20 08:11:43 Bordeaux NetworkManager: <info>  Config: added 'ssid'
value 'linksys'
Sep 20 08:11:43 Bordeaux NetworkManager: <info>  Config: added
'scan_ssid' value '1'
Sep 20 08:11:43 Bordeaux NetworkManager: <info>  Config: added
'key_mgmt' value 'NONE'
Sep 20 08:11:43 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 2 of 5 (Device Configure) complete.
Sep 20 08:11:43 Bordeaux NetworkManager: <info>  Config: set interface
ap_scan to 1
Sep 20 08:11:43 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 1 -> 2
Sep 20 08:11:43 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:11:43 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:11:43 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:11:44 Bordeaux dhclient: DHCPDISCOVER on wlan1 to
255.255.255.255 port 67 interval 6
Sep 20 08:11:44 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:11:44 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 2 -> 3
Sep 20 08:11:44 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:11:44 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:11:44 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 3 -> 4
Sep 20 08:11:44 Bordeaux NetworkManager: <info>  (wlan1): supplicant
connection state change: 4 -> 7
Sep 20 08:11:44 Bordeaux NetworkManager: <info>  Activation
(wlan1/wireless) Stage 2 of 5 (Device Configure) successful.
Connected to wireless network 'linksys'.
Sep 20 08:11:44 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 3 of 5 (IP Configure Start) scheduled.
Sep 20 08:11:44 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 3 of 5 (IP Configure Start) started...
Sep 20 08:11:44 Bordeaux NetworkManager: <info>  (wlan1): device state
change: 5 -> 7
Sep 20 08:11:44 Bordeaux NetworkManager: <info>  Activation (wlan1)
Beginning DHCP transaction.
Sep 20 08:11:44 Bordeaux NetworkManager: <info>  dhclient started with pid 22934
Sep 20 08:11:44 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 3 of 5 (IP Configure Start) complete.
Sep 20 08:11:44 Bordeaux dhclient: Internet Systems Consortium DHCP Client 4.0.0
Sep 20 08:11:44 Bordeaux dhclient: Copyright 2004-2007 Internet
Systems Consortium.
Sep 20 08:11:44 Bordeaux dhclient: All rights reserved.
Sep 20 08:11:44 Bordeaux dhclient: For info, please visit
http://www.isc.org/sw/dhcp/
Sep 20 08:11:44 Bordeaux dhclient:
Sep 20 08:11:44 Bordeaux NetworkManager: <info>  DHCP: device wlan1
state changed (null) -> preinit
Sep 20 08:11:44 Bordeaux dhclient: Listening on LPF/wlan1/00:1f:e2:ce:f1:64
Sep 20 08:11:44 Bordeaux dhclient: Sending on   LPF/wlan1/00:1f:e2:ce:f1:64
Sep 20 08:11:44 Bordeaux dhclient: Sending on   Socket/fallback
Sep 20 08:11:44 Bordeaux dhclient: DHCPDISCOVER on wlan1 to
255.255.255.255 port 67 interval 6
Sep 20 08:11:45 Bordeaux dhclient: DHCPOFFER from 192.168.1.1
Sep 20 08:11:45 Bordeaux dhclient: DHCPREQUEST on wlan1 to
255.255.255.255 port 67
Sep 20 08:11:45 Bordeaux dhclient: DHCPACK from 192.168.1.1
Sep 20 08:11:45 Bordeaux dhclient: bound to 192.168.1.102 -- renewal
in 38085 seconds.
Sep 20 08:11:45 Bordeaux NetworkManager: <info>  DHCP: device wlan1
state changed preinit -> bound
Sep 20 08:11:45 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 4 of 5 (IP Configure Get) scheduled...
Sep 20 08:11:45 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 4 of 5 (IP Configure Get) started...
Sep 20 08:11:45 Bordeaux NetworkManager: <info>    address 192.168.1.102
Sep 20 08:11:45 Bordeaux NetworkManager: <info>    netmask 255.255.255.0
Sep 20 08:11:45 Bordeaux NetworkManager: <info>    gateway 192.168.1.1
Sep 20 08:11:45 Bordeaux NetworkManager: <info>    hostname 'Bordeaux'
Sep 20 08:11:45 Bordeaux NetworkManager: <info>    nameserver '68.87.64.146'
Sep 20 08:11:45 Bordeaux NetworkManager: <info>    nameserver '68.87.75.194'
Sep 20 08:11:45 Bordeaux NetworkManager: <info>    nameserver '68.87.71.226'
Sep 20 08:11:45 Bordeaux NetworkManager: <info>    domain name
'hsd1.nj.comcast.net.'
Sep 20 08:11:45 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 5 of 5 (IP Configure Commit) scheduled...
Sep 20 08:11:45 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 4 of 5 (IP Configure Get) complete.
Sep 20 08:11:45 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 5 of 5 (IP Configure Commit) started...
Sep 20 08:11:45 Bordeaux avahi-daemon[22631]: Joining mDNS multicast
group on interface wlan1.IPv4 with address 192.168.1.102.
Sep 20 08:11:45 Bordeaux avahi-daemon[22631]: New relevant interface
wlan1.IPv4 for mDNS.
Sep 20 08:11:45 Bordeaux avahi-daemon[22631]: Registering new address
record for 192.168.1.102 on wlan1.IPv4.
Sep 20 08:11:46 Bordeaux NetworkManager: <info>  (wlan1): device state
change: 7 -> 8
Sep 20 08:11:46 Bordeaux NetworkManager: <info>  Policy set (wlan1) as
default device for routing and DNS.
Sep 20 08:11:46 Bordeaux NetworkManager: <info>  Activation (wlan1)
successful, device activated.
Sep 20 08:11:46 Bordeaux NetworkManager: <info>  Activation (wlan1)
Stage 5 of 5 (IP Configure Commit) complete.
Sep 20 08:11:49 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:11:49 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:11:49 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:11:49 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:11:50 Bordeaux dhclient: DHCPDISCOVER on wlan1 to
255.255.255.255 port 67 interval 10
Sep 20 08:11:51 Bordeaux dhclient: DHCPOFFER from 192.168.1.1
Sep 20 08:11:51 Bordeaux dhclient: DHCPREQUEST on wlan1 to
255.255.255.255 port 67
Sep 20 08:11:51 Bordeaux dhclient: DHCPACK from 192.168.1.1
Sep 20 08:11:51 Bordeaux NET[23087]: /sbin/dhclient-script : updated
/etc/resolv.conf
Sep 20 08:11:51 Bordeaux dhclient: bound to 192.168.1.102 -- renewal
in 41541 seconds.
Sep 20 08:12:29 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:12:29 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:12:29 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:12:29 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:13:29 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:13:29 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:13:29 Bordeaux kernel: ForceXPAon: 0
Sep 20 08:13:29 Bordeaux kernel: ForceXPAon: 0
_______

Currently the network has been up for 24 minutes. I will let you know
how long it will last.

Thanks again.

Partha

[ath9k-devel] ath9k constantly drops network connection

[Partha Bagchi]

--snip---
>
> Currently the network has been up for 24 minutes. I will let you know
> how long it will last.
>
> Thanks again.
>
> Partha
>

The connection died after 54 minutes. But I was able to restore with
NetworkManager.

BTW, why all the ForceXPAon: 0 messages?

Thanks,
Partha

[ath9k-devel] ath9k constantly drops network connection

[Luis R. Rodriguez]

On Sat, Sep 20, 2008 at 6:07 AM, Partha Bagchi <partha1b@gmail.com> wrote:
> --snip---
>>
>> Currently the network has been up for 24 minutes. I will let you know
>> how long it will last.
>>
>> Thanks again.
>>
>> Partha
>>
>
> The connection died after 54 minutes. But I was able to restore with
> NetworkManager.
>
> BTW, why all the ForceXPAon: 0 messages?

All I can see right now is we are setting this for our newer chipsets
during reset, it should only be printed during debug but right now it
*always* prints, so we'll fix that. Since it *always* happens it
shouldn't be bad, but I don't have documentation on what this is right
now so I can't tell you what it is for sure.

Can you do me a favor of pasting the output of:

sudo dmesg -c > /dev/null
sudo rmmod ath9k
sudo modprobe ath9k
sudo dmesg -c

Also, what type of box do you have (standard PC, MacBook, MacBook Pro), etc?

I have to say that since this is on 2.6.26 we haven't tested this
thoroughly but will try to help you get it working right anyway.

  Luis

[ath9k-devel] ath9k constantly drops network connection

[Partha Bagchi]

On Sat, Sep 20, 2008 at 3:57 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Sat, Sep 20, 2008 at 6:07 AM, Partha Bagchi <partha1b@gmail.com> wrote:
>> --snip---
>>>
>>> Currently the network has been up for 24 minutes. I will let you know
>>> how long it will last.
>>>
>>> Thanks again.
>>>
>>> Partha
>>>
>>
>> The connection died after 54 minutes. But I was able to restore with
>> NetworkManager.
>>
>> BTW, why all the ForceXPAon: 0 messages?
>
> All I can see right now is we are setting this for our newer chipsets
> during reset, it should only be printed during debug but right now it
> *always* prints, so we'll fix that. Since it *always* happens it
> shouldn't be bad, but I don't have documentation on what this is right
> now so I can't tell you what it is for sure.
>
> Can you do me a favor of pasting the output of:
>
> sudo dmesg -c > /dev/null
> sudo rmmod ath9k
> sudo modprobe ath9k
> sudo dmesg -c
>
> Also, what type of box do you have (standard PC, MacBook, MacBook Pro), etc?
>
> I have to say that since this is on 2.6.26 we haven't tested this
> thoroughly but will try to help you get it working right anyway.
>
>  Luis
>

Hi Luis,

In reply to your questions, I have a Sony VGN-FW139E laptop. Please
let me know if you want the output of
lspci.

Here is the output you asked for.
-------
[root at Bordeaux ~]# dmesg -c > /dev/null
[root at Bordeaux ~]# rmmod ath9k
[root at Bordeaux ~]# modprobe ath9k
[root at Bordeaux ~]# dmesg
ACPI: PCI interrupt for device 0000:06:00.0 disabled
ath9k: driver unloaded
ath9k: 0.1
ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:06:00.0 to 64
phy4: Selected rate control algorithm 'ath9k_rate_control'
Registered led device: ath9k-phy4:radio
Registered led device: ath9k-phy4:assoc
Registered led device: ath9k-phy4:tx
Registered led device: ath9k-phy4:rx
phy4: Atheros 9280: mem=0xf8b20000, irq=19
udev: renamed network interface wlan0 to wlan1
ForceXPAon: 0
ADDRCONF(NETDEV_UP): wlan1: link is not ready
ForceXPAon: 0
ForceXPAon: 0
ForceXPAon: 0
ForceXPAon: 0
wlan1: authenticate with AP 00:14:bf:85:52:fd
wlan1: authenticated
wlan1: associate with AP 00:14:bf:85:52:fd
wlan1: RX AssocResp from 00:14:bf:85:52:fd (capab=0x401 status=0 aid=1)
wlan1: associated
ForceXPAon: 0
ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
wlan1: disassociating by local choice (reason=3)
[root at Bordeaux ~]#
------

I will be happy to use the 2.6.27 kernel from rawhide if it will help
my connection.

Thanks again,
Partha

[ath9k-devel] ath9k constantly drops network connection

[Luis R. Rodriguez]

On Sat, Sep 20, 2008 at 01:31:48PM -0700, Partha Bagchi wrote:
> On Sat, Sep 20, 2008 at 3:57 PM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
> > On Sat, Sep 20, 2008 at 6:07 AM, Partha Bagchi <partha1b@gmail.com> wrote:
> >> --snip---
> >>>
> >>> Currently the network has been up for 24 minutes. I will let you know
> >>> how long it will last.
> >>>
> >>> Thanks again.
> >>>
> >>> Partha
> >>>
> >>
> >> The connection died after 54 minutes. But I was able to restore with
> >> NetworkManager.
> >>
> >> BTW, why all the ForceXPAon: 0 messages?
> >
> > All I can see right now is we are setting this for our newer chipsets
> > during reset, it should only be printed during debug but right now it
> > *always* prints, so we'll fix that. Since it *always* happens it
> > shouldn't be bad, but I don't have documentation on what this is right
> > now so I can't tell you what it is for sure.
> >
> > Can you do me a favor of pasting the output of:
> >
> > sudo dmesg -c > /dev/null
> > sudo rmmod ath9k
> > sudo modprobe ath9k
> > sudo dmesg -c
> >
> > Also, what type of box do you have (standard PC, MacBook, MacBook Pro), etc?
> >
> > I have to say that since this is on 2.6.26 we haven't tested this
> > thoroughly but will try to help you get it working right anyway.
> >
> >  Luis
> >
> 
> Hi Luis,
> 
> In reply to your questions, I have a Sony VGN-FW139E laptop. Please
> let me know if you want the output of
> lspci.
> 
> Here is the output you asked for.
> -------
> [root at Bordeaux ~]# dmesg -c > /dev/null
> [root at Bordeaux ~]# rmmod ath9k
> [root at Bordeaux ~]# modprobe ath9k
> [root at Bordeaux ~]# dmesg
> ACPI: PCI interrupt for device 0000:06:00.0 disabled
> ath9k: driver unloaded
> ath9k: 0.1
> ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 19 (level, low) -> IRQ 19
> PCI: Setting latency timer of device 0000:06:00.0 to 64
> phy4: Selected rate control algorithm 'ath9k_rate_control'
> Registered led device: ath9k-phy4:radio
> Registered led device: ath9k-phy4:assoc
> Registered led device: ath9k-phy4:tx
> Registered led device: ath9k-phy4:rx
> phy4: Atheros 9280: mem=0xf8b20000, irq=19

OK yea this is one of our newer chipsets :)
Is this a laptop? What model? Where you buy it?

> udev: renamed network interface wlan0 to wlan1
> ForceXPAon: 0
> ADDRCONF(NETDEV_UP): wlan1: link is not ready
> ForceXPAon: 0
> ForceXPAon: 0
> ForceXPAon: 0
> ForceXPAon: 0
> wlan1: authenticate with AP 00:14:bf:85:52:fd
> wlan1: authenticated
> wlan1: associate with AP 00:14:bf:85:52:fd
> wlan1: RX AssocResp from 00:14:bf:85:52:fd (capab=0x401 status=0 aid=1)
> wlan1: associated
> ForceXPAon: 0
> ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
> wlan1: disassociating by local choice (reason=3)
> [root at Bordeaux ~]#
> ------
> 
> I will be happy to use the 2.6.27 kernel from rawhide if it will help
> my connection.

Yeah sure, I'd like to help you on 26 but 27 should work better
as that is where we are doing most of our testing. Keep in mind
the group key patch still needs to be applied.

  Luis

[ath9k-devel] ath9k constantly drops network connection

[Partha Bagchi]

On Sat, Sep 20, 2008 at 4:54 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Sat, Sep 20, 2008 at 01:31:48PM -0700, Partha Bagchi wrote:
>> On Sat, Sep 20, 2008 at 3:57 PM, Luis R. Rodriguez
>> <lrodriguez@atheros.com> wrote:
>> > On Sat, Sep 20, 2008 at 6:07 AM, Partha Bagchi <partha1b@gmail.com> wrote:
>> >> --snip---
>> >>>
>> >>> Currently the network has been up for 24 minutes. I will let you know
>> >>> how long it will last.
>> >>>
>> >>> Thanks again.
>> >>>
>> >>> Partha
>> >>>
>> >>
>> >> The connection died after 54 minutes. But I was able to restore with
>> >> NetworkManager.
>> >>
>> >> BTW, why all the ForceXPAon: 0 messages?
>> >
>> > All I can see right now is we are setting this for our newer chipsets
>> > during reset, it should only be printed during debug but right now it
>> > *always* prints, so we'll fix that. Since it *always* happens it
>> > shouldn't be bad, but I don't have documentation on what this is right
>> > now so I can't tell you what it is for sure.
>> >
>> > Can you do me a favor of pasting the output of:
>> >
>> > sudo dmesg -c > /dev/null
>> > sudo rmmod ath9k
>> > sudo modprobe ath9k
>> > sudo dmesg -c
>> >
>> > Also, what type of box do you have (standard PC, MacBook, MacBook Pro), etc?
>> >
>> > I have to say that since this is on 2.6.26 we haven't tested this
>> > thoroughly but will try to help you get it working right anyway.
>> >
>> >  Luis
>> >
>>
>> Hi Luis,
>>
>> In reply to your questions, I have a Sony VGN-FW139E laptop. Please
>> let me know if you want the output of
>> lspci.
>>
>> Here is the output you asked for.
>> -------
>> [root at Bordeaux ~]# dmesg -c > /dev/null
>> [root at Bordeaux ~]# rmmod ath9k
>> [root at Bordeaux ~]# modprobe ath9k
>> [root at Bordeaux ~]# dmesg
>> ACPI: PCI interrupt for device 0000:06:00.0 disabled
>> ath9k: driver unloaded
>> ath9k: 0.1
>> ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 19 (level, low) -> IRQ 19
>> PCI: Setting latency timer of device 0000:06:00.0 to 64
>> phy4: Selected rate control algorithm 'ath9k_rate_control'
>> Registered led device: ath9k-phy4:radio
>> Registered led device: ath9k-phy4:assoc
>> Registered led device: ath9k-phy4:tx
>> Registered led device: ath9k-phy4:rx
>> phy4: Atheros 9280: mem=0xf8b20000, irq=19
>
> OK yea this is one of our newer chipsets :)
> Is this a laptop? What model? Where you buy it?

Yes - it is a Sony Laptop - their latest 16.4 inch widescreen model.
The model is VGN-FW139E. I couldn't wait so got it at Best-Buy.
>
>> udev: renamed network interface wlan0 to wlan1
>> ForceXPAon: 0
>> ADDRCONF(NETDEV_UP): wlan1: link is not ready
>> ForceXPAon: 0
>> ForceXPAon: 0
>> ForceXPAon: 0
>> ForceXPAon: 0
>> wlan1: authenticate with AP 00:14:bf:85:52:fd
>> wlan1: authenticated
>> wlan1: associate with AP 00:14:bf:85:52:fd
>> wlan1: RX AssocResp from 00:14:bf:85:52:fd (capab=0x401 status=0 aid=1)
>> wlan1: associated
>> ForceXPAon: 0
>> ADDRCONF(NETDEV_CHANGE): wlan1: link becomes ready
>> wlan1: disassociating by local choice (reason=3)
>> [root at Bordeaux ~]#
>> ------
>>
>> I will be happy to use the 2.6.27 kernel from rawhide if it will help
>> my connection.
>
> Yeah sure, I'd like to help you on 26 but 27 should work better
> as that is where we are doing most of our testing. Keep in mind
> the group key patch still needs to be applied.
>
>  Luis
>

Don't forget, I already copied the ath9k subdrirectory from the latest
tree and applied the patch and compiled it. Is there anything
intrinsic about the 2.6.27 kernel that will help the connection?

Thanks,
Partha

[ath9k-devel] ath9k constantly drops network connection

[Luis R. Rodriguez]

On Sat, Sep 20, 2008 at 2:19 PM, Partha Bagchi <partha1b@gmail.com> wrote:

> Don't forget, I already copied the ath9k subdrirectory from the latest
> tree and applied the patch and compiled it. Is there anything
> intrinsic about the 2.6.27 kernel that will help the connection?

You get a new shiny mac80211 with all the patches that went in for it.
We can't add the new mac80211 to compat-wireless-old as you did with
ath9k as 2.6.27 had the struct net_device change quite a lot (new TX
multiqueue changes) and backporting this was a major pain in the ass.
Hence we have compat-wireless-old for <= 2.6.26 and compat-wireless
for >= 2.6.27.

Still, if someone wants to go over all 2.6.27 mac80211 patches and
apply them to compat-wireless-old except for the TX MQ related ones,
that should work, but you'll have to find someone with enough
motivation to do it.

  Luis

[ath9k-devel] ath9k constantly drops network connection

[Partha Bagchi]

On Sat, Sep 20, 2008 at 6:54 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Sat, Sep 20, 2008 at 2:19 PM, Partha Bagchi <partha1b@gmail.com> wrote:
>
>> Don't forget, I already copied the ath9k subdrirectory from the latest
>> tree and applied the patch and compiled it. Is there anything
>> intrinsic about the 2.6.27 kernel that will help the connection?
>
> You get a new shiny mac80211 with all the patches that went in for it.
> We can't add the new mac80211 to compat-wireless-old as you did with
> ath9k as 2.6.27 had the struct net_device change quite a lot (new TX
> multiqueue changes) and backporting this was a major pain in the ass.
> Hence we have compat-wireless-old for <= 2.6.26 and compat-wireless
> for >= 2.6.27.
>
> Still, if someone wants to go over all 2.6.27 mac80211 patches and
> apply them to compat-wireless-old except for the TX MQ related ones,
> that should work, but you'll have to find someone with enough
> motivation to do it.
>
>  Luis
>

Thanks. I see your point. I am not sure I can do the job of backporting.

I will investigate updating the kernel from rawhide.

One additional question. I seem to be dropping connection much faster
(every 5 or 10 minutes) in the evening compared to the the morning and
afternoon (every 30 to 40 minutes). Any theories on this?

Thanks,
Partha

[ath9k-devel] ath9k constantly drops network connection

[Luis R. Rodriguez]

On Sat, Sep 20, 2008 at 4:38 PM, Partha Bagchi <partha1b@gmail.com> wrote:
> On Sat, Sep 20, 2008 at 6:54 PM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
>> On Sat, Sep 20, 2008 at 2:19 PM, Partha Bagchi <partha1b@gmail.com> wrote:
>>
>>> Don't forget, I already copied the ath9k subdrirectory from the latest
>>> tree and applied the patch and compiled it. Is there anything
>>> intrinsic about the 2.6.27 kernel that will help the connection?
>>
>> You get a new shiny mac80211 with all the patches that went in for it.
>> We can't add the new mac80211 to compat-wireless-old as you did with
>> ath9k as 2.6.27 had the struct net_device change quite a lot (new TX
>> multiqueue changes) and backporting this was a major pain in the ass.
>> Hence we have compat-wireless-old for <= 2.6.26 and compat-wireless
>> for >= 2.6.27.
>>
>> Still, if someone wants to go over all 2.6.27 mac80211 patches and
>> apply them to compat-wireless-old except for the TX MQ related ones,
>> that should work, but you'll have to find someone with enough
>> motivation to do it.
>>
>>  Luis
>>
>
> Thanks. I see your point. I am not sure I can do the job of backporting.
>
> I will investigate updating the kernel from rawhide.
>
> One additional question. I seem to be dropping connection much faster
> (every 5 or 10 minutes) in the evening compared to the the morning and
> afternoon (every 30 to 40 minutes). Any theories on this?

More noise when people get home perhaps, depends on where you live. We
haven't yet added ANI which should help with that, but work is
underway for it. ANI helps with adjusting the hardware due to noise,
it helps with reception.

  Luis

[ath9k-devel] ath9k constantly drops network connection

[Partha Bagchi]

On Sat, Sep 20, 2008 at 7:48 PM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Sat, Sep 20, 2008 at 4:38 PM, Partha Bagchi <partha1b@gmail.com> wrote:
>> On Sat, Sep 20, 2008 at 6:54 PM, Luis R. Rodriguez
>> <lrodriguez@atheros.com> wrote:
>>> On Sat, Sep 20, 2008 at 2:19 PM, Partha Bagchi <partha1b@gmail.com> wrote:
>>>
>>>> Don't forget, I already copied the ath9k subdrirectory from the latest
>>>> tree and applied the patch and compiled it. Is there anything
>>>> intrinsic about the 2.6.27 kernel that will help the connection?
>>>
>>> You get a new shiny mac80211 with all the patches that went in for it.
>>> We can't add the new mac80211 to compat-wireless-old as you did with
>>> ath9k as 2.6.27 had the struct net_device change quite a lot (new TX
>>> multiqueue changes) and backporting this was a major pain in the ass.
>>> Hence we have compat-wireless-old for <= 2.6.26 and compat-wireless
>>> for >= 2.6.27.
>>>
>>> Still, if someone wants to go over all 2.6.27 mac80211 patches and
>>> apply them to compat-wireless-old except for the TX MQ related ones,
>>> that should work, but you'll have to find someone with enough
>>> motivation to do it.
>>>
>>>  Luis
>>>
>>
>> Thanks. I see your point. I am not sure I can do the job of backporting.
>>
>> I will investigate updating the kernel from rawhide.
>>
>> One additional question. I seem to be dropping connection much faster
>> (every 5 or 10 minutes) in the evening compared to the the morning and
>> afternoon (every 30 to 40 minutes). Any theories on this?
>
> More noise when people get home perhaps, depends on where you live. We
> haven't yet added ANI which should help with that, but work is
> underway for it. ANI helps with adjusting the hardware due to noise,
> it helps with reception.
>
>  Luis
>

Thanks. Now I am having the weirdest thing happening. Suddenly, I am
getting these messages (while my connection is up and running fine!):
-------
Sep 20 19:53:11 Bordeaux kernel: ForceXPAon: 0
Sep 20 19:53:11 Bordeaux kernel: ForceXPAon: 0
Sep 20 19:53:11 Bordeaux kernel: ForceXPAon: 0
Sep 20 19:53:11 Bordeaux kernel: ForceXPAon: 0
Sep 20 19:53:12 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
Sep 20 19:53:29 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
Sep 20 19:53:45 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
Sep 20 19:53:58 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
Sep 20 19:54:09 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
Sep 20 19:54:17 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
Sep 20 19:54:32 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
Sep 20 19:54:42 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
Sep 20 19:54:54 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
Sep 20 19:55:11 Bordeaux kernel: ForceXPAon: 0
------

Hmmm,

Partha

[ath9k-devel] ath9k constantly drops network connection

[Luis R. Rodriguez]

On Sat, Sep 20, 2008 at 04:56:30PM -0700, Partha Bagchi wrote:
> On Sat, Sep 20, 2008 at 7:48 PM, Luis R. Rodriguez
> <lrodriguez@atheros.com> wrote:
> > On Sat, Sep 20, 2008 at 4:38 PM, Partha Bagchi <partha1b@gmail.com> wrote:
> >> On Sat, Sep 20, 2008 at 6:54 PM, Luis R. Rodriguez
> >> <lrodriguez@atheros.com> wrote:
> >>> On Sat, Sep 20, 2008 at 2:19 PM, Partha Bagchi <partha1b@gmail.com> wrote:
> >>>
> >>>> Don't forget, I already copied the ath9k subdrirectory from the latest
> >>>> tree and applied the patch and compiled it. Is there anything
> >>>> intrinsic about the 2.6.27 kernel that will help the connection?
> >>>
> >>> You get a new shiny mac80211 with all the patches that went in for it.
> >>> We can't add the new mac80211 to compat-wireless-old as you did with
> >>> ath9k as 2.6.27 had the struct net_device change quite a lot (new TX
> >>> multiqueue changes) and backporting this was a major pain in the ass.
> >>> Hence we have compat-wireless-old for <= 2.6.26 and compat-wireless
> >>> for >= 2.6.27.
> >>>
> >>> Still, if someone wants to go over all 2.6.27 mac80211 patches and
> >>> apply them to compat-wireless-old except for the TX MQ related ones,
> >>> that should work, but you'll have to find someone with enough
> >>> motivation to do it.
> >>>
> >>>  Luis
> >>>
> >>
> >> Thanks. I see your point. I am not sure I can do the job of backporting.
> >>
> >> I will investigate updating the kernel from rawhide.
> >>
> >> One additional question. I seem to be dropping connection much faster
> >> (every 5 or 10 minutes) in the evening compared to the the morning and
> >> afternoon (every 30 to 40 minutes). Any theories on this?
> >
> > More noise when people get home perhaps, depends on where you live. We
> > haven't yet added ANI which should help with that, but work is
> > underway for it. ANI helps with adjusting the hardware due to noise,
> > it helps with reception.
> >
> >  Luis
> >
> 
> Thanks. Now I am having the weirdest thing happening. Suddenly, I am
> getting these messages (while my connection is up and running fine!):
> -------
> Sep 20 19:53:11 Bordeaux kernel: ForceXPAon: 0
> Sep 20 19:53:11 Bordeaux kernel: ForceXPAon: 0
> Sep 20 19:53:11 Bordeaux kernel: ForceXPAon: 0
> Sep 20 19:53:11 Bordeaux kernel: ForceXPAon: 0

Ignore these.

> Sep 20 19:53:12 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
> Sep 20 19:53:29 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
> Sep 20 19:53:45 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
> Sep 20 19:53:58 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
> Sep 20 19:54:09 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
> Sep 20 19:54:17 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
> Sep 20 19:54:32 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
> Sep 20 19:54:42 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
> Sep 20 19:54:54 Bordeaux dhclient: DHCPREQUEST on wlan1 to 192.168.1.1 port 67
> Sep 20 19:55:11 Bordeaux kernel: ForceXPAon: 0

Are you on 2.6.27-rc7? You'll still need the group key patch, which was
not merged in for rc7.

  Luis

[ath9k-devel] ath9k constantly drops network connection

[Mats Johannesson]

On Wed, 17 Sep 2008 12:10:03 -0700 Luis R. Rodriguez wrote:
> On Wed, Sep 17, 2008 at 03:05:59AM -0700, Partha Bagchi wrote:
[...]
> > 03:42:27 EDT 2008 i686 i686 i386 GNU/Linux
> 
> Please try appling the patch titled:
> 
> "[PATCH] ath9k: connectivity is lost after Group rekeying is done"
> 
> which was posted on linux-wireless. If that fixes your issue I can

A question Luis. Looking at the code (and not knowing _anything_ about
wireless internals):

-		if (sc->sc_keytype == ATH9K_CIPHER_WEP)
+		if (tx_info->control.hw_key->alg == ALG_WEP)
 			txctl->keytype = ATH9K_KEY_TYPE_WEP;
-		else if (sc->sc_keytype == ATH9K_CIPHER_TKIP)
+		else if (tx_info->control.hw_key->alg == ALG_TKIP)
 			txctl->keytype = ATH9K_KEY_TYPE_TKIP;
-		else if (sc->sc_keytype == ATH9K_CIPHER_AES_CCM)
+		else if (tx_info->control.hw_key->alg == ALG_CCMP)
 			txctl->keytype = ATH9K_KEY_TYPE_AES;

I'm confused regarding the AES cypher. My AP is set through its
interface as:

Security Mode: WPA-Personal
WPA Mode: WPA2 Only
Cipher Type: AES
Group Key Update Interval: 2461 seconds (~41 minutes)
Pre-Shared Key: Loooong long key.

But the output from "iwlist scan" tells another story:

                    Encryption key:on
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (1) : TKIP
                        Authentication Suites (1) : PSK

So someones lying... Does this effect ath9k?

I'll compile another kernel and try to get rid of TKIP stuff completely
to test this out. At the moment the environment looks like this:

grep -i tkip my-.config
grep -i michael my-.config
# CONFIG_CRYPTO_MICHAEL_MIC is not set
grep -i ecb my-.config
CONFIG_CRYPTO_ECB=m
grep -i aes my-.config
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_X86_64=m

loke at sleipner:~$ lsmod|grep -i ecb
ecb                     1344  2
crypto_blkcipher        8964  1 ecb
crypto_algapi           6336  6 aes_x86_64,aes_generic,arc4,ecb,crypto_blkcipher,cryptomgr

loke at sleipner:~$ lsmod|grep -i aes
aes_x86_64              6784  3
aes_generic            25576  1 aes_x86_64
crypto_algapi           6336  6 aes_x86_64,aes_generic,arc4,ecb,crypto_blkcipher,cryptomgr

Perhaps I'll break ath9k if the kernel lets me compile without an ecb
module...

Mvh
Mats Johannesson

[ath9k-devel] ath9k constantly drops network connection

[Mats Johannesson]

On Thu, 18 Sep 2008 04:46:18 +0200 Mats Johannesson wrote:
> On Wed, 17 Sep 2008 12:10:03 -0700 Luis R. Rodriguez wrote:
> > On Wed, Sep 17, 2008 at 03:05:59AM -0700, Partha Bagchi wrote:
> [...]
> > > 03:42:27 EDT 2008 i686 i686 i386 GNU/Linux
> > 
> > Please try appling the patch titled:
> > 
> > "[PATCH] ath9k: connectivity is lost after Group rekeying is done"
> > 
> > which was posted on linux-wireless. If that fixes your issue I can
> 
> A question Luis. Looking at the code (and not knowing _anything_ about
> wireless internals):
> 
> -		if (sc->sc_keytype == ATH9K_CIPHER_WEP)
> +		if (tx_info->control.hw_key->alg == ALG_WEP)
>  			txctl->keytype = ATH9K_KEY_TYPE_WEP;
> -		else if (sc->sc_keytype == ATH9K_CIPHER_TKIP)
> +		else if (tx_info->control.hw_key->alg == ALG_TKIP)
>  			txctl->keytype = ATH9K_KEY_TYPE_TKIP;
> -		else if (sc->sc_keytype == ATH9K_CIPHER_AES_CCM)
> +		else if (tx_info->control.hw_key->alg == ALG_CCMP)
>  			txctl->keytype = ATH9K_KEY_TYPE_AES;
> 
> I'm confused regarding the AES cypher. My AP is set through its
> interface as:
> 
> Security Mode: WPA-Personal
> WPA Mode: WPA2 Only
> Cipher Type: AES
> Group Key Update Interval: 2461 seconds (~41 minutes)
> Pre-Shared Key: Loooong long key.
> 
> But the output from "iwlist scan" tells another story:
> 
>                     Encryption key:on
>                     IE: IEEE 802.11i/WPA2 Version 1
>                         Group Cipher : TKIP
>                         Pairwise Ciphers (1) : TKIP
>                         Authentication Suites (1) : PSK
> 
> So someones lying... Does this effect ath9k?
> 
> I'll compile another kernel and try to get rid of TKIP stuff
> completely to test this out. At the moment the environment looks like
> this:
> 
> grep -i tkip my-.config
> grep -i michael my-.config
> # CONFIG_CRYPTO_MICHAEL_MIC is not set
> grep -i ecb my-.config
> CONFIG_CRYPTO_ECB=m
> grep -i aes my-.config
> CONFIG_CRYPTO_AES=m
> CONFIG_CRYPTO_AES_X86_64=m
> 
> loke at sleipner:~$ lsmod|grep -i ecb
> ecb                     1344  2
> crypto_blkcipher        8964  1 ecb
> crypto_algapi           6336  6
> aes_x86_64,aes_generic,arc4,ecb,crypto_blkcipher,cryptomgr
> 
> loke at sleipner:~$ lsmod|grep -i aes
> aes_x86_64              6784  3
> aes_generic            25576  1 aes_x86_64
> crypto_algapi           6336  6
> aes_x86_64,aes_generic,arc4,ecb,crypto_blkcipher,cryptomgr
> 
> Perhaps I'll break ath9k if the kernel lets me compile without an ecb
> module...

Well, it didn't let me deselect ecb since that is selected by MAC80211
(as is arc4).

Anyhow, writing now to share the good news that the patch you refer to:
[PATCH] ath9k: connectivity is lost after Group rekeying is done
(Click on [Download message RAW] at
http://marc.info/?l=linux-wireless&m=122163541519736&w=2 to get a clean
copy) completely fixes the regression between -rc5 and -rc6 I reported
in:

[ath9k-devel] 2.6.27-rc6 (and forwartd to -rc6-git3) dies silently.
https://lists.ath9k.org/pipermail/ath9k-devel/2008-September/000263.html

Patching -rc6-git3 I've now run 4 hours without a connection drop.
Strangely enough it also allowed me to again make the connection
'sticky' over a reboot (Wicd Manager).

This patch is a must have for 2.6.27 no matter what merging policy is
in effect.

Mvh
Mats Johannesson

[ath9k-devel] ath9k constantly drops network connection

[Luis R. Rodriguez]

On Thu, Sep 18, 2008 at 1:36 AM, Mats Johannesson <spamcan1@abrasax.se> wrote:
> On Thu, 18 Sep 2008 04:46:18 +0200 Mats Johannesson wrote:
>> On Wed, 17 Sep 2008 12:10:03 -0700 Luis R. Rodriguez wrote:
>> > On Wed, Sep 17, 2008 at 03:05:59AM -0700, Partha Bagchi wrote:
>> [...]
>> > > 03:42:27 EDT 2008 i686 i686 i386 GNU/Linux
>> >
>> > Please try appling the patch titled:
>> >
>> > "[PATCH] ath9k: connectivity is lost after Group rekeying is done"
>> >
>> > which was posted on linux-wireless. If that fixes your issue I can
>>
>> A question Luis. Looking at the code (and not knowing _anything_ about
>> wireless internals):
>>
>> -             if (sc->sc_keytype == ATH9K_CIPHER_WEP)
>> +             if (tx_info->control.hw_key->alg == ALG_WEP)
>>                       txctl->keytype = ATH9K_KEY_TYPE_WEP;
>> -             else if (sc->sc_keytype == ATH9K_CIPHER_TKIP)
>> +             else if (tx_info->control.hw_key->alg == ALG_TKIP)
>>                       txctl->keytype = ATH9K_KEY_TYPE_TKIP;
>> -             else if (sc->sc_keytype == ATH9K_CIPHER_AES_CCM)
>> +             else if (tx_info->control.hw_key->alg == ALG_CCMP)
>>                       txctl->keytype = ATH9K_KEY_TYPE_AES;
>>
>> I'm confused regarding the AES cypher. My AP is set through its
>> interface as:
>>
>> Security Mode: WPA-Personal
>> WPA Mode: WPA2 Only
>> Cipher Type: AES
>> Group Key Update Interval: 2461 seconds (~41 minutes)
>> Pre-Shared Key: Loooong long key.
>>
>> But the output from "iwlist scan" tells another story:
>>
>>                     Encryption key:on
>>                     IE: IEEE 802.11i/WPA2 Version 1
>>                         Group Cipher : TKIP
>>                         Pairwise Ciphers (1) : TKIP
>>                         Authentication Suites (1) : PSK
>>
>> So someones lying... Does this effect ath9k?
>>
>> I'll compile another kernel and try to get rid of TKIP stuff
>> completely to test this out. At the moment the environment looks like
>> this:
>>
>> grep -i tkip my-.config
>> grep -i michael my-.config
>> # CONFIG_CRYPTO_MICHAEL_MIC is not set
>> grep -i ecb my-.config
>> CONFIG_CRYPTO_ECB=m
>> grep -i aes my-.config
>> CONFIG_CRYPTO_AES=m
>> CONFIG_CRYPTO_AES_X86_64=m
>>
>> loke at sleipner:~$ lsmod|grep -i ecb
>> ecb                     1344  2
>> crypto_blkcipher        8964  1 ecb
>> crypto_algapi           6336  6
>> aes_x86_64,aes_generic,arc4,ecb,crypto_blkcipher,cryptomgr
>>
>> loke at sleipner:~$ lsmod|grep -i aes
>> aes_x86_64              6784  3
>> aes_generic            25576  1 aes_x86_64
>> crypto_algapi           6336  6
>> aes_x86_64,aes_generic,arc4,ecb,crypto_blkcipher,cryptomgr
>>
>> Perhaps I'll break ath9k if the kernel lets me compile without an ecb
>> module...
>
> Well, it didn't let me deselect ecb since that is selected by MAC80211
> (as is arc4).
>
> Anyhow, writing now to share the good news that the patch you refer to:
> [PATCH] ath9k: connectivity is lost after Group rekeying is done
> (Click on [Download message RAW] at
> http://marc.info/?l=linux-wireless&m=122163541519736&w=2 to get a clean
> copy) completely fixes the regression between -rc5 and -rc6 I reported
> in:
>
> [ath9k-devel] 2.6.27-rc6 (and forwartd to -rc6-git3) dies silently.
> https://lists.ath9k.org/pipermail/ath9k-devel/2008-September/000263.html
>
> Patching -rc6-git3 I've now run 4 hours without a connection drop.
> Strangely enough it also allowed me to again make the connection
> 'sticky' over a reboot (Wicd Manager).
>
> This patch is a must have for 2.6.27 no matter what merging policy is
> in effect.

John please consider merging this for 27 as well as it fixes issues
reported due to lost of connectivity.

  Luis

Re: [ath9k-devel] ath9k constantly drops network connection

[Luis R. Rodriguez]

On Thu, Sep 18, 2008 at 1:36 AM, Mats Johannesson <spamcan1@abrasax.se> wrote:
> On Thu, 18 Sep 2008 04:46:18 +0200 Mats Johannesson wrote:
>> On Wed, 17 Sep 2008 12:10:03 -0700 Luis R. Rodriguez wrote:
>> > On Wed, Sep 17, 2008 at 03:05:59AM -0700, Partha Bagchi wrote:
>> [...]
>> > > 03:42:27 EDT 2008 i686 i686 i386 GNU/Linux
>> >
>> > Please try appling the patch titled:
>> >
>> > "[PATCH] ath9k: connectivity is lost after Group rekeying is done"
>> >
>> > which was posted on linux-wireless. If that fixes your issue I can
>>
>> A question Luis. Looking at the code (and not knowing _anything_ about
>> wireless internals):
>>
>> -             if (sc->sc_keytype == ATH9K_CIPHER_WEP)
>> +             if (tx_info->control.hw_key->alg == ALG_WEP)
>>                       txctl->keytype = ATH9K_KEY_TYPE_WEP;
>> -             else if (sc->sc_keytype == ATH9K_CIPHER_TKIP)
>> +             else if (tx_info->control.hw_key->alg == ALG_TKIP)
>>                       txctl->keytype = ATH9K_KEY_TYPE_TKIP;
>> -             else if (sc->sc_keytype == ATH9K_CIPHER_AES_CCM)
>> +             else if (tx_info->control.hw_key->alg == ALG_CCMP)
>>                       txctl->keytype = ATH9K_KEY_TYPE_AES;
>>
>> I'm confused regarding the AES cypher. My AP is set through its
>> interface as:
>>
>> Security Mode: WPA-Personal
>> WPA Mode: WPA2 Only
>> Cipher Type: AES
>> Group Key Update Interval: 2461 seconds (~41 minutes)
>> Pre-Shared Key: Loooong long key.
>>
>> But the output from "iwlist scan" tells another story:
>>
>>                     Encryption key:on
>>                     IE: IEEE 802.11i/WPA2 Version 1
>>                         Group Cipher : TKIP
>>                         Pairwise Ciphers (1) : TKIP
>>                         Authentication Suites (1) : PSK
>>
>> So someones lying... Does this effect ath9k?
>>
>> I'll compile another kernel and try to get rid of TKIP stuff
>> completely to test this out. At the moment the environment looks like
>> this:
>>
>> grep -i tkip my-.config
>> grep -i michael my-.config
>> # CONFIG_CRYPTO_MICHAEL_MIC is not set
>> grep -i ecb my-.config
>> CONFIG_CRYPTO_ECB=m
>> grep -i aes my-.config
>> CONFIG_CRYPTO_AES=m
>> CONFIG_CRYPTO_AES_X86_64=m
>>
>> loke@sleipner:~$ lsmod|grep -i ecb
>> ecb                     1344  2
>> crypto_blkcipher        8964  1 ecb
>> crypto_algapi           6336  6
>> aes_x86_64,aes_generic,arc4,ecb,crypto_blkcipher,cryptomgr
>>
>> loke@sleipner:~$ lsmod|grep -i aes
>> aes_x86_64              6784  3
>> aes_generic            25576  1 aes_x86_64
>> crypto_algapi           6336  6
>> aes_x86_64,aes_generic,arc4,ecb,crypto_blkcipher,cryptomgr
>>
>> Perhaps I'll break ath9k if the kernel lets me compile without an ecb
>> module...
>
> Well, it didn't let me deselect ecb since that is selected by MAC80211
> (as is arc4).
>
> Anyhow, writing now to share the good news that the patch you refer to:
> [PATCH] ath9k: connectivity is lost after Group rekeying is done
> (Click on [Download message RAW] at
> http://marc.info/?l=linux-wireless&m=122163541519736&w=2 to get a clean
> copy) completely fixes the regression between -rc5 and -rc6 I reported
> in:
>
> [ath9k-devel] 2.6.27-rc6 (and forwartd to -rc6-git3) dies silently.
> https://lists.ath9k.org/pipermail/ath9k-devel/2008-September/000263.html
>
> Patching -rc6-git3 I've now run 4 hours without a connection drop.
> Strangely enough it also allowed me to again make the connection
> 'sticky' over a reboot (Wicd Manager).
>
> This patch is a must have for 2.6.27 no matter what merging policy is
> in effect.

John please consider merging this for 27 as well as it fixes issues
reported due to lost of connectivity.

  Luis

[ath9k-devel] ath9k constantly drops network connection

[Steven Noonan]

On Thu, Sep 18, 2008 at 1:46 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Thu, Sep 18, 2008 at 1:36 AM, Mats Johannesson <spamcan1@abrasax.se> wrote:
>> Anyhow, writing now to share the good news that the patch you refer to:
>> [PATCH] ath9k: connectivity is lost after Group rekeying is done
>> (Click on [Download message RAW] at
>> http://marc.info/?l=linux-wireless&m=122163541519736&w=2 to get a clean
>> copy) completely fixes the regression between -rc5 and -rc6 I reported
>> in:
>>
>> [ath9k-devel] 2.6.27-rc6 (and forwartd to -rc6-git3) dies silently.
>> https://lists.ath9k.org/pipermail/ath9k-devel/2008-September/000263.html
>>
>> Patching -rc6-git3 I've now run 4 hours without a connection drop.
>> Strangely enough it also allowed me to again make the connection
>> 'sticky' over a reboot (Wicd Manager).
>>
>> This patch is a must have for 2.6.27 no matter what merging policy is
>> in effect.
>
> John please consider merging this for 27 as well as it fixes issues
> reported due to lost of connectivity.
>
>  Luis

Dang! I just developed a pretty much identical patch locally to solve
my wireless connection loss issues and was about 20 minutes into a 5
hour test to make certain it worked correctly. I wish I'd been faster
at getting mine tested and out the door. Oh well, at least -somebody-
got a fix up.

Indeed, please merge this to 2.6.27 ASAP. Having a problem like this
hit the 2.6.27 final release would -really- suck.

- Steven

Re: [ath9k-devel] ath9k constantly drops network connection

[Steven Noonan]

On Thu, Sep 18, 2008 at 1:46 AM, Luis R. Rodriguez
<lrodriguez@atheros.com> wrote:
> On Thu, Sep 18, 2008 at 1:36 AM, Mats Johannesson <spamcan1@abrasax.se> wrote:
>> Anyhow, writing now to share the good news that the patch you refer to:
>> [PATCH] ath9k: connectivity is lost after Group rekeying is done
>> (Click on [Download message RAW] at
>> http://marc.info/?l=linux-wireless&m=122163541519736&w=2 to get a clean
>> copy) completely fixes the regression between -rc5 and -rc6 I reported
>> in:
>>
>> [ath9k-devel] 2.6.27-rc6 (and forwartd to -rc6-git3) dies silently.
>> https://lists.ath9k.org/pipermail/ath9k-devel/2008-September/000263.html
>>
>> Patching -rc6-git3 I've now run 4 hours without a connection drop.
>> Strangely enough it also allowed me to again make the connection
>> 'sticky' over a reboot (Wicd Manager).
>>
>> This patch is a must have for 2.6.27 no matter what merging policy is
>> in effect.
>
> John please consider merging this for 27 as well as it fixes issues
> reported due to lost of connectivity.
>
>  Luis

Dang! I just developed a pretty much identical patch locally to solve
my wireless connection loss issues and was about 20 minutes into a 5
hour test to make certain it worked correctly. I wish I'd been faster
at getting mine tested and out the door. Oh well, at least -somebody-
got a fix up.

Indeed, please merge this to 2.6.27 ASAP. Having a problem like this
hit the 2.6.27 final release would -really- suck.

- Steven