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 config_wan="77.xxx.xxx.xxx/26" routes_wan="default via 77.xxx.xxx.xxx" config_tun6to4="ip6to4" link_tun6to4="wan" rc_need_tun6to4="net.wan"
I have the same problem (x86 arch)
do not add arches by yourself. thanks
affects me too
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: link_6to4="eth1" config_6to4="ip6to4" rc_need_6to4="net.eth1" Now I can start and stop the tunnel until a better fix is available
6to4 is actually a special subset of sit tunnels. Here's my larger document on how to set up SIT tunnels. http://dev.gentoo.org/~robbat2/conf.d-net/ipv6-addon.txt Due to udev rules, the tunnel interface MUST be named tun0 or sit0.
(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.
confirm this
(In reply to comment #7) > confirm this Still not working. current configuration: link_sit0="eth0" config_sit0="ip6to4" rc_need_sit0="net.eth0" effect: * Bringing up interface sit0 * ip6to4 ... [ ok ] * 2002:5be0:b44f::1/16 ... [ ok ] * Adding routes * 2003::/3 via ::192.88.99.1 metric 2147483647 ... [ ok ] but no ping6 anywhere. using the configuration: link_6to4="eth0" config_6to4="ip6to4" rc_need_6to4="net.eth0" Effect: * 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
(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
still nothing.I recompile my kernel to use sit drivern as module. Effect is still the same
All, the solution for this is in comment #5. Thanks, William
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?
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/net.ip6to4.sh 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.
Created attachment 295831 [details] ip6to4 - split interface creation and configuration I decided to go with option "2" and re-run the loop.
I have tried and it works! Good work Salah!
implemented in commit acf77b7. There are ways to store values between functions, so I used that instead of recomputing them.
