Do you know if it's possible to add the compatibility in TPLink Archer Ax6000 V1?
Please continue to read more about OpenWrt on Broadcom devices like TP-Link Archer AX6000 v1 here:
1 Like
Hello,
Totolink X5000R, Installation 22.03.5,not possible with LuCI Attendedsysupgrade.
Downloading Firmware from server to browser, but installing browser to router does not work. The router does not receive any information, the lights do not flash.
Firmware download, SHA-256 verification.
On installation, without keeping the configuration, display of the red banner, I checked "Force installation if verification of the image is compliant". The lights are flashing. After installation, I no longer have access to LuCI.
Installing luci-ssl with PuTTy, I found that version 22.03.5 was installed.
With LuCI, I restored my configuration. X500R is operational.
Apart from this little incident, thank you for the wonderful work you are doing.
Have a nice day
TP-LINK Archer C2600 v1 (which still shows links to 22.03.3) and two Archer A7s updated using Luci from 22.03.3 with settings kept, missing packages installed and devices rebooted.
So far all appears to be working normally.
Thanks again to all who do the work to make this not just possible, but easy.
Been using sysupgrade for upgrading Sitecom WLR-7100, WLR-8100 (v1 and v2) from 22.03.4 to 22.03.5 with settings preserved.
So far no issues (four days running). Thanks for the continued support of these Sitecom devices!
There are bugs with the switch acting like a hub on a bunch of devices including many of the Linksys WRT devices that are fine with the 5.15 kernel in the snapshots and the upcoming 23.x, but the 5.10 kernel in the 22.3.x releases had a bug that nobody has fully gotten to the bottom of yet and from what I've read as 5.15 kernels are known to fix it and are about ready to go live soon in 23.x nobody is willing to put in massive effort to fix something that week be fixed very soon (next month probably) by the next major release.
3 Likes
Installed on a Netgear WNDR3700 v4 and Linksys E8450 (UBI) with both configured as dumb AP's. It works flawlessly at boot and for a few days. After that an android phone gets stuck at the "obtaining IP address" phase of connecting to the netgear. Since the netgear router is just a dumb AP it requires a network connection back to the main router, which didn't happen. Unfortunately the netgear router was needed so I didn't have time to investigate more. The fact that it only happened on the netgear and not the identically configured linksys made me wonder if I should have quickly checked the memory used. The netgear has a lot less than the linksys and any leak would show up there first.
2 Likes
While this is true there is a bug with the snapshot builds where software flow offload in firewall (an experimental feature) is broken on mevbu systems. Make sure that option isn't checked and the snapshot will work fine.
2 Likes
Good to know. Thanks to all our devs who are doing amazing work! 
Some update for DIR-885L HW A1: I have switched to this FW Version: 10.10.122.45 CRC: 964bc676 Date: Wed 2017-05-31
md5sum ./brcmfmac4366b-pcie.bin 92d1baab27d88b3ff1c9b9a39c33b0b4
from here:
and it looks pretty stable and better than any one from Openwrt repos.
1 Like
Your dir-885 custom firmware engagement is awesome.
But if you are interested in maintaining currated news about custom builds of the dir-885, my recommendation would be, you open up a new dedicated thread e.g. „dir-885 custom builds“ in the community builds section of the forum.
That would give such dir-885 custom firmware news some needed structure instead of occasional „look here, I found something new“ shotgun postings in various threads. Users are aware to search for a device via Google, Wiki or forum search and would eventually find such a thread, in case you are worrying that people might miss your news.
2 Likes
The same problem happens to me about "obtaining IP address" and the culprit is dnsmasq, but I solved it by replacing dnsmasq with odhcpd + Unbound on the main router (no dumb AP) following the steps in this guide:
2 Likes
well for dumb ap you do not need any of that.
1 Like
Familiar issue to me. It looks like the problem is still present in 22.03.5.
For me, the problem has been around in several releases so far.
it occurs kind of random to me, sometimes weeks, sometimes months without issues. And then suddenly some kind of DHCP resource seems to deplete and devices which still have a valid lease will still work, while all devices that reconnect from then on seem offline, as if they do not get an IP via DHCP. my workaround so far: reboot main router.
Found other people with older similar sounding posts outside of OpenWRT:
https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg15776.html
1 Like
Or restart the "dnsmasq" service, but the problem will occur again later.
Maybe try DNSMasq 2.89 from snapshot in 22.03.5 release. I've been running it since it came out without issue.
I was hoping it would get backported but it didn't.
1 Like
I flash OpenWrt Snapshot on the main router (no dumb AP) and I haven't had the problem.
- dnsmasq v2.86 from OpenWrt 22.03.5 is broken and "obtaining IP address" problem happens.
- dnsmasq v2.89 from OpenWrt Snapshot the problem is fixed.
If you are using OpenWrt 22.03.5, I recommend that you replace dnsmasq with odhcpd + Unbound on the main router or flash OpenWrt Snapshot on the main router if you don't want to replace dnsmasq.
@account4538 Thank you very much for the solution and I hope that the developers update dnsmasq to version 2.89 (2023-02-04) in the next OpenWrt 22.03.6 service release, because this is a big problem and if OpenWrt stable continues using older dnsmasq version 2.86 (2021-09-08) people will have the same problem mentioned above and they will think that it is the fault of the router model or dumb AP or WLAN drivers, when the culprit is dnsmasq.
4 Likes
Hoping for the best, but I don’t see any clue in the 2.87-2.89 changelog about such a bug being fixed:
https://thekelleys.org.uk/dnsmasq/CHANGELOG
I've since realized that it isn't just limited to clients not getting an IP address but the local ntp program on the WNDR3700 v4 not keeping the time updated. In 5 days updtime it lost 5 hours. Clicking "restart" on ntpd in luci did resync the time.
This time I did explore a bit and it did show plenty of memory. I haven't rebooted so if anyone has ideas of what I should check, I'm all ears.
root@ap:~# cat /proc/meminfo
MemTotal: 121748 kB
MemFree: 79828 kB
MemAvailable: 62516 kB
Buffers: 0 kB
Cached: 11704 kB
SwapCached: 0 kB
Active: 8872 kB
Inactive: 6148 kB
Active(anon): 264 kB
Inactive(anon): 3272 kB
Active(file): 8608 kB
Inactive(file): 2876 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 0 kB
Writeback: 0 kB
AnonPages: 3324 kB
Mapped: 3888 kB
Shmem: 228 kB
KReclaimable: 3040 kB
Slab: 9828 kB
SReclaimable: 3040 kB
SUnreclaim: 6788 kB
KernelStack: 368 kB
PageTables: 372 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 60872 kB
Committed_AS: 12264 kB
VmallocTotal: 1048372 kB
VmallocUsed: 2996 kB
VmallocChunk: 0 kB
Percpu: 96 kB
True, after 5 days working, my dhcp stopped working. I had to reboot the router to make it work again.
Should be great to have 22.03.6 fixing it.
1 Like