If the problem is a mismatch between the router name string in the stock firmware and the board_data then I see two ways of fixing it.
Do you think that's all there is? Would that cause the checksum issues as well as "Could not load flash0.os:: Error"?
Certainly, the board_id mismatch may be contributing the router not doing anything with factory firmware once it's successfully tftp'ed. But I'm still puzzled why it chokes at the modified firmware with the Netgear header removed from the file.
The presumption is I must have done something to mess up board_data since I was able to upgrade stock firmware to another stock firmware before. The exact sequence was: erase linux -> reboot -> router stuck in tftp listening mode but won't do anything with successful uploads.
LOM wrote:
You either set up a tftp server that can receive files (Solarwinds tftp server for instance) and do a cfe save command of the flash memory sector containing the board_data. We can then see if the board_data is intact or if it by some reason has been damaged.
This sounds like a higher likelihood of finding something (and safer) as the router has not behaved as expected so far, and method #2 is asking the router to do something as expected.
It's worth a shot and not too difficult to pull off since I've been on serial so much that I wired up an easy-plug connector (there's no header connector on my WNR3500v2 like those pictures for WNR3500L).
What's the exact save command to do this?
P.S. I'm going to try one of the tftp servers: Tftpd32 or pumpkin or Open TFTP Server. I don't like that Solarwinds needs my private info for d/l.
You either set up a tftp server that can receive files (Solarwinds tftp server for instance) and do a cfe save command of the flash memory sector containing the board_data. We can then see if the board_data is intact or if it by some reason has been damaged.
Just thinking...is it not possible to check board_data from the shell in DD-WRT? Say, just by dumping the partition contents?
P.S. I'm going to try one of the tftp servers: Tftpd32 or pumpkin or Open TFTP Server. I don't like that Solarwinds needs my private info for d/l.
John Doe, email John.Doe@gmail.com , tel 123-4567
You can also dl the file from a few well known software archives without registration.
Tftpd32 should work so no big deal.
You can't dump the partition from within a dd-wrt shell because it doesn't exist as a partition in dd-wrt, you'll have to do it from the bootloader via the save memory command, ie
"save [-options] host:filename startaddr length" where startaddr is 0xbc3e0000 and length is 0x20000.
host is the ipaddress of your tftp server and no options needed. _________________ Kernel panic: Aiee, killing interrupt handler!
I'm looking at it...at the very beginning...."U12H127T70_NETGEAR"....but all the firmware has this header: "U12H127T00_NETGEAR".
I haven't tried fixing it yet. Should I? I could change T70 back to T00 and dd it back into mtd5. Would that work?
Wonder how that got changed....because it took the factory firmware once before....bad flash?
This is likely the reason why stock firmware isn't accepted when tftp'ing it, the cfe itself doesn't have this string but it reads it from the board_data and compares it to the uploaded firmware.
Don't know if you can write it it with the dd command, I think you have to upload the fixed binary to the /tmp directory and then use mtd erase board_data and mtd write /tmp/filename board_data _________________ Kernel panic: Aiee, killing interrupt handler!
Don't know if you can write it it with the dd command, I think you have to upload the fixed binary to the /tmp directory and then use mtd erase board_data and mtd write /tmp/filename board_data
Tomato doesn't have mtd. At least when I type mtd it's not in busybox. Guess I'll have to do it via CFE.
So after I do save at the CFE prompt and edit the file, what's the command to write it back? Do I use "flash" with an offset?
Don't know if you can write it it with the dd command, I think you have to upload the fixed binary to the /tmp directory and then use mtd erase board_data and mtd write /tmp/filename board_data
Tomato doesn't have mtd. At least when I type mtd it's not in busybox. Guess I'll have to do it via CFE.
So after I do save at the CFE prompt and edit the file, what's the command to write it back? Do I use "flash" with an offset?
hmm, I would try the dd command in Tomato first to see if dd accepts flash as of.
From what I can see in the crippled and customised cfe, it should be possible to use
"flash host:filename flash1.board_data" where host:name is the tftp serverip and filename and it will be written to flash1.board_data _________________ Kernel panic: Aiee, killing interrupt handler!
hmm, I would try the dd command in Tomato first to see if dd accepts flash as of.
Sweet! It worked! I just edited the file I had extracted and dd'ed it back into the board_data partition.
Tomato took the factory firmware and the router rebooted into "rescue" mode, with a checksum error and with the tftp server running. Then I just tftp'ed the same firmware a 2nd time and it stuck, so now I have factory FW running again.
I'll never know why board_data changed in the first place.
Now that I'm back to being able to reliably switch back to factory FW, it's time to start playing with 3rd party FW again. :)
Is there anything I should do while I'm in factory FW? I don't think I need to run commands like burnboardid, since everything seems to be running ok.
EDIT:
While poking around the factory FW, I just noticed something. The LAN and WLAN mac addresses are the same - I recall them being different on other FW, so that between LAN, WAN and WLAN, there are actually 3 mac's. Do I need to fix this in the factory FW?
EDIT 2:
What is burnrf? I read through Dark_Shadow's thread and there are all these pci id parameters he burned with burnrf...not sure if I have these? When I type burnrf, it just says "burnrf OK!" without displaying any parameters.
Is there anything I should do while I'm in factory FW? I don't think I need to run commands like burnboardid, since everything seems to be running ok.
EDIT:
While poking around the factory FW, I just noticed something. The LAN and WLAN mac addresses are the same - I recall them being different on other FW, so that between LAN, WAN and WLAN, there are actually 3 mac's. Do I need to fix this in the factory FW?
EDIT 2:
What is burnrf? I read through Dark_Shadow's thread and there are all these pci id parameters he burned with burnrf...not sure if I have these? When I type burnrf, it just says "burnrf OK!" without displaying any parameters.
Welcome back to stock life!
There are only 2 mac's but dd-wrt and tomato will make a 3rd one which actually doesn't belong to your router.
If memory serves me it is related to some wireless bridge mode where LAN and WLAN can't have the same mac.
The burnrf command is for writing radio rf parametser in the board_data but your router has only a few of them and not of the pci/1/1 type.
Your board_data matches the one I had from before in structure and in rf parameters so you are ok now. _________________ Kernel panic: Aiee, killing interrupt handler!
I'll never know why board_data changed in the first place.
It is likely that Tomato has rewritten the identifier, I don't think dd-wrt could have done it because board_data partition is not defined and therefore not available for dd-wrt to write in.
I think you should ask teddy_bear why this has happened
_________________ Kernel panic: Aiee, killing interrupt handler!
No, a change of 1 byte in the board_data partition has nothing to do with erasing linux, the linux partition does not include board_data. _________________ Kernel panic: Aiee, killing interrupt handler!
It is likely that Tomato has rewritten the identifier, I don't think dd-wrt could have done it because board_data partition is not defined and therefore not available for dd-wrt to write in.
Actually, I don't think Tomato could have done anything. Because the DD-WRT linux partition was too small, I could never get Tomato accepted on the router until teddy_bear's beta 14, but that wasn't released until I had already struggled with getting any FW back on the router. Eventually, I used CFE to get DD-WRT build 13527 onto the router, got it running, then tried beta 14, then went to DD-WRT build 14311.
So:
Original Netgear FW -> Newest Netgear FW -> DD-WRT 14311 .chk -> erase linux; reboot -> CFE goes into self rescue mode, but byte changed so nothing would take -> CFE flash of DD-WRT 13527 -> Tomato beta 14 or any other DD-WRT
It is likely that Tomato has rewritten the identifier, I don't think dd-wrt could have done it because board_data partition is not defined and therefore not available for dd-wrt to write in.
Actually, I don't think Tomato could have done anything. Because the DD-WRT linux partition was too small, I could never get Tomato accepted on the router until teddy_bear's beta 14, but that wasn't released until I had already struggled with getting any FW back on the router. Eventually, I used CFE to get DD-WRT build 13527 onto the router, got it running, then tried beta 14, then went to DD-WRT build 14311.
So:
Original Netgear FW -> Newest Netgear FW -> DD-WRT 14311 .chk -> erase linux; reboot -> CFE goes into self rescue mode, but byte changed so nothing would take -> CFE flash of DD-WRT 13527 -> Tomato beta 14 or any other DD-WRT
Ok, I may agree with you after having done some more checks now.
But only if you admit that you flashed a dd-wrt .chk file intended for WNR3500v2_VC instead of WNR3500v2
That is the only dd-wrt file with 70 instead of 00 in the board_data router string and the cfe will then auto update your board_data when it sees that. _________________ Kernel panic: Aiee, killing interrupt handler!