New package: pimd

  • Rebel Alliance Developer Netgate

    I created a package for pimd, which is a multicast routing daemon. I don't have a use case for it here, but we've had requests for it due to various shortcomings in igmpproxy. This is primarily to replace the role of the built-in IGMP Proxy function, it is not a replacement for Avahi.

    You might have seen references to pimd pop up in threads for things like SONOS speakers, IPTV, etc.

    It is now available for all users on 2.4.4-p3 as well as 2.4.5 & 2.5.0 snapshots.

    It should be possible to create any valid pimd configuration using the GUI alone, and likely some invalid ones. There is input validation but it's unlikely to catch everything. Raw config should not be necessary since the config format is so basic and all possibilities are covered by the GUI.

    Since the package is new, feel free to use this thread to give related feedback for whatever comes up initially (failures, typos, etc). Eventually I'll lock this down and new issues will go in separate threads.

    EDIT: Now available on 2.4.4-p3.

  • LAYER 8 Global Moderator

    I can not think of when I personally would need this - but its great to see expansion of capabilities.. And thanks Jim for heads up and info.. Sure many are grateful for your effort and contributions..

    I will have to find a way to test it out once 2.4.5 or 2.5 are live..

  • @johnpoz
    those that like doing "large scale" OS deployments might like it. If you get it work, multicast wds is nice.

    in the past i've moved the deployment-server to the corresponding client-vlan to be able to use broadcasts because i've never managed to get igmp-snooping & multicasts working correctly

  • Rebel Alliance Developer Netgate

    FYI- This is now showing up to install on 2.4.5 and 2.5.0 snapshots. If you don't see it, update to the latest snapshot and check again.

  • LAYER 8 Moderator

    Thanks! Hopefully will try at the weekend to update to 2.4.5-snapshot and try it out. With gaining access to the media VLAN without switching WiFis would be great.

  • Rebel Alliance Developer Netgate

    Seems to be working OK so I enabled it for 2.4.4-p3 as well, so anyone can install it now.

  • Seems to be working between interfaces on both my lab routers. I intend to connect two routers together and see if I can get traffic from one LAN to the other through a third LAN. But so far so good.

  • @chpalmer I'm complete new to this, is it possible to share some basic setup tip?

    I'm trying to have my Media Vlan working (Sonos, TV and Google chrome cast) but no luck so far

  • Still working on it myself..

    Seems when I updated snapshots I had to go back into the config page and hit "save" to get the package to "work" again.

    Even though its running Ive had no success as of yet with a multicast test program.. But I am trying to traverse two routers each connected to the other with a /30 subnet.

    I need to test more when I have time.

  • @jimp firstly thank you! awesome that you've made PIMD available as a package, really appreciated!

    I currently have a working Sonos implementation running over split VLAN's, using PIMD (manually installed as a package at OS level) and working perfectly.

    This PIMD package installed perfectly on 2.4.4-RELEASE-p3 for me, however for some reason it's not working like the OS installed version of PIMD does. I'll do some debugging today and figure out why.


    Manually configuring an RP address seems to have resolved my issue, now fully operation with Sonos discovering speakers on separate VLAN.

  • @msass there's a couple of elements to this in my experience, one is getting multicast working across VLAN's but you'll probably need some rules tuning as well (depending on how locked down your connectivity is between VLAN's).

    In terms of configuring PIMD, I'd suggest starting with a fully open configuration and then starting to lock it down. If you've installed PIMD then then change "Default Bind" to "Bind to All" and enable it. If that then gets everything working you'll need to start locking it down, as I wouldnt recommend having it running on, for example, your external interface.

  • @PacketMan Could you show us in more detail what you did to make it work for the Sonos devices or PM me

  • @Qinn said in New package: pimd:

    @PacketMan Could you show us in more detail what you did to make it work for the Sonos devices or PM me

    I'd be happy to help but probably easier if you tell me how far you've got and I help debug your setup. Most of my setup I did 18 months ago so it's not all fresh, do you have PIMD installed and are you seeing any multicast routes appear?

    UPDATE I've just found your other posts so I know you're further on, have you added a RP address? I didn't need to add the multicast group and the address has to be one reachable from all VLAN's.

  • just to be sure could you add a screenshot of your setting or if you don't want to share it publicly PM it to me, thanks.

  • LAYER 8 Moderator

    @jimp just testing out the package on 2.4.4-p3. When stopping/restarting I see a few of these:

    /status_services.php: The command '/usr/local/etc/rc.d/ stop' returned exit code '1', the output was ''

    every time the service is stopped. Perhaps a little error/oversight in the package?

  • Rebel Alliance Developer Netgate

    @JeGr said in New package: pimd:

    When stopping/restarting I see a few of these:

    Might be something we can avoid, not sure what might be causing that off the top of my head, though. It tries to shut down pimd nicely and then attempts to kill anything left over, but I didn't think either of those steps would cause the whole script to exit with an error like that.

  • LAYER 8 Moderator

    @jimp Also seem to have the problem that the package doesn't save its configuration in all dialogues right. Added/removed RP adresses by trial and error and even after removing all entries, the package restarted with "load static rp x.y.z.a". Only saving in the general settings after all removal and restarting seemed to solve that. There definitely seem to be config issues with adding/removing things.

  • 2.5 after a reboot-

    PIMD is enabled but not running. Check the configuration.

    I have to go hit save on the main PIMD screen to get this-

    Virtual Interface Table ======================================================
    Vif Local Address Subnet Thresh Flags Neighbors

    0 24.xx.48/20 1 DISABLED
    1 192.168.1 16 DR NO-NBR
    2 10.50.1/30 16 PIM
    3 register_vif0 1

    Vif SSM Group Sources

    Multicast Routing Table ======================================================
    --------------------------------- (,,G) ------------------------------------
    Number of Groups: 0
    Number of Cache MIRRORs: 0

  • @Qinn said in New package: pimd: just to be sure could you add a screenshot of your setting or if you don't want to share it publicly PM it to me, thanks.

    There would be no value in me sharing my PIMD setup, all I have done is enabled it, added the two interfaces (with no other config) and then an RP address (again none of the other fields).

    I think there's something in the RP address, someone used the Sonos speaker as the RP address but I suspect the problem is the reachable of the RP address from both subnets. The VLAN my speakers are on can't access the LAN for which the clients are on but I have a third interface/VLAN which is reachable by both and I put the IP address of the pfsense box as the RP address within that globally reachable VLAN.

  • Rebel Alliance Developer Netgate

    Just pushed out pimd version 0.0.2:

    • Fixed bonus tabs in status output
    • Fixed input validation of RP Candidate entries to allow empty group prefix
    • Fixed sync on delete for entries on tabs
    • Fixed error in stop script
    • Fixed shortcuts on config tabs other than 'General'

    It should be available now (or in a few moments, anyhow) for 2.4.4-p3, and with the next snapshot run for others.

  • @jimp is there any chance for a short guide how to basic setup this for

  • Rebel Alliance Developer Netgate

    Not from me, I don't have a use case here that I could test. Check the other threads out like the one linked a few replies up. You'll find examples there that worked for others.

  • LAYER 8 Global Moderator

    If I was going to do this, I would do it on my switches.. I have no use for multicast routing currently, nor can I see a need in the future either... To be honest in a home setup just best to put the stuff that needs to talk multicast on the same L2.. In an enterprise it would be done on the switches normally.

    Connect your phone or whatever to that L2 when you want to do whatever that requires to talk multicast to other devices. Ie if you want to control your sonos speakers or stream to them - then connect to that network.. That is way better then sending multicast traffic over multiple vlans..

    What I currently do on my switches for multicast is block it - because for me all it is noise! have nothing that uses it..

    The only use case I can see for this is where you need/want multicast routing and your switches are very lowend smart switches that can barely do vlans. So I am sure there will be plenty of users that can use it - just not something I would have a want or need to spend time doing a guide for.

  • @jimp thanks

  • @msass it's worth noting that @jimp has exposed all of the configuration options available via PIMD but you really don't need the vast majority for a basic home setup (might be an idea to have a simple mode and advanced mode). Literally decide on what interfaces should participate in multicast routing and it should work. I've found it gets complicated when your firewall rules get involved. I've found that whichever rule matches your multicast traffic must have the option to "Allow IP Options" enabled, as many multicast packets have this. PIMD's automatic selection of the RP didn't work for me either, this appears to be because I didn't have a reachable interface IP between the two VLAN's that both segments could reach.

    @johnpoz I should admit that my career in InfoSec has made me paranoid but I'm a big believer in L2 separation of IOT devices from other more sensitive systems (i.e. my NAS) and even run Snort between the two VLAN's. I also have an increasing number of systems and IOT devices that rely on multicast for discovery of services. I run numerous IOT closed eco-systems (e.g. Sonos, Smartthings, Heatmiser, Fibaro, HomeKit, Harmony Remote, Apple TV and then a series of Chinese copy products) with a HomeBridge providing a single interface via Apple HomeKit.

    PIMD has been a life saver and Pfsense's support for multicast routing makes it stand out from the crowd!

  • LAYER 8 Global Moderator

    I have multiple alexas, I have harmony remote.. I have multiple other iot devices. smart bulbs, smart switches, nest protect, s30 thermostat, garage door is iot for gosh sake.. None of which requires any sort of multicast bleeding from 1 L2 into another...

    All of these devices are isolated from the rest of my vlans..

    The closest thing that I have run into any sort of issue with discovery is clients being able to do airprint to printer... Simple solution is just to put the wired printer on my trusted wireless vlan.. So now my wifes phone, tablets, laptops that need/want to use airprint can just connect to that wireless network. My pc which is on my main lan, no wireless connectivity too can just print to the printers IP.. Doesn't need discovery, etc.

    While I understand that multicast has vast amount of uses.. I think blurring the line between between your vlans you isolated for "security" via routing multicast across them so you can discover something with multicast is defeating the whole purpose of isolation in the first place.

    If I want to do something with my roku's for example that requires discovery, I just connect my phone/tablet to do that.. But once the device has been setup once - the phone/table doesn't have to be on that vlan anymore, etc.

    Especially if your going to allow the full multicast group of 224/4, if you do need to do it, you should limit it to the specific groups required for X to work.

    While I am quite sure this function/feature can be of great use for specific use cases in the pfsense community.. And is great add to the product in general.. What I am concerned with is that users just doing this without understanding the underlaying security implications of just joining your multiple L2 together via multicast..

  • @johnpoz I can't argue with your point on caution of security implications, although I guess there's already some expectation you should have some knowledge of what you're doing when you build a home firewall (understanding how to build effective rulesets isn't a novice task imho).

    I've certainly had problems with my Apple handsets and tablets (Airprint was another good example), maybe you're using Android for your mobile kit, I dunno but Sonos is by far the most popular use case as you'll see from the numerous posts. Whilst I'm happy to change networks for a given application, my wife certainly isn't, just switching HDMI inputs usually involves plenty of cursing at high amplitude (for my benefit of course).

    I guess my motivation was to ensure it's value isn't dismissed, I for one am on pfsense purely for the ability to support Sonos across VLAN's and I feel multicast use (or to be more precise mDNS) in the consumer electronics segment isn't going away anytime soon (I'd also suggest that L3 enabled switches aren't common place in the home market).

    (Naturally I've filtered my multicast groups)

  • LAYER 8 Global Moderator

    No android personal devices in my home (not my choice).. Not sure what some of this iot stuff runs. You get sucked into a eco system.. And then its hard to break out ;) I am on my last ipad that is for sure.. But work phone and wife phone are apple. I was pretty excited that work was going to allow choice of work phone - and then they changed their mind.. And only apple as choice.

    Sonos yes is very common.. Security issues with them are nothing new.. Their latest debacle about updates with older stuff is example of how fun this stuff can be ;)

    You don't need L3 enabled switches to help fix some of the issues, just vlan support and soho routers that can support them.. You have these $300 plus mesh wifi systems everywhere - and they have zero actual vlan support - WTF!!! sad, you don't have to make it a requirement for the use to do - but it should be able to if you so desire..

    If anything - hopefully such exchanges of information will get users to do a bit of research before clicking to allow XYZ..

    I can understand the need of multicast in sending audio to multiple speakers at the same time.. Do they have documentation on how to do it correctly, what multicast group to allow.. How to set it up if your actually using vlans. Or do they just assume everyone using their products are one big flat L2?

    As to lowering security for user ease of use - this is a wide spread issue to be sure ;) Seems maybe your wife just needs some instruction - hehehe.. Yeah my wife complains the same - this is not printing.. Well your on the wrong network hun.. Just click here.. After 10 or 20 times it seems to have sunk in ;) Why apple will not just allow you to put in the IP of the printer vs that airprint nonsense is beyond me to be honest...

    These companies should really step up their game - but problem is proper security cost, and would reduce their profit margins or raise the cost and users want things for cheap as possible, vs actually functional secure setups.. And I get it, when 99.9% of your user base is just on 1 flat network and using of non secure discovery methods makes it easier for the user - then damn straight that is what is going to be on pretty much all soho devices. It really is just a sad state of affairs!

  • @johnpoz you're baiting me now with technology religion and politics, I can't resist ;)

    L3 switches, I was referring to your point on having the switches deal with Multicast.

    Sonos actually insist, and try to limit that everything is on the same L2 segment but also to their own Sonosnet rather than your existing WIFI (that took me hours to figure out how to migrate onto my actual WIFI). I don't believe Multicast is used for the streaming, in terms of their app, it's purely the initial discovery of the "master" speaker using mDNS then the address of it is cached in the app and it's all unicast.

    Now if you want to write a howto on convincing the wife to adopt new technology, I will personally give you a months salary! I love her to bits but mine, when doing the online shopping, just sits there for hours moaning about how crap online shopping is (EXPLETIVE Internet, EXPLETIVE Technology, how stupid the tool is (in that she can't find what she wants). My attempts to suggest getting off her butt then and down the supermarket don't seem to be helping ;)

    I think the reality is many of the engineers developing this stuff aren't security aware and they don't seem to pen test their own products, I guess with the drive to reduce manufacturing costs and the pressures from China, or am I just making excuses for them now.

  • LAYER 8 Global Moderator

    @PacketMan said in New package: pimd:

    L3 switches, I was referring to your point on having the switches deal with Multicast.

    Doesn't have to do L3 to route multicast.. Example the cisco sg200 line is only L2, and it can route multicast ;)

    Now my sg300, can also do it - but it can also do L3 routing..

    it's all unicast.

    So you have 3 speakers for example about your house - and your sending the same song to all 3... It unicast those on sep streams, vs just multicasting it? That seems moronic!! And sure and the hell would not be efficient..

  • @PacketMan said in New package: pimd:

    @Qinn said in New package: pimd: just to be sure could you add a screenshot of your setting or if you don't want to share it publicly PM it to me, thanks.

    There would be no value in me sharing my PIMD setup, all I have done is enabled it, added the two interfaces (with no other config) and then an RP address (again none of the other fields).

    I think there's something in the RP address, someone used the Sonos speaker as the RP address but I suspect the problem is the reachable of the RP address from both subnets. The VLAN my speakers are on can't access the LAN for which the clients are on but I have a third interface/VLAN which is reachable by both and I put the IP address of the pfsense box as the RP address within that globally reachable VLAN.

    I've tried this exact configuration and I still am unable to connect to my existing Sonos devices when trying to configure the application from scratch on a workstation installed behind a VLAN. Are you doing anything special in your switches to make this happen, i.e. IGMP snooping?

  • @johnpoz I knew you’d find a switch that does but wouldn’t class Cisco as being consumer grade kit. I don’t know the SG range myself but I’d imagine you don’t have anywhere near the filtering control you do on pfsense. Multicast on switches is great for LAN distribution of streaming media but I’ll be sticking to my Pfsense/PIMD setup for giving the control and filtering of multicast (and especially inter-VLAN).

    My unicast point was about the control connection for Sonos and the need for multicast in that. I’ve not taken the time to analyse how the Sonos is distributing its media streams. I wouldn’t assume multicast though, as whilst it’s the standard in this space, Sonos have some sort of proprietary “Sonosnet” which provides a mesh network for the speakers, appears to hub off one of the speakers which has been elected master (I do see a single unicast stream to the master) and apparently some proprietary solution to synchronise audio (sharing the same multicast stream doesn’t guarantee synchronisation).

  • @Deviant0ne I have a suggestion for you, can you add a rule on both interfaces that matches the multicast group you want, with “Allow IP options” and logging enabled. This rule alone may kick it in to life, assuming my theory on “allow IP options”, if not hopefully some logging insight.

  • LAYER 8 Global Moderator

    @PacketMan said in New package: pimd:

    but I’d imagine you don’t have anywhere near the filtering control you do on pfsense.

    Huh? Not using it as L3 firewall, talking about a multicast router function.. What filtering are you doing on pfsense for your multicast?

    As to homekit, they are small business line.. The other makers fully managed switches also support multicast routing and filtering.. They are priced where they could be used in home.. Atleast anyone in home serious about their networking ;)

    Again not saying this bad thing, anything that brings features to pfsense is good.. My concern, is misuse of it by users without any real understanding to what they are doing, to try and get something to work - that could have security and performance implications.. When done on the switch I can control exactly which ports are going to play in the multicast, along with filtering multicast groups. When done on the switching infrastructure pfsense doesn't have to even see the multicast traffic for it to be routed, etc.

    With the correct switch, I can keep a multicast noise maker from sending that multicast to the rest of the vlan.. Pfsense has no control over that. If I have the correct switch, really have no need for pimd on pfsense, where now users could misuse it, is the point trying to make..

  • Rebel Alliance Developer Netgate

    This seems to have strayed very far from the original intent of the thread. If you'd like to continue to discuss the merits of multicast routing in general, rather than issues directly related to the functionality of the package, start a new thread in an appropriate (non-packages) category.

    For those who have feedback about pimd, start a fresh thread for your individual issues. Please include details about your use case as well as current package settings. Ensure you are on pimd version 0.0.2.

    Locking this.

Log in to reply