Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Justino]

Yeh, follow les-70's advice and check whether there is any ethernet activity from the device. e.g. set your PC NIC to 'promiscuous' mode, and monitor for ethernet traffic.  Also try port scanning the common ports on the IP blocks for the three private networks using nmap or similar.  It's possible that its default IP address is now something unexpected, hence the failure of tftp to connect with the device.  That's a common point of failure.  Flashing in new firmware and overwriting the old network config settings, etc.  So the device ends up on a different subnet.

What were you flashing into it when it failed?  A firmware image containing a bootloader?  Using JTAG, you will need a NAND image (or part-of) to flash back into it, rather than a pre-built firmware image.   Generally you would only use JTAG to re-flash the bootloader. Then you flash the rest of the firmware - the kernel and filesystem(s) - into the device using a daemon running on the network stack of the bootloader.

JTAG'ing is an absolute last resort.  It's also possible that the NAND IC has physically failed.  NAND failure becomes more likely as the flash ICs age. SFAIK, failure occurs during programming and erasure. Not during reading.  A bit refuses to set (1) during the high voltage erase process.    And the NAND f/s drivers of these devices are not very intelligent, and can't cope well with physical errors.   Most have no wear-levelling and will only work with a file system or bootloader that is stored in a continuous block of NAND pages.  So if one NAND page fails in the middle of a compressed file system - or worst case scenario a NAND page fails in the bootloader partition, then the device becomes a doorstop. Unless you are willing to replace the NAND flash IC.  Which isn't worth the time and expense for a five year old device that can be bought s/h for just £10.

Good luck whatever you choose to do

cheers, a

I will give this a go tonight. When it is connected, the ethernet port light is on, on the front of the router, and the laptop is showing a connection, but no activity. I had changed the router IP address to 192.168.1.1 when it was working, I forget why now, but something to do with one of the wireless connections clashing.

I was flashing the latest dgteam firmware onto it - 1022 I recall. It wouldn't connect after attempting gui update (first mistake), then on using the xp recovery programme, it hung twice at this stage, when it reads deleting rom (I think). After that the router wouldn't show up in the device list. With ntfp, it just hangs at 'sending to eth0......'

[les-70]

 Good luck.  Given your change you should try also try an ethernet adaptor set in the range of the router e.g. 192.168.1.100.  If the hard reset worked i.e. the long reset button push of more than 10 sec with the router in final running state had any effect it may be back to 192.168.0.1  so you need to try both ranges.  Do also ensure the reset is kept pressed on power up so to get either the timeout update GUI to appear on the router address or to get the windows update utility to find the router.   

[Justino]

I'm not sure how to set the NIC to promiscuous despite a google search. Also what scan do I need to run in nmap and what target?

I have set the router ip to 192.168.1.100, and it is sat on the xp utility with no devices showing. I will also try 192.168.0.100.

For the timeout gui, do I need explorer running with the router ip address in the address bar?

[asbokid]

I'm not sure how to set the NIC to promiscuous despite a google search.

The Wikipedia entry for 'promiscuous mode' is a good starting point. [1]

In Linux, GUI tools like ethereal (aka wireshark) [2] and the CLI tool tcpdump are used to place a NIC in promiscuous mode. It can then be used to capture all or a selection of the frames/packets in the traffic on that ethernet network. This can help to determine whether a device is still alive.

Those tools are for Linux really, but are available for Microsoft although they may not work so well.

Also what scan do I need to run in nmap and what target?

Nmap has comprehensive help on its website. [3]

As suggested earlier, "Also try port scanning the common ports on the IP blocks for the three private networks using nmap or similar. "

So if you expect to find a webserver running on the device, then you would scan port 80/tcp (HTTP) on all the IP addresses in Class A, Class B and Class C private networks. [4]

That scanning could literally take hours. So it makes sense to begin by port-scanning just a small subset of those IP address ranges. Perhaps try scanning all addresses in the IP blocks:

192.168.0.0/16
10.0.0.0/16

And maybe expand the scan to include ftp (port 25/tcp), tftp perhaps (69/udp), bootp/dhcp, etc etc..   In the scan, include the number (and protocol) of any port on which you expect to find a daemon listening on the Netgear.

Good luck 

cheers, a

[1] http://en.wikipedia.org/wiki/Promiscuous_mode
[2] http://www.wireshark.org
[3] http://nmap.org/docs.html
[4] http://en.wikipedia.org/wiki/Private_network

[les-70]

  For timeout open a browser after the wait (IE may be best) and try likely IP addresses.