wanted: vlan for AC56U in AP-Mode

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

Bob.Dig

Regular Contributor
@grifo It hasn't worked out.
Code:
#!/bin/sh
robocfg vlan 201 ports "4t 5t"
vconfig add eth0 201
ifconfig vlan201 up

robocfg vlan 199 ports "0t 4t"
vconfig add eth0 199
ifconfig vlan199 up

brctl addbr br1
brctl delif br0 wl0.1
brctl addif br1 vlan201
brctl addif br1 wl0.1
ifconfig br1 up

nvram set lan_ifnames="vlan1 eth1 eth2"
nvram set lan_ifname="br0"
nvram set lan1_ifnames="vlan201 wl0.1"
nvram set lan1_ifname="br1"

nvram commit
killall eapd
eapd
I had hoped I could just change the virtual NIC driver and do one change in the real NIC, like it is described here, but had no success. Now I probably have to install the realtek vlan software to get this going, although it might not support having no vlan...
 
Last edited:

grifo

Senior Member
Yeah Realtek NICs have a reputation of not so great VLAN support.

By the way, just the robocfg line should in fact be enough for this to work, you can try it after you've sorted your PC's NIC.
Code:
robocfg vlan 199 ports "0t 4t"
 

Bob.Dig

Regular Contributor
Managed to get it working with some help.
I had to install Hyper-V to later use their vswitch with VMware Workstation... sounds crazy, right?
With an intel NIC I would be able to use their vlan virtual NICs instead of going with hyper-v ones. With realteks own solution, I couldn't get it to work with VMware Workstation.

Dear @grifo,
I would like to create a second guestnetwork with vlan id 202. Do I have to create a second bridge (br2) like so?
Code:
#!/bin/sh
robocfg vlan 199 ports "0t 4t"
robocfg vlan 201 ports "4t 5t"
robocfg vlan 202 ports "4t 5t"
vconfig add eth0 201
vconfig add eth0 202
ifconfig vlan201 up
ifconfig vlan202 up

brctl addbr br1
brctl delif br0 wl0.1
brctl addif br1 vlan201
brctl addif br1 wl0.1
ifconfig br1 up

brctl addbr br2
brctl delif br0 wl0.2
brctl addif br2 vlan202
brctl addif br2 wl0.2
ifconfig br2 up

nvram set lan_ifnames="vlan1 eth1 eth2"
nvram set lan_ifname="br0"
nvram set lan1_ifnames="vlan201 wl0.1"
nvram set lan1_ifnames="vlan202 wl0.2"
nvram set lan1_ifname="br1"
nvram set lan1_ifname="br2"

nvram commit
killall eapd
eapd
It is working. Something to optimize?
 
Last edited:

grifo

Senior Member
Yeah it looks ok, just the nvram set lan1_ifname should be nvram set lan2_ifname for the second bridge interfaces.
Code:
nvram set lan2_ifnames="vlan202 wl0.2"
nvram set lan2_ifname="br2"
 

Bob.Dig

Regular Contributor
@grifo, thanks, this also works. :)
Interesting that it seems to work anyway.
Code:
#!/bin/sh
robocfg vlan 199 ports "0t 4t"
robocfg vlan 201 ports "4t 5t"
robocfg vlan 202 ports "4t 5t"
vconfig add eth0 201
vconfig add eth0 202
ifconfig vlan201 up
ifconfig vlan202 up

brctl addbr br1
brctl delif br0 wl0.1
brctl addif br1 vlan201
brctl addif br1 wl0.1
ifconfig br1 up

brctl addbr br2
brctl delif br0 wl0.2
brctl addif br2 vlan202
brctl addif br2 wl0.2
ifconfig br2 up

nvram set lan_ifnames="vlan1 eth1 eth2"
nvram set lan_ifname="br0"
nvram set lan1_ifnames="vlan201 wl0.1"
nvram set lan2_ifnames="vlan202 wl0.2"
nvram set lan1_ifname="br1"
nvram set lan2_ifname="br2"

nvram commit
killall eapd
eapd
 

grifo

Senior Member
Yep, the most important parts for it to work are the ones above the nvram set lines.
 

Bob.Dig

Regular Contributor
Dear @grifo, I wanted to consolidate my networks. I removed vlan 199 and also added a 5GHz for vlan 201 and added one dedicated Port to vlan 202.
And with the latter I have problems. First, everything looked fine. But when I restarted the Asus again, the device on the Port lost its vlan 202.

I then added the vlan1 thingy, but after a second reboot, again the port lost its vlan 202.
I really don't get it, why it is always working for the first time...

Is there something I can do about it? Did I missed something? Also why a dedicated vlan for one port seemed to worked fine but having it together with the wifi is not?

Code:
#!/bin/sh
robocfg vlan 1 ports "0 1 2 4 5t"
robocfg vlan 201 ports "4t 5t"
robocfg vlan 202 ports "3 4t 5t"
vconfig add eth0 201
vconfig add eth0 202
ifconfig vlan201 up
ifconfig vlan202 up

brctl addbr br1
brctl delif br0 wl0.1
brctl delif br0 wl1.1
brctl addif br1 vlan201
brctl addif br1 wl0.1
brctl addif br1 wl1.1
ifconfig br1 up

brctl addbr br2
brctl delif br0 wl0.2
brctl addif br2 vlan202
brctl addif br2 wl0.2
ifconfig br2 up

nvram set lan_ifnames="vlan1 eth1 eth2"
nvram set lan_ifname="br0"
nvram set lan1_ifnames="vlan201 wl0.1 wl1.1"
nvram set lan2_ifnames="vlan202 wl0.2"
nvram set lan1_ifname="br1"
nvram set lan2_ifname="br2"

nvram commit
killall eapd
eapd
Code:
Jan  1 01:00:22 custom_script: Running /jffs/scripts/services-start
Jan  1 01:00:22 disk_monitor: be idle
Jan  1 01:00:22 kernel: device wl0.1 left promiscuous mode
Jan  1 01:00:22 kernel: br0: port 4(wl0.1) entering forwarding state
Jan  1 01:00:22 kernel: device wl1.1 left promiscuous mode
Jan  1 01:00:22 kernel: br0: port 6(wl1.1) entering forwarding state
Jan  1 01:00:22 kernel: device vlan201 entered promiscuous mode
Jan  1 01:00:22 kernel: device wl0.1 entered promiscuous mode
Jan  1 01:00:22 kernel: device wl1.1 entered promiscuous mode
Jan  1 01:00:22 kernel: br1: port 3(wl1.1) entering learning state
Jan  1 01:00:22 kernel: br1: port 3(wl1.1) entering learning state
Jan  1 01:00:22 kernel: br1: port 2(wl0.1) entering learning state
Jan  1 01:00:22 kernel: br1: port 2(wl0.1) entering learning state
Jan  1 01:00:22 kernel: br1: port 1(vlan201) entering learning state
Jan  1 01:00:22 kernel: br1: port 1(vlan201) entering learning state
Jan  1 01:00:22 kernel: device wl0.2 left promiscuous mode
Jan  1 01:00:22 kernel: br0: port 5(wl0.2) entering forwarding state
Jan  1 01:00:22 kernel: device vlan202 entered promiscuous mode
Jan  1 01:00:22 kernel: device wl0.2 entered promiscuous mode
Jan  1 01:00:22 kernel: br2: port 2(wl0.2) entering learning state
Jan  1 01:00:22 kernel: br2: port 2(wl0.2) entering learning state
Jan  1 01:00:22 kernel: br2: port 1(vlan202) entering learning state
Jan  1 01:00:22 kernel: br2: port 1(vlan202) entering learning state
Sep  6 12:45:19 rc_service: ntp 558:notify_rc restart_diskmon
Sep  6 12:45:19 ntp: NTP update successful after 1 attempt(s)
Sep  6 12:45:19 disk_monitor: be idle
Sep  6 12:45:30 kernel: br1: port 3(wl1.1) entering forwarding state
Sep  6 12:45:30 kernel: br1: port 2(wl0.1) entering forwarding state
Sep  6 12:45:30 kernel: br1: port 1(vlan201) entering forwarding state
Sep  6 12:45:30 kernel: br2: port 2(wl0.2) entering forwarding state
Sep  6 12:45:30 kernel: br2: port 1(vlan202) entering forwarding state
Sep  6 12:45:53 crond[584]: time disparity of 5092485 minutes detected
 
Last edited:

grifo

Senior Member
It shouldn't make a difference whether the port is in the same vlan as the wifi bridge or on one of its own. Can you post robocfg show after a reboot?
 

Bob.Dig

Regular Contributor
@grifo So second try:
Code:
#!/bin/sh
robocfg vlan 1 ports "1 2 3 4 5t"
robocfg vlan 201 ports "4t 5t"
robocfg vlan 202 ports "0 4t 5t"
vconfig add eth0 201
vconfig add eth0 202
ifconfig vlan201 up
ifconfig vlan202 up

brctl addbr br1
brctl delif br0 wl0.1
brctl delif br0 wl1.1
brctl addif br1 vlan201
brctl addif br1 wl0.1
brctl addif br1 wl1.1
ifconfig br1 up

brctl addbr br2
brctl delif br0 wl0.2
brctl addif br2 vlan202
brctl addif br2 wl0.2
ifconfig br2 up

nvram set lan_ifnames="vlan1 eth1 eth2"
nvram set lan_ifname="br0"
nvram set lan1_ifnames="vlan201 wl0.1 wl1.1"
nvram set lan2_ifnames="vlan202 wl0.2"
nvram set lan1_ifname="br1"
nvram set lan2_ifname="br2"

nvram commit
killall eapd
eapd
Code:
[email protected]:/tmp/home/root# robocfg show
Switch: enabled
Port 0:  100FD enabled stp: none vlan: 202 jumbo: off mac: 00:17:88:a2:92:56
Port 1:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 2:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 3:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 4: 1000FD enabled stp: none vlan: 1 jumbo: off mac: 00:19:99:e3:1b:e3
Port 8:   DOWN enabled stp: none vlan: 2 jumbo: off mac: 00:00:00:00:00:00
VLANs: BCM5301x enabled mac_check mac_hash
   1: vlan1: 1 2 3 4 5t
   2: vlan2: 5
  56: vlan56: 0t 2t 7t 8t
  57: vlan57: 0 2 5t
  58: vlan58: 2 3t 4 5t 7t 8t
  59: vlan59: 1t 2t 3t 7 8u
  60: vlan60: 0 1 7
  61: vlan61: 2 8u
  62: vlan62: 1t 7
201: vlan201: 4t 5t
202: vlan202: 0 4t 5t
[email protected]:/tmp/home/root#
And again, on a second reboot, not working anymore...

@grifo It seems, after a reboot, it will get a non vlan IP and will stay on it. If I refresh dhcp on the device, it will get the vlan IP. First tried with a hue bridge, then switched to a laptop and I can see this behavior now. Any thoughts?
So there is no connectivity, if its on non vlan but it doesn't reconnect itself, which is bad. ^^
 
Last edited:

grifo

Senior Member
@grifo So second try:
Code:
#!/bin/sh
robocfg vlan 1 ports "1 2 3 4 5t"
robocfg vlan 201 ports "4t 5t"
robocfg vlan 202 ports "0 4t 5t"
vconfig add eth0 201
vconfig add eth0 202
ifconfig vlan201 up
ifconfig vlan202 up

brctl addbr br1
brctl delif br0 wl0.1
brctl delif br0 wl1.1
brctl addif br1 vlan201
brctl addif br1 wl0.1
brctl addif br1 wl1.1
ifconfig br1 up

brctl addbr br2
brctl delif br0 wl0.2
brctl addif br2 vlan202
brctl addif br2 wl0.2
ifconfig br2 up

nvram set lan_ifnames="vlan1 eth1 eth2"
nvram set lan_ifname="br0"
nvram set lan1_ifnames="vlan201 wl0.1 wl1.1"
nvram set lan2_ifnames="vlan202 wl0.2"
nvram set lan1_ifname="br1"
nvram set lan2_ifname="br2"

nvram commit
killall eapd
eapd
Code:
[email protected]:/tmp/home/root# robocfg show
Switch: enabled
Port 0:  100FD enabled stp: none vlan: 202 jumbo: off mac: 00:17:88:a2:92:56
Port 1:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 2:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 3:   DOWN enabled stp: none vlan: 1 jumbo: off mac: 00:00:00:00:00:00
Port 4: 1000FD enabled stp: none vlan: 1 jumbo: off mac: 00:19:99:e3:1b:e3
Port 8:   DOWN enabled stp: none vlan: 2 jumbo: off mac: 00:00:00:00:00:00
VLANs: BCM5301x enabled mac_check mac_hash
   1: vlan1: 1 2 3 4 5t
   2: vlan2: 5
  56: vlan56: 0t 2t 7t 8t
  57: vlan57: 0 2 5t
  58: vlan58: 2 3t 4 5t 7t 8t
  59: vlan59: 1t 2t 3t 7 8u
  60: vlan60: 0 1 7
  61: vlan61: 2 8u
  62: vlan62: 1t 7
201: vlan201: 4t 5t
202: vlan202: 0 4t 5t
[email protected]:/tmp/home/root#
And again, on a second reboot, not working anymore...
Yes the robocfg vlan 1 line needs to be there if you want the port isolated to just one vlan. This robocfg show looks good and it should work.
 

Bob.Dig

Regular Contributor
@grifo But it doesn't in the sense that the device on that port will stay in the non vlan if not un- and replugged or otherwise get a new IP.
 

grifo

Senior Member
@grifo It seems, after a reboot, it will get a non vlan IP and will stay on it. If I refresh dhcp on the device, it will get the vlan IP. First tried with a hue bridge, then switched to a laptop and I can see this behavior now. Any thoughts?
So there is no connectivity, if its on non vlan but it doesn't reconnect itself, which is bad. ^^
It's probably because you were making the changes so the machine couldn't get an IP and it used a self assigned IP. This shouldn't happen in normal operations once the configuration is settled. I'd leave it with your latest config, reboot the machine and monitor it.
 

grifo

Senior Member
@grifo But it doesn't in the sense that the device on that port will stay in the non vlan if not un- and replugged or otherwise get a new IP.
It happens that the DHCP lease needs to be renewed when an end device picks up a wrong (while making configuration changes) or self assigned IP.

EDIT: there is a possibility of the machine picking up a wrong IP if it boots at the same time as the AP and it makes its DHCP request before the services-start script has been run, so it gets an IP from vlan 1. It's rare but it can happen and to prevent that I have the robocfg vlan lines (only) on a different script, init-start, which is the earliest script that is run. It normally only happens during testing and config changes as even if the power goes off chances are the machine will take longer to boot and make its DHCP request than it takes the AP to run all its scripts, so to keep things simpler I didn't mention it earlier.
 
Last edited:

Bob.Dig

Regular Contributor
@grifoTried this now multiple times and also waited for some minutes (even 10) and that problem persists and it is not going away. So I guess there is nothing we can do about it and I will have to stick for wifi vlans only, which is still great.
I am thinking of blocking unknown client in the dhcp server on that non vlan in pfSense. But if I forgot that setting I will have a hard time next time plugging in something new...
Or maybe drastically reducing the Default lease time for this interface in the dhcp server?

So I somewhat fixed it in pfSense by making a DHCP Static Mapping for that devices MAC plugged in that port under the "wrong" network and defined a leas time of just 60 second just for that Mapping. This seemed to work fine. But I have to remember what I did there. ;)

Now reading your edit above, maybe have to test that. But I am only rebooting the Asus, nothing more and the problem persisted.
 
Last edited:

grifo

Senior Member
@grifoTried this now multiple times and also waited for some minutes (even 10) and that problem persists and it is not going away. So I guess there is nothing we can do about it and I will have to stick for wifi vlans only, which is still great.
It's strange as it works on my RT-AC68U running in AP mode with the vlan to ssid config as per the posts above and an isolated wired port belonging to the guest vlan.
I am thinking of blocking unknown client in the dhcp server on that non vlan in pfSense. But if I forgot that setting I will have a hard time next time plugging in something new...
Or maybe drastically reducing the Default lease time for this interface in the dhcp server?
Not worth doing either IMO, if it still doesn't work after you've tried all else you can always create an extra wired only vlan like the 199 you had earlier. If it has to be on the same broadcast domain you can do the bridging on the pfsense.
 

Bob.Dig

Regular Contributor
I have the robocfg vlan lines (only) on a different script, init-start, which is the earliest script that is run.
Could you show it to me? Want to try that too the right way.
Not worth doing either IMO, if it still doesn't work after you've tried all else you can always create an extra wired only vlan like the 199 you had earlier.
To be honest, I only had this for testing purposes, I often unplugged and replugged the cable for this so I can't tell, if it would had this problem too.
 

grifo

Senior Member
Could you show it to me? Want to try that too the right way.
Yes, you create another script called init-start, also in /jffs/scripts/, with the below content, per your latest config:
Code:
#!/bin/sh
robocfg vlan 1 ports "0 1 2 4 5t"
robocfg vlan 201 ports "4t 5t"
robocfg vlan 202 ports "3 4t 5t"
And you remove the same lines from the services-start script.
 

Bob.Dig

Regular Contributor
@grifo According to my laptop, this does it. Thanks again!! :D
Code:
#!/bin/sh
robocfg vlan 1 ports "0 1 2 4 5t"
robocfg vlan 201 ports "4t 5t"
robocfg vlan 202 ports "3 4t 5t"
Code:
#!/bin/sh
vconfig add eth0 201
vconfig add eth0 202
ifconfig vlan201 up
ifconfig vlan202 up

brctl addbr br1
brctl delif br0 wl0.1
brctl delif br0 wl1.1
brctl addif br1 vlan201
brctl addif br1 wl0.1
brctl addif br1 wl1.1
ifconfig br1 up

brctl addbr br2
brctl delif br0 wl0.2
brctl addif br2 vlan202
brctl addif br2 wl0.2
ifconfig br2 up

nvram set lan_ifnames="vlan1 eth1 eth2"
nvram set lan_ifname="br0"
nvram set lan1_ifnames="vlan201 wl0.1 wl1.1"
nvram set lan2_ifnames="vlan202 wl0.2"
nvram set lan1_ifname="br1"
nvram set lan2_ifname="br2"

nvram commit
killall eapd
eapd
 
Last edited:

Similar threads

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