DAAP SSH tunneling time out

@sansp00 wrote:

It’s not a Firefly issue, but I thought that maybe someone might be able to give me some pointers.
I notice that my SSH tunnel for DAAP in between home and the office seems to stop working/timing out after around 3 songs ( ~10 minutes ) of listening. I restart the tunnel and things are back to normal.

I am using plink on my work XP box and connect to my NSLU2 running at home running behind a WGR614.

Thanks for the input !
Patrick S.

It may not be a ssh thing, it may be your firewall at work dropping the nat connection. Kind of dumb, but maybe you could try running some background traffic on that connection… maybe open the status page, and let it keep refreshing to keep traffic flowing?

Dumb idea, but worth a try. Maybe it buffers most of the song and then there is a long enough pause while it’s playing that the firewall decides the connection terminated?

— Ron

@sansp00 wrote:

I will try to host it on a different box and see if it help, but I rather run it locally so I stay ‘under the radar’ at the office.
Any suggestions ?
Thanks
Patrick S.

Mmm… yeah. It listens on 3689 for remote control applications. Like the remotes for iTunes via airtunes.

You can always forward 9999 to 3689 on the remote host:

ssh gatewayhost -L 9999:mt-daapd-server:3689

Then rendezvous proxy for 9999, rather than 3689.

— Ron

@mas wrote:

Hmmm Apple has actually made the life harder for people here because of pressure from the industry not to share this music further than the local network requiring these ssh-tunnel workarounds.

But firefly has no obligation to Apple and even supports the RSP alternative protocol anyway. So I am wondering if there isnt a way to simply make firefly announce the DAAP and RSP protocols in a way that doesnt limit it to the the local network but uses a mechanism that works without tunnels.

Dunno if I understand the underlying nw technique good enough but I happen to think that if Apple can turn this off then an Apple independant server may as well turn it on again or?

You don’t have to look for malice… that’s just how multicast works. It doesn’t even route well on a local network, much less doing crazy stuff like ssh tunnels. 🙂

And you could make some other announcement protocol, but then it wouldn’t work with iTunes, and that’s the primary purpose for the software.

There really isn’t a way around it, but it’s not because of evil on the part of apple. It’s just how it works.

You don’t have to look for malice… that’s just how multicast works. It doesn’t even route well on a local network, much less doing crazy stuff like ssh tunnels. Smile

Well iTunes 4.0 it did work, then 4.01 Apple disabled it deliberately as the musci industry was getting pissed. So far I understood it.

But yeah the problem may really be the client. You cant tell the iTunes client to connect to an IP, thats the problem it seems.

But actually devices like the roku’s or any other DAAP/RSP player could simply accept an IP option then it should work remote without ssh.

So ssh-tunnel is the only way to trick it so far?

Oh, wasnt meaning NAT Problems at all. If I want to access my mediaserver from remote then I simply open a firewall forward on the router for that port. I anyway need to do that for a ssh tunnel as I need port 22 forwarded for that to work.
So I can instead forward the ports that DAAP or RSP uses simply.
And the public IP one has is either pseudostatic or one can use dynip service to be able to reliably know it from remote.

No, IMHO what apple did was a) remove an option to tell the client side the IP/DNS name of a mediaserver to address it and implement that iTunes as a server will refuse a remote connection. To be fair to Apple that jackshit was likely forced on em by the Music industry. One can assume it was a condition for allowing em to sell their music via iTunes shop.

But well I wonder why theres still no way around it except tunnelling. Seeing that there are open source servers and clients for DAAP. If those 2 sides simply dont follow Apples way (and they have no obligation to) and do

a) Server doesnt refuse remote connections. Does firefly allow remote connections, provided the remote side has discovered the mediaserver?

b) The clients, such as GIT, need a program option to enter the address of a possible media server and try connecting to it as if rendevous had discovered it.

Shouldnt such be actually easy given a) + b) are arranged? And sharing the music not to everyone can be easily achieved. Simply setting a good password on the daap server should do or? Well once one dips into such remote access stuff one may be tempted to do implement some safeguards against hacking also then but except for that it should not be hard to do I tend to think.