While troubleshooting a network problem on my
MacBook Pro
laptop, I noticed, while examining a
packet
capture file in Wireshark, that a system was
sending a lot of
User Datagram Protocol (UDP) traffic to the xxx.xxx.xxx.255 subnet
broadcast address, i.e. to all systems on the
subnet,
using port 54915 as both the source and destination
ports. The below screenshot shows what I saw when I applied
a Wireshark filter
of udp.port == 54915.
Wireshark was associating the media access control (MAC) address for the system sending those UDP datagrams with Apple. The first six hexadecimal digits of a MAC address identifies the manufacturer of the network interface controller (NIC) in the device. The MAC address was f4:5c:89:c0:42:47 and F4:5C:89 is a code assigned to Apple, Inc.
When your system communicates with other devices over the network using the TCP/IP protocol, you can alo find the MAC address of other systems in communication with your system in the Address Resolution Protocol (ARP) table on the system. If the system is on the same subnet on your local area network (LAN), you can also see the ARP address by pinging the address of the other system and then checking the arp table with the arp command. If there is an intervening device, such as a router or firewall, between the system issuing the ping command and the address pinged, you won't be able to determine the MAC address of the system pinged, only the MAC address of the intervening device. And the MAC address shown by Wireshark and other packet analyzer programs, will only reflect the MAC address of the nearest intervening device, if the systems aren't on the same LAN and there is one or more intervening network devices such as routers or firewalls.
$ ping -c 1 128.154.156.83 PING 128.154.156.83 (128.154.156.83): 56 data bytes 64 bytes from 128.154.156.83: icmp_seq=0 ttl=64 time=112.225 ms --- 128.154.156.83 ping statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 112.225/112.225/112.225/0.000 ms $ arp -a | grep 128.154.156.83 gssla16040496-128154156083.abc.example.com (192.168.156.83) at f4:5c:89:c0:42:47 on en0 ifscope [ethernet] $
The results of the above ping also suggest the system is an Apple system, rather than a Microsoft Windows system, since the time to live (TTL) in the echo reply packets from the system is 64, since Apple OS X and iOS systems use a TTL value of 64, whereas it is usually 128 for Windows systems, though other operating systems also use a value of 64 - see Identifying Apple systems on the network.
Why may you see UDP packets with a source port of 54915 and a destination port of 54915 being sent to the broadcast address for a subnet? When I searched for information on these packets, I found they are associated with Logitech's Arx control software. Logitech states in regards to that software:
Win the information war and stay ahead of the competition with critical in-game information on your tablet or smartphone. Arx control serves as a second screen for supported titles.
Arx Control lets you monitor and control your Logitech G peripherals without ever leaving the game. Fine-tune your mouse DPI in real time, or call up a list of your G-Key macros for quick reference right on your smartphone or tablet device.
Troubleshoot and monitor your system hardware with GPU/CPU temperatures and usage levels. Control your media or launch games remotely with built-in controls.
Arx Control is available on Android and iOS on tablets and smartphones, and works on any system with Logitech Gaming Software installed. Stand your smartphone upright in the adjustable Arx Smart Dock, on select Logitech keyboards, for convenient viewing.
You can find the software on Apple's App Store at Logitech Arx Control. The page states "This app is only available on the App Store for iOS devices. Apple employs the iOS operating system on its iPhone, iPad, and iPod Touch devices. The software apparently looks for other devices with the Arx Conrol software installed by sending out the broadcast packets to UDP port 54,915 and then waits for those devices to respond.
When I looked at the contents of the packets with Wireshark, I saw the following globally unique identifier (GUID) in the data field:
{85606d47-401a-4575-a7fa-10d380f4313d}
Related articles:
