From owner-freebsd-net@FreeBSD.ORG Sat Jan 19 22:23:23 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A235616A418 for ; Sat, 19 Jan 2008 22:23:23 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id DF7FD13C4D9 for ; Sat, 19 Jan 2008 22:23:22 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona 1.7.0 Received: from [212.86.226.226] (account mav@alkar.net HELO [192.168.3.2]) by cmail.optima.ua (CommuniGate Pro SMTP 5.1.14) with ESMTPA id 66686341; Sun, 20 Jan 2008 00:23:21 +0200 Message-ID: <47927858.4050702@FreeBSD.org> Date: Sun, 20 Jan 2008 00:23:20 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Michael MacLeod References: <1200479046.00010232.1200466203@10.7.7.3> <1200479105.00010249.1200468002@10.7.7.3> <1200482587.00010258.1200469801@10.7.7.3> <1200489793.00010290.1200478201@10.7.7.3> <1200518607.00010486.1200507002@10.7.7.3> <478E834E.4080302@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Julian Elischer , Nikos Vassiliadis Subject: Re: Multilink PPP Download Speeds With Round-Robin Packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jan 2008 22:23:23 -0000 Hi. Michael MacLeod wrote: > On Jan 16, 2008 5:21 PM, Alexander Motin 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 username@teksavvy.com > 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 username@teksavvy.com set auth password password set link max-redial 0 open link l1 set auth authname username@teksavvy.com 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 "username@teksavvy.com" > 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 "username@teksavvy.com" > 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