PPPoE reconenction fix - mpd fix ($100)
-
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 knownMay 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 fiTested 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
-
i also got sick and tired of this issue but currently im using w0w's hack but the strange thing is after i implemented it, the rotuer is supposed to restart in a specific time if pppoe reconnection fails and i have set this to 3 mins so almost about 2:50 mins pppoe doesnt reconnect and when its about to reboot, it just reconencts magically.
i tried removing that hack but then it would reconnect in hours also.i hope some of the developers read this and posted some code change such that u can use DHCP as well as pppoe reconnects also if dhcp was the main issue
-
xbipin
looks like
"ifconfig em0 down
ifconfig em0 up"
works but delayed.Actually I've written another one startup script
#!/bin/sh IP=`/usr/bin/netstat -rn | /usr/bin/grep 'default' | /usr/bin/awk '{ print $2}'` /sbin/ping -c 2 $IP > /dev/null if [ $? != 0 ] ; then /sbin/ifconfig em0 down /sbin/ifconfig em0 up if /bin/ps auxww | /usr/bin/grep -e shutdown | /usr/bin/grep -v grep > /dev/null ; then echo "shutdown running" else echo "starting shutdown/reboot of pfsense" /sbin/shutdown -r +5 fi fiI've named it "ppp_force_linkup.sh" in the /usr/bin/ (Don't forget to change access to the file via WinSCP - properties - Octal: 0755 aka rwxr-xr-x )
Next I've downloaded config and edited:
/usr/local/sbin/expiretable -v -t 3600 sshlockout -------------------------------------inserted code begin----------------------------------------------------------- <minute>*/30</minute> <hour>*</hour> <mday>*</mday> <month>*</month> <wday>*</wday> <who>root</who> <command></command>/usr/bin/nice -n20 /usr/bin/ppp_force_linkup.sh -------------------------------------inserted code end----------------------------------------------------------- <minute>1</minute> <hour>1</hour> <mday>*</mday> <month>*</month> <wday>*</wday> <who>root</who> <command></command>/usr/bin/nice -n20 /etc/rc.dyndns.update <minute>*/60</minute> <hour>*</hour> <mday>*</mday> <month>*</month> <wday>*</wday>Every 30 min script looks for current getaway IP, pings it and if no success then it restarts the link and reboot is sheduled. if you are using previously modded ppp-linkup and ppp connection is established in that time, then sheduled reboot is canceled as it should be.
All those mods are needed only for the 2.0x branch, I think, this script was made for those situations, when PC is rebooted but no PPPoE link established for some reason or mpd runned into "stuck" mode or somethin else…
Even having this script enabled, I've got situation when getaway ping was OK but pinging any internet server
was failed (ISP problem, actually)So may be it's better to ping some www.google.com instead of pinging ISP getaway
something like that:
delete
IP=/usr/bin/netstat -rn | /usr/bin/grep 'default' | /usr/bin/awk '{ print $2}'
/sbin/ping -c 2 $IP > /dev/null
and
write only
/sbin/ping -c 2 www.google.com > /dev/nullBut if it is ISP problem, then reboot does not help, so I've preffered to ping ISP getaway
xbipin
Have you tried new 2.1 builds already? My reconnection bug is gone completely.
[2.1-BETA0][root@pfhacom.xxxnetxxx]/root(1): mpd5 -v
Version 5.6 (root@base-8_3-i386.builders.pfsense.org 21:22 6-Aug-2012)
works great for me.
I am not sure about other things as it is BETA0 :)
At least you can try, don't forget to backup your config or do full backup.
Before update don't forget to select the update source in "System: Firmware: Updater Settings"
http://snapshots.pfsense.org/FreeBSD_RELENG_8_3/i386/pfSense_HEAD/.updaters
and check also
"Allow auto-update firmware images with a missing or invalid digital signature to be used." and
"After updating, sync with the following repository/branch before reboot." (branch: master and repository url: git://github.com/bsdperimeter/pfsense.git )Good luck :)
-
thanks w0w, actually the first script works which u gave earlier so ill stick to that for now, i was planning to move to 2.1 but problem is its too early for that as it seems there r still many bugs in the core system functionality so ill wait a bit its its more stable
things i need to work properly r
upnp
dhcp
static arp
traffic shaper
limiter
pppoe
openvpn client
accesspoint
aliases
NAT
firewall rules -
I hope stable release coming mid-October.
Currently
upnp - OK for me
dhcp - OK on LAN
static arp - OK
traffic shaper - fixed some time ago, OK
limiter - may be :)
pppoe - OK
openvpn client - don't know
accesspoint - don't know
aliases - OK
NAT - OK (IPV4)
firewall rules - OK -
im on 2.1 and the problem still persists, can u provide some patch like u did for 2.0.1
-
That's strange, xbipin, that the problem still persists.. try to add only
ifconfig em0 down
ifconfig em0 up
those to the ppp-linkdown and look what is happening
or just do the full modification similar to old version -
ill try the old patch u gave on this and let u know.
i dont think the mpd etc has changed from 2.0.1 to 2.1 thats y the problem persists
-
the old hack still works except some errors popup during boot saying itnerface vr1 not available or something like that but it connects eventually and even if i reset my isp modem or unplug cable etc still manages to connect within 3 mins
-
from 2.0.x to 2.1 there is changed freebsd version from 8.1 to 8.3 and mpd is also 5.6 compiled in august.
-
but still doesnt solve my issue
-
im running into the same issue here.
i just switched to pfSense to get WANFailover.
i have 2 WANs, 16MBit DSL and 50MBit VDSLafter initioal install everything is running right. For testing i powered off the VDSL Modem, Gateway is recognized as down, WAN Failover goes to DSL connection.
BUT after repowering the VDSL connection (Telekom) no automatic reconnect. Not even a manual reconnect. The Interface does not get any IP information, though the status is connected…
now i just run with my slow conenction.i tryed 386 and amd64 version and also 2.0.1 and 2.1
seeing that this issue exists for a long time now, i doubt that pfSense is the product of my choice. It looks very prommising, but essentials like the PPPoE connect just need to work properly!I hope that the Developers give it a fast try of fixing, so i can stay with this firewall/router distribution.
thx in advance
-
actually its not a pfsense issue but some incompatibility with mpd and the pppoe server by the isp which has some security feature enabled and it seems many isp run the same hardware thats y more ppl will have the same issue sooner or later.
u can try the first patch posted by wow as i use that and works as of now to fix it temporarily.
i wonder how the local routers in my region reconnect fine without issues, actually all of them, only pfsense has this issue
