Limit PTP addresses to configured network interface

[rmounce]

This is a conservative change. I think I have identified an even better fix, but with more risk of regression.

Without this change (or with no general.interface configured) every address of the ShairPort Sync server seems to be advertised via PTP, including many internal Docker networks that are not reachable from elsewhere. My AirPlay sources (at least macOS 12.7.2 & iOS 17.3.1) send a lot of PTP messages to all of these addresses in parallel, most of which are rejected by my firewall.

With this change and when general.interface is set, only addresses for that interface are advertised for PTP. Even in this case my ShairPort Sync server still receives 4x seemingly duplicate streams of PTP messages to each of those addresses (static IPv4, link-local IPv6, ULA IPv6, public IPv6). The actual audio only goes to the public IPv6 address in my case.

I stumbled upon a potentally even better fix by accident when I mucked up the logic during testing: Don't advertise any addresses here. ShairPort still worked fine. PTP messages are still sent to the same address as the audio stream (public IPv6 address in my case) and recognised by ShairPort ("Connection 1: AP2 PTP connection from IPHONE_IPV6_ADDR"). Multi-room sync between ShairPort & a HomePod Mini seemed good. For now I'm going to run my build with the following hack as it minimises network traffic without any apparent drawbacks.

                //if ((iap->ifa_addr) && (iap->ifa_netmask) && (iap->ifa_flags & IFF_UP) &&
                //    ((iap->ifa_flags & IFF_LOOPBACK) == 0)) {
                // AirPlay sources seem to use the correct PTP address if
                // we don't advertise any addresses here.
                if (false) {

Testing performed:

• Built & run in Docker

[mikebrady]

Thanks. I'm going to have to take a careful look at this... 🙂

[mikebrady]

Thanks for this interesting idea. The problem here, of course, that we don't have any specification of what should be included here, so all we know is what seems to be what expected, and above all, what works. So, while it might work perfectly for you, I'd be a bit reluctant to incorporate it. Whaddya think?

[rmounce]

Fair enough. Perhaps I could submit another PR to control my hack with a new option like advertise_ptp_addresses that defaults to yes, the current behaviour?

I do think this PR to limit by interface is fairly safe (I can't imagine a scenario where users that are explicitly configuring an interface would also want to receive PTP traffic on addresses associated with all other interfaces), but it's a half measure so I'd be happy to drop it in favour of the more aggressive, opt-in approach.

[mikebrady]

Apologies for the delay. I think the PR is a good idea alright, but I think it would be better not to go any further. Every extra feature and setting brings with it a requirement to maintain and test it into the future, and so I'm sure you can understand that there is a very strong motivation to avoid adding new ones.

[mikebrady]

Many thanks for this!