IGMP Proxy stops working on PPPoE reset every day on embedded
-
Hmm. No, the igmpd did not start again :(
Jun 21 23:59:17 igmpproxy: Note: Removing MFC: 10.0.100.1 -> 239.255.255.250, InpVIf: 0 Jun 21 23:59:17 igmpproxy: Warn: MRT_DEL_MFC; Errno(49): Can't assign requested address Jun 21 23:59:17 igmpproxy: Note: Route is not active. No kernel updates done. Jun 22 00:00:16 igmpproxy: Note: New origin for route 239.255.255.250 is 10.0.100.1, flood -1 Jun 22 00:00:23 igmpproxy: Note: RECV Leave message from 172.16.100.254 to 224.0.0.2 (ip_hl 24, data 8) Jun 22 00:00:31 igmpproxy: Note: RECV V2 member report from 172.16.100.254 to 224.0.0.251 (ip_hl 24, data 8) Jun 22 00:00:31 igmpproxy: Note: The IGMP message was from myself. Ignoring. Jun 22 00:00:37 igmpproxy: Note: RECV V2 member report from 172.16.100.254 to 224.0.0.251 (ip_hl 24, data 8) Jun 22 00:00:37 igmpproxy: Note: The IGMP message was from myself. Ignoring. Jun 22 00:01:12 igmpproxy: ERRO: setsockopt IP_MULTICAST_IF x.x.x.x; Errno(49): Can't assign requested address -
Hey jimp. Any other idea what I might try? Or did I put the command in a wrong position?
-
That was probably in the wrong place. Since that is a PHP script, anything outside of ?> is just html, not a shell command.
So put it inside of ?> (up a few lines) and then run it via exec("<command></command>");
-
Ok jimp…
Now the files looks like this:
/* reload slbd */ /* if ($config['load_balancer']['lbpool']['type'] == "gateway") */ slbd_configure(); log_error("Configuring slbd"); return 0; # temp fix for igmpd restart exec("/usr/local/sbin/igmpproxy -c /tmp/igmpproxy.conf"); ?>Will tell you tomorrow if this worked…
Thanks again!
-
that looks better. If that doesn't help, you might also try to use mwexec_bg() instead of exec() so it would be launched in the background.
-
Okay, that didn't work either. Will try the mwexec_bg() version now…
-
Doesn't work either :-(
-
Any other hint, jimp?
-
What do the logs on a successful startup look like when compared to that failed startup?
-
Hi jimp,
this is the full output when the igmpd start correctly:
Jul 1 16:03:14 igmpproxy: Note: adding VIF, Ix 0 Fl 0x0 IP 0xfe64000a vr0, Threshold: 1, Ratelimit: 0 Jul 1 16:03:14 igmpproxy: Note: adding VIF, Ix 1 Fl 0x0 IP 0xfe02a8c0 vr1, Threshold: 1, Ratelimit: 0 Jul 1 16:03:14 igmpproxy: Note: adding VIF, Ix 2 Fl 0x0 IP 0xfe6410ac ath0, Threshold: 1, Ratelimit: 0 Jul 1 16:03:14 igmpproxy: Note: adding VIF, Ix 3 Fl 0x0 IP 0x61d7df4f ng0, Threshold: 1, Ratelimit: 0 Jul 1 16:03:14 igmpproxy: Note: joinMcGroup: 224.0.0.2 on vr1 Jul 1 16:03:14 igmpproxy: Note: joinMcGroup: 224.0.0.2 on ath0 Jul 1 16:03:14 igmpproxy: Note: joinMcGroup: 224.0.0.2 on ng0 Jul 1 16:03:14 igmpproxy: Note: RECV V2 member report from 172.16.100.254 to 224.0.0.2 (ip_hl 24, data 8) Jul 1 16:03:14 igmpproxy: Note: The IGMP message was from myself. Ignoring. Jul 1 16:03:14 igmpproxy: Note: RECV Membership query from 172.16.100.254 to 224.0.0.1 (ip_hl 20, data 8) Jul 1 16:03:18 igmpproxy: Note: RECV V2 member report from 172.16.100.254 to 224.0.0.251 (ip_hl 24, data 8) Jul 1 16:03:18 igmpproxy: Note: The IGMP message was from myself. Ignoring. -
So is there another solution? Otherwise I would stick with my cronjob. This is really frustrating, since it should be no big deal. Do you know who the package maintainer is so that we could ask him for comments?
-
Only other suggestion I can think of is that you might do a killall -9 igmpproxy, then sleep for 5-10 seconds, and then launch it again.
The last person to commit on the package was Ermal, but I'm not sure if he's actually the maintainer of the package or not. It hasn't had any commits in over a year.
-
Could I do this with the exec command in rc.newwanip again?
Like this?exec("killall -9 igmpproxy;sleep 10;/usr/local/sbin/igmpproxy -c /tmp/igmpproxy.conf"); -
I would put them each in separate exec() commands to be safer.
-
Okay. I'll try that…
-
Hmmm. It doesn't work that way. That beast doesn't get started! :(
-
Well, today it worked. But I had to put the exec statements before the 'return 0;' in that file. I'll check one more time and tell you if it still persists and all is well ;)
Thanks
-
Ok. This way it works. It needs to be above the last 'return 0;' statement…
-
So did it work with just the start above the return, or did it also require the kill?
-
I just tried it with the killall command. Will try tonight just with the start command…
