Hi,
no hope :-(
I tried with 1300 without success.

What make me worry is that in the Kernel, referring at the  graph 
http://open-source.arkoon.net/kernel/kernel_net.png
the fragmentation is performed in the ip_finish_output() function, and only 
after that function I can see the print I placed in the ip6_tnl_xmit.



ip_fragment: 1460 > 1300 Fragment packet
ip6_tnl_xmit2: Enapsulate Packet Size (1300)
ip6_tnl_xmit2: Enapsulate Packet Size (180)

 
Then it seems to me that the whole IPv4 stack is taking care of the packet 
without considering that the destination is an IPIP6 tunnel, I am using the 
Kernel version 2.6.33.5.
Ok, I am pretty sure that I have to make other tries before say that but .. can 
be a kernel bug ?





Pietro Paolini
pulsarpie...@aol.com




-----Original Message-----
From: Gert Doering <g...@greenie.muc.de>
To: Pietro Paolini <pulsarpie...@aol.com>
Cc: openwrt-devel <openwrt-devel@lists.openwrt.org>; gert 
<g...@greenie.muc.de>; p.paolini <p.paol...@genexis.eu>
Sent: Tue, Nov 5, 2013 4:33 pm
Subject: Re: [OpenWrt-Devel] IPIP6 Fragmentation


Hi,

try reducing the tun1 mtu further, to see whether it makes the issue go 
away - I'm not sure right now if "40" is the right size for ipipv6
(it's the extra IPv4 headers that you need to count, not the IPv6 header)

I'm not exactly sure how to test interface mtu on linux right now - 
"ifconfig tun1" should show, though...

gert


On Tue, Nov 05, 2013 at 08:43:16AM -0500, Pietro Paolini wrote:
> Hi,
> thanks for your response, the MTU of my input interface is 1500 and the MTU 
> of 
the tunnel interface is 1460 but I still have this problem.
> 
> 
> If I try to put another printk:
> 
> 
> 
> 
> static int ip_finish_output(struct sk_buff *skb) 
> {
> ....
>  if ((skb->ipsec_offload == 0) &&
>                 skb->len > ip_skb_dst_mtu(skb) && !skb_is_gso(skb)) {
>                 printk(KERN_ERR "%s: %d > %d Fragment packet input device 
(%s)\n",
>                                                                         
__FUNCTION__,
>                                                                         
skb->len,
>                                                                         
dst_mtu(skb_dst(skb)),
>                                                                         
skb->dev->name);
>                 return ip_fragment(skb, ip_finish_output2);
>         }
>  ..
> }
> 
> 
> 
> 
> I can see that when I send a packet of 1433 - UDP payload, total size 1461 - 
> ( 
I am using hping3 and I verify with wireshark ), the result is
> 
> 
> ip_fragment: 1461 > 1460 Fragment packet input device (dslite-vlan1)  
> 
> 
> then the packet is fragmented by the IPv4 Stack even if the MTU 1500 vs 1460 
(40 is the size of ipv6 headers)
> 
> 
> Any ideas ?
> 
> 
> 
> 
> 
> Pietro Paolini
> pulsarpie...@aol.com
> 
> 
> 
> 
> -----Original Message-----
> From: Gert Doering <g...@greenie.muc.de>
> To: OpenWrt Development List <openwrt-devel@lists.openwrt.org>
> Sent: Tue, Nov 5, 2013 12:02 pm
> Subject: Re: [OpenWrt-Devel] IPIP6 Fragmentation
> 
> 
> Hi,
> 
> On Mon, Nov 04, 2013 at 07:52:57AM -0500, Pietro Paolini wrote:
> > I am working for an embedded Linux firmware running on a CPE and I am 
> > using an IP4 over IPv6 tunnel configured as following:
> > 
> > ip -f inet6 tunnel add tun1 mode ipip6 remote XX:XX:XX local XX:XX:XX 
> > dev eth0
> 
> By setting an appropriate MTU on the tun1 interface ("outer mtu minus
> ipv6 header size") you should see the fragmentation happen only on
> the IPv6 side of things.
> 
> What you are doing is telling the stack "yes, tun1 can take my 1500 byte
> packets just fine!", and then the resulting packet will be too large for
> the IPv4 path it takes (which is not necessarily so, you could have an
> IPv4 MTU of 9000 bytes... who knows), so it needs to fragment IPv4,
> but at that point in time, IPv6 is "just payload" so it can't do anything
> about the IPv6 packet anymore (aka "send back ICMP PTB").
> 
> [..]
> > Is there any options to disable the fragmentation on IPV4  ? 
> 
> In that case, you'd need to drop the IPv4 packet.  Gain?  Zero :-)
> 
> gert
> -- 
> USENET is *not* the non-clickable part of WWW!
>                                                            //www.muc.de/~gert/
> Gert Doering - Munich, Germany                             g...@greenie.muc.de
> fax: +49-89-35655025                        g...@net.informatik.tu-muenchen.de
> 
>  
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
>  

-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             g...@greenie.muc.de
fax: +49-89-35655025                        g...@net.informatik.tu-muenchen.de

 
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Reply via email to