Netgate m1n1wall

Author Topic: PPPoE reconenction fix - mpd fix ($100)  (Read 44698 times)

0 Members and 1 Guest are viewing this topic.

Offline xbipin

  • Hero Member
  • *****
  • Posts: 1220
    • View Profile
Re: PPPoE reconenction fix - mpd fix ($100)
« Reply #105 on: May 24, 2012, 09:15:02 am »
well then i see this

Offline xbipin

  • Hero Member
  • *****
  • Posts: 1220
    • View Profile
Re: PPPoE reconenction fix - mpd fix ($100)
« Reply #106 on: May 24, 2012, 09:20:11 am »
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

Offline xbipin

  • Hero Member
  • *****
  • Posts: 1220
    • View Profile
Re: PPPoE reconenction fix - mpd fix ($100)
« Reply #107 on: May 24, 2012, 09:26:14 am »
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

Offline w0w

  • Jr. Member
  • **
  • Posts: 83
    • View Profile
Re: PPPoE reconenction fix - mpd fix ($100)
« Reply #108 on: May 24, 2012, 09:32:43 am »
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?

Offline xbipin

  • Hero Member
  • *****
  • Posts: 1220
    • View Profile
Re: PPPoE reconenction fix - mpd fix ($100)
« Reply #109 on: May 24, 2012, 09:38:01 am »
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

Offline w0w

  • Jr. Member
  • **
  • Posts: 83
    • View Profile
Re: PPPoE reconenction fix - mpd fix ($100)
« Reply #110 on: May 24, 2012, 09:48:27 am »
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

Offline w0w

  • Jr. Member
  • **
  • Posts: 83
    • View Profile
Re: PPPoE reconenction fix - mpd fix ($100)
« Reply #111 on: May 24, 2012, 09:56:28 am »
And I can't see system log anywhere, PPP only

Offline xbipin

  • Hero Member
  • *****
  • Posts: 1220
    • View Profile
Re: PPPoE reconenction fix - mpd fix ($100)
« Reply #112 on: May 24, 2012, 09:58:25 am »
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

Offline xbipin

  • Hero Member
  • *****
  • Posts: 1220
    • View Profile
Re: PPPoE reconenction fix - mpd fix ($100)
« Reply #113 on: May 24, 2012, 10:08:20 am »
here r system log and ppp log when isp device reset
Code: [Select]
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

Code: [Select]
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
Code: [Select]
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 ***

Code: [Select]
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
« Last Edit: May 24, 2012, 10:11:57 am by xbipin »

Offline w0w

  • Jr. Member
  • **
  • Posts: 83
    • View Profile
Re: PPPoE reconenction fix - mpd fix ($100)
« Reply #114 on: May 24, 2012, 01:02:52 pm »
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 +1

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

Offline w0w

  • Jr. Member
  • **
  • Posts: 83
    • View Profile
Re: PPPoE reconenction fix - mpd fix ($100)
« Reply #115 on: May 24, 2012, 01:31:08 pm »
My friend suggested me to modify his old SQL check script, so it would be

ppp-linkdown

Code: [Select]
#!/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

Code: [Select]
#!/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
« Last Edit: May 24, 2012, 01:51:53 pm by w0w »

Offline w0w

  • Jr. Member
  • **
  • Posts: 83
    • View Profile
Re: PPPoE reconenction fix - mpd fix ($100)
« Reply #116 on: May 31, 2012, 04:42:27 am »
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.

Code: [Select]
[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<s  12:58PM   0:00.00 shutdown -r +10

after "pkill shutdown"

Code: [Select]
ps auxww | grep shutdown | grep -v grep
root   25185  0.0  0.1  3316  1124  ??  S<s  12:36PM   0:00.00 shutdown -r +10

and  after, when this message appears:

*** 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.
« Last Edit: May 31, 2012, 04:22:06 pm by w0w »

Offline xbipin

  • Hero Member
  • *****
  • Posts: 1220
    • View Profile
Re: PPPoE reconenction fix - mpd fix ($100)
« Reply #117 on: June 19, 2012, 03:35:22 am »
i havent tried this as yet, will do so soon

Offline TimAtHome

  • Newbie
  • *
  • Posts: 1
    • View Profile
Re: PPPoE reconenction fix - mpd fix ($100)
« Reply #118 on: August 22, 2012, 09:52:04 pm »
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.

Offline w0w

  • Jr. Member
  • **
  • Posts: 83
    • View Profile
Re: PPPoE reconenction fix - mpd fix ($100)
« Reply #119 on: August 22, 2012, 10:31:01 pm »
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