Hi everyone,
I do have an... interesting... problem with my HTPC, an Intel Atom 230 +
Nvidia ION powered Acer Aspire Revo box.
By default it ships with an Atheros Mini PCI Express card. However,
since my experience with this card isn't the best (and it did not
connect to my access point with wither the Madwifi-NG or the ath9k
driver) I replaced it with an Intel WiFi Link 5100.
However, even with the new card, I could not make any kernel from 2.6.32
to 2.6.34 connect to any of my access points. Those are a Telekom DSL
router and a Juniper NetScreen 5GT Wireless. I tried WEP64, WPA, WPA2,
and even no encryption at all. My laptop with an Intel WiFi Link 5300
has no problems whatsoever in any of the modes.
The card is working for sure, if I put the 5100 in my laptop it works.
Also I feel it's not related to configuration or software - I took my
laptop's WiFi Link 5300 and the laptop HDD, and booted the HTPC up with
those - no connection to the AP possible.
I'm a bit at a loss here as what to try more. My access point doesn't
even see a packet, but there's no rfkill switch anywhere (it's a
stationary machine anyway).
Regards,
Christiam
On Fri, 2010-05-28 at 13:10 +0200, Christian P. Schmidt wrote:
> > Those values make no sense to me .. can you use "iw scan" and tell us
> > the dBm value?
>
> This translates to -52 to -30dBm.
Ok that sounds like you have antennas.
> Well, maybe you can answer me a question I never dared to ask because I
> felt stupid... I can't take the Intel card online with only ifconfig or
> ip? I always get "unknown error 132" on ifconfig wlan0 up / ip link set
> wlan0 up...
Huh. This means that the device detected rfkill. But you previously
posted logs that showed it trying to associate, which cannot happen. And
you can't even scan when you can't bring the device up??
Maybe try the rfkill tool:
http://wireless.kernel.org/en/users/Documentation/rfkill
johannes
On 05/24/2010 09:34 PM, reinette chatre wrote:
> On Sat, 2010-05-22 at 01:29 -0700, Christian P. Schmidt wrote:
>> However, even with the new card, I could not make any kernel from 2.6.32
>> to 2.6.34 connect to any of my access points. Those are a Telekom DSL
>> router and a Juniper NetScreen 5GT Wireless. I tried WEP64, WPA, WPA2,
>> and even no encryption at all. My laptop with an Intel WiFi Link 5300
>> has no problems whatsoever in any of the modes.
>
> Could you please post some logs captured during your association
> attempts? Were there any errors in your logs? In addition to this,
> having mac80211 verbose debugging enabled will help and also
> wpa_supplicant logs. That will give us a place to start.
>
> Reinette
>
wpa_supplicant isn't particularly verbose:
Selected interface 'wlan0'
Interactive mode
> scan_r
bssid / frequency / signal level / flags / ssid
00:10:db:a1:69:21 2447 223
[WPA2-PSK-TKIP+CCMP-preauth][ESS] digadd
00:10:db:a1:69:20 2447 214 [ESS] test
<2>Authentication with 00:10:db:a1:69:21 timed out.
> <2>CTRL-EVENT-SCAN-RESULTS
> <2>Trying to associate with 00:10:db:a1:69:20 (SSID='test' freq=2447 MHz)
<2>Authentication with 00:10:db:a1:69:20 timed out.
<2>CTRL-EVENT-SCAN-RESULTS
> <2>Trying to associate with 00:10:db:a1:69:20 (SSID='test' freq=2447 MHz)
<2>Authentication with 00:10:db:a1:69:20 timed out.
<2>CTRL-EVENT-SCAN-RESULTS
> <2>Trying to associate with 00:10:db:a1:69:21 (SSID='digadd' freq=2447
MHz)
<2>Authentication with 00:10:db:a1:69:21 timed out.
> <2>CTRL-EVENT-SCAN-RESULTS
> <2>Trying to associate with 00:10:db:a1:69:21 (SSID='digadd' freq=2447
MHz)
<2>Authentication with 00:10:db:a1:69:21 timed out.
dmesg with verbose mac80211:
[66188.364996] iwlagn: Intel(R) Wireless WiFi Link AGN driver for Linux,
in-tree:d
[66188.365474] iwlagn: Copyright(c) 2003-2010 Intel Corporation
[66188.365839] iwlagn 0000:05:00.0: PCI INT A -> Link[LN4A] -> GSI 19
(level, low) -> IRQ 19
[66188.365855] iwlagn 0000:05:00.0: setting latency timer to 64
[66188.365909] iwlagn 0000:05:00.0: Detected Intel Wireless WiFi Link
5100AGN REV=0x54
[66188.386206] iwlagn 0000:05:00.0: Tunable channels: 13 802.11bg, 24
802.11a channels
[66188.387527] iwlagn 0000:05:00.0: firmware: requesting
iwlwifi-5000-2.ucode
[66188.449118] iwlagn 0000:05:00.0: loaded firmware version 8.24.2.12
[66188.450753] phy1: Selected rate control algorithm 'iwl-agn-rs'
[66198.724027] phy1: device now idle
[66198.725051] ADDRCONF(NETDEV_UP): wlan0: link is not ready
[66199.028356] phy1: device no longer idle - scanning
[66202.396651] phy1: device now idle
[66202.398713] phy1: device no longer idle - working
[66202.398733] wlan0: direct probe to 00:10:db:a1:69:21 (try 1)
[66202.598036] wlan0: direct probe to 00:10:db:a1:69:21 (try 2)
[66202.798041] wlan0: direct probe to 00:10:db:a1:69:21 (try 3)
[66202.998031] wlan0: direct probe to 00:10:db:a1:69:21 timed out
[66203.001034] phy1: device now idle
[66212.399658] phy1: device no longer idle - scanning
[66215.779131] phy1: device now idle
[66215.779591] phy1: device no longer idle - working
[66215.779607] wlan0: direct probe to 00:10:db:a1:69:21 (try 1)
[66215.979026] wlan0: direct probe to 00:10:db:a1:69:21 (try 2)
[66216.179027] wlan0: direct probe to 00:10:db:a1:69:21 (try 3)
[66216.379030] wlan0: direct probe to 00:10:db:a1:69:21 timed out
[66216.382034] phy1: device now idle
[66225.784782] phy1: device no longer idle - scanning
[66229.164447] phy1: device now idle
[66229.164848] phy1: device no longer idle - working
[66229.164864] wlan0: direct probe to 00:10:db:a1:69:20 (try 1)
[66229.364034] wlan0: direct probe to 00:10:db:a1:69:20 (try 2)
[66229.564030] wlan0: direct probe to 00:10:db:a1:69:20 (try 3)
[66229.764027] wlan0: direct probe to 00:10:db:a1:69:20 timed out
[66229.767035] phy1: device now idle
[66239.165261] phy1: device no longer idle - scanning
[66242.537751] phy1: device now idle
[66242.538524] phy1: device no longer idle - working
[66242.538545] wlan0: direct probe to 00:10:db:a1:69:20 (try 1)
[66242.738028] wlan0: direct probe to 00:10:db:a1:69:20 (try 2)
[66242.938033] wlan0: direct probe to 00:10:db:a1:69:20 (try 3)
[66243.138029] wlan0: direct probe to 00:10:db:a1:69:20 timed out
[66243.142031] phy1: device now idle
I kind of feel that no packets are sent, since I can't see them on the
firewall, even with packet dumps, not even association attempts.
Running tcpdump on the client doesn't show anything either, but I'm not
sure whether it would normally capture association attempts.
Regards,
Christian
On 05/28/2010 12:41 PM, Johannes Berg wrote:
> On Fri, 2010-05-28 at 12:31 +0200, Christian P. Schmidt wrote:
>
>> After looking up the specs for the mini pci express port I'm gonna
>> disassemble the HTPC tonight and will figure out if that thing asserts
>> the RFKILL signal... even though there's no RFKILL switch.
>
> That isn't useful I think since the rfkill line would disable the
> hardware, which we'd know in software and never get this far. Maybe
> better check if the antennas are connected properly and are dual-band
> antennas if you use 5ghz? :)
I was wondering about that part, admitted. The original card (ath9k) was
an AGN two-antenna dual-band as well, came vendor fitted - and had the
same issue. I was considering trying different antennas, admittedly, but
I have none at hand.
I see a bunch of WLANs with levels between 180 and 225. I'll compare the
values to disconnected antennas while disassembling.
Regards,
Christian
On 05/28/2010 01:31 AM, reinette chatre wrote:
> Hi Christian,
>
> On Wed, 2010-05-26 at 06:14 -0700, Christian P. Schmidt wrote:
>> On 05/24/2010 09:34 PM, reinette chatre wrote:
>>> On Sat, 2010-05-22 at 01:29 -0700, Christian P. Schmidt wrote:
>>>> However, even with the new card, I could not make any kernel from 2.6.32
>>>> to 2.6.34 connect to any of my access points. Those are a Telekom DSL
>>>> router and a Juniper NetScreen 5GT Wireless. I tried WEP64, WPA, WPA2,
>>>> and even no encryption at all. My laptop with an Intel WiFi Link 5300
>>>> has no problems whatsoever in any of the modes.
>>>
>>> Could you please post some logs captured during your association
>>> attempts? Were there any errors in your logs? In addition to this,
>>> having mac80211 verbose debugging enabled will help and also
>>> wpa_supplicant logs. That will give us a place to start.
>>>
>>> Reinette
>>>
>>
>> wpa_supplicant isn't particularly verbose:
>
> It does become verbose when you enable debugging. Next time you need to
> do this then you can try the "-dddt" option. Not right now though since
> we can focus on the driver and mac80211 logs for now.
>
>> [66242.538545] wlan0: direct probe to 00:10:db:a1:69:20 (try 1)
>> [66242.738028] wlan0: direct probe to 00:10:db:a1:69:20 (try 2)
>> [66242.938033] wlan0: direct probe to 00:10:db:a1:69:20 (try 3)
>> [66243.138029] wlan0: direct probe to 00:10:db:a1:69:20 timed out
>> [66243.142031] phy1: device now idle
>>
>> I kind of feel that no packets are sent, since I can't see them on the
>> firewall, even with packet dumps, not even association attempts.
>
> We can look into this more by enabling TX debugging and general
> debugging. Could you please reload driver with "modprobe iwlagn
> debug=0x40843fff" and rerun your test?
I've attached two files, first the card init, second a full association
attempt to both access points (encrypted & open).
After looking up the specs for the mini pci express port I'm gonna
disassemble the HTPC tonight and will figure out if that thing asserts
the RFKILL signal... even though there's no RFKILL switch.
Regards,
Christian
On 05/28/2010 12:54 PM, Johannes Berg wrote:
> On Fri, 2010-05-28 at 12:49 +0200, Christian P. Schmidt wrote:
>
>> I see a bunch of WLANs with levels between 180 and 225. I'll compare the
>> values to disconnected antennas while disassembling.
>
> Those values make no sense to me .. can you use "iw scan" and tell us
> the dBm value?
This translates to -52 to -30dBm.
Well, maybe you can answer me a question I never dared to ask because I
felt stupid... I can't take the Intel card online with only ifconfig or
ip? I always get "unknown error 132" on ifconfig wlan0 up / ip link set
wlan0 up...
Regards,
Christian
On Fri, 2010-05-28 at 12:49 +0200, Christian P. Schmidt wrote:
> I see a bunch of WLANs with levels between 180 and 225. I'll compare the
> values to disconnected antennas while disassembling.
Those values make no sense to me .. can you use "iw scan" and tell us
the dBm value?
johannes
On 05/28/2010 01:24 PM, Johannes Berg wrote:
> On Fri, 2010-05-28 at 13:10 +0200, Christian P. Schmidt wrote:
>
> Ok that sounds like you have antennas.
Good :)
>> Well, maybe you can answer me a question I never dared to ask because I
>> felt stupid... I can't take the Intel card online with only ifconfig or
>> ip? I always get "unknown error 132" on ifconfig wlan0 up / ip link set
>> wlan0 up...
>
> Huh. This means that the device detected rfkill. But you previously
> posted logs that showed it trying to associate, which cannot happen. And
> you can't even scan when you can't bring the device up??
>
> Maybe try the rfkill tool:
> http://wireless.kernel.org/en/users/Documentation/rfkill
Ok, so something in gentoo's network init skripts unblocks the card when
you bring it online via the skript. When I don't use the skript it's
soft blocked, when running it's unblocked. I did not even have rfkill
installed at that point.
Good, that problem's gone, it's soft blocked when shut down and needs
rfkill unblock all prior to ifconfig up. Thanks for the heads up, but
that doesn't change the problem.
Regards,
Christian
Hi Christian,
On Wed, 2010-05-26 at 06:14 -0700, Christian P. Schmidt wrote:
> On 05/24/2010 09:34 PM, reinette chatre wrote:
> > On Sat, 2010-05-22 at 01:29 -0700, Christian P. Schmidt wrote:
> >> However, even with the new card, I could not make any kernel from 2.6.32
> >> to 2.6.34 connect to any of my access points. Those are a Telekom DSL
> >> router and a Juniper NetScreen 5GT Wireless. I tried WEP64, WPA, WPA2,
> >> and even no encryption at all. My laptop with an Intel WiFi Link 5300
> >> has no problems whatsoever in any of the modes.
> >
> > Could you please post some logs captured during your association
> > attempts? Were there any errors in your logs? In addition to this,
> > having mac80211 verbose debugging enabled will help and also
> > wpa_supplicant logs. That will give us a place to start.
> >
> > Reinette
> >
>
> wpa_supplicant isn't particularly verbose:
It does become verbose when you enable debugging. Next time you need to
do this then you can try the "-dddt" option. Not right now though since
we can focus on the driver and mac80211 logs for now.
> [66242.538545] wlan0: direct probe to 00:10:db:a1:69:20 (try 1)
> [66242.738028] wlan0: direct probe to 00:10:db:a1:69:20 (try 2)
> [66242.938033] wlan0: direct probe to 00:10:db:a1:69:20 (try 3)
> [66243.138029] wlan0: direct probe to 00:10:db:a1:69:20 timed out
> [66243.142031] phy1: device now idle
>
> I kind of feel that no packets are sent, since I can't see them on the
> firewall, even with packet dumps, not even association attempts.
We can look into this more by enabling TX debugging and general
debugging. Could you please reload driver with "modprobe iwlagn
debug=0x40843fff" and rerun your test?
Reinette
On Sat, 2010-05-22 at 01:29 -0700, Christian P. Schmidt wrote:
> However, even with the new card, I could not make any kernel from 2.6.32
> to 2.6.34 connect to any of my access points. Those are a Telekom DSL
> router and a Juniper NetScreen 5GT Wireless. I tried WEP64, WPA, WPA2,
> and even no encryption at all. My laptop with an Intel WiFi Link 5300
> has no problems whatsoever in any of the modes.
Could you please post some logs captured during your association
attempts? Were there any errors in your logs? In addition to this,
having mac80211 verbose debugging enabled will help and also
wpa_supplicant logs. That will give us a place to start.
Reinette
I'm having exactly the same problem with the same hardware
combination. If I can help to diagnose the problem in any way just
tell me what to do.
On Fri, 2010-05-28 at 12:31 +0200, Christian P. Schmidt wrote:
> >> I kind of feel that no packets are sent, since I can't see them on the
> >> firewall, even with packet dumps, not even association attempts.
> >
> > We can look into this more by enabling TX debugging and general
> > debugging. Could you please reload driver with "modprobe iwlagn
> > debug=0x40843fff" and rerun your test?
>
> I've attached two files, first the card init, second a full association
> attempt to both access points (encrypted & open).
I'll let Reinette analyse that.
> After looking up the specs for the mini pci express port I'm gonna
> disassemble the HTPC tonight and will figure out if that thing asserts
> the RFKILL signal... even though there's no RFKILL switch.
That isn't useful I think since the rfkill line would disable the
hardware, which we'd know in software and never get this far. Maybe
better check if the antennas are connected properly and are dual-band
antennas if you use 5ghz? :)
johannes
On Fri, 2010-06-04 at 09:40 -0700, reinette chatre wrote:
> On Thu, 2010-06-03 at 23:48 -0700, Johannes Berg wrote:
> > On Thu, 2010-06-03 at 17:56 +0200, Christian P. Schmidt wrote:
> >
> > > > Maybe try the rfkill tool:
> > > > http://wireless.kernel.org/en/users/Documentation/rfkill
> > >
> > > Yes, it was the rfkill tool that caused my attempts to fail. However,
> > > this didn't change my association attempt problems.
> > > I also took my time to look at the PCIe port - steady 3.3V on the RFKILL
> > > pin, which means "no RFKILL".
> > >
> > > Any further ideas?
> >
> > Unfortunately not. It would seem that something is causing your frames
> > not to be transmitted correctly, but I see no reason for that right now.
>
> The logs provided contains a lot of useful information. Among this is
> that the device is unable to transmit data with the firmware returning a
> "TX_LOCKED" status. From what I understand this is a regulatory check
> failure based on the channel type, which does not make sense in this
> regard since from what I can tell channel 8, which is an active channel,
> is used. I passed this question to our firmware folks and now waiting
> for an answer.
Unfortunately, since the firmware does not actually assert, the firmware
folks are unable to dig into this. I tried to take a second look at your
logs and one thing that I was able to see that is interesting is that,
when scanning, the device picks up very few frames that are good. I see
that there were five scans, none of which contained a since good frame
on 5GHz. On 2.4GHz there was a bit better success, but not consistent.
In the five scans there was the following on 2.4GHz:
1st scan: one good frame each on channels 5, 7, and 8.
2st scan: one good frame on channel 1
3st scan: one good frame each on channels 2, 7, and 9.
4st scan: one good frame each on channels 3, 5, 7, and 8.
5st scan: one good frame each on channels 1, 8, and 9.
If you want to check on this yourself, take a look at the lines:
[223263.179493] ieee80211 phy2: I iwl_rx_scan_results_notif Scan ch.res:
2 [802.11bg] (TSF: 0x00000000:05627B90) - 1 elapsed=33837 usec
The number before "elapsed" indicates the number of good frames seen
while scanning the channel. In the above example there was one.
This seems to indicate that there is some trouble on this platform ...
and makes me start thinking that this card may not work well on this
platform.
Some things you can try:
- are any APs on A band? If not, can you try to activate an AP on A band
to see if you have better success there?
- monitor the RX statistics ...
(/sys/kernel/debug/ieee80211/phy0/iwlagn/debug/ucode_rx_stats) to see if
there is an issue with crc checks and perhaps false alarms and plcp
also.
- something that you could try ... not sure how much it will help if you
are having noise issues ... is to vary how you scan. Since you know
which AP you are associating with, perhaps you can try to limit your
scan to that channel ... and also try passive instead of active. This
can be done with iw.
These are the only things I can think of.
Reinette
On 05/28/2010 01:24 PM, Johannes Berg wrote:
> On Fri, 2010-05-28 at 13:10 +0200, Christian P. Schmidt wrote:
>
>>> Those values make no sense to me .. can you use "iw scan" and tell us
>>> the dBm value?
>>
>> This translates to -52 to -30dBm.
>
> Ok that sounds like you have antennas.
Yes, I double checked it. Associations with my Linksys WRT54G running
OpenWRT times out as well, two laptops can successfully connect.
> Maybe try the rfkill tool:
> http://wireless.kernel.org/en/users/Documentation/rfkill
Yes, it was the rfkill tool that caused my attempts to fail. However,
this didn't change my association attempt problems.
I also took my time to look at the PCIe port - steady 3.3V on the RFKILL
pin, which means "no RFKILL".
Any further ideas?
Regards,
Christian
On Thu, 2010-06-03 at 23:48 -0700, Johannes Berg wrote:
> On Thu, 2010-06-03 at 17:56 +0200, Christian P. Schmidt wrote:
>
> > > Maybe try the rfkill tool:
> > > http://wireless.kernel.org/en/users/Documentation/rfkill
> >
> > Yes, it was the rfkill tool that caused my attempts to fail. However,
> > this didn't change my association attempt problems.
> > I also took my time to look at the PCIe port - steady 3.3V on the RFKILL
> > pin, which means "no RFKILL".
> >
> > Any further ideas?
>
> Unfortunately not. It would seem that something is causing your frames
> not to be transmitted correctly, but I see no reason for that right now.
The logs provided contains a lot of useful information. Among this is
that the device is unable to transmit data with the firmware returning a
"TX_LOCKED" status. From what I understand this is a regulatory check
failure based on the channel type, which does not make sense in this
regard since from what I can tell channel 8, which is an active channel,
is used. I passed this question to our firmware folks and now waiting
for an answer.
Reinette
On Thu, 2010-06-03 at 17:56 +0200, Christian P. Schmidt wrote:
> > Maybe try the rfkill tool:
> > http://wireless.kernel.org/en/users/Documentation/rfkill
>
> Yes, it was the rfkill tool that caused my attempts to fail. However,
> this didn't change my association attempt problems.
> I also took my time to look at the PCIe port - steady 3.3V on the RFKILL
> pin, which means "no RFKILL".
>
> Any further ideas?
Unfortunately not. It would seem that something is causing your frames
not to be transmitted correctly, but I see no reason for that right now.
johannes
On Fri, 2010-06-18 at 15:06 +0200, Carlos Balseiro wrote:
> Any news on this item?
You are very unlikely to get a useful answer if you post such questions.
If somebody dealt with your question, you would know it already. But if
the issue was fixed by somebody not familiar with your previous post,
that person would have no idea that the fix applies to your problem.
If you want a good answer, please put some effort into your question:
summarize the problem, provide links to previous posts, show what you
have tried.
--
Regards,
Pavel Roskin
> This seems to indicate that there is some trouble on this platform ...
> and makes me start thinking that this card may not work well on this
> platform.
Just installed Windows 7 on my machine to test this and efectively,
the problem also exist.