@jschwart I installed your image on a fresh v6, it flashed and booted properly. 5 GHz seems to work as well (61 Mbps up, 43 Mbps down over WLAN over my 250/50 line).
One odd thing though, maybe it was just a fluke(?): I installed luci and then configured wifi over it. After setting WPA3 and a password and applying the changes, the router crashed and I had to restart it manually. WiFi 5 GHz was enabled after that as requested in luci. But could not reproduce the problem.
EDIT.: The crash occurs when enabling the 5 GHz WiFi in LuCI. A manual reboot of the device is necessary.
That's great news!! So it seems we have one known issue, but with a known workaround! Be sure to keep us informed if you run into more issues and whether things are stable further one.
@remgodow@Renaud11232 would one of you like to have the honour of creating a PR to master or shall I do it?
I just updated the commit description to comply with the submitting requirements and rebased again against master. Could you check? I mostly copied the text from the v4 commit:
Hi @ashipaek0 welcome to the forum and great you're looking at testing along!!
The above page works, but you do need to have IPv6 connectivity (I can't easily assign spare IPv4 addresses to my servers unfortunately).
I did another rebase against OpenWRT master and provided a new image on the site linked above. I also put a copy here in any you cannot access my webserver: https://liv.nl.tab.digital/s/wYsTQwpbwRYMa9S
Anybody who's testing, please let me know if I can include your name & e-mail address in a Tested-by header for the commit.
Thank you very much.
got some errors installing luci
Configuring luci-light.
Configuring luci.
Collected errors:
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.132-1-993c4b695a7624047a1e8e8d6bad2b25) for kmod-nf-ipt
* pkg_hash_fetch_best_installation_candidate: Packages for kmod-nf-ipt found, but incompatible with the architectures configured
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.132-1-993c4b695a7624047a1e8e8d6bad2b25) for kmod-ipt-core
* pkg_hash_fetch_best_installation_candidate: Packages for kmod-ipt-core found, but incompatible with the architectures configured
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.132-1-993c4b695a7624047a1e8e8d6bad2b25) for kmod-ipt-conntrack
* pkg_hash_fetch_best_installation_candidate: Packages for kmod-ipt-conntrack found, but incompatible with the architectures configured
* pkg_hash_check_unresolved: cannot find dependency kernel (= 5.15.132-1-993c4b695a7624047a1e8e8d6bad2b25) for kmod-ipt-nat
* pkg_hash_fetch_best_installation_candidate: Packages for kmod-ipt-nat found, but incompatible with the architectures configured
In my experience installing packages with custom builds is always tricky. This should be easier once we have the PR merged and the device is officially supported.
Most likely you did. What you are actually missing according to the error messages are certain module packages that are specific to the kernel of this image.
There are two ways. One variant is to wait for official support. For this we need to get the PR merged and wait for an official release that includes the commit with device support. For this any testing and findings you have with the current image (without extra software) is really useful.
Your other option would be to build your own image. Then you can just incorporate WireGuard as part of the build process.
I'm not sure that will help much. Each issue you will run into might require another build. It should not be that hard to do a build yourself. You may ask questions if you run into problems with that. If you really feel that is not your cup of tea, it would be more prudent if you could test the generic functionality as much as possible. then we can merge this more quickly. Maybe you can also help with the questions below (mainly what kind of marking your box has).
Comparing the three different patches, I'm finding some differences we might need to address:
The v4 DTS has this section too. The v6 manual shows there is no LED marked as WPS, so I think this section should not be present. Let it know if your box does have a WPS LED!
The second patch uses mac-address-increment = <2>; where the others use mac-address-increment = <(-1)>;. (The v4 DTS uses -1.) What is the difference?
The second patch also marks the model as EU specifically, but they other patches have no such suffix. There seem to be at least an EU and RU model as can be seen here:
They are supposedly not compatible with each other's stock firmware:
(translated) We draw your attention to the fact that updating the software from the Russian version (RU) is possible only to the Russian version (RU => RU), and from the European version (EU) only to the European version (EU => EU). It is IMPOSSIBLE to change the Software from the Russian version to the European version or vice versa!!! RU ≠> EU; EU ≠> RU!
On what kind of boxes have you been testing? Are they marked explicitly as either EU or RU? The GPL code release for each of them points to the same file. There is a REGION=EU argument specified on the command-line for the build, but there are also only EU files included. I suspect that while these packages seem incomplete, the hardware is actually the same and one could switch to the other stock firmware with the right tricks.
There are differences in the HWID, HWRED and HWREVADD, the first patch uses:
The second set seems to match with the v4 values.
Could anybody clarify on the difference? Maybe this also relates to people facing different boxes (EU/RU)?
Alright. Then I think the current LED part is correct. @ashipaek0 also thank you for confirming your model does not have a WPS LED!
Regarding the MAC address assignment I don't know. Let me know if you think that should be changed.
I took a look at the firmware provided for the ES version and at first glance it seemed quite mysterious. The EU and RU firmwares are mostly identical. Extracting them with 7zip also shows large amounts of files are identical. So I'm quite sure that the EU and RU versions are identical. As I was looking at the downloads for the ES version, I noticed the picture shown for this model is quite different and the filename suggest it's a picture of the Archer C54. Checking it out its firmware also reveals that it is more or less similar. I found a topic here: Support for TP-Link Archer C54 v1 - #5
@jimuazu, @tp-linkuser I am afraid you are actually looking at an Archer C54 which is sold there as the Archer C50 v6. Could you confirm that your device is black? Similar to the one in the picture:
The device that we are looking at for the EU and RU variants is white/gray/silver colored. Maybe it would be good to enhance the PR to elaborate on which models the resulting firmware will work?
This reads as if somebody is coercing you into doing this! I certainly hope that is not the case! Don't worry I'm sure you'll get everything going with enough persistence! Maybe you could describe a bit what steps you took. Did you try building an image without any modifications as a first step?
happy to report i have successfully built the firmware with wireguard
i think the memory on the router was the reason for the builds failing before now
as you can see the free space is literally kilobytes......
i have also deployed wireguard successfully, but i'm unsure if the intermittent issues i'm having with it is due to my configuration or something else
