Re: [LARTC] quantum

2005-12-12 Thread Pau Oliva - pof
Hi,

I usually use this as a rule of thumb:

quantum = rate(in bytes)/r2q

Note that quantum should be  MTU (normally 1500).


Best regards,

  Pau Oliva


---
http://pof.eslack.org/blog/


On Mon, December 12, 2005 7:32, sujeet mulmi said:
 Dear all,

  I'm   new to traffic shapping although i have gone through marking
 and HTB queueing but i felt trouble in tc filter . I wonder if any
 one give me the hints about quantum or r2q.
i guess quantum is used when two class has same prio and rate and want
 to give first priority  between them and control the borrowing traffic.
 It should be set more than MTU too. But my question is that how can we
 set quantum exactly , i mean is there any calculation need to set this
 quantum parameter and its effect to r2q . Any changes we have to do in
 r2q parameter.

   Any suggestion will be apprieciated.

   thanks in advance.

   sujeet


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


Re: [LARTC] Marking packets by mac addr using tc filter u32 match?

2005-12-12 Thread Kristiadi Himawan


It's also match to this kind of traffic ?

17:16:53.740978 arp who-has 192.43.165.29 tell 192.43.165.30
17:16:53.752482 arp reply 192.43.165.29 is-at 00:04:c1:b5:bd:f1
17:16:53.812889 arp who-has 192.43.162.194 tell 192.43.162.193
17:16:53.812922 arp reply 192.43.162.194 is-at 00:08:c7:c9:a3:17


Lee Sanders wrote:


You haven't done a search on past posts...

the u32 can be used to match any bit in the ip header. Before the ip header, 
there is a frame header. In that frame header you can find the src and dst 
mac address. You can trick the u32 filter in using the frame header if you 
use negative offsets.


Decimal Offset  Description
-14:DST MAC, 6 bytes
-8: SRC MAC, 6 bytes
-2: Eth PROTO, 2 bytes, eg. ETH_P_IP
0:  Protocol header (IP Header)

Where  is the Eth Proto Code (from linux/include/linux/if_ether.h): 
ETH_P_IP= IP = match u16 0x0800

Where your MAC = M0M1M2M3M4M5

Egress (match Dst MAC):
... match u16 0x 0x at -2 match u32 0xM2M3M4M5 0x at -12 match 
u16 0xM0M1 0x at -14


Ingress (match Src MAC):
... match u16 0x 0x at -2 match u16 0xM4M5 0x at -4 match u32 
0xM0M1M2M3 0x at -8


The below is simplistic but it works to demonstrate the above.

tc qdisc add dev ppp0 root handle 1:0 htb default 20
tc class add dev ppp0 parent 1:0 classid 1:1 htb rate 128kbit ceil 128kbit

tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 64kbit ceil 128kbit
tc class add dev ppp0 parent 1:1 classid 1:20 htb rate 64kbit ceil 128kbit

tc qdisc add dev ppp0 parent 1:10 handle 100: sfq perturb 10
tc qdisc add dev ppp0 parent 1:20 handle 200: sfq perturb 10

# My Laptop
tc filter add dev ppp0 parent 1:0 protocol ip prio 1 u32 match u16 0x0800 
0x at -2 match u16 0xM4M5 0x at -4 match u32 0xM0M1M2M3  0x 
at -8 flowid 1:10

# My Desktop
tc filter add dev ppp0 parent 1:0 protocol ip prio 1 u32 match u16 0x0800 
0x at -2 match u16 0xM4M5 0x at -4 match u32 0xM0M1M2M3  0x 
at -8 flowid 1:20

# change the MAC's of course.

tc -s -d class show dev ppp0
tc -s -d qdisc show dev ppp0
tc -s -d filter show dev ppp0

There you have it.

:L
___
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


Re: [LARTC] quantum

2005-12-12 Thread Pau Oliva - pof
This page explains the quantum  r2q values used in HTB in depth:
   http://www.docum.org/docum.org/faq/cache/31.html

If you want to see my working example download this script:
   http://pof.eslack.org/archives/files/bw-shaper1.2.sh
results achieved can be seen here:
   http://pof.eslack.org/graphs/
...any commments appreciated ;)

Regards,

  Pau Oliva


On Mon, December 12, 2005 12:09, sujeet mulmi said:
 thanks pal.

i got the clue but i get confused in rates whether it should be the
 total b/w or rate seperate for class id.
   can you give me some hints on r2q too.

 Pau Oliva - pof [EMAIL PROTECTED] wrote:
   Hi,

 I usually use this as a rule of thumb:

 quantum = rate(in bytes)/r2q

 Note that quantum should be  MTU (normally 1500).


 Best regards,

 Pau Oliva


 ---
 http://pof.eslack.org/blog/


 On Mon, December 12, 2005 7:32, sujeet mulmi said:
 Dear all,

 I'm new to traffic shapping although i have gone through marking
 and HTB queueing but i felt trouble in tc filter . I wonder if any
 one give me the hints about quantum or r2q.
 i guess quantum is used when two class has same prio and rate and want
 to give first priority between them and control the borrowing traffic.
 It should be set more than MTU too. But my question is that how can we
 set quantum exactly , i mean is there any calculation need to set this
 quantum parameter and its effect to r2q . Any changes we have to do in
 r2q parameter.

 Any suggestion will be apprieciated.

 thanks in advance.

 sujeet


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


Re: [LARTC] Marking packets by mac addr using tc filter u32 match?

2005-12-12 Thread gypsy
Kristiadi Himawan wrote:
 
 It's also match to this kind of traffic ?
 
 17:16:53.740978 arp who-has 192.43.165.29 tell 192.43.165.30
 17:16:53.752482 arp reply 192.43.165.29 is-at 00:04:c1:b5:bd:f1
 17:16:53.812889 arp who-has 192.43.162.194 tell 192.43.162.193
 17:16:53.812922 arp reply 192.43.162.194 is-at 00:08:c7:c9:a3:17

No.  The 'match u16 0x0800 0x' says to ignore ARP.

 Lee Sanders wrote:
 
 You haven't done a search on past posts...
 
 the u32 can be used to match any bit in the ip header. Before the ip header,
 there is a frame header. In that frame header you can find the src and dst
 mac address. You can trick the u32 filter in using the frame header if you
 use negative offsets.
 
 Decimal Offset  Description
 -14:DST MAC, 6 bytes
 -8: SRC MAC, 6 bytes
 -2: Eth PROTO, 2 bytes, eg. ETH_P_IP
 0:  Protocol header (IP Header)
 
 Where  is the Eth Proto Code (from linux/include/linux/if_ether.h):
 ETH_P_IP= IP = match u16 0x0800
 Where your MAC = M0M1M2M3M4M5
 
 Egress (match Dst MAC):
 ... match u16 0x 0x at -2 match u32 0xM2M3M4M5 0x at -12 
 match
 u16 0xM0M1 0x at -14
 
 Ingress (match Src MAC):
 ... match u16 0x 0x at -2 match u16 0xM4M5 0x at -4 match u32
 0xM0M1M2M3 0x at -8
 
 The below is simplistic but it works to demonstrate the above.
 
 tc qdisc add dev ppp0 root handle 1:0 htb default 20
 tc class add dev ppp0 parent 1:0 classid 1:1 htb rate 128kbit ceil 128kbit
 
 tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 64kbit ceil 128kbit
 tc class add dev ppp0 parent 1:1 classid 1:20 htb rate 64kbit ceil 128kbit
 
 tc qdisc add dev ppp0 parent 1:10 handle 100: sfq perturb 10
 tc qdisc add dev ppp0 parent 1:20 handle 200: sfq perturb 10
 
 # My Laptop
 tc filter add dev ppp0 parent 1:0 protocol ip prio 1 u32 match u16 0x0800
 0x at -2 match u16 0xM4M5 0x at -4 match u32 0xM0M1M2M3  0x
 at -8 flowid 1:10
 # My Desktop
 tc filter add dev ppp0 parent 1:0 protocol ip prio 1 u32 match u16 0x0800
 0x at -2 match u16 0xM4M5 0x at -4 match u32 0xM0M1M2M3  0x
 at -8 flowid 1:20
 # change the MAC's of course.
 
 tc -s -d class show dev ppp0
 tc -s -d qdisc show dev ppp0
 tc -s -d filter show dev ppp0
 
 There you have it.
 
 :L
 ___
 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
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Re: [LARTC] UDP multicast stream and NAT

2005-12-12 Thread Gabriel
On Mon, 12 Dec 2005 04:08:54 +0200, Andy Furniss
[EMAIL PROTECTED] wrote:

 Andy Furniss wrote:
 Gabriel wrote:

 Hi, my ISP is streaming some local concert using UDP
 multicasting. I followed the instructions on the site
which
 described how to set VLC in order to view the stream,
but
 it didn't work. I am behind a Linux router/firewall
doing
 NAT. Using google, I quickly found out that the
 netfilter/conntrack code doesn't support NATing
multicast
 traffic. I thought about bridging the internet facing
 interface (eth0) and (one of) the internal interfaces
(the
 one my computer is plugged into). This way I could set
my
 IP to be public and no routing/NAT would be done on the
 Linux box. The only problem is that the box has 2 more
NICs
 in it and there are other people connected to those
NICs
 that need to use that connection (hence need to be
NATed).

 Then I tried thinking about a DMZ-like solution where
my
 box would be in the DMZ, but I can't see that working
 either because I only have one public IP assigned.

 Can anyone think of any other way for me to be able to
view
 the stream?

 Thanks.


 I also don't think the bridging will work.

 AIUI stateless NAT using ip doesn't work with 2.6
kernels so thinking
 about iptables only.

 Maybe you could get something working with the raw
table, you can bypass
 conntrack with that but then I am not sure if you could
dnat it ...

 There is another iptables target ROUTE maybe you could
use that. If the
 LAN PC is running Linux then you could setup a
vlan/tunnel/something and
 ROUTE it down there.

 I would also ask this on the netfilter users list.

 Anothe thought - I would tcpdump on the internet
interface and check if
 you can see multicast traffic.

 If you can then try making a normal dnat rule something
like -

 iptables -I PREROUTING -t nat -i ppp0 --src 224.0.0.0/4
-j DNAT --to
 192.168.0.3

 I don't think my isp does multicast - so I have never
tried to get it to
 work and haven't got a clue really :-)

 Andy.

I am familiar with only some of the iptables features
(ROUTE not included :) ), so I'll have to read about that.
I also don't know the details of how multicast works, but,
from what I've seen, there is an initial IGMP packet (a
Membership Report packet according to Ethereal) that,
theoretically, I would  still need to NAT. From there on,
the UDP multicast stream is one way only (but the incoming
stream would need to somehow be forwarded to my computer).

I have to say that I can't see this working without NATting
and if multicast traffic can not be NATed, then...

I also found out the TTL of the initial multicast packet
was 1, so I issued -j TTL --ttl-inc 1 on the router to
increment it. On the LAN facing interface, they would still
appear with the TTL=1 (according to tcpdump), so I guess
the incrementation is done sometime after tcpdump sees the
packet. Still, the packet did not show up on the internet
interface.

Then, I manually added a route to 224.0.0.0/4 through eth0
(internet facing NIC), it still didn't work. I also tried
to compile mrouted, but I got some errors (it's kinda old,
I think it was designed for 2.2 kernels), so I got stuck.

In the end, I managed to see the stream by plugging my
desktop PC directly into the cable modem. :))


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
___
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc


Re: [LARTC] Marking packets by mac addr using tc filter u32 match?

2005-12-12 Thread Kristiadi Himawan


it's should be 0x0806 0x ?
or you have the example how to catch that kind of traffic

gypsy wrote:


Kristiadi Himawan wrote:
 


It's also match to this kind of traffic ?

17:16:53.740978 arp who-has 192.43.165.29 tell 192.43.165.30
17:16:53.752482 arp reply 192.43.165.29 is-at 00:04:c1:b5:bd:f1
17:16:53.812889 arp who-has 192.43.162.194 tell 192.43.162.193
17:16:53.812922 arp reply 192.43.162.194 is-at 00:08:c7:c9:a3:17
   



No.  The 'match u16 0x0800 0x' says to ignore ARP.

 


Lee Sanders wrote:

   


You haven't done a search on past posts...

the u32 can be used to match any bit in the ip header. Before the ip header,
there is a frame header. In that frame header you can find the src and dst
mac address. You can trick the u32 filter in using the frame header if you
use negative offsets.

Decimal Offset  Description
-14:DST MAC, 6 bytes
-8: SRC MAC, 6 bytes
-2: Eth PROTO, 2 bytes, eg. ETH_P_IP
0:  Protocol header (IP Header)

Where  is the Eth Proto Code (from linux/include/linux/if_ether.h):
ETH_P_IP= IP = match u16 0x0800
Where your MAC = M0M1M2M3M4M5

Egress (match Dst MAC):
... match u16 0x 0x at -2 match u32 0xM2M3M4M5 0x at -12 match
u16 0xM0M1 0x at -14

Ingress (match Src MAC):
... match u16 0x 0x at -2 match u16 0xM4M5 0x at -4 match u32
0xM0M1M2M3 0x at -8

The below is simplistic but it works to demonstrate the above.

tc qdisc add dev ppp0 root handle 1:0 htb default 20
tc class add dev ppp0 parent 1:0 classid 1:1 htb rate 128kbit ceil 128kbit

tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 64kbit ceil 128kbit
tc class add dev ppp0 parent 1:1 classid 1:20 htb rate 64kbit ceil 128kbit

tc qdisc add dev ppp0 parent 1:10 handle 100: sfq perturb 10
tc qdisc add dev ppp0 parent 1:20 handle 200: sfq perturb 10

# My Laptop
tc filter add dev ppp0 parent 1:0 protocol ip prio 1 u32 match u16 0x0800
0x at -2 match u16 0xM4M5 0x at -4 match u32 0xM0M1M2M3  0x
at -8 flowid 1:10
# My Desktop
tc filter add dev ppp0 parent 1:0 protocol ip prio 1 u32 match u16 0x0800
0x at -2 match u16 0xM4M5 0x at -4 match u32 0xM0M1M2M3  0x
at -8 flowid 1:20
# change the MAC's of course.

tc -s -d class show dev ppp0
tc -s -d qdisc show dev ppp0
tc -s -d filter show dev ppp0

There you have it.

:L
___
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
   




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


[LARTC] MARK: targinfosize 8 != 4

2005-12-12 Thread Salim
Hello all,
   I got this problem while trying to shape traffic with iptables MARK and
HTB.

MARK: targinfosize 8 != 4

--set-mark gives invalid argument error message.

Kernel version is 2.4.29 (some patches from patch o matic applied)
Iptables version 1.3.4

Intel x86 architecture.

I saw this problem discussed in a few places, but the discussions didn't
come to a conclusion or solution.

please help...

thanks
Salim


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