Hello! 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? my system is a debian etch with kernel from backports, newer iptables and newer iproute2: root@router:~# uname -a Linux router 2.6.21-2-k7 #1 SMP Fri Jul 13 16:18:53 UTC 2007 i686 GNU/Linux root@router:~# iptables -V iptables v1.3.8 root@router:~# tc -V tc utility, iproute2-ss070710 Thanks in advance. Frithjof
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?
> Does this patch help?No, it doesn''t. :-( I''ve put in some printk statements to check, if ok_push ist set to zero. But it isn''t: dmesg prints out: "set ok_push to one." Any Ideas? Frithjof static int tcf_mirred_init(struct rtattr *rta, struct rtattr *est, struct tc_action *a, int ovr, int bind) { struct rtattr *tb[TCA_MIRRED_MAX]; struct tc_mirred *parm; struct tcf_mirred *m; struct tcf_common *pc; struct net_device *dev = NULL; int ret = 0; int ok_push = 0; if (rta == NULL || rtattr_parse_nested(tb, TCA_MIRRED_MAX, rta) < 0) return -EINVAL; if (tb[TCA_MIRRED_PARMS-1] == NULL || RTA_PAYLOAD(tb[TCA_MIRRED_PARMS-1]) < sizeof(*parm)) return -EINVAL; parm = RTA_DATA(tb[TCA_MIRRED_PARMS-1]); if (parm->ifindex) { dev = __dev_get_by_index(parm->ifindex); if (dev == NULL) return -ENODEV; switch (dev->type) { case ARPHRD_TUNNEL: case ARPHRD_TUNNEL6: case ARPHRD_SIT: case ARPHRD_IPGRE: case ARPHRD_VOID: case ARPHRD_NONE: case ARPHRD_PPP: ok_push = 0; printk ("set ok_push to zero.\n"); break; default: ok_push = 1; printk ("set ok_push to one.\n"); break; } }
> 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? Frithjof
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? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> 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 _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html