Guest Wifi changes pre/post 386.x FW

[bengalih]

In another post a user attempting to assist me in troubleshooting what I believe to be an unrelated problem made comments about my guest WiFi setup not being proper and that changes were introduced in the 386 FW that totally change how things are configured.

Now my current configuration was, I believe done pre 386 (I believe in 2019 or prior, maybe on 384?). However I rebuilt my router a year or so ago from scratch and manually recreated my configurations including my Guest Wifi setup.

I would like to explain what my goals were and how I configured it so I can get some better insight as to why my configuration might not be "proper" and some explanation as to how to convert it to a more "proper" configuration and what things, if any, I need to watch out for that might work differently. IOW, critique my configuration and tell me why I shouldn't be doing this (and just as important, how/why can/should I change it).

My needs are quite simple. I have 3 guest WiFi. One each of a 2.5 and a 5 that is used for visitors. The third is a 2.4 for IOT devices with a hidden SSID.
There are a few things tweaked on the IOT network, but the basic idea of all 3 was to allow internet access but not access to my internal LAN.
The way I currently have it configured I believe clients on all 3 networks can access each other (including the IOT), and while that might not be ideal, I haven't really cared about that and if I chose to I believe I can update my rules to fix that easily enough.

My LAN network and router IP is 10.10.10.1/24.
Device is RT-AC68U

These were my steps to configure the Guest WiFi networks.

1) Via the GUI > Guest Network. I simply clicked on "enable" for the first two 2.4 and the first 5 network and configured the options in the GUI. The "Access Intranet" option is disabled for all of them.
2) Found the interface names with ifconfig and then for each bound an IP to each interface:

ifconfig wl0.1 172.20.20.1 netmask 255.255.255.0
ifconfig wl1.1 172.20.30.1 netmask 255.255.255.0
ifconfig wl0.2 10.10.20.1 netmask 255.255.255.0

As a point of info here. I do/did not have my Asus do any DHCP for my LAN. DHCP was/is disabled in the GUI and all my main LAN/Wifi clients (10.10.10.0/24) get their DHCP info from a Windows DHCP server on the internal network. As I did not want the external clients accessing anything internal, I defined dhcp-ranges for each Guest WiFi in my dnsmasq. For example, my 5 GHz network is defined as:

interface=wl1.1
dhcp-range=wl1.1,172.20.30.150,172.20.30.199,255.255.255.0,86400s
dhcp-option=wl1.1,3,172.20.30.1
dhcp-option=wl1.1,6,1.1.1.1,1.0.0.1

My last issue was to enable the proper routing on these wl interfaces. At the time the method I found to use had me utilize ebtables by creating the following:

/usr/sbin/ebtables -t broute -I BROUTING -p arp -i wl1.1 -j DROP
/usr/sbin/ebtables -t broute -I BROUTING -p ipv4 -i wl1.1 -j DROP
/usr/sbin/ebtables -t broute -I BROUTING -p ipv6 -i wl1.1 -j DROP

My understanding is that the "DROP" on these kicks these packets from being bridged and up to the routing table.
However at this point the clients are still unable to actually get to the Asus interface to get an IP from the dnsmasq server.
To fix this I added:

/usr/sbin/iptables -I INPUT -i wl1.1 -j ACCEPT

That allowed access into the server itself, but the packets were not routed to the Internet. So I then add:

/usr/sbin/iptables -I FORWARD -i wl1.1 -j ACCEPT

Finally, to protect these clients from accessing my Ausus local interface or getting into the local network I also add:

/usr/sbin/iptables -I FORWARD -i wl1.1 -d 10.10.10.1/24 -j DROP
/usr/sbin/iptables -I INPUT -i wl1.1 -d 10.10.10.1/24 -j DROP

So my complete set of entries for each wl interface looks like:

/usr/sbin/ebtables -t broute -I BROUTING -p arp -i wl1.1 -j DROP
/usr/sbin/ebtables -t broute -I BROUTING -p ipv4 -i wl1.1 -j DROP
/usr/sbin/ebtables -t broute -I BROUTING -p ipv6 -i wl1.1 -j DROP

/usr/sbin/iptables -I FORWARD -i wl1.1 -j ACCEPT
/usr/sbin/iptables -I FORWARD -i wl1.1 -d 10.10.10.1/24 -j DROP
/usr/sbin/iptables -I INPUT -i wl1.1 -j ACCEPT
/usr/sbin/iptables -I INPUT -i wl1.1 -d 10.10.10.1/24 -j DROP

Everything works as I intend and doesn't appear to have any negative consequences to anything else I've configured on the network.

So. Is there anything inherently wrong with how I have it configured? I suppose there might be other configurations that work, and maybe some that are preferred for a more complex implementation.
Can/should I change this to some newer "386 fw compatible way"? What would I benefit? What might I lose or have issues with compared to the current way I do things?

thanks.

 

[drinkingbird]

In another post a user attempting to assist me in troubleshooting what I believe to be an unrelated problem made comments about my guest WiFi setup not being proper and that changes were introduced in the 386 FW that totally change how things are configured.

Now my current configuration was, I believe done pre 386 (I believe in 2019 or prior, maybe on 384?). However I rebuilt my router a year or so ago from scratch and manually recreated my configurations including my Guest Wifi setup.

I would like to explain what my goals were and how I configured it so I can get some better insight as to why my configuration might not be "proper" and some explanation as to how to convert it to a more "proper" configuration and what things, if any, I need to watch out for that might work differently. IOW, critique my configuration and tell me why I shouldn't be doing this (and just as important, how/why can/should I change it).

My needs are quite simple. I have 3 guest WiFi. One each of a 2.5 and a 5 that is used for visitors. The third is a 2.4 for IOT devices with a hidden SSID.
There are a few things tweaked on the IOT network, but the basic idea of all 3 was to allow internet access but not access to my internal LAN.
The way I currently have it configured I believe clients on all 3 networks can access each other (including the IOT), and while that might not be ideal, I haven't really cared about that and if I chose to I believe I can update my rules to fix that easily enough.

My LAN network and router IP is 10.10.10.1/24.
Device is RT-AC68U

These were my steps to configure the Guest WiFi networks.

1) Via the GUI > Guest Network. I simply clicked on "enable" for the first two 2.4 and the first 5 network and configured the options in the GUI. The "Access Intranet" option is disabled for all of them.
2) Found the interface names with ifconfig and then for each bound an IP to each interface:

ifconfig wl0.1 172.20.20.1 netmask 255.255.255.0
ifconfig wl1.1 172.20.30.1 netmask 255.255.255.0
ifconfig wl0.2 10.10.20.1 netmask 255.255.255.0

As a point of info here. I do/did not have my Asus do any DHCP for my LAN. DHCP was/is disabled in the GUI and all my main LAN/Wifi clients (10.10.10.0/24) get their DHCP info from a Windows DHCP server on the internal network. As I did not want the external clients accessing anything internal, I defined dhcp-ranges for each Guest WiFi in my dnsmasq. For example, my 5 GHz network is defined as:

interface=wl1.1
dhcp-range=wl1.1,172.20.30.150,172.20.30.199,255.255.255.0,86400s
dhcp-option=wl1.1,3,172.20.30.1
dhcp-option=wl1.1,6,1.1.1.1,1.0.0.1

My last issue was to enable the proper routing on these wl interfaces. At the time the method I found to use had me utilize ebtables by creating the following:

/usr/sbin/ebtables -t broute -I BROUTING -p arp -i wl1.1 -j DROP
/usr/sbin/ebtables -t broute -I BROUTING -p ipv4 -i wl1.1 -j DROP
/usr/sbin/ebtables -t broute -I BROUTING -p ipv6 -i wl1.1 -j DROP

My understanding is that the "DROP" on these kicks these packets from being bridged and up to the routing table.
However at this point the clients are still unable to actually get to the Asus interface to get an IP from the dnsmasq server.
To fix this I added:

/usr/sbin/iptables -I INPUT -i wl1.1 -j ACCEPT

That allowed access into the server itself, but the packets were not routed to the Internet. So I then add:

/usr/sbin/iptables -I FORWARD -i wl1.1 -j ACCEPT

Finally, to protect these clients from accessing my Ausus local interface or getting into the local network I also add:

/usr/sbin/iptables -I FORWARD -i wl1.1 -d 10.10.10.1/24 -j DROP
/usr/sbin/iptables -I INPUT -i wl1.1 -d 10.10.10.1/24 -j DROP

So my complete set of entries for each wl interface looks like:

/usr/sbin/ebtables -t broute -I BROUTING -p arp -i wl1.1 -j DROP
/usr/sbin/ebtables -t broute -I BROUTING -p ipv4 -i wl1.1 -j DROP
/usr/sbin/ebtables -t broute -I BROUTING -p ipv6 -i wl1.1 -j DROP

/usr/sbin/iptables -I FORWARD -i wl1.1 -j ACCEPT
/usr/sbin/iptables -I FORWARD -i wl1.1 -d 10.10.10.1/24 -j DROP
/usr/sbin/iptables -I INPUT -i wl1.1 -j ACCEPT
/usr/sbin/iptables -I INPUT -i wl1.1 -d 10.10.10.1/24 -j DROP

Everything works as I intend and doesn't appear to have any negative consequences to anything else I've configured on the network.

So. Is there anything inherently wrong with how I have it configured? I suppose there might be other configurations that work, and maybe some that are preferred for a more complex implementation.
Can/should I change this to some newer "386 fw compatible way"? What would I benefit? What might I lose or have issues with compared to the current way I do things?

thanks.

I'll let others deal with this but 3 comments:

1. You likely have a br1 with an IP and DHCP range associated, with wl0.1 under it with another IP and DHCP range associated, which could certainly be problematic.
2. The new code base does a lot of what you're doing for you, in a much cleaner and simpler way, and can be easily modified to tweak to your liking.
3. See this link for a list of all the interfaces the AC68U should have on 386 code base to get an idea of what I'm talking about - https://www.snbforums.com/threads/snmp-byte-counters-on-an-ac1900p-rt-ac68u.84266/#post-831383. Ideally, IPs and DHCP should only be put on main interfaces (ehtx or brx).

Well I guess 4 comments - since you're familiar with IPtables, why not just block DHCP inbound to the router (both UDP initial requests and TCP renewal requests) from your main LAN to resolve your other issue? Should not impact RA solicitations or advertisements.

 

[L&LD]

Using a hidden SSID will cause problems. Eventually.

 

[ColinTaylor]

I suggest you update your signature as you don't appear to be using firmware 384.19 anymore.

 

[bengalih]

I'll let others deal with this but 3 comments:

1. You likely have a br1 with an IP and DHCP range associated, with wl0.1 under it with another IP and DHCP range associated, which could certainly be problematic.

I do have a br1 interface defined:

br1       Link encap:Ethernet  HWaddr 1C:B7:2C:XX:XX:XX
          inet addr:192.168.101.1  Bcast:192.168.101.255  Mask:255.255.255.0
          inet6 addr: feXX::XXXX:2XXX:fXXX:4XXX/64 Scope:Link

And I do have a wl0.1 interface - it is the one I defined in my commands above:

wl0.1     Link encap:Ethernet  HWaddr 1C:B7:2C:XX:XX:XX
          inet addr:172.20.20.1  Bcast:172.20.20.255  Mask:255.255.255.0
          inet6 addr: feXX::XXXX:2XXX:fXXX:4XXX/64 Scope:Link

I don't know what you mean when you say "under it" unless you mean simply listed later in the ifconfig file...then yes.
Why specifically is this problematic? Your linked post is informational - assuming it is all correct (as you even state it is just your best guess, and I don't see any official word specifying this.). Assuming it is, how is this problematic in 386 compared to how it was in 384?

2. The new code base does a lot of what you're doing for you, in a much cleaner and simpler way, and can be easily modified to tweak to your liking.

Ok - but I see no instructions on how to configure it. It sounds like what I need to do is remove all the configuration commands I discussed above (easy enough) then go and delete my 3 networks and recreate them all on either 2 or 3.
After that I have nothing which describes how to configure my DHCP and routing requirements in this configuration.
And what of the Guest Wireless 1 networks, are they basically useless now?

3. See this link for a list of all the interfaces the AC68U should have on 386 code base to get an idea of what I'm talking about - https://www.snbforums.com/threads/snmp-byte-counters-on-an-ac1900p-rt-ac68u.84266/#post-831383. Ideally, IPs and DHCP should only be put on main interfaces (ehtx or brx).

Thanks, yes this is somewhat helpful (again, assuming it is accurate), but it is still difficult to understand without a comparison to how it was in 384. I'm trying to understand why what I did was right in 384 (assuming it was) and why it is wrong now.

Well I guess 4 comments - since you're familiar with IPtables, why not just block DHCP inbound to the router (both UDP initial requests and TCP renewal requests) from your main LAN to resolve your other issue? Should not impact RA solicitations or advertisements.

That could work, but seems pretty hacky to me. Remember, assuming that the message is normal for my configuration I'm not actually that concerned about it as I can always redirect the logging to another file. My main concern was that my dnsmasq configuration was somehow not optimal, but it seems to me more that dnsmasq just doesn't properly know how to log in that situation. But I don't want to engage on that topic in this thread any further.

thx

 

[drinkingbird]

I do have a br1 interface defined:

br1       Link encap:Ethernet  HWaddr 1C:B7:2C:XX:XX:XX
          inet addr:192.168.101.1  Bcast:192.168.101.255  Mask:255.255.255.0
          inet6 addr: feXX::XXXX:2XXX:fXXX:4XXX/64 Scope:Link

And I do have a wl0.1 interface - it is the one I defined in my commands above:

wl0.1     Link encap:Ethernet  HWaddr 1C:B7:2C:XX:XX:XX
          inet addr:172.20.20.1  Bcast:172.20.20.255  Mask:255.255.255.0
          inet6 addr: feXX::XXXX:2XXX:fXXX:4XXX/64 Scope:Link

Do a "brctl show". You'll see that wl0.1 is a sub-interface mapped under br1 (and wl1.1 is a sub-interface of br2)

So you essentially have two IPs and two DHCP ranges assigned to the same interface (br1). Should be obvious how that could be problematic, maybe it works now, maybe it won't when something changes. Maybe it appears to work but is causing other glitches that you can't explain or don't realize are related.

The list in the post is accurate and has been confirmed by others, the only thing that seems to differ is that some people have a "vlan2" software interface for the WAN while others don't. Not sure if that depends on hardware revision or something else like IPTV being in use etc. But it was intended to show you how the interfaces are now laid out on 386 code base to point you in the right direction.

The behavior of 384 is the same as under the "EDIT" at the bottom of that post. No VLAN 50x, no br1 or br2, no 192.168 subnets, wl0.1 and wl1.1 are under the br0 interface, they use the same subnet as the main LAN, and iptables prevents communication to the main LAN if "access LAN" is not enabled. Or in other words, on 384 all 3 Guest Wireless used the model that only Guest Wireless 2 and 3 now use on 386.

So when you compare GW1 on 384 and 386, you can see the way to do it is to create additional bridges when you want additional subnets and DHCP ranges, not assign IPs to individual virtual interfaces under a bridge that already has an IP and DHCP. That's how it should have been done under 384 as well, since at that point your GW1 would have been under BR0 which contains your LAN IP.

 

[bengalih]

Using a hidden SSID will cause problems. Eventually.

a) Hasn't up to this point for my needs, nor indeed have I ever had a problem with one (not that I have used them frequently). I am not using it as a security through obscurity, just to remove an additional network from the list of those in my home to make it easier for guests to connect to the right one. The only devices using it are a handful of IOT devices that I configure directly onto the network. All these seem to support connecting to it without issue. The only inconvenience is having to type in the SSID manually when I configure them initially.

b) While I appreciate this as per my invitation of "critique my configuration", it doesn't provide any information as to why you believe it is problematic and therefore doesn't add value (for me at least). Additionally, this was a minor point of my overall setting and is really irrelevant in the larger context of the question I'm asking.

I'm happy for you to provide your reasoning, and I will certainly take it into consideration. However for the main purposes of my question (and yes I realize I didn't place any caveats on what to "critique"), this is not really the area I am concerned about, but rather the interfaces and routing.

thx

 

[bengalih]

Do a "brctl show". You'll see that wl0.1 is a sub-interface mapped under br1 (and wl1.1 is a sub-interface of br2)

....

Ok, I'm starting to see a bit about what you are saying. I need to go over this a few times (probably in the morning when I'm fresh) before I try to reconfigure.

But I'm a bit confused by what you are saying since all three interfaces: br0,1,2 all have IP addresses defined (it seems the br1,2 192.x networks are hard coded even if you are not using them, and br0 has the LAN IP). But all the wlX interfaces in use (i.e. configured by the GUI) show up under at least one of those brX.

So are you saying that you need to break those wlX interfaces out and put them under a new bridge that doesn't have an IP assigned?
If so, is there a guide on that syntax?

thanks.

(p.s. tomorrow I'll probably remove my current guest configuration and test the DHCP issue. I don't expect it to fix it, but at least I'll be at a blank slate to try to reconfigure).

 

[drinkingbird]

Ok, I'm starting to see a bit about what you are saying. I need to go over this a few times (probably in the morning when I'm fresh) before I try to reconfigure.

But I'm a bit confused by what you are saying since all three interfaces: br0,1,2 all have IP addresses defined (it seems the br1,2 192.x networks are hard coded even if you are not using them, and br0 has the LAN IP). But all the wlX interfaces in use (i.e. configured by the GUI) show up under at least one of those brX.

So are you saying that you need to break those wlX interfaces out and put them under a new bridge that doesn't have an IP assigned?
If so, is there a guide on that syntax?

thanks.

(p.s. tomorrow I'll probably remove my current guest configuration and test the DHCP issue. I don't expect it to fix it, but at least I'll be at a blank slate to try to reconfigure).

Another thing I noticed from your earlier post, your br1 and wl0.1 have the same IPv6 address. That's definitely not good. May be why some of the commands you tried related to RA and DHCPv6 earlier did not work.

Regarding the quoted post above:
What I'm saying is if you take the factory configs (remove your script), you can make use of the existing bridges that it creates for you, move the sub-interfaces around as needed (for example you could use br1 for both your wl0.1 and wl1.1 which makes sense, use br2 for wl0.2 and wl1.2, and if you want a 3rd isolated subnet then you'd need to create a br3 for wl0.3 and wl1.3). You can change the IP assigned or use the defaults, either way. You do not assign any IP or DHCP configs to the wlx.x interfaces at all. They are just layer 2 interfaces under the layer 3 bridge interface.

br0 along with your main wifi (eth1 and eth2) and wired LAN (vlan1) will be configured via the gui as normal, nothing changes there.

To lay it out - below is what you should have with factory configs and all 3 guest wireless enabled (with access LAN disabled on GW #1):

1. br0-10.10.10.1/24 which you set in the GUI. DHCP scope is also configured in the GUI.
   1. vlan1 (your physical ports)
   2. eth1 - main wifi 2.4
   3. eth2 - main wifi 5
   4. wl0.2 - 2.4ghz guest wireless 2 - can easily move to br1 or br2 or a new br3
   5. wl1.2 - 5ghz guest wireless 2 - can move
   6. wl0.3 - 2.4ghz guest wireless 3 -can move
   7. wl1.3 - 2.4ghz guest wireless 3 - can move
2. br1 - 192.168.101.1/24 - can be changed via a script or just use that one. DHCP scope is hardcoded but can be changed with dnsmasq.postconf
   1. wl0.1 - 2.4ghz guest wireless 1
   2. several ethx.501 interfaces which are just used for aimesh, not really relevant here (can also be used for mapping wired ports into guest networks which is handy)
      1. Actually since VLAN 501 and 502 (br1 and 2) are sent tagged out all LAN ports, you could configure VLAN 501 and 502 on your DHCP server if its NIC supports VLANs, and move all your DHCP off the router.
3. br2 - 192.168.102.1/24 - same as above regarding IP and DHCP
   1. wl1.1 - 5ghz guest wireless 1
   2. several ethx.502 interfaces, again, not relevant here

So you can move wl 1.1 up to br1 so those both share a subnet (makes sense anyway, not sure why they split them up)

Then br2 is free to take one or both of your other guest networks

You'll have to look through IPtables and see if you need to update any of the rules when you make these changes but from what I can see the rules are all applied to the brx interfaces so should be ok.

If needed, can create br3. But if you have two guest networks that you don't care if they share a subnet, can just put 4 interfaces under br1 or br2. I believe all clients will be isolated from each other still, but again need to check the iptables rules to see how those client isolation rules are built, or it may just be using AP isolation to prevent them from seeing each other. Have not looked into it. Or if you don't care about client isolation within/between those guest networks, then no need to worry about it.

The nice thing about br1 and 2 is that the main LAN can access them, and they can respond, but they cannot initiate to the main LAN. Have found this actually rather handy, I can mirror my phone on the main LAN to TV on the IOT guest wireless 1. As opposed to GW2 and 3 default behavior under br0 which the IPtables rules block both directions. Once you move them to br1 or 2 they should adopt those rules and have that same behavior.

# iptables --list --verbose | grep -i br0
433K 125M PTCSRVWAN all -- !br0 any anywhere anywhere
40057 4719K PTCSRVLAN all -- br0 any anywhere anywhere
40057 4719K ACCEPT all -- br0 any anywhere anywhere state NEW
0 0 other2wan all -- !br0 eth0 anywhere anywhere
0 0 ACCEPT all -- br0 br0 anywhere anywhere
31183 8757K ACCEPT all -- br0 any anywhere anywhere
# iptables --list --verbose | grep -i br1
247 16622 ACCEPT udp -- br1 any anywhere anywhere udp dpt:domain
10 3338 ACCEPT udp -- br1 any anywhere anywhere udp dpt:bootps
0 0 ACCEPT udp -- br1 any anywhere anywhere udp dpt:bootpc
0 0 DROP all -- br1 any anywhere anywhere
377 107K WGNPControls all -- br1 any anywhere anywhere
377 107K ACCEPT all -- br1 eth0 anywhere anywhere
# iptables --list --verbose | grep -i br2
0 0 ACCEPT udp -- br2 any anywhere anywhere udp dpt:domain
0 0 ACCEPT udp -- br2 any anywhere anywhere udp dpt:bootps
0 0 ACCEPT udp -- br2 any anywhere anywhere udp dpt:bootpc
0 0 DROP all -- br2 any anywhere anywhere
0 0 WGNPControls all -- br2 any anywhere anywhere
0 0 ACCEPT all -- br2 eth0 anywhere anywhere


Moving virtual interfaces between bridges syntax is
brctl delif br0 wl0.1
brctl delif br0 wl1.1
brctl addif br1 wl0.1
brctl addif br1 wl1.1
you also should look through all the nvram variables that contain "ifname" and update those, they are used to generate some iptables rules I believe. Honestly I'm not positive what those variables do, some say they are used for generating iptables rules, they may also get used in the GUI for client list or traffic monitor. Maybe @RMerlin can shed some insight there.

Creating a new bridge is a bit more involved, but not bad, and you can basically mirror what has been done for br1 and br2
brctl addbr br3
ifconfig br3 up
Then need to replicate the iptables rules above for br3 and potentially add some nvram variables too (though if those nvram variables are called by GUI code, creating a new one for LAN3 or whatever wouldn't work, probably have to just put it under one of the existing variables like LAN2).

some have found they need to do "killall eapd" followed by "eapd" but I never found it needed. May be only on the HND based routers.

 

[L&LD]

@bengalih, thank you for your response.

For your technical questions, others like @drinkingbird are better suited to answer those questions, but what I like to do is start the network configuration properly, from the very start, and from the smallest details. This has served me and my customers very well.

I have learned this past decade in the networking field that following best practices, no matter how seemingly benign they may seem, goes a long way toward the most stable and performant network experience possible.

You can use Better Search at the top of the page to see why I suggest not using a hidden SSID if you like. but the reasons for 'why', are stated above.

To be clear, these are not simply my best practices. I have collected these all from the posts on these forums (I have read every single post here) and condensed them where I could. See the links below and compare them to how your network is set up if you like.

Am I all set to start fresh with the latest stable release? And a request for L&LD...

After creating the checklists two weeks ago to save the pages with settings, I've made all the screenshots (I think at least) of all the relevant guides written by @L&LD and the very useful tip by @netware5. The only thing is, those guides are great, except when you'll be offline at least for a...

www.snbforums.com

Merlin on ASUS ax86U Question

I have an ASUS AX86U and contemplating the installation of Merlin firmware. The DDNS settings on the AX86U are limited to select dns providers. If I install Merlin, will I have more flexability (choices) with the DDNS Settings? Thanks in advance!

www.snbforums.com

L&LD

www.snbforums.com

[Wireless Router] When Standard Reset Isn’t Working: Hard Factory Reset - Models list | Official Support | ASUS Global

 

[ColinTaylor]

You can use Better Search at the top of the page to see why I suggest not using a hidden SSID if you like.

Why not post a link to it rather than having to search through your 21,000+ posts?

but the reasons for 'why', are stated above.

No they weren't.

 

[L&LD]

Once again, you're misunderstanding my post. I didn't state that I wrote the reasons for no hidden SSID, a search will find them.

Yes, I stated my reasons. Your issue if you don't like/agree with them.

 

[ColinTaylor]

Once again, you're misunderstanding my post.

Apparently so.

I didn't state that I wrote the reasons for no hidden SSID, a search will find them.

And I asked you to provide a link rather than the OP having to sift through 21,000+ posts. If it's so easy for you to find the relevant post please post a link to it.

Yes, I stated my reasons. Your issue if you don't like/agree with them.

You just said in the previous sentence "I didn't state that I wrote the reasons for no hidden SSID". I can't agree or disagree with your reasons if I don't know what they are.

 

[L&LD]

You really find me that hard to understand, huh?

Here's a search for you.

Advanced search results

www.snbforums.com

My reasons are stated, yes. However, I didn't say that "I" state the reasons for no hidden SSIDs. These are not mutually exclusive. Please try to understand what I'm posting, instead of just spinning parts of what I write to amuse yourself.

 

[ColinTaylor]

You really find me that hard to understand, huh?

Here's a search for you.

Advanced search results

www.snbforums.com

I've just read through those posts and can't find anything that would explain your statement "Using a hidden SSID will cause problems."

 

[L&LD]

Then, I can't help you any further.