Re: udpiiu messages

["Hu, Yong via Tech-talk" <tech-talk at aps.anl.gov>]

Since we also use a number of GigE cameras, this issue reminded me to check the IOC logs for similar messages — and indeed, I found sporadic error messages across multiple camera-connected IOCs.

After a quick review of the source code and with some help from ChatGPT, I found a simple and practical workaround: use a firewall rule to drop the problematic UDP packets on the IOC’s Channel Access (CA) network interface. My IOC server has two NICs — one connected to the camera subnet and the other to the EPICS CA subnet.

The workaround looks like this:

iptables -A INPUT -i <IOC_CA_NIC> -p udp --sport 3956 -j DROP

This effectively filters out unwanted UDP traffic originating from the GigE camera protocol (port 3956), preventing it from interfering with Channel Access.

Cheers,

Yong

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Hill, Jeff via Tech-talk <tech-talk at aps.anl.gov>
Date: Monday, February 2, 2026 at 2:59 PM

 

The Ethernet, IP, and UDP checksums are not strong enough to detect situations where almost every byte in the message is damaged. This can cause even the UDP port field to arrive damaged.

The switch and attached device should be set for continuous auto-negotiation following modern practice. 

Often this problem happens because the network device driver auto-negotiates only once when booting up, and perhaps the switch was not powered up at that time.

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Hill, Jeff via Tech-talk <tech-talk at aps.anl.gov>
Sent: Monday, February 2, 2026 12:10 PM

This can pccur when one of the network switch or connected device are manually set to run at inconsistent ethernet clock rates...

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>
Sent: Thursday, January 29, 2026 7:26 AM

Folks,

I am seeing error messages like this printed in the Linux shell periodically:

../udpiiu.cpp: Undecipherable (payload too small) UDP msg from 10.54.160.250:3956 ignored

../udpiiu.cpp: Undecipherable (payload too small) UDP msg from 10.54.160.250:3956 ignored

../udpiiu.cpp: Undecipherable (payload too small) UDP msg from 10.54.160.246:3956 ignored

../udpiiu.cpp: Undecipherable (payload too small) UDP msg from 10.54.160.250:3956 ignored

../udpiiu.cpp: Undecipherable (payload too small) UDP msg from 10.54.160.246:3956 ignored

../udpiiu.cpp: Undecipherable (payload too small) UDP msg from 10.54.160.250:3956 ignored

../udpiiu.cpp: Undecipherable (payload too small) UDP msg from 10.54.160.246:3956 ignored

../udpiiu.cpp: Undecipherable (payload too small) UDP msg from 10.54.160.250:3956 ignored

../udpiiu.cpp: Undecipherable (payload too small) UDP msg from 10.54.160.246:3956 ignored

The messages are being printed from udpiiu.cpp in EPICS base.  I believe they are generated by medm that is running in the background.  medm is built with base 7.0.7.

I believe port 3956 is used for GigEVision.  This suggests that the devices with those IP addresses could be cameras, but they are not registered in our DNS.  I am trying to track them down.

However, given that the messages appear to have nothing to do with EPICS, why is EPICS base printing an error message, rather than simply ignoring them?

What do these messages mean, and can they be turned off? 

Thanks,

Mark