Modify

Opened 6 years ago

Last modified 21 months ago

#7795 reopened defect

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

Reported by: sartan Owned by: developers
Priority: normal Milestone: Barrier Breaker 14.07
Component: base system Version: Trunk
Keywords: Cc:

Description

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 

Attachments (0)

Change History (15)

comment:1 Changed 6 years ago by nbd

  • Resolution set to fixed
  • Status changed from new to closed

fixed in r22856

comment:2 Changed 6 years ago by sartan

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

comment:3 Changed 6 years ago by ecc@…

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:4 Changed 6 years ago by 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).

comment:5 Changed 6 years ago by agb

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:6 Changed 3 years ago by sartan

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:7 Changed 3 years ago by anonymous

*Since r36713

comment:8 Changed 2 years ago by 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.

comment:9 Changed 2 years ago by 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

comment:10 Changed 2 years ago by 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.

comment:11 Changed 2 years ago by 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.

comment:12 Changed 2 years ago by 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

comment:13 Changed 2 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

comment:14 Changed 22 months ago by ichilton

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

Ian

comment:15 Changed 21 months ago by 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

Add Comment

Modify Ticket

Action
as reopened .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.