I’ve spend the last few hours trying to get to the bottom of some network issues, and it seems that for some reason arp replies are not properly returned when send over a vlan interface on one of the switch ports. The same config works fine when using the WAN port.
This is the config I used to test this:
config interface 'lan' option type 'bridge' option proto 'static' option netmask '255.255.255.0' option ipaddr '10.0.0.15' option gateway '10.0.0.14' option dns '184.108.40.206' option ifname 'eth2.1 lan2 lan3.1 lan4'
I’ve got an upstream (from another Turris Omnia) which has tagged traffic on vlan 1 and 2. If I plug that into the WAN port (eth2) everything is fine. However if I plug the cable into lan3 I never receive arp responses. I can see the request reaching the target host and the response being send there. Arp requests from the Turris Omnia itself do work correctly. So it seems for some reason arp responses never cross the bridge on a tagged interface.
The connection is otherwise fine, as long as I don’t clear the arp cache there are no connection issues with systems for which the mac-address is already known.
I can’t really see what is causing this, but based on what I find searching it seems to me it has something to do with the DSA based configuration of the switch. Maybe it even is some kernel bug.
Are there any known issues which might cause this?
Now this is just the test case, for the real setup I can’t use the WAN port. So I’d like to find some way to work around this. For me the nicest solution would be if I could map one of the CPU ports directly onto one of the LAN ports, as I guess that would work around this issue. Is it possible to change the switch config in a way somewhat similar to how that was done in TOS 3.x?
And if anyone sees another workaround I’d be happy to hear that too