Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#19450 - [iproute2] "ip tunnel" complains about an ioctl with a bad argument

Attached to Project: Arch Linux
Opened by clemens fischer (aurino) - Thursday, 13 May 2010, 20:11 GMT
Last edited by Ronald van Haren (pressh) - Friday, 14 May 2010, 20:41 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Ronald van Haren (pressh)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

The "ip" utility complains about an ioctl with a bad argument:

<code>
0 4 # ip tunnel
ioctl: Invalid argument
sit0: ipv6/ip remote any local any ttl 64 nopmtudisc
ioctl: Invalid argument
tun6to4: ipv6/ip remote any local 95.88.25.91 ttl 111
</code>

Additional info:
* package version(s) iproute2 2.6.33-1

Could this have to do with a reversed patch? I'm not sure about this
one from file "/abs/core/iproute2/iftunnel.patch":

<code>
--- include/linux/if_tunnel.h 2009-08-16 21:17:23.145859979 +0200
+++ include/linux/if_tunnel.h.old 2009-08-16 21:15:22.991902394 +0200
@@ -2,7 +2,7 @@
#define _IF_TUNNEL_H_

#include <linux/types.h>
-#include <linux/ip.h>
+
</code>

I normally give the _old_ file, then the new as arguments to diff(1),
this patch has them reversed. Nonetheless the actual if_tunnel.h seems
to have the "<linux/ip.h>" include. Could the maintzainer check up on
this? Just a hunch.


Steps to reproduce:

Make some tunnel, preferably an automatic IPv6-in-IPv4 (rfc 3068)
tunnel. The commands somehow work. "ip tunnel [show]" always shows
the above messages.
This task depends upon

Closed by  Ronald van Haren (pressh)
Friday, 14 May 2010, 20:41 GMT
Reason for closing:  Not a bug
Comment by Ronald van Haren (pressh) - Friday, 14 May 2010, 09:15 GMT
the patch is correct, note that although it is reversed, it is also applied with the 'reverse' switch. Even so, it is only to fix a compile issue.

To the problem, below works for me. Am I doing wrong?

# sudo ip tunnel add ipv6 mode sit remote 192.168.1.42
# ip tunnel show
sit0: ipv6/ip remote any local any ttl 64 nopmtudisc 6rd-prefix 2002::/16
ipv6: ipv6/ip remote 192.168.1.42 local any ttl inherit 6rd-prefix 2002::/16
Comment by clemens fischer (aurino) - Friday, 14 May 2010, 16:23 GMT
> To the problem, below works for me. Am I doing wrong?
>
> # sudo ip tunnel add ipv6 mode sit remote 192.168.1.42
> # ip tunnel show
> sit0: ipv6/ip remote any local any ttl 64 nopmtudisc 6rd-prefix 2002::/16
> ipv6: ipv6/ip remote 192.168.1.42 local any ttl inherit 6rd-prefix 2002::/16

Looks ok to me. Does it work? You need at least a route for that. If
your provider is connected properly, you should have:

::/96 via :: dev ipv6 metric 256 mtu 1480 advmss 1420 hoplimit 0
2002::/16 dev ipv6 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 0
default via ::192.88.99.1 dev ipv6 metric 1011 mtu 1480 advmss 1420 hoplimit 0

According to RFC-3068 the "nearest" IPv6 capable router has the standard
IP 192.88.99.1 and your ISP wires it automatically. You should also
give a proper IPv6-in-IPv4 IP to the interface you named "ipv6". I do
it like this:

result=$(printf "2002:%02x%02x:%02x%02x::1/16" $(echo "${ip4}" | ${tr} '.' ' '))

Then you could already be able to ping www.ipv6.org or other pingable
IPv6 sites.

What kernel are you using? Maybe my custom 2.6.33.3 is misconfigured,
although it is very similiar to the one from ARCH. And everything
works, too. What IPv6 networking options are in your kernel?
Comment by clemens fischer (aurino) - Friday, 14 May 2010, 19:31 GMT
I wrote:

> What kernel are you using? Maybe my custom 2.6.33.3 is misconfigured,
> although it is very similiar to the one from ARCH. And everything
> works, too. What IPv6 networking options are in your kernel?

The ARCH kernel has a particular option not needed normally:

/net/ipv6/Kconfig:config IPV6_SIT_6RD
/net/ipv6/Kconfig: bool "IPv6: IPv6 Rapid Deployment (6RD) (EXPERIMENTAL)"
/net/ipv6/Kconfig- depends on IPV6_SIT && EXPERIMENTAL
/net/ipv6/Kconfig- default n
/net/ipv6/Kconfig- ---help---
/net/ipv6/Kconfig: IPv6 Rapid Deployment (6rd; draft-ietf-softwire-ipv6-6rd) builds upon
/net/ipv6/Kconfig- mechanisms of 6to4 (RFC3056) to enable a service provider to rapidly
/net/ipv6/Kconfig- deploy IPv6 unicast service to IPv4 sites to which it provides
/net/ipv6/Kconfig- customer premise equipment. Like 6to4, it utilizes stateless IPv6 in
/net/ipv6/Kconfig- IPv4 encapsulation in order to transit IPv4-only network
/net/ipv6/Kconfig: infrastructure. Unlike 6to4, a 6rd service provider uses an IPv6
/net/ipv6/Kconfig- prefix of its own in place of the fixed 6to4 prefix.
/net/ipv6/Kconfig-
/net/ipv6/Kconfig: With this option enabled, the SIT driver offers 6rd functionality by
/net/ipv6/Kconfig- providing additional ioctl API to configure the IPv6 Prefix for in
/net/ipv6/Kconfig- stead of static 2002::/16 for 6to4.

My IPv6 tunnel has always worked without IPV6_SIT_6RD. I made a new
kernel with this option and now I get:

$ ip t
sit0: ipv6/ip remote any local any ttl 64 nopmtudisc 6rd-prefix 2002::/16
tun6to4: ipv6/ip remote any local 95.89.48.138 ttl 111 6rd-prefix 2002::/16

meaning the problem is solved.

I think things like this could be resolved much easier when new or
changed options in the standard ARCH kernel had a "diff -u" posted some
place!
Comment by Ronald van Haren (pressh) - Friday, 14 May 2010, 20:40 GMT
You can see changes via the websvn interface for any package.

Loading...