Este tópico foi fechado
The Muppet Surgery Special (Banido(a)) 5 fev. 2016 às 9:07
[SOLVED] Need help debugging a.b.c.255 UDP spam (Logitech ARX)
Need some help debugging a.b.c.255 UDP spam I see in Wireshark

I have a network and NAS and I noticed the LAN LED blinking constantly even when it is not in use.

I used Wireshark to locate some UDP spam to a .255 address (broadcast) on my subnet.

I used Follow UDP stream and it is constantly showing my machine NAME and what looks like a 128-bit GUID in braces {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} constantly in each UDP packet.

I now have the NAS in idle down sleep mode, but my machine is still broadcasting that packet.

Destination: Broadcast (ff:ff:ff:ff:ff:ff)

Any ideas what it is? I searched the registry for the GUID but nothing found.

Source Port: 54915
Destination Port: 54915
Length: 271
Data length: 263

I found this

https://www.reddit.com/r/HomeNetworking/comments/3vukok/crazy_udp_broadcast_packets_where_they_come_from/

I have a Logitech KB and mouse and joystick and their drivers, anyway to stop this UDP spam?

I did a netstat -a and found nothing listening on that port.

This is causing my managed switch and NAS to constantly deal with this UDP broadcast spam.


SOLUTION:

Source of broadcast spam: Logitech ARX

Open Logitech Gaming Software keyboard software
Click settings
Open ARX Control tab
Disable mobile and automatic discovery


Whilst I was doing this, I found another source of broadcast spam

Wireshark filter

eth.addr == ff:ff:ff:ff:ff:ff

DropBox, it broadcasts every 30 seconds a bunch of requests both network wide and subnet wide. I fixed this by going to DropBox Settings-> Bandwidth -> unchecking Enable LAN Sync.


If you see your switch / devices LAN constantly blinking even with inactivity, it most likely is broadcast (destination MAC: ff:ff:ff:ff:ff:ff) spam on the network. You want to keep this to a minimum. Probably not an issue for most people, but with multiple clients (even on the same machine) it can suck up the bandwidth especially if it becomes a storm.
Última alteração por The Muppet Surgery Special; 5 fev. 2016 às 14:03
< >
A mostrar 1-6 de 6 comentários
One Cut 5 mai. 2017 às 20:50 
Thank you for this. I was trouble-shooting my PC, and WireShark found the same spam on both my regular connection and my VirtualBox Host-Only Network (with VirtualBox closed out).:squirtyay:
koolaidman04 4 mar. 2018 às 19:59 
You are a life saver. I would have spent hours searching for the source of my network spam and this took care of it instantly.

Apart from the thanks, the reason I am posting is to let future people suffering this same fate that the length of the packet is 305 now on my computer.

I don't know if this is because of an update on Logitech's behalf or because of a difference in some other system.

Thanks again!
Capricorn1 18 fev. 2019 às 6:47 
SPAMming LANs since 2016. I actually found this a while back with Logitech gaming software on my desktop, but recently my laptop started flooding my network with UDP packets (which my firewall was denying and logging) when I installed a Logitech camera and mouse. Got me again.

Packet size I am seeing is 271. Not sure if that matters.
iceman1980 18 fev. 2019 às 14:23 
Configure VLANs problem solved. 350 byte packets that is pretty small. Correction no they're not packets they are FRAMES not packets when talking about layer 2 traffic.
Última alteração por iceman1980; 18 fev. 2019 às 14:24
Renegrade 3 jan. 2020 às 4:57 
Thanks guys - this old post helped me squelch the source of these packets (wife's computer's mouse software)! According to the timestamps in Wireshark, it was being sent literally every second.

Originalmente postado por Tarantula Hawk:
Configure VLANs problem solved. 350 byte packets that is pretty small. Correction no they're not packets they are FRAMES not packets when talking about layer 2 traffic.

They are indeed frames (ethernet II broadcast to ff:ff:ff:ff:ff:ff), but they are also packets - IP broadcast on the local subnet, and UDP port 54915. Layers 2, 3 _and_ 4.

Also VLANs only contain the issue by (possibly) narrowing the broadcast domain. It'll still be causing unnecessary overhead on every device on the same VLAN as the offending machine(s). It's best to kill this sort of BS at the source. So I'm off to Logitech's programming department with a clue-by-four...
Red™ 3 jan. 2020 às 6:01 
Pointless necro. The thread is already answered.
< >
A mostrar 1-6 de 6 comentários
Por página: 1530 50

Postado a: 5 fev. 2016 às 9:07
Comentários: 6