Sorry, it looks like your device was not ported from ar71xx target to ath79 and the SOC differs from v1. The latest compatible version is OpenWRT 18.06.9 and that will probably be the end of it.
Out of curiosity did you try your tricks on 22.03?
I did try and I failed.
Latest 22.03 branch uses nftables instead of iptables. Even when I removed most things, that could be missed, I'm about 316 kB short of compressed image space. I'm sorry to say it, but those 4MB devices will have to stay on OpenWRT 19 or 21.
3 Likes
@Jack007 Try my build for your device as target ar71xx from here.
Updated 2 devices and they work as expected.
Many thanks.
1 Like
This is just brainstorming, and somebody probably already thought of this, but perhaps experimenting with DwarFS as it seems capable of getting smaller sizes than squashfs+xz when used at higher compression levels, though it might have issues running in embedded environments, but it might just be good as a test if under ideal conditions, things could get smaller. Also their readme is a wealth of comparisons with different compressed filesystems and parameters.
Also for squashfs there is (-b) and other parameters in the mksquashfs step which I believe is either common-netgear.mk or image-commands.mk or using an out of tree state of the art version from plougher/squashfs-tools if it is not the same, and try zstd, xz, etc as they are supported by the kernel 4.14.
I believe xz has filters for text and for executables so it can be tuned towards such, but no idea if they are applicable to MIPS or if that functionality is accessible by the mksquashfs command, if it is, then sorting the files based on text/executable might gain a few more kilobytes as well.
Lastly upx, the ultimate packer for executables has a mips stub, if it works it would probably compress executable better than any squash/dwarf/etc filesystem could as it is highly tuned. for best compression results try 'upx --brute program'. , this approach might lend dozens or hundreds of kilobytes if successful. There are some issues tickets involving compressing .so files with the devel branch and maybe other things, so might have to use a stable or older version.
Maybe one of the ideas above can shave off the difference. Though if even something heavyweight like DwarfFS can't do it, then it is likely the other filesystems meant for embedded stuff would be unable to and if upx doesn't bail things out is gameover, unless there is some yet again experimental compressed filesystem out there that is better. But if it does work, then I'd imagine the next step is to see if it can be decompressed with 16mb of ram and that the kernel flag/patches for the algorithm is enabled.
1 Like
I'm also looking for an openwrt version for the TP-Link TL-WR941ND v5 and TP-Link TL-WR840N v2.
Is there any change for this device?.
There are builds for both of them as ar71xx target. Sadly 19.07 was the last branch of OpenWRT ar71xx was compatible with.
What would your estimate of the difference between the versions for such a device would be? As of ‘the 19th one would be better for this use-case and the 21st one is for that use-case’.
I cannot understand whether 19 is much better than 18, and 21 is much better than 19. Considering it’s an old device anyway. Specifically my one is TP-Link TL-WR-841N v9.2.
Does anyone know whether I can use this router with this OpenWrt version as an extender for mesh-network? I cannot understand whether I need to have some extra hardware, or it’s purely a software thing.
Excuse me if my question is off-topic, please.
Essentially, you want to have a set minimum speed for all network members (APs), because having mesh network means you lose control over what AP you connect to and that is up to your device to decide.
You can have a bunch of OpenWRT APs connected with wires and configured exactly the same with 802.11r (fast transition) and what you get is a mesh network. Even these old devices could be used for that, but I'd prefer something with 802.11ac or faster.
If you want to mix it with brand mesh solutions, you'd end up with a headache full of problems: https://ashus.ashus.net/thread-188.html
So you might end up flashing everything possible to OpenWRT as I have.
1 Like
hi @Ashus as you probably noticed I'm trying to replicate your ath79 config to rt305x (mediatek/ramips target) but my main test user @MangoMan needs imagebuilder for his advanced setup.
Did you managed to compile a successful imagebuilder for ath79?
thanks
No, sorry, I only ever used direct building in console of virtual machine, I never tried imagebuilder. If you need it, you'd have to make it compatible yourself. I can't confirm it would still fit into 4MB ROMs.
1 Like
Thank you for your clarification!
What about just a dumb Wi-Fi repeater? Will it work well? I mean in the context of its hardware. Is it too slow for such a job?
I have this router working as an Access Point. I connected it to my main router (non-OpenWrt yet) with a cable, and it looks like it works perfectly well. It shares the same name with the primary router and all the connections look smooth to me. It is flashed with your 21.02.3 firmware. It works for a month or something. Noticed no issues within this time.
I have one more router lying around collecting dust, as I cannot lie a cable where I want it. I realized I can use it as a Wi-Fi repeater (without a cable). Or does it take much more load that way?
I’m aware the speed would be halved, it’s fine for my scenario, as I expect it to just cover some areas where there is no signal at all.
Dumb wi-fi repeater is something I would avoid as the speeds are much lower because of interference. Usually there is one radio, so if uplink is also wireless, any traffic sent from your phone to AP is resent on the same channel. In mesh setup you have no control over what AP you connect to, so your overall experience will drop rapidly. Use repeaters with separate SSIDs only (as extenders) or not at all.
Please note it is not enough to use the same SSID/passphrase/security. To really have mesh, transitions of devices between APs should be seamless and all open connections should be kept intact on roaming. That can be achieved by using 802.11r fast transition and configuring it. Older firmware OpenWRT 19.07.10 I have compiled for many devices can do just that. Package wpad-mini is not able to do this, but package wpad-basic is. In this setup, you need to have all devices on OpenWRT or you will have problems as I had. To test this seamless roaming, you can use Wifiman App (can be found on Google Play store).
Configuring a regular router with OpenWRT as repeater with wifi uplink can be done, but you would probably end up with creating another subnet. That is also wrong with mesh setup. To use the same subnet as uplink has, you would also need to use relayd configuration (relayd package is also in my 19.07.10 builds). That alone has some performance impact, so again, use separate SSIDs.
I recommend buying several Xiaomi Router 4A Gigabit, flashing them with OpenWRT (kinda tricky for the first time) and joining them with a smart gigabit switch with VLAN support. One of the devices could act as router, as they are both powerful and cheap. Then you can easily set up two networks with mesh: your private and a guest network (only internet access, but blocked local resources). If all is metallic, speeds are limited only by wifi 802.11ac standard (~60MB/s).
This could be your target if you can't afford to buy it all at once. You could slowly improve wifi range by moving devices to better spots or buying more and throwing the old ones away.
1 Like
@Ashus how to flash this build via web interface in my tp link mr3420 v2 router. I am on tp link official firmware now. And I have searched the forum too, the install image link of my router is dead now.
Flashed 3420v2 install image file. Wifi bandwidth can not be set to 40 MHz. Set in settings but analyzer shows 20 MHz only
Most likely you need to try the switch Force 40MHz bandwidth and/or you need to change the channel, not all of them support wider bandwidth.
How to force, kindly tell me
