[SOLVED] Need help debugging a.b.c.255 UDP spam (Logitech ARX)

[The Muppet Surgery Special]

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.

[One Cut]

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).

[koolaidman04]

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]

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]

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.

[Renegrade]

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.

Originally posted by 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™]

Pointless necro. The thread is already answered.