Birger Koblitz <m...@birger-koblitz.de> writes:

> Dear Russel,
>
> depending on how a particular device was configured previously by
> u-boot, this commit might have enabled proper vlan-filtering for the 
> first time on your device.  The default vlan-configuration has port 1
> configured as management port with vlan-id 100. So your DHCP server 
> would need to answer with this vlan-id. Could you check that
> - before the commit, the device was actually filtering vlans
> - after the commit you have a correct vlan configuration on the device
>   talking to the switch on port 1 and that this corresponds to the
>  vlan configuration of that port

Does the latest master work for you?

I see the same issues Russell reports.  With a config like:

root@OpenWrt:/# bridge vlan
port              vlan-id  
lan1              1 PVID Egress Untagged
                  100
lan2              1 PVID Egress Untagged
                  100
lan3              1 PVID Egress Untagged
lan4              1 PVID Egress Untagged
lan5              1 PVID Egress Untagged
lan6              1 PVID Egress Untagged
lan7              1 PVID Egress Untagged
lan8              1 PVID Egress Untagged
switch            1
                  100
root@OpenWrt:/# ifconfig switch.100
switch.100 Link encap:Ethernet  HWaddr BE:A5:11:9F:E1:23  
          inet addr:192.168.100.1  Bcast:192.168.100.255  Mask:255.255.255.0
          inet6 addr: fe80::bca5:11ff:fe9f:e123/64 Scope:Link
          inet6 addr: fd49:b68c:340b::1/60 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:1360 (1.3 KiB)



Looks like packets coming into port lan2 tagged with vlan id 100 are
dropped:

root@OpenWrt:/# ping 192.168.100.111
PING 192.168.100.111 (192.168.100.111): 56 data bytes
^C
--- 192.168.100.111 ping statistics ---
7 packets transmitted, 0 packets received, 100% packet loss
root@OpenWrt:/# ip ne sh
192.168.100.111 dev switch.100  FAILED


The other end, connected to lan2, sees the tagged arps and replies. So I
believe these must be dropped on ingress to the switch:

17055   May  8, 2021 15:23:00.973571758 CEST    be:a5:11:9f:e1:23       
ff:ff:ff:ff:ff:ff       100     ARP     Who has 192.168.100.111? Tell 
192.168.100.1
17056   May  8, 2021 15:23:00.973594729 CEST    34:97:f6:5d:03:11       
be:a5:11:9f:e1:23       100     ARP     192.168.100.111 is at 34:97:f6:5d:03:11
17057   May  8, 2021 15:23:01.593254696 CEST    80:e8:6f:97:78:01       
01:80:c2:00:00:00               STP     Conf. Root = 32768/37/80:e8:6f:97:78:00 
 Cost = 0  Port = 0x8001
17058   May  8, 2021 15:23:02.013561194 CEST    be:a5:11:9f:e1:23       
ff:ff:ff:ff:ff:ff       100     ARP     Who has 192.168.100.111? Tell 
192.168.100.1
17059   May  8, 2021 15:23:02.013572143 CEST    34:97:f6:5d:03:11       
be:a5:11:9f:e1:23       100     ARP     192.168.100.111 is at 34:97:f6:5d:03:11


Reverting the two commits

 cde31976e375 ("realtek: Add support for Layer 2 Multicast")
 4342d27ec90c ("realtek: Setup all VLANs with default configurations")

fixes the problem.  I guess 4342d27ec90c is the critical one.  Just
reverting both to avoid having to manually fixup anything for this
simple test.


With exactly the same config as above:

root@OpenWrt:/# ping 192.168.100.111
PING 192.168.100.111 (192.168.100.111): 56 data bytes
64 bytes from 192.168.100.111: seq=0 ttl=64 time=1.714 ms
64 bytes from 192.168.100.111: seq=1 ttl=64 time=0.866 ms
^C
--- 192.168.100.111 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.866/1.290/1.714 ms
root@OpenWrt:/# ip ne sh
192.168.100.111 dev switch.100 lladdr 34:97:f6:5d:03:11 REACHABLE


Bjørn

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to