Well, I screwed up a flash command, and blew away the bootloader.
Still fiddling with it? What can I do to help? Bought a c1900v2 thinking C9 firmware would would, and didn't realize the lack of support for v2 until now.
Posted: Fri Jan 01, 2021 17:37 Post subject: This is my understanding of what is happening
The FCC changed the law governing firmware and after a certain date (forgot the actual) there will be no more 3rd party firmware updates. The firmware will now have to be offered thru the manufacture. Just saying and that's my understanding. I also purchased a an Archer 1900 v2. Actually bought 2 they work well and perform well one of the only routers for the price that offer 2 1gig processors. The one I use for my vpn route the only downside is you can setup one vpn server at a time so it is kind of a pain. And you can't use open vpn. Aside from that all is good. I've already left a ticket at tplink asking for more vpn functionality maybe they'll listen but probably not. If I want more I'm probably going to have to step up to a more expensive router.
Cheers
Joined: 08 May 2018 Posts: 14247 Location: Texas, USA
Posted: Sun Aug 22, 2021 5:00 Post subject:
Serial dump of fullflash and bootlog would help; also a serial log of what happens when you try to flash it. And apparently, nobody has tried to TFTP flash this one. Press and hold wps/reset button, power on, 5-4-3-2-1, release, push the factory-to-ddwrt file. Be prepared to de-brick if necessary.
If you want 100% official support, a hardware donation will help.
Serial dump of fullflash and bootlog would help; also a serial log of what happens when you try to flash it. And apparently, nobody has tried to TFTP flash this one. Press and hold wps/reset button, power on, 5-4-3-2-1, release, push the factory-to-ddwrt file. Be prepared to de-brick if necessary.
If you want 100% official support, a hardware donation will help.
Serial dump of fullflash and bootlog would help; also a serial log of what happens when you try to flash it. And apparently, nobody has tried to TFTP flash this one. Press and hold wps/reset button, power on, 5-4-3-2-1, release, push the factory-to-ddwrt file. Be prepared to de-brick if necessary.
If you want 100% official support, a hardware donation will help.
I recently pulled out my C1900v2 (stock fw 161117) just this past weekend and happy to announce that I installed the C9v1 firmware. I haven't fully tested it yet, so I don't know for certain in regards to its functionality, but I will be setting it up and testing within the next few days.
To make a long story short, I removed the flash from the pcb and backed it up with a T48 programmer. Directly flashed different modified bin files directly with the programmer, soldered it back on, and tested what would happen. Did this about 6 times.
There was one instance where I took the stock (UN) C9v2 firmware, modified that bin file so that the starting hex values matched the ones from my backup. Flashed that bin file and tested it. While the router was bricked, interestingly enough, my TFTP server log was now asking for an ArcherC9v1_tp_recovery.bin instead of the ArcherC1900v2_tp_recovery.bin. Considering I modified the stock C9v2 firmware, I found that unusual. After still failing at numerous flash attempts, I gave up and flashed my backup and called it a day.
I then pulled out my serial programmer, soldered the 3-pin header on the router for TX,RX, and GND, and this is where things started heading up hill.
Instead of getting into the CFE console via the 5 second reset hold, I just did it via holding ctrl+c in putty while turning the router on. (I don't know if this makes a difference.) Also... I was using TFTP32 to upload the bin files.
The only way I was able to get flashing to actually work, I used the following commands with the router on stock fw 161117, using the dd-wrt C9v1 bin files:
wait a few minutes. It will say "Programming...done."
Code:
CFE> reboot
In the serial console, you will see that it actually attempts to boot but then kicks you back into CFE with the error "Could not load flash0.os:: Unsupported function." Next thing I did was flash archer-c9v1-webflash.bin. For my case, the router was now on the default dd-wrt subnet. So you may have to change your static IP to 192.168.1.66 if the file transfer isn't working.
Same deal. Wait again until it says "Programming...done." I threw in an "nvram reset" just because.. (I don't really know what I'm doing.) Finish it off with a reboot, and give it a moment to start up. You will notice in the serial console that the router is actually doing something. About 2 minutes later, the unsecured dd-wrt access point showed up and I was able to log into dd-wrt. I originally tried the same procedure with the C9v2 bin files, it booted, but did not initialize the interfaces.
So that's it, serial and tftp is seemingly the only way to get the C1900v2 on dd-wrt.
On another note, it seems that the C1900v2 is in fact just a C9v1. Not the C9v2 despite what the FCC ID says.
Joined: 08 May 2018 Posts: 14247 Location: Texas, USA
Posted: Wed Apr 03, 2024 5:31 Post subject:
The normal way to enter CFE prompt is CTRL+C on Broadcom - TFTP recovery is via 5-second reset hold on power-up.
llenp wrote:
Instead of getting into the CFE console via the 5 second reset hold, I just did it via holding ctrl+c in putty while turning the router on. (I don't know if this makes a difference.) Also... I was using TFTP32 to upload the bin files.
Unofficial possibly one-way methods aren't quite advisable, Caveat Emptor for future readers. The most reliable method of support is hardware donation as previously advised. No serial logs for stock firmware, hacky dd-wrt flash, fullflash dump of stock firmware, etc. isn't helpful to the developer(s), either.
The normal way to enter CFE prompt is CTRL+C on Broadcom - TFTP recovery is via 5-second reset hold on power-up.
Okay this makes sense. During one of my intentional bricks, it broke TFTP recovery and went straight to CFE. So I didn't know the difference.
kernel-panic69 wrote:
Unofficial possibly one-way methods aren't quite advisable, Caveat Emptor for future readers. The most reliable method of support is hardware donation as previously advised. No serial logs for stock firmware, hacky dd-wrt flash, fullflash dump of stock firmware, etc. isn't helpful to the developer(s), either.
Totally understand! I know my method isn't for everyone. I don't typically work with routers and don't know what I have to offer that dd-wrt veterans don't already know. This was just a mini weekend project to see if I can actually do it. So far everything that works on my official dd-wrt C9v1 is also working on the C1900v2. Virtual APs, vlans, openvpn. I also flashed r55576 via the web gui. But I can always go back, flash my original dump, and provide better documentation if anyone cares for it.
One thing I do recall was seeing a checksum mismatch happening with the old stock firmware whenever I attempted to load anything other than stock firmware made for that specific model. It took a second to get detected, and then automatically rebooted with no flash attempt. I'm guessing this was on TP-Links part to abide by FCC regulations? On principle, maybe the one-way method isn't such a bad thing.
Last edited by llenp on Wed Apr 03, 2024 14:56; edited 1 time in total
Joined: 08 May 2018 Posts: 14247 Location: Texas, USA
Posted: Wed Apr 03, 2024 14:54 Post subject:
llenp wrote:
But I can always go back, flash my original dump, and provide better documentation if anyone cares for it.
Complete documentation is _always_ preferred, but that is entirely up to you.
llenp wrote:
One thing I do recall was seeing a checksum mismatch happening with the old stock firmware whenever I attempted to load anything other than stock firmware made for that specific model. It took a second to get detected, and then automatically rebooted with no flash attempt. I'm guessing this was on TP-Links part to abide by FCC regulations?
No, it was probably a bad hexedit of a file. The header has to have the right checksum or it gets refused or the router gets bricked (worst case).
My apologies, I wasn't clear. This was during my attempts to flash an unmodified factory-to-ddwrt.bin (and various other unmodified firmware) via TFTP while the router was on stock firmware.
Some time ago, I accidently bricked my stock C9v1 when I accidently flashed the wrong firmware for another router. Fortunately, I was able to boot into recovery and restore it. It's just that unlike the C9v1, the C1900v2 just deliberately rejects anything that isn't stock version 161117 or 220524.
