Hi.
Michael MacLeod wrote:
On Jan 16, 2008 5:21 PM, Alexander Motin <[EMAIL PROTECTED]> wrote:
Mpd supports both. There were some mistakes in multilink transmission
part of ng_ppp kernel module working in splitting mode that in some
cases could lead to ineffective packet distribution, but they were fixed
8 months ago at 6-STABLE.
I updated my gateway using freebsd-update, and rebuilt my kernel after
making sure I had the latest sources. I proceeded to install mpd4 and
try out the configuration Nikos linked to. So far I haven't had any
success. I tried adding 'set bundle enable round-robin' since that's
how this is going to work on the download side of things, still
without success.
mpd.conf:
------------------------------------------------------------
startup:
set console ip 127.0.0.1
set console user username password
set console open
default:
load PPPoE
open
PPPoE:
new -i ng0 sam l0 l1
set auth authname [EMAIL PROTECTED]
set auth password password
set bundle enable multilink
set bundle enable round-robin
set iface idle 0
set iface route default
------------------------------------------------------------
This config is not completely correct for multilink case since
mpd-4.0rc1 due to changes:
- Auth configuration (set auth ...) moved from bundle layer to lcp. It
works per link now.
- Default argument of open/close commands changed from iface to lcp.
I would recommend you something like:
default:
new sam l0 l1
set bundle enable multilink
set bundle enable round-robin
set iface route default
link l0
set auth authname [EMAIL PROTECTED]
set auth password password
set link max-redial 0
open
link l1
set auth authname [EMAIL PROTECTED]
set auth password password
set link max-redial 0
open
and finally, the log file:
------------------------------------------------------------
Jan 19 16:34:26 gateway mpd: [l0] LCP: rec'd Configure Request #237 (Req-Sent)
Jan 19 16:34:26 gateway mpd: MRU 1492
Jan 19 16:34:26 gateway mpd: AUTHPROTO PAP
Jan 19 16:34:26 gateway mpd: MAGICNUM 4e7ea6a0
Your peer looks very interesting. The first thing it does is not
announcing multilink capabilities.
Jan 19 16:34:26 gateway mpd: [l0] LCP: rec'd Configure Reject #1 (Ack-Sent)
Jan 19 16:34:26 gateway mpd: MP MRRU 1600
Jan 19 16:34:26 gateway mpd: MP SHORTSEQ
Jan 19 16:34:26 gateway mpd: ENDPOINTDISC [802.1] 00 0e 0c dd 03 9b
Than it rejects mpd's multilink options negotiations.
Jan 19 16:34:26 gateway mpd: [l0] LCP: state change Ack-Sent --> Opened
Jan 19 16:34:26 gateway mpd: [l0] LCP: auth: peer wants PAP, I want nothing
Jan 19 16:34:26 gateway mpd: [l0] PAP: using authname "[EMAIL PROTECTED]"
Jan 19 16:34:26 gateway mpd: [l0] PAP: sending REQUEST len:33
Jan 19 16:34:26 gateway mpd: [l0] LCP: LayerUp
Jan 19 16:34:27 gateway mpd: [l0] LCP: rec'd Configure Request #0 (Opened)
Jan 19 16:34:27 gateway mpd: MRU 1492
Jan 19 16:34:27 gateway mpd: MP MRRU 32719
Jan 19 16:34:27 gateway mpd: ENDPOINTDISC [LOCAL] 34 36 30 37 32 31
30 30 39 34 00 00 00 00 00
Jan 19 16:34:27 gateway mpd: AUTHPROTO PAP
Jan 19 16:34:27 gateway mpd: MAGICNUM 5ec55af5
At this moment call probably passed from access concentrator (probably
LAC) to access server (probably LNS). LNS in difference to LAC advertise
miltilink support.
Jan 19 16:34:27 gateway mpd: [l0] LCP: LayerDown
Jan 19 16:34:27 gateway mpd: [l0] LCP: SendConfigReq #3
Jan 19 16:34:27 gateway mpd: PROTOCOMP
Jan 19 16:34:27 gateway mpd: MRU 1492
Jan 19 16:34:27 gateway mpd: MAGICNUM 6a64dffc
Jan 19 16:34:27 gateway mpd: [l0] LCP: SendConfigNak #0
Jan 19 16:34:27 gateway mpd: MP MRRU 1600
Jan 19 16:34:27 gateway mpd: [l0] LCP: state change Opened --> Req-Sent
Jan 19 16:34:27 gateway mpd: [l0] AUTH: Cleanup
Jan 19 16:34:27 gateway mpd: [l0] LCP: rec'd Configure Nak #3 (Req-Sent)
Jan 19 16:34:27 gateway mpd: MP MRRU 32719
Jan 19 16:34:27 gateway mpd: ENDPOINTDISC [NULL]
Jan 19 16:34:27 gateway mpd: [l0] LCP: SendConfigReq #4
Jan 19 16:34:27 gateway mpd: PROTOCOMP
Jan 19 16:34:27 gateway mpd: MRU 1492
Jan 19 16:34:27 gateway mpd: MAGICNUM 6a64dffc
After peer rejected multilink once, mpd is not trying to negotiate it
any more. I am not sure it is a correct behaviour, but Cisco manuals
recommend to configure LAC in a way that avoids rejections.
User-land ppp seems to have specific workaround for this case while mpd
does not. I don't very like this idea, but probably I could add this if
you like to test it.
Jan 19 16:34:27 gateway mpd: [l0] LCP: state change Ack-Sent --> Opened
Jan 19 16:34:27 gateway mpd: [l0] LCP: auth: peer wants PAP, I want nothing
Jan 19 16:34:27 gateway mpd: [l0] PAP: using authname "[EMAIL PROTECTED]"
Jan 19 16:34:27 gateway mpd: [l0] PAP: sending REQUEST len:33
Jan 19 16:34:27 gateway mpd: [l0] LCP: LayerUp
Jan 19 16:34:27 gateway mpd: [l0] LCP: rec'd Terminate Request #2 (Opened)
Why peer rejected you after second authentication without any reply is a
question to your provider.
Second link in your case even has not tried to connect.
--
Alexander Motin
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
