From owner-freebsd-net@FreeBSD.ORG Sun Aug 30 02:14:28 2009
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
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: <B583FBF374231F4A89607B4D08578A4305277CDC@bcs-mail03.internal.cacheflow.com>
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: <BFC746D7-9E88-43AD-8320-96928633C532@lurchi.franken.de>
<B583FBF374231F4A89607B4D08578A4305277931@bcs-mail03.internal.cacheflow.com>
<38B715CC-9C82-4D8D-97CC-134A9CB01A0C@lurchi.franken.de>
From: "Li, Qing" <qing.li@bluecoat.com>
To: =?iso-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de>
Cc: qingli@freebsd.org, "Bjoern A. Zeeb" <bz@freebsd.org>,
Randall Stewart <rrs@lakerest.net>, 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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: <FC7350CE-8C09-4D81-BF18-4A89DF21CEFB@lurchi.franken.de>
From: =?ISO-8859-1?Q?Michael_T=FCxen?= <Michael.Tuexen@lurchi.franken.de>
To: "Li, Qing" <qing.li@bluecoat.com>
In-Reply-To: <B583FBF374231F4A89607B4D08578A4305277CDC@bcs-mail03.internal.cacheflow.com>
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: <BFC746D7-9E88-43AD-8320-96928633C532@lurchi.franken.de>
<B583FBF374231F4A89607B4D08578A4305277931@bcs-mail03.internal.cacheflow.com>
<38B715CC-9C82-4D8D-97CC-134A9CB01A0C@lurchi.franken.de>
<B583FBF374231F4A89607B4D08578A4305277CDC@bcs-mail03.internal.cacheflow.com>
X-Mailer: Apple Mail (2.936)
Cc: qingli@freebsd.org, "Bjoern A. Zeeb" <bz@freebsd.org>,
Randall Stewart <rrs@lakerest.net>, 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@hub.freebsd.org>; 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 <freebsd-net@hub.freebsd.org>; 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 <freebsd-net@freefall.freebsd.org>; 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 <sam@errno.com>
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 <sam@errno.com>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <sam@errno.com>
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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@hub.freebsd.org>; 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 <freebsd-net@hub.freebsd.org>; 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 <freebsd-net@freefall.freebsd.org>; 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 <sshutdownow@gmail.com>
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 <sshutdownow@gmail.com>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <sshutdownow@gmail.com>
To: Sam Leffler <sam@errno.com>
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 <sam@errno.com>
> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Mon, 31 Aug 2009 01:05:09 +0000 (UTC)
Received: by gxk27 with SMTP id 27so4740843gxk.12
for <freebsd-net@freebsd.org>; 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: <C98FD50473CC484D9A3EFA86867EA14C@dts>
From: Sin <sinister@gmail.com>
To: <freebsd-net@freebsd.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric =
0 mtu 1500
options=3D8<VLAN_MTU>
ether 00:0f:3d:88:18:31
media: Ethernet autoselect (none)
status: no carrier
vr0: flags=3D8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric =
0 mtu 1500
options=3D2808<VLAN_MTU,WOL_UCAST,WOL_MAGIC>
ether 00:05:5d:75:1a:12
media: Ethernet autoselect (none)
status: no carrier
vr1: flags=3D8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric =
0 mtu 1500
options=3D2808<VLAN_MTU,WOL_UCAST,WOL_MAGIC>
ether 00:05:5d:e9:61:79
media: Ethernet autoselect (none)
status: no carrier
ath0: flags=3D8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> =
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<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric =
0 mtu 1500
options=3D8<VLAN_MTU>
ether 00:11:95:d7:25:e3
media: Ethernet autoselect (none)
status: no carrier
sk2: flags=3D8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric =
0 mtu 1500
options=3D8<VLAN_MTU>
ether 00:11:95:d7:25:ee
media: Ethernet autoselect (none)
status: no carrier
lo0: flags=3D8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
inet 127.0.0.1 netmask 0xff000000
bridge0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 3 priority 128 path cost 55
member: vr0 flags=3D143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 2 priority 128 path cost 55
member: sk2 flags=3D143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 6 priority 128 path cost 55
member: sk1 flags=3D143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 5 priority 128 path cost 55
member: sk0 flags=3D143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
ifmaxaddr 0 port 1 priority 128 path cost 55
member: ath0 flags=3D143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <spawk@acm.poly.edu>
User-Agent: Thunderbird 2.0.0.19 (X11/20090108)
MIME-Version: 1.0
To: Sin <sinister@gmail.com>
References: <C98FD50473CC484D9A3EFA86867EA14C@dts>
In-Reply-To: <C98FD50473CC484D9A3EFA86867EA14C@dts>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=8<VLAN_MTU>
> ether 00:0f:3d:88:18:31
> media: Ethernet autoselect (none)
> status: no carrier
> vr0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=2808<VLAN_MTU,WOL_UCAST,WOL_MAGIC>
> ether 00:05:5d:75:1a:12
> media: Ethernet autoselect (none)
> status: no carrier
> vr1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=2808<VLAN_MTU,WOL_UCAST,WOL_MAGIC>
> ether 00:05:5d:e9:61:79
> media: Ethernet autoselect (none)
> status: no carrier
> ath0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> 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<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=8<VLAN_MTU>
> ether 00:11:95:d7:25:e3
> media: Ethernet autoselect (none)
> status: no carrier
> sk2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> options=8<VLAN_MTU>
> ether 00:11:95:d7:25:ee
> media: Ethernet autoselect (none)
> status: no carrier
> lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
> inet 127.0.0.1 netmask 0xff000000
> bridge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> ifmaxaddr 0 port 3 priority 128 path cost 55
> member: vr0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> ifmaxaddr 0 port 2 priority 128 path cost 55
> member: sk2 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> ifmaxaddr 0 port 6 priority 128 path cost 55
> member: sk1 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> ifmaxaddr 0 port 5 priority 128 path cost 55
> member: sk0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> ifmaxaddr 0 port 1 priority 128 path cost 55
> member: ath0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP>
> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@hub.freebsd.org>; 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 <freebsd-net@hub.freebsd.org>; 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 <freebsd-net@freefall.freebsd.org>; 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 <paul@gtcomm.net>
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 <paul@gtcomm.net>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <paul@gtcomm.net>
To: Ed Maste <emaste@freebsd.org>
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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@FreeBSD.org>; 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 <freebsd-net@FreeBSD.org>; 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 <freebsd-net@FreeBSD.org>; 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 <bugmaster@FreeBSD.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <ipv6_addr> -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 <host> -iface <nic> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Mon, 31 Aug 2009 17:01:39 +0000 (UTC)
Resent-Message-Id: <none>
From: Stef Walter <stef-list@memberwebs.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: "freebsd-net@FreeBSD.org" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@hub.freebsd.org>; 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 <freebsd-net@hub.freebsd.org>; 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 <freebsd-net@freefall.freebsd.org>; 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 <stef-list@memberwebs.com>
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 <stef-list@memberwebs.com>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <stef-list@memberwebs.com>
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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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: <B583FBF374231F4A89607B4D08578A430527800B@bcs-mail03.internal.cacheflow.com>
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" <qing.li@bluecoat.com>
To: <stef@memberwebs.com>, "freebsd-net@FreeBSD.org" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@FreeBSD.org>; 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 <freebsd-net@FreeBSD.org>; 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 <bms@incunabulum.net>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Stef Walter <stef-list@memberwebs.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@FreeBSD.org>; 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 <freebsd-net@FreeBSD.org>; 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 <jhay@meraka.org.za>
To: Stef Walter <stef-list@memberwebs.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <stef-list@memberwebs.com>
> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <julian@elischer.org>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Mon, 31 Aug 2009 19:47:33 +0000 (UTC)
Resent-Message-Id: <none>
From: Stef Walter <stef-list@memberwebs.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Julian Elischer <julian@elischer.org>
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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@hub.freebsd.org>; 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 <freebsd-net@hub.freebsd.org>; 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 <freebsd-net@freefall.freebsd.org>; 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 <stef-list@memberwebs.com>
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 <stef-list@memberwebs.com>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <stef-list@memberwebs.com>
To: "Li, Qing" <qing.li@bluecoat.com>
Cc: "freebsd-net@FreeBSD.org" <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: <owner-freebsd-net@FreeBSD.ORG>
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: <none>
From: Stef Walter <stef-list@memberwebs.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: "Li, Qing" <qing.li@bluecoat.com>
References: <200908311702.n7VH2iHI022732@whisker.bluecoat.com>
<B583FBF374231F4A89607B4D08578A430527800B@bcs-mail03.internal.cacheflow.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" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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" <seklecki@noc.cfi.pgh.pa.us>
To: Graham Smith <smith.graham23@gmail.com>
In-Reply-To: <be61b3bb0908241212i7539feb2p3af06c328eddd732@mail.gmail.com>
References: <be61b3bb0908241212i7539feb2p3af06c328eddd732@mail.gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <net@freebsd.org>; 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 <net@freebsd.org>; 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" <bzeeb-lists@lists.zabbadoz.net>
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 <net@freebsd.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <net@freebsd.org>; 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 <net@freebsd.org>; 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 <julian@elischer.org>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>
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 <net@freebsd.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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: <B583FBF374231F4A89607B4D08578A43052EEDE6@bcs-mail03.internal.cacheflow.com>
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: <B583FBF374231F4A89607B4D08578A43052776D0@bcs-mail03.internal.cacheflow.com>
<20090830.024420.174808572.hrs@allbsd.org>
From: "Li, Qing" <qing.li@bluecoat.com>
To: "Hiroki Sato" <hrs@freebsd.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@hub.freebsd.org>; 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 <freebsd-net@hub.freebsd.org>; 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 <freebsd-net@freefall.freebsd.org>; 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" <pprocacci@datapipe.net>
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" <pprocacci@datapipe.net>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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" <pprocacci@datapipe.net>
To: <bug-followup@FreeBSD.org>, <samuel@boivie.org>
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: <Belkin USB2.0 WLAN, rev 2.00/48.10, addr 2> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <cjeker@diehard.n-r-g.com>
To: freebsd-net@freebsd.org
Message-ID: <20090901062449.GC25711@diehard.n-r-g.com>
Mail-Followup-To: Claudio Jeker <cjeker@diehard.n-r-g.com>,
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <john@dnepro.net>
To: freebsd-net@freebsd.org
Message-ID: <20090901161310.GA37481@traktor.dnepro.net>
Mail-Followup-To: freebsd-net@freebsd.org,
Pyun YongHyeon <pyunyh@gmail.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>
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 <pyunyh@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <bounces@nabble.com>) 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 <rconan@uvic.ca>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Tue, 1 Sep 2009 17:34:19 +0000 (UTC)
Received: by yxe33 with SMTP id 33so346316yxe.7
for <freebsd-net@freebsd.org>; 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: <abd04180909011034p1e2fc211v126fff410fa032e5@mail.gmail.com>
From: Fang Wang <wangfangcs@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Tue, 1 Sep 2009 23:30:34 +0000 (UTC)
Received: by fxm6 with SMTP id 6so414781fxm.43
for <freebsd-net@freebsd.org>; 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 <glen.j.barber@gmail.com>
To: rconan <rconan@uvic.ca>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2009 23:30:35 -0000
On Tue, Sep 1, 2009 at 12:15 PM, rconan<rconan@uvic.ca> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <hrs@FreeBSD.org>
In-Reply-To: <B583FBF374231F4A89607B4D08578A43052EEDE6@bcs-mail03.internal.cacheflow.com>
References: <B583FBF374231F4A89607B4D08578A43052776D0@bcs-mail03.internal.cacheflow.com>
<20090830.024420.174808572.hrs@allbsd.org>
<B583FBF374231F4A89607B4D08578A43052EEDE6@bcs-mail03.internal.cacheflow.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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" <qing.li@bluecoat.com> wrote
in <B583FBF374231F4A89607B4D08578A43052EEDE6@bcs-mail03.internal.cacheflow.com>:
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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Wed, 2 Sep 2009 12:07:11 +0000 (UTC)
Resent-Message-Id: <none>
From: Stef Walter <stef-list@memberwebs.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: "freebsd-net@FreeBSD.org" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Wed, 2 Sep 2009 15:02:12 +0000 (UTC)
Received: by ywh15 with SMTP id 15so2656431ywh.10
for <freebsd-net@freebsd.org>; 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 <sinister@gmail.com>
To: <freebsd-net@freebsd.org>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> =
metric 0 mtu 1500
ether 00:17:9a:4c:e7:83
media: IEEE 802.11 Wireless Ethernet autoselect mode 11g =
<hostap>
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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <sam@errno.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Sin <sinister@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
> ether 00:17:9a:4c:e7:83
> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap>
> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Wed, 2 Sep 2009 15:34:29 +0000 (UTC)
Received: by yxe40 with SMTP id 40so1304464yxe.13
for <freebsd-net@freebsd.org>; 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: <C3B4A04A39B74965AFA22B0A62876DB1@dts>
From: Sin <sinister@gmail.com>
To: "Sam Leffler" <sam@errno.com>,
"Sin" <sinister@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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" <sam@errno.com>
To: "Sin" <sinister@gmail.com>
Cc: <freebsd-net@freebsd.org>
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<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0
>> mtu 1500
>> ether 00:17:9a:4c:e7:83
>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g <hostap>
>> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <hrs@FreeBSD.org>
In-Reply-To: <20090902.155958.08019398.hrs@allbsd.org>
References: <20090830.024420.174808572.hrs@allbsd.org>
<B583FBF374231F4A89607B4D08578A43052EEDE6@bcs-mail03.internal.cacheflow.com>
<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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <hrs@freebsd.org> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> 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<UP,POINTOPOINT,MULTICAST> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@FreeBSD.org>; 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 <freebsd-net@FreeBSD.org>; 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 <freebsd-net@FreeBSD.org>; 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" <killing@multiplay.co.uk>
To: "David Christensen" <davidch@broadcom.com>,
"DutchDaemon" <freebsd@bengrimm.net>, <freebsd-net@FreeBSD.org>
References: <200906011450.n51Eo3Wp095320@freefall.freebsd.org><5CC0D128FDDD4BFBA815E2D8D388B2DF@multiplay.co.uk><5D267A3F22FD854F8F48B3D2B523819339EC2B524E@IRVEXCHCCR01.corp.ad.broadcom.com>
<C2A39F993C814FA3AD43BA0ED15903A0@multiplay.co.uk>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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" <killing@multiplay.co.uk>
> Thanks for the update David, if there is anything we can do
> to help let us know.
>
> Regards
> Steve
>
> ----- Original Message -----
> From: "David Christensen" <davidch@broadcom.com>
>
>> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <sam@errno.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Sin <sinister@gmail.com>
References: <4790A7EF670C4698ADB76933788A218F@dts> <4A9E8C68.3060300@errno.com>
<C3B4A04A39B74965AFA22B0A62876DB1@dts>
In-Reply-To: <C3B4A04A39B74965AFA22B0A62876DB1@dts>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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" <sam@errno.com>
> To: "Sin" <sinister@gmail.com>
> Cc: <freebsd-net@freebsd.org>
> 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<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST>
>>> metric 0 mtu 1500
>>> ether 00:17:9a:4c:e7:83
>>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
>>> <hostap>
>>> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Thu, 3 Sep 2009 19:00:00 +0000 (UTC)
Received: by ywh17 with SMTP id 17so302903ywh.3
for <freebsd-net@freebsd.org>; 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: <F1A40CDCE4EC46F2820AC95ED03195C4@dts>
From: Sin <sinister@gmail.com>
To: "Sam Leffler" <sam@errno.com>,
"Sin" <sinister@gmail.com>
References: <4790A7EF670C4698ADB76933788A218F@dts> <4A9E8C68.3060300@errno.com>
<C3B4A04A39B74965AFA22B0A62876DB1@dts> <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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" <sam@errno.com>
To: "Sin" <sinister@gmail.com>
Cc: <freebsd-net@freebsd.org>
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" <sam@errno.com>
>> To: "Sin" <sinister@gmail.com>
>> Cc: <freebsd-net@freebsd.org>
>> 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<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric
>>>> 0 mtu 1500
>>>> ether 00:17:9a:4c:e7:83
>>>> media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
>>>> <hostap>
>>>> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@hub.freebsd.org>; 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 <freebsd-net@hub.freebsd.org>; 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 <freebsd-net@freefall.freebsd.org>; 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 <burt@cs.miami.edu>
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 <burt@cs.miami.edu>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <burt@cs.miami.edu>
To: bug-followup@FreeBSD.org, Joe Marcus Clarke <marcus@marcuscom.com>
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 :<br>=A0<br> <a href=3D"http://www.freebsd.org/cgi/query-pr.c=
gi?pr=3Dkern/130628">http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/1306=
28</a><br><br>appears in 7.2-R-p3; With this kernel, against Fedora 8 distr=
os:<br>
<br>Linux <a href=3D"http://prism09.cs.miami.edu/" target=3D"_blank">prism0=
9.cs.miami.edu</a> 2.6.26.8-57.fc8 #1 SMP Thu Dec 18 18:59:49 EST 2008 x86_=
64 x86_64 x86_64 GNU/Linux<br><br>which are using NFS (tcp) to mount homedi=
rs form the freebsd server to the fedora client, <br>
server will become unresponsive from the network during graphical login of =
a client.<br><br>Applying the patch given in the article <a href=3D"http://=
www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/130628">http://www.freebsd.org/c=
gi/query-pr.cgi?pr=3Dkern/130628</a> 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.<br>
<br>When the problem appears, the sever cannot be pinged, an other network =
connections are halted. <br><br>On the server, for instance, top shows:<br>=
<br style=3D"font-family: courier new,monospace;"><span style=3D"font-famil=
y: courier new,monospace;">Proc, state, pri</span><br style=3D"font-family:=
courier new,monospace;">
<span style=3D"font-family: courier new,monospace;">--------------------</s=
pan><br style=3D"font-family: courier new,monospace;"><span style=3D"font-f=
amily: courier new,monospace;">pc.lockd=A0=A0 *tcpin=A0=A0 -68 </span><br s=
tyle=3D"font-family: courier new,monospace;">
<span style=3D"font-family: courier new,monospace;">nfsd=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 -=A0=A0=A0=A0=A0=A0 4</span><br style=3D"font-family: courier new=
,monospace;"><span style=3D"font-family: courier new,monospace;">rpcbind=A0=
=A0=A0=A0 select=A0=A0 44</span><br style=3D"font-family: courier new,monos=
pace;">
<span style=3D"font-family: courier new,monospace;">ntpd=A0=A0=A0=A0=A0=A0=
=A0 select=A0=A0 44</span><br style=3D"font-family: courier new,monospace;"=
><span style=3D"font-family: courier new,monospace;">nfsd=A0=A0=A0=A0=A0=A0=
=A0 select=A0=A0 44</span><br style=3D"font-family: courier new,monospace;"=
>
<span style=3D"font-family: courier new,monospace;">... etc...</span><br><b=
r><br>Also,<br><br><span style=3D"font-family: courier new,monospace;">./lo=
ckd restart</span><br style=3D"font-family: courier new,monospace;"><span s=
tyle=3D"font-family: courier new,monospace;">Stopping lockd.</span><br styl=
e=3D"font-family: courier new,monospace;">
<span style=3D"font-family: courier new,monospace;">Waiting for PIDS: 1114,=
1114, 1114, 1114,....</span><br style=3D"font-family: courier new,monospac=
e;"><br>kill -9 1114 also ineffective.<br><br>So it seems to be something s=
pinning in lockd.<br>
<br>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.<br><br><br><br>
--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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <spawk@acm.poly.edu>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <mel@rachie.is-a-geek.net>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <ithread_loop>, 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}} <repeats 89 times>, {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}} <repeats 165 times>}}
(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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Fri, 4 Sep 2009 13:01:11 +0000 (UTC)
Received: by fxm6 with SMTP id 6so639338fxm.43
for <freebsd-net@freebsd.org>; 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 <artis.caune@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2009 13:01:12 -0000
2009/8/1 <alexpalias-bsdnet@yahoo.com>:
> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Fri, 4 Sep 2009 14:11:23 +0000 (UTC)
Received: by ey-out-2122.google.com with SMTP id 4so809933eyf.9
for <freebsd-net@freebsd.org>; 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 <ady@freebsd.ady.ro>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2009 14:11:24 -0000
Hi,
On Sat, Aug 1, 2009 at 3:05 PM, <alexpalias-bsdnet@yahoo.com> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Fri, 4 Sep 2009 15:59:24 +0000 (UTC)
Received: by fxm6 with SMTP id 6so758958fxm.43
for <freebsd-net@freebsd.org>; 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" <gigabyte.tmn@gmail.com>
To: "Mel Flynn" <mel@rachie.is-a-geek.net>
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 <gigabyte.tmn@gmail.com>
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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" <mel@rachie.is-a-geek.net>
To: <FreeBSD-gnats-submit@freebsd.org>
Cc: <freebsd-net@FreeBSD.org>
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: <owner-freebsd-net@FreeBSD.ORG>
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 <net@freebsd.org>; 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 <net@freebsd.org>; 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 <net@freebsd.org>; 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 <net@freebsd.org>; 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 <wjw@digiware.nl>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <net@freebsd.org>; 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 <net@freebsd.org>; Fri, 4 Sep 2009 17:23:09 +0000 (UTC)
Received: by vws27 with SMTP id 27so813082vws.3
for <net@freebsd.org>; 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 <manishv@lineratesystems.com>
To: Willem Jan Withagen <wjw@digiware.nl>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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.<interface number>.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<wjw@digiware.nl> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <artis.caune@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2009 17:28:43 -0000
--- On Fri, 9/4/09, Artis Caune <artis.caune@gmail.com> 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 <Link#1> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <net@freebsd.org>; 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 <net@freebsd.org>; 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 <wjw@digiware.nl>
Organization: Digiware
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Manish Vachharajani <manishv@lineratesystems.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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.<interface number>.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<wjw@digiware.nl> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Fri, 4 Sep 2009 17:41:16 +0000 (UTC)
Received: by vws27 with SMTP id 27so823129vws.3
for <freebsd-net@freebsd.org>; 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 <manishv@lineratesystems.com>
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 <artis.caune@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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, <alexpalias-bsdnet@yahoo.com> wrote:
> --- On Fri, 9/4/09, Artis Caune <artis.caune@gmail.com> 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 <Link#1> =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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <ady@freebsd.ady.ro>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Sep 2009 17:43:34 -0000
--- On Fri, 9/4/09, Adrian Penisoara <ady@freebsd.ady.ro> wrote:
> From: Adrian Penisoara <ady@freebsd.ady.ro>
> 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Fri, 4 Sep 2009 21:23:24 +0000 (UTC)
Received: by qw-out-2122.google.com with SMTP id 3so321003qwe.7
for <freebsd-net@freebsd.org>; 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 <pyunyh@gmail.com>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <ccowart@rescomp.berkeley.edu>
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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <Address 0x104 out of bounds=
>) 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 <taskqu=
eue_thread_loop>, 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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; 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 <tejblum@yandex-team.ru>
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 <jfvogel@gmail.com>
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 <barney_cordoba@yahoo.com>,
Manish Vachharajani <manishv@lineratesystems.com>, 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Sat, 5 Sep 2009 18:10:41 +0000 (UTC)
Received: by yxe2 with SMTP id 2so3870338yxe.3
for <freebsd-net@freebsd.org>; 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 <jfvogel@gmail.com>
To: Dmitrij Tejblum <tejblum@yandex-team.ru>
Content-Type: text/plain; charset=ISO-8859-1
X-Content-Filtered-By: Mailman/MimeDel 2.1.5
Cc: Barney Cordoba <barney_cordoba@yahoo.com>,
Manish Vachharajani <manishv@lineratesystems.com>, 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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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 <tejblum@yandex-team.ru>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: <owner-freebsd-net@FreeBSD.ORG>
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 <freebsd-net@freebsd.org>; 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 <freebsd-net@freebsd.org>; Sat, 5 Sep 2009 21:03:43 +0000 (UTC)
Resent-Message-Id: <none>
From: Stef Walter <stef-list@memberwebs.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: "freebsd-net@FreeBSD.org" <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 <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
<mailto:freebsd-net-request@freebsd.org?subject=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