Idle HomePod transmitting GBs of data daily

TidBITS Talk
1

I’ve posted this issue on Apple’s Discussion board, but got no meaningful replies, so I thought I’d ask the ever-knowledgeable TidBITS community.

I recently updated my WiFi network gear, replacing an old Asus AP with a new faster Ubiquity access point (a UAP-AC-Lite). The UAP reports real-time data statistics for every client device connected to it. The stats reveal that my Original HomePod is a data pig. It’s transmitting 4 to 5 GB of data daily!! And receiving around 1 to 2 GB per day.

The HomePod is basically idle. It’s not being used. It’s in an upstairs bedroom - nobody’s been saying “Hey Siri” nor asking it any questions, so no need for it to be sending digitized audio to Siri HQ. It’s not been streaming any music (if it had, that would account for some bits being sent from the AP to the HomePod, but not transmitted from the HomePod). The feature to Share Analytics with Apple is turned off (and even if it were enabled, the occasional log file couldn’t possibly comprise gigabytes of data each day).

The HomePod is up to date with v14.6.

To be clear, the telemetry from the Ubiquity AP does not indicate that the gigabytes of data are being uploaded to the internet, just that the HomePod is sending out data on WiFi. No doubt it’s advertising itself on the LAN with mDNS broadcasts, notifying other Apple devices that it’s available. But such broadcast messages should not account for multi-gigabytes per day.

I’ve taken a look at the traffic stats captured by my gateway router. We have lots of internet download traffic (YouTube, Netflix, AppleTV, etc), but I don’t see any signs of multi-gigabytes of data getting sent upstream each day. The destination and purpose of the 4-5 GB of data that the HomePod is transmitting is unknown.

Any ideas?

2

Is it a Homekit hub?

1 Like
3

Michael,
No Homekit devices here (other than the Home Pod and an Apple TV). No HK accessories, no automations…

I wonder if the two of them are constantly yammering back and forth arguing about something.
“Are you there?”
“Yep, I’m here. Are you there?”
“Yep, I’m here. Are you there?”

4

A ~20 byte message divided into 5GB gives a lot of exchanges (millions or billions?)!This must be an exchange of high level data like music - but what and why?

5

Perhaps use Wireshark or similar to see what the traffic is? (I’d connect the machine running Wireshark via Ethernet: I suspect that the Wi-Fi router might filter out the traffic you are interested in.)

6

@ashley
I’ve thought of sniffing the traffic to see what’s going on, but since the HomePod is WiFi-only, it’s hard to access its packets. My current thinking is to add a managed switch to my LAN, connect the Unify AP to it, and configure the switch with a mirror port to get access to all the WiFi traffic to/from the AP. Then I can run Wireshark on a machine connected to the mirror. All in all, a real pain in the LAN.

7

Wow - much more involved than I thought. Thanks for explaining. Is it still possible to put a Wi-Fi card into promiscuous mode to hear the traffic without needing to reconfigure things like this? (Or perhaps I’ve misunderstood - I’ve only done this sort of thing sporadically.)

8

Not really.

Although a Wi-Fi card can go promiscuous to see all the packets on the wireless LAN, encryption will make it impossible to actually read the contents of other devices’ packets.

If your Wi-Fi has encryption/security disabled (bad idea) or if it uses WEP encryption (also bad idea - WEP was cracked a long time ago), then anyone joining your network can read everybody else’s packets.

The WPA series of security protocols (which everybody today should be running) uses a different set of keys for each user, so you can’t sniff anyone else’s packets.

Which means that if you want to sniff packets, you need to intercept them over the wired network (e.g. between the access point and the router or between the router and the modem).

2 Likes
9

The other David C beat me to it - his explanation about sniffing WiFi traffic is a cogent explanation of what’s on the radio link. If you’re interested to see the raw WiFi traffic (and you have a MacBook), you can sniff the packets using the macOS Wireless Diagnostics utility. It has a built-in Sniff function - no reconfiguration required. As David C indicates, the ethernet payload is shrouded with encryption.

I’ve obtained a small managed switch (a D-Link DGS-1100) and hope to add it to my LAN some weekend so I can use Wireshark to intercept the ethernet traffic going to/from the HomePod. In fact, any multicast traffic from the HomePod can be viewed without needing the switch, but the gigabits coming out of the HomePod would be a monster ton of broadcast messages.

The HomePod continues to upload (transmit) 4-5 GB daily.

1 Like
10

Well, you don’t need to capture them all. A short capture (a few seconds to a minute or two worth) should be enough to identify the destination IP addresses (I doubt there will be many).

If these are HTTP-like packets (e.g. REST-like protocols, then WireShark should be able to decode them, letting you see the URLs that are being accessed.

This should be enough to get started figuring out what’s going on.

11

I might first try capturing just the mcast packets on the network and see if there are any insights. I can do that without instrumenting the LAN with a new switch and mirror port. My Wireshark skills are quite rudimentary, but I’ve used it a couple of times in the past to diagnose obscure network issues.

Another thought I had was to set up another (temporary) AP, specifically for the HomePod. It would be wired to the same subnet. Then I could intercept the ethernet traffic on that AP’s LAN connection and inspect it, without having to perturb my primary LAN and the Unify AP. But how does one specify what SSID the HomePod connects to? It magically self-configures without the user having to enter SSID & password like other WiFi clients. There must be some iOS magic going on under the covers.

12

This is interesting - thanks for the explanations!

I noticed you use the word “contents” there. Would a Wi-Fi client on the same network in promiscuous mode still see the IP headers, if not the packet payload? If the source and destination addresses were visible, that would be quite a useful start.

Also… I wonder if TX / RX have got mixed up somehow and the HomePod is perhaps receiving constant (but silent) audio from a device somewhere on the LAN?

13

I don’t think so. I think you’ll see raw Wi-Fi frames (which should include your base station’s MAC address), but I think everything else will be encrypted.

1 Like
14

@Shamino
Some progress to report.
I added another AP to my LAN, with the same SSID as the Unify AP (so I wouldn’t have to reconfigure the HomePod). Inserted a managed switch between the new AP and the LAN. Configured a mirror port on the switch to mirror the upstream traffic (from the HomePod to the AP). Then used Wireshark to capture some traffic.

Around 10K packets captured in a minute!
The HomePod is sending a constant flood of traffic to a Mac mini on my LAN. It’s running OSX server, does Time Machine backups, runs an instance of Apple Mail with SpamSieve, and has a few other utilities on it that I need from time to time.
The Mac mini has iTunes on it, but I don’t use it. There’s no music in the library, hence no music library shared on the LAN that the HomePod might want to play.

In the 60-second capture, there are thousands of SYN/ACKs. That indicates that the Mac mini has initiated a TCP connection with the HomePod (by sending a SYN). The HomePod then responds with a SYN/ACK. Since I’m only capturing one side of the stream, I don’t see the entire 3-way handshake (SYN, SYN/ACK, ACK). Wireshark is just captures the upstream. By and large, the packets are small (66 bytes), but there are so many of them, the daily total is multiple gigabytes.

There are hundreds of RST (reset) messages being sent by the HomePod. Don’t know why.

There are hundreds of RTSP/1.0 200-OK messages that the HomePod is sending to the Mac mini, all containing the same text block:

  • application/x-apple-binary-plist
  • Server=AirTunes
    and other text strings that appear to be the HomePod advertising its audio capabilities to the Mac mini.

The Mac mini is rather old (10.11.6, El Capitan). I haven’t upgraded it because the version of Safari that’s on it still supports a couple of plug-ins that I need.

I may be able to reconfigure the managed switch to mirror both RX and TX, so I can then sniff both sides of the traffic flow. But I’m not sure I want to spend a weekend reverse engineering the data exchange between HomePod and macOS. A better use of time might be trying to figure out how to tweak the Mac mini so it will stop playing AirPlay games with the HomePod.

2 Likes
15

Interesting. At least it’s on your LAN, so it’s not burning through your Internet bandwidth and shouldn’t have any privacy implications…

The port numbers should help identify what services the Mac is trying to connect to. Even if they are Apple-proprietary services, a web search should help identify them. Once you know, it may be possible to configure the Mac to stop. Or at minimum, you’ll understand what’s going on.

TCP RST packets are used to close a connection that has gotten into a messed-up state. Or to refuse an incoming connection (typically because there is nothing listening on the port that could accept the connection.) Again, once we identify the port involved, we can know what’s going on and whether you want to make the Mac stop requesting connections, make the HomePod start accepting them or do nothing.

The RTSP reply OK message is a reply to a request it received from the Mac. You would need to see what the request is to understand the reply, but it may well be a Bonjour discovery mechanism for different Macs on your LAN to identify the HomePod and its capabilities.

I’m wondering if any devices on your LAN are configured to stream audio to the HomePod. Maybe they are trying to maintain the connection or quickly determine when availability goes up/down in order to accurately present a list of devices on an AirPlay menu.

If all the communication is with your Mac mini, then you should be able to run Wireshark on it and see both sides of the connections.

Thanks for keeping us updated. I am almost as interested as you are to learn what’s going on.

2 Likes
16

@Shamino
With help from Wireshark, the culprit has been found. The instigator of the flood of HomePod traffic is my Mac mini.

The fix: reboot the Mac mini.

TL;DR:
After reconfiguring the switch to mirror both Rx and Tx, I ran some more captures. First unplugged the HomePod. Started the capture, then plugged in back in (so I could watch its start-up behaviour). Several seconds after power-up, I see the DHCP Request and Ack, as the HomePod requests a lease for its reserved IP address. It sends out some mcasts (both IPv4 and IPv6) announcing that it’s a Airplay device. And also that it’s a Homekit device, and a Sleep Proxy server.

About 3 seconds later, mayhem ensues.

The Mac mini starts hammering it with TCP/IP connections to port 7000. The first capture showed over 4500 TCP SYNs in the first 2 seconds! (each from a different source port). The Mac mini really really wants to talk to the Home Pod.
Each of the SYNs evokes a SYN/ACK from the HomePod, then an ACK (standard 3-way handshake). Once the connection is established, the Mac mini sends a payload containing GetInfo Airplay. The HomePod replies with an RTSP/1.0 200-OK, and some strings indicating its AirPlay capabilities (packet size = 1514 bytes).
HomePod sends another payload containing “Audio Accessory” (328 bytes). Then the two ends tear down the TCP/IP socket. 14 packets in total for this conversation.

Each of the 4000-5000 connections sent from Mac mini to HomePod in the first few seconds results in another identical 14 packet conversation.

The Mac mini then backs off for a while, but not for long. Exactly 10 seconds after the start of the first flood, the Mac mini starts up again, sending another 4-5K SYNs to the HomePod, again over a couple of seconds. HomePod dutifully responds to each and every one. This pattern repeats forever: every 10 seconds, the Mac mini decides it needs to query the capabilities of the HomePod. Each GetInfo AirPlay query from the Mac mini causes the HomePod to transmit 1514+328 bytes of information back. That explains why my Unify AP was reporting a larger amount of upstream (HomePod to AP) traffic than downstream.

As far as I can tell, the only reason for the Mac mini to be interested in the HomePod is so the HomePod can be used as a potential audio output device. The HomePod (and my AppleTV) are both listed as AirPlay devices in the Output pane in the Sound preferences. El Capitan was thoughtful enough to build this list on its own…

Rebooting the Mac mini fixed whatever defect in the bowels of El Capitan is responsible for this aberrant behavior. I don’t know how long it will behave itself. I’ll have to keep an eye on the HomePod traffic reported by the Unifi AP to see if it recurs.

5 Likes
17

This doesn’t have any practical use for me, but I’ve really enjoyed reading your journey of discovery, and have been following with bated breath. So thank you for keeping us updated, taking the time to investigate, and posting all the details here. :raised_hands:

2 Likes
18

@jzw
Thanks! It’s been an interesting little ‘project’.

Along the way I found that the HomePod is an extremely chatty device. After powering up, it does a couple dozen DNS queries, looking up the IPs for what I assume are various Apple servers. It then establishes a number of secure sessions to such servers (TLS/1.3 on port 443) and they exchange some information. Since it’s all encrypted, I have no idea what info is being exported to or received from AppleHQ. The HomePod is probably logging on to my iCloud account so it could play music upon request (though I don’t have an Apple Music account). It’s probably checking for new iOS firmware. No doubt it’s connecting to a Siri server to handle any spoken commands.

Wireshark also revealed a ton of IPv6 messages on my LAN. I really wasn’t expecting this. I surmise that all the Apple devices on my network (there are a lot) have all assigned themselves local IPv6 addresses, and use that address scheme to chat among themselves. I know very little about IPv6 (other than that it exists), so can’t really decipher the various IPv6 mcast messages that Wireshark captured. (My ISP does not support IPv6, and as far as I know, there is no DHCP server on my network assigning IPv6 addresses, so they must be self-generated by the Apple devices).

1 Like
19

Was the anything in the log files on the Mac mini that suggests why it was acting so weird?

20

Good question.
Nothing jumps out, but I really have no idea where to look. I’ve always found the Console logging infrastructure somewhat inscrutable. There are hundreds of MBs of log files in /Library/Logs. Even more in /private/var/Logs.