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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Jun 30, 2009 at 3:53 AM, Valentin Manea<[email protected]> 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
On Tue, Jul 7, 2009 at 7:48 AM, John W. Linville<[email protected]> 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
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<[email protected]> wrote:
>>
>> On 06/30/2009 07:20 PM, Luis R. Rodriguez wrote:
>>> On Tue, Jun 30, 2009 at 3:53 AM, Valentin Manea<[email protected]>
>>> 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
On 07/07/2009 07:15 PM, Luis R. Rodriguez wrote:
> On Tue, Jul 7, 2009 at 7:48 AM, John W. Linville<[email protected]> 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
On Wed, Jul 8, 2009 at 5:57 AM, John W. Linville<[email protected]> 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<[email protected]> 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
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<[email protected]> wrote:
>>>
>>> On 06/30/2009 07:20 PM, Luis R. Rodriguez wrote:
>>>> On Tue, Jun 30, 2009 at 3:53 AM, Valentin Manea<[email protected]>
>>>> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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<[email protected]> 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
[email protected] might be all we have. Be ready.
?Viva Honduras Libre!
On Tue, Jun 30, 2009 at 11:42 PM, Valentin Manea<[email protected]> wrote:
>
>
> On 06/30/2009 07:20 PM, Luis R. Rodriguez wrote:
>>
>> On Tue, Jun 30, 2009 at 3:53 AM, Valentin Manea<[email protected]>
>> 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
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.
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
[email protected] might be all we have. Be ready.
?Viva Honduras Libre!
On 06/30/2009 07:20 PM, Luis R. Rodriguez wrote:
> On Tue, Jun 30, 2009 at 3:53 AM, Valentin Manea<[email protected]> 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