Date:	Sat, 3 Mar 2012 13:00:23 +0500
From:	Syed Muhammad Mohsin Kazmi <08beesmmkazmi@...cs.edu.pk>
To:	Francois Romieu <romieu@...zoreil.com>
Cc:	netdev@...r.kernel.org
Subject: Re: data is truncated in skb

I am not doing this for my proprietary use. However, somehow it is
related to my academic work but i am doing this for open source
contribution. I have run short of time as i have less than two months
to do it. Anybody like to contribute in this implementation is welcome
to do so.

Here is now, I elaborate  what i am doing and what is the problem :
       I am trying to write down very basic version of trill as Radia
Perlman has requested us personally. I have no previous experience in
Linux Kernel network programming. So, it is my bottle-neck. I have
studied few topics related to bridging and basic data structures as
sk_buff etc.
I have written a code as a start which encapsulates and decapsulates
packets with trill header. This is done fine and These encapsulated
packets routes to their destination exactly but due to encapsulated
data of the packets are truncated from the end by the size of
encapsulation header.
The topology upon which i am testing it is:

         virtual_host_1_eth0 ------ openvpn_tap0_bridge1_eth0
------------------- eth1_bridge2_openvpn_tap0 ------
eth0_virtual_host_2

where bridge1 and bridge2 are physical machines while host1 and host2
are virtual hosts on these physical machines.
I have run the wireshark on all of these machines (physical and virtual).

If i ping from one virtual host to other, the ICMP packets generated
by virtual host are encapsulated by its local bridge with trill header
and send them to other bridge where these packets are decapsulated.
Then these packets are send to its local virtual host where i have
seen them on wireshark.
I don't get the reply message from that host as original data is
truncated so may be these packets are discarded at its destination.

Secondly, i have got that message "protocol 0x22f3 is buggy at dev
tap0" on destination's local bridge.

I think so, first problem is, originally the packet is received by the
local bridge, device that receive it fill some field with number of
receive bytes may be in struct sock *sk (int recvbuf). So when the
device send these packets, it truncates the data that is exceeding
from this receiving byte field. I have checked skb_copy_expand()
funcation and skb_rellocate_headroom(). But not succeeded yet.
Any idea or suggestion that is closely related to the problem.

Second problem is, when the device receives the packet, it fills
skb->protocol field with 0x22f3 as a packet protocol in dev.c. When i
send the decapsulated packets then that field is remain same as
skb->protocol = 0x22f3. So, tap0 checks the protocol field with the
one used in packet that is now changed to 0x0800 for IP, so it
generates that message "protocol 0x22f3 is buggy at dev tap0". When i
changed that field skb->protocol to 0x0800 in decapsulating function.
Then these packets are not even received by virtual host.
So, any solution to this problem.

Regards,
Syed M. Mohsin Kazmi





On Fri, Mar 2, 2012 at 7:43 PM, Francois Romieu <romieu@...zoreil.com> wrote:
>
> Syed Muhammad Mohsin Kazmi <08beesmmkazmi@...cs.edu.pk> :
> [...]
> >       if(skb->data == push3)
> >       {
> >               skb_set_mac_header(skb,0);
> >
> >               skb_pull(skb,ETH_HLEN);
>
> May be this skb_pull as a start. Hard to tell without context (and I am not
> a free as in beer consultant for proprietary or academic homework).
>
> [...]
> >       printk("\t\t\tencapsulated Buffer\n");
>
> Help yourself: see Documentation/trace/kprobetrace.txt and check the
> skb_xyz calls.
>
> --
> Ueomor
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists