FYI
Problem found with cls_u32.c ...
Bert has asked me to forward this to this address so it can be taken care
of.
Thanks,
Eric April
-----Original Message-----
From: April, Eric (Satnet)
Sent: Thursday, January 12, 2006 4:25 PM
To: '[EMAIL PROTECTED]'
Subject: RE: tc filter
Hello Bert,
Finally, I had to debug the problem in cls_u32.c and found what was causing
me the trouble.
In the u32_classify function, there was the following which was compiled for
me
100 static int u32_classify(struct sk_buff *skb, struct tcf_proto *tp,
struct tcf_result *res)
101 {
102 struct {
103 struct tc_u_knode *knode;
104 u8 *ptr;
105 } stack[TC_U32_MAXDEPTH];
106
107 struct tc_u_hnode *ht = (struct tc_u_hnode*)tp->root;
108 u8 *ptr = skb->nh.raw;
109 struct tc_u_knode *n;
110 int sdepth = 0;
111 int off2 = 0;
112 int sel = 0;
113 int i;
114
115 #if !defined(__i386__) && !defined(__mc68000__)
116 if ((unsigned long)ptr & 3)
117 return -1;
118 #endif
I had to comment this #if statement because, in my case, on sat0, this
pointer is offset by 14 bytes because of the ethernet header since the
interface is IP. With this modification, the u32 classifier also works on
my sat0 interface.
I noticed that this #if was removed in 2.4.28 and 2.6.x. However, it would
be nice to document this problem somewhere for somebody else running into
the same problem in versions 2.4.18/20.
Thanks again for your help.
Best regards,
Eric
-----Original Message-----
From: April, Eric (Satnet)
Sent: Wednesday, January 11, 2006 5:40 PM
To: '[EMAIL PROTECTED]'; April, Eric (Satnet)
Subject: RE: tc filter
Thanks for the quick answer.
I ran tcpdump on sat0 interface and I got the following:
~ # Warning: arptype 65535 not supported by libpcap - falling back to cooked
socket
tcpdump: listening on sat0
Could an unsupported arptype be the reason tc filter is not working as
expected? I initialize my interface sat0 with type
dev->type = ARPHRD_VOID;
which is 0xFFFF. I do not see which other one would better apply from the
file if_arp.h.
Anyhow, I could still get the traces. Here they are:
~ # 00:11:06.878047 192.168.20.75 > 192.168.230.90: icmp: echo request (ttl
127, id 21494, len 60)
00:11:06.953003 192.168.230.90 > 192.168.20.75: icmp: echo reply (ttl 128,
id 18399, len 60)
00:11:07.878502 192.168.20.75 > 192.168.230.90: icmp: echo request (ttl 127,
id 21498, len 60)
00:11:07.932731 192.168.230.90 > 192.168.20.75: icmp: echo reply (ttl 128,
id 18655, len 60)
00:11:08.878553 192.168.20.75 > 192.168.230.90: icmp: echo request (ttl 127,
id 21501, len 60)
00:11:08.940482 192.168.230.90 > 192.168.20.75: icmp: echo reply (ttl 128,
id 18911, len 60)
00:11:09.879582 192.168.20.75 > 192.168.230.90: icmp: echo request (ttl 127,
id 21504, len 60)
00:11:09.946738 192.168.230.90 > 192.168.20.75: icmp: echo reply (ttl 128,
id 19167, len 60)
~ # tc -s -d class show dev sat0
class htb 1:1 root prio 0 quantum 1280 rate 100Kbit ceil 100Kbit burst
1728b/8 mpu 0b cburst 1728b/8 mpu 0b level 0
Sent 240 bytes 4 pkts (dropped 0, overlimits 0)
rate 5bps
lended: 4 borrowed: 0 giants: 0
tokens: 107008 ctokens: 107008
class htb 1:2 root prio 0 quantum 1000 rate 50Kbit ceil 50Kbit burst 1664b/8
mpu 0b cburst 1664b/8 mpu 0b level 0
Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
lended: 0 borrowed: 0 giants: 0
tokens: 212992 ctokens: 212992
~ #
~ # tc filter show dev sat0
filter parent 1: protocol ip pref 49152 u32
filter parent 1: protocol ip pref 49152 u32 fh 800: ht divisor 1
filter parent 1: protocol ip pref 49152 u32 fh 800::800 order 2048 key ht
800 bkt 0 flowid 1:2
match c0a8e65a/ffffffff at 16
~ #
Everything seems fine to me except that the packets go in the wrong classid.
Any ideas what the problem is?
Unfortunately, I was not able to run iptables with --set-mark argument.
~ # /mnt/rfs/sbin/iptables -A POSTROUTING -o sat0 -p icmp -j MARK --set-mark
6
iptables v1.2.6a: Unknown arg `--set-mark'
Try `iptables -h' or 'iptables --help' for more information.
Which version do I need? In any case, I would rather try to make tc filter
u32 classifier work first if at all possible.
-----Original Message-----
From: bert hubert [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 10, 2006 6:46 PM
To: April, Eric (Satnet)
Cc: '[EMAIL PROTECTED]'
Subject: Re: tc filter
On Tue, Jan 10, 2006 at 06:33:24PM -0500, April, Eric (Satnet) wrote:
> Hello Mr Bert Hubert,
>
> I would really appreciate if you could help me out with this problem.
Eric,
Could you run 'tcpdump -n -i eth0 -v -v icmp' and 'tcpdump -n -i sat0 -v -v
icmp'
both during pining?
This would answer two questions:
1) are the ip addresses right when they go out on the line
2) it sat0 might have some odd encapsulation that makes tc miss the
ip header
Another solution would be to use iptables to set the classid as described on
lartc.org:
On fwmark
You can mark packets with either ipchains or iptables and have that mark
survive routing across interfaces. This is really useful to for example only
shape traffic on eth1 that came in on eth0. Syntax:
# tc filter add dev eth1 protocol ip parent 1:0 prio 1 handle 6 fw flowid
1:1
Note that this is not a u32 match!
You can place a mark like this:
# iptables -A PREROUTING -t mangle -i eth0 -j MARK --set-mark 6
The number 6 is arbitrary.
See: http://lartc.org/howto/lartc.qdisc.filters.html#LARTC.FILTERING.SIMPLE
In your case you'd use POSTROUTING -o sat0 icmp -j MARK --set-mark 6 etc
Let me know if this works.
>
> I have been trying for many days now to resolve the issue but I cannot
find
> what is causing the problem.
> Basically, I can setup a filter using tc tool on an ethernet interface
> network device (eth0) to direct the packet to a specific classid but I
> cannot have the data to go anywhere else than the default on my other
> interface (sat0 -- packets forwarded to that interface are IP).
>
> To start with, here is my ifconfig info on the target router (runs linux
> 2.4.18 - embedded Linux Timesys version but I patched it to add HTB qdisc
> (3.6) and upgraded tc tool binary accordingly):
>
> eth0 Link encap:Ethernet HWaddr 00:40:FD:01:EF:9D
> inet addr:192.168.20.241 Bcast:192.168.20.255
Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:7614 errors:0 dropped:0 overruns:0 frame:0
> TX packets:613 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:5195521 (4.9 MiB) TX bytes:90254 (88.1 KiB)
> Interrupt:9 Base address:0xffe0
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MTU:16436 Metric:1
> RX packets:5 errors:0 dropped:0 overruns:0 frame:0
> TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:538 (538.0 B) TX bytes:538 (538.0 B)
>
> sat0 Link encap:UNSPEC HWaddr
> 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
> inet addr:172.16.0.101 Bcast:172.16.255.255
Mask:255.255.255.255
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
> Base address:0xffe0
>
> My tc settings configured on eth0 (this is my local interface on which my
> host PC (192.168.20.75) is connected to):
>
> tc qdisc del dev eth0 root 2> /dev/null > /dev/null
> tc qdisc add dev eth0 root handle 1:0 htb default 1
> tc class add dev eth0 parent 1: classid 1:1 htb rate 100kbit ceil 100kbit
> tc class add dev eth0 parent 1: classid 1:2 htb rate 50kbit ceil 50kbit
> tc filter add dev eth0 parent 1: protocol ip u32 \
> match ip dst 192.168.20.75 classid 1:2
>
> My tc settings configured on sat0 (this is my remote interface to which I
am
> pinging a PC (192.168.230.90)):
>
> tc qdisc del dev sat0 root 2> /dev/null > /dev/null
> tc qdisc add dev sat0 root handle 1:0 htb default 1
> tc class add dev sat0 parent 1: classid 1:1 htb rate 100kbit ceil 100kbit
> tc class add dev sat0 parent 1: classid 1:2 htb rate 50kbit ceil 100kbit
> tc filter add dev sat0 protocol ip parent 1: u32 \
> match ip dst 192.168.230.90 classid 1:2
>
> If I ping from my host PC the remote PC:
> --------------------------------------------------------------------------
> H:\>ping 192.168.230.90
>
> Pinging 192.168.230.90 with 32 bytes of data:
>
> Reply from 192.168.230.90: bytes=32 time=90ms TTL=127
> Reply from 192.168.230.90: bytes=32 time=77ms TTL=127
> Reply from 192.168.230.90: bytes=32 time=56ms TTL=127
> Reply from 192.168.230.90: bytes=32 time=63ms TTL=127
>
> Ping statistics for 192.168.230.90:
> Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
> Approximate round trip times in milli-seconds:
> Minimum = 56ms, Maximum = 90ms, Average = 71ms
>
----------------------------------------------------------------------------
> -
> then I see the following on my target router using
> ~ # tc -s -d class show dev eth0
> class htb 1:1 root prio 0 quantum 1280 rate 100Kbit ceil 100Kbit burst
> 1728b/8 mpu 0b cburst 1728b/8 mpu 0b level 0
> Sent 84 bytes 2 pkts (dropped 0, overlimits 0)
> lended: 2 borrowed: 0 giants: 0
> tokens: 108032 ctokens: 108032
>
> class htb 1:2 root prio 0 quantum 1000 rate 50Kbit ceil 50Kbit burst
1664b/8
> mpu 0b cburst 1664b/8 mpu 0b level 0
> Sent 296 bytes 4 pkts (dropped 0, overlimits 0)
> lended: 4 borrowed: 0 giants: 0
> tokens: 203776 ctokens: 203776
>
> which shows that the ping coming back are going via classid 1:2. That is
> what is expected. However, on the sat0 interface, here is what I have:
>
> ~ # tc -s -d class show dev sat0
> class htb 1:1 root prio 0 quantum 1280 rate 100Kbit ceil 100Kbit burst
> 1728b/8 mpu 0b cburst 1728b/8 mpu 0b level 0
> Sent 240 bytes 4 pkts (dropped 0, overlimits 0)
> lended: 4 borrowed: 0 giants: 0
> tokens: 107008 ctokens: 107008
>
> class htb 1:2 root prio 0 quantum 1000 rate 50Kbit ceil 100Kbit burst
> 1664b/8 mpu 0b cburst 1728b/8 mpu 0b level 0
> Sent 0 bytes 0 pkts (dropped 0, overlimits 0)
> lended: 0 borrowed: 0 giants: 0
> tokens: 212992 ctokens: 110592
>
> which shows that the ping sent out to sat0 is all going via classid 1:1,
the
> default, instead of classid 1:2 as it should be since it should match the
> destination IP address 192.168.230.90.
>
> ~ # tc filter show dev sat0
> filter parent 1: protocol ip pref 49152 u32
> filter parent 1: protocol ip pref 49152 u32 fh 800: ht divisor 1
> filter parent 1: protocol ip pref 49152 u32 fh 800::800 order 2048 key ht
> 800 bkt 0 flowid 1:2
> match c0a8e65a/ffffffff at 16
>
> Do you have any idea what could be my problem and if there is a solution?
>
> Eric
>
>
> !DSPAM:43c4445c223803607523816!
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://netherlabs.nl Open and Closed source services
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
