From owner-freebsd-net@FreeBSD.ORG Sun Jan 20 22:26:47 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 8FD4D16A46B for ; Sun, 20 Jan 2008 22:26:47 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.freebsd.org (Postfix) with ESMTP id 3DE3A13C474 for ; Sun, 20 Jan 2008 22:26:47 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so2578126pyb.10 for ; Sun, 20 Jan 2008 14:26:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=9rUNct1Reuwxq9S0JJIOtoWOZEq7/zKhqB0ZOykJqNQ=; b=lAdFlSZvPah/uSfjvJkcv/OIaQOPqOYAAkl7xTBvuW0DSI4LlQ4Wrbizbh3/ttBB6/DkOjtREZMobcgm9Mq8NelpTS55jrx/sVrzIMhabCWjhyl4YPNqCVP5Okp2PUZeU8+x7RPyq5lGZKMa8bMPI0lgSXXqcOCXKzkPcZA5xNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=xrWca5ENayLXEmh46RMaYTG1E9R79GZFzjS2KmDvcjw9y/+i83yp7QvGqAIYwdZR8FKkCE5UEDRzjjiuA6jjS3bH00w5W6v0kj2aiYZ0S1tlqC4hV4ZVXJPT6nlZUxCgN6lXKkMMX+K5/a2mehVctHk3eC8/hi2xnbYPRFPb1CA= Received: by 10.65.154.2 with SMTP id g2mr13178110qbo.55.1200868006039; Sun, 20 Jan 2008 14:26:46 -0800 (PST) Received: by 10.64.179.20 with HTTP; Sun, 20 Jan 2008 14:26:45 -0800 (PST) Message-ID: Date: Sun, 20 Jan 2008 17:26:45 -0500 From: "Michael MacLeod" To: "Alexander Motin" In-Reply-To: <47929B88.3050303@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> <47927858.4050702@FreeBSD.org> <47929B88.3050303@FreeBSD.org> 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: Sun, 20 Jan 2008 22:26:47 -0000 I figured out the real source of the problem. Turns out Bell went and screwed up the lantern test mappings on my connections, and dropped the profile on one of them to 3 megabits (which I didn't know because the lantern was mis-mapped). So I've spent the last several weeks racking my brains trying to figure out what the hell was going on. Due to happenstance, I have another DSL connection (yes, a third one) that syncs at 8 megabits down that still has sync (The account's been canceled, but Bell can't even cancel an account right. I have three cancellation numbers!). So I plugged my router into the DSL modem that has a 6 meg profile (even though the lantern says it's out of service) and into the supposed to be canceled line, and now here's the result: http://www.dslreports.com/im/44226057/2364.png I really appreciate all the help though, and I'm still going to test out the new mpd code. It might end up waiting until I get my DSL lines and profiles straightened out though, which I hope to have finished this week. Cheers Mike Oh, and if your curious why I'm talking about Bell rather than TekSavvy, it's because I had Bell install the lines directly, and TekSavvy is just selling me a login. I don't know if this is common practice elsewhere in the world, but in Canada the old monopoly telco's were forced to resell their service wholesale to other providers, which means all DSL service in Ontario and Quebec connect through a Bell 'cloud', and your login determines which ISP your connection terminates at. This has lots of advantages, like having two logins for redundancy :) On Jan 19, 2008 7:53 PM, Alexander Motin wrote: > After rereading RFC I have found that your provider operation possibly > not perfect but it is correct. It is possible to hint peer to use > multilink after rejecting by sending NAK. > I have made some changes to handle that in mpd5 CVS and merged them into > mpd4 branch. You can get new mpd version to test from mpd CVS > repository: https://sourceforge.net/cvs/?group_id=14145 > > -- > Alexander Motin >