A bizarre vlan tagging happens when I try to create a VLAN based SSID separation. Here's the configuration for the RT-N66U router running in the AP mode (the latest Merlin release):
When I connect to the guest SSID ("vlan4 wl0.1"), everything works fine, the packets are routed through VLAN4 as expected. However, when I try to connect through the main SSID("vlan1 eth1 eth2"), the packets are still routed via VLAN4 with some going through VLAN1:
Guest VLAN4 (good):
Main VLAN1 (bad, tagging with "4"):
Occasionally, just after the AP reboot, VLAN1 behaves properly:
However, switching to the guest VLAN4 and then back to VLAN1, causes the main SSID (VLAN1) misbehave by tagging the ethernet frames with tag 4 rather than 5.
I am reluctant to switch to Tomato because its WiFi driver appears to be inferior.
Code:
#!/bin/sh
robocfg vlan 4 ports "0t 8t"
vconfig add eth0 4
ifconfig vlan4 up
brctl addbr br1
brctl addif br1 vlan4
brctl delif br0 wl0.1
brctl addif br1 wl0.1
ifconfig br1 up
# EAP hack:
nvram set lan_ifnames="vlan1 eth1 eth2"
nvram set lan_ifname="br0"
nvram set lan1_ifnames="vlan4 wl0.1"
nvram set lan1_ifname="br1"
killall eapd
eapd
Guest VLAN4 (good):
Code:
16:38:47.933571 74:f0:6d:79:cd:26 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 60: vlan 4, p 0, ethertype ARP, Request who-has 192.168.4.61 tell 0.0.0.0, length 42
16:38:47.934752 74:f0:6d:79:cd:26 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 60: vlan 4, p 0, ethertype IPv4, 192.168.4.61 > 224.0.0.22: igmp v3 report, 1 group record(s)
16:38:47.935179 74:f0:6d:79:cd:26 > 33:33:ff:d8:30:bf, ethertype 802.1Q (0x8100), length 82: vlan 4, p 0, ethertype IPv6, :: > ff02::1:ffd8:30bf: ICMP6, neighbor solicitation, who has fe80::9883:b333:24d8:30bf, length 24
16:38:47.935229 74:f0:6d:79:cd:26 > 33:33:00:00:00:02, ethertype 802.1Q (0x8100), length 74: vlan 4, p 0, ethertype IPv6, fe80::9883:b333:24d8:30bf > ff02::2: ICMP6, router solicitation, length 16
16:38:47.935247 74:f0:6d:79:cd:26 > 33:33:00:00:00:16, ethertype 802.1Q (0x8100), length 94: vlan 4, p 0, ethertype IPv6, fe80::9883:b333:24d8:30bf > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
16:38:47.943692 74:f0:6d:79:cd:26 > 33:33:00:01:00:02, ethertype 802.1Q (0x8100), length 152: vlan 4, p 0, ethertype IPv6, fe80::9883:b333:24d8:30bf.546 > ff02::1:2.547: dhcp6 solicit
16:38:47.955417 74:f0:6d:79:cd:26 > ff:ff:ff:ff:ff:ff, ethertype 802.1Q (0x8100), length 346: vlan 4, p 0, ethertype IPv4, 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 74:f0:6d:79:cd:26, length 300
16:38:47.955846 1c:b7:2c:ca:d9:40 > 74:f0:6d:79:cd:26, ethertype 802.1Q (0x8100), length 66: vlan 4, p 0, ethertype IPv4, 192.168.4.1 > 192.168.4.61: ICMP echo request, id 10446, seq 0, length 28
16:38:48.011371 74:f0:6d:79:cd:26 > 33:33:00:00:00:16, ethertype 802.1Q (0x8100), length 94: vlan 4, p 0, ethertype IPv6, fe80::9883:b333:24d8:30bf > ff02::16: HBH ICMP6, multicast listener report v2, 1
Main VLAN1 (bad, tagging with "4"):
Code:
18:44:16.733913 1c:b7:2c:ca:d9:40 > 74:f0:6d:79:cd:26, ethertype 802.1Q (0x8100), length 64: vlan 1, p 0, ethertype IPv4, 68.87.20.9.995 > 10.1.1.28.60245: Flags [.], ack 585, win 33, length 0
18:44:16.775582 74:f0:6d:79:cd:26 > 1c:b7:2c:ca:d9:40, ethertype 802.1Q (0x8100), length 82: vlan 4, p 0, ethertype IPv4, 10.1.1.28.55459 > 10.1.1.250.53: 63097+ A? isatap.umber.local. (36)
18:44:16.817391 74:f0:6d:79:cd:26 > 1c:b7:2c:ca:d9:40, ethertype 802.1Q (0x8100), length 89: vlan 4, p 0, ethertype IPv4, 10.1.1.28.58946 > 10.1.1.250.53: 1119+ A? teredo.ipv6.microsoft.com. (43)
18:44:16.944949 74:f0:6d:79:cd:26 > 01:00:5e:00:00:16, ethertype 802.1Q (0x8100), length 60: vlan 1, p 0, ethertype IPv4, 10.1.1.28 > 224.0.0.22: igmp v3 report, 1 group record(s)
Occasionally, just after the AP reboot, VLAN1 behaves properly:
Code:
18:18:09.697527 74:f0:6d:79:cd:26 > 1c:b7:2c:ca:d9:40, ethertype 802.1Q (0x8100), length 83: vlan 1, p 0, ethertype IPv4, 10.1.1.28.64075 > 10.1.1.250.53: 56267+ A? Brother.umber.local. (37)
18:18:09.709273 1c:b7:2c:ca:d9:40 > 74:f0:6d:79:cd:26, ethertype 802.1Q (0x8100), length 158: vlan 1, p 0, ethertype IPv4, 10.1.1.250.53 > 10.1.1.28.64075: 56267 NXDomain 0/1/0 (112)
18:18:10.025098 74:f0:6d:79:cd:26 > 1c:b7:2c:ca:d9:40, ethertype 802.1Q (0x8100), length 82: vlan 1, p 0, ethertype IPv4, 10.1.1.28.55833 > 10.1.1.250.53: 39463+ A? isatap.umber.local. (36)
18:18:10.038290 1c:b7:2c:ca:d9:40 > 74:f0:6d:79:cd:26, ethertype 802.1Q (0x8100), length 157: vlan 1, p 0, ethertype IPv4, 10.1.1.250.53 > 10.1.1.28.55833: 39463 NXDomain 0/1/0 (111)
18:18:10.056483 74:f0:6d:79:cd:26 > 1c:b7:2c:ca:d9:40, ethertype 802.1Q (0x8100), length 88: vlan 1, p 0, ethertype IPv4, 10.1.1.28.51298 > 10.1.1.250.53: 16102+ A? detectportal.firefox.com. (42)
However, switching to the guest VLAN4 and then back to VLAN1, causes the main SSID (VLAN1) misbehave by tagging the ethernet frames with tag 4 rather than 5.
I am reluctant to switch to Tomato because its WiFi driver appears to be inferior.