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 25.9k 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.
    • 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
                                          • R
                                            rudelerius
                                            last edited by

                                            I did delete the igmpstart.sh file, as I knew I did not want it started both ways.  I just went and confirmed it is not there any longer, just to be sure I hadn't forgotten to remount the file system as rw before I attempted to delete it or something.  It is definitely not there any longer (see attached screen capture).

                                            As far as updating the package, I only followed your lead with the pkg commands.  I didn't do anything else.  I'm not smart enough to make any other changes to the way it installed.  : )

                                            Regarding starting before the VLANs have been initialized, I don't think that is the case.  Watching the bootup process, I can see that it brings up the vlans, then the interfaces, then down the road is where it runs into the script being blocked, or whatever, after igmpproxy starts.  Below is the code from /etc/inc/services.inc.  These are the only changes that I have made to the system startup or the startup for igmpproxy.

                                            /* NOTE: -d4 means everything LOG_WARNING and smaller */
                                                    mwexec("/usr/local/sbin/igmpproxy -v {$g['tmp_path']}/igmpproxy.conf");
                                                    log_error(gettext("Started IGMP proxy service."));
                                            
                                            

                                            igmpstartsh.JPG
                                            igmpstartsh.JPG_thumb

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