Re: linux 3.13: problems with isatap tunnel device and UFO

From: Wolfgang Walter <linux@stwm.de>
To: netdev@vger.kernel.org,
	Hannes Frederic Sowa <hannes@stressinduktion.org>
Subject: Re: linux 3.13: problems with isatap tunnel device and UFO
Date: Sun, 09 Feb 2014 00:17:15 +0100	[thread overview]
Message-ID: <1581659.JtJ1UQaXJr@h2o.as.studentenwerk.mhn.de> (raw)
In-Reply-To: <20140207222227.GC16198@order.stressinduktion.org>

Am Freitag, 7. Februar 2014, 23:22:27 schrieb Hannes Frederic Sowa:
> Hi!
> 
> On Fri, Feb 07, 2014 at 07:17:40PM +0100, Wolfgang Walter wrote:
> > Am Freitag, 7. Februar 2014, 18:56:41 schrieb Hannes Frederic Sowa:
> > > Hi!
> > > 
> > > On Fri, Feb 07, 2014 at 06:47:07PM +0100, Wolfgang Walter wrote:
> > > > with kernel 3.13 I have a problem with isatap tunnels receiving
> > > > fragmented
> > > > ipv6 udp packets.
> > > 
> > > Which was the last known version that did work?
> > 
> > I think 3.12 had no problems, but I'm not sure. I test this tonight.

3.12 is indeed fine. But this is probably because of:

ethtool -k is0
....
udp-fragmentation-offload: off [fixed]
....

> 
> Could you give me a bit more details on your setup, please?
> 
> I just tested a setup with UFO packets in sit tunnels and it worked
> properly for me (on net).
> 

host A (which shows the problem with kernel 3.13):

$ ip addr ls eth0
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
    link/ether 11:22:33:44:55:66 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2001:1111:2222:aaaa:0:5efe:c0a8:101/120 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::1322:33ff:fe44:5566/64 scope link 
       valid_lft forever preferred_lft forever

$ ip addr ls is0
14: is0: <NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group 
default 
    link/sit 192.168.1.1 brd 0.0.0.0
    inet6 2001:1111:2222:aaaa:0:5efe:c0a8:101/64 scope global dynamic 
       valid_lft 85977sec preferred_lft 13977sec
    inet6 fe80::5efe:c0a8:101/64 scope link 
       valid_lft forever preferred_lft forever

The other host B is in the same isatap-subnet (but a different ipv4-subnet):

$ ip addr ls eth0
4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
    link/ether 11:22:33:44:55:ee brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.1/24 brd 192.168.1.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::1322:33ff:fe44:55ee/64 scope link 
       valid_lft forever preferred_lft forever

$ ip addr ls is0
10: is0: <NOARP,UP,LOWER_UP> mtu 1280 qdisc noqueue state UNKNOWN group 
default 
    link/sit 192.168.10.1 brd 0.0.0.0
    inet6 2001:1111:2222:aaaa:0:5efe:c0a8:a01/64 scope global dynamic 
       valid_lft 85977sec preferred_lft 13977sec
    inet6 fe80::5efe:c0a8:a01/64 scope link 
       valid_lft forever preferred_lft forever

The application I see this is strongswan (ikev2). When it establishes an 
connection it sends udp-packets to large for is0 (here 1316 data-bytes, 
strongswan says).

For the tests I unloaded the netfilter modules so there should be no 
interference with the firewall or conntrack etc.

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts