Thanks rsl… Your questions are good and cover off all the obvious things to check…
@rsl360 wrote:
Have you tried the basic stuff? Like can you ping your M1001?
Yes I can ping it and can telnet into ports 4444 and 5555.
@rsl360 wrote:
And I assume you have it hard wired.
Yes.
@rsl360 wrote:
Do you have other 10/100 devices on the network and can you talk to them?
Yes – the network is working fine. All devices are contactable and working fine.
@rsl360 wrote:
Do you have other gigabit devices on the network?
Yes – many – its sad. And they’re all communicating perfectly at the normal 300-400 Mbit/s they normally sustain into the fedora 10 server that’s hosting firefly.
@rsl360 wrote:
Should the M1001 be able to see the internet, and does it?
It can definitely see more than the internet. Just for grins – and to perhaps be informative for anybody else that has trouble getting their M1001 working in the future, a wireshark trace taken on the server, filtering everything other than traffic to/from the M1001, shows the following: (Scenario is that M1001 is turned off, I start the wireshark trace, then turn on the M1001)…
No. Time Source Destination Protocol Info
1 0.000000 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x55443322
2 0.000002 RokuLlc_04:45:2a Broadcast ARP Who has 169.254.50.91? Tell 0.0.0.0
3 0.001310 0.0.0.0 255.255.255.255 DHCP DHCP Request - Transaction ID 0x55443322
4 0.130036 RokuLlc_04:45:2a Broadcast ARP Who has 172.16.1.1? Tell 172.16.1.16
5 0.130066 AsustekC_5a:b1:8f RokuLlc_04:45:2a ARP 172.16.1.1 is at 00:18:f3:5a:b1:8f
6 0.130257 172.16.1.16 172.16.1.1 NTP NTP client
7 0.130475 172.16.1.1 172.16.1.16 NTP NTP server
8 0.131075 172.16.1.16 172.16.1.1 NTP NTP client
9 0.131184 172.16.1.1 172.16.1.16 NTP NTP server
10 0.131794 172.16.1.16 172.16.1.1 NTP NTP client
11 0.131887 172.16.1.1 172.16.1.16 NTP NTP server
12 0.155875 172.16.1.16 172.16.1.1 DNS Standard query A www.radioroku.com
13 0.156391 172.16.1.1 172.16.1.16 DNS Standard query response CNAME radioroku.com A 209.200.236.41
14 0.182405 172.16.1.16 172.16.1.1 DNS Standard query A soundbridgeupgrade.rokulabs.com
15 0.182891 172.16.1.1 172.16.1.16 DNS Standard query response A 209.200.248.160
16 0.352190 172.16.1.16 209.200.236.41 TCP 8978 > http [SYN] Seq=0 Win=8192 Len=0
17 0.352320 209.200.236.41 172.16.1.16 TCP http > 8978 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
18 0.352622 172.16.1.16 209.200.236.41 TCP 8978 > http [ACK] Seq=1 Ack=1 Win=8192 Len=0
19 0.353200 172.16.1.16 209.200.236.41 TCP [TCP segment of a reassembled PDU]
20 0.353268 209.200.236.41 172.16.1.16 TCP http > 8978 [ACK] Seq=1 Ack=229 Win=6432 Len=0
21 0.353729 172.16.1.16 209.200.236.41 HTTP POST /services/url_performance.php
22 0.353817 209.200.236.41 172.16.1.16 TCP http > 8978 [ACK] Seq=1 Ack=712 Win=7504 Len=0
23 0.379974 172.16.1.16 209.200.248.160 TCP 8979 > http [SYN] Seq=0 Win=8192 Len=0
24 0.380108 209.200.248.160 172.16.1.16 TCP http > 8979 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1460
25 0.380413 172.16.1.16 209.200.248.160 TCP 8979 > http [ACK] Seq=1 Ack=1 Win=8192 Len=0
26 0.381845 172.16.1.16 209.200.248.160 HTTP GET /cgi-bin/debug4
27 0.381959 209.200.248.160 172.16.1.16 TCP http > 8979 [ACK] Seq=1 Ack=1461 Win=8760 Len=0
28 0.381848 172.16.1.16 209.200.248.160 HTTP Continuation or non-HTTP traffic
29 0.382004 209.200.248.160 172.16.1.16 TCP http > 8979 [ACK] Seq=1 Ack=1698 Win=11680 Len=0
30 0.395446 172.16.1.16 224.0.0.251 MDNS Standard query PTR _daap._tcp.local, "QU" question PTR _daap._udp.local, "QU" question PTR _rsp._tcp.local, "QU" question PTR _rsp._udp.local, "QU" question ANY SoundBridge._telnet._tcp.local, "QU" question ANY SoundBridge._roku-rcp._tcp.local, "QU" question ANY SoundBridge.local, "QU" question ANY SoundBridge._http._tcp.local, "QU" question
31 0.645222 172.16.1.16 224.0.0.251 MDNS Standard query ANY SoundBridge._telnet._tcp.local, "QM" question ANY SoundBridge._roku-rcp._tcp.local, "QM" question ANY SoundBridge.local, "QM" question ANY SoundBridge._http._tcp.local, "QM" question
...And the chit-chat continues for a while
You can see that the DHCP service gives the M1001 an address of 172.16.1.16, you can see the M1001 contact the NTP service on the server (at 172.16.1.1) and get the time/date, you can see the M1001 ‘phone home’ to soundbridgeupgrade.rokulabs.com and check for upgrades and to http://www.radioroku.com to tell them what I listen to (not really), and finally you can see the M1001 multicasting out to 224.0.0.251 on the 5353 daap port looking for servers.
When its working, my 172.16.1.1 firefly server responds immediately after the M1001 multicast to 224.0.0.251 with a list of supported services (when I’ve got a 10/100 card plugged into my one and only PCI slot). With either of my Gig E cards (one is an “r8169” based card and the other is based on the “Sundance Technology IPG Triple-Speed Ethernet” chipset), there’s no response from the firefly server.
@rsl360 wrote:
I have fedora 10 on my laptop and it has gigabit ethernet, and it works with firefly. But nothing else on the network is gigabit, so maybe that’s why it works.
I have some really old Dell D600 laptops with onboard Gig E and I checked one of these. It seems to work OK – ie when I compile and run a firefly server, the M1001 sees it immediately. It streams music OK. I’ve not had it running for long, just to start a song to see it works. Also – the same gig E NICs used to work fine with F8 and svn-1696. I was running this version of firefly on F8 without power-down for 18 months or more and earlier version on F7, F6, F5, F4 ….
Since the last posting, I’ve somehow configured the ‘broken’ GigE server so that the M1001 sees the firefly server *sometimes* but not all the time. If it sees it, it *sometimes* can’t connect (with the connection failed message on the screen on the M1001). If it connects, it is able to start streaming music, but it stops sometimes later with the message that it can’t find any music libraries. I’ve been trying desperately to capture the offending behaviour in wireshark so that I can compare the packet trace using a 10/100 card with the packet trace using a gig E card, to find out what’s missing or not – but I can’t seem to reproduce the behaviour in a reliable way – like I say, it *sometimes* seems to work, but not consistently. And I’ve been changing too many things to be able to confidently say what it is that got the M1001 to start seeing the firefly server in the first place.
This is seeming horribly like driver / networking issues with the latest fedora kernel or the ethernet driver code. Or possibly its an issue with the (now old) svn-1696 code with the (newer) fedora 10 kernel and drivers.
I shall be expending more effort because I’m damned if I’m going to give up and return to F8!!!
Any other ideas??
Thanks.