From owner-freebsd-net@FreeBSD.ORG Sun Apr 10 11:14:56 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A88F016A4CE; Sun, 10 Apr 2005 11:14:56 +0000 (GMT) Received: from mail.ciam.ru (mail.ciam.ru [213.147.57.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id F176743D31; Sun, 10 Apr 2005 11:14:55 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from ppp83-237-181-134.pppoe.mtu-net.ru ([83.237.181.134] helo=[192.168.0.3]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1DKaP0-000FPm-E6; Sun, 10 Apr 2005 15:14:54 +0400 Message-ID: <42590AB3.3070106@FreeBSD.org> Date: Sun, 10 Apr 2005 15:14:59 +0400 From: Sergey Matveychuk User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050111 X-Accept-Language: en-us, en, ru MIME-Version: 1.0 To: net@FreeBSD.org, questions@FreeBSD.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: route entries after ICMP redirect X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 10 Apr 2005 11:14:56 -0000 I've got some problem with route entries that was created after ICMP redirect messages. They are never expired. Our default gateway (it's a HP switch) send ICMP redirect messages if it see a short path to destination. It's makes it not so overloaded. But pathes sometime changed. There is no problem with Windows workstations, they are rebooted daily. But my FreeBSD boxes hold dinamic route entries forever. I've looked through RFCs and Stevens' books and found no answer on what TTL for this entries. Now I just add route flush as cron job. But may be there is another way? -- Sem. From owner-freebsd-net@FreeBSD.ORG Mon Apr 11 01:27:20 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A225316A4CE; Mon, 11 Apr 2005 01:27:20 +0000 (GMT) Received: from mail-relay1.yahoo.com (mail-relay1.yahoo.com [216.145.48.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E57C43D49; Mon, 11 Apr 2005 01:27:20 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98])j3B1RINn077939; Sun, 10 Apr 2005 18:27:18 -0700 (PDT) Date: Mon, 11 Apr 2005 10:27:17 +0900 Message-ID: From: gnn@FreeBSD.org To: Sergey Matveychuk In-Reply-To: <42590AB3.3070106@FreeBSD.org> References: <42590AB3.3070106@FreeBSD.org> User-Agent: Wanderlust/2.12.0 (Your Wildest Dreams) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3.50 (powerpc-apple-darwin7.7.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII cc: questions@FreeBSD.org cc: net@FreeBSD.org Subject: Re: route entries after ICMP redirect X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 11 Apr 2005 01:27:21 -0000 At Sun, 10 Apr 2005 15:14:59 +0400, Sergey Matveychuk wrote: > > I've got some problem with route entries that was created after ICMP > redirect messages. They are never expired. > > Our default gateway (it's a HP switch) send ICMP redirect messages if it > see a short path to destination. It's makes it not so overloaded. But > pathes sometime changed. There is no problem with Windows workstations, > they are rebooted daily. But my FreeBSD boxes hold dinamic route entries > forever. > > I've looked through RFCs and Stevens' books and found no answer on what > TTL for this entries. > Now I just add route flush as cron job. But may be there is another way? Routes set through the redirect path do not have a timeout associated with them. The redirect message usually implies an error in the network setup of your machines which would have to be handled by a human being changing the configuration. If you want to handle this in a more clever way than a cron job you could write a small daemon which reads routing messages and does "the right thing" for whatever your situation is. Later, George From owner-freebsd-net@FreeBSD.ORG Mon Apr 11 05:20:33 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48FA716A4CE; Mon, 11 Apr 2005 05:20:33 +0000 (GMT) Received: from relay-er5.mbrd.ru (relay-er5.mbrd.ru [194.117.71.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEE7243D39; Mon, 11 Apr 2005 05:20:32 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from msd.mbrd.ru ([172.16.4.9]) by relay-er5.mbrd.ru with esmtp (Exim 4.x) id 1DKrLb-000I39-3L; Mon, 11 Apr 2005 09:20:31 +0400 Message-ID: <425A091E.1000207@FreeBSD.org> Date: Mon, 11 Apr 2005 09:20:30 +0400 From: Sergey Matveychuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: gnn@FreeBSD.org References: <42590AB3.3070106@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: questions@FreeBSD.org cc: net@FreeBSD.org Subject: Re: route entries after ICMP redirect X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 11 Apr 2005 05:20:33 -0000 gnn@FreeBSD.org wrote: > If you want to handle this in a more clever way than a cron job you > could write a small daemon which reads routing messages and does "the > right thing" for whatever your situation is. I've explore a code and found I can do quite easy addition for dynamic routes - fill an expire field, check it periodicaly and remove expired entries (just like for arp entries). I think to do a sysctl variable for indication what time will set as expire values and set it to zero by default (no expires). -- Sem. From owner-freebsd-net@FreeBSD.ORG Mon Apr 11 06:25:52 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43BAB16A4CE; Mon, 11 Apr 2005 06:25:52 +0000 (GMT) Received: from gen129.n001.c02.escapebox.net (gen129.n001.c02.escapebox.net [213.73.91.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8CEB43D1F; Mon, 11 Apr 2005 06:25:51 +0000 (GMT) (envelope-from gemini@geminix.org) Message-ID: <425A186C.8050005@geminix.org> Date: Mon, 11 Apr 2005 08:25:48 +0200 From: Uwe Doering Organization: Private UNIX Site User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.6) Gecko/20050326 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sergey Matveychuk References: <42590AB3.3070106@FreeBSD.org> In-Reply-To: <42590AB3.3070106@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Received: from gemini by geminix.org with asmtp (TLSv1:AES256-SHA:256) (Exim 3.36 #1) id 1DKsMn-000PpT-00; Mon, 11 Apr 2005 08:25:49 +0200 cc: questions@FreeBSD.org cc: net@FreeBSD.org Subject: Re: route entries after ICMP redirect X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 11 Apr 2005 06:25:52 -0000 Sergey Matveychuk wrote: > I've got some problem with route entries that was created after ICMP > redirect messages. They are never expired. > > Our default gateway (it's a HP switch) send ICMP redirect messages if it > see a short path to destination. It's makes it not so overloaded. But > pathes sometime changed. There is no problem with Windows workstations, > they are rebooted daily. But my FreeBSD boxes hold dinamic route entries > forever. > > I've looked through RFCs and Stevens' books and found no answer on what > TTL for this entries. > Now I just add route flush as cron job. But may be there is another way? This has been fixed in CVS in MAIN (rev. 1.52) and MFC'ed to RELENG_4 (rev. 1.37.2.5) and RELENG_5 (rev. 1.51.4.2) a couple of weeks ago: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in_rmx.c So either syncing to one of these branches or applying the relevant patch manually to your kernel sources ought to solve the problem. Uwe -- Uwe Doering | EscapeBox - Managed On-Demand UNIX Servers gemini@geminix.org | http://www.escapebox.net From owner-freebsd-net@FreeBSD.ORG Mon Apr 11 09:11:06 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 595F016A4CE; Mon, 11 Apr 2005 09:11:06 +0000 (GMT) Received: from relay-er5.mbrd.ru (relay-er5.mbrd.ru [194.117.71.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 021E143D46; Mon, 11 Apr 2005 09:11:06 +0000 (GMT) (envelope-from sem@FreeBSD.org) Received: from msd.mbrd.ru ([172.16.4.9]) by relay-er5.mbrd.ru with esmtp (Exim 4.x) id 1DKuwi-000MsU-F6; Mon, 11 Apr 2005 13:11:04 +0400 Message-ID: <425A3F27.8000501@FreeBSD.org> Date: Mon, 11 Apr 2005 13:11:03 +0400 From: Sergey Matveychuk User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050319 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Uwe Doering References: <42590AB3.3070106@FreeBSD.org> <425A186C.8050005@geminix.org> In-Reply-To: <425A186C.8050005@geminix.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: questions@FreeBSD.org cc: net@FreeBSD.org Subject: Re: route entries after ICMP redirect X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 11 Apr 2005 09:11:06 -0000 Uwe Doering wrote: > This has been fixed in CVS in MAIN (rev. 1.52) and MFC'ed to RELENG_4 > (rev. 1.37.2.5) and RELENG_5 (rev. 1.51.4.2) a couple of weeks ago: Oh, thank you! And thanks to ru@! -- Sem. From owner-freebsd-net@FreeBSD.ORG Mon Apr 11 10:13:19 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A594116A509 for ; Mon, 11 Apr 2005 10:13:19 +0000 (GMT) Received: from orion.erdves.lt (ns2.lrtc.net [217.9.240.98]) by mx1.FreeBSD.org (Postfix) with SMTP id 8FCA143D48 for ; Mon, 11 Apr 2005 10:13:17 +0000 (GMT) (envelope-from dnr@freemail.lt) Received: (qmail 8476 invoked from network); 11 Apr 2005 10:12:51 -0000 Received: from unknown (HELO www.lrtc.net) (217.9.240.99) by orion.erdves.lt with SMTP; 11 Apr 2005 10:12:51 -0000 Received: from donatas ([217.9.241.242]) by www.lrtc.net (Lotus Domino Release 6.0) with SMTP id 2005041113125097-16678 ; Mon, 11 Apr 2005 13:12:50 +0300 Message-ID: <001501c53e7f$02dc2e00$9f90a8c0@DONATAS> From: "dnr" To: Date: Mon, 11 Apr 2005 13:12:47 +0300 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-MIMETrack: Itemize by SMTP Server on lotus/LRTC(Release 6.0|September 26, 2002) at 04/11/2005 01:12:51 PM,04/11/2005 01:12:51 PM, Serialize complete at 04/11/2005 01:12:51 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; format=flowed; charset="iso-8859-4"; reply-type=original Subject: unable to load atm_aal.ko X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 11 Apr 2005 10:13:19 -0000 FreeBSD 5.3 i386 intel 7520 server platform hatm0: mem 0xfce00000-0xfcefffff irq 24 at device 3.0 on pci2 - 155Mbit/s ATM adapter while loading atm_llc.ko (netgraph) module an error appears: link_elf: symbol m_gethdr undefined (atm_aal.ko has been installed from pulsar_freebsd_driver.tgz) other successfuly loaded modules: Id Refs Address Size Name 1 9 0xc0400000 64ade4 kernel 2 1 0xc0a4b000 3854 ng_eiface.ko 4 1 0xc0a53000 2d88 ng_atmllc.ko 5 14 0xc0a56000 537f0 acpi.ko Kernel configuration used: _________________________________________ device hatm device utopia device atm options NATM options NETGRAPH options NETGRAPH_BRIDGE options NETGRAPH_ETHER options NETGRAPH_IFACE options NETGRAPH_IP_INPUT options NETGRAPH_SOCKET options NETGRAPH_ATM_ATMPIF options NGATM_ATM options NGATM_ATMBASE options NGATM_SSCOP options NGATM_SSCFU options NGATM_UNI options ATM_CORE options ATM_IP options ATM_SIGPVC options ATM_SPANS options ATM_UNI _______________________________________________________________________ the most strange is that this module had been working smoothly and hanged while playing with ng_vlan kernel and atm_aal.ko recompilation could not solve the problem as well as reinstallation of reebsd and even change of FORE HE adapter into the other one. any ideas welcome thank you From owner-freebsd-net@FreeBSD.ORG Mon Apr 11 11:02:16 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B0F916A4CE for ; Mon, 11 Apr 2005 11:02:16 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2183443D1F for ; Mon, 11 Apr 2005 11:02:16 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j3BB2GPs088239 for ; Mon, 11 Apr 2005 11:02:16 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j3BB2Fx6088233 for freebsd-net@freebsd.org; Mon, 11 Apr 2005 11:02:15 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 11 Apr 2005 11:02:15 GMT Message-Id: <200504111102.j3BB2Fx6088233@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 11 Apr 2005 11:02:16 -0000 Current FreeBSD problem reports Critical problems Serious problems Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/07/11] kern/54383 net [nfs] [patch] NFS root configurations wit 1 problem total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 11 12:58:09 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF40816A4CE for ; Mon, 11 Apr 2005 12:58:09 +0000 (GMT) Received: from gvr.gvr.org (gvr-gw.gvr.org [80.126.103.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 553F943D2F for ; Mon, 11 Apr 2005 12:58:09 +0000 (GMT) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id 7EF52C12C; Mon, 11 Apr 2005 14:58:08 +0200 (CEST) Date: Mon, 11 Apr 2005 14:58:08 +0200 From: Guido van Rooij To: Max Laier Message-ID: <20050411125808.GA76366@gvr.gvr.org> References: <425196F0.4020309@x-trader.de> <200504042143.09216.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200504042143.09216.max@love2party.net> cc: freebsd-net@freebsd.org Subject: Re: FreeVRRPd project status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 11 Apr 2005 12:58:09 -0000 On Mon, Apr 04, 2005 at 09:43:01PM +0200, Max Laier wrote: > > Sorry, can't help with that, but if you don't need VRRP but a working > redundancy setup, you should look at CARP which is part of 6-CURRENT and > 5-STABLE since a couple of weeks and will be part of 5.4-RELEASE. > > http://www.FreeBSD.org/cgi/man.cgi?query=carp&manpath=FreeBSD+6.0-current Just read the manpage and I have one question: the manpage does not sepcify the default advskew value, just that 100 is slightly larger. Furthermore, the advskew, pass and other ifconfig options are not (yet) documented... -Guido From owner-freebsd-net@FreeBSD.ORG Mon Apr 11 18:09:29 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E50B816A4CE for ; Mon, 11 Apr 2005 18:09:29 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9AF2D43D49 for ; Mon, 11 Apr 2005 18:09:29 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j3BI9TFa008556; Mon, 11 Apr 2005 11:09:29 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j3BI9SX8008555; Mon, 11 Apr 2005 11:09:28 -0700 Date: Mon, 11 Apr 2005 11:09:28 -0700 From: Brooks Davis To: #ZHANG CHUNLEI# Message-ID: <20050411180928.GA16756@odin.ac.hmc.edu> References: <34C4FA35021357469685D8102806A1C01EAFD7@mail01.student.main.ntu.edu.sg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline In-Reply-To: <34C4FA35021357469685D8102806A1C01EAFD7@mail01.student.main.ntu.edu.sg> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-net@freebsd.org Subject: Re: how to do kernel debug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 11 Apr 2005 18:09:30 -0000 --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 09, 2005 at 07:54:11PM +0800, #ZHANG CHUNLEI# wrote: > Dear all: > i have modifiy some part of TCP code, while after compiling and > reboot, shows me fatal 12 page fault. I want to ask nomally how to do > kernel debug ? what are the steps. See the kernel debugging section of the developers handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel= debug.html -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --6c2NcOVqGQ03X4Wi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCWr1YXY6L6fI4GtQRAnlKAKDmXU9YYCzSbp+zxVARpu6rKm6tOACggoob qfhvKVtqb0nvf5TGfOJypeE= =dPhg -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 12 04:57:55 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99C2116A4CE; Tue, 12 Apr 2005 04:57:55 +0000 (GMT) Received: from omgo.iij.ad.jp (omgo.iij.ad.jp [202.232.30.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id D649A43D31; Tue, 12 Apr 2005 04:57:54 +0000 (GMT) (envelope-from keiichi@iijlab.net) Received: OTM-MO id j3C4vdIx006280; Tue, 12 Apr 2005 13:57:40 +0900 (JST) Received: OTM-MIX0 id j3C4vd3U006603; Tue, 12 Apr 2005 13:57:39 +0900 (JST) Received: JC-SMTP from localhost (jc-ssh.iij.ad.jp [192.168.174.22]) id j3C4vcSv001850; Tue, 12 Apr 2005 13:57:39 +0900 (JST) Date: Tue, 12 Apr 2005 13:57:23 +0900 (JST) Message-Id: <20050412.135723.92413233.keiichi@iijlab.net> To: snap-users@kame.net, gnn@freebsd.org From: Keiichi SHIMA In-Reply-To: References: X-Mailer: Mew version 4.2.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: rwatson@freebsd.org cc: sam@errno.com Subject: Re: (KAME-snap 9008) Please review this diff... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 12 Apr 2005 04:57:55 -0000 Hi, From: gnn@freebsd.org Date: Sat, 09 Apr 2005 22:30:45 +0900 > I would like to check in the following diff against FreeBSD-CURRENT > and to get feedback from the Kame folks on the general usefulness of > these fixes. All changes are against icmp6.c. > > The first part of the diff removes dead code as I suspect MCLBYTES, > the size of a cluster, will never be less than 48, which is the size > of maxlen set above those lines. I checked the log when the code was added, but found no useful information. Maybe it is intended to handle a special architecture which MCLBYTES is very small. I don't know such an architecture, though... > The second part checks for error returns from the duplication of the > packets before starting to copy things around. These error checks seems correct. We will update our code too. Thank you for your pointing them out. Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME project From owner-freebsd-net@FreeBSD.ORG Tue Apr 12 07:39:53 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E88A16A4CE for ; Tue, 12 Apr 2005 07:39:53 +0000 (GMT) Received: from orion.erdves.lt (ns2.lrtc.net [217.9.240.98]) by mx1.FreeBSD.org (Postfix) with SMTP id 0933543D48 for ; Tue, 12 Apr 2005 07:39:52 +0000 (GMT) (envelope-from donatas@lrtc.net) Received: (qmail 73077 invoked from network); 12 Apr 2005 07:39:50 -0000 Received: from unknown (HELO www.lrtc.net) (217.9.240.99) by orion.erdves.lt with SMTP; 12 Apr 2005 07:39:50 -0000 Received: from donatas ([217.9.241.242]) by www.lrtc.net (Lotus Domino Release 6.0) with ESMTP id 2005041210394966-16942 ; Tue, 12 Apr 2005 10:39:49 +0300 Message-ID: <00db01c53f32$cc540420$9f90a8c0@DONATAS> From: "Donatas" To: Date: Tue, 12 Apr 2005 10:39:45 +0300 Organization: AB Lietuvos Radijo ir Televizijos Centras MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-MIMETrack: Itemize by SMTP Server on lotus/LRTC(Release 6.0|September 26, 2002) at 04/12/2005 10:39:49 AM,04/12/2005 10:39:50 AM, Serialize complete at 04/12/2005 10:39:50 AM Content-Type: text/plain; charset="iso-8859-4" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: ng_vlan and ng_atmllc goes kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Donatas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 07:39:53 -0000 is it possible to use such scheme? hatm0:----->atmllc0:---->ng_vlan0---->ngeth0 because after linking=20 "ngctl mkpeer atmllc0: vlan ether downstream(or nomatch)" kernel goes panic. might it be realated with failure to "kldload atm_aal.ko" in 5.3 = release? thank you Donatas Gendvilas SC Lithuanian Radio And Television Center Data Transfers Department - N.O.C.=20 Phone: +370 5 2040444, +370 652 37580 Sausio 13-osios st. 10, 04347 Vilnius, Lithuania =20 From owner-freebsd-net@FreeBSD.ORG Tue Apr 12 07:50:38 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7A8316A4CE for ; Tue, 12 Apr 2005 07:50:38 +0000 (GMT) Received: from orion.erdves.lt (ns2.lrtc.net [217.9.240.98]) by mx1.FreeBSD.org (Postfix) with SMTP id E8DC443D1D for ; Tue, 12 Apr 2005 07:50:36 +0000 (GMT) (envelope-from donatas@lrtc.net) Received: (qmail 77732 invoked from network); 12 Apr 2005 07:50:35 -0000 Received: from unknown (HELO www.lrtc.net) (217.9.240.99) by orion.erdves.lt with SMTP; 12 Apr 2005 07:50:35 -0000 Received: from donatas ([217.9.241.242]) by www.lrtc.net (Lotus Domino Release 6.0) with ESMTP id 2005041210503482-16946 ; Tue, 12 Apr 2005 10:50:34 +0300 Message-ID: <010e01c53f34$4d006d10$9f90a8c0@DONATAS> From: "Donatas" To: Date: Tue, 12 Apr 2005 10:50:31 +0300 Organization: AB Lietuvos Radijo ir Televizijos Centras MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-MIMETrack: Itemize by SMTP Server on lotus/LRTC(Release 6.0|September 26, 2002) at 04/12/2005 10:50:35 AM,04/12/2005 10:50:35 AM Content-Type: multipart/mixed; boundary="----=_NextPart_000_010A_01C53F4D.72311C60" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: unable to load atm_aal.ko (Corrected) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Donatas List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2005 07:50:38 -0000 ------=_NextPart_000_010A_01C53F4D.72311C60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-4" sorry for an error(wrote atm_llc.ko) so once again, atm_aal.c and atm_aal.h files cannot be compiled under FreeBSD5.3 and on 5.2 machine compiled atm_aal.ko cannot be loaded: kldload atm_aal.ko=20 link_elf: symbol m_gethdr undefined can someone help to solve this problem? thank you Donatas Gendvilas SC Lithuanian Radio And Television Center Data Transfers Department - N.O.C.=20 Phone: +370 5 2040444, +370 652 37580 Sausio 13-osios st. 10, 04347 Vilnius, Lithuania ------=_NextPart_000_010A_01C53F4D.72311C60 Content-Type: application/octet-stream; name=".depend" Content-Disposition: attachment; filename=".depend" Content-Transfer-Encoding: base64 IyAtbm9zdGRpbmMgLURfS0VSTkVMIC1ES0xEX01PRFVMRSAtSS0gLUkuIC1JQCAtSUAvZGV2IC1J QC8uLi9pbmNsdWRlIC1JL3Vzci9pbmNsdWRlIGF0bV9hYWwuYyBhdG1fYWFsNS5jCmF0bV9hYWwu bzogYXRtX2FhbC5jIEAvc3lzL3BhcmFtLmggQC9zeXMvdHlwZXMuaCBAL3N5cy9jZGVmcy5oIFwK ICBtYWNoaW5lL2VuZGlhbi5oIEAvc3lzL190eXBlcy5oIG1hY2hpbmUvX3R5cGVzLmggQC9zeXMv c2VsZWN0LmggXAogIEAvc3lzL19zaWdzZXQuaCBAL3N5cy9fdGltZXZhbC5oIEAvc3lzL3RpbWVz cGVjLmggQC9zeXMvc3lzbGltaXRzLmggXAogIEAvc3lzL2Vycm5vLmggQC9zeXMvdGltZS5oIEAv c3lzL3ByaW9yaXR5LmggbWFjaGluZS9wYXJhbS5oIFwKICBAL3N5cy9zeXN0bS5oIG1hY2hpbmUv YXRvbWljLmggbWFjaGluZS9jcHVmdW5jLmggbWFjaGluZS9wc2wuaCBcCiAgQC9zeXMvY2FsbG91 dC5oIEAvc3lzL3F1ZXVlLmggQC9zeXMvc3RkaW50LmggbWFjaGluZS9fc3RkaW50LmggXAogIEAv c3lzL2xpYmtlcm4uaCBAL3N5cy9tYnVmLmggQC9zeXMvbWFsbG9jLmggQC9zeXMvX2xvY2suaCBc CiAgQC9zeXMvX211dGV4LmggQC9zeXMva2VybmVsLmggQC9zeXMvbGlua2VyX3NldC5oIEAvc3lz L21vZHVsZS5oIFwKICBAL3N5cy9sb2NrLmggQC9zeXMvbXV0ZXguaCBAL3N5cy9wY3B1LmggQC9z eXMvdm1tZXRlci5oIG1hY2hpbmUvcGNwdS5oIFwKICBtYWNoaW5lL3NlZ21lbnRzLmggbWFjaGlu ZS90c3MuaCBtYWNoaW5lL211dGV4LmggQC9zeXMvc29ja2V0LmggXAogIEAvc3lzL19pb3ZlYy5o IEAvbmV0L2lmLmggQC9uZXQvaWZfdmFyLmggQC9zeXMvX2xhYmVsLmggQC9zeXMvZXZlbnQuaCBc CiAgQC9uZXQvaWZfbWVkaWEuaCBAL25ldC9pZl9hdG0uaCBhdG1fYWFsLmgKYXRtX2FhbDUubzog YXRtX2FhbDUuYyBAL3N5cy9wYXJhbS5oIEAvc3lzL3R5cGVzLmggQC9zeXMvY2RlZnMuaCBcCiAg bWFjaGluZS9lbmRpYW4uaCBAL3N5cy9fdHlwZXMuaCBtYWNoaW5lL190eXBlcy5oIEAvc3lzL3Nl bGVjdC5oIFwKICBAL3N5cy9fc2lnc2V0LmggQC9zeXMvX3RpbWV2YWwuaCBAL3N5cy90aW1lc3Bl Yy5oIEAvc3lzL3N5c2xpbWl0cy5oIFwKICBAL3N5cy9lcnJuby5oIEAvc3lzL3RpbWUuaCBAL3N5 cy9wcmlvcml0eS5oIG1hY2hpbmUvcGFyYW0uaCBcCiAgQC9zeXMvc3lzdG0uaCBtYWNoaW5lL2F0 b21pYy5oIG1hY2hpbmUvY3B1ZnVuYy5oIG1hY2hpbmUvcHNsLmggXAogIEAvc3lzL2NhbGxvdXQu aCBAL3N5cy9xdWV1ZS5oIEAvc3lzL3N0ZGludC5oIG1hY2hpbmUvX3N0ZGludC5oIFwKICBAL3N5 cy9saWJrZXJuLmggQC9zeXMvbWJ1Zi5oIEAvc3lzL21hbGxvYy5oIEAvc3lzL19sb2NrLmggXAog IEAvc3lzL19tdXRleC5oIEAvc3lzL2tlcm5lbC5oIEAvc3lzL2xpbmtlcl9zZXQuaCBAL3N5cy9t b2R1bGUuaCBcCiAgQC9zeXMvbG9jay5oIEAvc3lzL211dGV4LmggQC9zeXMvcGNwdS5oIEAvc3lz L3ZtbWV0ZXIuaCBtYWNoaW5lL3BjcHUuaCBcCiAgbWFjaGluZS9zZWdtZW50cy5oIG1hY2hpbmUv dHNzLmggbWFjaGluZS9tdXRleC5oIEAvc3lzL3NvY2tldC5oIFwKICBAL3N5cy9faW92ZWMuaCBA L25ldC9pZi5oIEAvbmV0L2lmX3Zhci5oIEAvc3lzL19sYWJlbC5oIEAvc3lzL2V2ZW50LmggXAog IEAvbmV0L2lmX21lZGlhLmggQC9uZXQvaWZfYXRtLmggYXRtX2FhbC5oCg== ------=_NextPart_000_010A_01C53F4D.72311C60 Content-Type: application/octet-stream; name="atm_aal5.c" Content-Disposition: attachment; filename="atm_aal5.c" Content-Transfer-Encoding: base64 LyoKICogQ29weXJpZ2h0IChjKSAyMDAzLCBCZW5ubyBSaWNlIDxiZW5ub0BlbG9xdWVudC5jb20u YXU+CiAqIEFsbCBSaWdodHMgUmVzZXJ2ZWQuCiAqCiAqIERldmVsb3BtZW50IHNwb25zb3JlZCBi eSBUcmF2ZXJzZSBUZWNobm9sb2dpZXMsIGh0dHA6Ly93d3cudHJhdmVyc2UuY29tLmF1LwogKgog KiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRo IG9yIHdpdGhvdXQKICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQg dGhlIGZvbGxvd2luZyBjb25kaXRpb25zCiAqIGFyZSBtZXQ6CiAqIDEuIFJlZGlzdHJpYnV0aW9u cyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CiAqICAgIG5v dGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1l ci4KICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRo ZSBhYm92ZSBjb3B5cmlnaHQKICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBh bmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQogKiAgICBkb2N1bWVudGF0aW9uIGFu ZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgogKgog KiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgIGBgQVMgSVMnJyBBTkQK ICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1Qg TElNSVRFRCBUTywgVEhFCiAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkg QU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCiAqIEFSRSBESVNDTEFJTUVELiAg SU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhPUiAgQkUgTElBQkxFCiAqIEZPUiBBTlkgRElSRUNU LCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5U SUFMCiAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVO VCBPRiBTVUJTVElUVVRFIEdPT0RTCiAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwg T1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQogKiBIT1dFVkVSIENBVVNFRCBB TkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklD VAogKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lT RSkgQVJJU0lORyBJTiBBTlkgV0FZCiAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUs IEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKICogU1VDSCBEQU1BR0UuCiAq CiAqICRFbG9xdWVudDogcHJvamVjdHMvYXRtX2FhbC9hdG1fYWFsNS5jLHYgMS45IDIwMDMvMTIv MDEgMjM6NTY6MTggYmVubm8gRXhwICQKICovCgojaW5jbHVkZSA8c3lzL3BhcmFtLmg+CiNpbmNs dWRlIDxzeXMvc3lzdG0uaD4KI2luY2x1ZGUgPHN5cy9tYnVmLmg+CiNpbmNsdWRlIDxzeXMvbWFs bG9jLmg+CiNpbmNsdWRlIDxzeXMva2VybmVsLmg+CiNpbmNsdWRlIDxzeXMvbG9jay5oPgojaW5j bHVkZSA8c3lzL211dGV4Lmg+CiNpbmNsdWRlIDxzeXMvc29ja2V0Lmg+CgojaW5jbHVkZSA8bmV0 L2lmLmg+CiNpbmNsdWRlIDxuZXQvaWZfbWVkaWEuaD4KI2luY2x1ZGUgPG5ldC9pZl9hdG0uaD4K CiNpbmNsdWRlICJhdG1fYWFsLmgiCgojZGVmaW5lIEFUTV9BQUw1X0VPTShjZWxsKQkoY2VsbFsz XSAmIDB4MikKCnN0cnVjdCBhdG1fYWFsNV90cmFpbGVyIHsKCXVpbnQ4X3QJCWNwY3NfdXU7Cgl1 aW50OF90CQljcGk7Cgl1aW50MTZfdAlsZW5ndGg7Cgl1aW50MzJfdAljcmM7Cn07CgpzdGF0aWMg dWludDMyX3QgY3JjMzJ0YWJsZVtdID0gewoJMHgwMDAwMDAwMCwgMHgwNGMxMWRiNywgMHgwOTgy M2I2ZSwgMHgwZDQzMjZkOSwKCTB4MTMwNDc2ZGMsIDB4MTdjNTZiNmIsIDB4MWE4NjRkYjIsIDB4 MWU0NzUwMDUsIAoJMHgyNjA4ZWRiOCwgMHgyMmM5ZjAwZiwgMHgyZjhhZDZkNiwgMHgyYjRiY2I2 MSwKCTB4MzUwYzliNjQsIDB4MzFjZDg2ZDMsIDB4M2M4ZWEwMGEsIDB4Mzg0ZmJkYmQsIAoJMHg0 YzExZGI3MCwgMHg0OGQwYzZjNywgMHg0NTkzZTAxZSwgMHg0MTUyZmRhOSwKCTB4NWYxNWFkYWMs IDB4NWJkNGIwMWIsIDB4NTY5Nzk2YzIsIDB4NTI1NjhiNzUsIAoJMHg2YTE5MzZjOCwgMHg2ZWQ4 MmI3ZiwgMHg2MzliMGRhNiwgMHg2NzVhMTAxMSwKCTB4NzkxZDQwMTQsIDB4N2RkYzVkYTMsIDB4 NzA5ZjdiN2EsIDB4NzQ1ZTY2Y2QsIAoJMHg5ODIzYjZlMCwgMHg5Y2UyYWI1NywgMHg5MWExOGQ4 ZSwgMHg5NTYwOTAzOSwKCTB4OGIyN2MwM2MsIDB4OGZlNmRkOGIsIDB4ODJhNWZiNTIsIDB4ODY2 NGU2ZTUsIAoJMHhiZTJiNWI1OCwgMHhiYWVhNDZlZiwgMHhiN2E5NjAzNiwgMHhiMzY4N2Q4MSwK CTB4YWQyZjJkODQsIDB4YTllZTMwMzMsIDB4YTRhZDE2ZWEsIDB4YTA2YzBiNWQsIAoJMHhkNDMy NmQ5MCwgMHhkMGYzNzAyNywgMHhkZGIwNTZmZSwgMHhkOTcxNGI0OSwKCTB4YzczNjFiNGMsIDB4 YzNmNzA2ZmIsIDB4Y2ViNDIwMjIsIDB4Y2E3NTNkOTUsIAoJMHhmMjNhODAyOCwgMHhmNmZiOWQ5 ZiwgMHhmYmI4YmI0NiwgMHhmZjc5YTZmMSwKCTB4ZTEzZWY2ZjQsIDB4ZTVmZmViNDMsIDB4ZThi Y2NkOWEsIDB4ZWM3ZGQwMmQsIAoJMHgzNDg2NzA3NywgMHgzMDQ3NmRjMCwgMHgzZDA0NGIxOSwg MHgzOWM1NTZhZSwKCTB4Mjc4MjA2YWIsIDB4MjM0MzFiMWMsIDB4MmUwMDNkYzUsIDB4MmFjMTIw NzIsIAoJMHgxMjhlOWRjZiwgMHgxNjRmODA3OCwgMHgxYjBjYTZhMSwgMHgxZmNkYmIxNiwKCTB4 MDE4YWViMTMsIDB4MDU0YmY2YTQsIDB4MDgwOGQwN2QsIDB4MGNjOWNkY2EsIAoJMHg3ODk3YWIw NywgMHg3YzU2YjZiMCwgMHg3MTE1OTA2OSwgMHg3NWQ0OGRkZSwKCTB4NmI5M2RkZGIsIDB4NmY1 MmMwNmMsIDB4NjIxMWU2YjUsIDB4NjZkMGZiMDIsIAoJMHg1ZTlmNDZiZiwgMHg1YTVlNWIwOCwg MHg1NzFkN2RkMSwgMHg1M2RjNjA2NiwKCTB4NGQ5YjMwNjMsIDB4NDk1YTJkZDQsIDB4NDQxOTBi MGQsIDB4NDBkODE2YmEsIAoJMHhhY2E1YzY5NywgMHhhODY0ZGIyMCwgMHhhNTI3ZmRmOSwgMHhh MWU2ZTA0ZSwKCTB4YmZhMWIwNGIsIDB4YmI2MGFkZmMsIDB4YjYyMzhiMjUsIDB4YjJlMjk2OTIs IAoJMHg4YWFkMmIyZiwgMHg4ZTZjMzY5OCwgMHg4MzJmMTA0MSwgMHg4N2VlMGRmNiwKCTB4OTlh OTVkZjMsIDB4OWQ2ODQwNDQsIDB4OTAyYjY2OWQsIDB4OTRlYTdiMmEsIAoJMHhlMGI0MWRlNywg MHhlNDc1MDA1MCwgMHhlOTM2MjY4OSwgMHhlZGY3M2IzZSwKCTB4ZjNiMDZiM2IsIDB4Zjc3MTc2 OGMsIDB4ZmEzMjUwNTUsIDB4ZmVmMzRkZTIsIAoJMHhjNmJjZjA1ZiwgMHhjMjdkZWRlOCwgMHhj ZjNlY2IzMSwgMHhjYmZmZDY4NiwKCTB4ZDViODg2ODMsIDB4ZDE3OTliMzQsIDB4ZGMzYWJkZWQs IDB4ZDhmYmEwNWEsIAoJMHg2OTBjZTBlZSwgMHg2ZGNkZmQ1OSwgMHg2MDhlZGI4MCwgMHg2NDRm YzYzNywKCTB4N2EwODk2MzIsIDB4N2VjOThiODUsIDB4NzM4YWFkNWMsIDB4Nzc0YmIwZWIsIAoJ MHg0ZjA0MGQ1NiwgMHg0YmM1MTBlMSwgMHg0Njg2MzYzOCwgMHg0MjQ3MmI4ZiwKCTB4NWMwMDdi OGEsIDB4NThjMTY2M2QsIDB4NTU4MjQwZTQsIDB4NTE0MzVkNTMsIAoJMHgyNTFkM2I5ZSwgMHgy MWRjMjYyOSwgMHgyYzlmMDBmMCwgMHgyODVlMWQ0NywKCTB4MzYxOTRkNDIsIDB4MzJkODUwZjUs IDB4M2Y5Yjc2MmMsIDB4M2I1YTZiOWIsIAoJMHgwMzE1ZDYyNiwgMHgwN2Q0Y2I5MSwgMHgwYTk3 ZWQ0OCwgMHgwZTU2ZjBmZiwKCTB4MTAxMWEwZmEsIDB4MTRkMGJkNGQsIDB4MTk5MzliOTQsIDB4 MWQ1Mjg2MjMsIAoJMHhmMTJmNTYwZSwgMHhmNWVlNGJiOSwgMHhmOGFkNmQ2MCwgMHhmYzZjNzBk NywKCTB4ZTIyYjIwZDIsIDB4ZTZlYTNkNjUsIDB4ZWJhOTFiYmMsIDB4ZWY2ODA2MGIsIAoJMHhk NzI3YmJiNiwgMHhkM2U2YTYwMSwgMHhkZWE1ODBkOCwgMHhkYTY0OWQ2ZiwKCTB4YzQyM2NkNmEs IDB4YzBlMmQwZGQsIDB4Y2RhMWY2MDQsIDB4Yzk2MGViYjMsIAoJMHhiZDNlOGQ3ZSwgMHhiOWZm OTBjOSwgMHhiNGJjYjYxMCwgMHhiMDdkYWJhNywKCTB4YWUzYWZiYTIsIDB4YWFmYmU2MTUsIDB4 YTdiOGMwY2MsIDB4YTM3OWRkN2IsIAoJMHg5YjM2NjBjNiwgMHg5ZmY3N2Q3MSwgMHg5MmI0NWJh OCwgMHg5Njc1NDYxZiwKCTB4ODgzMjE2MWEsIDB4OGNmMzBiYWQsIDB4ODFiMDJkNzQsIDB4ODU3 MTMwYzMsIAoJMHg1ZDhhOTA5OSwgMHg1OTRiOGQyZSwgMHg1NDA4YWJmNywgMHg1MGM5YjY0MCwK CTB4NGU4ZWU2NDUsIDB4NGE0ZmZiZjIsIDB4NDcwY2RkMmIsIDB4NDNjZGMwOWMsIAoJMHg3Yjgy N2QyMSwgMHg3ZjQzNjA5NiwgMHg3MjAwNDY0ZiwgMHg3NmMxNWJmOCwKCTB4Njg4NjBiZmQsIDB4 NmM0NzE2NGEsIDB4NjEwNDMwOTMsIDB4NjVjNTJkMjQsIAoJMHgxMTliNGJlOSwgMHgxNTVhNTY1 ZSwgMHgxODE5NzA4NywgMHgxY2Q4NmQzMCwKCTB4MDI5ZjNkMzUsIDB4MDY1ZTIwODIsIDB4MGIx ZDA2NWIsIDB4MGZkYzFiZWMsIAoJMHgzNzkzYTY1MSwgMHgzMzUyYmJlNiwgMHgzZTExOWQzZiwg MHgzYWQwODA4OCwKCTB4MjQ5N2QwOGQsIDB4MjA1NmNkM2EsIDB4MmQxNWViZTMsIDB4MjlkNGY2 NTQsIAoJMHhjNWE5MjY3OSwgMHhjMTY4M2JjZSwgMHhjYzJiMWQxNywgMHhjOGVhMDBhMCwKCTB4 ZDZhZDUwYTUsIDB4ZDI2YzRkMTIsIDB4ZGYyZjZiY2IsIDB4ZGJlZTc2N2MsIAoJMHhlM2ExY2Jj MSwgMHhlNzYwZDY3NiwgMHhlYTIzZjBhZiwgMHhlZWUyZWQxOCwKCTB4ZjBhNWJkMWQsIDB4ZjQ2 NGEwYWEsIDB4ZjkyNzg2NzMsIDB4ZmRlNjliYzQsIAoJMHg4OWI4ZmQwOSwgMHg4ZDc5ZTBiZSwg MHg4MDNhYzY2NywgMHg4NGZiZGJkMCwKCTB4OWFiYzhiZDUsIDB4OWU3ZDk2NjIsIDB4OTMzZWIw YmIsIDB4OTdmZmFkMGMsIAoJMHhhZmIwMTBiMSwgMHhhYjcxMGQwNiwgMHhhNjMyMmJkZiwgMHhh MmYzMzY2OCwKCTB4YmNiNDY2NmQsIDB4Yjg3NTdiZGEsIDB4YjUzNjVkMDMsIDB4YjFmNzQwYjQs IAp9OwoKc3RhdGljIHVpbnQzMl90CWF0bV9hYWw1X2NyYyhzdHJ1Y3QgbWJ1ZiAqLCBpbnQpOwoK c3RydWN0IG1idWYgKgphdG1fYWFsNV9kZWNvZGUoc3RydWN0IGF0bV9hYWwgKmFhbCwgc3RydWN0 IGF0bV9hYWxfdmNjICp2Y2MsIHVpbnQ4X3QgKmNlbGwpCnsKCXVpbnQ4X3QJKmRhdGE7Cgl1X2lu dAlwZHVfbGVuZ3RoOwoJc3RydWN0CWF0bV9hYWw1X3RyYWlsZXIgdHJhaWxlcjsKCXN0cnVjdAlt YnVmICptOwoKCWlmICh2Y2MtPnZjY19tID09IE5VTEwpIHsKCQlNR0VUSERSKHZjYy0+dmNjX20s IE1fRE9OVFdBSVQsIE1UX0RBVEEpOwoJCWlmICh2Y2MtPnZjY19tID09IE5VTEwpIHsKCQkJcHJp bnRmKCJhdG1fYWFsNV9kZWNvZGU6IE1HRVRIRFIgZmFpbGVkXG4iKTsKCQkJcmV0dXJuIChOVUxM KTsKCQl9CgkJdmNjLT52Y2NfbS0+bV9sZW4gPSAwOwoJCXZjYy0+dmNjX20tPm1fcGt0aGRyLmxl biA9IDA7Cgl9CgoJZGF0YSA9IGNlbGwgKyAoYWFsLT5hYWxfZmxhZ3MgJiBBVE1fQUFMX0hFQURF Ul80QllURSA/IDQgOiA1KTsKCgltX2NvcHliYWNrKHZjYy0+dmNjX20sIHZjYy0+dmNjX2xlbmd0 aCwgNDgsIGRhdGEpOwoJdmNjLT52Y2NfbGVuZ3RoICs9IDQ4OwoKCWlmIChBVE1fQUFMNV9FT00o Y2VsbCkpIHsKCQl0cmFpbGVyLmNwY3NfdXUgPSBkYXRhWzQwXTsKCQl0cmFpbGVyLmNwaSA9IGRh dGFbNDFdOwoJCXRyYWlsZXIubGVuZ3RoID0gKChkYXRhWzQyXSAmIDB4ZmYpIDw8IDgpICsgKGRh dGFbNDNdICYgMHhmZik7CgkJdHJhaWxlci5jcmMgPSAoZGF0YVs0NF0gPDwgMjQpICsgKGRhdGFb NDVdIDw8IDE2KSArCgkJICAgIChkYXRhWzQ2XSA8PCA4KSArIGRhdGFbNDddOwoKCQlpZiAodmNj LT52Y2NfbGVuZ3RoIDwgdHJhaWxlci5sZW5ndGgpIHsKCQkJLyogV2UndmUgbG9zdCBzb21lIGRh dGEuICovCgkJCXByaW50ZigiYXRtX2FhbDVfZGVjb2RlOiBQRFUgdG9vIHNtYWxsXG4iKTsKCQkJ bV9mcmVlbSh2Y2MtPnZjY19tKTsKCQkJbSA9IE5VTEw7CgkJCWdvdG8gcmVzZXQ7CgkJfQoKCQlw ZHVfbGVuZ3RoID0gKCh0cmFpbGVyLmxlbmd0aCArIDggKyA0NykgLyA0OCkgKiA0ODsKCgkJaWYg KHZjYy0+dmNjX2xlbmd0aCA+IHBkdV9sZW5ndGgpIHsKCQkJLyoKCQkJICogV2UndmUgZ290IHRv byBtdWNoIGRhdGEuCgkJCSAqIFRyeSB0cmltbWluZyBvdXQgdGhlIHN0YXJ0IG9uIHRoZSBhc3N1 bXB0aW9uIHRoYXQKCQkJICogdGhlcmUncyBiZWVuIGEgbG9zdCBFT00gY2VsbC4KCQkJICovCgkJ CXByaW50ZigiYXRtX2FhbDVfZGVjb2RlOiBQRFUgdG9vIGxhcmdlXG4iKTsKCQkJbV9hZGoodmNj LT52Y2NfbSwgdmNjLT52Y2NfbGVuZ3RoIC0gcGR1X2xlbmd0aCk7CgkJCXZjYy0+dmNjX2xlbmd0 aCA9IHBkdV9sZW5ndGg7CgkJfQoKCQkvKiBDYWxjdWxhdGUgYW5kIGNoZWNrIENSQy4gKi8KCQlp ZiAoYXRtX2FhbDVfY3JjKHZjYy0+dmNjX20sIHBkdV9sZW5ndGggLSA0KSAhPSB0cmFpbGVyLmNy YykgewoJCQlwcmludGYoImF0bV9hYWw1X2RlY29kZTogQ1JDIG1pc21hdGNoXG4iKTsKCQkJbV9m cmVlbSh2Y2MtPnZjY19tKTsKCQkJbSA9IE5VTEw7CgkJCWdvdG8gcmVzZXQ7CgkJfQoKCQkvKiBE aXNjYXJkIHRoZSB0cmFpbGVyIGFuZCB0aGUgcGFkZGluZy4gKi8KCQltX2Fkaih2Y2MtPnZjY19t LCB0cmFpbGVyLmxlbmd0aCAtIHZjYy0+dmNjX2xlbmd0aCk7CgoJCW0gPSB2Y2MtPnZjY19tOwoJ CW0tPm1fcGt0aGRyLmxlbiA9IHRyYWlsZXIubGVuZ3RoOwoKcmVzZXQ6CgkJTUdFVEhEUih2Y2Mt PnZjY19tLCBNX0RPTlRXQUlULCBNVF9EQVRBKTsKCQlpZiAodmNjLT52Y2NfbSA9PSBOVUxMKSB7 CgkJCXByaW50ZigiYXRtX2FhbDVfZGVjb2RlOiBNR0VUSERSIGZhaWxlZFxuIik7CgkJfSBlbHNl IHsKCQkJdmNjLT52Y2NfbS0+bV9sZW4gPSAwOwoJCQl2Y2MtPnZjY19tLT5tX3BrdGhkci5sZW4g PSAwOwoJCX0KCgkJdmNjLT52Y2NfbGVuZ3RoID0gMDsKCgkJcmV0dXJuIChtKTsKCX0KCglyZXR1 cm4gKE5VTEwpOwp9CgpzdHJ1Y3QgbWJ1ZiAqCmF0bV9hYWw1X2VuY29kZShzdHJ1Y3QgYXRtX2Fh bCAqYWFsLCBzdHJ1Y3QgYXRtX2FhbF92Y2MgKnZjYywgc3RydWN0IG1idWYgKm0wKQp7Cgl1aW50 MTZfdAlwYXlsb2FkX2xlbmd0aDsKCWludAkJcGR1X2xlbmd0aCwgcGFkX2xlbmd0aDsKCXVpbnQz Ml90CWNyYzsKCXVpbnQ4X3QJCWJ1ZmZlcls1M10sICp0cmFpbGVyOwoKCWlmIChtMC0+bV9wa3Ro ZHIubGVuID4gNjU1MzUpIHsKCQlyZXR1cm4gKE5VTEwpOwoJfQoKCXBheWxvYWRfbGVuZ3RoID0g bTAtPm1fcGt0aGRyLmxlbiAmIDB4ZmZmZjsKCXBkdV9sZW5ndGggPSAoKHBheWxvYWRfbGVuZ3Ro ICsgOCArIDQ3KSAvIDQ4KSAqIDQ4OwoJcGFkX2xlbmd0aCA9IHBkdV9sZW5ndGggLSBwYXlsb2Fk X2xlbmd0aCAtIDg7CgliemVybyhidWZmZXIsIHBhZF9sZW5ndGggKyA4KTsKCgkvKiBXZSBsZWF2 ZSB0aGUgQ1BDUy1VVSBhbmQgQ1BJIGJpdHMgYXMgemVybyBmb3Igbm93LiAqLwoJdHJhaWxlciA9 ICZidWZmZXJbcGFkX2xlbmd0aF07Cgl0cmFpbGVyWzJdID0gKHBheWxvYWRfbGVuZ3RoID4+IDgp ICYgMHhmZjsKCXRyYWlsZXJbM10gPSBwYXlsb2FkX2xlbmd0aCAmIDB4ZmY7CgltX2NvcHliYWNr KG0wLCBwYXlsb2FkX2xlbmd0aCwgcGFkX2xlbmd0aCArIDQsIGJ1ZmZlcik7CgoJY3JjID0gYXRt X2FhbDVfY3JjKG0wLCBwZHVfbGVuZ3RoIC0gNCk7CgoJYnVmZmVyWzBdID0gKGNyYyA+PiAyNCkg JiAweGZmOwoJYnVmZmVyWzFdID0gKGNyYyA+PiAxNikgJiAweGZmOwoJYnVmZmVyWzJdID0gKGNy YyA+PiA4KSAmIDB4ZmY7CglidWZmZXJbM10gPSBjcmMgJiAweGZmOwoJbV9jb3B5YmFjayhtMCwg cGR1X2xlbmd0aCAtIDQsIDQsIGJ1ZmZlcik7CgoJcmV0dXJuIChhdG1fYWFsX3NlZ21lbnQodmNj LCBtMCkpOwp9CgpzdGF0aWMgdWludDMyX3QKYXRtX2FhbDVfY3JjKHN0cnVjdCBtYnVmICptMCwg aW50IGxlbmd0aCkKewoJdWludDMyX3QJY3JjOwoJc3RydWN0CQltYnVmICptOwoJdWludDhfdAkJ KmRhdGE7CglpbnQJCWxlbiwgdG90YWw7CgoJY3JjID0gMHhmZmZmZmZmZjsKCXRvdGFsID0gMDsK Cglmb3IgKG0gPSBtMDsgbSAhPSBOVUxMOyBtID0gbS0+bV9uZXh0KSB7CgkJZm9yIChsZW4gPSBt LT5tX2xlbiwgZGF0YSA9IG0tPm1fZGF0YTsgbGVuID4gMDsgbGVuLS0sIGRhdGErKykgewoJCQlj cmMgPSBjcmMzMnRhYmxlWygoY3JjID4+IDI0KSBeICpkYXRhKSAmIDB4ZmZdIF4KCQkJICAgIChj cmMgPDwgOCk7CgkJCXRvdGFsKys7CgkJCWlmICh0b3RhbCA+PSBsZW5ndGgpCgkJCQlicmVhazsK CQl9CgoJCWlmICh0b3RhbCA+PSBsZW5ndGgpCgkJCWJyZWFrOwoJfQoKCXJldHVybiAofmNyYyk7 Cn0K ------=_NextPart_000_010A_01C53F4D.72311C60 Content-Type: application/octet-stream; name="atm_aal.c" Content-Disposition: attachment; filename="atm_aal.c" Content-Transfer-Encoding: base64 LyoKICogQ29weXJpZ2h0IChjKSAyMDAzLCBCZW5ubyBSaWNlIDxiZW5ub0BlbG9xdWVudC5jb20u YXU+CiAqIEFsbCBSaWdodHMgUmVzZXJ2ZWQuCiAqCiAqIERldmVsb3BtZW50IHNwb25zb3JlZCBi eSBUcmF2ZXJzZSBUZWNobm9sb2dpZXMsIGh0dHA6Ly93d3cudHJhdmVyc2UuY29tLmF1LwogKgog KiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRo IG9yIHdpdGhvdXQKICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQg dGhlIGZvbGxvd2luZyBjb25kaXRpb25zCiAqIGFyZSBtZXQ6CiAqIDEuIFJlZGlzdHJpYnV0aW9u cyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CiAqICAgIG5v dGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1l ci4KICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRo ZSBhYm92ZSBjb3B5cmlnaHQKICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBh bmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQogKiAgICBkb2N1bWVudGF0aW9uIGFu ZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgogKgog KiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgIGBgQVMgSVMnJyBBTkQK ICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1Qg TElNSVRFRCBUTywgVEhFCiAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkg QU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCiAqIEFSRSBESVNDTEFJTUVELiAg SU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhPUiAgQkUgTElBQkxFCiAqIEZPUiBBTlkgRElSRUNU LCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5U SUFMCiAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVO VCBPRiBTVUJTVElUVVRFIEdPT0RTCiAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwg T1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQogKiBIT1dFVkVSIENBVVNFRCBB TkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklD VAogKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lT RSkgQVJJU0lORyBJTiBBTlkgV0FZCiAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUs IEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKICogU1VDSCBEQU1BR0UuCiAq CiAqICRFbG9xdWVudDogcHJvamVjdHMvYXRtX2FhbC9hdG1fYWFsLmMsdiAxLjIwIDIwMDMvMTIv MDEgMjM6NTY6MTggYmVubm8gRXhwICQKICovCgojaW5jbHVkZSA8c3lzL3BhcmFtLmg+CiNpbmNs dWRlIDxzeXMvc3lzdG0uaD4KI2luY2x1ZGUgPHN5cy9tYnVmLmg+CiNpbmNsdWRlIDxzeXMvbWFs bG9jLmg+CiNpbmNsdWRlIDxzeXMva2VybmVsLmg+CiNpbmNsdWRlIDxzeXMvbG9jay5oPgojaW5j bHVkZSA8c3lzL211dGV4Lmg+CiNpbmNsdWRlIDxzeXMvc29ja2V0Lmg+CiNpbmNsdWRlIDxzeXMv cXVldWUuaD4KCiNpbmNsdWRlIDxuZXQvaWYuaD4KI2luY2x1ZGUgPG5ldC9pZl9tZWRpYS5oPgoj aW5jbHVkZSA8bmV0L2lmX2F0bS5oPgoKI2luY2x1ZGUgImF0bV9hYWwuaCIKCk1BTExPQ19ERUZJ TkUoTV9BVE1fQUFMLCAiYXRtX2FhbCIsICJEYXRhIGZvciBBVE0gQUFMIG9wZXJhdGlvbnMiKTsK CiNkZWZpbmUJQVRNX0FBTF9HRVRfVlBJKGNlbGwpCVwKICAgICgoKGNlbGxbMF0gJiAweGYpIDw8 IDQpICsgKGNlbGxbMV0gPj4gNCkpCiNkZWZpbmUJQVRNX0FBTF9HRVRfVkNJKGNlbGwpCVwKICAg ICgoKGNlbGxbMV0gJiAweGYpIDw8IDEyKSArIChjZWxsWzJdIDw8IDQpICsgKGNlbGxbM10gPj4g NCkpCgpzdGF0aWMgdm9pZAlhdG1fYWFsX3ZjY19mcmVlKHN0cnVjdCBhdG1fYWFsX3ZjYyAqKTsK c3RhdGljIGludAlhdG1fYWFsX21vZGV2ZW50KG1vZHVsZV90LCBpbnQsIHZvaWQgKik7CgpzdHJ1 Y3QgYXRtX2FhbCAqCmF0bV9hYWxfY3JlYXRlKHN0cnVjdCBpZm5ldCAqaWZuZXQsIHVfaW50IGZs YWdzLCBhdG1fYWFsX2NhbGxiYWNrX3QgY2FsbGJhY2ssCiAgICB2b2lkICphcmcpCnsKCXN0cnVj dAlhdG1fYWFsICphYWw7CgoJTUFMTE9DKGFhbCwgc3RydWN0IGF0bV9hYWwgKiwgc2l6ZW9mKHN0 cnVjdCBhdG1fYWFsKSwKCSAgICBNX0FUTV9BQUwsIE1fV0FJVE9LIHwgTV9aRVJPKTsKCWlmIChh YWwgPT0gTlVMTCkgewoJCXByaW50ZigiYXRtX2FhbF9jcmVhdGU6IG1hbGxvYyBmYWlsZWRcbiIp OwoJCXJldHVybiAoTlVMTCk7Cgl9CgoJU0xJU1RfSU5JVCgmYWFsLT5hYWxfdmNjcyk7CglhYWwt PmFhbF9udmNjcyA9IDA7CgltdHhfaW5pdCgmYWFsLT5hYWxfbXR4LCAiQVRNIEFBTCIsIE5VTEws IE1UWF9ERUYpOwoJYWFsLT5hYWxfZmxhZ3MgPSBmbGFnczsKCWFhbC0+YWFsX2NhbGxiYWNrID0g Y2FsbGJhY2s7CglhYWwtPmFhbF9hcmcgPSBhcmc7CgoJcmV0dXJuIChhYWwpOwp9Cgp2b2lkCmF0 bV9hYWxfZGVzdHJveShzdHJ1Y3QgYXRtX2FhbCAqYWFsKQp7CgoJYXRtX2FhbF92Y2NfY2xvc2Vh bGwoYWFsKTsKCgltdHhfbG9jaygmYWFsLT5hYWxfbXR4KTsKCW10eF9kZXN0cm95KCZhYWwtPmFh bF9tdHgpOwoJRlJFRShhYWwsIE1fQVRNX0FBTCk7Cn0KCmludAphdG1fYWFsX3ZjY19vcGVuKHN0 cnVjdCBhdG1fYWFsICphYWwsIHVfaW50IHZwaSwgdV9pbnQgdmNpLCB1X2ludCBhYWx0eXBlLAog ICAgdV9pbnQgZmxhZ3MsIHZvaWQgKmFyZykKewoJc3RydWN0CWF0bV9hYWxfdmNjICp2Y2MsICp2 Y2MxOwoKCWlmICgoZmxhZ3MgJiBBVE1JT19GTEFHX05PVFgpICYmCgkgICAgKGZsYWdzICYgQVRN SU9fRkxBR19OT1JYKSkgewoJCXJldHVybiAoRUlOVkFMKTsKCX0KCglzd2l0Y2ggKGFhbHR5cGUp IHsKCWNhc2UgQVRNSU9fQUFMX1JBVzoKCWNhc2UgQVRNSU9fQUFMXzU6CgkJYnJlYWs7CglkZWZh dWx0OgoJCXJldHVybiAoRUlOVkFMKTsKCX0KCglNQUxMT0ModmNjLCBzdHJ1Y3QgYXRtX2FhbF92 Y2MgKiwgc2l6ZW9mKHN0cnVjdCBhdG1fYWFsX3ZjYyksCgkgICAgTV9BVE1fQUFMLCBNX1dBSVRP SyB8IE1fWkVSTyk7CglpZiAodmNjID09IE5VTEwpIHsKCQlwcmludGYoImF0bV9hYWxfdmNjX29w ZW46IG1hbGxvYyBmYWlsZWRcbiIpOwoJCXJldHVybiAoRU5PTUVNKTsKCX0KCglNR0VUSERSKHZj Yy0+dmNjX20sIE1fVFJZV0FJVCwgTVRfREFUQSk7CglpZiAodmNjLT52Y2NfbSA9PSBOVUxMKSB7 CgkJcHJpbnRmKCJhdG1fYWFsX3ZjY19vcGVuOiBNR0VUSERSIGZhaWxlZFxuIik7CgkJRlJFRSh2 Y2MsIE1fQVRNX0FBTCk7CgkJcmV0dXJuIChFTk9NRU0pOwoJfQoJdmNjLT52Y2NfbS0+bV9sZW4g PSAwOwoJdmNjLT52Y2NfbS0+bV9wa3RoZHIubGVuID0gMDsKCgl2Y2MtPnZjY192cGkgPSB2cGk7 Cgl2Y2MtPnZjY192Y2kgPSB2Y2k7Cgl2Y2MtPnZjY19hYWwgPSBhYWx0eXBlOwoJdmNjLT52Y2Nf ZmxhZ3MgPSBmbGFnczsKCXZjYy0+dmNjX2xlbmd0aCA9IDA7Cgl2Y2MtPnZjY19hcmcgPSBhcmc7 CgoJbXR4X2xvY2soJmFhbC0+YWFsX210eCk7CgoJU0xJU1RfRk9SRUFDSCh2Y2MxLCAmYWFsLT5h YWxfdmNjcywgdmNjX25leHQpIHsKCQlpZiAodmNjMS0+dmNjX3ZwaSA9PSB2cGkgJiYgdmNjMS0+ dmNjX3ZjaSA9PSB2Y2kpIHsKCQkJbV9mcmVlbSh2Y2MtPnZjY19tKTsKCQkJZnJlZSh2Y2MsIE1f QVRNX0FBTCk7CgkJCXJldHVybiAoRUJVU1kpOwoJCX0KCX0KCgoJU0xJU1RfSU5TRVJUX0hFQUQo JmFhbC0+YWFsX3ZjY3MsIHZjYywgdmNjX25leHQpOwoJYWFsLT5hYWxfbnZjY3MrKzsKCgltdHhf dW5sb2NrKCZhYWwtPmFhbF9tdHgpOwoKCXJldHVybiAoMCk7Cn0KCnZvaWQKYXRtX2FhbF92Y2Nf Y2xvc2Uoc3RydWN0IGF0bV9hYWwgKmFhbCwgdV9pbnQgdnBpLCB1X2ludCB2Y2kpCnsKCXN0cnVj dAlhdG1fYWFsX3ZjYyAqdmNjOwoKCW10eF9sb2NrKCZhYWwtPmFhbF9tdHgpOwoKCVNMSVNUX0ZP UkVBQ0godmNjLCAmYWFsLT5hYWxfdmNjcywgdmNjX25leHQpIHsKCQlpZiAodmNjLT52Y2NfdnBp ID09IHZwaSAmJiB2Y2MtPnZjY192Y2kgPT0gdmNpKSB7CgkJCVNMSVNUX1JFTU9WRSgmYWFsLT5h YWxfdmNjcywgdmNjLCBhdG1fYWFsX3ZjYywKCQkJICAgIHZjY19uZXh0KTsKCQkJYXRtX2FhbF92 Y2NfZnJlZSh2Y2MpOwoJCQlhYWwtPmFhbF9udmNjcy0tOwoJCQltdHhfdW5sb2NrKCZhYWwtPmFh bF9tdHgpOwoJCQlyZXR1cm47CgkJfQoJfQoKCW10eF91bmxvY2soJmFhbC0+YWFsX210eCk7Cn0K CnZvaWQKYXRtX2FhbF92Y2NfY2xvc2VhbGwoc3RydWN0IGF0bV9hYWwgKmFhbCkKewoJc3RydWN0 CWF0bV9hYWxfdmNjICp2Y2M7CgoJbXR4X2xvY2soJmFhbC0+YWFsX210eCk7CgoJd2hpbGUgKCFT TElTVF9FTVBUWSgmYWFsLT5hYWxfdmNjcykpIHsKCQl2Y2MgPSBTTElTVF9GSVJTVCgmYWFsLT5h YWxfdmNjcyk7CgkJU0xJU1RfUkVNT1ZFX0hFQUQoJmFhbC0+YWFsX3ZjY3MsIHZjY19uZXh0KTsK CQlhdG1fYWFsX3ZjY19mcmVlKHZjYyk7Cgl9CgoJYWFsLT5hYWxfbnZjY3MgPSAwOwoKCW10eF91 bmxvY2soJmFhbC0+YWFsX210eCk7Cn0KCnZvaWQKYXRtX2FhbF9wcm9jZXNzX2luKHN0cnVjdCBh dG1fYWFsICphYWwsIHVpbnQ4X3QgKmNlbGxzLCB1X2ludCBuY2VsbHMpCnsKCXN0cnVjdAlhdG1f YWFsX3ZjYyAqdmNjOwoJdV9pbnQJdnBpLCB2Y2k7Cgl1aW50OF90CSpjZWxsOwoJaW50CWk7Cglz dHJ1Y3QJbWJ1ZiAqbTsKCgl2Y2MgPSBOVUxMOwoKCW10eF9sb2NrKCZhYWwtPmFhbF9tdHgpOwoJ Zm9yIChpID0gMDsgaSA8IG5jZWxsczsgaSsrKSB7CgkJaWYgKGFhbC0+YWFsX2ZsYWdzICYgQVRN X0FBTF9IRUFERVJfNEJZVEUpIHsKCQkJY2VsbCA9ICZjZWxsc1tpICogNTJdOwoJCX0gZWxzZSB7 CgkJCWNlbGwgPSAmY2VsbHNbaSAqIDUzXTsKCQl9CgoJCXZwaSA9IEFUTV9BQUxfR0VUX1ZQSShj ZWxsKTsKCQl2Y2kgPSBBVE1fQUFMX0dFVF9WQ0koY2VsbCk7CgoJCWlmICh2Y2MgPT0gTlVMTCB8 fCB2Y2MtPnZjY192cGkgIT0gdnBpIHx8IHZjYy0+dmNjX3ZjaSAhPSB2Y2kpIHsKCQkJU0xJU1Rf Rk9SRUFDSCh2Y2MsICZhYWwtPmFhbF92Y2NzLCB2Y2NfbmV4dCkgewoJCQkJaWYgKHZjYy0+dmNj X3ZwaSA9PSB2cGkgJiYKCQkJCSAgICB2Y2MtPnZjY192Y2kgPT0gdmNpKSB7CgkJCQkJYnJlYWs7 CgkJCQl9CgkJCX0KCgkJCWlmICh2Y2MgPT0gTlVMTCkKCQkJCWNvbnRpbnVlOwoJCX0KCgkJaWYg KHZjYy0+dmNjX2ZsYWdzICYgQVRNSU9fRkxBR19OT1JYKSB7CgkJCWNvbnRpbnVlOwoJCX0KCgkJ bSA9IE5VTEw7CgoJCXN3aXRjaCAodmNjLT52Y2NfYWFsKSB7CgkJY2FzZSBBVE1JT19BQUxfMDoK CQljYXNlIEFUTUlPX0FBTF8zNDoKCQkJYnJlYWs7CS8qIFVOU1VQUE9SVEVEICovCgoJCWNhc2Ug QVRNSU9fQUFMXzU6CgkJCW0gPSBhdG1fYWFsNV9kZWNvZGUoYWFsLCB2Y2MsIGNlbGwpOwoJCQli cmVhazsKCgkJY2FzZSBBVE1JT19BQUxfUkFXOgoJCQltID0gYXRtX2FhbHJhd19kZWNvZGUoYWFs LCB2Y2MsIGNlbGwpOwoJCQlicmVhazsKCQl9CgoJCWlmIChtICE9IE5VTEwpIHsKCQkJbXR4X3Vu bG9jaygmYWFsLT5hYWxfbXR4KTsKCQkJYWFsLT5hYWxfY2FsbGJhY2soYWFsLCB2Y2MsIG0pOwoJ CQl2Y2MgPSBOVUxMOwoJCQltdHhfbG9jaygmYWFsLT5hYWxfbXR4KTsKCQl9Cgl9CgltdHhfdW5s b2NrKCZhYWwtPmFhbF9tdHgpOwp9CgpzdHJ1Y3QgbWJ1ZiAqCmF0bV9hYWxfcHJvY2Vzc19vdXQo c3RydWN0IGF0bV9hYWwgKmFhbCwgc3RydWN0IG1idWYgKm0pCnsKCXN0cnVjdAlhdG1fcHNldWRv aGRyICphcGg7Cgl1X2ludAl2cGksIHZjaTsKCXN0cnVjdAlhdG1fYWFsX3ZjYyAqdmNjOwoKCWlm IChtLT5tX3BrdGhkci5sZW4gPCBzaXplb2Yoc3RydWN0IGF0bV9wc2V1ZG9oZHIpKSB7CgkJcHJp bnRmKCJhdG1fYWFsX3Byb2Nlc3Nfb3V0OiBjaGFpbiB0b28gc21hbGwgKCVkKVxuIiwKCQkgICAg bS0+bV9wa3RoZHIubGVuKTsKCQltX2ZyZWVtKG0pOwoJCXJldHVybiAoTlVMTCk7Cgl9CgoJaWYg KG0tPm1fbGVuIDwgc2l6ZW9mKHN0cnVjdCBhdG1fcHNldWRvaGRyKSAmJgoJICAgIChtID0gbV9w dWxsdXAobSwgc2l6ZW9mKHN0cnVjdCBhdG1fcHNldWRvaGRyKSkpID09IE5VTEwpIHsKCQlwcmlu dGYoImF0bV9hYWxfcHJvY2Vzc19vdXQ6IG1fcHVsbHVwIGZhaWxlZFxuIik7CgkJcmV0dXJuIChO VUxMKTsKCX0KCglhcGggPSBtdG9kKG0sIHN0cnVjdCBhdG1fcHNldWRvaGRyICopOwoKCXZwaSA9 IEFUTV9QSF9WUEkoYXBoKTsKCXZjaSA9IEFUTV9QSF9WQ0koYXBoKTsKCgltX2FkaihtLCBzaXpl b2Yoc3RydWN0IGF0bV9wc2V1ZG9oZHIpKTsKCglpZiAobS0+bV9wa3RoZHIubGVuID09IDApIHsK CQlwcmludGYoImF0bV9hYWxfcHJvY2Vzc19vdXQ6IG5vIGRhdGFcbiIpOwoJCW1fZnJlZW0obSk7 CgkJcmV0dXJuIChOVUxMKTsKCX0KCgltdHhfbG9jaygmYWFsLT5hYWxfbXR4KTsKCglTTElTVF9G T1JFQUNIKHZjYywgJmFhbC0+YWFsX3ZjY3MsIHZjY19uZXh0KSB7CgkJaWYgKHZjYy0+dmNjX3Zw aSA9PSB2cGkgJiYgdmNjLT52Y2NfdmNpID09IHZjaSkgewoJCQlicmVhazsKCQl9Cgl9CgoJaWYg KHZjYyA9PSBOVUxMKSB7CgkJcHJpbnRmKCJhdG1fYWFsX3Byb2Nlc3Nfb3V0OiBubyB2Y2MgZm9y ICVkLyVkXG4iLCB2cGksIHZjaSk7CgkJbXR4X3VubG9jaygmYWFsLT5hYWxfbXR4KTsKCQltX2Zy ZWVtKG0pOwoJCXJldHVybiAoTlVMTCk7Cgl9CgoJc3dpdGNoICh2Y2MtPnZjY19hYWwpIHsKCWNh c2UgQVRNSU9fQUFMXzA6CgkJbSA9IGF0bV9hYWxfc2VnbWVudCh2Y2MsIG0pOwoJCWJyZWFrOwoK CWNhc2UgQVRNSU9fQUFMXzM0OgoJCWJyZWFrOwkvKiBVTlNVUFBPUlRFRCAqLwoKCWNhc2UgQVRN SU9fQUFMXzU6CgkJbSA9IGF0bV9hYWw1X2VuY29kZShhYWwsIHZjYywgbSk7CgkJYnJlYWs7Cgl9 CgoJbXR4X3VubG9jaygmYWFsLT5hYWxfbXR4KTsKCglyZXR1cm4gKG0pOwp9CgovKgogKiBBbGxv Y2F0ZSBhbiBtYnVmIGNoYWluIHRoYXQgaG9sZHMgdGhlIGdpdmVuIGFtb3VudCBvZiBkYXRhIGZp bGxlZAogKiB3aXRoIHdoYXQganVuayB3ZSBnb3QgZnJvbSB0aGUgYWxsb2NhdGlvbiByb3V0aW5l cy4KICovCnN0YXRpYyBzdHJ1Y3QgbWJ1ZiAqCmF0bV9hYWxfbWdldG0oc3RydWN0IG1idWYgKm0w LCB1X2ludCBsZW4pCnsKCXN0cnVjdCBtYnVmICptLCAqdG1wOwoKCWlmIChsZW4gPD0gTUhMRU4p IHsKCQlNR0VUSERSKG0sIE1fRE9OVFdBSVQsIE1UX0RBVEEpOwoJCWlmIChtID09IE5VTEwpICB7 CgkJCXByaW50ZigiYXRtX2FhbF9zZWdtZW50OiBNR0VUSERSIGZhaWxlZFxuIik7CgkJCXJldHVy biAoTlVMTCk7CgkJfQoJCWlmIChtX2R1cF9wa3RoZHIobSwgbTAsIE1fRE9OVFdBSVQpID09IDAp IHsKCQkJcHJpbnRmKCJhdG1fYWFsX3NlZ21lbnQ6IG1fZHVwX3BrdGhkciBmYWlsZWQ/XG4iKTsK CQkJbV9mcmVlbShtKTsKCQkJcmV0dXJuIChOVUxMKTsKCQl9CgkJbS0+bV9sZW4gPSBtLT5tX3Br dGhkci5sZW4gPSBsZW47CgkJcmV0dXJuIChtKTsKCX0KCW0gPSBtX2dldGNsKE1fRE9OVFdBSVQs IE1UX0RBVEEsIE1fUEtUSERSKTsKCWlmIChtID09IE5VTEwpIHsKCQlwcmludGYoImF0bV9hYWxf c2VnbWVudDogTUdFVEhEUiBmYWlsZWRcbiIpOwoJCXJldHVybiAoTlVMTCk7Cgl9CglpZiAobV9k dXBfcGt0aGRyKG0sIG0wLCBNX0RPTlRXQUlUKSA9PSAwKSB7CgkJcHJpbnRmKCJhdG1fYWFsX3Nl Z21lbnQ6IG1fZHVwX3BrdGhkciBmYWlsZWQ/XG4iKTsKCQltX2ZyZWVtKG0pOwoJCXJldHVybiAo TlVMTCk7Cgl9CglpZiAobGVuIDw9IE1DTEJZVEVTKSB7CgkJbS0+bV9sZW4gPSBtLT5tX3BrdGhk ci5sZW4gPSBsZW47CgkJcmV0dXJuIChtKTsKCX0KCW0tPm1fbGVuID0gTUNMQllURVM7CgltLT5t X3BrdGhkci5sZW4gPSBsZW47CglsZW4gLT0gTUNMQllURVM7Cgl0bXAgPSBtX2dldG0obSwgbGVu LCBNX0RPTlRXQUlULCBNVF9EQVRBKTsKCWlmICh0bXAgPT0gTlVMTCkgewoJCXByaW50ZigiYXRt X2FhbF9zZWdtZW50OiBhbGxvY2F0aW5nIGNoYWluIGZhaWxlZFxuIik7CgkJbV9mcmVlbShtKTsK CQlyZXR1cm4gKE5VTEwpOwoJfQoJLyogZml4dXAgbGVuZ3RocyAqLwoJd2hpbGUgKGxlbiA+IDAp IHsKCQlpZiAodG1wLT5tX2ZsYWdzICYgTV9FWFQpCgkJCXRtcC0+bV9sZW4gPSBtaW4obGVuLCBN Q0xCWVRFUyk7CgkJZWxzZQoJCQl0bXAtPm1fbGVuID0gbWluKGxlbiwgTUxFTik7CgkJbGVuIC09 IHRtcC0+bV9sZW47CgkJdG1wID0gdG1wLT5tX25leHQ7Cgl9CglyZXR1cm4gKG0pOwp9CgpzdHJ1 Y3QgbWJ1ZiAqCmF0bV9hYWxfc2VnbWVudChzdHJ1Y3QgYXRtX2FhbF92Y2MgKnZjYywgc3RydWN0 IG1idWYgKm0wKQp7CglpbnQJCXBkdV9jZWxscywgcGR1X2xlbmd0aCwgaTsKCXVpbnQ4X3QJCWJ1 ZmZlcls1M107CglzdHJ1Y3QJCW1idWYgKm07CgoJcGR1X2xlbmd0aCA9IG0wLT5tX3BrdGhkci5s ZW47CglwZHVfY2VsbHMgPSBwZHVfbGVuZ3RoIC8gNDg7CgoJbSA9IGF0bV9hYWxfbWdldG0obTAs IHBkdV9jZWxscyAqIDUyKTsKCWlmIChtID09IE5VTEwpCgkJcmV0dXJuIChOVUxMKTsKCglidWZm ZXJbMF0gPSAodmNjLT52Y2NfdnBpID4+IDQpICYgMHhmOwoJYnVmZmVyWzFdID0gKCh2Y2MtPnZj Y192cGkgPDwgNCkgJiAweGYwKSArCgkgICAgKCh2Y2MtPnZjY192Y2kgPj4gMTIpICYgMHhmKTsK CWJ1ZmZlclsyXSA9ICh2Y2MtPnZjY192Y2kgPj4gNCkgJiAweGZmOwoJYnVmZmVyWzNdID0gKHZj Yy0+dmNjX3ZjaSA8PCA0KSAmIDB4ZjA7CgkvKiBYWFg6IEhFQyAqLwoKCWZvciAoaSA9IDA7IGkg PCBwZHVfY2VsbHM7IGkrKykgewojaWZkZWYgREVCVUcKCQlwcmludGYoImF0bV9hYWxfc2VnbWVu dDogYmVmb3JlOiBtMCA9ICVkIG0gPSAlZFxuIiwgbV9sZW5ndGgobTAsIE5VTEwpLCBtX2xlbmd0 aChtLCBOVUxMKSk7CiNlbmRpZgoJCW1fY29weWRhdGEobTAsIGkgKiA0OCwgNDgsICZidWZmZXJb NF0pOwoKCQlpZiAoaSA9PSBwZHVfY2VsbHMgLSAxKSB7CgkJCS8qIFhYWDogQWxsIHRoZSB3b3Js ZCBpcyBBQUw1PyAqLwoJCQlidWZmZXJbM10gfD0gMHgyOwoJCQkvKiBYWFg6IEhFQyAqLwoJCX0K CgkJLyogWFhYIHNob3VsZCBvcHRpbWl6ZSBhbmQgbm90IHVzZSBtX2NvcHliYWNrICovCgkJbV9j b3B5YmFjayhtLCBpICogNTIsIDUyLCBidWZmZXIpOwojaWZkZWYgREVCVUcKCQlwcmludGYoImF0 bV9hYWxfc2VnbWVudDogYWZ0ZXI6IG0wID0gJWQgbSA9ICVkXG4iLCBtX2xlbmd0aChtMCwgTlVM TCksIG1fbGVuZ3RoKG0sIE5VTEwpKTsKI2VuZGlmCgl9CgoJbV9mcmVlbShtMCk7CglyZXR1cm4g KG0pOwp9Cgp2b2lkCmF0bV9hYWxfaW5wdXQoc3RydWN0IGF0bV9hYWwgKmFhbCwgc3RydWN0IGF0 bV9hYWxfdmNjICp2Y2MsIHN0cnVjdCBtYnVmICptKQp7CglzdHJ1Y3QJaWZuZXQgKmlmcDsKCXN0 cnVjdAlhdG1fcHNldWRvaGRyIGFwaDsKCglpZnAgPSAoc3RydWN0IGlmbmV0ICopYWFsLT5hYWxf YXJnOwoKCW0tPm1fcGt0aGRyLnJjdmlmID0gaWZwOwoKCUFUTV9QSF9GTEFHUygmYXBoKSA9IHZj Yy0+dmNjX2ZsYWdzOwoJQVRNX1BIX1ZQSSgmYXBoKSA9IHZjYy0+dmNjX3ZwaTsKCUFUTV9QSF9T RVRWQ0koJmFwaCwgdmNjLT52Y2NfdmNpKTsKCglpZnAtPmlmX2lwYWNrZXRzKys7CgoJYXRtX2lu cHV0KGlmcCwgJmFwaCwgbSwgdmNjLT52Y2NfYXJnKTsKfQoKc3RhdGljIHZvaWQKYXRtX2FhbF92 Y2NfZnJlZShzdHJ1Y3QgYXRtX2FhbF92Y2MgKnZjYykgewoJbV9mcmVlbSh2Y2MtPnZjY19tKTsK CUZSRUUodmNjLCBNX0FUTV9BQUwpOwp9CgpzdGF0aWMgaW50CmF0bV9hYWxfbW9kZXZlbnQobW9k dWxlX3QgbW9kLCBpbnQgdHlwZSwgdm9pZCAqdW51c2VkKQp7CgoJc3dpdGNoICh0eXBlKSB7Cglj YXNlIE1PRF9MT0FEOgoJCWlmIChib290dmVyYm9zZSkKCQkJcHJpbnRmKCJhdG1fYWFsOiA8U29m dHdhcmUgQVRNIEFkYXB0YXRpb24gTGF5ZXI+XG4iKTsKCQlyZXR1cm4gKDApOwoJCWJyZWFrOwoK CWNhc2UgTU9EX1VOTE9BRDoKCQlyZXR1cm4gKDApOwoJCWJyZWFrOwoJfQoKCXJldHVybiAoRUlO VkFMKTsKfQoKc3RhdGljIG1vZHVsZWRhdGFfdCBhdG1fYWFsX21vZCA9IHsKCSJhdG1fYWFsIiwK CWF0bV9hYWxfbW9kZXZlbnQsCgkwCn07CgpERUNMQVJFX01PRFVMRShhdG1fYWFsLCBhdG1fYWFs X21vZCwgU0lfU1VCX0RSSVZFUlMsIFNJX09SREVSX0ZJUlNUKTsKTU9EVUxFX1ZFUlNJT04oYXRt X2FhbCwgMSk7Ck1PRFVMRV9ERVBFTkQoYXRtX2FhbCwgYXRtLCAxLCAxLCAxKTsKCi8qCiAqIFJB VyBBQUwgLSBqdXN0IHByb2R1Y2Ugb25lIG1idWYgcGVyIGNlbGwKICovCnN0cnVjdCBtYnVmICoK YXRtX2FhbHJhd19kZWNvZGUoc3RydWN0IGF0bV9hYWwgKmFhbCwgc3RydWN0IGF0bV9hYWxfdmNj ICp2Y2MsIHVpbnQ4X3QgKmNlbGwpCnsKCXN0cnVjdCBtYnVmICptOwoKCWlmICh2Y2MtPnZjY19t ID09IE5VTEwpIHsKCQlNR0VUSERSKHZjYy0+dmNjX20sIE1fRE9OVFdBSVQsIE1UX0RBVEEpOwoJ CWlmICh2Y2MtPnZjY19tID09IE5VTEwpIHsKCQkJcHJpbnRmKCJhdG1fYWFsNV9kZWNvZGU6IE1H RVRIRFIgZmFpbGVkXG4iKTsKCQkJcmV0dXJuIChOVUxMKTsKCQl9CgkJdmNjLT52Y2NfbS0+bV9s ZW4gPSAwOwoJCXZjYy0+dmNjX20tPm1fcGt0aGRyLmxlbiA9IDA7Cgl9CgoJdmNjLT52Y2NfbS0+ bV9sZW4gPSA1MjsKCXZjYy0+dmNjX20tPm1fcGt0aGRyLmxlbiA9IDUyOwoKCWlmIChhYWwtPmFh bF9mbGFncyAmIEFUTV9BQUxfSEVBREVSXzRCWVRFKQoJCWJjb3B5KGNlbGwsIHZjYy0+dmNjX20t Pm1fZGF0YSwgNTIpOwoJZWxzZSB7CgkJYmNvcHkoY2VsbCwgdmNjLT52Y2NfbS0+bV9kYXRhLCA0 KTsKCQliY29weShjZWxsICsgNSwgdmNjLT52Y2NfbS0+bV9kYXRhICsgNCwgNDgpOwoJfQoKCW0g PSB2Y2MtPnZjY19tOwoJdmNjLT52Y2NfbSA9IE5VTEw7CgoJcmV0dXJuIChtKTsKfQoKLyoKICog UmV0dXJuIGp1c3QgYSBjb3B5IGJ1dCBiZSBzdXJlIHRvIHRydW5jYXRlIHRvIGEgbXVsdGlwbGUg b2YgNTIgYnl0ZQogKi8Kc3RydWN0IG1idWYgKgphdG1fYWFscmF3X2VuY29kZShzdHJ1Y3QgYXRt X2FhbCAqYWFsLCBzdHJ1Y3QgYXRtX2FhbF92Y2MgKnZjYywgc3RydWN0IG1idWYgKm0wKQp7Cglz dHJ1Y3QgbWJ1ZiAqbTsKCXVfaW50IHBkdV9jZWxsczsKCglwZHVfY2VsbHMgPSBtMC0+bV9wa3Ro ZHIubGVuIC8gNTI7CgoJaWYgKG0wLT5tX3BrdGhkci5sZW4gJSA1MiA9PSAwKQoJCW0gPSBtX2Nv cHlwYWNrZXQobTAsIE1fRE9OVFdBSVQpOwoJZWxzZSB7CgkJbSA9IG1fZHVwKG0wLCBNX0RPTlRX QUlUKTsKCQlpZiAobSAhPSBOVUxMKQoJCQltX2FkaihtLCAtKG0wLT5tX3BrdGhkci5sZW4gJSA1 MikpOwoJfQoJcmV0dXJuIChtKTsKfQo= ------=_NextPart_000_010A_01C53F4D.72311C60 Content-Type: application/octet-stream; name="atm_aal.h" Content-Disposition: attachment; filename="atm_aal.h" Content-Transfer-Encoding: base64 LyoKICogQ29weXJpZ2h0IChjKSAyMDAzLCBCZW5ubyBSaWNlIDxiZW5ub0BlbG9xdWVudC5jb20u YXU+CiAqIEFsbCBSaWdodHMgUmVzZXJ2ZWQuCiAqCiAqIERldmVsb3BtZW50IHNwb25zb3JlZCBi eSBUcmF2ZXJzZSBUZWNobm9sb2dpZXMsIGh0dHA6Ly93d3cudHJhdmVyc2UuY29tLmF1LwogKgog KiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRo IG9yIHdpdGhvdXQKICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQg dGhlIGZvbGxvd2luZyBjb25kaXRpb25zCiAqIGFyZSBtZXQ6CiAqIDEuIFJlZGlzdHJpYnV0aW9u cyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CiAqICAgIG5v dGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1l ci4KICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRo ZSBhYm92ZSBjb3B5cmlnaHQKICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBh bmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQogKiAgICBkb2N1bWVudGF0aW9uIGFu ZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgogKgog KiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgIGBgQVMgSVMnJyBBTkQK ICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1Qg TElNSVRFRCBUTywgVEhFCiAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkg QU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCiAqIEFSRSBESVNDTEFJTUVELiAg SU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhPUiAgQkUgTElBQkxFCiAqIEZPUiBBTlkgRElSRUNU LCBJTkRJUkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5U SUFMCiAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVO VCBPRiBTVUJTVElUVVRFIEdPT0RTCiAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwg T1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQogKiBIT1dFVkVSIENBVVNFRCBB TkQgT04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklD VAogKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lT RSkgQVJJU0lORyBJTiBBTlkgV0FZCiAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUs IEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKICogU1VDSCBEQU1BR0UuCiAq CiAqICRFbG9xdWVudDogcHJvamVjdHMvYXRtX2FhbC9hdG1fYWFsLmgsdiAxLjExIDIwMDMvMTIv MDEgMjM6NTY6MTggYmVubm8gRXhwICQKICovCgojaWZuZGVmIF9BVE1fQUFMX0hfCiNkZWZpbmUg X0FUTV9BQUxfSF8KCiNpbmNsdWRlIDxzeXMvcXVldWUuaD4KCk1BTExPQ19ERUNMQVJFKE1fQVRN X0FBTCk7CgpTTElTVF9IRUFEKGF0bV9hYWxfdmNjX2xpc3QsIGF0bV9hYWxfdmNjKTsKCnN0cnVj dCBhdG1fYWFsOwpzdHJ1Y3QgYXRtX2FhbF92Y2M7Cgp0eXBlZGVmIHZvaWQgYXRtX2FhbF9jYWxs YmFja190KHN0cnVjdCBhdG1fYWFsICosIHN0cnVjdCBhdG1fYWFsX3ZjYyAqLAogICAgc3RydWN0 IG1idWYgKik7CgpzdHJ1Y3QgYXRtX2FhbCB7CglpbnQJYWFsX252Y2NzOwkJLyogSG93IG1hbnkg VkNDcyB3ZSBoYXZlLiAqLwoJc3RydWN0CWF0bV9hYWxfdmNjX2xpc3QgYWFsX3ZjY3M7IC8qIExp c3Qgb2YgVkNDcy4gKi8KCXN0cnVjdAltdHggYWFsX210eDsJCS8qIE11dGV4LiAqLwoJdV9pbnQJ YWFsX2ZsYWdzOwkJLyogRmxhZ3MuICovCglhdG1fYWFsX2NhbGxiYWNrX3QgKmFhbF9jYWxsYmFj azsgLyogQ2FsbGJhY2sgZm9yIHdoZW4gd2UgaGF2ZSBkYXRhLiAqLwoJdm9pZAkqYWFsX2FyZzsJ CS8qIENhbGxiYWNrIGFyZ3VtZW50LiAqLwp9OwoKc3RydWN0IGF0bV9hYWxfdmNjIHsKCXVfaW50 CXZjY192cGk7CQkvKiBWaXJ0dWFsIFBhdGggSWRlbnRpZmllciAqLwoJdV9pbnQJdmNjX3ZjaTsJ CS8qIFZpcnR1YWwgQ2hhbm5lbCBJZGVudGlmaWVyICovCgl1X2ludAl2Y2NfYWFsOwkJLyogQVRN IEFkYXB0YXRpb24gTGF5ZXIgKi8KCXVfaW50CXZjY19mbGFnczsJCS8qIEZsYWdzICovCglzdHJ1 Y3QJbWJ1ZiAqdmNjX207CQkvKiBPdXIgY3VycmVudCBtYnVmLiAqLwoJdV9pbnQJdmNjX2xlbmd0 aDsJCS8qIEhvdyBtdWNoIGRhdGEgd2UncmUgaG9sZGluZy4gKi8KCXZvaWQJKnZjY19hcmc7CQkv KiBDYWxsYmFjayBhcmd1bWVudC4gKi8KCVNMSVNUX0VOVFJZKGF0bV9hYWxfdmNjKSB2Y2NfbmV4 dDsKfTsKCi8qIEZsYWcgZGVmaW5pdGlvbnMuICovCiNkZWZpbmUJQVRNX0FBTF9IRUFERVJfNEJZ VEUJMHgwMDAwMDAwMQkvKiBIRUMgaXMgZG9uZSBlbHNld2hlcmUuICovCgovKiBBQUwgY29udGV4 dCBtYW5hZ2VtZW50LiAqLwpzdHJ1Y3QgYXRtX2FhbCAqCWF0bV9hYWxfY3JlYXRlKHN0cnVjdCBp Zm5ldCAqLCB1X2ludCwKCQkJICAgIGF0bV9hYWxfY2FsbGJhY2tfdCwgdm9pZCAqKTsKdm9pZAkJ CWF0bV9hYWxfZGVzdHJveShzdHJ1Y3QgYXRtX2FhbCAqKTsKCi8qIEFBTCBWQ0MgbWFuYWdlbWVu dC4gKi8KaW50CQkJYXRtX2FhbF92Y2Nfb3BlbihzdHJ1Y3QgYXRtX2FhbCAqLCB1X2ludCwgdV9p bnQsIHVfaW50LAoJCQkgICAgdV9pbnQsIHZvaWQgKik7CnZvaWQJCQlhdG1fYWFsX3ZjY19jbG9z ZShzdHJ1Y3QgYXRtX2FhbCAqLCB1X2ludCwgdV9pbnQpOwp2b2lkCQkJYXRtX2FhbF92Y2NfY2xv c2VhbGwoc3RydWN0IGF0bV9hYWwgKik7CgovKiBFbnRyeSBwb2ludHMgZm9yIGluLSBhbmQgb3V0 Ym91bmQgcHJvY2Vzc2luZy4gKi8Kdm9pZAkJCWF0bV9hYWxfcHJvY2Vzc19pbihzdHJ1Y3QgYXRt X2FhbCAqLCB1aW50OF90ICosIHVfaW50KTsKc3RydWN0IG1idWYgKgkJYXRtX2FhbF9wcm9jZXNz X291dChzdHJ1Y3QgYXRtX2FhbCAqLCBzdHJ1Y3QgbWJ1ZiAqKTsKCi8qIENvbnZlbmllbmNlIGZ1 bmN0aW9uIGZvciBBQUxzLiAgSGFuZGxlcyBzZWdtZW50YXRpb24gYW5kIGhlYWRlciBhZGRpdGlv bi4gKi8Kc3RydWN0IG1idWYgKgkJYXRtX2FhbF9zZWdtZW50KHN0cnVjdCBhdG1fYWFsX3ZjYyAq LCBzdHJ1Y3QgbWJ1ZiAqKTsKCi8qIENvbnZlbmllbmNlIGZ1bmN0aW9uIHRvIGFjdCBhcyBhIGNh bGxiYWNrIHRvIGhhbmQgbWJ1ZnMgdG8gdGhlIEFUTSBsYXllci4gKi8Kdm9pZAkJCWF0bV9hYWxf aW5wdXQoc3RydWN0IGF0bV9hYWwgKiwgc3RydWN0IGF0bV9hYWxfdmNjICosCgkJCSAgICBzdHJ1 Y3QgbWJ1ZiAqKTsKCi8qIEZ1bmN0aW9uIGZvciByZXR1cm5pbmcgdGhlIHZjYyB0YWJsZS4gKi8K c3RydWN0IGF0bWlvX3ZjY3RhYmxlICoJYXRtX2FhbF9nZXR2Y2NzKHN0cnVjdCBhdG1fYWFsICos IGludCk7CgovKiBBQUw1IHJvdXRpbmVzLiAqLwpzdHJ1Y3QgbWJ1ZiAqCQlhdG1fYWFsNV9kZWNv ZGUoc3RydWN0IGF0bV9hYWwgKiwgc3RydWN0IGF0bV9hYWxfdmNjICosCgkJCSAgICB1aW50OF90 ICopOwpzdHJ1Y3QgbWJ1ZiAqCQlhdG1fYWFsNV9lbmNvZGUoc3RydWN0IGF0bV9hYWwgKiwgc3Ry dWN0IGF0bV9hYWxfdmNjICosCgkJCSAgICBzdHJ1Y3QgbWJ1ZiAqKTsKCi8qIFJBVyBBQUwgcm91 dGluZXMuICovCnN0cnVjdCBtYnVmICoJCWF0bV9hYWxyYXdfZGVjb2RlKHN0cnVjdCBhdG1fYWFs ICosCgkJCSAgICBzdHJ1Y3QgYXRtX2FhbF92Y2MgKiwgdWludDhfdCAqKTsKc3RydWN0IG1idWYg KgkJYXRtX2FhbHJhd19lbmNvZGUoc3RydWN0IGF0bV9hYWwgKiwKCQkJICAgIHN0cnVjdCBhdG1f YWFsX3ZjYyAqLCBzdHJ1Y3QgbWJ1ZiAqKTsKCiNlbmRpZgo= ------=_NextPart_000_010A_01C53F4D.72311C60 Content-Type: application/octet-stream; name="Makefile" Content-Disposition: attachment; filename="Makefile" Content-Transfer-Encoding: base64 IyAkRWxvcXVlbnQ6IHByb2plY3RzL2F0bV9hYWwvTWFrZWZpbGUsdiAxLjEgMjAwMy8wOS8yMCAx MjowMDo1MCBiZW5ubyBFeHAgJAoKS01PRD0JYXRtX2FhbApTUkNTPQlhdG1fYWFsLmMgYXRtX2Fh bDUuYwoKLmluY2x1ZGUgPGJzZC5rbW9kLm1rPgo= ------=_NextPart_000_010A_01C53F4D.72311C60-- From owner-freebsd-net@FreeBSD.ORG Tue Apr 12 11:08:22 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D927D16A4CE for ; Tue, 12 Apr 2005 11:08:22 +0000 (GMT) Received: from t1.perm.mtsnet.ru (ns.perm.mtsnet.ru [213.87.42.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DE1443D5C for ; Tue, 12 Apr 2005 11:08:21 +0000 (GMT) (envelope-from sergey@vavilov.org) Received: from [10.100.9.154] (vavy-ntbk.perm.mtsnet.ru [213.87.42.30]) by t1.perm.mtsnet.ru (8.13.3/8.13.3) with ESMTP id j3CB8JAa027420 for ; Tue, 12 Apr 2005 17:08:19 +0600 (YEKST) Message-ID: <425BAC1E.6090001@vavilov.org> Date: Tue, 12 Apr 2005 17:08:14 +0600 From: Sergey Vavilov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/822/Tue Apr 12 10:55:55 2005 on t1 X-Virus-Status: Clean Subject: natd, DNAT of UDP traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 12 Apr 2005 11:08:23 -0000 Hello, all! I want to make DNAT (Destination NAT) on FreeBSD 5.3 with saving of source IP in translated packets. As I understood, natd always changes source IP to value of "-alias_address" or IP of "-interface". As I understood, remaining source IP unchanged possible with "-proxy_only". But "proxy-only" works with TCP traffic only, but I want to process UDP traffic via natd. Please, give me some advice how I can to do this. Thank you beforehand! The Schema: srcipA-----> ipB(DNAT)------->dstipC Now I using redirect_address, but I want to see in server's logs at dstipC original client's ip address (srcipA - is a pool of 30 addresses). -- Sergey Vavilov, Perm, Russia From owner-freebsd-net@FreeBSD.ORG Wed Apr 13 00:02:33 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 519B116A4CE for ; Wed, 13 Apr 2005 00:02:33 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3A9143D45 for ; Wed, 13 Apr 2005 00:02:32 +0000 (GMT) (envelope-from swami.pichumani@gmail.com) Received: by zproxy.gmail.com with SMTP id 13so1978nzn for ; Tue, 12 Apr 2005 17:02:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=pfeUYfOu9g/NTx6svRlEUqN0jdl+PfnL3uDBW9pRuBwccNw5mULahSD7dyMCucfOwwJhaZTA+F2q/8NBpE9dCbbbc5Us/SxWi1SfAfh8nVHaTM5ggmx2VAjDNlyX+kkz1dtgcYVCTnuycq/tmZHR7oShe+YVHLzeIpaLPiBZ7Jw= Received: by 10.36.9.5 with SMTP id 5mr1641nzi; Tue, 12 Apr 2005 17:02:31 -0700 (PDT) Received: by 10.36.7.9 with HTTP; Tue, 12 Apr 2005 17:02:31 -0700 (PDT) Message-ID: Date: Tue, 12 Apr 2005 18:02:31 -0600 From: Swami Pichumani To: freebsd-net@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: RSA implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Swami Pichumani List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 00:02:33 -0000 Hi all Is there an in-kernel RSA implementation available...if there is one, could you kindly point me to it. I wish to use RSA functions in the TCP code. Can someone guide me on how I can go about doing that (if I dont want to implement RSA myself). thanks in advance, swami From owner-freebsd-net@FreeBSD.ORG Wed Apr 13 07:34:51 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2A8916A4CE for ; Wed, 13 Apr 2005 07:34:51 +0000 (GMT) Received: from mail3.mxc.ru (mail3.mxc.ru [80.64.106.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B924543D2F for ; Wed, 13 Apr 2005 07:34:50 +0000 (GMT) (envelope-from Stirch@mxc.ru) Received: from vasa ([10.3.1.171]) by monster2.mxc.ru (8.12.11/8.12.11) with ESMTP id j3D7W0VT028047 for ; Wed, 13 Apr 2005 11:32:00 +0400 Date: Wed, 13 Apr 2005 11:36:24 +0400 From: Nikolay Arhangelskiy X-Mailer: The Bat! (v2.00.6) Personal Organization: Maxima X-Priority: 3 (Normal) Message-ID: <147364753343.20050413113624@mxc.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Lots VLANs caouses ngctl to fail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Nikolay Arhangelskiy List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 07:34:52 -0000 Hello freebsd-net, I need to operate with hundreds VLANs on FreeBSD box (5.3). Using small script I create 250 VLANs, exec "ngctl list" - no problem, ngctl lists all 250 VLANs. After creating another 250 VLANs ngctl start to fail with message: ngctl: send msg: No buffer space available Is there are any limitations in ngctl on objects count? Or any kernel side limitations? -- Best regards, Nikolay mailto:Stirch@mxc.ru From owner-freebsd-net@FreeBSD.ORG Wed Apr 13 07:39:59 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CCD616A4CE for ; Wed, 13 Apr 2005 07:39:59 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1770743D1F for ; Wed, 13 Apr 2005 07:39:58 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j3D7duUC016476; Wed, 13 Apr 2005 11:39:56 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Wed, 13 Apr 2005 11:39:56 +0400 (MSD) From: Maxim Konovalov To: Nikolay Arhangelskiy In-Reply-To: <147364753343.20050413113624@mxc.ru> Message-ID: <20050413113925.D14769@mp2.macomnet.net> References: <147364753343.20050413113624@mxc.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-net@freebsd.org Subject: Re: Lots VLANs caouses ngctl to fail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 13 Apr 2005 07:39:59 -0000 On Wed, 13 Apr 2005, 11:36+0400, Nikolay Arhangelskiy wrote: > Hello freebsd-net, > > I need to operate with hundreds VLANs on FreeBSD box (5.3). > Using small script I create 250 VLANs, exec "ngctl list" - no > problem, ngctl lists all 250 VLANs. > After creating another 250 VLANs ngctl start to fail with message: > > ngctl: send msg: No buffer space available > > Is there are any limitations in ngctl on objects count? > Or any kernel side limitations? Increase net.graph.recvspace and net.graph.maxdgram. -- Maxim Konovalov From owner-freebsd-net@FreeBSD.ORG Wed Apr 13 07:45:02 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7576E16A4CE for ; Wed, 13 Apr 2005 07:45:02 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17E3643D39 for ; Wed, 13 Apr 2005 07:45:02 +0000 (GMT) (envelope-from phil.brennan@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so1523772nzk for ; Wed, 13 Apr 2005 00:45:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=jxFPJ/K9Mbn1ox0Fd0N9p+SbOcNkmTfTcM01Nq1l0KKIS3zf4kX8Om9Rth4XbKpLUR7Z0kCoa5gGVguxvDB+yjNU/DNNchil4jd48LWeETVgnqjqhH2Ekqm3wcDF3Tup7yDpeic8UbKUYo/REfRlQ5C5qNRCjHn4KKhGO7ZQRPo= Received: by 10.36.113.5 with SMTP id l5mr18189nzc; Wed, 13 Apr 2005 00:45:01 -0700 (PDT) Received: by 10.36.104.18 with HTTP; Wed, 13 Apr 2005 00:45:01 -0700 (PDT) Message-ID: Date: Wed, 13 Apr 2005 08:45:01 +0100 From: Phil Brennan To: freebsd-net@freebsd.org In-Reply-To: <147364753343.20050413113624@mxc.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <147364753343.20050413113624@mxc.ru> Subject: Re: Lots VLANs caouses ngctl to fail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Phil Brennan List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 07:45:02 -0000 On 4/13/05, Nikolay Arhangelskiy wrote: > Hello freebsd-net, >=20 > I need to operate with hundreds VLANs on FreeBSD box (5.3). > Using small script I create 250 VLANs, exec "ngctl list" - no > problem, ngctl lists all 250 VLANs. > After creating another 250 VLANs ngctl start to fail with message: >=20 > ngctl: send msg: No buffer space available >=20 > Is there are any limitations in ngctl on objects count? > Or any kernel side limitations? >=20 > -- > Best regards, > Nikolay mailto:Stirch@mxc.ru >=20 > _______________________________________________ > 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" >=20 I don't have a clue about ngctl, but still, it sounds like you are running out of network buffers. Have a look at the output of netstat -m, see if there is a problem with the usage of mbuf cluster usage. You might need to add something like OPTIONS NMBCLUSTERS 65536 to your kernel config and rebuild + reinstall the kernel. Or, I could be completely wrong, if so I apologise in advance :) Regards, Philip Brennan From owner-freebsd-net@FreeBSD.ORG Wed Apr 13 08:10:51 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65BF916A4CE for ; Wed, 13 Apr 2005 08:10:51 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0BD843D49 for ; Wed, 13 Apr 2005 08:10:50 +0000 (GMT) (envelope-from swami.pichumani@gmail.com) Received: by zproxy.gmail.com with SMTP id 34so83698nzf for ; Wed, 13 Apr 2005 01:10:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CNA53RWjQwyEHda9w7ekTgrkMUvLpMt4r0eHrxfrqmXaizVKditTj++lMabUK0IqB1U3jxNy6v4KuFKP19eYAYye5WguxuAQJCRBgafA75eL8TISRniUYicpd/xAaDgz+dhSEv4oGvYoRbtg3uHTUmdHTrcRQB/WWBo4OF+qhm8= Received: by 10.36.67.3 with SMTP id p3mr19372nza; Wed, 13 Apr 2005 01:10:50 -0700 (PDT) Received: by 10.36.7.9 with HTTP; Wed, 13 Apr 2005 01:10:50 -0700 (PDT) Message-ID: Date: Wed, 13 Apr 2005 04:10:50 -0400 From: Swami Pichumani To: freebsd-net@freebsd.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Subject: Fwd: RSA implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Swami Pichumani List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 08:10:51 -0000 Hi all Is there an in-kernel RSA implementation available...if there is one, could you kindly point me to it. I wish to use RSA functions in the TCP code. Can someone guide me on how I can go about doing that (if I dont want to implement RSA myself). thanks in advance, swami From owner-freebsd-net@FreeBSD.ORG Wed Apr 13 09:21:35 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B316916A4CE for ; Wed, 13 Apr 2005 09:21:35 +0000 (GMT) Received: from mail3.mxc.ru (mail3.mxc.ru [80.64.106.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C90043D58 for ; Wed, 13 Apr 2005 09:21:34 +0000 (GMT) (envelope-from Stirch@mxc.ru) Received: from vasa ([10.3.1.171]) by monster2.mxc.ru (8.12.11/8.12.11) with ESMTP id j3D9IkB6003689 for ; Wed, 13 Apr 2005 13:18:46 +0400 Resent-Date: Wed, 13 Apr 2005 13:18:46 +0400 Resent-Message-Id: <200504130918.j3D9IkB6003689@monster2.mxc.ru> Date: Wed, 13 Apr 2005 13:23:10 +0400 From: Nikolay Arhangelskiy X-Mailer: The Bat! (v2.00.6) Personal Organization: Maxima X-Priority: 3 (Normal) Message-ID: <169371158984.20050413132310@mxc.ru> To: freebsd-net@freebsd.org Resent-From: Nikolay Arhangelskiy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re[2]: Lots VLANs caouses ngctl to fail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Nikolay Arhangelskiy List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2005 09:21:35 -0000 Hello Maxim, >> I need to operate with hundreds VLANs on FreeBSD box (5.3). >> Using small script I create 250 VLANs, exec "ngctl list" - no >> problem, ngctl lists all 250 VLANs. >> After creating another 250 VLANs ngctl start to fail with message: >> >> ngctl: send msg: No buffer space available >> >> Is there are any limitations in ngctl on objects count? >> Or any kernel side limitations? MK> Increase net.graph.recvspace and net.graph.maxdgram. Very good, this solve the problem. Thank you. -- Best regards, Nikolay mailto:Stirch@mxc.ru From owner-freebsd-net@FreeBSD.ORG Wed Apr 13 09:39:26 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D35DF16A4CE for ; Wed, 13 Apr 2005 09:39:26 +0000 (GMT) Received: from sasami.jurai.net (sasami.jurai.net [69.17.104.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BADB43D39 for ; Wed, 13 Apr 2005 09:39:26 +0000 (GMT) (envelope-from mdodd@FreeBSD.ORG) Received: from sasami.jurai.net (winter@sasami.jurai.net [69.17.104.113]) by sasami.jurai.net (8.13.1/8.13.1) with ESMTP id j3D9dNqb017469; Wed, 13 Apr 2005 05:39:25 -0400 (EDT) (envelope-from mdodd@FreeBSD.ORG) Date: Wed, 13 Apr 2005 05:39:23 -0400 (EDT) From: "Matthew N. Dodd" X-X-Sender: winter@sasami.jurai.net To: Swami Pichumani In-Reply-To: Message-ID: <20050413052758.D3762@sasami.jurai.net> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sasami.jurai.net [69.17.104.113]); Wed, 13 Apr 2005 05:39:25 -0400 (EDT) cc: freebsd-net@FreeBSD.ORG Subject: Re: Fwd: RSA implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 13 Apr 2005 09:39:26 -0000 On Wed, 13 Apr 2005, Swami Pichumani wrote: > Is there an in-kernel RSA implementation available...if there is one, > could you kindly point me to it. I wish to use RSA functions in the TCP > code. Can someone guide me on how I can go about doing that (if I dont > want to implement RSA myself). The actual RSA bits aren't really a big deal: C = (T^E) mod PQ T = (C^D) mod PQ where C = ciphertext, T = plaintext, PQ = modulus, E = public exponent and D = secret exponent (from http://world.std.com/~franl/crypto/rsa-guts.html) You really need an arbitrary precision library and key management of some sort. I'm finishing up an arbitrary precision library that runs in the kernel and userland. I'd welcome review and critique once the code is ready for the light of day. I've got a few ideas about what key management should look like, and will be working on it soonish. What is your application? I'd like to make sure my work is useful to others. -- 10 40 80 C0 00 FF FF FF FF C0 00 00 00 00 10 AA AA 03 00 00 00 08 00 From owner-freebsd-net@FreeBSD.ORG Wed Apr 13 15:14:55 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D3AB16A4CE for ; Wed, 13 Apr 2005 15:14:55 +0000 (GMT) Received: from electra.nolink.net (electra.nolink.net [195.139.204.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3729D43D68 for ; Wed, 13 Apr 2005 15:14:54 +0000 (GMT) (envelope-from lerik@nolink.net) Received: (qmail 96819 invoked by uid 1000); 13 Apr 2005 15:14:53 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Apr 2005 15:14:53 -0000 Date: Wed, 13 Apr 2005 17:14:52 +0200 (CEST) From: Lars Erik Gullerud To: =?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?= In-Reply-To: <864qeibp0v.fsf@xps.des.no> Message-ID: <20050413171132.B96104@electra.nolink.net> References: <425196F0.4020309@x-trader.de> <6731347a839d85db456b1c5a33bcf0b5@mac.com> <864qeibp0v.fsf@xps.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-206236866-1113405292=:96104" cc: freebsd-net@freebsd.org Subject: Re: FreeVRRPd project status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 13 Apr 2005 15:14:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-206236866-1113405292=:96104 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 7 Apr 2005, Dag-Erling Sm=F8rgrav wrote: > Charles Swiger writes: >> It's dead, I think: Cisco's lawyers started making predatory noises >> about their "intellectual property". Some people from NetBSD are >> working on a replacement called CARP, which you might want to check >> out-- it seems that FreeBSD will be picking up support for this soon, >> as well. > > CARP comes from OpenBSD, not NetBSD, and is already in FreeBSD. =2E..and can't safely be deployed in a lot of datacenter scenarios where=20 the providers gear is running VRRP, since the OpenBSD-folks didn't bother= =20 to read up on how the process of obtaining a protocol number works, and=20 hence used the one assigned to VRRP after a half-baked attempt at getting= =20 one themselves. Hence making CARP pretty much useless for ISPs, no matter= =20 how good it may or may not be otherwise. /leg --0-206236866-1113405292=:96104-- From owner-freebsd-net@FreeBSD.ORG Wed Apr 13 15:30:50 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA21816A4CE for ; Wed, 13 Apr 2005 15:30:50 +0000 (GMT) Received: from foxgw.melen.org (foxgw.dna.fi [62.236.152.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CB5843D69 for ; Wed, 13 Apr 2005 15:30:49 +0000 (GMT) (envelope-from jan@melen.org) Received: from [192.168.2.2] ([192.168.2.2]) (authenticated bits=0) by foxgw.melen.org (8.13.3/8.12.11) with ESMTP id j3DFUimH002735 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 13 Apr 2005 18:30:47 +0300 (EEST) (envelope-from jan@melen.org) From: Jan Mikael Melen Date: Wed, 13 Apr 2005 18:30:42 +0300 User-Agent: KMail/1.7.1 To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200504131830.43195.jan@melen.org> X-Virus-Scanned: ClamAV 0.80/756/Tue Mar 8 22:21:12 2005 clamav-milter version 0.80j on foxgw.melen.org X-Virus-Status: Clean Subject: Fwd: [Hipsec] HIP4BSD source code X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 13 Apr 2005 15:30:51 -0000 Hi, In case somebody here is also interested in Host Identity Protocol (HIP). See below: ---------- Forwarded Message ---------- Subject: [Hipsec] HIP4BSD source code Date: Saturday 02 April 2005 12:54 To: Hi, There is now available new version of the HIP4BSD source code at http://www.hip4inter.net/ We have also a HIP test server running at our lab. The HIT of that server can be resolved from the AAAA record of either woodstock4.hip4inter.net or woodstock6.hip4inter.net. Naturally the woodstock4 resolves also as an IPv4 A record and woodstock6 resolves as an IPv6 AAAA record. On error during the base exchange an NOTIFY message will be sent and approriate error code is set. Both the code at hip4inter.net and the test server are implementing the draft-ietf-base-01 draft. Regards, Jan _______________________________________________ Hipsec mailing list http://honor.trusecure.com/mailman/listinfo/hipsec From owner-freebsd-net@FreeBSD.ORG Wed Apr 13 18:19:31 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B68A16A4CE for ; Wed, 13 Apr 2005 18:19:31 +0000 (GMT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9F9C43D3F for ; Wed, 13 Apr 2005 18:19:30 +0000 (GMT) (envelope-from cjeker@diehard.n-r-g.com) Received: (qmail 1600 invoked by uid 1001); 13 Apr 2005 18:19:32 -0000 Date: Wed, 13 Apr 2005 20:19:09 +0200 From: Claudio Jeker To: freebsd-net@freebsd.org Message-ID: <20050413181931.GA16696@diehard.n-r-g.com> Mail-Followup-To: Claudio Jeker , freebsd-net@freebsd.org References: <425196F0.4020309@x-trader.de> <6731347a839d85db456b1c5a33bcf0b5@mac.com> <864qeibp0v.fsf@xps.des.no> <20050413171132.B96104@electra.nolink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050413171132.B96104@electra.nolink.net> User-Agent: Mutt/1.5.8i Subject: Re: FreeVRRPd project status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 13 Apr 2005 18:19:31 -0000 On Wed, Apr 13, 2005 at 05:14:52PM +0200, Lars Erik Gullerud wrote: > On Thu, 7 Apr 2005, Dag-Erling Smørgrav wrote: > > >Charles Swiger writes: > >>It's dead, I think: Cisco's lawyers started making predatory noises > >>about their "intellectual property". Some people from NetBSD are > >>working on a replacement called CARP, which you might want to check > >>out-- it seems that FreeBSD will be picking up support for this soon, > >>as well. > > > >CARP comes from OpenBSD, not NetBSD, and is already in FreeBSD. > > ...and can't safely be deployed in a lot of datacenter scenarios where > the providers gear is running VRRP, since the OpenBSD-folks didn't bother > to read up on how the process of obtaining a protocol number works, and > hence used the one assigned to VRRP after a half-baked attempt at getting > one themselves. Hence making CARP pretty much useless for ISPs, no matter > how good it may or may not be otherwise. > This is not true. First of all the "OpenBSD-folks" asked IANA for protocol numbers for CARP and pfsync but IANA denied it. The reason was that CARP was not developped through an official standards organization. -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Wed Apr 13 18:22:29 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 564A316A4CE for ; Wed, 13 Apr 2005 18:22:29 +0000 (GMT) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA8AD43D2F for ; Wed, 13 Apr 2005 18:22:27 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [193.64.42.134] (h86.vuokselantie10.fi [193.64.42.134]) by silver.he.iki.fi (8.13.1/8.11.4) with ESMTP id j3DIMLQH067333; Wed, 13 Apr 2005 21:22:22 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <425D6378.5080108@he.iki.fi> Date: Wed, 13 Apr 2005 21:22:48 +0300 From: Petri Helenius User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claudio Jeker References: <425196F0.4020309@x-trader.de> <6731347a839d85db456b1c5a33bcf0b5@mac.com> <864qeibp0v.fsf@xps.des.no> <20050413171132.B96104@electra.nolink.net> <20050413181931.GA16696@diehard.n-r-g.com> In-Reply-To: <20050413181931.GA16696@diehard.n-r-g.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: freebsd-net@freebsd.org Subject: Re: FreeVRRPd project status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 13 Apr 2005 18:22:29 -0000 Claudio Jeker wrote: >On Wed, Apr 13, 2005 at 05:14:52PM +0200, Lars Erik Gullerud wrote: > > >>On Thu, 7 Apr 2005, Dag-Erling Smørgrav wrote: >> >> >> >>>Charles Swiger writes: >>> >>> >>>>It's dead, I think: Cisco's lawyers started making predatory noises >>>>about their "intellectual property". Some people from NetBSD are >>>>working on a replacement called CARP, which you might want to check >>>>out-- it seems that FreeBSD will be picking up support for this soon, >>>>as well. >>>> >>>> >>>CARP comes from OpenBSD, not NetBSD, and is already in FreeBSD. >>> >>> >>...and can't safely be deployed in a lot of datacenter scenarios where >>the providers gear is running VRRP, since the OpenBSD-folks didn't bother >>to read up on how the process of obtaining a protocol number works, and >>hence used the one assigned to VRRP after a half-baked attempt at getting >>one themselves. Hence making CARP pretty much useless for ISPs, no matter >>how good it may or may not be otherwise. >> >> >> > >This is not true. First of all the "OpenBSD-folks" asked IANA for protocol >numbers for CARP and pfsync but IANA denied it. The reason was that CARP >was not developped through an official standards organization. > > > Did this recently change since looking at /etc/protocols it does not seem to be the case for most of them anyway? Pete From owner-freebsd-net@FreeBSD.ORG Wed Apr 13 18:41:13 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3734C16A4CE for ; Wed, 13 Apr 2005 18:41:13 +0000 (GMT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F14743D1D for ; Wed, 13 Apr 2005 18:41:12 +0000 (GMT) (envelope-from cjeker@diehard.n-r-g.com) Received: (qmail 21687 invoked by uid 1001); 13 Apr 2005 18:41:11 -0000 Date: Wed, 13 Apr 2005 20:40:48 +0159 From: Claudio Jeker To: freebsd-net@freebsd.org Message-ID: <20050413184110.GB16696@diehard.n-r-g.com> Mail-Followup-To: Claudio Jeker , freebsd-net@freebsd.org References: <425196F0.4020309@x-trader.de> <6731347a839d85db456b1c5a33bcf0b5@mac.com> <864qeibp0v.fsf@xps.des.no> <20050413171132.B96104@electra.nolink.net> <20050413181931.GA16696@diehard.n-r-g.com> <425D6378.5080108@he.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <425D6378.5080108@he.iki.fi> User-Agent: Mutt/1.5.8i Subject: Re: FreeVRRPd project status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 13 Apr 2005 18:41:13 -0000 On Wed, Apr 13, 2005 at 09:22:48PM +0300, Petri Helenius wrote: > Claudio Jeker wrote: > > >On Wed, Apr 13, 2005 at 05:14:52PM +0200, Lars Erik Gullerud wrote: > > > > > >>On Thu, 7 Apr 2005, Dag-Erling Smørgrav wrote: > >> > >> > >> > >>>Charles Swiger writes: > >>> > >>> > >>>>It's dead, I think: Cisco's lawyers started making predatory noises > >>>>about their "intellectual property". Some people from NetBSD are > >>>>working on a replacement called CARP, which you might want to check > >>>>out-- it seems that FreeBSD will be picking up support for this soon, > >>>>as well. > >>>> > >>>> > >>>CARP comes from OpenBSD, not NetBSD, and is already in FreeBSD. > >>> > >>> > >>...and can't safely be deployed in a lot of datacenter scenarios where > >>the providers gear is running VRRP, since the OpenBSD-folks didn't bother > >>to read up on how the process of obtaining a protocol number works, and > >>hence used the one assigned to VRRP after a half-baked attempt at getting > >>one themselves. Hence making CARP pretty much useless for ISPs, no matter > >>how good it may or may not be otherwise. > >> > >> > >> > > > >This is not true. First of all the "OpenBSD-folks" asked IANA for protocol > >numbers for CARP and pfsync but IANA denied it. The reason was that CARP > >was not developped through an official standards organization. > > > > > > > Did this recently change since looking at /etc/protocols it does not > seem to be the case for most of them anyway? > Most new protocols come from either some company, DARPA or some US university. CARP was developped by neither of those three and it is long known that IETF and IANA are just a pathetic bunch of company deputies. -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Wed Apr 13 19:10:20 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 355A716A4CE for ; Wed, 13 Apr 2005 19:10:20 +0000 (GMT) Received: from silver.he.iki.fi (helenius.fi [193.64.42.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68E5743D39 for ; Wed, 13 Apr 2005 19:10:19 +0000 (GMT) (envelope-from pete@he.iki.fi) Received: from [193.64.42.134] (h86.vuokselantie10.fi [193.64.42.134]) by silver.he.iki.fi (8.13.1/8.11.4) with ESMTP id j3DJAF7F067601; Wed, 13 Apr 2005 22:10:16 +0300 (EEST) (envelope-from pete@he.iki.fi) Message-ID: <425D6EB2.5010304@he.iki.fi> Date: Wed, 13 Apr 2005 22:10:42 +0300 From: Petri Helenius User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Claudio Jeker References: <425196F0.4020309@x-trader.de> <6731347a839d85db456b1c5a33bcf0b5@mac.com> <864qeibp0v.fsf@xps.des.no> <20050413171132.B96104@electra.nolink.net> <20050413181931.GA16696@diehard.n-r-g.com> <425D6378.5080108@he.iki.fi> <20050413184110.GB16696@diehard.n-r-g.com> In-Reply-To: <20050413184110.GB16696@diehard.n-r-g.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: FreeVRRPd project status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 13 Apr 2005 19:10:20 -0000 Claudio Jeker wrote: >On Wed, Apr 13, 2005 at 09:22:48PM +0300, Petri Helenius wrote: > > >>Claudio Jeker wrote: >> >> >> >>> >>> >>> >>Did this recently change since looking at /etc/protocols it does not >>seem to be the case for most of them anyway? >> >> >> > >Most new protocols come from either some company, DARPA or some US >university. CARP was developped by neither of those three and it is long >known that IETF and IANA are just a pathetic bunch of company deputies. > > > However, it's an open process, anybody with roughly 30 people can start a WG. That's how protocols like "MS-CHAP" get "standardized". Pete From owner-freebsd-net@FreeBSD.ORG Wed Apr 13 19:36:50 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8ADAD16A4CE for ; Wed, 13 Apr 2005 19:36:50 +0000 (GMT) Received: from electra.nolink.net (electra.nolink.net [195.139.204.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FC4343D48 for ; Wed, 13 Apr 2005 19:36:49 +0000 (GMT) (envelope-from lerik@nolink.net) Received: (qmail 25034 invoked by uid 1000); 13 Apr 2005 19:36:48 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 13 Apr 2005 19:36:48 -0000 Date: Wed, 13 Apr 2005 21:36:48 +0200 (CEST) From: Lars Erik Gullerud To: Claudio Jeker In-Reply-To: <20050413181931.GA16696@diehard.n-r-g.com> Message-ID: <20050413212349.P22243@electra.nolink.net> References: <425196F0.4020309@x-trader.de> <6731347a839d85db456b1c5a33bcf0b5@mac.com> <20050413171132.B96104@electra.nolink.net> <20050413181931.GA16696@diehard.n-r-g.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-net@freebsd.org Subject: Re: FreeVRRPd project status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 13 Apr 2005 19:36:50 -0000 On Wed, 13 Apr 2005, Claudio Jeker wrote: > On Wed, Apr 13, 2005 at 05:14:52PM +0200, Lars Erik Gullerud wrote: >> >> ...and can't safely be deployed in a lot of datacenter scenarios where >> the providers gear is running VRRP, since the OpenBSD-folks didn't bother >> to read up on how the process of obtaining a protocol number works, and >> hence used the one assigned to VRRP after a half-baked attempt at getting >> one themselves. Hence making CARP pretty much useless for ISPs, no matter >> how good it may or may not be otherwise. >> > > This is not true. First of all the "OpenBSD-folks" asked IANA for protocol > numbers for CARP and pfsync but IANA denied it. The reason was that CARP Which is exactly what I said, they didn't bother to read how the process works and accordingly made a half-baked attempt only. You don't just fire off a mail to IANA and say "hi, can I get a protocol number", that's just not how things work, except in OpenBSD-land, obviously. :) > was not developped through an official standards organization. Which is balony, you do however need to take the PROCESS through the correct "organization" (i.e. the IETF and friends, although the protocol itself can be developed through my grandma's knitting club). So, I stand by my initial statement (but hey, I'm a network engineer at an ISP, not a BSD developer - yes, us people the OpenBSD guys don't like much because we like to point out the glaring problems in things like CARP and OpenBGPd). However, this is all very much beside the point, so further IETF/IANA-bashing or OpenBSD-bashing can be taken somewhere more appropriate than this list. (Feel free to flame me privately) My point is that this very unwise decision to reuse the VRRP protocol number, makes CARP mostly undeployable for ISP datacenter environments, and hence there is an obvious need for a working VRRP implementation, it doesn't help that CARP is now available in FreeBSD, because it is not a viable alternative in a lot of scenarios. /leg From owner-freebsd-net@FreeBSD.ORG Wed Apr 13 20:08:25 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1071816A4F6 for ; Wed, 13 Apr 2005 20:08:24 +0000 (GMT) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 023BD43D1D for ; Wed, 13 Apr 2005 20:08:23 +0000 (GMT) (envelope-from cjeker@diehard.n-r-g.com) Received: (qmail 13715 invoked by uid 1001); 13 Apr 2005 20:08:26 -0000 Date: Wed, 13 Apr 2005 22:08:04 +0200 From: Claudio Jeker To: freebsd-net@freebsd.org Message-ID: <20050413200826.GB6922@diehard.n-r-g.com> Mail-Followup-To: Claudio Jeker , freebsd-net@freebsd.org References: <425196F0.4020309@x-trader.de> <6731347a839d85db456b1c5a33bcf0b5@mac.com> <20050413171132.B96104@electra.nolink.net> <20050413181931.GA16696@diehard.n-r-g.com> <20050413212349.P22243@electra.nolink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050413212349.P22243@electra.nolink.net> User-Agent: Mutt/1.5.8i Subject: Re: FreeVRRPd project status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 13 Apr 2005 20:08:25 -0000 On Wed, Apr 13, 2005 at 09:36:48PM +0200, Lars Erik Gullerud wrote: > On Wed, 13 Apr 2005, Claudio Jeker wrote: > > >On Wed, Apr 13, 2005 at 05:14:52PM +0200, Lars Erik Gullerud wrote: > >> > >>...and can't safely be deployed in a lot of datacenter scenarios where > >>the providers gear is running VRRP, since the OpenBSD-folks didn't bother > >>to read up on how the process of obtaining a protocol number works, and > >>hence used the one assigned to VRRP after a half-baked attempt at getting > >>one themselves. Hence making CARP pretty much useless for ISPs, no matter > >>how good it may or may not be otherwise. > >> > > > >This is not true. First of all the "OpenBSD-folks" asked IANA for protocol > >numbers for CARP and pfsync but IANA denied it. The reason was that CARP > > Which is exactly what I said, they didn't bother to read how the process > works and accordingly made a half-baked attempt only. You don't just fire > off a mail to IANA and say "hi, can I get a protocol number", that's just > not how things work, except in OpenBSD-land, obviously. :) > OpenBSD did more than just write a mail "hi, can I get a protocol number". > >was not developped through an official standards organization. > > Which is balony, you do however need to take the PROCESS through > the correct "organization" (i.e. the IETF and friends, although the > protocol itself can be developed through my grandma's knitting club). So, > I stand by my initial statement (but hey, I'm a network engineer at an > ISP, not a BSD developer - yes, us people the OpenBSD guys don't like > much because we like to point out the glaring problems in things like > CARP and OpenBGPd). However, this is all very much beside the point, so > further IETF/IANA-bashing or OpenBSD-bashing can be taken somewhere more > appropriate than this list. (Feel free to flame me privately) > The problem is that the correct "organization" is a exclusive club where opensource mostly doesn't matter. It is hard to get into the club as a non-profit project that mostly gets developped in spare time. Also I would be intrested what the glaring problems of OpenBGPd are. An important part of developement is feedback. > My point is that this very unwise decision to reuse the VRRP protocol > number, makes CARP mostly undeployable for ISP datacenter environments, > and hence there is an obvious need for a working VRRP implementation, it > doesn't help that CARP is now available in FreeBSD, because it is not a > viable alternative in a lot of scenarios. > As it seems you know how the IETF and IANA process works to, you could go and get a protocol number for carp and solve the problem. But as usual it is far easier to come up with some semi-true statements, fallacies and straw mens than to acctually start fixing stuff. Now I should shut up and start hacking. -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Wed Apr 13 22:03:24 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 936C916A4CE; Wed, 13 Apr 2005 22:03:24 +0000 (GMT) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 353FD43D2D; Wed, 13 Apr 2005 22:03:22 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by aldan.algebra.com (8.13.1/8.13.1) with ESMTP id j3DM3HIR018762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Apr 2005 18:03:19 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (195-11.customer.cloud9.net [168.100.195.11])j3DM3An8073122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2005 18:03:11 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (mteterin@localhost [127.0.0.1]) by mteterin.us.murex.com (8.13.3/8.13.3) with ESMTP id j3DM39qJ063817; Wed, 13 Apr 2005 18:03:09 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by mteterin.us.murex.com (8.13.3/8.13.3/Submit) id j3DM38DB063816; Wed, 13 Apr 2005 18:03:08 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) X-Authentication-Warning: mteterin.us.murex.com: mteterin set sender to mi+mx@aldan.algebra.com using -f From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Q Date: Wed, 13 Apr 2005 18:03:08 -0400 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_ccZXC3AlSJ4BH2t" Message-Id: <200504131803.08538.mi+mx@aldan.algebra.com> X-Virus-Scanned: clamd / ClamAV version devel-20040615, clamav-milter version 0.73a on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 cc: amd64@FreeBSD.org cc: net@FreeBSD.org Subject: nvnet does not see NVidia's adapter on amd64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 13 Apr 2005 22:03:24 -0000 --Boundary-00=_ccZXC3AlSJ4BH2t Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi! I just installed a fresh 5.4-RC2 on IWill's DK8N motherboard: http://www.iwillusa.com/product_2.asp?p_id=27 I transfered the net/nvnet's distfiles using a floppy and built the driver. Unfortunately, kldload-ing if_nv did not make the interface appear... Putting ``if_nv_load="YES"'' into loader.conf and rebooting did not help either. Is there anything, you can suggest for me try right off the bat? I'm attaching the dmesg.boot and the output of 'pciconf -lv'. Thanks! Yours, -mi --Boundary-00=_ccZXC3AlSJ4BH2t Content-Type: text/plain; charset="us-ascii"; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.txt" ata3-slave: stat=0x7f err=0xff lsb=0xff msb=0xff ata3: reset tp2 stat0=ff stat1=ff devices=0x0 ata3: [MPSAFE] pcib1: at device 11.0 on pci0 pcib1: secondary bus 2 pcib1: subordinate bus 2 pcib1: I/O decode 0x9000-0x9fff pcib1: memory decode 0xff100000-0xff1fffff pcib1: prefetched decode 0xe6900000-0xee8fffff pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P2 - AE_NOT_FOUND pci2: on pcib1 pci2: physical bus=2 map[10]: type 3, range 32, base e8000000, size 26, enabled pcib1: device (null) requested decoded memory range 0xe8000000-0xebffffff map[14]: type 4, range 32, base 00009800, size 8, enabled pcib1: device (null) requested decoded I/O range 0x9800-0x98ff map[18]: type 1, range 32, base ff1fc000, size 14, enabled pcib1: device (null) requested decoded memory range 0xff1fc000-0xff1fffff pcib0: matched entry for 0.11.INTA (src \\_SB_.LNKE) pcib0: possible interrupts: 16 17 18 19 ACPI PCI link arbitrated settings: \\_SB_.LNKB (references 3, priority 840): interrupts: 19 18 17 16 penalty: 280 280 280 280 \\_SB_.LKSM (references 1, priority 706): interrupts: 20 22 21 penalty: 640 740 740 \\_SB_.LKMO (references 1, priority 706): interrupts: 20 22 21 penalty: 640 740 740 \\_SB_.LTIE (references 1, priority 706): interrupts: 20 22 21 penalty: 640 740 740 \\_SB_.LNKE (references 1, priority 280): interrupts: 19 18 17 16 penalty: 280 280 280 280 pcib0: slot 11 INTA routed to irq 19 via \\_SB_.LNKE pcib1: slot 0 INTA is routed to irq 19 found-> vendor=0x1002, dev=0x5446, revid=0x00 bus=2, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0087, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=19 powerspec 2 supports D0 D1 D3 current D0 pci2: at device 0.0 (no driver attached) pcib2: at device 14.0 on pci0 pcib2: secondary bus 1 pcib2: subordinate bus 1 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xff000000-0xff0fffff pcib2: prefetched decode 0xfff00000-0xfffff ACPI link \\_SB_.LNKD has invalid initial irq 10, ignoring ACPI link \\_SB_.LNKC has invalid initial irq 10, ignoring ACPI PCI link initial configuration: \\_SB_.LNKD irq 0: [16 17 18 19] 0+ low,level,sharable 1.7.0 \\_SB_.LNKA irq 0: [16 17 18 19] 0+ low,level,sharable 1.7.1 \\_SB_.LNKB irq 0: [16 17 18 19] 0+ low,level,sharable 1.7.2 \\_SB_.LNKC irq 0: [16 17 18 19] 0+ low,level,sharable 1.7.3 \\_SB_.LNKC irq 0: [16 17 18 19] 0+ low,level,sharable 1.6.0 \\_SB_.LNKD irq 0: [16 17 18 19] 0+ low,level,sharable 1.6.1 \\_SB_.LNKA irq 0: [16 17 18 19] 0+ low,level,sharable 1.6.2 \\_SB_.LNKB irq 0: [16 17 18 19] 0+ low,level,sharable 1.6.3 pci1: on pcib2 pci1: physical bus=1 map[10]: type 1, range 32, base ff0ff800, size 11, enabled pcib2: device (null) requested decoded memory range 0xff0ff800-0xff0fffff map[14]: type 1, range 32, base ff0f8000, size 14, enabled pcib2: device (null) requested decoded memory range 0xff0f8000-0xff0fbfff pcib2: matched entry for 1.6.INTA (src \\_SB_.LNKC) pcib2: possible interrupts: 16 17 18 19 ACPI PCI link arbitrated settings: \\_SB_.LNKB (references 5, priority 2212): interrupts: 18 17 16 19 penalty: 440 440 440 450 \\_SB_.LNKD (references 2, priority 885): interrupts: 18 17 16 19 penalty: 440 440 440 450 \\_SB_.LNKA (references 2, priority 885): interrupts: 18 17 16 19 penalty: 440 440 440 450 \\_SB_.LNKC (references 2, priority 885): interrupts: 18 17 16 19 penalty: 440 440 440 450 \\_SB_.LKSM (references 1, priority 706): interrupts: 20 21 22 penalty: 640 740 740 \\_SB_.LKMO (references 1, priority 706): interrupts: 20 21 22 penalty: 640 740 740 \\_SB_.LTIE (references 1, priority 706): interrupts: 20 21 22 penalty: 640 740 740 pcib2: slot 6 INTA routed to irq 18 via \\_SB_.LNKC found-> vendor=0x104c, dev=0x8023, revid=0x00 bus=1, slot=6, func=0 class=0c-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0116, statreg=0x0210, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=18 powerspec 2 supports D0 D1 D2 D3 current D0 fwohci0: mem 0xff0f8000-0xff0fbfff,0xff0ff800-0xff0fffff irq 18 at device 6.0 on pci1 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xff0ff800 fwohci0: [MPSAFE] fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:00:00:00:01:46:87 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:00:01:46:87 fwe0: bpf attached fwe0: Ethernet address: 02:00:00:01:46:87 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pcib3: on acpi0 pcib3: could not get PCI interrupt routing table for \\_SB_.PCIB - AE_NOT_FOUND pci3: on pcib3 pci3: physical bus=3 found-> vendor=0x1022, dev=0x7450, revid=0x12 bus=3, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0117, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x07 (1750 ns), maxlat=0x04 (1000 ns) map[10]: type 1, range 64, base ff6fe000, size 12, enabled found-> vendor=0x1022, dev=0x7451, revid=0x01 bus=3, slot=1, func=1 class=08-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x7450, revid=0x12 bus=3, slot=2, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0116, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 64, base ff6ff000, size 12, enabled found-> vendor=0x1022, dev=0x7451, revid=0x01 bus=3, slot=2, func=1 class=08-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib4: at device 1.0 on pci3 pcib4: secondary bus 5 pcib4: subordinate bus 5 pcib4: I/O decode 0xd000-0xefff pcib4: memory decode 0xff400000-0xff5fffff pcib4: prefetched decode 0xfff00000-0xfffff ACPI PCI link initial configuration: pci5: on pcib4 pci5: physical bus=5 map[10]: type 4, range 32, base 0000ec00, size 3, enabled pcib4: device (null) requested decoded I/O range 0xec00-0xec07 map[14]: type 4, range 32, base 0000e800, size 2, enabled pcib4: device (null) requested decoded I/O range 0xe800-0xe803 map[18]: type 4, range 32, base 0000e400, size 3, enabled pcib4: device (null) requested decoded I/O range 0xe400-0xe407 map[1c]: type 4, range 32, base 0000e000, size 2, enabled pcib4: device (null) requested decoded I/O range 0xe000-0xe003 map[20]: type 4, range 32, base 0000dc00, size 4, enabled pcib4: device (null) requested decoded I/O range 0xdc00-0xdc0f map[24]: type 1, range 32, base ff5ffc00, size 10, enabled pcib4: device (null) requested decoded memory range 0xff5ffc00-0xff5fffff pcib4: matched entry for 5.3.INTA pcib4: slot 3 INTA hardwired to IRQ 27 found-> vendor=0x1095, dev=0x3114, revid=0x02 bus=5, slot=3, func=0 class=01-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=27 powerspec 2 supports D0 D1 D2 D3 current D0 atapci2: port 0xdc00-0xdc0f,0xe000-0xe003,0xe400-0xe407,0xe800-0xe803,0xec00-0xec07 mem 0xff5ffc00-0xff5fffff irq 27 at device 3.0 on pci5 atapci2: Reserved 0x10 bytes for rid 0x20 type 4 at 0xdc00 atapci2: [MPSAFE] atapci2: Reserved 0x400 bytes for rid 0x24 type 3 at 0xff5ffc00 ata4: channel #0 on atapci2 ata4: reset tp1 mask=01 ostat0=50 ostat1=50 ata4-master: stat=0xd0 err=0xd0 lsb=0xd0 msb=0xd0 ata4-master: stat=0xd0 err=0xd0 lsb=0xd0 msb=0xd0 ata4-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata4: reset tp2 stat0=50 stat1=00 devices=0x1 ata4: [MPSAFE] ata5: channel #1 on atapci2 ata5: reset tp1 mask=01 ostat0=50 ostat1=50 ata5-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata5: reset tp2 stat0=50 stat1=00 devices=0x1 ata5: [MPSAFE] ata6: channel #2 on atapci2 ata6: reset tp1 mask=01 ostat0=7f ostat1=7f ata6-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata6-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata6-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata6-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata6-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata6-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata6-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata6: reset tp2 stat0=ff stat1=00 devices=0x0 ata6: [MPSAFE] ata7: channel #3 on atapci2 ata7: reset tp1 mask=01 ostat0=7f ostat1=7f ata7-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata7-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata7-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata7-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata7-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata7-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata7-master: stat=0x7f err=0x00 lsb=0x00 msb=0x00 ata7: reset tp2 stat0=ff stat1=00 devices=0x0 ata7: [MPSAFE] pci3: at device 1.1 (no driver attached) pcib5: at device 2.0 on pci3 pcib5: secondary bus 4 pcib5: subordinate bus 4 pcib5: I/O decode 0x0-0x0 pcib5: memory decode 0xff300000-0xff3fffff pcib5: prefetched decode 0xfea00000-0xfeafffff ACPI PCI link initial configuration: pci4: on pcib5 pci4: physical bus=4 map[10]: type 3, range 32, base feaf0000, size 16, enabled pcib5: device (null) requested decoded memory range 0xfeaf0000-0xfeafffff pcib5: matched entry for 4.1.INTA pcib5: slot 1 INTA hardwired to IRQ 29 found-> vendor=0x1000, dev=0x1960, revid=0x01 bus=4, slot=1, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x0116, statreg=0x04b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=29 powerspec 2 supports D0 D3 current D0 amr0: mem 0xfeaf0000-0xfeafffff irq 29 at device 1.0 on pci4 amr0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfeaf0000 amr0: [MPSAFE] amr0: Firmware 712T, BIOS G116, 64MB RAM pci3: at device 2.1 (no driver attached) acpi_button0: on acpi0 unknown: not probed (disabled) sio0: irq maps: 0xa3 0xb3 0xa3 0xa3 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: irq maps: 0xa3 0xab 0xa3 0xa3 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ahc_isa_probe 10: ioport 0xac00 alloc failed ahc_isa_probe 11: ioport 0xbc00 alloc failed ahc_isa_probe 12: ioport 0xcc00 alloc failed ahc_isa_probe 13: ioport 0xdc00 alloc failed ahc_isa_probe 14: ioport 0xec00 alloc failed ex_isa_identify() atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc8800-0xccfff,0xc0000-0xc7fff on isa0 ppc0: cannot reserve I/O port range ppc0: failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xffffffff800b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 EGA/VGA parameters to be used for mode 24 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 132744 -> 100000 procfs registered linprocfs registered Timecounter "TSC" frequency 1800005863 Hz quality 800 Timecounters tick every 1.000 msec Linux ELF exec handler installed lo0: bpf attached ata1-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin ata1-master: setting PIO4 on nVidia nForce3 Pro chip acd0: CDROM drive at ata1 as master acd0: read 5512KB/s (5512KB/s), 256KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA, packet acd0: Writes: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ata4-master: pio=0x0c wdma=0x22 udma=0x46 cable=40pin ad8: ATA-6 disk at ata4-master ad8: 190782MB (390721968 sectors), 387621 C, 16 H, 63 S, 512 B ad8: 16 secs/int, 1 depth queue, SATA150 ar: LSI check1 failed ata5-master: FAILURE - ATA_IDENTIFY status=51 error=4 LBA=0 GEOM: new disk ad8 [0] f:00 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:16771797 [1] f:80 typ:165 s(CHS):1023/255/63 e(CHS):1023/254/63 s:16771860 l:4192965 [2] f:00 typ:165 s(CHS):1023/255/63 e(CHS):1023/254/63 s:20964825 l:16771860 [3] f:00 typ:165 s(CHS):1023/255/63 e(CHS):1023/254/63 s:37736685 l:352980180 GEOM: Configure ad8s1, start 32256 length 8587160064 end 8587192319 GEOM: Configure ad8s2, start 8587192320 length 2146798080 end 10733990399 GEOM: Configure ad8s3, start 10733990400 length 8587192320 end 19321182719 GEOM: Configure ad8s4, start 19321182720 length 180725852160 end 200047034879 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 GEOM: Configure ad8s1b, start 0 length 8587160064 end 8587160063 GEOM: Configure ad8s1c, start 0 length 8587160064 end 8587160063 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 GEOM: Configure ad8s2a, start 0 length 2146798080 end 2146798079 GEOM: Configure ad8s2c, start 0 length 2146798080 end 2146798079 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 GEOM: Configure ad8s3c, start 0 length 8587192320 end 8587192319 GEOM: Configure ad8s3d, start 0 length 8587192320 end 8587192319 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 GEOM: Configure ad8s4c, start 0 length 180725852160 end 180725852159 GEOM: Configure ad8s4d, start 0 length 180725852160 end 180725852159 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 ata5: reiniting channel .. ata5: reset tp1 mask=01 ostat0=50 ostat1=50 ata5-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata5: reset tp2 stat0=50 stat1=00 devices=0x1 ata5: resetting done .. ata5-master: FAILURE - ATA_IDENTIFY status=51 error=4 LBA=0 ata5: reiniting channel .. ata5-master: FAILURE - ATA_IDENTIFY timed out ata5: device config done .. ata5-master: FAILURE - ATA_IDENTIFY timed out amrd0: on amr0 amrd0: 953885MB (1953556480 sectors) RAID 5 (optimal) GEOM: new disk amrd0 (probe21:amr0:0:15:0): error 22 (probe21:amr0:0:15:0): Unretryable Error (probe13:amr0:0:6:0): error 22 (probe13:amr0:0:6:0): Unretryable Error (probe14:amr0:0:8:0): error 22 (probe14:amr0:0:8:0): Unretryable Error (probe15:amr0:0:9:0): error 22 (probe15:amr0:0:9:0): Unretryable Error (probe16:amr0:0:10:0): error 22 (probe16:amr0:0:10:0): Unretryable Error (probe17:amr0:0:11:0): error 22 (probe17:amr0:0:11:0): Unretryable Error (probe18:amr0:0:12:0): error 22 (probe18:amr0:0:12:0): Unretryable Error (probe19:amr0:0:13:0): error 22 (probe19:amr0:0:13:0): Unretryable Error (probe20:amr0:0:14:0): error 22 (probe20:amr0:0:14:0): Unretryable Error (probe12:amr0:0:5:0): error 22 (probe12:amr0:0:5:0): Unretryable Error (probe11:amr0:0:4:0): error 22 (probe11:amr0:0:4:0): Unretryable Error (probe9:amr0:0:2:0): error 22 (probe9:amr0:0:2:0): Unretryable Error (probe7:amr0:0:0:0): error 22 (probe7:amr0:0:0:0): Unretryable Error (probe8:amr0:0:1:0): error 22 (probe8:amr0:0:1:0): Unretryable Error (probe10:amr0:0:3:0): error 22 (probe10:amr0:0:3:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 3 (ISA IRQ 3) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 6 (ISA IRQ 6) to cluster 0 ioapic0: routing intpin 8 (ISA IRQ 8) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 14 (ISA IRQ 14) to cluster 0 ioapic0: routing intpin 15 (ISA IRQ 15) to cluster 0 ioapic0: routing intpin 18 (PCI IRQ 18) to cluster 0 ioapic0: routing intpin 21 (PCI IRQ 21) to cluster 0 ioapic0: routing intpin 22 (PCI IRQ 22) to cluster 0 ioapic1: routing intpin 3 (PCI IRQ 27) to cluster 0 ioapic2: routing intpin 1 (PCI IRQ 29) to cluster 0 Mounting root from ufs:/dev/ad8s2a start_init: trying /sbin/init [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...3 2 2 1 0 0 done No buffers busy after final sync Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-RC2 #0: Sun Apr 10 04:02:23 UTC 2005 root@portnoy.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Opteron(tm) Processor 244 (1800.01-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0xf58 Stepping = 8 Features=0x78bfbff AMD Features=0xe0500800 real memory = 2146697216 (2047 MB) avail memory = 2060873728 (1965 MB) ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-27 on motherboard ioapic2 irqs 28-31 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 pcib0: port 0xcf8-0xcff on acpi0 ACPI link \\_SB_.LUS0 has invalid initial irq 10, ignoring ACPI link \\_SB_.LKLN has invalid initial irq 5, ignoring ACPI link \\_SB_.LUS1 has invalid initial irq 11, ignoring ACPI link \\_SB_.LUS2 has invalid initial irq 7, ignoring ACPI link \\_SB_.LNKE has invalid initial irq 11, ignoring ACPI link \\_SB_.LNKB has invalid initial irq 10, ignoring ACPI link \\_SB_.LTIE has invalid initial irq 10, ignoring pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xff2fb000-0xff2fbfff irq 22 at device 2.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered ohci1: mem 0xff2fc000-0xff2fcfff irq 21 at device 2.1 on pci0 usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 4 ports with 4 removable, self powered pci0: at device 2.2 (no driver attached) pci0: at device 5.0 (no driver attached) pci0: at device 6.0 (no driver attached) atapci0: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 8.0 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 atapci1: port 0xbc00-0xbc0f,0xc000-0xc003,0xc400-0xc407,0xc800-0xc803,0xcc00-0xcc07 irq 21 at device 10.0 on pci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 pcib1: at device 11.0 on pci0 pci2: on pcib1 pci2: at device 0.0 (no driver attached) pcib2: at device 14.0 on pci0 ACPI link \\_SB_.LNKD has invalid initial irq 10, ignoring ACPI link \\_SB_.LNKC has invalid initial irq 10, ignoring pci1: on pcib2 fwohci0: mem 0xff0f8000-0xff0fbfff,0xff0ff800-0xff0fffff irq 18 at device 6.0 on pci1 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:00:00:00:01:46:87 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:00:01:46:87 fwe0: Ethernet address: 02:00:00:01:46:87 fwe0: if_start running deferred for Giant sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pcib3: on acpi0 pci3: on pcib3 pcib4: at device 1.0 on pci3 pci5: on pcib4 atapci2: port 0xdc00-0xdc0f,0xe000-0xe003,0xe400-0xe407,0xe800-0xe803,0xec00-0xec07 mem 0xff5ffc00-0xff5fffff irq 27 at device 3.0 on pci5 ata4: channel #0 on atapci2 ata5: channel #1 on atapci2 ata6: channel #2 on atapci2 ata7: channel #3 on atapci2 pci3: at device 1.1 (no driver attached) pcib5: at device 2.0 on pci3 pci4: on pcib5 amr0: mem 0xfeaf0000-0xfeafffff irq 29 at device 1.0 on pci4 amr0: Firmware 712T, BIOS G116, 64MB RAM pci3: at device 2.1 (no driver attached) acpi_button0: on acpi0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 orm0: at iomem 0xc8800-0xccfff,0xc0000-0xc7fff on isa0 ppc0: cannot reserve I/O port range sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1800006073 Hz quality 800 Timecounters tick every 1.000 msec acd0: CDROM at ata1-master PIO4 ad8: 190782MB [387621/16/63] at ata4-master SATA150 ata5-master: FAILURE - ATA_IDENTIFY status=51 error=4 LBA=0 ata5-master: FAILURE - ATA_IDENTIFY status=51 error=4 LBA=0 ata5-master: FAILURE - ATA_IDENTIFY timed out ata5-master: FAILURE - ATA_IDENTIFY timed out amrd0: on amr0 amrd0: 953885MB (1953556480 sectors) RAID 5 (optimal) Mounting root from ufs:/dev/ad8s2a --Boundary-00=_ccZXC3AlSJ4BH2t Content-Type: text/plain; charset="us-ascii"; name="pciconf.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="pciconf.txt" hostb0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x00e110de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = bridge subclass = HOST-PCI isab0@pci0:1:0: class=0x060100 card=0x004415d4 chip=0x00e010de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-ISA none0@pci0:1:1: class=0x0c0500 card=0x004415d4 chip=0x00e410de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce PCI System Management' class = serial bus subclass = SMBus ohci0@pci0:2:0: class=0x0c0310 card=0x004415d4 chip=0x00e710de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = serial bus subclass = USB ohci1@pci0:2:1: class=0x0c0310 card=0x004415d4 chip=0x00e710de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = serial bus subclass = USB none1@pci0:2:2: class=0x0c0320 card=0x004415d4 chip=0x00e810de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = serial bus subclass = USB none2@pci0:5:0: class=0x068000 card=0x004415d4 chip=0x00df10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'Network Bus Enumerator' class = bridge none3@pci0:6:0: class=0x040100 card=0x004415d4 chip=0x00ea10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = multimedia subclass = audio atapci0@pci0:8:0: class=0x01018a card=0x004415d4 chip=0x00e510de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'CK8S Parallel ATA Controller' class = mass storage subclass = ATA atapci1@pci0:10:0: class=0x010185 card=0x00000000 chip=0x00e310de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'CK8S Serial ATA Controller' class = mass storage subclass = ATA pcib1@pci0:11:0: class=0x060400 card=0x00000000 chip=0x00e210de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'nForce3 250 AGP Host to PCI Bridge' class = bridge subclass = PCI-PCI pcib2@pci0:14:0: class=0x060400 card=0x00000000 chip=0x00ed10de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI hostb1@pci0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb2@pci0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron Address Map' class = bridge subclass = HOST-PCI hostb3@pci0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron DRAM Controller' class = bridge subclass = HOST-PCI hostb4@pci0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron Miscellaneous Control' class = bridge subclass = HOST-PCI none4@pci2:0:0: class=0x030000 card=0x04081002 chip=0x54461002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc.' device = 'Rage 128 PRO ULTRA Video Controller (VGA Compatible)' class = display subclass = VGA fwohci0@pci1:6:0: class=0x0c0010 card=0x8023104c chip=0x8023104c rev=0x00 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'TSB43AB22/A IEEE1394a-2000 OHCI PHY/Link-Layer Ctrlr' class = serial bus subclass = FireWire pcib4@pci3:1:0: class=0x060400 card=0x000000a0 chip=0x74501022 rev=0x12 hdr=0x01 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8131 PCI-X Bridge' class = bridge subclass = PCI-PCI none5@pci3:1:1: class=0x080010 card=0x36c01022 chip=0x74511022 rev=0x01 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8131 PCI-X IOAPIC' class = base peripheral subclass = interrupt controller pcib5@pci3:2:0: class=0x060400 card=0x000000a0 chip=0x74501022 rev=0x12 hdr=0x01 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8131 PCI-X Bridge' class = bridge subclass = PCI-PCI none6@pci3:2:1: class=0x080010 card=0x36c01022 chip=0x74511022 rev=0x01 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8131 PCI-X IOAPIC' class = base peripheral subclass = interrupt controller atapci2@pci5:3:0: class=0x018000 card=0x31141095 chip=0x31141095 rev=0x02 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'Sil 3114 SATALink/SATARaid Controller' class = mass storage amr0@pci4:1:0: class=0x010400 card=0x05231000 chip=0x19601000 rev=0x01 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' class = mass storage subclass = RAID --Boundary-00=_ccZXC3AlSJ4BH2t-- From owner-freebsd-net@FreeBSD.ORG Thu Apr 14 00:28:11 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 576C416A4CE; Thu, 14 Apr 2005 00:28:11 +0000 (GMT) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00CAC43D2F; Thu, 14 Apr 2005 00:28:10 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by aldan.algebra.com (8.13.1/8.13.1) with ESMTP id j3E0S74C019295 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Apr 2005 20:28:08 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (195-11.customer.cloud9.net [168.100.195.11])j3E0S17g074027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2005 20:28:02 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (mteterin@localhost [127.0.0.1]) by mteterin.us.murex.com (8.13.3/8.13.3) with ESMTP id j3E0S0wW064637; Wed, 13 Apr 2005 20:28:00 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by mteterin.us.murex.com (8.13.3/8.13.3/Submit) id j3E0Rxjk064636; Wed, 13 Apr 2005 20:27:59 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) X-Authentication-Warning: mteterin.us.murex.com: mteterin set sender to mi+mx@aldan.algebra.com using -f From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Q Date: Wed, 13 Apr 2005 20:27:59 -0400 User-Agent: KMail/1.7.2 References: <200504131803.08538.mi+mx@aldan.algebra.com> <7d0ce05415753151e32ccd716d820a2f@onthenet.com.au> In-Reply-To: <7d0ce05415753151e32ccd716d820a2f@onthenet.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200504132027.59726.mi+mx@aldan.algebra.com> X-Virus-Scanned: clamd / ClamAV version devel-20040615, clamav-milter version 0.73a on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 cc: amd64@FreeBSD.org cc: net@FreeBSD.org Subject: Re: nvnet does not see NVidia's adapter on amd64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 00:28:11 -0000 > > I just installed a fresh 5.4-RC2 on IWill's DK8N motherboard: > > > > ššššššhttp://www.iwillusa.com/product_2.asp?p_id=27 > > > > I transfered the net/nvnet's distfiles using a floppy and built the > > driver. > > > > Unfortunately, kldload-ing if_nv did not make the interface appear... > > Putting > > ``if_nv_load="YES"'' into loader.conf and rebooting did not help > > either. > > > > Is there anything, you can suggest for me try right off the bat? > > Try using the tarball from here http://www.onthenet.com.au/~q/nvnet Yes! That -- combined with the ftp://download1.nvidia.com/XFree86/nforce/1.0-0301/ -- worked! It currently reports the status of 100baseTX, even though, according to the switch, the connection is at 1Gb. But this is such a minor issue compared to having no network at all... Could update the net/nvnet port? When 5.4 gets released, I imagine plenty of people to be in my position... Thanks! Yours, -mi From owner-freebsd-net@FreeBSD.ORG Thu Apr 14 15:43:30 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7637316A4CE for ; Thu, 14 Apr 2005 15:43:30 +0000 (GMT) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BF9843D1D for ; Thu, 14 Apr 2005 15:43:28 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id 2B2ADE5D8; Thu, 14 Apr 2005 11:43:27 -0400 (EDT) Received: by canoe.dclg.ca (Postfix, from userid 101) id 2FBB91A0EA1; Thu, 14 Apr 2005 11:43:17 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16990.36757.26561.974023@canoe.dclg.ca> Date: Thu, 14 Apr 2005 11:43:17 -0400 To: Lars Erik Gullerud In-Reply-To: <20050413212349.P22243@electra.nolink.net> References: <425196F0.4020309@x-trader.de> <6731347a839d85db456b1c5a33bcf0b5@mac.com> <20050413171132.B96104@electra.nolink.net> <20050413181931.GA16696@diehard.n-r-g.com> <20050413212349.P22243@electra.nolink.net> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid cc: freebsd-net@freebsd.org cc: Claudio Jeker Subject: Re: FreeVRRPd project status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 15:43:30 -0000 >>>>> "Lars" == Lars Erik Gullerud writes: Lars> My point is that this very unwise decision to reuse the VRRP Lars> protocol number, makes CARP mostly undeployable for ISP Lars> datacenter environments, and hence there is an obvious need for Lars> a working VRRP implementation, it doesn't help that CARP is now Lars> available in FreeBSD, because it is not a viable alternative in Lars> a lot of scenarios. I think the origional point was that you'd need to pay Cisco a patent licence to use VRRP... which was why people stopped working on it. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-net@FreeBSD.ORG Thu Apr 14 16:04:08 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AF0B16A4CE for ; Thu, 14 Apr 2005 16:04:08 +0000 (GMT) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE9D843D5A for ; Thu, 14 Apr 2005 16:04:07 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id C31F11F271; Thu, 14 Apr 2005 18:04:06 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id AA8F26269; Thu, 14 Apr 2005 18:04:06 +0200 (CEST) Date: Thu, 14 Apr 2005 18:04:06 +0200 From: Marc Olzheim To: David Gilbert Message-ID: <20050414160406.GA5320@stack.nl> References: <425196F0.4020309@x-trader.de> <6731347a839d85db456b1c5a33bcf0b5@mac.com> <20050413171132.B96104@electra.nolink.net> <20050413181931.GA16696@diehard.n-r-g.com> <20050413212349.P22243@electra.nolink.net> <16990.36757.26561.974023@canoe.dclg.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bp/iNruPH9dso1Pn" Content-Disposition: inline In-Reply-To: <16990.36757.26561.974023@canoe.dclg.ca> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i cc: freebsd-net@freebsd.org cc: Lars Erik Gullerud cc: Claudio Jeker Subject: Re: FreeVRRPd project status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 14 Apr 2005 16:04:08 -0000 --bp/iNruPH9dso1Pn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 14, 2005 at 11:43:17AM -0400, David Gilbert wrote: > Lars> My point is that this very unwise decision to reuse the VRRP > Lars> protocol number, makes CARP mostly undeployable for ISP > Lars> datacenter environments, and hence there is an obvious need for > Lars> a working VRRP implementation, it doesn't help that CARP is now > Lars> available in FreeBSD, because it is not a viable alternative in > Lars> a lot of scenarios. >=20 > I think the origional point was that you'd need to pay Cisco a patent > licence to use VRRP... which was why people stopped working on it. Lars's point here is that is pretty stupid to prevent people from using both implementations cleanly in the same network... As in: using Cisco stuff in your net together with *BSD machines. Marc --bp/iNruPH9dso1Pn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCXpR2ezjnobFOgrERAhMZAJ9if29vDAEVRzcArfgTIAa+xmEyEwCfU7U6 SmcZJo38wcgBsKqJMs1BJcw= =D7dT -----END PGP SIGNATURE----- --bp/iNruPH9dso1Pn-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 15 04:58:22 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 295EC16A4CE for ; Fri, 15 Apr 2005 04:58:22 +0000 (GMT) Received: from lariat.org (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CD7243D1F for ; Fri, 15 Apr 2005 04:58:21 +0000 (GMT) (envelope-from brett@lariat.org) Received: (from brett@localhost) by lariat.org (8.9.3/8.9.3) id WAA07532 for net@freebsd.org; Thu, 14 Apr 2005 22:58:17 -0600 (MDT) Date: Thu, 14 Apr 2005 22:58:17 -0600 (MDT) From: Brett Glass Message-Id: <200504150458.WAA07532@lariat.org> To: net@freebsd.org Subject: BSD-licensed RADIUS server? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 04:58:22 -0000 I'm in the process of setting up a RADIUS server, and found three in the Ports collection. Of these, which do folks recommend? Is there one available that's BSD-licensed (or licensed under some other truly free license) rather than under the GNU Pernicious License? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Fri Apr 15 05:34:39 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E41E16A4CE for ; Fri, 15 Apr 2005 05:34:39 +0000 (GMT) Received: from r-dd.iij4u.or.jp (r-dd.iij4u.or.jp [210.130.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4F8143D2D for ; Fri, 15 Apr 2005 05:34:38 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from localhost (h003.p049.iij4u.or.jp [210.130.49.3]) by r-dd.iij4u.or.jp (8.11.6+IIJ/8.11.6) with ESMTP id j3F5YY805833; Fri, 15 Apr 2005 14:34:34 +0900 (JST) Date: Fri, 15 Apr 2005 14:35:21 +0900 (JST) Message-Id: <20050415.143521.57443821.Noritoshi@Demizu.ORG> From: Noritoshi Demizu To: freebsd-net@freebsd.org X-Mailer: Mew version 4.1 on Emacs 21 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: TCP MD5 Signature option handling in tcp_syncache.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 05:34:39 -0000 I'm trying to use the TCP MD5 Signature option in my TCP experiments. On a FreeBSD current box, I run a small experimental server, which just accepts a TCP connection and receives data. I have two problems. 1. When the TCP MD5 Signature option is used on a TCP connection, both the TCP Timestamps option and the TCP Window Scale option are turned off. I think the cause and the fix are as following: At line 987 in tcp_syncache.c 1.70, sc->sc_flags is overwritten by SCF_SIGNATURE. By this line, SCF_TIMESTAMP and SCF_WINSCALE are turned off. I think the operator "=" should be "|=". 987: - sc->sc_flags = SCF_SIGNATURE; 987: + sc->sc_flags |= SCF_SIGNATURE; 2. The TCP MD5 Signature option is used iff an incoming SYN has the TCP MD5 Signature option. However, RFC2385 says in section 2.0 as following. "Unlike other TCP extensions (e.g., the Window Scale option [RFC1323]), the absence of the option in the SYN,ACK segment must not cause the sender to disable its sending of signatures." I am sorry if the current behavior is intentional, but should the condition to turn on SCF_SIGNATURE be (tp->t_flags & TF_SIGNATURE)? 986: - if (to->to_flags & TOF_SIGNATURE) 986: + if (tp->t_flags & TF_SIGNATURE) Or, considering backward compatibility, should it be ((tp->t_flags & TF_SIGNATURE) || (to->to_flags & TOF_SIGNATURE))? BTW, I think the line 977 has the same problem with #1 above. Though it does not cause any practical problem at this moment, it would be safe to fix it. 977: - sc->sc_flags = SCF_NOOPT; 977: + sc->sc_flags |= SCF_NOOPT; Thank you. Regards, Noritoshi Demizu ========================================================================= << An excerpt from line 976 - 988 of tcp_syncache.c Rev 1.70 >> 976: if (tp->t_flags & TF_NOOPT) 977: sc->sc_flags = SCF_NOOPT; #ifdef TCP_SIGNATURE 979: /* 980: * If listening socket requested TCP digests, and received SYN 981: * contains the option, flag this in the syncache so that 982: * syncache_respond() will do the right thing with the SYN+ACK. 983: * XXX Currently we always record the option by default and will 984: * attempt to use it in syncache_respond(). 985: */ 986: if (to->to_flags & TOF_SIGNATURE) 987: sc->sc_flags = SCF_SIGNATURE; #endif ========================================================================= From owner-freebsd-net@FreeBSD.ORG Fri Apr 15 07:35:20 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4ABDE16A4CE; Fri, 15 Apr 2005 07:35:20 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67B5443D3F; Fri, 15 Apr 2005 07:35:19 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j3F7bbr2097250; Fri, 15 Apr 2005 10:37:37 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 29994-18; Fri, 15 Apr 2005 10:39:54 +0300 (EEST) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j3F7ba2P097247 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2005 10:37:36 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.3/8.13.3) id j3F7ZAfR089082; Fri, 15 Apr 2005 10:35:10 +0300 (EEST) (envelope-from ru) Date: Fri, 15 Apr 2005 10:35:10 +0300 From: Ruslan Ermilov To: Mikhail Teterin Message-ID: <20050415073510.GB88925@ip.net.ua> References: <200504131803.08538.mi+mx@aldan.algebra.com> <7d0ce05415753151e32ccd716d820a2f@onthenet.com.au> <200504132027.59726.mi+mx@aldan.algebra.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="opJtzjQTFsWo+cga" Content-Disposition: inline In-Reply-To: <200504132027.59726.mi+mx@aldan.algebra.com> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: Q cc: amd64@freebsd.org cc: net@freebsd.org Subject: Re: nvnet does not see NVidia's adapter on amd64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 07:35:20 -0000 --opJtzjQTFsWo+cga Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 13, 2005 at 08:27:59PM -0400, Mikhail Teterin wrote: > > > I just installed a fresh 5.4-RC2 on IWill's DK8N motherboard: > > > > > > =A0=A0=A0=A0=A0=A0http://www.iwillusa.com/product_2.asp?p_id=3D27 > > > > > > I transfered the net/nvnet's distfiles using a floppy and built the > > > driver. > > > > > > Unfortunately, kldload-ing if_nv did not make the interface appear... > > > Putting > > > ``if_nv_load=3D"YES"'' into loader.conf and rebooting did not help > > > either. > > > > > > Is there anything, you can suggest for me try right off the bat? > > > > Try using the tarball from here http://www.onthenet.com.au/~q/nvnet >=20 > Yes! That -- combined with the=20 > ftp://download1.nvidia.com/XFree86/nforce/1.0-0301/ -- worked! >=20 > It currently reports the status of 100baseTX, even though, according to t= he=20 > switch, the connection is at 1Gb. But this is such a minor issue compared= to=20 > having no network at all... >=20 > Could update the net/nvnet port? When 5.4 gets released, I imagine plenty= of=20 > people to be in my position... >=20 When 5.4 gets released, we likely will have if_nve(4) MFC'ed already. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --opJtzjQTFsWo+cga Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCX26uqRfpzJluFF4RAr4zAJsELYHpCzf6YoyPpq7YkSPoYWzMLwCghOAy WOKfm+VkWUv8axXkI76Qxto= =ibya -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 15 10:16:38 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA0CD16A4CE for ; Fri, 15 Apr 2005 10:16:38 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AD5843D54 for ; Fri, 15 Apr 2005 10:16:38 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id j3FAGaUn074003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Apr 2005 14:16:36 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.1/8.12.8) with ESMTP id j3FAGZa6061924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2005 14:16:36 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j3FAGZBk061923; Fri, 15 Apr 2005 14:16:35 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 15 Apr 2005 14:16:35 +0400 From: Gleb Smirnoff To: Nikolay Arhangelskiy Message-ID: <20050415101635.GB61665@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Nikolay Arhangelskiy , freebsd-net@freebsd.org References: <169371158984.20050413132310@mxc.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <169371158984.20050413132310@mxc.ru> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version devel-20050125, clamav-milter version 0.80ff on relay.bestcom.ru X-Virus-Status: Clean cc: freebsd-net@FreeBSD.org Subject: Re: Lots VLANs caouses ngctl to fail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 10:16:39 -0000 On Wed, Apr 13, 2005 at 01:23:10PM +0400, Nikolay Arhangelskiy wrote: N> Hello Maxim, N> N> >> I need to operate with hundreds VLANs on FreeBSD box (5.3). N> >> Using small script I create 250 VLANs, exec "ngctl list" - no N> >> problem, ngctl lists all 250 VLANs. N> >> After creating another 250 VLANs ngctl start to fail with message: N> >> N> >> ngctl: send msg: No buffer space available N> >> N> >> Is there are any limitations in ngctl on objects count? N> >> Or any kernel side limitations? N> N> MK> Increase net.graph.recvspace and net.graph.maxdgram. N> N> Very good, this solve the problem. Thank you. Anyway, there is still limit in RELENG_5. You can not obtain node listing via ngctl, if there are more than or equal to 911 nodes. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Apr 15 10:21:44 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36C2216A4CE for ; Fri, 15 Apr 2005 10:21:44 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A6B643D49 for ; Fri, 15 Apr 2005 10:21:43 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id j3FALfGX074115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Apr 2005 14:21:42 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.1/8.12.8) with ESMTP id j3FALecf062002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2005 14:21:41 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j3FALenn062001; Fri, 15 Apr 2005 14:21:40 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 15 Apr 2005 14:21:40 +0400 From: Gleb Smirnoff To: Guido van Rooij Message-ID: <20050415102140.GD61665@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Guido van Rooij , Max Laier , freebsd-net@freebsd.org References: <425196F0.4020309@x-trader.de> <200504042143.09216.max@love2party.net> <20050411125808.GA76366@gvr.gvr.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050411125808.GA76366@gvr.gvr.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version devel-20050125, clamav-milter version 0.80ff on relay.bestcom.ru X-Virus-Status: Clean cc: Max Laier cc: freebsd-net@FreeBSD.org Subject: Re: FreeVRRPd project status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 10:21:44 -0000 On Mon, Apr 11, 2005 at 02:58:08PM +0200, Guido van Rooij wrote: G> On Mon, Apr 04, 2005 at 09:43:01PM +0200, Max Laier wrote: G> > G> > Sorry, can't help with that, but if you don't need VRRP but a working G> > redundancy setup, you should look at CARP which is part of 6-CURRENT and G> > 5-STABLE since a couple of weeks and will be part of 5.4-RELEASE. G> > G> > http://www.FreeBSD.org/cgi/man.cgi?query=carp&manpath=FreeBSD+6.0-current G> G> Just read the manpage and I have one question: the manpage does not sepcify G> the default advskew value, just that 100 is slightly larger. G> Furthermore, the advskew, pass and other ifconfig options are not G> (yet) documented... Please look at updated manpage. If you have more comments, I'm open to hear them. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Apr 15 10:24:39 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9800416A4CE for ; Fri, 15 Apr 2005 10:24:39 +0000 (GMT) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBFC043D45 for ; Fri, 15 Apr 2005 10:24:38 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id j3FAOZMo074198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 15 Apr 2005 14:24:35 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.1/8.12.8) with ESMTP id j3FAOYoB062025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Apr 2005 14:24:34 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j3FAOXxr062024; Fri, 15 Apr 2005 14:24:34 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 15 Apr 2005 14:24:33 +0400 From: Gleb Smirnoff To: Lars Erik Gullerud Message-ID: <20050415102433.GE61665@cell.sick.ru> Mail-Followup-To: Gleb Smirnoff , Lars Erik Gullerud , Claudio Jeker , freebsd-net@freebsd.org References: <425196F0.4020309@x-trader.de> <6731347a839d85db456b1c5a33bcf0b5@mac.com> <20050413171132.B96104@electra.nolink.net> <20050413181931.GA16696@diehard.n-r-g.com> <20050413212349.P22243@electra.nolink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050413212349.P22243@electra.nolink.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version devel-20050125, clamav-milter version 0.80ff on relay.bestcom.ru X-Virus-Status: Clean cc: freebsd-net@FreeBSD.org cc: Claudio Jeker Subject: Re: FreeVRRPd project status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 10:24:39 -0000 On Wed, Apr 13, 2005 at 09:36:48PM +0200, Lars Erik Gullerud wrote: L> My point is that this very unwise decision to reuse the VRRP protocol L> number, makes CARP mostly undeployable for ISP datacenter environments, L> and hence there is an obvious need for a working VRRP implementation, it L> doesn't help that CARP is now available in FreeBSD, because it is not a L> viable alternative in a lot of scenarios. If this is an issue for you, then you can make a trivial hack and use another protocol number on your installations. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-net@FreeBSD.ORG Fri Apr 15 11:08:27 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6800316A4DA; Fri, 15 Apr 2005 11:08:27 +0000 (GMT) Received: from gvr.gvr.org (gvr-gw.gvr.org [80.126.103.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1708F43D64; Fri, 15 Apr 2005 11:08:26 +0000 (GMT) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id 20977C131; Fri, 15 Apr 2005 13:08:26 +0200 (CEST) Date: Fri, 15 Apr 2005 13:08:26 +0200 From: Guido van Rooij To: Gleb Smirnoff , Max Laier , freebsd-net@freebsd.org Message-ID: <20050415110826.GA52882@gvr.gvr.org> References: <425196F0.4020309@x-trader.de> <200504042143.09216.max@love2party.net> <20050411125808.GA76366@gvr.gvr.org> <20050415102140.GD61665@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050415102140.GD61665@cell.sick.ru> Subject: Re: FreeVRRPd project status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 11:08:27 -0000 On Fri, Apr 15, 2005 at 02:21:40PM +0400, Gleb Smirnoff wrote: > G> > G> Just read the manpage and I have one question: the manpage does not sepcify > G> the default advskew value, just that 100 is slightly larger. > G> Furthermore, the advskew, pass and other ifconfig options are not > G> (yet) documented... > > Please look at updated manpage. If you have more comments, I'm open > to hear them. Thanks. The carp page is much clearer after you updated it. I see you added cross references to carp in the ifconfig manpage. I think that should be enough (I'm not sure though what the correct way is: perhaps the carp specific config parameters should be mentioned explicitly in ifconfig's manpage). Thanks! -Guido From owner-freebsd-net@FreeBSD.ORG Fri Apr 15 17:38:26 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE7B416A4CE; Fri, 15 Apr 2005 17:38:26 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B44543D2F; Fri, 15 Apr 2005 17:38:26 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 8BA367A41E; Fri, 15 Apr 2005 10:38:26 -0700 (PDT) Message-ID: <425FFC12.7040500@elischer.org> Date: Fri, 15 Apr 2005 10:38:26 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Guido van Rooij References: <425196F0.4020309@x-trader.de> <200504042143.09216.max@love2party.net> <20050411125808.GA76366@gvr.gvr.org> <20050415102140.GD61665@cell.sick.ru> <20050415110826.GA52882@gvr.gvr.org> In-Reply-To: <20050415110826.GA52882@gvr.gvr.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Max Laier cc: freebsd-net@freebsd.org Subject: Re: FreeVRRPd project status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 17:38:26 -0000 Guido van Rooij wrote: >On Fri, Apr 15, 2005 at 02:21:40PM +0400, Gleb Smirnoff wrote: > > >> >> > >Thanks. The carp page is much clearer after you updated it. > >I see you added cross references to carp in the ifconfig manpage. >I think that should be enough (I'm not sure though what the correct way >is: perhaps the carp specific config parameters should be mentioned >explicitly in ifconfig's manpage). > > when I looked at it it used a lot of terms that were not defined there.. (e.g. what is "skew"?) >Thanks! > >-Guido >_______________________________________________ >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 Fri Apr 15 19:23:18 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26B5516A4CE for ; Fri, 15 Apr 2005 19:23:18 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FCF343D41 for ; Fri, 15 Apr 2005 19:23:17 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.206] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1DMWPL-0008HS-00; Fri, 15 Apr 2005 21:23:15 +0200 Received: from [84.163.231.184] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1DMWPL-0003JF-00; Fri, 15 Apr 2005 21:23:15 +0200 From: Max Laier To: freebsd-net@freebsd.org Date: Fri, 15 Apr 2005 21:23:06 +0200 User-Agent: KMail/1.8 References: <425196F0.4020309@x-trader.de> <20050415110826.GA52882@gvr.gvr.org> <425FFC12.7040500@elischer.org> In-Reply-To: <425FFC12.7040500@elischer.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7366455.Uz1f9gIfxR"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200504152123.13312.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: Julian Elischer Subject: Re: FreeVRRPd project status X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 19:23:18 -0000 --nextPart7366455.Uz1f9gIfxR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 15 April 2005 19:38, Julian Elischer wrote: > Guido van Rooij wrote: > >On Fri, Apr 15, 2005 at 02:21:40PM +0400, Gleb Smirnoff wrote: > > > >Thanks. The carp page is much clearer after you updated it. > > > >I see you added cross references to carp in the ifconfig manpage. > >I think that should be enough (I'm not sure though what the correct way > >is: perhaps the carp specific config parameters should be mentioned > >explicitly in ifconfig's manpage). > > when I looked at it it used a lot of terms that were not defined there.. > (e.g. what is "skew"?) from http://www.m-w.com/cgi-bin/dictionary?book=3DDictionary&va=3Dskew: "2 : to distort especially from a true value or symmetrical form" =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart7366455.Uz1f9gIfxR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCYBShXyyEoT62BG0RAkZUAJ0Sdu7OUm/E2FLmRcwxJEL6eFkloQCdHQYO vi59BpJbp296OdLqLFkzT9I= =CAmP -----END PGP SIGNATURE----- --nextPart7366455.Uz1f9gIfxR-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 15 21:20:18 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0AD816A4CE; Fri, 15 Apr 2005 21:20:18 +0000 (GMT) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7129843D39; Fri, 15 Apr 2005 21:20:18 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j3FLJsvM003243; Fri, 15 Apr 2005 14:19:54 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j3FLJrBA003242; Fri, 15 Apr 2005 14:19:53 -0700 (PDT) (envelope-from obrien) Date: Fri, 15 Apr 2005 14:19:53 -0700 From: "David O'Brien" To: Ruslan Ermilov Message-ID: <20050415211953.GA3205@dragon.NUXI.org> References: <200504131803.08538.mi+mx@aldan.algebra.com> <7d0ce05415753151e32ccd716d820a2f@onthenet.com.au> <200504132027.59726.mi+mx@aldan.algebra.com> <20050415073510.GB88925@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050415073510.GB88925@ip.net.ua> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i cc: Q cc: Mikhail Teterin cc: freebsd-amd64@freebsd.org cc: net@freebsd.org Subject: Re: nvnet does not see NVidia's adapter on amd64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2005 21:20:18 -0000 On Fri, Apr 15, 2005 at 10:35:10AM +0300, Ruslan Ermilov wrote: > On Wed, Apr 13, 2005 at 08:27:59PM -0400, Mikhail Teterin wrote: > > > > I just installed a fresh 5.4-RC2 on IWill's DK8N motherboard: > > > > I transfered the net/nvnet's distfiles using a floppy and built > > > > the driver. .. > > > Try using the tarball from here http://www.onthenet.com.au/~q/nvnet > > Yes! That -- combined with the > > ftp://download1.nvidia.com/XFree86/nforce/1.0-0301/ -- worked! .. > > Could update the net/nvnet port? When 5.4 gets released, I imagine > > plenty of people to be in my position... > > When 5.4 gets released, we likely will have if_nve(4) MFC'ed already. Nope. It will be a 5.5 feature. -- -- David (obrien@FreeBSD.org) From owner-freebsd-net@FreeBSD.ORG Fri Apr 15 23:18:45 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A22B816A4CE for ; Fri, 15 Apr 2005 23:18:45 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 810A143D66 for ; Fri, 15 Apr 2005 23:18:45 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 4575C7A403 for ; Fri, 15 Apr 2005 16:18:45 -0700 (PDT) Message-ID: <42604BD4.9040906@elischer.org> Date: Fri, 15 Apr 2005 16:18:44 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: cisco vpn experience? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 23:18:45 -0000 Has anyone connected a FreeBSD machine to a "cisco ipsec VPN" as exported by various Cisco routers. they have special solaris, linux and windows clients.. From owner-freebsd-net@FreeBSD.ORG Fri Apr 15 23:24:02 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20AB716A4CE for ; Fri, 15 Apr 2005 23:24:02 +0000 (GMT) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id B47FC43D41 for ; Fri, 15 Apr 2005 23:24:01 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id 010AA3BE40; Fri, 15 Apr 2005 18:24:01 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24700-01-48; Fri, 15 Apr 2005 18:24:00 -0500 (CDT) Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45]) by mailgate1b.savvis.net (Postfix) with ESMTP id CD00B3BE3A; Fri, 15 Apr 2005 18:24:00 -0500 (CDT) Received: from s228130hz1ew031.apptix-01.savvis.net ([10.146.4.28]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 18:23:50 -0500 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew031.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 18:23:45 -0500 Message-ID: <42604D00.4010401@savvis.net> Date: Fri, 15 Apr 2005 16:23:44 -0700 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040822 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <42604BD4.9040906@elischer.org> In-Reply-To: <42604BD4.9040906@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Apr 2005 23:23:45.0620 (UTC) FILETIME=[2B7A3140:01C54212] X-Virus-Scanned: amavisd-new at savvis.net cc: net@freebsd.org Subject: Re: cisco vpn experience? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 15 Apr 2005 23:24:02 -0000 Julian Elischer wrote: > Has anyone connected a FreeBSD machine to a "cisco ipsec VPN" as > exported by various Cisco routers. > > they have special solaris, linux and windows clients.. tried to play with it. no luck though. could find where to stick "group password" (or whatever its called). even looked at linux sources at one point. looked like (to me) some shim on top of ipsec. i might be wrong (it was long time ago). max From owner-freebsd-net@FreeBSD.ORG Sat Apr 16 00:13:19 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D339716A4CE for ; Sat, 16 Apr 2005 00:13:19 +0000 (GMT) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76F7143D48 for ; Sat, 16 Apr 2005 00:13:19 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id 1C74F3C12C; Fri, 15 Apr 2005 19:13:19 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12594-01-2; Fri, 15 Apr 2005 19:13:18 -0500 (CDT) Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45]) by mailgate1b.savvis.net (Postfix) with ESMTP id E648B3BE3A; Fri, 15 Apr 2005 19:13:18 -0500 (CDT) Received: from s228130hz1ew171.apptix-01.savvis.net ([10.146.4.29]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 19:13:15 -0500 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew171.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 15 Apr 2005 19:13:05 -0500 Message-ID: <42605891.5000104@savvis.net> Date: Fri, 15 Apr 2005 17:13:05 -0700 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040822 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <42604BD4.9040906@elischer.org> <42604D00.4010401@savvis.net> In-Reply-To: <42604D00.4010401@savvis.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Apr 2005 00:13:06.0131 (UTC) FILETIME=[10145230:01C54219] X-Virus-Scanned: amavisd-new at savvis.net cc: net@freebsd.org Subject: Re: cisco vpn experience? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 00:13:19 -0000 Maksim Yevmenkin wrote: > Julian Elischer wrote: > >> Has anyone connected a FreeBSD machine to a "cisco ipsec VPN" as >> exported by various Cisco routers. >> >> they have special solaris, linux and windows clients.. > > tried to play with it. no luck though. could find where to stick > "group password" (or whatever its called). even looked at linux > sources at one point. looked like (to me) some shim on top of ipsec. > i might be wrong (it was long time ago). just tried google'ing it again and http://www.unix-ag.uni-kl.de/~massar/vpnc/ came up... have not tried to actually use it, but it compliled fine max From owner-freebsd-net@FreeBSD.ORG Sat Apr 16 00:18:43 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C437516A4CE for ; Sat, 16 Apr 2005 00:18:43 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F13E43D3F for ; Sat, 16 Apr 2005 00:18:43 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 7E4AE7A41E; Fri, 15 Apr 2005 17:18:43 -0700 (PDT) Message-ID: <426059E3.5000902@elischer.org> Date: Fri, 15 Apr 2005 17:18:43 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Maksim Yevmenkin References: <42604BD4.9040906@elischer.org> <42604D00.4010401@savvis.net> <42605891.5000104@savvis.net> In-Reply-To: <42605891.5000104@savvis.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: net@freebsd.org Subject: Re: cisco vpn experience? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 00:18:43 -0000 Maksim Yevmenkin wrote: > Maksim Yevmenkin wrote: > >> Julian Elischer wrote: >> >>> Has anyone connected a FreeBSD machine to a "cisco ipsec VPN" as >>> exported by various Cisco routers. >>> >>> they have special solaris, linux and windows clients.. >> >> >> tried to play with it. no luck though. could find where to stick >> "group password" (or whatever its called). even looked at linux >> sources at one point. looked like (to me) some shim on top of ipsec. >> i might be wrong (it was long time ago). > > > just tried google'ing it again and > > http://www.unix-ag.uni-kl.de/~massar/vpnc/ > > came up... have not tried to actually use it, but it compliled fine yeah I found that. It's a port/package too.. I'm hoping it will do the trick for me though it seems a shame that we have to use a linux-based userland program when we have ipsec in the kernel. > > max From owner-freebsd-net@FreeBSD.ORG Sat Apr 16 03:53:36 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5042416A4CE for ; Sat, 16 Apr 2005 03:53:36 +0000 (GMT) Received: from nostrum.com (magus.nostrum.com [69.5.195.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A675243D55 for ; Sat, 16 Apr 2005 03:53:35 +0000 (GMT) (envelope-from dave@duchscher.com) Received: from [10.1.5.3] (ip70-186-96-108.ma.dl.cox.net [70.186.96.108]) (authenticated bits=0) by nostrum.com (8.12.11/8.12.11) with ESMTP id j3G3rOOQ042249 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 15 Apr 2005 22:53:27 -0500 (CDT) (envelope-from dave@duchscher.com) In-Reply-To: <426059E3.5000902@elischer.org> References: <42604BD4.9040906@elischer.org> <42604D00.4010401@savvis.net> <42605891.5000104@savvis.net> <426059E3.5000902@elischer.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-24928999; protocol="application/pkcs7-signature" Message-Id: <558fd238cf8728f9b87cb54a4092039f@duchscher.com> From: David Duchscher Date: Fri, 15 Apr 2005 22:53:18 -0500 To: Julian Elischer X-Mailer: Apple Mail (2.619.2) Received-SPF: pass (nostrum.com: 70.186.96.108 is authenticated by a trusted mechanism) X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: net@freebsd.org Subject: Re: cisco vpn experience? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 03:53:36 -0000 --Apple-Mail-1-24928999 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed On Apr 15, 2005, at 7:18 PM, Julian Elischer wrote: > > > Maksim Yevmenkin wrote: > >> Maksim Yevmenkin wrote: >> >>> Julian Elischer wrote: >>> >>>> Has anyone connected a FreeBSD machine to a "cisco ipsec VPN" as >>>> exported by various Cisco routers. >>>> >>>> they have special solaris, linux and windows clients.. >>> >>> >>> tried to play with it. no luck though. could find where to stick >>> "group password" (or whatever its called). even looked at linux >>> sources at one point. looked like (to me) some shim on top of ipsec. >>> i might be wrong (it was long time ago). >> >> >> just tried google'ing it again and >> >> http://www.unix-ag.uni-kl.de/~massar/vpnc/ >> >> came up... have not tried to actually use it, but it compliled fine > > yeah I found that. > > It's a port/package too.. > > I'm hoping it will do the trick for me though it seems a shame that we > have to use a > linux-based userland program when we have ipsec in the kernel. > I found this: http://ipsec-tools.sourceforge.net/ Was pointed to by this message: http://www.freebsdforums.com/forums/showthread.php?threadid=30092 and buried inside the src/racoon/samples/roadwarrior/README under 'Client setup' it says: This configuration should be compatible with the Cisco VPN 3000 using hybrid authentication, though this has not been tested. Hope this helps, -- DaveD --Apple-Mail-1-24928999-- From owner-freebsd-net@FreeBSD.ORG Sat Apr 16 12:18:12 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7342316A4CF for ; Sat, 16 Apr 2005 12:18:12 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [83.167.185.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDB9343D45 for ; Sat, 16 Apr 2005 12:18:11 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id F24D2651F7; Sat, 16 Apr 2005 13:17:44 +0100 (BST) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 80819-03; Sat, 16 Apr 2005 13:17:44 +0100 (BST) Received: from empiric.dek.spc.org (66-117-149-249.rdsl.lmi.net [66.117.149.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id BCF53651F4; Sat, 16 Apr 2005 13:17:43 +0100 (BST) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id 2185C616D; Sat, 16 Apr 2005 05:18:03 -0700 (PDT) Date: Sat, 16 Apr 2005 05:18:03 -0700 From: Bruce M Simpson To: Noritoshi Demizu Message-ID: <20050416121802.GB5452@empiric.icir.org> Mail-Followup-To: Noritoshi Demizu , freebsd-net@freebsd.org References: <20050415.143521.57443821.Noritoshi@Demizu.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050415.143521.57443821.Noritoshi@Demizu.ORG> cc: freebsd-net@freebsd.org Subject: Re: TCP MD5 Signature option handling in tcp_syncache.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 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, 16 Apr 2005 12:18:12 -0000 On Fri, Apr 15, 2005 at 02:35:21PM +0900, Noritoshi Demizu wrote: > 2. The TCP MD5 Signature option is used iff an incoming SYN has the > TCP MD5 Signature option. However, RFC2385 says in section 2.0 > as following. > > "Unlike other TCP extensions (e.g., the Window Scale option > [RFC1323]), the absence of the option in the SYN,ACK segment must not > cause the sender to disable its sending of signatures." > > I am sorry if the current behavior is intentional, but should the > condition to turn on SCF_SIGNATURE be (tp->t_flags & TF_SIGNATURE)? We can't make this change until we fix how security policy is implemented for listening sockets, otherwise we end up in a situation where for example a BGP listener can *only* accept MD5 sessions. Thank you for the other suggested fixes, I will try to review them in more depth when I have free time. BMS From owner-freebsd-net@FreeBSD.ORG Sat Apr 16 17:02:01 2005 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC7A916A4CF for ; Sat, 16 Apr 2005 17:02:01 +0000 (GMT) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DAB543D2D for ; Sat, 16 Apr 2005 17:02:00 +0000 (GMT) (envelope-from bsdfreak@gmail.com) Received: by zproxy.gmail.com with SMTP id 34so1121695nzf for ; Sat, 16 Apr 2005 10:02:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KvErr+r+QmcnfxGREZCm4onDTlwKUIz8T0AodnXdvBG14NNu3kZI5/rchmL3gKL1YPId0uC9PQgaLQZ0btK0gjR5tpvc6216kKwDZCpNhIfsR/xXsVE34Ho7GwpGu980ap7DI/4RyB0k34ylhIk7z4aEfDM5SVWxtOCWcGi+HSU= Received: by 10.36.22.7 with SMTP id 7mr261631nzv; Sat, 16 Apr 2005 10:02:00 -0700 (PDT) Received: by 10.36.7.11 with HTTP; Sat, 16 Apr 2005 10:02:00 -0700 (PDT) Message-ID: Date: Sat, 16 Apr 2005 13:02:00 -0400 From: Alexander Chamandy To: obrien@freebsd.org In-Reply-To: <20050415211953.GA3205@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200504131803.08538.mi+mx@aldan.algebra.com> <7d0ce05415753151e32ccd716d820a2f@onthenet.com.au> <200504132027.59726.mi+mx@aldan.algebra.com> <20050415073510.GB88925@ip.net.ua> <20050415211953.GA3205@dragon.NUXI.org> cc: Q cc: Mikhail Teterin cc: freebsd-amd64@freebsd.org cc: net@freebsd.org Subject: Re: nvnet does not see NVidia's adapter on amd64 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Alexander Chamandy List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2005 17:02:01 -0000 On 4/15/05, David O'Brien wrote: > On Fri, Apr 15, 2005 at 10:35:10AM +0300, Ruslan Ermilov wrote: > > On Wed, Apr 13, 2005 at 08:27:59PM -0400, Mikhail Teterin wrote: > > > > > I just installed a fresh 5.4-RC2 on IWill's DK8N motherboard: > > > > > I transfered the net/nvnet's distfiles using a floppy and built > > > > > the driver. > .. > > > > Try using the tarball from here http://www.onthenet.com.au/~q/nvnet > > > Yes! That -- combined with the > > > ftp://download1.nvidia.com/XFree86/nforce/1.0-0301/ -- worked! > .. > > > Could update the net/nvnet port? When 5.4 gets released, I imagine > > > plenty of people to be in my position... > > > > When 5.4 gets released, we likely will have if_nve(4) MFC'ed already. >=20 > Nope. It will be a 5.5 feature. The nvnet port works fine for my onboard Ethernet on my Gigabyte K8NNXP w/Athlon 3200+ CPU. >=20 > -- > -- David (obrien@FreeBSD.org) > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64-unsubscribe@freebsd.org" >=20 --=20 Best wishes, Alexander G. Chamandy Webmaster www.bsdfreak.org Your Source For BSD News!