Avahi (mDNS) stops working after ~30 mins on pfSense 2.5
-
My captive portal is also 'wifi' based.
Its 29 minutes later now, I can still see all my printers.
-
@gertjan do you have any virtual IPs or other interfaces?
-
-
@gertjan is your avahi on just the ipv4 interfaces?
-
IPv4 is present for backwards computability.
Most LAN traffic is IPv6.
Portal traffic is IPv4 only.
-
@gertjan I see. Since you’ve already checked virtual IPs that was what was causing my issue so I’m not sure what else I can suggest unless something else is causing another in / interface to appear on ipv6 which is causing avahi troubles..
-
This is the log, I still don't see device for casting.in youtube also in spotify, no tv no google mini.
Mar 1 17:17:00 avahi-daemon 39099 Found user 'avahi' (UID 558) and group 'avahi' (GID 558). Mar 1 17:17:00 avahi-daemon 39099 Successfully dropped root privileges. Mar 1 17:17:00 avahi-daemon 39099 avahi-daemon 0.8 starting up. Mar 1 17:17:00 avahi-daemon 38815 Found user 'avahi' (UID 558) and group 'avahi' (GID 558). Mar 1 17:17:00 avahi-daemon 38815 Successfully dropped root privileges. Mar 1 17:17:00 avahi-daemon 38815 open(/var/run/avahi-daemon//pid): File exists Mar 1 17:17:00 avahi-daemon 38815 Failed to create PID file: File exists Mar 1 17:17:00 avahi-daemon 39099 WARNING: No NSS support for mDNS detected, consider installing nss-mdns! Mar 1 17:17:00 avahi-daemon 39099 Loading service file /usr/local/etc/avahi/services/sftp-ssh.service. Mar 1 17:17:00 avahi-daemon 39099 Loading service file /usr/local/etc/avahi/services/ssh.service. Mar 1 17:17:00 avahi-daemon 39099 Joining mDNS multicast group on interface igb1.IPv4 with address 10.10.10.1. Mar 1 17:17:00 avahi-daemon 39099 New relevant interface igb1.IPv4 for mDNS. Mar 1 17:17:00 avahi-daemon 39099 Network interface enumeration completed. Mar 1 17:17:00 avahi-daemon 39099 Server startup complete. Host name is pfSense.local. Local service cookie is 717637330. Mar 1 17:17:00 avahi-daemon 39099 Failed to add service 'pfSense' of type '_ssh._tcp', ignoring service group (/usr/local/etc/avahi/services/ssh.service): Not permitted Mar 1 17:17:00 avahi-daemon 39099 Failed to add service 'pfSense' of type '_sftp-ssh._tcp', ignoring service group (/usr/local/etc/avahi/services/sftp-ssh.service): Not permitted Mar 1 17:30:24 avahi-daemon 39099 Leaving mDNS multicast group on interface igb1.IPv4 with address 10.10.10.1. Mar 1 17:30:24 avahi-daemon 39099 Joining mDNS multicast group on interface igb1.IPv4 with address 192.168.2.1
-
Up until :
@mrvarga said in Avahi (mDNS) stops working after ~30 mins on pfSense 2.5:
Mar 1 17:17:00 avahi-daemon 39099 Failed to add service 'pfSense' of type '_sftp-ssh._tcp', ignoring service group (/usr/local/etc/avahi/services/sftp-ssh.service): Not permitted
I see the same lines.
But my Avahi isn't
Joining mDNS multicast group on interface igb1.IPv4 with address 10.10.10.1.
as this is the pfBlockerNG web interface. Not some sort of network where I need Avahi to do something.
Btw : I parked this 10.10.10.1 to the local lo0 network :
@gertjan said in Avahi (mDNS) stops working after ~30 mins on pfSense 2.5:
I parked it on the lo0 (local host) interface.
( not on LAN !! )
Also : Avahi doesn't log what it does.
-
Hello to anyone who stumbles across this.
I too was battling with this Avahi issue and discovered that the root cause (in my case at least) was that Avahi wasn't re-joining interfaces properly after suricata does it's updates/refreshes. Disabling suricata means that Avahi now works flawlessly.Whilst not ideal for those who wish to use Suricata, I hope this will help to narrow down the cause of the problem for anyone who gets stuck on it like I did!
-
@theskelly said in Avahi (mDNS) stops working after ~30 mins on pfSense 2.5:
Hello to anyone who stumbles across this.
I too was battling with this Avahi issue and discovered that the root cause (in my case at least) was that Avahi wasn't re-joining interfaces properly after suricata does it's updates/refreshes. Disabling suricata means that Avahi now works flawlessly.Whilst not ideal for those who wish to use Suricata, I hope this will help to narrow down the cause of the problem for anyone who gets stuck on it like I did!
This likely happens because Suricata (if running with Inline IPS Mode) will cause netmap to take the interface down and then back up as Suricata stops and restarts. This is an artifact of the netmap kernel device and not something Suricata does intentionally.
I would not expect that behavior with Legacy Mode, though, as that simply uses libpcap to grab copies of packets traversing the interface. To my knowledge libpcap won't cycle the interface when it is stopped and restarted.
-
I have the same issue with Suricata resetting the interfaces. I looked into the suggestion made by @bmeeks, but do not know where to set the mode between inline and legacy. I had a quick look around, but I am yet to find the option. I have also read that it is the safer option to stay in Inline mode if you can.
With this in mind, I have enabled the setting where Suricata would do a live rules swap after a rules update. It states that it would not do a hard reset of the Suricata instances.
Goto Services/Suricata/Global Settings then under Rules Update Settings enable Live Rule Swap on Update.
I have done a manual rules update to test and when Suricata did the live swap it did not reset the interfaces so this seems to be working for now.
-
I had similar issue with Avahi and the posts about Suricata got me thinking and I realized I had a cron job to restart an openvpn client and server and it was the cause of my Avahi and homekit issues even though avahi was not bound to the openvpn interfaces.
-
@vlan_one thanks for the suggestion! The Live Rule Swap option fixed this for me. Now I can run both Avahi and Suricata with no issues
-
@theskelly I am glad I could help.