Project

General

Profile

Actions

Feature #3817

closed

NetworkMonitor fine-grained signals for macOS

Added by Junxiao Shi over 7 years ago. Updated almost 4 years ago.

Status:
Closed
Priority:
Normal
Category:
Network
Target version:
Start date:
03/25/2017
Due date:
% Done:

100%

Estimated time:
6.00 h
Tags:

Description

In NetworkMonitor, emit fine-grain signals for NIC addition/removal and IP address changes on macOS platform.


Related issues 2 (1 open1 closed)

Related to ndn-cxx - Feature #5097: Distinguish DOWN and NO_CARRIER in NetworkMonitor for macOSNew

Actions
Blocked by ndn-cxx - Feature #3353: NetworkMonitor: emit fine-grained signals when the state of a network interface changesClosedDavide Pesavento

Actions
Actions #1

Updated by Junxiao Shi over 7 years ago

  • Blocked by Feature #3353: NetworkMonitor: emit fine-grained signals when the state of a network interface changes added
Actions #2

Updated by Junxiao Shi over 7 years ago

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 :-(

Actions #3

Updated by Junxiao Shi over 7 years ago

  • Assignee set to Weiwei Liu
Actions #4

Updated by Junxiao Shi over 7 years ago

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.

Actions #5

Updated by Davide Pesavento about 7 years ago

  • Assignee deleted (Weiwei Liu)
Actions #6

Updated by Alex Afanasyev about 7 years ago

  • Status changed from New to In Progress
  • Assignee set to Alex Afanasyev
Actions #7

Updated by Alex Afanasyev about 7 years ago

  • Status changed from In Progress to Code review
  • Start date set to 03/25/2017
  • % Done changed from 0 to 80
Actions #8

Updated by Alex Afanasyev about 7 years ago

  • % Done changed from 80 to 90

https://gerrit.named-data.net/#/c/3794 implementation not extremely efficient, but it should not be a bottleneck in our operations. 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.)

Actions #9

Updated by Davide Pesavento about 7 years ago

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.

Actions #10

Updated by Davide Pesavento almost 7 years ago

  • Blocks Feature #4024: NetworkMonitor: stub implementation added
Actions #11

Updated by Davide Pesavento almost 7 years ago

  • Subject changed from NetworkMonitor fine-grain signals for macOS to NetworkMonitor fine-grained signals for macOS
Actions #12

Updated by Alex Afanasyev almost 7 years ago

  • Status changed from Code review to New
  • Assignee changed from Alex Afanasyev to Davide Pesavento

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
Actions #13

Updated by Davide Pesavento almost 7 years ago

  • Blocks deleted (Feature #4024: NetworkMonitor: stub implementation)
Actions #14

Updated by Junxiao Shi over 6 years ago

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.

Actions #15

Updated by Junxiao Shi over 6 years ago

  • Category changed from Utils to Network
Actions #16

Updated by Davide Pesavento over 6 years ago

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

Actions #17

Updated by Davide Pesavento over 6 years ago

  • Status changed from New to In Progress
Actions #18

Updated by Davide Pesavento over 6 years ago

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.

Actions #19

Updated by Davide Pesavento over 6 years ago

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.

Actions #20

Updated by Davide Pesavento over 6 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 90 to 100

Closing, per note-18.

Actions #21

Updated by Davide Pesavento almost 4 years ago

  • Related to Feature #5097: Distinguish DOWN and NO_CARRIER in NetworkMonitor for macOS added
Actions #22

Updated by Davide Pesavento almost 4 years ago

  • Tags set to macOS
Actions

Also available in: Atom PDF