Bugzilla – Bug 11600
Report of Squeezebox sending unnecessary Network Traffic
Last modified: 2013-10-11 13:59:42 UTC
Created attachment 5023 [details] First Pcap from E4E Hello All, We have received reports from the Admin of our vendor E4E that there is a large amount of traffic coming from our Squeezebox devices. Overall, after reviewing the PCAPs, I believe that part of the problem could be that there are lots of echoing going on within the network, causing unnecessary traffic the may appear as some type of outside attack. Attached are Pcaps of this issue. Below is what I what I have gathered from the PCAPs. 192.168.120.28 to 192.168.11.45 - Facebook - DNS query 192.168.120.28 to 192.168.11.45 - Ad Sense - googleads.g.doubleclick.net - DNS query 192.168.120.28 to 98.174.28.33 - TCP Source port 50771 - Destination port 80 192.168.120.28 to 98.174.28.59 - TCP Source port 50775 - Destination port 80 192.168.120.28 to 216.52.240.134 - TCP Source port 50769 - Destination port 80 - Also saw some from TCP source port 50767 and port 50766 192.168.120.28 to 74.125.19.154 - TCP - Source port 50773 - Destination port 80 Not too sure on what this device is, but seems that 192.168.120.28 could be some type of Server, or this could be a problem IP on the network. There are a lot of TCP traffic entries from the source 192.168.120.28. As for Squeezebox Traffic: 192.168.120.13 to 66.151.159.227 - The majority of the Squeezebox traffic is between these two IP addresses I researched the IP address 192.168.120.13 and found that this MAC address is Chad's Squeezebox Duet controller (00:04:20:1a:6d:d1). The IP address 66.151.159.227 is for the SV SqueezeNetwork Server. The majority of these entries seem to be TCP OUT-OF-ORDER, which, from my understanding can be caused by a firewall or virtual router filtering or scanning the packets, causing the Packet sequence to get thrown off. This could be caused by stateful packet inspection. All other traffic was normal for the other Squeezebox Devices in the pcaps. I hope this information is helpful. Thanks, LaRon
Created attachment 5024 [details] 2nd Pcap from E4E
Created attachment 5025 [details] 3rd Pcap from E4E
(correspondance to E4E, from DanE) We have investigated the wireshark logs you provided. Our initial conclusions are: * You have one system on your network that is producing a lot of echoed traffic. (Unknown system, IP 192.168.120.28 in the logs.) * One of the Squeezebox Controllers also is producing a lot of traffic (Chad's controller, IP 192.168.120.13 in the logs.) What I don't see is any other Squeezeboxes in these logs. Previously you were very convinced it was the Squeezeboxes on your network causing the bandwidth drain. Do have additional evidence of this? Granted, the above Controller is causing some undue traffic, but I doubt it would explain the magnitude of bandwidth usage you describe. More data is needed. I'd recommend adding the SMS team's Squeezeboxes back to your network, one at a time if you like. See if you see the same problem as before. Just don't connect Chad's Controller, to be safe.
(correspondence from E4E, from JohnH) Hi Dan The problem only appears when the units are left on all the time. The traffic from 192.168.120.28 is from a supervisors laptop PC and can be ignored. We have already in the past tried adding units one by one back on the network on a “full time” basis, only to see the aggregate outbound traffic from the 120 vlan skyrocket to between 2.5Mbps and 3.5Mbps. We can repeat these test and gather more packet captures for you. The most compelling evidence that this traffic is a result of the SMS device is when we see this large and continued spike in outbound internet traffic, we can put a stop to it by simply unplugging the SMS devices. As soon as the SMS devices are powered off, the traffic stops. This really only leaves two logical conclusions, 1) The SMS devices are generating the traffic or 2) the SMS devices have been breached and are being used as a WiFi bridge. Since we know from your team that these devices are not capable of acting as a bridge as they are connected (no LAN connection), the conclusion has been that it is the SMS devices generating the traffic.
I've got plenty of controllers. I'm happy to trade for Chad's controller if we think it will help.