Modify

Opened 6 years ago

Last modified 3 years ago

#11731 new defect

TL-WR1043ND - vlan bugs

Reported by: anonymous Owned by: developers
Priority: high Milestone: Barrier Breaker 14.07
Component: base system Version: Trunk
Keywords: vlan switch rtl8366rb Cc:

Description

In a setup with a vlan trunk including two OpenWRT-Devices of type TPLink TL-WR1043ND in build r32130, a linux server and a virtual host on that linux server, devices connected to the configured switch ports of the openwrt devices are sometimes not tagged or the packets get mangled on their way through a smart switch, or possibly when passing through a linux bridge.
The problem can be reproduced.
The problem does not occur, when the machines previously connected to openwrt get directly connected to the switch.

Facts:

  • A 4k Vlan-ID is in use.
  • The setup has worked fine before in earlier versions of openwrt. about two-three months ago.
  • Arp-Requests get through to the target (virtualized) machine, but ARP-resolution fails. Ping requests don't reach the target host.
  • The OpenWRT devices are connected by WAN-Ports, which are all configured for tagging.
  • The OpenWRT devices are reachable on various vlan interfaces.
  • Some hosts (via WLAN) are reachable too.
  • The machine sees all the connected machines on the same switch.
  • The connected machine (on openwrt/switch) can see almost all hosts on the network, but not the virtualized machine on the linux machine and vice versa, while the linux machine is reachable w/o problem and vice versa.
  • The error does not occur, if openwrt is not involved - e.g. direct connection to the other switch.
  • Connecting tagged trunks to a "dumb" switch instead of the smart switch (CISCO SLM2008) does not change a thing.
  • No forwarding rules apply
  • no arptables, erptables are in use.
  • Currently only ports 0 and 5 are tagged for all configured vlans. All other ports are untagged for one of those vlans, while all other vlans are "off" on these ports.

Assumption:
Switch seems to work in general.
Something in BSD Kernel or Linux Kernel mangles the packets, but only those from OpenWRT, probably removing the vlan-id for unknown reasons. (They are visible on the linux host raw ethernet device w/o vlan).

Conclusion:
Probably something in the ethernet frame header steming from OpenWRT has been set, so that one of the switches or the bridge thinks it needs to correct the header before passing it on?

Questions:
What header bits could be affected?
Are there known bugs in Linux or BSD network stacks?
Has the OpenWRT switch code for RTL8366rb or Vlan changed recently?
Is bridgeing + vlan a possible cause, as in previous linux kernels e.g. 2.6.39?

Attachments (0)

Change History (6)

comment:1 Changed 5 years ago by epek

This problem still persists in Version r32991 of "Bleeding Edge".
Computers connected to untagged vlan-Ports of rtl8366rb are still unreachable from the Pfsense machine. Arp resolution remains incomplete.

comment:2 Changed 5 years ago by epek@…

And still persists in r33132.
It looks like the packets tagged by Openwrt get dropped by pfsense for some reasons.
This is either a bug of FreeBSD/pfsense or OpenWRT. How can I help?

comment:3 Changed 5 years ago by E. N. Pekarek <epek@…>

New facts: The packets are indeed tagged, but vlan pcp is set to 2 on untagged ports:

see:
http://forum.pfsense.org/index.php/topi … 82176.html
https://forum.openwrt.org/viewtopic.php?id=37609
https://forum.openwrt.org/viewtopic.php?pid=175429

comment:4 Changed 5 years ago by Epek <epek@…>

Update: The pfsense people have fixed their software. The question still is, why the rtl8366[...] drivers tag traffic with a pcp value other than BE (Best effort). Did someone mix up the values?

comment:5 Changed 4 years ago by jow

  • Milestone changed from Attitude Adjustment 12.09 to Barrier Breaker 14.07

Milestone Attitude Adjustment 12.09 deleted

comment:6 Changed 3 years ago by ericwong

Seems like duplicate of /ticket/12181.html

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.