Restoring TP-Link Archer C7 V4 (US) back to stock firmware

Post new topic   Reply to topic    DD-WRT Forum Index -> Atheros WiSOC based Hardware
Goto page Previous  1, 2, 3  Next
Author Message
msoengineer
DD-WRT Guru


Joined: 21 Jan 2017
Posts: 1782
Location: Illinois Moderator

PostPosted: Tue Apr 28, 2020 14:11    Post subject: Reply with quote
Read this to help you understand about using wireshark to find out the right filename the router is looking for to recover back to stock firmware.
_________________
FORUM RULES

TIPS/TRICKS: Best QCA Wifi Settings | Latency tricks | QoS Port priority | NEVER USE MU-MIMO |
Why to NOT use MU-MIMO | Max Wifi Pwr by Country | Linux Wifi Pwr | AC MCS & AX MCS | QCA 5Ghz chnls to use | WIFI Freq WIKI | TFTP R7800 | Don't buy AX | IPERF3 How-To

[R9000]52396 nightly (Main Router)
[EA8500]43192 & 45493 (2xOffsite)
[R7800] resting
[WDR3600]BS 44715 (Offsite)
[A7v5]BS 43038 (Offsite+spare napping)
Sponsor
ghl
DD-WRT Novice


Joined: 26 Apr 2020
Posts: 10

PostPosted: Tue Apr 28, 2020 15:45    Post subject: Reply with quote
msoengineer wrote:
Read this to help you understand about using wireshark to find out the right filename the router is looking for to recover back to stock firmware.


thanks for your answer.
I did it..
here's the name of file

and it's the end of block data package


As I said, I'm able to flash ANOTHER firmware, using ths name "ArcherC7v4_tp_recovery.bin"

My router appears just avoid "Original" fw..
I've been trying to flash All of fw in oficial tp-link download firmware for US devices.

always follow the same procedure..
its strange behavior cuz I know that procedure is right, cuz i can flash openwrt always that i try.. also LEDE proj.. just the oficial firmware doenst work.

thanks
msoengineer
DD-WRT Guru


Joined: 21 Jan 2017
Posts: 1782
Location: Illinois Moderator

PostPosted: Tue Apr 28, 2020 16:18    Post subject: Reply with quote
Being that you are in Brazil, do you know which version of the router you have, global or USA?

you might be grabbing the USA stock firmware when you should be using the global stock firmware... My guess it that something in the header file won't let you go back to stock which is most likely due to grabbing the wrong version of the stock firmware. I have no idea what TP-Link would sell in Brazil... what is printed on the bottom label on the router?

When I try searching their site with BR it has firmware files with a (US) in the filename...seems strange...
https://www.tp-link.com/br/support/download/archer-c7/v4/#Firmware

Try to use the oldest firmware file and rename it accordingly.

_________________
FORUM RULES

TIPS/TRICKS: Best QCA Wifi Settings | Latency tricks | QoS Port priority | NEVER USE MU-MIMO |
Why to NOT use MU-MIMO | Max Wifi Pwr by Country | Linux Wifi Pwr | AC MCS & AX MCS | QCA 5Ghz chnls to use | WIFI Freq WIKI | TFTP R7800 | Don't buy AX | IPERF3 How-To

[R9000]52396 nightly (Main Router)
[EA8500]43192 & 45493 (2xOffsite)
[R7800] resting
[WDR3600]BS 44715 (Offsite)
[A7v5]BS 43038 (Offsite+spare napping)
ghl
DD-WRT Novice


Joined: 26 Apr 2020
Posts: 10

PostPosted: Tue Apr 28, 2020 17:13    Post subject: Reply with quote
msoengineer wrote:
Being that you are in Brazil, do you know which version of the router you have, global or USA?
what is printed on the bottom label on the router?


It has a label that says its US. take a look:


msoengineer wrote:
you might be grabbing the USA stock firmware when you should be using the global stock firmware...

Maybe, but I'm trying to find another firmware with Global label, but nothing. Just (US) or (EU)

msoengineer wrote:

When I try searching their site with BR it has firmware files with a (US) in the filename...seems strange...
https://www.tp-link.com/br/support/download/archer-c7/v4/#Firmware
I noticed that.

msoengineer wrote:

Try to use the oldest firmware file and rename it accordingly.


I tried all of the versions available in official website download page. but nothing yet..

I was talking with another guy in another forum with same issue. He said that he never got back to stock.

I'll keep trying here. if you or someone have any clue, let me know. thanks in advance.
msoengineer
DD-WRT Guru


Joined: 21 Jan 2017
Posts: 1782
Location: Illinois Moderator

PostPosted: Tue Apr 28, 2020 18:28    Post subject: Reply with quote
And to confirm, you are running TFTP32, or tftp64, in SERVER mode?

Make sure, if using windows, to allow the program in the firewall rules for both private AND public because that 192.168.0.66 address on your NIC and the 192.168.0.86 on the router come up as a public network and can be blocked by the firewall and won't allow the server to work right.

you need to put the router into "recovery" mode my holding down the reset button for 10 seconds on power up.
the same rules for the A7v5 should apply to the C7v4- https://wiki.dd-wrt.com/wiki/index.php/TP_Link_Archer_A7v5#TFTP_RECOVERY_TO_REVERT_BACK_TO_STOCK

_________________
FORUM RULES

TIPS/TRICKS: Best QCA Wifi Settings | Latency tricks | QoS Port priority | NEVER USE MU-MIMO |
Why to NOT use MU-MIMO | Max Wifi Pwr by Country | Linux Wifi Pwr | AC MCS & AX MCS | QCA 5Ghz chnls to use | WIFI Freq WIKI | TFTP R7800 | Don't buy AX | IPERF3 How-To

[R9000]52396 nightly (Main Router)
[EA8500]43192 & 45493 (2xOffsite)
[R7800] resting
[WDR3600]BS 44715 (Offsite)
[A7v5]BS 43038 (Offsite+spare napping)
ghl
DD-WRT Novice


Joined: 26 Apr 2020
Posts: 10

PostPosted: Tue Apr 28, 2020 20:29    Post subject: Reply with quote
msoengineer wrote:
And to confirm, you are running TFTP32, or tftp64, in SERVER mode?

Make sure, if using windows, to allow the program in the firewall rules for both private AND public because that 192.168.0.66 address on your NIC and the 192.168.0.86 on the router come up as a public network and can be blocked by the firewall and won't allow the server to work right.

you need to put the router into "recovery" mode my holding down the reset button for 10 seconds on power up.
the same rules for the A7v5 should apply to the C7v4- https://wiki.dd-wrt.com/wiki/index.php/TP_Link_Archer_A7v5#TFTP_RECOVERY_TO_REVERT_BACK_TO_STOCK



As I said, it's not tftp issue.
1. I'm Using Linux
2. I'm able to flash ANY other firmware throught my working tftp Server running on Linux.
(today I flashed openwrt 2 times, and dd-wrt 1 time).
It's looks firmware specfic firmware thing.

Thanks in advance.
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 14125
Location: Texas, USA

PostPosted: Tue Apr 28, 2020 20:54    Post subject: Reply with quote
Is the file being used a stripped file with no bootloader?
_________________
"Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT
Pogo - A minimal level of ability is expected and needed...
DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)

----------------------
Linux User #377467 counter.li.org / linuxcounter.net
blkt
DD-WRT Guru


Joined: 20 Jan 2019
Posts: 5660

PostPosted: Tue Apr 28, 2020 22:33    Post subject: Reply with quote
I notice the two newest firmwares are the same links or files for both US and BR download pages.

The third and oldest file hosted for Brazil is from 2017 (older than on the US site). This 2017 firmware binary is also the smallest.

The filenames for all four binaries do not specify "boot", but I didn't verify with a hex editor.

Success reported with version 180425 using the method described below.

https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1186306#1176528
ghl
DD-WRT Novice


Joined: 26 Apr 2020
Posts: 10

PostPosted: Wed Apr 29, 2020 2:55    Post subject: Reply with quote
kernel-panic69 wrote:
Is the file being used a stripped file with no bootloader?


Hello my friend, thanks in advance..
I tried to strippe the orig firmware and flash using tftp or throught ssh in router

I did
Code:
dd if=orig.bin of=tplink.bin skip=257 bs=512

than
Code:
mtd -r write /tmp/tplink.bin firmware


no success..
ghl
DD-WRT Novice


Joined: 26 Apr 2020
Posts: 10

PostPosted: Thu Apr 30, 2020 4:34    Post subject: Reply with quote
kernel-panic69 wrote:
Is the file being used a stripped file with no bootloader?


Hello friend.. I was trying to figure out Whats the difference between my environment while I'm trying to flash, and those that had success Flashing the same router with some issue..

I'm using Linux (Ubuntu, Fedora, and ArchLinux) and Mac (Catalina).. Don't have windows.

All that had success (almost that i saw) had been using Windows, and tftp 32bit program..

So, first as another test, I decided to try use another tftp (32bits).. than I create a vm with CentOS 7, 32bits and configure tftp-server.

No success. I can see the router ask for firmware.. it's seems normal.

Quote:
Apr 29 20:00:03 c732b systems: Started Tftp Server.
Apr 29 20:01:52 c732b in.tftpd[1606]: Client ::ffff:192.168.0.155 finished is_tftp_get_work.txt

Apr 29 20:13:59 c732b in.tftpd[1606]: Client ::ffff:192.168.0.86 finished ArcherC7v4_tp_recovery.bin
Apr 29 20:13:59 c732b in.tftpd[1606]: Client ::ffff:192.168.0.86 timed out

Apr 29 20:23:34 c732b in.tftpd[1606]: Client ::ffff:192.168.0.86 finished ArcherC7v4_tp_recovery.bin
Apr 29 20:23:34 c732b in.tftpd[1606]: Client ::ffff:192.168.0.86 timed out

Apr 29 20:34:12 c732b in.tftpd[1606]: Client ::ffff:192.168.0.86 finished ArcherC7v4_tp_recovery.bin
Apr 29 20:34:12 c732b in.tftpd[1606]: Client ::ffff:192.168.0.86 timed out


As i said, I'm able to flash openwrt fw without problems.. this firmware has around 5mb. I don't know if it's means something.

Which tftp server you're use?

Now, I'm starting to install windows 10 in VM, and trying to create the same environment that someone had success.. I'll let you all know.

_________________
-
1x tplink 1043nd v2
3x tplink wdr4300 v2
1x tplink Archerc7 v4
Client Bridge, WDS, Repeater, AP, Router.
msoengineer
DD-WRT Guru


Joined: 21 Jan 2017
Posts: 1782
Location: Illinois Moderator

PostPosted: Thu Apr 30, 2020 5:44    Post subject: Reply with quote
Just to confirm, does your C7v4 have both a reset button and WDS button?

Are you pressing the reset button(recessed into the router housing) and NOT the WDS button?

If you are indeed pushing the reset button, maybe the gpio mapping of the reset button is wrong on dd-wrt and so the reset button doesn't work and does not enable tftp recovery mode... The A7v5 had this issue until I asked BS to fix it.

To check the reset button to make sure it works, see if it actually clears all the router settings, if so, it's working and you don't need to check the gpio mappings, if not, post that it's not working and I will follow up.

_________________
FORUM RULES

TIPS/TRICKS: Best QCA Wifi Settings | Latency tricks | QoS Port priority | NEVER USE MU-MIMO |
Why to NOT use MU-MIMO | Max Wifi Pwr by Country | Linux Wifi Pwr | AC MCS & AX MCS | QCA 5Ghz chnls to use | WIFI Freq WIKI | TFTP R7800 | Don't buy AX | IPERF3 How-To

[R9000]52396 nightly (Main Router)
[EA8500]43192 & 45493 (2xOffsite)
[R7800] resting
[WDR3600]BS 44715 (Offsite)
[A7v5]BS 43038 (Offsite+spare napping)
ghl
DD-WRT Novice


Joined: 26 Apr 2020
Posts: 10

PostPosted: Fri May 01, 2020 0:53    Post subject: SOLVED! Reply with quote
# Post DD-WRT about Archer C7

Hey guys, I'm writing now to say that I finally got to get my Archer C7 v4 back to the STOCK firmware version.
First, I would like to thanks the whole community that strives to help us, whenever we are in distress and does not abandon us during those hard journey that is to solve problems.. hehe
I will share with you you all, here, everything I did from the beginning, my environment, what tests I did, and how I FINALLY understood the "BUG" and managed to solve it.

I had a problem here, using 13 hosts behind a TP-Link WDR4300 v1.2 that was in Client Bridge mode with my Archer C7 v4 (until then, Stock FW).
As you all well know, Client Bridge mode works very well if you have 1, maybe 2 hosts behind it. More than 1, or 2, problems start to appear. Issues Like:
I started to lose connectivity between the machines, latency problems, and among other things, the Main ROUTER (Archer C7v4 with stock firmware) had recognize all of those hosts that were behind wdr4300 with the same MAC_ADDR.

So, I had to use WDS mode to "Solve this problem", but for some reason the "WDS Station" mode (on wdr4300 v1.2) connected to Archer C7 v4 (with stock firmware), doen't work fine. All of the hosts connected directly to Archer C7 (Main Router with Stock Firmware at this moment) had connectivity issues with the hosts behind wdr4300.

So, After searching for solutions a little bit, I decided to update Archer C7v4 to dd-wrt and configure WDS mode between those TP-Link Routers.
I solved the MacAddr and connectivity problems, but I created another problems .. Archer C7 does not perform well with dd-wrt in WDS mode (as of the date of this post). Or at least I was not had better performance here.
I saw other people reporting the same problem on various forums with same router that I have. To give you an idea, I was reaching less than 1/4 of the speed provided by my ISP using this topology thorught Wireless Network:

Topology:

Quote:
Archer C7v4 (DD-WRT) as WDS AP ---> wdr4300 v1.2 (DD-WRT) as WDS Station.


I tried to improve performance in several ways, and I also migrated to openwrt to do some tests (openwrt stable version, and snapshot version), but it didn't even come close to Archer C7v4 ( With Stock firmware).

Then my journey to get back to stock firmware started:

I have 4 notebooks with Linux and 1 MacBook Pro here.
I set up tftp on all of them, and made sure they were working. I'm sure about that because I was successful in Flashing using various versions of openwrt.

But whenever I tried to install (Flash) Stock firmware, the router would reboot using the version of OpenWRT that was previously installed (LEDE).
I started capturing logs and started observing this msg in the Error Log: I reported it here some days ago:

Quote:
Apr 29 20:00:03 c732b systems: Started Tftp Server.
Apr 29 20:01:52 c732b in.tftpd[1606]: Client ::ffff:192.168.0.155 finished is_tftp_get_work.txt

Apr 29 20:13:59 c732b in.tftpd[1606]: Client ::ffff:192.168.0.86 finished ArcherC7v4_tp_recovery.bin
Apr 29 20:13:59 c732b in.tftpd[1606]: Client ::ffff:192.168.0.86 timed out

Apr 29 20:23:34 c732b in.tftpd[1606]: Client ::ffff:192.168.0.86 finished ArcherC7v4_tp_recovery.bin
Apr 29 20:23:34 c732b in.tftpd[1606]: Client ::ffff:192.168.0.86 timed out

Apr 29 20:34:12 c732b in.tftpd[1606]: Client ::ffff:192.168.0.86 finished ArcherC7v4_tp_recovery.bin
Apr 29 20:34:12 c732b in.tftpd[1606]: Client ::ffff:192.168.0.86 timed out


This "timeout message" seemed strange behaivor for me. For example, a TFTP server gave me some logs, but without much informations.. Even if you set the parameters -vvvv or --verbose=7.(tftp-hpa or tftpd-server respectively)

The procedure I used as a base when I started my troubleshooting journey, was published a following, user: @chewyfood


https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1186306#1176528


As I was always successful in writing the openWRT firmware version using this procedure, I started to think that the router was REJECTING all of the Original firmwares. Researching I saw that many people recommend using tftp32bits, but ALWAYS for windows, and never explained "what problems" they had with tftp 64 bits version.
I Decided to install 32-bit CentOS and configure the 32-bit tftpd-server .. but the logs are not changed.

I tried to imagine what the differences were between my procedure and environment, comparing to the procedure of the people who succeeded in Flash/Write Archer C7v4 with Stock firmware.

The difference was that everyone used Windows (at least from the posts I saw) and used 32bit bits on Windows.
Seeing some tftp32 for windows screenshots, I realized that it interface gave a lot more information, more records, more details.

Then, I Decided to eliminate this variable.

With VirtualBox, installed a Windows10 VM, in bridge mode with my eth0 (wired) network interface, I setted to perform TFTPD (192.168.0.66/24), Performed the necessary tests, (Telnet, tftp <host> get hello.txt, netstat -na|grep :69) and when everything was look like OK .. start the tests with differents firmware versions.

bellow I'll post some screenshots that occurred during this.

In this image, I was still using the LAN1 port and keeping the reset for longer, even after the WDS LED turns ON.
Following this procedure of holding or resetting without knowing exactly when release "reset button", a transfer ended with random progress. sometimes around 70%, sometimes around 80%.


In this image below, I started testing the "waiting pushed botton time"
to check if there was a connection and then observing that it made a difference (at least in my case)


In this image below, I understand that release reset button more quickly, the transfers throught move forward and transfer more data, at this point, it is possible to resolve the use of the SMALLEST firmware (the oldest)
The bug that I identified is for the latest firmware: I Cloncluded that: Or the Archer tftp client Always ends the connection and restarts before it ends, or it's simple REJECT the firmware.
In the image below, it seemed that the transfer was still happens ... but the Router had already restarted itself, the transfer broken and was already responding in openwrt.


In this image below, I was doing another one of the tests, using asmaller one firmware version. When I got at 99%, it was resolved. And I tryed to use 2017 firmware that I found in one of my researches, and then I was successful.

Analyzing all this, I started to realize some things that I will list for you:
- the Firmware was never COMPLETELY downloaded, and it gave an error most of the time.
- Firmware Progress varied according to the firmware size (larger file, lower percentage transfer, smaller file transfer == transfer percentage was GREATER, close to 100%)
- the behavior varied when trying to download the same firmware, more than once. Sometimes the transfer was very fast, sometimes slow, sometimes it reached 98%, other times 80%.

So I decided to do some tests that were not so clear in the procedures that I read, and that was not easy to identify since I always used to record the openwrt and it worked.
I Noticed that the openwrt has only 5mb and the stock firmware, and dd-wrt firmware around 13/14 / 15mb ..

I switched the network interface from LAN port 1 to LAN 4
After realizing that "staying holding the reset button forever after turning on the router" changed the time "that the tftp-client" of the router was active downloading the firmware .. I decided to try "Release the reset button" as fast as I could succeed, immediately after the WDS LED lights up.

Ready, Successful transfer. I GOT IT!!!

For the VERY first time in 5 days I saw the following msg in the logs:
Quote:
"<ArcherC7v4_tp_recovery.bin>: sent 8348 blks, 4274087 bytes in 1 s. 0 blk resent"


Conclusion that I arrived.
This version of the router has a BUG when using tftp. A connection between the router (such as the tftp client) and the server timeout, decreasing random times.
In several tests that you did, IN MY ROUTER, release the reset button more quickly as soon as WDS led will light up (EVEN IF YOU DON'T
SEE TRANSFER STARTS ON THE 32BITS TFTD IN WINDOWS)
It always made me "move forward" in the amount of data transferred.
What I mean is while I was delayd to release reset button, the transfer achived 60% / 70% and When I started to release reset button FAST it, a transfer rate started to be higher, And I Achived 98/99%
So I decided to get the "SMALLEST FIRMWARE" that I found on my version of the router (the oldest)

My model is Archer C7 (US) v4: official download page for an older version we have is "Archer C7 (US) _V4_180315"
I'll leave here the link for Oldest Firmware that I found:
See the version "Archer C7 (US) _V4_170301" which has the smallest file size:
I will make it available here for those who need it

Download the stock firmware "Archer C7 (US) _V4_170301": http://tiny.cc/g584nz

Also I'll leave here my tftp logs about some of the attempts that have using "windows10" until success (Trying another LAN Port, and release RESET BUTTON as fast as you can imediatly after WDS Led turns on)

Quote:
Connection received from 192.168.0.86 on port 2302 [29/04 22:09:00.335]
Read request for file <ArcherC7v4_tp_recovery.bin>. Mode octet [29/04 22:09:00.335]
OACK: <timeout=5,> [29/04 22:09:00.335]
Using local port 57498 [29/04 22:09:00.335]
TIMEOUT waiting for Ack block #24711 [29/04 22:09:35.367]
Connection received from 192.168.0.86 on port 3460 [29/04 22:10:44.006]
Read request for file <ArcherC7v4_tp_recovery.bin>. Mode octet [29/04 22:10:44.006]
OACK: <timeout=5,> [29/04 22:10:44.006]
Using local port 57499 [29/04 22:10:44.006]
TIMEOUT waiting for Ack block #29324 [29/04 22:11:19.054]
Connection received from 192.168.0.86 on port 2606 [29/04 22:15:52.329]
Read request for file <ArcherC7v4_tp_recovery.bin>. Mode octet [29/04 22:15:52.329]
File <ArcherC7v4_tp_recovery.bin> : error 2 in system call CreateFile The system cannot find the file specified. [29/04 22:15:52.329]
Connection received from 192.168.0.86 on port 3357 [29/04 22:16:46.328]
Read request for file <ArcherC7v4_tp_recovery.bin>. Mode octet [29/04 22:16:46.328]
OACK: <timeout=5,> [29/04 22:16:46.328]
Using local port 57501 [29/04 22:16:46.328]
TIMEOUT waiting for Ack block #28908 [29/04 22:18:31.532]
Connection received from 192.168.0.86 on port 3063 [29/04 22:21:21.798]
Read request for file <ArcherC7v4_tp_recovery.bin>. Mode octet [29/04 22:21:21.798]
OACK: <timeout=5,> [29/04 22:21:21.798]
Using local port 57502 [29/04 22:21:21.813]
TIMEOUT waiting for Ack block #26949 [29/04 22:23:06.985]
Connection received from 192.168.0.86 on port 2984 [29/04 22:28:37.828]
Read request for file <ArcherC7v4_tp_recovery.bin>. Mode octet [29/04 22:28:37.828]
OACK: <timeout=5,> [29/04 22:28:37.828]
Using local port 57503 [29/04 22:28:37.828]
<ArcherC7v4_tp_recovery.bin>: sent 29308 blks, 15005422 bytes in 10 s. 0 blk resent [29/04 22:28:47.795]
Connection received from 192.168.0.86 on port 3027 [29/04 22:30:43.469]
Read request for file <ArcherC7v4_tp_recovery.bin>. Mode octet [29/04 22:30:43.469]
OACK: <timeout=5,> [29/04 22:30:43.469]
Using local port 57504 [29/04 22:30:43.469]
TIMEOUT waiting for Ack block #29192 [29/04 22:32:28.594]
Connection received from 192.168.0.86 on port 3688 [29/04 22:34:46.063]
Read request for file <ArcherC7v4_tp_recovery.bin>. Mode octet [29/04 22:34:46.063]
OACK: <timeout=5,> [29/04 22:34:46.063]
Using local port 57505 [29/04 22:34:46.063]
<ArcherC7v4_tp_recovery.bin>: sent 29308 blks, 15005422 bytes in 9 s. 0 blk resent [29/04 22:34:55.967]
Connection received from 192.168.0.86 on port 2979 [29/04 22:38:10.297]
Read request for file <ArcherC7v4_tp_recovery.bin>. Mode octet [29/04 22:38:10.297]
OACK: <timeout=5,> [29/04 22:38:10.297]
Using local port 57506 [29/04 22:38:10.297]
TIMEOUT waiting for Ack block #29128 [29/04 22:39:55.495]
Connection received from 192.168.0.86 on port 2541 [29/04 22:40:44.994]
Read request for file <ArcherC7v4_tp_recovery.bin>. Mode octet [29/04 22:40:44.994]
OACK: <timeout=5,> [29/04 22:40:44.994]
Using local port 57507 [29/04 22:40:44.994]
TIMEOUT waiting for Ack block #25806 [29/04 22:42:30.229]
Connection received from 192.168.0.86 on port 3644 [29/04 22:42:57.713]
Read request for file <ArcherC7v4_tp_recovery.bin>. Mode octet [29/04 22:42:57.713]
OACK: <timeout=5,> [29/04 22:42:57.713]
Using local port 57508 [29/04 22:42:57.729]
<ArcherC7v4_tp_recovery.bin>: sent 28912 blks, 14802874 bytes in 10 s. 0 blk resent [29/04 22:43:07.539]


I hope that I have helped in some way and contributed a little with the community. Once again, thank you all very much.
Any doubt let me know

_________________
-
1x tplink 1043nd v2
3x tplink wdr4300 v2
1x tplink Archerc7 v4
Client Bridge, WDS, Repeater, AP, Router.
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 14125
Location: Texas, USA

PostPosted: Fri May 01, 2020 1:16    Post subject: Reply with quote
Ok, so was it user error or absolutely having to have windows and a 32-bit version of tftpd? Looks like it was mostly user error to me... that was solved by using windows and a 32-bit version of tftpd. Glad you got it sorted out, though. That how-to you used is pretty much the same how-to that videobruce posted, though...
_________________
"Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT
Pogo - A minimal level of ability is expected and needed...
DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)

----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Nanganator
DD-WRT Novice


Joined: 09 Dec 2019
Posts: 2

PostPosted: Fri May 01, 2020 10:53    Post subject: Reply with quote
I dare say there is a far easier way to resolve this. Set your tftp anticipation window to 1024 when returning to stock firmware. The default window is too small to send all the data in time.
kernel-panic69
DD-WRT Guru


Joined: 08 May 2018
Posts: 14125
Location: Texas, USA

PostPosted: Fri May 01, 2020 16:16    Post subject: Reply with quote
Nanganator wrote:
I dare say there is a far easier way to resolve this. Set your tftp anticipation window to 1024 when returning to stock firmware. The default window is too small to send all the data in time.


Incomplete suggestions without specific details as to where to do this may not be as helpful as intended.

_________________
"Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT
Pogo - A minimal level of ability is expected and needed...
DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)

----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Goto page Previous  1, 2, 3  Next Display posts from previous:    Page 2 of 3
Post new topic   Reply to topic    DD-WRT Forum Index -> Atheros WiSOC based Hardware All times are GMT

Navigation

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum