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>
