I posted this in the forums, but now realise I should have submitted a bug report.

I last asked about this issue one year ago. Basically, my University's network staff report that my Squeezbox malfunctions, degrading network performance to the Princeton University campus. When this happened last year the work-around was to connect the squeezebox directly to my computer via its Ethernet interface. This year I resorted to using the wireless again. Unfortunately, the SB3 continues to malfunction (see the University's technical report below), which has now resulted in my being banned from the network (see below: we have a three-strikes-you're-out rule and I was changing the MAC address to stay on-line).

Last time I asked about this I was told that it wasn't possibly having any real affect on Princeton's network performance, and so I assumed that the true reason it was being banned was because it can be used as a bridge (they say, again, at the end of the technical report "it's clear the device is acting as a router"). It turns out I was wrong -- apparently the Squeezebox was having a substantial affect on the campus’s network performance.

Here is the technical part of the email I received. If anyone can tell me anything about this, and can suggest a way of rectifying the problem, I would be most appreciative. The device has been confiscated by campus security, so unfortunately I can't give you any details I wouldn't know by memory. It is running the latest stable firmware, though this was an issue with the firmware that was current this time last year.

I'm filing this as a bug, but I'm also interested in what people make of the report below.

Cheers

Simon

Many thanks,
Simon

-----


[We] determined that the device was likely made by Logitech, and was in the
vicinity of the 23rd entryway of the New Graduate College. OIT Hardware Support staff (accompanied by a University Public Safety officer) visited the area on October 7 2009 to try to locate the device via radio tracking equipment. They were unable to locate the device at that time.

OIT continued to analyze the device's network traffic, and based on the traffic, identified the owner [or operator] as Simon Cullen GS. OIT Hardware Support (accompanied by Public Safety) returned to the New Graduate College on October 12 2009. This time they succeeded in using radio tracking equipment to locate the device. 

The device is a Logitech Squeezebox device (a network-attached music player).

Simon's connection of a device in September and October 2009 that malfunctions
in such a way as to degrade network service counts as "strike three" for him.

His third strike triggers blocking all network service for Simon, and escalation
to an appropriate disciplinary authority.

... I can tell you that OIT seriously considered removing visitor wireless service for the part of New Graduate College housing the offending device as a way of restoring acceptable network performance for the campus.  It was only the hope of discovering the location, and identity of the culprit device that prevented visitor wireless from being pulled completely from that location.

Below are the technical descriptions of the malfunctions causing the network degradation.  I would refer you at this point to Dean Montero to discuss the matter, to arrange to reclaim the confiscated machine, and to make your case to have network access restored for your collection of devices.

...
Technical Description of the Device's Current Malfunctions:


Malfunction 1:

When this device receives an IP broadcast packet from the campus network and it decides that it is not interested in the packet (or that something is in fact wrong with the packet), the device responds by sending an ICMP error message.

Here is an actual packet capture, showing an IP broadcast packet followed by an erroneous response from the device. This was captured on October 12 2009, while the customers' device was forging hardware address 20:55:3f:9d:89:fe:

12:44:59.162446 00:03:ba:5d:21:cf > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 43: (tos 0x0, ttl 1, id 1, offset 0, flags [none], proto UDP (17), length 29) 192.168.7.45.0 > 66.180.184.0.0: UDP, length 1

12:45:00.192777 20:55:3f:9d:89:fe > 00:06:2a:db:a0:c0, ethertype IPv4 (0x0800), length 71: (tos 0x0, ttl 64, id 32463, offset 0, flags [none], proto ICMP (1), length 57) 66.180.184.43 > 192.168.7.45: ICMP time exceeded in-transit, length 37 (tos 0x0, ttl 1, id 1, offset 0, flags [none], proto UDP (17), length 29) 192.168.7.45.0 > 66.180.184.0.0: UDP, length 1

This is not correct behavior; no device should ever send an ICMP error message in response to broadcast or multicast traffic. That's because when many devices behave in this erroneous fashion, it creates very large traffic spikes on the network, degrading network service for everyone. On large networks, such as many that compose the campus network, this is a real danger. (In certain situations, such behavior can even result in self-sustaining broadcast storms that keep the network unusable.)

This sort of behavior can be caused by a bug in the device's IP stack, requiring a bug fix from the vendor of the device. (In some unusual situations, it may also be possible for a device to exhibit this behavior as a result of incorrect configuration, but this is uncommon.)

This is the same malfunction we detected from the customer's device on October 2008.



Malfunction 2:

The device behaves incorrectly when it sees some link layer broadcast frames containing UDP/IP traffic destined to a non-local IP destination.

Below is an actual packet capture taken on the campus network on September 22 2009, while Simon's device was configured to forge hardware address 00:04:66:d7:44:1c.

14:56:35.558001 00:00:07:03:02:01 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto UDP (17), length 29) 192.168.7.45.7654 > 192.168.51.255.7654: UDP, length 1

14:56:35.603021 00:04:66:d7:44:1c > 00:06:2a:db:a0:c0, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 63, id 1, offset 0, flags [none], proto UDP (17), length 29) 192.168.7.45.7654 > 192.168.51.255.7654: UDP, length 1

The first frame is the UDP/IP packet destined to a non-local destination; the customer's device saw the frame because the frame was sent as a link layer broadcast. The IP destination of the frame is non-local from the point of view of the customer's device. Because the packet contains an IP destination address that is not the customer's IP address, nor an IP broadcast address for this network, the customer's device should discard the packet. Because the packet was
sent as a link layer broadcast, the customer's device should send no ICMP error message to the sender; it should simply be silent when it discards the packet.

The second frame is the erroneously-forwarded UDP/IP packet the client's device transmits back to the campus network. The fact that it does so is the problem. The device is transmitting the packet the the hardware address of the default router for the network, and the device has decremented the IP TTL field; it's clear the device is acting as a router.
Edit/Delete Message