Modify

Opened 2 years ago

Last modified 2 years ago

#20381 new defect

Creating a new VLAN breaks the existing default VLAN 1 eth1 device on TP-LINK TL-WR1043ND v2 router

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

Description

Hello,

I'm testing with OpenWrt 14.07 BB and TP-LINK TL-WR1043ND v2 router.

The default OpenWrt configuration on this device has the default
LAN interface on the physical device eth1.

When a new VLAN is created using the usual LuCI switch screen, when
the new VLAN is activated, the switch will then treat VLAN 1 (the
default VLAN) as accessible only using the device eth1.1.

As the default OpenWrt configuration references only eth1, the
result is a non-working LAN configuration on a VLAN that the user
does not expect to have been changed.

A straightforward fix would be to change the default OpenWrt
configuration to reference VLAN 1 right from the start using the
eth1.1 notation (similarly to how the older TL-WR1043NDv1 router
works).

There are two changes needed to do this: add a 0t to the VLAN1
switch definition to move the switch into VLAN mode, and reference
eth1.1 instead of eth1 in the LAN interface definition.

With these changes, users can later create VLANs with no impact
to VLAN1.

old:
config interface 'lan'

option ifname 'eth1'
option force_link '1'
option type 'bridge'

new:
config interface 'lan'

option ifname 'eth1.1' CHANGE HERE
option force_link '1'
option type 'bridge'

old:
config switch_vlan

option device 'switch0'
option vlan '1'
option ports '0 1 2 3 4'

new:
config switch_vlan

option device 'switch0'
option vlan '1'
option ports '0t 1 2 3 4' CHANGE HERE

Note this issue is specific to the v2 model of this router,
which uses a different switch chipset compared to the v1 older
model.

Regards,
Tim Miller Dyck

Attachments (0)

Change History (1)

comment:1 Changed 2 years ago by pauby

I can confirm this is still the case on the latest Chaos Calmer 15.05. It's a very frustrating bug as it appears it can only be solved by changing the LAN to eth1.1 by SSH so it means moving from the GUI to SSH to fix a bug.

The big is documented on the WR1043ND page which points specifically to this ticket. However there are no updates on this bug.

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.