Atom Feed
Comments Atom Feed


Similar Articles

05/04/2014 22:23
OpenWrt on RB450G for AAISP FTTC II (12.09: Attitude Adjustment)
17/11/2010 18:40
OpenWrt on RB450G for AAISP FTTC
24/04/2010 10:31
OpenWrt Take 2 - native IPv6 on DG834 v3 (using AAISP)
23/01/2010 18:41
OpenWrt with native IPv6 on DG834 v2 (using AAISP)
12/03/2016 15:33
PHP Zend opcache on Cacti via SNMP
22/11/2009 16:49
Postfix stats on Cacti (via SNMP)

Recent Articles

17/07/2016 15:23
AWS ssh known_host sync
11/07/2016 08:42
File integrity and log anomaly auditing Updated (like fcheck/logcheck)
30/05/2016 13:09
Xenial LXC Container on Debian
12/03/2016 15:33
PHP Zend opcache on Cacti via SNMP
11/03/2016 13:11
Git on (Smart) HTTP with read/write authentication

Glen Pitt-Pladdy :: Blog

OpenWrt on Netgear WNDR3700v2 for AAISP FTTC (14.07: Barrier Breaker)

Previously I've written about running the AAISP FTTC service on OpenWrt with Routerboard RB450G to be able to get native IPv6 and comprehensive firewalling. Changes in my plans means that being able to run wireless links from the edge router is a big advantage now and the RB450G is a cable/ethernet router, hence switching platforms to one with built-in wireless.

After lots of research I settled on the Netgear WNDR3700 v2 for having gigabit ports all round and dual-band wireless. It is not up to the same level on memory, but adequate for most uses (ie. no heavy applications in the mix). A bonus is that they come up on eBay periodically for not a lot of money so having a spare on hand for any problems is negliagable extra cost.

Download and Install

This is trivial with the pre-built image for the WNDR3700v2 available. Download the openwrt-ar71xx-generic-wndr3700v2-squashfs-factory.img image and simply load it as you would a regular fimware update through the web interface of the router. There are de-bricking instructions on the OpenWrt site, but I've not had any problems so never needed to try this.

To access this I connected a laptop with DHCP to the LAN ports on the router and telneted to and set the password with passwd. After that ssh is enabled and you can continue using that and the LuCI web interface.


For simplicity I use LuCI for most configuration and it's improved loads since prvious version so stuff now "just works".

Initial settings with LuCI

Under System->System Set:

  • Timezone
  • NTP server (eg.

At this point you can go ahead and configure the network. I've left the basic setup with the br-lan bridged network between Ethernet and wireless. I've removed the wan6 interface since this is not needed with the native IPv6 from AAISP. I'm using a no-NAT setup, but you can vary the setup for your requirements.

For the AAISP config it can be configured in LuCI similar to this:

OpenWrt on WNDR3700v2 AAISP FTTC Configuration - General


The correct physical interface will also need setting. In this case if you are using the Yellow "WAN" Socket then it will be eth1 as below:

OpenWrt on WNDR3700v2 AAISP FTTC Configuration - Physical


Finally, you may also like to thne the LCP Echo settings to quickly detect and drop failed connections. In this case an echo every 5 seconds, and drop after 5 failures which should mean reconnecting within something like 25-30 seconds of a failure occuring:

OpenWrt on WNDR3700v2 AAISP FTTC Configuration - Advanced


This yields an interface in /etc/config/network something like this:

config interface 'wan'
        option ifname 'eth1'
        option _orig_ifname 'eth1'
        option _orig_bridge 'false'
        option proto 'pppoe'
        option username 'yourusername@a'
        option password 'supersecretpassword'
        option ipv6 '1'
        option keepalive '5 5'

At this point IPv4 data should work, but after much head-scratching about why IPv6 was not working I came to the conclusion that it's not longer setting an IPv6 default route for the PPPoE link as it was in previous versions. The solution seems to be to do something similar to what is on AAISPs Wiki about setting this up on Linux and create a hotplug script to set the route when needed.

In my case I created /etc/hotplug.d/iface/00-local-ppp-ipv6 script containing:


if [ "$INTERFACE" = "wan" ]; then
    case "$ACTION" in
            # put in our default route via this interface
            route -A inet6 add default dev "$DEVICE"
            # clean up
            route -A inet6 del default

Then set this executable:

chmod +x /etc/hotplug.d/iface/00-local-ppp-ipv6

When the pppoe-wan interface comes up now it will set the IPv6 default route to that which makes IPv6 work for me.


This is largely the same as before - things to think about to make the router more secure.

ssh (dropbear)

Out the box this listens on all interfaces, but as a safety measure it's probably best to limit it to the LAN interface. In LuCI this can be done simply by selecting the LAN interface in System->Administration, else via the shell yielding an /etc/config/dropbear file something like:

config dropbear
    option PasswordAuth 'on'
    option Port '22'
    option Interface 'lan'

uhttpd / LuCI

Same here - this can be restricted to only listening on the LAN addresses by changing /etc/config/uhttpd to listening on the LAN IP addresses:

list listen_http        router.lan.ip.addr:80
list listen_http        [router:lan:ipv6::addr]:80
list listen_https       router.lan.ip.addr:443
list listen_https       [router:lan:ipv6::addr]:443

Then to bring this config into use restart uhttpd with /etc/init.d/uhttpd restart

Serial Port

Previously I locked this down, however since you need to take the router apart to get to this and make up an adaptor, I haven't bothered this time. If someone wants to go to that extent of actually messing with hardware there are far worse things they can do, so physical security is really the key thing this time round.


An important bit is to get a firewall setup. This can be done through LuCI or the shell as always, however if like me you need something more complex then /etc/firewall.user provides a shell scripting option. I've customized mine extensively with over 500 lines of code which processes my own format of rule sets as well as a bunch of sub-scripts which are included for flexibility when configuring the rules and behaviour for both IPv4 and IPv6.

One thing to notice has changed since earlier versions is that many more chains are created in more of the tables than before. If like me you really want to start clean then you will need to flush and delete all non-builtin chains which can be done with a pair of loops (IPv4 and IPv6) along the lines of:

for table in filter nat mangle raw; do
        iptables --table $table --flush
        iptables --table $table --delete-chain
for table in filter mangle raw; do
        ip6tables --table $table --flush
        ip6tables --table $table --delete-chain

Another thing I discovered was that I was getting a lot of backscatter (presumably from others faking source addresses with mine) of ICMP type 3 and TCP with SYN and ACK set, and the firewall was letting these straight through. Fortunately I have multiple layers of firewalling and logging enabled.

This hadn't happened on previous OpernWrt versions and a bit of digging turned up that nf_conntrack_skip_filter is enabled by default in the current version to save on resource usage.... well, I've decided I prefer to have clean firewalling that I know is safe so I've disabled this.

My full script is way to complex to share - if you are doing stuff like that then no doubt you will already be intimately familiar with iptables/ip6tables, IP networking and not need an example to work from. For most people I'm guessing LuCI is probably the way to go, but the option is there if you require something more heavy duty.


As before, I deploy a load of extra things to make everything work smoothly. Adaptions from before for the WNDR3700v2 are here.

Backup & dropbear keys

I use Dirvish (rsync based) for backups. To be able to use ssh key authentication for this either add the key in /etc/dropbear/authorized_keys or via LuCI in System->Administration.

This also requires installing rsync (automatically adds libpopt).

This brings the backups online and the entire system can be backed up like this.

Remote logging

Previously I was using syslog-ng3 for remote logging, however now the default logging seems to work fine with the remote option all I had to do was set the IP of the my log server in LuCi under System -> System -> Logging which yeilds a /etc/config/system of:

config system
    option zonename 'Europe/London'
    option timezone 'GMT0BST,M3.5.0/1,M10.5.0'
    option conloglevel '8'
    option cronloglevel '8'
    option log_ip 'ip.of.log.server'
    option hostname 'whateveryourhostnameis'


I run email notifications when events occur (potentially bad ones) on the WAN interface. For these we need to be able to send mail and I used mini-sendmail which will need installing before these can be used.

The /etc/ppp/if-*.d/ scripts are deprecated in Attitude Adjustment, preferring instead to use /etc/hotplug.d/iface/ scripts so I have updated and adapted my previous scripts for this.

Download: OpenWrt Hotplug Mail on Interface Up/Down

This simply emails on Interface up or down events. Configure the variables for mail servers etc. before use.

Download: OpenWrt check for BT test connection and restart WAN

Sometimes faults occur where DSL connections get switched to BTs test connections which are to a private test network. This basically means all internet connectivity is lost and until the connection drops or resets the router remains happily connected to an unusable service. If I'm away from home that means an awful lot of downtime could result so this script takes care of it automatically and both emails and restarts the WAN interface if the expected (static) WAN IP address isn't present. Again, configure the variables for mail servers etc. and the expected IP. If you are with another ISP which uses dynamic addresses then you will need to tweak this script to pattern match rather than use a fixed IP.

So that you can still send email when there are connectivity problems add the mail server into the hosts list in LuCI or in /etc/config/dhcp as follows:

config domain
        option name 'mail.yourdomain.tld'
        option ip 'ip.of.mail.server'

Cacti Monitoring

Previously I provided scripts and templates for Cacti to monitor the router. Little has changed however there have been various improvements and an update to work with uhttpd rather than the busybox httpd.

Download: OpenWrt CGI Monitoring Scripts

Unpack these in /www/cgi-bin/ and they should go into monitor/ providing various monitoring data via http. If required access to these could be locked down further, however as they take no input and are only served on the LAN (by config above) currently they are left open.

Additionally we need to flag the time that the WAN interface came up and for that there is another script to go in /etc/hotplug.d/iface/

Download: OpenWrt Interface Monitoring Script

We are still using largely the same Python Input Scripts for Cacti to collect the data. These should be unpacked into /usr/local/share/cacti/scripts on Debian based systems otherwise where is appropriate for your system and adapt the templates to match.

Download: OpenWrt WNDR3700v2 Cacti Input Scripts

Plus we have a improved Template.

Download: OpenWrt WNDR3700v2 Cacti Template

This is what you can expect in the way of graphs:

OpenWRT WNDR3700v2 PPP Status Cacti Graph

OpenWRT WNDR3700v2 Processes

OpenWRT WNDR3700v2 CPU Usage Cacti Graph

OpenWRT WNDR3700v2 WAN Bytes Cacti Graph

OpenWRT WNDR3700v2 WAN Packets Cacti Graph

OpenWRT WNDR3700v2 LAN Bytes Cacti Graph

OpenWRT WNDR3700v2 LAN Packets Cacti Graph

OpenWRT WNDR3700v2 IP Conntrack Cacti Graph

OpenWRT WNDR3700v2 Load Average Cacti Graph

OpenWRT WNDR3700v2 Memory Usage Cacti Graph

OpenWRT WNDR3700v2 PPPoE Bytes Cacti Graph

OpenWRT WNDR3700v2 PPPoE Packets Cacti Graph


Update Checking

Occasionally (eg. with openssl Heart Bleed bug) updates are released so worth checking. I've created a very simple script to do this

Download: OpenWrt package Update Check Script

This needs settings updating and then can be run from CRON as often as you want with an appropriate entry in /etc/crontabs/root or via LuCI in System -> Scheduled Tasks.


Are you human? (reduces spam)
Note: Identity details will be stored in a cookie. Posts may not appear immediately