PPPoE reconenction fix - mpd fix ($100)
-
tried it, still the same, no luck :(
Dec 1 18:44:40 ppp: [wan_link0] LCP: no reply to 1 echo request(s) Dec 1 18:44:50 ppp: [wan_link0] LCP: no reply to 2 echo request(s) Dec 1 18:45:00 ppp: [wan_link0] LCP: no reply to 3 echo request(s) Dec 1 18:45:10 ppp: [wan_link0] LCP: no reply to 4 echo request(s) Dec 1 18:45:20 ppp: [wan_link0] LCP: no reply to 5 echo request(s) Dec 1 18:45:20 ppp: [wan_link0] LCP: peer not responding to echo requests Dec 1 18:45:20 ppp: [wan_link0] LCP: state change Opened --> Stopping Dec 1 18:45:20 ppp: [wan_link0] Link: Leave bundle "wan" Dec 1 18:45:20 ppp: [wan] Bundle: Status update: up 0 links, total bandwidth 9600 bps Dec 1 18:45:20 ppp: [wan] IPCP: Close event Dec 1 18:45:20 ppp: [wan] IPCP: state change Opened --> Closing Dec 1 18:45:20 ppp: [wan] IPCP: SendTerminateReq #3 Dec 1 18:45:20 ppp: [wan] IPCP: LayerDown Dec 1 18:45:20 ppp: [wan] IFACE: Down event Dec 1 18:45:20 ppp: [wan] IPCP: Down event Dec 1 18:45:20 ppp: [wan] IPCP: LayerFinish Dec 1 18:45:20 ppp: [wan] Bundle: No NCPs left. Closing links... Dec 1 18:45:20 ppp: [wan] IPCP: state change Closing --> Initial Dec 1 18:45:20 ppp: [wan_link0] LCP: SendTerminateReq #2 Dec 1 18:45:20 ppp: [wan_link0] LCP: LayerDown Dec 1 18:45:22 ppp: [wan_link0] LCP: SendTerminateReq #3 Dec 1 18:45:24 ppp: [wan_link0] LCP: state change Stopping --> Stopped Dec 1 18:45:24 ppp: [wan_link0] LCP: LayerFinish Dec 1 18:45:24 ppp: [wan_link0] PPPoE: connection closed Dec 1 18:45:24 ppp: [wan_link0] Link: DOWN event Dec 1 18:45:24 ppp: [wan_link0] LCP: Down event Dec 1 18:45:24 ppp: [wan_link0] LCP: state change Stopped --> Starting Dec 1 18:45:24 ppp: [wan_link0] LCP: LayerStart Dec 1 18:45:24 ppp: [wan_link0] Link: reconnection attempt 1 in 1 seconds Dec 1 18:45:46 ppp: [wan_link0] PPPoE connection timeout after 9 seconds Dec 1 18:45:46 ppp: [wan_link0] Link: DOWN event Dec 1 18:45:46 ppp: [wan_link0] LCP: Down event Dec 1 18:45:46 ppp: [wan_link0] Link: reconnection attempt 3 in 4 seconds Dec 1 18:45:50 ppp: [wan_link0] Link: reconnection attempt 3 Dec 1 18:45:50 ppp: [wan_link0] PPPoE: Connecting to '' Dec 1 18:45:59 ppp: [wan_link0] PPPoE connection timeout after 9 seconds Dec 1 18:45:59 ppp: [wan_link0] Link: DOWN event Dec 1 18:45:59 ppp: [wan_link0] LCP: Down event Dec 1 18:45:59 ppp: [wan_link0] Link: reconnection attempt 4 in 1 seconds Dec 1 18:46:00 ppp: [wan_link0] Link: reconnection attempt 4 Dec 1 18:46:00 ppp: [wan_link0] PPPoE: Connecting to '' Dec 1 18:46:09 ppp: [wan_link0] PPPoE connection timeout after 9 seconds Dec 1 18:46:09 ppp: [wan_link0] Link: DOWN event Dec 1 18:46:09 ppp: [wan_link0] LCP: Down event Dec 1 18:46:09 ppp: [wan_link0] Link: reconnection attempt 5 in 4 seconds Dec 1 18:46:13 ppp: [wan_link0] Link: reconnection attempt 5 Dec 1 18:46:13 ppp: [wan_link0] PPPoE: Connecting to '' Dec 1 18:46:22 ppp: [wan_link0] PPPoE connection timeout after 9 seconds Dec 1 18:46:22 ppp: [wan_link0] Link: DOWN event Dec 1 18:46:22 ppp: [wan_link0] LCP: Down event Dec 1 18:46:22 ppp: [wan_link0] Link: reconnection attempt 6 in 4 seconds Dec 1 18:46:26 ppp: [wan_link0] Link: reconnection attempt 6 Dec 1 18:46:26 ppp: [wan_link0] PPPoE: Connecting to '' Dec 1 18:46:35 ppp: [wan_link0] PPPoE connection timeout after 9 seconds Dec 1 18:46:35 ppp: [wan_link0] Link: DOWN event Dec 1 18:46:35 ppp: [wan_link0] LCP: Down event Dec 1 18:46:35 ppp: [wan_link0] Link: reconnection attempt 7 in 1 seconds Dec 1 18:46:36 ppp: [wan_link0] Link: reconnection attempt 7 Dec 1 18:46:36 ppp: [wan_link0] PPPoE: Connecting to ''
-
Can you do me a 'ngctl list' when in this situation?
-
here is the output before and after
when normally connected after reboot
$ ngctl list There are 17 total nodes: Name: <unnamed>Type: socket ID: 0000001c Num hooks: 0 Name: <unnamed>Type: socket ID: 0000001b Num hooks: 0 Name: <unnamed>Type: pppoe ID: 00000011 Num hooks: 2 Name: <unnamed>Type: socket ID: 00000010 Num hooks: 0 Name: ng0 Type: iface ID: 0000000d Num hooks: 1 Name: mpd10888-wan_link0-lt Type: tee ID: 0000000f Num hooks: 2 Name: vr1 Type: ether ID: 00000002 Num hooks: 1 Name: vr2 Type: ether ID: 00000003 Num hooks: 0 Name: bridge0 Type: ether ID: 00000018 Num hooks: 0 Name: mpd10888-stats Type: socket ID: 00000012 Num hooks: 0 Name: mpd10888-cso Type: socket ID: 0000000b Num hooks: 0 Name: mpd10888-wan-mss Type: tcpmss ID: 00000013 Num hooks: 2 Name: mpd10888-wan Type: ppp ID: 0000000e Num hooks: 3 Name: mpd10888-eso Type: socket ID: 0000000c Num hooks: 0 Name: mpd10888-lso Type: socket ID: 0000000a Num hooks: 1 Name: wlan0 Type: ether ID: 00000017 Num hooks: 0 Name: ngctl4052 Type: socket ID: 00000023 Num hooks: 0</unnamed></unnamed></unnamed></unnamed>
when endless loop of reconenction
$ ngctl list There are 16 total nodes: Name: <unnamed>Type: socket ID: 0000001c Num hooks: 0 Name: <unnamed>Type: socket ID: 0000001b Num hooks: 0 Name: <unnamed>Type: pppoe ID: 00000011 Num hooks: 2 Name: <unnamed>Type: socket ID: 00000010 Num hooks: 0 Name: ng0 Type: iface ID: 0000000d Num hooks: 0 Name: mpd10888-wan_link0-lt Type: tee ID: 00000028 Num hooks: 2 Name: vr1 Type: ether ID: 00000002 Num hooks: 1 Name: vr2 Type: ether ID: 00000003 Num hooks: 0 Name: ngctl23563 Type: socket ID: 0000002d Num hooks: 0 Name: bridge0 Type: ether ID: 00000018 Num hooks: 0 Name: mpd10888-stats Type: socket ID: 00000012 Num hooks: 0 Name: mpd10888-cso Type: socket ID: 0000000b Num hooks: 0 Name: mpd10888-wan Type: ppp ID: 0000000e Num hooks: 1 Name: mpd10888-eso Type: socket ID: 0000000c Num hooks: 0 Name: mpd10888-lso Type: socket ID: 0000000a Num hooks: 2 Name: wlan0 Type: ether ID: 00000017 Num hooks: 0</unnamed></unnamed></unnamed></unnamed>
-
@ermal:
Can you do me a 'ngctl list' when in this situation?
any luck?
-
still no fix for this
-
Have your tried pfsense 2.1-DEVEL just in case the latest mpd 5.6 improves things?
-
havent tried it coz its not much in a usable state currently for light production, mayb later
-
Try adding
set bundle no noretry
src: http://unix.derkeiler.com/Mailing-Lists/FreeBSD/questions/2007-09/msg01895.html
Apparently it was also discussed here a couple of years ago:
According to http://mpd.sourceforge.net/doc5/mpd4.html
Changes since version 4.1rc2:
Bundle's noretry option is enabled by default now. -
i tried to feed that line in using edit file from the web GUI but it seems pfsense seems to remove that entry if rebooted or even if i goto interfaces and click disconnect and then connect
any help regarding some php code change to keep that entry intact?
-
i managed to edit the interfaces.inc so it adds the line which it does now but i guess mpd ignores it as the system log gives the below message
ppp: mpd_wan.conf:31: Incorrect context for: 'set bundle no noretry'
-
actually the command to use was this
set link no noretry
it didnt help coz the original issue which u mentioned in that first link was his connection wasnt redialing that was due to noretry defaulting to yes but that was in mpd4 and i guess pfsense uses mpd5 in v2.0.1 so thats y that command isnt recognized, only max-redial is the command available which cant be set to some number or 0 for unlimited and -1 to disable redial which pfsense defaults it to 0 so my connection is actually redialed but due to some other reason and the isp's fiber optic modem or their bras server, mpd isnt able to reconnect untill its rebooted so obviously something different happens during pfsense reboot time connection or mayb because the vr1 resets which then allows pfsense to connect fine on reboot but to replicate that i removed the network cable as well and tried and try replugging it in but doesnt help.
-
xbipin,
Let me try to recap:
-
You had no problem with PPPoE auto-reconnection with pfsense 1.2.3
-
You only started having problems with 2.0-something (BETA, RC etc)
-
You are able to reproduce the problem at will
-
There are others who have a similar problem, but most pfsense users don't
I think your best option would be to obtain logs with full verbosity and post them along your mpd config files to the mpd-forum at http://sourceforge.net/projects/mpd/forums/forum/44692
-
-
i already did that in their mailing list, hardly got any reply at all and there r many others with the problem but they r either using 1.2.3 or trying to live with 2.0.1 like me. the basic reconnection issue is mpd attempts but is unable to reconnect and if u read the past posts, i have provided logs, config etc etc almost more than 50 times now till date.
bytheway, all routers available in the market etc work very well over the same link, then y does mpd have issues?
-
there r many others with the problem but they r either using 1.2.3 or trying to live with 2.0.1 like me.
Then why aren't any others bidding here to try to get it fixed?
-
coz officially ermal was on this to get it solved but then mayb he realized its not a easy fix by simply patching some php code so this thread went old as i was out of town and got abandoned so most might not have read it also now but if u look at other threads here and there in the complete forum then there r quiet a few ppl suffering the same and it was already discussed many many times but didnt yield any permanent solution.
after a lot of tracing in the past also it came to light that there was something to do with the isp BRAS or pppoe server or whatever they call it and some security measures but my point is that how do commercial routers overcome this and pfsense or mpd doesnt
-
Looks like I've run into the same issue, not absolutely the same, but similar and solution for the problem is the same - reboot of pfsense always helps.
Is there the way to reboot pfsense automatically after XX PPPoE connection retries? I know this is not the best way, but at least it works always for me. -
not really i backed off just other priorities first.
Sorry about that.
-
ermal, at least you are monitoring ::)
Looks like I've found the solution, that works at least for me
I've added two lines to the end of ppp-linkdownifconfig em0 down
ifconfig em0 upAnd looks like reconnection bug is gone.
P.S. em0 is interface, where PPPoE is
P.P.S. I think it's related to driver. -
@w0w:
ermal, at least you are monitoring ::)
Looks like I've found the solution, that works at least for me
I've added two lines to the end of ppp-linkdownifconfig em0 down
ifconfig em0 upAnd looks like reconnection bug is gone.
P.S. em0 is interface, where PPPoE is
P.P.S. I think it's related to driver.can u mention the location of the file and where exactly did u put those lines, ill give it a try too
-
Certainly that will reset the device by doing up/down.
Just not a generic solution :) -
@w0w:
ermal, at least you are monitoring ::)
Looks like I've found the solution, that works at least for me
I've added two lines to the end of ppp-linkdownifconfig em0 down
ifconfig em0 upAnd looks like reconnection bug is gone.
P.S. em0 is interface, where PPPoE is
P.P.S. I think it's related to driver.can u mention the location of the file and where exactly did u put those lines, ill give it a try too
usr/local/sbin
You can also use Commands-Find File in WinSCP if you have windows
#!/bin/sh if [ -f /tmp/$1up ] && [ -f /conf/$1.log ]; then seconds=$((`date -j +%s` - `/usr/bin/stat -f %m /tmp/$1up`)) /usr/local/sbin/ppp-log-uptime.sh $seconds $1 & fi if [ "$3" != "" ]; then echo "Removing states from $3" | logger -t ppp-linkdown /sbin/pfctl -k 0.0.0.0/0 -k $3/32 /sbin/pfctl -k $3/32 pfctl -K $3/32 fi if [ "$4" != "" ]; then echo "Removing states to $4" | logger -t ppp-linkdown /sbin/pfctl -b 0.0.0.0/32 -b $4/32 if [ -f "/tmp/${interface}_defaultgw" ]; then route delete default $4 fi fi # delete the node just in case mpd cannot do that /usr/sbin/ngctl shutdown $1: if [ -f "/var/etc/nameserver_$1" ]; then # Remove old entries for nameserver in `cat /var/etc/nameserver_$1`; do /sbin/route delete $nameserver >/dev/null 2>&1 done /bin/rm -f /var/etc/nameserver_$1 fi # Do not remove gateway used during filter reload. /bin/rm -f /tmp/$1_router /bin/rm -f /tmp/$1up /bin/rm -f /tmp/$1_ip /usr/local/sbin/pfSctl -c 'service reload dns' ifconfig em0 down ifconfig em0 up
Do not forget to replace em0 with your own device name.
-
how do we find out the device name?
-
how do we find out the device name?
on status interface, you can see interface name and device.
WAN interface (em0)
-
on that it shows this
WAN interface (pppoe0)where as im using a alix and my wan port is vr1 so should i use pppoe0 or vr1?
-
vr1
You need to restart physical (port) interface, not virtual PPPoE, that I've tried to do also, by killing mpd and starting again with no luck
-
well then i see this
-
anyways i tried vr1 and rebooted and checked, it fixes the issue partially, meaning, if my isp fiber optic device is switched off and on then pfsense would connect fine once the device is booted which means one issue solved, but there is a reset switch on that isp device and suppose if i press that then once its booted, pfsense wont connect and fall into endless reconnection loop and one easier way to solve this is to pull the wan wire which connects isp device to pfsense and then pfsense reconnects instead of rebooting pfsense
-
yes there was vr1 on it.
this means when power is on on the isp device port coz its reset then the solution doesnt work but if its switched off and on or cable unplugged then the port looses power and then once reconnected pppoe reconnects fine.
the reason y i try to do the reset scenario coz in a few instances, the isp device gets a firware update and then it reboots, this leaves the power on and then pfsense wont reconnect
-
anyways i tried vr1 and rebooted and checked, it fixes the issue partially, meaning, if my isp fiber optic device is switched off and on then pfsense would connect fine once the device is booted which means one issue solved, but there is a reset switch on that isp device and suppose if i press that then once its booted, pfsense wont connect and fall into endless reconnection loop and one easier way to solve this is to pull the wan wire which connects isp device to pfsense and then pfsense reconnects instead of rebooting pfsense
You can also not to push reset switch on your magic ISP device :) Just power off and on to reset it 8)
Can you show the System and PPP log, when you have pressed the reset switch and pfsense won't reconnect?
-
like i said, i dont need to reset it, but due to a firmware update from isp or even a remotely trigerred reboot from isp causes this, the log is same as here
http://forum.pfsense.org/index.php/topic,41061.msg225631.html#msg225631 -
I hope that you have restored your original pppoe-linkdown file after playing with
/usr/sbin/ngctl shutdown $1:
and
/usr/local/sbin/pfSctl -c 'interface reload $iface'
that was suggested in november 2011 -
And I can't see system log anywhere, PPP only
-
yes the linkdown file is the standard one without any edits coz those edits didnt help, ill get u the system log now, frankly speaking i have already posted logs so many times that i got tired of doing the same again and again when some1 tries to help
-
here r system log and ppp log when isp device reset
May 24 19:03:16 syslogd: exiting on signal 15 May 24 19:03:16 syslogd: kernel boot file is /boot/kernel/kernel May 24 19:03:38 check_reload_status: Linkup starting vr1 May 24 19:03:38 kernel: vr1: link state changed to DOWN May 24 19:03:46 apinger: ALARM: ExpressVPN(107.6.112.170) *** down *** May 24 19:03:46 apinger: ALARM: WAN(195.229.252.27) *** down *** May 24 19:03:56 check_reload_status: Reloading filter May 24 19:04:39 check_reload_status: Rewriting resolv.conf May 24 19:04:46 dnsmasq[6884]: reading /etc/resolv.conf May 24 19:04:46 dnsmasq[6884]: using nameserver 198.153.192.1#53 May 24 19:04:46 dnsmasq[6884]: using nameserver 208.67.222.222#53 May 24 19:04:46 dnsmasq[6884]: using nameserver 213.42.20.20#53 May 24 19:04:46 dnsmasq[6884]: using nameserver 8.8.4.4#53 May 24 19:04:46 dnsmasq[6884]: ignoring nameserver 127.0.0.1 - local interface May 24 19:04:46 dnsmasq[6884]: ignoring nameserver 127.0.0.1 - local interface May 24 19:04:53 filterdns: host_dns: failed looking up "pptp-uk1.expressnetwork.net": hostname nor servname provided, or not known May 24 19:04:54 check_reload_status: Linkup starting vr1 May 24 19:04:54 kernel: vr1: link state changed to UP May 24 19:05:40 kernel: ovpnc1: link state changed to DOWN May 24 19:05:40 check_reload_status: Reloading filter May 24 19:05:51 filterdns: host_dns: failed looking up "pptp-uk1.expressnetwork.net": hostname nor servname provided, or not known
May 24 19:04:39 ppp: [wan] IFACE: Down event May 24 19:04:39 ppp: [wan] IPCP: Down event May 24 19:04:39 ppp: [wan] IPCP: LayerFinish May 24 19:04:39 ppp: [wan] Bundle: No NCPs left. Closing links... May 24 19:04:39 ppp: [wan] IPCP: state change Closing --> Initial May 24 19:04:39 ppp: [wan_link0] LCP: SendTerminateReq #2 May 24 19:04:39 ppp: [wan_link0] LCP: LayerDown May 24 19:04:41 ppp: [wan_link0] LCP: SendTerminateReq #3 May 24 19:04:43 ppp: [wan_link0] LCP: state change Stopping --> Stopped May 24 19:04:43 ppp: [wan_link0] LCP: LayerFinish May 24 19:04:43 ppp: [wan_link0] PPPoE: connection closed May 24 19:04:43 ppp: [wan_link0] Link: DOWN event May 24 19:04:43 ppp: [wan_link0] LCP: Down event May 24 19:04:43 ppp: [wan_link0] LCP: state change Stopped --> Starting May 24 19:04:43 ppp: [wan_link0] LCP: LayerStart May 24 19:04:43 ppp: [wan_link0] Link: reconnection attempt 1 in 4 seconds May 24 19:04:47 ppp: [wan_link0] Link: reconnection attempt 1 May 24 19:04:47 ppp: [wan_link0] PPPoE: Connecting to '' May 24 19:04:56 ppp: [wan_link0] PPPoE connection timeout after 9 seconds May 24 19:04:56 ppp: [wan_link0] Link: DOWN event May 24 19:04:56 ppp: [wan_link0] LCP: Down event May 24 19:04:56 ppp: [wan_link0] Link: reconnection attempt 2 in 3 seconds May 24 19:04:59 ppp: [wan_link0] Link: reconnection attempt 2 May 24 19:04:59 ppp: [wan_link0] PPPoE: Connecting to '' May 24 19:05:08 ppp: [wan_link0] PPPoE connection timeout after 9 seconds May 24 19:05:08 ppp: [wan_link0] Link: DOWN event May 24 19:05:08 ppp: [wan_link0] LCP: Down event May 24 19:05:08 ppp: [wan_link0] Link: reconnection attempt 3 in 4 seconds May 24 19:05:12 ppp: [wan_link0] Link: reconnection attempt 3 May 24 19:05:12 ppp: [wan_link0] PPPoE: Connecting to '' May 24 19:05:14 ppp: PPPoE: rec'd ACNAME "WE1" May 24 19:05:21 ppp: [wan_link0] PPPoE connection timeout after 9 seconds May 24 19:05:21 ppp: [wan_link0] Link: DOWN event May 24 19:05:21 ppp: [wan_link0] LCP: Down event May 24 19:05:21 ppp: [wan_link0] Link: reconnection attempt 4 in 3 seconds May 24 19:05:24 ppp: [wan_link0] Link: reconnection attempt 4 May 24 19:05:24 ppp: [wan_link0] PPPoE: Connecting to '' May 24 19:05:24 ppp: PPPoE: rec'd ACNAME "WE1" May 24 19:05:33 ppp: [wan_link0] PPPoE connection timeout after 9 seconds May 24 19:05:33 ppp: [wan_link0] Link: DOWN event May 24 19:05:33 ppp: [wan_link0] LCP: Down event May 24 19:05:33 ppp: [wan_link0] Link: reconnection attempt 5 in 2 seconds May 24 19:05:35 ppp: [wan_link0] Link: reconnection attempt 5 May 24 19:05:35 ppp: [wan_link0] PPPoE: Connecting to '' May 24 19:05:35 ppp: PPPoE: rec'd ACNAME "WE1"
the below is when it doesnt reconnect and i have to pull plug and replug to make it connect
May 24 19:06:35 kernel: vr1: vr_stop: Rx shutdown error May 24 19:06:35 kernel: vr1: Using force reset command. May 24 19:06:43 check_reload_status: Linkup starting vr1 May 24 19:06:43 kernel: vr1: link state changed to UP May 24 19:06:55 miniupnpd[45337]: ioctl(s, SIOCGIFADDR, ...): Can't assign requested address May 24 19:06:55 miniupnpd[45337]: ioctl(s, SIOCGIFADDR, ...): Can't assign requested address May 24 19:07:06 php: : ROUTING: setting default route to 195.229.252.27 May 24 19:07:06 dnsmasq[6884]: reading /etc/resolv.conf May 24 19:07:06 dnsmasq[6884]: using nameserver 198.153.192.1#53 May 24 19:07:06 dnsmasq[6884]: using nameserver 208.67.222.222#53 May 24 19:07:06 dnsmasq[6884]: using nameserver 213.42.20.20#53 May 24 19:07:06 dnsmasq[6884]: using nameserver 8.8.4.4#53 May 24 19:07:06 dnsmasq[6884]: ignoring nameserver 127.0.0.1 - local interface May 24 19:07:06 dnsmasq[6884]: ignoring nameserver 127.0.0.1 - local interface May 24 19:07:06 apinger: Exiting on signal 15. May 24 19:07:07 check_reload_status: Reloading filter May 24 19:07:07 apinger: Starting Alarm Pinger, apinger(27426) May 24 19:07:07 php: : DynDns: updatedns() starting May 24 19:07:07 php: : DynDns debug information: 92.99.234.53 extracted from local system. May 24 19:07:07 php: : DynDns: Current WAN IP: 92.99.234.53 Cached IP: 92.99.239.90 May 24 19:07:07 php: : DynDns debug information: DynDns: cacheIP != wan_ip. Updating. Cached IP: 92.99.239.90 WAN IP: 92.99.234.53 May 24 19:07:07 php: : DynDns: DynDns _update() starting. May 24 19:07:09 php: : DynDns: DynDns _checkStatus() starting. May 24 19:07:09 php: : DynDns: Current Service: dyndns May 24 19:07:09 php: : DynDns debug information: 92.99.234.53 extracted from local system. May 24 19:07:09 php: : phpDynDNS: updating cache file /conf/dyndns_wandyndns'***.dyndns.org'.cache: 92.99.234.53 May 24 19:07:09 php: : phpDynDNS: (Success) IP Address Changed Successfully! (92.99.234.53) May 24 19:07:15 php: : Resyncing OpenVPN instances for interface WAN. May 24 19:07:16 check_reload_status: Reloading filter May 24 19:07:16 php: : The command '/usr/bin/killall 'ntpd'' returned exit code '1', the output was 'killall: warning: kill -TERM 23775: No such process' May 24 19:07:16 php: : OpenNTPD is starting up. May 24 19:07:16 php: : pfSense package system has detected an ip change 92.99.239.90 -> ... Restarting packages. May 24 19:07:16 check_reload_status: Starting packages May 24 19:07:20 kernel: ovpnc1: link state changed to UP May 24 19:07:20 check_reload_status: rc.newwanip starting ovpnc1 May 24 19:07:24 php: : Restarting/Starting all packages. May 24 19:07:27 php: : rc.newwanip: Informational is starting ovpnc1. May 24 19:07:27 php: : rc.newwanip: on (IP address: 10.14.40.38) (interface: opt2) (real interface: ovpnc1). May 24 19:07:27 php: : Removing static route for monitor 107.6.112.170 and adding a new route through 10.14.40.37 May 24 19:07:27 apinger: Exiting on signal 15. May 24 19:07:28 check_reload_status: Reloading filter May 24 19:07:28 apinger: Starting Alarm Pinger, apinger(11588) May 24 19:07:32 dnsmasq[6884]: reading /etc/resolv.conf May 24 19:07:32 dnsmasq[6884]: using nameserver 198.153.192.1#53 May 24 19:07:32 dnsmasq[6884]: using nameserver 208.67.222.222#53 May 24 19:07:32 dnsmasq[6884]: using nameserver 213.42.20.20#53 May 24 19:07:32 dnsmasq[6884]: using nameserver 8.8.4.4#53 May 24 19:07:32 dnsmasq[6884]: ignoring nameserver 127.0.0.1 - local interface May 24 19:07:32 dnsmasq[6884]: ignoring nameserver 127.0.0.1 - local interface May 24 19:07:38 apinger: ALARM: ExpressVPN(107.6.112.170) *** down ***
May 24 19:06:59 ppp: [wan_link0] PROTOCOMP May 24 19:06:59 ppp: [wan_link0] MRU 1492 May 24 19:06:59 ppp: [wan_link0] MAGICNUM 155baca3 May 24 19:06:59 ppp: [wan_link0] LCP: rec'd Configure Request #29 (Req-Sent) May 24 19:06:59 ppp: [wan_link0] MRU 1492 May 24 19:06:59 ppp: [wan_link0] AUTHPROTO PAP May 24 19:06:59 ppp: [wan_link0] MAGICNUM 57dcb580 May 24 19:06:59 ppp: [wan_link0] LCP: SendConfigAck #29 May 24 19:06:59 ppp: [wan_link0] MRU 1492 May 24 19:06:59 ppp: [wan_link0] AUTHPROTO PAP May 24 19:06:59 ppp: [wan_link0] MAGICNUM 57dcb580 May 24 19:06:59 ppp: [wan_link0] LCP: state change Req-Sent --> Ack-Sent May 24 19:06:59 ppp: [wan_link0] LCP: rec'd Configure Ack #4 (Ack-Sent) May 24 19:06:59 ppp: [wan_link0] PROTOCOMP May 24 19:06:59 ppp: [wan_link0] MRU 1492 May 24 19:06:59 ppp: [wan_link0] MAGICNUM 155baca3 May 24 19:06:59 ppp: [wan_link0] LCP: state change Ack-Sent --> Opened May 24 19:06:59 ppp: [wan_link0] LCP: auth: peer wants PAP, I want nothing May 24 19:06:59 ppp: [wan_link0] PAP: using authname "******" May 24 19:06:59 ppp: [wan_link0] PAP: sending REQUEST #1 len: 20 May 24 19:06:59 ppp: [wan_link0] LCP: LayerUp May 24 19:06:59 ppp: [wan_link0] PAP: rec'd ACK #1 len: 5 May 24 19:06:59 ppp: [wan_link0] LCP: authorization successful May 24 19:06:59 ppp: [wan_link0] Link: Matched action 'bundle "wan" ""' May 24 19:06:59 ppp: [wan_link0] Link: Join bundle "wan" May 24 19:06:59 ppp: [wan] Bundle: Status update: up 1 link, total bandwidth 64000 bps May 24 19:06:59 ppp: [wan] IPCP: Open event May 24 19:06:59 ppp: [wan] IPCP: state change Initial --> Starting May 24 19:06:59 ppp: [wan] IPCP: LayerStart May 24 19:06:59 ppp: [wan] IPCP: Up event May 24 19:06:59 ppp: [wan] IPCP: state change Starting --> Req-Sent May 24 19:06:59 ppp: [wan] IPCP: SendConfigReq #4 May 24 19:06:59 ppp: [wan] IPADDR 0.0.0.0 May 24 19:06:59 ppp: [wan] IPCP: rec'd Configure Nak #4 (Req-Sent) May 24 19:06:59 ppp: [wan] IPADDR 92.99.234.53 May 24 19:06:59 ppp: [wan] 92.99.234.53 is OK May 24 19:07:00 ppp: [wan] IPCP: SendConfigReq #5 May 24 19:07:00 ppp: [wan] IPADDR 92.99.234.53 May 24 19:07:00 ppp: [wan] IPCP: rec'd Configure Ack #5 (Req-Sent) May 24 19:07:00 ppp: [wan] IPADDR 92.99.234.53 May 24 19:07:00 ppp: [wan] IPCP: state change Req-Sent --> Ack-Rcvd May 24 19:07:00 ppp: [wan] IPCP: rec'd Configure Request #168 (Ack-Rcvd) May 24 19:07:00 ppp: [wan] IPADDR 195.229.252.27 May 24 19:07:00 ppp: [wan] 195.229.252.27 is OK May 24 19:07:00 ppp: [wan] IPCP: SendConfigAck #168 May 24 19:07:00 ppp: [wan] IPADDR 195.229.252.27 May 24 19:07:00 ppp: [wan] IPCP: state change Ack-Rcvd --> Opened May 24 19:07:00 ppp: [wan] IPCP: LayerUp May 24 19:07:00 ppp: [wan] 92.99.234.53 -> 195.229.252.27 May 24 19:07:00 ppp: [wan] IFACE: Up event
-
I can't see any other software fix, instead on initiating reboot. This looks like more complex problem then driver or mpd only. So we need to write the if function to the ppp-linkdown, that checks for running shutdown process, and if it does not exists, starts one like 'shutdown -r +10', that means if script is running for the first time it always wants to restart pfsense after 10 minutes. And we need to add one line only to the ppp-linkup that looks like
'pkill shutdown'.I don't have knowledge to write the if function correctly, so I just added to the end of ppp-linkdown
shutdown -r +1and
pkill shutdown
to the ppp-linkup file.
Every reconnect starts own shutdown process but you don't have them much in one minute (yes +1 is a minute) before first of them restarts the pfsense. And if the PPPoE is coming up in less then 1 minute then shutdown process will be killed.
It would be good if somebody helps to write if function described above. -
My friend suggested me to modify his old SQL check script, so it would be
ppp-linkdown
#!/bin/sh if [ -f /tmp/$1up ] && [ -f /conf/$1.log ]; then seconds=$((`date -j +%s` - `/usr/bin/stat -f %m /tmp/$1up`)) /usr/local/sbin/ppp-log-uptime.sh $seconds $1 & fi if [ "$3" != "" ]; then echo "Removing states from $3" | logger -t ppp-linkdown /sbin/pfctl -k 0.0.0.0/0 -k $3/32 /sbin/pfctl -k $3/32 pfctl -K $3/32 fi if [ "$4" != "" ]; then echo "Removing states to $4" | logger -t ppp-linkdown /sbin/pfctl -b 0.0.0.0/32 -b $4/32 if [ -f "/tmp/${interface}_defaultgw" ]; then route delete default $4 fi fi # delete the node just in case mpd cannot do that /usr/sbin/ngctl shutdown $1: if [ -f "/var/etc/nameserver_$1" ]; then # Remove old entries for nameserver in `cat /var/etc/nameserver_$1`; do /sbin/route delete $nameserver >/dev/null 2>&1 done /bin/rm -f /var/etc/nameserver_$1 fi # Do not remove gateway used during filter reload. /bin/rm -f /tmp/$1_router /bin/rm -f /tmp/$1up /bin/rm -f /tmp/$1_ip /usr/local/sbin/pfSctl -c 'service reload dns' ifconfig em0 down ifconfig em0 up #initiate reboot if PPPoE reconnection fails. PID=`ps auxww | grep shutdown | grep -v grep | awk '{ print $2 }'` if ps auxww | grep -e shutdown | grep -v grep > /dev/null ; then echo "shutdown running on PID $PID" else echo "starting shutdown/reboot of pfsense" shutdown -r +10 fi
Tested OK!
ppp-linkup
#!/bin/sh # let the configuration system know that the ip has changed. /bin/echo $4 > /tmp/$1_router /bin/echo $3 > /tmp/$1_ip /usr/bin/touch /tmp/$1up ALLOWOVERRIDE=`/usr/bin/grep dnsallowoverride /conf/config.xml | /usr/bin/wc -l` if [ $ALLOWOVERRIDE -gt 0 ]; then # write nameservers to file if [ $6 = "dns1" ]; then echo $7 > /var/etc/nameserver_$1 /sbin/route change $7 $4 fi if [ $8 = "dns2" ]; then echo $9 >> /var/etc/nameserver_$1 /sbin/route change $9 $4 fi /usr/local/sbin/pfSctl -c 'service reload dns' /bin/sleep 1 fi /usr/local/sbin/pfSctl -c "interface newip $1" pkill shutdown exit 0
-
Please use 'shutdown -r +5' instead of 'shutdown -r +10'
I've found that it is impossible to kill the shutdown process if using +10 (10 minutes).
When tested I've used less then 5 minutes delay.[2.1-DEVELOPMENT][root@pfhacom.xxxnetxxx]/root(326): *** System shutdown message from root@pfhacom.xxxnetxxx *** System going down in 10 minutes [2.1-DEVELOPMENT][root@pfhacom.xxxnetxxx]/root(327): ps auxww | grep shutdown | grep -v grep root 2293 0.0 0.1 3316 1124 ?? I ``` ~~after "pkill shutdown"
ps auxww | grep shutdown | grep -v grep
root 25185 0.0 0.1 3316 1124 ?? S*** System shutdown message from root@pfhacom.xxxnetxxx *** System going down in 5 minutes I can kill the process by pkill shutdown. WTF? What am I doing wrong? If I start shutdown -r +10 or any number in console, I can always kill it.~~~~
-
i havent tried this as yet, will do so soon
-
After suffering from very similar logs and lots of googling I found a cure (well a cause) for me anyway.
If the router came up after pfSense (if it was powered off then on again), pfSense would not connect to it no matter what unless you power cycled it again or yanked the cable. What I found was happening was when the link first came up pfSense would grab the ip address from the router using DHCP and start sending its pppoe requests to it (producing the same logs about connecting posted earlier), it would never log in. Pulling the cable, waiting a bit then plugging it back in would then log in straight away.
What was happening was the first ip address it obtained from the router was a local 'admin' address (in my case 192.168.2.10), the router would then connect to whatever destination and sync, it would then change it's ip address to the correct WAN IP (In my case 217.155..), but as the link status stayed as 'up' pfSense would not grab the new ip address and keep sending it's pppoe junk to the original 192.168.2.10 address. No amount of ifconfig up/down would shift it.
The solution to my problem was just to disable the DHCP server in the router as it isn't required anyway (admin access can be got using a static ip). Now I can power on/off router or pull/reconnect cable and pfSense picks up the status and the correct ip address straight away with no rebooting or anything.
I hope this is of use to someone as googling this issue picks this post as the top one.
-
I'd just like to say that I have no problem with reconnection on the latest 2.1 versions based on freebsd 8.3 and new MPD version