shairport-sync segfaults on any plain http request

[dubo-dubon-duponey]

While looking to build a quick "health-check" for shairport-sync (in a container), I stumbled upon this: http-requesting shairport-sync makes it SIGSEGV:

(gdb) r
Starting program: /boot/bin/shairport-sync --use-stderr --mdns=tinysvcmdns --configfile=/config/shairport-sync.conf --output=alsa --name=foofoo --port 5042
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0x767b6400 (LWP 520)]
[New Thread 0x75fb5400 (LWP 521)]
[New Thread 0x755ff400 (LWP 522)]
[New Thread 0x74dfe400 (LWP 523)]
[Thread 0x75fb5400 (LWP 521) exited]
[New Thread 0x743ff400 (LWP 524)]
[New Thread 0x73bfe400 (LWP 525)]

Thread 6 "shairport-sync" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x743ff400 (LWP 524)]
rtsp_read_request (conn=conn@entry=0x444b18, the_packet=the_packet@entry=0x743fd910)
    at rtsp.c:722
722	rtsp.c: No such file or directory.

It doesn't matter what endpoint / method you hit - just curl "whatever":

curl -iv $IP:5042/play

Of course, RTSP is not HTTP, but then, it probably should not segfault?

Hope this helps.

Thanks for your work on shairport-sync! Love the project.

[dubo-dubon-duponey]

-vvv doesn't really give much more info...

         2.426732766|Connection 1: new connection from 192.168.1.250:49285 to self at 192.168.1.7:5042.
[New Thread 0x743ff400 (LWP 1032)]
         0.001942032|Successfully created RTSP receiver thread 1.
[New Thread 0x73bfe400 (LWP 1033)]
         0.001526094|RTSP Message Received: "GET /play HTTP/1.1".

Thread 6 "shairport-sync" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x743ff400 (LWP 1032)]
rtsp_read_request (conn=conn@entry=0x444b78, the_packet=the_packet@entry=0x743fd910)
    at rtsp.c:722
722	rtsp.c: No such file or directory.

[mikebrady]

Yikes, thanks for this — I’ll check it straight away.

[mikebrady]

I can confirm that it happens, thanks. The code responsible for it is some of the most "ancient" in the program and looks very gnarly, but I'd better dive in...

[mikebrady]

Just pushed out a fix, and I'd be grateful if you gave it a try. It simply closes the link – do you think that's a reasonable response, or should I try to send something more sensible back?

[mikebrady]

[Update] For instance, it could respond like this, if it was any use:

$ curl -iv raspberrypi4b.local:5000/play
*   Trying fe80::9c04:d63e:82f3:d4de...
* TCP_NODELAY set
* Connected to raspberrypi4b.local (fe80::xxxx:xxxx:xxxx:xxxx) port 5000 (#0)
> GET /play HTTP/1.1
> Host: raspberrypi4b.local:5000
> User-Agent: curl/7.64.1
> Accept: */*
> 
RTSP/1.0 400 Bad Request
Type: "Server", content: "AirTunes/105.1"
Type: "Connection", content: "close"

* Closing connection 0

[mikebrady]

[Further Update] It turns out that a real Airport Express does the following:

$ curl -iv 192.168.50.23:5000/play
*   Trying 192.168.50.23...
* TCP_NODELAY set
* Connected to 192.168.50.23 (192.168.50.23) port 5000 (#0)
> GET /play HTTP/1.1
> Host: 192.168.50.23:5000
> User-Agent: curl/7.64.1
> Accept: */*
> 
RTSP/1.0 400 Bad Request
Server: AirTunes/105.1

and leaves the connection open, so that's what I'll go for, unless you have a better idea...

[mikebrady]

So, just pushed another update that does that – responds the same way as an AirPort Express. One slight difference remaining is that in Shairport Sync the connection will be closed after two minutes of inactivity.

[dubo-dubon-duponey]

Awesome!
Thanks a lot @mikebrady !

I ll try this asap tomorrow

Also 400 makes a lot of sense - although I would instinctively drop the connection immediately - but then, mimicking Airport behavior is probably a good idea...

[dubo-dubon-duponey]

Running 0e85ec3 now.
Bug fixed as far as I'm concerned.

👍

[mikebrady]

Thanks a lot for this contribution. Closing the issue. Please open a new one if necessary.