All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] mac80211: Fix frame classification in AP mode for relayed frames
@ 2011-12-19 10:02 Helmut Schaa
  2011-12-19 15:55 ` Johannes Berg
  0 siblings, 1 reply; 7+ messages in thread
From: Helmut Schaa @ 2011-12-19 10:02 UTC (permalink / raw)
  To: linux-wireless; +Cc: linville, johannes, Helmut Schaa

When mac80211 relays a frame from STA1 to STA2 in AP mode it will get
re-classified in the tx path. Unfortunately the frame protocol field
is always set to ETH_P_8023 while the classification only kicks in
for ETH_P_IP. Hence, a high priority frame from STA1 will be send to
STA2 as best effort.

To allow proper re-classification of received frames, set the
skb->protocol field to the correct value without using eth_type_trans
as that would pull of the ethernet header. Also, set the network
header position correctly as otherwise the classification code won't
find the IP header.

This means that every frame relayed by a mac80211 AP will be
re-classified and might change its traffic class when the associated
STA and mac80211 use different 802.1d <-> TID mappings.

Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
---

We could also reuse the TID used by the source STA but I guess we should
always classify frames according to our own mapping instead of relying
on the associated STAs to do the right thing.

 net/mac80211/rx.c |   19 ++++++++++++++++---
 1 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index bf07d08..8418f66 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1827,10 +1827,23 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
 	}
 
 	if (xmit_skb) {
-		/* send to wireless media */
-		xmit_skb->protocol = htons(ETH_P_802_3);
-		skb_reset_network_header(xmit_skb);
+		/*
+		 * Send to wireless media
+		 *
+		 * Set protocol field according to the ethernet header
+		 * to allow reclassification of this frame in the tx path.
+		 *
+		 * Don't use eth_type_trans here since it will pull the
+		 * eth header and because we are sure to have an ethernet
+		 * header here.
+		 */
+		ehdr = (struct ethhdr *) xmit_skb->data;
+		if (ntohs(ehdr->h_proto) >= 1536)
+			xmit_skb->protocol = ehdr->h_proto;
+		else
+			xmit_skb->protocol = htons(ETH_P_802_3);
 		skb_reset_mac_header(xmit_skb);
+		skb_set_network_header(xmit_skb, sizeof(struct ethhdr));
 		dev_queue_xmit(xmit_skb);
 	}
 }
-- 
1.7.7


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] mac80211: Fix frame classification in AP mode for relayed frames
  2011-12-19 10:02 [PATCH] mac80211: Fix frame classification in AP mode for relayed frames Helmut Schaa
@ 2011-12-19 15:55 ` Johannes Berg
  2011-12-19 16:36   ` Helmut Schaa
  0 siblings, 1 reply; 7+ messages in thread
From: Johannes Berg @ 2011-12-19 15:55 UTC (permalink / raw)
  To: Helmut Schaa; +Cc: linux-wireless, linville

On Mon, 2011-12-19 at 11:02 +0100, Helmut Schaa wrote:
> When mac80211 relays a frame from STA1 to STA2 in AP mode it will get
> re-classified in the tx path. Unfortunately the frame protocol field
> is always set to ETH_P_8023 while the classification only kicks in
> for ETH_P_IP. Hence, a high priority frame from STA1 will be send to
> STA2 as best effort.
> 
> To allow proper re-classification of received frames, set the
> skb->protocol field to the correct value without using eth_type_trans
> as that would pull of the ethernet header. Also, set the network
> header position correctly as otherwise the classification code won't
> find the IP header.
> 
> This means that every frame relayed by a mac80211 AP will be
> re-classified and might change its traffic class when the associated
> STA and mac80211 use different 802.1d <-> TID mappings.
> 
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
> ---
> 
> We could also reuse the TID used by the source STA but I guess we should
> always classify frames according to our own mapping instead of relying
> on the associated STAs to do the right thing.

Not sure that's useful, since we classify almost nothing anyway. If this
was somehow hooked up to tc or iptables that would be more useful I
guess?

johannes


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] mac80211: Fix frame classification in AP mode for relayed frames
  2011-12-19 15:55 ` Johannes Berg
@ 2011-12-19 16:36   ` Helmut Schaa
  2011-12-19 16:41     ` Johannes Berg
  0 siblings, 1 reply; 7+ messages in thread
From: Helmut Schaa @ 2011-12-19 16:36 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless, linville

On Mon, Dec 19, 2011 at 4:55 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2011-12-19 at 11:02 +0100, Helmut Schaa wrote:
>> When mac80211 relays a frame from STA1 to STA2 in AP mode it will get
>> re-classified in the tx path. Unfortunately the frame protocol field
>> is always set to ETH_P_8023 while the classification only kicks in
>> for ETH_P_IP. Hence, a high priority frame from STA1 will be send to
>> STA2 as best effort.
>>
>> To allow proper re-classification of received frames, set the
>> skb->protocol field to the correct value without using eth_type_trans
>> as that would pull of the ethernet header. Also, set the network
>> header position correctly as otherwise the classification code won't
>> find the IP header.
>>
>> This means that every frame relayed by a mac80211 AP will be
>> re-classified and might change its traffic class when the associated
>> STA and mac80211 use different 802.1d <-> TID mappings.
>>
>> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
>> ---
>>
>> We could also reuse the TID used by the source STA but I guess we should
>> always classify frames according to our own mapping instead of relying
>> on the associated STAs to do the right thing.
>
> Not sure that's useful, since we classify almost nothing anyway.

Currently we only use the IPv4 DSCP field for assigning TIDs to
frames. That seems to be sufficient for VOIP traffic at least.

> If this was somehow hooked up to tc or iptables that would be
> more useful I guess?

Agreed. This would make sense in the future but I don't feel like
implementing this right now.

So, you'd prefer to just copy over the TID as used by the source
STA (via the priority+256 hack maybe)?

Helmut

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] mac80211: Fix frame classification in AP mode for relayed frames
  2011-12-19 16:36   ` Helmut Schaa
@ 2011-12-19 16:41     ` Johannes Berg
  2011-12-20  8:37       ` Helmut Schaa
  0 siblings, 1 reply; 7+ messages in thread
From: Johannes Berg @ 2011-12-19 16:41 UTC (permalink / raw)
  To: Helmut Schaa; +Cc: linux-wireless, linville

On Mon, 2011-12-19 at 17:36 +0100, Helmut Schaa wrote:

> >> We could also reuse the TID used by the source STA but I guess we should
> >> always classify frames according to our own mapping instead of relying
> >> on the associated STAs to do the right thing.
> >
> > Not sure that's useful, since we classify almost nothing anyway.
> 
> Currently we only use the IPv4 DSCP field for assigning TIDs to
> frames. That seems to be sufficient for VOIP traffic at least.
> 
> > If this was somehow hooked up to tc or iptables that would be
> > more useful I guess?
> 
> Agreed. This would make sense in the future but I don't feel like
> implementing this right now.
> 
> So, you'd prefer to just copy over the TID as used by the source
> STA (via the priority+256 hack maybe)?

Seems simpler to me really, at least right now and as default. Not sure,
maybe other people have more opinion? :)

I just don't expect anyone to hack the kernel for their local policy,
and using what the STA wanted seems OK? If you run wifi networks you
kinda trust them already anyway :)

johannes


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] mac80211: Fix frame classification in AP mode for relayed frames
  2011-12-19 16:41     ` Johannes Berg
@ 2011-12-20  8:37       ` Helmut Schaa
  2011-12-21  8:12         ` Helmut Schaa
  0 siblings, 1 reply; 7+ messages in thread
From: Helmut Schaa @ 2011-12-20  8:37 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless, linville

On Mon, Dec 19, 2011 at 5:41 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Mon, 2011-12-19 at 17:36 +0100, Helmut Schaa wrote:
>
>> >> We could also reuse the TID used by the source STA but I guess we should
>> >> always classify frames according to our own mapping instead of relying
>> >> on the associated STAs to do the right thing.
>> >
>> > Not sure that's useful, since we classify almost nothing anyway.
>>
>> Currently we only use the IPv4 DSCP field for assigning TIDs to
>> frames. That seems to be sufficient for VOIP traffic at least.
>>
>> > If this was somehow hooked up to tc or iptables that would be
>> > more useful I guess?
>>
>> Agreed. This would make sense in the future but I don't feel like
>> implementing this right now.
>>
>> So, you'd prefer to just copy over the TID as used by the source
>> STA (via the priority+256 hack maybe)?
>
> Seems simpler to me really, at least right now and as default. Not sure,
> maybe other people have more opinion? :)
>
> I just don't expect anyone to hack the kernel for their local policy,
> and using what the STA wanted seems OK? If you run wifi networks you
> kinda trust them already anyway :)

Fine with me. I'll change the patch to keep the priority the STA used ...
Helmut

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] mac80211: Fix frame classification in AP mode for relayed frames
  2011-12-20  8:37       ` Helmut Schaa
@ 2011-12-21  8:12         ` Helmut Schaa
  2011-12-21  8:50           ` Dave Taht
  0 siblings, 1 reply; 7+ messages in thread
From: Helmut Schaa @ 2011-12-21  8:12 UTC (permalink / raw)
  To: Johannes Berg; +Cc: linux-wireless, linville

On Tue, Dec 20, 2011 at 9:37 AM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
>>> So, you'd prefer to just copy over the TID as used by the source
>>> STA (via the priority+256 hack maybe)?
>>
>> Seems simpler to me really, at least right now and as default. Not sure,
>> maybe other people have more opinion? :)
>>
>> I just don't expect anyone to hack the kernel for their local policy,
>> and using what the STA wanted seems OK? If you run wifi networks you
>> kinda trust them already anyway :)
>
> Fine with me. I'll change the patch to keep the priority the STA used ...

Done. John, you can drop this one.

Thanks,
Helmut

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] mac80211: Fix frame classification in AP mode for relayed frames
  2011-12-21  8:12         ` Helmut Schaa
@ 2011-12-21  8:50           ` Dave Taht
  0 siblings, 0 replies; 7+ messages in thread
From: Dave Taht @ 2011-12-21  8:50 UTC (permalink / raw)
  To: Helmut Schaa; +Cc: Johannes Berg, linux-wireless, linville

On Wed, Dec 21, 2011 at 9:12 AM, Helmut Schaa
<helmut.schaa@googlemail.com> wrote:
> On Tue, Dec 20, 2011 at 9:37 AM, Helmut Schaa
> <helmut.schaa@googlemail.com> wrote:
>>>> So, you'd prefer to just copy over the TID as used by the source
>>>> STA (via the priority+256 hack maybe)?
>>>
>>> Seems simpler to me really, at least right now and as default. Not sure,
>>> maybe other people have more opinion? :)

Seeing this patch go by triggered me posting one of the patches I've
been using in cerowrt, which should appear on linux-wireless
as soon as the greylister gets done with me.

I think that much more extensive classification of wireless traffic is
highly desirable. In particular, tossing stuff with the TOS interactive bit
set into VI helps ssh traffic enormously.

It's the magic number hack that bugs me.


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2011-12-21  8:50 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-19 10:02 [PATCH] mac80211: Fix frame classification in AP mode for relayed frames Helmut Schaa
2011-12-19 15:55 ` Johannes Berg
2011-12-19 16:36   ` Helmut Schaa
2011-12-19 16:41     ` Johannes Berg
2011-12-20  8:37       ` Helmut Schaa
2011-12-21  8:12         ` Helmut Schaa
2011-12-21  8:50           ` Dave Taht

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.