WNDR3700 / RTL8366s dot1q tagging on non-cpu port requires a "kick" to work properly after reset

[sartan]

KAMIKAZE trunk r22704

RTL8366s device needs a "kick" to enable proper dot1q tagging off a non-CPU port.
WNDR3700: Ports 0-3 are onboard "LAN" ports, port 4 is a non-switched "WAN" port, and port 5 is the CPU.

swconfig dev rtl8366s reset
swconfig dev rtl8366s vlan {1-5} set ports ""
swconfig dev rtl8366s vlan 6 set ports "0t 1 2 3 5t"
swconfig dev rtl8366s vlan 7 set ports "0t 5t"
vconfig add eth0 6
vconfig add eth0 7
ifconfig eth0.6 172.16.66.2 netmask 255.255.255.0 up
ifconfig eth0.7 172.16.67.2 netmask 255.255.255.0 up

VLAN6 traffic works as expected. Adjacent Cisco 3560 switch on port 0 will work fine with encapsulated packets in vlan 6. Non-tagging devices on ports 1,2,3 work fine.
172.16.66.4 can ping 172.16.66.2.

VLAN7 traffic does not work as expected. tcpdump -ni eth0.7 shows zero packets coming in when 172.16.67.4 tries to ping 172.16.67.2.

I can "kick" it by doing:

swconfig dev rtl8366s vlan 7 set ports "0 5t"[pings continue to drop]
swconfig dev rtl8366s vlan 7 set ports "0t 5t"[redoing trunk config]

Once I set the port to a normal non-tagged vlan and back to a trunk port, I then get properly tagged traffic.

I included swconfig dev rtl8366s show output for vlans - this config looks identical before and after the "kick". /etc/config/network config also is set up correctly, but makes no difference.

VLAN 1:
        info: VLAN 1: Ports: '', members=0000, untag=0001, fid=0
        ports:
VLAN 2:
        info: VLAN 2: Ports: '', members=0000, untag=0000, fid=0
        ports: 
VLAN 3:
        info: VLAN 3: Ports: '', members=0000, untag=0000, fid=0
        ports: 
VLAN 4:
        info: VLAN 4: Ports: '', members=0000, untag=0000, fid=0
        ports: 
VLAN 5:
        info: VLAN 5: Ports: '', members=0000, untag=0000, fid=0
        ports: 
VLAN 6:
        info: VLAN 6: Ports: '0t1235t', members=002f, untag=000e, fid=0
        ports: 0t 1 2 3 5t 
VLAN 7:
        info: VLAN 7: Ports: '0t5t', members=0021, untag=0000, fid=0
        ports: 0t 5t 

[nbd]

fixed in r22856

[sartan]

I tested this earlier with nbd, the fix works great.

[ecc@…]

This bug seems to still be present, at least for the DIR-825. I'm running trunk r24030, with the following VLAN config:

vlan 1: ports '0 1 2 3t 5t'
vlan 10: ports '3t 5t'

When I reboot, no packets are received on eth0.1.
If I execute the following "kick", traffic starts flowing correctly:

# swconfig dev rtl8366s vlan 1 set ports '0 1 2 3t 5'
# swconfig dev rtl8366s vlan 1 set ports '0 1 2 3t 5t'

For now, I've put the above kickstart in /etc/rc.local, but that shouldn't be necessary.

Also, VLANs 2-5 seem to be initialized as follows upon boot, even though there are no corresponding settings in /etc/config/network:

VLAN 2:
	info: VLAN 2: Ports: '15', members=0022, untag=0022, fid=0
	ports: 1 5 
VLAN 3:
	info: VLAN 3: Ports: '25', members=0024, untag=0024, fid=0
	ports: 2 5 
VLAN 4:
	info: VLAN 4: Ports: '35', members=0028, untag=0028, fid=0
	ports: 3 5 
VLAN 5:
	info: VLAN 5: Ports: '45', members=0030, untag=0030, fid=0
	ports: 4 5 

I don't know if this is related or not.

[Eric Cooper <ecc@…>]

Sorry, I think this was just user error on my part (misconfigured VLAN on an Ethernet switch elsewhere in the network). Please go ahead and close it (again).

[sartan]

Unfortunately this issue has returned in r36713 nearly identically to the way i have reported earlier.

'vlan 8' does not work until i swconfig dev switch0 vlan 8 set ports "3 5t" and then "3t 5t" again - it does not work when the vlan is initially configured.

[anonymous]

*Since r36713

[tdobes@…]

I'm also seeing this problem with Attitude Adjustment r39928 on a Netgear WNDR3700 v1.

After "kicking" the switch as described in the initial bug report, it starts emitting tagged packets normally again. The output of "swconfig dev rtl8366s vlan # show" is the same both before and after running these commands, though.

[Stefan Hellermann <stefan@…>]

I reproducible resolved this problem on r40335 by enabling the vlan4k option:

config switch
	option name switch0
	option reset 1
	option enable_vlan 1
	option blinkrate 2
	option enable_vlan4k 1

[lars@…]

The "kick" workaround stoped working for me after making some configuration changes in /etc/config/network. I got my VLANs running again by explicitly pushing the configuration to the switch with the command

swconfig dev switch0 set apply 1

after restarting /etc/init.d/network.

[anonymous]

Having identical problem to original report on WNDR3700v1 with trunk r41407. It seems that any VLAN with only tagged ports does not set up correctly until you "kick" it by adding and removing an untagged port, as described.

[anonymous]

I'm getting the same problem on r41679 with a WNDR3700v2.

If I have:
option ports '0t 1t 5t'

then that vlan doesn't get to the switch connected to port 0 or the server connected to port 1.

If I change it to:
option ports '0t 1t 2 5t'
...it works.

Oddly though, one of my vlan's does work.

Here is my full switch config:

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

config switch_vlan
    option device 'switch0'
    option vlan 2
    option ports '0t 1t 5t'

config switch_vlan
        option device 'switch0'
        option vlan 3
        option ports '0t 1t 5t'

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

config switch_vlan
        option device 'switch0'
        option vlan 5
        option ports '0t 5t'

config switch_vlan
        option device 'switch0'
        option vlan 6
        option ports '0t 5t'

config switch_vlan
        option device 'switch0'
        option vlan 7
        option ports '0t 1t 3 5t'

config switch_vlan
        option device 'switch0'
        option vlan 8
        option ports '0t 1t 3 5t'

config switch_vlan
        option device 'switch0'
        option vlan 9
        option ports '0t 5t'

vlan 2 seems to work fine, but 4, 7 & 8 show the symptom above - so before I found this thread, I added to add port 3 to them both (there is nothing plugged into port 3) and it fixes the issue.

(i've not yet had chance to try vlans 3, 5 or 9)

Ian

[jow]

Milestone Attitude Adjustment 12.09 deleted

[ichilton]

This is still a problem in the final release of Barrier Breaker:
BARRIER BREAKER (14.07, r42625)

Ian

[anonymous]

I just tried and found that as said above, adding the following to /etc/config/network fixes this issue for me too:

option enable_vlan4k 1

Ian