Is it possible to look into simplified alternative LuCI configuration that auto-configures repeater mode by scanning for an AP, setting up client/AP interfaces, and enabling WDS if selected, with minimal user input,checking each of the currently error prone intermediate steps like setting up relayd and verifying the situation.
Even with latest openwrt the slightest mistake takes hours of troubleshooting allegedly freshtomato and gargoyle would have it, could anyone look into it perhaps ?
1 Like
If you're able to contribute the code, that would go a long way.
To give some context for the challenges:
- there are lots of "repeater" type configs, starting with the distinction between ethernet connected bridged devices and wireless backhaul.
- With wireless backhaul, if the upstream device is not OpenWrt, it is likely that relayd will be required.
- If it is OpenWrt, WDS or 802.11s (mesh) can be used, but selecting the appropriate method is contextual within the specific environment and usage scenarios.
- With both WDS and 802.11s, there are things on both the upstream AP and the downstream devices, so now you have to communicate and coordinate changes between the two devices.
With that in mind, it's not a one-size-fits all type configuration and so creating a GUI is not easy. It would be great, though.... so if you have the ability to contribute, this would be worthwhile project.
1 Like
I hope the official openwrt maintainers might consider some sort of alternative gui guided procedure somehow, I haven't got a firm grasp of what it would entail, because I'm confused even by the different wiki possibilities client, wds client etc.
1 Like
I guess that's my point. 
The reason that the device manufacturers (with their own firmware ecosystems) can do this successfully is that they don't need to make any assumptions about the rest of the system, and they can write special code to make it work automagically.
Because OpenWrt supports hundreds of different devices and cannot assume that the rest of a user's network (specifically in this case, the upstream wifi AP) is actually an OpenWrt system, it would need to present all the possible options to the user. Maybe it could be guided in some way, but there's nuance in each situation that wouldn't be captured so it might be even more confusing to go through a 'wizard flow' that would need to ask lots of questions and gather a lot of info before it could do anything.
The other thing to consider is that for relayd and 802.11s/mesh, there are packages to install. Those take up valuable space and are not universally needed, so they wouldn't be included in the default firmware images. As a result, an automatic system would need to figure out how to get itself online, download and install packages, and then configure them appropriately -- this would be pretty tricky to design as an automatic/guided system where the existing network parameters are unknown.
Hopefully my bullet points above are helpful and provide the appropriate guidance about which path you might want to take. But, with that in mind, that is why the forum is here -- we can help you select the appropriate approach, point you to the documentation, and then guide you through it if you get stuck.
2 Likes
Kind of funny because you have a good point but you're also pointing to the problem 
The unfortunate side of openwrt is the fragmented hardware section. I wish the leaders and developers would have a standard for system requirements, aka OpenWRT One, develop a robust system and polished UI off of that platform and then let other people fork the branch. A good example could be set of what openwrt 'could be' but right now Openwrt is just a 'hackon' OS. Feels like we're still living in the early 2000s trying to get Openwrt on wrt54. Kind of sucks that the project hasn't moved on after 20 years.
And this isn't meant to be a a**hole comment either.
You can see examples from people like Alta lab, Glinet, Nethsecurity who have taken openwrt to its future potential by focusing on a good user experience.
By far the most limiting factor of openwrt is Luci.. your average person does not want to use it as it's overly complex and not polished and a terrible user experience compared to just about every other router minus Fire IP 
You should really strive for as much hardware diversity as you can get, keeps the hardware vendors honest.
Not too long ago, Atheros was without competition, see the path they've been taking for the last 10 years - and it's only slightly shifting now with ipqp957x. Apart from the cold hard fact that everyone (only) works on what they want to work on, you really do want options and alternatives; the more, the merrier. While it may be possible to discourage developers from working on $x, but that doesn't suddenly shift their efforts to $y instead, they might just grab a beer instead.
2 Likes
possibly linux (universal repeater mode ?), or RaspAP have some sort of device agnostic repeater strategy ? wds functionality should be standard, not device specific, idk
Why is this unfortunate? Sure, it does make the idea of a single-pane-of-glass controller harder (it is important to note that this is and was never a goal of the OpenWrt project itself), but it also gives people a very wide selection of hardware to fit their needs. Or, looking at it from another angle, it gives many people the opportunity to breathe new life into the hardware they already have.
Oh... and what's more....
Commercial products from different companies (and even sometimes from the same company) don't play together for things like WDS and mesh (802.11s) because they don't use the base standards (often to add 'magic' to their platform which can increase sales and lock out other vendors). So those TP-Link, Netgear, and Linksys devices you have in your basement can't participate in a a true mesh network/wireless backhaul.... until you install OpenWrt on each of those devices. Suddenly this is indeed possible since those disparate brands are now actually running the same platform.
In addition, they now have common UI. Yeah, not everything will be identical, but the platform similarity is sufficient such that any user who learns one will know their way around all of them. Think of the layout of controls in a car (headlights, wipers, etc.) -- when you rent a car and are in a brand you rarely ever drive (say you drive a Honda and rent a Ford), you find that everything is in different places and you have to figure it out as if it's all new to you. Contrast that with two models from the same manufacturer (a Honda Civic vs Honda Accord) where things are similar enough that it takes only seconds to get your bearings.
Believe it or not, the whole project started with one device -- the Linksys WRT54G. Device support was added for new products shortly thereafter and continuously over the two decades. Not sure why the hardware flexibility and choice is undesirable in your view.
Plenty do. And, in fact, the forks can span the spectrum of "quite similar" with a few tweaks to, in certain cases, extremely different from official OpenWrt, especially when a fork is developed to support hardware that is not available in the linux upstream. Forks are actually a mixed bag -- they enable lots of companies/groups/individuals to leverage the power of a small embedded linux platform that is extremely flexible and extensible but it can also cause confusion when people expect the official project to provide support for a commercial fork that is essentially a black box.
In what way do you not see the project having moved on? OpenWrt has continuously adopted and integrated the newest standards in networking from wifi to IPv6, firewalls, VPNs, and so on. It supports essentially everything that consumers want while also supporting very advanced networking that can power enterprises (OSPF, BGP, etc.).
They do so with funding behind their efforts and an objective of making money... after all, those are commercial products you're talking about. However, in the process of developing their customized forks, they may simultaneously create a product that is perfect for some users and entirely missing the mark for others. Which, in all fairness, is the same outcome that you could say is true of official OpenWrt (which is FOSS and developed by an entirely volunteer team) insofar as it isn't designed for your technophobe who just needs the basic settings in a super simple UI.
I think it's actually quite good, but I am used to it and I am a technophile, so I'll admit that I'm biased. Would other members of my family "get it" -- maybe, maybe not. But OpenWrt (and LuCI) isn't made to be everything to everybody. It's a user friendly UI on top of an extremely flexible firmware, and that UI is designed such that many of those features are available without requiring use of the command line.
So, is OpenWrt a "consumer" product... I'd say it is for the network enthusiast and/or the user who wants more flexibility and control (and security and...) and is willing to spend at least a little bit of effort to discover and learn instead of just using a sleek but inflexible commercial UI.
TBH, kinda sounds like it.
But here's the thing... OpenWrt is indeed open source. Anyone can develop for it. Which means, you could contribute by developing a LuCI theme (or even a LuCI replacement/alternate) that is, in your view, more attractive and easier to use than the version that exists now. Instead of complaining, turn that energy into action that can benefit the platform. Your UI will inevitably be hated by some, but if it is enjoyed/useful for others, that is a win!
Your move.
5 Likes
Just having done some experiments, using WDS, I have to say, its easy to use. But it looks like the specs are a bit open to interpretation. Thus, there is the chance of non-functional interoperability, in case of different SW/HW. I used WDS on 3 different SoCs simultaneously, but all running openWRT, and it worked. But quite a few other HW-architectures around And it might need individual "tweaking", depending upon usage case.
Very well spoken and valid points.
My original post was not meant to be harsh but it came from the heart. A lot of frustration with the UI. I think what really pushed me off the edge was setting a DNS on the lan side or vlans. :-/
All I can do is revisit the project and a few years and hope that enough people express concern over the UI and hope that somebody from development sees the light. I guess we can all dream right. But if we don't post our thoughts how will development ever know 
.
But for now I no longer use Openwrt as my main house router, only small side projects. Having two kids no longer allows me the opportunity to tinker with tech or self-host like I used to. Thus I have to turn to vendors like nethsecurity or glinet for better user experience.
I actually got frustrated with both those vendors a little, not as much as Luci, but I decided to pull the trigger on a Firewalla, and I'm content at the moment 
or maybe I'm just getting too old to tinker with stuff
Thank you for the reply by the way, it was a very thoughtful. Much appreciated mate.
1 Like
could there be any shell scripts, around, possibly in linux distros, that check if not setup repeater mode, similarly to the wiki explanations but let's say in some sort of automated checks say "ah you missed this" ...
Yes... but....
The problem is not about if it is possible, but rather about how robust they would be and also about how complex it might be for the user.
Specifically, consider that the OpenWrt device will not have a priori knowledge about the upstream network to which it needs to connect. Should it connect as a standard STA mode client, or use WDS or 802.11s or relayd? STA mode is simple, but the others require either an internet connection to get started (802.11s and relayd) since there are package requirements and/or may require the manipulation of settings on the upstream AP (for 802.11s or WDS) in addition to the local settings that need to be applied. So... a script would have to generalize for enough scenarios as to make it relatively robust and reliable... that's a tall order given the incredible variety of home network configuration options.
1 Like
well, obviously it'd have to be interactive because the target upstream network to join is obviously to be determined, say after scanning "the upstream network will be x.y.z.k" or sothg, it could also be just informative/read only, say for firewall zones lan/wan, now I am trying to get hold of a "proper" (memory > 8 mb) openwrt router, that I'm curious what can be determined from the shell, because the wiki is structured also as gui/shell mmh
uci show
1 Like
I got hold of a wifi router which explicitly supports openwrt https://openwrt.org/toh/sim/simax1800t
EP-RT2960S
there seems to be a gui configuration wizard luci-app-wizard from https://github.com/x-wrt/com.x-wrt/tree/master/luci-app-wizard
is there any documentation about it ? it's a javascript client side ?
for the record, with that particular router/openwrt 23.05 it would seem repeater mode needn't have relayd installed/configured
this is the configuration https://filebin.net/jwtu31llb9h7q1kj