From owner-freebsd-net@FreeBSD.ORG Sun Nov 30 01:02:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DDE3E106564A for ; Sun, 30 Nov 2008 01:02:25 +0000 (UTC) (envelope-from dave.edwards@adelaide.on.net) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by mx1.freebsd.org (Postfix) with ESMTP id 6ED0A8FC0A for ; Sun, 30 Nov 2008 01:02:24 +0000 (UTC) (envelope-from dave.edwards@adelaide.on.net) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAF90MUnLeumf/2dsb2JhbACBbcwdgn0 X-IronPort-AV: E=Sophos;i="4.33,688,1220193000"; d="scan'208";a="240581299" Received: from eth16288.sa.adsl.internode.on.net (HELO chunga.apana.org.au) ([203.122.233.159]) by ipmail01.adl6.internode.on.net with ESMTP; 30 Nov 2008 11:32:23 +1030 Received: from [10.0.0.58] (tonto.leabrook [10.0.0.58]) by chunga.apana.org.au (8.14.2/8.12.11) with ESMTP id mAU12ME5044296 for ; Sun, 30 Nov 2008 11:32:22 +1030 (CST) Message-ID: <4931E629.8070503@adelaide.on.net> Date: Sun, 30 Nov 2008 11:32:33 +1030 From: Dave Edwards User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <492E8B52.9010408@adelaide.on.net> <4CREIW43kKwxaB43gZShXkxNn3U@2DcjJpvUBcA8GzIZe2t/Ulo9G+Y> In-Reply-To: <4CREIW43kKwxaB43gZShXkxNn3U@2DcjJpvUBcA8GzIZe2t/Ulo9G+Y> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (chunga.apana.org.au [10.0.0.1]); Sun, 30 Nov 2008 11:32:22 +1030 (CST) Subject: Re: nmap on FreeBSD 7.0-RELEASE 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, 30 Nov 2008 01:02:25 -0000 Eygene Ryabinkin wrote: > Dave, good day. > > Thu, Nov 27, 2008 at 10:28:10PM +1030, Dave Edwards wrote: > >> I've tried creating a host route for the nmap target instead of relying >> on the default route and I've tried three other versions of nmap. As an >> aside (or maybe a hint) when compiling nmap from source, there are a >> number of warnings like: > > Could you, please, post the accompanying config.log that was produced > by configure and the configure script itself? > Sorry, my reply contained attachments and went into the bit bucket. The config.log and configure script are at: http://chunga.apana.org.au/stuff/nmap-configure-stuff.tgz if anyone is interested. My main problem is that I can't use nmap (with options that require raw sockets) over a tun device. Any help would be appreciated. ciao dave From owner-freebsd-net@FreeBSD.ORG Sun Nov 30 03:44:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 465871065676 for ; Sun, 30 Nov 2008 03:44:25 +0000 (UTC) (envelope-from andrewwtulloch@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id CB20C8FC13 for ; Sun, 30 Nov 2008 03:44:24 +0000 (UTC) (envelope-from andrewwtulloch@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so803590eyi.7 for ; Sat, 29 Nov 2008 19:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:mime-version:content-type:content-transfer-encoding :content-disposition:x-google-sender-auth; bh=nhB9bK+9D35SXIJu1t9rBFhcWti46LOSSg7kFp40wbE=; b=j8iF++Zt8shP3oGseo79eg7F8UO8UTN/aiaZtfEdJBsgCE5sV7zfb10Z2F9TnyP61U OiZR4LMCgZr8mW3OvBDrP67J4uaUaJZhhWFSn580MRcHxKHnI1xFfo1zM9MsTCs/NCse 3CUebxNYCwnmicQF2Nv8H0g2WBSMBal99Y1Ps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition:x-google-sender-auth; b=W4aWYeRB54OXC+3pQ98f1310OnOYugDI6rmelWPDOq38IgxKb2dSVJ63kxKU2fnm1O XQqFApjCdMvUxne3Z0JIB0TCQ18Wc12vPowgRHnxarzJximRkSGsExDYygbZHEZYYPr8 BuNq/TKo09/Wvs6g5SoXwyvz54rXjc/i6AOwE= Received: by 10.210.142.10 with SMTP id p10mr5604433ebd.95.1228015121457; Sat, 29 Nov 2008 19:18:41 -0800 (PST) Received: by 10.210.48.20 with HTTP; Sat, 29 Nov 2008 19:18:41 -0800 (PST) Message-ID: <54854a7a0811291918s7affc753k998607f2529e7c2e@mail.gmail.com> Date: Sun, 30 Nov 2008 03:18:41 +0000 From: "Andrew Tulloch" Sender: andrewwtulloch@gmail.com To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 153a91956bf9a8cc Subject: re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6 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, 30 Nov 2008 03:44:25 -0000 I've just installed from the FreeBSD 7.1-BETA1 iso and get the following when the re driver attempts to attach to the two onboard NICs found on a Gigabyte GA-EX58-UD5 motherboard: re0: port 0x9e00-0x9eff mem 0xfd3ff000-0xfd3fffff,0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on pci8 re0: Chip rev. 0x28000000 re0: MAC rev. 0x00100000 re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6 pcib9: irq 17 at device 28.5 on pci0 pci9: on pcib9 re1: port 0x8e00-0x8eff mem 0xfd1ff000-0xfd1fffff,0xfd1f8000-0xfd1fbfff irq 17 at device 0.0 on pci9 re1: Chip rev. 0x28000000 re1: MAC rev. 0x00100000 re1: Unknown H/W revision: 0x28000000 device_attach: re1 attach returned 6 pciconf -lvc extract: re0@pci0:8:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint IRQ 0 cap 11[ac] = MSI-X supports 4 messages in map 0x20 cap 03[cc] = VPD re1@pci0:9:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 vendor = 'Realtek Semiconductor' device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit cap 10[70] = PCI-Express 2 endpoint IRQ 0 cap 11[ac] = MSI-X supports 4 messages in map 0x20 cap 03[cc] = VPD Is there any simple patch I can apply to get the driver to attach, assuming it should work? Thanks, Andrew From owner-freebsd-net@FreeBSD.ORG Sun Nov 30 04:32:36 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 111E9106564A for ; Sun, 30 Nov 2008 04:32:36 +0000 (UTC) (envelope-from prvs=julian=2131aa4c9@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 011BB8FC14 for ; Sun, 30 Nov 2008 04:32:35 +0000 (UTC) (envelope-from prvs=julian=2131aa4c9@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.239]) by smtp-outbound.ironport.com with ESMTP; 29 Nov 2008 20:20:31 -0800 Message-ID: <49321494.90706@elischer.org> Date: Sat, 29 Nov 2008 20:20:36 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Mykel References: <4931A5B6.1060000@mWare.ca> In-Reply-To: <4931A5B6.1060000@mWare.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Determining counts or size of routing table? (netstat performance?) 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, 30 Nov 2008 04:32:36 -0000 Mykel wrote: > Got a few 6.x machines running OpenBGPd with a few BGP full-feeds and a > handful of peers... I'd like to determine the size of the FIB/kernel > routing table. OpenBGPd does not give me this data, and on my > duallie-Xeon 2.8s, it takes quite a while to use netstat & wc to count. > > I'm not looking for exact numbers, just something I can poll via NetSNMP > and plot in cacti... > > I looked though netstat, route, sysctl, vmstat, even pored over an > snmpwalk... can't find anything. > Been asking around, and the only suggestion I've received was to write a > daemon that dumps the table and then monitors the changes, but I'm not a > programmer, nor could I find any tool in ports that might assist in this. > > I'd be happy with almost any metric that gives me some absolute > reference as to how big my routing table is so I can get some nice > pretty graphs done up. Not pounding the system every 60-300 seconds > would be very nice. > > Any suggestions? Or does everyone just pipe netstat? Is there a MIB for > sysctl or NetSNMP I'm missing? > no. It's a hard thing to do so that is why it hasn't been done yet. From owner-freebsd-net@FreeBSD.ORG Sun Nov 30 05:04:35 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D59B5106564A for ; Sun, 30 Nov 2008 05:04:35 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id B139D8FC12 for ; Sun, 30 Nov 2008 05:04:35 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id mAU54Y7j090900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Nov 2008 21:04:34 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <49321EE2.6020001@freebsd.org> Date: Sat, 29 Nov 2008 21:04:34 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Julian Elischer References: <4931A5B6.1060000@mWare.ca> <49321494.90706@elischer.org> In-Reply-To: <49321494.90706@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: Mykel , freebsd-net@freebsd.org Subject: Re: Determining counts or size of routing table? (netstat performance?) 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, 30 Nov 2008 05:04:35 -0000 Julian Elischer wrote: > Mykel wrote: >> Got a few 6.x machines running OpenBGPd with a few BGP full-feeds and a >> handful of peers... I'd like to determine the size of the FIB/kernel >> routing table. OpenBGPd does not give me this data, and on my >> duallie-Xeon 2.8s, it takes quite a while to use netstat & wc to count. >> >> I'm not looking for exact numbers, just something I can poll via NetSNMP >> and plot in cacti... >> >> I looked though netstat, route, sysctl, vmstat, even pored over an >> snmpwalk... can't find anything. >> Been asking around, and the only suggestion I've received was to write a >> daemon that dumps the table and then monitors the changes, but I'm not a >> programmer, nor could I find any tool in ports that might assist in >> this. >> >> I'd be happy with almost any metric that gives me some absolute >> reference as to how big my routing table is so I can get some nice >> pretty graphs done up. Not pounding the system every 60-300 seconds >> would be very nice. >> >> Any suggestions? Or does everyone just pipe netstat? Is there a MIB for >> sysctl or NetSNMP I'm missing? >> > > no. It's a hard thing to do so that is why it hasn't been done yet. Perhaps I misunderstand his question but trouble% vmstat -m |grep routetbl routetbl 14 2K - 33875 16,32,64,128,256 should show memory allocated to the routing table. Sam From owner-freebsd-net@FreeBSD.ORG Sun Nov 30 05:09:14 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DE461065673 for ; Sun, 30 Nov 2008 05:09:14 +0000 (UTC) (envelope-from Mykel@mWare.ca) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.freebsd.org (Postfix) with ESMTP id 0BBA08FC16 for ; Sun, 30 Nov 2008 05:09:13 +0000 (UTC) (envelope-from Mykel@mWare.ca) Received: from fulgidous.condor.lan (radix.mWare.ca [72.0.75.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ox.eicat.ca (Postfix) with ESMTP id F191EBF86 for ; Sun, 30 Nov 2008 00:09:12 -0500 (EST) Message-ID: <49321FF8.6000805@mWare.ca> Date: Sun, 30 Nov 2008 00:09:12 -0500 From: Mykel User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4931A5B6.1060000@mWare.ca> <49321494.90706@elischer.org> <49321EE2.6020001@freebsd.org> In-Reply-To: <49321EE2.6020001@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Determining counts or size of routing table? (netstat performance?) 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, 30 Nov 2008 05:09:14 -0000 Sam Leffler wrote: > Julian Elischer wrote: >> Mykel wrote: >>> Got a few 6.x machines running OpenBGPd with a few BGP full-feeds and a >>> handful of peers... I'd like to determine the size of the FIB/kernel >>> routing table. OpenBGPd does not give me this data, and on my >>> duallie-Xeon 2.8s, it takes quite a while to use netstat & wc to count. >>> >>> I'm not looking for exact numbers, just something I can poll via >>> NetSNMP >>> and plot in cacti... >>> >>> I looked though netstat, route, sysctl, vmstat, even pored over an >>> snmpwalk... can't find anything. >>> Been asking around, and the only suggestion I've received was to >>> write a >>> daemon that dumps the table and then monitors the changes, but I'm >>> not a >>> programmer, nor could I find any tool in ports that might assist in >>> this. >>> >>> I'd be happy with almost any metric that gives me some absolute >>> reference as to how big my routing table is so I can get some nice >>> pretty graphs done up. Not pounding the system every 60-300 seconds >>> would be very nice. >>> >>> Any suggestions? Or does everyone just pipe netstat? Is there a MIB for >>> sysctl or NetSNMP I'm missing? >>> >> >> no. It's a hard thing to do so that is why it hasn't been done yet. > Perhaps I misunderstand his question but > > trouble% vmstat -m |grep routetbl > routetbl 14 2K - 33875 16,32,64,128,256 > > should show memory allocated to the routing table. I was also shown (privately) this: # vmstat -z | grep "rtentry" rtentry: 120, 0, 198, 474, 12190, 0 Either works for me, so I'm now happy. Thanks! Myke From owner-freebsd-net@FreeBSD.ORG Sun Nov 30 05:18:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D79B1065670 for ; Sun, 30 Nov 2008 05:18:29 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id EA7358FC18 for ; Sun, 30 Nov 2008 05:18:28 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id mAU5IS1A090955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Nov 2008 21:18:28 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <49322224.8010806@freebsd.org> Date: Sat, 29 Nov 2008 21:18:28 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.9 (X11/20071125) MIME-Version: 1.0 To: Mykel References: <4931A5B6.1060000@mWare.ca> <49321494.90706@elischer.org> <49321EE2.6020001@freebsd.org> <49321FF8.6000805@mWare.ca> In-Reply-To: <49321FF8.6000805@mWare.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC--Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org Subject: Re: Determining counts or size of routing table? (netstat performance?) 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, 30 Nov 2008 05:18:29 -0000 Mykel wrote: > Sam Leffler wrote: > >> Julian Elischer wrote: >> >>> Mykel wrote: >>> >>>> Got a few 6.x machines running OpenBGPd with a few BGP full-feeds and a >>>> handful of peers... I'd like to determine the size of the FIB/kernel >>>> routing table. OpenBGPd does not give me this data, and on my >>>> duallie-Xeon 2.8s, it takes quite a while to use netstat & wc to count. >>>> >>>> I'm not looking for exact numbers, just something I can poll via >>>> NetSNMP >>>> and plot in cacti... >>>> >>>> I looked though netstat, route, sysctl, vmstat, even pored over an >>>> snmpwalk... can't find anything. >>>> Been asking around, and the only suggestion I've received was to >>>> write a >>>> daemon that dumps the table and then monitors the changes, but I'm >>>> not a >>>> programmer, nor could I find any tool in ports that might assist in >>>> this. >>>> >>>> I'd be happy with almost any metric that gives me some absolute >>>> reference as to how big my routing table is so I can get some nice >>>> pretty graphs done up. Not pounding the system every 60-300 seconds >>>> would be very nice. >>>> >>>> Any suggestions? Or does everyone just pipe netstat? Is there a MIB for >>>> sysctl or NetSNMP I'm missing? >>>> >>>> >>> no. It's a hard thing to do so that is why it hasn't been done yet. >>> >> Perhaps I misunderstand his question but >> >> trouble% vmstat -m |grep routetbl >> routetbl 14 2K - 33875 16,32,64,128,256 >> >> should show memory allocated to the routing table. >> > I was also shown (privately) this: > > # vmstat -z | grep "rtentry" > rtentry: 120, 0, 198, 474, > 12190, 0 > > Either works for me, so I'm now happy. Thanks! > Yes, was looking for that but stopped when I found malloc's for the radix tree :-) Sam From owner-freebsd-net@FreeBSD.ORG Sun Nov 30 05:25:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6ECE71065673 for ; Sun, 30 Nov 2008 05:25:03 +0000 (UTC) (envelope-from prvs=julian=2131aa4c9@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 61D748FC12 for ; Sun, 30 Nov 2008 05:25:03 +0000 (UTC) (envelope-from prvs=julian=2131aa4c9@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.239]) by smtp-outbound.ironport.com with ESMTP; 29 Nov 2008 21:25:03 -0800 Message-ID: <493223B5.7080502@elischer.org> Date: Sat, 29 Nov 2008 21:25:09 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Mykel References: <4931A5B6.1060000@mWare.ca> <49321494.90706@elischer.org> <49321EE2.6020001@freebsd.org> <49321FF8.6000805@mWare.ca> In-Reply-To: <49321FF8.6000805@mWare.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Determining counts or size of routing table? (netstat performance?) 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, 30 Nov 2008 05:25:03 -0000 Mykel wrote: > Sam Leffler wrote: >> Julian Elischer wrote: >>> Mykel wrote: >>>> Got a few 6.x machines running OpenBGPd with a few BGP full-feeds and a >>>> handful of peers... I'd like to determine the size of the FIB/kernel >>>> routing table. OpenBGPd does not give me this data, and on my >>>> duallie-Xeon 2.8s, it takes quite a while to use netstat & wc to count. >>>> >>>> I'm not looking for exact numbers, just something I can poll via >>>> NetSNMP >>>> and plot in cacti... >>>> >>>> I looked though netstat, route, sysctl, vmstat, even pored over an >>>> snmpwalk... can't find anything. >>>> Been asking around, and the only suggestion I've received was to >>>> write a >>>> daemon that dumps the table and then monitors the changes, but I'm >>>> not a >>>> programmer, nor could I find any tool in ports that might assist in >>>> this. >>>> >>>> I'd be happy with almost any metric that gives me some absolute >>>> reference as to how big my routing table is so I can get some nice >>>> pretty graphs done up. Not pounding the system every 60-300 seconds >>>> would be very nice. >>>> >>>> Any suggestions? Or does everyone just pipe netstat? Is there a MIB for >>>> sysctl or NetSNMP I'm missing? >>>> >>> no. It's a hard thing to do so that is why it hasn't been done yet. >> Perhaps I misunderstand his question but >> >> trouble% vmstat -m |grep routetbl >> routetbl 14 2K - 33875 16,32,64,128,256 >> >> should show memory allocated to the routing table. > I was also shown (privately) this: > > # vmstat -z | grep "rtentry" > rtentry: 120, 0, 198, 474, > 12190, 0 > > Either works for me, so I'm now happy. Thanks! neither of these gives an exactly accurate answer, In hte case of dangling routes, for example, routes can be outside the table and still not freed. (their reference counts have not gone to 0 as a socket still holds a reference for example). it is however a good upper bound I guess > > Myke > > _______________________________________________ > 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 Nov 30 12:32:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 64EF81065670 for ; Sun, 30 Nov 2008 12:32:00 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-gx0-f19.google.com (mail-gx0-f19.google.com [209.85.217.19]) by mx1.freebsd.org (Postfix) with ESMTP id 1CE548FC12 for ; Sun, 30 Nov 2008 12:31:59 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: by gxk12 with SMTP id 12so853698gxk.19 for ; Sun, 30 Nov 2008 04:31:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=byUjo2tQadga0qjGLDUARuUOiYEvhkIK2G60Ykqm5qM=; b=G2MZs1hpUf8KAqXnS8dqVXwiu7zGmjBmrSE9xVqR2B32PGYJajDhDFScgN4RxosQNA 7emRcLoJLlM9ZvzbyY5TeSsB/YqyyiqzLB0WMq79Zd1ZfoIBWGK0vSQuNNoI+W/AqM06 PdfcL6G31Um8yNhazPxEPCRwYNZ6AKekT3m/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=JUHsKbyP5d6EuKY1KMH+zr0vMbubdGEE9exmEDt06KLFqvOFv+TMLtMFBAQRRR4rP3 KcfnlIgtitRcqXXqknodPMxPbsn58/00EsHDBKAUBeLlpDgrEjkcbqagSu2bXXx8jr9Y gUf0HJEngfbvZFln89WUUqch6/om3at1STHKo= Received: by 10.150.219.16 with SMTP id r16mr3495269ybg.82.1228047042739; Sun, 30 Nov 2008 04:10:42 -0800 (PST) Received: by 10.151.131.2 with HTTP; Sun, 30 Nov 2008 04:10:42 -0800 (PST) Message-ID: Date: Sun, 30 Nov 2008 20:10:42 +0800 From: "Sepherosa Ziehau" To: "freebsd-net@freebsd.org" In-Reply-To: <54854a7a0811291918s7affc753k998607f2529e7c2e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <54854a7a0811291918s7affc753k998607f2529e7c2e@mail.gmail.com> Subject: Re: re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6 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, 30 Nov 2008 12:32:00 -0000 On Sun, Nov 30, 2008 at 11:18 AM, Andrew Tulloch wrote: > I've just installed from the FreeBSD 7.1-BETA1 iso and get the > following when the re driver attempts to attach to the two onboard > NICs found on a Gigabyte GA-EX58-UD5 motherboard: > > re0: Ethernet> port 0x9e00-0x9eff mem > 0xfd3ff000-0xfd3fffff,0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on > pci8 > re0: Chip rev. 0x28000000 It's 8168D, driver configuration should be same as 8168CP Best Regards, sephe -- Live Free or Die From owner-freebsd-net@FreeBSD.ORG Sun Nov 30 14:39:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3A5E1065675 for ; Sun, 30 Nov 2008 14:39:08 +0000 (UTC) (envelope-from mamruoc@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5BF628FC16 for ; Sun, 30 Nov 2008 14:39:08 +0000 (UTC) (envelope-from mamruoc@gmail.com) Received: by ey-out-2122.google.com with SMTP id 6so842137eyi.7 for ; Sun, 30 Nov 2008 06:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Z8M/jJMkdIgcSfKdxm61SwfwEAAzKkr1HOqj0o1c1rQ=; b=YxqfY9j/4cRTVm//EJ1hh99gV/sAiVmnLQgq+ctNEQyQSJKVUDq4oUpTzKkVmYC+f7 Caxp81E7CsA5TBwxERgWdDmASoNPZSRkT8qMZYRLaNXNQljmUvY1EsDeJnUOmXN2dgn9 P3pO9R10WUwD86nY63QH5RzsP8soWcJED4uHQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NvH/Rb+oqWA4GkgrsS364mi/JHajrpWgC9knrh6k0B4Z6yQK8qchK5VRyZSHHyRWKw kU0vVZwE8/dsND6wnkKxbIvyNCXjocXnlcQmJK1CxLrkikf1ns2+8JoM4nM4FyEMRg5w yDa2BGidbH19XQeRTV6XvF8vZWqNLGW68rs3w= Received: by 10.210.61.19 with SMTP id j19mr3032613eba.145.1228055947166; Sun, 30 Nov 2008 06:39:07 -0800 (PST) Received: from ?192.168.1.136? (217-14-12-152-dhcp-osl.bbse.no [217.14.12.152]) by mx.google.com with ESMTPS id f6sm15689149nfh.12.2008.11.30.06.39.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 30 Nov 2008 06:39:06 -0800 (PST) Message-ID: <4932A587.9010903@gmail.com> Date: Sun, 30 Nov 2008 15:39:03 +0100 From: Mam Ruoc User-Agent: Thunderbird 2.0.0.17 (X11/20080925) MIME-Version: 1.0 To: pyunyh@gmail.com References: <4d591a210811281220o7bdd420uafec124fc7e770a8@mail.gmail.com> <20081129065950.GG99324@cdnetworks.co.kr> <49314D3C.4050108@gmail.com> In-Reply-To: <49314D3C.4050108@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: vge driver does not work on a VIA EPIA EN12000EG 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, 30 Nov 2008 14:39:08 -0000 I tried the bootonly from: ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/7.1 That didnt make any difference, any idea, anybody? Mam Mam Ruoc wrote: > Pyun YongHyeon wrote: >> I think there was a similar report. Would you show me the output of >> "pciconf -lcv"? > > I'll try, unsure how to manage. > Have tried to use Fixit in sysinstall to create a new shell, but > Ghost-something did not have lspci, where can I find freebsd livecd? > >> For a long time I wanted to clean up vge(4). Unfortunately the PCI >> NIC I have seem to broken so I guess it's hard to complete the >> cleanup. You can get a WIP(now stalled) in the following URL. Note, >> the driver may be chatty due to various debugging statements and it >> may not work at all for your controller. >> >> http://people.freebsd.org/~yongari/vge/if_vge.c >> http://people.freebsd.org/~yongari/vge/if_vgereg.h >> http://people.freebsd.org/~yongari/vge/if_vgevar.h > > As I said in the other mail, unsure how to do this because I actually > ned the fix because pfSense 1.2.1RC2 have this problem and made my VIA > useless as a firewall. > > Mam From owner-freebsd-net@FreeBSD.ORG Sun Nov 30 23:11:21 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C32F1065675 for ; Sun, 30 Nov 2008 23:11:21 +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 1E2B68FC22 for ; Sun, 30 Nov 2008 23:11:20 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 56766 invoked from network); 30 Nov 2008 21:34:25 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Nov 2008 21:34:25 -0000 Message-ID: <49331DA0.3070804@freebsd.org> Date: Mon, 01 Dec 2008 00:11:28 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: David Malone References: <200811291746.aa88825@walton.maths.tcd.ie> In-Reply-To: <200811291746.aa88825@walton.maths.tcd.ie> Content-Type: multipart/mixed; boundary="------------090402010905090904010200" Cc: Rui Paulo , freebsd-net@freebsd.org, Kevin Oberman , Venkat Venkatsubra Subject: Re: FreeBSD Window updates 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, 30 Nov 2008 23:11:21 -0000 This is a multi-part message in MIME format. --------------090402010905090904010200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit David Malone wrote: > I've got an example extract tcpdump of this at the end of the mail > - here 6 ACKs are sent, 5 of which are pure window updates and > several are 2us apart! > > I think the easy option is to delete the code that generates explicit > window updates if the window moves by 2*MSS. We then should be doing > something similar to Linux. The other easy alternative would be to > add a sysclt that lets us generate an window update every N*MSS and > by default set it to something big, like 10 or 100. That should > effectively eliminate the updates during bulk data transfer, but > may still generate some window updates after a loss. The main problem of the pure window update test in tcp_output() is its complete ignorance of delayed ACKs. Second is the strict 4.4BSD adherence to sending an update for every window increase of >= 2*MSS. The third issue of sending a slew of window updates after having received a FIN (telling us the other end won't ever send more data) I have already fixed some moons ago. In my new-tcp work I've come across the window update logic some time ago and backchecked with relevant RFCs and other implementations. Attached is a compiling but otherwise untested backport of the new logic. -- Andre > Normal ACKing for driving congestion control shouldn't be impacted > by either of these suggested changes. > > David. > > 1227622713.276609 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40798 (DF) > 1227622713.276611 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40830 (DF) > 1227622713.276613 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40862 (DF) > 1227622713.276615 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40894 (DF) > 1227622713.276852 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40926 (DF) > 1227622713.276855 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144097745 win 40958 (DF) > 1227622713.296585 172.16.2.2.5002 > 172.16.1.51.39077: . ack 144100641 win 40956 (DF) --------------090402010905090904010200 Content-Type: text/plain; name="tcp_wu_fix-20081130.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcp_wu_fix-20081130.diff" Index: tcp_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v retrieving revision 1.158 diff -u -p -r1.158 tcp_output.c --- tcp_output.c 27 Nov 2008 13:19:42 -0000 1.158 +++ tcp_output.c 30 Nov 2008 22:58:46 -0000 @@ -539,14 +539,32 @@ after_sack_rexmit: } /* - * Compare available window to amount of window - * known to peer (as advertised window less - * next expected input). If the difference is at least two - * max size segments, or at least 50% of the maximum possible - * window, then want to send a window update to peer. + * Compare available window to amount of window known to peer + * (as advertised window less next expected input) and decide + * if we have to send a pure window update segment. + * + * When a delayed ACK is scheduled, do nothing. It will update + * the window anyway in a few milliseconds. + * + * If the receive socket buffer has less than 1/4 of space + * available and if the difference is at least two max size + * segments, send an immediate window update to peer. + * + * Otherwise if the difference is 1/8 (or more) of the receive + * socket buffer, or at least 1/2 of the maximum possible window, + * then we send a window update too. + * * Skip this if the connection is in T/TCP half-open state. * Don't send pure window updates when the peer has closed * the connection and won't ever send more data. + * + * See RFC793, Section 3.7, page 43, Window Management Suggestions + * See RFC1122: Section 4.2.3.3, When to Send a Window Update + * + * Note: We are less aggressive with sending window update than + * recommended in RFC1122. This is fine with todays large socket + * buffers and will not stall the peer. In addition we piggy back + * window update on regular ACKs and sends. */ if (recwin > 0 && !(tp->t_flags & TF_NEEDSYN) && !TCPS_HAVERCVDFIN(tp->t_state)) { @@ -554,14 +572,24 @@ after_sack_rexmit: * "adv" is the amount we can increase the window, * taking into account that we are limited by * TCP_MAXWIN << tp->rcv_scale. + * + * NB: adv must be equal or larger than the smallest + * unscaled window increment. */ long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) - (tp->rcv_adv - tp->rcv_nxt); - if (adv >= (long) (2 * tp->t_maxseg)) - goto send; - if (2 * adv >= (long) so->so_rcv.sb_hiwat) - goto send; + if (!(tp->t_flags & TF_DELACK) && + adv >= (long)0x1 << tp->rcv_scale) { + if (recwin <= (long)(so->so_rcv.sb_hiwat / 4) && + adv >= (long)(2 * tp->t_maxseg)) + goto send; + if (adv >= (long)(so->so_rcv.sb_hiwat / 8) && + adv >= (long)tp->t_maxseg) + goto send; + if (2 * adv >= (long)so->so_rcv.sb_hiwat) + goto send; + } } /* --------------090402010905090904010200-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 30 23:18:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F27431065672 for ; Sun, 30 Nov 2008 23:18:15 +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 5BDE68FC17 for ; Sun, 30 Nov 2008 23:18:15 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 56978 invoked from network); 30 Nov 2008 21:41:19 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Nov 2008 21:41:19 -0000 Message-ID: <49331F3E.2090305@freebsd.org> Date: Mon, 01 Dec 2008 00:18:22 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: David Malone References: <200811291746.aa88825@walton.maths.tcd.ie> <49331DA0.3070804@freebsd.org> In-Reply-To: <49331DA0.3070804@freebsd.org> Content-Type: multipart/mixed; boundary="------------080401030900080409080005" Cc: Rui Paulo , freebsd-net@freebsd.org, Venkat Venkatsubra , Kevin Oberman Subject: Re: FreeBSD Window updates 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, 30 Nov 2008 23:18:16 -0000 This is a multi-part message in MIME format. --------------080401030900080409080005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Andre Oppermann wrote: > David Malone wrote: >> I've got an example extract tcpdump of this at the end of the mail >> - here 6 ACKs are sent, 5 of which are pure window updates and >> several are 2us apart! >> >> I think the easy option is to delete the code that generates explicit >> window updates if the window moves by 2*MSS. We then should be doing >> something similar to Linux. The other easy alternative would be to >> add a sysclt that lets us generate an window update every N*MSS and >> by default set it to something big, like 10 or 100. That should >> effectively eliminate the updates during bulk data transfer, but >> may still generate some window updates after a loss. > > The main problem of the pure window update test in tcp_output() is > its complete ignorance of delayed ACKs. Second is the strict 4.4BSD > adherence to sending an update for every window increase of >= 2*MSS. > The third issue of sending a slew of window updates after having > received a FIN (telling us the other end won't ever send more data) > I have already fixed some moons ago. > > In my new-tcp work I've come across the window update logic some time > ago and backchecked with relevant RFCs and other implementations. > Attached is a compiling but otherwise untested backport of the new logic. Slightly improved version attached. -- Andre --------------080401030900080409080005 Content-Type: text/plain; name="tcp_wu_fix-20081201.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcp_wu_fix-20081201.diff" Index: tcp_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v retrieving revision 1.158 diff -u -p -r1.158 tcp_output.c --- tcp_output.c 27 Nov 2008 13:19:42 -0000 1.158 +++ tcp_output.c 30 Nov 2008 23:16:30 -0000 @@ -539,29 +539,56 @@ after_sack_rexmit: } /* - * Compare available window to amount of window - * known to peer (as advertised window less - * next expected input). If the difference is at least two - * max size segments, or at least 50% of the maximum possible - * window, then want to send a window update to peer. + * Compare available window to amount of window known to peer + * (as advertised window less next expected input) and decide + * if we have to send a pure window update segment. + * + * When a delayed ACK is scheduled, do nothing. It will update + * the window anyway in a few milliseconds. + * + * If the receive socket buffer has less than 1/4 of space + * available and if the difference is at least two max size + * segments, send an immediate window update to peer. + * + * Otherwise if the difference is 1/8 (or more) of the receive + * socket buffer, or at least 1/2 of the maximum possible window, + * then we send a window update too. + * * Skip this if the connection is in T/TCP half-open state. * Don't send pure window updates when the peer has closed * the connection and won't ever send more data. + * + * See RFC793, Section 3.7, page 43, Window Management Suggestions + * See RFC1122: Section 4.2.3.3, When to Send a Window Update + * + * Note: We are less aggressive with sending window update than + * recommended in RFC1122. This is fine with todays large socket + * buffers and will not stall the peer. In addition we piggy back + * window update on regular ACKs and sends. */ - if (recwin > 0 && !(tp->t_flags & TF_NEEDSYN) && - !TCPS_HAVERCVDFIN(tp->t_state)) { + if (recwin > 0 && !(tp->t_flags & TF_DELACK) && + !(tp->t_flags & TF_NEEDSYN) && !TCPS_HAVERCVDFIN(tp->t_state)) { /* * "adv" is the amount we can increase the window, * taking into account that we are limited by * TCP_MAXWIN << tp->rcv_scale. + * + * NB: adv must be equal or larger than the smallest + * unscaled window increment. */ long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) - (tp->rcv_adv - tp->rcv_nxt); - if (adv >= (long) (2 * tp->t_maxseg)) - goto send; - if (2 * adv >= (long) so->so_rcv.sb_hiwat) - goto send; + if (adv >= (long)0x1 << tp->rcv_scale) { + if (recwin <= (long)(so->so_rcv.sb_hiwat / 4) && + adv >= (long)(2 * tp->t_maxseg)) + goto send; + if (adv >= (long)(so->so_rcv.sb_hiwat / 8) && + adv >= (long)tp->t_maxseg) + goto send; + if (2 * adv >= (long)so->so_rcv.sb_hiwat) + goto send; + } } /* --------------080401030900080409080005-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 02:02:05 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7449D1065673; Mon, 1 Dec 2008 02:02:05 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from [127.0.0.1] (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BE4598FC30; Mon, 1 Dec 2008 02:02:03 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <4933459A.5090806@FreeBSD.org> Date: Sun, 30 Nov 2008 18:02:02 -0800 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: net@freebsd.org, FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: panic from ifconfig in IFAREF 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, 01 Dec 2008 02:02:05 -0000 I got this panic on HEAD when trying to configure an IP address on an interface immediately after boot: > Fatal trap 9: general protection fault while in kernel mode > ccpuid = 4; xapic id = 04 > ginstruction pointer = 0x8:0xffffffff80494b42 > bstack pointer = 0x10:0xffffffff20938490 > 0frame pointe:r = 0x10:0xffffffff20938610 > code segment = base 0x0, limit 0xfffff, type 0x1b > link state changed to DOWN > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1073 (ifconfig) > [thread pid 1073 tid 100250 ] > Stopped at strlen+0x2: cmpb $0,(%rdi) > db> wh > Tracing pid 1073 tid 100250 td 0xffffff00077ab720 > strlen() at strlen+0x2 > vsnprintf() at vsnprintf+0x2e > panic() at panic+0x1d8 > _mtx_lock_flags() at _mtx_lock_flags+0xd9 > rtrequest1_fib() at rtrequest1_fib+0x3e6 > rtinit() at rtinit+0x213 > in_ifinit() at in_ifinit+0x2bd > in_control() at in_control+0xe95 > ifioctl() at ifioctl+0xfa > kern_ioctl() at kern_ioctl+0x92 > ioctl() at ioctl+0xfd > syscall() at syscall+0x1bc > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (54, FreeBSD ELF64, ioctl), rip = 0x140a69dfc, rsp = 0x7fffffffe588, rbp = 0x7fffffffef7c --- > __func__.6541+0xfcb: mtx_lock() of spin mutex %s @ %s:%d The panic is here: /* * Note that we now have a reference to the ifa. * This moved from below so that rnh->rnh_addaddr() can * examine the ifa and ifa->ifa_ifp if it so desires. */ IFAREF(ifa); (net/route.c:1081) Kris From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 04:32:33 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 437731065672 for ; Mon, 1 Dec 2008 04:32:33 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.230]) by mx1.freebsd.org (Postfix) with ESMTP id 0BB648FC08 for ; Mon, 1 Dec 2008 04:32:32 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so2245736rvf.43 for ; Sun, 30 Nov 2008 20:32:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=ligKtHQons300GX/vS76xRMlvUhcLYWjOWiU/4CL/2c=; b=QjmfxEVE/clir819ZJZuvOZoOyv3hDK5Nr2TzcQYDmf9yej/O1TtCV7R9R7MjQvNgX hiHVPQPdlSNAUAQOtfhHKpMV4GC2WXsok+iu2NQniGrcCrqiUImLIBm6llGU0xx7MnPw Psgkt+fl0VxTtVspiAr7/+ri9qnO8oli2ZRdQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=D1l3FF6cTXQoB8AOyDftHmeQ0LfcsW2ClrXXQymf3DVTt0awuQTKrUSTS0Gt7BXf9P WNYN3gsimFLwB8USujZDkwqDm15npzT9QjdHSk6ubcwJzM+7uaFXRNSZO+IbUO7ia3yo bTmKLzhUxJVyxZf3Pt2vt7Z2tA7N/RA+pIr20= Received: by 10.110.47.9 with SMTP id u9mr15758219tiu.15.1228105951766; Sun, 30 Nov 2008 20:32:31 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id a14sm360158tia.12.2008.11.30.20.32.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 30 Nov 2008 20:32:30 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mB14WKba001822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Dec 2008 13:32:20 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mB14WJqs001821; Mon, 1 Dec 2008 13:32:19 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Mon, 1 Dec 2008 13:32:18 +0900 From: Pyun YongHyeon To: Andrew Tulloch Message-ID: <20081201043218.GB1082@cdnetworks.co.kr> References: <54854a7a0811291918s7affc753k998607f2529e7c2e@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <54854a7a0811291918s7affc753k998607f2529e7c2e@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2008 04:32:33 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Nov 30, 2008 at 03:18:41AM +0000, Andrew Tulloch wrote: > I've just installed from the FreeBSD 7.1-BETA1 iso and get the > following when the re driver attempts to attach to the two onboard > NICs found on a Gigabyte GA-EX58-UD5 motherboard: > > re0: Ethernet> port 0x9e00-0x9eff mem > 0xfd3ff000-0xfd3fffff,0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on > pci8 > re0: Chip rev. 0x28000000 > re0: MAC rev. 0x00100000 > re0: Unknown H/W revision: 0x28000000 > device_attach: re0 attach returned 6 > pcib9: irq 17 at device 28.5 on pci0 > pci9: on pcib9 > re1: Ethernet> port 0x8e00-0x8eff mem > 0xfd1ff000-0xfd1fffff,0xfd1f8000-0xfd1fbfff irq 17 at device 0.0 on > pci9 > re1: Chip rev. 0x28000000 > re1: MAC rev. 0x00100000 > re1: Unknown H/W revision: 0x28000000 > device_attach: re1 attach returned 6 > > pciconf -lvc extract: > re0@pci0:8:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit > cap 10[70] = PCI-Express 2 endpoint IRQ 0 > cap 11[ac] = MSI-X supports 4 messages in map 0x20 > cap 03[cc] = VPD > re1@pci0:9:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 > vendor = 'Realtek Semiconductor' > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > class = network > subclass = ethernet > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > cap 05[50] = MSI supports 1 message, 64 bit > cap 10[70] = PCI-Express 2 endpoint IRQ 0 > cap 11[ac] = MSI-X supports 4 messages in map 0x20 > cap 03[cc] = VPD > > > Is there any simple patch I can apply to get the driver to attach, > assuming it should work? > This controller seems to support MSI-X with 4 messages. Unfortunately previous PCIe controllers from RealTek were notorious for MSI issues so it's hard to know this revision really works with MSI-X. I guess it was added to support RSS(receive-side scaling of MS NDIS 6.0). As sephe said if the controller configuration is the same as 8168C family, the attached patch would make re(4) work as expected. -- Regards, Pyun YongHyeon --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="re.8168D.patch" Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 185504) +++ sys/dev/re/if_re.c (working copy) @@ -172,7 +172,7 @@ { RT_VENDORID, RT_DEVICEID_8101E, 0, "RealTek 8101E/8102E/8102EL PCIe 10/100baseTX" }, { RT_VENDORID, RT_DEVICEID_8168, 0, - "RealTek 8168/8168B/8168C/8168CP/8111B/8111C/8111CP PCIe " + "RealTek 8168/8168B/8168C/8168CP/8168D/8111B/8111C/8111CP PCIe " "Gigabit Ethernet" }, { RT_VENDORID, RT_DEVICEID_8169, 0, "RealTek 8169/8169S/8169SB(L)/8110S/8110SB(L) Gigabit Ethernet" }, @@ -1225,6 +1225,7 @@ case RL_HWREV_8168C: case RL_HWREV_8168C_SPIN2: case RL_HWREV_8168CP: + case RL_HWREV_8168D: sc->rl_flags |= RL_FLAG_INVMAR | RL_FLAG_PHYWAKE | RL_FLAG_PAR | RL_FLAG_DESCV2 | RL_FLAG_MACSTAT; /* Index: sys/pci/if_rlreg.h =================================================================== --- sys/pci/if_rlreg.h (revision 185504) +++ sys/pci/if_rlreg.h (working copy) @@ -157,6 +157,7 @@ #define RL_HWREV_8169_8110SB 0x10000000 #define RL_HWREV_8169_8110SC 0x18000000 #define RL_HWREV_8102EL 0x24800000 +#define RL_HWREV_8168D 0x28000000 #define RL_HWREV_8168_SPIN1 0x30000000 #define RL_HWREV_8100E 0x30800000 #define RL_HWREV_8101E 0x34000000 --SLDf9lqlvOQaIe6s-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 08:46:50 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 604FD1065670; Mon, 1 Dec 2008 08:46:50 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from mail.consult-scs.com (MAIL.CONSULT-SCS.COM [208.81.60.67]) by mx1.freebsd.org (Postfix) with ESMTP id 4613F8FC14; Mon, 1 Dec 2008 08:46:50 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from [127.0.0.1] (host72.netvulture.com [208.201.244.72]) (Authenticated sender: vulture@netvulture.com) by mail.consult-scs.com (Postfix) with ESMTPA id 05A241642486; Mon, 1 Dec 2008 00:28:00 -0800 (PST) Message-ID: <4933A00E.7080201@netvulture.com> Date: Mon, 01 Dec 2008 00:27:58 -0800 From: Jonathan Feally User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary="------------010705070407050807080507" X-SCS-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 05A241642486.49AC2 X-SCS-MailScanner: Found to be clean X-SCS-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-204.399, required 4, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, INIT_RECVD_OUR_AUTH -200.00) X-SCS-MailScanner-From: vulture@netvulture.com Cc: Subject: dhclient doing DISCOVER with bad IP checksum - bge 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, 01 Dec 2008 08:46:50 -0000 This is a multi-part message in MIME format. --------------010705070407050807080507 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sorry for the cross-post, but this could be either lists problem. I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is running ISC DHCPD 3.0.x from recent ports, and the other dhclient from make world. The server is refusing to answer the DISCOVER request, as it thinks the IP checksum is wrong, which tcpdump also confirms. Other DHCP clients are working fine on this network, so I do not believe it to be the network, server or dhcpd. Server is running a 2 Port Intel card - em driver. Client is a Dell PE1750 with 2 onboard NIC's - bge driver. I have tried turning off both RXCSUM and TXCSUM on both the client and server machines with no luck. I also tried the second NIC on the server with the same result. This setup was working just a couple of weeks ago, and the only thing that has changed is updating the src for a make world. PXE booting this server does result in an IP being issued, so it is pointing towards something new/changed in 7-STABLE. I have attached a 3 packet dump of the DISCOVER requests. Can anybody shed some light on this for me? Thanks, -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --------------010705070407050807080507 Content-Type: application/octet-stream; name="dhclient_badcsum.cap" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dhclient_badcsum.cap" 1MOyoQIABAAAAAAAAAAAAP//AAABAAAAuFgzSURyCgBWAQAAVgEAAP////// /wAPH2mL5QgARRABSAAAAAAQEV6WAAAAAP////8ARABDATSkzwEBBgC1qjdA AAAAAAAAAAAAAAAAAAAAAAAAAAAADx9pi+UAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAY4JTYzUBATIEwKgC8z0HAQAPH2mL5QwHZGF0YW1hbjcIARwCeQMPBgz/ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAL9YM0lmdAoAVgEAAFYBAAD///////8A Dx9pi+UIAEUQAUgAAAAAEBHulgAAAAD/////AEQAQwE0pMgBAQYAtao3QAAH AAAAAAAAAAAAAAAAAAAAAAAAAA8faYvlAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AGOCU2M1AQEyBMCoAvM9BwEADx9pi+UMB2RhdGFtYW43CAEcAnkDDwYM/wAA AAAAAAAAAAAAAAAAAAAAAAAAAADOWDNJWXYKAFYBAABWAQAA////////AA8f aYvlCABFEAFIAAAAABAR7pYAAAAA/////wBEAEMBNKS5AQEGALWqN0AAFgAA AAAAAAAAAAAAAAAAAAAAAAAPH2mL5QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABj glNjNQEBMgTAqALzPQcBAA8faYvlDAdkYXRhbWFuNwgBHAJ5Aw8GDP8AAAAA AAAAAAAAAAAAAAAAAAAAAAAA --------------010705070407050807080507-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 11:06:59 2008 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE587106564A for ; Mon, 1 Dec 2008 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B98C48FC0A for ; Mon, 1 Dec 2008 11:06:59 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB1B6x4N052626 for ; Mon, 1 Dec 2008 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB1B6xBY052622 for freebsd-net@FreeBSD.org; Mon, 1 Dec 2008 11:06:59 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Dec 2008 11:06:59 GMT Message-Id: <200812011106.mB1B6xBY052622@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2008 11:06:59 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129135 net vge driver on a VIA mini-ITX not working f kern/129074 net [ppp] [panic] kernel panic with pppoe_server o kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128884 net [msk] if_msk page fault while in kernel mode o kern/128840 net [igb] page fault under load with igb/LRO o kern/128833 net [bge] Network packets corrupted when bge card is in 64 o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o kern/128247 net [ip6] [panic] Fatal Trap 12 in ip6_forward = o kern/128181 net [fxp] panic in fxp_add_rfabuf o conf/128030 net [request] Isn't it time to enable IPsec in GENERIC? o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net arp: Segmentation fault (core dumped) s kern/127587 net [bge] [request] if_bge(4) doesn't support BCM576X fami f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126984 net [carp][patch] add carp userland notifications via devc o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and f kern/126564 net [ath] doesn't work with my PCI-E X1 wireless network a o kern/126561 net [nlm] [patch] NLM (rpclockd) RPC UNLOCK failure (stall o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126469 net [fxp] [panic] fxp(4) related kernel panic o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [in] Network: internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre f kern/125195 net [fxp] fxp(4) driver failed to initialize device Intel o kern/125079 net [ppp] host routes added by ppp with gateway flag (regr o kern/124904 net [fxp] EEPROM corruption with Compaq NC3163 NIC o kern/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets o kern/124609 net [ipsec] [panic] ipsec 'remainder too big' panic with p o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124127 net [msk] watchdog timeout (missed Tx interrupts) -- recov o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans o kern/123892 net [tap] [patch] No buffer space available o kern/123881 net [tcp] Turning on TCP blackholing causes slow localhost o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123200 net [netgraph] Server failure due to netgraph mpd and dhcp f kern/123172 net [bce] Watchdog timeout problems with if_bce o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/123066 net [ipsec] [panic] kernel trap with ipsec o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122839 net [multicast] FreeBSD 7 multicast routing problem p kern/122794 net [lagg] Kernel panic after brings lagg(8) up if NICs ar o kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122551 net [bge] Broadcom 5715S no carrier on HP BL460c blade usi o kern/122427 net [apm] [panic] apm and mDNSResponder cause panic during o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/122068 net [ppp] ppp can not set the correct interface with pptpd o kern/122058 net [em] [panic] Panic on em1: taskq o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup [reg o kern/121983 net [fxp] fxp0 MBUF and PAE o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] LOR icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o kern/121298 net [em] [panic] Fatal trap 12: page fault while in kernel o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [PATCH] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [panic] gnugk causes kernel panic when closing UDP soc o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119361 net [bge] bge(4) transmit performance problem o kern/119345 net [ath] Unsuported Atheros 5424/2424 and CPU speedstep n o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o kern/118880 net [ip6] IP_RECVDSTADDR & IP_SENDSRCADDR not implemented a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116837 net [tun] [panic] [patch] ifconfig tunX destroy: panic o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116328 net [bge]: Solid hang with bge interface o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/116077 net [ip] [patch] 6.2-STABLE panic during use of multi-cast o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/114839 net [fxp] fxp looses ability to speak with traffic o kern/114714 net [gre][patch] gre(4) is not MPSAFE and does not support o kern/113842 net [ip6] PF_INET6 proto domain state can't be cleared wit o kern/112722 net [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce]: Huge network latencies with 6.2-RELEASE / STABL o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge interface given in rc.conf not taking a o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o conf/102502 net [patch] ifconfig name does't rename netgraph node in n o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear o kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo f kern/92552 net A serious bug in most network drivers from 5.X to 6.X o kern/92090 net [bge] bge0: watchdog timeout -- resetting s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] if_sis short cable fix problems with NetGear FA3 s kern/60293 net FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [PATCH] for static ARP tables in rc.network 197 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 14:20:15 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD4581065672 for ; Mon, 1 Dec 2008 14:20:15 +0000 (UTC) (envelope-from paulo@nlink.com.br) Received: from smtp.nlink.com.br (smtp.nlink.com.br [201.12.59.3]) by mx1.freebsd.org (Postfix) with SMTP id E48698FC1D for ; Mon, 1 Dec 2008 14:20:14 +0000 (UTC) (envelope-from paulo@nlink.com.br) Received: (qmail 4441 invoked from network); 1 Dec 2008 13:53:32 -0000 Received: from j1.nlink.com.br (paulo@intra.nlink.com.br@201.12.59.126) by smtp.nlink.com.br with SMTP; 1 Dec 2008 13:53:32 -0000 Message-ID: <4933EC58.5030204@nlink.com.br> Date: Mon, 01 Dec 2008 10:53:28 -0300 From: Paulo Fragoso User-Agent: Thunderbird 2.0.0.17 (X11/20081030) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: FreeBSD 7.1 tcp problem (syncache)? 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, 01 Dec 2008 14:20:15 -0000 Hi, We was using one machine with FreeBSD 6.4-RELEASE running apache-worker-2.2.3 + mysql, this server can answer high request from one client using ab: {client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE ... Benchmarking ***** (be patient) Completed 200 requests Completed 400 requests Completed 600 requests Completed 800 requests Completed 1000 requests Completed 1200 requests Completed 1400 requests Completed 1600 requests Completed 1800 requests Finished 2000 requests ... {client}$ Using other hardware whit FreeBSD 7.1-PRERELEASE running apache-worker-2.2.9_5 + mysql, we have a poor result: {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE ... Test aborted after 10 failures apr_connect(): Invalid argument (22) {client}$ Looking for a problem on new server log we found: kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; syncache_chkrst: Spurious RST without matching syncache entry (possibly syncookie only), segment ignored All sysctl and apache conf are same on both server, is there a tcp problem with FreeBSD 7.x? Paulo Fragoso. From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 14:40:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A7941065687 for ; Mon, 1 Dec 2008 14:40:19 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id CF65A8FC16 for ; Mon, 1 Dec 2008 14:40:18 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1L79wb-0008Em-TW for freebsd-net@freebsd.org; Mon, 01 Dec 2008 14:40:13 +0000 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 Dec 2008 14:40:13 +0000 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 01 Dec 2008 14:40:13 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Mon, 01 Dec 2008 15:40:07 +0100 Lines: 41 Message-ID: References: <4933EC58.5030204@nlink.com.br> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig6EA04237E064FF1C8885F5B0" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 2.0.0.18 (X11/20081125) In-Reply-To: <4933EC58.5030204@nlink.com.br> X-Enigmail-Version: 0.95.0 Sender: news Subject: Re: FreeBSD 7.1 tcp problem (syncache)? 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, 01 Dec 2008 14:40:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig6EA04237E064FF1C8885F5B0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Paulo Fragoso wrote: >=20 > Using other hardware whit FreeBSD 7.1-PRERELEASE running > apache-worker-2.2.9_5 + mysql, we have a poor result: >=20 >=20 > {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE > ... > Test aborted after 10 failures >=20 > apr_connect(): Invalid argument (22) > {client}$ The important thing is what operating system is used on the machine running "ab", in both cases. "ab" is known to be broken with FreeBSD so if you run "ab" on FreeBSD, you'll get various problems. --------------enig6EA04237E064FF1C8885F5B0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJM/dHldnAQVacBcgRApufAKDLn61P8oQJgROY8HKepxSMvwaWLgCg84xj sAlzYtW2FpWEEWaS7JxEZNo= =E4KX -----END PGP SIGNATURE----- --------------enig6EA04237E064FF1C8885F5B0-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 14:42:22 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E0511065673 for ; Mon, 1 Dec 2008 14:42:22 +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 F0DE38FC1D for ; Mon, 1 Dec 2008 14:42:21 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 96740 invoked from network); 1 Dec 2008 13:05:19 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Dec 2008 13:05:19 -0000 Message-ID: <4933F7D6.50805@freebsd.org> Date: Mon, 01 Dec 2008 15:42:30 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Paulo Fragoso References: <4933EC58.5030204@nlink.com.br> In-Reply-To: <4933EC58.5030204@nlink.com.br> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 7.1 tcp problem (syncache)? 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, 01 Dec 2008 14:42:22 -0000 Paulo Fragoso wrote: > Hi, > > We was using one machine with FreeBSD 6.4-RELEASE running > apache-worker-2.2.3 + mysql, this server can answer high request from > one client using ab: > > {client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE > ... > Benchmarking ***** (be patient) > Completed 200 requests > Completed 400 requests > Completed 600 requests > Completed 800 requests > Completed 1000 requests > Completed 1200 requests > Completed 1400 requests > Completed 1600 requests > Completed 1800 requests > Finished 2000 requests > ... > {client}$ > > Using other hardware whit FreeBSD 7.1-PRERELEASE running > apache-worker-2.2.9_5 + mysql, we have a poor result: > > {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE > ... > Test aborted after 10 failures > > apr_connect(): Invalid argument (22) > {client}$ > > Looking for a problem on new server log we found: > > kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4; > syncache_chkrst: Spurious RST without matching syncache entry (possibly > syncookie only), segment ignored > kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; > syncache_chkrst: Spurious RST without matching syncache entry (possibly > syncookie only), segment ignored > kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; > syncache_chkrst: Spurious RST without matching syncache entry (possibly > syncookie only), segment ignored This error is harmless and occurs when the client closes the socket before the TCP session has terminated. The RST have crossed and hit the syncache. The same happens on 6.4 but it never told you about it. > All sysctl and apache conf are same on both server, is there a tcp > problem with FreeBSD 7.x? Are you using the HTTP accept filter on the server? This may cause the listen accept queue to overflow. Please post the output of "netstat -n -s -p tcp" to further diagnose the problem. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 15:19:51 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0747106578C for ; Mon, 1 Dec 2008 15:19:51 +0000 (UTC) (envelope-from paulo@nlink.com.br) Received: from smtp.nlink.com.br (smtp.nlink.com.br [201.12.59.3]) by mx1.freebsd.org (Postfix) with SMTP id BDE908FC1D for ; Mon, 1 Dec 2008 15:19:48 +0000 (UTC) (envelope-from paulo@nlink.com.br) Received: (qmail 14998 invoked from network); 1 Dec 2008 15:19:44 -0000 Received: from j1.nlink.com.br (paulo@intra.nlink.com.br@201.12.59.126) by smtp.nlink.com.br with SMTP; 1 Dec 2008 15:19:44 -0000 Message-ID: <4934008C.1070303@nlink.com.br> Date: Mon, 01 Dec 2008 12:19:40 -0300 From: Paulo Fragoso User-Agent: Thunderbird 2.0.0.17 (X11/20081030) MIME-Version: 1.0 To: Andre Oppermann References: <4933EC58.5030204@nlink.com.br> <4933F7D6.50805@freebsd.org> In-Reply-To: <4933F7D6.50805@freebsd.org> Content-Type: multipart/mixed; boundary="------------040306050501000500000100" Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 7.1 tcp problem (syncache)? 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, 01 Dec 2008 15:19:52 -0000 This is a multi-part message in MIME format. --------------040306050501000500000100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Em 01/12/2008 11:42, Andre Oppermann escreveu: > Paulo Fragoso wrote: >> Hi, >> >> We was using one machine with FreeBSD 6.4-RELEASE running >> apache-worker-2.2.3 + mysql, this server can answer high request from >> one client using ab: >> >> {client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE >> ... >> Benchmarking ***** (be patient) >> Completed 200 requests >> Completed 400 requests >> Completed 600 requests >> Completed 800 requests >> Completed 1000 requests >> Completed 1200 requests >> Completed 1400 requests >> Completed 1600 requests >> Completed 1800 requests >> Finished 2000 requests >> ... >> {client}$ >> >> Using other hardware whit FreeBSD 7.1-PRERELEASE running >> apache-worker-2.2.9_5 + mysql, we have a poor result: >> >> {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE >> ... >> Test aborted after 10 failures >> >> apr_connect(): Invalid argument (22) >> {client}$ >> >> Looking for a problem on new server log we found: >> >> kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry >> (possibly syncookie only), segment ignored >> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry >> (possibly syncookie only), segment ignored >> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry >> (possibly syncookie only), segment ignored > > This error is harmless and occurs when the client closes the socket > before the TCP session has terminated. The RST have crossed and hit > the syncache. The same happens on 6.4 but it never told you about it. Ok, but we can not understand why same solution fails using FreeBSD 7.1 and works fina with > >> All sysctl and apache conf are same on both server, is there a tcp >> problem with FreeBSD 7.x? > > Are you using the HTTP accept filter on the server? This may cause > the listen accept queue to overflow. No. server-7.1# kldstat Id Refs Address Size Name 1 4 0xffffffff80100000 b302e0 kernel 2 1 0xffffffffa3391000 8eba ipfw.ko 3 1 0xffffffffa33fe000 1ea green_saver.ko server-7.1# server-6.4# kldstat Id Refs Address Size Name 1 4 0xffffffff80100000 a380f0 kernel 2 1 0xffffffff979f0000 8566 ipfw.ko 3 1 0xffffffff97a35000 1dd green_saver.ko server-6.4# > > > Please post the output of "netstat -n -s -p tcp" to further diagnose > the problem. netstat output from two servers was attached. Our tests are based on 08 ab tests, changing -n and -c parameters at client machine, starting with: ab -n 100 -c 10 http://server/path_to_cgi and finishing with: ab -n 5000 -c 1000 http://server/path_to_cgi The old server using FreeBSD-6.4 and running on worst hardware can answer all request with some errors: FreeBSD 6.4: ab -n -c ------------------------------------------------ 100 10 1000 10 (8 errors) 1000 50 (12 errors) 1000 100 (12 errors) 1000 500 (11 errors) 2000 500 (24 errors) 2000 1000 (24 errors) 5000 1000 (4997 errors) but we can not receive any answer for two last test using server-7.1 FreeBSD 7.1: ab -n -c ------------------------------------------------ 100 10 (1 error) 1000 10 (5 errors) 1000 50 (7 errors) 1000 100 (8 errors) 1000 500 (11 errors) 2000 500 (15 errors) 2000 1000 no answer 5000 1000 no answer ab return this error on test machine: -------------------------------------- Test aborted after 10 failures apr_connect(): Invalid argument (22) -------------------------------------- Is there a new limit in FreeBSD-7.1? Paulo Fragoso --------------040306050501000500000100 Content-Type: text/plain; name="netstat-7.1.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netstat-7.1.txt" server-7.1# netstat -n -s -p tcp tcp: 75063 packets sent 31728 data packets (27702356 bytes) 2 data packets (1864 bytes) retransmitted 0 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 34657 ack-only packets (9002 delayed) 0 URG only packets 0 window probe packets 142 window update packets 8532 control packets 80919 packets received 28917 acks (for 15918245 bytes) 9425 duplicate acks 0 acks for unsent data 26168 packets (3681069 bytes) received in-sequence 893 completely duplicate packets (76110 bytes) 0 old duplicate packets 15 packets with some dup. data (1770 bytes duped) 60 out-of-order packets (86880 bytes) 10 packets (0 bytes) of data after window 0 window probes 3323 window update packets 2 packets received after close 0 discarded for bad checksums 0 discarded for bad header offset fields 0 discarded because packet too short 0 discarded due to memory problems 3 connection requests 11907 connection accepts 0 bad connection attempts 618 listen queue overflows 6398 ignored RSTs in the windows 11910 connections established (including accepts) 9740 connections closed (including 3266 drops) 24 connections updated cached RTT on close 24 connections updated cached RTT variance on close 0 connections updated cached ssthresh on close 0 embryonic connections dropped 28917 segments updated rtt (of 17512 attempts) 3 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 0 Connections (fin_wait_2) dropped because of timeout 0 keepalive timeouts 0 keepalive probes sent 0 connections dropped by keepalive 281 correct ACK header predictions 13610 correct data packet header predictions 12526 syncache entries added 6 retransmitted 8 dupsyn 0 dropped 11907 completed 28 bucket overflow 0 cache overflow 10 reset 0 stale 618 aborted 0 badack 0 unreach 0 zone failures 12526 cookies sent 37 cookies received 1 SACK recovery episode 1 segment rexmit in SACK recovery episodes 416 byte rexmits in SACK recovery episodes 4 SACK options (SACK blocks) received 31 SACK options (SACK blocks) sent 0 SACK scoreboard overflow --------------040306050501000500000100 Content-Type: text/plain; name="netstat-6.4.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="netstat-6.4.txt" server-6.4# netstat -n -s -p tcp tcp: 419071 packets sent 357030 data packets (378965034 bytes) 26 data packets (3665 bytes) retransmitted 15 data packets unnecessarily retransmitted 0 resends initiated by MTU discovery 44767 ack-only packets (13440 delayed) 0 URG only packets 0 window probe packets 11 window update packets 17237 control packets 315358 packets received 242513 acks (for 373590012 bytes) 12703 duplicate acks 0 acks for unsent data 59283 packets (4705080 bytes) received in-sequence 7 completely duplicate packets (384 bytes) 0 old duplicate packets 0 packets with some dup. data (0 bytes duped) 16 out-of-order packets (3904 bytes) 0 packets (0 bytes) of data after window 0 window probes 11056 window update packets 0 packets received after close 1 discarded for bad checksum 0 discarded for bad header offset fields 0 discarded because packet too short 4537 connection requests 13438 connection accepts 0 bad connection attempts 0 listen queue overflows 0 ignored RSTs in the windows 15708 connections established (including accepts) 15610 connections closed (including 2579 drops) 4556 connections updated cached RTT on close 4556 connections updated cached RTT variance on close 2 connections updated cached ssthresh on close 2265 embryonic connections dropped 241277 segments updated rtt (of 138901 attempts) 21 retransmit timeouts 0 connections dropped by rexmit timeout 0 persist timeouts 0 connections dropped by persist timeout 14 keepalive timeouts 14 keepalive probes sent 0 connections dropped by keepalive 31855 correct ACK header predictions 7454 correct data packet header predictions 13438 syncache entries added 17 retransmitted 0 dupsyn 0 dropped 13438 completed 34 bucket overflow 0 cache overflow 0 reset 0 stale 0 aborted 0 badack 0 unreach 0 zone failures 13438 cookies sent 34 cookies received 7 SACK recovery episodes 7 segment rexmits in SACK recovery episodes 336 byte rexmits in SACK recovery episodes 119 SACK options (SACK blocks) received 8 SACK options (SACK blocks) sent 0 SACK scoreboard overflow --------------040306050501000500000100-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 15:24:35 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51EA31065676 for ; Mon, 1 Dec 2008 15:24:35 +0000 (UTC) (envelope-from paulo@nlink.com.br) Received: from smtp.nlink.com.br (smtp.nlink.com.br [201.12.59.3]) by mx1.freebsd.org (Postfix) with SMTP id AFE928FC14 for ; Mon, 1 Dec 2008 15:24:31 +0000 (UTC) (envelope-from paulo@nlink.com.br) Received: (qmail 15480 invoked from network); 1 Dec 2008 15:24:29 -0000 Received: from j1.nlink.com.br (paulo@intra.nlink.com.br@201.12.59.126) by smtp.nlink.com.br with SMTP; 1 Dec 2008 15:24:29 -0000 Message-ID: <493401AD.90801@nlink.com.br> Date: Mon, 01 Dec 2008 12:24:29 -0300 From: Paulo Fragoso User-Agent: Thunderbird 2.0.0.17 (X11/20081030) MIME-Version: 1.0 To: Petri Helenius References: <4933EC58.5030204@nlink.com.br> <4933F7D6.50805@freebsd.org> <49340061.1060100@helenius.fi> In-Reply-To: <49340061.1060100@helenius.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Andre Oppermann Subject: Re: FreeBSD 7.1 tcp problem (syncache)? 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, 01 Dec 2008 15:24:35 -0000 Our machine test have apache-2.0.61_2 running FreeBSD-6.3-RELEASE-p3, its ab program is used on all tests. Paulo. On 01/12/2008 12:18, Petri Helenius wrote: > > I couldn't get Apache 2.2 ab to work on 7.0 at all. The ab from 2.0 > worked fine... > > Pete > > > Andre Oppermann wrote: >> Paulo Fragoso wrote: >>> Hi, >>> >>> We was using one machine with FreeBSD 6.4-RELEASE running >>> apache-worker-2.2.3 + mysql, this server can answer high request >>> from one client using ab: >>> >>> {client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE >>> ... >>> Benchmarking ***** (be patient) >>> Completed 200 requests >>> Completed 400 requests >>> Completed 600 requests >>> Completed 800 requests >>> Completed 1000 requests >>> Completed 1200 requests >>> Completed 1400 requests >>> Completed 1600 requests >>> Completed 1800 requests >>> Finished 2000 requests >>> ... >>> {client}$ >>> >>> Using other hardware whit FreeBSD 7.1-PRERELEASE running >>> apache-worker-2.2.9_5 + mysql, we have a poor result: >>> >>> {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE >>> ... >>> Test aborted after 10 failures >>> >>> apr_connect(): Invalid argument (22) >>> {client}$ >>> >>> Looking for a problem on new server log we found: >>> >>> kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4; >>> syncache_chkrst: Spurious RST without matching syncache entry >>> (possibly syncookie only), segment ignored >>> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >>> syncache_chkrst: Spurious RST without matching syncache entry >>> (possibly syncookie only), segment ignored >>> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >>> syncache_chkrst: Spurious RST without matching syncache entry >>> (possibly syncookie only), segment ignored >> >> This error is harmless and occurs when the client closes the socket >> before the TCP session has terminated. The RST have crossed and hit >> the syncache. The same happens on 6.4 but it never told you about it. >> >>> All sysctl and apache conf are same on both server, is there a tcp >>> problem with FreeBSD 7.x? >> >> Are you using the HTTP accept filter on the server? This may cause >> the listen accept queue to overflow. >> >> Please post the output of "netstat -n -s -p tcp" to further diagnose >> the problem. >> > From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 15:43:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F029A1065673; Mon, 1 Dec 2008 15:43:11 +0000 (UTC) (envelope-from petri@helenius.fi) Received: from silver.he.iki.fi (helenius.fi [83.150.107.219]) by mx1.freebsd.org (Postfix) with ESMTP id A852D8FC12; Mon, 1 Dec 2008 15:43:11 +0000 (UTC) (envelope-from petri@helenius.fi) Received: from localhost (localhost [127.0.0.1]) by silver.he.iki.fi (Postfix) with ESMTP id 69876BC03; Mon, 1 Dec 2008 17:21:02 +0200 (EET) Received: from silver.he.iki.fi ([127.0.0.1]) by localhost (silver.he.iki.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35Dh+FWJC8gg; Mon, 1 Dec 2008 17:20:55 +0200 (EET) Received: from [83.150.107.196] (d196.helenius.fi [83.150.107.196]) by silver.he.iki.fi (Postfix) with ESMTP; Mon, 1 Dec 2008 17:20:54 +0200 (EET) Message-ID: <49340061.1060100@helenius.fi> Date: Mon, 01 Dec 2008 17:18:57 +0200 From: Petri Helenius User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: Andre Oppermann References: <4933EC58.5030204@nlink.com.br> <4933F7D6.50805@freebsd.org> In-Reply-To: <4933F7D6.50805@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 7.1 tcp problem (syncache)? 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, 01 Dec 2008 15:43:12 -0000 I couldn't get Apache 2.2 ab to work on 7.0 at all. The ab from 2.0 worked fine... Pete Andre Oppermann wrote: > Paulo Fragoso wrote: >> Hi, >> >> We was using one machine with FreeBSD 6.4-RELEASE running >> apache-worker-2.2.3 + mysql, this server can answer high request from >> one client using ab: >> >> {client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE >> ... >> Benchmarking ***** (be patient) >> Completed 200 requests >> Completed 400 requests >> Completed 600 requests >> Completed 800 requests >> Completed 1000 requests >> Completed 1200 requests >> Completed 1400 requests >> Completed 1600 requests >> Completed 1800 requests >> Finished 2000 requests >> ... >> {client}$ >> >> Using other hardware whit FreeBSD 7.1-PRERELEASE running >> apache-worker-2.2.9_5 + mysql, we have a poor result: >> >> {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE >> ... >> Test aborted after 10 failures >> >> apr_connect(): Invalid argument (22) >> {client}$ >> >> Looking for a problem on new server log we found: >> >> kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry >> (possibly syncookie only), segment ignored >> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry >> (possibly syncookie only), segment ignored >> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry >> (possibly syncookie only), segment ignored > > This error is harmless and occurs when the client closes the socket > before the TCP session has terminated. The RST have crossed and hit > the syncache. The same happens on 6.4 but it never told you about it. > >> All sysctl and apache conf are same on both server, is there a tcp >> problem with FreeBSD 7.x? > > Are you using the HTTP accept filter on the server? This may cause > the listen accept queue to overflow. > > Please post the output of "netstat -n -s -p tcp" to further diagnose > the problem. > From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 16:05:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79B991065675 for ; Mon, 1 Dec 2008 16:05:25 +0000 (UTC) (envelope-from venkatvenkatsubra@yahoo.com) Received: from web58307.mail.re3.yahoo.com (web58307.mail.re3.yahoo.com [68.142.236.160]) by mx1.freebsd.org (Postfix) with SMTP id 2F1A28FC1B for ; Mon, 1 Dec 2008 16:05:25 +0000 (UTC) (envelope-from venkatvenkatsubra@yahoo.com) Received: (qmail 92552 invoked by uid 60001); 1 Dec 2008 16:05:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=kHOY7idu0N2+kDmT+3ZsFN4BRhKJJgPKDMUmIG7ZvW0m4miy9JckJaR2cDDltrwOZ6Qk7l4PE2T0JYESRXkyKK2IGCorKMs+xnsuliDq9dtBQiCDsSiZKNMCeIBPcPvssvKmfHNdWX/GrNV5QS/NSigSKKpyjajvK0JsC5TQewQ=; X-YMail-OSG: LDO.o7IVM1k_YnnIE.tNJJM8n.AMhFCLUyGvxHm8XMIuoYbOAgWPi8iYb140QbJxXGeQMoAmJpRRzyOTk1YHwz5uk7LkRSdebX55t97m5HxdmJ2ZTXrRJZ48Ijijs7NoBwROBU_o9EkT7FkjmqqbkqfXw8vqahuvd.JKsniNB_gtU6B2m7PlH1cIWS6A Received: from [70.112.131.248] by web58307.mail.re3.yahoo.com via HTTP; Mon, 01 Dec 2008 08:05:24 PST X-Mailer: YahooMailRC/1155.32 YahooMailWebService/0.7.260.1 References: <200811291746.aa88825@walton.maths.tcd.ie> <49331DA0.3070804@freebsd.org> <49331F3E.2090305@freebsd.org> Date: Mon, 1 Dec 2008 08:05:24 -0800 (PST) From: Venkat Venkatsubra To: Andre Oppermann , David Malone MIME-Version: 1.0 Message-ID: <538219.92538.qm@web58307.mail.re3.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Rui Paulo , freebsd-net@freebsd.org, Kevin Oberman Subject: Re: FreeBSD Window updates 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, 01 Dec 2008 16:05:25 -0000 Hi Andre,=0A=0AWhen delayed Ack is set the window update is not sent.=0ADoe= s this mean when odd number of packets are received and later read,=0Aa win= dow update won't go out either till the next segment arrives or=0A200 msecs= delayed ack timer ? Can this reduced window block the sender from=0Asendin= g the next segment that we are waiting for to open up the window ?=0A=0AWha= t's the purpose of the 2 MSS check by the way=A0? =0A=0AVenkat=A0=A0=0A=0A= =0A=0A=0A________________________________=0AFrom: Andre Oppermann =0ATo: David Malone =0ACc: Rui Paulo ; freebsd-net@freebsd.org; Venkat Venkatsubra ; Kevin Oberman =0ASent: Sunday, November 30, 2= 008 5:18:22 PM=0ASubject: Re: FreeBSD Window updates=0A=0AAndre Oppermann w= rote:=0A> David Malone wrote:=0A>> I've got an example extract tcpdump of t= his at the end of the mail=0A>> - here 6 ACKs are sent, 5 of which are pure= window updates and=0A>> several are 2us apart!=0A>>=0A>> I think the easy = option is to delete the code that generates explicit=0A>> window updates if= the window moves by 2*MSS. We then should be doing=0A>> something similar = to Linux. The other easy alternative would be to=0A>> add a sysclt that let= s us generate an window update every N*MSS and=0A>> by default set it to so= mething big, like 10 or 100. That should=0A>> effectively eliminate the upd= ates during bulk data transfer, but=0A>> may still generate some window upd= ates after a loss.=0A> =0A> The main problem of the pure window update test= in tcp_output() is=0A> its complete ignorance of delayed ACKs.=A0 Second i= s the strict 4.4BSD=0A> adherence to sending an update for every window inc= rease of >=3D 2*MSS.=0A> The third issue of sending a slew of window update= s after having=0A> received a FIN (telling us the other end won't ever send= more data)=0A> I have already fixed some moons ago.=0A> =0A> In my new-tcp= work I've come across the window update logic some time=0A> ago and backch= ecked with relevant RFCs and other implementations.=0A> Attached is a compi= ling but otherwise untested backport of the new logic.=0A=0ASlightly improv= ed version attached.=0A=0A-- =0AAndre=0A=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 16:07:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3E581065675 for ; Mon, 1 Dec 2008 16:07:00 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.freebsd.org (Postfix) with ESMTP id 4C5598FC19 for ; Mon, 1 Dec 2008 16:06:59 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: by ug-out-1314.google.com with SMTP id 30so2615172ugs.39 for ; Mon, 01 Dec 2008 08:06:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:subject:from:to:cc :in-reply-to:references:content-type:date:message-id:mime-version :x-mailer:content-transfer-encoding; bh=0wyzVrsnFS7SRkWTtEwRGAaEdnbUHGV1jMQPptulbVQ=; b=C/Wn4EGsyg89JEQPcMpqCXaUdQ2Wc8JBD6ZRIG/f/+nogf0XPCOFgBk3M6BiygQc6h zbeisAOmp1SNOZ+sARHVjFcuwYrXL/e0c5DCqcP77MSWvhPXtO/A//v0qmlGln1AZbCk EQ5J5eb94k5GIE7RaPjMYobJ646Aez8XhaNjo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=tQ4i1McyLKkOpoe/XEhJt5Dl4HKlixYuxiKmV6vdgCn7UhHu6dk2oIdhR1/QRuxGE/ yxXglZQKPULsaI34i3JKx5Y4QmjY7WQb3ubkpTv3v0V3h+vRNADcAiqT4E9n8NP9CUrG VeRuv04h+P5Jlqnpqyr/Kn7JxhQnYny6Chdww= Received: by 10.67.30.4 with SMTP id h4mr3465657ugj.28.1228146066640; Mon, 01 Dec 2008 07:41:06 -0800 (PST) Received: from ?127.0.0.1? (83-244-213-91.cust-83.exponential-e.net [83.244.213.91]) by mx.google.com with ESMTPS id o30sm8597881ugd.52.2008.12.01.07.41.04 (version=SSLv3 cipher=RC4-MD5); Mon, 01 Dec 2008 07:41:05 -0800 (PST) From: Tom Evans To: Paulo Fragoso In-Reply-To: <4933EC58.5030204@nlink.com.br> References: <4933EC58.5030204@nlink.com.br> Content-Type: text/plain Date: Mon, 01 Dec 2008 15:41:19 +0000 Message-Id: <1228146079.4196.26.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 7.1 tcp problem (syncache)? 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, 01 Dec 2008 16:07:00 -0000 On Mon, 2008-12-01 at 10:53 -0300, Paulo Fragoso wrote: > Hi, > > We was using one machine with FreeBSD 6.4-RELEASE running > apache-worker-2.2.3 + mysql, this server can answer high request from > one client using ab: > > > {client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE > ... > Benchmarking ***** (be patient) > Completed 200 requests > Completed 400 requests > Completed 600 requests > Completed 800 requests > Completed 1000 requests > Completed 1200 requests > Completed 1400 requests > Completed 1600 requests > Completed 1800 requests > Finished 2000 requests > ... > {client}$ > > > Using other hardware whit FreeBSD 7.1-PRERELEASE running > apache-worker-2.2.9_5 + mysql, we have a poor result: > > > {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE > ... > Test aborted after 10 failures > > apr_connect(): Invalid argument (22) > {client}$ > > > Looking for a problem on new server log we found: > > kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4; > syncache_chkrst: Spurious RST without matching syncache entry (possibly > syncookie only), segment ignored > kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; > syncache_chkrst: Spurious RST without matching syncache entry (possibly > syncookie only), segment ignored > kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; > syncache_chkrst: Spurious RST without matching syncache entry (possibly > syncookie only), segment ignored > > All sysctl and apache conf are same on both server, is there a tcp > problem with FreeBSD 7.x? > > Paulo Fragoso. > Just to rule it out, have you tried testing using a more robust tool than ab? ab is generally disliked by the apache devs I've met. Does it still fall over using something like siege[1] or flood[2]? Cheers Tom [1] http://www.joedog.org/JoeDog/Siege [2] http://httpd.apache.org/test/flood/ From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 20:15:42 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20E361065673; Mon, 1 Dec 2008 20:15:42 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [IPv6:2001:770:10:300::86e2:510b]) by mx1.freebsd.org (Postfix) with SMTP id 1F66E8FC17; Mon, 1 Dec 2008 20:15:40 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 1 Dec 2008 20:15:39 +0000 (GMT) Received: from localhost ([127.0.0.1] helo=maths.tcd.ie) by walton.maths.tcd.ie with SMTP id ; 1 Dec 2008 20:15:35 +0000 (GMT) To: Andre Oppermann In-reply-to: Your message of "Mon, 01 Dec 2008 00:18:22 +0100." <49331F3E.2090305@freebsd.org> X-Request-Do: Date: Mon, 01 Dec 2008 20:15:35 +0000 From: David Malone Message-ID: <200812012015.aa21449@walton.maths.tcd.ie> Cc: Rui Paulo , freebsd-net@freebsd.org, Venkat Venkatsubra , Kevin Oberman Subject: Re: FreeBSD Window updates 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, 01 Dec 2008 20:15:42 -0000 Hi Andre, > Slightly improved version attached. I like the idea of checking if the change is about 1 when scaled by the window scaling factor. It might even be better to check if the new window would look better when scaled down, because these aren't exactly the same. Especially when the window is small. > + * If the receive socket buffer has less than 1/4 of space > + * available and if the difference is at least two max size > + * segments, send an immediate window update to peer. I'm worried that this might leave us still being too aggressive in sending these updates. The "change by a factor of two" check might be - it will send lots of updates if the window is small (and at risk of closing) but won't send frequent pure updates if the window is big. This shouldn't be a problem because if the window is big then either: 1) there's lots of data in flight, which will naturally generate ACKs to keep the sender updated or 2) there's not much data in flight, in which case the window should be in no danger of getting too small. If we keep a rule like this, it might be better to make the limit >= 3*MSS, rather than >= 2*MSS, as I think this will tend to piggy back updates on the delayed ACK naturally (though I haven't tested this). > + * Otherwise if the difference is 1/8 (or more) of the receive > + * socket buffer, or at least 1/2 of the maximum possible window, > + * then we send a window update too. What's the motivation here? David. From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 20:25:55 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1C42F106564A for ; Mon, 1 Dec 2008 20:25:55 +0000 (UTC) (envelope-from paulo@nlink.com.br) Received: from smtp.nlink.com.br (smtp.nlink.com.br [201.12.59.3]) by mx1.freebsd.org (Postfix) with SMTP id 4A2D48FC12 for ; Mon, 1 Dec 2008 20:25:54 +0000 (UTC) (envelope-from paulo@nlink.com.br) Received: (qmail 47543 invoked from network); 1 Dec 2008 20:25:51 -0000 Received: from j1.nlink.com.br (paulo@intra.nlink.com.br@201.12.59.126) by smtp.nlink.com.br with SMTP; 1 Dec 2008 20:25:51 -0000 Message-ID: <4934484F.2020104@nlink.com.br> Date: Mon, 01 Dec 2008 17:25:51 -0300 From: Paulo Fragoso User-Agent: Thunderbird 2.0.0.17 (X11/20081030) MIME-Version: 1.0 To: Tom Evans References: <4933EC58.5030204@nlink.com.br> <1228146079.4196.26.camel@localhost> In-Reply-To: <1228146079.4196.26.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 7.1 tcp problem (syncache)? 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, 01 Dec 2008 20:25:55 -0000 On 01/12/2008 12:41, Tom Evans wrote: > On Mon, 2008-12-01 at 10:53 -0300, Paulo Fragoso wrote: > >> Hi, >> >> We was using one machine with FreeBSD 6.4-RELEASE running >> apache-worker-2.2.3 + mysql, this server can answer high request from >> one client using ab: >> >> >> {client}$ ab -n 2000 -c 1000 http://system_using_6.4-RELEASE >> ... >> Benchmarking ***** (be patient) >> Completed 200 requests >> Completed 400 requests >> Completed 600 requests >> Completed 800 requests >> Completed 1000 requests >> Completed 1200 requests >> Completed 1400 requests >> Completed 1600 requests >> Completed 1800 requests >> Finished 2000 requests >> ... >> {client}$ >> >> >> Using other hardware whit FreeBSD 7.1-PRERELEASE running >> apache-worker-2.2.9_5 + mysql, we have a poor result: >> >> >> {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE >> ... >> Test aborted after 10 failures >> >> apr_connect(): Invalid argument (22) >> {client}$ >> >> >> Looking for a problem on new server log we found: >> >> kernel: TCP: [client]:50197 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry (possibly >> syncookie only), segment ignored >> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry (possibly >> syncookie only), segment ignored >> kernel: TCP: [client]:53845 to [server]:80 tcpflags 0x4; >> syncache_chkrst: Spurious RST without matching syncache entry (possibly >> syncookie only), segment ignored >> >> All sysctl and apache conf are same on both server, is there a tcp >> problem with FreeBSD 7.x? >> >> Paulo Fragoso. >> >> > > Just to rule it out, have you tried testing using a more robust tool > than ab? ab is generally disliked by the apache devs I've met. Does it > still fall over using something like siege[1] or flood[2]? > > Cheers > > Tom > > [1] http://www.joedog.org/JoeDog/Siege > [2] http://httpd.apache.org/test/flood/ > > > We have tried siege because similar to ab configuration, but we have problem to repeat our ab tests: client$ siege -b -r1000 -c10 http://system_using_7.1-PRERELEASE HTTP/1.1 200 0.05 secs: 1948 bytes ==> /cgi-bin/path_to_program HTTP/1.1 200 0.04 secs: 1948 bytes ==> /cgi-bin/path_to_program HTTP/1.1 200 0.05 secs: 1948 bytes ==> /cgi-bin/path_to_program Segmentation fault: 11 (core dumped) same problem is happening trying old url: http://system_using_6.4-RELEASE. Have you had some advice? We are using ab since 2004 to make a historical reference for our tests for different hardware and systems. Why using same hardware to run ab we can test one server running 6.4-RELEASE but fails to teste 7.1-PRERELEASE? New way to answer request in 7.1 can crash ab at another machine? We are suspecting there is a new limit in 7.x which not clear for us yet. Paulo. From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 21:11:36 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 667761065670 for ; Mon, 1 Dec 2008 21:11:36 +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 AE23E8FC0C for ; Mon, 1 Dec 2008 21:11:35 +0000 (UTC) (envelope-from andre@freebsd.org) Received: (qmail 12703 invoked from network); 1 Dec 2008 19:34:30 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Dec 2008 19:34:30 -0000 Message-ID: <4934530F.20104@freebsd.org> Date: Mon, 01 Dec 2008 22:11:43 +0100 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: Venkat Venkatsubra References: <200811291746.aa88825@walton.maths.tcd.ie> <49331DA0.3070804@freebsd.org> <49331F3E.2090305@freebsd.org> <538219.92538.qm@web58307.mail.re3.yahoo.com> In-Reply-To: <538219.92538.qm@web58307.mail.re3.yahoo.com> Content-Type: multipart/mixed; boundary="------------070203050102030008020709" Cc: David Malone , Rui Paulo , Kevin Oberman , freebsd-net@freebsd.org Subject: Re: FreeBSD Window updates 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, 01 Dec 2008 21:11:36 -0000 This is a multi-part message in MIME format. --------------070203050102030008020709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Venkat Venkatsubra wrote: > Hi Andre, > > When delayed Ack is set the window update is not sent. > Does this mean when odd number of packets are received and later read, > a window update won't go out either till the next segment arrives or > 200 msecs delayed ack timer ? Can this reduced window block the sender from > sending the next segment that we are waiting for to open up the window ? Yes. The very idea of delayed ACK is to reduce the network utilization by ACKing only every other segment. Window updates should not override this as they currently do. Nagle comes into plays as well where we wait for the application to write something within the delayed ACK timeout to piggyback the answer together with the ACK (and window update). To answer your question: I do think we are fine with waiting for the delayed ACK. If an application starts to seriously lag behind like in your example the feedback mechanism should work and cause the sender to slow down too. The feedback loop in TCP is not only the network but also the sending and receiving application. In a normal bulk transfer where the receiving application services the receive buffer in regular intervals we update the window with every ACK. I'm open to other ideas if they fix the problem David is seeing without having more serious shortcomings. > What's the purpose of the 2 MSS check by the way ? This is part of the Silly Window Syndrome prevention. A good description is here: http://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWindow.htm PS: Attached is an updated version of the patch. The flag TF_DELACK can't be used to test for the presence of a delayed ACK. The presence of the delack timer has to be tested. -- Andre > Venkat > > > > > ________________________________ > From: Andre Oppermann > To: David Malone > Cc: Rui Paulo ; freebsd-net@freebsd.org; Venkat Venkatsubra ; Kevin Oberman > Sent: Sunday, November 30, 2008 5:18:22 PM > Subject: Re: FreeBSD Window updates > > Andre Oppermann wrote: >> David Malone wrote: >>> I've got an example extract tcpdump of this at the end of the mail >>> - here 6 ACKs are sent, 5 of which are pure window updates and >>> several are 2us apart! >>> >>> I think the easy option is to delete the code that generates explicit >>> window updates if the window moves by 2*MSS. We then should be doing >>> something similar to Linux. The other easy alternative would be to >>> add a sysclt that lets us generate an window update every N*MSS and >>> by default set it to something big, like 10 or 100. That should >>> effectively eliminate the updates during bulk data transfer, but >>> may still generate some window updates after a loss. >> The main problem of the pure window update test in tcp_output() is >> its complete ignorance of delayed ACKs. Second is the strict 4.4BSD >> adherence to sending an update for every window increase of >= 2*MSS. >> The third issue of sending a slew of window updates after having >> received a FIN (telling us the other end won't ever send more data) >> I have already fixed some moons ago. >> >> In my new-tcp work I've come across the window update logic some time >> ago and backchecked with relevant RFCs and other implementations. >> Attached is a compiling but otherwise untested backport of the new logic. > > Slightly improved version attached. > --------------070203050102030008020709 Content-Type: text/plain; name="tcp_wu_fix-20081201-2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcp_wu_fix-20081201-2.diff" Index: tcp_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/tcp_output.c,v retrieving revision 1.158 diff -u -p -r1.158 tcp_output.c --- tcp_output.c 27 Nov 2008 13:19:42 -0000 1.158 +++ tcp_output.c 1 Dec 2008 21:06:28 -0000 @@ -539,29 +539,59 @@ after_sack_rexmit: } /* - * Compare available window to amount of window - * known to peer (as advertised window less - * next expected input). If the difference is at least two - * max size segments, or at least 50% of the maximum possible - * window, then want to send a window update to peer. + * Compare available window to amount of window known to peer + * (as advertised window less next expected input) and decide + * if we have to send a pure window update segment. + * + * When a delayed ACK is scheduled, do nothing. It will update + * the window anyway in a few milliseconds when the: + * - next segment arrives we have to ack immediately; + * - application sends some data back to the peer; + * - delayed ACK timer expires. + * + * If the receive socket buffer has less than 1/4 of space + * available and if the difference is at least two max size + * segments, send an immediate window update to peer. + * + * Otherwise if the difference is 1/8 (or more) of the receive + * socket buffer, or at least 1/2 of the maximum possible window, + * then we send a window update too. + * * Skip this if the connection is in T/TCP half-open state. * Don't send pure window updates when the peer has closed * the connection and won't ever send more data. + * + * See RFC793, Section 3.7, page 43, Window Management Suggestions + * See RFC1122: Section 4.2.3.3, When to Send a Window Update + * + * Note: We are less aggressive with sending window update than + * recommended in RFC1122. This is fine with todays large socket + * buffers and will not stall the peer. In addition we piggy back + * window update on regular ACKs and sends. */ - if (recwin > 0 && !(tp->t_flags & TF_NEEDSYN) && - !TCPS_HAVERCVDFIN(tp->t_state)) { + if (recwin > 0 && !tcp_timer_active(tp, TT_DELACK) && + !(tp->t_flags & TF_NEEDSYN) && !TCPS_HAVERCVDFIN(tp->t_state)) { /* * "adv" is the amount we can increase the window, * taking into account that we are limited by * TCP_MAXWIN << tp->rcv_scale. + * + * NB: adv must be equal or larger than the smallest + * unscaled window increment. */ long adv = min(recwin, (long)TCP_MAXWIN << tp->rcv_scale) - (tp->rcv_adv - tp->rcv_nxt); - if (adv >= (long) (2 * tp->t_maxseg)) - goto send; - if (2 * adv >= (long) so->so_rcv.sb_hiwat) - goto send; + if (adv >= (long)0x1 << tp->rcv_scale) { + if (recwin <= (long)(so->so_rcv.sb_hiwat / 4) && + adv >= (long)(2 * tp->t_maxseg)) + goto send; + if (adv >= (long)(so->so_rcv.sb_hiwat / 8) && + adv >= (long)tp->t_maxseg) + goto send; + if (2 * adv >= (long)so->so_rcv.sb_hiwat) + goto send; + } } /* --------------070203050102030008020709-- From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 21:43:45 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3091710656D9; Mon, 1 Dec 2008 21:43:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A8B528FC0A; Mon, 1 Dec 2008 21:43:44 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mB1LhaQl000939; Mon, 1 Dec 2008 16:43:36 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-drivers@freebsd.org Date: Mon, 1 Dec 2008 15:05:56 -0500 User-Agent: KMail/1.9.7 References: <5D267A3F22FD854F8F48B3D2B52381933940B2DEFE@IRVEXCHCCR01.corp.ad.broadcom.com> <492B2306.60404@freebsd.org> In-Reply-To: <492B2306.60404@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812011505.56535.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Mon, 01 Dec 2008 16:43:37 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8704/Mon Dec 1 11:39:36 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: David Christensen , Sam Leffler , "freebsd-net@FreeBSD.org" Subject: Re: Gathering Hardware State During a Driver Initiated Kernel Panic 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, 01 Dec 2008 21:43:45 -0000 On Monday 24 November 2008 04:56:22 pm Sam Leffler wrote: > David Christensen wrote: > > Is there a method or callback in FreeBSD where a driver can > > be notified that it has caused a kernel panic in order to > > generate a dump of internal hardware state information? I've > > written a sysctl call for manual intervention and can handle > > some "expected" hardware events completely in the driver but > > I don't know of a way to get control again in cases where the > > driver wasn't expecting a failure. > > > > Not sure how one can deduce a driver is at fault but you might define a > ddb command for the driver and invoke that on panic using the ddb script > mechanisms (see ddb(4)). You might be able to set the current 'panic' ddb script function to one you define in your code somehow. That is, set it on entry to bce_start() and then reset it to empty when bce_start() returns. Similarly for the interrupt handler, bce_init(), and bce_ioctl(). I haven't looked to see if there is a clean way to set a script function in C though. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 21:53:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A0E31065676 for ; Mon, 1 Dec 2008 21:53:41 +0000 (UTC) (envelope-from venkatvenkatsubra@yahoo.com) Received: from web58307.mail.re3.yahoo.com (web58307.mail.re3.yahoo.com [68.142.236.160]) by mx1.freebsd.org (Postfix) with SMTP id 395288FC0C for ; Mon, 1 Dec 2008 21:53:41 +0000 (UTC) (envelope-from venkatvenkatsubra@yahoo.com) Received: (qmail 9272 invoked by uid 60001); 1 Dec 2008 21:53:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=UgtK6KfClXmHYvGb+UD5Y8sXO/ryLEu5QZg3BPMxNp+7Ax2JUW3xu4olE40sVRchbaHOW/w4vMcpvBJXwrZEh+3KAr1QyDonjMKwPcuRUKo8hD/mPvG9BFHQHFJt1T7wSNxcLNLxr9sdkWiqkcWgA3oVkQPQm8EFJ6wh3DUowOk=; X-YMail-OSG: k2ira4UVM1no9X6gTVfeNihLPnoyCW__.WCtBRc7mWphuHXx_DEdxvxMV4hyrgFWjXI3geEaqSjMoiLfaIJMuOWmFvy9OlSFBlll0QQXv.BbvoQVWdDS4k1r9_RfpgH4bsYZN6ugxZPT2smGPQW7mgc6tBLsYv9PmZ9.W58PuNNUBteR2WkgDdiN6FIV Received: from [70.112.131.248] by web58307.mail.re3.yahoo.com via HTTP; Mon, 01 Dec 2008 13:53:40 PST X-Mailer: YahooMailRC/1155.32 YahooMailWebService/0.7.260.1 References: <200811291746.aa88825@walton.maths.tcd.ie> <49331DA0.3070804@freebsd.org> <49331F3E.2090305@freebsd.org> <538219.92538.qm@web58307.mail.re3.yahoo.com> <4934530F.20104@freebsd.org> Date: Mon, 1 Dec 2008 13:53:40 -0800 (PST) From: Venkat Venkatsubra To: Andre Oppermann MIME-Version: 1.0 Message-ID: <624505.9242.qm@web58307.mail.re3.yahoo.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: David Malone , Rui Paulo , freebsd-net@freebsd.org, Kevin Oberman Subject: Re: FreeBSD Window updates 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, 01 Dec 2008 21:53:41 -0000 Hi Andre,=0A=0A>To answer your question: I do think we are fine with waitin= g for the=0A>delayed ACK.=A0 If an application starts to seriously lag behi= nd like=0A>in your example the feedback mechanism should work and cause the= sender=0A>to slow down too.=A0 The feedback loop in TCP is not only the ne= twork but=0A=0AThe case I was thinking was not apps lagging behind on the r= ead.=0AThe incoming packets got ahead and got dumped on the socket receive = buffer=0Abefore the app's blocked read could get scheduled by the OS and st= art reading=0Athe data. I am assuming the read needs the socket lock and it= has to contend for this lock=0Awith the incoming packets. The stack may no= t have any control over when the read eventually=0Agets to run. Suppose it = runs after the 13th incoming packet got copied to the socket buffer=A0=0Aan= d the window size is 13 MSS ?=0A=0A>=A0> What's the purpose of the 2 MSS ch= eck by the way ? =0A=0A>This is part of the Silly Window Syndrome preventio= n.=A0 A good description is here:=0A=0AEven without the 2 MSS check you are= going to prevent SWS, isn't that right ?=0AThe other checks will make sure= small window updates are not sent.=0A=0AVenkat=0A=0A=0A=0A________________= ________________=0AFrom: Andre Oppermann =0ATo: Venkat V= enkatsubra =0ACc: David Malone ; Rui Paulo ; Kevin Oberman ; free= bsd-net@freebsd.org=0ASent: Monday, December 1, 2008 3:11:43 PM=0ASubject: = Re: FreeBSD Window updates=0A=0AVenkat Venkatsubra wrote:=0A> Hi Andre,=0A>= =0A> When delayed Ack is set the window update is not sent.=0A> Does this = mean when odd number of packets are received and later read,=0A> a window u= pdate won't go out either till the next segment arrives or=0A> 200 msecs de= layed ack timer ? Can this reduced window block the sender from=0A> sending= the next segment that we are waiting for to open up the window ?=0A=0AYes.= =A0 The very idea of delayed ACK is to reduce the network utilization=0Aby = ACKing only every other segment.=A0 Window updates should not override=0Ath= is as they currently do.=A0 Nagle comes into plays as well where we wait=0A= for the application to write something within the delayed ACK timeout to=0A= piggyback the answer together with the ACK (and window update).=0A=0ATo ans= wer your question: I do think we are fine with waiting for the=0Adelayed AC= K.=A0 If an application starts to seriously lag behind like=0Ain your examp= le the feedback mechanism should work and cause the sender=0Ato slow down t= oo.=A0 The feedback loop in TCP is not only the network but=0Aalso the send= ing and receiving application.=A0 In a normal bulk transfer=0Awhere the rec= eiving application services the receive buffer in regular=0Aintervals we up= date the window with every ACK.=0A=0AI'm open to other ideas if they fix th= e problem David is seeing without=0Ahaving more serious shortcomings.=0A=0A= > What's the purpose of the 2 MSS check by the way ? =0A=0AThis is part of = the Silly Window Syndrome prevention.=A0 A good description is here:=0Ahttp= ://www.tcpipguide.com/free/t_TCPSillyWindowSyndromeandChangesTotheSlidingWi= ndow.htm=0A=0APS: Attached is an updated version of the patch.=A0 The flag = TF_DELACK=0Acan't be used to test for the presence of a delayed ACK.=A0 The= presence=0Aof the delack timer has to be tested.=0A=0A-- Andre=0A=0A> Venk= at=A0 =0A> =0A> =0A> =0A> ________________________________=0A> From: Andre = Oppermann =0A> To: David Malone = =0A> Cc: Rui Paulo ; freebsd-net@freebsd.org; Venkat Venka= tsubra ; Kevin Oberman =0A> Se= nt: Sunday, November 30, 2008 5:18:22 PM=0A> Subject: Re: FreeBSD Window up= dates=0A> =0A> Andre Oppermann wrote:=0A>> David Malone wrote:=0A>>> I've g= ot an example extract tcpdump of this at the end of the mail=0A>>> - here 6= ACKs are sent, 5 of which are pure window updates and=0A>>> several are 2u= s apart!=0A>>> =0A>>> I think the easy option is to delete the code that ge= nerates explicit=0A>>> window updates if the window moves by 2*MSS. We then= should be doing=0A>>> something similar to Linux. The other easy alternati= ve would be to=0A>>> add a sysclt that lets us generate an window update ev= ery N*MSS and=0A>>> by default set it to something big, like 10 or 100. Tha= t should=0A>>> effectively eliminate the updates during bulk data transfer,= but=0A>>> may still generate some window updates after a loss.=0A>> The ma= in problem of the pure window update test in tcp_output() is=0A>> its compl= ete ignorance of delayed ACKs.=A0 Second is the strict 4.4BSD=0A>> adherenc= e to sending an update for every window increase of >=3D 2*MSS.=0A>> The th= ird issue of sending a slew of window updates after having=0A>> received a = FIN (telling us the other end won't ever send more data)=0A>> I have alread= y fixed some moons ago.=0A>> =0A>> In my new-tcp work I've come across the = window update logic some time=0A>> ago and backchecked with relevant RFCs a= nd other implementations.=0A>> Attached is a compiling but otherwise untest= ed backport of the new logic.=0A> =0A> Slightly improved version attached.= =0A> =0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 22:53:53 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 529BC1065679; Mon, 1 Dec 2008 22:53:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 288EA8FC20; Mon, 1 Dec 2008 22:53:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB1MrqtA095385; Mon, 1 Dec 2008 22:53:52 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB1MrqAe095381; Mon, 1 Dec 2008 22:53:52 GMT (envelope-from linimon) Date: Mon, 1 Dec 2008 22:53:52 GMT Message-Id: <200812012253.mB1MrqAe095381@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/129352: [xl] [patch] xl0 watchdog timeout 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, 01 Dec 2008 22:53:53 -0000 Old Synopsis: xl0 watchdog timeout New Synopsis: [xl] [patch] xl0 watchdog timeout Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Dec 1 22:53:23 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=129352 From owner-freebsd-net@FreeBSD.ORG Mon Dec 1 23:10:05 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC3A01065670 for ; Mon, 1 Dec 2008 23:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B68AF8FC13 for ; Mon, 1 Dec 2008 23:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB1NA3so002608 for ; Mon, 1 Dec 2008 23:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB1NA30h002607; Mon, 1 Dec 2008 23:10:03 GMT (envelope-from gnats) Date: Mon, 1 Dec 2008 23:10:03 GMT Message-Id: <200812012310.mB1NA30h002607@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Anton Yuzhaninov Cc: Subject: Re: kern/122743: [panic] vm_page_unwire: invalid wire count: 0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Anton Yuzhaninov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2008 23:10:06 -0000 The following reply was made to PR kern/122743; it has been noted by GNATS. From: Anton Yuzhaninov To: bug-followup@FreeBSD.org, okor@zone.salut.ru Cc: Subject: Re: kern/122743: [panic] vm_page_unwire: invalid wire count: 0 Date: Tue, 02 Dec 2008 02:00:40 +0300 It looks like similar to this: http://docs.freebsd.org/cgi/mid.cgi?492B2F46.9000709 Try to change type for wire_count in struct vm_page from u_short to u_int (on i386 it has some overhead - sizeof(vm_page) increased by 4 bytes). -- Anton Yuzhaninov From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 00:50:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB43C106567B for ; Tue, 2 Dec 2008 00:50:08 +0000 (UTC) (envelope-from andrewwtulloch@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.freebsd.org (Postfix) with ESMTP id 49BD18FC17 for ; Tue, 2 Dec 2008 00:50:08 +0000 (UTC) (envelope-from andrewwtulloch@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so1455837nfh.33 for ; Mon, 01 Dec 2008 16:50:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=LhebMJVqGCb/3T/FYnIza1hHNyXLGt1YxzlIXojOVZU=; b=JFV9RXZdvJuJkSr+TKMXXi9ZVDcSf0q/A0VGXsagj921/AoDZ/Rf9EG+r7HNnb3L3x SKXTG1heF0kx4Ak4OE8TPYhM4evSAKHQfaYynafvCSzQBkdaCpZEIliPkAAbJ9NygYBb pHiiYqB4RIg1Kow1+wNaEeDp1QNd1q77RmUqc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=Kib8k2TIe5OVB92hP8DXflDGn9CVe+OHkY6wK/ncF5wp+EBijn9FYSnU38u1z3qzys H6/Ohn0fR7u492VnsJQxQgFm+vsPBlCuonclbmwBXNI5/bCMDTIW8iY0aS4SdxfBebhL F0ozOVG15P77Y4mhUAZ/b8LYkeG3YqcW/Y6tc= Received: by 10.210.29.11 with SMTP id c11mr5175429ebc.176.1228179007292; Mon, 01 Dec 2008 16:50:07 -0800 (PST) Received: by 10.210.48.20 with HTTP; Mon, 1 Dec 2008 16:50:07 -0800 (PST) Message-ID: <54854a7a0812011650i345884f5t257c066604d42e65@mail.gmail.com> Date: Tue, 2 Dec 2008 00:50:07 +0000 From: Andrew To: pyunyh@gmail.com In-Reply-To: <20081201043218.GB1082@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_78654_23757889.1228179007280" References: <54854a7a0811291918s7affc753k998607f2529e7c2e@mail.gmail.com> <20081201043218.GB1082@cdnetworks.co.kr> Cc: freebsd-net@freebsd.org Subject: Re: re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6 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, 02 Dec 2008 00:50:08 -0000 ------=_Part_78654_23757889.1228179007280 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2008/12/1 Pyun YongHyeon : > On Sun, Nov 30, 2008 at 03:18:41AM +0000, Andrew Tulloch wrote: > > I've just installed from the FreeBSD 7.1-BETA1 iso and get the > > following when the re driver attempts to attach to the two onboard > > NICs found on a Gigabyte GA-EX58-UD5 motherboard: > > > > re0: > Ethernet> port 0x9e00-0x9eff mem > > 0xfd3ff000-0xfd3fffff,0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on > > pci8 > > re0: Chip rev. 0x28000000 > > re0: MAC rev. 0x00100000 > > re0: Unknown H/W revision: 0x28000000 > > device_attach: re0 attach returned 6 > > pcib9: irq 17 at device 28.5 on pci0 > > pci9: on pcib9 > > re1: > Ethernet> port 0x8e00-0x8eff mem > > 0xfd1ff000-0xfd1fffff,0xfd1f8000-0xfd1fbfff irq 17 at device 0.0 on > > pci9 > > re1: Chip rev. 0x28000000 > > re1: MAC rev. 0x00100000 > > re1: Unknown H/W revision: 0x28000000 > > device_attach: re1 attach returned 6 > > > > pciconf -lvc extract: > > re0@pci0:8:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 > > vendor = 'Realtek Semiconductor' > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > class = network > > subclass = ethernet > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > cap 05[50] = MSI supports 1 message, 64 bit > > cap 10[70] = PCI-Express 2 endpoint IRQ 0 > > cap 11[ac] = MSI-X supports 4 messages in map 0x20 > > cap 03[cc] = VPD > > re1@pci0:9:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 > > vendor = 'Realtek Semiconductor' > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > class = network > > subclass = ethernet > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > cap 05[50] = MSI supports 1 message, 64 bit > > cap 10[70] = PCI-Express 2 endpoint IRQ 0 > > cap 11[ac] = MSI-X supports 4 messages in map 0x20 > > cap 03[cc] = VPD > > > > > > Is there any simple patch I can apply to get the driver to attach, > > assuming it should work? > > > > This controller seems to support MSI-X with 4 messages. > Unfortunately previous PCIe controllers from RealTek were notorious > for MSI issues so it's hard to know this revision really works with > MSI-X. I guess it was added to support RSS(receive-side scaling of > MS NDIS 6.0). > As sephe said if the controller configuration is the same as 8168C > family, the attached patch would make re(4) work as expected. > > -- > Regards, > Pyun YongHyeon > Pyun, I applied the patch, but it didn't attach initially, I added an extra entry to re_hwrevs as that seemed to be what was missing and it attached and seems to function (as far as a quick ping test and make update). Changes I made to if_re.c attached. If you have anything to try for MSI-X I can probably test those. Thanks, Andrew ------=_Part_78654_23757889.1228179007280 Content-Type: application/octet-stream; name=re.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_fo7tyabh1 Content-Disposition: attachment; filename=re.patch LS0tIGlmX3JlLmMub3JpZwkyMDA4LTA5LTE5IDA0OjM2OjUzLjAwMDAwMDAwMCArMDEwMAorKysg aWZfcmUuYwkyMDA4LTEyLTAyIDAwOjExOjA0LjAwMDAwMDAwMCArMDAwMApAQCAtMTcyLDcgKzE3 Miw3IEBACiAJeyBSVF9WRU5ET1JJRCwgUlRfREVWSUNFSURfODEwMUUsIDAsCiAJICAgICJSZWFs VGVrIDgxMDFFLzgxMDJFLzgxMDJFTCBQQ0llIDEwLzEwMGJhc2VUWCIgfSwKIAl7IFJUX1ZFTkRP UklELCBSVF9ERVZJQ0VJRF84MTY4LCAwLAotCSAgICAiUmVhbFRlayA4MTY4LzgxNjhCLzgxNjhD LzgxNjhDUC84MTExQi84MTExQy84MTExQ1AgUENJZSAiCisJICAgICJSZWFsVGVrIDgxNjgvODE2 OEIvODE2OEMvODE2OENQLzgxNjhELzgxMTFCLzgxMTFDLzgxMTFDUCBQQ0llICIKIAkgICAgIkdp Z2FiaXQgRXRoZXJuZXQiIH0sCiAJeyBSVF9WRU5ET1JJRCwgUlRfREVWSUNFSURfODE2OSwgMCwK IAkgICAgIlJlYWxUZWsgODE2OS84MTY5Uy84MTY5U0IoTCkvODExMFMvODExMFNCKEwpIEdpZ2Fi aXQgRXRoZXJuZXQiIH0sCkBAIC0yMTMsNiArMjEzLDcgQEAKIAl7IFJMX0hXUkVWXzgxNjhDLCBS TF84MTY5LCAiODE2OEMvODExMUMifSwKIAl7IFJMX0hXUkVWXzgxNjhDX1NQSU4yLCBSTF84MTY5 LCAiODE2OEMvODExMUMifSwKIAl7IFJMX0hXUkVWXzgxNjhDUCwgUkxfODE2OSwgIjgxNjhDUC84 MTExQ1AifSwKKwl7IFJMX0hXUkVWXzgxNjhELCBSTF84MTY5LCAiODE2OEQifSwKIAl7IDAsIDAs IE5VTEwgfQogfTsKIApAQCAtMTIyNSw2ICsxMjI2LDcgQEAKIAljYXNlIFJMX0hXUkVWXzgxNjhD OgogCWNhc2UgUkxfSFdSRVZfODE2OENfU1BJTjI6CiAJY2FzZSBSTF9IV1JFVl84MTY4Q1A6CisJ Y2FzZSBSTF9IV1JFVl84MTY4RDoKIAkJc2MtPnJsX2ZsYWdzIHw9IFJMX0ZMQUdfSU5WTUFSIHwg UkxfRkxBR19QSFlXQUtFIHwKIAkJICAgIFJMX0ZMQUdfUEFSIHwgUkxfRkxBR19ERVNDVjIgfCBS TF9GTEFHX01BQ1NUQVQ7CiAJCS8qCg== ------=_Part_78654_23757889.1228179007280-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 01:04:43 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40C68106564A for ; Tue, 2 Dec 2008 01:04:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by mx1.freebsd.org (Postfix) with ESMTP id CF20C8FC19 for ; Tue, 2 Dec 2008 01:04:42 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by ti-out-0910.google.com with SMTP id a1so1648658tib.3 for ; Mon, 01 Dec 2008 17:04:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=6edhwiMC2g8Id56ET+wobKPQA899Yn+h9lNoXsbg0CQ=; b=Fgbw/mlfhyHPFftNGJuVmIAkMN+4ehtN4fJGqKNY1aRFAE3kEZCidssACQBfnN/I2h 6oHtuMj9HPCxAH4PYL9W0doFuX46CAcnYteCki3LXVJh1IC85tV9Ldy0x6RTN+xb2Ohy cutqPVtk/0+v7jChrFDS5pRS9Y5kSxMfnHII0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=KRaSAtQvkT8ngySnmkjZ9kOtkZ5gQQ2V8uiI0UlAj7fbnHseTzKS/vpoEd/6dare/0 rGzI5iVb6wP16jm2LggTEFeUL+y0Q3RXve1+ZNmlIKPO58BcQoEOitxx05ywTjfoU3KT TsXvNcdy6DmXEYApXWnXNgTvhelqmJcoVKVXM= Received: by 10.110.62.4 with SMTP id k4mr17242259tia.17.1228179881603; Mon, 01 Dec 2008 17:04:41 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id y3sm2394872tia.6.2008.12.01.17.04.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Dec 2008 17:04:40 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mB214VcY005551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 10:04:31 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mB214VZA005550; Tue, 2 Dec 2008 10:04:31 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 2 Dec 2008 10:04:31 +0900 From: Pyun YongHyeon To: Andrew Message-ID: <20081202010431.GA5306@cdnetworks.co.kr> References: <54854a7a0811291918s7affc753k998607f2529e7c2e@mail.gmail.com> <20081201043218.GB1082@cdnetworks.co.kr> <54854a7a0812011650i345884f5t257c066604d42e65@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54854a7a0812011650i345884f5t257c066604d42e65@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2008 01:04:43 -0000 On Tue, Dec 02, 2008 at 12:50:07AM +0000, Andrew wrote: > 2008/12/1 Pyun YongHyeon : > > On Sun, Nov 30, 2008 at 03:18:41AM +0000, Andrew Tulloch wrote: > > > I've just installed from the FreeBSD 7.1-BETA1 iso and get the > > > following when the re driver attempts to attach to the two onboard > > > NICs found on a Gigabyte GA-EX58-UD5 motherboard: > > > > > > re0: > > Ethernet> port 0x9e00-0x9eff mem > > > 0xfd3ff000-0xfd3fffff,0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on > > > pci8 > > > re0: Chip rev. 0x28000000 > > > re0: MAC rev. 0x00100000 > > > re0: Unknown H/W revision: 0x28000000 > > > device_attach: re0 attach returned 6 > > > pcib9: irq 17 at device 28.5 on pci0 > > > pci9: on pcib9 > > > re1: > > Ethernet> port 0x8e00-0x8eff mem > > > 0xfd1ff000-0xfd1fffff,0xfd1f8000-0xfd1fbfff irq 17 at device 0.0 on > > > pci9 > > > re1: Chip rev. 0x28000000 > > > re1: MAC rev. 0x00100000 > > > re1: Unknown H/W revision: 0x28000000 > > > device_attach: re1 attach returned 6 > > > > > > pciconf -lvc extract: > > > re0@pci0:8:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 > > > vendor = 'Realtek Semiconductor' > > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > > class = network > > > subclass = ethernet > > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > > cap 05[50] = MSI supports 1 message, 64 bit > > > cap 10[70] = PCI-Express 2 endpoint IRQ 0 > > > cap 11[ac] = MSI-X supports 4 messages in map 0x20 > > > cap 03[cc] = VPD > > > re1@pci0:9:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 > > > vendor = 'Realtek Semiconductor' > > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > > class = network > > > subclass = ethernet > > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > > cap 05[50] = MSI supports 1 message, 64 bit > > > cap 10[70] = PCI-Express 2 endpoint IRQ 0 > > > cap 11[ac] = MSI-X supports 4 messages in map 0x20 > > > cap 03[cc] = VPD > > > > > > > > > Is there any simple patch I can apply to get the driver to attach, > > > assuming it should work? > > > > > > > This controller seems to support MSI-X with 4 messages. > > Unfortunately previous PCIe controllers from RealTek were notorious > > for MSI issues so it's hard to know this revision really works with > > MSI-X. I guess it was added to support RSS(receive-side scaling of > > MS NDIS 6.0). > > As sephe said if the controller configuration is the same as 8168C > > family, the attached patch would make re(4) work as expected. > > > > -- > > Regards, > > Pyun YongHyeon > > > > Pyun, > I applied the patch, but it didn't attach initially, I added an extra > entry to re_hwrevs as that seemed to be what was missing and it > attached and seems to function (as far as a quick ping test and make > update). Changes I made to if_re.c attached. If you have anything to > try for MSI-X I can probably test those. > You're right. I've missed to update revision entry. :-) I guess MSI-X requires a documentation from RealTek as it may have to map interrupt source to MSI-X vectors. It may also need to map PBA to MSI-X work on 8168D. Would you show me dmesg output of re(4)? Thanks for the patch and testing! -- Regards, Pyun YongHyeon From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 02:20:25 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16958106564A for ; Tue, 2 Dec 2008 02:20:25 +0000 (UTC) (envelope-from jiabwang@redhat.com) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by mx1.freebsd.org (Postfix) with ESMTP id 07C368FC19 for ; Tue, 2 Dec 2008 02:20:25 +0000 (UTC) (envelope-from jiabwang@redhat.com) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mB22KOhe016786 for ; Mon, 1 Dec 2008 21:20:24 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mB22KN1t018612 for ; Mon, 1 Dec 2008 21:20:24 -0500 Received: from [10.66.65.20] (dhcp-65-20.nay.redhat.com [10.66.65.20]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mB22KMZh010528 for ; Mon, 1 Dec 2008 21:20:23 -0500 Message-ID: <49349B93.40208@redhat.com> Date: Tue, 02 Dec 2008 10:21:07 +0800 From: wang_jiabo User-Agent: Thunderbird 2.0.0.14 (X11/20080515) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 Subject: [ipsec]could you help me explain where problem is for aes-ctr of ESP 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, 02 Dec 2008 02:20:25 -0000 Hello, all: following is my setkey configration. I can get SAD and SPD. but when I run " ping6 -I rl0 3ffe:501:ffff:103:20a:ebff:fe85:9e56 " on FreeBSD FreeBSD report: kernel: esp_aesctr_decrypt aes-ctr:payload length must be multiple of 16 kernel: decrypt fail in IPv6 ESP input : SA(SPI 8192 src=3ffe:0501:ffff:0103:020a:ebff:fe85:9e56 dst=3ffe:0501:ffff:0104:021d:0fff:fe19:59fc) but when I use "ping6 -I rl0 -s 4(or 6 or 20) 3ffe:501:ffff:103:20a:ebff:fe85:9e56" that the report disappear. I read RFC, did not find the explain. could you give me a explain? Thanks on RedHat (ipsec-tools 0.6.5) #!/sbin/setkey -f flush; spdflush; add 3ffe:501:ffff:104:21d:fff:fe19:59fc 3ffe:501:ffff:103:20a:ebff:fe85:9e56 esp 0x1000 -m transport -E aes-ctr "ipv6readylogoaes2to1" -A hmac-sha1 "ipv6readylogsha12to1"; spdadd 3ffe:501:ffff:104:21d:fff:fe19:59fc 3ffe:501:ffff:103:20a:ebff:fe85:9e56 any -P in ipsec esp/transport//require; add 3ffe:501:ffff:103:20a:ebff:fe85:9e56 3ffe:501:ffff:104:21d:fff:fe19:59fc esp 0x2000 -m transport -E aes-ctr "ipv6readylogoaes1to2" -A hmac-sha1 "ipv6readylogsha11to2"; spdadd 3ffe:501:ffff:103:20a:ebff:fe85:9e56 3ffe:501:ffff:104:21d:fff:fe19:59fc any -P out ipsec esp/transport//require; on FreeBSD6.3(ipsec-tools 0.7, using 0.6.6, problem keep still ) flush; spdflush; add 3ffe:501:ffff:103:20a:ebff:fe85:9e56 3ffe:501:ffff:104:21d:fff:fe19:59fc esp 0x2000 -m transport -E aes-ctr "ipv6readylogoaes1to2" -A hmac-sha1 "ipv6readylogsha11to2"; spdadd 3ffe:501:ffff:103:20a:ebff:fe85:9e56 3ffe:501:ffff:104:21d:fff:fe19:59fc any -P in ipsec esp/transport//require; add 3ffe:501:ffff:104:21d:fff:fe19:59fc 3ffe:501:ffff:103:20a:ebff:fe85:9e56 esp 0x1000 -m transport -E aes-ctr "ipv6readylogoaes2to1" -A hmac-sha1 "ipv6readylogsha12to1"; spdadd 3ffe:501:ffff:104:21d:fff:fe19:59fc 3ffe:501:ffff:103:20a:ebff:fe85:9e56 any -P out ipsec esp/transport//require; From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 02:22:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D3781065678 for ; Tue, 2 Dec 2008 02:22:13 +0000 (UTC) (envelope-from jiabwang@redhat.com) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by mx1.freebsd.org (Postfix) with ESMTP id 3E0808FC19 for ; Tue, 2 Dec 2008 02:22:13 +0000 (UTC) (envelope-from jiabwang@redhat.com) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mB22MD3m017032 for ; Mon, 1 Dec 2008 21:22:13 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mB22MCWc018814 for ; Mon, 1 Dec 2008 21:22:12 -0500 Received: from [10.66.65.20] (dhcp-65-20.nay.redhat.com [10.66.65.20]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mB22MBx8010599 for ; Mon, 1 Dec 2008 21:22:11 -0500 Message-ID: <49349C00.5080902@redhat.com> Date: Tue, 02 Dec 2008 10:22:56 +0800 From: wang_jiabo User-Agent: Thunderbird 2.0.0.14 (X11/20080515) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 Subject: [ipsec] why did not freebsd6.3 support icmp6 echo request on tunnel mode ? it is ok on transport mode. 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, 02 Dec 2008 02:22:13 -0000 Hello, all: the following configuration is my setkey info. when I run " setkey -f filename", system report "the result of line 4 :Invalid argument. the result of line 6 : Invalid argument." change "icmp6 128,0" to "icmp6 or any" , that is no problem . or change "tunnel" to "transport" , that is no problem. I do not know why , but the following configuration is no problem on RHEL5.2 that FreeBSD6.3 need patch ? could you give me explain Thank you very much flush; spdflush; add 3ffe:501:ffff:103:20a:ebff:fe85:9e56 3ffe:501:ffff:104:21d:fff:fe19:59fc esp 0x2000 -m tunnel -E 3des-cbc "ipv6readylogo3des1to2req" -A hmac-sha1 “ipv6readysha11to2req”; spdadd 3ffe:501:ffff:103:20a:ebff:fe85:9e56 3ffe:501:ffff:104:21d:fff:fe19:59fc icmp6 128,0 -P in ipsec esp/tunnel/3ffe:501:ffff:103:20a:ebff:fe85:9e56-3ffe:501:ffff:104:21d:fff:fe19:59fc/require; add 3ffe:501:ffff:104:21d:fff:fe19:59fc 3ffe:501:ffff:103:20a:ebff:fe85:9e56 esp 0x1000 -m tunnel -E 3des-cbc "ipv6readylogo3des2to1req" -A hmac-sha1 “ipv6readysha12to1req”; spdadd 3ffe:501:ffff:104:21d:fff:fe19:59fc 3ffe:501:ffff:103:20a:ebff:fe85:9e56 icmp6 128,0 -P out ipsec esp/tunnel/3ffe:501:ffff:104:21d:fff:fe19:59fc-3ffe:501:ffff:103:20a:ebff:fe85:9e56/require; From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 02:31:23 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D39571065670 for ; Tue, 2 Dec 2008 02:31:23 +0000 (UTC) (envelope-from jiabwang@redhat.com) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by mx1.freebsd.org (Postfix) with ESMTP id C5BAD8FC12 for ; Tue, 2 Dec 2008 02:31:23 +0000 (UTC) (envelope-from jiabwang@redhat.com) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mB22VNP9018433 for ; Mon, 1 Dec 2008 21:31:23 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mB22VMq7020215 for ; Mon, 1 Dec 2008 21:31:22 -0500 Received: from [10.66.65.20] (dhcp-65-20.nay.redhat.com [10.66.65.20]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mB22VL1m011573 for ; Mon, 1 Dec 2008 21:31:21 -0500 Message-ID: <49349E26.30002@redhat.com> Date: Tue, 02 Dec 2008 10:32:06 +0800 From: wang_jiabo User-Agent: Thunderbird 2.0.0.14 (X11/20080515) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 Subject: [ipsec] aes-ctr question 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, 02 Dec 2008 02:31:23 -0000 Hello, all: following is my setkey configration. I can get SAD and SPD. but when I run " ping6 -I rl0 3ffe:501:ffff:103:20a:ebff:fe85:9e56 " on FreeBSD FreeBSD report: kernel: esp_aesctr_decrypt aes-ctr:payload length must be multiple of 16 kernel: decrypt fail in IPv6 ESP input : SA(SPI 8192 src=3ffe:0501:ffff:0103:020a:ebff:fe85:9e56 dst=3ffe:0501:ffff:0104:021d:0fff:fe19:59fc) but when I use "ping6 -I rl0 -s 11(or 12 or 13 or 14) 3ffe:501:ffff:103:20a:ebff:fe85:9e56" that the ping pass. I read RFC, did not find the explain. could you give me a explain? Thanks flush; spdflush; add 3ffe:501:ffff:103:20a:ebff:fe85:9e56 3ffe:501:ffff:104:21d:fff:fe19:59fc esp 0x1000 -m tunnel -E aes-ctr "ipv6readylogoaes2to1" -A hmac-sha1 "ipv6readylogsha12to1"; spdadd 3ffe:501:ffff:103:20a:ebff:fe85:9e56 3ffe:501:ffff:104:21d:fff:fe19:59fc any -P in ipsec esp/tunnel/3ffe:501:ffff:103:20a:ebff:fe85:9e56-3ffe:501:ffff:104:21d:fff:fe19:59fc/require; add 3ffe:501:ffff:104:21d:fff:fe19:59fc 3ffe:501:ffff:103:20a:ebff:fe85:9e56 esp 0x2000 -m tunnel -E aes-ctr "ipv6readylogoaes1to2" -A hmac-sha1 "ipv6readylogsha11to2"; spdadd 3ffe:501:ffff:104:21d:fff:fe19:59fc 3ffe:501:ffff:103:20a:ebff:fe85:9e56 any -P out ipsec esp/tunnel/3ffe:501:ffff:104:21d:fff:fe19:59fc-3ffe:501:ffff:103:20a:ebff:fe85:9e56/require; From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 05:27:12 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 980B81065673; Tue, 2 Dec 2008 05:27:12 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from mail.consult-scs.com (MAIL.CONSULT-SCS.COM [208.81.60.67]) by mx1.freebsd.org (Postfix) with ESMTP id 8C1B18FC08; Tue, 2 Dec 2008 05:27:12 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from [127.0.0.1] (host77.netvulture.com [208.201.244.77]) (Authenticated sender: vulture@netvulture.com) by mail.consult-scs.com (Postfix) with ESMTPA id 4F72F1642489; Mon, 1 Dec 2008 21:27:41 -0800 (PST) Message-ID: <4934C733.4020506@netvulture.com> Date: Mon, 01 Dec 2008 21:27:15 -0800 From: Jonathan Feally User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org References: <4933A00E.7080201@netvulture.com> In-Reply-To: <4933A00E.7080201@netvulture.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SCS-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 4F72F1642489.DAC6B X-SCS-MailScanner: Found to be clean X-SCS-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-204.399, required 4, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, INIT_RECVD_OUR_AUTH -200.00) X-SCS-MailScanner-From: vulture@netvulture.com Cc: Subject: Re: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??) 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, 02 Dec 2008 05:27:12 -0000 Can someone please confirm or rule out my issue with dhclient sending bad IP checksum packets. It would really suck if 7.1 was released with a broken DHCP client. Jonathan Feally wrote: > Sorry for the cross-post, but this could be either lists problem. > > I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is > running ISC DHCPD 3.0.x from recent ports, and the other dhclient from > make world. > > The server is refusing to answer the DISCOVER request, as it thinks > the IP checksum is wrong, which tcpdump also confirms. Other DHCP > clients are working fine on this network, so I do not believe it to be > the network, server or dhcpd. > > Server is running a 2 Port Intel card - em driver. > > Client is a Dell PE1750 with 2 onboard NIC's - bge driver. > > I have tried turning off both RXCSUM and TXCSUM on both the client and > server machines with no luck. I also tried the second NIC on the > server with the same result. > > This setup was working just a couple of weeks ago, and the only thing > that has changed is updating the src for a make world. PXE booting > this server does result in an IP being issued, so it is pointing > towards something new/changed in 7-STABLE. > > I have attached a 3 packet dump of the DISCOVER requests. > > Can anybody shed some light on this for me? > > Thanks, -Jon > > ------------------------------------------------------------------------ > > _______________________________________________ > 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" -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 06:53:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DC321065679; Tue, 2 Dec 2008 06:53:41 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id 0EF568FC08; Tue, 2 Dec 2008 06:53:40 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (Inchoate.gsoft.com.au [203.31.81.30]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id mB26XjIm060326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Dec 2008 17:03:45 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Tue, 2 Dec 2008 17:03:37 +1030 User-Agent: KMail/1.9.10 References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> In-Reply-To: <4934C733.4020506@netvulture.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4748134.Xn4Dr6lWPW"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200812021703.44935.doconnor@gsoft.com.au> X-Spam-Score: -3.977 () ALL_TRUSTED,BAYES_00 X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-net@freebsd.org Subject: Re: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??) 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, 02 Dec 2008 06:53:41 -0000 --nextPart4748134.Xn4Dr6lWPW Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 02 December 2008 15:57:15 Jonathan Feally wrote: > Can someone please confirm or rule out my issue with dhclient sending > bad IP checksum packets. It would really suck if 7.1 was released with a > broken DHCP client. I had 7.1-PRE (early Octover) send out DHCP requests without issue, althoug= h I=20 don't have that system available now. It was using em card. I have a 7.0-STABLE system with an sk card from July that does DHCP request= s=20 just fine too.. I don't have any bge systems running 7 to test with though sorry.. Does it= =20 always give dud packets or just DHCP? Can you try another card in the clien= t? =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart4748134.Xn4Dr6lWPW Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBJNNbI5ZPcIHs/zowRAktgAJ407dx5bAwTyUNnfIGV0P6jEPPFkwCfQZWh CBeBrwgKBwnVY4FGljkCP2w= =87ln -----END PGP SIGNATURE----- --nextPart4748134.Xn4Dr6lWPW-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 11:25:20 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D5231065670 for ; Tue, 2 Dec 2008 11:25:20 +0000 (UTC) (envelope-from paulo@nlink.com.br) Received: from smtp.nlink.com.br (smtp.nlink.com.br [201.12.59.3]) by mx1.freebsd.org (Postfix) with SMTP id BC7A68FC17 for ; Tue, 2 Dec 2008 11:25:19 +0000 (UTC) (envelope-from paulo@nlink.com.br) Received: (qmail 78702 invoked from network); 2 Dec 2008 11:25:17 -0000 Received: from j1.nlink.com.br (paulo@intra.nlink.com.br@201.12.59.126) by smtp.nlink.com.br with SMTP; 2 Dec 2008 11:25:17 -0000 Message-ID: <49351B19.4030507@nlink.com.br> Date: Tue, 02 Dec 2008 08:25:13 -0300 From: Paulo Fragoso User-Agent: Thunderbird 2.0.0.17 (X11/20081030) MIME-Version: 1.0 To: Ivan Voras References: <4933EC58.5030204@nlink.com.br> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD 7.1 tcp problem (syncache)? 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, 02 Dec 2008 11:25:20 -0000 Em 01/12/2008 11:40, Ivan Voras escreveu: > Paulo Fragoso wrote: > > >> Using other hardware whit FreeBSD 7.1-PRERELEASE running >> apache-worker-2.2.9_5 + mysql, we have a poor result: >> >> >> {client}$ ab -n 2000 -c 1000 http://system_using_7.1-PRERELEASE >> ... >> Test aborted after 10 failures >> >> apr_connect(): Invalid argument (22) >> {client}$ >> > > > The important thing is what operating system is used on the machine > running "ab", in both cases. "ab" is known to be broken with FreeBSD so > if you run "ab" on FreeBSD, you'll get various problems. > client$ uname -a FreeBSD client 6.3-RELEASE-p3 FreeBSD 6.3-RELEASE-p3 #10: Wed Aug 20 10:45:00 BRT 2008 paulo@client:/usr/obj/usr/src/sys/KERNEL1 i386 Paulo. From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 12:44:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A58F0106564A for ; Tue, 2 Dec 2008 12:44:07 +0000 (UTC) (envelope-from vlad@prokk.net) Received: from smtp.prokk.net (smtp.prokk.net [195.16.77.5]) by mx1.freebsd.org (Postfix) with ESMTP id 02C1C8FC08 for ; Tue, 2 Dec 2008 12:44:03 +0000 (UTC) (envelope-from vlad@prokk.net) Received: from base (base.prokk.net [195.16.77.7]) by smtp.prokk.net (8.13.8/8.13.8) with ESMTP id mB2C6Vu1097963 for ; Tue, 2 Dec 2008 14:06:36 +0200 (EET) (envelope-from vlad@prokk.net) From: "Vladimir V. Kobal" To: Date: Tue, 2 Dec 2008 14:06:22 +0200 Organization: ProKK SE Message-ID: <001401c95476$67aec1b0$370c4510$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclUdmRdHAj9CerxRmCPAL9LJ/LVFw== Content-Language: uk X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp.prokk.net [195.16.77.5]); Tue, 02 Dec 2008 14:06:36 +0200 (EET) Subject: Multiple netgraph threads 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, 02 Dec 2008 12:44:07 -0000 Hello, I'm interested in the information of further development of Subject. I have a bottleneck: swi_net limited by one CPU core time. There was a thread http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017447.html . Patch http://people.freebsd.org/~mav/netgraph.threads.patch is not available :(. Could somebody mail it to me. Are there any other similar patches? Best regards, Vladimir Kobal From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 15:45:06 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 918481065670; Tue, 2 Dec 2008 15:45:06 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (cl-162.ewr-01.us.sixxs.net [IPv6:2001:4830:1200:a1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0E6EC8FC22; Tue, 2 Dec 2008 15:45:05 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.2) with ESMTP id mB2FjpAA091303; Tue, 2 Dec 2008 09:45:51 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id mB2Fjod3091302; Tue, 2 Dec 2008 09:45:50 -0600 (CST) (envelope-from brooks) Date: Tue, 2 Dec 2008 09:45:50 -0600 From: Brooks Davis To: Jonathan Feally Message-ID: <20081202154550.GA91152@lor.one-eyed-alien.net> References: <4933A00E.7080201@netvulture.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <4933A00E.7080201@netvulture.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 02 Dec 2008 09:45:51 -0600 (CST) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: dhclient doing DISCOVER with bad IP checksum - bge 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, 02 Dec 2008 15:45:06 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 01, 2008 at 12:27:58AM -0800, Jonathan Feally wrote: > Sorry for the cross-post, but this could be either lists problem. >=20 > I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is=20 > running ISC DHCPD 3.0.x from recent ports, and the other dhclient from ma= ke=20 > world. >=20 > The server is refusing to answer the DISCOVER request, as it thinks the I= P=20 > checksum is wrong, which tcpdump also confirms. Other DHCP clients are=20 > working fine on this network, so I do not believe it to be the network,= =20 > server or dhcpd. >=20 > Server is running a 2 Port Intel card - em driver. >=20 > Client is a Dell PE1750 with 2 onboard NIC's - bge driver. >=20 > I have tried turning off both RXCSUM and TXCSUM on both the client and=20 > server machines with no luck. I also tried the second NIC on the server= =20 > with the same result. >=20 > This setup was working just a couple of weeks ago, and the only thing tha= t=20 > has changed is updating the src for a make world. PXE booting this server= =20 > does result in an IP being issued, so it is pointing towards something=20 > new/changed in 7-STABLE. >=20 > I have attached a 3 packet dump of the DISCOVER requests. >=20 > Can anybody shed some light on this for me? Where are you running tcpdump? If on the host with the bge0 device, the checksums are probably useless due to checksum offloading. They should be valid on the server end of things. You might try disabling checksum offloading on the nic and see if that changes the results. It's possible the change to bpf.c to send packets through a socket when reassociateing isn't working correctly in that case. You might try backing out this change and seeing if the problem goes away (this will cause problems on some networks). http://svn.freebsd.org/viewvc/base/stable/7/sbin/dhclient/bpf.c?revision=3D= 178675&view=3Dmarkup -- Brooks --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (FreeBSD) iD8DBQFJNVguXY6L6fI4GtQRAi4dAJ4sdSSSL5KGyZ6VM24RFE7K8FoMiQCgyZus hBp6O01NOWY36pHpDfQ2Dg4= =IUhd -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 16:27:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 209531065670 for ; Tue, 2 Dec 2008 16:27:40 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id C38918FC12 for ; Tue, 2 Dec 2008 16:27:39 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1L7XnR-000Hmn-JA; Tue, 02 Dec 2008 18:08:21 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: Jonathan Feally In-reply-to: <4934C733.4020506@netvulture.com> References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> Comments: In-reply-to Jonathan Feally message dated "Mon, 01 Dec 2008 21:27:15 -0800." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 02 Dec 2008 18:08:21 +0200 From: Danny Braniss Message-ID: Cc: danny@cs.huji.ac.il, freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??) 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, 02 Dec 2008 16:27:40 -0000 > Can someone please confirm or rule out my issue with dhclient sending > bad IP checksum packets. It would really suck if 7.1 was released with a > broken DHCP client. > I've had many problems lately, but none involved checksum nor the dhcpd (btw, I assume that you are seeing bad checksum on the receiving server) could you add a nic to your PE1750? danny > Jonathan Feally wrote: > > Sorry for the cross-post, but this could be either lists problem. > > > > I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is > > running ISC DHCPD 3.0.x from recent ports, and the other dhclient from > > make world. > > > > The server is refusing to answer the DISCOVER request, as it thinks > > the IP checksum is wrong, which tcpdump also confirms. Other DHCP > > clients are working fine on this network, so I do not believe it to be > > the network, server or dhcpd. > > > > Server is running a 2 Port Intel card - em driver. > > > > Client is a Dell PE1750 with 2 onboard NIC's - bge driver. > > > > I have tried turning off both RXCSUM and TXCSUM on both the client and > > server machines with no luck. I also tried the second NIC on the > > server with the same result. > > > > This setup was working just a couple of weeks ago, and the only thing > > that has changed is updating the src for a make world. PXE booting > > this server does result in an IP being issued, so it is pointing > > towards something new/changed in 7-STABLE. > > > > I have attached a 3 packet dump of the DISCOVER requests. > > > > Can anybody shed some light on this for me? > > > > Thanks, -Jon > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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" > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > 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" > From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 17:40:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 881BE1065676; Tue, 2 Dec 2008 17:40:53 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from mail.consult-scs.com (MAIL.CONSULT-SCS.COM [208.81.60.67]) by mx1.freebsd.org (Postfix) with ESMTP id 669E28FC20; Tue, 2 Dec 2008 17:40:53 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from [127.0.0.1] (host77.netvulture.com [208.201.244.77]) (Authenticated sender: vulture@netvulture.com) by mail.consult-scs.com (Postfix) with ESMTPA id F3B8F1642485; Tue, 2 Dec 2008 09:41:25 -0800 (PST) Message-ID: <49357329.9000107@netvulture.com> Date: Tue, 02 Dec 2008 09:40:57 -0800 From: Jonathan Feally User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SCS-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: F3B8F1642485.6C299 X-SCS-MailScanner: Found to be clean X-SCS-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-203.107, required 4, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, INIT_RECVD_OUR_AUTH -200.00, MISSING_HEADERS 1.29) X-SCS-MailScanner-From: vulture@netvulture.com Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??) 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, 02 Dec 2008 17:40:53 -0000 I will try another em card in that server to confirm/rule out the nic driver. I am seeing the same checksum number on both the source machine, the dhcp server machine, and a 3rd windows xp machine sniffing the traffic with etherreal/wireshark. The windows xp box is running an intel nic as well, and those 0.0.0.0.67 -> 255.255.255.255.68 packets as seen by the server do have the correct checksum. After the nic test, if no change from one driver to the other, then I'll try to un-patch the bpf.c change. At this point it is acting like the checksum offloading (which I did disable on both the client and server) just isn't working. Will let you know. -Jon Danny Braniss wrote: >> Can someone please confirm or rule out my issue with dhclient sending >> bad IP checksum packets. It would really suck if 7.1 was released with a >> broken DHCP client. >> >> > I've had many problems lately, but none involved checksum nor the dhcpd > (btw, I assume that you are seeing bad checksum on the receiving server) > could you add a nic to your PE1750? > > danny > > > >> Jonathan Feally wrote: >> >>> Sorry for the cross-post, but this could be either lists problem. >>> >>> I have 2 boxes running 7-STABLE as of 20081130, both i386 SMP. One is >>> running ISC DHCPD 3.0.x from recent ports, and the other dhclient from >>> make world. >>> >>> The server is refusing to answer the DISCOVER request, as it thinks >>> the IP checksum is wrong, which tcpdump also confirms. Other DHCP >>> clients are working fine on this network, so I do not believe it to be >>> the network, server or dhcpd. >>> >>> Server is running a 2 Port Intel card - em driver. >>> >>> Client is a Dell PE1750 with 2 onboard NIC's - bge driver. >>> >>> I have tried turning off both RXCSUM and TXCSUM on both the client and >>> server machines with no luck. I also tried the second NIC on the >>> server with the same result. >>> >>> This setup was working just a couple of weeks ago, and the only thing >>> that has changed is updating the src for a make world. PXE booting >>> this server does result in an IP being issued, so it is pointing >>> towards something new/changed in 7-STABLE. >>> >>> I have attached a 3 packet dump of the DISCOVER requests. >>> >>> Can anybody shed some light on this for me? >>> >>> Thanks, -Jon >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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" >>> >> -- >> This message has been scanned for viruses and >> dangerous content by MailScanner, and is >> believed to be clean. >> >> _______________________________________________ >> 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" >> >> > > > _______________________________________________ > 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" > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 19:09:04 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEAC91065677; Tue, 2 Dec 2008 19:09:04 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from mail.consult-scs.com (MAIL.CONSULT-SCS.COM [208.81.60.67]) by mx1.freebsd.org (Postfix) with ESMTP id B3D9F8FC1A; Tue, 2 Dec 2008 19:09:04 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from [127.0.0.1] (host77.netvulture.com [208.201.244.77]) (Authenticated sender: vulture@netvulture.com) by mail.consult-scs.com (Postfix) with ESMTPA id 5BE5D164248E; Tue, 2 Dec 2008 11:09:37 -0800 (PST) Message-ID: <493587D4.5000400@netvulture.com> Date: Tue, 02 Dec 2008 11:09:08 -0800 From: Jonathan Feally User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> <49357329.9000107@netvulture.com> In-Reply-To: <49357329.9000107@netvulture.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SCS-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 5BE5D164248E.4F48C X-SCS-MailScanner: Found to be clean X-SCS-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-204.399, required 4, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, INIT_RECVD_OUR_AUTH -200.00) X-SCS-MailScanner-From: vulture@netvulture.com Cc: Subject: Re: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper??) 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, 02 Dec 2008 19:09:04 -0000 Jonathan Feally wrote: > I will try another em card in that server to confirm/rule out the nic > driver. I am seeing the same checksum number on both the source > machine, the dhcp server machine, and a 3rd windows xp machine > sniffing the traffic with etherreal/wireshark. The windows xp box is > running an intel nic as well, and those 0.0.0.0.67 -> > 255.255.255.255.68 packets as seen by the server do have the correct > checksum. After the nic test, if no change from one driver to the > other, then I'll try to un-patch the bpf.c change. > > At this point it is acting like the checksum offloading (which I did > disable on both the client and server) just isn't working. > > Will let you know. > > -Jon > > Danny Braniss wrote: Tried a add-in em0 card - intel pro/1000 XT server card - 82544E chip - no change. also tried with ifconfig em0 -rxcsum ifconfig em0 -txcsum dhclient em0 No change. Packets still received with bad IP checksum. Went back to bge0 now and reversed rev 178675 back to 172506 care of patch via http://svn.freebsd.org/viewvc/base/stable/7/sbin/dhclient/bpf.c?r1=172506&r2=178675&view=patch Also no change. So this change to dhclient doesn't seem to be the issue. >From looking at http://svn.freebsd.org/viewvc/base/stable/7/sbin/dhclient/ this patch I took out is 7 months old, and I had this system running on 7-STABLE just fine about as of about 2-3 weeks ago. So it must have been something else in the sys/net or sys/netinet. I do seem some changes that are 3 weeks old, 4 weeks, and 6 days for these directories on files that would effect the packet assembly. Authors are julian, rwatson, and bz. I'm going to look through these recent changes to try to find some that has to do with the checksum process. -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 20:05:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 85A201065673 for ; Tue, 2 Dec 2008 20:05:13 +0000 (UTC) (envelope-from andrewwtulloch@gmail.com) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.177]) by mx1.freebsd.org (Postfix) with ESMTP id 659DB8FC1F for ; Tue, 2 Dec 2008 20:05:12 +0000 (UTC) (envelope-from andrewwtulloch@gmail.com) Received: by ik-out-1112.google.com with SMTP id c21so2910519ika.3 for ; Tue, 02 Dec 2008 12:05:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=La0uHLtQdTmSjMIuh8nVmS36zk4REgO/Zr0BhGSAxSg=; b=Dl5fmqZNmHenWEFQM2mOmvWWTJtHUaSFiEO2Z1OkJgND74PVTa9QF9gBvQ/aMYjmRs A1bYNBT0Ewbo7rulAOLUr6FA52pphrMBI+QXU1YLQbAWG+My0L+A3N1Nqbik1jeZkTux UCzgeCoj0HB46e2tKpDK4M3DegRmuTXgMcTUQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=MCXMgphneZhsFuYhvFHXpIFb7qmt+kvZqQxzijIIpY0g7vcbwnx4VcYj5L0w4rGYR8 5OzkCqzB4A/Rv6pfkKBW2kLPoDganC+zLvASnB2sqyky4VfePvYq1nnA/Sj84Y0uBN8f J26WtDszw9Vx0GiG27FpKmjtszneF470v93uk= Received: by 10.210.61.8 with SMTP id j8mr14458146eba.45.1228248310707; Tue, 02 Dec 2008 12:05:10 -0800 (PST) Received: by 10.210.48.20 with HTTP; Tue, 2 Dec 2008 12:05:10 -0800 (PST) Message-ID: <54854a7a0812021205p5fc84511i4a596716f291d1a4@mail.gmail.com> Date: Tue, 2 Dec 2008 20:05:10 +0000 From: "Andrew Tulloch" Sender: andrewwtulloch@gmail.com To: pyunyh@gmail.com In-Reply-To: <20081202010431.GA5306@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_97484_15670526.1228248310716" References: <54854a7a0811291918s7affc753k998607f2529e7c2e@mail.gmail.com> <20081201043218.GB1082@cdnetworks.co.kr> <54854a7a0812011650i345884f5t257c066604d42e65@mail.gmail.com> <20081202010431.GA5306@cdnetworks.co.kr> X-Google-Sender-Auth: d834f9073d2aa6d1 Cc: freebsd-net@freebsd.org Subject: Re: re0: Unknown H/W revision: 0x28000000 device_attach: re0 attach returned 6 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, 02 Dec 2008 20:05:13 -0000 ------=_Part_97484_15670526.1228248310716 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 2008/12/2 Pyun YongHyeon : > On Tue, Dec 02, 2008 at 12:50:07AM +0000, Andrew wrote: > > 2008/12/1 Pyun YongHyeon : > > > On Sun, Nov 30, 2008 at 03:18:41AM +0000, Andrew Tulloch wrote: > > > > I've just installed from the FreeBSD 7.1-BETA1 iso and get the > > > > following when the re driver attempts to attach to the two onboard > > > > NICs found on a Gigabyte GA-EX58-UD5 motherboard: > > > > > > > > re0: > > > Ethernet> port 0x9e00-0x9eff mem > > > > 0xfd3ff000-0xfd3fffff,0xfd3f8000-0xfd3fbfff irq 16 at device 0.0 on > > > > pci8 > > > > re0: Chip rev. 0x28000000 > > > > re0: MAC rev. 0x00100000 > > > > re0: Unknown H/W revision: 0x28000000 > > > > device_attach: re0 attach returned 6 > > > > pcib9: irq 17 at device 28.5 on pci0 > > > > pci9: on pcib9 > > > > re1: > > > Ethernet> port 0x8e00-0x8eff mem > > > > 0xfd1ff000-0xfd1fffff,0xfd1f8000-0xfd1fbfff irq 17 at device 0.0 on > > > > pci9 > > > > re1: Chip rev. 0x28000000 > > > > re1: MAC rev. 0x00100000 > > > > re1: Unknown H/W revision: 0x28000000 > > > > device_attach: re1 attach returned 6 > > > > > > > > pciconf -lvc extract: > > > > re0@pci0:8:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 > > > > vendor = 'Realtek Semiconductor' > > > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > > > class = network > > > > subclass = ethernet > > > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > > > cap 05[50] = MSI supports 1 message, 64 bit > > > > cap 10[70] = PCI-Express 2 endpoint IRQ 0 > > > > cap 11[ac] = MSI-X supports 4 messages in map 0x20 > > > > cap 03[cc] = VPD > > > > re1@pci0:9:0:0: class=0x020000 card=0xe0001458 chip=0x816810ec rev=0x03 hdr=0x00 > > > > vendor = 'Realtek Semiconductor' > > > > device = 'RTL8168/8111 PCI-E Gigabit Ethernet NIC' > > > > class = network > > > > subclass = ethernet > > > > cap 01[40] = powerspec 3 supports D0 D1 D2 D3 current D0 > > > > cap 05[50] = MSI supports 1 message, 64 bit > > > > cap 10[70] = PCI-Express 2 endpoint IRQ 0 > > > > cap 11[ac] = MSI-X supports 4 messages in map 0x20 > > > > cap 03[cc] = VPD > > > > > > > > > > > > Is there any simple patch I can apply to get the driver to attach, > > > > assuming it should work? > > > > > > > > > > This controller seems to support MSI-X with 4 messages. > > > Unfortunately previous PCIe controllers from RealTek were notorious > > > for MSI issues so it's hard to know this revision really works with > > > MSI-X. I guess it was added to support RSS(receive-side scaling of > > > MS NDIS 6.0). > > > As sephe said if the controller configuration is the same as 8168C > > > family, the attached patch would make re(4) work as expected. > > > > > > -- > > > Regards, > > > Pyun YongHyeon > > > > > > > Pyun, > > I applied the patch, but it didn't attach initially, I added an extra > > entry to re_hwrevs as that seemed to be what was missing and it > > attached and seems to function (as far as a quick ping test and make > > update). Changes I made to if_re.c attached. If you have anything to > > try for MSI-X I can probably test those. > > > > You're right. I've missed to update revision entry. :-) > > I guess MSI-X requires a documentation from RealTek as it may have > to map interrupt source to MSI-X vectors. It may also need to map > PBA to MSI-X work on 8168D. Would you show me dmesg output of > re(4)? > > Thanks for the patch and testing! Pyun, Full dmesg from boot -v attached. Thanks, Andrew ------=_Part_97484_15670526.1228248310716 Content-Type: text/plain; name=dmesg-verbose.txt Content-Transfer-Encoding: base64 X-Attachment-Id: f_fo8zag8z0 Content-Disposition: attachment; filename=dmesg-verbose.txt Q29weXJpZ2h0IChjKSAxOTkyLTIwMDggVGhlIEZyZWVCU0QgUHJvamVjdC4NCkNvcHlyaWdodCAo YykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5Mywg MTk5NA0KCVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCBy aWdodHMgcmVzZXJ2ZWQuDQpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhl IEZyZWVCU0QgRm91bmRhdGlvbi4NCkZyZWVCU0QgNy4xLUJFVEEyICMxOiBUdWUgRGVjICAyIDAw OjE2OjQ4IEdNVCAyMDA4DQogICAgcm9vdEA6L3Vzci9vYmovdXNyL3NyYy9zeXMvR0VORVJJQw0K UHJlbG9hZGVkIGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC9rZXJuZWwiIGF0IDB4ZmZmZmZmZmY4 MGM0YzAwMC4NCkNhbGlicmF0aW5nIGNsb2NrKHMpIC4uLiBpODI1NCBjbG9jazogMTE5MzIwMiBI eg0KQ0xLX1VTRV9JODI1NF9DQUxJQlJBVElPTiBub3Qgc3BlY2lmaWVkIC0gdXNpbmcgZGVmYXVs dCBmcmVxdWVuY3kNClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVh bGl0eSAwDQpDYWxpYnJhdGluZyBUU0MgY2xvY2sgLi4uIFRTQyBjbG9jazogMjY5ODc3Mzc4NyBI eg0KQ1BVOiBJbnRlbChSKSBDb3JlKFRNKSBpNyBDUFUgICAgICAgICA5MjAgIEAgMi42N0dIeiAo MjY5OC43Ny1NSHogSzgtY2xhc3MgQ1BVKQ0KICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQg PSAweDEwNmE0ICBTdGVwcGluZyA9IDQNCiAgRmVhdHVyZXM9MHhiZmViZmJmZjxGUFUsVk1FLERF LFBTRSxUU0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxQ U0UzNixDTEZMVVNILERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLEhUVCxUTSxQQkU+DQog IEZlYXR1cmVzMj0weDk4ZTNiZDxTU0UzLFJTVkQyLE1PTixEU19DUEwsVk1YLEVTVCxUTTIsU1NT RTMsQ1gxNix4VFBSLFBEQ00sPGIxOT4sPGIyMD4sPGIyMz4+DQogIEFNRCBGZWF0dXJlcz0weDI4 MTAwODAwPFNZU0NBTEwsTlgsUkRUU0NQLExNPg0KICBBTUQgRmVhdHVyZXMyPTB4MTxMQUhGPg0K ICBDb3JlcyBwZXIgcGFja2FnZTogOA0KICBMb2dpY2FsIENQVXMgcGVyIGNvcmU6IDINCnVzYWJs ZSBtZW1vcnkgPSAzMjA1NzAxNjMyICgzMDU3IE1CKQ0KUGh5c2ljYWwgbWVtb3J5IGNodW5rKHMp Og0KMHgwMDAwMDAwMDAwMDAxMDAwIC0gMHgwMDAwMDAwMDAwMDliZmZmLCA2MzQ4ODAgYnl0ZXMg KDE1NSBwYWdlcykNCjB4MDAwMDAwMDAwMGQ0OTAwMCAtIDB4MDAwMDAwMDBiYTM5N2ZmZiwgMzEx MDQwMDAwMCBieXRlcyAoNzU5Mzc1IHBhZ2VzKQ0KYXZhaWwgbWVtb3J5ICA9IDMwOTk0MjI3MjAg KDI5NTUgTUIpDQpBQ1BJIEFQSUMgVGFibGU6IDxHQlQgICAgR0JUVUFDUEk+DQpJTlRSOiBBZGRp bmcgbG9jYWwgQVBJQyAyIGFzIGEgdGFyZ2V0DQpJTlRSOiBBZGRpbmcgbG9jYWwgQVBJQyA0IGFz IGEgdGFyZ2V0DQpJTlRSOiBBZGRpbmcgbG9jYWwgQVBJQyA2IGFzIGEgdGFyZ2V0DQpGcmVlQlNE L1NNUDogTXVsdGlwcm9jZXNzb3IgU3lzdGVtIERldGVjdGVkOiA4IENQVXMNCiBjcHUwIChCU1Ap OiBBUElDIElEOiAgMA0KIGNwdTEgKEFQKTogQVBJQyBJRDogIDENCiBjcHUyIChBUCk6IEFQSUMg SUQ6ICAyDQogY3B1MyAoQVApOiBBUElDIElEOiAgMw0KIGNwdTQgKEFQKTogQVBJQyBJRDogIDQN CiBjcHU1IChBUCk6IEFQSUMgSUQ6ICA1DQogY3B1NiAoQVApOiBBUElDIElEOiAgNg0KIGNwdTcg KEFQKTogQVBJQyBJRDogIDcNCkFQSUM6IENQVSAwIGhhcyBBQ1BJIElEIDANCkFQSUM6IENQVSAx IGhhcyBBQ1BJIElEIDcNCkFQSUM6IENQVSAyIGhhcyBBQ1BJIElEIDMNCkFQSUM6IENQVSAzIGhh cyBBQ1BJIElEIDYNCkFQSUM6IENQVSA0IGhhcyBBQ1BJIElEIDINCkFQSUM6IENQVSA1IGhhcyBB Q1BJIElEIDUNCkFQSUM6IENQVSA2IGhhcyBBQ1BJIElEIDENCkFQSUM6IENQVSA3IGhhcyBBQ1BJ IElEIDQNClVMRTogc2V0dXAgY3B1IGdyb3VwIDANClVMRTogc2V0dXAgY3B1IDANClVMRTogYWRk aW5nIGNwdSAwIHRvIGdyb3VwIDA6IGNwdXMgMSBtYXNrIDB4MQ0KVUxFOiBzZXR1cCBjcHUgMQ0K VUxFOiBhZGRpbmcgY3B1IDEgdG8gZ3JvdXAgMDogY3B1cyAyIG1hc2sgMHgzDQpVTEU6IHNldHVw IGNwdSBncm91cCAxDQpVTEU6IHNldHVwIGNwdSAyDQpVTEU6IGFkZGluZyBjcHUgMiB0byBncm91 cCAxOiBjcHVzIDEgbWFzayAweDQNClVMRTogc2V0dXAgY3B1IDMNClVMRTogYWRkaW5nIGNwdSAz IHRvIGdyb3VwIDE6IGNwdXMgMiBtYXNrIDB4Qw0KVUxFOiBzZXR1cCBjcHUgZ3JvdXAgMg0KVUxF OiBzZXR1cCBjcHUgNA0KVUxFOiBhZGRpbmcgY3B1IDQgdG8gZ3JvdXAgMjogY3B1cyAxIG1hc2sg MHgxMA0KVUxFOiBzZXR1cCBjcHUgNQ0KVUxFOiBhZGRpbmcgY3B1IDUgdG8gZ3JvdXAgMjogY3B1 cyAyIG1hc2sgMHgzMA0KVUxFOiBzZXR1cCBjcHUgZ3JvdXAgMw0KVUxFOiBzZXR1cCBjcHUgNg0K VUxFOiBhZGRpbmcgY3B1IDYgdG8gZ3JvdXAgMzogY3B1cyAxIG1hc2sgMHg0MA0KVUxFOiBzZXR1 cCBjcHUgNw0KVUxFOiBhZGRpbmcgY3B1IDcgdG8gZ3JvdXAgMzogY3B1cyAyIG1hc2sgMHhDMA0K QUNQSTogUlNEUCBAIDB4MHhmNzcxMC8weDAwMTQgKHYgIDAgR0JUICAgKQ0KQUNQSTogUlNEVCBA IDB4MHhiZmVlMjA0MC8weDAwMzggKHYgIDEgR0JUICAgIEdCVFVBQ1BJIDB4NDIzMDJFMzEgR0JU VSAweDAxMDEwMTAxKQ0KQUNQSTogRkFDUCBAIDB4MHhiZmVlMjBjMC8weDAwNzQgKHYgIDEgR0JU ICAgIEdCVFVBQ1BJIDB4NDIzMDJFMzEgR0JUVSAweDAxMDEwMTAxKQ0KQUNQSTogRFNEVCBAIDB4 MHhiZmVlMjE4MC8weDQ5MTkgKHYgIDEgR0JUICAgIEdCVFVBQ1BJIDB4MDAwMDEwMDAgTVNGVCAw eDAxMDAwMDBDKQ0KQUNQSTogRkFDUyBAIDB4MHhiZmVlMDAwMC8weDAwNDANCkFDUEk6IEVVRFMg QCAweDB4YmZlZTZjYzAvMHgwNDcwICh2ICAxIEdCVCAgICAgICAgICAgICAweDAwMDAwMDAwICAg ICAgMHgwMDAwMDAwMCkNCkFDUEk6IE1DRkcgQCAweDB4YmZlZTZjODAvMHgwMDNDICh2ICAxIEdC VCAgICBHQlRVQUNQSSAweDQyMzAyRTMxIEdCVFUgMHgwMTAxMDEwMSkNCkFDUEk6IEFQSUMgQCAw eDB4YmZlZTZiMDAvMHgwMEJDICh2ICAxIEdCVCAgICBHQlRVQUNQSSAweDQyMzAyRTMxIEdCVFUg MHgwMTAxMDEwMSkNCkFDUEk6IFNTRFQgQCAweDB4YmZlZTcxNDAvMHgxRUJDICh2ICAxIElOVEVM ICBQUE0gUkNNICAweDgwMDAwMDAxIElOVEwgMHgyMDA2MTEwOSkNCk1BRFQ6IEZvdW5kIElPIEFQ SUMgSUQgMiwgSW50ZXJydXB0IDAgYXQgMHhmZWMwMDAwMA0KaW9hcGljMDogQ2hhbmdpbmcgQVBJ QyBJRCB0byAyDQppb2FwaWMwOiBSb3V0aW5nIGV4dGVybmFsIDgyNTlBJ3MgLT4gaW50cGluIDAN Ck1BRFQ6IEludGVycnVwdCBvdmVycmlkZTogc291cmNlIDAsIGlycSAyDQppb2FwaWMwOiBSb3V0 aW5nIElSUSAwIC0+IGludHBpbiAyDQpNQURUOiBJbnRlcnJ1cHQgb3ZlcnJpZGU6IHNvdXJjZSA5 LCBpcnEgOQ0KaW9hcGljMDogaW50cGluIDkgdHJpZ2dlcjogbGV2ZWwNCmxhcGljMDogUm91dGlu ZyBOTUkgLT4gTElOVDENCmxhcGljMDogTElOVDEgdHJpZ2dlcjogZWRnZQ0KbGFwaWMwOiBMSU5U MSBwb2xhcml0eTogaGlnaA0KbGFwaWM2OiBSb3V0aW5nIE5NSSAtPiBMSU5UMQ0KbGFwaWM2OiBM SU5UMSB0cmlnZ2VyOiBlZGdlDQpsYXBpYzY6IExJTlQxIHBvbGFyaXR5OiBoaWdoDQpsYXBpYzQ6 IFJvdXRpbmcgTk1JIC0+IExJTlQxDQpsYXBpYzQ6IExJTlQxIHRyaWdnZXI6IGVkZ2UNCmxhcGlj NDogTElOVDEgcG9sYXJpdHk6IGhpZ2gNCmxhcGljMjogUm91dGluZyBOTUkgLT4gTElOVDENCmxh cGljMjogTElOVDEgdHJpZ2dlcjogZWRnZQ0KbGFwaWMyOiBMSU5UMSBwb2xhcml0eTogaGlnaA0K bGFwaWM3OiBSb3V0aW5nIE5NSSAtPiBMSU5UMQ0KbGFwaWM3OiBMSU5UMSB0cmlnZ2VyOiBlZGdl DQpsYXBpYzc6IExJTlQxIHBvbGFyaXR5OiBoaWdoDQpsYXBpYzU6IFJvdXRpbmcgTk1JIC0+IExJ TlQxDQpsYXBpYzU6IExJTlQxIHRyaWdnZXI6IGVkZ2UNCmxhcGljNTogTElOVDEgcG9sYXJpdHk6 IGhpZ2gNCmxhcGljMzogUm91dGluZyBOTUkgLT4gTElOVDENCmxhcGljMzogTElOVDEgdHJpZ2dl cjogZWRnZQ0KbGFwaWMzOiBMSU5UMSBwb2xhcml0eTogaGlnaA0KbGFwaWMxOiBSb3V0aW5nIE5N SSAtPiBMSU5UMQ0KbGFwaWMxOiBMSU5UMSB0cmlnZ2VyOiBlZGdlDQpsYXBpYzE6IExJTlQxIHBv bGFyaXR5OiBoaWdoDQppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhlcmJv YXJkDQpjcHUwIEJTUDoNCiAgICAgSUQ6IDB4MDAwMDAwMDAgICBWRVI6IDB4MDAwNjAwMTUgTERS OiAweDAwMDAwMDAwIERGUjogMHhmZmZmZmZmZg0KICBsaW50MDogMHgwMDAxMDcwMCBsaW50MTog MHgwMDAwMDQwMCBUUFI6IDB4MDAwMDAwMDAgU1ZSOiAweDAwMDAwMWZmDQogIHRpbWVyOiAweDAw MDEwMGVmIHRoZXJtOiAweDAwMDEwMDAwIGVycjogMHgwMDAxMDAwMCBwY206IDB4MDAwMTAwMDAN CmF0aF9yYXRlOiB2ZXJzaW9uIDEuMiA8U2FtcGxlUmF0ZSBiaXQtcmF0ZSBzZWxlY3Rpb24gYWxn b3JpdGhtPg0Kd2xhbl9hbXJyOiA8QU1SUiBUcmFuc21pdCBSYXRlIENvbnRyb2wgQWxnb3JpdGht Pg0Kd2xhbjogPDgwMi4xMSBMaW5rIExheWVyPg0KbnVsbDogPG51bGwgZGV2aWNlLCB6ZXJvIGRl dmljZT4NCnJhbmRvbTogPGVudHJvcHkgc291cmNlLCBTb2Z0d2FyZSwgWWFycm93Pg0KbmZzbG9j azogcHNldWRvLWRldmljZQ0Ka2JkOiBuZXcgYXJyYXkgc2l6ZSA0DQprYmQxIGF0IGtiZG11eDAN Cm1lbTogPG1lbW9yeT4NCmlvOiA8SS9PPg0KYXRoX2hhbDogMC45LjIwLjMgKEFSNTIxMCwgQVI1 MjExLCBBUjUyMTIsIFJGNTExMSwgUkY1MTEyLCBSRjI0MTMsIFJGNTQxMykNCmhwdHJyOiBSb2Nr ZXRSQUlEIDE3eHgvMnh4eCBTQVRBIGNvbnRyb2xsZXIgZHJpdmVyIHYxLjIgKERlYyAgMiAyMDA4 IDAwOjE2OjQzKQ0KYWNwaTA6IDxHQlQgR0JUVUFDUEk+IG9uIG1vdGhlcmJvYXJkDQppb2FwaWMw OiByb3V0aW5nIGludHBpbiA5IChJU0EgSVJRIDkpIHRvIHZlY3RvciA0OA0KYWNwaTA6IFtNUFNB RkVdDQphY3BpMDogW0lUSFJFQURdDQphY3BpMDogUG93ZXIgQnV0dG9uIChmaXhlZCkNCkFjcGlP c0Rlcml2ZVBjaUlkOiBcXF9TQl8uUENJMC5QWDQwLlBJUlEgLT4gYnVzIDAgZGV2IDMxIGZ1bmMg MA0KQWNwaU9zRGVyaXZlUGNpSWQ6IFxcX1NCXy5QQ0kwLlBYNDAuUElSMiAtPiBidXMgMCBkZXYg MzEgZnVuYyAwDQphY3BpMDogcmVzZXJ2YXRpb24gb2YgMCwgYTAwMDAgKDMpIGZhaWxlZA0KYWNw aTA6IHJlc2VydmF0aW9uIG9mIDEwMDAwMCwgYmZkZTAwMDAgKDMpIGZhaWxlZA0KQUNQSSB0aW1l cjogMS8xIDEvMSAxLzIgMS8yIDEvMCAxLzIgMS8wIDEvMSAxLzEgMS8wIC0+IDEwDQpUaW1lY291 bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDEwMDANCmFjcGlf dGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4NDA4LTB4NDBiIG9u IGFjcGkwDQpwY2lfbGluazA6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICBJ bml0aWFsIFByb2JlICAgICAgIDAgICAxMiAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEy IDE0IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDEyICAgTiAgICAgMCAgMyA0IDUgNiA3 IDkgMTAgMTEgMTIgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUgICBOICAgICAw ICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQ0KcGNpX2xpbmsxOiAgICAgICAgSW5kZXggIElS USAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAgMTAgICBOICAgICAw ICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQ0KICBWYWxpZGF0aW9uICAgICAgICAgIDAgICAx MCAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1DQogIEFmdGVyIERpc2FibGUg ICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUNCnBjaV9s aW5rMjogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIEluaXRpYWwgUHJvYmUg ICAgICAgMCAgICA3ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUNCiAgVmFs aWRhdGlvbiAgICAgICAgICAwICAgIDcgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAx NCAxNQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5 IDEwIDExIDEyIDE0IDE1DQpwY2lfbGluazM6ICAgICAgICBJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAgICAxMSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5 IDEwIDExIDEyIDE0IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgIDExICAgTiAgICAgMCAg MyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAgICAgICAwICAyNTUg ICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQ0KcGNpX2xpbms0OiAgICAgICAg SW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAgICAwICAyNTUg ICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQ0KICBWYWxpZGF0aW9uICAgICAg ICAgIDAgIDI1NSAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1DQogIEFmdGVy IERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQg MTUNCnBjaV9saW5rNTogICAgICAgIEluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogIEluaXRp YWwgUHJvYmUgICAgICAgMCAgICA0ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQg MTUNCiAgVmFsaWRhdGlvbiAgICAgICAgICAwICAgIDQgICBOICAgICAwICAzIDQgNSA2IDcgOSAx MCAxMSAxMiAxNCAxNQ0KICBBZnRlciBEaXNhYmxlICAgICAgIDAgIDI1NSAgIE4gICAgIDAgIDMg NCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1DQpwY2lfbGluazY6ICAgICAgICBJbmRleCAgSVJRICBS dGQgIFJlZiAgSVJRcw0KICBJbml0aWFsIFByb2JlICAgICAgIDAgICAgNSAgIE4gICAgIDAgIDMg NCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1DQogIFZhbGlkYXRpb24gICAgICAgICAgMCAgICA1ICAg TiAgICAgMCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUNCiAgQWZ0ZXIgRGlzYWJsZSAgICAg ICAwICAyNTUgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQ0KcGNpX2xpbms3 OiAgICAgICAgSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgSW5pdGlhbCBQcm9iZSAgICAg ICAwICAgIDMgICBOICAgICAwICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQ0KICBWYWxpZGF0 aW9uICAgICAgICAgIDAgICAgMyAgIE4gICAgIDAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1 DQogIEFmdGVyIERpc2FibGUgICAgICAgMCAgMjU1ICAgTiAgICAgMCAgMyA0IDUgNiA3IDkgMTAg MTEgMTIgMTQgMTUNCmFjcGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTANCnBjaWIw OiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTANCnBjaTA6 IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwDQpwY2kwOiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTAN CmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQwNSwgcmV2aWQ9MHgxMg0KCWRvbWFpbj0w LCBidXM9MCwgc2xvdD0wLCBmdW5jPTANCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBt ZmRldj0wDQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdv cmRzKQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0w eDAwICgwIG5zKQ0KCWludHBpbj1hLCBpcnE9MTINCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAg RDMgIGN1cnJlbnQgRDANCglNU0kgc3VwcG9ydHMgMiBtZXNzYWdlcywgdmVjdG9yIG1hc2tzDQpw Y2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4wLklOVEENCnBjaWIwOiBzbG90IDAgSU5UQSBoYXJk d2lyZWQgdG8gSVJRIDE2DQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDM0MDgsIHJldmlk PTB4MTINCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MSwgZnVuYz0wDQoJY2xhc3M9MDYtMDQtMDAs IGhkcnR5cGU9MHgwMSwgbWZkZXY9MA0KCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBj YWNoZWxuc3o9MTYgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCglpbnRwaW49YSwgaXJxPTEyDQoJcG93ZXJzcGVj IDMgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwDQoJTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMs IHZlY3RvciBtYXNrcw0KcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMS5JTlRBDQpwY2liMDog c2xvdCAxIElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNg0KZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgzNDBhLCByZXZpZD0weDEyDQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMsIGZ1bmM9MA0K CWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTANCgljbWRyZWc9MHgwMDA3LCBz dGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDA4ICgyMDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQoJaW50cGluPWEs IGlycT0xMg0KCXBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KCU1TSSBz dXBwb3J0cyAyIG1lc3NhZ2VzLCB2ZWN0b3IgbWFza3MNCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZv ciAwLjMuSU5UQQ0KcGNpYjA6IHNsb3QgMyBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTYNCmZvdW5k LT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQwYywgcmV2aWQ9MHgxMg0KCWRvbWFpbj0wLCBidXM9 MCwgc2xvdD01LCBmdW5jPTANCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0w DQoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQ0K CWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQ0KCWludHBpbj1hLCBpcnE9MTINCglwb3dlcnNwZWMgMyAgc3VwcG9ydHMgRDAgRDMgIGN1 cnJlbnQgRDANCglNU0kgc3VwcG9ydHMgMiBtZXNzYWdlcywgdmVjdG9yIG1hc2tzDQpwY2liMDog bWF0Y2hlZCBlbnRyeSBmb3IgMC41LklOVEENCnBjaWIwOiBzbG90IDUgSU5UQSBoYXJkd2lyZWQg dG8gSVJRIDE2DQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDM0MGUsIHJldmlkPTB4MTIN Cglkb21haW49MCwgYnVzPTAsIHNsb3Q9NywgZnVuYz0wDQoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5 cGU9MHgwMSwgbWZkZXY9MA0KCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxu c3o9MTYgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykNCglpbnRwaW49YSwgaXJxPTEyDQoJcG93ZXJzcGVjIDMgIHN1 cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwDQoJTVNJIHN1cHBvcnRzIDIgbWVzc2FnZXMsIHZlY3Rv ciBtYXNrcw0KcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuNy5JTlRBDQpwY2liMDogc2xvdCA3 IElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNg0KZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgz NDEwLCByZXZpZD0weDEyDQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTksIGZ1bmM9MA0KCWNsYXNz PTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTANCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVn PTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1p bmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQoJaW50cGluPWEsIGlycT0xMg0K CXBvd2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KCU1TSSBzdXBwb3J0cyAy IG1lc3NhZ2VzLCB2ZWN0b3IgbWFza3MNCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjkuSU5U QQ0KcGNpYjA6IHNsb3QgOSBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTYNCmZvdW5kLT4JdmVuZG9y PTB4ODA4NiwgZGV2PTB4MzQyNSwgcmV2aWQ9MHgxMg0KCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0x NiwgZnVuYz0wDQoJY2xhc3M9MDgtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQ0KCWNtZHJl Zz0weDAwMDAsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykNCglsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCmZv dW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQyNiwgcmV2aWQ9MHgxMg0KCWRvbWFpbj0wLCBi dXM9MCwgc2xvdD0xNiwgZnVuYz0xDQoJY2xhc3M9MDgtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZk ZXY9MQ0KCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDAwLCBjYWNoZWxuc3o9MTYgKGR3b3Jk cykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykNCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQyNywgcmV2aWQ9MHgxMg0K CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xNywgZnVuYz0wDQoJY2xhc3M9MDgtMDAtMDAsIGhkcnR5 cGU9MHgwMCwgbWZkZXY9MQ0KCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxu c3o9MTYgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMp LCBtYXhsYXQ9MHgwMCAoMCBucykNCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MzQyOCwg cmV2aWQ9MHgxMg0KCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xNywgZnVuYz0xDQoJY2xhc3M9MDgt MDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQ0KCWNtZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgw MDAwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250 PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCmZvdW5kLT4JdmVuZG9yPTB4ODA4Niwg ZGV2PTB4MzQyZCwgcmV2aWQ9MHgxMg0KCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0xOSwgZnVuYz0w DQoJY2xhc3M9MDgtMDAtMjAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQ0KCWNtZHJlZz0weDAwMDYs IHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCglwb3dlcnNwZWMg MyAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFu Z2UgMzIsIGJhc2UgMHhmZGZmZjAwMCwgc2l6ZSAxMiwgZW5hYmxlZA0KZm91bmQtPgl2ZW5kb3I9 MHg4MDg2LCBkZXY9MHgzNDJlLCByZXZpZD0weDEyDQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIw LCBmdW5jPTANCgljbGFzcz0wOC0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xDQoJY21kcmVn PTB4MDAwMCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQ0KCWxhdHRpbWVy PTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KZm91 bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzNDIyLCByZXZpZD0weDEyDQoJZG9tYWluPTAsIGJ1 cz0wLCBzbG90PTIwLCBmdW5jPTENCgljbGFzcz0wOC0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRl dj0xDQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRz KQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAw ICgwIG5zKQ0KZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzNDIzLCByZXZpZD0weDEyDQoJ ZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIwLCBmdW5jPTINCgljbGFzcz0wOC0wMC0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0xDQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5z ej0xNiAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyks IG1heGxhdD0weDAwICgwIG5zKQ0KZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzNDJmLCBy ZXZpZD0weDEyDQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTIxLCBmdW5jPTANCgljbGFzcz0wOC0w MC0yMCwgaGRydHlwZT0weDAwLCBtZmRldj0xDQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAw MDAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgzYTM3LCByZXZpZD0weDAwDQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI2LCBmdW5jPTAN CgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xDQoJY21kcmVnPTB4MDAwNSwg c3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQoJaW50cGluPWEsIGly cT0xMg0KCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZmYwMCwgc2l6 ZSAgNSwgZW5hYmxlZA0KcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjYuSU5UQQ0KcGNpYjA6 IHNsb3QgMjYgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2DQpmb3VuZC0+CXZlbmRvcj0weDgwODYs IGRldj0weDNhMzgsIHJldmlkPTB4MDANCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MjYsIGZ1bmM9 MQ0KCWNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMDA1 LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCglpbnRwaW49Yiwg aXJxPTQNCgltYXBbMjBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweGZlMDAsIHNp emUgIDUsIGVuYWJsZWQNCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjI2LklOVEINCnBjaWIw OiBzbG90IDI2IElOVEIgaGFyZHdpcmVkIHRvIElSUSAyMQ0KZm91bmQtPgl2ZW5kb3I9MHg4MDg2 LCBkZXY9MHgzYTM5LCByZXZpZD0weDAwDQoJZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI2LCBmdW5j PTINCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wDQoJY21kcmVnPTB4MDAw NSwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAo MCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQoJaW50cGluPWMs IGlycT03DQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhmZDAwLCBz aXplICA1LCBlbmFibGVkDQpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yNi5JTlRDDQpwY2li MDogc2xvdCAyNiBJTlRDIGhhcmR3aXJlZCB0byBJUlEgMTgNCmZvdW5kLT4JdmVuZG9yPTB4ODA4 NiwgZGV2PTB4M2EzYywgcmV2aWQ9MHgwMA0KCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yNiwgZnVu Yz03DQoJY2xhc3M9MGMtMDMtMjAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MA0KCWNtZHJlZz0weDAw MDYsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KCWludHBpbj1j LCBpcnE9Nw0KCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KCW1hcFsx MF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZkZmZlMDAwLCBzaXplIDEwLCBlbmFi bGVkDQpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yNi5JTlRDDQpwY2liMDogc2xvdCAyNiBJ TlRDIGhhcmR3aXJlZCB0byBJUlEgMTgNCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4M2Ez ZSwgcmV2aWQ9MHgwMA0KCWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yNywgZnVuYz0wDQoJY2xhc3M9 MDQtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MA0KCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9 MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWlu Z250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCglpbnRwaW49YSwgaXJxPTUNCglw b3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCglNU0kgc3VwcG9ydHMgMSBt ZXNzYWdlLCA2NCBiaXQNCgltYXBbMTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhm ZGZmODAwMCwgc2l6ZSAxNCwgZW5hYmxlZA0KcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjcu SU5UQQ0KcGNpYjA6IHNsb3QgMjcgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDIyDQpmb3VuZC0+CXZl bmRvcj0weDgwODYsIGRldj0weDNhNDAsIHJldmlkPTB4MDANCglkb21haW49MCwgYnVzPTAsIHNs b3Q9MjgsIGZ1bmM9MA0KCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTENCglj bWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpDQoJbGF0 dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMp DQoJaW50cGluPWEsIGlycT0xMg0KCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVu dCBEMA0KCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UNCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAw LjI4LklOVEENCnBjaWIwOiBzbG90IDI4IElOVEEgaGFyZHdpcmVkIHRvIElSUSAxNg0KZm91bmQt Pgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzYTQyLCByZXZpZD0weDAwDQoJZG9tYWluPTAsIGJ1cz0w LCBzbG90PTI4LCBmdW5jPTENCgljbGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0x DQoJY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAwMTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQ0K CWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQ0KCWludHBpbj1iLCBpcnE9MTANCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1 cnJlbnQgRDANCglNU0kgc3VwcG9ydHMgMSBtZXNzYWdlDQpwY2liMDogbWF0Y2hlZCBlbnRyeSBm b3IgMC4yOC5JTlRCDQpwY2liMDogc2xvdCAyOCBJTlRCIGhhcmR3aXJlZCB0byBJUlEgMTcNCmZv dW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4M2E0OCwgcmV2aWQ9MHgwMA0KCWRvbWFpbj0wLCBi dXM9MCwgc2xvdD0yOCwgZnVuYz00DQoJY2xhc3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZk ZXY9MQ0KCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3Jk cykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykNCglpbnRwaW49YSwgaXJxPTEyDQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQz ICBjdXJyZW50IEQwDQoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZQ0KcGNpYjA6IG1hdGNoZWQgZW50 cnkgZm9yIDAuMjguSU5UQQ0KcGNpYjA6IHNsb3QgMjggSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE2 DQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDNhNGEsIHJldmlkPTB4MDANCglkb21haW49 MCwgYnVzPTAsIHNsb3Q9MjgsIGZ1bmM9NQ0KCWNsYXNzPTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEs IG1mZGV2PTENCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTE2IChk d29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0 PTB4MDAgKDAgbnMpDQoJaW50cGluPWIsIGlycT0xMA0KCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBE MCBEMyAgY3VycmVudCBEMA0KCU1TSSBzdXBwb3J0cyAxIG1lc3NhZ2UNCnBjaWIwOiBtYXRjaGVk IGVudHJ5IGZvciAwLjI4LklOVEINCnBjaWIwOiBzbG90IDI4IElOVEIgaGFyZHdpcmVkIHRvIElS USAxNw0KZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzYTM0LCByZXZpZD0weDAwDQoJZG9t YWluPTAsIGJ1cz0wLCBzbG90PTI5LCBmdW5jPTANCgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0w eDAwLCBtZmRldj0xDQoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0w IChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4 bGF0PTB4MDAgKDAgbnMpDQoJaW50cGluPWEsIGlycT0zDQoJbWFwWzIwXTogdHlwZSBJL08gUG9y dCwgcmFuZ2UgMzIsIGJhc2UgMHhmYzAwLCBzaXplICA1LCBlbmFibGVkDQpwY2liMDogbWF0Y2hl ZCBlbnRyeSBmb3IgMC4yOS5JTlRBDQpwY2liMDogc2xvdCAyOSBJTlRBIGhhcmR3aXJlZCB0byBJ UlEgMjMNCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4M2EzNSwgcmV2aWQ9MHgwMA0KCWRv bWFpbj0wLCBidXM9MCwgc2xvdD0yOSwgZnVuYz0xDQoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9 MHgwMCwgbWZkZXY9MA0KCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9 MCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1h eGxhdD0weDAwICgwIG5zKQ0KCWludHBpbj1iLCBpcnE9MTENCgltYXBbMjBdOiB0eXBlIEkvTyBQ b3J0LCByYW5nZSAzMiwgYmFzZSAweGZiMDAsIHNpemUgIDUsIGVuYWJsZWQNCnBjaWIwOiBtYXRj aGVkIGVudHJ5IGZvciAwLjI5LklOVEINCnBjaWIwOiBzbG90IDI5IElOVEIgaGFyZHdpcmVkIHRv IElSUSAxOQ0KZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzYTM2LCByZXZpZD0weDAwDQoJ ZG9tYWluPTAsIGJ1cz0wLCBzbG90PTI5LCBmdW5jPTINCgljbGFzcz0wYy0wMy0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0wDQoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5z ej0wIChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpDQoJaW50cGluPWMsIGlycT03DQoJbWFwWzIwXTogdHlwZSBJL08g UG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhmYTAwLCBzaXplICA1LCBlbmFibGVkDQpwY2liMDogbWF0 Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRDDQpwY2liMDogc2xvdCAyOSBJTlRDIGhhcmR3aXJlZCB0 byBJUlEgMTgNCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4M2EzYSwgcmV2aWQ9MHgwMA0K CWRvbWFpbj0wLCBidXM9MCwgc2xvdD0yOSwgZnVuYz03DQoJY2xhc3M9MGMtMDMtMjAsIGhkcnR5 cGU9MHgwMCwgbWZkZXY9MA0KCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxu c3o9MCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyks IG1heGxhdD0weDAwICgwIG5zKQ0KCWludHBpbj1hLCBpcnE9Mw0KCXBvd2Vyc3BlYyAyICBzdXBw b3J0cyBEMCBEMyAgY3VycmVudCBEMA0KCW1hcFsxMF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwg YmFzZSAweGZkZmZkMDAwLCBzaXplIDEwLCBlbmFibGVkDQpwY2liMDogbWF0Y2hlZCBlbnRyeSBm b3IgMC4yOS5JTlRBDQpwY2liMDogc2xvdCAyOSBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMjMNCmZv dW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjQ0ZSwgcmV2aWQ9MHg5MA0KCWRvbWFpbj0wLCBi dXM9MCwgc2xvdD0zMCwgZnVuYz0wDQoJY2xhc3M9MDYtMDQtMDEsIGhkcnR5cGU9MHgwMSwgbWZk ZXY9MA0KCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MCAoZHdvcmRz KQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAw ICgwIG5zKQ0KZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzYTE2LCByZXZpZD0weDAwDQoJ ZG9tYWluPTAsIGJ1cz0wLCBzbG90PTMxLCBmdW5jPTANCgljbGFzcz0wNi0wMS0wMCwgaGRydHlw ZT0weDAwLCBtZmRldj0xDQoJY21kcmVnPTB4MDEwNywgc3RhdHJlZz0weDAyMTAsIGNhY2hlbG5z ej0wIChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwg bWF4bGF0PTB4MDAgKDAgbnMpDQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDNhMjAsIHJl dmlkPTB4MDANCglkb21haW49MCwgYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9Mg0KCWNsYXNzPTAxLTAx LThhLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDJi MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCglpbnRwaW49YiwgaXJxPTI1NQ0KCXBvd2Vy c3BlYyAzICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KCW1hcFsyMF06IHR5cGUgSS9PIFBv cnQsIHJhbmdlIDMyLCBiYXNlIDB4ZjkwMCwgc2l6ZSAgNCwgZW5hYmxlZA0KCW1hcFsyNF06IHR5 cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBiYXNlIDB4ZjgwMCwgc2l6ZSAgNCwgZW5hYmxlZA0KZm91 bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgzYTMwLCByZXZpZD0weDAwDQoJZG9tYWluPTAsIGJ1 cz0wLCBzbG90PTMxLCBmdW5jPTMNCgljbGFzcz0wYy0wNS0wMCwgaGRydHlwZT0weDAwLCBtZmRl dj0wDQoJY21kcmVnPTB4MDAwMywgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMp DQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAg KDAgbnMpDQoJaW50cGluPWMsIGlycT03DQoJbWFwWzEwXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0 LCBiYXNlIDB4ZmRmZmMwMDAsIHNpemUgIDgsIGVuYWJsZWQNCgltYXBbMjBdOiB0eXBlIEkvTyBQ b3J0LCByYW5nZSAzMiwgYmFzZSAweDUwMCwgc2l6ZSAgNSwgZW5hYmxlZA0KcGNpYjA6IG1hdGNo ZWQgZW50cnkgZm9yIDAuMzEuSU5UQw0KcGNpYjA6IHNsb3QgMzEgSU5UQyBoYXJkd2lyZWQgdG8g SVJRIDE4DQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDNhMjYsIHJldmlkPTB4MDANCglk b21haW49MCwgYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9NQ0KCWNsYXNzPTAxLTAxLTg1LCBoZHJ0eXBl PTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4MDJiMCwgY2FjaGVsbnN6 PTAgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBt YXhsYXQ9MHgwMCAoMCBucykNCglpbnRwaW49YiwgaXJxPTExDQoJcG93ZXJzcGVjIDMgIHN1cHBv cnRzIEQwIEQzICBjdXJyZW50IEQwDQoJbWFwWzEwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIs IGJhc2UgMHhmNjAwLCBzaXplICAzLCBlbmFibGVkDQoJbWFwWzE0XTogdHlwZSBJL08gUG9ydCwg cmFuZ2UgMzIsIGJhc2UgMHhmNTAwLCBzaXplICAyLCBlbmFibGVkDQoJbWFwWzE4XTogdHlwZSBJ L08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhmNDAwLCBzaXplICAzLCBlbmFibGVkDQoJbWFwWzFj XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhmMzAwLCBzaXplICAyLCBlbmFibGVk DQoJbWFwWzIwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhmMjAwLCBzaXplICA0 LCBlbmFibGVkDQoJbWFwWzI0XTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2UgMHhmMTAw LCBzaXplICA0LCBlbmFibGVkDQpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4zMS5JTlRCDQpw Y2liMDogc2xvdCAzMSBJTlRCIGhhcmR3aXJlZCB0byBJUlEgMTkNCnBjaWIxOiA8UENJLVBDSSBi cmlkZ2U+IGlycSAxNiBhdCBkZXZpY2UgMS4wIG9uIHBjaTANCnBjaWIxOiAgIGRvbWFpbiAgICAg ICAgICAgIDANCnBjaWIxOiAgIHNlY29uZGFyeSBidXMgICAgIDENCnBjaWIxOiAgIHN1Ym9yZGlu YXRlIGJ1cyAgIDENCnBjaWIxOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4NTAwMC0weDVmZmYNCnBj aWIxOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZmRiMDAwMDAtMHhmZGJmZmZmZg0KcGNpYjE6ICAg cHJlZmV0Y2hlZCBkZWNvZGUgMHhmZGEwMDAwMC0weGZkYWZmZmZmDQpwY2kxOiA8UENJIGJ1cz4g b24gcGNpYjENCnBjaTE6IGRvbWFpbj0wLCBwaHlzaWNhbCBidXM9MQ0KcGNpYjI6IDxQQ0ktUENJ IGJyaWRnZT4gaXJxIDE2IGF0IGRldmljZSAzLjAgb24gcGNpMA0KcGNpYjI6ICAgZG9tYWluICAg ICAgICAgICAgMA0KcGNpYjI6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMg0KcGNpYjI6ICAgc3Vib3Jk aW5hdGUgYnVzICAgMg0KcGNpYjI6ICAgSS9PIGRlY29kZSAgICAgICAgMHhkMDAwLTB4ZGZmZg0K cGNpYjI6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhmODAwMDAwMC0weGZiZmZmZmZmDQpwY2liMjog ICBwcmVmZXRjaGVkIGRlY29kZSAweGQwMDAwMDAwLTB4ZGZmZmZmZmYNCnBjaTI6IDxQQ0kgYnVz PiBvbiBwY2liMg0KcGNpMjogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz0yDQpmb3VuZC0+CXZlbmRv cj0weDEwZGUsIGRldj0weDA1ZTIsIHJldmlkPTB4YTENCglkb21haW49MCwgYnVzPTIsIHNsb3Q9 MCwgZnVuYz0wDQoJY2xhc3M9MDMtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MA0KCWNtZHJl Zz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykNCglsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCglp bnRwaW49YSwgaXJxPTEyDQoJcG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQw DQoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0DQoJbWFwWzEwXTogdHlwZSBNZW1vcnks IHJhbmdlIDMyLCBiYXNlIDB4ZmEwMDAwMDAsIHNpemUgMjQsIGVuYWJsZWQNCnBjaWIyOiByZXF1 ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmEwMDAwMDAtMHhmYWZmZmZmZjogZ29vZA0KCW1hcFsxNF06 IHR5cGUgUHJlZmV0Y2hhYmxlIE1lbW9yeSwgcmFuZ2UgNjQsIGJhc2UgMHhkMDAwMDAwMCwgc2l6 ZSAyOCwgZW5hYmxlZA0KcGNpYjI6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhkMDAwMDAwMC0w eGRmZmZmZmZmOiBnb29kDQoJbWFwWzFjXTogdHlwZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4 ZjgwMDAwMDAsIHNpemUgMjUsIGVuYWJsZWQNCnBjaWIyOiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdl IDB4ZjgwMDAwMDAtMHhmOWZmZmZmZjogZ29vZA0KCW1hcFsyNF06IHR5cGUgSS9PIFBvcnQsIHJh bmdlIDMyLCBiYXNlIDB4ZGYwMCwgc2l6ZSAgNywgZW5hYmxlZA0KcGNpYjI6IHJlcXVlc3RlZCBJ L08gcmFuZ2UgMHhkZjAwLTB4ZGY3ZjogaW4gcmFuZ2UNCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZv ciAwLjMuSU5UQQ0KcGNpYjA6IHNsb3QgMyBJTlRBIGhhcmR3aXJlZCB0byBJUlEgMTYNCnBjaWIy OiBzbG90IDAgSU5UQSBpcyByb3V0ZWQgdG8gaXJxIDE2DQp2Z2FwY2kwOiA8VkdBLWNvbXBhdGli bGUgZGlzcGxheT4gcG9ydCAweGRmMDAtMHhkZjdmIG1lbSAweGZhMDAwMDAwLTB4ZmFmZmZmZmYs MHhkMDAwMDAwMC0weGRmZmZmZmZmLDB4ZjgwMDAwMDAtMHhmOWZmZmZmZiBpcnEgMTYgYXQgZGV2 aWNlIDAuMCBvbiBwY2kyDQpwY2liMzogPFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNl IDUuMCBvbiBwY2kwDQpwY2liMzogICBkb21haW4gICAgICAgICAgICAwDQpwY2liMzogICBzZWNv bmRhcnkgYnVzICAgICAzDQpwY2liMzogICBzdWJvcmRpbmF0ZSBidXMgICAzDQpwY2liMzogICBJ L08gZGVjb2RlICAgICAgICAweGMwMDAtMHhjZmZmDQpwY2liMzogICBtZW1vcnkgZGVjb2RlICAg ICAweGZkOTAwMDAwLTB4ZmQ5ZmZmZmYNCnBjaWIzOiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZmQw MDAwMDAtMHhmZDBmZmZmZg0KcGNpMzogPFBDSSBidXM+IG9uIHBjaWIzDQpwY2kzOiBkb21haW49 MCwgcGh5c2ljYWwgYnVzPTMNCnBjaWI0OiA8UENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZp Y2UgNy4wIG9uIHBjaTANCnBjaWI0OiAgIGRvbWFpbiAgICAgICAgICAgIDANCnBjaWI0OiAgIHNl Y29uZGFyeSBidXMgICAgIDQNCnBjaWI0OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDQNCnBjaWI0OiAg IEkvTyBkZWNvZGUgICAgICAgIDB4NzAwMC0weDdmZmYNCnBjaWI0OiAgIG1lbW9yeSBkZWNvZGUg ICAgIDB4ZmNkMDAwMDAtMHhmY2RmZmZmZg0KcGNpYjQ6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhm ZGUwMDAwMC0weGZkZWZmZmZmDQpwY2k0OiA8UENJIGJ1cz4gb24gcGNpYjQNCnBjaTQ6IGRvbWFp bj0wLCBwaHlzaWNhbCBidXM9NA0KcGNpYjU6IDxQQ0ktUENJIGJyaWRnZT4gaXJxIDE2IGF0IGRl dmljZSA5LjAgb24gcGNpMA0KcGNpYjU6ICAgZG9tYWluICAgICAgICAgICAgMA0KcGNpYjU6ICAg c2Vjb25kYXJ5IGJ1cyAgICAgNQ0KcGNpYjU6ICAgc3Vib3JkaW5hdGUgYnVzICAgNQ0KcGNpYjU6 ICAgSS9PIGRlY29kZSAgICAgICAgMHg2MDAwLTB4NmZmZg0KcGNpYjU6ICAgbWVtb3J5IGRlY29k ZSAgICAgMHhmZGQwMDAwMC0weGZkZGZmZmZmDQpwY2liNTogICBwcmVmZXRjaGVkIGRlY29kZSAw eGZkYzAwMDAwLTB4ZmRjZmZmZmYNCnBjaTU6IDxQQ0kgYnVzPiBvbiBwY2liNQ0KcGNpNTogZG9t YWluPTAsIHBoeXNpY2FsIGJ1cz01DQpwY2kwOiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRlcnJ1cHQg Y29udHJvbGxlcj4gYXQgZGV2aWNlIDE2LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkNCnBjaTA6IDxi YXNlIHBlcmlwaGVyYWwsIGludGVycnVwdCBjb250cm9sbGVyPiBhdCBkZXZpY2UgMTYuMSAobm8g ZHJpdmVyIGF0dGFjaGVkKQ0KcGNpMDogPGJhc2UgcGVyaXBoZXJhbCwgaW50ZXJydXB0IGNvbnRy b2xsZXI+IGF0IGRldmljZSAxNy4wIChubyBkcml2ZXIgYXR0YWNoZWQpDQpwY2kwOiA8YmFzZSBw ZXJpcGhlcmFsLCBpbnRlcnJ1cHQgY29udHJvbGxlcj4gYXQgZGV2aWNlIDE3LjEgKG5vIGRyaXZl ciBhdHRhY2hlZCkNCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWwsIGludGVycnVwdCBjb250cm9sbGVy PiBhdCBkZXZpY2UgMjAuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KcGNpMDogPGJhc2UgcGVyaXBo ZXJhbCwgaW50ZXJydXB0IGNvbnRyb2xsZXI+IGF0IGRldmljZSAyMC4xIChubyBkcml2ZXIgYXR0 YWNoZWQpDQpwY2kwOiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRlcnJ1cHQgY29udHJvbGxlcj4gYXQg ZGV2aWNlIDIwLjIgKG5vIGRyaXZlciBhdHRhY2hlZCkNCnVoY2kwOiA8VUhDSSAoZ2VuZXJpYykg VVNCIGNvbnRyb2xsZXI+IHBvcnQgMHhmZjAwLTB4ZmYxZiBpcnEgMTYgYXQgZGV2aWNlIDI2LjAg b24gcGNpMA0KdWhjaTA6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBh dCAweGZmMDANCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE2IChQQ0kgSVJRIDE2KSB0byB2ZWN0 b3IgNDkNCnVoY2kwOiBbR0lBTlQtTE9DS0VEXQ0KdWhjaTA6IFtJVEhSRUFEXQ0KdXNiMDogPFVI Q0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMA0KdXNiMDogVVNCIHJldmlzaW9u IDEuMA0KdWh1YjA6IDxJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEu MDAsIGFkZHIgMT4gb24gdXNiMA0KdWh1YjA6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkDQp1aGNpMTogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4 ZmUwMC0weGZlMWYgaXJxIDIxIGF0IGRldmljZSAyNi4xIG9uIHBjaTANCnVoY2kxOiBSZXNlcnZl ZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHhmZTAwDQppb2FwaWMwOiByb3V0 aW5nIGludHBpbiAyMSAoUENJIElSUSAyMSkgdG8gdmVjdG9yIDUwDQp1aGNpMTogW0dJQU5ULUxP Q0tFRF0NCnVoY2kxOiBbSVRIUkVBRF0NCnVzYjE6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJv bGxlcj4gb24gdWhjaTENCnVzYjE6IFVTQiByZXZpc2lvbiAxLjANCnVodWIxOiA8SW50ZWwgVUhD SSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjENCnVo dWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KdWhjaTI6IDxVSENJ IChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGZkMDAtMHhmZDFmIGlycSAxOCBhdCBk ZXZpY2UgMjYuMiBvbiBwY2kwDQp1aGNpMjogUmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4 MjAgdHlwZSA0IGF0IDB4ZmQwMA0KaW9hcGljMDogcm91dGluZyBpbnRwaW4gMTggKFBDSSBJUlEg MTgpIHRvIHZlY3RvciA1MQ0KdWhjaTI6IFtHSUFOVC1MT0NLRURdDQp1aGNpMjogW0lUSFJFQURd DQp1c2IyOiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kyDQp1c2IyOiBV U0IgcmV2aXNpb24gMS4wDQp1aHViMjogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwg cmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IyDQp1aHViMjogMiBwb3J0cyB3aXRoIDIgcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQNCmVoY2kwOiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250 cm9sbGVyPiBtZW0gMHhmZGZmZTAwMC0weGZkZmZlM2ZmIGlycSAxOCBhdCBkZXZpY2UgMjYuNyBv biBwY2kwDQplaGNpMDogUmVzZXJ2ZWQgMHg0MDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBh dCAweGZkZmZlMDAwDQplaGNpMDogW0dJQU5ULUxPQ0tFRF0NCmVoY2kwOiBbSVRIUkVBRF0NCnVz YjM6IHdhaXRpbmcgZm9yIEJJT1MgdG8gZ2l2ZSB1cCBjb250cm9sDQp1c2IzOiBFSENJIHZlcnNp b24gMS4wDQp1c2IzOiBjb21wYW5pb24gY29udHJvbGxlcnMsIDIgcG9ydHMgZWFjaDogdXNiMCB1 c2IxIHVzYjINCnVzYjM6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVo Y2kwDQp1c2IzOiBVU0IgcmV2aXNpb24gMi4wDQp1aHViMzogPEludGVsIEVIQ0kgcm9vdCBodWIs IGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IzDQp1aHViMzogNiBwb3J0 cyB3aXRoIDYgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCnBjaTA6IDxtdWx0aW1lZGlhPiBhdCBk ZXZpY2UgMjcuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KcGNpYjY6IDxBQ1BJIFBDSS1QQ0kgYnJp ZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDI4LjAgb24gcGNpMA0KcGNpYjY6ICAgZG9tYWluICAgICAg ICAgICAgMA0KcGNpYjY6ICAgc2Vjb25kYXJ5IGJ1cyAgICAgNg0KcGNpYjY6ICAgc3Vib3JkaW5h dGUgYnVzICAgNg0KcGNpYjY6ICAgSS9PIGRlY29kZSAgICAgICAgMHhiMDAwLTB4YmZmZg0KcGNp YjY6ICAgbWVtb3J5IGRlY29kZSAgICAgMHhmZDgwMDAwMC0weGZkOGZmZmZmDQpwY2liNjogICBw cmVmZXRjaGVkIGRlY29kZSAweGZkNzAwMDAwLTB4ZmQ3ZmZmZmYNCnBjaTY6IDxBQ1BJIFBDSSBi dXM+IG9uIHBjaWI2DQpwY2k2OiBkb21haW49MCwgcGh5c2ljYWwgYnVzPTYNCnBjaWI3OiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gaXJxIDE3IGF0IGRldmljZSAyOC4xIG9uIHBjaTANCnBjaWI3OiAg IGRvbWFpbiAgICAgICAgICAgIDANCnBjaWI3OiAgIHNlY29uZGFyeSBidXMgICAgIDcNCnBjaWI3 OiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDcNCnBjaWI3OiAgIEkvTyBkZWNvZGUgICAgICAgIDB4YTAw MC0weGFmZmYNCnBjaWI3OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZmQ2MDAwMDAtMHhmZDZmZmZm Zg0KcGNpYjc6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhmZDUwMDAwMC0weGZkNWZmZmZmDQpwY2k3 OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNw0KcGNpNzogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz03 DQpmb3VuZC0+CXZlbmRvcj0weDE5N2IsIGRldj0weDIzNjMsIHJldmlkPTB4MDINCglkb21haW49 MCwgYnVzPTcsIHNsb3Q9MCwgZnVuYz0wDQoJY2xhc3M9MDEtMDEtODUsIGhkcnR5cGU9MHgwMCwg bWZkZXY9MA0KCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3 b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9 MHgwMCAoMCBucykNCglpbnRwaW49YSwgaXJxPTEwDQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQw IEQzICBjdXJyZW50IEQwDQoJbWFwWzEwXTogdHlwZSBJL08gUG9ydCwgcmFuZ2UgMzIsIGJhc2Ug MHhhZjAwLCBzaXplICAzLCBlbmFibGVkDQpwY2liNzogcmVxdWVzdGVkIEkvTyByYW5nZSAweGFm MDAtMHhhZjA3OiBpbiByYW5nZQ0KCW1hcFsxNF06IHR5cGUgSS9PIFBvcnQsIHJhbmdlIDMyLCBi YXNlIDB4YWUwMCwgc2l6ZSAgMiwgZW5hYmxlZA0KcGNpYjc6IHJlcXVlc3RlZCBJL08gcmFuZ2Ug MHhhZTAwLTB4YWUwMzogaW4gcmFuZ2UNCgltYXBbMThdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAz MiwgYmFzZSAweGFkMDAsIHNpemUgIDMsIGVuYWJsZWQNCnBjaWI3OiByZXF1ZXN0ZWQgSS9PIHJh bmdlIDB4YWQwMC0weGFkMDc6IGluIHJhbmdlDQoJbWFwWzFjXTogdHlwZSBJL08gUG9ydCwgcmFu Z2UgMzIsIGJhc2UgMHhhYzAwLCBzaXplICAyLCBlbmFibGVkDQpwY2liNzogcmVxdWVzdGVkIEkv TyByYW5nZSAweGFjMDAtMHhhYzAzOiBpbiByYW5nZQ0KCW1hcFsyMF06IHR5cGUgSS9PIFBvcnQs IHJhbmdlIDMyLCBiYXNlIDB4YWIwMCwgc2l6ZSAgNCwgZW5hYmxlZA0KcGNpYjc6IHJlcXVlc3Rl ZCBJL08gcmFuZ2UgMHhhYjAwLTB4YWIwZjogaW4gcmFuZ2UNCgltYXBbMjRdOiB0eXBlIE1lbW9y eSwgcmFuZ2UgMzIsIGJhc2UgMHhmZDZmZTAwMCwgc2l6ZSAxMywgZW5hYmxlZA0KcGNpYjc6IHJl cXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhmZDZmZTAwMC0weGZkNmZmZmZmOiBnb29kDQpwY2liNzog bWF0Y2hlZCBlbnRyeSBmb3IgNy4wLklOVEENCnBjaWI3OiBzbG90IDAgSU5UQSBoYXJkd2lyZWQg dG8gSVJRIDE3DQphdGFwY2kwOiA8Sk1pY3JvbiBKTUIzNjMgU0FUQTMwMCBjb250cm9sbGVyPiBw b3J0IDB4YWYwMC0weGFmMDcsMHhhZTAwLTB4YWUwMywweGFkMDAtMHhhZDA3LDB4YWMwMC0weGFj MDMsMHhhYjAwLTB4YWIwZiBtZW0gMHhmZDZmZTAwMC0weGZkNmZmZmZmIGlycSAxNyBhdCBkZXZp Y2UgMC4wIG9uIHBjaTcNCmF0YXBjaTA6IFJlc2VydmVkIDB4MTAgYnl0ZXMgZm9yIHJpZCAweDIw IHR5cGUgNCBhdCAweGFiMDANCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE3IChQQ0kgSVJRIDE3 KSB0byB2ZWN0b3IgNTINCmF0YXBjaTA6IFtNUFNBRkVdDQphdGFwY2kwOiBbSVRIUkVBRF0NCmF0 YXBjaTA6IFJlc2VydmVkIDB4MjAwMCBieXRlcyBmb3IgcmlkIDB4MjQgdHlwZSAzIGF0IDB4ZmQ2 ZmUwMDANCmF0YXBjaTA6IEFIQ0kgY2FsbGVkIGZyb20gdmVuZG9yIHNwZWNpZmljIGRyaXZlcg0K YXRhcGNpMDogQUhDSSBWZXJzaW9uIDAxLjAwIGNvbnRyb2xsZXIgd2l0aCAyIHBvcnRzIGRldGVj dGVkDQphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMA0KYXRhMjogU0FUQSBjb25uZWN0 IHN0YXR1cz0wMDAwMDAwMA0KYXRhMjogYWhjaV9yZXNldCBkZXZpY2VzPTB4MA0KYXRhMjogW01Q U0FGRV0NCmF0YTI6IFtJVEhSRUFEXQ0KYXRhMzogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAN CmF0YTM6IFNBVEEgY29ubmVjdCBzdGF0dXM9MDAwMDAwMDANCmF0YTM6IGFoY2lfcmVzZXQgZGV2 aWNlcz0weDANCmF0YTM6IFtNUFNBRkVdDQphdGEzOiBbSVRIUkVBRF0NCmF0YTQ6IDxBVEEgY2hh bm5lbCAyPiBvbiBhdGFwY2kwDQphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAw eDEwIHR5cGUgNCBhdCAweGFmMDANCmF0YXBjaTA6IFJlc2VydmVkIDB4NCBieXRlcyBmb3Igcmlk IDB4MTQgdHlwZSA0IGF0IDB4YWUwMA0KYXRhNDogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTYw IG9zdGF0MT03MA0KYXRhNDogc3RhdDA9MHgyMCBlcnI9MHgyMCBsc2I9MHgyMCBtc2I9MHgyMA0K YXRhNDogc3RhdDE9MHgzMCBlcnI9MHgzMCBsc2I9MHgzMCBtc2I9MHgzMA0KYXRhNDogcmVzZXQg dHAyIHN0YXQwPTIwIHN0YXQxPTMwIGRldmljZXM9MHgwDQphdGE0OiBbTVBTQUZFXQ0KYXRhNDog W0lUSFJFQURdDQpwY2liODogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAxNiBhdCBkZXZpY2Ug MjguNCBvbiBwY2kwDQpwY2liODogICBkb21haW4gICAgICAgICAgICAwDQpwY2liODogICBzZWNv bmRhcnkgYnVzICAgICA4DQpwY2liODogICBzdWJvcmRpbmF0ZSBidXMgICA4DQpwY2liODogICBJ L08gZGVjb2RlICAgICAgICAweDkwMDAtMHg5ZmZmDQpwY2liODogICBtZW1vcnkgZGVjb2RlICAg ICAweGZkNDAwMDAwLTB4ZmQ0ZmZmZmYNCnBjaWI4OiAgIHByZWZldGNoZWQgZGVjb2RlIDB4ZmQz MDAwMDAtMHhmZDNmZmZmZg0KcGNpODogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjgNCnBjaTg6IGRv bWFpbj0wLCBwaHlzaWNhbCBidXM9OA0KZm91bmQtPgl2ZW5kb3I9MHgxMGVjLCBkZXY9MHg4MTY4 LCByZXZpZD0weDAzDQoJZG9tYWluPTAsIGJ1cz04LCBzbG90PTAsIGZ1bmM9MA0KCWNsYXNzPTAy LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVnPTB4 MDAxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdu dD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQoJaW50cGluPWEsIGlycT0xMg0KCXBv d2Vyc3BlYyAzICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMA0KCU1TSSBzdXBwb3J0 cyAxIG1lc3NhZ2UsIDY0IGJpdA0KCU1TSS1YIHN1cHBvcnRzIDQgbWVzc2FnZXMgaW4gbWFwIDB4 MjANCgltYXBbMTBdOiB0eXBlIEkvTyBQb3J0LCByYW5nZSAzMiwgYmFzZSAweDllMDAsIHNpemUg IDgsIGVuYWJsZWQNCnBjaWI4OiByZXF1ZXN0ZWQgSS9PIHJhbmdlIDB4OWUwMC0weDllZmY6IGlu IHJhbmdlDQoJbWFwWzE4XTogdHlwZSBQcmVmZXRjaGFibGUgTWVtb3J5LCByYW5nZSA2NCwgYmFz ZSAweGZkM2ZmMDAwLCBzaXplIDEyLCBlbmFibGVkDQpwY2liODogcmVxdWVzdGVkIG1lbW9yeSBy YW5nZSAweGZkM2ZmMDAwLTB4ZmQzZmZmZmY6IGdvb2QNCgltYXBbMjBdOiB0eXBlIFByZWZldGNo YWJsZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZmQzZjgwMDAsIHNpemUgMTQsIGVuYWJsZWQN CnBjaWI4OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmQzZjgwMDAtMHhmZDNmYmZmZjogZ29v ZA0KcGNpYjg6IG1hdGNoZWQgZW50cnkgZm9yIDguMC5JTlRBDQpwY2liODogc2xvdCAwIElOVEEg aGFyZHdpcmVkIHRvIElSUSAxNg0KcmUwOiA8UmVhbFRlayA4MTY4LzgxNjhCLzgxNjhDLzgxNjhD UC84MTY4RC84MTExQi84MTExQy84MTExQ1AgUENJZSBHaWdhYml0IEV0aGVybmV0PiBwb3J0IDB4 OWUwMC0weDllZmYgbWVtIDB4ZmQzZmYwMDAtMHhmZDNmZmZmZiwweGZkM2Y4MDAwLTB4ZmQzZmJm ZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpOA0KcmUwOiBSZXNlcnZlZCAweDEwMDAgYnl0 ZXMgZm9yIHJpZCAweDE4IHR5cGUgMyBhdCAweGZkM2ZmMDAwDQpyZTA6IE1TSSBjb3VudCA6IDEN CnJlMDogQ2hpcCByZXYuIDB4MjgwMDAwMDANCnJlMDogTUFDIHJldi4gMHgwMDEwMDAwMA0KbWlp YnVzMDogPE1JSSBidXM+IG9uIHJlMA0KcmdlcGh5MDogPFJUTDgxNjlTLzgxMTBTLzgyMTFCIG1l ZGlhIGludGVyZmFjZT4gUEhZIDEgb24gbWlpYnVzMA0KcmdlcGh5MDogIDEwYmFzZVQsIDEwYmFz ZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBiYXNlVCwgMTAwMGJhc2VULUZE WCwgYXV0bw0KcmUwOiBicGYgYXR0YWNoZWQNCnJlMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MWY6 ZDA6YWU6NWQ6YTINCnJlMDogW01QU0FGRV0NCnJlMDogW0ZJTFRFUl0NCnBjaWI5OiA8QUNQSSBQ Q0ktUENJIGJyaWRnZT4gaXJxIDE3IGF0IGRldmljZSAyOC41IG9uIHBjaTANCnBjaWI5OiAgIGRv bWFpbiAgICAgICAgICAgIDANCnBjaWI5OiAgIHNlY29uZGFyeSBidXMgICAgIDkNCnBjaWI5OiAg IHN1Ym9yZGluYXRlIGJ1cyAgIDkNCnBjaWI5OiAgIEkvTyBkZWNvZGUgICAgICAgIDB4ODAwMC0w eDhmZmYNCnBjaWI5OiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4ZmQyMDAwMDAtMHhmZDJmZmZmZg0K cGNpYjk6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhmZDEwMDAwMC0weGZkMWZmZmZmDQpwY2k5OiA8 QUNQSSBQQ0kgYnVzPiBvbiBwY2liOQ0KcGNpOTogZG9tYWluPTAsIHBoeXNpY2FsIGJ1cz05DQpm b3VuZC0+CXZlbmRvcj0weDEwZWMsIGRldj0weDgxNjgsIHJldmlkPTB4MDMNCglkb21haW49MCwg YnVzPTksIHNsb3Q9MCwgZnVuYz0wDQoJY2xhc3M9MDItMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZk ZXY9MA0KCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMDEwLCBjYWNoZWxuc3o9MTYgKGR3b3Jk cykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgw MCAoMCBucykNCglpbnRwaW49YSwgaXJxPTEwDQoJcG93ZXJzcGVjIDMgIHN1cHBvcnRzIEQwIEQx IEQyIEQzICBjdXJyZW50IEQwDQoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0DQoJTVNJ LVggc3VwcG9ydHMgNCBtZXNzYWdlcyBpbiBtYXAgMHgyMA0KCW1hcFsxMF06IHR5cGUgSS9PIFBv cnQsIHJhbmdlIDMyLCBiYXNlIDB4OGUwMCwgc2l6ZSAgOCwgZW5hYmxlZA0KcGNpYjk6IHJlcXVl c3RlZCBJL08gcmFuZ2UgMHg4ZTAwLTB4OGVmZjogaW4gcmFuZ2UNCgltYXBbMThdOiB0eXBlIFBy ZWZldGNoYWJsZSBNZW1vcnksIHJhbmdlIDY0LCBiYXNlIDB4ZmQxZmYwMDAsIHNpemUgMTIsIGVu YWJsZWQNCnBjaWI5OiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmQxZmYwMDAtMHhmZDFmZmZm ZjogZ29vZA0KCW1hcFsyMF06IHR5cGUgUHJlZmV0Y2hhYmxlIE1lbW9yeSwgcmFuZ2UgNjQsIGJh c2UgMHhmZDFmODAwMCwgc2l6ZSAxNCwgZW5hYmxlZA0KcGNpYjk6IHJlcXVlc3RlZCBtZW1vcnkg cmFuZ2UgMHhmZDFmODAwMC0weGZkMWZiZmZmOiBnb29kDQpwY2liOTogbWF0Y2hlZCBlbnRyeSBm b3IgOS4wLklOVEENCnBjaWI5OiBzbG90IDAgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE3DQpyZTE6 IDxSZWFsVGVrIDgxNjgvODE2OEIvODE2OEMvODE2OENQLzgxNjhELzgxMTFCLzgxMTFDLzgxMTFD UCBQQ0llIEdpZ2FiaXQgRXRoZXJuZXQ+IHBvcnQgMHg4ZTAwLTB4OGVmZiBtZW0gMHhmZDFmZjAw MC0weGZkMWZmZmZmLDB4ZmQxZjgwMDAtMHhmZDFmYmZmZiBpcnEgMTcgYXQgZGV2aWNlIDAuMCBv biBwY2k5DQpyZTE6IFJlc2VydmVkIDB4MTAwMCBieXRlcyBmb3IgcmlkIDB4MTggdHlwZSAzIGF0 IDB4ZmQxZmYwMDANCnJlMTogTVNJIGNvdW50IDogMQ0KcmUxOiBDaGlwIHJldi4gMHgyODAwMDAw MA0KcmUxOiBNQUMgcmV2LiAweDAwMTAwMDAwDQptaWlidXMxOiA8TUlJIGJ1cz4gb24gcmUxDQpy Z2VwaHkxOiA8UlRMODE2OVMvODExMFMvODIxMUIgbWVkaWEgaW50ZXJmYWNlPiBQSFkgMSBvbiBt aWlidXMxDQpyZ2VwaHkxOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFz ZVRYLUZEWCwgMTAwMGJhc2VULCAxMDAwYmFzZVQtRkRYLCBhdXRvDQpyZTE6IGJwZiBhdHRhY2hl ZA0KcmUxOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoxZjpkMDphZTo1ZDphNA0KcmUxOiBbTVBTQUZF XQ0KcmUxOiBbRklMVEVSXQ0KdWhjaTM6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4g cG9ydCAweGZjMDAtMHhmYzFmIGlycSAyMyBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwDQp1aGNpMzog UmVzZXJ2ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4ZmMwMA0KaW9hcGlj MDogcm91dGluZyBpbnRwaW4gMjMgKFBDSSBJUlEgMjMpIHRvIHZlY3RvciA1Mw0KdWhjaTM6IFtH SUFOVC1MT0NLRURdDQp1aGNpMzogW0lUSFJFQURdDQp1c2I0OiA8VUhDSSAoZ2VuZXJpYykgVVNC IGNvbnRyb2xsZXI+IG9uIHVoY2kzDQp1c2I0OiBVU0IgcmV2aXNpb24gMS4wDQp1aHViNDogPElu dGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1 c2I0DQp1aHViNDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCnVoY2k0 OiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHhmYjAwLTB4ZmIxZiBpcnEg MTkgYXQgZGV2aWNlIDI5LjEgb24gcGNpMA0KdWhjaTQ6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9y IHJpZCAweDIwIHR5cGUgNCBhdCAweGZiMDANCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE5IChQ Q0kgSVJRIDE5KSB0byB2ZWN0b3IgNTQNCnVoY2k0OiBbR0lBTlQtTE9DS0VEXQ0KdWhjaTQ6IFtJ VEhSRUFEXQ0KdXNiNTogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpNA0K dXNiNTogVVNCIHJldmlzaW9uIDEuMA0KdWh1YjU6IDxJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFz cyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiNQ0KdWh1YjU6IDIgcG9ydHMgd2l0 aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQp1aGNpNTogPFVIQ0kgKGdlbmVyaWMpIFVTQiBj b250cm9sbGVyPiBwb3J0IDB4ZmEwMC0weGZhMWYgaXJxIDE4IGF0IGRldmljZSAyOS4yIG9uIHBj aTANCnVoY2k1OiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBlIDQgYXQgMHhm YTAwDQp1aGNpNTogW0dJQU5ULUxPQ0tFRF0NCnVoY2k1OiBbSVRIUkVBRF0NCnVzYjY6IDxVSENJ IChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTUNCnVzYjY6IFVTQiByZXZpc2lvbiAx LjANCnVodWI2OiA8SW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAw LCBhZGRyIDE+IG9uIHVzYjYNCnVodWI2OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYg cG93ZXJlZA0KZWhjaTE6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAw eGZkZmZkMDAwLTB4ZmRmZmQzZmYgaXJxIDIzIGF0IGRldmljZSAyOS43IG9uIHBjaTANCmVoY2kx OiBSZXNlcnZlZCAweDQwMCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZmRmZmQwMDAN CmVoY2kxOiBbR0lBTlQtTE9DS0VEXQ0KZWhjaTE6IFtJVEhSRUFEXQ0KdXNiNzogd2FpdGluZyBm b3IgQklPUyB0byBnaXZlIHVwIGNvbnRyb2wNCnVzYjc6IEVIQ0kgdmVyc2lvbiAxLjANCnVzYjc6 IGNvbXBhbmlvbiBjb250cm9sbGVycywgMiBwb3J0cyBlYWNoOiB1c2I0IHVzYjUgdXNiNg0KdXNi NzogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4gb24gZWhjaTENCnVzYjc6IFVT QiByZXZpc2lvbiAyLjANCnVodWI3OiA8SW50ZWwgRUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCBy ZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjcNCnVodWI3OiA2IHBvcnRzIHdpdGggNiByZW1v dmFibGUsIHNlbGYgcG93ZXJlZA0KdW1hc3MwOiA8S2luZ3N0b24gRGF0YVRyYXZlbGVyIDIuMCwg Y2xhc3MgMC8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDI+IG9uIHVodWI3DQp1bWFzczA6MDowOi0x OiBBdHRhY2hlZCB0byBzY2J1czANCnBjaWIxMDogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRl dmljZSAzMC4wIG9uIHBjaTANCnBjaWIxMDogICBkb21haW4gICAgICAgICAgICAwDQpwY2liMTA6 ICAgc2Vjb25kYXJ5IGJ1cyAgICAgMTANCnBjaWIxMDogICBzdWJvcmRpbmF0ZSBidXMgICAxMA0K cGNpYjEwOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4ZTAwMC0weGVmZmYNCnBjaWIxMDogICBtZW1v cnkgZGVjb2RlICAgICAweGZjZjAwMDAwLTB4ZmNmZmZmZmYNCnBjaWIxMDogICBwcmVmZXRjaGVk IGRlY29kZSAweGZjZTAwMDAwLTB4ZmNlZmZmZmYNCnBjaWIxMDogICBTdWJ0cmFjdGl2ZWx5IGRl Y29kZWQgYnJpZGdlLg0KcGNpMTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxMA0KcGNpMTA6IGRv bWFpbj0wLCBwaHlzaWNhbCBidXM9MTANCmZvdW5kLT4JdmVuZG9yPTB4MTA0YywgZGV2PTB4ODAy NCwgcmV2aWQ9MHgwMA0KCWRvbWFpbj0wLCBidXM9MTAsIHNsb3Q9NiwgZnVuYz0wDQoJY2xhc3M9 MGMtMDAtMTAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MA0KCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9 MHgwMjEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykNCglsYXR0aW1lcj0weDAyICg2MCBucyksIG1p bmdudD0weDAyICg1MDAgbnMpLCBtYXhsYXQ9MHgwNCAoMTAwMCBucykNCglpbnRwaW49YSwgaXJx PTcNCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDANCgltYXBb MTBdOiB0eXBlIE1lbW9yeSwgcmFuZ2UgMzIsIGJhc2UgMHhmY2ZmZjAwMCwgc2l6ZSAxMSwgZW5h YmxlZA0KcGNpYjEwOiByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZmNmZmYwMDAtMHhmY2ZmZjdm ZjogZ29vZA0KCW1hcFsxNF06IHR5cGUgTWVtb3J5LCByYW5nZSAzMiwgYmFzZSAweGZjZmY4MDAw LCBzaXplIDE0LCBlbmFibGVkDQpwY2liMTA6IHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhmY2Zm ODAwMC0weGZjZmZiZmZmOiBnb29kDQpwY2liMTA6IG1hdGNoZWQgZW50cnkgZm9yIDEwLjYuSU5U QQ0KcGNpYjEwOiBzbG90IDYgSU5UQSBoYXJkd2lyZWQgdG8gSVJRIDE4DQpmd29oY2kwOiA8VGV4 YXMgSW5zdHJ1bWVudHMgVFNCNDNBQjIzPiBtZW0gMHhmY2ZmZjAwMC0weGZjZmZmN2ZmLDB4ZmNm ZjgwMDAtMHhmY2ZmYmZmZiBpcnEgMTggYXQgZGV2aWNlIDYuMCBvbiBwY2kxMA0KZndvaGNpMDog UmVzZXJ2ZWQgMHg4MDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGZjZmZmMDAwDQpm d29oY2kwOiBbTVBTQUZFXQ0KZndvaGNpMDogW0ZJTFRFUl0NCmZ3b2hjaTA6IE9IQ0kgdmVyc2lv biAxLjEwIChST009MCkNCmZ3b2hjaTA6IE5vLiBvZiBJc29jaHJvbm91cyBjaGFubmVscyBpcyA0 Lg0KZndvaGNpMDogRVVJNjQgMDA6YWI6ODg6OWE6MDA6MDA6MWY6ZDANCmZ3b2hjaTA6IFBoeSAx Mzk0YSBhdmFpbGFibGUgUzQwMCwgMyBwb3J0cy4NCmZ3b2hjaTA6IExpbmsgUzQwMCwgbWF4X3Jl YyAyMDQ4IGJ5dGVzLg0KZmlyZXdpcmUwOiA8SUVFRTEzOTQoRmlyZVdpcmUpIGJ1cz4gb24gZndv aGNpMA0KZGNvbnNfY3JvbTA6IDxkY29ucyBjb25maWd1cmF0aW9uIFJPTT4gb24gZmlyZXdpcmUw DQpkY29uc19jcm9tMDogYnVzX2FkZHIgMHgxMTRjMDAwDQpmd2UwOiA8RXRoZXJuZXQgb3ZlciBG aXJlV2lyZT4gb24gZmlyZXdpcmUwDQppZl9md2UwOiBGYWtlIEV0aGVybmV0IGFkZHJlc3M6IDAy OmFiOjg4OjAwOjFmOmQwDQpmd2UwOiBicGYgYXR0YWNoZWQNCmZ3ZTA6IEV0aGVybmV0IGFkZHJl c3M6IDAyOmFiOjg4OjAwOjFmOmQwDQpmd2lwMDogPElQIG92ZXIgRmlyZVdpcmU+IG9uIGZpcmV3 aXJlMA0KZndpcDA6IGJwZiBhdHRhY2hlZA0KZndpcDA6IEZpcmV3aXJlIGFkZHJlc3M6IDAwOmFi Ojg4OjlhOjAwOjAwOjFmOmQwIEAgMHhmZmZlMDAwMDAwMDAsIFM0MDAsIG1heHJlYyAyMDQ4DQpz YnAwOiA8U0JQLTIvU0NTSSBvdmVyIEZpcmVXaXJlPiBvbiBmaXJld2lyZTANCmZ3b2hjaTA6IElu aXRpYXRlIGJ1cyByZXNldA0KZndvaGNpMDogQlVTIHJlc2V0DQpmd29oY2kwOiBub2RlX2lkPTB4 YzgwMGZmYzAsIGdlbj0xLCBDWUNMRU1BU1RFUiBtb2RlDQppc2FiMDogPFBDSS1JU0EgYnJpZGdl PiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwDQppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjANCmF0YXBj aTE6IDxJbnRlbCBBVEEgY29udHJvbGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3MC0w eDE3NywweDM3NiwweGY5MDAtMHhmOTBmLDB4ZjgwMC0weGY4MGYgYXQgZGV2aWNlIDMxLjIgb24g cGNpMA0KYXRhcGNpMTogUmVzZXJ2ZWQgMHgxMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0 IDB4ZjkwMA0KYXRhMDogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTENCmF0YXBjaTE6IFJlc2Vy dmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4MWYwDQphdGFwY2kxOiBSZXNl cnZlZCAweDEgYnl0ZXMgZm9yIHJpZCAweDE0IHR5cGUgNCBhdCAweDNmNg0KYXRhMDogcmVzZXQg dHAxIG1hc2s9MDMgb3N0YXQwPTdmIG9zdGF0MT03Zg0KYXRhMDogc3RhdDA9MHg3ZiBlcnI9MHhm ZiBsc2I9MHhmZiBtc2I9MHhmZg0KYXRhMDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBt c2I9MHhmZg0KYXRhMDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZg0KYXRh MDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZg0KYXRhMDogc3RhdDA9MHg3 ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZg0KYXRhMDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBs c2I9MHhmZiBtc2I9MHhmZg0KYXRhMDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9 MHhmZg0KYXRhMDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZg0KYXRhMDog c3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZg0KYXRhMDogc3RhdDA9MHg3ZiBl cnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZg0KYXRhMDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9 MHhmZiBtc2I9MHhmZg0KYXRhMDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhm Zg0KYXRhMDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZg0KYXRhMDogc3Rh dDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZg0KYXRhMDogc3RhdDA9MHg3ZiBlcnI9 MHhmZiBsc2I9MHhmZiBtc2I9MHhmZg0KYXRhMDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhm ZiBtc2I9MHhmZg0KYXRhMDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZg0K YXRhMDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZg0KYXRhMDogc3RhdDA9 MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZg0KYXRhMDogc3RhdDA9MHg3ZiBlcnI9MHhm ZiBsc2I9MHhmZiBtc2I9MHhmZg0KYXRhMDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBt c2I9MHhmZg0KYXRhMDogc3RhdDA9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZg0KYXRh MDogc3RhdDE9MHg3ZiBlcnI9MHhmZiBsc2I9MHhmZiBtc2I9MHhmZg0KYXRhMDogcmVzZXQgdHAy IHN0YXQwPWZmIHN0YXQxPWZmIGRldmljZXM9MHgwDQppb2FwaWMwOiByb3V0aW5nIGludHBpbiAx NCAoSVNBIElSUSAxNCkgdG8gdmVjdG9yIDU1DQphdGEwOiBbTVBTQUZFXQ0KYXRhMDogW0lUSFJF QURdDQphdGExOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRhcGNpMQ0KYXRhcGNpMTogUmVzZXJ2ZWQg MHg4IGJ5dGVzIGZvciByaWQgMHgxOCB0eXBlIDQgYXQgMHgxNzANCmF0YXBjaTE6IFJlc2VydmVk IDB4MSBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4Mzc2DQphdGExOiByZXNldCB0cDEg bWFzaz0wMyBvc3RhdDA9MDAgb3N0YXQxPTUwDQphdGExOiBzdGF0MD0weDAwIGVycj0weDAxIGxz Yj0weDE0IG1zYj0weGViDQphdGExOiBzdGF0MT0weDUwIGVycj0weDAxIGxzYj0weDAwIG1zYj0w eDAwDQphdGExOiByZXNldCB0cDIgc3RhdDA9MDAgc3RhdDE9NTAgZGV2aWNlcz0weDY8QVRBUElf TUFTVEVSLEFUQV9TTEFWRT4NCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDE1IChJU0EgSVJRIDE1 KSB0byB2ZWN0b3IgNTYNCmF0YTE6IFtNUFNBRkVdDQphdGExOiBbSVRIUkVBRF0NCnBjaTA6IDxz ZXJpYWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkNCmF0 YXBjaTI6IDxJbnRlbCBBVEEgY29udHJvbGxlcj4gcG9ydCAweGY2MDAtMHhmNjA3LDB4ZjUwMC0w eGY1MDMsMHhmNDAwLTB4ZjQwNywweGYzMDAtMHhmMzAzLDB4ZjIwMC0weGYyMGYsMHhmMTAwLTB4 ZjEwZiBpcnEgMTkgYXQgZGV2aWNlIDMxLjUgb24gcGNpMA0KYXRhcGNpMjogUmVzZXJ2ZWQgMHgx MCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4ZjIwMA0KYXRhcGNpMjogW01QU0FGRV0N CmF0YXBjaTI6IFtJVEhSRUFEXQ0KYXRhNTogPEFUQSBjaGFubmVsIDA+IG9uIGF0YXBjaTINCmF0 YXBjaTI6IFJlc2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSA0IGF0IDB4ZjYwMA0K YXRhcGNpMjogUmVzZXJ2ZWQgMHg0IGJ5dGVzIGZvciByaWQgMHgxNCB0eXBlIDQgYXQgMHhmNTAw DQphdGE1OiByZXNldCB0cDEgbWFzaz0wMyBvc3RhdDA9N2Ygb3N0YXQxPTdmDQphdGE1OiBzdGF0 MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmDQphdGE1OiBzdGF0MD0weDdmIGVycj0w eGZmIGxzYj0weGZmIG1zYj0weGZmDQphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZm IG1zYj0weGZmDQphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmDQph dGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmDQphdGE1OiBzdGF0MD0w eDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmDQphdGE1OiBzdGF0MD0weDdmIGVycj0weGZm IGxzYj0weGZmIG1zYj0weGZmDQphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1z Yj0weGZmDQphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmDQphdGE1 OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmDQphdGE1OiBzdGF0MD0weDdm IGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmDQphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxz Yj0weGZmIG1zYj0weGZmDQphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0w eGZmDQphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmDQphdGE1OiBz dGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmDQphdGE1OiBzdGF0MD0weDdmIGVy cj0weGZmIGxzYj0weGZmIG1zYj0weGZmDQphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0w eGZmIG1zYj0weGZmDQphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZm DQphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmDQphdGE1OiBzdGF0 MD0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmDQphdGE1OiBzdGF0MD0weDdmIGVycj0w eGZmIGxzYj0weGZmIG1zYj0weGZmDQphdGE1OiBzdGF0MD0weDdmIGVycj0weGZmIGxzYj0weGZm IG1zYj0weGZmDQphdGE1OiBzdGF0MT0weDdmIGVycj0weGZmIGxzYj0weGZmIG1zYj0weGZmDQph dGE1OiByZXNldCB0cDIgc3RhdDA9ZmYgc3RhdDE9ZmYgZGV2aWNlcz0weDANCmF0YTU6IFtNUFNB RkVdDQphdGE1OiBbSVRIUkVBRF0NCmF0YTY6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kyDQph dGFwY2kyOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDE4IHR5cGUgNCBhdCAweGY0MDAN CmF0YXBjaTI6IFJlc2VydmVkIDB4NCBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4ZjMw MA0KYXRhNjogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTUwIG9zdGF0MT0wMA0KYXRhNjogc3Rh dDA9MHg1MCBlcnI9MHgwMSBsc2I9MHgwMCBtc2I9MHgwMA0KYXRhNjogc3RhdDE9MHgwMCBlcnI9 MHgwMSBsc2I9MHgwMCBtc2I9MHgwMA0KYXRhNjogcmVzZXQgdHAyIHN0YXQwPTUwIHN0YXQxPTAw IGRldmljZXM9MHgxPEFUQV9NQVNURVI+DQphdGE2OiBbTVBTQUZFXQ0KYXRhNjogW0lUSFJFQURd DQpmZGMwOiA8ZmxvcHB5IGRyaXZlIGNvbnRyb2xsZXI+IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcg aXJxIDYgZHJxIDIgb24gYWNwaTANCmZkYzA6IGljX3R5cGUgOTAgcGFydF9pZCA4MA0KaW9hcGlj MDogcm91dGluZyBpbnRwaW4gNiAoSVNBIElSUSA2KSB0byB2ZWN0b3IgNTcNCmZkYzA6IFtGSUxU RVJdDQpjcHUwOiA8QUNQSSBDUFU+IG9uIGFjcGkwDQplc3QwOiA8RW5oYW5jZWQgU3BlZWRTdGVw IEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUwDQplc3QwOiBJbnZhbGlkIGlkMTYgKHNldCwgY3Vy KSA9ICgyMCwgMjEpDQplc3QwOiBJbnZhbGlkIGZyZXEgMjY2MCwgaWdub3JlZC4NCmVzdDA6IElu dmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE5LCAyMSkNCmVzdDA6IEludmFsaWQgZnJlcSAyNTI3 LCBpZ25vcmVkLg0KZXN0MDogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTgsIDIxKQ0KZXN0 MDogSW52YWxpZCBmcmVxIDIzOTQsIGlnbm9yZWQuDQplc3QwOiBJbnZhbGlkIGlkMTYgKHNldCwg Y3VyKSA9ICgxNywgMjEpDQplc3QwOiBJbnZhbGlkIGZyZXEgMjI2MSwgaWdub3JlZC4NCmVzdDA6 IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE2LCAyMSkNCmVzdDA6IEludmFsaWQgZnJlcSAy MTI4LCBpZ25vcmVkLg0KZXN0MDogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTUsIDIxKQ0K ZXN0MDogSW52YWxpZCBmcmVxIDE5OTUsIGlnbm9yZWQuDQplc3QwOiBJbnZhbGlkIGlkMTYgKHNl dCwgY3VyKSA9ICgxNCwgMjEpDQplc3QwOiBJbnZhbGlkIGZyZXEgMTg2MiwgaWdub3JlZC4NCmVz dDA6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDEzLCAyMSkNCmVzdDA6IEludmFsaWQgZnJl cSAxNzI5LCBpZ25vcmVkLg0KZXN0MDogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTIsIDIx KQ0KZXN0MDogSW52YWxpZCBmcmVxIDE1OTYsIGlnbm9yZWQuDQpwNHRjYzA6IDxDUFUgRnJlcXVl bmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1MA0KY3B1MTogPEFDUEkgQ1BVPiBvbiBhY3BpMA0K ZXN0MTogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MQ0KZXN0 MTogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMjAsIDIxKQ0KZXN0MTogSW52YWxpZCBmcmVx IDI2NjAsIGlnbm9yZWQuDQplc3QxOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxOSwgMjEp DQplc3QxOiBJbnZhbGlkIGZyZXEgMjUyNywgaWdub3JlZC4NCmVzdDE6IEludmFsaWQgaWQxNiAo c2V0LCBjdXIpID0gKDE4LCAyMSkNCmVzdDE6IEludmFsaWQgZnJlcSAyMzk0LCBpZ25vcmVkLg0K ZXN0MTogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTcsIDIxKQ0KZXN0MTogSW52YWxpZCBm cmVxIDIyNjEsIGlnbm9yZWQuDQplc3QxOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNiwg MjEpDQplc3QxOiBJbnZhbGlkIGZyZXEgMjEyOCwgaWdub3JlZC4NCmVzdDE6IEludmFsaWQgaWQx NiAoc2V0LCBjdXIpID0gKDE1LCAyMSkNCmVzdDE6IEludmFsaWQgZnJlcSAxOTk1LCBpZ25vcmVk Lg0KZXN0MTogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTQsIDIxKQ0KZXN0MTogSW52YWxp ZCBmcmVxIDE4NjIsIGlnbm9yZWQuDQplc3QxOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgx MywgMjEpDQplc3QxOiBJbnZhbGlkIGZyZXEgMTcyOSwgaWdub3JlZC4NCmVzdDE6IEludmFsaWQg aWQxNiAoc2V0LCBjdXIpID0gKDEyLCAyMSkNCmVzdDE6IEludmFsaWQgZnJlcSAxNTk2LCBpZ25v cmVkLg0KcDR0Y2MxOiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTENCmNw dTI6IDxBQ1BJIENQVT4gb24gYWNwaTANCmVzdDI6IDxFbmhhbmNlZCBTcGVlZFN0ZXAgRnJlcXVl bmN5IENvbnRyb2w+IG9uIGNwdTINCmVzdDI6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDIw LCAyMSkNCmVzdDI6IEludmFsaWQgZnJlcSAyNjYwLCBpZ25vcmVkLg0KZXN0MjogSW52YWxpZCBp ZDE2IChzZXQsIGN1cikgPSAoMTksIDIxKQ0KZXN0MjogSW52YWxpZCBmcmVxIDI1MjcsIGlnbm9y ZWQuDQplc3QyOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxOCwgMjEpDQplc3QyOiBJbnZh bGlkIGZyZXEgMjM5NCwgaWdub3JlZC4NCmVzdDI6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0g KDE3LCAyMSkNCmVzdDI6IEludmFsaWQgZnJlcSAyMjYxLCBpZ25vcmVkLg0KZXN0MjogSW52YWxp ZCBpZDE2IChzZXQsIGN1cikgPSAoMTYsIDIxKQ0KZXN0MjogSW52YWxpZCBmcmVxIDIxMjgsIGln bm9yZWQuDQplc3QyOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNSwgMjEpDQplc3QyOiBJ bnZhbGlkIGZyZXEgMTk5NSwgaWdub3JlZC4NCmVzdDI6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIp ID0gKDE0LCAyMSkNCmVzdDI6IEludmFsaWQgZnJlcSAxODYyLCBpZ25vcmVkLg0KZXN0MjogSW52 YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTMsIDIxKQ0KZXN0MjogSW52YWxpZCBmcmVxIDE3Mjks IGlnbm9yZWQuDQplc3QyOiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxMiwgMjEpDQplc3Qy OiBJbnZhbGlkIGZyZXEgMTU5NiwgaWdub3JlZC4NCnA0dGNjMjogPENQVSBGcmVxdWVuY3kgVGhl cm1hbCBDb250cm9sPiBvbiBjcHUyDQpjcHUzOiA8QUNQSSBDUFU+IG9uIGFjcGkwDQplc3QzOiA8 RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBvbiBjcHUzDQplc3QzOiBJbnZh bGlkIGlkMTYgKHNldCwgY3VyKSA9ICgyMCwgMjEpDQplc3QzOiBJbnZhbGlkIGZyZXEgMjY2MCwg aWdub3JlZC4NCmVzdDM6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE5LCAyMSkNCmVzdDM6 IEludmFsaWQgZnJlcSAyNTI3LCBpZ25vcmVkLg0KZXN0MzogSW52YWxpZCBpZDE2IChzZXQsIGN1 cikgPSAoMTgsIDIxKQ0KZXN0MzogSW52YWxpZCBmcmVxIDIzOTQsIGlnbm9yZWQuDQplc3QzOiBJ bnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNywgMjEpDQplc3QzOiBJbnZhbGlkIGZyZXEgMjI2 MSwgaWdub3JlZC4NCmVzdDM6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE2LCAyMSkNCmVz dDM6IEludmFsaWQgZnJlcSAyMTI4LCBpZ25vcmVkLg0KZXN0MzogSW52YWxpZCBpZDE2IChzZXQs IGN1cikgPSAoMTUsIDIxKQ0KZXN0MzogSW52YWxpZCBmcmVxIDE5OTUsIGlnbm9yZWQuDQplc3Qz OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNCwgMjEpDQplc3QzOiBJbnZhbGlkIGZyZXEg MTg2MiwgaWdub3JlZC4NCmVzdDM6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDEzLCAyMSkN CmVzdDM6IEludmFsaWQgZnJlcSAxNzI5LCBpZ25vcmVkLg0KZXN0MzogSW52YWxpZCBpZDE2IChz ZXQsIGN1cikgPSAoMTIsIDIxKQ0KZXN0MzogSW52YWxpZCBmcmVxIDE1OTYsIGlnbm9yZWQuDQpw NHRjYzM6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4gb24gY3B1Mw0KY3B1NDogPEFD UEkgQ1BVPiBvbiBhY3BpMA0KZXN0NDogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29u dHJvbD4gb24gY3B1NA0KZXN0NDogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMjAsIDIxKQ0K ZXN0NDogSW52YWxpZCBmcmVxIDI2NjAsIGlnbm9yZWQuDQplc3Q0OiBJbnZhbGlkIGlkMTYgKHNl dCwgY3VyKSA9ICgxOSwgMjEpDQplc3Q0OiBJbnZhbGlkIGZyZXEgMjUyNywgaWdub3JlZC4NCmVz dDQ6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE4LCAyMSkNCmVzdDQ6IEludmFsaWQgZnJl cSAyMzk0LCBpZ25vcmVkLg0KZXN0NDogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTcsIDIx KQ0KZXN0NDogSW52YWxpZCBmcmVxIDIyNjEsIGlnbm9yZWQuDQplc3Q0OiBJbnZhbGlkIGlkMTYg KHNldCwgY3VyKSA9ICgxNiwgMjEpDQplc3Q0OiBJbnZhbGlkIGZyZXEgMjEyOCwgaWdub3JlZC4N CmVzdDQ6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE1LCAyMSkNCmVzdDQ6IEludmFsaWQg ZnJlcSAxOTk1LCBpZ25vcmVkLg0KZXN0NDogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTQs IDIxKQ0KZXN0NDogSW52YWxpZCBmcmVxIDE4NjIsIGlnbm9yZWQuDQplc3Q0OiBJbnZhbGlkIGlk MTYgKHNldCwgY3VyKSA9ICgxMywgMjEpDQplc3Q0OiBJbnZhbGlkIGZyZXEgMTcyOSwgaWdub3Jl ZC4NCmVzdDQ6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDEyLCAyMSkNCmVzdDQ6IEludmFs aWQgZnJlcSAxNTk2LCBpZ25vcmVkLg0KcDR0Y2M0OiA8Q1BVIEZyZXF1ZW5jeSBUaGVybWFsIENv bnRyb2w+IG9uIGNwdTQNCmNwdTU6IDxBQ1BJIENQVT4gb24gYWNwaTANCmVzdDU6IDxFbmhhbmNl ZCBTcGVlZFN0ZXAgRnJlcXVlbmN5IENvbnRyb2w+IG9uIGNwdTUNCmVzdDU6IEludmFsaWQgaWQx NiAoc2V0LCBjdXIpID0gKDIwLCAyMSkNCmVzdDU6IEludmFsaWQgZnJlcSAyNjYwLCBpZ25vcmVk Lg0KZXN0NTogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTksIDIxKQ0KZXN0NTogSW52YWxp ZCBmcmVxIDI1MjcsIGlnbm9yZWQuDQplc3Q1OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgx OCwgMjEpDQplc3Q1OiBJbnZhbGlkIGZyZXEgMjM5NCwgaWdub3JlZC4NCmVzdDU6IEludmFsaWQg aWQxNiAoc2V0LCBjdXIpID0gKDE3LCAyMSkNCmVzdDU6IEludmFsaWQgZnJlcSAyMjYxLCBpZ25v cmVkLg0KZXN0NTogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTYsIDIxKQ0KZXN0NTogSW52 YWxpZCBmcmVxIDIxMjgsIGlnbm9yZWQuDQplc3Q1OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9 ICgxNSwgMjEpDQplc3Q1OiBJbnZhbGlkIGZyZXEgMTk5NSwgaWdub3JlZC4NCmVzdDU6IEludmFs aWQgaWQxNiAoc2V0LCBjdXIpID0gKDE0LCAyMSkNCmVzdDU6IEludmFsaWQgZnJlcSAxODYyLCBp Z25vcmVkLg0KZXN0NTogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTMsIDIxKQ0KZXN0NTog SW52YWxpZCBmcmVxIDE3MjksIGlnbm9yZWQuDQplc3Q1OiBJbnZhbGlkIGlkMTYgKHNldCwgY3Vy KSA9ICgxMiwgMjEpDQplc3Q1OiBJbnZhbGlkIGZyZXEgMTU5NiwgaWdub3JlZC4NCnA0dGNjNTog PENQVSBGcmVxdWVuY3kgVGhlcm1hbCBDb250cm9sPiBvbiBjcHU1DQpjcHU2OiA8QUNQSSBDUFU+ IG9uIGFjcGkwDQplc3Q2OiA8RW5oYW5jZWQgU3BlZWRTdGVwIEZyZXF1ZW5jeSBDb250cm9sPiBv biBjcHU2DQplc3Q2OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgyMCwgMjEpDQplc3Q2OiBJ bnZhbGlkIGZyZXEgMjY2MCwgaWdub3JlZC4NCmVzdDY6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIp ID0gKDE5LCAyMSkNCmVzdDY6IEludmFsaWQgZnJlcSAyNTI3LCBpZ25vcmVkLg0KZXN0NjogSW52 YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTgsIDIxKQ0KZXN0NjogSW52YWxpZCBmcmVxIDIzOTQs IGlnbm9yZWQuDQplc3Q2OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNywgMjEpDQplc3Q2 OiBJbnZhbGlkIGZyZXEgMjI2MSwgaWdub3JlZC4NCmVzdDY6IEludmFsaWQgaWQxNiAoc2V0LCBj dXIpID0gKDE2LCAyMSkNCmVzdDY6IEludmFsaWQgZnJlcSAyMTI4LCBpZ25vcmVkLg0KZXN0Njog SW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTUsIDIxKQ0KZXN0NjogSW52YWxpZCBmcmVxIDE5 OTUsIGlnbm9yZWQuDQplc3Q2OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNCwgMjEpDQpl c3Q2OiBJbnZhbGlkIGZyZXEgMTg2MiwgaWdub3JlZC4NCmVzdDY6IEludmFsaWQgaWQxNiAoc2V0 LCBjdXIpID0gKDEzLCAyMSkNCmVzdDY6IEludmFsaWQgZnJlcSAxNzI5LCBpZ25vcmVkLg0KZXN0 NjogSW52YWxpZCBpZDE2IChzZXQsIGN1cikgPSAoMTIsIDIxKQ0KZXN0NjogSW52YWxpZCBmcmVx IDE1OTYsIGlnbm9yZWQuDQpwNHRjYzY6IDxDUFUgRnJlcXVlbmN5IFRoZXJtYWwgQ29udHJvbD4g b24gY3B1Ng0KY3B1NzogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KZXN0NzogPEVuaGFuY2VkIFNwZWVk U3RlcCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1Nw0KZXN0NzogSW52YWxpZCBpZDE2IChzZXQs IGN1cikgPSAoMjAsIDIxKQ0KZXN0NzogSW52YWxpZCBmcmVxIDI2NjAsIGlnbm9yZWQuDQplc3Q3 OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxOSwgMjEpDQplc3Q3OiBJbnZhbGlkIGZyZXEg MjUyNywgaWdub3JlZC4NCmVzdDc6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE4LCAyMSkN CmVzdDc6IEludmFsaWQgZnJlcSAyMzk0LCBpZ25vcmVkLg0KZXN0NzogSW52YWxpZCBpZDE2IChz ZXQsIGN1cikgPSAoMTcsIDIxKQ0KZXN0NzogSW52YWxpZCBmcmVxIDIyNjEsIGlnbm9yZWQuDQpl c3Q3OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxNiwgMjEpDQplc3Q3OiBJbnZhbGlkIGZy ZXEgMjEyOCwgaWdub3JlZC4NCmVzdDc6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDE1LCAy MSkNCmVzdDc6IEludmFsaWQgZnJlcSAxOTk1LCBpZ25vcmVkLg0KZXN0NzogSW52YWxpZCBpZDE2 IChzZXQsIGN1cikgPSAoMTQsIDIxKQ0KZXN0NzogSW52YWxpZCBmcmVxIDE4NjIsIGlnbm9yZWQu DQplc3Q3OiBJbnZhbGlkIGlkMTYgKHNldCwgY3VyKSA9ICgxMywgMjEpDQplc3Q3OiBJbnZhbGlk IGZyZXEgMTcyOSwgaWdub3JlZC4NCmVzdDc6IEludmFsaWQgaWQxNiAoc2V0LCBjdXIpID0gKDEy LCAyMSkNCmVzdDc6IEludmFsaWQgZnJlcSAxNTk2LCBpZ25vcmVkLg0KcDR0Y2M3OiA8Q1BVIEZy ZXF1ZW5jeSBUaGVybWFsIENvbnRyb2w+IG9uIGNwdTcNCmV4X2lzYV9pZGVudGlmeSgpDQpmZGM6 IGZkYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0DQphaGNfaXNhX3Byb2JlIDEwOiBpb3Bv cnQgMHhhYzAwIGFsbG9jIGZhaWxlZA0Kc2M6IHNjMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcg aXQNCnZnYTogdmdhMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQNCmlzYV9wcm9iZV9jaGls ZHJlbjogZGlzYWJsaW5nIFBuUCBkZXZpY2VzDQppc2FfcHJvYmVfY2hpbGRyZW46IHByb2Jpbmcg bm9uLVBuUCBkZXZpY2VzDQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBh dCBwb3J0IDB4NjAsMHg2NCBvbiBpc2EwDQphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24g YXRrYmRjMA0Ka2JkMCBhdCBhdGtiZDANCmtiZDA6IGF0a2JkMCwgZ2VuZXJpYyAoMCksIGNvbmZp ZzoweDAsIGZsYWdzOjB4M2YwMDAwDQppb2FwaWMwOiByb3V0aW5nIGludHBpbiAxIChJU0EgSVJR IDEpIHRvIHZlY3RvciA1OA0KYXRrYmQwOiBbR0lBTlQtTE9DS0VEXQ0KYXRrYmQwOiBbSVRIUkVB RF0NCnBzbTA6IGN1cnJlbnQgY29tbWFuZCBieXRlOjAwNDcNCnBzbTA6IHN0cmFuZ2UgcmVzdWx0 IGZvciB0ZXN0IGF1eCBwb3J0ICgxKS4NCnBzbTA6IGZhaWxlZCB0byByZXNldCB0aGUgYXV4IGRl dmljZS4NCnBwYzA6IGNhbm5vdCByZXNlcnZlIEkvTyBwb3J0IHJhbmdlDQpwcGMwOiA8UGFyYWxs ZWwgcG9ydD4gZmFpbGVkIHRvIHByb2JlIGF0IGlycSA3IG9uIGlzYTANCnNjMDogPFN5c3RlbSBj b25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwDQpzYzA6IFZHQSA8MTYgdmlydHVhbCBjb25z b2xlcywgZmxhZ3M9MHgzMDA+DQpzYzA6IGZiMCwga2JkMSwgdGVybWluYWwgZW11bGF0b3I6IHNj IChzeXNjb25zIHRlcm1pbmFsKQ0Kc2lvMDogY29uZmlndXJlZCBpcnEgNCBub3QgaW4gYml0bWFw IG9mIHByb2JlZCBpcnFzIDANCnNpbzA6IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVkDQpzaW8wOiBp cnEgbWFwczogMCAwIDAgMA0Kc2lvMDogcHJvYmUgZmFpbGVkIHRlc3Qocyk6IDAgMSAyIDQgNiA3 IDkNCnNpbzA6IGNvbmZpZ3VyZWQgaXJxIDQgbm90IGluIGJpdG1hcCBvZiBwcm9iZWQgaXJxcyAw DQpzaW8wOiBwb3J0IG1heSBub3QgYmUgZW5hYmxlZA0Kc2lvMDogaXJxIG1hcHM6IDAgMCAwIDAN CnNpbzA6IHByb2JlIGZhaWxlZCB0ZXN0KHMpOiAwIDEgMiA0IDYgNyA5DQpzaW8wIGF0IHBvcnQg MHgzZjgtMHgzZmYgaXJxIDQgZmxhZ3MgMHgxMCBvbiBpc2EwDQpzaW8wOiB0eXBlIDgyNTAgb3Ig bm90IHJlc3BvbmRpbmcNCmlvYXBpYzA6IHJvdXRpbmcgaW50cGluIDQgKElTQSBJUlEgNCkgdG8g dmVjdG9yIDU5DQpzaW8wOiBbRklMVEVSXQ0Kc2lvMTogY29uZmlndXJlZCBpcnEgMyBub3QgaW4g Yml0bWFwIG9mIHByb2JlZCBpcnFzIDANCnNpbzE6IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVkDQpz aW8xOiBpcnEgbWFwczogMCAwIDAgMA0Kc2lvMTogcHJvYmUgZmFpbGVkIHRlc3Qocyk6IDAgMSAy IDQgNiA3IDkNCnNpbzEgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgyZjgtMHgyZmYgaXJxIDMg b24gaXNhMA0Kc2lvMjogbm90IHByb2JlZCAoZGlzYWJsZWQpDQpzaW8zOiBub3QgcHJvYmVkIChk aXNhYmxlZCkNCnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9t ZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTANCmlzYV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBQ blAgZGV2aWNlcw0KdWtiZDA6IDxNaWNyb3NvZnQgTWljcm9zb2Z0XE0tLiBEaWdpdGFsIE1lZGlh IFBybyBLZXlib2FyZCwgY2xhc3MgMC8wLCByZXYgMi4wMC8xLjEwLCBhZGRyIDI+IG9uIHVodWI2 DQprYmQyIGF0IHVrYmQwDQprYmQyOiB1a2JkMCwgZ2VuZXJpYyAoMCksIGNvbmZpZzoweDAsIGZs YWdzOjB4M2QwMDAwDQp1aGlkMDogPE1pY3Jvc29mdCBNaWNyb3NvZnRcTS0uIERpZ2l0YWwgTWVk aWEgUHJvIEtleWJvYXJkLCBjbGFzcyAwLzAsIHJldiAyLjAwLzEuMTAsIGFkZHIgMj4gb24gdWh1 YjYNCnVoaWQxOiA8TG9naXRlY2ggTG9naXRlY2ggVVNCIEhlYWRzZXQsIGNsYXNzIDAvMCwgcmV2 IDEuMTAvMTAuMTMsIGFkZHIgMz4gb24gdWh1YjYNCkRldmljZSBjb25maWd1cmF0aW9uIGZpbmlz aGVkLg0KUmVkdWNpbmcga2Vybi5tYXh2bm9kZXMgMTk2MDQ2IC0+IDEwMDAwMA0KcHJvY2ZzIHJl Z2lzdGVyZWQNCmxhcGljOiBEaXZpc29yIDIsIEZyZXF1ZW5jeSA2NzQ2OTM0MCBoeg0KVGltZWNv dW50ZXIgIlRTQyIgZnJlcXVlbmN5IDI2OTg3NzM3ODcgSHogcXVhbGl0eSAtMTAwDQpUaW1lY291 bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjDQpsbzA6IGJwZiBhdHRhY2hlZGZpcmV3aXJlMDog MSBub2RlcywgbWF4aG9wIDw9IDAsIGNhYmxlIElSTSA9IDAgKG1lKQ0KZmlyZXdpcmUwOiBidXMg bWFuYWdlciAwIChtZSkNCg0KaHB0cnI6IG5vIGNvbnRyb2xsZXIgZGV0ZWN0ZWQuDQphdGExLXNs YXZlOiBwaW89UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTEzMyBjYWJsZT00MCB3aXJlDQphdGEx LW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUExMDAgY2FibGU9NDAgd2lyZQ0K YWNkMDogPEhMLURULVNURFZELVJBTSBHSDIyTlMzMC8xLjAxPiBEVkRSIGRyaXZlIGF0IGF0YTEg YXMgbWFzdGVyDQphY2QwOiByZWFkIDgyNjlLQi9zICg4MjY5S0Ivcykgd3JpdGUgODI2OUtCL3Mg KDgyNjlLQi9zKSwgMjA0OEtCIGJ1ZmZlciwgVURNQTMzDQphY2QwOiBSZWFkczogQ0RSLCBDRFJX LCBDRERBIHN0cmVhbSwgRFZEUk9NLCBEVkRSLCBEVkRSQU0sIHBhY2tldA0KYWNkMDogV3JpdGVz OiBDRFIsIENEUlcsIERWRFIsIERWRFJBTSwgdGVzdCB3cml0ZSwgYnVybnByb29mDQphY2QwOiBB dWRpbzogcGxheSwgMjU1IHZvbHVtZSBsZXZlbHMNCmFjZDA6IE1lY2hhbmlzbTogZWplY3RhYmxl IHRyYXksIHVubG9ja2VkDQphY2QwOiBNZWRpdW06IG5vL2JsYW5rIGRpc2MNCmFkMzogMjg2MTY3 TUIgPFdEQyBXRDMwMDBHTEZTLTAxRjhVMCAwMy4wM1YwMT4gYXQgYXRhMS1zbGF2ZSBVRE1BMzMN CmFkMzogNTg2MDcwMjU1IHNlY3RvcnMgWzU4MTQxOEMvMTZILzYzU10gMTYgc2VjdG9ycy9pbnRl cnJ1cHQgMSBkZXB0aCBxdWV1ZQ0KYWQzOiBJbnRlbCBjaGVjazEgZmFpbGVkDQphZDM6IEFkYXB0 ZWMgY2hlY2sxIGZhaWxlZA0KYWQzOiBMU0kgKHYzKSBjaGVjazEgZmFpbGVkDQphZDM6IExTSSAo djIpIGNoZWNrMSBmYWlsZWQNCmFkMzogRnJlZUJTRCBjaGVjazEgZmFpbGVkDQphdGE2LW1hc3Rl cjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUExMzMgY2FibGU9NDAgd2lyZQ0KYWQxMjog NDc2OTQwTUIgPFdEQyBXRDUwMDJBQllTLTAxQjFCMCAwMi4wM0IwMj4gYXQgYXRhNi1tYXN0ZXIg VURNQTMzDQphZDEyOiA5NzY3NzMxNjggc2VjdG9ycyBbOTY5MDIxQy8xNkgvNjNTXSAxNiBzZWN0 b3JzL2ludGVycnVwdCAxIGRlcHRoIHF1ZXVlDQpHRU9NOiBuZXcgZGlzayBhZDMNCkdFT006IG5l dyBkaXNrIGFkMTINCmFkMTI6IEludGVsIGNoZWNrMSBmYWlsZWQNCmFkMTI6IEFkYXB0ZWMgY2hl Y2sxIGZhaWxlZA0KYWQxMjogTFNJICh2MykgY2hlY2sxIGZhaWxlZA0KYWQxMjogTFNJICh2Mikg Y2hlY2sxIGZhaWxlZA0KYWQxMjogRnJlZUJTRCBjaGVjazEgZmFpbGVkDQoocHJvYmUxOnNicDA6 MDowOjApOiBlcnJvciAyMg0KKHByb2JlMTpzYnAwOjA6MDowKTogVW5yZXRyeWFibGUgRXJyb3IN Cihwcm9iZTI6c2JwMDowOjE6MCk6IGVycm9yIDIyDQoocHJvYmUyOnNicDA6MDoxOjApOiBVbnJl dHJ5YWJsZSBFcnJvcg0KKHByb2JlMzpzYnAwOjA6MjowKTogZXJyb3IgMjINCihwcm9iZTM6c2Jw MDowOjI6MCk6IFVucmV0cnlhYmxlIEVycm9yDQoocHJvYmU0OnNicDA6MDozOjApOiBlcnJvciAy Mg0KKHByb2JlNDpzYnAwOjA6MzowKTogVW5yZXRyeWFibGUgRXJyb3INCihwcm9iZTU6c2JwMDow OjQ6MCk6IGVycm9yIDIyDQoocHJvYmU1OnNicDA6MDo0OjApOiBVbnJldHJ5YWJsZSBFcnJvcg0K KHByb2JlNjpzYnAwOjA6NTowKTogZXJyb3IgMjINCihwcm9iZTY6c2JwMDowOjU6MCk6IFVucmV0 cnlhYmxlIEVycm9yDQoocHJvYmU3OnNicDA6MDo2OjApOiBlcnJvciAyMg0KKHByb2JlNzpzYnAw OjA6NjowKTogVW5yZXRyeWFibGUgRXJyb3INCnBhc3MwIGF0IHVtYXNzLXNpbTAgYnVzIDAgdGFy Z2V0IDAgbHVuIDANCnBhc3MwOiA8S2luZ3N0b24gRGF0YVRyYXZlbGVyIDIuMCBQTUFQPiBSZW1v dmFibGUgRGlyZWN0IEFjY2VzcyBTQ1NJLTAgZGV2aWNlIA0KcGFzczA6IDQwLjAwME1CL3MgdHJh bnNmZXJzDQpHRU9NOiBuZXcgZGlzayBkYTANCkFUQSBQc2V1ZG9SQUlEIGxvYWRlZA0KU01QOiBB UCBDUFUgIzEgTGF1bmNoZWQhDQpjcHUxIEFQOg0KICAgICBJRDogMHgwMTAwMDAwMCAgIFZFUjog MHgwMDA2MDAxNSBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmDQogIGxpbnQwOiAweDAw MDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYN CiAgdGltZXI6IDB4MDAwMjAwZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEwMDAwIHBj bTogMHgwMDAxMDAwMA0KU01QOiBBUCBDUFUgIzIgTGF1bmNoZWQhDQpjcHUyIEFQOg0KICAgICBJ RDogMHgwMjAwMDAwMCAgIFZFUjogMHgwMDA2MDAxNSBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZm ZmZmZmZmDQogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAw MDAwMCBTVlI6IDB4MDAwMDAxZmYNCiAgdGltZXI6IDB4MDAwMjAwZWYgdGhlcm06IDB4MDAwMTAw MDAgZXJyOiAweDAwMDEwMDAwIHBjbTogMHgwMDAxMDAwMA0KU01QOiBBUCBDUFUgIzcgTGF1bmNo ZWQhDQpjcHU3IEFQOg0KICAgICBJRDogMHgwNzAwMDAwMCAgIFZFUjogMHgwMDA2MDAxNSBMRFI6 IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmDQogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAw eDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYNCiAgdGltZXI6IDB4MDAw MjAwZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEwMDAwIHBjbTogMHgwMDAxMDAwMA0K U01QOiBBUCBDUFUgIzUgTGF1bmNoZWQhDQpjcHU1IEFQOg0KICAgICBJRDogMHgwNTAwMDAwMCAg IFZFUjogMHgwMDA2MDAxNSBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmDQogIGxpbnQw OiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAw MDAxZmYNCiAgdGltZXI6IDB4MDAwMjAwZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEw MDAwIHBjbTogMHgwMDAxMDAwMA0KU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhDQpjcHUzIEFQOg0K ICAgICBJRDogMHgwMzAwMDAwMCAgIFZFUjogMHgwMDA2MDAxNSBMRFI6IDB4MDAwMDAwMDAgREZS OiAweGZmZmZmZmZmDQogIGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjog MHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYNCiAgdGltZXI6IDB4MDAwMjAwZWYgdGhlcm06IDB4 MDAwMTAwMDAgZXJyOiAweDAwMDEwMDAwIHBjbTogMHgwMDAxMDAwMA0KU01QOiBBUCBDUFUgIzQg TGF1bmNoZWQhDQpjcHU0IEFQOg0KICAgICBJRDogMHgwNDAwMDAwMCAgIFZFUjogMHgwMDA2MDAx NSBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmDQogIGxpbnQwOiAweDAwMDEwNzAwIGxp bnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6IDB4MDAwMDAxZmYNCiAgdGltZXI6 IDB4MDAwMjAwZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJyOiAweDAwMDEwMDAwIHBjbTogMHgwMDAx MDAwMA0KU01QOiBBUCBDUFUgIzYgTGF1bmNoZWQhDQpjcHU2IEFQOg0KICAgICBJRDogMHgwNjAw MDAwMCAgIFZFUjogMHgwMDA2MDAxNSBMRFI6IDB4MDAwMDAwMDAgREZSOiAweGZmZmZmZmZmDQog IGxpbnQwOiAweDAwMDEwNzAwIGxpbnQxOiAweDAwMDAwNDAwIFRQUjogMHgwMDAwMDAwMCBTVlI6 IDB4MDAwMDAxZmYNCiAgdGltZXI6IDB4MDAwMjAwZWYgdGhlcm06IDB4MDAwMTAwMDAgZXJyOiAw eDAwMDEwMDAwIHBjbTogMHgwMDAxMDAwMA0KaW9hcGljMDogQXNzaWduaW5nIElTQSBJUlEgMSB0 byBsb2NhbCBBUElDIDANCmlvYXBpYzA6IEFzc2lnbmluZyBJU0EgSVJRIDQgdG8gbG9jYWwgQVBJ QyAyDQppb2FwaWMwOiBBc3NpZ25pbmcgSVNBIElSUSA2IHRvIGxvY2FsIEFQSUMgNA0KaW9hcGlj MDogQXNzaWduaW5nIElTQSBJUlEgOSB0byBsb2NhbCBBUElDIDYNCmlvYXBpYzA6IEFzc2lnbmlu ZyBJU0EgSVJRIDE0IHRvIGxvY2FsIEFQSUMgMA0KaW9hcGljMDogQXNzaWduaW5nIElTQSBJUlEg MTUgdG8gbG9jYWwgQVBJQyAyDQppb2FwaWMwOiBBc3NpZ25pbmcgUENJIElSUSAxNiB0byBsb2Nh bCBBUElDIDQNCmlvYXBpYzA6IEFzc2lnbmluZyBQQ0kgSVJRIDE3IHRvIGxvY2FsIEFQSUMgNg0K aW9hcGljMDogQXNzaWduaW5nIFBDSSBJUlEgMTggdG8gbG9jYWwgQVBJQyAwDQppb2FwaWMwOiBB c3NpZ25pbmcgUENJIElSUSAxOSB0byBsb2NhbCBBUElDIDINCmlvYXBpYzA6IEFzc2lnbmluZyBQ Q0kgSVJRIDIxIHRvIGxvY2FsIEFQSUMgNA0KaW9hcGljMDogQXNzaWduaW5nIFBDSSBJUlEgMjMg dG8gbG9jYWwgQVBJQyA2DQpUcnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2FkMTJz MmENCnN0YXJ0X2luaXQ6IHRyeWluZyAvc2Jpbi9pbml0DQpyZTA6IGxpbmsgc3RhdGUgY2hhbmdl ZCB0byBVUA0K ------=_Part_97484_15670526.1228248310716-- From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 20:34:41 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A8E0106567A for ; Tue, 2 Dec 2008 20:34:41 +0000 (UTC) (envelope-from benjie@addgene.org) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 65F378FC21 for ; Tue, 2 Dec 2008 20:34:41 +0000 (UTC) (envelope-from benjie@addgene.org) Received: by yx-out-2324.google.com with SMTP id 8so1310270yxb.13 for ; Tue, 02 Dec 2008 12:34:40 -0800 (PST) Received: by 10.142.238.4 with SMTP id l4mr3871633wfh.242.1228248611231; Tue, 02 Dec 2008 12:10:11 -0800 (PST) Received: by 10.142.237.8 with HTTP; Tue, 2 Dec 2008 12:10:11 -0800 (PST) Message-ID: Date: Tue, 2 Dec 2008 15:10:11 -0500 From: "Benjie Chen" To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Weird TCP connect issue in FreeBSD 6 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, 02 Dec 2008 20:34:41 -0000 Hi I have a weird issue to report, and I am not sure if it's a bug or some other configuration problem. Server is a dual NICed FreeBSD 6.2 system. For example, one NIC is em0 = 192.168.0.1, and the other one is em1 = 192.168.0.2. I have an Apache server listening on 80 and 443 on both IP addresses. So we have 0.1:80, 0.1:443, 0.2:80, 0.2:443 Connections to 0.1:80, 0.1:443, 0.2:80, I have not experienced any problems. Connections to 0.2:443, however, I get frequently connection issues. I am connecting using telnet -- eg: telnet 192.168.0.2 443 Sometimes the connection would be established (past accept, I get to type something or ^]q out of telnet). Sometimes, however, immediately after connect is established, the connection would be terminated. I traced the problem by running tcpdump -p on em0 and em1, as well as a tcpdump on the same subnet as the client (which is on a whole different network). Packets to 0.2 are definitely arriving on em1, but responses from 0.2 back to client go out em0. This is just because of the default route. Here is what's happening on the failed/terminated connects: 1. client sends SYN to 0.2:443 2. 0.2:443 responds with SYN ACK 3. on tcpdumps on server, we see that before the SYN ACK from step 2 even reaches the client, we get repeated SYN packets to 0.2:443, and repeated (as expected) SYN ACK for each of the packet. we do not see the repeated SYNs on the tcpdump on the client network 4. step 3 goes on for a long time, even after the SYN ACK reaches client and client respond with an ACK 5. client receives a bunch of SYN ACK, and sends an ACK for each 6. at some point, I believe FreeBSD syn attack prevention kicks in and a RST is set to the server, connection is then terminated. Interesting observations: this does not happen all the time, just sometimes. This also does not happen (at least I can't get it to occur) for 0.2:80, or any of the 0.1:80 or 0.1:443 ports. I just switched to using IP aliasing on the same NIC, and so far I have not been able to re-produce the same problem. I am not familiar with the SYN cache/cookie code in FreeBSD, but is it possible that the dual NIC is confusing that piece of code, and in some cases, it does not see the SYN ACK from the server and retransmits the SYN? Something is retransmitting the SYN packets! If anyone has any information on this, please help! Thanks, Benjie --- Benjie Chen, Ph.D. Addgene, a better way to share plasmids www.addgene.org Manage your lab more efficiently Addgene Labs - www.addgenelabs.org From owner-freebsd-net@FreeBSD.ORG Tue Dec 2 20:44:45 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F162106564A for ; Tue, 2 Dec 2008 20:44:45 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-09.arcor-online.net (mail-in-09.arcor-online.net [151.189.21.49]) by mx1.freebsd.org (Postfix) with ESMTP id 269238FC1D for ; Tue, 2 Dec 2008 20:44:45 +0000 (UTC) (envelope-from mailnull@mips.inka.de) Received: from mail-in-04-z2.arcor-online.net (mail-in-04-z2.arcor-online.net [151.189.8.16]) by mail-in-09.arcor-online.net (Postfix) with ESMTP id 47DA73027F8 for ; Tue, 2 Dec 2008 21:12:29 +0100 (CET) Received: from mail-in-16.arcor-online.net (mail-in-16.arcor-online.net [151.189.21.56]) by mail-in-04-z2.arcor-online.net (Postfix) with ESMTP id 3B2BCAC1DE for ; Tue, 2 Dec 2008 21:12:29 +0100 (CET) Received: from lorvorc.mips.inka.de (dslb-092-075-206-164.pools.arcor-ip.net [92.75.206.164]) by mail-in-16.arcor-online.net (Postfix) with ESMTP id 1FCCE236E48 for ; Tue, 2 Dec 2008 21:12:29 +0100 (CET) Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.14.3/8.14.3) with ESMTP id mB2KCSUO034294 for ; Tue, 2 Dec 2008 21:12:28 +0100 (CET) (envelope-from mailnull@lorvorc.mips.inka.de) Received: (from mailnull@localhost) by lorvorc.mips.inka.de (8.14.3/8.14.3/Submit) id mB2KCSBt034293 for freebsd-net@freebsd.org; Tue, 2 Dec 2008 21:12:28 +0100 (CET) (envelope-from mailnull) From: naddy@mips.inka.de (Christian Weisgerber) Date: Tue, 2 Dec 2008 20:12:28 +0000 (UTC) Message-ID: References: <49349E26.30002@redhat.com> Originator: naddy@mips.inka.de (Christian Weisgerber) To: freebsd-net@freebsd.org X-Virus-Scanned: ClamAV 0.94.1/8712/Tue Dec 2 18:14:43 2008 on mail-in-16.arcor-online.net X-Virus-Status: Clean Subject: Re: [ipsec] aes-ctr question 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, 02 Dec 2008 20:44:45 -0000 wang_jiabo wrote: > following is my setkey configration. I can get SAD and SPD. but when I > run " ping6 -I rl0 3ffe:501:ffff:103:20a:ebff:fe85:9e56 " on FreeBSD > FreeBSD report: kernel: esp_aesctr_decrypt aes-ctr:payload length must > be multiple of 16 > kernel: decrypt fail in IPv6 ESP input : (I cannot comment on this problem. Looks like a padding bug.) > add 3ffe:501:ffff:103:20a:ebff:fe85:9e56 > 3ffe:501:ffff:104:21d:fff:fe19:59fc esp 0x1000 -m tunnel -E aes-ctr > "ipv6readylogoaes2to1" -A hmac-sha1 "ipv6readylogsha12to1"; Do not use AES-CTR with static keys! Re-use of keys with a stream cipher will allow listeners to recover the plaintext. (See section 7 of RFC 3686.) -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 01:00:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2063F1065670 for ; Wed, 3 Dec 2008 01:00:13 +0000 (UTC) (envelope-from jiabwang@redhat.com) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by mx1.freebsd.org (Postfix) with ESMTP id 4D6C88FC12 for ; Wed, 3 Dec 2008 01:00:11 +0000 (UTC) (envelope-from jiabwang@redhat.com) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mB3108ZJ015674; Tue, 2 Dec 2008 20:00:09 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mB3106Oc022349; Tue, 2 Dec 2008 20:00:07 -0500 Received: from [10.66.65.20] (dhcp-65-20.nay.redhat.com [10.66.65.20]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mB31041M008535; Tue, 2 Dec 2008 20:00:05 -0500 Message-ID: <4935DA42.2010804@redhat.com> Date: Wed, 03 Dec 2008 09:00:50 +0800 From: wang_jiabo User-Agent: Thunderbird 2.0.0.14 (X11/20080515) MIME-Version: 1.0 To: Christian Weisgerber References: <49349E26.30002@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 Cc: freebsd-net@freebsd.org Subject: Re: [ipsec] aes-ctr question 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, 03 Dec 2008 01:00:13 -0000 Christian Weisgerber wrote: > wang_jiabo wrote: > > >> following is my setkey configration. I can get SAD and SPD. but when I >> run " ping6 -I rl0 3ffe:501:ffff:103:20a:ebff:fe85:9e56 " on FreeBSD >> FreeBSD report: kernel: esp_aesctr_decrypt aes-ctr:payload length must >> be multiple of 16 >> kernel: decrypt fail in IPv6 ESP input : >> > > (I cannot comment on this problem. Looks like a padding bug.) > > >> add 3ffe:501:ffff:103:20a:ebff:fe85:9e56 >> 3ffe:501:ffff:104:21d:fff:fe19:59fc esp 0x1000 -m tunnel -E aes-ctr >> "ipv6readylogoaes2to1" -A hmac-sha1 "ipv6readylogsha12to1"; >> > > Do not use AES-CTR with static keys! Re-use of keys with a stream > cipher will allow listeners to recover the plaintext. > (See section 7 of RFC 3686.) > > but when I use " ping6 -I rl0 -s 11(or 12,13,14) 3ffe:501:ffff:103:20a:ebff:fe85:9e56" it is no problem From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 03:17:40 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0975B106564A; Wed, 3 Dec 2008 03:17:40 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from mail.consult-scs.com (MAIL.CONSULT-SCS.COM [208.81.60.67]) by mx1.freebsd.org (Postfix) with ESMTP id E382A8FC0A; Wed, 3 Dec 2008 03:17:39 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from [127.0.0.1] (host77.netvulture.com [208.201.244.77]) (Authenticated sender: vulture@netvulture.com) by mail.consult-scs.com (Postfix) with ESMTPA id 7D9971642486; Tue, 2 Dec 2008 19:18:15 -0800 (PST) Message-ID: <4935FA57.6080106@netvulture.com> Date: Tue, 02 Dec 2008 19:17:43 -0800 From: Jonathan Feally User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> <49357329.9000107@netvulture.com> <493587D4.5000400@netvulture.com> In-Reply-To: <493587D4.5000400@netvulture.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SCS-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 7D9971642486.8272C X-SCS-MailScanner: Found to be clean X-SCS-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-204.399, required 4, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, INIT_RECVD_OUR_AUTH -200.00) X-SCS-MailScanner-From: vulture@netvulture.com Cc: Subject: Re: dhclient doing DISCOVER with bad IP checksum - bge (7.1 show stopper?? NOPE - We're OK) 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, 03 Dec 2008 03:17:40 -0000 OK, so I installed a different PE1750 with BETA2 and then updated the source via cvsup RELENG_7 from cvsup3 and all is ok now on that box. Went back the first box and cvsup'ed the src again into an empty directory and it compiled and worked fine. Looks like my updating of the source along the way missed http://svn.freebsd.org/viewvc/base?view=revision&revision=182924 as that is the only diff between the 2 local source trees. Sorry for the confusion. I've never had this issue before with cvsup, but guess there's always a first time. Thanks to all for checking my own bad testing work. -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 07:09:08 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 785DC1065672; Wed, 3 Dec 2008 07:09:08 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from mail.consult-scs.com (MAIL.CONSULT-SCS.COM [208.81.60.67]) by mx1.freebsd.org (Postfix) with ESMTP id 5EEC18FC0A; Wed, 3 Dec 2008 07:09:08 +0000 (UTC) (envelope-from vulture@netvulture.com) Received: from [127.0.0.1] (host77.netvulture.com [208.201.244.77]) (Authenticated sender: vulture@netvulture.com) by mail.consult-scs.com (Postfix) with ESMTPA id 4F2DE1642485; Tue, 2 Dec 2008 23:09:46 -0800 (PST) Message-ID: <49363099.5040701@netvulture.com> Date: Tue, 02 Dec 2008 23:09:13 -0800 From: Jonathan Feally User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-stable@freebsd.org References: <4933A00E.7080201@netvulture.com> <4934C733.4020506@netvulture.com> <49357329.9000107@netvulture.com> <493587D4.5000400@netvulture.com> <4935FA57.6080106@netvulture.com> In-Reply-To: <4935FA57.6080106@netvulture.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SCS-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 4F2DE1642485.30571 X-SCS-MailScanner: Found to be clean X-SCS-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-204.399, required 4, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60, INIT_RECVD_OUR_AUTH -200.00) X-SCS-MailScanner-From: vulture@netvulture.com Cc: Subject: Re: dhclient doing DISCOVER with bad IP checksum - compile optimization issue 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, 03 Dec 2008 07:09:08 -0000 Ok, I managed to cause it again. dhclient was the problem. My source tree was fine. Turns out that it is my make.conf CFLAGS=-O3 setting. When compiled with -O3 it will generate packets with bad checksums. Simply recompiling it with -O2 did not cause this issue and dhclient works fine. So the question becomes, what is happening with -O3 that is breaking it? So far I am not having any other issues with -O3 on the rest of the system. -Jon -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 07:54:58 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C2981065672 for ; Wed, 3 Dec 2008 07:54:58 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id ECC378FC16 for ; Wed, 3 Dec 2008 07:54:57 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender; b=RbrnZtySlNyQkUiaXC8PzH5UaCt+67B0KA7gMPMt2H6icPyq/1mOyhmlCKVJwY6LPHKcVGOmxtprKb3q0CCeuUngsI8glY/ia7XtbfwHYV0v+LU92CA5zKI0vFMHYrnmFEUY7hDUW/FPByJEUjjv1Ek7TnDCteEIbbnAd+zHyqU=; Received: from void.codelabs.ru (void.codelabs.ru [144.206.177.25]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1L7mZU-000OWK-8k; Wed, 03 Dec 2008 10:54:56 +0300 Date: Wed, 3 Dec 2008 10:54:55 +0300 From: Eygene Ryabinkin To: Christian Weisgerber Message-ID: References: <49349E26.30002@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mjeOt6n4R71vn6wN" Content-Disposition: inline In-Reply-To: Sender: rea-fbsd@codelabs.ru Cc: freebsd-net@freebsd.org, gnn@freebsd.org Subject: Re: [ipsec] aes-ctr question 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, 03 Dec 2008 07:54:58 -0000 --mjeOt6n4R71vn6wN Content-Type: multipart/mixed; boundary="2R+TDOstMAPx/aG/" Content-Disposition: inline --2R+TDOstMAPx/aG/ Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Christian, good day. Tue, Dec 02, 2008 at 08:12:28PM +0000, Christian Weisgerber wrote: > wang_jiabo wrote: > > add 3ffe:501:ffff:103:20a:ebff:fe85:9e56 > > 3ffe:501:ffff:104:21d:fff:fe19:59fc esp 0x1000 -m tunnel -E aes-ctr > > "ipv6readylogoaes2to1" -A hmac-sha1 "ipv6readylogsha12to1"; > > Do not use AES-CTR with static keys! Re-use of keys with a stream > cipher will allow listeners to recover the plaintext. > (See section 7 of RFC 3686.) Good catch. Perhaps setkey should be extended to warn the user about this neat. The patch is attached. George, people, what do you think about it? --=20 Eygene _ ___ _.--. # \`.|\..----...-'` `-._.-'_.-'` # Remember that it is hard / ' ` , __.--' # to read the on-line manual =20 )/' _/ \ `-_, / # while single-stepping the kernel. `-'" `"\_ ,_.-;_.-\_ ', fsc/as # _.-'_./ {_.' ; / # -- FreeBSD Developers handbook=20 {_.-``-' {_/ # --2R+TDOstMAPx/aG/ Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="warn-user-if-he-wants-AES-CTR-mode.diff" Content-Transfer-Encoding: quoted-printable =46rom 9e076653cefc7c987c339d7a0bfd99ad6c83bd83 Mon Sep 17 00:00:00 2001 =46rom: Eygene Ryabinkin Date: Wed, 3 Dec 2008 10:48:19 +0300 Subject: [PATCH] setkey: warn user if he wants AES CTR mode Static encryption keys are very evil with the CTR modes: they allow to get the XORed plaintext values from two sessions sharing the same key. Warn user about possible consequences. There are reasons why this mode shouldn't be completely banned from the setkey and one of them is that user can do dynamic rekeying by himself. But in this case he would better use IKE or simular to avoid troubles. Signed-off-by: Eygene Ryabinkin --- sbin/setkey/parse.y | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/sbin/setkey/parse.y b/sbin/setkey/parse.y index 4107453..6c03810 100644 --- a/sbin/setkey/parse.y +++ b/sbin/setkey/parse.y @@ -335,6 +335,11 @@ enc_alg return -1; } p_alg_enc =3D $1; + if ($1 =3D=3D SADB_X_EALG_AESCTR) { + fprintf(stderr, + "WARNING: AES-CTR mode shouldn't be used with static encryption ke= ys.\n" + "WARNING: See RFC 3686, section 7 for explanations.\n"); + } =20 p_key_enc_len =3D $2.len; p_key_enc =3D $2.buf; --=20 1.6.0.4 --2R+TDOstMAPx/aG/-- --mjeOt6n4R71vn6wN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk2O08ACgkQthUKNsbL7YjvxQCeP5F9XGF/vtGjKsqIsRfXeLAz 2DUAoJUdvAf4x5UaOZeZ4/RYu4MiqpcO =YXN6 -----END PGP SIGNATURE----- --mjeOt6n4R71vn6wN-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 08:17:47 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2DC4B106564A for ; Wed, 3 Dec 2008 08:17:47 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id A71DF8FC1D for ; Wed, 3 Dec 2008 08:17:46 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from orphanage.alkar.net (account mav@alkar.net [212.86.226.11] verified) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPA id 228675719; Wed, 03 Dec 2008 10:17:45 +0200 Message-ID: <493640A9.8080701@FreeBSD.org> Date: Wed, 03 Dec 2008 10:17:45 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.14 (X11/20080612) MIME-Version: 1.0 To: "Vladimir V. Kobal" References: <1228234984.00043656.1228222202@10.7.7.3> In-Reply-To: <1228234984.00043656.1228222202@10.7.7.3> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Multiple netgraph threads 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, 03 Dec 2008 08:17:47 -0000 Hi. Vladimir V. Kobal wrote: > I'm interested in the information of further development of Subject. I have > a bottleneck: swi_net limited by one CPU core time. There was a thread > http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017447.html . > Patch http://people.freebsd.org/~mav/netgraph.threads.patch is not available > :(. Could somebody mail it to me. Are there any other similar patches? I have uploaded that patch back. Not sure is it correct at this moment, there was some changes, but that time it worked fine. I have measured some benefit on my tests with Core2Quad using NetPerf cluster. But even having all 4 cores busy, I have got just only about 20% performance benefit on that test setup (routing between three Gigabit PPTP links). I suppose it was result of constant cache trashing, when the same netgraph nodes write-accessed by different CPUs. But may be on more diverse workload, or with some heavy compression/encryption used benefit can be bigger. -- Alexander Motin From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 08:41:22 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C9641065672; Wed, 3 Dec 2008 08:41:22 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from smtp.zeninc.net (smtp.zeninc.net [80.67.176.25]) by mx1.freebsd.org (Postfix) with ESMTP id BE0D88FC16; Wed, 3 Dec 2008 08:41:21 +0000 (UTC) (envelope-from vanhu@zeninc.net) Received: from astro.zen.inc (astro.zen.inc [192.168.1.239]) by smtp.zeninc.net (smtpd) with ESMTP id 038DB2798B8; Wed, 3 Dec 2008 09:21:59 +0100 (CET) Received: by astro.zen.inc (Postfix, from userid 1000) id 59E7217051; Wed, 3 Dec 2008 09:25:49 +0100 (CET) Date: Wed, 3 Dec 2008 09:25:49 +0100 From: VANHULLEBUS Yvan To: Eygene Ryabinkin Message-ID: <20081203082549.GA62889@zeninc.net> References: <49349E26.30002@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: All mail clients suck. This one just sucks less. Cc: freebsd-net@freebsd.org, Christian Weisgerber , gnn@freebsd.org Subject: Re: [ipsec] aes-ctr question 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, 03 Dec 2008 08:41:22 -0000 On Wed, Dec 03, 2008 at 10:54:55AM +0300, Eygene Ryabinkin wrote: [...] > Good catch. Perhaps setkey should be extended to warn the user about > this neat. The patch is attached. George, people, what do you think > about it? If we're going to add security warnings in setkey, we could just put a warning when using static keys (so basically put a warning for "add" command....). Yvan. From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 09:47:39 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E347A1065672 for ; Wed, 3 Dec 2008 09:47:39 +0000 (UTC) (envelope-from prvs=julian=216e3e3bb@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id CE8818FC0A for ; Wed, 3 Dec 2008 09:47:39 +0000 (UTC) (envelope-from prvs=julian=216e3e3bb@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.87]) by smtp-outbound.ironport.com with ESMTP; 03 Dec 2008 01:18:35 -0800 Message-ID: <49364EF1.90703@elischer.org> Date: Wed, 03 Dec 2008 01:18:41 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Alexander Motin References: <1228234984.00043656.1228222202@10.7.7.3> <493640A9.8080701@FreeBSD.org> In-Reply-To: <493640A9.8080701@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, "Vladimir V. Kobal" Subject: Re: Multiple netgraph threads 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, 03 Dec 2008 09:47:40 -0000 Alexander Motin wrote: > Hi. > > Vladimir V. Kobal wrote: >> I'm interested in the information of further development of Subject. I have >> a bottleneck: swi_net limited by one CPU core time. There was a thread >> http://lists.freebsd.org/pipermail/freebsd-net/2008-March/017447.html . >> Patch http://people.freebsd.org/~mav/netgraph.threads.patch is not available >> :(. Could somebody mail it to me. Are there any other similar patches? > > I have uploaded that patch back. Not sure is it correct at this moment, > there was some changes, but that time it worked fine. > > I have measured some benefit on my tests with Core2Quad using NetPerf > cluster. But even having all 4 cores busy, I have got just only about > 20% performance benefit on that test setup (routing between three > Gigabit PPTP links). I suppose it was result of constant cache trashing, > when the same netgraph nodes write-accessed by different CPUs. But may > be on more diverse workload, or with some heavy compression/encryption > used benefit can be bigger. > I would like to see this work followed through.. From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 11:05:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD2C31065675 for ; Wed, 3 Dec 2008 11:05:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 5C0D88FC1B for ; Wed, 3 Dec 2008 11:05:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id C1BFB41C6A3; Wed, 3 Dec 2008 12:05:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id RDWZdBuC1q0e; Wed, 3 Dec 2008 12:05:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 6396241C6A1; Wed, 3 Dec 2008 12:05:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 489844448D5; Wed, 3 Dec 2008 11:03:06 +0000 (UTC) Date: Wed, 3 Dec 2008 11:03:05 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Frank Behrens In-Reply-To: <200811280653.mAS6r1P3014050@post.behrens.de> Message-ID: <20081203104040.D80401@maildrop.int.zabbadoz.net> References: <200811271542.mARFgglB004902@post.behrens.de> <200811280653.mAS6r1P3014050@post.behrens.de> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: Problem with new source address selection 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, 03 Dec 2008 11:05:08 -0000 On Fri, 28 Nov 2008, Frank Behrens wrote: Hi, > Bjoern A. Zeeb wrote on 27 Nov 2008 16:47: >>> Now I want to tunnel between my 192.168.90.0/24 and a foreign >>> 192.168.200.0/24. So I assigned 192.168.90.254/32 to lo2 and created >>> a static route. >> >> So if you don't mind to go out with a source address of 192.168.90.1 >> instead of .254, what about this hack. What happens if you change the >> route to >> route change -net 192.168.200.0/24 192.168.90.2 >> (assuming the .2 is not on your local machine). > > That works for the router, but for incoming packets on the internal > interface (from -net 192.168.90.0/24) the machine will send an ICMP > redirect to new router 192.168.90.2. Of course that is a black hole. > When I use the route to own interface address > (route change -net 192.168.200.0/24 192.168.90.1) it works, but also > for every incoming packet an ICMP redirect is sent. So that solution > is a workaround for short time only. You can disable icmp redircts entirely but not sure if soemthing else would stop working in your network topology then. sysctl net.inet.ip.redirect > Does anybody have a better solution for source address selection? Am > I the only one with an IPSEC tunnel? The best solution actually is to teach your application to bind for this connection I guess instead of relying on any hack. When it comes to the source address selection I am tempted to answer with: I am willing to still allow this in 7 to not break production setups but I am inclined to not change HEAD and keep the behavior dropped there. See patch below, which basically is what you had with the version check and the if (ia == NULL) check to not blindly overwrite if we had found anything closer (untested). Currently trying to discuss this with people. ------------------------------------------------------------------------ Index: sys/netinet/in_pcb.c =================================================================== --- sys/netinet/in_pcb.c (revision 185571) +++ sys/netinet/in_pcb.c (working copy) @@ -696,6 +696,10 @@ ia = ifatoia(ifa_ifwithnet(sintosa(&sain))); if (cred == NULL || !jailed(cred)) { +#if __FreeBSD_version < 800000 + if (ia == NULL) + ia = (struct in_ifaddr *)sro.ro_rt->rt_ifa; +#endif if (ia == NULL) { error = ENETUNREACH; goto done; ------------------------------------------------------------------------ /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 12:20:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CAA471065670 for ; Wed, 3 Dec 2008 12:20:16 +0000 (UTC) (envelope-from frank@harz.behrens.de) Received: from post.behrens.de (post.behrens.de [IPv6:2a01:170:1023::1:2]) by mx1.freebsd.org (Postfix) with ESMTP id 212538FC13 for ; Wed, 3 Dec 2008 12:20:15 +0000 (UTC) (envelope-from frank@harz.behrens.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=behrens.de; h=from:to:date:mime-version:subject:cc:in-reply-to:references:content-type:content-transfer-encoding:content-description; s=pinky1; t=1228306813; i=frank@harz.behrens.de; bh=fcAxjPXpe3MooGpTtdSyUpAmYXIWYsVMOwFmGSB9flc=; b=Z10vcrzwg6s+zCmDhAW3MCK4q+f5JFcThiugebAEOUChWjltXC5+cAIG81p0DBZAwg6GepIbmLlTDi8cDjLEgQ== Received: from sun.behrens ([IPv6:2a01:170:1023:0:6995:e4a5:5912:409f]) by post.behrens.de (8.14.3/8.14.2) with ESMTP(MSA) id mB3CK204015947; Wed, 3 Dec 2008 13:20:02 +0100 (CET) (envelope-from frank@harz.behrens.de) Message-Id: <200812031220.mB3CK204015947@post.behrens.de> From: "Frank Behrens" To: "Bjoern A. Zeeb" Date: Wed, 03 Dec 2008 13:20:02 +0100 MIME-Version: 1.0 Priority: normal In-reply-to: <20081203104040.D80401@maildrop.int.zabbadoz.net> References: <200811280653.mAS6r1P3014050@post.behrens.de> X-mailer: Pegasus Mail for Windows (4.31, DE v4.31 R1) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body X-Hashcash: 1:23:081203:freebsd-net@freebsd.org::xRdTrwC5zJh9MD3b:0000000000Niv5 X-Hashcash: 1:23:081203:bzeeb-lists@lists.zabbadoz.net::g0r8jrY1niW2gvi8:0000614I Cc: freebsd-net@freebsd.org Subject: Re: Problem with new source address selection 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, 03 Dec 2008 12:20:16 -0000 Bjoern A. Zeeb wrote on 3 Dec 2008 11:03: > On Fri, 28 Nov 2008, Frank Behrens wrote: > > That works for the router, but for incoming packets on the internal > > interface (from -net 192.168.90.0/24) the machine will send an ICMP > > redirect to new router 192.168.90.2. Of course that is a black hole. > > When I use the route to own interface address > > (route change -net 192.168.200.0/24 192.168.90.1) it works, but also > > for every incoming packet an ICMP redirect is sent. So that solution > > is a workaround for short time only. > > You can disable icmp redircts entirely but not sure if soemthing else > would stop working in your network topology then. > > sysctl net.inet.ip.redirect This is the workaround I made in the meantime. I believe icmp redirects are for a working network not necessary, they are only an optimization. > > Does anybody have a better solution for source address selection? Am > > I the only one with an IPSEC tunnel? > > The best solution actually is to teach your application to bind for > this connection I guess instead of relying on any hack. Hm, is this so easy? I thought address selection for outgoing connections is made by the OS? One of my test cases is bind/named. I don't know how to configure _multiple_ bind addresses for outgoing connections dependent from destination network. As I mentioned earlier I believe the main problem is IPSEC itself, where we don't have an interface for tunneled connections. So I made a workaround with a dummy loopback device. So I have a question to the network specialists: Is there no other solution? Am I the only stupid man, who wants to tunnel a subnet with private address range via IPSEC? > When it comes to the source address selection I am tempted to answer > with: I am willing to still allow this in 7 to not break production > setups but I am inclined to not change HEAD and keep the behavior > dropped there. See patch below, which basically is what you had with > the version check and the if (ia == NULL) check to not blindly overwrite > if we had found anything closer (untested). Thanks, I will try this. Regards, Frank -- Frank Behrens, Osterwieck, Germany PGP-key 0x5B7C47ED on public servers available. From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 14:12:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCA021065670 for ; Wed, 3 Dec 2008 14:12:03 +0000 (UTC) (envelope-from prvs=julian=216e3e3bb@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id C6FFD8FC29 for ; Wed, 3 Dec 2008 14:12:03 +0000 (UTC) (envelope-from prvs=julian=216e3e3bb@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.27]) by smtp-outbound.ironport.com with ESMTP; 03 Dec 2008 06:12:03 -0800 Message-ID: <493693B1.3030306@elischer.org> Date: Wed, 03 Dec 2008 06:12:01 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <200811271542.mARFgglB004902@post.behrens.de> <200811280653.mAS6r1P3014050@post.behrens.de> <20081203104040.D80401@maildrop.int.zabbadoz.net> In-Reply-To: <20081203104040.D80401@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Frank Behrens Subject: Re: Problem with new source address selection 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, 03 Dec 2008 14:12:03 -0000 Bjoern A. Zeeb wrote: > On Fri, 28 Nov 2008, Frank Behrens wrote: > > Hi, > >> Bjoern A. Zeeb wrote on 27 Nov 2008 >> 16:47: >>>> Now I want to tunnel between my 192.168.90.0/24 and a foreign >>>> 192.168.200.0/24. So I assigned 192.168.90.254/32 to lo2 and created >>>> a static route. >>> >>> So if you don't mind to go out with a source address of 192.168.90.1 >>> instead of .254, what about this hack. What happens if you change the >>> route to >>> route change -net 192.168.200.0/24 192.168.90.2 >>> (assuming the .2 is not on your local machine). >> >> That works for the router, but for incoming packets on the internal >> interface (from -net 192.168.90.0/24) the machine will send an ICMP >> redirect to new router 192.168.90.2. Of course that is a black hole. >> When I use the route to own interface address >> (route change -net 192.168.200.0/24 192.168.90.1) it works, but also >> for every incoming packet an ICMP redirect is sent. So that solution >> is a workaround for short time only. > > You can disable icmp redircts entirely but not sure if soemthing else > would stop working in your network topology then. > > sysctl net.inet.ip.redirect > > >> Does anybody have a better solution for source address selection? Am >> I the only one with an IPSEC tunnel? > > The best solution actually is to teach your application to bind for > this connection I guess instead of relying on any hack. > > > When it comes to the source address selection I am tempted to answer > with: I am willing to still allow this in 7 to not break production > setups but I am inclined to not change HEAD and keep the behavior > dropped there. See patch below, which basically is what you had with > the version check and the if (ia == NULL) check to not blindly overwrite > if we had found anything closer (untested). > > Currently trying to discuss this with people. can you assign a second FIB to handle this case? > > ------------------------------------------------------------------------ > Index: sys/netinet/in_pcb.c > =================================================================== > --- sys/netinet/in_pcb.c (revision 185571) > +++ sys/netinet/in_pcb.c (working copy) > @@ -696,6 +696,10 @@ > ia = ifatoia(ifa_ifwithnet(sintosa(&sain))); > > if (cred == NULL || !jailed(cred)) { > +#if __FreeBSD_version < 800000 > + if (ia == NULL) > + ia = (struct in_ifaddr *)sro.ro_rt->rt_ifa; > +#endif > if (ia == NULL) { > error = ENETUNREACH; > goto done; > ------------------------------------------------------------------------ > > > /bz > From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 19:36:16 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9360F106564A for ; Wed, 3 Dec 2008 19:36:16 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail15.syd.optusnet.com.au (mail15.syd.optusnet.com.au [211.29.132.196]) by mx1.freebsd.org (Postfix) with ESMTP id 27B048FC13 for ; Wed, 3 Dec 2008 19:36:15 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail15.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mB3JaAt3032260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Dec 2008 06:36:11 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id mB3JaAUn076956; Thu, 4 Dec 2008 06:36:10 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id mB3Ja9iT076955; Thu, 4 Dec 2008 06:36:09 +1100 (EST) (envelope-from peter) Date: Thu, 4 Dec 2008 06:36:09 +1100 From: Peter Jeremy To: Benjie Chen Message-ID: <20081203193609.GB58682@server.vk2pj.dyndns.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-net@freebsd.org Subject: Re: Weird TCP connect issue in FreeBSD 6 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, 03 Dec 2008 19:36:16 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Dec-02 15:10:11 -0500, Benjie Chen wrote: >I have a weird issue to report, and I am not sure if it's a bug or >some other configuration problem. I would suggest it is a configuration problem. >Server is a dual NICed FreeBSD 6.2 system. For example, one NIC is em0 >=3D 192.168.0.1, and the other one is em1 =3D 192.168.0.2. This is not a supported configuration - you cannot have addresses within the same subnet on more than one interface. >I just switched to using IP aliasing on the same NIC, and so far I >have not been able to re-produce the same problem. This is the correct configuration. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk236kACgkQ/opHv/APuIcuywCfQklbpe6Hl6sNMHZnhDpr4npC iUMAoJjvH7k2T+1JjjqtBcAADuuGZrvQ =yA2M -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-freebsd-net@FreeBSD.ORG Wed Dec 3 22:40:03 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63EA61065670 for ; Wed, 3 Dec 2008 22:40:03 +0000 (UTC) (envelope-from benjie@addgene.org) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.240]) by mx1.freebsd.org (Postfix) with ESMTP id 1D2A28FC0A for ; Wed, 3 Dec 2008 22:40:03 +0000 (UTC) (envelope-from benjie@addgene.org) Received: by an-out-0708.google.com with SMTP id b6so1520448ana.13 for ; Wed, 03 Dec 2008 14:40:01 -0800 (PST) Received: by 10.142.238.4 with SMTP id l4mr5507278wfh.98.1228344001061; Wed, 03 Dec 2008 14:40:01 -0800 (PST) Received: by 10.142.179.19 with HTTP; Wed, 3 Dec 2008 14:40:01 -0800 (PST) Message-ID: Date: Wed, 3 Dec 2008 17:40:01 -0500 From: "Benjie Chen" To: "Peter Jeremy" In-Reply-To: <20081203193609.GB58682@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081203193609.GB58682@server.vk2pj.dyndns.org> Cc: freebsd-net@freebsd.org Subject: Re: Weird TCP connect issue in FreeBSD 6 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, 03 Dec 2008 22:40:03 -0000 Peter, Thanks for the response. When I had two IPs from two different subnets configured for the two NICs, I had the same error. So while I did have a configuration issue, the problem with replicated SYNs did occur even when the two NICs had IP addresses on different networks. Benjie On Wed, Dec 3, 2008 at 2:36 PM, Peter Jeremy wrote: > On 2008-Dec-02 15:10:11 -0500, Benjie Chen wrote: >>I have a weird issue to report, and I am not sure if it's a bug or >>some other configuration problem. > > I would suggest it is a configuration problem. > >>Server is a dual NICed FreeBSD 6.2 system. For example, one NIC is em0 >>= 192.168.0.1, and the other one is em1 = 192.168.0.2. > > This is not a supported configuration - you cannot have addresses within > the same subnet on more than one interface. > >>I just switched to using IP aliasing on the same NIC, and so far I >>have not been able to re-produce the same problem. > > This is the correct configuration. > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. > From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 04:41:01 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33A4C1065672; Thu, 4 Dec 2008 04:41:01 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 0ABF68FC16; Thu, 4 Dec 2008 04:41:01 +0000 (UTC) (envelope-from yongari@FreeBSD.org) Received: from freefall.freebsd.org (yongari@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB44f0wF093936; Thu, 4 Dec 2008 04:41:00 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB44f0uY093932; Thu, 4 Dec 2008 04:41:00 GMT (envelope-from yongari) Date: Thu, 4 Dec 2008 04:41:00 GMT Message-Id: <200812040441.mB44f0uY093932@freefall.freebsd.org> To: nospam@ofloo.net, yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Cc: Subject: Re: kern/128181: [fxp] panic in fxp_add_rfabuf 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, 04 Dec 2008 04:41:01 -0000 Synopsis: [fxp] panic in fxp_add_rfabuf State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Thu Dec 4 04:36:10 UTC 2008 State-Changed-Why: I think this issue might be fixed in HEAD. Would you try fxp(4) in HEAD? (Replacing fxp(4) with HEAD version would also work on latest stable/7). Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Thu Dec 4 04:36:10 UTC 2008 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=128181 From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 05:05:36 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDC75106564A for ; Thu, 4 Dec 2008 05:05:36 +0000 (UTC) (envelope-from jiabwang@redhat.com) Received: from mx2.redhat.com (mx2.redhat.com [66.187.237.31]) by mx1.freebsd.org (Postfix) with ESMTP id 2BFAA8FC0C for ; Thu, 4 Dec 2008 05:05:34 +0000 (UTC) (envelope-from jiabwang@redhat.com) Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mB455UVB021588 for ; Thu, 4 Dec 2008 00:05:31 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mB455RwG015350 for ; Thu, 4 Dec 2008 00:05:29 -0500 Received: from [10.66.65.20] (dhcp-65-20.nay.redhat.com [10.66.65.20]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mB455Qq8004469 for ; Thu, 4 Dec 2008 00:05:27 -0500 Message-ID: <49376544.70006@redhat.com> Date: Thu, 04 Dec 2008 13:06:12 +0800 From: wang_jiabo User-Agent: Thunderbird 2.0.0.14 (X11/20080515) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.27.26 Subject: [ipv6]how to configure ipv6 address in /etc/rc.conf 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, 04 Dec 2008 05:05:36 -0000 I would like configure manual ipv6 address in /etc/rc.conf I add the following command : ipv6_enable="yes" ifconfig_rl0="inet6 3ffe:501:ffff:100::20 prefixlen 64" but, when I reboot the system, then ifconfig check, did not show the address please tell me how to configure From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 07:10:07 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C61171065672 for ; Thu, 4 Dec 2008 07:10:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 80BBC8FC13 for ; Thu, 4 Dec 2008 07:10:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id A71B541C5D8; Thu, 4 Dec 2008 08:10:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id SGRvB9I-nnF4; Thu, 4 Dec 2008 08:10:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 59D1A41C5C9; Thu, 4 Dec 2008 08:10:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 66C6C4448D5; Thu, 4 Dec 2008 07:05:31 +0000 (UTC) Date: Thu, 4 Dec 2008 07:05:30 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: wang_jiabo In-Reply-To: <49376544.70006@redhat.com> Message-ID: <20081204070239.X80401@maildrop.int.zabbadoz.net> References: <49376544.70006@redhat.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: [ipv6]how to configure ipv6 address in /etc/rc.conf 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, 04 Dec 2008 07:10:07 -0000 On Thu, 4 Dec 2008, wang_jiabo wrote: > I would like configure manual ipv6 address in /etc/rc.conf > I add the following command : > ipv6_enable="yes" > ifconfig_rl0="inet6 3ffe:501:ffff:100::20 prefixlen 64" > but, when I reboot the system, then ifconfig check, did not show the address > please tell me how to configure check /etc/defaults/rc.conf or better read man rc.conf and search for ipv6_network_interfaces and read it entirely. /bz -- Bjoern A. Zeeb Stop bit received. Insert coin for new game. From owner-freebsd-net@FreeBSD.ORG Thu Dec 4 14:08:29 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E74AD1065673; Thu, 4 Dec 2008 14:08:29 +0000 (UTC) (envelope-from vlad@prokk.net) Received: from smtp.prokk.net (smtp.prokk.net [195.16.77.5]) by mx1.freebsd.org (Postfix) with ESMTP id EEC268FC13; Thu, 4 Dec 2008 14:08:24 +0000 (UTC) (envelope-from vlad@prokk.net) Received: from base (base.prokk.net [195.16.77.7]) by smtp.prokk.net (8.13.8/8.13.8) with ESMTP id mB4E8Dqx019876; Thu, 4 Dec 2008 16:08:18 +0200 (EET) (envelope-from vlad@prokk.net) From: "Vladimir V. Kobal" To: "'Alexander Motin'" References: <1228234984.00043656.1228222202@10.7.7.3> <493640A9.8080701@FreeBSD.org> In-Reply-To: <493640A9.8080701@FreeBSD.org> Date: Thu, 4 Dec 2008 16:08:07 +0200 Organization: ProKK SE Message-ID: <003001c95619$be6e98a0$3b4bc9e0$@net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0031_01C9562A.81F768A0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AclVH7oE985BEYUTSAe84VFfmMez6gA8KcWg Content-Language: uk X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp.prokk.net [195.16.77.5]); Thu, 04 Dec 2008 16:08:18 +0200 (EET) Cc: freebsd-net@freebsd.org Subject: RE: Multiple netgraph threads 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, 04 Dec 2008 14:08:30 -0000 ]rn qnqr`bmne qnnayemhe b tnpl`re MIME. ------=_NextPart_000_0031_01C9562A.81F768A0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Alexander Motin wrote: >I have uploaded that patch back. Not sure is it correct at this moment, >there was some changes, but that time it worked fine. Thanks a lot. I've installed the patch with some changes. I'm using the 7-STABLE (ng_base.c,v 1.135.2.10) at a production NAS. Corresponding patch is in the attachment. I can't say anything of performance yet. Not enough statistics data is collected at the moment. But there is a strangeness with ng_queue threads: under high network load top display too low WCPU (while TIME has a normal value) for these threads. The maximum WCPU I saw under lower network load was 35-40% per ng_queue thread. Are there any ideas? Am I using correctly the kthread_create() in the patch? last pid: 21000; load averages: 1.52, 1.40, 1.02 up 0+00:25:39 14:24:28 79 processes: 5 running, 63 sleeping, 11 waiting CPU: 0.3% user, 0.0% nice, 41.4% system, 0.6% interrupt, 57.7% idle Mem: 40M Active, 11M Inact, 166M Wired, 112K Cache, 77M Buf, 1731M Free Swap: 2048M Total, 2048M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 12 root 1 171 ki31 0K 16K RUN 2 18:36 58.50% idle: cpu2 11 root 1 171 ki31 0K 16K RUN 3 18:02 63.87% idle: cpu3 13 root 1 171 ki31 0K 16K CPU1 1 17:56 41.26% idle: cpu1 14 root 1 171 ki31 0K 16K CPU0 0 17:20 59.96% idle: cpu0 2 root 1 96 - 0K 16K sleep 0 7:16 0.20% ng_queue0 3 root 1 96 - 0K 16K sleep 1 7:13 0.20% ng_queue1 25 root 1 -68 - 0K 16K - 1 5:44 36.67% em0 taskq 26 root 1 -68 - 0K 16K - 2 5:26 35.60% em1 taskq 16 root 1 -32 - 0K 16K WAIT 0 1:30 3.86% swi4: clock 2538 root 1 48 0 36720K 15228K select 3 0:25 0.59% mpd5 -- Vladimir Kobal ------=_NextPart_000_0031_01C9562A.81F768A0 Content-Type: application/octet-stream; name="netgraph.threads.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="netgraph.threads.patch" --- ng_base.c.orig 2008-12-03 11:29:36.000000000 +0200=0A= +++ ng_base.c 2008-12-03 16:12:20.000000000 +0200=0A= @@ -61,6 +61,8 @@=0A= #include =0A= #include =0A= #include =0A= +#include =0A= +#include =0A= #include =0A= =0A= #include =0A= @@ -203,7 +205,7 @@ static int ng_generic_msg(node_p here, i=0A= static ng_ID_t ng_decodeidname(const char *name);=0A= static int ngb_mod_event(module_t mod, int event, void *data);=0A= static void ng_worklist_add(node_p node);=0A= -static void ngintr(void);=0A= +static void ngthread(void *);=0A= static int ng_apply_item(node_p node, item_p item, int rw);=0A= static void ng_flush_input_queue(struct ng_queue * ngq);=0A= static node_p ng_ID2noderef(ng_ID_t ID);=0A= @@ -251,6 +253,10 @@ MALLOC_DEFINE(M_NETGRAPH_MSG, "netgraph_=0A= mtx_lock(&ng_worklist_mtx)=0A= #define NG_WORKLIST_UNLOCK() \=0A= mtx_unlock(&ng_worklist_mtx)=0A= +#define NG_WORKLIST_SLEEP() \=0A= + mtx_sleep(&ng_worklist, &ng_worklist_mtx, 0, "sleep", 0)=0A= +#define NG_WORKLIST_WAKEUP() \=0A= + wakeup_one(&ng_worklist)=0A= =0A= #ifdef NETGRAPH_DEBUG /*----------------------------------------------*/=0A= /*=0A= @@ -2858,9 +2864,13 @@ out:=0A= =0A= uma_zone_t ng_qzone;=0A= uma_zone_t ng_qdzone;=0A= +static int numthreads =3D 0; /* number of queue threads */=0A= static int maxalloc =3D 4096;/* limit the damage of a leak */=0A= static int maxdata =3D 512; /* limit the damage of a DoS */=0A= =0A= +TUNABLE_INT("net.graph.threads", &numthreads);=0A= +SYSCTL_INT(_net_graph, OID_AUTO, threads, CTLFLAG_RDTUN, &numthreads,=0A= + 0, "Number of queue processing threads to create");=0A= TUNABLE_INT("net.graph.maxalloc", &maxalloc);=0A= SYSCTL_INT(_net_graph, OID_AUTO, maxalloc, CTLFLAG_RDTUN, &maxalloc,=0A= 0, "Maximum number of non-data queue items to allocate");=0A= @@ -3055,6 +3065,7 @@ static int=0A= ngb_mod_event(module_t mod, int event, void *data)=0A= {=0A= int error =3D 0;=0A= + int i;=0A= =0A= switch (event) {=0A= case MOD_LOAD:=0A= @@ -3080,8 +3091,17 @@ ngb_mod_event(module_t mod, int event, v=0A= ng_qdzone =3D uma_zcreate("NetGraph data items", sizeof(struct = ng_item),=0A= NULL, NULL, NULL, NULL, UMA_ALIGN_CACHE, 0);=0A= uma_zone_set_max(ng_qdzone, maxdata);=0A= - netisr_register(NETISR_NETGRAPH, (netisr_t *)ngintr, NULL,=0A= - NETISR_MPSAFE);=0A= + /* Autoconfigure number of threads. */=0A= + if (numthreads <=3D 0)=0A= + numthreads =3D mp_ncpus;=0A= + /* Create threads. */=0A= + for (i =3D 0; i < numthreads; i++) {=0A= + if (kthread_create(ngthread, NULL, NULL,=0A= + 0, 0, "ng_queue%d", i)) {=0A= + numthreads =3D i - 1;=0A= + break;=0A= + }=0A= + }=0A= break;=0A= case MOD_UNLOAD:=0A= /* You can't unload it because an interface may be using it. */=0A= @@ -3236,29 +3256,25 @@ SYSCTL_PROC(_debug, OID_AUTO, ng_dump_it=0A= /***********************************************************************=0A= * Worklist routines=0A= **********************************************************************/=0A= -/* NETISR thread enters here */=0A= /*=0A= * Pick a node off the list of nodes with work,=0A= - * try get an item to process off it.=0A= - * If there are no more, remove the node from the list.=0A= + * try get an item to process off it. Remove the node from the list.=0A= */=0A= static void=0A= -ngintr(void)=0A= +ngthread(void *arg)=0A= {=0A= for (;;) {=0A= node_p node;=0A= =0A= /* Get node from the worklist. */=0A= NG_WORKLIST_LOCK();=0A= - node =3D TAILQ_FIRST(&ng_worklist);=0A= - if (!node) {=0A= - NG_WORKLIST_UNLOCK();=0A= - break;=0A= - }=0A= + while ((node =3D TAILQ_FIRST(&ng_worklist)) =3D=3D NULL)=0A= + NG_WORKLIST_SLEEP();=0A= TAILQ_REMOVE(&ng_worklist, node, nd_work);=0A= NG_WORKLIST_UNLOCK();=0A= CTR3(KTR_NET, "%20s: node [%x] (%p) taken off worklist",=0A= __func__, node->nd_ID, node);=0A= +=0A= /*=0A= * We have the node. We also take over the reference=0A= * that the list had on it.=0A= @@ -3310,9 +3326,9 @@ ng_worklist_add(node_p node)=0A= NG_WORKLIST_LOCK();=0A= TAILQ_INSERT_TAIL(&ng_worklist, node, nd_work);=0A= NG_WORKLIST_UNLOCK();=0A= - schednetisr(NETISR_NETGRAPH);=0A= CTR3(KTR_NET, "%20s: node [%x] (%p) put on worklist", __func__,=0A= node->nd_ID, node);=0A= + NG_WORKLIST_WAKEUP();=0A= } else {=0A= CTR3(KTR_NET, "%20s: node [%x] (%p) already on worklist",=0A= __func__, node->nd_ID, node);=0A= ------=_NextPart_000_0031_01C9562A.81F768A0-- From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 08:17:11 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C67E11065672 for ; Fri, 5 Dec 2008 08:17:11 +0000 (UTC) (envelope-from antonio.tommasi@unile.it) Received: from cabis.unile.it (cabis.unile.it [212.189.128.35]) by mx1.freebsd.org (Postfix) with ESMTP id 828268FC17 for ; Fri, 5 Dec 2008 08:17:11 +0000 (UTC) (envelope-from antonio.tommasi@unile.it) Received: from localhost (localhost [127.0.0.1]) by cabis.unile.it (Postfix) with ESMTP id DDD7E2E58F for ; Fri, 5 Dec 2008 08:58:42 +0100 (CET) X-Virus-Scanned: virus/spam checker at unile.it Received: from cabis.unile.it ([127.0.0.1]) by localhost (cabis.unile.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yi7L8IBuIUNM for ; Fri, 5 Dec 2008 08:58:34 +0100 (CET) Received: from titto.unile.it (titto.unile.it [212.189.128.38]) by cabis.unile.it (Postfix) with ESMTP id A0EEE2E5E7 for ; Fri, 5 Dec 2008 08:58:34 +0100 (CET) Message-ID: <4938DF2A.6080409@unile.it> Date: Fri, 05 Dec 2008 08:58:34 +0100 From: Antonio Tommasi User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <49376544.70006@redhat.com> <20081204070239.X80401@maildrop.int.zabbadoz.net> In-Reply-To: <20081204070239.X80401@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Virtual machine on freebsd 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, 05 Dec 2008 08:17:11 -0000 Hi to all, i want to install a virtual machine on my FreeBSD 7.0 box. Can you tell me which is the better sofware to do this? Thanks in advance Antonio From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 08:43:43 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FD2B106567A for ; Fri, 5 Dec 2008 08:43:43 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id 75DC38FC16 for ; Fri, 5 Dec 2008 08:43:43 +0000 (UTC) (envelope-from randy@psg.com) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L8WHm-000Ln8-Kc for freebsd-net@freebsd.org; Fri, 05 Dec 2008 08:43:42 +0000 Message-ID: <4938E9BD.3040607@psg.com> Date: Fri, 05 Dec 2008 17:43:41 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: FreeBSD Net X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: bgp, is-is, ... 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, 05 Dec 2008 08:43:43 -0000 openbgp is said to be the best bsd implementation of bgp. but i see that ports/openbgpd has not been updated in a while. it is at 4.0 while 4.3 is the current public release. ports/quagga is at 0.99.10, while the public release is 0.99.11. so that's a bit better. and, as i need is-is, i think quagga is my only choice, yes? i am not seeing any useful is-is docco on the quagga doc pages. but a bit of googling finds some. does the isisd work in a simple lan config, nothing fancy? for two full bgp feeds, is 4g of ram gonna last? or should i get 8g? randy From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 08:48:02 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A649106564A for ; Fri, 5 Dec 2008 08:48:02 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [195.131.4.140]) by mx1.freebsd.org (Postfix) with ESMTP id D8A5C8FC14 for ; Fri, 5 Dec 2008 08:48:01 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from desktop.home.serebryakov.spb.ru (blacklion.dialup.corbina.ru [89.179.122.169]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id 4369F13DF92 for ; Fri, 5 Dec 2008 11:37:34 +0300 (MSK) Date: Fri, 5 Dec 2008 11:29:39 +0300 From: Lev Serebryakov X-Priority: 3 (Normal) Message-ID: <1682252731.20081205112939@serebryakov.spb.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: quoted-printable Subject: NFS performance tuning? 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, 05 Dec 2008 08:48:02 -0000 Hello, Freebsd-net. I have two systems (7-Stable), connected with gigabit link. iperf shows 667 Mbits/sec on TCP and 600Mbit/s on UDP without any tuning. But NFS gives me only 17Mb/s (~136 Mbit/s) on sequential read of very big files, and about 8-10Mb/s on "real" workloads. Are here any guides how to tune NFS for performance? --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 08:58:10 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51D0A1065677; Fri, 5 Dec 2008 08:58:10 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id ED6E38FC14; Fri, 5 Dec 2008 08:58:09 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id 1986D28448; Fri, 5 Dec 2008 16:58:09 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 0FA16EBA5CE; Fri, 5 Dec 2008 16:58:08 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id Kokd2sZTK6Zh; Fri, 5 Dec 2008 16:58:01 +0800 (CST) Received: from charlie.delphij.net (c-67-188-86-197.hsd1.ca.comcast.net [67.188.86.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 8A672EB6808; Fri, 5 Dec 2008 16:58:00 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=uTFvmm97XYxeeliLWRlr8iH2r0dFDsgRTHHolxQMNJs61quIxEeSgYeOU5EXjKKqq pPN9lQTc4/Lv3gLcSJOHg== Message-ID: <4938ED14.8090101@delphij.net> Date: Fri, 05 Dec 2008 00:57:56 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Lev Serebryakov References: <1682252731.20081205112939@serebryakov.spb.ru> In-Reply-To: <1682252731.20081205112939@serebryakov.spb.ru> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: NFS performance tuning? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2008 08:58:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lev Serebryakov wrote: > Hello, Freebsd-net. > > I have two systems (7-Stable), connected with gigabit link. iperf > shows 667 Mbits/sec on TCP and 600Mbit/s on UDP without any tuning. > > But NFS gives me only 17Mb/s (~136 Mbit/s) on sequential read of > very big files, and about 8-10Mb/s on "real" workloads. > > Are here any guides how to tune NFS for performance? rsize/wsize? I think the current default (8192) is too smal, perhaps 262144 would be a better choice. What I usually use is: mount_nfs -3Tr 262144 -w 262144 - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk47RQACgkQi+vbBBjt66BYkwCgh+Eu+C+OJW9WdU7s1qww9GEb c5gAoKotFAXFTNTKD1ac+mNRAufck15t =pdBF -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 09:22:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE80A1065673 for ; Fri, 5 Dec 2008 09:22:53 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from mail.comstyle.com (unknown [IPv6:2001:470:1d:8c::2]) by mx1.freebsd.org (Postfix) with ESMTP id 819288FC08 for ; Fri, 5 Dec 2008 09:22:53 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from [192.168.3.42] (toronto-hs-216-138-195-228.s-ip.magma.ca [216.138.195.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: brad) by mail.comstyle.com (Postfix) with ESMTPSA id CEC709840A; Fri, 5 Dec 2008 04:22:45 -0500 (EST) From: Brad To: freebsd-net@freebsd.org Date: Fri, 5 Dec 2008 04:22:44 -0500 User-Agent: KMail/1.9.10 References: <4938E9BD.3040607@psg.com> In-Reply-To: <4938E9BD.3040607@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812050422.44586.brad@comstyle.com> X-comstyle-MailScanner-Information: Please contact the ISP for more information X-comstyle-MailScanner-ID: CEC709840A.AE639 X-comstyle-MailScanner: Found to be clean X-comstyle-MailScanner-From: brad@comstyle.com X-Spam-Status: No Cc: Randy Bush Subject: Re: bgp, is-is, ... 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, 05 Dec 2008 09:22:53 -0000 On Friday 05 December 2008 03:43:41 Randy Bush wrote: > openbgp is said to be the best bsd implementation of bgp. but i see > that ports/openbgpd has not been updated in a while. it is at 4.0 while > 4.3 is the current public release. Actually 4.4 is the latset release, although only available in CVS. I have prodded Henning again about updating the website/FTP site. The OpenOSPF port could use an update to 4.4. > for two full bgp feeds, is 4g of ram gonna last? or should i get 8g? A machine with 512MB of memory should have no problem with 3 maybe 4 feeds depending on BGP implementation and setup. So 2GB should be more than enough -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 09:28:43 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8148106564A for ; Fri, 5 Dec 2008 09:28:43 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id C1A038FC1A for ; Fri, 5 Dec 2008 09:28:43 +0000 (UTC) (envelope-from randy@psg.com) Received: from 50.216.138.210.bn.2iij.net ([210.138.216.50] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1L8WzL-000LsY-0t; Fri, 05 Dec 2008 09:28:43 +0000 Message-ID: <4938F449.3000401@psg.com> Date: Fri, 05 Dec 2008 18:28:41 +0900 From: Randy Bush User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Brad References: <4938E9BD.3040607@psg.com> <200812050422.44586.brad@comstyle.com> In-Reply-To: <200812050422.44586.brad@comstyle.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: bgp, is-is, ... 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, 05 Dec 2008 09:28:43 -0000 Brad wrote: > On Friday 05 December 2008 03:43:41 Randy Bush wrote: >> openbgp is said to be the best bsd implementation of bgp. but i see >> that ports/openbgpd has not been updated in a while. it is at 4.0 while >> 4.3 is the current public release. > Actually 4.4 is the latset release, although only available in CVS. I have > prodded Henning again about updating the website/FTP site. > The OpenOSPF port could use an update to 4.4. but no is-is? not to start an emacs/vi debate, but most of us old pharts are is-is, as are the big old backbones (and the smarter new ones:-). >> for two full bgp feeds, is 4g of ram gonna last? or should i get 8g? > A machine with 512MB of memory should have no problem with 3 maybe 4 feeds > depending on BGP implementation and setup. So 2GB should be more than enough cool. this will have at least two ibgp peers who have full external transit feeds, i.e. 200k prefixes each. randy From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 09:38:50 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3AA7D1065673 for ; Fri, 5 Dec 2008 09:38:50 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from mail.comstyle.com (unknown [IPv6:2001:470:1d:8c::2]) by mx1.freebsd.org (Postfix) with ESMTP id 0C5AE8FC21 for ; Fri, 5 Dec 2008 09:38:50 +0000 (UTC) (envelope-from brad@comstyle.com) Received: from [192.168.3.42] (toronto-hs-216-138-195-228.s-ip.magma.ca [216.138.195.228]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: brad) by mail.comstyle.com (Postfix) with ESMTPSA id DD81A9840A; Fri, 5 Dec 2008 04:38:42 -0500 (EST) From: Brad To: Randy Bush Date: Fri, 5 Dec 2008 04:38:41 -0500 User-Agent: KMail/1.9.10 References: <4938E9BD.3040607@psg.com> <200812050422.44586.brad@comstyle.com> <4938F449.3000401@psg.com> In-Reply-To: <4938F449.3000401@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812050438.42163.brad@comstyle.com> X-comstyle-MailScanner-Information: Please contact the ISP for more information X-comstyle-MailScanner-ID: DD81A9840A.60655 X-comstyle-MailScanner: Found to be clean X-comstyle-MailScanner-From: brad@comstyle.com X-Spam-Status: No Cc: freebsd-net@freebsd.org Subject: Re: bgp, is-is, ... 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, 05 Dec 2008 09:38:50 -0000 On Friday 05 December 2008 04:28:41 Randy Bush wrote: > but no is-is? not to start an emacs/vi debate, but most of us old > pharts are is-is, as are the big old backbones (and the smarter new > ones:-). Not yet. You're welcome to help start an isisd. ;) So far BGP, OSPF, RIP and DVMRP working. OSPF6d started. > >> for two full bgp feeds, is 4g of ram gonna last? or should i get 8g? > > > > A machine with 512MB of memory should have no problem with 3 maybe 4 > > feeds depending on BGP implementation and setup. So 2GB should be more > > than enough > > cool. this will have at least two ibgp peers who have full external > transit feeds, i.e. 200k prefixes each. Ya, with how cheap memory is for anything you will most likely use there is no point not having at least 1GB and that will provide more than enough memory to work with. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 12:10:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A8824106568A for ; Fri, 5 Dec 2008 12:10:13 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from ftp.translate.ru (ftp.translate.ru [195.131.4.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4E6A18FC19 for ; Fri, 5 Dec 2008 12:10:13 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.18.98.63] (brmea-proxy-2.Sun.COM [192.18.98.63]) (Authenticated sender: lev@serebryakov.spb.ru) by ftp.translate.ru (Postfix) with ESMTPA id C148313DF5C; Fri, 5 Dec 2008 15:17:59 +0300 (MSK) Message-ID: <49391A5C.50302@FreeBSD.org> Date: Fri, 05 Dec 2008 15:11:08 +0300 From: Lev Serebryakov Organization: FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.14) Gecko/20071210 Thunderbird/1.5.0.14 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: d@delphij.net References: <1682252731.20081205112939@serebryakov.spb.ru> <4938ED14.8090101@delphij.net> In-Reply-To: <4938ED14.8090101@delphij.net> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: NFS performance tuning? 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, 05 Dec 2008 12:10:13 -0000 Xin LI wrote: > What I usually use is: > mount_nfs -3Tr 262144 -w 262144 Yep, it helps to double speed. Much better. How should these options translates to /etc/fstab options? -- // Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 14:10:50 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57EAE1065673 for ; Fri, 5 Dec 2008 14:10:50 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id DA9D58FC0C for ; Fri, 5 Dec 2008 14:10:49 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: by nf-out-0910.google.com with SMTP id h3so5900nfh.33 for ; Fri, 05 Dec 2008 06:10:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=1str9SeiCGu0rygTHpqZRrqAMWgM9TaxCReiZSDw+Vs=; b=OEqYR+K5X6YSox6e1tgwAfblm8iKWnb4luL/8cHFBtUaTzZ7enkf0w4XDZrEZ2CaF9 /6jXnSWWKaTv3GmT2Ti7dN3kbTS3ERUA4mbQai66W3FP0SyiPqgCoKiz+cC7bjwkvu1s DVzn9iE3HqM23KOMUvpXczCs/emiNCHbODAQU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=fXdqZRgAYWA7xIRuuSqM+cER99VWMSWtkiP/P0Lr55Fi16AHGfo7ALHFehK3pBe3Kw yDbBUZlcROQEOVi7fWjOxlHlGA9viyjaFsu7ktOgXNfsmH8sPRRVwlijx3APbwP1U5/V 84zSYpJuSbSbp5SRFFLhDCVjTApKpTzEPB2ck= Received: by 10.210.46.4 with SMTP id t4mr23768ebt.49.1228484557427; Fri, 05 Dec 2008 05:42:37 -0800 (PST) Received: from localhost.localdomain ([213.152.137.42]) by mx.google.com with ESMTPS id 7sm56869eyb.54.2008.12.05.05.42.35 (version=SSLv3 cipher=RC4-MD5); Fri, 05 Dec 2008 05:42:36 -0800 (PST) Message-ID: <49392FDD.8050209@gmail.com> Date: Fri, 05 Dec 2008 16:42:53 +0300 From: Vladimir Ermakov User-Agent: Thunderbird 2.0.0.18 (X11/20081119) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: vlan support trouble in if_sis 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: Fri, 05 Dec 2008 14:10:50 -0000 Hello Using sis card (SiS 900) sis0: port 0xe800-0xe8ff mem 0xed160000-0xed160fff irq 19 at device 4.0 on pci0 # uname -a FreeBSD damask 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 # netstat -bin Name Mtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll sis0 1500 00:0d:61:xx:xx:xx 356 4 40934 155 0 29276 0 em0 1500 00:02:55:xx:xx:xx 0 0 0 0 0 0 0 lo0 16384 0 0 0 0 0 0 0 lo0 16384 fe80:3::1/64 fe80:3::1 0 - 0 0 - 0 - lo0 16384 ::1/128 ::1 0 - 0 0 - 0 - lo0 16384 127.0.0.0/8 127.0.0.1 0 - 0 0 - 0 - vlan0 1500 00:02:55:xx:xx:xx 0 0 0 0 0 0 0 vlan1 1500 00:0d:61:xx:xx:xx 255 0 29543 155 0 28656 0 # ifconfig sis0 sis0: flags=8843 metric 0 mtu 1500 options=8 ether 00:0d:61:xx:xx:xx media: Ethernet autoselect (100baseTX ) status: active # ifconfig vlan1 vlan1: flags=8843 metric 0 mtu 1500 ether 00:0d:61:xx:xx:xx inet 192.168.1.221 netmask 0xffffff80 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active vlan: 12 parent interface: sis0 noticed the following troubles with using interface vlan1 (vlandev sis0): - can not download a file using fget tool - increases Ierrs on the physical interface sis0 this bug in if_sis driver ? /Vladimir Ermakov From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 14:40:23 2008 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3639B1065673; Fri, 5 Dec 2008 14:40:23 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2594F8FC1C; Fri, 5 Dec 2008 14:40:23 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (glebius@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id mB5EeNLE087022; Fri, 5 Dec 2008 14:40:23 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id mB5EeMm3086907; Fri, 5 Dec 2008 14:40:22 GMT (envelope-from glebius) Date: Fri, 5 Dec 2008 14:40:22 GMT Message-Id: <200812051440.mB5EeMm3086907@freefall.freebsd.org> To: melifaro@ipfw.ru, glebius@FreeBSD.org, freebsd-net@FreeBSD.org, glebius@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/126984: [carp][patch] add carp userland notifications via devctl(4) 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, 05 Dec 2008 14:40:23 -0000 Synopsis: [carp][patch] add carp userland notifications via devctl(4) State-Changed-From-To: open->feedback State-Changed-By: glebius State-Changed-When: Fri Dec 5 14:37:54 UTC 2008 State-Changed-Why: I've just committed a change that makes link state change announcement when CARP changes status. This includes devd announcement. This is more standard than arbitrary message and also makes us compatible with OpenBSD. Alexander, are you satisfied with this change? Can the PR be closed after merging? Responsible-Changed-From-To: freebsd-net->glebius Responsible-Changed-By: glebius Responsible-Changed-When: Fri Dec 5 14:37:54 UTC 2008 Responsible-Changed-Why: I've just committed a change that makes link state change announcement when CARP changes status. This includes devd announcement. This is more standard than arbitrary message and also makes us compatible with OpenBSD. Alexander, are you satisfied with this change? Can the PR be closed after merging? http://www.freebsd.org/cgi/query-pr.cgi?pr=126984 From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 16:50:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 788A61065670 for ; Fri, 5 Dec 2008 16:50:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.freebsd.org (Postfix) with ESMTP id 16AC48FC0C for ; Fri, 5 Dec 2008 16:50:17 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c122-106-153-252.carlnfd1.nsw.optusnet.com.au (c122-106-153-252.carlnfd1.nsw.optusnet.com.au [122.106.153.252]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mB5Gluqu021720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Dec 2008 03:47:59 +1100 Date: Sat, 6 Dec 2008 03:47:57 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: d@delphij.net In-Reply-To: <4938ED14.8090101@delphij.net> Message-ID: <20081206031724.F76672@delplex.bde.org> References: <1682252731.20081205112939@serebryakov.spb.ru> <4938ED14.8090101@delphij.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, Lev Serebryakov Subject: Re: NFS performance tuning? 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, 05 Dec 2008 16:50:18 -0000 On Fri, 5 Dec 2008, Xin LI wrote: > Lev Serebryakov wrote: >> Hello, Freebsd-net. >> >> I have two systems (7-Stable), connected with gigabit link. iperf >> shows 667 Mbits/sec on TCP and 600Mbit/s on UDP without any tuning. >> >> But NFS gives me only 17Mb/s (~136 Mbit/s) on sequential read of MB >> very big files, and about 8-10Mb/s on "real" workloads. >> >> Are here any guides how to tune NFS for performance? > > rsize/wsize? I think the current default (8192) is too smal, perhaps > 262144 would be a better choice. The defaults of NFS_RSIZE/NFS_WSIZE (8192/8192) are only used for udp. The default is NFS_MAXDATA (32768) for tcp. This is large enough. > What I usually use is: > > mount_nfs -3Tr 262144 -w 262144 262144 is not supported. Size parameters larger than MAXBSIZE (65536) are silently reduced to MAXBSIZE. I use the defaults with tcp and IIRC 16K/16K with udp. IIRC 32K/32K doesn't work so well with udp, and there is a bug setting the defaults when toggling -T (apparently, defaults are only set initially, so if you start with udp and switch to tcp you keep the udp defaults for tcp, and vice versa). I use several optimizations for writing in the nfs server and several bug fixes for reading and writing in vfs clustering. Nfs latency is more of a problem than nfs throughput for some applications. E.g., compiling can take several times longer on nfs mainly because most of the time is spent waiting to reopen many include files many times each (the data normally remains cached after the first used, but each open() requires RPCs). I tune networks for latency and use some hacks to reduce the number of nfs RPCs, and compile with -j4 even on UP systems to reduce the effects of nonzero latency. Bruce From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 17:35:00 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 455C71065675 for ; Fri, 5 Dec 2008 17:35:00 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id 257C98FC14 for ; Fri, 5 Dec 2008 17:35:00 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id A99591A000B32 for ; Fri, 5 Dec 2008 09:13:05 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id HJ5f5DLMiogO for ; Fri, 5 Dec 2008 09:13:01 -0800 (PST) Received: from coal.localnet (unknown [192.168.0.10]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 70C3F1A000B29 for ; Fri, 5 Dec 2008 09:13:01 -0800 (PST) From: Freddie Cash To: freebsd-net@freebsd.org Date: Fri, 5 Dec 2008 09:13:00 -0800 User-Agent: KMail/1.10.3 (Linux/2.6.26-1-686; KDE/4.1.3; i686; ; ) References: <49376544.70006@redhat.com> <20081204070239.X80401@maildrop.int.zabbadoz.net> <4938DF2A.6080409@unile.it> In-Reply-To: <4938DF2A.6080409@unile.it> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812050913.00889.fjwcash@gmail.com> Subject: Re: Virtual machine on freebsd 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, 05 Dec 2008 17:35:00 -0000 On December 4, 2008 11:58 pm Antonio Tommasi wrote: > Hi to all, > i want to install a virtual machine on my FreeBSD 7.0 box. Can you tell > me which is the better sofware to do this? For a FreeBSD host, QEmu is the best supported option. There's also Win4BSD, which is a customised/modified version of QEmu. I've seen several reports online of this being better/faster than QEmu. I've never personally been able to get it to work, though. And that's pretty much it if you want full-OS virtualisation (ie, the VMs have their own OS). If you don't need that, and just want to run multiple FreeBSD setups on one host, have a look at jail(8). -- Freddie fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 19:44:56 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60ED21065673 for ; Fri, 5 Dec 2008 19:44:56 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.freebsd.org (Postfix) with ESMTP id E7C288FC0A for ; Fri, 5 Dec 2008 19:44:55 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (c122-106-215-175.belrs3.nsw.optusnet.com.au [122.106.215.175]) by mail13.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id mB5Jioc3026992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Dec 2008 06:44:51 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id mB5JinMn028467; Sat, 6 Dec 2008 06:44:49 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id mB5JinOW028466; Sat, 6 Dec 2008 06:44:49 +1100 (EST) (envelope-from peter) Date: Sat, 6 Dec 2008 06:44:49 +1100 From: Peter Jeremy To: Benjie Chen Message-ID: <20081205194449.GL58682@server.vk2pj.dyndns.org> References: <20081203193609.GB58682@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/NwG7NuG0/W8LcLh" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-net@freebsd.org Subject: Re: Weird TCP connect issue in FreeBSD 6 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, 05 Dec 2008 19:44:56 -0000 --/NwG7NuG0/W8LcLh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-Dec-03 17:40:01 -0500, Benjie Chen wrote: >When I had two IPs from two different subnets configured for the two >NICs, I had the same error. So while I did have a configuration issue, >the problem with replicated SYNs did occur even when the two NICs had >IP addresses on different networks. OK, that does sound wrong. Can you describe that setup please - what local addresses/netmasks and routes did you have and what was the remote IP address. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --/NwG7NuG0/W8LcLh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkk5hLEACgkQ/opHv/APuIddGgCeNRp0AWV3gUKJ4cYXErdPuexf imcAnRq4KuuES3AfGsFp2w6RKB4dNsdf =51ge -----END PGP SIGNATURE----- --/NwG7NuG0/W8LcLh-- From owner-freebsd-net@FreeBSD.ORG Fri Dec 5 23:22:37 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FDCC1065670 for ; Fri, 5 Dec 2008 23:22:37 +0000 (UTC) (envelope-from benjie@addgene.org) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by mx1.freebsd.org (Postfix) with ESMTP id 1F1DE8FC1E for ; Fri, 5 Dec 2008 23:22:37 +0000 (UTC) (envelope-from benjie@addgene.org) Received: by wf-out-1314.google.com with SMTP id 24so207376wfg.7 for ; Fri, 05 Dec 2008 15:22:36 -0800 (PST) Received: by 10.143.9.9 with SMTP id m9mr225378wfi.41.1228519356754; Fri, 05 Dec 2008 15:22:36 -0800 (PST) Received: by 10.142.179.19 with HTTP; Fri, 5 Dec 2008 15:22:36 -0800 (PST) Message-ID: Date: Fri, 5 Dec 2008 18:22:36 -0500 From: "Benjie Chen" To: "Peter Jeremy" In-Reply-To: <20081205194449.GL58682@server.vk2pj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20081203193609.GB58682@server.vk2pj.dyndns.org> <20081205194449.GL58682@server.vk2pj.dyndns.org> Cc: freebsd-net@freebsd.org Subject: Re: Weird TCP connect issue in FreeBSD 6 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, 05 Dec 2008 23:22:37 -0000 Local address em0: some IP XXX, with appropriate mask, /27 em1: some IP YYY, on different subnet, with appropriate mask /27 apache: listening on XXX:80, YYY:80, XXX:443, YYY:443 I can connect to the 80 ports on both machine from a third IP on yet another network, and I can connect to XXX:443 just fine. Connecting to YYY:443 results in connection termination frequently, but not all the time. Tcpdump on XXX shows packets are coming into em1 and returned on em0, and that when termination occurs, initial SYN from client to YYY:443 is repeated many many times, resulting in many SYN ACKs and then later on ACKs from the client. I think syn-attack protecting code then kicks in and send a RST to tear down the connection on the server (this part I understand, but not sure why the SYN packets are repeatedly sent to the kernel) Benjie --- Benjie Chen, Ph.D. Addgene, a better way to share plasmids www.addgene.org Manage your lab more efficiently Addgene Labs - www.addgenelabs.org On Fri, Dec 5, 2008 at 2:44 PM, Peter Jeremy wrote: > On 2008-Dec-03 17:40:01 -0500, Benjie Chen wrote: >>When I had two IPs from two different subnets configured for the two >>NICs, I had the same error. So while I did have a configuration issue, >>the problem with replicated SYNs did occur even when the two NICs had >>IP addresses on different networks. > > OK, that does sound wrong. Can you describe that setup please - what > local addresses/netmasks and routes did you have and what was the > remote IP address. > > -- > Peter Jeremy > Please excuse any delays as the result of my ISP's inability to implement > an MTA that is either RFC2821-compliant or matches their claimed behaviour. > From owner-freebsd-net@FreeBSD.ORG Sat Dec 6 02:22:13 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 457791065670 for ; Sat, 6 Dec 2008 02:22:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.225]) by mx1.freebsd.org (Postfix) with ESMTP id 0C32A8FC1A for ; Sat, 6 Dec 2008 02:22:12 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id b25so264314rvf.43 for ; Fri, 05 Dec 2008 18:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received:date:from :to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=4kGByYz+XLQf/K+xfikfHCBI+3b0p01oUnm5BqQ0Ekw=; b=L3fqW60MJ4SjO4+6WM8gvhUoXwQx//x6/hK9Y8/FCCqavXxDEReSVpYamZ+DsGKd9U pkQV0sQWHc7Dsbw6VAPQtSQXBlSzubrlQh2pEWR1h1M8aBoAyJTXZzCZYkkcaJKbQpKt O3R2hK8hh92NDqVGTmMMwqHbjKxsPdSO3jQDY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=qfLeHG1lynA/lKG8t6pYMuat1Er7+eNa4JQuWRabYNcldCv0wyu8Rq2wnyIEe77fTZ VKaztWJJEoVNePnjAqgaemF1Ye1EZkA3vXV9Ued3UqDzxG0cFaoq17IcWw/TLR6z6XK3 cTTUd2+hdD6FEumbxGRqqu5FOfaAxAeD5DOw8= Received: by 10.141.197.14 with SMTP id z14mr310195rvp.203.1228530132496; Fri, 05 Dec 2008 18:22:12 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([211.53.35.84]) by mx.google.com with ESMTPS id k37sm586048rvb.1.2008.12.05.18.22.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 05 Dec 2008 18:22:11 -0800 (PST) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id mB62M5gb022619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 6 Dec 2008 11:22:05 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id mB62M5Ig022618; Sat, 6 Dec 2008 11:22:05 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 6 Dec 2008 11:22:05 +0900 From: Pyun YongHyeon To: Vladimir Ermakov Message-ID: <20081206022205.GD22093@cdnetworks.co.kr> References: <49392FDD.8050209@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="1LKvkjL3sHcu1TtY" Content-Disposition: inline In-Reply-To: <49392FDD.8050209@gmail.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-net@freebsd.org Subject: Re: vlan support trouble in if_sis driver ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2008 02:22:13 -0000 --1LKvkjL3sHcu1TtY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Dec 05, 2008 at 04:42:53PM +0300, Vladimir Ermakov wrote: > Hello > > Using sis card (SiS 900) > sis0: port 0xe800-0xe8ff mem > 0xed160000-0xed160fff irq 19 at device 4.0 on pci0 > > # uname -a > FreeBSD damask 7.0-RELEASE FreeBSD 7.0-RELEASE #0: Sun Feb 24 19:59:52 > UTC 2008 root@logan.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386 > > # netstat -bin > Name Mtu Network Address Ipkts Ierrs Ibytes > Opkts Oerrs Obytes Coll > sis0 1500 00:0d:61:xx:xx:xx 356 4 > 40934 155 0 29276 0 > em0 1500 00:02:55:xx:xx:xx 0 0 > 0 0 0 0 0 > lo0 16384 0 0 > 0 0 0 0 0 > lo0 16384 fe80:3::1/64 fe80:3::1 0 - > 0 0 - 0 - > lo0 16384 ::1/128 ::1 0 - > 0 0 - 0 - > lo0 16384 127.0.0.0/8 127.0.0.1 0 - > 0 0 - 0 - > vlan0 1500 00:02:55:xx:xx:xx 0 0 > 0 0 0 0 0 > vlan1 1500 00:0d:61:xx:xx:xx 255 0 > 29543 155 0 28656 0 > > # ifconfig sis0 > sis0: flags=8843 metric 0 mtu 1500 > options=8 > ether 00:0d:61:xx:xx:xx > media: Ethernet autoselect (100baseTX ) > status: active > # ifconfig vlan1 > vlan1: flags=8843 metric 0 mtu 1500 > ether 00:0d:61:xx:xx:xx > inet 192.168.1.221 netmask 0xffffff80 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > status: active > vlan: 12 parent interface: sis0 > > noticed the following troubles with using interface vlan1 (vlandev sis0): > - can not download a file using fget tool > - increases Ierrs on the physical interface sis0 > > this bug in if_sis driver ? I don't have sis(4) hardwares so I'm not sure it's bug. Since you see Ierrs on parent interface sis0, I guess the hardware might set a giant bit when it receives VLAN frames. Driver might think it received errored frames which in turn make driver drop these VLAN frames. Would you try attached patch?(Just compile tested). -- Regards, Pyun YongHyeon --1LKvkjL3sHcu1TtY Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="sis.vlan.patch" Index: sys/dev/sis/if_sisreg.h =================================================================== --- sys/dev/sis/if_sisreg.h (revision 185658) +++ sys/dev/sis/if_sisreg.h (working copy) @@ -348,6 +348,11 @@ #define SIS_RXSTAT_OVERRUN 0x02000000 #define SIS_RXSTAT_RX_ABORT 0x04000000 +#define SIS_RXSTAT_ERROR(x) \ + ((x) & (SIS_RXSTAT_RX_ABORT | SIS_RXSTAT_OVERRUN | \ + SIS_RXSTAT_GIANT | SIS_RXSTAT_SYMBOLERR | SIS_RXSTAT_RUNT | \ + SIS_RXSTAT_CRCERR | SIS_RXSTAT_ALIGNERR)) + #define SIS_DSTCLASS_REJECT 0x00000000 #define SIS_DSTCLASS_UNICAST 0x00800000 #define SIS_DSTCLASS_MULTICAST 0x01000000 Index: sys/dev/sis/if_sis.c =================================================================== --- sys/dev/sis/if_sis.c (revision 185658) +++ sys/dev/sis/if_sis.c (working copy) @@ -1432,7 +1432,11 @@ * it should simply get re-used next time this descriptor * comes up in the ring. */ - if (!(rxstat & SIS_CMDSTS_PKT_OK)) { + if ((ifp->if_capenable & IFCAP_VLAN_MTU) != 0 && + total_len <= (ETHER_MAX_LEN + ETHER_VLAN_ENCAP_LEN - + ETHER_CRC_LEN)) + rxstat &= ~SIS_RXSTAT_GIANT; + if (SIS_RXSTAT_ERROR(rxstat) != 0) { ifp->if_ierrors++; if (rxstat & SIS_RXSTAT_COLL) ifp->if_collisions++; --1LKvkjL3sHcu1TtY-- From owner-freebsd-net@FreeBSD.ORG Sat Dec 6 15:40:18 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C813106567A for ; Sat, 6 Dec 2008 15:40:18 +0000 (UTC) (envelope-from healthy-wealthy-tea@freemail.lt) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by mx1.freebsd.org (Postfix) with ESMTP id EC3DE8FC23 for ; Sat, 6 Dec 2008 15:40:17 +0000 (UTC) (envelope-from healthy-wealthy-tea@freemail.lt) Received: from infong660.perfora.net (infong660.lxa.perfora.net [74.208.16.166]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0MKp8S-1L8z4H1rYY-0006fz; Sat, 06 Dec 2008 10:27:42 -0500 Received: from 121.97.158.125 (IP may be forged by CGI script) by infong660.perfora.net with HTTP id 3oUmtk-1L8z4H1rqZ-00050t; Sat, 06 Dec 2008 10:27:41 -0500 X-Sender-Info: <155977404@infong660.perfora.net> Date: Sat, 06 Dec 2008 10:27:41 -0500 Message-Id: <3oUmtk-1L8z4H1rqZ-00050t@infong660.perfora.net> Precedence: bulk To: "freebsd-net" From: "healthy-wealthy-tea freebsd-net" MIME-Version: 1.0 X-Mailer: Zen Cart Mailer Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX1+1sRTavg3+oZAVRCNEllP6Yc2VnAejViqg0kT Q5Fqz0joxvaNYf3PutePcaOt3AFTZ7rcdpmOOCFRLhYACbj42h 8/HZ78t/Hg= Subject: Your friend healthy-wealthy-tea freebsd-net has recommended this great product from Green Tea & Me X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Dec 2008 15:40:18 -0000 Hi freebsd-net! Your friend, healthy-wealthy-tea freebsd-net, thought that you would be interested in Matcha from Green Tea & Me. healthy-wealthy-tea freebsd-net sent a note saying: Amazing News, Get Paid, Look Smart And Stay Healthy! Hi Friend, Here's how it works... First, we detoxifies your body. Second, we burn your unwanted fats. Thus, we make all your friends jealous because you will actually lose weight the first day. And Third, you'll be paid the moment you start spreading the good news for others to try themselves with this extraordinary product. Visit this very important link below now!. http://123redirect.com/healthy-and-wealthy-tea So Goodluck, Look Good And Be Healthy, Associates http://123redirect.com/healthy-and-wealthy-tea Online Promoter P.S. Dr. Miller's Iaso Tea - formulated by Dr. Bill Miller (Bs.Ms.Ph.D. Nutritional Science) of Tennessee, USA - is a unique herbal blend of safe, all-natural ingredients designed to gently cleanse the digestive tract and detoxify the whole body. Iaso Tea is like a white tea, a green tea, a weight loss tea, and a great-tasting herbal tea - all wrapped up in each unbleached tea bag. But, most of all, Dr. Miller's Iaso Tea is a healing tea. Remarkable things happen when you drink Iaso Tea every day. It is gentle, yet surprisingly powerful as a colon cleanse, parasite cleanse, Candida cleanse, blood purifier, and whole body detoxifier. It acts like a general health tonic and a home remedy for many ailments like the ones mentioned below. Some want to call it a "miracle tea", but this cleansing and slimming tea is really just a special blend of high-quality herbs, tested and refined over time, which produce fast and effective results that no imitator has been able to copy. ------------------------------ Email here: healthy-wealthy-tea@freemail.lt and add "Not interested" ---------------------------------------------------------------------------------------- To view the product, click on the link below or copy and paste the link into your web browser: http://www.greenteame.com/store/index.php?main_page=product_info&products_id=1 Regards, Green Tea & Me http://www.greenteame.com/store/ ----- IMPORTANT: For your protection and to prevent malicious use, all emails sent via this web site are logged and the contents recorded and available to the store owner. If you feel that you have received this email in error, please send an email to customersupport@greenteame.com From owner-freebsd-net@FreeBSD.ORG Sat Dec 6 18:55:53 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33A011065672 for ; Sat, 6 Dec 2008 18:55:53 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by mx1.freebsd.org (Postfix) with ESMTP id 05F918FC17 for ; Sat, 6 Dec 2008 18:55:52 +0000 (UTC) (envelope-from samflanker@gmail.com) Received: by wa-out-1112.google.com with SMTP id m34so241666wag.27 for ; Sat, 06 Dec 2008 10:55:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=DeadQQXYPhyqVy7V4Q5PGk1lm1GKlZjrkzW/vzn5Gww=; b=clTX+ZnQ4lRqwZSSEV4/ncdfX5vWlmY+an8EQorekgKQCw3rYzl519KekzFqPqQnds jj8K5alS9MytXOKk/iuy/H7k0Mv85fwigFHUvWKo/C/HUzA5i7XzBooywoELCpoyuCLt Morq7L4c4bgRzr3D/JMTvz94sqfdIOm9sAkXg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=HNnA+MCIA3vnv38cH5MwfWw0bzr4ge2GlNJRFUNMYfj7wgO2l2TggO+eCiC5nR5LiZ 3M/f4cuhxjAe7HF5nwm6eIt8nKvCohkP8tpy7n0s7Rw96h0e1zdS4Vf3nyG5tPq2stm1 YqxmqQkBm6xLqw1NngVwJl8MeHSlYQHdKfJPA= Received: by 10.115.78.1 with SMTP id f1mr1073105wal.157.1228589752694; Sat, 06 Dec 2008 10:55:52 -0800 (PST) Received: by 10.114.135.19 with HTTP; Sat, 6 Dec 2008 10:55:52 -0800 (PST) Message-ID: Date: Sat, 6 Dec 2008 21:55:52 +0300 From: "Vladimir Ermakov" To: pyunyh@gmail.com In-Reply-To: <20081206022205.GD22093@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <49392FDD.8050209@gmail.com> <20081206022205.GD22093@cdnetworks.co.kr> Cc: freebsd-net@freebsd.org Subject: Re: vlan support trouble in if_sis 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, 06 Dec 2008 18:55:53 -0000 > I don't have sis(4) hardwares so I'm not sure it's bug. Since you > see Ierrs on parent interface sis0, I guess the hardware might set > a giant bit when it receives VLAN frames. Driver might think it > received errored frames which in turn make driver drop these VLAN > frames. Thanks, your patch fixes a problem with the card (sis). in the output of netstat no errors and files downloaded through fget what tests need to try? /Vladimir Ermakov