PPPoE reconenction fix - mpd fix ($100)
-
Try putting a sleep(5) after the killbypid call.
-
@ermal:
Try putting a sleep(5) after the killbypid call.
ill try that but i think the if statement doesnt come out true so probably its not killing mpd because the logs appear same before and after the patch plus even with modem up after some while and i try cable unplug and replug it still wont work
-
i tried sleep as well as that if statement i put in some logging and it seems that if statement never turns out to be true so the kill command isnt executed
-
i tried sleep as well as that if statement i put in some logging and it seems that if statement never turns out to be true so the kill command isnt exucuted
Did you try leaving out the PID check and running sigkillbyname() or killbyname() instead? (Don't think checking PIDs is the best idea around in similar messy state.)
-
i tried sleep as well as that if statement i put in some logging and it seems that if statement never turns out to be true so the kill command isnt exucuted
Did you try leaving out the PID check and running sigkillbyname() or killbyname() instead? (Don't think checking PIDs is the best idea around in similar messy state.)
can u provide a replacement line for the below as im not aware of the possible functions created
killbypid("{$g['varrun_path']}/" . escapeshellarg($ppp['type']) . "_{$interface}.pid");
-
You can try
killbyname("mpd5");
or
sigkillbyname("mpd5", "TERM");
or
sigkillbyname("mpd5", "KILL");
-
tried all 3 but once modem is rebooted and up and running, nothing helps, tried unplugging wan cable also with each of the commands but all still same, only get it to work is reboot pfsense
there is something that happens at reboot which makes it reconnect that doesnt happen when modem goes down and comes up again, probably the nic powering down and up makes it successfully connect at pfsense reboot. it would be great to disable the nic using software and then enabling it
-
So… is that command executed at all? (You mentioned you tried logging.)
-
i removed the logging and put in the command, im assuming its running it because i see the interface going down and up a multiple times now, no idea if thats supposed to happen
-
Well, so… put the logging back? :) (That, and adding the sleep in between...)
-
tried it and that command is executed but it seems somewhere else something is creating another mpd instance or something like that, also in system log i get messages like some package is already running so not starting another instance so i believe that command is doing few other bad things than actually doing good because the situation still is same, it wont reconnect
-
it seems somewhere else something is creating another mpd instance or something like that
Perhaps we are finally getting somewhere here. Posting the real logs could help.
-
the part about some other mpd starting is actually the netgraph thing which has multiple instances, ill try some more and get the logs shortly as this is a production box so need to get some work done for now
-
here u go
system log
Jan 17 14:38:16 syslogd: kernel boot file is /boot/kernel/kernel Jan 17 14:38:42 kernel: vr1: link state changed to DOWN Jan 17 14:39:29 check_reload_status: updating dyndns WAN Jan 17 14:39:29 check_reload_status: Restarting ipsec tunnels Jan 17 14:39:29 check_reload_status: Restarting OpenVPN tunnels/interfaces Jan 17 14:39:29 check_reload_status: Reloading filter Jan 17 14:39:33 php-fpm[77652]: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use WAN. Jan 17 14:39:33 php-fpm[77652]: /rc.openvpn: OpenVPN: Resync client1 ExpressVPN Jan 17 14:39:33 php-fpm[74920]: /rc.dyndns.update: phpDynDNS (firewall.domain.com): No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry. Jan 17 14:39:33 check_reload_status: Reloading filter Jan 17 14:39:33 kernel: ovpnc1: link state changed to DOWN Jan 17 14:39:49 php: rc.kill_states: rc.kill_states: Removing states for IP 86.99.127.163/32 Jan 17 14:39:49 check_reload_status: Rewriting resolv.conf Jan 17 14:39:51 php-fpm[74920]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Jan 17 14:39:51 php-fpm[74920]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Jan 17 14:39:51 php-fpm[74920]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Jan 17 14:39:51 php-fpm[74920]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Jan 17 14:39:51 php-fpm[74920]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Jan 17 14:39:51 php-fpm[74920]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Jan 17 14:39:51 php-fpm[74920]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Jan 17 14:39:51 php-fpm[74920]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Jan 17 14:39:51 php-fpm[74920]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Jan 17 14:39:51 php-fpm[74920]: /rc.filter_configure_sync: Could not find IPv4 gateway for interface (wan). Jan 17 14:39:57 check_reload_status: Linkup starting vr1 Jan 17 14:39:57 kernel: vr1: link state changed to UP Jan 17 14:39:59 php-fpm[77522]: /rc.linkup: REACHED HERE BEFORE KILL COMMAND AND SLEEP Jan 17 14:40:04 php-fpm[77522]: /rc.linkup: REACHED HERE AFTER KILL COMMAND AND SLEEP Jan 17 14:40:14 check_reload_status: Restarting ipsec tunnels Jan 17 14:40:19 check_reload_status: updating dyndns wan
ppp log
Jan 17 14:39:18 ppp: [wan_link0] LCP: no reply to 2 echo request(s) Jan 17 14:39:28 ppp: [wan_link0] LCP: no reply to 3 echo request(s) Jan 17 14:39:38 ppp: [wan_link0] LCP: no reply to 4 echo request(s) Jan 17 14:39:48 ppp: [wan_link0] LCP: no reply to 5 echo request(s) Jan 17 14:39:48 ppp: [wan_link0] LCP: peer not responding to echo requests Jan 17 14:39:48 ppp: [wan_link0] LCP: state change Opened --> Stopping Jan 17 14:39:48 ppp: [wan_link0] Link: Leave bundle "wan" Jan 17 14:39:48 ppp: [wan] Bundle: Status update: up 0 links, total bandwidth 9600 bps Jan 17 14:39:48 ppp: [wan] IPCP: Close event Jan 17 14:39:48 ppp: [wan] IPCP: state change Opened --> Closing Jan 17 14:39:48 ppp: [wan] IPCP: SendTerminateReq #4 Jan 17 14:39:48 ppp: [wan] IPCP: LayerDown Jan 17 14:39:49 ppp: [wan] IFACE: Delete route 0.0.0.0/0 2.48.4.1 failed: No such process Jan 17 14:39:49 ppp: [wan] IFACE: Down event Jan 17 14:39:49 ppp: [wan] IFACE: Rename interface pppoe0 to pppoe0 Jan 17 14:39:49 ppp: [wan] IPV6CP: Close event Jan 17 14:39:49 ppp: [wan] IPV6CP: state change Stopped --> Closed Jan 17 14:39:49 ppp: [wan] IPCP: Down event Jan 17 14:39:49 ppp: [wan] IPCP: LayerFinish Jan 17 14:39:49 ppp: [wan] Bundle: No NCPs left. Closing links... Jan 17 14:39:49 ppp: [wan] IPCP: state change Closing --> Initial Jan 17 14:39:49 ppp: [wan] IPV6CP: Down event Jan 17 14:39:49 ppp: [wan] IPV6CP: state change Closed --> Initial Jan 17 14:39:49 ppp: [wan_link0] LCP: SendTerminateReq #3 Jan 17 14:39:49 ppp: [wan_link0] LCP: LayerDown Jan 17 14:39:52 ppp: [wan_link0] LCP: SendTerminateReq #4 Jan 17 14:39:54 ppp: [wan_link0] LCP: state change Stopping --> Stopped Jan 17 14:39:54 ppp: [wan_link0] LCP: LayerFinish Jan 17 14:39:54 ppp: [wan_link0] PPPoE: connection closed Jan 17 14:39:54 ppp: [wan_link0] Link: DOWN event Jan 17 14:39:54 ppp: [wan_link0] LCP: Down event Jan 17 14:39:54 ppp: [wan_link0] LCP: state change Stopped --> Starting Jan 17 14:39:54 ppp: [wan_link0] LCP: LayerStart Jan 17 14:39:54 ppp: [wan_link0] Link: reconnection attempt 1 in 3 seconds Jan 17 14:39:57 ppp: [wan_link0] Link: reconnection attempt 1 Jan 17 14:39:57 ppp: [wan_link0] PPPoE: Connecting to '' Jan 17 14:40:04 ppp: Multi-link PPP daemon for FreeBSD Jan 17 14:40:04 ppp: Jan 17 14:40:04 ppp: process 91898 started, version 5.7 (root@pfsense-22-i386-builder 13:22 18-Nov-2014) Jan 17 14:40:04 ppp: web: web is not running Jan 17 14:40:04 ppp: [wan] Bundle: Interface ng1 created Jan 17 14:40:04 ppp: [wan] IFACE: ioctl(ng1, SIOCSIFNAME): File exists Jan 17 14:40:04 ppp: mpd_wan.conf:11: Error in 'set iface name pppoe0' Jan 17 14:40:04 ppp: [wan_link0] Link: OPEN event Jan 17 14:40:04 ppp: [wan_link0] LCP: Open event Jan 17 14:40:04 ppp: [wan_link0] LCP: state change Initial --> Starting Jan 17 14:40:04 ppp: [wan_link0] LCP: LayerStart Jan 17 14:40:04 ppp: [wan_link0] PPPoE: Connecting to '' Jan 17 14:40:13 ppp: [wan_link0] PPPoE connection timeout after 9 seconds Jan 17 14:40:13 ppp: [wan_link0] Link: DOWN event Jan 17 14:40:13 ppp: [wan_link0] LCP: Down event Jan 17 14:40:13 ppp: [wan_link0] Link: reconnection attempt 1 in 4 seconds Jan 17 14:40:17 ppp: [wan_link0] Link: reconnection attempt 1 Jan 17 14:40:17 ppp: [wan_link0] PPPoE: Connecting to '' Jan 17 14:40:26 ppp: [wan_link0] PPPoE connection timeout after 9 seconds Jan 17 14:40:26 ppp: [wan_link0] Link: DOWN event Jan 17 14:40:26 ppp: [wan_link0] LCP: Down event Jan 17 14:40:26 ppp: [wan_link0] Link: reconnection attempt 2 in 2 seconds Jan 17 14:40:28 ppp: [wan_link0] Link: reconnection attempt 2 Jan 17 14:40:28 ppp: [wan_link0] PPPoE: Connecting to '' Jan 17 14:40:37 ppp: [wan_link0] PPPoE connection timeout after 9 seconds Jan 17 14:40:37 ppp: [wan_link0] Link: DOWN event Jan 17 14:40:37 ppp: [wan_link0] LCP: Down event Jan 17 14:40:37 ppp: [wan_link0] Link: reconnection attempt 3 in 2 seconds Jan 17 14:40:39 ppp: [wan_link0] Link: reconnection attempt 3 Jan 17 14:40:39 ppp: [wan_link0] PPPoE: Connecting to '' Jan 17 14:40:48 ppp: [wan_link0] PPPoE connection timeout after 9 seconds Jan 17 14:40:48 ppp: [wan_link0] Link: DOWN event Jan 17 14:40:48 ppp: [wan_link0] LCP: Down event Jan 17 14:40:48 ppp: [wan_link0] Link: reconnection attempt 4 in 3 seconds Jan 17 14:40:51 ppp: [wan_link0] Link: reconnection attempt 4 Jan 17 14:40:51 ppp: [wan_link0] PPPoE: Connecting to '' Jan 17 14:41:00 ppp: [wan_link0] PPPoE connection timeout after 9 seconds Jan 17 14:41:00 ppp: [wan_link0] Link: DOWN event Jan 17 14:41:00 ppp: [wan_link0] LCP: Down event Jan 17 14:41:00 ppp: [wan_link0] Link: reconnection attempt 5 in 1 seconds Jan 17 14:41:01 ppp: [wan_link0] Link: reconnection attempt 5 Jan 17 14:41:01 ppp: [wan_link0] PPPoE: Connecting to '' Jan 17 14:41:10 ppp: [wan_link0] PPPoE connection timeout after 9 seconds Jan 17 14:41:10 ppp: [wan_link0] Link: DOWN event Jan 17 14:41:10 ppp: [wan_link0] LCP: Down event Jan 17 14:41:10 ppp: [wan_link0] Link: reconnection attempt 6 in 1 seconds Jan 17 14:41:11 ppp: [wan_link0] Link: reconnection attempt 6 Jan 17 14:41:11 ppp: [wan_link0] PPPoE: Connecting to '' Jan 17 14:41:20 ppp: [wan_link0] PPPoE connection timeout after 9 seconds Jan 17 14:41:20 ppp: [wan_link0] Link: DOWN event Jan 17 14:41:20 ppp: [wan_link0] LCP: Down event Jan 17 14:41:20 ppp: [wan_link0] Link: reconnection attempt 7 in 3 seconds Jan 17 14:41:23 ppp: [wan_link0] Link: reconnection attempt 7 Jan 17 14:41:23 ppp: [wan_link0] PPPoE: Connecting to '' Jan 17 14:41:32 ppp: [wan_link0] PPPoE connection timeout after 9 seconds Jan 17 14:41:32 ppp: [wan_link0] Link: DOWN event Jan 17 14:41:32 ppp: [wan_link0] LCP: Down event Jan 17 14:41:32 ppp: [wan_link0] Link: reconnection attempt 8 in 4 seconds
the part about netgraph in ppp log
Jan 17 14:40:04 ppp: [wan] IFACE: ioctl(ng1, SIOCSIFNAME): File exists Jan 17 14:40:04 ppp: mpd_wan.conf:11: Error in 'set iface name pppoe0'
-
Probably you get the error about the name since pfSense names itself the iface.
Since mpd5 latest has that included inside probably need to check removing the name. -
inspite of that error, pppoe still doesnt reconnect, probably tearing down the interface and bringing it back up using a down and up command would solve this.
-
I know all of the network professionals are going to roll their eyes at this question. So, forgive my ignorance. Would a work around be to put my ADSL modem back into router mode, then put my Pfsense firewall in the DMZ with a second public IP address on it? This would allow the modem to authenticate with PPPoE without affecting anything else. Please be gentle with your thoughts ;D
-
the part about netgraph in ppp log
Jan 17 14:40:04 ppp: [wan] IFACE: ioctl(ng1, SIOCSIFNAME): File exists Jan 17 14:40:04 ppp: mpd_wan.conf:11: Error in 'set iface name pppoe0'
Fixed in CVS
http://mpd.cvs.sourceforge.net/viewvc/mpd/mpd/src/iface.c?r1=1.223&r2=1.224&sortby=date -
issue still exists, it wont reconnect unless rebooted
-
I believe I’m having this issue, and have been for some time now. I always wondered why sometimes PPP would drop, and I’d drive out to site only to do a reboot and everything works. Sometimes I’d even have people put on site reboot for me, but it wouldn’t work. Is there any update on this issue?
Below log is newest on top, so read in reverse.
Feb 21 09:25:12 ppp 98216 [wan] IFACE: Down event Feb 21 09:25:08 ppp 98216 [wan] IPV6CP: LayerDown Feb 21 09:25:08 ppp 98216 [wan] IPV6CP: SendTerminateReq #38 Feb 21 09:25:08 ppp 98216 [wan] IPV6CP: state change Opened --> Closing Feb 21 09:25:08 ppp 98216 [wan] IPV6CP: Close event Feb 21 09:25:08 ppp 98216 [wan] IPCP: LayerDown Feb 21 09:25:08 ppp 98216 [wan] IPCP: SendTerminateReq #76 Feb 21 09:25:08 ppp 98216 [wan] IPCP: state change Opened --> Closing Feb 21 09:25:08 ppp 98216 [wan] IPCP: Close event Feb 21 09:25:08 ppp 98216 [wan] Bundle: Status update: up 0 links, total bandwidth 9600 bps Feb 21 09:25:08 ppp 98216 [wan_link0] Link: Leave bundle "wan" Feb 21 09:25:08 ppp 98216 [wan_link0] LCP: state change Opened --> Stopping Feb 21 09:25:08 ppp 98216 [wan_link0] LCP: peer not responding to echo requests Feb 21 09:25:08 ppp 98216 [wan_link0] LCP: no reply to 5 echo request(s) Feb 21 09:24:58 ppp 98216 [wan_link0] LCP: no reply to 4 echo request(s) Feb 21 09:24:48 ppp 98216 [wan_link0] LCP: no reply to 3 echo request(s) Feb 21 09:24:38 ppp 98216 [wan_link0] LCP: no reply to 2 echo request(s) Feb 21 09:24:27 ppp 98216 [wan_link0] LCP: no reply to 1 echo request(s
-