Re: Linux sk_buff issues.

Re: Linux sk_buff issues.

[Paul Schulz]

Greetings,

In the 2.4.1 kernel..
While looking at the packet classifier code (net/sched/cls_u32.c) and other
ipv4 code that makes use of sk_buf, the following is observed:

-- There exist data structures in sk_buf for the mac layer (mac), net
	header (nh), and transport header (h).

-- These data structures contain explicit labels for the various header
	fields (depending on the protocol used) as well as a 'raw'
	field.

-- Most of the cls_u32 code and packet handling code uses the
	'raw' label in the data-structure.

Using kgdb, and tracing these datastructures, there are cases where the data
looks to be inconsistant. (for example, skb->nh.iph
points to one part of memory and skb->h.tcphdr points to a different part).
Also, the values seem to be different, eg., (struct udphdr *)((char
*)skb->nh.raw + 20)->source != skb->h.udp->source. I am assuming using
skb->nh.raw is the corrent version to use at this point. Is this correct and
are their any guidelines to be aware of?

Thanks,
Paul
--
                       Paul Schulz - Software Engineer
        Foursticks Pty Ltd - 2/259 Glen Osmond Road, Frewville, SA 5063
    Phone: +61 8 8338 5500   Fax: +61 8 8338 5511   Mobile: +61 401 981 301
       Email: pschulz@foursticks.com           Web: www.foursticks.com

Re: Linux sk_buff issues.

[Alexey Kuznetsov]

Hello!

>							 I am assuming using
> skb->nh.raw is the corrent version to use at this point.

Yes, nh is almost always set to right value, unlike h.

"Almost" is because, it is possible to see it shifted
when packet is sent via raw packet socket with an complicaed MAC header.
Shortly, corresponding pointer is reliable when packet originated
by corresponding part of code. h is reliable, when packet is sourced
by tcp/udp, nh - when it is srourced by a protocol.

The only 100% right way is to parse from skb->data and skip mac header
at el.

Alexey