From owner-freebsd-net@FreeBSD.ORG Sun Aug 30 02:14:28 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 F363D106566B; Sun, 30 Aug 2009 02:14:27 +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 D644A8FC15; Sun, 30 Aug 2009 02:14:27 +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 n7U2EQEU008222; Sat, 29 Aug 2009 19:14:27 -0700 (PDT) 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: Sat, 29 Aug 2009 19:08:19 -0700 Message-ID: In-Reply-To: <38B715CC-9C82-4D8D-97CC-134A9CB01A0C@lurchi.franken.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: routing message problem Thread-Index: AcooECTrPp9whvmMQ+OaAD/RddsvTwBBoYKg References: <38B715CC-9C82-4D8D-97CC-134A9CB01A0C@lurchi.franken.de> From: "Li, Qing" To: =?iso-8859-1?Q?Michael_T=FCxen?= Cc: qingli@freebsd.org, "Bjoern A. Zeeb" , Randall Stewart , net@freebsd.org Subject: RE: routing message problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 02:14:28 -0000 Hi Michael, >=20 > your patch fixes the issue. > Will it find its way into 8.0? > Will it find its way into 7.3? >=20 Yes, the patch will make its way into 8.0 Release and 7.3, too. Thanks, -- Qing >=20 > On Aug 28, 2009, at 7:24 PM, Li, Qing wrote: >=20 > >> > >> Dear all, > >> > >> via a bug report from Preethi I figured out that there are no > >> RTM_NEWADDR > >> routing messages generated when an IP address is added to an > >> interface > >> and there is already an address in the same network configured. > >> This is a problem for the SCTP stack. > >> > >> To reproduce the problem you can > >> sudo ifconfig em0 192.168.1.1 > >> sudo ifconfig em0 192.168.1.2 alias > >> > >> and use the attached problem. It will only show the first address > >> being added. This problem applies to FreeBSD 9.0 CURRENT and 7.2 > >> RELEASE. > >> > >> Any idea how to fix the problem? > >> > > > > > > Please try my patch (not the final version) at > > > > http://people.freebsd.org/~qingli/patch-8-28-rtmsg.diff > > > > > > I have tested it and seems to work as expected. You should > > get the notifications for both address insertion ("alias") > > and deletion ("-alias"). > > > > Let me know if it's to your satisfaction. > > > > I found a couple of other issues while looking over the code. > > > > 1. in_scrubprefix() is called unnecessarily in 2 locations > > 2. the loopback host route is not removed for an alias > > > > On a related note, in.c can use some code cleanup. I think > > I will do that post 8.0 release. > > > > Thanks, > > > > -- Qing > > > > From owner-freebsd-net@FreeBSD.ORG Sun Aug 30 06:05:23 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 B01441065673; Sun, 30 Aug 2009 06:05:23 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id DDEB08FC21; Sun, 30 Aug 2009 06:05:22 +0000 (UTC) Received: from [192.168.1.100] (p508FC6A0.dip.t-dialin.net [80.143.198.160]) by mail-n.franken.de (Postfix) with ESMTP id 91D7B1C0C0BEA; Sun, 30 Aug 2009 08:05:20 +0200 (CEST) Message-Id: From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: "Li, Qing" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 30 Aug 2009 08:05:19 +0200 References: <38B715CC-9C82-4D8D-97CC-134A9CB01A0C@lurchi.franken.de> X-Mailer: Apple Mail (2.936) Cc: qingli@freebsd.org, "Bjoern A. Zeeb" , Randall Stewart , net@freebsd.org Subject: Re: routing message problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 06:05:23 -0000 On Aug 30, 2009, at 4:08 AM, Li, Qing wrote: > Hi Michael, >> >> your patch fixes the issue. >> Will it find its way into 8.0? >> Will it find its way into 7.3? >> > > Yes, the patch will make its way into 8.0 Release and 7.3, too. Great! Thanks a lot. Best regards Michael > > Thanks, > > -- Qing > > >> >> On Aug 28, 2009, at 7:24 PM, Li, Qing wrote: >> >>>> >>>> Dear all, >>>> >>>> via a bug report from Preethi I figured out that there are no >>>> RTM_NEWADDR >>>> routing messages generated when an IP address is added to an >>>> interface >>>> and there is already an address in the same network configured. >>>> This is a problem for the SCTP stack. >>>> >>>> To reproduce the problem you can >>>> sudo ifconfig em0 192.168.1.1 >>>> sudo ifconfig em0 192.168.1.2 alias >>>> >>>> and use the attached problem. It will only show the first address >>>> being added. This problem applies to FreeBSD 9.0 CURRENT and 7.2 >>>> RELEASE. >>>> >>>> Any idea how to fix the problem? >>>> >>> >>> >>> Please try my patch (not the final version) at >>> >>> http://people.freebsd.org/~qingli/patch-8-28-rtmsg.diff >>> >>> >>> I have tested it and seems to work as expected. You should >>> get the notifications for both address insertion ("alias") >>> and deletion ("-alias"). >>> >>> Let me know if it's to your satisfaction. >>> >>> I found a couple of other issues while looking over the code. >>> >>> 1. in_scrubprefix() is called unnecessarily in 2 locations >>> 2. the loopback host route is not removed for an alias >>> >>> On a related note, in.c can use some code cleanup. I think >>> I will do that post 8.0 release. >>> >>> Thanks, >>> >>> -- Qing >>> >>> > > From owner-freebsd-net@FreeBSD.ORG Sun Aug 30 07:33:16 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 5F8581065674; Sun, 30 Aug 2009 07:33:16 +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 387BC8FC34; Sun, 30 Aug 2009 07:33:16 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7U7XFsx014986; Sun, 30 Aug 2009 07:33:15 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7U7XFnK014980; Sun, 30 Aug 2009 07:33:15 GMT (envelope-from linimon) Date: Sun, 30 Aug 2009 07:33:15 GMT Message-Id: <200908300733.n7U7XFnK014980@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: bin/138331: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 07:33:16 -0000 Old Synopsis: FreeBSD 8.0-beta3 wpa_supplicant lost auth New Synopsis: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Aug 30 07:32:41 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138331 From owner-freebsd-net@FreeBSD.ORG Sun Aug 30 09:22:55 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 A396F1065672; Sun, 30 Aug 2009 09:22:55 +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 7B4638FC0C; Sun, 30 Aug 2009 09:22:55 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7U9MtjO035484; Sun, 30 Aug 2009 09:22:55 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7U9Mtsk035480; Sun, 30 Aug 2009 09:22:55 GMT (envelope-from linimon) Date: Sun, 30 Aug 2009 09:22:55 GMT Message-Id: <200908300922.n7U9Mtsk035480@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/138332: [tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BETA3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 09:22:55 -0000 Old Synopsis: ifconfig tun0 destroy causes LOR on 8.0-BETA3 New Synopsis: [tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BETA3 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Aug 30 09:22:38 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138332 From owner-freebsd-net@FreeBSD.ORG Sun Aug 30 17: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 D351B1065679 for ; Sun, 30 Aug 2009 17: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 AA35E8FC0A for ; Sun, 30 Aug 2009 17:50:03 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7UHo3tB060703 for ; Sun, 30 Aug 2009 17: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 n7UHo3Lg060702; Sun, 30 Aug 2009 17:50:03 GMT (envelope-from gnats) Date: Sun, 30 Aug 2009 17:50:03 GMT Message-Id: <200908301750.n7UHo3Lg060702@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Sam Leffler Cc: Subject: Re: bin/138331: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Sam Leffler List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 17:50:03 -0000 The following reply was made to PR bin/138331; it has been noted by GNATS. From: Sam Leffler To: bug-followup@FreeBSD.org, sshutdownow@gmail.com Cc: Subject: Re: bin/138331: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth Date: Sun, 30 Aug 2009 10:28:47 -0700 You appear to say this problem does not entirely stop traffic from flowing. Please provide a debug wpa_supplicant log that shows a complete session (i.e. a log with -d and/or -dd). Why do you set eapol_version=1. Is this really needed? What is your AP make/model? Note also that country=RU is ignored on freebsd. Sam From owner-freebsd-net@FreeBSD.ORG Sun Aug 30 19:00:05 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 8120C1065676 for ; Sun, 30 Aug 2009 19:00:05 +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 68AF48FC12 for ; Sun, 30 Aug 2009 19:00:05 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7UJ058X030534 for ; Sun, 30 Aug 2009 19:00:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7UJ05Ap030533; Sun, 30 Aug 2009 19:00:05 GMT (envelope-from gnats) Date: Sun, 30 Aug 2009 19:00:05 GMT Message-Id: <200908301900.n7UJ05Ap030533@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Igor Popov Cc: Subject: Re: bin/138331: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Igor Popov List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 19:00:05 -0000 The following reply was made to PR bin/138331; it has been noted by GNATS. From: Igor Popov To: Sam Leffler Cc: bug-followup@freebsd.org Subject: Re: bin/138331: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth Date: Sun, 30 Aug 2009 21:33:20 +0300 --0014852f5780d7c3810472602664 Content-Type: text/plain; charset=UTF-8 Hi, Sam. man (5) for wpa_supplicant.conf stands that it is default value, but when I commented out this parameter nothing has changed. I ping IP of Access Point: $ ping 192.168.12.1 PING 192.168.12.1 (192.168.12.1): 56 data bytes 64 bytes from 192.168.12.1: icmp_seq=0 ttl=128 time=6.450 ms 64 bytes from 192.168.12.1: icmp_seq=3 ttl=128 time=0.762 ms 64 bytes from 192.168.12.1: icmp_seq=25 ttl=128 time=0.743 ms 64 bytes from 192.168.12.1: icmp_seq=75 ttl=128 time=0.755 ms 64 bytes from 192.168.12.1: icmp_seq=79 ttl=128 time=0.959 ms 64 bytes from 192.168.12.1: icmp_seq=103 ttl=128 time=0.740 ms 64 bytes from 192.168.12.1: icmp_seq=162 ttl=128 time=5.322 ms 64 bytes from 192.168.12.1: icmp_seq=164 ttl=128 time=5.705 ms 64 bytes from 192.168.12.1: icmp_seq=165 ttl=128 time=22.138 ms 64 bytes from 192.168.12.1: icmp_seq=166 ttl=128 time=1.218 ms 64 bytes from 192.168.12.1: icmp_seq=167 ttl=128 time=26.788 ms 64 bytes from 192.168.12.1: icmp_seq=168 ttl=128 time=17.097 ms 64 bytes from 192.168.12.1: icmp_seq=169 ttl=128 time=3.628 ms 64 bytes from 192.168.12.1: icmp_seq=217 ttl=128 time=1.788 ms 64 bytes from 192.168.12.1: icmp_seq=218 ttl=128 time=3.626 ms 64 bytes from 192.168.12.1: icmp_seq=219 ttl=128 time=6.011 ms 64 bytes from 192.168.12.1: icmp_seq=220 ttl=128 time=2.699 ms 64 bytes from 192.168.12.1: icmp_seq=221 ttl=128 time=1.804 ms 64 bytes from 192.168.12.1: icmp_seq=222 ttl=128 time=3.044 ms 64 bytes from 192.168.12.1: icmp_seq=223 ttl=128 time=2.621 ms 64 bytes from 192.168.12.1: icmp_seq=224 ttl=128 time=2.852 ms 64 bytes from 192.168.12.1: icmp_seq=225 ttl=128 time=1.161 ms 64 bytes from 192.168.12.1: icmp_seq=226 ttl=128 time=4.579 ms 64 bytes from 192.168.12.1: icmp_seq=227 ttl=128 time=3.935 ms 64 bytes from 192.168.12.1: icmp_seq=228 ttl=128 time=4.390 ms 64 bytes from 192.168.12.1: icmp_seq=229 ttl=128 time=2.741 ms 64 bytes from 192.168.12.1: icmp_seq=230 ttl=128 time=3.711 ms 64 bytes from 192.168.12.1: icmp_seq=231 ttl=128 time=8.003 ms 64 bytes from 192.168.12.1: icmp_seq=232 ttl=128 time=6.082 ms 64 bytes from 192.168.12.1: icmp_seq=233 ttl=128 time=5.059 ms 64 bytes from 192.168.12.1: icmp_seq=234 ttl=128 time=2.456 ms 64 bytes from 192.168.12.1: icmp_seq=235 ttl=128 time=3.144 ms 64 bytes from 192.168.12.1: icmp_seq=236 ttl=128 time=1.202 ms 64 bytes from 192.168.12.1: icmp_seq=237 ttl=128 time=6.566 ms 64 bytes from 192.168.12.1: icmp_seq=238 ttl=128 time=13.830 ms 64 bytes from 192.168.12.1: icmp_seq=239 ttl=128 time=5.463 ms 64 bytes from 192.168.12.1: icmp_seq=240 ttl=128 time=1.272 ms ^C --- 192.168.12.1 ping statistics --- 241 packets transmitted, 37 packets received, 84.6% packet loss round-trip min/avg/max/stddev = 0.740/5.144/26.788/5.734 ms logs (during ping) that you are requested: # wpa_supplicant -Kdd -i wlan0 -Dbsd -c /etc/wpa_supplicant.conf Initializing interface 'wlan0' conf '/etc/wpa_supplicant.conf' driver 'bsd' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf' Reading configuration file '/etc/wpa_supplicant.conf' ctrl_interface_group='wheel' eapol_version=1 ap_scan=1 fast_reauth=1 country='RU' Line: 10 - start of a new network block ssid - hexdump_ascii(len=8): 6d 69 63 72 6f 6e 65 74 micronet BSSID - hexdump(len=6): 00 17 9a f0 b6 82 scan_ssid=1 (0x1) key_mgmt: 0x2 proto: 0x1 pairwise: 0x8 group: 0x8 PSK (ASCII passphrase) - hexdump_ascii(len=31): 4e 64 47 6a 51 74 55 4d 24 75 74 62 6b 2e 49 37 NdGjQtUM$utbk.I7 44 73 6b 37 36 2e 2e 66 30 61 59 61 55 65 2e Dsk76..f0aYaUe. PSK (from passphrase) - hexdump(len=32): 19 7b 12 a0 c6 0b ca 92 12 2a a5 77 e6 76 c4 ef 3b bf 43 88 18 b4 9d f1 f6 16 bb ff ac d2 cf 74 Priority group 0 id=0 ssid='micronet' Initializing interface (2) 'wlan0' Own MAC address: 00:15:e9:a4:58:9b wpa_driver_bsd_set_wpa: enabled=1 wpa_driver_bsd_set_wpa_internal: wpa=3 privacy=1 wpa_driver_bsd_del_key: keyidx=0 wpa_driver_bsd_del_key: keyidx=1 wpa_driver_bsd_del_key: keyidx=2 wpa_driver_bsd_del_key: keyidx=3 wpa_driver_bsd_set_countermeasures: enabled=0 wpa_driver_bsd_set_drop_unencrypted: enabled=1 RSN: flushing PMKID list in the driver Setting scan request: 0 sec 100000 usec Added interface wlan0 State: DISCONNECTED -> SCANNING Starting AP scan (specific SSID) Scan SSID - hexdump_ascii(len=8): 6d 69 63 72 6f 6e 65 74 micronet Trying to get current scan results first without requesting a new scan to speed up initial association Received 0 bytes of scan results (0 BSSes) Scan results: 0 Cached scan results are empty - not posting Selecting BSS from priority group 0 Try to find WPA-enabled AP Try to find non-WPA AP No suitable AP found. Setting scan request: 0 sec 0 usec Starting AP scan (broadcast SSID) Received 0 bytes of scan results (2 BSSes) Scan results: 2 CTRL-EVENT-SCAN-RESULTS Selecting BSS from priority group 0 Try to find WPA-enabled AP 0: 00:17:9a:f0:b6:82 ssid='micronet' wpa_ie_len=22 rsn_ie_len=0 caps=0x11 selected based on WPA IE selected WPA AP 00:17:9a:f0:b6:82 ssid='micronet' Trying to associate with 00:17:9a:f0:b6:82 (SSID='micronet' freq=2462 MHz) Cancelling scan request WPA: clearing own WPA/RSN IE Automatic auth_alg selection: 0x1 wpa_driver_bsd_set_auth_alg alg 0x1 authmode 1 WPA: using IEEE 802.11i/D3.0 WPA: Selected cipher suites: group 8 pairwise 8 key_mgmt 2 proto 1 WPA: set AP WPA IE - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 WPA: clearing AP RSN IE WPA: using GTK TKIP WPA: using PTK TKIP WPA: using KEY_MGMT WPA-PSK WPA: Set own WPA IE default - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 No keys have been configured - skip key clearing wpa_driver_bsd_set_drop_unencrypted: enabled=1 State: SCANNING -> ASSOCIATING wpa_driver_bsd_associate: ssid 'micronet' wpa ie len 24 pairwise 2 group 2 key mgmt 1 wpa_driver_bsd_associate: set PRIVACY 1 Setting authentication timeout: 10 sec 0 usec State: ASSOCIATING -> ASSOCIATED Associated to a new BSS: BSSID=00:17:9a:f0:b6:82 No keys have been configured - skip key clearing Associated with 00:17:9a:f0:b6:82 WPA: Association event - clear replay counter WPA: Clear old PTK Setting authentication timeout: 10 sec 0 usec Cancelling scan request RX EAPOL from 00:17:9a:f0:b6:82 RX EAPOL - hexdump(len=99): 01 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 18 79 fd 0e d3 6a d6 d9 b8 50 5b 9f e2 a1 34 50 88 fd 44 19 8d 7e 9a bc ca 4f cd eb 79 47 6c 55 99 44 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Setting authentication timeout: 10 sec 0 usec IEEE 802.1X RX: version=1 type=3 length=95 EAPOL-Key type=254 key_info 0x89 (ver=1 keyidx=0 rsvd=0 Pairwise Ack) key_length=32 key_data_length=0 replay_counter - hexdump(len=8): 00 00 00 00 00 00 18 79 key_nonce - hexdump(len=32): fd 0e d3 6a d6 d9 b8 50 5b 9f e2 a1 34 50 88 fd 44 19 8d 7e 9a bc ca 4f cd eb 79 47 6c 55 99 44 key_iv - hexdump(len=16): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 key_rsc - hexdump(len=8): 00 00 00 00 00 00 00 00 key_id (reserved) - hexdump(len=8): 00 00 00 00 00 00 00 00 key_mic - hexdump(len=16): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 WPA: RX EAPOL-Key - hexdump(len=99): 01 03 00 5f fe 00 89 00 20 00 00 00 00 00 00 18 79 fd 0e d3 6a d6 d9 b8 50 5b 9f e2 a1 34 50 88 fd 44 19 8d 7e 9a bc ca 4f cd eb 79 47 6c 55 99 44 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 State: ASSOCIATED -> 4WAY_HANDSHAKE WPA: RX message 1 of 4-Way Handshake from 00:17:9a:f0:b6:82 (ver=1) WPA: Renewed SNonce - hexdump(len=32): e7 85 ca a4 c8 2b de 3b 24 c6 9b 9e 44 1f 34 53 b7 7c b0 08 27 6f 24 57 58 ec a9 74 d5 c1 ad 50 WPA: PTK derivation - A1=00:15:e9:a4:58:9b A2=00:17:9a:f0:b6:82 WPA: PMK - hexdump(len=32): 19 7b 12 a0 c6 0b ca 92 12 2a a5 77 e6 76 c4 ef 3b bf 43 88 18 b4 9d f1 f6 16 bb ff ac d2 cf 74 WPA: PTK - hexdump(len=64): b8 d1 4e 9a 79 d6 20 c7 8e 99 c1 aa 0e 3b 12 6f f4 f4 f1 d9 fd 63 44 9d 1e 07 96 96 f4 38 e2 eb c0 0d e0 70 cf 42 e4 97 eb ef 33 78 10 b3 d0 7b c4 8e 71 a4 74 c4 54 46 31 40 9e 9f e9 9a 17 f3 WPA: WPA IE for msg 2/4 - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 WPA: Sending EAPOL-Key 2/4 WPA: TX EAPOL-Key - hexdump(len=123): 01 03 00 77 fe 01 09 00 20 00 00 00 00 00 00 18 79 e7 85 ca a4 c8 2b de 3b 24 c6 9b 9e 44 1f 34 53 b7 7c b0 08 27 6f 24 57 58 ec a9 74 d5 c1 ad 50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 82 35 c9 fa 43 a9 1a 7b e7 ba ae e8 b7 42 04 61 00 18 dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 RX EAPOL from 00:17:9a:f0:b6:82 RX EAPOL - hexdump(len=123): 01 03 00 77 fe 01 c9 00 20 00 00 00 00 00 00 18 7a fd 0e d3 6a d6 d9 b8 50 5b 9f e2 a1 34 50 88 fd 44 19 8d 7e 9a bc ca 4f cd eb 79 47 6c 55 99 44 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c1 a9 2f 5f 06 7e c4 73 8c 0a db 12 18 83 b7 b8 00 18 dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 IEEE 802.1X RX: version=1 type=3 length=119 EAPOL-Key type=254 key_info 0x1c9 (ver=1 keyidx=0 rsvd=0 Pairwise Install Ack MIC) key_length=32 key_data_length=24 replay_counter - hexdump(len=8): 00 00 00 00 00 00 18 7a key_nonce - hexdump(len=32): fd 0e d3 6a d6 d9 b8 50 5b 9f e2 a1 34 50 88 fd 44 19 8d 7e 9a bc ca 4f cd eb 79 47 6c 55 99 44 key_iv - hexdump(len=16): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 key_rsc - hexdump(len=8): 00 00 00 00 00 00 00 00 key_id (reserved) - hexdump(len=8): 00 00 00 00 00 00 00 00 key_mic - hexdump(len=16): c1 a9 2f 5f 06 7e c4 73 8c 0a db 12 18 83 b7 b8 WPA: RX EAPOL-Key - hexdump(len=123): 01 03 00 77 fe 01 c9 00 20 00 00 00 00 00 00 18 7a fd 0e d3 6a d6 d9 b8 50 5b 9f e2 a1 34 50 88 fd 44 19 8d 7e 9a bc ca 4f cd eb 79 47 6c 55 99 44 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c1 a9 2f 5f 06 7e c4 73 8c 0a db 12 18 83 b7 b8 00 18 dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 State: 4WAY_HANDSHAKE -> 4WAY_HANDSHAKE WPA: RX message 3 of 4-Way Handshake from 00:17:9a:f0:b6:82 (ver=1) WPA: IE KeyData - hexdump(len=24): dd 16 00 50 f2 01 01 00 00 50 f2 02 01 00 00 50 f2 02 01 00 00 50 f2 02 WPA: Sending EAPOL-Key 4/4 WPA: TX EAPOL-Key - hexdump(len=99): 01 03 00 5f fe 01 09 00 20 00 00 00 00 00 00 18 7a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 d6 ed 39 9f d9 ba 67 3d 71 02 1d 5a 5c a3 51 cb 00 00 WPA: Installing PTK to the driver. WPA: RSC - hexdump(len=6): 00 00 00 00 00 00 wpa_driver_bsd_set_key: alg=TKIP addr=00:17:9a:f0:b6:82 key_idx=0 set_tx=1 seq_len=6 key_len=32 State: 4WAY_HANDSHAKE -> GROUP_HANDSHAKE RX EAPOL from 00:17:9a:f0:b6:82 RX EAPOL - hexdump(len=131): 01 03 00 7f fe 03 b1 00 20 00 00 00 00 00 00 18 7c 73 86 0c ce 6c cb 57 bb b9 18 d9 5f 2c 0c 1d ee 89 b7 34 02 f5 0a 48 bd 45 1e df 05 68 42 d2 78 89 b7 34 02 00 00 00 00 00 00 00 00 00 00 00 02 89 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b8 a4 8d 9d da 1d 7e 78 16 ed ad ed 08 86 e1 59 00 20 b6 f6 79 22 3c d5 ce 0b 9a d9 87 5a 19 11 8b 2f 89 29 a8 c5 e6 6f 2e 3e 26 8f 72 ef 32 68 98 c8 IEEE 802.1X RX: version=1 type=3 length=127 EAPOL-Key type=254 key_info 0x3b1 (ver=1 keyidx=3 rsvd=0 Group Ack MIC Secure) key_length=32 key_data_length=32 replay_counter - hexdump(len=8): 00 00 00 00 00 00 18 7c key_nonce - hexdump(len=32): 73 86 0c ce 6c cb 57 bb b9 18 d9 5f 2c 0c 1d ee 89 b7 34 02 f5 0a 48 bd 45 1e df 05 68 42 d2 78 key_iv - hexdump(len=16): 89 b7 34 02 00 00 00 00 00 00 00 00 00 00 00 02 key_rsc - hexdump(len=8): 89 00 00 00 00 00 00 00 key_id (reserved) - hexdump(len=8): 00 00 00 00 00 00 00 00 key_mic - hexdump(len=16): b8 a4 8d 9d da 1d 7e 78 16 ed ad ed 08 86 e1 59 WPA: RX EAPOL-Key - hexdump(len=131): 01 03 00 7f fe 03 b1 00 20 00 00 00 00 00 00 18 7c 73 86 0c ce 6c cb 57 bb b9 18 d9 5f 2c 0c 1d ee 89 b7 34 02 f5 0a 48 bd 45 1e df 05 68 42 d2 78 89 b7 34 02 00 00 00 00 00 00 00 00 00 00 00 02 89 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b8 a4 8d 9d da 1d 7e 78 16 ed ad ed 08 86 e1 59 00 20 b6 f6 79 22 3c d5 ce 0b 9a d9 87 5a 19 11 8b 2f 89 29 a8 c5 e6 6f 2e 3e 26 8f 72 ef 32 68 98 c8 WPA: RX message 1 of Group Key Handshake from 00:17:9a:f0:b6:82 (ver=1) State: GROUP_HANDSHAKE -> GROUP_HANDSHAKE WPA: Group Key - hexdump(len=32): 76 5a 29 1b c2 1b 83 f6 66 7b ab 11 69 df d0 d4 4a ab 6f b6 37 6a f2 c4 0c 8a 52 8b 17 86 8a 97 WPA: Installing GTK to the driver (keyidx=3 tx=0 len=32). WPA: RSC - hexdump(len=6): 89 00 00 00 00 00 wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=3 set_tx=0 seq_len=6 key_len=32 WPA: Sending EAPOL-Key 2/2 WPA: TX EAPOL-Key - hexdump(len=99): 01 03 00 5f fe 03 31 00 20 00 00 00 00 00 00 18 7c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 35 38 6c a0 5b 7f 1a 13 d5 14 ef 88 9c 6f 0b 00 00 WPA: Key negotiation completed with 00:17:9a:f0:b6:82 [PTK=TKIP GTK=TKIP] Cancelling authentication timeout State: GROUP_HANDSHAKE -> COMPLETED CTRL-EVENT-CONNECTED - Connection to 00:17:9a:f0:b6:82 completed (auth) [id=0 id_str=] RX EAPOL from 00:17:9a:f0:b6:82 RX EAPOL - hexdump(len=131): 01 03 00 7f fe 03 91 00 20 00 00 00 00 00 00 18 7d 61 3d 02 58 83 53 8b 2d cd 0b ec 98 40 aa 52 97 77 6a 2b 33 65 a9 f6 3e 7a 1e a9 21 b0 a9 98 10 77 6a 2b 33 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c7 57 30 c7 63 85 89 1c 48 87 3c 4b 44 6d 95 d6 00 20 0b 9c 67 9e a7 04 7f 3e 17 4b c5 2b ae ce c9 fb 5b ad 0c 15 b1 b5 1c c1 29 79 89 36 37 7a 89 c5 IEEE 802.1X RX: version=1 type=3 length=127 EAPOL-Key type=254 key_info 0x391 (ver=1 keyidx=1 rsvd=0 Group Ack MIC Secure) key_length=32 key_data_length=32 replay_counter - hexdump(len=8): 00 00 00 00 00 00 18 7d key_nonce - hexdump(len=32): 61 3d 02 58 83 53 8b 2d cd 0b ec 98 40 aa 52 97 77 6a 2b 33 65 a9 f6 3e 7a 1e a9 21 b0 a9 98 10 key_iv - hexdump(len=16): 77 6a 2b 33 00 00 00 00 00 00 00 00 00 00 00 02 key_rsc - hexdump(len=8): 00 00 00 00 00 00 00 00 key_id (reserved) - hexdump(len=8): 00 00 00 00 00 00 00 00 key_mic - hexdump(len=16): c7 57 30 c7 63 85 89 1c 48 87 3c 4b 44 6d 95 d6 WPA: RX EAPOL-Key - hexdump(len=131): 01 03 00 7f fe 03 91 00 20 00 00 00 00 00 00 18 7d 61 3d 02 58 83 53 8b 2d cd 0b ec 98 40 aa 52 97 77 6a 2b 33 65 a9 f6 3e 7a 1e a9 21 b0 a9 98 10 77 6a 2b 33 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c7 57 30 c7 63 85 89 1c 48 87 3c 4b 44 6d 95 d6 00 20 0b 9c 67 9e a7 04 7f 3e 17 4b c5 2b ae ce c9 fb 5b ad 0c 15 b1 b5 1c c1 29 79 89 36 37 7a 89 c5 WPA: RX message 1 of Group Key Handshake from 00:17:9a:f0:b6:82 (ver=1) State: COMPLETED -> GROUP_HANDSHAKE WPA: Group Key - hexdump(len=32): d5 ac 9c 27 18 64 aa dd f6 08 8c 7d e5 1f 71 d8 f7 9c 83 91 3a 2d bf b7 bd ca e2 63 3a cd 7b 66 WPA: Installing GTK to the driver (keyidx=1 tx=0 len=32). WPA: RSC - hexdump(len=6): 00 00 00 00 00 00 wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=1 set_tx=0 seq_len=6 key_len=32 WPA: Sending EAPOL-Key 2/2 WPA: TX EAPOL-Key - hexdump(len=99): 01 03 00 5f fe 03 11 00 20 00 00 00 00 00 00 18 7d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 6d 5c 8b 2e a1 80 22 2d ec d9 bb 39 b5 3d 86 b6 00 00 WPA: Group rekeying completed with 00:17:9a:f0:b6:82 [GTK=TKIP] Cancelling authentication timeout State: GROUP_HANDSHAKE -> COMPLETED ^CCTRL-EVENT-TERMINATING - signal 2 received Removing interface wlan0 State: COMPLETED -> DISCONNECTED wpa_driver_bsd_deauthenticate wpa_driver_bsd_del_key: keyidx=0 wpa_driver_bsd_del_key: keyidx=1 wpa_driver_bsd_del_key: keyidx=2 wpa_driver_bsd_del_key: keyidx=3 wpa_driver_bsd_del_key: addr=00:17:9a:f0:b6:82 keyidx=0 ioctl[SIOCS80211, op 20, len 7]: Can't assign requested address wpa_driver_bsd_set_wpa: enabled=0 wpa_driver_bsd_set_wpa_internal: wpa=0 privacy=0 ioctl[SIOCS80211, op 26, arg 0x0]: Operation not supported Failed to disable WPA in the driver. wpa_driver_bsd_set_drop_unencrypted: enabled=0 wpa_driver_bsd_set_countermeasures: enabled=0 No keys have been configured - skip key clearing Cancelling scan request Cancelling authentication timeout wpa_driver_bsd_set_wpa_internal: wpa=1 privacy=0 ELOOP: remaining socket: sock=4 eloop_data=0x28305140 user_data=0x2830d040 handler=0x8067aa0 2009/8/30 Sam Leffler > You appear to say this problem does not entirely stop traffic from flowing. > Please provide a debug wpa_supplicant log that shows a complete session > (i.e. a log with -d and/or -dd). > > Why do you set eapol_version=1. Is this really needed? What is your AP > make/model? > > Note also that country=RU is ignored on freebsd. > > Sam > --0014852f5780d7c3810472602664 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 SGksIFNhbS48YnI+bWFuICg1KSBmb3Igd3BhX3N1cHBsaWNhbnQuY29uZiBzdGFuZHMgdGhhdCBp dCBpcyBkZWZhdWx0IHZhbHVlLCBidXQgd2hlbiBJIGNvbW1lbnRlZCBvdXQgdGhpcyBwYXJhbWV0 ZXIgbm90aGluZyBoYXMgY2hhbmdlZC48YnI+PGJyPkkgcGluZyBJUCBvZiBBY2Nlc3MgUG9pbnQ6 PGJyPjxicj4kIHBpbmcgMTkyLjE2OC4xMi4xwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+ ClBJTkcgMTkyLjE2OC4xMi4xICgxOTIuMTY4LjEyLjEpOiA1NiBkYXRhIGJ5dGVzwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+NjQg Ynl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8L2E+ OiBpY21wX3NlcT0wIHR0bD0xMjggdGltZT02LjQ1MCBtc8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIDxicj42NCBieXRlcyBmcm9tIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMTY4LjEyLjEi PjE5Mi4xNjguMTIuMTwvYT46IGljbXBfc2VxPTMgdHRsPTEyOCB0aW1lPTAuNzYyIG1zwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgo2NCBieXRlcyBmcm9tIDxhIGhyZWY9Imh0 dHA6Ly8xOTIuMTY4LjEyLjEiPjE5Mi4xNjguMTIuMTwvYT46IGljbXBfc2VxPTI1IHR0bD0xMjgg dGltZT0wLjc0MyBtc8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+NjQgYnl0ZXMg ZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8L2E+OiBpY21w X3NlcT03NSB0dGw9MTI4IHRpbWU9MC43NTUgbXPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgPGJyPgo2NCBieXRlcyBmcm9tIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMTY4LjEyLjEiPjE5Mi4x NjguMTIuMTwvYT46IGljbXBfc2VxPTc5IHR0bD0xMjggdGltZT0wLjk1OSBtc8KgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+NjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTky LjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8L2E+OiBpY21wX3NlcT0xMDMgdHRsPTEyOCB0aW1lPTAu NzQwIG1zwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CjY0IGJ5dGVzIGZyb20gPGEg aHJlZj0iaHR0cDovLzE5Mi4xNjguMTIuMSI+MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9zZXE9MTYy IHR0bD0xMjggdGltZT01LjMyMiBtczxicj42NCBieXRlcyBmcm9tIDxhIGhyZWY9Imh0dHA6Ly8x OTIuMTY4LjEyLjEiPjE5Mi4xNjguMTIuMTwvYT46IGljbXBfc2VxPTE2NCB0dGw9MTI4IHRpbWU9 NS43MDUgbXM8YnI+NjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4xMi4xIj4x OTIuMTY4LjEyLjE8L2E+OiBpY21wX3NlcT0xNjUgdHRsPTEyOCB0aW1lPTIyLjEzOCBtczxicj4K NjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8 L2E+OiBpY21wX3NlcT0xNjYgdHRsPTEyOCB0aW1lPTEuMjE4IG1zPGJyPjY0IGJ5dGVzIGZyb20g PGEgaHJlZj0iaHR0cDovLzE5Mi4xNjguMTIuMSI+MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9zZXE9 MTY3IHR0bD0xMjggdGltZT0yNi43ODggbXM8YnI+NjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRw Oi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8L2E+OiBpY21wX3NlcT0xNjggdHRsPTEyOCB0 aW1lPTE3LjA5NyBtczxicj4KNjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4x Mi4xIj4xOTIuMTY4LjEyLjE8L2E+OiBpY21wX3NlcT0xNjkgdHRsPTEyOCB0aW1lPTMuNjI4IG1z PGJyPjY0IGJ5dGVzIGZyb20gPGEgaHJlZj0iaHR0cDovLzE5Mi4xNjguMTIuMSI+MTkyLjE2OC4x Mi4xPC9hPjogaWNtcF9zZXE9MjE3IHR0bD0xMjggdGltZT0xLjc4OCBtczxicj42NCBieXRlcyBm cm9tIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMTY4LjEyLjEiPjE5Mi4xNjguMTIuMTwvYT46IGljbXBf c2VxPTIxOCB0dGw9MTI4IHRpbWU9My42MjYgbXM8YnI+CjY0IGJ5dGVzIGZyb20gPGEgaHJlZj0i aHR0cDovLzE5Mi4xNjguMTIuMSI+MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9zZXE9MjE5IHR0bD0x MjggdGltZT02LjAxMSBtczxicj42NCBieXRlcyBmcm9tIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMTY4 LjEyLjEiPjE5Mi4xNjguMTIuMTwvYT46IGljbXBfc2VxPTIyMCB0dGw9MTI4IHRpbWU9Mi42OTkg bXM8YnI+NjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4 LjEyLjE8L2E+OiBpY21wX3NlcT0yMjEgdHRsPTEyOCB0aW1lPTEuODA0IG1zPGJyPgo2NCBieXRl cyBmcm9tIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMTY4LjEyLjEiPjE5Mi4xNjguMTIuMTwvYT46IGlj bXBfc2VxPTIyMiB0dGw9MTI4IHRpbWU9My4wNDQgbXM8YnI+NjQgYnl0ZXMgZnJvbSA8YSBocmVm PSJodHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8L2E+OiBpY21wX3NlcT0yMjMgdHRs PTEyOCB0aW1lPTIuNjIxIG1zPGJyPjY0IGJ5dGVzIGZyb20gPGEgaHJlZj0iaHR0cDovLzE5Mi4x NjguMTIuMSI+MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9zZXE9MjI0IHR0bD0xMjggdGltZT0yLjg1 MiBtczxicj4KNjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIu MTY4LjEyLjE8L2E+OiBpY21wX3NlcT0yMjUgdHRsPTEyOCB0aW1lPTEuMTYxIG1zPGJyPjY0IGJ5 dGVzIGZyb20gPGEgaHJlZj0iaHR0cDovLzE5Mi4xNjguMTIuMSI+MTkyLjE2OC4xMi4xPC9hPjog aWNtcF9zZXE9MjI2IHR0bD0xMjggdGltZT00LjU3OSBtczxicj42NCBieXRlcyBmcm9tIDxhIGhy ZWY9Imh0dHA6Ly8xOTIuMTY4LjEyLjEiPjE5Mi4xNjguMTIuMTwvYT46IGljbXBfc2VxPTIyNyB0 dGw9MTI4IHRpbWU9My45MzUgbXM8YnI+CjY0IGJ5dGVzIGZyb20gPGEgaHJlZj0iaHR0cDovLzE5 Mi4xNjguMTIuMSI+MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9zZXE9MjI4IHR0bD0xMjggdGltZT00 LjM5MCBtczxicj42NCBieXRlcyBmcm9tIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMTY4LjEyLjEiPjE5 Mi4xNjguMTIuMTwvYT46IGljbXBfc2VxPTIyOSB0dGw9MTI4IHRpbWU9Mi43NDEgbXM8YnI+NjQg Ynl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8L2E+ OiBpY21wX3NlcT0yMzAgdHRsPTEyOCB0aW1lPTMuNzExIG1zPGJyPgo2NCBieXRlcyBmcm9tIDxh IGhyZWY9Imh0dHA6Ly8xOTIuMTY4LjEyLjEiPjE5Mi4xNjguMTIuMTwvYT46IGljbXBfc2VxPTIz MSB0dGw9MTI4IHRpbWU9OC4wMDMgbXM8YnI+NjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8v MTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8L2E+OiBpY21wX3NlcT0yMzIgdHRsPTEyOCB0aW1l PTYuMDgyIG1zPGJyPjY0IGJ5dGVzIGZyb20gPGEgaHJlZj0iaHR0cDovLzE5Mi4xNjguMTIuMSI+ MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9zZXE9MjMzIHR0bD0xMjggdGltZT01LjA1OSBtczxicj4K NjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJodHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8 L2E+OiBpY21wX3NlcT0yMzQgdHRsPTEyOCB0aW1lPTIuNDU2IG1zPGJyPjY0IGJ5dGVzIGZyb20g PGEgaHJlZj0iaHR0cDovLzE5Mi4xNjguMTIuMSI+MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9zZXE9 MjM1IHR0bD0xMjggdGltZT0zLjE0NCBtczxicj42NCBieXRlcyBmcm9tIDxhIGhyZWY9Imh0dHA6 Ly8xOTIuMTY4LjEyLjEiPjE5Mi4xNjguMTIuMTwvYT46IGljbXBfc2VxPTIzNiB0dGw9MTI4IHRp bWU9MS4yMDIgbXM8YnI+CjY0IGJ5dGVzIGZyb20gPGEgaHJlZj0iaHR0cDovLzE5Mi4xNjguMTIu MSI+MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9zZXE9MjM3IHR0bD0xMjggdGltZT02LjU2NiBtczxi cj42NCBieXRlcyBmcm9tIDxhIGhyZWY9Imh0dHA6Ly8xOTIuMTY4LjEyLjEiPjE5Mi4xNjguMTIu MTwvYT46IGljbXBfc2VxPTIzOCB0dGw9MTI4IHRpbWU9MTMuODMwIG1zPGJyPjY0IGJ5dGVzIGZy b20gPGEgaHJlZj0iaHR0cDovLzE5Mi4xNjguMTIuMSI+MTkyLjE2OC4xMi4xPC9hPjogaWNtcF9z ZXE9MjM5IHR0bD0xMjggdGltZT01LjQ2MyBtczxicj4KNjQgYnl0ZXMgZnJvbSA8YSBocmVmPSJo dHRwOi8vMTkyLjE2OC4xMi4xIj4xOTIuMTY4LjEyLjE8L2E+OiBpY21wX3NlcT0yNDAgdHRsPTEy OCB0aW1lPTEuMjcyIG1zPGJyPl5DPGJyPi0tLSAxOTIuMTY4LjEyLjEgcGluZyBzdGF0aXN0aWNz IC0tLTxicj4yNDEgcGFja2V0cyB0cmFuc21pdHRlZCwgMzcgcGFja2V0cyByZWNlaXZlZCwgODQu NiUgcGFja2V0IGxvc3M8YnI+cm91bmQtdHJpcCBtaW4vYXZnL21heC9zdGRkZXYgPSAwLjc0MC81 LjE0NC8yNi43ODgvNS43MzQgbXM8YnI+Cjxicj48YnI+bG9ncyAoZHVyaW5nIHBpbmcpIHRoYXQg eW91IGFyZSByZXF1ZXN0ZWQ6PGJyPjxicj4jIHdwYV9zdXBwbGljYW50IC1LZGQgLWkgd2xhbjAg LURic2QgLWMgL2V0Yy93cGFfc3VwcGxpY2FudC5jb25mIDxicj5Jbml0aWFsaXppbmcgaW50ZXJm YWNlICYjMzk7d2xhbjAmIzM5OyBjb25mICYjMzk7L2V0Yy93cGFfc3VwcGxpY2FudC5jb25mJiMz OTsgZHJpdmVyICYjMzk7YnNkJiMzOTsgY3RybF9pbnRlcmZhY2UgJiMzOTtOL0EmIzM5OyBicmlk Z2UgJiMzOTtOL0EmIzM5O8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CkNvbmZp Z3VyYXRpb24gZmlsZSAmIzM5Oy9ldGMvd3BhX3N1cHBsaWNhbnQuY29uZiYjMzk7IC0mZ3Q7ICYj Mzk7L2V0Yy93cGFfc3VwcGxpY2FudC5jb25mJiMzOTvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgPGJyPlJlYWRpbmcgY29uZmlndXJhdGlvbiBmaWxlICYjMzk7L2V0Yy93cGFfc3VwcGxp Y2FudC5jb25mJiMzOTvCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+Y3RybF9pbnRlcmZhY2VfZ3JvdXA9 JiMzOTt3aGVlbCYjMzk7wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CmVhcG9sX3ZlcnNpb249McKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+YXBfc2Nhbj0xwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5mYXN0X3JlYXV0aD0xwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CmNvdW50cnk9JiMzOTtSVSYjMzk7 wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5MaW5lOiAxMCAt IHN0YXJ0IG9mIGEgbmV3IG5ldHdvcmsgYmxvY2vCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgPGJyPnNzaWQgLSBoZXhkdW1wX2FzY2lpKGxlbj04KTrCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIDxicj4KwqDCoMKgwqAgNmQgNjkgNjMgNzIgNmYgNmUgNjUgNzTCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIG1pY3JvbmV0wqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5CU1NJRCAtIGhl eGR1bXAobGVuPTYpOiAwMCAxNyA5YSBmMCBiNiA4MsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIDxicj5zY2FuX3NzaWQ9MSAoMHgxKcKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIDxicj4Ka2V5X21nbXQ6IDB4MsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgPGJyPnByb3RvOiAweDHCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDxicj5wYWlyd2lzZTogMHg4wqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+Cmdyb3VwOiAweDjCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5QU0sgKEFTQ0lJIHBhc3NwaHJhc2UpIC0gaGV4 ZHVtcF9hc2NpaShsZW49MzEpOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj7CoMKg wqDCoCA0ZSA2NCA0NyA2YSA1MSA3NCA1NSA0ZCAyNCA3NSA3NCA2MiA2YiAyZSA0OSAzN8KgwqAg TmRHalF0VU0kdXRiay5JN8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxi cj4KwqDCoMKgwqAgNDQgNzMgNmIgMzcgMzYgMmUgMmUgNjYgMzAgNjEgNTkgNjEgNTUgNjUgMmXC oMKgwqDCoMKgIERzazc2Li5mMGFZYVVlLsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgPGJyPlBTSyAoZnJvbSBwYXNzcGhyYXNlKSAtIGhleGR1bXAobGVuPTMyKTogMTkg N2IgMTIgYTAgYzYgMGIgY2EgOTIgMTIgMmEgYTUgNzcgZTYgNzYgYzQgZWYgM2IgYmYgNDMgODgg MTggYjQgOWQgZjEgZjYgMTYgYmIgZmYgYWMgZDIgY2YgNzTCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgPGJyPgpQcmlvcml0eSBncm91cCAwwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCA8YnI+wqDCoCBpZD0wIHNzaWQ9JiMzOTttaWNyb25ldCYjMzk7wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgPGJyPkluaXRpYWxpemluZyBpbnRlcmZhY2UgKDIpICYjMzk7d2xhbjAmIzM5 O8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg PGJyPgpPd24gTUFDIGFkZHJlc3M6IDAwOjE1OmU5OmE0OjU4OjliwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+d3BhX2RyaXZlcl9ic2Rf c2V0X3dwYTogZW5hYmxlZD0xwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDxicj53cGFfZHJpdmVyX2JzZF9zZXRfd3BhX2ludGVybmFsOiB3 cGE9MyBwcml2YWN5PTHCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgp3cGFfZHJpdmVy X2JzZF9kZWxfa2V5OiBrZXlpZHg9MMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj53cGFfZHJpdmVyX2JzZF9kZWxfa2V5OiBrZXlp ZHg9McKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIDxicj53cGFfZHJpdmVyX2JzZF9kZWxfa2V5OiBrZXlpZHg9MsKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj4Kd3BhX2Ry aXZlcl9ic2RfZGVsX2tleToga2V5aWR4PTPCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+d3BhX2RyaXZlcl9ic2Rfc2V0X2NvdW50 ZXJtZWFzdXJlczogZW5hYmxlZD0wwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxi cj53cGFfZHJpdmVyX2JzZF9zZXRfZHJvcF91bmVuY3J5cHRlZDogZW5hYmxlZD0xwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+ClJTTjogZmx1c2hpbmcgUE1LSUQgbGlzdCBpbiB0 aGUgZHJpdmVywqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg PGJyPlNldHRpbmcgc2NhbiByZXF1ZXN0OiAwIHNlYyAxMDAwMDAgdXNlY8KgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+QWRkZWQgaW50ZXJmYWNlIHdsYW4w wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj4KU3RhdGU6IERJU0NPTk5FQ1RFRCAtJmd0OyBT Q0FOTklOR8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgPGJyPlN0YXJ0aW5nIEFQIHNjYW4gKHNwZWNpZmljIFNTSUQpwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPlNj YW4gU1NJRCAtIGhleGR1bXBfYXNjaWkobGVuPTgpOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CsKgwqDCoMKgIDZkIDY5IDYzIDcy IDZmIDZlIDY1IDc0wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCBtaWNyb25ldMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCA8YnI+VHJ5aW5nIHRvIGdldCBjdXJyZW50IHNjYW4gcmVzdWx0cyBmaXJz dCB3aXRob3V0IHJlcXVlc3RpbmcgYSBuZXcgc2NhbiB0byBzcGVlZCB1cCBpbml0aWFsIGFzc29j aWF0aW9uwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgpS ZWNlaXZlZCAwIGJ5dGVzIG9mIHNjYW4gcmVzdWx0cyAoMCBCU1NlcynCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPlNjYW4gcmVzdWx0czogMMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+Q2FjaGVkIHNjYW4gcmVzdWx0cyBhcmUgZW1wdHkg LSBub3QgcG9zdGluZ8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgpT ZWxlY3RpbmcgQlNTIGZyb20gcHJpb3JpdHkgZ3JvdXAgMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5UcnkgdG8gZmluZCBXUEEtZW5hYmxl ZCBBUMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDxicj5UcnkgdG8gZmluZCBub24tV1BBIEFQwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCA8YnI+Ck5vIHN1aXRhYmxlIEFQIGZvdW5kLsKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCA8YnI+U2V0dGluZyBzY2FuIHJlcXVlc3Q6IDAgc2VjIDAgdXNlY8KgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPlN0YXJ0aW5nIEFQ IHNjYW4gKGJyb2FkY2FzdCBTU0lEKcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+ClJlY2VpdmVkIDAgYnl0ZXMgb2Ygc2NhbiByZXN1 bHRzICgyIEJTU2VzKcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+ U2NhbiByZXN1bHRzOiAywqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5D VFJMLUVWRU5ULVNDQU4tUkVTVUxUU8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj4KU2VsZWN0aW5n IEJTUyBmcm9tIHByaW9yaXR5IGdyb3VwIDDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+VHJ5IHRvIGZpbmQgV1BBLWVuYWJsZWQgQVDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCA8YnI+MDogMDA6MTc6OWE6ZjA6YjY6ODIgc3NpZD0mIzM5O21pY3JvbmV0JiMz OTsgd3BhX2llX2xlbj0yMiByc25faWVfbGVuPTAgY2Fwcz0weDExwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCA8YnI+CsKgwqAgc2VsZWN0ZWQgYmFzZWQgb24gV1BBIElFwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIDxicj7CoMKgIHNlbGVjdGVkIFdQQSBBUCAwMDoxNzo5YTpmMDpiNjo4MiBzc2lkPSYj Mzk7bWljcm9uZXQmIzM5O8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPlRyeWluZyB0byBhc3NvY2lh dGUgd2l0aCAwMDoxNzo5YTpmMDpiNjo4MiAoU1NJRD0mIzM5O21pY3JvbmV0JiMzOTsgZnJlcT0y NDYyIE1IeinCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CkNhbmNlbGxpbmcg c2NhbiByZXF1ZXN0wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPldQQTogY2xlYXJpbmcgb3duIFdQ QS9SU04gSUXCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDxicj5BdXRvbWF0aWMgYXV0aF9hbGcgc2VsZWN0aW9uOiAweDHC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg PGJyPgp3cGFfZHJpdmVyX2JzZF9zZXRfYXV0aF9hbGcgYWxnIDB4MSBhdXRobW9kZSAxwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+V1BBOiB1c2luZyBJRUVFIDgwMi4xMWkvRDMu MMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgPGJyPldQQTogU2VsZWN0ZWQgY2lwaGVyIHN1aXRlczogZ3JvdXAgOCBwYWly d2lzZSA4IGtleV9tZ210IDIgcHJvdG8gMcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCA8YnI+CldQQTogc2V0IEFQIFdQQSBJRSAtIGhleGR1bXAobGVuPTI0 KTogZGQgMTYgMDAgNTAgZjIgMDEgMDEgMDAgMDAgNTAgZjIgMDIgMDEgMDAgMDAgNTAgZjIgMDIg MDEgMDAgMDAgNTAgZjIgMDLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPldQQTog Y2xlYXJpbmcgQVAgUlNOIElFwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgpXUEE6IHVzaW5nIEdU SyBUS0lQwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+V1BBOiB1c2luZyBQVEsgVEtJ UMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPldQQTogdXNpbmcgS0VZX01HTVQgV1BB LVBTS8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCA8YnI+CldQQTogU2V0IG93biBXUEEgSUUgZGVmYXVsdCAtIGhleGR1 bXAobGVuPTI0KTogZGQgMTYgMDAgNTAgZjIgMDEgMDEgMDAgMDAgNTAgZjIgMDIgMDEgMDAgMDAg NTAgZjIgMDIgMDEgMDAgMDAgNTAgZjIgMDLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPk5vIGtleXMgaGF2ZSBi ZWVuIGNvbmZpZ3VyZWQgLSBza2lwIGtleSBjbGVhcmluZ8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoCA8YnI+CndwYV9kcml2ZXJfYnNkX3NldF9kcm9wX3VuZW5jcnlwdGVkOiBlbmFibGVkPTHC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5TdGF0ZTogU0NBTk5JTkcgLSZndDsg QVNTT0NJQVRJTkfCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgPGJyPndwYV9kcml2ZXJfYnNkX2Fzc29jaWF0ZTogc3NpZCAmIzM5 O21pY3JvbmV0JiMzOTsgd3BhIGllIGxlbiAyNCBwYWlyd2lzZSAyIGdyb3VwIDIga2V5IG1nbXQg McKgwqDCoMKgwqAgPGJyPgp3cGFfZHJpdmVyX2JzZF9hc3NvY2lhdGU6IHNldCBQUklWQUNZIDHC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPlNldHRpbmcg YXV0aGVudGljYXRpb24gdGltZW91dDogMTAgc2VjIDAgdXNlY8KgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCA8YnI+U3RhdGU6IEFTU09DSUFUSU5HIC0mZ3Q7IEFTU09DSUFURUTCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8 YnI+CkFzc29jaWF0ZWQgdG8gYSBuZXcgQlNTOiBCU1NJRD0wMDoxNzo5YTpmMDpiNjo4MsKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+Tm8ga2V5cyBoYXZlIGJlZW4gY29uZmlndXJlZCAt IHNraXAga2V5IGNsZWFyaW5nwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5Bc3NvY2lh dGVkIHdpdGggMDA6MTc6OWE6ZjA6YjY6ODLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgpXUEE6IEFzc29jaWF0aW9uIGV2ZW50IC0g Y2xlYXIgcmVwbGF5IGNvdW50ZXLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJy PldQQTogQ2xlYXIgb2xkIFBUS8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+U2V0 dGluZyBhdXRoZW50aWNhdGlvbiB0aW1lb3V0OiAxMCBzZWMgMCB1c2VjwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDxicj4KQ2FuY2VsbGluZyBzY2FuIHJlcXVlc3TCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCA8YnI+UlggRUFQT0wgZnJvbSAwMDoxNzo5YTpmMDpiNjo4MsKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPlJY IEVBUE9MIC0gaGV4ZHVtcChsZW49OTkpOiAwMSAwMyAwMCA1ZiBmZSAwMCA4OSAwMCAyMCAwMCAw MCAwMCAwMCAwMCAwMCAxOCA3OSBmZCAwZSBkMyA2YSBkNiBkOSBiOCA1MCA1YiA5ZiBlMiBhMSAz NCA1MCA4OCBmZCA0NCAxOSA4ZCA3ZSA5YSBiYyBjYSA0ZiBjZCBlYiA3OSA0NyA2YyA1NSA5OSA0 NCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCA8YnI+ClNldHRpbmcgYXV0aGVudGljYXRpb24gdGltZW91dDogMTAgc2VjIDAgdXNlY8KgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+SUVFRSA4MDIuMVggUlg6IHZlcnNpb249 MSB0eXBlPTMgbGVuZ3RoPTk1wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IDxicj7CoCBFQVBPTC1LZXkgdHlwZT0yNTTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+ CsKgIGtleV9pbmZvIDB4ODkgKHZlcj0xIGtleWlkeD0wIHJzdmQ9MCBQYWlyd2lzZSBBY2spwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAga2V5X2xlbmd0aD0zMiBrZXlfZGF0YV9sZW5ndGg9MMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8 YnI+wqAgcmVwbGF5X2NvdW50ZXIgLSBoZXhkdW1wKGxlbj04KTogMDAgMDAgMDAgMDAgMDAgMDAg MTggNznCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIDxicj4KwqAga2V5X25vbmNlIC0gaGV4ZHVtcChsZW49MzIpOiBmZCAwZSBk MyA2YSBkNiBkOSBiOCA1MCA1YiA5ZiBlMiBhMSAzNCA1MCA4OCBmZCA0NCAxOSA4ZCA3ZSA5YSBi YyBjYSA0ZiBjZCBlYiA3OSA0NyA2YyA1NSA5OSA0NMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj7CoCBrZXlfaXYgLSBoZXhkdW1wKGxlbj0x Nik6IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj4KwqAga2V5X3JzYyAtIGhleGR1bXAobGVuPTgp OiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAga2V5 X2lkIChyZXNlcnZlZCkgLSBoZXhkdW1wKGxlbj04KTogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IDxicj7CoCBrZXlfbWljIC0gaGV4ZHVtcChsZW49MTYpOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJy PgpXUEE6IFJYIEVBUE9MLUtleSAtIGhleGR1bXAobGVuPTk5KTogMDEgMDMgMDAgNWYgZmUgMDAg ODkgMDAgMjAgMDAgMDAgMDAgMDAgMDAgMDAgMTggNzkgZmQgMGUgZDMgNmEgZDYgZDkgYjggNTAg NWIgOWYgZTIgYTEgMzQgNTAgODggZmQgNDQgMTkgOGQgN2UgOWEgYmMgY2EgNGYgY2QgZWIgNzkg NDcgNmMgNTUgOTkgNDQgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJy PgpTdGF0ZTogQVNTT0NJQVRFRCAtJmd0OyA0V0FZX0hBTkRTSEFLRcKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5XUEE6IFJYIG1lc3NhZ2Ug MSBvZiA0LVdheSBIYW5kc2hha2UgZnJvbSAwMDoxNzo5YTpmMDpiNjo4MiAodmVyPTEpwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+V1BBOiBSZW5ld2Vk IFNOb25jZSAtIGhleGR1bXAobGVuPTMyKTogZTcgODUgY2EgYTQgYzggMmIgZGUgM2IgMjQgYzYg OWIgOWUgNDQgMWYgMzQgNTMgYjcgN2MgYjAgMDggMjcgNmYgMjQgNTcgNTggZWMgYTkgNzQgZDUg YzEgYWQgNTDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj4KV1BBOiBQ VEsgZGVyaXZhdGlvbiAtIEExPTAwOjE1OmU5OmE0OjU4OjliIEEyPTAwOjE3OjlhOmYwOmI2Ojgy wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxi cj5XUEE6IFBNSyAtIGhleGR1bXAobGVuPTMyKTogMTkgN2IgMTIgYTAgYzYgMGIgY2EgOTIgMTIg MmEgYTUgNzcgZTYgNzYgYzQgZWYgM2IgYmYgNDMgODggMTggYjQgOWQgZjEgZjYgMTYgYmIgZmYg YWMgZDIgY2YgNzTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCA8YnI+CldQQTogUFRLIC0gaGV4ZHVtcChsZW49NjQpOiBiOCBkMSA0ZSA5 YSA3OSBkNiAyMCBjNyA4ZSA5OSBjMSBhYSAwZSAzYiAxMiA2ZiBmNCBmNCBmMSBkOSBmZCA2MyA0 NCA5ZCAxZSAwNyA5NiA5NiBmNCAzOCBlMiBlYiBjMCAwZCBlMCA3MCBjZiA0MiBlNCA5NyBlYiBl ZiAzMyA3OCAxMCBiMyBkMCA3YiBjNCA4ZSA3MSBhNCA3NCBjNCA1NCA0NiAzMSA0MCA5ZSA5ZiBl OSA5YSAxNyBmM8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgPGJyPgpXUEE6IFdQQSBJRSBmb3IgbXNnIDIvNCAtIGhleGR1bXAobGVuPTI0KTogZGQgMTYg MDAgNTAgZjIgMDEgMDEgMDAgMDAgNTAgZjIgMDIgMDEgMDAgMDAgNTAgZjIgMDIgMDEgMDAgMDAg NTAgZjIgMDLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+V1BBOiBTZW5kaW5nIEVBUE9MLUtleSAy LzTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCA8YnI+CldQQTogVFggRUFQT0wtS2V5IC0gaGV4ZHVtcChsZW49MTIz KTogMDEgMDMgMDAgNzcgZmUgMDEgMDkgMDAgMjAgMDAgMDAgMDAgMDAgMDAgMDAgMTggNzkgZTcg ODUgY2EgYTQgYzggMmIgZGUgM2IgMjQgYzYgOWIgOWUgNDQgMWYgMzQgNTMgYjcgN2MgYjAgMDgg MjcgNmYgMjQgNTcgNTggZWMgYTkgNzQgZDUgYzEgYWQgNTAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgODIgMzUgYzkgZmEgNDMgYTkgMWEgN2IgZTcgYmEgYWUgZTggYjcg NDIgMDQgNjEgMDAgMTggZGQgMTYgMDAgNTAgZjIgMDEgMDEgMDAgMDAgNTAgZjIgMDIgMDEgMDAg MDAgNTAgZjIgMDIgMDEgMDAgMDAgNTAgZjIgMDLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgPGJyPgpSWCBFQVBPTCBmcm9tIDAwOjE3OjlhOmYwOmI2OjgywqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+ UlggRUFQT0wgLSBoZXhkdW1wKGxlbj0xMjMpOiAwMSAwMyAwMCA3NyBmZSAwMSBjOSAwMCAyMCAw MCAwMCAwMCAwMCAwMCAwMCAxOCA3YSBmZCAwZSBkMyA2YSBkNiBkOSBiOCA1MCA1YiA5ZiBlMiBh MSAzNCA1MCA4OCBmZCA0NCAxOSA4ZCA3ZSA5YSBiYyBjYSA0ZiBjZCBlYiA3OSA0NyA2YyA1NSA5 OSA0NCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCBjMSBhOSAyZiA1ZiAw NiA3ZSBjNCA3MyA4YyAwYSBkYiAxMiAxOCA4MyBiNyBiOCAwMCAxOCBkZCAxNiAwMCA1MCBmMiAw MSAwMSAwMCAwMCA1MCBmMiAwMiAwMSAwMCAwMCA1MCBmMiAwMiAwMSAwMCAwMCA1MCBmMiAwMsKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8 YnI+CklFRUUgODAyLjFYIFJYOiB2ZXJzaW9uPTEgdHlwZT0zIGxlbmd0aD0xMTnCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj7CoCBFQVBPTC1LZXkgdHlwZT0yNTTCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAga2V5X2luZm8gMHgxYzkgKHZlcj0xIGtleWlk eD0wIHJzdmQ9MCBQYWlyd2lzZSBJbnN0YWxsIEFjayBNSUMpwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgrCoCBrZXlfbGVuZ3RoPTMyIGtleV9k YXRhX2xlbmd0aD0yNMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqAgPGJyPsKgIHJlcGxheV9jb3VudGVyIC0gaGV4ZHVtcChsZW49OCk6IDAwIDAw IDAwIDAwIDAwIDAwIDE4IDdhwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAga2V5X25vbmNlIC0gaGV4ZHVtcChsZW49 MzIpOiBmZCAwZSBkMyA2YSBkNiBkOSBiOCA1MCA1YiA5ZiBlMiBhMSAzNCA1MCA4OCBmZCA0NCAx OSA4ZCA3ZSA5YSBiYyBjYSA0ZiBjZCBlYiA3OSA0NyA2YyA1NSA5OSA0NMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj4KwqAga2V5X2l2IC0g aGV4ZHVtcChsZW49MTYpOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAga2V5X3JzYyAtIGhl eGR1bXAobGVuPTgpOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oCA8YnI+wqAga2V5X2lkIChyZXNlcnZlZCkgLSBoZXhkdW1wKGxlbj04KTogMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIDxicj4KwqAga2V5X21pYyAtIGhleGR1bXAobGVuPTE2KTogYzEgYTkgMmYg NWYgMDYgN2UgYzQgNzMgOGMgMGEgZGIgMTIgMTggODMgYjcgYjjCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIDxicj5XUEE6IFJYIEVBUE9MLUtleSAtIGhleGR1bXAobGVuPTEyMyk6IDAxIDAz IDAwIDc3IGZlIDAxIGM5IDAwIDIwIDAwIDAwIDAwIDAwIDAwIDAwIDE4IDdhIGZkIDBlIGQzIDZh IGQ2IGQ5IGI4IDUwIDViIDlmIGUyIGExIDM0IDUwIDg4IGZkIDQ0IDE5IDhkIDdlIDlhIGJjIGNh IDRmIGNkIGViIDc5IDQ3IDZjIDU1IDk5IDQ0IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIGMxIGE5IDJmIDVmIDA2IDdlIGM0IDczIDhjIDBhIGRiIDEyIDE4IDgzIGI3IGI4 IDAwIDE4IGRkIDE2IDAwIDUwIGYyIDAxIDAxIDAwIDAwIDUwIGYyIDAyIDAxIDAwIDAwIDUwIGYy IDAyIDAxIDAwIDAwIDUwIGYyIDAywqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgIDxicj4KU3RhdGU6IDRXQVlfSEFORFNIQUtFIC0mZ3Q7IDRXQVlfSEFORFNIQUtFwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5XUEE6IFJYIG1lc3Nh Z2UgMyBvZiA0LVdheSBIYW5kc2hha2UgZnJvbSAwMDoxNzo5YTpmMDpiNjo4MiAodmVyPTEpwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+V1BBOiBJRSBL ZXlEYXRhIC0gaGV4ZHVtcChsZW49MjQpOiBkZCAxNiAwMCA1MCBmMiAwMSAwMSAwMCAwMCA1MCBm MiAwMiAwMSAwMCAwMCA1MCBmMiAwMiAwMSAwMCAwMCA1MCBmMiAwMsKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CldQQTogU2VuZGluZyBFQVBPTC1LZXkgNC80wqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgPGJyPldQQTogVFggRUFQT0wtS2V5IC0gaGV4ZHVtcChsZW49OTkpOiAwMSAwMyAw MCA1ZiBmZSAwMSAwOSAwMCAyMCAwMCAwMCAwMCAwMCAwMCAwMCAxOCA3YSAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCBkNiBlZCAzOSA5ZiBkOSBiYSA2NyAzZCA3MSAwMiAxZCA1YSA1YyBhMyA1MSBjYiAw MCAwMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCA8YnI+CldQQTogSW5zdGFsbGluZyBQVEsgdG8gdGhlIGRyaXZlci7CoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5XUEE6IFJT QyAtIGhleGR1bXAobGVuPTYpOiAwMCAwMCAwMCAwMCAwMCAwMMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIDxicj53cGFfZHJpdmVyX2JzZF9zZXRfa2V5OiBhbGc9VEtJUCBhZGRy PTAwOjE3OjlhOmYwOmI2OjgyIGtleV9pZHg9MCBzZXRfdHg9MSBzZXFfbGVuPTYga2V5X2xlbj0z MsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqAgPGJyPgpTdGF0ZTogNFdBWV9IQU5EU0hBS0UgLSZndDsgR1JPVVBfSEFORFNIQUtFwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+UlggRUFQT0wgZnJvbSAw MDoxNzo5YTpmMDpiNjo4MsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPlJYIEVBUE9MIC0gaGV4ZHVtcChsZW49MTMxKTogMDEg MDMgMDAgN2YgZmUgMDMgYjEgMDAgMjAgMDAgMDAgMDAgMDAgMDAgMDAgMTggN2MgNzMgODYgMGMg Y2UgNmMgY2IgNTcgYmIgYjkgMTggZDkgNWYgMmMgMGMgMWQgZWUgODkgYjcgMzQgMDIgZjUgMGEg NDggYmQgNDUgMWUgZGYgMDUgNjggNDIgZDIgNzggODkgYjcgMzQgMDIgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDIgODkgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgYjggYTQgOGQgOWQgZGEgMWQgN2UgNzggMTYgZWQgYWQgZWQgMDggODYgZTEg NTkgMDAgMjAgYjYgZjYgNzkgMjIgM2MgZDUgY2UgMGIgOWEgZDkgODcgNWEgMTkgMTEgOGIgMmYg ODkgMjkgYTggYzUgZTYgNmYgMmUgM2UgMjYgOGYgNzIgZWYgMzIgNjggOTggYzjCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAg PGJyPgpJRUVFIDgwMi4xWCBSWDogdmVyc2lvbj0xIHR5cGU9MyBsZW5ndGg9MTI3wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAgRUFQT0wtS2V5IHR5cGU9MjU0wqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPsKgIGtleV9pbmZvIDB4M2IxICh2ZXI9MSBrZXlp ZHg9MyByc3ZkPTAgR3JvdXAgQWNrIE1JQyBTZWN1cmUpwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CsKgIGtleV9sZW5ndGg9MzIg a2V5X2RhdGFfbGVuZ3RoPTMywqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAgcmVwbGF5X2NvdW50ZXIgLSBoZXhkdW1wKGxlbj04KTog MDAgMDAgMDAgMDAgMDAgMDAgMTggN2PCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj7CoCBrZXlfbm9uY2UgLSBoZXhkdW1w KGxlbj0zMik6IDczIDg2IDBjIGNlIDZjIGNiIDU3IGJiIGI5IDE4IGQ5IDVmIDJjIDBjIDFkIGVl IDg5IGI3IDM0IDAyIGY1IDBhIDQ4IGJkIDQ1IDFlIGRmIDA1IDY4IDQyIGQyIDc4wqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgrCoCBrZXlf aXYgLSBoZXhkdW1wKGxlbj0xNik6IDg5IGI3IDM0IDAyIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAywqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj7CoCBrZXlfcnNj IC0gaGV4ZHVtcChsZW49OCk6IDg5IDAwIDAwIDAwIDAwIDAwIDAwIDAwwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgIDxicj7CoCBrZXlfaWQgKHJlc2VydmVkKSAtIGhleGR1bXAobGVuPTgpOiAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqAgPGJyPgrCoCBrZXlfbWljIC0gaGV4ZHVtcChsZW49MTYpOiBiOCBh NCA4ZCA5ZCBkYSAxZCA3ZSA3OCAxNiBlZCBhZCBlZCAwOCA4NiBlMSA1OcKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgPGJyPldQQTogUlggRUFQT0wtS2V5IC0gaGV4ZHVtcChsZW49MTMxKTog MDEgMDMgMDAgN2YgZmUgMDMgYjEgMDAgMjAgMDAgMDAgMDAgMDAgMDAgMDAgMTggN2MgNzMgODYg MGMgY2UgNmMgY2IgNTcgYmIgYjkgMTggZDkgNWYgMmMgMGMgMWQgZWUgODkgYjcgMzQgMDIgZjUg MGEgNDggYmQgNDUgMWUgZGYgMDUgNjggNDIgZDIgNzggODkgYjcgMzQgMDIgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgMDAgMDAgMDIgODkgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDAg MDAgMDAgMDAgMDAgMDAgYjggYTQgOGQgOWQgZGEgMWQgN2UgNzggMTYgZWQgYWQgZWQgMDggODYg ZTEgNTkgMDAgMjAgYjYgZjYgNzkgMjIgM2MgZDUgY2UgMGIgOWEgZDkgODcgNWEgMTkgMTEgOGIg MmYgODkgMjkgYTggYzUgZTYgNmYgMmUgM2UgMjYgOGYgNzIgZWYgMzIgNjggOTggYzjCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgpXUEE6IFJYIG1l c3NhZ2UgMSBvZiBHcm91cCBLZXkgSGFuZHNoYWtlIGZyb20gMDA6MTc6OWE6ZjA6YjY6ODIgKHZl cj0xKcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5TdGF0ZTogR1JP VVBfSEFORFNIQUtFIC0mZ3Q7IEdST1VQX0hBTkRTSEFLRcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIDxicj5XUEE6IEdyb3VwIEtleSAtIGhleGR1bXAobGVuPTMyKTog NzYgNWEgMjkgMWIgYzIgMWIgODMgZjYgNjYgN2IgYWIgMTEgNjkgZGYgZDAgZDQgNGEgYWIgNmYg YjYgMzcgNmEgZjIgYzQgMGMgOGEgNTIgOGIgMTcgODYgOGEgOTfCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+CldQQTogSW5zdGFsbGluZyBHVEsgdG8g dGhlIGRyaXZlciAoa2V5aWR4PTMgdHg9MCBsZW49MzIpLsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+V1BBOiBSU0Mg LSBoZXhkdW1wKGxlbj02KTogODkgMDAgMDAgMDAgMDAgMDDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoCA8YnI+d3BhX2RyaXZlcl9ic2Rfc2V0X2tleTogYWxnPVRLSVAgYWRkcj1m ZjpmZjpmZjpmZjpmZjpmZiBrZXlfaWR4PTMgc2V0X3R4PTAgc2VxX2xlbj02IGtleV9sZW49MzLC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IDxicj4KV1BBOiBTZW5kaW5nIEVBUE9MLUtleSAyLzLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+V1BBOiBU WCBFQVBPTC1LZXkgLSBoZXhkdW1wKGxlbj05OSk6IDAxIDAzIDAwIDVmIGZlIDAzIDMxIDAwIDIw IDAwIDAwIDAwIDAwIDAwIDAwIDE4IDdjIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIGZmIDM1IDM4IDZj IGEwIDViIDdmIDFhIDEzIGQ1IDE0IGVmIDg4IDljIDZmIDBiIDAwIDAwwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj4KV1BBOiBL ZXkgbmVnb3RpYXRpb24gY29tcGxldGVkIHdpdGggMDA6MTc6OWE6ZjA6YjY6ODIgW1BUSz1US0lQ IEdUSz1US0lQXcKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPkNhbmNlbGxp bmcgYXV0aGVudGljYXRpb24gdGltZW91dMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+U3RhdGU6IEdST1VQX0hBTkRTSEFLRSAtJmd0 OyBDT01QTEVURUTCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCA8YnI+CkNUUkwtRVZFTlQtQ09OTkVDVEVEIC0gQ29ubmVjdGlvbiB0byAwMDoxNzo5 YTpmMDpiNjo4MiBjb21wbGV0ZWQgKGF1dGgpIFtpZD0wIGlkX3N0cj1dwqDCoMKgwqAgPGJyPlJY IEVBUE9MIGZyb20gMDA6MTc6OWE6ZjA6YjY6ODLCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5SWCBFQVBPTCAtIGhleGR1bXAo bGVuPTEzMSk6IDAxIDAzIDAwIDdmIGZlIDAzIDkxIDAwIDIwIDAwIDAwIDAwIDAwIDAwIDAwIDE4 IDdkIDYxIDNkIDAyIDU4IDgzIDUzIDhiIDJkIGNkIDBiIGVjIDk4IDQwIGFhIDUyIDk3IDc3IDZh IDJiIDMzIDY1IGE5IGY2IDNlIDdhIDFlIGE5IDIxIGIwIGE5IDk4IDEwIDc3IDZhIDJiIDMzIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAyIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIGM3IDU3IDMwIGM3IDYzIDg1IDg5IDFjIDQ4IDg3IDNj IDRiIDQ0IDZkIDk1IGQ2IDAwIDIwIDBiIDljIDY3IDllIGE3IDA0IDdmIDNlIDE3IDRiIGM1IDJi IGFlIGNlIGM5IGZiIDViIGFkIDBjIDE1IGIxIGI1IDFjIGMxIDI5IDc5IDg5IDM2IDM3IDdhIDg5 IGM1wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIDxicj4KSUVFRSA4MDIuMVggUlg6IHZlcnNpb249MSB0eXBlPTMgbGVuZ3Ro PTEyN8KgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPsKgIEVBUE9MLUtl eSB0eXBlPTI1NMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj7CoCBrZXlfaW5mbyAweDM5 MSAodmVyPTEga2V5aWR4PTEgcnN2ZD0wIEdyb3VwIEFjayBNSUMgU2VjdXJlKcKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPgrCoCBr ZXlfbGVuZ3RoPTMyIGtleV9kYXRhX2xlbmd0aD0zMsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJyPsKgIHJlcGxheV9jb3VudGVyIC0gaGV4 ZHVtcChsZW49OCk6IDAwIDAwIDAwIDAwIDAwIDAwIDE4IDdkwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAga2V5X25v bmNlIC0gaGV4ZHVtcChsZW49MzIpOiA2MSAzZCAwMiA1OCA4MyA1MyA4YiAyZCBjZCAwYiBlYyA5 OCA0MCBhYSA1MiA5NyA3NyA2YSAyYiAzMyA2NSBhOSBmNiAzZSA3YSAxZSBhOSAyMSBiMCBhOSA5 OCAxMMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IDxicj4KwqAga2V5X2l2IC0gaGV4ZHVtcChsZW49MTYpOiA3NyA2YSAyYiAzMyAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8 YnI+wqAga2V5X3JzYyAtIGhleGR1bXAobGVuPTgpOiAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+wqAga2V5X2lkIChyZXNlcnZlZCkgLSBoZXhkdW1wKGxl bj04KTogMDAgMDAgMDAgMDAgMDAgMDAgMDAgMDDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj4KwqAga2V5X21pYyAtIGhleGR1bXAo bGVuPTE2KTogYzcgNTcgMzAgYzcgNjMgODUgODkgMWMgNDggODcgM2MgNGIgNDQgNmQgOTUgZDbC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxicj5XUEE6IFJYIEVBUE9MLUtleSAtIGhleGR1 bXAobGVuPTEzMSk6IDAxIDAzIDAwIDdmIGZlIDAzIDkxIDAwIDIwIDAwIDAwIDAwIDAwIDAwIDAw IDE4IDdkIDYxIDNkIDAyIDU4IDgzIDUzIDhiIDJkIGNkIDBiIGVjIDk4IDQwIGFhIDUyIDk3IDc3 IDZhIDJiIDMzIDY1IGE5IGY2IDNlIDdhIDFlIGE5IDIxIGIwIGE5IDk4IDEwIDc3IDZhIDJiIDMz IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAyIDAwIDAwIDAwIDAwIDAwIDAwIDAw IDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIGM3IDU3IDMwIGM3IDYzIDg1IDg5IDFjIDQ4IDg3 IDNjIDRiIDQ0IDZkIDk1IGQ2IDAwIDIwIDBiIDljIDY3IDllIGE3IDA0IDdmIDNlIDE3IDRiIGM1 IDJiIGFlIGNlIGM5IGZiIDViIGFkIDBjIDE1IGIxIGI1IDFjIGMxIDI5IDc5IDg5IDM2IDM3IDdh IDg5IGM1wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDxi cj4KV1BBOiBSWCBtZXNzYWdlIDEgb2YgR3JvdXAgS2V5IEhhbmRzaGFrZSBmcm9tIDAwOjE3Ojlh OmYwOmI2OjgyICh2ZXI9MSnCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8 YnI+U3RhdGU6IENPTVBMRVRFRCAtJmd0OyBHUk9VUF9IQU5EU0hBS0XCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCA8YnI+V1BBOiBHcm91cCBLZXkg LSBoZXhkdW1wKGxlbj0zMik6IGQ1IGFjIDljIDI3IDE4IDY0IGFhIGRkIGY2IDA4IDhjIDdkIGU1 IDFmIDcxIGQ4IGY3IDljIDgzIDkxIDNhIDJkIGJmIGI3IGJkIGNhIGUyIDYzIDNhIGNkIDdiIDY2 PGJyPgpXUEE6IEluc3RhbGxpbmcgR1RLIHRvIHRoZSBkcml2ZXIgKGtleWlkeD0xIHR4PTAgbGVu PTMyKS48YnI+V1BBOiBSU0MgLSBoZXhkdW1wKGxlbj02KTogMDAgMDAgMDAgMDAgMDAgMDA8YnI+ d3BhX2RyaXZlcl9ic2Rfc2V0X2tleTogYWxnPVRLSVAgYWRkcj1mZjpmZjpmZjpmZjpmZjpmZiBr ZXlfaWR4PTEgc2V0X3R4PTAgc2VxX2xlbj02IGtleV9sZW49MzI8YnI+V1BBOiBTZW5kaW5nIEVB UE9MLUtleSAyLzI8YnI+CldQQTogVFggRUFQT0wtS2V5IC0gaGV4ZHVtcChsZW49OTkpOiAwMSAw MyAwMCA1ZiBmZSAwMyAxMSAwMCAyMCAwMCAwMCAwMCAwMCAwMCAwMCAxOCA3ZCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAwMCAw MCAwMCAwMCAwMCA2ZCA1YyA4YiAyZSBhMSA4MCAyMiAyZCBlYyBkOSBiYiAzOSBiNSAzZCA4NiBi NiAwMCAwMDxicj4KV1BBOiBHcm91cCByZWtleWluZyBjb21wbGV0ZWQgd2l0aCAwMDoxNzo5YTpm MDpiNjo4MiBbR1RLPVRLSVBdPGJyPkNhbmNlbGxpbmcgYXV0aGVudGljYXRpb24gdGltZW91dDxi cj5TdGF0ZTogR1JPVVBfSEFORFNIQUtFIC0mZ3Q7IENPTVBMRVRFRDxicj5eQ0NUUkwtRVZFTlQt VEVSTUlOQVRJTkcgLSBzaWduYWwgMiByZWNlaXZlZDxicj5SZW1vdmluZyBpbnRlcmZhY2Ugd2xh bjA8YnI+ClN0YXRlOiBDT01QTEVURUQgLSZndDsgRElTQ09OTkVDVEVEPGJyPndwYV9kcml2ZXJf YnNkX2RlYXV0aGVudGljYXRlPGJyPndwYV9kcml2ZXJfYnNkX2RlbF9rZXk6IGtleWlkeD0wPGJy PndwYV9kcml2ZXJfYnNkX2RlbF9rZXk6IGtleWlkeD0xPGJyPndwYV9kcml2ZXJfYnNkX2RlbF9r ZXk6IGtleWlkeD0yPGJyPndwYV9kcml2ZXJfYnNkX2RlbF9rZXk6IGtleWlkeD0zPGJyPndwYV9k cml2ZXJfYnNkX2RlbF9rZXk6IGFkZHI9MDA6MTc6OWE6ZjA6YjY6ODIga2V5aWR4PTA8YnI+Cmlv Y3RsW1NJT0NTODAyMTEsIG9wIDIwLCBsZW4gN106IENhbiYjMzk7dCBhc3NpZ24gcmVxdWVzdGVk IGFkZHJlc3M8YnI+d3BhX2RyaXZlcl9ic2Rfc2V0X3dwYTogZW5hYmxlZD0wPGJyPndwYV9kcml2 ZXJfYnNkX3NldF93cGFfaW50ZXJuYWw6IHdwYT0wIHByaXZhY3k9MDxicj5pb2N0bFtTSU9DUzgw MjExLCBvcCAyNiwgYXJnIDB4MF06IE9wZXJhdGlvbiBub3Qgc3VwcG9ydGVkPGJyPgpGYWlsZWQg dG8gZGlzYWJsZSBXUEEgaW4gdGhlIGRyaXZlci48YnI+d3BhX2RyaXZlcl9ic2Rfc2V0X2Ryb3Bf dW5lbmNyeXB0ZWQ6IGVuYWJsZWQ9MDxicj53cGFfZHJpdmVyX2JzZF9zZXRfY291bnRlcm1lYXN1 cmVzOiBlbmFibGVkPTA8YnI+Tm8ga2V5cyBoYXZlIGJlZW4gY29uZmlndXJlZCAtIHNraXAga2V5 IGNsZWFyaW5nPGJyPkNhbmNlbGxpbmcgc2NhbiByZXF1ZXN0PGJyPkNhbmNlbGxpbmcgYXV0aGVu dGljYXRpb24gdGltZW91dDxicj4Kd3BhX2RyaXZlcl9ic2Rfc2V0X3dwYV9pbnRlcm5hbDogd3Bh PTEgcHJpdmFjeT0wPGJyPkVMT09QOiByZW1haW5pbmcgc29ja2V0OiBzb2NrPTQgZWxvb3BfZGF0 YT0weDI4MzA1MTQwIHVzZXJfZGF0YT0weDI4MzBkMDQwIGhhbmRsZXI9MHg4MDY3YWEwPGJyPjxi cj48YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj4yMDA5LzgvMzAgU2FtIExlZmZsZXIg PHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86c2FtQGVycm5vLmNvbSI+c2FtQGVy cm5vLmNvbTwvYT4mZ3Q7PC9zcGFuPjxicj4KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdp bjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+WW91IGFwcGVhciB0byBz YXkgdGhpcyBwcm9ibGVtIGRvZXMgbm90IGVudGlyZWx5IHN0b3AgdHJhZmZpYyBmcm9tIGZsb3dp bmcuIMKgUGxlYXNlIHByb3ZpZGUgYSBkZWJ1ZyB3cGFfc3VwcGxpY2FudCBsb2cgdGhhdCBzaG93 cyBhIGNvbXBsZXRlIHNlc3Npb24gKGkuZS4gYSBsb2cgd2l0aCAtZCBhbmQvb3IgLWRkKS48YnI+ Cgo8YnI+CldoeSBkbyB5b3Ugc2V0IGVhcG9sX3ZlcnNpb249MS4gwqBJcyB0aGlzIHJlYWxseSBu ZWVkZWQ/IMKgV2hhdCBpcyB5b3VyIEFQIG1ha2UvbW9kZWw/PGJyPgo8YnI+Ck5vdGUgYWxzbyB0 aGF0IGNvdW50cnk9UlUgaXMgaWdub3JlZCBvbiBmcmVlYnNkLjxicj48Zm9udCBjb2xvcj0iIzg4 ODg4OCI+Cjxicj4KIMKgIMKgIMKgIMKgU2FtPGJyPgo8L2ZvbnQ+PC9ibG9ja3F1b3RlPjwvZGl2 Pjxicj4K --0014852f5780d7c3810472602664-- From owner-freebsd-net@FreeBSD.ORG Sun Aug 30 19:03:52 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 E1DF6106568F; Sun, 30 Aug 2009 19:03:52 +0000 (UTC) (envelope-from sam@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BA1818FC0C; Sun, 30 Aug 2009 19:03:52 +0000 (UTC) Received: from freefall.freebsd.org (sam@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7UJ3q8S039741; Sun, 30 Aug 2009 19:03:52 GMT (envelope-from sam@freefall.freebsd.org) Received: (from sam@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7UJ3qMB039737; Sun, 30 Aug 2009 19:03:52 GMT (envelope-from sam) Date: Sun, 30 Aug 2009 19:03:52 GMT Message-Id: <200908301903.n7UJ3qMB039737@freefall.freebsd.org> To: sam@FreeBSD.org, freebsd-net@FreeBSD.org, sam@FreeBSD.org From: sam@FreeBSD.org Cc: Subject: Re: bin/138331: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Aug 2009 19:03:53 -0000 Synopsis: FreeBSD 8.0-beta3 wpa_supplicant(8) lost auth Responsible-Changed-From-To: freebsd-net->sam Responsible-Changed-By: sam Responsible-Changed-When: Sun Aug 30 19:03:26 UTC 2009 Responsible-Changed-Why: I'll handle this http://www.freebsd.org/cgi/query-pr.cgi?pr=138331 From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 01:05: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 894B31065676 for ; Mon, 31 Aug 2009 01:05:10 +0000 (UTC) (envelope-from sinister@gmail.com) Received: from mail-gx0-f227.google.com (mail-gx0-f227.google.com [209.85.217.227]) by mx1.freebsd.org (Postfix) with ESMTP id 39F748FC0A for ; Mon, 31 Aug 2009 01:05:09 +0000 (UTC) Received: by gxk27 with SMTP id 27so4740843gxk.12 for ; Sun, 30 Aug 2009 18:05:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:subject :date:mime-version:content-type:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=RUBYx1HxMKzyNee206nmuLOPYrh4GTYydm2tSijb8/Y=; b=a4tikBbQWnHBRmGYeji6wgo7dwN+0/5U8wLF4QvXwIES1xQz8SQQjEDHe5r+TJRoKT +M5gh+I7UdPp3Y20xoWjRMAHGh2s48dgKls+2fGCkpKx3IO8epAEMenrgRt86FzWYcCk A4VP9xEkW0G2aDKHi2ayNK8KlJfT3BzoPfpAQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:mime-version:content-type :x-priority:x-msmail-priority:x-mailer:x-mimeole; b=Uvz3lktyJLzeisD10Xyp3B0lYllgYlIEbE76yhLk6SbMMUQaZgwInjpQUhYusGQG/8 RaxU0jSBNRQgLrvvlfkUSq3+M7nVJnn4hAyrRgaWcx+YeJSVvyQE6Atlf9Nqvk9K2t1i oD2IPw4Uvt7Yr7UisTqRJ7yZcX4Rez8Xhi+IE= Received: by 10.90.127.20 with SMTP id z20mr3502554agc.118.1251679083901; Sun, 30 Aug 2009 17:38:03 -0700 (PDT) Received: from dts (markofthebeast.ca [216.8.139.47]) by mx.google.com with ESMTPS id 34sm3079484agc.31.2009.08.30.17.38.01 (version=SSLv3 cipher=RC4-MD5); Sun, 30 Aug 2009 17:38:02 -0700 (PDT) Message-ID: From: Sin To: Date: Sun, 30 Aug 2009 20:38:13 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ath0 unable to DHCP as part of a bridge 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, 31 Aug 2009 01:05:10 -0000 Hello, I'm using FreeBSD 7-STABLE. I have 6 NICs as a bridged interface, one = of which is a ath0 wireless NIC. I don't understand if this acting the = way it should. If I try to dhclient on interfact ath0 I'll get the = request no problems. But if I dhclient to bridge0 interface, it acts = like there's no server - Even though its bridged. Also note if I = connect a cable to any of the wired NICs, dhclient will then work on = bridge0 interface. The setup is kinda complicated, but i'm hoping someone may have a = different view on it. One thing that confused me is that the line in = /etc/rc.conf ifconfig_ath0=3D"WPA" - it does not matter if this line is = before or after the bridge declaration.=20 Compiled into the kernel: options NETGRAPH options NETGRAPH_L2TP options NETGRAPH_PPP options NETGRAPH_PPPOE options NETGRAPH_PPTPGRE options NETGRAPH_MPPC_ENCRYPTION options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT options IPFIREWALL_DEFAULT_TO_ACCEPT device if_bridge #Bridge interface device gre #IP over IP tunneling FreeBSD domainname 7.2-STABLE FreeBSD 7.2-STABLE #0: Sat Aug 29 05:39:09 = EDT 2009 root@domainname:/tmp/CVS/src/sys/i386/compile/TESTROUTER = i386 test# kldstat Id Refs Address Size Name 1 3 0xc0400000 556810 kernel 2 1 0xc0957000 6a49c acpi.ko test# ifconfig -a sk0: flags=3D8943 metric = 0 mtu 1500 options=3D8 ether 00:0f:3d:88:18:31 media: Ethernet autoselect (none) status: no carrier vr0: flags=3D8943 metric = 0 mtu 1500 options=3D2808 ether 00:05:5d:75:1a:12 media: Ethernet autoselect (none) status: no carrier vr1: flags=3D8943 metric = 0 mtu 1500 options=3D2808 ether 00:05:5d:e9:61:79 media: Ethernet autoselect (none) status: no carrier ath0: flags=3D8943 = metric 0 mtu 1500 ether 00:17:9a:4c:e7:83 inet 192.168.0.251 netmask 0xffffff00 broadcast 192.168.0.255 media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/48Mbps) status: associated ssid dts channel 2 (2417 Mhz 11g) bssid 00:17:9a:9e:f3:82 authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP = 3:128-bit txpower 31.5 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS burst roaming MANUAL bintval 30 sk1: flags=3D8943 metric = 0 mtu 1500 options=3D8 ether 00:11:95:d7:25:e3 media: Ethernet autoselect (none) status: no carrier sk2: flags=3D8943 metric = 0 mtu 1500 options=3D8 ether 00:11:95:d7:25:ee media: Ethernet autoselect (none) status: no carrier lo0: flags=3D8049 metric 0 mtu 16384 inet 127.0.0.1 netmask 0xff000000 bridge0: flags=3D8843 metric 0 = mtu 1500 ether 96:25:58:f9:dd:3d 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: vr1 flags=3D143 ifmaxaddr 0 port 3 priority 128 path cost 55 member: vr0 flags=3D143 ifmaxaddr 0 port 2 priority 128 path cost 55 member: sk2 flags=3D143 ifmaxaddr 0 port 6 priority 128 path cost 55 member: sk1 flags=3D143 ifmaxaddr 0 port 5 priority 128 path cost 55 member: sk0 flags=3D143 ifmaxaddr 0 port 1 priority 128 path cost 55 member: ath0 flags=3D143 ifmaxaddr 0 port 4 priority 128 path cost 76923 - 7.1-RELEASE upgrade to stable without mergemaster - world and kenel built from this supfile: test# cat /tmp/CVS/supfile *default tag=3DRELENG_7 *default host=3Dcvsup1.ca.FreeBSD.org *default prefix=3D/tmp/CVS *default base=3D/var/db *default release=3Dcvs delete use-rel-suffix compress src-all example of the exact issue as found in the command line: test# dhclient bridge0 DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 5 DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 10 DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 14 DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 21 DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 7 No DHCPOFFERS received. No working leases in persistent database - sleeping. test# dhclient ath0 DHCPREQUEST on ath0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.1 bound to 192.168.0.177 -- renewal in 43200 seconds. From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 01:17:56 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 CFCC0106566B for ; Mon, 31 Aug 2009 01:17:56 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id 97BE98FC0A for ; Mon, 31 Aug 2009 01:17:56 +0000 (UTC) Received: (qmail 75190 invoked from network); 31 Aug 2009 01:17:54 -0000 Received: from unknown (HELO ?192.168.0.2?) (spawk@69.123.45.64) by acm.poly.edu with AES256-SHA encrypted SMTP; 31 Aug 2009 01:17:54 -0000 Message-ID: <4A9B249D.1050104@acm.poly.edu> Date: Sun, 30 Aug 2009 21:17:17 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.19 (X11/20090108) MIME-Version: 1.0 To: Sin References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: ath0 unable to DHCP as part of a bridge 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, 31 Aug 2009 01:17:56 -0000 Sin wrote: > Hello, > > > I'm using FreeBSD 7-STABLE. I have 6 NICs as a bridged interface, one of which is a ath0 wireless NIC. I don't understand if this acting the way it should. If I try to dhclient on interfact ath0 I'll get the request no problems. But if I dhclient to bridge0 interface, it acts like there's no server - Even though its bridged. Also note if I connect a cable to any of the wired NICs, dhclient will then work on bridge0 interface. > > The setup is kinda complicated, but i'm hoping someone may have a different view on it. One thing that confused me is that the line in /etc/rc.conf ifconfig_ath0="WPA" - it does not matter if this line is before or after the bridge declaration. > > > Compiled into the kernel: > > > options NETGRAPH > options NETGRAPH_L2TP > options NETGRAPH_PPP > options NETGRAPH_PPPOE > options NETGRAPH_PPTPGRE > options NETGRAPH_MPPC_ENCRYPTION > > options IPFIREWALL > options IPFIREWALL_VERBOSE > options IPFIREWALL_VERBOSE_LIMIT > options IPFIREWALL_DEFAULT_TO_ACCEPT > > device if_bridge #Bridge interface > device gre #IP over IP tunneling > > > > > FreeBSD domainname 7.2-STABLE FreeBSD 7.2-STABLE #0: Sat Aug 29 05:39:09 EDT 2009 root@domainname:/tmp/CVS/src/sys/i386/compile/TESTROUTER i386 > > > test# kldstat > Id Refs Address Size Name > 1 3 0xc0400000 556810 kernel > 2 1 0xc0957000 6a49c acpi.ko > > > test# ifconfig -a > sk0: flags=8943 metric 0 mtu 1500 > options=8 > ether 00:0f:3d:88:18:31 > media: Ethernet autoselect (none) > status: no carrier > vr0: flags=8943 metric 0 mtu 1500 > options=2808 > ether 00:05:5d:75:1a:12 > media: Ethernet autoselect (none) > status: no carrier > vr1: flags=8943 metric 0 mtu 1500 > options=2808 > ether 00:05:5d:e9:61:79 > media: Ethernet autoselect (none) > status: no carrier > ath0: flags=8943 metric 0 mtu 1500 > ether 00:17:9a:4c:e7:83 > inet 192.168.0.251 netmask 0xffffff00 broadcast 192.168.0.255 > media: IEEE 802.11 Wireless Ethernet autoselect (OFDM/48Mbps) > status: associated > ssid dts channel 2 (2417 Mhz 11g) bssid 00:17:9a:9e:f3:82 > authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit > txpower 31.5 bmiss 7 scanvalid 60 bgscan bgscanintvl 300 > bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS burst > roaming MANUAL bintval 30 > sk1: flags=8943 metric 0 mtu 1500 > options=8 > ether 00:11:95:d7:25:e3 > media: Ethernet autoselect (none) > status: no carrier > sk2: flags=8943 metric 0 mtu 1500 > options=8 > ether 00:11:95:d7:25:ee > media: Ethernet autoselect (none) > status: no carrier > lo0: flags=8049 metric 0 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > bridge0: flags=8843 metric 0 mtu 1500 > ether 96:25:58:f9:dd:3d > 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: vr1 flags=143 > ifmaxaddr 0 port 3 priority 128 path cost 55 > member: vr0 flags=143 > ifmaxaddr 0 port 2 priority 128 path cost 55 > member: sk2 flags=143 > ifmaxaddr 0 port 6 priority 128 path cost 55 > member: sk1 flags=143 > ifmaxaddr 0 port 5 priority 128 path cost 55 > member: sk0 flags=143 > ifmaxaddr 0 port 1 priority 128 path cost 55 > member: ath0 flags=143 > ifmaxaddr 0 port 4 priority 128 path cost 76923 > > > - 7.1-RELEASE upgrade to stable without mergemaster > - world and kenel built from this supfile: > > test# cat /tmp/CVS/supfile > *default tag=RELENG_7 > *default host=cvsup1.ca.FreeBSD.org > *default prefix=/tmp/CVS > *default base=/var/db > *default release=cvs delete use-rel-suffix compress > > src-all > > > > > example of the exact issue as found in the command line: > > test# dhclient bridge0 > DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 4 > DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 5 > DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 10 > DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 14 > DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 21 > DHCPDISCOVER on bridge0 to 255.255.255.255 port 67 interval 7 > No DHCPOFFERS received. > No working leases in persistent database - sleeping. > > test# dhclient ath0 > DHCPREQUEST on ath0 to 255.255.255.255 port 67 > DHCPACK from 192.168.0.1 > bound to 192.168.0.177 -- renewal in 43200 seconds. > > _______________________________________________ > 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" > I think you are hitting the limitation described at the bottom of the if_bridge(4) man page: Only wireless interfaces in hostap mode can be bridged due to the 802.11 framing format, bridging a wireless client is not supported yet. -Boris From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 04:10:07 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 92FD71065672 for ; Mon, 31 Aug 2009 04:10:07 +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 8284D8FC15 for ; Mon, 31 Aug 2009 04:10:07 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7V4A7WD005350 for ; Mon, 31 Aug 2009 04:10:07 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7V4A7qS005349; Mon, 31 Aug 2009 04:10:07 GMT (envelope-from gnats) Date: Mon, 31 Aug 2009 04:10:07 GMT Message-Id: <200908310410.n7V4A7qS005349@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Paul Cc: Subject: Re: kern/122780: [lagg] tcpdump on lagg interface during high pps wedges netcode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 04:10:07 -0000 The following reply was made to PR kern/122780; it has been noted by GNATS. From: Paul To: Ed Maste Cc: bug-followup@FreeBSD.org Subject: Re: kern/122780: [lagg] tcpdump on lagg interface during high pps wedges netcode Date: Sun, 30 Aug 2009 23:33:59 -0400 Yes next time I reboot one of the routers I can test it. Have you guys made any progress on SMP routing yet? Ed Maste wrote: > Can you retest on recent 7.x or HEAD? I think there have been BPF changes > to address this issue. > > -Ed > > -- GloboTech Communications Phone: 1-514-907-0050 x 215 Toll Free: 1-(888)-GTCOMM1 Fax: 1-(514)-907-0750 paul@gtcomm.net http://www.gtcomm.net From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 10:32:41 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 15405106566B; Mon, 31 Aug 2009 10:32:41 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DFB988FC0C; Mon, 31 Aug 2009 10:32:40 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7VAWe7m039966; Mon, 31 Aug 2009 10:32:40 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7VAWeDg039961; Mon, 31 Aug 2009 10:32:40 GMT (envelope-from linimon) Date: Mon, 31 Aug 2009 10:32:40 GMT Message-Id: <200908311032.n7VAWeDg039961@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/138378: [altq] [patch] Memory leak in hfsc_class_modify() in file sys/contrib/altq/altq/altq_hfsc.c 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, 31 Aug 2009 10:32:41 -0000 Old Synopsis: Memory leak in hfsc_class_modify() in file sys/contrib/altq/altq/altq_hfsc.c New Synopsis: [altq] [patch] Memory leak in hfsc_class_modify() in file sys/contrib/altq/altq/altq_hfsc.c Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 31 10:32:03 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138378 From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 11:07: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 314E81065697 for ; Mon, 31 Aug 2009 11:07:12 +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 1EDCA8FC22 for ; Mon, 31 Aug 2009 11:07:12 +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 n7VB7CEu070651 for ; Mon, 31 Aug 2009 11:07:12 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7VB7Bx8070647 for freebsd-net@FreeBSD.org; Mon, 31 Aug 2009 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 31 Aug 2009 11:07:11 GMT Message-Id: <200908311107.n7VB7Bx8070647@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, 31 Aug 2009 11:07:12 -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/138378 net [altq] [patch] Memory leak in hfsc_class_modify() in f o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR on 8.0-BE o kern/138292 net [zyd] [usb8] "zyd0: device timeout" with ZyXEL G-202 o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138130 net [netinet] [patch] Resource leak in LibAliasRefreshModu 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 o 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/137170 net [ath] atheros AR9285 not recognised 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/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/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 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/132625 net [iwn] iwn drivers don't support setting country 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 conf/132179 net [patch] /etc/network.subr: ipv6 rtsol on incorrect wla 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/128598 net [bluetooth] WARNING: attempt to net_add_domain(bluetoo o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o 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/126924 net [an] [patch] printf -> device_printf and simplify prob o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o bin/126822 net wpa_supplicant(8): WPA PSK does not work in adhoc mode o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and 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 [multicast] 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 f kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122195 net [ed] Alignment problems in if_ed o kern/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/116328 net [bge]: Solid hang with bge interface 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/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] if_sis short cable fix problems with NetGear FA3 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 331 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 11:58:18 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 EF7EE1065672; Mon, 31 Aug 2009 11:58:18 +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 C726C8FC18; Mon, 31 Aug 2009 11:58:18 +0000 (UTC) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7VBwIbF026902; Mon, 31 Aug 2009 11:58:18 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7VBwIEt026898; Mon, 31 Aug 2009 11:58:18 GMT (envelope-from gavin) Date: Mon, 31 Aug 2009 11:58:18 GMT Message-Id: <200908311158.n7VBwIEt026898@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-usb@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/113432: [ucom] WARNING: attempt to net_add_domain(netgraph) after domainfinalize() 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, 31 Aug 2009 11:58:19 -0000 Synopsis: [ucom] WARNING: attempt to net_add_domain(netgraph) after domainfinalize() Responsible-Changed-From-To: freebsd-usb->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Mon Aug 31 11:55:54 UTC 2009 Responsible-Changed-Why: I believe this is more likely to be a problem at the netgraph level rather than USB. http://www.freebsd.org/cgi/query-pr.cgi?pr=113432 From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 14:22: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 6C7531065670; Mon, 31 Aug 2009 14:22:27 +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 4325F8FC19; Mon, 31 Aug 2009 14:22:27 +0000 (UTC) Received: from freefall.freebsd.org (gavin@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7VEMRHt076691; Mon, 31 Aug 2009 14:22:27 GMT (envelope-from gavin@freefall.freebsd.org) Received: (from gavin@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7VEMREW076687; Mon, 31 Aug 2009 14:22:27 GMT (envelope-from gavin) Date: Mon, 31 Aug 2009 14:22:27 GMT Message-Id: <200908311422.n7VEMREW076687@freefall.freebsd.org> To: gavin@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: gavin@FreeBSD.org Cc: Subject: Re: kern/138390: [gif] [patch] NULL pointer dereference in gif_input() in file sys/net/if_gif.c 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, 31 Aug 2009 14:22:27 -0000 Old Synopsis: NULL pointer dereference in gif_input() in file sys/net/if_gif.c New Synopsis: [gif] [patch] NULL pointer dereference in gif_input() in file sys/net/if_gif.c Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: gavin Responsible-Changed-When: Mon Aug 31 14:20:26 UTC 2009 Responsible-Changed-Why: Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=138390 From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 17:01: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 875C51065694 for ; Mon, 31 Aug 2009 17:01:39 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [74.82.45.72]) by mx1.freebsd.org (Postfix) with ESMTP id 770588FC21 for ; Mon, 31 Aug 2009 17:01:39 +0000 (UTC) Resent-Message-Id: From: Stef Walter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "freebsd-net@FreeBSD.org" Content-Type: multipart/mixed; boundary="------------020109080001040507040400" X-Virus-Scanned: ClamAV using ClamSMTP Resent-Date: Mon, 31 Aug 2009 17:01:39 +0000 (UTC) Resent-From: stef-list@memberwebs.com Subject: [patch] Unbreak setfib + routing daemons X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Mon, 31 Aug 2009 17:01:39 -0000 X-List-Received-Date: Mon, 31 Aug 2009 17:01:39 -0000 This is a multi-part message in MIME format. --------------020109080001040507040400 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Currently route messages are sent to all listeners of PF_ROUTE, regardless or which FIB the listener socket was started on. The upshot of this is that one can't really use routing daemons together with multiple FIBs. The routing daemon sees the messages from the alternate FIBs and rapidly gets confused. In the future, someone might decide to expose FIB numbers in the route messages themselves. This could allow routing daemons to filter them out. Such a solution might be appropriate for FreeBSD 9.x and later, as it would likely break API and ABI. In any case, I'm not really qualified to argue the merits/problems of such an approach, and coding it is beyond my abilities... Attached is a patch which fixes this problem in a simple way. It limits route messages to listening PF_ROUTE sockets on the same FIB that the route message was for. It compiles and works on 7.1+ and 8.0 and CURRENT. FreeBSD PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134931 How can I help this get into FreeBSD? It would be awesome if this fix or one like it made it in before the 8.0 release. Cheers, Stef --------------020109080001040507040400 Content-Type: text/x-diff; name="freebsd-route-messages-respect-fib.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-route-messages-respect-fib.patch" --- sys/net/rtsock.c.orig 2009-08-31 15:26:03.000000000 +0000 +++ sys/net/rtsock.c 2009-08-31 16:07:06.000000000 +0000 @@ -777,4 +777,5 @@ } if (m) { + M_SETFIB(m, so->so_fibnum); if (rp) { /* --- sys/net/raw_usrreq.c.orig 2009-08-31 16:04:58.000000000 +0000 +++ sys/net/raw_usrreq.c 2009-08-31 16:05:11.000000000 +0000 @@ -84,4 +84,7 @@ rp->rcb_proto.sp_protocol != proto->sp_protocol) continue; + if (proto->sp_family == PF_ROUTE && rp->rcb_socket && + M_GETFIB (m) != rp->rcb_socket->so_fibnum) + continue; if (last) { struct mbuf *n; --------------020109080001040507040400-- From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 17:20:08 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 9425F106568F for ; Mon, 31 Aug 2009 17:20:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 820DE8FC08 for ; Mon, 31 Aug 2009 17:20:08 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7VHK8no047214 for ; Mon, 31 Aug 2009 17:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7VHK8El047213; Mon, 31 Aug 2009 17:20:08 GMT (envelope-from gnats) Date: Mon, 31 Aug 2009 17:20:08 GMT Message-Id: <200908311720.n7VHK8El047213@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Stef Walter Cc: Subject: Re: kern/134931:[route] [fib] Route messages sent to all socket listeners regardless of setfib X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stef Walter List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 17:20:08 -0000 The following reply was made to PR kern/134931; it has been noted by GNATS. From: Stef Walter To: bug-followup@FreeBSD.org, count@211.ru Cc: Subject: Re: kern/134931:[route] [fib] Route messages sent to all socket listeners regardless of setfib Date: Mon, 31 Aug 09 17:20:06 UTC This is a multi-part message in MIME format. --------------030509050508050401080102 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As it currently stands, using routing daemons + multiple fibs in FreeBSD 7.x and 8.x is pretty much broken. Here's a patch which fixes the problem. I agree in principle with Mark that having future route messages might be able to let routing daemons differentiate between various fibs and manage them, and that this might be a feature.... However any implementation of that would likely break API and ABI, and very probably exist purely in FreeBSD 9.x. All the best, Stef --------------030509050508050401080102 Content-Type: text/x-diff; name="freebsd-route-messages-respect-fib.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-route-messages-respect-fib.patch" --- sys/net/rtsock.c.orig 2009-08-31 15:26:03.000000000 +0000 +++ sys/net/rtsock.c 2009-08-31 16:07:06.000000000 +0000 @@ -777,4 +777,5 @@ } if (m) { + M_SETFIB(m, so->so_fibnum); if (rp) { /* --- sys/net/raw_usrreq.c.orig 2009-08-31 16:04:58.000000000 +0000 +++ sys/net/raw_usrreq.c 2009-08-31 16:05:11.000000000 +0000 @@ -84,4 +84,7 @@ rp->rcb_proto.sp_protocol != proto->sp_protocol) continue; + if (proto->sp_family == PF_ROUTE && rp->rcb_socket && + M_GETFIB (m) != rp->rcb_socket->so_fibnum) + continue; if (last) { struct mbuf *n; --------------030509050508050401080102-- From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 17:26: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 41D5B106566B for ; Mon, 31 Aug 2009 17:26:37 +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 29FD78FC19 for ; Mon, 31 Aug 2009 17:26:37 +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 n7VHQa97026668; Mon, 31 Aug 2009 10:26:36 -0700 (PDT) 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: Mon, 31 Aug 2009 10:26:25 -0700 Message-ID: In-Reply-To: <200908311702.n7VH2iHI022732@whisker.bluecoat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [patch] Unbreak setfib + routing daemons Thread-Index: AcoqXN6bsmxAS2rpQVWl5P4YOT/BuQAAwFPA References: <200908311702.n7VH2iHI022732@whisker.bluecoat.com> From: "Li, Qing" To: , "freebsd-net@FreeBSD.org" Cc: Subject: RE: [patch] Unbreak setfib + routing daemons 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, 31 Aug 2009 17:26:37 -0000 Hi Stef, I am not sure if this patch is complete. There are other commands through the routing socket that can trigger routing messages. For example, issuing "ifconfig" to add and remove interface addresses. At the moment these types of routing messages do not have=20 a fib associated with them, which may need fixing. -- Qing > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd- > net@freebsd.org] On Behalf Of Stef Walter > Sent: Monday, August 31, 2009 10:03 AM > To: freebsd-net@FreeBSD.org > Subject: [patch] Unbreak setfib + routing daemons >=20 > Currently route messages are sent to all listeners of PF_ROUTE, > regardless or which FIB the listener socket was started on. >=20 > The upshot of this is that one can't really use routing daemons > together > with multiple FIBs. The routing daemon sees the messages from the > alternate FIBs and rapidly gets confused. >=20 > In the future, someone might decide to expose FIB numbers in the route > messages themselves. This could allow routing daemons to filter them > out. Such a solution might be appropriate for FreeBSD 9.x and later, as > it would likely break API and ABI. In any case, I'm not really > qualified > to argue the merits/problems of such an approach, and coding it is > beyond my abilities... >=20 > Attached is a patch which fixes this problem in a simple way. It limits > route messages to listening PF_ROUTE sockets on the same FIB that the > route message was for. It compiles and works on 7.1+ and 8.0 and > CURRENT. >=20 > FreeBSD PR: >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/134931 >=20 > How can I help this get into FreeBSD? It would be awesome if this fix > or > one like it made it in before the 8.0 release. >=20 > Cheers, >=20 > Stef From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 17:37: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 C73A7106566B; Mon, 31 Aug 2009 17:37:04 +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 9DEBF8FC0C; Mon, 31 Aug 2009 17:37:04 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7VHb4Qn068147; Mon, 31 Aug 2009 17:37:04 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7VHb4NC068143; Mon, 31 Aug 2009 17:37:04 GMT (envelope-from linimon) Date: Mon, 31 Aug 2009 17:37:04 GMT Message-Id: <200908311737.n7VHb4NC068143@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/138407: [gre] gre(4) interface does not come up after 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, 31 Aug 2009 17:37:04 -0000 Old Synopsis: gre(4) interface does not come up after reboot New Synopsis: [gre] gre(4) interface does not come up after reboot Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Aug 31 17:36:28 UTC 2009 Responsible-Changed-Why: Most likely a problem in the driver. http://www.freebsd.org/cgi/query-pr.cgi?pr=138407 From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 17:57: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 8E0531065672 for ; Mon, 31 Aug 2009 17:57:24 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 5E7EA8FC0A for ; Mon, 31 Aug 2009 17:57:24 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 82A975838B; Mon, 31 Aug 2009 13:57:23 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Mon, 31 Aug 2009 13:57:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=jY2eS3UKdJCpM0O6ldejiNQGMwQ=; b=GLRbPFymlJvZQyzGBDYOtlylLQmYEQVU7pnlsiwVqAYs2LD+MnffubyIUevy7EtTtZjLdrv9HP5k5lHRRAqAbPO5+cHB0U1kLiSFEfhFyHTTSjHxIrZD8c9O2oACTpclpN6rpuDhmNRJg/IAF7LfN4qg8XNOEmP9gB2rr7O83SA= X-Sasl-enc: rU/6RGRQa/n0Ooep+cA/6zDs9I5dtaF4FY7hKF6ev9zS 1251741443 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id E01E53EB72; Mon, 31 Aug 2009 13:57:22 -0400 (EDT) Message-ID: <4A9C0F00.7020208@incunabulum.net> Date: Mon, 31 Aug 2009 18:57:20 +0100 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Stef Walter References: <200908311720.n7VHK8El047213@freefall.freebsd.org> In-Reply-To: <200908311720.n7VHK8El047213@freefall.freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: kern/134931:[route] [fib] Route messages sent to all socket listeners regardless of setfib 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, 31 Aug 2009 17:57:24 -0000 Stef Walter wrote: > I agree in principle with Mark that having future route messages might > be able to let routing daemons differentiate between various fibs and > manage them, and that this might be a feature.... However any > implementation of that would likely break API and ABI, and very probably > exist purely in FreeBSD 9.x. > Surely a good time for someone to act on the suggestion that we implement the Netlink socket family? It is a Tag-Length-Value protocol, so it can easily adapt to new additions. It exists as an informational RFC, therefore it is not encumbered by the GPL; however it would need to be carefully implemented in FreeBSD. It's who dares wins -- I wouldn't object to doing it, but I'm committed to doing other stuff for the moment. From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 18:11: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 BB7BD106568B for ; Mon, 31 Aug 2009 18:11:24 +0000 (UTC) (envelope-from jhay@meraka.csir.co.za) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 115D98FC17 for ; Mon, 31 Aug 2009 18:11:24 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id 3B48039824; Mon, 31 Aug 2009 20:11:22 +0200 (SAST) Date: Mon, 31 Aug 2009 20:11:22 +0200 From: John Hay To: Stef Walter Message-ID: <20090831181122.GA18911@zibbi.meraka.csir.co.za> References: <200908311720.n7VHK8El047213@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200908311720.n7VHK8El047213@freefall.freebsd.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@FreeBSD.org Subject: Re: kern/134931:[route] [fib] Route messages sent to all socket listeners regardless of setfib 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, 31 Aug 2009 18:11:24 -0000 On Mon, Aug 31, 2009 at 05:20:08PM +0000, Stef Walter wrote: > The following reply was made to PR kern/134931; it has been noted by GNATS. > > From: Stef Walter > To: bug-followup@FreeBSD.org, count@211.ru > Cc: > Subject: Re: kern/134931:[route] [fib] Route messages sent to all socket listeners > regardless of setfib > Date: Mon, 31 Aug 09 17:20:06 UTC > > As it currently stands, using routing daemons + multiple fibs in FreeBSD > 7.x and 8.x is pretty much broken. Here's a patch which fixes the problem. This sounds good. Currently quagga gets really confused if route changes to another fib is made. For instance, if you add a default route to another fib, quagga will remove the default route from its fib. John -- John Hay -- jhay@meraka.csir.co.za / jhay@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 18:16:30 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 D4E8A106568F for ; Mon, 31 Aug 2009 18:16:30 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outB.internet-mail-service.net (outb.internet-mail-service.net [216.240.47.225]) by mx1.freebsd.org (Postfix) with ESMTP id BFADA8FC24 for ; Mon, 31 Aug 2009 18:16:30 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id C005BB9857; Mon, 31 Aug 2009 11:16:30 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 1E3FD2D6018; Mon, 31 Aug 2009 11:16:30 -0700 (PDT) Message-ID: <4A9C137C.7020303@elischer.org> Date: Mon, 31 Aug 2009 11:16:28 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: stef@memberwebs.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@FreeBSD.org" Subject: Re: [patch] Unbreak setfib + routing daemons 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, 31 Aug 2009 18:16:30 -0000 Stef Walter wrote: > Currently route messages are sent to all listeners of PF_ROUTE, > regardless or which FIB the listener socket was started on. > > The upshot of this is that one can't really use routing daemons together > with multiple FIBs. The routing daemon sees the messages from the > alternate FIBs and rapidly gets confused. > > In the future, someone might decide to expose FIB numbers in the route > messages themselves. This could allow routing daemons to filter them > out. Such a solution might be appropriate for FreeBSD 9.x and later, as > it would likely break API and ABI. In any case, I'm not really qualified > to argue the merits/problems of such an approach, and coding it is > beyond my abilities... > > Attached is a patch which fixes this problem in a simple way. It limits > route messages to listening PF_ROUTE sockets on the same FIB that the > route message was for. It compiles and works on 7.1+ and 8.0 and CURRENT. there are two ways to go with this one being what you have done teh other to add fib info to the messages, Apparently OpenBSD has implemented the second by re-using a disused field. (I'm ve only been told this second hand) I"ll look a tyour change and see what we can do. it might just make it to 8.1 at this stage but we can see what it looks like. > > FreeBSD PR: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/134931 how much have you tested this? > > How can I help this get into FreeBSD? It would be awesome if this fix or > one like it made it in before the 8.0 release. > > Cheers, > > Stef > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Aug 31 19:47:34 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 28E9B106566C for ; Mon, 31 Aug 2009 19:47:34 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [74.82.45.72]) by mx1.freebsd.org (Postfix) with ESMTP id 1C3D38FC24 for ; Mon, 31 Aug 2009 19:47:33 +0000 (UTC) Resent-Message-Id: From: Stef Walter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Julian Elischer References: <4A9C137C.7020303@elischer.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Resent-Date: Mon, 31 Aug 2009 19:47:34 +0000 (UTC) Resent-From: stef-list@memberwebs.com Cc: "freebsd-net@FreeBSD.org" Subject: Re: [patch] Unbreak setfib + routing daemons X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Mon, 31 Aug 2009 19:47:34 -0000 X-List-Received-Date: Mon, 31 Aug 2009 19:47:34 -0000 Julian Elischer wrote: > there are two ways to go with this one being what you have done teh > other to add fib info to the messages, Apparently > OpenBSD has implemented the second by re-using a disused field. > (I'm ve only been told this second hand) It seems like they've taken apart the rtm_flags field (int), and repurposed it as rtm_tableid (u_short), rtm_priority (u_char) and padding. Obviously such a change would require patches to the various routing daemons as well. But if you think this is the only way forward (ie: filtering the messages in userland), I'd be happy to contribute. > I"ll look a tyour change and see what we can do. > it might just make it to 8.1 at this stage but we can > see what it looks like. I've posted a new patch which should handle all the various senders of route messages better. Qing Li pointed out some naive assumptions I made in my initial patch. It's more complex because we can no longer use M_GETFIB and M_SETFIB to relay FIB information into the netisr routine. > how much have you tested this? I need this for some client systems that we're upgrading. I'll be putting it into production this week. If there's any problems with it, I'll let you and the mailing list know. Cheers, Stef From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 20:00:15 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 31DE8106566B for ; Mon, 31 Aug 2009 20:00:15 +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 1F7F48FC19 for ; Mon, 31 Aug 2009 20:00:15 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n7VK0EhS012792 for ; Mon, 31 Aug 2009 20:00:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n7VK0Eqj012791; Mon, 31 Aug 2009 20:00:14 GMT (envelope-from gnats) Date: Mon, 31 Aug 2009 20:00:14 GMT Message-Id: <200908312000.n7VK0Eqj012791@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Stef Walter Cc: Subject: Re: kern/134931 [patch] Unbreak setfib + routing daemons X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stef Walter List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Aug 2009 20:00:15 -0000 The following reply was made to PR kern/134931; it has been noted by GNATS. From: Stef Walter To: "Li, Qing" Cc: "freebsd-net@FreeBSD.org" , bug-followup@FreeBSD.org, julian@elischer.org Subject: Re: kern/134931 [patch] Unbreak setfib + routing daemons Date: Mon, 31 Aug 09 20:00:13 UTC This is a multi-part message in MIME format. --------------000601070001040803040904 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Li, Qing wrote: > There are other commands through the routing socket that > can trigger routing messages. For example, issuing "ifconfig" > to add and remove interface addresses. Thanks for taking a look at this and catching that problem. Here's a new patch which does the following: * Both rt_dispatch and raw_input accept an fib, or -1 (for any fib). * Pases the fib along in the context to the netisr routine that actually dispatches route messages. * As you noted, some senders of route messages don't have the context necessary to know what fib a message would belong to. Where possible we pass in the appropriate fib to the routines that send off route messages. Cheers, Stef --------------000601070001040803040904 Content-Type: text/x-diff; name="freebsd-route-messages-respect-fib-2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-route-messages-respect-fib-2.patch" --- ./sys/net/rtsock.c.orig 2009-08-31 15:26:03.000000000 +0000 +++ ./sys/net/rtsock.c 2009-08-31 19:06:53.000000000 +0000 @@ -93,4 +93,9 @@ SYSCTL_NODE(_net, OID_AUTO, route, CTLFLAG_RD, 0, ""); +struct rt_dispatch_ctx { + unsigned short family; /* Socket family */ + int fibnum; /* FIB for message or -1 for all */ +}; + struct walkarg { int w_tmemsize; @@ -114,5 +119,5 @@ static void rt_getmetrics(const struct rt_metrics_lite *in, struct rt_metrics *out); -static void rt_dispatch(struct mbuf *, const struct sockaddr *); +static void rt_dispatch(struct mbuf *, const struct sockaddr *, int); static struct netisr_handler rtsock_nh = { @@ -155,17 +160,19 @@ { struct sockproto route_proto; - unsigned short *family; + struct rt_dispatch_ctx *ctx; struct m_tag *tag; + int fibnum = -1; route_proto.sp_family = PF_ROUTE; - tag = m_tag_find(m, PACKET_TAG_RTSOCKFAM, NULL); + tag = m_tag_find(m, PACKET_TAG_RTSOCK, NULL); if (tag != NULL) { - family = (unsigned short *)(tag + 1); - route_proto.sp_protocol = *family; + ctx = (struct rt_dispatch_ctx*)(tag + 1); + route_proto.sp_protocol = ctx->family; + fibnum = ctx->fibnum; m_tag_delete(m, tag); } else route_proto.sp_protocol = 0; - raw_input(m, &route_proto, &route_src); + raw_input(m, &route_proto, &route_src, fibnum); } @@ -784,8 +791,8 @@ unsigned short family = rp->rcb_proto.sp_family; rp->rcb_proto.sp_family = 0; - rt_dispatch(m, info.rti_info[RTAX_DST]); + rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum); rp->rcb_proto.sp_family = family; } else - rt_dispatch(m, info.rti_info[RTAX_DST]); + rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum); } } @@ -1010,5 +1017,5 @@ */ void -rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error) +rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error, int fibnum) { struct rt_msghdr *rtm; @@ -1025,5 +1032,5 @@ rtm->rtm_errno = error; rtm->rtm_addrs = rtinfo->rti_addrs; - rt_dispatch(m, sa); + rt_dispatch(m, sa, fibnum); } @@ -1050,5 +1057,5 @@ ifm->ifm_data = ifp->if_data; ifm->ifm_addrs = 0; - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, -1); } @@ -1062,5 +1069,5 @@ */ void -rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt) +rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt, int fibnum) { struct rt_addrinfo info; @@ -1120,5 +1127,5 @@ rtm->rtm_addrs = info.rti_addrs; } - rt_dispatch(m, sa); + rt_dispatch(m, sa, fibnum); } } @@ -1156,5 +1163,5 @@ ifmam->ifmam_index = ifp->if_index; ifmam->ifmam_addrs = info.rti_addrs; - rt_dispatch(m, ifma->ifma_addr); + rt_dispatch(m, ifma->ifma_addr, -1); } @@ -1216,5 +1223,5 @@ m->m_pkthdr.len += data_len; mtod(m, struct if_announcemsghdr *)->ifan_msglen += data_len; - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, -1); } } @@ -1232,10 +1239,11 @@ m = rt_makeifannouncemsg(ifp, RTM_IFANNOUNCE, what, &info); if (m != NULL) - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, -1); } static void -rt_dispatch(struct mbuf *m, const struct sockaddr *sa) +rt_dispatch(struct mbuf *m, const struct sockaddr *sa, int fibnum) { + struct rt_dispatch_ctx *ctx; struct m_tag *tag; @@ -1243,14 +1251,16 @@ * Preserve the family from the sockaddr, if any, in an m_tag for * use when injecting the mbuf into the routing socket buffer from - * the netisr. + * the netisr. Additionally save the fibnum if needed. */ - if (sa != NULL) { - tag = m_tag_get(PACKET_TAG_RTSOCKFAM, sizeof(unsigned short), - M_NOWAIT); + if (sa != NULL || fibnum >= 0) { + tag = m_tag_get(PACKET_TAG_RTSOCK, + sizeof(struct rt_dispatch_ctx*), M_NOWAIT); if (tag == NULL) { m_freem(m); return; } - *(unsigned short *)(tag + 1) = sa->sa_family; + ctx = (struct rt_dispatch_ctx*)(tag + 1); + ctx->family = sa->sa_family; + ctx->fibnum = fibnum; m_tag_prepend(m, tag); } --- ./sys/net/raw_usrreq.c.orig 2009-08-31 16:04:58.000000000 +0000 +++ ./sys/net/raw_usrreq.c 2009-08-31 18:34:38.000000000 +0000 @@ -70,5 +70,5 @@ */ void -raw_input(struct mbuf *m0, struct sockproto *proto, struct sockaddr *src) +raw_input(struct mbuf *m0, struct sockproto *proto, struct sockaddr *src, int fibnum) { struct rawcb *rp; @@ -84,4 +84,7 @@ rp->rcb_proto.sp_protocol != proto->sp_protocol) continue; + if (fibnum >= 0 && rp->rcb_socket && + fibnum != rp->rcb_socket->so_fibnum) + continue; if (last) { struct mbuf *n; --- ./sys/net/raw_cb.h.orig 2009-08-31 18:34:56.000000000 +0000 +++ ./sys/net/raw_cb.h 2009-08-31 18:35:05.000000000 +0000 @@ -73,5 +73,5 @@ int raw_attach(struct socket *, int); void raw_detach(struct rawcb *); -void raw_input(struct mbuf *, struct sockproto *, struct sockaddr *); +void raw_input(struct mbuf *, struct sockproto *, struct sockaddr *, int); /* --- ./sys/net/route.c.orig 2009-08-31 18:18:30.000000000 +0000 +++ ./sys/net/route.c 2009-08-31 18:59:20.000000000 +0000 @@ -384,5 +384,5 @@ bzero(&info, sizeof(info)); info.rti_info[RTAX_DST] = dst; - rt_missmsg(msgtype, &info, 0, err); + rt_missmsg(msgtype, &info, 0, err, fibnum); } done: @@ -609,5 +609,5 @@ info.rti_info[RTAX_NETMASK] = netmask; info.rti_info[RTAX_AUTHOR] = src; - rt_missmsg(RTM_REDIRECT, &info, flags, error); + rt_missmsg(RTM_REDIRECT, &info, flags, error, fibnum); if (ifa != NULL) ifa_free(ifa); @@ -1433,5 +1433,5 @@ rt->rt_ifp->if_index; } - rt_newaddrmsg(cmd, ifa, error, rt); + rt_newaddrmsg(cmd, ifa, error, rt, fibnum); if (cmd == RTM_DELETE) { /* --- ./sys/net/route.h.orig 2009-08-31 18:56:05.000000000 +0000 +++ ./sys/net/route.h 2009-08-31 18:59:32.000000000 +0000 @@ -381,6 +381,6 @@ void rt_ifannouncemsg(struct ifnet *, int); void rt_ifmsg(struct ifnet *); -void rt_missmsg(int, struct rt_addrinfo *, int, int); -void rt_newaddrmsg(int, struct ifaddr *, int, struct rtentry *); +void rt_missmsg(int, struct rt_addrinfo *, int, int, int); +void rt_newaddrmsg(int, struct ifaddr *, int, struct rtentry *, int); void rt_newmaddrmsg(int, struct ifmultiaddr *); int rt_setgate(struct rtentry *, struct sockaddr *, struct sockaddr *); --- ./sys/netinet6/nd6_rtr.c.orig 2009-08-31 18:19:54.000000000 +0000 +++ ./sys/netinet6/nd6_rtr.c 2009-08-31 19:09:27.000000000 +0000 @@ -449,5 +449,5 @@ ifa = NULL; - rt_missmsg(cmd, &info, rt->rt_flags, 0); + rt_missmsg(cmd, &info, rt->rt_flags, 0, -1); if (ifa != NULL) ifa_free(ifa); --- ./sys/netinet6/in6.c.orig 2009-08-31 19:00:43.000000000 +0000 +++ ./sys/netinet6/in6.c 2009-08-31 19:01:00.000000000 +0000 @@ -1238,5 +1238,5 @@ rt_key(&rt0) = (struct sockaddr *)&addr; rt0.rt_flags = RTF_HOST | RTF_STATIC; - rt_newaddrmsg(RTM_DELETE, ifa, 0, &rt0); + rt_newaddrmsg(RTM_DELETE, ifa, 0, &rt0, -1); /* @@ -1831,5 +1831,5 @@ rt_key(&rt) = (struct sockaddr *)&addr; rt.rt_flags = RTF_UP | RTF_HOST | RTF_STATIC; - rt_newaddrmsg(RTM_ADD, &ia->ia_ifa, 0, &rt); + rt_newaddrmsg(RTM_ADD, &ia->ia_ifa, 0, &rt, -1); } --- ./sys/sys/mbuf.h.orig 2009-08-31 18:26:12.000000000 +0000 +++ ./sys/sys/mbuf.h 2009-08-31 18:26:24.000000000 +0000 @@ -897,5 +897,5 @@ #define PACKET_TAG_MACLABEL (19 | MTAG_PERSISTENT) /* MAC label */ #define PACKET_TAG_PF 21 /* PF + ALTQ information */ -#define PACKET_TAG_RTSOCKFAM 25 /* rtsock sa family */ +#define PACKET_TAG_RTSOCK 25 /* rtsock extra info */ #define PACKET_TAG_IPOPTIONS 27 /* Saved IP options */ #define PACKET_TAG_CARP 28 /* CARP info */ --------------000601070001040803040904-- From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 19:50: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 7BA0B1065676; Mon, 31 Aug 2009 19:50:38 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [74.82.45.72]) by mx1.freebsd.org (Postfix) with ESMTP id 66E538FC19; Mon, 31 Aug 2009 19:50:38 +0000 (UTC) Resent-Message-Id: From: Stef Walter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "Li, Qing" References: <200908311702.n7VH2iHI022732@whisker.bluecoat.com> Content-Type: multipart/mixed; boundary="------------000601070001040803040904" X-Virus-Scanned: ClamAV using ClamSMTP Resent-Date: Mon, 31 Aug 2009 19:50:38 +0000 (UTC) Resent-From: stef-list@memberwebs.com X-Mailman-Approved-At: Mon, 31 Aug 2009 20:01:41 +0000 Cc: "freebsd-net@FreeBSD.org" , julian@elischer.org, bug-followup@FreeBSD.org Subject: Re: kern/134931 [patch] Unbreak setfib + routing daemons X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Mon, 31 Aug 2009 19:50:38 -0000 X-List-Received-Date: Mon, 31 Aug 2009 19:50:38 -0000 This is a multi-part message in MIME format. --------------000601070001040803040904 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Li, Qing wrote: > There are other commands through the routing socket that > can trigger routing messages. For example, issuing "ifconfig" > to add and remove interface addresses. Thanks for taking a look at this and catching that problem. Here's a new patch which does the following: * Both rt_dispatch and raw_input accept an fib, or -1 (for any fib). * Pases the fib along in the context to the netisr routine that actually dispatches route messages. * As you noted, some senders of route messages don't have the context necessary to know what fib a message would belong to. Where possible we pass in the appropriate fib to the routines that send off route messages. Cheers, Stef --------------000601070001040803040904 Content-Type: text/x-diff; name="freebsd-route-messages-respect-fib-2.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="freebsd-route-messages-respect-fib-2.patch" --- ./sys/net/rtsock.c.orig 2009-08-31 15:26:03.000000000 +0000 +++ ./sys/net/rtsock.c 2009-08-31 19:06:53.000000000 +0000 @@ -93,4 +93,9 @@ SYSCTL_NODE(_net, OID_AUTO, route, CTLFLAG_RD, 0, ""); +struct rt_dispatch_ctx { + unsigned short family; /* Socket family */ + int fibnum; /* FIB for message or -1 for all */ +}; + struct walkarg { int w_tmemsize; @@ -114,5 +119,5 @@ static void rt_getmetrics(const struct rt_metrics_lite *in, struct rt_metrics *out); -static void rt_dispatch(struct mbuf *, const struct sockaddr *); +static void rt_dispatch(struct mbuf *, const struct sockaddr *, int); static struct netisr_handler rtsock_nh = { @@ -155,17 +160,19 @@ { struct sockproto route_proto; - unsigned short *family; + struct rt_dispatch_ctx *ctx; struct m_tag *tag; + int fibnum = -1; route_proto.sp_family = PF_ROUTE; - tag = m_tag_find(m, PACKET_TAG_RTSOCKFAM, NULL); + tag = m_tag_find(m, PACKET_TAG_RTSOCK, NULL); if (tag != NULL) { - family = (unsigned short *)(tag + 1); - route_proto.sp_protocol = *family; + ctx = (struct rt_dispatch_ctx*)(tag + 1); + route_proto.sp_protocol = ctx->family; + fibnum = ctx->fibnum; m_tag_delete(m, tag); } else route_proto.sp_protocol = 0; - raw_input(m, &route_proto, &route_src); + raw_input(m, &route_proto, &route_src, fibnum); } @@ -784,8 +791,8 @@ unsigned short family = rp->rcb_proto.sp_family; rp->rcb_proto.sp_family = 0; - rt_dispatch(m, info.rti_info[RTAX_DST]); + rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum); rp->rcb_proto.sp_family = family; } else - rt_dispatch(m, info.rti_info[RTAX_DST]); + rt_dispatch(m, info.rti_info[RTAX_DST], so->so_fibnum); } } @@ -1010,5 +1017,5 @@ */ void -rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error) +rt_missmsg(int type, struct rt_addrinfo *rtinfo, int flags, int error, int fibnum) { struct rt_msghdr *rtm; @@ -1025,5 +1032,5 @@ rtm->rtm_errno = error; rtm->rtm_addrs = rtinfo->rti_addrs; - rt_dispatch(m, sa); + rt_dispatch(m, sa, fibnum); } @@ -1050,5 +1057,5 @@ ifm->ifm_data = ifp->if_data; ifm->ifm_addrs = 0; - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, -1); } @@ -1062,5 +1069,5 @@ */ void -rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt) +rt_newaddrmsg(int cmd, struct ifaddr *ifa, int error, struct rtentry *rt, int fibnum) { struct rt_addrinfo info; @@ -1120,5 +1127,5 @@ rtm->rtm_addrs = info.rti_addrs; } - rt_dispatch(m, sa); + rt_dispatch(m, sa, fibnum); } } @@ -1156,5 +1163,5 @@ ifmam->ifmam_index = ifp->if_index; ifmam->ifmam_addrs = info.rti_addrs; - rt_dispatch(m, ifma->ifma_addr); + rt_dispatch(m, ifma->ifma_addr, -1); } @@ -1216,5 +1223,5 @@ m->m_pkthdr.len += data_len; mtod(m, struct if_announcemsghdr *)->ifan_msglen += data_len; - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, -1); } } @@ -1232,10 +1239,11 @@ m = rt_makeifannouncemsg(ifp, RTM_IFANNOUNCE, what, &info); if (m != NULL) - rt_dispatch(m, NULL); + rt_dispatch(m, NULL, -1); } static void -rt_dispatch(struct mbuf *m, const struct sockaddr *sa) +rt_dispatch(struct mbuf *m, const struct sockaddr *sa, int fibnum) { + struct rt_dispatch_ctx *ctx; struct m_tag *tag; @@ -1243,14 +1251,16 @@ * Preserve the family from the sockaddr, if any, in an m_tag for * use when injecting the mbuf into the routing socket buffer from - * the netisr. + * the netisr. Additionally save the fibnum if needed. */ - if (sa != NULL) { - tag = m_tag_get(PACKET_TAG_RTSOCKFAM, sizeof(unsigned short), - M_NOWAIT); + if (sa != NULL || fibnum >= 0) { + tag = m_tag_get(PACKET_TAG_RTSOCK, + sizeof(struct rt_dispatch_ctx*), M_NOWAIT); if (tag == NULL) { m_freem(m); return; } - *(unsigned short *)(tag + 1) = sa->sa_family; + ctx = (struct rt_dispatch_ctx*)(tag + 1); + ctx->family = sa->sa_family; + ctx->fibnum = fibnum; m_tag_prepend(m, tag); } --- ./sys/net/raw_usrreq.c.orig 2009-08-31 16:04:58.000000000 +0000 +++ ./sys/net/raw_usrreq.c 2009-08-31 18:34:38.000000000 +0000 @@ -70,5 +70,5 @@ */ void -raw_input(struct mbuf *m0, struct sockproto *proto, struct sockaddr *src) +raw_input(struct mbuf *m0, struct sockproto *proto, struct sockaddr *src, int fibnum) { struct rawcb *rp; @@ -84,4 +84,7 @@ rp->rcb_proto.sp_protocol != proto->sp_protocol) continue; + if (fibnum >= 0 && rp->rcb_socket && + fibnum != rp->rcb_socket->so_fibnum) + continue; if (last) { struct mbuf *n; --- ./sys/net/raw_cb.h.orig 2009-08-31 18:34:56.000000000 +0000 +++ ./sys/net/raw_cb.h 2009-08-31 18:35:05.000000000 +0000 @@ -73,5 +73,5 @@ int raw_attach(struct socket *, int); void raw_detach(struct rawcb *); -void raw_input(struct mbuf *, struct sockproto *, struct sockaddr *); +void raw_input(struct mbuf *, struct sockproto *, struct sockaddr *, int); /* --- ./sys/net/route.c.orig 2009-08-31 18:18:30.000000000 +0000 +++ ./sys/net/route.c 2009-08-31 18:59:20.000000000 +0000 @@ -384,5 +384,5 @@ bzero(&info, sizeof(info)); info.rti_info[RTAX_DST] = dst; - rt_missmsg(msgtype, &info, 0, err); + rt_missmsg(msgtype, &info, 0, err, fibnum); } done: @@ -609,5 +609,5 @@ info.rti_info[RTAX_NETMASK] = netmask; info.rti_info[RTAX_AUTHOR] = src; - rt_missmsg(RTM_REDIRECT, &info, flags, error); + rt_missmsg(RTM_REDIRECT, &info, flags, error, fibnum); if (ifa != NULL) ifa_free(ifa); @@ -1433,5 +1433,5 @@ rt->rt_ifp->if_index; } - rt_newaddrmsg(cmd, ifa, error, rt); + rt_newaddrmsg(cmd, ifa, error, rt, fibnum); if (cmd == RTM_DELETE) { /* --- ./sys/net/route.h.orig 2009-08-31 18:56:05.000000000 +0000 +++ ./sys/net/route.h 2009-08-31 18:59:32.000000000 +0000 @@ -381,6 +381,6 @@ void rt_ifannouncemsg(struct ifnet *, int); void rt_ifmsg(struct ifnet *); -void rt_missmsg(int, struct rt_addrinfo *, int, int); -void rt_newaddrmsg(int, struct ifaddr *, int, struct rtentry *); +void rt_missmsg(int, struct rt_addrinfo *, int, int, int); +void rt_newaddrmsg(int, struct ifaddr *, int, struct rtentry *, int); void rt_newmaddrmsg(int, struct ifmultiaddr *); int rt_setgate(struct rtentry *, struct sockaddr *, struct sockaddr *); --- ./sys/netinet6/nd6_rtr.c.orig 2009-08-31 18:19:54.000000000 +0000 +++ ./sys/netinet6/nd6_rtr.c 2009-08-31 19:09:27.000000000 +0000 @@ -449,5 +449,5 @@ ifa = NULL; - rt_missmsg(cmd, &info, rt->rt_flags, 0); + rt_missmsg(cmd, &info, rt->rt_flags, 0, -1); if (ifa != NULL) ifa_free(ifa); --- ./sys/netinet6/in6.c.orig 2009-08-31 19:00:43.000000000 +0000 +++ ./sys/netinet6/in6.c 2009-08-31 19:01:00.000000000 +0000 @@ -1238,5 +1238,5 @@ rt_key(&rt0) = (struct sockaddr *)&addr; rt0.rt_flags = RTF_HOST | RTF_STATIC; - rt_newaddrmsg(RTM_DELETE, ifa, 0, &rt0); + rt_newaddrmsg(RTM_DELETE, ifa, 0, &rt0, -1); /* @@ -1831,5 +1831,5 @@ rt_key(&rt) = (struct sockaddr *)&addr; rt.rt_flags = RTF_UP | RTF_HOST | RTF_STATIC; - rt_newaddrmsg(RTM_ADD, &ia->ia_ifa, 0, &rt); + rt_newaddrmsg(RTM_ADD, &ia->ia_ifa, 0, &rt, -1); } --- ./sys/sys/mbuf.h.orig 2009-08-31 18:26:12.000000000 +0000 +++ ./sys/sys/mbuf.h 2009-08-31 18:26:24.000000000 +0000 @@ -897,5 +897,5 @@ #define PACKET_TAG_MACLABEL (19 | MTAG_PERSISTENT) /* MAC label */ #define PACKET_TAG_PF 21 /* PF + ALTQ information */ -#define PACKET_TAG_RTSOCKFAM 25 /* rtsock sa family */ +#define PACKET_TAG_RTSOCK 25 /* rtsock extra info */ #define PACKET_TAG_IPOPTIONS 27 /* Saved IP options */ #define PACKET_TAG_CARP 28 /* CARP info */ --------------000601070001040803040904-- From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 22:20:11 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 CAC9E106566B for ; Mon, 31 Aug 2009 22:20:11 +0000 (UTC) (envelope-from seklecki@noc.cfi.pgh.pa.us) Received: from mx04.pub.collaborativefusion.com (mx04.pub.collaborativefusion.com [206.210.72.84]) by mx1.freebsd.org (Postfix) with ESMTP id 915728FC08 for ; Mon, 31 Aug 2009 22:20:11 +0000 (UTC) Received: from [192.168.2.161] ([206.210.89.202]) by mx04.pub.collaborativefusion.com (StrongMail Enterprise 4.1.1.4(4.1.1.4-47689)); Mon, 31 Aug 2009 17:55:07 -0400 X-VirtualServerGroup: Default X-MailingID: 00000::00000::00000::00000::::0 X-SMHeaderMap: mid="X-MailingID" X-Destination-ID: freebsd-net@freebsd.org X-SMFBL: ZnJlZWJzZC1uZXRAZnJlZWJzZC5vcmc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=noc.cfi.pgh.pa.us; s=noc_cfi_pgh_pa_us_key_dkim; l=1008; t=1251755708; i=@noc.cfi.pgh.pa.us; h=Subject:From:To:Cc: In-Reply-To:References:Content-Type:Date:Message-Id:Mime-Version: X-Mailer:Content-Transfer-Encoding; bh=Xp2NL1IRMBbLynKgifLMm54i6 Q4=; b=SwAHZAe6qCOJGwUmd9hqkXfEVW+K4PNQO28YBhb9tO3f7RNQlmqIhWfN3 2FtiZt2my4ufcHihhg/pLwYyHsHg9WnXh6+Pj+mt2ZDrAyfBpT1M3ritfsXcnm3H +B6fS2a From: "Brian A. Seklecki" To: Graham Smith In-Reply-To: References: Content-Type: text/plain Date: Mon, 31 Aug 2009 18:20:07 -0400 Message-Id: <1251757207.25573.1794.camel@soundwave.ws.pitbpa0.priv.collaborativefusion.com> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 (2.26.3-1.fc11) Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: native vlan 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, 31 Aug 2009 22:20:11 -0000 On Mon, 2009-08-24 at 12:12 -0700, Graham Smith wrote: > requiring creation of native vlan (vlan 0) and why native vlan are > most suitable for this scene ? Cisco highly recommend changing the management VLAN away from VLAN1. Here's an example, of using alternative native VLANs, ironically, on the one Cisco product that doesn't follow that VLAN1-rule. On the Cisco Aironet AP 1200, you can run a Dot1Q VLAN trunk to map X-number of different ESSIDs-to-VLANs. You do this by setting the "bridge-group" of the Ethernet Subinterface and the Dot11Radio subinterfaces to the same VLAN that you would like to bridge. Whereas, management traffic (Monitoring, etc.) has to run on "BVI1", or Bridged Virtual Interface 1, which must transmit untagged on Ethernet0. This stipulation is set by the Bridging IOS on the AP1200. If your management VLAN is something other than VLAN1 (god forbid), you simply set the "native VLAN" on that Dot1Q trunk port on the Catalyst to some other VLAN From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 22:27:47 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 9D95B1065670 for ; Mon, 31 Aug 2009 22:27:47 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [195.88.108.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5B0838FC16 for ; Mon, 31 Aug 2009 22:27:47 +0000 (UTC) Received: from localhost (amavis.fra.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id DDFB141C710; Tue, 1 Sep 2009 00:10:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([195.88.108.3]) by localhost (amavis.fra.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id s39HelIYH1Vi; Tue, 1 Sep 2009 00:10:06 +0200 (CEST) Received: by mail.cksoft.de (Postfix, from userid 66) id 3F7CE41C729; Tue, 1 Sep 2009 00:10:06 +0200 (CEST) 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 5008A4448E6; Mon, 31 Aug 2009 22:08:37 +0000 (UTC) Date: Mon, 31 Aug 2009 22:08:37 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: qingli@freebsd.org Message-ID: <20090831215129.V93661@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD networkers mailing list Subject: CFR/CFT: plug mbuf leak in new arp code 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, 31 Aug 2009 22:27:47 -0000 Hi, I have a patch for FreeBSD 8.x / 9-CURRENT that plugs an mbuf leak in the new arp code that needs review and further testing. Find a longer description of the problem at the beginning of the patch. There is a lot of context in the patch; if you want a shorter one, apply and re-gen it. If you want to see the current problem, log in to a remote 8/9 machine and repeatedly type ... over that connection (you need to be su): arp -ad > /dev/null ; netstat -m | head -1 Watch the first number. Warning: doing it too often will make that machine panic eventually. Here's the patch: http://people.freebsd.org/~bz/20090831-01-plug-new-arp-mbuf-leak.diff Thanks for your help in advance. /bz -- Bjoern A. Zeeb What was I talking about and who are you again? From owner-freebsd-net@FreeBSD.ORG Mon Aug 31 23:04:04 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 CCBBF106568F for ; Mon, 31 Aug 2009 23:04:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outA.internet-mail-service.net (outa.internet-mail-service.net [216.240.47.224]) by mx1.freebsd.org (Postfix) with ESMTP id B4A4A8FC15 for ; Mon, 31 Aug 2009 23:04:04 +0000 (UTC) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id B01C3B57E; Mon, 31 Aug 2009 16:04:04 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id E2E452D6013; Mon, 31 Aug 2009 16:04:03 -0700 (PDT) Message-ID: <4A9C56E2.7070609@elischer.org> Date: Mon, 31 Aug 2009 16:04:02 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20090831215129.V93661@maildrop.int.zabbadoz.net> In-Reply-To: <20090831215129.V93661@maildrop.int.zabbadoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: qingli@freebsd.org, FreeBSD networkers mailing list Subject: Re: CFR/CFT: plug mbuf leak in new arp code 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, 31 Aug 2009 23:04:04 -0000 Bjoern A. Zeeb wrote: > Hi, > > I have a patch for FreeBSD 8.x / 9-CURRENT that plugs an mbuf leak > in the new arp code that needs review and further testing. > > Find a longer description of the problem at the beginning of the > patch. There is a lot of context in the patch; if you want a shorter > one, apply and re-gen it. > > If you want to see the current problem, log in to a remote 8/9 machine > and repeatedly type ... over that connection (you need to be su): > arp -ad > /dev/null ; netstat -m | head -1 > Watch the first number. Warning: doing it too often will make that > machine panic eventually. > > Here's the patch: > http://people.freebsd.org/~bz/20090831-01-plug-new-arp-mbuf-leak.diff > > Thanks for your help in advance. > > /bz > looks pretty right... all the paths I followed through did the right thing WRT locks and mbufs. From owner-freebsd-net@FreeBSD.ORG Tue Sep 1 01:44:33 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 90CB6106568B; Tue, 1 Sep 2009 01:44:33 +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 750198FC1A; Tue, 1 Sep 2009 01:44:33 +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 n811iWP8006106; Mon, 31 Aug 2009 18:44:32 -0700 (PDT) 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: Mon, 31 Aug 2009 18:44:25 -0700 Message-ID: In-Reply-To: <20090830.024420.174808572.hrs@allbsd.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 regression on 8.x Thread-Index: Acoo0HsjKhik75XsQjG/X1fWVdINtwB1IOFw References: <20090830.024420.174808572.hrs@allbsd.org> From: "Li, Qing" To: "Hiroki Sato" Cc: qingli@freebsd.org, freebsd-current@freebsd.org, freebsd-net@freebsd.org Subject: RE: IPv6 regression on 8.x 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, 01 Sep 2009 01:44:33 -0000 Hi Hiroki, > > 2) Issue of subnet-router anycast address with a global address >=20 > Thanks for the fixes! With the two patches 1) and 3) are gone, but > 2) still remains. Is there something I can help to narrow down it? >=20 Hmm... I tried multiple test cases and all seem to work as expected. I also tried the exact configuration sequence as you outlined in your original bug report email, and that case worked, too. The only difference I can see from the given information, is I have=20 3 em interfaces, whereas you have 2 em interfaces and 1 re, but I=20 don't see how that would make a difference. Would it be possible for you to email me your system configuration=20 produced from "ifconfig" and "netstat" privately ? Thank you. -- Qing From owner-freebsd-net@FreeBSD.ORG Tue Sep 1 05:20: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 A8CAE10656A5 for ; Tue, 1 Sep 2009 05:20: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 986DB8FC12 for ; Tue, 1 Sep 2009 05:20:03 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n815K3dr081240 for ; Tue, 1 Sep 2009 05:20:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n815K3S2081239; Tue, 1 Sep 2009 05:20:03 GMT (envelope-from gnats) Date: Tue, 1 Sep 2009 05:20:03 GMT Message-Id: <200909010520.n815K3S2081239@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Paul A. Procacci" Cc: Subject: Re: kern/138292: [zyd] [usb8] "zyd0: device timeout" with ZyXEL G-202 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Paul A. Procacci" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2009 05:20:03 -0000 The following reply was made to PR kern/138292; it has been noted by GNATS. From: "Paul A. Procacci" To: , Cc: Subject: Re: kern/138292: [zyd] [usb8] "zyd0: device timeout" with ZyXEL G-202 Date: Tue, 1 Sep 2009 00:02:58 -0500 I've got the same problem here for what it's worth. zyd0: on usbus0 This is Freebsd 9.0-Current. Same timeout problems. (was trying to download/install fluxbox) This message may contain confidential or privileged information. If you ar= e not the intended recipient, please advise us immediately and delete this = message. See http://www.datapipe.com/emaildisclaimer.aspx for further info= rmation on confidentiality and the risks of non-secure electronic communica= tion. If you cannot access these links, please notify us by reply message a= nd we will send the contents to you. From owner-freebsd-net@FreeBSD.ORG Tue Sep 1 05:32:50 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 56BAA106566C; Tue, 1 Sep 2009 05:32:50 +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 2DC2C8FC17; Tue, 1 Sep 2009 05:32:50 +0000 (UTC) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n815WoMY001718; Tue, 1 Sep 2009 05:32:50 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n815WoJL001714; Tue, 1 Sep 2009 05:32:50 GMT (envelope-from linimon) Date: Tue, 1 Sep 2009 05:32:50 GMT Message-Id: <200909010532.n815WoJL001714@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/138427: [wpi] [panic] Kernel panic after trying set monitor wlanmode on Intel 3945 ABG (wpi 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, 01 Sep 2009 05:32:50 -0000 Old Synopsis: Kernel panic after trying set monitor wlanmode on Intel 3945 ABG (wpi driver) New Synopsis: [wpi] [panic] Kernel panic after trying set monitor wlanmode on Intel 3945 ABG (wpi driver) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Sep 1 05:32:27 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138427 From owner-freebsd-net@FreeBSD.ORG Tue Sep 1 06:51:32 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 71AD2106566C for ; Tue, 1 Sep 2009 06:51:32 +0000 (UTC) (envelope-from cjeker@diehard.n-r-g.com) Received: from diehard.n-r-g.com (diehard.n-r-g.com [62.48.3.9]) by mx1.freebsd.org (Postfix) with ESMTP id E2C498FC2A for ; Tue, 1 Sep 2009 06:51:31 +0000 (UTC) Received: (qmail 17798 invoked by uid 1001); 1 Sep 2009 06:24:50 -0000 Date: Tue, 1 Sep 2009 08:24:50 +0200 From: Claudio Jeker To: freebsd-net@freebsd.org Message-ID: <20090901062449.GC25711@diehard.n-r-g.com> Mail-Followup-To: Claudio Jeker , freebsd-net@freebsd.org References: <4A9C137C.7020303@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [patch] Unbreak setfib + routing daemons 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, 01 Sep 2009 06:51:32 -0000 On Mon, Aug 31, 2009 at 07:48:32PM +0000, Stef Walter wrote: > Julian Elischer wrote: > > there are two ways to go with this one being what you have done teh > > other to add fib info to the messages, Apparently > > OpenBSD has implemented the second by re-using a disused field. > > (I'm ve only been told this second hand) > > It seems like they've taken apart the rtm_flags field (int), and > repurposed it as rtm_tableid (u_short), rtm_priority (u_char) and padding. > This is not 100% correct. rtm_flags is still there. We changed the structure of the routing messages some time ago and added the necessary additional fields while doing that. This included a bump in rtm_version and a simple recompile of third party routing daemons like quagga was enough. > Obviously such a change would require patches to the various routing > daemons as well. But if you think this is the only way forward (ie: > filtering the messages in userland), I'd be happy to contribute. > I plan to extend our routing socket filters to include the tableid making it possible to limit the messages to only that part needed. Getting all messages from all routing domains into all PF_ROUTE listeners results in unneeded overhead. -- :wq Claudio From owner-freebsd-net@FreeBSD.ORG Tue Sep 1 16:13:14 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 97DA51065679 for ; Tue, 1 Sep 2009 16:13:14 +0000 (UTC) (envelope-from john@traktor.dnepro.net) Received: from traktor.dnepro.net (roof1.dnepro.net [212.3.111.66]) by mx1.freebsd.org (Postfix) with ESMTP id 135C48FC0C for ; Tue, 1 Sep 2009 16:13:13 +0000 (UTC) Received: from traktor.dnepro.net (localhost [127.0.0.1]) by traktor.dnepro.net (8.14.3/8.14.3) with ESMTP id n81GDArf049266; Tue, 1 Sep 2009 19:13:10 +0300 (EEST) (envelope-from john@traktor.dnepro.net) Received: (from john@localhost) by traktor.dnepro.net (8.14.3/8.14.3/Submit) id n81GDAdd049263; Tue, 1 Sep 2009 19:13:10 +0300 (EEST) (envelope-from john) Date: Tue, 1 Sep 2009 19:13:10 +0300 From: Eugene Perevyazko To: freebsd-net@freebsd.org Message-ID: <20090901161310.GA37481@traktor.dnepro.net> Mail-Followup-To: freebsd-net@freebsd.org, Pyun YongHyeon References: <20090821142039.GA40018@traktor.dnepro.net> <20090821221932.GE1262@michelle.cdnetworks.com> <20090825083857.GA22983@traktor.dnepro.net> <20090825114649.GA11642@traktor.dnepro.net> <20090825130821.GA41669@traktor.dnepro.net> <20090825182553.GD1282@michelle.cdnetworks.com> <20090826093916.GB10790@traktor.dnepro.net> <20090826094856.GC10790@traktor.dnepro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090826094856.GC10790@traktor.dnepro.net> User-Agent: Mutt/1.4.2.3i Cc: Pyun YongHyeon Subject: Re: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link 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, 01 Sep 2009 16:13:14 -0000 On Wed, Aug 26, 2009 at 12:48:56PM +0300, Eugene Perevyazko wrote: > On Wed, Aug 26, 2009 at 12:39:16PM +0300, Eugene Perevyazko wrote: > > On Tue, Aug 25, 2009 at 11:25:53AM -0700, Pyun YongHyeon wrote: > > > > > > Try attached patch and let me know how it goes on your box. > > > You can see statistics counters maintained in driver with sysctl. > > > "sysctl dev.msk.0.stats" will show some numbers if it can see > > > packets on wire. > > > > With attached patch NIC doesn't see link again. > > All counters in dev.msk.0.stats are 0s. > > > > At the same time the link led on NIC is on, and switch shows that port is up. > That's different from the unpatched system, where led was off and switch port > was down. > Any chances to get that NIC working? I tried to look at linux driver for it (sk98lin) but quickly got lost - it's about 700 lines only for SkGmInitPhyMarv() - Initialize the Marvell PHY registers And hw programming is definitely not my expertise :( -- Eugene Perevyazko From owner-freebsd-net@FreeBSD.ORG Tue Sep 1 16:33:06 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 0C3431065676 for ; Tue, 1 Sep 2009 16:33:06 +0000 (UTC) (envelope-from bounces@nabble.com) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by mx1.freebsd.org (Postfix) with ESMTP id D8CD58FC14 for ; Tue, 1 Sep 2009 16:33:05 +0000 (UTC) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1MiW1C-0000Hb-2j for freebsd-net@freebsd.org; Tue, 01 Sep 2009 09:15:38 -0700 Message-ID: <25243305.post@talk.nabble.com> Date: Tue, 1 Sep 2009 09:15:38 -0700 (PDT) From: rconan To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: rconan@uvic.ca Subject: Intel 5100 AGN Wifi 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, 01 Sep 2009 16:33:06 -0000 Hi I have a laptop with an Intel 5100 AGN Wifi adapter. Is there a driver for FreeBSD 7.2? Thanks Rod -- View this message in context: http://www.nabble.com/Intel-5100-AGN-Wifi-tp25243305p25243305.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Tue Sep 1 17:34:19 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 AD2361065670 for ; Tue, 1 Sep 2009 17:34:19 +0000 (UTC) (envelope-from wangfangcs@gmail.com) Received: from mail-yx0-f195.google.com (mail-yx0-f195.google.com [209.85.210.195]) by mx1.freebsd.org (Postfix) with ESMTP id 38F048FC16 for ; Tue, 1 Sep 2009 17:34:19 +0000 (UTC) Received: by yxe33 with SMTP id 33so346316yxe.7 for ; Tue, 01 Sep 2009 10:34:18 -0700 (PDT) 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=zW7hltwBDzTdHuNl0ZkrsZaWivbCI7bkzUK6Ke4whnU=; b=t12c5Ucn081xFJ+jb3RNi6aUawJ90tKiN1GjwRYk/v2T/dRdrVGA6kq5LfxdSdIBAg fz+JAyQGWjl4Qs20teA5BcEoPTaHNQ2h9ohq2cQnUNJd6X14tJQo7uj0tnffH+gUTdzv ki9fYvOEG/kGbSBnhTV+5NFnH8a5B2gwt37+o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=YDjWnbklEeeL+/Fnf1nM/A4ABjhNe2EZEpI5a61TUbsOedMKafWlfIk61gKUKCnfUi iPNTmVy3n+drfUtP4v5hCiZSgy/QG/AmIWMpl8HzDlmJVCS5FfgnYi27vr+xIrHoGtvo ghCuqMbUpnQpo3R/E4a3MRqs/TTfGy+FK8KR4= MIME-Version: 1.0 Received: by 10.100.80.2 with SMTP id d2mr7931645anb.35.1251826458546; Tue, 01 Sep 2009 10:34:18 -0700 (PDT) Date: Wed, 2 Sep 2009 01:34:18 +0800 Message-ID: From: Fang Wang To: freebsd-net@freebsd.org Content-Type: multipart/mixed; boundary=0050450176f461d4580472878f74 Subject: TCP UTO (RFC 5482) patch calls for review 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, 01 Sep 2009 17:34:19 -0000 --0050450176f461d4580472878f74 Content-Type: text/plain; charset=ISO-8859-1 Hi, The attached patch implements TCP User Timeout Option(RFC 5482 [0]) in freebsd tcp stack. And this patch comes from my GSoC 2009 project -- Implement TCP UTO(mentor, Rui Paulo). I will be very grateful to any tips, suggestions and questions. Brief introduction about TCP UTO: The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. TCP User Timeout Option allows one end of a TCP connection to advertise it's current user timeout value. This information provides advice to the other end of the TCP connection to adapt it's user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity. [0] - http://tools.ietf.org/html/rfc5482 Best Regards, Fang Wang --0050450176f461d4580472878f74 Content-Type: text/x-patch; charset=US-ASCII; name="tcputo.diff" Content-Disposition: attachment; filename="tcputo.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fz2w5egd0 SW5kZXg6IHN5cy9uZXRpbmV0L3RjcF9pbnB1dC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXRpbmV0 L3RjcF9pbnB1dC5jCShyZXZpc2lvbiAxOTY0NTUpCisrKyBzeXMvbmV0aW5ldC90Y3BfaW5wdXQu Ywkod29ya2luZyBjb3B5KQpAQCAtMTE5Niw2ICsxMTk2LDE5IEBACiAJICAgICh0aGZsYWdzICYg VEhfU1lOKSA/IFRPX1NZTiA6IDApOwogCiAJLyoKKwkgKiBJZiB0aGUgVENQIHVzZXIgdGltZW91 dCBvcHRpb24gaXMgcHJlc2VudCwgcmVjb3JkIGl0IGJ1dAorCSAqIGRvIG5vdGhpbmcgYmVjYXVz ZSBpdCdzIGFuIG9wdGlvbmFsIG9wdGlvbi4KKwkgKiBXZSB3aWxsIHByb2Nlc3Mgb24gdGhlIGZv bGxvd2luZyBjYXNlczoKKwkgKiAgICAxLiBXZSBuZWVkIGRvIHJldHJhbnNtaXNzaW9uLgorCSAq ICAgIDIuIFVzZXJzIHJlcXVlc3QgYSBVVE8gdmFsdWUuCisJICovCisJaWYgKHRvLnRvX2ZsYWdz ICYgVE9GX1VUTykgeworCQl0cC0+dXRvX2ZsYWdzIHw9IFRDUFVUT19SQ1ZEOworCQl0cC0+cmN2 X3V0byA9IHRvLnRvX3V0bzsKKwkJVENQU1RBVF9JTkModGNwc19yY3Z1dG8pOworCX0KKwkKKwkv KgogCSAqIElmIGVjaG9lZCB0aW1lc3RhbXAgaXMgbGF0ZXIgdGhhbiB0aGUgY3VycmVudCB0aW1l LAogCSAqIGZhbGwgYmFjayB0byBub24gUkZDMTMyMyBSVFQgY2FsY3VsYXRpb24uICBOb3JtYWxp emUKIAkgKiB0aW1lc3RhbXAgaWYgc3luY29va2llcyB3ZXJlIHVzZWQgd2hlbiB0aGlzIGNvbm5l Y3Rpb24KQEAgLTIyNDcsNiArMjI2MCwxNCBAQAogCQl9CiAKIHByb2Nlc3NfQUNLOgorCQkvKgor CQkgKiBJZiByZWNlaXZlZCBhbiBBQ0sgZm9yIGEgcHJldmlvdXNseSBzZW50IFRDUCBVVE8gb3B0 aW9uLAorCQkgKiBzdG9wIGluY2x1ZGluZyB0aGUgVENQIFVUTyBvcHRpb24gb24gb3V0cHV0IHBh Y2tldHMuCisJCSAqLworCQlpZiAodHAtPnV0b19mbGFncyAmIFRDUFVUT19TRU5ESU5HKQorCQkJ aWYgKFNFUV9HRVEodGgtPnRoX2FjaywgdHAtPnV0b19jYXJyaWVyKSkKKwkJCQl0cC0+dXRvX2Zs YWdzICY9IH5UQ1BVVE9fU0VORElORzsKKwogCQlJTlBfSU5GT19MT0NLX0FTU0VSVCgmVl90Y2Jp bmZvKTsKIAkJS0FTU0VSVCh0aV9sb2NrZWQgPT0gVElfUkxPQ0tFRCB8fCB0aV9sb2NrZWQgPT0g VElfV0xPQ0tFRCwKIAkJICAgICgidGNwX2lucHV0OiBwcm9jZXNzX0FDSyB0aV9sb2NrZWQgJWQi LCB0aV9sb2NrZWQpKTsKQEAgLTI5NTMsNiArMjk3NCwxNCBAQAogCQkJdG8tPnRvX3NhY2tzID0g Y3AgKyAyOwogCQkJVENQU1RBVF9JTkModGNwc19zYWNrX3Jjdl9ibG9ja3MpOwogCQkJYnJlYWs7 CisJCWNhc2UgVENQT1BUX1VUTzoKKwkJCWlmIChvcHRsZW4gIT0gVENQT0xFTl9VVE8pCisJCQkJ Y29udGludWU7CisJCQl0by0+dG9fZmxhZ3MgfD0gVE9GX1VUTzsKKwkJCWJjb3B5KChjaGFyICop Y3AgKyAyLAorCQkJICAgIChjaGFyICopJnRvLT50b191dG8sIHNpemVvZih0by0+dG9fdXRvKSk7 CisJCQl0by0+dG9fdXRvID0gbnRvaHModG8tPnRvX3V0byk7CisJCQlicmVhazsKIAkJZGVmYXVs dDoKIAkJCWNvbnRpbnVlOwogCQl9CkluZGV4OiBzeXMvbmV0aW5ldC90Y3Bfc3Vici5jCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIHN5cy9uZXRpbmV0L3RjcF9zdWJyLmMJKHJldmlzaW9uIDE5NjQ1NSkKKysrIHN5 cy9uZXRpbmV0L3RjcF9zdWJyLmMJKHdvcmtpbmcgY29weSkKQEAgLTMzNiw2ICszMzYsNyBAQAog CVZfdGNwX2F1dG9yY3ZidWZfbWF4ID0gMjU2KjEwMjQ7CiAJVl90Y3BfZG9fcmZjMzQ2NSA9IDE7 CiAJVl90Y3BfYWJjX2xfdmFyID0gMjsKKwlWX3RjcF91dG9fZW5hYmxlID0gMDsKIAogCVZfdGNw X21zc2RmbHQgPSBUQ1BfTVNTOwogI2lmZGVmIElORVQ2CkBAIC00MTksNiArNDIwLDggQEAKIAl0 Y3BfcmV4bWl0X3Nsb3AgPSBUQ1BUVl9DUFVfVkFSOwogCXRjcF9maW53YWl0Ml90aW1lb3V0ID0g VENQVFZfRklOV0FJVDJfVElNRU9VVDsKIAl0Y3BfdGNiaGFzaHNpemUgPSBoYXNoc2l6ZTsKKwlW X3RjcF91dG9fbWluID0gVENQVFZfVVRPX01JTjsKKwlWX3RjcF91dG9fbWF4ID0gVENQVFZfVVRP X01BWDsKIAogI2lmZGVmIElORVQ2CiAjZGVmaW5lIFRDUF9NSU5QUk9UT0hEUiAoc2l6ZW9mKHN0 cnVjdCBpcDZfaGRyKSArIHNpemVvZihzdHJ1Y3QgdGNwaGRyKSkKQEAgLTc3Myw3ICs3NzYsMTgg QEAKIAl0cC0+c25kX3NzdGhyZXNoID0gVENQX01BWFdJTiA8PCBUQ1BfTUFYX1dJTlNISUZUOwog CXRwLT50X3JjdnRpbWUgPSB0aWNrczsKIAl0cC0+dF9id19ydHR0aW1lID0gdGlja3M7CisKKwl0 cC0+dXRvX2ZsYWdzID0gVENQVVRPX0NIQU5HRUFCTEU7CisJaWYgKFZfdGNwX3V0b19lbmFibGUp CisJCXRwLT51dG9fZmxhZ3MgfD0gVENQVVRPX0VOQUJMRTsKIAkvKgorCSAqIEFjY29yZGluZyB0 byBSRkMgNTQ4MiwgdF91dG9fYWR2IGlzIFVUTyBvcHRpb24gYWR2ZXJ0aXNlZCB0byB0aGUKKwkg KiByZW1vdGUgVENQIHBlZXIuICBJdCBkZWZhdWx0cyB0byB0aGUgZGVmYXVsdCBzeXN0ZW0td2lk ZSBVU0VSCisJICogVElNRU9VVC4KKwkgKi8KKwl0cC0+dF91dG9fYWR2ID0gVENQVFZfVVRPX0RF RkFVTFQ7CisKKwkvKgogCSAqIElQdjQgVFRMIGluaXRpYWxpemF0aW9uIGlzIG5lY2Vzc2FyeSBm b3IgYW4gSVB2NiBzb2NrZXQgYXMgd2VsbCwKIAkgKiBiZWNhdXNlIHRoZSBzb2NrZXQgbWF5IGJl IGJvdW5kIHRvIGFuIElQdjYgd2lsZGNhcmQgYWRkcmVzcywKIAkgKiB3aGljaCBtYXkgbWF0Y2gg YW4gSVB2NC1tYXBwZWQgSVB2NiBhZGRyZXNzLgpJbmRleDogc3lzL25ldGluZXQvdGNwX3RpbWVy LmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQotLS0gc3lzL25ldGluZXQvdGNwX3RpbWVyLmMJKHJldmlzaW9uIDE5NjQ1 NSkKKysrIHN5cy9uZXRpbmV0L3RjcF90aW1lci5jCSh3b3JraW5nIGNvcHkpCkBAIC0xMTAsNyAr MTEwLDIxIEBACiBTWVNDVExfUFJPQyhfbmV0X2luZXRfdGNwLCBPSURfQVVUTywgZmlud2FpdDJf dGltZW91dCwgQ1RMVFlQRV9JTlR8Q1RMRkxBR19SVywKICAgICAmdGNwX2ZpbndhaXQyX3RpbWVv dXQsIDAsIHN5c2N0bF9tc2VjX3RvX3RpY2tzLCAiSSIsICJGSU4tV0FJVDIgdGltZW91dCIpOwog CitWTkVUX0RFRklORShpbnQsIHRjcF91dG9fbWluKTsKK1NZU0NUTF9WTkVUX1BST0MoX25ldF9p bmV0X3RjcCwgT0lEX0FVVE8sIHV0b19taW4sIENUTFRZUEVfSU5UfENUTEZMQUdfUlcsCisgICAg JlZORVRfTkFNRSh0Y3BfdXRvX21pbiksIDAsIHN5c2N0bF9tc2VjX3RvX3RpY2tzLCAiSSIsCisg ICAgIk1pbmltdW4gVXNlciBUaW1lb3V0Iik7CiAKK1ZORVRfREVGSU5FKGludCwgdGNwX3V0b19t YXgpOworU1lTQ1RMX1ZORVRfUFJPQyhfbmV0X2luZXRfdGNwLCBPSURfQVVUTywgdXRvX21heCwg Q1RMVFlQRV9JTlR8Q1RMRkxBR19SVywKKyAgICAmVk5FVF9OQU1FKHRjcF91dG9fbWF4KSwgMCwg c3lzY3RsX21zZWNfdG9fdGlja3MsICJJIiwKKyAgICAiTWF4aW11bSBVc2VyIFRpbWVvdXQiKTsK KworVk5FVF9ERUZJTkUoaW50LCB0Y3BfdXRvX2VuYWJsZSk7CitTWVNDVExfVk5FVF9JTlQoX25l dF9pbmV0X3RjcCwgT0lEX0FVVE8sIHV0b19hbHdheXMsIENUTFRZUEVfSU5UfENUTEZMQUdfUlcs CisgICAgJlZORVRfTkFNRSh0Y3BfdXRvX2VuYWJsZSksIDAsCisgICAgIkVuYWJsZSBUQ1AgVVRP IChSRkM1NDgyKSBvbiBldmVyeSBzb2NrZXQiKTsKKwogc3RhdGljIGludAl0Y3Bfa2VlcGNudCA9 IFRDUFRWX0tFRVBDTlQ7CiAJLyogbWF4IGlkbGUgcHJvYmVzICovCiBpbnQJdGNwX21heHBlcnNp c3RpZGxlOwpAQCAtNDczLDEyICs0ODcsMjAgQEAKIAl9CiAJY2FsbG91dF9kZWFjdGl2YXRlKCZ0 cC0+dF90aW1lcnMtPnR0X3JleG10KTsKIAl0Y3BfZnJlZV9zYWNraG9sZXModHApOworCisJaWYg KHRwLT50X3J4dHNoaWZ0ID09IDApIHsKKwkJVENQVF9SRVNPTFZFX1VUTyh0cCk7CisJCXRwLT50 X3V0b19sZWZ0ID0gdHAtPnRfdXRvX2ltcGwgLyBoejsKKwkJdHAtPnRfdXRvX2xlZnQgLT0gdGNw X2JhY2tvZmZbMF07CisJfQogCS8qCiAJICogUmV0cmFuc21pc3Npb24gdGltZXIgd2VudCBvZmYu ICBNZXNzYWdlIGhhcyBub3QKIAkgKiBiZWVuIGFja2VkIHdpdGhpbiByZXRyYW5zbWl0IGludGVy dmFsLiAgQmFjayBvZmYKIAkgKiB0byBhIGxvbmdlciByZXRyYW5zbWl0IGludGVydmFsIGFuZCBy ZXRyYW5zbWl0IG9uZSBzZWdtZW50LgogCSAqLwotCWlmICgrK3RwLT50X3J4dHNoaWZ0ID4gVENQ X01BWFJYVFNISUZUKSB7CisJaWYgKCgrK3RwLT50X3J4dHNoaWZ0ID4gVENQX01BWFJYVFNISUZU ICYmCisJICAgICh0cC0+dXRvX2ZsYWdzICYgVENQVVRPX0lNUEwpID09IDApIHx8CisJICAgICh0 cC0+dF91dG9fbGVmdCA9PSAwICYmIHRwLT51dG9fZmxhZ3MgJiBUQ1BVVE9fSU1QTCkpIHsKIAkJ dHAtPnRfcnh0c2hpZnQgPSBUQ1BfTUFYUlhUU0hJRlQ7CiAJCVRDUFNUQVRfSU5DKHRjcHNfdGlt ZW91dGRyb3ApOwogCQl0cCA9IHRjcF9kcm9wKHRwLCB0cC0+dF9zb2Z0ZXJyb3IgPwpAQCAtNTEw LDkgKzUzMiwyNyBAQAogCWlmICh0cC0+dF9zdGF0ZSA9PSBUQ1BTX1NZTl9TRU5UKQogCQlyZXht dCA9IFRDUF9SRVhNVFZBTCh0cCkgKiB0Y3Bfc3luX2JhY2tvZmZbdHAtPnRfcnh0c2hpZnRdOwog CWVsc2UKLQkJcmV4bXQgPSBUQ1BfUkVYTVRWQUwodHApICogdGNwX2JhY2tvZmZbdHAtPnRfcnh0 c2hpZnRdOwotCVRDUFRfUkFOR0VTRVQodHAtPnRfcnh0Y3VyLCByZXhtdCwKLQkJICAgICAgdHAt PnRfcnR0bWluLCBUQ1BUVl9SRVhNVE1BWCk7CisJCWlmICgodHAtPnV0b19mbGFncyAmIFRDUFVU T19JTVBMKSA9PSAwKSB7CisJCQlyZXhtdCA9IFRDUF9SRVhNVFZBTCh0cCkgKiB0Y3BfYmFja29m Zlt0cC0+dF9yeHRzaGlmdF07CisJCQlUQ1BUX1JBTkdFU0VUKHRwLT50X3J4dGN1ciwgcmV4bXQs IHRwLT50X3J0dG1pbiwKKwkJCSAgICBUQ1BUVl9SRVhNVE1BWCk7CisJCX0gZWxzZSB7CisJCQlp bnQgcnh0c2hpZnQsIGludGVydmFsOworCQkJcnh0c2hpZnQgPSBtaW4oVENQX01BWFJYVFNISUZU LCB0cC0+dF9yeHRzaGlmdCk7CisJCQlpbnRlcnZhbCA9IG1pbihUQ1BfUkVYTVRNQVgsIHRjcF9i YWNrb2ZmW3J4dHNoaWZ0XSk7CisJCQlyZXhtdCA9IFRDUF9SRVhNVFZBTCh0cCkgKiB0Y3BfYmFj a29mZltyeHRzaGlmdF07CisJCQlUQ1BUX1JBTkdFU0VUKHRwLT50X3J4dGN1ciwgcmV4bXQsCisJ CQkgICAgdHAtPnRfcnR0bWluLCBUQ1BUVl9SRVhNVE1BWCk7CisJCQlpZiAodHAtPnRfdXRvX2xl ZnQgPCBpbnRlcnZhbCkgeworCQkJCXRwLT50X3J4dGN1ciA9ICh0cC0+dF9yeHRjdXIgKiB0cC0+ dF91dG9fbGVmdCkKKwkJCQkgICAgLyBpbnRlcnZhbDsKKwkJCQkvKiBQcmV2ZW50IHRfcnh0Y3Vy IGZyb20gcmVhY2hpbmcgemVybyAqLworCQkJCVRDUFRfUkFOR0VTRVQodHAtPnRfcnh0Y3VyLCB0 cC0+dF9yeHRjdXIsCisJCQkJICAgIHRwLT50X3J0dG1pbiwgVENQVFZfUkVYTVRNQVgpOworCQkJ fQorCQkJdHAtPnRfdXRvX2xlZnQgLT0gbWluKHRwLT50X3V0b19sZWZ0LCBpbnRlcnZhbCk7CisJ CX0KKwogCS8qCiAJICogRGlzYWJsZSByZmMxMzIzIGlmIHdlIGhhdm4ndCBnb3QgYW55IHJlc3Bv bnNlIHRvCiAJICogb3VyIHRoaXJkIFNZTiB0byB3b3JrLWFyb3VuZCBzb21lIGJyb2tlbiB0ZXJt aW5hbCBzZXJ2ZXJzCkluZGV4OiBzeXMvbmV0aW5ldC90Y3BfdGltZXIuaAo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0t LSBzeXMvbmV0aW5ldC90Y3BfdGltZXIuaAkocmV2aXNpb24gMTk2NDU1KQorKysgc3lzL25ldGlu ZXQvdGNwX3RpbWVyLmgJKHdvcmtpbmcgY29weSkKQEAgLTkxLDYgKzkxLDEwIEBACiAKICNkZWZp bmUgVENQVFZfRklOV0FJVDJfVElNRU9VVCAoNjAqaHopICAgICAgICAgLyogRklOX1dBSVRfMiB0 aW1lb3V0IGlmIG5vIHJlY2VpdmVyICovCiAKKyNkZWZpbmUJVENQVFZfVVRPX01JTgkJKCAxMjAq aHopCS8qIG1pbiB1c2VyIHRpbWVvdXQgKi8KKyNkZWZpbmUJVENQVFZfVVRPX01BWAkJKDEwMjAq aHopCS8qIG1heCB1c2VyIHRpbWVvdXQgKi8KKyNkZWZpbmUJVENQVFZfVVRPX0RFRkFVTFQJKCA1 MTEqaHopCS8qIGRlZmF1bHQgdXNlciB0aW1lb3V0ICovCisKIC8qCiAgKiBNaW5pbXVtIHJldHJh bnNtaXQgdGltZXIgaXMgMyB0aWNrcywgZm9yIGFsZ29yaXRobWljIHN0YWJpbGl0eS4KICAqIFRD UFRfUkFOR0VTRVQoKSB3aWxsIGFkZCBhbm90aGVyIFRDUFRWX0NQVV9WQVIgdG8gZGVhbCB3aXRo CkBAIC0xMTMsOCArMTE3LDkgQEAKICAqLwogI2RlZmluZQlUQ1BUVl9NSU4JKCBoei8zMyApCQkv KiBtaW5pbXVtIGFsbG93YWJsZSB2YWx1ZSAqLwogI2RlZmluZSBUQ1BUVl9DUFVfVkFSCSggaHov NSApCQkvKiBjcHUgdmFyaWFuY2UgYWxsb3dlZCAoMjAwbXMpICovCi0jZGVmaW5lCVRDUFRWX1JF WE1UTUFYCSggNjQqaHopCQkvKiBtYXggYWxsb3dhYmxlIFJFWE1UIHZhbHVlICovCi0KKyNkZWZp bmUJVENQX1JFWE1UTUFYCTY0CQkJLyogbWF4IGFsbG93YWJsZSBSRVhNVCB2YWx1ZQorCQkJCQkJ ICAgaW4gc2Vjb25kcyAqLworI2RlZmluZQlUQ1BUVl9SRVhNVE1BWAkoIFRDUF9SRVhNVE1BWCpo eiApCS8qIG1heCBhbGxvd2FibGUgUkVYTVQgdmFsdWUgKi8KICNkZWZpbmUgVENQVFZfVFdUUlVO Qwk4CQkJLyogUlRPIGZhY3RvciB0byB0cnVuY2F0ZSBUVyAqLwogCiAjZGVmaW5lCVRDUF9MSU5H RVJUSU1FCTEyMAkJCS8qIGxpbmdlciBhdCBtb3N0IDIgbWludXRlcyAqLwpAQCAtMTY4LDcgKzE3 Myw2IEBACiAKIGV4dGVybiBpbnQgdGNwX2ZpbndhaXQyX3RpbWVvdXQ7CiBleHRlcm4gaW50IHRj cF9mYXN0X2ZpbndhaXQyX3JlY3ljbGU7Ci0KIHZvaWQJdGNwX3RpbWVyX2luaXQodm9pZCk7CiB2 b2lkCXRjcF90aW1lcl8ybXNsKHZvaWQgKnh0cCk7CiBzdHJ1Y3QgdGNwdHcgKgpJbmRleDogc3lz L25ldGluZXQvdGNwX3Zhci5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXRpbmV0L3RjcF92YXIuaAko cmV2aXNpb24gMTk2NDU1KQorKysgc3lzL25ldGluZXQvdGNwX3Zhci5oCSh3b3JraW5nIGNvcHkp CkBAIC0yMDAsOSArMjAwLDIxIEBACiAJdm9pZAkqdF90b2U7CQkJLyogVE9FIHBjYiBwb2ludGVy ICovCiAJaW50CXRfYnl0ZXNfYWNrZWQ7CQkvKiAjIGJ5dGVzIGFja2VkIGR1cmluZyBjdXJyZW50 IFJUVCAqLwogCi0JaW50CXRfaXNwYXJlOwkJLyogZXhwbGljaXQgcGFkIGZvciA2NGJpdCBhbGln bm1lbnQgKi8KKwkvKiBUQ1AgVXNlciBUaW1lb3V0IHZhcmlhYmxlcyAoUkZDIDU0ODIpICovCisg CXVpbnQxNl90IHJjdl91dG87CQkvKiByZWNlaXZlZCB1c2VyIHRpbWVvdXQgKi8KKyAJdWludDE2 X3Qgc25kX3V0bzsJCS8qIHNlbmQgdXNlciB0aW1lb3V0ICovCisgCXVpbnQ4X3QJdXRvX2ZsYWdz OworCS8qIEFsbCB2YWx1ZXMgaW4gdGlja3MgKi8KKyAJdV9pbnQJdF91dG9fYWR2OwkJLyogdXNl ciB0aW1lb3V0IHNlbnQgdG8gcmVtb3RlIHBlZXIKKwkJCQkJICAgKHRpY2tzKSAqLworIAl1X2lu dAl0X3V0b19pbXBsOwkJLyogaW1wbGVtZW50ZWQgdXNlciB0aW1lb3V0ICh0aWNrcykgKi8KKyAJ dV9pbnQJdF91dG9fbGVmdDsJCS8qIHJlbWFpbmVkIHVzZXIgdGltZW91dCB2YWx1ZQorCQkJCQkg ICAoc2Vjb25kcykgKi8KKyAJdGNwX3NlcQl1dG9fY2FycmllcjsJCS8qIG1heCBzZXF1ZW5jZSBu dW1iZXIgdGhhdCBjYXJyeSB1c2VyCisJCQkJCSAgIHRpbWVvdXQgKi8KKwogCXZvaWQJKnRfcHNw YXJlMls2XTsJCS8qIDIgQ0MgLyA0IFRCRCAqLwotCXVpbnQ2NF90IF9wYWRbMTJdOwkJLyogNyBV VE8sIDUgVEJEICgxLTIgQ0MvUlRUPykgKi8KKwl1aW50NjRfdCBfcGFkWzhdOwkJLyogNyBUQkQg KDEtMiBDQy9SVFQ/KSAqLwogfTsKIAogLyoKQEAgLTI0NSw2ICsyNTcsMzUgQEAKICNkZWZpbmUJ VENQT09CX0hBVkVEQVRBCTB4MDEKICNkZWZpbmUJVENQT09CX0hBRERBVEEJMHgwMgogCisvKgor ICogRmxhZ3MgZm9yIHRoZSB1dG9fZmxhZ3MgZmllbGQuCisgKi8KKyNkZWZpbmUJVENQVVRPX0VO QUJMRQkweDAxCS8qIGVuYWJsZSB0Y3AgdXNlciB0aW1lb3V0ICovCisjZGVmaW5lCVRDUFVUT19D SEFOR0VBQkxFIDB4MDIJLyogdXNlciB0aW1lb3V0IGNhbiBiZSBjaGFuZ2VkIGJ5IG90aGVyIHNp ZGUgKi8KKyNkZWZpbmUJVENQVVRPX0lNUEwJMHgwNAkvKiBpbXBsZW1lbnQgdXNlciB0aW1lb3V0 ICovCisjZGVmaW5lCVRDUFVUT19SQ1ZECTB4MDgJLyogb3RoZXIgc2lkZSBoYXMgcmVxdWVzdGVk IHVzZXIgdGltZW91dCAqLworI2RlZmluZQlUQ1BVVE9fTkVFRAkweDEwCS8qIHVzZXIgdGltZW91 dCBuZWVkcyB0byBiZSBzZW50ICovCisjZGVmaW5lCVRDUFVUT19TRU5ESU5HCTB4MjAJLyogdXNl ciB0aW1lb3V0IGlzIGluIHRoZSBwcm9jZXNzIG9mIHNlbmRpbmcgKi8KKworLyoKKyAqIFJlc29s dmUgdXNlciB0aW1lb3V0IHZhbHVlKHRpY2tzKS4KKyovCisjZGVmaW5lCVRDUFRfUkVTT0xWRV9V VE8odHApIGRvIHsJCQkJXAorCWlmICgodHApLT51dG9fZmxhZ3MgJiBUQ1BVVE9fRU5BQkxFICYm CQkJXAorCSAgICAodHApLT51dG9fZmxhZ3MgJiBUQ1BVVE9fUkNWRCAmJgkJCVwKKwkgICAgKHRw KS0+dXRvX2ZsYWdzICYgVENQVVRPX0NIQU5HRUFCTEUpIHsJCVwKKwkJKHRwKS0+dF91dG9faW1w bCA9ICh0cCktPnJjdl91dG8gPj4gMTsJCVwKKwkJaWYgKCh0cCktPnJjdl91dG8gJiAxKQkJCQlc CisJCQkodHApLT50X3V0b19pbXBsICo9IDYwOwkJCVwKKwkJKHRwKS0+dF91dG9faW1wbCAqPSBo ejsJCQkJXAorCQkodHApLT50X3V0b19pbXBsID0gbWluKHRjcF91dG9fbWF4LAkJXAorCQkgICAg bWF4KCh0cCktPnRfdXRvX2FkdiwJCQlcCisJCSAgICBtYXgoKHRwKS0+dF91dG9faW1wbCwgdGNw X3V0b19taW4pKSk7CVwKKwkJKHRwKS0+dXRvX2ZsYWdzICY9IH5UQ1BVVE9fUkNWRDsJCVwKKwkJ KHRwKS0+dXRvX2ZsYWdzIHw9IFRDUFVUT19JTVBMOwkJCVwKKwl9CQkJCQkJCVwKK30gd2hpbGUo MCkKKwogI2lmZGVmIFRDUF9TSUdOQVRVUkUKIC8qCiAgKiBEZWZpbmVzIHdoaWNoIGFyZSBuZWVk ZWQgYnkgdGhlIHhmb3JtX3RjcCBtb2R1bGUgYW5kIHRjcF9baW58b3V0XXB1dApAQCAtMjc2LDcg KzMxNyw4IEBACiAjZGVmaW5lCVRPRl9UUwkJMHgwMDEwCQkvKiB0aW1lc3RhbXAgKi8KICNkZWZp bmUJVE9GX1NJR05BVFVSRQkweDAwNDAJCS8qIFRDUC1NRDUgc2lnbmF0dXJlIG9wdGlvbiAoUkZD MjM4NSkgKi8KICNkZWZpbmUJVE9GX1NBQ0sJMHgwMDgwCQkvKiBQZWVyIHNlbnQgU0FDSyBvcHRp b24gKi8KLSNkZWZpbmUJVE9GX01BWE9QVAkweDAxMDAKKyNkZWZpbmUJVE9GX1VUTwkJMHgwMTAw CQkvKiB1c2VyIHRpbWVvdXQgKFJGQzU0ODIpICovCisjZGVmaW5lCVRPRl9NQVhPUFQJMHgwMjAw CiAJdV9pbnQzMl90CXRvX3RzdmFsOwkvKiBuZXcgdGltZXN0YW1wICovCiAJdV9pbnQzMl90CXRv X3RzZWNyOwkvKiByZWZsZWN0ZWQgdGltZXN0YW1wICovCiAJdV9jaGFyCQkqdG9fc2Fja3M7CS8q IHBvaW50ZXIgdG8gdGhlIGZpcnN0IFNBQ0sgYmxvY2tzICovCkBAIC0yODQsNiArMzI2LDcgQEAK IAl1X2ludDE2X3QJdG9fbXNzOwkJLyogbWF4aW11bSBzZWdtZW50IHNpemUgKi8KIAl1X2ludDhf dAl0b193c2NhbGU7CS8qIHdpbmRvdyBzY2FsaW5nICovCiAJdV9pbnQ4X3QJdG9fbnNhY2tzOwkv KiBudW1iZXIgb2YgU0FDSyBibG9ja3MgKi8KKwl1X2ludDE2X3QJdG9fdXRvOwkJLyogVVRPIG9w dGlvbiAoUkZDNTQ4MikgKi8KIH07CiAKIC8qCkBAIC0zOTUsNiArNDM4LDcgQEAKIAl1X2xvbmcJ dGNwc19zbmR1cmc7CQkvKiBwYWNrZXRzIHNlbnQgd2l0aCBVUkcgb25seSAqLwogCXVfbG9uZwl0 Y3BzX3NuZHdpbnVwOwkJLyogd2luZG93IHVwZGF0ZS1vbmx5IHBhY2tldHMgc2VudCAqLwogCXVf bG9uZwl0Y3BzX3NuZGN0cmw7CQkvKiBjb250cm9sIChTWU58RklOfFJTVCkgcGFja2V0cyBzZW50 ICovCisJdV9sb25nCXRjcHNfc25kdXRvOwkJLyogcGFja2V0cyBzZW50IHdpdGggdGNwIFVUTyBv cHRpb24gKi8KIAogCXVfbG9uZwl0Y3BzX3JjdnRvdGFsOwkJLyogdG90YWwgcGFja2V0cyByZWNl aXZlZCAqLwogCXVfbG9uZwl0Y3BzX3JjdnBhY2s7CQkvKiBwYWNrZXRzIHJlY2VpdmVkIGluIHNl cXVlbmNlICovCkBAIC00MTgsNiArNDYyLDcgQEAKIAl1X2xvbmcJdGNwc19yY3ZhY2twYWNrOwkv KiByY3ZkIGFjayBwYWNrZXRzICovCiAJdV9sb25nCXRjcHNfcmN2YWNrYnl0ZTsJLyogYnl0ZXMg YWNrZWQgYnkgcmN2ZCBhY2tzICovCiAJdV9sb25nCXRjcHNfcmN2d2ludXBkOwkJLyogcmN2ZCB3 aW5kb3cgdXBkYXRlIHBhY2tldHMgKi8KKwl1X2xvbmcJdGNwc19yY3Z1dG87CQkvKiBwYWNrZXRz IHJlY2VpdmVkIHdpdGggdGNwIFVUTyBvcHRpb24gKi8KIAl1X2xvbmcJdGNwc19wYXdzZHJvcDsJ CS8qIHNlZ21lbnRzIGRyb3BwZWQgZHVlIHRvIFBBV1MgKi8KIAl1X2xvbmcJdGNwc19wcmVkYWNr OwkJLyogdGltZXMgaGRyIHByZWRpY3Qgb2sgZm9yIGFja3MgKi8KIAl1X2xvbmcJdGNwc19wcmVk ZGF0OwkJLyogdGltZXMgaGRyIHByZWRpY3Qgb2sgZm9yIGRhdGEgcGt0cyAqLwpAQCAtNjE2LDYg KzY2MSw5IEBACiBWTkVUX0RFQ0xBUkUoaW50LCB0Y3Bfc2NfcnN0X3NvY2tfZmFpbCk7CS8qIFJT VCBvbiBzb2NrIGFsbG9jIGZhaWx1cmUgKi8KIFZORVRfREVDTEFSRShpbnQsIHRjcF9kb19lY24p OwkJCS8qIFRDUCBFQ04gZW5hYmxlZC9kaXNhYmxlZCAqLwogVk5FVF9ERUNMQVJFKGludCwgdGNw X2Vjbl9tYXhyZXRyaWVzKTsKK1ZORVRfREVDTEFSRShpbnQsIHRjcF91dG9fbWluKTsKK1ZORVRf REVDTEFSRShpbnQsIHRjcF91dG9fbWF4KTsKK1ZORVRfREVDTEFSRShpbnQsIHRjcF91dG9fZW5h YmxlKTsKIAogI2RlZmluZQlWX3RjcF9kb19zYWNrCQlWTkVUKHRjcF9kb19zYWNrKQogI2RlZmlu ZQlWX3RjcF9zYWNrX21heGhvbGVzCVZORVQodGNwX3NhY2tfbWF4aG9sZXMpCkBAIC02MjQsNiAr NjcyLDkgQEAKICNkZWZpbmUJVl90Y3Bfc2NfcnN0X3NvY2tfZmFpbAlWTkVUKHRjcF9zY19yc3Rf c29ja19mYWlsKQogI2RlZmluZQlWX3RjcF9kb19lY24JCVZORVQodGNwX2RvX2VjbikKICNkZWZp bmUJVl90Y3BfZWNuX21heHJldHJpZXMJVk5FVCh0Y3BfZWNuX21heHJldHJpZXMpCisjZGVmaW5l CVZfdGNwX3V0b19taW4JCVZORVQodGNwX3V0b19taW4pCisjZGVmaW5lCVZfdGNwX3V0b19tYXgJ CVZORVQodGNwX3V0b19tYXgpCisjZGVmaW5lCVZfdGNwX3V0b19lbmFibGUJVk5FVCh0Y3BfdXRv X2VuYWJsZSkKIAogaW50CSB0Y3BfYWRkb3B0aW9ucyhzdHJ1Y3QgdGNwb3B0ICosIHVfY2hhciAq KTsKIHN0cnVjdCB0Y3BjYiAqCkluZGV4OiBzeXMvbmV0aW5ldC90Y3Bfb3V0cHV0LmMKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQotLS0gc3lzL25ldGluZXQvdGNwX291dHB1dC5jCShyZXZpc2lvbiAxOTY0NTUpCisrKyBz eXMvbmV0aW5ldC90Y3Bfb3V0cHV0LmMJKHdvcmtpbmcgY29weSkKQEAgLTY5NCw5ICs2OTQsNDAg QEAKIAkJaWYgKHRwLT50X2ZsYWdzICYgVEZfU0lHTkFUVVJFKQogCQkJdG8udG9fZmxhZ3MgfD0g VE9GX1NJR05BVFVSRTsKICNlbmRpZiAvKiBUQ1BfU0lHTkFUVVJFICovCisJCS8qCisJCSAqIFdl IHNldCB0aGUgVVRPIG9wdGlvbiBpbiBUQ1AgaGVhZGVyIGluIHR3byBjYXNlczogdGhlCisJCSAq IHNlZ21lbnQgaGFzIGEgU1lOLCBhIFNZTiB8IEFDSywgb3IgYSBub3JtYWwgZGF0YSBzZWdtZW50 LgorCQkgKi8KKwkJaWYgKGZsYWdzICYgVEhfU1lOIHx8CisJCSAgICAobGVuICYmICh0cC0+dF9m bGFncyAmIFRGX0ZPUkNFREFUQSkgPT0gMCkpCisJCQlpZiAodHAtPnV0b19mbGFncyAmIChUQ1BV VE9fTkVFRCB8IFRDUFVUT19TRU5ESU5HKSkgeworCQkJCXRvLnRvX3V0byA9IHRwLT5zbmRfdXRv OworCQkJCXRvLnRvX2ZsYWdzIHw9IFRPRl9VVE87CisJCQl9CiAKIAkJLyogUHJvY2Vzc2luZyB0 aGUgb3B0aW9ucy4gKi8KIAkJaGRybGVuICs9IG9wdGxlbiA9IHRjcF9hZGRvcHRpb25zKCZ0bywg b3B0KTsKKworCQkvKiAKKwkJICogQWNjb3JkaW5nIHRvIFJGQyA1NDgyOgorCQkgKiAiSW4gYWRk aXRpb24gdG8gZXhjaGFuZ2luZyBVVE8gb3B0aW9ucyBpbiB0aGUgU1lOIHNlZ21lbnRzLAorCQkg KiAgYSBjb25uZWN0aW9uIHRoYXQgaGFzIGVuYWJsZWQgVVRPIG9wdGlvbnMgU0hPVUxEIGluY2x1 ZGUgYQorCQkgKiAgVVRPIG9wdGlvbiBpbiB0aGUgZmlyc3QgcGFja2V0IHRoYXQgZG9lcyBub3Qg aGF2ZSB0aGUgU1lOCisJCSAqICBmbGFnIHNldC4gVGhpcyBoZWxwcyAgdG8gbWluaW1pemUgdGhl IGFtb3VudCBvZiBzdGF0ZQorCQkgKiAgaW5mb3JtYXRpb24gVENQIG11c3Qga2VlcCBmb3IgIGNv bm5lY3Rpb25zIGluCisJCSAqICBub24tc3luY2hyb25pemVkIHN0YXRlcy4iIAorCQkgKiBTbyBl dmVuIHRob3VnaCB0aGUgVVRPIG9wdGlvbiBpcyBzZXQgaW4gdGhlIFNZTiBzZWdtZW50LAorCQkg KiB3ZSB3ZSBzaGFsbCByZXRyYW5zbWl0IGl0LgorCQkgKi8KKwkJaWYgKHRwLT51dG9fZmxhZ3Mg JiAoVENQVVRPX05FRUQgfCBUQ1BVVE9fU0VORElORykgJiYKKwkJICAgICh0by50b19mbGFncyAm IFRPRl9VVE8pID09IDApIHsKKwkJCWlmICgoZmxhZ3MgJiBUSF9TWU4pID09IDApIHsKKwkJCQl0 cC0+dXRvX2ZsYWdzICY9IH4oVENQVVRPX05FRUQgfCBUQ1BVVE9fU0VORElORyk7CisJCQkJdHAt PnV0b19mbGFncyB8PSBUQ1BVVE9fU0VORElORzsKKwkJCQl0cC0+dXRvX2NhcnJpZXIgPSB0cC0+ c25kX254dCArIGxlbjsKKwkJCX0KKwkJCVRDUFNUQVRfSU5DKHRjcHNfc25kdXRvKTsKKwkJfQog CX0KIAogI2lmZGVmIElORVQ2CkBAIC0xMzIzLDYgKzEzNTQsMTEgQEAKICAqIEF0IG1pbmltdW0g d2UgbmVlZCAxMCBieXRlcyAodG8gZ2VuZXJhdGUgMSBTQUNLIGJsb2NrKS4gIElmIGJvdGgKICAq IFRDUCBUaW1lc3RhbXBzICgxMiBieXRlcykgYW5kIFRDUCBTaWduYXR1cmVzICgxOCBieXRlcykg YXJlIHByZXNlbnQsCiAgKiB3ZSBvbmx5IGhhdmUgMTAgYnl0ZXMgZm9yIFNBQ0sgb3B0aW9ucyAo NDAgLSAoMTIgKyAxOCkpLgorICogCisgKiBUQ1Agb3B0aW9uIFVUTyAodXNlciB0aW1lb3V0LCBk ZWZpbmVkIGluIFJGQyA1NDgyKSwgaXMgYW4gb3B0aW9uYWwgb3B0aW9uCisgKiB0aGF0IGNvbnN1 bWVzIDQgYnl0ZXMuIFdlIGF0dGFjaCB0aGUgVVRPIG9wdGlvbiBvbmx5IHdoZW4gdGhlcmUgaXMg ZW5vdWdoCisgKiBmcmVlIHNwYWNlIGluIHRoZSBUQ1AgaGVhZGVyLgorICogQWx0aG91Z2ggVVRP IGlzIG9wdGlvbmFsLCB3ZSBzaG91bGQgdHJ5IG91ciBiZXN0IHRvIHRyYW5zbWl0IGl0LgogICov CiBpbnQKIHRjcF9hZGRvcHRpb25zKHN0cnVjdCB0Y3BvcHQgKnRvLCB1X2NoYXIgKm9wdHApCkBA IC0xNDM3LDYgKzE0NzMsMTkgQEAKIAkJCVRDUFNUQVRfSU5DKHRjcHNfc2Fja19zZW5kX2Jsb2Nr cyk7CiAJCQlicmVhazsKIAkJCX0KKwkJY2FzZSBUT0ZfVVRPOgorCQkJeworCQkJaWYgKFRDUF9N QVhPTEVOIC0gb3B0bGVuIDwgVENQT0xFTl9VVE8pCisJCQkJY29udGludWU7CisJCQkqb3B0cCsr ID0gVENQT1BUX1VUTzsKKwkJCSpvcHRwKysgPSBUQ1BPTEVOX1VUTzsKKwkJCW9wdGxlbiArPSBU Q1BPTEVOX1VUTzsKKwkJCXRvLT50b191dG8gPSBodG9ucyh0by0+dG9fdXRvKTsKKwkJCWJjb3B5 KCh1X2NoYXIgKikmdG8tPnRvX3V0bywgb3B0cCwgc2l6ZW9mKHRvLT50b191dG8pKTsKKwkJCW9w dHAgKz0gc2l6ZW9mKHRvLT50b191dG8pOworCQkJdG8tPnRvX2ZsYWdzICY9IH5UT0ZfVVRPOwor CQkJYnJlYWs7CisJCQl9CiAJCWRlZmF1bHQ6CiAJCQlwYW5pYygiJXM6IHVua25vd24gVENQIG9w dGlvbiB0eXBlIiwgX19mdW5jX18pOwogCQkJYnJlYWs7CkluZGV4OiBzeXMvbmV0aW5ldC90Y3Au aAo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09Ci0tLSBzeXMvbmV0aW5ldC90Y3AuaAkocmV2aXNpb24gMTk2NDU1KQorKysg c3lzL25ldGluZXQvdGNwLmgJKHdvcmtpbmcgY29weSkKQEAgLTk2LDYgKzk2LDggQEAKICNkZWZp bmUgICAgVENQT0xFTl9UU1RBTVBfQVBQQQkJKFRDUE9MRU5fVElNRVNUQU1QKzIpIC8qIGFwcGVu ZGl4IEEgKi8KICNkZWZpbmUJVENQT1BUX1NJR05BVFVSRQkxOQkJLyogS2V5ZWQgTUQ1OiBSRkMg MjM4NSAqLwogI2RlZmluZQkgICBUQ1BPTEVOX1NJR05BVFVSRQkJMTgKKyNkZWZpbmUJVENQT1BU X1VUTwkJMjgKKyNkZWZpbmUJICAgVENQT0xFTl9VVE8JCQk0CiAKIC8qIE1pc2NlbGxhbmVvdXMg Y29uc3RhbnRzICovCiAjZGVmaW5lCU1BWF9TQUNLX0JMS1MJNgkvKiBNYXggIyBTQUNLIGJsb2Nr cyBzdG9yZWQgYXQgcmVjZWl2ZXIgc2lkZSAqLwpAQCAtMTUwLDYgKzE1MiwxNCBAQAogI2RlZmlu ZSBUQ1BfTUQ1U0lHCTB4MTAJLyogdXNlIE1ENSBkaWdlc3RzIChSRkMyMzg1KSAqLwogI2RlZmlu ZQlUQ1BfSU5GTwkweDIwCS8qIHJldHJpZXZlIHRjcF9pbmZvIHN0cnVjdHVyZSAqLwogI2RlZmlu ZQlUQ1BfQ09OR0VTVElPTgkweDQwCS8qIGdldC9zZXQgY29uZ2VzdGlvbiBjb250cm9sIGFsZ29y aXRobSAqLworI2RlZmluZQlUQ1BfVVRPCQkweDgwCS8qIHNldCB0Y3AgdXNlciB0aW1lb3V0ICov CitzdHJ1Y3QgdGNwdXRvIHsKKwlpbnQJdXRvOworCWludAlmbGFnczsKK307CisjZGVmaW5lCVRD UF9VVE9fU1RPUkUJCTB4MDEKKyNkZWZpbmUJVENQX1VUT19FTkFCTEUJCTB4MDIKKyNkZWZpbmUJ VENQX1VUT19DSEFOR0UJCTB4MDQKIAogI2RlZmluZQlUQ1BfQ0FfTkFNRV9NQVgJMTYJLyogbWF4 IGNvbmdlc3Rpb24gY29udHJvbCBuYW1lIGxlbmd0aCAqLwogCkBAIC0xNTgsNiArMTY4LDcgQEAK ICNkZWZpbmUJVENQSV9PUFRfV1NDQUxFCQkweDA0CiAjZGVmaW5lCVRDUElfT1BUX0VDTgkJMHgw OAogI2RlZmluZQlUQ1BJX09QVF9UT0UJCTB4MTAKKyNkZWZpbmUJVENQSV9PUFRfVVRPCQkweDIw CiAKIC8qCiAgKiBUaGUgVENQX0lORk8gc29ja2V0IG9wdGlvbiBjb21lcyBmcm9tIHRoZSBMaW51 eCAyLjYgVENQIEFQSSwgYW5kIHBlcm1pdHMKQEAgLTIxNyw5ICsyMjgsMTAgQEAKIAl1X2ludDMy X3QJdGNwaV9zbmRfbnh0OwkJLyogTmV4dCBlZ3Jlc3Mgc2Vxbm8gKi8KIAl1X2ludDMyX3QJdGNw aV9yY3Zfbnh0OwkJLyogTmV4dCBpbmdyZXNzIHNlcW5vICovCiAJdV9pbnQzMl90CXRjcGlfdG9l X3RpZDsJCS8qIEhXVElEIGZvciBUT0UgZW5kcG9pbnRzICovCi0JCisJdV9pbnQzMl90CXRjcGlf dXRvOwkJLyogdGNwIHVzZXIgdGltZW91dCB2YWx1ZSAqLworCiAJLyogUGFkZGluZyB0byBncm93 IHdpdGhvdXQgYnJlYWtpbmcgQUJJLiAqLwotCXVfaW50MzJfdAlfX3RjcGlfcGFkWzI5XTsJCS8q IFBhZGRpbmcuICovCisJdV9pbnQzMl90CV9fdGNwaV9wYWRbMjhdOwkJLyogUGFkZGluZy4gKi8K IH07CiAjZW5kaWYKIApJbmRleDogc3lzL25ldGluZXQvdGNwX3N5bmNhY2hlLmMKPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQotLS0gc3lzL25ldGluZXQvdGNwX3N5bmNhY2hlLmMJKHJldmlzaW9uIDE5NjQ1NSkKKysrIHN5 cy9uZXRpbmV0L3RjcF9zeW5jYWNoZS5jCSh3b3JraW5nIGNvcHkpCkBAIC03NzQsNiArNzc0LDEw IEBACiAjZW5kaWYKIAkJaWYgKHNjLT5zY19mbGFncyAmIFNDRl9TQUNLKQogCQkJdHAtPnRfZmxh Z3MgfD0gVEZfU0FDS19QRVJNSVQ7CisJCWlmIChzYy0+c2NfZmxhZ3MgJiBTQ0ZfVVRPKSB7CisJ CQl0cC0+dXRvX2ZsYWdzIHw9IFRDUFVUT19SQ1ZEOworCQkJdHAtPnJjdl91dG8gPSBzYy0+c2Nf cGVlcl91dG87CisJCX0KIAl9CiAKIAlpZiAoc2MtPnNjX2ZsYWdzICYgU0NGX0VDTikKQEAgLTEy MTIsNiArMTIxNiwxMSBAQAogCQlzYy0+c2NfZmxhZ3MgfD0gU0NGX05PT1BUOwogCWlmICgodGgt PnRoX2ZsYWdzICYgKFRIX0VDRXxUSF9DV1IpKSAmJiBWX3RjcF9kb19lY24pCiAJCXNjLT5zY19m bGFncyB8PSBTQ0ZfRUNOOworCWlmICh0by0+dG9fZmxhZ3MgJiBUT0ZfVVRPKSB7CisJCXNjLT5z Y19wZWVyX3V0byA9IHRvLT50b191dG87CisJCXNjLT5zY19mbGFncyB8PSBTQ0ZfVVRPOworCQlU Q1BTVEFUX0lOQyh0Y3BzX3JjdnV0byk7CisJfQogCiAJaWYgKFZfdGNwX3N5bmNvb2tpZXMpIHsK IAkJc3luY29va2llX2dlbmVyYXRlKHNjaCwgc2MsICZmbG93dG1wKTsKSW5kZXg6IHN5cy9uZXRp bmV0L3RjcF9zeW5jYWNoZS5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXRpbmV0L3RjcF9zeW5jYWNo ZS5oCShyZXZpc2lvbiAxOTY0NTUpCisrKyBzeXMvbmV0aW5ldC90Y3Bfc3luY2FjaGUuaAkod29y a2luZyBjb3B5KQpAQCAtNzQsNiArNzQsNyBAQAogCXVfaW50OF90CXNjX2lwX3RvczsJCS8qIElQ djQgVE9TICovCiAJdV9pbnQ4X3QJc2NfcmVxdWVzdGVkX3Nfc2NhbGU6NCwKIAkJCXNjX3JlcXVl c3RlZF9yX3NjYWxlOjQ7CisJdV9pbnQxNl90CXNjX3BlZXJfdXRvOwkJLyogcGVlcidzIHVzZXIg dGltZW91dCAqLwogCXVfaW50MTZfdAlzY19mbGFnczsKICNpZm5kZWYgVENQX09GRkxPQURfRElT QUJMRQogCXN0cnVjdCB0b2VfdXNycmVxcyAqc2NfdHU7CQkvKiBUT0Ugb3BlcmF0aW9ucyAqLwpA QCAtOTQsNiArOTUsNyBAQAogI2RlZmluZSBTQ0ZfU0lHTkFUVVJFCTB4MjAJCQkvKiBzZW5kIE1E NSBkaWdlc3RzICovCiAjZGVmaW5lIFNDRl9TQUNLCTB4ODAJCQkvKiBzZW5kIFNBQ0sgb3B0aW9u ICovCiAjZGVmaW5lIFNDRl9FQ04JCTB4MTAwCQkJLyogc2VuZCBFQ04gc2V0dXAgcGFja2V0ICov CisjZGVmaW5lIFNDRl9VVE8JCTB4MjAwCQkJLyogVVRPIG9wdGlvbiByZWNlaXZlZCAqLwogCiAj ZGVmaW5lCVNZTkNPT0tJRV9TRUNSRVRfU0laRQk4CS8qIGR3b3JkcyAqLwogI2RlZmluZQlTWU5D T09LSUVfTElGRVRJTUUJMTYJLyogc2Vjb25kcyAqLwpJbmRleDogc3lzL25ldGluZXQvdGNwX3Vz cnJlcS5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXRpbmV0L3RjcF91c3JyZXEuYwkocmV2aXNpb24g MTk2NDU1KQorKysgc3lzL25ldGluZXQvdGNwX3VzcnJlcS5jCSh3b3JraW5nIGNvcHkpCkBAIC0x MTk4LDYgKzExOTgsMTEgQEAKIAkJdGktPnRjcGlfb3B0aW9ucyB8PSBUQ1BJX09QVF9XU0NBTEU7 CiAJCXRpLT50Y3BpX3NuZF93c2NhbGUgPSB0cC0+c25kX3NjYWxlOwogCQl0aS0+dGNwaV9yY3Zf d3NjYWxlID0gdHAtPnJjdl9zY2FsZTsKKwl9CQorCVRDUFRfUkVTT0xWRV9VVE8odHApOworCWlm ICh0cC0+dXRvX2ZsYWdzICYgVENQVVRPX0lNUEwpIHsKKwkJdGktPnRjcGlfb3B0aW9ucyB8PSBU Q1BJX09QVF9VVE87CisJCXRpLT50Y3BpX3V0byA9IHRwLT50X3V0b19pbXBsIC8gaHo7CiAJfQog CiAJdGktPnRjcGlfcnR0ID0gKCh1X2ludDY0X3QpdHAtPnRfc3J0dCAqIHRpY2spID4+IFRDUF9S VFRfU0hJRlQ7CkBAIC0xMjQyLDYgKzEyNDcsNyBAQAogCXN0cnVjdAlpbnBjYiAqaW5wOwogCXN0 cnVjdAl0Y3BjYiAqdHA7CiAJc3RydWN0CXRjcF9pbmZvIHRpOworCXN0cnVjdAl0Y3B1dG8gdHU7 CiAKIAllcnJvciA9IDA7CiAJaW5wID0gc290b2lucGNiKHNvKTsKQEAgLTEzNTEsNiArMTM1Nyw1 MyBAQAogCQkJZXJyb3IgPSBFSU5WQUw7CiAJCQlicmVhazsKIAorCQljYXNlIFRDUF9VVE86CisJ CQlJTlBfV1VOTE9DSyhpbnApOworCQkJZXJyb3IgPSBzb29wdGNvcHlpbihzb3B0LCAmdHUsIHNp emVvZiB0dSwKKwkJCSAgICBzaXplb2YgdHUpOworCQkJaWYgKGVycm9yKQorCQkJCXJldHVybiAo ZXJyb3IpOworCisJCQlJTlBfV0xPQ0tfUkVDSEVDSyhpbnApOworCQkJaWYgKHR1LmZsYWdzICYg fihUQ1BfVVRPX0VOQUJMRSB8IFRDUF9VVE9fU1RPUkUgfAorCQkJICAgIFRDUF9VVE9fQ0hBTkdF KSkgeworCQkJCWVycm9yID0gRUlOVkFMOworCQkJCWJyZWFrOworCQkJfQorCQkJaWYgKHR1LmZs YWdzICYgVENQX1VUT19FTkFCTEUpCisJCQkJdHAtPnV0b19mbGFncyB8PSBUQ1BVVE9fRU5BQkxF OworCQkJaWYgKHR1LmZsYWdzICYgVENQX1VUT19TVE9SRSkgeworCQkJCXRwLT51dG9fZmxhZ3Mg fD0gVENQVVRPX05FRUQ7CisJCQkJaWYgKHR1LnV0byA+IDAgJiYgdHUudXRvIDw9IDB4N0ZGRiAq IDYwKSB7CisJCQkJCWlmICh0dS51dG8gPiAweDdGRkYpIHsKKwkJCQkJCXRwLT5zbmRfdXRvID0g dHUudXRvIC8gNjA7CisJCQkJCQl0cC0+c25kX3V0byA8PD0gMTsKKwkJCQkJCXRwLT5zbmRfdXRv IHw9IDE7CisJCQkJCX0gZWxzZSB7CisJCQkJCQl0cC0+c25kX3V0byA9IHR1LnV0bzsKKwkJCQkJ CXRwLT5zbmRfdXRvIDw8PSAxOworCQkJCQl9CisJCQkJCWlmICh0cC0+dXRvX2ZsYWdzICYgVENQ VVRPX0VOQUJMRSAmJgorCQkJCQkgICAgdHAtPnV0b19mbGFncyAmIFRDUFVUT19ORUVEKSB7CisJ CQkJCQl1aW50MzJfdCBtYXh0aW1lOworCisJCQkJCQltYXh0aW1lID0gbWF4KHR1LnV0bypoeiwK KwkJCQkJCSAgICB0Y3BfdXRvX21pbik7CisJCQkJCQl0cC0+dF91dG9faW1wbCA9CisJCQkJCQkg ICAgbWluKHRjcF91dG9fbWF4LCBtYXh0aW1lKTsKKwkJCQkJCXRwLT50X3V0b19hZHYgPSB0cC0+ dF91dG9faW1wbDsKKwkJCQkJCXRwLT51dG9fZmxhZ3MgJj0KKwkJCQkJCSAgICB+VENQVVRPX0NI QU5HRUFCTEU7CisJCQkJCQl0cC0+dXRvX2ZsYWdzIHw9IFRDUFVUT19JTVBMOworCQkJCQl9CisJ CQkJfSBlbHNlCisJCQkJCWVycm9yID0gRUlOVkFMOworCQkJfQorCQkJaWYgKHR1LmZsYWdzICYg VENQX1VUT19DSEFOR0UpCisJCQkJdHAtPnV0b19mbGFncyB8PSBUQ1BVVE9fQ0hBTkdFQUJMRTsK KwkJCUlOUF9XVU5MT0NLKGlucCk7CisJCQlicmVhazsKKwogCQlkZWZhdWx0OgogCQkJSU5QX1dV TkxPQ0soaW5wKTsKIAkJCWVycm9yID0gRU5PUFJPVE9PUFQ7CkBAIC0xMzk0LDYgKzE0NDcsMjAg QEAKIAkJCUlOUF9XVU5MT0NLKGlucCk7CiAJCQllcnJvciA9IHNvb3B0Y29weW91dChzb3B0LCAm dGksIHNpemVvZiB0aSk7CiAJCQlicmVhazsKKwkJY2FzZSBUQ1BfVVRPOgorCQkJdHUuZmxhZ3Mg PSAwOworCQkJaWYgKHRwLT51dG9fZmxhZ3MgJiBUQ1BVVE9fRU5BQkxFKQorCQkJCXR1LmZsYWdz IHw9IFRDUF9VVE9fRU5BQkxFOworCQkJaWYgKHRwLT51dG9fZmxhZ3MgJiBUQ1BVVE9fQ0hBTkdF QUJMRSkKKwkJCQl0dS5mbGFncyB8PSBUQ1BfVVRPX0NIQU5HRTsKKwkJCVRDUFRfUkVTT0xWRV9V VE8odHApOworCQkJaWYgKHRwLT51dG9fZmxhZ3MgJiBUQ1BVVE9fSU1QTCkgeworCQkJCXR1LmZs YWdzIHw9IFRDUF9VVE9fU1RPUkU7CisJCQkJdHUudXRvID0gdHAtPnRfdXRvX2ltcGwgLyBoejsK KwkJCX0KKwkJCUlOUF9XVU5MT0NLKGlucCk7CisJCQllcnJvciA9IHNvb3B0Y29weW91dChzb3B0 LCAmdHUsIHNpemVvZiB0dSk7CisJCQlicmVhazsKIAkJZGVmYXVsdDoKIAkJCUlOUF9XVU5MT0NL KGlucCk7CiAJCQllcnJvciA9IEVOT1BST1RPT1BUOwpJbmRleDogdXNyLmJpbi9uZXRzdGF0L2lu ZXQuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09Ci0tLSB1c3IuYmluL25ldHN0YXQvaW5ldC5jCShyZXZpc2lvbiAxOTY0 NTUpCisrKyB1c3IuYmluL25ldHN0YXQvaW5ldC5jCSh3b3JraW5nIGNvcHkpCkBAIC02MDcsNiAr NjA3LDcgQEAKIAlwKHRjcHNfc25kcHJvYmUsICJcdFx0JWx1IHdpbmRvdyBwcm9iZSBwYWNrZXQl c1xuIik7CiAJcCh0Y3BzX3NuZHdpbnVwLCAiXHRcdCVsdSB3aW5kb3cgdXBkYXRlIHBhY2tldCVz XG4iKTsKIAlwKHRjcHNfc25kY3RybCwgIlx0XHQlbHUgY29udHJvbCBwYWNrZXQlc1xuIik7CisJ cCh0Y3BzX3NuZHV0bywgIlx0XHQlbHUgdGNwIHV0byBlbmFibGVkIHBhY2tldCVzXG4iKTsKIAlw KHRjcHNfcmN2dG90YWwsICJcdCVsdSBwYWNrZXQlcyByZWNlaXZlZFxuIik7CiAJcDIodGNwc19y Y3ZhY2twYWNrLCB0Y3BzX3JjdmFja2J5dGUsCiAJICAgICJcdFx0JWx1IGFjayVzIChmb3IgJWx1 IGJ5dGUlcylcbiIpOwpAQCAtNjIzLDYgKzYyNCw3IEBACiAJICAgICJcdFx0JWx1IG91dC1vZi1v cmRlciBwYWNrZXQlcyAoJWx1IGJ5dGUlcylcbiIpOwogCXAyKHRjcHNfcmN2cGFja2FmdGVyd2lu LCB0Y3BzX3JjdmJ5dGVhZnRlcndpbiwKIAkgICAgIlx0XHQlbHUgcGFja2V0JXMgKCVsdSBieXRl JXMpIG9mIGRhdGEgYWZ0ZXIgd2luZG93XG4iKTsKKwlwKHRjcHNfcmN2dXRvLCAiXHRcdCVsdSB0 Y3AgdXRvIGVuYWJsZWQgcGFja2V0JXNcbiIpOwogCXAodGNwc19yY3Z3aW5wcm9iZSwgIlx0XHQl bHUgd2luZG93IHByb2JlJXNcbiIpOwogCXAodGNwc19yY3Z3aW51cGQsICJcdFx0JWx1IHdpbmRv dyB1cGRhdGUgcGFja2V0JXNcbiIpOwogCXAodGNwc19yY3ZhZnRlcmNsb3NlLCAiXHRcdCVsdSBw YWNrZXQlcyByZWNlaXZlZCBhZnRlciBjbG9zZVxuIik7CkluZGV4OiBjb250cmliL3RjcGR1bXAv cHJpbnQtdGNwLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQotLS0gY29udHJpYi90Y3BkdW1wL3ByaW50LXRjcC5jCShy ZXZpc2lvbiAxOTY0NTUpCisrKyBjb250cmliL3RjcGR1bXAvcHJpbnQtdGNwLmMJKHdvcmtpbmcg Y29weSkKQEAgLTEyNCw2ICsxMjQsNyBAQAogICAgICAgICB7IFRDUE9QVF9DQ0VDSE8sICIiIH0s CiAgICAgICAgIHsgVENQT1BUX1NJR05BVFVSRSwgIm1kNSIgfSwKICAgICAgICAgeyBUQ1BPUFRf QVVUSCwgImVuaGFuY2VkIGF1dGgiIH0sCisgICAgICAgIHsgVENQT1BUX1VUTywgInV0byIgfSwK ICAgICAgICAgeyAwLCBOVUxMIH0KIH07CiAKQEAgLTYxMyw2ICs2MTQsMTcgQEAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICovCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGJyZWFrOwogCisgICAgICAgICAgICAgICAgICAgICAgICBjYXNlIFRDUE9QVF9VVE86Cisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGRhdGFsZW4gPSAyOworICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBMRU5DSEVDSyhkYXRhbGVuKTsKKyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdWludCB1dG92YWwgPSBFWFRSQUNUXzE2QklUUyhjcCk7CisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGlmICh1dG92YWwgJiAweDAwMDEpCisgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdXRvdmFsID0gKHV0b3ZhbCA+PiAxKSAqIDYw OworICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBlbHNlCisgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdXRvdmFsID4+PSAxOworICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAodm9pZClwcmludGYoIiAldSIsIHV0b3ZhbCk7CisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGJyZWFrOworCiAgICAgICAgICAgICAgICAgICAgICAgICBkZWZh dWx0OgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkYXRhbGVuID0gbGVuIC0gMjsK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9yIChpID0gMDsgaSA8IGRhdGFsZW47 ICsraSkgewpJbmRleDogY29udHJpYi90Y3BkdW1wL3RjcC5oCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGNvbnRy aWIvdGNwZHVtcC90Y3AuaAkocmV2aXNpb24gMTk2NDU1KQorKysgY29udHJpYi90Y3BkdW1wL3Rj cC5oCSh3b3JraW5nIGNvcHkpCkBAIC04Myw2ICs4Myw4IEBACiAjZGVmaW5lICAgIFRDUE9MRU5f U0lHTkFUVVJFCQkxOAogI2RlZmluZSBUQ1BfU0lHTEVOIDE2CQkJLyogbGVuZ3RoIG9mIGFuIG9w dGlvbiAxOSBkaWdlc3QgKi8KICNkZWZpbmUgVENQT1BUX0FVVEggICAgICAgICAgICAgMjAgICAg ICAvKiBFbmhhbmNlZCBBVVRIIG9wdGlvbiAqLworI2RlZmluZQlUQ1BPUFRfVVRPCQkyOAkvKiB0 Y3AgdXNlciB0aW1lb3V0IChyZmM1NDgyKSAqLworI2RlZmluZQkgICBUQ1BPTEVOX1VUTwkJCTQK IAogI2RlZmluZSBUQ1BPUFRfVFNUQU1QX0hEUglcCiAgICAgKFRDUE9QVF9OT1A8PDI0fFRDUE9Q VF9OT1A8PDE2fFRDUE9QVF9USU1FU1RBTVA8PDh8VENQT0xFTl9USU1FU1RBTVApCkluZGV4OiB0 b29scy9yZWdyZXNzaW9uL25ldGluZXQvdGNwdXRvL3RjcHV0by5jCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHRv b2xzL3JlZ3Jlc3Npb24vbmV0aW5ldC90Y3B1dG8vdGNwdXRvLmMJKHJldmlzaW9uIDApCisrKyB0 b29scy9yZWdyZXNzaW9uL25ldGluZXQvdGNwdXRvL3RjcHV0by5jCShyZXZpc2lvbiAwKQpAQCAt MCwwICsxLDU2NSBAQAorLyotCisgKiBDb3B5cmlnaHQgKGMpIDIwMDkgRmFuZyBXYW5nIDxmYW5n d2FuZ0BGcmVlQlNELm9yZz4KKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCisgKgorICogUmVkaXN0 cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywgd2l0aCBvciB3aXRo b3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQgdGhhdCB0aGUgZm9s bG93aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRpc3RyaWJ1dGlvbnMgb2Yg c291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNl LCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyLgor ICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVwcm9kdWNlIHRoZSBh Ym92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5k IHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyAqICAgIGRvY3VtZW50YXRpb24gYW5k L29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmlidXRpb24uCisgKgor ICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIEFORCBDT05UUklCVVRP UlMgYGBBUyBJUycnIEFORAorICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBXQVJSQU5USUVTLCBJ TkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVEIFdBUlJBTlRJRVMg T0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VMQVIgUFVSUE9TRQor ICogQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVUSE9SIE9SIENPTlRS SUJVVE9SUyBCRSBMSUFCTEUKKyAqIEZPUiBBTlkgRElSRUNULCBJTkRJUkVDVCwgSU5DSURFTlRB TCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisgKiBEQU1BR0VTIChJTkNM VURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VCU1RJVFVURSBHT09E UworICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9GSVRTOyBPUiBCVVNJ TkVTUyBJTlRFUlJVUFRJT04pCisgKiBIT1dFVkVSIENBVVNFRCBBTkQgT04gQU5ZIFRIRU9SWSBP RiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorICogTElBQklMSVRZLCBP UiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFSSVNJTkcgSU4gQU5Z IFdBWQorICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZFTiBJRiBBRFZJU0VE IE9GIFRIRSBQT1NTSUJJTElUWSBPRgorICogU1VDSCBEQU1BR0UuCisgKgorICogJEZyZWVCU0Qk CisgKi8KKworLyoKKyAqIFRDUCByZWdyZXNzaW9uIHRlc3QgZm9yIHRjcCB1c2VyIHRpbWVvdXQ7 IGJ1aWxkIGEgVENQIGNvbm5lY3Rpb24sIGludGVycnVwdAorICogaXQgd2l0aG91dCBkZXRlY3Rl ZCBieSBvcGVyYXRpbmcgc3lzdGVtLCBhbmQgbWFrZSBzdXJlIHRoZSB0aW1lb3V0IHRpbWUgYW5k CisgKiByZXRyYW5zbWlzc2lvbiB0aW1lcyBoYXMgYmVlbiBjaGFuZ2VkIGFwcHJvcHJpYXRlbHku CisgKi8KKworCisjaW5jbHVkZSA8c3lzL3R5cGVzLmg+CisjaW5jbHVkZSA8c3lzL3NvY2tldC5o PgorCisjaW5jbHVkZSA8bmV0L2V0aGVybmV0Lmg+CisjaW5jbHVkZSA8bmV0aW5ldC9pbi5oPgor I2luY2x1ZGUgPG5ldGluZXQvaXAuaD4KKyNpbmNsdWRlIDxuZXRpbmV0L3RjcC5oPgorCisjaW5j bHVkZSA8YXJwYS9pbmV0Lmg+CisKKyNpbmNsdWRlIDxlcnIuaD4KKyNpbmNsdWRlIDxlcnJuby5o PgorI2luY2x1ZGUgPGZjbnRsLmg+CisjaW5jbHVkZSA8c3RkaW8uaD4KKyNpbmNsdWRlIDxzdGRs aWIuaD4KKyNpbmNsdWRlIDxzdHJpbmcuaD4KKyNpbmNsdWRlIDx1bmlzdGQuaD4KKyNpbmNsdWRl IDx0aW1lLmg+CisjaW5jbHVkZSA8c2lnbmFsLmg+CisKKyNpbmNsdWRlIDxwY2FwLmg+CisjaW5j bHVkZSA8cHRocmVhZC5oPgorCisjZGVmaW5lCVNJWkVfRVRIRVJORVQJc2l6ZW9mKHN0cnVjdCBl dGhlcl9oZWFkZXIpCisjZGVmaW5lCU1BWF9SWFQJMjAwCisKK3N0cnVjdCB0Y3ByeHQgeworCXN0 cnVjdCB0aW1ldmFsIHRzOworCXVfaW50CXRoX29mZjsKKwl0Y3Bfc2VxCXRoX3NlcTsKKwl0Y3Bf c2VxCXRoX2FjazsKKwl1X3Nob3J0CXRoX3dpbjsKKwl1X2NoYXIJdGhfZmxhZ3M7Cit9OworCitz dGF0aWMgc3RydWN0IHRjcHJ4dAlyeHRzW01BWF9SWFRdOworCitzdGF0aWMgdm9pZAorcGFyc2Vf cGFja2V0KHVfY2hhciAqYXJncywgY29uc3Qgc3RydWN0IHBjYXBfcGt0aGRyICpwa3RfaGVhZGVy LAorICAgIGNvbnN0IHVfY2hhciAqcGFja2V0KQoreworCWNvbnN0IHN0cnVjdCBpcCAqaXA7CisJ Y29uc3Qgc3RydWN0IHRjcGhkciAqdGNwOworCWNvbnN0IHVfY2hhciAqdGNwb3B0OworCXN0cnVj dCB0Y3ByeHQgcnh0OworCXVfaW50IG9wdCwgb3B0bGVuOworCXVfaW50IGhsZW47CisJdV9pbnQg bGVuZ3RoOworCisJbGVuZ3RoID0gcGt0X2hlYWRlci0+bGVuIC0gU0laRV9FVEhFUk5FVDsKKwlp cCA9IChzdHJ1Y3QgaXAgKikocGFja2V0ICsgU0laRV9FVEhFUk5FVCk7CisJaGxlbiA9IGlwLT5p cF9obCAqIDQ7CisJbGVuZ3RoIC09IGhsZW47CisJaWYgKGhsZW4gPCAyMCkgeworCQlwcmludGYo IiAgICogSW52YWxpZCBJUCBoZWFkZXIgbGVuZ3RoOiAldSBieXRlc1xuIiwgaGxlbik7CisJCXJl dHVybjsKKwl9CisJdGNwID0gKHN0cnVjdCB0Y3BoZHIgKikoKHVfY2hhciAqKWlwICsgaGxlbik7 CisJaGxlbiA9IHRjcC0+dGhfb2ZmICogNDsKKwlsZW5ndGggLT0gaGxlbjsKKwlpZiAoaGxlbiA8 IDIwKSB7CisJCXByaW50ZigiICAgKiBJbnZhbGlkIFRDUCBoZWFkZXIgbGVuZ3RoOiAldSBieXRl c1xuIiwgaGxlbik7CisJCXJldHVybjsKKwl9CisJdGNwb3B0ID0gKHVfY2hhciAqKXRjcCArIHNp emVvZigqdGNwKTsKKwlobGVuIC09IHNpemVvZigqdGNwKTsKKwl3aGlsZSAoaGxlbiA+IDApIHsK KwkJb3B0ID0gKnRjcG9wdCsrOworCQlobGVuLS07CisJCWlmIChvcHQgPT0gVENQT1BUX0VPTCkK KwkJCWJyZWFrOworCQlpZiAob3B0ID09IFRDUE9QVF9OT1ApCisJCQljb250aW51ZTsKKwkJb3B0 bGVuID0gKnRjcG9wdCsrOworCQlpZiAob3B0ID09IFRDUE9QVF9VVE8pIHsKKwkJCXVfaW50IHV0 byA9IGh0b25zKCoodV9zaG9ydCAqKXRjcG9wdCk7CisJCQlzdHJ1Y3QgdG0gKnA7CisJCQlpZiAo dXRvICYgMSkKKwkJCQl1dG8gPSAodXRvID4+IDEpICogNjA7CisJCQllbHNlCisJCQkJdXRvID4+ PSAxOworCQkJcCA9IGxvY2FsdGltZSgmcGt0X2hlYWRlci0+dHMudHZfc2VjKTsKKwkJCXByaW50 ZigidXRvIHBhY2tldDogIik7CisJCQlwcmludGYoIiUwMmQ6JTAyZDolMDJkLiUtNnUgIiwgcC0+ dG1faG91ciwgcC0+dG1fbWluLAorCQkJICAgIHAtPnRtX3NlYywgcGt0X2hlYWRlci0+dHMudHZf dXNlYyk7CisJCQlwcmludGYoIiVzLiVkID4gIiwgaW5ldF9udG9hKGlwLT5pcF9zcmMpLAorCQkJ ICAgIGh0b25zKHRjcC0+dGhfc3BvcnQpKTsKKwkJCXByaW50ZigiJXMuJWQsICIsIGluZXRfbnRv YShpcC0+aXBfZHN0KSwKKwkJCSAgICBodG9ucyh0Y3AtPnRoX2Rwb3J0KSk7CisJCQlwcmludGYo ImZsYWdzIFsiKTsKKwkJCWlmICh0Y3AtPnRoX2ZsYWdzICYgVEhfU1lOKQorCQkJCXByaW50Zigi UyIpOworCQkJaWYgKHRjcC0+dGhfZmxhZ3MgJiBUSF9SU1QpCisJCQkJcHJpbnRmKCJSIik7CisJ CQlpZiAodGNwLT50aF9mbGFncyAmIFRIX1BVU0gpCisJCQkJcHJpbnRmKCJQIik7CisJCQlpZiAo dGNwLT50aF9mbGFncyAmIFRIX0FDSykKKwkJCQlwcmludGYoIi4iKTsKKwkJCWlmICh0Y3AtPnRo X2ZsYWdzICYgVEhfVVJHKQorCQkJCXByaW50ZigiVSIpOworCQkJcHJpbnRmKCJdLCAiKTsKKwkJ CXByaW50ZigidXRvICV1LCB3aW4gJXUsIGxlbmd0aCAldVxuIiwgdXRvLAorCQkJICAgIGh0b25z KHRjcC0+dGhfd2luKSwgbGVuZ3RoKTsKKwkJfQorCQlobGVuIC09IG9wdGxlbiAtIDE7CisJCXRj cG9wdCArPSBvcHRsZW4gLSAyOworCX0KKwlpZiAobGVuZ3RoID4gMCB8fCB0Y3AtPnRoX2ZsYWdz ICYgVEhfUlNUKSB7CisJCW1lbXNldCgmcnh0LCAwLCBzaXplb2Yocnh0KSk7CisJCW1lbWNweSgm cnh0LnRzLCAmcGt0X2hlYWRlci0+dHMsIHNpemVvZihyeHQudHMpKTsKKwkJcnh0LnRoX3dpbiA9 IGh0b25zKHRjcC0+dGhfd2luKTsKKwkJcnh0LnRoX29mZiA9IHRjcC0+dGhfb2ZmOworCQlyeHQu dGhfYWNrID0gaHRvbmwodGNwLT50aF9hY2spOworCQlyeHQudGhfc2VxID0gaHRvbmwodGNwLT50 aF9zZXEpOworCQlyeHQudGhfZmxhZ3MgPSB0Y3AtPnRoX2ZsYWdzOworCQltZW1jcHkoJnJ4dHNb MF0sICZyeHRzWzFdLAorCQkgICAgc2l6ZW9mKHN0cnVjdCB0Y3ByeHQpICogKE1BWF9SWFQgLSAx KSk7CisJCW1lbWNweSgmcnh0c1tNQVhfUlhUIC0gMV0sICZyeHQsIHNpemVvZihyeHQpKTsKKwl9 Cit9CisKK3N0YXRpYyB2b2lkICoKK2R1bXBfcGFja2V0KHZvaWQgKmFyZykKK3sKKwlwY2FwX3Qg KmhhbmRsZTsKKwljaGFyIGVycmJ1ZltQQ0FQX0VSUkJVRl9TSVpFXTsKKwlzdHJ1Y3QgYnBmX3By b2dyYW0gZnA7CisJY2hhciBmaWx0ZXJfZXhwWzEyOF07CisJYnBmX3VfaW50MzIgbWFzazsKKwli cGZfdV9pbnQzMiBuZXQ7CisJc3RydWN0IHBjYXBfcGt0aGRyIGhlYWRlcjsKKwljb25zdCB1X2No YXIgKnBhY2tldDsKKwlzdHJ1Y3Qgc29ja2FkZHJfaW4gc3JjYWRkciwgZHN0YWRkciwgKmRldmFk ZHJwOworCWludCBvcHRsZW47CisJcGNhcF9pZl90ICphbGxkZXZzcCwgKmRldnA7CisJcGNhcF9h ZGRyX3QgKmFkZHJwOworCWludCBmbGFnOworCisJb3B0bGVuID0gc2l6ZW9mKHNyY2FkZHIpOwor CWlmIChnZXRzb2NrbmFtZSgqKChpbnQgKilhcmcpLCAoc3RydWN0IHNvY2thZGRyICopJnNyY2Fk ZHIsCisJICAgICZvcHRsZW4pID09IC0xKQorCQllcnIoLTEsICJnZXRzb2NrbmFtZSIpOworCW9w dGxlbiA9IHNpemVvZihkc3RhZGRyKTsKKwlpZiAoZ2V0cGVlcm5hbWUoKigoaW50ICopYXJnKSwg KHN0cnVjdCBzb2NrYWRkciAqKSZkc3RhZGRyLAorCSAgICAmb3B0bGVuKSA9PSAtMSkKKwkJZXJy KC0xLCAiZ2V0c29ja25hbWUiKTsKKworCWlmIChwY2FwX2ZpbmRhbGxkZXZzKCZhbGxkZXZzcCwg ZXJyYnVmKSA9PSAtMSkgeworCQlmcHJpbnRmKHN0ZGVyciwgIkNvdWxkbid0IGdldCBhbGwgZGV2 aWNlOiAlc1xuIiwgZXJyYnVmKTsKKwkJZXhpdCgtMSk7CisJfQorCisJZGV2cCA9IGFsbGRldnNw OworCWZsYWcgPSAxOworCXdoaWxlIChkZXZwICE9IE5VTEwpIHsKKwkJYWRkcnAgPSBkZXZwLT5h ZGRyZXNzZXM7CisJCXdoaWxlIChhZGRycCAhPSBOVUxMICYmIGZsYWcpIHsKKwkJCWRldmFkZHJw ID0gKHN0cnVjdCBzb2NrYWRkcl9pbiAqKWFkZHJwLT5hZGRyOworCQkJaWYgKCFtZW1jbXAoJmRl dmFkZHJwLT5zaW5fYWRkciwgJnNyY2FkZHIuc2luX2FkZHIsCisJCQkgICAgc2l6ZW9mKHNyY2Fk ZHIuc2luX2FkZHIpKSkgeworCQkJCWZsYWcgPSAwOworCQkJCWJyZWFrOworCQkJfQorCQkJYWRk cnAgPSBhZGRycC0+bmV4dDsKKwkJfQorCQlpZiAoIWZsYWcpCisJCQlicmVhazsKKwkJZGV2cCA9 IGRldnAtPm5leHQ7CisJfQorCisJaWYgKGRldnAgPT0gTlVMTCkgeworCQlmcHJpbnRmKHN0ZGVy ciwgIkNvdWxkbid0IGZpbmQgdXNpbmcgZGV2aWNlXG4iKTsKKwkJZXhpdCgtMSk7CisJfQorCisJ aWYgKHBjYXBfbG9va3VwbmV0KGRldnAtPm5hbWUsICZuZXQsICZtYXNrLCBlcnJidWYpID09IC0x KSB7CisJCWZwcmludGYoc3RkZXJyLCAiQ291bGRuJ3QgZ2V0IG5ldG1hc2sgZm9yIGRldmljZSAl czogJXNcbiIsCisJCSAgICBkZXZwLT5uYW1lLCBlcnJidWYpOworCQluZXQgPSAwOworCQltYXNr ID0gMDsKKwl9CisKKwloYW5kbGUgPSBwY2FwX29wZW5fbGl2ZShkZXZwLT5uYW1lLCBCVUZTSVos IDEsIDEwMDAsIGVycmJ1Zik7CisJaWYgKGhhbmRsZSA9PSBOVUxMKSB7CisJCWZwcmludGYoc3Rk ZXJyLCAiQ291bGRuJ3Qgb3BlbiBkZXZpY2UgJXM6ICVzXG4iLAorCQkgICAgZGV2cC0+bmFtZSwg ZXJyYnVmKTsKKwkJZXhpdCgtMSk7CisJfQorCisJcGNhcF9mcmVlYWxsZGV2cyhhbGxkZXZzcCk7 CisKKwlzbnByaW50ZihmaWx0ZXJfZXhwLCBzaXplb2YoZmlsdGVyX2V4cCksCisJICAgICIodGNw IHNyYyBwb3J0ICVkIGFuZCBkc3QgcG9ydCAlZCkgb3IiCisJICAgICIodGNwIHNyYyBwb3J0ICVk IGFuZCBkc3QgcG9ydCAlZCkiLAorCSAgICBudG9ocyhzcmNhZGRyLnNpbl9wb3J0KSwgbnRvaHMo ZHN0YWRkci5zaW5fcG9ydCksCisJICAgIG50b2hzKGRzdGFkZHIuc2luX3BvcnQpLCBudG9ocyhz cmNhZGRyLnNpbl9wb3J0KSk7CisKKwlpZiAocGNhcF9jb21waWxlKGhhbmRsZSwgJmZwLCBmaWx0 ZXJfZXhwLCAwLCBuZXQpID09IC0xKSB7CisJCWZwcmludGYoc3RkZXJyLCAiQ291bGRuJ3QgcGFy c2UgZmlsdGVyICVzOiAlc1xuIiwKKwkJICAgIGZpbHRlcl9leHAsIHBjYXBfZ2V0ZXJyKGhhbmRs ZSkpOworCQlleGl0KC0xKTsKKwl9CisJaWYgKHBjYXBfc2V0ZmlsdGVyKGhhbmRsZSwgJmZwKSA9 PSAtMSkgeworCQlmcHJpbnRmKHN0ZGVyciwgIkNvdWxkbid0IGluc3RhbGwgZmlsdGVyICVzOiAl c1xuIiwKKwkJICAgIGZpbHRlcl9leHAsIHBjYXBfZ2V0ZXJyKGhhbmRsZSkpOworCQlleGl0KC0x KTsKKwl9CisKKwlwY2FwX2xvb3AoaGFuZGxlLCAtMSwgcGFyc2VfcGFja2V0LCBOVUxMKTsKKwlw Y2FwX2Nsb3NlKGhhbmRsZSk7CisKKwlyZXR1cm4gTlVMTDsKK30KKworc3RhdGljIHZvaWQKK3By aW50X3Jlc3VsdCgpCit7CisJdGNwX3NlcSByeHRfc2VxOworCWludCBpLCBsYXN0LCByeHRfbnI7 CisJc3RydWN0IHRtICpwOworCQorCS8qIEdldCB0aGUgcmV0cmFuc21pdCBzZXF1ZW5jZSBudW1i ZXIgKi8KKwlyeHRfc2VxID0gcnh0c1tNQVhfUlhUIC0gMl0udGhfc2VxOworCWZvciAobGFzdCA9 IC0xLCByeHRfbnIgPSAwLCBpID0gMDsgaSA8IE1BWF9SWFQ7IGkrKykgeworCQlpZiAocnh0c1tp XS50aF9zZXEgJiYKKwkJICAgIChyeHRzW2ldLnRoX3NlcSA9PSByeHRfc2VxIHx8IHJ4dHNbaV0u dGhfZmxhZ3MgJiBUSF9SU1QpKSB7CisJCQlpZiAocnh0c1tpXS50aF9mbGFncyAmIFRIX1JTVCkK KwkJCQlwcmludGYoInJlc2V0IHBhY2tldCwgIik7CisJCQllbHNlIGlmIChyeHRfbnIpCisJCQkJ cHJpbnRmKCJyZXRyYW5zbWl0ICUwMmQsICIsIHJ4dF9ucik7CisJCQllbHNlIGlmICghcnh0X25y KQorCQkJCXByaW50Zigic2VuZCBwYWNrZXQsICIpOworCQkJcCA9IGxvY2FsdGltZSgmcnh0c1tp XS50cy50dl9zZWMpOworCQkJcHJpbnRmKCIlMDJkOiUwMmQ6JTAyZC4lLTZ1ICIsIHAtPnRtX2hv dXIsIHAtPnRtX21pbiwKKwkJCSAgICBwLT50bV9zZWMsIHJ4dHNbaV0udHMudHZfdXNlYyk7CisJ CQlpZiAobGFzdCAhPSAtMSkgeworCQkJCS8qIHByaW50IGludGVydmFsIGJldHdlZW4gdHdvIHBh Y2tldHMgKi8KKwkJCQlpZiAocnh0c1tpXS50cy50dl91c2VjIDwgcnh0c1tsYXN0XS50cy50dl91 c2VjKQorCQkJCQlwcmludGYoIiglMnUuJS02dSkgIiwKKwkJCQkJICAgIHJ4dHNbaV0udHMudHZf c2VjIC0KKwkJCQkJICAgIHJ4dHNbbGFzdF0udHMudHZfc2VjIC0gMSwKKwkJCQkJICAgIDEwMDAw MDAgKyByeHRzW2ldLnRzLnR2X3VzZWMgLQorCQkJCQkgICAgcnh0c1tsYXN0XS50cy50dl91c2Vj KTsKKwkJCQllbHNlCisJCQkJCXByaW50ZigiKCUydS4lLTZ1KSAiLAorCQkJCQkgICAgcnh0c1tp XS50cy50dl9zZWMgLQorCQkJCQkgICAgcnh0c1tsYXN0XS50cy50dl9zZWMsCisJCQkJCSAgICBy eHRzW2ldLnRzLnR2X3VzZWMgLQorCQkJCQkgICAgcnh0c1tsYXN0XS50cy50dl91c2VjKTsKKwkJ CX0KKwkJCXByaW50Zigic2VxICV1LCBhY2sgJXUsICIsCisJCQkgICAgcnh0c1tpXS50aF9zZXEs IHJ4dHNbaV0udGhfYWNrKTsKKwkJCXByaW50Zigid2luICV1XG4iLCByeHRzW2ldLnRoX3dpbik7 CisJCQlsYXN0ID0gaTsKKwkJCXJ4dF9ucisrOworCQl9CisJfQorfQorCitzdGF0aWMgaW50Citw cmludF91dG9fc3RhdHVzKGludCBzb2NrLCBpbnQgcHJpbnQpCit7CisJc3RhdGljIHN0cnVjdCB0 Y3B1dG8gdHUgPSB7MCwgMH07CisJaW50IGRlZmF1bHRfdXRvID0gMSArIDIgKyA0ICsgOCArIDE2 ICsgMzIgKyA2NCArCisJICAgIDY0ICsgNjQgKyA2NCArIDY0ICsgNjQgKyA2NDsKKwlpbnQgb3B0 bGVuOworCWludCB1dG92YWw7CisKKwlvcHRsZW4gPSBzaXplb2YodHUpOworCSh2b2lkKWdldHNv Y2tvcHQoc29jaywgSVBQUk9UT19UQ1AsIFRDUF9VVE8sICZ0dSwgJm9wdGxlbik7CisJaWYgKHBy aW50KSB7CisJCWlmICh0dS5mbGFncyAmIFRDUF9VVE9fRU5BQkxFKSB7CisJCQlwcmludGYoInRj cHV0bzogZW5hYmxlZCwgIik7CisJCQlpZiAodHUuZmxhZ3MgJiBUQ1BfVVRPX1NUT1JFKSB7CisJ CQkJcHJpbnRmKCJ1c2VyIHRpbWVvdXQoY2hhbmdlZCk6ICVkIHNlY29uZHNcbiIsCisJCQkJICAg IHR1LnV0byk7CisJCQkJdXRvdmFsID0gdHUudXRvOworCQkJfSBlbHNlIHsKKwkJCQlwcmludGYo InVzZXIgdGltZW91dChkZWZhdWx0KTogJWQgc2Vjb25kc1xuIiwKKwkJCQkgICAgZGVmYXVsdF91 dG8pOworCQkJCXV0b3ZhbCA9IGRlZmF1bHRfdXRvOworCQkJfQorCQl9IGVsc2UgeworCQkJcHJp bnRmKCJ0Y3B1dG86IGRpc2FibGVkLCBkZWZhdWx0IHRpbWVvdXQ6ICVkICIKKwkJCSAgICAic2Vj b25kc1xuIiwgZGVmYXVsdF91dG8pOworCQkJdXRvdmFsID0gZGVmYXVsdF91dG87CisJCX0KKwl9 CisKKwlyZXR1cm4gKHV0b3ZhbCk7Cit9CisKK3N0YXRpYyB2b2lkCit1c2FnZSh2b2lkKQorewor CWZwcmludGYoc3RkZXJyLCAidGNwdXRvIHNlcnZlciBwb3J0IFt1dG8gW3RpbWVvdXRdXVxuIik7 CisJZnByaW50ZihzdGRlcnIsICJ0Y3B1dG8gY2xpZW50IGlwIHBvcnQgW3V0byBbdGltZW91dF1d XG4iKTsKKwlleGl0KC0xKTsKK30KKworc3RhdGljIGludAordGNwdXRvX3RpbWVyKHZvaWQpCit7 CisJc3RhdGljIHRpbWVfdCBzdGFydF90aW1lID0gMDsKKwl0aW1lX3QgZW5kX3RpbWU7CisJdGlt ZV90IGludGVydmFsOworCisJaWYgKHN0YXJ0X3RpbWUgPT0gMCkgeworCQl0aW1lKCZzdGFydF90 aW1lKTsKKwkJaW50ZXJ2YWwgPSAwOworCX0gZWxzZSB7CisJCXRpbWUoJmVuZF90aW1lKTsKKwkJ aW50ZXJ2YWwgPSBlbmRfdGltZSAtIHN0YXJ0X3RpbWU7CisJCXN0YXJ0X3RpbWUgPSAwOworCX0K KworCXJldHVybiAoaW50KShpbnRlcnZhbCk7Cit9CisKK3N0YXRpYyB2b2lkCit0Y3B1dG9fc2Vy dmVyKGludCBhcmdjLCBjaGFyICphcmd2W10pCit7CisJaW50IGxpc3Rlbl9zb2NrLCBhY2NlcHRf c29jazsKKwlzdHJ1Y3Qgc29ja2FkZHJfaW4gc2luOworCWNoYXIgKmR1bW15OworCWNoYXIgYnVm WzgqMTAyNF07CisJbG9uZyBwb3J0OworCWludCB1c2VyX3RpbWVvdXQ7CisJaW50IG9wdHZhbDsK KwlzdHJ1Y3QgdGNwdXRvIHV0bzsKKwlwdGhyZWFkX3QgdGlkOworCisJaWYgKGFyZ2MgPCAxICYm IGFyZ2MgPiAzKQorCQl1c2FnZSgpOworCisJYnplcm8oJnNpbiwgc2l6ZW9mKHNpbikpOworCXNp bi5zaW5fbGVuID0gc2l6ZW9mKHNpbik7CisJc2luLnNpbl9mYW1pbHkgPSBBRl9JTkVUOworCXNp bi5zaW5fYWRkci5zX2FkZHIgPSBodG9ubChJTkFERFJfQU5ZKTsKKworCXBvcnQgPSBzdHJ0b3Vs KGFyZ3ZbMF0sICZkdW1teSwgMTApOworCWlmIChwb3J0IDwgMSB8fCBwb3J0ID4gNjU1MzUgfHwg KmR1bW15ICE9ICdcMCcpCisJCXVzYWdlKCk7CisJc2luLnNpbl9wb3J0ID0gaHRvbnMocG9ydCk7 CisKKwlsaXN0ZW5fc29jayA9IHNvY2tldChQRl9JTkVULCBTT0NLX1NUUkVBTSwgMCk7CisJaWYg KGxpc3Rlbl9zb2NrID09IC0xKQorCQllcnIoLTEsICJzb2NrZXQiKTsKKwlvcHR2YWwgPSAxOwor CWlmIChzZXRzb2Nrb3B0KGxpc3Rlbl9zb2NrLCBTT0xfU09DS0VULCBTT19SRVVTRUFERFIsICZv cHR2YWwsCisJICAgIHNpemVvZihvcHR2YWwpKSA9PSAtMSkKKwkJZXJyKC0xLCAic2V0c29ja29w dCIpOworCisJaWYgKGJpbmQobGlzdGVuX3NvY2ssIChzdHJ1Y3Qgc29ja2FkZHIgKikmc2luLCBz aXplb2Yoc2luKSkgPT0gLTEpCisJCWVycigtMSwgImJpbmQiKTsKKworCWlmIChsaXN0ZW4obGlz dGVuX3NvY2ssIC0xKSA9PSAtMSkKKwkJZXJyKC0xLCAibGlzdGVuIik7CisKKwlhY2NlcHRfc29j ayA9IGFjY2VwdChsaXN0ZW5fc29jaywgTlVMTCwgTlVMTCk7CisJaWYgKGFjY2VwdF9zb2NrID09 IC0xKQorCQllcnIoLTEsICJhY2NlcHQiKTsKKwljbG9zZShsaXN0ZW5fc29jayk7CisKKwlpZiAo cHRocmVhZF9jcmVhdGUoJnRpZCwgTlVMTCwgZHVtcF9wYWNrZXQsICh2b2lkICopJmFjY2VwdF9z b2NrKSkKKwkJZXJyKC0xLCAiY3JlYXRlIHRocmVhZCIpOworCisJaWYgKGFyZ2MgPj0gMikgewor CQltZW1zZXQoJnV0bywgMCwgc2l6ZW9mKHV0bykpOworCQkvKgorCQkgKiBJZiBUQ1AgVVRPIGlz IGVuYWJsZWQgYnV0IG5vdCBzZXQsIG1ha2UgaXQgY2hhbmdlYWJsZSwKKwkJICogb3RoZXJ3aXNl LCBtYWtlIGl0IHVuY2hhbmdlYWJsZS4KKwkJICovCisJCWlmICghc3RyY21wKGFyZ3ZbMV0sICJ1 dG8iKSkgeworCQkJdXRvLmZsYWdzIHw9IFRDUF9VVE9fRU5BQkxFOworCQkJdXRvLmZsYWdzIHw9 IFRDUF9VVE9fQ0hBTkdFOworCQl9IGVsc2UKKwkJCXVzYWdlKCk7CisJCWlmIChhcmdjID09IDMp IHsKKwkJCXV0by51dG8gPSBzdHJ0b3VsKGFyZ3ZbMl0sICZkdW1teSwgMTApOworCQkJaWYgKHV0 by51dG8gPD0gMCB8fCAqZHVtbXkgIT0gJ1wwJykKKwkJCQl1c2FnZSgpOworCQkJdXRvLmZsYWdz IHw9IFRDUF9VVE9fU1RPUkU7CisJCQl1dG8uZmxhZ3MgJj0gflRDUF9VVE9fQ0hBTkdFOworCQl9 CisJCWlmIChzZXRzb2Nrb3B0KGFjY2VwdF9zb2NrLCBJUFBST1RPX1RDUCwgVENQX1VUTywgJnV0 bywKKwkJICAgIHNpemVvZih1dG8pKSA9PSAtMSkKKwkJCWVycigtMSwgInNldHNvY2tvcHQiKTsK Kwl9CisKKwlvcHR2YWwgPSA0KjEwMjQ7CisJaWYgKHNldHNvY2tvcHQoYWNjZXB0X3NvY2ssIFNP TF9TT0NLRVQsIFNPX1NOREJVRiwgJm9wdHZhbCwKKwkgICAgc2l6ZW9mKG9wdHZhbCkpID09IC0x KQorCQllcnIoLTEsICJzZXRzb2Nrb3B0Iik7CisKKwlmb3IgKDs7KSB7CisJCXNsZWVwKDEpOwor CQl3aGlsZSAocmVjdihhY2NlcHRfc29jaywgYnVmLCA4KjEwMjQsIE1TR19ET05UV0FJVCkgPiAw KQorCQkJOworCQkodm9pZCl0Y3B1dG9fdGltZXIoKTsKKwkJLyoKKwkJICogU2VuZCBtb3JlIGRh dGEgdGhhbiBzb2NrZXQgc2VuZCBidWZmZXIsCisJCSAqIHNvIHRoYXQgZGF0YSBhcmUgbm90IGJ1 ZmZlcmVkLgorCQkgKi8KKwkJaWYgKHNlbmQoYWNjZXB0X3NvY2ssIGJ1ZiwgOCoxMDI0LCBNU0df Tk9TSUdOQUwpID49IDApIHsKKwkJCSh2b2lkKXRjcHV0b190aW1lcigpOworCQkJKHZvaWQpcHJp bnRfdXRvX3N0YXR1cyhhY2NlcHRfc29jaywgMCk7CisJCQljb250aW51ZTsKKwkJfQorCQl1c2Vy X3RpbWVvdXQgPSB0Y3B1dG9fdGltZXIoKTsKKwkJcHJpbnRmKCJDb25uZWN0aW9uIHRpbWVvdXQs ICVkIHNlY29uZHMuXG4iLCB1c2VyX3RpbWVvdXQpOworCQlicmVhazsKKwl9CisJLyogd2FpdCBm b3IgdGhlIHJlc2V0IHBhY2tldCB0byBiZSBjYXB0dXJlZCAqLworCXNsZWVwKDEpOworCSh2b2lk KXB0aHJlYWRfa2lsbCh0aWQsIFNJR1RFUk0pOworCisJY2xvc2UoYWNjZXB0X3NvY2spOworfQor CitzdGF0aWMgdm9pZAordGNwdXRvX2NsaWVudChpbnQgYXJnYywgY2hhciAqYXJndltdKQorewor CXN0cnVjdCBzb2NrYWRkcl9pbiBzaW47CisJbG9uZyBwb3J0OworCWNoYXIgKmR1bW15OworCWNo YXIgYnVmWzgqMTAyNF07CisJaW50IHNvY2s7CisJaW50IHVzZXJfdGltZW91dDsKKwlpbnQgb3B0 dmFsOworCXN0cnVjdCB0Y3B1dG8gdXRvOworCXB0aHJlYWRfdCB0aWQ7CisKKwlpZiAoYXJnYyA8 IDIgJiYgYXJnYyA+IDQpCisJCXVzYWdlKCk7CisKKwliemVybygmc2luLCBzaXplb2Yoc2luKSk7 CisJc2luLnNpbl9sZW4gPSBzaXplb2Yoc2luKTsKKwlzaW4uc2luX2ZhbWlseSA9IEFGX0lORVQ7 CisJaWYgKGluZXRfYXRvbihhcmd2WzBdLCAmc2luLnNpbl9hZGRyKSA9PSAwKQorCQllcnIoLTEs ICJjb252ZXJ0IGFkZHJlc3MiKTsKKworCXBvcnQgPSBzdHJ0b3VsKGFyZ3ZbMV0sICZkdW1teSwg MTApOworCWlmIChwb3J0IDwgMSB8fCBwb3J0ID4gNjU1MzUgfHwgKmR1bW15ICE9ICdcMCcpCisJ CXVzYWdlKCk7CisJc2luLnNpbl9wb3J0ID0gaHRvbnMocG9ydCk7CisJc29jayA9IHNvY2tldChQ Rl9JTkVULCBTT0NLX1NUUkVBTSwgMCk7CisJaWYgKHNvY2sgPT0gLTEpCisJCWVycigtMSwgInNv Y2tldCIpOworCisJb3B0dmFsID0gNCoxMDI0OworCWlmIChzZXRzb2Nrb3B0KHNvY2ssIFNPTF9T T0NLRVQsIFNPX1NOREJVRiwgJm9wdHZhbCwKKwkgICAgc2l6ZW9mKG9wdHZhbCkpID09IC0xKQor CQllcnIoLTEsICJzZXRzb2Nrb3B0Iik7CisKKwlpZiAoYXJnYyA+PSAzKSB7CisJCW1lbXNldCgm dXRvLCAwLCBzaXplb2YodXRvKSk7CisJCS8qCisJCSAqIElmIFRDUCBVVE8gaXMgZW5hYmxlZCBi dXQgbm90IHNldCwgbWFrZSBpdCBjaGFuZ2VhYmxlLAorCQkgKiBvdGhlcndpc2UsIG1ha2UgaXQg dW5jaGFuZ2VhYmxlLgorCQkgKi8KKwkJaWYgKCFzdHJjbXAoYXJndlsyXSwgInV0byIpKSB7CisJ CQl1dG8uZmxhZ3MgfD0gVENQX1VUT19FTkFCTEU7CisJCQl1dG8uZmxhZ3MgfD0gVENQX1VUT19D SEFOR0U7CisJCX0gZWxzZQorCQkJdXNhZ2UoKTsKKwkJaWYgKGFyZ2MgPT0gNCkgeworCQkJdXRv LnV0byA9IHN0cnRvdWwoYXJndlszXSwgJmR1bW15LCAxMCk7CisJCQlpZiAodXRvLnV0byA8PSAw IHx8ICpkdW1teSAhPSAnXDAnKQorCQkJCXVzYWdlKCk7CisJCQl1dG8uZmxhZ3MgfD0gVENQX1VU T19TVE9SRTsKKwkJCXV0by5mbGFncyAmPSB+VENQX1VUT19DSEFOR0U7CisJCX0KKwkJaWYgKHNl dHNvY2tvcHQoc29jaywgSVBQUk9UT19UQ1AsIFRDUF9VVE8sICZ1dG8sCisJCSAgICBzaXplb2Yo dXRvKSkgPT0gLTEpCisJCQllcnIoLTEsICJzZXRzb2Nrb3B0Iik7CisJfQorCisJaWYgKGNvbm5l Y3Qoc29jaywgKHN0cnVjdCBzb2NrYWRkciAqKSZzaW4sIHNpemVvZihzaW4pKSA9PSAtMSkKKwkJ ZXJyKC0xLCAiY29ubmVjdCIpOworCisJaWYgKHB0aHJlYWRfY3JlYXRlKCZ0aWQsIE5VTEwsIGR1 bXBfcGFja2V0LCAodm9pZCAqKSZzb2NrKSkKKwkJZXJyKC0xLCAiY3JlYXRlIHRocmVhZCIpOwor CisJZm9yICg7OykgeworCQlzbGVlcCgxKTsKKwkJd2hpbGUocmVjdihzb2NrLCBidWYsIDgqMTAy NCwgTVNHX0RPTlRXQUlUKSA+IDApCisJCQk7CisJCSh2b2lkKXRjcHV0b190aW1lcigpOworCQkv KgorCQkgKiBTZW5kIG1vcmUgZGF0YSB0aGFuIHNvY2tldCBzZW5kIGJ1ZmZlciwKKwkJICogc28g dGhhdCBkYXRhIGFyZSBub3QgYnVmZmVyZWQuCisJCSAqLworCQlpZiAoc2VuZChzb2NrLCBidWYs IDgqMTAyNCwgTVNHX05PU0lHTkFMKSA+IDApIHsKKwkJCSh2b2lkKXRjcHV0b190aW1lcigpOwor CQkJKHZvaWQpcHJpbnRfdXRvX3N0YXR1cyhzb2NrLCAwKTsKKwkJCWNvbnRpbnVlOworCQl9CisJ CXVzZXJfdGltZW91dCA9IHRjcHV0b190aW1lcigpOworCQlwcmludGYoIkNvbm5lY3Rpb24gdGlt ZW91dCwgJWQgc2Vjb25kcy5cbiIsIHVzZXJfdGltZW91dCk7CisJCWJyZWFrOworCX0KKwkvKiB3 YWl0IGZvciB0aGUgcmVzZXQgcGFja2V0IHRvIGJlIGNhcHR1cmVkICovCisJc2xlZXAoMSk7CisJ KHZvaWQpcHRocmVhZF9raWxsKHRpZCwgU0lHVEVSTSk7CisKKwljbG9zZShzb2NrKTsKK30KKwor aW50CittYWluKGludCBhcmdjLCBjaGFyICphcmd2W10pCit7CisJaW50IHV0b3ZhbDsKKworCWlm IChhcmdjIDwgMikKKwkJdXNhZ2UoKTsKKworCWlmIChzdHJjbXAoYXJndlsxXSwgInNlcnZlciIp ID09IDApCisJCXRjcHV0b19zZXJ2ZXIoYXJnYyAtIDIsIGFyZ3YgKyAyKTsKKwllbHNlIGlmIChz dHJjbXAoYXJndlsxXSwgImNsaWVudCIpID09IDApCisJCXRjcHV0b19jbGllbnQoYXJnYyAtIDIs IGFyZ3YgKyAyKTsKKwllbHNlCisJCXVzYWdlKCk7CisJCisJKHZvaWQpcHJpbnRfdXRvX3N0YXR1 cygtMSwgMSk7CisJcHJpbnRfcmVzdWx0KCk7CisKKwlleGl0KDApOworfQorCgpQcm9wZXJ0eSBj aGFuZ2VzIG9uOiB0b29scy9yZWdyZXNzaW9uL25ldGluZXQvdGNwdXRvL3RjcHV0by5jCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KQWRkZWQ6IHN2bjptaW1lLXR5cGUKICAgKyB0ZXh0L3BsYWluCkFkZGVkOiBzdm46a2V5 d29yZHMKICAgKyBGcmVlQlNEPSVICkFkZGVkOiBzdm46ZW9sLXN0eWxlCiAgICsgbmF0aXZlCgpJ bmRleDogdG9vbHMvcmVncmVzc2lvbi9uZXRpbmV0L3RjcHV0by9NYWtlZmlsZQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Ci0tLSB0b29scy9yZWdyZXNzaW9uL25ldGluZXQvdGNwdXRvL01ha2VmaWxlCShyZXZpc2lvbiAw KQorKysgdG9vbHMvcmVncmVzc2lvbi9uZXRpbmV0L3RjcHV0by9NYWtlZmlsZQkocmV2aXNpb24g MCkKQEAgLTAsMCArMSw4IEBACisjICRGcmVlQlNEJAorCitQUk9HPQl0Y3B1dG8KK0RQQUREPQkk e0xJQlBDQVB9ICR7TElCUFRIUkVBRH0KK0xEQUREPQktbHBjYXAgLWxwdGhyZWFkCitOT19NQU49 CisKKy5pbmNsdWRlIDxic2QucHJvZy5taz4KClByb3BlcnR5IGNoYW5nZXMgb246IHRvb2xzL3Jl Z3Jlc3Npb24vbmV0aW5ldC90Y3B1dG8vTWFrZWZpbGUKX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpBZGRlZDogc3ZuOm1p bWUtdHlwZQogICArIHRleHQvcGxhaW4KQWRkZWQ6IHN2bjprZXl3b3JkcwogICArIEZyZWVCU0Q9 JUgKQWRkZWQ6IHN2bjplb2wtc3R5bGUKICAgKyBuYXRpdmUKCkluZGV4OiB0b29scy9yZWdyZXNz aW9uL25ldGluZXQvdGNwdXRvL1JFQURNRQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0b29scy9yZWdyZXNzaW9u L25ldGluZXQvdGNwdXRvL1JFQURNRQkocmV2aXNpb24gMCkKKysrIHRvb2xzL3JlZ3Jlc3Npb24v bmV0aW5ldC90Y3B1dG8vUkVBRE1FCShyZXZpc2lvbiAwKQpAQCAtMCwwICsxLDIzIEBACit0Y3B1 dG8gLSBhIHNpbXBsZSBUQ1AgdXNlciB0aW1lb3V0IHRlc3QgdG9vbAorLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KKwordGNwdXRvIGdlbmVyYXRlcyBUQ1AgY29u bmVjdGlvbnMgYmV0d2VlbiBhICdjbGllbnQnIGFuZCBhICdzZXJ2ZXInLiAgVGhlCitjbGllbnQg YW5kIHNlcnZlciB3cml0ZXMgYSBmaXggYnl0ZSBzdHJlYW0gdXNpbmcgd3JpdGUgc2l6ZXMgdGhh dCBncmVhdGVyCit0aGFuIHNvY2tldCBvdXRwdXQgYnVmZmVyIGFuZCByZWFkcyBhbGwgYXZhaWxh YmxlIGJ5dGVzIGluIG5vbmJsb2NrIG1vZGUuCitUbyBydW4gVENQIHVzZXIgdGltZW91dCB0ZXN0 LCB0aGUgVENQIGNvbm5lY3Rpb24gbXVzdCBiZSBicm9rZW4gd2l0aG91dAorZGV0ZWN0ZWQgYnkg b3BlcmF0aW5nIHN5c3RlbSwgZm9yIGV4YW1wbGUsIGJyaW5nIGRvd24gYW4gaW50ZXJtZWRpYXRl IAorcm91dGVyIHRoYXQgZG9lcyBub3QgY29ubmVjdCB0byB0aGUgY2xpZW50IG9yIHNlcnZlciBk aXJlY3RseS4gIFRoZW4sIHNlbGVjdAorYSBwb3J0IG51bWJlciAoZm9yIHRoZSBjbGllbnQgYW5k IHNlcnZlcikgYW5kIGRlY2lkZSB3aGV0aGVyIGVuYWJsZSBUQ1AgdXNlcgordGltZW91dCBhbmQg dGhlIHZhbHVlIG9mIHVzZXIgdGltZW91dCB0byBzZW5kLiAgVHlwaWNhbCB1c2UgbWlnaHQgYmU6 CisKK1J1biB0aGUgc2VydmVyIG9uIHBvcnQgODA4MCBhbmQgZW5hYmxlIFRDUCB1c2VyIHRpbWVv dXQ6CisKKyAgICB0Y3B1dG8gc2VydmVyIDgwODAgdXRvCisKK05vdyBydW4gdGhlIGNsaWVudCBv biBhIHNlY29uZCBtYWNoaW5lIHdpdGggdGhlIHNlcnZlcidzIElQLCBwb3J0IDgwODAsIGVuYWJs ZQorVENQIHVzZXIgdGltZW91dCwgYW5kIHNlbmQgYSA3MDAgc2Vjb25kcyB1c2VyIHRpbWVvdXQg dmFsdWU6CisKKyAgICB0Y3B1dG8gY2xpZW50IDE5Mi4xNjguMTAuMTAgODA4MCB1dG8gNzAwCisK K0FmdGVyIHRoYXQsIGludGVycnVwdCB0aGUgY29ubmVjdGlvbiB3aXRob3V0IGRldGVjdGVkIGJ5 IG9wZXJhdGluZyBzeXN0ZW0sIGFuZAord2FpdCB1bnRpbCBwcm9jZXNzIGV4aXRzLgo= --0050450176f461d4580472878f74-- From owner-freebsd-net@FreeBSD.ORG Tue Sep 1 23:30: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 439BE1065679 for ; Tue, 1 Sep 2009 23:30:35 +0000 (UTC) (envelope-from glen.j.barber@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id D01E48FC18 for ; Tue, 1 Sep 2009 23:30:34 +0000 (UTC) Received: by fxm6 with SMTP id 6so414781fxm.43 for ; Tue, 01 Sep 2009 16:30:34 -0700 (PDT) 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=YbYUYgYjg9DdMvQY2lk5LKop4amhldO/3mxnIWRdQ5w=; b=iWnwTYEenhktqNfkcvtqDGNiW0g/QItT/IR/yrRu5/9pol3tzBm2CTrbra0/SS/jzn yPKJGuO5PK5AboEZg0TwvDGa4lC6i9FSGEyWAo5MDFp2NDYGGCe/rdPCVZBRXagg+gib RghWAajeyo0nQgz0be1YplsGOnplX0TqDoHXA= 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=gZQ3VW+F2uqerSaWbRngAPuIL/pB3o80pNBBuDHnwaGtlBiW/f1ub23MMV7LsO/MBp HkSh6UFVbLnm3j2pPPI2dze6kgep/IXRECMeEb9e37Z9SmZLcTx1Evt0nfAXpqgCqf3c Bzype31qGkzG+DMluSHm/gzRxlm5Wi8eGeVOo= MIME-Version: 1.0 Received: by 10.223.4.148 with SMTP id 20mr3309791far.0.1251847834010; Tue, 01 Sep 2009 16:30:34 -0700 (PDT) In-Reply-To: <25243305.post@talk.nabble.com> References: <25243305.post@talk.nabble.com> Date: Tue, 1 Sep 2009 19:30:33 -0400 Message-ID: <4ad871310909011630k3cbd8596nd57ec60270f4fe7b@mail.gmail.com> From: Glen Barber To: rconan Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Intel 5100 AGN Wifi 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, 01 Sep 2009 23:30:35 -0000 On Tue, Sep 1, 2009 at 12:15 PM, rconan wrote: > > Hi > > I have a laptop with an Intel 5100 AGN Wifi adapter. > Is there a driver for FreeBSD 7.2? > Hi, Last I saw a list post about this, the driver is not yet being worked on. I would imagine that is partly due to getting 8.0-RELEASE out, but I am only speculating. If you search the list archives, you can find the recent conversations. Cheers, -- Glen Barber From owner-freebsd-net@FreeBSD.ORG Wed Sep 2 07:00: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 D8A4B1065670; Wed, 2 Sep 2009 07:00:51 +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 636948FC0C; Wed, 2 Sep 2009 07:00:51 +0000 (UTC) Received: from delta.allbsd.org (p4121-ipbf1805funabasi.chiba.ocn.ne.jp [114.146.83.121]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id n8270ZXt018655; Wed, 2 Sep 2009 16:00:45 +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 n8270SpE073686; Wed, 2 Sep 2009 16:00:29 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 02 Sep 2009 15:59:58 +0900 (JST) Message-Id: <20090902.155958.08019398.hrs@allbsd.org> To: qing.li@bluecoat.com From: Hiroki Sato In-Reply-To: References: <20090830.024420.174808572.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.2.51 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(Wed_Sep__2_15_59_58_2009_896)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.allbsd.org [133.31.130.32]); Wed, 02 Sep 2009 16:00:46 +0900 (JST) Cc: qingli@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: IPv6 regression on 8.x 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, 02 Sep 2009 07:00:51 -0000 ----Security_Multipart(Wed_Sep__2_15_59_58_2009_896)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Li, Qing" wrote in : qi> Hi Hiroki, qi> qi> > qi> > 2) Issue of subnet-router anycast address with a global address qi> > qi> > Thanks for the fixes! With the two patches 1) and 3) are gone, but qi> > 2) still remains. Is there something I can help to narrow down it? qi> > qi> qi> Hmm... I tried multiple test cases and all seem to work as expected. qi> I also tried the exact configuration sequence as you outlined in your qi> original bug report email, and that case worked, too. qi> qi> The only difference I can see from the given information, is I have qi> 3 em interfaces, whereas you have 2 em interfaces and 1 re, but I qi> don't see how that would make a difference. I think reproduction of the case 2) needs two boxes. One has two NICs and another has one NIC, and the three NICs are connected with a subnet independent from each other. Anyway, I will try the a-box-with-three-NICs case when I return home today. I didn't try it. qi> Would it be possible for you to email me your system configuration qi> produced from "ifconfig" and "netstat" privately ? Sure. I will send them to you later. -- Hiroki ----Security_Multipart(Wed_Sep__2_15_59_58_2009_896)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkqeF+4ACgkQTyzT2CeTzy0BAgCg2RR7Xmiweyt/lHnwT3Q3zQuk OBsAn0a4V/KdeinizFgCvUy3dJfVit4D =9jCd -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Sep__2_15_59_58_2009_896)---- From owner-freebsd-net@FreeBSD.ORG Wed Sep 2 12:07: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 825D91065679 for ; Wed, 2 Sep 2009 12:07:12 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [74.82.45.72]) by mx1.freebsd.org (Postfix) with ESMTP id 764D68FC19 for ; Wed, 2 Sep 2009 12:07:11 +0000 (UTC) Resent-Message-Id: From: Stef Walter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "freebsd-net@FreeBSD.org" References: <20090820042016.C8F913039754@mx.npubs.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Resent-Date: Wed, 2 Sep 2009 12:07:12 +0000 (UTC) Resent-From: stef-list@memberwebs.com X-Mailman-Approved-At: Wed, 02 Sep 2009 12:20:16 +0000 Subject: Re: ath0: ath_rx_proc: no mbuf! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 02 Sep 2009 12:07:12 -0000 X-List-Received-Date: Wed, 02 Sep 2009 12:07:12 -0000 Stef Walter wrote: > A short while ago (perhaps due to a change in traffic), every few hours, > the wireless interface becomes unresponsive, and I started seeing > thousands of lines like this in: > > ath0: ath_rx_proc: no mbuf! > ath0: ath_rx_proc: no mbuf! > ath0: ath_rx_proc: no mbuf! > ath0: ath_rx_proc: no mbuf! > ath0: ath_rx_proc: no mbuf! For the record. It was a hardware problem. Cheers, Stef From owner-freebsd-net@FreeBSD.ORG Wed Sep 2 15:02:13 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 1A48110656A3 for ; Wed, 2 Sep 2009 15:02:13 +0000 (UTC) (envelope-from sinister@gmail.com) Received: from mail-yw0-f185.google.com (mail-yw0-f185.google.com [209.85.211.185]) by mx1.freebsd.org (Postfix) with ESMTP id C07328FC2B for ; Wed, 2 Sep 2009 15:02:12 +0000 (UTC) Received: by ywh15 with SMTP id 15so2656431ywh.10 for ; Wed, 02 Sep 2009 08:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:subject :date:mime-version:content-type:x-priority:x-msmail-priority :x-mailer:x-mimeole; bh=ipOb24+dBq13hjNV+LppVI2klilW87gxWGDbYOxwix0=; b=GMFBT5xvr08Zglja5Rb1ua6KcvLrOozzk4gqdcJU5DAlvTmUot6dRUqQL2uoRQ69WA 1siZqypZgOCJkaV8ozLLgAcxMqXxlKcLz8qo+kTmRp4qLkpr8YHRCT8lfkQ+xnIR8TIi 7hYo4YQdWL/04JVf8q0eLD3wfaklPhznKS/Vk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:subject:date:mime-version:content-type :x-priority:x-msmail-priority:x-mailer:x-mimeole; b=OImyRJxV3+GfxXOXNRfkXe+B/FajK28bneCPnZqcogSNjEkRAeUq0fmgcFQsSvtTyw y3SDv3cNMixq0A04aq4g/XDfTL3vc2nBU7Sx1AridS9z7BqsCqhM2N9R8NNT1k1SLeof Gp88gJYUdlKIhTlB3Y7lvdRJC6oLByi5/wMKI= Received: by 10.91.143.18 with SMTP id v18mr6176440agn.71.1251903731737; Wed, 02 Sep 2009 08:02:11 -0700 (PDT) Received: from dts (markofthebeast.ca [216.8.139.47]) by mx.google.com with ESMTPS id 30sm11787agc.19.2009.09.02.08.02.10 (version=SSLv3 cipher=RC4-MD5); Wed, 02 Sep 2009 08:02:10 -0700 (PDT) Message-ID: <4790A7EF670C4698ADB76933788A218F@dts> From: Sin To: Date: Wed, 2 Sep 2009 11:02:07 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: toggle short / long preamble with hostapd 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, 02 Sep 2009 15:02:13 -0000 Hello, Does anyone know how to enable short preamble in 7-STABLE ? I'm using ath with hostapd in ap mode. It seems there was an option in = hostapd.conf, but this is not in FreeBSD's = /usr/share/examples/hostapd/hostapd.conf The missing hostapd.conf option was found in google: # Short Preamble # This parameter can be used to enable optional use of short preamble = for # frames sent at 2 Mbps, 5.5 Mbps, and 11 Mbps to improve network = performance. # This applies only to IEEE 802.11b-compatible networks and this should = only be # enabled if the local hardware supports use of short preamble. If any = of the # associated STAs do not support short preamble, use of short preamble = will be # disabled (and enabled when such STAs disassociate) dynamically. # 0 =3D do not allow use of short preamble (default) # 1 =3D allow use of short preamble #preamble=3D1 my version of hostapd is " v0.5.10 " - I was not able to set this option hostapd.conf: interface=3Dath0 #preamble=3D1 debug=3D1 ctrl_interface=3D/var/run/hostapd ctrl_interface_group=3Dwheel ssid=3Dprivate wpa=3D1 wpa_passphrase=3Dapassword wpa_key_mgmt=3DWPA-PSK wpa_pairwise=3DTKIP rc.conf: hostapd_enable=3D"YES" ifconfig_ath0=3D"mode 11g hidessid mediaopt hostap" ifconfig ath0: ath0: flags=3D8943 = metric 0 mtu 1500 ether 00:17:9a:4c:e7:83 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g = status: associated ssid private channel 1 (2412 Mhz 11g) bssid 00:17:9a:4c:e7:83 authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP = 3:128-bit txpower 31.5 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 roam:rssi11g 7 roam:rate11g 5 protmode CTS burst hidessid = dtimperiod 1 From owner-freebsd-net@FreeBSD.ORG Wed Sep 2 15:16: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 9BBB01065676 for ; Wed, 2 Sep 2009 15:16:57 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id 567EB8FC21 for ; Wed, 2 Sep 2009 15:16:57 +0000 (UTC) Received: from ice.local ([10.0.0.115]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n82FGuMY026393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Sep 2009 08:16:56 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4A9E8C68.3060300@errno.com> Date: Wed, 02 Sep 2009 08:16:56 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Sin References: <4790A7EF670C4698ADB76933788A218F@dts> In-Reply-To: <4790A7EF670C4698ADB76933788A218F@dts> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org Subject: Re: toggle short / long preamble with hostapd 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, 02 Sep 2009 15:16:57 -0000 Sin wrote: > Hello, > > > Does anyone know how to enable short preamble in 7-STABLE ? > > I'm using ath with hostapd in ap mode. It seems there was an option in hostapd.conf, but this is not in FreeBSD's /usr/share/examples/hostapd/hostapd.conf > > > The missing hostapd.conf option was found in google: > > # Short Preamble > # This parameter can be used to enable optional use of short preamble for > # frames sent at 2 Mbps, 5.5 Mbps, and 11 Mbps to improve network performance. > # This applies only to IEEE 802.11b-compatible networks and this should only be > # enabled if the local hardware supports use of short preamble. If any of the > # associated STAs do not support short preamble, use of short preamble will be > # disabled (and enabled when such STAs disassociate) dynamically. > # 0 = do not allow use of short preamble (default) > # 1 = allow use of short preamble > #preamble=1 > > > my version of hostapd is " v0.5.10 " - I was not able to set this option On freebsd hostapd is _purely_ an authenticator; to configure 802.11 parameters you use ifconfig. > > > hostapd.conf: > > interface=ath0 > #preamble=1 > debug=1 > ctrl_interface=/var/run/hostapd > ctrl_interface_group=wheel > ssid=private > wpa=1 > wpa_passphrase=apassword > wpa_key_mgmt=WPA-PSK > wpa_pairwise=TKIP > > > > rc.conf: > > hostapd_enable="YES" > ifconfig_ath0="mode 11g hidessid mediaopt hostap" > > > > ifconfig ath0: > > ath0: flags=8943 metric 0 mtu 1500 > ether 00:17:9a:4c:e7:83 > media: IEEE 802.11 Wireless Ethernet autoselect mode 11g > status: associated > ssid private channel 1 (2412 Mhz 11g) bssid 00:17:9a:4c:e7:83 > authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP 3:128-bit > txpower 31.5 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 > roam:rssi11g 7 roam:rate11g 5 protmode CTS burst hidessid dtimperiod 1 In ap mode you should not manually configure preamble; it should be selected according to the associated stations. What are you trying to accomplish? Sam From owner-freebsd-net@FreeBSD.ORG Wed Sep 2 15:34: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 4E8191065676 for ; Wed, 2 Sep 2009 15:34:31 +0000 (UTC) (envelope-from sinister@gmail.com) Received: from mail-yx0-f202.google.com (mail-yx0-f202.google.com [209.85.210.202]) by mx1.freebsd.org (Postfix) with ESMTP id F35268FC17 for ; Wed, 2 Sep 2009 15:34:29 +0000 (UTC) Received: by yxe40 with SMTP id 40so1304464yxe.13 for ; Wed, 02 Sep 2009 08:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:cc :references:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=8rMPhDHmMd6En8yEIKDAC8KXLLfBE/z+7YaNUTtsOGU=; b=UczebDkQFz0dCOHSQ5tCPKTrnO9afWcIhx9d65S36X3wHnSMhVPJURBfueoq/uuUcN RKsskUQjVn/egbkT5sftMz9Xxq/pvPj6AR+r2jt5PExR1EAGoL2r2D8NpdMpK7YV9x0s RjiEuYZeEY1+wt+nKy70TKdnB+zM24zx48C5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=IrYUjeZaVR4bVoKDwuoL9weGHtvVhBpke3+2iXWWpnVdOf7Fd2ZlWPtuUnNgUYD3UR fy/Y+dW8PvUx6xtiIhmfpKyWAn7cnRPJRtGR3xukvFjLltq5YxcCjVd6GiOwwPvgZaLn Q56H2FqmH3HE7BmVj8ljfgmgjiLA16BMCqHcY= Received: by 10.90.149.6 with SMTP id w6mr6196289agd.90.1251905669191; Wed, 02 Sep 2009 08:34:29 -0700 (PDT) Received: from dts (markofthebeast.ca [216.8.139.47]) by mx.google.com with ESMTPS id 39sm68181aga.21.2009.09.02.08.34.27 (version=SSLv3 cipher=RC4-MD5); Wed, 02 Sep 2009 08:34:28 -0700 (PDT) Message-ID: From: Sin To: "Sam Leffler" , "Sin" References: <4790A7EF670C4698ADB76933788A218F@dts> <4A9E8C68.3060300@errno.com> Date: Wed, 2 Sep 2009 11:34:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: freebsd-net@freebsd.org Subject: Re: toggle short / long preamble with hostapd 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, 02 Sep 2009 15:34:31 -0000 Sam, Basically I have a dlink WBR-1310 thats in bridge mode connected to my current BSD router ( 6.3) I'm trying to replace this 1310 product with FreeBSD 7. The last problem i'm dealing with is poor preformance. When I use my current BSD 7 setup it works, but ping times from client to another or even to the access point are bad. 100 - 400ms round trip. I had this exact problem with the 1310. The fix was to change from long to short preable. Been fine ever since. I used three computers to prove this before emailing. Just swapping the 1310 for the 7-STABLE corrects this. The 1310 uses g only mode with short preamble getting less then 5ms ping times to each client and host and vice-versa I realize that hostapd.conf is just for the encryption. However ifconfig and ath man pages do not talk about this setting. ----- Original Message ----- From: "Sam Leffler" To: "Sin" Cc: Sent: Wednesday, September 02, 2009 11:16 AM Subject: Re: toggle short / long preamble with hostapd > Sin wrote: >> Hello, >> >> >> Does anyone know how to enable short preamble in 7-STABLE ? >> >> I'm using ath with hostapd in ap mode. It seems there was an option in >> hostapd.conf, but this is not in FreeBSD's >> /usr/share/examples/hostapd/hostapd.conf >> >> >> The missing hostapd.conf option was found in google: >> >> # Short Preamble >> # This parameter can be used to enable optional use of short preamble for >> # frames sent at 2 Mbps, 5.5 Mbps, and 11 Mbps to improve network >> performance. >> # This applies only to IEEE 802.11b-compatible networks and this should >> only be >> # enabled if the local hardware supports use of short preamble. If any of >> the >> # associated STAs do not support short preamble, use of short preamble >> will be >> # disabled (and enabled when such STAs disassociate) dynamically. >> # 0 = do not allow use of short preamble (default) >> # 1 = allow use of short preamble >> #preamble=1 >> >> >> my version of hostapd is " v0.5.10 " - I was not able to set this option > > On freebsd hostapd is _purely_ an authenticator; to configure 802.11 > parameters you use ifconfig. > >> >> >> hostapd.conf: >> >> interface=ath0 >> #preamble=1 >> debug=1 >> ctrl_interface=/var/run/hostapd >> ctrl_interface_group=wheel >> ssid=private >> wpa=1 >> wpa_passphrase=apassword >> wpa_key_mgmt=WPA-PSK >> wpa_pairwise=TKIP >> >> >> >> rc.conf: >> >> hostapd_enable="YES" >> ifconfig_ath0="mode 11g hidessid mediaopt hostap" >> >> >> >> ifconfig ath0: >> >> ath0: flags=8943 metric 0 >> mtu 1500 >> ether 00:17:9a:4c:e7:83 >> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g >> status: associated >> ssid private channel 1 (2412 Mhz 11g) bssid 00:17:9a:4c:e7:83 >> authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP >> 3:128-bit >> txpower 31.5 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 >> roam:rssi11g 7 roam:rate11g 5 protmode CTS burst hidessid >> dtimperiod 1 > > In ap mode you should not manually configure preamble; it should be > selected according to the associated stations. What are you trying to > accomplish? > > Sam > From owner-freebsd-net@FreeBSD.ORG Wed Sep 2 19: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 D1139106566B; Wed, 2 Sep 2009 19:41:05 +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 AFF308FC14; Wed, 2 Sep 2009 19:41:04 +0000 (UTC) Received: from delta.allbsd.org (p4121-ipbf1805funabasi.chiba.ocn.ne.jp [114.146.83.121]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id n82JenRE032730; Thu, 3 Sep 2009 04:41:00 +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 n82Jefhh074585; Thu, 3 Sep 2009 04:40:43 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 03 Sep 2009 04:38:40 +0900 (JST) Message-Id: <20090903.043840.213910223.hrs@allbsd.org> To: qing.li@bluecoat.com From: Hiroki Sato In-Reply-To: <20090902.155958.08019398.hrs@allbsd.org> References: <20090830.024420.174808572.hrs@allbsd.org> <20090902.155958.08019398.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.2.51 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_Sep__3_04_38_40_2009_684)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.2 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.allbsd.org [133.31.130.32]); Thu, 03 Sep 2009 04:41:00 +0900 (JST) Cc: qingli@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-net@FreeBSD.org Subject: Re: IPv6 regression on 8.x 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, 02 Sep 2009 19:41:05 -0000 ----Security_Multipart(Thu_Sep__3_04_38_40_2009_684)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hiroki Sato wrote in <20090902.155958.08019398.hrs@allbsd.org>: hr> Anyway, I will try the a-box-with-three-NICs case when I return home hr> today. I didn't try it. Okay, I tried the case of all of NICs on a host and confirmed it works fine. hr> hr> qi> Would it be possible for you to email me your system configuration hr> qi> produced from "ifconfig" and "netstat" privately ? hr> hr> Sure. I will send them to you later. The results of ifconfig and netstat are the following. These are by another configuration from one I sent in the previous email, but the symptom is still reproducible: box-A (RELENG_7): re0: flags=8843 metric 0 mtu 1500 ether 00:26:18:41:64:1a inet6 fe80::226:18ff:fe41:641a%re0 prefixlen 64 scopeid 0x2 inet6 2001:db8:1::6 prefixlen 64 Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default fe80::21a:6dff:feb9:fd1b%ng1 UGS ng1 ::1 ::1 UHL lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 2001:db8:1:: 00:13:a9:ff:63:e6 UHLW re0 => 2001:db8:1::/64 link#2 UC re0 2001:db8:1::1 00:13:a9:ff:63:e6 UHLW re0 2001:db8:1::6 00:26:18:41:64:1a UHL lo0 box-B (CURRENT): msk0: flags=8843 metric 0 mtu 1500 ether 00:13:a9:ff:63:e6 inet6 fe80::213:a9ff:feff:63e6%msk0 prefixlen 64 scopeid 0x1 inet6 2001:db8:1:: prefixlen 64 anycast gif0: flags=8011 metric 0 mtu 1280 inet6 2001:db8:2::1 prefixlen 64 inet6 fe80::213:a9ff:feff:63e6%gif0 prefixlen 64 scopeid 0x7 Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 => default fe80::214:1bff:fe39:281a%msk0 UG msk0 ::1 ::1 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 2001:db8:1:: link#5 UHS lo0 => 2001:db8:1::/64 link#1 U msk0 2001:db8:2::/64 link#7 U gif0 2001:db8:2::1 link#5 UHS lo0 fe80::/10 ::1 UGRS lo0 fe80::%msk0/64 link#1 U msk0 fe80::213:a9ff:feff:63e6%msk0 link#5 UHS lo0 fe80::%lo0/64 link#5 U lo0 fe80::%gif0/64 link#7 U gif0 fe80::213:a9ff:feff:63e6%gif0 link#5 UHS lo0 ff01:1::/32 fe80::213:a9ff:feff:63e6%msk0 U msk0 ff01:5::/32 ::1 U lo0 ff01:7::/32 2001:db8:2::1 U gif0 ff02::/16 ::1 UGRS lo0 ff02::%msk0/32 fe80::213:a9ff:feff:63e6%msk0 U msk0 ff02::%lo0/32 ::1 U lo0 ff02::%gif0/32 2001:db8:2::1 U gif0 When doing "ping6 2001:db8:1::" from box-A, the source address becomes 2001:db8:1::6 (this is correct) and a link-local address on msk0 on box-B replies. -- Hiroki ----Security_Multipart(Thu_Sep__3_04_38_40_2009_684)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkqeycAACgkQTyzT2CeTzy34JACfTvifjvsyaNPzSqPt+nHVznUh PSoAoIMNJge5B3+o0fIracP05n6ehWbu =ac7z -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Sep__3_04_38_40_2009_684)---- From owner-freebsd-net@FreeBSD.ORG Wed Sep 2 21:17: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 4BF691065670 for ; Wed, 2 Sep 2009 21:17:36 +0000 (UTC) (envelope-from prvs=1496da7ed5=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id D55578FC16 for ; Wed, 2 Sep 2009 21:17:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1251925612; x=1252530412; q=dns/txt; h=Received: Message-ID:From:To:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=buTDDi3BYA2wSbafe8eM7 NFIvBgfWmqMNmkkrHWm1io=; b=KiWdI/yLTmLRbdv9S512HTvMvQIbynOhVqGiJ Ny0A71kE2DEJXXmKQwkf5IbEBynRCuyefbpBkaQS3SBGyuoCINxLE0w9WF7ilaNa 3zG/HWbslNQwvBpATjo1nkLtN+irLh89GpkgV4TL7OFgYfCxeEux4vfcqnhgNnXp Obfc+E= X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 02 Sep 2009 22:06:52 +0100 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v10.0.4) with ESMTP id md50008162256.msg for ; Wed, 02 Sep 2009 22:06:51 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 02 Sep 2009 22:06:51 +0100 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=1496da7ed5=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@FreeBSD.org Message-ID: <59E03381ABC6401B9572DB1BD3302543@multiplay.co.uk> From: "Steven Hartland" To: "David Christensen" , "DutchDaemon" , References: <200906011450.n51Eo3Wp095320@freefall.freebsd.org><5CC0D128FDDD4BFBA815E2D8D388B2DF@multiplay.co.uk><5D267A3F22FD854F8F48B3D2B523819339EC2B524E@IRVEXCHCCR01.corp.ad.broadcom.com> Date: Wed, 2 Sep 2009 22:06:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: Subject: Re: kern/134658: [bce] bce driver fails on PowerEdge m610 blade. 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, 02 Sep 2009 21:17:36 -0000 Any news on the driver update for 5709S yet Dave? Regards Steve ----- Original Message ----- From: "Steven Hartland" > Thanks for the update David, if there is anything we can do > to help let us know. > > Regards > Steve > > ----- Original Message ----- > From: "David Christensen" > >> Anyone point me in the right direction on how to add the phy >> to support these machine? >> >> Seems like its just a matter of adding the PHY details to >> miidevs but how do I find out the specifics of that? > > Sorry, this is the 5709S and I haven't had an opportunity to > implement this PHY yet. Unfortunately it's more than just a > change to miidevs since the SerDes is actually an IEEE clause > 45 compliant device (instead of the more common Clause 22 > devices found in 1GbE controllers). The registers are > diffrerent so the effort is more substantial. No estimate > yet on when I can get to it. > > Dave ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Thu Sep 3 18:04: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 282371065672 for ; Thu, 3 Sep 2009 18:04:16 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id D472F8FC08 for ; Thu, 3 Sep 2009 18:04:15 +0000 (UTC) Received: from ice.local ([10.0.0.115]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n83I4FWP034651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Sep 2009 11:04:15 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4AA0051F.8080202@errno.com> Date: Thu, 03 Sep 2009 11:04:15 -0700 From: Sam Leffler User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Sin References: <4790A7EF670C4698ADB76933788A218F@dts> <4A9E8C68.3060300@errno.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-Misty-Metrics: ebb.errno.com; whitelist Cc: freebsd-net@freebsd.org Subject: Re: toggle short / long preamble with hostapd 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, 03 Sep 2009 18:04:16 -0000 If I understand correctly you say that you have stations associated to a FreeBSD 7 ap operating in 11g and pings between the clients are slow. This occurred w/ the Dlink AP you're trying to replace until you manually forced short preamble. If I've got it right then this doesn't make sense as the ap should be using short preamble unless there are non-ERP stations on the channel. You can trace the status of short/long preamble with: wlandebug +assoc (you should get console msgs that when stations associate that indicate whether protection is enabled). I believe you'll also get the same info with: ifconfig wlan0 list sta on the ap. All this applies to 8.x; I've long since forgotten how things work on 7.x and I'd recommend that if you're doing a new install you use 8.0 and not 7.x. In general forcing short preamble should not have the effect you describe; just the opposite. If you want to figure out what's really going on then try to turn off stations that might be interfering (if possible). Otherwise you might try moving to a different channel to avoid whatever station is interfering. Another possibility is one or both stations are in power save mode and there's a bug in the RELENG_7 ap support; wlandebug +power might help for that. I can look at adding a knob to force short/long preamble. It would go into HEAD though and can't promise to backport to RELENG_7. Sam Sin wrote: > Sam, > > Basically I have a dlink WBR-1310 thats in bridge mode connected to my > current BSD router ( 6.3) I'm trying to replace this 1310 product with > FreeBSD 7. The last problem i'm dealing with is poor preformance. > When I use my current BSD 7 setup it works, but ping times from client > to another or even to the access point are bad. 100 - 400ms round > trip. I had this exact problem with the 1310. The fix was to change > from long to short preable. Been fine ever since. > > I used three computers to prove this before emailing. Just swapping > the 1310 for the 7-STABLE corrects this. The 1310 uses g only mode > with short preamble getting less then 5ms ping times to each client and > host and vice-versa > > I realize that hostapd.conf is just for the encryption. However > ifconfig and ath man pages do not talk about this setting. > > > ----- Original Message ----- From: "Sam Leffler" > To: "Sin" > Cc: > Sent: Wednesday, September 02, 2009 11:16 AM > Subject: Re: toggle short / long preamble with hostapd > > >> Sin wrote: >>> Hello, >>> >>> >>> Does anyone know how to enable short preamble in 7-STABLE ? >>> >>> I'm using ath with hostapd in ap mode. It seems there was an option >>> in hostapd.conf, but this is not in FreeBSD's >>> /usr/share/examples/hostapd/hostapd.conf >>> >>> >>> The missing hostapd.conf option was found in google: >>> >>> # Short Preamble >>> # This parameter can be used to enable optional use of short preamble >>> for >>> # frames sent at 2 Mbps, 5.5 Mbps, and 11 Mbps to improve network >>> performance. >>> # This applies only to IEEE 802.11b-compatible networks and this >>> should only be >>> # enabled if the local hardware supports use of short preamble. If >>> any of the >>> # associated STAs do not support short preamble, use of short >>> preamble will be >>> # disabled (and enabled when such STAs disassociate) dynamically. >>> # 0 = do not allow use of short preamble (default) >>> # 1 = allow use of short preamble >>> #preamble=1 >>> >>> >>> my version of hostapd is " v0.5.10 " - I was not able to set this option >> >> On freebsd hostapd is _purely_ an authenticator; to configure 802.11 >> parameters you use ifconfig. >> >>> >>> >>> hostapd.conf: >>> >>> interface=ath0 >>> #preamble=1 >>> debug=1 >>> ctrl_interface=/var/run/hostapd >>> ctrl_interface_group=wheel >>> ssid=private >>> wpa=1 >>> wpa_passphrase=apassword >>> wpa_key_mgmt=WPA-PSK >>> wpa_pairwise=TKIP >>> >>> >>> >>> rc.conf: >>> >>> hostapd_enable="YES" >>> ifconfig_ath0="mode 11g hidessid mediaopt hostap" >>> >>> >>> >>> ifconfig ath0: >>> >>> ath0: flags=8943 >>> metric 0 mtu 1500 >>> ether 00:17:9a:4c:e7:83 >>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g >>> >>> status: associated >>> ssid private channel 1 (2412 Mhz 11g) bssid 00:17:9a:4c:e7:83 >>> authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP >>> 3:128-bit >>> txpower 31.5 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 >>> roam:rssi11g 7 roam:rate11g 5 protmode CTS burst hidessid >>> dtimperiod 1 >> >> In ap mode you should not manually configure preamble; it should be >> selected according to the associated stations. What are you trying to >> accomplish? >> >> Sam >> > > From owner-freebsd-net@FreeBSD.ORG Thu Sep 3 19:00:01 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 DD60A106566C for ; Thu, 3 Sep 2009 19:00:00 +0000 (UTC) (envelope-from sinister@gmail.com) Received: from mail-yw0-f187.google.com (mail-yw0-f187.google.com [209.85.211.187]) by mx1.freebsd.org (Postfix) with ESMTP id 7A9D38FC15 for ; Thu, 3 Sep 2009 19:00:00 +0000 (UTC) Received: by ywh17 with SMTP id 17so302903ywh.3 for ; Thu, 03 Sep 2009 11:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to:cc :references:subject:date:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=WKwt9jAB+YCYrfxAk5MMgdvjO1Vy7cq19ula7+NjFTs=; b=OWHwaIVO4x/pIg/3J3KtXRNpWG7/iJWMcxdG6d7CwsFa6UgG9U9QAByAdRY2SZDjaD 8PB/oSwi84AwSJ+4x1tZAVA52ZDyjReLls0w7wJL8V+ERBHrlVhNMPMHZUvaSKQr9T4l jh3zS3dzhuU0d86rDX60o/HJ/JQpky+vyhd5I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding:x-priority:x-msmail-priority :x-mailer:x-mimeole; b=VSFz+y4qIMlo0Qf3666R22dFrq/wohR5VoO/uVz66WVwadYTZgoBRc8wcrqatbbnp6 Z4YCm6n3+5OB5W9kCEWFiJeTjYPFVyDPnFFXK2/5ZPjTDihBTi3saVRw3oAt73scYMOP CYudbribl0f0DCauLh3GOeyy2qDEsbjjWwhz4= Received: by 10.91.20.12 with SMTP id x12mr214198agi.19.1252004399355; Thu, 03 Sep 2009 11:59:59 -0700 (PDT) Received: from dts (markofthebeast.ca [216.8.139.47]) by mx.google.com with ESMTPS id 17sm462151agd.66.2009.09.03.11.59.55 (version=SSLv3 cipher=RC4-MD5); Thu, 03 Sep 2009 11:59:57 -0700 (PDT) Message-ID: From: Sin To: "Sam Leffler" , "Sin" References: <4790A7EF670C4698ADB76933788A218F@dts> <4A9E8C68.3060300@errno.com> <4AA0051F.8080202@errno.com> Date: Thu, 3 Sep 2009 14:59:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: freebsd-net@freebsd.org Subject: Re: toggle short / long preamble with hostapd 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, 03 Sep 2009 19:00:01 -0000 Sam, You understand correctly. I should of mentioned also before with high latency comes packet loss, around 15 %. Setting short preamble makes this 1 % or less. So you are right - this doesn't make sense. If I've read this correctly, short preamble is enabled. So I do the ping tests from each machine including the AP and latency is back to under 2ms. test# ifconfig ath0 list sta ADDR AID CHAN RATE RSSI IDLE TXSEQ RXSEQ CAPS FLAG 00:18:de:22:13:f1 1 10 36M 29.5 0 146 34480 EPS AE WPA 00:18:39:15:c6:24 2 10 48M 36.0 0 140 32160 EPS AE WPA I was using channel 1 before in the first email because it was free ( found it free with ifconfig ath0 up scan ) I'm wondering if just changing to channel 10 was the real fix. I wll take your advice and move everything to 8.0. Having the option in any version to force preamble mode would be a nice feature. ----- Original Message ----- From: "Sam Leffler" To: "Sin" Cc: Sent: Thursday, September 03, 2009 2:04 PM Subject: Re: toggle short / long preamble with hostapd > If I understand correctly you say that you have stations associated to a > FreeBSD 7 ap operating in 11g and pings between the clients are slow. This > occurred w/ the Dlink AP you're trying to replace until you manually > forced short preamble. If I've got it right then this doesn't make sense > as the ap should be using short preamble unless there are non-ERP stations > on the channel. You can trace the status of short/long preamble with: > > wlandebug +assoc > > (you should get console msgs that when stations associate that indicate > whether protection is enabled). I believe you'll also get the same info > with: > > ifconfig wlan0 list sta > > on the ap. All this applies to 8.x; I've long since forgotten how things > work on 7.x and I'd recommend that if you're doing a new install you use > 8.0 and not 7.x. > > In general forcing short preamble should not have the effect you describe; > just the opposite. If you want to figure out what's really going on then > try to turn off stations that might be interfering (if possible). > Otherwise you might try moving to a different channel to avoid whatever > station is interfering. Another possibility is one or both stations are > in power save mode and there's a bug in the RELENG_7 ap support; wlandebug > +power might help for that. > > I can look at adding a knob to force short/long preamble. It would go > into HEAD though and can't promise to backport to RELENG_7. > > Sam > > Sin wrote: >> Sam, >> >> Basically I have a dlink WBR-1310 thats in bridge mode connected to my >> current BSD router ( 6.3) I'm trying to replace this 1310 product with >> FreeBSD 7. The last problem i'm dealing with is poor preformance. >> When I use my current BSD 7 setup it works, but ping times from client to >> another or even to the access point are bad. 100 - 400ms round trip. >> I had this exact problem with the 1310. The fix was to change from long >> to short preable. Been fine ever since. >> >> I used three computers to prove this before emailing. Just swapping the >> 1310 for the 7-STABLE corrects this. The 1310 uses g only mode with >> short preamble getting less then 5ms ping times to each client and host >> and vice-versa >> >> I realize that hostapd.conf is just for the encryption. However ifconfig >> and ath man pages do not talk about this setting. >> >> >> ----- Original Message ----- From: "Sam Leffler" >> To: "Sin" >> Cc: >> Sent: Wednesday, September 02, 2009 11:16 AM >> Subject: Re: toggle short / long preamble with hostapd >> >> >>> Sin wrote: >>>> Hello, >>>> >>>> >>>> Does anyone know how to enable short preamble in 7-STABLE ? >>>> >>>> I'm using ath with hostapd in ap mode. It seems there was an option in >>>> hostapd.conf, but this is not in FreeBSD's >>>> /usr/share/examples/hostapd/hostapd.conf >>>> >>>> >>>> The missing hostapd.conf option was found in google: >>>> >>>> # Short Preamble >>>> # This parameter can be used to enable optional use of short preamble >>>> for >>>> # frames sent at 2 Mbps, 5.5 Mbps, and 11 Mbps to improve network >>>> performance. >>>> # This applies only to IEEE 802.11b-compatible networks and this should >>>> only be >>>> # enabled if the local hardware supports use of short preamble. If any >>>> of the >>>> # associated STAs do not support short preamble, use of short preamble >>>> will be >>>> # disabled (and enabled when such STAs disassociate) dynamically. >>>> # 0 = do not allow use of short preamble (default) >>>> # 1 = allow use of short preamble >>>> #preamble=1 >>>> >>>> >>>> my version of hostapd is " v0.5.10 " - I was not able to set this >>>> option >>> >>> On freebsd hostapd is _purely_ an authenticator; to configure 802.11 >>> parameters you use ifconfig. >>> >>>> >>>> >>>> hostapd.conf: >>>> >>>> interface=ath0 >>>> #preamble=1 >>>> debug=1 >>>> ctrl_interface=/var/run/hostapd >>>> ctrl_interface_group=wheel >>>> ssid=private >>>> wpa=1 >>>> wpa_passphrase=apassword >>>> wpa_key_mgmt=WPA-PSK >>>> wpa_pairwise=TKIP >>>> >>>> >>>> >>>> rc.conf: >>>> >>>> hostapd_enable="YES" >>>> ifconfig_ath0="mode 11g hidessid mediaopt hostap" >>>> >>>> >>>> >>>> ifconfig ath0: >>>> >>>> ath0: flags=8943 metric >>>> 0 mtu 1500 >>>> ether 00:17:9a:4c:e7:83 >>>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g >>>> >>>> status: associated >>>> ssid private channel 1 (2412 Mhz 11g) bssid 00:17:9a:4c:e7:83 >>>> authmode WPA privacy MIXED deftxkey 2 TKIP 2:128-bit TKIP >>>> 3:128-bit >>>> txpower 31.5 scanvalid 60 bgscan bgscanintvl 300 bgscanidle 250 >>>> roam:rssi11g 7 roam:rate11g 5 protmode CTS burst hidessid >>>> dtimperiod 1 >>> >>> In ap mode you should not manually configure preamble; it should be >>> selected according to the associated stations. What are you trying to >>> accomplish? >>> >>> Sam >>> >> >> > > From owner-freebsd-net@FreeBSD.ORG Thu Sep 3 19:10:08 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 82803106566B for ; Thu, 3 Sep 2009 19:10:08 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6FB5A8FC18 for ; Thu, 3 Sep 2009 19:10:08 +0000 (UTC) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.3/8.14.3) with ESMTP id n83JA85g018091 for ; Thu, 3 Sep 2009 19:10:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.3/8.14.3/Submit) id n83JA8QA018090; Thu, 3 Sep 2009 19:10:08 GMT (envelope-from gnats) Date: Thu, 3 Sep 2009 19:10:08 GMT Message-Id: <200909031910.n83JA8QA018090@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Burt Rosenberg Cc: Subject: Re: kern/130628: [nfs] NFS / rpc.lockd deadlock on 7.1-R X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Burt Rosenberg List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 19:10:08 -0000 The following reply was made to PR kern/130628; it has been noted by GNATS. From: Burt Rosenberg To: bug-followup@FreeBSD.org, Joe Marcus Clarke Cc: bvowk@math.ualberta.ca Subject: Re: kern/130628: [nfs] NFS / rpc.lockd deadlock on 7.1-R Date: Thu, 3 Sep 2009 14:40:24 -0400 --000e0cd518fc7a0bcd0472b0b7ce Content-Type: multipart/alternative; boundary=000e0cd518fc7a0bbf0472b0b7cc --000e0cd518fc7a0bbf0472b0b7cc Content-Type: text/plain; charset=ISO-8859-1 It seems that : http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/130628 appears in 7.2-R-p3; With this kernel, against Fedora 8 distros: Linux prism09.cs.miami.edu 2.6.26.8-57.fc8 #1 SMP Thu Dec 18 18:59:49 EST 2008 x86_64 x86_64 x86_64 GNU/Linux which are using NFS (tcp) to mount homedirs form the freebsd server to the fedora client, server will become unresponsive from the network during graphical login of a client. Applying the patch given in the article http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/130628 seems at present to fix the problem. Under a 7.2-R-p3, we can manifest the problem in a few minutes, and under said kernel with patches as described in the article, and as provided by diffs against the current source, we have not yet seen the problem. When the problem appears, the sever cannot be pinged, an other network connections are halted. On the server, for instance, top shows: Proc, state, pri -------------------- pc.lockd *tcpin -68 nfsd - 4 rpcbind select 44 ntpd select 44 nfsd select 44 ... etc... Also, ./lockd restart Stopping lockd. Waiting for PIDS: 1114, 1114, 1114, 1114,.... kill -9 1114 also ineffective. So it seems to be something spinning in lockd. I think this is a serious issue and would like to see it resolved. Our setup is available if you would like to send instrumented code. I attach diffs. --000e0cd518fc7a0bbf0472b0b7cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It seems that :
=A0
http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/1306= 28

appears in 7.2-R-p3; With this kernel, against Fedora 8 distr= os:

Linux prism0= 9.cs.miami.edu 2.6.26.8-57.fc8 #1 SMP Thu Dec 18 18:59:49 EST 2008 x86_= 64 x86_64 x86_64 GNU/Linux

which are using NFS (tcp) to mount homedi= rs form the freebsd server to the fedora client,
server will become unresponsive from the network during graphical login of = a client.

Applying the patch given in the article http://www.freebsd.org/c= gi/query-pr.cgi?pr=3Dkern/130628 seems at present to fix the problem. U= nder a 7.2-R-p3, we can manifest the problem in a few minutes, and under sa= id kernel with patches as described in the article, and as provided by diff= s against the current source, we have not yet seen the problem.

When the problem appears, the sever cannot be pinged, an other network = connections are halted.

On the server, for instance, top shows:
=
Proc, state, pri
--------------------
pc.lockd=A0=A0 *tcpin=A0=A0 -68
nfsd=A0=A0=A0=A0=A0=A0= =A0=A0=A0 -=A0=A0=A0=A0=A0=A0 4
rpcbind=A0= =A0=A0=A0 select=A0=A0 44
ntpd=A0=A0=A0=A0=A0=A0= =A0 select=A0=A0 44
nfsd=A0=A0=A0=A0=A0=A0= =A0 select=A0=A0 44
... etc...

Also,

./lo= ckd restart
Stopping lockd.
Waiting for PIDS: 1114,= 1114, 1114, 1114,....

kill -9 1114 also ineffective.

So it seems to be something s= pinning in lockd.

I think this is a serious issue and would like to see it resolved. Our = setup is available if you would like to send instrumented code. I attach di= ffs.



--000e0cd518fc7a0bbf0472b0b7cc-- --000e0cd518fc7a0bcd0472b0b7ce Content-Type: application/octet-stream; name="svc.c.diff" Content-Disposition: attachment; filename="svc.c.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fz5u5alz0 MTgxYzE4MQo8IHhwcnRfaW5hY3RpdmUoU1ZDWFBSVCAqeHBydCkKLS0tCj4geHBydF9pbmFjdGl2 ZV9sb2NrZWQoU1ZDWFBSVCAqeHBydCkKMTg1LDE4NmQxODQKPCAJbXR4X2xvY2soJnBvb2wtPnNw X2xvY2spOwo8IAoxOTFjMTg5CjwgCXdha2V1cCgmcG9vbC0+c3BfYWN0aXZlKTsKLS0tCj4gfQox OTJhMTkxLDE5Nwo+IHZvaWQKPiB4cHJ0X2luYWN0aXZlKFNWQ1hQUlQgKnhwcnQpCj4gewo+IAlT VkNQT09MICpwb29sID0geHBydC0+eHBfcG9vbDsKPiAKPiAJbXR4X2xvY2soJnBvb2wtPnNwX2xv Y2spOwo+IAl4cHJ0X2luYWN0aXZlX2xvY2tlZCh4cHJ0KTsK --000e0cd518fc7a0bcd0472b0b7ce Content-Type: application/octet-stream; name="svc.h.diff" Content-Disposition: attachment; filename="svc.h.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fz5u5am51 NDlhNTAKPiAjaW5jbHVkZSA8c3lzL19zeC5oPgoxMzFjMTMyCjwgCXN0cnVjdCBtdHgJeHBfbG9j azsKLS0tCj4gCXN0cnVjdCBzeCAgICAgICB4cF9sb2NrOwozMzRhMzM2Cj4gZXh0ZXJuIHZvaWQg ICAgIHhwcnRfaW5hY3RpdmVfbG9ja2VkKFNWQ1hQUlQgKik7Cg== --000e0cd518fc7a0bcd0472b0b7ce Content-Type: application/octet-stream; name="svc_dg.c.diff" Content-Disposition: attachment; filename="svc_dg.c.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fz5u5am92 NTVhNTYKPiAjaW5jbHVkZSA8c3lzL3N4Lmg+CjEyMWMxMjIKPCAJbXR4X2luaXQoJnhwcnQtPnhw X2xvY2ssICJ4cHJ0LT54cF9sb2NrIiwgTlVMTCwgTVRYX0RFRik7Ci0tLQo+IAlzeF9pbml0KCZ4 cHJ0LT54cF9sb2NrLCAieHBydC0+eHBfbG9jayIpOwoxNjNhMTY1LDE2Nwo+IAlpZiAoc29yZWFk YWJsZSh4cHJ0LT54cF9zb2NrZXQpKQo+IAkJZXR1cm4gKFhQUlRfTU9SRVJFUVMpOwo+IAoxNzRh MTc5LDE4Mwo+IAkvKiAKPiAJICogU2VyaWFsaXNlIGFjY2VzcyB0byB0aGUgc29ja2V0Lgo+IAkg Ki8KPiAJc3hfeGxvY2soJnhwcnQtPnhwX2xvY2spOwo+IAoxOTAsMTkxZDE5OAo8IAltdHhfbG9j aygmeHBydC0+eHBfbG9jayk7CjwgCjE5OSwyMDBjMjA2LDIxMAo8IAkJeHBydF9pbmFjdGl2ZSh4 cHJ0KTsKPCAJCW10eF91bmxvY2soJnhwcnQtPnhwX2xvY2spOwotLS0KPiAJCW10eF9sb2NrKCZ4 cHJ0LT54cF9wb29sLT5zcF9sb2NrKTsKPiAJCWlmICghc29yZWFkYWJsZSh4cHJ0LT54cF9zb2Nr ZXQpKQo+IAkJCXhwcnRfaW5hY3RpdmVfbG9ja2VkKHhwcnQpOwo+IAkJbXR4X3VubG9jaygmeHBy dC0+eHBfcG9vbC0+c3BfbG9jayk7Cj4gCQlzeF94dW5sb2NrKCZ4cHJ0LT54cF9sb2NrKTsKMjEx YzIyMQo8IAkJbXR4X3VubG9jaygmeHBydC0+eHBfbG9jayk7Ci0tLQo+IAkJc3hfeHVubG9jaygm eHBydC0+eHBfbG9jayk7CjIxNWMyMjUKPCAJbXR4X3VubG9jaygmeHBydC0+eHBfbG9jayk7Ci0t LQo+IAlzeF94dW5sb2NrKCZ4cHJ0LT54cF9sb2NrKTsKMzA0YzMxNAo8IAltdHhfZGVzdHJveSgm eHBydC0+eHBfbG9jayk7Ci0tLQo+IAlzeF9kZXN0cm95KCZ4cHJ0LT54cF9sb2NrKTsKMzMxZDM0 MAo8IAltdHhfbG9jaygmeHBydC0+eHBfbG9jayk7CjMzM2QzNDEKPCAJbXR4X3VubG9jaygmeHBy dC0+eHBfbG9jayk7Cg== --000e0cd518fc7a0bcd0472b0b7ce Content-Type: application/octet-stream; name="svc_vc.c.diff" Content-Disposition: attachment; filename="svc_vc.c.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_fz5u5amc3 NTZhNTcKPiAjaW5jbHVkZSA8c3lzL3N4Lmg+CjE0NWMxNDYKPCAJbXR4X2luaXQoJnhwcnQtPnhw X2xvY2ssICJ4cHJ0LT54cF9sb2NrIiwgTlVMTCwgTVRYX0RFRik7Ci0tLQo+IAlzeF9pbml0KCZ4 cHJ0LT54cF9sb2NrLCAieHBydC0+eHBfbG9jayIpOwoyMjJjMjIzLDIyNAo8IAltdHhfaW5pdCgm eHBydC0+eHBfbG9jaywgInhwcnQtPnhwX2xvY2siLCBOVUxMLCBNVFhfREVGKTsKLS0tCj4gCXN4 X2luaXQoJnhwcnQtPnhwX2xvY2ssICJ4cHJ0LT54cF9sb2NrIik7Cj4gCjI1OGMyNjAKPCAJbXR4 X2xvY2soJnhwcnQtPnhwX2xvY2spOwotLS0KPiAJc3hfeGxvY2soJnhwcnQtPnhwX2xvY2spOwoy NjBjMjYyLDI2Mwo8IAltdHhfdW5sb2NrKCZ4cHJ0LT54cF9sb2NrKTsKLS0tCj4gCXN4X3h1bmxv Y2soJnhwcnQtPnhwX2xvY2spOwo+IAozNTljMzYyCjwgCW10eF9sb2NrKCZ4cHJ0LT54cF9sb2Nr KTsKLS0tCj4gCXN4X3hsb2NrKCZ4cHJ0LT54cF9sb2NrKTsKMzY0LDM2NWMzNjcsMzczCjwgCQl4 cHJ0X2luYWN0aXZlKHhwcnQpOwo8IAkJbXR4X3VubG9jaygmeHBydC0+eHBfbG9jayk7Ci0tLQo+ IAkJQUNDRVBUX0xPQ0soKTsKPiAJCW10eF9sb2NrKCZ4cHJ0LT54cF9wb29sLT5zcF9sb2NrKTsK PiAJCWlmIChUQUlMUV9FTVBUWSgmeHBydC0+eHBfc29ja2V0LT5zb19jb21wKSkKPiAJCQl4cHJ0 X2luYWN0aXZlX2xvY2tlZCh4cHJ0KTsKPiAJCW10eF91bmxvY2soJnhwcnQtPnhwX3Bvb2wtPnNw X2xvY2spOwo+IAkJQUNDRVBUX1VOTE9DSygpOwo+IAkJc3hfeHVubG9jaygmeHBydC0+eHBfbG9j ayk7CjM3NmMzODQKPCAJCW10eF91bmxvY2soJnhwcnQtPnhwX2xvY2spOwotLS0KPiAJCXN4X3h1 bmxvY2soJnhwcnQtPnhwX2xvY2spOwozODBjMzg4CjwgCW10eF91bmxvY2soJnhwcnQtPnhwX2xv Y2spOwotLS0KPiAJc3hfeHVubG9jaygmeHBydC0+eHBfbG9jayk7CjQyNWM0MzMKPCAJbXR4X2Rl c3Ryb3koJnhwcnQtPnhwX2xvY2spOwotLS0KPiAJc3hfZGVzdHJveSgmeHBydC0+eHBfbG9jayk7 CjQ5MWE1MDAKPiAJCXN4X3hsb2NrKCZ4cHJ0LT54cF9sb2NrKTsKNDk2YTUwNgo+IAkJc3hfeHVu bG9jaygmeHBydC0+eHBfbG9jayk7CjUwMGE1MTEsNTEzCj4gCWlmIChzb3JlYWRhYmxlKHhwcnQt PnhwX3NvY2tldCkpCj4gCQlyZXR1cm4gKFhQUlRfTU9SRVJFUVMpOwo+IAo1MTFhNTI1LDUyNgo+ IAlzeF94bG9jaygmeHBydC0+eHBfbG9jayk7Cj4gCjU4NmE2MDIKPiAJCQkJc3hfeHVubG9jaygm eHBydC0+eHBfbG9jayk7CjYxNGQ2MjkKPCAJCW10eF9sb2NrKCZ4cHJ0LT54cF9sb2NrKTsKNjI0 LDYyNWM2MzksNjQzCjwgCQkJeHBydF9pbmFjdGl2ZSh4cHJ0KTsKPCAJCQltdHhfdW5sb2NrKCZ4 cHJ0LT54cF9sb2NrKTsKLS0tCj4gCQkJbXR4X2xvY2soJnhwcnQtPnhwX3Bvb2wtPnNwX2xvY2sp Owo+IAkJCWlmICghc29yZWFkYWJsZSh4cHJ0LT54cF9zb2NrZXQpKQo+IAkJCQl4cHJ0X2luYWN0 aXZlX2xvY2tlZCh4cHJ0KTsKPiAJCQltdHhfdW5sb2NrKCZ4cHJ0LT54cF9wb29sLT5zcF9sb2Nr KTsKPiAJCQlzeF94dW5sb2NrKCZ4cHJ0LT54cF9sb2NrKTsKNjM3YzY1NQo8IAkJCW10eF91bmxv Y2soJnhwcnQtPnhwX2xvY2spOwotLS0KPiAJCQlzeF94dW5sb2NrKCZ4cHJ0LT54cF9sb2NrKTsK NjQ0YTY2Mwo+IAkJCXhwcnRfaW5hY3RpdmUoeHBydCk7CjY0NmM2NjUKPCAJCQltdHhfdW5sb2Nr KCZ4cHJ0LT54cF9sb2NrKTsKLS0tCj4gCQkJc3hfeHVubG9jaygmeHBydC0+eHBfbG9jayk7CjY1 NCw2NTVkNjcyCjwgCjwgCQltdHhfdW5sb2NrKCZ4cHJ0LT54cF9sb2NrKTsKNzQyZDc1OAo8IAlt dHhfbG9jaygmeHBydC0+eHBfbG9jayk7Cjc0NGQ3NTkKPCAJbXR4X3VubG9jaygmeHBydC0+eHBf bG9jayk7Cg== --000e0cd518fc7a0bcd0472b0b7ce-- From owner-freebsd-net@FreeBSD.ORG Thu Sep 3 21:51:46 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 3FE051065672 for ; Thu, 3 Sep 2009 21:51:46 +0000 (UTC) (envelope-from spawk@acm.poly.edu) Received: from acm.poly.edu (acm.poly.edu [128.238.9.200]) by mx1.freebsd.org (Postfix) with ESMTP id D3D938FC16 for ; Thu, 3 Sep 2009 21:51:45 +0000 (UTC) Received: (qmail 97995 invoked from network); 3 Sep 2009 21:51:44 -0000 Received: from unknown (HELO ?192.168.0.146?) (spawk@66.206.120.2) by acm.poly.edu with AES256-SHA encrypted SMTP; 3 Sep 2009 21:51:44 -0000 Message-ID: <4AA03A41.1080200@acm.poly.edu> Date: Thu, 03 Sep 2009 17:50:57 -0400 From: Boris Kochergin User-Agent: Thunderbird 2.0.0.19 (X11/20090108) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4A8C3557.20002@acm.poly.edu> In-Reply-To: <4A8C3557.20002@acm.poly.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: kmem_map too small panics with Soekris/Atheros access point 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, 03 Sep 2009 21:51:46 -0000 Boris Kochergin wrote: > Ahoy. I've got two Soekris Net5501s with Atheros 5212 cards in them, > acting as access points. They are both running 7.2-RELEASE and at > times each one has up to 30 machines associated with it. Relevant > information about them can be found at > "http://acm.poly.edu/~spawk/ap/". After a few days, they panic with: > > panic: kmem_malloc(32768): kmem_map too small: 86142976 total allocated > > Indeed, vm.kmem_size on each of them is 86228992. I had nowhere to > write a core dump to, but the root issue seems to be that all kernel > memory was exhausted, which sounds like a memory leak somewhere. Is > that a known problem with that release and hardware configuration? > > -Boris > _______________________________________________ > 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" More information: I upgraded it to a 7.2-STABLE with August 20th sources and increased kern.ipc.nmbclusters to 65536 in hopes of getting the panic less often. I managed to catch it in a state where there were a bunch of "ath0: ath_rx_proc: no mbuf!" messages in the kernel buffer. One line of "vmstat -m" stood out as the leak: 80211node 12677 101401K - 120901 16,512 "ifconfig ath0 down" freed the memory. Is there any other useful information I can provide if I catch it again? Someone suggested the output of "vmstat -z" off list, and I will have that next time. -Boris From owner-freebsd-net@FreeBSD.ORG Fri Sep 4 09:57: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 67FC31065790; Fri, 4 Sep 2009 09:57:16 +0000 (UTC) (envelope-from root@mailhub.rachie.is-a-geek.net) Received: from mailhub.rachie.is-a-geek.net (rachie.is-a-geek.net [66.230.99.27]) by mx1.freebsd.org (Postfix) with ESMTP id 0DBEB8FC19; Fri, 4 Sep 2009 09:57:15 +0000 (UTC) Received: by mailhub.rachie.is-a-geek.net (Postfix, from userid 0) id B61227E854; Fri, 4 Sep 2009 01:39:07 -0800 (AKDT) To: FreeBSD-gnats-submit@freebsd.org From: Mel Flynn X-send-pr-version: 3.113 X-GNATS-Notify: Message-Id: <20090904093907.B61227E854@mailhub.rachie.is-a-geek.net> Date: Fri, 4 Sep 2009 01:39:07 -0800 (AKDT) Cc: freebsd-net@FreeBSD.org Subject: [panic] Kernel corruption of pppoe lists 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, 04 Sep 2009 09:57:16 -0000 >Submitter-Id: current-users >Originator: Mel Flynn >Confidential: no >Synopsis: [panic] Kernel corruption of pppoe lists >Severity: critical >Priority: low >Category: kern >Class: sw-bug >Release: FreeBSD 7.2-STABLE i386 >Environment: System: FreeBSD gate.rachie.is-a-geek.net 7.2-STABLE FreeBSD 7.2-STABLE #0: Sun Jun 28 00:01:59 AKDT 2009 mdev@squish.rachie.is-a-geek.net:/data/obj/data/RELENG_7/src/sys/GATE i386 >Description: I realize the kernel is a bit old, but it also very hard to reproduce. Kernel was up 56 days and this crash happened shortly after a very long connect time, hangup by ISP and some renegotiation issues. I can provide the ppp.log of the incident if needed. What bothers me is the contents of the session list element, preceding the element cannot be accessed. Clearly, there is random kernel memory present there, judging from ether_dhost and ether_shost. # kgdb /boot/kernel/kernel /var/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x2d465459 fault code = supervisor read, page not present instruction pointer = 0x20:0xc06cd0a0 stack pointer = 0x28:0xc3b86a98 frame pointer = 0x28:0xc3b86ac0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 35 (irq22: xl0) trap number = 12 panic: page fault Uptime: 56d6h29m38s Physical memory: 1007 MB Dumping 174 MB: 159 143 127 111 95 79 63 47 31 15 Reading symbols from /boot/kernel/geom_journal.ko...Reading symbols from /boot/kernel/geom_journal.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_journal.ko Reading symbols from /boot/kernel/wlan_xauth.ko...Reading symbols from /boot/kernel/wlan_xauth.ko.symbols...done. done. Loaded symbols for /boot/kernel/wlan_xauth.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/if_bridge.ko...Reading symbols from /boot/kernel/if_bridge.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_bridge.ko Reading symbols from /boot/kernel/bridgestp.ko...Reading symbols from /boot/kernel/bridgestp.ko.symbols...done. done. Loaded symbols for /boot/kernel/bridgestp.ko Reading symbols from /boot/kernel/ng_ether.ko...Reading symbols from /boot/kernel/ng_ether.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_ether.ko Reading symbols from /boot/kernel/ng_socket.ko...Reading symbols from /boot/kernel/ng_socket.ko.symbols...done. done. Loaded symbols for /boot/kernel/ng_socket.ko Reading symbols from /boot/kernel/daemon_saver.ko...Reading symbols from /boot/kernel/daemon_saver.ko.symbols...done. done. Loaded symbols for /boot/kernel/daemon_saver.ko #0 doadump () at pcpu.h:196 196 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:196 #1 0xc05ef5d3 in boot (howto=260) at /data/RELENG_7/src/sys/kern/kern_shutdown.c:418 #2 0xc05ef7de in panic (fmt=Variable "fmt" is not available. ) at /data/RELENG_7/src/sys/kern/kern_shutdown.c:574 #3 0xc085c72c in trap_fatal (frame=0xc3b86a58, eva=759583833) at /data/RELENG_7/src/sys/i386/i386/trap.c:938 #4 0xc085c9b0 in trap_pfault (frame=0xc3b86a58, usermode=0, eva=759583833) at /data/RELENG_7/src/sys/i386/i386/trap.c:851 #5 0xc085d339 in trap (frame=0xc3b86a58) at /data/RELENG_7/src/sys/i386/i386/trap.c:529 #6 0xc0844a4b in calltrap () at /data/RELENG_7/src/sys/i386/i386/exception.s:166 #7 0xc06cd0a0 in pppoe_findsession (privp=0xc4258000, wh=Variable "wh" is not available. ) at /data/RELENG_7/src/sys/netgraph/ng_pppoe.c:567 #8 0xc06ce1a0 in ng_pppoe_rcvdata_ether (hook=0xc41b6380, item=0xc4256120) at /data/RELENG_7/src/sys/netgraph/ng_pppoe.c:1612 #9 0xc06c566f in ng_apply_item (node=0xc4111e80, item=0xc4256120, rw=0) at /data/RELENG_7/src/sys/netgraph/ng_base.c:2336 #10 0xc06c47e0 in ng_snd_item (item=0xc4256120, flags=Variable "flags" is not available. ) at /data/RELENG_7/src/sys/netgraph/ng_base.c:2254 #11 0xc068de5f in ether_demux (ifp=0xc3dbb400, m=0xc8024d00) at /data/RELENG_7/src/sys/net/if_ethersubr.c:851 #12 0xc068e1b3 in ether_input (ifp=0xc3dbb400, m=0xc8024d00) at /data/RELENG_7/src/sys/net/if_ethersubr.c:692 #13 0xc07b5348 in xl_rxeof (sc=0xc3dbc000) at /data/RELENG_7/src/sys/pci/if_xl.c:2022 #14 0xc07b7834 in xl_intr (arg=0xc3dbc000) at /data/RELENG_7/src/sys/pci/if_xl.c:2257 #15 0xc05cd10b in ithread_loop (arg=0xc3dc10c0) at /data/RELENG_7/src/sys/kern/kern_intr.c:1127 #16 0xc05c9ae6 in fork_exit (callout=0xc05ccf60 , arg=0xc3dc10c0, frame=0xc3b86d38) at /data/RELENG_7/src/sys/kern/kern_fork.c:811 #17 0xc0844ac0 in fork_trampoline () at /data/RELENG_7/src/sys/i386/i386/exception.s:271 (kgdb) frame 7 #7 0xc06cd0a0 in pppoe_findsession (privp=0xc4258000, wh=Variable "wh" is not available. ) at /data/RELENG_7/src/sys/netgraph/ng_pppoe.c:567 567 if (sp->Session_ID == session && (kgdb) print sp $1 = 0x2d465455 (kgdb) print *sp Cannot access memory at address 0x2d465455 (kgdb) print *privp $2 = {node = 0xc4111e80, ethernet_hook = 0xc41b6380, debug_hook = 0x0, packets_in = 126728356, packets_out = 69301432, flags = 0, eh = {ether_dhost = "ÿÿÿÿÿÿ", ether_shost = "\000\001\002Çù6", ether_type = 25480}, listeners = {lh_first = 0x0}, sesshash = {{mtx = {lock_object = {lo_name = 0xc08b8dc2 "PPPoE hash mutex", lo_type = 0xc08b8dc2 "PPPoE hash mutex", lo_flags = 16973824, lo_witness_data = { lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 3285460096, mtx_recurse = 0}, head = {lh_first = 0xc5093780}}, {mtx = {lock_object = { lo_name = 0xc08b8dc2 "PPPoE hash mutex", lo_type = 0xc08b8dc2 "PPPoE hash mutex", lo_flags = 16973824, lo_witness_data = { lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, head = {lh_first = 0x0}} , {mtx = { lock_object = {lo_name = 0xc08b8dc2 "PPPoE hash mutex", lo_type = 0xc08b8dc2 "PPPoE hash mutex", lo_flags = 16973824, lo_witness_data = { lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, head = {lh_first = 0xc4dc5bc0}}, {mtx = {lock_object = { lo_name = 0xc08b8dc2 "PPPoE hash mutex", lo_type = 0xc08b8dc2 "PPPoE hash mutex", lo_flags = 16973824, lo_witness_data = { lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4, mtx_recurse = 0}, head = {lh_first = 0x0}} }} (kgdb) print *privp->sesshash.head.lh_first->sessions.le_next->sessions.le_next $4 = {hook = 0x1, Session_ID = 52, state = 1920169263, creator = 1852400175, pkt_hdr = { eh = {ether_dhost = "/zcat", ether_shost = "/usr/s", ether_type = 24936}, ph = { ver = 2 '\002', type = 7 '\a', code = 101 'e', sid = 27951, length = 28257, tag = 0xc4e68524}}, neg = 0x2e6e652f, sessions = {le_next = 0x2d465455, le_prev = 0x61632f38}} >How-To-Repeat: Unknown at this time. >Fix: I don't expect this to be fixed, without a reproduction scenario, so I'm mainly reporting this to see if others have experienced a similar crash. From owner-freebsd-net@FreeBSD.ORG Fri Sep 4 13:01: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 556B2106566B for ; Fri, 4 Sep 2009 13:01:12 +0000 (UTC) (envelope-from artis.caune@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id D39368FC12 for ; Fri, 4 Sep 2009 13:01:11 +0000 (UTC) Received: by fxm6 with SMTP id 6so639338fxm.43 for ; Fri, 04 Sep 2009 06:01:10 -0700 (PDT) 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=7BJ1B4G4JyBnODP3zx6zG+BrAQ37wQX/DQlS4QPIpI8=; b=j5KWY3JClUoDe/CEjNFQakrX70N6X20CFnt8g+WM8fwfJhGyG33h9uvRqBOlgcKB8z ND4V/3U1IKTa60dPYycMfXR4YfkhNLicoMG9N/D39GaSLm7GVud7/VS7yGqbPP462y04 WLxdeNR3MOD7nJilVSHNltyTze85qcRLKaTPA= 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=KDS/6rABgCd8KSLbwHJRpMRnUfDCFCeqDhj8lS/SL3u8liPeOoVhzOc2Lr7xc/wa+7 pThAvuu9931hygqFU3Ok6YgvGYE0RcGr5TKP4jmhfl77uoD/70oJAihOiCKdldODzmgi 1JH81AxjkFNtzfHwkhmmr/uawR20jf9iHweMs= MIME-Version: 1.0 Received: by 10.103.67.32 with SMTP id u32mr4748891muk.133.1252069270728; Fri, 04 Sep 2009 06:01:10 -0700 (PDT) In-Reply-To: <11420.28890.qm@web56404.mail.re3.yahoo.com> References: <11420.28890.qm@web56404.mail.re3.yahoo.com> Date: Fri, 4 Sep 2009 16:01:10 +0300 Message-ID: <9e20d71e0909040601s100688c2m7d7f73eb187f4809@mail.gmail.com> From: Artis Caune To: alexpalias-bsdnet@yahoo.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: em driver input errors 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, 04 Sep 2009 13:01:12 -0000 2009/8/1 : > Good day > > I'm running a FreeBSD 7.2 router and I am seeing a lot of input errors on= one of the em interfaces (em0), coupled with (at approximately the same ti= mes) much fewer errors on em1 and em2.=C2=A0 Monitoring is done with SNMP f= rom another machine, and the CPU load as reported via SNMP is mostly below = 30%, with a couple of spikes up to 35%. > > Software description: > > - FreeBSD 7.2-RELEASE-p2, amd64 > - bsnmpd with modules: hostres and (from ports) snmp_ucd > - quagga 0.99.12 (running only zebra and bgpd) > - netgraph (ng_ether and ng_netflow) > > Hardware description: > > - Dell machine, dual Xeon 3.20 GHz, 4 GB RAM > - 2 x built-in gigabit interfaces (em0, em1) > - 1 x dual-port gigabit interface, PCI-X (em2, em3) [see pciconf near the= end] > > > The machine receives the global routing table ("netstat -nr | wc -l" give= s 289115 currently). > > All of the em interfaces are just configured "up", with various vlan inte= rfaces on them.=C2=A0 Note that I use "kpps" to mean "thousands of packets = per second", sorry if that's the wrong shorthand. > > - em0 sees a traffic of 10...22 kpps in, and 15...35 kpps out.=C2=A0 In b= its, it's 30...120Mbits/s in, and 100...210Mbits/s out.=C2=A0 Vlans configu= red are vlan100 and vlan200, and most of the traffic is on vlan100 (vlan200= sees 4kpps in / 0.5kpps out maximum, with the average at about one third o= f this).=C2=A0 em0 is the external interface, and its traffic corresponds t= o the sum of traffic through em1 and em2 > > - em1 has 5 vlans, and sees about 22kpps in / 11kpps out (maximum) > > - em2 has a single VLAN, and sees about 4...13kpps both in and out (almos= t equal in/out during most of the day) > > - em3 is a backup interface, with 2 VLANS, and is the only one which has = seen no errors. > > Only the vlans on em0 are analyzed by ng_netflow, and the errors I'm seei= ng have started appearing days before netgraph was even loaded in the kerne= l. > > Tuning done: > > /boot/loader.conf: > hw.em.rxd=3D4096 > hw.em.txd=3D4096 > > Witout the above we were seeing way more errors, now they are reduced, bu= t still come in bursts of over 1000 errors on em0. > > /etc/sysctl.conf: > net.inet.ip.fastforwarding=3D1 > dev.em.0.rx_processing_limit=3D300 > dev.em.1.rx_processing_limit=3D300 > dev.em.2.rx_processing_limit=3D300 > dev.em.3.rx_processing_limit=3D300 > > Still seeing errros, after some searching the mailing lists we also added= : > > # the four lines below are repeated for em1, em2, em3 > dev.em.0.rx_int_delay=3D0 > dev.em.0.rx_abs_int_delay=3D0 > dev.em.0.tx_int_delay=3D0 > dev.em.0.tx_abs_int_delay=3D0 > > Still getting errors, so I also added: > > net.inet.ip.intr_queue_maxlen=3D4096 > net.route.netisr_maxqlen=3D1024 > > and > > kern.ipc.nmbclusters=3D655360 > > > Also tried with rx_processing_limit set to -1 on all em interfaces, still= getting errors. > > Looking at the shape of the error and packet graphs, there seems to be a = correlation between the number of packets per second on em0 and the height = of the error "spikes" on the error graph.=C2=A0 These spikes are spread thr= oughout the day, with spaces (zones with no errors) of various lengths (10 = minutes ... 2 hours spaces within the last 24 hours), but sometimes there a= re errors even in the lowest kpps times of the day. > > em0 and em1 error times are correlated, with all errors on the graph for = em0 having a smaller corresponding error spike on em1 at the same time, and= sometimes an error spike on em2. > > The old router was seeing about the same traffic, and had em0, em1, re0 a= nd re1 network cards, and was only seeing errors on the em cards.=C2=A0 It = was running 7.2-PRERELEASE/i386 > > > Any suggestions would be greatly appreciated.=C2=A0 Please note that this= is a live router, and I can't reboot it (unless absolutely necessary).=C2= =A0 Tuning that can be applied without rebooting will be tried first. Is it still actual? You didn't mention if you are using pf or other firewall. I have similar problem with two boxes replicating zfs pools, when I noticed input errors. After some investigation turns out it was pf overhead, even though I was skipping on interfaces where zfs sedn/recv. With pf enables (and skip) I can copy 50-80MB/s with 50-80Kpps and 0-100+ input drops per second. With pf disabled I can copy constantly with 102 or 93 MB/s and 110-131Kpps, few drops (because 1 CPU almost eaten). --=20 Artis Caune Everything should be made as simple as possible, but not simpler. From owner-freebsd-net@FreeBSD.ORG Fri Sep 4 14:11: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 5781D106568B for ; Fri, 4 Sep 2009 14:11:24 +0000 (UTC) (envelope-from ady@ady.ro) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by mx1.freebsd.org (Postfix) with ESMTP id EE5098FC12 for ; Fri, 4 Sep 2009 14:11:23 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id 4so809933eyf.9 for ; Fri, 04 Sep 2009 07:11:22 -0700 (PDT) MIME-Version: 1.0 Sender: ady@ady.ro Received: by 10.211.154.7 with SMTP id g7mr12476306ebo.10.1252073482078; Fri, 04 Sep 2009 07:11:22 -0700 (PDT) In-Reply-To: <11420.28890.qm@web56404.mail.re3.yahoo.com> References: <11420.28890.qm@web56404.mail.re3.yahoo.com> From: Adrian Penisoara Date: Fri, 4 Sep 2009 16:11:00 +0200 X-Google-Sender-Auth: 26e788b019a5e1a0 Message-ID: <78cb3d3f0909040711i5702c4c7l4dbb89bb1fef259a@mail.gmail.com> To: alexpalias-bsdnet@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: em driver input errors 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, 04 Sep 2009 14:11:24 -0000 Hi, On Sat, Aug 1, 2009 at 3:05 PM, wrote: > Good day > > I'm running a FreeBSD 7.2 router and I am seeing a lot of input errors on= one of the em interfaces (em0), coupled with (at approximately the same ti= mes) much fewer errors on em1 and em2.=A0 Monitoring is done with SNMP from= another machine, and the CPU load as reported via SNMP is mostly below 30%= , with a couple of spikes up to 35%. First question that comes to mind is: have you tried device polling ? Looking up the thorough decscription you made it appears not to. Please check the polling(4) manual page and Luigi's page [1] for detailed information. Basically it switches the device driver from interrupt mode to polling mode, allowing to specify the user/system CPU usage fraction. [1] http://info.iet.unipi.it/~luigi/polling/ Regards, Adrian Penisoara EnterpriseBSD From owner-freebsd-net@FreeBSD.ORG Fri Sep 4 15:59: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 C791F106568D for ; Fri, 4 Sep 2009 15:59:24 +0000 (UTC) (envelope-from gigabyte.tmn@gmail.com) Received: from mail-fx0-f210.google.com (mail-fx0-f210.google.com [209.85.220.210]) by mx1.freebsd.org (Postfix) with ESMTP id 509A58FC18 for ; Fri, 4 Sep 2009 15:59:24 +0000 (UTC) Received: by fxm6 with SMTP id 6so758958fxm.43 for ; Fri, 04 Sep 2009 08:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:reply-to:from:to :cc:references:subject:date:organization:mime-version:content-type :content-transfer-encoding:x-priority:x-msmail-priority:x-mailer :x-mimeole; bh=Y9U7pGTikjT4RX9yO+VV/cmKe8RmseOUwhFJGNDA2+8=; b=Klf8+Oct/5aQswjpq5oQLYueFzH7lKjfVPwLqPGn3tEr5hpjdpzKPgaxnr/6q99M4j LnCxqTZ9AAxm1cb99fQhgHKNSMnbG+o0jgprThrgX/48M5Fc0zNtDe5y4iAhns7+AIbh bI6gLVpfoIbiyU+s4cJ43T8MkIpT3921hXeK0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:reply-to:from:to:cc:references:subject:date:organization :mime-version:content-type:content-transfer-encoding:x-priority :x-msmail-priority:x-mailer:x-mimeole; b=mIK8XwjBfttQBqflq2T4MO0STzjWLjHoQMQjO2ogNvyqd7WwPDr68dTNRSbrhNrgWx P6GPplZVGK7tNpXLU0gFNkUUzOvQ/h5YXCipPWmh56lsgLNT/c34L8WO7MVoiYHJSrCG b65zC01kzkkzCoewEl6UiWdHHgBM1oWr50AEo= Received: by 10.204.154.131 with SMTP id o3mr9251690bkw.66.1252079962977; Fri, 04 Sep 2009 08:59:22 -0700 (PDT) Received: from dm (51.dynamic-n193.r72.info [91.211.193.51]) by mx.google.com with ESMTPS id 1sm1968109fks.6.2009.09.04.08.59.21 (version=SSLv3 cipher=RC4-MD5); Fri, 04 Sep 2009 08:59:21 -0700 (PDT) Message-ID: <001601ca2d78$aecc4af0$1e010a0a@in72.ru> From: "Dmitriy Zamuraev" To: "Mel Flynn" References: <20090904093907.B61227E854@mailhub.rachie.is-a-geek.net> Date: Fri, 4 Sep 2009 21:59:25 +0600 Organization: Netline NSP MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Cc: freebsd-net@freebsd.org Subject: Re: [panic] Kernel corruption of pppoe lists X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dmitriy Zamuraev List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 15:59:24 -0000 I have same problem, and we are not alone. See http://www.freebsd.org/cgi/query-pr.cgi?pr=137881 (PR: kern/137881) You may append to this PR. ----- Original Message ----- From: "Mel Flynn" To: Cc: Sent: Friday, September 04, 2009 3:39 PM Subject: [panic] Kernel corruption of pppoe lists >>Description: > I realize the kernel is a bit old, but it also very hard to reproduce. > Kernel > was up 56 days and this crash happened shortly after a very long connect > time, > hangup by ISP and some renegotiation issues. I can provide the ppp.log of > the > incident if needed. > > What bothers me is the contents of the session list element, preceding the > element > cannot be accessed. Clearly, there is random kernel memory present there, > judging > from ether_dhost and ether_shost. > > #7 0xc06cd0a0 in pppoe_findsession (privp=0xc4258000, wh=Variable "wh" is > not available. > ) > at /data/RELENG_7/src/sys/netgraph/ng_pppoe.c:567 > #8 0xc06ce1a0 in ng_pppoe_rcvdata_ether (hook=0xc41b6380, > item=0xc4256120) > at /data/RELENG_7/src/sys/netgraph/ng_pppoe.c:1612 From owner-freebsd-net@FreeBSD.ORG Fri Sep 4 16:28:13 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 125071065679 for ; Fri, 4 Sep 2009 16:28:13 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (unknown [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id A3EB18FC1C for ; Fri, 4 Sep 2009 16:28:12 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id E95AE153436 for ; Fri, 4 Sep 2009 18:28:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rygiwvgcPbPk; Fri, 4 Sep 2009 18:28:09 +0200 (CEST) Received: from [212.61.27.67] (opteron [212.61.27.67]) by mail.digiware.nl (Postfix) with ESMTP id 15474153435 for ; Fri, 4 Sep 2009 18:28:09 +0200 (CEST) Message-ID: <4AA14018.3010102@digiware.nl> Date: Fri, 04 Sep 2009 18:28:08 +0200 From: Willem Jan Withagen Organization: Digiware User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: UDP output performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 16:28:13 -0000 First of: I've been googleing for about a day, but I'll take any suggestions for more info. What I'm trying to do is get as much 1440 byte UDP packets out of an em device. And when tat works, get as much out of the 7 em devices that this board has. :) Currently I run into trouble at 250*174 = 43500 packets/sec. How is the setup: em0 gets 1 stream of 174 p/s which is ~ 2Mbit this gets repeated to 250 streams currently to 2 other servers, 125 streams each. each on their own 1 Gbit port This works uptil 123 streams each, going high gives packet loss. So this is at about 500Mbit/sec on a 1Gbit port And why do I know that the packetloss is not in the network? Well there are no errors on the output interface the ports on the switch the input ports on the receivers the mib of the switch does not show any signs of dropped packets, or likes. Also I can change the order of the queing in my repeater, and then the packetloss moves to the host which is last the outputlist. I tried raising the socketbuffer " sysctl -w net.inet.udp.maxdgram=184320" in a few steps. But that did not bring anything. So my guess is that I'm dropping packets somewhere from the output socket to the wire. BTW al stats in systat -vm are close to 0%. What tunables are there to turn? And if not tuneable, what parts of the code would be target for closer inspection. Any help is more than welcome --WjW From owner-freebsd-net@FreeBSD.ORG Fri Sep 4 17:23:10 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 43D781065672 for ; Fri, 4 Sep 2009 17:23:10 +0000 (UTC) (envelope-from manishv@lineratesystems.com) Received: from mail-vw0-f189.google.com (mail-vw0-f189.google.com [209.85.212.189]) by mx1.freebsd.org (Postfix) with ESMTP id 095288FC26 for ; Fri, 4 Sep 2009 17:23:09 +0000 (UTC) Received: by vws27 with SMTP id 27so813082vws.3 for ; Fri, 04 Sep 2009 10:23:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.107.163 with SMTP id b35mr15406292vcp.74.1252083728744; Fri, 04 Sep 2009 10:02:08 -0700 (PDT) In-Reply-To: <4AA14018.3010102@digiware.nl> References: <4AA14018.3010102@digiware.nl> Date: Fri, 4 Sep 2009 11:02:08 -0600 Message-ID: <5bc218350909041002x670460c8nf202a714182d1bf6@mail.gmail.com> From: Manish Vachharajani To: Willem Jan Withagen Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: UDP output performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 17:23:10 -0000 Hmm, what version of FreeBSD are you using? I don't know the solution but I wonder if it is related to a similar problem we are having with TCP connection scaling, both under 7.2 and 8.0 over a 10 Gb link. We've been trying to track it down, and if you see it for UDP as well that may give some clues. If you do a netstat -idh what is the output? Does the recieving interface show any Ierrs or drops? If so, you should be able to do a sysctl dev.em..stats=3D1 and then see some output via dmesg. Does this show any missed packets? Oh, also, what kind of machine are you running on? Manish On Fri, Sep 4, 2009 at 10:28 AM, Willem Jan Withagen wrote= : > First of: I've been googleing for about a day, but I'll take any suggesti= ons > for more info. > > What I'm trying to do is get as much 1440 byte UDP packets out of an em > device. And when tat works, get as much out of the 7 em devices that this > board has. :) > > Currently I run into trouble at 250*174 =3D 43500 packets/sec. > > How is the setup: > =A0 =A0 =A0 =A0em0 gets 1 stream of 174 p/s which is ~ 2Mbit > this gets repeated to 250 streams > =A0 =A0 =A0 =A0currently to 2 other servers, 125 streams each. > =A0 =A0 =A0 =A0each on their own 1 Gbit port > > This works uptil 123 streams each, going high gives packet loss. > So this is at about 500Mbit/sec on a 1Gbit port > > And why do I know that the packetloss is not in the network? > Well there are no errors on > =A0 =A0 =A0 =A0the output interface > =A0 =A0 =A0 =A0the ports on the switch > =A0 =A0 =A0 =A0the input ports on the receivers > =A0 =A0 =A0 =A0the mib of the switch does not show any signs of dropped p= ackets, or > likes. > > Also I can change the order of the queing in my repeater, and then the > packetloss moves to the host which is last the outputlist. > I tried raising the socketbuffer " sysctl -w net.inet.udp.maxdgram=3D1843= 20" > in a few steps. But that did not bring anything. > > So my guess is that I'm dropping packets somewhere from the output socket= to > the wire. > > BTW al stats in systat -vm are close to 0%. > > What tunables are there to turn? > > And if not tuneable, what parts of the code would be target for closer > inspection. > > Any help is more than welcome > > --WjW > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Sep 4 17:28: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 4B69C106566B for ; Fri, 4 Sep 2009 17:28:43 +0000 (UTC) (envelope-from alexpalias-bsdnet@yahoo.com) Received: from n63.bullet.mail.sp1.yahoo.com (n63.bullet.mail.sp1.yahoo.com [98.136.44.33]) by mx1.freebsd.org (Postfix) with SMTP id 261FE8FC17 for ; Fri, 4 Sep 2009 17:28:43 +0000 (UTC) Received: from [69.147.84.144] by n63.bullet.mail.sp1.yahoo.com with NNFMP; 04 Sep 2009 17:14:51 -0000 Received: from [68.142.237.90] by t6.bullet.mail.sp1.yahoo.com with NNFMP; 04 Sep 2009 17:14:51 -0000 Received: from [66.196.97.135] by t6.bullet.re3.yahoo.com with NNFMP; 04 Sep 2009 17:14:51 -0000 Received: from [127.0.0.1] by omp108.mail.re3.yahoo.com with NNFMP; 04 Sep 2009 17:14:51 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 131625.17242.bm@omp108.mail.re3.yahoo.com Received: (qmail 71229 invoked by uid 60001); 4 Sep 2009 17:14:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252084491; bh=JUTQGrGSDCyuBVIq8xaFBgSrpLfJRoIfjRTR7qNaR6s=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=S8C8/YkIvmxKP1Vtlzz+4/iR0q4BA4BxWHjOz16dlWTVMYA71Tlpih35k96Xryt2Q8+pJKrXEuR7jHvyU0ckZr7vLbyePfsZOmhFfNjk//XYOCr9y31SLQSxMMQOvFNtOqLNhaje6vYVPsfgo3tA2ciTi/OOyoNz29aHCmSsNws= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=gdK1qiMfsj0e5sTCc9W7rnczokIGwLPeey0vND+v5lZOlu5nZsJZjy0XWRxYDN8p8dxuPo3chqhwwy0hYoKWmsdkWwgDD9LADesBQRGwfOLxMQjBHfEY/vVidNU7XujORZRQkEO4wyV6on2gHKOsRvnVVBT5h+zwQnN9jwqArHs=; Message-ID: <3413.68869.qm@web56406.mail.re3.yahoo.com> X-YMail-OSG: 2P4CyigVM1mQsxN6bqjnosbCPnDwnonCgECDoekQkYyod0FhpBYSG0zL_ASfNk0ZLUaobg0NO6zFOShN_f1HU4brIpv1bCFvYiiZnSG46h5kORxxjrLwzK51Pt4P_3xlB4VlyvadqljNUvNZcewoxS1E4vfr1GKMKURCqK8LwTo6O8o1yBQbPTy9DXAyUNZkOKbV2LIsv1WGM6JoxyAJCukxqstXT_UASqmr6BXKIl8ABgDa1H15y3eEw3XJfEdow2t44KJLviYveec7zZpQQTdAeXgZ9.ppy8XntvaJV8reL9EX_.O17hiufLUrzR6yEo0YIuyF6JV.C9CK.Wttt_WWE4E8svt_N.P08MsE3EnL9DfXunGt2XujM6nVmtFv9F1H Received: from [91.200.96.47] by web56406.mail.re3.yahoo.com via HTTP; Fri, 04 Sep 2009 10:14:50 PDT X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.347.2 Date: Fri, 4 Sep 2009 10:14:50 -0700 (PDT) From: alexpalias-bsdnet@yahoo.com To: Artis Caune In-Reply-To: <9e20d71e0909040601s100688c2m7d7f73eb187f4809@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org Subject: Re: em driver input errors X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alexpalias-bsdnet@yahoo.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 17:28:43 -0000 --- On Fri, 9/4/09, Artis Caune wrote: > Is it still actual? Hello. Yes, this is still actual. 1> netstat -nbhI em0 ; uptime Name Mtu Network Address Ipkts Ierrs Ibytes Opkts Oerrs Obytes Coll em0 1500 00:14:22:17:80:dc 31G 93M 18T 36G 0 27T 0 7:50PM up 23 days, 15:40, 1 user, load averages: 0.84, 1.05, 1.16 The huge number of input errors is due to a 80-100kpps flood we received via that interface, which got the errors/sec numbers up in the 50k/s range for a few minutes. > You didn't mention if you are using pf or other firewall. Sorry if I didn't mention it. I am using pf, but have tried "kldunload pf" and the errors didn't disappear. > I have similar problem with two boxes replicating zfs > pools, when I > noticed input errors. > After some investigation turns out it was pf overhead, even > though I > was skipping on interfaces where zfs sedn/recv. > > With pf enables (and skip) I can copy 50-80MB/s with > 50-80Kpps and > 0-100+ input drops per second. > With pf disabled I can copy constantly with 102 or 93 MB/s > and > 110-131Kpps, few drops (because 1 CPU almost eaten). This is the kind of traffic I am seeing: Errors/second (5 minute average) per interface: http://www.dataxnet.ro/alex/errors.png Packets/second (5 minute average) per interface: http://www.dataxnet.ro/alex/packets.png Those graphs were saved a few minutes ago, times are EEST (GMT+3) I'm sorry I don't have the Mbits/s graphs up, I haven't been collecting that data per interface recently (it's collected per vlan). Alex From owner-freebsd-net@FreeBSD.ORG Fri Sep 4 17:30:45 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 CC378106566B for ; Fri, 4 Sep 2009 17:30:45 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (unknown [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id 780FB8FC1B for ; Fri, 4 Sep 2009 17:30:45 +0000 (UTC) Received: from localhost (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 7F33B153434; Fri, 4 Sep 2009 19:30:44 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by localhost (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfKi-irX-Yh2; Fri, 4 Sep 2009 19:30:42 +0200 (CEST) Received: from [212.61.27.67] (opteron [212.61.27.67]) by mail.digiware.nl (Postfix) with ESMTP id 3C940153435; Fri, 4 Sep 2009 19:30:42 +0200 (CEST) Message-ID: <4AA14EC1.6010402@digiware.nl> Date: Fri, 04 Sep 2009 19:30:41 +0200 From: Willem Jan Withagen Organization: Digiware User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Manish Vachharajani References: <4AA14018.3010102@digiware.nl> <5bc218350909041002x670460c8nf202a714182d1bf6@mail.gmail.com> In-Reply-To: <5bc218350909041002x670460c8nf202a714182d1bf6@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: UDP output performance X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 17:30:46 -0000 Manish Vachharajani wrote: > Hmm, what version of FreeBSD are you using? I don't know the solution > but I wonder if it is related to a similar problem we are having with > TCP connection scaling, both under 7.2 and 8.0 over a 10 Gb link. > We've been trying to track it down, and if you see it for UDP as well > that may give some clues. Well, asfar as I remember the majority of the code path for UDP and TCP is rather diffent. And our caseis evenmore special, since we do not do controlflow and thus do not have packets coming back in over that same interface/ip-nr. There is almost no state at all. > If you do a netstat -idh what is the output? Does the recieving > interface show any Ierrs or drops? If so, you should be able to do a > sysctl dev.em..stats=1 and then see some output via > dmesg. Does this show any missed packets? No, errors at all. But I would also be very reluctant to add more logging since that IS going to impact throughput. > Oh, also, what kind of machine are you running on? FreeBSD 7.2-STABLE #0: Fri Sep 4 18:01:30 CEST 2009 CPU: Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz (2133.42-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6f2 Stepping = 2 real memory = 1072623616 (1022 MB) avail memory = 1040248832 (992 MB) 7 * em device over PCI-E em6@pci0:7:0:0: class=0x020000 card=0x00008086 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Intel PRO/1000 PL Network Adaptor' class = network subclass = ethernet And Yes the idea is to do something similar over a 10Gb interface. --WjW > Manish > > On Fri, Sep 4, 2009 at 10:28 AM, Willem Jan Withagen wrote: >> First of: I've been googleing for about a day, but I'll take any suggestions >> for more info. >> >> What I'm trying to do is get as much 1440 byte UDP packets out of an em >> device. And when tat works, get as much out of the 7 em devices that this >> board has. :) >> >> Currently I run into trouble at 250*174 = 43500 packets/sec. >> >> How is the setup: >> em0 gets 1 stream of 174 p/s which is ~ 2Mbit >> this gets repeated to 250 streams >> currently to 2 other servers, 125 streams each. >> each on their own 1 Gbit port >> >> This works uptil 123 streams each, going high gives packet loss. >> So this is at about 500Mbit/sec on a 1Gbit port >> >> And why do I know that the packetloss is not in the network? >> Well there are no errors on >> the output interface >> the ports on the switch >> the input ports on the receivers >> the mib of the switch does not show any signs of dropped packets, or >> likes. >> >> Also I can change the order of the queing in my repeater, and then the >> packetloss moves to the host which is last the outputlist. >> I tried raising the socketbuffer " sysctl -w net.inet.udp.maxdgram=184320" >> in a few steps. But that did not bring anything. >> >> So my guess is that I'm dropping packets somewhere from the output socket to >> the wire. >> >> BTW al stats in systat -vm are close to 0%. >> >> What tunables are there to turn? >> >> And if not tuneable, what parts of the code would be target for closer >> inspection. >> >> Any help is more than welcome >> >> --WjW >> >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > From owner-freebsd-net@FreeBSD.ORG Fri Sep 4 17:41:17 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 4AA69106568D for ; Fri, 4 Sep 2009 17:41:17 +0000 (UTC) (envelope-from manishv@lineratesystems.com) Received: from mail-vw0-f189.google.com (mail-vw0-f189.google.com [209.85.212.189]) by mx1.freebsd.org (Postfix) with ESMTP id DCEE28FC08 for ; Fri, 4 Sep 2009 17:41:16 +0000 (UTC) Received: by vws27 with SMTP id 27so823129vws.3 for ; Fri, 04 Sep 2009 10:41:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.89.2 with SMTP id c2mr15897591vcm.16.1252086075920; Fri, 04 Sep 2009 10:41:15 -0700 (PDT) In-Reply-To: <3413.68869.qm@web56406.mail.re3.yahoo.com> References: <9e20d71e0909040601s100688c2m7d7f73eb187f4809@mail.gmail.com> <3413.68869.qm@web56406.mail.re3.yahoo.com> Date: Fri, 4 Sep 2009 11:41:15 -0600 Message-ID: <5bc218350909041041x49ec9765k81346e90bbfe891a@mail.gmail.com> From: Manish Vachharajani To: alexpalias-bsdnet@yahoo.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Artis Caune Subject: Re: em driver input errors 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, 04 Sep 2009 17:41:17 -0000 Just decided to follow this thread as it seems to be related to some issues we are seeing as well. It appears that under heavy packet loads, the kernel cannot pull packets off the NIC fast enough and thus is slow to free up descriptors into which the NIC can DMA packets. This causes the NIC to drop the packet after it's internal queue fills up (and record the packet as missed) because the hardware does not have enough descriptors to write the packets into. We ahve this issue with the ixgbe 10 Gb/s card though the absolute packet rates at which we see a problem are higher than those reported here. In our test scenario the problem gets worse with many simultaneous TCP connections, but the issue is the same. Under high packet rates, the driver cannot keep up and the NIC reports missed packets. The issue is not related to data throughput though as turning on jumbo frames solves our issue for a fixed number of connections, and it seems here that reducing the packet rate makes the misses go away. More importantly, in our tests, only the receiver sees a problem, the transmitter is fine. There was also another thread about problems with UDP throughput that I suspect are caused by the same type of packet rate spikes. The question is, why is the kernel stack slow to handle these packet rates, doing some back of the envelope calculations, they don't seem too bad? Where is the time going? And, are our problem, the UDP issue, and this problem all caused by the same source of slowness or are they three unrelated issues. Manish On Fri, Sep 4, 2009 at 11:14 AM, wrote: > --- On Fri, 9/4/09, Artis Caune wrote: > >> Is it still actual? > > Hello. =A0Yes, this is still actual. > > 1> netstat -nbhI em0 ; uptime > Name =A0 =A0Mtu Network =A0 =A0 =A0 Address =A0 =A0 =A0 =A0 =A0 =A0 =A0Ip= kts Ierrs =A0 =A0 Ibytes =A0 =A0Opkts Oerrs =A0 =A0 Obytes =A0Coll > em0 =A0 =A01500 =A0 =A0 =A000:14:22:17:80:dc =A0 =A0 =A031G =A0 = 93M =A0 =A0 =A0 =A018T =A0 =A0 =A036G =A0 =A0 0 =A0 =A0 =A0 =A027T =A0 =A0 = 0 > =A07:50PM =A0up 23 days, 15:40, 1 user, load averages: 0.84, 1.05, 1.16 > > The huge number of input errors is due to a 80-100kpps flood we received = via that interface, which got the errors/sec numbers up in the 50k/s range = for a few minutes. > >> You didn't mention if you are using pf or other firewall. > > Sorry if I didn't mention it. =A0I am using pf, but have tried "kldunload= pf" and the errors didn't disappear. > >> I have similar problem with two boxes replicating zfs >> pools, when I >> noticed input errors. >> After some investigation turns out it was pf overhead, even >> though I >> was skipping on interfaces where zfs sedn/recv. >> >> With pf enables (and skip) I can copy 50-80MB/s with >> 50-80Kpps and >> 0-100+ input drops per second. >> With pf disabled I can copy constantly with 102 or 93 MB/s >> and >> 110-131Kpps, few drops (because 1 CPU almost eaten). > > This is the kind of traffic I am seeing: > > Errors/second (5 minute average) per interface: > http://www.dataxnet.ro/alex/errors.png > Packets/second (5 minute average) per interface: > http://www.dataxnet.ro/alex/packets.png > > Those graphs were saved a few minutes ago, times are EEST (GMT+3) > > I'm sorry I don't have the Mbits/s graphs up, I haven't been collecting t= hat data per interface recently (it's collected per vlan). > > Alex > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Fri Sep 4 17:43:34 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 697D21065676 for ; Fri, 4 Sep 2009 17:43:34 +0000 (UTC) (envelope-from alexpalias-bsdnet@yahoo.com) Received: from n2.bullet.mail.re3.yahoo.com (n2.bullet.mail.re3.yahoo.com [68.142.237.109]) by mx1.freebsd.org (Postfix) with SMTP id 1C0BD8FC14 for ; Fri, 4 Sep 2009 17:43:33 +0000 (UTC) Received: from [68.142.237.90] by n2.bullet.mail.re3.yahoo.com with NNFMP; 04 Sep 2009 17:29:57 -0000 Received: from [216.252.110.140] by t6.bullet.re3.yahoo.com with NNFMP; 04 Sep 2009 17:29:57 -0000 Received: from [127.0.0.1] by omp210.mail.re3.yahoo.com with NNFMP; 04 Sep 2009 17:29:57 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 634761.17967.bm@omp210.mail.re3.yahoo.com Received: (qmail 57427 invoked by uid 60001); 4 Sep 2009 17:29:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1252085397; bh=zBjioOcj8LztFqgmlLXNm4UALqVgdJu/q4WxskbxapA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=B4wd7WL3UYTrb/8jYmFGgh9JHwy/lmtpN+v+JSGQStC+bMIF2Lf7kKzrwDpimDpyCo0e8TVGtmwsSNGD8ya3wSJkLgG7we4XvH+Ga6BaSQLS4AmKnv2p8kcAvOnndMcnHUeYqmEypGjW3zYTrGTP06xB7B3TRAc/maZsbiD+COI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=SzTuEDW2llbdyyUuVGESUiNZCmKxF/M/WN4h5jQH5GaJ7NM+teOlx2AXTJR3FhSf7S9GD46J68g0oLTPSqF97m9jn35vNkfHGf2/KVCrjJYLY3gyRrKWmWbMGhtXTZZ6XgDAQEhhVP0l3XqmWKxboyckObHZrh1HnbR8NRoSICw=; Message-ID: <540877.57168.qm@web56401.mail.re3.yahoo.com> X-YMail-OSG: N9D7fQ8VM1m8cIn7uwJ0tQWHcRp6H08kl7dbJug_qDZQuzkMAExHQpLM6KrFiJQK30bxoRCeBpchDdcXIsOsNOj0TGJsg6RVjfvKDS7qoGVNWiXeqPniAzsslJwgI2t8_O5DIw.rm8gexetTBjhgkKM_qtArTRCjeDCytR6RmgNxfpLlQCDfoe.9sGpGkw9Afup._t5vYz22FvdHZKrKYu9nls2HyzCLFDaohCHNSwpo1MkOWJyUh1uqxJmmt8mAFZbIUQo08.DAwy3zETMaLvPXZTpYxPNshs8cIAg8LxkymVQyQ._zKMFz2Zwt8DAeFRHp35eQ9MqBgD_ycn3hNtQP8ZneaMrNQjYxj_PnUUfR8GlogQp6sNnIGukzdjwJhQ-- Received: from [91.200.96.47] by web56401.mail.re3.yahoo.com via HTTP; Fri, 04 Sep 2009 10:29:57 PDT X-Mailer: YahooMailClassic/6.1.2 YahooMailWebService/0.7.347.2 Date: Fri, 4 Sep 2009 10:29:57 -0700 (PDT) From: alexpalias-bsdnet@yahoo.com To: Adrian Penisoara In-Reply-To: <78cb3d3f0909040711i5702c4c7l4dbb89bb1fef259a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org Subject: Re: em driver input errors X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alexpalias-bsdnet@yahoo.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 17:43:34 -0000 --- On Fri, 9/4/09, Adrian Penisoara wrote: > From: Adrian Penisoara > Subject: Re: em driver input errors > To: alexpalias-bsdnet@yahoo.com > Cc: freebsd-net@freebsd.org > Date: Friday, September 4, 2009, 5:11 PM > Hi, Hello > First question that comes to mind is: have you tried device > polling ? > Looking up the thorough decscription you made it appears > not to. Yes, I did try it. I mentioned it in a followup mail (I had scheduled maintenance one week from my first message, and with that occasion I booted a kernel with support for polling). The polling only increased latency, and got me way more errors, and more consistently. If you look at the graphs linked below, instead of having those 35 errors/sec spikes several times per day, I was constantly exceeding 100 errorrs/s, with no error-free parts. I will admit I only had HZ=1000 in the kernel config file. The next step will probably be trying 8.0-RELEASE after it seems stable enough on a test machine. I might try setting polling mode back on for a few hours, and posting graphs. Links to the errors/s and packets/s graphs: http://www.dataxnet.ro/alex/errors.png http://www.dataxnet.ro/alex/packets.png > Please check the polling(4) manual page and Luigi's page > [1] for > detailed information. Basically it switches the device > driver from > interrupt mode to polling mode, allowing to specify the > user/system > CPU usage fraction. > > [1] http://info.iet.unipi.it/~luigi/polling/ > > Regards, > Adrian Penisoara > EnterpriseBSD Thanks for the help Alex From owner-freebsd-net@FreeBSD.ORG Fri Sep 4 21:23: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 946891065672 for ; Fri, 4 Sep 2009 21:23:25 +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 2D1538FC08 for ; Fri, 4 Sep 2009 21:23:24 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so321003qwe.7 for ; Fri, 04 Sep 2009 14:23:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:subject :message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=cBVdnTo44tgyoA0+addtldNEhGRAkG7VJBo2aHIsxbY=; b=Mcv+1H50X3uhThhG6kHXgq3nA7YAoFib9c+HmfpZ/jN7gaxVuvXDV7ZGe3UjHENYjT fgRf0oo5D9ZFjMZiYsbmhNOczwfdhFE69OQgGnDDWS5NG3/o8xGqrkAeLg0wCyniL7gc mzajjP6RqTJuV8YFWxoSxgl0QHcu6jLCMwmw8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=bdYxfEGIbbdKAZU0WG3cLoncfE/u1jMmMDcltPYSUUGiduMyil2IxN6Q48XZ06yecr eGpPDGasz5Rhz4Dtl2THenVHK6aAsmLddsM34jATK5tUpvqFKkWEaXFJNslV1j65oSwk aPeOsQgB+vLE7eTdt8NKQjQKWC6CmUjkrVyS0= Received: by 10.224.64.207 with SMTP id f15mr7853494qai.167.1252099404436; Fri, 04 Sep 2009 14:23:24 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 20sm824267qyk.5.2009.09.04.14.23.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Sep 2009 14:23:22 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 4 Sep 2009 14:22:23 -0700 From: Pyun YongHyeon Date: Fri, 4 Sep 2009 14:22:23 -0700 To: freebsd-net@freebsd.org Message-ID: <20090904212223.GA9950@michelle.cdnetworks.com> References: <20090821142039.GA40018@traktor.dnepro.net> <20090821221932.GE1262@michelle.cdnetworks.com> <20090825083857.GA22983@traktor.dnepro.net> <20090825114649.GA11642@traktor.dnepro.net> <20090825130821.GA41669@traktor.dnepro.net> <20090825182553.GD1282@michelle.cdnetworks.com> <20090826093916.GB10790@traktor.dnepro.net> <20090826094856.GC10790@traktor.dnepro.net> <20090901161310.GA37481@traktor.dnepro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090901161310.GA37481@traktor.dnepro.net> User-Agent: Mutt/1.4.2.3i Subject: Re: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link 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: Fri, 04 Sep 2009 21:23:26 -0000 On Tue, Sep 01, 2009 at 07:13:10PM +0300, Eugene Perevyazko wrote: > On Wed, Aug 26, 2009 at 12:48:56PM +0300, Eugene Perevyazko wrote: > > On Wed, Aug 26, 2009 at 12:39:16PM +0300, Eugene Perevyazko wrote: > > > On Tue, Aug 25, 2009 at 11:25:53AM -0700, Pyun YongHyeon wrote: > > > > > > > > Try attached patch and let me know how it goes on your box. > > > > You can see statistics counters maintained in driver with sysctl. > > > > "sysctl dev.msk.0.stats" will show some numbers if it can see > > > > packets on wire. > > > > > > With attached patch NIC doesn't see link again. > > > All counters in dev.msk.0.stats are 0s. > > > > > > > At the same time the link led on NIC is on, and switch shows that port is up. > > That's different from the unpatched system, where led was off and switch port > > was down. > > > > Any chances to get that NIC working? I tried to look at linux driver for it > (sk98lin) but quickly got lost - it's about 700 lines only for > SkGmInitPhyMarv() - Initialize the Marvell PHY registers sk98lin driver is much more complex than sky2 driver. I agree Linux sky2 driver is also hard to read but I guess it mainly cames from numerous workarounds for vendor's broken controller. > And hw programming is definitely not my expertise :( > Would you back out previous changes and apply the patch at the following URL? http://people.freebsd.org/~yongari/msk/msk.DGE560.diff2 Note, I have no more access to msk(4) hardwares so it wasn't tested at all except compilation. > -- > Eugene Perevyazko From owner-freebsd-net@FreeBSD.ORG Fri Sep 4 22:48: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 62F03106566C for ; Fri, 4 Sep 2009 22:48:04 +0000 (UTC) (envelope-from ccowart@rescomp.berkeley.edu) Received: from hal.rescomp.berkeley.edu (hal.Rescomp.Berkeley.EDU [169.229.70.150]) by mx1.freebsd.org (Postfix) with ESMTP id 503808FC13 for ; Fri, 4 Sep 2009 22:48:04 +0000 (UTC) Received: by hal.rescomp.berkeley.edu (Postfix, from userid 1225) id B6933597C47; Fri, 4 Sep 2009 15:31:23 -0700 (PDT) Date: Fri, 4 Sep 2009 15:31:23 -0700 From: Chris Cowart To: freebsd-net@freebsd.org Message-ID: <20090904223123.GD16213@hal.rescomp.berkeley.edu> Mail-Followup-To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="iVCmgExH7+hIHJ1A" Content-Disposition: inline Organization: RSSP-IT, UC Berkeley User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Crash in ether_input 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, 04 Sep 2009 22:48:04 -0000 --iVCmgExH7+hIHJ1A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, Starting about a week ago, our primary webserver (then running FreeBSD 7.0) began crashing several times a day, typically during our higher-load times of day. We have since upgraded to 7.1p7, but continued to see the frequent crashes.=20 We are running an apache22 webserver with a lot of perl, logging via syslog-ng, and using IPSec in transport mode between the webserver and both the fileserver and logserver. Everything is IPv4. =46rom uname:=20 | FreeBSD mug.rescomp.berkeley.edu 7.1-RELEASE-p7 FreeBSD 7.1-RELEASE-p7 | #0: Wed Sep 2 17:56:59 PDT 2009 | root@mug.rescomp.berkeley.edu:/usr/obj/usr/src/sys/GENERIC amd64 Some information that appears typical across many crashes: | Unread portion of the kernel message buffer: |=20 | Fatal trap 27: stack fault while in kernel mode | cpuid =3D 0; apic id =3D 00 | instruction pointer =3D 0x8:0xffffffff80559fb4 | stack pointer =3D 0x10:0xffffffffae39faf0 | frame pointer =3D 0x10:0xf85ecc37f9239402 | code segment =3D base 0x0, limit 0xfffff, type 0x1b | =3D DPL 0, pres 1, long 1, def32 0, gran 1 | processor eflags =3D interrupt enabled, resume, IOPL =3D 0 | current process =3D 27 (em0 taskq) | trap number =3D 27 | panic: stack fault | cpuid =3D 0 | Uptime: 43m44s | Physical memory: 4082 MB | Dumping 361 MB: 346 330 314 298 282 266 250 234 218 202em0: watchdog time= out -- resetting | (kgdb) bt | #0 doadump () at pcpu.h:195 | #1 0x0000000000000004 in ?? () | #2 0xffffffff804bd9b9 in boot (howto=3D260) at /usr/src/sys/kern/kern_sh= utdown.c:418 | #3 0xffffffff804bddc2 in panic (fmt=3D0x104
) at /usr/src/sys/kern/kern_shutdown.c:574 | #4 0xffffffff807b9f23 in trap_fatal (frame=3D0xffffff00012d66e0, eva=3DV= ariable "eva" is not available. | ) at /usr/src/sys/amd64/amd64/trap.c:764 | #5 0xffffffff807baa75 in trap (frame=3D0xffffffffae39fa40) at /usr/src/s= ys/amd64/amd64/trap.c:565 | #6 0xffffffff807a042e in calltrap () at /usr/src/sys/amd64/amd64/excepti= on.S:209 | #7 0xffffffff80559fb4 in ether_input (ifp=3D0xffffff00012bf000, m=3D0xff= ffff0003576000) at /usr/src/sys/net/if_ethersubr.c:545 | #8 0xffffffff802bd645 in em_rxeof (adapter=3D0xffffffff80e4c000, count= =3D99) at /usr/src/sys/dev/e1000/if_em.c:4539 | #9 0xffffffff802be55e in em_handle_rxtx (context=3DVariable "context" is= not available. | ) at /usr/src/sys/dev/e1000/if_em.c:1702 | #10 0xffffffff804f2afd in taskqueue_run (queue=3D0xffffff00012c8c80) at /= usr/src/sys/kern/subr_taskqueue.c:282 | #11 0xffffffff804f2da6 in taskqueue_thread_loop (arg=3DVariable "arg" is = not available. | ) at /usr/src/sys/kern/subr_taskqueue.c:401 | #12 0xffffffff8049b2f3 in fork_exit (callout=3D0xffffffff804f2d40 , arg=3D0xffffffff80e50588, frame=3D0xffffffffae39fc80) at = /usr/src/sys/kern/kern_fork.c:804 | #13 0xffffffff807a07fe in fork_trampoline () at /usr/src/sys/amd64/amd64/= exception.S:455 | #14 0x0000000000000000 in ?? () | #15 0x0000000000000000 in ?? () | #16 0x0000000000000001 in ?? () [...] | (kgdb) source debug/gdb6 | (kgdb) frame 7 | #7 0xffffffff80559fb4 in ether_input (ifp=3D0xffffff00012bf000, m=3D0xff= ffff0003576000) at /usr/src/sys/net/if_ethersubr.c:545 | 545 eh =3D mtod(m, struct ether_header *); | (kgdb) info locals | eh =3D (struct ether_header *) 0xf85ecc37f9239402 | (kgdb) info args | ifp =3D (struct ifnet *) 0xffffff00012bf000 | m =3D (struct mbuf *) 0xffffff0003576000 | (kgdb) mbuf m | 0xffffff0003576000: 125 bytes ext 0xaf29dcb45d53e701 packet: 125 bytes re= ceived via em0 | 0xbb763383e10eda22Cannot access memory at address 0xbb763383e10eda3a | (kgdb)=20 If anyone can provide some points on other things I can try to get useful data out of these core dumps, I'm open to it. We did decide to stop mounting NFS, upgrade to syslog-ng3 (which supports TLS), and revert the webserver back to a GENERIC kernel. Since booting the GENERIC kernel, the system has been up for nearly 2 days. Right now, we're logging via TLS to a temporary/testing logserver. That logserver is one of our default builds with IPSec. It is configured to forward logs over udp/syslog (via IPSec in transport mode) to our primary logserver.=20 Within hours of beginning to pass the production webserver's logs through this temporary logserver (and thus having its syslog-ng forward to the primary logserver), the temporary logserver began exhibiting the same behavior that the webserver was previously showing. We're totally grasping at straws here, but it's looking like some kind of bug related to IPSec. Maybe related to long messages? High volume of messages? We would love to get this hammered out, so please let me know if there's any debugging we can perform or patches we can try. Thanks, --=20 Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley --iVCmgExH7+hIHJ1A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iQIcBAEBAwAGBQJKoZU7AAoJEC8b9sM8ejXt6ScP/R3VDPUU2zSdpDQtfmZjf4oO eFi3oKAd97XyZ9WkdTadfeS7cQzuqYC9nqqCG7Pzqv14AJ1607dW7LYp6Fe/Y6dt miFv3/PrfQBijeY8Ab9h+NoBwEVUeMuXktHpbdDbgHpWKGtOeRnPk3BwVwXOThqq JhVjl/jjBg/K9U87Y54M+Xj8PIhj0mOVahqwm9kywOCRJ24x9LuD+8OCrHBsE6N+ ke+K+gn7ZXjZlaNfg3UsUh5ZlnfcuxJvfanPMyaIwOT5XvRTP6mNS2n9X2K7WBvk j74pz2L7MSg0cksMHDxBsDYBOipMoqGQHBjBDhtKA9AkCuaFnP21DWOMIrF6sJKg 8VF5Ti0i+Wuy/SsaEr23OxVu+v8RXNbju2XwC/8j8w36ORz3xEJWeUs4l+2nXSUQ qvKc4iJfQqc7sIG9EcHmBp3AcdFRt98ETohhkiUcYT5zpT0+50s396XeJxb+9Igi v8L/b/Lqx7f0TfcdZfzDztlJT8RACQPd+h+zPCh/OTolJMzv5IUNzALDlFOQYeIy cVbe5ZqrQoLu+ldDfhOrKKeI5aJrLKjTvdknIuP+lqWbjkdSqPXbiAi10eHRBSdn txALeQ0wxjPXjMU3W4RdrWnwcSOaiHem8+Yq8GodWAe6qz4JEzSZP2qpnuUgaOhh uR771RZdLf78kLQUw1vJ =wAoy -----END PGP SIGNATURE----- --iVCmgExH7+hIHJ1A-- From owner-freebsd-net@FreeBSD.ORG Sat Sep 5 18:00: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 2E283106566C for ; Sat, 5 Sep 2009 18:00:37 +0000 (UTC) (envelope-from tejblum@yandex-team.ru) Received: from mammoth.yandex.ru (mammoth.yandex.ru [93.158.136.51]) by mx1.freebsd.org (Postfix) with ESMTP id D4A828FC13 for ; Sat, 5 Sep 2009 18:00:36 +0000 (UTC) Received: from tejblum.pp.ru (dhcp250-245.yandex.ru [87.250.250.245]) by mammoth.yandex.ru (Postfix) with ESMTPS id E951C4F6EC9; Sat, 5 Sep 2009 21:45:26 +0400 (MSD) Message-ID: <4AA2A3B5.3000108@yandex-team.ru> Date: Sat, 05 Sep 2009 21:45:25 +0400 From: Dmitrij Tejblum User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.1.17) Gecko/20081109 SeaMonkey/1.1.12 MIME-Version: 1.0 To: Jack Vogel References: <5bc218350908191146j2a22f8dcrdecb0b67eedce5c2@mail.gmail.com> <435336.24858.qm@web63908.mail.re1.yahoo.com> <5bc218350908200953p630d99c6u1538999b308c55f9@mail.gmail.com> <2a41acea0908201008y6e8f160dx27b406db7d3081b7@mail.gmail.com> <5bc218350908201023q14c51cer6effadd49cc4c604@mail.gmail.com> <5bc218350908201032l44859117obc3203ad91fc5706@mail.gmail.com> <5bc218350908201034u553df7feiaead037432279360@mail.gmail.com> <2a41acea0908201037n10505b04le924f29efd5398a7@mail.gmail.com> <5bc218350908201039q574f92e3mabe73d01c35f662c@mail.gmail.com> <2a41acea0908201721o33372c89q25e33b8cde8edf06@mail.gmail.com> In-Reply-To: <2a41acea0908201721o33372c89q25e33b8cde8edf06@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Barney Cordoba , Manish Vachharajani , freebsd-net@freebsd.org Subject: Re: Dropped vs. missed packets in the ixgbe 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, 05 Sep 2009 18:00:37 -0000 Jack, The code you committed does not look right with respect to missed packets counting: for (int i = 0; i < 8; i++) { /* missed_rx tallies misses for the gprc workaround */ missed_rx += IXGBE_READ_REG(hw, IXGBE_MPC(i)); adapter->stats.mpc[i] += missed_rx; /* Running comprehensive total for stats display */ total_missed_rx += adapter->stats.mpc[i]; if (hw->mac.type == ixgbe_mac_82598EB) adapter->stats.rnbc[i] += IXGBE_READ_REG(hw, IXGBE_RNBC(i)); } You see, the value of the MPC(0) register also added to mpc[1], mpc[2], ... mpc[7], and thus gets added to total_missed_rx 8 times. The MPC(1) register gets added to total_missed_rx 7 times, and so on. I would suggest something like this: for (int i = 0; i < 8; i++) { u32 mp; mp = IXGBE_READ_REG(hw, IXGBE_MPC(i)); /* missed_rx tallies misses for the gprc workaround */ missed_rx += mp; adapter->stats.mpc[i] += mp; /* Running comprehensive total for stats display */ total_missed_rx += adapter->stats.mpc[i]; if (hw->mac.type == ixgbe_mac_82598EB) adapter->stats.rnbc[i] += IXGBE_READ_REG(hw, IXGBE_RNBC(i)); } Also, there was PR kern/127834 on this issue, that should be closed as the issue fixed. -- Dima From owner-freebsd-net@FreeBSD.ORG Sat Sep 5 18:10:42 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 DF68A1065676 for ; Sat, 5 Sep 2009 18:10:41 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.210.172]) by mx1.freebsd.org (Postfix) with ESMTP id 927F88FC1A for ; Sat, 5 Sep 2009 18:10:41 +0000 (UTC) Received: by yxe2 with SMTP id 2so3870338yxe.3 for ; Sat, 05 Sep 2009 11:10:40 -0700 (PDT) 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=zwYC2Ve95+9xHfgwt4evgm5EBBPGaHWO3JOy6Ag5564=; b=H0rAwJGzVq7gBIYETatmFMp5xGfBeJ6A2GAxVYprwK8K/BHScsknx+BarUm5imsvif fWxP4iWDXApwcpBfdkXiJ04bwMZn8r2JTked3zVvxH0UHI6CLJEhGznIyCVJT0IZft/9 g8RwqE2DhYKrX5RAiIV0Qncm+sAgbPVQN7nQw= 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=iTXWDTmtPMv+qtBSAGJllHJ2DWRpHT0p8MrW2tJIMmkAtrmge7Uj/gxKF9BP5mX0wn nY3LK2diXcF3pPP1562MKkNiwC+j+VazQRo8eDEwSAXjmEbmURk3xAgyh0LStp4NiVoq 6cn4hfuexB6rxHY63gLpMa/fLxOgEHq8j7JAY= MIME-Version: 1.0 Received: by 10.101.56.13 with SMTP id i13mr1539318ank.194.1252174240779; Sat, 05 Sep 2009 11:10:40 -0700 (PDT) In-Reply-To: <4AA2A3B5.3000108@yandex-team.ru> References: <5bc218350908191146j2a22f8dcrdecb0b67eedce5c2@mail.gmail.com> <5bc218350908200953p630d99c6u1538999b308c55f9@mail.gmail.com> <2a41acea0908201008y6e8f160dx27b406db7d3081b7@mail.gmail.com> <5bc218350908201023q14c51cer6effadd49cc4c604@mail.gmail.com> <5bc218350908201032l44859117obc3203ad91fc5706@mail.gmail.com> <5bc218350908201034u553df7feiaead037432279360@mail.gmail.com> <2a41acea0908201037n10505b04le924f29efd5398a7@mail.gmail.com> <5bc218350908201039q574f92e3mabe73d01c35f662c@mail.gmail.com> <2a41acea0908201721o33372c89q25e33b8cde8edf06@mail.gmail.com> <4AA2A3B5.3000108@yandex-team.ru> Date: Sat, 5 Sep 2009 11:10:40 -0700 Message-ID: <2a41acea0909051110v755f66cbkfc4d2f84b3d8a353@mail.gmail.com> From: Jack Vogel To: Dmitrij Tejblum Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Barney Cordoba , Manish Vachharajani , freebsd-net@freebsd.org Subject: Re: Dropped vs. missed packets in the ixgbe 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, 05 Sep 2009 18:10:42 -0000 Sigh, yes, you're right, I will get this corrected after the holiday weekend. Thanks, Jack On Sat, Sep 5, 2009 at 10:45 AM, Dmitrij Tejblum wrote: > Jack, > > The code you committed does not look right with respect to missed packets > counting: > > > for (int i = 0; i < 8; i++) { > /* missed_rx tallies misses for the gprc workaround */ > missed_rx += IXGBE_READ_REG(hw, IXGBE_MPC(i)); > adapter->stats.mpc[i] += missed_rx; > /* Running comprehensive total for stats display */ > total_missed_rx += adapter->stats.mpc[i]; > if (hw->mac.type == ixgbe_mac_82598EB) > adapter->stats.rnbc[i] += > IXGBE_READ_REG(hw, IXGBE_RNBC(i)); > } > > You see, the value of the MPC(0) register also added to mpc[1], mpc[2], ... > mpc[7], and thus gets added to total_missed_rx 8 times. The MPC(1) register > gets added to total_missed_rx 7 times, and so on. > > > I would suggest something like this: > > for (int i = 0; i < 8; i++) { > u32 mp; > mp = IXGBE_READ_REG(hw, IXGBE_MPC(i)); > /* missed_rx tallies misses for the gprc workaround */ > missed_rx += mp; > adapter->stats.mpc[i] += mp; > /* Running comprehensive total for stats display */ > total_missed_rx += adapter->stats.mpc[i]; > if (hw->mac.type == ixgbe_mac_82598EB) > adapter->stats.rnbc[i] += > IXGBE_READ_REG(hw, IXGBE_RNBC(i)); > } > > Also, there was PR kern/127834 on this issue, that should be closed as the > issue fixed. > > > > > -- > Dima > From owner-freebsd-net@FreeBSD.ORG Sat Sep 5 21:03:44 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 58553106566B for ; Sat, 5 Sep 2009 21:03:44 +0000 (UTC) (envelope-from stef-list@memberwebs.com) Received: from mail.npubs.com (mail.npubs.com [74.82.45.72]) by mx1.freebsd.org (Postfix) with ESMTP id 4CA0C8FC16 for ; Sat, 5 Sep 2009 21:03:43 +0000 (UTC) Resent-Message-Id: From: Stef Walter User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "freebsd-net@FreeBSD.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Resent-Date: Sat, 5 Sep 2009 21:03:44 +0000 (UTC) Resent-From: stef-list@memberwebs.com Cc: bms@incunabulum.net Subject: Panic in imo_match_source (netinet/in_mcast.c) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stef@memberwebs.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Sat, 05 Sep 2009 21:03:44 -0000 X-List-Received-Date: Sat, 05 Sep 2009 21:03:44 -0000 On a new VPN server, running OSPF, I'm experiencing regular panics at: imo_match_source: !AF_INET System is: 8.0-BETA3 i386 This is the stack trace: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/137164&cat= I noticed this code was changed as part of an IGMPv3 update in March: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/in_mcast.c#rev1.15 Anyone heard of this before, or knows of a commit/patch that might fix the problem? Cheers, Stef