OpenWRT 19.07.7 compiled.
Download location is almost the same - just another directory.
Looks like this time it's again mostly security patches.
Also I managed to fit in wpad-basic per @zen1932 's request. Could you please test 802.11r?
4 Likes
woah, I can't wait to test it with my wr841nv7, and it works for 802.11r !!!
many thanks, these tiny devices can now be resuscitated.
Hi. Thanks for the images!
I've been using this image since Dec. 2020 on two WR841 v11. I'm not sure which version I started with but probably the 19.07.4, and I only updated once to OpenWrt 19.07.5 r11257-5090152ae3 in January 2021.
I'm asking for help on debugging the wireless performance on these.
The problem: after a while of being turned on, the wireless is completely broken but it's still broadcasting the SSD. If I try to connect to it, I can't even get an IP address from the dhcp and the connection is closed (android). The wired internet is still working. A reboot appears to be required to restore the wireless.
The version I tried in December, had this behavior very frequently - on the first 30 min to 2 hours of being powered on. This last version was holding fine for some weeks and then failed. I rebooted them yesterday and today they are again with no wireless connectivity.
Some highlights on config I have:
- one gets internet from ISP through DHCP, provides the internal networks, dhcp server, firewall, etc, the other one is a dumb AP;
- the dumb AP has most of unnecessary servicies disabled;
- two networks on two vlans (lan and guest);
- two SSIDs for the two vlans;
- both are broadcasting the same SSIDs, same wifi configs at different channels;
- most known devices (mobiles, laptops, etc.) have a fixed IP on the router.
This problem happens at least on the dumb AP - I just rebooted that one and I got the wireless back.
I just have no idea where to start looking. I'm comfortable with linux (I only use linux) but my network skills are very limited.
I think I was affected by this [TL-WR841N v8 ath79 Link Unstable - #9 by leeandy] because on dmesg I saw something like this:
[ 8829.952701] eth1: link up (10Mbps/Half duplex)
However this also affected the wired network and now only wifi is affected.
I just noticed the main router might rebooted itself 3d ago.
Current dmesg look great on both and RAM usage is at 85% for the main router (no wifi clients) and 90% for the dumb AP (3 wifi clients).
I'm holding the update to 19.07.7 for some days in case you want me to check something on this version.
Any thoughts?
Thank you!
First I'd looks into logs. Personally I have found some permission denied messages after upgrade and when I removed the files and restarted affected services, it worked well. You can also compare running services on routers using ps command.
Of course I can't guarantee the bug Link unstable hasn't come back, but it is unlikely. Some of the outages you had are most likely not related.
1 Like
I see image for tl-wa701nd-v1 but not for tl-wa701nd-v2 - same Flash&RAM
Is there a reason for that?
From what I could find, tl-wa701nd-v2 was not migrated from ar71xx architecture to ath79.
My bad. Thank you!
Will it be possible to host another build with wireguard while without luci ?
OpenWRT 19.07.7 without LuCI with Wireguard compiled.
https://openwrt.ashus.net/ 19.07.7-targets-ath79-tiny-wireguard
You may try it, but it has not been tested at all. All tiny devices I had are now in production use or replaced. Please report back whether it works, maybe you could tell the others highest transmission (upload) rate your device has CPU power for.
3 Likes
Thank you very much!
Sure will try and report back here.
Im going to try the wa901nd v5 firmware, and then report if its good, i intend to use it in client mode.
A question that i havent seen answered here is, if someone wants to flash the original firmware from Openwrt-Luci, how is it achieved, does anyone have a special firmware for this purpose.
Thank you.
That is because it is beyond scope of this topic. There is a generic guide, but it may not work for every device as you may be required to trim the binary stock firmware before flashing.
Usually the specifics are on device info wiki page:
Finally if you use Google, you can find out, that someone recently needed to do this and even made the modified stock firmware available:
Thank you for the reply.
I already read some of that information, flashing with WinSCP, still no one has confirmed if its ok or not.
Btw, there is a new oficial firmware from tp-link on their site, after 4 years they decided to update the firmware.
I prefer using wget as usually you can't use WinSCP to get into OpenWRT right away (sftp incompatiblity).
Sorry, but I don't trust official firmwares. I have several TL-WA7510Nv1 outdoor APs in my network and their firmware is so old (2013) it doesn't even pass through important IPv6 neighbor solicitation ICMP packets. I guess new firmware after such long time is good news, but offical ROMs are good for one thing only - speed optimalization. For security and everything else there is OpenWRT. Sadly most manufacturers abandon their product support in under 2 years.
In WinSCP you can change protocol to "SCP" from "SFTP"
1 Like
Do i understand correctly that the image posted in the OP can be used for TP-link TL-WR841N/D?
And where can I find flashing process explained? I'm currently running native/stock firmware from dlink?
IME there are several ways of decreasing ease to try and get back to OEM firmware:
- LUCI GUI
- SSH to the device and see if you can force the image via sysupgrade
- "Magic" button or timing with stock boot that will get device to look for image on TFTP if you have it up and running
- Serial port to interrupt bootloader, and use the limited command line interface to TFTP image
Does this mean patches for master, or previous releases? I currently have local patches / stashes for the 4+32 devices I use as extenders. I'd be very happy to push patches for them on ar71xx and ath79 so I don't have to keep those so much myself, and others can build the locally for their own use.
Yes, TL-WR841N/ND revisions 5,7,8,9,10,11,12. You should use images marked factory for flashing from stock.
1 Like
Past releases (19.07.x, 18.06.x, 17.01.x) are done and dusted, neither of them will accept new device additions (and 18.06.x, 17.01.x are out of support, not accepting any changes at all). Once a release has been made (after e.g. 19.07.0 or 21.02.0), only bug- and security fixes are accepted, new devices or features have to be merged to master and wait there for the next release branch.
1 Like