@rpedde wrote:
@Casao wrote:
2008-01-17 21:33:44 (9b65e856): Thread 98: could not read: An existing connection was forcibly closed by the remote host.[/code]
The metacode stuff is normal. The error above is because iTunes closed the connection ungracefully. Usually that’s because it doesn’t like what it sees and quits the connection or something like that.
– Tried it under iTunes 7.5 in Parallels on my Macbook Pro, it didn’t generate the log entry, but showed the same “[null]” connection in the web panel.
– Tried it on a completely unrealted Windows PC running Windows XP SP2 and iTunes 7.6,, it generated an identical log and showed a “[null]” on the web control panel.
That’s likely a bug in that the server isn’t closing the connection right when the client terminates ungracefully. Still… same root cause though.
– I just tried it by running iTunes on the server and it actually connected fine – however, instead of showing a lan ip on the Server Status page, it shows my internet IP. The music plays fine.
??
Are you saying that your server has multiple interfaces? Like two nics, one connected to your internal network and another connected to the internet?
Or is one the hamachi interface? Or what?
Sounds like you have some unique network configuration here, and that’s probably what’s going on. The fact that you are connecting to a public ip is probably also a clue.
I attempted to open port 9999 & 5353 on my router because I saw that it worked when connecting via the external port. However, it’s still a no go and I can’t get it to work.
5353 is udp, and it’s the discovery protocol. If it shows up in iTunes at all, that part is working. 9999 is the part that serves the music. You can connect to port 9999 with a web browser (http://ip.address:9999) and see if you get a password prompt. That can help debug firewall issues, or problems with binding particular interfaces.
Is there any reason why the iTunes on the server can get to the shares while the others can’t? I figured since it was an external IP there was something wrong with my local network – however, samba shares and everything will work just fine.
I expect that’s the root of the problem. Mdns uses different discovery techniques than does windows browsing, so likely the different discovery stuff is doing something enough differently that the apple discovery stuff is discovering the external interface, while the broadcast based discovery is discoving the internal interface. Or that’s my guess, anyway.
Are there any ports beside 9999 and 5353 that need to be forwarded from my router to the server? Is there any reason why iTunes from the same machine can connect to the server, but comes up as my external IP instead of one of the local hosts?
see above. Yeah, my guess is that if you are multihomed, the server itself can connect to the outside ip. Again, I’d have to have more info on how you network is set up. From inside the network, you shouldn’t be able to access the machine by public ip. Most routers don’t support one-armed natting like that.
On the server status page, should I be seeing a connection from 127.0.0.1 with status “Serving xml-rpc method”?
yes. 127.0.0.1 is the local machine, and when you are viewing the status page, it’s logging into the server to fetch the status… and the connection it’s seeing is the connection it’s making to check connections. 🙂
And is there any other information or other files you need to help diagnose this problem? If you tell me what you want, I can provide just about any information about my setup.
Net info… how many interfaces, what routing devices, access points, etc. A general idea of how your public/private are set up, at least in terms of how you are natting and that kind of thing.
But yeah, the public ip thing is the thing that’s breaking it, I’m sure.
— Ron
My network configuration is fairly standard – I’m running a Linksys WRT54G w/ Tomato Firmware. Connected to this are 4 computers:
– The Win2k3R2 server, which is running Firefly Media Server. This is connected directly via an Ethernet cable to the router. It’s got a permanent ip of 192.168.1.100
– My Macbook Pro running Leopard – this connects via Wireless, but it’s generally only a few feet from the router so Ethernet is an option, which I’ve tested. It’s got a static IP of 192.168.1.101
– An old Dell box running Windows XP SP2. Connected via an ethernet cable. It doesn’t have a permanently assigned address, but it tends to receive 192.168.1.121
– A beige-box PC running Windows XP SP2. This is connected via WiFi, but I’ve not used this to test anything.
I’ve got a few other things connected, mostly game consoles. This doesn’t really come into account though.
For my earlier tests, I tried it on the Macbook Pro, which shows “Connecting to Firefly Media Server” indefinitely. I tried it on the old Dell box, which came up with the same error. I tried it on the Win2k3 box running the server, and it seemed to work and in the web interface it gave me an IP I mistakenly identified as an external IP – I just went back and checked again, and Hamachi’s network connection was running but the program itself was closed. The IP was my Hamachi IP, so apparently it looped back on itself via Hamachi. After closing the Hamachi IP, it’s still able to connect to the local Firefly server, but it instead gives an ip of 192.168.1.100 – its local IP.
Connecting to http://192.168.1.100:9999 on my Macbook Pro comes up with the no_access.html page – it appears to be connecting and serving fine. After adding an admin password, I can access the web configuration panel fine.
Sorry for the earlier confusion about IP addresses, to reiterate, it was Hamachi’s IP, and once I disabled Hamachi I am still able to connect to it and it gives my private IP.
Everything listed in the network connection uses only a single interface, with any spare interfaces disabled in the OS.
Actually, as an experiment, I went ahead and loaded up Hamachi on this machine and logged into the network, and it was completely capable of connecting to the share and playing files through Hamachi – looking at the web config panel now shows the connection through the Hamachi IP. I’m not sure why this would be the case, but it appears to work. I’d still be more than glad to help diagnose the root problem if you’re interested, but for my purposes, I can tunnel everything through Hamachi without problems.