It looks like a curious bug but the real catch is that for some people
(like you), it happens a lot, but for others, they don't see it...
which makes it hard to diagnose.
Your first post implies it has been diagnosed, but I don't see that in
the thread there... did I miss a way to duplicate this? (Computers may
-seem- random and chaotic, but they are really, well, programmed and
predictable... so things should be reproducable... but finding the
exact conditions is the tricky part.)
Is there anything special about your setup that this happens?
Looking at the packet capture, I see this:
Code:
--------------------
12:49:58.508392 00:04:20:06:68:e4 > Broadcast, ethertype ARP (0x0806), length
60: arp who-has 192.168.1.24 (Broadcast) tell 192.168.1.20
12:49:59.427438 00:04:20:06:68:e4 > Broadcast, ethertype ARP (0x0806), length
60: arp who-has 192.168.1.24 (Broadcast) tell 192.168.1.20
12:50:00.349080 00:04:20:06:68:e4 > Broadcast, ethertype ARP (0x0806), length
60: arp who-has 192.168.1.24 (Broadcast) tell 192.168.1.20
12:50:01.577808 00:04:20:06:68:e4 > Broadcast, ethertype ARP (0x0806), length
60: arp who-has 192.168.1.24 (Broadcast) tell 192.168.1.20
12:50:02.499364 00:04:20:06:68:e4 > Broadcast, ethertype ARP (0x0806), length
60: arp who-has 192.168.1.24 (Broadcast) tell 192.168.1.20
12:50:07.414606 00:04:20:06:68:e4 > Broadcast, ethertype ARP (0x0806), length
60: arp who-has 192.168.1.24 (Broadcast) tell 192.168.1.20
12:50:08.336120 00:04:20:06:68:e4 > Broadcast, ethertype ARP (0x0806), length
60: arp who-has 192.168.1.24 (Broadcast) tell 192.168.1.20
12:50:09.565006 00:04:20:06:68:e4 > Broadcast, ethertype ARP (0x0806), length
60: arp who-has 192.168.1.24 (Broadcast) tell 192.168.1.20
--------------------
That is the Squeezebox at 192.168.1.20 saying, "Hey, my server was at
192.168.1.24, what is the MAC address of that?" And getting no
response.
Which would mean the server is no longer at 192.168.1.24, or the server
is broken... at the networking level. (Perhaps a firewall? But it is
long before any software from SlimDevices.. the TCP/IP stack on
192.168.1.24 should be responding all by itself.)
Intermixed with these, I see this:
Code:
--------------------
12:50:47.658257 00:04:20:06:68:e4 > Broadcast, ethertype IPv4 (0x0800),
length 144: IP (tos 0x0, ttl 64, id 33474, offset 0, flags [none], lengt
h: 130) 192.168.1.20.3483 > 255.255.255.255.8900: [udp sum ok] UDP, length:
102
--------------------
That is the Squeezebox, again. This time it is sending a UDP broadcast
out, saying, "Hey, anyone listening on UDP/8900? Hello?"
I have no idea why it is doing that: the usual "slim discovery" port is
3483.
On reboot, the SB in that log then connects immediately to
Squeezenetwork, I don't even see it trying to connect to a local server
until it looks like it is logged off SN:
Code:
--------------------
12:55:15.559548 00:04:20:06:68:e4 > Broadcast, ethertype IPv4 (0x0800),
length 60: IP (tos 0x0, ttl 64, id 58, offset 0, flags [none], length: 4
6) 192.168.1.20.3483 > 255.255.255.255.3483: [udp sum ok] UDP, length: 18
12:55:15.560833 00:0c:76:bd:46:d5 > 00:04:20:06:68:e4, ethertype IPv4
(0x0800), length 60: IP (tos 0x0, ttl 128, id 21302, offset 0, flags [none]
, length: 46) 192.168.1.24.3483 > 192.168.1.20.3483: [udp sum ok] UDP,
length: 18
--------------------
That is the SB again asking "hello? anyone talking to me?" with a UDP
broadcast, but this time it is on the right port and gets an answer.
And oddly:
Code:
--------------------
12:55:17.778834 00:04:20:06:68:e4 > Broadcast, ethertype ARP (0x0806), length
42: arp who-has 192.168.1.24 (Broadcast) tell 192.168.1.20
12:55:17.779664 00:0c:76:bd:46:d5 > 00:04:20:06:68:e4, ethertype ARP
(0x0806), length 60: arp reply 192.168.1.24 is-at 00:0c:76:bd:46:d5
--------------------
Now ARP works and the server is responding. It is the exact same thing
that is at the start, but this time 192.168.1.24 feels like responding.
If the server responded like that at the start of the log, it should
have worked... but again, ARP responses are low-level IP stuff (well at
the border between IP and Ether layers...) and an application program
can't change the responses... only a firewall or broken IP stack should
break them.
Is there a firewall on that machine? What is breaking ARP?
--
snarlydwarf
------------------------------------------------------------------------
snarlydwarf's Profile: http://forums.slimdevices.com/member.php?userid=1179
View this thread: http://forums.slimdevices.com/showthread.php?t=31661
_______________________________________________
discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss
