Disclaimer: I don't know a thing about dSNAKE.
Once I had a closer look at a pair of USB/DP extender which uses UTP cables between them. They speak ethernet frames, so placing switch in between (with dedicated VLAN as well) still allowed them to communicate. Even though officially using ethernet switches in between is not supported.
What I observed was huge number of MAC addresses appearing in switch's FDB. My speculation is that these devices use ethernet frame structure, but don't adhere to proper ethernet header structure ... they simply fill ethernet frames, including frame headers, with payload. So basically (ab)using ethernet hardware (MII) as cheap L1 for their own communication.
Observed behaviour for sure can fill up FDB (and quickly) and switch is more than right to signal error state ... while still forwarding frames but without using FDB (which essentially means they start to behave as high-speed VLAN-aware ethernet hub, forwarding all frames to all eligible ports).
Once I had a closer look at a pair of USB/DP extender which uses UTP cables between them. They speak ethernet frames, so placing switch in between (with dedicated VLAN as well) still allowed them to communicate. Even though officially using ethernet switches in between is not supported.
What I observed was huge number of MAC addresses appearing in switch's FDB. My speculation is that these devices use ethernet frame structure, but don't adhere to proper ethernet header structure ... they simply fill ethernet frames, including frame headers, with payload. So basically (ab)using ethernet hardware (MII) as cheap L1 for their own communication.
Observed behaviour for sure can fill up FDB (and quickly) and switch is more than right to signal error state ... while still forwarding frames but without using FDB (which essentially means they start to behave as high-speed VLAN-aware ethernet hub, forwarding all frames to all eligible ports).
Statistics: Posted by mkx — Thu Jan 30, 2025 9:11 pm