Posted: Mon Aug 15, 2011 19:14 Post subject: Netgear WGR614v10 / WNR1000v3
This router has a weird <32KiB NVRAM size and the CFE uses Netgear's weird firmware checksum routine, so my solution is to turn it into an Asus RT-N10 by swapping out the CFE through JTAG.
I swapped it, so now the CFE is using DD-WRT compatible partitioning. I flashed the Asus RT-N10 version of DD-WRT and it now runs.
There are a few asterisks to that, though. First off, the GPIOs on the Netgear WGR614v10 / WNR1000v3 are different from the Asus RT-N10, which I expected from the beginning. Second, the WAN in DD-WRT didn't work until I changed the WAN port from vlan1 to eth0. I have not tested wireless yet, but I assume it probably works.
You can swap the CFE out without JTAG if you patch the setup.c file (I think that's the one?) in linux on the OEM firmware to disable write protection on /dev/mtd/0, then you can take a non-byte-swapped cfe.bin and add a TRX header with the TRX_NO_HEADER flag set. After you flash the modded firmware to the router, you can use write (part of the rc multicall binary) to write the cfe.trx to flash. I bricked mine this way at first, because I mixed up the cfe.bin I intended to write and some random CFE among the collection of embedded hacking clutter on my file server.
One more note: If you google for and download someone else's Asus RT-N10 CFE, please hex-edit it to change the WPS PIN and MAC address to the one for your router. Thank you.
Note 2: I am posting this through my newly-modded WGR614v10.
Posted: Mon Aug 15, 2011 19:32 Post subject: Re: Netgear WGR614v10 / WNR1000v3
matthacker wrote:
You can swap the CFE out without JTAG if you patch the setup.c file (I think that's the one?) in linux on the OEM firmware to disable write protection on /dev/mtd/0, then you can take a non-byte-swapped cfe.bin and add a TRX header with the TRX_NO_HEADER flag set. After you flash the modded firmware to the router, you can use write (part of the rc multicall binary) to write the cfe.trx to flash. I bricked mine this way at first, because I mixed up the cfe.bin I intended to write and some random CFE among the collection of embedded hacking clutter on my file server.
That part was over complicating a simple matter.
Swapping can be done in most hex editors and if the router is running dd-wrt then it is simple matter of enabling ssh and transfer the new cfe from your computer to the routers /tmp directory with WinSCP.
When the file is there then connect to the router via telnet and issue a mtd write command to write it from /tmp into mtd0. _________________ Kernel panic: Aiee, killing interrupt handler!
The stock firmware doesn't have the mtd command, and you can't really run dd-wrt until you do swap out the CFE or weird things can happen.
My point is that this router is on the http://www.dd-wrt.com/wiki/index.php/Known_incompatible_devices page because of its weird NVRAM size, and through swapping the CFE, I now have it 95% running without the risk of things going haywire with Netgear's bad checksum code.
Last edited by matthacker on Mon Aug 15, 2011 19:39; edited 1 time in total
Well, then load dd-wrt on it first.
Must be much less pain than modding stock firmware and making header for the cfe.. _________________ Kernel panic: Aiee, killing interrupt handler!
You can't safely run dd-wrt without swapping the CFE, else there would be no point in doing so.
Yes, that's true for these 2 models with low nvram space.
So what if I tell you that the cfe can distinguish between a kernel binary and a cfe binary and update the correct part of flash when you tftp a file before router has started to boot linux. Its only a matter of the header _________________ Kernel panic: Aiee, killing interrupt handler!
Update, wireless doesn't start working until you change the TX and RX antenna under Advanced Settings from Auto to either Left or Right. Left is connected to the rubber ducky antenna, and Right goes to a PCB trace antenna.
The reason you can't just flash dd-wrt is because the CFE is customized by Netgear for their own weird middle-of-flash checksum code, which is buggy and it may crash if overwritten with the tail end of DD-WRT. The reason for this is that if you overwrite it with whatever, the length may be wrong, and it may crash or get stuck at boot time.
It may work, but it may not work. And it may work for a while and not work, hence the current Incompatible Devices status.
It's working much better now that I am using the latest BrainSlayer build instead of the really, really old one from the router database. Before, station mode was broken (therefore, client and repeater modes didn't work) and the wireless performance wasn't very good.
Now, everything seems to work correctly except for some of the GPIOs. The GPIOs for reset and WPS are correct, but this router has a dedicated wifi on/off button separate from the WPS button which needs its own configuration option. Also, the two power LEDs seem to share GPIOs with the reset and WPS buttons. They are very dimly lit by weak pull-ups and the buttons turn one or the other completely off, suggesting that those buttons pull them low. Amber is connected to the WPS button, and green is connected to the reset button.
Aside from the extra button that doesn't do anything and the power LEDs, this router is entirely usable with the Asus RT-N10 build of dd-wrt.
Just want to report that I successfully cross-flashed my WNR1000v3. I tried using TJTAG 3.0.2 with a home-made dlc5 cable, but experienced endianness issues with write operations (maybe the firmware just needs to be byte-swapped before flashing?). I ended up pulling the chip from the board with a heatgun and programming it with flashrom via rayer_spi.
The official Asus firmware seemed to work fine with my tests, but DD-WRT r26653 has severe signal problems with this router(you can only connect if your within 3 feet) and WPA2 seemed to be broken. I ended up flashing Tomato v1.28.9052 which seems to work fine so far acting as a wireless ethernet bridge using 802.11N and WPA2.