What's new

Repeater connected to Guest SSID bypassing Access Intranet = Disable

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Like I said, disable WDS and just use it as a standard repeater. They are not updating or fixing anything with WDS, the technology is old, insecure, and flawed.

If you're running a coffee shop and letting anyone add a WDS node, you should focus on coffee and hire someone to set up your wifi.

Pulled out an AP last night, connected as repeater on my guest network, guests on that AP get 192.168.101.x IPs and cannot hit main LAN or main router.
WDS is not being used and wps is disabled. It is being used as a standard repeater.

This AP you pulled out was it an ASUS wireless router in repeater mode? If not then it does not apply to this issue.
 
Last edited:
WDS is not being used and wps is disabled. It is being used as a standard repeater.

From what @guetech posted from the logs, it is using WDS. I guess even if it is disabled it is getting used, which if so, is a bug for sure. Doesn't seem to be an issue on the AC68U so maybe it is only with the HND chipset routers.

Of course anyone with bad intentions can crack your main wifi in a few minutes with readily available utilities anyway so it isn't like we're talking high security to start with here.

If you're concerned with malicious users, time to go to professional gear. If you want to isolate IOT or guest stuff and aren't worried about your neighbors trying to hack you, Aimesh is the solution for that, or you can run a script to move the WDS interfaces that are getting created into the proper bridges.

@RMerlin - do you know why Asus is using WDS when it sees its own brand repeater connect, even if WDS is not configured? Something related to AImesh?
 
From what @guetech posted from the logs, it is using WDS. I guess even if it is disabled it is getting used, which if so, is a bug for sure. Doesn't seem to be an issue on the AC68U so maybe it is only with the HND chipset routers.

Of course anyone with bad intentions can crack your main wifi in a few minutes with readily available utilities anyway so it isn't like we're talking high security to start with here.

If you're concerned with malicious users, time to go to professional gear. If you want to isolate IOT or guest stuff and aren't worried about your neighbors trying to hack you, Aimesh is the solution for that, or you can run a script to move the WDS interfaces that are getting created into the proper bridges.

@RMerlin - do you know why Asus is using WDS when it sees its own brand repeater connect, even if WDS is not configured? Something related to AImesh?
Thank you for acknowledging it. I understand that if this is a big issue for someone that they should be using better equipment but that does not mean that Asus should ignore it. In the corporate world this would be a huge concern and a company like Cisco would have it fixed within days.
 
From what @guetech posted from the logs, it is using WDS.
I don't believe it is using WDS. wds1.1.1 is just the name of the interface. Even if it wanted to use WDS it would only be able to do so if it was enabled on the primary router, which we have been assured it isn't.
 
I don't believe it is using WDS. wds1.1.1 is just the name of the interface. Even if it wanted to use WDS it would only be able to do so if it was enabled on the primary router, which we have been assured it isn't.

Maybe not officially wds but it is creating a new interface for that repeater only when it is an asus router. Maybe it is part of the aimesh discovery process and preparing it for setup? Must be a way to completely disable aimesh on these things?
 
Maybe not officially wds but it is creating a new interface for that repeater only when it is an asus router. Maybe it is part of the aimesh discovery process and preparing it for setup? Must be a way to completely disable aimesh on these things?
It would be more useful seeing the log activity on the primary router rather than the repeater as that is where the guest isolation is taking place.
 
It would be more useful seeing the log activity on the primary router rather than the repeater as that is where the guest isolation is taking place.

The log from my post here was taken from the primary router, it shows what happens when the repeater connects to it.

All this talk about WDS is a red herring because both repeater mode and aimesh use a modified WDS that is unrelated to enabling/disabling WDS in the GUI on the primary router.


By the way I found a possible solution: Apply the same ebtable rules on interface wds+ that Asus puts on wlX.X when intranet is disabled:

Code:
ebtables -t broute -A BROUTING -p IPv4 -i wds+ --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
ebtables -t broute -A BROUTING -p IPv4 -i wds+ --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
ebtables -t broute -A BROUTING -p IPv4 -i wds+ --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP

Those rules need to be reapplied when wireless is restarted and will break AiMesh if you use it.
 
The log from my post here was taken from the primary router, it shows what happens when the repeater connects to it.
Sorry, my mistake. I thought it was from the repeater because none of those wds interfaces exist on my router that's also running a guest network. So if you haven't enabled WDS it must be being enabled in some other way as alluded to by @drinkingbird.
 
Sorry, my mistake. I thought it was from the repeater because none of those wds interfaces exist on my router that's also running a guest network. So if you haven't enabled WDS it must be being enabled in some other way as alluded to by @drinkingbird.
The interface is automatically created when the repeater connects, it isn't present before that.

Edit: Let me know if I can enable a more verbose logging mode to follow more closely what happens when the repeater connects to the primary!
 
Last edited:
The interface is automatically created when the repeater connects, it isn't present before that.

Edit: Let me know if I can enable a more verbose logging mode to follow more closely what happens when the repeater connects to the primary!
I configured my old RT-AC68U as a repeater and confirmed your findings.

When my repeater connects to the router's guest Wi-Fi it creates another wireless interface (wds0.2.1) and adds it to the bridge br0. But it doesn't make any changes to ebtables so there's no LAN isolation.

I think the creation of the new interface is happening somewhere within the wireless driver. I initially assumed that there was some client/server communication happening between the two devices but that doesn't appear to be the case as there is no IP configured on the connection (tcpdump sees only two broadcast packets over the interface).

I don't know at what point the router creates the normal ebtables isolation rules. I'd guess that this would be a separate userland process that happens after an interface is created rather than being part of the wireless driver code. If that's the case then that code was probably never written to take account of guest isolation for an Asus repeater.

Code:
May  4 01:17:34 wlceventd: wlceventd_proc_event(505): wl0.2: Auth 30:5A:3A:C7:8A:21, status: Successful (0)
May  4 01:17:34 wlceventd: wlceventd_proc_event(469): wl0.2: Deauth_ind 30:5A:3A:C7:8A:21, status: 0, reason: Unspecified reason (1)
May  4 01:17:34 wlceventd: wlceventd_proc_event(505): wl0.2: Auth 30:5A:3A:C7:8A:21, status: Successful (0)
May  4 01:17:34 hostapd: wl0.2: STA 30:5a:3a:c7:8a:21 IEEE 802.11: associated
May  4 01:17:34 wlceventd: wlceventd_proc_event(534): wl0.2: Assoc 30:5A:3A:C7:8A:21, status: Successful (0)
May  4 01:17:35 hostapd: wl0.2: STA 30:5a:3a:c7:8a:21 RADIUS: starting accounting session 666B8932B21C30B8
May  4 01:17:35 hostapd: wl0.2: STA 30:5a:3a:c7:8a:21 WPA: pairwise key handshake completed (RSN)
May  4 01:17:35 kernel: wfd_registerdevice Successfully registered dev wds0.2.1 ifidx 1 wfd_idx 0
May  4 01:17:35 kernel: device wds0.2.1 entered promiscuous mode
May  4 01:17:35 kernel: br0: port 9(wds0.2.1) entered forwarding state
May  4 01:17:35 kernel: br0: port 9(wds0.2.1) entered forwarding state
May  4 01:17:36 kernel: device br0 entered promiscuous mode

May  4 01:17:52 dnsmasq-dhcp[2965]: DHCPDISCOVER(br0) 30:5a:3a:c7:8a:20
May  4 01:17:52 dnsmasq-dhcp[2965]: DHCPOFFER(br0) 192.168.1.187 30:5a:3a:c7:8a:20
May  4 01:17:52 dnsmasq-dhcp[2965]: DHCPREQUEST(br0) 192.168.1.187 30:5a:3a:c7:8a:20
May  4 01:17:52 dnsmasq-dhcp[2965]: DHCPACK(br0) 192.168.1.187 30:5a:3a:c7:8a:20
May  4 01:19:35 kernel: device br0 left promiscuous mode

Code:
# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.f02f749237d8       no              eth1
                                                        eth2
                                                        eth3
                                                        eth4
                                                        eth5
                                                        eth6
                                                        eth7
                                                        wds0.2.1
                                                        wl0.2
                                                     
# ebtables -t broute -L
Bridge table: broute

Bridge chain: BROUTING, entries: 5, policy: ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
 
Last edited:
The log from my post here was taken from the primary router, it shows what happens when the repeater connects to it.

All this talk about WDS is a red herring because both repeater mode and aimesh use a modified WDS that is unrelated to enabling/disabling WDS in the GUI on the primary router.


By the way I found a possible solution: Apply the same ebtable rules on interface wds+ that Asus puts on wlX.X when intranet is disabled:

Code:
ebtables -t broute -A BROUTING -p IPv4 -i wds+ --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
ebtables -t broute -A BROUTING -p IPv4 -i wds+ --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
ebtables -t broute -A BROUTING -p IPv4 -i wds+ --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP

Those rules need to be reapplied when wireless is restarted and will break AiMesh if you use it.

You also want to move the wds interface over to the guest bridge (br1 in the case of 192.168.1.1), just need to toy with the best script to put it in, probably one of the service-event ones. That way the IPtables rules get applied also since they are against the br1 interface. The ebtables rules allow all UDP through and will also allow ping of the router interface (not a big deal on the second one, but the first you want to block, which the IPtables rules do, with the exception of DHCP and DNS).

EDIT Sorry I forgot you are using GW2/3 - disregard. The necessary iptables rules are already in place since they all share BR0.

Make sure you delete your rules with -D prior to doing -A. Otherwise you can end up with many copies and could become an issue (each time the script is called it adds them and does not overwrite) and the firewall-start script gets called twice at startup and when you do other things also, and service-event ones can get called many times.

My guess is that it is still related to Aimesh, even if you aren't enabling it, it is making itself discoverable, or expecting that you are going to configure aimesh or something. There is probably some process you can kill at startup or maybe NVRAM value you can change to prevent this behavior alltogether.

If you don't want devices on the repeater to be able to see each other, enable AP isolation on that (same thing asus does on guest). Or maybe that setting is being propagated by this phantom aimesh, who knows.
 
Last edited:
I configured my old RT-AC68U as a repeater and confirmed your findings.

When my repeater connects to the router's guest Wi-Fi it creates another wireless interface (wds0.2.1) and adds it to the bridge br0. But it doesn't make any changes to ebtables so there's no LAN isolation.

I think the creation of the new interface is happening somewhere within the wireless driver. I initially assumed that there was some client/server communication happening between the two devices but that doesn't appear to be the case as there is no IP configured on the connection (tcpdump sees only two broadcast packets over the interface).

I don't know at what point the router creates the normal ebtables isolation rules. I'd guess that this would be a separate userland process that happens after an interface is created rather than being part of the wireless driver code. If that's the case then that code was probably never written to take account of guest isolation for an Asus repeater.

Code:
May  4 01:17:34 wlceventd: wlceventd_proc_event(505): wl0.2: Auth 30:5A:3A:C7:8A:21, status: Successful (0)
May  4 01:17:34 wlceventd: wlceventd_proc_event(469): wl0.2: Deauth_ind 30:5A:3A:C7:8A:21, status: 0, reason: Unspecified reason (1)
May  4 01:17:34 wlceventd: wlceventd_proc_event(505): wl0.2: Auth 30:5A:3A:C7:8A:21, status: Successful (0)
May  4 01:17:34 hostapd: wl0.2: STA 30:5a:3a:c7:8a:21 IEEE 802.11: associated
May  4 01:17:34 wlceventd: wlceventd_proc_event(534): wl0.2: Assoc 30:5A:3A:C7:8A:21, status: Successful (0)
May  4 01:17:35 hostapd: wl0.2: STA 30:5a:3a:c7:8a:21 RADIUS: starting accounting session 666B8932B21C30B8
May  4 01:17:35 hostapd: wl0.2: STA 30:5a:3a:c7:8a:21 WPA: pairwise key handshake completed (RSN)
May  4 01:17:35 kernel: wfd_registerdevice Successfully registered dev wds0.2.1 ifidx 1 wfd_idx 0
May  4 01:17:35 kernel: device wds0.2.1 entered promiscuous mode
May  4 01:17:35 kernel: br0: port 9(wds0.2.1) entered forwarding state
May  4 01:17:35 kernel: br0: port 9(wds0.2.1) entered forwarding state
May  4 01:17:36 kernel: device br0 entered promiscuous mode

May  4 01:17:52 dnsmasq-dhcp[2965]: DHCPDISCOVER(br0) 30:5a:3a:c7:8a:20
May  4 01:17:52 dnsmasq-dhcp[2965]: DHCPOFFER(br0) 192.168.1.187 30:5a:3a:c7:8a:20
May  4 01:17:52 dnsmasq-dhcp[2965]: DHCPREQUEST(br0) 192.168.1.187 30:5a:3a:c7:8a:20
May  4 01:17:52 dnsmasq-dhcp[2965]: DHCPACK(br0) 192.168.1.187 30:5a:3a:c7:8a:20
May  4 01:19:35 kernel: device br0 left promiscuous mode

Code:
# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.f02f749237d8       no              eth1
                                                        eth2
                                                        eth3
                                                        eth4
                                                        eth5
                                                        eth6
                                                        eth7
                                                        wds0.2.1
                                                        wl0.2
                                                     
# ebtables -t broute -L
Bridge table: broute

Bridge chain: BROUTING, entries: 5, policy: ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.1.1 --ip-proto icmp -j ACCEPT
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto icmp -j DROP
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP
-p IPv4 -i wl0.2 --ip-dst 192.168.1.0/24 --ip-proto tcp -j DROP

So it is re-applying a second copy of the ebtables rules but using the wrong interface. This must be some sort of leftover from either early aimesh or some auto-WDS or auto mesh that they had at some point and forgot about/didn't update.

Probably be more fruitful to find a process that can be killed at some point during startup but I guess as long as EBTABLES rules are added with the "+" it will cover any Asus repeater that gets added.
 
So it is re-applying a second copy of the ebtables rules but using the wrong interface.
No, the duplicated rules can be ignored as they're nothing to do with this problem. They're present even when the repeater isn't connected, and I don't use AiMesh. My firmware is rather old now so it's likely this glitch has since been corrected. I'll edit my post to remove those lines to avoid future confusion.
 
No, the duplicated rules can be ignored as they're nothing to do with this problem. They're present even when the repeater isn't connected, and I don't use AiMesh. My firmware is rather old now so it's likely this glitch has since been corrected. I'll edit my post to remove those lines to avoid future confusion.

Ah, yeah I only have one copy on mine, figured it was adding those when you added the repeater.
 
My guess is that it is still related to Aimesh, even if you aren't enabling it, it is making itself discoverable, or expecting that you are going to configure aimesh or something. There is probably some process you can kill at startup or maybe NVRAM value you can change to prevent this behavior alltogether.

I had the same feeling so I tried dropping traffic to cfg_server (UDP 7788 and TCP 7788) and infosvr (UDP 9999) on the primary to see if it would help.

The primary no longer knew the SSIDs of the repeater (they were visible in nvram show before) and no longer knew it was an AX-55, so that's something. Unfortunately the wds still ended up in br0 with no ebtables restrictions. (I also tried again connecting the repeater to guest 1 but it still ends up in br0 instead of br1/2).

It's possible my rules weren't perfect or that there are more processes at play (/usr/sbin/asusdiscovery seems to start during the pairing but it doesn't run long enough for me to see if it listens or sends anything).


I took your advice and did some tests to see what still goes through. Asus rules were indeed leaky, so I improved a bit. I also looked for the best script to apply the new rules, which seems to be service-event-end when $2==wireless and firewall-start.

Code:
#!/bin/sh

LAN_SUBNET="192.168.1.0/24"
ROUTER_IP="192.168.1.1"

ebtables -t broute --new-chain RESTRICT_LAN 2> /dev/null
ebtables -t broute -F RESTRICT_LAN
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-proto udp --ip-sport 67:68 --ip-dport 67:68 -j ACCEPT # DHCP
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst $ROUTER_IP --ip-proto tcp --ip-dport 53 -j ACCEPT # DNS
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst $ROUTER_IP --ip-proto udp --ip-dport 53 -j ACCEPT # DNS
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst $ROUTER_IP --ip-proto udp --ip-dport 5351 -j ACCEPT # NAT-PMP
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst $ROUTER_IP --ip-proto icmp -j ACCEPT
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst $LAN_SUBNET -j DROP
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst 224.0.0.0/4 -j DROP
ebtables -t broute -A RESTRICT_LAN -p IPv6 -j DROP

# Always apply our restrictions to WDS devices (avoid(reduce) isolation break when a repeater connects to a guest network)
ebtables -t broute -D BROUTING -i wds+ -j RESTRICT_LAN
ebtables -t broute -A BROUTING -i wds+ -j RESTRICT_LAN

# Apply our custom restrictions to guest 2 and 3 if needed
for INTERFACE in wl0.2 wl0.3 wl1.2 wl1.3; do
    ebtables -t broute -L BROUTING | grep "\-i $INTERFACE " | while read -r line ; do
        ebtables -t broute -D BROUTING $line
    done
    if [ "$(nvram get "${INTERFACE}_bss_enabled")-$(nvram get ${INTERFACE}_lanaccess)" = "1-off" ]; then
        ebtables -t broute -A BROUTING -i $INTERFACE -j RESTRICT_LAN
    fi
done


As a bonus the single chain now gives a much more readable ebroute -t broute -L output.
 
I had the same feeling so I tried dropping traffic to cfg_server (UDP 7788 and TCP 7788) and infosvr (UDP 9999) on the primary to see if it would help.

The primary no longer knew the SSIDs of the repeater (they were visible in nvram show before) and no longer knew it was an AX-55, so that's something. Unfortunately the wds still ended up in br0 with no ebtables restrictions. (I also tried again connecting the repeater to guest 1 but it still ends up in br0 instead of br1/2).

It's possible my rules weren't perfect or that there are more processes at play (/usr/sbin/asusdiscovery seems to start during the pairing but it doesn't run long enough for me to see if it listens or sends anything).


I took your advice and did some tests to see what still goes through. Asus rules were indeed leaky, so I improved a bit. I also looked for the best script to apply the new rules, which seems to be service-event-end when $2==wireless and firewall-start.

Code:
#!/bin/sh

LAN_SUBNET="192.168.1.0/24"
ROUTER_IP="192.168.1.1"

ebtables -t broute --new-chain RESTRICT_LAN 2> /dev/null
ebtables -t broute -F RESTRICT_LAN
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-proto udp --ip-sport 67:68 --ip-dport 67:68 -j ACCEPT # DHCP
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst $ROUTER_IP --ip-proto tcp --ip-dport 53 -j ACCEPT # DNS
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst $ROUTER_IP --ip-proto udp --ip-dport 53 -j ACCEPT # DNS
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst $ROUTER_IP --ip-proto udp --ip-dport 5351 -j ACCEPT # NAT-PMP
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst $ROUTER_IP --ip-proto icmp -j ACCEPT
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst $LAN_SUBNET -j DROP
ebtables -t broute -A RESTRICT_LAN -p IPv4 --ip-dst 224.0.0.0/4 -j DROP
ebtables -t broute -A RESTRICT_LAN -p IPv6 -j DROP

# Always apply our restrictions to WDS devices (avoid(reduce) isolation break when a repeater connects to a guest network)
ebtables -t broute -D BROUTING -i wds+ -j RESTRICT_LAN
ebtables -t broute -A BROUTING -i wds+ -j RESTRICT_LAN

# Apply our custom restrictions to guest 2 and 3 if needed
for INTERFACE in wl0.2 wl0.3 wl1.2 wl1.3; do
    ebtables -t broute -L BROUTING | grep "\-i $INTERFACE " | while read -r line ; do
        ebtables -t broute -D BROUTING $line
    done
    if [ "$(nvram get "${INTERFACE}_bss_enabled")-$(nvram get ${INTERFACE}_lanaccess)" = "1-off" ]; then
        ebtables -t broute -A BROUTING -i $INTERFACE -j RESTRICT_LAN
    fi
done


As a bonus the single chain now gives a much more readable ebroute -t broute -L output.

Yeah not really sure why they allow UDP in the EBTABLES rules for GW2 and 3, possibly so you can stream from your phone on main LAN to your TV on IOT guest or something. For GW1 it is not an issue since it will hit IPTABLES and get denied there. Though I wonder if since it is passing between two different interfaces within the bridge if it does hit IPTABLES even though it is the same subnet. Haven't tested that, in theory it shouldn't hit IPTABLES but I'm not an expert on linux firewall, have just figured out enough to get my asus working how I want (guest able to print to main LAN but block all other, etc).

You could probably put some EBTABLES rules on the repeater to stop guests on that from talking to guests that hang off the main router, though AP isolation on the main router probably stops that anyway.

If the repeater mode supports AP isolation you can enable that there to stop guests from talking to each other when on the repeater too.

Keep in mind the BROUTING chain is special. "DROP" means send it to the interface (the wl or wds ones in this case) for routing. In this case, since the wl interface has no IP on it, it can't route, it blackholes and effectively does just become a drop rule. ACCEPT means bridge the traffic, in this case send to BR0. So in the way asus has implemented it, DROP and ACCEPT actually work as you'd expect. When sending to your new sub-chain, not sure if that behavior is carried over, I would assume so, not positive. But doesn't matter since it will work as DROP and ACCEPT either way for the reasons above.

Similar to deleting your BROUTING rule before adding, I'd probably delete your custom chain before adding too. Just so you don't end up with duplicate rules every time the firewall restarts.
EDIT just noticed you're flushing it first, never mind.

ebtables -t broute -L --Lc gives you counters which is handy too.
 
Keep in mind the BROUTING chain is special. "DROP" means send it to the interface (the wl or wds ones in this case) for routing. In this case, since the wl interface has no IP on it, it can't route, it blackholes and effectively does just become a drop rule. ACCEPT means bridge the traffic, in this case send to BR0. So in the way asus has implemented it, DROP and ACCEPT actually work as you'd expect. When sending to your new sub-chain, not sure if that behavior is carried over, I would assume so, not positive. But doesn't matter since it will work as DROP and ACCEPT either way for the reasons above.
Thank you for the insight!

Do you know if it's possible with ebtables to drop packets going from other interface to the guest/wds interface? With the current rules the guest can't send broadcasts but it will still receive them from other interfaces (asuswrt relies on client isolation to stop that which is moot here since it's across routers). I tried playing with the filter tables in ebtables but it didn't seem to work.

The proper solution is to move the wds to br1 (as you suggested) so that it's in a different subnet and broadcast domain. And it works but it doesn't seem very stable, a few times the interface was removed from the bridge by asuswrt. And there's no script to catch its creation. Maybe I have to use a cron that runs every minute and fix the bridges? I guess it wouldn't be too bad on such a beefy router?
 
Maybe I have to use a cron that runs every minute and fix the bridges? I guess it wouldn't be too bad on such a beefy router?

Something along those lines:

* * * * * fix-guest-networks-cron
Code:
#!/bin/sh
PREV_VALUE="$(cat /tmp/fix-guest-status 2> /dev/null)"
CURR_VALUE="$(brctl show)$(ebtables -t broute)"
if [ "$PREV_VALUE" != "$CURR_VALUE" ]; then
    /jffs/scripts/fix-guest-networks
    echo "$(brctl show)$(ebtables -t broute)" > /tmp/fix-guest-status
fi

Not terribly elegant but is there a better way to catch bridge changes made by asus?
 
Thank you for the insight!

Do you know if it's possible with ebtables to drop packets going from other interface to the guest/wds interface? With the current rules the guest can't send broadcasts but it will still receive them from other interfaces (asuswrt relies on client isolation to stop that which is moot here since it's across routers). I tried playing with the filter tables in ebtables but it didn't seem to work.

The proper solution is to move the wds to br1 (as you suggested) so that it's in a different subnet and broadcast domain. And it works but it doesn't seem very stable, a few times the interface was removed from the bridge by asuswrt. And there's no script to catch its creation. Maybe I have to use a cron that runs every minute and fix the bridges? I guess it wouldn't be too bad on such a beefy router?

If the interfaces are in the same bridge/subnet you're mostly limited to using ebtables, though for broadcasts I guess iptables may come into play, at least for ones sourcing from the router interface. Try using ebtables to block 255.255.255.255 (with no protocol specified) but you'd need to craft it in a way that it doesn't block broadcasts on your regular LAN.

Maybe it would be more prudent to try using Aimesh and finding a way to hide/remove your main SSID from the node?
 
Maybe it would be more prudent to try using Aimesh and finding a way to hide/remove your main SSID from the node?
That won't work for me because I'm using an AX55 as the repeater and there's no scripting support, but it might be a solution for others yes.
Something like
Code:
nvram set wl0_closed=0
nvram set wl1_closed=0

Would need a cron because aimesh propagates config every now and then.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top