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 dd
ed to the appropriate mtd
s.
# 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 vim
ing 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
logread