IGMP Proxy is broken?

rudelerius

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.

Andrew453

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.

rudelerius

@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.

rudelerius

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_thumb

rudelerius

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.

Andrew453

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.

Andrew453

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!

rudelerius

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.

Andrew453

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

rudelerius

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_Assign.JPG_thumb

Andrew453

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.

YoMarK

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.

doktornotor

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

rudelerius

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_thumb

Andrew453

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?

.

rudelerius

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! : (

rudelerius

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.

rudelerius

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

Andrew453

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?

rudelerius

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_thumb