All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] Problems matching by mac address
@ 2006-04-04 17:54 Adam M. Towarnyckyj
  2006-04-04 22:15 ` Alexey Toptygin
                   ` (5 more replies)
  0 siblings, 6 replies; 7+ messages in thread
From: Adam M. Towarnyckyj @ 2006-04-04 17:54 UTC (permalink / raw)
  To: lartc

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

--===============1336715041==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C65810.D1897F3D"

This is a multi-part message in MIME format.

[-- Attachment #2: Type: text/plain, Size: 1773 bytes --]

Hey all,

 

            I recently read on a prior post as well as the FAQ that
packets can be limited by mac address using the u32 filter. I attempted
this and, while all the commands went through with no errors, it is not
limiting at all. I'm attempting to limit all IP traffic to a specific
destination mac address (00:12:3f:05:43:7f). Here is a quick rundown of
the commands I've used:

 

tc qdisc add dev eth1 root handle 1: prio

tc qdisc add dev eth1 parent 1:1 handle 11: pfifo

tc qdisc add dev eth1 parent 1:2 handle 12: htb

 

tc class add dev eth1 parent 12: classid 12:10 htb rate 128kbit

tc qdisc add dev eth1 parent 12:10 sfq quantum 1514 perturb 15

 

tc filter add dev eth1 protocol ip parent 12: prio 5 u32 match u16
0x0800 0xFFFF at -2 match u32 0x3f05437f 0xFFFFFF at -12 match u16
0x0012 0xFFFF at -14 flowid 12:10

 

eth1 is the outgoing interface on a bridge I have setup.

 

When I download a large file through the bridge, it is still showing
7Mbit on a 10Mbit network. The weird part is, everything limits just
fine if I change the filter to match by IP destination instead of mac
address destination. The only problem with this is that I require it be
done by mac address. The filter by ip I use is:

 

tc filter add dev eth1 protocol ip parent 12: prio 5 u32 match ip dst
xxx.xxx.xxx.xxx/32 flowid 12:10

 

Filtering by destination IP has worked for me for months now just fine.
The only problem is, I'm opening up DHCP to a pool and want to limit by
destination mac address since I can't be sure what IP someone is getting
without interaction with the dhcp lease file. Does anyone notice
anything I may be doing wrong? Your help would be much appreciated.
Thanks.

 

Adam


[-- Attachment #3: Type: text/html, Size: 5565 bytes --]

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

* Re: [LARTC] Problems matching by mac address
  2006-04-04 17:54 [LARTC] Problems matching by mac address Adam M. Towarnyckyj
@ 2006-04-04 22:15 ` Alexey Toptygin
  2006-04-07 21:06 ` Adam M. Towarnyckyj
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: Alexey Toptygin @ 2006-04-04 22:15 UTC (permalink / raw)
  To: lartc


On Tue, 4 Apr 2006, Adam M. Towarnyckyj wrote:

>            I recently read on a prior post as well as the FAQ that
> packets can be limited by mac address using the u32 filter. I attempted
> this and, while all the commands went through with no errors, it is not
> limiting at all. I'm attempting to limit all IP traffic to a specific
> destination mac address (00:12:3f:05:43:7f). Here is a quick rundown of
> the commands I've used:

Not sure that this will help, but

> tc qdisc add dev eth1 parent 1:2 handle 12: htb
> tc class add dev eth1 parent 12: classid 12:10 htb rate 128kbit

no ceil?

> tc filter add dev eth1 protocol ip parent 12: prio 5 u32 match u16
> 0x0800 0xFFFF at -2 match u32 0x3f05437f 0xFFFFFF at -12 match u16
> 0x0012 0xFFFF at -14 flowid 12:10

Shouldn't that be "match u32 0x3f05437f 0xFFFFFFFF at -12" (2 more Fs)

Also, what you sent didn't have any rules to classify from root down to 
12: so the above filter won't be consulted...

 			Alexey
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

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

* RE: [LARTC] Problems matching by mac address
  2006-04-04 17:54 [LARTC] Problems matching by mac address Adam M. Towarnyckyj
  2006-04-04 22:15 ` Alexey Toptygin
@ 2006-04-07 21:06 ` Adam M. Towarnyckyj
  2006-04-11 17:39 ` Adam M. Towarnyckyj
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: Adam M. Towarnyckyj @ 2006-04-07 21:06 UTC (permalink / raw)
  To: lartc

Hey Alexey,

Thanks for the input. I think that lack of two F's was a typo on my part
but I tried it anyways and it still does not work. I also added the ceil
to it with no luck.

I'm a bit confused on what you meant by not having any rules to classify
from root down to 12:. Can you elaborate or show me an example?

As I stated before, this is pretty much the exact setup I used when I
filtered by destination IP. The only thing I'm changing now is the
actual filter command. Everything else has been in place for a while.

Thanks.
Adam

-----Original Message-----
From: Alexey Toptygin [mailto:alexeyt@freeshell.org] 
Sent: Tuesday, April 04, 2006 3:15 PM
To: Adam M. Towarnyckyj
Cc: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] Problems matching by mac address


On Tue, 4 Apr 2006, Adam M. Towarnyckyj wrote:

>            I recently read on a prior post as well as the FAQ that
> packets can be limited by mac address using the u32 filter. I
attempted
> this and, while all the commands went through with no errors, it is
not
> limiting at all. I'm attempting to limit all IP traffic to a specific
> destination mac address (00:12:3f:05:43:7f). Here is a quick rundown
of
> the commands I've used:

Not sure that this will help, but

> tc qdisc add dev eth1 parent 1:2 handle 12: htb
> tc class add dev eth1 parent 12: classid 12:10 htb rate 128kbit

no ceil?

> tc filter add dev eth1 protocol ip parent 12: prio 5 u32 match u16
> 0x0800 0xFFFF at -2 match u32 0x3f05437f 0xFFFFFF at -12 match u16
> 0x0012 0xFFFF at -14 flowid 12:10

Shouldn't that be "match u32 0x3f05437f 0xFFFFFFFF at -12" (2 more Fs)

Also, what you sent didn't have any rules to classify from root down to 
12: so the above filter won't be consulted...

 			Alexey
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

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

* RE: [LARTC] Problems matching by mac address
  2006-04-04 17:54 [LARTC] Problems matching by mac address Adam M. Towarnyckyj
  2006-04-04 22:15 ` Alexey Toptygin
  2006-04-07 21:06 ` Adam M. Towarnyckyj
@ 2006-04-11 17:39 ` Adam M. Towarnyckyj
  2006-04-12 21:10 ` Andy Furniss
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: Adam M. Towarnyckyj @ 2006-04-11 17:39 UTC (permalink / raw)
  To: lartc

Sorry for bumping this one, but I wanted to know if anyone else had any
ideas as well. I'm a bit baffled as to why this isn't working. Thanks.

Adam

-----Original Message-----
From: lartc-bounces@mailman.ds9a.nl
[mailto:lartc-bounces@mailman.ds9a.nl] On Behalf Of Adam M. Towarnyckyj
Sent: Friday, April 07, 2006 2:06 PM
To: lartc@mailman.ds9a.nl
Subject: RE: [LARTC] Problems matching by mac address

Hey Alexey,

Thanks for the input. I think that lack of two F's was a typo on my part
but I tried it anyways and it still does not work. I also added the ceil
to it with no luck.

I'm a bit confused on what you meant by not having any rules to classify
from root down to 12:. Can you elaborate or show me an example?

As I stated before, this is pretty much the exact setup I used when I
filtered by destination IP. The only thing I'm changing now is the
actual filter command. Everything else has been in place for a while.

Thanks.
Adam

-----Original Message-----
From: Alexey Toptygin [mailto:alexeyt@freeshell.org] 
Sent: Tuesday, April 04, 2006 3:15 PM
To: Adam M. Towarnyckyj
Cc: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] Problems matching by mac address


On Tue, 4 Apr 2006, Adam M. Towarnyckyj wrote:

>            I recently read on a prior post as well as the FAQ that
> packets can be limited by mac address using the u32 filter. I
attempted
> this and, while all the commands went through with no errors, it is
not
> limiting at all. I'm attempting to limit all IP traffic to a specific
> destination mac address (00:12:3f:05:43:7f). Here is a quick rundown
of
> the commands I've used:

Not sure that this will help, but

> tc qdisc add dev eth1 parent 1:2 handle 12: htb
> tc class add dev eth1 parent 12: classid 12:10 htb rate 128kbit

no ceil?

> tc filter add dev eth1 protocol ip parent 12: prio 5 u32 match u16
> 0x0800 0xFFFF at -2 match u32 0x3f05437f 0xFFFFFF at -12 match u16
> 0x0012 0xFFFF at -14 flowid 12:10

Shouldn't that be "match u32 0x3f05437f 0xFFFFFFFF at -12" (2 more Fs)

Also, what you sent didn't have any rules to classify from root down to 
12: so the above filter won't be consulted...

 			Alexey
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

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

* Re: [LARTC] Problems matching by mac address
  2006-04-04 17:54 [LARTC] Problems matching by mac address Adam M. Towarnyckyj
                   ` (2 preceding siblings ...)
  2006-04-11 17:39 ` Adam M. Towarnyckyj
@ 2006-04-12 21:10 ` Andy Furniss
  2006-04-12 23:08 ` Adam M. Towarnyckyj
  2006-04-15 16:14 ` Andy Furniss
  5 siblings, 0 replies; 7+ messages in thread
From: Andy Furniss @ 2006-04-12 21:10 UTC (permalink / raw)
  To: lartc

Adam M. Towarnyckyj wrote:
> Sorry for bumping this one, but I wanted to know if anyone else had any
> ideas as well. I'm a bit baffled as to why this isn't working. Thanks.

Hmm this is a strange one - I tried both ip and mac version of your 
script (on non-bridged eth) and both "work" ie the traffic ends up in 
htb 12:10 and gets shaped. I tested with proftpd as sender - it's going 
to be important to test both with the same app that sets tos bits for 
prio - probably also worth putting a bfifo on 1:3 just for stats as 
default prio is three band.

Now what I don't get is in both cases if I do tc -s filter ls parent 
12:0 I don't get any matches, so would have expected them to have gone 
through htb as default - unshaped not 12:10 - strange.

Will have to think/try different kernel and tc versions.

Did you do both tests with the same tos bit setting sender app?

Alexey's point about filtering to 12:0 is because normally if you set up 
a tree structure for filters you need a filter rule on root to pass 
traffic down to child(ren) - prios automatic filtering seems to do it - 
but not as I expected.

Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

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

* RE: [LARTC] Problems matching by mac address
  2006-04-04 17:54 [LARTC] Problems matching by mac address Adam M. Towarnyckyj
                   ` (3 preceding siblings ...)
  2006-04-12 21:10 ` Andy Furniss
@ 2006-04-12 23:08 ` Adam M. Towarnyckyj
  2006-04-15 16:14 ` Andy Furniss
  5 siblings, 0 replies; 7+ messages in thread
From: Adam M. Towarnyckyj @ 2006-04-12 23:08 UTC (permalink / raw)
  To: lartc

Andy,

Thanks for investigating so extensively. However, I'm an idiot and made
a fundamental mistake in networking that I should have realized in the
first place. I completely didn't think about the fact that the filter is
looking at the data link layer of the packet and that this gets changed
through each device. The test machine is set up behind a router. Also,
to answer your question, I'm using a download test app on a web server I
set up, so I'm basically using the same program for testing the
throughput each time.

Sorry if I wasted anyone's time on this. With me, it's always something
obvious I missed and usually I don't realize until after I have
investigated every FAQ, Googled the hell out of the question, and posted
to a list.

If anyone has any ideas on how I can accomplish destination mac address
filtering through multiple hops, I'd love to hear them. Otherwise, I
think I'm going back to the drawing board on this one.

Adam

Interesting.... Outlook doesn't recognize "Googled" as a verb...

-----Original Message-----
From: Andy Furniss [mailto:andy.furniss@dsl.pipex.com]
Sent: Wednesday, April 12, 2006 2:11 PM
To: Adam M. Towarnyckyj
Cc: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] Problems matching by mac address

Adam M. Towarnyckyj wrote:
> Sorry for bumping this one, but I wanted to know if anyone else had
any
> ideas as well. I'm a bit baffled as to why this isn't working. Thanks.

Hmm this is a strange one - I tried both ip and mac version of your 
script (on non-bridged eth) and both "work" ie the traffic ends up in 
htb 12:10 and gets shaped. I tested with proftpd as sender - it's going 
to be important to test both with the same app that sets tos bits for 
prio - probably also worth putting a bfifo on 1:3 just for stats as 
default prio is three band.

Now what I don't get is in both cases if I do tc -s filter ls parent 
12:0 I don't get any matches, so would have expected them to have gone 
through htb as default - unshaped not 12:10 - strange.

Will have to think/try different kernel and tc versions.

Did you do both tests with the same tos bit setting sender app?

Alexey's point about filtering to 12:0 is because normally if you set up

a tree structure for filters you need a filter rule on root to pass 
traffic down to child(ren) - prios automatic filtering seems to do it - 
but not as I expected.

Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

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

* Re: [LARTC] Problems matching by mac address
  2006-04-04 17:54 [LARTC] Problems matching by mac address Adam M. Towarnyckyj
                   ` (4 preceding siblings ...)
  2006-04-12 23:08 ` Adam M. Towarnyckyj
@ 2006-04-15 16:14 ` Andy Furniss
  5 siblings, 0 replies; 7+ messages in thread
From: Andy Furniss @ 2006-04-15 16:14 UTC (permalink / raw)
  To: lartc

Adam M. Towarnyckyj wrote:
> Andy,
> 
> Thanks for investigating so extensively. However, I'm an idiot and made
> a fundamental mistake in networking that I should have realized in the
> first place. I completely didn't think about the fact that the filter is
> looking at the data link layer of the packet and that this gets changed
> through each device. The test machine is set up behind a router. Also,
> to answer your question, I'm using a download test app on a web server I
> set up, so I'm basically using the same program for testing the
> throughput each time.
> 
> Sorry if I wasted anyone's time on this. With me, it's always something
> obvious I missed and usually I don't realize until after I have
> investigated every FAQ, Googled the hell out of the question, and posted
> to a list.

No problem - I don't know how to solve your new problem.

I retried the test on a 2.6.15 with tc 051107 and the counters are OK 
now when I tc -s filter ls dev eth0 parent 12:0.

One thing - I always considered the match 0x0800 0xFFFF at -2 to be 
redundant if you say protocol ip in the filter - so I ended up using the 
following, which I think is a bit easier to read with mac of target 
machine 00:C1:26:0F:04:AD.

tc filter add dev eth0 protocol ip parent 12: prio 1 u32 \
match u16 0x00c1 0xffff at -14 \
match u32 0x260f04ad 0xffffffff at -12 \
flowid 12:10

Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

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

end of thread, other threads:[~2006-04-15 16:14 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-04-04 17:54 [LARTC] Problems matching by mac address Adam M. Towarnyckyj
2006-04-04 22:15 ` Alexey Toptygin
2006-04-07 21:06 ` Adam M. Towarnyckyj
2006-04-11 17:39 ` Adam M. Towarnyckyj
2006-04-12 21:10 ` Andy Furniss
2006-04-12 23:08 ` Adam M. Towarnyckyj
2006-04-15 16:14 ` Andy Furniss

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.