sent DATA <block=1, 512 bytes>
received ERROR <code=0, msg=Unsupport MODEL>
Can you upload the first 512 bytes of the firmware?
OK I am in North America, and this is from the firmware that came on the CD. It is the same as the one on the North America CD on the Buffalo website. Also- diff between my "North America" firmware and the firmware on the Asia website for this router is nothing, so the firmwares are the same. I hope I chopped the firmware correctly. I used 'head -c 512 OFW > OFW.smaller'
I guess it would make just as much sense for me to try Buffalo branded dd-wrt firmwares, as I think the one I am playing with is encrypted anyway.... So just did that and got the exact same results with latest Buffalo branded DD-WRT download from Buffalo website with North America selected.
It's obvious that the file is not created for tftpboot because it doesn't contain a valid 512-byte header.
It is not obvious at all.
Buffalo u-boot can handle 2 types of tftp files, Buffalo Airstation Open Format and Buffalo encrypted format when updating the firmware via tftp.
OpenWRT uses the open format, Buffalo and dd-wrt uses the encrypted format and the header looks structurally correct for an encrypted format file.
How do you backup original mtd3 and mtd4 on a router which has the dd-wrt firmware installed? _________________ Kernel panic: Aiee, killing interrupt handler!
How do you backup original mtd3 and mtd4 on a router which has the dd-wrt firmware installed?
I believe I have access to a family member's version 2 router with stock firmware. So as long as I can get that and figure out the rest, we might be in business. Thanks for the info and ideas.
It's obvious that the file is not created for tftpboot because it doesn't contain a valid 512-byte header.
It is not obvious at all.
Buffalo u-boot can handle 2 types of tftp files, Buffalo Airstation Open Format and Buffalo encrypted format when updating the firmware via tftp.
OpenWRT uses the open format, Buffalo and dd-wrt uses the encrypted format and the header looks structurally correct for an encrypted format file.
Thank you for correcting me.
LOM wrote:
How do you backup original mtd3 and mtd4 on a router which has the dd-wrt firmware installed? :wink:
I referred to stock/original firmware, shouldn't I? Question is, why bother doing so if there's an easier way to revert to stock firmware? Why doesn't WZR-HP-G300NH2 accept an encrypted format file came from the support CD?
So far there's only one report with successful reverting to stock firmware but without further explanation.
afrmx wrote:
I apparently found the mistake on this solution, it never mentions that the tftp put request should be done in binary mode, while the default is ascii. When done in ascii I always got the unsupport model error, once I changed it to binary it worked on the first try. Good Luck.
Excuse me that I thought I can help but actually I can't. So please continue without my presence.
I think you can. I don't know WTF I'm doing and I have a version 2 with original Buffalo branded DD-WRT firmware right in front of me.
fyi2000 wrote:
To create a file for reverting from DD-WRT to STOCK FIRMWARE,
access console and backup original mtd3:kernel and mtd4:rootfs.
Need help with that part. I'll keep googling for now.
...... OK, I downloaded everything in /dev/mtd/ from a new, never flashed v2 router. Now moving on to figure out what to do with that. Could I just put 'cat mtd3.dump > /dev/mtdblock3' (and mtd4) on the device that I want to revert? I probably won't try that yet. I'm patient. Playing many games between all this. I guess I might as well post the files in case it could help anyone else.
Last edited by cRACKmONKEY421 on Fri Dec 09, 2011 7:12; edited 1 time in total
Hi there. I'm not that crazy to download that "40.99 MB" thing. Just give me "dmesg" and the first 512-byte of mtd1:linux.
BTW, you can remove the files you upload so far. At the end I'll help you to create just one file that can be write to the flash directly. _________________ DD-WRT Forum - Atheros Recommended Build
the mtd1.dump is the complete firmware, ie kernel followed by rootfs. It starts with a normal u-boot header so it is a plain (not encrypted) firmware which you can use on your bricked router. _________________ Kernel panic: Aiee, killing interrupt handler!
Hi there. I'm not that crazy to download that "40.99 MB" thing. Just give me "dmesg" and the first 512-byte of mtd1:linux.
LOL! You'd be crazy to download a 41MB file? It takes about 70 seconds on my sub-par DSL. I feel like that comment came straight from 1992, you time traveler
I can chop it down later if LOM's suggestion doesn't work.
LOM wrote:
the mtd1.dump is the complete firmware, ie kernel followed by rootfs. It starts with a normal u-boot header so it is a plain (not encrypted) firmware which you can use on your bricked router.
Woohoo! I'll give it a try tonight and let you all know.
I would love to flash the buffalo version of 17798 on to my wzr-hp-g300nh2....
Ive tried everything I can to get any version of tftp to work and nothing is seeing my router.
Maybe someone else can assist me or tell me where Im going wrong.....
the only issue that I can seem to find is that for some reason, no matter how many 30/30/30 resets i do, everything comes back up showing a 192.168.1.1 ip address with 192.168.1.100 being the starting ip.
LOM is right about it. I forgot that with DD-WRT V24 preSP2 you only need the mtd "linux". "dmesg" should be able to explain that. Maybe LOM can add a 28-byte DD-WRT header to it so that you can upload it via DD-WRT WebGUI. _________________ DD-WRT Forum - Atheros Recommended Build
Didn't quite work yet. When I TFTP mtd1.dump, it actually accepts the file and allows me to send the whole thing. But that's as far as it gets. Eventually the DIAG light turns off, and the router comes up with what was already on it--a newer, community version of dd-wrt. So although the TFTP server accepts the file, it appears to get rejected somewhere down the line.
Didn't quite work yet. When I TFTP mtd1.dump, it actually accepts the file and allows me to send the whole thing. But that's as far as it gets. Eventually the DIAG light turns off, and the router comes up with what was already on it--a newer, community version of dd-wrt. So although the TFTP server accepts the file, it appears to get rejected somewhere down the line.
