Project

General

Profile

Actions

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:

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 open1 closed)

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

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

Actions
Actions #1

Updated by Junxiao Shi over 7 years ago

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

Updated by Davide Pesavento over 7 years ago

  • Status changed from New to Code review
Actions #3

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 #4

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 #5

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 #6

Updated by Junxiao Shi over 7 years ago

  • Description updated (diff)
Actions #7

Updated by Junxiao Shi over 7 years ago

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

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 #9

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 #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 #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 #12

Updated by Alex Afanasyev over 7 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.

Actions #13

Updated by Junxiao Shi over 7 years ago

  • Category changed from Utils to Network
Actions #14

Updated by Davide Pesavento almost 7 years ago

  • Target version deleted (v0.6)
Actions #15

Updated by Davide Pesavento over 4 years ago

  • Tags set to macOS
Actions

Also available in: Atom PDF