bind_address not used for airplay session

[CapitalT]

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:

• eth0: 192.168.1.113 (via dhcp)
• eth0:10 192.168.1.10 (for Owntone)
• eth1:11 192.168.1.11 (other webapp)
• etc.

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]

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]

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]

It's a bug.

The setting for websocket_interface has nothing to do with airplay.