NWEthernetChannel crash when interface is reconnected to the system

Question

Created Apr ’21

Replies 2

Boosts 0

Participants 2

I am developing a service that implements a custom L3 protocol using NWEthernetChannel API from Network.framework.

I have noticed that when network interface (e.g. USB Ethernet dongle) is physically disconnected from the system, and then connected back, my application crashes with the following call stack:

Code Block (lldb) thread backtrace
* thread #6, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=EXC_I386_INVOP, subcode=0x0)
  * frame #0: 0x00000001002d5115 libdispatch.dylib`_dispatch_assert_queue_fail + 99
    frame #1: 0x00000001002d50aa libdispatch.dylib`dispatch_assert_queue + 122
    frame #2: 0x00007fff6f826209 libnetwork.dylib`nw_path_evaluator_create_flow + 121
    frame #3: 0x00007fff6fa7c6f0 libnetwork.dylib`__nw_ethernet_channel_handle_path_update_locked_block_invoke + 2896
    frame #4: 0x00007fff6fb7ccbf libnetwork.dylib`nw_path_enumerate_interface_options + 175
    frame #5: 0x00007fff6fa7b661 libnetwork.dylib`nw_ethernet_channel_handle_path_update_locked + 161
    frame #6: 0x00007fff6fa7b4e0 libnetwork.dylib`__nw_ethernet_channel_start_block_invoke + 512
    frame #7: 0x00007fff6f9239b4 libnetwork.dylib`__nw_path_necp_update_evaluator_block_invoke + 388
    frame #8: 0x00000001002d2844 libdispatch.dylib`_dispatch_call_block_and_release + 12
    frame #9: 0x00000001002d3826 libdispatch.dylib`_dispatch_client_callout + 8
    frame #10: 0x00000001002dadd7 libdispatch.dylib`_dispatch_lane_serial_drain + 777
    frame #11: 0x00000001002dbbc1 libdispatch.dylib`_dispatch_lane_invoke + 487
    frame #12: 0x00000001002d5c9a libdispatch.dylib`_dispatch_queue_override_invoke + 539
    frame #13: 0x00000001002e7391 libdispatch.dylib`_dispatch_root_queue_drain + 334
    frame #14: 0x00000001002e7e03 libdispatch.dylib`_dispatch_worker_thread2 + 127
    frame #15: 0x000000010036131b libsystem_pthread.dylib`_pthread_wqthread + 220
    frame #16: 0x000000010036049b libsystem_pthread.dylib`start_wqthread + 15

Is this behaviour expected, or is this a bug in the API implementation?
As a workaround, I currently delete the NWEthernetChannel object when its state changes to nw_ethernet_channel_state_failed. But given that it is a high-level API, I would expect it to resume automatically when the interface is reconnected, or at least not crash.

Answered by DTS Engineer in 671819022

Is this behaviour expected … ?

Well, generally crashes are not expected, no (-; Please file a bug about this, and then post your bug number here, just for the record.

As a workaround, I currently delete the NWEthernetChannel object
when its state changes to nw_ethernet_channel_state_failed.

That sounds like a reasonable workaround. But, yeah, I agree, you should not have to do this.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Boost

Answer 1

DTS Engineer OP

Apple

Apr ’21

Accepted Answer

Is this behaviour expected … ?

Well, generally crashes are not expected, no (-; Please file a bug about this, and then post your bug number here, just for the record.

As a workaround, I currently delete the NWEthernetChannel object
when its state changes to nw_ethernet_channel_state_failed.

That sounds like a reasonable workaround. But, yeah, I agree, you should not have to do this.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

1

Answer 2

ragafonov OP

Apr ’21

Hi Quinn,

Thanks for your feedback!

Please file a bug about this

Done! Here it is: FB9086784 (NWEthernetChannel crashes when interface is reconnected to the system)

Best regards,
Roman

0