DAAP SSH tunneling time out

[sansp00]

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.

[rpedde]

@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]

Well, after some testing, I came to the conclusion its not a time out issue. It seems pretty easy to reproduce. Just select a song, let it play a few seconds and select another one for immediate play. I think iTunes get confused a bit. When I start iTunes, it starts listening on 0.0.0.0:3689 and my rendezvous proxy runs on 127.0.0.1:3689. I thought that my iTunes had sharing on but no. It had the sharing of my library deactivated and only the option to look for other shared libary on.
Why does iTunes would want to listen on that port since it does not share anything ? Is there a way to turn this off ?
When I start my proxy, it listens on 127.0.0.1:3689 and works well when all operation are ‘bundled’. But as soon as I want to skip a track or listen to something else, it fails and I see the listen socket in funky states ( FIN_WAIT … )
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.

[rpedde]

@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]

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?

[rpedde]

@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.

[sansp00]

BTW, had some time to try out another port, got the same results … It seems that switching songs while one is playing messes things up. I am still trying to figure out the source, talked to our network team or rather guy here and he said time out was based on lack of activity for 24h, so this is out of the way.

I am now wondering if it ain’t my router at home who is giving me a hard time or is unstable ?
Anyway, still digging and looking for ideas on things to try out …
Patrick S.

[mas]

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?

[rpedde]

@mas wrote:

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?

Not exactly sure what you mean, exactly. It’s not really a “trick”, it’s just a way to get a connection from behind another nat. There isn’t any reason you couldn’t just run the server on a public ip address, then you wouldn’t need ssh-tunnel at all. The tunnel is just a way to traverse firewalls without poking holes or letting random people be able to see your daap server.

Now, true, you still have to have some way of discovering it, but again, that’s not an apple thing. You wouldn’t want service discovery stuff working across the whole internet, or you’d see everyone’s iTunes in the whole world. (although you could probably find any kind of music you were looking for).

So that’s the rendezvous proxy.

As far as direct connections to IP… that may actually have gone away. But I’m sure you could use a rendezvous proxy to stuff a remote address in there — I don’t think iTunes can’t *connect* to a remote subnet, I just think it won’t *accept* connections from a remote subnet.

Well, so I guess there is a trick in there after all. 🙂

And yeah, it is kinda chickenshit of apple to cripple the program intentionally in that way, but what do you do?

[mas]

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.

[Author]

Posts