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.
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.
I have been using binary mode all along with no luck. What type of file did you manage to Tftp? I have been trying to send the Buffalo "enc" file with no luck. I mentioned this in the Buffalo Tech forums and an Admin stated that it's not possible to tftp a "enc" file as it is encrypted. The only file I could tftp to my WZR-HP-300GNH2 was an Open-Wrt "bin" file.
Joined: 06 Feb 2010 Posts: 7401 Location: Little Rock
Posted: Thu Nov 17, 2011 11:56 Post subject:
Deepdish wrote:
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.
I have been using binary mode all along with no luck. What type of file did you manage to Tftp? I have been trying to send the Buffalo "enc" file with no luck. I mentioned this in the Buffalo Tech forums and an Admin stated that it's not possible to tftp a "enc" file as it is encrypted. The only file I could tftp to my WZR-HP-300GNH2 was an Open-Wrt "bin" file.
I read that statement from that 'admin'. That person doesn't know much about buffalo's products, which he is admin of, either. I can assure you that i can tftp .bin's .enc's etc.
Only one of his statements i found to be true, the one about .enc means encrypted, sure that is true but that only locks down file acceptance from within the buffalo webgui, the tftp window initializes before the OS, and TFTP accepts all files, thus why its called 'trivial'...
Ahhh.. very interesting and yes I did find it odd that he gave reference to Blogspot with a brick recovery guide using tftp because if as he said an "enc" file can not be sent via tftp why would he refer to it? Also he says that if you brick your device to RMA it as you have a two year warranty and then he goes on to offer a disclaimer that adding third party software will void it. lol.. He is full of contradictions so I am definitely in question of his knowledge now too. Great to hear that you have actually had luck in tftp'g all types of files and now I know it is actually possible so back to the drawing board tonight. I have been using Ubuntu up to this point but I think I will try Pumpkin in Win XP and see how that goes.
Joined: 06 Feb 2010 Posts: 7401 Location: Little Rock
Posted: Fri Nov 18, 2011 0:07 Post subject:
Deepdish wrote:
Ahhh.. very interesting and yes I did find it odd that he gave reference to Blogspot with a brick recovery guide using tftp because if as he said an "enc" file can not be sent via tftp why would he refer to it? Also he says that if you brick your device to RMA it as you have a two year warranty and then he goes on to offer a disclaimer that adding third party software will void it. lol.. He is full of contradictions so I am definitely in question of his knowledge now too. Great to hear that you have actually had luck in tftp'g all types of files and now I know it is actually possible so back to the drawing board tonight. I have been using Ubuntu up to this point but I think I will try Pumpkin in Win XP and see how that goes.
I've always used windows XP to do the TFTP flashing. The main thing is adding that static arp entry and timing, which atleast on the g300nh, you have to wait 10 seconds from power up. So plug in the unit, as soon as its plugged in, count to 10 then initialize transfer. Only other thing i have which probably helps is i use a hardware switch inbetween.
so is there no way to revert the unit back to the original Buffalo firmware now? Original firmware has been updated to 17798 and DDNS is working!
Well I tried every method under the sun to revert back to stock Buffalo firmware without luck. I could not tftp any of the factory "enc" files. It always comes back with "unsupported model". The only file I had luck sending via tftp was openwrt to do a brick recovery a while ago. The version 2 of this model seems much trickier to deal with then the original WZR-HP-G300NH. Buddee has tftp'd all kinds of files to the original unit without issue. Hopefully we get a revert bin file for the Version 2 just like they have for the original unit.
Joined: 06 Feb 2010 Posts: 7401 Location: Little Rock
Posted: Mon Nov 21, 2011 23:56 Post subject:
Deepdish wrote:
tomato120 wrote:
so is there no way to revert the unit back to the original Buffalo firmware now? Original firmware has been updated to 17798 and DDNS is working!
Well I tried every method under the sun to revert back to stock Buffalo firmware without luck. I could not tftp any of the factory "enc" files. It always comes back with "unsupported model". The only file I had luck sending via tftp was openwrt to do a brick recovery a while ago. The version 2 of this model seems much trickier to deal with then the original WZR-HP-G300NH. Buddee has tftp'd all kinds of files to the original unit without issue. Hopefully we get a revert bin file for the Version 2 just like they have for the original unit.
Hey Buddee, yup Win XP with a switch in between using command line or Pumpkin Tftp with the same result. Always comes back with "unsupported model". I found hitting enter at 12 seconds after power up to be the sweet spot and I can tell the router is listening because the diag light starts to flash twice when the file is attempting to send. It would be nice if you could get your hands on a Version 2 to see what you observe.
Joined: 06 Feb 2010 Posts: 7401 Location: Little Rock
Posted: Wed Nov 23, 2011 0:18 Post subject:
Deepdish wrote:
It would be nice if you could get your hands on a Version 2 to see what you observe.
Yes i have thought about that as well, only problem is when i order from Newegg, they can not tell me what version hardware i'll get, something about "well thats in a warehouse somewhere else, we just handle customer support" _________________ Wireless N Config | Linking Routers | DD-WRT Wiki | DD-WRT Builds | Peacock - Broadcom FAQ
Also I do believe the static arp I am using is working as the router seems to report to TFTP that it is an "unsupported router" which I don't think it would do if the file isn't being recognized but I could be wrong.
Which MAC address did you end up using for the static arp entry? I haven't seen a definite answer to that question yet for the v2 of this router. I've tried my router's LAN MAC, and I believe I tried the generic MAC listed for wzr-hp-g300nh v1 (I may have pasted the wrong one). Tried with Linux and Windows and on a in-between switch with the same results. It just seems that the TFTP client never finds the TFTP server. I think it's because I have the wrong MAC. I've flashed several other models of routers using TFTP before, but never had this much trouble.
I used 02:AA:BB:CC:DD:1A as the mac address for the static arp entry as per an Openwrt Wiki guide I found for the version 2. I also tried the routers own mac address. There doesn't seem to be nearly as much known about this router yet compared to the version 1. I wonder if anybody has successfully Tftp'd the version 2 yet?
Thanks. Now at least I think I got as far as you got, but I still could not get any Buffalo firmwares to be accepted by the TFTP server either. I tried using the non-advanced Buffalo firmware, which doesn't have an extension, but I think it's still encrypted. One thread mentions this problem on the version 1 model when using the wrong region of firmware. However, firmware for version 2 is the same for every region. Someone on the Buffalo forum mentioned this and suspected TFTP only works for a particular hardware region--whatever region that matches the firmware they release for every region. I'll keep searching and post here if I ever get it flashed with the Buffalo firmware. Maybe I'll give it a try in Windows now. Here's what I did:
~$ sudo arp -s 192.168.11.1 02:AA:BB:CC:DD:1A
~$ cd Desktop
~/Desktop$ tftp 192.168.11.1
tftp> verbose
Verbose mode on.
tftp> binary
mode set to octet
tftp> trace
Packet tracing on.
tftp> rexmt 1
tftp> timeout 60
tftp> put wzrhpg300nh2-180
putting wzrhpg300nh2-180 to 192.168.11.1:wzrhpg300nh2-180 [octet]
sent WRQ <file=wzrhpg300nh2-180, mode=octet>
sent WRQ <file=wzrhpg300nh2-180, mode=octet>
sent WRQ <file=wzrhpg300nh2-180, mode=octet>
received ACK <block=0>
sent DATA <block=1, 512 bytes>
received ERROR <code=0, msg=Unsupport MODEL>
Error code 0: Unsupport MODEL
tftp> quit
sent DATA <block=1, 512 bytes>
received ERROR <code=0, msg=Unsupport MODEL>
Can you upload the first 512 bytes of the firmware?
The received error code is because he can upload the first 512 bytes which Buffalo's u-boot checks for valid model, hw-version, and region before accepting the reminder of the file. _________________ Kernel panic: Aiee, killing interrupt handler!
