XBMC

[kodel]

I tried XBMC builds from 2.0 to the latest, all of them give the “cannot connect to serer” message after about 20 seconds.

I’ll investigate later today how I can turn on debugging/tracing in the various components (XBMC, Firefly, Bonjour) and post some logs here

[kodel]

When testing with debugging turned on, the Firefly log does not show a connection attempt (doublechecked debugging configuration by making a working connection with iTunes to see what comes in the log).

Debug log of XMBC:

07:24:20 M: 38813696 DEBUG: CApplication::OnKey: 11 pressed, action is 7
07:24:20 M: 39047168 DEBUG: CGUIMediaWindow::GetDirectory (daap://10.0.0.1:9999/)
07:24:20 M: 39047168 DEBUG: ParentPath = []
07:24:40 M: 38989824 ERROR: CDaapClient::GetHost(10.0.0.1) – Unable to connect
07:24:40 M: 38989824 ERROR: CGUIMediaWindow::GetDirectory(daap://10.0.0.1:9999/) failed
07:24:40 M: 38989824 DEBUG: CGUIMediaWindow::GetDirectory ()
07:24:40 M: 38989824 DEBUG: ParentPath = []
07:24:40 M: 38989824 DEBUG: CURL::CURL – Url has no protocol Music, empty CURL created

So it looks like I’ll have to setup an Etherreal to see whats going on at the network level. I’ll install a test configuration on a spare machine this evening, since current tests are run on my production system (Vista , itunes, large song DB -> all potential troubles…)

I’ll let you know how it goes, but for now Firefly doesn’t seem to be involved.

[kodel]

Whilst doing some test to pinpount my XBMC – Firefly connection problem, I might have found a bug in how the Firefly installer handles Vista Firefly rules:

TEST 1: VISTA with Firefly installed, windows firewall turned on
TEST 2: XP pro with firefly installed, windows firewall turned on
TEST 3: VISTA with Firefly installed, windows firewall turned off
TEST 4: XP pro with firefly installed, windows firewall turned off

When starting up firefly with -d9, test 2,3 and 4 yield result B
When starting up firefly with -d9, test 1 yields result A (so, the name doesn’t get registered in Bonjour)

IMHO this means Firefly isn’t properly registering itself in the Vista Firewall. Although when I look at the Exceptions list in the Windows Firewall Settings, both Bonjour and Firefly Media Server are registered with scope “any computer”, so that should be fine.

result A:
2007-02-13 17:32:45 (a02e3f68): Scanned 3 songs (was 3) in 0 seconds

result B:
2007-02-13 17:32:45 (a02e3f68): Scanned 3 songs (was 3) in 0 seconds
2007-02-13 17:32:46 (4021d85b): Got a reply for Firefly Media Server (2)._http._tcp.local.
2007-02-13 17:32:46 (4021d85b): Name now registered and active
2007-02-13 17:32:46 (4021d85b): Got a reply for Firefly Media Server (2)._daap._tcp.local.
2007-02-13 17:32:46 (4021d85b): Name now registered and active
2007-02-13 17:32:46 (4021d85b): Got a reply for Firefly Media Server (2)._rsp._tcp.local.
2007-02-13 17:32:46 (4021d85b): Name now registered and active

[kodel]

Ignore the previous post: I haven’t been able to reproduce this behaviour. Now also test1 yields result B, so that’s OK.

But, on with my quest:

* when windows firewall is ENABLED, it takes 20 sec. before XBMC tells me “can not connect to server

* when windwos firewall is DISABLED, XBMC immediately tells me “can not connect to server”

The entries in the XBMC log look the same, besides the timing difference.

On to Ethereal…

[kodel]

I just spent some time looking at ethereal captures. I can see the MDNS messages from Bonjour on startup, and regular MDNS announcements from the FireFly server.

However, I don’t see any MDNS message from the XBOX to the server. When attempting to connect, I see the XBMC doing an ARP request for the server’s IP, then it sends out a TCP SYN message with MSS=1604. The server replies with a TCP ACK message with the RST flag set, however it sets the window size to zero.

Then nothing happens…

Is it the windows size response in TCP? Isn’t the xbmc supposed to set up a tcp connection to the server? Is it something else? I’ll have to read up on how DAAP is working, since I’m just staring blind.

The only other messages I see is a broadcast ping from the xbox and an MDNS “standard query resposne SRV 0 0 9999 …” from the server.

PS: I have sporadically seen the behaviour again reported a few messages back (firefly not registering with bonjour), but not been able to find the cause of it.

[kodel]

I compared with working ethereal traces between Firefly and iTunes. There, I indeed see that the iTunes PC initiates the “connection” by starting the MDNS name / adress negotiation. From that moment on, itunes indicates it is connected.
When one clicks on the server (to retrieve the playlist) a TCP connection is opened (just like the xbmc tries). The only difference in the SYN message is that the windows scale requested in the TCP option field is 8, whereas the xbmc doesn’t request this option. However, that should not be a problem as far as my TCP knowledge (or rather feeling 🙂 ) goes.

So, temporary conclusion for today:

The XBMC doesn’t implement the Bonjour discovery, but directly tries to retrieve the playlist using the IP+port number of Firefly. Firefly doesn’t like this and refuses the TCP connection by returning an ACK with windows size 0.

Is this new behaviour of Firefly? Should it be changed or should XBMC implement the complete Bonjour protocol ?

Just some testing from a newbie (installed XBMC last weekend…)

[rpedde]

@kodel wrote:

The XBMC doesn’t implement the Bonjour discovery, but directly tries to retrieve the playlist using the IP+port number of Firefly.

This is true. That’s why you have to specify an IP address in your xbmc settings, and not just let it autodetect.

Firefly doesn’t like this and refuses the TCP connection by returning an ACK with windows size 0.

Firefly doesn’t care. It will happy accept any connection, regardless of how the client knows it’s there.

Is this new behaviour of Firefly? Should it be changed or should XBMC implement the complete Bonjour protocol ?

Nope. It’s fine without it. It would of course be easier to locate daap servers with full bonjour on xbmc, but it’s not strictly necessary.

As far as the packet traces you got:

A TCP SYN that gets a RST is something that’s happening at the stack level. If it were firefly closing the connection, you’d get: SYN, SYN+ACK, ACK, then firefly would register the connection and start the FIN teardown.

Instead, the stack itself is closing the connection with a reset. That means that either:

1. Nothing is listening on the port you tried to connect to

or

2. The firewall is resetting those connections.

Those are the only two options.

— Ron

[kodel]

Thanks Ron,

I forgot to doublecheck the port numbers in the capture log. Indeed, XMBC tries to connect on port 3689 whilst Firefly is listening on 9999.

Switching the Firefly portn number to 3689 and voila: works like a charm!

I tried all kinds of formatting options to enter the port number in the xbmc configuration file, but I can’t make it connect to another port then 3689. Probably someone who tried to implement a fix for i-Tunes 7 or so took some shortcuts and hardcoded a port number somewhere in the daap code.

[rpedde]

@kodel wrote:

Thanks Ron,

I forgot to doublecheck the port numbers in the capture log. Indeed, XMBC tries to connect on port 3689 whilst Firefly is listening on 9999.

Switching the Firefly portn number to 3689 and voila: works like a charm!

I tried all kinds of formatting options to enter the port number in the xbmc configuration file, but I can’t make it connect to another port then 3689. Probably someone who tried to implement a fix for i-Tunes 7 or so took some shortcuts and hardcoded a port number somewhere in the daap code.

Aaaah! Interesting. That’s a good point to note for the future.

Thanks.

— Ron

[tgor]

Port 3689 did it for me too. Thanks.

[Author]

Posts