Navigation

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

    ADSL MLPPP help

    2.0-RC Snapshot Feedback and Problems - RETIRED
    7
    22
    7534
    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.
    • I
      itbit last edited by

      Hi,

      I'm currenlty using Tomato/MLPPP with my internet provider using 2 ADSL lines using PPPoe

      It works but it is not stable enough for my needs, so I started testing PfSense Version 2.0 on a P4 3.0 GHz to use it just a the multilink router.

      I have been reading around and as far as I understand everybody seems to be able to make it work without problems. Which makes me think that I'm missing something that is obvious

      The main thing that I can see in the system log under PPP is:

      ppp: [wan_link0] LCP: parameter negotiation failed
      ppp: [wan_link0] link did not validate in bundle
      ppp: [wan_link0] Can't join bundle wan without multilink negotiated.
      ppp: [wan_link0] LCP: authorization successful

      I followed up with my internet provider and they can see one connection been established and a second one been authorized but  disconnect and reconnects every second.

      As a consequence I have 1 link working, also my isp confirms that they do not see any mlppp in the link that is operational

      Attached are a copy of my PPP log and my mpd_wan.conf

      I have updated to the latest snapshot
      I have played with the bandwidth, mtu, mru
      I have disable vjcomp, tcpmssfix, shortseq, acfcomp and protocomp (individually and in different permutations of them)
      but the result are the same

      So I wonder if any body has an idea of what else I should try?.

      Thanks

      mpd_wan.conf.txt
      ppp.log.txt

      1 Reply Last reply Reply Quote 0
      • E
        eri-- last edited by

        You need 2 different accounts to authenticate differently for each link.
        So tell your ISP to give you a different account for each link that should fix your multilink issue.

        1 Reply Last reply Reply Quote 0
        • I
          itbit last edited by

          Hi ermal,

          Thanks for the reply, I have tried that, with no luck. :'(

          I got two accounts from my provider and each account will provide me with a different IP address

          I have pppoe0 assinged to the WAN
          If I set pppoe0 with account1
          and OPT1 with account2
          and then I set pppoe0 (xl1, OPT1) it only tries to connect using the account assigned to pppoe0

          Also I've been doing all this through the GUI and the page for editing the PPPoE link (https://pfsense2/interfaces_ppps_edit.php?id=0)
          only has the space for one username and password.

          should there be another path that I shoudl take to do this?

          Thanks

          1 Reply Last reply Reply Quote 0
          • C
            clarknova last edited by

            @ermal:

            You need 2 different accounts to authenticate differently for each link.
            So tell your ISP to give you a different account for each link that should fix your multilink issue.

            Not with my provider (Teksavvy).

            If yours is like mine, you first need to go into http://pfsense/interfaces_ppps.php (Interfaces>(assign)>PPPs) and use the ctrl key to select the member interfaces. Save changes and go to /interfaces_assign.php (Interfaces>(assign)>Interface Assignments) and choose the PPPOE0 virtual interface you just created as your WAN interface. Save and apply.

            It's slightly more complicated if you're using vlans for your modem interfaces, so post back if that's what you're attempting.

            Otherwise post back to let us know if you get this working.

            db

            1 Reply Last reply Reply Quote 0
            • I
              itbit last edited by

              Hi clarknova,

              That is exactly how I did it:
              "
              If yours is like mine, you first need to go into http://pfsense/interfaces_ppps.php (Interfaces>(assign)>PPPs) and use the ctrl key to select the member interfaces. Save changes and go to /interfaces_assign.php (Interfaces>(assign)>Interface Assignments) and choose the PPPOE0 virtual interface you just created as your WAN interface. Save and apply.
              "
              But no luck :(
              the message that I see all the time in the log is

              ppp: [wan_link0] LCP: parameter negotiation failed
              ppp: [wan_link0] link did not validate in bundle
              ppp: [wan_link0] Can't join bundle wan without multilink negotiated.
              ppp: [wan_link0] LCP: authorization successful

              Does anybody know how the multilink negotiation works?

              As far as I know from my ISP which provided me a tomato/mlppp router they set it up with one account and it is pretty much plug and play
              and everytime I plug the tomato/mlppp back it works, so I think on their side it seems to be configured properly.

              that is why I'm thinking that somhow I'm missing a setting somewhere.

              any other ideas?

              Thanks

              1 Reply Last reply Reply Quote 0
              • C
                clarknova last edited by

                Your mpd_wan.conf looks like mine, except I don't use these options:

                set link no shortseq

                set link no acfcomp

                set link no protocomp

                Have you tried unsetting them?

                db

                1 Reply Last reply Reply Quote 0
                • I
                  itbit last edited by

                  Hi clarknova,

                  yeap i tried that too :(

                  I also just updated it to todays snapshot
                  2.0-BETA4
                  built on Sat Aug 7 04:21:34 EDT 2010

                  But the log still says the same but this time wan_link0 is the one connected and wan_link1 is trying to connect:

                  Aug 7 10:24:36 ppp: [wan_link1] Link: reconnection attempt 107 in 2 seconds
                  Aug 7 10:24:36 ppp: [wan_link1] LCP: LayerStart
                  Aug 7 10:24:36 ppp: [wan_link1] LCP: state change Stopped –> Starting
                  Aug 7 10:24:36 ppp: [wan_link1] LCP: Down event
                  Aug 7 10:24:36 ppp: [wan_link1] Link: DOWN event
                  Aug 7 10:24:36 ppp: [wan_link1] PPPoE: connection closed
                  Aug 7 10:24:36 ppp: [wan_link1] LCP: LayerFinish
                  Aug 7 10:24:36 ppp: [wan_link1] LCP: state change Stopping –> Stopped
                  Aug 7 10:24:36 ppp: [wan_link1] LCP: rec'd Terminate Ack #172 (Stopping)
                  Aug 7 10:24:36 ppp: [wan_link1] rec'd proto IPCP during terminate phase
                  Aug 7 10:24:36 ppp: [wan_link1] LCP: LayerDown
                  Aug 7 10:24:36 ppp: [wan_link1] LCP: SendTerminateReq #172
                  Aug 7 10:24:36 ppp: [wan_link1] LCP: state change Opened –> Stopping
                  Aug 7 10:24:36 ppp: [wan_link1] LCP: parameter negotiation failed
                  Aug 7 10:24:36 ppp: [wan_link1] link did not validate in bundle
                  Aug 7 10:24:36 ppp: [wan_link1] Can't join bundle wan without multilink negotiated.
                  Aug 7 10:24:36 ppp: [wan_link1] LCP: authorization successful
                  Aug 7 10:24:36 ppp: [wan_link1] CHAP: rec'd SUCCESS #161 len: 4
                  Aug 7 10:24:36 ppp: [wan_link1] CHAP: sending RESPONSE #161 len: 57

                  Any more ideas?

                  Thanks

                  1 Reply Last reply Reply Quote 0
                  • C
                    clarknova last edited by

                    I'm stumped. Maybe you could post screenshots of your PPPs page with the personal info obscured?

                    db

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

                      I am having this same problem. I work for an ISP in ontario that offers multilink ( NetAccess ). Normally, we would use a Cisco Router ( 1811 ) or I would use Zeroshell or Tomato. Those work fine. In pfSense the link never bundles.

                      Here is the log from pfSense:

                      Aug 7 23:01:56 	ppp: [wan_link0] PROTOCOMP
Aug 7 23:01:56 	ppp: [wan_link0] MRU 1492
Aug 7 23:01:56 	ppp: [wan_link0] MAGICNUM 313231ec
Aug 7 23:01:56 	ppp: [wan_link0] LCP: rec'd Configure Reject #8 (Ack-Sent)
Aug 7 23:01:56 	ppp: [wan_link0] MRU 1492
Aug 7 23:01:56 	ppp: [wan_link0] LCP: SendConfigReq #9
Aug 7 23:01:56 	ppp: [wan_link0] PROTOCOMP
Aug 7 23:01:56 	ppp: [wan_link0] MAGICNUM 313231ec
Aug 7 23:01:56 	ppp: [wan_link0] LCP: rec'd Configure Ack #9 (Ack-Sent)
Aug 7 23:01:56 	ppp: [wan_link0] PROTOCOMP
Aug 7 23:01:56 	ppp: [wan_link0] MAGICNUM 313231ec
Aug 7 23:01:56 	ppp: [wan_link0] LCP: state change Ack-Sent --> Opened
Aug 7 23:01:56 	ppp: [wan_link0] LCP: auth: peer wants PAP, I want nothing
Aug 7 23:01:56 	ppp: [wan_link0] PAP: using authname "abuttonadsl@nas.net"
Aug 7 23:01:56 	ppp: [wan_link0] PAP: sending REQUEST #1 len: 33
Aug 7 23:01:56 	ppp: [wan_link0] LCP: LayerUp
Aug 7 23:01:58 	ppp: [wan_link0] PAP: using authname "abuttonadsl@nas.net"
Aug 7 23:01:58 	ppp: [wan_link0] PAP: sending REQUEST #2 len: 33
Aug 7 23:02:00 	ppp: [wan_link0] PAP: using authname "abuttonadsl@nas.net"
Aug 7 23:02:00 	ppp: [wan_link0] PAP: sending REQUEST #3 len: 33
Aug 7 23:02:02 	ppp: [wan_link0] PAP: using authname "abuttonadsl@nas.net"
Aug 7 23:02:02 	ppp: [wan_link0] PAP: sending REQUEST #4 len: 33
Aug 7 23:02:04 	ppp: [wan_link0] PAP: using authname "abuttonadsl@nas.net"
Aug 7 23:02:04 	ppp: [wan_link0] PAP: sending REQUEST #5 len: 33
Aug 7 23:02:10 	ppp: [wan_link0] PAP: rec'd ACK #5 len: 5
Aug 7 23:02:10 	ppp: [wan_link0] LCP: authorization successful
Aug 7 23:02:10 	ppp: [wan_link0] Can't join bundle wan without multilink negotiated.
Aug 7 23:02:10 	ppp: [wan_link0] link did not validate in bundle
Aug 7 23:02:10 	ppp: [wan_link0] LCP: parameter negotiation failed
Aug 7 23:02:10 	ppp: [wan_link0] LCP: state change Opened --> Stopping
Aug 7 23:02:10 	ppp: [wan_link0] LCP: SendTerminateReq #10
Aug 7 23:02:10 	ppp: [wan_link0] LCP: LayerDown
Aug 7 23:02:10 	ppp: [wan_link0] rec'd proto IPCP during terminate phase
Aug 7 23:02:10 	ppp: [wan_link0] LCP: rec'd Terminate Ack #10 (Stopping)
Aug 7 23:02:10 	ppp: [wan_link0] LCP: state change Stopping --> Stopped
Aug 7 23:02:10 	ppp: [wan_link0] LCP: LayerFinish
Aug 7 23:02:10 	ppp: [wan_link0] PPPoE: connection closed
Aug 7 23:02:10 	ppp: [wan_link0] Link: DOWN event
Aug 7 23:02:10 	ppp: [wan_link0] LCP: Down event
Aug 7 23:02:10 	ppp: [wan_link0] LCP: state change Stopped --> Starting
Aug 7 23:02:10 	ppp: [wan_link0] LCP: LayerStart
Aug 7 23:02:10 	ppp: [wan_link0] Link: reconnection attempt 3 in 4 seconds
Aug 7 23:02:14 	ppp: [wan_link0] Link: reconnection attempt 3
Aug 7 23:02:14 	ppp: [wan_link0] PPPoE: Connecting to '*'
Aug 7 23:02:23 	ppp: [wan_link0] PPPoE connection timeout after 9 seconds
Aug 7 23:02:23 	ppp: [wan_link0] Link: DOWN event
Aug 7 23:02:23 	ppp: [wan_link0] LCP: Down event
Aug 7 23:02:23 	ppp: [wan_link0] Link: reconnection attempt 4 in 1 seconds
Aug 7 23:02:24 	ppp: [wan_link0] Link: reconnection attempt 4
Aug 7 23:02:24 	ppp: [wan_link0] PPPoE: Connecting to '*'

                      Here is my config page:

                      And here are the radius logs from our side:

                      Sat Aug  7 11:31:05 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 243 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:4881:3785:33b428)
Sat Aug  7 11:31:05 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 11:47:35 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 2091 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:4fd2:23cf:33b489)
Sat Aug  7 11:47:35 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 11:52:43 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 1175 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:70f5:3419:33b4a2)
Sat Aug  7 11:52:43 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 11:57:49 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 1115 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:2361:43bd:33b4bf)
Sat Aug  7 11:57:49 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 12:02:54 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 1586 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:b17:2b46:33b4d8)
Sat Aug  7 12:02:54 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 12:13:42 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 1022 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:4ea7:23ae:33b509)
Sat Aug  7 12:13:42 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 12:18:49 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 682 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:4095:7af:33b529)
Sat Aug  7 12:18:49 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 12:23:55 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 2348 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:37a2:1316:33b545)
Sat Aug  7 12:23:55 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 12:29:07 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 500 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:53d8:d4d:33b560)
Sat Aug  7 12:29:07 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 12:34:15 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 1516 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:68fa:34ed:33b57c)
Sat Aug  7 12:34:15 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 12:39:21 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 897 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:694f:37d6:33b5a0)
Sat Aug  7 12:39:21 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 12:44:30 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 860 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:526b:3af5:33b5ca)
Sat Aug  7 12:44:30 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 12:54:52 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 218 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:6ed3:f05:33b610)
Sat Aug  7 12:54:52 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 13:00:01 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 2266 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:7571:1f3d:33b637)
Sat Aug  7 13:00:01 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 13:10:50 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 2184 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:6dbf:4071:33b67d)
Sat Aug  7 13:10:50 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 13:15:56 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 1356 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:6637:33d5:33b698)
Sat Aug  7 13:15:56 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 13:21:03 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 1863 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:ebe:4478:33b6b8)
Sat Aug  7 13:21:03 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 13:31:51 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 1191 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:7942:43d7:33b6fe)
Sat Aug  7 13:31:51 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 13:47:56 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 612 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:2bd2:3f0e:33b761)
Sat Aug  7 13:47:56 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 14:04:26 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 264 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:3c6b:efa:33b7c2)
Sat Aug  7 14:04:26 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 14:09:37 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 1459 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:84f1:2a3d:33b7dd)
Sat Aug  7 14:09:37 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 14:14:43 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 2101 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:8561:191e:33b7f7)
Sat Aug  7 14:14:43 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 14:31:21 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 1749 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:139d:34fc:33b852)
Sat Aug  7 14:31:21 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 14:42:11 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 77 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:5970:8ed:33b888)
Sat Aug  7 14:42:11 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 14:47:19 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 1805 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:41bc:3004:33b8a0)
Sat Aug  7 14:47:19 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 14:52:24 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 1869 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:566a:1b4c:33b8bc)
Sat Aug  7 14:52:24 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 14:57:31 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 2105 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:4b94:42c9:33b8d7)
Sat Aug  7 14:57:31 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 15:02:39 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 2058 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:6a65:1709:33b8f2)
Sat Aug  7 15:02:39 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 15:13:28 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 2146 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:647f:211b:33b925)
Sat Aug  7 15:13:28 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 15:41:25 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 48 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:28a0:3b84:33b9be)
Sat Aug  7 15:41:25 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 15:46:32 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 2426 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:8801:1ef9:33b9d2)
Sat Aug  7 15:46:32 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 15:57:19 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 1427 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:108f:16b9:33ba09)
Sat Aug  7 15:57:19 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 16:13:54 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 1950 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:8741:1f74:33ba76)
Sat Aug  7 16:13:54 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 16:30:03 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 2277 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:3b9:29b7:33bae0)
Sat Aug  7 16:30:03 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 16:40:17 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 112 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:1b42:20c5:33bb1a)
Sat Aug  7 16:40:17 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 16:51:05 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 1727 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:5191:184b:33bb52)
Sat Aug  7 16:51:05 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 17:01:45 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 2247 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:853f:4283:33bb90)
Sat Aug  7 17:01:45 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 17:12:35 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 2285 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:1017:2495:33bbca)
Sat Aug  7 17:12:35 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 17:22:59 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 1118 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:6950:3417:33bc00)
Sat Aug  7 17:22:59 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 17:39:32 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 649 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:6add:16c6:33bc70)
Sat Aug  7 17:39:32 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 17:44:44 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 332 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:7e13:1380:33bc8b)
Sat Aug  7 17:44:44 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 18:01:19 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 2342 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:75c7:1da7:33bce6)
Sat Aug  7 18:01:19 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 18:23:41 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 571 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:645a:3b5b:33bd78)
Sat Aug  7 18:23:41 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 18:40:17 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 141 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:4dd4:3fe7:33bddf)
Sat Aug  7 18:40:17 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 18:51:09 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 2319 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:2677:1df5:33be12)
Sat Aug  7 18:51:09 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 19:01:41 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 845 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:4446:f20:33be4c)
Sat Aug  7 19:02:10 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 910 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:3a58:2321:33be4d)
Sat Aug  7 19:02:10 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 19:07:16 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 1475 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:35ff:160d:33be65)
Sat Aug  7 19:07:16 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 19:12:24 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 670 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:4cb:20d8:33be7c)
Sat Aug  7 19:12:24 2010 : Error: rlm_sql (sql) in sql_accounting: stop packet with zero session length. [user 'abuttonadsl@nas.net', nas '216.145.97.1']
Sat Aug  7 19:13:47 2010 : Auth: Login OK: [abuttonadsl@nas.net] (from client heh port 2217 cli ip:64.230.198.28:64.230.196.21:a2b:2fdc:299c:18c6:33be82)
                      1 Reply Last reply Reply Quote 0
                      • N
                        nybble last edited by

                        I second that, Same ISP as allanbutton, Same problem.

                        1 Reply Last reply Reply Quote 0
                        • I
                          itbit last edited by

                          Hi Clarnova,

                          I'm attaching a screen shot of my inteface assigment,
                          my PPPs edit page looks just like the one from allanbutton

                          Thanks,


                          1 Reply Last reply Reply Quote 0
                          • C
                            clarknova last edited by

                            Well, everything looks correct to my limited knowledge. I wish I knew more about troubleshooting pppoe issues, but mine has always just worked, fortunately for me.

                            There are some on this forum who know vastly more about it than I do. You may want to PM gnhb and point him to this thread if he doesn't chime in in the next few days.

                            db

                            1 Reply Last reply Reply Quote 0
                            • G
                              gnhb last edited by

                              Hi Guys,
                              Well, I'm not sure what's happening here. As you may know, pfSense is using the mpd5 application for PPP (MLPPP), PPPoE, PPtP and L2tP connections, so the mpd-5.5 code is the issue here. I didn't write that code, so my ability to help is limited. However, I search for the error message text in the mpd-5.5 source code. This is in the mpd-5.5/src/bund.c file.

                              
	  if (b->n_up > 0 &&
	  (b->peer_mrru == 0 || lcp->peer_mrru == 0 || lcp->want_mrru == 0)) {
    	    Log(LG_BUND, ("[%s] Can't join bundle %s without "
		"multilink negotiated.", l->name, b->name));
	    return (0);
	}

                              It looks like the issue has to do with the mrru negotiation. I didn't expose the MRRU as a setting in the pfSense UI, so the negotiation is all going on behind the scenes. I also found this http://www.dslreports.com/forum/r21715415-FreeBSD-and-the-latest-MLPPP-issues which is also talking about difficulties with the mrru negotiation, but the error is slightly different.

                              Maybe the problem is the same as what they are seeing in the link above. Essentially, mpd5 won't allow MRRU less than 1500 and your ISP is trying to set MRRU less than 1500.

                              elsewhere in mpd-5.5/src/bund.c

                              
	/* Configure the bundle */
	b->pppConfig.bund.enableMultilink = (lcp->peer_mrru && lcp->want_mrru)?1:0;
	/* ng_ppp does not allow MRRU less then 1500 bytes. */
	b->pppConfig.bund.mrru = (lcp->peer_mrru < 1500) ? 1500 : lcp->peer_mrru;
	b->pppConfig.bund.xmitShortSeq = lcp->peer_shortseq;
	b->pppConfig.bund.recvShortSeq = lcp->want_shortseq;
	b->pppConfig.bund.enableRoundRobin =
    	    Enabled(&b->conf.options, BUND_CONF_ROUNDROBIN);

                              A second possibility is shown here: (These logs are in reverse order; oldest on bottom)
                              Aug 3 11:34:27 ppp: [wan_link0] ENDPOINTDISC [802.1] 00 0c f1 97 15 66
                              Aug 3 11:34:27 ppp: [wan_link0] MP SHORTSEQ
                              Aug 3 11:34:27 ppp: [wan_link0] MP MRRU 2048
                              Aug 3 11:34:27 ppp: [wan_link0] LCP: rec'd Configure Reject #185 (Ack-Sent)
                              Aug 3 11:34:27 ppp: [wan_link0] LCP: state change Req-Sent –> Ack-Sent
                              Aug 3 11:34:27 ppp: [wan_link0] MAGICNUM 58920e14
                              Aug 3 11:34:27 ppp: [wan_link0] AUTHPROTO CHAP MD5
                              Aug 3 11:34:27 ppp: [wan_link0] MRU 1492
                              Aug 3 11:34:27 ppp: [wan_link0] LCP: SendConfigAck #164
                              Aug 3 11:34:27 ppp: [wan_link0] MAGICNUM 58920e14
                              Aug 3 11:34:27 ppp: [wan_link0] AUTHPROTO CHAP MD5
                              Aug 3 11:34:27 ppp: [wan_link0] MRU 1492
                              Aug 3 11:34:27 ppp: [wan_link0] LCP: rec'd Configure Request #164 (Req-Sent)

                              The ISP is rejecting SHORTSEQ and the requested MRRU value of 2048 in the third, fourth and fifth lines from the top of the log, but the ISP is not requesting an alternate MRRU value, so it looks like the MRRU negotiation is just dropped, leaving mpd5 with all MRRU values set to 0, and thus the error.

                              Please get confirmation from the ISP(s) about what MRRU value they are requesting for the link. If it's less than 1500, there's your problem.
                              If their MLPPP implementation is rejecting pfSense's MRRU value but isn't offering an MRRU value in the negotiation, then that causes a problem for mpd5. Just find out what their MRRU value they are assuming for the link if their PPP code isn't requesting one in the negotiation.

                              It looks like we might need to expose the MRRU setting in the GUI, and possibly also patch the mpd5 source (which Ermal can do) to allow MRRU values less than 1500.

                              Please get info from the ISP first.

                              Thanks,
                              GB

                              1 Reply Last reply Reply Quote 0
                              • E
                                eri-- last edited by

                                AFAIK it does not make sense to have MRRU less than mru!

                                From Mpd manual:

                                The set link mtu command sets the maximum transmit unit (MTU) value for the link. This is the size of the largest single PPP frame (minus PPP header) that this link will transmit, unless the peer requests an even lower value. The default value is 1500 bytes.

                                The set link mru command sets maximum receive unit (MRU) value for the link, which is the size of the largest single PPP frame (minus PPP header) that this link is capable of receiving. The default value is 1500 bytes.

                                If PPP multilink is negotiated on a link, then these values are less important, because multilink allows PPP frames themselves to be fragmented, so a PPP frame up to MRRU bytes can always pass through no matter how small the MTU is in a particular direction.

                                Probably try forcing your MRU to 1500 bytes and try again. After all that is the whole point of MLPPP.
                                Though it seems like you need to provide a MRRU value in config.

                                1 Reply Last reply Reply Quote 0
                                • I
                                  itbit last edited by

                                  I followed up with my ISP

                                  MRRU is negotiated first at 2048
                                  and later on negotiated and accepted at 1524

                                  MTU is done at 1492

                                  I have attempted to set MTU at 1500 but the problem stayed to be the same

                                  So I wonder if the MRRU of 1524 too low or failing somewhere else.

                                  Any Ideas?

                                  Thanks

                                  1 Reply Last reply Reply Quote 0
                                  • E
                                    eri-- last edited by

                                    try setting MRU to 1500 not MTU to 1500!

                                    1 Reply Last reply Reply Quote 0
                                    • I
                                      itbit last edited by

                                      Hi ermal,

                                      I'm sorry it was a typo, what I meant was

                                      MRRU is negotiated first at 2048
                                      and later on negotiated and accepted at 1524

                                      MRU is done at 1492

                                      I have attempted to set MRU at 1500 but the problem stayed to be the same

                                      1 Reply Last reply Reply Quote 0
                                      • E
                                        eri-- last edited by

                                        I belive you should ask the ISP what those values should be.
                                        And enter them in your config for testing. For MRRU you have to edit the file manually i think.

                                        1 Reply Last reply Reply Quote 0
                                        • G
                                          gnhb last edited by

                                          I just made two commits to the source tree, so future builds should have these features.

                                          1. MRRU is exposed in the GUI so you can set it there now.

                                          2. If you copy the mpd_wan.conf (or mpd_optX.conf) file generated by pfSense from the /var/etc/ directory on the pfSense box to the /conf directory (keeping the SAME file name), you can tweak that file manually and pfSense will use it for the link configuration instead of what's stored in the pfSense configuration data (config.xml). So you can massage it (in /conf ) as much as you want, and then just delete it when you're done with it.

                                          GB

                                          1 Reply Last reply Reply Quote 0
                                          • G
                                            gnhb last edited by

                                            Where are we with this? Any improvements, changes, or more testing?

                                            GB

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

                                              Hi gnhb,
                                              I'm going to give this a try over the weekend. I will let you know.
                                              Thanks!

                                              1 Reply Last reply Reply Quote 0
                                              • V
                                                valunthar last edited by

                                                Would the procedure mentioned earlier in this thread be applicable for setting up single link MLPPP as well?

                                                1 Reply Last reply Reply Quote 0
                                                • First post
                                                  Last post

                                                Products

                                                • Platform Overview
                                                • TNSR
                                                • pfSense
                                                • Appliances

                                                Services

                                                • Training
                                                • Professional Services

                                                Support

                                                • Subscription Plans
                                                • Contact Support
                                                • Product Lifecycle
                                                • Documentation

                                                News

                                                • Media Coverage
                                                • Press
                                                • Events

                                                Resources

                                                • Blog
                                                • FAQ
                                                • Find a Partner
                                                • Resource Library
                                                • Security Information

                                                Company

                                                • About Us
                                                • Careers
                                                • Partners
                                                • Contact Us
                                                • Legal
                                                Our Mission

                                                We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                                                Subscribe to our Newsletter

                                                Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                                                © 2021 Rubicon Communications, LLC | Privacy Policy