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
On Wed, Nov 19, 2008 at 5:15 PM, Fabio Rossi <[email protected]> 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 %% http://www.bobcopeland.com
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
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
> 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).
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
On Mon, Nov 17, 2008 at 3:20 PM, Fabio Rossi <[email protected]> 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 %% http://www.bobcopeland.com
On Tuesday 18 November 2008, Bob Copeland wrote:
> On Mon, Nov 17, 2008 at 3:20 PM, Fabio Rossi <[email protected]> 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
On Friday 21 November 2008, Bob Copeland wrote:
> On Wed, Nov 19, 2008 at 5:15 PM, Fabio Rossi <[email protected]> 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
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
>> 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
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)
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html