New Avahi package
-
@dennypage My pcaps show that Avahi is sending a pair of IGMPv3 joins for 224.0.0.251 when it starts, then no additional control packets from Avahi are showing up on the wire afterward, even on a capture that I let run 20 minutes. Perhaps my understanding of how Avahi works is wrong, but shouldn't I see periodic IGMP membership reports from Avahi for this mcast group?
The switches and AP have separate IGMP snooping settings, of which I've tried every combination of snooping on and off for the VLANs connected to each interface (hn1 and hn3) and each combination of having it enabled on all hardware, disabled on all hardware, only enabled on switches, and only enabled on APs. No matter what combination I use, snooping does not seem to affect the behavior at all.
When the switch snooping is enabled, the switches will act as and elect a querier by default. I've read that in some environments, people have had success keeping mDNS working by using an IGMP querier (though I'd expect Avahi to fulfill that role if a querier on a switch is not present) because snooping will aggressive prune ports that don't generate queries or reports to indicate that they want to remain joined to the group. Given that I'm not seeing any membership reports over 20 minutes, even with snooping completely off, could this be causing the device to stop participating in mDNS?
And for what it's worth, we're going on about 4 hours now with the pfBlockerNG VIP removed from hn1 and still haven't seen the culprit device drop from mDNS yet. Again, not sure if this is coincidence and whether the issue lies with a pfSense behavior or IGMP, but it's a promising result so far.
-
@xpxp2002 said in New Avahi package:
@dennypage My pcaps show that Avahi is sending a pair of IGMPv3 joins for 224.0.0.251 when it starts, then no additional control packets from Avahi are showing up on the wire afterward, even on a capture that I let run 20 minutes. Perhaps my understanding of how Avahi works is wrong, but shouldn't I see periodic IGMP membership reports from Avahi for this mcast group?
Just for clarity, applications such as Avahi do not send IGMP packets, operating systems do.
Simplified version... when the first application on a host joins a multicast group on an interface, the OS sends an initial IGMP message indicating that it has joined the group. When the last application on the host leaves the group, the OS will send a IGMP message indicating that it is leaving the group. In between the join and leave, It will not send another membership message for the group unless it receives a specific request from a router or a switch to confirm that it is still a member of the group.
Debugging IGMP multicast issues can be a serious pain. Unless you have a great deal of confidence in the implementations, I would simply disable IGMP snooping. Particularly for wifi. Unless you have a large amount of multicast in your network that you need to prune, it isn't going to have a negative impact. Just make sure that multicast forwarding is enabled (if such a setting exists in your gear).
-
Thanks. I have edited the avahi.inc file for the moment while waiting the package update. Just want to make sure if the package got updated via GUI then the avahi-deamon.conf gets updated with the point to point flag.
-
@sammybernard said in New Avahi package:
Thanks. I have edited the avahi.inc file for the moment while waiting the package update. Just want to make sure if the package got updated via GUI then the avahi-deamon.conf gets updated with the point to point flag.
Not sure if you are asking about the behavior with the current version 2.0.0_1 or the coming 2.0.0_2...
With 2.0.0_1, any change to the configuration will cause avahi-daemon.conf to be overwritten, and the manual edit for allow-point-to-point flag will be lost.
With 2.0.0_2 and beyond, the config file will always be written with the allow-point-to-point flag set. Given that the interface list is positive selection only, there really isn’t a reason to make the point-to-point setting configurable via the GUI.
I expect the new version will be available shortly after folk return from holiday next week. You can follow the PR using the link above.
-
Same package, another question :
In the good old days, I could see what avahi "sees" doing by running :avahi-browse -a -vOr, now :
avahi-browse -a -v Failed to create client object: Daemon not runningWith the help of Google and the left mouse button, I found out that in the file
/usr/local/etc/avahi/avahi-daemon.conf
This lineenable-dbus=nois hard coded to "no".
Making itenable-dbus=yesrewriting the config and .....
avahi-browse -a -v Server version: avahi 0.7; Host name: pfsense.local E Ifce Prot Name Type Domain + fxp0 IPv6 pfsense [00:12:3f:b3:58:75] _workstation._tcp local + fxp0 IPv4 pfsense [00:12:3f:b3:58:75] _workstation._tcp local + sis0 IPv6 pfsense [00:0f:b5:fe:4e:e7] _workstation._tcp local + sis0 IPv4 pfsense [00:0f:b5:fe:4e:e7] _workstation._tcp local + fxp0 IPv6 pfsense _ssh._tcp local + fxp0 IPv4 pfsense _ssh._tcp local + sis0 IPv6 pfsense _ssh._tcp local ......Thoughts ?
-
@gertjan Yes, this is intentional. There are no local mDNS browse clients for pfSense, so there isn't much use for dbus support on the firewall itself. Further dbus was the cause of a couple of significant issues, one being the minimum 5 second startup delay, and the other being a sporadic failure of Avahi to start at boot for many users.
If you want to see what is in the network, I would recommend doing this from a general workstation or laptop in the network. This will also give you a better view into the overall functionality of reflection. There are several tools that support this. If you are a Mac user, then there is a free application called "Discovery" that is pretty nice. For a Unix based system, you can use avahi-discover (GUI) or avahi-browse (command line). I haven't used Windows in many years, but I'm sure there are some decent tools there as well.
-
@dennypage said in New Avahi package:
@gertjan Yes, this is intentional. There are no local mDNS browse clients for pfSense, so there isn't much use for dbus support on the firewall itself. Further dbus was the cause of a couple of significant issues, one being the minimum 5 second startup delay, and the other being a sporadic failure of Avahi to start at boot for many users
Ok, get it - the only browser that exist on the firewall was ..... avahi-browser ^^ (this one needs avahi - logic, and mbus I guess).
I have the Discovery app my Mac (iPhone) : great tool !
Thanks for the detailed explanation.
-
@dennypage said in New Avahi package:
the point-to-point setting configurable via the GUI.
I meant that while we wait for the 2.0.0_2 version, I have edited the avahi.inc file based on the GitHub changes you had submitted so avahi-deamon.conf will have the allow-point-to-point flag.
-
@sammybernard Sounds good.
-
I can confirm my OpenVPN interfaces, that wouldn't get MDNS before, get it now with v2.0.0_2
Thanks!
(I can control the Chromecast from work once again...) -
@muppet You’re welcome. Glad it’s working for you.
-
Would it be possible to to set a single listen network then select rebroadcast networks?
I have an edge case of having several VLANs, three of which have castable devices, but only one of those devices should be visible on multiple networks.
There is a common area Shield TV (should be visible to it's network, and three others), as well as my bedroom Chromecast (should only be visible on my network) and my roommate has a Chromecast (should only be visible on his network).
Or a a client exclusion by IP address or network?
-
@METDeath Avahi reflection, which is what is used to proxy mDNS, applies to all allowed interfaces. There is no way to limit the advertisements. Remember however that being able to see the device doesn't mean that you can route packets to it. Standard firewall rules still apply.
In other words, you can't hide it but you can easily prevent people from using it.
-
@dennypage Yup, just wanted to make it less of a headache, plus I had my roommate on his VLAN try casting to my Chromecast on my VLAN and it triggered some odd behavior on my phone about my Chromecast.
-
Hi.
Sorry if this is a stupid question.My setup is Lan interface on OPT1 192.168.10.x and wireless on OPT2 10.10.10.x
I have some rules in place to allow specific Lan devices to access the wireless network.
However anything using multicast, Chromecast, printer, scanner, DNLA etc fail.
Would this package help and how would I set it up ?Thanks
-
@TomT said in New Avahi package:
Would this package help and how would I set it up ?
Yep.
Install it - start it - done.
Default setup values do fine for me. Just select all your local LAN interfaces. -
Thanks. I'll give it a go
-
I'm about to set this up.. but had a quick follow up thought.
When this is enabled will it allow OPT -> OPT1 & OPT1 -> OPT ?
Thanks
-
@TomT Avahi reflection allows cross network discovery for all interfaces which it is configured on. That being said, remember Avahi itself offers discovery only. In other words, Avahi will allow you to see that a service is available in another network, but it doesn't mean you will be able to access the service. Access is controlled by firewall rules.
-
Hello,
Sorry if I don't post in the right place.
We have a site-to-site vpn tunnel (openvpn) between 2 pfSense instances. It is operational. We want to be able to use the Mac OS Messages app (formerly iChat) between our 2 LANs. We installed and configured Avahi 2.0.0_2 on each side. In the friends list, we can't see the remote stations. Likewise, Discovery app only lists local stations. The firewall is configured to allow to see (any ports) the remote stations on each side: LAN 192.168.10.0/24 and LAN 192.168.60.0/24.
We don't see why it doesn't work.
However, a post indicates that it is possible: https://forum.netgate.com/topic/18877/routing-apple-bonjour
Thanks in advance for any help. We aren't geeks !
Best regards from France.Here is the Avahi configuration used:
[Server]
allow-interfaces = RE0
allow-Point-to-Point = yes
use-ipv4 = yes
use-ipv6 = no
enable-dbus = no
Cache-entries-max = 0[Wide-area]
enable-wide-area = no[Publish]
disable-publishing = yes
publish-addresses = No
publish-hinfo = no
publish-workstation = no
publish-domain = No.
publish-yyyy-on-ipv4 = no
publish-on-a-ipv6 = no
disable-user-service-publishing = yes[Reflector]
enable-reflector = yes
