Mi Stock Recovery V2.0.1 .zip

0 views

Skip to first unread message

Brian Bezdicek

unread,

Aug 3, 2024, 4:59:19 PM8/3/24

to enerilpur

Here's my problem : i just bought the Archer C6 Tp Link router (V2).
I want Open WRT on it for experience and DHCP connection (my ISP is Orange Telecom)
I follow this link : -link/tp-link_archer_c6_v2_eu
I download the openwrt factory firmware et sysupgrade firmware : both of them don't work with web gui. I have error message : "Invalid file type"

I launch tftpd64, i verify directory, i choose correct server interface.
I push the reset button(with a pen), i power on router, i wait 5 secs...and nothing happened. The router boot normally but no tftp....nothing.

Notice : whe the router is powering on and the power led is up and after a few second down, the server interface in tftpd64 go to 127.0.0.1 (loopback). I don't know if there is a part of the probleme too.

I have a similar issue with this router : I cannot see any packets (ARP) from the router during the boot.
Strangely using my old eeepc 701 on debian 8, I managed to capture these ARP request each time !
I keep the reset button pressed until the WPS LED lights up then the router sent ARP request to find the host 192.168.0.66.

With my usual laptop (lenovo x230) on many debian versions (from 7 to 9) I wasn't able to catch any packets.
I tried to set the media speed to 10Mbits/s half duplex knowning eeepc has only a 100Mbits/s interface.
But nothing works as expected, I'm still investigating with others laptops/O.S

At this point, I can see that the bin file is being downloaded to the router (tcpdump shows tftp data & ack packets back and forth between router and tftp server), after the file is downloaded to the router though, it just boots back to the stock TP-Link firmware. It seems the downloaded file is being rejected by the router for some reason. I have tried the factory image, the upgrade image, as well as the initramfs image (all renamed to ArcherA6v2_tp_recovery.bin) and I get the same behavior with each. The router refuses to boot the tftp image and boots the stock firmware.

Likely the built images have region "EU" thus get rejected by your US version. Also if it's like the A7 the factory header is different but once running OpenWrt you can go to C firmware since the hardware is the same.

I have the same problem with an Archer C6 v2 EU tried a lot to get openwrt on there but i have no idea how to continue now. I tried with web but get invalid file type. I tried with tftp on mac and windows but both i don't see that they recieve any requests. Tried various times to hold the reset button but nothing. Any help would be really appreciated.
I have firmware version [Archer C6(EU)_V2_190115] atm.
In the notes tp-link mentions:
2. As we have added new functions in this version of firmware, once you have upgraded to this firmware, you will not be able to downgrade to the old one.

@zeldalink I've got the same firmware version before switching to openwrt.
You can try different Linux live CD and maybe you will be able to see these ARP packets.
Once you see them you can setup the TFTP server.
The recovery procedure :

It worked after some tries. what helped for me was the following:
Power up your router.
Press the reset button.
Press power button off and immediately on. (keep reset pressed)
When the WPS licht was on release the reset button.
I Had the router plugged in to my PC and had the script running you provided.
That solved my issue with not able to boot tftp.
I have no idee if the power on part was really needed but tried over 10 times without and that did not work.

I added a sub-interface (eth0.100) on a raspberry pi i had, and installed tftpd, xinetd, etc. I connected the archer c6 and the raspberry pi to a switch, placed the ports in the same vlan. During the boot process of the archer c6 i ran the following command in the raspberry pi (tftpd server) :

This will catch the control packet (file request) but then when the file transfer occurs it happens on alternate dynamic ports, so the above command won't see the file transfer itself. So we can just run :

The US A6v2 has a 16MB flash with a different partition layout. It's expected the OpenWrt binary to be rejected by the TFTP recovery, as the US unit is not in the supported list in the binary. Don't try to force it, as you might brick your device, and as you mentioned there's no serial console on the board, not event some TPs remotely close to something like uart interface. Adding support for the US A6v2 should not be a difficult task now when TP-Link published a firmware update binary for the A6v2(US).

Essential part here was the presence of intermediate device between the router and PC (switch, hub, another router) - otherwise, the PC might just not be in time to wake up it's Ethernet interface for pick up TFTP packets of the recovery sequence.

I've been trying to flash my C6 v2 (EU), but I can't seem to get the tftp method to work. I have a switch between C6 and the computer, IP set to 192.168.0.66 and tftpd64 running, but nothing happens when I hold down the reset button and power up the router - even if I capture with Wireshark, I can't see any packets on the interface.

while reading this thread today I had one or two ideas that you might find interesting (or maybe not). To cut short: I have not been playing the game for quite a while now so forgive me if am going to say something totally wrong, but IIRC when this mod is installed, failures are almost immediate. Indeed sudden and catastrophic failures are realistic in most situations, especially where rockets and big fuel masses are involved, yet I can imagine situations where a system starts malfunctioning before it fails. An engine for instance might start overheating and/or vibrating before it shuts down or explodes, a battery might start leaking liquid before it actually starts losing its charge, an electrical system might suffer electrical dispersion before it blows up, etc, etc. Moreover, some malfunctions might evolve in major failures, while others, like a loose electrical connection might cause certains parts to work intermittently.

I noticed an issue running KSP 1.8.1 and this newest version (2.0.0.1) on an existing save (along with Scrapyard, of course). With the newest version, the scene never loads. This error shows up in KSP.log:

If I roll back to Oh Scrap 1.7.1, everything is good to go. I have a saved KSP.log and mod list if that helps. I noticed I can get a scene to load from the tracking center, but then KSP slows to a crawl.

No need, I know what the issue is. It's trying to call some debug stuff that doesn't get compiled into the release version and falling over when it can't find it. I forgot that it doesn't compile that code in Release, I thought it just hid it. Sorry about that.

not sure what you mean... if *any* parts were recovered intact, they could make it back into the part pool, otherwise reliability would improve because newer versions of the parts would be built next time.

Every time a part gets built "new" -- it gets considered a newer "generation" of part --- so if you build the same craft five times in a row, the fifth craft will be "better" because of all the refining of part making and materials, or whatever version of improvement that the mod is simulating.

So, the overall rating of SRBs could be approximated to the rating of the least reliable SRB on the ship. But when an actual failure occurs, you can still roll on a weighted table to see which one actually fails.

I fly a complete SSTO mission from the runway, all the way to orbit, deploy the payload, land back at the runway... and get no generation increase. At first I thought it was KCT conflicting, with it's "recover to SPH" function, but specific testing by using only the stock recovery function gives the same behavior. I can't get it to reliably upgrade gens. Any chance you could define how/when the generation increase code is called @severedsolo? Would help with further troubleshooting.

Additionally, we've run into the old issue where Oh Scrap is spamming fail tests as fast as it can for a craft that spawns on the runway. Even at overall reliability 9, a craft sitting on the runway for about 60s had almost every non-reliability-10 part fail. Only way to mitigate is to spawn to the runway and immediately light a stage, which flips the fail check spam down to a more reasonable level.

Is there anything we can check there? Under what circumstances would the mod attempt to spam a check per second? It may be a conflict with World Stabilizer, which spawns the craft off the ground and "eases" it down... so perhaps the game is thinking a newly spawned craft starts at a state of flying and then becomes landed? Still not sure why a landed craft would spam a fail check per second, though...

Well the generation won't increase if you are fully recovering and re-using the parts. OhScrap stores the PartID and recalls it when the PartModule loads. It's a fairly complex bit of code but it starts here: - if the safety rate isn't changing that's a definite bug.