From owner-freebsd-net@FreeBSD.ORG Sun Jan 13 00:47:15 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 CB1EF16A418 for ; Sun, 13 Jan 2008 00:47:15 +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 44F5613C458 for ; Sun, 13 Jan 2008 00:47:14 +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 64349624 for freebsd-net@freebsd.org; Sun, 13 Jan 2008 01:47:13 +0200 Message-ID: <4789517F.902@FreeBSD.org> Date: Sun, 13 Jan 2008 01:47:11 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Mpd-5.0 released 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, 13 Jan 2008 00:47:15 -0000 Hello everybody! Mpd5 has got all of it's planned functionality and successfully working in many production environments. Remarking this I am glad to present you a new mpd-5.0 release, the first release of the new epoch! Comparing to 4.x, mpd5 presents significantly changed configuration and operation ideology, based on dynamic link/bundle creation. This gives many benefits, such as simplified configuration, better multilink operation, call forwarding (LAC/PAC/TSA) alike to Cisco VPDN, better scalability and many others. Mpd5 supports all FreeBSD versions from 5.x to HEAD, while newer system is preferred to get full functionality. Port: net/mpd5 Manual: http://mpd.sourceforge.net/doc5/mpd.html Forums: http://sourceforge.net/forum/?group_id=14145 -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Sun Jan 13 03:36:41 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C66C16A418; Sun, 13 Jan 2008 03:36:41 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 387B713C469; Sun, 13 Jan 2008 03:36:41 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0D3afhN093264; Sun, 13 Jan 2008 03:36:41 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0D3afcJ093260; Sun, 13 Jan 2008 03:36:41 GMT (envelope-from linimon) Date: Sun, 13 Jan 2008 03:36:41 GMT Message-Id: <200801130336.m0D3afcJ093260@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/119617: [nfs] nfs error on wpa network when reseting/shutdown 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, 13 Jan 2008 03:36:41 -0000 Old Synopsis: nfs error on wpa network when reseting/shutdown New Synopsis: [nfs] nfs error on wpa network when reseting/shutdown Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jan 13 03:35:29 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=119617 From owner-freebsd-net@FreeBSD.ORG Sun Jan 13 07:29:51 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 90CBE16A41B for ; Sun, 13 Jan 2008 07:29:51 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.187]) by mx1.freebsd.org (Postfix) with ESMTP id 8CD3713C457 for ; Sun, 13 Jan 2008 07:29:51 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so1717962rvb.43 for ; Sat, 12 Jan 2008 23:29:51 -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:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=/IlvZXwAhU6S5VG9IemK6f5ViWRsEeOg+/eyvZfdhNE=; b=SVgxNmHwItA9C0Ggzl63abHRTyy1VQ6lUntz46xydkdW6kkpeMsxJ9HO6AbFDAd9CS1XgdUSNwgqApzkFeQqdBnyflvu9JDafj2yiHGAm1a0Q/juiQEMItqaEDD9HjBOpyDF1ZuKAxLke/u2U/dy5e/TFkmrnxWhE54A5enMtdk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=aS31InuShLjVWA3JRPlFdLwkW6Dp6QFIP7N6rdf241gTLwQoAM/3rOWd0kA1Vee3ozpOYt3gsSdoOEYjlE8bmAAkRp9Ibe/JrX09J9GY3K64Je2CkTIDyfYaXAJidIURhuotplIVOZNSufRk7WPCz0nEldpNI3FHnocJ4NGeJbc= Received: by 10.140.163.3 with SMTP id l3mr1233525rve.253.1200209391077; Sat, 12 Jan 2008 23:29:51 -0800 (PST) Received: by 10.141.170.18 with HTTP; Sat, 12 Jan 2008 23:29:51 -0800 (PST) Message-ID: <2e77fc10801122329u359b918vb5efdaad4b71e002@mail.gmail.com> Date: Sun, 13 Jan 2008 09:29:51 +0200 From: "Niki Denev" Sender: ndenev@gmail.com To: freebsd-net@freebsd.org In-Reply-To: <47894992.8080202@vineyard.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <47894992.8080202@vineyard.net> X-Google-Sender-Auth: e41ea15941512dc0 Subject: Re: bgp router preferences 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, 13 Jan 2008 07:29:51 -0000 On Jan 13, 2008 1:13 AM, Eric W. Bates wrote: > I think I have finally given up on cisco. > > What are folks recommendations for a machine doing full bgp routes? > > I think I need to get a Sangoma card; but what is the current favorite > bgp routing software and how much RAM do folks think I can get away with? > > Thanks for your time. > > -- > Eric W. Bates > ericx@vineyard.net I'm using openbgpd and i'm quite happy with it. It's a very basic setup, but works without any problems, and the memory usage is very low. bgpd uses under 60M memory with one full routing table from the ISP, another received via IBGP and another session with about 250K addresses (local peering). Regards, Niki From owner-freebsd-net@FreeBSD.ORG Sun Jan 13 13:46:34 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7ADB216A419; Sun, 13 Jan 2008 13:46:34 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 3FAB913C45B; Sun, 13 Jan 2008 13:46:34 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 9D135207E; Sun, 13 Jan 2008 14:46:25 +0100 (CET) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: -0.2/3.0 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on tim.des.no Received: from ds4.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id 8E6F02049; Sun, 13 Jan 2008 14:46:25 +0100 (CET) Received: by ds4.des.no (Postfix, from userid 1001) id 75E93844C0; Sun, 13 Jan 2008 14:46:25 +0100 (CET) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: "Sepherosa Ziehau" References: <86ir2hznnd.fsf@ds4.des.no> <86abnpu0wv.fsf@ds4.des.no> <86abnovy4k.fsf@ds4.des.no> <86odc3dlgi.fsf@ds4.des.no> <86lk76c6t5.fsf@ds4.des.no> <864pds8idc.fsf@ds4.des.no> Date: Sun, 13 Jan 2008 14:46:25 +0100 In-Reply-To: (Sepherosa Ziehau's message of "Fri\, 11 Jan 2008 20\:37\:39 +0800") Message-ID: <864pdhrg7i.fsf@ds4.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: kevlo@freebsd.org, sam@freebsd.org, current@freebsd.org, net@freebsd.org Subject: Re: if_ral regression 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, 13 Jan 2008 13:46:34 -0000 "Sepherosa Ziehau" writes: > revert the old patch at your AP side and try this one > http://people.freebsd.org/~sephe/rt2560_test.diff1 No improvement. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 06:35:35 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 3233E16A469 for ; Mon, 14 Jan 2008 06:35:35 +0000 (UTC) (envelope-from portcitycs@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.freebsd.org (Postfix) with ESMTP id DE3E113C461 for ; Mon, 14 Jan 2008 06:35:34 +0000 (UTC) (envelope-from portcitycs@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so2901324pyb.10 for ; Sun, 13 Jan 2008 22:35:34 -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:mime-version:content-type; bh=KnpLI3+YRW2vaODfCV9aag22zboCPXs9pzw7ChdKe8E=; b=peSoY9qES4ia/TrcKkUcur7uW0kmhnqw++RtX+hTcSAM/j8zs6GTXdp8bvX5q1v/E1fZ4f1qC8ejbI9IIKnLugnOy0hH2EZwvz0yzdyUdd2rYWim3bPCIBfYYRR+ZcdAO5OU7DOe9k6KX48zsDn3jqDG1zPYV/HBBMs+EyJLS/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=jX1fSoA4aVfbCKsjW7BDuWHj+Xs/9y04Kj1/iehhZ+joIl/YC3N7B4lHLvdL1r4fPbJKZYVXDHJdN62EXnIpXUJ22dNEJe6561iiCct62Pe1xNkJ944mcXhxu/IeXcBlXBLANVGhV3vAQEdnUBUpBwdV7njX28571kKKof0mNHQ= Received: by 10.142.127.10 with SMTP id z10mr2265435wfc.122.1200292533542; Sun, 13 Jan 2008 22:35:33 -0800 (PST) Received: by 10.142.47.12 with HTTP; Sun, 13 Jan 2008 22:35:33 -0800 (PST) Message-ID: <5a1835cd0801132235q4de087c6p42fac3da420f16f@mail.gmail.com> Date: Mon, 14 Jan 2008 01:35:33 -0500 From: "Lyle Scott III" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: question about captive wifi portal... 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: Mon, 14 Jan 2008 06:35:35 -0000 I am experimenting more to make a small captive (wifi) portal system. I would like to use pf. I have been looking into authpf and it is a pretty good fit for what i need... but the users won't be SSHing to get allowed. Is there another way around this? Does anyone else have and suggestions or links that could be helpful? I also thought i could just use packet marks, but I am just unaware of anything else to make the pf packets more dynamic... i guess that would be the goal of this post -- Lyle Scott, III http://www.lylescott.ws From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 06:44:10 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7087116A46E; Mon, 14 Jan 2008 06:44:10 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 55C9713C457; Mon, 14 Jan 2008 06:44:10 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0E6iALk065922; Mon, 14 Jan 2008 06:44:10 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0E6i9ee065916; Mon, 14 Jan 2008 06:44:09 GMT (envelope-from linimon) Date: Mon, 14 Jan 2008 06:44:09 GMT Message-Id: <200801140644.m0E6i9ee065916@freefall.freebsd.org> To: phil@ultimate.com, linimon@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/118722: [tcp] Many old TCP connections in SYN_RCVD state 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: Mon, 14 Jan 2008 06:44:10 -0000 Synopsis: [tcp] Many old TCP connections in SYN_RCVD state State-Changed-From-To: open->feedback State-Changed-By: linimon State-Changed-When: Mon Jan 14 06:43:40 UTC 2008 State-Changed-Why: Note that submitter was asked for feedback. http://www.freebsd.org/cgi/query-pr.cgi?pr=118722 From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 08:10:08 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63CC016A41A for ; Mon, 14 Jan 2008 08:10:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5FD5D13C44B for ; Mon, 14 Jan 2008 08:10:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0E8A2He023708 for ; Mon, 14 Jan 2008 08:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0E8A2ab023707; Mon, 14 Jan 2008 08:10:02 GMT (envelope-from gnats) Date: Mon, 14 Jan 2008 08:10:02 GMT Message-Id: <200801140810.m0E8A2ab023707@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Nagy Keve" Cc: Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Nagy Keve List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2008 08:10:08 -0000 The following reply was made to PR kern/112654; it has been noted by GNATS. From: "Nagy Keve" To: bug-followup@freebsd.org Cc: Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 Date: Mon, 14 Jan 2008 09:06:42 +0100 An important update is that my earlier conclusion regarding the patch was f= lawed. The patch DOES WORK on RELENG_6, it gets rid of the kernel panic upon loadi= ng the module and it DOES FIND the appropriate cable media connected. I a= m still unable to explain what caused the "no carrier" issue during my ea= rlier attempts with this patch. So the concept is proved, this could be a proper fix if we can get the pcn = driver to use ns_phy instead of uk_phy. With the current patch both ns_ph= y and uk_phy shows up in dmesg, and I would rather see ns_phy only. From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 09:18:26 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 6909E16A469 for ; Mon, 14 Jan 2008 09:18:26 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from rv-out-0910.google.com (rv-out-0910.google.com [209.85.198.186]) by mx1.freebsd.org (Postfix) with ESMTP id 48E3513C46A for ; Mon, 14 Jan 2008 09:18:26 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: by rv-out-0910.google.com with SMTP id l15so2093191rvb.43 for ; Mon, 14 Jan 2008 01:18:26 -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:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=xcvMIgy8peC+epyOa5u/WEbu4N7kC+syVqiDlma+z7g=; b=vDSGtzRz5VrnoIQB/rJ7fEkAzmImY3KplGc1JHXY4THGBrnuces2m9tXEBLaUPmHjbu4sFpe2cntnTPqXX68rmPXCOn+v3J7eWDDXGZPiM9FzvPvqU897ZXhFfPDZ0NlZ7ut8pt/i6c87v321EqIeQp4oK6RxM8jvfi3WhM6ymQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=orNsa6wMCYxmst9qA43kszpcXs+HtzO8VQelwUVCNDSzEvVb5ahjwruYz7wvIhsRibzv15nx/3a+mMiAxlj9GEBvf4XlNkwhYbrhrZ/wov+WA84t+5q6KiwW0/z+UfH595yQZAL0tq9nsV5+WOi4V2BYPCvJYtbvo/WkCQk1H6I= Received: by 10.141.26.18 with SMTP id d18mr3632609rvj.106.1200302306132; Mon, 14 Jan 2008 01:18:26 -0800 (PST) Received: by 10.141.170.18 with HTTP; Mon, 14 Jan 2008 01:18:26 -0800 (PST) Message-ID: <2e77fc10801140118g44c139a0r162b0a8293e33ca1@mail.gmail.com> Date: Mon, 14 Jan 2008 11:18:26 +0200 From: "Niki Denev" Sender: ndenev@gmail.com To: freebsd-net@freebsd.org In-Reply-To: <5a1835cd0801132235q4de087c6p42fac3da420f16f@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <5a1835cd0801132235q4de087c6p42fac3da420f16f@mail.gmail.com> X-Google-Sender-Auth: 41aca5d49b4b35a6 Subject: Re: question about captive wifi portal... 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: Mon, 14 Jan 2008 09:18:26 -0000 On Jan 14, 2008 8:35 AM, Lyle Scott III wrote: > I am experimenting more to make a small captive (wifi) portal system. > > I would like to use pf. I have been looking into authpf and it is a pretty > good fit for what i need... but the users won't be SSHing to get allowed. > > Is there another way around this? Does anyone else have and suggestions or > links that could be helpful? > > I also thought i could just use packet marks, but I am just unaware of > anything else to make the pf packets more dynamic... i guess that would be > the goal of this post > > -- > Lyle Scott, III > http://www.lylescott.ws Hi, pfSense[1], a FreeBSD based router/firewall distribution has integrated captive portal using pf. Maybe you'll want to check how they are doing this. [1] http://pfsense.com HTH, Niki From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 11:07:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E98A516A4E9 for ; Mon, 14 Jan 2008 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E307B13C4D1 for ; Mon, 14 Jan 2008 11:07:03 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0EB73aF052625 for ; Mon, 14 Jan 2008 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0EB73LF052621 for freebsd-net@FreeBSD.org; Mon, 14 Jan 2008 11:07:03 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 14 Jan 2008 11:07:03 GMT Message-Id: <200801141107.m0EB73LF052621@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org 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: Mon, 14 Jan 2008 11:07:04 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- f kern/115360 net [ipv6] IPv6 address and if_bridge don't play well toge 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue f kern/62374 net panic: free: multiple frees s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit s kern/105943 net Network stack may modify read-only mbuf chain copies o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112722 net IP v4 udp fragmented packet reject o kern/113457 net [ipv6] deadlock occurs if a tunnel goes down while the o kern/113842 net [ipv6] PF_INET6 proto domain state can't be cleared wi o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/116077 net 6.2-STABLE panic during use of multi-cast networking c o kern/116172 net Network / ipv6 recursive mutex panic o kern/116185 net if_iwi driver leads system to reboot o kern/116328 net [bge]: Solid hang with bge interface o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117423 net [vlan] Duplicate IP on different interfaces o kern/117448 net [carp] 6.2 kernel crash (regression) o kern/118880 net [ipv6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card (regr o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119361 net [bge] bge(4) transmit performance problem f kern/119548 net [pf] [ath] [patch] PF Altq with ath hostap problem 32 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/112654 net [pcn] Kernel panic upon if_pcn module load on a Netfin o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o bin/116643 net [patch] fstat(1): add INET/INET6 socket details as in o bin/117339 net [patch] route(8): loading routing management commands f kern/118722 net [tcp] Many old TCP connections in SYN_RCVD state o kern/118727 net [ng] [patch] add new ng_pf module a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118975 net [bge] [patch] Broadcom 5906 not handled by FreeBSD o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/119432 net [arp] route add -host -iface causes arp e o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown 22 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 15:07:27 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 65EAD16A41B for ; Mon, 14 Jan 2008 15:07:27 +0000 (UTC) (envelope-from raffaele.delorenzo@libero.it) Received: from grupposervizi.it (mail1.tagetik.com [85.18.71.243]) by mx1.freebsd.org (Postfix) with SMTP id 764B113C4E5 for ; Mon, 14 Jan 2008 15:07:25 +0000 (UTC) (envelope-from raffaele.delorenzo@libero.it) Received: (qmail 9225 invoked by uid 453); 14 Jan 2008 15:07:24 -0000 Received: from [192.9.217.29] (HELO noel.grupposervizi.it) (192.9.217.29) by grupposervizi.it (qpsmtpd/0.31.1) with ESMTP; Mon, 14 Jan 2008 16:07:24 +0100 Message-ID: <478B7AA6.9010304@libero.it> Date: Mon, 14 Jan 2008 16:07:18 +0100 From: Raffaele De Lorenzo User-Agent: Thunderbird 2.0.0.9 (X11/20071204) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, freebsd-security@freebsd.org, freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "raffaele.delorenzo" Subject: Added native socks support to libc in FreeBSD 7 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: Mon, 14 Jan 2008 15:07:27 -0000 Upgrade: 1) Added IPv6 Support (need to be tested) Cheers Raffaele Hi, i added a native (client) Socks V4/V5 support inside FreeBSD libc library. The work is based of my project (see http://csocks.altervista.org) CSOCKS. You can get it here: http://csocks.altervista.org/download/FreeBSD_libc.tar.gz CHANGES: I changed the file: /usr/src/lib/libc/Makefile I added the Directory: /usr/src/lib/libc/socks They contains the files: csocks.c csocks.h csocks.conf.5 csocks.1 Makefile.inc I added the configuration file (csocks.conf in the /etc/ directory) /usr/src/etc/ INSTALL ISTRUCTIONS: copy the Makefile in /usr/src/lib/libc/ copy the directory socks in /usr/src/lib/libc/ touch /etc/csocks.conf recompile the libc and install it (cd /usr/src/lib/libc && make && make install) I Tested it in FreeBSD 7 only on i386 cheers Raffaele From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 15:07:39 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 BF13216A5B9 for ; Mon, 14 Jan 2008 15:07:39 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog16.obsmtp.com (s200aog16.obsmtp.com [207.126.144.130]) by mx1.freebsd.org (Postfix) with SMTP id EAB2A13C506 for ; Mon, 14 Jan 2008 15:07:37 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob016.postini.com ([207.126.147.11]) with SMTP; Mon, 14 Jan 2008 15:07:36 UTC Received: from bill.mintel.co.uk (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 7D7A218141E for ; Mon, 14 Jan 2008 15:07:36 +0000 (GMT) Message-ID: <478B7AB7.5010208@tomjudge.com> Date: Mon, 14 Jan 2008 15:07:35 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Programming interface MAC filter without enabling PROMISC on an interface from user space. 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: Mon, 14 Jan 2008 15:07:39 -0000 Hi, I have just started experimenting with OpenLLDP and come across a little bit of a nasty. When it opens the interface, it puts it into PROMISC mode, which I don't really want to happen. Is there any way to add the LLDP MAC address (01-80-C2-00-00-0E) to the interface mac filter from user space, so that the interface does not have to be set to PROMISC? The OpenLLDP uses BPF to interface with the network stack as it has to send and receive RAW Ethernet frames (ether type 88-CC). If this is not possible where would one start with moving the LLDP implementation into the kernel. I was thinking of 3 options: * Having a virtual interface (like vlan/carp) that attaches to a parent that processes the packages. * A netgraph node to processes the packets and send responses. * A core protocol handler that deals with the hole thing for any Ethernet capable interface. Any help with this would be greatly appreciated. Tom From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 16:08:20 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 16E4D16A41B for ; Mon, 14 Jan 2008 16:08:20 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id CFA8413C46A for ; Mon, 14 Jan 2008 16:08:19 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 01B8A88896; Mon, 14 Jan 2008 11:08:19 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 14 Jan 2008 11:08:19 -0500 X-Sasl-enc: 1GFCpBEXJqjmTE6am+aJJILAvekd+J30Ta9+EJUHYkuQ 1200326895 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 709132A06C; Mon, 14 Jan 2008 11:08:15 -0500 (EST) Message-ID: <478B88EE.7090307@FreeBSD.org> Date: Mon, 14 Jan 2008 16:08:14 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Tom Judge References: <478B7AB7.5010208@tomjudge.com> In-Reply-To: <478B7AB7.5010208@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Programming interface MAC filter without enabling PROMISC on an interface from user space. 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: Mon, 14 Jan 2008 16:08:20 -0000 Tom Judge wrote: > Hi, > > I have just started experimenting with OpenLLDP and come across a > little bit of a nasty. When it opens the interface, it puts it into > PROMISC mode, which I don't really want to happen. Is there any way > to add the LLDP MAC address (01-80-C2-00-00-0E) to the interface mac > filter from user space, so that the interface does not have to be set > to PROMISC? There *is* an API for this but it's not integrated into pcap or bpf; see SIOCADDMULTI and SIOCDELMULTI. There are some issues with doing that portably, Windows and Linux do things somewhat differently in this space. Really we could do with a KPI for this so that the references are properly refcounted. If you have other link layer multicast listeners it's not guaranteed that the stack will correctly restore the hash filters at the driver level if it has to enable ALLMULTI mode. You almost certainly don't want to set PROMISC if you are ever going to do any kind of IP forwarding, although I believe I fixed that historic bug whereby the IP layer kept seeing its own packets about a year ago. later BMS From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 16:25:44 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 4F32716A418; Mon, 14 Jan 2008 16:25:44 +0000 (UTC) (envelope-from lolo@agneau.org) Received: from bergerie.agneau.org (bergerie.agneau.org [88.173.248.15]) by mx1.freebsd.org (Postfix) with ESMTP id E506813C503; Mon, 14 Jan 2008 16:25:43 +0000 (UTC) (envelope-from lolo@agneau.org) Received: by bergerie.agneau.org (Postfix, from userid 500) id 33CC2109086; Mon, 14 Jan 2008 17:07:56 +0100 (CET) Date: Mon, 14 Jan 2008 17:07:56 +0100 From: Laurent Frigault To: Sepherosa Ziehau Message-ID: <20080114160756.GA7716@obelix.bergerie.agneau.org> References: <200801071728.m07HSsFl030966@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Powered-By: UUCP Cc: freebsd-net@freebsd.org, remko@freebsd.org Subject: Re: kern/119361: [bge] bge(4) transmit performance problem 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: Mon, 14 Jan 2008 16:25:44 -0000 On Fri, Jan 11, 2008 at 10:02:34PM +0800, Sepherosa Ziehau wrote: > On Jan 8, 2008 1:28 AM, wrote: > > Synopsis: [bge] bge(4) transmit performance problem > > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > > Responsible-Changed-By: remko > > Responsible-Changed-When: Mon Jan 7 17:28:37 UTC 2008 > > Responsible-Changed-Why: > > reassign to -net team > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=119361 > > Have you tested polling(4)? If polling could give you better TX > performance, you should consider raise: > in bge_attach() > sc->bge_tx_max_coal_bds = 10; > to 64 or more I tested with polling and did not see any changes for the transmit performance problem. I just re-test with polling AND bge_tx_max_coal_bds raised to 64 => no changes. Regards, -- Laurent Frigault From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 16:38:59 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 C992A16A4A1 for ; Mon, 14 Jan 2008 16:38:59 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog14.obsmtp.com (s200aog14.obsmtp.com [207.126.144.128]) by mx1.freebsd.org (Postfix) with SMTP id 11A4E13C46E for ; Mon, 14 Jan 2008 16:38:58 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob014.postini.com ([207.126.147.11]) with SMTP; Mon, 14 Jan 2008 16:38:57 UTC Received: from bill.mintel.co.uk (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 2C46018141F; Mon, 14 Jan 2008 16:38:57 +0000 (GMT) Message-ID: <478B9020.3000402@tomjudge.com> Date: Mon, 14 Jan 2008 16:38:56 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <478B7AB7.5010208@tomjudge.com> <478B88EE.7090307@FreeBSD.org> In-Reply-To: <478B88EE.7090307@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Programming interface MAC filter without enabling PROMISC on an interface from user space. 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: Mon, 14 Jan 2008 16:38:59 -0000 Bruce M. Simpson wrote: > Tom Judge wrote: >> Hi, >> >> I have just started experimenting with OpenLLDP and come across a >> little bit of a nasty. When it opens the interface, it puts it into >> PROMISC mode, which I don't really want to happen. Is there any way >> to add the LLDP MAC address (01-80-C2-00-00-0E) to the interface mac >> filter from user space, so that the interface does not have to be set >> to PROMISC? > > There *is* an API for this but it's not integrated into pcap or bpf; see > SIOCADDMULTI and SIOCDELMULTI. There are some issues with doing that > portably, Windows and Linux do things somewhat differently in this space. > > Really we could do with a KPI for this so that the references are > properly refcounted. If you have other link layer multicast listeners > it's not guaranteed that the stack will correctly restore the hash > filters at the driver level if it has to enable ALLMULTI mode. > > You almost certainly don't want to set PROMISC if you are ever going to > do any kind of IP forwarding, although I believe I fixed that historic > bug whereby the IP layer kept seeing its own packets about a year ago. > > later > BMS Hi Bruce, Thanks for the response. I have a quick grep of the src tree to find an example of this being used and only found the following from wpa_supplicant and I have a few questions: * I am presuming that this will do what I want, am I correct? * If I was only ever to add the address to an interface an never delete it would this cause any problems? I.e. when lldpd ends, or is restarted and tries to add the address again? * Alternatively is there a way to query the filter to ask what addresses it is currently programmed for? At this stage I am not looking for portability, I just want a working solution for a FreeBSD only shop. Thanks again Tom From contrib/wpa_supplicant/driver_wired.c: static int wpa_driver_wired_multi(const char *ifname, const u8 *addr, int add) { struct ifreq ifr; int s; s = socket(PF_INET, SOCK_DGRAM, 0); if (s < 0) { perror("socket"); return -1; } memset(&ifr, 0, sizeof(ifr)); strncpy(ifr.ifr_name, ifname, IFNAMSIZ); ifr.ifr_hwaddr.sa_family = AF_UNSPEC; memcpy(ifr.ifr_hwaddr.sa_data, addr, ETH_ALEN); if (ioctl(s, add ? SIOCADDMULTI : SIOCDELMULTI, (caddr_t) &ifr) < 0) { perror("ioctl[SIOC{ADD/DEL}MULTI]"); close(s); return -1; } close(s); return 0; } From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 17:13:17 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 3835A16A41B for ; Mon, 14 Jan 2008 17:13:17 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id E798113C442 for ; Mon, 14 Jan 2008 17:13:16 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id ACFEE84EEF; Mon, 14 Jan 2008 12:13:16 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 14 Jan 2008 12:13:16 -0500 X-Sasl-enc: 1kLVZRIGGd2d+fm/vRFFDryCCTEQIQ4lgN+sgiYULg47 1200330796 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 4300F2A072; Mon, 14 Jan 2008 12:13:16 -0500 (EST) Message-ID: <478B982B.304@FreeBSD.org> Date: Mon, 14 Jan 2008 17:13:15 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Tom Judge References: <478B7AB7.5010208@tomjudge.com> <478B88EE.7090307@FreeBSD.org> <478B9020.3000402@tomjudge.com> In-Reply-To: <478B9020.3000402@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Programming interface MAC filter without enabling PROMISC on an interface from user space. 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: Mon, 14 Jan 2008 17:13:17 -0000 Tom Judge wrote: > Thanks for the response. I have a quick grep of the src tree to find > an example of this being used and only found the following from > wpa_supplicant and I have a few questions: > > * I am presuming that this will do what I want, am I correct? Yes, it will attempt to add the given link layer multicast group to the ifnet's underlying device driver. > > * If I was only ever to add the address to an interface an never > delete it would this cause any problems? I.e. when lldpd ends, or is > restarted and tries to add the address again? SIOCADDMULTI is very low level, no resource tracking is performed; I changed its semantics to only allow one userland opener so that in-kernel refcounting would work, as there is no per-process or per-client resource tracking -- so it's a really good idea to clean up after it. > > * Alternatively is there a way to query the filter to ask what > addresses it is currently programmed for? Nope, there is no userland or kernel API for that unless you hack up the driver. cheers BMS From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 18:39:31 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 19C9016A468; Mon, 14 Jan 2008 18:39:31 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog10.obsmtp.com (s200aog10.obsmtp.com [207.126.144.124]) by mx1.freebsd.org (Postfix) with SMTP id 3868913C4CE; Mon, 14 Jan 2008 18:39:29 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob010.postini.com ([207.126.147.11]) with SMTP; Mon, 14 Jan 2008 18:39:29 UTC Received: from bill.mintel.co.uk (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id EFC88181421; Mon, 14 Jan 2008 18:39:28 +0000 (GMT) Message-ID: <478BAC60.9030506@tomjudge.com> Date: Mon, 14 Jan 2008 18:39:28 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <478B7AB7.5010208@tomjudge.com> <478B88EE.7090307@FreeBSD.org> <478B9020.3000402@tomjudge.com> <478B982B.304@FreeBSD.org> In-Reply-To: <478B982B.304@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Programming interface MAC filter without enabling PROMISC on an interface from user space. 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: Mon, 14 Jan 2008 18:39:31 -0000 Bruce M. Simpson wrote: > Tom Judge wrote: >> Thanks for the response. I have a quick grep of the src tree to find >> an example of this being used and only found the following from >> wpa_supplicant and I have a few questions: >> >> * I am presuming that this will do what I want, am I correct? > > Yes, it will attempt to add the given link layer multicast group to the > ifnet's underlying device driver. >> >> * If I was only ever to add the address to an interface an never >> delete it would this cause any problems? I.e. when lldpd ends, or is >> restarted and tries to add the address again? > > SIOCADDMULTI is very low level, no resource tracking is performed; I > changed its semantics to only allow one userland opener so that > in-kernel refcounting would work, as there is no per-process or > per-client resource tracking -- so it's a really good idea to clean up > after it. > >> >> * Alternatively is there a way to query the filter to ask what >> addresses it is currently programmed for? > > Nope, there is no userland or kernel API for that unless you hack up the > driver. > Ok, so if I can safely assume that the process sending/receiving the LLDP frames should always be running would it be safe to use a helper program to add the mac on system startup so it is always registered on particular interfaces for the uptime of the system rather than having the daemon add/remove the address on startup shutdown? If not what problems would this create? Personally I can't see why this approach would be a problem, but I am not a expert. The address is defined in IEEE Std 802.1D-2004 as to not be forwarded by bridges (which I interpret as it being link local in a sense as switches/bridges are not allowed to forward the frame), so I can't see it being a problem registered on multiple interfaces. On a side note does anyone know if if_bridge will respect the standard and not forward this frame on to other interfaces? Thanks again Tom From owner-freebsd-net@FreeBSD.ORG Mon Jan 14 18:48:19 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 B525216A46B for ; Mon, 14 Jan 2008 18:48:19 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 759C813C4E3 for ; Mon, 14 Jan 2008 18:48:19 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 68F08891C5; Mon, 14 Jan 2008 13:48:18 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 14 Jan 2008 13:48:18 -0500 X-Sasl-enc: 2W9NKTyf7cVOWJKhzBzl3vEPRcfHplybr7HgbhIKWEct 1200336498 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id E53AC2A0B6; Mon, 14 Jan 2008 13:48:17 -0500 (EST) Message-ID: <478BAE70.9050702@FreeBSD.org> Date: Mon, 14 Jan 2008 18:48:16 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Tom Judge References: <478B7AB7.5010208@tomjudge.com> <478B88EE.7090307@FreeBSD.org> <478B9020.3000402@tomjudge.com> <478B982B.304@FreeBSD.org> <478BAC60.9030506@tomjudge.com> In-Reply-To: <478BAC60.9030506@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Programming interface MAC filter without enabling PROMISC on an interface from user space. 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: Mon, 14 Jan 2008 18:48:19 -0000 Tom Judge wrote: > > Ok, so if I can safely assume that the process sending/receiving the > LLDP frames should always be running would it be safe to use a helper > program to add the mac on system startup so it is always registered on > particular interfaces for the uptime of the system rather than having > the daemon add/remove the address on startup shutdown? > If not what problems would this create? If the daemon doesn't unregister its use of the link layer group, the kernel will not clean up after it. It won't prevent kernel entities from joining the group -- they will just acquire another reference -- but other userland clients will not be able to join the group until SIOCDELMULTI is called by at least one client. By the way, other processes can hijack this, but only if they have permission to use SIOCDELMULTI. I believe this requires root privileges. I believe it should be possible to use mtest to clean up manually. This is far from ideal and it really does want an API. NDIS, incidentally, can do all of what you describe. > > Personally I can't see why this approach would be a problem, but I am > not a expert. The address is defined in IEEE Std 802.1D-2004 as to > not be forwarded by bridges (which I interpret as it being link local > in a sense as switches/bridges are not allowed to forward the frame), > so I can't see it being a problem registered on multiple interfaces. SIOCADDMULTI memberships are specific to the interface you request them on. I can't speak for the bridging code -- I don't think it does any special handling of multicast frames, however I'm not sure if it's smart enough not to forward this group. Like IN_LOCALGROUP() it might need its own 'don't forward this' clause. later BMS From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 00:44:01 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 3CE5616A4C8 for ; Tue, 15 Jan 2008 00:44:01 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id F121413C447 for ; Tue, 15 Jan 2008 00:44:00 +0000 (UTC) (envelope-from mike@sentex.net) Received: from BLUELAPIS.sentex.ca (cage.simianscience.com [64.7.134.1]) by smarthost2.sentex.ca (8.14.1/8.13.8) with SMTP id m0F0NasT068434; Mon, 14 Jan 2008 19:23:37 -0500 (EST) (envelope-from mike@sentex.net) From: Mike Tancsa To: "Eric W. Bates" Date: Mon, 14 Jan 2008 19:23:46 -0500 Message-ID: <35vno31cbagg7k3abhf6q1q7reo0j78v95@4ax.com> References: <47894992.8080202@vineyard.net> In-Reply-To: <47894992.8080202@vineyard.net> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: bgp router preferences 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: Tue, 15 Jan 2008 00:44:01 -0000 On Sat, 12 Jan 2008 18:13:22 -0500, in sentex.lists.freebsd.net you wrote: >I think I have finally given up on cisco. > >What are folks recommendations for a machine doing full bgp routes? > >I think I need to get a Sangoma card; but what is the current favorite=20 I am not sure the card is still supported under FreeBSD. Do you really need T1 connectivity ? >bgp routing software and how much RAM do folks think I can get away = with? Quagga and 1G of RAM is plenty. 512 will work just fine, but splurge on the extra $50 to give you a bit more room :) ---Mike -------------------------------------------------------- Mike Tancsa, Sentex communications http://www.sentex.net Providing Internet Access since 1994 mike@sentex.net, (http://www.tancsa.com) From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 00:56:37 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 BDD0616A417 for ; Tue, 15 Jan 2008 00:56:37 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.224]) by mx1.freebsd.org (Postfix) with ESMTP id 6F1AB13C45A for ; Tue, 15 Jan 2008 00:56:37 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by nz-out-0506.google.com with SMTP id l8so1026652nzf.13 for ; Mon, 14 Jan 2008 16:56:36 -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=fE5TLj4POPjtlTXkqz9PHTmqJK6BXZfVLRZc5tZ7+GA=; b=L98xDmt+Sh5J2rHNL3fvzb/3bmpPn51IC+XeVlAKnIA2bvXsxLJx2IKI1dzbTDHH8KrHGxfNJujg2WLg9EVhf44hKm5dSIugCKVSNZcoLoI3XjPOUdVSOrqftieo+RS3FmsFakuVVM/9z0QEFbrnnSFvFD/L6yK/oMRYMtfIgrs= 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=qRtjtCAdrwVqrkswaq+CKhuY2K+JAv8bM7TfmRH5EinyUXQ/mtycKeUP9nm6T55o6eu1dji2f2CvQy4fbbtiMW7bKRrj4WfCxjdrCAlH39OPe02EJuFO/7t19dEfxQRzn7hh/6sCo+iCM7VTs2/l+AibGKGhBBfPoUGXDkG4Gug= Received: by 10.142.222.21 with SMTP id u21mr2908843wfg.128.1200358596148; Mon, 14 Jan 2008 16:56:36 -0800 (PST) Received: by 10.142.162.20 with HTTP; Mon, 14 Jan 2008 16:56:36 -0800 (PST) Message-ID: Date: Tue, 15 Jan 2008 08:56:36 +0800 From: "Sepherosa Ziehau" To: "Laurent Frigault" In-Reply-To: <20080114160756.GA7716@obelix.bergerie.agneau.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200801071728.m07HSsFl030966@freefall.freebsd.org> <20080114160756.GA7716@obelix.bergerie.agneau.org> Cc: freebsd-net@freebsd.org, remko@freebsd.org Subject: Re: kern/119361: [bge] bge(4) transmit performance problem 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: Tue, 15 Jan 2008 00:56:37 -0000 On Jan 15, 2008 12:07 AM, Laurent Frigault wrote: > On Fri, Jan 11, 2008 at 10:02:34PM +0800, Sepherosa Ziehau wrote: > > On Jan 8, 2008 1:28 AM, wrote: > > > Synopsis: [bge] bge(4) transmit performance problem > > > > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-net > > > Responsible-Changed-By: remko > > > Responsible-Changed-When: Mon Jan 7 17:28:37 UTC 2008 > > > Responsible-Changed-Why: > > > reassign to -net team > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=119361 > > > > Have you tested polling(4)? If polling could give you better TX > > performance, you should consider raise: > > in bge_attach() > > sc->bge_tx_max_coal_bds = 10; > > to 64 or more > > I tested with polling and did not see any changes for the transmit > performance problem. > > I just re-test with polling AND bge_tx_max_coal_bds raised to 64 => no > changes. Please test following patch: http://people.freebsd.org/~sephe/if_bge.c.6.diff Best Regards, sephe -- Live Free or Die From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 06:21:26 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 A2F1216A419 for ; Tue, 15 Jan 2008 06:21:26 +0000 (UTC) (envelope-from thierry@herbelot.com) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id 7E35213C458 for ; Tue, 15 Jan 2008 06:21:26 +0000 (UTC) (envelope-from thierry@herbelot.com) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by postfix1-g20.free.fr (Postfix) with ESMTP id B6554216277D for ; Tue, 15 Jan 2008 06:56:31 +0100 (CET) Received: from smtp4-g19.free.fr (localhost.localdomain [127.0.0.1]) by smtp4-g19.free.fr (Postfix) with ESMTP id D1F833EA0CF; Tue, 15 Jan 2008 06:56:29 +0100 (CET) Received: from mail.herbelot.nom (bne75-4-82-227-159-103.fbx.proxad.net [82.227.159.103]) by smtp4-g19.free.fr (Postfix) with ESMTP id A517F3EA0CC; Tue, 15 Jan 2008 06:56:29 +0100 (CET) Received: from diversion.herbelot.nom (diversion.herbelot.nom [192.168.2.6]) by mail.herbelot.nom (8.14.0/8.14.0) with ESMTP id m0F5uS3Y027372; Tue, 15 Jan 2008 06:56:28 +0100 (CET) From: Thierry Herbelot To: freebsd-current@freebsd.org Date: Tue, 15 Jan 2008 06:56:21 +0100 User-Agent: KMail/1.9.7 X-Warning: Windows can lose your files X-Op-Sys: Le FriBi de la mort qui tue X-Org: TfH&Co X-MailScanner: Found to be clean MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801150656.22319.thierry@herbelot.com> Cc: freebsd-net@freebsd.org Subject: Linux SMP network performance measurements X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: thierry@herbelot.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2008 06:21:26 -0000 Hello, a recent article (http://www.ibm.com/developerworks/linux/library/l-scalability/?ca=dgr-lnxw02FasterLinuxNet) gives some measurements on various tweakings of an SMP machine with 4 Xeon processors (it *shows* a nice improvement when using more CPUs and more bonded Ethernet interfaces). Has some the machine (and the time, obviously) to make some of the same measurements with the latest FreeBSD versions ? TfH From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 08:07:01 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 DF47516A418; Tue, 15 Jan 2008 08:07:01 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: from blah.sun-fish.com (blah.sun-fish.com [217.18.249.150]) by mx1.freebsd.org (Postfix) with ESMTP id 4B77213C45D; Tue, 15 Jan 2008 08:07:00 +0000 (UTC) (envelope-from stefan.lambrev@moneybookers.com) Received: by blah.sun-fish.com (Postfix, from userid 1002) id E8CC61B10EF3; Tue, 15 Jan 2008 09:06:58 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on blah.cmotd.com X-Spam-Level: X-Spam-Status: No, score=-10.6 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from hater.haters.org (unknown [192.168.25.10]) by blah.sun-fish.com (Postfix) with ESMTP id D74BC1B10EE7; Tue, 15 Jan 2008 09:06:54 +0100 (CET) Message-ID: <478C699E.8080105@moneybookers.com> Date: Tue, 15 Jan 2008 10:06:54 +0200 From: Stefan Lambrev User-Agent: Thunderbird 2.0.0.9 (X11/20071120) MIME-Version: 1.0 To: thierry@herbelot.com References: <200801150656.22319.thierry@herbelot.com> In-Reply-To: <200801150656.22319.thierry@herbelot.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/5483/Mon Jan 14 15:45:01 2008 on blah.cmotd.com X-Virus-Status: Clean Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Linux SMP network performance measurements 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: Tue, 15 Jan 2008 08:07:02 -0000 Greetings, Thierry Herbelot wrote: > Hello, > > a recent article > (http://www.ibm.com/developerworks/linux/library/l-scalability/?ca=dgr-lnxw02FasterLinuxNet) > gives some measurements on various tweakings of an SMP machine with 4 Xeon > processors (it *shows* a nice improvement when using more CPUs and more > bonded Ethernet interfaces). > > Has some the machine (and the time, obviously) to make some of the same > measurements with the latest FreeBSD versions ? > I'm planning to test network performance on FreeBSD + bridged interfaces, very soon, but my test servers are not so powerful as the server from this page :) Best that I'll have is 1x quad core processor, 4 port gigabit intel network card and 2GB RAM. But I think this should be enough for tests. When I have some results/question I'll post to -performance :) > TfH > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Best Wishes, Stefan Lambrev ICQ# 24134177 From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 08:17:04 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 2BBB716A41A for ; Tue, 15 Jan 2008 08:17:04 +0000 (UTC) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.freebsd.org (Postfix) with ESMTP id 0E4EF13C46A for ; Tue, 15 Jan 2008 08:17:03 +0000 (UTC) (envelope-from randy@psg.com) Received: from [202.214.86.183] by rip.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1JEgyl-000Mqx-3U for freebsd-net@freebsd.org; Tue, 15 Jan 2008 08:17:03 +0000 Message-ID: <478C6BF4.8010606@psg.com> Date: Tue, 15 Jan 2008 17:16:52 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: FreeBSD Net X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: 802.11abg pci recco 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: Tue, 15 Jan 2008 08:17:04 -0000 i am putting in a newegg order for when i visit the states in two weeks. among other goodies, i may need a pci 802.11 card to work with current in a soekris 5501 (see minipci saga elsewhere). what is smack on compatible and solid? thanks. randy From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 09:59:25 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 CE56916A417; Tue, 15 Jan 2008 09:59:25 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog13.obsmtp.com (s200aog13.obsmtp.com [207.126.144.127]) by mx1.freebsd.org (Postfix) with SMTP id DED8813C457; Tue, 15 Jan 2008 09:59:24 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob013.postini.com ([207.126.147.11]) with SMTP; Tue, 15 Jan 2008 09:59:23 UTC Received: from bill.mintel.co.uk (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 68C5218141E; Tue, 15 Jan 2008 09:59:23 +0000 (GMT) Message-ID: <478C83FA.7070907@tomjudge.com> Date: Tue, 15 Jan 2008 09:59:22 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <478B7AB7.5010208@tomjudge.com> <478B88EE.7090307@FreeBSD.org> <478B9020.3000402@tomjudge.com> <478B982B.304@FreeBSD.org> <478BAC60.9030506@tomjudge.com> <478BAE70.9050702@FreeBSD.org> In-Reply-To: <478BAE70.9050702@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Programming interface MAC filter without enabling PROMISC on an interface from user space. 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: Tue, 15 Jan 2008 09:59:25 -0000 Bruce M. Simpson wrote: > Tom Judge wrote: >> Personally I can't see why this approach would be a problem, but I am >> not a expert. The address is defined in IEEE Std 802.1D-2004 as to >> not be forwarded by bridges (which I interpret as it being link local >> in a sense as switches/bridges are not allowed to forward the frame), >> so I can't see it being a problem registered on multiple interfaces. > > SIOCADDMULTI memberships are specific to the interface you request them > on. I can't speak for the bridging code -- I don't think it does any > special handling of multicast frames, however I'm not sure if it's smart > enough not to forward this group. Like IN_LOCALGROUP() it might need its > own 'don't forward this' clause. > Just for the record it seems that if_bridge replaces the destination MAC of a Ethernet multicast packet with its own MAC therefore making sure that the packets are not forwarded. Andrew can you confirm this assumption? (Based on sys/net/if_bridge.c lines 2011-2018 on RELENG_6_2) Tom From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 12:33:08 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 AADF316A419 for ; Tue, 15 Jan 2008 12:33:08 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from munchkin.clue.co.za (munchkin.clue.co.za [66.219.59.160]) by mx1.freebsd.org (Postfix) with ESMTP id 9003E13C442 for ; Tue, 15 Jan 2008 12:33:08 +0000 (UTC) (envelope-from ianf@clue.co.za) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=20070313; d=clue.co.za; h=Received:Received:Received:To:cc:From:Subject:In-Reply-To:X-Attribution:Date:Message-Id; b=cdZFh4ef7gB2K8vzP3n15TRkzjtbC+lKbgVGcVEzVIJ+91m9+aT8S1M3CsrFenCvUJ+ke+c1Xt4DQiwwJ6YcwZq49Pl1MKXWqqzf2R37h5Ze1xZq5ZB5jvgUMEVWg5qqmYdG+CnDxk4Mw+ACSsWNfE9uYRg2ozsDPbznERuej1A/sA4GU/tSESHkOEnLicb+xRzApheZ1TDOE4MRz59OoVxeWQrbMi0iRFpT2qj6hRsUXqWYPqx8W0S1GXZj8kGf; Received: from uucp by munchkin.clue.co.za with local-rmail (Exim 4.67) (envelope-from ) id 1JEkcJ-00041U-EV; Tue, 15 Jan 2008 12:10:07 +0000 Received: from dsl-241-38-20.telkomadsl.co.za ([41.241.38.20] helo=clue.co.za) by urchin.clue.co.za with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1JEkbS-0004vA-Dc; Tue, 15 Jan 2008 12:09:14 +0000 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1JEkbQ-0001bz-Of; Tue, 15 Jan 2008 14:09:12 +0200 To: Stefan Lambrev From: Ian FREISLICH In-Reply-To: Message from Stefan Lambrev of "Tue, 15 Jan 2008 10:06:54 +0200." <478C699E.8080105@moneybookers.com> X-Attribution: BOFH Date: Tue, 15 Jan 2008 14:09:12 +0200 Message-Id: Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, thierry@herbelot.com Subject: Re: Linux SMP network performance measurements 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: Tue, 15 Jan 2008 12:33:08 -0000 Stefan Lambrev wrote: > Thierry Herbelot wrote: > > gives some measurements on various tweakings of an SMP machine with > > 4 Xeon processors (it *shows* a nice improvement when using more > > CPUs and more bonded Ethernet interfaces). > > > > Has some the machine (and the time, obviously) to make some of the > > same measurements with the latest FreeBSD versions ? > > I'm planning to test network performance on FreeBSD + bridged > interfaces, very soon, but my test servers are not so powerful as > the server from this page :) Best that I'll have is 1x quad core > processor, 4 port gigabit intel network card and 2GB RAM. I did some testing about a year or two ago and with a recent current of about 2 months ago. I found that generally SMP was a performance regression for the workload I tested - forwarding and filtering. The single most significant contributer to network performance is level 1 cache size. I believe that the extreme cost of mutex acquisition on Intel cpus is the main culprit for SMP network performance regression. Coupled with miniscule L1 cache size on the entire Intel CPU product line gives pretty poor network performance. Forwarding (routing between multiple interfaces) and filtering (ipfw) IIRC with quad Intel e1000 NIC: Dual Intel Xeon 2.8GHz: 240Kpps 12k L1 cache Single Intel Xeon 2.8GHz: 380Kpps 12k L1 cache Core 2 Duo 1.8Ghz: 420kpps 12k L1 cache Single Pentium-M 1.8GHz: 550Kpps 32k L1 cache Dual AMD opteron 2GHz: 890Kpps 64k L1 cache Single AMD opteron 2GHz: 970Kpps 64k L1 cache All these hosts had 255 vlan interfaces with about 3000 routes and about 30000 firewall rules, with a good spread of packets between the interfaces with polling and fastforwarding. I struggled to generate enough packets to load the AMD routers. I was interested in SMP due to additional processing for netflow accounting and packet rate monitoring for DDoS detection and mitigation. I recomend to anyone using FreeBSD as a router or for any serious workload to just plain forget about using Intel CPUs. Ian -- Ian Freislich From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 14:25:31 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 A735216A41B; Tue, 15 Jan 2008 14:25:31 +0000 (UTC) (envelope-from lolo@agneau.org) Received: from bergerie.agneau.org (bergerie.agneau.org [88.173.248.15]) by mx1.freebsd.org (Postfix) with ESMTP id 7F4C813C4CE; Tue, 15 Jan 2008 14:25:31 +0000 (UTC) (envelope-from lolo@agneau.org) Received: by bergerie.agneau.org (Postfix, from userid 500) id 2B4D8108A75; Tue, 15 Jan 2008 15:25:30 +0100 (CET) Date: Tue, 15 Jan 2008 15:25:30 +0100 From: Laurent Frigault To: Sepherosa Ziehau Message-ID: <20080115142530.GA25951@obelix.bergerie.agneau.org> References: <200801071728.m07HSsFl030966@freefall.freebsd.org> <20080114160756.GA7716@obelix.bergerie.agneau.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Powered-By: UUCP Cc: freebsd-net@freebsd.org, remko@freebsd.org Subject: Re: kern/119361: [bge] bge(4) transmit performance problem 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: Tue, 15 Jan 2008 14:25:31 -0000 On Tue, Jan 15, 2008 at 08:56:36AM +0800, Sepherosa Ziehau wrote: > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=119361 > > > > > > Have you tested polling(4)? If polling could give you better TX > > > performance, you should consider raise: > > > in bge_attach() > > > sc->bge_tx_max_coal_bds = 10; > > > to 64 or more > > > > I tested with polling and did not see any changes for the transmit > > performance problem. > > > > I just re-test with polling AND bge_tx_max_coal_bds raised to 64 => no > > changes. > > Please test following patch: > http://people.freebsd.org/~sephe/if_bge.c.6.diff I apply your patch and re-run the test (without and with polling) => no changes. Best Regards, -- Laurent Frigault | UNIX _IS_ user friendly. It's just selective about who its friends are. From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 19:54:41 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 D7F4216A421 for ; Tue, 15 Jan 2008 19:54:41 +0000 (UTC) (envelope-from nullpt@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id BA28813C448 for ; Tue, 15 Jan 2008 19:54:41 +0000 (UTC) (envelope-from nullpt@gmail.com) Received: by wa-out-1112.google.com with SMTP id k17so4732829waf.3 for ; Tue, 15 Jan 2008 11:54:41 -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:mime-version:content-type; bh=FLscZ2jTqO1KVSJLDec5qLostHShsH52e40aEjmZrzk=; b=CqXzVtOGEcme7fXPDXMz2Rwd17Pwb37z3PnBB9xkryae/FJygjPVn/htAVCqrSknfIDAEHY0SAKbDmSAIeiJWCeqPzumT2uNRS3ZS9A7G9+ODCxbITGvWOU4RAXP7zVWrSs20SWjJgm+zlD1g8qi5Usrk8+IxuMoBHI1nOrFXQI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=S2M4OOP4VwgpCjCbdO3GoP9qBLcdajOa06ORLx2ZxGHXoLbrpmPUtPOXgfTgD1vXZ/hzMi9Lie6i1PpIZcVTiCC3h4axMB28Hn4RTc0l8Nal/4+/f2iLa6V4hm4LZONVaWGGCQgXsqqvYvsq24+NEPQEctBLg2I13NlSZahWPG8= Received: by 10.114.150.1 with SMTP id x1mr5235313wad.46.1200425361657; Tue, 15 Jan 2008 11:29:21 -0800 (PST) Received: by 10.114.240.9 with HTTP; Tue, 15 Jan 2008 11:29:21 -0800 (PST) Message-ID: <755cb9fc0801151129h6e519557g7ea33e4190196fed@mail.gmail.com> Date: Tue, 15 Jan 2008 19:29:21 +0000 From: "Alexandre Vieira" To: freebsd-pf@freebsd.org, freebsd-questions@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Relayd (former hoststated) status for freebsd 7.0RC1 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: Tue, 15 Jan 2008 19:54:41 -0000 Hello all, I remember that there was a port (net/hoststated) where I could install hoststated to use with PF. Anyone can shed a light on what is the status of this software implementation on 7.0? TIA -- Alexandre Vieira - nullpt@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 20:00:46 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 7616E16A41A; Tue, 15 Jan 2008 20:00:46 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id 1DFCC13C458; Tue, 15 Jan 2008 20:00:46 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id B450E74B8; Wed, 16 Jan 2008 08:48:04 +1300 (NZDT) Date: Wed, 16 Jan 2008 08:48:04 +1300 From: Andrew Thompson To: Tom Judge Message-ID: <20080115194804.GA10076@heff.fud.org.nz> References: <478B7AB7.5010208@tomjudge.com> <478B88EE.7090307@FreeBSD.org> <478B9020.3000402@tomjudge.com> <478B982B.304@FreeBSD.org> <478BAC60.9030506@tomjudge.com> <478BAE70.9050702@FreeBSD.org> <478C83FA.7070907@tomjudge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <478C83FA.7070907@tomjudge.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net@freebsd.org, "Bruce M. Simpson" Subject: Re: Programming interface MAC filter without enabling PROMISC on an interface from user space. 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: Tue, 15 Jan 2008 20:00:46 -0000 On Tue, Jan 15, 2008 at 09:59:22AM +0000, Tom Judge wrote: > Bruce M. Simpson wrote: >> Tom Judge wrote: > >>> Personally I can't see why this approach would be a problem, but I am >>> not a expert. The address is defined in IEEE Std 802.1D-2004 as to not >>> be forwarded by bridges (which I interpret as it being link local in a >>> sense as switches/bridges are not allowed to forward the frame), so I >>> can't see it being a problem registered on multiple interfaces. >> SIOCADDMULTI memberships are specific to the interface you request them >> on. I can't speak for the bridging code -- I don't think it does any >> special handling of multicast frames, however I'm not sure if it's smart >> enough not to forward this group. Like IN_LOCALGROUP() it might need its >> own 'don't forward this' clause. > > > Just for the record it seems that if_bridge replaces the destination MAC of > a Ethernet multicast packet with its own MAC therefore making sure that the > packets are not forwarded. Andrew can you confirm this assumption? (Based > on sys/net/if_bridge.c lines 2011-2018 on RELENG_6_2) No, the only multicast address that the bridge does not forward is the STP one (01:80:c2:00:00:00). It will pass LLDP frames. Andrew From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 20:24:59 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 5C03916A46B; Tue, 15 Jan 2008 20:24:59 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by mx1.freebsd.org (Postfix) with ESMTP id 375DC13C458; Tue, 15 Jan 2008 20:24:58 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 73EA28A5B2; Tue, 15 Jan 2008 15:24:58 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 15 Jan 2008 15:24:58 -0500 X-Sasl-enc: f+RIxgWQUf8h+Z2/rNcoiWpz/0zHocnMRs3QAGcBqyHq 1200428698 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 5C07E2A5B6; Tue, 15 Jan 2008 15:24:56 -0500 (EST) Message-ID: <478D1694.8010906@FreeBSD.org> Date: Tue, 15 Jan 2008 20:24:52 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: Alexandre Vieira References: <755cb9fc0801151129h6e519557g7ea33e4190196fed@mail.gmail.com> In-Reply-To: <755cb9fc0801151129h6e519557g7ea33e4190196fed@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Relayd (former hoststated) status for freebsd 7.0RC1 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: Tue, 15 Jan 2008 20:24:59 -0000 Alexandre Vieira wrote: > Hello all, > > I remember that there was a port (net/hoststated) where I could install > hoststated to use with PF. Anyone can shed a light on what is the status of > this software implementation on 7.0? > Perhaps ports/net/ifstated is the answer? BMS From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 20:29:56 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 A60A316A46C; Tue, 15 Jan 2008 20:29:56 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from mail.comstyle.com (unknown [IPv6:2001:16d8:ffe8:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 29CFA13C474; Tue, 15 Jan 2008 20:29:56 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from [192.168.3.30] (toronto-hs-216-138-195-228.s-ip.magma.ca [216.138.195.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: brad) by mail.comstyle.com (Postfix) with ESMTP id 24F7982D2F; Tue, 15 Jan 2008 21:29:36 +0100 (CET) From: Brad To: freebsd-net@freebsd.org Date: Tue, 15 Jan 2008 15:29:32 -0500 User-Agent: KMail/1.9.7 References: <755cb9fc0801151129h6e519557g7ea33e4190196fed@mail.gmail.com> <478D1694.8010906@FreeBSD.org> In-Reply-To: <478D1694.8010906@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801151529.32312.brad@comstyle.com> X-comstyle-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 24F7982D2F.E1AC8 X-comstyle-MailScanner: Found to be clean X-comstyle-MailScanner-From: brad@comstyle.com X-Spam-Status: No Cc: freebsd-questions@freebsd.org, freebsd-pf@freebsd.org Subject: Re: Relayd (former hoststated) status for freebsd 7.0RC1 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: Tue, 15 Jan 2008 20:29:56 -0000 On Tuesday 15 January 2008 15:24:52 Bruce M. Simpson wrote: > Alexandre Vieira wrote: > > Hello all, > > > > I remember that there was a port (net/hoststated) where I could install > > hoststated to use with PF. Anyone can shed a light on what is the status of > > this software implementation on 7.0? > > > > Perhaps ports/net/ifstated is the answer? > > BMS ifstated and relayd (used to be hoststated) are for totally different purposes. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-net@FreeBSD.ORG Tue Jan 15 21:59:01 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 BE6A216A418 for ; Tue, 15 Jan 2008 21:59:01 +0000 (UTC) (envelope-from nullpt@gmail.com) Received: from ro-out-1112.google.com (ro-out-1112.google.com [72.14.202.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6321913C461 for ; Tue, 15 Jan 2008 21:59:01 +0000 (UTC) (envelope-from nullpt@gmail.com) Received: by ro-out-1112.google.com with SMTP id m6so3302008roe.13 for ; Tue, 15 Jan 2008 13:59:00 -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:references; bh=Ym8y8GH5UcmxbUZ8yVwvuDfB5grWG6G/zhpNqt4L1cQ=; b=akqqTReflPUeXz9AlkIsnj/u9twVmwcL3XWP/dLRCgxWTSSf5IKKOCDPlhwzqI1cit7DgtlsR45aUJuufCgNo83OSyoIYRnnCTwzvrHkcePW3XDRnAFJZlUh+pR2zQTb/tw2c2Piyh0WBKCmtRYT3Kibg80lPBDDzggCmPQLWqY= 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:references; b=Q3mAzUSVIsfMeiUuYF9xeOEFcpjXD8Zaa7UCaQeRxCtKegVreerMnf49ZMYQj/1Www7PHWIi3kfiVkiXVaO3tBxGlauwy+gNjfjzrLfbydpacMKJckQA6QUVjQW8mU4jq/4yHBJwZuPjHJYmE/XQF1Oy4i7s7LuqfqEwpIxP4WY= Received: by 10.114.53.1 with SMTP id b1mr5510078waa.134.1200434339413; Tue, 15 Jan 2008 13:58:59 -0800 (PST) Received: by 10.114.240.9 with HTTP; Tue, 15 Jan 2008 13:58:59 -0800 (PST) Message-ID: <755cb9fc0801151358k35cdd267x7500767925e5f3cc@mail.gmail.com> Date: Tue, 15 Jan 2008 21:58:59 +0000 From: "Alexandre Vieira" To: freebsd-net@freebsd.org, freebsd-questions@freebsd.org, freebsd-pf@freebsd.org In-Reply-To: <200801151529.32312.brad@comstyle.com> MIME-Version: 1.0 References: <755cb9fc0801151129h6e519557g7ea33e4190196fed@mail.gmail.com> <478D1694.8010906@FreeBSD.org> <200801151529.32312.brad@comstyle.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: flz@FreeBSD.org Subject: Re: Relayd (former hoststated) status for freebsd 7.0RC1 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: Tue, 15 Jan 2008 21:59:01 -0000 On Jan 15, 2008 8:29 PM, Brad wrote: > On Tuesday 15 January 2008 15:24:52 Bruce M. Simpson wrote: > > Alexandre Vieira wrote: > > > Hello all, > > > > > > I remember that there was a port (net/hoststated) where I could > install > > > hoststated to use with PF. Anyone can shed a light on what is the > status of > > > this software implementation on 7.0? > > > > > > > Perhaps ports/net/ifstated is the answer? > > > > BMS > > ifstated and relayd (used to be hoststated) are for totally different > purposes. > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > Hi, I meant hostated aka hoststated aka relayd. It's in Obsd base system and had there was a port for freebsd not long ago. I've found the old port structure: http://people.freebsd.org/~flz/local/ports/hoststated/ which stands for ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/local-distfiles/flz/hoststated/hoststated-20070131.tgz. Many changes were commited since 07/01/31: http://kho.bonghongxanh.vn/pub/.disk0/ftp.openbsd.org/pub/OpenBSD/cvs/src/usr.sbin/relayd/Makefile,v Added flz@ to the loop. TIA for any effort to get this working. Kind Regards -- Alexandre Vieira - nullpt@gmail.com From owner-freebsd-net@FreeBSD.ORG Wed Jan 16 06:41:32 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 AECE416A41A for ; Wed, 16 Jan 2008 06:41:32 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.freebsd.org (Postfix) with ESMTP id 4CCAA13C44B for ; Wed, 16 Jan 2008 06:41:32 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so228522pyb.10 for ; Tue, 15 Jan 2008 22:41:30 -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:mime-version:content-type:content-transfer-encoding:content-disposition; bh=bsWSgrxea1a5y6IFFqwOzmFgK5jv5KhM3SD2wxLMRmk=; b=KGqNxucVjZ8a7YsYUw2Fd/3oKrtfGNKG1lQapCEw8T/fZ79m+8KoAh01thJPZGEkFOrGby4Er7ddP6zASHbehUvRvVUvjNeonkGum8toiHOstIkG4dbwBegkA3MNHmcmhvvddJwYN8JxVYx8dhTPweWIWwnGo0kkEDt2a/jPk+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=kMYxdIU+kwI2LWUmiY0DnVOHFMsua5vfpOCH1OwXqxZ3pd23RgZ9tAI3A+qmeHRt6BH1e7kWqotMwsbU9ySrKfsPf9e+dlD4gvhmxCWELDAgeBHfF6WThVh/v6yhgiWqpZx0y+Nis9I92ZUV94i1XTTg3Jk/8dSKFbz+Jm0er7Q= Received: by 10.64.199.2 with SMTP id w2mr930961qbf.11.1200464059276; Tue, 15 Jan 2008 22:14:19 -0800 (PST) Received: by 10.64.179.20 with HTTP; Tue, 15 Jan 2008 22:14:19 -0800 (PST) Message-ID: Date: Wed, 16 Jan 2008 01:14:19 -0500 From: "Michael MacLeod" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: 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: Wed, 16 Jan 2008 06:41:32 -0000 Hello all, I've got two DSL lines running to my house, and two WAN NIC's installed in my FreeBSD router. I've been trying to get multilink ppp working through my ISP (TekSavvy in Canada) for the last little while, with mixed results. Each of my DSL lines sync's at 6016 kbits down and 800 kbits up. I have traffic working through the bonded connection, and the upload speed is 1350 kb, which is about right for a 1.6 megabit connection minus network overhead. The problem I'm running into is the download speed is only that of one of my downlinks (approx 5000kb, which is about right for 6 megabits minus network overhead). TekSavvy enabled packet splitting on the upload side of my connection, but are being cautious and only doing round-robin packets for the download side. I assume they are worried about collateral damage to non-multilink ppp users. I've posted to the dslreports teksavvy forum about my problem, and another FreeBSD user posted parts of his config and some speedtests that show that he has his download running at the full bonded speed. I've also received still another ppp.conf file from another FreeBSD user from the dslreports forums who was also able to get full bonded download speeds. This leads me to believe that there's something specific to my setup that is causing the problem. In discussions on the dslreports forums I've compared my sysctl output for net.inet.tcp with someone successfully getting full download speed, so it doesn't seem to be there, though it could certainly be elsewhere in sysctl. I'm already using ppp.conf files from someone who's successfully made their download go full speed. It could be a kernel option, but the other two users haven't reported changing anything special in the kernel. Unfortunately, I'm relatively new to FreeBSD, so I'm not sure where else to look. I've documented large parts of the setup, and my problems, on a wiki page here: http://bsdtips.utcorp.net/mediawiki/index.php/Mersault/MultiLink_PPP And here are the important threads from the dslreports forums: http://www.dslreports.com/forum/r19513042-MultiLink-PPP-Performance http://www.dslreports.com/forum/r19719787-Still-Having-Multilink-PPP-Problems If anyone has any ideas of where to look next, I'd be very grateful. Mike From owner-freebsd-net@FreeBSD.ORG Wed Jan 16 07:17:24 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 32DF016A41B for ; Wed, 16 Jan 2008 07:17:24 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outU.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 0999A13C46B for ; Wed, 16 Jan 2008 07:17:24 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Tue, 15 Jan 2008 23:17:23 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id D8C47126F09; Tue, 15 Jan 2008 23:17:22 -0800 (PST) Message-ID: <478DAF82.8010702@elischer.org> Date: Tue, 15 Jan 2008 23:17:22 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Michael MacLeod References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org 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: Wed, 16 Jan 2008 07:17:24 -0000 Michael MacLeod wrote: > Hello all, > > I've got two DSL lines running to my house, and two WAN NIC's > installed in my FreeBSD router. I've been trying to get multilink ppp > working through my ISP (TekSavvy in Canada) for the last little while, > with mixed results. Each of my DSL lines sync's at 6016 kbits down and > 800 kbits up. I have traffic working through the bonded connection, > and the upload speed is 1350 kb, which is about right for a 1.6 > megabit connection minus network overhead. The problem I'm running > into is the download speed is only that of one of my downlinks (approx > 5000kb, which is about right for 6 megabits minus network overhead). > > TekSavvy enabled packet splitting on the upload side of my connection, > but are being cautious and only doing round-robin packets for the > download side. I assume they are worried about collateral damage to > non-multilink ppp users. I've posted to the dslreports teksavvy forum > about my problem, and another FreeBSD user posted parts of his config > and some speedtests that show that he has his download running at the > full bonded speed. I've also received still another ppp.conf file from > another FreeBSD user from the dslreports forums who was also able to > get full bonded download speeds. This leads me to believe that there's > something specific to my setup that is causing the problem. > > In discussions on the dslreports forums I've compared my sysctl output > for net.inet.tcp with someone successfully getting full download > speed, so it doesn't seem to be there, though it could certainly be > elsewhere in sysctl. I'm already using ppp.conf files from someone > who's successfully made their download go full speed. It could be a > kernel option, but the other two users haven't reported changing > anything special in the kernel. Unfortunately, I'm relatively new to > FreeBSD, so I'm not sure where else to look. > > I've documented large parts of the setup, and my problems, on a wiki page here: > http://bsdtips.utcorp.net/mediawiki/index.php/Mersault/MultiLink_PPP > > And here are the important threads from the dslreports forums: > http://www.dslreports.com/forum/r19513042-MultiLink-PPP-Performance > http://www.dslreports.com/forum/r19719787-Still-Having-Multilink-PPP-Problems > > If anyone has any ideas of where to look next, I'd be very grateful. a couple of things... 1/ when downloading, does the load on each incoming interface (I assume you have one ethernet to each modem) match? 2/ do the IP stats show a lot of out-of order packets? (netstat -s -ptcp I think) in fact ip reassembly problems might be of interest. (netstat -s -pip (?)) 3/are there many retransmissions? 4/ what is the outgoing data bandwidth when you are downloading? 5/ have you tried mpd? (in ports (multilink ppp daemon).) it may have different operating characteristics.. (it does it all in the kernel using netgraph). Sounds like you need to fix it at the other end but mpd might trigger different behaviour in the router. > > Mike > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Jan 16 07:44:08 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 3DF1A16A417 for ; Wed, 16 Jan 2008 07:44:08 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9316413C457 for ; Wed, 16 Jan 2008 07:44:06 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so252786pyb.10 for ; Tue, 15 Jan 2008 23:44:05 -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=LE1QR3SBpIKr7C/lu6KD/SW3nTY4Rc7r+m5GFYVPpu4=; b=Q3Vt914UUKLXIXqiAIbaA2G4TvN26SpufyIYmq0oyDxzxUAgx5DsP4pTB3CIEcZQtxN4q45R027c4yMG5Pv1ChjmVUDVMwOF3W02SY6mrpppHIMkGW3MWGuowFRJ1aeqAV1QZ4QZyugGdmSPcelr3ttksMFYX3V+GE/T3mYyUHs= 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=FjCPxYLUtTaXOvgAN0yWqXuCBQa1CMR5Iz5Z573pb83+LwyZbDYOaEAPGSjT4WOz01imK6+N5yPlG4mqAsRVuNUSGwMKXjmkVRRhWBwoiT6FH5tUMLh8wcoMlcH+pNOR9aF5mPkkhfj1K7F+dg1DLy8ZJ2a/l3PcohtCaOmyFD8= Received: by 10.65.15.19 with SMTP id s19mr1067861qbi.17.1200469445376; Tue, 15 Jan 2008 23:44:05 -0800 (PST) Received: by 10.64.179.20 with HTTP; Tue, 15 Jan 2008 23:44:05 -0800 (PST) Message-ID: Date: Wed, 16 Jan 2008 02:44:05 -0500 From: "Michael MacLeod" To: "Julian Elischer" In-Reply-To: <478DAF82.8010702@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <478DAF82.8010702@elischer.org> Cc: freebsd-net@freebsd.org 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: Wed, 16 Jan 2008 07:44:08 -0000 On Jan 16, 2008 2:17 AM, Julian Elischer wrote: > 1/ when downloading, does the load on each incoming interface > (I assume you have one ethernet to each modem) match? This is a pretty rough way to estimate it, but starting/stopping tcpdump on each of the interfaces at the same time suggests the load is balanced down each link pretty evenly. There's a lot of inbound traffic right now, as a friend is sending me a file right now. Most of the other tools I'm used to working with to watch traffic only want to work on the tun0 interface created by ppp. > 2/ do the IP stats show a lot of out-of order packets? > (netstat -s -ptcp I think) > in fact ip reassembly problems might be of interest. > (netstat -s -pip (?)) > 3/are there many retransmissions? # netstat -s -ptcp tcp: 144824 packets sent 88543 data packets (117925386 bytes) 34 data packets (45103 bytes) retransmitted 6 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 49084 ack-only packets (1022 delayed) 0 URG only packets 0 window probe packets 7156 window update packets 42 control packets 140315 packets received 42211 acks (for 117742680 bytes) 7009 duplicate acks 0 acks for unsent data 90610 packets (117590676 bytes) received in-sequence 5665 completely duplicate packets (0 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 45 out-of-order packets (64530 bytes) 0 packets (0 bytes) of data after window 0 window probes 640 window update packets 0 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short < snip > # netstat -s -pip ip: 2143677 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 149764 packets for this host 0 packets for unknown/unsupported protocol 1986854 packets forwarded (0 packets fast forwarded) 651 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 156851 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header So it looks like the connection is pretty decent, though admittedly I haven't seen what these stats should look like on a non-multilink ppp connection. However, empirically my VoIP traffic doesn't suffer from jitter or choppiness, so I'm going to go out on a limb and say the connection is pretty decent. > 4/ what is the outgoing data bandwidth when you are downloading? I've been tuning my pf firewall to do outbound traffic shaping, so I'm not swamping the ack packets in either direction. I can basically run the pipe at 5000kb down and 1350kb up consistently. > 5/ have you tried mpd? (in ports (multilink ppp daemon).) > it may have different operating characteristics.. (it does it all > in the kernel using netgraph). Sounds like you need to fix it > at the other end but mpd might trigger different behaviour > in the router. I looked into mpd first. I tried several of the ports (mpd, mpd4, and mpd5) all without much success. There isn't much documentation for mpd (at least compared to the standard userland ppp). Also, both of the individuals who I know have successfully used multilink ppp and TekSavvy are using userland ppp. I'd be happy to use mpd, except that I'm *almost* there with userland ppp, and I'm guessing it's something I've overlooked or misconfigered somewhere and once I find and correct it, it'll work like a charm. A bit more info about the connection: I'm using pf to do my firewalling. My pf.conf includes some packet reassembly bits that one of the other successful guys at dslreports sent me. The wan nic's are 3com (xl) cards, and my lan and dmz cards are both Intel gigabit (em) cards. The router itself is an older dual PIII 550Mhz rackmount server I got from my place of employment with plenty of ram. Previously I'd used an older PIII 933Mhz computer I had lying around, with two realtek (rl) cards for the wan nic's, and I ran into the same problems, so I can assume it's not the hardware either. From owner-freebsd-net@FreeBSD.ORG Wed Jan 16 10:04:49 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 BAB4916A468 for ; Wed, 16 Jan 2008 10:04:49 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: from wmail.teledomenet.gr (wmail.teledomenet.gr [213.142.128.16]) by mx1.freebsd.org (Postfix) with ESMTP id 340B213C4D3 for ; Wed, 16 Jan 2008 10:04:49 +0000 (UTC) (envelope-from nvass@teledomenet.gr) Received: by wmail.teledomenet.gr (Postfix, from userid 1002) id 324EA1C80BA; Wed, 16 Jan 2008 12:04:48 +0200 (EET) X-Spam-Checker-Version: SpamAssassin 3.1.7-deb (2006-10-05) on wmail.teledomenet.gr X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7-deb Received: from iris (unknown [192.168.1.71]) by wmail.teledomenet.gr (Postfix) with ESMTP id E3E151C80BA; Wed, 16 Jan 2008 12:04:43 +0200 (EET) From: Nikos Vassiliadis To: freebsd-net@freebsd.org Date: Wed, 16 Jan 2008 12:04:23 +0200 User-Agent: KMail/1.9.7 References: <478DAF82.8010702@elischer.org> In-Reply-To: X-NCC-RegID: gr.telehouse MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801161204.23905.nvass@teledomenet.gr> Cc: Michael MacLeod , Julian Elischer 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: Wed, 16 Jan 2008 10:04:49 -0000 On Wednesday 16 January 2008 09:44:05 Michael MacLeod wrote: > On Jan 16, 2008 2:17 AM, Julian Elischer wrote: > > 1/ when downloading, does the load on each incoming interface > > (I assume you have one ethernet to each modem) match? > > This is a pretty rough way to estimate it, but starting/stopping > tcpdump on each of the interfaces at the same time suggests the load > is balanced down each link pretty evenly. There's a lot of inbound > traffic right now, as a friend is sending me a file right now. Most of > the other tools I'm used to working with to watch traffic only want to > work on the tun0 interface created by ppp. use "netstat -I xl0 -w 1", "netstat -I xl1 -w 1" and "netstat -I tun0 -w 1" or "systat -ifstat" for an interactive terminal display. > > 2/ do the IP stats show a lot of out-of order packets? > > (netstat -s -ptcp I think) > > in fact ip reassembly problems might be of interest. > > (netstat -s -pip (?)) > > 3/are there many retransmissions? > > # netstat -s -ptcp > tcp: > 144824 packets sent > 88543 data packets (117925386 bytes) > 34 data packets (45103 bytes) retransmitted > 6 data packets unnecessarily retransmitted > 0 resends initiated by MTU discovery > 49084 ack-only packets (1022 delayed) > 0 URG only packets > 0 window probe packets > 7156 window update packets > 42 control packets > 140315 packets received > 42211 acks (for 117742680 bytes) > 7009 duplicate acks > 0 acks for unsent data > 90610 packets (117590676 bytes) received in-sequence > 5665 completely duplicate packets (0 bytes) > 0 old duplicate packets > 0 packets with some dup. data (0 bytes duped) > 45 out-of-order packets (64530 bytes) > 0 packets (0 bytes) of data after window > 0 window probes > 640 window update packets > 0 packets received after close > 0 discarded for bad checksums > 0 discarded for bad header offset fields > 0 discarded because packet too short > < snip > > > # netstat -s -pip > ip: > 2143677 total packets received > 0 bad header checksums > 0 with size smaller than minimum > 0 with data size < data length > 0 with ip length > max ip packet size > 0 with header length < data size > 0 with data length < header length > 0 with bad options > 0 with incorrect version number > 0 fragments received > 0 fragments dropped (dup or out of space) > 0 fragments dropped after timeout > 0 packets reassembled ok > 149764 packets for this host > 0 packets for unknown/unsupported protocol > 1986854 packets forwarded (0 packets fast forwarded) > 651 packets not forwardable > 0 packets received for unknown multicast group > 0 redirects sent > 156851 packets sent from this host > 0 packets sent with fabricated ip header > 0 output packets dropped due to no bufs, etc. > 0 output packets discarded due to no route > 0 output datagrams fragmented > 0 fragments created > 0 datagrams that can't be fragmented > 0 tunneling packets that can't find gif > 0 datagrams with bad address in header > > So it looks like the connection is pretty decent, though admittedly I > haven't seen what these stats should look like on a non-multilink ppp > connection. However, empirically my VoIP traffic doesn't suffer from > jitter or choppiness, so I'm going to go out on a limb and say the > connection is pretty decent. Though it seems that most of the traffic is forwarded and thus the FreeBSD host will not get much TCP. So, you wouldn't know much of the retransmissions happening. You could use 2-3 instances of "fetch ftp://somewhere/something" in parallel to fully utilize your DSL lines from your FreeBSD box. [snip] > > 5/ have you tried mpd? (in ports (multilink ppp daemon).) > > it may have different operating characteristics.. (it does it all > > in the kernel using netgraph). Sounds like you need to fix it > > at the other end but mpd might trigger different behaviour > > in the router. > > I looked into mpd first. I tried several of the ports (mpd, mpd4, and > mpd5) all without much success. There isn't much documentation for mpd > (at least compared to the standard userland ppp). No, mpd is adequately documented. /usr/local/share/doc/mpd* > Also, both of the > individuals who I know have successfully used multilink ppp and > TekSavvy are using userland ppp. I'd be happy to use mpd, except that > I'm *almost* there with userland ppp, and I'm guessing it's something > I've overlooked or misconfigered somewhere and once I find and correct > it, it'll work like a charm. If you are willing to try mpd, you can find a multilink PPPoE setup here: http://lists.freebsd.org/pipermail/freebsd-questions/2007-September/157110.html You can use the above example with mpd4. HTH, Nikos From owner-freebsd-net@FreeBSD.ORG Wed Jan 16 18:02:51 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 9C91C16A419 for ; Wed, 16 Jan 2008 18:02:51 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by mx1.freebsd.org (Postfix) with ESMTP id 4152213C45A for ; Wed, 16 Jan 2008 18:02:51 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so496856pyb.10 for ; Wed, 16 Jan 2008 10:02:50 -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=QyWI+EbjqNizzn4U+JOb3CmU1wEAZsl+AS2spRdBbFM=; b=kHIPT0+0q+XwoC1XBy8KFyiYoIDYzB8Vlk31DByMZhatz7eC/IrrMTU2GfDksNnpebYFJKTItZAd0NSlaSpVURWEqxQO1EFsbKyE//g5n0DBjmrUag/0TjqiN+NXLaXGW6MWU/1bpAKQb+E/l8f3f5EiU+HcSdWBNbUvL3XjWLs= 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=o6wHaBrD50LvJuxIHiDEgWdg8Th1lACqWYJ+Ml3RRVDDqO7FK4hX2ShI1CLcv7fQ3xLI6CdpFkSFZQRVQUD8LtW7gt4JjiQEwOQ2ctGKkgXhLPfzOfrLCE1XdG6mB7vq+XH3AupsmtjbiB8Bt1/g8ptnb9QTHuTEGiRKcba4K/Y= Received: by 10.65.233.16 with SMTP id k16mr2321207qbr.43.1200506569923; Wed, 16 Jan 2008 10:02:49 -0800 (PST) Received: by 10.64.179.20 with HTTP; Wed, 16 Jan 2008 10:02:49 -0800 (PST) Message-ID: Date: Wed, 16 Jan 2008 13:02:49 -0500 From: "Michael MacLeod" To: "Nikos Vassiliadis" In-Reply-To: <200801161204.23905.nvass@teledomenet.gr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <478DAF82.8010702@elischer.org> <200801161204.23905.nvass@teledomenet.gr> Cc: freebsd-net@freebsd.org, Julian Elischer 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: Wed, 16 Jan 2008 18:02:51 -0000 On Jan 16, 2008 5:04 AM, Nikos Vassiliadis wrote: > On Wednesday 16 January 2008 09:44:05 Michael MacLeod wrote: > > On Jan 16, 2008 2:17 AM, Julian Elischer wrote: > > > 1/ when downloading, does the load on each incoming interface > use "netstat -I xl0 -w 1", "netstat -I xl1 -w 1" and "netstat -I tun0 -w 1" > or "systat -ifstat" for an interactive terminal display. Here's some sample output from netstat -I -w 1: input (xl0) output packets errs bytes packets errs bytes colls 226 0 337862 157 0 12911 0 219 0 325854 156 0 13040 0 232 0 344078 156 0 12696 0 226 0 337862 157 0 13063 0 input (xl1) output packets errs bytes packets errs bytes colls 224 0 334834 157 0 12931 0 223 0 336188 156 0 12992 0 225 0 336348 157 0 12971 0 input (tun0) output packets errs bytes packets errs bytes colls 447 0 658506 320 0 19148 0 457 0 669064 311 0 18440 0 454 0 667474 314 0 18500 0 442 0 648204 329 0 20044 0 According to systat -ifstat I'm getting approx 320kb a sec down each pipe, for a total throughput of approx 640kb. I was downloading several copies of the linux kernel from kernel.org in parallel, and maxing out the connection. > > > 2/ do the IP stats show a lot of out-of order packets? > > > (netstat -s -ptcp I think) > > > in fact ip reassembly problems might be of interest. > > > (netstat -s -pip (?)) > > > 3/are there many retransmissions? > Though it seems that most of the traffic is forwarded and thus the > FreeBSD host will not get much TCP. So, you wouldn't know much of > the retransmissions happening. You could use 2-3 instances of > "fetch ftp://somewhere/something" in parallel to fully utilize > your DSL lines from your FreeBSD box. # netstat -s -ptcp < snip > 396978 packets received 67065 acks (for 184666044 bytes) 11483 duplicate acks 0 acks for unsent data 296659 packets (405850084 bytes) received in-sequence 9171 completely duplicate packets (64530 bytes) 0 old duplicate packets 2 packets with some dup. data (1017 bytes duped) 20958 out-of-order packets (29976306 bytes) 0 packets (0 bytes) of data after window 0 window probes 1111 window update packets 4 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short < snip > # netstat -s -pip ip: 4622318 total packets received 0 bad header checksums 0 with size smaller than minimum 0 with data size < data length 0 with ip length > max ip packet size 0 with header length < data size 0 with data length < header length 0 with bad options 0 with incorrect version number 0 fragments received 0 fragments dropped (dup or out of space) 0 fragments dropped after timeout 0 packets reassembled ok 405541 packets for this host 0 packets for unknown/unsupported protocol 4198571 packets forwarded (0 packets fast forwarded) 4091 packets not forwardable 0 packets received for unknown multicast group 0 redirects sent 369718 packets sent from this host 0 packets sent with fabricated ip header 0 output packets dropped due to no bufs, etc. 0 output packets discarded due to no route 0 output datagrams fragmented 0 fragments created 0 datagrams that can't be fragmented 0 tunneling packets that can't find gif 0 datagrams with bad address in header So there are lots of out of order packets, but that's to be expected with round-robin multilink ppp. I ran these after downloading three copies of the linux kernel in parallel, and there are no packets that were reassembled. > [snip] > > > 5/ have you tried mpd? (in ports (multilink ppp daemon).) > > > it may have different operating characteristics.. (it does it all > > > in the kernel using netgraph). Sounds like you need to fix it > > > at the other end but mpd might trigger different behaviour > > > in the router. > > > > I looked into mpd first. I tried several of the ports (mpd, mpd4, and > > mpd5) all without much success. There isn't much documentation for mpd > > (at least compared to the standard userland ppp). > > No, mpd is adequately documented. /usr/local/share/doc/mpd* > > > Also, both of the > > individuals who I know have successfully used multilink ppp and > > TekSavvy are using userland ppp. I'd be happy to use mpd, except that > > I'm *almost* there with userland ppp, and I'm guessing it's something > > I've overlooked or misconfigered somewhere and once I find and correct > > it, it'll work like a charm. > > If you are willing to try mpd, you can find a multilink PPPoE setup here: > http://lists.freebsd.org/pipermail/freebsd-questions/2007-September/157110.html > > You can use the above example with mpd4. I tried mpd first, and did manage to find the above config and tried to use it. I was not successful unfortunately. When playing with mpd I even downloaded a local copy of the documentation you mentioned so I could easily browse it from work (I have a sweet job with plenty of downtime). Given that the other two freebsd users doing mutlilink ppp on the dslreports forums were using userland ppp, I decided to focus on that. If I can't get userland ppp working by this weekend, I'll try your mpd config once more, and see if I can make it work. However, when I was reading up on it, I seem to recall that mpd did not support either packet splitting or round-robin (I forget which, and I forget where I read it), and since my connection to TekSavvy uses both of these, it might be a non-starter. I'd really like to get userland ppp working however, since I know it's possible for it to work optimally. Thanks for your patience, Mike From owner-freebsd-net@FreeBSD.ORG Wed Jan 16 19:47:39 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 0EB1616A46D for ; Wed, 16 Jan 2008 19:47:39 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outU.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id E31EB13C4F3 for ; Wed, 16 Jan 2008 19:47:38 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 16 Jan 2008 11:47:38 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id 9E47F126F45; Wed, 16 Jan 2008 11:47:37 -0800 (PST) Message-ID: <478E5F5B.8090602@elischer.org> Date: Wed, 16 Jan 2008 11:47:39 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Michael MacLeod References: <478DAF82.8010702@elischer.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org 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: Wed, 16 Jan 2008 19:47:39 -0000 Michael MacLeod wrote: > On Jan 16, 2008 2:17 AM, Julian Elischer wrote: >> 1/ when downloading, does the load on each incoming interface >> (I assume you have one ethernet to each modem) match? > > This is a pretty rough way to estimate it, but starting/stopping > tcpdump on each of the interfaces at the same time suggests the load > is balanced down each link pretty evenly. There's a lot of inbound > traffic right now, as a friend is sending me a file right now. Most of > the other tools I'm used to working with to watch traffic only want to > work on the tun0 interface created by ppp. > >> 2/ do the IP stats show a lot of out-of order packets? >> (netstat -s -ptcp I think) >> in fact ip reassembly problems might be of interest. >> (netstat -s -pip (?)) >> 3/are there many retransmissions? > > # netstat -s -ptcp > tcp: > 144824 packets sent > 88543 data packets (117925386 bytes) > 34 data packets (45103 bytes) retransmitted > 6 data packets unnecessarily retransmitted > 0 resends initiated by MTU discovery > 49084 ack-only packets (1022 delayed) > 0 URG only packets > 0 window probe packets > 7156 window update packets > 42 control packets > 140315 packets received > 42211 acks (for 117742680 bytes) > 7009 duplicate acks > 0 acks for unsent data > 90610 packets (117590676 bytes) received in-sequence > 5665 completely duplicate packets (0 bytes) > 0 old duplicate packets > 0 packets with some dup. data (0 bytes duped) > 45 out-of-order packets (64530 bytes) > 0 packets (0 bytes) of data after window > 0 window probes > 640 window update packets > 0 packets received after close > 0 discarded for bad checksums > 0 discarded for bad header offset fields > 0 discarded because packet too short it would be interesting to see how fast the dup packet and dup ack numbers are changing.. > < snip > > > # netstat -s -pip > ip: > 2143677 total packets received > 0 bad header checksums > 0 with size smaller than minimum > 0 with data size < data length > 0 with ip length > max ip packet size > 0 with header length < data size > 0 with data length < header length > 0 with bad options > 0 with incorrect version number > 0 fragments received > 0 fragments dropped (dup or out of space) > 0 fragments dropped after timeout > 0 packets reassembled ok > 149764 packets for this host > 0 packets for unknown/unsupported protocol > 1986854 packets forwarded (0 packets fast forwarded) > 651 packets not forwardable > 0 packets received for unknown multicast group > 0 redirects sent > 156851 packets sent from this host > 0 packets sent with fabricated ip header > 0 output packets dropped due to no bufs, etc. > 0 output packets discarded due to no route > 0 output datagrams fragmented > 0 fragments created > 0 datagrams that can't be fragmented > 0 tunneling packets that can't find gif > 0 datagrams with bad address in header > > So it looks like the connection is pretty decent, though admittedly I > haven't seen what these stats should look like on a non-multilink ppp > connection. However, empirically my VoIP traffic doesn't suffer from > jitter or choppiness, so I'm going to go out on a limb and say the > connection is pretty decent. > >> 4/ what is the outgoing data bandwidth when you are downloading? > > I've been tuning my pf firewall to do outbound traffic shaping, so I'm > not swamping the ack packets in either direction. I can basically run > the pipe at 5000kb down and 1350kb up consistently. > >> 5/ have you tried mpd? (in ports (multilink ppp daemon).) >> it may have different operating characteristics.. (it does it all >> in the kernel using netgraph). Sounds like you need to fix it >> at the other end but mpd might trigger different behaviour >> in the router. > > I looked into mpd first. I tried several of the ports (mpd, mpd4, and > mpd5) all without much success. There isn't much documentation for mpd > (at least compared to the standard userland ppp). Also, both of the > individuals who I know have successfully used multilink ppp and > TekSavvy are using userland ppp. I'd be happy to use mpd, except that > I'm *almost* there with userland ppp, and I'm guessing it's something > I've overlooked or misconfigered somewhere and once I find and correct > it, it'll work like a charm. > > A bit more info about the connection: I'm using pf to do my > firewalling. My pf.conf includes some packet reassembly bits that one > of the other successful guys at dslreports sent me. > > The wan nic's are 3com (xl) cards, and my lan and dmz cards are both > Intel gigabit (em) cards. The router itself is an older dual PIII > 550Mhz rackmount server I got from my place of employment with plenty > of ram. Previously I'd used an older PIII 933Mhz computer I had lying > around, with two realtek (rl) cards for the wan nic's, and I ran into > the same problems, so I can assume it's not the hardware either. hmm I 'm not seeing much.. What happens with multiple downloads at once vs one big one.. From owner-freebsd-net@FreeBSD.ORG Wed Jan 16 22:21:09 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 D32BB16A419 for ; Wed, 16 Jan 2008 22:21:09 +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 523B513C44B for ; Wed, 16 Jan 2008 22:21:09 +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 65558514; Thu, 17 Jan 2008 00:21:08 +0200 Message-ID: <478E834E.4080302@FreeBSD.org> Date: Thu, 17 Jan 2008 00:21:02 +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> In-Reply-To: <1200518607.00010486.1200507002@10.7.7.3> 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: Wed, 16 Jan 2008 22:21:09 -0000 Michael MacLeod wrote: > So there are lots of out of order packets, but that's to be expected > with round-robin multilink ppp. I ran these after downloading three > copies of the linux kernel in parallel, and there are no packets that > were reassembled. Even working in round-robin mode ppp avoids packet reordering as it may lead to problems with compression/encryption protocols. Multilink header includes serial number especially for this purpose. > I seem to recall that mpd did not support either > packet splitting or round-robin (I forget which, and I forget where I > read it), and since my connection to TekSavvy uses both of these, it > might be a non-starter. 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. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 02:54:59 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 8F84F16A41B; Thu, 17 Jan 2008 02:54:59 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 3096113C442; Thu, 17 Jan 2008 02:54:59 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from localhost (localhost [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id AA61434175; Thu, 17 Jan 2008 02:22:55 +0000 (GMT) Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbR9NnR3pIsy; Thu, 17 Jan 2008 02:22:55 +0000 (GMT) Received: from [192.168.255.6] (unknown [192.168.255.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 8B6DA34174; Thu, 17 Jan 2008 02:22:54 +0000 (GMT) Message-ID: <478EBBFD.4090806@tomjudge.com> Date: Thu, 17 Jan 2008 02:22:53 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Andrew Thompson , freebsd-net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: if_bridge forwarding incorrectly forwarding ethernet link local addressed packets (e.g. lldp) 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: Thu, 17 Jan 2008 02:54:59 -0000 Hi, As brought up in the thread "Programming interface MAC filter without enabling PROMISC on an interface from user space." it would seem that if_bridge does not conform to IEEE 802.1D-2004. Which states: 7.12.6 Reserved addresses Frames containing any of the group MAC Addresses specified in Table 7-10 in their destination address field shall not be relayed by the Bridge. They are configured in the Permanent Database. Management shall not provide the capability to modify or remove these entries from the Permanent or the Filtering Databases. These group MAC Addresses are reserved for assignment to standard protocols, according to the criteria for such assignments (Clause 5.5 of ISO/IEC TR 11802-2). Assignment Value Bridge Group Address 01-80-C2-00-00-00 IEEE Std 802.3x Full Duplex PAUSE operation 01-80-C2-00-00-01 IEEE Std 802.3ad Slow_Protocols_Multicast address 01-80-C2-00-00-02 IEEE P802.1X PAE address 01-80-C2-00-00-03 Reserved for future standardization 01-80-C2-00-00-04 Reserved for future standardization 01-80-C2-00-00-05 Reserved for future standardization 01-80-C2-00-00-06 Reserved for future standardization 01-80-C2-00-00-07 Reserved for future standardization 01-80-C2-00-00-08 Reserved for future standardization 01-80-C2-00-00-09 Reserved for future standardization 01-80-C2-00-00-0A Reserved for future standardization 01-80-C2-00-00-0B Reserved for future standardization 01-80-C2-00-00-0C Reserved for future standardization 01-80-C2-00-00-0D Reserved for future standardization 01-80-C2-00-00-0E Reserved for future standardization 01-80-C2-00-00-0F
Should I raise a PR about this? Regards Tom From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 03:08:07 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 64C5E16A419 for ; Thu, 17 Jan 2008 03:08:07 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from heff.fud.org.nz (203-109-251-39.static.bliink.ihug.co.nz [203.109.251.39]) by mx1.freebsd.org (Postfix) with ESMTP id BD35813C447 for ; Thu, 17 Jan 2008 03:08:06 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: by heff.fud.org.nz (Postfix, from userid 1001) id C331377D4; Thu, 17 Jan 2008 16:08:04 +1300 (NZDT) Date: Thu, 17 Jan 2008 16:08:04 +1300 From: Andrew Thompson To: Tom Judge Message-ID: <20080117030804.GA30931@heff.fud.org.nz> References: <478EBBFD.4090806@tomjudge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <478EBBFD.4090806@tomjudge.com> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: freebsd-net Subject: Re: if_bridge forwarding incorrectly forwarding ethernet link local addressed packets (e.g. lldp) 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: Thu, 17 Jan 2008 03:08:07 -0000 On Thu, Jan 17, 2008 at 02:22:53AM +0000, Tom Judge wrote: > > Hi, > > As brought up in the thread "Programming interface MAC filter without > enabling PROMISC on an interface from user space." it would seem that > if_bridge does not conform to IEEE 802.1D-2004. Which states: > > > 7.12.6 Reserved addresses > Frames containing any of the group MAC Addresses specified in Table 7-10 in > their destination address field shall not be relayed by the Bridge. They > are configured in the Permanent Database. Management shall not provide the > capability to modify or remove these entries from the Permanent or the > Filtering Databases. These group MAC Addresses are reserved for assignment > to standard protocols, according to the criteria for such assignments > (Clause 5.5 of ISO/IEC TR 11802-2). > > > > > Assignment Value > Bridge Group Address 01-80-C2-00-00-00 > IEEE Std 802.3x Full Duplex PAUSE operation 01-80-C2-00-00-01 > IEEE Std 802.3ad Slow_Protocols_Multicast address 01-80-C2-00-00-02 > IEEE P802.1X PAE address 01-80-C2-00-00-03 > Reserved for future standardization 01-80-C2-00-00-04 > Reserved for future standardization 01-80-C2-00-00-05 > Reserved for future standardization 01-80-C2-00-00-06 > Reserved for future standardization 01-80-C2-00-00-07 > Reserved for future standardization 01-80-C2-00-00-08 > Reserved for future standardization 01-80-C2-00-00-09 > Reserved for future standardization 01-80-C2-00-00-0A > Reserved for future standardization 01-80-C2-00-00-0B > Reserved for future standardization 01-80-C2-00-00-0C > Reserved for future standardization 01-80-C2-00-00-0D > Reserved for future standardization 01-80-C2-00-00-0E > Reserved for future standardization 01-80-C2-00-00-0F >
> > Should I raise a PR about this? Yes please, just paste the same content in. Thanks for investigating this, I will sort out a patch. Andrew From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 06:30:16 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5836716A417; Thu, 17 Jan 2008 06:30:16 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from mx-out-01.forthnet.gr (mx-out.forthnet.gr [193.92.150.104]) by mx1.freebsd.org (Postfix) with ESMTP id C3F7513C45B; Thu, 17 Jan 2008 06:30:15 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from mx-av-01.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.13.8/8.13.8) with ESMTP id m0H4Rveu018397; Thu, 17 Jan 2008 06:27:57 +0200 Received: from MX-IN-03.forthnet.gr (mx-in-05.forthnet.gr [193.92.150.32]) by mx-av-01.forthnet.gr (8.14.1/8.14.1) with ESMTP id m0H4RvEg027531; Thu, 17 Jan 2008 06:27:57 +0200 Received: from kobe.laptop (ppp176-5.adsl.forthnet.gr [62.1.179.5]) by MX-IN-03.forthnet.gr (8.14.2/8.14.2) with ESMTP id m0H4RotA002829; Thu, 17 Jan 2008 06:27:51 +0200 Authentication-Results: MX-IN-03.forthnet.gr smtp.mail=keramida@freebsd.org; spf=permerror Authentication-Results: MX-IN-03.forthnet.gr header.from=keramida@freebsd.org; sender-id=permerror Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.2/8.14.2) with ESMTP id m0H4Rn4M001708; Thu, 17 Jan 2008 06:27:49 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.2/8.14.2/Submit) id m0H4RmfM001707; Thu, 17 Jan 2008 06:27:48 +0200 (EET) (envelope-from keramida@freebsd.org) Date: Thu, 17 Jan 2008 06:27:48 +0200 From: Giorgos Keramidas To: Andre Oppermann Message-ID: <20080117042747.GA1617@kobe.laptop> References: <20071219123305.Y95322@fledge.watson.org> <47693DBD.6050104@swin.edu.au> <476A45D6.6030305@freebsd.org> <47858D35.6060006@swin.edu.au> <4786D23A.1080509@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4786D23A.1080509@freebsd.org> Cc: James Healy , Lawrence Stewart , net@freebsd.org, Robert Watson , arch@freebsd.org Subject: Re: Coordinating TCP projects 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: Thu, 17 Jan 2008 06:30:16 -0000 On 2008-01-11 03:19, Andre Oppermann wrote: >Lawrence Stewart wrote: >>> I've got a rewritten and much more efficient tcp_reass() function in >>> my local tree. I'll import it into Perforce next week with all the >>> other stuff. You may want to base your auto-sizing work on it. The >>> only missing parts are some statistics gathering. >> >> Where abouts is this code? A cursory browse through the Perforce web >> front-end reveals nothing. We're going to start work on the TCP >> reassembly queue autotuning patch now and if you think we should base >> it on your new tcp_reass() we need to have a look at it. > > The first cut is now at //depot/projects/tcp_reass/ however I made a > mistake when creating the branch and now the code is in the same > changeset as the branching itself. Doesn't make it easy to do a diff. > Have to see how I can fix that. Anyway, have a look and I'm going to > finish/fix the code tomorrow evening. Hi Andre, You can `p4 obliterate' the branch and recommit. Alternatively, you can commit a second change, with the clean branch-origin source, and then re-commit the tcp_reass code. The perforce-admins may have a preferred way of fixing this, so it's probably worth asking too. HTH, Giorgos From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 10:53: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 12D8516A417 for ; Thu, 17 Jan 2008 10:53:47 +0000 (UTC) (envelope-from netslists@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 8E00B13C458 for ; Thu, 17 Jan 2008 10:53:46 +0000 (UTC) (envelope-from netslists@gmail.com) Received: by fg-out-1718.google.com with SMTP id 16so708139fgg.35 for ; Thu, 17 Jan 2008 02:53:45 -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:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=YarXc+ovEutWKt9LigBMDmuoEbUy78jaqguOZfpd+2c=; b=pRLoXu6tH+O+3hoxD/dpePGRxmdzNE8dUr1XXBloj0BSTk4KmWof4KoldkiYpBHQDlFpWH1PzuHl+/65e5xNjvSPwPECJrViLnNyTNf0e3BRxxvVVuLRkyDInHs/iea8qqEb6q6QIYwy/o0atsj3tj3XGN6rJRB9qkwG7bR8/G8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=AkTfzaBSH/oE5dt3ghHBcjSpPE6gNQnpG61UBWBcfh6m2W1lGNEM1OMF+iuH/+WJTqBzPFRVTby3N0UT1WJJe+OprqRaZm62DegqKdotyaABEn7aZiP14mT5ArtuRO6dop3mTigZLXdS84k4H7UmQVAQq3esiMO5IRxMurnZqVA= Received: by 10.86.50.8 with SMTP id x8mr1780893fgx.25.1200567225254; Thu, 17 Jan 2008 02:53:45 -0800 (PST) Received: from ?192.168.9.8? ( [91.135.49.10]) by mx.google.com with ESMTPS id l12sm2102335fgb.8.2008.01.17.02.53.43 (version=SSLv3 cipher=RC4-MD5); Thu, 17 Jan 2008 02:53:44 -0800 (PST) Message-ID: <478F33AE.2030804@gmail.com> Date: Thu, 17 Jan 2008 11:53:34 +0100 From: Sten Daniel Soersdal User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Michael MacLeod References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org 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: Thu, 17 Jan 2008 10:53:47 -0000 Michael MacLeod wrote: > Hello all, > > I've got two DSL lines running to my house, and two WAN NIC's > installed in my FreeBSD router. I've been trying to get multilink ppp > working through my ISP (TekSavvy in Canada) for the last little while, > with mixed results. Each of my DSL lines sync's at 6016 kbits down and > 800 kbits up. I have traffic working through the bonded connection, > and the upload speed is 1350 kb, which is about right for a 1.6 > megabit connection minus network overhead. The problem I'm running > into is the download speed is only that of one of my downlinks (approx > 5000kb, which is about right for 6 megabits minus network overhead). > It is quite possible that the ISP is employing bandwidth limiting and the limits are set to that of one ppp link (since this multilink combines two ppp links into a single link and thus logically it could be limited to that of one ppp connection). -- Sten Daniel Soersdal From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 11:57:29 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 09CC816A417 for ; Thu, 17 Jan 2008 11:57:29 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog17.obsmtp.com (s200aog17.obsmtp.com [207.126.144.131]) by mx1.freebsd.org (Postfix) with SMTP id A7C0E13C465 for ; Thu, 17 Jan 2008 11:57:27 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob017.postini.com ([207.126.147.11]) with SMTP; Thu, 17 Jan 2008 11:57:26 UTC Received: from bill.mintel.co.uk (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 0D78418141F; Thu, 17 Jan 2008 11:57:26 +0000 (GMT) Message-ID: <478F42A5.6080301@tomjudge.com> Date: Thu, 17 Jan 2008 11:57:25 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Andrew Thompson References: <478EBBFD.4090806@tomjudge.com> <20080117030804.GA30931@heff.fud.org.nz> In-Reply-To: <20080117030804.GA30931@heff.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: if_bridge forwarding incorrectly forwarding ethernet link local addressed packets (e.g. lldp) 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: Thu, 17 Jan 2008 11:57:29 -0000 Andrew Thompson wrote: > On Thu, Jan 17, 2008 at 02:22:53AM +0000, Tom Judge wrote: >> Hi, >> >> As brought up in the thread "Programming interface MAC filter without >> enabling PROMISC on an interface from user space." it would seem that >> if_bridge does not conform to IEEE 802.1D-2004. Which states: >> >> >> 7.12.6 Reserved addresses >> Frames containing any of the group MAC Addresses specified in Table 7-10 in >> their destination address field shall not be relayed by the Bridge. They >> are configured in the Permanent Database. Management shall not provide the >> capability to modify or remove these entries from the Permanent or the >> Filtering Databases. These group MAC Addresses are reserved for assignment >> to standard protocols, according to the criteria for such assignments >> (Clause 5.5 of ISO/IEC TR 11802-2). >> >> >> >> >> Assignment Value >> Bridge Group Address 01-80-C2-00-00-00 >> IEEE Std 802.3x Full Duplex PAUSE operation 01-80-C2-00-00-01 >> IEEE Std 802.3ad Slow_Protocols_Multicast address 01-80-C2-00-00-02 >> IEEE P802.1X PAE address 01-80-C2-00-00-03 >> Reserved for future standardization 01-80-C2-00-00-04 >> Reserved for future standardization 01-80-C2-00-00-05 >> Reserved for future standardization 01-80-C2-00-00-06 >> Reserved for future standardization 01-80-C2-00-00-07 >> Reserved for future standardization 01-80-C2-00-00-08 >> Reserved for future standardization 01-80-C2-00-00-09 >> Reserved for future standardization 01-80-C2-00-00-0A >> Reserved for future standardization 01-80-C2-00-00-0B >> Reserved for future standardization 01-80-C2-00-00-0C >> Reserved for future standardization 01-80-C2-00-00-0D >> Reserved for future standardization 01-80-C2-00-00-0E >> Reserved for future standardization 01-80-C2-00-00-0F >>
>> >> Should I raise a PR about this? > > Yes please, just paste the same content in. Thanks for investigating > this, I will sort out a patch. > > > Andrew Hi, I have raised a PR about this: kern/119744 I also put a possible solution into the PR. I'm not sure if the boolean logic on eh->ether_dhost is valid though: if (eh->ether_dhost & 0xFFFFFFFFFFF0 == 0x0180C2000000) {} How ever the symantics of the logic should be correct even if the code is wrong. I have not tested this fix at all (not even compile). Tom From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 12:49:57 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 3B09A16A417 for ; Thu, 17 Jan 2008 12:49:57 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog17.obsmtp.com (s200aog17.obsmtp.com [207.126.144.131]) by mx1.freebsd.org (Postfix) with SMTP id 9370F13C447 for ; Thu, 17 Jan 2008 12:49:56 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob017.postini.com ([207.126.147.11]) with SMTP; Thu, 17 Jan 2008 12:49:55 UTC Received: from bill.mintel.co.uk (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 6FF17181420 for ; Thu, 17 Jan 2008 12:49:55 +0000 (GMT) Message-ID: <478F4EF2.7060209@tomjudge.com> Date: Thu, 17 Jan 2008 12:49:54 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Tuning of IP_MAX_MEMBERSHIPS for IP Multicast Sockets 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: Thu, 17 Jan 2008 12:49:57 -0000 Hi, On RELENG_6_2 the max multicast memberships per socket (IP_MAX_MEMBERSHIPS) is hard coded in sys/netinet/in.h to 20. Would there be any problem with bumping this to say 40. The problem is our VPN routers running quagga (ospf) seem to be hitting this limit. I know the problem is fixed on 7+ but would there be any adverse side affects of bumping this value up? Thanks Tom From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 13:26:48 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 2C00916A420 for ; Thu, 17 Jan 2008 13:26:48 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (www.svzserv.kemerovo.su [213.184.65.80]) by mx1.freebsd.org (Postfix) with ESMTP id 96D5B13C4CE for ; Thu, 17 Jan 2008 13:26:47 +0000 (UTC) (envelope-from eugen@www.svzserv.kemerovo.su) Received: from www.svzserv.kemerovo.su (eugen@localhost [127.0.0.1]) by www.svzserv.kemerovo.su (8.13.8/8.13.8) with ESMTP id m0HCsIaT088391; Thu, 17 Jan 2008 19:54:18 +0700 (KRAT) (envelope-from eugen@www.svzserv.kemerovo.su) Received: (from eugen@localhost) by www.svzserv.kemerovo.su (8.13.8/8.13.8/Submit) id m0HCsIKE088390; Thu, 17 Jan 2008 19:54:18 +0700 (KRAT) (envelope-from eugen) Date: Thu, 17 Jan 2008 19:54:18 +0700 From: Eugene Grosbein To: Tom Judge Message-ID: <20080117125418.GA88165@svzserv.kemerovo.su> References: <478F4EF2.7060209@tomjudge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <478F4EF2.7060209@tomjudge.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net Subject: Re: Tuning of IP_MAX_MEMBERSHIPS for IP Multicast Sockets 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: Thu, 17 Jan 2008 13:26:48 -0000 On Thu, Jan 17, 2008 at 12:49:54PM +0000, Tom Judge wrote: > On RELENG_6_2 the max multicast memberships per socket > (IP_MAX_MEMBERSHIPS) is hard coded in sys/netinet/in.h to 20. > > Would there be any problem with bumping this to say 40. The problem is > our VPN routers running quagga (ospf) seem to be hitting this limit. > > I know the problem is fixed on 7+ but would there be any adverse side > affects of bumping this value up? Not at all. I raised the limit upto 200 for my 4.11-STABLE quagga router 3 months ago and have no problems. There are 65 active now. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 14:53:16 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 166D516A418 for ; Thu, 17 Jan 2008 14:53:16 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from mail.comstyle.com (unknown [IPv6:2001:16d8:ffe8:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9D07A13C461 for ; Thu, 17 Jan 2008 14:53:15 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from [192.168.3.30] (toronto-hs-216-138-195-228.s-ip.magma.ca [216.138.195.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: brad) by mail.comstyle.com (Postfix) with ESMTP id 6520F82D2F; Thu, 17 Jan 2008 15:52:54 +0100 (CET) From: Brad To: freebsd-net@freebsd.org Date: Thu, 17 Jan 2008 09:52:53 -0500 User-Agent: KMail/1.9.7 References: <478F33AE.2030804@gmail.com> In-Reply-To: <478F33AE.2030804@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801170952.53217.brad@comstyle.com> X-comstyle-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 6520F82D2F.A26E8 X-comstyle-MailScanner: Found to be clean X-comstyle-MailScanner-From: brad@comstyle.com X-Spam-Status: No Cc: Michael MacLeod , Sten Daniel Soersdal 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: Thu, 17 Jan 2008 14:53:16 -0000 On Thursday 17 January 2008 05:53:34 Sten Daniel Soersdal wrote: > Michael MacLeod wrote: > > Hello all, > > > > I've got two DSL lines running to my house, and two WAN NIC's > > installed in my FreeBSD router. I've been trying to get multilink ppp > > working through my ISP (TekSavvy in Canada) for the last little while, > > with mixed results. Each of my DSL lines sync's at 6016 kbits down and > > 800 kbits up. I have traffic working through the bonded connection, > > and the upload speed is 1350 kb, which is about right for a 1.6 > > megabit connection minus network overhead. The problem I'm running > > into is the download speed is only that of one of my downlinks (approx > > 5000kb, which is about right for 6 megabits minus network overhead). > > > > It is quite possible that the ISP is employing bandwidth limiting and > the limits are set to that of one ppp link (since this multilink > combines two ppp links into a single link and thus logically it could be > limited to that of one ppp connection). Read his whole post again.. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 17:15:54 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06B4416A419 for ; Thu, 17 Jan 2008 17:15:54 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from outbound0.mx.meer.net (outbound0.mx.meer.net [209.157.153.23]) by mx1.freebsd.org (Postfix) with ESMTP id 0785C13C458 for ; Thu, 17 Jan 2008 17:15:53 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.mx.meer.net (8.12.10/8.12.6) with ESMTP id m0HHFr7T057609 for ; Thu, 17 Jan 2008 09:15:53 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id m0HHFrRI058715 for ; Thu, 17 Jan 2008 09:15:53 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from gnnbsd.hudson-trading.com.neville-neil.com ([66.150.84.1]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.1) with ESMTP id m0HHFqV9030850 for ; Thu, 17 Jan 2008 09:15:53 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Thu, 17 Jan 2008 12:15:52 -0500 Message-ID: <7izlv4pe47.wl%gnn@neville-neil.com> From: gnn@freebsd.org To: net@freebsd.org User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/21.3 (amd64--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: Are there known issues with multicast on Intel Pro 1000? 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: Thu, 17 Jan 2008 17:15:54 -0000 Howdy, At my current gig we find that the network interface locks up if we subject it to a high rate of multicast traffic. Since the whole purpose of this box is to do multicast (it absorbs a feed of data over multicast manipulates and then sends it out again over multicast) it's a "bad thing" if this kind of thing does not work. What I currently know is not complete but I figured I could start here. The symptom is that all network communication stops, but the system itself is still responsive, so I can get to the console and get information. Release: 6.2 and 6.3-PRERELEASE (6.3 as of Wed Jan 16th) `Motherboard: CPU: 2 x Intel Xeon X5365 3GHz (4 cores each) Memory: 8G em0: Intel PRO/1000 6.7.3 port 0x2000-0x201f mem 0xd8320000-0xd833ffff em1: Intel PRO/1000 6.7.3 port 0x2020-0x203f mem 0xd8320000-0xd833ffff em2: Intel PRO/1000 6.7.3 port 0x3000-0x303f mem 0xd8240000-0xd825ffff, 0xd8200000-0xd823ffff em3: Intel PRO/1000 6.7.3 port 0x3040-0x307f mem 0xd8260000-0xd827ffff Other data: em2 is the interface that multicasts out our digested data and it also is receiving a lot of digested multicast traffic, which is being recorded by a proprietary program sysctl dev.em.2.debug=1 em2: CTRL = 0x487c0a01 RCTL=0x8002 em2: Pcket buffer = Tx=16k Rx=48k em2: fifo workaround = 0, fifo_reset_count = 0 em2: hw tdh = 76, hw tdt = 76 em2: hw rdh = 213, hw rdt = 212 em2: Num Tx descriptors avail = 256 em2: Tx Descriptors not avail1 = 0 em2: Tx Descriptors not avail2 = 0 em2: Std mbuf failed = 0 em2: Std mbuf cluster fialed = 1247383 (this number is increasing by about 1 a second) em2: Driver dropped packets = 0 em2: Driver tx dma failure in encap = 0 sysctl dev.em.2.stats=1 (all are zero except what is recorded) em2: Missed Packets = 4683 em2: Receive No Buffers = 46905 em2: RX overruns = 83 em2: Good Packets Rcvd = 11416687 em2: Good Packets Xmtd = 146576 em0 is the interface we receive the raw data over multicast on em0: hw tdh = 130, hw tdt = 130 em0: hw rdh = 13, hw rdt = 12 em0: Num Tx descriptors avail = 256 em0: Std mbuf cluster failed = 5111461 (this number is going up by about 1 a second) sysctl dev.em.0.stats=1 (all are zero except what is recorded) em0: Missed Packets = 292778 em0: Receive No Buffers = 96211 em0: RX overruns = 1092 em0: Good Packets Rcvd = 5386001 em0: Good Packets Xmtd = 12418 em3 receives a little data from multicast and it is recorded using a proprietary program em3: hw tdh = 45, hw tdt = 45 em3: hw rdh = 216, hw rdt = 215 em3: Num Tx descriptors avail = 256 em3: Std mbuf cluster failed = 195951 (also going up by 1 very slowly) sysctl dev.em.3.stats=1 (all are zero except what is recorded) em3: Good Packets Rcvd = 9637851 em3: Good Packets Xmtd = 8237 One odd thing is that when the system boots, em1, which is unused in this case complains of: em1: Using MSI interrupt em1: Setup of Shared code failed What more do people need to help debug this? Best, George From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 18:41:26 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 705A216A468 for ; Thu, 17 Jan 2008 18:41:26 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from s200aog14.obsmtp.com (s200aog14.obsmtp.com [207.126.144.128]) by mx1.freebsd.org (Postfix) with SMTP id DEA8613C4CE for ; Thu, 17 Jan 2008 18:40:53 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from source ([217.206.187.80]) by eu1sys200aob014.postini.com ([207.126.147.11]) with SMTP; Thu, 17 Jan 2008 18:40:52 UTC Received: from bill.mintel.co.uk (bill.mintel.co.uk [10.0.0.89]) by rodney.mintel.co.uk (Postfix) with ESMTP id 8A23818141B; Thu, 17 Jan 2008 18:40:52 +0000 (GMT) Message-ID: <478FA134.6010707@tomjudge.com> Date: Thu, 17 Jan 2008 18:40:52 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Eugene Grosbein References: <478F4EF2.7060209@tomjudge.com> <20080117125418.GA88165@svzserv.kemerovo.su> In-Reply-To: <20080117125418.GA88165@svzserv.kemerovo.su> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net Subject: Re: Tuning of IP_MAX_MEMBERSHIPS for IP Multicast Sockets 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: Thu, 17 Jan 2008 18:41:26 -0000 Eugene Grosbein wrote: > On Thu, Jan 17, 2008 at 12:49:54PM +0000, Tom Judge wrote: > >> On RELENG_6_2 the max multicast memberships per socket >> (IP_MAX_MEMBERSHIPS) is hard coded in sys/netinet/in.h to 20. >> >> Would there be any problem with bumping this to say 40. The problem is >> our VPN routers running quagga (ospf) seem to be hitting this limit. >> >> I know the problem is fixed on 7+ but would there be any adverse side >> affects of bumping this value up? > > Not at all. I raised the limit upto 200 for my 4.11-STABLE > quagga router 3 months ago and have no problems. There are 65 active now. > Thanks for the response, I will give this a try as soon as my work load cools off a little. Tom From owner-freebsd-net@FreeBSD.ORG Thu Jan 17 20:09:03 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6E51016A419 for ; Thu, 17 Jan 2008 20:09:03 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mx1.freebsd.org (Postfix) with ESMTP id 6CFDE13C467 for ; Thu, 17 Jan 2008 20:09:03 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 17 Jan 2008 12:09:03 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m0HK93Wt014544; Thu, 17 Jan 2008 12:09:03 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m0HK8wnx003977; Thu, 17 Jan 2008 20:09:03 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 12:08:53 -0800 Received: from [128.107.109.215] ([128.107.109.215]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jan 2008 12:08:52 -0800 Message-ID: <478FB53B.60808@cisco.com> Date: Thu, 17 Jan 2008 15:06:19 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.13) Gecko/20070601 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gnn@freebsd.org References: <7izlv4pe47.wl%gnn@neville-neil.com> In-Reply-To: <7izlv4pe47.wl%gnn@neville-neil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jan 2008 20:08:52.0975 (UTC) FILETIME=[C81867F0:01C85944] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4023; t=1200600543; x=1201464543; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20Are=20there=20known=20issues=20with=20m ulticast=20on=20Intel=20Pro=201000? |Sender:=20; bh=fF3GsA+FjJxkc5lvEkeMeIofc+5/PCkeyfxe+MmVax4=; b=UoeQ95Rlhc0aoQBnjqnVa6c0v1JfY0UzQ1v4Zou1dnl3ZrBHec3fIO9a6p FmIotJTC+aTe2SxQhIaU2RtjjqTH43RsY2c7YYT8wmWo+kCBcXimMht729fB YzsQCk+dNJ; Authentication-Results: sj-dkim-3; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: net@freebsd.org Subject: Re: Are there known issues with multicast on Intel Pro 1000? 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: Thu, 17 Jan 2008 20:09:03 -0000 gnn@freebsd.org wrote: > Howdy, > > At my current gig we find that the network interface locks up if we > subject it to a high rate of multicast traffic. Since the whole > purpose of this box is to do multicast (it absorbs a feed of data over > multicast manipulates and then sends it out again over multicast) it's > a "bad thing" if this kind of thing does not work. > > What I currently know is not complete but I figured I could start > here. > > The symptom is that all network communication stops, but the system > itself is still responsive, so I can get to the console and get > information. If you let it run long enough does it eventually lock up? I have seen similar behavior when a lock is not released when I was breaking things :-) Everything is fine EXCEPT the interface.. for a while.. then eventually you get a train-wreck :-) I would drop to ddb and do the show locks.. Also I believe top (or ps) will tell you what locks are being waited on in a course way... I think the ps in DDB will do this. R > > Release: 6.2 and 6.3-PRERELEASE (6.3 as of Wed Jan 16th) > > `Motherboard: > > CPU: 2 x Intel Xeon X5365 3GHz (4 cores each) > > Memory: 8G > > em0: Intel PRO/1000 6.7.3 port 0x2000-0x201f mem 0xd8320000-0xd833ffff > em1: Intel PRO/1000 6.7.3 port 0x2020-0x203f mem 0xd8320000-0xd833ffff > em2: Intel PRO/1000 6.7.3 port 0x3000-0x303f mem 0xd8240000-0xd825ffff, 0xd8200000-0xd823ffff > em3: Intel PRO/1000 6.7.3 port 0x3040-0x307f mem 0xd8260000-0xd827ffff > > Other data: > > em2 is the interface that multicasts out our digested data and it also > is receiving a lot of digested multicast traffic, which is being > recorded by a proprietary program > > sysctl dev.em.2.debug=1 > em2: CTRL = 0x487c0a01 RCTL=0x8002 > em2: Pcket buffer = Tx=16k Rx=48k > em2: fifo workaround = 0, fifo_reset_count = 0 > em2: hw tdh = 76, hw tdt = 76 > em2: hw rdh = 213, hw rdt = 212 > em2: Num Tx descriptors avail = 256 > em2: Tx Descriptors not avail1 = 0 > em2: Tx Descriptors not avail2 = 0 > em2: Std mbuf failed = 0 > em2: Std mbuf cluster fialed = 1247383 (this number is increasing by about 1 a > second) > em2: Driver dropped packets = 0 > em2: Driver tx dma failure in encap = 0 > sysctl dev.em.2.stats=1 > (all are zero except what is recorded) > em2: Missed Packets = 4683 > em2: Receive No Buffers = 46905 > em2: RX overruns = 83 > em2: Good Packets Rcvd = 11416687 > em2: Good Packets Xmtd = 146576 > > em0 is the interface we receive the raw data over multicast on > > em0: hw tdh = 130, hw tdt = 130 > em0: hw rdh = 13, hw rdt = 12 > em0: Num Tx descriptors avail = 256 > em0: Std mbuf cluster failed = 5111461 (this number is going up by about 1 a > second) > sysctl dev.em.0.stats=1 > (all are zero except what is recorded) > em0: Missed Packets = 292778 > em0: Receive No Buffers = 96211 > em0: RX overruns = 1092 > em0: Good Packets Rcvd = 5386001 > em0: Good Packets Xmtd = 12418 > > em3 receives a little data from multicast and it is recorded using > a proprietary program > > em3: hw tdh = 45, hw tdt = 45 > em3: hw rdh = 216, hw rdt = 215 > em3: Num Tx descriptors avail = 256 > em3: Std mbuf cluster failed = 195951 (also going up by 1 very slowly) > > sysctl dev.em.3.stats=1 > (all are zero except what is recorded) > em3: Good Packets Rcvd = 9637851 > em3: Good Packets Xmtd = 8237 > > > > One odd thing is that when the system boots, em1, which is unused in > this case complains of: > > em1: Using MSI interrupt > em1: Setup of Shared code failed > > > > What more do people need to help debug this? > > Best, > George > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 06:24:15 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 D4FA716A41A for ; Fri, 18 Jan 2008 06:24:15 +0000 (UTC) (envelope-from lstewart@room52.net) Received: from swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.222]) by mx1.freebsd.org (Postfix) with ESMTP id 33C2513C474 for ; Fri, 18 Jan 2008 06:24:14 +0000 (UTC) (envelope-from lstewart@room52.net) Received: from [136.186.229.95] (lstewart.caia.swin.edu.au [136.186.229.95]) by swin.edu.au (8.13.6.20060614/8.13.1) with ESMTP id m0I5LqM4023238 for ; Fri, 18 Jan 2008 16:21:52 +1100 Message-ID: <47903770.1000200@room52.net> Date: Fri, 18 Jan 2008 16:21:52 +1100 From: Lawrence Stewart User-Agent: Thunderbird 1.5.0.9 (X11/20070123) MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=5.0 tests=ALL_TRUSTED autolearn=disabled version=3.1.9 X-Spam-Checker-Version: SpamAssassin 3.1.9 (2007-02-13) on gpo2.cc.swin.edu.au Subject: How to clear dummynet counters? 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: Fri, 18 Jan 2008 06:24:15 -0000 Hi All, I'm working on a minor modification to dummynet to create a pipe option that allows arbitrarily specified packets to be dropped (as opposed to the current "plr" option that introduces random, uncontrollable packet loss). I can't seem to figure out how to clear/reset dummynet queue counters associated with a pipe, which are shown when "ipfw pipe list" is issued. Example of counters I'm referring to: ... Tot_pkt/bytes Pkt/Byte Drp ... 2619 219996 0 0 4 ^^^^ ^^^^^^ ^ ^ ^ The ipfw man page and source does not reveal anything obvious, and in fact indicates to me that the functionality does not exist at all. Yes, I can delete and recreate the pipe which has the same net effect, but it's not as useful as, say, a "ipfw pipe zero" option. It's entirely possible I've missed something though so I wanted to check before diving in and attempting to add support for this. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Fri Jan 18 22:10:04 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A751916A417 for ; Fri, 18 Jan 2008 22:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8EAAC13C459 for ; Fri, 18 Jan 2008 22:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0IMA23G032215 for ; Fri, 18 Jan 2008 22:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0IMA22D032214; Fri, 18 Jan 2008 22:10:02 GMT (envelope-from gnats) Date: Fri, 18 Jan 2008 22:10:02 GMT Message-Id: <200801182210.m0IMA22D032214@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: wforms@Safe-mail.net Cc: Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: wforms@Safe-mail.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2008 22:10:04 -0000 The following reply was made to PR kern/112654; it has been noted by GNATS. From: wforms@Safe-mail.net To: bug-followup@freebsd.org Cc: "Andy Farkas" Subject: Re: kern/112654: [pcn] Kernel panic upon if_pcn module load on a Netfinity 5000 Date: Fri, 18 Jan 2008 20:40:26 +0100 It seems that my duf/poliod webmail client messes up these messages, so I'll try to submit from here instead. I run another test today, checking out what OpenBSD says when the network card driver loads. Interestingly it seems that the OpenBSD people did something similar to Andy's suggestion, as dmesg shows traces of both ukphy and nsphy. I am posting the relevant bit of OpenBSD dmesg in the hope that somebody way smarter than me will find it more useful than I did. :-) OpenBSD 4.1 on my crappy Netfinity 5000: ... pcn0 at pci0 dev 9 function 0 "AMD 79c970 PCnet-PCI" rev 0x36, Am79c972, rev 6: irq 11, address 00:06:29:50:xx:xx nsphyter0 at pcn0 phy 1: DP83843 10/100 PHY, rev. 0 ukphy0 at pcn0 phy 31: Generic IEEE 802.3u media interface, rev. 1: OUI 0x00001a, model 0x0001 ... Best regards, Keve Nagy * Debrecen * Hungary From owner-freebsd-net@FreeBSD.ORG Sat Jan 19 06:35:06 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C312A16A419; Sat, 19 Jan 2008 06:35:06 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8D1E013C461; Sat, 19 Jan 2008 06:35:06 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m0J6Z6L8069728; Sat, 19 Jan 2008 06:35:06 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m0J6Z6IX069724; Sat, 19 Jan 2008 06:35:06 GMT (envelope-from linimon) Date: Sat, 19 Jan 2008 06:35:06 GMT Message-Id: <200801190635.m0J6Z6IX069724@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/119791: [nfs] UDP NFS mount of aliased IP addresses from a Solaris 10 NFS v4 server fail 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 06:35:06 -0000 Old Synopsis: UDP NFS mount of aliased IP addresses from a Solaris 10 NFS v4 server fail New Synopsis: [nfs] UDP NFS mount of aliased IP addresses from a Solaris 10 NFS v4 server fail Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Jan 19 06:33:47 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=119791 From owner-freebsd-net@FreeBSD.ORG Sat Jan 19 21:47:29 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 AC73C16A46E for ; Sat, 19 Jan 2008 21:47:29 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.freebsd.org (Postfix) with ESMTP id 4E44C13C46E for ; Sat, 19 Jan 2008 21:47:28 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so2176815pyb.10 for ; Sat, 19 Jan 2008 13:47:28 -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=xYcjdGpAZP6wYtWaBccw+qwvOCr+aRBH4AZ882b4oF0=; b=ouzgWe765LVCWk3AYR0CrXO482V7Ho4pZ1jrDkYOTcaibdx9+0btQ9DE+vn1wU8OOp140+SoKnGPG1K0fj95zABB1SaFMr9sdZ5/n2vDsHFOkreKrA6wfDfo+1NXLKw46QPNef99oeK/PhzqokxwX4IqSxDOkEoIqQqHDdE+cUw= 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=GxHs2Nzhl00aHFaODOhk5jyK/NjqO5PzlrgiahKjmU8Cq3IOFORZb6H6DbMfOf6WGcxmeNWblgKqh0iwBpTMTJdK3yhAGJZROwZL/94VsCODeMBrwiaMSCa4ChWx0oRpMydCM888t16/S8mHCsQpXkbL2u1cY9o9GTllLhmVe+A= Received: by 10.64.199.2 with SMTP id w2mr10841446qbf.11.1200779246914; Sat, 19 Jan 2008 13:47:26 -0800 (PST) Received: by 10.64.179.20 with HTTP; Sat, 19 Jan 2008 13:47:26 -0800 (PST) Message-ID: Date: Sat, 19 Jan 2008 16:47:26 -0500 From: "Michael MacLeod" To: "Alexander Motin" In-Reply-To: <478E834E.4080302@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> 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 21:47:29 -0000 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 ------------------------------------------------------------ mpd.links: ------------------------------------------------------------ l0: set link type pppoe # set link mtu 1486 # set link mru 1492 set pppoe iface xl0 set pppoe disable incoming set pppoe enable originate l1: set link type pppoe # set link mtu 1486 # set link mru 1492 set pppoe iface xl1 set pppoe disable incoming set pppoe enable originate ------------------------------------------------------------ and finally, the log file: ------------------------------------------------------------ Jan 19 16:34:26 gateway mpd: Multi-link PPP daemon for FreeBSD Jan 19 16:34:26 gateway mpd: Jan 19 16:34:26 gateway mpd: process 1862 started, version 4.3 (root@localhost 18:58 16-Jan-2008) Jan 19 16:34:26 gateway mpd: CONSOLE: listening on 127.0.0.1 5005 Jan 19 16:34:26 gateway mpd: [sam] using interface ng0 Jan 19 16:34:26 gateway mpd: [l0] link: OPEN event Jan 19 16:34:26 gateway mpd: [l0] LCP: Open event Jan 19 16:34:26 gateway mpd: [l0] LCP: state change Initial --> Starting Jan 19 16:34:26 gateway mpd: [l0] LCP: LayerStart Jan 19 16:34:26 gateway mpd: [l0] PPPoE: Connecting to '*' Jan 19 16:34:26 gateway mpd: PPPoE: rec'd ACNAME "bas3-toronto02" Jan 19 16:34:26 gateway mpd: [l0] PPPoE: connection successful Jan 19 16:34:26 gateway mpd: [l0] link: UP event Jan 19 16:34:26 gateway mpd: [l0] link: origination is local Jan 19 16:34:26 gateway mpd: [l0] LCP: Up event Jan 19 16:34:26 gateway mpd: [l0] LCP: state change Starting --> Req-Sent Jan 19 16:34:26 gateway mpd: [l0] LCP: SendConfigReq #1 Jan 19 16:34:26 gateway mpd: PROTOCOMP Jan 19 16:34:26 gateway mpd: MRU 1492 Jan 19 16:34:26 gateway mpd: MAGICNUM 6a64dffc 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 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 Jan 19 16:34:26 gateway mpd: [l0] LCP: SendConfigAck #237 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 Jan 19 16:34:26 gateway mpd: [l0] LCP: state change Req-Sent --> Ack-Sent 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 Jan 19 16:34:26 gateway mpd: [l0] LCP: SendConfigReq #2 Jan 19 16:34:26 gateway mpd: PROTOCOMP Jan 19 16:34:26 gateway mpd: MRU 1492 Jan 19 16:34:26 gateway mpd: MAGICNUM 6a64dffc Jan 19 16:34:26 gateway mpd: [l0] LCP: rec'd Configure Ack #2 (Ack-Sent) Jan 19 16:34:26 gateway mpd: PROTOCOMP Jan 19 16:34:26 gateway mpd: MRU 1492 Jan 19 16:34:26 gateway mpd: MAGICNUM 6a64dffc 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 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 Jan 19 16:34:27 gateway mpd: [l0] LCP: rec'd Configure Request #1 (Req-Sent) Jan 19 16:34:27 gateway mpd: MRU 1492 Jan 19 16:34:27 gateway mpd: MP MRRU 1600 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 Jan 19 16:34:27 gateway mpd: [l0] LCP: SendConfigAck #1 Jan 19 16:34:27 gateway mpd: MRU 1492 Jan 19 16:34:27 gateway mpd: MP MRRU 1600 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 Jan 19 16:34:27 gateway mpd: [l0] LCP: state change Req-Sent --> Ack-Sent Jan 19 16:34:27 gateway mpd: [l0] LCP: rec'd Configure Ack #4 (Ack-Sent) 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: 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) Jan 19 16:34:27 gateway mpd: [l0] LCP: state change Opened --> Stopping Jan 19 16:34:27 gateway mpd: [l0] AUTH: Cleanup Jan 19 16:34:27 gateway mpd: [l0] LCP: SendTerminateAck #5 Jan 19 16:34:27 gateway mpd: [l0] LCP: LayerDown Jan 19 16:34:27 gateway mpd: [l0] LCP: rec'd Terminate Request #238 (Stopping) Jan 19 16:34:27 gateway mpd: [l0] LCP: SendTerminateAck #6 Jan 19 16:34:27 gateway mpd: [l0] PPPoE: connection closed Jan 19 16:34:27 gateway mpd: [l0] link: DOWN event Jan 19 16:34:27 gateway mpd: [l0] LCP: Close event Jan 19 16:34:27 gateway mpd: [l0] LCP: state change Stopping --> Closing Jan 19 16:34:27 gateway mpd: [l0] LCP: Down event Jan 19 16:34:27 gateway mpd: [l0] LCP: LayerFinish Jan 19 16:34:27 gateway mpd: [l0] LCP: state change Closing --> Initial Jan 19 16:34:35 gateway mpd: caught fatal signal term Jan 19 16:34:35 gateway mpd: [sam] IFACE: Close event Jan 19 16:34:35 gateway mpd: [sam] IPCP: Close event Jan 19 16:34:37 gateway mpd: process 1862 terminated 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 From owner-freebsd-net@FreeBSD.ORG Sat Jan 19 23:12:43 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 43DC916A41B for ; Sat, 19 Jan 2008 23:12:43 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id AC78F13C45D for ; Sat, 19 Jan 2008 23:12:42 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: by py-out-1112.google.com with SMTP id u52so2199622pyb.10 for ; Sat, 19 Jan 2008 15:12:41 -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=IP0OVkw7FoY6kkV7XDJCqvL6cYRCeRB5WXJ6C+6Hiog=; b=LX8HV9+XmT/6KPQ0InA9Wz2JwV4xg4g4Q7HazrlFLyGN4S0N67mW69QYYARScBITxaVHcwnn7SwK0Feg3u9QCKDCym0Hla1L/hOWxcDAA0YH3x7nn8h81HElysDJrJekk7BbBofStQps8ZUwku6PX0ofTRvd1y9ukVXfWyTvVqw= 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=Afzpi4nZQJCzRMlj3ty81evr5Vmu0Mlw77/BOBriaXexVPsJT7xbWD8VWzj2DlMiGNx6wCtYwabIn05Ulid8HwQz3Xb0FEXabtMmeB9yRh1FzBkmBWsdfQQ3fZwqoVsQVQU682AFwKi81fgLFbovfPPaDobaW0w+z6iv3tup0a8= Received: by 10.65.61.5 with SMTP id o5mr10985814qbk.62.1200784361052; Sat, 19 Jan 2008 15:12:41 -0800 (PST) Received: by 10.64.179.20 with HTTP; Sat, 19 Jan 2008 15:12:40 -0800 (PST) Message-ID: Date: Sat, 19 Jan 2008 18:12:40 -0500 From: "Michael MacLeod" To: "Alexander Motin" In-Reply-To: <47927858.4050702@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> 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 23:12:43 -0000 On Jan 19, 2008 5:23 PM, Alexander Motin wrote: > 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 Here are the mpd.conf and mpd.link files I ended up having to use (I started with yours then added stuff 'till it stopped complaining). mpd.conf: ------------------------------------------------------------ startup: set console ip 127.0.0.1 set console user username password set console open default: new sam l0 l1 set bundle enable multilink set bundle enable round-robin set iface route default ------------------------------------------------------------ mpd.links: ------------------------------------------------------------ l0: set link type pppoe set pppoe iface xl0 set pppoe disable incoming set pppoe enable originate set auth authname username@teksavvy.com set auth password password set link max-redial 0 open l1: set link type pppoe set pppoe iface xl1 set pppoe disable incoming set pppoe enable originate set auth authname username@teksavvy.com set auth password password set link max-redial 0 open ------------------------------------------------------------ The end result was that one of the links came up. While watching systat -ifstat I could see that one of the links was up, but was only running at approx 2 or 2.5 megabits. Now, I happen to know a bit about the network at the TekSavvy. They have three Juniper ERX's (and I know the IP's of them), and also a Cisco (that is soon to be retired). I have a static IP from TekSavvy, so when connecting with userland ppp I actually specify which ERX I want to connect to. > 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. If that's what it takes, I'm happy to test it. Also, the engineers at my ISP are remarkably approachable, and if you tell me what to ask them I can probably get you a decent answer pretty quick. > Why peer rejected you after second authentication without any reply is a > question to your provider. I'm still learning about all this stuff, and there's a lot going on with all the different layers in PPP that I don't yet know. But like I said, I can approach the engineers at my ISP with questions. Cheers, Mike and once again, the log file: ------------------------------------------------------------ Jan 19 17:48:24 gateway mpd: Multi-link PPP daemon for FreeBSD Jan 19 17:48:24 gateway mpd: Jan 19 17:48:24 gateway mpd: process 2518 started, version 4.3 (root@localhost 18:58 16-Jan-2008) Jan 19 17:48:24 gateway mpd: CONSOLE: listening on 127.0.0.1 5005 Jan 19 17:48:24 gateway mpd: [sam] using interface ng0 Jan 19 17:48:24 gateway mpd: [l0] link: OPEN event Jan 19 17:48:24 gateway mpd: [l0] LCP: Open event Jan 19 17:48:24 gateway mpd: [l0] LCP: state change Initial --> Starting Jan 19 17:48:24 gateway mpd: [l0] LCP: LayerStart Jan 19 17:48:24 gateway mpd: [l1] link: OPEN event Jan 19 17:48:24 gateway mpd: [l1] LCP: Open event Jan 19 17:48:24 gateway mpd: [l1] LCP: state change Initial --> Starting Jan 19 17:48:24 gateway mpd: [l1] LCP: LayerStart Jan 19 17:48:24 gateway mpd: [l0] PPPoE: Connecting to '*' Jan 19 17:48:24 gateway mpd: [l1] PPPoE: Connecting to '*' Jan 19 17:48:24 gateway mpd: PPPoE: rec'd ACNAME "bas3-toronto02" Jan 19 17:48:24 gateway mpd: PPPoE: rec'd ACNAME "bas3-toronto02" Jan 19 17:48:24 gateway mpd: [l0] PPPoE: connection successful Jan 19 17:48:24 gateway mpd: [l0] link: UP event Jan 19 17:48:24 gateway mpd: [l0] link: origination is local Jan 19 17:48:24 gateway mpd: [l0] LCP: Up event Jan 19 17:48:24 gateway mpd: [l0] LCP: state change Starting --> Req-Sent Jan 19 17:48:24 gateway mpd: [l0] LCP: SendConfigReq #1 Jan 19 17:48:24 gateway mpd: PROTOCOMP Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MAGICNUM 2b2e1c22 Jan 19 17:48:24 gateway mpd: MP MRRU 1600 Jan 19 17:48:24 gateway mpd: MP SHORTSEQ Jan 19 17:48:24 gateway mpd: ENDPOINTDISC [802.1] 00 0e 0c dd 03 9b Jan 19 17:48:24 gateway mpd: [l1] PPPoE: connection successful Jan 19 17:48:24 gateway mpd: [l1] link: UP event Jan 19 17:48:24 gateway mpd: [l1] link: origination is local Jan 19 17:48:24 gateway mpd: [l1] LCP: Up event Jan 19 17:48:24 gateway mpd: [l1] LCP: state change Starting --> Req-Sent Jan 19 17:48:24 gateway mpd: [l1] LCP: SendConfigReq #1 Jan 19 17:48:24 gateway mpd: PROTOCOMP Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MAGICNUM 2ac1b8f4 Jan 19 17:48:24 gateway mpd: MP MRRU 1600 Jan 19 17:48:24 gateway mpd: MP SHORTSEQ Jan 19 17:48:24 gateway mpd: ENDPOINTDISC [802.1] 00 0e 0c dd 03 9b Jan 19 17:48:24 gateway mpd: [l0] LCP: rec'd Configure Request #201 (Req-Sent) Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: AUTHPROTO PAP Jan 19 17:48:24 gateway mpd: MAGICNUM 2ca5f3ff Jan 19 17:48:24 gateway mpd: [l0] LCP: SendConfigAck #201 Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: AUTHPROTO PAP Jan 19 17:48:24 gateway mpd: MAGICNUM 2ca5f3ff Jan 19 17:48:24 gateway mpd: [l0] LCP: state change Req-Sent --> Ack-Sent Jan 19 17:48:24 gateway mpd: [l0] LCP: rec'd Configure Reject #1 (Ack-Sent) Jan 19 17:48:24 gateway mpd: MP MRRU 1600 Jan 19 17:48:24 gateway mpd: MP SHORTSEQ Jan 19 17:48:24 gateway mpd: ENDPOINTDISC [802.1] 00 0e 0c dd 03 9b Jan 19 17:48:24 gateway mpd: [l0] LCP: SendConfigReq #2 Jan 19 17:48:24 gateway mpd: PROTOCOMP Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MAGICNUM 2b2e1c22 Jan 19 17:48:24 gateway mpd: [l1] LCP: rec'd Configure Request #233 (Req-Sent) Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: AUTHPROTO PAP Jan 19 17:48:24 gateway mpd: MAGICNUM 7c51d9e2 Jan 19 17:48:24 gateway mpd: [l1] LCP: SendConfigAck #233 Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: AUTHPROTO PAP Jan 19 17:48:24 gateway mpd: MAGICNUM 7c51d9e2 Jan 19 17:48:24 gateway mpd: [l1] LCP: state change Req-Sent --> Ack-Sent Jan 19 17:48:24 gateway mpd: [l1] LCP: rec'd Configure Reject #1 (Ack-Sent) Jan 19 17:48:24 gateway mpd: MP MRRU 1600 Jan 19 17:48:24 gateway mpd: MP SHORTSEQ Jan 19 17:48:24 gateway mpd: ENDPOINTDISC [802.1] 00 0e 0c dd 03 9b Jan 19 17:48:24 gateway mpd: [l1] LCP: SendConfigReq #2 Jan 19 17:48:24 gateway mpd: PROTOCOMP Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MAGICNUM 2ac1b8f4 Jan 19 17:48:24 gateway mpd: [l0] LCP: rec'd Configure Ack #2 (Ack-Sent) Jan 19 17:48:24 gateway mpd: PROTOCOMP Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MAGICNUM 2b2e1c22 Jan 19 17:48:24 gateway mpd: [l0] LCP: state change Ack-Sent --> Opened Jan 19 17:48:24 gateway mpd: [l0] LCP: auth: peer wants PAP, I want nothing Jan 19 17:48:24 gateway mpd: [l0] PAP: using authname "username@teksavvy.com" Jan 19 17:48:24 gateway mpd: [l0] PAP: sending REQUEST len:33 Jan 19 17:48:24 gateway mpd: [l0] LCP: LayerUp Jan 19 17:48:24 gateway mpd: [l1] LCP: rec'd Configure Ack #2 (Ack-Sent) Jan 19 17:48:24 gateway mpd: PROTOCOMP Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MAGICNUM 2ac1b8f4 Jan 19 17:48:24 gateway mpd: [l1] LCP: state change Ack-Sent --> Opened Jan 19 17:48:24 gateway mpd: [l1] LCP: auth: peer wants PAP, I want nothing Jan 19 17:48:24 gateway mpd: [l1] PAP: using authname "username@teksavvy.com" Jan 19 17:48:24 gateway mpd: [l1] PAP: sending REQUEST len:33 Jan 19 17:48:24 gateway mpd: [l1] LCP: LayerUp Jan 19 17:48:24 gateway mpd: [l0] LCP: rec'd Configure Request #224 (Opened) Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MP MRRU 32719 Jan 19 17:48:24 gateway mpd: ENDPOINTDISC [LOCAL] 34 36 30 36 33 38 30 30 39 33 00 00 00 00 00 Jan 19 17:48:24 gateway mpd: AUTHPROTO PAP Jan 19 17:48:24 gateway mpd: MAGICNUM 2f9a5450 Jan 19 17:48:24 gateway mpd: [l0] LCP: LayerDown Jan 19 17:48:24 gateway mpd: [l0] LCP: SendConfigReq #3 Jan 19 17:48:24 gateway mpd: PROTOCOMP Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MAGICNUM 2b2e1c22 Jan 19 17:48:24 gateway mpd: [l0] LCP: SendConfigNak #224 Jan 19 17:48:24 gateway mpd: MP MRRU 1600 Jan 19 17:48:24 gateway mpd: [l0] LCP: state change Opened --> Req-Sent Jan 19 17:48:24 gateway mpd: [l0] AUTH: Cleanup Jan 19 17:48:24 gateway mpd: [l0] LCP: rec'd Configure Nak #3 (Req-Sent) Jan 19 17:48:24 gateway mpd: MP MRRU 32719 Jan 19 17:48:24 gateway mpd: ENDPOINTDISC [NULL] Jan 19 17:48:24 gateway mpd: [l0] LCP: SendConfigReq #4 Jan 19 17:48:24 gateway mpd: PROTOCOMP Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MAGICNUM 2b2e1c22 Jan 19 17:48:24 gateway mpd: [l0] LCP: rec'd Configure Request #225 (Req-Sent) Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MP MRRU 1600 Jan 19 17:48:24 gateway mpd: ENDPOINTDISC [LOCAL] 34 36 30 36 33 38 30 30 39 33 00 00 00 00 00 Jan 19 17:48:24 gateway mpd: AUTHPROTO PAP Jan 19 17:48:24 gateway mpd: MAGICNUM 2f9a5450 Jan 19 17:48:24 gateway mpd: [l0] LCP: SendConfigAck #225 Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MP MRRU 1600 Jan 19 17:48:24 gateway mpd: ENDPOINTDISC [LOCAL] 34 36 30 36 33 38 30 30 39 33 00 00 00 00 00 Jan 19 17:48:24 gateway mpd: AUTHPROTO PAP Jan 19 17:48:24 gateway mpd: MAGICNUM 2f9a5450 Jan 19 17:48:24 gateway mpd: [l0] LCP: state change Req-Sent --> Ack-Sent Jan 19 17:48:24 gateway mpd: [l0] LCP: rec'd Configure Ack #4 (Ack-Sent) Jan 19 17:48:24 gateway mpd: PROTOCOMP Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MAGICNUM 2b2e1c22 Jan 19 17:48:24 gateway mpd: [l0] LCP: state change Ack-Sent --> Opened Jan 19 17:48:24 gateway mpd: [l0] LCP: auth: peer wants PAP, I want nothing Jan 19 17:48:24 gateway mpd: [l0] PAP: using authname "username@teksavvy.com" Jan 19 17:48:24 gateway mpd: [l0] PAP: sending REQUEST len:33 Jan 19 17:48:24 gateway mpd: [l0] LCP: LayerUp Jan 19 17:48:24 gateway mpd: [l0] LCP: rec'd Terminate Request #226 (Opened) Jan 19 17:48:24 gateway mpd: [l0] LCP: state change Opened --> Stopping Jan 19 17:48:24 gateway mpd: [l0] AUTH: Cleanup Jan 19 17:48:24 gateway mpd: [l0] LCP: SendTerminateAck #5 Jan 19 17:48:24 gateway mpd: [l0] LCP: LayerDown Jan 19 17:48:24 gateway mpd: [l0] LCP: rec'd Terminate Request #202 (Stopping) Jan 19 17:48:24 gateway mpd: [l0] LCP: SendTerminateAck #6 Jan 19 17:48:24 gateway mpd: [l0] PPPoE: connection closed Jan 19 17:48:24 gateway mpd: [l0] link: DOWN event Jan 19 17:48:24 gateway mpd: [l0] link: reconnection attempt 1 Jan 19 17:48:24 gateway mpd: [l0] LCP: Down event Jan 19 17:48:24 gateway mpd: [l0] LCP: state change Stopping --> Starting Jan 19 17:48:24 gateway mpd: [l0] pausing 6 seconds before open Jan 19 17:48:24 gateway mpd: [l1] LCP: rec'd Configure Request #159 (Opened) Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MP MRRU 32719 Jan 19 17:48:24 gateway mpd: ENDPOINTDISC [LOCAL] 34 36 30 37 32 31 30 30 39 31 00 00 00 00 00 Jan 19 17:48:24 gateway mpd: AUTHPROTO PAP Jan 19 17:48:24 gateway mpd: MAGICNUM 5863420a Jan 19 17:48:24 gateway mpd: [l1] LCP: LayerDown Jan 19 17:48:24 gateway mpd: [l1] LCP: SendConfigReq #3 Jan 19 17:48:24 gateway mpd: PROTOCOMP Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MAGICNUM 2ac1b8f4 Jan 19 17:48:24 gateway mpd: [l1] LCP: SendConfigNak #159 Jan 19 17:48:24 gateway mpd: MP MRRU 1600 Jan 19 17:48:24 gateway mpd: [l1] LCP: state change Opened --> Req-Sent Jan 19 17:48:24 gateway mpd: [l1] AUTH: Cleanup Jan 19 17:48:24 gateway mpd: [l1] LCP: rec'd Configure Nak #3 (Req-Sent) Jan 19 17:48:24 gateway mpd: MP MRRU 32719 Jan 19 17:48:24 gateway mpd: ENDPOINTDISC [NULL] Jan 19 17:48:24 gateway mpd: [l1] LCP: SendConfigReq #4 Jan 19 17:48:24 gateway mpd: PROTOCOMP Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MAGICNUM 2ac1b8f4 Jan 19 17:48:24 gateway mpd: [l1] LCP: rec'd Configure Request #160 (Req-Sent) Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MP MRRU 1600 Jan 19 17:48:24 gateway mpd: ENDPOINTDISC [LOCAL] 34 36 30 37 32 31 30 30 39 31 00 00 00 00 00 Jan 19 17:48:24 gateway mpd: AUTHPROTO PAP Jan 19 17:48:24 gateway mpd: MAGICNUM 5863420a Jan 19 17:48:24 gateway mpd: [l1] LCP: SendConfigAck #160 Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MP MRRU 1600 Jan 19 17:48:24 gateway mpd: ENDPOINTDISC [LOCAL] 34 36 30 37 32 31 30 30 39 31 00 00 00 00 00 Jan 19 17:48:24 gateway mpd: AUTHPROTO PAP Jan 19 17:48:24 gateway mpd: MAGICNUM 5863420a Jan 19 17:48:24 gateway mpd: [l1] LCP: state change Req-Sent --> Ack-Sent Jan 19 17:48:24 gateway mpd: [l1] LCP: rec'd Configure Ack #4 (Ack-Sent) Jan 19 17:48:24 gateway mpd: PROTOCOMP Jan 19 17:48:24 gateway mpd: MRU 1492 Jan 19 17:48:24 gateway mpd: MAGICNUM 2ac1b8f4 Jan 19 17:48:24 gateway mpd: [l1] LCP: state change Ack-Sent --> Opened Jan 19 17:48:24 gateway mpd: [l1] LCP: auth: peer wants PAP, I want nothing Jan 19 17:48:24 gateway mpd: [l1] PAP: using authname "username@teksavvy.com" Jan 19 17:48:24 gateway mpd: [l1] PAP: sending REQUEST len:33 Jan 19 17:48:24 gateway mpd: [l1] LCP: LayerUp Jan 19 17:48:24 gateway mpd: [l1] LCP: rec'd Terminate Request #161 (Opened) Jan 19 17:48:24 gateway mpd: [l1] LCP: state change Opened --> Stopping Jan 19 17:48:24 gateway mpd: [l1] AUTH: Cleanup Jan 19 17:48:24 gateway mpd: [l1] LCP: SendTerminateAck #5 Jan 19 17:48:24 gateway mpd: [l1] LCP: LayerDown Jan 19 17:48:25 gateway mpd: [l1] LCP: rec'd Terminate Request #234 (Stopping) Jan 19 17:48:25 gateway mpd: [l1] LCP: SendTerminateAck #6 Jan 19 17:48:25 gateway mpd: [l1] PPPoE: connection closed Jan 19 17:48:25 gateway mpd: [l1] link: DOWN event Jan 19 17:48:25 gateway mpd: [l1] link: reconnection attempt 1 Jan 19 17:48:25 gateway mpd: [l1] LCP: Down event Jan 19 17:48:25 gateway mpd: [l1] LCP: state change Stopping --> Starting Jan 19 17:48:25 gateway mpd: [l1] pausing 5 seconds before open Jan 19 17:48:30 gateway mpd: [l1] PPPoE: Connecting to '*' Jan 19 17:48:30 gateway mpd: PPPoE: rec'd ACNAME "bas3-toronto02" Jan 19 17:48:30 gateway mpd: [l1] PPPoE: connection successful Jan 19 17:48:30 gateway mpd: [l1] link: UP event Jan 19 17:48:30 gateway mpd: [l1] link: origination is local Jan 19 17:48:30 gateway mpd: [l1] LCP: Up event Jan 19 17:48:30 gateway mpd: [l1] LCP: state change Starting --> Req-Sent Jan 19 17:48:30 gateway mpd: [l1] LCP: SendConfigReq #7 Jan 19 17:48:30 gateway mpd: PROTOCOMP Jan 19 17:48:30 gateway mpd: MRU 1492 Jan 19 17:48:30 gateway mpd: MAGICNUM de35ce9a Jan 19 17:48:30 gateway mpd: MP MRRU 1600 Jan 19 17:48:30 gateway mpd: MP SHORTSEQ Jan 19 17:48:30 gateway mpd: ENDPOINTDISC [802.1] 00 0e 0c dd 03 9b Jan 19 17:48:30 gateway mpd: [l1] LCP: rec'd Configure Request #166 (Req-Sent) Jan 19 17:48:30 gateway mpd: MRU 1492 Jan 19 17:48:30 gateway mpd: AUTHPROTO PAP Jan 19 17:48:30 gateway mpd: MAGICNUM 4725e149 Jan 19 17:48:30 gateway mpd: [l1] LCP: SendConfigAck #166 Jan 19 17:48:30 gateway mpd: MRU 1492 Jan 19 17:48:30 gateway mpd: AUTHPROTO PAP Jan 19 17:48:30 gateway mpd: MAGICNUM 4725e149 Jan 19 17:48:30 gateway mpd: [l1] LCP: state change Req-Sent --> Ack-Sent Jan 19 17:48:30 gateway mpd: [l1] LCP: rec'd Configure Reject #7 (Ack-Sent) Jan 19 17:48:30 gateway mpd: MP MRRU 1600 Jan 19 17:48:30 gateway mpd: MP SHORTSEQ Jan 19 17:48:30 gateway mpd: ENDPOINTDISC [802.1] 00 0e 0c dd 03 9b Jan 19 17:48:30 gateway mpd: [l1] LCP: SendConfigReq #8 Jan 19 17:48:30 gateway mpd: PROTOCOMP Jan 19 17:48:30 gateway mpd: MRU 1492 Jan 19 17:48:30 gateway mpd: MAGICNUM de35ce9a Jan 19 17:48:30 gateway mpd: [l1] LCP: rec'd Configure Ack #8 (Ack-Sent) Jan 19 17:48:30 gateway mpd: PROTOCOMP Jan 19 17:48:30 gateway mpd: MRU 1492 Jan 19 17:48:30 gateway mpd: MAGICNUM de35ce9a Jan 19 17:48:30 gateway mpd: [l1] LCP: state change Ack-Sent --> Opened Jan 19 17:48:30 gateway mpd: [l1] LCP: auth: peer wants PAP, I want nothing Jan 19 17:48:30 gateway mpd: [l1] PAP: using authname "username@teksavvy.com" Jan 19 17:48:30 gateway mpd: [l1] PAP: sending REQUEST len:33 Jan 19 17:48:30 gateway mpd: [l1] LCP: LayerUp Jan 19 17:48:30 gateway mpd: [l1] LCP: rec'd Configure Request #42 (Opened) Jan 19 17:48:30 gateway mpd: MRU 1492 Jan 19 17:48:30 gateway mpd: MP MRRU 32719 Jan 19 17:48:30 gateway mpd: ENDPOINTDISC [LOCAL] 34 36 30 37 32 33 30 30 39 39 00 00 00 00 00 Jan 19 17:48:30 gateway mpd: AUTHPROTO PAP Jan 19 17:48:30 gateway mpd: MAGICNUM 04500a48 Jan 19 17:48:30 gateway mpd: [l1] LCP: LayerDown Jan 19 17:48:30 gateway mpd: [l1] LCP: SendConfigReq #9 Jan 19 17:48:30 gateway mpd: PROTOCOMP Jan 19 17:48:30 gateway mpd: MRU 1492 Jan 19 17:48:30 gateway mpd: MAGICNUM de35ce9a Jan 19 17:48:30 gateway mpd: [l1] LCP: SendConfigNak #42 Jan 19 17:48:30 gateway mpd: MP MRRU 1600 Jan 19 17:48:30 gateway mpd: [l1] LCP: state change Opened --> Req-Sent Jan 19 17:48:30 gateway mpd: [l1] AUTH: Cleanup Jan 19 17:48:30 gateway mpd: [l1] LCP: rec'd Configure Nak #9 (Req-Sent) Jan 19 17:48:30 gateway mpd: MP MRRU 32719 Jan 19 17:48:30 gateway mpd: ENDPOINTDISC [NULL] Jan 19 17:48:30 gateway mpd: [l1] LCP: SendConfigReq #10 Jan 19 17:48:30 gateway mpd: PROTOCOMP Jan 19 17:48:30 gateway mpd: MRU 1492 Jan 19 17:48:30 gateway mpd: MAGICNUM de35ce9a Jan 19 17:48:30 gateway mpd: [l1] LCP: rec'd Configure Request #43 (Req-Sent) Jan 19 17:48:30 gateway mpd: MRU 1492 Jan 19 17:48:30 gateway mpd: MP MRRU 1600 Jan 19 17:48:30 gateway mpd: ENDPOINTDISC [LOCAL] 34 36 30 37 32 33 30 30 39 39 00 00 00 00 00 Jan 19 17:48:30 gateway mpd: AUTHPROTO PAP Jan 19 17:48:30 gateway mpd: MAGICNUM 04500a48 Jan 19 17:48:30 gateway mpd: [l1] LCP: SendConfigAck #43 Jan 19 17:48:30 gateway mpd: MRU 1492 Jan 19 17:48:30 gateway mpd: MP MRRU 1600 Jan 19 17:48:30 gateway mpd: ENDPOINTDISC [LOCAL] 34 36 30 37 32 33 30 30 39 39 00 00 00 00 00 Jan 19 17:48:30 gateway mpd: AUTHPROTO PAP Jan 19 17:48:30 gateway mpd: MAGICNUM 04500a48 Jan 19 17:48:30 gateway mpd: [l1] LCP: state change Req-Sent --> Ack-Sent Jan 19 17:48:30 gateway mpd: [l1] LCP: rec'd Configure Ack #10 (Ack-Sent) Jan 19 17:48:30 gateway mpd: PROTOCOMP Jan 19 17:48:30 gateway mpd: MRU 1492 Jan 19 17:48:30 gateway mpd: MAGICNUM de35ce9a Jan 19 17:48:30 gateway mpd: [l1] LCP: state change Ack-Sent --> Opened Jan 19 17:48:30 gateway mpd: [l1] LCP: auth: peer wants PAP, I want nothing Jan 19 17:48:30 gateway mpd: [l1] PAP: using authname "username@teksavvy.com" Jan 19 17:48:30 gateway mpd: [l1] PAP: sending REQUEST len:33 Jan 19 17:48:30 gateway mpd: [l1] LCP: LayerUp Jan 19 17:48:30 gateway mpd: [l1] LCP: rec'd Terminate Request #44 (Opened) Jan 19 17:48:30 gateway mpd: [l1] LCP: state change Opened --> Stopping Jan 19 17:48:30 gateway mpd: [l1] AUTH: Cleanup Jan 19 17:48:30 gateway mpd: [l1] LCP: SendTerminateAck #11 Jan 19 17:48:30 gateway mpd: [l1] LCP: LayerDown Jan 19 17:48:30 gateway mpd: [l1] LCP: rec'd Terminate Request #167 (Stopping) Jan 19 17:48:30 gateway mpd: [l1] LCP: SendTerminateAck #12 Jan 19 17:48:30 gateway mpd: [l1] PPPoE: connection closed Jan 19 17:48:30 gateway mpd: [l1] link: DOWN event Jan 19 17:48:30 gateway mpd: [l1] link: reconnection attempt 2 Jan 19 17:48:30 gateway mpd: [l1] LCP: Down event Jan 19 17:48:30 gateway mpd: [l1] LCP: state change Stopping --> Starting Jan 19 17:48:30 gateway mpd: [l1] pausing 5 seconds before open Jan 19 17:48:30 gateway mpd: [l0] PPPoE: Connecting to '*' Jan 19 17:48:30 gateway mpd: PPPoE: rec'd ACNAME "bas3-toronto02" Jan 19 17:48:30 gateway mpd: [l0] PPPoE: connection successful Jan 19 17:48:30 gateway mpd: [l0] link: UP event Jan 19 17:48:30 gateway mpd: [l0] link: origination is local Jan 19 17:48:30 gateway mpd: [l0] LCP: Up event Jan 19 17:48:30 gateway mpd: [l0] LCP: state change Starting --> Req-Sent Jan 19 17:48:30 gateway mpd: [l0] LCP: SendConfigReq #7 Jan 19 17:48:30 gateway mpd: PROTOCOMP Jan 19 17:48:30 gateway mpd: MRU 1492 Jan 19 17:48:30 gateway mpd: MAGICNUM 5bad4a9e Jan 19 17:48:30 gateway mpd: MP MRRU 1600 Jan 19 17:48:30 gateway mpd: MP SHORTSEQ Jan 19 17:48:30 gateway mpd: ENDPOINTDISC [802.1] 00 0e 0c dd 03 9b Jan 19 17:48:31 gateway mpd: [l0] LCP: rec'd Configure Request #142 (Req-Sent) Jan 19 17:48:31 gateway mpd: MRU 1492 Jan 19 17:48:31 gateway mpd: AUTHPROTO PAP Jan 19 17:48:31 gateway mpd: MAGICNUM 44263bf5 Jan 19 17:48:31 gateway mpd: [l0] LCP: SendConfigAck #142 Jan 19 17:48:31 gateway mpd: MRU 1492 Jan 19 17:48:31 gateway mpd: AUTHPROTO PAP Jan 19 17:48:31 gateway mpd: MAGICNUM 44263bf5 Jan 19 17:48:31 gateway mpd: [l0] LCP: state change Req-Sent --> Ack-Sent Jan 19 17:48:31 gateway mpd: [l0] LCP: rec'd Configure Reject #7 (Ack-Sent) Jan 19 17:48:31 gateway mpd: MP MRRU 1600 Jan 19 17:48:31 gateway mpd: MP SHORTSEQ Jan 19 17:48:31 gateway mpd: ENDPOINTDISC [802.1] 00 0e 0c dd 03 9b Jan 19 17:48:31 gateway mpd: [l0] LCP: SendConfigReq #8 Jan 19 17:48:31 gateway mpd: PROTOCOMP Jan 19 17:48:31 gateway mpd: MRU 1492 Jan 19 17:48:31 gateway mpd: MAGICNUM 5bad4a9e Jan 19 17:48:31 gateway mpd: [l0] LCP: rec'd Configure Ack #8 (Ack-Sent) Jan 19 17:48:31 gateway mpd: PROTOCOMP Jan 19 17:48:31 gateway mpd: MRU 1492 Jan 19 17:48:31 gateway mpd: MAGICNUM 5bad4a9e Jan 19 17:48:31 gateway mpd: [l0] LCP: state change Ack-Sent --> Opened Jan 19 17:48:31 gateway mpd: [l0] LCP: auth: peer wants PAP, I want nothing Jan 19 17:48:31 gateway mpd: [l0] PAP: using authname "username@teksavvy.com" Jan 19 17:48:31 gateway mpd: [l0] PAP: sending REQUEST len:33 Jan 19 17:48:31 gateway mpd: [l0] LCP: LayerUp Jan 19 17:48:31 gateway mpd: [l0] LCP: rec'd Configure Request #41 (Opened) Jan 19 17:48:31 gateway mpd: MRU 1492 Jan 19 17:48:31 gateway mpd: MP MRRU 32719 Jan 19 17:48:31 gateway mpd: ENDPOINTDISC [LOCAL] 34 36 30 37 32 33 30 30 39 39 00 00 00 00 00 Jan 19 17:48:31 gateway mpd: AUTHPROTO PAP Jan 19 17:48:31 gateway mpd: MAGICNUM 6075351f Jan 19 17:48:31 gateway mpd: [l0] LCP: LayerDown Jan 19 17:48:31 gateway mpd: [l0] LCP: SendConfigReq #9 Jan 19 17:48:31 gateway mpd: PROTOCOMP Jan 19 17:48:31 gateway mpd: MRU 1492 Jan 19 17:48:31 gateway mpd: MAGICNUM 5bad4a9e Jan 19 17:48:31 gateway mpd: [l0] LCP: SendConfigNak #41 Jan 19 17:48:31 gateway mpd: MP MRRU 1600 Jan 19 17:48:31 gateway mpd: [l0] LCP: state change Opened --> Req-Sent Jan 19 17:48:31 gateway mpd: [l0] AUTH: Cleanup Jan 19 17:48:31 gateway mpd: [l0] LCP: rec'd Configure Nak #9 (Req-Sent) Jan 19 17:48:31 gateway mpd: MP MRRU 32719 Jan 19 17:48:31 gateway mpd: ENDPOINTDISC [NULL] Jan 19 17:48:31 gateway mpd: [l0] LCP: SendConfigReq #10 Jan 19 17:48:31 gateway mpd: PROTOCOMP Jan 19 17:48:31 gateway mpd: MRU 1492 Jan 19 17:48:31 gateway mpd: MAGICNUM 5bad4a9e Jan 19 17:48:31 gateway mpd: [l0] LCP: rec'd Configure Request #42 (Req-Sent) Jan 19 17:48:31 gateway mpd: MRU 1492 Jan 19 17:48:31 gateway mpd: MP MRRU 1600 Jan 19 17:48:31 gateway mpd: ENDPOINTDISC [LOCAL] 34 36 30 37 32 33 30 30 39 39 00 00 00 00 00 Jan 19 17:48:31 gateway mpd: AUTHPROTO PAP Jan 19 17:48:31 gateway mpd: MAGICNUM 6075351f Jan 19 17:48:31 gateway mpd: [l0] LCP: SendConfigAck #42 Jan 19 17:48:31 gateway mpd: MRU 1492 Jan 19 17:48:31 gateway mpd: MP MRRU 1600 Jan 19 17:48:31 gateway mpd: ENDPOINTDISC [LOCAL] 34 36 30 37 32 33 30 30 39 39 00 00 00 00 00 Jan 19 17:48:31 gateway mpd: AUTHPROTO PAP Jan 19 17:48:31 gateway mpd: MAGICNUM 6075351f Jan 19 17:48:31 gateway mpd: [l0] LCP: state change Req-Sent --> Ack-Sent Jan 19 17:48:31 gateway mpd: [l0] LCP: rec'd Configure Ack #10 (Ack-Sent) Jan 19 17:48:31 gateway mpd: PROTOCOMP Jan 19 17:48:31 gateway mpd: MRU 1492 Jan 19 17:48:31 gateway mpd: MAGICNUM 5bad4a9e Jan 19 17:48:31 gateway mpd: [l0] LCP: state change Ack-Sent --> Opened Jan 19 17:48:31 gateway mpd: [l0] LCP: auth: peer wants PAP, I want nothing Jan 19 17:48:31 gateway mpd: [l0] PAP: using authname "username@teksavvy.com" Jan 19 17:48:31 gateway mpd: [l0] PAP: sending REQUEST len:33 Jan 19 17:48:31 gateway mpd: [l0] LCP: LayerUp Jan 19 17:48:31 gateway mpd: [l0] LCP: rec'd Terminate Request #43 (Opened) Jan 19 17:48:31 gateway mpd: [l0] LCP: state change Opened --> Stopping Jan 19 17:48:31 gateway mpd: [l0] AUTH: Cleanup Jan 19 17:48:31 gateway mpd: [l0] LCP: SendTerminateAck #11 Jan 19 17:48:31 gateway mpd: [l0] LCP: LayerDown Jan 19 17:48:31 gateway mpd: [l0] LCP: rec'd Terminate Request #143 (Stopping) Jan 19 17:48:31 gateway mpd: [l0] LCP: SendTerminateAck #12 Jan 19 17:48:31 gateway mpd: [l0] PPPoE: connection closed Jan 19 17:48:31 gateway mpd: [l0] link: DOWN event Jan 19 17:48:31 gateway mpd: [l0] link: reconnection attempt 2 Jan 19 17:48:31 gateway mpd: [l0] LCP: Down event Jan 19 17:48:31 gateway mpd: [l0] LCP: state change Stopping --> Starting Jan 19 17:48:31 gateway mpd: [l0] pausing 5 seconds before open etc etc etc ------------------------------------------------------------