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.

Hi Hnyman,

How easy would it be to install OpenVPN & conntrack-rtsp on your build? Do I need to rebuild it or can I just build the packages?

Cheers!

Etique wrote:

How easy would it be to install OpenVPN & conntrack-rtsp on your build? Do I need to rebuild it or can I just build the packages?

You might even try just installing the openvpn from the snapshot repository, because the installation includes no kernel mods.

conntrack is probably more difficult, you probably need to compile the whole firmware.


EDIT:
I tried installing openvpn to my 3.6.7 build from snapshot repository, and at least it didn't crash the router immediately ;-)
Not sure if it works, though...
Based on the install log in luci, the installation checked kmod-tun, for which it absolutely should keep my version instead of the snapshot version.

Installing openvpn (2.2.2-2) to root...
Downloading http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/openvpn_2.2.2-2_ar71xx.ipk.
Multiple packages (kmod-tun and kmod-tun) providing same name marked HOLD or PREFER. Using latest.
Installing liblzo (2.06-1) to root...
Downloading http://downloads.openwrt.org/snapshots/trunk/ar71xx/packages/liblzo_2.06-1_ar71xx.ipk.
Configuring liblzo.
Configuring openvpn.
BusyBox v1.19.4 (2012-11-21 19:33:19 EET) built-in shell (ash)
Enter 'help' for a list of built-in commands.

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 BARRIER BREAKER (Bleeding Edge, r34288)
 -----------------------------------------------------
  * 1/2 oz Galliano         Pour all ingredients into
  * 4 oz cold Coffee        an irish coffee mug filled
  * 1 1/2 oz Dark Rum       with crushed ice. Stir.
  * 2 tsp. Creme de Cacao
 -----------------------------------------------------
root@OpenWrt:~# which openvpn
/usr/sbin/openvpn
root@OpenWrt:~# openvpn
Usage message not available
root@OpenWrt:~# uname -r
3.6.7

(Last edited by hnyman on 21 Nov 2012, 21:16)

It's actually not conntrack-rtsp, but kmod-ipt-nathelper-rtsp.

Cheers! Will give it a try smile

Ok, Openvpn installed and works! smile

but I need to recompile kmod-ipt-nathelper-rtsp.

Installing kmod-ipt-nathelper-rtsp (3.3.8+1.45-1) to root...
Downloading http://downloads.openwrt.org/snapshots/ … r71xx.ipk.
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-ipt-nathelper-rtsp:
*     kernel (= 3.3.8-1-231112e548aba152810eababd16134bc) *
* opkg_install_cmd: Cannot install package kmod-ipt-nathelper-rtsp.


I'm not sure why I can't install, as you're using the trunk kernel. Is the kernel hash linked to the SVN version? (I'm on r34280)

Search for opkg --force.

It is even tighter, as it practically requires kmod to be compiled along the kernel

hnyman wrote:

- Trunk 33311: gcc compiler: code optimization for 24kc processors (instead of the general mips32r2)

Did you add this manually by editing the .config file? I noticed that if you run "make menuconfig", the gcc optimization goes back to the default mips32r2. Do you know how to make them stick in the config file?

phuque99 wrote:
hnyman wrote:

- Trunk 33311: gcc compiler: code optimization for 24kc processors (instead of the general mips32r2)

Did you add this manually by editing the .config file? I noticed that if you run "make menuconfig", the gcc optimization goes back to the default mips32r2. Do you know how to make them stick in the config file?

I first added that optimization in menuconfig and then copied the three changed lines to my .config recipe. Look at the source code diffs.

CONFIG_DEVEL=y
CONFIG_TARGET_OPTIONS=y
CONFIG_TARGET_OPTIMIZATION="-Os -pipe -march=24kc -mtune=24kc -fno-caller-saves"

You can do the same in menuconfig:
Advanced configuration options (for developers) --> Target Options --> Target Optimizations

If you want to use exactly same build options, you can get my .config.init from here:
http://koti.welho.com/hnyman1/Openwrt/trunk-r34318-2012-11-24/

Copy this file as your .config, run "make defconfig" and you will have the exactly same .config as I and you can use menuconfig to add kmods: http://koti.welho.com/hnyman1/Openwrt/t … onfig.init

All my build scripts are in http://koti.welho.com/hnyman1/Openwrt/t … cripts.txt

(Last edited by hnyman on 25 Nov 2012, 10:10)

hnyman wrote:
CONFIG_DEVEL=y
CONFIG_TARGET_OPTIONS=y
CONFIG_TARGET_OPTIMIZATION="-Os -pipe -march=24kc -mtune=24kc -fno-caller-saves"

You can do the same in menuconfig:
Advanced configuration options (for developers) --> Target Options --> Target Optimizations

If you want to use exactly same build options, you can get my .config.init from here:
http://koti.welho.com/hnyman1/Openwrt/trunk-r34318-2012-11-24/

Copy this file as your .config, run "make defconfig" and you will have the exactly same .config as I and you can use menuconfig to add kmods: http://koti.welho.com/hnyman1/Openwrt/t … onfig.init

All my build scripts are in http://koti.welho.com/hnyman1/Openwrt/t … cripts.txt

Thanks hnyman. Are these target optimization inherited and used for the kernel compile? Or do I also have to manually modify "target/linux/ar71xx/Makefile" to add these optimization flags for the Linux kernel?

phuque99 wrote:
hnyman wrote:
CONFIG_DEVEL=y
CONFIG_TARGET_OPTIONS=y
CONFIG_TARGET_OPTIMIZATION="-Os -pipe -march=24kc -mtune=24kc -fno-caller-saves"

You can do the same in menuconfig:
Advanced configuration options (for developers) --> Target Options --> Target Optimizations

Are these target optimization inherited and used for the kernel compile? Or do I also have to manually modify "target/linux/ar71xx/Makefile" to add these optimization flags for the Linux kernel?

They are used for all target compilation, both kernel and packages.
It overrides the default provided by "target/linux/ar71xx/Makefile".

hnyman wrote:

It overrides the default provided by "target/linux/ar71xx/Makefile".

I'm not sure if I missed anything else. I have the optimization flag set for "24kc". I noticed on the verbose output during compilation, various packages were compiled with the 24kc flag.

However during kernel compilation phase, I checked the ps output and saw that it was using the default "-march=mips32r2" optimization. I wonder if I missed anything.

openuser    30047  0.0  0.0   4636   636 pts/2    S+   11:57   0:00 mips-openwrt-linux-uclibc-gcc -Wp,-MD,net/ipv4/netfilter/.ip_tables.o.d -nostdinc -isystem /home/openuser/trunk/staging_dir/toolchain-mips_gcc-4.6-linaro_uClibc-0.9.33.2/lib/gcc/mips-openwrt-linux-uclibc/4.6.4/include -I/home/openuser/trunk/build_dir/linux-ar71xx_generic_uClibc-0.9.33.2/linux-3.6.7/arch/mips/include -Iarch/mips/include/generated -Iinclude -include /home/openuser/trunk/build_dir/linux-ar71xx_generic_uClibc-0.9.33.2/linux-3.6.7/include/linux/kconfig.h -D__KERNEL__ -DVMLINUX_LOAD_ADDRESS=0xffffffff80060000 -DDATAOFFSET=0 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -fno-delete-null-pointer-checks -Os -fno-caller-saves -mno-check-zero-division -mabi=32 -G 0 -mno-abicalls -fno-pic -pipe -msoft-float -ffreestanding -march=mips32r2 -Wa,-mips32r2 -Wa,--trap -I/home/openuser/trunk/build_dir/linux-ar71xx_generic_uClibc-0.9.33.2/linux-3.6.7/arch/mips/include/asm/mach-ath79 -I/home/openuser/trunk/build_dir/linux-ar71xx_generic_uClibc-0.9.33.2/linux-3.6.7/arch/mips/include/asm/mach-generic -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -DCC_HAVE_ASM_GOTO -DMODULE -mno-long-calls -DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(ip_tables) -DKBUILD_MODNAME=KBUILD_STR(ip_tables) -c -o net/ipv4/netfilter/ip_tables.o net/ipv4/netfilter/ip_tables.c

Looks like at least that module usea totally different compilation options, which might be hardcoded to it, or something like that. I will check my own build logs.

I ran "make clean" for my trunk build with normal kernel 3.3.8 and then a normal make with V=s to create a detailed build log.

The build log contained 32505 lines, of which 4637 contained the "-march" option.
Of these, 4631 lines had "24kc" and only 6 lines had "mips32r2".
So, it looks like you have managed to spot one of the few exceptions belonging to that 0.1%.

(I didn't do that for the 3.6.7 kernel that you used, but I see no reason why it should change there.)

(Last edited by hnyman on 27 Nov 2012, 20:23)

hnyman wrote:

Of these, 4631 lines had "24kc" and only 6 lines had "mips32r2".
So, it looks like you have managed to spot one of the few exceptions belonging to that 0.1%.

Thanks for reviewing. I should do a bit more logging to spot these myself. I was afraid that the entire kernel build was hard-coded to use mips32r2.

Am also interested in installing openvpn, and appologize for not understanding the previous discussion - (newbie).

FWICT, either openvpn can be successfully installed from the snapshot repository, or it can be successfully installed after a modification to kmod-ipt-nathelper-rtsp!?

If the modification needs to be made, could/would you please include that change in future hnyman releases?

TIA

(and thanks for a reliable package that I've been using since its inception)

- r34423: kernel 3.6.8, new "ipv6-support" module, kmod-fs-cifs included

The default kernel for ar71xx target was bumped from 3.3.8 to 3.6.8 today. I had already earlier tried 3.6.7 and did not have any problems with it, so I do not expect 3.6.8 to cause any havoc.

Later today r34417-34423 introduced a bunch of ipv6 related changes, which are now included by the new "ipv6-support" metapackage. Apparently the developers' goal is to provide rudimentary ipv6 support at one strike. Those changes are included in my build and did not break my own 6in4 tunnel, but radvd seems to give some warnings. You might need to check your config after this build. (Some of the new functionality is by default commented off in the new config files.) So far I have not seen any discussion or documentation for the new packages introduced.

Additionally, I added the kmod-fs-cifs in the build, providing support for cifs/samba client functionality, so that I can mount the shares from my Linkstation NAS if I want.

98i4rtg wrote:

Am also interested in installing openvpn, and appologize for not understanding the previous discussion - (newbie).

FWICT, either openvpn can be successfully installed from the snapshot repository, or it can be successfully installed after a modification to kmod-ipt-nathelper-rtsp!?

You should probably be able to install openvpn from the snapshot repository (after the next build with kernel 3.6.8 has been completed, see http://buildbot.openwrt.org/builders/ar71xx/builds/99), but I can't guarantee that. And I have no idea, for which purpose the kmod-ipt-nathelper-rtsp would be used...

(Last edited by hnyman on 29 Nov 2012, 22:57)

Sorry for being a bit quiet about yesterday's IPv6 changes.

I already added a wiki-page which explains all the configuration variables here http://wiki.openwrt.org/doc/uci/network6
There are no LuCI pages yet, but new things will come in the following weeks.

Just a few quick tips:
There is no need for radvd and or a separate DHCPv6-server or client anymore. ipv6-support pulls in the relevant packages
and configures them automatically using the settings given in /etc/config/network6.

If you have a native IPv6 connection (e.g. your ISP has a DHCPv6 with prefix delegation) you don't need to do anything.
The default settings will ensure that you will receive the prefix information via DHCPv6 and the logic will automatically split up the prefixes for all downstream interfaces and assign them to them. Our RD-server will notice the new prefixes and automatically announce them.

If you have a native IPv6 connection but the upstream router doesn't support prefix delegation wan and lan are automatically put in relay mode (when not otherwise configured) meaning RD-, DHCPv6 and NDP are proxied so that both interfaces operate in the same /64.

If you have a 6in4 tunnel or an otherwise static configuration use mode=static on the relevant interface and just put your global /48 or /56 in static_prefix and it will be split up and distributed onto the downstream interfaces (lan etc.) as well.

For now I integrated a few newly developed tools for RD & DHCPv6-service which are very small in size (compared to e.g. radvd, wide-dhcpv6, etc.). Support for alternative RD / DHCPv6-servers (like dnsmasq-dhcpv6) might follow later. If you have any feedback please let us know.

PS: Ah yes, and keep up the good work, please ;-)

(Last edited by CyrusFF on 30 Nov 2012, 16:01)

CyrusFF wrote:

Sorry for being a bit quiet about yesterday's IPv6 changes.

I already added a wiki-page which explains all the configuration variables here http://wiki.openwrt.org/doc/uci/network6
...
If you have a 6in4 tunnel or an otherwise static configuration use mode=static on the relevant interface and just put your global /48 or /56 in static_prefix and it will be split up and distributed onto the downstream interfaces (lan etc.) as well.

For now I integrated a few newly developed tools for RD & DHCPv6-service which are very small in size (compared to e.g. radvd, wide-dhcpv6, etc.). Support for alternative RD / DHCPv6-servers (like dnsmasq-dhcpv6) might follow later. If you have any feedback please let us know.

Thanks for info. I will have to analyse that and possibly change the contents of my build.

My build already included the dnsmasq-dhcpv6 variant in addition to radvd, and that worked ok as a radvd replacement, if so required. I also added some uci config support in dnsmasq for ipv6, see https://forum.openwrt.org/viewtopic.php?pid=175200#p175200 ). If the developers' intention is to go forward with the new packages in the ipv6-support package, I will probably drop both dnsmasq-dhcpv6 and radvd.

The advantage with radvd has been its automatic sniffing of the correct /64. I have 3 different ipv6 tunnels, so I have experimented with various configs. I have left /64 definition empty in the radvd config and have just set the LAN interface's static address. Radvd has then used that address to determine the correct /64. At the first glance, your current config requires the user to set /64 for a (static) 6in4 tunnel. It would be great if the package would use LAN's address as the base for a /64 if no address has been defined with a "static_prefix" option.

It is great that there is finally some work with the "out-of-the-box ipv6" functionality. Hopefully ipv6 gets more mainstream. So far it has been left for enthusiasts to a large extent.

EDIT:
After disabling radvd I was able to get my 6in4 tunnel to work by setting option 'request_prefix' to 'no' for wan and setting the correct /64 prefix with 'static_prefix' option after also renaming the section according to the tunnel interface's name.

It would greatly improve your wiki documentation, if you would include clear examples of those three cases you described for me.

(Last edited by hnyman on 30 Nov 2012, 16:55)

hnyman wrote:

The advantage with radvd has been its automatic sniffing of the correct /64.

Yes, the new small RD-server (6relayd) does exactly the same. It detects all addresses assigned to an interface that have a prefix <= 64 and announces them via RD messages. It also remembers the prefixes it announced last time and deprecates prefixes that were removed (announces them with preferred time=0 and a very low valid time). It also does stateless DHCPv6 to announce the DNS.

The whole configuration mess is exactly the problem that is preventing me from integration dnsmasq-dhcpv6 right now: It might work when you have static prefixes through a tunnel or so, but when prefixes change e.g. on a DSL line and are dynamiccaly acquired you end up having a mess and to constantly reconfigure, check and restart the daemon. Once we can get a suitable solution for this, we might think about integtration dnsmasq-dhcpv6 as an alternative, mainly because it supports stateful DHCPv6 as well which the 6relayd-server does not,  but we will se what the time brings.

hnyman wrote:

At the first glance, your current config requires the user to set /64 for a (static) 6in4 tunnel. It would be great if the package would use LAN's address as the base for a /64 if no address has been defined with a "static_prefix" option.

Hmm this might be a misunderstanding. The idea of the new IPv6-stuff is that you don't have to manually assign interfaces on the lan-side anymore. This will be done automatically. If you want to do 6in4 with it, I'd suggest the following (thouhg I haven't tested it with 6in4 yet, but it should work).

When using the 6in4-proto in network e.g.

config interface henet
    option proto    6in4
    ...

leave this as is and just add a section to network6:

config interface henet
        option mode static
        list static_prefix '2001:DB8::/48'

where 2001:DB8::/48 is your routed-prefix (either /48 or /64 etc.).

Once the tunnel comes up (and if the hotplug-scripts are working correctly, haha) a daemon will assign a part of the static_prefix (e.g. a /64) to lan automatically. If you have more than one downstream interface (e.g. another unbridged wifi or so) this will get another /64 from the static prefix (if the static prefix is big enough).

On the downstream interfaces (lan & friends), you only hint on how big your assigned prefix should be, e.g. by setting advertise_prefix to '64' to get a /64 subprefix. The address distribution daemon will take care of the rest so you only need to
set your routed prefix once.

This also works when you have multiple 6in4 or uplinks. Then the lan interface will get one /64 from each tunnel prefix.
Again this is less important for static configuration but is more important for dynamically acquired prefix coming from DHCPv6.



hnyman wrote:

It is great that there is finally some work with the "out-of-the-box ipv6" functionality. Hopefully ipv6 gets more mainstream. So far it has been left for enthusiasts to a large extent.

Yeah the problem is that the current Linux tools for this are not very suitable for routers. Either they were too big or the configuration is too static etc. etc. This mainly meant, rewriting most of the tools from scratch.

CyrusFF wrote:

Hmm this might be a misunderstanding. The idea of the new IPv6-stuff is that you don't have to manually assign interfaces on the lan-side anymore. This will be done automatically. If you want to do 6in4 with it, I'd suggest the following (thouhg I haven't tested it with 6in4 yet, but it should work).

When using the 6in4-proto in network e.g.

config interface henet
    option proto    6in4
    ...

leave this as is and just add a section to network6:

config interface henet
        option mode static
        list static_prefix '2001:DB8::/48'

where 2001:DB8::/48 is your routed-prefix (either /48 or /64 etc.).

Once the tunnel comes up (and if the hotplug-scripts are working correctly, haha) a daemon will assign a part of the static_prefix (e.g. a /64) to lan automatically.

Does not work for me.
I left the router's lan interface's ip6addr unset by commenting it out and now there is no ipv6 connectivity any more. No ipv6 address is shown for the router, neither in Luci nor with ifconfig. (I can can still ping ipv6.google.com from router console, as the 6in4 tunnel still works normally.)

To be exact, with a SixXS (static) tunnel, there is the "tunnel /64" that is used just by the tunnel endpoints and is set manually. Then there is the "routed /48" or /64 which has a separate prefix. I have used to set an address belonging to that prefix for the router's LAN interface with ip6addr option. If I now leave that empty/commented, router's LAN does not get assigned an ipv6 address despite the prefix being given in the static_prefix.

Relevant sections from the config files:

config 'interface' 'lan'
        option 'ifname' 'eth0.1'
        option 'type' 'bridge'
        option 'proto' 'static'
        option 'ipaddr' '192.168.1.1'
        option 'netmask' '255.255.255.0'
#       option 'ip6addr' '2001:14DD:DDDD:ABCD::1/64'

config 'interface' 'sixxs'
        option 'proto' '6in4'
        option 'peeraddr' '62.78.96.38'
        option 'ip6addr' '2001:14DD:B00:25b::2/64'

...
network6:
config interface 'sixxs'
        option mode 'static'
        list static_prefix '2001:14DD:DDDD:ABCD::/64'

(Last edited by hnyman on 30 Nov 2012, 17:29)

Hmm did you also add a section for lan to network6?
If not please try something like this in addition to the section you already have in network6.

config interface 'lan'
        option mode 'downstream'
        option advertise_prefix '64'

I just tested it with a static prefix on a regular ethernet interface

config interface 'wan'
        option mode 'static'
        list static_prefix '2001:DB8::/64'

and it worked, so it can be that the logic doesn't work for 6in4 interfaces yet. I will try to investigate and get back to you if I can find something.

(Last edited by CyrusFF on 30 Nov 2012, 17:39)

CyrusFF wrote:

Hmm did you also add a section for lan to network6?
If not please try something like this in addition to the section you already have in network6.

config interface 'lan'
        option mode 'downstream'
        option advertise_prefix '64'

Yes, my /etc/config/network6 is:

root@OpenWrt:~# cat /etc/config/network6

config interface 'wan'
        option mode 'upstream'
        option request_prefix 'no'
        option prefix_fallback 'relay'
        option peerdns '1'
        option ula_prefix 'fdf3:f5b3:987e::/48'

config interface 'lan'
        option mode 'downstream'
        option advertise_prefix '64'
        option relay_master 'wan'

config interface 'sixxs'
        option mode 'static'
        list static_prefix '2001:14DD:DDDD:ABCD::/64'

Just thinking, if the reason might be the "relay-master" field? Shoud it be "sixxs" as that gives the prefix? EDIT: no, did not help.

(Last edited by hnyman on 30 Nov 2012, 17:48)

No thats not the reason. It must have been something to do with how the 6in4 notifies the rest of openwrt.
Currently compiling an image but don't know if I can manage to fix it before Monday. I'll get back to you with a fix.

Thanks for testing.

Additional info:
Looks like /etc/init.d/network restart is not enough, but reboot is...

I had earlier tested with just a network restart.

I compiled a new firmware (with vanilla dnsmasq) and flashed it while preserving settings. After the reboot the router's LAN interface has now both the manually set ::1 and automatically set addresses:

br-lan    Link encap:Ethernet  HWaddr 76:44:xxx
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::7444:1ff:fe8d:a3e7/64 Scope:Link
          inet6 addr: 2001:xxxxx:abcd:7444:1ff:fe8d:a3e7/64 Scope:Global
          inet6 addr: 2001:xxxxx:abcd::1/64 Scope:Global

So, it looks like some of the new server processes do not get properly activated/restarted with a /etc/init.d/network restart, but do apply the full config correctly in connection with a reboot.


EDIT:
I again commented that manual LAN interafce ip6addr and rebooted. Results were interesting:
It works, but instead of having a random address, the router has now ::1 set automagically as the main address. Intentional? Additionally there is now the ULA address fd...

          inet6 addr: fdf3:f5b3:987e::1/64 Scope:Global
          inet6 addr: fe80::7444:1ff:fe8d:a3e7/64 Scope:Link
          inet6 addr: 2001:xxxxx:abcd::1/64 Scope:Global

That is also properly reflected at my PC, where the ipv6 address for the DNS server has changed correspondingly.

before:
DNS Servers . . . . . . . . . . . : 2001:xxxxx:abcd:7444:1ff:fe8d:a3e7
                                    192.168.1.1

after:
 DNS Servers . . . . . . . . . . . : 2001:xxxxx:abcd::1
                                     192.168.1.1

(Last edited by hnyman on 30 Nov 2012, 18:45)

- r34432: revert to vanilla dnsmasq with no dhcpv6 support. This is also probably the last build with radvd included, as similar basic functionality is now offered by the ipv6-support package.

I will probably remove radvd in the next build, as similar basic functionality is now included in the new ipv6-support package. That change will help to decrease the firmware size by 64 kB, which has impact especially with wndr3700v1.

If you are using my build and are currently using radvd, please experiment with the new packages and see if your needs are fulfilled with it. Documentation in http://wiki.openwrt.org/doc/uci/network6 (and also in this thread by Cyrus a few messages back).

(Last edited by hnyman on 30 Nov 2012, 19:04)