No automatic connect to ISP

ambo

@ermal:

something has changed in mpd to make it more strict on later versions

It seems to me that mpd stops reconnecting when it experiences a connect fail or auth fail. Can't say whether this is a feature or a bug but it is definitely a problem.

Even a connection that has auth failed should be retried periodically since the reason for the failure can go away and one would expect pfSense to recover from this within a reasonable time and without intervention.

I have a similar problem, PPOe disconnects every day, and don't connect back again automatically, I have to do it manually, with version 1.2.3 and previous this work perfectly, if ppoe disconnects for any reason it reconnects automatically.

nocer

Hi.

I've no clue how it was done in 1.2.x but just wondering if you guys force mpd to re-establish a connection by adding "set bundle no noretry" into appropriate section of your interfaces.inc. This will force mpd to re-connect whenever the keep-alive expires. Or sit tight and wait for it'd be fixed eventually in any later builds…

cheers,

_igor_

Thanks much! I'll try it.

Michael Sh.

This problem not only for PPoE.
I use separate PPTP mpd client connection. After linkdown sometimes reconnect sucsessful, but many times not.
Additional:
1. Cannot set MTU for PPTP link.
2. Static routes for PPTP link not activating after link down/up.

_igor_

It doesn't work. As I can see, mpd dies when a disconnect occurs. Logs show this: (reverse order)

Jan 17 19:58:47 mpd:
Jan 17 19:58:47 mpd: Multi-link PPP daemon for FreeBSD
Jan 17 19:58:46 mpd: process 37549 terminated
Jan 17 19:58:44 mpd: caught fatal signal term
Jan 17 19:57:41 last message repeated 7 times

cat /var/etc/mpd_wan.conf
startup:
pppoeclient:
new -i pppoe0 pppoeclient pppoeclient
set iface route default
set iface enable on-demand
set iface idle 0
set iface enable tcpmssfix
set iface up-script /usr/local/sbin/ppp-linkup
set iface down-script /usr/local/sbin/ppp-linkdown
set iface addrs 192.0.2.112 192.0.2.113
set bundle disable multilink
set bundle no noretry
set auth authname "xxx"
set auth password "yyy"
set link keep-alive 10 60
set link max-redial 0
set link no acfcomp protocomp
set link disable pap chap
set link accept chap
set link mtu 1492
set ipcp yes vjcomp
set ipcp ranges 0.0.0.0/0 0.0.0.0/0
set ipcp enable req-pri-dns
set ipcp enable req-sec-dns
open

¿Any news about this?

I'm working with latest version, 2.0-BETA1 built on Fri Jan 22 00:26:29 EST 2010, and this problem persists, every morning I've to manually connect to my ISP.

_igor_

Does the option "set bundle no noretry" help? Did you try it?

nocer

Hi,

Again I have no clue about 1.2.x but auto-reconnect just works fine for me with;

set link max-redial 0
set bundle no noretry
(set link keep-alive 5 15) <- 10 60 is way too loooooooong to me

into my mpd.conf, just to clarify, I tested this by disconnecting utp to the modem, wait 'till keep-alive expired
then connect the utp to the modem again, link re-established again. Need to flush routing table some times.
Any chances to try on-demand mode instead if you've outgoing traffic constantly.

It's about to consider moving to mpd5 since it's been there for a while and quite stable for now…

cheers,

Thanks for your comments, I did it yesterday, adding the "set bundle no noretry" and it seems to be working:

$mpdconf .= << <eod<br>set bundle disable multilink
set auth authname "{$wancfg['pppoe_username']}"
set auth password "{$wancfg['pppoe_password']}"
set bundle no noretry
set link keep-alive 10 60
set link max-redial 0
set link no acfcomp protocomp
set link disable pap chap
set link accept chap

If it's fails again I will try with "set link keep-alive 5 15"

Thanks</eod<br>

It fails again, so I'll try with, "set link keep-alive 5 15"

Besides I update to latest version (2.0-BETA1 built on Mon Jan 25 20:57:42 EST 2010)
The modifications goes away with firmware updates, so I've to re-write these modifications.

Regards
Alfredo

_igor_

In my case none of the otions work. Connection fails every several hours. Its a really awful thing. Its beginning to drive me a bit crazy. I'm thinking that the whole thing fails because of routing. There is a default route to ISP-IP, but the whole thing looks a bit strange to me:


default	               195.14.226.7	UGS	0	42483	        1492	        pppoe0	 
10.0.0.0/27	        link#3	        U	8	248149868	1500	        bge1	 
10.0.0.1	                link#3	        UHS	0	1068827	        16384	lo0	 
10.0.0.32	                link#9	        UHS	0	0	                16384	lo0	=>
10.0.0.32/29      	link#9	        U	0	0	                1500	        ral0_wlan0	 
87.78.x.y	                link#8	        UHS	0	0	                16384	lo0	 
127.0.0.1             	link#4	        UH	0	4289065	        16384	lo0	 
127.0.0.2	                127.0.0.1	        UHS	0	1068827	        16384	lo0	 
195.14.226.7      	link#8	        UH	0	0	                1492 	pppoe0

Where is the use of Link 8? Transfer 0 byte? Both related to my ISP! No use of the links. And last but not least, on dashboard my WAN-gateway is stuck on "Gathering data". Apart from the fact that the whole routing seems to be on heavy construction. Therre was a time when I could change things in the routing, but since a time I cannot do anythiong there, only errors appear there. Maybe I'm wrong, but it looks a bit strange to me.

jimp

I'm in a rather unique situation to test this repeatedly, as I control both ends of the PPPoE link I have a test box hooked to. I have a 2.0 test box sitting on my test PPPoE DSL line at work and I also control the router on the other end of the link, so I can boot it at will.

I did confirm (as others have seen) that not only does PPPoE not reconnect, if the interface is unplugged at boot time, it doesn't try to connect initially either.

If I use "set bundle no noretry" it falls into a loop where it just constantly tries to connect after making a good PPPoE link. I see it authenticate on the ISP end and MPD immediately says the link has gone and tries to redial. The keep alive settings made no difference.

If I get some more time tomorrow at work I'll try to tinker with this, but it may have to wait for the weekend.

_igor_

This are great news! The "set bundle no noretry" doesn't help. Same as before. :-( But I'll wait and then try with a new install. Maybe that helps.

MegaV

For me the same problem. Here my subject :http://forum.pfsense.org/index.php/topic,22145.0.html
Correction mpd_wan.conf has not helped.
The problem what is not right enough for MPD for change of a configuration of interfaces can?
Excuse for bad English language, I badly know it.

antiben

in pfsense 1.2.3 the wan/pppoe mpd.conf has the "no noretry" option set.
in pfsense 2.0 it's not set…

1.2.3 uses freebsd's mpd version 3.18 and
2.0 uses mpd version 4.4.1, so it's mpd related?? (guess not)

@jimp:

…
If I use "set bundle no noretry" it falls into a loop where it just constantly tries to connect after making a good PPPoE link. I see it authenticate on the ISP end and MPD immediately says the link has gone and tries to redial. The keep alive settings made no difference.
...

as the6thday wrote: it's pretty much unusable (for most german dsl users) :/

but i have some hopes. (or at least a workaround…)
i never tried freebsd / monowall or pfsense before, so prepare that i may have a lot of questions.

i first started with a 2.0b live cd, got the reconnection problem and soon got into this sub-forum.
i now have 1.2.3 upgraded to 2.0b (so old binaries (like mpd) are still on the partition) and done some modifications for testing...

but more on this after my next reconnect g

sorry for this german/english
// edit - fix url typo, cut off quote

_igor_

Same thing happend to me too, but not everytime. So sometimes it was in a loop getting indefinitely a new IP. Pressing the "connect"-button established the connection.
But afterwards I had/have to call the DynDNS-page and save to actualize the DynDNS-IP. rc.newwanIP was never called upon manual connect.

Yesterday I did a complete new install because mpd died before and never "woke up" again. So I think, something broke up in my installation. mpd died instantly.
Will see if now things are better.

Update: After the fresh install I see that adding an external DNS-server results in the fact that my ISPs DNS-servers are not settled. No internet-activity possible. Even pfSense is not able to find updates. So only the external DNS is set. Deleting this DNS-entry results in an instantly added ISP-DNS and my Internet-connection works. pfSense finds its updates too.

Looking in the logs I see after restart of pfSense 3 attempts to connect to my ISP Then the log spits out this:
php: : The command 'fetch -o /dev/null -q https://localhost:443/preload.php' returned exit code '1', the output was 'fetch: https://localhost:443/preload.php: Unknown error: 0'.
That was it. I will try to add the "no noretry"-option.
When I manually connect I get the mentioned failings. Here mpd dies but restarts again (reverse order):

mpd: Multi-link PPP daemon for FreeBSD
Feb 19 11:07:37 mpd: process 6494 terminated
Feb 19 11:07:35 mpd: caught fatal signal term
Feb 19 11:07:27 php: : Could not find gateway for interface(wan).

I will keep you updated.

antiben

hi igor,

what do you mean by 'not everytime.' ?

for nocer and afrugone it seems to work, so i tried the "no noretry" bundle option on mpd 4.4.1 some days ago,
but like jimp and you wrote: it falls into a loop… fortunately i saw the loop 2 minutes later g

currently i'm writing with my new wan-pppoe ip - no need to manual reconnect for now. but here is the catch,
my pfsense 2.0 runs the old mpd 3.18 with the ng networking subsystem.
and here is a first quick freebsd question:
what / where are the diffs between ng0 (mpd3) and pppoe0 (mpd4)?

dyndns upate seems to work… but dnsmasq was invoked later, so that may be another order issue...
luckily i have the same dns(s) like yesterday, (as per mpd: they are really the same), so dyndns was successfully...

i may setup and try mpd 4.4.1 with my modifications...
why has the "no noretry" option been removed from the pppoe interface.inc section?

ps: after i saw the preload file, i understood the unknown error from fetch g
(joke, i know the preload.php exists longer… but that's not nice for the php interpreter)

_igor_

The loop only 2 or 3 times. Mostly not. Due to the spare times it looped I didn't think to mention it. Difficult to fix something like this.

Only to clarify, for me is not working perfectly, is better, but after some days (about a week) I get the same problem, and I have to manully reconnect