Glen Pitt-Pladdy :: Blog

OpenWrt 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 Bricks

Before 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 bootloaders

As 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 Kamakaze

Grab 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 it

Annoyingly, 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
$ dd if=openwrt-ar7-squashfs.bin of=mtd0.bin bs=1 skip=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
# cat /proc/mounts >/etc/fstab
# mount / -f -o remout,ro
# wget http://IP_of_your_web_server/mtd1.bin
# wget http://IP_of_your_web_server/mtd0.bin
# dd if=mtd1 of=/dev/mtdblock/1
# dd if=mtd0 of=/dev/mtdblock/0

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 TCP

If 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
Connected to 192.168.1.1.
220 ADAM2 FTP Server ready.
Name (192.168.1.1): adam2
331 Password required for adam2.
Password: adam2
230 User adam2 successfully logged in.
Remote system type is UNIX.
ftp> quote MEDIA FLSH
200 Media set to FLSH.
ftp> bin
200 Type set to I.
ftp> hash
Hash mark printing on (1024 bytes/hash mark).
ftp> quote SETENV HWA_0,YO:UR:MA:CA:DD:RE:SS
200 SETENV command successful
ftp> quote SETENV ProductID,DG834
200 SETENV command successful
ftp> quote SETENV BOOTCFG,m:f:"mtd4"
200 SETENV command successful
ftp> put openwrt-ar7-squashfs.bin "fs mtd4"
local: openwrt-ar7-squashfs.bin remote: fs mtd4
200 Port command successful.
120 service ready in 33 seconds.
##################################............
############
150 Opening BINARY mode data connection for file transfer.
3080196 bytes sent in 62.04 secs (48.5 kB/s)
ftp> quote REBOOT
226 Transfer complete.
ftp> bye
221-Thank you for using the FTP service on ADAM2.
221 Goodbye.

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 away

The 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
Trying 192.168.1.1...
Connected to 192.168.1.1.
Escape character is '^]'.
 === IMPORTANT ============================
  Use 'passwd' to set your login password
  this will disable telnet and enable SSH
 ------------------------------------------
....
root@OpenWrt:/# passwd    
Changing password for root
New password:
Retype password:
Password for root changed by root
root@OpenWrt:/# exit
Connection closed by foreign host.

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 broken

LEDs 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
Settings for eth0:
        Supported ports: [ TP AUI BNC MII FIBRE ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  100baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 10Mb/s
        Duplex: Half
        Port: MII
        PHYAD: 16
        Transceiver: external
        Auto-negotiation: on
        Link detected: yes

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 toys

Refer to my previous article for existing scripts and fixes. New stuff I have added:

Emails about connectivity

I 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 backup

When 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
root@router's password:
tar: removing leading '/' from member names
.....

Then to restore after flashing assuming you have set the password and ssh is up:

$ scp router-config.tar.gz root@router:/tmp
root@router's password:
$ ssh root@router
root@router's password:
root@OpenWrt:~# cd /
root@OpenWrt:/# tar zxvf /tmp/backup.tar.gz
......
root@OpenWrt:/# reboot;exit

It should come back up running the config you saved.

Comments:

redrs Image  09/06/2010 12:17 :: redrs

Hi there

Came across your site when I was researching what I could do with my Netgear DG834 V2 - was given one and set out to bring new life to it. Found some good stuff here, thanks for putting it up.

Was not too difficult to piece together enough information to install OpenWRT on this device, will think about getting another V2 or V2 router to mess with after I finish my install off configuring my current one - hit a snag with routing ( https://forum.openwrt.org/viewtopic.php?id=25183 )

redrs Image  09/06/2010 12:17 :: redrs

Hi there

Came across your site when I was researching what I could do with my Netgear DG834 V2 - was given one and set out to bring new life to it. Found some good stuff here, thanks for putting it up.

Was not too difficult to piece together enough information to install OpenWRT on this device, will think about getting another V2 or V2 router to mess with after I finish my install off configuring my current one - hit a snag with routing ( https://forum.openwrt.org/viewtopic.php?id=25183 )

Glen Pitt-Pladdy Image  09/06/2010 22:07 :: Glen Pitt-Pladdy

There are a few things that in my experience are always likely candidates or will often lead to the answer:

1) Firewall - disabling it can often cure these things in which case the rules need a close look at.

2) Is forwarding enabled - cat /proc/sys/net/ipv4/ip_forward

3) Something deeper - try pinging and tracerouting stuff from the router rather than LAN machines, and see if that makes a difference. It may point to routing, forwarding, firewall problems.

4) Try watching the logs in another terminal while testing stuff out - logread -f

Hope that gives some clues what is going on.

Glen Pitt-Pladdy Image  09/06/2010 22:07 :: Glen Pitt-Pladdy

There are a few things that in my experience are always likely candidates or will often lead to the answer:

1) Firewall - disabling it can often cure these things in which case the rules need a close look at.

2) Is forwarding enabled - cat /proc/sys/net/ipv4/ip_forward

3) Something deeper - try pinging and tracerouting stuff from the router rather than LAN machines, and see if that makes a difference. It may point to routing, forwarding, firewall problems.

4) Try watching the logs in another terminal while testing stuff out - logread -f

Hope that gives some clues what is going on.

Glen Pitt-Pladdy Image  09/06/2010 22:19 :: Glen Pitt-Pladdy

Another thing that is often useful is to see if the packets are actually going where you think.

Try getting someone to use a packet sniffer (wireshark, tshark, tcpdump etc.) from a remote machine or for those on AAISP use the dump feature on the control pages to see if packets are actually getting out and back.

Likewise, load tcpdump onto the router and see if you can see traffic is going through each interface while testing.

Seeing what traffic is actually making it in/out of the router may give vital clues. You may even find that NAT is not working or some other bizarre stuff - I have seen bizarre stuff where kit at an ISP that is not working as expected after the connection dropped while changing routers.

Glen Pitt-Pladdy Image  09/06/2010 22:19 :: Glen Pitt-Pladdy

Another thing that is often useful is to see if the packets are actually going where you think.

Try getting someone to use a packet sniffer (wireshark, tshark, tcpdump etc.) from a remote machine or for those on AAISP use the dump feature on the control pages to see if packets are actually getting out and back.

Likewise, load tcpdump onto the router and see if you can see traffic is going through each interface while testing.

Seeing what traffic is actually making it in/out of the router may give vital clues. You may even find that NAT is not working or some other bizarre stuff - I have seen bizarre stuff where kit at an ISP that is not working as expected after the connection dropped while changing routers.

klc Image  21/12/2010 00:20 :: klc

Thanks Glen! Bricked my V3 after successfully flashing with kamikaze - trying to flash with Backfire. /dev/mtd0 in kamikaze is NOT the same as /dev/mtdblock/0 or 1 in stock firmware :)

Anyways - now jtagged pspboot on there and booted with latest backfire. network seems fine - yet to test fully. (tjtag fc:27 for my unit, else would stop at 90001fff if that helps anyone)

klc Image  21/12/2010 00:20 :: klc

Thanks Glen! Bricked my V3 after successfully flashing with kamikaze - trying to flash with Backfire. /dev/mtd0 in kamikaze is NOT the same as /dev/mtdblock/0 or 1 in stock firmware :)

Anyways - now jtagged pspboot on there and booted with latest backfire. network seems fine - yet to test fully. (tjtag fc:27 for my unit, else would stop at 90001fff if that helps anyone)

Glen Pitt-Pladdy Image  21/12/2010 08:20 :: Glen Pitt-Pladdy

Yeah - bricking does seem to be the name of the game with these with the crippled bootloader in v3. A JTAG cable is practically a necessity.

I had wondered how many people would be able to pull this off as it is a tricky one so it's good to hear that you had success!

Glen Pitt-Pladdy Image  21/12/2010 08:20 :: Glen Pitt-Pladdy

Yeah - bricking does seem to be the name of the game with these with the crippled bootloader in v3. A JTAG cable is practically a necessity.

I had wondered how many people would be able to pull this off as it is a tricky one so it's good to hear that you had success!

Zip Image  27/02/2011 17:33 :: Zip

The Netgear DG834G V3 has a group of 14pins for the JTAG, does a normal 12Pin JTAG cable work?

Zip Image  27/02/2011 17:33 :: Zip

The Netgear DG834G V3 has a group of 14pins for the JTAG, does a normal 12Pin JTAG cable work?

Glen Pitt-Pladdy Image  27/02/2011 17:52 :: Glen Pitt-Pladdy

Not sure of different cables - there do seem to be a few variants. I used the basic "Xilinx" cable described in the link above and it worked for me.

As there are connections to both ends of the 14-pin connector, I would suggest that the 12-pin cable may not be sufficient.

Glen Pitt-Pladdy Image  27/02/2011 17:52 :: Glen Pitt-Pladdy

Not sure of different cables - there do seem to be a few variants. I used the basic "Xilinx" cable described in the link above and it worked for me.

As there are connections to both ends of the 14-pin connector, I would suggest that the 12-pin cable may not be sufficient.

Zip Image  02/03/2011 00:38 :: Zip

Thanks for that Glen. The config file you link isn't loading for me, are you able to fix that link?

Zip Image  02/03/2011 00:38 :: Zip

Thanks for that Glen. The config file you link isn't loading for me, are you able to fix that link?

Glen Pitt-Pladdy Image  02/03/2011 08:04 :: Glen Pitt-Pladdy

Thanks for pointing that out. Not sure what happened there - the permission on the config file was set wrong where all the others where fine.

Should be working now.

Glen Pitt-Pladdy Image  02/03/2011 08:04 :: Glen Pitt-Pladdy

Thanks for pointing that out. Not sure what happened there - the permission on the config file was set wrong where all the others where fine.

Should be working now.

RossH Image  01/04/2011 20:45 :: RossH

Thanks for the great tutorial. I came across it when researching an IPv6 router for use with AAISP

Have successfully managed to flash OpenWRT r26349 (29/03/11) (openwrt-ar7-squashfs.bin downloaded from the OpenWRT site) onto my DG834Gv3 using the stock ADAM2 bootloader and without having to resort to JTAG etc (bit of a relief!) I did however 'brick' it a few times trying Backfire 10.03.1 rc1/rc4 but seems to work with a more bleading edge version (i think due to ethernet bug being fixed in trunk in November (after rc4 was compiled). Needed nftp/Ubuntu to reflash/unbrick it about 3 times.

Issue i still have is Wifi not working, has anyone else managed this?

LEDs also dont look right, have yet to try your scripts.

Off to try geting full IPv6 working now :o

RossH Image  01/04/2011 20:45 :: RossH

Thanks for the great tutorial. I came across it when researching an IPv6 router for use with AAISP

Have successfully managed to flash OpenWRT r26349 (29/03/11) (openwrt-ar7-squashfs.bin downloaded from the OpenWRT site) onto my DG834Gv3 using the stock ADAM2 bootloader and without having to resort to JTAG etc (bit of a relief!) I did however 'brick' it a few times trying Backfire 10.03.1 rc1/rc4 but seems to work with a more bleading edge version (i think due to ethernet bug being fixed in trunk in November (after rc4 was compiled). Needed nftp/Ubuntu to reflash/unbrick it about 3 times.

Issue i still have is Wifi not working, has anyone else managed this?

LEDs also dont look right, have yet to try your scripts.

Off to try geting full IPv6 working now :o

Glen Pitt-Pladdy Image  02/04/2011 09:35 :: Glen Pitt-Pladdy

Glad to hear people are having success.

With my config the wifi is disabled as I am using wired only. Others seem to have had success getting it working on the v2 and since v3 seems very similar beyond the bootloader I would expect it's possible. I believe it appears as another network interface and needs to be bridged with the wired interface, though personally I would treat it separately so I can firewall between the interfaces for an extra layer of safety.

Glen Pitt-Pladdy Image  02/04/2011 09:35 :: Glen Pitt-Pladdy

Glad to hear people are having success.

With my config the wifi is disabled as I am using wired only. Others seem to have had success getting it working on the v2 and since v3 seems very similar beyond the bootloader I would expect it's possible. I believe it appears as another network interface and needs to be bridged with the wired interface, though personally I would treat it separately so I can firewall between the interfaces for an extra layer of safety.

Simon Iremonger Image  11/08/2011 15:36 :: Simon Iremonger

Briefly, with backfire (10.3 series), it is possible to get native-IPv6 (e.g. AAISP/UK) working with no issues.

In terms of wireless, the latest kmod-acx-mac80211 20010704 works for the DG834Gv2 (acx111/TNETW1130), WPA2 encrypted access point etc.

DG834Gv3 will work, but the TNETW1350A access point will not (RouterTech firmware can support this).

These problems may happen:-

a) Ethernet does not work due to DG834Gv3 ADAM2 not enabling the ethernet fully and linux not sorting it out. Solution: replace with PSPBOOT 1.4.0.4 ... You can use Ciclamab with XILINX parallel cable to backup/restore via JTAG.

b) on 10.3.1-rc3 and newer, all but the port externally labelled "4" do not work due to bug: https://dev.openwrt.org/ticket/8525 Solution: use my build (linked there) or older version or new trunk version.

c) Wireless does not work or support WPA2 due to old acx driver, or out of date ack-mac80211. Solution: use my build or patch similarly yourself.

Hope that is helpful!

Simon Iremonger Image  11/08/2011 15:36 :: Simon Iremonger

Briefly, with backfire (10.3 series), it is possible to get native-IPv6 (e.g. AAISP/UK) working with no issues.

In terms of wireless, the latest kmod-acx-mac80211 20010704 works for the DG834Gv2 (acx111/TNETW1130), WPA2 encrypted access point etc.

DG834Gv3 will work, but the TNETW1350A access point will not (RouterTech firmware can support this).

These problems may happen:-

a) Ethernet does not work due to DG834Gv3 ADAM2 not enabling the ethernet fully and linux not sorting it out. Solution: replace with PSPBOOT 1.4.0.4 ... You can use Ciclamab with XILINX parallel cable to backup/restore via JTAG.

b) on 10.3.1-rc3 and newer, all but the port externally labelled "4" do not work due to bug: https://dev.openwrt.org/ticket/8525 Solution: use my build (linked there) or older version or new trunk version.

c) Wireless does not work or support WPA2 due to old acx driver, or out of date ack-mac80211. Solution: use my build or patch similarly yourself.

Hope that is helpful!

lucapost Image  24/02/2012 10:25 :: lucapost

hi, I have a problem with my dg834u and openwrt. After access with telnet, if I try to ping my webserver (where I put mtd* images), I get always

# ping 192.168.0.20

PING 192.168.0.20 (192.168.0.20): 56 data bytes

64 bytes from 192.168.0.20: icmp_seq=0 ttl=64 time=0.0 ms

64 bytes from 192.168.0.20: icmp_seq=1 ttl=64 time=0.0 ms

note time=0.0 ms

and I can't download images to the router.

I have 4.01.06 firmware.

can anybody help me?

thanks,

LP

Glen Pitt-Pladdy Image  24/02/2012 10:43 :: Glen Pitt-Pladdy

I'm not familiar with the DG834U - what I've found on searching seems to suggest it's a "v5" device with slightly different firmware for an Australian ISP so may not have much in common with the "v3" device described here.

The return time being 0.0ms does seem quick and might indicate that the router is responding to the pings itself. From what I can find it appears that the DG834U has a different startup address to standard DG834 devices so by default would not work on that address. I would check the the router is configured for the same network as your web server and that it isn't doing anything like NATing that route in any way.

Klaus Image  28/02/2012 09:39 :: Klaus

@lucapost

Sorry, I haven't got a v3 with Netgear's firmware anymore :-) But, testing to PING somewhere on the LAN from a DG834G v2 (fw V3.01.31) yielded the same 0.0ms result you've got. Going through the modem, the results look more normal:

# ping 192.168.0.51

PING 192.168.0.51 (192.168.0.51): 56 data bytes

64 bytes from 192.168.0.51: icmp_seq=0 ttl=64 time=0.0 ms

64 bytes from 192.168.0.51: icmp_seq=1 ttl=64 time=0.0 ms

64 bytes from 192.168.0.51: icmp_seq=2 ttl=64 time=0.0 ms

--- 192.168.0.51 ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max = 0.0/0.0/0.0 ms

# ping www.google.com

PING www.l.google.com (173.194.66.106): 56 data bytes

64 bytes from 173.194.66.106: icmp_seq=0 ttl=48 time=50.0 ms

64 bytes from 173.194.66.106: icmp_seq=1 ttl=48 time=40.0 ms

--- www.l.google.com ping statistics ---

3 packets transmitted, 2 packets received, 33% packet loss

round-trip min/avg/max = 40.0/45.0/50.0 ms

Klaus Image  28/02/2012 10:29 :: Klaus

Another success, 10.03.1 on the DG834G v3. One hurdle I struggled with for a loooong time was the BOOTCFG variable. Not understanding what it does or even how it works in PSPBoot, I didn't appreciate the quotes around "mtd4" properly. Using Debian sid's ftp client (works fine with Glen's timeout workaround), I typed

ftp> quote SETENV BOOTCFG,m:f:"mtd4"

and the subsequent flashing of the firmware worked fine. But the router failed to boot, with various image files, even my own mtdblock backup. What solved it eventually was to escape the double quotes:

ftp> quote SETENV BOOTCFG,m:f:\"mtd4\"

Thanks Glen, up and running now!

Hope this helps somebody,

Klaus

George Smart Image  29/04/2012 20:41 :: George Smart

Hi. I followed this tutorial with mixed success. First of all, and the main thing for me, the device booted and OpenWRT came up. Great stuff, thanks for that. However, I don't think the ethernet patch applied properly as I have no ethernet connectivity (despite doing as instructed). This is the first time I've done this and I made every mistake possible, including compiling for every platform (not fully reading the OpenWRT options). Took just over 3 hours on a quad-core machine, for interest :)

Thanks.

George, London, England.

Glen Pitt-Pladdy Image  29/04/2012 20:55 :: Glen Pitt-Pladdy

Good to hear you had some degree of success. My suspicion is that the problems relate to this article being about 2 years old now and things having moved on. Certainly I no longer run a DSL router as I've switched to FTTC and BT provide the a FTTC modem so I only deal with PPPoE now.

Looking at the ticket the patch was from (https://dev.openwrt.org/ticket/3782) it looks like the patch has been included in later versions so depending on what revision you got you may not need to patch, or even the patch may have only partially applied and broken stuff.

Another thing to check is running tcpdump on each network device may give you a clue if there is some life and just a config problem preventing it coming up fully.

I'm not going to be able to help much on this now as I no longer use these devices.

ginopilotino Image  07/05/2012 15:25 :: ginopilotino

My dg834g v3 is bricked. I need the original adam2 boot loader, because I have jtag only, no serial cable. Please help.

Glen Pitt-Pladdy Image  07/05/2012 15:58 :: Glen Pitt-Pladdy

I may be wrong, but I think the bootloader is included in the downloadable firmware image from Netgear.

Asif Image  04/07/2012 19:58 :: Asif

you are not wrong, it is available in firmware image, from 0x00000 to 0x1ffff (i had bricked it also, and had figured it out by myself, it's a long story) but mtd4 (config variables is also required in order to boot with working ADAM2)

anyways, if anyone need one file copy of working bootloader PM me at will be glad to help :)

Cheers

Kazari Image  12/09/2012 10:37 :: Kazari

I need a working bootloader is bricked my router netgear dg834gv3. Serial console does not work, just nonsensical characters appear. Have you tried everything 9600-115200. Ip address does not work.

Thanks (sorry do not know English)

Glen Pitt-Pladdy Image  12/09/2012 12:28 :: Glen Pitt-Pladdy

If it's bricked then you will likely have to use jtag and I just used the standard Netgear image - the beginning of it is the bootloader

Kazari Image  12/09/2012 13:55 :: Kazari

JTAG works, there is a cable (Xilinx), but I could not find bin file that you could put up the partition mtd2 (64kb). The standard BIN files can be created IMG file?

Thanks for the quick response.




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