What's new

YazFi YazFi possible to merge 2.4Ghz and 5Ghz as a single subnet?

  • 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!

BatKing

Occasional Visitor
Hi,

New AC68U YazFi user here and what a wonderful add-on. Just a question, is it possible to merge GuestNetwork's 2.4 and 5Ghz as single subnet? from the UI and Config, it seems each wifi 2.4Ghz and 5Ghz has to be separated subnet. My goal is each Guest network have both 2.4 and 5Ghz wifi and the 2 frequencies combine as single subnet so the clients on Guest1 can talk to each other even they are on different wifi frequency. Thanks.

Leon
 
Hi,

New AC68U YazFi user here and what a wonderful add-on. Just a question, is it possible to merge GuestNetwork's 2.4 and 5Ghz as single subnet? from the UI and Config, it seems each wifi 2.4Ghz and 5Ghz has to be separated subnet. My goal is each Guest network have both 2.4 and 5Ghz wifi and the 2 frequencies combine as single subnet so the clients on Guest1 can talk to each other even they are on different wifi frequency. Thanks.

Leon
you can make devices from one subnet communcate to the other subnet with static routes. If your only aim is to allow communication between the two subnets.
 
Not sure if adding following iptables rule in firewall-start script can work? I am not around the router currently, but will test this out when I can get my hand on the router again. Thanks.

Code:
iptables -I OrgVLANs -i wl0.1 -o wl1.1 -m state --state NEW,ESTABLISHED -m comment --comment "Join wl0.1 to wl1.1" -j ACCEPT
iptables -I OrgVLANs -i wl1.1 -o wl0.1 -m state --state NEW,ESTABLISHED -m comment --comment "Join wl1.1 to wl0.1" -j ACCEPT
 
Not sure if adding following iptables rule in firewall-start script can work? I am not around the router currently, but will test this out when I can get my hand on the router again. Thanks.

Code:
iptables -I OrgVLANs -i wl0.1 -o wl1.1 -m state --state NEW,ESTABLISHED -m comment --comment "Join wl0.1 to wl1.1" -j ACCEPT
iptables -I OrgVLANs -i wl1.1 -o wl0.1 -m state --state NEW,ESTABLISHED -m comment --comment "Join wl1.1 to wl0.1" -j ACCEPT
did this work for you?
 
did this work for you?
not sure if u see my other thread about my failed upgrade to 386.1. I didn't proceed the iptables test as I was thinking to go AiMesh2.0 and YazFi not ready for AiMesh2.0 last I heard. so I used my old scripts.

see below thread last post for my working scripts. I am still using basically the same script. but this only works for AiMesh1.0. 2.0 may also work but the bridge structure and Wireless interface naming all changed and 2.4 and 5Ghz itself already created in br1 and br2 separately alone (instead of all in br0 initially for AiMesh1.0.) so the scripts may work but needs to change for AiMesh 2.0. Please note, because I roll back to 384.19 I never test this script in AiMesh2.0

 
Last edited:
Is this still not possible?

My goal is to have my Guest network SSIDs work like a normal/primary SSID, where both 5ghz and 2.4ghz clients can talk to each other within that Guest network SSID. (send to printer, or send to Airplay/Chromecast without having chromecast playback controls/printer exposed to the primary SSID, for instance).
 
My goal is to have my Guest network SSIDs work like a normal/primary SSID, where both 5ghz and 2.4ghz clients can talk to each other within that Guest network SSID. (send to printer, or send to Airplay/Chromecast without having chromecast playback controls/printer exposed to the primary SSID, for instance).
Its possible you may be able to do what you seek with custom firewall rules. See this YazFi GitHub link:
 
I'm surprised such a basic feature/fundamental use-case is not accessible via a simple GUI-switch, quite frankly?
 
I'm sorry if I came across condescending, Yaz. I was just genuinely perplexed because I thought that running a regular guestnetwork-subnet with both 2.4 and 5ghz clients on it was what people were using this plugin for, thinking I must be overlooking something.

Are you planning to implement this feature in the future? I'd happily donate to a project that solves this problem.

(I was also a bit surprised that one has to set DNS address manually, but I found out that setting it to the primary-network (192.168.1.1) would mean that it follows the default DNS address on the router (dynamically). I think new users would appreciate the addition of a "Same as primary network" button. Just a tip).
 
(I was also a bit surprised that one has to set DNS address manually, but I found out that setting it to the primary-network (192.168.1.1) would mean that it follows the default DNS address on the router (dynamically). I think new users would appreciate the addition of a "Same as primary network" button. Just a tip).
You could also point the dns at the first address of that network, for instance if it is 192.168.2.0/24, the first address would be 192.168.2.1, which dnsmasq listens on this address as well allowing you to keep your subnets separate which would be the intended goal. By using the first address of the bridge(parent) network, you are in some ways bypassing the network you are intending to use.
 
Last edited:
I'm sorry if I came across condescending, Yaz. I was just genuinely perplexed because I thought that running a regular guestnetwork-subnet with both 2.4 and 5ghz clients on it was what people were using this plugin for, thinking I must be overlooking something.

Are you planning to implement this feature in the future? I'd happily donate to a project that solves this problem.

(I was also a bit surprised that one has to set DNS address manually, but I found out that setting it to the primary-network (192.168.1.1) would mean that it follows the default DNS address on the router (dynamically). I think new users would appreciate the addition of a "Same as primary network" button. Just a tip).
the main blocker is that each interface is set up on its own, so if you were to "link" i'd need to write the code that handles all the firewall rules to let the user's config work. this would be solved with bridging, but that's basically a full rewrite of YazFi.
plus, would i restrict it to 2.4-1 and 5-1 linking, what about the people that want to link 2.4-1 with 5-2? i guarantee that whatever i add, i'll always get someone asking when will X happen or why doesn't it do Y already :(
 
the main blocker is that each interface is set up on its own, so if you were to "link" i'd need to write the code that handles all the firewall rules to let the user's config work. this would be solved with bridging, but that's basically a full rewrite of YazFi.
plus, would i restrict it to 2.4-1 and 5-1 linking, what about the people that want to link 2.4-1 with 5-2? i guarantee that whatever i add, i'll always get someone asking when will X happen or why doesn't it do Y already :(
You could just make a function that treats each pair of networks as variable, but limiting it to being allowed to be used on only one pair of networks.
 
You could also point the dns at the first address of that network, for instance if it is 192.168.2.0/24, the first address would be 192.168.2.1, which dnsmasq listens on this address as well allowing you to keep your subnets separate which would be the intended goal. By using the first address of the bridge(parent) network, you are in some ways bypassing the network you are intending to use.
Not sure I understood what you mean here, sorry. They would only share DNS server, but the clients themselves would still not see each other?

the main blocker is that each interface is set up on its own, so if you were to "link" i'd need to write the code that handles all the firewall rules to let the user's config work. this would be solved with bridging, but that's basically a full rewrite of YazFi.
plus, would i restrict it to 2.4-1 and 5-1 linking, what about the people that want to link 2.4-1 with 5-2? i guarantee that whatever i add, i'll always get someone asking when will X happen or why doesn't it do Y already :(
Not sure why people would want to link 2.4-1 and 5-2, but speaking to my own use-case, I wish for the ability to share an internet connection with my neighbours where each have our own SSID in order to prevent the interference that occurs when sharing intranet, still having the option of running 2.4 on some units while 5ghz on others (for example, if you are streaming to a stationary unit @5ghz from a mobile unit with 2.4ghz because of connection issues @5ghz. Honestly thought this was the primary use-case behind YazFi.

But maybe there are other routers more suited for this kind of setup, like DD-WRT? A damn pity HND routers no longer support it.

An option is to run several routers with their own SSID connected to LAN in a primary router with WAN/internet controlling the QoS, but then you'll have lets say 3 routers in close proximity, each hogging a significant portion of the 2.4ghz network, as if that wasn't overfilled with second-door neighbours already.
I also don't know if QoS will run that well, having all the clients on the child routers router being mashed into one device on the primary router, constituting one "QoS slot" only given equal attention as each of the other clients connected directly to the primary router that each would have their own "QoS slot". If I had a subnetted guest-network, each client would receive equal attention because all the clients on the guest network would show up alongside the clients on the primary router.
 
Last edited:
Not sure I understood what you mean here, sorry. They would only share DNS server, but the clients themselves would still not see each other?
Traffic could still be seen as "leaking" into the other network even if communications between clients was not allowed. Typically a network 192.168.2.0/24 should not be looking to get request from address 192.168.1.1 even though the traffic may be allowed with the firewall. Especially if there are no intentions of these networks crossing paths, so to speak. If dnsmasq also listens on 192.168.2.1, request for 192.168.2.0/24 network would be better served from a local address( 192.168.2.1) than an address from a network not intending to be reached (192.168.1.1). I know you might not think about things on terms like this, but it could be said to be an arguably valid argument. Just like you wouldn't tell 192.168.1.0/24 to use a dns server that was being hosted on 192.168.2.0/24, unless you had a legitimate reason for wanting to go across the networks like that.
 
Traffic could still be seen as "leaking" into the other network even if communications between clients was not allowed. Typically a network 192.168.2.0/24 should not be looking to get request from address 192.168.1.1 even though the traffic may be allowed with the firewall. Especially if there are no intentions of these networks crossing paths, so to speak. If dnsmasq also listens on 192.168.2.1, request for 192.168.2.0/24 network would be better served from a local address( 192.168.2.1) than an address from a network not intending to be reached (192.168.1.1). I know you might not think about things on terms like this, but it could be said to be an arguably valid argument. Just like you wouldn't tell 192.168.1.0/24 to use a dns server that was being hosted on 192.168.2.0/24, unless you had a legitimate reason for wanting to go across the networks like that.
What this does reiterate, is the clear need for is a visible option that sets the DNS address to "same as primary network". It's a simple concept once you explain it, but before doing a few searches, I honestly thought I had to manually had to manually input the DNS address from the primary network, which would have caused downtime and headache if my ISP updated the DNS address without the Guest network(s) in question would not be able to fetch automatically.
 
What this does reiterate, is the clear need for is a visible option that sets the DNS address to "same as primary network". It's a simple concept once you explain it, but before doing a few searches, I honestly thought I had to manually had to manually input the DNS address from the primary network, which would have caused downtime and headache if my ISP updated the DNS address without the Guest network(s) in question would not be able to fetch automatically.
I think of it in terms of who is acting DHCP addressing host for the network. 192.168.2.0/24 is providing dhcp options for for devices connecting to it, and not 192.168.1.1. Same as vice versa. The fact that users are allowed to "define" a DNS here simply means if I put 8.8.8.8 or 9.9.9.9, the device does not talk back to the network scope (192.168.2.0/24) for DNS instead it reaches out to 8.8.8.8 directly or 9.9.9.9 directly, thus skipping the middleman host. Kind of like doing the same on the DHCP for the router does. I honestly think that is why it is left blank or for you to decide on what you want to do. In most scenarios where clients do not communicate on the same network segment, we would be concerned with them sharing the same DNS middle man addresses such as 192.168.1.1 or 192.168.2.1 unless there was a specific interest for doing such. We would want them to resolve out directly to the DNS server skipping the local DNS instance, so other users would not be able to resolve a client on the same network segment.

And these I think are @Jack Yaz Intentions and why I support his implementation.
 

Latest threads

Sign Up For SNBForums Daily Digest

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