WNR3500v2 stuck in waiting for tftp mode [Solved]

Post new topic   Reply to topic    DD-WRT Forum Index -> Broadcom SoC based Hardware
Goto page Previous  1, 2, 3, 4  Next
Author Message
tsanga
DD-WRT Novice


Joined: 25 May 2010
Posts: 25

PostPosted: Fri Jun 18, 2010 20:27    Post subject: Reply with quote
LOM wrote:
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.
Sponsor
tsanga
DD-WRT Novice


Joined: 25 May 2010
Posts: 25

PostPosted: Sat Jun 19, 2010 2:25    Post subject: Reply with quote
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.

Just thinking...is it not possible to check board_data from the shell in DD-WRT? Say, just by dumping the partition contents?
LOM
DD-WRT Guru


Joined: 28 Dec 2008
Posts: 7647

PostPosted: Sat Jun 19, 2010 2:54    Post subject: Reply with quote
tsanga wrote:


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 Very Happy
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!
tsanga
DD-WRT Novice


Joined: 25 May 2010
Posts: 25

PostPosted: Sat Jun 19, 2010 3:15    Post subject: Reply with quote
LOM wrote:
John Doe, email John.Doe@gmail.com , tel 123-4567 Very Happy
You can also dl the file from a few well known software archives without registration.

Yeah, just the principle of it, that's all.

I think I was successful doing it from Tomato. Wink

Take a look and let me know if this seems right.

Tomato has board_data as a partition:
Code:
dev:    size   erasesize  name
mtd0: 00040000 00010000 "pmon"
mtd1: 003a0000 00010000 "linux"
mtd2: 002a7c00 00010000 "rootfs"
mtd3: 00020000 00010000 "jffs2"
mtd4: 00010000 00010000 "nvram"
mtd5: 00010000 00010000 "board_data"


So I just used dd if=/dev/mtd5 to extract it. See attached.

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?



board_data.bin
 Description:

Download
 Filename:  board_data.bin
 Filesize:  64 KB
 Downloaded:  742 Time(s)

LOM
DD-WRT Guru


Joined: 28 Dec 2008
Posts: 7647

PostPosted: Sat Jun 19, 2010 4:34    Post subject: Reply with quote
[quote="tsanga"]
LOM wrote:


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!
tsanga
DD-WRT Novice


Joined: 25 May 2010
Posts: 25

PostPosted: Sat Jun 19, 2010 5:20    Post subject: Reply with quote
LOM wrote:
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. Laughing 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?
LOM
DD-WRT Guru


Joined: 28 Dec 2008
Posts: 7647

PostPosted: Sat Jun 19, 2010 5:59    Post subject: Reply with quote
tsanga wrote:
LOM wrote:
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. Laughing 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!
tsanga
DD-WRT Novice


Joined: 25 May 2010
Posts: 25

PostPosted: Sat Jun 19, 2010 16:42    Post subject: Reply with quote
LOM wrote:
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.
LOM
DD-WRT Guru


Joined: 28 Dec 2008
Posts: 7647

PostPosted: Sun Jun 20, 2010 3:49    Post subject: Reply with quote
tsanga wrote:


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! Very Happy

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!
tsanga
DD-WRT Novice


Joined: 25 May 2010
Posts: 25

PostPosted: Sun Jun 20, 2010 5:50    Post subject: Reply with quote
Alright, big thanks go to all of you experts that have helped me through this thread.

Now let me know if you ever get around to making the linux partition a bit bigger....
LOM
DD-WRT Guru


Joined: 28 Dec 2008
Posts: 7647

PostPosted: Sun Jun 20, 2010 12:23    Post subject: Reply with quote
tsanga wrote:


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
Very Happy

_________________
Kernel panic: Aiee, killing interrupt handler!
Gingernut
DD-WRT User


Joined: 29 Jul 2007
Posts: 229

PostPosted: Sun Jun 20, 2010 13:22    Post subject: Reply with quote
But he was fine until he used these commands.

erase linux
reboot

From there on is when all this started.
LOM
DD-WRT Guru


Joined: 28 Dec 2008
Posts: 7647

PostPosted: Sun Jun 20, 2010 13:27    Post subject: Reply with quote
Gingernut wrote:
But he was fine until he used these commands.

erase linux
reboot

From there on is when all this started.


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!
tsanga
DD-WRT Novice


Joined: 25 May 2010
Posts: 25

PostPosted: Sun Jun 20, 2010 15:49    Post subject: Reply with quote
LOM wrote:
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
LOM
DD-WRT Guru


Joined: 28 Dec 2008
Posts: 7647

PostPosted: Sun Jun 20, 2010 15:57    Post subject: Reply with quote
tsanga wrote:
LOM wrote:
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 Very Happy
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!
Goto page Previous  1, 2, 3, 4  Next Display posts from previous:    Page 3 of 4
Post new topic   Reply to topic    DD-WRT Forum Index -> Broadcom SoC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum