search

owntone / owntone-server

Linux/FreeBSD DAAP (iTunes) and MPD audio server with support for AirPlay 1 and 2 speakers (multiroom), Apple Remote (and compatibles), Chromecast, Spotify and internet radio.
https://owntone.github.io/owntone-server
GNU General Public License v2.0
2.11k stars 237 forks source link

bind_address not used for airplay session #1546

Open CapitalT opened 2 years ago

CapitalT commented 2 years ago

Hi,

I am running Owntone version 28.5 on a RaspberryPi/RaspbianOS. Because I have a couple of applications running there and I don't like to use port numbers I have added a couple of IP addresses in /etc/network/interfaces.d/ so the PI has:

When I add to /etc/owntone.conf:

        bind_address = "192.168.1.10"
        port = 80

the Web interface works as expected but music is not played on my Airplay 1 device. I got the same error as described in issue #1344 but for Airplay 1: player: The AirPlay 1 device 'box' failed to activate.

I saw in the debug logs that the Airplay 1 device is trying to establish a session on the eth0 IP address.

[2022-10-17 11:36:04] [DEBUG]     raop: device_start: Sending OPTIONS to 'box'
[2022-10-17 11:36:04] [DEBUG]     raop: startup_options: Sending auth-setup to 'box'
[2022-10-17 11:36:05] [DEBUG]     raop: startup_auth_setup: Sending ANNOUNCE to 'box'
[2022-10-17 11:36:05] [DEBUG]     raop: Local address: 192.168.1.113 (LL: no) port 54816
[2022-10-17 11:36:05] [ INFO]     raop: Setting up AirPlay session 2475765115 (192.168.1.113 -> 192.168.1.135)

I fixed this by setting bind_address to the eth0 IP but I would expect that the IP communicated to the Airplay device would be the bind_address if services are running there.

I also tried setting websocket_interface = "eth0:10" but then owntone would complain that it could not write to a 'dummy pipe' and would not start.

ejurgensen commented 2 years ago

Yes, looks like while the bind address is used for the Airplay services that OwnTone serves, it is not used as source address when OwnTone makes connections, and it is not (necessarily) the address that the speaker is provided (in the SDP packet).

CapitalT commented 2 years ago

Yes, looks like while the bind address is used for the Airplay services that OwnTone serves, it is not used as source address when OwnTone makes connections, and it is not (necessarily) the address that the speaker is provided (in the SDP packet).

So is this expected behaviour or a bug? Or is there a role for websocket_interface here?

ejurgensen commented 2 years ago

It's a bug.

The setting for websocket_interface has nothing to do with airplay.