I'd like to test the recent p54 AP mode patches against my XG-603
(ISL3886) MiniPCI card.
Tried that with the current wireless-testing.git, compiled ok, module
loads with 2.13.1.0.arm firmware.
I was under the impression that this should now work:
iwconfig wlan1 mode Master
however it errors with:
Error for wireless request "Set Mode" (8B06) : SET failed on
device wlan1 ; Invalid argument.
Being new to wireless, I'd please like a pointer on what to
investigate and which info to provide.
Thank you,
Stefan.
> The gap is filled by some "Null function" packets originating
> on the iPod (maybe it is getting impatient?). This gets me an
> application-level timeout.
Some comments about your "ipod_http_request_delayed_answer.pcap":
Clients use "null functions" to tell the AP that they're going to
sleep --- or that they are now waking up again. You can see this
in wireshark if you open "IEEE802.11", then "Frame Control:
xxxx", then "Flags". Look at the flag "PWR_MGT".
While sleeping, the AP should notify the client via a bitmask in
it's beacons that there is traffic for it. As your dump doesn't
include the beacons from the AP, we can't see if the proper bit
is set there.
At time 36.04 the Ipod WLAN card signals that it woke up and it
got then it's packet at time 36.70, which isn't awfully fast
after the wakeup, but ...
Just make a trace with beacons towards your mac80211 based AP and
one trace towards another access points and compare the beacon.
On Thu, 2008-11-20 at 15:37 +0100, Holger Schurig wrote:
> Just make a trace with beacons towards your mac80211 based AP and
> one trace towards another access points and compare the beacon.
No need to compare; you just need to check whether the AID bit is
properly set in the TIM. I think p54 may have problems with that, in
fact.
johannes
Now I'm learning something! Seems like Johannes' initial question
about powersaving might have been right on the mark, and Holger's
explanation set that straight in my brain. Thank you for that!
I have attached some traces. Connected my iPod to the XG-601 AP and to
my fritzbox 7170.
I'm not sure about the interpretation of the beacon flags, but I never
see beacon flags other than 0x0, does that mean the AP is saying "stay
awake, no sleeping" to the client?
The iPod alternates Null Functions with the PWR MGT bit on and off -
whatever that means. Is it ignoring the AP and snoring away?
@Johannes:
I was not able to find any indicated traffic in any of the beacon TIMs.
Thank you all for your valuable time with this,
Stefan.
2008/11/20 Holger Schurig <[email protected]>:
>> The gap is filled by some "Null function" packets originating
>> on the iPod (maybe it is getting impatient?). This gets me an
>> application-level timeout.
>
> Some comments about your "ipod_http_request_delayed_answer.pcap":
>
>
> Clients use "null functions" to tell the AP that they're going to
> sleep --- or that they are now waking up again. You can see this
> in wireshark if you open "IEEE802.11", then "Frame Control:
> xxxx", then "Flags". Look at the flag "PWR_MGT".
>
>
> While sleeping, the AP should notify the client via a bitmask in
> it's beacons that there is traffic for it. As your dump doesn't
> include the beacons from the AP, we can't see if the proper bit
> is set there.
>
> At time 36.04 the Ipod WLAN card signals that it woke up and it
> got then it's packet at time 36.70, which isn't awfully fast
> after the wakeup, but ...
>
>
> Just make a trace with beacons towards your mac80211 based AP and
> one trace towards another access points and compare the beacon.
>
On Fri, 2008-11-21 at 09:37 +0100, Stefan Steuerwald wrote:
> indeed I overlooked the AID bit in the relevant traffic sequences.
> Knowing now what to look for, I can follow what is going on and find
> it ok - except for the huge delay in between http request and reply.
> Typically, the http request is sent, the iPod goes to sleep, and
> several seconds pass (with numerous beacons without any AID bit set),
> before we see one or two "traffic for you" beacons, then the iPod
> wakes up and gets the reply. Most of the time my app already
> timeouted.
>
> I have checked that my app indeed completes its TCP reply in almost no
> time. Mysteriously, the data takes several seconds from boost::asio
> write completion until it appears on the air. That's the problem.
>
> I will go back to square one and the fact that I see different
> behaviour in the iPod and my other clients. I will work out the
> differences. Will be back in case I come up with more wireless
> questions.
Well, there could a buffering error in mac80211/p54 too. You could
enable verbose power save mode debugging (mac80211 debug kconfig,
normally not recommended to turn on); that will then print to the kernel
log whenever data for the station is being buffered and the AID bit will
be set. Since multiple seconds pass, you should be able to correlate
whether or not the AID bit is sent in the beacon right away after
mac80211 requests that, or not.
johannes
On Wed, 2008-11-19 at 16:37 +0100, Stefan Steuerwald wrote:
> > http://wireless.kernel.org/en/users/Documentation/modes#AccessPoint.28AP.29infrastructuremode
> > johannes
>
> Thank you, that's it, took the latest hostapd from git.
> I can now connect from my iPod to the XG-603 in AP mode (unencrypted
> and WPA/TKIP, WPA2/TKIP, WPA2/CCMP tested).
Cool
> However - data throughput seems low; accessing a webserver I get an
> update "now and then". I'm aware this can have a lots of causes - I
> have more time and more cards available (XG-601/ISL3880, and an
> AR5212/5213 one) and will play with this.
What rate control algorithm did you compile into the kernel? Minstrel
should perform quite well on p54, unless we made a mistake.
johannes
2008/11/19 Johannes Berg <[email protected]>:
> On Wed, 2008-11-19 at 17:23 +0100, Stefan Steuerwald wrote:
>
>> At first glance this improves things, but not enough. I have an ajax
>> application that is polling the web server and which runs into its 5
>> sec timeouts fairly regularly. [...deleted...]
>
> What's your client? Is it using powersave? Anyone know whether
> multicast-after-dtim works correctly in p54? Or maybe there's a bug
> hitting with TIM bits? Do you have an extra card that you could use to
> monitor and see what happens when it times out?
I have tested multiple clients at this time with my XG-601/ISL3880 p54 card:
- iPod Touch 2G with firmware 2.1.1
- Sony Vaio with a Marvell 88E8036 (Vista SP1)
- Amilo Notebook with Intel 4965AGN (stock Ubuntu 8.10)
- Amilo Notebook with Netgear USB-WLAN-Stick with RTL8187B (stock Ubuntu 8.10)
Interestingly, only the iPod is unusable, with constant timeouts of my
web-app. The other clients work 99% of the time with an _occasional_
timeout. I have multiple clients connected at the same time, and never
saw a simultaneous timeout with any two clients. I have also a wired
reference connection which never exhibits any timeouts.
I have no clue about iPod powersave. On the 4965 and the RTL8187 it
seems to be off (iwconfig output).
I do have indications of "general" WLAN problems with the iPod
(Apple's support forum is brimming with complaints). There may not be
any AP-related problem at all.
I will learn how to set up a card in monitor mode and post more info
if anything looks suspicious.
Thanks!
Stefan.
Thank you Johannes and Holger,
indeed I overlooked the AID bit in the relevant traffic sequences.
Knowing now what to look for, I can follow what is going on and find
it ok - except for the huge delay in between http request and reply.
Typically, the http request is sent, the iPod goes to sleep, and
several seconds pass (with numerous beacons without any AID bit set),
before we see one or two "traffic for you" beacons, then the iPod
wakes up and gets the reply. Most of the time my app already
timeouted.
I have checked that my app indeed completes its TCP reply in almost no
time. Mysteriously, the data takes several seconds from boost::asio
write completion until it appears on the air. That's the problem.
I will go back to square one and the fact that I see different
behaviour in the iPod and my other clients. I will work out the
differences. Will be back in case I come up with more wireless
questions.
Thank you for your help! Great work!
Stefan.
2008/11/21 Holger Schurig <[email protected]>:
> On Thursday 20 November 2008 20:21:44 Stefan Steuerwald wrote:
>> The iPod alternates Null Functions with the PWR MGT bit on and
>> off - whatever that means. Is it ignoring the AP and snoring
>> away?
>
> This is because the Ipod WLAN card all the time takes a nap of
> sleep. Whenever it goes to sleep, it sets the PWR_MGT bit. When
> it wakes up, it sends again a null packet with the bit off. So
> the AP should always know if the station sleeps or not.
>
> If the Ipod has data for the Ipod while it sleeps, it simply
> wakes up and sends the data, with the PWR_MGT bit off. Maybe it
> also sends a NULL packet iwth the PWR_MGT bit off in advance.
>
> If the AP has data for the Ipod while the Ipod sleeps, it sets
> the bit that corresponds to the AID of the Ipod in its TIM map.
> This is sent in the beacons of the AP. Even when a WLAN station
> sleeps, it knows when a beacon get's broadcasted and wakes up
> just in order to receive this beacon and check for it's AID bit.
> If it is set, it wakes up fully, notifies the AP about this and
> the AP sends the data packet to the now fully awoke WLAN
> station.
>
Can you trhis this patch?
Also, next time please don't filter the captures so much, it made it
hard to diagnose the problem.
johannes
Subject: mac80211: only transition STAs ps->wake on data frames
When a station goes to PS mode to scan, it will then send
probe requests without the PS bit set. mac80211 will take
that as indication that the station woke up, but it didn't.
This patch changes mac80211 to only consider doze->wake
transitions on data frames to to fix that issue.
Signed-off-by: Johannes Berg <[email protected]>
---
net/mac80211/rx.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
--- everything.orig/net/mac80211/rx.c 2008-11-23 14:58:21.000000000 +0100
+++ everything/net/mac80211/rx.c 2008-11-23 14:59:58.000000000 +0100
@@ -750,9 +750,11 @@ ieee80211_rx_h_sta_process(struct ieee80
/* Change STA power saving mode only in the end of a frame
* exchange sequence */
if (test_sta_flags(sta, WLAN_STA_PS) &&
- !ieee80211_has_pm(hdr->frame_control))
- rx->sent_ps_buffered += ap_sta_ps_end(sta);
- else if (!test_sta_flags(sta, WLAN_STA_PS) &&
+ !ieee80211_has_pm(hdr->frame_control)) {
+ /* ignore PS bit on non-data frames */
+ if (ieee80211_is_data(hdr->frame_control))
+ rx->sent_ps_buffered += ap_sta_ps_end(sta);
+ } else if (!test_sta_flags(sta, WLAN_STA_PS) &&
ieee80211_has_pm(hdr->frame_control))
ap_sta_ps_start(sta);
}
On Thu, 2008-11-20 at 20:29 +0100, Johannes Berg wrote:
> > @Johannes:
> > I was not able to find any indicated traffic in any of the beacon TIMs.
>
> Indeed. But did the problem happen during the trace here? It looks like
> there is no traffic for the ipod between it going to sleep and waking up
> again at all, should there be?
Never mind, I'm stupid, I set wireshark to assume an FCS and then it
didn't dissect things correctly. The TIM bit for AID 1 is set, and since
I guess nothing else is on the network hostapd will have used AID 1 for
the ipod, and the ipod also wakes up.
Therefore, the problem is something else.
johannes
Hello Johannes,
thank you for providing this patch. Tested, but I'm not sure about the result.
I THINK the frequency of my app-level timeouts is reduced, but I'm not
really sure. In any case it doesn't break anything for me.
I'm investigating this reason for my timeouts:
http://marc.info/?l=linux-wireless&m=122727674810057&w=2
and have better log info to post, will followup there.
Thank you,
Stefan.
2008/11/23 Johannes Berg <[email protected]>:
> Can you trhis this patch?
>
> Also, next time please don't filter the captures so much, it made it
> hard to diagnose the problem.
>
> johannes
>
>
> Subject: mac80211: only transition STAs ps->wake on data frames
>
> When a station goes to PS mode to scan, it will then send
> probe requests without the PS bit set. mac80211 will take
> that as indication that the station woke up, but it didn't.
> This patch changes mac80211 to only consider doze->wake
> transitions on data frames to to fix that issue.
>
> Signed-off-by: Johannes Berg <[email protected]>
> ---
> net/mac80211/rx.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> --- everything.orig/net/mac80211/rx.c 2008-11-23 14:58:21.000000000 +0100
> +++ everything/net/mac80211/rx.c 2008-11-23 14:59:58.000000000 +0100
> @@ -750,9 +750,11 @@ ieee80211_rx_h_sta_process(struct ieee80
> /* Change STA power saving mode only in the end of a frame
> * exchange sequence */
> if (test_sta_flags(sta, WLAN_STA_PS) &&
> - !ieee80211_has_pm(hdr->frame_control))
> - rx->sent_ps_buffered += ap_sta_ps_end(sta);
> - else if (!test_sta_flags(sta, WLAN_STA_PS) &&
> + !ieee80211_has_pm(hdr->frame_control)) {
> + /* ignore PS bit on non-data frames */
> + if (ieee80211_is_data(hdr->frame_control))
> + rx->sent_ps_buffered += ap_sta_ps_end(sta);
> + } else if (!test_sta_flags(sta, WLAN_STA_PS) &&
> ieee80211_has_pm(hdr->frame_control))
> ap_sta_ps_start(sta);
> }
>
>
>
On Thursday 20 November 2008 20:21:44 Stefan Steuerwald wrote:
> The iPod alternates Null Functions with the PWR MGT bit on and
> off - whatever that means. Is it ignoring the AP and snoring
> away?
This is because the Ipod WLAN card all the time takes a nap of
sleep. Whenever it goes to sleep, it sets the PWR_MGT bit. When
it wakes up, it sends again a null packet with the bit off. So
the AP should always know if the station sleeps or not.
If the Ipod has data for the Ipod while it sleeps, it simply
wakes up and sends the data, with the PWR_MGT bit off. Maybe it
also sends a NULL packet iwth the PWR_MGT bit off in advance.
If the AP has data for the Ipod while the Ipod sleeps, it sets
the bit that corresponds to the AID of the Ipod in its TIM map.
This is sent in the beacons of the AP. Even when a WLAN station
sleeps, it knows when a beacon get's broadcasted and wakes up
just in order to receive this beacon and check for it's AID bit.
If it is set, it wakes up fully, notifies the AP about this and
the AP sends the data packet to the now fully awoke WLAN
station.
On Thu, 2008-11-20 at 20:21 +0100, Stefan Steuerwald wrote:
> Now I'm learning something! Seems like Johannes' initial question
> about powersaving might have been right on the mark, and Holger's
> explanation set that straight in my brain. Thank you for that!
:)
> I have attached some traces. Connected my iPod to the XG-601 AP and to
> my fritzbox 7170.
> I'm not sure about the interpretation of the beacon flags, but I never
> see beacon flags other than 0x0, does that mean the AP is saying "stay
> awake, no sleeping" to the client?
beacon flags are useless, APs are always awake. No, the AP isn't saying
that to the clients, it's saying that about itself :)
> The iPod alternates Null Functions with the PWR MGT bit on and off -
> whatever that means. Is it ignoring the AP and snoring away?
See above :)
> @Johannes:
> I was not able to find any indicated traffic in any of the beacon TIMs.
Indeed. But did the problem happen during the trace here? It looks like
there is no traffic for the ipod between it going to sleep and waking up
again at all, should there be? If there should be, then there's
definitely a bug in p54/mac80211 somewhere. However, I can't find
anything in the other dumps either, so it seems like there was no
traffic.
Can you try a better test:
(1) start monitoring
(2) connect your ipod to the AP
(3) add the ipod's MAC address to arp (arp -i wlan0 -s 123.456.789.000 gg:jj:kk:ll:mm:nn)
(3) ping it from the network so that it'll be asleep and need to be
woken
johannes
On Wed, 2008-11-19 at 17:23 +0100, Stefan Steuerwald wrote:
> At first glance this improves things, but not enough. I have an ajax
> application that is polling the web server and which runs into its 5
> sec timeouts fairly regularly. I had this working almost ok before
> with an Atheros card and the latest madwifi driver, but got trashed by
> "stuck beacon" events. I will try this card again with the ath5k
> driver and see how this works.
What's your client? Is it using powersave? Anyone know whether
multicast-after-dtim works correctly in p54? Or maybe there's a bug
hitting with TIM bits? Do you have an extra card that you could use to
monitor and see what happens when it times out?
johannes
Some comments about
your "ipod_http_request_probe_responses.pcap":
I think here the same problem happens.
In packet 10 and again in packet 12 your Ipod tells the AP that
it is now sleeping. The AP acknowledges both packets.
Then I see lots of probe responses from the AP to a different
MAC, but they seem to be unrelated to your Ipod. Also the probe
requests that one can see are from somebody else, e.g.
In packet 121 your Ipod tells the AP that it now woke up and
immediately closed the HTTP connection.
And you might have guess by now that also in
your "ipod_http_request_tcp_reset.pcap" the problem started once
your Ipod told the AP that it goes to sleep, again with two
packets.
>> What's your client? Is it using powersave? Anyone know whether
>> multicast-after-dtim works correctly in p54? Or maybe there's a bug
>> hitting with TIM bits? Do you have an extra card that you could use to
>> monitor and see what happens when it times out?
>
> I have tested multiple clients at this time with my XG-601/ISL3880 p54 card:
> - iPod Touch 2G with firmware 2.1.1
> - Sony Vaio with a Marvell 88E8036 (Vista SP1)
> - Amilo Notebook with Intel 4965AGN (stock Ubuntu 8.10)
> - Amilo Notebook with Netgear USB-WLAN-Stick with RTL8187B (stock Ubuntu 8.10)
>
> Interestingly, only the iPod is unusable, with constant timeouts of my
> web-app. The other clients work 99% of the time with an _occasional_
> timeout. I have multiple clients connected at the same time, and never
> saw a simultaneous timeout with any two clients. I have also a wired
> reference connection which never exhibits any timeouts.
I have attached some traffic dumps that happen between my iPod Touch
and the XG-601-based AP (obtained with a RTL8187B in monitor mode):
Observations:
- ipod_http_request_ok.pcap shows how I would like the world to be
(and how it is _occasionally_ with the iPod and _almost always_ with
my other clients). We build a TCP connection, make a http request, get
a TCP ACK, followed swiftly by an answer and the TCP connection
closes.
- Sometimes, however, the http answer does not appear immediately
after the request (about 4-7 secs of delay). The gap is filled by some
"Null function" packets originating on the iPod (maybe it is getting
impatient?). This gets me an application-level timeout. See
ipod_http_request_delayed_answer.pcap .
- Then, there's a scenario that makes the iPod reset any new TCP
connection until I disassociate and reassociate it to the AP (see the
last two pcaps). This seems to happen whenever somebody (must be my
Notebook WLAN) sends probes. The same sequence of events does not
cause anything untoward with my other clients.
It may be Apple's job to fix this - however, iPods work ok with many
APs (including Apple's own AirPort of course) (and the latest madwifi
except for annoying "stuck beacons" resulting in card resets).
Any ideas? Should I forward this info to someone? Anything I should try?
My goal is to make the iPod work with any decent MiniPCI card that
supports AP mode.
Best regards,
Stefan.
>> However - data throughput seems low; accessing a webserver I get an
>> update "now and then". I'm aware this can have a lots of causes - I
>> have more time and more cards available (XG-601/ISL3880, and an
>> AR5212/5213 one) and will play with this.
>
> What rate control algorithm did you compile into the kernel? Minstrel
> should perform quite well on p54, unless we made a mistake.
I had only compiled in the PID-based thing. Fixed that, made Minstrel
the default.
At first glance this improves things, but not enough. I have an ajax
application that is polling the web server and which runs into its 5
sec timeouts fairly regularly. I had this working almost ok before
with an Atheros card and the latest madwifi driver, but got trashed by
"stuck beacon" events. I will try this card again with the ath5k
driver and see how this works.
Thanks for your help,
Stefan.
On Wed, 2008-11-19 at 12:16 +0100, Stefan Steuerwald wrote:
> I'd like to test the recent p54 AP mode patches against my XG-603
> (ISL3886) MiniPCI card.
> Tried that with the current wireless-testing.git, compiled ok, module
> loads with 2.13.1.0.arm firmware.
> I was under the impression that this should now work:
> iwconfig wlan1 mode Master
> however it errors with:
> Error for wireless request "Set Mode" (8B06) : SET failed on
> device wlan1 ; Invalid argument.
>
> Being new to wireless, I'd please like a pointer on what to
> investigate and which info to provide.
http://wireless.kernel.org/en/users/Documentation/modes#AccessPoint.28AP.29infrastructuremode
johannes
> http://wireless.kernel.org/en/users/Documentation/modes#AccessPoint.28AP.29infrastructuremode
> johannes
Thank you, that's it, took the latest hostapd from git.
I can now connect from my iPod to the XG-603 in AP mode (unencrypted
and WPA/TKIP, WPA2/TKIP, WPA2/CCMP tested).
However - data throughput seems low; accessing a webserver I get an
update "now and then". I'm aware this can have a lots of causes - I
have more time and more cards available (XG-601/ISL3880, and an
AR5212/5213 one) and will play with this.
Stefan.