Re: [LARTC] ifb and ppp

Re: [LARTC] ifb and ppp

[Patrick McHardy]

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

Frithjof Hammer wrote:
> My goal is to setup an ingress traffic shaping on my PPPOE DSL line with ifb. 
> 
> My old imq stuff used iptables marks (like 'iptables -t mangle -A 
> PREROUTING -p tcp --sport 22 -m length --length :500 -j MARK --set-mark 31') 
> to classify the traffic and since i am lazy, i tried to to reuse them with 
> ifb. But no luck: iptables marks the packets well, but tc doesn't see the 
> marks on ifb0.
> 
> May be my problem is somewhere between ppp0 and ifb0, so for a basic test, I 
> tried this:
> 
> tc qdisc add dev ppp0 ingress
> modprobe ifb
> ip link set up dev ifb0
> tc filter add dev ppp0 parent ffff: protocol ip prio 10 u32 \
>    match u32 0 0 flowid 1:1 \
>    action mirred egress redirect dev ifb0
> 
> and run:
> 
> root@router:/# tcpdump -i ifb0 -n
> tcpdump: WARNING: ifb0: no IPv4 address assigned
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on ifb0, link-type EN10MB (Ethernet), capture size 96 bytes
> 12:38:29.584451 PPPoE  [ses 0x7dc] IP 217.10.79.2.10000 > 84.189.95.184.1024: 
> UDP, length 84
> 12:38:29.585924 PPPoE  [ses 0x7dc] IP 84.189.5.17 > 84.189.95.184: GREv1, call 
> 24388, seq 1868, ack 3210, length 205: compressed PPP data
> 12:38:29.600506 PPPoE  [ses 0x7dc] IP truncated-ip - 256 bytes missing! 
> 24.163.113.160.34247 > 84.189.95.184.9025: UDP, length 359
> [...]
> 
> Looks like the packetes are still pppoe en-capsuled. Is this the correct 
> behavior? This only occurs on ppp0, on other devices (like eth0) my iptables 
> marks are matched by tc. What can I do to get my iptables marks working on 
> ppp0 again?


Does this patch help?



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

diff --git a/net/sched/act_mirred.c b/net/sched/act_mirred.c
index 5795789..7c80f16 100644
--- a/net/sched/act_mirred.c
+++ b/net/sched/act_mirred.c
@@ -83,6 +83,7 @@ static int tcf_mirred_init(struct rtattr *rta, struct rtattr *est,
 			case ARPHRD_IPGRE:
 			case ARPHRD_VOID:
 			case ARPHRD_NONE:
+			case ARPHRD_PPP:
 				ok_push = 0;
 				break;
 			default:

Re: [LARTC] ifb and ppp

[Patrick McHardy]

Please keep netdev and myself CCed.

Frithjof Hammer wrote:
>>Does this patch help?
> 
> 
> A further examiniation:
> [...]
> printk ("fri: mein type %x\n",dev->type);
>                 switch (dev->type) {
> 
> [...]
> shows this:
> 
> root@router:/usr/src/linux-source-2.6.21# dmesg | grep fri
> fri: mein type 1
> 
> that is defined as ARPHRD_ETHER in include/linux/if_arp.h.
> 
> As far as i understand this means, that my ppp0 device is recognized as 
> Ethernetinterface.
> 
> Any further help/ideas?


I misread the code, the device it looks at in tcf_mirred_init is
the target device (ifb). So what it does is check whether the
target device wants a link layer header and if it does restores
the one from the source device. So currently it seems impossible
to get rid of the PPP(oE) header.

Jamal, is that how its supposed to work?

Re: [LARTC] ifb and ppp

[jamal]

On Thu, 2007-20-09 at 13:55 +0200, Patrick McHardy wrote:
> Please keep netdev and myself CCed.

and me too (I am way behind on netdev)

> Frithjof Hammer wrote:

> > Any further help/ideas?

Sorry, I didnt follow the thread - what is the goal to be achieved with
the setup?

> I misread the code, the device it looks at in tcf_mirred_init is
> the target device (ifb). So what it does is check whether the
> target device wants a link layer header and if it does restores
> the one from the source device. So currently it seems impossible
> to get rid of the PPP(oE) header.

It is tricky to redirect from devices that have disparity
in their view of link layer headers except for those that we know
dont expect anything. 

> Jamal, is that how its supposed to work?

Right - some netdevices on receipt will expect the link layer header.

cheers,
jamal

Re: ifb and ppp

[Frithjof Hammer]

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

> Sorry, I didnt follow the thread - what is the goal to be achieved with
> the setup?

A simple ingress shaping on ppp0 (PPPOE DSL line). I want to replace my old 
imq ingress shaper in favor of ifb. My former script used iptables marks  to 
classify the packets. My iptables marks are getting set, as like before with 
imq. But tc seems not to recognize them: It only uses the default class.

So i run tcpdump -i ifb0  and discovered that the packets seems to be still 
encapsulated on ifb0. I suppose this is why my iptables stuff is not working.

I've attached the ingress part of my shaping script. 

Thanks for your help
Frithjof

[-- Attachment #2: trafficshaping_ifb.sh.txt --]
[-- Type: text/plain, Size: 1947 bytes --]


 
tc qdisc del dev ppp0 root    2> /dev/null > /dev/null
tc qdisc del dev ifb0 root 2> /dev/null > /dev/null
tc qdisc del dev ppp0 ingress

 modprobe ifb
 ifconfig ifb0 up

 tc qdisc add dev ppp0 ingress
 tc filter add dev ppp0 parent ffff: protocol ip u32 match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0

 tc qdisc add dev ifb0 handle 1: root hfsc default 32
 tc class add dev ifb0 parent 1: classid 1:1 hfsc sc rate 6000kbit ul rate 6000kbit

 tc class add dev ifb0 parent 1:1 classid 1:30 hfsc rt umax 208b dmax 20ms rate 83kbit ls rate 120kbit
 tc class add dev ifb0 parent 1:1 classid 1:31 hfsc sc rate $[(6000-120)/3]kbit ul rate 6000kbit
 tc class add dev ifb0 parent 1:1 classid 1:32 hfsc sc rate $[(6000-120)/3*2]kbit ul rate  6000kbit

 tc qdisc add dev ifb0 parent 1:30 handle 30: sfq perturb 10
 tc qdisc add dev ifb0 parent 1:31 handle 31: sfq perturb 10
 tc qdisc add dev ifb0 parent 1:32 handle 32: red limit 1000000 min 5000 max 100000 avpkt 1000 burst 50

 tc filter add dev ifb0 parent 1:0 prio 0 protocol ip handle 30 fw flowid 1:30
 tc filter add dev ifb0 parent 1:0 prio 0 protocol ip handle 31 fw flowid 1:31
 tc filter add dev ifb0 parent 1:0 prio 0 protocol ip handle 32 fw flowid 1:32


 iptables -t mangle -N MYSHAPER-IN
 iptables -t mangle -I PREROUTING -i ppp0 -j MYSHAPER-IN

 iptables -t mangle -A MYSHAPER-IN -p tcp -m length --length :64 -j MARK --set-mark 31 # short TCP packets are probably ACKs
 iptables -t mangle -A MYSHAPER-IN -p tcp --dport 22 -m length --length :500 -j MARK --set-mark 3    # secure shell
 iptables -t mangle -A MYSHAPER-IN -p tcp --sport 22 -m length --length :500 -j MARK --set-mark 31    # secure shell
 iptables -t mangle -A MYSHAPER-IN -p ! tcp -j MARK --set-mark 31              # Set non-tcp packets to high priority
 iptables -t mangle -A MYSHAPER-IN -m mark --mark 0 -j MARK --set-mark 32              # redundant- mark any unmarked packets as 26 (low prio)

[...]

[-- Attachment #3: Type: text/plain, Size: 143 bytes --]

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

Re: [LARTC] ifb and ppp

[Patrick McHardy]

Frithjof Hammer wrote:
>>Sorry, I didnt follow the thread - what is the goal to be achieved with
>>the setup?
> 
> 
> A simple ingress shaping on ppp0 (PPPOE DSL line). I want to replace my old 
> imq ingress shaper in favor of ifb. My former script used iptables marks  to 
> classify the packets. My iptables marks are getting set, as like before with 
> imq. But tc seems not to recognize them: It only uses the default class.
> 
> So i run tcpdump -i ifb0  and discovered that the packets seems to be still 
> encapsulated on ifb0. I suppose this is why my iptables stuff is not working.


Thats actually a completely different problem. Unlike with imq, packets
are delivered to ifb *before* they pass through iptables. So at that
time they're not marked. I don't see a good solution for this that
allows to keep the iptables rules, I'd suggest to switch to ematches.

Re: [LARTC] ifb and ppp

[jamal]

On Thu, 2007-20-09 at 17:26 +0200, Patrick McHardy wrote:
>  I don't see a good solution for this that
> allows to keep the iptables rules, I'd suggest to switch to ematches.

One approach could be to use ipt action:

-------------------
tc filter add dev ppp0 parent ffff: protocol ip u32 match u32/ematch
some match flowid 1:1 action ipt -j mark --set-mark 1
..
...
....
iptables here to use the marks ...
----------------

cheers,
jamal

Re: [LARTC] ifb and ppp

[Patrick McHardy]

jamal wrote:
> On Thu, 2007-20-09 at 17:26 +0200, Patrick McHardy wrote:
> 
>> I don't see a good solution for this that
>>allows to keep the iptables rules, I'd suggest to switch to ematches.
> 
> 
> One approach could be to use ipt action:
> 
> -------------------
> tc filter add dev ppp0 parent ffff: protocol ip u32 match u32/ematch
> some match flowid 1:1 action ipt -j mark --set-mark 1
> ..
> ...
> ....
> iptables here to use the marks ...


This doesn't help much since he uses the iptables marks for
classification on the ifb device, so he might as well just
classify directly using u32. I think it would be nice to
have an ematch equivalent to the ipt action for matches.
Should be pretty easy to write (slightly above 60 seconds
according to the documentation :)).

Re: [LARTC] ifb and ppp

[jamal]

On Fri, 2007-21-09 at 13:56 +0200, Patrick McHardy wrote:

> This doesn't help much since he uses the iptables marks for
> classification on the ifb device, so he might as well just
> classify directly using u32. 

true.

> I think it would be nice to
> have an ematch equivalent to the ipt action for matches.

yes, that would help in his case.

> Should be pretty easy to write 
> (slightly above 60 seconds
> according to the documentation :)).

Ah, i hadnt paid attention to that before;-> I'd like to use
that whole thing on a tshirt.

cheers,
jamal