Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 372575 - sys-apps/openrc: 6to4 tunnel fails with custom tunnel name
Summary: sys-apps/openrc: 6to4 tunnel fails with custom tunnel name
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: OpenRC (show other bugs)
Hardware: x86 Linux
: Normal normal with 5 votes (vote)
Assignee: OpenRC Team
Whiteboard: openrc:oldnet:ip6to4
Depends on:
Blocks: openrc-tracker
  Show dependency tree
Reported: 2011-06-22 12:58 UTC by Ctibor Brančík
Modified: 2011-12-27 01:11 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---

ip6to4 - split interface creation and configuration (,2.85 KB, text/plain)
2011-12-14 18:20 UTC, Christopher Byrne

Note You need to log in before you can comment on or make changes to this bug.
Description Ctibor Brančík 2011-06-22 12:58:34 UTC
I have set up tunnel to connect to ipv6 internet by local relay according to documentation in /usr/share/doc/openrc/net.example

When I choose tunnel name other then sit0, it cannot be set up and init script fails.

Default configuration of the sit0 device when module is loaded:

sit0: ipv6/ip  remote any  local any  ttl 64  nopmtudisc 6rd-prefix 2002::/16 

I have investigated the matter further. Creating tunnel manualy also fails unless you specify local parameter with iproute2:

ip tunnel add tun6to4 mode sit remote any local <public ipv4 address>

Apparently kernel doesn't like when there are two sit tunnels with "local any". It spits out error.

ip tunnel add tun6to4 mode sit remote any local any
ioctl: No buffer space available

Obviously init script doesn't add local parameter when creating tunnel.

kernel: 2.6.36-r5
iproute: 2.6.35-r2
openrc: 0.8.2

Reproducible: Always

Steps to Reproduce:
1. Set 6to4 tunnel according to the official doc
2. create appropriate symlink to net.lo
3. start the service
Actual Results:  
/etc/init.d/net.tun6to4 start

* Bringing up interface tun6to4
 *   ERROR: interface tun6to4 does not exist
 *   Ensure that you have loaded the correct kernel module for your hardware
 * ERROR: net.tun6to4 failed to start

Expected Results:  
I should have 6to4 tunnel ready

relevant part /etc/conf.d/net

routes_wan="default via"

Comment 1 bike123 2011-06-22 18:22:57 UTC
I have the same problem (x86 arch)
Comment 2 Agostino Sarubbo gentoo-dev 2011-06-24 10:24:05 UTC
do not add arches by yourself. thanks
Comment 3 Michael Moon 2011-06-28 15:22:03 UTC
affects me too
Comment 4 Jeroen Asselman 2011-08-09 20:07:23 UTC
I have got a workaround. The script fails because it will try to detect if the interface exists. Which it doesn't of course because it actually has to create the tunnel.
When you choose sit0 instead of a custom name, the init script will continue, but then ip tunnel add will fail with "No buffer space available" because the interface already exists. The "No buffer space available" just happens to be a generic error message on the iproute2 part unfortunately.

Instead of symlinking your net.customname to net.lo, make a copy of it and edit the file. This is what I did:

cp /etc/init.d/net.lo /etc/init.d/net.6to4

edit the file net.6to4, and on line 510, remove the if ! _exists check completely.

My /etc/conf.d/net for the tunnel is:

Now I can start and stop the tunnel until a better fix is available
Comment 5 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2011-08-09 20:30:48 UTC
6to4 is actually a special subset of sit tunnels.

Here's my larger document on how to set up SIT tunnels.

Due to udev rules, the tunnel interface MUST be named tun0 or sit0.
Comment 6 William Hubbs gentoo-dev 2011-08-09 21:47:46 UTC
(In reply to comment #4)
> Instead of symlinking your net.customname to net.lo, make a copy of it and edit
> the file. This is what I did:
> cp /etc/init.d/net.lo /etc/init.d/net.6to4
> edit the file net.6to4, and on line 510, remove the if ! _exists check
> completely.

Please do not do this. This is a hack and could cause major issues if you update openrc later and forget to make this a symlink again.
Comment 7 MaratIK 2011-12-01 01:38:55 UTC
confirm this
Comment 8 bike123 2011-12-02 21:31:00 UTC
(In reply to comment #7)
> confirm this
Still not working.

current configuration:



* Bringing up interface sit0
 *   ip6to4 ...                                                           [ ok ]
 *   2002:5be0:b44f::1/16 ...                                             [ ok ]
 *   Adding routes
 *     2003::/3 via :: metric 2147483647 ...                   [ ok ]

but no ping6 anywhere.

using the configuration:


 * Bringing up interface 6to4
 *   ERROR: interface 6to4 does not exist
 *   Ensure that you have loaded the correct kernel module for your hardware
 * ERROR: net.6to4 failed to start
Comment 9 MaratIK 2011-12-02 22:02:28 UTC
(In reply to comment #8)
>  *   2002:5be0:b44f::1/16 ...                                             [ ok

Try to change mask from /16 to /48 as I mentioned in Bug 392723
Comment 10 bike123 2011-12-02 22:31:47 UTC
still nothing.I recompile my kernel to use sit drivern as module. Effect is still the same
Comment 11 William Hubbs gentoo-dev 2011-12-02 23:28:45 UTC

the solution for this is in comment #5.


Comment 12 Ctibor Brančík 2011-12-03 09:29:27 UTC
The comment #5 is only a workaround for now in my point of view. Documentation clearly says, that I can use custom names for my tunnel. See /usr/share/doc/openrc/net.example.

So its either a bug in docs and those should be changed. But then openrc would behave differently than old initscripts which support custom tunnel names out of the box if I remember correctly. Or is it a bug in udev instead according to the supposed solution?

So my conclusion and most simple formal solution in my opinion is to declare a bug in documentation of openrc and change that. Or not?
Comment 13 Christopher Byrne 2011-12-12 07:15:01 UTC
The underlying problem is start() really means configure(), and of course, one cannot configure an interface that doesn't exist. Now there are "pre_start" (create) and "post_stop" (destroy) interfaces, which are used by bridge and tuntap modules. But that doesn't work for ip6to4 - ip6to4_pre_start isn't getting called because its not in ${MODULES}. Why not? (I was having the same problem with a module I wrote, see bug 392223)

Almost a month of staring at the code, 5 panels of walls and several head bumps later because...

...$_config_vars in /lib/rc/ was BEFORE ip6to4_depend instead of AFTER IT it! UGH!

Now the solution should work - create the tunnels in ip6to4_pre_start then actually configure them and set the routes in ip6to4_start.

But as turns it is slightly more difficult than that - ip6to4 iterates over each IP address (excluding any private IPs from the list). We need that list generated in "pre_start" for use in the "start" phase - but how to do that?

There's a couple ways to this (in no particular order).
1) Create a global variable in ip6to4 to store it; however no other module does that and it may not be permissible (but it does work)
2) Re-run the loop in "start"
3) Create a phony config var, say "iplist", clear "iplist_{$IFACE}" at the beginning of "pre_start" and set it later in the function to the list of ipv4 addresses, then re-use that variable in "start"
4) Rename "start" to "pre_start" and make "start" a dummy function that always returns success - this is what the ppp module does.
Comment 14 Christopher Byrne 2011-12-14 18:20:14 UTC
Created attachment 295831 [details]
ip6to4 - split interface creation and configuration

I decided to go with option "2" and re-run the loop.
Comment 15 Ctibor Brančík 2011-12-14 19:23:34 UTC
I have tried and it works! Good work Salah!
Comment 16 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2011-12-27 01:11:44 UTC
implemented in commit acf77b7.

There are ways to store values between functions, so I used that instead of recomputing them.