NFD

To avoid a jumbo commit, I'll break down as much as possible.

https://gerrit.named-data.net/4003 extends NetworkInterfacePredicate to accept ndn::net::NetworkInterface in addition to NetworkInterfaceInfo. The latter will eventually be removed.

https://gerrit.named-data.net/4004 changes EthernetTransport and EthernetChannel constructors to use ndn::net::NetworkInterface instead of NetworkInterfaceInfo. The callers, including EthernetFactory and test suites, are still using nfd::listNetworkInterfaces() which returns NetworkInterfaceInfo, and need to do a conversion into ndn::net::NetworkInterface.

https://gerrit.named-data.net/4036 changes TcpFactory prohibited endpoint set to use NetworkMonitor instead of nfd::listNetworkInterfaces().
If a local channel listens on an ANY address, the expected behavior is to prohibit face creation toward any of the local addresses.
Previous implementation achieves this by enumerating all local IP addresses during channel creation, and adding multiple entries into the container.
New implementation only adds a single entry with ANY address into the container, while the enumeration result from NetworkMonitor is used when determining whether a remote endpoint would be prohibited.

What was the original motivation behind these "prohibited endpoints" anyway? That logic was introduced in commit ca53ac6b003ef1d0bd630fd3074fe3ef38967c07, which references #1414 and #1427, but neither explains why we can't allow NFD to connect to itself.

ProtocolFactory subclass instances in test suites have been changed to be constructed with NetworkMonitorStub rather than NetworkMonitor. However, existing test cases for UdpFactory were relying on real network interfaces. https://gerrit.named-data.net/4086 patchset3 adopts a temporary solution which copies real network interfaces into NetworkMonitorStub. I choose copying rather than constructing UdpFactory from a real NetworkMonitor because in #4026, this test suite will be expanded to consider interactions between NetworkMonitor and multicast configuraton changes. By that time, an uncontrollable NetworkMonitor is almost useless. I understand that a multicast UDP face can only be created on a real netif, and the plan for #4026 is to populate NetworkMonitorStub with a mix of MulticastUdpTransport-capable real netifs and other fake netifs that are either incapable or rejected by configuration.

https://gerrit.named-data.net/4088 EthernetFactory

NFD start log indicates UDP multicast faces, Ethernet channels, and Ethernet multicast faces are created:

vagrant@m0212:~/NFD$ sudo build/bin/nfd --config ../nfd.conf 
1502061291.014864 INFO: [EthernetFactory] enabling unicast channels
1502061291.014901 INFO: [EthernetFactory] enabling multicast on 01:00:5e:00:17:aa
1502061291.015418 INFO: [UdpFactory] enabling multicast on 224.0.23.170:56363
1502061291.016957 DEBUG: [EthernetFactory] Not creating channel on lo: netif is loopback
1502061291.016989 DEBUG: [EthernetFactory] Not creating multicast face on lo: netif cannot multicast
1502061291.016996 DEBUG: [UdpFactory] Not creating multicast face on lo: netif cannot multicast
1502061291.017006 DEBUG: [EthernetFactory] Creating channel on eth0
1502061291.051164 DEBUG: [EthernetFactory] Creating multicast face on eth0
1502061291.081208 DEBUG: [UdpFactory] Not creating multicast face on eth0: no IPv4 address
1502061291.083808 DEBUG: [UdpFactory] Creating multicast face on eth0

https://gerrit.named-data.net/4089 deletes NetworkInterfaceInfo which is no longer needed.

1-argument constructor of FaceSystem was marked DEPRECATED, but was not removed. During code review, Junxiao said:

This is still used in FaceManager test suite, which I'll get to in another commit. I mark DEPRECATED as a reminder.

When do you intend to do this?

Reply to note-22:

This is noted in #3377. Unfortunately I do not have the resource to perform that task.