OpenWrt Forum Archive

Topic: Build for WNDR3700/WNDR3800

The content of this topic has been archived between 9 Jul 2013 and 6 May 2018. Unfortunately there are posts – most likely complete pages – missing.

An alternative to sixxs is tunnelbroker.net, you can get a subnet immediately there without having to gather credits first.

jow wrote:

An alternative to sixxs is tunnelbroker.net, you can get a subnet immediately there without having to gather credits first.

yeah I'm using tunnelbroker myself the registration is instant and configuration for openwrt is very easy and straightforward.

But their setup doesn't cope with dynamic endpoint addresses, or am I missing something? Most people don't have a static IPv4 address at home.

You do miss something. The endpoint can be updated with a simple HTTP get request. The 6in4 package wraps that all up in /etc/config/network.

Any docs on proper configuration available?

EDIT: Hey what do you know, I managed to set it up through the web interface smile

(Last edited by arokh on 14 Feb 2011, 13:46)

redcow wrote:
arokh wrote:

Any docs on proper configuration available?

EDIT: Hey what do you know, I managed to set it up through the web interface smile

even through /etc/config/network its very easy

http://wiki.openwrt.org/doc/howto/ipv6# … .tunneling

The 6in4 package is actually written to work specifically with Hurricane Electric (i.e. tunnelbroket.net) dynamic tunnel. If there is username & password given in the tunnel setup, then it uses that to update your tunnel endpoint at HE.
https://dev.openwrt.org/browser/trunk/p … n4.hotplug

(I haven't tried HE myself, as the static tunnel from SixXS works for me.)

Hi,
Just a quick stop-by to thank you, hnyman, for these builds, containing almost exactly what I need, and not the all the extra stuff arokh add to his builds (which are also excellent work, don't take me wrong).
And thanks also for the IPv6 tutorial, helped me alot.

Trunk has been updated to 25572 and Backfire to 25565.
No actual changes in my code.

But I noticed that the Luci footer is now shown as "Powered by LuCI Trunk (vtrunk)" instead of a proper Luci version number. After some source code research I found out that the recent Trunk name change from "Kamikaze" to a two-word release name "Attitude Adjustment" most probably broke a script in Luci build process, which assumed that the release name is just one word...

I wrote a Luci ticket about the issue, so hopefully it will get fixed soon. http://luci.subsignal.org/trac/ticket/202
(A quick & dirty fix would be to change Attitude Adjustment to Attitude_Adjustment in toplevel.mk, so that the name is again just one word. Better solution would be to somehow quote the version name in Luci makefile & related shell script arguments.)

Trunk and Backfire versions updated to 25595. I am currently running trunk.

The discussion today in Arokh's thread about miniupnpd prompted me to investigate, why my 6in4 tunnel dies, when I touch some network settings. And after some research, I found the reason and patched the 6in4.hotplug.

Like miniupnpd, also a static 6in4 tunnel from SixXS dies if network settings are touched even lightly. For example, just going into Wifi settings and not changing anything, but selecting Save&Apply, makes the network interfaces to boot again, but sadly the 6in4 tunnel stays dead. In Luci's Network/Interfaces screen, the tunnel stays with the status as "Interface not present or not connected yet". Manually restarting the tunnel from that screen brings it nicely back to life.

The reason seems to be that the whole 6in4 package has probably been originally designed for Hurricane Electric (tunnelbroker.net) tunnels. Those tunnels have a tunnel name, username and password. The current hotplug script only restarts the tunnel interface if there is username & password, and it even first HTTP-connects to HE in the hotplug script. The "ifup" command is hidden so deep into the conditions, that it does not get launched for other service providers. It only gets run, if the tunnel update with HE succeeded.

Logic in 6in4.hotplug  (/etc/hotplug.d/iface/90-6in4 in a live Openwrt system):

...
                        [ -n "$tunnelid" ] && [ -n "$username" ] && [ -n "$password" ] && {
                                [ "${#password}" == 32 -a -z "${password//[a-f0-9]/}" ] || {
                                        password="$(echo -n "$password" | md5sum)"; password="${password%% *}"
                                }
                                uci_set_state network "$cfg" ipaddr "$wanip"

                                (
                                        local url="http://ipv4.tunnelbroker.net/ipv4_end.php?ipv4b=AUTO&user_id=$username&pass=$password&tunnel_id=$tunnelid"
                                        local try=0
                                        local max=3

                                        while [ $((++try)) -le $max ]; do
                                                wget -qO/dev/null "$url" 2>/dev/null && {
                                                        logger -t 6in4-update "Updated tunnel #$tunnelid endpoint to $wanip"
                                                        ifup "$cfg"
...

The static tunnels from SixXs do not use username/password, so I have never entered that kind of information to the tunnel's config. And thus the tunnel interface never got the ifup command again from the hotplug script.

I patched the 6in4.hotplug script so that in case some information required for HE is missing, it still tries to set the tunnel working again (setting wan ip and ifup'ing the interface). I also added some logging for understanding the process better.

Patch is included in my 25595 builds. 
http://koti.welho.com/hnyman1/Openwrt/

The patch below applies both to Backfire and Trunk, and will help all those using OpenWrt with SixXS static tunnels.

There is still one piece of the full solution missing, and I think that this applies both for HE and SixXS users:
If the 6in4 interface is restarted and radvd is not, then there will be errors in syslog every 5 minutes about "resetting ipv6-allrouters membership" etc. That is due to the known "feature" in radvd, that if interfaces get updated IDs (interface indexes) when restarting, then radvd gets confused and needs to be restarted. I have not yet figured our, what would be the best way to restart radvd after bringing the tunnel up. I thought that I might  add a line "/etc/init.d/radvd restart" to the hotplug script, but something else might be better. Any ideas?


6in4.hotplug patch:

Relevant files in source code:
https://dev.openwrt.org/browser/trunk/p … n4.hotplug
https://dev.openwrt.org/browser/branche … n4.hotplug

Those files get copied into /etc/hotplug.d/iface/90-6in4 in a live Openwrt system.

Index: /Openwrt/backfire/package/6in4/files/6in4.hotplug
===================================================================
--- /Openwrt/backfire/package/6in4/files/6in4.hotplug    (revision 25595)
+++ /Openwrt/backfire/package/6in4/files/6in4.hotplug    (working copy)
@@ -13,11 +13,13 @@
         config_get proto "$cfg" proto
         [ "$proto" = 6in4 ] || return 0
 
+                logger -t 6in4-update "$ACTION for tunnel '$cfg'"
         local wandev
         config_get wandev "$cfg" wan_device "$(find_6in4_wanif)"
         [ "$wandev" = "$DEVICE" ] || return 0
 
         local wanip=$(find_6in4_wanip "$wandev")
+                logger -t 6in4-update "Tunnel '$cfg' Wan IP: $wanip"
 
         [ -n "$wanip" ] && {
             local tunnelid
@@ -51,7 +53,11 @@
                         }
                     done
                 )&
-            }
+            } || {
+                                logger -t 6in4-update "Tunnel '$cfg': No HE-related info, just try to bring tunnel up."
+                                uci_set_state network "$cfg" ipaddr "$wanip"
+                                ifup "$cfg"
+                        }
         }
     }

I think radvd should gain its own hotplug handler in /etc/hotplug.d/iface/ that restarts the service whenever an iface is ifup'd which appears in /etc/config/radvd.
Another cheap solution would be to just mark /etc/init.d/radvd as affected by /etc/init.d/network in /etc/config/ucitrack

jow wrote:

I think radvd should gain its own hotplug handler in /etc/hotplug.d/iface/ that restarts the service whenever an iface is ifup'd which appears in /etc/config/radvd.

Well, I created a crude hotplug that only monitors the first interface listed in radvd config and restarts radvd, if the interface gets 'ifup'. (I used the miniupnpd hotplug as a model.)

It seems to work for me and in now included in my r25626 builds.

/etc/hotplug.d/iface/92-radvd

#!/bin/sh

/etc/init.d/radvd enabled && [ -n "`pidof radvd`" ] && {
        local intif="$(uci_get radvd @interface[0] interface)"
        [ "$ACTION" = "ifup" ] && [ "$INTERFACE" = "$intif" ] && {
                logger -t radvd-hotplug "Ifup for interface '$intif', restart radvd"
                /etc/init.d/radvd restart

        }
}

6in4 hotplug changed added.

jow wrote:

6in4 hotplug changed added.

Thanks. As you have also patched the Luci trunk to take care of radvd restart, it looks like I can drop my 6in4 & radvd patches for Trunk builds. ;-)

After building a new version (Trunk r25631 and Luci r6922), it seems to me that the radvd-oriented change in Luci for ucitrack fails. Radvd is not getting restarted when network changes. There is nothing in the syslog about radvd 1.7 starting , and the previously mentioned errors start to appear:

Feb 20 23:09:23 OpenWrt daemon.warn radvd[2057]: resetting ipv6-allrouters membership on br-lan
Feb 20 23:09:23 OpenWrt daemon.warn radvd[2057]: sendmsg: No such device

(This actually matches my previous experience from yesterday. I tried first the Ucitrack way, but when it did not succeed, I wrote the hotplug script.)

So, I think that the Luci change 6922 does not produce the result seeked.
http://luci.subsignal.org/trac/changeset/6922

I have updated  both Trunk and Backfire to r25662.

My build should now properly reconnect the 6in4 tunnel and also restart radvd so that it will continue passing IPv6 routing information in LAN.

As neither the Ucitrack change nor the Luci changes (Luci r6923) seemed to make the radvd to restart properly, I have still included the 92-radvd hotplug script.  (The script only monitors the first interface in its interface list, so it is not perfect, but should be enough for most users without multiple IPv6 segments in LAN or multiple LANs.)

this needs to be changed to affect native IPv6 as well, not just 6in4

I decided to update to the 3/29 Backfire build you just created, and it runs fine so far but there's an issue installing the DynDNS support. Previously I was running WNDR3700-backfire-r25877-2011-03-05-1012 and "opkg install luci-app-ddns" worked fine. At the time, it installed a package from the svn luci branch.

Now with WNDR3700-backfire-r26359-2011-03-29-2112, the same opkg install fetches from the luci 0.9.0 branch, and fails because the build is using an svn luci. Is this a repository issue?

root@Upstairs /root# opkg update
Downloading http://downloads.openwrt.org/backfire/10.03/ar71xx/packages/Packages.gz.
Inflating http://downloads.openwrt.org/backfire/10.03/ar71xx/packages/Packages.gz.
Updated list of available packages in /var/opkg-lists/packages.
root@Upstairs /root# opkg install luci-app-ddns
Installing luci-app-ddns (0.9.0-1) to root...
Downloading http://downloads.openwrt.org/backfire/10.03/ar71xx/packages/luci-app-ddns_0.9.0-1_ar71xx.ipk.
Installing luci-core (0.9.0-1) to root...
Downloading http://downloads.openwrt.org/backfire/10.03/ar71xx/packages/luci-core_0.9.0-1_ar71xx.ipk.
Collected errors:
 * check_data_file_clashes: Package luci-core wants to install file /usr/lib/lua/luci/ip.lua
        But that file is already provided by package  * luci-lib-core
 * check_data_file_clashes: Package luci-core wants to install file /usr/lib/lua/luci/debug.lua
        But that file is already provided by package  * luci-lib-core
 * check_data_file_clashes: Package luci-core wants to install file /usr/lib/lua/luci/version.lua
        But that file is already provided by package  * luci-lib-core
 * check_data_file_clashes: Package luci-core wants to install file /usr/lib/lua/luci/util.lua
        But that file is already provided by package  * luci-lib-core
 * check_data_file_clashes: Package luci-core wants to install file /usr/lib/lua/luci/init.lua
        But that file is already provided by package  * luci-lib-core
 * check_data_file_clashes: Package luci-core wants to install file /usr/lib/lua/luci/ltn12.lua
        But that file is already provided by package  * luci-lib-core
 * check_data_file_clashes: Package luci-core wants to install file /usr/lib/lua/luci/ccache.lua
        But that file is already provided by package  * luci-lib-core
 * check_data_file_clashes: Package luci-core wants to install file /usr/lib/lua/luci/store.lua
        But that file is already provided by package  * luci-lib-core
 * check_data_file_clashes: Package luci-core wants to install file /usr/lib/lua/luci/fs.lua
        But that file is already provided by package  * luci-lib-core
 * opkg_install_cmd: Cannot install package luci-app-ddns.
root@Upstairs /root#

One other quirk - after a reboot, the 6to4 interface did not start automatically. A quick trip to the Luci network setup, WAN6, Save&Apply and it's working.

Not much in the syslog, but initially:

Mar 30 09:26:46 Upstairs user.notice 6to4-wan6: Cannot find wan interface - aborting

and then after doing the above in luci (addresses redacted):

Mar 30 09:26:53 Upstairs user.notice 6to4-wan6: Starting ...
Mar 30 09:26:53 Upstairs user.notice 6to4-wan6:  * IPv4 address is XXXXX
Mar 30 09:26:53 Upstairs user.notice 6to4-wan6:  * IPv6 address is YYYYYY
Mar 30 09:26:53 Upstairs user.info kernel: 6to4-wan6: Disabled Privacy Extensions
Mar 30 09:26:53 Upstairs user.notice 6to4-wan6:  * Adding default route
Mar 30 09:26:54 Upstairs user.notice 6to4-wan6:  * Advertising IPv6 subnet YYYYYY on lan (br-lan)
Mar 30 09:26:54 Upstairs daemon.warn radvd[4219]: Exiting, sigterm or sigint received.
Mar 30 09:26:55 Upstairs daemon.info dnsmasq-dhcp[2434]: DHCPDISCOVER(br-lan) MMMMMM 
Mar 30 09:26:55 Upstairs daemon.info dnsmasq-dhcp[2434]: DHCPOFFER(br-lan) XXXXXX MMMMMM
Mar 30 09:26:55 Upstairs daemon.info dnsmasq-dhcp[2434]: DHCPREQUEST(br-lan) XXXXXX MMMMMM
Mar 30 09:26:55 Upstairs daemon.info dnsmasq-dhcp[2434]: DHCPACK(br-lan) XXXXXX MMMMMM ZZZZZZ
Mar 30 09:26:55 Upstairs daemon.info radvd[4677]: version 1.7 started
tt wrote:

I decided to update to the 3/29 Backfire build you just created, and it runs fine so far but there's an issue installing the DynDNS support. Previously I was running WNDR3700-backfire-r25877-2011-03-05-1012 and "opkg install luci-app-ddns" worked fine. At the time, it installed a package from the svn luci branch.

Now with WNDR3700-backfire-r26359-2011-03-29-2112, the same opkg install fetches from the luci 0.9.0 branch, and fails because the build is using an svn luci. Is this a repository issue?

Actually, you are seeing the fallback from a correction of a month old erroneoeus check-in, which Jow corrected yesterday: https://dev.openwrt.org/changeset/26359

During the past month, the Backfire builds have inadvertently fetched modules from Openwrt trunk depository, which has not been the intention.


And Backfire as default is currently building out of Luci-0.10, not 0.9 any more, and this has changes after Backfire 10.1-rc4, so there are no current packages available...
So, fetching packages from the Backfire depository will produce errors for you in any case.

But I am building from Luci trunk, (as there is not much difference between Luci trunk and 0.10, but Luci trunk has some better features). And Luci trunk is used by OpenWrt trunk, so those Luci modules should be compatible.

If you change your /etc/opkg.conf to again fetch packages from OpenWrt trunk snapshots depository, you should probably be able to get compatible packages for Luci.

tt wrote:

One other quirk - after a reboot, the 6to4 interface did not start automatically. A quick trip to the Luci network setup, WAN6, Save&Apply and it's working.

Not much help is available from me, as I only have 6in4 functionality, so I can't test 6to4 by myself.

hnyman wrote:

If you change your /etc/opkg.conf to again fetch packages from OpenWrt trunk snapshots depository, you should probably be able to get compatible packages for Luci.

Ok, thanks. Speaking of trunk, do you recommend your "trunk" build over the "backfire" one? I have been preferring your backfire build because it requires less manual intervention from me, for example after an upgrade the trunk build requires changing the IP address from the 192.168.1.1 default. The backfire build retains my changed setting across the upgrade. What functional differences should I expect when running trunk?

One tiny feature request though - if you could include the luci-app-ddns (and ddns-scripts which it needs) packages by default, your build would be just a teeny-weeny bit better. :-)

tt wrote:

Speaking of trunk, do you recommend your "trunk" build over the "backfire" one?...

One tiny feature request though - if you could include the luci-app-ddns (and ddns-scripts which it needs) packages by default, your build would be just a teeny-weeny bit better. :-)

I actually prefer the Backfire build, as it seems to cause slightly smaller system load. For testing purposes I have been running trunk & Backfire on a weekly basis, alternating between them every week...

I have not noticed any major differences between the trunk/Backfire versions regarding updates and config files, but I have mainly been updating the config files using an USB stick, just copying my personal settings and leaving all others to defaults. (I have not wanted to copy all config files from build to build, as I want to see if there are any changes to the defaults.)

I included DynDNS script and LuCI in the latest r26378 build. (That DynDNS is a "proper" router functionality, so it fits to my definition of the core components.)

(Last edited by hnyman on 30 Mar 2011, 19:51)

Ok, it's officially the perfect build now. :-) Thanks for including the ddns support. I think I'll stick with your backfire config for now.

To test the 6to4 issue, I backed out to the 3/5, 3/18 and 3/29 builds and it turns out they all behave a little strangely, and all in the same way. The first boot after an upgrade is fine, but subsequent boots generally fail to initialize the 6to4 interface. All other functions are fine. A trip through luci to re-enable is a workaround, or sometimes just waiting a few minutes does it too. Very odd. I wonder if it's a Comcast 6to4 service issue. I'll keep monitoring, see if I can isolate it.

This work is great! nice tip smile