New Feature Ready for Review: VLAN Support

[santa47]

This is generally better handled by letting the os network stack do its job, and at most run namespacing for isolation for the clients. Its total overkill to have the application understand stuff below layer 3 when the stack itself is designed to handle all of this trivially already.

Like you could add support for vxlan, qinq etc, or just configure the virtual interfaces on the box properly in about 4 lines of netconf and just tap the virtual interface and avoid all this extra work duplicating the effort.

[mystery]

This is generally better handled by letting the os network stack do its job, and at most run namespacing for isolation for the clients. Its total overkill to have the application understand stuff below layer 3 when the stack itself is designed to handle all of this trivially already.

Like you could add support for vxlan, qinq etc, or just configure the virtual interfaces on the box properly in about 4 lines of netconf and just tap the virtual interface and avoid all this extra work duplicating the effort.

If that would have worked, I would have done that. I spent extensive time trying to figure out a solution without modifying the application code.

The issue is related to the TP-LINK switch I have, and how it does 802.1q tagging. Because some of the packets end up VLAN tagged and some do not (due to the mechanics of the mirror switch port), simply assigning VLANs at the network stack level does not solve it.

Thanks for your suggestion, though.

Edit: I would also argue that doing things by "letting the os network stack do its job" seems to be ignorant of the fact that seq itself is doing packet analysis already. It's a moot point.

[santa47]

You can easily bridge the tagged and untagged interface in 2 lines of netconfig....