Airplay across VLANs requires firewall rule, but works from macbook without rules
I'm running Fedora 38 with pipewire 0.3.72. I have an airplay compatible speaker on a different VLAN to my laptop. I load the roap module with the following command PIPEWIRE_LOG_SYSTEMD=false PIPEWIRE_DEBUG=*:3,mod.raop*:5,pw.rstp-client*:5 pw-cli -m load-module libpipewire-module-raop-discover
and I'm able to select the speaker. However when I start playing audio, I get an error like this
[I][19345.948525] default | [ rtsp-client.c: 243 process_status()] status: RTSP/1.0 520 Origin Error
[I][19345.948851] default | [ rtsp-client.c: 317 process_header()] Content-Length: 0
[I][19345.948866] default | [ rtsp-client.c: 317 process_header()] Server: AirTunes/366.0
[I][19345.948876] default | [ rtsp-client.c: 317 process_header()] CSeq: 4
[I][19345.948895] default | [ rtsp-client.c: 276 dispatch_handler()] received reply to request with cseq:4
[I][19345.948919] mod.raop-sink | [module-raop-sink: 976 rtsp_setup_reply()] reply 520
[E][19345.948940] mod.raop-sink | [module-raop-sink: 979 rtsp_setup_reply()] missing Session header
I put my laptop on the same VLAN as the speaker and I'm able to use airplay. I did some packet sniffing on the non working configuration and found that the speaker sends UDP packets to Port 6002 on my laptop and this gets blocked by my firewall. The firewall allows traffic from the laptop to the speaker but not the other way round. So I guess as long as the laptop initiates the UDP traffic, it should work. But since the speaker initiates it, the traffic is blocked. Adding a rule to allow any UDP traffic from the speaker to the laptop allows airplay to work.
All of this is understandable, but the issue here is that airplay works from an Apple Silicon Macbook running Ventura in the same VLAN config without poking any holes in the firewall. The packet capture for this configuration looks very different. The first UDP packet seems to be initiated by the macbook, so the firewall allows traffic to flow through.
I am trying to find a way to anonymize the packet captures and will post them here. Or I can share them privately with a developer who's willing to look into the issue.