Hey guys. I have a couple of old OpenWrt routers lying around that I'd like to make useful again. I have a TP-Link TL-WR841n v11 and a TP-Link TL-WR842N v3. The older WR841n v11 is currently running OpenWrt 18.06.6 and the 842n v3 is running stock firmware at the moment. My question is this - what sort of setup is most likely to allow me to extract the full speed of these aging devices for Wi-Fi bridge purposes? I have a couple of dwellings around 20m apart that I would like to reliably extend the network to whilst achieving at least 50mbit - it is a semi-rural area so 2.4Ghz interference is not an issue and I can use 40Mhz channels.
I've had poor experiences using RelayD due to DHCP screwing up, WDS is better but seems to lack some protocol support (e.g. IPv6) and still doesn't seem to be that reliable. 802.11s has worked well for me in the past, but I don't think that will run on the older version of OpenWrt. There is also batman-adv but I have no experience with that. Is there another firmware I could install on my 841n that might work well? Or something else? Curious what protocols / setup people suggest. Thanks in advance!
This device needs to be retired. The last fully supported build for that device is indeed what you're running (18.06) but that has been EOL and unsupported for half a decade. That means that there are many serious security vulnerabilities that have been discovered over that time and it is no longer safe to use this device.
This one can actually run OpenWrt 24.10. I'd recommend that you use this and not the stock firmware since the vendor firmware hasn't been updated in even longer than the half decade since your WR841 was.
I would expect that the most you'll get out of the 842 is probably around 50Mbps (maybe a bit more) in real-world/real-data bandwidth, but sounds like that is sufficient for your needs. I don't know that it will be able to achieve that bandwidth over the 20m distance, though. You'll need to test. It'll very much depend on the environmental conditions (are we talking true line of sight, among many other things).
Not surprising. relayd is a bit of a hack and not really ideal for much. It's a method of last resort.
It should be generally pretty reliable and I think that IPv6 should pass transparently. The key is to have WDS running on the same firmware ecosystem (i.e. OpenWrt) on both sides. There is a bandwidth penalty of ~50%, though, when you are talking about running in WDS mode with a single radio.
Not possible on the 841 (which you need to e-cycle anyway). The 842 might be able to do it, but it won't be a good experience.
Don't bother with these old devices.. You can get 802.11ac (wifi 5) and even wifi 6 stuff dirt cheap and it will have much better performance in general. Get one that runs OpenWrt and that has 2 or 3 radios in it and you can setup a nice 802.11s mesh system.
Can you elaborate on the security risks? This device isn't going to be doing routing, accessing the internet or anything like that. Just bridging, and it won't be broadcasting an AP (I have an old ISP modem I am going to use as an AP). I could go further and VLAN it off if needed. I'd rather use what I have - I also have a v10 and v9 unit as well.
You are looking at eight years of accumulated security issues, including local- and wireless (driver/ stack) ones, plenty to choose from - and there were quite a few high-profile ones within that time frame.
Could anyone who shits themself over theoretical life threatening security hole please point at least some of them....
Because what the fukk should happen with an dumb ap where ssh is only exposed to trusted lan? Please educate me.
And still in every thread when this is mentioned not a single issue is specifically pointed out how the elite hackers from your neighborhood should p0wn you ...
Yeah maybe someone could crack your wpa2 but this is an issue since all these years.
So what is exactly the issue with an old Kernel and hostapd where nothing else is running.... I'm really curious about the real world relevance and impact.
hostapd/ wpa_supplicant has, on average, 1-2 security issues per year, then there are things like KRACK (wireless stack and -drivers; not limited to that specific issue, there were more), but the buck doesn't stop there (musl, busybox, kernel, …). Taking care of getting fixes like these shipped quickly has been part of my life in another venue for quite a while, so I am very well aware of the issues as well as qualifying their actual impact. What I am not good at, is putting dates on particular issues - I care about getting things fixed, not to write essays or timelines about them. So no, I'm not going to write up a detailed list for you.
Security fixes are not optional, even if one issue might be hard to exploit, a combination of two- or more orthogonal issues can burn down your castle much easier, and this does happen, regularly. "I have nothing to hide" or "who'd care about my little router" are not valid argument, botnets ('commercial' criminals/ organized crime or state actors) thrive from having access to diverse to hide their tracks, to get you into trouble and not themselves. If you can't run a current -security supported- version of OpenWrt, you better don't run it at all - if you want to get hacked, I for one prefer you blaming them OEM, rather than OpenWrt (it's all your own fault anyways, if you don't stay updated, but the finer details are usually lost in translation).
Security is a fluid situation, in any non-trivial environment there will always be security issue, the question is how you deal with them. And the known exploits are quickly taken up by the criminals and mere script-kiddies of the internet at large. So once a bug/ fix is known, it will be exploited at large, so you better keep up with fixing it quickly.
I can agree with your overall statement but as I see the list of hostapd for the last 6 years. Not a single issue is relavant in the god damn simple home usage ap mode.
To hack the Kernel you have to be on the device first. If the 8 year old dump ap does only speak ssh then dropbear needs an pretty good vuln... My point is, yes updates are imported but you have to consider the environment too.
And in your small town most likely the Mossad gives a shit about you and if not you know about it I would assume...
I would like to see a simple but critical exploit path for these kinds of unpatched AP let's say 6 years old.
No theoretical a Korean teen group could do a bot net. Dump AP with ssh on local lan. No radius. Simple wpa2... How large is my attack vector?
Again, I don't disagree with your attitude or would down speak your work and skills but I don't get the point in these discussions because mostly there are really special vuln which are not relavant in many simple deployments....
Beyond what @slh discussed on the security front, there is one other really important consideration with EOL/unsupported devices... syntax for the configs.
Specifically, a lot has changed in the 5 major revisions of OpenWrt since 18.06 was released. The config files are not compatible as a function of the continual evolution of the platform. Therefore, anyone trying to use older versions will be largely on their own for configurations and the like. I would guess that very few forum contributors actually remember the day-to-day configuration syntax for such old versions and the nuances of how things work. And attempting to use the modern syntax on older versions will likely cause major issues.
I think a plain dumb AP is realistic to achieve. For everything else more complex for sure that would be pain. I would like to not wake up one morning in such a kafkaesq situation and been forced to debug such an old environment....
As much as I appreciate the discussion about security on 18.06, that's not the focus here. It doesn't have to run that firmware. It won't even be powered on 24-7, only when needed. I can also see that tiny versions of 21.02.x Openwrt builds with backports are available. OpenWrt 21.02.x ath79 tiny LuCI
If we could get back to the core part of my query, that would be appreciated.
alternatively, you could run the TP-Link stock firmware for both end-points, since these are not going to be facing the internet, the risk is relatively low, all told... it's been a while since I've looked at their stock firmware, but last recollection is that they are fairly complete, and should be able to do what you want with little trouble.
The biggest thing outside of security with 18.06 is that it's really old, and a lot of the plumbing has changed, so it could be hard to sort issues here, as the community has moved on...
The stock firmware does not have WDS or 802.1s mesh so that's not really an option. I don't want a repeater, just a Wi-Fi bridge, repeaters have awful performance.
Have you tried to compile your own firmware?
Iirc the 841 has only 8 MB flash, correct?
There are some guides how to remove various features on the build target to shrink the image size.
Luci is an obvious one. Pppoe too.
And if 23.x is still to large I would try 21.x...