Glen Pitt-Pladdy :: BlogOpenWrt Take 2 - native IPv6 on DG834 v3 (using AAISP) | |||
Previously I blogged about getting a DG834v2 working with OpenWrt Kamakaze 8.09. Long story, but I have to admit to totally bricking the router (nuked the bootloader) trying to do some silly stuff and although technically it could be resurrected with several hours of work and some tricky soldering, it's simply not worth the hassle with the money that these go for second hand on eBay. I now have my hands on a DG834v3 which has better ADSL and a faster CPU (about 40% faster actually!), although otherwise is virtually identical hardware ignoring the new (cost reduced?) PCB layout. Note that this is the wired-only version and the DG384Gv3 is the wireless version. Much of this is likely to work with the DG834G v3 too, but I can't test if the wireless will work on that. As I have left out the wireless config in my build, you will also need to put that in if you want to have a go. The tricky thing with DG834 v3 is that it has a modified ADAM2 bootloader which disables all input during boot (serial or network) and doesn't initialise the ethernet. The result is that you can't FTP the images, and the ethernet doesn't work. Not much use for a router! As I backup the router along with my regular backups, I have all the config from my old router so don't have to cover much old ground, and I can take advantage of the previous experience to make a neater job of it this time. This time I tried to use the recently released Backfire (10.03) rather than Kamakaze (8.09), but it has serious problems on the DG834v3. Days of experimenting with config, different tweaks to the source, network analysis and other tricks and have had no success. The two problems that Backfire has on this is that the ethernet is broken (it does respond with ARPs when pinged, but the MAC address has the last two octets zeroed and not surprisingly no IP traffic moves, plus the serial console breaks during boot (appears to be when the kernel detects the serial devices) making it impossible to debug further. Backfire is still very new and hopefully these will be fixed soon. For this I am still using Kamakaze like before. Mind the BricksBefore you start, keep in mind that DG834 v3 routers are far more prone to bricking that v2 types as you can't FTP to the bootloader with v3 routers. Many things that I do here are risky so make sure you know how to de-brick your router before you start. On the plus side they do have space to solder on a JTAG connection and I have successfully de-bricked mine several times with TJTAG 3.0 and suitable cables. TJTAG requires a real parallel port (rare these days) and will not generally work with USB parallel adaptors. This often means installing a parallel card or using an old machine that has a parallel port. As TJTAG is very slow, I suggest you only restore ADAM2 (mtd2) and rely on the Netgear recovery tool which does work for v3 too. Be aware that this must be run as Administrator under windows, and if using Vista or later you will need to set it to run in XP SP2 compatibility mode. Choice of bootloadersAs mentioned, the v3 ships with a crippled version of ADAM2. The method I use here can be used with the stock, crippled ADAM2. I have only been able to get a patched version of Kamakaze working with the stock ADAM2, so if you are happy with that then it is probably safest not to replace ADAM2, and it allows the use of the Netgear recovery tool to de-brick the router if you get into trouble. If you want a fully functional bootloader then PSP Bootloader seems to do the job well. I have tried version 1.4.0.4 of PSP Bootloader (originally for W422G) with success on my DG834v3, but it has been painful installing it - I have only had success installing it with JTAG. The Netgear firmware seems to modify it when it writes to mtd2 which results in a bricked router. Once installed you will also need a serial cable to modify an environment variable if you are using Windows FTP since quotes don't travel across Windows FTP well. I have settled on this route simply because I have the electronics background, have already made up the relevant cables, and it allows me more flexibility in the long term in that I can directly replace the firmware without having to restore the Netgear firmware before I can do anything. Building KamakazeGrab the source for OpenWRT Kakakaze from SVN, and if you want it to work with ADAM2 then grab the patch for the ethernet and put it in target/linux/ar7/patches You will need to configure the source. You may use my DG834v3 OpenWRT 8.09 Kamakaze config as a starting point (copy it to .config in the base of the source tree). I have added a load of extra packages I find useful which save space if they are built into the main image, but you can easily remove them if you don't need them. To enable all the available packages (optional and needed for my config): $ make package/symlinks And to run the configuration: $ make menuconfig After configuring anything you need, build it: $ make The finished images are found under bin/ar7. For PSP Bootloader use openwrt-ar7-squashfs.bin which is what we will be using from now. ADAM2: Getting down to itAnnoyingly, the later firmwares for the DG834 v3 do not include wget which makes things far more difficult. If you are going to go the ADAM2 route then you will need to install OpenWrt via the Netgear firmware. My suggestion is to download the original 4.01.06 firmware which does have everything you need for this process. Once you have downgraded the router to the 4.01.06 then you are ready to begin. Since we can't use ADAM2 to do the installation, this has to be done from the Netgear firmware. You need to dice up the image into mtd1.bin and mtd0.bin before we can use it:
$ dd if=openwrt-ar7-squashfs.bin of=mtd1.bin bs=1 count=720896 Take the mtd*.bin files and put them on a webserver attached to the router and then switch the router to debug mode (hit http://IP_of_your_router/setup.cgi?todo=debug from your browser) and telnet in:
# cd /tmp As soon as that has finished writing then pull the power on the router. Do not do a soft reboot as this might try and write to the partitions and corrupt them. Plug in the power and after booting (which can take a while the first time), continue the normal OpenWrt configuration with telnet to the IP address you configured in the build. If it fails then you will need to use the Netgear recovery tool to get it back to the Netgear firmware and try agin. PSP Bootloader: Terrible TCPIf using PSP Boot then you can use FTP to install the image the same way as with a standard ADAM2. I have not found any way of installing PSP Boot reliably other than via JTAG. ADAM2 and PSP bootloaders both have flaky IP stacks (they drop all traffic while erasing the flash which can be several seconds and really throw the FTP client). FTP under Linux generally stalls and never recovers, but can also be made to work by changing a setting. By using a different timeout handling algorithm it seems quite happy. As root (no you can't sudo this command and have to "sudo -s") try the following: # echo 0 >/proc/sys/net/ipv4/tcp_frto Your milage may vary, but I find that these seem to make things work most of the time. If you want this to persist across reboots then you will need to add it to your sysctl. FTP under Windows does seem to work more reliably, but you may get timeouts while erasing the Flash. I found that by adding a registry key (beware, this is risky and could break your Windows install) to retry more, it worked reliably under Vista: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersTcpMaxDataRetransmissions This should be a DWORD, and I set it to 40 (HEX) which seems to be plenty of retries for even the largest Flash partitions to erase. Now the only problem remaining is not being able to put quotes in Windows FTP when setting environment variables. This can however be done with a serial cable to the router (requires soldering etc.). Now you should be able to FTP to your router without constant problems. Power up the router with PSP Boot installed on and start FTP around 8 to 12 seconds later (some experimenting may be needed) from a machine configured on the same subnet (eg. 192.168.1.100):
$ ftp 192.168.1.1 At that point your router should start booting up on the new image. Setting BOOTCFG will not work with Windows FTP, so you need to use a serial console for that, or do that with Linux FTP. Up and awayThe initial boot is slow while additional filesystems and initial setup is done. Once the router is doing it's heartbeat flash on the orange Internet light, you should be able to telnet in and start configuration:
$ telnet 192.168.1.11 Wait a while and you can ssh in and continue configuration. The whole point in this project was to use IPv6 with AAISP who offer native IPv6 over ADSL. There are some other ISPs around doing this now, and this approach may also work with them. Normally only exotic routers support this, but with OpenWrt and a cheap Netgear off eBay it is within reach of anyone reasonably techy. The remaining configuration including IPv6 is exactly the same as I did in my last article on the DG834v2 so I'm not going to repeat myself. Stuff that is brokenLEDs seem to be only partly working on this one, but that may be due to me using PSP Bootloader. The ADSL and PPP LEDs are working, but the power and test LEDs don't seem to work. I have tried compiling in the GPIO stuff and manually kicking the lines and had no success. There does seem to be a small amount of current (faint glow) on the LEDs and the GPIO line is pulled down to about 1.5V. I suspect that the lines may have been configured as inputs with pull-downs or something similar (perhaps by the bootloader). The ethernet is still falling down to 10Mbit Half Duplex:
root@OpenWrt:~# ethtool eth0 While messing with GPIO I found that setting gpio17 low seems to break the switch (all port LEDs light and network access is lost), but curiously messages about PHY up, and 100Mbit Full Duplex are logged to the serial console. Hmmmm.... does that mean that the interface up/down flag is inverted and it thinks successfully connected when disconnected, and autonegotiates to the minimum rate when actually connected? When I get a chance I will have a go making a patch to test that theory out. Apart from that, everything seems to be functional. Updates and additional toysRefer to my previous article for existing scripts and fixes. New stuff I have added: Emails about connectivityI find it useful to get emails about the connection going up and down. For this I use mini_sendmail and the following scripts: local-mail-inform-up - make it executable and put this in /etc/ppp/ip-up.d and motify it to suit. local-mail-inform-down - make it executable and put this in/etc/ppp/ip-down.d and motify it to suit. Note that these will not work if the mail server (or DNS) is not accessable while the PPP link is down. It is only practical to use a mail server on the Ethernet side of the router. You can work around DNS problems by specifying the IP of the mail server or adding it to /etc/hosts As mini_sendmail is not a full blown MTA, you need to make sure that the mail server is not going to do stuff like Greylisting, strict sanitisation of SMTP etc. If you are running Postfix then you can normally sort this by adding the router IP address into mynetworks and making sure that permit_mynetworks appears in any restrictions before any strict checks or Greylisting rules. Quick backupWhen I flash the router with new firmware via PSP Boot, the existing config and everything gets lost. While I do have backups with dirvish, it's much more convenient to be able to do a real quick tarball of everything that I want to keep. That's what this script is about and it should back up everything I have added to the router via ssh: Download: OpenWrt quick config backup script You can then scp the file back to the router and untar it in the root directory. For example:
$ ./openwrt-quick-config-backup root@router >router-config.tar.gz Then to restore after flashing assuming you have set the password and ssh is up:
$ scp router-config.tar.gz root@router:/tmp It should come back up running the config you saved. |
|||
|
This is a bunch of random thoughts, ideas and other nonsense, and is not intended to be taken seriously. I'm experimenting and mostly have no idea what I am doing with most of this so it should be taken with cuation and at your own risk. Intrustive technologies are minimised where possible. For the purposes of reducing abuse and other risks hCaptcha is used and has it's own policies linked from the widget.
Copyright Glen Pitt-Pladdy 2008-2023
|
|||