Contributor I

Answered

Seeking fix for bug: Sonos S1 Controller on Mac hangs at startup when NordVPN is active

Forum|Forum|3 years ago
August 26, 2023
16 replies
458 views

Sonos S1 Controller hangs at startup on my Mac. Wondering if there is a solution that does not involve disabling NordVPN.

Here is stack trace, seems to be the same as this Sonos S2 issue that was reported for a different VPN product,

Analysis of sampling Sonos S1 Controller (pid 22295) every 1 millisecond
Process:         Sonos S1 Controller [22295]
Path:            /Applications/Sonos S1 Controller.app/Contents/MacOS/Sonos S1 Controller
Load Address:    0x10f1c5000
Identifier:      com.sonos.macController
Version:         57.14.37030
Code Type:       X86-64
Platform:        macOS
Parent Process:  ??? [1]

Date/Time:       2023-08-26 12:44:22.693 -0700
Launch Time:     2023-08-26 12:43:57.445 -0700
OS Version:      macOS 11.7.2 (20G1020)
Report Version:  7
Analysis Tool:   /usr/bin/sample

Physical footprint:         96.8M
Physical footprint (peak):  96.8M
----

Call graph:
    7920 Thread_922607   DispatchQueue_1: com.apple.main-thread  (serial)
    + 7920 start  (in libdyld.dylib) + 1  [0x7fff2032df3d]
    +   7920 NSApplicationMain  (in AppKit) + 816  [0x7fff22bd680c]
    +     7920 -[NSApplication run]  (in AppKit) + 586  [0x7fff22c02609]
    +       7920 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:]  (in AppKit) + 1364  [0x7fff22c102e5]
    +         7920 _DPSNextEvent  (in AppKit) + 864  [0x7fff22c11b12]
    +           7920 _BlockUntilNextEventMatchingListInModeWithFilter  (in HIToolbox) + 70  [0x7fff28651cf3]
    +             7920 ReceiveNextEventCommon  (in HIToolbox) + 587  [0x7fff28651f55]
    +               7920 RunCurrentEventLoopInMode  (in HIToolbox) + 292  [0x7fff286521f3]
    +                 7920 CFRunLoopRunSpecific  (in CoreFoundation) + 563  [0x7fff204089fc]
    +                   7920 __CFRunLoopRun  (in CoreFoundation) + 1988  [0x7fff20409883]
    +                     7920 __CFRunLoopDoTimers  (in CoreFoundation) + 307  [0x7fff20422c7a]
    +                       7920 __CFRunLoopDoTimer  (in CoreFoundation) + 927  [0x7fff2042311d]
    +                         7920 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__  (in CoreFoundation) + 20  [0x7fff20423629]
    +                           7920 __NSFireDelayedPerform  (in Foundation) + 415  [0x7fff211bb1e7]
    +                             7920 ???  (in Sonos S1 Controller)  load address 0x10f1c5000 + 0xad9367  [0x10fc9e367]
    +                               7920 ???  (in Sonos S1 Controller)  load address 0x10f1c5000 + 0x41f6ab  [0x10f5e46ab]
    +                                 7920 ???  (in Sonos S1 Controller)  load address 0x10f1c5000 + 0x1d7e83  [0x10f39ce83]
    +                                   7920 ???  (in Sonos S1 Controller)  load address 0x10f1c5000 + 0x8f7885  [0x10fabc885]
    +                                     7920 ???  (in Sonos S1 Controller)  load address 0x10f1c5000 + 0x901232  [0x10fac6232]
    +                                       7920 ???  (in Sonos S1 Controller)  load address 0x10f1c5000 + 0x900e73  [0x10fac5e73]
    +                                         7920 __sendto  (in libsystem_kernel.dylib) + 10  [0x7fff202e07d2]

It sends some traffic out to sentry.io (verified with Little Snitch) before it hangs.

No other applications on my Mac except Sonos have any problems accessing any points on my local network while NordVPN is active, so this appears to be a bug specifically with the Sonos application.

This topic has been closed for further comments. You can use the search bar to find a similar topic, or create a new one by clicking Create Topic at the top of the page.

Best answer by Corry P

Hi @gvup5lmo

Welcome to the Sonos Community!

Sonos requires that the controller (device running the Sonos app) be able to communicate on the same subnet as the speaker. For this reason, no VPNs are supported and they must be disabled (or, at least, disabled for the Sonos app) for Sonos to operate.

https://support.sonos.com/en-gb/article/sonos-system-requirements#:~:text=Sonos%20app%20and%20all%20Sonos%20products%20are%20on%20the%20same%20subnet

This is not a bug, but fundamental to how Sonos systems work. The other thread you linked to explains all this - if the VPN is not providing split-tunnelling, this is all expected behaviour.

I hope this helps.

Edit: Changed “be on the same subnet” to “be able to communicate on the same subnet” for accuracy.

Show previous replies

Corry P

Sonos Staff

Hi @Antonio_2

I am unable to view the reply you linked to on the NordVPN site due to website filtering in place on my work PC. Could you please copy and paste the content of the reply here in this thread? I’ll be happy to respond.

"Common sense is the collection of prejudices acquired by age eighteen." - Albert Einstein

A

Antonio_2

Contributor I

@Corry P You did reply to @gvup5lmo, saying that you’d flag the issue with engineering, but that was 6 months ago. Did you get a response from an engineer? The point being that, when a machine is connected to a VPN server, the desktop controller and the speaker remain on the same subnet, so the explanation you gave cannot be the right one. The situation would be slightly less frustrating if we were given an explanation that made sense.

Corry P

Sonos Staff

Hi @Antonio_2

Ah - I understand, though I am now confused about your link to the NordVPN website in your last post (Edit: I managed to look and it is a dead link - it will be removed)

The response from engineering was that we don’t support the use of VPNs, and due to this, they were not sufficiently impelled to investigate further.

Apologies - I don’t consider myself a networking expert by any means (and as VPNs are unsupported, there isn’t exactly a lot of documentation on them available to me), so it does seem I used incorrect language when describing the issue before: my use of the word “subnet” was incorrect as the IP address of the device doesn’t change when connected to a VPN, but that device’s resulting inability to communicate with other devices on the local network (without split-tunnelling) will be an issue when the Sonos app is trying to communicate with the system. What this re-routing is specifically called, I don’t know, but it will impede the app’s efforts to communicate with the speakers.

Regardless of the explanation/reason of/for the issue, VPNs are not supported by Sonos - if your VPN does not permit a connection between your Sonos app and Sonos speakers, that is to be expected. Should the VPN have a tunnelling feature that doesn’t seem to help the situation, I can only recommend you get in touch with the VPN’s support team for assistance - perhaps their split-tunnelling only works with unicast network packets, which would probably be an issue for our app. Our answer remains that the VPN should be removed for correct usage of the Sonos app.

I hope this helps.

"Common sense is the collection of prejudices acquired by age eighteen." - Albert Einstein

A

Antonio_2

Contributor I

@Corry P Thanks for taking the time to explain. Still lots of unanswered questions but, if the engineers aren’t forthcoming with details, I guess we’re stuck.

Airgetlam

Since a VPN is designed to stop ‘extra’ connections except from one source to another, and Sonos works by each device creating multiple connections, both to the controller and to the outside world, there’s some logic in the fact that Sonos doesn’t work with VPNs. They’re in direct opposition in functionality.

Bruce

controlav

Lead Maestro

As was said in the very first reply, for any VPN to work with Sonos it must support split-tunneling. This is a feature that sends external network calls through the VPN, but stays out of the way of local network traffic.

Author of the leading independent Sonos apps for Android, MacOS, iOS, Windows and Xbox.

Sign up

Login to the community