Hey,
is it possible that something is broken with powersave mode? I frequently
have connection stalls up to hangs with the N770 that go away when I
either continually ping from the beginning of the connection or do
something from the N770 instead of from the laptop that is functioning
as the AP.
The logs also sometimes contain many messages
[17145.100011] Buffered frame expired (STA <mac addr>)
which leads me to believe that the N770 enters powersave mode but
starting to ping it after it has entered PS mode doesn't wake it up from
PS mode. I can see beacons using my zd1211 device as monitor, but none
of them has anything in the TIM bitmap. However, zd1211 seems to not
show me any non-broadcast frames in monitor mode right now so I can't
verify at the moment whether the N770 does or doesn't go into powersave
mode, I don't see it locally on the monitor interface but it might
actually be negotiating powersave mode with the firm/hardware in
bcm43xx...
I'll keep digging, but if somebody has any idea if/how the powersave
code works let me know where to look.
johannes
On Tue, 2007-08-28 at 21:08 +0300, Kalle Valo wrote:
> I hope you have time to investigate this, because I really would like
> to have Nokia N800 and 770 working with b43 AP. So if you need more
> testing, just ask.
Can you disable QoS and see if the same weird frames show up again? b43
doesn't really support QoS yet but I don't think that should be causing
such frame corruption.
Interestingly, your N800 seems to pick up the frames correctly since it
did reply to the ping packets... Did you have a capture size limit?
johannes
Hey,
Good news. I figured out the DTIM thing and the multicast frame queue
stuff. For multicast frames, you simply send them down queue four and
they are dequeued and sent by the ucode after the DTIM beacon.
> But that's not all, also multicast frames (including ARP broadcast)
> are not buffered correctly. They are sent randomly instead of directly
> after a DTIM beacon. Also Multicast bit is not set and DTIM is always
> zero even though DTIM period is two.
Actually, they were sent right away because we enqueued them to queue
zero, not queue four.
Please try the attached patches. I haven't implemented the set_tim()
callback yet, but the device should now wake up for multicast traffic,
not for unicast yet. The patches work for me on a heavily patched kernel
('everything' plus http://johannes.sipsolutions.net/patches/kernel/all/)
I'll update the specs to indicate that
(1) the tim offset shm thing needs to be set as well as the dtim period
(2) queue four must be used for multicast frames [in client mode we
never send multicast frames so doing it unconditionally is fine]
(3) updating the beacon on every beacon interrupt isn't necessary, it
only needs to be updated if it has changed (it works fine even if
you update it, it's just not necessary)
(4) the TIM is software controlled and should be set by the driver with
help from the beacon interrupt.
(5) the 0xa8 (==0x54*2) shm offset needs to be described, it's the
"last multicast frame" for clearing the more-data bit and 0xffff is
a special value that causes the microcode to clear the more-data
bit on all multicast frames (odd, and I don't know why that would
be useful, probably something with IBSS when we're not beaconing)
Due to the last point, I'm not entirely sure these patches are correct.
And I haven't bothered about PIO, do we even have access to that queue
there?
As for the whole beacon handling... I suggest that we change mac80211 to
give the beacon head and beacon tail to the driver like it gets it from
hostapd. Thing is, we first go to all the effort to build a valid beacon
frame, but then the driver gets to parse it all out again. That's dumb.
Hardware that has beaconing offload and implements the set_tim()
callback needs to know the TIM position, so it's probably better off
knowing the beacon head and tail. Drivers that call get_beacon() don't
care about conf->beacon except that they need to free it. Not obvious,
and many are probably buggy.
johannes
On Wed, 2007-08-29 at 10:37 +0200, Johannes Berg wrote:
> I'll update the specs to indicate that
I wrote http://bcm-v4.sipsolutions.net/802.11/TX#QueueSelection and
updated the ObjectMemory page for the SHM stuff wrt. DTIM period etc.
johannes
On Wed, 2007-08-29 at 19:50 +0200, Michael Buesch wrote:
> Hm, I am wondering why this "more data" thing is needed.
> Driver sets it and fw clears it? So why set it at all?
It only clears it on the last multicast frame, if you read the 802.11
spec it says that it must be set on all others.
johannes
Johannes Berg <[email protected]> writes:
> Good news.
Really good news!
>> But that's not all, also multicast frames (including ARP broadcast)
>> are not buffered correctly. They are sent randomly instead of directly
>> after a DTIM beacon. Also Multicast bit is not set and DTIM is always
>> zero even though DTIM period is two.
>
> Actually, they were sent right away because we enqueued them to queue
> zero, not queue four.
Yeah, I meant randomly relative to a DTIM beacon.
> Please try the attached patches. I haven't implemented the set_tim()
> callback yet, but the device should now wake up for multicast traffic,
> not for unicast yet. The patches work for me on a heavily patched kernel
> ('everything' plus http://johannes.sipsolutions.net/patches/kernel/all/)
Applied 055-b43-timb-position.patch and 057-b43-mcast.patch to commit
0347a7c86f. Multicast is buffered correctly and N800 sees them. Also
DTIM count and multicast bit are now correct in beacons.
--
Kalle Valo
On Wed, 2007-08-29 at 17:35 +0300, Kalle Valo wrote:
> I tested your multicast stuff and it worked. Do you still want me to
> test with QoS disabled in N800?
No. But please test the little patch I gave you that should clear out
the QoS header properly.
> > Yes, the odd thing however is that it replies to these mangled packets.
> > I would guess that's a bug in the QoS implementation on the N800.
>
> Good point. I'll look into that.
Thanks.
johannes
Johannes Berg <[email protected]> writes:
> On Wed, 2007-08-29 at 07:18 +0300, Kalle Valo wrote:
>
>> > Can you disable QoS and see if the same weird frames show up again? b43
>> > doesn't really support QoS yet but I don't think that should be causing
>> > such frame corruption.
>>
>> From b43 or N800?
>
> N800, I guess, if possible. But since you didn't do this yet you might
> want to try the stuff I sent you first.
I tested your multicast stuff and it worked. Do you still want me to
test with QoS disabled in N800?
>> > Interestingly, your N800 seems to pick up the frames correctly since it
>> > did reply to the ping packets...
>>
>> Yes, N800 managed to receive some ping packets from the laptop
>
> Yes, the odd thing however is that it replies to these mangled packets.
> I would guess that's a bug in the QoS implementation on the N800.
Good point. I'll look into that.
--
Kalle Valo
Johannes Berg <[email protected]> writes:
>> Are there any tricks or should this be enough with b43:
>>
>> iwconfig wlan0 mode master channel 2 essid mac80211
>> ip link set wlan0 up
>
> Umm, of course not. You need hostapd.
Heh, I guess I have used madwifi too much :)
I didn't even think of hostapd, for some strange reason I have always
thought it as an optional feature.
I couldn't find any instructions how to use hostapd with mac80211, so
here's what I did (for the archive):
o pulled latest wireless-dev#everything
o pulled latest hostapd from git
o compiled hostapd with these extra settings in .config:
CONFIG_DRIVER_DEVICESCAPE=y
WIRELESS_DEV=/home/kvalo/linux-2.6/
CFLAGS += -I$(WIRELESS_DEV)/net/mac80211
o edited hostapd.conf (wlan1 is my b43 interface):
interface=wlan1
driver=devicescape
hw_mode=g
channel=5
o started hostapd:
# ./hostapd hostapd.conf
--
Kalle Valo
On Tue, 2007-08-28 at 19:06 +0300, Kalle Valo wrote:
> I also some really odd frames sent by b43 when N800 had PSM enabled.
> Never seen it before, no idea what it is. Dump at the of this message.
> QoS Control
> Priority: 4 (Controlled Load) (Video)
> .... 0... = EOSP: Service period
> Ack Policy: Block Ack (0x03)
> Payload Type: A-MSDU
> QAP PS Buffer State: 0xd5
> IEEE 802.11 Aggregate MSDU
> A-MSDU Subframe #1
That's just f'ed up. We shouldn't be sending aggregated MSDUs, but we
do due to the uninitialised header. But it's a bug in the N800 that it
accepts such frames. Try the patch below with qos enabled.
johannes
--- wireless-dev.orig/net/mac80211/tx.c 2007-08-28 21:25:44.804618695 +0200
+++ wireless-dev/net/mac80211/tx.c 2007-08-28 21:37:22.394618695 +0200
@@ -1346,7 +1346,15 @@ int ieee80211_subif_start_xmit(struct sk
struct ieee80211_sub_if_data *sdata;
int ret = 1, head_need;
u16 ethertype, hdrlen, fc;
- struct ieee80211_hdr hdr;
+ /*
+ * QoS headers are 2 bytes longer (32 bytes with a
+ * 4-addr format frame) and the QoS control field
+ * needs to be initialised to zero.
+ */
+ union {
+ struct ieee80211_hdr hdr;
+ char __buf[32];
+ } hdr = { .__buf = {0} };
const u8 *encaps_data;
int encaps_len, skip_header_bytes;
int nh_pos, h_pos;
@@ -1374,40 +1382,40 @@ int ieee80211_subif_start_xmit(struct sk
case IEEE80211_IF_TYPE_VLAN:
fc |= IEEE80211_FCTL_FROMDS;
/* DA BSSID SA */
- memcpy(hdr.addr1, skb->data, ETH_ALEN);
- memcpy(hdr.addr2, dev->dev_addr, ETH_ALEN);
- memcpy(hdr.addr3, skb->data + ETH_ALEN, ETH_ALEN);
+ memcpy(hdr.hdr.addr1, skb->data, ETH_ALEN);
+ memcpy(hdr.hdr.addr2, dev->dev_addr, ETH_ALEN);
+ memcpy(hdr.hdr.addr3, skb->data + ETH_ALEN, ETH_ALEN);
hdrlen = 24;
break;
case IEEE80211_IF_TYPE_WDS:
fc |= IEEE80211_FCTL_FROMDS | IEEE80211_FCTL_TODS;
/* RA TA DA SA */
- memcpy(hdr.addr1, sdata->u.wds.remote_addr, ETH_ALEN);
- memcpy(hdr.addr2, dev->dev_addr, ETH_ALEN);
- memcpy(hdr.addr3, skb->data, ETH_ALEN);
- memcpy(hdr.addr4, skb->data + ETH_ALEN, ETH_ALEN);
+ memcpy(hdr.hdr.addr1, sdata->u.wds.remote_addr, ETH_ALEN);
+ memcpy(hdr.hdr.addr2, dev->dev_addr, ETH_ALEN);
+ memcpy(hdr.hdr.addr3, skb->data, ETH_ALEN);
+ memcpy(hdr.hdr.addr4, skb->data + ETH_ALEN, ETH_ALEN);
hdrlen = 30;
break;
case IEEE80211_IF_TYPE_STA:
if (dls_link_status(local, skb->data) == DLS_STATUS_OK) {
/* DA SA BSSID */
- memcpy(hdr.addr1, skb->data, ETH_ALEN);
- memcpy(hdr.addr2, skb->data + ETH_ALEN, ETH_ALEN);
- memcpy(hdr.addr3, sdata->u.sta.bssid, ETH_ALEN);
+ memcpy(hdr.hdr.addr1, skb->data, ETH_ALEN);
+ memcpy(hdr.hdr.addr2, skb->data + ETH_ALEN, ETH_ALEN);
+ memcpy(hdr.hdr.addr3, sdata->u.sta.bssid, ETH_ALEN);
} else {
fc |= IEEE80211_FCTL_TODS;
/* BSSID SA DA */
- memcpy(hdr.addr1, sdata->u.sta.bssid, ETH_ALEN);
- memcpy(hdr.addr2, skb->data + ETH_ALEN, ETH_ALEN);
- memcpy(hdr.addr3, skb->data, ETH_ALEN);
+ memcpy(hdr.hdr.addr1, sdata->u.sta.bssid, ETH_ALEN);
+ memcpy(hdr.hdr.addr2, skb->data + ETH_ALEN, ETH_ALEN);
+ memcpy(hdr.hdr.addr3, skb->data, ETH_ALEN);
}
hdrlen = 24;
break;
case IEEE80211_IF_TYPE_IBSS:
/* DA SA BSSID */
- memcpy(hdr.addr1, skb->data, ETH_ALEN);
- memcpy(hdr.addr2, skb->data + ETH_ALEN, ETH_ALEN);
- memcpy(hdr.addr3, sdata->u.sta.bssid, ETH_ALEN);
+ memcpy(hdr.hdr.addr1, skb->data, ETH_ALEN);
+ memcpy(hdr.hdr.addr2, skb->data + ETH_ALEN, ETH_ALEN);
+ memcpy(hdr.hdr.addr3, sdata->u.sta.bssid, ETH_ALEN);
hdrlen = 24;
break;
default:
@@ -1416,7 +1424,7 @@ int ieee80211_subif_start_xmit(struct sk
}
/* receiver is QoS enabled, use a QoS type frame */
- sta = sta_info_get(local, hdr.addr1);
+ sta = sta_info_get(local, hdr.hdr.addr1);
if (sta) {
if (sta->flags & WLAN_STA_WME) {
fc |= IEEE80211_STYPE_QOS_DATA;
@@ -1425,9 +1433,9 @@ int ieee80211_subif_start_xmit(struct sk
sta_info_put(sta);
}
- hdr.frame_control = cpu_to_le16(fc);
- hdr.duration_id = 0;
- hdr.seq_ctrl = 0;
+ hdr.hdr.frame_control = cpu_to_le16(fc);
+ hdr.hdr.duration_id = 0;
+ hdr.hdr.seq_ctrl = 0;
skip_header_bytes = ETH_HLEN;
if (ethertype == ETH_P_AARP || ethertype == ETH_P_IPX) {
On Thu, 2007-08-16 at 17:31 +0300, Kalle Valo wrote:
> Are there any tricks or should this be enough with b43:
>
> iwconfig wlan0 mode master channel 2 essid mac80211
> ip link set wlan0 up
Umm, of course not. You need hostapd.
joahnnes
On Wednesday 29 August 2007 12:11:52 Johannes Berg wrote:
> On Wed, 2007-08-29 at 10:37 +0200, Johannes Berg wrote:
>
> > I'll update the specs to indicate that
>
> I wrote http://bcm-v4.sipsolutions.net/802.11/TX#QueueSelection and
> updated the ObjectMemory page for the SHM stuff wrt. DTIM period etc.
Hm, I am wondering why this "more data" thing is needed.
Driver sets it and fw clears it? So why set it at all?
--
Greetings Michael.
> Applied 055-b43-timb-position.patch and 057-b43-mcast.patch to commit
> 0347a7c86f. Multicast is buffered correctly and N800 sees them. Also
> DTIM count and multicast bit are now correct in beacons.
Good. However, it appears that in STA mode we need to enqueue multicast
frames to queue 1 as well, not 4, so the patches aren't exactly correct.
johannes
"Johannes Berg" <[email protected]> writes:
> is it possible that something is broken with powersave mode? I frequently
> have connection stalls up to hangs with the N770 that go away when I
> either continually ping from the beginning of the connection or do
> something from the N770 instead of from the laptop that is functioning
> as the AP.
[...]
> I'll keep digging, but if somebody has any idea if/how the powersave
> code works let me know where to look.
One thing which came to my mind is that when Nokia 770 is in PSM it
uses PS-Poll to fetch the frames from AP. Few devices do that, so I
wonder if mac80211 supports that properly?
But I'm just guessing here.
--
Kalle Valo
On Tue, 2007-08-28 at 19:06 +0300, Kalle Valo wrote:
> Ok, I finally managed to test it. Hardware was Nokia N800 and Broadcom
> 4318 in an x86 laptop. I used b43 from wireless-dev#everything commit
> 0347a7c86f8406 and hostapd from commit 62897a2a1a0e. I tested running
> ping and arping from the laptop to N800.
Cool, thanks.
> Everything works fine when N800 has WLAN PSM disabled. When WLAN PSM
> is enabled, TIM for AID is not set in beacons, just like you said.
Right.
> But that's not all, also multicast frames (including ARP broadcast)
> are not buffered correctly. They are sent randomly instead of directly
> after a DTIM beacon. Also Multicast bit is not set and DTIM is always
> zero even though DTIM period is two.
Hm, yeah, I almost expected this, b43 hardware has some capabilities for
this but we don't really know how to use it yet. We also need to upload
the DTIM count to the hardware (shm somewhere)
> I also some really odd frames sent by b43 when N800 had PSM enabled.
> Never seen it before, no idea what it is. Dump at the of this message.
Could you send me a packet capture in pkt format via private mail?
johannes
Johannes Berg <[email protected]> writes:
>> Heh, I guess I have used madwifi too much :)
>
> Heh, yeah, the BSD folks insist of putting all that functionality into
> the kernel because for some reason they believe it'll magically make it
> more stable (they told me that, minus the "magically")
Hostapd makes sense to me (now) and it was really easy to setup, so no
problems with that.
I just have a fear that we don't endup in "udev-hell", that is
incompatibility between kernel and hostapd versions. It was just awful
with udev few years ago, let's try to avoid that. Official hostapd
releases should work with all official kernel releases, without any
exceptions.
> In any case, I'm fairly sure the TIM is just wrong, if you have a third
> device you could try capturing the beacons and check that the TIM is
> never updated.
I will check that later and send the results here.
--
Kalle Valo
On Thu, 2007-08-16 at 08:43 +0300, Kalle Valo wrote:
> One thing which came to my mind is that when Nokia 770 is in PSM it
> uses PS-Poll to fetch the frames from AP. Few devices do that, so I
> wonder if mac80211 supports that properly?
I had to return the N770 I tested with to its owner, but I think I found
the problem anyway. b43 doesn't have a set_tim() handler so the TIM bits
are never set.
Michael, the firmware automatically sets the DTIM count field in the
beacon according to the the B43_SHM_SH_DTIMPER value, B43_SHM_SH_TIMBPOS
must point to the correct offset into the beacon (to the TIM information
element.) Bit 0 of the TIM (broadcast/multicast) is set according to
whether FIFO 4 has contents or not so we'll have to do some more reverse
engineering to get that bit properly set. The microcode doesn't seem to
do any other things with the TIM, but I haven't fully understood the PMQ
thing yet, but it appears to be just some firmware-assisted PS mode
tracking (it adds entries when a STA enters or leaves PS mode or
disassociates/deauthenticates etc.
johannes
On Mon, 2007-08-27 at 18:58 +0300, Kalle Valo wrote:
> Heh, I guess I have used madwifi too much :)
Heh, yeah, the BSD folks insist of putting all that functionality into
the kernel because for some reason they believe it'll magically make it
more stable (they told me that, minus the "magically")
In any case, I'm fairly sure the TIM is just wrong, if you have a third
device you could try capturing the beacons and check that the TIM is
never updated.
johannes
Johannes Berg <[email protected]> writes:
> On Tue, 2007-08-28 at 13:59 +0300, Kalle Valo wrote:
>
>> I just have a fear that we don't endup in "udev-hell", that is
>> incompatibility between kernel and hostapd versions. It was just awful
>> with udev few years ago, let's try to avoid that. Official hostapd
>> releases should work with all official kernel releases, without any
>> exceptions.
>
> Well, with mac80211 mainline kernels currently don't support AP mode at
> all, and wireless-dev/hostapd are quite in lockstep.
Yeah, I understood that.
> As soon as we merge the AP mode stuff into mainline, however, it
> will be via nl80211 which shall be a stable interface for that.
That's a relief for me :) Thanks.
--
Kalle Valo
Johannes Berg <[email protected]> writes:
>> > In any case, I'm fairly sure the TIM is just wrong, if you have a third
>> > device you could try capturing the beacons and check that the TIM is
>> > never updated.
Ok, I finally managed to test it. Hardware was Nokia N800 and Broadcom
4318 in an x86 laptop. I used b43 from wireless-dev#everything commit
0347a7c86f8406 and hostapd from commit 62897a2a1a0e. I tested running
ping and arping from the laptop to N800.
Everything works fine when N800 has WLAN PSM disabled. When WLAN PSM
is enabled, TIM for AID is not set in beacons, just like you said.
But that's not all, also multicast frames (including ARP broadcast)
are not buffered correctly. They are sent randomly instead of directly
after a DTIM beacon. Also Multicast bit is not set and DTIM is always
zero even though DTIM period is two.
I also some really odd frames sent by b43 when N800 had PSM enabled.
Never seen it before, no idea what it is. Dump at the of this message.
Here's one beacon taken with madwifi and formatted with wireshark to
show that the TIM is not set:
No. Time Source Destination Protocol Info
628 0.102 Belkin_f4:c2:42 Broadcast IEEE 802.11 Beacon frame,SN=1177,FN=0,BI=100, SSID: "valo-test"
Frame 628 (245 bytes on wire, 245 bytes captured)
Arrival Time: Aug 28, 2007 18:32:54.271060000
[Time delta from previous captured frame: 0.080321000 seconds]
[Time delta from previous displayed frame: 0.102410000 seconds]
[Time since reference or first frame: 13.005208000 seconds]
Frame Number: 628
Frame Length: 245 bytes
Capture Length: 245 bytes
[Frame is marked: False]
[Protocols in frame: prism:wlan]
Prism Monitoring Header
Message Code: 68
Message Length: 144
Device: ath3
Host Time: 0x2d9cf73 (DID 0x10044, Status 0x0, Length 0x4)
MAC Time: 0x2f0d213a (DID 0x20044, Status 0x0, Length 0x4)
Channel: 0x5 (DID 0x30044, Status 0x0, Length 0x4)
RSSI: 0x3b (DID 0x40044, Status 0x0, Length 0x4)
SQ: 0x0 (DID 0x0, Status 0x0, Length 0x0)
Signal: 0xffffffdb (DID 0x60044, Status 0x0, Length 0x4)
Noise: 0xffffffa0 (DID 0x70044, Status 0x0, Length 0x4)
Data Rate: 1.0 Mb/s
IsTX: 0x0 (DID 0x90044, Status 0x0, Length 0x4)
Frame Length: 0x69 (DID 0xa0044, Status 0x0, Length 0x4)
IEEE 802.11
Type/Subtype: Beacon frame (0x08)
Frame Control: 0x0080 (Normal)
Version: 0
Type: Management frame (0)
Subtype: 8
Flags: 0x0
DS status: Not leaving DS or network is operating in AD-HOC mode (To DS: 0 From DS: 0) (0x00)
.... .0.. = More Fragments: This is the last fragment
.... 0... = Retry: Frame is not being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = Order flag: Not strictly ordered
Duration: 0
Destination address: Broadcast (ff:ff:ff:ff:ff:ff)
Source address: Belkin_f4:c2:42 (00:11:50:f4:c2:42)
BSS Id: Belkin_f4:c2:42 (00:11:50:f4:c2:42)
Fragment number: 0
Sequence number: 1177
IEEE 802.11 wireless LAN management frame
Fixed parameters (12 bytes)
Timestamp: 0x00000000508D6189
Beacon Interval: 0,102400 [Seconds]
Capability Information: 0x0401
.... .... .... ...1 = ESS capabilities: Transmitter is an AP
.... .... .... ..0. = IBSS status: Transmitter belongs to a BSS
.... ..0. .... 00.. = CFP participation capabilities: No point coordinator at AP (0x0000)
.... .... ...0 .... = Privacy: AP/STA cannot support WEP
.... .... ..0. .... = Short Preamble: Short preamble not allowed
.... .... .0.. .... = PBCC: PBCC modulation not allowed
.... .... 0... .... = Channel Agility: Channel agility not in use
.... ...0 .... .... = Spectrum Management: dot11SpectrumManagementRequired FALSE
.... .1.. .... .... = Short Slot Time: Short slot time in use
.... 0... .... .... = Automatic Power Save Delivery: apsd not implemented
..0. .... .... .... = DSSS-OFDM: DSSS-OFDM modulation not allowed
.0.. .... .... .... = Delayed Block Ack: delayed block ack not implemented
0... .... .... .... = Immediate Block Ack: immediate block ack not implemented
Tagged parameters (65 bytes)
SSID parameter set: "valo-test"
Tag Number: 0 (SSID parameter set)
Tag length: 9
Tag interpretation: valo-test
Supported Rates: 1,0(B) 2,0(B) 5,5(B) 11,0(B) 6,0 9,0 12,0 18,0
Tag Number: 1 (Supported Rates)
Tag length: 8
Tag interpretation: Supported rates: 1,0(B) 2,0(B) 5,5(B) 11,0(B) 6,0 9,0 12,0 18,0 [Mbit/sec]
DS Parameter set: Current Channel: 5
Tag Number: 3 (DS Parameter set)
Tag length: 1
Tag interpretation: Current Channel: 5
Traffic Indication Map (TIM): DTIM 0 of 2 bitmap empty
Tag Number: 5 (Traffic Indication Map (TIM))
TIM length: 4
DTIM count: 0
DTIM period: 2
Bitmap Control: 0x00 (mcast:0, bitmap offset 0)
ERP Information: no Non-ERP STAs, do not use protection, short or long preambles
Tag Number: 42 (ERP Information)
Tag length: 1
Tag interpretation: ERP info: 0x0 (no Non-ERP STAs, do not use protection, short or long preambles)
Extended Supported Rates: 24,0 36,0 48,0 54,0
Tag Number: 50 (Extended Supported Rates)
Tag length: 4
Tag interpretation: Supported rates: 24,0 36,0 48,0 54,0 [Mbit/sec]
Vendor Specific: WME
Tag Number: 221 (Vendor Specific)
Tag length: 24
Tag interpretation: WME PE: type 2, subtype 1, version 1, parameter set 0
Tag interpretation: WME AC Parameters: ACI 0 (Best Effort), Admission Control not Mandatory, AIFSN 3, ECWmin 4, ECWmax 4, TXOP 0
Tag interpretation: WME AC Parameters: ACI 1 (Background), Admission Control not Mandatory, AIFSN 7, ECWmin 4, ECWmax 4, TXOP 0
Tag interpretation: WME AC Parameters: ACI 2 (Video), Admission Control not Mandatory, AIFSN 2, ECWmin 3, ECWmax 3, TXOP 94
Tag interpretation: WME AC Parameters: ACI 3 (Voice), Admission Control not Mandatory, AIFSN 2, ECWmin 2, ECWmax 2, TXOP 47
0000 44 00 00 00 90 00 00 00 61 74 68 33 00 00 00 00 D.......ath3....
0010 00 00 00 00 00 00 00 00 44 00 01 00 00 00 04 00 ........D.......
0020 73 cf d9 02 44 00 02 00 00 00 04 00 3a 21 0d 2f s...D.......:!./
0030 44 00 03 00 00 00 04 00 05 00 00 00 44 00 04 00 D...........D...
0040 00 00 04 00 3b 00 00 00 00 00 00 00 00 00 00 00 ....;...........
0050 00 00 00 00 44 00 06 00 00 00 04 00 db ff ff ff ....D...........
0060 44 00 07 00 00 00 04 00 a0 ff ff ff 44 00 08 00 D...........D...
0070 00 00 04 00 02 00 00 00 44 00 09 00 00 00 04 00 ........D.......
0080 00 00 00 00 44 00 0a 00 00 00 04 00 69 00 00 00 ....D.......i...
0090 80 00 00 00 ff ff ff ff ff ff 00 11 50 f4 c2 42 ............P..B
00a0 00 11 50 f4 c2 42 90 49 89 61 8d 50 00 00 00 00 ..P..B.I.a.P....
00b0 64 00 01 04 00 09 76 61 6c 6f 2d 74 65 73 74 01 d.....valo-test.
00c0 08 82 84 8b 96 0c 12 18 24 03 01 05 05 04 00 02 ........$.......
00d0 00 00 2a 01 00 32 04 30 48 60 6c dd 18 00 50 f2 ..*..2.0H`l...P.
00e0 02 01 01 00 d9 03 a4 00 00 27 a4 00 00 42 43 5e .........'...BC^
00f0 00 62 32 2f 00 .b2/.
And here's a dump about the odd frames I saw:
No. Time Source Destination Protocol Info
653 0.001 Belkin_f4:c2:42 Nokia_fe:b8:19 LLC [Packet size limited during capture]
Frame 653 (262 bytes on wire, 262 bytes captured)
Arrival Time: Aug 28, 2007 18:32:54.601251000
[Time delta from previous captured frame: 0.001532000 seconds]
[Time delta from previous displayed frame: 0.001545000 seconds]
[Time since reference or first frame: 13.335399000 seconds]
Frame Number: 653
Frame Length: 262 bytes
Capture Length: 262 bytes
[Frame is marked: False]
[Protocols in frame: prism:wlan:llc]
Prism Monitoring Header
Message Code: 68
Message Length: 144
Device: ath3
Host Time: 0x2d9cfc6 (DID 0x10044, Status 0x0, Length 0x4)
MAC Time: 0x2f122afb (DID 0x20044, Status 0x0, Length 0x4)
Channel: 0x5 (DID 0x30044, Status 0x0, Length 0x4)
RSSI: 0x3b (DID 0x40044, Status 0x0, Length 0x4)
SQ: 0x0 (DID 0x0, Status 0x0, Length 0x0)
Signal: 0xffffffdb (DID 0x60044, Status 0x0, Length 0x4)
Noise: 0xffffffa0 (DID 0x70044, Status 0x0, Length 0x4)
Data Rate: 1.0 Mb/s
IsTX: 0x0 (DID 0x90044, Status 0x0, Length 0x4)
Frame Length: 0x7a (DID 0xa0044, Status 0x0, Length 0x4)
IEEE 802.11
Type/Subtype: QoS Data (0x28)
Frame Control: 0x0A88 (Normal)
Version: 0
Type: Data frame (2)
Subtype: 8
Flags: 0xA
DS status: Frame from DS to a STA via AP(To DS: 0 From DS: 1) (0x02)
.... .0.. = More Fragments: This is the last fragment
.... 1... = Retry: Frame is being retransmitted
...0 .... = PWR MGT: STA will stay up
..0. .... = More Data: No data buffered
.0.. .... = Protected flag: Data is not protected
0... .... = Order flag: Not strictly ordered
Duration: 314
Destination address: Nokia_fe:b8:19 (00:15:2a:fe:b8:19)
BSS Id: Belkin_f4:c2:42 (00:11:50:f4:c2:42)
Source address: Belkin_f4:c2:42 (00:11:50:f4:c2:42)
Fragment number: 0
Sequence number: 1182
QoS Control
Priority: 4 (Controlled Load) (Video)
.... 0... = EOSP: Service period
Ack Policy: Block Ack (0x03)
Payload Type: A-MSDU
QAP PS Buffer State: 0xd5
IEEE 802.11 Aggregate MSDU
A-MSDU Subframe #1
Destination address: aa:aa:03:00:00:00 (aa:aa:03:00:00:00)
Source address: Concurre_00:00:54 (08:00:45:00:00:54)
MSDU length: 0x0000
[Packet size limited during capture: LLC truncated]
0000 44 00 00 00 90 00 00 00 61 74 68 33 00 00 00 00 D.......ath3....
0010 00 00 00 00 00 00 00 00 44 00 01 00 00 00 04 00 ........D.......
0020 c6 cf d9 02 44 00 02 00 00 00 04 00 fb 2a 12 2f ....D........*./
0030 44 00 03 00 00 00 04 00 05 00 00 00 44 00 04 00 D...........D...
0040 00 00 04 00 3b 00 00 00 00 00 00 00 00 00 00 00 ....;...........
0050 00 00 00 00 44 00 06 00 00 00 04 00 db ff ff ff ....D...........
0060 44 00 07 00 00 00 04 00 a0 ff ff ff 44 00 08 00 D...........D...
0070 00 00 04 00 02 00 00 00 44 00 09 00 00 00 04 00 ........D.......
0080 00 00 00 00 44 00 0a 00 00 00 04 00 7a 00 00 00 ....D.......z...
0090 88 0a 3a 01 00 15 2a fe b8 19 00 11 50 f4 c2 42 ..:...*.....P..B
00a0 00 11 50 f4 c2 42 e0 49 fc d5 aa aa 03 00 00 00 ..P..B.I........
00b0 08 00 45 00 00 54 00 00 40 00 40 01 a3 55 c0 a8 ..E..T..@[email protected]..
00c0 0b 01 c0 a8 0b 02 08 00 45 31 95 16 00 01 1d 40 ........E1.....@
00d0 d4 46 3b 2d 06 00 08 09 0a 0b 0c 0d 0e 0f 10 11 .F;-............
00e0 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 .............. !
00f0 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 "#$%&'()*+,-./01
0100 32 33 34 35 36 37 234567
On Tue, 2007-08-28 at 13:59 +0300, Kalle Valo wrote:
> I just have a fear that we don't endup in "udev-hell", that is
> incompatibility between kernel and hostapd versions. It was just awful
> with udev few years ago, let's try to avoid that. Official hostapd
> releases should work with all official kernel releases, without any
> exceptions.
Well, with mac80211 mainline kernels currently don't support AP mode at
all, and wireless-dev/hostapd are quite in lockstep. As soon as we merge
the AP mode stuff into mainline, however, it will be via nl80211 which
shall be a stable interface for that.
> > In any case, I'm fairly sure the TIM is just wrong, if you have a third
> > device you could try capturing the beacons and check that the TIM is
> > never updated.
>
> I will check that later and send the results here.
Thanks, I appreciate it.
johannes
(Sorry for sending twice, I accidentally sent the previous mail too
early.)
Johannes Berg <[email protected]> writes:
> On Tue, 2007-08-28 at 21:08 +0300, Kalle Valo wrote:
>
>> I hope you have time to investigate this, because I really would like
>> to have Nokia N800 and 770 working with b43 AP. So if you need more
>> testing, just ask.
>
> Can you disable QoS and see if the same weird frames show up again? b43
> doesn't really support QoS yet but I don't think that should be causing
> such frame corruption.
>From b43 or N800?
> Interestingly, your N800 seems to pick up the frames correctly since it
> did reply to the ping packets...
Yes, N800 managed to receive some ping packets from the laptop, but
the packet loss was high (at least 50%). It happened because the ARP
requests were not buffered and N800 could receive them occasionally
just by luck. When N800 replied to the request, it woke up from PSM
and b43 immediately sent all the buffered frames to N800.
N800 stays awake 200 ms (100 ms if display is off) after a transmitted
frame, so there's some time to receive packets at that time.
If added a static ARP entry (ip neigh change ... permanent), packet
loss was 100%.
> Did you have a capture size limit?
I think I didn't, but I have to recheck.
--
Kalle Valo
On Thu, 2007-08-16 at 08:43 +0300, Kalle Valo wrote:
> One thing which came to my mind is that when Nokia 770 is in PSM it
> uses PS-Poll to fetch the frames from AP.
Yeah, I noticed.
> Few devices do that, so I
> wonder if mac80211 supports that properly?
It should, as far as I can tell, but I haven't been able to quite
pinpoint it yet. I'll need to get a third device fully monitoring.
johannes
"Johannes Berg" <[email protected]> writes:
> On Thu, 2007-08-16 at 08:43 +0300, Kalle Valo wrote:
>
>> Few devices do that, so I
>> wonder if mac80211 supports that properly?
>
> It should, as far as I can tell, but I haven't been able to quite
> pinpoint it yet. I'll need to get a third device fully monitoring.
What driver are you using in? I tried b43 from wireless-dev this
morning and couldn't get my N800 to see it. I guess it wasn't sending
beacons, but I didn't have time to check that. I'll try again tonight.
Are there any tricks or should this be enough with b43:
iwconfig wlan0 mode master channel 2 essid mac80211
ip link set wlan0 up
--
Kalle Valo
On Wed, 2007-08-29 at 07:18 +0300, Kalle Valo wrote:
> > Can you disable QoS and see if the same weird frames show up again? b43
> > doesn't really support QoS yet but I don't think that should be causing
> > such frame corruption.
>
> From b43 or N800?
N800, I guess, if possible. But since you didn't do this yet you might
want to try the stuff I sent you first.
> > Interestingly, your N800 seems to pick up the frames correctly since it
> > did reply to the ping packets...
>
> Yes, N800 managed to receive some ping packets from the laptop
Yes, the odd thing however is that it replies to these mangled packets.
I would guess that's a bug in the QoS implementation on the N800.
johannes
Johannes Berg <[email protected]> writes:
>> But that's not all, also multicast frames (including ARP broadcast)
>> are not buffered correctly. They are sent randomly instead of directly
>> after a DTIM beacon. Also Multicast bit is not set and DTIM is always
>> zero even though DTIM period is two.
>
> Hm, yeah, I almost expected this, b43 hardware has some capabilities for
> this but we don't really know how to use it yet. We also need to upload
> the DTIM count to the hardware (shm somewhere)
I hope you have time to investigate this, because I really would like
to have Nokia N800 and 770 working with b43 AP. So if you need more
testing, just ask.
>> I also some really odd frames sent by b43 when N800 had PSM enabled.
>> Never seen it before, no idea what it is. Dump at the of this message.
>
> Could you send me a packet capture in pkt format via private mail?
Sent.
--
Kalle Valo