From owner-freebsd-net@FreeBSD.ORG Sun Oct 22 03:39:55 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 4D2CC16A407 for ; Sun, 22 Oct 2006 03:39:55 +0000 (UTC) (envelope-from prvs=julian=44322f810@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 109ED43D60 for ; Sun, 22 Oct 2006 03:39:54 +0000 (GMT) (envelope-from prvs=julian=44322f810@elischer.org) Received: from unknown (HELO [192.168.2.5]) ([10.251.60.42]) by a50.ironport.com with ESMTP; 21 Oct 2006 20:39:54 -0700 Message-ID: <453AE809.4030107@elischer.org> Date: Sat, 21 Oct 2006 20:39:53 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Max Laier References: <453977CA.8020807@elischer.org> <200610210358.51403.max@love2party.net> In-Reply-To: <200610210358.51403.max@love2party.net> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: more on pfil and bridging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 03:39:55 -0000 Max Laier wrote: > On Saturday 21 October 2006 03:28, Julian Elischer wrote: >> The more I look at this the more I think that it is broken. >> >> Instead of the bridge registering a separate filter queue for itself, >> it is using the queues set up by the IP stack. >> >> It should register its own stack and each filter type should >> register their own filter functions for that level on the stack. >> >> is there a reason that this is not done? If the answer is simply >> ENOTIME then I will volunteer to go through it and do it properly. > > I guess so. > >> suggested changes: >> >> I propose to create filter queues for if_ethersubr.c and if_bridge.c >> distinguished by slightly different keys. I also propose to rename >> inet_pfil_hook to be inet_pfil_head (or inet_pfil_hooks). >> >> I would also look at following the documentation by seeing whether >> we shouldn't be using a DLT/KEY instead of PFIL_AF and AF_INET >> as the key type/key. > > I think if_ethersubr.c and if_bridge.c should pass to the same pfil hook. > And I'd vote for the current - very sophisticated - if_bridge.c filtering > to stay, at least as opt-in. Otherwise it will be tricky to support > stateful filtering in pf on transparent bridges. Ather and bridge need to be distinguishable. Believe me. I do this in a product and I need to tell them apart. > >> The Direction argument should be expanded to be a generic 'flags' >> argument where two of the flags are direction. >> Other flags can be: >> WAIT_OK: (It's already defined to be there) >> HOST_ORDER: Fields in the header have been swapped to host order. >> >> The ipfw code would supply different entry points for bridge >> and Ethernet supplied packets. >> >> the ipfw args struct should grow a 'flags' field that can >> indicate (for example) that the IP header fields have not been >> put in host order (or have) and that the packet is from a bridge >> rather than just being layer2. >> >> ipfw would grow a 'bridge' keyword to check that flag. > > I don't think that is necessary. Right now we also have a mode to pass > bridged packets as "normal" L2 packets. ipfw doesn't discriminate > between packets from if_ethersubr.c and if_bridge.c - and I don't see why > it should. If discrimination is required one can still fall back on the > L3decap in if_bridge.c - see above. I really need to distinguish between the two cases. > From owner-freebsd-net@FreeBSD.ORG Sun Oct 22 03:50:31 2006 Return-Path: X-Original-To: net@freebsd.org 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 2A23D16A415 for ; Sun, 22 Oct 2006 03:50:31 +0000 (UTC) (envelope-from prvs=julian=44322f810@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAC9C43D45 for ; Sun, 22 Oct 2006 03:50:30 +0000 (GMT) (envelope-from prvs=julian=44322f810@elischer.org) Received: from unknown (HELO [192.168.2.5]) ([10.251.60.42]) by a50.ironport.com with ESMTP; 21 Oct 2006 20:50:30 -0700 Message-ID: <453AEA86.4070103@elischer.org> Date: Sat, 21 Oct 2006 20:50:30 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Brett Glass References: <200610210648.AAA01737@lariat.net> In-Reply-To: <200610210648.AAA01737@lariat.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Avoiding natd overhead X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 03:50:31 -0000 Brett Glass wrote: > I'm working with a FreeBSD-based router that's using IPFW for policy > routing, traffic shaping, and transparent proxying and natd for network > address translation. IPFW does these things pretty well (in fact, I > don't know if another firewall, like pf, could even do some of these > things I'm doing with IPFW), but natd is by far the most CPU-intensive > process on the system and is causing it to crumple like a wet towel > under heavy loads. How can I replace just the functionality of natd > without moving to an entirely new firewall? Can I still select which > packets are routed to the NAT engine, and when this occurs during the > processing of the packet? > > --Brett Glass one thing that you need to name sure of is that only the packets that have potential of being on interest to natd are passed to natd. i.e. be VERY specific in your natd rules.. ipfw add 1000 divert natd ip from any to any out recv {inner-ineterface} xmit {outer-interface}. ipfw add 1001 divert natd ip from any to {inner-interface-address} in recv {outer-interface}. don't waste natd's time with packets it doesn't care about. > > _______________________________________________ > 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 Sun Oct 22 04:00:07 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 CD3EA16A47C for ; Sun, 22 Oct 2006 04:00:06 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B70943D53 for ; Sun, 22 Oct 2006 04:00:06 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20061022040004m9100ek9b5e>; Sun, 22 Oct 2006 04:00:04 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id k9M402V1025735; Sat, 21 Oct 2006 23:00:02 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id k9M400dr025715; Sat, 21 Oct 2006 23:00:00 -0500 (CDT) (envelope-from brooks) Date: Sat, 21 Oct 2006 23:00:00 -0500 From: Brooks Davis To: Peter Ankerst?l Message-ID: <20061022040000.GA25640@lor.one-eyed-alien.net> References: <453A9851.4070101@pean.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <453A9851.4070101@pean.org> User-Agent: Mutt/1.5.11 Cc: freebsd-net@freebsd.org Subject: Re: Sub-interfaces. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 04:00:07 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 21, 2006 at 11:59:45PM +0200, Peter Ankerst?l wrote: > I've looked all over the web for some tutorials on how to create=20 > sub-interfaces i FreeBSD.. > Something like fxp0.1 >=20 > Should I use ng_ ? If you mean vlan interfaces, "ifconfig fxp0.1 create" should actually work if the vlan module is loaded or compiled in. -- Brooks --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFOuy/XY6L6fI4GtQRAmY8AJ9dETau9ee6KGqe0J0WN3ghWMh9cwCg4hpk EGaUGabJTNYZCgn4xBhnyk8= =WVcJ -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From owner-freebsd-net@FreeBSD.ORG Sun Oct 22 04:14:21 2006 Return-Path: X-Original-To: net@freebsd.org 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 B0BC516A407 for ; Sun, 22 Oct 2006 04:14:21 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20BDC43D45 for ; Sun, 22 Oct 2006 04:14:20 +0000 (GMT) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id WAA15541; Sat, 21 Oct 2006 22:14:14 -0600 (MDT) Message-Id: <200610220414.WAA15541@lariat.net> X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 21 Oct 2006 22:13:18 -0600 To: Julian Elischer From: Brett Glass In-Reply-To: <453AEA86.4070103@elischer.org> References: <200610210648.AAA01737@lariat.net> <453AEA86.4070103@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-516E617 Cc: net@freebsd.org Subject: Re: Avoiding natd overhead X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 04:14:21 -0000 At 09:50 PM 10/21/2006, Julian Elischer wrote: >one thing that you need to name sure of is that only the packets >that have potential of being on interest to natd are passed to natd. I do. In fact, this is a capability I would lose if I used ipfilters or pf to do NAT, which is why I want to find a way to use a mechanism that's triggered by IPFW. You were the person who invented "divert sockets," were you not? How hard would it be to create a mechanism (a sort of "kernel divert socket") so that kernel modules and/or netgraph nodes could do the same things which are now done by userland processes listening on divert sockets? This would boost the performance of any FreeBSD machine that did NAT (which many if not most do). --Brett Glass From owner-freebsd-net@FreeBSD.ORG Sun Oct 22 04:21:20 2006 Return-Path: X-Original-To: net@freebsd.org 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 368B216A492 for ; Sun, 22 Oct 2006 04:21:17 +0000 (UTC) (envelope-from prvs=julian=44322f810@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 035DE43D45 for ; Sun, 22 Oct 2006 04:21:16 +0000 (GMT) (envelope-from prvs=julian=44322f810@elischer.org) Received: from unknown (HELO [192.168.2.5]) ([10.251.60.42]) by a50.ironport.com with ESMTP; 21 Oct 2006 21:21:16 -0700 Message-ID: <453AF1BB.7070507@elischer.org> Date: Sat, 21 Oct 2006 21:21:15 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Brett Glass References: <200610210648.AAA01737@lariat.net> <453AEA86.4070103@elischer.org> <200610220414.WAA15541@lariat.net> In-Reply-To: <200610220414.WAA15541@lariat.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Avoiding natd overhead X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 04:21:20 -0000 Brett Glass wrote: > At 09:50 PM 10/21/2006, Julian Elischer wrote: > >> one thing that you need to name sure of is that only the packets that >> have potential of being on interest to natd are passed to natd. > > I do. In fact, this is a capability I would lose if I used ipfilters or > pf to do NAT, which is why I want to find a way to use a mechanism > that's triggered by IPFW. > > You were the person who invented "divert sockets," were you not? How > hard would it be to create a mechanism (a sort of "kernel divert > socket") so that kernel modules and/or netgraph nodes could do the same > things which are now done by userland processes listening on divert > sockets? This would boost the performance of any FreeBSD machine that > did NAT (which many if not most do). you can in two ways.. create a netgraph ksocket node of type divert then attach that to a netgraph ng_nat node. OR in 7.0 you can call netgraph directly there is a netgraph keyword in ipfw. > > --Brett Glass > From owner-freebsd-net@FreeBSD.ORG Sun Oct 22 14:09:31 2006 Return-Path: X-Original-To: net@freebsd.org 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 F13B016A412 for ; Sun, 22 Oct 2006 14:09:31 +0000 (UTC) (envelope-from flag@newluxor.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FFC243D49 for ; Sun, 22 Oct 2006 14:09:30 +0000 (GMT) (envelope-from flag@newluxor.wired.org) Received: from newluxor.wired.org (ip-64-88.sn2.eutelia.it [83.211.64.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id 3D41F11AE43; Sun, 22 Oct 2006 16:09:28 +0200 (CEST) Received: (from flag@localhost) by newluxor.wired.org (8.13.8/8.13.8/Submit) id k9ME9Eu6064581; Sun, 22 Oct 2006 16:09:14 +0200 (CEST) (envelope-from flag) Date: Sun, 22 Oct 2006 16:09:08 +0200 From: Paolo Pisati To: "Matthew D. Fuller" Message-ID: <20061022140908.GA1275@tin.it> References: <200610210648.AAA01737@lariat.net> <20061021095808.GH75501@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061021095808.GH75501@over-yonder.net> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: net@freebsd.org Subject: Re: Avoiding natd overhead X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 14:09:32 -0000 On Sat, Oct 21, 2006 at 04:58:08AM -0500, Matthew D. Fuller wrote: > On Sat, Oct 21, 2006 at 12:47:54AM -0600 I heard the voice of > Brett Glass, and lo! it spake thus: > > > > How can I replace just the functionality of natd without moving to > > an entirely new firewall? Can I still select which packets are > > routed to the NAT engine, and when this occurs during the processing > > of the packet? > > Paolo Pisati's 2005 SoC work on integrating libalias into ipfw might > fit here. It should move the NAT'ing into the kernel and save all the > context switches and copies, and (what has me more interested) make it > much easier to change port forwarding and other rules. The worst > thing about natd for me isn't performance, it's that I have to blow > away all the state to change anything. > > I think some of the support has been brought in, at least to -CURRENT, > but I'm not sure, and I'm pretty sure it isn't in RELENG_6 or earlier. > Paolo? i've imported in CURRENT the libalias side of work (mainly modules), while for the ipfw part (nat&c), there are two things still to talk about: 1) locking of libalias: put an embedded lock into libalias and grab it into the different LibAlias* functions? or leave it outside the library? 2) libalias+nat in kernel: Glebius suggested to make the nat part truly independent through ipfw_nat.ko. libalias+ipfw nat add 80kb to the entire kernel. bye -- Paolo Piso's first law: nothing works as expected! From owner-freebsd-net@FreeBSD.ORG Sun Oct 22 16:00:22 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 932F116A47B for ; Sun, 22 Oct 2006 16:00:22 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0328A43D46 for ; Sun, 22 Oct 2006 16:00:16 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp2-g19.free.fr (Postfix) with ESMTP id 5B60675C12; Sun, 22 Oct 2006 18:00:16 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id A719E9E6C2; Sun, 22 Oct 2006 16:01:03 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 922AC405B; Sun, 22 Oct 2006 18:01:03 +0200 (CEST) Date: Sun, 22 Oct 2006 18:01:03 +0200 From: Jeremie Le Hen To: Raymond Wagner Message-ID: <20061022160103.GX53114@obiwan.tataz.chchile.org> References: <20061016061255.CNQK10743.gx6.fuse.net@raymond2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061016061255.CNQK10743.gx6.fuse.net@raymond2> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-net@freebsd.org Subject: Re: [fbsd] Virtual Network Interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 16:00:22 -0000 Hi Raymond, On Mon, Oct 16, 2006 at 02:12:47AM -0400, Raymond Wagner wrote: > My ISP provides me up to 5 dynamically assigned addresses out of a /20 > block. I have more than 5 machines on my network, so I have no choice but > to run NAT, however I would like to force two of those machines onto their > own external addresses. If I had static addresses, I could simply alias the > addresses into the external interface and then use "binat" in pf to redirect > the traffic. However, the addresses have to be requested from the DHCP > server, and expire after 4 hours. > > I can get this to work by running the NAT function under QEMU and just > giving the virtual machine several interfaces bridged to the physical > external interface. Running a VM is far from ideal. Is there any way I > could set up a virtual network interface that could be bridged to the true > interface and grab its own DHCP address? I don't know if that works, but I would try the following setup. Supposing you have two physical interaces, an external one (ext0) and an internal one (int0), I would create a VLAN on int0 for each machine which have to have its own public address (vlan1 and vlan2) and bridge { ext0, vlan1, vlan2 }. On Linux, there is an interesting feature that, once two interfaces are bridged, you can use a tool called "ebtables" to select if a packet is going to be bridged or routed, depending on layer 2 and layer 3 informations. (See http://ebtables.sourceforge.net/ebtables-man.html) Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Sun Oct 22 16:18:44 2006 Return-Path: X-Original-To: net@freebsd.org 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 7D44116A415 for ; Sun, 22 Oct 2006 16:18:44 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92FF343D5C for ; Sun, 22 Oct 2006 16:18:41 +0000 (GMT) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id KAA21897; Sun, 22 Oct 2006 10:18:35 -0600 (MDT) Message-Id: <200610221618.KAA21897@lariat.net> X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 22 Oct 2006 10:18:27 -0600 To: Julian Elischer From: Brett Glass In-Reply-To: <453AF1BB.7070507@elischer.org> References: <200610210648.AAA01737@lariat.net> <453AEA86.4070103@elischer.org> <200610220414.WAA15541@lariat.net> <453AF1BB.7070507@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-avg-checked=avg-ok-516E617 Cc: net@freebsd.org Subject: Re: Avoiding natd overhead X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 16:18:44 -0000 At 10:21 PM 10/21/2006, Julian Elischer wrote: >you can in two ways.. > >create a netgraph ksocket node of type divert >then attach that to a netgraph ng_nat node. > >OR in 7.0 you can call netgraph directly > >there is a netgraph keyword in ipfw. How would one create and control the ng_nat node from the shell? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Sun Oct 22 22:23:03 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 204DA16A403 for ; Sun, 22 Oct 2006 22:23:03 +0000 (UTC) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (unsane.co.uk [62.140.220.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46C3B43D77 for ; Sun, 22 Oct 2006 22:22:59 +0000 (GMT) (envelope-from jhary@unsane.co.uk) Received: from unsane.co.uk (localhost [127.0.0.1]) by unsane.co.uk (8.13.7/8.13.3) with ESMTP id k9MMMvFA010498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 Oct 2006 23:22:57 +0100 (BST) (envelope-from jhary@unsane.co.uk) Received: from localhost (jhary@localhost) by unsane.co.uk (8.13.7/8.13.3/Submit) with ESMTP id k9MMMu1q010495; Sun, 22 Oct 2006 23:22:57 +0100 (BST) (envelope-from jhary@unsane.co.uk) Date: Sun, 22 Oct 2006 23:22:56 +0100 (BST) From: Vince Hoffman To: =?ISO-8859-1?Q?Peter_Ankerst=E5l?= In-Reply-To: <453A9851.4070101@pean.org> Message-ID: <20061022230647.V9913@unsane.co.uk> References: <453A9851.4070101@pean.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1191901226-1161555317=:9913" Content-ID: <20061022231816.R9913@unsane.co.uk> Cc: freebsd-net@freebsd.org Subject: Re: Sub-interfaces. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Oct 2006 22:23:03 -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-1191901226-1161555317=:9913 Content-Type: TEXT/PLAIN; CHARSET=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: <20061022231816.U9913@unsane.co.uk> On Sat, 21 Oct 2006, Peter Ankerst=E5l wrote: > I've looked all over the web for some tutorials on how to create=20 > sub-interfaces i FreeBSD.. > Something like fxp0.1 Do you mean just additional addresses on an interface like http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-virt= ual-hosts.html this doesnt give the command line which would=20 be ifconfig fxp0 alias 1.2.3.4/24 if you wished to add a new address of 1.2.3.4 with a 24 bit netmask to=20 your fxp0 interface. otherwise if you mean something more like a cisco subinterface on a=20 specific vlan, load the vlan module if needed, then ifconfig fxp0.1 create should create a subinterface like fxp0.1: flags=3D8842 mtu 1500 ether 00:50:8b:03:6d:00 media: Ethernet 100baseTX status: active vlan: 1 parent interface: fxp0 Vince > > Should I use ng_ ? > _______________________________________________ > 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" > --0-1191901226-1161555317=:9913-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 23 00:35:34 2006 Return-Path: X-Original-To: net@freebsd.org 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 20B3316A412 for ; Mon, 23 Oct 2006 00:35:34 +0000 (UTC) (envelope-from joe@joeholden.co.uk) Received: from claire.ber.rewt.org.uk (claire.ber.rewt.org.uk [217.160.200.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id A848143D45 for ; Mon, 23 Oct 2006 00:35:33 +0000 (GMT) (envelope-from joe@joeholden.co.uk) Received: from localhost (localhost [127.0.0.1]) by claire.ber.rewt.org.uk (Postfix) with ESMTP id 1E0A7140036B for ; Mon, 23 Oct 2006 01:35:32 +0100 (BST) X-Virus-Scanned: Scanned at claire.ber.rewt.org.uk Received: from claire.ber.rewt.org.uk ([127.0.0.1]) by localhost (claire.ber.rewt.org.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO-fYEmlaqDO for ; Mon, 23 Oct 2006 01:35:24 +0100 (BST) Received: from [82.152.108.189] (dyn189.stf.rewt.org.uk [82.152.108.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: joe) by claire.ber.rewt.org.uk (Postfix) with ESMTP id D0FFB1400343 for ; Mon, 23 Oct 2006 01:35:23 +0100 (BST) Message-ID: <453C0E42.4010604@joeholden.co.uk> Date: Mon, 23 Oct 2006 01:35:14 +0100 From: Joe Holden User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Instructing dhclient to set hostname of client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joe@joeholden.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 00:35:34 -0000 Hi all, Is it possible to get dhclient to resolve the ip its been given, and set that as the hostname? (6.2-PRE) Ta, J From owner-freebsd-net@FreeBSD.ORG Mon Oct 23 05:30:55 2006 Return-Path: X-Original-To: net@freebsd.org 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 B452816A40F for ; Mon, 23 Oct 2006 05:30:55 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id C909143D5D for ; Mon, 23 Oct 2006 05:30:50 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 12295 invoked by uid 399); 23 Oct 2006 05:30:50 -0000 Received: from localhost (HELO ?192.168.0.4?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 23 Oct 2006 05:30:50 -0000 Message-ID: <453C5386.5080102@FreeBSD.org> Date: Sun, 22 Oct 2006 22:30:46 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: joe@joeholden.co.uk References: <453C0E42.4010604@joeholden.co.uk> In-Reply-To: <453C0E42.4010604@joeholden.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Instructing dhclient to set hostname of client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 05:30:55 -0000 Joe Holden wrote: > Hi all, > > Is it possible to get dhclient to resolve the ip its been given, and set > that as the hostname? (6.2-PRE) For future reference, this really belongs on freebsd-questions. If you know for sure that the DHCP server is going to send you a hostname, then you can put this in your /etc/dhclient.conf: request subnet-mask, routers, broadcast-address, domain-name, host-name, domain-name-servers; (obviously those aren't all related to your hostname, but probably a good idea anyway). If you're talking about a laptop where you're not sure what the DHCP server is going to send you, then I have this in /etc/rc.local: for ip in `ifconfig | awk '/inet / {print $2}'`; do case "${ip}" in 127.0.0.1|0.0.0.0) ;; *) newhost=`host ${ip} | cut -f5 -d ' '` case "${newhost}" in ''|*NXDOMAIN*) ;; *\.*) hostname ${newhost%.} sleep 1 break ;; esac ;; esac done Combine that with a default hostname in /etc/rc.conf[.local] and you're good to go. hth, Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Mon Oct 23 05:50:52 2006 Return-Path: X-Original-To: net@freebsd.org 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 9802B16A417 for ; Mon, 23 Oct 2006 05:50:52 +0000 (UTC) (envelope-from vova@sw.ru) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB09843D4C for ; Mon, 23 Oct 2006 05:50:48 +0000 (GMT) (envelope-from vova@sw.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gbc46-0000XM-5R; Sun, 22 Oct 2006 16:04:30 +0400 From: Vladimir Grebenschikov To: Brett Glass In-Reply-To: <200610212208.QAA11801@lariat.net> References: <200610210648.AAA01737@lariat.net> <1161424493.1489.10.camel@localhost> <200610212208.QAA11801@lariat.net> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Sun, 22 Oct 2006 16:04:02 +0400 Message-Id: <1161518642.1455.15.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: net@freebsd.org Subject: Re: Avoiding natd overhead X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 05:50:52 -0000 =F7 =D3=C2, 21/10/2006 =D7 16:08 -0600, Brett Glass =D0=C9=DB=C5=D4: > At 03:54 AM 10/21/2006, Vladimir Grebenschikov wrote: > =20 > > 1. use PF for nat - it does aliasing in kernel space >=20 > True, but it doesn't let me translate the packets and > then continue processing within the firewall -- which > is necessary if you want to catch unregistered destination > addresses BEFORE translation and then unregistered source > addresses AFTER translation. >=20 > > 2. use in-kernel libalias implementation=20 > > (I guess man-page for ng_nat(4) will help) >=20 > Same problem. I don't know how I could send packets > through a Netgraph node in the middle of processing > by IPFW and then bring them back at the next rule. Some years ago, I've managed to use ksocket interface to catch divert packets from ipfw and even return them back (surprisingly it did support divert AF). But, be careful, it is easy to get infinite loop in kernel with this technique. Probably some loop prevention appears in from these times, but I am not sure. > I suppose that one solution might be, for lack of a > better term, a "kernel divert socket," which would > pass packets through a kernel module rather than a > user process. (This could actually be used to speed > up many things for which the current "userland" > divert sockets are now used.) It would then be > possible to make a "nat.ko" module, and either > provide a utility to control it or roll that > functionality into ipfw(8). >=20 > --Brett=20 >=20 --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-net@FreeBSD.ORG Mon Oct 23 05:56:25 2006 Return-Path: X-Original-To: net@freebsd.org 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 41A7016A403; Mon, 23 Oct 2006 05:56:25 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mx18.yandex.ru (smtp2.yandex.ru [213.180.200.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4617543D62; Mon, 23 Oct 2006 05:56:22 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from ns.kirov.so-cdu.ru ([81.18.142.225]:18182 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S3375999AbWJWF4N (ORCPT + 1 other); Mon, 23 Oct 2006 09:56:13 +0400 X-Comment: RFC 2476 MSA function at smtp2.yandex.ru logged sender identity as: bu7cher Message-ID: <453C5979.4050408@yandex.ru> Date: Mon, 23 Oct 2006 09:56:09 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Doug Barton References: <453C0E42.4010604@joeholden.co.uk> <453C5386.5080102@FreeBSD.org> In-Reply-To: <453C5386.5080102@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Instructing dhclient to set hostname of client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 05:56:25 -0000 Doug Barton wrote: > If you're talking about a laptop where you're not sure what the DHCP > server is going to send you, then I have this in /etc/rc.local: Hi, Doug. What you think about adding a new feature to dhclient - Alternate IP Configuration. This configuration can be specified in dhclient.conf and take effect when a DHCP server not respond. MS Windows have a similar feature. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Mon Oct 23 06:15:03 2006 Return-Path: X-Original-To: net@freebsd.org 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 1E3A616A412 for ; Mon, 23 Oct 2006 06:15:03 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71FF443D46 for ; Mon, 23 Oct 2006 06:15:02 +0000 (GMT) (envelope-from dudu@dudu.ro) Received: by py-out-1112.google.com with SMTP id c59so59006pyc for ; Sun, 22 Oct 2006 23:15:01 -0700 (PDT) Received: by 10.65.234.3 with SMTP id l3mr4733761qbr; Sun, 22 Oct 2006 23:08:13 -0700 (PDT) Received: by 10.65.110.19 with HTTP; Sun, 22 Oct 2006 23:08:13 -0700 (PDT) Message-ID: Date: Mon, 23 Oct 2006 09:08:13 +0300 From: "Vlad Galu" To: net@freebsd.org In-Reply-To: <1161518642.1455.15.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline References: <200610210648.AAA01737@lariat.net> <1161424493.1489.10.camel@localhost> <200610212208.QAA11801@lariat.net> <1161518642.1455.15.camel@localhost> Cc: Subject: Re: Avoiding natd overhead X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 06:15:03 -0000 T24gMTAvMjIvMDYsIFZsYWRpbWlyIEdyZWJlbnNjaGlrb3YgPHZvdmFAZmJzZC5ydT4gd3JvdGU6 Cj4g9yDTwiwgMjEvMTAvMjAwNiDXIDE2OjA4IC0wNjAwLCBCcmV0dCBHbGFzcyDQydvF1DoKPiA+ IEF0IDAzOjU0IEFNIDEwLzIxLzIwMDYsIFZsYWRpbWlyIEdyZWJlbnNjaGlrb3Ygd3JvdGU6Cj4g Pgo+ID4gPiAxLiB1c2UgUEYgZm9yIG5hdCAtIGl0IGRvZXMgYWxpYXNpbmcgaW4ga2VybmVsIHNw YWNlCj4gPgo+ID4gVHJ1ZSwgYnV0IGl0IGRvZXNuJ3QgbGV0IG1lIHRyYW5zbGF0ZSB0aGUgcGFj a2V0cyBhbmQKPiA+IHRoZW4gY29udGludWUgcHJvY2Vzc2luZyB3aXRoaW4gdGhlIGZpcmV3YWxs IC0tIHdoaWNoCj4gPiBpcyBuZWNlc3NhcnkgaWYgeW91IHdhbnQgdG8gY2F0Y2ggdW5yZWdpc3Rl cmVkIGRlc3RpbmF0aW9uCj4gPiBhZGRyZXNzZXMgQkVGT1JFIHRyYW5zbGF0aW9uIGFuZCB0aGVu IHVucmVnaXN0ZXJlZCBzb3VyY2UKPiA+IGFkZHJlc3NlcyBBRlRFUiB0cmFuc2xhdGlvbi4KPiA+ Cj4gPiA+IDIuIHVzZSBpbi1rZXJuZWwgbGliYWxpYXMgaW1wbGVtZW50YXRpb24KPiA+ID4gICAg KEkgZ3Vlc3MgbWFuLXBhZ2UgZm9yIG5nX25hdCg0KSB3aWxsIGhlbHApCj4gPgo+ID4gU2FtZSBw cm9ibGVtLiBJIGRvbid0IGtub3cgaG93IEkgY291bGQgc2VuZCBwYWNrZXRzCj4gPiB0aHJvdWdo IGEgTmV0Z3JhcGggbm9kZSBpbiB0aGUgbWlkZGxlIG9mIHByb2Nlc3NpbmcKPiA+IGJ5IElQRlcg YW5kIHRoZW4gYnJpbmcgdGhlbSBiYWNrIGF0IHRoZSBuZXh0IHJ1bGUuCj4KPiBTb21lIHllYXJz IGFnbywgSSd2ZSBtYW5hZ2VkIHRvIHVzZSBrc29ja2V0IGludGVyZmFjZSB0byBjYXRjaCBkaXZl cnQKPiBwYWNrZXRzIGZyb20gaXBmdyBhbmQgZXZlbiByZXR1cm4gdGhlbSBiYWNrIChzdXJwcmlz aW5nbHkgaXQgZGlkIHN1cHBvcnQKPiBkaXZlcnQgQUYpLgo+Cj4gQnV0LCBiZSBjYXJlZnVsLCBp dCBpcyBlYXN5IHRvIGdldCBpbmZpbml0ZSBsb29wIGluIGtlcm5lbCB3aXRoIHRoaXMKPiB0ZWNo bmlxdWUuIFByb2JhYmx5IHNvbWUgbG9vcCBwcmV2ZW50aW9uIGFwcGVhcnMgaW4gZnJvbSB0aGVz ZSB0aW1lcywKPiBidXQgSSBhbSBub3Qgc3VyZS4KCiAgIFllcywgb25lIGNhbiB1c2UgbWJ1Zl90 YWdzKDkpIHRvIHByZXZlbnQgbG9vcHMuCgo+Cj4gPiBJIHN1cHBvc2UgdGhhdCBvbmUgc29sdXRp b24gbWlnaHQgYmUsIGZvciBsYWNrIG9mIGEKPiA+IGJldHRlciB0ZXJtLCBhICJrZXJuZWwgZGl2 ZXJ0IHNvY2tldCwiIHdoaWNoIHdvdWxkCj4gPiBwYXNzIHBhY2tldHMgdGhyb3VnaCBhIGtlcm5l bCBtb2R1bGUgcmF0aGVyIHRoYW4gYQo+ID4gdXNlciBwcm9jZXNzLiAoVGhpcyBjb3VsZCBhY3R1 YWxseSBiZSB1c2VkIHRvIHNwZWVkCj4gPiB1cCBtYW55IHRoaW5ncyBmb3Igd2hpY2ggdGhlIGN1 cnJlbnQgInVzZXJsYW5kIgo+ID4gZGl2ZXJ0IHNvY2tldHMgYXJlIG5vdyB1c2VkLikgSXQgd291 bGQgdGhlbiBiZQo+ID4gcG9zc2libGUgdG8gbWFrZSBhICJuYXQua28iIG1vZHVsZSwgYW5kIGVp dGhlcgo+ID4gcHJvdmlkZSBhIHV0aWxpdHkgdG8gY29udHJvbCBpdCBvciByb2xsIHRoYXQKPiA+ IGZ1bmN0aW9uYWxpdHkgaW50byBpcGZ3KDgpLgo+ID4KPiA+IC0tQnJldHQKPiA+Cj4gLS0KPiBW bGFkaW1pciBCLiBHcmViZW5zY2hpa292Cj4gdm92YUBmYnNkLnJ1Cj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KPiBmcmVlYnNkLW5ldEBmcmVlYnNkLm9y ZyBtYWlsaW5nIGxpc3QKPiBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5m by9mcmVlYnNkLW5ldAo+IFRvIHVuc3Vic2NyaWJlLCBzZW5kIGFueSBtYWlsIHRvICJmcmVlYnNk LW5ldC11bnN1YnNjcmliZUBmcmVlYnNkLm9yZyIKPgoKCi0tIApJZiBpdCdzIHRoZXJlLCBhbmQg eW91IGNhbiBzZWUgaXQsIGl0J3MgcmVhbC4KSWYgaXQncyBub3QgdGhlcmUsIGFuZCB5b3UgY2Fu IHNlZSBpdCwgaXQncyB2aXJ0dWFsLgpJZiBpdCdzIHRoZXJlLCBhbmQgeW91IGNhbid0IHNlZSBp dCwgaXQncyB0cmFuc3BhcmVudC4KSWYgaXQncyBub3QgdGhlcmUsIGFuZCB5b3UgY2FuJ3Qgc2Vl IGl0LCB5b3UgZXJhc2VkIGl0Lgo= From owner-freebsd-net@FreeBSD.ORG Mon Oct 23 09:47:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 E24A516A415 for ; Mon, 23 Oct 2006 09:47:06 +0000 (UTC) (envelope-from tataz@tataz.chchile.org) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B58343D4C for ; Mon, 23 Oct 2006 09:47:06 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp1-g19.free.fr (Postfix) with ESMTP id 4AD6C5123; Mon, 23 Oct 2006 11:47:05 +0200 (CEST) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 220359E6C6; Mon, 23 Oct 2006 09:47:43 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 0BC71405F; Mon, 23 Oct 2006 11:47:43 +0200 (CEST) Date: Mon, 23 Oct 2006 11:47:42 +0200 From: Jeremie Le Hen To: Raymond Wagner Message-ID: <20061023094742.GA53114@obiwan.tataz.chchile.org> References: <20061016061255.CNQK10743.gx6.fuse.net@raymond2> <20061022160103.GX53114@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061022160103.GX53114@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-net@freebsd.org Subject: Re: Virtual Network Interfaces X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 09:47:07 -0000 Raymond, On Sun, Oct 22, 2006 at 06:01:03PM +0200, Jeremie Le Hen wrote: > On Mon, Oct 16, 2006 at 02:12:47AM -0400, Raymond Wagner wrote: > > My ISP provides me up to 5 dynamically assigned addresses out of a /20 > > block. I have more than 5 machines on my network, so I have no choice but > > to run NAT, however I would like to force two of those machines onto their > > own external addresses. If I had static addresses, I could simply alias the > > addresses into the external interface and then use "binat" in pf to redirect > > the traffic. However, the addresses have to be requested from the DHCP > > server, and expire after 4 hours. > > > > I can get this to work by running the NAT function under QEMU and just > > giving the virtual machine several interfaces bridged to the physical > > external interface. Running a VM is far from ideal. Is there any way I > > could set up a virtual network interface that could be bridged to the true > > interface and grab its own DHCP address? > > I don't know if that works, but I would try the following setup. > Supposing you have two physical interaces, an external one (ext0) > and an internal one (int0), I would create a VLAN on int0 for > each machine which have to have its own public address (vlan1 > and vlan2) and bridge { ext0, vlan1, vlan2 }. I thought of another way this morning in my bathroom, which is far neater, though I've not tested it. First use if_bridge(4) to mingle ext0 and int0, then use the MAC addresses to let through but the machines that are supposed to have a public IP address; the other will have to use your FreeBSD as a default gateway. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-net@FreeBSD.ORG Mon Oct 23 11:08:27 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org 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 42A8616A417 for ; Mon, 23 Oct 2006 11:08:27 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B09B43D55 for ; Mon, 23 Oct 2006 11:08:27 +0000 (GMT) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id k9NB8QXn027730 for ; Mon, 23 Oct 2006 11:08:26 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id k9NB8PTt027726 for freebsd-net@FreeBSD.org; Mon, 23 Oct 2006 11:08:25 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Oct 2006 11:08:25 GMT Message-Id: <200610231108.k9NB8PTt027726@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 11:08:27 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- a kern/38554 net changing interface ipaddress doesn't seem to work s kern/39937 net ipstealth issue s kern/52585 net [netinet] [patch] Kernel panic with ipfw2 and syncooki o kern/92552 net A serious bug in most network drivers from 5.X to 6.X f kern/93220 net [inet6] nd6_lookup: failed to add route for a neighbor s kern/95665 net [if_tun] "ping: sendto: No buffer space available" wit 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19875 net A new protocol family, PF_IPOPTION, to handle IP optio o conf/23063 net [PATCH] for static ARP tables in rc.network s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s kern/60293 net FreeBSD arp poison patch o kern/95267 net packet drops periodically appear f kern/95277 net [netinet] IP Encapsulation mask_match() returns wrong o kern/102035 net [plip] plip networking disables parallel port printing o conf/102502 net [patch] ifconfig name does't rename netgraph node in n 9 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 23 17:37:53 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 EA8F816A582; Mon, 23 Oct 2006 17:37:53 +0000 (UTC) (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 mx1.FreeBSD.org (Postfix) with ESMTP id 1028443D75; Mon, 23 Oct 2006 17:37:40 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k9NHbdkF055590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Oct 2006 13:37:39 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Gleb Smirnoff Date: Mon, 23 Oct 2006 13:37:33 -0400 User-Agent: KMail/1.9.1 References: <200610211300.09476@aldan> <20061021173358.GC75694@cell.sick.ru> In-Reply-To: <20061021173358.GC75694@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200610231337.33873.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88.4/2082/Mon Oct 23 10:58:17 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: em network issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 17:37:54 -0000 ΣΥΒΟΤΑ 21 ΦΟΧΤΕΞΨ 2006 13:33, Gleb Smirnoff ΞΑΠΙΣΑΧ: > We aren't currently speaking about performance, we need to know whether > kernel with DEVICE_POLLING option makes NIC work stable. Yes, that seems to be the case... After I got to the machine's console (there was no network access) and turning off the polling on em0, it started accepting the dumps (two streams in parallel from two different remote servers), and compressing them (zlib -9) at about 35 Mb/s. The em0's interrupts fire between 3K and 4K times per second, accounting for 3-7% of the total CPU load. I'll test with three parallel dumps tonight (one of them from an "overwhelming" 8-Sparc db-server), but it looks quite promising already. Yours, -mi 4 users Load 2.46 2.34 1.63 23 ΦΟΧ 13:34 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 113456 17640 233076 44512 89204 count All 2001588 20244 1426659k 51588 pages Interrupts Proc:r p d s w Csw Trp Sys Int Sof Flt cow 7738 total 2 60 12703 172391928576 70 254372 wire irq1: atkb 120004 act irq6: fdc0 4.9%Sys 6.3%Intr 88.8%User 0.0%Nice 0.0%Idl 1548080 inact irq15: ata | | | | | | | | | | 86240 cache irq17: fwo ==++++>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2964 free irq20: nve daefr irq21: ohc Namei Name-cache Dir-cache prcfr 2 irq22: ehc Calls hits % hits % react 3679 irq25: em0 312 312 100 pdwak 67 irq29: amr zfod pdpgs 1995 cpu0: time Disks ad4 ad6 amrd0 ozfod intrn 1995 cpu1: time KB/t 128 0.00 75.03 %slo-z 221184 buf tps 1 0 58 1112 tfree 23 dirtybuf MB/s 0.12 0.00 4.23 100000 desiredvnodes % busy 0 0 61 2757 numvnodes Showing vmstat, refresh every 1 seconds. 1965 From owner-freebsd-net@FreeBSD.ORG Mon Oct 23 18:50:45 2006 Return-Path: X-Original-To: net@freebsd.org 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 6202416A407 for ; Mon, 23 Oct 2006 18:50:45 +0000 (UTC) (envelope-from brett@lariat.net) Received: from lariat.net (lariat.net [65.122.236.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19BDD43DB0 for ; Mon, 23 Oct 2006 18:50:28 +0000 (GMT) (envelope-from brett@lariat.net) Received: from anne-o1dpaayth1.lariat.org (IDENT:ppp1000.lariat.net@lariat.net [65.122.236.2]) by lariat.net (8.9.3/8.9.3) with ESMTP id MAA12253; Mon, 23 Oct 2006 12:50:12 -0600 (MDT) Message-Id: <200610231850.MAA12253@lariat.net> X-message-flag: Warning! Use of Microsoft Outlook renders your system susceptible to Internet worms. X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 23 Oct 2006 12:50:05 -0600 To: Julian Elischer From: Brett Glass In-Reply-To: <453AF1BB.7070507@elischer.org> References: <200610210648.AAA01737@lariat.net> <453AEA86.4070103@elischer.org> <200610220414.WAA15541@lariat.net> <453AF1BB.7070507@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; x-avg-checked=avg-ok-81811ED Cc: net@freebsd.org Subject: Re: Avoiding natd overhead X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 18:50:45 -0000 At 10:21 PM 10/21/2006, Julian Elischer wrote: >OR in 7.0 you can call netgraph directly > >there is a netgraph keyword in ipfw. I just took a look at that. Could work, except that the ng_nat Netgraph node only does very basic NAT. One can't do static NAT, and none of natd's other options are accessible. Whilst perusing the code, I also noticed that libalias expects all packets to be in a single contiguous buffer. This means that ng_nat doesn't get rid of one of the big inefficiencies involved in the use of natd: the need to make a copy of the mbuf chain containing the packet to ensure contiguity. (This is an issue with anything that uses divert sockets, but it creeps in with ng_nat as well due to the way libalias is coded.) Using a Netgraph node would help with the ring transition, though, so there should be some savings. Has the "netgraph" keyword been MFCed? --Brett Glass From owner-freebsd-net@FreeBSD.ORG Mon Oct 23 18:51:01 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 1EEAF16A4D1; Mon, 23 Oct 2006 18:51:01 +0000 (UTC) (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 mx1.FreeBSD.org (Postfix) with ESMTP id 7CA8B43D45; Mon, 23 Oct 2006 18:50:52 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k9NIooCO058639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Oct 2006 14:50:51 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Gleb Smirnoff Date: Mon, 23 Oct 2006 14:50:44 -0400 User-Agent: KMail/1.9.1 References: <200610211300.09476@aldan> <20061021173358.GC75694@cell.sick.ru> <200610231337.33873.mi+mx@aldan.algebra.com> In-Reply-To: <200610231337.33873.mi+mx@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200610231450.44657.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88.4/2082/Mon Oct 23 10:58:17 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: em network issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 18:51:01 -0000 ΠΟΞΕΔ¦ΜΟΛ 23 ΦΟΧΤΕΞΨ 2006 13:37, Mikhail Teterin ΞΑΠΙΣΑΧ: > > We aren't currently speaking about performance, we need to know whether > > kernel with DEVICE_POLLING option makes NIC work stable. > > Yes, that seems to be the case... I spoke too soon :-( It took a lot longer this time (without polling), but the network hung again on the box. Everything recovered by itself after I walked over and simply pushed the Shift button on the machine's keyboard... -mi From owner-freebsd-net@FreeBSD.ORG Mon Oct 23 19:07:22 2006 Return-Path: X-Original-To: net@freebsd.org 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 2FAE116A407; Mon, 23 Oct 2006 19:07:22 +0000 (UTC) (envelope-from prvs=julian=4448fe975@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB2E043D8D; Mon, 23 Oct 2006 19:07:12 +0000 (GMT) (envelope-from prvs=julian=4448fe975@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 23 Oct 2006 12:07:12 -0700 Message-ID: <453D12E0.5090906@elischer.org> Date: Mon, 23 Oct 2006 12:07:12 -0700 From: Julian Elischer User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Max Laier References: <200610210016.k9L0GWdR090610@repoman.freebsd.org> <200610210305.52458.max@love2party.net> In-Reply-To: <200610210305.52458.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: andre@freebsd.org, cvs-all@freebsd.org, FreeBSD Net Subject: Re: pfil and ipfw for bridge and ether. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 19:07:22 -0000 Max Laier wrote: > I think andre has a WIP for that ... Andre?!? Time to commit. Anyone know where andre has his work? It's been the weekend since then and still not heard anything.. I need to get this stuff fixed soonish and can do it if he's been ENOTIME'd. From owner-freebsd-net@FreeBSD.ORG Mon Oct 23 19:26:45 2006 Return-Path: X-Original-To: net@freebsd.org 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 2614316A40F for ; Mon, 23 Oct 2006 19:26:45 +0000 (UTC) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C26143D64 for ; Mon, 23 Oct 2006 19:26:40 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.13.6) with ESMTP id k9NJQak2089662; Mon, 23 Oct 2006 12:26:36 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id k9NJQax9089661; Mon, 23 Oct 2006 12:26:36 -0700 (PDT) (envelope-from rizzo) Date: Mon, 23 Oct 2006 12:26:36 -0700 From: Luigi Rizzo To: Brett Glass Message-ID: <20061023122636.B89538@xorpc.icir.org> References: <200610210648.AAA01737@lariat.net> <453AEA86.4070103@elischer.org> <200610220414.WAA15541@lariat.net> <453AF1BB.7070507@elischer.org> <200610231850.MAA12253@lariat.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <200610231850.MAA12253@lariat.net>; from brett@lariat.net on Mon, Oct 23, 2006 at 12:50:05PM -0600 Cc: Julian Elischer , net@freebsd.org Subject: Re: Avoiding natd overhead X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 19:26:45 -0000 On Mon, Oct 23, 2006 at 12:50:05PM -0600, Brett Glass wrote: > At 10:21 PM 10/21/2006, Julian Elischer wrote: > > >OR in 7.0 you can call netgraph directly > > > >there is a netgraph keyword in ipfw. > > I just took a look at that. Could work, except that the ng_nat > Netgraph node only does very basic NAT. One can't do static NAT, > and none of natd's other options are accessible. there is another part of paolo's work that adds the 'nat' keyword to ipfw. Even if not merged, i think it is available as a patch, right paolo ? > Whilst perusing the code, I also noticed that libalias expects all > packets to be in a single contiguous buffer. This means that ng_nat > doesn't get rid of one of the big inefficiencies involved in the > use of natd: the need to make a copy of the mbuf chain containing the copy may have been a problem 20 or even 10 years ago. These days, with huge memory bandwidths and because of the effect of burst access to memory, i would be surprised if the memcopy overhead were anything significant. Yes, you trash the cache a bit, but on the other hand you bring early in-cache the fields you need to inspect. The real performance issue with divert is the system call. Next, I'd also check if there is a scalability issue related to inefficient data structures. cheers luigi > the packet to ensure contiguity. (This is an issue with anything > that uses divert sockets, but it creeps in with ng_nat as well due > to the way libalias is coded.) Using a Netgraph node would help > with the ring transition, though, so there should be some savings. > Has the "netgraph" keyword been MFCed? > > --Brett Glass > > _______________________________________________ > 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 Mon Oct 23 21:36:02 2006 Return-Path: X-Original-To: net@freebsd.org 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 CFB5116A412; Mon, 23 Oct 2006 21:36:02 +0000 (UTC) (envelope-from joe@joeholden.co.uk) Received: from claire.ber.rewt.org.uk (claire.ber.rewt.org.uk [217.160.200.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6291143D69; Mon, 23 Oct 2006 21:35:56 +0000 (GMT) (envelope-from joe@joeholden.co.uk) Received: from localhost (localhost [127.0.0.1]) by claire.ber.rewt.org.uk (Postfix) with ESMTP id C1AB0140036B; Mon, 23 Oct 2006 22:35:54 +0100 (BST) X-Virus-Scanned: Scanned at claire.ber.rewt.org.uk Received: from claire.ber.rewt.org.uk ([127.0.0.1]) by localhost (claire.ber.rewt.org.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TTyGZPFPB3aj; Mon, 23 Oct 2006 22:35:46 +0100 (BST) Received: from [82.152.108.189] (dyn189.stf.rewt.org.uk [82.152.108.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: joe) by claire.ber.rewt.org.uk (Postfix) with ESMTP id 2E22F1400343; Mon, 23 Oct 2006 22:35:46 +0100 (BST) Message-ID: <453D35AB.3000908@joeholden.co.uk> Date: Mon, 23 Oct 2006 22:35:39 +0100 From: Joe Holden User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <453C0E42.4010604@joeholden.co.uk> <453C5386.5080102@FreeBSD.org> <453C5979.4050408@yandex.ru> In-Reply-To: <453C5979.4050408@yandex.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Doug Barton , net@freebsd.org Subject: Re: Instructing dhclient to set hostname of client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joe@joeholden.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 21:36:02 -0000 Andrey V. Elsukov wrote: > Doug Barton wrote: >> If you're talking about a laptop where you're not sure what the DHCP >> server is going to send you, then I have this in /etc/rc.local: > > Hi, Doug. > > What you think about adding a new feature to dhclient - Alternate IP > Configuration. This configuration can be specified in dhclient.conf > and take effect when a DHCP server not respond. MS Windows have a > similar feature. > Really I was hoping dhclient would have this sort of functionality where it would resolve the ip given and set that as hostname, as as far as im aware, isc-dhcpd will not send hostnames? Ta, Joe From owner-freebsd-net@FreeBSD.ORG Mon Oct 23 23:34:39 2006 Return-Path: X-Original-To: net@freebsd.org 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 A6A4416A403 for ; Mon, 23 Oct 2006 23:34:39 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 1B3F043D5A for ; Mon, 23 Oct 2006 23:34:38 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 10541 invoked by uid 399); 23 Oct 2006 23:34:38 -0000 Received: from localhost (HELO ?156.154.4.185?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 23 Oct 2006 23:34:38 -0000 Message-ID: <453D518C.4040608@FreeBSD.org> Date: Mon, 23 Oct 2006 16:34:36 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Andrey V. Elsukov" References: <453C0E42.4010604@joeholden.co.uk> <453C5386.5080102@FreeBSD.org> <453C5979.4050408@yandex.ru> In-Reply-To: <453C5979.4050408@yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Instructing dhclient to set hostname of client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Oct 2006 23:34:39 -0000 Andrey V. Elsukov wrote: > Doug Barton wrote: >> If you're talking about a laptop where you're not sure what the DHCP >> server is going to send you, then I have this in /etc/rc.local: > > Hi, Doug. > > What you think about adding a new feature to dhclient - Alternate IP > Configuration. This configuration can be specified in dhclient.conf > and take effect when a DHCP server not respond. MS Windows have a > similar feature. I think making FreeBSD more like Windows is a bad idea. :) Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Tue Oct 24 06:11:24 2006 Return-Path: X-Original-To: net@freebsd.org 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 47DC016A4E1; Tue, 24 Oct 2006 06:11:24 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mx18.yandex.ru (smtp2.yandex.ru [213.180.200.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EA1743D5E; Tue, 24 Oct 2006 06:11:22 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from mail.kirov.so-cdu.ru ([81.18.142.225]:51469 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S3378226AbWJXGG6 (ORCPT + 1 other); Tue, 24 Oct 2006 10:06:58 +0400 X-Comment: RFC 2476 MSA function at smtp2.yandex.ru logged sender identity as: bu7cher Message-ID: <453DAD7F.1040504@yandex.ru> Date: Tue, 24 Oct 2006 10:06:55 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Doug Barton References: <453C0E42.4010604@joeholden.co.uk> <453C5386.5080102@FreeBSD.org> <453C5979.4050408@yandex.ru> <453D518C.4040608@FreeBSD.org> In-Reply-To: <453D518C.4040608@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Instructing dhclient to set hostname of client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2006 06:11:24 -0000 Doug Barton wrote: > I think making FreeBSD more like Windows is a bad idea. :) Yes, i partially agree, but this feature can be usefull on a laptops. If this feature will have a chance to commit, I can try to implement it. -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Tue Oct 24 07:16:11 2006 Return-Path: X-Original-To: net@freebsd.org 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 5768C16A403; Tue, 24 Oct 2006 07:16:11 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-3.dlr.de (smtp-3.dlr.de [195.37.61.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2649C43D46; Tue, 24 Oct 2006 07:16:08 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from knop-beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-3.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 09:16:06 +0200 Date: Tue, 24 Oct 2006 09:16:07 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@knop-beagle.kn.op.dlr.de To: Joe Holden In-Reply-To: <453D35AB.3000908@joeholden.co.uk> Message-ID: <20061024091523.G45134@knop-beagle.kn.op.dlr.de> References: <453C0E42.4010604@joeholden.co.uk> <453C5386.5080102@FreeBSD.org> <453C5979.4050408@yandex.ru> <453D35AB.3000908@joeholden.co.uk> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 24 Oct 2006 07:16:06.0587 (UTC) FILETIME=[45AF90B0:01C6F73C] Cc: Doug Barton , "Andrey V. Elsukov" , net@freebsd.org Subject: Re: Instructing dhclient to set hostname of client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2006 07:16:11 -0000 On Mon, 23 Oct 2006, Joe Holden wrote: JH>Andrey V. Elsukov wrote: JH>> Doug Barton wrote: JH>>> If you're talking about a laptop where you're not sure what the DHCP JH>>> server is going to send you, then I have this in /etc/rc.local: JH>> JH>> Hi, Doug. JH>> JH>> What you think about adding a new feature to dhclient - Alternate IP JH>> Configuration. This configuration can be specified in dhclient.conf JH>> and take effect when a DHCP server not respond. MS Windows have a JH>> similar feature. JH>> JH>Really I was hoping dhclient would have this sort of functionality where JH>it would resolve the ip given and set that as hostname, as as far as im JH>aware, isc-dhcpd will not send hostnames? Sure it does. On my machines I set hostname to "" in rc.conf and let dhclient set it. Works fine. harti From owner-freebsd-net@FreeBSD.ORG Tue Oct 24 14:42:19 2006 Return-Path: X-Original-To: net@freebsd.org 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 0652B16A580; Tue, 24 Oct 2006 14:42:19 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from sccmmhc91.asp.att.net (sccmmhc91.asp.att.net [204.127.203.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20D3543D7E; Tue, 24 Oct 2006 14:41:54 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net ([12.207.12.9]) by sccmmhc91.asp.att.net (sccmmhc91) with ESMTP id <20061024144037m9100em72me>; Tue, 24 Oct 2006 14:40:48 +0000 Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id k9OEdjmc052413; Tue, 24 Oct 2006 09:39:45 -0500 (CDT) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id k9OEdiKv052412; Tue, 24 Oct 2006 09:39:44 -0500 (CDT) (envelope-from brooks) Date: Tue, 24 Oct 2006 09:39:40 -0500 From: Brooks Davis To: Harti Brandt Message-ID: <20061024143940.GA52335@lor.one-eyed-alien.net> References: <453C0E42.4010604@joeholden.co.uk> <453C5386.5080102@FreeBSD.org> <453C5979.4050408@yandex.ru> <453D35AB.3000908@joeholden.co.uk> <20061024091523.G45134@knop-beagle.kn.op.dlr.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <20061024091523.G45134@knop-beagle.kn.op.dlr.de> User-Agent: Mutt/1.5.11 Cc: "Andrey V. Elsukov" , net@freebsd.org, Joe Holden , Doug Barton Subject: Re: Instructing dhclient to set hostname of client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2006 14:42:19 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 24, 2006 at 09:16:07AM +0200, Harti Brandt wrote: > On Mon, 23 Oct 2006, Joe Holden wrote: >=20 > JH>Andrey V. Elsukov wrote: > JH>> Doug Barton wrote: > JH>>> If you're talking about a laptop where you're not sure what the DHCP > JH>>> server is going to send you, then I have this in /etc/rc.local: > JH>>=20 > JH>> Hi, Doug. > JH>>=20 > JH>> What you think about adding a new feature to dhclient - Alternate IP > JH>> Configuration. This configuration can be specified in dhclient.conf > JH>> and take effect when a DHCP server not respond. MS Windows have a > JH>> similar feature. > JH>>=20 > JH>Really I was hoping dhclient would have this sort of functionality whe= re > JH>it would resolve the ip given and set that as hostname, as as far as im > JH>aware, isc-dhcpd will not send hostnames? >=20 > Sure it does. On my machines I set hostname to "" in rc.conf and let=20 > dhclient set it. Works fine. Once upon a time I implemented some code to add a default_hostname variable to rc.conf which was then used by the startup scripts and dhclient-script to allow the local network to override the name if desired while insuring that the system had a name at all times (required for laptop use). I'd take patches to do this. -- Brooks P.S. hacking this into rc.local won't work longterm because addresses will be assigned in a totally different context. --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFPiWsXY6L6fI4GtQRAvskAJ9JdU2qlWZBcQmFe/7jN7WfIg50BACg0uTC EG8TmTJf+l8UBU7z/BGuD0I= =dQEc -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From owner-freebsd-net@FreeBSD.ORG Tue Oct 24 15:26:16 2006 Return-Path: X-Original-To: net@freebsd.org 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 DF74C16A415; Tue, 24 Oct 2006 15:26:16 +0000 (UTC) (envelope-from joe@joeholden.co.uk) Received: from claire.ber.rewt.org.uk (claire.ber.rewt.org.uk [217.160.200.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31A3B43D4C; Tue, 24 Oct 2006 15:26:15 +0000 (GMT) (envelope-from joe@joeholden.co.uk) Received: from localhost (localhost [127.0.0.1]) by claire.ber.rewt.org.uk (Postfix) with ESMTP id A0E131400343; Tue, 24 Oct 2006 16:26:14 +0100 (BST) X-Virus-Scanned: Scanned at claire.ber.rewt.org.uk Received: from claire.ber.rewt.org.uk ([127.0.0.1]) by localhost (claire.ber.rewt.org.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAgLJXxYxZ-2; Tue, 24 Oct 2006 16:26:05 +0100 (BST) Received: from [82.152.108.189] (dyn189.stf.rewt.org.uk [82.152.108.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: joe) by claire.ber.rewt.org.uk (Postfix) with ESMTP id 2FD0E1400358; Tue, 24 Oct 2006 16:26:05 +0100 (BST) Message-ID: <453E3085.7040003@joeholden.co.uk> Date: Tue, 24 Oct 2006 16:25:57 +0100 From: Joe Holden User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Brooks Davis References: <453C0E42.4010604@joeholden.co.uk> <453C5386.5080102@FreeBSD.org> <453C5979.4050408@yandex.ru> <453D35AB.3000908@joeholden.co.uk> <20061024091523.G45134@knop-beagle.kn.op.dlr.de> <20061024143940.GA52335@lor.one-eyed-alien.net> In-Reply-To: <20061024143940.GA52335@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Doug Barton , "Andrey V. Elsukov" , Harti Brandt , net@freebsd.org Subject: Re: Instructing dhclient to set hostname of client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: joe@joeholden.co.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2006 15:26:17 -0000 Brooks Davis wrote: > On Tue, Oct 24, 2006 at 09:16:07AM +0200, Harti Brandt wrote: >> On Mon, 23 Oct 2006, Joe Holden wrote: >> >> JH>Andrey V. Elsukov wrote: >> JH>> Doug Barton wrote: >> JH>>> If you're talking about a laptop where you're not sure what the DHCP >> JH>>> server is going to send you, then I have this in /etc/rc.local: >> JH>> >> JH>> Hi, Doug. >> JH>> >> JH>> What you think about adding a new feature to dhclient - Alternate IP >> JH>> Configuration. This configuration can be specified in dhclient.conf >> JH>> and take effect when a DHCP server not respond. MS Windows have a >> JH>> similar feature. >> JH>> >> JH>Really I was hoping dhclient would have this sort of functionality where >> JH>it would resolve the ip given and set that as hostname, as as far as im >> JH>aware, isc-dhcpd will not send hostnames? >> >> Sure it does. On my machines I set hostname to "" in rc.conf and let >> dhclient set it. Works fine. > > Once upon a time I implemented some code to add a default_hostname > variable to rc.conf which was then used by the startup scripts and > dhclient-script to allow the local network to override the name if > desired while insuring that the system had a name at all times (required > for laptop use). I'd take patches to do this. > > -- Brooks > > P.S. hacking this into rc.local won't work longterm because addresses > will be assigned in a totally different context. I wrote an rc.d script called updatehost that does this, its called after other net scripts, and basically gets the ip from $interface (set by updatehost_flags="blah0" in rc.conf, and resolves that, seems to work, a dirty hack but it does the trick. Thanks, Joe From owner-freebsd-net@FreeBSD.ORG Tue Oct 24 20:25:06 2006 Return-Path: X-Original-To: net@freebsd.org 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 398F416A403 for ; Tue, 24 Oct 2006 20:25:06 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5B8243D53 for ; Tue, 24 Oct 2006 20:25:04 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 3151 invoked from network); 24 Oct 2006 20:21:36 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 24 Oct 2006 20:21:36 -0000 Message-ID: <453E76A0.7000708@freebsd.org> Date: Tue, 24 Oct 2006 22:25:04 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Julian Elischer References: <200610210016.k9L0GWdR090610@repoman.freebsd.org> <200610210305.52458.max@love2party.net> <453D12E0.5090906@elischer.org> In-Reply-To: <453D12E0.5090906@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Max Laier , cvs-all@freebsd.org, FreeBSD Net Subject: Re: pfil and ipfw for bridge and ether. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2006 20:25:06 -0000 Julian Elischer wrote: > Max Laier wrote: > >> I think andre has a WIP for that ... Andre?!? Time to commit. > > > Anyone know where andre has his work? > It's been the weekend since then and still not heard anything.. > I need to get this stuff fixed soonish and can do it if > he's been ENOTIME'd. I can work on it next week. I've got some stuff in my local tree but nothing complete. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Oct 25 18:19:17 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 A65FC16A412 for ; Wed, 25 Oct 2006 18:19:17 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [64.174.51.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9635C43D77 for ; Wed, 25 Oct 2006 18:18:50 +0000 (GMT) (envelope-from ambrisko@ambrisko.com) Received: from server2.ambrisko.com (HELO www.ambrisko.com) ([192.168.1.2]) by mail.ambrisko.com with ESMTP; 25 Oct 2006 11:15:31 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by www.ambrisko.com (8.13.1/8.12.11) with ESMTP id k9PIIfmb062531; Wed, 25 Oct 2006 11:18:41 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.13.1/8.13.1/Submit) id k9PIIe7p062530; Wed, 25 Oct 2006 11:18:40 -0700 (PDT) (envelope-from ambrisko) From: Doug Ambrisko Message-Id: <200610251818.k9PIIe7p062530@ambrisko.com> In-Reply-To: To: John Polstra Date: Wed, 25 Oct 2006 11:18:40 -0700 (PDT) X-Mailer: ELM [version 2.4ME+ PL94b (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net , Scott Long Subject: Re: em network issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2006 18:19:17 -0000 John Polstra writes: | On 19-Oct-2006 Scott Long wrote: | > The performance measurements that Andre and I did early this year showed | > that the INTR_FAST handler provided a very large benefit. | | I'm trying to understand why that's the case. Is it because an | INTR_FAST interrupt doesn't have to be masked and unmasked in the | APIC? I can't see any other reason for much of a performance | difference in that driver. With or without INTR_FAST, you've got | the bulk of the work being done in a background thread -- either the | ithread or the taskqueue thread. It's not clear to me that it's any | cheaper to run a task than it is to run an ithread. | | A difference might show up if you had two or more em devices sharing | the same IRQ. Then they'd share one ithread, but would each get their | own taskqueue thread. But sharing an IRQ among multiple gigabit NICs | would be avoided by anyone who cared about performance, so it's not a | very interesting case. Besides, when you first committed this | stuff, INTR_FAST interrupts were not sharable. | | Another change you made in the same commit (if_em.c revision 1.98) | greatly reduced the number of PCI writes made to the RX ring consumer | pointer register. That would yield a significant performance | improvement. Did you see gains from INTR_FAST even without this | independent change? Something that we've fixed locally in atleast one version is: 1) Limit the loop in em_intr to 3 iterations 2) Pass a valid value to em_process_receive_interrupts/em_rxeof a good value like 100 instead of -1. Since this is the count for how many time to iterate over the rx stuff. Seems this got lost in the some change of APIs. 3) In em_process_receive_interrupts/em_rxeof always decrement the count on every run through the loop. If you notice count is an is an int that starts at the passed in value of -1. It then count-- until count==0. Doing -1, -2, -3 takes awhile until the int rolls over to 0. Passing 100 limits it more :-) So this can run 3 * 100 versuses infinite * int roll over assuming we don't skip a count--. Doing these changes made our multiple em based machines a lot happier when slammed with traffic without starving other things that shared interrupts like other em cards (especially in 4.X). Interrupt handler should have limits of how long they should be able to run then let someone else go. We use this in 6.X as well and haven't had any problems with our config's that use this. We haven't tested much without these since we need to fix other issues and this is now a non-issue for us. I haven't pushed this more since I first found issue 1 and the concept was rejected ... my machine hung in the interrupt spin loop :-( If someone wants to examine/play with it more then that's great. These issues (I think they are bugs) have been in there a while. That's my 2 cents. Doug A. From owner-freebsd-net@FreeBSD.ORG Wed Oct 25 18:33:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 2A9F516A47C for ; Wed, 25 Oct 2006 18:33:10 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5323A43D76 for ; Wed, 25 Oct 2006 18:33:07 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so152209pyc for ; Wed, 25 Oct 2006 11:33:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=RH7GDy0W8zuo7YjuiH0cQtTQYcjbrfpH7pz43EcQlMH7zhvUPsUYRUxrTCIRU4wGV0REQGAZZ/khrV1xGR3nmFp6t/hyDTUR90kSPR7J5WQR6kasdjwgq+IYGtXrQsSFZdlrvdpZ4cpd8EAzO2nVstF6WyUrSMRTRqam7uETYkI= Received: by 10.35.128.1 with SMTP id f1mr1528002pyn; Wed, 25 Oct 2006 11:33:06 -0700 (PDT) Received: by 10.35.118.6 with HTTP; Wed, 25 Oct 2006 11:33:05 -0700 (PDT) Message-ID: <2a41acea0610251133s7eadf41fn937aa6c43e6136a2@mail.gmail.com> Date: Wed, 25 Oct 2006 11:33:06 -0700 From: "Jack Vogel" To: "Doug Ambrisko" In-Reply-To: <200610251818.k9PIIe7p062530@ambrisko.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200610251818.k9PIIe7p062530@ambrisko.com> Cc: freebsd-net , Scott Long , John Polstra Subject: Re: em network issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2006 18:33:10 -0000 On 10/25/06, Doug Ambrisko wrote: > John Polstra writes: > | On 19-Oct-2006 Scott Long wrote: > | > The performance measurements that Andre and I did early this year showed > | > that the INTR_FAST handler provided a very large benefit. > | > | I'm trying to understand why that's the case. Is it because an > | INTR_FAST interrupt doesn't have to be masked and unmasked in the > | APIC? I can't see any other reason for much of a performance > | difference in that driver. With or without INTR_FAST, you've got > | the bulk of the work being done in a background thread -- either the > | ithread or the taskqueue thread. It's not clear to me that it's any > | cheaper to run a task than it is to run an ithread. > | > | A difference might show up if you had two or more em devices sharing > | the same IRQ. Then they'd share one ithread, but would each get their > | own taskqueue thread. But sharing an IRQ among multiple gigabit NICs > | would be avoided by anyone who cared about performance, so it's not a > | very interesting case. Besides, when you first committed this > | stuff, INTR_FAST interrupts were not sharable. > | > | Another change you made in the same commit (if_em.c revision 1.98) > | greatly reduced the number of PCI writes made to the RX ring consumer > | pointer register. That would yield a significant performance > | improvement. Did you see gains from INTR_FAST even without this > | independent change? > > Something that we've fixed locally in atleast one version is: > 1) Limit the loop in em_intr to 3 iterations > 2) Pass a valid value to em_process_receive_interrupts/em_rxeof > a good value like 100 instead of -1. Since this is the count > for how many time to iterate over the rx stuff. Seems this > got lost in the some change of APIs. > 3) In em_process_receive_interrupts/em_rxeof always decrement > the count on every run through the loop. If you notice > count is an is an int that starts at the passed in value > of -1. It then count-- until count==0. Doing -1, -2, -3 > takes awhile until the int rolls over to 0. Passing 100 > limits it more :-) So this can run 3 * 100 versuses > infinite * int roll over assuming we don't skip a count--. > Doing these changes made our multiple em based machines a lot happier > when slammed with traffic without starving other things that shared > interrupts like other em cards (especially in 4.X). Interrupt handler > should have limits of how long they should be able to run then let > someone else go. We use this in 6.X as well and haven't had any problems > with our config's that use this. We haven't tested much without these > since we need to fix other issues and this is now a non-issue for us. > > I haven't pushed this more since I first found issue 1 and the concept > was rejected ... my machine hung in the interrupt spin loop :-( > > If someone wants to examine/play with it more then that's great. > These issues (I think they are bugs) have been in there a while. > > That's my 2 cents. > > Doug A. Interesting, I had forgotten about a couple of these issues. Timely email because I now have a test setup that has repro'd at least one version of the reported problems and I am currently debugging. This is something I can test. Thanks Doug, Jack From owner-freebsd-net@FreeBSD.ORG Wed Oct 25 19:14:42 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 7425A16A40F for ; Wed, 25 Oct 2006 19:14:42 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B635243D45 for ; Wed, 25 Oct 2006 19:14:39 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([165.236.175.187]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k9PJEUZl092043; Wed, 25 Oct 2006 13:14:35 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <453FB78F.7060402@samsco.org> Date: Wed, 25 Oct 2006 13:14:23 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Doug Ambrisko References: <200610251818.k9PIIe7p062530@ambrisko.com> In-Reply-To: <200610251818.k9PIIe7p062530@ambrisko.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net , John Polstra Subject: Re: em network issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2006 19:14:42 -0000 Doug Ambrisko wrote: > John Polstra writes: > | On 19-Oct-2006 Scott Long wrote: > | > The performance measurements that Andre and I did early this year showed > | > that the INTR_FAST handler provided a very large benefit. > | > | I'm trying to understand why that's the case. Is it because an > | INTR_FAST interrupt doesn't have to be masked and unmasked in the > | APIC? I can't see any other reason for much of a performance > | difference in that driver. With or without INTR_FAST, you've got > | the bulk of the work being done in a background thread -- either the > | ithread or the taskqueue thread. It's not clear to me that it's any > | cheaper to run a task than it is to run an ithread. > | > | A difference might show up if you had two or more em devices sharing > | the same IRQ. Then they'd share one ithread, but would each get their > | own taskqueue thread. But sharing an IRQ among multiple gigabit NICs > | would be avoided by anyone who cared about performance, so it's not a > | very interesting case. Besides, when you first committed this > | stuff, INTR_FAST interrupts were not sharable. > | > | Another change you made in the same commit (if_em.c revision 1.98) > | greatly reduced the number of PCI writes made to the RX ring consumer > | pointer register. That would yield a significant performance > | improvement. Did you see gains from INTR_FAST even without this > | independent change? > > Something that we've fixed locally in atleast one version is: > 1) Limit the loop in em_intr to 3 iterations > 2) Pass a valid value to em_process_receive_interrupts/em_rxeof > a good value like 100 instead of -1. Since this is the count > for how many time to iterate over the rx stuff. Seems this > got lost in the some change of APIs. > 3) In em_process_receive_interrupts/em_rxeof always decrement > the count on every run through the loop. If you notice > count is an is an int that starts at the passed in value > of -1. It then count-- until count==0. Doing -1, -2, -3 > takes awhile until the int rolls over to 0. Passing 100 > limits it more :-) So this can run 3 * 100 versuses > infinite * int roll over assuming we don't skip a count--. > Doing these changes made our multiple em based machines a lot happier > when slammed with traffic without starving other things that shared > interrupts like other em cards (especially in 4.X). Interrupt handler > should have limits of how long they should be able to run then let > someone else go. We use this in 6.X as well and haven't had any problems > with our config's that use this. We haven't tested much without these > since we need to fix other issues and this is now a non-issue for us. > > I haven't pushed this more since I first found issue 1 and the concept > was rejected ... my machine hung in the interrupt spin loop :-( > > If someone wants to examine/play with it more then that's great. > These issues (I think they are bugs) have been in there a while. > > That's my 2 cents. > > Doug A. When I was first developing and testing the INTR_FAST patches, I did a similar thing with limiting the loop. I can't recall why I dopped that (or if it was even me that dropped it). I think it's a good idea to generally have. One concern that I've had with the whole INTR_FAST/taskqueue scheme is that having the rx loop be unbounded could cause a livelock on UP. In fact, I'm pretty sure that the performance measurements done with the smartbits included having the loop be bounded. Scott From owner-freebsd-net@FreeBSD.ORG Wed Oct 25 23:46:45 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 C084116A412 for ; Wed, 25 Oct 2006 23:46:45 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24D3844727 for ; Wed, 25 Oct 2006 23:46:44 +0000 (GMT) (envelope-from stb@lassitu.de) Received: (from stb@koef.zs64.net) (authenticated) by koef.zs64.net (8.13.8/8.13.8) with ESMTP id k9PNkf2t004751 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 26 Oct 2006 01:46:42 +0200 (CEST) (envelope-from stb@lassitu.de) In-Reply-To: <45391895.8010507@tnetus.com> References: <45391895.8010507@tnetus.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <349CA351-5E6B-402D-9D18-B35CDA9C88FC@lassitu.de> Content-Transfer-Encoding: 7bit From: Stefan Bethke Date: Thu, 26 Oct 2006 01:46:40 +0200 To: Brian Hawk X-Mailer: Apple Mail (2.752.2) Cc: freebsd-net@freebsd.org Subject: Re: Gateway problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Oct 2006 23:46:45 -0000 Am 20.10.2006 um 20:42 schrieb Brian Hawk: > tun0 and ADSL is the default gateway. But the TCP packets are bound > to 212.64.212.180 IP address which should send them out thru xl1. > But it doesn't. That is correct. The routing table will only consider the destination address when deciding which route (and thereby which interface) a packet should traverse. You will need to use IPFW, pf, or similiar to force packets originating on your xl0's address (212.64.212.180) to go to the router on that network instead of to the default routes gateway/ interface. Stefan -- Stefan Bethke Fon +49 170 346 0140 From owner-freebsd-net@FreeBSD.ORG Thu Oct 26 00:36:25 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 A4FB016A403 for ; Thu, 26 Oct 2006 00:36:25 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3527743D7E for ; Thu, 26 Oct 2006 00:36:21 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so205111pyc for ; Wed, 25 Oct 2006 17:36:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=clt8ZS9iA6coE+qCVDF1s2IN7S1Jgjr7QUlNg9aRoeEVjGaDKa/gq0B45b+8KSflxEWZq7qxeYQqJlShEgc5vUL3e3dHgafCzabOgTaXhEmuFJkQY9ceCgjpH40pRaoY7rSpWRFguum0C4lfv4unH22/iHT2tnAd4aVeoa7Z+go= Received: by 10.35.121.12 with SMTP id y12mr2146309pym; Wed, 25 Oct 2006 17:36:17 -0700 (PDT) Received: by 10.35.118.6 with HTTP; Wed, 25 Oct 2006 17:36:17 -0700 (PDT) Message-ID: <2a41acea0610251736n16cc4188h489f6d953130f91a@mail.gmail.com> Date: Wed, 25 Oct 2006 17:36:17 -0700 From: "Jack Vogel" To: "Doug Ambrisko" In-Reply-To: <200610251818.k9PIIe7p062530@ambrisko.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200610251818.k9PIIe7p062530@ambrisko.com> Cc: freebsd-net , Scott Long , John Polstra Subject: Re: em network issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2006 00:36:25 -0000 On 10/25/06, Doug Ambrisko wrote: > 3) In em_process_receive_interrupts/em_rxeof always decrement > the count on every run through the loop. If you notice > count is an is an int that starts at the passed in value > of -1. It then count-- until count==0. Doing -1, -2, -3 > takes awhile until the int rolls over to 0. Passing 100 > limits it more :-) So this can run 3 * 100 versuses > infinite * int roll over assuming we don't skip a count--. Been chatting with Jesse Brandeburg (one of our senior Linux guys) about receive side cleaning. Gave me a number of things to think about. First off, this change you mention is problematic. The reason it doesnt increment every time thru the while loop is its meant as a packet counter, NOT a descriptor counter. If we just fix this number at 100, and have it only counting descriptors you could get all but the EOP descriptor of a packet and then exit without finishing it and calling the stack, not a good tactic. Having a limited count is still a good idea, but I think we still want to base it on packets and not just descriptors. Jesse also talked about their experience with the Linux driver, deciding where to update the RDT, my current code doesnt do it til after the whole while loop is completed (havent looked at CURRENT again today yet), Jesse suggested doing it but not EVERY pass in the loop, maybe making it mod the number of rx descriptors. Having that AND a fixed limit on the number of total packets cleaned in a pass might be good. I was also thinking, maybe having the taskqueue code be selectable, but not just a POLL vs TASKQUEUE, rather keep a legacy intr option which has a POLL option within it. My motivation for doing that is I can take the TASKQUEUE code into the Intel code base, but make it backward compatible, the default would have it optioned off. Jack From owner-freebsd-net@FreeBSD.ORG Thu Oct 26 01:05:44 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 98EFD16A416 for ; Thu, 26 Oct 2006 01:05:44 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9838143D58 for ; Thu, 26 Oct 2006 01:05:43 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k9Q15ZBC094046; Wed, 25 Oct 2006 19:05:41 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <454009DF.5000704@samsco.org> Date: Wed, 25 Oct 2006 19:05:35 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Jack Vogel References: <200610251818.k9PIIe7p062530@ambrisko.com> <2a41acea0610251736n16cc4188h489f6d953130f91a@mail.gmail.com> In-Reply-To: <2a41acea0610251736n16cc4188h489f6d953130f91a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net , John Polstra Subject: Re: em network issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2006 01:05:44 -0000 Jack Vogel wrote: > On 10/25/06, Doug Ambrisko wrote: > >> 3) In em_process_receive_interrupts/em_rxeof always decrement >> the count on every run through the loop. If you notice >> count is an is an int that starts at the passed in value >> of -1. It then count-- until count==0. Doing -1, -2, -3 >> takes awhile until the int rolls over to 0. Passing 100 >> limits it more :-) So this can run 3 * 100 versuses >> infinite * int roll over assuming we don't skip a count--. > > Been chatting with Jesse Brandeburg (one of our senior Linux guys) about > receive side cleaning. Gave me a number of things to think about. First > off, > this change you mention is problematic. The reason it doesnt increment > every time thru the while loop is its meant as a packet counter, NOT a > descriptor counter. If we just fix this number at 100, and have it only > counting descriptors you could get all but the EOP descriptor of a packet > and then exit without finishing it and calling the stack, not a good > tactic. > > Having a limited count is still a good idea, but I think we still want > to base > it on packets and not just descriptors. > > Jesse also talked about their experience with the Linux driver, deciding > where to update the RDT, my current code doesnt do it til after the whole > while loop is completed (havent looked at CURRENT again today yet), > Jesse suggested doing it but not EVERY pass in the loop, maybe making > it mod the number of rx descriptors. Having that AND a fixed limit on the > number of total packets cleaned in a pass might be good. Good idea. Though for 1518 byte frames, I think you'll only have one descriptor per packet. Definitely need to do the right thing for jumbo frames, though. > > I was also thinking, maybe having the taskqueue code be selectable, but > not just a POLL vs TASKQUEUE, rather keep a legacy intr option which > has a POLL option within it. > > My motivation for doing that is I can take the TASKQUEUE code into the > Intel code base, but make it backward compatible, the default would have > it optioned off. > > Jack I had it that way initially, and I think you commented that it was ugly ;-) From owner-freebsd-net@FreeBSD.ORG Thu Oct 26 04:50:50 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 B814216A407; Thu, 26 Oct 2006 04:50:50 +0000 (UTC) (envelope-from suz@alaxala.net) Received: from pc1.alaxala.net (pc1.alaxala.net [203.178.142.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52A2A43D45; Thu, 26 Oct 2006 04:50:50 +0000 (GMT) (envelope-from suz@alaxala.net) Received: from localhost (localhost [127.0.0.1]) by pc1.alaxala.net (Postfix) with ESMTP id 62DC6B94B; Thu, 26 Oct 2006 13:50:48 +0900 (JST) X-Virus-Scanned: amavisd-new at alaxala.net Received: from pc1.alaxala.net ([127.0.0.1]) by localhost (pc1.alaxala.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZvZEL0ol5kV; Thu, 26 Oct 2006 13:50:42 +0900 (JST) Received: from flora220.uki-uki.net (pc2.alaxala.net [203.178.142.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pc1.alaxala.net (Postfix) with ESMTP id BA16AB82B; Thu, 26 Oct 2006 13:50:42 +0900 (JST) Date: Thu, 26 Oct 2006 13:50:41 +0900 Message-ID: From: SUZUKI Shinsuke To: chenxiaochen@emcite.com X-cite: xcite 1.33 In-Reply-To: <200610230941421092269@emcite.com> References: <200610181908570311458@emcite.com> <200610230941421092269@emcite.com> User-Agent: Wanderlust/2.15.1 (Almost Unreal) Emacs/22.0 Mule/5.0 (SAKAKI) Organization: Networking Technology Development Dept., ALAXALA Networks Corporation MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: gnn@freebsd.org, freebsd-net@freebsd.org Subject: Re: Problems under test of IPv6 Ready Logo Program Phase-2 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2006 04:50:50 -0000 Hi, >>>>> On Mon, 23 Oct 2006 09:41:57 -0700 >>>>> chenxiaochen@emcite.com("chenxiaochen") said: > > > 1. Section 5: RFC 2463 - ICMPv6 (snip) > In my opinion, rl1 should discard the packet and send a ICMP > packet-too-big message.But only discard ... That's not correct. ICMP packet-too-big is sent back to the source, when a router detects that the outgoing interface's MTU is too small. (please see RFC4443 3.2 Description) > > > 2. Section 2: RFC 2461 - Neighbor Discovery for IPv6 (snip) > I wander I set the vltime and pltime into fixed value mode by my configuration. > Would you pleas have a look of my steps? > -------------------------------- > default:\ > pim6dd.core :maxinterval#4:\ > pim6dd.core :mininterval#3:\ > pim6dd.core :chlim#0:\ > pim6dd.core :rltime#0:\ > pim6dd.core :rtime#0:\ > pim6dd.core :rtime#0:\ > pim6dd.core :vltime#0:\ > pim6dd.core :pltime#0: > > ether:\ > pim6dd.core :mtu#0:tc=default: > > rl0:\ > pim6dd.core :tc=ether: > --------------------------------- You have to specify prefix and prefix-length in the configuration, in addition to vltime and pltime. (please see man rtadvd.conf) > > > 3. Section 3: RFC 2462 - IPv6 Stateless Address Autoconfiguration (snip) > ---In my opinion, the way to disable auto-negotiation is to use > "ifconfig" or modify rc.conf. The latter can keep the change after > reboot. However, no DAD appear after I disable auto-negotiation. I > wander whether the way is wrong. I think you have to explicitly specify a link-local address, since net.inet6.ip6.auto_linklocal is set to 0. (as far as I see from your rc.conf, there's no such description) Thanks, ---- SUZUKI, Shinsuke @ KAME Project From owner-freebsd-net@FreeBSD.ORG Thu Oct 26 05:11:35 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 786C116A40F for ; Thu, 26 Oct 2006 05:11:35 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9164243D49 for ; Thu, 26 Oct 2006 05:11:34 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id c59so243054pyc for ; Wed, 25 Oct 2006 22:11:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kEeS21RaZZGBv1lQHrx+X4gaFWss5CIvmmNzbWlD0hHoGsKoG9I9tZ0hX+RjVRKgqL9Qt3zcWKoayu4+ReZvUs+rH+UUCXwemO9JUMp2fByLmorxoSsy+kSFHUpKHjcK0fMqow6HfZtxQGZE9PHb3Zr0Kudj1F9ozpQJZn+k4JQ= Received: by 10.35.78.13 with SMTP id f13mr2626112pyl; Wed, 25 Oct 2006 22:11:34 -0700 (PDT) Received: by 10.35.118.6 with HTTP; Wed, 25 Oct 2006 22:11:33 -0700 (PDT) Message-ID: <2a41acea0610252211w262e95c4k32e80d729475c0b9@mail.gmail.com> Date: Wed, 25 Oct 2006 22:11:33 -0700 From: "Jack Vogel" To: "Scott Long" In-Reply-To: <454009DF.5000704@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200610251818.k9PIIe7p062530@ambrisko.com> <2a41acea0610251736n16cc4188h489f6d953130f91a@mail.gmail.com> <454009DF.5000704@samsco.org> Cc: freebsd-net , John Polstra Subject: Re: em network issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2006 05:11:35 -0000 On 10/25/06, Scott Long wrote: > Jack Vogel wrote: > > On 10/25/06, Doug Ambrisko wrote: > > > >> 3) In em_process_receive_interrupts/em_rxeof always decrement > >> the count on every run through the loop. If you notice > >> count is an is an int that starts at the passed in value > >> of -1. It then count-- until count==0. Doing -1, -2, -3 > >> takes awhile until the int rolls over to 0. Passing 100 > >> limits it more :-) So this can run 3 * 100 versuses > >> infinite * int roll over assuming we don't skip a count--. > > > > Been chatting with Jesse Brandeburg (one of our senior Linux guys) about > > receive side cleaning. Gave me a number of things to think about. First > > off, > > this change you mention is problematic. The reason it doesnt increment > > every time thru the while loop is its meant as a packet counter, NOT a > > descriptor counter. If we just fix this number at 100, and have it only > > counting descriptors you could get all but the EOP descriptor of a packet > > and then exit without finishing it and calling the stack, not a good > > tactic. > > > > Having a limited count is still a good idea, but I think we still want > > to base > > it on packets and not just descriptors. > > > > Jesse also talked about their experience with the Linux driver, deciding > > where to update the RDT, my current code doesnt do it til after the whole > > while loop is completed (havent looked at CURRENT again today yet), > > Jesse suggested doing it but not EVERY pass in the loop, maybe making > > it mod the number of rx descriptors. Having that AND a fixed limit on the > > number of total packets cleaned in a pass might be good. > > Good idea. Though for 1518 byte frames, I think you'll only have one > descriptor per packet. Definitely need to do the right thing for jumbo > frames, though. > > > > > I was also thinking, maybe having the taskqueue code be selectable, but > > not just a POLL vs TASKQUEUE, rather keep a legacy intr option which > > has a POLL option within it. > > > > My motivation for doing that is I can take the TASKQUEUE code into the > > Intel code base, but make it backward compatible, the default would have > > it optioned off. > > > > Jack > > I had it that way initially, and I think you commented that it was ugly > ;-) Naaahhhh, couldnt be, I'd never do anything like that :) OHHHH, I know what you're talking about. When I first started this job a year ago the driver was just PEPPERED with all these #if _FreeBSD_Version < BladdyFoo or something like that. I think the Intel code base was even worse cuz Tony was trying to make a single source base for 4.X and 5.X at that point. It was a major pain to look at that code :) What I'm talking about is a simple #ifdef EM_FASTINTR or something like that, no defines that remind me of POSIX header files please :) Jack From owner-freebsd-net@FreeBSD.ORG Thu Oct 26 05:15:49 2006 Return-Path: X-Original-To: freebsd-net@FreeBSD.org 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 1DD6116A407 for ; Thu, 26 Oct 2006 05:15:49 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 901E743D4C for ; Thu, 26 Oct 2006 05:15:48 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id A734861FEDA; Thu, 26 Oct 2006 15:15:42 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (Postfix) with ESMTP id 171468C30; Thu, 26 Oct 2006 15:15:40 +1000 (EST) Date: Thu, 26 Oct 2006 15:15:35 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Doug Ambrisko In-Reply-To: <200610251818.k9PIIe7p062530@ambrisko.com> Message-ID: <20061026134024.Y6316@delplex.bde.org> References: <200610251818.k9PIIe7p062530@ambrisko.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net , Scott Long , John Polstra Subject: Re: em network issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2006 05:15:49 -0000 On Wed, 25 Oct 2006, Doug Ambrisko wrote: > John Polstra writes: > | On 19-Oct-2006 Scott Long wrote: > | > The performance measurements that Andre and I did early this year showed > | > that the INTR_FAST handler provided a very large benefit. > | > | I'm trying to understand why that's the case. Is it because an > | INTR_FAST interrupt doesn't have to be masked and unmasked in the > | APIC? I can't see any other reason for much of a performance > | difference in that driver. With or without INTR_FAST, you've got > | the bulk of the work being done in a background thread -- either the > | ithread or the taskqueue thread. It's not clear to me that it's any > | cheaper to run a task than it is to run an ithread. > | ... The answer was given indirectly in a previous reply: its cost is insignifcantly different, but it gives more parallelism, so in some configurations (mainly ones with more CPU than I/O) it gives more I/O bandwidth. ("it" == just INTR_FAST vs normal interrupts with an identical interrupt handler.) > Something that we've fixed locally in atleast one version is: > 1) Limit the loop in em_intr to 3 iterations > 2) Pass a valid value to em_process_receive_interrupts/em_rxeof > a good value like 100 instead of -1. Since this is the count > for how many time to iterate over the rx stuff. Seems this > got lost in the some change of APIs. > 3) In em_process_receive_interrupts/em_rxeof always decrement > the count on every run through the loop. If you notice > count is an is an int that starts at the passed in value > of -1. It then count-- until count==0. Doing -1, -2, -3 > takes awhile until the int rolls over to 0. Passing 100 > limits it more :-) So this can run 3 * 100 versuses > infinite * int roll over assuming we don't skip a count--. > Doing these changes made our multiple em based machines a lot happier > when slammed with traffic without starving other things that shared > interrupts like other em cards (especially in 4.X). This basically works in the opposite way, by giving less parallelism, so in some configurations (mainly ones with less CPU than I/O) it gives less I/O bandwidth and thus frees some CPU for doing something other than I/O. I don't understand why simple limits on the counts make much difference. Returning prematurely from the interrupt handler is normally a bad idea, since unless you have disabled interrupts then you get another interrupt which returns you to the interrupt handler immediately, and the only effect of returning immediately is extra cost for the return and reentry. The hardware should refrain from generating a new interrupt if you handle enough rx+tx descriptors, but if you can't keep up then this won't help for more than one burst in bursty traffic, and with bursty traffic that can be kept up with on average there will be enough CPU for other things eventually. > Interrupt handler > should have limits of how long they should be able to run then let > someone else go. SWI threads or tasks plus scheduling of tasks should give this automatically in -current. I think this is the right way to go once you accept the large overhead of context switches to get to ithreads (I don't accept this :-). However, ithreads have fixed priorities, and em's interrupt task has the highest priority that is actually used, so the em task is rarely if ever preempted in -current. > We use this in 6.X as well and haven't had any problems > with our config's that use this. We haven't tested much without these > since we need to fix other issues and this is now a non-issue for us. > ... 6.X has a fast interrupt handler for em so it is quite different from 6.1. > I haven't pushed this more since I first found issue 1 and the concept > was rejected ... my machine hung in the interrupt spin loop :-( ~5.2 has hard-coded 3 calls to the rx+tx interrupt sub-handlers, but this seems to be bogus. em_intr() in -current (for the DEVICE_POLLING configured but not enabled case) cdoes the natural check of a status register to determine whether it should keep calling the sub-handlers, and has no limit on the number of calls except for the status register. This should only hang if there is always more em-I/O than CPU, or the status register is broken. Without DEVICE_POLLING, the reasons for the hang would be slightly different. Bruce From owner-freebsd-net@FreeBSD.ORG Thu Oct 26 05:20:23 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 2BF7216A407 for ; Thu, 26 Oct 2006 05:20:23 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9FF843D58 for ; Thu, 26 Oct 2006 05:20:22 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k9Q5IQXk095238; Wed, 25 Oct 2006 23:18:32 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <45404522.6000001@samsco.org> Date: Wed, 25 Oct 2006 23:18:26 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Jack Vogel References: <200610251818.k9PIIe7p062530@ambrisko.com> <2a41acea0610251736n16cc4188h489f6d953130f91a@mail.gmail.com> <454009DF.5000704@samsco.org> <2a41acea0610252211w262e95c4k32e80d729475c0b9@mail.gmail.com> In-Reply-To: <2a41acea0610252211w262e95c4k32e80d729475c0b9@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net , John Polstra Subject: Re: em network issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2006 05:20:23 -0000 Jack Vogel wrote: > On 10/25/06, Scott Long wrote: >> Jack Vogel wrote: >> > On 10/25/06, Doug Ambrisko wrote: >> > >> >> 3) In em_process_receive_interrupts/em_rxeof always decrement >> >> the count on every run through the loop. If you notice >> >> count is an is an int that starts at the passed in value >> >> of -1. It then count-- until count==0. Doing -1, -2, -3 >> >> takes awhile until the int rolls over to 0. Passing 100 >> >> limits it more :-) So this can run 3 * 100 versuses >> >> infinite * int roll over assuming we don't skip a count--. >> > >> > Been chatting with Jesse Brandeburg (one of our senior Linux guys) >> about >> > receive side cleaning. Gave me a number of things to think about. First >> > off, >> > this change you mention is problematic. The reason it doesnt increment >> > every time thru the while loop is its meant as a packet counter, NOT a >> > descriptor counter. If we just fix this number at 100, and have it only >> > counting descriptors you could get all but the EOP descriptor of a >> packet >> > and then exit without finishing it and calling the stack, not a good >> > tactic. >> > >> > Having a limited count is still a good idea, but I think we still want >> > to base >> > it on packets and not just descriptors. >> > >> > Jesse also talked about their experience with the Linux driver, >> deciding >> > where to update the RDT, my current code doesnt do it til after the >> whole >> > while loop is completed (havent looked at CURRENT again today yet), >> > Jesse suggested doing it but not EVERY pass in the loop, maybe making >> > it mod the number of rx descriptors. Having that AND a fixed limit >> on the >> > number of total packets cleaned in a pass might be good. >> >> Good idea. Though for 1518 byte frames, I think you'll only have one >> descriptor per packet. Definitely need to do the right thing for jumbo >> frames, though. >> >> > >> > I was also thinking, maybe having the taskqueue code be selectable, but >> > not just a POLL vs TASKQUEUE, rather keep a legacy intr option which >> > has a POLL option within it. >> > >> > My motivation for doing that is I can take the TASKQUEUE code into the >> > Intel code base, but make it backward compatible, the default would >> have >> > it optioned off. >> > >> > Jack >> >> I had it that way initially, and I think you commented that it was ugly >> ;-) > > Naaahhhh, couldnt be, I'd never do anything like that :) > > OHHHH, I know what you're talking about. When I first started this job a > year > ago the driver was just PEPPERED with all these #if _FreeBSD_Version < > BladdyFoo > or something like that. I think the Intel code base was even worse cuz > Tony was > trying to make a single source base for 4.X and 5.X at that point. It > was a major > pain to look at that code :) > > What I'm talking about is a simple #ifdef EM_FASTINTR or something like > that, > no defines that remind me of POSIX header files please :) > > Jack Yes, that's almost exactly what was there! It was #ifndef NO_EM_FASTINTR Anywho... From owner-freebsd-net@FreeBSD.ORG Thu Oct 26 06:44:24 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 7C40D16A407 for ; Thu, 26 Oct 2006 06:44:24 +0000 (UTC) (envelope-from ozkan@mersin.edu.tr) Received: from mail.mersin.edu.tr (mail.mersin.edu.tr [193.255.128.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id F28A843D49 for ; Thu, 26 Oct 2006 06:44:23 +0000 (GMT) (envelope-from ozkan@mersin.edu.tr) Received: from localhost (localhost.mersin.edu.tr [127.0.0.1]) by mail.mersin.edu.tr (Postfix) with ESMTP id 095E74552B for ; Thu, 26 Oct 2006 09:36:11 +0300 (EEST) X-Virus-Scanned: by amavisd-new at mersin.edu.tr Received: from mail.mersin.edu.tr ([127.0.0.1]) by localhost (mail.mersin.edu.tr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8EQb0F3wIoD for ; Thu, 26 Oct 2006 09:35:56 +0300 (EEST) Received: from localhost (localhost.mersin.edu.tr [127.0.0.1]) by mail.mersin.edu.tr (Postfix) with SMTP id EECFF4539A for ; Thu, 26 Oct 2006 09:35:55 +0300 (EEST) To: From: Date: Thu, 26 Oct 2006 09:35:55 EEST Errors-To: X-Priority: 3 (Normal) X-Originating-Ip: [10.0.11.44] X-Mailer: NOCC v0.9.5 Content-Type: text/plain; charset="ISO-8859-9" Content-Transfer-Encoding: 8bit Message-Id: <20061026063555.EECFF4539A@mail.mersin.edu.tr> Subject: 6.1 STABLE Strangely Hangs when VLAN enabled. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ozkan@mersin.edu.tr List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2006 06:44:24 -0000 Hi, I have a HP DL380-G4 server. Single Xeon 3.0Ghz cpu, two onboard bge NICs and one dual em NIC. I am using vlan interfaces on bge0 (there is 9 vlan interface on bge0). But systems hangs at a random time without any logs/errors and even panic message! Before system hangs everything works normally. (OS: 6.1 STABLE-200609) After this problem I tried 6.1 STABLE-200607. Same result! After removing vlan support from kernel, everything became normal. I installed same system to another pc (P4-1.4Ghz NICs: rl). When VLAN enabled, system hangs at a random time again. I got crazy. What the problem can be? How can i debug the problem? Used These Options on That Kernel: options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100000 options IPFIREWALL_DEFAULT_TO_ACCEPT options IPDIVERT options DUMMYNET options IPSTEALTH options TCP_DROP_SYNFIN options NETGRAPH options LIBALIAS options NETGRAPH_NAT options NETGRAPH_IPFW options NETGRAPH_SOCKET options NETGRAPH_IFACE options NETGRAPH_PPP options NETGRAPH_BPF options NETGRAPH_VJC options GEOM_BDE device vlan Have an idea? Thanks by now. Ozkan KIRIK From owner-freebsd-net@FreeBSD.ORG Thu Oct 26 06:50:57 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 9CEB816A407; Thu, 26 Oct 2006 06:50:57 +0000 (UTC) (envelope-from jan@melen.org) Received: from foxgw.melen.org (Savi-Mel.dna.fi [83.143.60.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBDD343D4C; Thu, 26 Oct 2006 06:50:56 +0000 (GMT) (envelope-from jan@melen.org) Received: from localhost ([IPv6:2001:14b8:400:f00::ffff]) (authenticated bits=0) by foxgw.melen.org (8.13.8/8.13.7) with ESMTP id k9Q6odKq079375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Oct 2006 09:50:54 +0300 (EEST) (envelope-from jan@melen.org) From: Jan Mikael Melen To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org Date: Thu, 26 Oct 2006 09:52:09 +0300 User-Agent: KMail/1.9.4 References: <200608092157.07573.jan@melen.org> In-Reply-To: <200608092157.07573.jan@melen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200610260952.10413.jan@melen.org> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on foxgw.melen.org X-Virus-Status: Clean Cc: Subject: Re: Problem with routes when configuring IPv6 addresses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2006 06:50:57 -0000 Hi, Just answering my own mail. Here is small patch that fixes this problem for us in 6.1. --- nd6_rtr.c.orig Mon Mar 20 18:23:08 2006 +++ nd6_rtr.c Thu Oct 26 09:48:59 2006 @@ -1409,12 +1409,20 @@ if (pr->ndpr_raf_onlink == 0) continue; - if ((pr->ndpr_stateflags & NDPRF_DETACHED) == 0 && + /* For some reason nd6 tries to find a active + * advertising router also for prefixes that are + * statically configured which shouldn't be the case + */ + if (pr->ndpr_vltime == ND6_INFINITE_LIFETIME) { + pr->ndpr_stateflags &= ~NDPRF_DETACHED; + } else { + if ((pr->ndpr_stateflags & NDPRF_DETACHED) == 0 && find_pfxlist_reachable_router(pr) == NULL) pr->ndpr_stateflags |= NDPRF_DETACHED; if ((pr->ndpr_stateflags & NDPRF_DETACHED) != 0 && find_pfxlist_reachable_router(pr) != 0) pr->ndpr_stateflags &= ~NDPRF_DETACHED; + } } } else { /* there is no prefix that has a reachable router */ On Wednesday 09 August 2006 21:57, Jan Mikael Melen wrote: > Hello, > > I previously already sent this to the freebsd-net list but didn't get any > response so let's try the hackers list instead. > > I have a problem with routes in 6.1 when configuring IPv6 address using > both autoconfigured addresses at the same time with statically configured > addresses from different prefixes. > > If the host is not accepting router advertisements everything seems to work > fine: > # sysctl -a | grep rtad > net.inet6.ip6.accept_rtadv: 0 > # ifconfig fxp0 inet6 3ffe:101::1 prefixlen 64 > > # netstat -rn -f inet6 | grep 3ffe:101 > 3ffe:101::/64 link#1 UC > fxp0 > 3ffe:101::1 00:12:3f:71:3e:ef UHL > lo0 > # > > As you can see I have two routes one for the loopback and one for the > prefix as it should GREAT! > > Now if I'll set the host to accept router advertisements then the route for > the 3ffe:101:: prefix will be deleted as the first router advertisement is > received. The router advertises prefix 3ffe:14b8:400:101::/64. > > # sysctl net.inet6.ip6.accept_rtadv=1 > net.inet6.ip6.accept_rtadv: 0 -> 1 > # rtsol -a > # netstat -rn -f inet6 | grep 3ffe:101 > 3ffe:101::1 00:12:3f:71:3e:ef UHL > lo0 > # > > It seems that the route is deleted because in function > pfxlist_onlink_check() there is a check that if the state has changed to > DETACHED the > nd6_prefix_offlink will be called which then removes the route: > if ((pr->ndpr_stateflags & NDPRF_DETACHED) != 0 && > (pr->ndpr_stateflags & NDPRF_ONLINK) != 0) { > if ((e = nd6_prefix_offlink(pr)) != 0) { > nd6log((LOG_ERR, > "pfxlist_onlink_check: failed to " > "make %s/%d offlink, errno=%d\n", > ip6_sprintf(&pr->ndpr_prefix.sin6_addr), > pr->ndpr_plen, e)); > } > } > > This far I digged in to the code but then ran out of steam :-( Obviously > the state should not be set to DETACHED for manually configured prefixes > but the question is rather where it should be done. > > Before somebody asks, if I first do the autoconfiguration part and then > after I have the autoconfigured address add the manually configured address > the result is that there wont be any route for the manually configured > prefix (3ffe:101::/64). > > Regards, > Jan > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Oct 26 09:47:40 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 BC2C716A412 for ; Thu, 26 Oct 2006 09:47:40 +0000 (UTC) (envelope-from ozkan@mersin.edu.tr) Received: from mail.mersin.edu.tr (mail.mersin.edu.tr [193.255.128.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 320B643D6A for ; Thu, 26 Oct 2006 09:47:39 +0000 (GMT) (envelope-from ozkan@mersin.edu.tr) Received: from localhost (localhost.mersin.edu.tr [127.0.0.1]) by mail.mersin.edu.tr (Postfix) with ESMTP id 27C3E45595; Thu, 26 Oct 2006 12:39:57 +0300 (EEST) X-Virus-Scanned: by amavisd-new at mersin.edu.tr Received: from mail.mersin.edu.tr ([127.0.0.1]) by localhost (mail.mersin.edu.tr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oaxnCeT8ED-7; Thu, 26 Oct 2006 12:39:37 +0300 (EEST) Received: from localhost (localhost.mersin.edu.tr [127.0.0.1]) by mail.mersin.edu.tr (Postfix) with SMTP id 16F13455A4; Thu, 26 Oct 2006 12:30:57 +0300 (EEST) To: From: Date: Thu, 26 Oct 2006 12:30:57 EEST Errors-To: X-Priority: 3 (Normal) X-Originating-Ip: [10.0.11.44] X-Mailer: NOCC v0.9.5 Content-Type: text/plain; charset="ISO-8859-9" Content-Transfer-Encoding: 8bit Message-Id: <20061026093057.16F13455A4@mail.mersin.edu.tr> Cc: rmkml Subject: Ynt: Re: 6.1 STABLE Strangely Hangs when VLAN enabled. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ozkan@mersin.edu.tr List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2006 09:47:40 -0000 Hi, Freebsd 61 hangs 4-5 times per day, i didnt test via single vlan. i have no crash dump, even makeoptions=-g configured. kernel doesnt panic, system only hangs :( I tried both Hyperthreading enabled/disabled. I tried both SMP Kernel / Non-SMP Kernel. The answer is same. This server's job is mainly a DMZ Firewall. Jobs: - apache2.0 for web management - ng_nat (nat for each vlan, 9 ng_nat configured) - two natd daemon for port forwarding and static nat - dhcpd - only ipfw - vlan logic interfaces used for ipfw rules - ipfw tables used - mpd for incoming vpn connections - bge0 is connected to LAN (VLAN is on this interface) - bge1 is connected to ATM Router directly - em0 is connected to DMZ Switch - em1 is disconnected Thanks for your interests Best Regards, Ozkan KIRIK Rmkml : > Hi ozkan, > how many times per day freebsd61 hang ? > if you only 1 vlan, do you have hang ? (two ?, three ?...) > do you have crash dump ? > you have one physical processor, but do you have hypertreading enabled ? > what jobs srv have ? (vlan ok, ipfw ?, ipfilter ?, pf ?, smtp ?, ....) > possible check with top/netstat if you memory fill ? > do you use ipfw/ipf/pf with vlan logic interface ? > do you use two bge interface or only one ? > same question for two em interface ? > Best Regards > Rmkml > > > On Thu, 26 Oct 2006, ozkan@mersin.edu.tr > wrote: > > > Date: Thu, 26 Oct 2006 09:35:55 EEST > > From: ozkan@mersin.edu.tr > > To: freebsd-net@freebsd.org > > Subject: 6.1 STABLE Strangely Hangs when VLAN enabled. > > > > Hi, > > > > I have a HP DL380-G4 server. > > Single Xeon 3.0Ghz cpu, two onboard bge NICs and one dual em NIC. > > > > I am using vlan interfaces on bge0 (there is 9 vlan interface on bge0). But > systems hangs at a random time without any logs/errors and even panic message! > Before system hangs everything works normally. (OS: 6.1 STABLE-200609) > > After this problem I tried 6.1 STABLE-200607. Same result! > > > > After removing vlan support from kernel, everything became normal. > > > > I installed same system to another pc (P4-1.4Ghz NICs: rl). > > When VLAN enabled, system hangs at a random time again. > > I got crazy. > > > > What the problem can be? How can i debug the problem? > > > > > > Used These Options on That Kernel: > > > > options IPFIREWALL > > options IPFIREWALL_VERBOSE > > options IPFIREWALL_VERBOSE_LIMIT=100000 > > options IPFIREWALL_DEFAULT_TO_ACCEPT > > options IPDIVERT > > options DUMMYNET > > options IPSTEALTH > > options TCP_DROP_SYNFIN > > options NETGRAPH > > options LIBALIAS > > options NETGRAPH_NAT > > options NETGRAPH_IPFW > > options NETGRAPH_SOCKET > > options NETGRAPH_IFACE > > options NETGRAPH_PPP > > options NETGRAPH_BPF > > options NETGRAPH_VJC > > options GEOM_BDE > > device vlan > > > > Have an idea? > > > > Thanks by now. > > > > Ozkan KIRIK > > > > > > > > > > > > _______________________________________________ > > 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 Thu Oct 26 23:40:20 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 EF04E16A403 for ; Thu, 26 Oct 2006 23:40:08 +0000 (UTC) (envelope-from smw2010@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7114D43D55 for ; Thu, 26 Oct 2006 23:40:07 +0000 (GMT) (envelope-from smw2010@gmail.com) Received: by nz-out-0102.google.com with SMTP id o37so442121nzf for ; Thu, 26 Oct 2006 16:40:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=V61puB19QR0lkhDyZ01ux0VAuU583UqzlrYiGm2Bh9yeXLy+Xbs7IJwwKIRWMO315et6iew0+UvjOgaTqraYjsFxbppLI06rTHpSITL1X0WpGPAnvMG1WwqJawETvfPZhr9XVfLNVsxZyBpHna1mxqxA6tmlJyYiVFUAANX+y+0= Received: by 10.64.250.3 with SMTP id x3mr4080568qbh; Thu, 26 Oct 2006 16:40:06 -0700 (PDT) Received: by 10.65.241.10 with HTTP; Thu, 26 Oct 2006 16:40:06 -0700 (PDT) Message-ID: Date: Fri, 27 Oct 2006 09:40:06 +1000 From: "Sam Wun" To: ozkan@mersin.edu.tr In-Reply-To: <20061026063555.EECFF4539A@mail.mersin.edu.tr> MIME-Version: 1.0 References: <20061026063555.EECFF4539A@mail.mersin.edu.tr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: 6.1 STABLE Strangely Hangs when VLAN enabled. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2006 23:40:20 -0000 Can you test this in 6.2-Prerelease? On 10/26/06, ozkan@mersin.edu.tr wrote: > > Hi, > > I have a HP DL380-G4 server. > Single Xeon 3.0Ghz cpu, two onboard bge NICs and one dual em NIC. > > I am using vlan interfaces on bge0 (there is 9 vlan interface on bge0). > But systems hangs at a random time without any logs/errors and even panic > message! Before system hangs everything works normally. (OS: 6.1STABLE-200609) > After this problem I tried 6.1 STABLE-200607. Same result! > > After removing vlan support from kernel, everything became normal. > > I installed same system to another pc (P4-1.4Ghz NICs: rl). > When VLAN enabled, system hangs at a random time again. > I got crazy. > > What the problem can be? How can i debug the problem? > > > Used These Options on That Kernel: > > options IPFIREWALL > options IPFIREWALL_VERBOSE > options IPFIREWALL_VERBOSE_LIMIT=100000 > options IPFIREWALL_DEFAULT_TO_ACCEPT > options IPDIVERT > options DUMMYNET > options IPSTEALTH > options TCP_DROP_SYNFIN > options NETGRAPH > options LIBALIAS > options NETGRAPH_NAT > options NETGRAPH_IPFW > options NETGRAPH_SOCKET > options NETGRAPH_IFACE > options NETGRAPH_PPP > options NETGRAPH_BPF > options NETGRAPH_VJC > options GEOM_BDE > device vlan > > Have an idea? > > Thanks by now. > > Ozkan KIRIK > > > > > > _______________________________________________ > 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 Thu Oct 26 23:43:18 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 C16AD16A407 for ; Thu, 26 Oct 2006 23:43:18 +0000 (UTC) (envelope-from smw2010@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 383B043D55 for ; Thu, 26 Oct 2006 23:43:18 +0000 (GMT) (envelope-from smw2010@gmail.com) Received: by nz-out-0102.google.com with SMTP id o37so442521nzf for ; Thu, 26 Oct 2006 16:43:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=B9PAH2x1SEgOp950A6foclq3cL/TbOvE3Jarvz2PUyUJlaGJq1NUOW8h3U7NVgoKTGf1iKxJ9vkktjfPvv+DPKy15j9NI1AhqE2bUW5hA48SKR7bQOuZtLzORakB+03e95ZUVpbo4m5an3hO8XkQwPbNf0NPLV0mrVU6n4TCUCc= Received: by 10.65.38.13 with SMTP id q13mr4036115qbj; Thu, 26 Oct 2006 16:43:17 -0700 (PDT) Received: by 10.65.241.10 with HTTP; Thu, 26 Oct 2006 16:43:17 -0700 (PDT) Message-ID: Date: Fri, 27 Oct 2006 09:43:17 +1000 From: "Sam Wun" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: check internet connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2006 23:43:18 -0000 Hi, I want to write a C program to check freebsd's internet connection. What s the best way to achieve this checking in layer 2 or 3 of the tcp/ip stacks in freebsd? Thanks S From owner-freebsd-net@FreeBSD.ORG Fri Oct 27 06:48:07 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 2E25E16A407 for ; Fri, 27 Oct 2006 06:48:07 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from mail01.solnet.ch (mail01.solnet.ch [212.101.4.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0A5543D46 for ; Fri, 27 Oct 2006 06:48:06 +0000 (GMT) (envelope-from freebsdlists@bsdunix.ch) X-Virus-Scanned: by amavisd-new at mail01.solnet.ch Received: from mail01.solnet.ch ([127.0.0.1]) by localhost (mail01.solnet.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id F5bbP1DwWVEK for ; Fri, 27 Oct 2006 06:48:02 +0000 (GMT) Received: from [192.168.1.102] (home.bsdunix.ch [82.220.17.23]) by mail01.solnet.ch (Postfix) with ESMTP id 91C3E62582 for ; Fri, 27 Oct 2006 06:48:01 +0000 (GMT) Message-ID: <4541AB5C.2060009@bsdunix.ch> Date: Fri, 27 Oct 2006 08:46:52 +0200 From: Thomas User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: paket loss on freebsd router if (b)snmpd is running X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 06:48:07 -0000 Hello I use several 5.4 and 6.1 FBSD machines as router (with quagga). The average traffic is 300mbit/s (em interfaces with polling enabled). It works more or less. Problem: If bsnmpd is running and I'm doing a snmpwalk from a remote machine the router has some significant packet loss. We are talking about 3-15% of packet loss. It's a simple snmpwalk (ipRouteTable and the interfaces stats). The CPU load is always pretty low no matter if snmpd is running or not. I have this problem with 5.x and 6.x Any idea who I can fix this or debug it in a better way? loader.conf: hint.acpi.0.disabled="1" beastie_disable="YES" autoboot_delay="2" kern.ipc.nmbclusters="32768" sysctl.conf: vm.swap_enabled=0 # no swap space kern.ipc.somaxconn=8192 # increased from 1024 kern.polling.enable=1 # interface polling kern.polling.user_frac=20 # reserve this much for userland kern.polling.burst_max=300 # Upper bound for the burst size kern.random.sys.harvest.ethernet=0 kern.random.sys.harvest.interrupt=0 net.inet.udp.recvspace=65536 net.inet.tcp.sendspace=65536 net.inet.udp.maxdgram=57344 # new net.local.stream.recvspace=65535 # new net.local.stream.sendspace=65535 # new net.inet.tcp.delayed_ack=0 # no delayed ACKs net.inet.tcp.msl=5000 # go away after 5 seconds net.isr.enable=1 net.inet.ip.maxfragpackets=40 # don't accept too many net.inet.ip.maxfragsperpacket=4 # only 4 fragments per packet net.inet.ip.fw.one_pass=0 # continue after dummynet net.inet.ip.fw.dyn_max=8192 net.inet.ip.fw.dyn_udp_lifetime=15 net.inet.ip.fastforwarding=1 # forwarding enable net.inet.ip.forwarding=1 net.inet.icmp.icmplim=50 # ICMP Unreach limit to 50 dmesg: 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-RELEASE-p2 #0: Thu Jun 30 13:28:06 UTC 2005 root@bb-router.foobar:/mnt/obj/mnt/src/sys/UPROUTER Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2399.33-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf25 Stepping = 5 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 1073217536 (1023 MB) avail memory = 1044848640 (996 MB) npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 pci0: at device 0.1 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pci1: at device 28.0 (no driver attached ) pcib2: at device 29.0 on pci1 pci2: on pcib2 em0: port 0x3000-0x303f mem 0xfc200000-0xfc21ffff irq 5 at device 3.0 on pci2 em0: Ethernet address: 00:30:48:2c:6e:9a em0: Speed:N/A Duplex:N/A em1: port 0x3040-0x307f mem 0xfc220000-0xfc23ffff irq 5 at device 3.1 on pci2 em1: Ethernet address: 00:30:48:2c:6e:9b em1: Speed:N/A Duplex:N/A pci1: at device 30.0 (no driver attached ) pcib3: at device 31.0 on pci1 pci3: on pcib3 atapci0: port 0x4000-0x400f,0x4020-0x4023,0x4028-0 x402f,0x4024-0x4027,0x4030-0x4037 mem 0xfc300000-0xfc3001ff irq 5 at device 2.0 on pci3 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 atapci1: port 0x4010-0x401f,0x4038-0x403b,0x4040-0 x4047,0x403c-0x403f,0x4048-0x404f mem 0xfc300400-0xfc3005ff irq 5 at device 3.0 on pci3 ata4: channel #0 on atapci1 ata5: channel #1 on atapci1 pci0: at device 29.0 (no driver attached) pci0: at device 29.1 (no driver attached) pci0: at device 29.2 (no driver attached) pcib4: at device 30.0 on pci0 pci4: on pcib4 pci4: at device 1.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci2: port 0x2060-0x206f,0x376,0x170-0x177,0x 3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci2 ata1: channel #1 on atapci2 pci0: at device 31.3 (no driver attached) orm0: at iomem 0xe0000-0xe3fff,0xc9000-0xcd7ff,0xc8000-0xc8fff ,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: at port 0x3f0-0x3f5 irq 6 drq 2 on isa0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounter "TSC" frequency 2399328688 Hz quality 800 Timecounters tick every 1.000 msec IPv6 packet filtering initialized, logging limited to 100 packets/entry Fast IPsec: Initialized Security Association Processing. ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to ac cept, logging limited to 100 packets/entry by default ad0: FAILURE - SETFEATURES ENABLE RCACHE status=51 error=4 ad0: FAILURE - SETFEATURES ENABLE WCACHE status=51 error=4 ad0: 497MB [1010/16/63] at ata0-master PIO4 acd0: CDROM at ata1-master PIO4 em0: Link is up 1000 Mbps Full Duplex em1: Link is up 1000 Mbps Full Duplex ad10: 35304MB [71730/16/63] at ata5-master SATA150 Mounting root from ufs:/dev/ad0s1a Regards, Thomas From owner-freebsd-net@FreeBSD.ORG Fri Oct 27 07:46:04 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 1CB8E16A403 for ; Fri, 27 Oct 2006 07:46:04 +0000 (UTC) (envelope-from snb@threerings.net) Received: from a.mail.sonic.net (a.mail.sonic.net [64.142.16.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB6D343D5A for ; Fri, 27 Oct 2006 07:46:03 +0000 (GMT) (envelope-from snb@threerings.net) Received: from [192.168.1.101] (c-67-169-22-25.hsd1.ca.comcast.net [67.169.22.25]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k9R7k3Tr012708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 27 Oct 2006 00:46:03 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <9C9DCC39-27DD-4642-A503-BAD720301597@threerings.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-net@freebsd.org From: Nick Barkas Date: Fri, 27 Oct 2006 00:45:45 -0700 X-Mailer: Apple Mail (2.752.3) Subject: patch to support setting carp state with ifconfig X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 07:46:04 -0000 Hello- A few months ago I wrote a small patch that allows ifconfig to explicitly set a carp device to MASTER or BACKUP state. The code is based upon OpenBSD's ifconfig, which has this feature. This is handy for situations where you want an active carp interface to fail over to/take over from the other host, perhaps for testing purposes or if you have a failed master you've brought back up that you want to take over again for a currently active slave host. The patch is attached to this PR: http://www.freebsd.org/cgi/query- pr.cgi?pr=100956. No one has sent any followups to the PR, but I thought there may be someone on this list interested in having this feature added. Nick From owner-freebsd-net@FreeBSD.ORG Fri Oct 27 08:47:06 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 53D2B16A416 for ; Fri, 27 Oct 2006 08:47:06 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B02A43D67 for ; Fri, 27 Oct 2006 08:47:00 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from knop-beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 10:46:59 +0200 Date: Fri, 27 Oct 2006 10:46:56 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@knop-beagle.kn.op.dlr.de To: Thomas In-Reply-To: <4541AB5C.2060009@bsdunix.ch> Message-ID: <20061027104553.D27619@knop-beagle.kn.op.dlr.de> References: <4541AB5C.2060009@bsdunix.ch> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 27 Oct 2006 08:46:59.0152 (UTC) FILETIME=[76E83500:01C6F9A4] Cc: freebsd-net@freebsd.org Subject: Re: paket loss on freebsd router if (b)snmpd is running##SPAM X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 08:47:06 -0000 On Fri, 27 Oct 2006, Thomas wrote: T>Hello T> T>I use several 5.4 and 6.1 FBSD machines as router (with quagga). The T>average traffic is 300mbit/s (em interfaces with polling enabled). It T>works more or less. T> T>Problem: T>If bsnmpd is running and I'm doing a snmpwalk from a remote machine the T>router has some significant packet loss. We are talking about 3-15% of T>packet loss. It's a simple snmpwalk (ipRouteTable and the interfaces stats). Does this happen also if you walk only the interface tables? What size is your routing table? harti From owner-freebsd-net@FreeBSD.ORG Fri Oct 27 15:34:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 E6AEB16A47E; Fri, 27 Oct 2006 15:34:37 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from mail01.solnet.ch (mail01.solnet.ch [212.101.4.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7600743D5F; Fri, 27 Oct 2006 15:34:37 +0000 (GMT) (envelope-from freebsdlists@bsdunix.ch) X-Virus-Scanned: by amavisd-new at mail01.solnet.ch Received: from mail01.solnet.ch ([127.0.0.1]) by localhost (mail01.solnet.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4F7vQfD1PeKs; Fri, 27 Oct 2006 15:34:33 +0000 (GMT) Received: from [192.168.1.102] (home.bsdunix.ch [82.220.17.23]) by mail01.solnet.ch (Postfix) with ESMTP id 34F7E6268C; Fri, 27 Oct 2006 15:34:33 +0000 (GMT) Message-ID: <454226C7.10505@bsdunix.ch> Date: Fri, 27 Oct 2006 17:33:27 +0200 From: Thomas User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Harti Brandt References: <4541AB5C.2060009@bsdunix.ch> <20061027104553.D27619@knop-beagle.kn.op.dlr.de> In-Reply-To: <20061027104553.D27619@knop-beagle.kn.op.dlr.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: paket loss on freebsd router if (b)snmpd is running##SPAM X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 15:34:38 -0000 Hello Harti Harti Brandt schrieb: > On Fri, 27 Oct 2006, Thomas wrote: > > T>Hello > T> > T>I use several 5.4 and 6.1 FBSD machines as router (with quagga). The > T>average traffic is 300mbit/s (em interfaces with polling enabled). It > T>works more or less. > T> > T>Problem: > T>If bsnmpd is running and I'm doing a snmpwalk from a remote machine the > T>router has some significant packet loss. We are talking about 3-15% of > T>packet loss. It's a simple snmpwalk (ipRouteTable and the interfaces stats). > > Does this happen also if you walk only the interface tables? What size is > your routing table? The routing table has approx. 200k entries. I've to correct my statement. I don't walk over the RoutingTable. It's only an interface table walk (IF-MIB). bsnmpd consumes approx. 6-10% cpu. I already have significant packet loss if bsnmpd is started. bsnmpd not running: ping www.switch.ch --- oreius.switch.ch ping statistics --- 44 packets transmitted, 44 packets received, 0% packet loss round-trip min/avg/max/stddev = 6.825/7.425/8.007/0.252 ms zero packet loss. netstat -w 1 shows no error. input (Total) output packets errs bytes packets errs bytes colls 39877 0 34330807 38614 0 34087518 0 45522 0 38730142 44124 0 38424881 0 44671 0 38783909 43455 0 38604698 0 43140 0 36939542 42059 0 36691583 0 43428 0 36858817 42213 0 36700954 0 43748 0 37994949 42687 0 37780190 0 42698 0 36451927 41409 0 36270936 0 38695 0 32184588 37119 0 31791417 0 bsnmpd started: ping www.switch.ch --- oreius.switch.ch ping statistics --- 57 packets transmitted, 53 packets received, 7% packet loss round-trip min/avg/max/stddev = 6.715/12.638/95.183/19.041 ms 7% packet loss. netstat shows some errors too. netstat -w 1 input (Total) output packets errs bytes packets errs bytes colls 33597 0 27508009 32433 0 27344720 0 38204 0 32117848 36950 0 31852251 0 39171 0 33870984 37999 0 33696346 0 32160 0 26825650 31065 0 26591079 0 26915 726 20902878 25771 0 20791170 0 35167 0 29173014 33945 0 28904867 0 33282 370 27478393 32140 0 27297079 0 29738 0 23859586 28464 0 23524984 0 38456 598 31559055 36881 0 31313396 0 34738 0 28088584 33247 0 27743827 0 38193 648 30854513 36657 0 30556948 0 A snmpwalk makes it a bit worse but not much. I already have packet loss if bsnmpd is just started without any walks. Regards, Thomas From owner-freebsd-net@FreeBSD.ORG Fri Oct 27 15:44:58 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 AC6EC16A4A0 for ; Fri, 27 Oct 2006 15:44:58 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6CC5D43D62 for ; Fri, 27 Oct 2006 15:44:56 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from knop-beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 17:44:54 +0200 Date: Fri, 27 Oct 2006 17:44:55 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@knop-beagle.kn.op.dlr.de To: Thomas In-Reply-To: <454226C7.10505@bsdunix.ch> Message-ID: <20061027173957.S27619@knop-beagle.kn.op.dlr.de> References: <4541AB5C.2060009@bsdunix.ch> <20061027104553.D27619@knop-beagle.kn.op.dlr.de> <454226C7.10505@bsdunix.ch> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 27 Oct 2006 15:44:54.0852 (UTC) FILETIME=[D9306040:01C6F9DE] Cc: freebsd-net@freebsd.org Subject: Re: paket loss on freebsd router if (b)snmpd is running##SPAM X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 15:44:58 -0000 On Fri, 27 Oct 2006, Thomas wrote: T>Hello Harti T> T>Harti Brandt schrieb: T>> On Fri, 27 Oct 2006, Thomas wrote: T>> T>> T>Hello T>> T> T>> T>I use several 5.4 and 6.1 FBSD machines as router (with quagga). The T>> T>average traffic is 300mbit/s (em interfaces with polling enabled). It T>> T>works more or less. T>> T> T>> T>Problem: T>> T>If bsnmpd is running and I'm doing a snmpwalk from a remote machine the T>> T>router has some significant packet loss. We are talking about 3-15% of T>> T>packet loss. It's a simple snmpwalk (ipRouteTable and the interfaces stats). T>> T>> Does this happen also if you walk only the interface tables? What size is T>> your routing table? T> T>The routing table has approx. 200k entries. I've to correct my T>statement. I don't walk over the RoutingTable. Oh. That would be a nice test how good the RB-tree implementation of the routing table is :-) T>It's only an interface table walk (IF-MIB). bsnmpd consumes approx. T>6-10% cpu. I already have significant packet loss if bsnmpd is started. T> T>bsnmpd not running: T> T>ping www.switch.ch T> T>--- oreius.switch.ch ping statistics --- T>44 packets transmitted, 44 packets received, 0% packet loss T>round-trip min/avg/max/stddev = 6.825/7.425/8.007/0.252 ms T> T>zero packet loss. T> T> T>netstat -w 1 shows no error. T> T> input (Total) output T> packets errs bytes packets errs bytes colls T> 39877 0 34330807 38614 0 34087518 0 T> 45522 0 38730142 44124 0 38424881 0 T> 44671 0 38783909 43455 0 38604698 0 T> 43140 0 36939542 42059 0 36691583 0 T> 43428 0 36858817 42213 0 36700954 0 T> 43748 0 37994949 42687 0 37780190 0 T> 42698 0 36451927 41409 0 36270936 0 T> 38695 0 32184588 37119 0 31791417 0 T> T> T> T> T>bsnmpd started: T> T>ping www.switch.ch T>--- oreius.switch.ch ping statistics --- T>57 packets transmitted, 53 packets received, 7% packet loss T>round-trip min/avg/max/stddev = 6.715/12.638/95.183/19.041 ms T> T>7% packet loss. T> T> T>netstat shows some errors too. T>netstat -w 1 T> input (Total) output T> packets errs bytes packets errs bytes colls T> 33597 0 27508009 32433 0 27344720 0 T> 38204 0 32117848 36950 0 31852251 0 T> 39171 0 33870984 37999 0 33696346 0 T> 32160 0 26825650 31065 0 26591079 0 T> 26915 726 20902878 25771 0 20791170 0 T> 35167 0 29173014 33945 0 28904867 0 T> 33282 370 27478393 32140 0 27297079 0 T> 29738 0 23859586 28464 0 23524984 0 T> 38456 598 31559055 36881 0 31313396 0 T> 34738 0 28088584 33247 0 27743827 0 T> 38193 648 30854513 36657 0 30556948 0 T> T> T>A snmpwalk makes it a bit worse but not much. I already have packet loss T>if bsnmpd is just started without any walks. You mean, you have loss if it is just ideling around? The only thing bsnmpd does in this situation is polling the interface statistics, which is needed because the kernel has only 32-bit counters. Could you please check what the polling interval is? You find this in the BEGEMOT-MIB2-MIB. Something like snmpwalk ... begemotMib2 given that /usr/share/snmp/mibs is in your MIB path. harti From owner-freebsd-net@FreeBSD.ORG Fri Oct 27 15:59:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 B0EA516A407 for ; Fri, 27 Oct 2006 15:59:02 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout2-b.corp.dcn.yahoo.com (mrout2-b.corp.dcn.yahoo.com [216.109.112.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id F398643D6E for ; Fri, 27 Oct 2006 15:59:00 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout2-b.corp.dcn.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id k9RFwk64012136; Fri, 27 Oct 2006 08:58:47 -0700 (PDT) Date: Fri, 27 Oct 2006 17:58:42 +0200 Message-ID: From: gnn@freebsd.org To: "Sam Wun" In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.50 (i386-apple-darwin8.7.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-net@freebsd.org Subject: Re: check internet connection X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 15:59:02 -0000 At Fri, 27 Oct 2006 09:43:17 +1000, Sam Wun wrote: > > [1 ] > Hi, > > I want to write a C program to check freebsd's internet connection. > What s the best way to achieve this checking in layer 2 or 3 of the tcp/ip > stacks in freebsd? What do you want to check? There are many layers of connectivity. Later, George From owner-freebsd-net@FreeBSD.ORG Fri Oct 27 17:24:33 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 B146816A49E; Fri, 27 Oct 2006 17:24:33 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from mail01.solnet.ch (mail01.solnet.ch [212.101.4.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08D3C43DAD; Fri, 27 Oct 2006 17:22:37 +0000 (GMT) (envelope-from freebsdlists@bsdunix.ch) X-Virus-Scanned: by amavisd-new at mail01.solnet.ch Received: from mail01.solnet.ch ([127.0.0.1]) by localhost (mail01.solnet.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id VONJK8gJEjFo; Fri, 27 Oct 2006 17:22:33 +0000 (GMT) Received: from [192.168.1.102] (home.bsdunix.ch [82.220.17.23]) by mail01.solnet.ch (Postfix) with ESMTP id 575006220F; Fri, 27 Oct 2006 17:22:33 +0000 (GMT) Message-ID: <45424017.2030905@bsdunix.ch> Date: Fri, 27 Oct 2006 19:21:27 +0200 From: Thomas User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Harti Brandt References: <4541AB5C.2060009@bsdunix.ch> <20061027104553.D27619@knop-beagle.kn.op.dlr.de> <454226C7.10505@bsdunix.ch> <20061027173957.S27619@knop-beagle.kn.op.dlr.de> In-Reply-To: <20061027173957.S27619@knop-beagle.kn.op.dlr.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: paket loss on freebsd router if (b)snmpd is running##SPAM X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 17:24:33 -0000 Hello Harti Harti Brandt schrieb: > On Fri, 27 Oct 2006, Thomas wrote: > > T>Hello Harti > T> > T>Harti Brandt schrieb: > T>> On Fri, 27 Oct 2006, Thomas wrote: > T>> > T>> T>Hello > T>> T> > T>> T>I use several 5.4 and 6.1 FBSD machines as router (with quagga). The > T>> T>average traffic is 300mbit/s (em interfaces with polling enabled). It > T>> T>works more or less. > T>> T> > T>> T>Problem: > T>> T>If bsnmpd is running and I'm doing a snmpwalk from a remote machine the > T>> T>router has some significant packet loss. We are talking about 3-15% of > T>> T>packet loss. It's a simple snmpwalk (ipRouteTable and the interfaces stats). > T>> > T>> Does this happen also if you walk only the interface tables? What size is > T>> your routing table? > T> > T>The routing table has approx. 200k entries. I've to correct my > T>statement. I don't walk over the RoutingTable. > > Oh. That would be a nice test how good the RB-tree implementation of the > routing table is :-) > > T>It's only an interface table walk (IF-MIB). bsnmpd consumes approx. > T>6-10% cpu. I already have significant packet loss if bsnmpd is started. > T> > T>bsnmpd not running: > T> > T>ping www.switch.ch > T> > T>--- oreius.switch.ch ping statistics --- > T>44 packets transmitted, 44 packets received, 0% packet loss > T>round-trip min/avg/max/stddev = 6.825/7.425/8.007/0.252 ms > T> > T>zero packet loss. > T> > T> > T>netstat -w 1 shows no error. > T> > T> input (Total) output > T> packets errs bytes packets errs bytes colls > T> 39877 0 34330807 38614 0 34087518 0 > T> 45522 0 38730142 44124 0 38424881 0 > T> 44671 0 38783909 43455 0 38604698 0 > T> 43140 0 36939542 42059 0 36691583 0 > T> 43428 0 36858817 42213 0 36700954 0 > T> 43748 0 37994949 42687 0 37780190 0 > T> 42698 0 36451927 41409 0 36270936 0 > T> 38695 0 32184588 37119 0 31791417 0 > T> > T> > T> > T> > T>bsnmpd started: > T> > T>ping www.switch.ch > T>--- oreius.switch.ch ping statistics --- > T>57 packets transmitted, 53 packets received, 7% packet loss > T>round-trip min/avg/max/stddev = 6.715/12.638/95.183/19.041 ms > T> > T>7% packet loss. > T> > T> > T>netstat shows some errors too. > T>netstat -w 1 > T> input (Total) output > T> packets errs bytes packets errs bytes colls > T> 33597 0 27508009 32433 0 27344720 0 > T> 38204 0 32117848 36950 0 31852251 0 > T> 39171 0 33870984 37999 0 33696346 0 > T> 32160 0 26825650 31065 0 26591079 0 > T> 26915 726 20902878 25771 0 20791170 0 > T> 35167 0 29173014 33945 0 28904867 0 > T> 33282 370 27478393 32140 0 27297079 0 > T> 29738 0 23859586 28464 0 23524984 0 > T> 38456 598 31559055 36881 0 31313396 0 > T> 34738 0 28088584 33247 0 27743827 0 > T> 38193 648 30854513 36657 0 30556948 0 > T> > T> > T>A snmpwalk makes it a bit worse but not much. I already have packet loss > T>if bsnmpd is just started without any walks. > > You mean, you have loss if it is just ideling around? The only thing > bsnmpd does in this situation is polling the interface statistics, which > is needed because the kernel has only 32-bit counters. Could you please > check what the polling interval is? You find this in the BEGEMOT-MIB2-MIB. > Something like > Yes, bsnmpd is just ideling. > snmpwalk ... begemotMib2 On this freebsd 5.4 machine I have bsnmpd-1.12: share/snmp/mibs/BEGEMOT-MIB.txt share/snmp/mibs/BEGEMOT-NTP-MIB.txt share/snmp/mibs/BEGEMOT-SNMPD.txt but no BEGEMOT-MIB2-MIB. snmpwalk -v 2c -m /usr/share/snmp/mibs/BEGEMOT-MIB.txt -c public localhost BEGEMOT BEGEMOT-MIB::begemot.1.1.1.1.0 = INTEGER: 2048 BEGEMOT-MIB::begemot.1.1.1.2.0 = INTEGER: 2048 BEGEMOT-MIB::begemot.1.1.1.3.0 = INTEGER: 1 BEGEMOT-MIB::begemot.1.1.1.4.0 = IpAddress: 0.0.0.0 BEGEMOT-MIB::begemot.1.1.1.5.0 = Gauge32: 3 BEGEMOT-MIB::begemot.1.1.2.1.3.192.168.1.10.162 = INTEGER: 1 BEGEMOT-MIB::begemot.1.1.2.1.4.192.168.1.10.162 = STRING: "SNTrap" BEGEMOT-MIB::begemot.1.1.2.1.5.192.168.1.10.162 = INTEGER: 2 BEGEMOT-MIB::begemot.1.1.4.1.3.127.0.0.1.161 = INTEGER: 1 BEGEMOT-MIB::begemot.1.1.4.1.3.192.168.1.100.161 = INTEGER: 1 BEGEMOT-MIB::begemot.1.1.6.1.2.5.109.105.98.73.73 = STRING: "/usr/local/lib/snmp_mibII.so" BEGEMOT-MIB::begemot.1.1.6.1.3.5.109.105.98.73.73 = STRING: "This module implements the interface and ip groups." BEGEMOT-MIB::begemot.1.1.7.1.0 = Counter32: 0 BEGEMOT-MIB::begemot.1.1.7.2.0 = Counter32: 0 BEGEMOT-MIB::begemot.1.1.7.3.0 = Counter32: 0 BEGEMOT-MIB::begemot.1.1.7.4.0 = Counter32: 0 BEGEMOT-MIB::begemot.1.1.8.1.0 = INTEGER: 2 BEGEMOT-MIB::begemot.1.1.8.2.0 = Gauge32: 0 BEGEMOT-MIB::begemot.1.1.8.3.0 = INTEGER: 7 BEGEMOT-MIB::begemot.1.1.9.1.2.19.47.118.97.114.47.114.117.110.47.115.110.109.112.100.46.115.111.99.107 = INTEGER: 1 BEGEMOT-MIB::begemot.1.1.9.1.3.19.47.118.97.114.47.114.117.110.47.115.110.109.112.100.46.115.111.99.107 = INTEGER: 4 BEGEMOT-MIB::begemot.1.1.10.1.1.2.3.117.100.112 = INTEGER: 1 BEGEMOT-MIB::begemot.1.1.10.1.1.2.5.108.115.111.99.107 = INTEGER: 1 BEGEMOT-MIB::begemot.1.1.10.1.1.3.3.117.100.112 = OID: BEGEMOT-MIB::begemot.1.1.10.2 BEGEMOT-MIB::begemot.1.1.10.1.1.3.5.108.115.111.99.107 = OID: BEGEMOT-MIB::begemot.1.1.10.3 BEGEMOT-MIB::begemot.3.1.1.1.0 = Counter64: 1000000000 BEGEMOT-MIB::begemot.3.1.1.2.0 = Timeticks: (2000) 0:00:20.00 BEGEMOT-MIB::begemot.3.1.1.3.0 = Timeticks: (0) 0:00:00.00 > given that /usr/share/snmp/mibs is in your MIB path. snmpd.conf: # Configuration %snmpd begemotSnmpdDebugDumpPdus = 2 begemotSnmpdDebugSyslogPri = 7 begemotSnmpdCommunityString.0.1 = $(read) begemotSnmpdCommunityString.0.2 = $(write) begemotSnmpdCommunityDisable = 1 # open standard SNMP ports begemotSnmpdPortStatus.[$(host)].161 = 1 begemotSnmpdPortStatus.127.0.0.1.161 = 1 # open a unix domain socket begemotSnmpdLocalPortStatus."/var/run/snmpd.sock" = 1 begemotSnmpdLocalPortType."/var/run/snmpd.sock" = 4 # send traps to the traphost begemotTrapSinkStatus.[$(traphost)].$(trapport) = 4 begemotTrapSinkVersion.[$(traphost)].$(trapport) = 2 begemotTrapSinkComm.[$(traphost)].$(trapport) = $(trap) sysContact = $(contact) sysLocation = $(location) sysObjectId = 1.3.6.1.4.1.12325.1.1.2.1.$(system) snmpEnableAuthenTraps = 2 begemotSnmpdModulePath."mibII" = "/usr/local/lib/snmp_mibII.so" Regards, Thomas From owner-freebsd-net@FreeBSD.ORG Fri Oct 27 19:03:49 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 5D8BC16A403 for ; Fri, 27 Oct 2006 19:03:49 +0000 (UTC) (envelope-from khetan@os.org.za) Received: from gauntlet.os.org.za (gauntlet.os.org.za [196.35.70.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6BBF43D45 for ; Fri, 27 Oct 2006 19:03:44 +0000 (GMT) (envelope-from khetan@os.org.za) Received: from localhost (localhost [127.0.0.1]) by gauntlet.os.org.za (Postfix) with ESMTP id 0E8486794B for ; Fri, 27 Oct 2006 21:03:42 +0200 (SAST) X-Virus-Scanned: amavisd-new at os.org.za Received: from gauntlet.os.org.za ([127.0.0.1]) by localhost (gauntlet.os.org.za [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0Fyi17RRTJ-x for ; Fri, 27 Oct 2006 21:03:35 +0200 (SAST) Received: from gauntlet.os.org.za (gauntlet.os.org.za [196.35.70.242]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: khetan) by gauntlet.os.org.za (Postfix) with ESMTP id D302D67941 for ; Fri, 27 Oct 2006 21:03:35 +0200 (SAST) Date: Fri, 27 Oct 2006 21:03:35 +0200 (SAST) From: Khetan Gajjar To: freebsd-net@freebsd.org Message-ID: <20061027203322.X2293@gauntlet.os.org.za> X-Alternate-From: Khetan Gajjar X-Mobile: +27 82 885 4047 X-URL: http://khetan.gajjar.co.za/ X-Attribute-1: BOFH X-Attribute-2: the righteous bastard with a finger on The Switch X-Message-flag: This message sponsored by Internet Solutions. X-PGP-KeyID: 0x806AD0D9 X-PGP-Fingerprint: 19 29 68 D5 74 2B 6E E5 1B 88 45 3B 29 0B 8A 27 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Path MTU discovery broken in IPSec X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 19:03:49 -0000 Hi. Summary; searching for this problem revealed another query, but no solution - http://lists.freebsd.org/pipermail/freebsd-net/2005-July/007899.html Explanation; I'm experiencing a broken path MTU discovery problem between two hosts connecting with each other via IPSec transport mode, exasperated by the fact that the two hosts are more than 600ms apart in terms of network latency. Host 1 and Host 2 both run FreeBSD 6.1-stable, circa Sep 7. Host 1's IPsec config looks like /etc/ipsec.conf: flush; spdflush; spdadd x.x.x.x y.y.y.y any -P out ipsec esp/transport//require; spdadd y.y.y.y x.x.x.x any -P in ipsec esp/transport//require; and its network config looks like em0: flags=9843 mtu 1500 options=b inet6 fe80::212:3fff:feec:d1ce%em0 prefixlen 64 scopeid 0x1 inet x.x.x.x netmask 0xffffff00 broadcast x.x.x.255 ether 00:12:3f:ec:d1:ce media: Ethernet 100baseTX status: active lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 Host 2's IPsec config looks like /etc/ipsec.conf: flush; spdflush; spdadd x.x.x.x y.y.y.y any -P in ipsec esp/transport//require; spdadd y.y.y.y x.x.x.x any -P out ipsec esp/transport//require; and its network config looks like fxp0: flags=9843 mtu 1500 options=b inet6 fe80::202:b3ff:feeb:21db%fxp0 prefixlen 64 scopeid 0x1 inet y.y.y.y netmask 0xfffffff8 broadcast y.y.y.z ether 00:02:b3:eb:21:db media: Ethernet 10baseT/UTP status: active plip0: flags=108810 mtu 1500 lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff000000 Both machines are running the same kernel configs and the same sysctl configs. The sysctl's in play are net.inet.icmp.icmplim=500 net.inet.ip.ttl=128 net.inet.raw.maxdgram=57344 net.inet.raw.recvspace=65535 net.inet.tcp.always_keepalive=1 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.drop_redirect=1 net.inet.icmp.log_redirect=1 net.inet.ip.redirect=0 net.inet6.ip6.redirect=0 net.inet.ip.sourceroute=0 net.inet.ip.accept_sourceroute=0 net.inet.icmp.bmcastecho=0 net.inet.icmp.maskrepl=0 net.inet.tcp.delayed_ack=0 net.inet.tcp.sendspace=65535 net.inet.tcp.recvspace=65535 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 racoon does its thing, and the ipsec tunnels come up. I can ping both sides, and there are no ipfw rules running. Connectivity via ssh and nfs seems to work fine, as do DNS zone transfers (for very small zones). Connectivity from host 2 to host 1 works perfectly. From host 1 to host 2 however, TCP sessions break / stall / timeout. I've tried reducing the MTU sizes from the default 1500 to 1492 on both interfaces, and that makes no difference. Are there any suggestions or additional debugging that could assist in solving this problem ? Khetan Gajjar. -- khetan@os.org.za +27 82 885 4047 From owner-freebsd-net@FreeBSD.ORG Fri Oct 27 21:32:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 A9A7C16A412 for ; Fri, 27 Oct 2006 21:32:02 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from ms-smtp-04.southeast.rr.com (ms-smtp-04.southeast.rr.com [24.25.9.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A98843D64 for ; Fri, 27 Oct 2006 21:31:54 +0000 (GMT) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (cpe-024-211-118-154.sc.res.rr.com [24.211.118.154]) by ms-smtp-04.southeast.rr.com (8.13.6/8.13.6) with ESMTP id k9RLVodR001134 for ; Fri, 27 Oct 2006 17:31:50 -0400 (EDT) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.13.8/8.13.8) with ESMTP id k9RLVnco000201 for ; Fri, 27 Oct 2006 17:31:50 -0400 (EDT) (envelope-from morganw@chemikals.org) Date: Fri, 27 Oct 2006 17:31:49 -0400 (EDT) From: Wesley Morgan To: freebsd-net@freebsd.org Message-ID: <20061027172447.I82826@volatile.chemikals.org> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1824411618-1161984709=:82826" X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: ppp and mpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 21:32:02 -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-1824411618-1161984709=:82826 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed I'm using a DSL connection and user-ppp, but would like to use mpd instead. I never had a problem with bellsouth DSL but this version doesn't seem to work for me. I've got basically a vanilla ppp.conf and mpd.conf. The logs from ppp and mpd are attached (sorry for the length). I'm sure it's some crazy option that I've overlooked, but I can't seem to figure it out. If anyone can help I'd be quite grateful! Thanks! My ppp.conf is: default: set log Phase Chat IPCP CCP tun command set server /var/run/pppctl ******* 0177 ident user-ppp VERSION (built COMPILATIONDATE) netracer: set device PPPoE:xl0 set authname morganw set authkey ********** set dial set login set mru 1492 add default HISADDR And mpd.conf is: default: load netracer netracer: new -i ng0 netracer PPPoE set iface addrs 1.1.1.1 2.2.2.2 set iface route default set iface disable on-demand set iface session 5 set iface enable tcpmssfix set iface idle 0 set debug 4 set bundle disable multilink set bundle authname morganw set link enable no-orig-auth set link no acfcomp protocomp set link accept pap set link accept chap set ipcp yes req-pri-dns set ipcp yes req-sec-dns set ipcp ranges 0.0.0.0/0 0.0.0.0/0 log +ccp +echo +frame open iface And mpd.links: PPPoE: set link type pppoe set pppoe iface xl0 set pppoe service "netracer" set pppoe enable originate -- This .signature sanitized for your protection --0-1824411618-1161984709=:82826 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=mpd.log Content-Transfer-Encoding: BASE64 Content-ID: <20061027173149.V82826@volatile.chemikals.org> Content-Description: Content-Disposition: attachment; filename=mpd.log bXBkOiBwaWQgODQxNjAsIHZlcnNpb24gMy4xOCAocm9vdEB2b2xhdGlsZSAx Mjo0MCAgOS1PY3QtMjAwNikNCltuZXRyYWNlcl0gcHBwIG5vZGUgaXMgIm1w ZDg0MTYwLW5ldHJhY2VyIg0KW25ldHJhY2VyXSBleGVjOiAvc2Jpbi9pZmNv bmZpZyB4bDAgdXANCltuZXRyYWNlcl0gdXNpbmcgaW50ZXJmYWNlIG5nMA0K W25ldHJhY2VyXSBJUENQOiBwZWVyIGFkZHJlc3MgY2Fubm90IGJlIHplcm8N CltuZXRyYWNlcl0gSUZBQ0U6IE9wZW4gZXZlbnQNCltuZXRyYWNlcl0gSVBD UDogT3BlbiBldmVudA0KW25ldHJhY2VyXSBJUENQOiBzdGF0ZSBjaGFuZ2Ug SW5pdGlhbCAtLT4gU3RhcnRpbmcNCltuZXRyYWNlcl0gSVBDUDogTGF5ZXJT dGFydA0KW25ldHJhY2VyXSBidW5kbGU6IE9QRU4gZXZlbnQgaW4gc3RhdGUg Q0xPU0VEDQpbbmV0cmFjZXJdIG9wZW5pbmcgbGluayAiUFBQb0UiLi4uDQpb UFBQb0VdIGxpbms6IE9QRU4gZXZlbnQNCltQUFBvRV0gTENQOiBPcGVuIGV2 ZW50DQpbUFBQb0VdIExDUDogc3RhdGUgY2hhbmdlIEluaXRpYWwgLS0+IFN0 YXJ0aW5nDQpbUFBQb0VdIExDUDogTGF5ZXJTdGFydA0KW1BQUG9FXSBkZXZp Y2U6IE9QRU4gZXZlbnQgaW4gc3RhdGUgRE9XTg0KW25ldHJhY2VyXSBuZXRn cmFwaDogU0VORElORyBNRVNTQUdFOg0KW25ldHJhY2VyXSBuZXRncmFwaDog U09DS0FERFI6IHsgZmFtPTMyIGxlbj00IGFkZHI9Ii4iIH0NCltuZXRyYWNl cl0gbmV0Z3JhcGg6IE5HX01FU0cgOg0KW25ldHJhY2VyXSBuZXRncmFwaDog ICB2ZXJzICAgOA0KW25ldHJhY2VyXSBuZXRncmFwaDogICBhcmdsZW4gMA0K W25ldHJhY2VyXSBuZXRncmFwaDogICBmbGFncyAgMA0KW25ldHJhY2VyXSBu ZXRncmFwaDogICB0b2tlbiAgMjINCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAg Y29va2llIEdFTkVSSUMgKDk3NzY3NDQwOCkNCltuZXRyYWNlcl0gbmV0Z3Jh cGg6ICAgY21kICAgIDI2ODQzNTQ2Mg0KW25ldHJhY2VyXSBuZXRncmFwaDog ICBhcmdzICgwIGJ5dGVzKQ0KW25ldHJhY2VyXSBuZXRncmFwaDogUkVDRUlW RUQgUkVTUE9OU0U6DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiBTT0NLQUREUjog eyBmYW09MzIgbGVuPTggYWRkcj0iWzVjXToiIH0NCltuZXRyYWNlcl0gbmV0 Z3JhcGg6IE5HX01FU0cgOg0KW25ldHJhY2VyXSBuZXRncmFwaDogICB2ZXJz ICAgOA0KW25ldHJhY2VyXSBuZXRncmFwaDogICBhcmdsZW4gNzINCltuZXRy YWNlcl0gbmV0Z3JhcGg6ICAgZmxhZ3MgIDENCltuZXRyYWNlcl0gbmV0Z3Jh cGg6ICAgdG9rZW4gIDIyDQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIGNvb2tp ZSBHRU5FUklDICg5Nzc2NzQ0MDgpDQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAg IGNtZCAgICBub2RlaW5mbyAoMjY4NDM1NDYyKQ0KW25ldHJhY2VyXSBuZXRn cmFwaDogICBhcmdzICAgeyB0eXBlPSJzb2NrZXQiIGlkPTB4NWMgfQ0KW25l dHJhY2VyXSBuZXRncmFwaDogU0VORElORyBNRVNTQUdFOg0KW25ldHJhY2Vy XSBuZXRncmFwaDogU09DS0FERFI6IHsgZmFtPTMyIGxlbj05IGFkZHI9ImJ5 cGFzcyIgfQ0KW25ldHJhY2VyXSBuZXRncmFwaDogTkdfTUVTRyA6DQpbbmV0 cmFjZXJdIG5ldGdyYXBoOiAgIHZlcnMgICA4DQpbbmV0cmFjZXJdIG5ldGdy YXBoOiAgIGFyZ2xlbiA1NzYNCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgZmxh Z3MgIDANCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgdG9rZW4gIDI0DQpbbmV0 cmFjZXJdIG5ldGdyYXBoOiAgIGNvb2tpZSBHRU5FUklDICg5Nzc2NzQ0MDgp DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIGNtZCAgICAzDQpbbmV0cmFjZXJd IG5ldGdyYXBoOiAgIGFyZ3MgKDU3NiBieXRlcykNCltuZXRyYWNlcl0gbmV0 Z3JhcGg6IDAwMDA6ICA3OCA2YyAzMCAzYSA2ZiA3MiA3MCA2OCA2MSA2ZSA3 MyAwMCAwMCAwMCAwMCAwMCAgIHhsMDpvcnBoYW5zLi4uLi4NCltuZXRyYWNl cl0gbmV0Z3JhcGg6IDAwMTA6ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4NCltu ZXRyYWNlcl0gbmV0Z3JhcGg6IDAwMjA6ICAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4u Li4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAwMzA6ICAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4u Li4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAwNDA6ICAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4u Li4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAwNTA6ICAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAgIC4uLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAw NjA6ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3Jh cGg6IDAwNzA6ICAwMCAwMCAwMCAwMCA5OCBkMyBiZiBiZiBiOCBkMyBiZiBi ZiBmNSBmZSAwYyAyOCAgIC4uLi4uLi4uLi4uLi4uLigNCltuZXRyYWNlcl0g bmV0Z3JhcGg6IDAwODA6ICAwNyBkNCBiZiBiZiBkYSAwYiAwZCAyOCAxYiAw MCAwMCAwMCAwOCAwMiBmZiBmZiAgIC4uLi4uLi4oLi4uLi4uLi4NCltuZXRy YWNlcl0gbmV0Z3JhcGg6IDAwOTA6ICAwMiBkNCBiZiBiZiAyMCAwMCAwMCAw MCAwMSAwMCAwMCAwMCAwMCAwMiAyZCAzOCAgIC4uLi4gLi4uLi4uLi4uLTgN CltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAwYTA6ICAzNCAzMSAzNiAzMCAwMCAw MCAwMCAwMCAwNiAwMCAwMCAxMCAwMCAwMCAwMCAwMCAgIDQxNjAuLi4uLi4u Li4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAwYjA6ICA2MyBkMyBiZiBi ZiAwMSAwMCAwMCAwMCAyMCBmMCAwOCAwOCAwNSAwMCAwMCAwMCAgIGMuLi4u Li4uIC4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAwYzA6ICAzNSAz NCAzNiAzMiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAg IDU0NjIuLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAwZDA6 ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCA1MCBkNiBiZiBiZiAwMCAwMCAw MCAwMCAgIC4uLi4uLi4uUC4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6 IDAwZTA6ICAwMCAwMCAwMCAwMCA0NyA5ZiAwNyAwOCAwMCAwMCAwMCAwMCAy OCAxMiAwZCAyOCAgIC4uLi5HLi4uLi4uLiguLigNCltuZXRyYWNlcl0gbmV0 Z3JhcGg6IDAwZjA6ICA3MCBkMyBiZiBiZiAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAxMiBmYSAwYyAyOCAgIHAuLi4uLi4uLi4uLi4uLigNCltuZXRyYWNl cl0gbmV0Z3JhcGg6IDAxMDA6ICAwZSAwMCAwMCAwMCAwMCBkNCBiZiBiZiAw OCAwMCAwMCAwMCBlMCBkNCBiZiBiZiAgIC4uLi4uLi4uLi4uLi4uLi4NCltu ZXRyYWNlcl0gbmV0Z3JhcGg6IDAxMTA6ICAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCA5OCBkNiBiZiBiZiAwMCAwMiAyZCAyOCAgIC4uLi4uLi4uLi4uLi4u LSgNCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAxMjA6ICAyMCAwMCAwMCAwMCAy YyBkNSBiZiBiZiAxOCBkNSBiZiBiZiA5MSBmNCAyYSAyOCAgICAuLi4sLi4u Li4uLi4uKigNCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAxMzA6ICBhMCBkNCBi ZiBiZiBmOCA3ZSAwNyAwOCAzNCBkNSBiZiBiZiAwNSAwMCAwMCAwMCAgIC4u Li4ufi4uNC4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAxNDA6ICAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAgIC4uLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAx NTA6ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3Jh cGg6IDAxNjA6ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0g bmV0Z3JhcGg6IDAxNzA6ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4NCltuZXRy YWNlcl0gbmV0Z3JhcGg6IDAxODA6ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4N CltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAxOTA6ICAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4u Li4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAxYTA6ICAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4u Li4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAxYjA6ICAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAg IC4uLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAxYzA6 ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6 IDAxZDA6ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0 Z3JhcGg6IDAxZTA6ICA0NSBkNSBiZiBiZiAwMCAwMCAwMCAwMCAxYSAwMCAw MCAwMCAwOCAwMiBmZiBmZiAgIEUuLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNl cl0gbmV0Z3JhcGg6IDAxZjA6ICA0MCBkNSBiZiBiZiAxZiAwMCAwMCAwMCAw NCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgIEAuLi4uLi4uLi4uLi4uLi4NCltu ZXRyYWNlcl0gbmV0Z3JhcGg6IDAyMDA6ICA2YyA2OSA2ZSA2YiAzMCAwMCAw NyAwOCAyNCBhMCAwOCAwOCAwMSAwMCAwMCAwMCAgIGxpbmswLi4uJC4uLi4u Li4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAyMTA6ICAwMSAwMCAwMCAwMCA4 NiA5MiAwNyAwOCAwMCBkNCBiZiBiZiAwMCAwMiAyZCAyOCAgIC4uLi4uLi4u Li4uLi4uLSgNCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAyMjA6ICA2ZCA3MCA2 NCAzOCAzNCAzMSAzNiAzMCAyZCA1MCA1MCA1MCA2ZiA0NSAwMCAyOCAgIG1w ZDg0MTYwLVBQUG9FLigNCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAyMzA6ICA3 OCBmZiAyYyAyOCA5MCBkNyBiZiBiZiAxOCBkNSBiZiBiZiA0YSA0YiAyYSAy OCAgIHguLCguLi4uLi4uLkpLKigNCltuZXRyYWNlcl0gbmV0Z3JhcGg6IFNF TkRJTkcgTUVTU0FHRToNCltuZXRyYWNlcl0gbmV0Z3JhcGg6IFNPQ0tBRERS OiB7IGZhbT0zMiBsZW49MTQgYWRkcj0ieGwwOm9ycGhhbnMiIH0NCltuZXRy YWNlcl0gbmV0Z3JhcGg6IE5HX01FU0cgOg0KW25ldHJhY2VyXSBuZXRncmFw aDogICB2ZXJzICAgOA0KW25ldHJhY2VyXSBuZXRncmFwaDogICBhcmdsZW4g NDINCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgZmxhZ3MgIDANCltuZXRyYWNl cl0gbmV0Z3JhcGg6ICAgdG9rZW4gIDI1DQpbbmV0cmFjZXJdIG5ldGdyYXBo OiAgIGNvb2tpZSBQUFBPRSAoMTA4OTg5MzA3MikNCltuZXRyYWNlcl0gbmV0 Z3JhcGg6ICAgY21kICAgIHBwcG9lX2Nvbm5lY3QgKDIpDQpbbmV0cmFjZXJd IG5ldGdyYXBoOiAgIGFyZ3MgICB7IGhvb2s9Im1wZDg0MTYwLVBQUG9FIiBk YXRhPSJuZXRyYWNlciIgfQ0KW1BQUG9FXSBkZXZpY2UgaXMgbm93IGluIHN0 YXRlIE9QRU5JTkcNCltQUFBvRV0gUFBQb0UgY29ubmVjdGlvbiB0aW1lb3V0 IGFmdGVyIDkgc2Vjb25kcw0KW25ldHJhY2VyXSBuZXRncmFwaDogU0VORElO RyBNRVNTQUdFOg0KW25ldHJhY2VyXSBuZXRncmFwaDogU09DS0FERFI6IHsg ZmFtPTMyIGxlbj0xNCBhZGRyPSJ4bDA6b3JwaGFucyIgfQ0KW25ldHJhY2Vy XSBuZXRncmFwaDogTkdfTUVTRyA6DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAg IHZlcnMgICA4DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIGFyZ2xlbiAzMg0K W25ldHJhY2VyXSBuZXRncmFwaDogICBmbGFncyAgMA0KW25ldHJhY2VyXSBu ZXRncmFwaDogICB0b2tlbiAgMjcNCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAg Y29va2llIEdFTkVSSUMgKDk3NzY3NDQwOCkNCltuZXRyYWNlcl0gbmV0Z3Jh cGg6ICAgY21kICAgIHJtaG9vayAoNSkNCltuZXRyYWNlcl0gbmV0Z3JhcGg6 ICAgYXJncyAgIHsgaG9vaz0ibXBkODQxNjAtUFBQb0UiIH0NCltQUFBvRV0g ZGV2aWNlOiBET1dOIGV2ZW50IGluIHN0YXRlIE9QRU5JTkcNCltQUFBvRV0g ZGV2aWNlIGlzIG5vdyBpbiBzdGF0ZSBET1dODQpbUFBQb0VdIGxpbms6IERP V04gZXZlbnQNCltQUFBvRV0gTENQOiBEb3duIGV2ZW50DQpbbmV0cmFjZXJd IG5ldGdyYXBoOiBTRU5ESU5HIE1FU1NBR0U6DQpbbmV0cmFjZXJdIG5ldGdy YXBoOiBTT0NLQUREUjogeyBmYW09MzIgbGVuPTkgYWRkcj0iYnlwYXNzIiB9 DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiBOR19NRVNHIDoNCltuZXRyYWNlcl0g bmV0Z3JhcGg6ICAgdmVycyAgIDgNCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAg YXJnbGVuIDINCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgZmxhZ3MgIDANCltu ZXRyYWNlcl0gbmV0Z3JhcGg6ICAgdG9rZW4gIDI5DQpbbmV0cmFjZXJdIG5l dGdyYXBoOiAgIGNvb2tpZSBQUFAgKDk0MDg5Nzc5NSkNCltuZXRyYWNlcl0g bmV0Z3JhcGg6ICAgY21kICAgIDYNCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAg YXJncyAoMiBieXRlcykNCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAwMDA6ICAw MCAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC4uICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KW25ldHJhY2Vy XSBuZXRncmFwaDogUkVDRUlWRUQgUkVTUE9OU0U6DQpbbmV0cmFjZXJdIG5l dGdyYXBoOiBTT0NLQUREUjogeyBmYW09MzIgbGVuPTggYWRkcj0iWzU4XToi IH0NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IE5HX01FU0cgOg0KW25ldHJhY2Vy XSBuZXRncmFwaDogICB2ZXJzICAgOA0KW25ldHJhY2VyXSBuZXRncmFwaDog ICBhcmdsZW4gMzINCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgZmxhZ3MgIDEN CltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgdG9rZW4gIDI5DQpbbmV0cmFjZXJd IG5ldGdyYXBoOiAgIGNvb2tpZSBQUFAgKDk0MDg5Nzc5NSkNCltuZXRyYWNl cl0gbmV0Z3JhcGg6ICAgY21kICAgIGdldGNscnN0YXRzICg2KQ0KW25ldHJh Y2VyXSBuZXRncmFwaDogICBhcmdzICAge30NCltQUFBvRV0gZGV2aWNlOiBP UEVOIGV2ZW50IGluIHN0YXRlIERPV04NCltQUFBvRV0gcGF1c2luZyA0IHNl Y29uZHMgYmVmb3JlIG9wZW4NCltQUFBvRV0gZGV2aWNlIGlzIG5vdyBpbiBz dGF0ZSBET1dODQpbUFBQb0VdIGRldmljZTogT1BFTiBldmVudCBpbiBzdGF0 ZSBET1dODQpbUFBQb0VdIHBhdXNpbmcgMiBzZWNvbmRzIGJlZm9yZSBvcGVu DQpbUFBQb0VdIGRldmljZSBpcyBub3cgaW4gc3RhdGUgRE9XTg0KW1BQUG9F XSBkZXZpY2U6IE9QRU4gZXZlbnQgaW4gc3RhdGUgRE9XTg0KW25ldHJhY2Vy XSBuZXRncmFwaDogU0VORElORyBNRVNTQUdFOg0KW25ldHJhY2VyXSBuZXRn cmFwaDogU09DS0FERFI6IHsgZmFtPTMyIGxlbj00IGFkZHI9Ii4iIH0NCltu ZXRyYWNlcl0gbmV0Z3JhcGg6IE5HX01FU0cgOg0KW25ldHJhY2VyXSBuZXRn cmFwaDogICB2ZXJzICAgOA0KW25ldHJhY2VyXSBuZXRncmFwaDogICBhcmds ZW4gMA0KW25ldHJhY2VyXSBuZXRncmFwaDogICBmbGFncyAgMA0KW25ldHJh Y2VyXSBuZXRncmFwaDogICB0b2tlbiAgMzENCltuZXRyYWNlcl0gbmV0Z3Jh cGg6ICAgY29va2llIEdFTkVSSUMgKDk3NzY3NDQwOCkNCltuZXRyYWNlcl0g bmV0Z3JhcGg6ICAgY21kICAgIDI2ODQzNTQ2Mg0KW25ldHJhY2VyXSBuZXRn cmFwaDogICBhcmdzICgwIGJ5dGVzKQ0KW25ldHJhY2VyXSBuZXRncmFwaDog UkVDRUlWRUQgUkVTUE9OU0U6DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiBTT0NL QUREUjogeyBmYW09MzIgbGVuPTggYWRkcj0iWzYxXToiIH0NCltuZXRyYWNl cl0gbmV0Z3JhcGg6IE5HX01FU0cgOg0KW25ldHJhY2VyXSBuZXRncmFwaDog ICB2ZXJzICAgOA0KW25ldHJhY2VyXSBuZXRncmFwaDogICBhcmdsZW4gNzIN CltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgZmxhZ3MgIDENCltuZXRyYWNlcl0g bmV0Z3JhcGg6ICAgdG9rZW4gIDMxDQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAg IGNvb2tpZSBHRU5FUklDICg5Nzc2NzQ0MDgpDQpbbmV0cmFjZXJdIG5ldGdy YXBoOiAgIGNtZCAgICBub2RlaW5mbyAoMjY4NDM1NDYyKQ0KW25ldHJhY2Vy XSBuZXRncmFwaDogICBhcmdzICAgeyB0eXBlPSJzb2NrZXQiIGlkPTB4NjEg fQ0KW25ldHJhY2VyXSBuZXRncmFwaDogU0VORElORyBNRVNTQUdFOg0KW25l dHJhY2VyXSBuZXRncmFwaDogU09DS0FERFI6IHsgZmFtPTMyIGxlbj05IGFk ZHI9ImJ5cGFzcyIgfQ0KW25ldHJhY2VyXSBuZXRncmFwaDogTkdfTUVTRyA6 DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIHZlcnMgICA4DQpbbmV0cmFjZXJd IG5ldGdyYXBoOiAgIGFyZ2xlbiA1NzYNCltuZXRyYWNlcl0gbmV0Z3JhcGg6 ICAgZmxhZ3MgIDANCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgdG9rZW4gIDMz DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIGNvb2tpZSBHRU5FUklDICg5Nzc2 NzQ0MDgpDQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIGNtZCAgICAzDQpbbmV0 cmFjZXJdIG5ldGdyYXBoOiAgIGFyZ3MgKDU3NiBieXRlcykNCltuZXRyYWNl cl0gbmV0Z3JhcGg6IDAwMDA6ICA3OCA2YyAzMCAzYSA2ZiA3MiA3MCA2OCA2 MSA2ZSA3MyAwMCAwMCAwMCAwMCAwMCAgIHhsMDpvcnBoYW5zLi4uLi4NCltu ZXRyYWNlcl0gbmV0Z3JhcGg6IDAwMTA6ICAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4u Li4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAwMjA6ICAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4u Li4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAwMzA6ICAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4u Li4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAwNDA6ICAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAgIC4uLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAw NTA6ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3Jh cGg6IDAwNjA6ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0g bmV0Z3JhcGg6IDAwNzA6ICAwMCAwMCAwMCAwMCA5OCBkMyBiZiBiZiBiOCBk MyBiZiBiZiBmNSBmZSAwYyAyOCAgIC4uLi4uLi4uLi4uLi4uLigNCltuZXRy YWNlcl0gbmV0Z3JhcGg6IDAwODA6ICAwNyBkNCBiZiBiZiBkYSAwYiAwZCAy OCAxYiAwMCAwMCAwMCAwOCAwMiBmZiBmZiAgIC4uLi4uLi4oLi4uLi4uLi4N CltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAwOTA6ICAwMiBkNCBiZiBiZiAyMCAw MCAwMCAwMCA3OCBkMyBiZiBiZiA4MCBiMiAwOCAzOCAgIC4uLi4gLi4ueC4u Li4uLjgNCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAwYTA6ICAzNCAzMSAzNiAz MCAwMCAwMCAwMCAwMCAwNiAwMCAwMCAxMCAwMCAwMCAwMCAwMCAgIDQxNjAu Li4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAwYjA6ICA2MyBk MyBiZiBiZiAwMSAwMCAwMCAwMCAyMCBmMCAwOCAwOCAwNSAwMCAwMCAwMCAg IGMuLi4uLi4uIC4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAwYzA6 ICAzNSAzNCAzNiAzMiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAgIDU0NjIuLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6 IDAwZDA6ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCA2NCA3NSAyYyAyOCAw MCAwMCAwMCAwMCAgIC4uLi4uLi4uZHUsKC4uLi4NCltuZXRyYWNlcl0gbmV0 Z3JhcGg6IDAwZTA6ICAwMCAwMCAwMCAwMCA0NyA5ZiAwNyAwOCAwMCAwMCAw MCAwMCAyOCAxMiAwZCAyOCAgIC4uLi5HLi4uLi4uLiguLigNCltuZXRyYWNl cl0gbmV0Z3JhcGg6IDAwZjA6ICA3MCBkMyBiZiBiZiAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAxMiBmYSAwYyAyOCAgIHAuLi4uLi4uLi4uLi4uLigNCltu ZXRyYWNlcl0gbmV0Z3JhcGg6IDAxMDA6ICAwZSAwMCAwMCAwMCAwMCBkNCBi ZiBiZiAwOCAwMCAwMCAwMCBlMCBkNCBiZiBiZiAgIC4uLi4uLi4uLi4uLi4u Li4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAxMTA6ICAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCA5OCBkNiBiZiBiZiAwMCAwMiAyZCAyOCAgIC4uLi4uLi4u Li4uLi4uLSgNCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAxMjA6ICAyMCAwMCAw MCAwMCAyYyBkNSBiZiBiZiAxOCBkNSBiZiBiZiA5MSBmNCAyYSAyOCAgICAu Li4sLi4uLi4uLi4uKigNCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAxMzA6ICBh MCBkNCBiZiBiZiBmOCA3ZSAwNyAwOCAzNCBkNSBiZiBiZiAwNSAwMCAwMCAw MCAgIC4uLi4ufi4uNC4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAx NDA6ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3Jh cGg6IDAxNTA6ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0g bmV0Z3JhcGg6IDAxNjA6ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4NCltuZXRy YWNlcl0gbmV0Z3JhcGg6IDAxNzA6ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4N CltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAxODA6ICAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4u Li4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAxOTA6ICAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4u Li4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAxYTA6ICAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAg IC4uLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAxYjA6 ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6 IDAxYzA6ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNlcl0gbmV0 Z3JhcGg6IDAxZDA6ICAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAgIC4uLi4uLi4uLi4uLi4uLi4NCltuZXRyYWNl cl0gbmV0Z3JhcGg6IDAxZTA6ICA0NSBkNSBiZiBiZiAwMCAwMCAwMCAwMCAx YSAwMCAwMCAwMCAwOCAwMiBmZiBmZiAgIEUuLi4uLi4uLi4uLi4uLi4NCltu ZXRyYWNlcl0gbmV0Z3JhcGg6IDAxZjA6ICA0MCBkNSBiZiBiZiAxZiAwMCAw MCAwMCAwNCAwMCAwMCAwMCAwMCAwMiAyZCAyOCAgIEAuLi4uLi4uLi4uLi4u LSgNCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAyMDA6ICA2YyA2OSA2ZSA2YiAz MCAwMCAwMCAwMCAyNCBhMCAwOCAwOCAwMSAwMCAwMCAwMCAgIGxpbmswLi4u JC4uLi4uLi4NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAyMTA6ICAwMSAwMCAw MCAwMCA4NiA5MiAwNyAwOCAwMCBkNCBiZiBiZiAwMCAwMiAyZCAyOCAgIC4u Li4uLi4uLi4uLi4uLSgNCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAyMjA6ICA2 ZCA3MCA2NCAzOCAzNCAzMSAzNiAzMCAyZCA1MCA1MCA1MCA2ZiA0NSAwMCAy OCAgIG1wZDg0MTYwLVBQUG9FLigNCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAy MzA6ICA3OCBmZiAyYyAyOCA5MCBkNyBiZiBiZiA1OCBkNyBiZiAwMCA0YSA0 YiAyYSAyOCAgIHguLCguLi4uWC4uLkpLKigNCltuZXRyYWNlcl0gbmV0Z3Jh cGg6IFNFTkRJTkcgTUVTU0FHRToNCltuZXRyYWNlcl0gbmV0Z3JhcGg6IFNP Q0tBRERSOiB7IGZhbT0zMiBsZW49MTQgYWRkcj0ieGwwOm9ycGhhbnMiIH0N CltuZXRyYWNlcl0gbmV0Z3JhcGg6IE5HX01FU0cgOg0KW25ldHJhY2VyXSBu ZXRncmFwaDogICB2ZXJzICAgOA0KW25ldHJhY2VyXSBuZXRncmFwaDogICBh cmdsZW4gNDINCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgZmxhZ3MgIDANCltu ZXRyYWNlcl0gbmV0Z3JhcGg6ICAgdG9rZW4gIDM0DQpbbmV0cmFjZXJdIG5l dGdyYXBoOiAgIGNvb2tpZSBQUFBPRSAoMTA4OTg5MzA3MikNCltuZXRyYWNl cl0gbmV0Z3JhcGg6ICAgY21kICAgIHBwcG9lX2Nvbm5lY3QgKDIpDQpbbmV0 cmFjZXJdIG5ldGdyYXBoOiAgIGFyZ3MgICB7IGhvb2s9Im1wZDg0MTYwLVBQ UG9FIiBkYXRhPSJuZXRyYWNlciIgfQ0KW1BQUG9FXSBkZXZpY2UgaXMgbm93 IGluIHN0YXRlIE9QRU5JTkcNCltQUFBvRV0gUFBQb0UgY29ubmVjdGlvbiB0 aW1lb3V0IGFmdGVyIDkgc2Vjb25kcw0KW25ldHJhY2VyXSBuZXRncmFwaDog U0VORElORyBNRVNTQUdFOg0KW25ldHJhY2VyXSBuZXRncmFwaDogU09DS0FE RFI6IHsgZmFtPTMyIGxlbj0xNCBhZGRyPSJ4bDA6b3JwaGFucyIgfQ0KW25l dHJhY2VyXSBuZXRncmFwaDogTkdfTUVTRyA6DQpbbmV0cmFjZXJdIG5ldGdy YXBoOiAgIHZlcnMgICA4DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIGFyZ2xl biAzMg0KW25ldHJhY2VyXSBuZXRncmFwaDogICBmbGFncyAgMA0KW25ldHJh Y2VyXSBuZXRncmFwaDogICB0b2tlbiAgMzYNCltuZXRyYWNlcl0gbmV0Z3Jh cGg6ICAgY29va2llIEdFTkVSSUMgKDk3NzY3NDQwOCkNCltuZXRyYWNlcl0g bmV0Z3JhcGg6ICAgY21kICAgIHJtaG9vayAoNSkNCltuZXRyYWNlcl0gbmV0 Z3JhcGg6ICAgYXJncyAgIHsgaG9vaz0ibXBkODQxNjAtUFBQb0UiIH0NCltQ UFBvRV0gZGV2aWNlOiBET1dOIGV2ZW50IGluIHN0YXRlIE9QRU5JTkcNCltQ UFBvRV0gZGV2aWNlIGlzIG5vdyBpbiBzdGF0ZSBET1dODQpbUFBQb0VdIGxp bms6IERPV04gZXZlbnQNCltQUFBvRV0gTENQOiBEb3duIGV2ZW50DQpbbmV0 cmFjZXJdIG5ldGdyYXBoOiBTRU5ESU5HIE1FU1NBR0U6DQpbbmV0cmFjZXJd IG5ldGdyYXBoOiBTT0NLQUREUjogeyBmYW09MzIgbGVuPTkgYWRkcj0iYnlw YXNzIiB9DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiBOR19NRVNHIDoNCltuZXRy YWNlcl0gbmV0Z3JhcGg6ICAgdmVycyAgIDgNCltuZXRyYWNlcl0gbmV0Z3Jh cGg6ICAgYXJnbGVuIDINCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgZmxhZ3Mg IDANCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgdG9rZW4gIDM4DQpbbmV0cmFj ZXJdIG5ldGdyYXBoOiAgIGNvb2tpZSBQUFAgKDk0MDg5Nzc5NSkNCltuZXRy YWNlcl0gbmV0Z3JhcGg6ICAgY21kICAgIDYNCltuZXRyYWNlcl0gbmV0Z3Jh cGg6ICAgYXJncyAoMiBieXRlcykNCltuZXRyYWNlcl0gbmV0Z3JhcGg6IDAw MDA6ICAwMCAwMCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIC4uICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KW25l dHJhY2VyXSBuZXRncmFwaDogUkVDRUlWRUQgUkVTUE9OU0U6DQpbbmV0cmFj ZXJdIG5ldGdyYXBoOiBTT0NLQUREUjogeyBmYW09MzIgbGVuPTggYWRkcj0i WzU4XToiIH0NCltuZXRyYWNlcl0gbmV0Z3JhcGg6IE5HX01FU0cgOg0KW25l dHJhY2VyXSBuZXRncmFwaDogICB2ZXJzICAgOA0KW25ldHJhY2VyXSBuZXRn cmFwaDogICBhcmdsZW4gMzINCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgZmxh Z3MgIDENCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgdG9rZW4gIDM4DQpbbmV0 cmFjZXJdIG5ldGdyYXBoOiAgIGNvb2tpZSBQUFAgKDk0MDg5Nzc5NSkNCltu ZXRyYWNlcl0gbmV0Z3JhcGg6ICAgY21kICAgIGdldGNscnN0YXRzICg2KQ0K W25ldHJhY2VyXSBuZXRncmFwaDogICBhcmdzICAge30NCltQUFBvRV0gZGV2 aWNlOiBPUEVOIGV2ZW50IGluIHN0YXRlIERPV04NCltQUFBvRV0gcGF1c2lu ZyA2IHNlY29uZHMgYmVmb3JlIG9wZW4NCltQUFBvRV0gZGV2aWNlIGlzIG5v dyBpbiBzdGF0ZSBET1dODQpbUFBQb0VdIGRldmljZTogT1BFTiBldmVudCBp biBzdGF0ZSBET1dODQpbbmV0cmFjZXJdIG5ldGdyYXBoOiBTRU5ESU5HIE1F U1NBR0U6DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiBTT0NLQUREUjogeyBmYW09 MzIgbGVuPTQgYWRkcj0iLiIgfQ0KW25ldHJhY2VyXSBuZXRncmFwaDogTkdf TUVTRyA6DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIHZlcnMgICA4DQpbbmV0 cmFjZXJdIG5ldGdyYXBoOiAgIGFyZ2xlbiAwDQpbbmV0cmFjZXJdIG5ldGdy YXBoOiAgIGZsYWdzICAwDQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIHRva2Vu ICA0MA0KW25ldHJhY2VyXSBuZXRncmFwaDogICBjb29raWUgR0VORVJJQyAo OTc3Njc0NDA4KQ0KW25ldHJhY2VyXSBuZXRncmFwaDogICBjbWQgICAgMjY4 NDM1NDYyDQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIGFyZ3MgKDAgYnl0ZXMp DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiBSRUNFSVZFRCBSRVNQT05TRToNCltu ZXRyYWNlcl0gbmV0Z3JhcGg6IFNPQ0tBRERSOiB7IGZhbT0zMiBsZW49OCBh ZGRyPSJbNjZdOiIgfQ0KW25ldHJhY2VyXSBuZXRncmFwaDogTkdfTUVTRyA6 DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIHZlcnMgICA4DQpbbmV0cmFjZXJd IG5ldGdyYXBoOiAgIGFyZ2xlbiA3Mg0KW25ldHJhY2VyXSBuZXRncmFwaDog ICBmbGFncyAgMQ0KW25ldHJhY2VyXSBuZXRncmFwaDogICB0b2tlbiAgNDAN CltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgY29va2llIEdFTkVSSUMgKDk3NzY3 NDQwOCkNCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgY21kICAgIG5vZGVpbmZv ICgyNjg0MzU0NjIpDQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIGFyZ3MgICB7 IHR5cGU9InNvY2tldCIgaWQ9MHg2NiB9DQpbbmV0cmFjZXJdIG5ldGdyYXBo OiBTRU5ESU5HIE1FU1NBR0U6DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiBTT0NL QUREUjogeyBmYW09MzIgbGVuPTkgYWRkcj0iYnlwYXNzIiB9DQpbbmV0cmFj ZXJdIG5ldGdyYXBoOiBOR19NRVNHIDoNCltuZXRyYWNlcl0gbmV0Z3JhcGg6 ICAgdmVycyAgIDgNCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgYXJnbGVuIDU3 Ng0KW25ldHJhY2VyXSBuZXRncmFwaDogICBmbGFncyAgMA0KW25ldHJhY2Vy XSBuZXRncmFwaDogICB0b2tlbiAgNDINCltuZXRyYWNlcl0gbmV0Z3JhcGg6 ICAgY29va2llIEdFTkVSSUMgKDk3NzY3NDQwOCkNCltuZXRyYWNlcl0gbmV0 Z3JhcGg6ICAgY21kICAgIDMNCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgYXJn cyAoNTc2IGJ5dGVzKQ0KW25ldHJhY2VyXSBuZXRncmFwaDogMDAwMDogIDc4 IDZjIDMwIDNhIDZmIDcyIDcwIDY4IDYxIDZlIDczIDAwIDAwIDAwIDAwIDAw ICAgeGwwOm9ycGhhbnMuLi4uLg0KW25ldHJhY2VyXSBuZXRncmFwaDogMDAx MDogIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLg0KW25ldHJhY2VyXSBuZXRncmFw aDogMDAyMDogIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLg0KW25ldHJhY2VyXSBu ZXRncmFwaDogMDAzMDogIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLg0KW25ldHJh Y2VyXSBuZXRncmFwaDogMDA0MDogIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLg0K W25ldHJhY2VyXSBuZXRncmFwaDogMDA1MDogIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4u Li4uLg0KW25ldHJhY2VyXSBuZXRncmFwaDogMDA2MDogIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4u Li4uLi4uLi4uLg0KW25ldHJhY2VyXSBuZXRncmFwaDogMDA3MDogIDAwIDAw IDAwIDAwIDk4IGQzIGJmIGJmIGI4IGQzIGJmIGJmIGY1IGZlIDBjIDI4ICAg Li4uLi4uLi4uLi4uLi4uKA0KW25ldHJhY2VyXSBuZXRncmFwaDogMDA4MDog IDA3IGQ0IGJmIGJmIGRhIDBiIDBkIDI4IDFiIDAwIDAwIDAwIDA4IDAyIGZm IGZmICAgLi4uLi4uLiguLi4uLi4uLg0KW25ldHJhY2VyXSBuZXRncmFwaDog MDA5MDogIDAyIGQ0IGJmIGJmIDIwIDAwIDAwIDAwIDc4IGQzIGJmIGJmIDQw IGIyIDA4IDM4ICAgLi4uLiAuLi54Li4uQC4uOA0KW25ldHJhY2VyXSBuZXRn cmFwaDogMDBhMDogIDM0IDMxIDM2IDMwIDAwIDAwIDAwIDAwIDA2IDAwIDAw IDEwIDAwIDAwIDAwIDAwICAgNDE2MC4uLi4uLi4uLi4uLg0KW25ldHJhY2Vy XSBuZXRncmFwaDogMDBiMDogIDYzIGQzIGJmIGJmIDAxIDAwIDAwIDAwIDIw IGYwIDA4IDA4IDA1IDAwIDAwIDAwICAgYy4uLi4uLi4gLi4uLi4uLg0KW25l dHJhY2VyXSBuZXRncmFwaDogMDBjMDogIDM1IDM0IDM2IDMyIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgNTQ2Mi4uLi4uLi4uLi4u Lg0KW25ldHJhY2VyXSBuZXRncmFwaDogMDBkMDogIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDY0IDc1IDJjIDI4IDAwIDAwIDAwIDAwICAgLi4uLi4uLi5k dSwoLi4uLg0KW25ldHJhY2VyXSBuZXRncmFwaDogMDBlMDogIDAwIDAwIDAw IDAwIDQ3IDlmIDA3IDA4IDAwIDAwIDAwIDAwIDI4IDEyIDBkIDI4ICAgLi4u LkcuLi4uLi4uKC4uKA0KW25ldHJhY2VyXSBuZXRncmFwaDogMDBmMDogIDcw IGQzIGJmIGJmIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDEyIGZhIDBjIDI4 ICAgcC4uLi4uLi4uLi4uLi4uKA0KW25ldHJhY2VyXSBuZXRncmFwaDogMDEw MDogIDBlIDAwIDAwIDAwIDAwIGQ0IGJmIGJmIDA4IDAwIDAwIDAwIGUwIGQ0 IGJmIGJmICAgLi4uLi4uLi4uLi4uLi4uLg0KW25ldHJhY2VyXSBuZXRncmFw aDogMDExMDogIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDk4IGQ2IGJmIGJm IDAwIDAyIDJkIDI4ICAgLi4uLi4uLi4uLi4uLi4tKA0KW25ldHJhY2VyXSBu ZXRncmFwaDogMDEyMDogIDIwIDAwIDAwIDAwIDJjIGQ1IGJmIGJmIDE4IGQ1 IGJmIGJmIDkxIGY0IDJhIDI4ICAgIC4uLiwuLi4uLi4uLi4qKA0KW25ldHJh Y2VyXSBuZXRncmFwaDogMDEzMDogIGEwIGQ0IGJmIGJmIGY4IDdlIDA3IDA4 IDM0IGQ1IGJmIGJmIDA1IDAwIDAwIDAwICAgLi4uLi5+Li40Li4uLi4uLg0K W25ldHJhY2VyXSBuZXRncmFwaDogMDE0MDogIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4u Li4uLg0KW25ldHJhY2VyXSBuZXRncmFwaDogMDE1MDogIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4u Li4uLi4uLi4uLg0KW25ldHJhY2VyXSBuZXRncmFwaDogMDE2MDogIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAg Li4uLi4uLi4uLi4uLi4uLg0KW25ldHJhY2VyXSBuZXRncmFwaDogMDE3MDog IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwICAgLi4uLi4uLi4uLi4uLi4uLg0KW25ldHJhY2VyXSBuZXRncmFwaDog MDE4MDogIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLg0KW25ldHJhY2VyXSBuZXRn cmFwaDogMDE5MDogIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLg0KW25ldHJhY2Vy XSBuZXRncmFwaDogMDFhMDogIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4uLg0KW25l dHJhY2VyXSBuZXRncmFwaDogMDFiMDogIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4uLi4uLi4u Lg0KW25ldHJhY2VyXSBuZXRncmFwaDogMDFjMDogIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4uLi4uLi4u Li4uLi4uLg0KW25ldHJhY2VyXSBuZXRncmFwaDogMDFkMDogIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwICAgLi4u Li4uLi4uLi4uLi4uLg0KW25ldHJhY2VyXSBuZXRncmFwaDogMDFlMDogIDQ1 IGQ1IGJmIGJmIDAwIDAwIDAwIDAwIDFhIDAwIDAwIDAwIDA4IDAyIGZmIGZm ICAgRS4uLi4uLi4uLi4uLi4uLg0KW25ldHJhY2VyXSBuZXRncmFwaDogMDFm MDogIDQwIGQ1IGJmIGJmIDFmIDAwIDAwIDAwIDA0IDAwIDAwIDAwIDAwIDAy IDJkIDI4ICAgQC4uLi4uLi4uLi4uLi4tKA0KW25ldHJhY2VyXSBuZXRncmFw aDogMDIwMDogIDZjIDY5IDZlIDZiIDMwIDAwIDAwIDAwIDI0IGEwIDA4IDA4 IDAxIDAwIDAwIDAwICAgbGluazAuLi4kLi4uLi4uLg0KW25ldHJhY2VyXSBu ZXRncmFwaDogMDIxMDogIDAxIDAwIDAwIDAwIDg2IDkyIDA3IDA4IDAwIGQ0 IGJmIGJmIDAwIDAyIDJkIDI4ICAgLi4uLi4uLi4uLi4uLi4tKA0KW25ldHJh Y2VyXSBuZXRncmFwaDogMDIyMDogIDZkIDcwIDY0IDM4IDM0IDMxIDM2IDMw IDJkIDUwIDUwIDUwIDZmIDQ1IDAwIDI4ICAgbXBkODQxNjAtUFBQb0UuKA0K W25ldHJhY2VyXSBuZXRncmFwaDogMDIzMDogIDc4IGZmIDJjIDI4IDkwIGQ3 IGJmIGJmIDU4IGQ3IGJmIDAwIDRhIDRiIDJhIDI4ICAgeC4sKC4uLi5YLi4u SksqKA0KW25ldHJhY2VyXSBuZXRncmFwaDogU0VORElORyBNRVNTQUdFOg0K W25ldHJhY2VyXSBuZXRncmFwaDogU09DS0FERFI6IHsgZmFtPTMyIGxlbj0x NCBhZGRyPSJ4bDA6b3JwaGFucyIgfQ0KW25ldHJhY2VyXSBuZXRncmFwaDog TkdfTUVTRyA6DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIHZlcnMgICA4DQpb bmV0cmFjZXJdIG5ldGdyYXBoOiAgIGFyZ2xlbiA0Mg0KW25ldHJhY2VyXSBu ZXRncmFwaDogICBmbGFncyAgMA0KW25ldHJhY2VyXSBuZXRncmFwaDogICB0 b2tlbiAgNDMNCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgY29va2llIFBQUE9F ICgxMDg5ODkzMDcyKQ0KW25ldHJhY2VyXSBuZXRncmFwaDogICBjbWQgICAg cHBwb2VfY29ubmVjdCAoMikNCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgYXJn cyAgIHsgaG9vaz0ibXBkODQxNjAtUFBQb0UiIGRhdGE9Im5ldHJhY2VyIiB9 DQpbUFBQb0VdIGRldmljZSBpcyBub3cgaW4gc3RhdGUgT1BFTklORw0KW1BQ UG9FXSBQUFBvRSBjb25uZWN0aW9uIHRpbWVvdXQgYWZ0ZXIgOSBzZWNvbmRz DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiBTRU5ESU5HIE1FU1NBR0U6DQpbbmV0 cmFjZXJdIG5ldGdyYXBoOiBTT0NLQUREUjogeyBmYW09MzIgbGVuPTE0IGFk ZHI9InhsMDpvcnBoYW5zIiB9DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiBOR19N RVNHIDoNCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgdmVycyAgIDgNCltuZXRy YWNlcl0gbmV0Z3JhcGg6ICAgYXJnbGVuIDMyDQpbbmV0cmFjZXJdIG5ldGdy YXBoOiAgIGZsYWdzICAwDQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIHRva2Vu ICA0NQ0KW25ldHJhY2VyXSBuZXRncmFwaDogICBjb29raWUgR0VORVJJQyAo OTc3Njc0NDA4KQ0KW25ldHJhY2VyXSBuZXRncmFwaDogICBjbWQgICAgcm1o b29rICg1KQ0KW25ldHJhY2VyXSBuZXRncmFwaDogICBhcmdzICAgeyBob29r PSJtcGQ4NDE2MC1QUFBvRSIgfQ0KbXBkOiBjYXVnaHQgZmF0YWwgc2lnbmFs IGludA0KbXBkOiBmYXRhbCBlcnJvciwgZXhpdGluZw0KW25ldHJhY2VyXSBJ UENQOiBEb3duIGV2ZW50DQpbbmV0cmFjZXJdIElGQUNFOiBDbG9zZSBldmVu dA0KW25ldHJhY2VyXSBJUENQOiBDbG9zZSBldmVudA0KW25ldHJhY2VyXSBJ UENQOiBzdGF0ZSBjaGFuZ2UgU3RhcnRpbmcgLS0+IEluaXRpYWwNCltuZXRy YWNlcl0gSVBDUDogTGF5ZXJGaW5pc2gNCltuZXRyYWNlcl0gbmV0Z3JhcGg6 IFNFTkRJTkcgTUVTU0FHRToNCltuZXRyYWNlcl0gbmV0Z3JhcGg6IFNPQ0tB RERSOiB7IGZhbT0zMiBsZW49NyBhZGRyPSJuZzA6IiB9DQpbbmV0cmFjZXJd IG5ldGdyYXBoOiBOR19NRVNHIDoNCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAg dmVycyAgIDgNCltuZXRyYWNlcl0gbmV0Z3JhcGg6ICAgYXJnbGVuIDANCltu ZXRyYWNlcl0gbmV0Z3JhcGg6ICAgZmxhZ3MgIDANCltuZXRyYWNlcl0gbmV0 Z3JhcGg6ICAgdG9rZW4gIDQ3DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIGNv b2tpZSBHRU5FUklDICg5Nzc2NzQ0MDgpDQpbbmV0cmFjZXJdIG5ldGdyYXBo OiAgIGNtZCAgICBzaHV0ZG93biAoMSkNCltuZXRyYWNlcl0gbmV0Z3JhcGg6 ICAgYXJncyAgIA0KW25ldHJhY2VyXSBuZXRncmFwaDogU0VORElORyBNRVNT QUdFOg0KW25ldHJhY2VyXSBuZXRncmFwaDogU09DS0FERFI6IHsgZmFtPTMy IGxlbj0xNCBhZGRyPSJieXBhc3MuaW5ldCIgfQ0KW25ldHJhY2VyXSBuZXRn cmFwaDogTkdfTUVTRyA6DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIHZlcnMg ICA4DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIGFyZ2xlbiAwDQpbbmV0cmFj ZXJdIG5ldGdyYXBoOiAgIGZsYWdzICAwDQpbbmV0cmFjZXJdIG5ldGdyYXBo OiAgIHRva2VuICA0OQ0KW25ldHJhY2VyXSBuZXRncmFwaDogICBjb29raWUg R0VORVJJQyAoOTc3Njc0NDA4KQ0KW25ldHJhY2VyXSBuZXRncmFwaDogICBj bWQgICAgMQ0KW25ldHJhY2VyXSBuZXRncmFwaDogICBhcmdzICgwIGJ5dGVz KQ0KW25ldHJhY2VyXSBuZXRncmFwaDogU0VORElORyBNRVNTQUdFOg0KW25l dHJhY2VyXSBuZXRncmFwaDogU09DS0FERFI6IHsgZmFtPTMyIGxlbj05IGFk ZHI9ImJ5cGFzcyIgfQ0KW25ldHJhY2VyXSBuZXRncmFwaDogTkdfTUVTRyA6 DQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIHZlcnMgICA4DQpbbmV0cmFjZXJd IG5ldGdyYXBoOiAgIGFyZ2xlbiAwDQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAg IGZsYWdzICAwDQpbbmV0cmFjZXJdIG5ldGdyYXBoOiAgIHRva2VuICA1MA0K W25ldHJhY2VyXSBuZXRncmFwaDogICBjb29raWUgR0VORVJJQyAoOTc3Njc0 NDA4KQ0KW25ldHJhY2VyXSBuZXRncmFwaDogICBjbWQgICAgMQ0KW25ldHJh Y2VyXSBuZXRncmFwaDogICBhcmdzICgwIGJ5dGVzKQ0KbXBkOiBwcm9jZXNz IDg0MTYwIHRlcm1pbmF0ZWQNCg== --0-1824411618-1161984709=:82826 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=ppp.log Content-Transfer-Encoding: BASE64 Content-ID: <20061027173149.X82826@volatile.chemikals.org> Content-Description: Content-Disposition: attachment; filename=ppp.log UGhhc2U6IFVzaW5nIGludGVyZmFjZTogdHVuMA0KUGhhc2U6IGRlZmxpbms6 IENyZWF0ZWQgaW4gY2xvc2VkIHN0YXRlDQp0dW4wOiBDb21tYW5kOiBkZWZh dWx0OiBzZXQgc2VydmVyIC92YXIvcnVuL3BwcGN0bCAqKioqKioqKiAwMTc3 DQp0dW4wOiBQaGFzZTogTGlzdGVuaW5nIGF0IGxvY2FsIHNvY2tldCAvdmFy L3J1bi9wcHBjdGwuDQp0dW4wOiBDb21tYW5kOiBkZWZhdWx0OiBpZGVudCB1 c2VyLXBwcCBWRVJTSU9OIChidWlsdCBDT01QSUxBVElPTkRBVEUpDQp0dW4w OiBJRDA6IDB4MjgzNDMyMjAgPSBmb3BlbigiL2V0Yy9wcHAvcHBwLmNvbmYi LCAiciIpDQp0dW4wOiBEZWJ1ZzogUmVhZFN5c3RlbTogQ2hlY2tpbmcgbmV0 cmFjZXIgKC9ldGMvcHBwL3BwcC5jb25mKS4NCnR1bjA6IENvbW1hbmQ6IG5l dHJhY2VyOiBzZXQgZGV2aWNlIFBQUG9FOnhsMA0KdHVuMDogQ29tbWFuZDog bmV0cmFjZXI6IHNldCBhdXRobmFtZSBtb3JnYW53DQp0dW4wOiBDb21tYW5k OiBuZXRyYWNlcjogc2V0IGF1dGhrZXkgKioqKioqKioNCnR1bjA6IENvbW1h bmQ6IG5ldHJhY2VyOiBzZXQgZGlhbA0KdHVuMDogQ29tbWFuZDogbmV0cmFj ZXI6IHNldCBsb2dpbg0KdHVuMDogQ29tbWFuZDogbmV0cmFjZXI6IHNldCBt cnUgMTQ5Mg0KdHVuMDogQ29tbWFuZDogbmV0cmFjZXI6IGFkZCBkZWZhdWx0 IEhJU0FERFINCnR1bjA6IElEMDogMTAgPSBzb2NrZXQoMTcsIDMsIDApDQp0 dW4wOiBDb21tYW5kOiBuZXRyYWNlcjogc2V0IGxvZyBBbGwNCnR1bjA6IENv bW1hbmQ6IG5ldHJhY2VyOiBzZXQgc2VydmVyIC92YXIvcnVuL3BwcGN0bCAq KioqKioqKiAwMTc3DQp0dW4wOiBQaGFzZTogTGlzdGVuaW5nIGF0IGxvY2Fs IHNvY2tldCAvdmFyL3J1bi9wcHBjdGwuDQoNCnR1bjA6IElEMDogMHgyODM0 MzIyMCA9IGZvcGVuKCIvdmFyL3J1bi90dW4wLnBpZCIsICJ3IikNCnR1bjA6 IFBoYXNlOiBQUFAgU3RhcnRlZCAoZGRpYWwgbW9kZSkuDQp0dW4wOiBQaGFz ZTogYnVuZGxlOiBFc3RhYmxpc2gNCnR1bjA6IFBoYXNlOiBkZWZsaW5rOiBj bG9zZWQgLT4gb3BlbmluZw0KdHVuMDogSUQwOiAwID0gTmdNa1NvY2tOb2Rl KCIiLCAmY3MsICZkcykNCnR1bjA6IERlYnVnOiBMaXN0IG9mIG5ldGdyYXBo IG5vZGUgYGB4bDA6JycgKGlkIDIpIGhvb2tzOg0KdHVuMDogRGVidWc6ICAg Rm91bmQgb3JwaGFucyAtPiBldGhlcm5ldA0KdHVuMDogRGVidWc6IENvbm5l Y3RpbmcgbmV0Z3JhcGggc29ja2V0IC46dHVuMCAtPiBbNV06OnR1bjANCnR1 bjA6IElEMDogMiA9IHNvY2tldCgyLCAyLCAwKQ0KdHVuMDogSUQwOiAwID0g aW9jdGwoMiwgMzIyMzM0OTUyMSwgMHhiZmJmZDZkMCkNCnR1bjA6IElEMDog MCA9IGlvY3RsKDIsIDIxNDk2MDc2OTYsIDB4YmZiZmQ2ZDApDQp0dW4wOiBE ZWJ1ZzogU2VuZGluZyBQUFBPRV9DT05ORUNUIHRvIC46dHVuMA0KdHVuMDog RGVidWc6IEZvdW5kIHRoZSBmb2xsb3dpbmcgaW50ZXJmYWNlczoNCnR1bjA6 IERlYnVnOiAgSW5kZXggMSwgbmFtZSAidnIwIg0KdHVuMDogRGVidWc6ICBJ bmRleCAyLCBuYW1lICJ4bDAiDQp0dW4wOiBEZWJ1ZzogIEluZGV4IDQsIG5h bWUgInBmbG9nMCINCnR1bjA6IERlYnVnOiAgSW5kZXggNSwgbmFtZSAibG8w Ig0KdHVuMDogRGVidWc6ICBJbmRleCA2LCBuYW1lICJ0dW4wIg0KdHVuMDog UGhhc2U6IGRlZmxpbms6IENvbm5lY3RlZCENCnR1bjA6IFBoYXNlOiBkZWZs aW5rOiBvcGVuaW5nIC0+IGRpYWwNCnR1bjA6IFBoYXNlOiBkZWZsaW5rOiBk aWFsIC0+IGNhcnJpZXINCnR1bjA6IERlYnVnOiBXYWl0aW5nIGZvciBjYXJy aWVyDQp0dW4wOiBQaGFzZTogUmVjZWl2ZWQgTkdNX1BQUE9FX0FDTkFNRSAo aG9vayAiTVJJTlNDWEEwNFctMEEwMTQwNzA0MDA0NDYiKQ0KdHVuMDogUGhh c2U6IFJlY2VpdmVkIE5HTV9QUFBPRV9TRVNTSU9OSUQNCnR1bjA6IFBoYXNl OiBSZWNlaXZlZCBOR01fUFBQT0VfU1VDQ0VTUw0KdHVuMDogUGhhc2U6IGRl Zmxpbms6IGNhcnJpZXIgLT4gbG9naW4NCnR1bjA6IFBoYXNlOiBkZWZsaW5r OiBsb2dpbiAtPiBsY3ANCnR1bjA6IExDUDogRlNNOiBVc2luZyAiZGVmbGlu ayIgYXMgYSB0cmFuc3BvcnQNCnR1bjA6IExDUDogZGVmbGluazogU3RhdGUg Y2hhbmdlIEluaXRpYWwgLS0+IENsb3NlZA0KdHVuMDogTENQOiBkZWZsaW5r OiBTdGF0ZSBjaGFuZ2UgQ2xvc2VkIC0tPiBTdG9wcGVkDQp0dW4wOiBMQ1A6 IGRlZmxpbms6IExheWVyU3RhcnQNCnR1bjA6IExDUDogZGVmbGluazogU2Vu ZENvbmZpZ1JlcSgxKSBzdGF0ZSA9IFN0b3BwZWQNCnR1bjA6IExDUDogIEFD RkNPTVBbMl0NCnR1bjA6IExDUDogIFBST1RPQ09NUFsyXQ0KdHVuMDogTENQ OiAgQUNDTUFQWzZdIDB4MDAwMDAwMDANCnR1bjA6IExDUDogIE1SVVs0XSAx NDkyDQp0dW4wOiBMQ1A6ICBNQUdJQ05VTVs2XSAweDg1NmE1Y2YwDQp0dW4w OiBEZWJ1ZzogZnNtX091dHB1dA0KdHVuMDogRGVidWc6ICAwMSAwMSAwMCAx OCAwOCAwMiAwNyAwMiAwMiAwNiAwMCAwMCAwMCAwMCAwMSAwNCAgLi4uLi4u Li4uLi4uLi4uLg0KdHVuMDogRGVidWc6ICAwNSBkNCAwNSAwNiA4NSA2YSA1 YyBmMCAgICAgICAgICAgICAgICAgICAgICAgICAgLi4uLi5qXC4NCnR1bjA6 IERlYnVnOiBwcm90b19MYXllclB1c2g6IFVzaW5nIDB4YzAyMQ0KdHVuMDog U3luYzogV3JpdGUNCnR1bjA6IFN5bmM6ICBjMCAyMSAwMSAwMSAwMCAxOCAw OCAwMiAwNyAwMiAwMiAwNiAwMCAwMCAwMCAwMCAgLiEuLi4uLi4uLi4uLi4u Lg0KdHVuMDogU3luYzogIDAxIDA0IDA1IGQ0IDA1IDA2IDg1IDZhIDVjIGYw ICAgICAgICAgICAgICAgICAgICAuLi4uLi4ualwuDQp0dW4wOiBEZWJ1Zzog bGlua19QdXNoUGFja2V0OiBUcmFuc21pdCBwcm90byAweGMwMjENCnR1bjA6 IERlYnVnOiBtX2VucXVldWU6IGxlbiA9IDENCnR1bjA6IExDUDogZGVmbGlu azogU3RhdGUgY2hhbmdlIFN0b3BwZWQgLS0+IFJlcS1TZW50DQp0dW4wOiBE ZWJ1ZzogbV9kZXF1ZXVlOiBxdWV1ZSBsZW4gPSAxDQp0dW4wOiBEZWJ1Zzog bGlua19EZXF1ZXVlOiBEZXF1ZXVlZCBmcm9tIHF1ZXVlIDEsIGNvbnRhaW5p bmcgMCBtb3JlIHBhY2tldHMNCnR1bjA6IERlYnVnOiBkZWZsaW5rOiBEZXNj cmlwdG9yV3JpdGU6IHdyb3RlIDI2KDI2KSB0byAxDQp0dW4wOiBEZWJ1Zzog ZGVmbGluazogRGVzY3JpcHRvclJlYWQ6IHJlYWQgMjAvMjA0OCBmcm9tIDEN CnR1bjA6IFN5bmM6IFJlYWQNCnR1bjA6IFN5bmM6ICBjMCAyMSAwMSA3ZCAw MCAxMiAwMSAwNCAwNSBkNCAwMyAwNCBjMCAyMyAwNSAwNiAgLiEufS4uLi4u Li4uLiMuLg0KdHVuMDogU3luYzogIDAzIDllIDNhIGNmICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAuLjouDQp0dW4wOiBEZWJ1Zzog cHJvdG9fTGF5ZXJQdWxsOiB1bmtub3duIC0+IDB4YzAyMQ0KdHVuMDogRGVi dWc6IGxpbmtfUHVsbFBhY2tldDogRGVzcGF0Y2ggcHJvdG8gMHhjMDIxDQp0 dW4wOiBMQ1A6IGRlZmxpbms6IFJlY3ZDb25maWdSZXEoMTI1KSBzdGF0ZSA9 IFJlcS1TZW50DQp0dW4wOiBMQ1A6ICBNUlVbNF0gMTQ5Mg0KdHVuMDogTENQ OiAgQVVUSFBST1RPWzRdIDB4YzAyMyAoUEFQKQ0KdHVuMDogTENQOiAgTUFH SUNOVU1bNl0gMHgwMzllM2FjZg0KdHVuMDogTENQOiBkZWZsaW5rOiBTZW5k Q29uZmlnQWNrKDEyNSkgc3RhdGUgPSBSZXEtU2VudA0KdHVuMDogTENQOiAg TVJVWzRdIDE0OTINCnR1bjA6IExDUDogIEFVVEhQUk9UT1s0XSAweGMwMjMg KFBBUCkNCnR1bjA6IExDUDogIE1BR0lDTlVNWzZdIDB4MDM5ZTNhY2YNCnR1 bjA6IERlYnVnOiBmc21fT3V0cHV0DQp0dW4wOiBEZWJ1ZzogIDAyIDdkIDAw IDEyIDAxIDA0IDA1IGQ0IDAzIDA0IGMwIDIzIDA1IDA2IDAzIDllICAufS4u Li4uLi4uLiMuLi4uDQp0dW4wOiBEZWJ1ZzogIDNhIGNmICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA6Lg0KdHVuMDogRGVi dWc6IHByb3RvX0xheWVyUHVzaDogVXNpbmcgMHhjMDIxDQp0dW4wOiBTeW5j OiBXcml0ZQ0KdHVuMDogU3luYzogIGMwIDIxIDAyIDdkIDAwIDEyIDAxIDA0 IDA1IGQ0IDAzIDA0IGMwIDIzIDA1IDA2ICAuIS59Li4uLi4uLi4uIy4uDQp0 dW4wOiBTeW5jOiAgMDMgOWUgM2EgY2YgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIC4uOi4NCnR1bjA6IERlYnVnOiBsaW5rX1B1c2hQ YWNrZXQ6IFRyYW5zbWl0IHByb3RvIDB4YzAyMQ0KdHVuMDogRGVidWc6IG1f ZW5xdWV1ZTogbGVuID0gMQ0KdHVuMDogTENQOiBkZWZsaW5rOiBTdGF0ZSBj aGFuZ2UgUmVxLVNlbnQgLS0+IEFjay1TZW50DQp0dW4wOiBEZWJ1ZzogZGVm bGluazogRGVzY3JpcHRvclJlYWQ6IHJlYWQgMTYvMjA0OCBmcm9tIDENCnR1 bjA6IFN5bmM6IFJlYWQNCnR1bjA6IFN5bmM6ICBjMCAyMSAwNCAwMSAwMCAw ZSAwOCAwMiAwNyAwMiAwMiAwNiAwMCAwMCAwMCAwMCAgLiEuLi4uLi4uLi4u Li4uLg0KdHVuMDogRGVidWc6IHByb3RvX0xheWVyUHVsbDogdW5rbm93biAt PiAweGMwMjENCnR1bjA6IERlYnVnOiBsaW5rX1B1bGxQYWNrZXQ6IERlc3Bh dGNoIHByb3RvIDB4YzAyMQ0KdHVuMDogTENQOiBkZWZsaW5rOiBSZWN2Q29u ZmlnUmVqKDEpIHN0YXRlID0gQWNrLVNlbnQNCnR1bjA6IExDUDogZGVmbGlu azogU2VuZElkZW50KDApIHN0YXRlID0gQWNrLVNlbnQNCnR1bjA6IERlYnVn OiBmc21fT3V0cHV0DQp0dW4wOiBEZWJ1ZzogIDBjIDAwIDAwIDJhIDg1IDZh IDVjIGYwIDc1IDczIDY1IDcyIDJkIDcwIDcwIDcwICAuLi4qLmpcLnVzZXIt cHBwDQp0dW4wOiBEZWJ1ZzogIDIwIDMzIDJlIDM0IDJlIDMyIDIwIDI4IDYy IDc1IDY5IDZjIDc0IDIwIDUzIDY1ICAgMy40LjIgKGJ1aWx0IFNlDQp0dW4w OiBEZWJ1ZzogIDcwIDIwIDMyIDM4IDIwIDMyIDMwIDMwIDM2IDI5ICAgICAg ICAgICAgICAgICAgICBwIDI4IDIwMDYpDQp0dW4wOiBEZWJ1ZzogcHJvdG9f TGF5ZXJQdXNoOiBVc2luZyAweGMwMjENCnR1bjA6IFN5bmM6IFdyaXRlDQp0 dW4wOiBTeW5jOiAgYzAgMjEgMGMgMDAgMDAgMmEgODUgNmEgNWMgZjAgNzUg NzMgNjUgNzIgMmQgNzAgIC4hLi4uKi5qXC51c2VyLXANCnR1bjA6IFN5bmM6 ICA3MCA3MCAyMCAzMyAyZSAzNCAyZSAzMiAyMCAyOCA2MiA3NSA2OSA2YyA3 NCAyMCAgcHAgMy40LjIgKGJ1aWx0IA0KdHVuMDogU3luYzogIDUzIDY1IDcw IDIwIDMyIDM4IDIwIDMyIDMwIDMwIDM2IDI5ICAgICAgICAgICAgICBTZXAg MjggMjAwNikNCnR1bjA6IERlYnVnOiBsaW5rX1B1c2hQYWNrZXQ6IFRyYW5z bWl0IHByb3RvIDB4YzAyMQ0KdHVuMDogRGVidWc6IG1fZW5xdWV1ZTogbGVu ID0gMg0KdHVuMDogTENQOiAgTUFHSUNOVU0gODU2YTVjZjANCnR1bjA6IExD UDogIFRFWFQgdXNlci1wcHAgMy40LjIgKGJ1aWx0IFNlcCAyOCAyMDA2KQ0K dHVuMDogTENQOiAgQUNGQ09NUFsyXQ0KdHVuMDogTENQOiAgUFJPVE9DT01Q WzJdDQp0dW4wOiBMQ1A6ICBBQ0NNQVBbNl0gMHgwMDAwMDAwMA0KdHVuMDog TENQOiBkZWZsaW5rOiBTZW5kQ29uZmlnUmVxKDIpIHN0YXRlID0gQWNrLVNl bnQNCnR1bjA6IExDUDogIE1SVVs0XSAxNDkyDQp0dW4wOiBMQ1A6ICBNQUdJ Q05VTVs2XSAweDg1NmE1Y2YwDQp0dW4wOiBEZWJ1ZzogZnNtX091dHB1dA0K dHVuMDogRGVidWc6ICAwMSAwMiAwMCAwZSAwMSAwNCAwNSBkNCAwNSAwNiA4 NSA2YSA1YyBmMCAgICAgICAgLi4uLi4uLi4uLi5qXC4NCnR1bjA6IERlYnVn OiBwcm90b19MYXllclB1c2g6IFVzaW5nIDB4YzAyMQ0KdHVuMDogU3luYzog V3JpdGUNCnR1bjA6IFN5bmM6ICBjMCAyMSAwMSAwMiAwMCAwZSAwMSAwNCAw NSBkNCAwNSAwNiA4NSA2YSA1YyBmMCAgLiEuLi4uLi4uLi4uLmpcLg0KdHVu MDogRGVidWc6IGxpbmtfUHVzaFBhY2tldDogVHJhbnNtaXQgcHJvdG8gMHhj MDIxDQp0dW4wOiBEZWJ1ZzogbV9lbnF1ZXVlOiBsZW4gPSAzDQp0dW4wOiBE ZWJ1ZzogbV9kZXF1ZXVlOiBxdWV1ZSBsZW4gPSAzDQp0dW4wOiBEZWJ1Zzog bGlua19EZXF1ZXVlOiBEZXF1ZXVlZCBmcm9tIHF1ZXVlIDEsIGNvbnRhaW5p bmcgMiBtb3JlIHBhY2tldHMNCnR1bjA6IERlYnVnOiBkZWZsaW5rOiBEZXNj cmlwdG9yV3JpdGU6IHdyb3RlIDIwKDIwKSB0byAxDQp0dW4wOiBEZWJ1Zzog bV9kZXF1ZXVlOiBxdWV1ZSBsZW4gPSAyDQp0dW4wOiBEZWJ1ZzogbGlua19E ZXF1ZXVlOiBEZXF1ZXVlZCBmcm9tIHF1ZXVlIDEsIGNvbnRhaW5pbmcgMSBt b3JlIHBhY2tldHMNCnR1bjA6IERlYnVnOiBkZWZsaW5rOiBEZXNjcmlwdG9y V3JpdGU6IHdyb3RlIDQ0KDQ0KSB0byAxDQp0dW4wOiBEZWJ1ZzogZGVmbGlu azogRGVzY3JpcHRvclJlYWQ6IHJlYWQgNDgvMjA0OCBmcm9tIDENCnR1bjA6 IFN5bmM6IFJlYWQNCnR1bjA6IFN5bmM6ICBjMCAyMSAwNyA3ZSAwMCAyZSAw YyAwMCAwMCAyYSA4NSA2YSA1YyBmMCA3NSA3MyAgLiEufi4uLi4uKi5qXC51 cw0KdHVuMDogU3luYzogIDY1IDcyIDJkIDcwIDcwIDcwIDIwIDMzIDJlIDM0 IDJlIDMyIDIwIDI4IDYyIDc1ICBlci1wcHAgMy40LjIgKGJ1DQp0dW4wOiBT eW5jOiAgNjkgNmMgNzQgMjAgNTMgNjUgNzAgMjAgMzIgMzggMjAgMzIgMzAg MzAgMzYgMjkgIGlsdCBTZXAgMjggMjAwNikNCnR1bjA6IERlYnVnOiBwcm90 b19MYXllclB1bGw6IHVua25vd24gLT4gMHhjMDIxDQp0dW4wOiBEZWJ1Zzog bGlua19QdWxsUGFja2V0OiBEZXNwYXRjaCBwcm90byAweGMwMjENCnR1bjA6 IExDUDogZGVmbGluazogUmVjdkNvZGVSZWooMTI2KSBzdGF0ZSA9IEFjay1T ZW50DQp0dW4wOiBEZWJ1ZzogZGVmbGluazogRGVzY3JpcHRvclJlYWQ6IHJl YWQgMTYvMjA0OCBmcm9tIDENCnR1bjA6IFN5bmM6IFJlYWQNCnR1bjA6IFN5 bmM6ICBjMCAyMSAwMiAwMiAwMCAwZSAwMSAwNCAwNSBkNCAwNSAwNiA4NSA2 YSA1YyBmMCAgLiEuLi4uLi4uLi4uLmpcLg0KdHVuMDogRGVidWc6IHByb3Rv X0xheWVyUHVsbDogdW5rbm93biAtPiAweGMwMjENCnR1bjA6IERlYnVnOiBs aW5rX1B1bGxQYWNrZXQ6IERlc3BhdGNoIHByb3RvIDB4YzAyMQ0KdHVuMDog TENQOiBkZWZsaW5rOiBSZWN2Q29uZmlnQWNrKDIpIHN0YXRlID0gQWNrLVNl bnQNCnR1bjA6IExDUDogIE1SVVs0XSAxNDkyDQp0dW4wOiBMQ1A6ICBNQUdJ Q05VTVs2XSAweDg1NmE1Y2YwDQp0dW4wOiBMQ1A6IGRlZmxpbms6IFN0YXRl IGNoYW5nZSBBY2stU2VudCAtLT4gT3BlbmVkDQp0dW4wOiBMQ1A6IGRlZmxp bms6IExheWVyVXANCnR1bjA6IExRTTogZGVmbGluazogTFFSL0xDUCBFQ0hP IG5vdCBuZWdvdGlhdGVkDQp0dW4wOiBMQ1A6IGRlZmxpbms6IFNlbmRJZGVu dCgxKSBzdGF0ZSA9IE9wZW5lZA0KdHVuMDogRGVidWc6IGZzbV9PdXRwdXQN CnR1bjA6IERlYnVnOiAgMGMgMDEgMDAgMmEgODUgNmEgNWMgZjAgNzUgNzMg NjUgNzIgMmQgNzAgNzAgNzAgIC4uLioualwudXNlci1wcHANCnR1bjA6IERl YnVnOiAgMjAgMzMgMmUgMzQgMmUgMzIgMjAgMjggNjIgNzUgNjkgNmMgNzQg MjAgNTMgNjUgICAzLjQuMiAoYnVpbHQgU2UNCnR1bjA6IERlYnVnOiAgNzAg MjAgMzIgMzggMjAgMzIgMzAgMzAgMzYgMjkgICAgICAgICAgICAgICAgICAg IHAgMjggMjAwNikNCnR1bjA6IERlYnVnOiBwcm90b19MYXllclB1c2g6IFVz aW5nIDB4YzAyMQ0KdHVuMDogU3luYzogV3JpdGUNCnR1bjA6IFN5bmM6ICBj MCAyMSAwYyAwMSAwMCAyYSA4NSA2YSA1YyBmMCA3NSA3MyA2NSA3MiAyZCA3 MCAgLiEuLi4qLmpcLnVzZXItcA0KdHVuMDogU3luYzogIDcwIDcwIDIwIDMz IDJlIDM0IDJlIDMyIDIwIDI4IDYyIDc1IDY5IDZjIDc0IDIwICBwcCAzLjQu MiAoYnVpbHQgDQp0dW4wOiBTeW5jOiAgNTMgNjUgNzAgMjAgMzIgMzggMjAg MzIgMzAgMzAgMzYgMjkgICAgICAgICAgICAgIFNlcCAyOCAyMDA2KQ0KdHVu MDogRGVidWc6IGxpbmtfUHVzaFBhY2tldDogVHJhbnNtaXQgcHJvdG8gMHhj MDIxDQp0dW4wOiBEZWJ1ZzogbV9lbnF1ZXVlOiBsZW4gPSAxDQp0dW4wOiBM Q1A6ICBNQUdJQ05VTSA4NTZhNWNmMA0KdHVuMDogTENQOiAgVEVYVCB1c2Vy LXBwcCAzLjQuMiAoYnVpbHQgU2VwIDI4IDIwMDYpDQp0dW4wOiBQaGFzZTog YnVuZGxlOiBBdXRoZW50aWNhdGUNCnR1bjA6IFBoYXNlOiBkZWZsaW5rOiBo aXMgPSBQQVAsIG1pbmUgPSBub25lDQp0dW4wOiBEZWJ1ZzogcGFwX1JlcTog bmFtZWxlbiA9IDcsIGtleWxlbiA9IDYNCnR1bjA6IFBoYXNlOiBQYXAgT3V0 cHV0OiBtb3JnYW53ICoqKioqKioqDQp0dW4wOiBEZWJ1ZzogcHJvdG9fTGF5 ZXJQdXNoOiBVc2luZyAweGMwMjMNCnR1bjA6IFN5bmM6IFdyaXRlDQp0dW4w OiBTeW5jOiAgYzAgMjMgMDEgMDEgMDAgMTMgMDcgNmQgNmYgNzIgNjcgNjEg NmUgNzcgMDYgMzAgIC4jLi4uLi5tb3JnYW53LjANCnR1bjA6IFN5bmM6ICA0 NiA0MiAzOSAzNSA0MSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgRkI5NUENCnR1bjA6IERlYnVnOiBsaW5rX1B1c2hQYWNrZXQ6IFRyYW5z bWl0IHByb3RvIDB4YzAyMw0KdHVuMDogRGVidWc6IG1fZW5xdWV1ZTogbGVu ID0gMg0KdHVuMDogRGVidWc6IG1fZGVxdWV1ZTogcXVldWUgbGVuID0gMg0K dHVuMDogRGVidWc6IGxpbmtfRGVxdWV1ZTogRGVxdWV1ZWQgZnJvbSBxdWV1 ZSAxLCBjb250YWluaW5nIDEgbW9yZSBwYWNrZXRzDQp0dW4wOiBEZWJ1Zzog ZGVmbGluazogRGVzY3JpcHRvcldyaXRlOiB3cm90ZSA0NCg0NCkgdG8gMQ0K dHVuMDogRGVidWc6IG1fZGVxdWV1ZTogcXVldWUgbGVuID0gMQ0KdHVuMDog RGVidWc6IGxpbmtfRGVxdWV1ZTogRGVxdWV1ZWQgZnJvbSBxdWV1ZSAxLCBj b250YWluaW5nIDAgbW9yZSBwYWNrZXRzDQp0dW4wOiBEZWJ1ZzogZGVmbGlu azogRGVzY3JpcHRvcldyaXRlOiB3cm90ZSAyMSgyMSkgdG8gMQ0KdHVuMDog RGVidWc6IGRlZmxpbms6IERlc2NyaXB0b3JSZWFkOiByZWFkIDQ4LzIwNDgg ZnJvbSAxDQp0dW4wOiBTeW5jOiBSZWFkDQp0dW4wOiBTeW5jOiAgYzAgMjEg MDcgN2YgMDAgMmUgMGMgMDEgMDAgMmEgODUgNmEgNWMgZjAgNzUgNzMgIC4h Li4uLi4uLioualwudXMNCnR1bjA6IFN5bmM6ICA2NSA3MiAyZCA3MCA3MCA3 MCAyMCAzMyAyZSAzNCAyZSAzMiAyMCAyOCA2MiA3NSAgZXItcHBwIDMuNC4y IChidQ0KdHVuMDogU3luYzogIDY5IDZjIDc0IDIwIDUzIDY1IDcwIDIwIDMy IDM4IDIwIDMyIDMwIDMwIDM2IDI5ICBpbHQgU2VwIDI4IDIwMDYpDQp0dW4w OiBEZWJ1ZzogcHJvdG9fTGF5ZXJQdWxsOiB1bmtub3duIC0+IDB4YzAyMQ0K dHVuMDogRGVidWc6IGxpbmtfUHVsbFBhY2tldDogRGVzcGF0Y2ggcHJvdG8g MHhjMDIxDQp0dW4wOiBMQ1A6IGRlZmxpbms6IFJlY3ZDb2RlUmVqKDEyNykg c3RhdGUgPSBPcGVuZWQNCnR1bjA6IERlYnVnOiBkZWZsaW5rOiBEZXNjcmlw dG9yUmVhZDogcmVhZCA3LzIwNDggZnJvbSAxDQp0dW4wOiBTeW5jOiBSZWFk DQp0dW4wOiBTeW5jOiAgYzAgMjMgMDIgMDEgMDAgMDUgMDAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIC4jLi4uLi4NCnR1bjA6IERlYnVnOiBwcm90 b19MYXllclB1bGw6IHVua25vd24gLT4gMHhjMDIzDQp0dW4wOiBEZWJ1Zzog bGlua19QdWxsUGFja2V0OiBEZXNwYXRjaCBwcm90byAweGMwMjMNCnR1bjA6 IFBoYXNlOiBQYXAgSW5wdXQ6IFNVQ0NFU1MgKCkNCnR1bjA6IENDUDogRlNN OiBVc2luZyAiZGVmbGluayIgYXMgYSB0cmFuc3BvcnQNCnR1bjA6IENDUDog ZGVmbGluazogU3RhdGUgY2hhbmdlIEluaXRpYWwgLS0+IENsb3NlZA0KdHVu MDogQ0NQOiBkZWZsaW5rOiBMYXllclN0YXJ0Lg0KdHVuMDogQ0NQOiBNUFBF OiBOb3QgdXNhYmxlIHdpdGhvdXQgQ0hBUDgxDQp0dW4wOiBDQ1A6IGRlZmxp bms6IFNlbmRDb25maWdSZXEoMSkgc3RhdGUgPSBDbG9zZWQNCnR1bjA6IEND UDogIERFRkxBVEVbNF0gd2luIDE1DQp0dW4wOiBDQ1A6ICBQUkVEMVsyXSAN CnR1bjA6IERlYnVnOiBmc21fT3V0cHV0DQp0dW4wOiBEZWJ1ZzogIDAxIDAx IDAwIDBhIDFhIDA0IDc4IDAwIDAxIDAyICAgICAgICAgICAgICAgICAgICAu Li4uLi54Li4uDQp0dW4wOiBEZWJ1ZzogcHJvdG9fTGF5ZXJQdXNoOiBVc2lu ZyAweDgwZmQNCnR1bjA6IFN5bmM6IFdyaXRlDQp0dW4wOiBTeW5jOiAgODAg ZmQgMDEgMDEgMDAgMGEgMWEgMDQgNzggMDAgMDEgMDIgICAgICAgICAgICAg IC4uLi4uLi4ueC4uLg0KdHVuMDogRGVidWc6IGxpbmtfUHVzaFBhY2tldDog VHJhbnNtaXQgcHJvdG8gMHg4MGZkDQp0dW4wOiBEZWJ1ZzogbV9lbnF1ZXVl OiBsZW4gPSAxDQp0dW4wOiBDQ1A6IGRlZmxpbms6IFN0YXRlIGNoYW5nZSBD bG9zZWQgLS0+IFJlcS1TZW50DQp0dW4wOiBQaGFzZTogZGVmbGluazogbGNw IC0+IG9wZW4NCnR1bjA6IFBoYXNlOiBidW5kbGU6IE5ldHdvcmsNCnR1bjA6 IElQQ1A6IEZTTTogVXNpbmcgImRlZmxpbmsiIGFzIGEgdHJhbnNwb3J0DQp0 dW4wOiBJUENQOiBkZWZsaW5rOiBTdGF0ZSBjaGFuZ2UgSW5pdGlhbCAtLT4g Q2xvc2VkDQp0dW4wOiBJUENQOiBkZWZsaW5rOiBMYXllclN0YXJ0Lg0KdHVu MDogSVBDUDogZGVmbGluazogU2VuZENvbmZpZ1JlcSgxKSBzdGF0ZSA9IENs b3NlZA0KdHVuMDogSVBDUDogIElQQUREUls2XSAxOTIuMTY4LjAuMQ0KdHVu MDogSVBDUDogIENPTVBQUk9UT1s2XSAxNiBWSiBzbG90cyB3aXRoIHNsb3Qg Y29tcHJlc3Npb24NCnR1bjA6IERlYnVnOiBmc21fT3V0cHV0DQp0dW4wOiBE ZWJ1ZzogIDAxIDAxIDAwIDEwIDAzIDA2IGMwIGE4IDAwIDAxIDAyIDA2IDAw IDJkIDBmIDAxICAuLi4uLi4uLi4uLi4uLS4uDQp0dW4wOiBEZWJ1ZzogcHJv dG9fTGF5ZXJQdXNoOiBVc2luZyAweDgwMjENCnR1bjA6IFN5bmM6IFdyaXRl DQp0dW4wOiBTeW5jOiAgODAgMjEgMDEgMDEgMDAgMTAgMDMgMDYgYzAgYTgg MDAgMDEgMDIgMDYgMDAgMmQgIC4hLi4uLi4uLi4uLi4uLi0NCnR1bjA6IFN5 bmM6ICAwZiAwMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLi4NCnR1bjA6IERlYnVnOiBsaW5rX1B1c2hQYWNrZXQ6IFRy YW5zbWl0IHByb3RvIDB4ODAyMQ0KdHVuMDogRGVidWc6IG1fZW5xdWV1ZTog bGVuID0gMg0KdHVuMDogSVBDUDogZGVmbGluazogU3RhdGUgY2hhbmdlIENs b3NlZCAtLT4gUmVxLVNlbnQNCnR1bjA6IERlYnVnOiBkZWZsaW5rOiBEZXNj cmlwdG9yUmVhZDogcmVhZCAxMi8yMDQ4IGZyb20gMQ0KdHVuMDogU3luYzog UmVhZA0KdHVuMDogU3luYzogIDgwIDIxIDAxIDFhIDAwIDBhIDAzIDA2IDQy IDk5IDkwIDAxICAgICAgICAgICAgICAuIS4uLi4uLkIuLi4NCnR1bjA6IERl YnVnOiBwcm90b19MYXllclB1bGw6IHVua25vd24gLT4gMHg4MDIxDQp0dW4w OiBEZWJ1ZzogbGlua19QdWxsUGFja2V0OiBEZXNwYXRjaCBwcm90byAweDgw MjENCnR1bjA6IElQQ1A6IGRlZmxpbms6IFJlY3ZDb25maWdSZXEoMjYpIHN0 YXRlID0gUmVxLVNlbnQNCnR1bjA6IElQQ1A6ICBJUEFERFJbNl0gNjYuMTUz LjE0NC4xDQp0dW4wOiBJUENQOiBkZWZsaW5rOiBTZW5kQ29uZmlnQWNrKDI2 KSBzdGF0ZSA9IFJlcS1TZW50DQp0dW4wOiBJUENQOiAgSVBBRERSWzZdIDY2 LjE1My4xNDQuMQ0KdHVuMDogRGVidWc6IGZzbV9PdXRwdXQNCnR1bjA6IERl YnVnOiAgMDIgMWEgMDAgMGEgMDMgMDYgNDIgOTkgOTAgMDEgICAgICAgICAg ICAgICAgICAgIC4uLi4uLkIuLi4NCnR1bjA6IERlYnVnOiBwcm90b19MYXll clB1c2g6IFVzaW5nIDB4ODAyMQ0KdHVuMDogU3luYzogV3JpdGUNCnR1bjA6 IFN5bmM6ICA4MCAyMSAwMiAxYSAwMCAwYSAwMyAwNiA0MiA5OSA5MCAwMSAg ICAgICAgICAgICAgLiEuLi4uLi5CLi4uDQp0dW4wOiBEZWJ1ZzogbGlua19Q dXNoUGFja2V0OiBUcmFuc21pdCBwcm90byAweDgwMjENCnR1bjA6IERlYnVn OiBtX2VucXVldWU6IGxlbiA9IDMNCnR1bjA6IElQQ1A6IGRlZmxpbms6IFN0 YXRlIGNoYW5nZSBSZXEtU2VudCAtLT4gQWNrLVNlbnQNCnR1bjA6IERlYnVn OiBtX2RlcXVldWU6IHF1ZXVlIGxlbiA9IDMNCnR1bjA6IERlYnVnOiBsaW5r X0RlcXVldWU6IERlcXVldWVkIGZyb20gcXVldWUgMSwgY29udGFpbmluZyAy IG1vcmUgcGFja2V0cw0KdHVuMDogRGVidWc6IGRlZmxpbms6IERlc2NyaXB0 b3JXcml0ZTogd3JvdGUgMTIoMTIpIHRvIDENCnR1bjA6IERlYnVnOiBtX2Rl cXVldWU6IHF1ZXVlIGxlbiA9IDINCnR1bjA6IERlYnVnOiBsaW5rX0RlcXVl dWU6IERlcXVldWVkIGZyb20gcXVldWUgMSwgY29udGFpbmluZyAxIG1vcmUg cGFja2V0cw0KdHVuMDogRGVidWc6IGRlZmxpbms6IERlc2NyaXB0b3JXcml0 ZTogd3JvdGUgMTgoMTgpIHRvIDENCnR1bjA6IERlYnVnOiBtX2RlcXVldWU6 IHF1ZXVlIGxlbiA9IDENCnR1bjA6IERlYnVnOiBsaW5rX0RlcXVldWU6IERl cXVldWVkIGZyb20gcXVldWUgMSwgY29udGFpbmluZyAwIG1vcmUgcGFja2V0 cw0KdHVuMDogRGVidWc6IGRlZmxpbms6IERlc2NyaXB0b3JXcml0ZTogd3Jv dGUgMTIoMTIpIHRvIDENCnR1bjA6IERlYnVnOiBkZWZsaW5rOiBEZXNjcmlw dG9yUmVhZDogcmVhZCAxMi8yMDQ4IGZyb20gMQ0KdHVuMDogU3luYzogUmVh ZA0KdHVuMDogU3luYzogIDgwIDIxIDA0IDAxIDAwIDBhIDAyIDA2IDAwIDJk IDBmIDAxICAgICAgICAgICAgICAuIS4uLi4uLi4tLi4NCnR1bjA6IERlYnVn OiBwcm90b19MYXllclB1bGw6IHVua25vd24gLT4gMHg4MDIxDQp0dW4wOiBE ZWJ1ZzogbGlua19QdWxsUGFja2V0OiBEZXNwYXRjaCBwcm90byAweDgwMjEN CnR1bjA6IElQQ1A6IGRlZmxpbms6IFJlY3ZDb25maWdSZWooMSkgc3RhdGUg PSBBY2stU2VudA0KdHVuMDogTENQOiBkZWZsaW5rOiBTZW5kSWRlbnQoMikg c3RhdGUgPSBPcGVuZWQNCnR1bjA6IERlYnVnOiBmc21fT3V0cHV0DQp0dW4w OiBEZWJ1ZzogIDBjIDAyIDAwIDJhIDg1IDZhIDVjIGYwIDc1IDczIDY1IDcy IDJkIDcwIDcwIDcwICAuLi4qLmpcLnVzZXItcHBwDQp0dW4wOiBEZWJ1Zzog IDIwIDMzIDJlIDM0IDJlIDMyIDIwIDI4IDYyIDc1IDY5IDZjIDc0IDIwIDUz IDY1ICAgMy40LjIgKGJ1aWx0IFNlDQp0dW4wOiBEZWJ1ZzogIDcwIDIwIDMy IDM4IDIwIDMyIDMwIDMwIDM2IDI5ICAgICAgICAgICAgICAgICAgICBwIDI4 IDIwMDYpDQp0dW4wOiBEZWJ1ZzogcHJvdG9fTGF5ZXJQdXNoOiBVc2luZyAw eGMwMjENCnR1bjA6IFN5bmM6IFdyaXRlDQp0dW4wOiBTeW5jOiAgYzAgMjEg MGMgMDIgMDAgMmEgODUgNmEgNWMgZjAgNzUgNzMgNjUgNzIgMmQgNzAgIC4h Li4uKi5qXC51c2VyLXANCnR1bjA6IFN5bmM6ICA3MCA3MCAyMCAzMyAyZSAz NCAyZSAzMiAyMCAyOCA2MiA3NSA2OSA2YyA3NCAyMCAgcHAgMy40LjIgKGJ1 aWx0IA0KdHVuMDogU3luYzogIDUzIDY1IDcwIDIwIDMyIDM4IDIwIDMyIDMw IDMwIDM2IDI5ICAgICAgICAgICAgICBTZXAgMjggMjAwNikNCnR1bjA6IERl YnVnOiBsaW5rX1B1c2hQYWNrZXQ6IFRyYW5zbWl0IHByb3RvIDB4YzAyMQ0K dHVuMDogRGVidWc6IG1fZW5xdWV1ZTogbGVuID0gMQ0KdHVuMDogTENQOiAg TUFHSUNOVU0gODU2YTVjZjANCnR1bjA6IExDUDogIFRFWFQgdXNlci1wcHAg My40LjIgKGJ1aWx0IFNlcCAyOCAyMDA2KQ0KdHVuMDogSVBDUDogIENPTVBQ Uk9UT1s2XSAxNiBWSiBzbG90cyB3aXRoIHNsb3QgY29tcHJlc3Npb24NCnR1 bjA6IElQQ1A6IGRlZmxpbms6IFNlbmRDb25maWdSZXEoMikgc3RhdGUgPSBB Y2stU2VudA0KdHVuMDogSVBDUDogIElQQUREUls2XSAxOTIuMTY4LjAuMQ0K dHVuMDogRGVidWc6IGZzbV9PdXRwdXQNCnR1bjA6IERlYnVnOiAgMDEgMDIg MDAgMGEgMDMgMDYgYzAgYTggMDAgMDEgICAgICAgICAgICAgICAgICAgIC4u Li4uLi4uLi4NCnR1bjA6IERlYnVnOiBwcm90b19MYXllclB1c2g6IFVzaW5n IDB4ODAyMQ0KdHVuMDogU3luYzogV3JpdGUNCnR1bjA6IFN5bmM6ICA4MCAy MSAwMSAwMiAwMCAwYSAwMyAwNiBjMCBhOCAwMCAwMSAgICAgICAgICAgICAg LiEuLi4uLi4uLi4uDQp0dW4wOiBEZWJ1ZzogbGlua19QdXNoUGFja2V0OiBU cmFuc21pdCBwcm90byAweDgwMjENCnR1bjA6IERlYnVnOiBtX2VucXVldWU6 IGxlbiA9IDINCnR1bjA6IERlYnVnOiBtX2RlcXVldWU6IHF1ZXVlIGxlbiA9 IDINCnR1bjA6IERlYnVnOiBsaW5rX0RlcXVldWU6IERlcXVldWVkIGZyb20g cXVldWUgMSwgY29udGFpbmluZyAxIG1vcmUgcGFja2V0cw0KdHVuMDogRGVi dWc6IGRlZmxpbms6IERlc2NyaXB0b3JXcml0ZTogd3JvdGUgNDQoNDQpIHRv IDENCnR1bjA6IERlYnVnOiBtX2RlcXVldWU6IHF1ZXVlIGxlbiA9IDENCnR1 bjA6IERlYnVnOiBsaW5rX0RlcXVldWU6IERlcXVldWVkIGZyb20gcXVldWUg MSwgY29udGFpbmluZyAwIG1vcmUgcGFja2V0cw0KdHVuMDogRGVidWc6IGRl Zmxpbms6IERlc2NyaXB0b3JXcml0ZTogd3JvdGUgMTIoMTIpIHRvIDENCnR1 bjA6IERlYnVnOiBkZWZsaW5rOiBEZXNjcmlwdG9yUmVhZDogcmVhZCA0OC8y MDQ4IGZyb20gMQ0KdHVuMDogU3luYzogUmVhZA0KdHVuMDogU3luYzogIGMw IDIxIDA3IDgwIDAwIDJlIDBjIDAyIDAwIDJhIDg1IDZhIDVjIGYwIDc1IDcz ICAuIS4uLi4uLi4qLmpcLnVzDQp0dW4wOiBTeW5jOiAgNjUgNzIgMmQgNzAg NzAgNzAgMjAgMzMgMmUgMzQgMmUgMzIgMjAgMjggNjIgNzUgIGVyLXBwcCAz LjQuMiAoYnUNCnR1bjA6IFN5bmM6ICA2OSA2YyA3NCAyMCA1MyA2NSA3MCAy MCAzMiAzOCAyMCAzMiAzMCAzMCAzNiAyOSAgaWx0IFNlcCAyOCAyMDA2KQ0K dHVuMDogRGVidWc6IHByb3RvX0xheWVyUHVsbDogdW5rbm93biAtPiAweGMw MjENCnR1bjA6IERlYnVnOiBsaW5rX1B1bGxQYWNrZXQ6IERlc3BhdGNoIHBy b3RvIDB4YzAyMQ0KdHVuMDogTENQOiBkZWZsaW5rOiBSZWN2Q29kZVJlaigx MjgpIHN0YXRlID0gT3BlbmVkDQp0dW4wOiBEZWJ1ZzogZGVmbGluazogRGVz Y3JpcHRvclJlYWQ6IHJlYWQgMTIvMjA0OCBmcm9tIDENCnR1bjA6IFN5bmM6 IFJlYWQNCnR1bjA6IFN5bmM6ICA4MCAyMSAwMyAwMiAwMCAwYSAwMyAwNiA0 MiA5OSA5MCAwYiAgICAgICAgICAgICAgLiEuLi4uLi5CLi4uDQp0dW4wOiBE ZWJ1ZzogcHJvdG9fTGF5ZXJQdWxsOiB1bmtub3duIC0+IDB4ODAyMQ0KdHVu MDogRGVidWc6IGxpbmtfUHVsbFBhY2tldDogRGVzcGF0Y2ggcHJvdG8gMHg4 MDIxDQp0dW4wOiBJUENQOiBkZWZsaW5rOiBSZWN2Q29uZmlnTmFrKDIpIHN0 YXRlID0gQWNrLVNlbnQNCnR1bjA6IElQQ1A6ICBJUEFERFJbNl0gNjYuMTUz LjE0NC4xMQ0KdHVuMDogSVBDUDogIElQQUREUls2XSBjaGFuZ2luZyBhZGRy ZXNzOiAxOTIuMTY4LjAuMSAgLS0+IDY2LjE1My4xNDQuMTENCnR1bjA6IElQ Q1A6IGRlZmxpbms6IFNlbmRDb25maWdSZXEoMykgc3RhdGUgPSBBY2stU2Vu dA0KdHVuMDogSVBDUDogIElQQUREUls2XSA2Ni4xNTMuMTQ0LjExDQp0dW4w OiBEZWJ1ZzogZnNtX091dHB1dA0KdHVuMDogRGVidWc6ICAwMSAwMyAwMCAw YSAwMyAwNiA0MiA5OSA5MCAwYiAgICAgICAgICAgICAgICAgICAgLi4uLi4u Qi4uLg0KdHVuMDogRGVidWc6IHByb3RvX0xheWVyUHVzaDogVXNpbmcgMHg4 MDIxDQp0dW4wOiBTeW5jOiBXcml0ZQ0KdHVuMDogU3luYzogIDgwIDIxIDAx IDAzIDAwIDBhIDAzIDA2IDQyIDk5IDkwIDBiICAgICAgICAgICAgICAuIS4u Li4uLkIuLi4NCnR1bjA6IERlYnVnOiBsaW5rX1B1c2hQYWNrZXQ6IFRyYW5z bWl0IHByb3RvIDB4ODAyMQ0KdHVuMDogRGVidWc6IG1fZW5xdWV1ZTogbGVu ID0gMQ0KdHVuMDogRGVidWc6IG1fZGVxdWV1ZTogcXVldWUgbGVuID0gMQ0K dHVuMDogRGVidWc6IGxpbmtfRGVxdWV1ZTogRGVxdWV1ZWQgZnJvbSBxdWV1 ZSAxLCBjb250YWluaW5nIDAgbW9yZSBwYWNrZXRzDQp0dW4wOiBEZWJ1Zzog ZGVmbGluazogRGVzY3JpcHRvcldyaXRlOiB3cm90ZSAxMigxMikgdG8gMQ0K dHVuMDogRGVidWc6IGRlZmxpbms6IERlc2NyaXB0b3JSZWFkOiByZWFkIDEy LzIwNDggZnJvbSAxDQp0dW4wOiBTeW5jOiBSZWFkDQp0dW4wOiBTeW5jOiAg ODAgMjEgMDIgMDMgMDAgMGEgMDMgMDYgNDIgOTkgOTAgMGIgICAgICAgICAg ICAgIC4hLi4uLi4uQi4uLg0KdHVuMDogRGVidWc6IHByb3RvX0xheWVyUHVs bDogdW5rbm93biAtPiAweDgwMjENCnR1bjA6IERlYnVnOiBsaW5rX1B1bGxQ YWNrZXQ6IERlc3BhdGNoIHByb3RvIDB4ODAyMQ0KdHVuMDogSVBDUDogZGVm bGluazogUmVjdkNvbmZpZ0FjaygzKSBzdGF0ZSA9IEFjay1TZW50DQp0dW4w OiBJUENQOiAgSVBBRERSWzZdIDY2LjE1My4xNDQuMTENCnR1bjA6IElQQ1A6 IGRlZmxpbms6IFN0YXRlIGNoYW5nZSBBY2stU2VudCAtLT4gT3BlbmVkDQp0 dW4wOiBJUENQOiBkZWZsaW5rOiBMYXllclVwLg0KdHVuMDogSVBDUDogbXlh ZGRyIDY2LjE1My4xNDQuMTEgaGlzYWRkciA9IDY2LjE1My4xNDQuMQ0KdHVu MDogSUQwOiAyID0gc29ja2V0KDIsIDIsIDApDQp0dW4wOiBJRDA6IDAgPSBp b2N0bCgyLCAyMTUxNzA0ODU4LCAweGJmYmZkNWEwKQ0KdHVuMDogV2Fybmlu ZzogdHVuMDogQUlGQUREUiA2Ni4xNTMuMTQ0LjExIC0+IDY2LjE1My4xNDQu MSByZXR1cm5zIDANCnR1bjA6IElEMDogMiA9IHNvY2tldCgxNywgMywgMCkN CnR1bjA6IElEMDogMTQwID0gd3JpdGUoMiwgZGF0YSwgMTQwKQ0KdHVuMDog RGVidWc6IHdyb3RlIDE0MDogY21kID0gQWRkISwgZHN0ID0gMC4wLjAuMC8w LCBnYXRld2F5ID0gNjYuMTUzLjE0NC4xDQp0dW4wOiBJRDA6IDIgPSBzb2Nr ZXQoMiwgMiwgMCkNCnR1bjA6IElEMDogMCA9IGlvY3RsKDIsIDMyMjMzNDk1 MjEsIDB4YmZiZmQ3ZTApDQp0dW4wOiBJRDA6IDAgPSBpb2N0bCgyLCAyMTQ5 NjA3Njk2LCAweGJmYmZkN2UwKQ0KdHVuMDogSUQwOiAweDAgPSBmb3Blbigi L2V0Yy9wcHAvcHBwLmxpbmt1cCIsICJyIikNCnR1bjA6IERlYnVnOiBSZWFk U3lzdGVtOiBDYW4ndCBvcGVuIC9ldGMvcHBwL3BwcC5saW5rdXAuDQp0dW4w OiBJRDA6IDB4MCA9IGZvcGVuKCIvZXRjL3BwcC9wcHAubGlua3VwIiwgInIi KQ0KdHVuMDogRGVidWc6IFJlYWRTeXN0ZW06IENhbid0IG9wZW4gL2V0Yy9w cHAvcHBwLmxpbmt1cC4NCnR1bjA6IElEMDogMHgwID0gZm9wZW4oIi9ldGMv cHBwL3BwcC5saW5rdXAiLCAiciIpDQp0dW4wOiBEZWJ1ZzogUmVhZFN5c3Rl bTogQ2FuJ3Qgb3BlbiAvZXRjL3BwcC9wcHAubGlua3VwLg0KdHVuMDogRGVi dWc6IGRlZmxpbms6IFBQUG9FOnhsMDogQ2Fubm90IGRldGVybWluZSBiYW5k d2lkdGgNCnR1bjA6IElEMDogMCA9IGlvY3RsKDYsIDIxNDgwMzc3MjMsIDB4 YmZiZmQ4NTApDQp0dW4wOiBEZWJ1Zzogcm91dGVfVXBkYXRlTVRVICg2KQ0K dHVuMDogVENQL0lQOiByb3V0ZV9VcGRhdGVNVFU6IE5ldGlmOiA2ICh0dW4w KSwgZHN0IDAuMC4wLjAvMCwgbXR1IDE0OTINCnR1bjA6IElEMDogMiA9IHNv Y2tldCgxNywgMywgMCkNCnR1bjA6IElEMDogMTI0ID0gd3JpdGUoMiwgZGF0 YSwgMTI0KQ0KdHVuMDogVENQL0lQOiByb3V0ZV9VcGRhdGVNVFU6IE5ldGlm OiA2ICh0dW4wKSwgZHN0IDY2LjE1My4xNDQuMSwgbXR1IDE0OTINCnR1bjA6 IElEMDogMiA9IHNvY2tldCgxNywgMywgMCkNCnR1bjA6IElEMDogMTI0ID0g d3JpdGUoMiwgZGF0YSwgMTI0KQ0KdHVuMDogRGVidWc6IGRlZmxpbms6IERl c2NyaXB0b3JSZWFkOiByZWFkIDYxLzIwNDggZnJvbSAxDQp0dW4wOiBTeW5j OiBSZWFkDQp0dW4wOiBTeW5jOiAgMDAgMjEgNDUgMDAgMDAgM2IgZTYgMDUg MDAgMDAgNmMgMTEgNjcgMjcgNDUgNzYgIC4hRS4uOy4uLi5sLmcnRXYNCnR1 bjA6IFN5bmM6ICBlOSA2YSA0MiA5OSA5MCAwYiA1OSBlNiBjYSBmMyAwMCAy NyA2ZCBlMCBkOSAxNCAgLmpCLi4uWS4uLi4nbS4uLg0KdHVuMDogU3luYzog IDdiIDQ0IGVmIDJjIGQwIDMxIDZlIDJiIGJmIDcxIDIxIDliIDAwIDAwIDAw IDAxICB7RC4sLjFuKy5xIS4uLi4uDQp0dW4wOiBTeW5jOiAgMDAgMDggMDAg MDAgMDAgYzMgODMgNTMgNDMgNTAgNDEgMDAgMDAgICAgICAgICAgIC4uLi4u Li5TQ1BBLi4NCnR1bjA6IERlYnVnOiBwcm90b19MYXllclB1bGw6IHVua25v d24gLT4gMHgwMDIxDQp0dW4wOiBEZWJ1ZzogbGlua19QdWxsUGFja2V0OiBE ZXNwYXRjaCBwcm90byAweDAwMjENCnR1bjA6IFRDUC9JUDogSU4gVURQOiA2 OS4xMTguMjMzLjEwNjoyMzAxNCAtLS0+IDY2LjE1My4xNDQuMTE6NTE5NTUg KDMxLzU5KQ0KdHVuMDogVENQL0lQOiBPVVQgSUNNUDogNjYuMTUzLjE0NC4x MTozIC0tLT4gNjkuMTE4LjIzMy4xMDYgKDgvNTYpDQp0dW4wOiBEZWJ1Zzog bV9lbnF1ZXVlOiBsZW4gPSAxDQp0dW4wOiBEZWJ1ZzogbV9kZXF1ZXVlOiBx dWV1ZSBsZW4gPSAxDQp0dW4wOiBEZWJ1ZzogcHJvdG9fTGF5ZXJQdXNoOiBV c2luZyAweDAwMjENCnR1bjA6IFN5bmM6IFdyaXRlDQp0dW4wOiBTeW5jOiAg MDAgMjEgNDUgMDAgMDAgMzggZGQgYmMgMDAgMDAgNDAgMDEgOWIgODMgNDIg OTkgIC4hRS4uOC4uLi5ALi4uQi4NCnR1bjA6IFN5bmM6ICA5MCAwYiA0NSA3 NiBlOSA2YSAwMyAwMyA2YSAxYiAwMCAwMCAwMCAwMCA0NSAwMCAgLi5Fdi5q Li5qLi4uLi5FLg0KdHVuMDogU3luYzogIDAwIDNiIGU2IDA1IDAwIDAwIDZj IDExIDY3IDI3IDQ1IDc2IGU5IDZhIDQyIDk5ICAuOy4uLi5sLmcnRXYuakIu DQp0dW4wOiBTeW5jOiAgOTAgMGIgNTkgZTYgY2EgZjMgMDAgMjcgNmQgZTAg ICAgICAgICAgICAgICAgICAgIC4uWS4uLi4nbS4NCnR1bjA6IERlYnVnOiBs aW5rX1B1c2hQYWNrZXQ6IFRyYW5zbWl0IHByb3RvIDB4MDAyMQ0KdHVuMDog RGVidWc6IG1fZW5xdWV1ZTogbGVuID0gMQ0KdHVuMDogRGVidWc6IG1fZGVx dWV1ZTogcXVldWUgbGVuID0gMQ0KdHVuMDogRGVidWc6IGxpbmtfRGVxdWV1 ZTogRGVxdWV1ZWQgZnJvbSBxdWV1ZSAwLCBjb250YWluaW5nIDAgbW9yZSBw YWNrZXRzDQp0dW4wOiBEZWJ1ZzogZGVmbGluazogRGVzY3JpcHRvcldyaXRl OiB3cm90ZSA1OCg1OCkgdG8gMQ0KdHVuMDogQ0NQOiBNUFBFOiBOb3QgdXNh YmxlIHdpdGhvdXQgQ0hBUDgxDQp0dW4wOiBDQ1A6IGRlZmxpbms6IFNlbmRD b25maWdSZXEoMSkgc3RhdGUgPSBSZXEtU2VudA0KdHVuMDogQ0NQOiAgREVG TEFURVs0XSB3aW4gMTUNCnR1bjA6IENDUDogIFBSRUQxWzJdIA0KdHVuMDog RGVidWc6IGZzbV9PdXRwdXQNCnR1bjA6IERlYnVnOiAgMDEgMDEgMDAgMGEg MWEgMDQgNzggMDAgMDEgMDIgICAgICAgICAgICAgICAgICAgIC4uLi4uLngu Li4NCnR1bjA6IERlYnVnOiBwcm90b19MYXllclB1c2g6IFVzaW5nIDB4ODBm ZA0KdHVuMDogU3luYzogV3JpdGUNCnR1bjA6IFN5bmM6ICA4MCBmZCAwMSAw MSAwMCAwYSAxYSAwNCA3OCAwMCAwMSAwMiAgICAgICAgICAgICAgLi4uLi4u Li54Li4uDQp0dW4wOiBEZWJ1ZzogbGlua19QdXNoUGFja2V0OiBUcmFuc21p dCBwcm90byAweDgwZmQNCnR1bjA6IERlYnVnOiBtX2VucXVldWU6IGxlbiA9 IDENCnR1bjA6IERlYnVnOiBtX2RlcXVldWU6IHF1ZXVlIGxlbiA9IDENCnR1 bjA6IERlYnVnOiBsaW5rX0RlcXVldWU6IERlcXVldWVkIGZyb20gcXVldWUg MSwgY29udGFpbmluZyAwIG1vcmUgcGFja2V0cw0KdHVuMDogRGVidWc6IGRl Zmxpbms6IERlc2NyaXB0b3JXcml0ZTogd3JvdGUgMTIoMTIpIHRvIDENCnR1 bjA6IERlYnVnOiBkZWZsaW5rOiBEZXNjcmlwdG9yUmVhZDogcmVhZCAxOC8y MDQ4IGZyb20gMQ0KdHVuMDogU3luYzogUmVhZA0KdHVuMDogU3luYzogIGMw IDIxIDA4IDAwIDAwIDEwIDgwIGZkIDAxIDAxIDAwIDBhIDFhIDA0IDc4IDAw ICAuIS4uLi4uLi4uLi4uLnguDQp0dW4wOiBTeW5jOiAgMDEgMDIgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC4uDQp0dW4w OiBEZWJ1ZzogcHJvdG9fTGF5ZXJQdWxsOiB1bmtub3duIC0+IDB4YzAyMQ0K dHVuMDogRGVidWc6IGxpbmtfUHVsbFBhY2tldDogRGVzcGF0Y2ggcHJvdG8g MHhjMDIxDQp0dW4wOiBMQ1A6IGRlZmxpbms6IFJlY3ZQcm90b2NvbFJlaigw KSBzdGF0ZSA9IE9wZW5lZA0KdHVuMDogTENQOiBkZWZsaW5rOiAtLSBQcm90 b2NvbCAweDgwZmQgKENvbXByZXNzaW9uIENvbnRyb2wgUHJvdG9jb2wpIHdh cyByZWplY3RlZCENCnR1bjA6IENDUDogZGVmbGluazogU3RhdGUgY2hhbmdl IFJlcS1TZW50IC0tPiBTdG9wcGVkDQp0dW4wOiBEZWJ1ZzogZGVmbGluazog RGVzY3JpcHRvclJlYWQ6IHJlYWQgMTAvMjA0OCBmcm9tIDENCnR1bjA6IFN5 bmM6IFJlYWQNCnR1bjA6IFN5bmM6ICBjMCAyMSAwOSAwMSAwMCAwOCAwMyA5 ZSAzYSBjZiAgICAgICAgICAgICAgICAgICAgLiEuLi4uLi46Lg0KdHVuMDog RGVidWc6IHByb3RvX0xheWVyUHVsbDogdW5rbm93biAtPiAweGMwMjENCnR1 bjA6IERlYnVnOiBsaW5rX1B1bGxQYWNrZXQ6IERlc3BhdGNoIHByb3RvIDB4 YzAyMQ0KdHVuMDogTENQOiBkZWZsaW5rOiBSZWN2RWNob1JlcXVlc3QoMSkg c3RhdGUgPSBPcGVuZWQNCnR1bjA6IExDUDogZGVmbGluazogU2VuZEVjaG9S ZXBseSgxKSBzdGF0ZSA9IE9wZW5lZA0KdHVuMDogRGVidWc6IGZzbV9PdXRw dXQNCnR1bjA6IERlYnVnOiAgMGEgMDEgMDAgMDggODUgNmEgNWMgZjAgICAg ICAgICAgICAgICAgICAgICAgICAgIC4uLi4ualwuDQp0dW4wOiBEZWJ1Zzog cHJvdG9fTGF5ZXJQdXNoOiBVc2luZyAweGMwMjENCnR1bjA6IFN5bmM6IFdy aXRlDQp0dW4wOiBTeW5jOiAgYzAgMjEgMGEgMDEgMDAgMDggODUgNmEgNWMg ZjAgICAgICAgICAgICAgICAgICAgIC4hLi4uLi5qXC4NCnR1bjA6IERlYnVn OiBsaW5rX1B1c2hQYWNrZXQ6IFRyYW5zbWl0IHByb3RvIDB4YzAyMQ0KdHVu MDogRGVidWc6IG1fZW5xdWV1ZTogbGVuID0gMQ0KdHVuMDogRGVidWc6IG1f ZGVxdWV1ZTogcXVldWUgbGVuID0gMQ0KdHVuMDogRGVidWc6IGxpbmtfRGVx dWV1ZTogRGVxdWV1ZWQgZnJvbSBxdWV1ZSAxLCBjb250YWluaW5nIDAgbW9y ZSBwYWNrZXRzDQp0dW4wOiBEZWJ1ZzogZGVmbGluazogRGVzY3JpcHRvcldy aXRlOiB3cm90ZSAxMCgxMCkgdG8gMQ0K --0-1824411618-1161984709=:82826-- From owner-freebsd-net@FreeBSD.ORG Fri Oct 27 22:07:53 2006 Return-Path: X-Original-To: net@freebsd.org 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 0914616A412 for ; Fri, 27 Oct 2006 22:07:53 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 7B57A43D5A for ; Fri, 27 Oct 2006 22:07:51 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 3915 invoked by uid 399); 27 Oct 2006 22:07:50 -0000 Received: from localhost (HELO ?192.168.0.8?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 27 Oct 2006 22:07:50 -0000 Message-ID: <45428334.8010909@FreeBSD.org> Date: Fri, 27 Oct 2006 15:07:48 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: joe@joeholden.co.uk References: <453C0E42.4010604@joeholden.co.uk> <453C5386.5080102@FreeBSD.org> <453C5979.4050408@yandex.ru> <453D35AB.3000908@joeholden.co.uk> <20061024091523.G45134@knop-beagle.kn.op.dlr.de> <20061024143940.GA52335@lor.one-eyed-alien.net> <453E3085.7040003@joeholden.co.uk> In-Reply-To: <453E3085.7040003@joeholden.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Andrey V. Elsukov" , Harti Brandt , net@freebsd.org Subject: Re: Instructing dhclient to set hostname of client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Oct 2006 22:07:53 -0000 Joe Holden wrote: > Brooks Davis wrote: >> On Tue, Oct 24, 2006 at 09:16:07AM +0200, Harti Brandt wrote: >>> On Mon, 23 Oct 2006, Joe Holden wrote: >>> >>> JH>Andrey V. Elsukov wrote: >>> JH>> Doug Barton wrote: >>> JH>>> If you're talking about a laptop where you're not sure what the DHCP >>> JH>>> server is going to send you, then I have this in /etc/rc.local: >>> JH>> >>> JH>> Hi, Doug. >>> JH>> >>> JH>> What you think about adding a new feature to dhclient - Alternate IP >>> JH>> Configuration. This configuration can be specified in dhclient.conf >>> JH>> and take effect when a DHCP server not respond. MS Windows have a >>> JH>> similar feature. >>> JH>> >>> JH>Really I was hoping dhclient would have this sort of functionality where >>> JH>it would resolve the ip given and set that as hostname, as as far as im >>> JH>aware, isc-dhcpd will not send hostnames? >>> >>> Sure it does. On my machines I set hostname to "" in rc.conf and let >>> dhclient set it. Works fine. >> Once upon a time I implemented some code to add a default_hostname >> variable to rc.conf which was then used by the startup scripts and >> dhclient-script to allow the local network to override the name if >> desired while insuring that the system had a name at all times (required >> for laptop use). I'd take patches to do this. >> >> -- Brooks >> >> P.S. hacking this into rc.local won't work longterm because addresses >> will be assigned in a totally different context. I wasn't suggesting it as a long term fix, I was just trying to answer the OP's question. :) > I wrote an rc.d script called updatehost that does this, its called > after other net scripts, and basically gets the ip from $interface (set > by updatehost_flags="blah0" in rc.conf, and resolves that, seems to > work, a dirty hack but it does the trick. My only concern with that as a longer term solution would be not interfering with a hostname set by dhclient if one exists. I'd have to think more about the different possible combinations here ... Doug -- This .signature sanitized for your protection From owner-freebsd-net@FreeBSD.ORG Sat Oct 28 01:44:38 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 C479E16A407 for ; Sat, 28 Oct 2006 01:44:38 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2139343D49 for ; Sat, 28 Oct 2006 01:44:38 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by nz-out-0102.google.com with SMTP id o37so678347nzf for ; Fri, 27 Oct 2006 18:44:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=W6UJvIc1UJh6+6kv68UwExculMyGG+8obKfbg/VCTmVgIy8CyhSBb+yrfaUAjhSwJCUVm60JkzV0HVQ8UkkMy+a08AXxkaEf43R4IQ3yCMT5oxv4qJAadLu4sEf3SFVmcxjNnEMTWfZq6udv7FAi6/pj63xp0Zr0d5hECUUBmkE= Received: by 10.35.106.18 with SMTP id i18mr537799pym; Fri, 27 Oct 2006 18:44:37 -0700 (PDT) Received: by 10.35.118.6 with HTTP; Fri, 27 Oct 2006 18:44:37 -0700 (PDT) Message-ID: <2a41acea0610271844o4759424cv35a018ffc0c23373@mail.gmail.com> Date: Fri, 27 Oct 2006 18:44:37 -0700 From: "Jack Vogel" To: freebsd-stable@freebsd.org, freebsd-net MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: New em driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 01:44:38 -0000 After a conference call today, it was decided that a merge of my Intel driver base and the STABLE code would take place. This code undoes the INTR_FAST/taskqueue approach for right now. Work will continue to get that to work, but the hope is that this driver will be more stable for the 6.2 release. I encourage everyone that has been having issues to pull the new driver and give us feedback. A few select testers so far have seen stable performance. Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Sat Oct 28 04:30:15 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 E063316A407; Sat, 28 Oct 2006 04:30:14 +0000 (UTC) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan.algebra.com [216.254.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31CDE43D45; Sat, 28 Oct 2006 04:30:14 +0000 (GMT) (envelope-from mi+kde@aldan.algebra.com) Received: from aldan.algebra.com (aldan [127.0.0.1]) by aldan.algebra.com (8.13.8/8.13.7) with ESMTP id k9S4UD15082981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 Oct 2006 00:30:13 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by aldan.algebra.com (8.13.8/8.13.7/Submit) id k9S4UCHP082980; Sat, 28 Oct 2006 00:30:12 -0400 (EDT) (envelope-from mi+kde@aldan.algebra.com) From: Mikhail Teterin To: Gleb Smirnoff Date: Sat, 28 Oct 2006 00:30:11 -0400 User-Agent: KMail/1.9.1 References: <200610211300.09476@aldan> <20061021173358.GC75694@cell.sick.ru> In-Reply-To: <20061021173358.GC75694@cell.sick.ru> X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7whJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, jfvogel@gmail.com Subject: new em-driver still broken (was: Re: em network issues) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 04:30:15 -0000 On Saturday 21 October 2006 13:33, Gleb Smirnoff wrote: = We aren't currently speaking about performance, we need to know whether = kernel with DEVICE_POLLING option makes NIC work stable. Having noticed today's em-driver update, I rebuilt world/kernel and tried the dump-test again. The kernel had the DEVICE_POLLING option in it, but polling was not, actually, enabled on em0. With three simultanious dumps arriving, the system-component of the load was 40-50%: 2 users Load 2.64 0.98 0.41 28 ΦΟΧ 00:13 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 109936 30080 196064 42464 1642672 count All 366172 32684 1413555k 48140 pages Interrupts Proc:r p d s w Csw Trp Sys Int Sof Flt cow 6720 total 3 55 9736 151241k19989 47 232248 wire irq1: atkb 79108 act irq6: fdc0 35.8%Sys 4.5%Intr 59.7%User 0.0%Nice 0.0%Idl 60372 inact irq15: ata | | | | | | | | | | 276 cache irq17: fwo ==================++>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1642396 free irq20: nve daefr irq21: ohc Namei Name-cache Dir-cache prcfr irq22: ehc Calls hits % hits % react 2710 irq25: em0 229 229 100 pdwak 24 irq29: amr zfod pdpgs 1993 cpu0: time Disks ad4 ad6 amrd0 ozfod intrn 1993 cpu1: time KB/t 0.00 0.00 128 %slo-z 221184 buf tps 0 0 12 4 tfree 22 dirtybuf MB/s 0.00 0.00 1.49 100000 desiredvnodes % busy 0 0 30 2409 numvnodes It was working... Then I entered the following shell command: % (ifconfig em0 polling; sleep 179; ifconfig em0 -polling) & Hoping, that, even if polling causes problems, three minutes later it will turn back off automatically. Unfortunately, the machine dropped off the network immediately and is not coming back. I'll get to its console on Monday, but something is still very wrong with the em-driver :-( -mi From owner-freebsd-net@FreeBSD.ORG Sat Oct 28 13:37:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 38B6116A412 for ; Sat, 28 Oct 2006 13:37:02 +0000 (UTC) (envelope-from quetzal@zone3000.net) Received: from mx1.sitevalley.com (sitevalley.com [209.67.60.43]) by mx1.FreeBSD.org (Postfix) with SMTP id 6871343D55 for ; Sat, 28 Oct 2006 13:36:59 +0000 (GMT) (envelope-from quetzal@zone3000.net) Received: from unknown (HELO localhost) (217.144.69.37) by 209.67.61.254 with SMTP; 28 Oct 2006 13:36:58 -0000 Date: Sat, 28 Oct 2006 16:36:31 +0300 From: Nikolay Pavlov To: Jack Vogel Message-ID: <20061028133631.GA1553@zone3000.net> Mail-Followup-To: Nikolay Pavlov , Jack Vogel , freebsd-stable@freebsd.org, freebsd-net References: <2a41acea0610271844o4759424cv35a018ffc0c23373@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2a41acea0610271844o4759424cv35a018ffc0c23373@mail.gmail.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.1-RELEASE-p10 Cc: freebsd-net , freebsd-stable@freebsd.org Subject: Re: New em driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 13:37:02 -0000 On Friday, 27 October 2006 at 18:44:37 -0700, Jack Vogel wrote: > After a conference call today, it was decided that a merge of > my Intel driver base and the STABLE code would take place. > > This code undoes the INTR_FAST/taskqueue approach for right > now. Work will continue to get that to work, but the hope is that > this driver will be more stable for the 6.2 release. > > I encourage everyone that has been having issues to pull the > new driver and give us feedback. A few select testers so far > have seen stable performance. > > Cheers, > > Jack > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" Hi, Jack. Could you please post here exact revision number of this merge, just for history. -- ====================================================================== - Best regards, Nikolay Pavlov. <<<----------------------------------- ====================================================================== From owner-freebsd-net@FreeBSD.ORG Sat Oct 28 15:21:10 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 0A47716A407; Sat, 28 Oct 2006 15:21:10 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67E1643D75; Sat, 28 Oct 2006 15:21:03 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k9SFKkBc019235; Sat, 28 Oct 2006 09:20:52 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4543754F.2070005@samsco.org> Date: Sat, 28 Oct 2006 09:20:47 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Mikhail Teterin References: <200610211300.09476@aldan> <20061021173358.GC75694@cell.sick.ru> <200610280030.12319@aldan> In-Reply-To: <200610280030.12319@aldan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, jfvogel@gmail.com Subject: Re: new em-driver still broken X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 15:21:10 -0000 Mikhail Teterin wrote: > On Saturday 21 October 2006 13:33, Gleb Smirnoff wrote: > = We aren't currently speaking about performance, we need to know whether > = kernel with DEVICE_POLLING option makes NIC work stable. > > Having noticed today's em-driver update, I rebuilt world/kernel and tried the > dump-test again. > > The kernel had the DEVICE_POLLING option in it, but polling was not, actually, > enabled on em0. > > With three simultanious dumps arriving, the system-component of the load was > 40-50%: > > 2 users Load 2.64 0.98 0.41 28 ??? 00:13 > > Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER > Tot Share Tot Share Free in out in out > Act 109936 30080 196064 42464 1642672 count > All 366172 32684 1413555k 48140 pages > Interrupts > Proc:r p d s w Csw Trp Sys Int Sof Flt cow 6720 total > 3 55 9736 151241k19989 47 232248 wire irq1: atkb > 79108 act irq6: fdc0 > 35.8%Sys 4.5%Intr 59.7%User 0.0%Nice 0.0%Idl 60372 inact irq15: ata > | | | | | | | | | | 276 cache irq17: fwo > ==================++>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1642396 free irq20: nve > daefr irq21: ohc > Namei Name-cache Dir-cache prcfr irq22: ehc > Calls hits % hits % react 2710 irq25: em0 > 229 229 100 pdwak 24 irq29: amr > zfod pdpgs 1993 cpu0: time > Disks ad4 ad6 amrd0 ozfod intrn 1993 cpu1: time > KB/t 0.00 0.00 128 %slo-z 221184 buf > tps 0 0 12 4 tfree 22 dirtybuf > MB/s 0.00 0.00 1.49 100000 desiredvnodes > % busy 0 0 30 2409 numvnodes > > It was working... > > Then I entered the following shell command: > > % (ifconfig em0 polling; sleep 179; ifconfig em0 -polling) & > > Hoping, that, even if polling causes problems, three minutes later it will > turn back off automatically. > > Unfortunately, the machine dropped off the network immediately and is not > coming back. I'll get to its console on Monday, but something is still very > wrong with the em-driver :-( > > -mi So the driver works fine for you so long as you don't try to change the polling parameter while it's running? Scott From owner-freebsd-net@FreeBSD.ORG Sat Oct 28 17:10:29 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 EE89916A47C for ; Sat, 28 Oct 2006 17:10:29 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id C238543D66 for ; Sat, 28 Oct 2006 17:10:27 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by nz-out-0102.google.com with SMTP id o37so789083nzf for ; Sat, 28 Oct 2006 10:10:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Lt8+VzgjCOUqNx/m2DSad6i5TQLfxA0DpyrcrC8roz1NdEsVyYnMFzSch+qCl35jlL2JmRYEIx/wSVhSSvMHY+JJEg/MjvspfAQB40jCvRTMpI1Y/RnTqdFT/RNd2kjFGuJqfaJVZUQ35XXiuRGIv5bDyf499iwOOEoXnzX0Nlk= Received: by 10.35.78.13 with SMTP id f13mr1874448pyl; Sat, 28 Oct 2006 10:10:26 -0700 (PDT) Received: by 10.35.118.6 with HTTP; Sat, 28 Oct 2006 10:10:26 -0700 (PDT) Message-ID: <2a41acea0610281010g5cc5f4e3s8141d26b27e9fee8@mail.gmail.com> Date: Sat, 28 Oct 2006 10:10:26 -0700 From: "Jack Vogel" To: "Nikolay Pavlov" , "Jack Vogel" , freebsd-stable@freebsd.org, freebsd-net In-Reply-To: <20061028133631.GA1553@zone3000.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2a41acea0610271844o4759424cv35a018ffc0c23373@mail.gmail.com> <20061028133631.GA1553@zone3000.net> Cc: Subject: Re: New em driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Oct 2006 17:10:30 -0000 On 10/28/06, Nikolay Pavlov wrote: > On Friday, 27 October 2006 at 18:44:37 -0700, Jack Vogel wrote: > > After a conference call today, it was decided that a merge of > > my Intel driver base and the STABLE code would take place. > > > > This code undoes the INTR_FAST/taskqueue approach for right > > now. Work will continue to get that to work, but the hope is that > > this driver will be more stable for the 6.2 release. > > > > I encourage everyone that has been having issues to pull the > > new driver and give us feedback. A few select testers so far > > have seen stable performance. > > > > Cheers, > > > > Jack > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > Hi, Jack. > Could you please post here exact revision number of this merge, just for > history. Sure thing: Log: Merge of Intel 6.2.9 em driver code. Approved by: re, scottl, jhb, pdeuskar Revision Changes Path 1.65.2.19 +731 -589 src/sys/dev/em/if_em.c 1.32.2.5 +97 -71 src/sys/dev/em/if_em.h 1.16.2.4 +574 -531 src/sys/dev/em/if_em_hw.c 1.15.2.5 +96 -148 src/sys/dev/em/if_em_hw.h 1.14.2.3 +46 -52 src/sys/dev/em/if_em_osdep.h