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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 09 Feb 2014 00:17:15 +0100
From:	Wolfgang Walter <linux@...m.de>
To:	netdev@...r.kernel.org,
	Hannes Frederic Sowa <hannes@...essinduktion.org>
Subject: Re: linux 3.13: problems with isatap tunnel device and UFO

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
--
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