Re: ath5k: problems during the connection to a sitecom AP

Re: ath5k: problems during the connection to a sitecom AP

[rossi.f]

>> When I do a scan after having loaded the driver, the iwlist
>> can't report 
the SSID because it's hidden. I don't know if
>> this is a problem but I have 
noticed that the reported SSIDs
>> of the two APs are a little bit different. 
With the 3com AP
>> (the working one) I get ESSID:" " (1 char blank string) 
while
>> with the Sitecom AP ESSID:"" (0 chars empty string).
>
>Okay, that 
could very well be the problem.
>
>Side node: it doesn't buy you anything to 
"hide" the SSID of an 
>AP. Actually, you can't really hide. The hidden bit 
only makes 
>the AP lie about the SSID in it's beacons, but for other 802.11 

>WLAN protocol messages (like Association Request, Assoc Resp) 
>the SSID has 
to be send in cleartext anyway.
>
>So turn of this stupid thingy. This also 
makes your roaming 
>slightly faster and use slightly less battery (because 
the 
>client doesn't need to probe the AP if it has the right, 
>expected, 
SSID. The client knows in an instant that this is the 
>case).

Yes, I know 
that the hidden SSID technique doesn't have to be used for
security purposes. I 
might activate the transmission of the SSID on
my AP but this doesn't solve the 
problem in the mac80211 framework
regarding the empty SSIDs (if this is really 
the bug).

The problem is that the ieee80211_direct_probe() function is
never 
called during the associating request via iwconfig.

Regards,
Fabio

ath5k: problems during the connection to a sitecom AP

[Fabio Rossi]

I'm testing the ath5k driver (wireless-testing v2.6.28-rc4-5172-gc1a847c) with 
my 3com 3CRDAG675 PCI card (atheros AR5212). I can try alternatively two 
different access points (both configured with WEP + hidden SSID), the 
procedure I use is the same but the results are different.

Here are the commands used:

modprobe ath5k
ifconfig ath0 192.168.1.2 up
iwconfig ath0 key <MYKEY>
iwconfig ath0 ap <AP_MAC>
iwconfig ath0 essid <MY_ESSID>


*** 3com AP ***
With this one I can associate without problems at the first try (SSID not 
broadcast + WEP encryption):

ath5k_pci 0000:00:0b.0: PCI INT A -> Link[LNKB] -> GSI 10 (level, low) -> IRQ 
10
ath5k_pci 0000:00:0b.0: registered as 'phy1'
phy1: Selected rate control algorithm 'minstrel'
ath5k phy1: Atheros AR5212 chip found (MAC: 0x56, PHY: 0x41)
ath5k phy1: RF5112B multiband radio found (0x36)
udev: renamed network interface wlan0 to ath0
ath0: direct probe to AP <AP_MAC> try 1
ath0 direct probe responded
ath0: authenticate with AP <AP_MAC>
ath0: authenticated
ath0: associate with AP <AP_MAC>
ath0: RX AssocResp from <AP_MAC> (capab=0x421 status=0 aid=4)
ath0: associated
phy1: Allocated STA <AP_MAC>
phy1: Inserted STA <AP_MAC>
ath0: switched to short barker preamble (BSSID=<AP_MAC>)
ath0: switched to short slot (BSSID=<AP_MAC>)

*** Sitecom AP ***
With this one I'm able to associate only when the SSID is broadcast (with or 
without encryption). Moreover the association process isn't successful at 
first try (like for the 3com AP) and the link quality is very bad. An example 
of ping statistics is the following

629 packets transmitted, 527 received, 16% packet loss, time 711605ms
rtt min/avg/max/mdev = 6.332/6303.120/151334.339/18133.729 ms, pipe 114

and it's common to get the following error message (transmission buffer 
saturated?):

ping: sendmsg: No buffer space available

When I disable the SSID I can't associate anymore to the AP, the only debug 
messages are the following:

ath5k_pci 0000:00:0b.0: PCI INT A -> Link[LNKB] -> GSI 10 (level, low) -> IRQ 
10
ath5k_pci 0000:00:0b.0: registered as 'phy12'
phy12: Selected rate control algorithm 'minstrel'
ath5k phy12: Atheros AR5212 chip found (MAC: 0x56, PHY: 0x41)
ath5k phy12: RF5112B multiband radio found (0x36)
udev: renamed network interface wlan0 to ath0

How can I debug to provide more details (e.g. using debugfs)?

Thank you for any help,
Fabio

Re: ath5k: problems during the connection to a sitecom AP

[Fabio Rossi]

Which is the best way to proceed with the debug to understand why my 
card isn't going through the authentication-association process with the 
hidden SSID?

Thanks,
Fabio

On Saturday 15 November 2008, you wrote:

> I'm testing the ath5k driver (wireless-testing v2.6.28-rc4-5172-gc1a847c)
> with my 3com 3CRDAG675 PCI card (atheros AR5212). I can try alternatively
> two different access points (both configured with WEP + hidden SSID), the
> procedure I use is the same but the results are different.
>
> Here are the commands used:
>
> modprobe ath5k
> ifconfig ath0 192.168.1.2 up
> iwconfig ath0 key <MYKEY>
> iwconfig ath0 ap <AP_MAC>
> iwconfig ath0 essid <MY_ESSID>
>
>
> *** 3com AP ***
> With this one I can associate without problems at the first try (SSID not
> broadcast + WEP encryption):
>
> ath5k_pci 0000:00:0b.0: PCI INT A -> Link[LNKB] -> GSI 10 (level, low) ->
> IRQ 10
> ath5k_pci 0000:00:0b.0: registered as 'phy1'
> phy1: Selected rate control algorithm 'minstrel'
> ath5k phy1: Atheros AR5212 chip found (MAC: 0x56, PHY: 0x41)
> ath5k phy1: RF5112B multiband radio found (0x36)
> udev: renamed network interface wlan0 to ath0
> ath0: direct probe to AP <AP_MAC> try 1
> ath0 direct probe responded
> ath0: authenticate with AP <AP_MAC>
> ath0: authenticated
> ath0: associate with AP <AP_MAC>
> ath0: RX AssocResp from <AP_MAC> (capab=0x421 status=0 aid=4)
> ath0: associated
> phy1: Allocated STA <AP_MAC>
> phy1: Inserted STA <AP_MAC>
> ath0: switched to short barker preamble (BSSID=<AP_MAC>)
> ath0: switched to short slot (BSSID=<AP_MAC>)
>
> *** Sitecom AP ***
> With this one I'm able to associate only when the SSID is broadcast (with
> or without encryption). Moreover the association process isn't successful
> at first try (like for the 3com AP) and the link quality is very bad. An
> example of ping statistics is the following
>
> 629 packets transmitted, 527 received, 16% packet loss, time 711605ms
> rtt min/avg/max/mdev = 6.332/6303.120/151334.339/18133.729 ms, pipe 114
>
> and it's common to get the following error message (transmission buffer
> saturated?):
>
> ping: sendmsg: No buffer space available
>
> When I disable the SSID I can't associate anymore to the AP, the only debug
> messages are the following:
>
> ath5k_pci 0000:00:0b.0: PCI INT A -> Link[LNKB] -> GSI 10 (level, low) ->
> IRQ 10
> ath5k_pci 0000:00:0b.0: registered as 'phy12'
> phy12: Selected rate control algorithm 'minstrel'
> ath5k phy12: Atheros AR5212 chip found (MAC: 0x56, PHY: 0x41)
> ath5k phy12: RF5112B multiband radio found (0x36)
> udev: renamed network interface wlan0 to ath0
>
> How can I debug to provide more details (e.g. using debugfs)?
>
> Thank you for any help,
> Fabio
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: ath5k: problems during the connection to a sitecom AP

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

On Mon, 2008-11-17 at 21:20 +0100, Fabio Rossi wrote:
> Which is the best way to proceed with the debug to understand why my 
> card isn't going through the authentication-association process with the 
> hidden SSID?

get a second wireless card and look at what's happening.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ath5k: problems during the connection to a sitecom AP

[Fabio Rossi]

On Monday 17 November 2008, Johannes Berg wrote:

> On Mon, 2008-11-17 at 21:20 +0100, Fabio Rossi wrote:
> > Which is the best way to proceed with the debug to understand why my
> > card isn't going through the authentication-association process with the
> > hidden SSID?
>
> get a second wireless card and look at what's happening.
>
> johannes

I have 2 PCMCIA cards but none work correctly up to now :-( I have to test 
them with mac80211...

Which is the best tool to use, kismet or aircrack-ng? I have never used this 
kind of program.

Regards,
Fabio

Re: ath5k: problems during the connection to a sitecom AP

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 213 bytes --]

On Wed, 2008-11-19 at 22:00 +0100, Fabio Rossi wrote:

> Which is the best tool to use, kismet or aircrack-ng? I have never used this 
> kind of program.

just tcpdump/wireshark is probably best

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: ath5k: problems during the connection to a sitecom AP

[Bob Copeland]

On Mon, Nov 17, 2008 at 3:20 PM, Fabio Rossi <rossi.f@inwind.it> wrote:
> Which is the best way to proceed with the debug to understand why my
> card isn't going through the authentication-association process with the
> hidden SSID?

You can get a dump of most of the traffic on the wireless medium for ath5k by
using the debugfs files (echo -n "all" > /debug/ath5k/phy0/debug).  It might
miss some packets, get garbled, and chew up a lot of disk in a short period of
time, but it's an alternative to using a second card.  You can log more or
less stuff by using different options, cat the file for a list.

-- 
Bob Copeland %% www.bobcopeland.com

Re: ath5k: problems during the connection to a sitecom AP

[Fabio Rossi]

[-- Attachment #1: Type: text/plain, Size: 1105 bytes --]

On Tuesday 18 November 2008, Bob Copeland wrote:

> On Mon, Nov 17, 2008 at 3:20 PM, Fabio Rossi <rossi.f@inwind.it> wrote:
> > Which is the best way to proceed with the debug to understand why my
> > card isn't going through the authentication-association process with the
> > hidden SSID?
>
> You can get a dump of most of the traffic on the wireless medium for ath5k
> by using the debugfs files (echo -n "all" > /debug/ath5k/phy0/debug).  It
> might miss some packets, get garbled, and chew up a lot of disk in a short
> period of time, but it's an alternative to using a second card.  You can
> log more or less stuff by using different options, cat the file for a list.

Thank you Bob for the help. Sorry for the delay but I don't have access to the 
PC every day.

I've attached a kernel log of what's happening and a commands log with time 
references. I hope it's useful, tell me if you need other data.

As written previously the AP is configured with WEP (before going to WPA which 
depends on another external piece of software) and doesn't transmit the SSID. 
The channel is number 6.

Fabio

[-- Attachment #2: 20081119_cmd.log.gz --]
[-- Type: application/x-gzip, Size: 159 bytes --]

[-- Attachment #3: 20081119_kernel.log.bz2 --]
[-- Type: application/x-bzip2, Size: 16983 bytes --]

Re: ath5k: problems during the connection to a sitecom AP

[Bob Copeland]

On Wed, Nov 19, 2008 at 5:15 PM, Fabio Rossi <rossi.f@inwind.it> wrote:
> I've attached a kernel log of what's happening and a commands log with time
> references. I hope it's useful, tell me if you need other data.

Ok, well at least we know we see beacons from the AP in question.
Other than that, it doesn't help a whole lot, as all the log captured
was beacons from various APs.  Can you try again without the 'trace'
option?  Also if you turn on CONFIG_MAC80211_VERBOSE_DEBUG then we
can see the probe requests etc.

If you do have another wireless card, that would still be better.  You
can use it like this:

   # ifconfig wlan1 down
   # iwconfig wlan1 mode monitor
   # ifconfig wlan1 up
   # tcpdump -s 1000 -w assoc.cap -i wlan1

Then you can load assoc.cap into wireshark (you can capture from inside
wireshark too if you prefer).

-- 
Bob Copeland %% www.bobcopeland.com

Re: ath5k: problems during the connection to a sitecom AP

[Fabio Rossi]

On Friday 21 November 2008, Bob Copeland wrote:

> On Wed, Nov 19, 2008 at 5:15 PM, Fabio Rossi <rossi.f@inwind.it> wrote:
> > I've attached a kernel log of what's happening and a commands log with
> > time references. I hope it's useful, tell me if you need other data.
>
> Ok, well at least we know we see beacons from the AP in question.
> Other than that, it doesn't help a whole lot, as all the log captured
> was beacons from various APs.  Can you try again without the 'trace'
> option?  Also if you turn on CONFIG_MAC80211_VERBOSE_DEBUG then we
> can see the probe requests etc.

CONFIG_MAC80211_VERBOSE_DEBUG was already set in the previous log (I 
used "echo -n "all" > /debug/ath5k/phy1/debug"). The problem is that there 
are no direct probe requests, the card doesn't transmit at all (there are no 
TX dumps).

I have compared the logs with the two access points (both are configured in 
the same way, no SSID broadcast, WEP and 802.11b&g mode). With the 3com AP at 
a certain point I see the following lines (with TX and RX dumps not reported 
here):

kernel: ath0: direct probe to AP 00:0d:54:fb:55:33 try 1
kernel: ath0 direct probe responded
kernel: ath0: authenticate with AP 00:0d:54:fb:55:33
kernel: ath0: authenticated
kernel: ath0: associate with AP 00:0d:54:fb:55:33
kernel: ath0: RX AssocResp from 00:0d:54:fb:55:33 (capab=0x431 status=0 aid=5)
kernel: ath0: associated
kernel: phy14: Allocated STA 00:0d:54:fb:55:33
kernel: phy14: Inserted STA 00:0d:54:fb:55:33

while with the Sitecom AP I see nothing similar.

I have also tried a PCMCIA card which uses the rtl8180 driver. The result is 
the same, I can associate to the 3com AP but not to the Sitecom one.

I'm suspecting that it's not an ath5k driver issue but an higher level issue 
in the mac80211 framework.

When I do a scan after having loaded the driver, the iwlist can't report the 
SSID because it's hidden. I don't know if this is a problem but I have 
noticed that the reported SSIDs of the two APs are a little bit different. 
With the 3com AP (the working one) I get ESSID:" " (1 char blank 
string) while with the Sitecom AP ESSID:"" (0 chars empty string).

> If you do have another wireless card, that would still be better.  You
> can use it like this:
>
>    # ifconfig wlan1 down
>    # iwconfig wlan1 mode monitor
>    # ifconfig wlan1 up
>    # tcpdump -s 1000 -w assoc.cap -i wlan1
>
> Then you can load assoc.cap into wireshark (you can capture from inside
> wireshark too if you prefer).

Now I'm able to use a second additional PCMCIA wireless card in RFmon mode. 
The capturing confirms that there is no network traffic generated by the 
ath5k wireless card during the authentication & association with the Sitecom 
AP (no packets with the source MAC address of the wireless card).

Regards,
Fabio

Re: ath5k: problems during the connection to a sitecom AP

[Holger Schurig]

> When I do a scan after having loaded the driver, the iwlist
> can't report the SSID because it's hidden. I don't know if
> this is a problem but I have noticed that the reported SSIDs
> of the two APs are a little bit different. With the 3com AP
> (the working one) I get ESSID:" " (1 char blank string) while
> with the Sitecom AP ESSID:"" (0 chars empty string).

Okay, that could very well be the problem.


Side node: it doesn't buy you anything to "hide" the SSID of an 
AP. Actually, you can't really hide. The hidden bit only makes 
the AP lie about the SSID in it's beacons, but for other 802.11 
WLAN protocol messages (like Association Request, Assoc Resp) 
the SSID has to be send in cleartext anyway.

So turn of this stupid thingy. This also makes your roaming 
slightly faster and use slightly less battery (because the 
client doesn't need to probe the AP if it has the right, 
expected, SSID. The client knows in an instant that this is the 
case).

Re: ath5k: problems during the connection to a sitecom AP

[Fabio Rossi]

On Monday 24 November 2008, Holger Schurig wrote:

> > When I do a scan after having loaded the driver, the iwlist
> > can't report the SSID because it's hidden. I don't know if
> > this is a problem but I have noticed that the reported SSIDs
> > of the two APs are a little bit different. With the 3com AP
> > (the working one) I get ESSID:" " (1 char blank string) while
> > with the Sitecom AP ESSID:"" (0 chars empty string).
>
> Okay, that could very well be the problem.

Ok, I think I have found because the association request doesn't take place. 
In mlme.c there is the function ieee80211_sta_match_ssid(). My AP is 
broadcasting a fake SSID string '\0' with length 0. The function returns 0 
instead of 1.

I don't understand the meaning of the following code:

    hidden_ssid = 1;
    tmp = ssid_len;
    while (tmp--) {
        if (ssid[tmp] != '\0') {
            hidden_ssid = 0;
            break;
        }
    }

    if (hidden_ssid && ifsta->ssid_len == ssid_len)
        return 1;

    if (ssid_len == 1 && ssid[0] == ' ')
        return 1;

Of course hidden_ssid stays 1: why do I have to verify that the two lengths 
are equal? Conversely hidden_ssid goes 0 also when it's really hidden (e.g.
SSID ' ').

The code treats the strings ' ' as a jolly (independently of hidden_sid), why 
isn't the same for the empty string ''?

I have applied the following patch, now I'm able to associate.

--- mlme.c.orig 2008-11-25 00:39:00.000000000 +0100
+++ mlme.c      2008-11-25 00:40:03.000000000 +0100
@@ -2029,6 +2029,9 @@ static int ieee80211_sta_match_ssid(stru
        if (ssid_len == 1 && ssid[0] == ' ')
                return 1;

+       if (ssid_len == 0 && ssid[0] == '\0')
+               return 1;
+
        return 0;
 }

Regards,
Fabio

Re: ath5k: problems during the connection to a sitecom AP

[Holger Schurig]

On Friday 21 November 2008 21:22:41 Bob Copeland wrote:
>    # tcpdump -s 1000 -w assoc.cap -i wlan1
>
> Then you can load assoc.cap into wireshark (you can capture
> from inside wireshark too if you prefer).

Or dump tcpdump completely, because you can make a dump from the 
commandline with text-based wireshark "tshark":

tshark -s 1000 -i wlan1 -w assoc.cap


(However, I usually omit the -s 1000 when using tshark)