hi. i am a kernel networking newbie and i really look forward to getting
your advice on a problem at hand. please bear with it, if the problem
seems trivial [or] said approach is wrong.
this is for an implementation of a minimal encapsulation [ipip] protocol
as covered by rfc2004.
* the idea is instead of having an outer ip header like in ipip, one just
inserts a small minimal forwarding header and just change the original
ip header instead. this saves something like 8-12 bytes per packet
which is _good_ for mobile commn. however yes, this is just an optional
feature NOTHING compulsory or needed...... {and cant be used for
already fragmented packets as the minimal header just acts as a
temporary store for the original source and destination addresses}
* thus we have [original ip modified header] -> [minimal header] -> [payload]
instead of [encpap iph] -> [original iph] -> [payload]
* i thought that i could slip in a struct miniphdr like this:
xmit() function -->
<setup miniphdr with original source & dest address>
<copy contents of iph i.e skb->nh.raw >
* skb_pull(skb,sizeof(struct iphdr));
* skb_push(skb,sizeof(struct miniphdr));
* skb_pull(skb,sizeof(struct iphdr));
<restore contents of iph>
<update contents of iph - i.e modify the original header>
<calculate lengths, checksum> --> ip_send(skb)
ipip_rcv() function -->
<skb->mac.raw = skb->nh.raw ??>
<copy contents of iph i.e skb->nh.raw >
skb_pull(skb,sizeof(struct iphdr));
skb_pull(skb,sizeof(struct miniphdr));
skb_push(skb,sizeof(struct iphdr));
<restore contents of iph>
<skb->h.raw=skb->nh.raw , i.e like in ipip where after pulling
the outer header skb->nh.raw and skb->h.raw pt to the same place>
<use the addresses in the miniphdr and update the modified ip
header, calculate lengths, checksum> --> netif_rx().....
this JUST doesnt seem to work.why? i have introduced printk's everywhere
to check whats going on and i seem to be getting some stray packets
at the entry pt of the tunnel. the entry pt seems to send the data fine
and the exit pt receives it. it then replies AND it is seen though
additional `absurd' stray replies are also seen?? i really am stumped by
this and have spent some time in a full networking code walkthrough
[2.2.18] but still cannot see why its failing.
q1) i think the skb->mac, skb->h and skb->nh pointers are getting mixed
up but i have checked it also. is there something i have overlooked here?
q2) is it because the packets are fragmented ? how do i check this ?
there is an IP_DF value and a frag_offset , how do i use them ?
however in the case i test, the source of the packet IS the entry pt of
the tunnel. hence maybe there shouldnt be any fragmentation of the source
packet as it has not travelled over any [low mtu] networks or any thing
like that. right ?
q2) any ideas or suggestions please on whats wrong ????
* mr.Harald Welte was also kind enough to suggest a few ideas and also
pointed me out the 2.4 ip_nat_ftp netfilter implementation from which
i got the idea of how the skb_buff structure works] but i am not able
to get the exact rfc implementation to work though i have some
`hacks' which work [like adding it to skb->end, using three headers etc:):)]
q3) IS it necessary for such insertion of data into the skb to
formally add a struct miniphdr to the skb->h union in skbuff.h ????
something like adding a new protocol header..... i thought i could
avoid this and just use the skb functions to get over it.
Please reply,
Sorry for the inconvenience.
Vikram
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
