Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IGMP Proxy is broken?

    Scheduled Pinned Locked Moved General pfSense Questions
    59 Posts 7 Posters 26.0k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • A
      Andrew453
      last edited by

      Hi.  Can you post your config file please?

      1 Reply Last reply Reply Quote 0
      • R
        rudelerius
        last edited by

        Here is my /tmp/igmpproxy.conf file:

        ##------------------------------------------------------
        ## Enable Quickleave mode (Sends Leave instantly)
        ##------------------------------------------------------
        quickleave
        phyint em0 upstream ratelimit 0 threshold 1
        altnet 224.0.0.0/4
        altnet 184.60.0.0/16
        altnet 184.61.0.0/16
        
        phyint em1_vlan10 downstream ratelimit 0 threshold 1
        altnet 10.10.0.0/24
        
        phyint lagg0_vlan80 disabled
        phyint lagg0_vlan10 disabled
        phyint em1_vlan12 disabled
        phyint em1_vlan80 disabled
        phyint bridge2 disabled
        
        

        Here are the ifconfig outputs for em0 and em1_vlan10:

        $ ifconfig em0
        em0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
        	options=5209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwfilter,vlan_hwtso>ether 00:01:xx:xx:xx:xx
        	inet6 fe80::201:69ff:fe01:24b9%em0 prefixlen 64 scopeid 0x1 
        	inet 192.168.0.16 netmask 0xffffff00 broadcast 192.168.0.255 
        	nd6 options=23 <performnud,accept_rtadv,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>)
        	status: active</full-duplex></performnud,accept_rtadv,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwfilter,vlan_hwtso></up,broadcast,running,promisc,simplex,multicast> 
        

        Yes, my WAN address is a private IP.  Until I can figure out this igmpproxy problem, my pfSense firewall is sitting behind my ISPs Actiontec modem/router.

        $ ifconfig em1_vlan10
        em1_vlan10: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
        	options=3 <rxcsum,txcsum>ether 00:01:xx:xx:xx:xx
        	inet6 fe80::201:69ff:fe01:24b8%em1_vlan10 prefixlen 64 scopeid 0xe 
        	inet 10.10.0.1 netmask 0xffffff00 broadcast 10.10.0.255 
        	nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>)
        	status: active
        	vlan: 10 vlanpcp: 0 parent interface: em1</full-duplex></performnud,auto_linklocal></rxcsum,txcsum></up,broadcast,running,promisc,simplex,multicast> 
        

        All looks fine to me.  I don't get it.

        1 Reply Last reply Reply Quote 0
        • A
          Andrew453
          last edited by

          I had a look at the source code for igmpproxy to see when it throws this error.  Basically, it iterates through the available interfaces and adds them in if (1) they have an IPv4 address and (2) they're not a loopback adapter.  Both your interfaces seem to have ipv4 and aren't loopback, so I imagine that for some reason it's not finding the interfaces in the first place.

          I wonder if it might have something to do with your vlans - they're not physical interfaces.

          Just for testing purposes, have you tried disabling your vlans, giving em1 the 10.8.0.x address range and trying again?  If it picks it up then, at least you know what the problem is.

          1 Reply Last reply Reply Quote 0
          • R
            rudelerius
            last edited by

            @Andrew453-
            I've been kicking around your comment about igmpproxy not finding my interface at all.  I think that, as you also noted, that the vlan may be the issue.  Here's why:

            After looking around the interwebs a bit, I think I may have stumbled onto a possible cause/solution at this link: http://wiki.ipfire.org/en/addons/igmpproxy/start.

            Specifically, the notation of the interface name in the config file posted there:

            phyint red0.8

            It makes me wonder if the use of the alias "em1_vlan10" may be the cause of the problem.  I speculate that if I change the interface name in the config file to em1.10, it might work.  I've no real idea if that's the cause, but it can't hurt to try it!

            I'll post results here once I've had a chance to give it a go.

            1 Reply Last reply Reply Quote 0
            • R
              rudelerius
              last edited by

              Well- tried using the following config with no luck:

              ##------------------------------------------------------
              ## Enable Quickleave mode (Sends Leave instantly)
              ##------------------------------------------------------
              quickleave
              phyint em0 upstream ratelimit 0 threshold 1
              altnet 224.0.0.0/4
              altnet 184.60.0.0/16
              altnet 184.61.0.0/16
              
              phyint em1.10 downstream ratelimit 0 threshold 1
              altnet 10.10.0.0/24
              
              phyint lagg0.80 disabled
              phyint lagg0.10 disabled
              phyint em1.12 disabled
              phyint em1.80 disabled
              phyint br2 disabled
              

              According to the logs (see attached), it keeps failing on the upstream (em0) interface; it doesn't even appear to make it to the downstream interface.  But, I see absolutely no reason why that should be the case- I'm not using any VLAN on the WAN interface. I don't get it.

              log.PNG
              log.PNG_thumb

              1 Reply Last reply Reply Quote 0
              • R
                rudelerius
                last edited by

                I really suspect that this line in the source code for igmpproxy is causing the failure to find the downstream interface:

                if(strlen(token) >= IF_NAMESIZE) return NULL;
                

                I think the IF name: "em1_vlan1" may be longer than the value held in that constant.

                Unfortunately, after looking in all of the files included in the tar file for igmpproxy, I could not find where that constant was defined and what the maximum number of characters is for the if name.

                Perhaps someone more saavy could find it for me?

                Jon.

                EDIT: this link indicates it is defined in system file sys/net/if.h.  Not clear to me if the max size is 16 bits. 
                http://fxr.watson.org/fxr/ident?v=FREEBSD51;im=bigexcerpts;i=IF_NAMESIZE
                Seems too small.

                1 Reply Last reply Reply Quote 0
                • A
                  Andrew453
                  last edited by

                  It's 16 characters, rather than bits.

                  I think that part of the code is actually reading the interface config from your file - so it's sanity checking what's in the config file rather than what the hardware is reporting exists.  There's a separate bit of the code that actually loads in the physical interfaces, and then attempts to match the two.

                  If you look in your logs at start up you should see it initialise the interfaces, e.g.:

                  Aug 1 09:43:54 igmpproxy[23972]: adding VIF, Ix 2 Fl 0x0 IP 0x[  ] ath0_wlan0, Threshold: 1, Ratelimit: 0
                  Aug 1 09:43:54 igmpproxy[23972]: adding VIF, Ix 1 Fl 0x0 IP 0x[  ] re1, Threshold: 1, Ratelimit: 0
                  Aug 1 09:43:54 igmpproxy[23972]: adding VIF, Ix 0 Fl 0x0 IP 0x[  ] re0, Threshold: 1, Ratelimit: 0

                  I suspect you'll find your Vlan is missing.

                  Perhaps try to rename it to shorten it and remove any out of the ordinary characters etc (no underscores, spaces, dots etc).  I suspect that's probably not the issue though.  You're not the first person to have trouble getting igmpproxy to work with vlans:  http://community.ubnt.com/t5/EdgeMAX/How-do-I-add-vlan-to-igmp-proxy/td-p/1099265

                  I saw a reference elsewhere to giving your vlans different mac addresses, in an attempt to get igmpproxy to pick them up.

                  1 Reply Last reply Reply Quote 0
                  • A
                    Andrew453
                    last edited by

                    Hi rudelerius.  I've had a bit more of a look at this - I was wondering whether igmproxy supports vlans or not, so I tried it on my set up.

                    I can confirm it does support vlans so it should see them.  e.g. below is my log when I had a vlan running:

                    Aug 1 16:39:17 igmpproxy[18165]: adding VIF, Ix 3 Fl 0x0 IP 0x[  ] re1_vlan12, Threshold: 1, Ratelimit: 0
                    Aug 1 16:39:17 igmpproxy[18165]: adding VIF, Ix 2 Fl 0x0 IP 0x[  ] ath0_wlan0, Threshold: 1, Ratelimit: 0
                    Aug 1 16:39:17 igmpproxy[18165]: adding VIF, Ix 1 Fl 0x0 IP 0x[  ] re1, Threshold: 1, Ratelimit: 0
                    Aug 1 16:39:17 igmpproxy[18165]: adding VIF, Ix 0 Fl 0x0 IP 0x[  ] re0, Threshold: 1, Ratelimit: 0

                    Are you sure you've got your vlans set up right?

                    You need to define the vlan in Interfaces > (assign) > VLANs.

                    Then you need to add it to the interfaces list and enable it.  pfSense will give it another interface name, e.g. OPT2

                    Once you've got that, give it an IP etc.

                    Then, in Services > IGMP proxy, define your upstream and downstream interfaces and select the vlan interface as appropriate e.g. OPT2

                    When the igmpproxy service restarts, all should be well.  There's no need to edit the igmpproxy.conf file directly (services.inc overwrites it anyway), nor start/stop the service from the command line if you've followed my updated instructions to patch services.inc

                    Hope this helps!

                    1 Reply Last reply Reply Quote 0
                    • R
                      rudelerius
                      last edited by

                      Are you sure you've got your vlans set up right?

                      You need to define the vlan in Interfaces > (assign) > VLANs.

                      Then you need to add it to the interfaces list and enable it.  pfSense will give it another interface name, e.g. OPT2

                      Once you've got that, give it an IP etc.

                      Then, in Services > IGMP proxy, define your upstream and downstream interfaces and select the vlan interface as appropriate e.g. OPT2

                      When the igmpproxy service restarts, all should be well.  There's no need to edit the igmpproxy.conf file directly (services.inc overwrites it anyway), nor start/stop the service from the command line if you've followed my updated instructions to patch services.inc

                      Hope this helps!

                      Thanks for trying to help Andrew453.  Unfortunately, nothing works.

                      I have double checked all of my configuration of the vlan, interfaces, igmpproxy, etc. and I cannot find anything that isn't set up correctly.  I have followed all of your instructions to the letter. Whenever I restart pfSense (or try to start igmpproxy manually), I see the following in the logs:

                      Aug 6 09:24:00 php-fpm[7798]: /rc.newwanip: The command '/usr/local/sbin/igmpproxy -v -v /tmp/igmpproxy.conf' returned exit code '255', the output was ''
                      Aug 6 09:24:00 igmpproxy[47493]: There must be at least 2 Vif's where one is upstream.
                      Aug 6 09:24:00 igmpproxy[47493]: adding VIF, Ix 0 Fl 0x0 IP 0x1000a8c0 em0, Threshold: 1, Ratelimit: 0

                      em0 is my WAN interface.  The next line in my config should configure my LAN interface (em1_vlan10) as the upstream interface, but it fails as noted above.  I have no idea why and it just doesn't make any sense.

                      Name Type Values Description
                      WAN  upstream      224.0.0.0/4, 184.60.0.0/16, 184.61.0.0/16  TDS TV UPSTREAM IGMP PROXY 
                      LAN  downstream  10.10.0.0/24 TDS TV DOWNSTREAM IGMP PROXY

                      I'm at a complete loss of what to do to fix this problem.

                      1 Reply Last reply Reply Quote 0
                      • A
                        Andrew453
                        last edited by

                        Can you post your Interfaces > (assign) screen, and your Interfaces > VLANs screen please?

                        1 Reply Last reply Reply Quote 0
                        • R
                          rudelerius
                          last edited by

                          Hopefully your eyes can see something wrong that mine can't.  It all looks correct to me. Images are attached, as I don't know how to post in-line.

                          Interfaces_vlans.JPG_thumb
                          Interfaces_vlans.JPG
                          Interfaces_Assign.JPG_thumb
                          Interfaces_Assign.JPG

                          1 Reply Last reply Reply Quote 0
                          • A
                            Andrew453
                            last edited by

                            Thanks. When I had multicast VLANs working on my setup and recognised by igmpproxy, I also had an interface assigned in pfSense to the underlying physical port (em1 in your case).  Have you tried that? It shouldn't matter, but if igmpproxy is being fussy it might help to ensure the underlying interface on which the VLANs depend is up and running.

                            There's usually a certain amount of trial and error in diagnosing the issue and getting these things to work.  The trick is to keep on trying different tweaks to your setup until you get a response from igmpproxy and then work backwards from that.

                            1 Reply Last reply Reply Quote 0
                            • Y
                              YoMarK
                              last edited by

                              Luckily i found this thread, was trying for hours and hours yesterday to get IGMP proxy working, but it just would not work.
                              So I upgraded it to the latest version using pkg and made the change to the pfsense config file (tnx Andrew453).

                              After that, it started working immediately.
                              FYI: I'm using it on a dutch fibre connection where they have a separate iptv network(so WAN/IPTV is a different cable).

                              This is a mayor bug, and the fix seems quite simple.

                              1 Reply Last reply Reply Quote 0
                              • D
                                doktornotor Banned
                                last edited by

                                Bumped the bug… the outdated junk gets really annoying. https://redmine.pfsense.org/issues/4672#note-6

                                1 Reply Last reply Reply Quote 0
                                • R
                                  rudelerius
                                  last edited by

                                  Hi all,

                                  It shouldn't matter, but if igmpproxy is being fussy it might help to ensure the underlying interface on which the VLANs depend is up and running.

                                  In spite of the fact that I agree with Andrew453 that it doesn't seem necessary that the em1 network port should need to be assigned to an interface in pfSense, since the proxy is not using that interface as either upstream or downstream, but rather the vlan interface that rides on top of it, it does appear that this has resolved my problem with igmpproxy actually starting.

                                  Although, I'm still leery that it will work correctly though.  In my case, when the proxy is started, the log shows that the em1 interface is brought up, not the em1_vlan interface (see attached image).  I'm not able to test it at the moment, as I already have an igmp proxy running on the ISP's router/gateway device, and I don't want to cause any issues with the IPTV that would result in the kids and (especially) the wife to go ballistic on me for ruining their brain-melting veg-out time on a Saturday afternoon.

                                  syslog_igmpproxy.JPG
                                  syslog_igmpproxy.JPG_thumb

                                  1 Reply Last reply Reply Quote 0
                                  • A
                                    Andrew453
                                    last edited by

                                    I doubt it's working I'm afraid - I'd hoped assigning em1 might also have brought up the VLAN but it hasn't.  The VLAN still isn't recognised so the multicast traffic won't route properly.  Running out of ideas I'm afraid. For some reason it just doesn't like your VLAN. I assume your NICs support VLAN  tagging and the VLAN is enabled in pfSense?

                                    One possible workaround: I assume you're using VLANs to segregate traffic on your local network for security or other reasons.  I can see you've set a number of them up, for which the IPTV network is one.  One option would be to run the IPTV on the native em1 (i.e. not a VLAN), which is recognised by igmpproxy.  As long as everything else is on VLANs, the traffic should still be segregated.  Would that work?

                                    .

                                    1 Reply Last reply Reply Quote 0
                                    • R
                                      rudelerius
                                      last edited by

                                      Just to see if it helped, I rebooted the firewall.  I thought maybe it would help igmpproxy find the vlan interface, and unfortunately, it doesn't.

                                      But, I can see membership queries in the logs from both networks: the ISP residential gateway at 192.168.0.1, and also from pfSense and my Dell switches on the pfSense vlan: 10.10.0.2 and 10.10.0.3.

                                      I really have no idea what the heck is going on!  The em nics are vlan capable (refer to previous posts with ifconfig details).  Also, the vlans are all properly set up in pfSense and assigned to interfaces (see previous attachments).

                                      Maybe it's hardware related?  This is a pretty old box- a repurposed MSA 4000 that I found on eBay.  For instance, after rebooting this most recent time to see if it helped igmpproxy, the vga output on the box sort of stopped working.  That is, it shows the boot sequence, right up until the line "Generating RRD Graphs…..Done" and then it stops all output.  Hitting enter does nothing (where in the past it used to bring up the pfSense menu). I can still access the box by SSH and get to the menu, but it just no longer works on the vga output.  When I toggle the kvm switch, it ouputs the log info for the hardware changes, as it always has, but never reverts to the menu.

                                      Obviously, this is another issue, but it only appeared on this box after finally getting igmpproxy to run and then rebooting the system.  Who knows.  Sometimes, I wish stuff would just work!  : (

                                      1 Reply Last reply Reply Quote 0
                                      • R
                                        rudelerius
                                        last edited by

                                        Ok.  HOLY CRAP!

                                        This makes no sense, but, feeling dejected after my last post, I decided to throw in the towel.

                                        I stopped the igmpproxy service.  And as soon as I did, the box sounded the "chime," completed the boot sequence, and the remaining output appeared on the screen and returned to the menu.

                                        It also wrote the last of the boot logs, which were filled with errors related to LCDproc (which I forgot I added back to this system to tinker with this morning).  I've removed that package completely from the system again.

                                        I'm going to restart one more time and see if that resolved the boot problems.  Unfortunately, I don't think it has anything to do with the igmpproxy interface issue, but what the hell!  I might as well just try one more time.

                                        1 Reply Last reply Reply Quote 0
                                        • R
                                          rudelerius
                                          last edited by

                                          Alright, this stinks.  Whenever my system starts, the boot sequence gets stuck until I stop the igmpproxy service.  I removed the LCDproc package, so it definitely has nothing to do with that.

                                          Maybe the logs will help

                                          Aug 8 15:51:04 sshlockout[62465]: sshlockout/webConfigurator v3.0 starting up
                                          Aug 8 15:51:04 login: login on ttyv0 as root
                                          Aug 8 15:51:02 php-fpm[53527]: /rc.start_packages: Restarting/Starting all packages.
                                          Aug 8 15:50:53 syslogd: kernel boot file is /boot/kernel/kernel
                                          Aug 8 15:50:53 syslogd: exiting on signal 15
                                          Aug 8 15:50:53 php: rc.bootup: Started IGMP proxy service.
                                          Aug 8 15:50:53 igmpproxy[64540]: All routes removed. Routing table is empty.
                                          Aug 8 15:50:53 igmpproxy[64540]: Got a interupt signal. Exiting.
                                          Aug 8 15:50:53 igmpproxy[64540]: select() failure; Errno(4): Interrupted system call
                                          Aug 8 15:50:36 igmpproxy[64540]: RECV Membership query from 10.10.0.2 to 224.0.0.1
                                          Aug 8 15:49:42 igmpproxy[64540]: RECV Membership query from 192.168.0.1 to 224.0.0.1
                                          Aug 8 15:49:42 igmpproxy[64540]: RECV Membership query from 192.168.0.1 to 224.0.0.1
                                          Aug 8 15:49:07 igmpproxy[64540]: RECV Membership query from 10.10.0.3 to 224.0.0.1
                                          Aug 8 15:49:07 igmpproxy[64540]: RECV Membership query from 10.10.0.3 to 224.0.0.1
                                          Aug 8 15:48:45 igmpproxy[64540]: RECV Membership query from 10.10.0.2 to 224.0.0.1
                                          Aug 8 15:48:45 igmpproxy[64540]: RECV Membership query from 10.10.0.2 to 224.0.0.1
                                          Aug 8 15:48:45 igmpproxy[64540]: RECV Membership query from 10.10.0.2 to 224.0.0.1
                                          Aug 8 15:48:45 igmpproxy[64540]: RECV Membership query from 10.10.0.2 to 224.0.0.1
                                          Aug 8 15:48:27 igmpproxy[64540]: RECV Membership query from 10.10.0.2 to 224.0.0.1
                                          Aug 8 15:48:10 php-fpm[3901]: /index.php: Successful login for user 'admin' from: 10.10.0.36
                                          Aug 8 15:48:10 php-fpm[3901]: /index.php: Successful login for user 'admin' from: 10.10.0.36
                                          Aug 8 15:47:37 igmpproxy[64540]: RECV Membership query from 192.168.0.1 to 224.0.0.1
                                          Aug 8 15:47:37 igmpproxy[64540]: RECV Membership query from 192.168.0.1 to 224.0.0.1
                                          Aug 8 15:46:57 igmpproxy[64540]: RECV Membership query from 10.10.0.3 to 224.0.0.1
                                          Aug 8 15:46:57 igmpproxy[64540]: RECV Membership query from 10.10.0.3 to 224.0.0.1
                                          Aug 8 15:46:36 igmpproxy[64540]: RECV Membership query from 10.10.0.2 to 224.0.0.1
                                          Aug 8 15:46:36 igmpproxy[64540]: RECV Membership query from 10.10.0.2 to 224.0.0.1
                                          Aug 8 15:46:36 igmpproxy[64540]: RECV Membership query from 10.10.0.2 to 224.0.0.1
                                          Aug 8 15:46:36 igmpproxy[64540]: RECV Membership query from 10.10.0.2 to 224.0.0.1
                                          Aug 8 15:46:23 php-fpm[55941]: /rc.dyndns.update: phpDynDNS (xxxxx): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
                                          Aug 8 15:46:18 igmpproxy[64540]: RECV Membership query from 10.10.0.2 to 224.0.0.1
                                          Aug 8 15:46:14 php-fpm[55941]: /rc.dyndns.update: phpDynDNS (xxxxx): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
                                          Aug 8 15:46:10 php-fpm[45394]: /rc.dyndns.update: phpDynDNS (xxxxx): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
                                          Aug 8 15:46:01 php-fpm[45394]: /rc.dyndns.update: DynDNS (xxxxx) There was an error trying to determine the public IP for interface - wan(em0). Probably interface is not a WAN interface.
                                          Aug 8 15:46:01 php-fpm[45394]: /rc.dyndns.update: DynDns (xxxxx): IP address could not be extracted from checkip.dyndns.org
                                          Aug 8 15:45:55 kernel: pid 3672 (ntpd), uid 0: exited on signal 11 (core dumped)
                                          Aug 8 15:45:46 php-fpm[7815]: /rc.dyndns.update: phpDynDNS (xxxxx): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
                                          Aug 8 15:45:41 check_reload_status: Reloading filter
                                          Aug 8 15:45:41 check_reload_status: Restarting OpenVPN tunnels/interfaces
                                          Aug 8 15:45:41 check_reload_status: Restarting ipsec tunnels
                                          Aug 8 15:45:41 check_reload_status: updating dyndns WAN_DHCP
                                          Aug 8 15:45:39 php-fpm[55941]: /rc.newwanip: rc.newwanip: Info: starting on em0.
                                          Aug 8 15:45:38 check_reload_status: rc.newwanip starting em0
                                          Aug 8 15:45:32 igmpproxy[64540]: RECV Membership query from 192.168.0.1 to 224.0.0.1
                                          Aug 8 15:45:32 igmpproxy[64540]: RECV Membership query from 192.168.0.1 to 224.0.0.1
                                          Aug 8 15:45:31 php-fpm[7815]: /rc.dyndns.update: DynDNS (xxxxx) There was an error trying to determine the public IP for interface - wan(em0). Probably interface is not a WAN interface.
                                          Aug 8 15:45:31 php-fpm[7815]: /rc.dyndns.update: Dyndns debug information (xxxxx): Could not resolve checkip.dyndns.org to IP using interface IP 192.168.0.16.
                                          Aug 8 15:45:21 igmpproxy[64540]: adding VIF, Ix 1 Fl 0x0 IP 0x0102a8c0 em1, Threshold: 1, Ratelimit: 0
                                          Aug 8 15:45:21 igmpproxy[64540]: adding VIF, Ix 0 Fl 0x0 IP 0x1000a8c0 em0, Threshold: 1, Ratelimit: 0

                                          1 Reply Last reply Reply Quote 0
                                          • A
                                            Andrew453
                                            last edited by

                                            Looking at the logs, it looks like igmpproxy is being started other than by the bootup script and is then blocking the bootup script. If it's blocking the bootup script, this suggests it's starting in the foreground rather than being started by the daemon.  If imgpproxy is starting in the foreground, the bootup script won't resume until igmpproxy exits.  When it does exit (e.g. because you terminate the service) the bootup script resumes and logs the "Started IGMP proxy service".  This seems to be consistent with what you're seeing.

                                            Have you got igmpstart.sh as well as having patched services.inc, as you don't need both?  If you've patched services.inc (which is the better way to do it) you can delete igmpstart.sh.  Alternatively, when upgrading igmpproxy have you somehow put the executable itself (or some other script) in a path that gets launched during boot (I can see from an earlier post that you're running NanoBSD).

                                            If igmpproxy is starting too early somehow, it might also be starting before your VLANs have been initialised, which might explain your other issues?

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.