Lately I've noticed a constant flood of these entires in my syslog. ipv6 already disabled in my Unraid Network Settings (set to ipv4 only). Has anyone found a solution to either how to address these or disable them so they don't fill up logs? Seems my syslog would be almost empty without them. Thanks.

Oct 2 04:46:06 Unraid avahi-daemon[35430]: Record [Unraid._ssh._tcp.local IN SRV 0 0 22 Unraid.local ; ttl=120] not fitting in legacy unicast packet, dropping.

Oct 2 04:46:06 Unraid avahi-daemon[35430]: Record [_smb._tcp.local IN PTR Unraid._smb._tcp.local ; ttl=4500] not fitting in legacy unicast packet, dropping.

Oct 2 04:46:06 Unraid avahi-daemon[35430]: Record [Unraid._smb._tcp.local IN TXT ; ttl=4500] not fitting in legacy unicast packet, dropping.

Oct 2 04:46:06 Unraid avahi-daemon[35430]: Record [Unraid._smb._tcp.local IN SRV 0 0 445 Unraid.local ; ttl=120] not fitting in legacy unicast packet, dropping.

Oct 2 04:46:06 Unraid avahi-daemon[35430]: Record [_sftp-ssh._tcp.local IN PTR Unraid._sftp-ssh._tcp.local ; ttl=4500] not fitting in legacy unicast packet, dropping.

Oct 2 04:46:06 Unraid avahi-daemon[35430]: Record [Unraid._sftp-ssh._tcp.local IN TXT ; ttl=4500] not fitting in legacy unicast packet, dropping.

Oct 2 04:46:06 Unraid avahi-daemon[35430]: Record [Unraid._sftp-ssh._tcp.local IN SRV 0 0 22 Unraid.local ; ttl=120] not fitting in legacy unicast packet, dropping.

Oct 2 04:46:06 Unraid avahi-daemon[35430]: Record [_device-info._tcp.local IN PTR Unraid._device-info._tcp.local ; ttl=4500] not fitting in legacy unicast packet, dropping.

Oct 2 04:46:06 Unraid avahi-daemon[35430]: Record [Unraid._device-info._tcp.local IN TXT "model=Xserve" ; ttl=4500] not fitting in legacy unicast packet, dropping.

Oct 2 04:46:06 Unraid avahi-daemon[35430]: Record [Unraid._device-info._tcp.local IN SRV 0 0 0 Unraid.local ; ttl=120] not fitting in legacy unicast packet, dropping.

Oct 2 04:47:06 Unraid avahi-daemon[35430]: Record [Unraid._ssh._tcp.local IN SRV 0 0 22 Unraid.local ; ttl=120] not fitting in legacy unicast packet, dropping.

Oct 2 04:47:06 Unraid avahi-daemon[35430]: Record [Unraid.local IN A 192.168.0.168 ; ttl=120] not fitting in legacy unicast packet, dropping.

Oct 2 04:47:06 Unraid avahi-daemon[35430]: Record [_smb._tcp.local IN PTR Unraid._smb._tcp.local ; ttl=4500] not fitting in legacy unicast packet, dropping.

Oct 2 04:47:06 Unraid avahi-daemon[35430]: Record [Unraid._smb._tcp.local IN TXT ; ttl=4500] not fitting in legacy unicast packet, dropping.

Please post the diagnostics.

33 minutes ago, JorgeB said:

Please post the diagnostics.

Hi @JorgeB attached per your request. Really appreciate any insight you're able to provide. Thanks in advance.

unraid-diagnostics-20261002-1117.zip

Thanks for the diagnostics. These messages mean that Avahi cannot fit all the service-discovery records into a legacy unicast reply. This also happens over IPv4, so disabling IPv6 does not prevent it.

Your logs show bursts about once per minute, which suggests a device or application is repeatedly querying the server. The log filesystem is currently only 6% used.

To help identify the sender, run this in the Unraid terminal while the warnings occur:

tcpdump -pni br0 -nn -vv 'udp dst port 5353 and not udp src port 5353'

Let it run for about two minutes, then press Ctrl+C. Which device owns the source IP that repeats around the warning times? If you need help interpreting the output, post a few matching lines with addresses and hostnames replaced by consistent labels.

I recommend identifying that sender before disabling Avahi, since Avahi provides network service discovery.

Hi @JorgeB per your request, I was able to capture the attached logs from tcpdump using a docker container with tcpdump on host. Note these are all unique hardware devices and/or VLANs not running on my physical unraid instance. My unraid is on the 192.168.0.0/24 subnet:

Hardware 1:

192.168.0.1 my Unifi gateway

192.168.10.1 my Unifi CCTV gateway

192.168.20.1 my Unifi IoT gateway

192.168.30.1 my unifi guest gateway

Hardware 2:

192.168.0.193 Roon Rock media server

unraid_tcpdump.txt

Edited October 2Oct 2 by miles267

Thanks, this narrows it down. Your UniFi LAN gateway sends a large discovery query at 13:09:06 and again at 13:10:06. Both request SSH, SFTP, SMB, and device-info, the services listed in the Avahi warnings.

Similar queries also appear from the VLAN gateway addresses, which suggests mDNS forwarding. These packets do not need to originate from containers on Unraid.

The gateway queries are the strongest lead. However, we need syslog from the same capture period to confirm the connection.

Could you temporarily turn off UniFi’s mDNS Proxy, then watch the syslog and repeat the capture for about three minutes? Record the original setting first. Restore it afterward and check whether the warnings return. Leave Roon and Avahi running during this comparison.

This can temporarily interrupt device discovery across VLANs, including AirPlay, Chromecast, and printers.

Please also provide your UniFi Network version, gateway software version, and current mDNS Proxy mode. If the large queries continue with proxying disabled, we can investigate gateway discovery separately.

Hi JorgeB. I’ve have also done some testing and I believe I’ve isolated the source to a scheduled UniFi gateway process.

Environment:

- Gateway: UCG Fiber

- UniFi OS: 6.0.10

- UniFi Network: 10.6.106

- Unraid server: Antharas

- Antharas LAN IP: 192.168.1.20

- Antharas also has 192.168.2.20 on the IoT VLAN

- UniFi mDNS Proxy was originally set to Auto

I first performed the test you suggested and disabled UniFi mDNS Proxy. The Avahi warnings continued at the same approximately once-per-minute interval, so disabling the configurable mDNS Proxy did not stop the queries/warnings. I subsequently restored mDNS Proxy to its original setting.

I also temporarily restricted the Unraid Avahi configuration from:

allow-interfaces=br0,br2.2

to:

allow-interfaces=br0

and restarted Avahi. The warnings still occurred, so having Avahi active on both the LAN and IoT VLAN was not the cause. I restored the original interface configuration afterward.

I then captured the traffic directly on the UCG. This showed the gateway sending queries from 192.168.1.1 to 224.0.0.251:5353 using ephemeral UDP source ports and with the QU bit set, requesting unicast replies.

The timing is particularly interesting. At xx:xx:06, I captured a gateway query containing exactly:

device-info.tcp.local

sftp-ssh.tcp.local

smb.tcp.local

ssh.tcp.local

At that same :06 second, Antharas logs the corresponding:

not fitting in legacy unicast packet, dropping

messages for sftp-ssh and device-info.

This behaviour repeats every minute. So the :06 timing of the gateway discovery query and the Unraid Avahi warnings correlates exactly.

I initially investigated the UCG's normal avahi-daemon. One of its persistent high UDP ports was involved in a larger discovery query, but I completely terminated the UCG Avahi daemon and confirmed its PID was gone. Antharas still produced the warnings at the next :06. Therefore the UCG's normal Avahi daemon was not required to trigger the issue.

I also stopped /usr/bin/uos-discovery-client as a diagnostic test. The warnings continued.

Rebooting the UCG Fiber also did not change the behaviour.

I then monitored short-lived UDP sockets/processes on the UCG and found a process being launched approximately once per minute:

/usr/sbin/ubntmdnsd

Example command line:

/usr/sbin/ubntmdnsd -t10 -f /tmp/mdns_services.json -c /data/udapi-config/mdns.cache -s -j -b -u -e meshcop,trel

I found what launches it:

/etc/cron.d/mdns-job

contains:

* * * * * root /usr/sbin/ubntmdnsd -t10 -f /tmp/mdns_services.json -c /data/udapi-config/mdns.cache -s -j -b -u -e meshcop,trel

So the UCG is explicitly launching ubntmdnsd once every minute.

I then inspected /tmp/mdns_services.json. It includes, among many other services:

device-info.tcp

sftp-ssh.tcp

smb.tcp

ssh.tcp

Those are the same four services in the gateway query captured at :06.

Finally I performed an A/B test. I temporarily renamed:

/etc/cron.d/mdns-job

to:

/etc/cron.d/mdns-job.disabled

I left Unraid Avahi running and made no other changes.

The once-per-minute Avahi warnings stopped completely.

I then restored /etc/cron.d/mdns-job, since it is a UniFi-managed component and I did not want to leave the gateway modified.

So at this point the chain appears to be:

UCG Fiber cron (every minute) → ubntmdnsd → QU mDNS discovery query → Antharas Avahi legacy-unicast response → not fitting in legacy unicast packet, dropping warnings at :06.

The configurable UniFi mDNS Proxy being Off does not stop ubntmdnsd from performing this discovery.

I have also raised this with Ubiquiti support and they have escalated the case, but I have not yet received a response from their escalation team.

If useful, I can provide the packet captures showing the gateway query at :06, the corresponding Unraid syslog from the same time, /tmp/mdns_services.json, or repeat a synchronised capture/syslog test.

Thanks, that's excellent work, and it fully explains the warnings.

Avahi decides how to answer a query by its source port, not by the QU bit. Any query that doesn't come from port 5353 is treated as a "legacy unicast" query. The reply must then fit into one 512-byte packet, and Avahi logs a warning for every record it has to leave out. ubntmdnsd runs as a short-lived job from cron and sends from an ephemeral port, so every run hits that path.

Asking for four service types in one query is more than fits, which gives you the burst at :06 each minute. That also explains why disabling mDNS Proxy made no difference: this scan is separate from the proxy.

The only side effect is that the gateway's own scan sees an incomplete list of the Unraid services. Other devices on the network query from port 5353 and get complete replies, so normal discovery from Macs, Windows, and so on is not affected. Nothing is wrong on the Unraid side.

The proper fix needs to come from Ubiquiti, for example by sending these queries from port 5353 or by splitting them. Your escalation is the right way forward. I wouldn't leave mdns-job disabled, since it's UniFi-managed and probably used by the gateway's own features. Please post back if Ubiquiti replies or a later UniFi release changes the behavior.

This should also apply to the original poster's setup, since the timing and requested services are identical.

I am also experiencing this since last nights update to Ubiquiti 6.0.17