Multicast and DTIM with implicit I/O
EtherNet/IP I/O sent as multicast crosses Wi-Fi at the basic rate with no acknowledgement and no retry, and waits for the DTIM beacon whenever a client uses power save, so it loses frames that the same connection as unicast would recover.
On this page5 sections
Is this your problem? It presents like this
- I/O connections time out while pings and explicit messages to the same device stay clean.
- Stationary devices lose I/O as well as moving ones.
- Loss grows with distance from the access point and with channel load, because nothing is retried.
- Access points with no multicast consumer show multicast in their transmit counters.
- Multicast I/O arrives late, by up to the DTIM interval, when phones or handhelds in power save share the access point.
- A wireless device that consumes multicast can lose that data after a roam while unicast to it resumes.
- Bands
- 2.4 GHz5 GHz5 GHz DFS6 GHz
Why it happens
An access point sends a multicast frame once, to everyone, and never learns who missed it. There are no acknowledgements for multicast, so nothing is retried, and a loss rate of 5% or more1 is not unusual. The frame goes out at the basic rate so the farthest station can decode it. Unicast to the same device gets acknowledgements and retries. Multicast gets one try.
EtherNet/IP can put I/O on multicast by design. Data from the target back to the originator can be UDP multicast, so other devices can listen. A design guide for EtherNet/IP over WLAN states the cost: multicast frames are not acknowledged and not repeated if lost, which raises loss and the chance of connection timeouts. It calls for unicast connections only for wireless I/O and produced and consumed data. ControlLogix supports unicast for standard I/O from version 182, and the current Logix manual selects it for a consumed tag by default. Multicast stays one checkbox away.
Power save adds delay. If any one station on the access point has power save enabled, the AP holds all multicast until the next DTIM beacon. With hostapd’s defaults, a beacon every 100 time units of 1.024 ms3 and a DTIM on every second beacon, that wait can reach about 205 ms. Your I/O devices may never sleep. One phone in power save on the same access point is enough.
The wired side decides where multicast goes. ODVA highly recommends IGMP snooping. A snooping switch with no membership report from a port does not forward the group there, and it may flood groups it has no report for to every port. Flooded multicast is copied onto the WLAN at the basic rate. Hosts report when they join and when the querier asks, every 125 seconds by default4, so a wireless consumer that roams to another switch port can wait for the next query.
Access points can convert multicast to unicast, but the IETF notes there is no standardized method yet, and one vendor turns conversion off above a client count, 32 in its example5. Configure the connection as unicast, and the radio never has to guess who heard it.
How to confirm it
- List every I/O and produced and consumed connection that crosses the WLAN, and check whether each one is unicast or multicast.
- Time the gaps as in the measurement guide on one multicast and one unicast connection to the same device, and compare their loss.
- Capture over the air near a consumer. Group-addressed I/O frames (UDP port 2222 to a multicast address) get no acknowledgement and no retry. Note the rate they go out at.
- Read multicast packets sent and received in each radio's statistics, and compare them with your baseline.
- Check the beacon interval and DTIM period on the SSID, and whether any client on the access point uses power save.
- On the switches, confirm IGMP snooping and an active querier on the I/O VLAN, and check which ports each group reaches before and after a roam.
The measurement guide shows how to probe, capture, and time a drop step by step.
The fix
- Change wireless I/O and produced and consumed connections to unicast wherever the controller and the device support it.
- Where multicast has to stay, run IGMP snooping with a querier on the VLAN, so each group reaches only the ports that joined it.
- Keep wired multicast that no wireless device consumes off the access points' switch ports.
- Set the DTIM period to 1 on an SSID that must carry multicast I/O, and keep power-saving phones and handhelds off it.
- Treat multicast-to-unicast conversion on the access point as a fallback. Find its client limit and test it with your devices.
Prevent it at design time
- Write unicast for every connection that crosses the WLAN into the controls specification and the project review.
- Give I/O its own SSID with no phones, tablets, or laptops on it.
- Baseline the multicast counters on every radio, and alarm on unexpected multicast.
- Include a roaming multicast consumer in acceptance tests, and time how long its data takes to return after each roam.
About this page
Built from 8 sources: 3 standards bodies and labs, 1 protocol owner or alliance and 4 vendor documents. Researched and drafted with AI assistance. How pages are made
- First published
- Last updated
Change history (1)
- First published
Cite this page
Plain
Ben Rutter. "Multicast and DTIM with implicit I/O." OT Wireless, published October 8, 2026. https://otwireless.com/causes/multicast-and-dtim-with-implicit-io/
APA 7
Rutter, B. (2026, October 8). Multicast and DTIM with implicit I/O. OT Wireless. https://otwireless.com/causes/multicast-and-dtim-with-implicit-io/
BibTeX
@misc{rutter2026multicastanddtimwithimplicitio,
author = {Rutter, Ben},
title = {{Multicast and DTIM with implicit I/O}},
year = {2026},
howpublished = {\url{https://otwireless.com/causes/multicast-and-dtim-with-implicit-io/}},
organization = {OT Wireless},
}