mac80211 and broadcast frames

mac80211 and broadcast frames

[Valentin Manea]

Hi,

    I've been working on a small project that basically sends broadcast 
UDP frames from an Wireless AP to multiple clients. While I can send UDP 
frames just fine from the AP to the client the only a few broadcast 
frames reach my client. What is really puzzling is that on the client 
machine using tcpdump I can see all the broadcast frames arriving, my 
application sees only a small fraction of them.

* I have suspected some bug in the application, but the same app using 
the same computers works fine when using wired ethernet.
* I have used both 2.6.30 and the latest wireless-testing kernels, the 
results are the same
* I have used the latest hostapd in AP mode
* I did the same tests in ad-hoc mode, the results are the same
* I used both atheros and intel wireless cards, the problem is not 
related to the wireless drivers.

Any ideea what I'm doing wrong?


Thanks,
Valentin

Re: mac80211 and broadcast frames

[Valentin Manea]

Hello Again,

    I have been studying the network statistics for this problem and 
they don't really make sense to me, if I bombard the wireless device 
with broadcast packets *RX packets* in ifconfig increases very fast but 
*RX bytes* does not. However when I'm doing the same thing over the 
wired device both of them increase very fast.
    This doesn't really make sense to me, I don't understand where those 
packets are going exactly.

Thanks,
Valentin

On 06/30/2009 01:53 PM, Valentin Manea wrote:
> Hi,
>
>    I've been working on a small project that basically sends broadcast 
> UDP frames from an Wireless AP to multiple clients. While I can send 
> UDP frames just fine from the AP to the client the only a few 
> broadcast frames reach my client. What is really puzzling is that on 
> the client machine using tcpdump I can see all the broadcast frames 
> arriving, my application sees only a small fraction of them.
>
> * I have suspected some bug in the application, but the same app using 
> the same computers works fine when using wired ethernet.
> * I have used both 2.6.30 and the latest wireless-testing kernels, the 
> results are the same
> * I have used the latest hostapd in AP mode
> * I did the same tests in ad-hoc mode, the results are the same
> * I used both atheros and intel wireless cards, the problem is not 
> related to the wireless drivers.
>
> Any ideea what I'm doing wrong?
>
>
> Thanks,
> Valentin
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mac80211 and broadcast frames

[Luis R. Rodriguez]

On Tue, Jun 30, 2009 at 3:53 AM, Valentin Manea<linux-wireless@mrs.ro> wrote:
> Hi,
>
>   I've been working on a small project that basically sends broadcast UDP
> frames from an Wireless AP to multiple clients. While I can send UDP frames
> just fine from the AP to the client the only a few broadcast frames reach my
> client. What is really puzzling is that on the client machine using tcpdump
> I can see all the broadcast frames arriving, my application sees only a
> small fraction of them.

Keep in mind when you use tcpdump it will modify the RX filters of the
device you use but if you say you see them on tcpdump and at the same
time do not see them on the application that seems fishy and non
driver related.

  Luis

Re: mac80211 and broadcast frames

[Valentin Manea]

On 06/30/2009 07:20 PM, Luis R. Rodriguez wrote:
> On Tue, Jun 30, 2009 at 3:53 AM, Valentin Manea<linux-wireless@mrs.ro>  wrote:
>> Hi,
>>
>>    I've been working on a small project that basically sends broadcast UDP
>> frames from an Wireless AP to multiple clients. While I can send UDP frames
>> just fine from the AP to the client the only a few broadcast frames reach my
>> client. What is really puzzling is that on the client machine using tcpdump
>> I can see all the broadcast frames arriving, my application sees only a
>> small fraction of them.
>
> Keep in mind when you use tcpdump it will modify the RX filters of the
> device you use but if you say you see them on tcpdump and at the same
> time do not see them on the application that seems fishy and non
> driver related.
>
>    Luis

tcpdump doesn't affect the results at all, with or without it running 
it's the same.

I have tried tracing the packets, I thought that maybe there is a 
problem in the 80211 stack and for some reason they would be dropped but 
as far as I can tell every packet is routed to the ip stack with the 
correct protocol and pkt_type.

One more strange thing, if I'm looking at netstat -s everything seems to 
be normal, InBcastPkts is fine, also the number of incomming UDP packets.

Any ideas where I could look? it just gets stranger and stranger.


Thanks,
Valentin

who can share 802.11s draft

[Angela]

Hi all,

who can share me 802.11s  draft?? thanks!

2009-07-01 
Angela 

Re: mac80211 and broadcast frames

[Luis R. Rodriguez]

On Tue, Jun 30, 2009 at 11:42 PM, Valentin Manea<linux-wireless@mrs.ro> wrote:
>
>
> On 06/30/2009 07:20 PM, Luis R. Rodriguez wrote:
>>
>> On Tue, Jun 30, 2009 at 3:53 AM, Valentin Manea<linux-wireless@mrs.ro>
>>  wrote:
>>>
>>> Hi,
>>>
>>>   I've been working on a small project that basically sends broadcast UDP
>>> frames from an Wireless AP to multiple clients. While I can send UDP
>>> frames
>>> just fine from the AP to the client the only a few broadcast frames reach
>>> my
>>> client. What is really puzzling is that on the client machine using
>>> tcpdump
>>> I can see all the broadcast frames arriving, my application sees only a
>>> small fraction of them.
>>
>> Keep in mind when you use tcpdump it will modify the RX filters of the
>> device you use but if you say you see them on tcpdump and at the same
>> time do not see them on the application that seems fishy and non
>> driver related.
>>
>>   Luis
>
> tcpdump doesn't affect the results at all, with or without it running it's
> the same.

Well it would if you had had other nodes sending data on the same BSS,
it would mean more RX'd frames that are passed up on your host. This
would just be specific to your BSS as you would be using promiscuous
mode and not a real monitor mode, so just wanted to point that out.

> I have tried tracing the packets, I thought that maybe there is a problem in
> the 80211 stack and for some reason they would be dropped but as far as I
> can tell every packet is routed to the ip stack with the correct protocol
> and pkt_type.

OK  then the issue is further down and not related to the driver or
wireless stack it seems.

> One more strange thing, if I'm looking at netstat -s everything seems to be
> normal, InBcastPkts is fine, also the number of incomming UDP packets.

More confirmation things are peachy on the linux-wireless front and
that this is a userspace issue somewhere.

> Any ideas where I could look? it just gets stranger and stranger.

If you see the frames do get to the host then definitely not on the
drivers / stack.

  Luis

Re: mac80211 and broadcast frames

[Valentin Manea]

Hi,

   I've tracked this problem down and to my shame the problem was on the 
sending side, it seems that when sending broadcast/multicast frames the 
sending side chooses the lowest bit rate possible. Is this how it is 
supposed to behave?

Best Regards,
Valentin

On 07/01/2009 08:33 PM, Luis R. Rodriguez wrote:
> On Tue, Jun 30, 2009 at 11:42 PM, Valentin Manea<linux-wireless@mrs.ro>  wrote:
>>
>> On 06/30/2009 07:20 PM, Luis R. Rodriguez wrote:
>>> On Tue, Jun 30, 2009 at 3:53 AM, Valentin Manea<linux-wireless@mrs.ro>
>>>   wrote:
>>>> Hi,
>>>>
>>>>    I've been working on a small project that basically sends broadcast UDP
>>>> frames from an Wireless AP to multiple clients. While I can send UDP
>>>> frames
>>>> just fine from the AP to the client the only a few broadcast frames reach
>>>> my
>>>> client. What is really puzzling is that on the client machine using
>>>> tcpdump
>>>> I can see all the broadcast frames arriving, my application sees only a
>>>> small fraction of them.
>>> Keep in mind when you use tcpdump it will modify the RX filters of the
>>> device you use but if you say you see them on tcpdump and at the same
>>> time do not see them on the application that seems fishy and non
>>> driver related.
>>>
>>>    Luis
>> tcpdump doesn't affect the results at all, with or without it running it's
>> the same.
>
> Well it would if you had had other nodes sending data on the same BSS,
> it would mean more RX'd frames that are passed up on your host. This
> would just be specific to your BSS as you would be using promiscuous
> mode and not a real monitor mode, so just wanted to point that out.
>
>> I have tried tracing the packets, I thought that maybe there is a problem in
>> the 80211 stack and for some reason they would be dropped but as far as I
>> can tell every packet is routed to the ip stack with the correct protocol
>> and pkt_type.
>
> OK  then the issue is further down and not related to the driver or
> wireless stack it seems.
>
>> One more strange thing, if I'm looking at netstat -s everything seems to be
>> normal, InBcastPkts is fine, also the number of incomming UDP packets.
>
> More confirmation things are peachy on the linux-wireless front and
> that this is a userspace issue somewhere.
>
>> Any ideas where I could look? it just gets stranger and stranger.
>
> If you see the frames do get to the host then definitely not on the
> drivers / stack.
>
>    Luis

Re: mac80211 and broadcast frames

[David Ross]

Actually it is required to be a mutual BASIC rate (not extended rates) - 
not necessarily the "lowest possible" - David.

Valentin Manea wrote:
> Hi,
>
>   I've tracked this problem down and to my shame the problem was on 
> the sending side, it seems that when sending broadcast/multicast 
> frames the sending side chooses the lowest bit rate possible. Is this 
> how it is supposed to behave?
>
> Best Regards,
> Valentin
>
> On 07/01/2009 08:33 PM, Luis R. Rodriguez wrote:
>> On Tue, Jun 30, 2009 at 11:42 PM, Valentin 
>> Manea<linux-wireless@mrs.ro>  wrote:
>>>
>>> On 06/30/2009 07:20 PM, Luis R. Rodriguez wrote:
>>>> On Tue, Jun 30, 2009 at 3:53 AM, Valentin Manea<linux-wireless@mrs.ro>
>>>>   wrote:
>>>>> Hi,
>>>>>
>>>>>    I've been working on a small project that basically sends 
>>>>> broadcast UDP
>>>>> frames from an Wireless AP to multiple clients. While I can send UDP
>>>>> frames
>>>>> just fine from the AP to the client the only a few broadcast 
>>>>> frames reach
>>>>> my
>>>>> client. What is really puzzling is that on the client machine using
>>>>> tcpdump
>>>>> I can see all the broadcast frames arriving, my application sees 
>>>>> only a
>>>>> small fraction of them.
>>>> Keep in mind when you use tcpdump it will modify the RX filters of the
>>>> device you use but if you say you see them on tcpdump and at the same
>>>> time do not see them on the application that seems fishy and non
>>>> driver related.
>>>>
>>>>    Luis
>>> tcpdump doesn't affect the results at all, with or without it 
>>> running it's
>>> the same.
>>
>> Well it would if you had had other nodes sending data on the same BSS,
>> it would mean more RX'd frames that are passed up on your host. This
>> would just be specific to your BSS as you would be using promiscuous
>> mode and not a real monitor mode, so just wanted to point that out.
>>
>>> I have tried tracing the packets, I thought that maybe there is a 
>>> problem in
>>> the 80211 stack and for some reason they would be dropped but as far 
>>> as I
>>> can tell every packet is routed to the ip stack with the correct 
>>> protocol
>>> and pkt_type.
>>
>> OK  then the issue is further down and not related to the driver or
>> wireless stack it seems.
>>
>>> One more strange thing, if I'm looking at netstat -s everything 
>>> seems to be
>>> normal, InBcastPkts is fine, also the number of incomming UDP packets.
>>
>> More confirmation things are peachy on the linux-wireless front and
>> that this is a userspace issue somewhere.
>>
>>> Any ideas where I could look? it just gets stranger and stranger.
>>
>> If you see the frames do get to the host then definitely not on the
>> drivers / stack.
>>
>>    Luis
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mac80211 and broadcast frames

[John W. Linville]

On Tue, Jul 07, 2009 at 09:10:52PM +1000, David Ross wrote:
> Actually it is required to be a mutual BASIC rate (not extended rates) -  
> not necessarily the "lowest possible" - David.

True, but FWIW I think all of our rate scaling algorithms choose the
lowest rate.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.
			¡Viva Honduras Libre!

Re: mac80211 and broadcast frames

[Luis R. Rodriguez]

On Tue, Jul 7, 2009 at 7:48 AM, John W. Linville<linville@tuxdriver.com> wrote:
> On Tue, Jul 07, 2009 at 09:10:52PM +1000, David Ross wrote:
>> Actually it is required to be a mutual BASIC rate (not extended rates) -
>> not necessarily the "lowest possible" - David.
>
> True, but FWIW I think all of our rate scaling algorithms choose the
> lowest rate.

And then iwlwifi and ath9k have their own rate control algo, and at
least ath9k uses the lowest valid rate IIRC.

  Luis

Re: mac80211 and broadcast frames

[Valentin Manea]

On 07/07/2009 07:15 PM, Luis R. Rodriguez wrote:
> On Tue, Jul 7, 2009 at 7:48 AM, John W. Linville<linville@tuxdriver.com>  wrote:
>> On Tue, Jul 07, 2009 at 09:10:52PM +1000, David Ross wrote:
>>> Actually it is required to be a mutual BASIC rate (not extended rates) -
>>> not necessarily the "lowest possible" - David.
>> True, but FWIW I think all of our rate scaling algorithms choose the
>> lowest rate.
>
> And then iwlwifi and ath9k have their own rate control algo, and at
> least ath9k uses the lowest valid rate IIRC.
>
>    Luis


   I've found the code in ath9k and you are right, it always chooses the 
lowest rate.
   So, basically to transmit multicast frames at a better bitrate I have 
to hack the rate control algorithm, right?


Thanks,
Valentin

Re: mac80211 and broadcast frames

[David Ross]

Valentin Manea wrote:
>   I've found the code in ath9k and you are right, it always chooses 
> the lowest rate.
>   So, basically to transmit multicast frames at a better bitrate I 
> have to hack the rate control algorithm, right?
>
> Thanks,
> Valentin
If you want to still be an 802.11 device then you may only use one of 
the basic rates, no extended rates, viz:
"All frames with multicast and broadcast in the Address 1 field that 
have a UP of zero shall be transmitted at one of the rates included in 
the BSSBasicRateSet parameter, regardless of their type or subtype." 
(from the 2007 edition of the standard).

- David Ross.

Re: mac80211 and broadcast frames

[John W. Linville]

On Wed, Jul 08, 2009 at 10:30:29AM +0300, Valentin Manea wrote:
>
>
> On 07/07/2009 07:15 PM, Luis R. Rodriguez wrote:
>> On Tue, Jul 7, 2009 at 7:48 AM, John W. Linville<linville@tuxdriver.com>  wrote:
>>> On Tue, Jul 07, 2009 at 09:10:52PM +1000, David Ross wrote:
>>>> Actually it is required to be a mutual BASIC rate (not extended rates) -
>>>> not necessarily the "lowest possible" - David.
>>> True, but FWIW I think all of our rate scaling algorithms choose the
>>> lowest rate.
>>
>> And then iwlwifi and ath9k have their own rate control algo, and at
>> least ath9k uses the lowest valid rate IIRC.
>>
>>    Luis
>
>
>   I've found the code in ath9k and you are right, it always chooses the  
> lowest rate.
>   So, basically to transmit multicast frames at a better bitrate I have  
> to hack the rate control algorithm, right?

Yes.  Feel free to suggest patches for all of the available (i.e. both
generic and device-dependent) algorithms as well.

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.
			¡Viva Honduras Libre!

Re: mac80211 and broadcast frames

[Luis R. Rodriguez]

On Wed, Jul 8, 2009 at 5:57 AM, John W. Linville<linville@tuxdriver.com> wrote:
> On Wed, Jul 08, 2009 at 10:30:29AM +0300, Valentin Manea wrote:
>>
>>
>> On 07/07/2009 07:15 PM, Luis R. Rodriguez wrote:
>>> On Tue, Jul 7, 2009 at 7:48 AM, John W. Linville<linville@tuxdriver.com>  wrote:
>>>> On Tue, Jul 07, 2009 at 09:10:52PM +1000, David Ross wrote:
>>>>> Actually it is required to be a mutual BASIC rate (not extended rates) -
>>>>> not necessarily the "lowest possible" - David.
>>>> True, but FWIW I think all of our rate scaling algorithms choose the
>>>> lowest rate.
>>>
>>> And then iwlwifi and ath9k have their own rate control algo, and at
>>> least ath9k uses the lowest valid rate IIRC.
>>>
>>>    Luis
>>
>>
>>   I've found the code in ath9k and you are right, it always chooses the
>> lowest rate.
>>   So, basically to transmit multicast frames at a better bitrate I have
>> to hack the rate control algorithm, right?
>
> Yes.  Feel free to suggest patches for all of the available (i.e. both
> generic and device-dependent) algorithms as well.

BTW all this code is very generic between all drivers right now. The
rate control patches I sent a while back generalize all this and add
*one helper* routine which is used by all drivers for figuring the
rate for broadcasts. Once those patches are applied you can then just
focus on improving that one helper and then *every* driver will
benefit from your work.

The reason for this being a common helper instead of just embedded
directly into mac80211 was that in the future some rate control
algorithms may want to user higher rates for broadcast later. If there
is a way to make this generic and still use a higher rate the generic
helper can be extended. If rate control algorithms disagree with that
implementation or want to change it they can simply drop the helper
and implement their own solution.

  Luis