Dear gentlemen, this is not a pressing issue. Just my lunatic idea that would help me in the lab at the moment...
Every once in a while, on random occasions, I have an opportunity to review an Ethernet switch for its practical PTP capabilities. If I'm lucky, I have at least two pieces of the switch on the lab desk, but sometimes I only have one. A particular prospective application is the electric energy business, i.e. the power profile = L2 multicast P2P. And, one of the test setups that have proven useful, is running PTP through a VLAN trunk, in multiple simultaneous sessions. There have been two different styles of running PTP (power profile) through a VLAN trunk: A) the old way: PTP just a single session in the default VLAN, possibly untagged, seeping to all the untagged VLAN access ports on the switch (ignoring VLAN isolation) B) the more modern way: Announce+Sync+Follow-up properly tagged, running in custom VLAN's, only the PDelay running either tagged with the default VLAN, or untagged (on the trunk). Now - to test the latter without a second switch, i.e. if I should want to plug the trunk from the switch into a Linux box, I am out of options how to cobble together the "traffic mix" in Linux. I can certainly bind ptp4l to a VLAN subinterface, but in that case, PDelay traffic gets tagged as well. I've noticed the nftables' "bridge" address family, allowing me to filter packets while passing through a soft-bridge device. No clues if this would work per output interface for multicast destinations. Plus, I haven't found any way to filter the "opaque" PTP frame structure (unknown to nftables), within the PTP ethertype, on ptp.v2.message_id (as per the Wireshark display filter syntax). Even if I could pull this off, I would only be able to run one such session against the VLAN trunk, because in principle only one ptp4l instance can handle the shared PDelay in the default VLAN. Principally, to approach the problem systematically, I'd have to code PTP support into the Linux soft-bridge :-) Not gonna happen, and there's hardly any point beyond my today's hallucination. AFAICT, ptp4l doesn't support VLAN tagging internally - which is perfectly understandable, and probably has been debated before. Let me know if I'm missing something :-) Frank _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel