UNIX domain socket ports

[dsseng]

Like /run/ptp4l and /run/ptp4lro ports ptp4l creates to offer management capabilities. These are useful for testing and local management. I use /run/ptp4lro in PipeWire to determine current sync state and GM identity from within a user session. pmc tool from the linuxptp project also offers similar functionality. If wanted I could write a similar utility for statime and using its PTP serialization library.

If nobody has objections I could try myself at implementing this type of ports.

[cikzh]

We're actually working on the readonly part right now. I've created a draft pull request (#390), so you can check it's progress. Our first goal is to get metrics from statime-linux to be used in a Prometheus exporter, but eventually our plan is to implement a tool similar to ntp-ctl eventually. See https://docs.ntpd-rs.pendulum-project.org/man/ntp-ctl.8/ and https://github.com/pendulum-project/ntpd-rs/blob/main/ntpd/src/ctl.rs.

Maybe you can try implementing the ctl itself?

Note that we're planning to finish this PR in the coming weeks, so the implementation might be subject to rigorous changes and it might be wise to wait for it to be merged.

[dsseng]

Perhaps this PR implements Statime-specific management/monitoring protocol. What I asked for (and is willing to implement after approval) is to talk using PTPv2 MGMT, but over a UNIX socket. These are universal and well-defined for the things I ask for from PipeWire. Other stuff might also be done as extensions (linuxptp has some vendored TLVs not defined in standards). For my purpose it doesn't feel right to create extra code from both sides while we have a part of the standard for it (I managed to run GET PARENT_DATA_SET using pmc via network on Statime, so it supports the thing)

[rnijveld]

We think our setup is better than what ptp4linux offers here. Specifically for the /run/ptp4lro port: that port implements the full PTP over the wire protocol, thus it will need to be both read from and written to in order for a client to receive the read only information. In our version of this, the client just connects and immediately receives all the information, meaning that no write permissions are needed and we never have to do any un-trusted input validation here, and there is no chance of escalation here. Additionally, processing it as a PTP port internally would mean adding all kinds of privilege checks to make sure that we never respond to MGMT commands from ports that we don't trust, creating more possibilities for mistakes. I just think that management of PTP should be done out of band, and not within the PTP protocol, it doesn't make much sense to me and sounds like asking for security troubles (especially if those commands could modify daemon state).

It should be possible to use our stats UNIX socket as a base though and create a (separate binary) adapter that connects to the statime-linux stats socket whenever the PTP MGMT request comes in requesting the instance information and then sends that information back to the client in PTP MGMT format. If you'd like to implement something along those lines, we'd love to adopt it! Any thoughts?

[dsseng]

Well, sounds reasonable. Not sure I'll do that soon, but makes sense. PTP management protocol is standardized though so might be beneficial for some use cases