PPPoE reconenction fix - mpd fix ($100)

dhatz

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.

xbipin

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?

xbipin

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'

xbipin

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.

dhatz

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

xbipin

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?

dhatz

@xbipin:

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?

xbipin

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

w0w

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.

eri--

not really i backed off just other priorities first.

Sorry about that.

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-linkdown

ifconfig em0 down
ifconfig em0 up

And looks like reconnection bug is gone.
P.S. em0 is interface, where PPPoE is
P.P.S. I think it's related to driver.

xbipin

@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-linkdown

ifconfig em0 down
ifconfig em0 up

And 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

eri--

Certainly that will reset the device by doing up/down.
Just not a generic solution :)

w0w

@xbipin:

@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-linkdown

ifconfig em0 down
ifconfig em0 up

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

xbipin

how do we find out the device name?

marcelloc

@xbipin:

how do we find out the device name?

on status interface, you can see interface name and device.

WAN interface (em0)

xbipin

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?

w0w

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

xxxx.jpg_thumb

xxx2.jpg_thumb

xbipin

well then i see this

CropperCapture[1].jpg
CropperCapture[1].jpg_thumb

xbipin

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