Hi Akshay,
Thanks for your reply.
I am looking at the ip_build_xmit() code, but i have a feeling that this
is not my problem. The 16 bytes is the length of 'myheader' and is not
something related to a multiple of 16 bytes.
My packets travel from one machine to another but they dont go up the
protocol stack on the destination machine.
Following is the output of tcpdump at the destination machine for ping
traffic that i am sending (ping data set to 0xff).
--------------------------------------------------------------------
14:29:05.003856 eth0 < truncated-ip - 157 bytes missing!10.5.1.2 >
69.0.0.84: (frag 2573:217@2056) [tos 0x5] (ttl 3, bad cksum 0!,
optlen=20[|ip])
1. 0a05 0101 0a0d 0101 0300 0000 0a05 0102
2. 4500 0054 0378 0000 4001 611e 0a0d 0101
3. 0a05 0101 0800 4b8a 5a02 3600 0191 373b
4. e3a6 0000 ffff ffff ffff ffff ffff ffff
5. ffff ffff ffff ffff ffff ffff ffff ffff
6. ffff ffff ffff ffff ffff ffff ffff ffff
7. ffff ffff
-------------------------------------------------------------------
As can be seen from tcpdump's interpretation, the src is 10.5.1.2 and
destination is 69.0.0.84. That means the IP src and destination are being
taken from the last 4 bytes of line 1 (0a05 0102) and first 4 bytes of
line 2 (4500 0054). This in turn means that the first line is taken to be
the IP header when in fact it is "myheader".
The real IP header begins from line 2 (4500 0054).
I tried setting skb->nh.iph to that point (line 2) but it doesnt seem to
work ! That is when i noticed that skb->nh.raw and skb->h.raw are set to
skb->data in net_bh(). So essentially mac.raw, nh.raw and h.raw are all
pointing to the ethernet header when the packet reaches net_bh() on the
destination machine.
I dont exactly know where my reasoning is going wrong.
Regards,
Amit
On Mon, 25 Jun 2001, Akshay Adhikari wrote:
> Hi,
>
> I (think I) had a similar problem a while back - the
> lengths are not exactly what you want them to be.
> If you observe functions like ip_build_xmit (), or
> similar functions which start with building an
> sk_buff, you will notice that the length they allocate
> is padded to a multiple of 16 bytes. They do this:
>
> length = (length + 15)&~15.
>
> Look also at alloc_skb ()
>
> I think thats where you can account for your 16 bytes.
>
>
> hth,
> akshay
>
> --- Amit Kucheria <amitk@ittc.ku.edu> wrote:
> > Hi all,
> >
> > I am writing a device driver which requires me to
> > add a new header in
> > between the IP header and the MAC header (ethernet).
> >
> > Now, i dont want to modify the original sk_buff
> > structure to add a pointer
> > to this header. What i have done instead is to
> > specify the
> > 'hard_header_len' of this device to be equal to the
> > sum of MAC and custom
> > header lengths.
> >
> > ie. mydevice->hard_header_len = MAC header length +
> > myheader length
> >
> > Now when i transmit these packets using
> > dev_queue_xmit (which in turn
> > calls the hard_start_xmit function of eth0), my
> > packets arrive mangled at
> > the destination machine. Essentially the IP header
> > pointer
> > (nh.raw/nh.iph) is pointing to 'myheader'instead of
> > to the IP header
> > which starts after 16 bytes.
> >
> > Any comments or suggestions on this approach will be
> > appreciated.
> >
> > Regards,
> > Amit
--
^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^
Amit Kucheria
EECS Grad. Research Assistant
Team Niehaus || Room # 245E
University of Kansas @ Lawrence
(R)+1-(785)-830 8521 ||| (O)+1-(785)-864 7774
____________________________________________________
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
