All that remains is for the firmware to get loaded, but the router doesn’t seem to pick it up. Any clues why? How can I check that the TFTP server is working correctly?
Your router is mac address xx…:41 and computer is xx…:ef ?
You’re right, from the timestamps it should be already transferring tftp firmware via udp - wireshark is how you check, you should see the filename being requested (tftp port 69). And the router should be initiating the transfer.
If it doesn’t after a couple of more attempts, order this one:
, hook it up to a raspberry pi SPI pins, and use flashrom to flash. OTOH you probably need to remove first 128bytes from the image file you get from tp link website. You could also use the pepe2k bootloader for that board / router, or just the original one from his repos.
I would advise this or if you know how to remove the information from the image file you can try that but its a daunting endeavor for a newbie to the deal…
@risk some asus ruters have this but Im curious… could you buy the chip that has the firmware and solder it on? like I said only some routers have this floating around
Theres also a recovery mode stated in the WIKI is that broke?
Firmware recovery worked from a different computer running Ubuntu and tftpd-hpa server
“Factory” (ddwrt) firmware was the one that worked (vs webflash firmware)
Best method found for checking tftp server: netstat -an | grep 69
Noticed: Ubuntu had udp and udp6 listed listening for port 69, while the Fedora machine that failed had only udp6. Could that be the reason? I even disabled IPv6 in the ethernet connection with Network Manager. Wireshark showed IPv6 addresses and TFTP transmission never took place.
All settings (static IP, ssh key, wifi password, ssid, etc) are intact on the undead router! I thought 30/30/30 resets (probably did a dozen times) were supposed to clear them and restore default settings??
I’m puzzled, and would eventually like to figure out the problem with the Fedora machine, but for now, problem solved.
Appreciate the replies. @risk you were correct about the router and computer mac addresses. I was really hoping to avoid the physical interventions…
@PhaseLockedLoop which recovery mode stated in the wiki? It’s kinda confusing. There’s a bit about telnet, but only for v7, and for the others it refers back to the TFTP method. I might have missed some(many)things. To give you an idea of my level of noobness on this subject, today is the first time I heard of TFTP…
Anyways, now I appreciate this little router/AP even more! Firmware failsafes are now high on my priority list for routers, motherboards, etc
It would seem maybe you were missing some command line switch to enable tftp over udp/ipv4.
I’d normally use dnsmasq as a tftp server, purely because of my own personal familiarity with it and the fact it can run without a config file making it handy for once off uses. For example: $ sudo dnsmasq -kd -p 0 -C /dev/null -u nobody --enable-tftp --tftp-root=/srv/ftp
pepe2k bootloaders have an http webserver built-in (similar approach to some of Netgear/D-Link stuff) that you can use to upload the new firmwares; it’s handy if you’re messing with firmwares a lot), but as @PhaseLockedLoop would say “…can be daunting…” TFTP client that TP-Link uses in their bootloader, with a fixed ip, is almost as good of a solution.
Yes, but it’s far easier to buy the test clip (one clip will fit all the flash chips that have the form factor, 90% of the routers out there of various brands, usually those with less than 32MB of flash, also some other devices, all use soic-8), and attach it onto the chip/board without any soldering at all.
You can also cross your fingers and flash from existing firmware, and take a screwdriver only if you screw something up.
flashrom can then use the SPI interface e.g. on a raspberry pi to talk to the chip directly. It’ll autodetect the exact type of the chip, and from there all you need is contents to flash, which manufacturers usually provide as part of some update image.
Alternatively, you can read the existing contents, back it up or compare it with a known good image.
Newer and more expensive routers with 128/256/512/1GB flash, use NAND storage (cheaper smaller are single byte addressible NOR) and those larger chips are usually physically different, they come in a couple of different sizes and will typically support a couple of different protocols (some kind of single byte at a time emulation is common, but usually they’re meant to be accessed a page at a time). I don’t have as much experience with those, but their datasheets are public, and you can find which one your router uses on wikidevi usually.
What do your systemd unit files look like? Do you use socket activation or do you have a permanently running service? Does anything in this bug ring a bell with your setup?
Brilliant. That bug (from 2013!!) sounds identical, and the workaround proposed (ListenDatagram=0.0.0.0:69) works to get udp (and not udp6) listed by netstat.
Not sure, both?
$ sudo systemctl stop tftp
Warning: Stopping tftp.service, but it can still be activated by:
tftp.socket
I stop both tftp.service and, due to this warning, also tftp.socket. Now with your comment it makes more sense.
These are the two relevant (original) systemd files at /usr/lib/systemd/system/.
Hmm, Fedora seems to set bindv6only by default globally? interesting. I wonder if you end up having issues with other socket activated servers, or what their files look like.
Either way, I’m happy the mystery is resolved now.
