Posted: Thu Jul 25, 2024 17:18 Post subject: Why is SFE not disabled when WAN is set to disabled?
I always wondered why SFE options are enabled in GUI if WAN is set to Disabled. A lot of other GUI options do change, but not SFE. Isn't SFE irrelevant without WAN? Maybe should be corrected to avoid confusion...
Probably for the same reason the Operating Mode remains in its current setting (usually Gateway) when the WAN is disabled. The router simply isn't 100% accurate in how it presents the GUI given various settings. Seems to me there should also be a Disabled setting for Operation Mode when the WAN is disabled. Or perhaps it shouldn't be a visible option at all. Or even better, perhaps there should be an AP option under Operating Mode, which disables the WAN, disables the firewall, disables the DHCP server, etc.
IOW, the router doesn't officially recognize AP mode. It puts the burden on YOU to know what buttons to push and strings to pull in order to get the desired behavior. And because it doesn't, you get other oddities where neither enabling NAT'ing nor Net Isolation w/ the GUI works w/ an unbridged VAP. OTOH, Forced DNS Redirection does! And all of these rely on the firewall. It's completely inconsistent.
The router simply isn't smart enough to recognize the user's intentions, which is to NAT the VAP over the LAN (br0), NOT the WAN, while still denying access between the VAP and LAN (br0). The firewall just remains empty (except for the DNS redirection). And w/o NAT'ing, and no static routing for the VAP's ip network upstream, there's no internet access from the VAP either. No reported errors. No nothing. It just doesn't work.
So how do *I* make it all work? Years of experience knowing where the router is going to fail me, and manually correcting it.
IMO, the router could benefit from an overhaul in this area so the setting of options was more consistent w/ the users intentions. Because it is lacking, we end up having to fix the same misconfigurations over and over. Fortunately @egc's excellent online manuals have helped mitigate the situation. But even so, it would be nice to see more thought put into the whole business of configuring Gateway vs. Router vs. AP mode so the GUI worked properly. And formally adding an AP mode would be a good place to start. A lot of other subsystems could also benefit from *explicitly* being informed of AP mode being active, such as the VPNs.
Wow, you put some time into that post. Good knowledge, well said and I agree the WebUI should be "smarter". It's not a priority I am sure as we only have one developer, for the most part and workarounds exist, while still a PiTA.
Among other things, SFE options should totally disappear when WAN is disabled and WAN goes to br0 automatically (I think it does already on most routers). This may be different with routers with built in switches and those than do not. I have not checked.
This would potentially be a huge change and probably never going to happen without a year of serious debugging. _________________ - Linksys EA8500: I-Gateway, WAP/VAP 5ghz only. Features: WDS-AP, VLANs, Samba, WG, Entware - r58662
- Linksys EA8500: 802.11s Secondary w/VLAN Trunk - r58662
- Linksys MX4300: 802.11s Primary w/VLAN Trunk over 5ghz. 2.4ghz WAP/VAP only - r58662
- Linksys MX4300 (WAP/VAP (7)) Multiple VLANs over single trunk port. Entware/Samba r58662
- Linksys MR7350: Testing r58662
- Linksys Velop WHW03v1 x2: OpenWRT w/GRETAP tunnel for VLANs on VAPs
- OSes: Fedora 39, 9 RPis (2,3,4,5), 20 ESP8266s: Straight from Amiga to Linux in '95, never having owned a Windows PC.
Joined: 08 May 2018 Posts: 15225 Location: Texas, USA
Posted: Fri Jul 26, 2024 3:28 Post subject:
The problem with gateway mode vs router mode when WAN is disabled is most likely because of SFE option, among other
things. No telling who broke the original functionality of Linksys Firmware / Sveasoft. Possibly related to the old fullswitch
function that was removed. In original Linksys firmware, all you had to do was set LAN (router) IP and disable the DHCP
server. I'll have to check to see if WAN port is still functional on my old WRT160Nv2 (RT2880 4/16) device, but still, it was
an easier, simpler process. No word back from BS on this query and I haven't taken the time to look through the code repo. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
SFE should not be enabled by default. I have said this many times and I would love to know the reasoning of why it is enabled. Makes zero sense. _________________ - Linksys EA8500: I-Gateway, WAP/VAP 5ghz only. Features: WDS-AP, VLANs, Samba, WG, Entware - r58662
- Linksys EA8500: 802.11s Secondary w/VLAN Trunk - r58662
- Linksys MX4300: 802.11s Primary w/VLAN Trunk over 5ghz. 2.4ghz WAP/VAP only - r58662
- Linksys MX4300 (WAP/VAP (7)) Multiple VLANs over single trunk port. Entware/Samba r58662
- Linksys MR7350: Testing r58662
- Linksys Velop WHW03v1 x2: OpenWRT w/GRETAP tunnel for VLANs on VAPs
- OSes: Fedora 39, 9 RPis (2,3,4,5), 20 ESP8266s: Straight from Amiga to Linux in '95, never having owned a Windows PC.
SFE should not be enabled by default. I have said this many times and I would love to know the reasoning of why it is enabled. Makes zero sense.
Because like most things w/ the router, proper functionality and compatibility take a backseat to performance. No one wants to put out a product that defaults w/ lower performance. Instead, you let the user experience the most the router can deliver, THEN wait for things to break as he begins to configure other features and introduces those incompatibilities.
I wouldn't have a problem w/ that *if* the router automatically disabled SFE/CTF/FA when incompatibile features were enabled. If that was the case, you wouldn't even need to expose these options in the first place. It's a technology most users don't understand, and they simply toggle it ON/OFF (usually at our direction) to see the effects, good or bad. Better to keep it where it belongs; hidden and managed by the router itself, NOT the end-user.
Because like most things w/ the router, proper functionality and compatibility take a backseat to performance. No one wants to put out a product that defaults w/ lower performance. Instead, you let the user experience the most the router can deliver, THEN wait for things to break as he begins to configure other features and introduces those incompatibilities.
You are correct, when commercial companies are involved, I would have doubts about DD-WRT being guilty of this. I am sure BS has his reasons, but I would be surprised if this is one of them.
eibgrad wrote:
I wouldn't have a problem w/ that *if* the router automatically disabled SFE/CTF/FA when incompatibile features were enabled. If that was the case, you wouldn't even need to expose these options in the first place. It's a technology most users don't understand, and they simply toggle it ON/OFF (usually at our direction) to see the effects, good or bad. Better to keep it where it belongs; hidden and managed by the router itself, NOT the end-user.
It all comes down to not being able to fully boot on bad builds w/SFE enabled. This totally fscks normal users who cannot tftp or even know what a serial port is. If you don't have a dual boot partition you are done. Toss it in the trash can, for most folks. _________________ - Linksys EA8500: I-Gateway, WAP/VAP 5ghz only. Features: WDS-AP, VLANs, Samba, WG, Entware - r58662
- Linksys EA8500: 802.11s Secondary w/VLAN Trunk - r58662
- Linksys MX4300: 802.11s Primary w/VLAN Trunk over 5ghz. 2.4ghz WAP/VAP only - r58662
- Linksys MX4300 (WAP/VAP (7)) Multiple VLANs over single trunk port. Entware/Samba r58662
- Linksys MR7350: Testing r58662
- Linksys Velop WHW03v1 x2: OpenWRT w/GRETAP tunnel for VLANs on VAPs
- OSes: Fedora 39, 9 RPis (2,3,4,5), 20 ESP8266s: Straight from Amiga to Linux in '95, never having owned a Windows PC.
This would potentially be a huge change and probably never going to happen without a year of serious debugging.
I don't think it would be as difficult or require as much time to implement as you believe. Once AP mode is made known, it just amounts to conditional implementation of various settings (if AP mode, do X, else do Y). What makes it difficult is not KNOWING the user is effectively in AP mode (i.e., bridged). But once you do, I just don't see it being all that complex.
Whatever the effort required, part of the problem here is that the limited resources of the project are spent primarily on making sure every Tom, Dick, and Harry router known to mankind is supported, including those from the early 2000's. What I'd prefer to see is a little less focus on THAT (even just a brief hiatus) and more time spent on solving these kinds of pesky UI issues.
What makes it difficult is not KNOWING the user is effectively in AP mode (i.e., bridged). But once you do, I just don't see it being all that complex.
This may be the show stopper.
eibgrad wrote:
Whatever the effort required, part of the problem here is that the limited resources of the project are spent primarily on making sure every Tom, Dick, and Harry router known to mankind is supported, including those from the early 2000's. What I'd prefer to see is a little less focus on THAT (even just a brief hiatus) and more time spent on solving these kinds of pesky UI issues.
Trust me, there has been no major (but a few minor) attention paid to these old 2006-2012 routers in many years. The kernels are no longer supported at all. It' honestly a waste of build resources, but some people still have them including myself. I don't use them but pull them out once or twice a year and upgrade them, or try anyway. Some builds are atrocious.
Quote:
Fortunately other devs, like @egc and company, have taken up the slack in recent years to make a lot of this happen (the project has never looked and worked better in many respects), but there are still a lot of lingering issues that need attention.
It's a very small crew. Not anything like openwrt, but better in the end I think. I love it regardless of the issues. I have used it for 18 years. I know the quarks and workarounds. _________________ - Linksys EA8500: I-Gateway, WAP/VAP 5ghz only. Features: WDS-AP, VLANs, Samba, WG, Entware - r58662
- Linksys EA8500: 802.11s Secondary w/VLAN Trunk - r58662
- Linksys MX4300: 802.11s Primary w/VLAN Trunk over 5ghz. 2.4ghz WAP/VAP only - r58662
- Linksys MX4300 (WAP/VAP (7)) Multiple VLANs over single trunk port. Entware/Samba r58662
- Linksys MR7350: Testing r58662
- Linksys Velop WHW03v1 x2: OpenWRT w/GRETAP tunnel for VLANs on VAPs
- OSes: Fedora 39, 9 RPis (2,3,4,5), 20 ESP8266s: Straight from Amiga to Linux in '95, never having owned a Windows PC.
Among other things, SFE options should totally disappear when WAN is disabled and WAN goes to br0 automatically (I think it does already on most routers). This may be different with routers with built in switches and those than do not. I have not checked.
Most routers apart from x86 and a few AX devices have an integrated switch.
On these devices, the switch must be reconfigured and the WAN port does not have to be bridged with the LAN.
This must be changed at switch level then the traffic is also handled by the switch fabric.
If you simply bridge the WAN port then all traffic flows through the processor. (and this is not desirable on old routers with little CPU power)
secondly, SFE/NSS/CTF/FA should not be hidden in principle if the WAN is deactivated.
The NSS stuff can at least do WIFI offloading. (no idea if it works in the latest build - so far I haven't noticed anything)
The R7800 does not manage 1gbit WLAN throughput (TX) without NSS offoading because the CPU with 100% load is the bottleneck.
I have tested various NSS firmwares in the past and they managed 1Gbit (TX) with 50-75% load.
I remember the EA8500 (among many others) once had a checkbox to make WAN part of the LAN whenever WAN was disabled. This disappeared quite some time ago and simply disabling the WAN made it a regular switch port. Then with the updated switch config, we had to move the WAN to VLAN1 to make it part of the switch.
With that said, much has changed since then, including the much needed major upgrades to the Switch Config page. Perhaps this was when the check box disappeared?
Had no idea NSS could also handle WiFi. I assumed, like many others it was WAN only. Thanks for that info. So I guess the question is, how does one utilize that? Is it automatic? _________________ - Linksys EA8500: I-Gateway, WAP/VAP 5ghz only. Features: WDS-AP, VLANs, Samba, WG, Entware - r58662
- Linksys EA8500: 802.11s Secondary w/VLAN Trunk - r58662
- Linksys MX4300: 802.11s Primary w/VLAN Trunk over 5ghz. 2.4ghz WAP/VAP only - r58662
- Linksys MX4300 (WAP/VAP (7)) Multiple VLANs over single trunk port. Entware/Samba r58662
- Linksys MR7350: Testing r58662
- Linksys Velop WHW03v1 x2: OpenWRT w/GRETAP tunnel for VLANs on VAPs
- OSes: Fedora 39, 9 RPis (2,3,4,5), 20 ESP8266s: Straight from Amiga to Linux in '95, never having owned a Windows PC.
Joined: 08 May 2018 Posts: 15225 Location: Texas, USA
Posted: Fri Jul 26, 2024 21:26 Post subject:
lexridge wrote:
I remember the EA8500 (among many others) once had a checkbox to make WAN part of the LAN whenever WAN was disabled. This disappeared quite some time ago and simply disabling the WAN made it a regular switch port. Then with the updated switch config, we had to move the WAN to VLAN1 to make it part of the switch.
With that said, much has changed since then, including the much needed major upgrades to the Switch Config page. Perhaps this was when the check box disappeared?
This was part of the fullswitch function I've mentioned. I do believe that it coincided with Broadom switching over to SWCONFIG and the VLANs page fixes that sir @ho1Aetoo so diligently assisted with. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
