mt-daapd over HTTPS

[Adar]

I’m quite sure that -p is needed. The “remote” end as far as ssh is concerned, is the machine on which it is invoked. That is, my work machine, where I am running ssh, is the remote end, and as such, “ssh -p 12345 localhost”.

In other news, I finally managed to get this to work! It occurred to me that corkscrew and/or proxytunnel (proxytunnel.sourceforge.net) can be made to work if we use a super-server like inetd to spawn them. This also circumvents the “lack of multiplexing connections” problem that I ran into. So I downloaded and compiled proxytunnel, which tunnels a connection into an interactive session through an HTTPS tunnel.

Then I added an entry in inetd for daap: “daap stream tcp nowait root /usr/bin/tcpd /usr/local/bin/proxytunnel -g myproxy -G proxyport -d myip -D 3689.

With proper publishing through mdnsresponder, I could now open multiple streams and listen to music!

Next question: Given my limited bandwidth and my frequent use of heavy-bitrate mp3’s, can I downsample mp3’s on the fly through mt-daapd to conserve bandwidth?

[Adar]

I’d also like to point out that the reason my HTTP tunnel and ssh over it failed is because when you forward a port in ssh, it isn’t made available to other machines. So even though port 3689 was properly forwarded to my daapd server, my iTunes client was on a different machine than the one with the forwarded port, and so it couldn’t connect to that forwarded port. The solution is in using “-L *:3689:localhost:3689” when using -L to forward a port. This binds it to all interfaces, not just localhost, so other machines can connect to it.

[Adar]

Another update. My work proxy likes to terminate connections that become persistant. From my tests, it seems like this happens every 15 minutes. This ought to be a problem only for songs over 15 minutes long, but the DB connection is opened persistantly, and when it is lost, the entire connection to the share and any music playing is gone too.

Interestingly, I tried keeping an ssh connection open to my server, in the same way, and it lasted about 50 minutes before being disconnected. Perhaps it has more to do with the amount of data transferred.

As such, I’ll have to discard using the proxy to forward, and try the other approach: run mt-daapd locally with a cached DB, and hack it to open remote connections for the mp3’s. Or just buy an external hdd and copy them. 🙂

[rpedde]

That’s too bad. I liked the idea of the http tunnel. 🙁

I guess you are probably right… next easiest is usb hdd + rsync/unity.

Too bad, though.

[Adar]

Well, the lesson here was that it could be done. Local mdns beacon coupled with something like inetd+corkscrew or inetd+proxytunnel to go through the proxy. Your proxy just has to be more sympathetic than mine.

[fd0]

When at work I run proxytunnel on my OSX laptop with an application called Network Beacon.
This app creates a local daapd presence on my laptop where local and remote clients can connect to. This runs perfectly fine, also because bandwith is usually no issue, 1Mbit up from home with a collection of 27000 mp3’s

It takes less than one minute to load the the catalog into my iTunes client when at work

warning: with proxytunnel and a proxy that requires authentication, use the env vars to store userid/password (especially on a shared machine)

[Author]

Posts