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 <m...@birger-koblitz.de> 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