Can't find any UPnP devices (Sonos)

[GrahamSH-LLK]

Hi! I've been trying to set this up on my network for a few days now. However, it cannot find any devices. I've tried on my macOS machine and a pi box and neither can find anything. The only logs I get (with full debug) are

./airupnp-macos-arm64-static -d all=sdebug
[20:40:05.584572] main:1355 Starting airupnp version: v1.0.13 (Dec 10 2022 @ 11:10:32)
[20:40:05.585462] main:1362 no config file, using defaults
[20:40:05.586350] Start:1087 Binding to 192.168.1.17:0
[20:40:25.004972] MasterHandler:557 event: 7 [UPNP_DISCOVERY_SEARCH_TIMEOUT] [0x0] (recurse 0)

I read in the comments of a troubleshooting issue that I can try soco-cli to see if SSDP is working, and it can find my devices using SSDP. I'm at a loss, so any help would be appreciated!

[philippe44]

What UPnP devices do you have?

[GrahamSH-LLK]

I have 8 sonos devices on my wifi, all running under S1. I just tried and gssdp-discover can locate them, but AirConnect cannot for some reason.

[GrahamSH-LLK]

If this helps here is the list from the Sonos app:

Associated Product: 192.168.1.23
---------------------------------
Play:5: Basement Back (R)
Serial Number: B8-E9-37-2B-FA-06:E
Sonos OS: S1
Version: 11.6.1 (build 571334140)
Hardware Version: 1.16.4.1-1.0
Series ID: P100
IP Address: 192.168.1.10
WM: 1
OTP: 1.1.1(1-16-4-zp5s-0.5)
---------------------------------
Play:5: Basement Back (L)
Serial Number: 00-0E-58-84-70-40:5
Sonos OS: S1
Version: 11.6.1 (build 571334140)
Hardware Version: 1.16.4.1-1.0
Series ID: P100
IP Address: 192.168.1.3
WM: 1
OTP: 1.1.1(1-16-4-zp5s-0.5)
---------------------------------
Sub: Basement TV
Serial Number: 00-0E-58-9C-92-D4:7
Sonos OS: S1
Version: 11.6.1 (build 571334140)
Hardware Version: 1.8.2.4-1.0
Series ID: A100
IP Address: 192.168.1.14
WM: 2
OTP: 
---------------------------------
Playbar: Basement TV
Serial Number: 00-0E-58-BB-1F-CD:1
Sonos OS: S1
Version: 11.6.1 (build 571334140)
Hardware Version: 1.9.1.10-1.0
Series ID: A100
IP Address: 192.168.1.23
Audio In: 
WM: 1
OTP: 
---------------------------------
Connect:Amp: Dining Room
Serial Number: 00-0E-58-34-AA-02:6
Sonos OS: S1
Version: 11.6.1 (build 571334140)
Hardware Version: 1.16.3.1-1.0
Series ID: P100
IP Address: 192.168.1.18
WM: 1
OTP: 1.1.1(1-16-3-0.9)
---------------------------------
Connect: Dining Room 2
Serial Number: B8-E9-37-9E-4C-26:4
Sonos OS: S1
Version: 11.6.1 (build 571334140)
Hardware Version: 1.17.5.5-1.1
Series ID: C100
IP Address: 192.168.1.2
WM: 1
OTP: 1.1.1(1-17-5-zp90-2.1)
---------------------------------
Connect:Amp: Graham’s Bathroom
Serial Number: B8-E9-37-A3-80-6C:C
Sonos OS: S1
Version: 11.6.1 (build 571334140)
Hardware Version: 1.16.3.1-1.0
Series ID: P100
IP Address: 192.168.1.9
WM: 1
OTP: 1.1.1(1-16-3-0.9)
---------------------------------
Play:1: Graham’s Room
Serial Number: B8-E9-37-58-B3-E8:A
Sonos OS: S1
Version: 11.6.1 (build 571334140)
Hardware Version: 1.8.3.7-1.0
Series ID: A101
IP Address: 192.168.1.16
WM: 1
OTP: 
---------------------------------
Connect:Amp: Living Room
Serial Number: 00-0E-58-DA-50-1E:8
Sonos OS: S1
Version: 11.6.1 (build 571334140)
Hardware Version: 1.16.3.1-1.0
Series ID: P100
IP Address: 192.168.1.15
WM: 1
OTP: 1.1.1(1-16-3-0.9)
---------------------------------
Connect: Outside 105
Serial Number: 00-0E-58-26-D2-28:2
Sonos OS: S1
Version: 11.6.1 (build 571334140)
Hardware Version: 1.1.16.4-1.0
Series ID: S100
IP Address: 192.168.1.7
WM: 1
r8: 16.0-7

[philippe44]

I've changed something recently about the way UPnP binds to a given interface but I've not published it yet. I'll do that in a couple of hours

[GrahamSH-LLK]

Oh, awesome. Do you think this will resolve the issue I'm seeing?

[philippe44]

Sorry it took me more than a few hours 😄. You should have a different log now that gives the name of the interface that is used and that might be the issue on macOS. You can now specify a different name using -b

[GrahamSH-LLK]

Sorry it took me more than a few hours 😄. You should have a different log now that gives the name of the interface that is used and that might be the issue on macOS. You can now specify a different name using -b

It's fine! Where is this new build by the way?

[philippe44]

It's pushed, but not made a release. You can just GET the latest binaries

[GrahamSH-LLK]

It still seems to not to be working on the latest version. It is binding to the correct interface (given it has the right IP)

[philippe44]

Can you show me that log

[GrahamSH-LLK]

Sure!

./airupnp-macos-arm64-static -d all=sdebug
[15:05:37.392067] main:884 Starting aircast version: v1.0.14 (Jan 25 2023 @ 10:42:36)
[15:05:37.392525] main:891 no config file, using defaults
[15:05:37.392564] Start:662 Binding to 192.168.1.50

on this version I seem not to be getting the timeout errors, but before I was getting something like this:

./airupnp-macos-arm64-static -b en0 -d all=sdebug
[13:55:13.585375] main:1355 Starting airupnp version: v1.0.13 (Dec 10 2022 @ 11:10:32)
[13:55:13.585804] main:1362 no config file, using defaults
[13:55:13.586148] Start:1087 Binding to 192.168.1.50:49152
[13:55:33.004968] MasterHandler:557 event: 7 [UPNP_DISCOVERY_SEARCH_TIMEOUT] [0x0] (recurse 0)
[13:55:33.005300] UpdateThread:692 Presence checking
[13:55:53.003858] MasterHandler:557 event: 7 [UPNP_DISCOVERY_SEARCH_TIMEOUT] [0x0] (recurse 0)
[13:55:53.003904] UpdateThread:692 Presence checking
[13:56:13.007766] MasterHandler:557 event: 7 [UPNP_DISCOVERY_SEARCH_TIMEOUT] [0x0] (recurse 0)
[13:56:13.009355] UpdateThread:692 Presence checking
[13:56:33.005531] MasterHandler:557 event: 7 [UPNP_DISCOVERY_SEARCH_TIMEOUT] [0x0] (recurse 0)
[13:56:33.006603] UpdateThread:692 Presence checking
[13:56:53.004935] MasterHandler:557 event: 7 [UPNP_DISCOVERY_SEARCH_TIMEOUT] [0x0] (recurse 0)
[13:56:53.005755] UpdateThread:692 Presence checking
^C[13:57:03.661810] Stop:1143 terminate update thread ...
[13:57:03.662033] Stop:1148 flush renderers ...
[13:57:03.662131] Stop:1151 terminate libupnp
[13:57:04.168858] Stop:1170 terminate main thread ...

[philippe44]

That's the wrong version, still 1.0.13

[GrahamSH-LLK]

That's the wrong version, sill 1.0.13

I know, the first one is new and the second one is before the update.

[philippe44]

So then there is something wrong with my build because this is not the log you should have with 1.0.14

[philippe44]

I've re-build everything, you should see a "Binding to iface <...>". The log of the macOS 1.0.14 version is all rubbish, even the line number is non-sense...

[philippe44]

Oh crap! When you run the .14 version, it runs aircast, the ChromeCast bridge. HUH?

Please check on your side, but I've done a binary search in that file and there is no "aircast" in there, so I have no idea why this is messed-up like that.

[GrahamSH-LLK]

Oh my god, I'm really dumb. I accidentally curl'ed the aircast version. The actual logs are

./airupnp-macos-arm64-static -d all=sdebug
[16:19:57.884950] main:1360 Starting airupnp version: v1.0.14 (Jan 25 2023 @ 12:47:31)
[16:19:57.885647] main:1367 no config file, using defaults
[16:19:57.886156] Start:1083 Binding to iface en0@192.168.1.50:0
[16:20:17.005032] MasterHandler:557 event: 7 [UPNP_DISCOVERY_SEARCH_TIMEOUT] [0x0] (recurse 0)
[16:20:17.005406] UpdateThread:692 Presence checking

[philippe44]

Makes more sense now 😄. So, en0 is the right interface and it's now sure that the UPnP interface is using it. Can you try again on a Pi because there is actually an issue with the mac build but I've not been able to figure it out yet and I was hoping that it was the UPnP binding interface but obviously it's not. But I never saw an issue on Pi.

One last thing on macOS, you can try setting a high port as well, like 50000 to double check in the -b parameters

[GrahamSH-LLK]

The pi seems to be working now! I've been playing around with router settings so I'm not sure if that's what fixed it, but they're showing up now!