No hesitation, I prefer the old interface

I no longer have IPv6 on the LAN side (r36225). Consequences of recent changes of Cyrus?

Edit: But everything is ok on both sides of the device itself.

Edit2: everything ok on Win XP, only teredo on Win8

Edit3: IPv6 is fully back on my LAN after one night.

(Last edited by Manani on 7 Apr 2013, 09:58)

- r36246: TLS/SSL support added for VSFTPD

TLS/SSL support was added today to vsftpd FTP server. I have included the ssl variant in my build. I struggled a bit in getting the suitable RSA keys created, but finally succeeded and also included the command in the model vsftpd config file. That seemed to require including the openssl command line tool, as I didn't figure out the correct command to generate keys with the built-in px5g command.

command to generate keys (one long command): 
example command to generate key: openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/vsftpd_privkey.pem -out /etc/vsftpd_cert.pem -subj /C="DE"/ST="Saxony"/L="Leipzig"/CN="OpenWrt"

Additions to /etc/vsftpd.conf

ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=NO
force_local_logins_ssl=NO
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
rsa_cert_file=/etc/vsftpd_cert.pem
rsa_private_key_file=/etc/vsftpd_privkey.pem

I placed the keys to /etc but that is probably not quite so optimal, as they did not survive sysupgrade (as they have not been marked as config files). I will probably move my own keys to /etc/config at some point

(Last edited by hnyman on 7 Apr 2013, 15:38)

@hnyman
When I update the router to your latest build the network configuration get messed up, because I'm using a 6in4 tunnel and not a native ipv6 connection.

Before:

...
config interface 'wan'
        option ifname 'eth1'
        option proto 'pppoe'
        option username 'XXXXXXXXXX'
        option password 'XXXXXXXXXX'
...
config interface 'wan6'
        option ifname 'wan6'
        option proto '6in4'
        option mtu '1472'
        option ttl '64'
        option peeraddr XXX.XXX.XXX.XXX'
        option ip6addr 'XXXX:XXXX:XXXX:XX::2/64'
        option ip6prefix 'XXXX:XXXX:XXXX::/48'
...

After:

...
config interface 'wan'
        option ifname 'eth1'
        option proto 'pppoe'
        option username 'XXXXXXXXXX'
        option password 'XXXXXXXXXX'
        option ipv6 1
...
config interface 'wan6'
        option mtu '1472'
        option ttl '64'
        option peeraddr XXX.XXX.XXX.XXX'
        option ip6addr 'XXXX:XXXX:XXXX:XX::2/64'
        option ip6prefix 'XXXX:XXXX:XXXX::/48'
        option ifname @wan
        option proto dhcpv6
...

(Last edited by ferob on 13 Apr 2013, 15:03)

Anyone can help me? (I tried again but failed again... compilations doesn't go to the end, and the nathelper-extra package that I managed to build has also a failed dependency...)

For r36246?

I suspect that it is due to changeset 36278. It forcibly sets some ipv6 relaetd network settings in connection with each firmware flash, overriding the user's previous settings.

https://dev.openwrt.org/changeset/36278

I suggest that you leave "wan6" alone and rename your own tunnel interface to something else, e.g. tunnel6 or whatever.

Ok, I managed to build the kmod-ipt-nathelper-rtsp package individually (finally understood what was needed to do to build it) but I still get a dependency problem for r36246 (that I installed as a bin)

Installing kmod-ipt-nathelper-rtsp (3.8.6+2.1-1) to root...
Collected errors:
* satisfy_dependencies_for: Cannot satisfy the following dependencies for kmod-ipt-nathelper-rtsp:
*     kernel (= 3.8.6-1-82e7ed91d54decbb73e18cce522fa6c6)

How can I ensure that my environment is the same as Hnyman's (I followed his instruction in #2)? I should have the same md5 stamp at the end of the kernel version, shouldn't I?

Or are we forced to compile the complete build with the packages at the same time?

(Last edited by Etique on 17 Apr 2013, 19:52)

We are forced to do that, when we are talking about kernel modules.
We need to build kernel and the kmods in the same compilation run.

(Last edited by hnyman on 17 Apr 2013, 20:47)

Ok. So my only luck is to get the full image to compile.

I tried to force-depends but to no avail.

I cannot get the full image to build... (I can provide the build log if anyone is interested...)

Hnyman, any chance you can compile it for me for your next release ? As a separate package if you don't want to include it in your build?

kmod-ipt-nathelper-rtsp

That would quite help me!

I built that module along the 36370 build. You can download the firmware and the module from http://koti.welho.com/hnyman1/Openwrt/trunk-r36370-2013-04-21/

It works! Thanks a huge lot!

But I'm still disappointed I can't get the image to build. I've really little knowledge on that topic so it's hard for me to debug but... maybe you could have a second look on your second post and check if anything is missing/has changed?

Anyway, thanks again. Now my XBMC setup can play RTSP feeds from my ISP! Awesome.

I had trouble reading the ADSL TV stream. I linked it to a fault with the port forwarding.
With the installation of kmod-ipt-nathelper-rtsp everything is back in order. So I need this package as Etique.
Thank you both.

kmod-ipt-nathelper-rtsp seems to be so small package (a few kB) that I might include it in the default build, as there seems to be more interest for it.

- r36377: dnsmasq 2.66, kmod-ipt-nathelper-rtsp included

Good message!
Thanks

I'd like to say thanks for providing these builds, it's so nice to be able to run a newer release without having to wait for an official release (And I get cool stuff like DHCPv6, codel, better entropy gathering, etc.)

I am a bit confused though about why 6relayd is handling DHCPv6 and not dnsmasq? I personally don't need 6relayd (from what I can see), so it's strange for me to keep it around purely to replicate a feature another software package already provides (if it wasn't compiled out)

By default the ipv6 functionality is not compiled into dnsmasq. I did compile the ipv6 variant for a while, but when ipv6-support (with 6relayd etc.) was introduced, I dropped it and reverted to the vanilla dnsmasq.

6relayd and odhcpd etc. modules make a good job in providing versatile out-of-the-box ipv6 functionality for Openwrt. I think that theis status as own modules makes it easier to adapt the defaults to the changes in the surrounding Openwrt, as the source code can be changed more easily than dnsmasq. And I am not quite sure if dnsmasq-dhcpv6 variant handles all the cases 6relayd currently does.

The main reason I'd prefer to use dnsmasq as the DHCPv6 server is that it adds the v6 address information into it's DNS cache, so existing address lookups will start receiving AAAA responses for LAN hosts.

I'll admit I'm still not entirely sure what the exact use case for 6relayd is though, apart from sharing a given prefix over a layer of routers (so if I added another router to my network it could share the existing /64 range vs. getting a /48 or so)

Well one of the advantages if that you can use it behind other router that only give out addresses to clients (don't support PD) e.g. behind a router given to you by your ISP or you want to use a WiFi in client-mode as your wan-interface.

Also if you have a regular /48 or /56 or so from your ISP / tunnelprovider it can now also act as a DHCPv6-PD server and you can distribute a part of your prefix to another router.

It is also more standards compliant and smaller in size compared to dnsmasq's DHCPv6 features so in the end a bit more versatile for a variety of environments it can be used in.

If this all doesn't matter to you, nobody is discouraging you from using dnsmasq. It's a great peace of software in the end and it supports stateful DHCPv6 for clients if you are into that and - as you mentioned - it takes the hostname obtained from DHCPv4 and resolves it to the IPv6 addresses.

However I personally don't see this as essential.
The whole hostname reporting this is not really well thought of or implemented in the major OS (not a problem of dnsmasq but IPv6 / DHCPv6 in general) and so the current solutions or workarounds like the ones in dnsmasq don't really work reliably without additional IPv4 connectivity so why not simply resolve to IPv4 in the first place.

(Last edited by CyrusFF on 23 Apr 2013, 13:08)

Yeah, my setup isn't the ideal mix for it (My current ISP doesn't so IPv6 so I'm using a /64 from HE, the ISP I want to switch to does DHCPv6-PD, and I only have 1 router on my entire network so I don't need a /48 or so for multiple subnets) And I did run into issues with DHCPv6 when I was testing dnsmasq in a VM, OS X being the worst offender there (It was renewing the lease every 40 seconds, and never provided a hostname, so it would have had to fallback to the v4/SLAAC mix/hack)

It wasn't ever a deal breaker for me, I just didn't expect the behaviour when upgrading from backfire (It's all working fine, I should be clear about that). And if 6relayd works better in more situations then good.

- Attitude Adjustment 12.09 r36423, equal to 12.09 release

Attitude Adjustment 12.09 has been released today. The release was tagged today and the AA sources got modified by r36421-36422 to show the release version and the release package repository directory.

I have built version r36423 that matches the release functionality and points to the correct package directory, so that opkg can install from the release package repository.
http://koti.welho.com/hnyman1/Openwrt/attitude-r36423-2013-04-25-release12.09/

I will probably continue building AA every now and then if there are any larger changes, but based on the last few months I do not expect to lots of backporting current trunk functionality to AA. Instead the devs will probably branch BB in the next few months and concentrate on releasing that.

(Last edited by hnyman on 25 Apr 2013, 17:49)

Hi Hnyman,

I'm trying to setup strongswan using the wiki article:
http://wiki.openwrt.org/inbox/strongswan.howto

I'm loading below packages
After re-loading the firewall the router gets trashed and enter reboot-loop and I have to go to tftp for recovery.

I'm thinking kmod-ipt-ipsec or iptables-mod-ipsec are causing problems.

Any chance you can include (or make module available) for kmod-ipt-ipsec and iptables-mod-ipsec in the next build?

-Rolf

opkg update
opkg install --force-depends kmod-ipt-ipsec
opkg install --force-depends strongswan-default
opkg install --force-depends strongswan-mod-dhcp
opkg install --force-depends strongswan-mod-af-alg
opkg install --force-depends strongswan-mod-gcrypt
opkg install --force-depends strongswan-mod-blowfish
opkg install --force-depends strongswan-mod-md4
opkg install --force-depends strongswan-mod-openssl
opkg install --force-depends strongswan-mod-pkcs11
opkg install --force-depends strongswan-mod-pkcs8
opkg install --force-depends strongswan-mod-test-vectors
opkg install --force-depends strongswan-mod-farp
opkg install --force-depends iptables-mod-ipsec

(Last edited by rolfl on 26 Apr 2013, 04:42)

I found that to perform an update makes packages incompatible even with the option --force-depends. The update seems to change the md5sum. This was the case during the brief period when Hnyman gave us separately the package kmod-ipt-nathelper-rtsp.
The ideal would be to have packages for each version Hnyman. But I guess it must be complicated, or long to make, or a question of space, or everything at once.

(Last edited by Manani on 26 Apr 2013, 19:45)

The advice in https://forum.openwrt.org/viewtopic.php?pid=127011#p127011 is still quite valid. I have just re-created my build-environment in a brand new Ubuntu 13.04 x64.

Log of the actual commands I used is below. I did the steps in a slightly different order than the original advice, as I downloaded patches early and then edited the newOpenwrtBuildroot.sh script to have the correct patch filenames. That enabled me to uncomment the patch command lines at the end of newOpenwrtBuildroot.sh, so that script did also the patching on the same run. (I have modified the current advice to reflect this.)

I have removed a few unnecessary 'ls' commands etc., but all actual commands are here:

STEP 1-3
    2  cd /
    3  sudo mkdir Openwrt
    4  chown perus Openwrt/
    5  sudo chown perus Openwrt/
    6  chmod 777 Openwrt/
    7  cd Openwrt/
    9  wget http://koti.welho.com/hnyman1/Openwrt/trunk-r36462-2013-04-27/WNDR3700-trunk-r36462-2013-04-27-1017-buildscripts.txt
   15  chmod 744 WNDR3700-trunk-r36462-2013-04-27-1017-buildscripts.txt 
   16  ./WNDR3700-trunk-r36462-2013-04-27-1017-buildscripts.txt 
   18  chmod 744 newOpenwrtBuildroot.sh 

STEP 4
   22  wget http://koti.welho.com/hnyman1/Openwrt/trunk-r36462-2013-04-27/WNDR3700-trunk-r36462-2013-04-27-1017-luci-trunk.patch
   23  wget http://koti.welho.com/hnyman1/Openwrt/trunk-r36462-2013-04-27/WNDR3700-trunk-r36462-2013-04-27-1017-openwrt.patch
   24  wget http://koti.welho.com/hnyman1/Openwrt/trunk-r36462-2013-04-27/WNDR3700-trunk-r36462-2013-04-27-1017-packages.patch
   25  wget http://koti.welho.com/hnyman1/Openwrt/attitude-r36423-2013-04-25-release12.09/WNDR3700-attitude-r36423-2013-04-25-1916-luci-0.11.patch
   26  wget http://koti.welho.com/hnyman1/Openwrt/attitude-r36423-2013-04-25-release12.09/WNDR3700-attitude-r36423-2013-04-25-1916-openwrt.patch
   27  wget http://koti.welho.com/hnyman1/Openwrt/attitude-r36423-2013-04-25-release12.09/WNDR3700-attitude-r36423-2013-04-25-1916-packages.patch

STEP 5  (correct patch names and uncomment the lines so that patches will also get done. I only edited the six patch names and uncommented all commands in that section)
   29  gedit newOpenwrtBuildroot.sh &

STEP 6
   30  ./newOpenwrtBuildroot.sh 

STEP 7
   32  cd trunk/
   33  svn status
   34  cd feeds/packages
   40  svn status
   41  svn add utils/collectd/patches/140-fix-fqdnlookup.patch
   62  cd /Openwrt/attitude/
   63  svn status
   64  cd feeds/packages
   66  svn status
   67  svn add utils/collectd/patches/910-upstream-fixes-after-4-10-7.patch
   68  svn add utils/collectd/patches/920-fix-ping-droprate.patch

STEP 8
   75  cd /Openwrt
   76  cp *.sh trunk/
   78  chmod 755 trunk/*.sh
   82  cp *.sh attitude/
   83  chmod 755 attitude/*.sh

BUILD
   84  cd trunk
   85  cp .config.init .config
   86  ./updateNmake.sh

After the build I noticed that I had changed newOpenwrtBuildroot.sh by editing its patch section before copying the files to the new trunk and attitude directories. So I unpacked the scripts again and recopied that script to keep the original one intact (patch commands commented out).

RE-UNPACK newOpenwrtBuildroot.sh AND COPY IT AGAIN
   94  cd /Openwrt
   95  ./WNDR3700-trunk-r36462-2013-04-27-1017-buildscripts.txt 
   98  cp newOpenwrtBuildroot.sh trunk/
   99  cp newOpenwrtBuildroot.sh attitude/

I will probably modify the script a bit to make it easier to keep the original script and will edit the advice accordingly. (EDIT: new steps 3b and 3c added)

(Last edited by hnyman on 28 Apr 2013, 17:52)