IGMP Proxy stops working on PPPoE reset every day on embedded
-
What is your uplink interface? ng0?
-
Nope. ng0 is the interface which does the PPPoE connection. I only use the IGMP proxy between my LAN (vr0) and my WLAN/OPT interface (ath0)…
-
Doesn't ath0 go to down state at that time for some reason?
-
I don't know. I just know that the PPPoE reset is at that time. I don't know why the wireless interface should go down here…
-
setsockopt will fail if interface implicitly used in this function is down. (I am 99% sure)
-
Okay. So what could I do?
-
Monitor closely your uplink interface around this time.
-
But my uplink interface is vr0 (LAN) with a cable in it. And I'm usually not up that late ;)
-
How could I start the proxy via ssh or console? Then I could simply put in a cronjob to start the proxy at 0:10 every day…
-
Okay. I put in a cronjob now for staring the igmp proxy and now the server didn't die! When the cronjob should start the proxy there was a message in the log saying that the address is already in use, so it was running. I am deleting the cron entry again and see if it works now. Probably the box just needed a reboot…
-
No. Did not work. Again the proxy dies on PPPoE reconnect. So I'll put in the cronjob again…
-
It might be a problem with the package's sync routine not restarting the program properly.
Try adding the code to restart it to /etc/rc.newwanip instead of a cron job.
It would be good to know if you can replicate this on pfSense 2.0.
-
Okay. Will do this tonight. Can't test it on 2.0, got rid of it. Need a stable device right now. Will tell you tomorrow if it worked…
Can I simply edit the file via ssh? But this won't be in any backup then, right?
-
You could edit it via ssh, but making a backup is a good idea.
You'll just need to remember to use /etc/rc.conf_mount_rw before editing and /etc/rc.conf_mount_ro afterward.
-
Ok. What I meant is that these changes to a file won't be in any backup so I have to do the changes on every update…
-
Yes, that is correct, but this would only be a temporary test.
If that does fix it, then the package's sync routine is wrong (it should be sync'd on every run of /etc/rc.newwanip when a new WAN IP is found). If the package can be fixed, that will be the permanent resolution.
-
Ok. Entered it at the end of the config file:
/* reload slbd */ /* if ($config['load_balancer']['lbpool']['type'] == "gateway") */ slbd_configure(); log_error("Configuring slbd"); return 0; ?> # temp fix for igmpd restart /usr/local/sbin/igmpproxy -c /tmp/igmpproxy.conf -
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>");
