Project

General

Profile

Feature #4019

"ad hoc" detection on macOS

Added by Junxiao Shi about 3 years ago. Updated about 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Network
Target version:
-
Start date:
03/27/2017
Due date:
% Done:

80%

Estimated time:

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

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

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

Actions

History

#1

Updated by Junxiao Shi about 3 years ago

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

Updated by Davide Pesavento about 3 years ago

  • Status changed from New to Code review
#3

Updated by Junxiao Shi about 3 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.

#4

Updated by Davide Pesavento almost 3 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.

#5

Updated by Alex Afanasyev almost 3 years ago

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

Updated by Junxiao Shi almost 3 years ago

  • Description updated (diff)
#7

Updated by Junxiao Shi almost 3 years ago

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

Updated by Junxiao Shi almost 3 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?

#9

Updated by Alex Afanasyev almost 3 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
#10

Updated by Junxiao Shi almost 3 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.

#11

Updated by Davide Pesavento almost 3 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.

#12

Updated by Alex Afanasyev almost 3 years ago

  • Status changed from In Progress to New
  • Assignee deleted (Alex Afanasyev)
  • % Done changed from 50 to 80

Detection implemented, but not integrated with NetworkMonitor yet.

#13

Updated by Junxiao Shi over 2 years ago

  • Category changed from Utils to Network
#14

Updated by Davide Pesavento about 2 years ago

  • Target version deleted (v0.6)

Also available in: Atom PDF