TFTP Connect Request Failed
Opened this issue · 6 comments
I'm getting an error during the TFTP:
Immediately executing TFTP transfer to 192.168.29.1 ...
Connect request failed
The recovery webpage is up and working on 192.168.29.1
Side note: Since my router was upgraded to the latest T-Mobile firmware, I have been unable to use the recovery webpage to update the firmware. I repeatedly get the message:
Receive file size=16949296
The file transferred is not a valid firmware image.
Trying to use the Asus Recovery software has failed as well.
So I don't know if this is a problem with the method or with the router.
I have Googled around and not seen a solution to the "invalid firmware" problem. I was hoping that the Badger would be a fix.
Edit: For any future visitors to this issue thread...
...please also check out this wiki page: https://github.com/jasonbuechler/asus-rebadger/wiki/TFTP-Troubleshooting
Very interesting... can you copy/paste the entire powershell window to a gist or attach a .txt here or something, so we can pick through for any clues?
The only time i can recall (for what that's worth) getting a connect-request-failed error was when there was no route. Once it happened because I was manually configured to the wrong subnet, and another time it happened when I was wired to the WAN port instead of LAN port... but I don't think that could be the case for you if you can see the miniCFE page.
On my newest tm-ac1900, I was also was unable to get the miniCFE page to work, and I was sure to do it quickly... that was actually why I originally wrote the first core pieces of v1 of the badger. And just the other day I tested reverting from...
- the newest tmo CFE
- the 1703 tmo firmware (I couldn't find a trx of the latest tmo firmware)
...and was successful at getting back to stock asus and then back up to the latest Merlin.
Just to verify-- you're executing the TFTP combo step ("C" chaining "D" and "E" together) immediately after...
- powering off router
- holding down the recessed reset button in back
- powering on the router
...correct? The window of opportunity is exceptionally small so I figured I'd at least ask.
Interestingly, stingy on slickdeals also mentioned being suspicious of TFTP being an option for kicking it back to 1703, but it worked right off the flop for me... Maybe try it immediately following an NVRAM whack (with the WPS button)? Unfortunately, I didn't check what tmo firmware was installed when I originally reverted, so I can't be sure I was on the latest :/
OH
Is your windows machine, by any chance, governed by a non-default group policy? Or you have a software firewall? Crap, I definitely had made a mental note to put this in the help notes somewhere, but
I kinda recall the first time you attempt to use a TFTP connection, the windows firewall will prompt you asking if you're sure you're cool with opening that port. (Although I might be remembering this for SCP/SSH... I'm pretty sure it was tftp... kinda sure.) It's easy to dismiss as just another annoying windows popup, but it's necessary to allow the connection. Or similarly if you have some software firewall, it might be seeing this unusual traffic and putting the kibosh on it immediately. A quick google says remote UDP port 69 is the one to allow... if for some reason it was blocking on a port-specific basis. Which doesn't make a lot of sense to me but whatever, we're just spitballing here.
Another thought... I was convinced that the tftp server would operate using the default ipv4 configuration currently on the router (and logically, set by the firmware)... but I guess there's no reason that has to be true. It's possible as part of their defense, they could be accepting tftp on another address in that subnet? I just am skeptical they'd disable tftp entirely, since i think that's what the asus recovery tool uses and probably how they do it at the refurb processor. definitely would be worth port scanning to see?
crossing fingers something in there helps!
Ok, so it appears I was one of the "lucky" ones according to this wiki on slickdeals: https://slickdeals.net/f/12685621-t-mobile-wi-fi-cellspot-router-tm-ac1900-certified-pre-owned-39-99-plus-free-shipping#post124717105
If accessing the mini-CFE webserver doesn't work at all for you...
You are experiencing the effects of a locked firmware...
You have to change Guides.
Directions for rolling back to AC68 after AC1900 rollback: Direct Google Docs Link [google.com]. We call this the Google Doc. Guide. You can download it here [mega.nz]
What is wrong with the T-Mobile 3199 firmware
The Cellspots are USUALLY now shipped out with firmware 3199, that makes it harder for you to downgrade that firmware. Sometimes you get lucky with the above steps, sometimes you don't.
This is also caused if you have a converted a Cellspot -TM-AC1900 to RT-AC68U, that did not do the MTD5 commands, and attempted to do a firmware update past 3.0.0.4.384.20308.
And indeed perhaps this is what stingy was referring to when he warned TFTP might not work for the initial step -- but I cannot verify this. I have lots of reservations from a technician's perspective about the likelihood they would disable TFTP... and thoughts about how they might have changed access to it... but the quicker answer is it's pretty damned simple to circumvent using a vulnerability in one of the tools in the router's webgui. Well easy for me and probably you, but not so much for other people maybe. Check that google doc and ping me back if you have any questions.
Unfortunately, for the life of me, I can't force my stupid router to update to recent tmo firmware. I can push the latest tmo cfe onto it and get old tmo trx on there... newer asus firmware... manual trx upload... on-board firmware update... whatever I try, I can't trigger the tmo "takeover", so I can't verify any of these difficult issues. :(
For any future visitors to this issue thread...
...please also check out this wiki page: https://github.com/jasonbuechler/asus-rebadger/wiki/TFTP-Troubleshooting
I've got a RT-AC68U router on the latest firmware! (Well, honestly waiting a few days to make sure it doesn't default back to TM-1900AC...)
To document the error I was getting at the wget step in the "Google Doc" method, I ran through the steps again. And I didn't get the error! So without thinking, I went all the way through.
So sorry I won't be able to provide the TM-1900AC files you requested to troubleshoot the TFTP connect failing at this time.
But please post the instructions on what files you would like and the method to get them. I should have another TM-1900AC coming in a few days that I can upgrade to the new firmware. Or someone else may step in while I'm waiting for the delivery.
Sorry my late reply, @SpicyITC -- thanks for the update! so just sorta stream of consciousness (since I don't have a nicely list made up) I'll throw some stuff out there:
- the full file listing on the router (e.g. "the google doc" mentions using the 'find' command in appendix 5 ... or if you had shell access before changing (most) of the files, you could just use that to "find /"
- I'm not sure how you could copy it, but if the url for it is in any log anywhere on the router, I'd love to grab the trx of the current tmo firmware
- getting the trx might not be possible, but getting its components in-place is possible using the same method we use to backup the mtd5 flash memory block, but for all the others too (e.g. "cat /dev/mtd0 > /jffs/mtd0.bin; cat /dev/mtd1 > /jffs/mtd1.bin; cat /dev/mtd2 > /jffs/jtd2.bin;" etc...)
- oh maybe the most valuable to me, would be investigating exaaaactly what happened to the TFTP service upon putting the router into recovery mode. I'd be curious to grasp at straws and try a whole bunch of different things including changing subnets/IPs, port scanning, different button combinations, etc. I can't remember where I read it (it was probably in the middle of a thousand-comment deep Slickdeals thread) but someone reported that simply after doing it over and over more than 10 times it suddenly worked. soooo...) but maybe we can identify something
- i'll return to this list as I think of things... if i think of things. :p thank you!
I've got two routers delivered today. Yes, T-Mobile duplicated my order and billed me for both. So I've got two to play with and decide what I want to return when I'm done.
One router is at the latest 3199 version. The other router is at 3181. The 3181 prompted me to upgrade the firmware, but allowed me to cancel.
My thinking is tonight I'll run the 3181 through the Badger and see if I find any bugs. I'll turn off the TFTP and confirm I get prompted this time.
Is there anything else I should test about the Badger for firmware 3181?
Then I can take a look at the 3199.