Feature #4019: "ad hoc" detection on macOS - ndn-cxx - NDN project issue tracking system

Feature #4019

open

"ad hoc" detection on macOS

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

Status:

New

Priority:

Normal

Assignee:

Category:

Network

Target version:

Start date:

03/27/2017

Due date:

% Done:

80%

Estimated time:

Tags:

macOS

Description

When creating a multicast Ethernet or UDP face, use macOS-specific API to detect whether the underlying network interface is ad hoc.

Related issues 2 (1 open — 1 closed)

Blocked by NFD - Feature #3967: "ad hoc" property on multi-access face

Closed

Teng Liang

Actions

Blocks NFD - Feature #4113: Use auto-detected "ad hoc" attribute to create faces

New

Actions

Issue # Delay: days Cancel

History
Notes
Property changes

Actions

Copy link

Updated by Junxiao Shi over 7 years ago

Blocked by Feature #3967: "ad hoc" property on multi-access face added

Actions

Copy link

Updated by Davide Pesavento over 7 years ago

Status changed from New to Code review

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

Actions

Copy link

Updated by Junxiao Shi over 7 years ago

Status changed from Code review to In Progress
% Done changed from 0 to 50

This is only half done. The other half is enabling the feature in EthernetFactory and UdpFactory, which needs to wait for #3967 to close.

https://gerrit.named-data.net/3798 only adds a function in ndn::util::detail namespace, which would not be installed and thus is inaccessible from outside ndn-cxx.
The information should be exposed in ndn::util::NetworkInterface struct.

Actions

Copy link

Updated by Davide Pesavento over 7 years ago

Since the API is going to be implemented in ndn-cxx, this task should be moved to the corresponding project. Implementing automatic ad hoc detection (using this API) in the relevant transports/factories should be a separate task under NFD project.

Actions

Copy link

Updated by Alex Afanasyev over 7 years ago

Project changed from NFD to ndn-cxx
Category changed from Faces to Utils
Target version changed from v0.6 to v0.6

Actions

Copy link

Updated by Junxiao Shi over 7 years ago

Description updated (diff)

Actions

Copy link

Updated by Junxiao Shi over 7 years ago

Blocks Feature #4113: Use auto-detected "ad hoc" attribute to create faces added

Actions

Copy link

Updated by Junxiao Shi over 7 years ago

Would link-type of an airport interface change during its lifetime? Suppose the airport is initially connected to infrastructure WiFi, and then paired with an ad hoc network, what signal would NetworkMonitor emit?

Actions

Copy link

Updated by Alex Afanasyev over 7 years ago

Status can change during lifetime. This is test output (we don't have signals yet):

[20170605T053332.268385] awdl0: onStateChanged down -> running
[20170605T053332.268422] awdl0: link-type: multi-access
[20170605T053332.268678] awdl0: onAddressAdded fe80::c0b7:89ff:fee0:6450/64
[20170605T053332.268880] en0: onStateChanged down -> running
[20170605T053332.268910] en0: link-type: multi-access
[20170605T053332.269092] en0: onAddressAdded fe80::c88:70af:4793:1fda/64
[20170605T053334.275906] en0: onAddressAdded 10.0.0.2/24

[20170605T053335.276402] en0: onAddressAdded 2605:e000:1521:a5:10fc:5df3:e4c7:dd32/64
[20170605T053335.276444] en0: onAddressAdded 2605:e000:1521:a5:2540:97b1:afed:a94a/64

[20170605T053402.350086] en0: onStateChanged running -> down
[20170605T053402.350135] en0: link-type: adhoc
[20170605T053402.350360] awdl0: onStateChanged running -> down
[20170605T053402.350390] awdl0: link-type: adhoc
[20170605T053402.350582] en0: onAddressRemoved 10.0.0.2/24
[20170605T053402.350608] en0: onAddressRemoved 2605:e000:1521:a5:10fc:5df3:e4c7:dd32/64
[20170605T053402.350628] en0: onAddressRemoved 2605:e000:1521:a5:2540:97b1:afed:a94a/64
[20170605T053402.350645] en0: onAddressRemoved fe80::c88:70af:4793:1fda/64
[20170605T053402.350733] awdl0: onAddressRemoved fe80::c0b7:89ff:fee0:6450/64
[20170605T053404.351560] en0: onStateChanged down -> running
[20170605T053404.351587] en0: link-type: adhoc
[20170605T053404.353031] en0: onAddressAdded fe80::c88:70af:4793:1fda/64

[20170605T053423.398990] en0: onAddressAdded 169.254.130.89/16
[20170605T053425.400186] en0: onStateChanged running -> down
[20170605T053425.400236] en0: link-type: multi-access
[20170605T053425.400548] awdl0: onStateChanged down -> running
[20170605T053425.400586] awdl0: link-type: multi-access
[20170605T053425.400803] awdl0: onAddressAdded fe80::c0b7:89ff:fee0:6450/64
[20170605T053425.400938] en0: onAddressRemoved 169.254.130.89/16
[20170605T053425.400980] en0: onAddressRemoved fe80::c88:70af:4793:1fda/64

Actions

Copy link

#10

Updated by Junxiao Shi over 7 years ago

It seems that the airport interface will go DOWN when changing between multi-access and ad-hoc. In this case, a separate signal is not needed.

Actions

Copy link

#11

Updated by Davide Pesavento over 7 years ago

Junxiao Shi wrote:

It seems that the airport interface will go DOWN when changing between multi-access and ad-hoc. In this case, a separate signal is not needed.

I think that should really be NO_CARRIER, not DOWN, but https://gerrit.named-data.net/3794 patchset 14 cannot distinguish between the two. I've left a comment there with a potential solution.

Actions

Copy link

#12