Modify

Opened 3 years ago

Last modified 3 years ago

#19391 new defect

WNDR4300: Adding a VLAN in the Web UI causes a loss of connectivity

Reported by: pontillo@… Owned by: developers
Priority: normal Milestone:
Component: base system Version: Barrier Breaker 14.07
Keywords: Cc:

Description

I'm not sure if an invalid configuration is being generated by the UI, or if this is a bug with this particular device, or otherwise. Any comments would be appreciated.

Steps to reproduce:

  • Using the web UI, configure a new VLAN (vid 3) and set it to be tagged in ports 1-5

Result:

The device can no longer be managed (cannot ping, ssh/telnet, web management no longer functions).

Here is my /etc/config/network (gathered in failsafe mode):

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 'fd75:xxxx:xxxx::/48'

config interface 'lan'
        option ifname 'eth0.1'
        option force_link '1'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option macaddr '04:a1:51:xx:xx:xx'

config interface 'wan'
        option ifname 'eth0.2'
        option proto 'dhcp'
        option macaddr '04:a1:51:82:8b:24'

config interface 'wan6'
        option ifname '@wan'
        option proto 'dhcpv6'

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

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

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

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

Note: I first experienced this when adding a more complex VLAN configuration, so I retried as stated above, and only added a single VLAN.

Any suggestions to further debug this?

Attachments (0)

Change History (4)

comment:1 Changed 3 years ago by pontillo@…

When doing commands like:

# swconfig dev switch0 vlan 5 show
VLAN 5:

vid: 5
ports:

I noticed that the vid and the VLAN number always match. I got worried that duplicate VIDs were being programmed to the hardware, causing this problem. (though in retrospect, that isn't possible with the simple failing use case I showed in the bug above.)

In any case, I tried doing:

# swconfig dev switch0 vlan 42 set ports '0t 1t 2t 3t 4t'

To see if I could configure the VLAN in hardware without affecting management capabilities.

Unfortunately, the switch doesn't pass traffic in VLAN 42 with this configuration. Is there something else that must be done to get forwarding to work? (I tried without port 0 first, but then figured it might be needed in order to program the forwarding table -- but I'm not sure where that happens in OpenWRT...)

comment:2 Changed 3 years ago by pontillo@…

Ah. As soon as I did the following, after setting the ports as mentioned above:

# swconfig dev switch0 set apply

... this caused it to exhibit the symptom mentioned in the bug.

I wonder why the first 2 VLANs can be created successfully, but not subsequent VLANs?

comment:3 Changed 3 years ago by pontillo@…

Here's another interesting experiment. Since I'm not using the WAN interface, I did the following:

# swconfig dev switch0 vlan 2 set ports '0t 1t 2t 3t 4t'
# swconfig dev switch0 vlan 2 set vid 42
# swconfig dev switch0 set apply

This caused traffic to be passed on VID 42 on my network. However, it *also* immediately caused the symptom noted in the bug: I could no longer manage the device.

After resetting the device and trying another experiment:

# swconfig dev switch0 vlan 42 set ports '1t 2t 3t 4t'
# swconfig dev switch0 set apply

... I found that it also caused traffic to be passed on VID 42 on my network. (in addition to shutting down management capabilities.)

Furthermore, another data point: it appears that when doing this, it isn't just management capabilities that stop. The switch no longer forwards traffic, at all, in VLAN 1.

I'm looking forward to other ideas to narrow this down further...

comment:4 Changed 3 years ago by pontillo@…

Final experiment (for now); sorry for the bug spam:

# swconfig dev switch0 set enable_vlan 0
# swconfig dev switch0 set apply

This *appears to have* the effect of causing the behavior I want, where traffic in *all* my VLANs, tagged and untagged, is passed through. (however -- and this is most likely expected since I'm disabling VLANs completely -- it also prevents the device from being managed.)

Also, I may have been mistaken when I said the switch doesn't forward traffic on VLAN 1 in the above comments. I noticed a configuration error that caused my test case to be flawed. However, in all of the above cases, the device can no longer be managed.

Add Comment

Modify Ticket

Action
as new .
Author


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

 
Note: See TracTickets for help on using tickets.