Switch chip not working?

Omnia hardware Omnia HW help
57

I believe it is compiled into the kernel. Without it all the vlan configs on the cpu (like vlan 7 for Deutsche Telekom VDSL) would not work.

root@turris:/proc# cat /proc/config.gz | gzip -cd | grep 8021Q
CONFIG_VLAN_8021Q=y

While some advanced options might be missing, basic vlan based separation should work with the switch chip in the Omnia. That switch chip was pretty reliable in other devices I used so far.
The best way of implementing is to assume all VLAN IDs are global to the switch (some advanced switches can have the same vlan id representing different L2 networks) and that only basic ingress/egress filtering exists.
That means (for tag based VLANs):

  • a tagged port is going to output all traffic if part of the VLAN with vlan tag left intact
  • a tagged port will accept all tagged traffic with vlan tags which the port is a member of (note: the switch chip can be run in an mode which accepts all tagged traffic even if not for a vlan id it is member in)
  • a tagged port will output traffic matching is PVID without a vlan tag
  • a tagged port will put any incoming untagged traffic into the vlan matching it’s PVID
  • a untagged port will only output traffic of the vlan matching it’s PVID and the traffic will be without a VLAN tag
  • a untagged port will only accept traffic without a vlan tag and will put it into the VLAN matching it’s PVID (note that the switch chip supports a mode where it accepts tagged traffic for all VLANs too).

To test the segregation you could:

  • put the CPU port (port 5) into tagged mode
  • configure VLAN 1 on the CPU port (but no other VLANs)
  • configure LAN0 to be part of VLAN 1 in untagged mode
  • configure LAN1 to be part of VLAN 1 in untagged mode
  • ensure all other ports are not part of VLAN 1
  • create VLAN 3 and assign LAN2 to it in untagged mode
  • give VLAN1 (eth0.1) an IP on the omnia (CPU)
  • connect two clients to LAN0 and LAN1 and give them an IP network assigned to VLAN1 in the previous step
  • ping the client which should work and show the ethernet src/dst to be the MACs of the two clients
  • move one client (e.g. the one on LAN1) to LAN2 port and observe that the pings stop as the two clients can’t see each other

Note the reason for not presenting the VLAN 3 to the CPU is that it removes a lot of possible leaks.
By default Linux IP stack attaches to all interfaces and by default accepts/forwards even if if the packet arrives on an interface with no IP. (see sysctl rp_filter as one pointer)

@anon50890781 I suspect that you got a leak in your config somewhere. I’d hazard a guess that if you successfully ping between hosts in different VLANs you will see that the src/dst MAC is not the one of the two hosts (likely it is one belonging to Omnia).

As @protree mentioned, feel free to share your config (and preferably a tcpdump/wireshark packetdump) of the two clients (filter on icmp and arp as that is the only two interesting parts).

1 Like