Re: realtek: Setup all VLANs with default configurations
Birger Koblitz writes:
> Yes, this looks like the DSA-tag in the packet buffer is not being
> overwritten by the CRC.
> Could you try out the following patch, which tries to follow the convolutions
> of the SDK for the 8380,
> with respect of buffer length and packet length when the CRC is being
> calculated by offloading.
> On my DLink 1210-10hp I see properly formed packets with small (<60 octets)
> and larger size.
> It fixes also the detection of DSA tags with a high port number (>=28) on the
> 8390.
>
> diff --git
> a/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
> b/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
> index c5c6e3b6b7..9fe4fcd647 100644
> --- a/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
> +++ b/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
> @@ -1129,23 +1129,16 @@ static int rtl838x_eth_tx(struct sk_buff *skb, struct
> net_device *dev)
>
> /* Check for DSA tagging at the end of the buffer */
> if (netdev_uses_dsa(dev) && skb->data[len-4] == 0x80 &&
> skb->data[len-3] > 0
> - && skb->data[len-3] < 28 && skb->data[len-2] == 0x10
> + && skb->data[len-3] < priv->cpu_port &&
> skb->data[len-2] == 0x10
> && skb->data[len-1] == 0x00) {
> /* Reuse tag space for CRC if possible */
> dest_port = skb->data[len-3];
> + skb->data[len-4] = skb->data[len-3] = skb->data[len-2] =
> skb->data[len-1] = 0x00;
> len -= 4;
> }
>
> len += 4; // Add space for CRC
>
> - // On RTL8380 SoCs, the packet needs extra padding
> - if (priv->family_id == RTL8380_FAMILY_ID) {
> - if (len < ETH_ZLEN)
> - len = ETH_ZLEN; // SoC not automatically padding to
> ETH_ZLEN
> - else
> - len += 4;
> - }
> -
> if (skb_padto(skb, len)) {
> ret = NETDEV_TX_OK;
> goto txdone;
> @@ -1158,6 +1151,11 @@ static int rtl838x_eth_tx(struct sk_buff *skb, struct
> net_device *dev)
> h = &ring->tx_header[q][ring->c_tx[q]];
> h->size = len;
> h->len = len;
> + // On RTL8380 SoCs, small packet lengths being sent need
> adjustments
> + if (priv->family_id == RTL8380_FAMILY_ID) {
> + if (len < ETH_ZLEN - 4)
> + h->len -= 4;
> + }
>
> priv->r->create_tx_header(h, dest_port, skb->priority >> 1);
Yup, looks much better with that. No more FCS errors on the untagged
DHCP discovers.
Bjørn
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: realtek: Setup all VLANs with default configurations
On 08/05/2021 17:39, Bjørn Mork wrote:
But I'm not convinced it works so well for the default either... I see
this received on the native VLAN 1:
canardo:/tmp# tshark -nVi xeth0 -f 'udp port 67'
Running as user "root" and group "root". This could be dangerous.
Capturing on 'xeth0'
Frame 1: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits) on
interface 0
Interface id: 0 (xeth0)
Interface name: xeth0
Encapsulation type: Ethernet (1)
Arrival Time: May 8, 2021 16:56:20.581072322 CEST
[Time shift for this packet: 0.0 seconds]
Epoch Time: 1620485780.581072322 seconds
[Time delta from previous captured frame: 0.0 seconds]
[Time delta from previous displayed frame: 0.0 seconds]
[Time since reference or first frame: 0.0 seconds]
Frame Number: 1
Frame Length: 346 bytes (2768 bits)
Capture Length: 346 bytes (2768 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:bootp]
Ethernet II, Src: bc:a5:11:9f:e1:23, Dst: ff:ff:ff:ff:ff:ff
Destination: ff:ff:ff:ff:ff:ff
Address: ff:ff:ff:ff:ff:ff
..1. = LG bit: Locally administered address
(this is NOT the factory default)
...1 = IG bit: Group address
(multicast/broadcast)
Source: bc:a5:11:9f:e1:23
Address: bc:a5:11:9f:e1:23
..0. = LG bit: Globally unique address
(factory default)
...0 = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Frame check sequence: 0x80091000 incorrect, should be 0x63ff5c43
[Expert Info (Error/Checksum): Bad checksum [should be 0x63ff5c43]]
[Bad checksum [should be 0x63ff5c43]]
[Severity level: Error]
[Group: Checksum]
[FCS Status: Bad]
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255
0100 = Version: 4
0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
00.. = Differentiated Services Codepoint: Default (0)
..00 = Explicit Congestion Notification: Not ECN-Capable
Transport (0)
Total Length: 328
Identification: 0x (0)
Flags: 0x
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (17)
Header checksum: 0x79a6 [validation disabled]
[Header checksum status: Unverified]
Source: 0.0.0.0
Destination: 255.255.255.255
User Datagram Protocol, Src Port: 68, Dst Port: 67
Source Port: 68
Destination Port: 67
Length: 308
Checksum: 0xd82b [unverified]
[Checksum Status: Unverified]
[etc]
That seemingly magic number 0x80091000 instead of the expected FCS is
pretty suspicious. Leaking tag? Or what?
Yes, this looks like the DSA-tag in the packet buffer is not being overwritten
by the CRC.
Could you try out the following patch, which tries to follow the convolutions
of the SDK for the 8380,
with respect of buffer length and packet length when the CRC is being
calculated by offloading.
On my DLink 1210-10hp I see properly formed packets with small (<60 octets) and
larger size.
It fixes also the detection of DSA tags with a high port number (>=28) on the
8390.
diff --git a/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
b/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
index c5c6e3b6b7..9fe4fcd647 100644
--- a/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
+++ b/target/linux/realtek/files-5.4/drivers/net/ethernet/rtl838x_eth.c
@@ -1129,23 +1129,16 @@ static int rtl838x_eth_tx(struct sk_buff *skb, struct
net_device *dev)
/* Check for DSA tagging at the end of the buffer */
if (netdev_uses_dsa(dev) && skb->data[len-4] == 0x80 && skb->data[len-3]
> 0
- && skb->data[len-3] < 28 && skb->data[len-2] == 0x10
+ && skb->data[len-3] < priv->cpu_port &&
skb->data[len-2] == 0x10
&& skb->data[len-1] == 0x00) {
/* Reuse tag space for CRC if possible */
dest_port = skb->data[len-3];
+ skb->data[len-4] = skb->data[len-3] = skb->data[len-2] =
skb->data[len-1] = 0x00;
len -= 4;
}
len += 4; // Add space for CRC
- // On RTL8380 SoCs, the packet needs extra padding
- if (priv->family_id == RTL8380_FAMILY_ID) {
- if (len < ETH_ZLEN)
- len = ETH_ZLEN; // SoC not automatically padding to
ETH_ZLEN
- else
- len += 4;
- }
-
if (skb_padto(skb, len)) {
ret = NETDEV_TX_OK;
go
Re: realtek: Setup all VLANs with default configurations
Hi, Actually, you don't have to disable the profile_setups. This change is sufficient to make VLANs work (at least in the limited testing I've done): diff --git a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c index dfd773c5e6fc..5d764b6a32d6 100644 --- a/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c +++ b/target/linux/realtek/files-5.4/drivers/net/dsa/rtl83xx/rtl838x.c @@ -398,7 +398,7 @@ static void rtl838x_vlan_profile_setup(int profile) * On RTL93XX, the portmask is directly set in the profile, * see e.g. rtl9300_vlan_profile_setup */ - rtl838x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0xfff); + rtl838x_write_mcast_pmask(UNKNOWN_MC_PMASK, 0x1fff); } static inline int rtl838x_vlan_port_egr_filter(int port) No idea why or how. Just a magic value with a magic result, like most of the code. Come on Björn, it wasn't so magic if you could figure that out although you hadn't seen the code before. There is more and more understanding on how this piece of hardware works, even though we only have an SDK which is spaghetti and magic sauce and you might have noticed there are more and more comments in the latest additions. Yes, that was indeed my mistake, the second parameter is the mask of ports MC packets are flooded to as long as a multicast group has not been set up by the bridge, port 28 (= BIT 28) being the CPU port on the 8380. I thought all relevant traffic would anyway be trapped to the CPU, I did quite some testing setting up the traps. I was evidently wrong. I really don't think these changes have been tested well enough to be pushed into openwrt master yet. Based on this first impression, I would be surprised if there isn't more broken stuff. I asked for testing of this set of patches in the rtl83xx irc a week ago and the code was on GitHub since then. I got no feedback up til now when it ended up in master. I'll post a patch for all the architectures for this problem. Cheers, Birger ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: realtek: Setup all VLANs with default configurations
yes, counters are reset on every read. I guess I should have learned to do more vlan-testing. I'll try to figure out what is going on. Birger On 08/05/2021 17:39, Bjørn Mork wrote: Birger Koblitz writes: I tested the latest master on my 3 Zyxel devices, one for each SoC generation, the GS1900-10HP, the GS1900-48 and the XGS-1210-10. They got their IP addresses via DHCP on port 1 using the default network setup. I then tested pinging, multicast (VLC) and iperf between different non-management ports (2 and 3) and for multicast verified that nothing could be seen on the router's CPU-Port nor the management PC. I did not test anything specific to VLAN. I don't think it's suficient to test without vlan tagging when messing around with the vlan config on these switches. Experience has shown that there are a number of possible and real failure modes, where you forward with wrong tagging or filter on the wrong vid. But I'm not convinced it works so well for the default either... I see this received on the native VLAN 1: canardo:/tmp# tshark -nVi xeth0 -f 'udp port 67' Running as user "root" and group "root". This could be dangerous. Capturing on 'xeth0' Frame 1: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits) on interface 0 Interface id: 0 (xeth0) Interface name: xeth0 Encapsulation type: Ethernet (1) Arrival Time: May 8, 2021 16:56:20.581072322 CEST [Time shift for this packet: 0.0 seconds] Epoch Time: 1620485780.581072322 seconds [Time delta from previous captured frame: 0.0 seconds] [Time delta from previous displayed frame: 0.0 seconds] [Time since reference or first frame: 0.0 seconds] Frame Number: 1 Frame Length: 346 bytes (2768 bits) Capture Length: 346 bytes (2768 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ip:udp:bootp] Ethernet II, Src: bc:a5:11:9f:e1:23, Dst: ff:ff:ff:ff:ff:ff Destination: ff:ff:ff:ff:ff:ff Address: ff:ff:ff:ff:ff:ff ..1. = LG bit: Locally administered address (this is NOT the factory default) ...1 = IG bit: Group address (multicast/broadcast) Source: bc:a5:11:9f:e1:23 Address: bc:a5:11:9f:e1:23 ..0. = LG bit: Globally unique address (factory default) ...0 = IG bit: Individual address (unicast) Type: IPv4 (0x0800) Frame check sequence: 0x80091000 incorrect, should be 0x63ff5c43 [Expert Info (Error/Checksum): Bad checksum [should be 0x63ff5c43]] [Bad checksum [should be 0x63ff5c43]] [Severity level: Error] [Group: Checksum] [FCS Status: Bad] Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255 0100 = Version: 4 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 00.. = Differentiated Services Codepoint: Default (0) ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) Total Length: 328 Identification: 0x (0) Flags: 0x 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (17) Header checksum: 0x79a6 [validation disabled] [Header checksum status: Unverified] Source: 0.0.0.0 Destination: 255.255.255.255 User Datagram Protocol, Src Port: 68, Dst Port: 67 Source Port: 68 Destination Port: 67 Length: 308 Checksum: 0xd82b [unverified] [Checksum Status: Unverified] [etc] That seemingly magic number 0x80091000 instead of the expected FCS is pretty suspicious. Leaking tag? Or what? I merely verified via "bridge fdb"t that the entries in the forwarding table now use the vlan as forwarding ID together with the target MAC address. Before that they were using a fixed and very strange forwarding ID (4031 on the 8380) together with a MAC-address. At the moment I do not have access to these devices (in summer house) only a buggy DLink DGS 1210-10P, that does not want to bridge between ports with OpenWRT. I added some interesting debug possibility in my "pie" branch. copy debugfs.c over and you can use |cat /sys/kernel/debug/rtl838x/drop_counters| to see why the switch drops packets. root@OpenWrt:/# cat /sys/kernel/debug/rtl838x/drop_counters ALE_TX_GOOD_PKTS: 74 MAC_RX_DROP: 0 ACL_FWD_DROP: 0 HW_ATTACK_PREVENTION_DROP: 0 RMA_DROP: 0 VLAN_IGR_FLTR_DROP: 0 INNER_OUTER_CFI_EQUAL_1_DROP: 0 PORT_MOVE_DROP: 0 NEW_SA_DROP: 0 MAC_LIMIT_SYS_DROP: 0 MAC_LIMIT_VLAN_DROP: 0 MAC_LIMIT_PORT_DROP: 0 SWITCH_MAC_DROP: 0 ROUTING_EXCEPTION_DROP: 0 DA_LKMISS_DROP: 0 RSPAN_DROP: 0 ACL_LKMISS_DROP: 0 ACL_DROP: 0 INBW_DROP: 0 IGR_METER_D
Re: realtek: Setup all VLANs with default configurations
Birger Koblitz writes: > I tested the latest master on my 3 Zyxel devices, one for each SoC > generation, the GS1900-10HP, the GS1900-48 and the XGS-1210-10. They > got their IP addresses via DHCP on port 1 using the default network > setup. I then tested pinging, multicast (VLC) and iperf between > different non-management ports (2 and 3) and for multicast verified > that nothing could be seen on the router's CPU-Port nor the management > PC. I did not test anything specific to VLAN. I don't think it's suficient to test without vlan tagging when messing around with the vlan config on these switches. Experience has shown that there are a number of possible and real failure modes, where you forward with wrong tagging or filter on the wrong vid. But I'm not convinced it works so well for the default either... I see this received on the native VLAN 1: canardo:/tmp# tshark -nVi xeth0 -f 'udp port 67' Running as user "root" and group "root". This could be dangerous. Capturing on 'xeth0' Frame 1: 346 bytes on wire (2768 bits), 346 bytes captured (2768 bits) on interface 0 Interface id: 0 (xeth0) Interface name: xeth0 Encapsulation type: Ethernet (1) Arrival Time: May 8, 2021 16:56:20.581072322 CEST [Time shift for this packet: 0.0 seconds] Epoch Time: 1620485780.581072322 seconds [Time delta from previous captured frame: 0.0 seconds] [Time delta from previous displayed frame: 0.0 seconds] [Time since reference or first frame: 0.0 seconds] Frame Number: 1 Frame Length: 346 bytes (2768 bits) Capture Length: 346 bytes (2768 bits) [Frame is marked: False] [Frame is ignored: False] [Protocols in frame: eth:ethertype:ip:udp:bootp] Ethernet II, Src: bc:a5:11:9f:e1:23, Dst: ff:ff:ff:ff:ff:ff Destination: ff:ff:ff:ff:ff:ff Address: ff:ff:ff:ff:ff:ff ..1. = LG bit: Locally administered address (this is NOT the factory default) ...1 = IG bit: Group address (multicast/broadcast) Source: bc:a5:11:9f:e1:23 Address: bc:a5:11:9f:e1:23 ..0. = LG bit: Globally unique address (factory default) ...0 = IG bit: Individual address (unicast) Type: IPv4 (0x0800) Frame check sequence: 0x80091000 incorrect, should be 0x63ff5c43 [Expert Info (Error/Checksum): Bad checksum [should be 0x63ff5c43]] [Bad checksum [should be 0x63ff5c43]] [Severity level: Error] [Group: Checksum] [FCS Status: Bad] Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255 0100 = Version: 4 0101 = Header Length: 20 bytes (5) Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT) 00.. = Differentiated Services Codepoint: Default (0) ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0) Total Length: 328 Identification: 0x (0) Flags: 0x 0... = Reserved bit: Not set .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 64 Protocol: UDP (17) Header checksum: 0x79a6 [validation disabled] [Header checksum status: Unverified] Source: 0.0.0.0 Destination: 255.255.255.255 User Datagram Protocol, Src Port: 68, Dst Port: 67 Source Port: 68 Destination Port: 67 Length: 308 Checksum: 0xd82b [unverified] [Checksum Status: Unverified] [etc] That seemingly magic number 0x80091000 instead of the expected FCS is pretty suspicious. Leaking tag? Or what? > I merely verified via > "bridge fdb"t that the entries in the forwarding table now use the > vlan as forwarding ID together with the target MAC address. Before > that they were using a fixed and very strange forwarding ID (4031 on > the 8380) together with a MAC-address. At the moment I do not have > access to these devices (in summer house) only a buggy DLink DGS > 1210-10P, that does not want to bridge between ports with OpenWRT. > I added some interesting debug possibility in my "pie" branch. copy > debugfs.c over and you can use > > |cat /sys/kernel/debug/rtl838x/drop_counters| > > to see why the switch drops packets. root@OpenWrt:/# cat /sys/kernel/debug/rtl838x/drop_counters ALE_TX_GOOD_PKTS: 74 MAC_RX_DROP: 0
Re: realtek: Setup all VLANs with default configurations
Birger Koblitz 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
switch1
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 CESTbe: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 CEST34: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 CEST80: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 CESTbe: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 CEST34: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
Re: realtek: Setup all VLANs with default configurations
This is the configuration that was previously working. Note also, it works for about 400 (plus or minus 70) seconds and then stops. config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config device 'switch' option name 'switch' option type 'bridge' option macaddr '9c:c9:eb:aa:bb:cc' config bridge-vlan 'wan_vlan' option device 'switch' option vlan '1' option ports 'lan1' config interface 'wan' option ifname 'switch.1' option proto 'dhcp' config device 'wan_switch_1_dev' option name 'switch.1' option macaddr '9c:c9:eb:aa:bb:cc' config interface 'wan6' option ifname 'switch.1' option proto 'dhcpv6' option reqprefix '60' config bridge-vlan 'pub_vlan' option device 'switch' option vlan '2' option ports 'lan2 lan3 lan4 lan5 lan6 lan7 lan8' config interface 'pub' option proto 'static' option ipaddr '10.0.0.161' option ifname 'switch.2' option netmask '255.255.255.224' config device 'lan_switch_2_dev' option macaddr '9e:c9:eb:d8:d8:d0' option name 'switch.2' On Fri, May 7, 2021 at 10:41 PM Birger Koblitz wrote: > > 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 > > Cheers, >Birger > > On 08/05/2021 01:55, Russell Senior wrote: > > The recent commit 4342d27ec90cd0988fd3e62ccefbe66f2e691372 to OpenWrt > > seems to have broken the network on my Netgear GS108T v3. After about > > 300-500 seconds of uptime, the interface (in my case, switch.1 > > configured as WAN) stops receiving traffic. Nothing in dmesg or syslog > > at the time of failure. From tcpdump -i switch.1 I can see the device > > ARP'ing for the gateway address (which it received by DHCP) but not > > seeing anything come back. Rolling back to the commit immediately > > before and I don't see the problem and can ping the gateway > > indefinitely. > > > > Thanks! > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: realtek: Setup all VLANs with default configurations
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 Cheers, Birger On 08/05/2021 01:55, Russell Senior wrote: The recent commit 4342d27ec90cd0988fd3e62ccefbe66f2e691372 to OpenWrt seems to have broken the network on my Netgear GS108T v3. After about 300-500 seconds of uptime, the interface (in my case, switch.1 configured as WAN) stops receiving traffic. Nothing in dmesg or syslog at the time of failure. From tcpdump -i switch.1 I can see the device ARP'ing for the gateway address (which it received by DHCP) but not seeing anything come back. Rolling back to the commit immediately before and I don't see the problem and can ping the gateway indefinitely. Thanks! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: realtek: Setup all VLANs with default configurations
The recent commit 4342d27ec90cd0988fd3e62ccefbe66f2e691372 to OpenWrt seems to have broken the network on my Netgear GS108T v3. After about 300-500 seconds of uptime, the interface (in my case, switch.1 configured as WAN) stops receiving traffic. Nothing in dmesg or syslog at the time of failure. From tcpdump -i switch.1 I can see the device ARP'ing for the gateway address (which it received by DHCP) but not seeing anything come back. Rolling back to the commit immediately before and I don't see the problem and can ping the gateway indefinitely. Thanks! -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
