VLAN Tagging on Linksys EX6150v2

[Silverstar]

Hi together

I have an enterprise managed layer 3 switch and i have configured some ports with vlan tagging. Now i want to install some Linksys access points (EX6150v2) into my new house. The idea was to tag the traffic of the different ssid (Guest/Private/SmartHome) with vlan id's. But i have some trouble when i add the vlan interfaces in the access point config.

For testing i start with the simple config. Port 24 on my switch is untagged (VLAN1) an this port is the port how the Linksys is connected for configuration. My client is also on a untagged Port 3 (VLAN1) on the same switch.

VLAN 1 has a dhcp server in the ip range 172.16.10.x/24 and my client get an ip from the server. My client has also a manual configured ip address 192.168.10.10 for the basic config of the Linksys access points. On this side all things working fine and i can manage the access points over ssh or the web interface.

Then i configure the /etc/config/network as followed:

root@OpenWrt:~# vi /etc/config/network 


config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd15:d1a2:6277::/48'

config interface 'lan'
        option ifname 'eth0'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'default_vlan'
        option proto 'dhcp'
        option ifname 'eth0.1'

after restarting the network service the ifconfig comand shows a new interface

root@OpenWrt:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 3C:37:86:1E:42:B2  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1918 errors:0 dropped:63 overruns:0 frame:0
          TX packets:1214 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:248079 (242.2 KiB)  TX bytes:294779 (287.8 KiB)

eth0.1    Link encap:Ethernet  HWaddr 3C:37:86:1E:42:B2  
          inet6 addr: fe80::3e37:86ff:fe1e:42b2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:67 errors:0 dropped:0 overruns:0 frame:0
          TX packets:75 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3150 (3.0 KiB)  TX bytes:24002 (23.4 KiB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:192 errors:0 dropped:0 overruns:0 frame:0
          TX packets:192 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:13056 (12.7 KiB)  TX bytes:13056 (12.7 KiB)

The System log after network service reload looks good for me.

Wed Jan 30 13:16:32 2019 daemon.notice netifd: Interface 'lan' is now down
Wed Jan 30 13:16:32 2019 daemon.notice netifd: Interface 'loopback' is now down
Wed Jan 30 13:16:32 2019 daemon.notice netifd: Interface 'loopback' is disabled
Wed Jan 30 13:16:32 2019 daemon.notice netifd: Network device 'lo' link is down
Wed Jan 30 13:16:32 2019 daemon.notice netifd: Interface 'loopback' has link connectivity loss
Wed Jan 30 13:16:32 2019 daemon.notice netifd: default_vlan (2742): udhcpc: received SIGTERM
Wed Jan 30 13:16:32 2019 daemon.notice netifd: Interface 'default_vlan' is now down
Wed Jan 30 13:16:33 2019 daemon.notice netifd: Interface 'lan' is disabled
Wed Jan 30 13:16:33 2019 daemon.notice netifd: Interface 'default_vlan' is disabled
Wed Jan 30 13:16:33 2019 daemon.notice netifd: VLAN 'eth0.1' link is down
Wed Jan 30 13:16:33 2019 daemon.notice netifd: Interface 'default_vlan' has link connectivity loss
Wed Jan 30 13:16:33 2019 daemon.notice netifd: Network device 'eth0' link is down
Wed Jan 30 13:16:33 2019 daemon.notice netifd: Interface 'lan' has link connectivity loss
Wed Jan 30 13:16:34 2019 user.notice : Added device handler type: tunnel
Wed Jan 30 13:16:34 2019 user.notice : Added device handler type: Network device
Wed Jan 30 13:16:34 2019 user.notice : Added device handler type: bridge
Wed Jan 30 13:16:34 2019 user.notice : Added device handler type: veth
Wed Jan 30 13:16:34 2019 user.notice : Added device handler type: macvlan
Wed Jan 30 13:16:34 2019 user.notice : Added device handler type: 8021ad
Wed Jan 30 13:16:34 2019 user.notice : Added device handler type: 8021q
Wed Jan 30 13:16:34 2019 daemon.notice procd: /etc/init.d/network: 'radio0' is disabled
Wed Jan 30 13:16:34 2019 daemon.notice procd: /etc/init.d/network: 'radio1' is disabled
Wed Jan 30 13:16:34 2019 daemon.notice procd: /etc/init.d/network: 'radio0' is disabled
Wed Jan 30 13:16:34 2019 daemon.notice procd: /etc/init.d/network: 'radio1' is disabled
Wed Jan 30 13:16:35 2019 daemon.notice netifd: Interface 'lan' is enabled
Wed Jan 30 13:16:35 2019 daemon.notice netifd: Interface 'lan' is setting up now
Wed Jan 30 13:16:35 2019 kern.info kernel: [ 3343.333441] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Wed Jan 30 13:16:35 2019 kern.info kernel: [ 3343.333513] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Wed Jan 30 13:16:35 2019 daemon.notice netifd: Interface 'lan' is now up
Wed Jan 30 13:16:35 2019 daemon.notice netifd: Interface 'default_vlan' is enabled
Wed Jan 30 13:16:35 2019 daemon.notice netifd: Interface 'loopback' is enabled
Wed Jan 30 13:16:35 2019 daemon.notice netifd: Interface 'loopback' is setting up now
Wed Jan 30 13:16:35 2019 daemon.notice netifd: Interface 'loopback' is now up
Wed Jan 30 13:16:35 2019 daemon.notice netifd: Network device 'eth0' link is up
Wed Jan 30 13:16:35 2019 daemon.notice netifd: Interface 'lan' has link connectivity
Wed Jan 30 13:16:35 2019 daemon.notice netifd: VLAN 'eth0.1' link is up
Wed Jan 30 13:16:35 2019 daemon.notice netifd: Interface 'default_vlan' has link connectivity
Wed Jan 30 13:16:35 2019 daemon.notice netifd: Interface 'default_vlan' is setting up now
Wed Jan 30 13:16:35 2019 daemon.notice netifd: Network device 'lo' link is up
Wed Jan 30 13:16:35 2019 daemon.notice netifd: Interface 'loopback' has link connectivity
Wed Jan 30 13:16:35 2019 daemon.notice netifd: default_vlan (3142): udhcpc: started, v1.28.4
Wed Jan 30 13:16:35 2019 user.notice firewall: Reloading firewall due to ifup of lan (eth0)
Wed Jan 30 13:16:35 2019 daemon.notice netifd: default_vlan (3142): udhcpc: sending discover
Wed Jan 30 13:16:35 2019 daemon.info dnsmasq[684]: read /etc/hosts - 4 addresses
Wed Jan 30 13:16:35 2019 daemon.info dnsmasq[684]: read /tmp/hosts/odhcpd - 0 addresses
Wed Jan 30 13:16:35 2019 daemon.info dnsmasq[684]: read /tmp/hosts/dhcp.cfg01411c - 0 addresses
Wed Jan 30 13:16:36 2019 daemon.info dnsmasq[684]: read /etc/hosts - 4 addresses
Wed Jan 30 13:16:36 2019 daemon.info dnsmasq[684]: read /tmp/hosts/odhcpd - 0 addresses
Wed Jan 30 13:16:36 2019 daemon.info dnsmasq[684]: read /tmp/hosts/dhcp.cfg01411c - 0 addresses
Wed Jan 30 13:16:38 2019 daemon.notice netifd: default_vlan (3142): udhcpc: sending discover
Wed Jan 30 13:16:41 2019 daemon.notice netifd: default_vlan (3142): udhcpc: sending discover

Then i change the switch port from the untagged (Port 24) to the working tagged one (Port 13) the access point wan't get a ip address from the dhcp server in the vlan 1. The default ip isn't also accessible but this is a normal behavior.

The switch config is correct. When i test with a raspi it works fine with all four virtual vlan interfaces (eth0.1/eth0.10/eth0.20/eth0.30/eth0.40) that are configured on it and the switch port 13. The raspi get an ip address on eth0.1 from the dhcp server in the vlan1.

Any idea? I'm a little bit confused.

[jeff]

Several things going on here. The first is that the IPQ401x has, well, a unique way of dealing with VLANs and its switch and Ethernet phys.

IPQ40xx Switch Config "Strangeness" (swconfig)

Impacting EA8300 and apparently EA6350v3, the IPQ40xx switch in these devices seems to have a mind of its own about VLANs and configuration. From what I've read, this is a "non-standard" switch that may require additional development work to have functional VLANs. It seems as though the two Ethernet phys are internally "wired" to VLANs off switch port 0. These devices appear to be dual-NIC devices, which may be almost certainly are a different wrinkle than dealt with in other threads / patches…

There are various commits to remove the "hard-wired", internal VLAN tags. It's on my list to look at after I wrap some other work.

The internal, UCI-based switch config is, in general, a little challenging at times. Conceptually, the VLAN in UCI is a "table entry" that happens to default the tag to the same number. If you're using more than your switch's driver has for entries, you need to add the vid tag (and pvid) as well. Until I or someone else works out the locked-down, internal tagging, this would be "future".

[Jonny007-MKD]

Hi,

I have tried for several days to get VLANs working on the EX6150v2 and now found the solution here:

IPQ40xx: Is it possible to use vlans?

Thank you! I think it's better for me to wait for tomorrow and try it with a fresh mind. Before I have to figure out which button I can use as failsafe-button and how to perform the boot into failsafe mode.

The trick is to add the switch vlan config in /etc/config/network:

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option vid '1'
        option ports '0t 4t'

config switch_vlan
        ### repeat for each vlan ###

and then to use eth0.X as physical device in the interface.

Best regards,
Jonny007