From owner-freebsd-net@FreeBSD.ORG Sun Nov 22 00:50:03 2009 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 882F31065672 for ; Sun, 22 Nov 2009 00:50: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 6DB448FC18 for ; Sun, 22 Nov 2009 00:50:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAM0o3Kf016284 for ; Sun, 22 Nov 2009 00:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAM0o3g2016283; Sun, 22 Nov 2009 00:50:03 GMT (envelope-from gnats) Date: Sun, 22 Nov 2009 00:50:03 GMT Message-Id: <200911220050.nAM0o3g2016283@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Bruce Cran Cc: Subject: Re: kern/139162: [fwip] [panic] 8.0-RC1 panics if using IP over firewire X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bruce Cran List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 00:50:03 -0000 The following reply was made to PR kern/139162; it has been noted by GNATS. From: Bruce Cran To: bug-followup@FreeBSD.org, numisemis@yahoo.com Cc: Subject: Re: kern/139162: [fwip] [panic] 8.0-RC1 panics if using IP over firewire Date: Sun, 22 Nov 2009 00:46:08 +0000 I get the same panic on 9.0-CURRENT from 15th November. Here's a backtrace: callout_reset_on() at callout_reset_on+0x48 arpintr() at arpintr+0xd8e netisr_dispatch_src() at netisr_dispatch_src+0xb8 firewire_input() at firewire_input+0x56c fwip_unicast_input() at fwip_unicast_input+0x13a fwohci_arcv() at fwohci_arcv+0x30b fwohci_task_dma() at fwohci_task_dma+0x751 taskqueue_run() at taskqueue_run+0x91 taskqueue_thread_loop() at taskqueue_thread_loop+0x3f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff8076f73d30, rbp = 0 --- -- Bruce Cran From owner-freebsd-net@FreeBSD.ORG Sun Nov 22 02:48:58 2009 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 06243106566B for ; Sun, 22 Nov 2009 02:48:58 +0000 (UTC) (envelope-from freebsd-net@adam.gs) Received: from mail.adam.gs (mail.adam.gs [76.9.2.116]) by mx1.freebsd.org (Postfix) with ESMTP id D859B8FC17 for ; Sun, 22 Nov 2009 02:48:57 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.adam.gs (Postfix) with ESMTP id 339C13D8ECF for ; Sat, 21 Nov 2009 21:32:46 -0500 (EST) From: Adam Jacob Muller Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 21 Nov 2009 21:32:45 -0500 Message-Id: <35F73C4F-3C77-4B40-9D7D-16BEB8FE6EAD@adam.gs> To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1077) X-Authentication: KBjQjPlS6fNSIGpVdWXovG+Bdso/EEjNT+I4SU49Atn++FyB4WRlwbAEYBlTasU67P2ARaJZB5n57xFH2imLr186pjwjlxAAczTZWkgBe4Aah2U46PL7n4zwHnko5bk08OAmtyktaS9fxwOB8eAj2axEV3VH7KGTVsjVDOxv7epHOfEjlmTR96WG3w== Subject: openbgpd + 8.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 02:48:58 -0000 Hi, I have an openbgpd running on an 8.0 box where openbgpd crashes (exits = silently) whenever an interface on the system (vlan/tun/tap s are = dynamically created here) is removed. I've traced the error back to kroute.c:dispatch_rtmsg_addr if ((sa =3D rti_info[RTAX_DST]) =3D=3D NULL) { This check is failing, which returns -1, which is passed up = (dispatch_rtmsg up to kr_dispatch_msg up to bgpd.c main() whcih sets = exit=3D1). Unfortunately, this is quickly approaching=20 Any idea what exactly is going on here? I'm not 100% sure but I think this is a regression from 7.x, I don't = have any 7.x systems I can test this on at the moment unfortunately. I've subverted this check by, simply, not setting quit=3D1 in main.c = when kr_dispatch_msg() fails, and everything SEEMS to operate normally, = i'm kinda curious to hear thoughts on this though... -Adam= From owner-freebsd-net@FreeBSD.ORG Sun Nov 22 04:55:09 2009 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 0B16C1065695 for ; Sun, 22 Nov 2009 04:55:09 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id C0E9A8FC2E for ; Sun, 22 Nov 2009 04:55:08 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 75AE348AF1; Sun, 22 Nov 2009 04:55:07 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHgcsmzSh8up; Sun, 22 Nov 2009 04:55:01 +0000 (GMT) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id B448B48AE5; Sun, 22 Nov 2009 04:55:00 +0000 (GMT) Message-ID: <4B08C3DC.1080607@tomjudge.com> Date: Sun, 22 Nov 2009 04:53:48 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Josh Paetzel References: <4B0825DD.3000702@tomjudge.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "net@freebsd.org" Subject: Re: if_bridge as if_vlan parent X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 04:55:09 -0000 Josh Paetzel wrote: > On Nov 21, 2009, at 11:39 AM, Tom Judge wrote: > >> Hi, >> >> I was why I get the following error when trying to create a vlan on top of if_bridge: >> >> # ifconfig bridge0 create >> # ifconfig vlan2 vlan 2 vlandev bridge0 >> ifconfig: SIOCSETVLAN: Protocol not supported >> >> >> And if there was/is any reason for this to not be supported. >> >> Thanks >> > > > You can create a bridge from a pair of vlan devices.... > > # ifconfig vlan1 create > # ifcconfig vlan2 create > # ifconfig bridge0 create > # ifconfig vlan1 vlan 1 vlandev em0 > # ifconfig vlan2 vlan 2 vlandev em0 > # ifconfig bridge0 addm vlan1 addm vlan2 > > Is that more in line with what you want to do? > > I'm a little curious what problem set using a bridge as the parent of a vlan solves though. > > You have the problem upside down. I am trying to bridge 2 trunk ports on 2 separate switches with a FreeBSD box, and I would like to access a number of tagged vlans on the trunk with the FreeBSD box. [sw1-1/g1]->[FBSD-em0]-[FBSD-bridge0]-[FBSD-em1]->[sw2-1/g1] / \ [FBSD-vlan2] [FBSD-vlan200] So: ifconfig em0 up ifconfig em1 up ifconfig bridge0 create ifconfig bridge0 addm em0 stp em0 addm em1 stp em1 up ifconfig vlan2 create ifconfig vlan2 10.0.0.1/24 vlan 2 vlandev bridge0 ifconfig vlan200 create ifconfig vlan200 10.9.9.1/24 vlan 200 vlandev bridge0 This will fail when I try to attach the if_vlan's to the if_bridge. Tom From owner-freebsd-net@FreeBSD.ORG Sun Nov 22 12:11:19 2009 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 A9DE4106568D; Sun, 22 Nov 2009 12:11:19 +0000 (UTC) (envelope-from gavin@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 813B18FC08; Sun, 22 Nov 2009 12:11:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAMCBJOx049056; Sun, 22 Nov 2009 12:11:19 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAMCBJXq049052; Sun, 22 Nov 2009 12:11:19 GMT (envelope-from gavin) Date: Sun, 22 Nov 2009 12:11:19 GMT Message-Id: <200911221211.nAMCBJXq049052@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/140742: rum(4) Two asus-WL167G adapters cannot talk to each other X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 12:11:19 -0000 Old Synopsis: assus-WL167G rum driver New Synopsis: rum(4) Two asus-WL167G adapters cannot talk to each other Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Sun Nov 22 12:08:40 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=140742 From owner-freebsd-net@FreeBSD.ORG Sun Nov 22 12:52:24 2009 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 70B92106566C; Sun, 22 Nov 2009 12:52:24 +0000 (UTC) (envelope-from arved@FreeBSD.org) Received: from iris.rise-s.com (iris.rise-s.com [88.116.105.226]) by mx1.freebsd.org (Postfix) with ESMTP id 2EA0F8FC13; Sun, 22 Nov 2009 12:52:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by iris.rise-s.com (Postfix) with ESMTP id CABAC40E2F4; Sun, 22 Nov 2009 13:34:06 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at iris.rise-s.com Received: from dhcp122.wlan (fwswe.rise-s.com [83.65.168.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rise-world.com (Postfix) with ESMTPSA id A511F40E0FC; Sun, 22 Nov 2009 13:34:05 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1077) From: =?utf-8?Q?T=C4=B1lman_Linneweh?= Date: Sun, 22 Nov 2009 13:33:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: To: freebsd-net@FreeBSD.org X-Mailer: Apple Mail (2.1077) Cc: Jack Vogel Subject: Intel NIC 0x10f08086 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 12:52:24 -0000 Hi List, Hi Jack! I have an Intel NIC with the pci chip=3D0x10f08086 rev=3D0x05 as onboard = Card on an "Intel DP55WB" Mainboard. According to Google it is an "82578DC".=20 Now i wonder how to make it work. I tried to add the PCI ID to both = em(4) and igb(4) but the attach failed, so it looks like something more = is required.=20 Any ideas? regards arved= From owner-freebsd-net@FreeBSD.ORG Sun Nov 22 13:21:21 2009 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 A9C601065672 for ; Sun, 22 Nov 2009 13:21:21 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp1.dlr.de (smtp1.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id 4146D8FC12 for ; Sun, 22 Nov 2009 13:21:20 +0000 (UTC) Received: from beagle.kn.op.dlr.de ([129.247.178.136]) by smtp1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sun, 22 Nov 2009 14:09:15 +0100 Date: Sun, 22 Nov 2009 14:09:12 +0100 (CET) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: freebsd-net@freebsd.org Message-ID: <20091122130156.F52486@beagle.kn.op.dlr.de> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 22 Nov 2009 13:09:15.0274 (UTC) FILETIME=[FDD95EA0:01CA6B74] Subject: ARP regression in releng-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 13:21:21 -0000 Hi all, I try to figure out something simple like the ARP retransmission timeout to populate the ipv4InterfaceRetransmitTime in the RFC4293 MIB. In line 357 of netinet/if_ether.c it says: /* * Return EWOULDBLOCK if we have tried less than arp_maxtries. It * will be masked by ether_output(). Return EHOSTDOWN/EHOSTUNREACH * if we have already sent arp_maxtries ARP requests. Retransmit the * ARP request, but not faster than one request per second. */ Unfortunately the comment about the 1s minimum retransmit interval is there, but the code not. A simple ping -f shows the code transmitting ARP requests every 30 milliseconds, which is not good in my opinion. releng-7 (with the old L2 code) works correctly. BTW, what means the comment on line 282 in the same file? /* XXXXX */ harti From owner-freebsd-net@FreeBSD.ORG Sun Nov 22 15:39:48 2009 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 2C623106566C; Sun, 22 Nov 2009 15:39:48 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id F2DA38FC12; Sun, 22 Nov 2009 15:39:46 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id nAMFdZWW070618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Nov 2009 00:39:40 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Mon, 23 Nov 2009 00:39:35 +0900 Message-ID: From: Hajimu UMEMOTO To: net@FreeBSD.org, current@FreeBSD.org User-Agent: Wanderlust/2.15.7 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i386-portbld-freebsd8.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.0-RELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Mon_Nov_23_00:39:35_2009-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Mon, 23 Nov 2009 00:39:40 +0900 (JST) X-Virus-Scanned: clamav-milter 0.95.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: Subject: [CFR] unified rc.firewall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 15:39:48 -0000 --Multipart_Mon_Nov_23_00:39:35_2009-1 Content-Type: text/plain; charset=US-ASCII Hi, The ipfw and ip6fw were unified into ipfw2, now. But, we still have rc.firewall and rc.firewall6. However, there are conflicts with each other, and it confuses the users, IMHO. So, I made a patch to unify rc.firewall and rc.firewall6, and obsolete rc.firewall6 and rc.d/ip6fw. Please review the attached patch. If there is no objection, I'll commit it in next weekend. Sincerely, --Multipart_Mon_Nov_23_00:39:35_2009-1 Content-Type: application/octet-stream; type=patch Content-Disposition: attachment; filename="ipfw-unify.diff" Content-Transfer-Encoding: 7bit Index: etc/Makefile diff -u etc/Makefile.orig etc/Makefile --- etc/Makefile.orig 2009-10-25 10:10:29.000000000 +0900 +++ etc/Makefile 2009-11-22 22:07:19.840275808 +0900 @@ -15,7 +15,7 @@ inetd.conf libalias.conf login.access login.conf mac.conf motd \ netconfig network.subr networks newsyslog.conf nsswitch.conf \ phones profile protocols \ - rc rc.bsdextended rc.firewall rc.firewall6 rc.initdiskless \ + rc rc.bsdextended rc.firewall rc.initdiskless \ rc.sendmail rc.shutdown \ rc.subr remote rpc services shells \ sysctl.conf syslog.conf \ Index: etc/defaults/rc.conf diff -u etc/defaults/rc.conf.orig etc/defaults/rc.conf --- etc/defaults/rc.conf.orig 2009-10-25 10:10:29.000000000 +0900 +++ etc/defaults/rc.conf 2009-11-22 21:25:22.343296205 +0900 @@ -118,7 +118,10 @@ firewall_quiet="NO" # Set to YES to suppress rule display firewall_logging="NO" # Set to YES to enable events logging firewall_flags="" # Flags passed to ipfw when type is a file -firewall_client_net="192.0.2.0/24" # Network address for "client" firewall. +firewall_client_net="192.0.2.0/24" # IPv4 Network address for "client" + # firewall. +#firewall_client_net_ipv6="2001:db8:2:1::/64" # IPv6 network prefix for + # "client" firewall. firewall_simple_iif="ed1" # Inside network interface for "simple" # firewall. firewall_simple_inet="192.0.2.16/28" # Inside network address for "simple" @@ -127,12 +130,22 @@ # firewall. firewall_simple_onet="192.0.2.0/28" # Outside network address for "simple" # firewall. +#firewall_simple_iif_ipv6="ed1" # Inside IPv6 network interface for "simple" + # firewall. +#firewall_simple_inet_ipv6="2001:db8:2:800::/56" # Inside IPv6 network prefix + # for "simple" firewall. +#firewall_simple_oif_ipv6="ed0" # Outside IPv6 network interface for "simple" + # firewall. +#firewall_simple_onet_ipv6="2001:db8:2:0::/56" # Outside IPv6 network prefix + # for "simple" firewall. firewall_myservices="" # List of TCP ports on which this host # offers services for "workstation" firewall. firewall_allowservices="" # List of IPs which have access to # $firewall_myservices for "workstation" # firewall. -firewall_trusted="" # List of IPs which have full access to this +firewall_trusted="" # List of IPv4s which have full access to this + # host for "workstation" firewall. +firewall_trusted_ipv6="" # List of IPv6s which have full access to this # host for "workstation" firewall. firewall_logdeny="NO" # Set to YES to log default denied incoming # packets for "workstation" firewall. @@ -470,13 +483,18 @@ # faithd(8) setup. ipv6_ipv4mapping="NO" # Set to "YES" to enable IPv4 mapped IPv6 addr # communication. (like ::ffff:a.b.c.d) -ipv6_firewall_enable="NO" # Set to YES to enable IPv6 firewall - # functionality -ipv6_firewall_script="/etc/rc.firewall6" # Which script to run to set up the IPv6 firewall -ipv6_firewall_type="UNKNOWN" # IPv6 Firewall type (see /etc/rc.firewall6) -ipv6_firewall_quiet="NO" # Set to YES to suppress rule display -ipv6_firewall_logging="NO" # Set to YES to enable events logging -ipv6_firewall_flags="" # Flags passed to ip6fw when type is a file +#ipv6_firewall_enable="NO" # Set to YES to enable IPv6 firewall + # functionality (DEPRECAED) +#ipv6_firewall_script="/etc/rc.firewall6" # Which script to run to set up the + # IPv6 firewall (DEPRECAED) +#ipv6_firewall_type="UNKNOWN" # IPv6 Firewall type (see /etc/rc.firewall6) + # (DEPRECAED) +#ipv6_firewall_quiet="NO" # Set to YES to suppress rule display + # (DEPRECAED) +#ipv6_firewall_logging="NO" # Set to YES to enable events logging + # (DEPRECAED) +#ipv6_firewall_flags="" # Flags passed to ip6fw when type is a file + # (DEPRECAED) ipv6_ipfilter_rules="/etc/ipf6.rules" # rules definition file for ipfilter, # see /usr/src/contrib/ipfilter/rules # for examples Index: etc/rc.d/Makefile diff -u etc/rc.d/Makefile.orig etc/rc.d/Makefile --- etc/rc.d/Makefile.orig 2009-10-25 10:10:29.000000000 +0900 +++ etc/rc.d/Makefile 2009-11-22 20:42:16.398311126 +0900 @@ -15,7 +15,7 @@ hcsecd \ hostapd hostid hostid_save hostname \ inetd initrandom \ - ip6addrctl ip6fw ipfilter ipfs ipfw ipmon \ + ip6addrctl ipfilter ipfs ipfw ipmon \ ipnat ipsec ipxrouted \ jail \ kadmind kerberos keyserv kldxref kpasswdd \ Index: etc/rc.d/ipfw diff -u etc/rc.d/ipfw.orig etc/rc.d/ipfw --- etc/rc.d/ipfw.orig 2009-11-22 20:43:59.000000000 +0900 +++ etc/rc.d/ipfw 2009-11-22 20:46:17.663938405 +0900 @@ -61,7 +61,13 @@ # Enable the firewall # if ! ${SYSCTL_W} net.inet.ip.fw.enable=1 1>/dev/null 2>&1; then - warn "failed to enable firewall" + warn "failed to enable IPv4 firewall" + fi + if ifconfig lo0 inet6 >/dev/null 2>&1; then + if ! ${SYSCTL_W} net.inet6.ip6.fw.enable=1 1>/dev/null 2>&1 + then + warn "failed to enable IPv6 firewall" + fi fi } @@ -70,6 +76,9 @@ # Disable the firewall # ${SYSCTL_W} net.inet.ip.fw.enable=0 + if ifconfig lo0 inet6 >/dev/null 2>&1; then + ${SYSCTL_W} net.inet6.ip6.fw.enable=0 + fi if [ -f /etc/rc.d/natd ] ; then /etc/rc.d/natd quietstop fi Index: etc/rc.firewall diff -u etc/rc.firewall.orig etc/rc.firewall --- etc/rc.firewall.orig 2009-10-25 10:10:29.000000000 +0900 +++ etc/rc.firewall 2009-11-22 23:44:43.101805845 +0900 @@ -40,6 +40,27 @@ fi fi +# afexists af +# Returns 0 if the address family is enabled in the kernel +# 1 otherwise. +afexists() +{ + local _af + _af=$1 + + case ${_af} in + inet) + sysctl -n net.inet > /dev/null 2>&1 + ;; + inet6) + sysctl -n net.inet6 > /dev/null 2>&1 + ;; + *) + err 1 "afexists(): Unsupported address family: $_af" + ;; + esac +} + ############ # Define the firewall type in /etc/rc.conf. Valid values are: # open - will allow anyone in @@ -85,6 +106,32 @@ ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any + if afexists inet6; then + ${fwcmd} add 400 deny ip6 from any to ::1 + ${fwcmd} add 500 deny ip6 from ::1 to any + fi +} + +setup_ipv6_mandatory () { + afexists inet6 || return 0 + + ############ + # Only in rare cases do you want to change these rules + # + # ND + # + # DAD + ${fwcmd} add pass ip6 from :: to ff02::/16 proto ipv6-icmp + # RS, RA, NS, NA, redirect... + ${fwcmd} add pass ip6 from fe80::/10 to fe80::/10 proto ipv6-icmp + ${fwcmd} add pass ip6 from fe80::/10 to ff02::/16 proto ipv6-icmp + + # Allow ICMPv6 destination unreach + ${fwcmd} add pass ip6 from any to any icmp6types 1 proto ipv6-icmp + + # Allow NS/NA/toobig (don't filter it out) + ${fwcmd} add pass ip6 from any to any icmp6types 2,135,136 \ + proto ipv6-icmp } if [ -n "${1}" ]; then @@ -109,6 +156,7 @@ ${fwcmd} -f flush setup_loopback +setup_ipv6_mandatory ############ # Network Address Translation. All packets are passed to natd(8) @@ -166,11 +214,13 @@ # against people from outside your own network. # # Configuration: - # firewall_client_net: Network address of local network. + # firewall_client_net: Network address of local IPv4 network. + # firewall_client_net_ipv6: Network address of local IPv6 network. ############ # set this to your local network net="$firewall_client_net" + net6="$firewall_client_net_ipv6" # Allow limited broadcast traffic from my own net. ${fwcmd} add pass all from ${net} to 255.255.255.255 @@ -178,6 +228,16 @@ # Allow any traffic to or from my own net. ${fwcmd} add pass all from me to ${net} ${fwcmd} add pass all from ${net} to me + if [ -n "$net6" ]; then + ${fwcmd} add pass ip6 from me6 to ${net6} + ${fwcmd} add pass ip6 from ${net6} to me6 + fi + + if [ -n "$net6" ]; then + # Allow any link-local multicast traffic + ${fwcmd} add pass ip6 from fe80::/10 to ff02::/16 + ${fwcmd} add pass ip6 from ${net6} to ff02::/16 + fi # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established @@ -212,23 +272,35 @@ # on the inside at this machine for those services. # # Configuration: - # firewall_simple_iif: Inside network interface. - # firewall_simple_inet: Inside network address. - # firewall_simple_oif: Outside network interface. - # firewall_simple_onet: Outside network address. + # firewall_simple_iif: Inside IPv4 network interface. + # firewall_simple_inet: Inside IPv4 network address. + # firewall_simple_oif: Outside IPv4 network interface. + # firewall_simple_onet: Outside IPv4 network address. + # firewall_simple_iif_ipv6: Inside IPv6 network interface. + # firewall_simple_inet_ipv6: Inside IPv6 network prefix. + # firewall_simple_oif_ipv6: Outside IPv6 network interface. + # firewall_simple_onet_ipv6: Outside IPv6 network prefix. ############ # set these to your outside interface network oif="$firewall_simple_oif" onet="$firewall_simple_onet" + oif6="$firewall_simple_oif_ipv6" + onet6="$firewall_simple_onet_ipv6" # set these to your inside interface network iif="$firewall_simple_iif" inet="$firewall_simple_inet" + iif6="$firewall_simple_iif_ipv6" + inet6="$firewall_simple_inet_ipv6" # Stop spoofing ${fwcmd} add deny all from ${inet} to any in via ${oif} ${fwcmd} add deny all from ${onet} to any in via ${iif} + if [ -n "$oif6" -a -n "$onet6" -a -n "$iif6" -a -n "$inet6" ]; then + ${fwcmd} add deny ip6 from ${inet6} to any in via ${oif6} + ${fwcmd} add deny ip6 from ${onet6} to any in via ${iif6} + fi # Stop RFC1918 nets on the outside interface ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} @@ -254,7 +326,7 @@ case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then - ${fwcmd} add divert natd all from any to any via ${natd_interface} + ${fwcmd} add divert natd ip4 from any to any via ${natd_interface} fi ;; esac @@ -273,6 +345,55 @@ ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} + if [ -n "$oif6" -a -n "$onet6" -a -n "$iif6" -a -n "$inet6" ]; then + # Stop unique local unicast address on the outside interface + ${fwcmd} add deny ip6 from fc00::/7 to any via ${oif6} + ${fwcmd} add deny ip6 from any to fc00::/7 via ${oif6} + + # Stop site-local on the outside interface + ${fwcmd} add deny ip6 from fec0::/10 to any via ${oif6} + ${fwcmd} add deny ip6 from any to fec0::/10 via ${oif6} + + # Disallow "internal" addresses to appear on the wire. + ${fwcmd} add deny ip6 from ::ffff:0.0.0.0/96 to any \ + via ${oif6} + ${fwcmd} add deny ip6 from any to ::ffff:0.0.0.0/96 \ + via ${oif6} + + # Disallow packets to malicious IPv4 compatible prefix. + ${fwcmd} add deny ip6 from ::224.0.0.0/100 to any via ${oif6} + ${fwcmd} add deny ip6 from any to ::224.0.0.0/100 via ${oif6} + ${fwcmd} add deny ip6 from ::127.0.0.0/104 to any via ${oif6} + ${fwcmd} add deny ip6 from any to ::127.0.0.0/104 via ${oif6} + ${fwcmd} add deny ip6 from ::0.0.0.0/104 to any via ${oif6} + ${fwcmd} add deny ip6 from any to ::0.0.0.0/104 via ${oif6} + ${fwcmd} add deny ip6 from ::255.0.0.0/104 to any via ${oif6} + ${fwcmd} add deny ip6 from any to ::255.0.0.0/104 via ${oif6} + + ${fwcmd} add deny ip6 from ::0.0.0.0/96 to any via ${oif6} + ${fwcmd} add deny ip6 from any to ::0.0.0.0/96 via ${oif6} + + # Disallow packets to malicious 6to4 prefix. + ${fwcmd} add deny ip6 from 2002:e000::/20 to any via ${oif6} + ${fwcmd} add deny ip6 from any to 2002:e000::/20 via ${oif6} + ${fwcmd} add deny ip6 from 2002:7f00::/24 to any via ${oif6} + ${fwcmd} add deny ip6 from any to 2002:7f00::/24 via ${oif6} + ${fwcmd} add deny ip6 from 2002:0000::/24 to any via ${oif6} + ${fwcmd} add deny ip6 from any to 2002:0000::/24 via ${oif6} + ${fwcmd} add deny ip6 from 2002:ff00::/24 to any via ${oif6} + ${fwcmd} add deny ip6 from any to 2002:ff00::/24 via ${oif6} + + ${fwcmd} add deny ip6 from 2002:0a00::/24 to any via ${oif6} + ${fwcmd} add deny ip6 from any to 2002:0a00::/24 via ${oif6} + ${fwcmd} add deny ip6 from 2002:ac10::/28 to any via ${oif6} + ${fwcmd} add deny ip6 from any to 2002:ac10::/28 via ${oif6} + ${fwcmd} add deny ip6 from 2002:c0a8::/32 to any via ${oif6} + ${fwcmd} add deny ip6 from any to 2002:c0a8::/32 via ${oif6} + + ${fwcmd} add deny ip6 from ff05::/16 to any via ${oif6} + ${fwcmd} add deny ip6 from any to ff05::/16 via ${oif6} + fi + # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established @@ -291,7 +412,11 @@ ${fwcmd} add pass tcp from any to me 80 setup # Reject&Log all setup of incoming connections from the outside - ${fwcmd} add deny log tcp from any to any in via ${oif} setup + ${fwcmd} add deny log ip4 from any to any in via ${oif} setup proto tcp + if [ -n "$oif6" -a -n "$onet6" -a -n "$iif6" -a -n "$inet6" ]; then + ${fwcmd} add deny log ip6 from any to any in via ${oif6} \ + setup proto tcp + fi # Allow setup of any other TCP connection ${fwcmd} add pass tcp from any to any setup @@ -313,7 +438,7 @@ # offers services. # firewall_allowservices: List of IPs which has access to # $firewall_myservices. - # firewall_trusted: List of IPs which has full access + # firewall_trusted: List of IPv4s which has full access # to this host. Be very carefull # when setting this. This option can # seriously degrade the level of @@ -324,17 +449,31 @@ # firewall_nologports: List of TCP/UDP ports for which # denied incomming packets are not # logged. - + # firewall_trusted_ipv6: List of IPv6s which has full access + # to this host. Be very carefull + # when setting this. This option can + # seriously degrade the level of + # protection provided by the firewall. + # Allow packets for which a state has been built. ${fwcmd} add check-state # For services permitted below. ${fwcmd} add pass tcp from me to any established + if afexists inet6; then + ${fwcmd} add pass ip6 from any to any proto tcp established + fi # Allow any connection out, adding state for each. ${fwcmd} add pass tcp from me to any setup keep-state ${fwcmd} add pass udp from me to any keep-state ${fwcmd} add pass icmp from me to any keep-state + if afexists inet6; then + ${fwcmd} add pass ip6 from me6 to any proto tcp setup + ${fwcmd} add pass ip6 from me6 to any proto udp keep-state + ${fwcmd} add pass ip6 from me6 to any proto ipv6-icmp \ + keep-state + fi # Allow DHCP. ${fwcmd} add pass udp from 0.0.0.0 68 to 255.255.255.255 67 out @@ -343,6 +482,10 @@ # Some servers will ping the IP while trying to decide if it's # still in use. ${fwcmd} add pass icmp from any to any icmptype 8 + if afexists inet6; then + ${fwcmd} add pass ip6 from any to any icmp6type 128,129 \ + proto ipv6-icmp + fi # Allow "mandatory" ICMP in. ${fwcmd} add pass icmp from any to any icmptype 3,4,11 @@ -361,6 +504,9 @@ for i in ${firewall_allowservices} ; do for j in ${firewall_myservices} ; do ${fwcmd} add pass tcp from $i to me $j + if afexists inet6; then + ${fwcmd} add pass tcp from $i to me6 $j setup + fi done done @@ -370,7 +516,10 @@ for i in ${firewall_trusted} ; do ${fwcmd} add pass ip from $i to me done - + for i in ${firewall_trusted_ipv6} ; do + ${fwcmd} add pass ip6 from $i to me6 + done + ${fwcmd} add 65000 count ip from any to any # Drop packets to ports where we don't want logging --Multipart_Mon_Nov_23_00:39:35_2009-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Mon_Nov_23_00:39:35_2009-1-- From owner-freebsd-net@FreeBSD.ORG Sun Nov 22 18:34:25 2009 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 9DBFC1065733 for ; Sun, 22 Nov 2009 18:34:22 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 884968FC0A for ; Sun, 22 Nov 2009 18:34:22 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nAMIYMsM025485; Sun, 22 Nov 2009 10:34:22 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Nov 2009 10:34:08 -0800 Message-ID: In-Reply-To: <20091122130156.F52486@beagle.kn.op.dlr.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ARP regression in releng-8 Thread-Index: Acprdr733LFX52Z/ThGrKRbHBvzPDAAK44dw References: <20091122130156.F52486@beagle.kn.op.dlr.de> From: "Li, Qing" To: "Harti Brandt" , Cc: Subject: RE: ARP regression in releng-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 18:34:25 -0000 I will look into it and get back to you. -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Harti Brandt > Sent: Sunday, November 22, 2009 5:09 AM > To: freebsd-net@freebsd.org > Subject: ARP regression in releng-8 >=20 > Hi all, >=20 > I try to figure out something simple like the ARP retransmission > timeout > to populate the ipv4InterfaceRetransmitTime in the RFC4293 MIB. In line > 357 of netinet/if_ether.c it says: >=20 > /* > * Return EWOULDBLOCK if we have tried less than arp_maxtries. > It > * will be masked by ether_output(). Return > EHOSTDOWN/EHOSTUNREACH > * if we have already sent arp_maxtries ARP requests. > Retransmit > the > * ARP request, but not faster than one request per second. > */ >=20 > Unfortunately the comment about the 1s minimum retransmit interval is > there, but the code not. A simple ping -f shows the code transmitting > ARP > requests every 30 milliseconds, which is not good in my opinion. > releng-7 > (with the old L2 code) works correctly. >=20 > BTW, what means the comment on line 282 in the same file? >=20 > /* XXXXX > */ >=20 > harti > _______________________________________________ > 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 22 18:40:10 2009 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 65947106566C for ; Sun, 22 Nov 2009 18:40:10 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 4F4208FC12 for ; Sun, 22 Nov 2009 18:40:10 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nAMIe6tj025867; Sun, 22 Nov 2009 10:40:08 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Nov 2009 10:39:53 -0800 Message-ID: In-Reply-To: <35F73C4F-3C77-4B40-9D7D-16BEB8FE6EAD@adam.gs> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: openbgpd + 8.0 Thread-Index: AcprHnTWtOIcBwzBR62XF8pkB9C/XAAhCOgQ References: <35F73C4F-3C77-4B40-9D7D-16BEB8FE6EAD@adam.gs> From: "Li, Qing" To: "Adam Jacob Muller" , Cc: Subject: RE: openbgpd + 8.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 18:40:10 -0000 I am not sure if what you are observing is a side effect of svn-r196714. In particular, the code I added for: -------------------- - Routing messages are not generated when adding and removing interface address aliases. -------------------- If my memory serves me right, I put in the above patch for SCTP. I'd be happy to work with you offline and confirm either way... -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Adam Jacob Muller > Sent: Saturday, November 21, 2009 6:33 PM > To: freebsd-net@freebsd.org > Subject: openbgpd + 8.0 >=20 > Hi, > I have an openbgpd running on an 8.0 box where openbgpd crashes (exits > silently) whenever an interface on the system (vlan/tun/tap s are > dynamically created here) is removed. >=20 >=20 > I've traced the error back to kroute.c:dispatch_rtmsg_addr >=20 > if ((sa =3D rti_info[RTAX_DST]) =3D=3D NULL) { >=20 >=20 > This check is failing, which returns -1, which is passed up > (dispatch_rtmsg up to kr_dispatch_msg up to bgpd.c main() whcih sets > exit=3D1). > Unfortunately, this is quickly approaching >=20 > Any idea what exactly is going on here? >=20 > I'm not 100% sure but I think this is a regression from 7.x, I don't > have any 7.x systems I can test this on at the moment unfortunately. >=20 > I've subverted this check by, simply, not setting quit=3D1 in main.c when > kr_dispatch_msg() fails, and everything SEEMS to operate normally, i'm > kinda curious to hear thoughts on this though... >=20 >=20 > -Adam > _______________________________________________ > 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 22 18:44:43 2009 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 68D751065670 for ; Sun, 22 Nov 2009 18:44:43 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 36FCD8FC0C for ; Sun, 22 Nov 2009 18:44:42 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id nAMIiegP026145; Sun, 22 Nov 2009 10:44:40 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 22 Nov 2009 10:44:27 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: openbgpd + 8.0 Thread-Index: AcprHnTWtOIcBwzBR62XF8pkB9C/XAAhCOgQAABBD2A= References: <35F73C4F-3C77-4B40-9D7D-16BEB8FE6EAD@adam.gs> From: "Li, Qing" To: "Adam Jacob Muller" , Cc: Subject: RE: openbgpd + 8.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 18:44:43 -0000 Just to be a bit more specific, in r196714 /sys/netinet/in.c: /* QL: XXX 1090 * Report a blank rtentry when a route has not been 1091 * installed for the given interface address. 1092 */ 1093 =09 -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Li, Qing > Sent: Sunday, November 22, 2009 10:40 AM > To: Adam Jacob Muller; freebsd-net@freebsd.org > Subject: RE: openbgpd + 8.0 >=20 > I am not sure if what you are observing is a side effect of > svn-r196714. In particular, the code I added for: >=20 > -------------------- > - Routing messages are not generated when adding and removing > interface address aliases. > -------------------- >=20 > If my memory serves me right, I put in the above patch for SCTP. > I'd be happy to work with you offline and confirm either way... >=20 > -- Qing >=20 >=20 > > -----Original Message----- > > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > > net@freebsd.org] On Behalf Of Adam Jacob Muller > > Sent: Saturday, November 21, 2009 6:33 PM > > To: freebsd-net@freebsd.org > > Subject: openbgpd + 8.0 > > > > Hi, > > I have an openbgpd running on an 8.0 box where openbgpd crashes > (exits > > silently) whenever an interface on the system (vlan/tun/tap s are > > dynamically created here) is removed. > > > > > > I've traced the error back to kroute.c:dispatch_rtmsg_addr > > > > if ((sa =3D rti_info[RTAX_DST]) =3D=3D NULL) { > > > > > > This check is failing, which returns -1, which is passed up > > (dispatch_rtmsg up to kr_dispatch_msg up to bgpd.c main() whcih sets > > exit=3D1). > > Unfortunately, this is quickly approaching > > > > Any idea what exactly is going on here? > > > > I'm not 100% sure but I think this is a regression from 7.x, I don't > > have any 7.x systems I can test this on at the moment unfortunately. > > > > I've subverted this check by, simply, not setting quit=3D1 in main.c > when > > kr_dispatch_msg() fails, and everything SEEMS to operate normally, > i'm > > kinda curious to hear thoughts on this though... > > > > > > -Adam > > _______________________________________________ > > 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" > _______________________________________________ > 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 22 18:54:25 2009 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 C1048106566C for ; Sun, 22 Nov 2009 18:54:25 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 641238FC13 for ; Sun, 22 Nov 2009 18:54:24 +0000 (UTC) Received: by fxm10 with SMTP id 10so2300284fxm.14 for ; Sun, 22 Nov 2009 10:54:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.16.216 with SMTP id p24mr632201faa.35.1258916064234; Sun, 22 Nov 2009 10:54:24 -0800 (PST) In-Reply-To: References: <35F73C4F-3C77-4B40-9D7D-16BEB8FE6EAD@adam.gs> From: Vlad Galu Date: Sun, 22 Nov 2009 20:52:33 +0200 Message-ID: To: "Li, Qing" Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Adam Jacob Muller Subject: Re: openbgpd + 8.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 18:54:25 -0000 On Sun, Nov 22, 2009 at 8:44 PM, Li, Qing wrote: > Just to be a bit more specific, in r196714 /sys/netinet/in.c: [...] Just wanting to let you know the following behavior changes: 1. Some customers of mine used to run 7.x with quagga. Another app was adding static routes with a nexthop of 127.0.0.1, which were redistributed by quagga to BGP as part of the "redistribute kernel" directive. After upgrading to 8.x, routes are being properly exported upon adding, however quagga doesn't stop announcing them in BGP after they disappear from the kernel route table. "route monitor" sees the RTM_DELETE message, but quagga either doesn't, or just ignores it. The same quagga port version was used on both 7.x and 8.x. 2. Switching to OpenBGPD fixed the above issue, with the notable mention that it doesn't redistribute routes with a nexthop of 127.0.0.1, so we had to rewrite the app for that (127.0.0.1 was hardcoded - INADDR_LOOPBACK). This might be an OpenBGPD check, though. Hope this is useful info. Cheers, Vlad From owner-freebsd-net@FreeBSD.ORG Sun Nov 22 19:12:27 2009 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 309081065695 for ; Sun, 22 Nov 2009 19:12:27 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id B62E88FC19 for ; Sun, 22 Nov 2009 19:12:26 +0000 (UTC) Received: (qmail 323 invoked by uid 399); 22 Nov 2009 19:12:26 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 22 Nov 2009 19:12:26 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B098D21.4040607@FreeBSD.org> Date: Sun, 22 Nov 2009 11:12:33 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Hajimu UMEMOTO References: In-Reply-To: X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: [CFR] unified rc.firewall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 19:12:27 -0000 Hajimu UMEMOTO wrote: > Hi, > > The ipfw and ip6fw were unified into ipfw2, now. But, we still have > rc.firewall and rc.firewall6. However, there are conflicts with each > other, and it confuses the users, IMHO. > So, I made a patch to unify rc.firewall and rc.firewall6, and obsolete > rc.firewall6 and rc.d/ip6fw. > Please review the attached patch. If there is no objection, I'll > commit it in next weekend. Overall I think this is good, and I'm definitely in favor of more integration of IPv6 into the mainstream rather than something that is glued on. A few comments: In rc.firewall you seem to have copied afexists() from network.subr. Is there a reason that you did not simply source that file? That would be the preferred method. Also in that file you call "if afexists inet6" quite a few times. My preference from a performance standpoint would be to call it once, perhaps in a start_precmd then cache the value. And of course, you have regression tested this thoroughly, yes? :) Please include scenarios where there is no INET6 in the kernel as well. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Sun Nov 22 23:18:39 2009 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 B63FD106566C; Sun, 22 Nov 2009 23:18:39 +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 8AC3B8FC08; Sun, 22 Nov 2009 23:18:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAMNIdG7019440; Sun, 22 Nov 2009 23:18:39 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAMNIdOa019436; Sun, 22 Nov 2009 23:18:39 GMT (envelope-from linimon) Date: Sun, 22 Nov 2009 23:18:39 GMT Message-Id: <200911222318.nAMNIdOa019436@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/140778: [em] randomly panic in vlan/em X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 23:18:39 -0000 Old Synopsis: randomly panic in vlan/em New Synopsis: [em] randomly panic in vlan/em Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 22 23:18:23 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140778 From owner-freebsd-net@FreeBSD.ORG Sun Nov 22 23:31:53 2009 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 49AC81065698; Sun, 22 Nov 2009 23:31: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 1FF018FC0C; Sun, 22 Nov 2009 23:31:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAMNVrCt036986; Sun, 22 Nov 2009 23:31:53 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAMNVqJs036982; Sun, 22 Nov 2009 23:31:52 GMT (envelope-from linimon) Date: Sun, 22 Nov 2009 23:31:52 GMT Message-Id: <200911222331.nAMNVqJs036982@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/140796: [ath] [panic] privileged instruction fault X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 23:31:53 -0000 Old Synopsis: panic: privileged instruction fault (ath related) New Synopsis: [ath] [panic] privileged instruction fault Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Nov 22 23:31:33 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140796 From owner-freebsd-net@FreeBSD.ORG Sun Nov 22 23:37:41 2009 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 2E937106568F for ; Sun, 22 Nov 2009 23:37:41 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id E0C748FC1A for ; Sun, 22 Nov 2009 23:37:40 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 53E441E0071B; Mon, 23 Nov 2009 00:19:10 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id nAMNGwE8068521; Mon, 23 Nov 2009 00:16:58 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id nAMNGwfV068520; Mon, 23 Nov 2009 00:16:58 +0100 (CET) (envelope-from nox) Date: Mon, 23 Nov 2009 00:16:58 +0100 (CET) From: Juergen Lock Message-Id: <200911222316.nAMNGwfV068520@triton8.kn-bremen.de> To: fli@shapeshifter.se X-Newsgroups: local.list.freebsd.emulation In-Reply-To: <4B09992F.1080900@shapeshifter.se> References: <4B08DD0C.3080106@FreeBSD.org> <4B0963BF.1070908@shapeshifter.se> <4B0972B5.40903@FreeBSD.org> Organization: home Cc: freebsd-net@FreeBSD.org, freebsd-emulation@FreeBSD.org, Doug Barton Subject: bridging vs wifi, proxy arp broken on 8.0 rc? (was: Re: Bridged networking for virtualbox on -current?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2009 23:37:41 -0000 In article <4B09992F.1080900@shapeshifter.se> you write: >Doug Barton wrote: >> Fredrik Lindberg wrote: >>> Doug Barton wrote: >>>> Is bridged networking for vbox supposed to work on -current? It says >>>> on the wiki that it does, but I tried it tonight and couldn't get it >>>> to work. >>>> >>>> I did see one page that suggested trying one of the Intel virtual >>>> nicks, which I did, no luck. >>>> >>>> If this is not supposed to work it would be nice to update the wiki, I >>>> spent quite a bit of time trying to get it to work that I hope was not >>>> wasted. >>>> >>> The short answer is that it should work. The long answer is that >>> it depends, for example it doesn't play nice when trying to >>> bridge a virtual nic with an if_bridge interface. >>> >>> A slightly more verbose description of your environment and what >>> error messages you're seeing would probably help. >> >> Thanks. I'm using an up to date -current, and my outgoing nic is >> wlan0. I followed the instructions on the wiki. I first tried the >> default nic in OSE then I tried the first Intel nic on the list (which >> required downloading drivers of course). >> > >Which type of virtual interface you're using in virtualbox doesn't >matter. However, it hits me that I've actually never really tested >the bridging code with a wireless interface and it looks like you've >hit a bug. I tried to use a wireless interface just now and it >doesn't work, need to look into why though. The problem with bridging and wifi is that on wifi you usually can use only a single mac address... There are ways around this (using nat or routing), and I actually played with the latter using qemu tap networking recently, but couldn't get the most ideal solution working the way I wanted on 8.0 rc - it only worked on 7-stable. (using a sub-subnet of the lan interface for the tap interface + guest, and routing + proxy arp for the guest ip.) I just wanted to try it again on the 8.0 rc box and now even setting up the prox arp entry fails with: arp: writing to routing socket: Invalid argument Commands I tried: arp -s pub only and arp -s auto pub only (both before even configuring the tap interface this time...) Mind you my 8.0 rc checkout is a little old (Sep 29) so maybe I should try updating first (I want to test 8-stable anyway one of these days) - but looking for `arp' in the relevant commitlogs also came up empty. :( (I'm Cc'ing -net just in case, please keep me on the Cc cause I'm not subscribed there...) Cheers, Juergen From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 00:41:05 2009 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 D557B106566B for ; Mon, 23 Nov 2009 00:41:05 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id 6249C8FC13 for ; Mon, 23 Nov 2009 00:41:05 +0000 (UTC) Received: (qmail 27611 invoked by uid 399); 23 Nov 2009 00:41:05 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 23 Nov 2009 00:41:05 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B09DA1A.2050109@FreeBSD.org> Date: Sun, 22 Nov 2009 16:40:58 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Juergen Lock References: <4B08DD0C.3080106@FreeBSD.org> <4B0963BF.1070908@shapeshifter.se> <4B0972B5.40903@FreeBSD.org> <200911222316.nAMNGwfV068520@triton8.kn-bremen.de> In-Reply-To: <200911222316.nAMNGwfV068520@triton8.kn-bremen.de> X-Enigmail-Version: 0.96.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, freebsd-emulation@FreeBSD.org, fli@shapeshifter.se Subject: Re: bridging vs wifi, proxy arp broken on 8.0 rc? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 00:41:05 -0000 Juergen Lock wrote: > The problem with bridging and wifi is that on wifi you usually can > use only a single mac address... Ok, I'm not heartbroken if it won't work, but it would be nice if the wiki were updated so that no one else wastes time on it like I did last night. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 06:08:54 2009 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 A43AE106566C for ; Mon, 23 Nov 2009 06:08:54 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outH.internet-mail-service.net (outh.internet-mail-service.net [216.240.47.231]) by mx1.freebsd.org (Postfix) with ESMTP id 894FA8FC17 for ; Mon, 23 Nov 2009 06:08:54 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id CD65F301EE; Sun, 22 Nov 2009 22:08:54 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id A31742D6012; Sun, 22 Nov 2009 22:08:53 -0800 (PST) Message-ID: <4B0A26F4.4020803@elischer.org> Date: Sun, 22 Nov 2009 22:08:52 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Tom Judge References: <4B0825DD.3000702@tomjudge.com> <4B08C3DC.1080607@tomjudge.com> In-Reply-To: <4B08C3DC.1080607@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Josh Paetzel , "net@freebsd.org" Subject: Re: if_bridge as if_vlan parent X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 06:08:54 -0000 Tom Judge wrote: > Josh Paetzel wrote: >> On Nov 21, 2009, at 11:39 AM, Tom Judge wrote: >> >>> Hi, >>> >>> I was why I get the following error when trying to create a vlan on >>> top of if_bridge: >>> >>> # ifconfig bridge0 create >>> # ifconfig vlan2 vlan 2 vlandev bridge0 >>> ifconfig: SIOCSETVLAN: Protocol not supported >>> >>> >>> And if there was/is any reason for this to not be supported. >>> >>> Thanks >>> >> >> >> You can create a bridge from a pair of vlan devices.... >> >> # ifconfig vlan1 create >> # ifcconfig vlan2 create >> # ifconfig bridge0 create >> # ifconfig vlan1 vlan 1 vlandev em0 >> # ifconfig vlan2 vlan 2 vlandev em0 >> # ifconfig bridge0 addm vlan1 addm vlan2 >> >> Is that more in line with what you want to do? >> >> I'm a little curious what problem set using a bridge as the parent of >> a vlan solves though. >> >> > You have the problem upside down. > > I am trying to bridge 2 trunk ports on 2 separate switches with a > FreeBSD box, and I would like to access a number of tagged vlans on the > trunk with the FreeBSD box. > > [sw1-1/g1]->[FBSD-em0]-[FBSD-bridge0]-[FBSD-em1]->[sw2-1/g1] > / \ > [FBSD-vlan2] [FBSD-vlan200] > > So: > > ifconfig em0 up > ifconfig em1 up > ifconfig bridge0 create > ifconfig bridge0 addm em0 stp em0 addm em1 stp em1 up > ifconfig vlan2 create > ifconfig vlan2 10.0.0.1/24 vlan 2 vlandev bridge0 > ifconfig vlan200 create > ifconfig vlan200 10.9.9.1/24 vlan 200 vlandev bridge0 > > > This will fail when I try to attach the if_vlan's to the if_bridge. I haven't tried it, but you MAY be able to plumb up some solution to this using the netgraph vlan and bridge nodes. > > Tom > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 07:30:06 2009 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 555F71065670 for ; Mon, 23 Nov 2009 07:30:06 +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 2AD1F8FC08 for ; Mon, 23 Nov 2009 07:30:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAN7U5aV066745 for ; Mon, 23 Nov 2009 07:30:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAN7U5WZ066742; Mon, 23 Nov 2009 07:30:05 GMT (envelope-from gnats) Date: Mon, 23 Nov 2009 07:30:05 GMT Message-Id: <200911230730.nAN7U5WZ066742@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Benjamin Kaduk Cc: Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Benjamin Kaduk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 07:30:06 -0000 The following reply was made to PR kern/140036; it has been noted by GNATS. From: Benjamin Kaduk To: Bernhard Schmidt Cc: bug-followup@freebsd.org Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Date: Mon, 23 Nov 2009 02:25:35 -0500 (EST) On Sun, 22 Nov 2009, Bernhard Schmidt wrote: > On Sunday 01 November 2009 00:24:59 you wrote: >> Indeed, I think I saw a lockup a couple days ago, possibly when >> my card had dissociated and was trying to reassociate. >> >> Thanks for looking into this, > > Seems like your initial fix for that was actually correct, that lock up you > saw there is related to something else. There was an issue with sending null > data frames. > > Can you verify that the LOR is gone with the latest checkout of my repository? > Compile instructions: > http://forums.freebsd.org/showpost.php?p=47627&postcount=16 I upgraded to today's current (which picked up a number of probably-unrelated changes), and then installed the driver from your tree on top of it. No LOR on boot, and I'll let you know if I see any lockups. Thanks, Ben From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 07:47:24 2009 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 3C4E610656A4; Mon, 23 Nov 2009 07:47:24 +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 079F38FC1F; Mon, 23 Nov 2009 07:47:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAN7lNtm090352; Mon, 23 Nov 2009 07:47:23 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAN7lN4M090348; Mon, 23 Nov 2009 07:47:23 GMT (envelope-from linimon) Date: Mon, 23 Nov 2009 07:47:23 GMT Message-Id: <200911230747.nAN7lN4M090348@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/140684: [bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail after soft reboot X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 07:47:24 -0000 Old Synopsis: Broadcom NetXtreme II BCM5709 1000Base-T - fail after soft reboot New Synopsis: [bce] Broadcom NetXtreme II BCM5709 1000Base-T - fail after soft reboot Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Nov 23 07:46:48 UTC 2009 Responsible-Changed-Why: This does not sound i386-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=140684 From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 11:07:00 2009 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 EFC4F106568B for ; Mon, 23 Nov 2009 11:07:00 +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 DBF2A8FC1F for ; Mon, 23 Nov 2009 11:07:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nANB70Zf070201 for ; Mon, 23 Nov 2009 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nANB70bW070199 for freebsd-net@FreeBSD.org; Mon, 23 Nov 2009 11:07:00 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 23 Nov 2009 11:07:00 GMT Message-Id: <200911231107.nANB70bW070199@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, 23 Nov 2009 11:07:01 -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/140796 net [ath] [panic] privileged instruction fault o kern/140778 net [em] randomly panic in vlan/em o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net [em] [patch] Fast irq registration in em driver o kern/140647 net [em] [patch] e1000 driver does not correctly handle mu o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc s kern/140597 net [request] implement Lost Retransmission Detection f bin/140571 net [patch] ifconfig(8) does not set country DE o kern/140567 net [ath] [patch] ath is not worked on my notebook PC o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140358 net 8.0RC2: [arp] arp: writing to routing socket: Invalid o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net [em] em0: watchdog timeout when communicating to windo o kern/140245 net [ath] [panic] Kernel panic during network activity on o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/140051 net [bce] [arp] ARP not sent through Bridge Firewall with o kern/140036 net [iwn] [lor] lock order reversal with iwn0_com_lock and o kern/139761 net [bce] bce driver on IBM HS22 [No PHY found on Child MI o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139559 net [tun] several tun(4) interfaces can be created with sa o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139145 net [ip6] IPv6 blackhole / reject routes broken o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139113 net [arp] removing IP alias doesn't delete permanent arp e o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138999 net [libc] lighttpd/php-cgi with freebsd sendfile(2) enabl o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net [bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138676 net [route] after buildworld not work local routes [regres f kern/138666 net [multicast] [panic] not working multicast through igmp o kern/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BE o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137317 net [tcp] logs full of syncache problems o kern/137292 net [ste] DFE-580TX not working properly o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136482 net [age] Attansic L1 Gigabit Ethernet recieves multicasts o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135836 net [bce] bce BCM5709 Watchdog after warm boot - ok after o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/135067 net [patch] [fib] Incorrect KASSERTs in sys/net/route.c o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] [fib] Route messages sent to all socket listen o kern/134658 net [bce] bce driver fails on PowerEdge m610 blade. o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134369 net [route] [ip6] IPV6 in Head broken for routing table up o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132991 net [bge] if_bge low performance problem f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [fib] [patch] allow to setup fib for service running f o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131162 net [ath] Atheros driver bugginess and kernel crashes o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129580 net [ndis] Netgear WG311v3 (ndis) causes kenel trap at boo o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o kern/129135 net [vge] vge driver on a VIA mini-ITX not working o bin/128954 net ifconfig(8) deletes valid routes 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 bin/128602 net [an] wpa_supplicant(8) crashes with an(4) 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 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] 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/126945 net [carp] CARP interface destruction with ifconfig destro 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 o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under 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 [inet] [patch] 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 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/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/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee 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 f 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/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/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 [if_em] FreeBSD 7 multicast routing problem 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 [mbuf] [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/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122195 net [ed] Alignment problems in if_ed 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 bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw 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 bin/121359 net [patch] ppp(8): fix local stack overflow in ppp 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 [udp] [panic] gnugk causes kernel panic when closing U 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 bin/120060 net routed(8) deletes link-level routes in the presence of 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/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a bin/118987 net ifconfig(8): ifconfig -l (address_family) does not wor o sparc/118932 net [panic] 7.0-BETA4/sparc-64 kernel panic in rip_output 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 a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. 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/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset 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/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load 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 kern/109251 net [re] [patch] if_re cardbus card won't attach 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 / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n 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 o kern/106243 net [nve] double fault panic in if_nve.c on high loads o kern/105945 net Address can disappear from network interface 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 kern/105348 net [ath] ath device stopps TX o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap 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/100709 net [libc] getaddrinfo(3) should return TTL info 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/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in o kern/95519 net [ral] ral0 could not map mbuf 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 s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 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/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o kern/85266 net [xe] [patch] xe(4) driver does not recognise Xircom XE o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre o bin/82975 net route change does not parse classfull network as given o kern/82497 net [vge] vge(4) on AMD64 only works when loaded late, not f kern/81644 net [vge] vge(4) does not work properly when loaded as a K s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported 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/77341 net [ip6] problems with IPV6 implementation 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/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/64556 net [sis] [patch] if_sis short cable fix problems with Net s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 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/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c o conf/23063 net [arp] [patch] for static ARP tables in rc.network 371 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 13:07:49 2009 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 05A941065679 for ; Mon, 23 Nov 2009 13:07:49 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id C9BA08FC08 for ; Mon, 23 Nov 2009 13:07:48 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id D73A7C093C for ; Mon, 23 Nov 2009 08:07:47 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 23 Nov 2009 08:07:47 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=w03tKB/o3Zn1C3flRkUUGqtJd9M=; b=BANIjeYE0oW9Yw9YLRAlFsg2uJuozyQ25Q+xq+04Zdgzd1Y3zze3ikAF5HCIU6fFg16k0HUWgVbnW1WJHz71f0zWWKeV9HAciNP8sY7Zl9Cbm9zwIwcbOo+BlP3VOtEEIxpiKl6ASenaTzXBOxgwtn8Tfc4MiWVoPBMWdVLg5wI= X-Sasl-enc: tqp7BS6SQAZ48HdxsGqhf4FpXtFeG/fBmB+mtOo2LK3D 1258981667 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 7373D4BBD1F for ; Mon, 23 Nov 2009 08:07:47 -0500 (EST) Message-ID: <4B0A890C.2000309@incunabulum.net> Date: Mon, 23 Nov 2009 13:07:24 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.23 (X11/20090824) MIME-Version: 1.0 To: FreeBSD Net References: <4B055A17.9080503@incunabulum.net> <4B055A6E.2090901@incunabulum.net> In-Reply-To: <4B055A6E.2090901@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PATCH] CFR: use refcount(9) in mcast X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 13:07:49 -0000 After discussion with jhb@, no real need for it. The atomics add instructions which aren't needed as all accesses are covered by a mutex. cheers, BMS From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 15:14:06 2009 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 72557106566C; Mon, 23 Nov 2009 15:14:06 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 422938FC18; Mon, 23 Nov 2009 15:14:05 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id nANFDsUA010760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 00:13:54 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 24 Nov 2009 00:13:54 +0900 Message-ID: From: Hajimu UMEMOTO To: Doug Barton In-Reply-To: <4B098D21.4040607@FreeBSD.org> References: <4B098D21.4040607@FreeBSD.org> User-Agent: xcite1.58> Wanderlust/2.15.7 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i386-portbld-freebsd8.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.0-RELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Tue_Nov_24_00:13:53_2009-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Tue, 24 Nov 2009 00:13:54 +0900 (JST) X-Virus-Scanned: clamav-milter 0.95.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: [CFR] unified rc.firewall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 15:14:06 -0000 --Multipart_Tue_Nov_24_00:13:53_2009-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On Sun, 22 Nov 2009 11:12:33 -0800 >>>>> Doug Barton said: dougb> In rc.firewall you seem to have copied afexists() from network.subr. dougb> Is there a reason that you did not simply source that file? That would dougb> be the preferred method. Also in that file you call "if afexists dougb> inet6" quite a few times. My preference from a performance standpoint dougb> would be to call it once, perhaps in a start_precmd then cache the value. Thank you for the comments. Ah, yes, afexists() is only in 9-CURRENT, and is not MFC'ed into 8, yet. So, I thought the patch should be able to work on both 9 and 8, for review. I've changed to source network.subr for afexists(). Calling afexists() several times was not good idea. So, I've changed to call afexists() just once. The new patch is attached. dougb> And of course, you have regression tested this thoroughly, yes? :) dougb> Please include scenarios where there is no INET6 in the kernel as well. Okay, I've tested it on INET6-less kernel, as well. Sincerely, --Multipart_Tue_Nov_24_00:13:53_2009-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="ipfw-unify.diff" Content-Transfer-Encoding: 7bit Index: etc/Makefile diff -u etc/Makefile.orig etc/Makefile --- etc/Makefile.orig 2009-10-25 10:10:29.000000000 +0900 +++ etc/Makefile 2009-11-22 22:07:19.840275808 +0900 @@ -15,7 +15,7 @@ inetd.conf libalias.conf login.access login.conf mac.conf motd \ netconfig network.subr networks newsyslog.conf nsswitch.conf \ phones profile protocols \ - rc rc.bsdextended rc.firewall rc.firewall6 rc.initdiskless \ + rc rc.bsdextended rc.firewall rc.initdiskless \ rc.sendmail rc.shutdown \ rc.subr remote rpc services shells \ sysctl.conf syslog.conf \ Index: etc/defaults/rc.conf diff -u etc/defaults/rc.conf.orig etc/defaults/rc.conf --- etc/defaults/rc.conf.orig 2009-10-25 10:10:29.000000000 +0900 +++ etc/defaults/rc.conf 2009-11-22 21:25:22.343296205 +0900 @@ -118,7 +118,10 @@ firewall_quiet="NO" # Set to YES to suppress rule display firewall_logging="NO" # Set to YES to enable events logging firewall_flags="" # Flags passed to ipfw when type is a file -firewall_client_net="192.0.2.0/24" # Network address for "client" firewall. +firewall_client_net="192.0.2.0/24" # IPv4 Network address for "client" + # firewall. +#firewall_client_net_ipv6="2001:db8:2:1::/64" # IPv6 network prefix for + # "client" firewall. firewall_simple_iif="ed1" # Inside network interface for "simple" # firewall. firewall_simple_inet="192.0.2.16/28" # Inside network address for "simple" @@ -127,12 +130,22 @@ # firewall. firewall_simple_onet="192.0.2.0/28" # Outside network address for "simple" # firewall. +#firewall_simple_iif_ipv6="ed1" # Inside IPv6 network interface for "simple" + # firewall. +#firewall_simple_inet_ipv6="2001:db8:2:800::/56" # Inside IPv6 network prefix + # for "simple" firewall. +#firewall_simple_oif_ipv6="ed0" # Outside IPv6 network interface for "simple" + # firewall. +#firewall_simple_onet_ipv6="2001:db8:2:0::/56" # Outside IPv6 network prefix + # for "simple" firewall. firewall_myservices="" # List of TCP ports on which this host # offers services for "workstation" firewall. firewall_allowservices="" # List of IPs which have access to # $firewall_myservices for "workstation" # firewall. -firewall_trusted="" # List of IPs which have full access to this +firewall_trusted="" # List of IPv4s which have full access to this + # host for "workstation" firewall. +firewall_trusted_ipv6="" # List of IPv6s which have full access to this # host for "workstation" firewall. firewall_logdeny="NO" # Set to YES to log default denied incoming # packets for "workstation" firewall. @@ -470,13 +483,18 @@ # faithd(8) setup. ipv6_ipv4mapping="NO" # Set to "YES" to enable IPv4 mapped IPv6 addr # communication. (like ::ffff:a.b.c.d) -ipv6_firewall_enable="NO" # Set to YES to enable IPv6 firewall - # functionality -ipv6_firewall_script="/etc/rc.firewall6" # Which script to run to set up the IPv6 firewall -ipv6_firewall_type="UNKNOWN" # IPv6 Firewall type (see /etc/rc.firewall6) -ipv6_firewall_quiet="NO" # Set to YES to suppress rule display -ipv6_firewall_logging="NO" # Set to YES to enable events logging -ipv6_firewall_flags="" # Flags passed to ip6fw when type is a file +#ipv6_firewall_enable="NO" # Set to YES to enable IPv6 firewall + # functionality (DEPRECAED) +#ipv6_firewall_script="/etc/rc.firewall6" # Which script to run to set up the + # IPv6 firewall (DEPRECAED) +#ipv6_firewall_type="UNKNOWN" # IPv6 Firewall type (see /etc/rc.firewall6) + # (DEPRECAED) +#ipv6_firewall_quiet="NO" # Set to YES to suppress rule display + # (DEPRECAED) +#ipv6_firewall_logging="NO" # Set to YES to enable events logging + # (DEPRECAED) +#ipv6_firewall_flags="" # Flags passed to ip6fw when type is a file + # (DEPRECAED) ipv6_ipfilter_rules="/etc/ipf6.rules" # rules definition file for ipfilter, # see /usr/src/contrib/ipfilter/rules # for examples Index: etc/rc.d/Makefile diff -u etc/rc.d/Makefile.orig etc/rc.d/Makefile --- etc/rc.d/Makefile.orig 2009-10-25 10:10:29.000000000 +0900 +++ etc/rc.d/Makefile 2009-11-22 20:42:16.398311126 +0900 @@ -15,7 +15,7 @@ hcsecd \ hostapd hostid hostid_save hostname \ inetd initrandom \ - ip6addrctl ip6fw ipfilter ipfs ipfw ipmon \ + ip6addrctl ipfilter ipfs ipfw ipmon \ ipnat ipsec ipxrouted \ jail \ kadmind kerberos keyserv kldxref kpasswdd \ Index: etc/rc.d/ipfw diff -u etc/rc.d/ipfw.orig etc/rc.d/ipfw --- etc/rc.d/ipfw.orig 2009-11-22 20:43:59.000000000 +0900 +++ etc/rc.d/ipfw 2009-11-23 19:29:05.426333161 +0900 @@ -61,7 +61,13 @@ # Enable the firewall # if ! ${SYSCTL_W} net.inet.ip.fw.enable=1 1>/dev/null 2>&1; then - warn "failed to enable firewall" + warn "failed to enable IPv4 firewall" + fi + if afexists inet6; then + if ! ${SYSCTL_W} net.inet6.ip6.fw.enable=1 1>/dev/null 2>&1 + then + warn "failed to enable IPv6 firewall" + fi fi } @@ -70,6 +76,9 @@ # Disable the firewall # ${SYSCTL_W} net.inet.ip.fw.enable=0 + if afexists inet6; then + ${SYSCTL_W} net.inet6.ip6.fw.enable=0 + fi if [ -f /etc/rc.d/natd ] ; then /etc/rc.d/natd quietstop fi Index: etc/rc.firewall diff -u etc/rc.firewall.orig etc/rc.firewall --- etc/rc.firewall.orig 2009-10-25 10:10:29.000000000 +0900 +++ etc/rc.firewall 2009-11-23 20:03:03.419477872 +0900 @@ -85,12 +85,43 @@ ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any + if [ $ipv6_available -eq 0 ]; then + ${fwcmd} add 400 deny ip6 from any to ::1 + ${fwcmd} add 500 deny ip6 from ::1 to any + fi +} + +setup_ipv6_mandatory () { + [ $ipv6_available -eq 0 ] || return 0 + + ############ + # Only in rare cases do you want to change these rules + # + # ND + # + # DAD + ${fwcmd} add pass ip6 from :: to ff02::/16 proto ipv6-icmp + # RS, RA, NS, NA, redirect... + ${fwcmd} add pass ip6 from fe80::/10 to fe80::/10 proto ipv6-icmp + ${fwcmd} add pass ip6 from fe80::/10 to ff02::/16 proto ipv6-icmp + + # Allow ICMPv6 destination unreach + ${fwcmd} add pass ip6 from any to any icmp6types 1 proto ipv6-icmp + + # Allow NS/NA/toobig (don't filter it out) + ${fwcmd} add pass ip6 from any to any icmp6types 2,135,136 \ + proto ipv6-icmp } if [ -n "${1}" ]; then firewall_type="${1}" fi +. /etc/rc.subr +. /etc/network.subr +afexists inet6 +ipv6_available=$? + ############ # Set quiet mode if requested # @@ -109,6 +140,7 @@ ${fwcmd} -f flush setup_loopback +setup_ipv6_mandatory ############ # Network Address Translation. All packets are passed to natd(8) @@ -166,11 +198,13 @@ # against people from outside your own network. # # Configuration: - # firewall_client_net: Network address of local network. + # firewall_client_net: Network address of local IPv4 network. + # firewall_client_net_ipv6: Network address of local IPv6 network. ############ # set this to your local network net="$firewall_client_net" + net6="$firewall_client_net_ipv6" # Allow limited broadcast traffic from my own net. ${fwcmd} add pass all from ${net} to 255.255.255.255 @@ -178,6 +212,16 @@ # Allow any traffic to or from my own net. ${fwcmd} add pass all from me to ${net} ${fwcmd} add pass all from ${net} to me + if [ -n "$net6" ]; then + ${fwcmd} add pass ip6 from me6 to ${net6} + ${fwcmd} add pass ip6 from ${net6} to me6 + fi + + if [ -n "$net6" ]; then + # Allow any link-local multicast traffic + ${fwcmd} add pass ip6 from fe80::/10 to ff02::/16 + ${fwcmd} add pass ip6 from ${net6} to ff02::/16 + fi # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established @@ -212,23 +256,35 @@ # on the inside at this machine for those services. # # Configuration: - # firewall_simple_iif: Inside network interface. - # firewall_simple_inet: Inside network address. - # firewall_simple_oif: Outside network interface. - # firewall_simple_onet: Outside network address. + # firewall_simple_iif: Inside IPv4 network interface. + # firewall_simple_inet: Inside IPv4 network address. + # firewall_simple_oif: Outside IPv4 network interface. + # firewall_simple_onet: Outside IPv4 network address. + # firewall_simple_iif_ipv6: Inside IPv6 network interface. + # firewall_simple_inet_ipv6: Inside IPv6 network prefix. + # firewall_simple_oif_ipv6: Outside IPv6 network interface. + # firewall_simple_onet_ipv6: Outside IPv6 network prefix. ############ # set these to your outside interface network oif="$firewall_simple_oif" onet="$firewall_simple_onet" + oif6="$firewall_simple_oif_ipv6" + onet6="$firewall_simple_onet_ipv6" # set these to your inside interface network iif="$firewall_simple_iif" inet="$firewall_simple_inet" + iif6="$firewall_simple_iif_ipv6" + inet6="$firewall_simple_inet_ipv6" # Stop spoofing ${fwcmd} add deny all from ${inet} to any in via ${oif} ${fwcmd} add deny all from ${onet} to any in via ${iif} + if [ -n "$oif6" -a -n "$onet6" -a -n "$iif6" -a -n "$inet6" ]; then + ${fwcmd} add deny ip6 from ${inet6} to any in via ${oif6} + ${fwcmd} add deny ip6 from ${onet6} to any in via ${iif6} + fi # Stop RFC1918 nets on the outside interface ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} @@ -254,7 +310,7 @@ case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then - ${fwcmd} add divert natd all from any to any via ${natd_interface} + ${fwcmd} add divert natd ip4 from any to any via ${natd_interface} fi ;; esac @@ -273,6 +329,55 @@ ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} + if [ -n "$oif6" -a -n "$onet6" -a -n "$iif6" -a -n "$inet6" ]; then + # Stop unique local unicast address on the outside interface + ${fwcmd} add deny ip6 from fc00::/7 to any via ${oif6} + ${fwcmd} add deny ip6 from any to fc00::/7 via ${oif6} + + # Stop site-local on the outside interface + ${fwcmd} add deny ip6 from fec0::/10 to any via ${oif6} + ${fwcmd} add deny ip6 from any to fec0::/10 via ${oif6} + + # Disallow "internal" addresses to appear on the wire. + ${fwcmd} add deny ip6 from ::ffff:0.0.0.0/96 to any \ + via ${oif6} + ${fwcmd} add deny ip6 from any to ::ffff:0.0.0.0/96 \ + via ${oif6} + + # Disallow packets to malicious IPv4 compatible prefix. + ${fwcmd} add deny ip6 from ::224.0.0.0/100 to any via ${oif6} + ${fwcmd} add deny ip6 from any to ::224.0.0.0/100 via ${oif6} + ${fwcmd} add deny ip6 from ::127.0.0.0/104 to any via ${oif6} + ${fwcmd} add deny ip6 from any to ::127.0.0.0/104 via ${oif6} + ${fwcmd} add deny ip6 from ::0.0.0.0/104 to any via ${oif6} + ${fwcmd} add deny ip6 from any to ::0.0.0.0/104 via ${oif6} + ${fwcmd} add deny ip6 from ::255.0.0.0/104 to any via ${oif6} + ${fwcmd} add deny ip6 from any to ::255.0.0.0/104 via ${oif6} + + ${fwcmd} add deny ip6 from ::0.0.0.0/96 to any via ${oif6} + ${fwcmd} add deny ip6 from any to ::0.0.0.0/96 via ${oif6} + + # Disallow packets to malicious 6to4 prefix. + ${fwcmd} add deny ip6 from 2002:e000::/20 to any via ${oif6} + ${fwcmd} add deny ip6 from any to 2002:e000::/20 via ${oif6} + ${fwcmd} add deny ip6 from 2002:7f00::/24 to any via ${oif6} + ${fwcmd} add deny ip6 from any to 2002:7f00::/24 via ${oif6} + ${fwcmd} add deny ip6 from 2002:0000::/24 to any via ${oif6} + ${fwcmd} add deny ip6 from any to 2002:0000::/24 via ${oif6} + ${fwcmd} add deny ip6 from 2002:ff00::/24 to any via ${oif6} + ${fwcmd} add deny ip6 from any to 2002:ff00::/24 via ${oif6} + + ${fwcmd} add deny ip6 from 2002:0a00::/24 to any via ${oif6} + ${fwcmd} add deny ip6 from any to 2002:0a00::/24 via ${oif6} + ${fwcmd} add deny ip6 from 2002:ac10::/28 to any via ${oif6} + ${fwcmd} add deny ip6 from any to 2002:ac10::/28 via ${oif6} + ${fwcmd} add deny ip6 from 2002:c0a8::/32 to any via ${oif6} + ${fwcmd} add deny ip6 from any to 2002:c0a8::/32 via ${oif6} + + ${fwcmd} add deny ip6 from ff05::/16 to any via ${oif6} + ${fwcmd} add deny ip6 from any to ff05::/16 via ${oif6} + fi + # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established @@ -291,7 +396,11 @@ ${fwcmd} add pass tcp from any to me 80 setup # Reject&Log all setup of incoming connections from the outside - ${fwcmd} add deny log tcp from any to any in via ${oif} setup + ${fwcmd} add deny log ip4 from any to any in via ${oif} setup proto tcp + if [ -n "$oif6" -a -n "$onet6" -a -n "$iif6" -a -n "$inet6" ]; then + ${fwcmd} add deny log ip6 from any to any in via ${oif6} \ + setup proto tcp + fi # Allow setup of any other TCP connection ${fwcmd} add pass tcp from any to any setup @@ -313,7 +422,7 @@ # offers services. # firewall_allowservices: List of IPs which has access to # $firewall_myservices. - # firewall_trusted: List of IPs which has full access + # firewall_trusted: List of IPv4s which has full access # to this host. Be very carefull # when setting this. This option can # seriously degrade the level of @@ -324,17 +433,31 @@ # firewall_nologports: List of TCP/UDP ports for which # denied incomming packets are not # logged. - + # firewall_trusted_ipv6: List of IPv6s which has full access + # to this host. Be very carefull + # when setting this. This option can + # seriously degrade the level of + # protection provided by the firewall. + # Allow packets for which a state has been built. ${fwcmd} add check-state # For services permitted below. ${fwcmd} add pass tcp from me to any established + if [ $ipv6_available -eq 0 ]; then + ${fwcmd} add pass ip6 from any to any proto tcp established + fi # Allow any connection out, adding state for each. ${fwcmd} add pass tcp from me to any setup keep-state ${fwcmd} add pass udp from me to any keep-state ${fwcmd} add pass icmp from me to any keep-state + if [ $ipv6_available -eq 0 ]; then + ${fwcmd} add pass ip6 from me6 to any proto tcp setup + ${fwcmd} add pass ip6 from me6 to any proto udp keep-state + ${fwcmd} add pass ip6 from me6 to any proto ipv6-icmp \ + keep-state + fi # Allow DHCP. ${fwcmd} add pass udp from 0.0.0.0 68 to 255.255.255.255 67 out @@ -343,6 +466,10 @@ # Some servers will ping the IP while trying to decide if it's # still in use. ${fwcmd} add pass icmp from any to any icmptype 8 + if [ $ipv6_available -eq 0 ]; then + ${fwcmd} add pass ip6 from any to any icmp6type 128,129 \ + proto ipv6-icmp + fi # Allow "mandatory" ICMP in. ${fwcmd} add pass icmp from any to any icmptype 3,4,11 @@ -361,6 +488,9 @@ for i in ${firewall_allowservices} ; do for j in ${firewall_myservices} ; do ${fwcmd} add pass tcp from $i to me $j + if [ $ipv6_available -eq 0 ]; then + ${fwcmd} add pass tcp from $i to me6 $j setup + fi done done @@ -370,7 +500,10 @@ for i in ${firewall_trusted} ; do ${fwcmd} add pass ip from $i to me done - + for i in ${firewall_trusted_ipv6} ; do + ${fwcmd} add pass ip6 from $i to me6 + done + ${fwcmd} add 65000 count ip from any to any # Drop packets to ports where we don't want logging --Multipart_Tue_Nov_24_00:13:53_2009-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Tue_Nov_24_00:13:53_2009-1-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 15:16:02 2009 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 5D9B8106566B for ; Mon, 23 Nov 2009 15:16:02 +0000 (UTC) (envelope-from proks@skylinetele.com) Received: from Harpy.sky.od.ua (harpy.sky.od.ua [81.25.224.2]) by mx1.freebsd.org (Postfix) with ESMTP id 71B538FC13 for ; Mon, 23 Nov 2009 15:15:53 +0000 (UTC) Received: from logos.sky.od.ua (logos [81.25.224.11]) by Harpy.sky.od.ua (8.12.10/8.12.10) with ESMTP id nANEubwi023200 for ; Mon, 23 Nov 2009 16:56:37 +0200 Message-ID: <4B0AA2CC.5010205@skylinetele.com> Date: Mon, 23 Nov 2009 16:57:16 +0200 From: "Prokofiev S.P." User-Agent: Thunderbird 2.0.0.21 (X11/20090410) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: Hangs down/up Intel NIC during creating vlan. Bug em driver ??? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 15:16:02 -0000 Hi ALL ! I have several servers with FreeBSD 8.0-PRERELEASE on SuperMicro with different Intel NICs. When I create new vlan on em interface ( ifconfig vlan557 create vlandev em0 vlan 557), it hangs down and then up and server becomes inaccessible by ssh, but reply on icmp request. on amd64, custom kernel: em0@pci0:13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (82573E)' class = network subclass = ethernet em1@pci0:14:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Intel PRO/1000 PL Network Adaptor (82573L)' class = network subclass = ethernet on i386, GENERIC kernel: em0@pci0:2:1:0: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (82546EB)' class = network subclass = ethernet em1@pci0:2:1:1: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Dual Port Gigabit Ethernet Controller (82546EB)' class = network subclass = ethernet /var/log/messages: Nov 23 11:35:49 freebsd kernel: em1: link state changed to DOWN Nov 23 11:35:49 freebsd kernel: vlan557: link state changed to DOWN Nov 23 11:35:52 freebsd kernel: em1: link state changed to UP Nov 23 11:35:52 freebsd kernel: vlan557: link state changed to UP Nov 23 11:36:09 freebsd kernel: em1: link state changed to DOWN Nov 23 11:36:13 freebsd kernel: em1: link state changed to UP From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 15:56:18 2009 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 93E15106566C; Mon, 23 Nov 2009 15:56:18 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 650638FC15; Mon, 23 Nov 2009 15:56:18 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EAB1C46B37; Mon, 23 Nov 2009 10:56:17 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 2F2218A01D; Mon, 23 Nov 2009 10:56:17 -0500 (EST) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 23 Nov 2009 10:56:14 -0500 User-Agent: KMail/1.9.7 References: <4B098D21.4040607@FreeBSD.org> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200911231056.15247.jhb@freebsd.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 23 Nov 2009 10:56:17 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-net@freebsd.org, Doug Barton , Hajimu UMEMOTO Subject: Re: [CFR] unified rc.firewall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 15:56:18 -0000 On Monday 23 November 2009 10:13:54 am Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Sun, 22 Nov 2009 11:12:33 -0800 > >>>>> Doug Barton said: > > dougb> In rc.firewall you seem to have copied afexists() from network.subr. > dougb> Is there a reason that you did not simply source that file? That would > dougb> be the preferred method. Also in that file you call "if afexists > dougb> inet6" quite a few times. My preference from a performance standpoint > dougb> would be to call it once, perhaps in a start_precmd then cache the value. > > Thank you for the comments. > Ah, yes, afexists() is only in 9-CURRENT, and is not MFC'ed into 8, > yet. So, I thought the patch should be able to work on both 9 and 8, > for review. I've changed to source network.subr for afexists(). > Calling afexists() several times was not good idea. So, I've changed > to call afexists() just once. > The new patch is attached. > > dougb> And of course, you have regression tested this thoroughly, yes? :) > dougb> Please include scenarios where there is no INET6 in the kernel as well. > > Okay, I've tested it on INET6-less kernel, as well. Some comments I have: @@ -178,6 +212,16 @@ # Allow any traffic to or from my own net. ${fwcmd} add pass all from me to ${net} ${fwcmd} add pass all from ${net} to me + if [ -n "$net6" ]; then + ${fwcmd} add pass ip6 from me6 to ${net6} + ${fwcmd} add pass ip6 from ${net6} to me6 + fi + + if [ -n "$net6" ]; then + # Allow any link-local multicast traffic + ${fwcmd} add pass ip6 from fe80::/10 to ff02::/16 + ${fwcmd} add pass ip6 from ${net6} to ff02::/16 + fi Any reason to not use 'all' here rather than 'ip6' to match the earlier IPv4 rules? @@ -273,6 +329,55 @@ ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} + if [ -n "$oif6" -a -n "$onet6" -a -n "$iif6" -a -n "$inet6" ]; then + # Stop unique local unicast address on the outside interface + ${fwcmd} add deny ip6 from fc00::/7 to any via ${oif6} + ${fwcmd} add deny ip6 from any to fc00::/7 via ${oif6} + .... Similarly here, why not use 'all' instead of 'ip6'? @@ -291,7 +396,11 @@ ${fwcmd} add pass tcp from any to me 80 setup # Reject&Log all setup of incoming connections from the outside - ${fwcmd} add deny log tcp from any to any in via ${oif} setup + ${fwcmd} add deny log ip4 from any to any in via ${oif} setup proto tcp + if [ -n "$oif6" -a -n "$onet6" -a -n "$iif6" -a -n "$inet6" ]; then + ${fwcmd} add deny log ip6 from any to any in via ${oif6} \ + setup proto tcp + fi I would actually not use separate v6 interfaces for the 'simple' firewall but just have 'oif', 'onet', and 'onet_ipv6' variables. Then you don't need this diff at all as the existing rule will work fine. # For services permitted below. ${fwcmd} add pass tcp from me to any established + if [ $ipv6_available -eq 0 ]; then + ${fwcmd} add pass ip6 from any to any proto tcp established + fi I think this extra rule here isn't needed at all as the first rule should already match all of those packets. # Allow any connection out, adding state for each. ${fwcmd} add pass tcp from me to any setup keep-state ${fwcmd} add pass udp from me to any keep-state ${fwcmd} add pass icmp from me to any keep-state + if [ $ipv6_available -eq 0 ]; then + ${fwcmd} add pass ip6 from me6 to any proto tcp setup + ${fwcmd} add pass ip6 from me6 to any proto udp keep-state + ${fwcmd} add pass ip6 from me6 to any proto ipv6-icmp \ + keep-state + fi I think it is more consistent to use 'pass tcp from me6 to any' similar to the IPv4 rules here. It is also shorter and easier to read that way IMO. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 16:15:07 2009 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 846CF106566C; Mon, 23 Nov 2009 16:15:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [IPv6:2001:4068:10::3]) by mx1.freebsd.org (Postfix) with ESMTP id 0FBAD8FC27; Mon, 23 Nov 2009 16:15:07 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id C71E941C64A; Mon, 23 Nov 2009 17:15:05 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([192.168.74.103]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id l45mUYSjC5+D; Mon, 23 Nov 2009 17:15:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 5C5ED41C679; Mon, 23 Nov 2009 17:15: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 862C04448EC; Mon, 23 Nov 2009 16:12:20 +0000 (UTC) Date: Mon, 23 Nov 2009 16:12:20 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Hajimu UMEMOTO In-Reply-To: <200911231056.15247.jhb@freebsd.org> Message-ID: <20091123161013.X37440@maildrop.int.zabbadoz.net> References: <4B098D21.4040607@FreeBSD.org> <200911231056.15247.jhb@freebsd.org> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: [CFR] unified rc.firewall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 16:15:07 -0000 On Mon, 23 Nov 2009, John Baldwin wrote: > On Monday 23 November 2009 10:13:54 am Hajimu UMEMOTO wrote: >> Hi, >> >>>>>>> On Sun, 22 Nov 2009 11:12:33 -0800 >>>>>>> Doug Barton said: >> >> dougb> In rc.firewall you seem to have copied afexists() from network.subr. >> dougb> Is there a reason that you did not simply source that file? That > would >> dougb> be the preferred method. Also in that file you call "if afexists >> dougb> inet6" quite a few times. My preference from a performance standpoint >> dougb> would be to call it once, perhaps in a start_precmd then cache the > value. >> >> Thank you for the comments. >> Ah, yes, afexists() is only in 9-CURRENT, and is not MFC'ed into 8, >> yet. So, I thought the patch should be able to work on both 9 and 8, >> for review. I've changed to source network.subr for afexists(). >> Calling afexists() several times was not good idea. So, I've changed >> to call afexists() just once. >> The new patch is attached. >> >> dougb> And of course, you have regression tested this thoroughly, yes? :) >> dougb> Please include scenarios where there is no INET6 in the kernel as > well. >> >> Okay, I've tested it on INET6-less kernel, as well. > > Some comments I have: > > @@ -178,6 +212,16 @@ > # Allow any traffic to or from my own net. > ${fwcmd} add pass all from me to ${net} > ${fwcmd} add pass all from ${net} to me I haven't looked at the entire update but as I see this I shall note unless I missed a fix to ipfw, you need to make that ip and use ip6 and me6 for the new world order. Please make sure that this works as expected in mixed-world scenarios as well as legacy IP and IPv6 only worlds. /bz -- Bjoern A. Zeeb It will not break if you know what you are doing. From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 17:27:38 2009 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 6CCFB1065679; Mon, 23 Nov 2009 17:27:38 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 7C00F8FC15; Mon, 23 Nov 2009 17:27:37 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id nANHRNZc041681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Nov 2009 02:27:27 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Tue, 24 Nov 2009 02:27:23 +0900 Message-ID: From: Hajimu UMEMOTO To: John Baldwin In-Reply-To: <200911231056.15247.jhb@freebsd.org> References: <4B098D21.4040607@FreeBSD.org> <200911231056.15247.jhb@freebsd.org> User-Agent: xcite1.58> Wanderlust/2.15.7 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i386-portbld-freebsd8.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.0-RELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Tue, 24 Nov 2009 02:27:27 +0900 (JST) X-Virus-Scanned: clamav-milter 0.95.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Doug Barton Subject: Re: [CFR] unified rc.firewall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 17:27:38 -0000 Hi, >>>>> On Mon, 23 Nov 2009 10:56:14 -0500 >>>>> John Baldwin said: jhb> @@ -178,6 +212,16 @@ jhb> # Allow any traffic to or from my own net. jhb> ${fwcmd} add pass all from me to ${net} jhb> ${fwcmd} add pass all from ${net} to me jhb> + if [ -n "$net6" ]; then jhb> + ${fwcmd} add pass ip6 from me6 to ${net6} jhb> + ${fwcmd} add pass ip6 from ${net6} to me6 jhb> + fi jhb> + jhb> + if [ -n "$net6" ]; then jhb> + # Allow any link-local multicast traffic jhb> + ${fwcmd} add pass ip6 from fe80::/10 to ff02::/16 jhb> + ${fwcmd} add pass ip6 from ${net6} to ff02::/16 jhb> + fi jhb> Any reason to not use 'all' here rather than 'ip6' to match the earlier IPv4 jhb> rules? Thank you for the review. The rule is only applicable for IPv6. Rather, I prefer to use 'ip4' explicitly over 'all' or 'ip' here. However, changing 'all' to 'ip4' makes the diff complex. So, I keep 'all' as is. jhb> @@ -273,6 +329,55 @@ jhb> ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} jhb> ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} jhb> jhb> + if [ -n "$oif6" -a -n "$onet6" -a -n "$iif6" -a -n "$inet6" ]; then jhb> + # Stop unique local unicast address on the outside interface jhb> + ${fwcmd} add deny ip6 from fc00::/7 to any via ${oif6} jhb> + ${fwcmd} add deny ip6 from any to fc00::/7 via ${oif6} jhb> + jhb> .... jhb> Similarly here, why not use 'all' instead of 'ip6'? Same above. jhb> @@ -291,7 +396,11 @@ jhb> ${fwcmd} add pass tcp from any to me 80 setup jhb> jhb> # Reject&Log all setup of incoming connections from the outside jhb> - ${fwcmd} add deny log tcp from any to any in via ${oif} setup jhb> + ${fwcmd} add deny log ip4 from any to any in via ${oif} setup proto jhb> tcp jhb> + if [ -n "$oif6" -a -n "$onet6" -a -n "$iif6" -a -n "$inet6" ]; then jhb> + ${fwcmd} add deny log ip6 from any to any in via ${oif6} \ jhb> + setup proto tcp jhb> + fi jhb> I would actually not use separate v6 interfaces for the 'simple' firewall jhb> but just have 'oif', 'onet', and 'onet_ipv6' variables. Then you don't need jhb> this diff at all as the existing rule will work fine. Yup, it should makes rule simpler. However, many sites still use tunnel for IPv6 connectivity. I think, separating 'oif' and 'oif6' makes such sites happy. So, this diff should make sense, IMHO. jhb> # For services permitted below. jhb> ${fwcmd} add pass tcp from me to any established jhb> + if [ $ipv6_available -eq 0 ]; then jhb> + ${fwcmd} add pass ip6 from any to any proto tcp established jhb> + fi jhb> I think this extra rule here isn't needed at all as the first rule should jhb> already match all of those packets. WORKSTATION type rule is fully dynamic. However, I saw it doesn't work for IPv6 as expected. SSH connection stalls after some period. I suspect keepalive timer doesn't work well for IPv6. So, I changed to use traditional setup/established rule for TCP/IPv6. Further, 'me' doesn't match to IPv6 address. jhb> # Allow any connection out, adding state for each. jhb> ${fwcmd} add pass tcp from me to any setup keep-state jhb> ${fwcmd} add pass udp from me to any keep-state jhb> ${fwcmd} add pass icmp from me to any keep-state jhb> + if [ $ipv6_available -eq 0 ]; then jhb> + ${fwcmd} add pass ip6 from me6 to any proto tcp setup jhb> + ${fwcmd} add pass ip6 from me6 to any proto udp keep-state jhb> + ${fwcmd} add pass ip6 from me6 to any proto ipv6-icmp \ jhb> + keep-state jhb> + fi jhb> I think it is more consistent to use 'pass tcp from me6 to any' similar to jhb> the IPv4 rules here. It is also shorter and easier to read that way IMO. I thought similar thing with 'all' vs 'ip4'. Rather, I prefer to change IPv4 rules. However, if 'all' is preferable, I'll change so. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 17:29:41 2009 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 C873A10656A9 for ; Mon, 23 Nov 2009 17:29:41 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 53ADB8FC15 for ; Mon, 23 Nov 2009 17:29:40 +0000 (UTC) Received: by ewy26 with SMTP id 26so2251558ewy.3 for ; Mon, 23 Nov 2009 09:29:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=KrTEiM3OvL9OmOx4Jc1SSPeU7C+eEixoFXSze9sAs3A=; b=I6xGwhrZERoNPL+uKNNgdoqxh16Djj3peYXYpCzod2t1X+GOnffKRkOjxNeZdRDO5K JetOW58F5Ql7xm0LEMtu+awSTVzUnpTlN4YNyvFSpU0BjMvWZbbrbk1+UsJ8rgpnZzxE JZgIN1D3vSJQlBN92nyO7l2u37bypdIzb+AkM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=K34qkwDIXbm9XRF2uwNnTLW+4hxf7iJLIUJu3eB09qwt3qz/w8AL1tk+rlTcv9kPrU R30v0oc1fLs+WtFyTMYsd3rzHeuLYaoSZlII93RMypeKGxxKIcnbTO+Q6UExiBWXNvtC vTLbKHqddZI9+9qEvkGBK6gS3/iK1hD65hhXo= MIME-Version: 1.0 Received: by 10.216.91.20 with SMTP id g20mr1589393wef.94.1258997380165; Mon, 23 Nov 2009 09:29:40 -0800 (PST) In-Reply-To: <4B0AA2CC.5010205@skylinetele.com> References: <4B0AA2CC.5010205@skylinetele.com> Date: Mon, 23 Nov 2009 09:29:39 -0800 Message-ID: <2a41acea0911230929h53771ed8j2d8f81be286476a0@mail.gmail.com> From: Jack Vogel To: "Prokofiev S.P." Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: Hangs down/up Intel NIC during creating vlan. Bug em driver ??? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 17:29:41 -0000 Custom kernel, well, does it happen on the installed GENERIC kernel, and what is needed to reproduce this, just down/up the interface? And are you saying that it will happen on either the 82573 or the 82546 or just one of them?? Would be nice if this stuff could be discovered earlier :( In any case I will look into it, there is another reported problems with em and vlans as well. Jack 2009/11/23 Prokofiev S.P. > Hi ALL ! > I have several servers with FreeBSD 8.0-PRERELEASE on SuperMicro with > different Intel NICs. When I create new vlan on em interface > ( ifconfig vlan557 create vlandev em0 vlan 557), > it hangs down and then up and server becomes inaccessible by ssh, but reply > on icmp request. > > on amd64, custom kernel: > > em0@pci0:13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 > rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel Corporation 82573E Gigabit Ethernet Controller > (Copper) (82573E)' > class = network > subclass = ethernet > em1@pci0:14:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 > rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Intel PRO/1000 PL Network Adaptor (82573L)' > class = network > subclass = ethernet > > on i386, GENERIC kernel: > > em0@pci0:2:1:0: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Dual Port Gigabit Ethernet Controller (82546EB)' > class = network > subclass = ethernet > em1@pci0:2:1:1: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 > hdr=0x00 > vendor = 'Intel Corporation' > device = 'Dual Port Gigabit Ethernet Controller (82546EB)' > class = network > subclass = ethernet > > /var/log/messages: > > Nov 23 11:35:49 freebsd kernel: em1: link state changed to DOWN > Nov 23 11:35:49 freebsd kernel: vlan557: link state changed to DOWN > Nov 23 11:35:52 freebsd kernel: em1: link state changed to UP > Nov 23 11:35:52 freebsd kernel: vlan557: link state changed to UP > Nov 23 11:36:09 freebsd kernel: em1: link state changed to DOWN > Nov 23 11:36:13 freebsd kernel: em1: link state changed to UP > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 17:36:04 2009 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 EAF7C1065670; Mon, 23 Nov 2009 17:36:04 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by mx1.freebsd.org (Postfix) with ESMTP id 2D3EC8FC1E; Mon, 23 Nov 2009 17:36:03 +0000 (UTC) Received: by ewy26 with SMTP id 26so2258045ewy.3 for ; Mon, 23 Nov 2009 09:36:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=5S+vddvYFSGxHcxOZmbKo/WeKLL/Ryy0KvmLYft9/m4=; b=fzKPiPWyz8JXnkLesKKAp/iPdLCOHXvgpVbPvO5COlBvK71b9ecgRQ39eS6jZaVO4N CyPGiVe7XKaI47skT2VDvtgl5O+XD5yxmVxdkWTOOqhpGauVnrKdMIrzMlg0y9KrZWip rpOx+TQ5k/IlauM3RaWsH1bJ03aVGuyO1FsA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QhAyTNq39bs/wOmX5DpOWnuaQ3d6SGvoBd5Rm6y6uyN252mg4rtSGrG5i//+aiPC9C dkEVkL5qu+M8ijw4/miER5o4t853UoJ7OUN+Fg5d6d0E2lfdY3GCykF/wcX6rJ0ny4h6 lJquECukOlvptCKE7RkVeAB/k0ZGkXetPAgls= MIME-Version: 1.0 Received: by 10.216.86.16 with SMTP id v16mr1642167wee.162.1258997761277; Mon, 23 Nov 2009 09:36:01 -0800 (PST) In-Reply-To: References: Date: Mon, 23 Nov 2009 09:36:01 -0800 Message-ID: <2a41acea0911230936n2ed75bcbk34e362a88e70ea7f@mail.gmail.com> From: Jack Vogel To: =?UTF-8?Q?T=C4=B1lman_Linneweh?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jack Vogel , freebsd-net@freebsd.org Subject: Re: Intel NIC 0x10f08086 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 17:36:05 -0000 This is the new PCH interface, there will be a driver that supports it checked into CURRENT shortly. Cheers, Jack On Sun, Nov 22, 2009 at 4:33 AM, T=C4=B1lman Linneweh w= rote: > Hi List, Hi Jack! > > I have an Intel NIC with the pci chip=3D0x10f08086 rev=3D0x05 as onboard = Card > on an "Intel DP55WB" Mainboard. > > According to Google it is an "82578DC". > > Now i wonder how to make it work. I tried to add the PCI ID to both em(4) > and igb(4) but the attach failed, so it looks like something more is > required. > > Any ideas? > > regards > arved From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 17:55:38 2009 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 DF02510656CD; Mon, 23 Nov 2009 17:55:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 9B13E8FC1F; Mon, 23 Nov 2009 17:55:37 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 1CA6E46B29; Mon, 23 Nov 2009 12:55:37 -0500 (EST) Received: from jhbbsd.hudson-trading.com (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 31D208A01B; Mon, 23 Nov 2009 12:55:36 -0500 (EST) From: John Baldwin To: Hajimu UMEMOTO Date: Mon, 23 Nov 2009 12:55:25 -0500 User-Agent: KMail/1.9.7 References: <200911231056.15247.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200911231255.26279.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 23 Nov 2009 12:55:36 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Doug Barton Subject: Re: [CFR] unified rc.firewall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 17:55:38 -0000 On Monday 23 November 2009 12:27:23 pm Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Mon, 23 Nov 2009 10:56:14 -0500 > >>>>> John Baldwin said: > > jhb> @@ -178,6 +212,16 @@ > jhb> # Allow any traffic to or from my own net. > jhb> ${fwcmd} add pass all from me to ${net} > jhb> ${fwcmd} add pass all from ${net} to me > jhb> + if [ -n "$net6" ]; then > jhb> + ${fwcmd} add pass ip6 from me6 to ${net6} > jhb> + ${fwcmd} add pass ip6 from ${net6} to me6 > jhb> + fi > jhb> + > jhb> + if [ -n "$net6" ]; then > jhb> + # Allow any link-local multicast traffic > jhb> + ${fwcmd} add pass ip6 from fe80::/10 to ff02::/16 > jhb> + ${fwcmd} add pass ip6 from ${net6} to ff02::/16 > jhb> + fi > > jhb> Any reason to not use 'all' here rather than 'ip6' to match the earlier IPv4 > jhb> rules? > > Thank you for the review. > The rule is only applicable for IPv6. Rather, I prefer to use 'ip4' > explicitly over 'all' or 'ip' here. However, changing 'all' to 'ip4' > makes the diff complex. So, I keep 'all' as is. Hmm, however, using 'all' will work, and while in this case the typing is the same I find it easier to read 'add pass tcp <...>' vs 'add pass ip <...> proto tcp'. I do think they should be consistent regardless. > jhb> # For services permitted below. > jhb> ${fwcmd} add pass tcp from me to any established > jhb> + if [ $ipv6_available -eq 0 ]; then > jhb> + ${fwcmd} add pass ip6 from any to any proto tcp established > jhb> + fi > > jhb> I think this extra rule here isn't needed at all as the first rule should > jhb> already match all of those packets. > > WORKSTATION type rule is fully dynamic. However, I saw it doesn't > work for IPv6 as expected. SSH connection stalls after some period. > I suspect keepalive timer doesn't work well for IPv6. > So, I changed to use traditional setup/established rule for TCP/IPv6. > Further, 'me' doesn't match to IPv6 address. I had missed the me vs any. It is true that the equivalent rule would use me6. I would rather figure out the IPv6 bug so that TCP is treated the same for both protocols instead of having a weaker firewall for IPv6 than IPV4. > jhb> # Allow any connection out, adding state for each. > jhb> ${fwcmd} add pass tcp from me to any setup keep-state > jhb> ${fwcmd} add pass udp from me to any keep-state > jhb> ${fwcmd} add pass icmp from me to any keep-state > jhb> + if [ $ipv6_available -eq 0 ]; then > jhb> + ${fwcmd} add pass ip6 from me6 to any proto tcp setup > jhb> + ${fwcmd} add pass ip6 from me6 to any proto udp keep-state > jhb> + ${fwcmd} add pass ip6 from me6 to any proto ipv6-icmp \ > jhb> + keep-state > jhb> + fi > > jhb> I think it is more consistent to use 'pass tcp from me6 to any' similar to > jhb> the IPv4 rules here. It is also shorter and easier to read that way IMO. > > I thought similar thing with 'all' vs 'ip4'. Rather, I prefer to > change IPv4 rules. However, if 'all' is preferable, I'll change so. I do find the shorter version easier to read, and it matches the existing style as well as the examples in the manual page, handbook, etc. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 18:01:43 2009 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 7DFDF1065696 for ; Mon, 23 Nov 2009 18:01:43 +0000 (UTC) (envelope-from administrator@shtorm.com) Received: from ns.shtorm.com (ns.shtorm.com [195.62.14.3]) by mx1.freebsd.org (Postfix) with ESMTP id 04A738FC12 for ; Mon, 23 Nov 2009 18:01:42 +0000 (UTC) Received: from [10.66.6.77] (unknown [10.66.6.77]) by ns.shtorm.com (Postfix) with ESMTP id 221B71A0846 for ; Mon, 23 Nov 2009 19:39:35 +0200 (EET) From: "Yuriy A. Korobko" To: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" Date: Mon, 23 Nov 2009 19:42:20 +0200 Message-ID: <1258998140.3015.34.camel@stormi-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Subject: Reducing number of interrupts from intel pro 1000 et adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 18:01:43 -0000 Hi, I'd like to know a way to control tx interrupts on intel pro 1000 et adapter with igb driver. Just installed one in the router and systat shows 8-9k rx interrupts and 20k tx interrupts from igb0 and igb1 adapters. Box is a router running freebsd 7.2 release, I've tried default driver from kernel source and latest from intel site, effect is the same with automatic interrupt moderation enabled and disabled. I have the same box with intel pro 1000 pt adapter which have tx(rx)_int_delay sysctls in em driver, I was able to reduce number of tx/rx interrupts to 7-8k per interface and got much more cpu idle because of less context switches with same pps. Interfacae load border# netstat -I igb0 -w 1 input (igb0) output packets errs bytes packets errs bytes colls 41438 0 37923274 51173 0 24539512 0 44827 0 41626876 53408 0 24595412 0 43300 0 39736056 53118 0 24574219 0 43146 0 40399285 53455 0 24368290 0 44827 0 42463307 53921 0 23959752 0 Here is sysctls dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 1.7.4 dev.igb.0.%driver: igb dev.igb.0.%location: slot=0 function=0 dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x8086 subdevice=0xa03c class=0x020000 dev.igb.0.%parent: pci1 dev.igb.0.debug: -1 dev.igb.0.stats: -1 dev.igb.0.flow_control: 0 dev.igb.0.enable_aim: 1 dev.igb.0.low_latency: 1000 dev.igb.0.ave_latency: 4000 dev.igb.0.bulk_latency: 8000 dev.igb.0.rx_processing_limit: 1000 dev.igb.1.%desc: Intel(R) PRO/1000 Network Connection version - 1.7.4 dev.igb.1.%driver: igb dev.igb.1.%location: slot=0 function=1 dev.igb.1.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x8086 subdevice=0xa03c class=0x020000 dev.igb.1.%parent: pci1 dev.igb.1.debug: -1 dev.igb.1.stats: -1 dev.igb.1.flow_control: 0 dev.igb.1.enable_aim: 1 dev.igb.1.low_latency: 1000 dev.igb.1.ave_latency: 4000 dev.igb.1.bulk_latency: 8000 dev.igb.1.rx_processing_limit: 1000 And debug kernel: igb0: Adapter hardware address = 0xc796ec1c kernel: igb0: CTRL = 0x40c00241 RCTL = 0x48002 kernel: igb0: Packet buffer = Tx=0k Rx=0k kernel: igb0: Flow control watermarks high = 63488 low = 61988 kernel: igb0: Queue(0) tdh = 3023, tdt = 3025 kernel: igb0: TX(0) no descriptors avail event = 0 kernel: igb0: TX(0) MSIX IRQ Handled = 3754097484 kernel: igb0: TX(0) Packets sent = 4815628967 kernel: igb0: Queue(0) rdh = 3658, rdt = 3645 kernel: igb0: RX(0) Packets received = 7611879022 kernel: igb0: RX(0) Split Packets = 0 kernel: igb0: RX(0) Byte count = 7013625984942 kernel: igb0: RX(0) MSIX IRQ Handled = 3232986641 kernel: igb0: RX(0) LRO Queued= 0 kernel: igb0: RX(0) LRO Flushed= 0 kernel: igb0: LINK MSIX IRQ Handled = 3 kernel: igb0: Mbuf defrag failed = 0 kernel: igb0: Std mbuf header failed = 0 kernel: igb0: Std mbuf packet failed = 0 kernel: igb0: Driver dropped packets = 0 kernel: igb0: Driver tx dma failure in xmit = 0 kernel: igb1: Adapter hardware address = 0xc796dc1c kernel: igb1: CTRL = 0x40c00241 RCTL = 0x48002 kernel: igb1: Packet buffer = Tx=0k Rx=0k kernel: igb1: Flow control watermarks high = 63488 low = 61988 kernel: igb1: Queue(0) tdh = 4093, tdt = 4093 kernel: igb1: TX(0) no descriptors avail event = 0 kernel: igb1: TX(0) MSIX IRQ Handled = 10882048108 kernel: igb1: TX(0) Packets sent = 31169311987 kernel: igb1: Queue(0) rdh = 2515, rdt = 2513 kernel: igb1: RX(0) Packets received = 30747961847 kernel: igb1: RX(0) Split Packets = 0 kernel: igb1: RX(0) Byte count = 26511993282060 kernel: igb1: RX(0) MSIX IRQ Handled = 4834518320 kernel: igb1: RX(0) LRO Queued= 0 kernel: igb1: RX(0) LRO Flushed= 0 kernel: igb1: LINK MSIX IRQ Handled = 5 kernel: igb1: Mbuf defrag failed = 0 kernel: igb1: Std mbuf header failed = 0 kernel: igb1: Std mbuf packet failed = 0 kernel: igb1: Driver dropped packets = 0 kernel: igb1: Driver tx dma failure in xmit = 0 From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 18:27:51 2009 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 B2F10106568D; Mon, 23 Nov 2009 18:27:51 +0000 (UTC) (envelope-from ben@b1c1l1.com) Received: from lancer.b1c1l1.com (unknown [IPv6:2607:f358:1a:1a:1000::]) by mx1.freebsd.org (Postfix) with ESMTP id 97A288FC19; Mon, 23 Nov 2009 18:27:51 +0000 (UTC) Received: from supra.b1c1l1.com (supra.b1c1l1.com [IPv6:2001:470:83fb:0:216:cbff:fe07:bd1b]) by lancer.b1c1l1.com (Postfix) with ESMTPSA id 015935C21; Mon, 23 Nov 2009 10:27:50 -0800 (PST) Message-ID: <4B0AD41F.6020709@b1c1l1.com> Date: Mon, 23 Nov 2009 10:27:43 -0800 From: Benjamin Lee User-Agent: Thunderbird 2.0.0.23 (X11/20090829) MIME-Version: 1.0 To: John Baldwin References: <200911231056.15247.jhb@freebsd.org> <200911231255.26279.jhb@freebsd.org> In-Reply-To: <200911231255.26279.jhb@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB79F6952EB28033E2BC02B4D" Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Hajimu UMEMOTO , Doug Barton Subject: Re: [CFR] unified rc.firewall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 18:27:51 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB79F6952EB28033E2BC02B4D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 11/23/2009 09:55 AM, John Baldwin wrote: > On Monday 23 November 2009 12:27:23 pm Hajimu UMEMOTO wrote: >> Hi, >> >>>>>>> On Mon, 23 Nov 2009 10:56:14 -0500 >>>>>>> John Baldwin said: >> jhb> # For services permitted below. >> jhb> ${fwcmd} add pass tcp from me to any established >> jhb> + if [ $ipv6_available -eq 0 ]; then >> jhb> + ${fwcmd} add pass ip6 from any to any proto tcp e= stablished >> jhb> + fi >> >> jhb> I think this extra rule here isn't needed at all as the first rul= e should >> jhb> already match all of those packets. >> >> WORKSTATION type rule is fully dynamic. However, I saw it doesn't >> work for IPv6 as expected. SSH connection stalls after some period. >> I suspect keepalive timer doesn't work well for IPv6. >> So, I changed to use traditional setup/established rule for TCP/IPv6. >> Further, 'me' doesn't match to IPv6 address. >=20 > I had missed the me vs any. It is true that the equivalent rule would = use > me6. I would rather figure out the IPv6 bug so that TCP is treated the= > same for both protocols instead of having a weaker firewall for IPv6 th= an > IPV4. There is a bug in ipfw send_pkt() that prevents ipfw_tick() from functioning for IPv6. See PR kern/117234. --=20 Benjamin Lee http://www.b1c1l1.com/ --------------enigB79F6952EB28033E2BC02B4D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJLCtQnAAoJEHBW16CPoSMCjswP/ixFY0rcmatbLLK450mhUfc3 VhWZO6pK6qw3I/9rLr14vBoSyOFa839y/3RusTIpr6xHMOF+fL3ZlUWIT7xlk0nr 83S/Zv670FD+SBnzBqHEcTOinrCo/qz4duWqE56jki8329S4usEIJCz1ZOzjk0mi SRca7IuQp5/Rfb49lBfUjT1pOW/pVcx59kV87hXphj/re/TLCSQa+83N70MKHZHW 6kv+SCqymmysvUzWrbkJfb/NPAPGZL7aSO6M+FTuBrfaTFW9DlRJyEpXTmsb7p3U ixfXfUL5OjbKT38EhCGJFuJ7vlzhGwzzOzgDlQRshu3zabrVnPOL527s6j94OjN/ 0yx8RUyh+x88ShKBBdeSxFoM824LdCTdjWfsMSAvPlumlOnCvhGgVY4wdau+yDFc ZN0XNE6gD7rCdIHSmRSYDkLg+ZYwMITxpJiVS2mvoB03v7hPgGLV+YZEmTqG6piX SkVmX7zHW5RFBHmjKEHhXyMSR+lglXdtAMSqlIwXsv6hjrFXEBgH5fP5cMNs5ulD fs/vZJ1ICm2WXgEezKo3gpXyGaa44BZdxbjTEi7Fbmx/0eofIEKRESUwTEPkfD1f 4fpnhdNFZYdvndT2Q3rkFurxxKQJkhKNiUvZIxA2zAzBfrqzFFHH00JI1Y2ZAe84 H9XD0c9VoTjX/0GoKTGs =O7NI -----END PGP SIGNATURE----- --------------enigB79F6952EB28033E2BC02B4D-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 18:32:36 2009 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 B36F41065698; Mon, 23 Nov 2009 18:32:36 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 339188FC0C; Mon, 23 Nov 2009 18:32:35 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 49DCA1E0071B; Mon, 23 Nov 2009 19:32:34 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id nANIS9QN037770; Mon, 23 Nov 2009 19:28:09 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id nANIS9X4037769; Mon, 23 Nov 2009 19:28:09 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Mon, 23 Nov 2009 19:28:09 +0100 To: Juergen Lock Message-ID: <20091123182809.GA35896@triton8.kn-bremen.de> References: <4B08DD0C.3080106@FreeBSD.org> <4B0963BF.1070908@shapeshifter.se> <4B0972B5.40903@FreeBSD.org> <200911222316.nAMNGwfV068520@triton8.kn-bremen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200911222316.nAMNGwfV068520@triton8.kn-bremen.de> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@FreeBSD.org, freebsd-emulation@FreeBSD.org, Doug Barton , fli@shapeshifter.se Subject: Re: bridging vs wifi, proxy arp broken on 8.0 rc? (was: Re: Bridged networking for virtualbox on -current?) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 18:32:36 -0000 On Mon, Nov 23, 2009 at 12:16:58AM +0100, Juergen Lock wrote: > In article <4B09992F.1080900@shapeshifter.se> you write: > >Doug Barton wrote: > >> Fredrik Lindberg wrote: > >>> Doug Barton wrote: > >>>> Is bridged networking for vbox supposed to work on -current? It says > >>>> on the wiki that it does, but I tried it tonight and couldn't get it > >>>> to work. > >>>> > >>>> I did see one page that suggested trying one of the Intel virtual > >>>> nicks, which I did, no luck. > >>>> > >>>> If this is not supposed to work it would be nice to update the wiki, I > >>>> spent quite a bit of time trying to get it to work that I hope was not > >>>> wasted. > >>>> > >>> The short answer is that it should work. The long answer is that > >>> it depends, for example it doesn't play nice when trying to > >>> bridge a virtual nic with an if_bridge interface. > >>> > >>> A slightly more verbose description of your environment and what > >>> error messages you're seeing would probably help. > >> > >> Thanks. I'm using an up to date -current, and my outgoing nic is > >> wlan0. I followed the instructions on the wiki. I first tried the > >> default nic in OSE then I tried the first Intel nic on the list (which > >> required downloading drivers of course). > >> > > > >Which type of virtual interface you're using in virtualbox doesn't > >matter. However, it hits me that I've actually never really tested > >the bridging code with a wireless interface and it looks like you've > >hit a bug. I tried to use a wireless interface just now and it > >doesn't work, need to look into why though. > > The problem with bridging and wifi is that on wifi you usually can > use only a single mac address... There are ways around this (using > nat or routing), and I actually played with the latter using qemu tap > networking recently, but couldn't get the most ideal solution working > the way I wanted on 8.0 rc - it only worked on 7-stable. (using a > sub-subnet of the lan interface for the tap interface + guest, and > routing + proxy arp for the guest ip.) I just wanted to try it again > on the 8.0 rc box and now even setting up the prox arp entry fails > with: > arp: writing to routing socket: Invalid argument > Commands I tried: > arp -s pub only > and > arp -s auto pub only > (both before even configuring the tap interface this time...) > > Mind you my 8.0 rc checkout is a little old (Sep 29) so maybe I should > try updating first (I want to test 8-stable anyway one of these days) - > but looking for `arp' in the relevant commitlogs also came up empty. :( > > (I'm Cc'ing -net just in case, please keep me on the Cc cause I'm > not subscribed there...) I meanwhile found a few arp related commits (it helps if you don't forget to ignore case when searching for `arp'... doh! :) - but I now also grabbed stable/8 and head snapshot isos and tested that arp command there, and found its still broken. :( (The same command without the `only' succeeds but can never work for _this_ use case, right?) How I tested (head snapshot livefs in qemu:) % qemu -m 256 -cdrom 9.0-HEAD-20091123-JPSNAP-i386-dvd1.iso -net nic,model=e1000 -net user -curses [In sysinstall select fixit -> cdrom/dvd, then:] Fixit# mkdir /var/db Fixit# dhclient em0 DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 8 DHCPOFFER from 10.0.2.2 DHCPREQUEST on em0 to 255.255.255.255 port 67 DHCPACK from 10.0.2.2 bound to 10.0.2.15 -- renewal in 43200 seconds. Fixit# arp -s 10.0.2.65 auto pub only using interface em0 for proxy with address 52:54:00:12:34:56 arp: writing to routing socket: Invalid argument Fixit# ifconfig em0 em0: flags=8843 metric 0 mtu 1500 options=9b ether 52:54:00:12:34:56 inet6 fe80::5054:ff:fe12:3456%em0 prefixlen 64 scopeid 0x1 inet 10.0.2.15 netmask 0xffffff00 broadcast 10.0.2.255 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active Fixit# And as I said stable/8 and 8.0 rc also suffer from the same bug. (sysinstall doesn't seem to have a way to shutdown instead of reboot by itself but you can just `killall qemu' here when finished; if you want less violent redirect the monitor or omit -curses if you have X and in the monitor do `system_powerdown' to press the virtual acpi powerbutton and then hit return in sysinstall to confirm the `abort installation' prompt that should come up.) Thanx, Juergen PS: (Coming back to the actual tap networking on wifi use case:) Of course you could still use static routes on the other lan boxen that need to talk to the guest, or only use one on one box (like your router/ap) and setup proxy arp on that, but thats not nearly as nice as doing proxy arp on the same box that runs the guest. But of course its too late for 8.0 now... PPS: btw there is another use case besides wifi for doing it this way, i.e. routing + (optionally) proxy arp instead of bridging: when you want to protect your lan from stupid guests causing arp trouble etc... From owner-freebsd-net@FreeBSD.ORG Mon Nov 23 19:52:51 2009 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 CDDB81065679; Mon, 23 Nov 2009 19:52:51 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail4.es.net [IPv6:2001:400:6000:6::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7CF558FC0A; Mon, 23 Nov 2009 19:52:51 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id nANJqnIK011999 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Nov 2009 11:52:50 -0800 Received: from ptavv.es.net (ptavv.es.net [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 1518C1CC0E; Mon, 23 Nov 2009 11:52:49 -0800 (PST) To: John Baldwin In-reply-to: Your message of "Mon, 23 Nov 2009 12:55:25 EST." <200911231255.26279.jhb@freebsd.org> Date: Mon, 23 Nov 2009 11:52:49 -0800 From: "Kevin Oberman" Message-Id: <20091123195249.1518C1CC0E@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2009-11-23_10:2009-11-16, 2009-11-23, 2009-11-23 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-0911230175 Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Hajimu UMEMOTO , Doug Barton Subject: Re: [CFR] unified rc.firewall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 19:52:51 -0000 > From: John Baldwin > Date: Mon, 23 Nov 2009 12:55:25 -0500 > Sender: owner-freebsd-current@freebsd.org > > On Monday 23 November 2009 12:27:23 pm Hajimu UMEMOTO wrote: > > Hi, > > > > >>>>> On Mon, 23 Nov 2009 10:56:14 -0500 > > >>>>> John Baldwin said: > > > > jhb> @@ -178,6 +212,16 @@ > > jhb> # Allow any traffic to or from my own net. > > jhb> ${fwcmd} add pass all from me to ${net} > > jhb> ${fwcmd} add pass all from ${net} to me > > jhb> + if [ -n "$net6" ]; then > > jhb> + ${fwcmd} add pass ip6 from me6 to ${net6} > > jhb> + ${fwcmd} add pass ip6 from ${net6} to me6 > > jhb> + fi > > jhb> + > > jhb> + if [ -n "$net6" ]; then > > jhb> + # Allow any link-local multicast traffic > > jhb> + ${fwcmd} add pass ip6 from fe80::/10 to ff02::/16 > > jhb> + ${fwcmd} add pass ip6 from ${net6} to ff02::/16 > > jhb> + fi > > > > jhb> Any reason to not use 'all' here rather than 'ip6' to match the earlier IPv4 > > jhb> rules? > > > > Thank you for the review. > > The rule is only applicable for IPv6. Rather, I prefer to use 'ip4' > > explicitly over 'all' or 'ip' here. However, changing 'all' to 'ip4' > > makes the diff complex. So, I keep 'all' as is. > > Hmm, however, using 'all' will work, and while in this case the typing is the > same I find it easier to read 'add pass tcp <...>' vs > 'add pass ip <...> proto tcp'. I do think they should be consistent > regardless. > > > jhb> # For services permitted below. > > jhb> ${fwcmd} add pass tcp from me to any established > > jhb> + if [ $ipv6_available -eq 0 ]; then > > jhb> + ${fwcmd} add pass ip6 from any to any proto tcp established > > jhb> + fi > > > > jhb> I think this extra rule here isn't needed at all as the first rule should > > jhb> already match all of those packets. > > > > WORKSTATION type rule is fully dynamic. However, I saw it doesn't > > work for IPv6 as expected. SSH connection stalls after some period. > > I suspect keepalive timer doesn't work well for IPv6. > > So, I changed to use traditional setup/established rule for TCP/IPv6. > > Further, 'me' doesn't match to IPv6 address. FWIW, I have been seeing this since the last update of OpenSSH. I never saw it until then. It's a real pain and I'd love to see it fixed. Right now I'm forced to use IPv4 for the jobs that I tunnel in SSH. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-net@FreeBSD.ORG Tue Nov 24 02:30:06 2009 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 A6860106566B for ; Tue, 24 Nov 2009 02:30:06 +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 96AA38FC1C for ; Tue, 24 Nov 2009 02:30:06 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAO2U6Iv004172 for ; Tue, 24 Nov 2009 02:30:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAO2U6Ak004167; Tue, 24 Nov 2009 02:30:06 GMT (envelope-from gnats) Date: Tue, 24 Nov 2009 02:30:06 GMT Message-Id: <200911240230.nAO2U6Ak004167@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Benjamin Kaduk Cc: Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Benjamin Kaduk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 02:30:06 -0000 The following reply was made to PR kern/140036; it has been noted by GNATS. From: Benjamin Kaduk To: Bernhard Schmidt Cc: bug-followup@freebsd.org Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock Date: Mon, 23 Nov 2009 21:27:15 -0500 (EST) On Mon, 23 Nov 2009, Benjamin Kaduk wrote: > On Sun, 22 Nov 2009, Bernhard Schmidt wrote: >> >> Can you verify that the LOR is gone with the latest checkout of my >> repository? >> Compile instructions: >> http://forums.freebsd.org/showpost.php?p=47627&postcount=16 > > I upgraded to today's current (which picked up a number of probably-unrelated > changes), and then installed the driver from > your tree on top of it. > No LOR on boot, and I'll let you know if I see any lockups. I got a "lockup" (no idea what actually was happening) while in X tonight; nothing useful is in the logs. I'm not even sure if I can blame iwn for it ... I did get a LOR after turning on the hardware wireless switch, though: iwn0: RF switch: radio enabled wlan0: link state changed to UP lock order reversal: 1st 0xffffff800033d018 iwn0_com_lock (iwn0_com_lock) @ /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3280 2nd 0xffffff8000309010 iwn0 (network driver) @ /usr/devel/iwn/freebsd/sys/modules/iwn/../../dev/iwn/if_iwn.c:3289 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _mtx_lock_flags() at _mtx_lock_flags+0x78 iwn_start() at iwn_start+0x35 if_transmit() at if_transmit+0xd6 ieee80211_start() at ieee80211_start+0x3f4 scan_task() at scan_task+0x4c7 taskqueue_run() at taskqueue_run+0x91 taskqueue_thread_loop() at taskqueue_thread_loop+0x3f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffff80001ffd30, rbp = 0 --- I don't think I'll have time to look at it particularly soon, though. -Ben Kaduk From owner-freebsd-net@FreeBSD.ORG Tue Nov 24 09:52:18 2009 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 AE4F41065672 for ; Tue, 24 Nov 2009 09:52:18 +0000 (UTC) (envelope-from proks@skylinetele.com) Received: from Harpy.sky.od.ua (harpy.sky.od.ua [81.25.224.2]) by mx1.freebsd.org (Postfix) with ESMTP id F18A28FC12 for ; Tue, 24 Nov 2009 09:51:50 +0000 (UTC) Received: from logos.sky.od.ua (logos [81.25.224.11]) by Harpy.sky.od.ua (8.12.10/8.12.10) with ESMTP id nAO9oiwi003110; Tue, 24 Nov 2009 11:50:44 +0200 Message-ID: <4B0BAC87.7050703@skylinetele.com> Date: Tue, 24 Nov 2009 11:51:03 +0200 From: "Prokofiev S.P." User-Agent: Thunderbird 2.0.0.21 (X11/20090410) MIME-Version: 1.0 To: Jack Vogel References: <4B0AA2CC.5010205@skylinetele.com> <2a41acea0911230929h53771ed8j2d8f81be286476a0@mail.gmail.com> In-Reply-To: <2a41acea0911230929h53771ed8j2d8f81be286476a0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Hangs down/up Intel NIC during creating vlan. Bug em driver ??? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 09:52:18 -0000 It happen on the 82573 and the 82546 depend on vlandev. To reproduce this input command ifconfig vlan557 create vlandev em1 vlan 557 and you may see Nov 23 11:35:49 ...... kernel: em1: link state changed to DOWN Nov 23 11:35:49 ...... kernel: vlan557: link state changed to DOWN Nov 23 11:35:52 ...... kernel: em1: link state changed to UP Nov 23 11:35:52 ...... kernel: vlan557: link state changed to UP Nov 23 11:36:09 ...... kernel: em1: link state changed to DOWN Nov 23 11:36:13 ...... kernel: em1: link state changed to UP For example: em0: flags=8843 metric 0 mtu 1500 options=9b ether 00:1b:21:06:43:1a media: Ethernet autoselect (1000baseT ) status: active em1: flags=8843 metric 0 mtu 1500 options=9b ether 00:1b:21:06:43:1b media: Ethernet autoselect status: no carrier .... vlan2: flags=8843 metric 0 mtu 1500 options=3 ether 00:1b:21:06:43:1a inet 10.25.224.23 netmask 0xfffffff0 broadcast 10.25.224.31 media: Ethernet autoselect (1000baseT ) status: active vlan: 2 parent interface: em0 input command ifconfig vlan557 create vlandev em0 vlan 557 in /var/log/messages: Nov 24 10:59:37 ....... kernel: em0: link state changed to DOWN Nov 24 10:59:37 ....... kernel: vlan2: link state changed to DOWN Nov 24 10:59:37 ....... kernel: vlan557: link state changed to DOWN Nov 24 10:59:41 ....... kernel: em0: link state changed to UP Nov 24 10:59:41 ....... kernel: vlan2: link state changed to UP Nov 24 10:59:41 ....... kernel: vlan557: link state changed to UP On custom kernel ssh client lost connect and reconnect failure until reboot. This is tcpdump on fail server (10.25.224.23): 11:13:23.559741 IP 10.25.224.21.58222 > 10.25.224.23.22: Flags [S], seq 1981788951, win 65535, options [mss 1460,nop,wscale 8,sackOK,TS val 3107838092 ecr 0], length 0 11:13:23.559771 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,TS val 1953228413 ecr 3107838092], length 0 11:13:26.559555 IP 10.25.224.21.58222 > 10.25.224.23.22: Flags [S], seq 1981788951, win 65535, options [mss 1460,nop,wscale 8,sackOK,TS val 3107841092 ecr 0], length 0 11:13:26.559579 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,TS val 1953228413 ecr 3107841092], length 0 11:13:29.560220 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,TS val 1953228413 ecr 3107841092], length 0 11:13:29.759620 IP 10.25.224.21.58222 > 10.25.224.23.22: Flags [S], seq 1981788951, win 65535, options [mss 1460,nop,wscale 8,sackOK,TS val 3107844292 ecr 0], length 0 11:13:29.759641 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,TS val 1953228413 ecr 3107844292], length 0 11:13:32.760214 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,TS val 1953228413 ecr 3107844292], length 0 11:13:32.959809 IP 10.25.224.21.58222 > 10.25.224.23.22: Flags [S], seq 1981788951, win 65535, options [mss 1460,sackOK,eol], length 0 11:13:32.959829 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,eol], length 0 11:13:35.960214 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,eol], length 0 11:13:36.159874 IP 10.25.224.21.58222 > 10.25.224.23.22: Flags [S], seq 1981788951, win 65535, options [mss 1460,sackOK,eol], length 0 11:13:36.159892 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,eol], length 0 11:13:39.160211 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,eol], length 0 11:13:39.359940 IP 10.25.224.21.58222 > 10.25.224.23.22: Flags [S], seq 1981788951, win 65535, options [mss 1460,sackOK,eol], length 0 11:13:39.359956 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,eol], length 0 11:13:42.360212 IP 10.25.224.23.22 > 10.25.224.21.58222: Flags [S.], seq 2713869415, ack 1981788952, win 65535, options [mss 1460,nop,wscal e 3,sackOK,eol], length 0 But on client I see only requests without reply. On GENERIC kernel reconnect is success. But down/up interface is not right behavior. Jack Vogel wrote: > Custom kernel, well, does it happen on the installed GENERIC kernel, and > what is needed > to reproduce this, just down/up the interface? And are you saying that it > will happen on > either the 82573 or the 82546 or just one of them?? > > Would be nice if this stuff could be discovered earlier :( In any case I > will look into it, there > is another reported problems with em and vlans as well. > > Jack > > > 2009/11/23 Prokofiev S.P. > > >> Hi ALL ! >> I have several servers with FreeBSD 8.0-PRERELEASE on SuperMicro with >> different Intel NICs. When I create new vlan on em interface >> ( ifconfig vlan557 create vlandev em0 vlan 557), >> it hangs down and then up and server becomes inaccessible by ssh, but reply >> on icmp request. >> >> on amd64, custom kernel: >> >> em0@pci0:13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 >> rev=0x03 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Intel Corporation 82573E Gigabit Ethernet Controller >> (Copper) (82573E)' >> class = network >> subclass = ethernet >> em1@pci0:14:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 >> rev=0x00 hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Intel PRO/1000 PL Network Adaptor (82573L)' >> class = network >> subclass = ethernet >> >> on i386, GENERIC kernel: >> >> em0@pci0:2:1:0: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Dual Port Gigabit Ethernet Controller (82546EB)' >> class = network >> subclass = ethernet >> em1@pci0:2:1:1: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = 'Dual Port Gigabit Ethernet Controller (82546EB)' >> class = network >> subclass = ethernet >> >> /var/log/messages: >> >> Nov 23 11:35:49 freebsd kernel: em1: link state changed to DOWN >> Nov 23 11:35:49 freebsd kernel: vlan557: link state changed to DOWN >> Nov 23 11:35:52 freebsd kernel: em1: link state changed to UP >> Nov 23 11:35:52 freebsd kernel: vlan557: link state changed to UP >> Nov 23 11:36:09 freebsd kernel: em1: link state changed to DOWN >> Nov 23 11:36:13 freebsd kernel: em1: link state changed to UP >> _______________________________________________ >> 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" >> >> > _______________________________________________ > 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 Tue Nov 24 15:30:04 2009 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 AE5F3106566C for ; Tue, 24 Nov 2009 15:30:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 82DD88FC08 for ; Tue, 24 Nov 2009 15:30:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAOFU4ab014332 for ; Tue, 24 Nov 2009 15:30:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAOFU4bx014329; Tue, 24 Nov 2009 15:30:04 GMT (envelope-from gnats) Date: Tue, 24 Nov 2009 15:30:04 GMT Message-Id: <200911241530.nAOFU4bx014329@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Max V. Irgiznov" Cc: Subject: Re: kern/118238: [bce] [patch] bce driver shows "no carrier" on Intel SBXD132 blade (based on IBM HS21) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Max V. Irgiznov" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 15:30:04 -0000 The following reply was made to PR kern/118238; it has been noted by GNATS. From: "Max V. Irgiznov" To: , Cc: Subject: Re: kern/118238: [bce] [patch] bce driver shows "no carrier" on Intel SBXD132 blade (based on IBM HS21) Date: Tue, 24 Nov 2009 18:09:43 +0300 This bug still exist in FreeBSD 8.0-RELEASE #0: Tue Nov 24 17:24:49 UTC 2009 root@:/usr/obj/usr/src/sys/GENERIC amd64 From owner-freebsd-net@FreeBSD.ORG Tue Nov 24 15:40:54 2009 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 B8FC8106566B; Tue, 24 Nov 2009 15:40:54 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3807B8FC12; Tue, 24 Nov 2009 15:40:54 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga-m.mahoroba.org [IPv6:2001:2f0:104:801c:21b:d3ff:fe38:5381]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id nAOFeMtk066783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Nov 2009 00:40:24 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Wed, 25 Nov 2009 00:40:16 +0900 Message-ID: From: Hajimu UMEMOTO To: Benjamin Lee In-Reply-To: <4B0AD41F.6020709@b1c1l1.com> References: <200911231056.15247.jhb@freebsd.org> <200911231255.26279.jhb@freebsd.org> <4B0AD41F.6020709@b1c1l1.com> User-Agent: xcite1.58> Wanderlust/2.15.7 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i386-portbld-freebsd8.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.0-RELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Wed, 25 Nov 2009 00:40:24 +0900 (JST) X-Virus-Scanned: clamav-milter 0.95.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, John Baldwin , Doug Barton Subject: Re: [CFR] unified rc.firewall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 15:40:54 -0000 Hi, >>>>> On Mon, 23 Nov 2009 10:27:43 -0800 >>>>> Benjamin Lee said: ben> There is a bug in ipfw send_pkt() that prevents ipfw_tick() from ben> functioning for IPv6. See PR kern/117234. I confirmed that the patch fixed the problem. Thank you for letting me know. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Tue Nov 24 18:01:59 2009 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 2F05B106568F; Tue, 24 Nov 2009 18:01:59 +0000 (UTC) (envelope-from ceache@gmail.com) Received: from mail-ew0-f221.google.com (mail-ew0-f221.google.com [209.85.219.221]) by mx1.freebsd.org (Postfix) with ESMTP id 89F298FC27; Tue, 24 Nov 2009 18:01:57 +0000 (UTC) Received: by ewy21 with SMTP id 21so793790ewy.13 for ; Tue, 24 Nov 2009 10:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=5G7CF/S/fbf1z8Mzf+a5os2apakHH5861W0ajc3176U=; b=Kdr53/YbkiCoQKrttuWmORsdmiH/0g/z8BvSXlHNe3GVAQTUFfDwOYbkwjKiiPCKMu FMY6EG0S2xvXBTyMa9DgWyHsFn5r3pqWFzNz0e50FDgx7kMvruLCBdcaV3eKxZhtLx+u 6HNiChSq85AioN3s5eTU7mw42XdvZC+4Cs4lM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; b=ZPTseO3OvjGdlpGp2DQrCr9KEqzu7jFLPsBsDcbcZhH7ZLLKP4cLX7QPnc2302srzK 5jMC2vEGR/juZbp7BxascIe93nFy08Ucty+KDmopC3ypknGi1qx04pgDCHgIBPyIAKgV OZlsJCOWjgJ0hY4nHDo72OGT9pk+3eIrSYDdI= MIME-Version: 1.0 Received: by 10.213.109.156 with SMTP id j28mr5426224ebp.79.1259084451157; Tue, 24 Nov 2009 09:40:51 -0800 (PST) From: Charles Henri de Boysson Date: Tue, 24 Nov 2009 12:40:31 -0500 Message-ID: <184b04b20911240940g36621d69hf3ca160a6d122ecc@mail.gmail.com> To: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Subject: Performance issue with new pipe profile feature in FreeBSD 8.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: Tue, 24 Nov 2009 18:01:59 -0000 Hi, I have a simple setup with two computer connected via a FreeBSD bridge running 8.0 RELEASE. I am trying to use dummynet to simulate a wireless network between the two and for that I wanted to use the pipe profile feature of FreeBSD 8.0. But as I was experimenting with the pipe profile feature I ran into some is= sues. I have setup ipfw to send traffic coming for either interface of the bridge to a respective pipe as follow: # ipfw show 00100 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 allow ip from any to an= y via lo0 00200 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 deny ip from any to 127= .0.0.0/8 00300 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 deny ip from 127.0.0.0/= 8 to any 01000 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 pipe 1 ip from any to a= ny via vr0 layer2 01100 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 pipe 101 ip from any to= any via vr4 layer2 65000 =C2=A07089 =C2=A0 =C2=A0716987 allow ip from any to any 65535 =C2=A0 =C2=A0 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 deny ip from any to any When I setup my pipes as follow: # ipfw pipe 1 config bw 10Mbit delay 25 mask proto 0 # ipfw pipe 101 config bw 10Mbit delay 25 mask proto 0 # ipfw pipe show 00001: =C2=A010.000 Mbit/s =C2=A0 25 ms =C2=A0 50 sl. 0 queues (1 buckets) = droptail burst: 0 Byte 00101: =C2=A010.000 Mbit/s =C2=A0 25 ms =C2=A0 50 sl. 0 queues (1 buckets) = droptail burst: 0 Byte With this setup, when I try to pass traffic through the bridge with iperf, I obtain the desired speed: iperf reports about 9.7Mbits/sec in UDP mode and 9.5 in TCP mode (I copied and pasted the iperf runs at the end of this email). The problem arise when I setup pipe 1 (the downlink) with an equivalent profile (I tried to simplify it as much as possible). # ipfw pipe 1 config profile test.pipeconf mask proto 0 # ipfw pipe show 00001: 10.000 Mbit/s 0 ms 50 sl. 0 queues (1 buckets) droptail burst: 0 Byte profile: name "test" loss 1.000000 samples 2 00101: 10.000 Mbit/s 25 ms 50 sl. 0 queues (1 buckets) droptail burst: 0 Byte # cat test.pipeconf name test bw 10Mbit loss-level 1.0 samples 2 prob delay 0.0 25 1.0 25 The same iperf TCP tests then collapse to about 500Kbit/s with the same settings (copy and pasted the output of iperf bellow) I can't figure out what is going on. There is no visible load on the bridge= . I have an unmodified GENERIC kernel with the following sysctl. net.link.bridge.ipfw: 1 kern.hz: 1000 The bridge configuration is as follow: bridge0: flags=3D8843 metric 0 mtu = 1500 ether 1a:1f:2e:42:74:8d id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: vr4 flags=3D143 =C2=A0 =C2=A0 =C2=A0 =C2=A0ifmaxaddr 0 port 6 priority 128 path cost 200000 member: vr0 flags=3D143 =C2=A0 =C2=A0 =C2=A0 =C2=A0ifmaxaddr 0 port 2 priority 128 path cost 200000 iperf runs without the profile set: % iperf -B 10.1.0.1 -c 10.0.0.254 -t 15 ------------------------------------------------------------ Client connecting to 10.0.0.254, TCP port 5001 Binding to local address 10.1.0.1 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.1.0.1 port 5001 connected with 10.0.0.254 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-15.0 sec 17.0 MBytes 9.49 Mbits/sec % iperf -B 10.1.0.1 -c 10.0.0.254 -t 15 -u -b 10Mbit ------------------------------------------------------------ Client connecting to 10.0.0.254, UDP port 5001 Binding to local address 10.1.0.1 Sending 1470 byte datagrams UDP buffer size: 110 KByte (default) ------------------------------------------------------------ [ 3] local 10.1.0.1 port 5001 connected with 10.0.0.254 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-15.0 sec 18.8 MBytes 10.5 Mbits/sec [ 3] Sent 13382 datagrams [ 3] Server Report: [ 3] 0.0-15.1 sec 17.4 MBytes 9.72 Mbits/sec 0.822 ms 934/13381 (7%) [ 3] 0.0-15.1 sec 1 datagrams received out-of-order iperf runs with the profile set: % iperf -B 10.1.0.1 -c 10.0.0.254 -t 15 ------------------------------------------------------------ Client connecting to 10.0.0.254, TCP port 5001 Binding to local address 10.1.0.1 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.1.0.1 port 5001 connected with 10.0.0.254 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-15.7 sec 968 KBytes 505 Kbits/sec % iperf -B 10.1.0.1 -c 10.0.0.254 -t 15 -u -b 10Mbit ------------------------------------------------------------ Client connecting to 10.0.0.254, UDP port 5001 Binding to local address 10.1.0.1 Sending 1470 byte datagrams UDP buffer size: 110 KByte (default) ------------------------------------------------------------ [ 3] local 10.1.0.1 port 5001 connected with 10.0.0.254 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-15.0 sec 18.8 MBytes 10.5 Mbits/sec [ 3] Sent 13382 datagrams [ 3] Server Report: [ 3] 0.0-16.3 sec 893 KBytes 449 Kbits/sec 1.810 ms 12757/13379 (9= 5%) Let me know what other information you would need to help me debugging this= . In advance, thank you for your help -- Charles-Henri de Boysson From owner-freebsd-net@FreeBSD.ORG Tue Nov 24 18:56:07 2009 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 622811065694 for ; Tue, 24 Nov 2009 18:56:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 393388FC16 for ; Tue, 24 Nov 2009 18:56:07 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id EA14246B2C for ; Tue, 24 Nov 2009 13:56:06 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 3A11D8A01B for ; Tue, 24 Nov 2009 13:56:06 -0500 (EST) From: John Baldwin To: net@freebsd.org Date: Tue, 24 Nov 2009 13:56:05 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091103; KDE/4.3.1; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200911241356.05528.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 24 Nov 2009 13:56:06 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=4.2 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Subject: [PATCH] Remove if_watchdog and if_timer X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 18:56:07 -0000 Now that no drivers in the tree use if_watchdog and if_timer, this patch just removes them completely. Since if_timer was a short that was adjacent to if_index, removing if_timer would have still left a padding hole in the form of a short on all of our current architectures. After discussing this briefly with Brooks I changed if_index to be an int rather than leaving the padding hole. Comments? --- //depot/vendor/freebsd/src/sys/net/if.c 2009/11/12 19:05:14 +++ //depot/user/jhb/cleanup/sys/net/if.c 2009/11/19 22:35:58 @@ -125,10 +125,8 @@ static void if_freemulti(struct ifmultiaddr *); static void if_init(void *); static void if_grow(void); -static void if_check(void *); static void if_route(struct ifnet *, int flag, int fam); static int if_setflag(struct ifnet *, int, int, int *, int); -static void if_slowtimo(void *); static int if_transmit(struct ifnet *ifp, struct mbuf *m); static void if_unroute(struct ifnet *, int flag, int fam); static void link_rtrequest(int, struct rtentry *, struct rt_addrinfo *); @@ -185,11 +183,6 @@ static if_com_alloc_t *if_com_alloc[256]; static if_com_free_t *if_com_free[256]; -/* - * System initialization - */ -SYSINIT(interface_check, SI_SUB_PROTO_IF, SI_ORDER_FIRST, if_check, NULL); - MALLOC_DEFINE(M_IFNET, "ifnet", "interface internals"); MALLOC_DEFINE(M_IFADDR, "ifaddr", "interface address"); MALLOC_DEFINE(M_IFMADDR, "ether_multi", "link-level multicast address"); @@ -375,18 +368,6 @@ V_ifindex_table = e; } -static void -if_check(void *dummy __unused) -{ - - /* - * If at least one interface added during boot uses - * if_watchdog then start the timer. - */ - if (slowtimo_started) - if_slowtimo(0); -} - /* * Allocate a struct ifnet and an index for an interface. A layer 2 * common structure will also be allocated if an allocation routine is @@ -670,18 +651,6 @@ /* Announce the interface. */ rt_ifannouncemsg(ifp, IFAN_ARRIVAL); - - if (!vmove && ifp->if_watchdog != NULL) { - if_printf(ifp, - "WARNING: using obsoleted if_watchdog interface\n"); - - /* - * Note that we need if_slowtimo(). If this happens after - * boot, then call if_slowtimo() directly. - */ - if (atomic_cmpset_int(&slowtimo_started, 0, 1) && !cold) - if_slowtimo(0); - } } static void @@ -1973,39 +1942,6 @@ } /* - * Handle interface watchdog timer routines. Called - * from softclock, we decrement timers (if set) and - * call the appropriate interface routine on expiration. - * - * XXXRW: Note that because timeouts run with Giant, if_watchdog() is called - * holding Giant. - */ -static void -if_slowtimo(void *arg) -{ - VNET_ITERATOR_DECL(vnet_iter); - struct ifnet *ifp; - int s = splimp(); - - VNET_LIST_RLOCK_NOSLEEP(); - IFNET_RLOCK_NOSLEEP(); - VNET_FOREACH(vnet_iter) { - CURVNET_SET(vnet_iter); - TAILQ_FOREACH(ifp, &V_ifnet, if_link) { - if (ifp->if_timer == 0 || --ifp->if_timer) - continue; - if (ifp->if_watchdog) - (*ifp->if_watchdog)(ifp); - } - CURVNET_RESTORE(); - } - IFNET_RUNLOCK_NOSLEEP(); - VNET_LIST_RUNLOCK_NOSLEEP(); - splx(s); - timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); -} - -/* * Map interface name to interface structure pointer, with or without * returning a reference. */ --- //depot/vendor/freebsd/src/sys/net/if_dead.c 2009/04/23 11:55:13 +++ //depot/user/jhb/cleanup/sys/net/if_dead.c 2009/11/19 22:35:58 @@ -70,12 +70,6 @@ return (ENXIO); } -static void -ifdead_watchdog(struct ifnet *ifp) -{ - -} - static int ifdead_resolvemulti(struct ifnet *ifp, struct sockaddr **llsa, struct sockaddr *sa) @@ -107,7 +101,6 @@ ifp->if_input = ifdead_input; ifp->if_start = ifdead_start; ifp->if_ioctl = ifdead_ioctl; - ifp->if_watchdog = ifdead_watchdog; ifp->if_resolvemulti = ifdead_resolvemulti; ifp->if_qflush = ifdead_qflush; ifp->if_transmit = ifdead_transmit; --- //depot/vendor/freebsd/src/sys/net/if_var.h 2009/11/12 19:05:14 +++ //depot/user/jhb/cleanup/sys/net/if_var.h 2009/11/19 22:35:58 @@ -140,8 +140,7 @@ int if_pcount; /* number of promiscuous listeners */ struct carp_if *if_carp; /* carp interface structure */ struct bpf_if *if_bpf; /* packet filter structure */ - u_short if_index; /* numeric abbreviation for this if */ - short if_timer; /* time 'til if_watchdog called */ + u_int if_index; /* numeric abbreviation for this if */ struct ifvlantrunk *if_vlantrunk; /* pointer to 802.1q data */ int if_flags; /* up/down, broadcast, etc. */ int if_capabilities; /* interface features & capabilities */ @@ -161,8 +160,6 @@ (struct ifnet *); int (*if_ioctl) /* ioctl routine */ (struct ifnet *, u_long, caddr_t); - void (*if_watchdog) /* timer routine */ - (struct ifnet *); void (*if_init) /* Init routine */ (void *); int (*if_resolvemulti) /* validate/resolve multicast */ -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Nov 24 19:40:57 2009 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 8F15D106566C for ; Tue, 24 Nov 2009 19:40:57 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 41F768FC14 for ; Tue, 24 Nov 2009 19:40:56 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 9so1544147qwb.7 for ; Tue, 24 Nov 2009 11:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=c/6v1vYjtmC5awCMMvTNi9uAtPDqNVpbqIQwYDydjmg=; b=TtbCZi8ctiZsZx7VrTfcNwfVP8rLA2BDhnR9E9cUHKPZnW8Yss02jNgV1FaTew6YPu Vgx3ofKs54yECBdMdmvOuf74DiK3V7sm9Cv+1AtlGiHcexaMN3c1j2eAkHKzM1ou6Sp9 EmQnY+UOJotxpIEW8gfHbkNM2jzN/0VUPMUNE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=aI//vh/Cns9cnZoHHLc9QVvhvzH75USt4eG5p9rWPz4yq9WLVhgNErNm5q2Dj6XGqC Gdf3/P/fleFuevfju3YzEfCKcE8VCV2yEwUp2qD8i3oS2YOTSTw5DjqpIN/O3+HeQ+Sv HhmR5cutmrxJqJkApavryNanWT9PnmtrEgFck= Received: by 10.224.105.26 with SMTP id r26mr3430374qao.0.1259091656325; Tue, 24 Nov 2009 11:40:56 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 7sm16081684qwb.2.2009.11.24.11.40.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 11:40:55 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 24 Nov 2009 11:40:25 -0800 From: Pyun YongHyeon Date: Tue, 24 Nov 2009 11:40:25 -0800 To: "Yuriy A. Korobko" Message-ID: <20091124194025.GA1116@michelle.cdnetworks.com> References: <1258998140.3015.34.camel@stormi-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1258998140.3015.34.camel@stormi-desktop> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Reducing number of interrupts from intel pro 1000 et adapter 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, 24 Nov 2009 19:40:57 -0000 On Mon, Nov 23, 2009 at 07:42:20PM +0200, Yuriy A. Korobko wrote: > Hi, > > I'd like to know a way to control tx interrupts on intel pro 1000 et > adapter with igb driver. Just installed one in the router and systat > shows 8-9k rx interrupts and 20k tx interrupts from igb0 and igb1 > adapters. Box is a router running freebsd 7.2 release, I've tried > default driver from kernel source and latest from intel site, effect is > the same with automatic interrupt moderation enabled and disabled. I I'm also aware of this issue. Here is patch I'm currently experimenting. It seems igb(4) wants to dynamically adjust interrupt moderation on Rx traffic such that this seems to cause lots of Tx interrupts under heavy Rx traffic. I simply disabled that feature and fixed Rx handler not to generate more interrupts. Without Rx handler fix the igb(4) took all CPU cycles under heady load(64 bytes UDP torture test) I couldn't even type a character on console. You can get my patch at the following URL. http://people.freebsd.org/~yongari/igb/igb.buf.patch5 The patch also includes other changes I made so it's somewhat big. Note, please don't apply the patch on production servers it needs more testing. > have the same box with intel pro 1000 pt adapter which have > tx(rx)_int_delay sysctls in em driver, I was able to reduce number of > tx/rx interrupts to 7-8k per interface and got much more cpu idle > because of less context switches with same pps. > I guess you sacrificed latencies. From owner-freebsd-net@FreeBSD.ORG Tue Nov 24 19:59:23 2009 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 08E9C106566C for ; Tue, 24 Nov 2009 19:59:23 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 88F8F8FC15 for ; Tue, 24 Nov 2009 19:59:22 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 22so1742208eye.9 for ; Tue, 24 Nov 2009 11:59:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=luGrQp/T1G6oE3jMaWPZ6K22OLRU3JDlHRJ3H7z3R1Y=; b=qzt0lTuL7EJl3s/C+oW6wj1myRjpshO3fIdqy+Yvj4/be3o9ye3AQeUQcnQ8dFCb8V myzJvN+oFn9KY+3RVH/dAsoBbsbbyXGJ0DueEDY2REItjK1iyvfnrLvfYN3qTPux9jO8 aKs8QRShuuV0hBOz6bt+L1jPFGKcSNT77S+Nw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MhgwQiCCAiiFUGSJg85LQtr78gZ2VOro/8Gz77oHrpsJAruFB0+EKiOy0EdGSUMXgK QqpiwOJz1X5T51ny9pSLrusuLvksG5gqnnZdQk4NOQPtngBU5Tf+6R4QecvK9DzedDKl AlSyxINVEhEEb7ps3YwBGA+j/9N+Sjz1fm7Po= MIME-Version: 1.0 Received: by 10.216.87.3 with SMTP id x3mr2181420wee.132.1259092761126; Tue, 24 Nov 2009 11:59:21 -0800 (PST) In-Reply-To: <20091124194025.GA1116@michelle.cdnetworks.com> References: <1258998140.3015.34.camel@stormi-desktop> <20091124194025.GA1116@michelle.cdnetworks.com> Date: Tue, 24 Nov 2009 11:59:21 -0800 Message-ID: <2a41acea0911241159u3b2dab36p66f29724f8cac13@mail.gmail.com> From: Jack Vogel To: pyunyh@gmail.com Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "Yuriy A. Korobko" , freebsd-net@freebsd.org Subject: Re: Reducing number of interrupts from intel pro 1000 et adapter X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 19:59:23 -0000 There are significant changes to igb forthcoming, I believe I have fixed the multiqueue problems that exist in it now, and I am working to improve the AIM code so it handles TX and RX (this is still experimental right now though). I hope it addresses your problems. Jack On Tue, Nov 24, 2009 at 11:40 AM, Pyun YongHyeon wrote: > On Mon, Nov 23, 2009 at 07:42:20PM +0200, Yuriy A. Korobko wrote: > > Hi, > > > > I'd like to know a way to control tx interrupts on intel pro 1000 et > > adapter with igb driver. Just installed one in the router and systat > > shows 8-9k rx interrupts and 20k tx interrupts from igb0 and igb1 > > adapters. Box is a router running freebsd 7.2 release, I've tried > > default driver from kernel source and latest from intel site, effect is > > the same with automatic interrupt moderation enabled and disabled. I > > I'm also aware of this issue. Here is patch I'm currently > experimenting. It seems igb(4) wants to dynamically adjust > interrupt moderation on Rx traffic such that this seems to cause > lots of Tx interrupts under heavy Rx traffic. I simply disabled > that feature and fixed Rx handler not to generate more interrupts. > Without Rx handler fix the igb(4) took all CPU cycles under heady > load(64 bytes UDP torture test) I couldn't even type a character > on console. You can get my patch at the following URL. > http://people.freebsd.org/~yongari/igb/igb.buf.patch5 > > The patch also includes other changes I made so it's somewhat big. > Note, please don't apply the patch on production servers it needs > more testing. > > > have the same box with intel pro 1000 pt adapter which have > > tx(rx)_int_delay sysctls in em driver, I was able to reduce number of > > tx/rx interrupts to 7-8k per interface and got much more cpu idle > > because of less context switches with same pps. > > > > I guess you sacrificed latencies. > _______________________________________________ > 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 Tue Nov 24 23:07:21 2009 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 66A591065670; Tue, 24 Nov 2009 23:07:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 400018FC12; Tue, 24 Nov 2009 23:07:21 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id F2BEA46B2A; Tue, 24 Nov 2009 18:07:20 -0500 (EST) Date: Tue, 24 Nov 2009 23:07:20 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <200911241356.05528.jhb@freebsd.org> Message-ID: References: <200911241356.05528.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@freebsd.org Subject: Re: [PATCH] Remove if_watchdog and if_timer X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Nov 2009 23:07:21 -0000 On Tue, 24 Nov 2009, John Baldwin wrote: > Now that no drivers in the tree use if_watchdog and if_timer, this patch > just removes them completely. Since if_timer was a short that was adjacent > to if_index, removing if_timer would have still left a padding hole in the > form of a short on all of our current architectures. After discussing this > briefly with Brooks I changed if_index to be an int rather than leaving the > padding hole. Comments? The if_watchdog/if_timer changes sound good to me, but let's do the if_index change separately, and just add padding in this change. The if_index -> 32-bit chnge is one that's been overdue for a long time, but it's going to have a lot of side effects, so keeping it to its own changesets (which can be backed out if needed more easily) is probably a good idea. Thanks for taking on the watchdog changes! Robert N M Watson Computer Laboratory University of Cambridge > > --- //depot/vendor/freebsd/src/sys/net/if.c 2009/11/12 19:05:14 > +++ //depot/user/jhb/cleanup/sys/net/if.c 2009/11/19 22:35:58 > @@ -125,10 +125,8 @@ > static void if_freemulti(struct ifmultiaddr *); > static void if_init(void *); > static void if_grow(void); > -static void if_check(void *); > static void if_route(struct ifnet *, int flag, int fam); > static int if_setflag(struct ifnet *, int, int, int *, int); > -static void if_slowtimo(void *); > static int if_transmit(struct ifnet *ifp, struct mbuf *m); > static void if_unroute(struct ifnet *, int flag, int fam); > static void link_rtrequest(int, struct rtentry *, struct rt_addrinfo *); > @@ -185,11 +183,6 @@ > static if_com_alloc_t *if_com_alloc[256]; > static if_com_free_t *if_com_free[256]; > > -/* > - * System initialization > - */ > -SYSINIT(interface_check, SI_SUB_PROTO_IF, SI_ORDER_FIRST, if_check, NULL); > - > MALLOC_DEFINE(M_IFNET, "ifnet", "interface internals"); > MALLOC_DEFINE(M_IFADDR, "ifaddr", "interface address"); > MALLOC_DEFINE(M_IFMADDR, "ether_multi", "link-level multicast address"); > @@ -375,18 +368,6 @@ > V_ifindex_table = e; > } > > -static void > -if_check(void *dummy __unused) > -{ > - > - /* > - * If at least one interface added during boot uses > - * if_watchdog then start the timer. > - */ > - if (slowtimo_started) > - if_slowtimo(0); > -} > - > /* > * Allocate a struct ifnet and an index for an interface. A layer 2 > * common structure will also be allocated if an allocation routine is > @@ -670,18 +651,6 @@ > > /* Announce the interface. */ > rt_ifannouncemsg(ifp, IFAN_ARRIVAL); > - > - if (!vmove && ifp->if_watchdog != NULL) { > - if_printf(ifp, > - "WARNING: using obsoleted if_watchdog interface\n"); > - > - /* > - * Note that we need if_slowtimo(). If this happens after > - * boot, then call if_slowtimo() directly. > - */ > - if (atomic_cmpset_int(&slowtimo_started, 0, 1) && !cold) > - if_slowtimo(0); > - } > } > > static void > @@ -1973,39 +1942,6 @@ > } > > /* > - * Handle interface watchdog timer routines. Called > - * from softclock, we decrement timers (if set) and > - * call the appropriate interface routine on expiration. > - * > - * XXXRW: Note that because timeouts run with Giant, if_watchdog() is called > - * holding Giant. > - */ > -static void > -if_slowtimo(void *arg) > -{ > - VNET_ITERATOR_DECL(vnet_iter); > - struct ifnet *ifp; > - int s = splimp(); > - > - VNET_LIST_RLOCK_NOSLEEP(); > - IFNET_RLOCK_NOSLEEP(); > - VNET_FOREACH(vnet_iter) { > - CURVNET_SET(vnet_iter); > - TAILQ_FOREACH(ifp, &V_ifnet, if_link) { > - if (ifp->if_timer == 0 || --ifp->if_timer) > - continue; > - if (ifp->if_watchdog) > - (*ifp->if_watchdog)(ifp); > - } > - CURVNET_RESTORE(); > - } > - IFNET_RUNLOCK_NOSLEEP(); > - VNET_LIST_RUNLOCK_NOSLEEP(); > - splx(s); > - timeout(if_slowtimo, (void *)0, hz / IFNET_SLOWHZ); > -} > - > -/* > * Map interface name to interface structure pointer, with or without > * returning a reference. > */ > --- //depot/vendor/freebsd/src/sys/net/if_dead.c 2009/04/23 11:55:13 > +++ //depot/user/jhb/cleanup/sys/net/if_dead.c 2009/11/19 22:35:58 > @@ -70,12 +70,6 @@ > return (ENXIO); > } > > -static void > -ifdead_watchdog(struct ifnet *ifp) > -{ > - > -} > - > static int > ifdead_resolvemulti(struct ifnet *ifp, struct sockaddr **llsa, > struct sockaddr *sa) > @@ -107,7 +101,6 @@ > ifp->if_input = ifdead_input; > ifp->if_start = ifdead_start; > ifp->if_ioctl = ifdead_ioctl; > - ifp->if_watchdog = ifdead_watchdog; > ifp->if_resolvemulti = ifdead_resolvemulti; > ifp->if_qflush = ifdead_qflush; > ifp->if_transmit = ifdead_transmit; > --- //depot/vendor/freebsd/src/sys/net/if_var.h 2009/11/12 19:05:14 > +++ //depot/user/jhb/cleanup/sys/net/if_var.h 2009/11/19 22:35:58 > @@ -140,8 +140,7 @@ > int if_pcount; /* number of promiscuous listeners */ > struct carp_if *if_carp; /* carp interface structure */ > struct bpf_if *if_bpf; /* packet filter structure */ > - u_short if_index; /* numeric abbreviation for this if */ > - short if_timer; /* time 'til if_watchdog called */ > + u_int if_index; /* numeric abbreviation for this if */ > struct ifvlantrunk *if_vlantrunk; /* pointer to 802.1q data */ > int if_flags; /* up/down, broadcast, etc. */ > int if_capabilities; /* interface features & capabilities */ > @@ -161,8 +160,6 @@ > (struct ifnet *); > int (*if_ioctl) /* ioctl routine */ > (struct ifnet *, u_long, caddr_t); > - void (*if_watchdog) /* timer routine */ > - (struct ifnet *); > void (*if_init) /* Init routine */ > (void *); > int (*if_resolvemulti) /* validate/resolve multicast */ > > -- > John Baldwin > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Nov 25 00:06:27 2009 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 5F105106568D; Wed, 25 Nov 2009 00:06:27 +0000 (UTC) (envelope-from will@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 360218FC13; Wed, 25 Nov 2009 00:06:27 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAP06Qd9069692; Wed, 25 Nov 2009 00:06:26 GMT (envelope-from will@freefall.freebsd.org) Received: (from will@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAP06QkS069688; Wed, 25 Nov 2009 00:06:26 GMT (envelope-from will) Date: Wed, 25 Nov 2009 00:06:26 GMT Message-Id: <200911250006.nAP06QkS069688@freefall.freebsd.org> To: krassi@bulinfo.net, will@FreeBSD.org, freebsd-net@FreeBSD.org From: will@FreeBSD.org Cc: Subject: Re: bin/118987: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 00:06:27 -0000 Synopsis: ifconfig(8): ifconfig -l (address_family) does not work correctly on RELENG-7 State-Changed-From-To: analyzed->closed State-Changed-By: will State-Changed-When: Wed Nov 25 00:05:19 UTC 2009 State-Changed-Why: Fixed in r199770 (HEAD). http://www.freebsd.org/cgi/query-pr.cgi?pr=118987 From owner-freebsd-net@FreeBSD.ORG Wed Nov 25 00:10:02 2009 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 BFCEC1065679 for ; Wed, 25 Nov 2009 00:10:02 +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 9590C8FC13 for ; Wed, 25 Nov 2009 00:10:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nAP0A2sS069783 for ; Wed, 25 Nov 2009 00:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nAP0A2C2069782; Wed, 25 Nov 2009 00:10:02 GMT (envelope-from gnats) Date: Wed, 25 Nov 2009 00:10:02 GMT Message-Id: <200911250010.nAP0A2C2069782@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: bin/118987: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 00:10:02 -0000 The following reply was made to PR bin/118987; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: bin/118987: commit references a PR Date: Wed, 25 Nov 2009 00:01:12 +0000 (UTC) Author: will Date: Wed Nov 25 00:00:57 2009 New Revision: 199770 URL: http://svn.freebsd.org/changeset/base/199770 Log: Make ``ifconfig -l ether'' only list interfaces that speak Ethernet. PR: 118987 Approved by: ken (mentor) Modified: head/sbin/ifconfig/ifconfig.c Modified: head/sbin/ifconfig/ifconfig.c ============================================================================== --- head/sbin/ifconfig/ifconfig.c Tue Nov 24 22:37:04 2009 (r199769) +++ head/sbin/ifconfig/ifconfig.c Wed Nov 25 00:00:57 2009 (r199770) @@ -147,7 +147,7 @@ main(int argc, char *argv[]) struct ifaddrs *ifap, *ifa; struct ifreq paifr; const struct sockaddr_dl *sdl; - char options[1024], *cp; + char options[1024], *cp, *namecp = NULL; const char *ifname; struct option *p; size_t iflen; @@ -294,7 +294,7 @@ main(int argc, char *argv[]) sdl = (const struct sockaddr_dl *) ifa->ifa_addr; else sdl = NULL; - if (cp != NULL && strcmp(cp, ifa->ifa_name) == 0) + if (cp != NULL && strcmp(cp, ifa->ifa_name) == 0 && !namesonly) continue; iflen = strlcpy(name, ifa->ifa_name, sizeof(name)); if (iflen >= sizeof(name)) { @@ -308,16 +308,32 @@ main(int argc, char *argv[]) continue; if (uponly && (ifa->ifa_flags & IFF_UP) == 0) continue; - ifindex++; /* * Are we just listing the interfaces? */ if (namesonly) { + if (namecp == cp) + continue; + if (afp != NULL) { + /* special case for "ether" address family */ + if (!strcmp(afp->af_name, "ether")) { + if (sdl == NULL || + sdl->sdl_type != IFT_ETHER || + sdl->sdl_alen != ETHER_ADDR_LEN) + continue; + } else { + if (ifa->ifa_addr->sa_family != afp->af_af) + continue; + } + } + namecp = cp; + ifindex++; if (ifindex > 1) printf(" "); fputs(name, stdout); continue; } + ifindex++; if (argc > 0) ifconfig(argc, argv, 0, afp); _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Nov 25 00:58:50 2009 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 EB1FE1065692 for ; Wed, 25 Nov 2009 00:58:50 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 97F828FC22 for ; Wed, 25 Nov 2009 00:58:50 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 0A42448AF4; Wed, 25 Nov 2009 00:58:49 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIiBHvNNRbmT; Wed, 25 Nov 2009 00:58:46 +0000 (GMT) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 047C048AF1; Wed, 25 Nov 2009 00:58:44 +0000 (GMT) Message-ID: <4B0C80FB.5040901@tomjudge.com> Date: Wed, 25 Nov 2009 00:57:31 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: David Christensen References: <4AE72910.8090708@tomjudge.com> <4AE76FF1.9010401@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA1183.7050306@tomjudge.com> <4AEB2571.7090006@tomjudge.com> <4AFAE428.5090907@quip.cz> <5D267A3F22FD854F8F48B3D2B52381933A20D4C55D@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFAF542.8050004@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A20D4CA70@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFC862B.6060805@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A20E0EFE1@IRVEXCHCCR01.corp.ad.broadcom.com> <5D267A3F22FD854F8F48B3D2B52381933A20E0F332@IRVEXCHCCR01.corp.ad.broadcom.com> In-Reply-To: <5D267A3F22FD854F8F48B3D2B52381933A20E0F332@IRVEXCHCCR01.corp.ad.broadcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gideon Naim , "rwilliams@borderware.com" , Miroslav Lachman <000.fbsd@quip.cz>, "net@freebsd.org" Subject: Re: bce(4) BCM5907 CTX write errors on 7.2 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: Wed, 25 Nov 2009 00:58:51 -0000 David Christensen wrote: >>> For the record we also have not been able to reproduce the issue on >>> the R710 only the R610. >> I got hold of an R610 system and I now understand why the >> issue was difficult to replicate on R710. The R610 ships >> without Enterprise iDRAC while the R710 ship with the add-in >> Enterprise iDRAC module. When the module is present the >> system is managed through the additional RJ45 port but when >> the module is absent iDRAC traffic will flow through the >> on-board 5709 adpaters. >> The error will only occur when management firmware is loaded >> on the 5709 AND when NC-SI management functionality is enabled. >> >> You should be able to confirm this by adding or removing the >> Enterprise iDRAC module on your systems. Now that I have a >> failure again I have some ideas to test which might help. >> Stay tuned. > > Does the attached patch make a difference for you? > > FYI, I'll be out next week on vacation. > Hi David, This patch seems to do the trick, on at least one of the R610's that we have. Just did cold boot, 5 warm boots, cold boot, 5 warm boots and have not had any issues. Thanks Tom From owner-freebsd-net@FreeBSD.ORG Wed Nov 25 05:20:35 2009 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 9188010656B3; Wed, 25 Nov 2009 05:20:35 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 0C4D78FC0C; Wed, 25 Nov 2009 05:20:34 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 0A872730DA; Wed, 25 Nov 2009 06:28:33 +0100 (CET) Date: Wed, 25 Nov 2009 06:28:33 +0100 From: Luigi Rizzo To: Charles Henri de Boysson Message-ID: <20091125052833.GA6726@onelab2.iet.unipi.it> References: <184b04b20911240940g36621d69hf3ca160a6d122ecc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <184b04b20911240940g36621d69hf3ca160a6d122ecc@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: Performance issue with new pipe profile feature in FreeBSD 8.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: Wed, 25 Nov 2009 05:20:35 -0000 Hi, there is no bug, the 'pipe profile' code is working correctly. In your mail below you are comparing two different things. "pipe config bw 10Mbit/s delay 25ms" means that _after shaping_ at 10Mbps, all traffic will be subject to an additional delay of 25ms. Each packet (1470 bytes) will take Length/Bandwidth sec to come out or 1470*8/10M = 1.176ms , but you won't see them until you wait another 25ms (7500km at the speed of light). "pipe config bw 10Mbit/s profile "test" ..." means that in addition to the Length/Bandwidth, _each packet transmission_ will consume some additional air-time as specified in the profile (25ms in your case) So, in your case with 1470bytes/pkt each transmission will take len/bw (1.176ms) + 25ms (extra air time) = 26.76ms That is 25 times more than the previous case and explains the reduced bandwidth you see. The 'delay profile' is effectively extra air time used for each transmission. The name is probably confusing, i should have called it 'extra-time' or 'overhead' and not 'delay' cheers luigi On Tue, Nov 24, 2009 at 12:40:31PM -0500, Charles Henri de Boysson wrote: > Hi, > > I have a simple setup with two computer connected via a FreeBSD bridge > running 8.0 RELEASE. > I am trying to use dummynet to simulate a wireless network between the > two and for that I wanted to use the pipe profile feature of FreeBSD > 8.0. > But as I was experimenting with the pipe profile feature I ran into some issues. > > I have setup ipfw to send traffic coming for either interface of the > bridge to a respective pipe as follow: > > # ipfw show > 00100 ?? ?? 0 ?? ?? ?? ?? 0 allow ip from any to any via lo0 > 00200 ?? ?? 0 ?? ?? ?? ?? 0 deny ip from any to 127.0.0.0/8 > 00300 ?? ?? 0 ?? ?? ?? ?? 0 deny ip from 127.0.0.0/8 to any > 01000 ?? ?? 0 ?? ?? ?? ?? 0 pipe 1 ip from any to any via vr0 layer2 > 01100 ?? ?? 0 ?? ?? ?? ?? 0 pipe 101 ip from any to any via vr4 layer2 > 65000 ??7089 ?? ??716987 allow ip from any to any > 65535 ?? ?? 0 ?? ?? ?? ?? 0 deny ip from any to any > > When I setup my pipes as follow: > > # ipfw pipe 1 config bw 10Mbit delay 25 mask proto 0 > # ipfw pipe 101 config bw 10Mbit delay 25 mask proto 0 > # ipfw pipe show > > 00001: ??10.000 Mbit/s ?? 25 ms ?? 50 sl. 0 queues (1 buckets) droptail > burst: 0 Byte > 00101: ??10.000 Mbit/s ?? 25 ms ?? 50 sl. 0 queues (1 buckets) droptail > burst: 0 Byte > > With this setup, when I try to pass traffic through the bridge with > iperf, I obtain the desired speed: iperf reports about 9.7Mbits/sec in > UDP mode and 9.5 in TCP mode (I copied and pasted the iperf runs at > the end of this email). > > The problem arise when I setup pipe 1 (the downlink) with an > equivalent profile (I tried to simplify it as much as possible). > > # ipfw pipe 1 config profile test.pipeconf mask proto 0 > # ipfw pipe show > 00001: 10.000 Mbit/s 0 ms 50 sl. 0 queues (1 buckets) droptail > burst: 0 Byte > profile: name "test" loss 1.000000 samples 2 > 00101: 10.000 Mbit/s 25 ms 50 sl. 0 queues (1 buckets) droptail > burst: 0 Byte > > # cat test.pipeconf > name test > bw 10Mbit > loss-level 1.0 > samples 2 > prob delay > 0.0 25 > 1.0 25 > > The same iperf TCP tests then collapse to about 500Kbit/s with the > same settings (copy and pasted the output of iperf bellow) > > I can't figure out what is going on. There is no visible load on the bridge. > I have an unmodified GENERIC kernel with the following sysctl. > > net.link.bridge.ipfw: 1 > kern.hz: 1000 > > The bridge configuration is as follow: > > bridge0: flags=8843 metric 0 mtu 1500 > ether 1a:1f:2e:42:74:8d > id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 > maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 > root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 > member: vr4 flags=143 > ?? ?? ?? ??ifmaxaddr 0 port 6 priority 128 path cost 200000 > member: vr0 flags=143 > ?? ?? ?? ??ifmaxaddr 0 port 2 priority 128 path cost 200000 > > > iperf runs without the profile set: > % iperf -B 10.1.0.1 -c 10.0.0.254 -t 15 > ------------------------------------------------------------ > Client connecting to 10.0.0.254, TCP port 5001 > Binding to local address 10.1.0.1 > TCP window size: 16.0 KByte (default) > ------------------------------------------------------------ > [ 3] local 10.1.0.1 port 5001 connected with 10.0.0.254 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-15.0 sec 17.0 MBytes 9.49 Mbits/sec > > % iperf -B 10.1.0.1 -c 10.0.0.254 -t 15 -u -b 10Mbit > ------------------------------------------------------------ > Client connecting to 10.0.0.254, UDP port 5001 > Binding to local address 10.1.0.1 > Sending 1470 byte datagrams > UDP buffer size: 110 KByte (default) > ------------------------------------------------------------ > [ 3] local 10.1.0.1 port 5001 connected with 10.0.0.254 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-15.0 sec 18.8 MBytes 10.5 Mbits/sec > [ 3] Sent 13382 datagrams > [ 3] Server Report: > [ 3] 0.0-15.1 sec 17.4 MBytes 9.72 Mbits/sec 0.822 ms 934/13381 (7%) > [ 3] 0.0-15.1 sec 1 datagrams received out-of-order > > > iperf runs with the profile set: > % iperf -B 10.1.0.1 -c 10.0.0.254 -t 15 > ------------------------------------------------------------ > Client connecting to 10.0.0.254, TCP port 5001 > Binding to local address 10.1.0.1 > TCP window size: 16.0 KByte (default) > ------------------------------------------------------------ > [ 3] local 10.1.0.1 port 5001 connected with 10.0.0.254 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-15.7 sec 968 KBytes 505 Kbits/sec > > % iperf -B 10.1.0.1 -c 10.0.0.254 -t 15 -u -b 10Mbit > ------------------------------------------------------------ > Client connecting to 10.0.0.254, UDP port 5001 > Binding to local address 10.1.0.1 > Sending 1470 byte datagrams > UDP buffer size: 110 KByte (default) > ------------------------------------------------------------ > [ 3] local 10.1.0.1 port 5001 connected with 10.0.0.254 port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-15.0 sec 18.8 MBytes 10.5 Mbits/sec > [ 3] Sent 13382 datagrams > [ 3] Server Report: > [ 3] 0.0-16.3 sec 893 KBytes 449 Kbits/sec 1.810 ms 12757/13379 (95%) > > > Let me know what other information you would need to help me debugging this. > In advance, thank you for your help > > -- > Charles-Henri de Boysson > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Nov 25 10:09:53 2009 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 8B182106566B for ; Wed, 25 Nov 2009 10:09:53 +0000 (UTC) (envelope-from beezarliu@yahoo.com.cn) Received: from n14.bullet.mail.mud.yahoo.com (n14.bullet.mail.mud.yahoo.com [68.142.206.41]) by mx1.freebsd.org (Postfix) with SMTP id 4DDEC8FC1D for ; Wed, 25 Nov 2009 10:09:53 +0000 (UTC) Received: from [209.191.108.97] by n14.bullet.mail.mud.yahoo.com with NNFMP; 25 Nov 2009 09:57:22 -0000 Received: from [68.142.201.72] by t4.bullet.mud.yahoo.com with NNFMP; 25 Nov 2009 09:57:22 -0000 Received: from [127.0.0.1] by omp424.mail.mud.yahoo.com with NNFMP; 25 Nov 2009 09:57:22 -0000 X-Yahoo-Newman-Id: 301322.96483.bm@omp424.mail.mud.yahoo.com Received: (qmail 6091 invoked from network); 25 Nov 2009 09:57:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.cn; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Date:From:To:Subject:Message-ID:X-mailer:Mime-Version:Content-Type; b=6EDuxlFj/rBs/TQc2ij6RRwUweAbKQEUyHAjTWEJk6DYbEsnxBQbsEjzaC1fbWj66x1rWKhVKoWbMJGu1JJAn93TJWl1eaE+ysiZ+enqZDLuxhG2NlovYLMfnZ5P38g7kDRsFklu0FUkSSTSIp6+pWOMnazAT6L7z894ynAXoWY= ; Received: from (beezarliu@124.42.99.101 with login) by smtp123.plus.mail.sp1.yahoo.com with SMTP; 25 Nov 2009 01:57:21 -0800 PST X-Yahoo-SMTP: YP5UPy2swBBHZGZlvbmOrntlD3fotw-- X-YMail-OSG: FJZwPzQVM1l4J1tqInNmFBLIAsTPqyTBi2H81WK9.d6bu1YLdTta1ksjFYND3LIUvM0foz67tyxzp9g_s_2LfEBhXM2AqrjnOn5Vyr6GsjHq6SKOlroma.jDnhms1JXxxUFlr.7NzlwqELK37dPjrRRnWMlHuJRGBlHB0waSdxZZQVPMaUr9q0_Z_j2sD0icN9Oj.37.gV47K91V2nf41VozghPeqljEi09WS1Fo9QmLYibvmiEnjyRhelWdmAdi X-Yahoo-Newman-Property: ymail-3 Date: Wed, 25 Nov 2009 17:56:50 +0800 From: "beezarliu" To: "freebsd-net" Message-ID: <200911251756446718122@yahoo.com.cn> X-mailer: Foxmail 6, 10, 201, 20 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: possible memory leak in em_dma_free? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 10:09:54 -0000 Hi all, I saw em driver, and found a possible memory leak. dma->dma_map may be NULL, so the dma memory will not be freed. I think the condition will it be beter if it is "(dma->dma_vaddr != NULL) {" Thanks static void em_dma_free(struct adapter *adapter, struct em_dma_alloc *dma) { if (dma->dma_tag == NULL) return; if (dma->dma_map != NULL) { --> if (dma->dma_vaddr != NULL) { bus_dmamap_sync(dma->dma_tag, dma->dma_map, BUS_DMASYNC_POSTREAD | BUS_DMASYNC_POSTWRITE); bus_dmamap_unload(dma->dma_tag, dma->dma_map); bus_dmamem_free(dma->dma_tag, dma->dma_vaddr, dma->dma_map); dma->dma_map = NULL; } bus_dma_tag_destroy(dma->dma_tag); dma->dma_tag = NULL; } 2009-11-25 beezarliu From owner-freebsd-net@FreeBSD.ORG Wed Nov 25 12:15:04 2009 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 73F1B10656CF for ; Wed, 25 Nov 2009 12:15:04 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp1.dlr.de (smtp1.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id 0B2BD8FC1B for ; Wed, 25 Nov 2009 12:15:03 +0000 (UTC) Received: from exbe5.intra.dlr.de ([172.21.106.15]) by smtp1.dlr.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 13:15:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Nov 2009 13:15:01 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need help on IPv6 prefixes and interface addresses Thread-Index: AcptyOnR5h88lhyVTBSa5Vs3v+DjGA== From: To: X-OriginalArrivalTime: 25 Nov 2009 12:15:01.0816 (UTC) FILETIME=[E9E05380:01CA6DC8] Subject: Need help on IPv6 prefixes and interface addresses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 12:15:04 -0000 Hi all, I try to make bsnmpd IPv6 aware and need some help here. I've set up a = small IPv6 network for testing between a couple of VMs. For IPv6 interface addresses there are two tables: ipAddressPrefix table = and ipAddressTable (containing pointers to the prefix table). Now I see = something on my system I cannot grasp. ndp -pn gives me: 2001:638:101:ff::/64 if=3Dle0 flags=3DLO vltime=3Dinfinity, pltime=3Dinfinity, expire=3DNever, ref=3D1 No advertising router fe80::%le0/64 if=3Dle0 flags=3DLAO vltime=3Dinfinity, pltime=3Dinfinity, expire=3DNever, = ref=3D0 No advertising router fe80::%lo0/64 if=3Dlo0 flags=3DLAO vltime=3Dinfinity, pltime=3Dinfinity, expire=3DNever, = ref=3D0 No advertising router ifconfig -a inet6 gives: le0: flags=3D8843 metric 0 mtu = 1500 options=3D8 inet6 fe80::20c:29ff:fe90:dd1b%le0 prefixlen 64 scopeid 0x1=20 inet6 2001:638:101:ff::8:ffff prefixlen 64=20 lo0: flags=3D8049 metric 0 mtu 16384 options=3D3 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 So far, so nice. When I ask for the interface addresses via sysctl([0, NET_RT_IFLIST, 0], = ...) I get strange RTM_NEWADDR messages: msglen=3D76 version=3D5 type=3DRTM_NEWADDR flags=3D0 index=3D1 metric=3D0 netmask=3DINET6,28,{0,0,ffff:ffff:ffff:ffff::,0} ifa=3DINET6,28,{0,0,fe80:1::20c:29ff:fe90:dd1b,0} Which means a prefix of fe80:1::/64 instead of fe80::%le0/64. Note, the = :1: there and note the zero missing scope_id (the last 0 inside the {}). Same for lo0: msglen=3D80 version=3D5 type=3DRTM_NEWADDR flags=3D0 index=3D2 metric=3D0 netmask=3DINET6,28,{0,0,ffff:ffff:ffff:ffff::,0} ifa=3DINET6,28,{0,0,fe80:2::1,0} brd=3DUNSPEC,0,{} So my questions: - are the routing message really that inconsistent and broken? Or do I = read them somehow incorrect? - is it possible to rely on the prefix table? In other words: Does = *each* prefix used in a INET6 interface address appear in the prefix list? harti From owner-freebsd-net@FreeBSD.ORG Wed Nov 25 15:10:50 2009 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 B33A8106568F for ; Wed, 25 Nov 2009 15:10:50 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp2.dlr.de (smtp1.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id 46D988FC1E for ; Wed, 25 Nov 2009 15:10:49 +0000 (UTC) Received: from exbe5.intra.dlr.de ([172.21.106.15]) by smtp2.dlr.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 16:10:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Nov 2009 16:07:45 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Need help on IPv6 prefixes and interface addresses Thread-Index: AcptyOnR5h88lhyVTBSa5Vs3v+DjGAAGCEtq References: From: To: , X-OriginalArrivalTime: 25 Nov 2009 15:10:48.0593 (UTC) FILETIME=[783EC810:01CA6DE1] Cc: Subject: RE: Need help on IPv6 prefixes and interface addresses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 15:10:50 -0000 To answer my own question :-) These strange link local addresses are = explained in the developers handbook section 8.1.1.3 and are called = embedded link local addresses. These are not standard IPv6 addresses, but a way = to encode the interface index (aka zone index) into the IPv6 address. = This must be undone by the user program before using these addresses. harti=20 -----Original Message----- From: owner-freebsd-net@freebsd.org on behalf of Hartmut.Brandt@dlr.de Sent: Wed 11/25/2009 1:15 PM To: freebsd-net@freebsd.org Subject: Need help on IPv6 prefixes and interface addresses =20 Hi all, I try to make bsnmpd IPv6 aware and need some help here. I've set up a = small IPv6 network for testing between a couple of VMs. For IPv6 interface addresses there are two tables: ipAddressPrefix table = and ipAddressTable (containing pointers to the prefix table). Now I see = something on my system I cannot grasp. ndp -pn gives me: 2001:638:101:ff::/64 if=3Dle0 flags=3DLO vltime=3Dinfinity, pltime=3Dinfinity, expire=3DNever, ref=3D1 No advertising router fe80::%le0/64 if=3Dle0 flags=3DLAO vltime=3Dinfinity, pltime=3Dinfinity, expire=3DNever, = ref=3D0 No advertising router fe80::%lo0/64 if=3Dlo0 flags=3DLAO vltime=3Dinfinity, pltime=3Dinfinity, expire=3DNever, = ref=3D0 No advertising router ifconfig -a inet6 gives: le0: flags=3D8843 metric 0 mtu = 1500 options=3D8 inet6 fe80::20c:29ff:fe90:dd1b%le0 prefixlen 64 scopeid 0x1=20 inet6 2001:638:101:ff::8:ffff prefixlen 64=20 lo0: flags=3D8049 metric 0 mtu 16384 options=3D3 inet6 ::1 prefixlen 128=20 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2=20 So far, so nice. When I ask for the interface addresses via sysctl([0, NET_RT_IFLIST, 0], = ...) I get strange RTM_NEWADDR messages: msglen=3D76 version=3D5 type=3DRTM_NEWADDR flags=3D0 index=3D1 metric=3D0 netmask=3DINET6,28,{0,0,ffff:ffff:ffff:ffff::,0} ifa=3DINET6,28,{0,0,fe80:1::20c:29ff:fe90:dd1b,0} Which means a prefix of fe80:1::/64 instead of fe80::%le0/64. Note, the = :1: there and note the zero missing scope_id (the last 0 inside the {}). Same for lo0: msglen=3D80 version=3D5 type=3DRTM_NEWADDR flags=3D0 index=3D2 metric=3D0 netmask=3DINET6,28,{0,0,ffff:ffff:ffff:ffff::,0} ifa=3DINET6,28,{0,0,fe80:2::1,0} brd=3DUNSPEC,0,{} So my questions: - are the routing message really that inconsistent and broken? Or do I = read them somehow incorrect? - is it possible to rely on the prefix table? In other words: Does = *each* prefix used in a INET6 interface address appear in the prefix list? harti _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Nov 25 16:01:29 2009 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 0DCE710656A5 for ; Wed, 25 Nov 2009 16:01:28 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id 52AAC8FC1A for ; Wed, 25 Nov 2009 16:01:28 +0000 (UTC) Received: from delta.allbsd.org (p3177-ipbf416funabasi.chiba.ocn.ne.jp [123.225.92.177]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id nAPG11W4003203; Thu, 26 Nov 2009 01:01:12 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id nAPG0t0u045476; Thu, 26 Nov 2009 01:01:00 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 26 Nov 2009 01:00:45 +0900 (JST) Message-Id: <20091126.010045.102373628.hrs@allbsd.org> To: Hartmut.Brandt@dlr.de From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3rc1 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Nov_26_01_00_45_2009_509)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Thu, 26 Nov 2009 01:01:18 +0900 (JST) X-Spam-Status: No, score=-4.4 required=13.0 tests=AWL,BAYES_00, CONTENT_TYPE_PRESENT, SPF_SOFTFAIL, X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org Subject: Re: Need help on IPv6 prefixes and interface addresses X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:01:29 -0000 ----Security_Multipart(Thu_Nov_26_01_00_45_2009_509)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit wrote in : Ha> To answer my own question :-) These strange link local addresses are Ha> explained in the developers handbook section 8.1.1.3 and are called Ha> embedded Ha> link local addresses. These are not standard IPv6 addresses, but a way Ha> to encode the interface index (aka zone index) into the IPv6 Ha> address. This must be undone by the user program before using these Ha> addresses. I think "1.3.1 Kernel internal" in /usr/share/doc/IPv6/IMPLEMENTATION would also help. -- Hiroki ----Security_Multipart(Thu_Nov_26_01_00_45_2009_509)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAksNVK0ACgkQTyzT2CeTzy1XgQCfbaFHotSVr46fY9rGqjlvWUAk i8MAniCSlAhnrHHmEXk/BkiPlc9OsobE =1tzD -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Nov_26_01_00_45_2009_509)---- From owner-freebsd-net@FreeBSD.ORG Wed Nov 25 16:01:36 2009 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 4D022106568B; Wed, 25 Nov 2009 16:01:36 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id E7E688FC16; Wed, 25 Nov 2009 16:01:34 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id nAPG1GVc001065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 01:01:21 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 26 Nov 2009 01:01:16 +0900 Message-ID: From: Hajimu UMEMOTO To: John Baldwin In-Reply-To: <200911231255.26279.jhb@freebsd.org> References: <200911231056.15247.jhb@freebsd.org> <200911231255.26279.jhb@freebsd.org> User-Agent: xcite1.58> Wanderlust/2.15.7 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i386-portbld-freebsd8.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.0-RELEASE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Thu_Nov_26_01:01:16_2009-1" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Thu, 26 Nov 2009 01:01:21 +0900 (JST) X-Virus-Scanned: clamav-milter 0.95.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Doug Barton Subject: Re: [CFR] unified rc.firewall X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 16:01:36 -0000 --Multipart_Thu_Nov_26_01:01:16_2009-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On Mon, 23 Nov 2009 12:55:25 -0500 >>>>> John Baldwin said: I updated the patch. jhb> I had missed the me vs any. It is true that the equivalent rule would use jhb> me6. I would rather figure out the IPv6 bug so that TCP is treated the jhb> same for both protocols instead of having a weaker firewall for IPv6 than jhb> IPV4. Yes, it is better, definitely. I thought that we could change to use dynamic rule, once it was fixed. Since the PR kern/117234 fixed it, I changed to use dynamic rule for IPv6 as well. So, it requires the patch in the PR. jhb> I do find the shorter version easier to read, and it matches the existing jhb> style as well as the examples in the manual page, handbook, etc. Okay, I changed 'ip6' to 'all' where we can use it, and stopped use of 'proto xxx'' as possible. I reconsidered oif vs oif6 and iif vs iif6 issue. Now, if $firewall_simple_oif_ipv6 is not set, $firewall_simple_oif is assumed for oif6, and, $firewall_simple_iif_ipv6 is not set, $firewall_simple_iif is assumed for iif6. Further, I think we don't assign a global IPv6 address to oif in usual. So, I made $firewall_simple_onet_ipv6 optional. One more change is that DHCPv6 is allowed as well as IPv4 DHCP for WORKSTATION type. I'm using DHCPv6 in usual; L2TP + DHCPv6 PD, DHCPv6 DNS option ... Sincerely, --Multipart_Thu_Nov_26_01:01:16_2009-1 Content-Type: text/x-patch; type=patch; charset=US-ASCII Content-Disposition: attachment; filename="ipfw-unify.diff" Content-Transfer-Encoding: 7bit Index: etc/Makefile diff -u etc/Makefile.orig etc/Makefile --- etc/Makefile.orig 2009-10-25 10:10:29.000000000 +0900 +++ etc/Makefile 2009-11-22 22:07:19.840275808 +0900 @@ -15,7 +15,7 @@ inetd.conf libalias.conf login.access login.conf mac.conf motd \ netconfig network.subr networks newsyslog.conf nsswitch.conf \ phones profile protocols \ - rc rc.bsdextended rc.firewall rc.firewall6 rc.initdiskless \ + rc rc.bsdextended rc.firewall rc.initdiskless \ rc.sendmail rc.shutdown \ rc.subr remote rpc services shells \ sysctl.conf syslog.conf \ Index: etc/defaults/rc.conf diff -u etc/defaults/rc.conf.orig etc/defaults/rc.conf --- etc/defaults/rc.conf.orig 2009-10-25 10:10:29.000000000 +0900 +++ etc/defaults/rc.conf 2009-11-22 21:25:22.343296205 +0900 @@ -118,7 +118,10 @@ firewall_quiet="NO" # Set to YES to suppress rule display firewall_logging="NO" # Set to YES to enable events logging firewall_flags="" # Flags passed to ipfw when type is a file -firewall_client_net="192.0.2.0/24" # Network address for "client" firewall. +firewall_client_net="192.0.2.0/24" # IPv4 Network address for "client" + # firewall. +#firewall_client_net_ipv6="2001:db8:2:1::/64" # IPv6 network prefix for + # "client" firewall. firewall_simple_iif="ed1" # Inside network interface for "simple" # firewall. firewall_simple_inet="192.0.2.16/28" # Inside network address for "simple" @@ -127,12 +130,22 @@ # firewall. firewall_simple_onet="192.0.2.0/28" # Outside network address for "simple" # firewall. +#firewall_simple_iif_ipv6="ed1" # Inside IPv6 network interface for "simple" + # firewall. +#firewall_simple_inet_ipv6="2001:db8:2:800::/56" # Inside IPv6 network prefix + # for "simple" firewall. +#firewall_simple_oif_ipv6="ed0" # Outside IPv6 network interface for "simple" + # firewall. +#firewall_simple_onet_ipv6="2001:db8:2:0::/56" # Outside IPv6 network prefix + # for "simple" firewall. firewall_myservices="" # List of TCP ports on which this host # offers services for "workstation" firewall. firewall_allowservices="" # List of IPs which have access to # $firewall_myservices for "workstation" # firewall. -firewall_trusted="" # List of IPs which have full access to this +firewall_trusted="" # List of IPv4s which have full access to this + # host for "workstation" firewall. +firewall_trusted_ipv6="" # List of IPv6s which have full access to this # host for "workstation" firewall. firewall_logdeny="NO" # Set to YES to log default denied incoming # packets for "workstation" firewall. @@ -470,13 +483,18 @@ # faithd(8) setup. ipv6_ipv4mapping="NO" # Set to "YES" to enable IPv4 mapped IPv6 addr # communication. (like ::ffff:a.b.c.d) -ipv6_firewall_enable="NO" # Set to YES to enable IPv6 firewall - # functionality -ipv6_firewall_script="/etc/rc.firewall6" # Which script to run to set up the IPv6 firewall -ipv6_firewall_type="UNKNOWN" # IPv6 Firewall type (see /etc/rc.firewall6) -ipv6_firewall_quiet="NO" # Set to YES to suppress rule display -ipv6_firewall_logging="NO" # Set to YES to enable events logging -ipv6_firewall_flags="" # Flags passed to ip6fw when type is a file +#ipv6_firewall_enable="NO" # Set to YES to enable IPv6 firewall + # functionality (DEPRECAED) +#ipv6_firewall_script="/etc/rc.firewall6" # Which script to run to set up the + # IPv6 firewall (DEPRECAED) +#ipv6_firewall_type="UNKNOWN" # IPv6 Firewall type (see /etc/rc.firewall6) + # (DEPRECAED) +#ipv6_firewall_quiet="NO" # Set to YES to suppress rule display + # (DEPRECAED) +#ipv6_firewall_logging="NO" # Set to YES to enable events logging + # (DEPRECAED) +#ipv6_firewall_flags="" # Flags passed to ip6fw when type is a file + # (DEPRECAED) ipv6_ipfilter_rules="/etc/ipf6.rules" # rules definition file for ipfilter, # see /usr/src/contrib/ipfilter/rules # for examples Index: etc/rc.d/Makefile diff -u etc/rc.d/Makefile.orig etc/rc.d/Makefile --- etc/rc.d/Makefile.orig 2009-10-25 10:10:29.000000000 +0900 +++ etc/rc.d/Makefile 2009-11-22 20:42:16.398311126 +0900 @@ -15,7 +15,7 @@ hcsecd \ hostapd hostid hostid_save hostname \ inetd initrandom \ - ip6addrctl ip6fw ipfilter ipfs ipfw ipmon \ + ip6addrctl ipfilter ipfs ipfw ipmon \ ipnat ipsec ipxrouted \ jail \ kadmind kerberos keyserv kldxref kpasswdd \ Index: etc/rc.d/ipfw diff -u etc/rc.d/ipfw.orig etc/rc.d/ipfw --- etc/rc.d/ipfw.orig 2009-11-22 20:43:59.000000000 +0900 +++ etc/rc.d/ipfw 2009-11-23 19:29:05.426333161 +0900 @@ -61,7 +61,13 @@ # Enable the firewall # if ! ${SYSCTL_W} net.inet.ip.fw.enable=1 1>/dev/null 2>&1; then - warn "failed to enable firewall" + warn "failed to enable IPv4 firewall" + fi + if afexists inet6; then + if ! ${SYSCTL_W} net.inet6.ip6.fw.enable=1 1>/dev/null 2>&1 + then + warn "failed to enable IPv6 firewall" + fi fi } @@ -70,6 +76,9 @@ # Disable the firewall # ${SYSCTL_W} net.inet.ip.fw.enable=0 + if afexists inet6; then + ${SYSCTL_W} net.inet6.ip6.fw.enable=0 + fi if [ -f /etc/rc.d/natd ] ; then /etc/rc.d/natd quietstop fi Index: etc/rc.firewall diff -u etc/rc.firewall.orig etc/rc.firewall --- etc/rc.firewall.orig 2009-10-25 10:10:29.000000000 +0900 +++ etc/rc.firewall 2009-11-25 03:18:14.568870172 +0900 @@ -85,12 +85,42 @@ ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny all from any to 127.0.0.0/8 ${fwcmd} add 300 deny ip from 127.0.0.0/8 to any + if [ $ipv6_available -eq 0 ]; then + ${fwcmd} add 400 deny all from any to ::1 + ${fwcmd} add 500 deny all from ::1 to any + fi +} + +setup_ipv6_mandatory () { + [ $ipv6_available -eq 0 ] || return 0 + + ############ + # Only in rare cases do you want to change these rules + # + # ND + # + # DAD + ${fwcmd} add pass ipv6-icmp from :: to ff02::/16 + # RS, RA, NS, NA, redirect... + ${fwcmd} add pass ipv6-icmp from fe80::/10 to fe80::/10 + ${fwcmd} add pass ipv6-icmp from fe80::/10 to ff02::/16 + + # Allow ICMPv6 destination unreach + ${fwcmd} add pass ipv6-icmp from any to any icmp6types 1 + + # Allow NS/NA/toobig (don't filter it out) + ${fwcmd} add pass ipv6-icmp from any to any icmp6types 2,135,136 } if [ -n "${1}" ]; then firewall_type="${1}" fi +. /etc/rc.subr +. /etc/network.subr +afexists inet6 +ipv6_available=$? + ############ # Set quiet mode if requested # @@ -109,6 +139,7 @@ ${fwcmd} -f flush setup_loopback +setup_ipv6_mandatory ############ # Network Address Translation. All packets are passed to natd(8) @@ -166,11 +197,13 @@ # against people from outside your own network. # # Configuration: - # firewall_client_net: Network address of local network. + # firewall_client_net: Network address of local IPv4 network. + # firewall_client_net_ipv6: Network address of local IPv6 network. ############ # set this to your local network net="$firewall_client_net" + net6="$firewall_client_net_ipv6" # Allow limited broadcast traffic from my own net. ${fwcmd} add pass all from ${net} to 255.255.255.255 @@ -178,6 +211,16 @@ # Allow any traffic to or from my own net. ${fwcmd} add pass all from me to ${net} ${fwcmd} add pass all from ${net} to me + if [ -n "$net6" ]; then + ${fwcmd} add pass all from me6 to ${net6} + ${fwcmd} add pass all from ${net6} to me6 + fi + + if [ -n "$net6" ]; then + # Allow any link-local multicast traffic + ${fwcmd} add pass all from fe80::/10 to ff02::/16 + ${fwcmd} add pass all from ${net6} to ff02::/16 + fi # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established @@ -212,23 +255,38 @@ # on the inside at this machine for those services. # # Configuration: - # firewall_simple_iif: Inside network interface. - # firewall_simple_inet: Inside network address. - # firewall_simple_oif: Outside network interface. - # firewall_simple_onet: Outside network address. + # firewall_simple_iif: Inside IPv4 network interface. + # firewall_simple_inet: Inside IPv4 network address. + # firewall_simple_oif: Outside IPv4 network interface. + # firewall_simple_onet: Outside IPv4 network address. + # firewall_simple_iif_ipv6: Inside IPv6 network interface. + # firewall_simple_inet_ipv6: Inside IPv6 network prefix. + # firewall_simple_oif_ipv6: Outside IPv6 network interface. + # firewall_simple_onet_ipv6: Outside IPv6 network prefix. ############ # set these to your outside interface network oif="$firewall_simple_oif" onet="$firewall_simple_onet" + oif6="${firewall_simple_oif_ipv6:-$firewall_simple_oif}" + onet6="$firewall_simple_onet_ipv6" # set these to your inside interface network iif="$firewall_simple_iif" inet="$firewall_simple_inet" + iif6="${firewall_simple_iif_ipv6:-$firewall_simple_iif}" + inet6="$firewall_simple_inet_ipv6" # Stop spoofing ${fwcmd} add deny all from ${inet} to any in via ${oif} ${fwcmd} add deny all from ${onet} to any in via ${iif} + if [ -n "$inet6" ]; then + ${fwcmd} add deny all from ${inet6} to any in via ${oif6} + if [ -n "$onet6" ]; then + ${fwcmd} add deny all from ${onet6} to any in \ + via ${iif6} + fi + fi # Stop RFC1918 nets on the outside interface ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} @@ -254,7 +312,7 @@ case ${natd_enable} in [Yy][Ee][Ss]) if [ -n "${natd_interface}" ]; then - ${fwcmd} add divert natd all from any to any via ${natd_interface} + ${fwcmd} add divert natd ip4 from any to any via ${natd_interface} fi ;; esac @@ -273,6 +331,55 @@ ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} + if [ -n "$inet6" ]; then + # Stop unique local unicast address on the outside interface + ${fwcmd} add deny all from fc00::/7 to any via ${oif6} + ${fwcmd} add deny all from any to fc00::/7 via ${oif6} + + # Stop site-local on the outside interface + ${fwcmd} add deny all from fec0::/10 to any via ${oif6} + ${fwcmd} add deny all from any to fec0::/10 via ${oif6} + + # Disallow "internal" addresses to appear on the wire. + ${fwcmd} add deny all from ::ffff:0.0.0.0/96 to any \ + via ${oif6} + ${fwcmd} add deny all from any to ::ffff:0.0.0.0/96 \ + via ${oif6} + + # Disallow packets to malicious IPv4 compatible prefix. + ${fwcmd} add deny all from ::224.0.0.0/100 to any via ${oif6} + ${fwcmd} add deny all from any to ::224.0.0.0/100 via ${oif6} + ${fwcmd} add deny all from ::127.0.0.0/104 to any via ${oif6} + ${fwcmd} add deny all from any to ::127.0.0.0/104 via ${oif6} + ${fwcmd} add deny all from ::0.0.0.0/104 to any via ${oif6} + ${fwcmd} add deny all from any to ::0.0.0.0/104 via ${oif6} + ${fwcmd} add deny all from ::255.0.0.0/104 to any via ${oif6} + ${fwcmd} add deny all from any to ::255.0.0.0/104 via ${oif6} + + ${fwcmd} add deny all from ::0.0.0.0/96 to any via ${oif6} + ${fwcmd} add deny all from any to ::0.0.0.0/96 via ${oif6} + + # Disallow packets to malicious 6to4 prefix. + ${fwcmd} add deny all from 2002:e000::/20 to any via ${oif6} + ${fwcmd} add deny all from any to 2002:e000::/20 via ${oif6} + ${fwcmd} add deny all from 2002:7f00::/24 to any via ${oif6} + ${fwcmd} add deny all from any to 2002:7f00::/24 via ${oif6} + ${fwcmd} add deny all from 2002:0000::/24 to any via ${oif6} + ${fwcmd} add deny all from any to 2002:0000::/24 via ${oif6} + ${fwcmd} add deny all from 2002:ff00::/24 to any via ${oif6} + ${fwcmd} add deny all from any to 2002:ff00::/24 via ${oif6} + + ${fwcmd} add deny all from 2002:0a00::/24 to any via ${oif6} + ${fwcmd} add deny all from any to 2002:0a00::/24 via ${oif6} + ${fwcmd} add deny all from 2002:ac10::/28 to any via ${oif6} + ${fwcmd} add deny all from any to 2002:ac10::/28 via ${oif6} + ${fwcmd} add deny all from 2002:c0a8::/32 to any via ${oif6} + ${fwcmd} add deny all from any to 2002:c0a8::/32 via ${oif6} + + ${fwcmd} add deny all from ff05::/16 to any via ${oif6} + ${fwcmd} add deny all from any to ff05::/16 via ${oif6} + fi + # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established @@ -291,7 +398,11 @@ ${fwcmd} add pass tcp from any to me 80 setup # Reject&Log all setup of incoming connections from the outside - ${fwcmd} add deny log tcp from any to any in via ${oif} setup + ${fwcmd} add deny log ip4 from any to any in via ${oif} setup proto tcp + if [ -n "$inet6" ]; then + ${fwcmd} add deny log ip6 from any to any in via ${oif6} \ + setup proto tcp + fi # Allow setup of any other TCP connection ${fwcmd} add pass tcp from any to any setup @@ -313,7 +424,7 @@ # offers services. # firewall_allowservices: List of IPs which has access to # $firewall_myservices. - # firewall_trusted: List of IPs which has full access + # firewall_trusted: List of IPv4s which has full access # to this host. Be very carefull # when setting this. This option can # seriously degrade the level of @@ -324,25 +435,44 @@ # firewall_nologports: List of TCP/UDP ports for which # denied incomming packets are not # logged. - + # firewall_trusted_ipv6: List of IPv6s which has full access + # to this host. Be very carefull + # when setting this. This option can + # seriously degrade the level of + # protection provided by the firewall. + # Allow packets for which a state has been built. ${fwcmd} add check-state # For services permitted below. ${fwcmd} add pass tcp from me to any established + if [ $ipv6_available -eq 0 ]; then + ${fwcmd} add pass tcp from me6 to any established + fi # Allow any connection out, adding state for each. ${fwcmd} add pass tcp from me to any setup keep-state ${fwcmd} add pass udp from me to any keep-state ${fwcmd} add pass icmp from me to any keep-state + if [ $ipv6_available -eq 0 ]; then + ${fwcmd} add pass tcp from me6 to any setup keep-state + ${fwcmd} add pass udp from me6 to any keep-state + ${fwcmd} add pass ipv6-icmp from me6 to any keep-state + fi # Allow DHCP. ${fwcmd} add pass udp from 0.0.0.0 68 to 255.255.255.255 67 out ${fwcmd} add pass udp from any 67 to me 68 in ${fwcmd} add pass udp from any 67 to 255.255.255.255 68 in + if [ $ipv6_available -eq 0 ]; then + ${fwcmd} add pass udp from fe80::/10 to me6 546 in + fi # Some servers will ping the IP while trying to decide if it's # still in use. ${fwcmd} add pass icmp from any to any icmptype 8 + if [ $ipv6_available -eq 0 ]; then + ${fwcmd} add pass ipv6-icmp from any to any icmp6type 128,129 + fi # Allow "mandatory" ICMP in. ${fwcmd} add pass icmp from any to any icmptype 3,4,11 @@ -361,6 +491,9 @@ for i in ${firewall_allowservices} ; do for j in ${firewall_myservices} ; do ${fwcmd} add pass tcp from $i to me $j + if [ $ipv6_available -eq 0 ]; then + ${fwcmd} add pass tcp from $i to me6 $j + fi done done @@ -370,7 +503,10 @@ for i in ${firewall_trusted} ; do ${fwcmd} add pass ip from $i to me done - + for i in ${firewall_trusted_ipv6} ; do + ${fwcmd} add pass all from $i to me6 + done + ${fwcmd} add 65000 count ip from any to any # Drop packets to ports where we don't want logging --Multipart_Thu_Nov_26_01:01:16_2009-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Thu_Nov_26_01:01:16_2009-1-- From owner-freebsd-net@FreeBSD.ORG Wed Nov 25 18:22:12 2009 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 3CC73106566C for ; Wed, 25 Nov 2009 18:22:12 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp2.dlr.de (smtp1.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id C688B8FC18 for ; Wed, 25 Nov 2009 18:22:11 +0000 (UTC) Received: from exbe5.intra.dlr.de ([172.21.106.15]) by smtp2.dlr.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Nov 2009 19:22:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Nov 2009 19:22:09 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Getting creation and modification time of an IPv6 interface address Thread-Index: Acpt/DNHbSdszT9pRTyVTKm6DQj8aw== From: To: X-OriginalArrivalTime: 25 Nov 2009 18:22:10.0009 (UTC) FILETIME=[33B3D490:01CA6DFC] Subject: Getting creation and modification time of an IPv6 interface address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:22:12 -0000 Hi, I'm working on the IpAddressTable for bsnmpd. This table has two rows = ipAddressCreated and ipAddressLastUpdated which seem to correspond to the created and changed fields of the struct in6_ifaddr. = Because there seems no way (except for poking in the kernel memory) to get at these values I have added an ioctl to get them = much in the spirit of the other ioctls for IPv6 addresses. I'm not sure how the ioctl codes are allocated so I just took the next = available one. If this looks ok and there are no principal problems, I would like to commit that. harti Index: in6.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvsup/src/sys/netinet6/in6.c,v retrieving revision 1.121.2.8 diff -u -r1.121.2.8 in6.c --- in6.c 28 Oct 2009 21:45:25 -0000 1.121.2.8 +++ in6.c 25 Nov 2009 17:41:40 -0000 @@ -312,6 +312,7 @@ case SIOCSIFALIFETIME_IN6: case SIOCGIFSTAT_IN6: case SIOCGIFSTAT_ICMP6: + case SIOCGIFATIMES_IN6: sa6 =3D &ifr->ifr_addr; break; default: @@ -383,6 +384,7 @@ case SIOCGIFNETMASK_IN6: case SIOCGIFDSTADDR_IN6: case SIOCGIFALIFETIME_IN6: + case SIOCGIFATIMES_IN6: /* must think again about its semantics */ if (ia =3D=3D NULL) { error =3D EADDRNOTAVAIL; @@ -652,6 +654,11 @@ prelist_remove(pr); EVENTHANDLER_INVOKE(ifaddr_event, ifp); break; + + case SIOCGIFATIMES_IN6: + ifr->ifr_ifru.ifru_times[0] =3D ia->ia6_createtime; + ifr->ifr_ifru.ifru_times[1] =3D ia->ia6_updatetime; + break; } =20 default: Index: in6_var.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /usr/cvsup/src/sys/netinet6/in6_var.h,v retrieving revision 1.45.2.1 diff -u -r1.45.2.1 in6_var.h --- in6_var.h 3 Aug 2009 08:13:06 -0000 1.45.2.1 +++ in6_var.h 25 Nov 2009 17:07:34 -0000 @@ -277,6 +277,7 @@ struct in6_ifstat ifru_stat; struct icmp6_ifstat ifru_icmp6stat; u_int32_t ifru_scope_id[16]; + time_t ifru_times[2]; } ifr_ifru; }; =20 @@ -463,6 +464,8 @@ #define SIOCAADDRCTL_POLICY _IOW('u', 108, struct in6_addrpolicy) #define SIOCDADDRCTL_POLICY _IOW('u', 109, struct in6_addrpolicy) =20 +#define SIOCGIFATIMES_IN6 _IOWR('i', 110, struct in6_ifreq) + #define IN6_IFF_ANYCAST 0x01 /* anycast address */ #define IN6_IFF_TENTATIVE 0x02 /* tentative address */ #define IN6_IFF_DUPLICATED 0x04 /* DAD detected duplicate */ From owner-freebsd-net@FreeBSD.ORG Wed Nov 25 18:56:11 2009 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 10A8B10656A4 for ; Wed, 25 Nov 2009 18:56:11 +0000 (UTC) (envelope-from brunner@nic-naa.net) Received: from abenaki.wabanaki.net (abenaki.wabanaki.net [65.99.1.130]) by mx1.freebsd.org (Postfix) with ESMTP id B90848FC19 for ; Wed, 25 Nov 2009 18:56:10 +0000 (UTC) Received: from limpet.local (cpe-67-241-43-7.twcny.res.rr.com [67.241.43.7]) by abenaki.wabanaki.net (8.14.3/8.14.3) with ESMTP id nAPIS6gC028737 for ; Wed, 25 Nov 2009 13:28:06 -0500 (EST) (envelope-from brunner@nic-naa.net) Message-ID: <4B0D78A3.8080309@nic-naa.net> Date: Wed, 25 Nov 2009 13:34:11 -0500 From: Eric Brunner-Williams User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "net@freebsd.org" References: <4AE72910.8090708@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A04B491AE@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE8CC59.7020004@tomjudge.com> <4AE9D10F.4040703@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A054DE883@IRVEXCHCCR01.corp.ad.broadcom.com> <4AE9F576.4060101@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35A55@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA0B11.2050209@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A19B35AB0@IRVEXCHCCR01.corp.ad.broadcom.com> <4AEA1183.7050306@tomjudge.com> <4AEB2571.7090006@tomjudge.com> <4AFAE428.5090907@quip.cz> <5D267A3F22FD854F8F48B3D2B52381933A20D4C55D@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFAF542.8050004@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A20D4CA70@IRVEXCHCCR01.corp.ad.broadcom.com> <4AFC862B.6060805@tomjudge.com> <5D267A3F22FD854F8F48B3D2B52381933A20E0EFE1@IRVEXCHCCR01.corp.ad.broadcom.com> <5D267A3F22FD854F8F48B3D2B52381933A20E0F332@IRVEXCHCCR01.corp.ad.broadcom.com> <4B0C80FB.5040901@tomjudge.com> In-Reply-To: <4B0C80FB.5040901@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Wireless PCI recommendations for CURRENT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:56:11 -0000 I'd like suggestions for a PCI wifi. Vanilla tower with -CURRENT. Thanks in advance, Eric From owner-freebsd-net@FreeBSD.ORG Wed Nov 25 18:57:55 2009 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 A221F1065672 for ; Wed, 25 Nov 2009 18:57:55 +0000 (UTC) (envelope-from rganascim@gmail.com) Received: from mail-yx0-f184.google.com (mail-yx0-f184.google.com [209.85.210.184]) by mx1.freebsd.org (Postfix) with ESMTP id 5933A8FC1A for ; Wed, 25 Nov 2009 18:57:55 +0000 (UTC) Received: by yxe14 with SMTP id 14so9390yxe.7 for ; Wed, 25 Nov 2009 10:57:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=yZQEeWsvXBfneP7KQGlv4QLOwEEo6BebA0f58Cfcwzo=; b=artOcT46T0k8E8UgDY21TgxA9/XN59U0k2aZOfPAcKCXxHmcFWeNNpS3RVOZ5ki5Xz bKAI7UhE8DTtP6lOSHSp1iyfk7DFxK/PwPZOShtiELwPzB582ateI0IMexVCSXXhhjTU 9g7tpszVLFcYqYQpudWpC8wiHChwnKy4bSrSM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=JXkAF/STsfpq1/05qH+5L2jjLG8IrADAHysCb15Wb09h+95pcEqKLn9MOjH4cXOoHx aFsY4Aug11YKiQzFK5p7bVhU3tOMTU4z+ZSAU49lQyQYQo+hUiDGOvDGcB1Wa7qGk0p/ UEPksOlHB9zH6BSU3yOPwcYENIYDjQw6MTaoM= MIME-Version: 1.0 Received: by 10.90.210.11 with SMTP id i11mr1685635agg.94.1259174066547; Wed, 25 Nov 2009 10:34:26 -0800 (PST) Date: Wed, 25 Nov 2009 16:34:26 -0200 Message-ID: <2f7feda40911251034p17686d34h25e2a9467751c728@mail.gmail.com> From: Rafael Ganascim To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: What is better? Use a SMP kernel or amd64 for network? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 18:57:55 -0000 Hi list, I have a doubt (don't encountered on google) about what is better for a FreeBSD Router: use a 32bits SMP kernel or an amd64? I know that exists some differences, but generaly, what is better and why? I have a hardware with Xeon Dual processor. Thanks, Rafael From owner-freebsd-net@FreeBSD.ORG Wed Nov 25 22:42:26 2009 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 05664106566C for ; Wed, 25 Nov 2009 22:42:26 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from warped.bluecherry.net (unknown [IPv6:2001:440:eeee:fffb::2]) by mx1.freebsd.org (Postfix) with ESMTP id 8541B8FC16 for ; Wed, 25 Nov 2009 22:42:25 +0000 (UTC) Received: from volatile.chemikals.org (adsl-67-221-140.shv.bellsouth.net [98.67.221.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by warped.bluecherry.net (Postfix) with ESMTPSA id 8445098AB603; Wed, 25 Nov 2009 16:42:24 -0600 (CST) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.14.3/8.14.3) with ESMTP id nAPMgK26067149; Wed, 25 Nov 2009 16:42:21 -0600 (CST) (envelope-from morganw@chemikals.org) Date: Wed, 25 Nov 2009 16:42:20 -0600 (CST) From: Wes Morgan To: Rafael Ganascim In-Reply-To: <2f7feda40911251034p17686d34h25e2a9467751c728@mail.gmail.com> Message-ID: References: <2f7feda40911251034p17686d34h25e2a9467751c728@mail.gmail.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: clamav-milter 0.95.2 at warped X-Virus-Status: Clean Cc: freebsd-net@freebsd.org Subject: Re: What is better? Use a SMP kernel or amd64 for network? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 22:42:26 -0000 On Wed, 25 Nov 2009, Rafael Ganascim wrote: > Hi list, > > I have a doubt (don't encountered on google) about what is better for a > FreeBSD Router: use a 32bits SMP kernel or an amd64? I know that exists some > differences, but generaly, what is better and why? > > I have a hardware with Xeon Dual processor. Why not an SMP amd64 kernel? SMP is not exclusive to i386. From owner-freebsd-net@FreeBSD.ORG Wed Nov 25 23:26:38 2009 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 91B7E106568B for ; Wed, 25 Nov 2009 23:26:38 +0000 (UTC) (envelope-from freebsdlists@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 4E1E28FC1D for ; Wed, 25 Nov 2009 23:26:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id 35B796122 for ; Thu, 26 Nov 2009 00:08:14 +0100 (CET) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XWetUuF5uEmf for ; Thu, 26 Nov 2009 00:08:10 +0100 (CET) Received: from Toms-Kraftbuch.local (dmhd.bsdunix.ch [82.220.17.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id 97D045D5A for ; Thu, 26 Nov 2009 00:08:10 +0100 (CET) Message-ID: <4B0DB8DA.90003@bsdunix.ch> Date: Thu, 26 Nov 2009 00:08:10 +0100 From: Thomas Vogt User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: netstat -an shows me an open "phantom" tcp6 port X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2009 23:26:38 -0000 Hi I'm confused. I've a new installed FreeBSD system. I'm running NFS, http, ntpd and a ftp server. If i look for open ports netstat shows me something on port 1000 (ipv6) netstat -an | grep 1000 tcp6 0 0 *.1000 *.* LISTEN But sockstat shows me nothing: sockstat -6 | grep tcp6 root sshd 704 3 tcp6 *:22 *:* root rpc.statd 599 6 tcp6 *:912 *:* root rpcbind 597 8 tcp6 *:111 *:* Also lsof -i 6 -a -P shows me nothing on port 1000. Any idea who i can figure out whats running on port 1000 with ipv6? Only the loopback interface has an ipv6 address. System: FreeBSD 7.2-RELEASE-p4 amd64 Regards, Thomas From owner-freebsd-net@FreeBSD.ORG Thu Nov 26 00:07:31 2009 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 16AA91065695 for ; Thu, 26 Nov 2009 00:07:31 +0000 (UTC) (envelope-from hhw@pce-net.com) Received: from van-mx-1.mx.peer1.net (smtp.peer1.com [69.90.111.110]) by mx1.freebsd.org (Postfix) with ESMTP id EF16D8FC18 for ; Thu, 26 Nov 2009 00:07:30 +0000 (UTC) Received: from [64.34.104.10] by van-mx-1.mx.peer1.net with esmtpa (Exim 4.69) (envelope-from ) id 1NDRLg-00079f-2U for freebsd-net@freebsd.org; Wed, 25 Nov 2009 15:32:36 -0800 Message-ID: <4B0DBE93.20102@pce-net.com> Date: Wed, 25 Nov 2009 15:32:35 -0800 From: Han Hwei Woo User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <2f7feda40911251034p17686d34h25e2a9467751c728@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Do-Not-Run: Yes X-SA-Exim-Connect-IP: 64.34.104.10 X-SA-Exim-Mail-From: hhw@pce-net.com X-SA-Exim-Scanned: No (on van-mx-1.mx.peer1.net); SAEximRunCond expanded to false Subject: Re: What is better? Use a SMP kernel or amd64 for network? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 00:07:31 -0000 It used to be that UP i386 was the way to go for best routing performance. I'm not sure if this has changed more recently, due to the changes in the network stack. Wes Morgan wrote: > On Wed, 25 Nov 2009, Rafael Ganascim wrote: > >> Hi list, >> >> I have a doubt (don't encountered on google) about what is better for a >> FreeBSD Router: use a 32bits SMP kernel or an amd64? I know that >> exists some >> differences, but generaly, what is better and why? >> >> I have a hardware with Xeon Dual processor. > > Why not an SMP amd64 kernel? SMP is not exclusive to i386. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Nov 26 05:28:37 2009 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 E826E106566B for ; Thu, 26 Nov 2009 05:28:37 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outN.internet-mail-service.net (outn.internet-mail-service.net [216.240.47.237]) by mx1.freebsd.org (Postfix) with ESMTP id D09018FC17 for ; Thu, 26 Nov 2009 05:28:37 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id A51BEC055E; Wed, 25 Nov 2009 21:28:37 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id 3508F2D6011; Wed, 25 Nov 2009 21:28:37 -0800 (PST) Message-ID: <4B0E1204.2070004@elischer.org> Date: Wed, 25 Nov 2009 21:28:36 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Han Hwei Woo References: <2f7feda40911251034p17686d34h25e2a9467751c728@mail.gmail.com> <4B0DBE93.20102@pce-net.com> In-Reply-To: <4B0DBE93.20102@pce-net.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: What is better? Use a SMP kernel or amd64 for network? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 05:28:38 -0000 Han Hwei Woo wrote: > It used to be that UP i386 was the way to go for best routing performance. > > I'm not sure if this has changed more recently, due to the changes in > the network stack. In all seriousness, try it and let us know. > > > Wes Morgan wrote: >> On Wed, 25 Nov 2009, Rafael Ganascim wrote: >> >>> Hi list, >>> >>> I have a doubt (don't encountered on google) about what is better for a >>> FreeBSD Router: use a 32bits SMP kernel or an amd64? I know that >>> exists some >>> differences, but generaly, what is better and why? >>> >>> I have a hardware with Xeon Dual processor. >> Why not an SMP amd64 kernel? SMP is not exclusive to i386. >> _______________________________________________ >> 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" > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Thu Nov 26 20:46:48 2009 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 B316A1065679 for ; Thu, 26 Nov 2009 20:46:48 +0000 (UTC) (envelope-from jon.otterholm@ide.resurscentrum.se) Received: from mail1.cil.se (mail1.cil.se [217.197.56.125]) by mx1.freebsd.org (Postfix) with ESMTP id 48E6F8FC23 for ; Thu, 26 Nov 2009 20:46:47 +0000 (UTC) Received: from onob6.irc-net.se ([192.168.98.91]) by mail1.cil.se over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 26 Nov 2009 21:35:03 +0100 Message-ID: <4B0EE63C.5010301@ide.resurscentrum.se> Date: Thu, 26 Nov 2009 21:34:04 +0100 From: Jon Otterholm User-Agent: Thunderbird 2.0.0.21 (X11/20090421) MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2009 20:35:03.0207 (UTC) FILETIME=[EE830B70:01CA6ED7] Subject: GRED on queue or pipe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2009 20:46:48 -0000 Doing some test of gred in dummynet. My ruleset consists of a number of queues connected to the same pipe. Queues have different weight and I want to make use of gred instead of taildrop. Should i define gred on the queues or on the pipe? To me it seems reasonable to set it on the pipe and let the pipe handle the weight from the queues. How do I define the queue-depth on queues and pipes? If the pipe has 2000 slots should queues have the same number on queues or should the total number of slots in all queues sum up to the number defined in the pipe? Example: ipfw queue 1000 config pipe 1000 weight 5 ipfw queue 2000 config pipe 2000 weight 5 ipfw queue 1001 config pipe 1000 weight 80 ipfw queue 2001 config pipe 2000 weight 80 ipfw pipe 1000 config bw 100Mbit/s buckets 65535 queue 2000 gred 0.002/1800/2000/0.1 ipfw pipe 2000 config bw 100Mbit/s buckets 65535 queue 2000 gred 0.002/1800/2000/0.1 ipfw add 10 queue 1000 ip from any to table(10) dst-port 25 out xmit em1 ipfw add 10 queue 2000 ip from table(10) to any dst-port 25 out xmit em0 ipfw add 20 queue 1001 ip from any to table(20) out xmit em1 ipfw add 20 queue 2001 ip from table(20) to any out xmit em0 //JO From owner-freebsd-net@FreeBSD.ORG Fri Nov 27 08:55:07 2009 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 5140A1065670 for ; Fri, 27 Nov 2009 08:55:07 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from mailrelay1.rambler.ru (mailrelay1.rambler.ru [81.19.66.239]) by mx1.freebsd.org (Postfix) with ESMTP id 08DD68FC14 for ; Fri, 27 Nov 2009 08:55:06 +0000 (UTC) Received: from kas30pipe.localhost (localhost [127.0.0.1]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 6C2CE130C8A for ; Fri, 27 Nov 2009 11:55:05 +0300 (MSK) Received: from localhost (sysoev.ru [81.19.68.137]) by mailrelay1.rambler.ru (Postfix) with ESMTP id BC36D130C6C for ; Fri, 27 Nov 2009 11:55:04 +0300 (MSK) Date: Fri, 27 Nov 2009 11:55:04 +0300 From: Igor Sysoev To: freebsd-net@freebsd.org Message-ID: <20091127085504.GH17494@sysoev.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.33/RELEASE, bases: 02092009 #2738642, status: clean X-SpamTest-Envelope-From: is@rambler-co.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 9536 [Sen 02 2009] X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: none X-SpamTest-Rate: 10 X-SpamTest-SPF: pass X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Subject: interface FIB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 08:55:07 -0000 Currently only packets generated during encapsulation can use interface's FIB stored during interface creation: setfib 1 ifconfig gif0 ... setfib 1 ifconfig tun0 ... is it possible to implement this feature for any interface: setfib 1 ifconfig vlan0 ... or ifconfig vlan0 setfib 1 ... -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Fri Nov 27 10:22:16 2009 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 A2E301065676 for ; Fri, 27 Nov 2009 10:22:16 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 66CB08FC26 for ; Fri, 27 Nov 2009 10:22:14 +0000 (UTC) Received: by bwz5 with SMTP id 5so1079092bwz.3 for ; Fri, 27 Nov 2009 02:22:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ifXuU0d0mkX3y94lFYCH30PlLEeVe+mxbXT5bpxxjb8=; b=HDtw0Hg8PatAO47eXQGg8UTd0K5StMs1QDOqZLmEh/q2Di5labnaNwUXlOVHmtpUrU 0s+exShtLaF6S3KjjC/ty/R0LRgMoqG12G4kWa3ckyQG5i95VaWTZ01tlIE/6996EBzD ZbFEYGtvBuQjrVv0ybXqsC7/EcjJj184VQY44= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KNskF5Lj5sxjC1kLYue+mJaY4pGpPTnXkNK2nRLuP8FvBEZIctnEE7DlsmzTiDArp9 0/Xkd34W8JrpnAxtBA1rsThXmcMg2fT0FU8BfLnbDuF5P9SyOJ9i9C8wBrtMfIDlG31I A2usBeSGoVeWsQ4nU9UdSs0h8XTAOyGJj79Hc= MIME-Version: 1.0 Received: by 10.204.33.194 with SMTP id i2mr851503bkd.146.1259317334087; Fri, 27 Nov 2009 02:22:14 -0800 (PST) In-Reply-To: <200911061758.nA6Hwic2024307@svn.freebsd.org> References: <200911061758.nA6Hwic2024307@svn.freebsd.org> Date: Fri, 27 Nov 2009 13:22:14 +0300 Message-ID: From: pluknet To: Doug Ambrisko Content-Type: multipart/mixed; boundary=00032555a0ca5b9a98047957aa60 Cc: FreeBSD Net Subject: Re: svn commit: r198994 - in stable/6/sys/dev: bce mii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 10:22:16 -0000 --00032555a0ca5b9a98047957aa60 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2009/11/6 Doug Ambrisko : > Author: ambrisko > Date: Fri Nov =A06 17:58:44 2009 > New Revision: 198994 > URL: http://svn.freebsd.org/changeset/base/198994 > > Log: > =A0MFC: Merge in minimal 5709/5716 support into 6.X extracted from curren= t. > =A0This is not a direct merge since I tried to only extra the changes to > =A0support the 5709 from all of the other changes that have happened in > =A0head. =A0This should not introduce any issues that the other changes m= ay > =A0have caused. =A0We have been running this code for months on Dell r710= 's. > =A0It has been lightly tested on systems with 5716's. > > =A0This is to allow people to run newer hardware on 6.X. Very nice. Thank you. I'm afraid not all the chunks were merged since I cannot run on 6.x with my BCM5709. FreeBSD 7.2 - works FreeBSD 6.4-stable - does not It locks up somewhere in the late stage of multiuser (usually in a random step of rc.d) and getty cannot take the control. Here it still pings via network, I can achieve ssh stage where ssh warns me "The authenticity of host '$HOST' can't be established." If I type "yes", then it stops here and no go. After return from ddb it stops even ping until next reboot. I use boot via NFS/PXE, so it may interfere there, since rc.d usually write something to disk, which is NFS-mounted here. So it probably could run fine if booting from a local disk (I can't test this setup). I've attached dmesg (doesn't differs much from 7.2) and some ddb output bel= ow. Looking in alltrace I see no obvious lockups, no nfs stuck. But sometimes sh stucks somewhere in nfsreq. The same box boots fine via NFS on different NFS setup with 7.2, a different (in h/w) box boots fine on these NFS setup and NFS root, so no mistakes in setup part. I remember that back to August I tried to boot 6.4 with what is in bce of RELENG_7 on this box and it booted fine and I xmitted some traffic with it. So I guess the problem is in NFS-boot. I'll try to find ways to boot the system locally and report back.. --=20 wbr, pluknet --00032555a0ca5b9a98047957aa60 Content-Type: application/octet-stream; name="dmesg.x3650m2-6.4-patched-verbose-bce" Content-Disposition: attachment; filename="dmesg.x3650m2-6.4-patched-verbose-bce" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g2irqec12 YmNlMDogPEJyb2FkY29tIE5ldFh0cmVtZSBJSSBCQ001NzA5IDEwMDBCYXNlLVQgKEMwKT4gbWVt IDB4OTIwMDAwMDAtMHg5M2ZmZmZmZiBpcnEgMjggYXQgZGV2aWNlIDAuMCBvbiBwY2kxMQpiY2Uw OiBSZXNlcnZlZCAweDIwMDAwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweDkyMDAw MDAwCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBiY2UwCmJyZ3BoeTA6IDxCQ001NzA5QyAxMC8xMDAv MTAwMGJhc2VUWCBQSFk+IG9uIG1paWJ1czAKYnJncGh5MDogT1VJIDB4MDA1MGVmLCBtb2RlbCAw eDAwM2MsIHJldi4gOApicmdwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwg MTAwYmFzZVRYLUZEWCwgMTAwMGJhc2VULCAxMDAwYmFzZVQtRkRYLCBhdXRvCmJjZTA6IGJwZiBh dHRhY2hlZApiY2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDoyMTo1ZTpjNjo1ZDo0Ywppb2FwaWMx OiByb3V0aW5nIGludHBpbiA0IChQQ0kgSVJRIDI4KSB0byB2ZWN0b3IgNDkKYmNlMDogW01QU0FG RV0KYmNlMDogQVNJQyAoMHg1NzA5MjAwMyk7IFJldiAoQzApOyBCdXMgKFBDSWUgeDIsIDVHYnBz KTsgRi9XICgweDA1MDAwNjA1KTsgRmxhZ3MoIE1GVyApCmJjZTE6IDxCcm9hZGNvbSBOZXRYdHJl bWUgSUkgQkNNNTcwOSAxMDAwQmFzZS1UIChDMCk+IG1lbSAweDk0MDAwMDAwLTB4OTVmZmZmZmYg aXJxIDQwIGF0IGRldmljZSAwLjEgb24gcGNpMTEKYmNlMTogUmVzZXJ2ZWQgMHgyMDAwMDAwIGJ5 dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHg5NDAwMDAwMAptaWlidXMxOiA8TUlJIGJ1cz4g b24gYmNlMQpicmdwaHkxOiA8QkNNNTcwOUMgMTAvMTAwLzEwMDBiYXNlVFggUEhZPiBvbiBtaWli dXMxCmJyZ3BoeTE6IE9VSSAweDAwNTBlZiwgbW9kZWwgMHgwMDNjLCByZXYuIDgKYnJncGh5MTog IDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIDEwMDBiYXNl VCwgMTAwMGJhc2VULUZEWCwgYXV0bwpiY2UxOiBicGYgYXR0YWNoZWQKYmNlMTogRXRoZXJuZXQg YWRkcmVzczogMDA6MjE6NWU6YzY6NWQ6NGUKaW9hcGljMTogcm91dGluZyBpbnRwaW4gMTYgKFBD SSBJUlEgNDApIHRvIHZlY3RvciA1MApiY2UxOiBbTVBTQUZFXQpiY2UxOiBBU0lDICgweDU3MDky MDAzKTsgUmV2IChDMCk7IEJ1cyAoUENJZSB4MiwgNUdicHMpOyBGL1cgKDB4MDUwMDA2MDUpOyBG bGFncyggTUZXICkKCg== --00032555a0ca5b9a98047957aa60 Content-Type: application/octet-stream; name="dmesg.x3650m2-6.4-patched" Content-Disposition: attachment; filename="dmesg.x3650m2-6.4-patched" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g2irx2qe2 R0RCOiBubyBkZWJ1ZyBwb3J0cyBwcmVzZW50ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgS0RCOiBkZWJ1Z2dlciBiYWNrZW5kczogZGRiICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBLREI6IGN1cnJlbnQg YmFja2VuZDogZGRiICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgCjEwNDg1NzYwSyBvZiBtZW1vcnkgYWJvdmUgNEdCIGlnbm9yZWQKQ29weXJpZ2h0 IChjKSAxOTkyLTIwMDggVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChjKSAxOTc5LCAx OTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAxOTk0CiAgICAg ICAgVGhlIFJlZ2VudHMgb2YgdGhlIFVuaXZlcnNpdHkgb2YgQ2FsaWZvcm5pYS4gQWxsIHJpZ2h0 cyByZXNlcnZlZC4KRnJlZUJTRCBpcyBhIHJlZ2lzdGVyZWQgdHJhZGVtYXJrIG9mIFRoZSBGcmVl QlNEIEZvdW5kYXRpb24uCkZyZWVCU0QgNi40LVJFTEVBU0UtcDcgIzExOiBGcmkgTm92ICA2IDIz OjQyOjM5IE1TSyAyMDA5CiAgICByb290QHg6L3Vzci9vYmovdXNyL3NyYy9zeXMveCBwbCMxNApU aW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApDUFU6IElu dGVsKFIpIFhlb24oUikgQ1BVICAgICAgICAgICBFNTUyMCAgQCAyLjI3R0h6ICgyMjY2Ljc2LU1I eiA2ODYtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4MTA2YTUg IFN0ZXBwaW5nID0gNQogIEZlYXR1cmVzPTB4YmZlYmZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1T UixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsQ0xGTFVT SCxEVFMsQUNQSSxNTVgsRlhTUixTU0UsU1NFMixTUyxIVFQsVE0sUEJFPgogIEZlYXR1cmVzMj0w eDljZTNiZDxTU0UzLFJTVkQyLE1PTixEU19DUEwsVk1YLEVTVCxUTTIsU1NTRTMsQ1gxNix4VFBS LFBEQ00sRENBLDxiMTk+LDxiMjA+LDxiMjM+PgogIEFNRCBGZWF0dXJlcz0weDI4MTAwMDAwPE5Y LFJEVFNDUCxMTT4KICBBTUQgRmVhdHVyZXMyPTB4MTxMQUhGPgogIENvcmVzIHBlciBwYWNrYWdl OiA4CiAgTG9naWNhbCBDUFVzIHBlciBjb3JlOiAyCnJlYWwgbWVtb3J5ICA9IDIxMzc1ODM2MTYg KDIwMzggTUIpCmF2YWlsIG1lbW9yeSA9IDIwODE2OTc3OTIgKDE5ODUgTUIpCkFDUEkgQVBJQyBU YWJsZTogPElCTSAgICBUSFVSTEVZID4KRnJlZUJTRC9TTVA6IE11bHRpcHJvY2Vzc29yIFN5c3Rl bSBEZXRlY3RlZDogMTYgQ1BVcwogY3B1MCAoQlNQKTogQVBJQyBJRDogIDAKIGNwdTEgKEFQKTog QVBJQyBJRDogIDEKIGNwdTIgKEFQKTogQVBJQyBJRDogIDIKIGNwdTMgKEFQKTogQVBJQyBJRDog IDMKIGNwdTQgKEFQKTogQVBJQyBJRDogIDQKIGNwdTUgKEFQKTogQVBJQyBJRDogIDUKIGNwdTYg KEFQKTogQVBJQyBJRDogIDYKIGNwdTcgKEFQKTogQVBJQyBJRDogIDcKIGNwdTggKEFQKTogQVBJ QyBJRDogMTYKIGNwdTkgKEFQKTogQVBJQyBJRDogMTcKIGNwdTEwIChBUCk6IEFQSUMgSUQ6IDE4 CiBjcHUxMSAoQVApOiBBUElDIElEOiAxOQogY3B1MTIgKEFQKTogQVBJQyBJRDogMjAKIGNwdTEz IChBUCk6IEFQSUMgSUQ6IDIxCiBjcHUxNCAoQVApOiBBUElDIElEOiAyMgogY3B1MTUgKEFQKTog QVBJQyBJRDogMjMKdXNlciBWTUVNIGFjY291bnRpbmcgb24KaW9hcGljMCA8VmVyc2lvbiAyLjA+ IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZAppb2FwaWMxIDxWZXJzaW9uIDIuMD4gaXJxcyAyNC00 NyBvbiBtb3RoZXJib2FyZAprYmQxIGF0IGtiZG11eDAKYXRoX2hhbDogMC45LjIwLjMgKEFSNTIx MCwgQVI1MjExLCBBUjUyMTIsIFJGNTExMSwgUkY1MTEyLCBSRjI0MTMsIFJGNTQxMykKYWNwaTA6 IDxJQk0gVEhVUkxFWT4gb24gbW90aGVyYm9hcmQKYWNwaTA6IFBvd2VyIEJ1dHRvbiAoZml4ZWQp ClRpbWVjb3VudGVyICJIUEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSA5MDAKVGlt ZWNvdW50ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwCmFj cGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4NTg4LTB4NThi IG9uIGFjcGkwCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MTogPEFDUEkgQ1BVPiBvbiBh Y3BpMApjcHUyOiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTM6IDxBQ1BJIENQVT4gb24gYWNwaTAK Y3B1NDogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHU1OiA8QUNQSSBDUFU+IG9uIGFjcGkwCmNwdTY6 IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1NzogPEFDUEkgQ1BVPiBvbiBhY3BpMApjcHU4OiA8QUNQ SSBDUFU+IG9uIGFjcGkwCmNwdTk6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MTA6IDxBQ1BJIENQ VT4gb24gYWNwaTAKY3B1MTE6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MTI6IDxBQ1BJIENQVT4g b24gYWNwaTAKY3B1MTM6IDxBQ1BJIENQVT4gb24gYWNwaTAKY3B1MTQ6IDxBQ1BJIENQVT4gb24g YWNwaTAKY3B1MTU6IDxBQ1BJIENQVT4gb24gYWNwaTAKcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJy aWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3BpMApwY2kwOiA8QUNQSSBQQ0kgYnVzPiBvbiBw Y2liMApwY2liMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGlycSAyOCBhdCBkZXZpY2UgMS4wIG9u IHBjaTAKcGNpMTE6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIxCmJjZTA6IDxCcm9hZGNvbSBOZXRY dHJlbWUgSUkgQkNNNTcwOSAxMDAwQmFzZS1UIChDMCk+IG1lbSAweDkyMDAwMDAwLTB4OTNmZmZm ZmYgaXJxIDI4IGF0IGRldmljZSAwLjAgb24gcGNpMTEKbWlpYnVzMDogPE1JSSBidXM+IG9uIGJj ZTAKYnJncGh5MDogPEJDTTU3MDlDIDEwLzEwMC8xMDAwYmFzZVRYIFBIWT4gb24gbWlpYnVzMApi cmdwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUZEWCwg MTAwMGJhc2VULCAxMDAwYmFzZVQtRkRYLCBhdXRvCmJjZTA6IEV0aGVybmV0IGFkZHJlc3M6IDAw OjIxOjVlOmM2OjVkOjRjCmJjZTA6IEFTSUMgKDB4NTcwOTIwMDMpOyBSZXYgKEMwKTsgQnVzIChQ Q0llIHgyLCA1R2Jwcyk7IEYvVyAoMHgwNTAwMDYwNSk7IEZsYWdzKCBNRlcgKQpiY2UxOiA8QnJv YWRjb20gTmV0WHRyZW1lIElJIEJDTTU3MDkgMTAwMEJhc2UtVCAoQzApPiBtZW0gMHg5NDAwMDAw MC0weDk1ZmZmZmZmIGlycSA0MCBhdCBkZXZpY2UgMC4xIG9uIHBjaTExCm1paWJ1czE6IDxNSUkg YnVzPiBvbiBiY2UxCmJyZ3BoeTE6IDxCQ001NzA5QyAxMC8xMDAvMTAwMGJhc2VUWCBQSFk+IG9u IG1paWJ1czEKYnJncGh5MTogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJh c2VUWC1GRFgsIDEwMDBiYXNlVCwgMTAwMGJhc2VULUZEWCwgYXV0bwpiY2UxOiBFdGhlcm5ldCBh ZGRyZXNzOiAwMDoyMTo1ZTpjNjo1ZDo0ZQpiY2UxOiBBU0lDICgweDU3MDkyMDAzKTsgUmV2IChD MCk7IEJ1cyAoUENJZSB4MiwgNUdicHMpOyBGL1cgKDB4MDUwMDA2MDUpOyBGbGFncyggTUZXICkK cGNpYjI6IDxQQ0ktUENJIGJyaWRnZT4gaXJxIDI5IGF0IGRldmljZSAyLjAgb24gcGNpMApwY2kx NjogPFBDSSBidXM+IG9uIHBjaWIyCnBjaWIzOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDI0 IGF0IGRldmljZSAzLjAgb24gcGNpMApwY2kyMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMKcGNp YjQ6IDxQQ0ktUENJIGJyaWRnZT4gaXJxIDI2IGF0IGRldmljZSA1LjAgb24gcGNpMApwY2kyNjog PFBDSSBidXM+IG9uIHBjaWI0CnBjaWI1OiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gaXJxIDMwIGF0 IGRldmljZSA3LjAgb24gcGNpMApwY2kzMTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjUKcGNpYjY6 IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMzIgYXQgZGV2aWNlIDkuMCBvbiBwY2kwCnBjaTM2 OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liNgpwY2kwOiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRlcnJ1 cHQgY29udHJvbGxlcj4gYXQgZGV2aWNlIDE2LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDog PGJhc2UgcGVyaXBoZXJhbCwgaW50ZXJydXB0IGNvbnRyb2xsZXI+IGF0IGRldmljZSAxNi4xIChu byBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWwsIGludGVycnVwdCBjb250 cm9sbGVyPiBhdCBkZXZpY2UgMTcuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8YmFzZSBw ZXJpcGhlcmFsLCBpbnRlcnJ1cHQgY29udHJvbGxlcj4gYXQgZGV2aWNlIDE3LjEgKG5vIGRyaXZl ciBhdHRhY2hlZCkKcGNpMDogPGJhc2UgcGVyaXBoZXJhbCwgaW50ZXJydXB0IGNvbnRyb2xsZXI+ IGF0IGRldmljZSAyMC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVy YWwsIGludGVycnVwdCBjb250cm9sbGVyPiBhdCBkZXZpY2UgMjAuMSAobm8gZHJpdmVyIGF0dGFj aGVkKQpwY2kwOiA8YmFzZSBwZXJpcGhlcmFsLCBpbnRlcnJ1cHQgY29udHJvbGxlcj4gYXQgZGV2 aWNlIDIwLjIgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPGJhc2UgcGVyaXBoZXJhbCwgaW50 ZXJydXB0IGNvbnRyb2xsZXI+IGF0IGRldmljZSAyMC4zIChubyBkcml2ZXIgYXR0YWNoZWQpCnBj aTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAyMi4wIChubyBkcml2ZXIgYXR0YWNoZWQp CnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAyMi4xIChubyBkcml2ZXIgYXR0YWNo ZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAyMi4yIChubyBkcml2ZXIgYXR0 YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAyMi4zIChubyBkcml2ZXIg YXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAyMi40IChubyBkcml2 ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAyMi41IChubyBk cml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAyMi42IChu byBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxiYXNlIHBlcmlwaGVyYWw+IGF0IGRldmljZSAyMi43 IChubyBkcml2ZXIgYXR0YWNoZWQpCnVoY2kwOiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xs ZXI+IHBvcnQgMHgyMGEwLTB4MjBiZiBpcnEgMTcgYXQgZGV2aWNlIDI2LjAgb24gcGNpMAp1aGNp MDogW0dJQU5ULUxPQ0tFRF0KdXNiMDogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBv biB1aGNpMAp1c2IwOiBVU0IgcmV2aXNpb24gMS4wCnVodWIwOiBJbnRlbCBVSENJIHJvb3QgaHVi LCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQp1aHViMDogMiBwb3J0cyB3aXRoIDIg cmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWhjaTE6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJv bGxlcj4gcG9ydCAweDIwODAtMHgyMDlmIGlycSAxOCBhdCBkZXZpY2UgMjYuMSBvbiBwY2kwCnVo Y2kxOiBbR0lBTlQtTE9DS0VEXQp1c2IxOiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+ IG9uIHVoY2kxCnVzYjE6IFVTQiByZXZpc2lvbiAxLjAKdWh1YjE6IEludGVsIFVIQ0kgcm9vdCBo dWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCnVodWIxOiAyIHBvcnRzIHdpdGgg MiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAplaGNpMDogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAg Y29udHJvbGxlcj4gbWVtIDB4OTdhMjE0MDAtMHg5N2EyMTdmZiBpcnEgMTkgYXQgZGV2aWNlIDI2 Ljcgb24gcGNpMAplaGNpMDogW0dJQU5ULUxPQ0tFRF0KdXNiMjogRUhDSSB2ZXJzaW9uIDEuMAp1 c2IyOiB3cm9uZyBudW1iZXIgb2YgY29tcGFuaW9ucyAoMyAhPSAyKQp1c2IyOiBjb21wYW5pb24g Y29udHJvbGxlcnMsIDIgcG9ydHMgZWFjaDogdXNiMCB1c2IxCnVzYjI6IDxFSENJIChnZW5lcmlj KSBVU0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kwCnVzYjI6IFVTQiByZXZpc2lvbiAyLjAKdWh1 YjI6IEludGVsIEVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAx CnVodWIyOiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApwY2liNzogPFBD SS1QQ0kgYnJpZGdlPiBpcnEgMTYgYXQgZGV2aWNlIDI4LjAgb24gcGNpMApwY2kxOiA8UENJIGJ1 cz4gb24gcGNpYjcKbWZpMDogPExTSSBNZWdhU0FTIDEwNzg+IHBvcnQgMHgxMDAwLTB4MTBmZiBt ZW0gMHg5NzkwMDAwMC0weDk3OTNmZmZmLDB4OTc5NDAwMDAtMHg5Nzk3ZmZmZiBpcnEgMTYgYXQg ZGV2aWNlIDAuMCBvbiBwY2kxCm1maTA6IE1lZ2FyYWlkIFNBUyBkcml2ZXIgVmVyIDIuMDAgCm1m aTA6IDM2MzkgKDMxMjU0Mjg4NHMvMHgwMDIwL2luZm8pIC0gU2h1dGRvd24gY29tbWFuZCByZWNl aXZlZCBmcm9tIGhvc3QKbWZpMDogMzY0MCAoYm9vdCArIDNzLzB4MDAyMC9pbmZvKSAtIEZpcm13 YXJlIGluaXRpYWxpemF0aW9uIHN0YXJ0ZWQgKFBDSSBJRCAwMDYwLzEwMDAvMDM2NC8xMDE0KQpt ZmkwOiAzNjQxIChib290ICsgM3MvMHgwMDIwL2luZm8pIC0gRmlybXdhcmUgdmVyc2lvbiAxLjQw LjYyLTA2OTEKbWZpMDogMzY0MiAoYm9vdCArIDNzLzB4MDAyMC9pbmZvKSAtIEZpcm13YXJlIGlu aXRpYWxpemF0aW9uIHN0YXJ0ZWQgKFBDSSBJRCAwMDYwLzEwMDAvMDM2NC8xMDE0KQptZmkwOiAz NjQzIChib290ICsgM3MvMHgwMDIwL2luZm8pIC0gRmlybXdhcmUgdmVyc2lvbiAxLjQwLjYyLTA2 OTEKbWZpMDogMzY0NCAoYm9vdCArIDY0cy8weDAwMDgvaW5mbykgLSBCYXR0ZXJ5IFByZXNlbnQK bWZpMDogMzY0NSAoYm9vdCArIDY0cy8weDAwMjAvaW5mbykgLSBCQlUgRlJVIGlzIAptZmkwOiAz NjQ2IChib290ICsgNjRzLzB4MDAyMC9pbmZvKSAtIEJvYXJkIFJldmlzaW9uIAptZmkwOiAzNjQ3 IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwOChlMHhmZi9zOCkKbWZp MDogMzY0OCAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMDgoZTB4ZmYv czgpIEluZm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBwb3J0TWFwPTAwLCBzYXNBZGRyPTUw MDBjNTAwMTM4ZDZhYTEsMDAwMDAwMDAwMDAwMDAwMAptZmkwOiAzNjQ5IChib290ICsgODlzLzB4 MDAwMi9pbmZvKSAtIFBEIDA4KGUweGZmL3M4KSBGUlUgaXMgNDJEMDQyMiAgICAgCm1maTA6IDM2 NTAgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDA5KGUweGZmL3M5KQpt ZmkwOiAzNjUxIChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwOShlMHhm Zi9zOSkgSW5mbzogZW5jbFBkPWZmZmYsIHNjc2lUeXBlPTAsIHBvcnRNYXA9MDEsIHNhc0FkZHI9 NTAwMGM1MDAxMzhkODY2MSwwMDAwMDAwMDAwMDAwMDAwCm1maTA6IDM2NTIgKGJvb3QgKyA4OXMv MHgwMDAyL2luZm8pIC0gUEQgMDkoZTB4ZmYvczkpIEZSVSBpcyA0MkQwNDIyICAgICAKbWZpMDog MzY1MyAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMGEoZTB4ZmYvczEw KQptZmkwOiAzNjU0IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwYShl MHhmZi9zMTApIEluZm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBwb3J0TWFwPTA0LCBzYXNB ZGRyPTUwMDBjNTAwMTM4ZDY1OTksMDAwMDAwMDAwMDAwMDAwMAptZmkwOiAzNjU1IChib290ICsg ODlzLzB4MDAwMi9pbmZvKSAtIFBEIDBhKGUweGZmL3MxMCkgRlJVIGlzIDQyRDA0MjIgICAgIApt ZmkwOiAzNjU2IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwYihlMHhm Zi9zMTEpCm1maTA6IDM2NTcgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBE IDBiKGUweGZmL3MxMSkgSW5mbzogZW5jbFBkPWZmZmYsIHNjc2lUeXBlPTAsIHBvcnRNYXA9MDUs IHNhc0FkZHI9NTAwMGM1MDAxMzhkNjIwNSwwMDAwMDAwMDAwMDAwMDAwCm1maTA6IDM2NTggKGJv b3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gUEQgMGIoZTB4ZmYvczExKSBGUlUgaXMgNDJEMDQyMiAg ICAgCm1maTA6IDM2NTkgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBj KGUweGZmL3MxMikKbWZpMDogMzY2MCAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRl ZDogUEQgMGMoZTB4ZmYvczEyKSBJbmZvOiBlbmNsUGQ9ZmZmZiwgc2NzaVR5cGU9MCwgcG9ydE1h cD0wMiwgc2FzQWRkcj01MDAwYzUwMDEzOGQ2YWRkLDAwMDAwMDAwMDAwMDAwMDAKbWZpMDogMzY2 MSAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBQRCAwYyhlMHhmZi9zMTIpIEZSVSBpcyA0MkQw NDIyICAgICAKbWZpMDogMzY2MiAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDog UEQgMGQoZTB4ZmYvczEzKQptZmkwOiAzNjYzIChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIElu c2VydGVkOiBQRCAwZChlMHhmZi9zMTMpIEluZm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBw b3J0TWFwPTAzLCBzYXNBZGRyPTUwMDBjNTAwMTM4YzQ2NTEsMDAwMDAwMDAwMDAwMDAwMAptZmkw OiAzNjY0IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIFBEIDBkKGUweGZmL3MxMykgRlJVIGlz IDQyRDA0MjIgICAgIAptZmkwOiAzNjY1IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2Vy dGVkOiBQRCAwZShlMHhmZi9zMTQpCm1maTA6IDM2NjYgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8p IC0gSW5zZXJ0ZWQ6IFBEIDBlKGUweGZmL3MxNCkgSW5mbzogZW5jbFBkPWZmZmYsIHNjc2lUeXBl PTAsIHBvcnRNYXA9MDYsIHNhc0FkZHI9NTAwMGM1MDAxMzhkNWRlNSwwMDAwMDAwMDAwMDAwMDAw Cm1maTA6IDM2NjcgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gUEQgMGUoZTB4ZmYvczE0KSBG UlUgaXMgNDJEMDQyMiAgICAgCm1maTA6IDM2NjggKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0g SW5zZXJ0ZWQ6IFBEIDBmKGUweGZmL3MxNSkKbWZpMDogMzY2OSAoYm9vdCArIDg5cy8weDAwMDIv aW5mbykgLSBJbnNlcnRlZDogUEQgMGYoZTB4ZmYvczE1KSBJbmZvOiBlbmNsUGQ9ZmZmZiwgc2Nz aVR5cGU9MCwgcG9ydE1hcD0wNywgc2FzQWRkcj01MDAwYzUwMDEzOGQ2MWYxLDAwMDAwMDAwMDAw MDAwMDAKbWZpMDogMzY3MCAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBQRCAwZihlMHhmZi9z MTUpIEZSVSBpcyA0MkQwNDIyICAgICAKbWZpMDogMzY3MSAoYm9vdCArIDE0NHMvMHgwMDA4L2lu Zm8pIC0gQmF0dGVyeSBzdGFydGVkIGNoYXJnaW5nCm1maTA6IDM2NzIgKGJvb3QgKyAxNDRzLzB4 MDAwOC9pbmZvKSAtIEJhdHRlcnkgdGVtcGVyYXR1cmUgaXMgbm9ybWFsCm1maTA6IDM2NzMgKDMx MjU0MzEyNXMvMHgwMDIwL2luZm8pIC0gVGltZSBlc3RhYmxpc2hlZCBhcyAxMS8yNi8wOSAgOToz MjowNTsgKDIwOCBzZWNvbmRzIHNpbmNlIHBvd2VyIG9uKQptZmkwOiAzNjc0ICgzMTI1NDMyNTZz LzB4MDAwOC9pbmZvKSAtIEJhdHRlcnkgY2hhcmdlIGNvbXBsZXRlCm1maTA6IDM2NzUgKGJvb3Qg KyAzcy8weDAwMjAvaW5mbykgLSBGaXJtd2FyZSBpbml0aWFsaXphdGlvbiBzdGFydGVkIChQQ0kg SUQgMDA2MC8xMDAwLzAzNjQvMTAxNCkKbWZpMDogMzY3NiAoYm9vdCArIDNzLzB4MDAyMC9pbmZv KSAtIEZpcm13YXJlIHZlcnNpb24gMS40MC42Mi0wNjkxCm1maTA6IDM2NzcgKGJvb3QgKyAzcy8w eDAwMjAvaW5mbykgLSBGaXJtd2FyZSBpbml0aWFsaXphdGlvbiBzdGFydGVkIChQQ0kgSUQgMDA2 MC8xMDAwLzAzNjQvMTAxNCkKbWZpMDogMzY3OCAoYm9vdCArIDNzLzB4MDAyMC9pbmZvKSAtIEZp cm13YXJlIHZlcnNpb24gMS40MC42Mi0wNjkxCm1maTA6IDM2NzkgKGJvb3QgKyA2NHMvMHgwMDA4 L2luZm8pIC0gQmF0dGVyeSBQcmVzZW50Cm1maTA6IDM2ODAgKGJvb3QgKyA2NHMvMHgwMDIwL2lu Zm8pIC0gQkJVIEZSVSBpcyAKbWZpMDogMzY4MSAoYm9vdCArIDY0cy8weDAwMjAvaW5mbykgLSBC b2FyZCBSZXZpc2lvbiAKbWZpMDogMzY4MiAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNl cnRlZDogUEQgMDgoZTB4ZmYvczgpCm1maTA6IDM2ODMgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8p IC0gSW5zZXJ0ZWQ6IFBEIDA4KGUweGZmL3M4KSBJbmZvOiBlbmNsUGQ9ZmZmZiwgc2NzaVR5cGU9 MCwgcG9ydE1hcD0wMCwgc2FzQWRkcj01MDAwYzUwMDEzOGQ2YWExLDAwMDAwMDAwMDAwMDAwMDAK bWZpMDogMzY4NCAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBQRCAwOChlMHhmZi9zOCkgRlJV IGlzIDQyRDA0MjIgICAgIAptZmkwOiAzNjg1IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIElu c2VydGVkOiBQRCAwOShlMHhmZi9zOSkKbWZpMDogMzY4NiAoYm9vdCArIDg5cy8weDAwMDIvaW5m bykgLSBJbnNlcnRlZDogUEQgMDkoZTB4ZmYvczkpIEluZm86IGVuY2xQZD1mZmZmLCBzY3NpVHlw ZT0wLCBwb3J0TWFwPTAxLCBzYXNBZGRyPTUwMDBjNTAwMTM4ZDg2NjEsMDAwMDAwMDAwMDAwMDAw MAptZmkwOiAzNjg3IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIFBEIDA5KGUweGZmL3M5KSBG UlUgaXMgNDJEMDQyMiAgICAgCm1maTA6IDM2ODggKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0g SW5zZXJ0ZWQ6IFBEIDBhKGUweGZmL3MxMCkKbWZpMDogMzY4OSAoYm9vdCArIDg5cy8weDAwMDIv aW5mbykgLSBJbnNlcnRlZDogUEQgMGEoZTB4ZmYvczEwKSBJbmZvOiBlbmNsUGQ9ZmZmZiwgc2Nz aVR5cGU9MCwgcG9ydE1hcD0wNCwgc2FzQWRkcj01MDAwYzUwMDEzOGQ2NTk5LDAwMDAwMDAwMDAw MDAwMDAKbWZpMDogMzY5MCAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBQRCAwYShlMHhmZi9z MTApIEZSVSBpcyA0MkQwNDIyICAgICAKbWZpMDogMzY5MSAoYm9vdCArIDg5cy8weDAwMDIvaW5m bykgLSBJbnNlcnRlZDogUEQgMGIoZTB4ZmYvczExKQptZmkwOiAzNjkyIChib290ICsgODlzLzB4 MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwYihlMHhmZi9zMTEpIEluZm86IGVuY2xQZD1mZmZm LCBzY3NpVHlwZT0wLCBwb3J0TWFwPTA1LCBzYXNBZGRyPTUwMDBjNTAwMTM4ZDYyMDUsMDAwMDAw MDAwMDAwMDAwMAptZmkwOiAzNjkzIChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIFBEIDBiKGUw eGZmL3MxMSkgRlJVIGlzIDQyRDA0MjIgICAgIAptZmkwOiAzNjk0IChib290ICsgODlzLzB4MDAw Mi9pbmZvKSAtIEluc2VydGVkOiBQRCAwYyhlMHhmZi9zMTIpCm1maTA6IDM2OTUgKGJvb3QgKyA4 OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBjKGUweGZmL3MxMikgSW5mbzogZW5jbFBk PWZmZmYsIHNjc2lUeXBlPTAsIHBvcnRNYXA9MDIsIHNhc0FkZHI9NTAwMGM1MDAxMzhkNmFkZCww MDAwMDAwMDAwMDAwMDAwCm1maTA6IDM2OTYgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gUEQg MGMoZTB4ZmYvczEyKSBGUlUgaXMgNDJEMDQyMiAgICAgCm1maTA6IDM2OTcgKGJvb3QgKyA4OXMv MHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBkKGUweGZmL3MxMykKbWZpMDogMzY5OCAoYm9v dCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMGQoZTB4ZmYvczEzKSBJbmZvOiBl bmNsUGQ9ZmZmZiwgc2NzaVR5cGU9MCwgcG9ydE1hcD0wMywgc2FzQWRkcj01MDAwYzUwMDEzOGM0 NjUxLDAwMDAwMDAwMDAwMDAwMDAKbWZpMDogMzY5OSAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykg LSBQRCAwZChlMHhmZi9zMTMpIEZSVSBpcyA0MkQwNDIyICAgICAKbWZpMDogMzcwMCAoYm9vdCAr IDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMGUoZTB4ZmYvczE0KQptZmkwOiAzNzAx IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwZShlMHhmZi9zMTQpIElu Zm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBwb3J0TWFwPTA2LCBzYXNBZGRyPTUwMDBjNTAw MTM4ZDVkZTUsMDAwMDAwMDAwMDAwMDAwMAptZmkwOiAzNzAyIChib290ICsgODlzLzB4MDAwMi9p bmZvKSAtIFBEIDBlKGUweGZmL3MxNCkgRlJVIGlzIDQyRDA0MjIgICAgIAptZmkwOiAzNzAzIChi b290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwZihlMHhmZi9zMTUpCm1maTA6 IDM3MDQgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBmKGUweGZmL3Mx NSkgSW5mbzogZW5jbFBkPWZmZmYsIHNjc2lUeXBlPTAsIHBvcnRNYXA9MDcsIHNhc0FkZHI9NTAw MGM1MDAxMzhkNjFmMSwwMDAwMDAwMDAwMDAwMDAwCm1maTA6IDM3MDUgKGJvb3QgKyA4OXMvMHgw MDAyL2luZm8pIC0gUEQgMGYoZTB4ZmYvczE1KSBGUlUgaXMgNDJEMDQyMiAgICAgCm1maTA6IDM3 MDYgKGJvb3QgKyAxNDRzLzB4MDAwOC9pbmZvKSAtIEJhdHRlcnkgdGVtcGVyYXR1cmUgaXMgbm9y bWFsCm1maTA6IDM3MDcgKDMxMjU0MzUzNnMvMHgwMDIwL2luZm8pIC0gVGltZSBlc3RhYmxpc2hl ZCBhcyAxMS8yNi8wOSAgOTozODo1NjsgKDIxMiBzZWNvbmRzIHNpbmNlIHBvd2VyIG9uKQptZmkw OiAzNzA4IChib290ICsgM3MvMHgwMDIwL2luZm8pIC0gRmlybXdhcmUgaW5pdGlhbGl6YXRpb24g c3RhcnRlZCAoUENJIElEIDAwNjAvMTAwMC8wMzY0LzEwMTQpCm1maTA6IDM3MDkgKGJvb3QgKyAz cy8weDAwMjAvaW5mbykgLSBGaXJtd2FyZSB2ZXJzaW9uIDEuNDAuNjItMDY5MQptZmkwOiAzNzEw IChib290ICsgM3MvMHgwMDIwL2luZm8pIC0gRmlybXdhcmUgaW5pdGlhbGl6YXRpb24gc3RhcnRl ZCAoUENJIElEIDAwNjAvMTAwMC8wMzY0LzEwMTQpCm1maTA6IDM3MTEgKGJvb3QgKyAzcy8weDAw MjAvaW5mbykgLSBGaXJtd2FyZSB2ZXJzaW9uIDEuNDAuNjItMDY5MQptZmkwOiAzNzEyIChib290 ICsgNjRzLzB4MDAwOC9pbmZvKSAtIEJhdHRlcnkgUHJlc2VudAptZmkwOiAzNzEzIChib290ICsg NjRzLzB4MDAyMC9pbmZvKSAtIEJCVSBGUlUgaXMgCm1maTA6IDM3MTQgKGJvb3QgKyA2NHMvMHgw MDIwL2luZm8pIC0gQm9hcmQgUmV2aXNpb24gCm1maTA6IDM3MTUgKGJvb3QgKyA4OXMvMHgwMDAy L2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDA4KGUweGZmL3M4KQptZmkwOiAzNzE2IChib290ICsgODlz LzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwOChlMHhmZi9zOCkgSW5mbzogZW5jbFBkPWZm ZmYsIHNjc2lUeXBlPTAsIHBvcnRNYXA9MDAsIHNhc0FkZHI9NTAwMGM1MDAxMzhkNmFhMSwwMDAw MDAwMDAwMDAwMDAwCm1maTA6IDM3MTcgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gUEQgMDgo ZTB4ZmYvczgpIEZSVSBpcyA0MkQwNDIyICAgICAKbWZpMDogMzcxOCAoYm9vdCArIDg5cy8weDAw MDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMDkoZTB4ZmYvczkpCm1maTA6IDM3MTkgKGJvb3QgKyA4 OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDA5KGUweGZmL3M5KSBJbmZvOiBlbmNsUGQ9 ZmZmZiwgc2NzaVR5cGU9MCwgcG9ydE1hcD0wMSwgc2FzQWRkcj01MDAwYzUwMDEzOGQ4NjYxLDAw MDAwMDAwMDAwMDAwMDAKbWZpMDogMzcyMCAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBQRCAw OShlMHhmZi9zOSkgRlJVIGlzIDQyRDA0MjIgICAgIAptZmkwOiAzNzIxIChib290ICsgODlzLzB4 MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwYShlMHhmZi9zMTApCm1maTA6IDM3MjIgKGJvb3Qg KyA4OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBhKGUweGZmL3MxMCkgSW5mbzogZW5j bFBkPWZmZmYsIHNjc2lUeXBlPTAsIHBvcnRNYXA9MDQsIHNhc0FkZHI9NTAwMGM1MDAxMzhkNjU5 OSwwMDAwMDAwMDAwMDAwMDAwCm1maTA6IDM3MjMgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0g UEQgMGEoZTB4ZmYvczEwKSBGUlUgaXMgNDJEMDQyMiAgICAgCm1maTA6IDM3MjQgKGJvb3QgKyA4 OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBiKGUweGZmL3MxMSkKbWZpMDogMzcyNSAo Ym9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMGIoZTB4ZmYvczExKSBJbmZv OiBlbmNsUGQ9ZmZmZiwgc2NzaVR5cGU9MCwgcG9ydE1hcD0wNSwgc2FzQWRkcj01MDAwYzUwMDEz OGQ2MjA1LDAwMDAwMDAwMDAwMDAwMDAKbWZpMDogMzcyNiAoYm9vdCArIDg5cy8weDAwMDIvaW5m bykgLSBQRCAwYihlMHhmZi9zMTEpIEZSVSBpcyA0MkQwNDIyICAgICAKbWZpMDogMzcyNyAoYm9v dCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMGMoZTB4ZmYvczEyKQptZmkwOiAz NzI4IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwYyhlMHhmZi9zMTIp IEluZm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBwb3J0TWFwPTAyLCBzYXNBZGRyPTUwMDBj NTAwMTM4ZDZhZGQsMDAwMDAwMDAwMDAwMDAwMAptZmkwOiAzNzI5IChib290ICsgODlzLzB4MDAw Mi9pbmZvKSAtIFBEIDBjKGUweGZmL3MxMikgRlJVIGlzIDQyRDA0MjIgICAgIAptZmkwOiAzNzMw IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwZChlMHhmZi9zMTMpCm1m aTA6IDM3MzEgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBkKGUweGZm L3MxMykgSW5mbzogZW5jbFBkPWZmZmYsIHNjc2lUeXBlPTAsIHBvcnRNYXA9MDMsIHNhc0FkZHI9 NTAwMGM1MDAxMzhjNDY1MSwwMDAwMDAwMDAwMDAwMDAwCm1maTA6IDM3MzIgKGJvb3QgKyA4OXMv MHgwMDAyL2luZm8pIC0gUEQgMGQoZTB4ZmYvczEzKSBGUlUgaXMgNDJEMDQyMiAgICAgCm1maTA6 IDM3MzMgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBlKGUweGZmL3Mx NCkKbWZpMDogMzczNCAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMGUo ZTB4ZmYvczE0KSBJbmZvOiBlbmNsUGQ9ZmZmZiwgc2NzaVR5cGU9MCwgcG9ydE1hcD0wNiwgc2Fz QWRkcj01MDAwYzUwMDEzOGQ1ZGU1LDAwMDAwMDAwMDAwMDAwMDAKbWZpMDogMzczNSAoYm9vdCAr IDg5cy8weDAwMDIvaW5mbykgLSBQRCAwZShlMHhmZi9zMTQpIEZSVSBpcyA0MkQwNDIyICAgICAK bWZpMDogMzczNiAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMGYoZTB4 ZmYvczE1KQptZmkwOiAzNzM3IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQ RCAwZihlMHhmZi9zMTUpIEluZm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBwb3J0TWFwPTA3 LCBzYXNBZGRyPTUwMDBjNTAwMTM4ZDYxZjEsMDAwMDAwMDAwMDAwMDAwMAptZmkwOiAzNzM4IChi b290ICsgODlzLzB4MDAwMi9pbmZvKSAtIFBEIDBmKGUweGZmL3MxNSkgRlJVIGlzIDQyRDA0MjIg ICAgIAptZmkwOiAzNzM5IChib290ICsgMTQ0cy8weDAwMDgvaW5mbykgLSBCYXR0ZXJ5IHRlbXBl cmF0dXJlIGlzIG5vcm1hbAptZmkwOiAzNzQwICgzMTI1NDM5ODBzLzB4MDAyMC9pbmZvKSAtIFRp bWUgZXN0YWJsaXNoZWQgYXMgMTEvMjYvMDkgIDk6NDY6MjA7ICgyMTEgc2Vjb25kcyBzaW5jZSBw b3dlciBvbikKbWZpMDogMzc0MSAoYm9vdCArIDNzLzB4MDAyMC9pbmZvKSAtIEZpcm13YXJlIGlu aXRpYWxpemF0aW9uIHN0YXJ0ZWQgKFBDSSBJRCAwMDYwLzEwMDAvMDM2NC8xMDE0KQptZmkwOiAz NzQyIChib290ICsgM3MvMHgwMDIwL2luZm8pIC0gRmlybXdhcmUgdmVyc2lvbiAxLjQwLjYyLTA2 OTEKbWZpMDogMzc0MyAoYm9vdCArIDNzLzB4MDAyMC9pbmZvKSAtIEZpcm13YXJlIGluaXRpYWxp emF0aW9uIHN0YXJ0ZWQgKFBDSSBJRCAwMDYwLzEwMDAvMDM2NC8xMDE0KQptZmkwOiAzNzQ0IChi b290ICsgM3MvMHgwMDIwL2luZm8pIC0gRmlybXdhcmUgdmVyc2lvbiAxLjQwLjYyLTA2OTEKbWZp MDogMzc0NSAoYm9vdCArIDY0cy8weDAwMDgvaW5mbykgLSBCYXR0ZXJ5IFByZXNlbnQKbWZpMDog Mzc0NiAoYm9vdCArIDY0cy8weDAwMjAvaW5mbykgLSBCQlUgRlJVIGlzIAptZmkwOiAzNzQ3IChi b290ICsgNjRzLzB4MDAyMC9pbmZvKSAtIEJvYXJkIFJldmlzaW9uIAptZmkwOiAzNzQ4IChib290 ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwOChlMHhmZi9zOCkKbWZpMDogMzc0 OSAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMDgoZTB4ZmYvczgpIElu Zm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBwb3J0TWFwPTAwLCBzYXNBZGRyPTUwMDBjNTAw MTM4ZDZhYTEsMDAwMDAwMDAwMDAwMDAwMAptZmkwOiAzNzUwIChib290ICsgODlzLzB4MDAwMi9p bmZvKSAtIFBEIDA4KGUweGZmL3M4KSBGUlUgaXMgNDJEMDQyMiAgICAgCm1maTA6IDM3NTEgKGJv b3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDA5KGUweGZmL3M5KQptZmkwOiAz NzUyIChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwOShlMHhmZi9zOSkg SW5mbzogZW5jbFBkPWZmZmYsIHNjc2lUeXBlPTAsIHBvcnRNYXA9MDEsIHNhc0FkZHI9NTAwMGM1 MDAxMzhkODY2MSwwMDAwMDAwMDAwMDAwMDAwCm1maTA6IDM3NTMgKGJvb3QgKyA4OXMvMHgwMDAy L2luZm8pIC0gUEQgMDkoZTB4ZmYvczkpIEZSVSBpcyA0MkQwNDIyICAgICAKbWZpMDogMzc1NCAo Ym9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMGEoZTB4ZmYvczEwKQptZmkw OiAzNzU1IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwYShlMHhmZi9z MTApIEluZm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBwb3J0TWFwPTA0LCBzYXNBZGRyPTUw MDBjNTAwMTM4ZDY1OTksMDAwMDAwMDAwMDAwMDAwMAptZmkwOiAzNzU2IChib290ICsgODlzLzB4 MDAwMi9pbmZvKSAtIFBEIDBhKGUweGZmL3MxMCkgRlJVIGlzIDQyRDA0MjIgICAgIAptZmkwOiAz NzU3IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwYihlMHhmZi9zMTEp Cm1maTA6IDM3NTggKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBiKGUw eGZmL3MxMSkgSW5mbzogZW5jbFBkPWZmZmYsIHNjc2lUeXBlPTAsIHBvcnRNYXA9MDUsIHNhc0Fk ZHI9NTAwMGM1MDAxMzhkNjIwNSwwMDAwMDAwMDAwMDAwMDAwCm1maTA6IDM3NTkgKGJvb3QgKyA4 OXMvMHgwMDAyL2luZm8pIC0gUEQgMGIoZTB4ZmYvczExKSBGUlUgaXMgNDJEMDQyMiAgICAgCm1m aTA6IDM3NjAgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBjKGUweGZm L3MxMikKbWZpMDogMzc2MSAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQg MGMoZTB4ZmYvczEyKSBJbmZvOiBlbmNsUGQ9ZmZmZiwgc2NzaVR5cGU9MCwgcG9ydE1hcD0wMiwg c2FzQWRkcj01MDAwYzUwMDEzOGQ2YWRkLDAwMDAwMDAwMDAwMDAwMDAKbWZpMDogMzc2MiAoYm9v dCArIDg5cy8weDAwMDIvaW5mbykgLSBQRCAwYyhlMHhmZi9zMTIpIEZSVSBpcyA0MkQwNDIyICAg ICAKbWZpMDogMzc2MyAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMGQo ZTB4ZmYvczEzKQptZmkwOiAzNzY0IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVk OiBQRCAwZChlMHhmZi9zMTMpIEluZm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBwb3J0TWFw PTAzLCBzYXNBZGRyPTUwMDBjNTAwMTM4YzQ2NTEsMDAwMDAwMDAwMDAwMDAwMAptZmkwOiAzNzY1 IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIFBEIDBkKGUweGZmL3MxMykgRlJVIGlzIDQyRDA0 MjIgICAgIAptZmkwOiAzNzY2IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQ RCAwZShlMHhmZi9zMTQpCm1maTA6IDM3NjcgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gSW5z ZXJ0ZWQ6IFBEIDBlKGUweGZmL3MxNCkgSW5mbzogZW5jbFBkPWZmZmYsIHNjc2lUeXBlPTAsIHBv cnRNYXA9MDYsIHNhc0FkZHI9NTAwMGM1MDAxMzhkNWRlNSwwMDAwMDAwMDAwMDAwMDAwCm1maTA6 IDM3NjggKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gUEQgMGUoZTB4ZmYvczE0KSBGUlUgaXMg NDJEMDQyMiAgICAgCm1maTA6IDM3NjkgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0 ZWQ6IFBEIDBmKGUweGZmL3MxNSkKbWZpMDogMzc3MCAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykg LSBJbnNlcnRlZDogUEQgMGYoZTB4ZmYvczE1KSBJbmZvOiBlbmNsUGQ9ZmZmZiwgc2NzaVR5cGU9 MCwgcG9ydE1hcD0wNywgc2FzQWRkcj01MDAwYzUwMDEzOGQ2MWYxLDAwMDAwMDAwMDAwMDAwMDAK bWZpMDogMzc3MSAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBQRCAwZihlMHhmZi9zMTUpIEZS VSBpcyA0MkQwNDIyICAgICAKbWZpMDogMzc3MiAoYm9vdCArIDE0NHMvMHgwMDA4L2luZm8pIC0g QmF0dGVyeSB0ZW1wZXJhdHVyZSBpcyBub3JtYWwKbWZpMDogMzc3MyAoMzEyNTQ0MzI1cy8weDAw MjAvaW5mbykgLSBUaW1lIGVzdGFibGlzaGVkIGFzIDExLzI2LzA5ICA5OjUyOjA1OyAoMjAwIHNl Y29uZHMgc2luY2UgcG93ZXIgb24pCm1maTA6IDM3NzQgKGJvb3QgKyAzcy8weDAwMjAvaW5mbykg LSBGaXJtd2FyZSBpbml0aWFsaXphdGlvbiBzdGFydGVkIChQQ0kgSUQgMDA2MC8xMDAwLzAzNjQv MTAxNCkKbWZpMDogMzc3NSAoYm9vdCArIDNzLzB4MDAyMC9pbmZvKSAtIEZpcm13YXJlIHZlcnNp b24gMS40MC42Mi0wNjkxCm1maTA6IDM3NzYgKGJvb3QgKyAzcy8weDAwMjAvaW5mbykgLSBGaXJt d2FyZSBpbml0aWFsaXphdGlvbiBzdGFydGVkIChQQ0kgSUQgMDA2MC8xMDAwLzAzNjQvMTAxNCkK bWZpMDogMzc3NyAoYm9vdCArIDNzLzB4MDAyMC9pbmZvKSAtIEZpcm13YXJlIHZlcnNpb24gMS40 MC42Mi0wNjkxCm1maTA6IDM3NzggKGJvb3QgKyA2NHMvMHgwMDA4L2luZm8pIC0gQmF0dGVyeSBQ cmVzZW50Cm1maTA6IDM3NzkgKGJvb3QgKyA2NHMvMHgwMDIwL2luZm8pIC0gQkJVIEZSVSBpcyAK bWZpMDogMzc4MCAoYm9vdCArIDY0cy8weDAwMjAvaW5mbykgLSBCb2FyZCBSZXZpc2lvbiAKbWZp MDogMzc4MSAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMDgoZTB4ZmYv czgpCm1maTA6IDM3ODIgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDA4 KGUweGZmL3M4KSBJbmZvOiBlbmNsUGQ9ZmZmZiwgc2NzaVR5cGU9MCwgcG9ydE1hcD0wMCwgc2Fz QWRkcj01MDAwYzUwMDEzOGQ2YWExLDAwMDAwMDAwMDAwMDAwMDAKbWZpMDogMzc4MyAoYm9vdCAr IDg5cy8weDAwMDIvaW5mbykgLSBQRCAwOChlMHhmZi9zOCkgRlJVIGlzIDQyRDA0MjIgICAgIApt ZmkwOiAzNzg0IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwOShlMHhm Zi9zOSkKbWZpMDogMzc4NSAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQg MDkoZTB4ZmYvczkpIEluZm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBwb3J0TWFwPTAxLCBz YXNBZGRyPTUwMDBjNTAwMTM4ZDg2NjEsMDAwMDAwMDAwMDAwMDAwMAptZmkwOiAzNzg2IChib290 ICsgODlzLzB4MDAwMi9pbmZvKSAtIFBEIDA5KGUweGZmL3M5KSBGUlUgaXMgNDJEMDQyMiAgICAg Cm1maTA6IDM3ODcgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBhKGUw eGZmL3MxMCkKbWZpMDogMzc4OCAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDog UEQgMGEoZTB4ZmYvczEwKSBJbmZvOiBlbmNsUGQ9ZmZmZiwgc2NzaVR5cGU9MCwgcG9ydE1hcD0w NCwgc2FzQWRkcj01MDAwYzUwMDEzOGQ2NTk5LDAwMDAwMDAwMDAwMDAwMDAKbWZpMDogMzc4OSAo Ym9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBQRCAwYShlMHhmZi9zMTApIEZSVSBpcyA0MkQwNDIy ICAgICAKbWZpMDogMzc5MCAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQg MGIoZTB4ZmYvczExKQptZmkwOiAzNzkxIChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2Vy dGVkOiBQRCAwYihlMHhmZi9zMTEpIEluZm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBwb3J0 TWFwPTA1LCBzYXNBZGRyPTUwMDBjNTAwMTM4ZDYyMDUsMDAwMDAwMDAwMDAwMDAwMAptZmkwOiAz NzkyIChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIFBEIDBiKGUweGZmL3MxMSkgRlJVIGlzIDQy RDA0MjIgICAgIAptZmkwOiAzNzkzIChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVk OiBQRCAwYyhlMHhmZi9zMTIpCm1maTA6IDM3OTQgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0g SW5zZXJ0ZWQ6IFBEIDBjKGUweGZmL3MxMikgSW5mbzogZW5jbFBkPWZmZmYsIHNjc2lUeXBlPTAs IHBvcnRNYXA9MDIsIHNhc0FkZHI9NTAwMGM1MDAxMzhkNmFkZCwwMDAwMDAwMDAwMDAwMDAwCm1m aTA6IDM3OTUgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gUEQgMGMoZTB4ZmYvczEyKSBGUlUg aXMgNDJEMDQyMiAgICAgCm1maTA6IDM3OTYgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gSW5z ZXJ0ZWQ6IFBEIDBkKGUweGZmL3MxMykKbWZpMDogMzc5NyAoYm9vdCArIDg5cy8weDAwMDIvaW5m bykgLSBJbnNlcnRlZDogUEQgMGQoZTB4ZmYvczEzKSBJbmZvOiBlbmNsUGQ9ZmZmZiwgc2NzaVR5 cGU9MCwgcG9ydE1hcD0wMywgc2FzQWRkcj01MDAwYzUwMDEzOGM0NjUxLDAwMDAwMDAwMDAwMDAw MDAKbWZpMDogMzc5OCAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBQRCAwZChlMHhmZi9zMTMp IEZSVSBpcyA0MkQwNDIyICAgICAKbWZpMDogMzc5OSAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykg LSBJbnNlcnRlZDogUEQgMGUoZTB4ZmYvczE0KQptZmkwOiAzODAwIChib290ICsgODlzLzB4MDAw Mi9pbmZvKSAtIEluc2VydGVkOiBQRCAwZShlMHhmZi9zMTQpIEluZm86IGVuY2xQZD1mZmZmLCBz Y3NpVHlwZT0wLCBwb3J0TWFwPTA2LCBzYXNBZGRyPTUwMDBjNTAwMTM4ZDVkZTUsMDAwMDAwMDAw MDAwMDAwMAptZmkwOiAzODAxIChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIFBEIDBlKGUweGZm L3MxNCkgRlJVIGlzIDQyRDA0MjIgICAgIAptZmkwOiAzODAyIChib290ICsgODlzLzB4MDAwMi9p bmZvKSAtIEluc2VydGVkOiBQRCAwZihlMHhmZi9zMTUpCm1maTA6IDM4MDMgKGJvb3QgKyA4OXMv MHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBmKGUweGZmL3MxNSkgSW5mbzogZW5jbFBkPWZm ZmYsIHNjc2lUeXBlPTAsIHBvcnRNYXA9MDcsIHNhc0FkZHI9NTAwMGM1MDAxMzhkNjFmMSwwMDAw MDAwMDAwMDAwMDAwCm1maTA6IDM4MDQgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gUEQgMGYo ZTB4ZmYvczE1KSBGUlUgaXMgNDJEMDQyMiAgICAgCm1maTA6IDM4MDUgKGJvb3QgKyAxNDRzLzB4 MDAwOC9pbmZvKSAtIEJhdHRlcnkgdGVtcGVyYXR1cmUgaXMgbm9ybWFsCm1maTA6IDM4MDYgKDMx MjU0NDY3NnMvMHgwMDIwL2luZm8pIC0gVGltZSBlc3RhYmxpc2hlZCBhcyAxMS8yNi8wOSAgOTo1 Nzo1NjsgKDIwMSBzZWNvbmRzIHNpbmNlIHBvd2VyIG9uKQptZmkwOiAzODA3IChib290ICsgM3Mv MHgwMDIwL2luZm8pIC0gRmlybXdhcmUgaW5pdGlhbGl6YXRpb24gc3RhcnRlZCAoUENJIElEIDAw NjAvMTAwMC8wMzY0LzEwMTQpCm1maTA6IDM4MDggKGJvb3QgKyAzcy8weDAwMjAvaW5mbykgLSBG aXJtd2FyZSB2ZXJzaW9uIDEuNDAuNjItMDY5MQptZmkwOiAzODA5IChib290ICsgM3MvMHgwMDIw L2luZm8pIC0gRmlybXdhcmUgaW5pdGlhbGl6YXRpb24gc3RhcnRlZCAoUENJIElEIDAwNjAvMTAw MC8wMzY0LzEwMTQpCm1maTA6IDM4MTAgKGJvb3QgKyAzcy8weDAwMjAvaW5mbykgLSBGaXJtd2Fy ZSB2ZXJzaW9uIDEuNDAuNjItMDY5MQptZmkwOiAzODExIChib290ICsgNjRzLzB4MDAwOC9pbmZv KSAtIEJhdHRlcnkgUHJlc2VudAptZmkwOiAzODEyIChib290ICsgNjRzLzB4MDAyMC9pbmZvKSAt IEJCVSBGUlUgaXMgCm1maTA6IDM4MTMgKGJvb3QgKyA2NHMvMHgwMDIwL2luZm8pIC0gQm9hcmQg UmV2aXNpb24gCm1maTA6IDM4MTQgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6 IFBEIDA4KGUweGZmL3M4KQptZmkwOiAzODE1IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIElu c2VydGVkOiBQRCAwOChlMHhmZi9zOCkgSW5mbzogZW5jbFBkPWZmZmYsIHNjc2lUeXBlPTAsIHBv cnRNYXA9MDAsIHNhc0FkZHI9NTAwMGM1MDAxMzhkNmFhMSwwMDAwMDAwMDAwMDAwMDAwCm1maTA6 IDM4MTYgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gUEQgMDgoZTB4ZmYvczgpIEZSVSBpcyA0 MkQwNDIyICAgICAKbWZpMDogMzgxNyAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRl ZDogUEQgMDkoZTB4ZmYvczkpCm1maTA6IDM4MTggKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0g SW5zZXJ0ZWQ6IFBEIDA5KGUweGZmL3M5KSBJbmZvOiBlbmNsUGQ9ZmZmZiwgc2NzaVR5cGU9MCwg cG9ydE1hcD0wMSwgc2FzQWRkcj01MDAwYzUwMDEzOGQ4NjYxLDAwMDAwMDAwMDAwMDAwMDAKbWZp MDogMzgxOSAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBQRCAwOShlMHhmZi9zOSkgRlJVIGlz IDQyRDA0MjIgICAgIAptZmkwOiAzODIwIChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2Vy dGVkOiBQRCAwYShlMHhmZi9zMTApCm1maTA6IDM4MjEgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8p IC0gSW5zZXJ0ZWQ6IFBEIDBhKGUweGZmL3MxMCkgSW5mbzogZW5jbFBkPWZmZmYsIHNjc2lUeXBl PTAsIHBvcnRNYXA9MDQsIHNhc0FkZHI9NTAwMGM1MDAxMzhkNjU5OSwwMDAwMDAwMDAwMDAwMDAw Cm1maTA6IDM4MjIgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gUEQgMGEoZTB4ZmYvczEwKSBG UlUgaXMgNDJEMDQyMiAgICAgCm1maTA6IDM4MjMgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0g SW5zZXJ0ZWQ6IFBEIDBiKGUweGZmL3MxMSkKbWZpMDogMzgyNCAoYm9vdCArIDg5cy8weDAwMDIv aW5mbykgLSBJbnNlcnRlZDogUEQgMGIoZTB4ZmYvczExKSBJbmZvOiBlbmNsUGQ9ZmZmZiwgc2Nz aVR5cGU9MCwgcG9ydE1hcD0wNSwgc2FzQWRkcj01MDAwYzUwMDEzOGQ2MjA1LDAwMDAwMDAwMDAw MDAwMDAKbWZpMDogMzgyNSAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBQRCAwYihlMHhmZi9z MTEpIEZSVSBpcyA0MkQwNDIyICAgICAKbWZpMDogMzgyNiAoYm9vdCArIDg5cy8weDAwMDIvaW5m bykgLSBJbnNlcnRlZDogUEQgMGMoZTB4ZmYvczEyKQptZmkwOiAzODI3IChib290ICsgODlzLzB4 MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwYyhlMHhmZi9zMTIpIEluZm86IGVuY2xQZD1mZmZm LCBzY3NpVHlwZT0wLCBwb3J0TWFwPTAyLCBzYXNBZGRyPTUwMDBjNTAwMTM4ZDZhZGQsMDAwMDAw MDAwMDAwMDAwMAptZmkwOiAzODI4IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIFBEIDBjKGUw eGZmL3MxMikgRlJVIGlzIDQyRDA0MjIgICAgIAptZmkwOiAzODI5IChib290ICsgODlzLzB4MDAw Mi9pbmZvKSAtIEluc2VydGVkOiBQRCAwZChlMHhmZi9zMTMpCm1maTA6IDM4MzAgKGJvb3QgKyA4 OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBkKGUweGZmL3MxMykgSW5mbzogZW5jbFBk PWZmZmYsIHNjc2lUeXBlPTAsIHBvcnRNYXA9MDMsIHNhc0FkZHI9NTAwMGM1MDAxMzhjNDY1MSww MDAwMDAwMDAwMDAwMDAwCm1maTA6IDM4MzEgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gUEQg MGQoZTB4ZmYvczEzKSBGUlUgaXMgNDJEMDQyMiAgICAgCm1maTA6IDM4MzIgKGJvb3QgKyA4OXMv MHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBlKGUweGZmL3MxNCkKbWZpMDogMzgzMyAoYm9v dCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMGUoZTB4ZmYvczE0KSBJbmZvOiBl bmNsUGQ9ZmZmZiwgc2NzaVR5cGU9MCwgcG9ydE1hcD0wNiwgc2FzQWRkcj01MDAwYzUwMDEzOGQ1 ZGU1LDAwMDAwMDAwMDAwMDAwMDAKbWZpMDogMzgzNCAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykg LSBQRCAwZShlMHhmZi9zMTQpIEZSVSBpcyA0MkQwNDIyICAgICAKbWZpMDogMzgzNSAoYm9vdCAr IDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMGYoZTB4ZmYvczE1KQptZmkwOiAzODM2 IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwZihlMHhmZi9zMTUpIElu Zm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBwb3J0TWFwPTA3LCBzYXNBZGRyPTUwMDBjNTAw MTM4ZDYxZjEsMDAwMDAwMDAwMDAwMDAwMAptZmkwOiAzODM3IChib290ICsgODlzLzB4MDAwMi9p bmZvKSAtIFBEIDBmKGUweGZmL3MxNSkgRlJVIGlzIDQyRDA0MjIgICAgIAptZmkwOiAzODM4IChi b290ICsgMTQ0cy8weDAwMDgvaW5mbykgLSBCYXR0ZXJ5IHRlbXBlcmF0dXJlIGlzIG5vcm1hbApt ZmkwOiAzODM5ICgzMTI1NDgwODlzLzB4MDAyMC9pbmZvKSAtIFRpbWUgZXN0YWJsaXNoZWQgYXMg MTEvMjYvMDkgMTA6NTQ6NDk7ICgyMDMgc2Vjb25kcyBzaW5jZSBwb3dlciBvbikKbWZpMDogMzg0 MCAoYm9vdCArIDNzLzB4MDAyMC9pbmZvKSAtIEZpcm13YXJlIGluaXRpYWxpemF0aW9uIHN0YXJ0 ZWQgKFBDSSBJRCAwMDYwLzEwMDAvMDM2NC8xMDE0KQptZmkwOiAzODQxIChib290ICsgM3MvMHgw MDIwL2luZm8pIC0gRmlybXdhcmUgdmVyc2lvbiAxLjQwLjYyLTA2OTEKbWZpMDogMzg0MiAoYm9v dCArIDNzLzB4MDAyMC9pbmZvKSAtIEZpcm13YXJlIGluaXRpYWxpemF0aW9uIHN0YXJ0ZWQgKFBD SSBJRCAwMDYwLzEwMDAvMDM2NC8xMDE0KQptZmkwOiAzODQzIChib290ICsgM3MvMHgwMDIwL2lu Zm8pIC0gRmlybXdhcmUgdmVyc2lvbiAxLjQwLjYyLTA2OTEKbWZpMDogMzg0NCAoYm9vdCArIDY0 cy8weDAwMDgvaW5mbykgLSBCYXR0ZXJ5IFByZXNlbnQKbWZpMDogMzg0NSAoYm9vdCArIDY0cy8w eDAwMjAvaW5mbykgLSBCQlUgRlJVIGlzIAptZmkwOiAzODQ2IChib290ICsgNjRzLzB4MDAyMC9p bmZvKSAtIEJvYXJkIFJldmlzaW9uIAptZmkwOiAzODQ3IChib290ICsgODlzLzB4MDAwMi9pbmZv KSAtIEluc2VydGVkOiBQRCAwOChlMHhmZi9zOCkKbWZpMDogMzg0OCAoYm9vdCArIDg5cy8weDAw MDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMDgoZTB4ZmYvczgpIEluZm86IGVuY2xQZD1mZmZmLCBz Y3NpVHlwZT0wLCBwb3J0TWFwPTAwLCBzYXNBZGRyPTUwMDBjNTAwMTM4ZDZhYTEsMDAwMDAwMDAw MDAwMDAwMAptZmkwOiAzODQ5IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIFBEIDA4KGUweGZm L3M4KSBGUlUgaXMgNDJEMDQyMiAgICAgCm1maTA6IDM4NTAgKGJvb3QgKyA4OXMvMHgwMDAyL2lu Zm8pIC0gSW5zZXJ0ZWQ6IFBEIDA5KGUweGZmL3M5KQptZmkwOiAzODUxIChib290ICsgODlzLzB4 MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwOShlMHhmZi9zOSkgSW5mbzogZW5jbFBkPWZmZmYs IHNjc2lUeXBlPTAsIHBvcnRNYXA9MDEsIHNhc0FkZHI9NTAwMGM1MDAxMzhkODY2MSwwMDAwMDAw MDAwMDAwMDAwCm1maTA6IDM4NTIgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gUEQgMDkoZTB4 ZmYvczkpIEZSVSBpcyA0MkQwNDIyICAgICAKbWZpMDogMzg1MyAoYm9vdCArIDg5cy8weDAwMDIv aW5mbykgLSBJbnNlcnRlZDogUEQgMGEoZTB4ZmYvczEwKQptZmkwOiAzODU0IChib290ICsgODlz LzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwYShlMHhmZi9zMTApIEluZm86IGVuY2xQZD1m ZmZmLCBzY3NpVHlwZT0wLCBwb3J0TWFwPTA0LCBzYXNBZGRyPTUwMDBjNTAwMTM4ZDY1OTksMDAw MDAwMDAwMDAwMDAwMAptZmkwOiAzODU1IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIFBEIDBh KGUweGZmL3MxMCkgRlJVIGlzIDQyRDA0MjIgICAgIAptZmkwOiAzODU2IChib290ICsgODlzLzB4 MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwYihlMHhmZi9zMTEpCm1maTA6IDM4NTcgKGJvb3Qg KyA4OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBiKGUweGZmL3MxMSkgSW5mbzogZW5j bFBkPWZmZmYsIHNjc2lUeXBlPTAsIHBvcnRNYXA9MDUsIHNhc0FkZHI9NTAwMGM1MDAxMzhkNjIw NSwwMDAwMDAwMDAwMDAwMDAwCm1maTA6IDM4NTggKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0g UEQgMGIoZTB4ZmYvczExKSBGUlUgaXMgNDJEMDQyMiAgICAgCm1maTA6IDM4NTkgKGJvb3QgKyA4 OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBjKGUweGZmL3MxMikKbWZpMDogMzg2MCAo Ym9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMGMoZTB4ZmYvczEyKSBJbmZv OiBlbmNsUGQ9ZmZmZiwgc2NzaVR5cGU9MCwgcG9ydE1hcD0wMiwgc2FzQWRkcj01MDAwYzUwMDEz OGQ2YWRkLDAwMDAwMDAwMDAwMDAwMDAKbWZpMDogMzg2MSAoYm9vdCArIDg5cy8weDAwMDIvaW5m bykgLSBQRCAwYyhlMHhmZi9zMTIpIEZSVSBpcyA0MkQwNDIyICAgICAKbWZpMDogMzg2MiAoYm9v dCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMGQoZTB4ZmYvczEzKQptZmkwOiAz ODYzIChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwZChlMHhmZi9zMTMp IEluZm86IGVuY2xQZD1mZmZmLCBzY3NpVHlwZT0wLCBwb3J0TWFwPTAzLCBzYXNBZGRyPTUwMDBj NTAwMTM4YzQ2NTEsMDAwMDAwMDAwMDAwMDAwMAptZmkwOiAzODY0IChib290ICsgODlzLzB4MDAw Mi9pbmZvKSAtIFBEIDBkKGUweGZmL3MxMykgRlJVIGlzIDQyRDA0MjIgICAgIAptZmkwOiAzODY1 IChib290ICsgODlzLzB4MDAwMi9pbmZvKSAtIEluc2VydGVkOiBQRCAwZShlMHhmZi9zMTQpCm1m aTA6IDM4NjYgKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBlKGUweGZm L3MxNCkgSW5mbzogZW5jbFBkPWZmZmYsIHNjc2lUeXBlPTAsIHBvcnRNYXA9MDYsIHNhc0FkZHI9 NTAwMGM1MDAxMzhkNWRlNSwwMDAwMDAwMDAwMDAwMDAwCm1maTA6IDM4NjcgKGJvb3QgKyA4OXMv MHgwMDAyL2luZm8pIC0gUEQgMGUoZTB4ZmYvczE0KSBGUlUgaXMgNDJEMDQyMiAgICAgCm1maTA6 IDM4NjggKGJvb3QgKyA4OXMvMHgwMDAyL2luZm8pIC0gSW5zZXJ0ZWQ6IFBEIDBmKGUweGZmL3Mx NSkKbWZpMDogMzg2OSAoYm9vdCArIDg5cy8weDAwMDIvaW5mbykgLSBJbnNlcnRlZDogUEQgMGYo ZTB4ZmYvczE1KSBJbmZvOiBlbmNsUGQ9ZmZmZiwgc2NzaVR5cGU9MCwgcG9ydE1hcD0wNywgc2Fz QWRkcj01MDAwYzUwMDEzOGQ2MWYxLDAwMDAwMDAwMDAwMDAwMDAKbWZpMDogMzg3MCAoYm9vdCAr IDg5cy8weDAwMDIvaW5mbykgLSBQRCAwZihlMHhmZi9zMTUpIEZSVSBpcyA0MkQwNDIyICAgICAK bWZpMDogMzg3MSAoYm9vdCArIDE0NHMvMHgwMDA4L2luZm8pIC0gQmF0dGVyeSB0ZW1wZXJhdHVy ZSBpcyBub3JtYWwKcGNpYjg6IDxQQ0ktUENJIGJyaWRnZT4gaXJxIDE2IGF0IGRldmljZSAyOC40 IG9uIHBjaTAKcGNpNjogPFBDSSBidXM+IG9uIHBjaWI4CnBjaWI5OiA8UENJLVBDSSBicmlkZ2U+ IGlycSAxNiBhdCBkZXZpY2UgMC4wIG9uIHBjaTYKcGNpNzogPFBDSSBidXM+IG9uIHBjaWI5CnBj aTc6IDxkaXNwbGF5LCBWR0E+IGF0IGRldmljZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKdWhj aTI6IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDIwNjAtMHgyMDdmIGly cSAxNyBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwCnVoY2kyOiBbR0lBTlQtTE9DS0VEXQp1c2IzOiA8 VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIHVoY2kyCnVzYjM6IFVTQiByZXZpc2lv biAxLjAKdWh1YjM6IEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4w MCwgYWRkciAxCnVodWIzOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1 aGNpMzogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBwb3J0IDB4MjA0MC0weDIwNWYg aXJxIDE4IGF0IGRldmljZSAyOS4xIG9uIHBjaTAKdWhjaTM6IFtHSUFOVC1MT0NLRURdCnVzYjQ6 IDxVSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4gb24gdWhjaTMKdXNiNDogVVNCIHJldmlz aW9uIDEuMAp1aHViNDogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8x LjAwLCBhZGRyIDEKdWh1YjQ6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVk CnVoY2k0OiA8VUhDSSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IHBvcnQgMHgyMDIwLTB4MjAz ZiBpcnEgMTkgYXQgZGV2aWNlIDI5LjIgb24gcGNpMAp1aGNpNDogW0dJQU5ULUxPQ0tFRF0KdXNi NTogPFVIQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpNAp1c2I1OiBVU0IgcmV2 aXNpb24gMS4wCnVodWI1OiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAw LzEuMDAsIGFkZHIgMQp1aHViNTogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2Vy ZWQKZWhjaTE6IDxFSENJIChnZW5lcmljKSBVU0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweDk3YTIx MDAwLTB4OTdhMjEzZmYgaXJxIDE3IGF0IGRldmljZSAyOS43IG9uIHBjaTAKZWhjaTE6IFtHSUFO VC1MT0NLRURdCnVzYjY6IEVIQ0kgdmVyc2lvbiAxLjAKdXNiNjogY29tcGFuaW9uIGNvbnRyb2xs ZXJzLCAyIHBvcnRzIGVhY2g6IHVzYjMgdXNiNCB1c2I1CnVzYjY6IDxFSENJIChnZW5lcmljKSBV U0IgMi4wIGNvbnRyb2xsZXI+IG9uIGVoY2kxCnVzYjY6IFVTQiByZXZpc2lvbiAyLjAKdWh1YjY6 IEludGVsIEVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxCnVo dWI2OiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApwY2liMTA6IDxQQ0kt UENJIGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMApwY2k0MTogPFBDSSBidXM+IG9uIHBj aWIxMAppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2UgMzEuMCBvbiBwY2kwCmlzYTA6 IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFwY2kwOiA8SW50ZWwgQVRBIGNvbnRyb2xsZXI+IHBvcnQg MHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHgyMGYwLTB4MjBmZiwweDIwZTAt MHgyMGVmIGlycSAxNiBhdCBkZXZpY2UgMzEuMiBvbiBwY2kwCmF0YTA6IDxBVEEgY2hhbm5lbCAw PiBvbiBhdGFwY2kwCmF0YTE6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCnBjaTA6IDxzZXJp YWwgYnVzLCBTTUJ1cz4gYXQgZGV2aWNlIDMxLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKYXRhcGNp MTogPEludGVsIEFUQSBjb250cm9sbGVyPiBwb3J0IDB4MjEwOC0weDIxMGYsMHgyMTI0LTB4MjEy NywweDIxMDAtMHgyMTA3LDB4MjEyMC0weDIxMjMsMHgyMGQwLTB4MjBkZiwweDIwYzAtMHgyMGNm IGlycSAyMSBhdCBkZXZpY2UgMzEuNSBvbiBwY2kwCmF0YTI6IDxBVEEgY2hhbm5lbCAwPiBvbiBh dGFwY2kxCmF0YTM6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kxCnNpbzA6IDwxNjU1MEEtY29t cGF0aWJsZSBDT00gcG9ydD4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFj cGkwCnNpbzA6IHR5cGUgMTY1NTBBLCBjb25zb2xlCnNpbzE6IDwxNjU1MEEtY29tcGF0aWJsZSBD T00gcG9ydD4gcG9ydCAweDJmOC0weDJmZiBpcnEgMyBvbiBhY3BpMApzaW8xOiB0eXBlIDE2NTUw QQpwbXRpbWVyMCBvbiBpc2EwCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4YzAw MDAtMHhjN2ZmZiwweGNhODAwLTB4ZDhmZmYgb24gaXNhMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29u dHJvbGxlciAoaTgwNDIpPiBhdCBwb3J0IDB4NjAsMHg2NCBvbiBpc2EwCmF0a2JkMDogPEFUIEtl eWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmtiZDAgYXQgYXRrYmQwCmF0a2JkMDogW0dJQU5ULUxP Q0tFRF0KcHBjMDogcGFyYWxsZWwgcG9ydCBub3QgZm91bmQuCnNjMDogPFN5c3RlbSBjb25zb2xl PiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBm bGFncz0weDMwMD4KdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBp b21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMApjZGNlMDogSUJNIFJORElTL0NEQyBFVEhFUiwg cmV2IDIuMDAvMi4xNSwgYWRkciAyCmNkY2UwOiBmYWtpbmcgTUFDIGFkZHJlc3MKY2RjZTA6IEV0 aGVybmV0IGFkZHJlc3M6IDJhOjAwOjAwOjAwOjAwOjAwCmNkY2UwOiBpZl9zdGFydCBydW5uaW5n IGRlZmVycmVkIGZvciBHaWFudApUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjCmlw ZncyICgraXB2NikgaW5pdGlhbGl6ZWQsIGRpdmVydCBsb2FkYWJsZSwgcnVsZS1iYXNlZCBmb3J3 YXJkaW5nIGVuYWJsZWQsIGRlZmF1bHQgdG8gYWNjZXB0LCBsb2dnaW5nIGxpbWl0ZWQgdG8gNTAw IHBhY2tldHMvZW50cnkgYnkgZGVmYXVsdApiY2UwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gRE9X TgpiY2UxOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gRE9XTgphY2QwOiBDRFJXIDxVSkRBNzgyIERW RC9DRFJXL1ZBMTM+IGF0IGF0YTAtbWFzdGVyIFVETUEzMwptZmkwOiAzODcyICgzMTI1OTkwMTBz LzB4MDAyMC9pbmZvKSAtIFRpbWUgZXN0YWJsaXNoZWQgYXMgMTEvMjcvMDkgIDE6MDM6MzA7ICgy MDQgc2Vjb25kcyBzaW5jZSBwb3dlciBvbikKU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhClNNUDog QVAgQ1BVICMxMiBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzYgTGF1bmNoZWQhClNNUDogQVAgQ1BV ICMxMyBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzkgTGF1bmNoZWQhClNNUDogQVAgQ1BVICM0IExh dW5jaGVkIQpTTVA6IEFQIENQVSAjMiBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzEgTGF1bmNoZWQh ClNNUDogQVAgQ1BVICM1IExhdW5jaGVkIQpTTVA6IEFQIENQVSAjMTQgTGF1bmNoZWQhClNNUDog QVAgQ1BVICMxMCBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzE1IExhdW5jaGVkIQpTTVA6IEFQIENQ VSAjNyBMYXVuY2hlZCEKU01QOiBBUCBDUFUgIzExIExhdW5jaGVkIQpTTVA6IEFQIENQVSAjOCBM YXVuY2hlZCEKVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSBuZnM6eC54LnguNzk6L3Vzci90c3Qt bWRiL2hvbWUvamFpbHMvZnJlZWJzZDYuNApORlMgUk9PVDogeC54LnguNzk6L3Vzci90c3QtbWRi L2hvbWUvamFpbHMvZnJlZWJzZDYuNC8KYmNlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCmJj ZTE6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUAoKQ2h1bmtzIGZyb20gc2hvdyBtc2didWY6CgpU cnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIG5mczp4LngueC43OTovdXNyL3RzdC1tZGIvaG9tZS9q YWlscy9mcmVlYnNkNi40Ck5GUyBST09UOiB4LngueC43OTovdXNyL3RzdC1tZGIvaG9tZS9qYWls cy9mcmVlYnNkNi40Lwo8MTE4PkludGVyZmFjZSBiY2UwIElQLUFkZHJlc3MgeC54LnguMTA4IEJy b2FkY2FzdCB4LngueC4yNTUgCjwxMTg+TG9hZGluZyBjb25maWd1cmF0aW9uIGZpbGVzLgo8MTE4 Pi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFuZDogZG9pdDogZHVtcG9uX3N0YXJ0IAo8MTE4 Pi9ldGMvcmM6IFdBUk5JTkc6IElnbm9yaW5nIHNjcmF0Y2ggZmlsZSAvZXRjL3JjLmQvaW5pdHJh bmRvbS5iYWsKPDExOD4vZXRjL3JjOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6IGRvaXQ6IGdlbGlf c3RhcnQgCjwxMTg+L2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBzdGFydF9wcmVjbWQ6 IGZpbmRfZ2JkZV9kZXZpY2VzIHN0YXJ0IAo8MTE4Pi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29t bWFuZDogZG9pdDogZ2JkZV9zdGFydCAKPDExOD4vZXRjL3JjOiBERUJVRzogcnVuX3JjX2NvbW1h bmQ6IGRvaXQ6IGVuY3N3YXBfYXR0YWNoIAo8MTE4Pi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29t bWFuZDogZG9pdDogY2NkX3N0YXJ0IAo8MTE4Pi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFu ZDogZG9pdDogc3dhcG9uIC1hIAo8MTE4Pi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFuZDog ZG9pdDogbWRjb25maWdfc3RhcnQgCjwxMTg+L2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21tYW5k OiBkb2l0OiByYW1kaXNrX3N0YXJ0IAo8MTE4Pi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFu ZDogZG9pdDogZnNja19zdGFydCAKPDExOD5TdGFydGluZyBmaWxlIHN5c3RlbSBjaGVja3M6Cjwx MTg+L2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IGJhY2tncm91bmRfZnNjayBpcyBzZXQgdG8g WUVTLgo8MTE4Pi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFuZDogZG9pdDogcm9vdF9zdGFy dCAKPDExOD5tb3VudF9uZnM6IAo8MTE4PmNhbid0IHVwZGF0ZSAvdmFyL2RiL21vdW50dGFiIGZv ciB4LngueC43OTovdXNyL3RzdC1tZGIvaG9tZS9qYWlscy9mcmVlYnNkNi40CjwxMTg+CjwxMTg+ L2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBkb2l0OiBtb3VudGNyaXRsb2NhbF9zdGFy dCAKPDExOD5Nb3VudGluZyBsb2NhbCBmaWxlIHN5c3RlbXM6CjwxMTg+Lgo8MTE4Pi9ldGMvcmM6 IFdBUk5JTkc6IElnbm9yaW5nIHNjcmF0Y2ggZmlsZSAvZXRjL3JjLmQvcmFuZG9tLmJhawo8MTE4 Pi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFuZDogZG9pdDogYWRqa2VybnR6IC1pIAo8MTE4 Pi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBhdG1fZW5hYmxlIGlzIHNldCB0byBOTy4KPDEx OD4vZXRjL3JjOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6IGRvaXQ6IGhvc3RuYW1lX3N0YXJ0IAo8 MTE4Pi9ldGMvcmM6IFdBUk5JTkc6ICRob3N0bmFtZSBpcyBub3Qgc2V0IC0tIHNlZSByYy5jb25m KDUpLgo8MTE4Pi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBpcGZpbHRlcl9lbmFibGUgaXMg c2V0IHRvIE5PLgo8MTE4Pi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBpcG5hdF9lbmFibGUg aXMgc2V0IHRvIE5PLgo8MTE4Pi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBpcGZzX2VuYWJs ZSBpcyBzZXQgdG8gTk8uCjwxMTg+L2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IGtsZHhyZWZf ZW5hYmxlIGlzIHNldCB0byBOTy4KPDExOD4vZXRjL3JjOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6 IGRvaXQ6IHNwcHBfc3RhcnQgCjwxMTg+L2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBk b2l0OiBhZGRzd2FwX3N0YXJ0IAo8MTE4Pi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFuZDog ZG9pdDogYXV0b19saW5rbG9jYWxfc3RhcnQgCjwxMTg+L2V0Yy9yYzogREVCVUc6IGNoZWNreWVz bm86IGlwdjZfZW5hYmxlIGlzIHNldCB0byBOTy4KPDExOD5uZXQuaW5ldDYuaXA2LmF1dG9fbGlu a2xvY2FsOiAKPDExOD4xCjwxMTg+IC0+IAo8MTE4PjAKPDExOD4KPDExOD4vZXRjL3JjOiBERUJV RzogcnVuX3JjX2NvbW1hbmQ6IGRvaXQ6IHN5c2N0bF9zdGFydCAKPDExOD5rZXJuLmlwYy5zb21h eGNvbm46IAo8MTE4PjEyOAo8MTE4PiAtPiAKPDExOD40MDk2CjwxMTg+CjwxMTg+a2Vybi5tYXhm aWxlczogCjwxMTg+MTIzMjgKPDExOD4gLT4gCjwxMTg+MTMxMDcyCjwxMTg+CjwxMTg+a2Vybi5p cGMubm1iY2x1c3RlcnM6IAo8MTE4PjI1NjAwCjwxMTg+IC0+IAo8MTE4PjMyNzY4CjwxMTg+ICAg CjwxMTg+bmV0LmluZXQudGNwLm1heHRjcHR3OiAKPDExOD4yNDY1CjwxMTg+IC0+IAo8MTE4PjEy MAo8MTE4Pgo8MTE4Pm5ldC5pbmV0LnRjcC5tc2w6IAo8MTE4PjMwMDAwCjwxMTg+IC0+IAo8MTE4 PjE1MDAwCjwxMTg+CjwxMTg+bmV0LmluZXQudGNwLnJlY3ZzcGFjZTogCjwxMTg+NjU1MzYKPDEx OD4gLT4gCjwxMTg+NDA5Ngo8MTE4Pgo8MTE4Pmtlcm4uaXBjLm1heHNvY2tldHM6IAo8MTE4PjEy MzI4CjwxMTg+IC0+IAo8MTE4PjY1NTM0CjwxMTg+ICAgCjwxMTg+bmV0LmluZXQudGNwLmJsYWNr aG9sZTogCjwxMTg+MAo8MTE4PiAtPiAKPDExOD4xCjwxMTg+CjwxMTg+a2Vybi5hY2N0X3N1c3Bl bmQ6IAo8MTE4PjIKPDExOD4gLT4gCjwxMTg+MTUKPDExOD4KPDExOD5rZXJuLmFjY3RfcmVzdW1l OiAKPDExOD40CjwxMTg+IC0+IAo8MTE4PjIwCjwxMTg+CjwxMTg+dm0uYmlncHJvY19wcm90aGl1 aWQ6IAo8MTE4PjAKPDExOD4gLT4gCjwxMTg+MTAwMAo8MTE4PiAgIAo8MTE4PnZtLmJpZ3Byb2Nf aWdub3JlX25vYm9keTogCjwxMTg+MAo8MTE4PiAtPiAKPDExOD4xCjwxMTg+CjwxMTg+dm0uc3dh cF91bmRlcnJ1bjogCjwxMTg+NjQKPDExOD4gLT4gCjwxMTg+NjQwMDAKPDExOD4KPDExOD5rZXJu LmlwYy5zaG1hbGw6IAo8MTE4PjgxOTIKPDExOD4gLT4gCjwxMTg+MTYzODQKPDExOD4KPDExOD52 ZnMudWZzLmRpcmhhc2hfbWF4bWVtOiAKPDExOD4yMDk3MTUyCjwxMTg+IC0+IAo8MTE4PjgzODg2 MDgKPDExOD4gICAKPDExOD4vZXRjL3JjOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6IGRvaXQ6IHBj Y2FyZF9zdGFydCAKPDExOD4vZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogY2xlYW52YXJfZW5h YmxlIGlzIHNldCB0byBZRVMuCjwxMTg+L2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBz dGFydF9wcmVjbWQ6IGNsZWFudmFyX3ByZXN0YXJ0IAo8MTE4Pi9ldGMvcmM6IERFQlVHOiBydW5f cmNfY29tbWFuZDogZG9pdDogY2xlYW52YXJfc3RhcnQgCjwxMTg+L2V0Yy9yYzogREVCVUc6IHJ1 bl9yY19jb21tYW5kOiBkb2l0OiBuZXR3b3JrX3N0YXJ0IAo8MTE4Pi9ldGMvcmM6IERFQlVHOiBD bG9uZWQ6IAo8MTE4PmxvMDogZmxhZ3M9ODA0OTxVUCxMT09QQkFDSyxSVU5OSU5HLE1VTFRJQ0FT VD4gbXR1IDE2Mzg0CjwxMTg+ICAgaW5ldDYgZmU4MDo6MSVsbzAgcHJlZml4bGVuIDY0IHNjb3Bl aWQgMHg0IAo8MTE4PiAgIGluZXQ2IDo6MSBwcmVmaXhsZW4gMTI4IAo8MTE4PiAgIGluZXQgMTI3 LjAuMC4xIG5ldG1hc2sgMHhmZjAwMDAwMCAKPDExOD4vZXRjL3JjOiBERUJVRzogVGhlIGZvbGxv d2luZyBpbnRlcmZhY2VzIHdlcmUgbm90IGNvbmZpZ3VyZWQ6ICBiY2UwIGJjZTEgY2RjZTAKPDEx OD4vZXRjL3JjLmQvaXBmaWx0ZXI6IERFQlVHOiBjaGVja3llc25vOiBpcGZpbHRlcl9lbmFibGUg aXMgc2V0IHRvIE5PLgo8MTE4Pi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBpcDZhZGRyY3Rs X2VuYWJsZSBpcyBzZXQgdG8gWUVTLgo8MTE4Pi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFu ZDogZG9pdDogaXA2YWRkcmN0bF9zdGFydCAKPDExOD4vZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNu bzogaXB2Nl9lbmFibGUgaXMgc2V0IHRvIE5PLgo8MTE4Pi9ldGMvcmM6IERFQlVHOiBjaGVja3ll c25vOiBpcDZhZGRyY3RsX3ZlcmJvc2UgaXMgc2V0IHRvIE5PLgo8MTE4Pi9ldGMvcmM6IERFQlVH OiBjaGVja3llc25vOiBhdG1fZW5hYmxlIGlzIHNldCB0byBOTy4KPDExOD4vZXRjL3JjOiBERUJV RzogY2hlY2t5ZXNubzogcGZzeW5jX2VuYWJsZSBpcyBzZXQgdG8gTk8uCjwxMTg+L2V0Yy9yYzog REVCVUc6IGNoZWNreWVzbm86IHBmbG9nX2VuYWJsZSBpcyBzZXQgdG8gTk8uCjwxMTg+L2V0Yy9y YzogREVCVUc6IGNoZWNreWVzbm86IHBmX2VuYWJsZSBpcyBzZXQgdG8gTk8uCjwxMTg+L2V0Yy9y YzogREVCVUc6IGNoZWNreWVzbm86IGlzZG5fZW5hYmxlIGlzIHNldCB0byBOTy4KPDExOD4vZXRj L3JjOiBERUJVRzogY2hlY2t5ZXNubzogcHBwX2VuYWJsZSBpcyBzZXQgdG8gTk8uCjwxMTg+L2V0 Yy9yYzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBkb2l0OiByb3V0aW5nX3N0YXJ0IAo8MTE4PkFk ZGl0aW9uYWwgcm91dGluZyBvcHRpb25zOgo8MTE4Pi4KPDExOD4vZXRjL3JjOiBERUJVRzogY2hl Y2t5ZXNubzogaXB2Nl9maXJld2FsbF9lbmFibGUgaXMgc2V0IHRvIE5PLgo8MTE4Pi9ldGMvcmM6 IERFQlVHOiBjaGVja3llc25vOiBpcHY2X2VuYWJsZSBpcyBzZXQgdG8gTk8uCjwxMTg+L2V0Yy9y YzogREVCVUc6IGNoZWNreWVzbm86IGRldmRfZW5hYmxlIGlzIHNldCB0byBZRVMuCjwxMTg+U3Rh cnRpbmcgZGV2ZC4KPDExOD4vZXRjL3JjOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6IGRvaXQ6IC9z YmluL2RldmQgIAo8MTE4Pi9ldGMvcGNjYXJkX2V0aGVyOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6 IHN0YXJ0X3ByZWNtZDogY2hlY2thdXRvIAo8MTE4Pi9ldGMvcGNjYXJkX2V0aGVyOiBERUJVRzog cnVuX3JjX2NvbW1hbmQ6IGRvaXQ6IHBjY2FyZF9ldGhlcl9zdGFydCAKPDExOD4vZXRjL3BjY2Fy ZF9ldGhlcjogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBzdGFydF9wcmVjbWQ6IGNoZWNrYXV0byAK PDExOD4vZXRjL3BjY2FyZF9ldGhlcjogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBkb2l0OiBwY2Nh cmRfZXRoZXJfc3RhcnQgCjwxMTg+L2V0Yy9yYy5kL25ldGlmOiBERUJVRzogcnVuX3JjX2NvbW1h bmQ6IGRvaXQ6IG5ldHdvcmtfc3RhcnQgYmNlMQo8MTE4Pi9ldGMvcmMuZC9uZXRpZjogREVCVUc6 IFRoZSBmb2xsb3dpbmcgaW50ZXJmYWNlcyB3ZXJlIG5vdCBjb25maWd1cmVkOiAgYmNlMQo8MTE4 Pi9ldGMvcmMuZC9pcGZpbHRlcjogREVCVUc6IGNoZWNreWVzbm86IGlwZmlsdGVyX2VuYWJsZSBp cyBzZXQgdG8gTk8uCjwxMTg+L2V0Yy9yYy5kL2JyaWRnZTogREVCVUc6IHJ1bl9yY19jb21tYW5k OiBkb2l0OiBicmlkZ2Vfc3RhcnQgCjwxMTg+L2V0Yy9wY2NhcmRfZXRoZXI6IERFQlVHOiBydW5f cmNfY29tbWFuZDogc3RhcnRfcHJlY21kOiBjaGVja2F1dG8gCjwxMTg+L2V0Yy9wY2NhcmRfZXRo ZXI6IERFQlVHOiBydW5fcmNfY29tbWFuZDogZG9pdDogcGNjYXJkX2V0aGVyX3N0YXJ0IAo8MTE4 Pi9ldGMvcmMuZC9uZXRpZjogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBkb2l0OiBuZXR3b3JrX3N0 YXJ0IGNkY2UwCjwxMTg+L2V0Yy9yYy5kL25ldGlmOiBERUJVRzogVGhlIGZvbGxvd2luZyBpbnRl cmZhY2VzIHdlcmUgbm90IGNvbmZpZ3VyZWQ6ICBjZGNlMApLREI6IGVudGVyOiBMaW5lIGJyZWFr IG9uIGNvbnNvbGUKYmNlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCmJjZTE6IGxpbmsgc3Rh dGUgY2hhbmdlZCB0byBVUAoKZGI+IHBzCiAgcGlkICBwcGlkICBwZ3JwICAgdWlkICAgc3RhdGUg ICB3bWVzZyAgICAgd2NoYW4gICAgY21kCiAgNjM3ICAgNjMzICAgIDYyICAgICAwICBSKyAgICAg ICAgICAgICAgICAgICAgICAgICAgbG9nZ2VyCiAgNjMzICAgNTk3ICAgIDYyICAgICAwICBTKyAg ICAgIHdhaXQgICAgIDB4YzZkMTQ2NDggc2gKICA1OTcgICA1ODUgICAgNjIgICAgIDAgIFMrICAg ICAgd2FpdCAgICAgMHhjNjk1ZTQzMCBzaAogIDU4NSAgIDU4NCAgICA2MiAgICAgMCAgUysgICAg ICB3YWl0ICAgICAweGM2ZDRhYzkwIHNoCiAgNTg0ICAgNTA2ICAgIDYyICAgICAwICBTKyAgICAg IHdhaXQgICAgIDB4YzZkNTIyMTggc2gKICA1MDYgICA0OTkgICAgNjIgICAgIDAgIFMrICAgICAg d2FpdCAgICAgMHhjNmQwYmM5MCBkZXZkCiAgNDk5ICAgIDYyICAgIDYyICAgICAwICBTKyAgICAg IHdhaXQgICAgIDB4YzZkZWUyMTggc2gKICAgNzIgICAgIDAgICAgIDAgICAgIDAgIFNMICAgICAg LSAgICAgICAgMHhjMGE3ZjAwNCBbbmZzaW9kIDFdCiAgIDYzICAgICAwICAgICAwICAgICAwICBT TCAgICAgIC0gICAgICAgIDB4YzBhN2YwMDAgW25mc2lvZCAwXQogICA2MiAgICAgMSAgICA2MiAg ICAgMCAgU3MrICAgICB3YWl0ICAgICAweGM2ZDE0YzkwIHNoCiAgIDYxICAgICAwICAgICAwICAg ICAwICBTTCAgICAgIHNkZmx1c2ggIDB4YzBhODQ2OTQgW3NvZnRkZXBmbHVzaF0KICAgNjAgICAg IDAgICAgIDAgICAgIDAgIFJMICAgICAgICAgICAgICAgICAgICAgICAgICBbdm5scnVdCiAgIDU5 ICAgICAwICAgICAwICAgICAwICBTTCAgICAgIHN5bmNlciAgIDB4YzBhNmIyYmMgW3N5bmNlcl0K ICAgNTggICAgIDAgICAgIDAgICAgIDAgIFJMICAgICAgICAgICAgICAgICAgICAgICAgICBbYnVm ZGFlbW9uXQogICA1NyAgICAgMCAgICAgMCAgICAgMCAgU0wgICAgICBwZ3plcm8gICAweGMwYTg1 NmM0IFtwYWdlemVyb10KICAgNTYgICAgIDAgICAgIDAgICAgIDAgIFNMICAgICAgcHNsZWVwICAg MHhjMGE4NTFkNCBbdm1kYWVtb25dCiAgIDU1ICAgICAwICAgICAwICAgICAwICBTTCAgICAgIHBz bGVlcCAgIDB4YzBhODUxODggW3BhZ2VkYWVtb25dCiAgIDU0ICAgICAwICAgICAwICAgICAwICBX TCAgICAgICAgICAgICAgICAgICAgICAgICAgW2lycTE6IGF0a2JkMF0KICAgNTMgICAgIDAgICAg IDAgICAgIDAgIFdMICAgICAgICAgICAgICAgICAgICAgICAgICBbc3dpMDogc2lvXQpkYj4gYWxs dHJhY2UKClRyYWNpbmcgY29tbWFuZCBsb2dnZXIgcGlkIDYzNyB0aWQgMTAwMDYzIHRkIDB4YzZk MGYwMDAKc2NoZWRfc3dpdGNoKGM2ZDBmMDAwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTQzCm1p X3N3aXRjaCgxLDAsYzBhNmI1NGMsZWQxZTRjNDgsYzA2ZDIxYzIsLi4uKSBhdCBtaV9zd2l0Y2gr MHgxYmEKc2xlZXBxX3N3aXRjaChjMGE2YjU0YykgYXQgc2xlZXBxX3N3aXRjaCsweDg3CnNsZWVw cV90aW1lZHdhaXRfc2lnKGMwYTZiNTRjKSBhdCBzbGVlcHFfdGltZWR3YWl0X3NpZysweDFlCm1z bGVlcChjMGE2YjU0YywwLDE1YyxjMDk2N2IxYiwyLC4uLikgYXQgbXNsZWVwKzB4MjMwCmtlcm5f bmFub3NsZWVwKGM2ZDBmMDAwLGVkMWU0Y2NjLGVkMWU0Y2M0KSBhdCBrZXJuX25hbm9zbGVlcCsw eGFiCm5hbm9zbGVlcChjNmQwZjAwMCxlZDFlNGQwNCkgYXQgbmFub3NsZWVwKzB4NGYKc3lzY2Fs bCgzYiwzYiwzYixkLDVlLC4uLikgYXQgc3lzY2FsbCsweDJiZgpYaW50MHg4MF9zeXNjYWxsKCkg YXQgWGludDB4ODBfc3lzY2FsbCsweDFmCi0tLSBzeXNjYWxsICgyNDAsIEZyZWVCU0QgRUxGMzIs IG5hbm9zbGVlcCksIGVpcCA9IDB4MjgxMjFkMGYsIGVzcCA9IDB4YmZiZmRjM2MsIGVicCA9IDB4 YmZiZmRjNjggLS0tCgpUcmFjaW5nIGNvbW1hbmQgc2ggcGlkIDYzMyB0aWQgMTAwMDczIHRkIDB4 YzY5YTdkMDAKc2NoZWRfc3dpdGNoKGM2OWE3ZDAwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTQz Cm1pX3N3aXRjaCgxLDAsYzZkMTQ2NDgsZWFmYjRjMTgsYzA2ZDIwYzEsLi4uKSBhdCBtaV9zd2l0 Y2grMHgxYmEKc2xlZXBxX3N3aXRjaChjNmQxNDY0OCkgYXQgc2xlZXBxX3N3aXRjaCsweDg3CnNs ZWVwcV93YWl0X3NpZyhjNmQxNDY0OCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4MWQKbXNsZWVwKGM2 ZDE0NjQ4LGM2ZDE0NmIwLDE1YyxjMDk2NzJmYSwwKSBhdCBtc2xlZXArMHgyNWEKa2Vybl93YWl0 KGM2OWE3ZDAwLGZmZmZmZmZmLGVhZmI0Yzg0LDIsMCkgYXQga2Vybl93YWl0KzB4YTk3CndhaXQ0 KGM2OWE3ZDAwLGVhZmI0ZDA0KSBhdCB3YWl0NCsweDJhCnN5c2NhbGwoM2IsM2IsM2IsYmZiZmUw MTgsM2UsLi4uKSBhdCBzeXNjYWxsKzB4MmJmClhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4 MF9zeXNjYWxsKzB4MWYKLS0tIHN5c2NhbGwgKDcsIEZyZWVCU0QgRUxGMzIsIHdhaXQ0KSwgZWlw ID0gMHgyODEzOWMzNywgZXNwID0gMHhiZmJmZGZjYywgZWJwID0gMHhiZmJmZGZlOCAtLS0KClRy YWNpbmcgY29tbWFuZCBzaCBwaWQgNTk3IHRpZCAxMDAwNTEgdGQgMHhjNjk1YzAwMApzY2hlZF9z d2l0Y2goYzY5NWMwMDAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNDMKbWlfc3dpdGNoKDEsMCxj Njk1ZTQzMCxlYWU2YmMxOCxjMDZkMjBjMSwuLi4pIGF0IG1pX3N3aXRjaCsweDFiYQpzbGVlcHFf c3dpdGNoKGM2OTVlNDMwKSBhdCBzbGVlcHFfc3dpdGNoKzB4ODcKc2xlZXBxX3dhaXRfc2lnKGM2 OTVlNDMwKSBhdCBzbGVlcHFfd2FpdF9zaWcrMHgxZAptc2xlZXAoYzY5NWU0MzAsYzY5NWU0OTgs MTVjLGMwOTY3MmZhLDApIGF0IG1zbGVlcCsweDI1YQprZXJuX3dhaXQoYzY5NWMwMDAsZmZmZmZm ZmYsZWFlNmJjODQsMiwwKSBhdCBrZXJuX3dhaXQrMHhhOTcKd2FpdDQoYzY5NWMwMDAsZWFlNmJk MDQpIGF0IHdhaXQ0KzB4MmEKc3lzY2FsbCgzYiwzYiwzYixiZmJmZGFkOCwzZSwuLi4pIGF0IHN5 c2NhbGwrMHgyYmYKWGludDB4ODBfc3lzY2FsbCgpIGF0IFhpbnQweDgwX3N5c2NhbGwrMHgxZgot LS0gc3lzY2FsbCAoNywgRnJlZUJTRCBFTEYzMiwgd2FpdDQpLCBlaXAgPSAweDI4MTM5YzM3LCBl c3AgPSAweGJmYmZkYThjLCBlYnAgPSAweGJmYmZkYWE4IC0tLQoKVHJhY2luZyBjb21tYW5kIHNo IHBpZCA1ODUgdGlkIDEwMDA4MyB0ZCAweGM2ZDRiMzQwCnNjaGVkX3N3aXRjaChjNmQ0YjM0MCww LDEpIGF0IHNjaGVkX3N3aXRjaCsweDE0MwptaV9zd2l0Y2goMSwwLGM2ZDRhYzkwLGVkMjEyYzE4 LGMwNmQyMGMxLC4uLikgYXQgbWlfc3dpdGNoKzB4MWJhCnNsZWVwcV9zd2l0Y2goYzZkNGFjOTAp IGF0IHNsZWVwcV9zd2l0Y2grMHg4NwpzbGVlcHFfd2FpdF9zaWcoYzZkNGFjOTApIGF0IHNsZWVw cV93YWl0X3NpZysweDFkCm1zbGVlcChjNmQ0YWM5MCxjNmQ0YWNmOCwxNWMsYzA5NjcyZmEsMCkg YXQgbXNsZWVwKzB4MjVhCmtlcm5fd2FpdChjNmQ0YjM0MCxmZmZmZmZmZixlZDIxMmM4NCwyLDAp IGF0IGtlcm5fd2FpdCsweGE5Nwp3YWl0NChjNmQ0YjM0MCxlZDIxMmQwNCkgYXQgd2FpdDQrMHgy YQpzeXNjYWxsKDNiLDNiLDNiLGJmYmZkYjY4LDNlLC4uLikgYXQgc3lzY2FsbCsweDJiZgpYaW50 MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDFmCi0tLSBzeXNjYWxsICg3LCBG cmVlQlNEIEVMRjMyLCB3YWl0NCksIGVpcCA9IDB4MjgxMzljMzcsIGVzcCA9IDB4YmZiZmRiMWMs IGVicCA9IDB4YmZiZmRiMzggLS0tCgpUcmFjaW5nIGNvbW1hbmQgc2ggcGlkIDU4NCB0aWQgMTAw MDkyIHRkIDB4YzZkMGYzNDAKc2NoZWRfc3dpdGNoKGM2ZDBmMzQwLDAsMSkgYXQgc2NoZWRfc3dp dGNoKzB4MTQzCm1pX3N3aXRjaCgxLDAsYzZkNTIyMTgsZWQxZWFjMTgsYzA2ZDIwYzEsLi4uKSBh dCBtaV9zd2l0Y2grMHgxYmEKc2xlZXBxX3N3aXRjaChjNmQ1MjIxOCkgYXQgc2xlZXBxX3N3aXRj aCsweDg3CnNsZWVwcV93YWl0X3NpZyhjNmQ1MjIxOCkgYXQgc2xlZXBxX3dhaXRfc2lnKzB4MWQK bXNsZWVwKGM2ZDUyMjE4LGM2ZDUyMjgwLDE1YyxjMDk2NzJmYSwwKSBhdCBtc2xlZXArMHgyNWEK a2Vybl93YWl0KGM2ZDBmMzQwLGZmZmZmZmZmLGVkMWVhYzg0LDIsMCkgYXQga2Vybl93YWl0KzB4 YTk3CndhaXQ0KGM2ZDBmMzQwLGVkMWVhZDA0KSBhdCB3YWl0NCsweDJhCnN5c2NhbGwoM2IsM2Is M2IsYmZiZmViZjgsM2UsLi4uKSBhdCBzeXNjYWxsKzB4MmJmClhpbnQweDgwX3N5c2NhbGwoKSBh dCBYaW50MHg4MF9zeXNjYWxsKzB4MWYKLS0tIHN5c2NhbGwgKDcsIEZyZWVCU0QgRUxGMzIsIHdh aXQ0KSwgZWlwID0gMHgyODEzOWMzNywgZXNwID0gMHhiZmJmZWJhYywgZWJwID0gMHhiZmJmZWJj OCAtLS0KClRyYWNpbmcgY29tbWFuZCBkZXZkIHBpZCA1MDYgdGlkIDEwMDA2OSB0ZCAweGM2ZDBj NGUwCnNjaGVkX3N3aXRjaChjNmQwYzRlMCwwLDEpIGF0IHNjaGVkX3N3aXRjaCsweDE0MwptaV9z d2l0Y2goMSwwLGM2ZDBiYzkwLGVkMWQyYzE4LGMwNmQyMGMxLC4uLikgYXQgbWlfc3dpdGNoKzB4 MWJhCnNsZWVwcV9zd2l0Y2goYzZkMGJjOTApIGF0IHNsZWVwcV9zd2l0Y2grMHg4NwpzbGVlcHFf d2FpdF9zaWcoYzZkMGJjOTApIGF0IHNsZWVwcV93YWl0X3NpZysweDFkCm1zbGVlcChjNmQwYmM5 MCxjNmQwYmNmOCwxNWMsYzA5NjcyZmEsMCkgYXQgbXNsZWVwKzB4MjVhCmtlcm5fd2FpdChjNmQw YzRlMCwyNDgsZWQxZDJjODQsMCwwKSBhdCBrZXJuX3dhaXQrMHhhOTcKd2FpdDQoYzZkMGM0ZTAs ZWQxZDJkMDQpIGF0IHdhaXQ0KzB4MmEKc3lzY2FsbCgzYiwzYiwzYixiZmJmZTgyYywyNDgsLi4u KSBhdCBzeXNjYWxsKzB4MmJmClhpbnQweDgwX3N5c2NhbGwoKSBhdCBYaW50MHg4MF9zeXNjYWxs KzB4MWYKLS0tIHN5c2NhbGwgKDcsIEZyZWVCU0QgRUxGMzIsIHdhaXQ0KSwgZWlwID0gMHg4MDY0 ZmMzLCBlc3AgPSAweGJmYmZlODBjLCBlYnAgPSAweGJmYmZlOGM4IC0tLQoKVHJhY2luZyBjb21t YW5kIHNoIHBpZCA0OTkgdGlkIDEwMDExMyB0ZCAweGM2ZGMwMzQwCnNjaGVkX3N3aXRjaChjNmRj MDM0MCwwLDEpIGF0IHNjaGVkX3N3aXRjaCsweDE0MwptaV9zd2l0Y2goMSwwLGM2ZGVlMjE4LGVk MjcwYzE4LGMwNmQyMGMxLC4uLikgYXQgbWlfc3dpdGNoKzB4MWJhCnNsZWVwcV9zd2l0Y2goYzZk ZWUyMTgpIGF0IHNsZWVwcV9zd2l0Y2grMHg4NwpzbGVlcHFfd2FpdF9zaWcoYzZkZWUyMTgpIGF0 IHNsZWVwcV93YWl0X3NpZysweDFkCm1zbGVlcChjNmRlZTIxOCxjNmRlZTI4MCwxNWMsYzA5Njcy ZmEsMCkgYXQgbXNsZWVwKzB4MjVhCmtlcm5fd2FpdChjNmRjMDM0MCxmZmZmZmZmZixlZDI3MGM4 NCwyLDApIGF0IGtlcm5fd2FpdCsweGE5Nwp3YWl0NChjNmRjMDM0MCxlZDI3MGQwNCkgYXQgd2Fp dDQrMHgyYQpzeXNjYWxsKDNiLDNiLDNiLGJmYmZkNzA4LDNlLC4uLikgYXQgc3lzY2FsbCsweDJi ZgpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4ODBfc3lzY2FsbCsweDFmCi0tLSBzeXNjYWxs ICg3LCBGcmVlQlNEIEVMRjMyLCB3YWl0NCksIGVpcCA9IDB4MjgxMzljMzcsIGVzcCA9IDB4YmZi ZmQ2YmMsIGVicCA9IDB4YmZiZmQ2ZDggLS0tCgpUcmFjaW5nIGNvbW1hbmQgbmZzaW9kIDEgcGlk IDcyIHRpZCAxMDAwNjcgdGQgMHhjNmQwYzgyMApzY2hlZF9zd2l0Y2goYzZkMGM4MjAsMCwxKSBh dCBzY2hlZF9zd2l0Y2grMHgxNDMKbWlfc3dpdGNoKDEsMCxjMGE3ZjAwNCxlZDFkOGNjMCxjMDZk MjFjMiwuLi4pIGF0IG1pX3N3aXRjaCsweDFiYQpzbGVlcHFfc3dpdGNoKGMwYTdmMDA0KSBhdCBz bGVlcHFfc3dpdGNoKzB4ODcKc2xlZXBxX3RpbWVkd2FpdF9zaWcoYzBhN2YwMDQpIGF0IHNsZWVw cV90aW1lZHdhaXRfc2lnKzB4MWUKbXNsZWVwKGMwYTdmMDA0LDAsMTVjLGMwOTYyN2IzLDFkNGMw LC4uLikgYXQgbXNsZWVwKzB4MjMwCm5mc3N2Y19pb2QoYzBhN2U5YTQsZWQxZDhkMzgpIGF0IG5m c3N2Y19pb2QrMHhiYQpmb3JrX2V4aXQoYzA3YWM0M2MsYzBhN2U5YTQsZWQxZDhkMzgpIGF0IGZv cmtfZXhpdCsweDcxCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0t IHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGVkMWQ4ZDZjLCBlYnAgPSAwIC0tLQoKVHJhY2lu ZyBjb21tYW5kIG5mc2lvZCAwIHBpZCA2MyB0aWQgMTAwMDc1IHRkIDB4YzY5YTc5YzAKc2NoZWRf c3dpdGNoKGM2OWE3OWMwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTQzCm1pX3N3aXRjaCgxLDAs YzBhN2YwMDAsZWFmYWVjYzAsYzA2ZDIxYzIsLi4uKSBhdCBtaV9zd2l0Y2grMHgxYmEKc2xlZXBx X3N3aXRjaChjMGE3ZjAwMCkgYXQgc2xlZXBxX3N3aXRjaCsweDg3CnNsZWVwcV90aW1lZHdhaXRf c2lnKGMwYTdmMDAwKSBhdCBzbGVlcHFfdGltZWR3YWl0X3NpZysweDFlCm1zbGVlcChjMGE3ZjAw MCwwLDE1YyxjMDk2MjdiMywxZDRjMCwuLi4pIGF0IG1zbGVlcCsweDIzMApuZnNzdmNfaW9kKGMw YTdlOWEwLGVhZmFlZDM4KSBhdCBuZnNzdmNfaW9kKzB4YmEKZm9ya19leGl0KGMwN2FjNDNjLGMw YTdlOWEwLGVhZmFlZDM4KSBhdCBmb3JrX2V4aXQrMHg3MQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBm b3JrX3RyYW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDB4MSwgZWlwID0gMCwgZXNwID0gMHhlYWZhZWQ2 YywgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCBzaCBwaWQgNjIgdGlkIDEwMDA3NiB0ZCAw eGM2OWE3ODIwCnNjaGVkX3N3aXRjaChjNjlhNzgyMCwwLDEpIGF0IHNjaGVkX3N3aXRjaCsweDE0 MwptaV9zd2l0Y2goMSwwLGM2ZDE0YzkwLGVhZmFiYzE4LGMwNmQyMGMxLC4uLikgYXQgbWlfc3dp dGNoKzB4MWJhCnNsZWVwcV9zd2l0Y2goYzZkMTRjOTApIGF0IHNsZWVwcV9zd2l0Y2grMHg4Nwpz bGVlcHFfd2FpdF9zaWcoYzZkMTRjOTApIGF0IHNsZWVwcV93YWl0X3NpZysweDFkCm1zbGVlcChj NmQxNGM5MCxjNmQxNGNmOCwxNWMsYzA5NjcyZmEsMCkgYXQgbXNsZWVwKzB4MjVhCmtlcm5fd2Fp dChjNjlhNzgyMCxmZmZmZmZmZixlYWZhYmM4NCwyLDApIGF0IGtlcm5fd2FpdCsweGE5Nwp3YWl0 NChjNjlhNzgyMCxlYWZhYmQwNCkgYXQgd2FpdDQrMHgyYQpzeXNjYWxsKDNiLDNiLDNiLGJmYmZl ODI4LDNlLC4uLikgYXQgc3lzY2FsbCsweDJiZgpYaW50MHg4MF9zeXNjYWxsKCkgYXQgWGludDB4 ODBfc3lzY2FsbCsweDFmCi0tLSBzeXNjYWxsICg3LCBGcmVlQlNEIEVMRjMyLCB3YWl0NCksIGVp cCA9IDB4MjgxMzljMzcsIGVzcCA9IDB4YmZiZmU3ZGMsIGVicCA9IDB4YmZiZmU3ZjggLS0tCgpU cmFjaW5nIGNvbW1hbmQgc29mdGRlcGZsdXNoIHBpZCA2MSB0aWQgMTAwMDUyIHRkIDB4YzY4ZDJk MDAKc2NoZWRfc3dpdGNoKGM2OGQyZDAwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTQzCm1pX3N3 aXRjaCgxLDAsYzY4ZDJkMDAsZTZlNThjYzAsYzA2ZDIxNmMsLi4uKSBhdCBtaV9zd2l0Y2grMHgx YmEKc2xlZXBxX3N3aXRjaChjMGE4NDY5NCxjNjhkMmQwMCxlNmU1OGNlMCxjMDZiN2MyNSxjMGE4 NDY5NCwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHg4NwpzbGVlcHFfdGltZWR3YWl0KGMwYTg0Njk0 KSBhdCBzbGVlcHFfdGltZWR3YWl0KzB4NWMKbXNsZWVwKGMwYTg0Njk0LGMwYTg0NjYwLDQ0LGMw OTc5ZGQ0LDNlOCkgYXQgbXNsZWVwKzB4MjQ1CnNvZnRkZXBfZmx1c2goMCxlNmU1OGQzOCkgYXQg c29mdGRlcF9mbHVzaCsweDMzYQpmb3JrX2V4aXQoYzA4MGU5ZDQsMCxlNmU1OGQzOCkgYXQgZm9y a19leGl0KzB4NzEKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0g dHJhcCAweDEsIGVpcCA9IDAsIGVzcCA9IDB4ZTZlNThkNmMsIGVicCA9IDAgLS0tCgpUcmFjaW5n IGNvbW1hbmQgdm5scnUgcGlkIDYwIHRpZCAxMDAwNTMgdGQgMHhjNjhkMmI2MApzY2hlZF9zd2l0 Y2goYzY4ZDJiNjAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNDMKbWlfc3dpdGNoKDEsMCxjNjhk MmI2MCxlNmU1NWNiOCxjMDZkMjE2YywuLi4pIGF0IG1pX3N3aXRjaCsweDFiYQpzbGVlcHFfc3dp dGNoKGM2OTVlODYwLGM2OGQyYjYwLGU2ZTU1Y2Q4LGMwNmI3YzI1LGM2OTVlODYwLC4uLikgYXQg c2xlZXBxX3N3aXRjaCsweDg3CnNsZWVwcV90aW1lZHdhaXQoYzY5NWU4NjApIGF0IHNsZWVwcV90 aW1lZHdhaXQrMHg1Ywptc2xlZXAoYzY5NWU4NjAsYzBhNzcyYTAsMjUwLGMwOTZjMjc1LDNlOCxj MGE3NzMyMCkgYXQgbXNsZWVwKzB4MjQ1CnZubHJ1X3Byb2MoMCxlNmU1NWQzOCkgYXQgdm5scnVf cHJvYysweDExNwpmb3JrX2V4aXQoYzA3MGIzYjQsMCxlNmU1NWQzOCkgYXQgZm9ya19leGl0KzB4 NzEKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAweDEs IGVpcCA9IDAsIGVzcCA9IDB4ZTZlNTVkNmMsIGVicCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQg c3luY2VyIHBpZCA1OSB0aWQgMTAwMDU0IHRkIDB4YzY4ZDI5YzAKc2NoZWRfc3dpdGNoKGM2OGQy OWMwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTQzCm1pX3N3aXRjaCgxLDAsYzY4ZDI5YzAsZTZl NTJjYjAsYzA2ZDIwNzAsLi4uKSBhdCBtaV9zd2l0Y2grMHgxYmEKc2xlZXBxX3N3aXRjaChjMGE2 YjJiYykgYXQgc2xlZXBxX3N3aXRjaCsweDg3CnNsZWVwcV93YWl0KGMwYTZiMmJjLDAsYzY4ZDI5 YzAsMCxjNjliN2FjYywuLi4pIGF0IHNsZWVwcV93YWl0KzB4NWMKbXNsZWVwKGMwYTZiMmJjLDAs NjgsYzA5NmMzMTAsMCkgYXQgbXNsZWVwKzB4MjY5CnNjaGVkX3N5bmMoMCxlNmU1MmQzOCkgYXQg c2NoZWRfc3luYysweDNkYwpmb3JrX2V4aXQoYzA3MGQwM2MsMCxlNmU1MmQzOCkgYXQgZm9ya19l eGl0KzB4NzEKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJh cCAweDEsIGVpcCA9IDAsIGVzcCA9IDB4ZTZlNTJkNmMsIGVicCA9IDAgLS0tCgpUcmFjaW5nIGNv bW1hbmQgYnVmZGFlbW9uIHBpZCA1OCB0aWQgMTAwMDU1IHRkIDB4YzY4ZDI4MjAKc2NoZWRfc3dp dGNoKGM2OGQyODIwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTQzCm1pX3N3aXRjaCgxLDAsYzY4 ZDI4MjAsZTZlNGZjZDAsYzA2ZDIxNmMsLi4uKSBhdCBtaV9zd2l0Y2grMHgxYmEKc2xlZXBxX3N3 aXRjaChjMGE3NmVhMCxjNjhkMjgyMCxlNmU0ZmNmMCxjMDZiN2MyNSxjMGE3NmVhMCwuLi4pIGF0 IHNsZWVwcV9zd2l0Y2grMHg4NwpzbGVlcHFfdGltZWR3YWl0KGMwYTc2ZWEwKSBhdCBzbGVlcHFf dGltZWR3YWl0KzB4NWMKbXNsZWVwKGMwYTc2ZWEwLGMwYTc2ZWMwLDQ0LGMwOTZiMjg5LDNlOCkg YXQgbXNsZWVwKzB4MjQ1CmJ1Zl9kYWVtb24oMCxlNmU0ZmQzOCkgYXQgYnVmX2RhZW1vbisweDE3 Mwpmb3JrX2V4aXQoYzA2ZmQyNzQsMCxlNmU0ZmQzOCkgYXQgZm9ya19leGl0KzB4NzEKZm9ya190 cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAweDEsIGVpcCA9IDAs IGVzcCA9IDB4ZTZlNGZkNmMsIGVicCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgcGFnZXplcm8g cGlkIDU3IHRpZCAxMDAwNTYgdGQgMHhjNjhkMjY4MApzY2hlZF9zd2l0Y2goYzY4ZDI2ODAsMCwx KSBhdCBzY2hlZF9zd2l0Y2grMHgxNDMKbWlfc3dpdGNoKDEsMCxjNjhkMjY4MCxlNmU0Y2NkNCxj MDZkMjE2YywuLi4pIGF0IG1pX3N3aXRjaCsweDFiYQpzbGVlcHFfc3dpdGNoKGMwYTg1NmM0LDQs ZTZlNGNjZjQsYzA2YjdjMjUsYzBhODU2YzQsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4ODcKc2xl ZXBxX3RpbWVkd2FpdChjMGE4NTZjNCkgYXQgc2xlZXBxX3RpbWVkd2FpdCsweDVjCm1zbGVlcChj MGE4NTZjNCxjMGE4NTE0MCwyMDAsYzA5N2Q5ZmMsNDkzZTApIGF0IG1zbGVlcCsweDI0NQp2bV9w YWdlemVybygwLGU2ZTRjZDM4KSBhdCB2bV9wYWdlemVybysweDhhCmZvcmtfZXhpdChjMDg0N2Nj NCwwLGU2ZTRjZDM4KSBhdCBmb3JrX2V4aXQrMHg3MQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3Jr X3RyYW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDB4MSwgZWlwID0gMCwgZXNwID0gMHhlNmU0Y2Q2Yywg ZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCB2bWRhZW1vbiBwaWQgNTYgdGlkIDEwMDA1NyB0 ZCAweGM2OGQyNGUwCnNjaGVkX3N3aXRjaChjNjhkMjRlMCwwLDEpIGF0IHNjaGVkX3N3aXRjaCsw eDE0MwptaV9zd2l0Y2goMSwwLGM2OGQyNGUwLGU2ZTQ5Y2E4LGMwNmQyMDcwLC4uLikgYXQgbWlf c3dpdGNoKzB4MWJhCnNsZWVwcV9zd2l0Y2goYzBhODUxZDQpIGF0IHNsZWVwcV9zd2l0Y2grMHg4 NwpzbGVlcHFfd2FpdChjMGE4NTFkNCwwLGM2OGQyNGUwLGM2OWEzMjE4LGMwODQ2YWZjLC4uLikg YXQgc2xlZXBxX3dhaXQrMHg1Ywptc2xlZXAoYzBhODUxZDQsYzBhODUxZTAsNjgsYzA5NmIyODks MCwuLi4pIGF0IG1zbGVlcCsweDI2OQp2bV9kYWVtb24oMCxlNmU0OWQzOCkgYXQgdm1fZGFlbW9u KzB4NTMKZm9ya19leGl0KGMwODQ2YWZjLDAsZTZlNDlkMzgpIGF0IGZvcmtfZXhpdCsweDcxCmZv cmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMHgxLCBlaXAg PSAwLCBlc3AgPSAweGU2ZTQ5ZDZjLCBlYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIHBhZ2Vk YWVtb24gcGlkIDU1IHRpZCAxMDAwNTggdGQgMHhjNjhkMjM0MApzY2hlZF9zd2l0Y2goYzY4ZDIz NDAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNDMKbWlfc3dpdGNoKDEsMCxjNjhkMjM0MCxlNmU0 NmNjYyxjMDZkMjE2YywuLi4pIGF0IG1pX3N3aXRjaCsweDFiYQpzbGVlcHFfc3dpdGNoKGMwYTg1 MTg4LGM2OGQyMzQwLGU2ZTQ2Y2VjLGMwNmI3YzI1LGMwYTg1MTg4LC4uLikgYXQgc2xlZXBxX3N3 aXRjaCsweDg3CnNsZWVwcV90aW1lZHdhaXQoYzBhODUxODgpIGF0IHNsZWVwcV90aW1lZHdhaXQr MHg1Ywptc2xlZXAoYzBhODUxODgsYzBhODUxNDAsNDQsYzA5NmIyODksMTM4OCkgYXQgbXNsZWVw KzB4MjQ1CnZtX3BhZ2VvdXQoMCxlNmU0NmQzOCkgYXQgdm1fcGFnZW91dCsweDI4MApmb3JrX2V4 aXQoYzA4NDY2ZjgsMCxlNmU0NmQzOCkgYXQgZm9ya19leGl0KzB4NzEKZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAweDEsIGVpcCA9IDAsIGVzcCA9IDB4 ZTZlNDZkNmMsIGVicCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgaXJxMTogYXRrYmQwIHBpZCA1 NCB0aWQgMTAwMDU5IHRkIDB4YzY4ZDIxYTAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFt cG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgc3dpMDogc2lvIHBpZCA1MyB0aWQgMTAwMDYwIHRkIDB4 YzY5YTczNDAKc2NoZWRfc3dpdGNoKGM2OWE3MzQwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTQz Cm1pX3N3aXRjaCgxLDApIGF0IG1pX3N3aXRjaCsweDFiYQppdGhyZWFkX2xvb3AoYzY5YWM0ZTAs ZWFmYTJkMzgpIGF0IGl0aHJlYWRfbG9vcCsweGQ5CmZvcmtfZXhpdChjMDY5N2ViOCxjNjlhYzRl MCxlYWZhMmQzOCkgYXQgZm9ya19leGl0KzB4NzEKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190 cmFtcG9saW5lKzB4OAotLS0gdHJhcCAweDEsIGVpcCA9IDAsIGVzcCA9IDB4ZWFmYTJkNmMsIGVi cCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgaXJxMjE6IGF0YXBjaTEgcGlkIDUyIHRpZCAxMDAw NjEgdGQgMHhjNjlhNzFhMApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRy YWNpbmcgY29tbWFuZCBpcnExNTogYXRhMSBwaWQgNTEgdGlkIDEwMDA2MiB0ZCAweGM2OWE3MDAw CmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5kIGly cTE0OiBhdGEwIHBpZCA1MCB0aWQgMTAwMDM4IHRkIDB4YzY4ZDE2ODAKc2NoZWRfc3dpdGNoKGM2 OGQxNjgwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTQzCm1pX3N3aXRjaCgxLDApIGF0IG1pX3N3 aXRjaCsweDFiYQppdGhyZWFkX2xvb3AoYzY5YTE0NDAsZTZlMzFkMzgpIGF0IGl0aHJlYWRfbG9v cCsweGQ5CmZvcmtfZXhpdChjMDY5N2ViOCxjNjlhMTQ0MCxlNmUzMWQzOCkgYXQgZm9ya19leGl0 KzB4NzEKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAw eDEsIGVpcCA9IDAsIGVzcCA9IDB4ZTZlMzFkNmMsIGVicCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1h bmQgdXNiNiBwaWQgNDkgdGlkIDEwMDAzOSB0ZCAweGM2OGQxNGUwCnNjaGVkX3N3aXRjaChjNjhk MTRlMCwwLDEpIGF0IHNjaGVkX3N3aXRjaCsweDE0MwptaV9zd2l0Y2goMSwwLGM2OGQxNGUwLGU2 ZTJlY2NjLGMwNmQyMTZjLC4uLikgYXQgbWlfc3dpdGNoKzB4MWJhCnNsZWVwcV9zd2l0Y2goYzY4 YzgyMTAsYzY4ZDE0ZTAsZTZlMmVjZWMsYzA2YjdjMjUsYzY4YzgyMTAsLi4uKSBhdCBzbGVlcHFf c3dpdGNoKzB4ODcKc2xlZXBxX3RpbWVkd2FpdChjNjhjODIxMCkgYXQgc2xlZXBxX3RpbWVkd2Fp dCsweDVjCm1zbGVlcChjNjhjODIxMCwwLDVjLGMwOTYwMGVlLGVhNjAsYzY5OTBhNDApIGF0IG1z bGVlcCsweDI0NQp1c2JfZXZlbnRfdGhyZWFkKGM2OTkwYTQwLGU2ZTJlZDM4KSBhdCB1c2JfZXZl bnRfdGhyZWFkKzB4OTAKZm9ya19leGl0KGMwNjQ0YTgwLGM2OTkwYTQwLGU2ZTJlZDM4KSBhdCBm b3JrX2V4aXQrMHg3MQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4Ci0t LSB0cmFwIDB4MSwgZWlwID0gMCwgZXNwID0gMHhlNmUyZWQ2YywgZWJwID0gMCAtLS0KClRyYWNp bmcgY29tbWFuZCB1c2I1IHBpZCA0OCB0aWQgMTAwMDQwIHRkIDB4YzY4ZDEzNDAKc2NoZWRfc3dp dGNoKGM2OGQxMzQwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTQzCm1pX3N3aXRjaCgxLDAsYzY4 ZDEzNDAsZTZlMmJjY2MsYzA2ZDIxNmMsLi4uKSBhdCBtaV9zd2l0Y2grMHgxYmEKc2xlZXBxX3N3 aXRjaChjNjk4NzIxMCxjNjhkMTM0MCxlNmUyYmNlYyxjMDZiN2MyNSxjNjk4NzIxMCwuLi4pIGF0 IHNsZWVwcV9zd2l0Y2grMHg4NwpzbGVlcHFfdGltZWR3YWl0KGM2OTg3MjEwKSBhdCBzbGVlcHFf dGltZWR3YWl0KzB4NWMKbXNsZWVwKGM2OTg3MjEwLDAsNWMsYzA5NjAwZWUsZWE2MCxjNjk3NTBj MCkgYXQgbXNsZWVwKzB4MjQ1CnVzYl9ldmVudF90aHJlYWQoYzY5NzUwYzAsZTZlMmJkMzgpIGF0 IHVzYl9ldmVudF90aHJlYWQrMHg5MApmb3JrX2V4aXQoYzA2NDRhODAsYzY5NzUwYzAsZTZlMmJk MzgpIGF0IGZvcmtfZXhpdCsweDcxCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGlu ZSsweDgKLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGU2ZTJiZDZjLCBlYnAgPSAwIC0t LQoKVHJhY2luZyBjb21tYW5kIHVzYjQgcGlkIDQ3IHRpZCAxMDAwNDEgdGQgMHhjNjhkMTFhMApz Y2hlZF9zd2l0Y2goYzY4ZDExYTAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNDMKbWlfc3dpdGNo KDEsMCxjNjhkMTFhMCxlNmUyOGNjYyxjMDZkMjE2YywuLi4pIGF0IG1pX3N3aXRjaCsweDFiYQpz bGVlcHFfc3dpdGNoKGM2OTdmMjEwLGM2OGQxMWEwLGU2ZTI4Y2VjLGMwNmI3YzI1LGM2OTdmMjEw LC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDg3CnNsZWVwcV90aW1lZHdhaXQoYzY5N2YyMTApIGF0 IHNsZWVwcV90aW1lZHdhaXQrMHg1Ywptc2xlZXAoYzY5N2YyMTAsMCw1YyxjMDk2MDBlZSxlYTYw LGM2OTc0MWMwKSBhdCBtc2xlZXArMHgyNDUKdXNiX2V2ZW50X3RocmVhZChjNjk3NDFjMCxlNmUy OGQzOCkgYXQgdXNiX2V2ZW50X3RocmVhZCsweDkwCmZvcmtfZXhpdChjMDY0NGE4MCxjNjk3NDFj MCxlNmUyOGQzOCkgYXQgZm9ya19leGl0KzB4NzEKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190 cmFtcG9saW5lKzB4OAotLS0gdHJhcCAweDEsIGVpcCA9IDAsIGVzcCA9IDB4ZTZlMjhkNmMsIGVi cCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgdXNiMyBwaWQgNDYgdGlkIDEwMDA0MiB0ZCAweGM2 OGQxMDAwCnNjaGVkX3N3aXRjaChjNjhkMTAwMCwwLDEpIGF0IHNjaGVkX3N3aXRjaCsweDE0Mwpt aV9zd2l0Y2goMSwwLGM2OGQxMDAwLGU2ZTI1Y2NjLGMwNmQyMTZjLC4uLikgYXQgbWlfc3dpdGNo KzB4MWJhCnNsZWVwcV9zd2l0Y2goYzY5NjIyMTAsYzY4ZDEwMDAsZTZlMjVjZWMsYzA2YjdjMjUs YzY5NjIyMTAsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4ODcKc2xlZXBxX3RpbWVkd2FpdChjNjk2 MjIxMCkgYXQgc2xlZXBxX3RpbWVkd2FpdCsweDVjCm1zbGVlcChjNjk2MjIxMCwwLDVjLGMwOTYw MGVlLGVhNjAsYzY5NzRhODApIGF0IG1zbGVlcCsweDI0NQp1c2JfZXZlbnRfdGhyZWFkKGM2OTc0 YTgwLGU2ZTI1ZDM4KSBhdCB1c2JfZXZlbnRfdGhyZWFkKzB4OTAKZm9ya19leGl0KGMwNjQ0YTgw LGM2OTc0YTgwLGU2ZTI1ZDM4KSBhdCBmb3JrX2V4aXQrMHg3MQpmb3JrX3RyYW1wb2xpbmUoKSBh dCBmb3JrX3RyYW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDB4MSwgZWlwID0gMCwgZXNwID0gMHhlNmUy NWQ2YywgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCBpcnExNjogbWZpMCBwaWQgNDUgdGlk IDEwMDA0MyB0ZCAweGM2ODIzZDAwCnNjaGVkX3N3aXRjaChjNjgyM2QwMCwwLDEpIGF0IHNjaGVk X3N3aXRjaCsweDE0MwptaV9zd2l0Y2goMSwwKSBhdCBtaV9zd2l0Y2grMHgxYmEKaXRocmVhZF9s b29wKGM2OTU5NjkwLGU2ZTIyZDM4KSBhdCBpdGhyZWFkX2xvb3ArMHhkOQpmb3JrX2V4aXQoYzA2 OTdlYjgsYzY5NTk2OTAsZTZlMjJkMzgpIGF0IGZvcmtfZXhpdCsweDcxCmZvcmtfdHJhbXBvbGlu ZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAw eGU2ZTIyZDZjLCBlYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIHVzYjIgcGlkIDQ0IHRpZCAx MDAwNDQgdGQgMHhjNjgyM2I2MApzY2hlZF9zd2l0Y2goYzY4MjNiNjAsMCwxKSBhdCBzY2hlZF9z d2l0Y2grMHgxNDMKbWlfc3dpdGNoKDEsMCxjNjgyM2I2MCxlNmUxZmNjYyxjMDZkMjE2YywuLi4p IGF0IG1pX3N3aXRjaCsweDFiYQpzbGVlcHFfc3dpdGNoKGM2OGM3MjEwLGM2ODIzYjYwLGU2ZTFm Y2VjLGMwNmI3YzI1LGM2OGM3MjEwLC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDg3CnNsZWVwcV90 aW1lZHdhaXQoYzY4YzcyMTApIGF0IHNsZWVwcV90aW1lZHdhaXQrMHg1Ywptc2xlZXAoYzY4Yzcy MTAsMCw1YyxjMDk2MDBlZSxlYTYwLGM2OTRjNDAwKSBhdCBtc2xlZXArMHgyNDUKdXNiX2V2ZW50 X3RocmVhZChjNjk0YzQwMCxlNmUxZmQzOCkgYXQgdXNiX2V2ZW50X3RocmVhZCsweDkwCmZvcmtf ZXhpdChjMDY0NGE4MCxjNjk0YzQwMCxlNmUxZmQzOCkgYXQgZm9ya19leGl0KzB4NzEKZm9ya190 cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAweDEsIGVpcCA9IDAs IGVzcCA9IDB4ZTZlMWZkNmMsIGVicCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgaXJxMTk6IGVo Y2kwIHVoY2k0IHBpZCA0MyB0aWQgMTAwMDQ1IHRkIDB4YzY4MjM5YzAKZm9ya190cmFtcG9saW5l KCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1hbmQgdXNiMSBwaWQgNDIgdGlkIDEw MDA0NiB0ZCAweGM2OTVjODIwCnNjaGVkX3N3aXRjaChjNjk1YzgyMCwwLDEpIGF0IHNjaGVkX3N3 aXRjaCsweDE0MwptaV9zd2l0Y2goMSwwLGM2OTVjODIwLGVhZTdhY2NjLGMwNmQyMTZjLC4uLikg YXQgbWlfc3dpdGNoKzB4MWJhCnNsZWVwcV9zd2l0Y2goYzY5NTAyMTAsYzY5NWM4MjAsZWFlN2Fj ZWMsYzA2YjdjMjUsYzY5NTAyMTAsLi4uKSBhdCBzbGVlcHFfc3dpdGNoKzB4ODcKc2xlZXBxX3Rp bWVkd2FpdChjNjk1MDIxMCkgYXQgc2xlZXBxX3RpbWVkd2FpdCsweDVjCm1zbGVlcChjNjk1MDIx MCwwLDVjLGMwOTYwMGVlLGVhNjAsYzY5NGNlMDApIGF0IG1zbGVlcCsweDI0NQp1c2JfZXZlbnRf dGhyZWFkKGM2OTRjZTAwLGVhZTdhZDM4KSBhdCB1c2JfZXZlbnRfdGhyZWFkKzB4OTAKZm9ya19l eGl0KGMwNjQ0YTgwLGM2OTRjZTAwLGVhZTdhZDM4KSBhdCBmb3JrX2V4aXQrMHg3MQpmb3JrX3Ry YW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDB4MSwgZWlwID0gMCwg ZXNwID0gMHhlYWU3YWQ2YywgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCBpcnExODogdWhj aTEgdWhjaTMgcGlkIDQxIHRpZCAxMDAwNDcgdGQgMHhjNjk1YzY4MApmb3JrX3RyYW1wb2xpbmUo KSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB1c2J0YXNrIHBpZCA0MCB0aWQg MTAwMDQ4IHRkIDB4YzY5NWM0ZTAKc2NoZWRfc3dpdGNoKGM2OTVjNGUwLDAsMSkgYXQgc2NoZWRf c3dpdGNoKzB4MTQzCm1pX3N3aXRjaCgxLDAsYzY5NWM0ZTAsZWFlNzRjZDQsYzA2ZDIwNzAsLi4u KSBhdCBtaV9zd2l0Y2grMHgxYmEKc2xlZXBxX3N3aXRjaChjMGE2N2MyNCkgYXQgc2xlZXBxX3N3 aXRjaCsweDg3CnNsZWVwcV93YWl0KGMwYTY3YzI0LDAsYzY5NWM0ZTAsYzY5NWJjOTAsYzA2NDRi MzAsLi4uKSBhdCBzbGVlcHFfd2FpdCsweDVjCm1zbGVlcChjMGE2N2MyNCwwLDVjLGMwOTYwMGY1 LDAsLi4uKSBhdCBtc2xlZXArMHgyNjkKdXNiX3Rhc2tfdGhyZWFkKDAsZWFlNzRkMzgpIGF0IHVz Yl90YXNrX3RocmVhZCsweDYzCmZvcmtfZXhpdChjMDY0NGIzMCwwLGVhZTc0ZDM4KSBhdCBmb3Jr X2V4aXQrMHg3MQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4Ci0tLSB0 cmFwIDB4MSwgZWlwID0gMCwgZXNwID0gMHhlYWU3NGQ2YywgZWJwID0gMCAtLS0KClRyYWNpbmcg Y29tbWFuZCB1c2IwIHBpZCAzOSB0aWQgMTAwMDQ5IHRkIDB4YzY5NWMzNDAKc2NoZWRfc3dpdGNo KGM2OTVjMzQwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTQzCm1pX3N3aXRjaCgxLDAsYzY5NWMz NDAsZWFlNzFjY2MsYzA2ZDIxNmMsLi4uKSBhdCBtaV9zd2l0Y2grMHgxYmEKc2xlZXBxX3N3aXRj aChjNjhkNzIxMCxjNjk1YzM0MCxlYWU3MWNlYyxjMDZiN2MyNSxjNjhkNzIxMCwuLi4pIGF0IHNs ZWVwcV9zd2l0Y2grMHg4NwpzbGVlcHFfdGltZWR3YWl0KGM2OGQ3MjEwKSBhdCBzbGVlcHFfdGlt ZWR3YWl0KzB4NWMKbXNsZWVwKGM2OGQ3MjEwLDAsNWMsYzA5NjAwZWUsZWE2MCxjNjk0ZGI4MCkg YXQgbXNsZWVwKzB4MjQ1CnVzYl9ldmVudF90aHJlYWQoYzY5NGRiODAsZWFlNzFkMzgpIGF0IHVz Yl9ldmVudF90aHJlYWQrMHg5MApmb3JrX2V4aXQoYzA2NDRhODAsYzY5NGRiODAsZWFlNzFkMzgp IGF0IGZvcmtfZXhpdCsweDcxCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsw eDgKLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGVhZTcxZDZjLCBlYnAgPSAwIC0tLQoK VHJhY2luZyBjb21tYW5kIGlycTE3OiB1aGNpMCB1aGNpKyBwaWQgMzggdGlkIDEwMDAyNyB0ZCAw eGM2N2MyZDAwCnNjaGVkX3N3aXRjaChjNjdjMmQwMCwwLDEpIGF0IHNjaGVkX3N3aXRjaCsweDE0 MwptaV9zd2l0Y2goMSwwKSBhdCBtaV9zd2l0Y2grMHgxYmEKaXRocmVhZF9sb29wKGM2OTQ0NWQw LGU1M2U0ZDM4KSBhdCBpdGhyZWFkX2xvb3ArMHhkOQpmb3JrX2V4aXQoYzA2OTdlYjgsYzY5NDQ1 ZDAsZTUzZTRkMzgpIGF0IGZvcmtfZXhpdCsweDcxCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtf dHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGU1M2U0ZDZjLCBl YnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIGlycTQwOiBiY2UxIHBpZCAzNyB0aWQgMTAwMDI4 IHRkIDB4YzY3YzJiNjAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFj aW5nIGNvbW1hbmQgaXJxMjg6IGJjZTAgcGlkIDM2IHRpZCAxMDAwMjkgdGQgMHhjNjdjMjljMApz Y2hlZF9zd2l0Y2goYzY3YzI5YzAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNDMKbWlfc3dpdGNo KDEsMCkgYXQgbWlfc3dpdGNoKzB4MWJhCml0aHJlYWRfbG9vcChjNjkzMDcyMCxlNTNkZWQzOCkg YXQgaXRocmVhZF9sb29wKzB4ZDkKZm9ya19leGl0KGMwNjk3ZWI4LGM2OTMwNzIwLGU1M2RlZDM4 KSBhdCBmb3JrX2V4aXQrMHg3MQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUr MHg4Ci0tLSB0cmFwIDB4MSwgZWlwID0gMCwgZXNwID0gMHhlNTNkZWQ2YywgZWJwID0gMCAtLS0K ClRyYWNpbmcgY29tbWFuZCBpcnE5OiBhY3BpMCBwaWQgMzUgdGlkIDEwMDAzMCB0ZCAweGM2N2My ODIwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZQoKVHJhY2luZyBjb21tYW5k IHN3aTY6IHRhc2sgcXVldWUgcGlkIDM0IHRpZCAxMDAwMzEgdGQgMHhjNjdjMjY4MApzY2hlZF9z d2l0Y2goYzY3YzI2ODAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNDMKbWlfc3dpdGNoKDEsMCkg YXQgbWlfc3dpdGNoKzB4MWJhCml0aHJlYWRfbG9vcChjNjg2YzRhMCxlNTNkOGQzOCkgYXQgaXRo cmVhZF9sb29wKzB4ZDkKZm9ya19leGl0KGMwNjk3ZWI4LGM2ODZjNGEwLGU1M2Q4ZDM4KSBhdCBm b3JrX2V4aXQrMHg3MQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4Ci0t LSB0cmFwIDB4MSwgZWlwID0gMCwgZXNwID0gMHhlNTNkOGQ2YywgZWJwID0gMCAtLS0KClRyYWNp bmcgY29tbWFuZCBzd2kyOiBjYW1iaW8gcGlkIDMzIHRpZCAxMDAwMzIgdGQgMHhjNjdjMjRlMApm b3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNpbmcgY29tbWFuZCB4cHRf dGhyZCBwaWQgMzIgdGlkIDEwMDAzMyB0ZCAweGM2OGQyMDAwCnNjaGVkX3N3aXRjaChjNjhkMjAw MCwwLDEpIGF0IHNjaGVkX3N3aXRjaCsweDE0MwptaV9zd2l0Y2goMSwwLGM2OGQyMDAwLGU2ZTQw Y2QwLGMwNmQyMDcwLC4uLikgYXQgbWlfc3dpdGNoKzB4MWJhCnNsZWVwcV9zd2l0Y2goYzBhNGRi NjQpIGF0IHNsZWVwcV9zd2l0Y2grMHg4NwpzbGVlcHFfd2FpdChjMGE0ZGI2NCwwLGM2OGQyMDAw LGM2OGQwYTc4LGMwNDViZjg0LC4uLikgYXQgc2xlZXBxX3dhaXQrMHg1Ywptc2xlZXAoYzBhNGRi NjQsMCw0YyxjMDkyNmNlNSwwKSBhdCBtc2xlZXArMHgyNjkKeHB0X3NjYW5uZXJfdGhyZWFkKDAs ZTZlNDBkMzgpIGF0IHhwdF9zY2FubmVyX3RocmVhZCsweDRkCmZvcmtfZXhpdChjMDQ1YmY4NCww LGU2ZTQwZDM4KSBhdCBmb3JrX2V4aXQrMHg3MQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3Ry YW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDB4MSwgZWlwID0gMCwgZXNwID0gMHhlNmU0MGQ2YywgZWJw ID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCBrcXVldWUgdGFza3EgcGlkIDkgdGlkIDEwMDAzNCB0 ZCAweGM2OGQxZDAwCnNjaGVkX3N3aXRjaChjNjhkMWQwMCwwLDEpIGF0IHNjaGVkX3N3aXRjaCsw eDE0MwptaV9zd2l0Y2goMSwwLGM2OGQxZDAwLGU2ZTNkY2M4LGMwNmQyMDcwLC4uLikgYXQgbWlf c3dpdGNoKzB4MWJhCnNsZWVwcV9zd2l0Y2goYzY4Y2ZiMDApIGF0IHNsZWVwcV9zd2l0Y2grMHg4 NwpzbGVlcHFfd2FpdChjNjhjZmIwMCwwLGM2OGQxZDAwLGM2OGNmYjAwLGM2OGNmYjFjLC4uLikg YXQgc2xlZXBxX3dhaXQrMHg1Ywptc2xlZXAoYzY4Y2ZiMDAsYzY4Y2ZiMWMsMCxjMDk2MjdiMyww KSBhdCBtc2xlZXArMHgyNjkKdGFza3F1ZXVlX3RocmVhZF9sb29wKGMwYTY4ZGMwLGU2ZTNkZDM4 KSBhdCB0YXNrcXVldWVfdGhyZWFkX2xvb3ArMHhjMApmb3JrX2V4aXQoYzA2ZDM5Y2MsYzBhNjhk YzAsZTZlM2RkMzgpIGF0IGZvcmtfZXhpdCsweDcxCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtf dHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGU2ZTNkZDZjLCBl YnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIGFjcGlfdGFza18yIHBpZCA4IHRpZCAxMDAwMzUg dGQgMHhjNjhkMWI2MApzY2hlZF9zd2l0Y2goYzY4ZDFiNjAsMCwxKSBhdCBzY2hlZF9zd2l0Y2gr MHgxNDMKbWlfc3dpdGNoKDEsMCxjNjhkMWI2MCxlNmUzYWNjOCxjMDZkMjA3MCwuLi4pIGF0IG1p X3N3aXRjaCsweDFiYQpzbGVlcHFfc3dpdGNoKGM2OGNmYjgwKSBhdCBzbGVlcHFfc3dpdGNoKzB4 ODcKc2xlZXBxX3dhaXQoYzY4Y2ZiODAsMCxjNjhkMWI2MCxjNjhjZmI4MCxjNjhjZmI5YywuLi4p IGF0IHNsZWVwcV93YWl0KzB4NWMKbXNsZWVwKGM2OGNmYjgwLGM2OGNmYjljLDAsYzA5NjI3YjMs MCkgYXQgbXNsZWVwKzB4MjY5CnRhc2txdWV1ZV90aHJlYWRfbG9vcChjMGJmOTFhMCxlNmUzYWQz OCkgYXQgdGFza3F1ZXVlX3RocmVhZF9sb29wKzB4YzAKZm9ya19leGl0KGMwNmQzOWNjLGMwYmY5 MWEwLGU2ZTNhZDM4KSBhdCBmb3JrX2V4aXQrMHg3MQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3Jr X3RyYW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDB4MSwgZWlwID0gMCwgZXNwID0gMHhlNmUzYWQ2Yywg ZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCBhY3BpX3Rhc2tfMSBwaWQgNyB0aWQgMTAwMDM2 IHRkIDB4YzY4ZDE5YzAKc2NoZWRfc3dpdGNoKGM2OGQxOWMwLDAsMSkgYXQgc2NoZWRfc3dpdGNo KzB4MTQzCm1pX3N3aXRjaCgxLDAsYzY4ZDE5YzAsZTZlMzdjYzgsYzA2ZDIwNzAsLi4uKSBhdCBt aV9zd2l0Y2grMHgxYmEKc2xlZXBxX3N3aXRjaChjNjhjZmI4MCkgYXQgc2xlZXBxX3N3aXRjaCsw eDg3CnNsZWVwcV93YWl0KGM2OGNmYjgwLDAsYzY4ZDE5YzAsYzY4Y2ZiODAsYzY4Y2ZiOWMsLi4u KSBhdCBzbGVlcHFfd2FpdCsweDVjCm1zbGVlcChjNjhjZmI4MCxjNjhjZmI5YywwLGMwOTYyN2Iz LDApIGF0IG1zbGVlcCsweDI2OQp0YXNrcXVldWVfdGhyZWFkX2xvb3AoYzBiZjkxYTAsZTZlMzdk MzgpIGF0IHRhc2txdWV1ZV90aHJlYWRfbG9vcCsweGMwCmZvcmtfZXhpdChjMDZkMzljYyxjMGJm OTFhMCxlNmUzN2QzOCkgYXQgZm9ya19leGl0KzB4NzEKZm9ya190cmFtcG9saW5lKCkgYXQgZm9y a190cmFtcG9saW5lKzB4OAotLS0gdHJhcCAweDEsIGVpcCA9IDAsIGVzcCA9IDB4ZTZlMzdkNmMs IGVicCA9IDAgLS0tCgpUcmFjaW5nIGNvbW1hbmQgYWNwaV90YXNrXzAgcGlkIDYgdGlkIDEwMDAz NyB0ZCAweGM2OGQxODIwCnNjaGVkX3N3aXRjaChjNjhkMTgyMCwwLDEpIGF0IHNjaGVkX3N3aXRj aCsweDE0MwptaV9zd2l0Y2goMSwwLGM2OGQxODIwLGU2ZTM0Y2M4LGMwNmQyMDcwLC4uLikgYXQg bWlfc3dpdGNoKzB4MWJhCnNsZWVwcV9zd2l0Y2goYzY4Y2ZiODApIGF0IHNsZWVwcV9zd2l0Y2gr MHg4NwpzbGVlcHFfd2FpdChjNjhjZmI4MCwwLGM2OGQxODIwLGM2OGNmYjgwLGM2OGNmYjljLC4u LikgYXQgc2xlZXBxX3dhaXQrMHg1Ywptc2xlZXAoYzY4Y2ZiODAsYzY4Y2ZiOWMsMCxjMDk2Mjdi MywwKSBhdCBtc2xlZXArMHgyNjkKdGFza3F1ZXVlX3RocmVhZF9sb29wKGMwYmY5MWEwLGU2ZTM0 ZDM4KSBhdCB0YXNrcXVldWVfdGhyZWFkX2xvb3ArMHhjMApmb3JrX2V4aXQoYzA2ZDM5Y2MsYzBi ZjkxYTAsZTZlMzRkMzgpIGF0IGZvcmtfZXhpdCsweDcxCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZv cmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGU2ZTM0ZDZj LCBlYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIHN3aTU6ICsgcGlkIDMxIHRpZCAxMDAwMTcg dGQgMHhjNjdiZTY4MApmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUKClRyYWNp bmcgY29tbWFuZCB0aHJlYWQgdGFza3EgcGlkIDUgdGlkIDEwMDAxOCB0ZCAweGM2N2JlNGUwCnNj aGVkX3N3aXRjaChjNjdiZTRlMCwwLDEpIGF0IHNjaGVkX3N3aXRjaCsweDE0MwptaV9zd2l0Y2go MSwwLGM2N2JlNGUwLGU1M2JhY2M4LGMwNmQyMDcwLC4uLikgYXQgbWlfc3dpdGNoKzB4MWJhCnNs ZWVwcV9zd2l0Y2goYzY4MjAzMDApIGF0IHNsZWVwcV9zd2l0Y2grMHg4NwpzbGVlcHFfd2FpdChj NjgyMDMwMCwwLGM2N2JlNGUwLGM2ODIwMzAwLGM2ODIwMzFjLC4uLikgYXQgc2xlZXBxX3dhaXQr MHg1Ywptc2xlZXAoYzY4MjAzMDAsYzY4MjAzMWMsMCxjMDk2MjdiMywwKSBhdCBtc2xlZXArMHgy NjkKdGFza3F1ZXVlX3RocmVhZF9sb29wKGMwYTc1M2U4LGU1M2JhZDM4KSBhdCB0YXNrcXVldWVf dGhyZWFkX2xvb3ArMHhjMApmb3JrX2V4aXQoYzA2ZDM5Y2MsYzBhNzUzZTgsZTUzYmFkMzgpIGF0 IGZvcmtfZXhpdCsweDcxCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJhbXBvbGluZSsweDgK LS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGU1M2JhZDZjLCBlYnAgPSAwIC0tLQoKVHJh Y2luZyBjb21tYW5kIHN3aTY6IEdpYW50IHRhc2txIHBpZCAzMCB0aWQgMTAwMDE5IHRkIDB4YzY3 YmUzNDAKZm9ya190cmFtcG9saW5lKCkgYXQgZm9ya190cmFtcG9saW5lCgpUcmFjaW5nIGNvbW1h bmQgeWFycm93IHBpZCAyOSB0aWQgMTAwMDIwIHRkIDB4YzY3YmUxYTAKc2NoZWRfc3dpdGNoKGM2 N2JlMWEwLDAsMSkgYXQgc2NoZWRfc3dpdGNoKzB4MTQzCm1pX3N3aXRjaCgxLDAsYzY3YmUxYTAs ZTUzYjRjYmMsYzA2ZDIxNmMsLi4uKSBhdCBtaV9zd2l0Y2grMHgxYmEKc2xlZXBxX3N3aXRjaChj MGE2NTk0MCw2LGU1M2I0Y2RjLGMwNmI3YzI1LGMwYTY1OTQwLC4uLikgYXQgc2xlZXBxX3N3aXRj aCsweDg3CnNsZWVwcV90aW1lZHdhaXQoYzBhNjU5NDApIGF0IHNsZWVwcV90aW1lZHdhaXQrMHg1 Ywptc2xlZXAoYzBhNjU5NDAsMCwwLGMwOTYyN2IzLDY0KSBhdCBtc2xlZXArMHgyNDUKcmFuZG9t X2t0aHJlYWQoMCxlNTNiNGQzOCkgYXQgcmFuZG9tX2t0aHJlYWQrMHgyMWMKZm9ya19leGl0KGMw NWYxYzEwLDAsZTUzYjRkMzgpIGF0IGZvcmtfZXhpdCsweDcxCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGU1M2I0 ZDZjLCBlYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIGdfZG93biBwaWQgNCB0aWQgMTAwMDIx IHRkIDB4YzY4MjM4MjAKc2NoZWRfc3dpdGNoKGM2ODIzODIwLDAsMSkgYXQgc2NoZWRfc3dpdGNo KzB4MTQzCm1pX3N3aXRjaCgxLDAsYzY4MjM4MjAsZTZlMTljYjgsYzA2ZDIxNmMsLi4uKSBhdCBt aV9zd2l0Y2grMHgxYmEKc2xlZXBxX3N3aXRjaChjMGE2ODUwOCxjNjgyMzgyMCxlNmUxOWNkOCxj MDZiN2MyNSxjMGE2ODUwOCwuLi4pIGF0IHNsZWVwcV9zd2l0Y2grMHg4NwpzbGVlcHFfdGltZWR3 YWl0KGMwYTY4NTA4KSBhdCBzbGVlcHFfdGltZWR3YWl0KzB4NWMKbXNsZWVwKGMwYTY4NTA4LGMw YTY4M2U4LDI0YyxjMDk2MjdiMyw2NCkgYXQgbXNsZWVwKzB4MjQ1CmdfaW9fc2NoZWR1bGVfZG93 bihjNjgyMzgyMCkgYXQgZ19pb19zY2hlZHVsZV9kb3duKzB4NTYKZ19kb3duX3Byb2Nib2R5KDAs ZTZlMTlkMzgpIGF0IGdfZG93bl9wcm9jYm9keSsweDkyCmZvcmtfZXhpdChjMDY3MjEzYywwLGU2 ZTE5ZDM4KSBhdCBmb3JrX2V4aXQrMHg3MQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1w b2xpbmUrMHg4Ci0tLSB0cmFwIDB4MSwgZWlwID0gMCwgZXNwID0gMHhlNmUxOWQ2YywgZWJwID0g MCAtLS0KClRyYWNpbmcgY29tbWFuZCBnX3VwIHBpZCAzIHRpZCAxMDAwMjIgdGQgMHhjNjgyMzY4 MApzY2hlZF9zd2l0Y2goYzY4MjM2ODAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNDMKbWlfc3dp dGNoKDEsMCxjNjgyMzY4MCxlNmUxNmNiYyxjMDZkMjE2YywuLi4pIGF0IG1pX3N3aXRjaCsweDFi YQpzbGVlcHFfc3dpdGNoKGMwYTY4NTA0LGM2ODIzNjgwLGU2ZTE2Y2RjLGMwNmI3YzI1LGMwYTY4 NTA0LC4uLikgYXQgc2xlZXBxX3N3aXRjaCsweDg3CnNsZWVwcV90aW1lZHdhaXQoYzBhNjg1MDQp IGF0IHNsZWVwcV90aW1lZHdhaXQrMHg1Ywptc2xlZXAoYzBhNjg1MDQsYzBhNjg0MjgsMjRjLGMw OTYyN2IzLDY0KSBhdCBtc2xlZXArMHgyNDUKZ19pb19zY2hlZHVsZV91cChjNjgyMzY4MCkgYXQg Z19pb19zY2hlZHVsZV91cCsweGNjCmdfdXBfcHJvY2JvZHkoMCxlNmUxNmQzOCkgYXQgZ191cF9w cm9jYm9keSsweDkyCmZvcmtfZXhpdChjMDY3MjBhNCwwLGU2ZTE2ZDM4KSBhdCBmb3JrX2V4aXQr MHg3MQpmb3JrX3RyYW1wb2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDB4 MSwgZWlwID0gMCwgZXNwID0gMHhlNmUxNmQ2YywgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFu ZCBnX2V2ZW50IHBpZCAyIHRpZCAxMDAwMjMgdGQgMHhjNjgyMzRlMApzY2hlZF9zd2l0Y2goYzY4 MjM0ZTAsMCwxKSBhdCBzY2hlZF9zd2l0Y2grMHgxNDMKbWlfc3dpdGNoKDEsMCxjNjgyMzRlMCxl NmUxM2NjNCxjMDZkMjE2YywuLi4pIGF0IG1pX3N3aXRjaCsweDFiYQpzbGVlcHFfc3dpdGNoKGMw YTY4NGZjLGM2ODIzNGUwLGU2ZTEzY2U0LGMwNmI3YzI1LGMwYTY4NGZjLC4uLikgYXQgc2xlZXBx X3N3aXRjaCsweDg3CnNsZWVwcV90aW1lZHdhaXQoYzBhNjg0ZmMpIGF0IHNsZWVwcV90aW1lZHdh aXQrMHg1Ywptc2xlZXAoYzBhNjg0ZmMsMCw0YyxjMDk2MjdiMyw2NCkgYXQgbXNsZWVwKzB4MjQ1 CmdfZXZlbnRfcHJvY2JvZHkoMCxlNmUxM2QzOCkgYXQgZ19ldmVudF9wcm9jYm9keSsweGNhCmZv cmtfZXhpdChjMDY3MjFkNCwwLGU2ZTEzZDM4KSBhdCBmb3JrX2V4aXQrMHg3MQpmb3JrX3RyYW1w b2xpbmUoKSBhdCBmb3JrX3RyYW1wb2xpbmUrMHg4Ci0tLSB0cmFwIDB4MSwgZWlwID0gMCwgZXNw ID0gMHhlNmUxM2Q2YywgZWJwID0gMCAtLS0KClRyYWNpbmcgY29tbWFuZCBzd2kzOiB2bSBwaWQg MjggdGlkIDEwMDAyNCB0ZCAweGM2ODIzMzQwCmZvcmtfdHJhbXBvbGluZSgpIGF0IGZvcmtfdHJh bXBvbGluZQoKVHJhY2luZyBjb21tYW5kIHN3aTQ6IGNsb2NrIHNpbyBwaWQgMjcgdGlkIDEwMDAy NSB0ZCAweGM2ODIzMWEwCnNjaGVkX3N3aXRjaChjNjgyMzFhMCwwLDEpIGF0IHNjaGVkX3N3aXRj aCsweDE0MwptaV9zd2l0Y2goMSwwKSBhdCBtaV9zd2l0Y2grMHgxYmEKaXRocmVhZF9sb29wKGM2 Nzk5OGYwLGU2ZTBkZDM4KSBhdCBpdGhyZWFkX2xvb3ArMHhkOQpmb3JrX2V4aXQoYzA2OTdlYjgs YzY3OTk4ZjAsZTZlMGRkMzgpIGF0IGZvcmtfZXhpdCsweDcxCmZvcmtfdHJhbXBvbGluZSgpIGF0 IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGU2ZTBk ZDZjLCBlYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIHN3aTE6IG5ldCBwaWQgMjYgdGlkIDEw MDAyNiB0ZCAweGM2ODIzMDAwCnNjaGVkX3N3aXRjaChjNjgyMzAwMCwwLDEpIGF0IHNjaGVkX3N3 aXRjaCsweDE0MwptaV9zd2l0Y2goMSwwKSBhdCBtaV9zd2l0Y2grMHgxYmEKaXRocmVhZF9sb29w KGM2Nzk5OTAwLGU2ZTBhZDM4KSBhdCBpdGhyZWFkX2xvb3ArMHhkOQpmb3JrX2V4aXQoYzA2OTdl YjgsYzY3OTk5MDAsZTZlMGFkMzgpIGF0IGZvcmtfZXhpdCsweDcxCmZvcmtfdHJhbXBvbGluZSgp IGF0IGZvcmtfdHJhbXBvbGluZSsweDgKLS0tIHRyYXAgMHgxLCBlaXAgPSAwLCBlc3AgPSAweGU2 ZTBhZDZjLCBlYnAgPSAwIC0tLQoKVHJhY2luZyBjb21tYW5kIGlkbGU6IGNwdTAgcGlkIDI1IHRp ZCAxMDAwMDggdGQgMHhjNjdiYzFhMApzY2hlZF9zd2l0Y2goMCxlNTM5OWMyYyxjMDlmZDQxOCw5 MzllLDAsLi4uKSBhdCBzY2hlZF9zd2l0Y2grMHgxNDMKKioqIGVycm9yIHJlYWRpbmcgZnJvbSBh ZGRyZXNzIGRkMzEzMTg0ICoqKgpkYj4gc2hvdyBwY2lyZWdzCmhvc3RiMEBwY2kwOjA6MDogICAg ICAgIGNsYXNzPTB4MDYwMDAwIGNhcmQ9MHg3MjcwMTAxNCBjaGlwPTB4MzQwNjgwODYgcmV2PTB4 MTMgaGRyPTB4MDAKcGNpYjFAcGNpMDoxOjA6IGNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgzNDA4MTAx NCBjaGlwPTB4MzQwODgwODYgcmV2PTB4MTMgaGRyPTB4MDEKcGNpYjJAcGNpMDoyOjA6IGNsYXNz PTB4MDYwNDAwIGNhcmQ9MHgzNDA5MTAxNCBjaGlwPTB4MzQwOTgwODYgcmV2PTB4MTMgaGRyPTB4 MDEKcGNpYjNAcGNpMDozOjA6IGNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgzNDBhMTAxNCBjaGlwPTB4 MzQwYTgwODYgcmV2PTB4MTMgaGRyPTB4MDEKcGNpYjRAcGNpMDo1OjA6IGNsYXNzPTB4MDYwNDAw IGNhcmQ9MHgzNDBjMTAxNCBjaGlwPTB4MzQwYzgwODYgcmV2PTB4MTMgaGRyPTB4MDEKcGNpYjVA cGNpMDo3OjA6IGNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgzNDBlMTAxNCBjaGlwPTB4MzQwZTgwODYg cmV2PTB4MTMgaGRyPTB4MDEKcGNpYjZAcGNpMDo5OjA6IGNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgz NDEwMTAxNCBjaGlwPTB4MzQxMDgwODYgcmV2PTB4MTMgaGRyPTB4MDEKbm9uZTBAcGNpMDoxNjow OiAgICAgICAgY2xhc3M9MHgwODAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgzNDI1ODA4NiBy ZXY9MHgxMyBoZHI9MHgwMApub25lMUBwY2kwOjE2OjE6ICAgICAgICBjbGFzcz0weDA4MDAwMCBj YXJkPTB4MDAwMDAwMDAgY2hpcD0weDM0MjY4MDg2IHJldj0weDEzIGhkcj0weDAwCm5vbmUyQHBj aTA6MTc6MDogICAgICAgIGNsYXNzPTB4MDgwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MzQy NzgwODYgcmV2PTB4MTMgaGRyPTB4MDAKbm9uZTNAcGNpMDoxNzoxOiAgICAgICAgY2xhc3M9MHgw ODAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgzNDI4ODA4NiByZXY9MHgxMyBoZHI9MHgwMApu b25lNEBwY2kwOjIwOjA6ICAgICAgICBjbGFzcz0weDA4MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hp cD0weDM0MmU4MDg2IHJldj0weDEzIGhkcj0weDAwCm5vbmU1QHBjaTA6MjA6MTogICAgICAgIGNs YXNzPTB4MDgwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MzQyMjgwODYgcmV2PTB4MTMgaGRy PTB4MDAKbm9uZTZAcGNpMDoyMDoyOiAgICAgICAgY2xhc3M9MHgwODAwMDAgY2FyZD0weDAwMDAw MDAwIGNoaXA9MHgzNDIzODA4NiByZXY9MHgxMyBoZHI9MHgwMApub25lN0BwY2kwOjIwOjM6ICAg ICAgICBjbGFzcz0weDA4MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDM0Mzg4MDg2IHJldj0w eDEzIGhkcj0weDAwCmlvYXBpYzBAcGNpMDoyMTowOiAgICAgIGNsYXNzPTB4MDgwMDIwIGNhcmQ9 MHgwMDAwMDAwMCBjaGlwPTB4MzQyZjgwODYgcmV2PTB4MTMgaGRyPTB4MDAKbm9uZThAcGNpMDoy MjowOiAgICAgICAgY2xhc3M9MHgwODgwMDAgY2FyZD0weDM0MzAxMDE0IGNoaXA9MHgzNDMwODA4 NiByZXY9MHgxMyBoZHI9MHgwMApub25lOUBwY2kwOjIyOjE6ICAgICAgICBjbGFzcz0weDA4ODAw MCBjYXJkPTB4MzQzMTEwMTQgY2hpcD0weDM0MzE4MDg2IHJldj0weDEzIGhkcj0weDAwCm5vbmUx MEBwY2kwOjIyOjI6ICAgICAgIGNsYXNzPTB4MDg4MDAwIGNhcmQ9MHgzNDMyMTAxNCBjaGlwPTB4 MzQzMjgwODYgcmV2PTB4MTMgaGRyPTB4MDAKbm9uZTExQHBjaTA6MjI6MzogICAgICAgY2xhc3M9 MHgwODgwMDAgY2FyZD0weDM0MzMxMDE0IGNoaXA9MHgzNDMzODA4NiByZXY9MHgxMyBoZHI9MHgw MApub25lMTJAcGNpMDoyMjo0OiAgICAgICBjbGFzcz0weDA4ODAwMCBjYXJkPTB4MzQyOTEwMTQg Y2hpcD0weDM0Mjk4MDg2IHJldj0weDEzIGhkcj0weDAwCm5vbmUxM0BwY2kwOjIyOjU6ICAgICAg IGNsYXNzPTB4MDg4MDAwIGNhcmQ9MHgzNDJhMTAxNCBjaGlwPTB4MzQyYTgwODYgcmV2PTB4MTMg aGRyPTB4MDAKbm9uZTE0QHBjaTA6MjI6NjogICAgICAgY2xhc3M9MHgwODgwMDAgY2FyZD0weDM0 MmIxMDE0IGNoaXA9MHgzNDJiODA4NiByZXY9MHgxMyBoZHI9MHgwMApub25lMTVAcGNpMDoyMjo3 OiAgICAgICBjbGFzcz0weDA4ODAwMCBjYXJkPTB4MzQyYzEwMTQgY2hpcD0weDM0MmM4MDg2IHJl dj0weDEzIGhkcj0weDAwCnVoY2kwQHBjaTA6MjY6MDogICAgICAgIGNsYXNzPTB4MGMwMzAwIGNh cmQ9MHgzYTM3MTAxNCBjaGlwPTB4M2EzNzgwODYgcmV2PTB4MDAgaGRyPTB4MDAKdWhjaTFAcGNp MDoyNjoxOiAgICAgICAgY2xhc3M9MHgwYzAzMDAgY2FyZD0weDNhMzgxMDE0IGNoaXA9MHgzYTM4 ODA4NiByZXY9MHgwMCBoZHI9MHgwMAplaGNpMEBwY2kwOjI2Ojc6ICAgICAgICBjbGFzcz0weDBj MDMyMCBjYXJkPTB4M2EzYzEwMTQgY2hpcD0weDNhM2M4MDg2IHJldj0weDAwIGhkcj0weDAwCnBj aWI3QHBjaTA6Mjg6MDogICAgICAgIGNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgzYTQwMTAxNCBjaGlw PTB4M2E0MDgwODYgcmV2PTB4MDAgaGRyPTB4MDEKcGNpYjhAcGNpMDoyODo0OiAgICAgICAgY2xh c3M9MHgwNjA0MDAgY2FyZD0weDNhNDgxMDE0IGNoaXA9MHgzYTQ4ODA4NiByZXY9MHgwMCBoZHI9 MHgwMQp1aGNpMkBwY2kwOjI5OjA6ICAgICAgICBjbGFzcz0weDBjMDMwMCBjYXJkPTB4M2EzNDEw MTQgY2hpcD0weDNhMzQ4MDg2IHJldj0weDAwIGhkcj0weDAwCnVoY2kzQHBjaTA6Mjk6MTogICAg ICAgIGNsYXNzPTB4MGMwMzAwIGNhcmQ9MHgzYTM1MTAxNCBjaGlwPTB4M2EzNTgwODYgcmV2PTB4 MDAgaGRyPTB4MDAKdWhjaTRAcGNpMDoyOToyOiAgICAgICAgY2xhc3M9MHgwYzAzMDAgY2FyZD0w eDNhMzYxMDE0IGNoaXA9MHgzYTM2ODA4NiByZXY9MHgwMCBoZHI9MHgwMAplaGNpMUBwY2kwOjI5 Ojc6ICAgICAgICBjbGFzcz0weDBjMDMyMCBjYXJkPTB4M2EzYTEwMTQgY2hpcD0weDNhM2E4MDg2 IHJldj0weDAwIGhkcj0weDAwCnBjaWIxMEBwY2kwOjMwOjA6ICAgICAgIGNsYXNzPTB4MDYwNDAx IGNhcmQ9MHgyNDRlMTAxNCBjaGlwPTB4MjQ0ZTgwODYgcmV2PTB4OTAgaGRyPTB4MDEKaXNhYjBA cGNpMDozMTowOiAgICAgICAgY2xhc3M9MHgwNjAxMDAgY2FyZD0weDNhMTgxMDE0IGNoaXA9MHgz YTE4ODA4NiByZXY9MHgwMCBoZHI9MHgwMAphdGFwY2kwQHBjaTA6MzE6MjogICAgICBjbGFzcz0w eDAxMDE4YSBjYXJkPTB4M2EyMDEwMTQgY2hpcD0weDNhMjA4MDg2IHJldj0weDAwIGhkcj0weDAw Cm5vbmUxNkBwY2kwOjMxOjM6ICAgICAgIGNsYXNzPTB4MGMwNTAwIGNhcmQ9MHgzYTMwMTAxNCBj aGlwPTB4M2EzMDgwODYgcmV2PTB4MDAgaGRyPTB4MDAKYXRhcGNpMUBwY2kwOjMxOjU6ICAgICAg Y2xhc3M9MHgwMTAxODUgY2FyZD0weDNhMjYxMDE0IGNoaXA9MHgzYTI2ODA4NiByZXY9MHgwMCBo ZHI9MHgwMApiY2UwQHBjaTExOjA6MDogY2xhc3M9MHgwMjAwMDAgY2FyZD0weDAzYTkxMDE0IGNo aXA9MHgxNjM5MTRlNCByZXY9MHgyMCBoZHI9MHgwMApiY2UxQHBjaTExOjA6MTogY2xhc3M9MHgw MjAwMDAgY2FyZD0weDAzYTkxMDE0IGNoaXA9MHgxNjM5MTRlNCByZXY9MHgyMCBoZHI9MHgwMApt ZmkwQHBjaTE6MDowOiAgY2xhc3M9MHgwMTA0MDAgY2FyZD0weDAzNjQxMDE0IGNoaXA9MHgwMDYw MTAwMCByZXY9MHgwNCBoZHI9MHgwMApwY2liOUBwY2k2OjA6MDogY2xhc3M9MHgwNjA0MDAgY2Fy ZD0weDAzNjkxMDE0IGNoaXA9MHgwNDUyMTAxYiByZXY9MHgwMSBoZHI9MHgwMQpub25lMTdAcGNp NzowOjA6ICAgICAgICBjbGFzcz0weDAzMDAwMCBjYXJkPTB4MDM2OTEwMTQgY2hpcD0weDA1MzAx MDJiIHJldj0weDAwIGhkcj0weDAwCmRiPiBzaG93IGludHJjbnQKaXJxNDogc2lvMCAgICAgICAg ICAgICAgNwppcnExNDogYXRhMCAgICAgICAgICAgICA0NwppcnExNjogbWZpMCAgICAgICAgICAg ICA3NTkyCmlycTE3OiB1aGNpMCB1aGNpKyAgICAgIDEKaXJxMjg6IGJjZTAgICAgICAgICAgICAg NzQ0MgpjcHUwOiB0aW1lciAgICAgICAgICAgICA5MTYwNDYKY3B1NjogdGltZXIgICAgICAgICAg ICAgOTEwMTczCmNwdTE1OiB0aW1lciAgICAgICAgICAgIDEzNTYKY3B1MTogdGltZXIgICAgICAg ICAgICAgNjIyCmNwdTI6IHRpbWVyICAgICAgICAgICAgIDkxMDIzOQpjcHUxNDogdGltZXIgICAg ICAgICAgICA5MTAyNDkKY3B1NDogdGltZXIgICAgICAgICAgICAgOTEwMTYxCmNwdTExOiB0aW1l ciAgICAgICAgICAgIDEzNTYKY3B1MzogdGltZXIgICAgICAgICAgICAgMTM1NgpjcHUxMjogdGlt ZXIgICAgICAgICAgICA5MTAyNTAKY3B1ODogdGltZXIgICAgICAgICAgICAgOTEwMjUwCmNwdTc6 IHRpbWVyICAgICAgICAgICAgIDEzNTYKY3B1MTM6IHRpbWVyICAgICAgICAgICAgMTM1NgpjcHU5 OiB0aW1lciAgICAgICAgICAgICAxMzU2CmNwdTU6IHRpbWVyICAgICAgICAgICAgIDEzNTYKY3B1 MTA6IHRpbWVyICAgICAgICAgICAgOTEwMjQ5CmRiPiBwcwogIHBpZCAgcHBpZCAgcGdycCAgIHVp ZCAgIHN0YXRlICAgd21lc2cgICAgIHdjaGFuICAgIGNtZAogIDI3MiAgICA2MiAgICA2MiAgICAg MCAgUisgICAgICAgICAgICAgICAgICAgICAgICAgIHNoCiAgIDcyICAgICAwICAgICAwICAgICAw ICBTTCAgICAgIC0gICAgICAgIDB4YzBhN2YwMDQgW25mc2lvZCAxXQogICA2MyAgICAgMCAgICAg MCAgICAgMCAgU0wgICAgICAtICAgICAgICAweGMwYTdmMDAwIFtuZnNpb2QgMF0KICAgNjIgICAg IDEgICAgNjIgICAgIDAgIFNzKyAgICAgd2FpdCAgICAgMHhjNmQyN2M5MCBzaAogICA2MSAgICAg MCAgICAgMCAgICAgMCAgUkwgICAgICAgICAgICAgICAgICAgICAgICAgIFtzb2Z0ZGVwZmx1c2hd CiAgIDYwICAgICAwICAgICAwICAgICAwICBTTCAgICAgIHZscnV3dCAgIDB4YzY5NWU4NjAgW3Zu bHJ1XQogICA1OSAgICAgMCAgICAgMCAgICAgMCAgUkwgICAgICAgICAgICAgICAgICAgICAgICAg IFtzeW5jZXJdCiAgIDU4ICAgICAwICAgICAwICAgICAwICBTTCAgICAgIHBzbGVlcCAgIDB4YzBh NzZlYTAgW2J1ZmRhZW1vbl0KICAgNTcgICAgIDAgICAgIDAgICAgIDAgIFNMICAgICAgcGd6ZXJv ICAgMHhjMGE4NTZjNCBbcGFnZXplcm9dCiAgIDU2ICAgICAwICAgICAwICAgICAwICBTTCAgICAg IHBzbGVlcCAgIDB4YzBhODUxZDQgW3ZtZGFlbW9uXQogICA1NSAgICAgMCAgICAgMCAgICAgMCAg U0wgICAgICBwc2xlZXAgICAweGMwYTg1MTg4IFtwYWdlZGFlbW9uXQogICA1NCAgICAgMCAgICAg MCAgICAgMCAgV0wgICAgICAgICAgICAgICAgICAgICAgICAgIFtpcnExOiBhdGtiZDBdCiAgIDUz ICAgICAwICAgICAwICAgICAwICBXTCAgICAgICAgICAgICAgICAgICAgICAgICAgW3N3aTA6IHNp b10KICAgNTIgICAgIDAgICAgIDAgICAgIDAgIFdMICAgICAgICAgICAgICAgICAgICAgICAgICBb aXJxMjE6IGF0YXBjaTFdCiAgIDUxICAgICAwICAgICAwICAgICAwICBXTCAgICAgICAgICAgICAg ICAgICAgICAgICAgW2lycTE1OiBhdGExXQogICA1MCAgICAgMCAgICAgMCAgICAgMCAgV0wgICAg ICAgICAgICAgICAgICAgICAgICAgIFtpcnExNDogYXRhMF0KICAgNDkgICAgIDAgICAgIDAgICAg IDAgIFNMICAgICAgdXNiZXZ0ICAgMHhjNjhjODIxMCBbdXNiNl0KICAgNDggICAgIDAgICAgIDAg ICAgIDAgIFNMICAgICAgdXNiZXZ0ICAgMHhjNjk4NzIxMCBbdXNiNV0KICAgNDcgICAgIDAgICAg IDAgICAgIDAgIFNMICAgICAgdXNiZXZ0ICAgMHhjNjk3ZjIxMCBbdXNiNF0KZGI+IGJ0IDI3MgpU cmFjaW5nIHBpZCAyNzIgdGlkIDEwMDA3MSB0ZCAweGM2ZDIwMWEwCnNjaGVkX3N3aXRjaChjNmQy MDFhMCwwLDEpIGF0IHNjaGVkX3N3aXRjaCsweDE0MwptaV9zd2l0Y2goMSwwLGM2ZDRlNGM4LGVk MWNjYmVjLGMwNmQyMGMxLC4uLikgYXQgbWlfc3dpdGNoKzB4MWJhCnNsZWVwcV9zd2l0Y2goYzZk NGU0YzgpIGF0IHNsZWVwcV9zd2l0Y2grMHg4NwpzbGVlcHFfd2FpdF9zaWcoYzZkNGU0YzgpIGF0 IHNsZWVwcV93YWl0X3NpZysweDFkCm1zbGVlcChjNmQ0ZTRjOCxjNmQ0ZTYzOCwxNGMsYzA5Njk2 YTUsMCwuLi4pIGF0IG1zbGVlcCsweDI1YQpwaXBlX3JlYWQoYzZkM2MzNjAsZWQxY2NjYmMsYzY3 YjlkMDAsMCxjNmQyMDFhMCkgYXQgcGlwZV9yZWFkKzB4NDJkCmRvZmlsZXJlYWQoYzZkMjAxYTAs MyxjNmQzYzM2MCxlZDFjY2NiYyxmZmZmZmZmZiwuLi4pIGF0IGRvZmlsZXJlYWQrMHg4NQprZXJu X3JlYWR2KGM2ZDIwMWEwLDMsZWQxY2NjYmMsYmZiZmNjOTAsODAsLi4uKSBhdCBrZXJuX3JlYWR2 KzB4MzYKcmVhZChjNmQyMDFhMCxlZDFjY2QwNCkgYXQgcmVhZCsweDQ1CnN5c2NhbGwoM2IsM2Is M2IsODA3MTBmNCwwLC4uLikgYXQgc3lzY2FsbCsweDJiZgpYaW50MHg4MF9zeXNjYWxsKCkgYXQg WGludDB4ODBfc3lzY2FsbCsweDFmCi0tLSBzeXNjYWxsICgzLCBGcmVlQlNEIEVMRjMyLCByZWFk KSwgZWlwID0gMHgyODFhMzIyNywgZXNwID0gMHhiZmJmY2MwYywgZWJwID0gMHhiZmJmY2QzOCAt LS0KCg== --00032555a0ca5b9a98047957aa60-- From owner-freebsd-net@FreeBSD.ORG Fri Nov 27 17:49:47 2009 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 2F455106566C for ; Fri, 27 Nov 2009 17:49:47 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 90D138FC16 for ; Fri, 27 Nov 2009 17:49:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 2E9A816C5; Fri, 27 Nov 2009 18:33:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mail; t=1259343193; x= 1261157593; bh=8OZXox9WS8WOdkfiWrCzC9MeV6bDTCf9j8V4LqaZ71U=; b=i dZVo119s9ZnbzkYF0me87tVg5zPMZxJdieDBL4BozpyV/eWz+HjpvKgkgsyt9ZU9 7g4do7rzDDas/OCut2bUvmsFkuPmC3XBdZgH5o5Qb54ZB1yM45VN6twpZAzttcsR jTZkz4TluG3jA7vlMynJ4K+DE5MiCheIynV0jUZ200= X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by localhost (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aE8mEuKtqvfh; Fri, 27 Nov 2009 18:33:13 +0100 (CET) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 6BAA116BD; Fri, 27 Nov 2009 18:33:13 +0100 (CET) Date: Fri, 27 Nov 2009 18:33:13 +0100 From: Guido Falsi To: Chris Message-ID: <20091127173313.GC13193@megatron.madpilot.net> References: <64aa03030911261831i1994a3dcpca545ab7ffd78dfe@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <64aa03030911261831i1994a3dcpca545ab7ffd78dfe@mail.gmail.com> X-Operating-System: FreeBSD 8.0-RC2 User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: ipw driver on FreeBSD 8.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2009 17:49:47 -0000 On Thu, Nov 26, 2009 at 09:31:58PM -0500, Chris wrote: > Hello, > > Months ago there was some chatter about the ipw driver (For Centrino Intel > 2100 wireless) being broken in 8.0 but that was when 8.0 was still under the > CURRENT branch. Can anyone tell me if it has been fixed? I'm having a heck > of a time trying to get it to work with the new VAP stuff. Here's the thread > I'm referring to: > > http://old.nabble.com/wpa_supplicant-can%27t-associate-with-WPA2-AP-td22687633.html > > I'm seeing exactly the same problem shown in the thread when trying to > associate with a regular WPA access point. > > Any info would be appreciated! That was me having thet problem on my old laptop. Still using that same laptop(I'd like to buy the latest hardware for my home setup, but at this time of the year I like spending my money to go to sky!). I have not tried ipw driver anymore, I have "fixed" the problem by using ndis. Works like a charm, so if you have this problem I suggest you do the same. I have not seen any major commit to the ipw driver, so my take is it is as it was then. Please correct me if I'm wrong. Some time ago I also had a look at the driver source, but it really requires some major knowledge of wlan protocols and device interface, and I lack both. BTW, at present my biggest problem with WiFi is the one described in PR kern/139117: [lagg] + wlan boot timing (EBUSY). I encountered it while trying to configure a wlan(with WPA2) failsafe lagg with the cabled ethernet. Any news on that front? Sorry if I could not be of any more help and thanks for any answers to my query. P.S. I'm also CCing freebsd-net@, since the problems seems to be appropriate there. -- Guido Falsi From owner-freebsd-net@FreeBSD.ORG Sat Nov 28 05:12:39 2009 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 48272106566B for ; Sat, 28 Nov 2009 05:12:39 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outM.internet-mail-service.net (outm.internet-mail-service.net [216.240.47.236]) by mx1.freebsd.org (Postfix) with ESMTP id 317B28FC1A for ; Sat, 28 Nov 2009 05:12:38 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 31621AE06B; Fri, 27 Nov 2009 21:12:38 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by idiom.com (Postfix) with ESMTP id F1F6B2D601A; Fri, 27 Nov 2009 21:12:37 -0800 (PST) Message-ID: <4B10B145.1050704@elischer.org> Date: Fri, 27 Nov 2009 21:12:37 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Igor Sysoev References: <20091127085504.GH17494@sysoev.ru> In-Reply-To: <20091127085504.GH17494@sysoev.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: interface FIB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 05:12:39 -0000 Igor Sysoev wrote: > Currently only packets generated during encapsulation can use > interface's FIB stored during interface creation: > > setfib 1 ifconfig gif0 ... > setfib 1 ifconfig tun0 ... not sure if tun actually does this (in fac tit shouldn't) but for gre and gif (and stf) these are tunnelling other things into IP and thus it makes sense to be able to connect a routing table with the generated envelopes. > > is it possible to implement this feature for any interface: > > setfib 1 ifconfig vlan0 ... > > or > > ifconfig vlan0 setfib 1 ... these two things would mean differnt things. and one of them wouldn't mean anything. setfig 1 ifconfig vlan0 woudl mean "what" exactly? VLAN tagging is an L2/L1 operation and FIBS have no effect on this. as for ifconfig vlan0 setfib 1, or ifconfig em0 setfib 1 this will (shortly) mean that incoming packets through this interface will be default be connected with fib 1 so the any return packets (resets, icmp etc.) will use FIB1 to go back to the sender. That patch is in the works. > > From owner-freebsd-net@FreeBSD.ORG Sat Nov 28 08:03:55 2009 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 6186E106566C for ; Sat, 28 Nov 2009 08:03:55 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from mailrelay1.rambler.ru (mailrelay1.rambler.ru [81.19.66.239]) by mx1.freebsd.org (Postfix) with ESMTP id 164E48FC08 for ; Sat, 28 Nov 2009 08:03:55 +0000 (UTC) Received: from kas30pipe.localhost (localhost [127.0.0.1]) by mailrelay1.rambler.ru (Postfix) with ESMTP id F2221130C3D for ; Sat, 28 Nov 2009 11:03:53 +0300 (MSK) Received: from localhost (sysoev.ru [81.19.68.137]) by mailrelay1.rambler.ru (Postfix) with ESMTP id 770AB130C26 for ; Sat, 28 Nov 2009 11:03:53 +0300 (MSK) Date: Sat, 28 Nov 2009 11:03:53 +0300 From: Igor Sysoev To: freebsd-net@freebsd.org Message-ID: <20091128080353.GA11509@sysoev.ru> References: <20091127085504.GH17494@sysoev.ru> <4B10B145.1050704@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4B10B145.1050704@elischer.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.33/RELEASE, bases: 02092009 #2738642, status: clean X-SpamTest-Envelope-From: is@rambler-co.ru X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 9536 [Sen 02 2009] X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: none X-SpamTest-Rate: 10 X-SpamTest-SPF: pass X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0284], KAS30/Release Subject: Re: interface FIB X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 08:03:55 -0000 On Fri, Nov 27, 2009 at 09:12:37PM -0800, Julian Elischer wrote: > Igor Sysoev wrote: > > Currently only packets generated during encapsulation can use > > interface's FIB stored during interface creation: > > > > setfib 1 ifconfig gif0 ... > > setfib 1 ifconfig tun0 ... > > not sure if tun actually does this (in fac tit shouldn't) > > but for gre and gif (and stf) these are tunnelling other things into > IP and thus it makes sense to be able to connect a routing table with > the generated envelopes. I've got this from 8.0 release notes: A packet generated on tunnel interfaces such as gif(4) and tun(4) will be encapsulated using the FIB of the process which set up the tunnel. However, sys/net/if_tun.c is really has no FIB related changes. > > is it possible to implement this feature for any interface: > > > > setfib 1 ifconfig vlan0 ... > > > > or > > > > ifconfig vlan0 setfib 1 ... > > these two things would mean differnt things. > and one of them wouldn't mean anything. > > setfig 1 ifconfig vlan0 woudl mean "what" exactly? > VLAN tagging is an L2/L1 operation and FIBS have no effect on this. > > as for ifconfig vlan0 setfib 1, or ifconfig em0 setfib 1 > > this will (shortly) mean that incoming packets through this interface > will be default be connected with fib 1 so the any return packets > (resets, icmp etc.) will use FIB1 to go back to the sender. This is exactly what I meant. > That patch is in the works. I'm ready to test the patch in production on 7/8-STABLE if the patch can be applied to it. -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Sat Nov 28 10:06:08 2009 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 CEC73106568B for ; Sat, 28 Nov 2009 10:06:08 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web51803.mail.re2.yahoo.com (web51803.mail.re2.yahoo.com [206.190.38.234]) by mx1.freebsd.org (Postfix) with SMTP id 6EBB98FC13 for ; Sat, 28 Nov 2009 10:06:08 +0000 (UTC) Received: (qmail 94638 invoked by uid 60001); 28 Nov 2009 10:06:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1259402767; bh=rh7G9cx4VaYlrWshafFW3oJ8X9i7TRZBpV0e0v+nggU=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=l5xScO8STMMzfT7BDhVdNljrr03NAZB0v4U1tF79oX5Zj8G7CTwiZqR5Lf4Du6m7mwT+cEnYmY7uq9RIRdngiWh5T1hmougAXoBQFiCZXiOt9GDQkavzA6Kyt/C5smtJAJHD30/FaZwEP2U3aETrkpVfkFTFrVDylzOMmeHSKwY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=uSogW9vZ+FI0AlyqdPExyQuorSiXze5be/Ain5ZZa2OHkIhaEcxT3WA8jMCO6kwaYokN+BIXZyeqnCAOjWwM/2skj8GxtFiVarEVK8oNxiflmHrJDlCF8Fpx4wTMMLT2QySTrIZWNK9ZGa4GW+jAVJ5IfmPN0qOIuqDdwjUiQxg=; Message-ID: <748570.94146.qm@web51803.mail.re2.yahoo.com> X-YMail-OSG: s9N9Lj8VM1npY0RP1IWXuvy0q9QvI25wEi6HcpI9Mlh6C_zugMxH_OotxbozWAVryO72TIewtXvPNmcC.p5dKYWQmXKA8KOQN95Bow8PAZs2iUkESbOapMb1gFhuj.FgeXs5XXkzMNzok2PyjRZFhfH6rdY_kk4YyOVls73TnMUCKHGuSPtZhaZpdLQIKp8Jga5716asQxntE88E2h4dW_T7MbpLqWLvURsRz_2d3cbCGY4B0Rc.WTFTOMNF2eax0QB7MOQqB4u0If4GccWn2Zl9syCM0SJKEzX9pC9Gd7ge6uKUsTY_rgfjangnCGc8bhtgLHsbSej1UgUjdNlADHPtKrTFi.rezuugPaOJZtddIFB6HsGOEscqV5SrrxFJeMrl9Y2dt4rQv2KvpIdqn10CQZdS1MQOWxj2nufD5xEGvhcqvNUtCX6C9VncYYjVsVgpOa3_N5FT32QNQD8Beazpv2An8PLIMGTQPrVNl3N7.OOHsywoCxS_aUnLqAfyilCRqt9xxM8Us8HmRThgDrkFsEyIxa7tT6U3MYJ84Pf3E1leaX4Y8QeoQZFf6vho2RkklIoTULDhPk4T9D9kG_UMnBcJyEo- Received: from [75.158.17.63] by web51803.mail.re2.yahoo.com via HTTP; Sat, 28 Nov 2009 02:06:07 PST X-Mailer: YahooMailRC/211.6 YahooMailWebService/0.8.100.260964 Date: Sat, 28 Nov 2009 02:06:07 -0800 (PST) From: PseudoCylon To: freebsd-current@freebsd.org, freebsd-drivers@freebsd.org, freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Fix available for run driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 10:06:08 -0000 Hello,=0A=0AThere are some fixes for run driver for 8.0 release and current= . It can be downloaded from freebsd forums at=0Ahttp://forums.freebsd.org/s= howpost.php?s=3D87e376cf71273061f7de5aaf258132a1&p=3D44110&postcount=3D1=0A= =0ASome packet loss/drop and memory leak have been identified and fixed. (I= t improved some performance, too)=0A=0AAlso, 40 more vender/device IDs have= been added.=0A=0ADetails are on RELEASE_NOTES included.=0A=0APlease update= before the driver causing any troubles.=0A=0AAkinori=0A=0A=0A _______= ___________________________________________________________=0AMake your bro= wsing faster, safer, and easier with the new Internet Explorer=AE 8. Optimi= zed for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/intern= etexplorer/ From owner-freebsd-net@FreeBSD.ORG Sat Nov 28 15:27:51 2009 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 22CD61065670; Sat, 28 Nov 2009 15:27:51 +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 ED2068FC0C; Sat, 28 Nov 2009 15:27:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id nASFRope098431; Sat, 28 Nov 2009 15:27:50 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id nASFRoMH098427; Sat, 28 Nov 2009 15:27:50 GMT (envelope-from linimon) Date: Sat, 28 Nov 2009 15:27:50 GMT Message-Id: <200911281527.nASFRoMH098427@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/140970: [bce] The two NetXtreme II BCM5709S NICs on our HP Bl460c G1 Blade can't be accessed on FreeBSD 7.2 and 8 [regression] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 15:27:51 -0000 Old Synopsis: [bce] The two NetXtreme II BCM5709S NICs on our HP Bl460c G1 Blade can't be accessed on FreeBSD 7.2 and 8 New Synopsis: [bce] The two NetXtreme II BCM5709S NICs on our HP Bl460c G1 Blade can't be accessed on FreeBSD 7.2 and 8 [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Nov 28 15:26:24 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=140970 From owner-freebsd-net@FreeBSD.ORG Sat Nov 28 17:04:40 2009 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 9E7541065679 for ; Sat, 28 Nov 2009 17:04:40 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by mx1.freebsd.org (Postfix) with ESMTP id 2C2018FC08 for ; Sat, 28 Nov 2009 17:04:39 +0000 (UTC) Received: by fxm10 with SMTP id 10so2009288fxm.14 for ; Sat, 28 Nov 2009 09:04:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kpf+ybu+3YxfjMmqjMYdzsJ3mmZxYxgr1PCUbspJbWY=; b=msGUsDUHz8nDOOncNuf5KyUF3FN2A1dALuS4or+QO4ahKi4oZ/1u1jFLqLtMzHasdi cfGoFStUEiD6mYFvzDnc+fqJsl6CT6LX+MaKw5V9T6pmdWLFXeniLSUvFYJTHrs1mDZA ofLq+RYIRLsky2609eaI9jNYMKYnM5TPRum/I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=c0TDhRAFLbKoybjLKHp/Qn/Dp8Km5wHWAVpzJ62oYOFIHre5DDu0SubBUHU/NDYRGV XyO3FWF+74u0JQxz9inhzdSVgE9nuH90JkkGxZ5nSjNqA60F8MhBmoXRIupAio1Pd9wI yig76CkaD9GJpH0Ljl0epauNIOx34EsEaT7C0= MIME-Version: 1.0 Received: by 10.223.13.214 with SMTP id d22mr369338faa.53.1259427878912; Sat, 28 Nov 2009 09:04:38 -0800 (PST) In-Reply-To: <200911240230.nAO2U6Ak004167@freefall.freebsd.org> References: <200911240230.nAO2U6Ak004167@freefall.freebsd.org> Date: Sat, 28 Nov 2009 12:04:38 -0500 Message-ID: <4ad871310911280904h10b6ab16gc0d73057973ebf08@mail.gmail.com> From: Glen Barber To: Benjamin Kaduk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: kern/140036: [iwn] [lor] lock order reversal with iwn0_com_lock and iwn0 softc lock X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 17:04:40 -0000 Hi, On Mon, Nov 23, 2009 at 9:30 PM, Benjamin Kaduk > =A0> On Sun, 22 Nov 2009, Bernhard Schmidt wrote: > =A0>> > =A0>> Can you verify that the LOR is gone with the latest checkout of my > =A0>> repository? > =A0>> Compile instructions: > =A0>> http://forums.freebsd.org/showpost.php?p=3D47627&postcount=3D16 > =A0> > =A0> I upgraded to today's current (which picked up a number of probably-= unrelated > =A0> changes), and then installed the driver from > =A0> your tree on top of it. > =A0> No LOR on boot, and I'll let you know if I see any lockups. I am seeing this LOR on 8-STABLE (with the latest iwn(4) patches from the site above). > > > =A0I got a "lockup" (no idea what actually was happening) while in X toni= ght; > =A0nothing useful is in the logs. Do you mean "lockup" as in the system becomes non-responsive? If so, I am experiencing this as well. I recently switched my filesystem to ZFS because of the time fsck_ufs takes, and added the following options to GENERIC to try to track this down: KDB DDB BREAK_TO_DEBUGGER ALT_BREAK_TO_DEBUGGER INVARIANTS INVARIANT_SUPPORT WITNESS WITNESS_SKIPSPIN SOCKBUF_DEBUG DIAGNOSTIC SW_WATCHDOG DEBUG_VFS_LOCKS > =A0I'm not even sure if I can blame iwn for it ... The last time the system locked, I wasn't in X. I saw the following on the console before it became unusable: firmware error log: error type =3D "SYSASSERT" (0x00000005) program counter =3D 0x0000C920 source line =3D 0x00000619 error data =3D 0x000000FE00000000 branch link =3D 0x0000C8420000C842 interrupt link =3D 0x0000090E00000000 time =3D 1182627 driver status: tx ring 0: qid=3D0 cur=3D1 queued=3D1 tx ring 1: qid=3D1 cur=3D0 queued=3D0 tx ring 2: qid=3D2 cur=3D0 queued=3D0 tx ring 3: qid=3D3 cur=3D0 queued=3D0 tx ring 4: qid=3D4 cur=3D12 queued=3D0 tx ring 5: qid=3D5 cur=3D0 queued=3D0 tx ring 6: qid=3D6 cur=3D0 queued=3D0 tx ring 7: qid=3D7 cur=3D0 queued=3D0 tx ring 8: qid=3D8 cur=3D0 queued=3D0 tx ring 9: qid=3D9 cur=3D0 queued=3D0 tx ring 10: qid=3D10 cur=3D0 queued=3D0 tx ring 11: qid=3D11 cur=3D0 queued=3D0 tx ring 12: qid=3D12 cur=3D0 queued=3D0 tx ring 13: qid=3D13 cur=3D0 queued=3D0 tx ring 14: qid=3D14 cur=3D0 queued=3D0 tx ring 15: qid=3D15 cur=3D0 queued=3D0 tx ring 16: qid=3D16 cur=3D0 queued=3D0 tx ring 17: qid=3D17 cur=3D0 queued=3D0 tx ring 18: qid=3D18 cur=3D0 queued=3D0 tx ring 19: qid=3D19 cur=3D0 queued=3D0 rx ring: cur=3D59 iwn0: iwn_apm_stop_master: timeout waiting for master If there is more information I can provide, please let me know. --=20 Glen Barber