Hi, I discover recently that the arp traffic is managed like any other flow. So you get hang after a moment if you don''t use a default class. Is the any means to avoid this ? Not to have a default class is a way to filter traffic ... One would be to managed to class ARP request with tc but I don''t know if it is possible. Thanks in advance, -- Éric Leblond courriel : eric@regit.org
Eric, We recently had a discussion here about filtering non-IP traffic. See my attempt here: http://mailman.ds9a.nl/pipermail/lartc/2003q1/006656.html And Julian''s follow-up post which closed the thread: http://mailman.ds9a.nl/pipermail/lartc/2003q1/006663.html You should be able to select with something like this: U32="tc filter add dev $DEV parent 1:0 protocol ip u32" $U32 match u16 0x0806 0xFFFF at -2 where 0x0806 identifies the ethernet frame as an ARP packet, per $LINUX_SOURCE/include/linux/if_ether.h: #define ETH_P_ARP 0x0806 /* Address Resolution packet */ Good luck, -Martin On Fri, 10 Jan 2003, Eric Leblond wrote: : Hi, : : I discover recently that the arp traffic is managed like any other flow. : So you get hang after a moment if you don''t use a default class. : : Is the any means to avoid this ? Not to have a default class is a way to : filter traffic ... : : One would be to managed to class ARP request with tc but I don''t know if : it is possible. : : Thanks in advance, : -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Fri, 2003-01-10 at 17:06, Martin A. Brown wrote:> : > We recently had a discussion here about filtering non-IP traffic. See my > : > attempt here: > : > > : > http://mailman.ds9a.nl/pipermail/lartc/2003q1/006656.html > :I did not manage to push arp packet in the wanted queue. I use the following syntax : tc class add dev eth0 parent 1:1 classid 1:4 htb \\ rate 512.0Kbit ceil 512.0Kbit burst 1.28Kbit prio 0 tc filter add dev eth0 protocol ip u32 \\ match u16 0x0806 0xFFFF at -2 flowid 1:4 Do I need special options in the qos code (special modules ...) Any Help appreciated ! -- Éric Leblond courriel : eric@regit.org
Has somebody realyy manage to use the examples given when using negative offset in u32 ? I look at the kernel code, I''m almost a real beginner here so I could wrote stupid things : I saw that in the file cls_u32.c we work with skb and use only skb->nh.raw. That''s the network header, so we don''t have any information about Ethernet header (it''s in skb->mac.raw that we have the ethernet header and that the protocol is given). Furthermore (maybe i''m wrong cause of inverted stockage in memory) in the skbuf struct the ethernet header union follow the network header union so we should read something else. Thus we can at least say that negative offset in u32 are really "tricky" and really non clean and as seems to show experiment that they don''t work (?) -- Éric Leblond courriel : eric@regit.org
Eric Leblond wrote:>Has somebody realyy manage to use the examples given when using negative >offset in u32 ? > >I look at the kernel code, I''m almost a real beginner here so I could >wrote stupid things : > >I saw that in the file cls_u32.c we work with skb and use only >skb->nh.raw. That''s the network header, so we don''t have any information >about Ethernet header (it''s in skb->mac.raw that we have the ethernet >header and that the protocol is given). >Furthermore (maybe i''m wrong cause of inverted stockage in memory) in >the skbuf struct the ethernet header union follow the network header >union so we should read something else. >Thus we can at least say that negative offset in u32 are really "tricky" >and really non clean and as seems to show experiment that they don''t >work (?) > > >Eric, the following offsets are from a mail previously posted on this list. I hope it helps. Stephane Ouellette. Decimal Ofs 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) _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> Eric Leblond wrote: > >>Has somebody realyy manage to use the examples given when using negative >>offset in u32 ? > > > Decimal Ofs 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)Yes I try these one. But I was unable to get them working. So I look at the kernel code and find that''s it is (for me) impossible to access these fields BR -- Eric Leblond courriel : eric@regit.org Computer are like air conditionners, they don''t work when windows are open. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hello, On 14 Jan 2003, Eric Leblond wrote:> I look at the kernel code, I''m almost a real beginner here so I could > wrote stupid things : > > I saw that in the file cls_u32.c we work with skb and use only > skb->nh.raw. That''s the network header, so we don''t have any information > about Ethernet header (it''s in skb->mac.raw that we have the ethernet > header and that the protocol is given).Everything starts from the net drivers (drivers/net/*.c): - dev_alloc_skb() is used to reserve skb head space for the eth hdr and data space for the packet - NIC stores ethhdr and packet there - eth_type_trans() is called to set skb->mac.raw and to skip the eth header by incrementing skb->data with skb_pull() - net/core/dev.c sets skb->nh.raw = skb->data and packet is passed to upper layers where tc ingress works> Furthermore (maybe i''m wrong cause of inverted stockage in memory) in > the skbuf struct the ethernet header union follow the network header > union so we should read something else.tc sees: skb: +-------+ head | | before ofs=-14: more reserved bytes | | ofs=-14: dst mac | | ofs=-8: src mac |ethhdr | ofs=-2: eth proto +-------+ data ofs=+0, same as nh.raw |packet | | | +-------+ tail | | +-------+ end As for u32_classify, nh.ptr is used as base offset, later the ''ptr'' is adjusted by signed int offsets, so it can touch lower addresses.> Thus we can at least say that negative offset in u32 are really "tricky" > and really non clean and as seems to show experiment that they don''t > work (?)This is a hack, of course (may be designed so). But it works for me (tm) Regards -- Julian Anastasov <ja@ssi.bg> _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hello, On 14 Jan 2003, Eric Leblond wrote:> I did not manage to push arp packet in the wanted queue. I use the > following syntax : > > tc class add dev eth0 parent 1:1 classid 1:4 htb \\ > rate 512.0Kbit ceil 512.0Kbit burst 1.28Kbit prio 0 > tc filter add dev eth0 protocol ip u32 \\ > match u16 0x0806 0xFFFF at -2 flowid 1:4 > > Do I need special options in the qos code (special modules ...)No, no more hacks, just use "protocol arp" instead of "protocol ip". Then you can avoid matching the eth proto code at -2. The filter''s "protocol XXX" uses skb->protocol which is built from the eth proto code for eth devices (returned from eth_type_trans). So, "protocol ip" is ETH_P_IP, "protocol arp" is ETH_P_ARP and so on. See the "llproto_names" array in iproute2 (lib/ll_proto.c) and ll_proto_a2n() used from tc/tc_filter.c Regards -- Julian Anastasov <ja@ssi.bg> _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/