AP Isolation Feature Missing on Netgear WNDR3800CH (in 17.01)

Hello,

I have a Netgear WNDR3800CH running LEDE 17.01.4. Everything works great! But I seem to missing a feature. Could it be due to a bug, lack of implementation, or unobtanium with LEDE?

When I go into Advanced on Wireless interfaces, I am missing the option to isolate AP client traffic.

Any help or suggestions would be greatly appreciated!

From where / what you know / assume it should be there? On a Netgear R7800 it is also not present.

It may be a feature of the full wpad (instead of wpad-mini) only, use opkg to switch it.

1 Like

With full wpad the feature is present at least on master both with R7800 and WNDR3700v2:

I see no reason why the feature would be missing from 17.01.4

(and the feature is listed in the common wireless interface optiosn in https://lede-project.org/docs/user-guide/wifi_configuration#common_options1 )

1 Like

Thank you @slh & @hnyman for the hints. Although it is a useful option for a broader user group and regarding it's mentioned in the "common wireless interface options" I find it a bit uncommon to find & use.

Best way to get a better presentation / attention of this feature and the package which is necessary to use it?

For beginners also useful: Remove installed wpad-mini or parallel installation of wpad & wpad-mini

Thanks so much for the responses.

I have another router running LEDE 17.01.4, which, just like the image you provided, has the checkbox to isolate clients under Advanced.

Even after removing wpad-mini and replacing it with wpad, the feature is not present.

Please accept my apologies for misunderstanding. I didn't mean the feature was missing entirely from LEDE 17.01.4 per se, but that it was missing on the WNDR3800CH when using 17.01.X (and was also missing on OpenWRT builds tested before switching to LEDE). Also adding the line to enable AP Isolate from SSH has no effect.

Perhaps lack of support for this feature in the drivers inside the firmware? Or any other suggestions?

Thanks again for the help!

1 Like

Sounds strange as I do not think that the 3800CH version would be different regarding that feature.

Please forgive my ignorance of LEDE and everything with packages. While I do have an understanding of Linux, I have not been using LEDE but a few short months, and before, OpenWRT for less than a year. I do know how the packages work with respect to adding software to the router to add features above and beyond those included by default in the LEDE firmware, and have installed packages on my router (wshaper). Outside of that, I have no clue which packages supplement which features.

The best way I know to present this feature is to just explain our network environment and exactly what we are aiming to achieve.

There are two configured interfaces. One for LAN, one for Guest.

In Ethernet, LAN is bridged to vlan1 and Guest is bridged to vlan3. All 4 Ethernet ports are untagged vlan1, with the exception of two, which also has vlan3 tagged which connects to two other switches (and access points).

In Wireless, under both the 2.4 and 5.7 radios, there are two SSID's. One which is bridged to the LAN interface, and the other bridged to the Guest interface.

As things stand, traffic between wired devices and wireless stations connected to the LAN interface and wireless stations connected to the Guest interface are isolated from one another and neither are able to communicate outside their respective interface/vlan assignment, which works exactly as intended.

On the wireless Guest SSID, we desire exactly what the setting describes and enables, which is to isolate client stations and prevent client-to-client communication, except in the rare circumstances when governed by and permitted by the gateway.

If two stations are connected to the Guest SSID, they should not be able to see or talk to one another directly, regardless of what both of the station's IPv4/IPv6 address settings and subnet membership may be or whatever the communication protocol utilized may be (example, IPX/SPX or NetBeui). The only device on the network that connected stations on the Guest SSID should be able to directly communicate with is the Gateway/Router (and, technically, all wired devices that may happen to also be on vlan3).

The intention is to prevent guests with devices that are connected stations on our network from being able to communicate with the other guest stations via our network. There are several reasons for desiring this, but primary reasons are to protect guests and their connected devices from other connected guests who may potentially be bad actors from gaining unauthorized access to their devices and their data, prevent guests that are potential bad actors from depriving other guest devices the capability to utilize network resources through Denial of Service attacks, and prevent the spread of malware (computer viruses, worms, etc.) by guests with infected devices to other guests with devices potentially vulnerable by exploitation through automated transmission of data consisting of malware payload via our network, such as demonstrated by the "WannaCry" ransomware that spread from an infected host to a vulnerable host by exploiting certain Microsoft Windows products vulnerable to the "SMB1 EternalBlue" exploit.

However, client isolation is not desired for devices connected to the LAN SSID. For connected stations on this SSID, network communication shall be business as usual. These stations should be treated just like they were wired into an Ethernet port bridged to the LAN interface and shall be capable of engaging in two-way communication with all other devices also on the LAN interface without the requirement of intervention from the Gateway/Router, regardless of the method the target device may be connected to the LAN interface (Ethernet, wireless, virtual network switch, or any other means such a VPN bridge or by carrier pigeon).

I am going to go out on a limb and guess that the package(s) required to utilize this feature, as well as other wireless features, is going to be wpad and wpad-mini. But I am not 100% sure here. From my viewpoint, it looks more like this is feature of the wireless chipset that is enabled and ultimately governed by chipset drivers which is then controlled by packages wpad/wpad-mini (The end user chooses whether or not to enable feature through LEDE or SSH, which then wpad sets the stage for the chipset driver to do it's wonderful magic). It appears that the wpad/wpad-mini packages are working as expected and the option is being suppressed in LEDE and configuration option ignored by wpad because the chipset driver may not advertise the capability or the driver completely lacks the feature as one of it's options, as "Test Subject #2" router (Not a Netgear WNDR3800CH) has the isolation option present and is functional when enabled.

BUT... I'm just speculating here and rambling on!

If the wireless chipsets in this radio simply lack the capability to do client isolation, then that's just how it is and I am satisfied with that answer and we'll make the best of the situation and move on. Otherwise, if it is lack of support in the drivers, or poor implementation, I will be more than glad to do my part and lend a hand in trying to help make it work. Noted, my assistance will most likely be severely limited to testing development snapshots or beta firmwares (or whatever), unless you want to teach this old dog new tricks. I'm willing to learn. :wink:

There may be other devices in the wild with the same chipsets and radios as mine which also exhibit the feature disabled and lack of configuration option in LuCI owned and used by other loyal LEDE users who either haven't noticed the feature missing, didn't know about the feature to begin with, or did happen to notice the feature lacking and simply chalked it up as a feature unsupported by LEDE. If so, then I am sure the community would benefit from proper implementation of this feature, regardless of whether the chipset driver or the wpad package is the culprit.

Thanks again for your attention and assistance!

Based on Googling the intarwebs, it appears that the 'isolate' feature may only be implemented for Broadcom chipsets. The Netgear WNDR3800CH has an Atheros chipset, and the wifi-device type identifies as 'mac80211'.

image

The afore mentionend R7800 is also Atheros based. Have you tried to add the option to the right section of /etc/config/wireless?

Hello,

Thanks for the reply.

While the R7800 is Atheros based, it's CPU is a "Qualcomm Atheros IPQ8065" and WLAN radios are "Qualcomm Atheros QCA9984".

The WNDR3800 CPU is an Atheros AR716 and WLAN radios are AR9220 and AR9223.

While both routers indeed have Atheros silicon inside of them, they are not one in the same, and most likely require different drivers to function.

As far as adding the line "option isolate 1" under appropriate config wifi-iface blocks in /etc/config/wireless with vi using ssh, that was one of the first things I tried. Adding the line does not break anything with wireless, nor does it enable isolation. There is no noticeable difference adding the config option, it appears as if the line simply gets ignored.

I wish the solution was that easy though! If it were, I would be isolating, happy as a pig in the mud, and wouldn't be here bugging y'all! :slight_smile:

Furthermore, based on my Googlin' research of the Intarwebs, it appears that problems with isolation support on OpenWRT "backfire" and mac80211 (ath9k) was reported several years ago, earning Ticket #7645, but appears to have been closed with no explanation. It does appear that around 7 years ago, some driver patches for mac80211/ath9k on Linux was written, and patches were written to enable isolation support in hostapd for mac80211, but is most likely useless without support from the drivers.

Based on other people's accounts, support was added to the OpenWRT trunk somewhere around version 10, but was quietly pulled in a later release... Also, I don't know what differences are between hostapd and wpad and whether a patch for one would be relevant for developing a patch for the other. We're beginning to enter the Twilight Zone that consists of the limits of my coding experience (or scripting, programming, or whatever the cool kids call it these days).

To try and get the appropriate attention focused on this that is deserved, I am going to "git" the source code of the latest build of LEDE and review the code for ath9k and mac8011 drivers and see if isolate support is there. I think that would be a good start to solving this mystery, and then we can figure out where to go from there.

My speculation:

Many moons ago, this problem was reported to OpenWRT, and a patched driver based on the current driver at the time adding support was put in the "trunk" (or whatever political process that happens when updated code is committed to the project). Later, Atheros releases an official driver update of their own, but still lacked isolation support, or was improperly implemented. The official updated driver from Atheros, unpatched, replaced the unofficial patched driver in trunk, and since fixing isolation was not a hard pressing issue, the earth continued to revolve and no further cares were given and the rest is history.

Sometimes I hate history.

You have done a fair part of research, good work! So now there is a tiny chance of changing history or loosing some hair and your sane mind ;- )

Practically I would buy another router and sell the old one, but different folks choose different strokes ;- )

...or file a bug report?

Thank you so much! I guess you don't see many people these days that do that much more.

Change history!??? I always knew I would do something great with my life...

Lose some hair??? It is cut to the nub anyways, so no worries!

Lose my sane mind? Oh, hell... I lost that many years ago!!!

Purchasing a new router is something that I do plan to do in the future. This router was a Charter cable freebie, so no love lost there. Usually once I take old routers out of service, I try to extend their life by making them standalone switches / access points to improve wireless signal in a home, donate to someone in need that cannot afford, or use them for Wifi Repeaters. If you want to know something that does make me lose my hair and lose sanity, it is tossing out equipment that is still technologically relevant and useful. Love Mother Earth and Recycle! :slight_smile:

OK, so, let's get serious here about this. Who's chain do I need to yank to file a bug report???

I like your spirit, same here. I try to repair everything like micro waves, washing machines, TFT monitors, HiFi equipment, motherboards, bikes and cars and extend it's life e.g. Lineage OS on old smartphones.

Here is the link for the bug report:

https://bugs.lede-project.org/

Thank you very much. I will escalate this issue further in a bug report, and hopefully someone more knowledgeable about all the 1's and 0's of this router and the firmware project can diligently cook up a working solution that will make me, and possibly many other very loyal LEDE firmware users, very happy!!!

Also, I do greatly appreciate you taking time today to try and assist me with this. With troubleshooting, suggestions and tips, and sharing ideas. I hope Karma greatly rewards you for your generosity assisting others!

Please do have a great evening.

LEDE FOR LIFE!!!

Y'all. Check this!

So, overnight while inebriated, I made the wise choice to whack the software and settings in this Netgear WNDR3800CH router. Yeah yeah, go ahead, rub it in while the wounds are nice and fresh!

At first, I thought, I'll just re-flash the 17.01.4 firmware and things will be golden and I can go back to goofing off on the Intarwebs.

Not a chance!

So I knew my night of bad decisions and poor mouse clicks would reach the point where "wiping" the LEDE partition and starting from scratch would be the quickest and easiest route to joyful packet flow. I also felt that it would be fun to download and flash the latest LEDE development snapshot firmware into the big red router.

And I sure am glad I did. This choice would prove to be the smartest choice I made all night, hell, the past 24 hours!

While getting everything all set back up through LuCI, I noticed that the "Isolate Clients" feature was present in the development snapshot!

Is this just some evil joke to tease me? Is this too good to be true? I just had to find out!

My tests confirm that the latest development snapshot does show the "Isolate Clients" option under Advanced Settings, and it does work as advertised when enabled!

WOO HOO!!! Christmas came early for this old boy!

Cash me online. Howbow dah?

Good decision to try the snapshot! When does the feature showed up? After installing wpad? You removed wpad-mini afterwards?

Hey bud, thanks for responding.

The feature showed up instantly after flashing the snapshot firmware, which like other firmware releases I've tried, has wpad-mini out of the box. I did not have to remove wpad-mini and install wpad to make it work.

Thank you for your feedback, spares me some time fiddling around....