search

eduvpn / apple

app for iOS and macOS
Other
62 stars 18 forks source link

Spontaneous disconnect on macOS when using Bluetooth/AirDrop #307

Closed efef closed 4 years ago

efef commented 4 years ago

Sometimes the VPN session spontaneous drops (and reconnects).

An user reported that using airdrop or bluetooth will trigger VPN drop. Have tried on my macbook with a bluetooth mouse. When disable bluetooth, while using mouse, nothing happens. However when enable bluetooth again the VPN will drop.

efef commented 4 years ago

tested with Let's Connect 2.1.7 (appstore version)

joosth9n commented 4 years ago

Just tried while Let's Connect was connected:

I couldn't reproduce the issue this way, but I don't have a bluetooth mouse available for example.

I was using:

joosth9n commented 4 years ago

@efef Are you using macOS 10.15.5 too?

efef commented 4 years ago

@joosthoogendoorn 10.14.6

roop commented 4 years ago

@efef Can you get the tunnel log after this drop+reconnect happens (and before it disconnects)?

Edit: By tunnel log, I mean what we get by clicking on "View log" in the app.

joosth9n commented 4 years ago

It might have something to do with AWDL (Apple Wireless Direct Link). It works by using its own network interface, typically "awdl0", by using the same physical interface as "en0". It shouldn't, but at least for Airdrop (as it uses WiFi) I can imagine it can cause problems. Why using Bluetooth could give the same symptoms is not clear to me yet, but it's using the AWDL protocol too.

Google comes up with one similar looking problem:

https://community.cisco.com/t5/vpn/cisco-anyconnect-constantly-reconnecting-on-macbook-pro/m-p/3869153

Things which are said in that forum:

"In the past month my VPN AnyConnect is constantly reconnecting."

"I think you may be hitting this issue: Apple introduced hardware changes in their 2018 models (2018 MacBook Pro, 2018 MacBook Air, and 2018 Mac mini in which also include their new T2 Security Chip). It has been determined that due to Apple’s changes, features/functions specific to AWDL (ie: AirDrop, Apple Watch, AirPlay, BlueTooth, etc), in which all use Apple’s dedicated ‘awdl0 interface’, are handled differently by the hardware."

"I disabled air drop as per workaround instructions. And It does seem to be working without any reconnecting."

"I have the same issue and disabling air drop did not resolve it. I have to disable bluetooth entirely."

"This fixed the issue till 10.14.6 came out. Now it’s back again."

@efef Are you by any chance using one of the following or later?: a 2018 MacBook Pro, 2018 MacBook Air or 2018 Mac Mini.

@efef And is the user by any chance using macOS 10.14.6 too on the same or later hardware?

efef commented 4 years ago

Without bluetooth/airdrop 'trick' I gathered logging when the disconnect happened.

On 10.15.4. I successfully connected the eduVPN app (2.1.7) to nl.eduvnp.org. The icon became 'green'. I did not yet see ipaddress. Next icon become yellow and reconnect happened spontaneously.

I have both app logging and console logging with search "process:eduVPN any:error"

connection_log.connect_disconnect_connect.txt console_log.connect_disconnect_connect.txt

joosth9n commented 4 years ago

On 10.15.4. I successfully connected the eduVPN app (2.1.7) to nl.eduvnp.org. The icon became 'green'. I did not yet see ipaddress. Next icon become yellow and reconnect happened spontaneously.

I had this exact same symptom today, but only one time, with both the eduVPN app and the Let's Connect app. In both cases the connection was restored after ~30 seconds. In logging I saw the same as in the logging provided by @efef :

2020-06-05 10:20:48.117 DEBUG NEUDPSocket.observeValueInTunnelQueue():179 - Socket has a better path 2020-06-05 10:20:48.117 DEBUG OpenVPNTunnelProvider.socketHasBetterPath():506 - Stopping tunnel due to a new better path 2020-06-05 10:20:48.117 DEBUG OpenVPNTunnelProvider.logCurrentSSID():826 - Current SSID: none (disconnected from WiFi) 2020-06-05 10:20:48.125 ERROR OpenVPNSession.doReconnect():1290 - Trigger reconnection (error: networkChanged) 2020-06-05 10:20:48.125 ERROR OpenVPNTunnelProvider.sessionDidStop():584 - Session did stop with error: networkChanged

I didn't find a way yet to reproduce it (including a reboot for example), every subsequent Connect runs fine, with Bluetooth and Airdrop enabled.

This symptom and logging "Socket has a better path" happens in case "For example, if the session is established over a cellular data network and Wi-Fi is now available, then the session has a better path available" and will cause a reconnect. ( https://developer.apple.com/documentation/networkextension/nwudpsession/1406231-hasbetterpath ) It's not clear to me yet why this would happen in for example my case when I wasn't switching networks and upon a first connect, which isn't reproducible anymore.

Anyway, the symptom we see here seems to be different from the symptom in the first post of this issue: "An user reported that using airdrop or bluetooth will trigger VPN drop."

@efef Can you reproduce a reconnect symptom on macOS 10.15.4 while playing with Bluetooth or Airdrop?

And did you have the same outcome as me where on every subsequent Connect the reconnect symptom wouldn't show up anymore, so it was only one time?

efef commented 4 years ago

Was about to try something else but experienced a disconnect directly after connecting to nl.eduvpn.org. Have both app-log as console log (searching for process: eduVPN and ANY: error) disconnect2_console.txt disconnect2.txt

efef commented 4 years ago

@joosthoogendoorn strangely I can't reproduce the bluetooth/airdrop isse, looks like the 2.1.7 client solved the issue. So think we can close this bluetooth specific issue.

joosth9n commented 4 years ago

Was about to try something else but experienced a disconnect directly after connecting to nl.eduvpn.org. Have both app-log as console log (searching for process: eduVPN and ANY: error) disconnect2_console.txt disconnect2.txt

In logging I see the same "Socket has a better path" again, followed by a reconnect. This seems to be undesired behaviour, as this should only happen when switching from cellular to WiFi for example. I will do some more debugging and probably open a separate issue for this.

@joosthoogendoorn strangely I can't reproduce the bluetooth/airdrop isse, looks like the 2.1.7 client solved the issue. So think we can close this bluetooth specific issue.

I'll close this issue for now, if it comes back we'll re-open this issue.