01:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01)
Subsystem: Foxconn International, Inc. Device e008
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at 55100000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [60] Express (v1) Legacy Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr+ FatalErr- UnsuppReq+ AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us
ClockPM- Surprise- LLActRep- BwNot-
LnkCtl: ASPM L1 Enabled; RCB 128 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Capabilities: [90] MSI-X: Enable- Count=1 Masked-
Vector table: BAR=0 offset=00000000
PBA: BAR=0 offset=00000000
Capabilities: [100] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq+ ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr+ BadTLP- BadDLLP- Rollover- Timeout+ NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
AERCap: First Error Pointer: 14, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140] Virtual Channel <?>
Kernel driver in use: ath5k
Kernel modules: ath5k
On Sun, Jan 24, 2010 at 6:04 PM, Don Darling <[email protected]> wrote:
> Hello folks,
>
> I recently tried upgrading to kernel version 2.6.32, but after this upgrade
> my wireless card became flaky when making connections. In cases where a
> connection can be established it is ?stable, but there are problems when
> making wireless associations. Downgrading to kernel version 2.6.31 resolves
> this issue. ?I'm not sure at the moment which versions of the ath5k driver
> maps to these kernel versions.
The (vanilla) kernel version is sufficient to know which driver it is.
> I'm assuming this issue is related to the ath5k driver itself -- the network
> I'm using is only WEP128, and doesn't need wpa_supplicant.
Huh, I didn't think any mac80211 driver supported WEP 128. Are you sure you
weren't using madwifi before? Or maybe WEP 104?
Are you using any modparams with ath5k?
> In fact, I have
> fewer problems when I connect to WPA+TKIP networks with wpa_supplicant.
This is somewhat more secure, so I'd recommend it, or better CCMP.
> Reverting to 2.6.31 resolves this issue. It will connect the first time, and
> I can disconnect/re-connect several times without issue.
I can't think of anything that changed in this time frame with ath5k
specifically
having to do with crypto. If you were using nohwcrypt=1, it could be a problem
with mac80211. Otherwise, bisecting might be the best route to pin it down.
Also on the off-chance that it's not crypto related, you may try the suggestions
in the following to get a better picture of whwat is going on:
http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
--
Bob Copeland %% http://www.bobcopeland.com
On 01/25/2010 11:39 AM, Bob Copeland wrote:
> On Sun, Jan 24, 2010 at 6:04 PM, Don Darling<[email protected]> wrote:
>> I'm assuming this issue is related to the ath5k driver itself -- the network
>> I'm using is only WEP128, and doesn't need wpa_supplicant.
>
> Huh, I didn't think any mac80211 driver supported WEP 128. Are you sure you
> weren't using madwifi before? Or maybe WEP 104?
For the record, WEP104 and WEP128 are the same thing. The smaller number makes
it explicit that the 24-bit IV is transmitted in the open. The same thing
applies to WEP40 and WEP64.
Larry
Hello folks,
Thanks for the suggestions -- here are a few questions I can answer from
earlier today:
1) I didn't realize there was a subtle difference between WEP104 and
WEP128. What I can tell you is that the WEP AP is running Tomato 1.23,
and is set to WEP 128-bit. However, the key I'm using is only 104
bits. This probably means I'm actually using WEP104.
2) I'm definitely not using madwifi in either case -- I've always used
the ath5k driver on this machine.
3) As far as I can tell, there are no modparams being used with ath5k.
I checked both /etc/modprobe.d and /etc/sysctl.conf (I'm not sure if the
latter affects modules or not, actually - I think it might depend on the
module).
4) I realize WPA+TKIP is more secure and I would use it if I could, but
I have some old devices that don't support WPA it so I'm limited to WEP.
5) I use -Dwext with wpa_supplicant when I *do* use WPA+TKIP networks.
Also, FWIW:
# lsmod | grep ath
ath5k 127364 0
mac80211 155788 1 ath5k
ath 7708 1 ath5k
cfg80211 90364 3 ath5k,mac80211,ath
led_class 4000 1 ath5k
I'm not sure when I might have a chance to bisect, but will certainly
let you know if I do.
Best regards,
Don
Bob Copeland wrote:
> 2010/1/25 G?bor Stefanik <[email protected]>:
>
>> On Mon, Jan 25, 2010 at 7:52 PM, Larry Finger <[email protected]> wrote:
>>
>>> For the record, WEP104 and WEP128 are the same thing. The smaller number
>>> makes it explicit that the 24-bit IV is transmitted in the open. The same
>>> thing applies to WEP40 and WEP64.
>>>
>>>
>> Only one problem there is another, nonstandard WEP type where the
>> actual key is 128-bit, and this is also sometimes referred to as
>> WEP128 (with the same metric as WEP64, this one would be WEP152). Same
>> goes for "WEP228/WEP256/WEP280".
>>
>
> Yea, I think ath hw supports that too:
>
> #define AR5K_KEYTABLE_TYPE_40 0x00000000
> #define AR5K_KEYTABLE_TYPE_104 0x00000001
> #define AR5K_KEYTABLE_TYPE_128 0x00000003
>
> at least that's what I assumed it meant. But there's no way to set it
> from mac80211 (nor should there be).
>
>
On Mon, Jan 25, 2010 at 7:52 PM, Larry Finger <[email protected]> wrote:
> On 01/25/2010 11:39 AM, Bob Copeland wrote:
>>
>> On Sun, Jan 24, 2010 at 6:04 PM, Don Darling<[email protected]>
>> ?wrote:
>>>
>>> I'm assuming this issue is related to the ath5k driver itself -- the
>>> network
>>> I'm using is only WEP128, and doesn't need wpa_supplicant.
>>
>> Huh, I didn't think any mac80211 driver supported WEP 128. ?Are you sure
>> you
>> weren't using madwifi before? ?Or maybe WEP 104?
>
> For the record, WEP104 and WEP128 are the same thing. The smaller number
> makes it explicit that the 24-bit IV is transmitted in the open. The same
> thing applies to WEP40 and WEP64.
>
> Larry
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
Only one problem there is another, nonstandard WEP type where the
actual key is 128-bit, and this is also sometimes referred to as
WEP128 (with the same metric as WEP64, this one would be WEP152). Same
goes for "WEP228/WEP256/WEP280".
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
On Mon, Jan 25, 2010 at 6:39 PM, Bob Copeland <[email protected]> wrote:
> On Sun, Jan 24, 2010 at 6:04 PM, Don Darling <[email protected]> wrote:
>> Hello folks,
>>
>> I recently tried upgrading to kernel version 2.6.32, but after this upgrade
>> my wireless card became flaky when making connections. In cases where a
>> connection can be established it is ?stable, but there are problems when
>> making wireless associations. Downgrading to kernel version 2.6.31 resolves
>> this issue. ?I'm not sure at the moment which versions of the ath5k driver
>> maps to these kernel versions.
>
> The (vanilla) kernel version is sufficient to know which driver it is.
>
>> I'm assuming this issue is related to the ath5k driver itself -- the network
>> I'm using is only WEP128, and doesn't need wpa_supplicant.
>
> Huh, I didn't think any mac80211 driver supported WEP 128. ?Are you sure you
> weren't using madwifi before? ?Or maybe WEP 104?
>
> Are you using any modparams with ath5k?
>
>> In fact, I have
>> fewer problems when I connect to WPA+TKIP networks with wpa_supplicant.
>
> This is somewhat more secure, so I'd recommend it, or better CCMP.
>
>> Reverting to 2.6.31 resolves this issue. It will connect the first time, and
>> I can disconnect/re-connect several times without issue.
>
> I can't think of anything that changed in this time frame with ath5k
> specifically
> having to do with crypto. ?If you were using nohwcrypt=1, it could be a problem
> with mac80211. ?Otherwise, bisecting might be the best route to pin it down.
One more important detail: wpa_supplicant can use both wext and
nl80211, while iwconfig and networkmanager are wext-only.
Don: do you use -d wext or -d nl80211 with wpa_supplicant?
>
> Also on the off-chance that it's not crypto related, you may try the suggestions
> in the following to get a better picture of whwat is going on:
>
> http://wireless.kernel.org/en/users/Documentation/Reporting_bugs
>
> --
> Bob Copeland %% http://www.bobcopeland.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
--
Vista: [V]iruses, [I]ntruders, [S]pyware, [T]rojans and [A]dware. :-)
2010/1/25 G?bor Stefanik <[email protected]>:
> On Mon, Jan 25, 2010 at 7:52 PM, Larry Finger <[email protected]> wrote:
>> For the record, WEP104 and WEP128 are the same thing. The smaller number
>> makes it explicit that the 24-bit IV is transmitted in the open. The same
>> thing applies to WEP40 and WEP64.
>>
>
> Only one problem there is another, nonstandard WEP type where the
> actual key is 128-bit, and this is also sometimes referred to as
> WEP128 (with the same metric as WEP64, this one would be WEP152). Same
> goes for "WEP228/WEP256/WEP280".
Yea, I think ath hw supports that too:
#define AR5K_KEYTABLE_TYPE_40 0x00000000
#define AR5K_KEYTABLE_TYPE_104 0x00000001
#define AR5K_KEYTABLE_TYPE_128 0x00000003
at least that's what I assumed it meant. But there's no way to set it
from mac80211 (nor should there be).
--
Bob Copeland %% http://www.bobcopeland.com
On Sun, Mar 21, 2010 at 4:49 PM, nanok <[email protected]> wrote:
>
> i can confirm don's issue. i have been using several revisions of 2.6.32
> (debian, not vanilla, it's true), i have resorted (back) to using
> ath-pci
> instead (i had been using it before because of the nifty functionality,
> but i
> switched to ath5k lately because of it being included in the kernel).
>
> reading don's report here, i tried using the 2.6.30 i already have, it
> seems
> to work fine
As you are using debian I have to ask: have you installed
crda? Since 2.6.30 ath5k gained regulatory support which
may cause certain channels to be disabled.
--
Bob Copeland %% http://www.bobcopeland.com
On Thu, Mar 25, 2010 at 5:02 PM, Bob Copeland <[email protected]> wrote:
> As you are using debian I have to ask: have you installed
> crda? ?Since 2.6.30 ath5k gained regulatory support which
> may cause certain channels to be disabled.
By "since 2.6.30" I meant post-2.6.30, sorry for any
confusion.
--
Bob Copeland %% http://www.bobcopeland.com
On Thu, Mar 25, 2010 at 6:24 PM, nanok <[email protected]> wrote:
> On Thu, Mar 25, 2010 at 05:04:02PM -0400, Bob Copeland wrote:
>> On Thu, Mar 25, 2010 at 5:02 PM, Bob Copeland <[email protected]> wrote:
>>
>> > As you are using debian I have to ask: have you installed
>> > crda? ?Since 2.6.30 ath5k gained regulatory support which
>> > may cause certain channels to be disabled.
>>
>> By "since 2.6.30" I meant post-2.6.30, sorry for any
>> confusion.
>>
>> --
>> Bob Copeland %% http://www.bobcopeland.com
>>
>
> hi Bob,
>
> no confusion, it's perfectly clear either way you state it.
> unfortunately, it's 2.6.3
> 0 that "works" (not pre-2.6.30), or did you mean since 2.6.30, excluding
> 2.6.30?
Right, that is what I tried to correct. _After_ 2.6.30,
ath5k began reporting the regdomain from the EEPROM which
means some channels (13 is a common case) are no longer
accessible whereas they were before with static reg domains
and no EEPROM support. That was the major change in the
driver. Most other changes since 2.6.30 were in the
upper-layers. I don't recall any changes to crypto in that
timeframe.
WRT to the original report, is only WEP causing problems
(i.e. does WPA work?)
--
Bob Copeland %% http://www.bobcopeland.com
On Thu, Mar 25, 2010 at 06:44:01PM -0400, Bob Copeland wrote:
> On Thu, Mar 25, 2010 at 6:24 PM, nanok <[email protected]> wrote:
> > On Thu, Mar 25, 2010 at 05:04:02PM -0400, Bob Copeland wrote:
> >> On Thu, Mar 25, 2010 at 5:02 PM, Bob Copeland <[email protected]> wrote:
> >>
> >> > As you are using debian I have to ask: have you installed
> >> > crda? ?Since 2.6.30 ath5k gained regulatory support which
> >> > may cause certain channels to be disabled.
> >>
> >> By "since 2.6.30" I meant post-2.6.30, sorry for any
> >> confusion.
> >>
> >> --
> >> Bob Copeland %% http://www.bobcopeland.com
> >>
> >
> > hi Bob,
> >
> > no confusion, it's perfectly clear either way you state it.
> > unfortunately, it's 2.6.3
> > 0 that "works" (not pre-2.6.30), or did you mean since 2.6.30, excluding
> > 2.6.30?
>
> Right, that is what I tried to correct. _After_ 2.6.30,
> ath5k began reporting the regdomain from the EEPROM which
> means some channels (13 is a common case) are no longer
> accessible whereas they were before with static reg domains
> and no EEPROM support. That was the major change in the
> driver. Most other changes since 2.6.30 were in the
> upper-layers. I don't recall any changes to crypto in that
> timeframe.
>
> WRT to the original report, is only WEP causing problems
> (i.e. does WPA work?)
>
> --
> Bob Copeland %% http://www.bobcopeland.com
>
wpa works with wpa_supplicant, i haven't tested in a while, but i can as
soon as i get home. plain also works (no encryption). iirc, the original
"plaintif" experienced the same.
to keep things accurate, i have experienced again a lock up (kernel
panick) while i was trying to get the wlan0 up (ath5k), and getting
errors, so now i have switched back to ath-pci (madwifi). there might be
something wrong with my hardware (additionally).
--
nanok
On Thu, Mar 25, 2010 at 7:04 PM, nanok <[email protected]> wrote:
> wpa works with wpa_supplicant, i haven't tested in a while, but i can as
> soon as i get home. plain also works (no encryption). iirc, the original
> "plaintif" experienced the same.
>
> to keep things accurate, i have experienced again a lock up (kernel
> panick) while i was trying to get the wlan0 up (ath5k), and getting
> errors, so now i have switched back to ath-pci
If you can manage to capture the panic, that would
be helpful, for example by switching to a console
beforehand and taking a picture with a digital camera.
(Still wishing for KMS to solve this problem...)
--
Bob Copeland %% http://www.bobcopeland.com
Don Darling <darling.don@...> writes:
>
> Hello folks,
>
> I recently tried upgrading to kernel version 2.6.32, but after this
> upgrade my wireless card became flaky when making connections. In cases
> where a connection can be established it is stable, but there are
> problems when making wireless associations. Downgrading to kernel
> version 2.6.31 resolves this issue. I'm not sure at the moment which
> versions of the ath5k driver maps to these kernel versions.
>
> Here is a brief description of my system:
hi,
i can confirm don's issue. i have been using several revisions of 2.6.32
(debian, not vanilla, it's true), i have resorted (back) to using
ath-pci
instead (i had been using it before because of the nifty functionality,
but i
switched to ath5k lately because of it being included in the kernel).
reading don's report here, i tried using the 2.6.30 i already have, it
seems
to work fine.
i can test pretty much whatever is needed, so feel free to ask.
here is the working ath5k details:
the laptop is a compaq nc6000,
the card:
lspci | grep -i ath
02:04.0 Ethernet controller: Atheros Communications Inc. Atheros
AR5001X+
Wireless Network Adapter (rev 01)
modinfo ath5k
filename:
/lib/modules/2.6.30-2-686/kernel/drivers/net/wireless/ath5k/ath5k.ko
version: 0.6.0 (EXPERIMENTAL)
license: Dual BSD/GPL
description: Support for 5xxx series of Atheros 802.11 wireless LAN
cards.
author: Nick Kossifidis
author: Jiri Slaby
srcversion: EE1D08AEEC0159304E1A703
modinfo mac80211
filename:
/lib/modules/2.6.30-2-686/kernel/net/mac80211/mac80211.ko
license: GPL
description: IEEE 802.11 subsystem
depends: cfg80211
vermagic: 2.6.30-2-686 SMP mod_unload modversions 686
parm: ieee80211_default_rc_a
modinfo cfg80211
filename:
/lib/modules/2.6.30-2-686/kernel/net/wireless/cfg80211.ko
description: wireless configuration support
license: GPL
author: Johannes Berg
depends:
vermagic: 2.6.30-2-686 SMP mod_unload modversions 686
parm: ieee80211_regdom:IEEE 802.11 regulatory domain code
(charp)
problematic ath5k:
filename:
/lib/modules/2.6.32-3-686/kernel/drivers/net/wireless/ath/ath5k/ath5k.ko
version: 0.6.0 (EXPERIMENTAL)
license: Dual BSD/GPL
description: Support for 5xxx series of Atheros 802.11 wireless LAN
cards.
author: Nick Kossifidis
author: Jiri Slaby
srcversion: DEA0BE918B6E0D0429CDF27
(same version, 0.6.0, but different src version).
hope this helps
ps: i am also having a seldom kernel panic issue, i cannot confirm if it
has
anything to do with ath5k, but it did happen once or twice when
inserting or
removing the module. i also had issues bringing the interface up after
inserting ath5k, i would get "error 132". again, no idea if any of this
is
related.
--
nanok
ps2: "You have lines longer than 80 characters. Fix that.". huh? why
doesn't the webform just enforce that instead? very annoying :(
On Thu, Mar 25, 2010 at 05:04:02PM -0400, Bob Copeland wrote:
> On Thu, Mar 25, 2010 at 5:02 PM, Bob Copeland <[email protected]> wrote:
>
> > As you are using debian I have to ask: have you installed
> > crda? ?Since 2.6.30 ath5k gained regulatory support which
> > may cause certain channels to be disabled.
>
> By "since 2.6.30" I meant post-2.6.30, sorry for any
> confusion.
>
> --
> Bob Copeland %% http://www.bobcopeland.com
>
hi Bob,
no confusion, it's perfectly clear either way you state it.
unfortunately, it's 2.6.3
0 that "works" (not pre-2.6.30), or did you mean since 2.6.30, excluding
2.6.30?
anyway, not sure why the crda would affect only wep operation, but
here's a snip of o
ne of my /var/log/messages, see if it helps (not sure i got where you
are aiming, so forgive me if this isn't what you need to know)
Mar 16 16:50:51 spartakus kernel: [14842.518127] cfg80211: Using static regulatory domain info
Mar 16 16:50:51 spartakus kernel: [14842.518130] cfg80211: Regulatory domain: US
Mar 16 16:50:51 spartakus kernel: [14842.518133] (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Mar 16 16:50:51 spartakus kernel: [14842.518137] (2402000 KHz - 2472000 KHz @ 40000 KHz), (600 mBi, 2700 mBm)
Mar 16 16:50:51 spartakus kernel: [14842.518141] (5170000 KHz - 5190000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
Mar 16 16:50:51 spartakus kernel: [14842.518145] (5190000 KHz - 5210000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
Mar 16 16:50:51 spartakus kernel: [14842.518148] (5210000 KHz - 5230000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
Mar 16 16:50:51 spartakus kernel: [14842.518152] (5230000 KHz - 5330000 KHz @ 40000 KHz), (600 mBi, 2300 mBm)
Mar 16 16:50:51 spartakus kernel: [14842.518156] (5735000 KHz - 5835000 KHz @ 40000 KHz), (600 mBi, 3000 mBm)
Mar 16 16:50:51 spartakus kernel: [14842.518395] cfg80211: Calling CRDA for country: US
Mar 16 16:50:51 spartakus kernel: [14842.551365] ath5k 0000:02:04.0: PCI INT A -> Link[C0C7] -> GSI 11 (level, low) -> IRQ 11
Mar 16 16:50:51 spartakus kernel: [14842.551412] ath5k 0000:02:04.0: registered as 'phy0'
Mar 16 16:50:51 spartakus kernel: [14842.798956] Registered led device: ath5k-phy0::rx
Mar 16 16:50:51 spartakus kernel: [14842.800364] Registered led device: ath5k-phy0::tx
Mar 16 16:50:51 spartakus kernel: [14842.800370] ath5k phy0: Atheros AR5212 chip found (MAC: 0x56, PHY: 0x41)
Mar 16 16:50:51 spartakus kernel: [14842.800373] ath5k phy0: RF5111 5GHz radio found (0x17)
Mar 16 16:50:51 spartakus kernel: [14842.800376] ath5k phy0: RF2111 2GHz radio found (0x23)
Mar 16 16:50:57 spartakus kernel: [14849.209305] ADDRCONF(NETDEV_UP): wlan0: link is not ready
Linux version 2.6.32-3-686 (Debian 2.6.32-9) (maks
@debian.org) (gcc version 4.3.4 (Debian 4.3.4-8) ) #1 SMP Thu Feb 25
06:14:20 UTC 2010
note: the above is not from a particular working/non working session, it
just illustrates (somehting to do with) crda. to obtain logs from a
particular scenario, i would need ot test specifically, to be sure what
happened when (however, as far as i remember, there's nothing
"interesting" in the logs when it won't work, in most cases it looks the
same)
--
nanok