NFD » ndn-cxx

Peter investigated what APIs on macOS platform provide similar functionality as Linux RTNL used in #3353.

I did some research on the topic, there aren’t many alternatives for OS X and found something that might be useful.

1/ Darwin Notify Center seems ambiguous to me, even though userInfo parameter is supplied in the notification callback, the documentation explicitly says that "If the notification center is a Darwin notification center, this value must be ignored.”. Thus, relying on it, may be risky.

2/ I found an alternative to the RTNL in OS X - seems that you need to look into Network Kernel Extensions which may provide both control and notifications APIs for network kernel events (generated by network driver, for instance).

Davide's answer to this was:

At least superficially, this NKE API looks powerful enough for our purposes, I believe it could be the most promising approach for implementing the NetworkMonitor on macOS.

Unfortunately (and unsurprisingly) it's almost completely undocumented. I found some code in Wireshark that uses this API to monitor arrival/removal of network interfaces (we need more than that). I also found the definition of some constants and structures that are needed to use the API doc source. The KEV_DL_* constants are not described anywhere, so we'll need to do some trial and error...

One major(?) drawback is that only root can create the PF_SYSTEM socket to receive the network event notifications :-(

I talked to Weiwei on 20161121 and she agreed to work on this issue.
This is blocked by #3353, however investigations on macOS APIs can start right now.

Alex Afanasyev wrote:

https://gerrit.named-data.net/#/c/3794 implementation not extremely efficient, but it should not be a bottleneck in our operations.

During the hackathon you mentioned possible memory leaks in the code, did you check for those?

Also, it does not support MTU changes, as macOS seem to be lacking a mechanism to notify about such changes. If it is a critical element, we can implement it through polling, but then how often would we want to poll information from interfaces? (I would vote for not implementing it for now.)

Agreed. Supporting runtime MTU changes is a "nice to have" feature, but by no means critical. We survived without it so far, and as far as I know nobody requested it. Also, people can always recreate the face(s) after changing MTU.

During the review of https://gerrit.named-data.net/3978 patchset5, it is discovered that macOS implementation of NetworkMonitor leaves NetworkAddress::getScope() as NOWHERE, resulting in addresses being unusable. The address scope information shall be extracted from the OS.

Junxiao Shi wrote:

During the review of https://gerrit.named-data.net/3978 patchset5, it is discovered that macOS implementation of NetworkMonitor leaves NetworkAddress::getScope() as NOWHERE, resulting in addresses being unusable. The address scope information shall be extracted from the OS.

https://gerrit.named-data.net/4028

Alex Afanasyev wrote:

Davide will address distinguish between DOWN and NO_CARRIER.

From gerrit:

You can inspect the interface flags to do that (ifa_flags) which means you need to call updateInterfaceInfo before calculating the interface state. Then:

• if isActive => InterfaceState::RUNNING
• if !isActive && flags contain RUNNING => InterfaceState::NO_CARRIER
• if flags don't contain RUNNING or don't contain UP => InterfaceState::DOWN

So, I've spent many hours on this, but there seems to be no way to get a notification from SCDynamicStore when the interface flags change.
Interestingly enough, the low-level API (a PF_SYSTEM/SYSPROTO_EVENT socket) does provide such a notification. I don't want to rewrite the whole NetworkMonitorImplOsx backend just for this though.

Given that this is a minor feature, and it's not clear if we really need it in NFD, I think we can ignore the distinction between DOWN and NO_CARRIER on macOS for now.

Junxiao Shi wrote:

Davide's answer to this was:

[...]
One major(?) drawback is that only root can create the PF_SYSTEM socket to receive the network event notifications :-(

Correction: I've tried doing that on macOS Sierra and it worked (I was receiving notification messages, at least the basic ones) even without root privileges.