Throughout this documentation, it is assumed that the router has IP address 192.168.0.1. Another computer is needed to do the manipulations. In the following, it will be called client and will have IP address 192.168.0.2.

Once OpenWRT is installed, the network changes to the default of 192.168.1.0/24.

The latest firmware at the time of this writing is 3.01.29.

Based on this documentation.

In debug mode, a telnet server is run on the router. This mode is enabled by visiting http://192.168.0.1/setup.cgi?todo=debug.

An HTTP server is started from /tmp to ease downloading memory dumps. These dumps are then created.

# cd /tmp ; mini_httpd -p 1080
# cat /dev/mtdblock/0 > /tmp/dg834_fw_3.01.29_mtd0.bin
# cat /dev/mtdblock/1 > /tmp/dg834_fw_3.01.29_mtd1.bin
# cat /dev/mtdblock/2 > /tmp/dg834_fw_3.01.29_mtd2.bin
# cat /dev/mtdblock/3 > /tmp/dg834_fw_3.01.29_mtd3.bin
# cat /dev/mtdblock/4 > /tmp/dg834_fw_3.01.29_mtd4.bin

They can then be downloaded at http://192.168.0.1:1080/dg834_fw_3.01.29_mtd[0,1,2,3,4].bin.

client$ wget http://192.168.0.1:1080/dg834_fw_3.01.29_mtd{0,1,2,3,4}.bin

Just in case, the the backup files are here.

Jonathan says: “The boot loader for the DG834 […] has a rather annoying feature; it calculates a checksum over flash and refuses to boot if it doesn't match what's stored. This is fine for the stock Netgear firmware […]. It causes the router to huff after the first OpenWRT boot however. Unless we patch ADAM2 to ignore an incorrect checksum…”

So we patch it after checking that we have the same binary file (which we do). The checksum after the manual patch is what was expected.

client$ md5sum dg834_fw_2.10.22_mtd2.bin
0530bfdf00ec155f4182afd70da028c1  dg834_fw_2.10.22_mtd2.bin
client$ cp dg834_fw_2.10.22_mtd2.bin dg834_fw_2.10.22_mtd2_patched.bin
client$ hexedit dg834_fw_2.10.22_mtd2_patched.bin
[Change '44 09 00 0C' at offset 0x3944 for '00 00 00 00']
client$ md5sum dg834_fw_2.10.22_mtd2_patched.bin
d8a2f4623bf6f64b7427812f0e849aa7  dg834_fw_2.10.22_mtd2_patched.bin

The patched bootloader has to be copied back to the router. Fortunately, the firmware contains a wget binary. The new bootloader image can then be served by an HTTP server anywhere. The easiest may however be to use webfs.

client$ webfsd -p8080

# wget http://192.168.0.2:8080/dg834_fw_3.01.29_mtd2_patched.bin

A quick check to see that the file has been properly sent.

client$ wget -q http://192.168.0.1:1080/dg834_fw_3.01.29_mtd2_patched.bin -O - | md5sum
d8a2f4623bf6f64b7427812f0e849aa7  -

Then the patched ADAM2 can be installed in the flash.

# dd if=dg834_fw_3.01.29_mtd2_patched.bin  of=/dev/mtdblock/2
256+0 records in
256+0 records out

Being extra-paranoid, one can check that the new bootloader has bee installed properly.

# dd if=/dev/mtdblock/2 of=adam2-check.bin
256+0 records in
256+0 records out

client$ wget -q http://192.168.0.1:1080/adam2-check.bin -O - | md5sum
d8a2f4623bf6f64b7427812f0e849aa7  -

Good.

Time to reboot the router and hope for the best.

We testdrive the process by installing an official release (r18961).

The image has to be split to be copied over on two MTDs.

$ dd if=openwrt-ar7-squashfs.bin of=openwrt-ar7-squashfs_mtd1.bin count=720896 bs=1
$ dd if=openwrt-ar7-squashfs.bin of=openwrt-ar7-squashfs_mtd0.bin skip=720896 bs=1

There are several method to upload the OpenWRT image. The “standard” one seems to bo using a feature similar to that called “boot_wait”. In this mode, the bootloader configures a static IP address and waits a tiny bit for an FTP connection which would upload a new firmware. The IP address is configured using the debug mode's telnet access.

# echo "my_ipaddress 192.168.0.1" > /proc/sys/dev/adam2/environment

However, according to this documentation, the firmware upload using boot_wait is risky. Not willing to brick the modem unnecessarily we'll use the dd-based method instead. More detail on the boot_wait technique can be found in Jonathan's documentation.

Indeed, the split OpenWRT image will be copied to the router's /tmp from the webfsd running on the client, then dded to the appropriate mtds.

# cd /tmp
# wget http://192.168.0.2:8080/openwrt-ar7-squashfs_mtd0.bin
# wget http://192.168.0.2:8080/openwrt-ar7-squashfs_mtd1.bin
# dd if=openwrt-ar7-squashfs_mtd1.bin of=/dev/mtdblock/1
1408+0 records in
1408+0 records out
# dd if=openwrt-ar7-squashfs_mtd0.bin of=/dev/mtdblock/0
3712+1 records in
3712+1 records out

Note the inverted order in which the MTDs are flashed. There isn't any explanation about why in the initial documentation, but it may be related to the location of the dd binary, and how it may not work for the second part of the image if it has been overwritten. Trying to run dd once again just after flashing both parts in works fine, however, which tends to refute this theory.

It's time to reboot the router again, to start the brand new OpenWRT. After being solid for a tiny bit then flashing constantly, the orange test led eventually adopts a steady blinking pattern (two quick blinks every two seconds). This means OpenWRT is on and ready. A DHCP server is running by default, so the client can request an IP (in the 192.168.1.0/24 network).

Connecting to http://192.168.1.1 hopefully brings the LuCI web interface on. The first thing to do is, of course, to change the root password to something decently secure.

LuCI is nice, but somehow, it doesn't manage to update the configuration files. Rather than wating too much time on the issue, an ssh connection and some viming solve the problem.

The network configuration file is in /jffs2/etc/config/network. Before bringing the PPPoE link on, an ATM bridge (nas0) has to be setup. This is done by adding the following (with the help of snippets from this post, and this).

config atm-bridge
      option 'unit'     '0'
      option 'encaps'   'llc'
      option 'vpi'      '8'
      option 'vci'      '35'

The VPI/VCI configuration for Internode is found on their website.

Then, the PPPoE link can be configured.

config interface wan
      option 'ifname'   'nas0'
      option 'proto'    'pppoe'
      option 'username' 'LOGIN@internode.on.net'
      option 'password' 'PASSWORD'

One unfortunate thing with OpenWRT is that it doesn't operate the Internet led. IT is however properly detected by the kernel. Actually, two LEDS are available, one for each color: /sys/class/leds/adsl is orange and /sys/class/leds/ppp is green.

One way to do this could be to use the new LED target of iptables. Unfortunately, it is not yet present in the Kamikaze release.

# iptables -A INPUT -i ppp0 -j LED --led-trigger-id adsl --led-delay 100
# iptables -A OUTPUT -o ppp0 -j LED --led-trigger-id ppp --led-delay 100

The good news is that LuCI actually has a dedicated page to configure these LEDs at will, in response to traffic on a given interface.

Thanks to Andrew Byrne for compiling his custom native IPv6 OpenWRT build for AR7 (r19772)!

client$ md5sum openwrt-nativeipv6-ar7-squashfs.bin
3cc20970cf13ff06a7a6906045b5197b  openwrt-nativeipv6-ar7-squashfs.bin

The router now runs the official OpenWRT image, so the client's IP address is now 192.168.1.141.

root@OpenWrt:/tmp# wget http://192.168.1.141:8080/openwrt-nativeipv6-ar7-squashfs.bin
Connecting to 192.168.1.141:8080 (192.168.1.141:8080)
openwrt-nativeipv6-a 100% |*******************************|  3328k 00:00:00 ETA
root@OpenWrt:/tmp# md5sum openwrt-nativeipv6-ar7-squashfs.bin
3cc20970cf13ff06a7a6906045b5197b  openwrt-nativeipv6-ar7-squashfs.bin

It is then easier to install the new firmware using the ''mtd'' tool.

root@OpenWrt:/tmp# mtd -r write openwrt-nativeipv6-ar7-squashfs.bin  linux
Unlocking linux ...
Writing from openwrt-nativeipv6-ar7-squashfs.bin to linux ...
Rebooting ...
Connection to 192.168.1.1 closed by remote host.
Connection to 192.168.1.1 closed.

Some parameters have to be adjusted to enable IPv6 over the PPP link.

config interface wan
        option 'ifname'   'nas0'
        option 'proto'    'pppoe'
        option 'username' 'LOGIN@ipv6.internode.on.net'
        option 'password' 'PASSWORD'
        option 'ipv6'      '1'

The router automatically sets the link up, queries an IPv6 for itself and a prefix delegation, then starts advertising it on the local link.

br-lan    Link encap:Ethernet  HWaddr 00:0F:B5:17:39:29
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: 2001:44b8:7e57:cc01:20f:b5ff:fe17:3929/64 Scope:Global
          inet6 addr: fe80::c468:4aff:fefe:f47d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5746 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5709 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2681199 (2.5 MiB)  TX bytes:5618401 (5.3 MiB)
(...)
ppp0      Link encap:Point-to-Point Protocol
          inet addr:121.45.188.63  P-t-P:150.101.197.23  Mask:255.255.255.255
          inet6 addr: 2001:44b8:3071:364:b83d:74dc:8400:5201/64 Scope:Global
          inet6 addr: fe80::b83d:74dc:8400:5201/10 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1
          RX packets:5435 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5375 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:5
          RX bytes:5563903 (5.3 MiB)  TX bytes:2656906 (2.5 MiB)

For some reason, it seems the IPv6 forwarding rules in /etc/config/firewall6 are not configured properly, leading to delays and timeouts before ultimately resorting to IPv4.

A quick and possibly dirty solution is to activate forwarding on the WAN interface. Check that it is safe

config zone
        option name             wan
        option input    REJECT
        option output   ACCEPT 
        option forward  ACCEPT
        option mtu_fix  0

The DG834 has but a few bytes of memory (16MiB, to be precise). It usually has troubles tracking a large number of connections at once. We thus both reduce the maximum number of connections tracked, and reduce the timeout before established connections are forgotten. This is done in /etc/sysctl.conf.

...
net.ipv4.netfilter.ip_conntrack_max=2048 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=600
...

The changes gan be applied withet a reboot with

# sysctl -p /etc/sysctl.conf

Internode does not quite provide a /48. but their /60 should be enough to start with. Two of them are already used: one on the loopback to be permanently up and running, and the other on the LAN. Using DHCP relay, we allow other routers in the network to ask for these prefixes.

A DHCPv6 server is already running on the modem. It has to be deactivated. This is done in /etc/config/dhcp6s, by setting line option 'enabled' to 0.

DHCP6Relay is now part of the base OpenWRT system. This was not the case when the router was first installed, so it has to be installed now.

# wget http://downloads.openwrt.org/snapshots/trunk/ar7/packages/wide-dhcpv6-relay_20080615-3_ar7.ipk
Connecting to downloads.openwrt.org (78.24.191.177:80)
wide-dhcpv6-relay_20 100% |*******************************| 25483  00:00:00 ETA
# opkg install wide-dhcpv6-relay_20080615-3_ar7.ipk
Installing wide-dhcpv6-relay (20080615-3) to root...
Configuring wide-dhcpv6-relay.

We use the same WIDE DHCPv6 package on the hosted router, which happens to be muDrublic.

$ sudo pkg_add wide-dhcpv6

We configure it in /etc/dhcp6c.conf

interface sis0 {
        send ia-pd 0;
        send rapid-commit;
        request domain-name-servers;
};

id-assoc pd 0 {
# Under OpenBSD, lo0 isn't accepted
#        prefix-interface lo0 {
#                sla-id 2;
#                sla-len 4;
#        };
        prefix-interface ath0 {
                sla-id 3;
                sla-len 4;
        };
                prefix-interface rtw0 {
                sla-id 4;
                sla-len 4;
        };

};

The DHCPv6 client is started when initializing sis0, in /etc/hostname.sis0.

dhcp
up
!/usr/local/sbin/dhcp6c sis0

• Internode's generic IPv6 page and their DSL trial
• Custom builds
• Hardware details
• OpenWRT installation instructions for the DG834G and here too
• This could also be of interest if one were willing to use the router as a PPPoE modem only
• Reading Syslog on OpenWRT using logread
• PPPoE and PPPoA setup in OpenWRT
• Router slowdown solutions with DD-WRT