Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    No automatic connect to ISP

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    91 Posts 14 Posters 35.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • E
      eri--
      last edited by

      It is something regarding your ISP that does not de-authenticate you correctly and something has changed in mpd to make it more strict on later versions.
      It needs more investigation and more time though i have not much as of now.

      Though you can take a packet trace and attach it here so i can follow later on.

      1 Reply Last reply Reply Quote 0
      • _
        _igor_
        last edited by

        ok, will do. Should I do it with the 2.0 or the 1.2.3? I think it should be tcpdump, but how should I do this? Looked around the man-page, but i don't understand it much.

        Should it be like this?

        tcpdump -i bge0 -n ether proto 0x8863 '||' ether proto 0x8864

        assuming that bge0 is my wan-interface.

        1 Reply Last reply Reply Quote 0
        • _
          _igor_
          last edited by

          ok, the tcpdump in the mentioned way only worked with pfSense 1.2.3, so for 2.0 I did 2 separate tcpdumps. Strange…
          Hope it helps.

          First I disconnected the wan-IF, auto-connect worked on 1.2.3, so no further things to do. Surfed around, disconnected some times.
          Same on 2.0, except the failing autoconnect. So I connected via Button, surfed, disconnected and connected several times.

          If you need more, tell me please.
          I zipped the files and attached .txt to upload it. Please remove the .txt to get the zip back.

          tcpdump.zip.txt

          1 Reply Last reply Reply Quote 0
          • A
            ambo
            last edited by

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

            1 Reply Last reply Reply Quote 0
            • ?
              Guest
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • N
                nocer
                last edited by

                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,

                1 Reply Last reply Reply Quote 0
                • _
                  _igor_
                  last edited by

                  Thanks much! I'll try it.

                  1 Reply Last reply Reply Quote 0
                  • M
                    Michael Sh.
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • _
                      _igor_
                      last edited by

                      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

                      1 Reply Last reply Reply Quote 0
                      • ?
                        Guest
                        last edited by

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

                        1 Reply Last reply Reply Quote 0
                        • _
                          _igor_
                          last edited by

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

                          1 Reply Last reply Reply Quote 0
                          • N
                            nocer
                            last edited by

                            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,

                            1 Reply Last reply Reply Quote 0
                            • ?
                              Guest
                              last edited by

                              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>

                              1 Reply Last reply Reply Quote 0
                              • ?
                                Guest
                                last edited by

                                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

                                1 Reply Last reply Reply Quote 0
                                • _
                                  _igor_
                                  last edited by

                                  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.

                                  1 Reply Last reply Reply Quote 0
                                  • jimpJ
                                    jimp Rebel Alliance Developer Netgate
                                    last edited by

                                    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.

                                    Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!

                                    Need help fast? Netgate Global Support!

                                    Do not Chat/PM for help!

                                    1 Reply Last reply Reply Quote 0
                                    • _
                                      _igor_
                                      last edited by

                                      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.

                                      1 Reply Last reply Reply Quote 0
                                      • M
                                        MegaV
                                        last edited by

                                        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.

                                        1 Reply Last reply Reply Quote 0
                                        • A
                                          antiben
                                          last edited by

                                          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

                                          1 Reply Last reply Reply Quote 0
                                          • _
                                            _igor_
                                            last edited by

                                            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.

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.