mac80211 AP mode powersaving problems?

mac80211 AP mode powersaving problems?

[Johannes Berg]

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

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

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

Re: mac80211 AP mode powersaving problems?

[Kalle Valo]

"Johannes Berg" <johannes@sipsolutions.net> 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

Re: mac80211 AP mode powersaving problems?

[Johannes Berg]

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

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

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

Re: mac80211 AP mode powersaving problems?

[Kalle Valo]

"Johannes Berg" <johannes@sipsolutions.net> 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

Re: mac80211 AP mode powersaving problems?

[Johannes Berg]

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

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

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

Re: mac80211 AP mode powersaving problems?

[Johannes Berg]

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

On Thu, 2007-08-16 at 09:41 -0700, Russell Senior wrote:

>   I have yet to see (maybe I am just blind), except for a very sparse
>   smattering of examples, a description of how mac80211 is intended to
>   be used.  I've never needed hostapd for master-mode before.  

That is, I expect, because you had a device that handled all that in
hardware/firmware. We now handle many MLME things in software, and have
pushed it out of the kernel into userspace.

>   I am
>   not even sure what it does.

It handles everything from association to encryption etc.

>   Is there somewhere I should be looking
>   for user-level documentation?

http://hostap.epitest.fi/hostapd/
But I think you need git version to compile against the current
wireless-dev 'everything' branch.

johannes

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

Re: mac80211 AP mode powersaving problems?

[Russell Senior]

>>>>> "Johannes" == Johannes Berg <johannes@sipsolutions.net> writes:

Russell> Is there somewhere I should be looking for user-level
Russell> documentation?

Johannes> http://hostap.epitest.fi/hostapd/ 

Sorry, I meant user-level documentation for using the mac80211 stuff,
not hostapd specifically.


-- 
Russell Senior         ``I have nine fingers; you have ten.''
seniorr@aracnet.com

Re: mac80211 AP mode powersaving problems?

[Johannes Berg]

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

On Thu, 2007-08-16 at 11:37 -0700, Russell Senior wrote:

> Sorry, I meant user-level documentation for using the mac80211 stuff,
> not hostapd specifically.

Oh. Well, I don't think there really is anything. But there isn't much
to know either, for WPA or AP mode you need wpa_supplicant or hostapd
respectively, and everything else should just work.

johannes

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

b43 vs. the TIM (was: mac80211 AP mode powersaving problems?)

[Johannes Berg]

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

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

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

Re: mac80211 AP mode powersaving problems?

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> 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

Re: mac80211 AP mode powersaving problems?

[Johannes Berg]

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

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

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

Re: mac80211 AP mode powersaving problems?

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> 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

Re: mac80211 AP mode powersaving problems?

[Johannes Berg]

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

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

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

Re: mac80211 AP mode powersaving problems?

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> 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

Re: mac80211 AP mode powersaving problems?

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> 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..@.@..U..
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

Re: mac80211 AP mode powersaving problems?

[Johannes Berg]

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

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

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

Re: mac80211 AP mode powersaving problems?

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> 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

Re: mac80211 AP mode powersaving problems?

[Johannes Berg]

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

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

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

Re: mac80211 AP mode powersaving problems?

[Johannes Berg]

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) {

Re: mac80211 AP mode powersaving problems?

[Johannes Berg]

[-- Attachment #1.1: Type: text/plain, Size: 2552 bytes --]

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

[-- Attachment #1.2: 055-b43-timb-position.patch --]
[-- Type: text/x-vhdl, Size: 1730 bytes --]

---
 drivers/net/wireless/b43/main.c |   12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

--- wireless-dev.orig/drivers/net/wireless/b43/main.c	2007-08-29 01:43:44.404618695 +0200
+++ wireless-dev/drivers/net/wireless/b43/main.c	2007-08-29 01:43:46.954618695 +0200
@@ -1180,6 +1180,7 @@ static void b43_write_beacon_template(st
 	len = min((size_t) dev->cached_beacon->len,
 		  0x200 - sizeof(struct b43_plcp_hdr6));
 	data = (const u8 *)(dev->cached_beacon->data);
+	printk(KERN_DEBUG "writing beacon\n");
 	b43_write_template_common(dev, data,
 				  len, ram_offset, shm_size_offset, rate);
 }
@@ -1242,6 +1243,13 @@ static u8 *b43_generate_probe_resp(struc
 			memcpy(dest_data + dest_pos, src_data + src_pos,
 			       elem_size);
 			dest_pos += elem_size;
+		} else {
+			printk(KERN_DEBUG "TIM is at 0x%x\n", dest_pos);
+			printk(KERN_DEBUG "DTIM period is %d\n", src_data[src_pos + 3]);
+			b43_shm_write16(dev, B43_SHM_SHARED,
+					B43_SHM_SH_TIMBPOS, dest_pos + 6 /* PLCP */);
+			b43_shm_write16(dev, B43_SHM_SHARED,
+					B43_SHM_SH_DTIMPER, src_data[src_pos + 3]);
 		}
 	}
 	*dest_size = dest_pos;
@@ -1371,12 +1379,12 @@ static void handle_irq_beacon(struct b43
 		return;
 	}
 	if (!(status & 0x1)) {
-		b43_write_beacon_template(dev, 0x68, 0x18, B43_CCK_RATE_1MB);
+//		b43_write_beacon_template(dev, 0x68, 0x18, B43_CCK_RATE_1MB);
 		status |= 0x1;
 		b43_write32(dev, B43_MMIO_STATUS2_BITFIELD, status);
 	}
 	if (!(status & 0x2)) {
-		b43_write_beacon_template(dev, 0x468, 0x1A, B43_CCK_RATE_1MB);
+//		b43_write_beacon_template(dev, 0x468, 0x1A, B43_CCK_RATE_1MB);
 		status |= 0x2;
 		b43_write32(dev, B43_MMIO_STATUS2_BITFIELD, status);
 	}

[-- Attachment #1.3: 057-b43-mcast.patch --]
[-- Type: text/x-vhdl, Size: 2307 bytes --]

---
 drivers/net/wireless/b43/dma.c  |   19 ++++++++++++++++---
 drivers/net/wireless/b43/xmit.c |   10 ++++++++++
 2 files changed, 26 insertions(+), 3 deletions(-)

--- wireless-dev.orig/drivers/net/wireless/b43/dma.c	2007-08-29 02:22:29.084618695 +0200
+++ wireless-dev/drivers/net/wireless/b43/dma.c	2007-08-29 02:45:38.574618695 +0200
@@ -1038,6 +1038,8 @@ static u16 generate_cookie(struct b43_dm
 	 * in the lower 12 bits.
 	 * Note that the cookie must never be 0, as this
 	 * is a special value used in RX path.
+	 * It can also not be 0xFFFF because that is special
+	 * for multicast frames.
 	 */
 	switch (ring->index) {
 	case 0:
@@ -1056,7 +1058,7 @@ static u16 generate_cookie(struct b43_dm
 		cookie = 0xE000;
 		break;
 	case 5:
-		cookie = 0xF000;
+		cookie = 0x9000;
 		break;
 	}
 	B43_WARN_ON(slot & ~0x0FFF);
@@ -1088,7 +1090,7 @@ struct b43_dmaring *parse_cookie(struct 
 	case 0xE000:
 		ring = dma->tx_ring4;
 		break;
-	case 0xF000:
+	case 0x9000:
 		ring = dma->tx_ring5;
 		break;
 	default:
@@ -1205,7 +1207,18 @@ int b43_dma_tx(struct b43_wldev *dev,
 	int err = 0;
 	unsigned long flags;
 
-	ring = priority_to_txring(dev, ctl->queue);
+	if (skb->len < 5) {
+		printk(KERN_ERR "really short frame\n");
+		return -EIO;
+	}
+
+	if (skb->data[4] & 1) {
+		ring = dev->dma.tx_ring4;
+		/* set more data bit, ucode will clear on the last frame */
+		skb->data[1] |= 0x20;
+	} else {
+		ring = priority_to_txring(dev, ctl->queue);
+	}
 	spin_lock_irqsave(&ring->lock, flags);
 	B43_WARN_ON(!ring->tx);
 	if (unlikely(free_slots(ring) < SLOTS_PER_PACKET)) {
--- wireless-dev.orig/drivers/net/wireless/b43/xmit.c	2007-08-29 02:39:53.884618695 +0200
+++ wireless-dev/drivers/net/wireless/b43/xmit.c	2007-08-29 02:47:34.304618695 +0200
@@ -195,6 +195,16 @@ static void generate_txhdr_fw4(struct b4
 	u16 phy_ctl = 0;
 	u8 extra_ft = 0;
 
+	/*
+	 * give microcode the cookie of the last frame in the multicast
+	 * queue so it can clear the more-data bit in it
+	 */
+	/* FIXME: should really check the queue or something */
+	if ((cookie & 0xF000) == 0x9000) {
+		/* FIXME: locking */
+		b43_shm_write16(dev, B43_SHM_SHARED, 0x54*2, cookie);
+	}
+
 	memset(txhdr, 0, sizeof(*txhdr));
 
 	rate = txctl->tx_rate;

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

Re: mac80211 AP mode powersaving problems?

[Kalle Valo]

(Sorry for sending twice, I accidentally sent the previous mail too
early.)

Johannes Berg <johannes@sipsolutions.net> 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

Re: mac80211 AP mode powersaving problems?

[Johannes Berg]

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

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

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

Re: mac80211 AP mode powersaving problems?

[Johannes Berg]

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

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

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

Re: mac80211 AP mode powersaving problems?

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> 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

Re: mac80211 AP mode powersaving problems?

[Kalle Valo]

Johannes Berg <johannes@sipsolutions.net> 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

Re: mac80211 AP mode powersaving problems?

[Michael Buesch]

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.

Re: mac80211 AP mode powersaving problems?

[Johannes Berg]

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

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

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

Re: mac80211 AP mode powersaving problems?

[Johannes Berg]

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


> 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

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

Re: mac80211 AP mode powersaving problems?

[Johannes Berg]

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

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

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