From qing.li at bluecoat.com  Tue Sep  1 01:44:33 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Tue Sep  1 01:44:39 2009
Subject: IPv6 regression on 8.x
In-Reply-To: <20090830.024420.174808572.hrs@allbsd.org>
References: <B583FBF374231F4A89607B4D08578A43052776D0@bcs-mail03.internal.cacheflow.com>
	<20090830.024420.174808572.hrs@allbsd.org>
Message-ID: <B583FBF374231F4A89607B4D08578A43052EEDE6@bcs-mail03.internal.cacheflow.com>

Hi Hiroki,

>
>  2) Issue of subnet-router anycast address with a global address
> 
>  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?
> 

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 
3 em interfaces, whereas you have 2 em interfaces and 1 re, but I 
don't see how that would make a difference.

Would it be possible for you to email me your system configuration 
produced from "ifconfig" and "netstat" privately ?

Thank you.

-- Qing




From pprocacci at datapipe.net  Tue Sep  1 05:20:03 2009
From: pprocacci at datapipe.net (Paul A. Procacci)
Date: Tue Sep  1 05:20:09 2009
Subject: kern/138292: [zyd] [usb8] "zyd0: device timeout" with ZyXEL
	G-202
Message-ID: <200909010520.n815K3S2081239@freefall.freebsd.org>

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 linimon at FreeBSD.org  Tue Sep  1 05:32:50 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Tue Sep  1 05:32:56 2009
Subject: kern/138427: [wpi] [panic] Kernel panic after trying set
	monitor wlanmode on Intel 3945 ABG (wpi driver)
Message-ID: <200909010532.n815WoJL001714@freefall.freebsd.org>

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 cjeker at diehard.n-r-g.com  Tue Sep  1 06:51:32 2009
From: cjeker at diehard.n-r-g.com (Claudio Jeker)
Date: Tue Sep  1 06:51:38 2009
Subject: [patch] Unbreak setfib + routing daemons
References: <4A9C137C.7020303@elischer.org>
Message-ID: <20090901062449.GC25711@diehard.n-r-g.com>

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 john at dnepro.net  Tue Sep  1 16:13:14 2009
From: john at dnepro.net (Eugene Perevyazko)
Date: Tue Sep  1 16:13:21 2009
Subject: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link
In-Reply-To: <20090826094856.GC10790@traktor.dnepro.net>
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>
Message-ID: <20090901161310.GA37481@traktor.dnepro.net>

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 rconan at uvic.ca  Tue Sep  1 16:33:06 2009
From: rconan at uvic.ca (rconan)
Date: Tue Sep  1 16:33:18 2009
Subject: Intel 5100 AGN Wifi
Message-ID: <25243305.post@talk.nabble.com>


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 wangfangcs at gmail.com  Tue Sep  1 17:34:19 2009
From: wangfangcs at gmail.com (Fang Wang)
Date: Tue Sep  1 17:34:27 2009
Subject: TCP UTO (RFC 5482) patch calls for review
Message-ID: <abd04180909011034p1e2fc211v126fff410fa032e5@mail.gmail.com>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tcputo.diff
Type: text/x-patch
Size: 39265 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090901/6f47c43e/tcputo.bin
From glen.j.barber at gmail.com  Tue Sep  1 23:30:35 2009
From: glen.j.barber at gmail.com (Glen Barber)
Date: Tue Sep  1 23:30:41 2009
Subject: Intel 5100 AGN Wifi
In-Reply-To: <25243305.post@talk.nabble.com>
References: <25243305.post@talk.nabble.com>
Message-ID: <4ad871310909011630k3cbd8596nd57ec60270f4fe7b@mail.gmail.com>

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 hrs at FreeBSD.org  Wed Sep  2 07:00:51 2009
From: hrs at FreeBSD.org (Hiroki Sato)
Date: Wed Sep  2 07:00:59 2009
Subject: IPv6 regression on 8.x
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>
Message-ID: <20090902.155958.08019398.hrs@allbsd.org>

"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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090902/b7ea69ce/attachment.pgp
From stef-list at memberwebs.com  Wed Sep  2 12:07:12 2009
From: stef-list at memberwebs.com (Stef Walter)
Date: Wed Sep  2 12:20:17 2009
Subject: ath0: ath_rx_proc: no mbuf!
References: <20090820042016.C8F913039754@mx.npubs.com>
Message-ID: <mailman.5.1251894017.1066.freebsd-net@freebsd.org>

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 sinister at gmail.com  Wed Sep  2 15:02:13 2009
From: sinister at gmail.com (Sin)
Date: Wed Sep  2 15:02:19 2009
Subject: toggle short / long preamble with hostapd
Message-ID: <4790A7EF670C4698ADB76933788A218F@dts>

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


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
From sam at errno.com  Wed Sep  2 15:16:57 2009
From: sam at errno.com (Sam Leffler)
Date: Wed Sep  2 15:17:04 2009
Subject: toggle short / long preamble with hostapd
In-Reply-To: <4790A7EF670C4698ADB76933788A218F@dts>
References: <4790A7EF670C4698ADB76933788A218F@dts>
Message-ID: <4A9E8C68.3060300@errno.com>

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 sinister at gmail.com  Wed Sep  2 15:34:31 2009
From: sinister at gmail.com (Sin)
Date: Wed Sep  2 15:34:37 2009
Subject: toggle short / long preamble with hostapd
References: <4790A7EF670C4698ADB76933788A218F@dts> <4A9E8C68.3060300@errno.com>
Message-ID: <C3B4A04A39B74965AFA22B0A62876DB1@dts>

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 hrs at FreeBSD.org  Wed Sep  2 19:41:05 2009
From: hrs at FreeBSD.org (Hiroki Sato)
Date: Wed Sep  2 19:41:18 2009
Subject: IPv6 regression on 8.x
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>
Message-ID: <20090903.043840.213910223.hrs@allbsd.org>

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090902/4ba77330/attachment.pgp
From killing at multiplay.co.uk  Wed Sep  2 21:17:36 2009
From: killing at multiplay.co.uk (Steven Hartland)
Date: Wed Sep  2 21:17:42 2009
Subject: kern/134658: [bce] bce driver fails on PowerEdge m610 blade.
References: <200906011450.n51Eo3Wp095320@freefall.freebsd.org><5CC0D128FDDD4BFBA815E2D8D388B2DF@multiplay.co.uk><5D267A3F22FD854F8F48B3D2B523819339EC2B524E@IRVEXCHCCR01.corp.ad.broadcom.com>
	<C2A39F993C814FA3AD43BA0ED15903A0@multiplay.co.uk>
Message-ID: <59E03381ABC6401B9572DB1BD3302543@multiplay.co.uk>

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 sam at errno.com  Thu Sep  3 18:04:16 2009
From: sam at errno.com (Sam Leffler)
Date: Thu Sep  3 18:04:22 2009
Subject: toggle short / long preamble with hostapd
In-Reply-To: <C3B4A04A39B74965AFA22B0A62876DB1@dts>
References: <4790A7EF670C4698ADB76933788A218F@dts> <4A9E8C68.3060300@errno.com>
	<C3B4A04A39B74965AFA22B0A62876DB1@dts>
Message-ID: <4AA0051F.8080202@errno.com>

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 sinister at gmail.com  Thu Sep  3 19:00:01 2009
From: sinister at gmail.com (Sin)
Date: Thu Sep  3 19:00:07 2009
Subject: toggle short / long preamble with hostapd
References: <4790A7EF670C4698ADB76933788A218F@dts> <4A9E8C68.3060300@errno.com>
	<C3B4A04A39B74965AFA22B0A62876DB1@dts> <4AA0051F.8080202@errno.com>
Message-ID: <F1A40CDCE4EC46F2820AC95ED03195C4@dts>

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 burt at cs.miami.edu  Thu Sep  3 19:10:08 2009
From: burt at cs.miami.edu (Burt Rosenberg)
Date: Thu Sep  3 19:10:15 2009
Subject: kern/130628: [nfs] NFS / rpc.lockd deadlock on 7.1-R
Message-ID: <200909031910.n83JA8QA018090@freefall.freebsd.org>

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 spawk at acm.poly.edu  Thu Sep  3 21:51:46 2009
From: spawk at acm.poly.edu (Boris Kochergin)
Date: Thu Sep  3 21:51:52 2009
Subject: kmem_map too small panics with Soekris/Atheros access point
In-Reply-To: <4A8C3557.20002@acm.poly.edu>
References: <4A8C3557.20002@acm.poly.edu>
Message-ID: <4AA03A41.1080200@acm.poly.edu>

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 mel at rachie.is-a-geek.net  Fri Sep  4 09:57:16 2009
From: mel at rachie.is-a-geek.net (Mel Flynn)
Date: Fri Sep  4 09:57:30 2009
Subject: [panic] Kernel corruption of pppoe lists
Message-ID: <20090904093907.B61227E854@mailhub.rachie.is-a-geek.net>


>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 artis.caune at gmail.com  Fri Sep  4 13:01:12 2009
From: artis.caune at gmail.com (Artis Caune)
Date: Fri Sep  4 13:01:19 2009
Subject: em driver input errors
In-Reply-To: <11420.28890.qm@web56404.mail.re3.yahoo.com>
References: <11420.28890.qm@web56404.mail.re3.yahoo.com>
Message-ID: <9e20d71e0909040601s100688c2m7d7f73eb187f4809@mail.gmail.com>

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 times) much fewer errors on em1 and em2.? 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%.
>
> 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" gives 289115 currently).
>
> All of the em interfaces are just configured "up", with various vlan interfaces on them.? 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.? In bits, it's 30...120Mbits/s in, and 100...210Mbits/s out.? Vlans configured 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 of this).? em0 is the external interface, and its traffic corresponds to 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 (almost 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 seeing have started appearing days before netgraph was even loaded in the kernel.
>
> Tuning done:
>
> /boot/loader.conf:
> hw.em.rxd=4096
> hw.em.txd=4096
>
> Witout the above we were seeing way more errors, now they are reduced, but still come in bursts of over 1000 errors on em0.
>
> /etc/sysctl.conf:
> net.inet.ip.fastforwarding=1
> dev.em.0.rx_processing_limit=300
> dev.em.1.rx_processing_limit=300
> dev.em.2.rx_processing_limit=300
> dev.em.3.rx_processing_limit=300
>
> 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=0
> dev.em.0.rx_abs_int_delay=0
> dev.em.0.tx_int_delay=0
> dev.em.0.tx_abs_int_delay=0
>
> Still getting errors, so I also added:
>
> net.inet.ip.intr_queue_maxlen=4096
> net.route.netisr_maxqlen=1024
>
> and
>
> kern.ipc.nmbclusters=655360
>
>
> 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.? These spikes are spread throughout the day, with spaces (zones with no errors) of various lengths (10 minutes ... 2 hours spaces within the last 24 hours), but sometimes there are 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 and re1 network cards, and was only seeing errors on the em cards.? It was running 7.2-PRERELEASE/i386
>
>
> Any suggestions would be greatly appreciated.? Please note that this is a live router, and I can't reboot it (unless absolutely necessary).? 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).





-- 
Artis Caune

    Everything should be made as simple as possible, but not simpler.
From ady at freebsd.ady.ro  Fri Sep  4 14:11:24 2009
From: ady at freebsd.ady.ro (Adrian Penisoara)
Date: Fri Sep  4 14:11:30 2009
Subject: em driver input errors
In-Reply-To: <11420.28890.qm@web56404.mail.re3.yahoo.com>
References: <11420.28890.qm@web56404.mail.re3.yahoo.com>
Message-ID: <78cb3d3f0909040711i5702c4c7l4dbb89bb1fef259a@mail.gmail.com>

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 times) much fewer errors on em1 and em2.? 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 gigabyte.tmn at gmail.com  Fri Sep  4 15:59:24 2009
From: gigabyte.tmn at gmail.com (Dmitriy Zamuraev)
Date: Fri Sep  4 15:59:31 2009
Subject: [panic] Kernel corruption of pppoe lists
References: <20090904093907.B61227E854@mailhub.rachie.is-a-geek.net>
Message-ID: <001601ca2d78$aecc4af0$1e010a0a@in72.ru>

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 wjw at digiware.nl  Fri Sep  4 16:28:13 2009
From: wjw at digiware.nl (Willem Jan Withagen)
Date: Fri Sep  4 16:28:20 2009
Subject: UDP output performance
Message-ID: <4AA14018.3010102@digiware.nl>

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 manishv at lineratesystems.com  Fri Sep  4 17:23:10 2009
From: manishv at lineratesystems.com (Manish Vachharajani)
Date: Fri Sep  4 17:23:17 2009
Subject: UDP output performance
In-Reply-To: <4AA14018.3010102@digiware.nl>
References: <4AA14018.3010102@digiware.nl>
Message-ID: <5bc218350909041002x670460c8nf202a714182d1bf6@mail.gmail.com>

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=1 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 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 alexpalias-bsdnet at yahoo.com  Fri Sep  4 17:28:43 2009
From: alexpalias-bsdnet at yahoo.com (alexpalias-bsdnet@yahoo.com)
Date: Fri Sep  4 17:28:50 2009
Subject: em driver input errors
In-Reply-To: <9e20d71e0909040601s100688c2m7d7f73eb187f4809@mail.gmail.com>
Message-ID: <3413.68869.qm@web56406.mail.re3.yahoo.com>

--- 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 wjw at digiware.nl  Fri Sep  4 17:30:46 2009
From: wjw at digiware.nl (Willem Jan Withagen)
Date: Fri Sep  4 17:30:52 2009
Subject: UDP output performance
In-Reply-To: <5bc218350909041002x670460c8nf202a714182d1bf6@mail.gmail.com>
References: <4AA14018.3010102@digiware.nl>
	<5bc218350909041002x670460c8nf202a714182d1bf6@mail.gmail.com>
Message-ID: <4AA14EC1.6010402@digiware.nl>

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 manishv at lineratesystems.com  Fri Sep  4 17:41:17 2009
From: manishv at lineratesystems.com (Manish Vachharajani)
Date: Fri Sep  4 17:41:27 2009
Subject: em driver input errors
In-Reply-To: <3413.68869.qm@web56406.mail.re3.yahoo.com>
References: <9e20d71e0909040601s100688c2m7d7f73eb187f4809@mail.gmail.com>
	<3413.68869.qm@web56406.mail.re3.yahoo.com>
Message-ID: <5bc218350909041041x49ec9765k81346e90bbfe891a@mail.gmail.com>

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. ?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
>
> _______________________________________________
> 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 alexpalias-bsdnet at yahoo.com  Fri Sep  4 17:43:34 2009
From: alexpalias-bsdnet at yahoo.com (alexpalias-bsdnet@yahoo.com)
Date: Fri Sep  4 17:43:41 2009
Subject: em driver input errors
In-Reply-To: <78cb3d3f0909040711i5702c4c7l4dbb89bb1fef259a@mail.gmail.com>
Message-ID: <540877.57168.qm@web56401.mail.re3.yahoo.com>

--- 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 pyunyh at gmail.com  Fri Sep  4 21:23:26 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Fri Sep  4 21:23:33 2009
Subject: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link
In-Reply-To: <20090901161310.GA37481@traktor.dnepro.net>
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>
Message-ID: <20090904212223.GA9950@michelle.cdnetworks.com>

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 ccowart at rescomp.berkeley.edu  Fri Sep  4 22:48:04 2009
From: ccowart at rescomp.berkeley.edu (Chris Cowart)
Date: Fri Sep  4 22:48:11 2009
Subject: Crash in ether_input
Message-ID: <20090904223123.GD16213@hal.rescomp.berkeley.edu>

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. 

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.

From uname: 

| 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:
| 
| Fatal trap 27: stack fault while in kernel mode
| cpuid = 0; apic id = 00
| instruction pointer     = 0x8:0xffffffff80559fb4
| stack pointer           = 0x10:0xffffffffae39faf0
| frame pointer           = 0x10:0xf85ecc37f9239402
| code segment            = base 0x0, limit 0xfffff, type 0x1b
|                         = DPL 0, pres 1, long 1, def32 0, gran 1
| processor eflags        = interrupt enabled, resume, IOPL = 0
| current process         = 27 (em0 taskq)
| trap number             = 27
| panic: stack fault
| cpuid = 0
| Uptime: 43m44s
| Physical memory: 4082 MB
| Dumping 361 MB: 346 330 314 298 282 266 250 234 218 202em0: watchdog timeout -- resetting

| (kgdb) bt
| #0  doadump () at pcpu.h:195
| #1  0x0000000000000004 in ?? ()
| #2  0xffffffff804bd9b9 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418
| #3  0xffffffff804bddc2 in panic (fmt=0x104 <Address 0x104 out of bounds>) at /usr/src/sys/kern/kern_shutdown.c:574
| #4  0xffffffff807b9f23 in trap_fatal (frame=0xffffff00012d66e0, eva=Variable "eva" is not available.
| ) at /usr/src/sys/amd64/amd64/trap.c:764
| #5  0xffffffff807baa75 in trap (frame=0xffffffffae39fa40) at /usr/src/sys/amd64/amd64/trap.c:565
| #6  0xffffffff807a042e in calltrap () at /usr/src/sys/amd64/amd64/exception.S:209
| #7  0xffffffff80559fb4 in ether_input (ifp=0xffffff00012bf000, m=0xffffff0003576000) at /usr/src/sys/net/if_ethersubr.c:545
| #8  0xffffffff802bd645 in em_rxeof (adapter=0xffffffff80e4c000, count=99) at /usr/src/sys/dev/e1000/if_em.c:4539
| #9  0xffffffff802be55e in em_handle_rxtx (context=Variable "context" is not available.
| ) at /usr/src/sys/dev/e1000/if_em.c:1702
| #10 0xffffffff804f2afd in taskqueue_run (queue=0xffffff00012c8c80) at /usr/src/sys/kern/subr_taskqueue.c:282
| #11 0xffffffff804f2da6 in taskqueue_thread_loop (arg=Variable "arg" is not available.
| ) at /usr/src/sys/kern/subr_taskqueue.c:401
| #12 0xffffffff8049b2f3 in fork_exit (callout=0xffffffff804f2d40 <taskqueue_thread_loop>, arg=0xffffffff80e50588, frame=0xffffffffae39fc80) 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=0xffffff00012bf000, m=0xffffff0003576000) at /usr/src/sys/net/if_ethersubr.c:545
| 545             eh = mtod(m, struct ether_header *);
| (kgdb) info locals
| eh = (struct ether_header *) 0xf85ecc37f9239402
| (kgdb) info args
| ifp = (struct ifnet *) 0xffffff00012bf000
| m = (struct mbuf *) 0xffffff0003576000
| (kgdb) mbuf m
| 0xffffff0003576000: 125 bytes ext 0xaf29dcb45d53e701 packet: 125 bytes received via em0
| 0xbb763383e10eda22Cannot access memory at address 0xbb763383e10eda3a
| (kgdb) 

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. 

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,

-- 
Chris Cowart
Network Technical Lead
Network & Infrastructure Services, RSSP-IT
UC Berkeley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090904/aca6751c/attachment.pgp
From tejblum at yandex-team.ru  Sat Sep  5 18:00:37 2009
From: tejblum at yandex-team.ru (Dmitrij Tejblum)
Date: Sat Sep  5 18:00:44 2009
Subject: Dropped vs. missed packets in the ixgbe driver
In-Reply-To: <2a41acea0908201721o33372c89q25e33b8cde8edf06@mail.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>
Message-ID: <4AA2A3B5.3000108@yandex-team.ru>

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 jfvogel at gmail.com  Sat Sep  5 18:10:42 2009
From: jfvogel at gmail.com (Jack Vogel)
Date: Sat Sep  5 18:10:49 2009
Subject: Dropped vs. missed packets in the ixgbe driver
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>
Message-ID: <2a41acea0909051110v755f66cbkfc4d2f84b3d8a353@mail.gmail.com>

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 stef-list at memberwebs.com  Sat Sep  5 21:03:44 2009
From: stef-list at memberwebs.com (Stef Walter)
Date: Sat Sep  5 21:03:50 2009
Subject: Panic in imo_match_source (netinet/in_mcast.c)
Message-ID: <mailman.6.1252184630.1066.freebsd-net@freebsd.org>

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

From stef-list at memberwebs.com  Sun Sep  6 00:48:43 2009
From: stef-list at memberwebs.com (Stef Walter)
Date: Sun Sep  6 00:48:50 2009
Subject: kmem_map too small panics with Soekris/Atheros access point
References: <4A8C3557.20002@acm.poly.edu> <4AA03A41.1080200@acm.poly.edu>
Message-ID: <mailman.7.1252198130.1066.freebsd-net@freebsd.org>

Boris Kochergin wrote:
>> _______________________________________________
>> 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.

This might be a long shot:

Back when I deployed some similar devices on FreeBSD 6.0 there was a
leak when using oddball ath_rate driver. I believe it went away when I
used ath_rate_sample. But according to 'man 4 ath' nothing else besides
ath_rate_sample exists anymore.

Cheers,

Stef

From melifaro at ipfw.ru  Sun Sep  6 20:06:25 2009
From: melifaro at ipfw.ru (Alexander V. Chernikov)
Date: Sun Sep  6 20:07:28 2009
Subject: Call for testers: ng_netflow with v9 and IPv6 support
Message-ID: <4AA41192.6080708@ipfw.ru>

Hi!

There are patches for 7.2R and . to make ng_netflow export IPv4/IPv6 
flows via V9 protocol (RFC3954). Your feedback is welcome.
Alternative links:
http://static.ipfw.ru/patches/netflow_v9_20090906_72.diff
http://static.ipfw.ru/patches/netflow_v9_20090906_curr.diff

node runtime control messages:
Set export version:
setversion { version=X }. X=[59], defaults to  9
Set export interface mtu
setmtu { mtu=X }. X has to be <= MHLEN at the moment, defaults to 1500
Set v9 template announce conditions
settemplateperiodic { time=X packets=Y }. Send templates every X seconds 
or Y packets, X=600, Y=500 by default


-------------- next part --------------
diff -urN sys/netgraph/_netflow.orig/netflow.c sys/netgraph/netflow/netflow.c
--- sys/netgraph/_netflow.orig/netflow.c	2009-09-01 02:37:44.000000000 +0400
+++ sys/netgraph/netflow/netflow.c	2009-09-06 17:04:28.000000000 +0400
@@ -30,6 +30,8 @@
 static const char rcs_id[] =
     "@(#) $FreeBSD: src/sys/netgraph/netflow/netflow.c,v 1.33 2008/12/15 06:10:57 qingli Exp $";
 
+#include "opt_inet6.h"
+
 #include <sys/param.h>
 #include <sys/kernel.h>
 #include <sys/limits.h>
@@ -37,14 +39,18 @@
 #include <sys/syslog.h>
 #include <sys/systm.h>
 #include <sys/socket.h>
+#include <sys/endian.h>
 
 #include <machine/atomic.h>
+#include <machine/stdarg.h>
 
 #include <net/if.h>
 #include <net/route.h>
+#include <net/ethernet.h>
 #include <netinet/in.h>
 #include <netinet/in_systm.h>
 #include <netinet/ip.h>
+#include <netinet/ip6.h>
 #include <netinet/tcp.h>
 #include <netinet/udp.h>
 
@@ -94,12 +100,99 @@
 			 ((t) << 6) +	/* 64  */	\
 			 ((t) << 5) +	/* 32  */	\
 			 ((t) << 3))	/* 8   */
+/*
+ * Defines for different neflow version dispatchers
+ *
+ */
+static int export_add(item_p, struct flow_entry *);
+static int export_add_v9(item_p, struct flow_entry *);
+static int export_send(priv_p, item_p, int flags);
+static int export_send_v9(priv_p, item_p, int flags);
+
+typedef int (*record_add_ptr)(item_p, struct flow_entry *);
+typedef int (*record_send_ptr)(priv_p, item_p, int);
+struct _netflow_dispatchers {
+	record_add_ptr	record_add;
+	record_send_ptr	record_send;
+};
+
+static struct _netflow_dispatchers netflow_dispatcher[] =
+{
+	{ NULL, NULL },
+	{ NULL, NULL },
+	{ NULL, NULL },
+	{ NULL, NULL },
+	{ NULL, NULL },
+	{ export_add, export_send }, /* Version 5 */
+	{ NULL, NULL },
+	{ NULL, NULL },
+	{ NULL, NULL },
+	{ export_add_v9, export_send_v9 }, /* Version 9 */
+	{ NULL, NULL }
+};
+
+record_add_ptr record_add = NULL;
+record_send_ptr record_send = NULL;
 
 MALLOC_DECLARE(M_NETFLOW_HASH);
 MALLOC_DEFINE(M_NETFLOW_HASH, "netflow_hash", "NetFlow hash");
 
-static int export_add(item_p, struct flow_entry *);
-static int export_send(priv_p, item_p, int flags);
+
+static struct netflow_v9_template _netflow_v9_record_ipv4_tcp[] = 
+{
+	{ NETFLOW_V9_FIELD_IPV4_SRC_ADDR, 4},
+	{ NETFLOW_V9_FIELD_IPV4_DST_ADDR, 4},
+	{ NETFLOW_V9_FIELD_IPV4_NEXT_HOP, 4},
+	{ NETFLOW_V9_FIELD_INPUT_SNMP, 2},
+	{ NETFLOW_V9_FIELD_OUTPUT_SNMP, 2},
+	{ NETFLOW_V9_FIELD_IN_PKTS, sizeof(cntr)},
+	{ NETFLOW_V9_FIELD_IN_BYTES, sizeof(cntr)},
+	{ NETFLOW_V9_FIELD_OUT_PKTS, sizeof(cntr)},
+	{ NETFLOW_V9_FIELD_OUT_BYTES, sizeof(cntr)},
+	{ NETFLOW_V9_FIELD_FIRST_SWITCHED, 4},
+	{ NETFLOW_V9_FIELD_LAST_SWITCHED, 4},
+	{ NETFLOW_V9_FIELD_L4_SRC_PORT, 2},
+	{ NETFLOW_V9_FIELD_L4_DST_PORT, 2},
+	{ NETFLOW_V9_FIELD_TCP_FLAGS, 1},
+	{ NETFLOW_V9_FIELD_PROTOCOL, 1},
+	{ NETFLOW_V9_FIELD_TOS, 1},
+	{ NETFLOW_V9_FIELD_SRC_AS, 4},
+	{ NETFLOW_V9_FIELD_DST_AS, 4},
+	{ NETFLOW_V9_FIELD_SRC_MASK, 1},
+	{ NETFLOW_V9_FIELD_DST_MASK, 1},
+	{0, 0}
+};
+
+static struct netflow_v9_template _netflow_v9_record_ipv6_tcp[] = 
+{
+	{ NETFLOW_V9_FIELD_IPV6_SRC_ADDR, 16},
+	{ NETFLOW_V9_FIELD_IPV6_DST_ADDR, 16},
+	{ NETFLOW_V9_FIELD_IPV6_NEXT_HOP, 16},
+	{ NETFLOW_V9_FIELD_INPUT_SNMP, 2},
+	{ NETFLOW_V9_FIELD_OUTPUT_SNMP, 2},
+	{ NETFLOW_V9_FIELD_IN_PKTS, sizeof(cntr)},
+	{ NETFLOW_V9_FIELD_IN_BYTES, sizeof(cntr)},
+	{ NETFLOW_V9_FIELD_OUT_PKTS, sizeof(cntr)},
+	{ NETFLOW_V9_FIELD_OUT_BYTES, sizeof(cntr)},
+	{ NETFLOW_V9_FIELD_FIRST_SWITCHED, 4},
+	{ NETFLOW_V9_FIELD_LAST_SWITCHED, 4},
+	{ NETFLOW_V9_FIELD_L4_SRC_PORT, 2},
+	{ NETFLOW_V9_FIELD_L4_DST_PORT, 2},
+	{ NETFLOW_V9_FIELD_TCP_FLAGS, 1},
+	{ NETFLOW_V9_FIELD_PROTOCOL, 1},
+	{ NETFLOW_V9_FIELD_TOS, 1},
+	{ NETFLOW_V9_FIELD_SRC_AS, 4},
+	{ NETFLOW_V9_FIELD_DST_AS, 4},
+	{ NETFLOW_V9_FIELD_SRC_MASK, 1},
+	{ NETFLOW_V9_FIELD_DST_MASK, 1},
+	{0, 0}
+};
+
+
+static int generate_v9_templates(priv_p priv);
+
+MALLOC_DECLARE(M_NETFLOW_GENERAL);
+MALLOC_DEFINE(M_NETFLOW_GENERAL, "netflog_general", "plog, templates data");
 
 /* Generate hash for a given flow record. */
 static __inline uint32_t
@@ -108,10 +201,24 @@
 	switch (r->r_ip_p) {
 	case IPPROTO_TCP:
 	case IPPROTO_UDP:
-		return FULL_HASH(r->r_src.s_addr, r->r_dst.s_addr,
+		return FULL_HASH(r->src.r_src.s_addr, r->dst.r_dst.s_addr,
 		    r->r_sport, r->r_dport);
 	default:
-		return ADDR_HASH(r->r_src.s_addr, r->r_dst.s_addr);
+		return ADDR_HASH(r->src.r_src.s_addr, r->dst.r_dst.s_addr);
+	}
+}
+
+/* Generate hash for a given flow record. Use lower 4 octets from v6 addresses */
+static __inline uint32_t
+ip6_hash(struct flow_rec *r)
+{
+	switch (r->r_ip_p) {
+	case IPPROTO_TCP:
+	case IPPROTO_UDP:
+		return FULL_HASH(r->src.r_src6.__u6_addr.__u6_addr32[3], r->dst.r_dst6.__u6_addr.__u6_addr32[3],
+		    r->r_sport, r->r_dport);
+	default:
+		return ADDR_HASH(r->src.r_src6.__u6_addr.__u6_addr32[3], r->dst.r_dst6.__u6_addr.__u6_addr32[3]);
 	}
 }
 
@@ -126,6 +233,7 @@
 
 	atomic_add_32(&priv->info.nfinfo_used, 1);
 
+
 	return (0);
 }
 
@@ -141,6 +249,7 @@
 /*
  * Detach export datagram from priv, if there is any.
  * If there is no, allocate a new one.
+ * -- V9/IPv6 ready
  */
 static item_p
 get_export_dgram(priv_p priv)
@@ -166,14 +275,163 @@
 			return (NULL);
 		dgram = mtod(m, struct netflow_v5_export_dgram *);
 		dgram->header.count = 0;
-		dgram->header.version = htons(NETFLOW_V5);
+		dgram->header.version = htons(priv->version);
+
+		if (priv->version == NETFLOW_V9) {
+			atomic_fetchadd_32(&priv->sent_packets, 1);
+
+			/*
+			 * Let's insert mbuf tag to store some info
+			 */
+			struct netflow_v9_mbuf_tag *t;
+			struct m_tag *mt = m_tag_alloc(MTAG_NETFLOW, MTAG_NETFLOW_V9, sizeof(struct netflow_v9_mbuf_tag), M_NOWAIT);
+			if (mt == NULL) {
+				m_freem(m);
+				return (NULL);
+			}
+
+			m_tag_init(m);
+			m_tag_prepend(m, mt);
 
+			t = (struct netflow_v9_mbuf_tag *)(mt + 1);
+			t->length = sizeof(struct netflow_v9_header);
+			t->count = 0;
+			t->mtu = priv->mtu;
+			t->flow_header = t->length;
+
+			/*
+			 * Check if we need to insert templates into packet
+			 */
+			
+			struct timespec ts;
+			struct netflow_v9_flowset_header	*fl;
+
+			getnanotime(&ts);
+			if ((ts.tv_sec >= priv->templ_time + priv->templ_last_ts) || (priv->sent_packets >= priv->templ_packets + priv->templ_last_pkt)) {
+				//vlog("INSERTING TEMPLATE: ts: %lu last: %u packets: %u last: %u delay: %u", ts.tv_sec, priv->templ_last_ts, priv->sent_packets, priv->templ_last_pkt, priv->templ_time);
+				atomic_store_rel_32(&priv->templ_last_ts, ts.tv_sec);
+				atomic_store_rel_32(&priv->templ_last_pkt, priv->sent_packets);
+				//vlog("ts: %lu last_t: %u last_p: %u delay: %u", ts.tv_sec, priv->templ_last_ts, priv->templ_last_pkt, priv->templ_time);
+
+				fl = priv->v9_flowsets[0];
+				bcopy(fl, (char *)dgram + t->length, ntohs(fl->length));
+
+				t->length += ntohs(fl->length);
+				t->flow_header = t->length;
+				t->count += priv->flowset_records[0];
+			}
+		
+		}
 	}
 
 	return (item);
 }
 
 /*
+ * Pre-compiles flow exporter for all possible FlowSets
+ * so we can add flowset to packet via simple memcpy()
+ */
+#define __push(x)	*p++ = htons((x))
+static int
+generate_v9_templates(priv_p priv)
+{
+	uint16_t *p, *template_fields_cnt;
+	int cnt;
+
+	int flowset_size = sizeof(struct netflow_v9_flowset_header) +
+		_NETFLOW_V9_TEMPLATE_SIZE(_netflow_v9_record_ipv4_tcp) + /* netflow_v9_record_ipv4_tcp */
+		_NETFLOW_V9_TEMPLATE_SIZE(_netflow_v9_record_ipv6_tcp); /* netflow_v9_record_ipv6_tcp */
+
+	priv->v9_flowsets[0] = malloc(flowset_size, M_NETFLOW_GENERAL, M_WAITOK | M_ZERO);
+	if (priv->v9_flowsets[0] == NULL)
+		return (ENOMEM);
+
+
+	if (flowset_size % 4)
+		flowset_size += 4 - (flowset_size % 4); /* Padding to 4-byte boundary */
+
+	priv->flowsets_count = 1;
+	p = (uint16_t *)priv->v9_flowsets[0];
+	*p++ = 0; /* Flowset ID, 0 is reserved for Template FlowSets  */
+	*p++ = htons(flowset_size); /* Total FlowSet length */
+
+	/*
+	 * Most common TCP/UDP IPv4 template, ID = 256
+	 */
+	*p++ = htons(0x100 + NETFLOW_V9_FLOW_V4_L4);
+	template_fields_cnt = p++;
+	for (cnt = 0; _netflow_v9_record_ipv4_tcp[cnt].field_id != 0; cnt++) {
+		*p++ = htons(_netflow_v9_record_ipv4_tcp[cnt].field_id);
+		*p++ = htons(_netflow_v9_record_ipv4_tcp[cnt].field_length);
+	}
+	*template_fields_cnt = htons(cnt);
+
+	/*
+	 * TCP/UDP IPv6 template, ID = 257
+	 */
+	*p++ = htons(0x100 + NETFLOW_V9_FLOW_V6_L4);
+	template_fields_cnt = p++;
+	for (cnt = 0; _netflow_v9_record_ipv6_tcp[cnt].field_id != 0; cnt++) {
+		*p++ = htons(_netflow_v9_record_ipv6_tcp[cnt].field_id);
+		*p++ = htons(_netflow_v9_record_ipv6_tcp[cnt].field_length);
+	}
+	*template_fields_cnt = htons(cnt);
+
+
+	priv->flowset_records[0] = 2;
+	return (0);
+}
+
+/*
+ * Switches version used for netflow export
+ *
+ */
+void 
+ng_netflow_switch_version(priv_p priv, int ver, int boot)
+{
+	item_p	item = NULL;
+
+	if ((ver != NETFLOW_V9) && (ver != NETFLOW_V5))
+		return;
+
+	if ((ver == priv->version) && (boot == 0))
+		return;
+
+	/*
+	 * All new threads acquiring export datagram will wait for lock
+	 * so we can change pointers.
+	 * Existing threads with export datagram already held will call
+	 * wrong export function which will do version check at the beginning
+	 */
+
+	mtx_lock(&priv->export_mtx);
+	/* XXX: Need to be machine-independent here */
+	record_add = netflow_dispatcher[ver].record_add;
+	record_send = netflow_dispatcher[ver].record_send;
+	//atomic_store_rel_ptr((unsigned long *)record_add, (unsigned long)netflow_dispatcher[ver].record_add);
+	//atomic_store_rel_ptr((unsigned long *)record_send, (unsigned long)netflow_dispatcher[ver].record_send);
+	item = priv->export_item;
+	priv->export_item = NULL;
+	mtx_unlock(&priv->export_mtx);
+
+	if (ver == NETFLOW_V9) {
+		priv->templ_last_pkt = 0;
+		priv->templ_last_ts = 0;
+	}
+
+	//vlog("NEW: add=%p send=%p", record_add, record_send);
+
+	if (item != NULL)
+		(*netflow_dispatcher[priv->version].record_send)(priv, item, NG_NOFLAGS);
+	
+	if (boot)
+		log(LOG_DEBUG, "ng_netflow: v%d export started\n", ver);
+	else
+		log(LOG_DEBUG, "ng_netflow: export switched: v%d -> v%d\n", priv->version, ver);
+	priv->version = ver;
+}
+
+/*
  * Re-attach incomplete datagram back to priv.
  * If there is already another one, then send incomplete. */
 static void
@@ -190,13 +448,14 @@
 		mtx_unlock(&priv->export_mtx);
 	} else {
 		mtx_unlock(&priv->export_mtx);
-		export_send(priv, item, flags);
+		(*record_send)(priv, item, flags);
 	}
 }
 
 /*
  * The flow is over. Call export_add() and free it. If datagram is
  * full, then call export_send().
+ * -- v9/IPv6 nearly ready
  */
 static __inline void
 expire_flow(priv_p priv, item_p *item, struct flow_entry *fle, int flags)
@@ -208,8 +467,8 @@
 		uma_zfree_arg(priv->zone, fle, priv);
 		return;
 	}
-	if (export_add(*item, fle) > 0) {
-		export_send(priv, *item, flags);
+	if ((*record_add)(*item, fle) > 0) {
+		(*record_send)(priv, *item, flags);
 		*item = NULL;
 	}
 	uma_zfree_arg(priv->zone, fle, priv);
@@ -234,11 +493,14 @@
  * to be sure.
  */
 static __inline int
-hash_insert(priv_p priv, struct flow_hash_entry  *hsh, struct flow_rec *r,
+hash_insert(priv_p priv, struct flow_hash_entry  *hsh, struct flow_rec *r, uint16_t eproto,
 	int plen, uint8_t tcp_flags)
 {
 	struct flow_entry *fle;
 	struct sockaddr_in sin;
+#ifdef INET6
+	struct sockaddr_in6 sin6;
+#endif
 	struct rtentry *rt;
 
 	mtx_assert(&hsh->mtx, MA_OWNED);
@@ -257,6 +519,7 @@
 	bcopy(r, &fle->f.r, sizeof(struct flow_rec));
 	fle->f.bytes = plen;
 	fle->f.packets = 1;
+	fle->f.proto = eproto;
 	fle->f.tcp_flags = tcp_flags;
 
 	fle->f.first = fle->f.last = time_uptime;
@@ -265,46 +528,94 @@
 	 * First we do route table lookup on destination address. So we can
 	 * fill in out_ifx, dst_mask, nexthop, and dst_as in future releases.
 	 */
-	bzero(&sin, sizeof(sin));
-	sin.sin_len = sizeof(struct sockaddr_in);
-	sin.sin_family = AF_INET;
-	sin.sin_addr = fle->f.r.r_dst;
-	/* XXX MRT 0 as a default.. need the m here to get fib */
-	rt = rtalloc1_fib((struct sockaddr *)&sin, 0, 0, 0);
-	if (rt != NULL) {
-		fle->f.fle_o_ifx = rt->rt_ifp->if_index;
-
-		if (rt->rt_flags & RTF_GATEWAY &&
-		    rt->rt_gateway->sa_family == AF_INET)
-			fle->f.next_hop =
-			    ((struct sockaddr_in *)(rt->rt_gateway))->sin_addr;
-
-		if (rt_mask(rt))
-			fle->f.dst_mask = bitcount32(((struct sockaddr_in *)
-			    rt_mask(rt))->sin_addr.s_addr);
-		else if (rt->rt_flags & RTF_HOST)
-			/* Give up. We can't determine mask :( */
-			fle->f.dst_mask = 32;
-
-		RTFREE_LOCKED(rt);
-	}
-
-	/* Do route lookup on source address, to fill in src_mask. */
-	bzero(&sin, sizeof(sin));
-	sin.sin_len = sizeof(struct sockaddr_in);
-	sin.sin_family = AF_INET;
-	sin.sin_addr = fle->f.r.r_src;
-	/* XXX MRT 0 as a default  revisit.  need the mbuf for fib*/
-	rt = rtalloc1_fib((struct sockaddr *)&sin, 0, 0, 0);
-	if (rt != NULL) {
-		if (rt_mask(rt))
-			fle->f.src_mask = bitcount32(((struct sockaddr_in *)
-			    rt_mask(rt))->sin_addr.s_addr);
-		else if (rt->rt_flags & RTF_HOST)
-			/* Give up. We can't determine mask :( */
-			fle->f.src_mask = 32;
+	if (eproto == ETHERTYPE_IP) {
+		bzero(&sin, sizeof(sin));
+		sin.sin_len = sizeof(struct sockaddr_in);
+		sin.sin_family = AF_INET;
+		sin.sin_addr = fle->f.r.dst.r_dst;
+		/* XXX MRT 0 as a default.. need the m here to get fib */
+		rt = rtalloc1_fib((struct sockaddr *)&sin, 0, 0, 0);
+		if (rt != NULL) {
+			fle->f.fle_o_ifx = rt->rt_ifp->if_index;
+	
+			if (rt->rt_flags & RTF_GATEWAY &&
+			    rt->rt_gateway->sa_family == AF_INET)
+				fle->f.n.next_hop =
+				    ((struct sockaddr_in *)(rt->rt_gateway))->sin_addr;
+	
+			if (rt_mask(rt))
+				fle->f.dst_mask = bitcount32(((struct sockaddr_in *)
+				    rt_mask(rt))->sin_addr.s_addr);
+			else if (rt->rt_flags & RTF_HOST)
+				/* Give up. We can't determine mask :( */
+				fle->f.dst_mask = 32;
+	
+			RTFREE_LOCKED(rt);
+		}
+	
+		/* Do route lookup on source address, to fill in src_mask. */
+		bzero(&sin, sizeof(sin));
+		sin.sin_len = sizeof(struct sockaddr_in);
+		sin.sin_family = AF_INET;
+		sin.sin_addr = fle->f.r.src.r_src;
+		/* XXX MRT 0 as a default  revisit.  need the mbuf for fib*/
+		rt = rtalloc1_fib((struct sockaddr *)&sin, 0, 0, 0);
+		if (rt != NULL) {
+			if (rt_mask(rt))
+				fle->f.src_mask = bitcount32(((struct sockaddr_in *)
+				    rt_mask(rt))->sin_addr.s_addr);
+			else if (rt->rt_flags & RTF_HOST)
+				/* Give up. We can't determine mask :( */
+				fle->f.src_mask = 32;
+	
+			RTFREE_LOCKED(rt);
+		}
+	} else {
+#ifdef INET6		
+		bzero(&sin6, sizeof(sin6));
+		sin6.sin6_len = sizeof(struct sockaddr_in6);
+		sin6.sin6_family = AF_INET6;
+		sin6.sin6_addr = fle->f.r.dst.r_dst6;
+		/* XXX fib works for AF_INET only */
+		rt = rtalloc1_fib((struct sockaddr *)&sin6, 0, 0, 0);
+		if (rt != NULL) {
+			fle->f.fle_o_ifx = rt->rt_ifp->if_index;
+	
+			if (rt->rt_flags & RTF_GATEWAY &&
+			    rt->rt_gateway->sa_family == AF_INET6)
+				fle->f.n.next_hop6 =
+				    ((struct sockaddr_in6 *)(rt->rt_gateway))->sin6_addr;
+			if (rt_mask(rt))
+/*	
+				fle->f.dst_mask = bitcount32(((struct sockaddr_in6 *)
+				    rt_mask(rt))->sin_addr.s_addr);
+			else if (rt->rt_flags & RTF_HOST) */
+				/* Give up. We can't determine mask :( */
+				fle->f.dst_mask = 128;
+	
+			RTFREE_LOCKED(rt);
+		}
+	
+		/* Do route lookup on source address, to fill in src_mask. */
+		bzero(&sin6, sizeof(sin6));
+		sin6.sin6_len = sizeof(struct sockaddr_in6);
+		sin6.sin6_family = AF_INET6;
+		sin6.sin6_addr = fle->f.r.src.r_src6;
+		/* XXX MRT 0 as a default  revisit.  need the mbuf for fib*/
+		rt = rtalloc1_fib((struct sockaddr *)&sin6, 0, 0, 0);
+		if (rt != NULL) {
+/*			
+			if (rt_mask(rt))
+				fle->f.src_mask = bitcount32(((struct sockaddr_in6 *)
+				    rt_mask(rt))->sin_addr.s_addr);
+			else if (rt->rt_flags & RTF_HOST) */
+				/* Give up. We can't determine mask :( */
+				fle->f.src_mask = 128;
+	
+			RTFREE_LOCKED(rt);
+		}
 
-		RTFREE_LOCKED(rt);
+#endif
 	}
 
 	/* Push new flow at the and of hash. */
@@ -347,6 +658,10 @@
 
 	mtx_init(&priv->export_mtx, "export dgram lock", NULL, MTX_DEF);
 
+	generate_v9_templates(priv);
+
+	ng_netflow_switch_version(priv, priv->version, 1);
+
 	return (0);
 }
 
@@ -359,6 +674,7 @@
 	item_p			item = NULL;
 	int i;
 
+
 	/*
 	 * We are going to free probably billable data.
 	 * Expire everything before freeing it.
@@ -371,7 +687,7 @@
 		}
 
 	if (item != NULL)
-		export_send(priv, item, NG_QUEUE);
+		(*record_send)(priv, item, NG_QUEUE);
 
 	uma_zdestroy(priv->zone);
 
@@ -383,46 +699,34 @@
 	if (priv->hash)
 		free(priv->hash, M_NETFLOW_HASH);
 
+	/* FreeFlow Tables */
+	for (i = 0; i < priv->flowsets_count; i++)
+		free(priv->v9_flowsets[i], M_NETFLOW_GENERAL);
+
 	mtx_destroy(&priv->export_mtx);
 }
 
-/* Insert packet from into flow cache. */
+/* 
+ * Insert packet from into flow cache. Assume size/version check passed
+ */
 int
-ng_netflow_flow_add(priv_p priv, struct ip *ip, unsigned int src_if_index)
+ng_netflow_flow_add(priv_p priv, caddr_t ip_ptr, caddr_t upper_ptr, uint8_t upper_proto, uint8_t is_frag, unsigned int src_if_index)
 {
 	register struct flow_entry	*fle, *fle1;
 	struct flow_hash_entry		*hsh;
 	struct flow_rec		r;
+	struct ip		*ip = NULL;
+#ifdef INET6
+	struct ip6_hdr		*ip6 = NULL;
+#endif
 	item_p			item = NULL;
-	int			hlen, plen;
+	int			plen;
 	int			error = 0;
 	uint8_t			tcp_flags = 0;
-
-	/* Try to fill flow_rec r */
-	bzero(&r, sizeof(r));
-	/* check version */
-	if (ip->ip_v != IPVERSION)
-		return (EINVAL);
-
-	/* verify min header length */
-	hlen = ip->ip_hl << 2;
-
-	if (hlen < sizeof(struct ip))
-		return (EINVAL);
-
-	r.r_src = ip->ip_src;
-	r.r_dst = ip->ip_dst;
-
-	/* save packet length */
-	plen = ntohs(ip->ip_len);
-
-	r.r_ip_p = ip->ip_p;
-	r.r_tos = ip->ip_tos;
-
-	r.r_i_ifx = src_if_index;
+	uint16_t		eproto;
 
 	/*
-	 * XXX NOTE: only first fragment of fragmented TCP, UDP and
+	 * XXX Fragmentation NOTE: only first fragment of fragmented TCP, UDP and
 	 * ICMP packet will be recorded with proper s_port and d_port.
 	 * Following fragments will be recorded simply as IP packet with
 	 * ip_proto = ip->ip_p and s_port, d_port set to zero.
@@ -430,22 +734,91 @@
 	 * ip packet assebmling here. Anyway, (in)famous trafd works this way -
 	 * and nobody complains yet :)
 	 */
-	if ((ip->ip_off & htons(IP_OFFMASK)) == 0)
-		switch(r.r_ip_p) {
-		case IPPROTO_TCP:
-		{
-			register struct tcphdr *tcp;
-
-			tcp = (struct tcphdr *)((caddr_t )ip + hlen);
-			r.r_sport = tcp->th_sport;
-			r.r_dport = tcp->th_dport;
-			tcp_flags = tcp->th_flags;
-			break;
+
+	/* Try to fill flow_rec r */
+	bzero(&r, sizeof(r));
+	ip = (struct ip *)ip_ptr;
+	if (ip->ip_v == IPVERSION) {
+		eproto = ETHERTYPE_IP;
+		r.src.r_src = ip->ip_src;
+		r.dst.r_dst = ip->ip_dst;
+
+		/* Assume L$ template by default */
+		r.flow_type = NETFLOW_V9_FLOW_V4_L4;
+
+		/* save packet length */
+		plen = ntohs(ip->ip_len);
+
+		r.r_tos = ip->ip_tos;
+
+		if (is_frag == 0) {
+			switch(upper_proto) {
+			case IPPROTO_TCP:
+			{
+				register struct tcphdr *tcp;
+
+				tcp = (struct tcphdr *)upper_ptr;
+				r.r_ports = *(uint32_t *)upper_ptr;
+				tcp_flags = tcp->th_flags;
+				/* r.flow_type = NETFLOW_V9_FLOW_V4_L4; */
+				break;
+			}
+			case IPPROTO_UDP:
+			case IPPROTO_SCTP:
+			{
+				r.r_ports = *(uint32_t *)upper_ptr;
+				/* r.flow_type = NETFLOW_V9_FLOW_V4_L4; */
+				break;
+			}
+
+			}
 		}
+
+	} else {
+#ifdef INET6		
+		/* IPv6 traffic */
+		ip = NULL;
+		ip6 = (struct ip6_hdr *)ip_ptr;
+		eproto = ETHERTYPE_IPV6;
+
+		r.src.r_src6 = ip6->ip6_src;
+		r.dst.r_dst6 = ip6->ip6_dst;
+
+		/* Assume L4 template by default */
+		r.flow_type = NETFLOW_V9_FLOW_V6_L4;
+
+		/* save packet length */
+		plen = ntohs(ip6->ip6_plen) + sizeof(struct ip6_hdr);
+
+		//r.r_tos = ip->ip_tos;
+
+		if (is_frag == 0) {
+			switch(upper_proto) {
+			case IPPROTO_TCP:
+			{
+				register struct tcphdr *tcp;
+
+				tcp = (struct tcphdr *)upper_ptr;
+				r.r_ports = *(uint32_t *)upper_ptr;
+				tcp_flags = tcp->th_flags;
+				/* r.flow_type = NETFLOW_V9_FLOW_V6_L4; */
+				break;
+			}
 			case IPPROTO_UDP:
-			r.r_ports = *(uint32_t *)((caddr_t )ip + hlen);
-			break;
+			case IPPROTO_SCTP:
+			{
+				r.r_ports = *(uint32_t *)upper_ptr;
+				/* r.flow_type = NETFLOW_V9_FLOW_V6_L4; */
+				break;
+			}
+
+			}
 		}
+#endif		
+	}
+
+	r.r_ip_p = upper_proto;
+	r.r_i_ifx = src_if_index;
 
 	/* Update node statistics. XXX: race... */
 	priv->info.nfinfo_packets ++;
@@ -486,7 +859,7 @@
 		 * - it is going to overflow counter
 		 */
 		if (tcp_flags & TH_FIN || tcp_flags & TH_RST || AGED(fle) ||
-		    (fle->f.bytes >= (UINT_MAX - IF_MAXMTU)) ) {
+		    (fle->f.bytes >= (cntr_max - IF_MAXMTU)) ) {
 			TAILQ_REMOVE(&hsh->head, fle, fle_hash);
 			expire_flow(priv, &item, fle, NG_QUEUE);
 			atomic_add_32(&priv->info.nfinfo_act_exp, 1);
@@ -502,7 +875,7 @@
 			}
 		}
 	} else				/* A new flow entry. */
-		error = hash_insert(priv, hsh, &r, plen, tcp_flags);
+		error = hash_insert(priv, hsh, &r, eproto, plen, tcp_flags);
 
 	mtx_unlock(&hsh->mtx);
 
@@ -611,6 +984,65 @@
 	return (error);
 }
 
+/* We have full datagram in privdata. Send it to export hook. */
+static int
+export_send_v9(priv_p priv, item_p item, int flags)
+{
+	struct mbuf *m = NGI_M(item);
+	struct netflow_v9_export_dgram *dgram = mtod(m,
+					struct netflow_v9_export_dgram *);
+	struct netflow_v9_header *header = &dgram->header;
+	struct timespec ts;
+	int error = 0;
+	uint16_t len = 0;
+
+	struct netflow_v9_mbuf_tag *t;
+	struct netflow_v9_flowset_header *fs = NULL;
+	struct m_tag *mt = m_tag_locate(m, MTAG_NETFLOW, MTAG_NETFLOW_V9, NULL);
+
+	if (mt == NULL) {
+		/* */
+		log(LOG_DEBUG, "ng_netflow: V9 export packet without tag!\n");
+		return (0);
+	}
+
+	t = (struct netflow_v9_mbuf_tag *)(mt + 1);
+
+	/* Close FlowSet if not closed */
+	if (t->length != t->flow_header) {
+		fs = (struct netflow_v9_flowset_header *)(mtod(m, char *) + t->flow_header);
+		len = (uint16_t)(t->length - t->flow_header);
+		if (len % 4) {
+			t->length += 4 - (len % 4);
+			len += 4 - (len % 4);
+		}
+		fs->length = htons(len);
+	}
+
+
+
+	/* Fill mbuf header. */
+	m->m_len = m->m_pkthdr.len = t->length;
+
+	/* Fill export header. */
+	header->count = t->count;
+	header->sys_uptime = htonl(MILLIUPTIME(time_uptime));
+	getnanotime(&ts);
+	header->unix_secs  = htonl(ts.tv_sec);
+	header->seq_num = htonl(atomic_fetchadd_32(&priv->flow_seq, 1));
+	header->count = htons(t->count);
+	header->source_id = htonl(NG_NODE_ID(priv->node));
+
+	/* remove tag */
+	m_tag_delete_chain(m, NULL);
+
+	if (priv->export != NULL)
+		NG_FWD_ITEM_HOOK_FLAGS(error, item, priv->export, flags);
+	else
+		NG_FREE_ITEM(item);
+
+	return (error);
+}
 
 /* Add export record to dgram. */
 static int
@@ -628,9 +1060,9 @@
 	    ("ng_netflow: export too big"));
 
 	/* Fill in export record. */
-	rec->src_addr = fle->f.r.r_src.s_addr;
-	rec->dst_addr = fle->f.r.r_dst.s_addr;
-	rec->next_hop = fle->f.next_hop.s_addr;
+	rec->src_addr = fle->f.r.src.r_src.s_addr;
+	rec->dst_addr = fle->f.r.dst.r_dst.s_addr;
+	rec->next_hop = fle->f.n.next_hop.s_addr;
 	rec->i_ifx    = htons(fle->f.fle_i_ifx);
 	rec->o_ifx    = htons(fle->f.fle_o_ifx);
 	rec->packets  = htonl(fle->f.packets);
@@ -654,6 +1086,135 @@
 		return (0);	
 }
 
+/* Add V9 record to dgram. */
+static int
+export_add_v9(item_p item, struct flow_entry *fle)
+{
+	size_t len = 0;
+	uint16_t new_flow = 0;
+	void *offset_ptr;
+	struct netflow_v9_mbuf_tag *t;
+	struct netflow_v9_flowset_header *fs = NULL;
+	struct mbuf *m =  NGI_M(item);
+	struct m_tag *mt = m_tag_locate(m, MTAG_NETFLOW, MTAG_NETFLOW_V9, NULL);
+
+	if (mt == NULL) {
+		/* */
+		log(LOG_DEBUG, "ng_netflow: V9 export packet without tag!\n");
+		return (0);
+	}
+
+	t = (struct netflow_v9_mbuf_tag *)(mt + 1);
+	offset_ptr = (mtod(m, char *) + t->length);
+
+	/* Check if new records has the same template */
+	if (fle->f.r.flow_type != t->flow_type) {
+		new_flow = 1;
+		
+		/* 'Close' old FlowSet */
+		fs = (struct netflow_v9_flowset_header *)(mtod(m, char *) + t->flow_header);
+		len = (uint16_t)(t->length - t->flow_header);
+		if (len % 4) {
+			t->length += 4 - (len % 4);
+			len += 4 - (len % 4);
+		}
+		fs->length = htons(len);
+
+		/* Prepare 'new', but do not modify any counters here because switch can fail */
+		t->flow_type = NETFLOW_V9_FLOW_FAKE;
+		t->flow_header = t->length;
+		fs = (struct netflow_v9_flowset_header *)(mtod(m, char *) + t->length);
+		offset_ptr = (fs + 1);
+	}
+
+
+	switch (fle->f.r.flow_type) {
+	case NETFLOW_V9_FLOW_V4_L4:
+	{
+		/* IPv4 TCP/UDP/[SCTP] */
+		struct netflow_v9_record_ipv4_tcp *rec = (struct netflow_v9_record_ipv4_tcp *)offset_ptr;
+
+		
+		rec->src_addr = fle->f.r.src.r_src.s_addr;
+		rec->dst_addr = fle->f.r.dst.r_dst.s_addr;
+		rec->next_hop = fle->f.n.next_hop.s_addr;
+		rec->i_ifx    = htons(fle->f.fle_i_ifx);
+		rec->o_ifx    = htons(fle->f.fle_o_ifx);
+		rec->i_packets  = htonl(fle->f.packets);
+		rec->i_octets   = htonl(fle->f.bytes);
+		rec->o_packets  = htonl(0);
+		rec->o_octets   = htonl(0);
+		rec->first    = htonl(MILLIUPTIME(fle->f.first));
+		rec->last     = htonl(MILLIUPTIME(fle->f.last));
+		rec->s_port   = fle->f.r.r_sport;
+		rec->d_port   = fle->f.r.r_dport;
+		rec->flags    = fle->f.tcp_flags;
+		rec->prot     = fle->f.r.r_ip_p;
+		rec->tos      = fle->f.r.r_tos;
+		rec->dst_mask = fle->f.dst_mask;
+		rec->src_mask = fle->f.src_mask;
+
+		/* Not supported fields. */
+		rec->src_as = rec->dst_as = 0;
+
+		len = sizeof(struct netflow_v9_record_ipv4_tcp);
+		break;
+	}
+#ifdef INET6	
+	case NETFLOW_V9_FLOW_V6_L4:
+	{
+		/* IPv6 TCP/UDP/[SCTP] */
+		struct netflow_v9_record_ipv6_tcp *rec = (struct netflow_v9_record_ipv6_tcp *)offset_ptr;
+
+		/* ACHTUNG! unchecked code! */
+		rec->src_addr = fle->f.r.src.r_src6;
+		rec->dst_addr = fle->f.r.dst.r_dst6;
+		rec->next_hop = fle->f.n.next_hop6;
+		rec->i_ifx    = htons(fle->f.fle_i_ifx);
+		rec->o_ifx    = htons(fle->f.fle_o_ifx);
+		rec->i_packets  = htonl(fle->f.packets);
+		rec->i_octets   = htonl(fle->f.bytes);
+		rec->first    = htonl(MILLIUPTIME(fle->f.first));
+		rec->last     = htonl(MILLIUPTIME(fle->f.last));
+		rec->s_port   = fle->f.r.r_sport;
+		rec->d_port   = fle->f.r.r_dport;
+		rec->flags    = fle->f.tcp_flags;
+		rec->prot     = fle->f.r.r_ip_p;
+		rec->tos      = fle->f.r.r_tos;
+		rec->dst_mask = fle->f.dst_mask;
+		rec->src_mask = fle->f.src_mask;
+
+		/* Not supported fields. */
+		rec->src_as = rec->dst_as = 0;
+
+		len = sizeof(struct netflow_v9_record_ipv6_tcp);
+		break;
+	}
+#endif	
+	default:
+	{
+		log(LOG_DEBUG, "ng_netflow: Don't know what to do with %d flow type!\n", fle->f.r.flow_type);
+		return (0);
+	}
+	}
+
+	if (new_flow) {
+		/* Generate data segment ID */
+		fs->id = htons(0x100 + fle->f.r.flow_type);
+		t->flow_type = fle->f.r.flow_type;
+		t->length += sizeof(struct netflow_v9_flowset_header);
+	}
+
+	t->length += len;
+	t->count++;
+
+	if (t->length + NETFLOW_V9_MAX_RECORD_SIZE + 4 >= _NETFLOW_V9_MAX_SIZE(t->mtu))
+		return (1); /* end of datagram */
+	else
+		return (0);
+}
+
+
 /* Periodic flow expiry run. */
 void
 ng_netflow_expire(void *arg)
diff -urN sys/netgraph/_netflow.orig/netflow.h sys/netgraph/netflow/netflow.h
--- sys/netgraph/_netflow.orig/netflow.h	2009-09-01 02:37:44.000000000 +0400
+++ sys/netgraph/netflow/netflow.h	2009-09-06 12:41:29.000000000 +0400
@@ -46,6 +46,7 @@
 
 #define NETFLOW_V1 1
 #define NETFLOW_V5 5
+#define NETFLOW_V9 9
 
 struct netflow_v1_header
 {
@@ -69,6 +70,16 @@
   uint16_t pad;		/* Pad to word boundary */
 } __attribute__((__packed__));
 
+struct netflow_v9_header
+{
+  uint16_t version;	/* NetFlow version */
+  uint16_t count;	/* Total number of records in packet */
+  uint32_t sys_uptime;	/* System uptime */
+  uint32_t unix_secs;	/* Current seconds since 0000 UTC 1970 */
+  uint32_t seq_num;	/* Sequence number */
+  uint32_t source_id;	/* Observation Domain id */
+} __attribute__((__packed__));
+
 struct netflow_v1_record
 {
   uint32_t src_addr;	/* Source IP address */
@@ -115,6 +126,142 @@
   uint16_t pad2;	/* Pad to word boundary */
 } __attribute__((__packed__));
 
+
+
+/* RFC3954 field definitions */
+#define NETFLOW_V9_FIELD_IN_BYTES	1	/* Input bytes count for a flow. Default 4, can be 8 */
+#define NETFLOW_V9_FIELD_IN_PKTS	2	/* Incoming counter with number of packets associated with an IP Flow. Default 4 */
+#define NETFLOW_V9_FIELD_FLOWS		3	/* Number of Flows that were aggregated. Default 4 */
+#define NETFLOW_V9_FIELD_PROTOCOL	4	/* IP protocol byte. 1 */
+#define NETFLOW_V9_FIELD_TOS		5	/* Type of service byte setting when entering the incoming interface. 1 */
+#define NETFLOW_V9_FIELD_TCP_FLAGS	6	/* TCP flags; cumulative of all the TCP flags seen in this Flow. 1 */
+#define NETFLOW_V9_FIELD_L4_SRC_PORT	7	/* TCP/UDP source port number. 2 */
+#define NETFLOW_V9_FIELD_IPV4_SRC_ADDR	8	/* IPv4 source address. 4 */
+#define NETFLOW_V9_FIELD_SRC_MASK	9	/* The number of contiguous bits in the source subnet mask (i.e., the mask in slash notation). 1 */
+#define NETFLOW_V9_FIELD_INPUT_SNMP	10	/* Input interface index. Default 2 */
+#define NETFLOW_V9_FIELD_L4_DST_PORT	11	/* TCP/UDP destination port number. 2 */
+#define NETFLOW_V9_FIELD_IPV4_DST_ADDR	12	/* IPv4 destination address. 4 */
+#define NETFLOW_V9_FIELD_DST_MASK	13	/* The number of contiguous bits in the destination subnet mask (i.e., the mask in slash notation). 1 */
+#define NETFLOW_V9_FIELD_OUTPUT_SNMP	14	/* Output interface index. Default 2 */
+#define NETFLOW_V9_FIELD_IPV4_NEXT_HOP	15	/* IPv4 address of the next-hop router. 4 */
+#define NETFLOW_V9_FIELD_SRC_AS		16	/* Source BGP autonomous system number. Default 2, can be 4 */
+#define NETFLOW_V9_FIELD_DST_AS		17	/* Destination BGP autonomous system number. Default 2, can be 4 */
+#define NETFLOW_V9_FIELD_BGP_IPV4_NEXT_HOP	18	/* Next-hop router's IP address in the BGP domain. 4 */
+#define NETFLOW_V9_FIELD_MUL_DST_PKTS	19	/* IP multicast outgoing packet counter for packets associated with IP flow. Default 4 */
+#define NETFLOW_V9_FIELD_MUL_DST_BYTES	20	/* IP multicast outgoing Octet (byte) counter for the number of bytes associated with IP flow. Default 4 */
+#define NETFLOW_V9_FIELD_LAST_SWITCHED	21	/* sysUptime in msec at which the last packet of this Flow was switched. 4 */
+#define NETFLOW_V9_FIELD_FIRST_SWITCHED	22	/* sysUptime in msec at which the first packet of this Flow was switched. 4 */
+#define NETFLOW_V9_FIELD_OUT_BYTES	23	/* Outgoing counter for the number of bytes associated with an IP Flow. Default 4 */
+#define NETFLOW_V9_FIELD_OUT_PKTS	24	/* Outgoing counter for the number of packets associated with an IP Flow. Default 4 */
+#define NETFLOW_V9_FIELD_IPV6_SRC_ADDR	27	/* IPv6 source address. 16 */
+#define NETFLOW_V9_FIELD_IPV6_DST_ADDR	28	/* IPv6 destination address. 16 */
+#define NETFLOW_V9_FIELD_IPV6_SRC_MASK	29	/* Length of the IPv6 source mask in contiguous bits. 1 */
+#define NETFLOW_V9_FIELD_IPV6_DST_MASK	30	/* Length of the IPv6 destination mask in contiguous bits. 1 */
+#define NETFLOW_V9_FIELD_IPV6_FLOW_LABEL	31	/* IPv6 flow label as per RFC 2460 definition. 3 */
+#define NETFLOW_V9_FIELD_ICMP_TYPE	32	/* Internet Control Message Protocol (ICMP) packet type; reported as ICMP Type * 256 + ICMP code. 2 */
+#define NETFLOW_V9_FIELD_MUL_IGMP_TYPE	33	/* Internet Group Management Protocol (IGMP) packet type. 1 */
+#define NETFLOW_V9_FIELD_SAMPLING_INTERVAL	34	/* When using sampled NetFlow, the rate at which packets are sampled; for example, a value of 100 indicates that one of every hundred packets is sampled. 4 */
+#define NETFLOW_V9_FIELD_SAMPLING_ALGORITHM	35	/* For sampled NetFlow platform-wide: 0x01 deterministic sampling 0x02 random sampling. 1 */
+#define NETFLOW_V9_FIELD_FLOW_ACTIVE_TIMEOUT	36	/* Timeout value (in seconds) for active flow entries in the NetFlow cache. 2 */
+#define NETFLOW_V9_FIELD_FLOW_INACTIVE_TIMEOUT	37	/* Timeout value (in seconds) for inactive Flow entries in the NetFlow cache. 2 */
+#define NETFLOW_V9_FIELD_ENGINE_TYPE	38	/* Type of Flow switching engine (route processor, linecard, etc...). 1 */
+#define NETFLOW_V9_FIELD_ENGINE_ID	39	/* ID number of the Flow switching engine. 1 */
+#define NETFLOW_V9_FIELD_TOTAL_BYTES_EXP	40	/* Counter with for the number of bytes exported by the Observation Domain. Default 4 */
+#define NETFLOW_V9_FIELD_TOTAL_PKTS_EXP	41	/* Counter with for the number of packets exported by the Observation Domain. Default 4 */
+#define NETFLOW_V9_FIELD_TOTAL_FLOWS_EXP	42	/* Counter with for the number of flows exported by the Observation Domain. Default 4 */
+#define NETFLOW_V9_FIELD_MPLS_TOP_LABEL_TYPE	46	/* MPLS Top Label Type. 1 */
+#define NETFLOW_V9_FIELD_MPLS_TOP_LABEL_IP_ADDR	47	/* Forwarding Equivalent Class corresponding to the MPLS Top Label. 4 */
+#define NETFLOW_V9_FIELD_FLOW_SAMPLER_ID	48	/* Identifier shown in "show flow-sampler". 1 */
+#define NETFLOW_V9_FIELD_FLOW_SAMPLER_MODE	49	/* The type of algorithm used for sampling data. 2 */
+#define NETFLOW_V9_FIELD_FLOW_SAMPLER_RANDOM_INTERVAL	50	/* Packet interval at which to sample. 4. */
+#define NETFLOW_V9_FIELD_DST_TOS	55	/* Type of Service byte setting when exiting outgoing interface. 1. */
+#define NETFLOW_V9_FIELD_SRC_MAC	56	/* Source MAC Address. 6 */
+#define NETFLOW_V9_FIELD_DST_MAC	57	/* Destination MAC Address. 6 */
+#define NETFLOW_V9_FIELD_SRC_VLAN	58	/* Virtual LAN identifier associated with ingress interface. 2 */
+#define NETFLOW_V9_FIELD_DST_VLAN	59	/* irtual LAN identifier associated with egress interface. 2 */
+#define NETFLOW_V9_FIELD_IP_PROTOCOL_VERSION	60	/* Internet Protocol Version. Set to 4 for IPv4, set to 6 for IPv6. If not present in the template, then version 4 is assumed. 1. */
+#define NETFLOW_V9_FIELD_DIRECTION	61	/* Flow direction: 0 - ingress flow 1 - egress flow. 1 */
+#define NETFLOW_V9_FIELD_IPV6_NEXT_HOP	62	/* IPv6 address of the next-hop router. 16 */
+#define NETFLOW_V9_FIELD_BGP_IPV6_NEXT_HOP	63	/* Next-hop router in the BGP domain. 16 */
+#define NETFLOW_V9_FIELD_IPV6_OPTION_HEADERS	64	/* Bit-encoded field identifying IPv6 option headers found in the flow */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_1	70	/* MPLS label at position 1 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_2	71	/* MPLS label at position 2 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_3	72	/* MPLS label at position 3 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_4	73	/* MPLS label at position 4 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_5	74	/* MPLS label at position 5 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_6	75	/* MPLS label at position 6 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_7	76	/* MPLS label at position 7 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_8	77	/* MPLS label at position 8 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_9	78	/* MPLS label at position 9 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_10	79	/* MPLS label at position 10 in the stack. 3 */
+
+#ifdef COUNTERS_64
+#define cntr		uint64_t
+#define cntr_max	UINT64_MAX
+#else
+#define cntr		uint32_t
+#define cntr_max	UINT_MAX
+#endif
+
+struct netflow_v9_template
+{
+	int	field_id;
+	int	field_length;
+};
+
+/* Template ID for tcp/udp v4 streams ID:257 (0x100 + NETFLOW_V9_FLOW_V4_L4) */
+struct netflow_v9_record_ipv4_tcp
+{
+  uint32_t src_addr;	/* Source IPv4 address (IPV4_SRC_ADDR) */
+  uint32_t dst_addr;	/* Destination IPv4 address (IPV4_DST_ADDR) */
+  uint32_t next_hop;	/* Next hop IPv4 address (IPV4_NEXT_HOP) */  
+  uint16_t i_ifx;	/* Source interface index (INPUT_SNMP) */
+  uint16_t o_ifx;	/* Destination interface index (OUTPUT_SNMP) */
+  cntr i_packets;	/* Number of incoming packets in a flow (IN_PKTS) */
+  cntr i_octets;	/* Number of incoming octets in a flow (IN_BYTES) */
+  cntr o_packets;	/* Number of outgoing packets in a flow (OUT_PKTS) */
+  cntr o_octets;	/* Number of outgoing octets in a flow (OUT_BYTES) */
+  uint32_t first;	/* System uptime at start of a flow (FIRST_SWITCHED) */
+  uint32_t last;	/* System uptime at end of a flow (LAST_SWITCHED) */
+  uint16_t s_port;	/* Source port (L4_SRC_PORT) */
+  uint16_t d_port;	/* Destination port (L4_DST_PORT) */
+  uint8_t flags;	/* Cumulative OR of tcp flags (TCP_FLAGS) */
+  uint8_t prot;		/* IP protocol */
+  uint8_t tos;		/* IP type of service IN (or OUT) (TOS) */
+  uint32_t src_as;	/* Src peer/origin Autonomous System (SRC_AS) */  
+  uint32_t dst_as;	/* Dst peer/origin Autonomous System (DST_AS) */
+  uint8_t src_mask;	/* Source route's mask bits (SRC_MASK) */
+  uint8_t dst_mask; 	/* Destination route's mask bits (DST_MASK) */
+} __attribute__((__packed__));
+
+
+/* Template ID for tcp/udp v6 streams ID: 260 (0x100 + NETFLOW_V9_FLOW_V6_L4) */
+struct netflow_v9_record_ipv6_tcp
+{
+  struct in6_addr src_addr;	/* Source IPv6 address (IPV6_SRC_ADDR) */
+  struct in6_addr dst_addr;	/* Destination IPv6 address (IPV6_DST_ADDR) */
+  struct in6_addr next_hop;	/* Next hop IPv6 address (IPV6_NEXT_HOP) */  
+  uint16_t i_ifx;	/* Source interface index (INPUT_SNMP) */
+  uint16_t o_ifx;	/* Destination interface index (OUTPUT_SNMP) */
+  cntr i_packets;	/* Number of incoming packets in a flow (IN_PKTS) */
+  cntr i_octets;	/* Number of incoming octets in a flow (IN_BYTES) */
+  cntr o_packets;	/* Number of outgoing packets in a flow (OUT_PKTS) */
+  cntr o_octets;	/* Number of outgoing octets in a flow (OUT_BYTES) */
+  uint32_t first;	/* System uptime at start of a flow (FIRST_SWITCHED) */
+  uint32_t last;	/* System uptime at end of a flow (LAST_SWITCHED) */
+  uint16_t s_port;	/* Source port (L4_SRC_PORT) */
+  uint16_t d_port;	/* Destination port (L4_DST_PORT) */
+  uint8_t flags;	/* Cumulative OR of tcp flags (TCP_FLAGS) */
+  uint8_t prot;		/* IP protocol */
+  uint8_t tos;		/* IP type of service IN (or OUT) (TOS) */
+  uint32_t src_as;	/* Src peer/origin Autonomous System (SRC_AS) */  
+  uint32_t dst_as;	/* Dst peer/origin Autonomous System (DST_AS) */
+  uint8_t src_mask;	/* Source route's mask bits (SRC_MASK) */
+  uint8_t dst_mask; 	/* Destination route's mask bits (DST_MASK) */
+} __attribute__((__packed__));
+
+#define vlog(x, ...)	log(LOG_DEBUG, "%s:%d " x "\n", __FUNCTION__, __LINE__, ##__VA_ARGS__)
+
 #define NETFLOW_V1_MAX_RECORDS 24
 #define NETFLOW_V5_MAX_RECORDS 30
 
@@ -123,7 +270,50 @@
 #define NETFLOW_V5_MAX_SIZE (sizeof(netflow_v5_header)+ \
 			     sizeof(netflow_v5_record)*NETFLOW_V5_MAX_RECORDS)
 
+#define BASE_MTU	1500
+#define MIN_MTU		sizeof(struct netflow_v5_header)
+#define MAX_MTU		16384
+#define NETFLOW_V9_MAX_SIZE	_NETFLOW_V9_MAX_SIZE(BASE_MTU)
+#define _NETFLOW_V9_MAX_SIZE(x)	(x) - sizeof(struct ip6_hdr) - sizeof(struct udphdr)
+#define NETFLOW_V9_MAX_FLOWSETS	2
+
+#define NETFLOW_V9_MAX_RECORD_SIZE	sizeof(struct netflow_v9_record_ipv6_tcp)
+#define NETFLOW_V9_MAX_PACKETS_TEMPL	500	/* Send data templates every ... packets */
+#define NETFLOW_V9_MAX_TIME_TEMPL	600	/* Send data templates every ... seconds */
+#define NETFLOW_V9_MAX_TEMPLATES	16	/* Not a real value */
+#define _NETFLOW_V9_TEMPLATE_SIZE(x)	(sizeof(x) / sizeof(struct netflow_v9_template)) * 4
+//#define _NETFLOW_V9_TEMPLATE_SIZE(x)	((x) + 1) * 4
+
+/* Flow Templates */
+#define NETFLOW_V9_FLOW_V4_L4	1 /* IPv4 TCP/UDP packet */
+#define NETFLOW_V9_FLOW_V4_ICMP	2 /* IPv4 ICMP packet, currently unused */
+#define NETFLOW_V9_FLOW_V4_L3	3 /* IPv4 IP packet */
+#define NETFLOW_V9_FLOW_V6_L4	4 /* IPv6 TCP/UDP packet */
+#define NETFLOW_V9_FLOW_V6_ICMP	5 /* IPv6 ICMP packet, currently unused */
+#define NETFLOW_V9_FLOW_V6_L3	6 /* IPv6 IP packet */
+
+#define NETFLOW_V9_FLOW_FAKE	65535 /* Not uset used in real flowsets! */
+
 struct netflow_v5_export_dgram {
 	struct netflow_v5_header	header;
 	struct netflow_v5_record	r[NETFLOW_V5_MAX_RECORDS];
 } __attribute__((__packed__));
+
+struct netflow_v9_export_dgram {
+	struct netflow_v9_header	header;
+	char				data; /* MTU can change, record length is dynamic */
+};
+
+struct netflow_v9_flowset_header {
+	uint16_t	id; /* FlowSet id */
+	uint16_t	length; /* FlowSet length */
+} __attribute__((__packed__));
+
+struct netflow_v9_mbuf_tag {
+	struct m_tag	tag; /* pointer to mbuf tag */
+	uint16_t	length; /* Current packet length */
+	uint16_t	count; /* current records count */
+	uint16_t	mtu; /* max MTU shapshot */
+	uint16_t	flow_type; /* current flowset */
+	uint16_t	flow_header; /* offset pointing to current flow header */
+};
diff -urN sys/netgraph/_netflow.orig/ng_netflow.c sys/netgraph/netflow/ng_netflow.c
--- sys/netgraph/_netflow.orig/ng_netflow.c	2009-09-01 02:37:44.000000000 +0400
+++ sys/netgraph/netflow/ng_netflow.c	2009-09-06 16:36:08.000000000 +0400
@@ -30,6 +30,8 @@
 static const char rcs_id[] =
     "@(#) $FreeBSD: src/sys/netgraph/netflow/ng_netflow.c,v 1.20 2009/05/13 02:26:34 mav Exp $";
 
+#include "opt_inet6.h"
+
 #include <sys/param.h>
 #include <sys/systm.h>
 #include <sys/kernel.h>
@@ -48,8 +50,11 @@
 #include <netinet/in.h>
 #include <netinet/in_systm.h>
 #include <netinet/ip.h>
+#include <netinet/ip6.h>
+#include <netinet/ip6.h>
 #include <netinet/tcp.h>
 #include <netinet/udp.h>
+#include <netinet/sctp.h>
 
 #include <netgraph/ng_message.h>
 #include <netgraph/ng_parse.h>
@@ -114,6 +119,30 @@
 	&ng_netflow_setconfig_type_fields
 };
 
+/* Parse type for ng_netflow_setversion */
+static const struct ng_parse_struct_field ng_netflow_setversion_type_fields[]
+	= NG_NETFLOW_SETVERSION_TYPE;
+static const struct ng_parse_type ng_netflow_setversion_type = {
+	&ng_parse_struct_type,
+	&ng_netflow_setversion_type_fields
+};
+
+/* Parse type for ng_netflow_settemplateperiodic */
+static const struct ng_parse_struct_field ng_netflow_settemplateperiodic_type_fields[]
+	= NG_NETFLOW_SETTEMPLATEPERIODIC_TYPE;
+static const struct ng_parse_type ng_netflow_settemplateperiodic_type = {
+	&ng_parse_struct_type,
+	&ng_netflow_settemplateperiodic_type_fields
+};
+
+/* Parse type for ng_netflow_setmtu */
+static const struct ng_parse_struct_field ng_netflow_setmtu_type_fields[]
+	= NG_NETFLOW_SETMTU_TYPE;
+static const struct ng_parse_type ng_netflow_setmtu_type = {
+	&ng_parse_struct_type,
+	&ng_netflow_setmtu_type_fields
+};
+
 /* List of commands and how to convert arguments to/from ASCII */
 static const struct ng_cmdlist ng_netflow_cmds[] = {
        {
@@ -158,6 +187,27 @@
 	&ng_netflow_setconfig_type,
 	NULL
        },
+       {
+	NGM_NETFLOW_COOKIE,
+	NGM_NETFLOW_SETVERSION,
+	"setversion",
+	&ng_netflow_setversion_type,
+	NULL
+       },
+       {
+	NGM_NETFLOW_COOKIE,
+	NGM_NETFLOW_SETTEMPLATEPERIODIC,
+	"settemplateperiodic",
+	&ng_netflow_settemplateperiodic_type,
+	NULL
+       },
+       {
+	NGM_NETFLOW_COOKIE,
+	NGM_NETFLOW_SETMTU,
+	"setmtu",
+	&ng_netflow_setmtu_type,
+	NULL
+       },
        { 0 }
 };
 
@@ -202,6 +252,13 @@
 	for (i = 0; i < NG_NETFLOW_MAXIFACES; i++)
 		priv->ifaces[i].info.conf = NG_NETFLOW_CONF_INGRESS;
 
+	/* Set v9 defaults */
+	priv->version = NETFLOW_V9;
+	priv->templ_time = NETFLOW_V9_MAX_TIME_TEMPL;
+	priv->templ_packets = NETFLOW_V9_MAX_PACKETS_TEMPL;
+	priv->mtu = BASE_MTU;
+	priv->flow_seq = 0;
+
 	/* Initialize callout handle */
 	callout_init(&priv->exp_callout, CALLOUT_MPSAFE);
 
@@ -434,6 +491,52 @@
 	
 			break;
 		}
+		case NGM_NETFLOW_SETVERSION:
+		{
+			struct ng_netflow_setversion *set;
+
+			if (msg->header.arglen != sizeof(struct ng_netflow_setversion))
+				ERROUT(EINVAL);
+
+			set = (struct ng_netflow_setversion *)msg->data;
+			if ((set->version != NETFLOW_V9) && (set->version != NETFLOW_V5))
+				ERROUT(EINVAL);
+
+			ng_netflow_switch_version(priv, set->version, 0);
+
+			break;
+		}
+		case NGM_NETFLOW_SETTEMPLATEPERIODIC:
+		{
+			struct ng_netflow_settemplateperiodic *set;
+
+			if (msg->header.arglen != sizeof(struct ng_netflow_settemplateperiodic))
+				ERROUT(EINVAL);
+
+			set = (struct ng_netflow_settemplateperiodic *)msg->data;
+
+			/* XXX: Set atomic here */
+			priv->templ_packets = set->packets;
+			priv->templ_time = set->time;
+
+			break;
+		}
+		case NGM_NETFLOW_SETMTU:
+		{
+			struct ng_netflow_setmtu *set;
+
+			if (msg->header.arglen != sizeof(struct ng_netflow_setmtu))
+				ERROUT(EINVAL);
+
+			set = (struct ng_netflow_setmtu *)msg->data;
+			if ((set->mtu < MIN_MTU) || (set->mtu > MAX_MTU))
+				ERROUT(EINVAL);
+
+			/* XXX: Set atomic here */
+			priv->mtu = set->mtu;
+
+			break;
+		}
 		case NGM_NETFLOW_SHOW:
 		{
 			uint32_t *last;
@@ -481,12 +584,15 @@
 	const priv_p priv = NG_NODE_PRIVATE(node);
 	const iface_p iface = NG_HOOK_PRIVATE(hook);
 	hook_p out;
-	struct mbuf *m = NULL;
-	struct ip *ip;
+	struct mbuf *m, *m_old = NULL;
+	struct ip *ip = NULL;
+	struct ip6_hdr *ip6 = NULL;
 	struct m_tag *mtag;
-	int pullup_len = 0;
+	int pullup_len = 0, off;
+	uint8_t upper_proto = 0, is_frag = 0;
 	int error = 0, bypass = 0;
 	unsigned int src_if_index;
+	caddr_t upper_ptr = NULL;
 
 	if (hook == priv->export) {
 		/*
@@ -541,6 +647,7 @@
 	}
 
 	NGI_GET_M(item, m);
+	m_old = m;
 
 	/* Increase counters. */
 	iface->info.ifinfo_packets++;
@@ -569,6 +676,22 @@
 	}							\
 } while (0)
 
+/*	
+#define	M_HCHECK(length)	do {				\
+	pullup_len += length + sizeof(ip6_ext);			\
+	if ((m)->m_pkthdr.len < (pullup_len)) {			\
+		pullup_len -= length + sizeof(ip6_ext);
+		M_CHECK(length);
+		`
+	} 							\
+	if ((m)->m_len < (pullup_len) &&			\
+	   (((m) = m_pullup((m),(pullup_len))) == NULL)) {	\
+		error = ENOBUFS;				\
+		goto done;					\
+	}							\
+} while (0)
+*/
+
 	switch (iface->info.ifinfo_dlt) {
 	case DLT_EN10MB:	/* Ethernet */
 	    {
@@ -586,6 +709,33 @@
 			eh = mtod(m, struct ether_header *);
 			ip = (struct ip *)(eh + 1);
 			break;
+#ifdef INET6			
+		case ETHERTYPE_IPV6:
+			/* 
+			 * This is done not to pullup mbuf twice on every ext
+			 * header 
+			 */
+			pullup_len += sizeof(struct ip6_hdr) + sizeof(struct ip6_ext);
+			if (m->m_pkthdr.len >= pullup_len) {
+				if ((m = m_pullup(m, pullup_len)) == NULL) {
+					error = ENOBUFS;
+					goto done;
+				}
+				pullup_len -= sizeof(struct ip6_ext);
+			} else {
+				pullup_len -= sizeof(struct ip6_hdr) + sizeof(struct ip6_ext);
+				M_CHECK(sizeof(struct ip6_hdr));
+				eh = mtod(m, struct ether_header *);
+				ip6 = (struct ip6_hdr *)(eh + 1);
+				if (ip6->ip6_nxt != IPPROTO_NONE) {
+					error = EINVAL;
+					goto bypass;
+				}
+			}
+			eh = mtod(m, struct ether_header *);
+			ip6 = (struct ip6_hdr *)(eh + 1);
+			break;
+#endif			
 		case ETHERTYPE_VLAN:
 		    {
 			struct ether_vlan_header *evh;
@@ -597,6 +747,29 @@
 				M_CHECK(sizeof(struct ip));
 				ip = (struct ip *)(evh + 1);
 				break;
+			} else if (ntohs(evh->evl_proto) == ETHERTYPE_IPV6) {
+#ifdef INET6				
+				pullup_len += sizeof(struct ip6_hdr) + sizeof(struct ip6_ext);
+				if (m->m_pkthdr.len >= pullup_len) {
+					if ((m = m_pullup(m, pullup_len)) == NULL) {
+						error = ENOBUFS;
+						goto done;
+					}
+					pullup_len -= sizeof(struct ip6_ext);
+				} else {
+					pullup_len -= sizeof(struct ip6_hdr) + sizeof(struct ip6_ext);
+					M_CHECK(sizeof(struct ip6_hdr));
+					eh = mtod(m, struct ether_header *);
+					ip6 = (struct ip6_hdr *)(eh + 1);
+					if (ip6->ip6_nxt != IPPROTO_NONE) {
+						error = EINVAL;
+						goto bypass;
+					}
+				}
+				eh = mtod(m, struct ether_header *);
+				ip6 = (struct ip6_hdr *)(eh + 1);
+				break;
+#endif				
 			}
 		    }
 		default:
@@ -607,18 +780,32 @@
 	case DLT_RAW:		/* IP packets */
 		M_CHECK(sizeof(struct ip));
 		ip = mtod(m, struct ip *);
+#ifdef INET6		
+		if (ip->ip_v == 6) {
+			/* IPv6 packet */
+			ip = NULL;
+			M_CHECK(sizeof(struct ip6_hdr));
+			ip6 = mtod(m, struct ip6_hdr *);
+		}
+#endif		
 		break;
 	default:
 		goto bypass;
 		break;
 	}
 
-	if ((ip->ip_off & htons(IP_OFFMASK)) == 0) {
+	if ((ip != NULL) && ((ip->ip_off & htons(IP_OFFMASK)) == 0)) {
+		if ((ip->ip_v != IPVERSION) || 
+		    ((ip->ip_hl << 2) < sizeof(struct ip)))
+			goto bypass;
 		/*
-		 * In case of IP header with options, we haven't pulled
+		 * In case of IPv4 header with options, we haven't pulled
 		 * up enough, yet.
 		 */
 		pullup_len += (ip->ip_hl << 2) - sizeof(struct ip);
+		off = pullup_len;
+		//vlog("upper_offset = %d", off);
+		upper_proto = ip->ip_p;
 
 		switch (ip->ip_p) {
 		case IPPROTO_TCP:
@@ -627,38 +814,161 @@
 		case IPPROTO_UDP:
 			M_CHECK(sizeof(struct udphdr));
 			break;
+		case IPPROTO_SCTP:
+			M_CHECK(sizeof(struct sctphdr));
+			break;
 		}
-	}
+	} else if (ip != NULL) {
+		is_frag = 1;
+		upper_proto = ip->ip_p;
+		if ((ip->ip_v != IPVERSION) || 
+		    ((ip->ip_hl << 2) < sizeof(struct ip)))
+			goto bypass;
+	} else if (ip6 != NULL) {
+#ifdef INET6		
+		/* Check if we can export */
+		if (priv->version < NETFLOW_V9)
+			goto bypass;
+
+		/* Loop thru IPv6 extended headers to get upper layer header / frag */
+		int cur = ip6->ip6_nxt, hdr_off = 0;
+		struct ip6_ext *ip6e;
+		struct ip6_frag *ip6f;
+
+		off = pullup_len;
+		upper_proto = cur;
+
+		if ((ip6->ip6_vfc & IPV6_VERSION_MASK) != IPV6_VERSION)
+			goto bypass;
+
+		while (42) {
+
+			/*
+			 * At the moment we're 'standing' with pullup_len and
+			 * off 
+			 */
+			switch (cur) {
+
+			/* Ensure pointer is contiguous */
+			case IPPROTO_TCP:
+				M_CHECK(sizeof(struct tcphdr));
+				goto loopend;
+			case IPPROTO_UDP:
+				M_CHECK(sizeof(struct udphdr));
+				goto loopend;
+			case IPPROTO_SCTP:
+				M_CHECK(sizeof(struct sctphdr));
+				goto loopend;
+
+			/* Loop until 'real' upper layer headers */
+			case IPPROTO_HOPOPTS:
+			case IPPROTO_ROUTING:
+			case IPPROTO_DSTOPTS:
+				ip6e = (struct ip6_ext *)(mtod(m, caddr_t) + off);
+				upper_proto = ip6e->ip6e_nxt;
+				hdr_off = (ip6e->ip6e_len + 1) << 3;
+				break;
 
-	switch (iface->info.ifinfo_dlt) {
-	case DLT_EN10MB:
-	    {
-		struct ether_header *eh;
+			/* RFC4302, can be before DSTOPTS */
+			case IPPROTO_AH:
+				ip6e = (struct ip6_ext *)(mtod(m, caddr_t) + off);
+				upper_proto = ip6e->ip6e_nxt;
+				hdr_off = (ip6e->ip6e_len + 2) << 2;
+				break;
 
-		eh = mtod(m, struct ether_header *);
-		switch (ntohs(eh->ether_type)) {
-		case ETHERTYPE_IP:
-			ip = (struct ip *)(eh + 1);
-			break;
-		case ETHERTYPE_VLAN:
-		    {
-			struct ether_vlan_header *evh;
+			
+			case IPPROTO_FRAGMENT:
+				ip6f = (struct ip6_frag *)(mtod(m, caddr_t) + off);
+				upper_proto = ip6f->ip6f_nxt;
+				hdr_off = sizeof(struct ip6_frag);
+				off += hdr_off;
+				is_frag = 1;
+				goto loopend;
+
+/*				
+			case IPPROTO_NONE:
+				goto loopend;
+*/
+			default:
+				goto loopend;
+			}
 
-			evh = mtod(m, struct ether_vlan_header *);
-			ip = (struct ip *)(evh + 1);
+			off += hdr_off + sizeof(struct ip6_ext);
+			cur = upper_proto;
+			if (m->m_pkthdr.len >= off) {
+				if ((m = m_pullup(m, off)) == NULL) {
+					error = ENOBUFS;
+					goto done;
+				}
+				off -= sizeof(struct ip6_ext);
+				pullup_len += hdr_off;
+			} else {
+				/*
+				 * Packet ends somewhere here.
+				 * if its next header is not IPPROTO_NONE it is
+				 * possibly mailformed packet. Let's count as RAW IP
+				 */
+				upper_proto = IPPROTO_NONE;
+				off -= sizeof(struct ip6_ext);
+				goto loopend;
+			}
+
+		}
+#endif
+	}
+
+#ifdef INET6
+loopend:
+#endif
+	if (m != m_old) {
+		switch (iface->info.ifinfo_dlt) {
+		case DLT_EN10MB:	/* Ethernet */
+		    {
+			struct ether_header *eh;
+	
+			eh = mtod(m, struct ether_header *);
+			switch (ntohs(eh->ether_type)) {
+			case ETHERTYPE_IP:
+				ip = (struct ip *)(eh + 1);
+				break;
+			case ETHERTYPE_IPV6:
+				ip6 = (struct ip6_hdr *)(eh + 1);
+				break;
+			case ETHERTYPE_VLAN:
+			    {
+				struct ether_vlan_header *evh;
+	
+				evh = mtod(m, struct ether_vlan_header *);
+				if (ntohs(evh->evl_proto) == ETHERTYPE_IP) {
+					ip = (struct ip *)(evh + 1);
+					break;
+				} else if (ntohs(evh->evl_proto) == ETHERTYPE_IPV6) {
+#ifdef INET6					
+					ip6 = (struct ip6_hdr *)(evh + 1);
+					break;
+#endif					
+				}
+			    }
+			default:
+				panic("ng_netflow entered deadcode");
+			}
+			break;
+		    }
+		case DLT_RAW:		/* IP packets */
+			ip = mtod(m, struct ip *);
+#ifdef INET6			
+			if (ip->ip_v == 6) {
+				/* IPv6 packet */
+				ip = NULL;
+				ip6 = mtod(m, struct ip6_hdr *);
+			}
+#endif			
 			break;
-		     }
 		default:
 			panic("ng_netflow entered deadcode");
 		}
-		break;
-	     }
-	case DLT_RAW:
-		ip = mtod(m, struct ip *);
-		break;
-	default:
-		panic("ng_netflow entered deadcode");
 	}
+	upper_ptr = (caddr_t)(mtod(m, caddr_t) + off);
 
 #undef	M_CHECK
 
@@ -670,7 +980,7 @@
 	} else
 		src_if_index = iface->info.ifinfo_index;
 
-	error = ng_netflow_flow_add(priv, ip, src_if_index);
+	error = ng_netflow_flow_add(priv, (ip != NULL) ? (caddr_t)ip : (caddr_t)ip6, upper_ptr, upper_proto, is_frag, src_if_index);
 
 bypass:
 	if (out != NULL) {
diff -urN sys/netgraph/_netflow.orig/ng_netflow.h sys/netgraph/netflow/ng_netflow.h
--- sys/netgraph/_netflow.orig/ng_netflow.h	2009-09-01 02:37:44.000000000 +0400
+++ sys/netgraph/netflow/ng_netflow.h	2009-09-06 16:36:17.000000000 +0400
@@ -51,6 +51,9 @@
     NGM_NETFLOW_SETIFINDEX	= 5, 	/* set interface index */
     NGM_NETFLOW_SETTIMEOUTS	= 6, 	/* set active/inactive flow timeouts */
     NGM_NETFLOW_SETCONFIG	= 7, 	/* set flow generation options */
+    NGM_NETFLOW_SETVERSION	= 8, 	/* set flow export version  */
+    NGM_NETFLOW_SETTEMPLATEPERIODIC	= 9, 	/* set v9 flow template periodic */
+    NGM_NETFLOW_SETMTU		= 10, 	/* set outgoing interface MTU */
 };
 
 /* This structure is returned by the NGM_NETFLOW_INFO message */
@@ -105,10 +108,34 @@
 	u_int32_t conf;			/* new config */
 };
 
+/* This structure is passed to NGM_NETFLOW_SETVERSION */
+struct ng_netflow_setversion {
+	u_int8_t version;		/* netflow version */
+};
+
+/* This structure is passed to NGM_NETFLOW_SETTEMPLATEPERIODIC */
+struct ng_netflow_settemplateperiodic {
+	u_int16_t time;		/* max time between announce */
+	u_int16_t packets;	/* max packets between announce */
+};
+
+/* This structure is passed to NGM_NETFLOW_SETMTU */
+struct ng_netflow_setmtu {
+	u_int16_t mtu;		/* MTU for packet */
+};
+
 /* This is unique data, which identifies flow */
 struct flow_rec {
-	struct in_addr	r_src;
-	struct in_addr	r_dst;
+	uint16_t	flow_type; /* IPv4 L4/L3 Ipv6 L4/L3 flow, see NETFLOW_V9_FLOW* */
+	uint16_t	ether_proto; /* unused */
+	union {
+		struct in_addr	r_src;
+		struct in6_addr	r_src6;
+	} src;
+	union {
+		struct in_addr	r_dst;
+		struct in6_addr	r_dst6;
+	} dst;
 	union {
 		struct {
 			uint16_t	s_port;	/* source TCP/UDP port */
@@ -137,7 +164,10 @@
 /* A flow entry which accumulates statistics */
 struct flow_entry_data {
 	struct flow_rec		r;
-	struct in_addr		next_hop;
+	union {
+		struct in_addr		next_hop;
+		struct in6_addr		next_hop6;
+	} n;
 	uint16_t		fle_o_ifx;	/* output interface index */
 #define				fle_i_ifx	r.misc.i.i_ifx
 	uint8_t		dst_mask;	/* destination route mask bits */
@@ -146,6 +176,7 @@
 	u_long			bytes;
 	long			first;	/* uptime on first packet */
 	long			last;	/* uptime on last packet */
+	uint16_t		proto; /* IP/IPv6 */
 	u_char			tcp_flags;	/* cumulative OR */
 };
 
@@ -227,6 +258,26 @@
 	{ NULL }					\
 }
 
+/* Parse the setversion structure */
+#define	NG_NETFLOW_SETVERSION_TYPE {			\
+	{ "version",	&ng_parse_uint8_type },		\
+	{ NULL }					\
+}
+
+/* Parse the settemplateperiodic structure */
+#define	NG_NETFLOW_SETTEMPLATEPERIODIC_TYPE {			\
+	{ "time",	&ng_parse_uint16_type },		\
+	{ "packets",	&ng_parse_uint16_type },		\
+	{ NULL }					\
+}
+
+/* Parse the setmtu structure */
+#define	NG_NETFLOW_SETMTU_TYPE {			\
+	{ "mtu",	&ng_parse_uint16_type },		\
+	{ NULL }					\
+}
+
+
 /* Private hook data */
 struct ng_netflow_iface {
 	hook_p		hook;		/* NULL when disconnected */
@@ -270,6 +321,20 @@
 	item_p			export_item;
 	struct mtx		export_mtx;
 	uint32_t		flow_seq;	/* current flow sequence */
+	/* 
+	 * RFC 3954 clause 7.3
+	 * "Both options MUST be configurable by the user on the Exporter."
+	 */
+	uint16_t		templ_time;	/* time between sending templates */
+	uint16_t		templ_packets;	/* packets between sending templates */
+	uint32_t		templ_last_ts;	/* unixtime of last template announce */
+	uint32_t		templ_last_pkt;	/* packets count on last template announce */
+	uint32_t		sent_packets;	/* packets sent by exporeter; can be reached another way ? */
+	u_char			version;	/* Netflow export version */
+	u_char			flowsets_count; /* current flowsets used */
+	u_char			flowset_records[NETFLOW_V9_MAX_FLOWSETS - 1]; /* Count of records in each flowset */
+	uint16_t		mtu;		/* export interface MTU */
+	struct netflow_v9_flowset_header	*v9_flowsets[NETFLOW_V9_MAX_FLOWSETS - 1]; /* Pointers to pre-compiled flowsets */
 
 	struct ng_netflow_iface	ifaces[NG_NETFLOW_MAXIFACES];
 };
@@ -286,14 +351,15 @@
 
 #define MTAG_NETFLOW		1221656444
 #define MTAG_NETFLOW_CALLED	0
+#define MTAG_NETFLOW_V9		1
 
 /* Prototypes for netflow.c */
 int	ng_netflow_cache_init(priv_p);
 void	ng_netflow_cache_flush(priv_p);
 void	ng_netflow_copyinfo(priv_p, struct ng_netflow_info *);
 timeout_t ng_netflow_expire;
-int	ng_netflow_flow_add(priv_p, struct ip *, unsigned int src_if_index);
+int	ng_netflow_flow_add(priv_p, caddr_t ip_ptr, caddr_t upper_ptr, uint8_t upper_proto, uint8_t is_frag, unsigned int src_if_index);
 int	ng_netflow_flow_show(priv_p, uint32_t last, struct ng_mesg *);
-
+void	ng_netflow_switch_version(priv_p priv, int ver, int boot);
 #endif	/* _KERNEL */
 #endif	/* _NG_NETFLOW_H_ */
diff -urN sys/modules/netgraph/netflow/Makefile.orig sys/modules/netgraph/netflow/Makefile
--- sys/modules/netgraph/netflow/Makefile.orig	2009-09-06 16:31:18.000000000 +0400
+++ sys/modules/netgraph/netflow/Makefile	2009-09-06 16:33:32.000000000 +0400
@@ -3,9 +3,19 @@
 # Author: Gleb Smirnoff <glebius@freebsd.org>
 #
 
+.include <bsd.own.mk>
+
 .PATH: ${.CURDIR}/../../../netgraph/netflow
 
 KMOD=   ng_netflow
-SRCS=   ng_netflow.c netflow.c
+SRCS=   ng_netflow.c netflow.c opt_inet6.h
+
+.if !defined(KERNBUILDDIR)
+
+.if ${MK_INET6_SUPPORT} != "no"
+opt_inet6.h:
+	echo "#define INET6 1" > ${.TARGET}
+.endif
+.endif
 
 .include <bsd.kmod.mk>
-------------- next part --------------
diff -urN sys/netgraph/netflow/netflow.c.orig sys/netgraph/netflow/netflow.c
--- sys/netgraph/netflow/netflow.c.orig	2009-01-09 23:55:26.000000000 +0300
+++ sys/netgraph/netflow/netflow.c	2009-09-06 18:51:53.000000000 +0400
@@ -30,6 +30,8 @@
 static const char rcs_id[] =
     "@(#) $FreeBSD: src/sys/netgraph/netflow/netflow.c,v 1.25.2.3 2009/01/09 20:55:26 mav Exp $";
 
+#include "opt_inet6.h"
+
 #include <sys/param.h>
 #include <sys/kernel.h>
 #include <sys/limits.h>
@@ -37,14 +39,18 @@
 #include <sys/syslog.h>
 #include <sys/systm.h>
 #include <sys/socket.h>
+#include <sys/endian.h>
 
 #include <machine/atomic.h>
+#include <machine/stdarg.h>
 
 #include <net/if.h>
 #include <net/route.h>
+#include <net/ethernet.h>
 #include <netinet/in.h>
 #include <netinet/in_systm.h>
 #include <netinet/ip.h>
+#include <netinet/ip6.h>
 #include <netinet/tcp.h>
 #include <netinet/udp.h>
 
@@ -94,12 +100,99 @@
 			 ((t) << 6) +	/* 64  */	\
 			 ((t) << 5) +	/* 32  */	\
 			 ((t) << 3))	/* 8   */
+/*
+ * Defines for different neflow version dispatchers
+ *
+ */
+static int export_add(item_p, struct flow_entry *);
+static int export_add_v9(item_p, struct flow_entry *);
+static int export_send(priv_p, item_p, int flags);
+static int export_send_v9(priv_p, item_p, int flags);
+
+typedef int (*record_add_ptr)(item_p, struct flow_entry *);
+typedef int (*record_send_ptr)(priv_p, item_p, int);
+struct _netflow_dispatchers {
+	record_add_ptr	record_add;
+	record_send_ptr	record_send;
+};
+
+static struct _netflow_dispatchers netflow_dispatcher[] =
+{
+	{ NULL, NULL },
+	{ NULL, NULL },
+	{ NULL, NULL },
+	{ NULL, NULL },
+	{ NULL, NULL },
+	{ export_add, export_send }, /* Version 5 */
+	{ NULL, NULL },
+	{ NULL, NULL },
+	{ NULL, NULL },
+	{ export_add_v9, export_send_v9 }, /* Version 9 */
+	{ NULL, NULL }
+};
+
+record_add_ptr record_add = NULL;
+record_send_ptr record_send = NULL;
 
 MALLOC_DECLARE(M_NETFLOW_HASH);
 MALLOC_DEFINE(M_NETFLOW_HASH, "netflow_hash", "NetFlow hash");
 
-static int export_add(item_p, struct flow_entry *);
-static int export_send(priv_p, item_p, int flags);
+
+static struct netflow_v9_template _netflow_v9_record_ipv4_tcp[] = 
+{
+	{ NETFLOW_V9_FIELD_IPV4_SRC_ADDR, 4},
+	{ NETFLOW_V9_FIELD_IPV4_DST_ADDR, 4},
+	{ NETFLOW_V9_FIELD_IPV4_NEXT_HOP, 4},
+	{ NETFLOW_V9_FIELD_INPUT_SNMP, 2},
+	{ NETFLOW_V9_FIELD_OUTPUT_SNMP, 2},
+	{ NETFLOW_V9_FIELD_IN_PKTS, sizeof(cntr)},
+	{ NETFLOW_V9_FIELD_IN_BYTES, sizeof(cntr)},
+	{ NETFLOW_V9_FIELD_OUT_PKTS, sizeof(cntr)},
+	{ NETFLOW_V9_FIELD_OUT_BYTES, sizeof(cntr)},
+	{ NETFLOW_V9_FIELD_FIRST_SWITCHED, 4},
+	{ NETFLOW_V9_FIELD_LAST_SWITCHED, 4},
+	{ NETFLOW_V9_FIELD_L4_SRC_PORT, 2},
+	{ NETFLOW_V9_FIELD_L4_DST_PORT, 2},
+	{ NETFLOW_V9_FIELD_TCP_FLAGS, 1},
+	{ NETFLOW_V9_FIELD_PROTOCOL, 1},
+	{ NETFLOW_V9_FIELD_TOS, 1},
+	{ NETFLOW_V9_FIELD_SRC_AS, 4},
+	{ NETFLOW_V9_FIELD_DST_AS, 4},
+	{ NETFLOW_V9_FIELD_SRC_MASK, 1},
+	{ NETFLOW_V9_FIELD_DST_MASK, 1},
+	{0, 0}
+};
+
+static struct netflow_v9_template _netflow_v9_record_ipv6_tcp[] = 
+{
+	{ NETFLOW_V9_FIELD_IPV6_SRC_ADDR, 16},
+	{ NETFLOW_V9_FIELD_IPV6_DST_ADDR, 16},
+	{ NETFLOW_V9_FIELD_IPV6_NEXT_HOP, 16},
+	{ NETFLOW_V9_FIELD_INPUT_SNMP, 2},
+	{ NETFLOW_V9_FIELD_OUTPUT_SNMP, 2},
+	{ NETFLOW_V9_FIELD_IN_PKTS, sizeof(cntr)},
+	{ NETFLOW_V9_FIELD_IN_BYTES, sizeof(cntr)},
+	{ NETFLOW_V9_FIELD_OUT_PKTS, sizeof(cntr)},
+	{ NETFLOW_V9_FIELD_OUT_BYTES, sizeof(cntr)},
+	{ NETFLOW_V9_FIELD_FIRST_SWITCHED, 4},
+	{ NETFLOW_V9_FIELD_LAST_SWITCHED, 4},
+	{ NETFLOW_V9_FIELD_L4_SRC_PORT, 2},
+	{ NETFLOW_V9_FIELD_L4_DST_PORT, 2},
+	{ NETFLOW_V9_FIELD_TCP_FLAGS, 1},
+	{ NETFLOW_V9_FIELD_PROTOCOL, 1},
+	{ NETFLOW_V9_FIELD_TOS, 1},
+	{ NETFLOW_V9_FIELD_SRC_AS, 4},
+	{ NETFLOW_V9_FIELD_DST_AS, 4},
+	{ NETFLOW_V9_FIELD_SRC_MASK, 1},
+	{ NETFLOW_V9_FIELD_DST_MASK, 1},
+	{0, 0}
+};
+
+
+static int generate_v9_templates(priv_p priv);
+
+MALLOC_DECLARE(M_NETFLOW_GENERAL);
+MALLOC_DEFINE(M_NETFLOW_GENERAL, "netflog_general", "plog, templates data");
 
 /* Generate hash for a given flow record. */
 static __inline uint32_t
@@ -108,10 +201,24 @@
 	switch (r->r_ip_p) {
 	case IPPROTO_TCP:
 	case IPPROTO_UDP:
-		return FULL_HASH(r->r_src.s_addr, r->r_dst.s_addr,
+		return FULL_HASH(r->src.r_src.s_addr, r->dst.r_dst.s_addr,
+		    r->r_sport, r->r_dport);
+	default:
+		return ADDR_HASH(r->src.r_src.s_addr, r->dst.r_dst.s_addr);
+	}
+}
+
+/* Generate hash for a given flow record. Use lower 4 octets from v6 addresses */
+static __inline uint32_t
+ip6_hash(struct flow_rec *r)
+{
+	switch (r->r_ip_p) {
+	case IPPROTO_TCP:
+	case IPPROTO_UDP:
+		return FULL_HASH(r->src.r_src6.__u6_addr.__u6_addr32[3], r->dst.r_dst6.__u6_addr.__u6_addr32[3],
 		    r->r_sport, r->r_dport);
 	default:
-		return ADDR_HASH(r->r_src.s_addr, r->r_dst.s_addr);
+		return ADDR_HASH(r->src.r_src6.__u6_addr.__u6_addr32[3], r->dst.r_dst6.__u6_addr.__u6_addr32[3]);
 	}
 }
 
@@ -126,6 +233,7 @@
 
 	atomic_add_32(&priv->info.nfinfo_used, 1);
 
+
 	return (0);
 }
 
@@ -141,6 +249,7 @@
 /*
  * Detach export datagram from priv, if there is any.
  * If there is no, allocate a new one.
+ * -- V9/IPv6 ready
  */
 static item_p
 get_export_dgram(priv_p priv)
@@ -166,14 +275,163 @@
 			return (NULL);
 		dgram = mtod(m, struct netflow_v5_export_dgram *);
 		dgram->header.count = 0;
-		dgram->header.version = htons(NETFLOW_V5);
+		dgram->header.version = htons(priv->version);
+
+		if (priv->version == NETFLOW_V9) {
+			atomic_fetchadd_32(&priv->sent_packets, 1);
+
+			/*
+			 * Let's insert mbuf tag to store some info
+			 */
+			struct netflow_v9_mbuf_tag *t;
+			struct m_tag *mt = m_tag_alloc(MTAG_NETFLOW, MTAG_NETFLOW_V9, sizeof(struct netflow_v9_mbuf_tag), M_NOWAIT);
+			if (mt == NULL) {
+				m_freem(m);
+				return (NULL);
+			}
+
+			m_tag_init(m);
+			m_tag_prepend(m, mt);
 
+			t = (struct netflow_v9_mbuf_tag *)(mt + 1);
+			t->length = sizeof(struct netflow_v9_header);
+			t->count = 0;
+			t->mtu = priv->mtu;
+			t->flow_header = t->length;
+
+			/*
+			 * Check if we need to insert templates into packet
+			 */
+			
+			struct timespec ts;
+			struct netflow_v9_flowset_header	*fl;
+
+			getnanotime(&ts);
+			if ((ts.tv_sec >= priv->templ_time + priv->templ_last_ts) || (priv->sent_packets >= priv->templ_packets + priv->templ_last_pkt)) {
+				//vlog("INSERTING TEMPLATE: ts: %lu last: %u packets: %u last: %u delay: %u", ts.tv_sec, priv->templ_last_ts, priv->sent_packets, priv->templ_last_pkt, priv->templ_time);
+				atomic_store_rel_32(&priv->templ_last_ts, ts.tv_sec);
+				atomic_store_rel_32(&priv->templ_last_pkt, priv->sent_packets);
+				//vlog("ts: %lu last_t: %u last_p: %u delay: %u", ts.tv_sec, priv->templ_last_ts, priv->templ_last_pkt, priv->templ_time);
+
+				fl = priv->v9_flowsets[0];
+				bcopy(fl, (char *)dgram + t->length, ntohs(fl->length));
+
+				t->length += ntohs(fl->length);
+				t->flow_header = t->length;
+				t->count += priv->flowset_records[0];
+			}
+		
+		}
 	}
 
 	return (item);
 }
 
 /*
+ * Pre-compiles flow exporter for all possible FlowSets
+ * so we can add flowset to packet via simple memcpy()
+ */
+#define __push(x)	*p++ = htons((x))
+static int
+generate_v9_templates(priv_p priv)
+{
+	uint16_t *p, *template_fields_cnt;
+	int cnt;
+
+	int flowset_size = sizeof(struct netflow_v9_flowset_header) +
+		_NETFLOW_V9_TEMPLATE_SIZE(_netflow_v9_record_ipv4_tcp) + /* netflow_v9_record_ipv4_tcp */
+		_NETFLOW_V9_TEMPLATE_SIZE(_netflow_v9_record_ipv6_tcp); /* netflow_v9_record_ipv6_tcp */
+
+	priv->v9_flowsets[0] = malloc(flowset_size, M_NETFLOW_GENERAL, M_WAITOK | M_ZERO);
+	if (priv->v9_flowsets[0] == NULL)
+		return (ENOMEM);
+
+
+	if (flowset_size % 4)
+		flowset_size += 4 - (flowset_size % 4); /* Padding to 4-byte boundary */
+
+	priv->flowsets_count = 1;
+	p = (uint16_t *)priv->v9_flowsets[0];
+	*p++ = 0; /* Flowset ID, 0 is reserved for Template FlowSets  */
+	*p++ = htons(flowset_size); /* Total FlowSet length */
+
+	/*
+	 * Most common TCP/UDP IPv4 template, ID = 256
+	 */
+	*p++ = htons(0x100 + NETFLOW_V9_FLOW_V4_L4);
+	template_fields_cnt = p++;
+	for (cnt = 0; _netflow_v9_record_ipv4_tcp[cnt].field_id != 0; cnt++) {
+		*p++ = htons(_netflow_v9_record_ipv4_tcp[cnt].field_id);
+		*p++ = htons(_netflow_v9_record_ipv4_tcp[cnt].field_length);
+	}
+	*template_fields_cnt = htons(cnt);
+
+	/*
+	 * TCP/UDP IPv6 template, ID = 257
+	 */
+	*p++ = htons(0x100 + NETFLOW_V9_FLOW_V6_L4);
+	template_fields_cnt = p++;
+	for (cnt = 0; _netflow_v9_record_ipv6_tcp[cnt].field_id != 0; cnt++) {
+		*p++ = htons(_netflow_v9_record_ipv6_tcp[cnt].field_id);
+		*p++ = htons(_netflow_v9_record_ipv6_tcp[cnt].field_length);
+	}
+	*template_fields_cnt = htons(cnt);
+
+
+	priv->flowset_records[0] = 2;
+	return (0);
+}
+
+/*
+ * Switches version used for netflow export
+ *
+ */
+void 
+ng_netflow_switch_version(priv_p priv, int ver, int boot)
+{
+	item_p	item = NULL;
+
+	if ((ver != NETFLOW_V9) && (ver != NETFLOW_V5))
+		return;
+
+	if ((ver == priv->version) && (boot == 0))
+		return;
+
+	/*
+	 * All new threads acquiring export datagram will wait for lock
+	 * so we can change pointers.
+	 * Existing threads with export datagram already held will call
+	 * wrong export function which will do version check at the beginning
+	 */
+
+	mtx_lock(&priv->export_mtx);
+	/* XXX: Need to be machine-independent here */
+	record_add = netflow_dispatcher[ver].record_add;
+	record_send = netflow_dispatcher[ver].record_send;
+	//atomic_store_rel_ptr((unsigned long *)record_add, (unsigned long)netflow_dispatcher[ver].record_add);
+	//atomic_store_rel_ptr((unsigned long *)record_send, (unsigned long)netflow_dispatcher[ver].record_send);
+	item = priv->export_item;
+	priv->export_item = NULL;
+	mtx_unlock(&priv->export_mtx);
+
+	if (ver == NETFLOW_V9) {
+		priv->templ_last_pkt = 0;
+		priv->templ_last_ts = 0;
+	}
+
+	//vlog("NEW: add=%p send=%p", record_add, record_send);
+
+	if (item != NULL)
+		(*netflow_dispatcher[priv->version].record_send)(priv, item, NG_NOFLAGS);
+	
+	if (boot)
+		log(LOG_DEBUG, "ng_netflow: v%d export started\n", ver);
+	else
+		log(LOG_DEBUG, "ng_netflow: export switched: v%d -> v%d\n", priv->version, ver);
+	priv->version = ver;
+}
+
+/*
  * Re-attach incomplete datagram back to priv.
  * If there is already another one, then send incomplete. */
 static void
@@ -190,13 +448,14 @@
 		mtx_unlock(&priv->export_mtx);
 	} else {
 		mtx_unlock(&priv->export_mtx);
-		export_send(priv, item, flags);
+		(*record_send)(priv, item, flags);
 	}
 }
 
 /*
  * The flow is over. Call export_add() and free it. If datagram is
  * full, then call export_send().
+ * -- v9/IPv6 nearly ready
  */
 static __inline void
 expire_flow(priv_p priv, item_p *item, struct flow_entry *fle, int flags)
@@ -208,8 +467,8 @@
 		uma_zfree_arg(priv->zone, fle, priv);
 		return;
 	}
-	if (export_add(*item, fle) > 0) {
-		export_send(priv, *item, flags);
+	if ((*record_add)(*item, fle) > 0) {
+		(*record_send)(priv, *item, flags);
 		*item = NULL;
 	}
 	uma_zfree_arg(priv->zone, fle, priv);
@@ -234,12 +493,15 @@
  * to be sure.
  */
 static __inline int
-hash_insert(priv_p priv, struct flow_hash_entry  *hsh, struct flow_rec *r,
+hash_insert(priv_p priv, struct flow_hash_entry  *hsh, struct flow_rec *r, uint16_t eproto,
 	int plen, uint8_t tcp_flags)
 {
 	struct flow_entry	*fle;
-	struct route ro;
-	struct sockaddr_in *sin;
+	struct sockaddr_in sin;
+#ifdef INET6
+	struct sockaddr_in6 sin6;
+#endif
+	struct rtentry *rt;
 
 	mtx_assert(&hsh->mtx, MA_OWNED);
 
@@ -257,6 +519,7 @@
 	bcopy(r, &fle->f.r, sizeof(struct flow_rec));
 	fle->f.bytes = plen;
 	fle->f.packets = 1;
+	fle->f.proto = eproto;
 	fle->f.tcp_flags = tcp_flags;
 
 	fle->f.first = fle->f.last = time_uptime;
@@ -265,52 +528,93 @@
 	 * First we do route table lookup on destination address. So we can
 	 * fill in out_ifx, dst_mask, nexthop, and dst_as in future releases.
 	 */
-	bzero((caddr_t)&ro, sizeof(ro));
-	sin = (struct sockaddr_in *)&ro.ro_dst;
-	sin->sin_len = sizeof(*sin);
-	sin->sin_family = AF_INET;
-	sin->sin_addr = fle->f.r.r_dst;
-	/* XXX MRT 0 as a default.. need the m here to get fib */
-	rtalloc_ign_fib(&ro, RTF_CLONING, 0);
-	if (ro.ro_rt != NULL) {
-		struct rtentry *rt = ro.ro_rt;
-
-		fle->f.fle_o_ifx = rt->rt_ifp->if_index;
-
-		if (rt->rt_flags & RTF_GATEWAY &&
-		    rt->rt_gateway->sa_family == AF_INET)
-			fle->f.next_hop =
-			    ((struct sockaddr_in *)(rt->rt_gateway))->sin_addr;
-
-		if (rt_mask(rt))
-			fle->f.dst_mask = bitcount32(((struct sockaddr_in *)
-			    rt_mask(rt))->sin_addr.s_addr);
-		else if (rt->rt_flags & RTF_HOST)
-			/* Give up. We can't determine mask :( */
-			fle->f.dst_mask = 32;
-
-		RTFREE(ro.ro_rt);
-	}
-
-	/* Do route lookup on source address, to fill in src_mask. */
-
-	bzero((caddr_t)&ro, sizeof(ro));
-	sin = (struct sockaddr_in *)&ro.ro_dst;
-	sin->sin_len = sizeof(*sin);
-	sin->sin_family = AF_INET;
-	sin->sin_addr = fle->f.r.r_src;
-	rtalloc_ign_fib(&ro, RTF_CLONING, 0); /* XXX MRT */
-	if (ro.ro_rt != NULL) {
-		struct rtentry *rt = ro.ro_rt;
-
-		if (rt_mask(rt))
-			fle->f.src_mask = bitcount32(((struct sockaddr_in *)
-			    rt_mask(rt))->sin_addr.s_addr);
-		else if (rt->rt_flags & RTF_HOST)
-			/* Give up. We can't determine mask :( */
-			fle->f.src_mask = 32;
-
-		RTFREE(ro.ro_rt);
+	if (eproto == ETHERTYPE_IP) {
+		bzero(&sin, sizeof(sin));
+		sin.sin_len = sizeof(struct sockaddr_in);
+		sin.sin_family = AF_INET;
+		sin.sin_addr = fle->f.r.dst.r_dst;
+		/* XXX MRT 0 as a default.. need the m here to get fib */
+		rt = rtalloc1_fib((struct sockaddr *)&sin, 0, 0, 0);
+		if (rt != NULL) {
+			fle->f.fle_o_ifx = rt->rt_ifp->if_index;
+	
+			if (rt->rt_flags & RTF_GATEWAY &&
+			    rt->rt_gateway->sa_family == AF_INET)
+				fle->f.n.next_hop =
+				    ((struct sockaddr_in *)(rt->rt_gateway))->sin_addr;
+	
+			if (rt_mask(rt))
+				fle->f.dst_mask = bitcount32(((struct sockaddr_in *)
+				    rt_mask(rt))->sin_addr.s_addr);
+			else if (rt->rt_flags & RTF_HOST)
+				/* Give up. We can't determine mask :( */
+				fle->f.dst_mask = 32;
+	
+			RTFREE_LOCKED(rt);
+		}
+	
+		/* Do route lookup on source address, to fill in src_mask. */
+		bzero(&sin, sizeof(sin));
+		sin.sin_len = sizeof(struct sockaddr_in);
+		sin.sin_family = AF_INET;
+		sin.sin_addr = fle->f.r.src.r_src;
+		/* XXX MRT 0 as a default  revisit.  need the mbuf for fib*/
+		rt = rtalloc1_fib((struct sockaddr *)&sin, 0, 0, 0);
+		if (rt != NULL) {
+			if (rt_mask(rt))
+				fle->f.src_mask = bitcount32(((struct sockaddr_in *)
+				    rt_mask(rt))->sin_addr.s_addr);
+			else if (rt->rt_flags & RTF_HOST)
+				/* Give up. We can't determine mask :( */
+				fle->f.src_mask = 32;
+	
+			RTFREE_LOCKED(rt);
+		}
+	} else {
+#ifdef INET6		
+		bzero(&sin6, sizeof(sin6));
+		sin6.sin6_len = sizeof(struct sockaddr_in6);
+		sin6.sin6_family = AF_INET6;
+		sin6.sin6_addr = fle->f.r.dst.r_dst6;
+		/* XXX fib works for AF_INET only */
+		rt = rtalloc1_fib((struct sockaddr *)&sin6, 0, 0, 0);
+		if (rt != NULL) {
+			fle->f.fle_o_ifx = rt->rt_ifp->if_index;
+	
+			if (rt->rt_flags & RTF_GATEWAY &&
+			    rt->rt_gateway->sa_family == AF_INET6)
+				fle->f.n.next_hop6 =
+				    ((struct sockaddr_in6 *)(rt->rt_gateway))->sin6_addr;
+			if (rt_mask(rt))
+/*	
+				fle->f.dst_mask = bitcount32(((struct sockaddr_in6 *)
+				    rt_mask(rt))->sin_addr.s_addr);
+			else if (rt->rt_flags & RTF_HOST) */
+				/* Give up. We can't determine mask :( */
+				fle->f.dst_mask = 128;
+	
+			RTFREE_LOCKED(rt);
+		}
+	
+		/* Do route lookup on source address, to fill in src_mask. */
+		bzero(&sin6, sizeof(sin6));
+		sin6.sin6_len = sizeof(struct sockaddr_in6);
+		sin6.sin6_family = AF_INET6;
+		sin6.sin6_addr = fle->f.r.src.r_src6;
+		/* XXX MRT 0 as a default  revisit.  need the mbuf for fib*/
+		rt = rtalloc1_fib((struct sockaddr *)&sin6, 0, 0, 0);
+		if (rt != NULL) {
+/*			
+			if (rt_mask(rt))
+				fle->f.src_mask = bitcount32(((struct sockaddr_in6 *)
+				    rt_mask(rt))->sin_addr.s_addr);
+			else if (rt->rt_flags & RTF_HOST) */
+				/* Give up. We can't determine mask :( */
+				fle->f.src_mask = 128;
+	
+			RTFREE_LOCKED(rt);
+		}
+#endif
 	}
 
 	/* Push new flow at the and of hash. */
@@ -354,6 +658,10 @@
 
 	mtx_init(&priv->export_mtx, "export dgram lock", NULL, MTX_DEF);
 
+	generate_v9_templates(priv);
+
+	ng_netflow_switch_version(priv, priv->version, 1);
+
 	return (0);
 }
 
@@ -366,6 +674,7 @@
 	item_p			item = NULL;
 	int i;
 
+
 	/*
 	 * We are going to free probably billable data.
 	 * Expire everything before freeing it.
@@ -378,7 +687,7 @@
 		}
 
 	if (item != NULL)
-		export_send(priv, item, NG_QUEUE);
+		(*record_send)(priv, item, NG_QUEUE);
 
 	uma_zdestroy(priv->zone);
 
@@ -390,46 +699,34 @@
 	if (priv->hash)
 		FREE(priv->hash, M_NETFLOW_HASH);
 
+	/* FreeFlow Tables */
+	for (i = 0; i < priv->flowsets_count; i++)
+		free(priv->v9_flowsets[i], M_NETFLOW_GENERAL);
+
 	mtx_destroy(&priv->export_mtx);
 }
 
-/* Insert packet from into flow cache. */
+/* 
+ * Insert packet from into flow cache. Assume size/version check passed
+ */
 int
-ng_netflow_flow_add(priv_p priv, struct ip *ip, unsigned int src_if_index)
+ng_netflow_flow_add(priv_p priv, caddr_t ip_ptr, caddr_t upper_ptr, uint8_t upper_proto, uint8_t is_frag, unsigned int src_if_index)
 {
 	register struct flow_entry	*fle, *fle1;
 	struct flow_hash_entry		*hsh;
 	struct flow_rec		r;
+	struct ip		*ip = NULL;
+#ifdef INET6
+	struct ip6_hdr		*ip6 = NULL;
+#endif
 	item_p			item = NULL;
-	int			hlen, plen;
+	int			plen;
 	int			error = 0;
 	uint8_t			tcp_flags = 0;
-
-	/* Try to fill flow_rec r */
-	bzero(&r, sizeof(r));
-	/* check version */
-	if (ip->ip_v != IPVERSION)
-		return (EINVAL);
-
-	/* verify min header length */
-	hlen = ip->ip_hl << 2;
-
-	if (hlen < sizeof(struct ip))
-		return (EINVAL);
-
-	r.r_src = ip->ip_src;
-	r.r_dst = ip->ip_dst;
-
-	/* save packet length */
-	plen = ntohs(ip->ip_len);
-
-	r.r_ip_p = ip->ip_p;
-	r.r_tos = ip->ip_tos;
-
-	r.r_i_ifx = src_if_index;
+	uint16_t		eproto;
 
 	/*
-	 * XXX NOTE: only first fragment of fragmented TCP, UDP and
+	 * XXX Fragmentation NOTE: only first fragment of fragmented TCP, UDP and
 	 * ICMP packet will be recorded with proper s_port and d_port.
 	 * Following fragments will be recorded simply as IP packet with
 	 * ip_proto = ip->ip_p and s_port, d_port set to zero.
@@ -437,22 +734,91 @@
 	 * ip packet assebmling here. Anyway, (in)famous trafd works this way -
 	 * and nobody complains yet :)
 	 */
-	if ((ip->ip_off & htons(IP_OFFMASK)) == 0)
-		switch(r.r_ip_p) {
-		case IPPROTO_TCP:
-		{
-			register struct tcphdr *tcp;
-
-			tcp = (struct tcphdr *)((caddr_t )ip + hlen);
-			r.r_sport = tcp->th_sport;
-			r.r_dport = tcp->th_dport;
-			tcp_flags = tcp->th_flags;
-			break;
+
+	/* Try to fill flow_rec r */
+	bzero(&r, sizeof(r));
+	ip = (struct ip *)ip_ptr;
+	if (ip->ip_v == IPVERSION) {
+		eproto = ETHERTYPE_IP;
+		r.src.r_src = ip->ip_src;
+		r.dst.r_dst = ip->ip_dst;
+
+		/* Assume L$ template by default */
+		r.flow_type = NETFLOW_V9_FLOW_V4_L4;
+
+		/* save packet length */
+		plen = ntohs(ip->ip_len);
+
+		r.r_tos = ip->ip_tos;
+
+		if (is_frag == 0) {
+			switch(upper_proto) {
+			case IPPROTO_TCP:
+			{
+				register struct tcphdr *tcp;
+
+				tcp = (struct tcphdr *)upper_ptr;
+				r.r_ports = *(uint32_t *)upper_ptr;
+				tcp_flags = tcp->th_flags;
+				/* r.flow_type = NETFLOW_V9_FLOW_V4_L4; */
+				break;
+			}
+			case IPPROTO_UDP:
+			case IPPROTO_SCTP:
+			{
+				r.r_ports = *(uint32_t *)upper_ptr;
+				/* r.flow_type = NETFLOW_V9_FLOW_V4_L4; */
+				break;
+			}
+
+			}
 		}
+
+	} else {
+#ifdef INET6		
+		/* IPv6 traffic */
+		ip = NULL;
+		ip6 = (struct ip6_hdr *)ip_ptr;
+		eproto = ETHERTYPE_IPV6;
+
+		r.src.r_src6 = ip6->ip6_src;
+		r.dst.r_dst6 = ip6->ip6_dst;
+
+		/* Assume L4 template by default */
+		r.flow_type = NETFLOW_V9_FLOW_V6_L4;
+
+		/* save packet length */
+		plen = ntohs(ip6->ip6_plen) + sizeof(struct ip6_hdr);
+
+		//r.r_tos = ip->ip_tos;
+
+		if (is_frag == 0) {
+			switch(upper_proto) {
+			case IPPROTO_TCP:
+			{
+				register struct tcphdr *tcp;
+
+				tcp = (struct tcphdr *)upper_ptr;
+				r.r_ports = *(uint32_t *)upper_ptr;
+				tcp_flags = tcp->th_flags;
+				/* r.flow_type = NETFLOW_V9_FLOW_V6_L4; */
+				break;
+			}
 			case IPPROTO_UDP:
-			r.r_ports = *(uint32_t *)((caddr_t )ip + hlen);
-			break;
+			case IPPROTO_SCTP:
+			{
+				r.r_ports = *(uint32_t *)upper_ptr;
+				/* r.flow_type = NETFLOW_V9_FLOW_V6_L4; */
+				break;
+			}
+
+			}
 		}
+#endif		
+	}
+
+	r.r_ip_p = upper_proto;
+	r.r_i_ifx = src_if_index;
 
 	/* Update node statistics. XXX: race... */
 	priv->info.nfinfo_packets ++;
@@ -493,7 +859,7 @@
 		 * - it is going to overflow counter
 		 */
 		if (tcp_flags & TH_FIN || tcp_flags & TH_RST || AGED(fle) ||
-		    (fle->f.bytes >= (UINT_MAX - IF_MAXMTU)) ) {
+		    (fle->f.bytes >= (cntr_max - IF_MAXMTU)) ) {
 			TAILQ_REMOVE(&hsh->head, fle, fle_hash);
 			expire_flow(priv, &item, fle, NG_QUEUE);
 			atomic_add_32(&priv->info.nfinfo_act_exp, 1);
@@ -509,7 +875,7 @@
 			}
 		}
 	} else				/* A new flow entry. */
-		error = hash_insert(priv, hsh, &r, plen, tcp_flags);
+		error = hash_insert(priv, hsh, &r, eproto, plen, tcp_flags);
 
 	mtx_unlock(&hsh->mtx);
 
@@ -618,6 +984,65 @@
 	return (error);
 }
 
+/* We have full datagram in privdata. Send it to export hook. */
+static int
+export_send_v9(priv_p priv, item_p item, int flags)
+{
+	struct mbuf *m = NGI_M(item);
+	struct netflow_v9_export_dgram *dgram = mtod(m,
+					struct netflow_v9_export_dgram *);
+	struct netflow_v9_header *header = &dgram->header;
+	struct timespec ts;
+	int error = 0;
+	uint16_t len = 0;
+
+	struct netflow_v9_mbuf_tag *t;
+	struct netflow_v9_flowset_header *fs = NULL;
+	struct m_tag *mt = m_tag_locate(m, MTAG_NETFLOW, MTAG_NETFLOW_V9, NULL);
+
+	if (mt == NULL) {
+		/* */
+		log(LOG_DEBUG, "ng_netflow: V9 export packet without tag!\n");
+		return (0);
+	}
+
+	t = (struct netflow_v9_mbuf_tag *)(mt + 1);
+
+	/* Close FlowSet if not closed */
+	if (t->length != t->flow_header) {
+		fs = (struct netflow_v9_flowset_header *)(mtod(m, char *) + t->flow_header);
+		len = (uint16_t)(t->length - t->flow_header);
+		if (len % 4) {
+			t->length += 4 - (len % 4);
+			len += 4 - (len % 4);
+		}
+		fs->length = htons(len);
+	}
+
+
+
+	/* Fill mbuf header. */
+	m->m_len = m->m_pkthdr.len = t->length;
+
+	/* Fill export header. */
+	header->count = t->count;
+	header->sys_uptime = htonl(MILLIUPTIME(time_uptime));
+	getnanotime(&ts);
+	header->unix_secs  = htonl(ts.tv_sec);
+	header->seq_num = htonl(atomic_fetchadd_32(&priv->flow_seq, 1));
+	header->count = htons(t->count);
+	header->source_id = htonl(NG_NODE_ID(priv->node));
+
+	/* remove tag */
+	m_tag_delete_chain(m, NULL);
+
+	if (priv->export != NULL)
+		NG_FWD_ITEM_HOOK_FLAGS(error, item, priv->export, flags);
+	else
+		NG_FREE_ITEM(item);
+
+	return (error);
+}
 
 /* Add export record to dgram. */
 static int
@@ -635,9 +1060,9 @@
 	    ("ng_netflow: export too big"));
 
 	/* Fill in export record. */
-	rec->src_addr = fle->f.r.r_src.s_addr;
-	rec->dst_addr = fle->f.r.r_dst.s_addr;
-	rec->next_hop = fle->f.next_hop.s_addr;
+	rec->src_addr = fle->f.r.src.r_src.s_addr;
+	rec->dst_addr = fle->f.r.dst.r_dst.s_addr;
+	rec->next_hop = fle->f.n.next_hop.s_addr;
 	rec->i_ifx    = htons(fle->f.fle_i_ifx);
 	rec->o_ifx    = htons(fle->f.fle_o_ifx);
 	rec->packets  = htonl(fle->f.packets);
@@ -661,6 +1086,135 @@
 		return (0);	
 }
 
+/* Add V9 record to dgram. */
+static int
+export_add_v9(item_p item, struct flow_entry *fle)
+{
+	size_t len = 0;
+	uint16_t new_flow = 0;
+	void *offset_ptr;
+	struct netflow_v9_mbuf_tag *t;
+	struct netflow_v9_flowset_header *fs = NULL;
+	struct mbuf *m =  NGI_M(item);
+	struct m_tag *mt = m_tag_locate(m, MTAG_NETFLOW, MTAG_NETFLOW_V9, NULL);
+
+	if (mt == NULL) {
+		/* */
+		log(LOG_DEBUG, "ng_netflow: V9 export packet without tag!\n");
+		return (0);
+	}
+
+	t = (struct netflow_v9_mbuf_tag *)(mt + 1);
+	offset_ptr = (mtod(m, char *) + t->length);
+
+	/* Check if new records has the same template */
+	if (fle->f.r.flow_type != t->flow_type) {
+		new_flow = 1;
+		
+		/* 'Close' old FlowSet */
+		fs = (struct netflow_v9_flowset_header *)(mtod(m, char *) + t->flow_header);
+		len = (uint16_t)(t->length - t->flow_header);
+		if (len % 4) {
+			t->length += 4 - (len % 4);
+			len += 4 - (len % 4);
+		}
+		fs->length = htons(len);
+
+		/* Prepare 'new', but do not modify any counters here because switch can fail */
+		t->flow_type = NETFLOW_V9_FLOW_FAKE;
+		t->flow_header = t->length;
+		fs = (struct netflow_v9_flowset_header *)(mtod(m, char *) + t->length);
+		offset_ptr = (fs + 1);
+	}
+
+
+	switch (fle->f.r.flow_type) {
+	case NETFLOW_V9_FLOW_V4_L4:
+	{
+		/* IPv4 TCP/UDP/[SCTP] */
+		struct netflow_v9_record_ipv4_tcp *rec = (struct netflow_v9_record_ipv4_tcp *)offset_ptr;
+
+		
+		rec->src_addr = fle->f.r.src.r_src.s_addr;
+		rec->dst_addr = fle->f.r.dst.r_dst.s_addr;
+		rec->next_hop = fle->f.n.next_hop.s_addr;
+		rec->i_ifx    = htons(fle->f.fle_i_ifx);
+		rec->o_ifx    = htons(fle->f.fle_o_ifx);
+		rec->i_packets  = htonl(fle->f.packets);
+		rec->i_octets   = htonl(fle->f.bytes);
+		rec->o_packets  = htonl(0);
+		rec->o_octets   = htonl(0);
+		rec->first    = htonl(MILLIUPTIME(fle->f.first));
+		rec->last     = htonl(MILLIUPTIME(fle->f.last));
+		rec->s_port   = fle->f.r.r_sport;
+		rec->d_port   = fle->f.r.r_dport;
+		rec->flags    = fle->f.tcp_flags;
+		rec->prot     = fle->f.r.r_ip_p;
+		rec->tos      = fle->f.r.r_tos;
+		rec->dst_mask = fle->f.dst_mask;
+		rec->src_mask = fle->f.src_mask;
+
+		/* Not supported fields. */
+		rec->src_as = rec->dst_as = 0;
+
+		len = sizeof(struct netflow_v9_record_ipv4_tcp);
+		break;
+	}
+#ifdef INET6	
+	case NETFLOW_V9_FLOW_V6_L4:
+	{
+		/* IPv6 TCP/UDP/[SCTP] */
+		struct netflow_v9_record_ipv6_tcp *rec = (struct netflow_v9_record_ipv6_tcp *)offset_ptr;
+
+		/* ACHTUNG! unchecked code! */
+		rec->src_addr = fle->f.r.src.r_src6;
+		rec->dst_addr = fle->f.r.dst.r_dst6;
+		rec->next_hop = fle->f.n.next_hop6;
+		rec->i_ifx    = htons(fle->f.fle_i_ifx);
+		rec->o_ifx    = htons(fle->f.fle_o_ifx);
+		rec->i_packets  = htonl(fle->f.packets);
+		rec->i_octets   = htonl(fle->f.bytes);
+		rec->first    = htonl(MILLIUPTIME(fle->f.first));
+		rec->last     = htonl(MILLIUPTIME(fle->f.last));
+		rec->s_port   = fle->f.r.r_sport;
+		rec->d_port   = fle->f.r.r_dport;
+		rec->flags    = fle->f.tcp_flags;
+		rec->prot     = fle->f.r.r_ip_p;
+		rec->tos      = fle->f.r.r_tos;
+		rec->dst_mask = fle->f.dst_mask;
+		rec->src_mask = fle->f.src_mask;
+
+		/* Not supported fields. */
+		rec->src_as = rec->dst_as = 0;
+
+		len = sizeof(struct netflow_v9_record_ipv6_tcp);
+		break;
+	}
+#endif	
+	default:
+	{
+		log(LOG_DEBUG, "ng_netflow: Don't know what to do with %d flow type!\n", fle->f.r.flow_type);
+		return (0);
+	}
+	}
+
+	if (new_flow) {
+		/* Generate data segment ID */
+		fs->id = htons(0x100 + fle->f.r.flow_type);
+		t->flow_type = fle->f.r.flow_type;
+		t->length += sizeof(struct netflow_v9_flowset_header);
+	}
+
+	t->length += len;
+	t->count++;
+
+	if (t->length + NETFLOW_V9_MAX_RECORD_SIZE + 4 >= _NETFLOW_V9_MAX_SIZE(t->mtu))
+		return (1); /* end of datagram */
+	else
+		return (0);
+}
+
+
 /* Periodic flow expiry run. */
 void
 ng_netflow_expire(void *arg)
diff -urN sys/netgraph/netflow/ng_netflow.c.orig sys/netgraph/netflow/ng_netflow.c
--- sys/netgraph/netflow/ng_netflow.c.orig	2009-01-09 23:55:26.000000000 +0300
+++ sys/netgraph/netflow/ng_netflow.c	2009-09-06 18:38:40.000000000 +0400
@@ -30,6 +30,8 @@
 static const char rcs_id[] =
     "@(#) $FreeBSD: src/sys/netgraph/netflow/ng_netflow.c,v 1.14.2.4 2009/01/09 20:55:26 mav Exp $";
 
+#include "opt_inet6.h"
+
 #include <sys/param.h>
 #include <sys/systm.h>
 #include <sys/kernel.h>
@@ -48,8 +50,11 @@
 #include <netinet/in.h>
 #include <netinet/in_systm.h>
 #include <netinet/ip.h>
+#include <netinet/ip6.h>
+#include <netinet/ip6.h>
 #include <netinet/tcp.h>
 #include <netinet/udp.h>
+#include <netinet/sctp.h>
 
 #include <netgraph/ng_message.h>
 #include <netgraph/ng_parse.h>
@@ -114,6 +119,30 @@
 	&ng_netflow_setconfig_type_fields
 };
 
+/* Parse type for ng_netflow_setversion */
+static const struct ng_parse_struct_field ng_netflow_setversion_type_fields[]
+	= NG_NETFLOW_SETVERSION_TYPE;
+static const struct ng_parse_type ng_netflow_setversion_type = {
+	&ng_parse_struct_type,
+	&ng_netflow_setversion_type_fields
+};
+
+/* Parse type for ng_netflow_settemplateperiodic */
+static const struct ng_parse_struct_field ng_netflow_settemplateperiodic_type_fields[]
+	= NG_NETFLOW_SETTEMPLATEPERIODIC_TYPE;
+static const struct ng_parse_type ng_netflow_settemplateperiodic_type = {
+	&ng_parse_struct_type,
+	&ng_netflow_settemplateperiodic_type_fields
+};
+
+/* Parse type for ng_netflow_setmtu */
+static const struct ng_parse_struct_field ng_netflow_setmtu_type_fields[]
+	= NG_NETFLOW_SETMTU_TYPE;
+static const struct ng_parse_type ng_netflow_setmtu_type = {
+	&ng_parse_struct_type,
+	&ng_netflow_setmtu_type_fields
+};
+
 /* List of commands and how to convert arguments to/from ASCII */
 static const struct ng_cmdlist ng_netflow_cmds[] = {
        {
@@ -158,6 +187,27 @@
 	&ng_netflow_setconfig_type,
 	NULL
        },
+       {
+	NGM_NETFLOW_COOKIE,
+	NGM_NETFLOW_SETVERSION,
+	"setversion",
+	&ng_netflow_setversion_type,
+	NULL
+       },
+       {
+	NGM_NETFLOW_COOKIE,
+	NGM_NETFLOW_SETTEMPLATEPERIODIC,
+	"settemplateperiodic",
+	&ng_netflow_settemplateperiodic_type,
+	NULL
+       },
+       {
+	NGM_NETFLOW_COOKIE,
+	NGM_NETFLOW_SETMTU,
+	"setmtu",
+	&ng_netflow_setmtu_type,
+	NULL
+       },
        { 0 }
 };
 
@@ -202,6 +252,13 @@
 	for (i = 0; i < NG_NETFLOW_MAXIFACES; i++)
 		priv->ifaces[i].info.conf = NG_NETFLOW_CONF_INGRESS;
 
+	/* Set v9 defaults */
+	priv->version = NETFLOW_V9;
+	priv->templ_time = NETFLOW_V9_MAX_TIME_TEMPL;
+	priv->templ_packets = NETFLOW_V9_MAX_PACKETS_TEMPL;
+	priv->mtu = BASE_MTU;
+	priv->flow_seq = 0;
+
 	/* Initialize callout handle */
 	callout_init(&priv->exp_callout, CALLOUT_MPSAFE);
 
@@ -434,6 +491,52 @@
 	
 			break;
 		}
+		case NGM_NETFLOW_SETVERSION:
+		{
+			struct ng_netflow_setversion *set;
+
+			if (msg->header.arglen != sizeof(struct ng_netflow_setversion))
+				ERROUT(EINVAL);
+
+			set = (struct ng_netflow_setversion *)msg->data;
+			if ((set->version != NETFLOW_V9) && (set->version != NETFLOW_V5))
+				ERROUT(EINVAL);
+
+			ng_netflow_switch_version(priv, set->version, 0);
+
+			break;
+		}
+		case NGM_NETFLOW_SETTEMPLATEPERIODIC:
+		{
+			struct ng_netflow_settemplateperiodic *set;
+
+			if (msg->header.arglen != sizeof(struct ng_netflow_settemplateperiodic))
+				ERROUT(EINVAL);
+
+			set = (struct ng_netflow_settemplateperiodic *)msg->data;
+
+			/* XXX: Set atomic here */
+			priv->templ_packets = set->packets;
+			priv->templ_time = set->time;
+
+			break;
+		}
+		case NGM_NETFLOW_SETMTU:
+		{
+			struct ng_netflow_setmtu *set;
+
+			if (msg->header.arglen != sizeof(struct ng_netflow_setmtu))
+				ERROUT(EINVAL);
+
+			set = (struct ng_netflow_setmtu *)msg->data;
+			if ((set->mtu < MIN_MTU) || (set->mtu > MAX_MTU))
+				ERROUT(EINVAL);
+
+			/* XXX: Set atomic here */
+			priv->mtu = set->mtu;
+
+			break;
+		}
 		case NGM_NETFLOW_SHOW:
 		{
 			uint32_t *last;
@@ -481,12 +584,15 @@
 	const priv_p priv = NG_NODE_PRIVATE(node);
 	const iface_p iface = NG_HOOK_PRIVATE(hook);
 	hook_p out;
-	struct mbuf *m = NULL;
-	struct ip *ip;
+	struct mbuf *m, *m_old = NULL;
+	struct ip *ip = NULL;
+	struct ip6_hdr *ip6 = NULL;
 	struct m_tag *mtag;
-	int pullup_len = 0;
+	int pullup_len = 0, off = 0;
+	uint8_t upper_proto = 0, is_frag = 0;
 	int error = 0, bypass = 0;
 	unsigned int src_if_index;
+	caddr_t upper_ptr = NULL;
 
 	if (hook == priv->export) {
 		/*
@@ -541,6 +647,7 @@
 	}
 
 	NGI_GET_M(item, m);
+	m_old = m;
 
 	/* Increase counters. */
 	iface->info.ifinfo_packets++;
@@ -569,6 +676,22 @@
 	}							\
 } while (0)
 
+/*	
+#define	M_HCHECK(length)	do {				\
+	pullup_len += length + sizeof(ip6_ext);			\
+	if ((m)->m_pkthdr.len < (pullup_len)) {			\
+		pullup_len -= length + sizeof(ip6_ext);
+		M_CHECK(length);
+		`
+	} 							\
+	if ((m)->m_len < (pullup_len) &&			\
+	   (((m) = m_pullup((m),(pullup_len))) == NULL)) {	\
+		error = ENOBUFS;				\
+		goto done;					\
+	}							\
+} while (0)
+*/
+
 	switch (iface->info.ifinfo_dlt) {
 	case DLT_EN10MB:	/* Ethernet */
 	    {
@@ -586,6 +709,33 @@
 			eh = mtod(m, struct ether_header *);
 			ip = (struct ip *)(eh + 1);
 			break;
+#ifdef INET6			
+		case ETHERTYPE_IPV6:
+			/* 
+			 * This is done not to pullup mbuf twice on every ext
+			 * header 
+			 */
+			pullup_len += sizeof(struct ip6_hdr) + sizeof(struct ip6_ext);
+			if (m->m_pkthdr.len >= pullup_len) {
+				if ((m = m_pullup(m, pullup_len)) == NULL) {
+					error = ENOBUFS;
+					goto done;
+				}
+				pullup_len -= sizeof(struct ip6_ext);
+			} else {
+				pullup_len -= sizeof(struct ip6_hdr) + sizeof(struct ip6_ext);
+				M_CHECK(sizeof(struct ip6_hdr));
+				eh = mtod(m, struct ether_header *);
+				ip6 = (struct ip6_hdr *)(eh + 1);
+				if (ip6->ip6_nxt != IPPROTO_NONE) {
+					error = EINVAL;
+					goto bypass;
+				}
+			}
+			eh = mtod(m, struct ether_header *);
+			ip6 = (struct ip6_hdr *)(eh + 1);
+			break;
+#endif			
 		case ETHERTYPE_VLAN:
 		    {
 			struct ether_vlan_header *evh;
@@ -597,6 +747,29 @@
 				M_CHECK(sizeof(struct ip));
 				ip = (struct ip *)(evh + 1);
 				break;
+			} else if (ntohs(evh->evl_proto) == ETHERTYPE_IPV6) {
+#ifdef INET6				
+				pullup_len += sizeof(struct ip6_hdr) + sizeof(struct ip6_ext);
+				if (m->m_pkthdr.len >= pullup_len) {
+					if ((m = m_pullup(m, pullup_len)) == NULL) {
+						error = ENOBUFS;
+						goto done;
+					}
+					pullup_len -= sizeof(struct ip6_ext);
+				} else {
+					pullup_len -= sizeof(struct ip6_hdr) + sizeof(struct ip6_ext);
+					M_CHECK(sizeof(struct ip6_hdr));
+					eh = mtod(m, struct ether_header *);
+					ip6 = (struct ip6_hdr *)(eh + 1);
+					if (ip6->ip6_nxt != IPPROTO_NONE) {
+						error = EINVAL;
+						goto bypass;
+					}
+				}
+				eh = mtod(m, struct ether_header *);
+				ip6 = (struct ip6_hdr *)(eh + 1);
+				break;
+#endif				
 			}
 		    }
 		default:
@@ -607,18 +780,32 @@
 	case DLT_RAW:		/* IP packets */
 		M_CHECK(sizeof(struct ip));
 		ip = mtod(m, struct ip *);
+#ifdef INET6		
+		if (ip->ip_v == 6) {
+			/* IPv6 packet */
+			ip = NULL;
+			M_CHECK(sizeof(struct ip6_hdr));
+			ip6 = mtod(m, struct ip6_hdr *);
+		}
+#endif		
 		break;
 	default:
 		goto bypass;
 		break;
 	}
 
-	if ((ip->ip_off & htons(IP_OFFMASK)) == 0) {
+	if ((ip != NULL) && ((ip->ip_off & htons(IP_OFFMASK)) == 0)) {
+		if ((ip->ip_v != IPVERSION) || 
+		    ((ip->ip_hl << 2) < sizeof(struct ip)))
+			goto bypass;
 		/*
-		 * In case of IP header with options, we haven't pulled
+		 * In case of IPv4 header with options, we haven't pulled
 		 * up enough, yet.
 		 */
 		pullup_len += (ip->ip_hl << 2) - sizeof(struct ip);
+		off = pullup_len;
+		//vlog("upper_offset = %d", off);
+		upper_proto = ip->ip_p;
 
 		switch (ip->ip_p) {
 		case IPPROTO_TCP:
@@ -627,38 +814,161 @@
 		case IPPROTO_UDP:
 			M_CHECK(sizeof(struct udphdr));
 			break;
+		case IPPROTO_SCTP:
+			M_CHECK(sizeof(struct sctphdr));
+			break;
 		}
-	}
+	} else if (ip != NULL) {
+		is_frag = 1;
+		upper_proto = ip->ip_p;
+		if ((ip->ip_v != IPVERSION) || 
+		    ((ip->ip_hl << 2) < sizeof(struct ip)))
+			goto bypass;
+	} else if (ip6 != NULL) {
+#ifdef INET6		
+		/* Check if we can export */
+		if (priv->version < NETFLOW_V9)
+			goto bypass;
+
+		/* Loop thru IPv6 extended headers to get upper layer header / frag */
+		int cur = ip6->ip6_nxt, hdr_off = 0;
+		struct ip6_ext *ip6e;
+		struct ip6_frag *ip6f;
+
+		off = pullup_len;
+		upper_proto = cur;
+
+		if ((ip6->ip6_vfc & IPV6_VERSION_MASK) != IPV6_VERSION)
+			goto bypass;
+
+		while (42) {
+
+			/*
+			 * At the moment we're 'standing' with pullup_len and
+			 * off 
+			 */
+			switch (cur) {
+
+			/* Ensure pointer is contiguous */
+			case IPPROTO_TCP:
+				M_CHECK(sizeof(struct tcphdr));
+				goto loopend;
+			case IPPROTO_UDP:
+				M_CHECK(sizeof(struct udphdr));
+				goto loopend;
+			case IPPROTO_SCTP:
+				M_CHECK(sizeof(struct sctphdr));
+				goto loopend;
+
+			/* Loop until 'real' upper layer headers */
+			case IPPROTO_HOPOPTS:
+			case IPPROTO_ROUTING:
+			case IPPROTO_DSTOPTS:
+				ip6e = (struct ip6_ext *)(mtod(m, caddr_t) + off);
+				upper_proto = ip6e->ip6e_nxt;
+				hdr_off = (ip6e->ip6e_len + 1) << 3;
+				break;
 
-	switch (iface->info.ifinfo_dlt) {
-	case DLT_EN10MB:
-	    {
-		struct ether_header *eh;
+			/* RFC4302, can be before DSTOPTS */
+			case IPPROTO_AH:
+				ip6e = (struct ip6_ext *)(mtod(m, caddr_t) + off);
+				upper_proto = ip6e->ip6e_nxt;
+				hdr_off = (ip6e->ip6e_len + 2) << 2;
+				break;
 
-		eh = mtod(m, struct ether_header *);
-		switch (ntohs(eh->ether_type)) {
-		case ETHERTYPE_IP:
-			ip = (struct ip *)(eh + 1);
-			break;
-		case ETHERTYPE_VLAN:
-		    {
-			struct ether_vlan_header *evh;
+			
+			case IPPROTO_FRAGMENT:
+				ip6f = (struct ip6_frag *)(mtod(m, caddr_t) + off);
+				upper_proto = ip6f->ip6f_nxt;
+				hdr_off = sizeof(struct ip6_frag);
+				off += hdr_off;
+				is_frag = 1;
+				goto loopend;
+
+/*				
+			case IPPROTO_NONE:
+				goto loopend;
+*/
+			default:
+				goto loopend;
+			}
 
-			evh = mtod(m, struct ether_vlan_header *);
-			ip = (struct ip *)(evh + 1);
+			off += hdr_off + sizeof(struct ip6_ext);
+			cur = upper_proto;
+			if (m->m_pkthdr.len >= off) {
+				if ((m = m_pullup(m, off)) == NULL) {
+					error = ENOBUFS;
+					goto done;
+				}
+				off -= sizeof(struct ip6_ext);
+				pullup_len += hdr_off;
+			} else {
+				/*
+				 * Packet ends somewhere here.
+				 * if its next header is not IPPROTO_NONE it is
+				 * possibly mailformed packet. Let's count as RAW IP
+				 */
+				upper_proto = IPPROTO_NONE;
+				off -= sizeof(struct ip6_ext);
+				goto loopend;
+			}
+
+		}
+#endif
+	}
+
+#ifdef INET6
+loopend:
+#endif
+	if (m != m_old) {
+		switch (iface->info.ifinfo_dlt) {
+		case DLT_EN10MB:	/* Ethernet */
+		    {
+			struct ether_header *eh;
+	
+			eh = mtod(m, struct ether_header *);
+			switch (ntohs(eh->ether_type)) {
+			case ETHERTYPE_IP:
+				ip = (struct ip *)(eh + 1);
+				break;
+			case ETHERTYPE_IPV6:
+				ip6 = (struct ip6_hdr *)(eh + 1);
+				break;
+			case ETHERTYPE_VLAN:
+			    {
+				struct ether_vlan_header *evh;
+	
+				evh = mtod(m, struct ether_vlan_header *);
+				if (ntohs(evh->evl_proto) == ETHERTYPE_IP) {
+					ip = (struct ip *)(evh + 1);
+					break;
+				} else if (ntohs(evh->evl_proto) == ETHERTYPE_IPV6) {
+#ifdef INET6					
+					ip6 = (struct ip6_hdr *)(evh + 1);
+					break;
+#endif					
+				}
+			    }
+			default:
+				panic("ng_netflow entered deadcode");
+			}
+			break;
+		    }
+		case DLT_RAW:		/* IP packets */
+			ip = mtod(m, struct ip *);
+#ifdef INET6			
+			if (ip->ip_v == 6) {
+				/* IPv6 packet */
+				ip = NULL;
+				ip6 = mtod(m, struct ip6_hdr *);
+			}
+#endif			
 			break;
-		     }
 		default:
 			panic("ng_netflow entered deadcode");
 		}
-		break;
-	     }
-	case DLT_RAW:
-		ip = mtod(m, struct ip *);
-		break;
-	default:
-		panic("ng_netflow entered deadcode");
 	}
+	upper_ptr = (caddr_t)(mtod(m, caddr_t) + off);
 
 #undef	M_CHECK
 
@@ -670,7 +980,7 @@
 	} else
 		src_if_index = iface->info.ifinfo_index;
 
-	error = ng_netflow_flow_add(priv, ip, src_if_index);
+	error = ng_netflow_flow_add(priv, (ip != NULL) ? (caddr_t)ip : (caddr_t)ip6, upper_ptr, upper_proto, is_frag, src_if_index);
 
 bypass:
 	if (out != NULL) {
diff -urN sys/netgraph/_netflow.orig/netflow.h sys/netgraph/netflow/netflow.h
--- sys/netgraph/_netflow.orig/netflow.h	2009-09-01 02:37:44.000000000 +0400
+++ sys/netgraph/netflow/netflow.h	2009-09-06 12:41:29.000000000 +0400
@@ -46,6 +46,7 @@
 
 #define NETFLOW_V1 1
 #define NETFLOW_V5 5
+#define NETFLOW_V9 9
 
 struct netflow_v1_header
 {
@@ -69,6 +70,16 @@
   uint16_t pad;		/* Pad to word boundary */
 } __attribute__((__packed__));
 
+struct netflow_v9_header
+{
+  uint16_t version;	/* NetFlow version */
+  uint16_t count;	/* Total number of records in packet */
+  uint32_t sys_uptime;	/* System uptime */
+  uint32_t unix_secs;	/* Current seconds since 0000 UTC 1970 */
+  uint32_t seq_num;	/* Sequence number */
+  uint32_t source_id;	/* Observation Domain id */
+} __attribute__((__packed__));
+
 struct netflow_v1_record
 {
   uint32_t src_addr;	/* Source IP address */
@@ -115,6 +126,142 @@
   uint16_t pad2;	/* Pad to word boundary */
 } __attribute__((__packed__));
 
+
+
+/* RFC3954 field definitions */
+#define NETFLOW_V9_FIELD_IN_BYTES	1	/* Input bytes count for a flow. Default 4, can be 8 */
+#define NETFLOW_V9_FIELD_IN_PKTS	2	/* Incoming counter with number of packets associated with an IP Flow. Default 4 */
+#define NETFLOW_V9_FIELD_FLOWS		3	/* Number of Flows that were aggregated. Default 4 */
+#define NETFLOW_V9_FIELD_PROTOCOL	4	/* IP protocol byte. 1 */
+#define NETFLOW_V9_FIELD_TOS		5	/* Type of service byte setting when entering the incoming interface. 1 */
+#define NETFLOW_V9_FIELD_TCP_FLAGS	6	/* TCP flags; cumulative of all the TCP flags seen in this Flow. 1 */
+#define NETFLOW_V9_FIELD_L4_SRC_PORT	7	/* TCP/UDP source port number. 2 */
+#define NETFLOW_V9_FIELD_IPV4_SRC_ADDR	8	/* IPv4 source address. 4 */
+#define NETFLOW_V9_FIELD_SRC_MASK	9	/* The number of contiguous bits in the source subnet mask (i.e., the mask in slash notation). 1 */
+#define NETFLOW_V9_FIELD_INPUT_SNMP	10	/* Input interface index. Default 2 */
+#define NETFLOW_V9_FIELD_L4_DST_PORT	11	/* TCP/UDP destination port number. 2 */
+#define NETFLOW_V9_FIELD_IPV4_DST_ADDR	12	/* IPv4 destination address. 4 */
+#define NETFLOW_V9_FIELD_DST_MASK	13	/* The number of contiguous bits in the destination subnet mask (i.e., the mask in slash notation). 1 */
+#define NETFLOW_V9_FIELD_OUTPUT_SNMP	14	/* Output interface index. Default 2 */
+#define NETFLOW_V9_FIELD_IPV4_NEXT_HOP	15	/* IPv4 address of the next-hop router. 4 */
+#define NETFLOW_V9_FIELD_SRC_AS		16	/* Source BGP autonomous system number. Default 2, can be 4 */
+#define NETFLOW_V9_FIELD_DST_AS		17	/* Destination BGP autonomous system number. Default 2, can be 4 */
+#define NETFLOW_V9_FIELD_BGP_IPV4_NEXT_HOP	18	/* Next-hop router's IP address in the BGP domain. 4 */
+#define NETFLOW_V9_FIELD_MUL_DST_PKTS	19	/* IP multicast outgoing packet counter for packets associated with IP flow. Default 4 */
+#define NETFLOW_V9_FIELD_MUL_DST_BYTES	20	/* IP multicast outgoing Octet (byte) counter for the number of bytes associated with IP flow. Default 4 */
+#define NETFLOW_V9_FIELD_LAST_SWITCHED	21	/* sysUptime in msec at which the last packet of this Flow was switched. 4 */
+#define NETFLOW_V9_FIELD_FIRST_SWITCHED	22	/* sysUptime in msec at which the first packet of this Flow was switched. 4 */
+#define NETFLOW_V9_FIELD_OUT_BYTES	23	/* Outgoing counter for the number of bytes associated with an IP Flow. Default 4 */
+#define NETFLOW_V9_FIELD_OUT_PKTS	24	/* Outgoing counter for the number of packets associated with an IP Flow. Default 4 */
+#define NETFLOW_V9_FIELD_IPV6_SRC_ADDR	27	/* IPv6 source address. 16 */
+#define NETFLOW_V9_FIELD_IPV6_DST_ADDR	28	/* IPv6 destination address. 16 */
+#define NETFLOW_V9_FIELD_IPV6_SRC_MASK	29	/* Length of the IPv6 source mask in contiguous bits. 1 */
+#define NETFLOW_V9_FIELD_IPV6_DST_MASK	30	/* Length of the IPv6 destination mask in contiguous bits. 1 */
+#define NETFLOW_V9_FIELD_IPV6_FLOW_LABEL	31	/* IPv6 flow label as per RFC 2460 definition. 3 */
+#define NETFLOW_V9_FIELD_ICMP_TYPE	32	/* Internet Control Message Protocol (ICMP) packet type; reported as ICMP Type * 256 + ICMP code. 2 */
+#define NETFLOW_V9_FIELD_MUL_IGMP_TYPE	33	/* Internet Group Management Protocol (IGMP) packet type. 1 */
+#define NETFLOW_V9_FIELD_SAMPLING_INTERVAL	34	/* When using sampled NetFlow, the rate at which packets are sampled; for example, a value of 100 indicates that one of every hundred packets is sampled. 4 */
+#define NETFLOW_V9_FIELD_SAMPLING_ALGORITHM	35	/* For sampled NetFlow platform-wide: 0x01 deterministic sampling 0x02 random sampling. 1 */
+#define NETFLOW_V9_FIELD_FLOW_ACTIVE_TIMEOUT	36	/* Timeout value (in seconds) for active flow entries in the NetFlow cache. 2 */
+#define NETFLOW_V9_FIELD_FLOW_INACTIVE_TIMEOUT	37	/* Timeout value (in seconds) for inactive Flow entries in the NetFlow cache. 2 */
+#define NETFLOW_V9_FIELD_ENGINE_TYPE	38	/* Type of Flow switching engine (route processor, linecard, etc...). 1 */
+#define NETFLOW_V9_FIELD_ENGINE_ID	39	/* ID number of the Flow switching engine. 1 */
+#define NETFLOW_V9_FIELD_TOTAL_BYTES_EXP	40	/* Counter with for the number of bytes exported by the Observation Domain. Default 4 */
+#define NETFLOW_V9_FIELD_TOTAL_PKTS_EXP	41	/* Counter with for the number of packets exported by the Observation Domain. Default 4 */
+#define NETFLOW_V9_FIELD_TOTAL_FLOWS_EXP	42	/* Counter with for the number of flows exported by the Observation Domain. Default 4 */
+#define NETFLOW_V9_FIELD_MPLS_TOP_LABEL_TYPE	46	/* MPLS Top Label Type. 1 */
+#define NETFLOW_V9_FIELD_MPLS_TOP_LABEL_IP_ADDR	47	/* Forwarding Equivalent Class corresponding to the MPLS Top Label. 4 */
+#define NETFLOW_V9_FIELD_FLOW_SAMPLER_ID	48	/* Identifier shown in "show flow-sampler". 1 */
+#define NETFLOW_V9_FIELD_FLOW_SAMPLER_MODE	49	/* The type of algorithm used for sampling data. 2 */
+#define NETFLOW_V9_FIELD_FLOW_SAMPLER_RANDOM_INTERVAL	50	/* Packet interval at which to sample. 4. */
+#define NETFLOW_V9_FIELD_DST_TOS	55	/* Type of Service byte setting when exiting outgoing interface. 1. */
+#define NETFLOW_V9_FIELD_SRC_MAC	56	/* Source MAC Address. 6 */
+#define NETFLOW_V9_FIELD_DST_MAC	57	/* Destination MAC Address. 6 */
+#define NETFLOW_V9_FIELD_SRC_VLAN	58	/* Virtual LAN identifier associated with ingress interface. 2 */
+#define NETFLOW_V9_FIELD_DST_VLAN	59	/* irtual LAN identifier associated with egress interface. 2 */
+#define NETFLOW_V9_FIELD_IP_PROTOCOL_VERSION	60	/* Internet Protocol Version. Set to 4 for IPv4, set to 6 for IPv6. If not present in the template, then version 4 is assumed. 1. */
+#define NETFLOW_V9_FIELD_DIRECTION	61	/* Flow direction: 0 - ingress flow 1 - egress flow. 1 */
+#define NETFLOW_V9_FIELD_IPV6_NEXT_HOP	62	/* IPv6 address of the next-hop router. 16 */
+#define NETFLOW_V9_FIELD_BGP_IPV6_NEXT_HOP	63	/* Next-hop router in the BGP domain. 16 */
+#define NETFLOW_V9_FIELD_IPV6_OPTION_HEADERS	64	/* Bit-encoded field identifying IPv6 option headers found in the flow */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_1	70	/* MPLS label at position 1 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_2	71	/* MPLS label at position 2 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_3	72	/* MPLS label at position 3 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_4	73	/* MPLS label at position 4 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_5	74	/* MPLS label at position 5 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_6	75	/* MPLS label at position 6 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_7	76	/* MPLS label at position 7 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_8	77	/* MPLS label at position 8 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_9	78	/* MPLS label at position 9 in the stack. 3 */
+#define NETFLOW_V9_FIELD_MPLS_LABEL_10	79	/* MPLS label at position 10 in the stack. 3 */
+
+#ifdef COUNTERS_64
+#define cntr		uint64_t
+#define cntr_max	UINT64_MAX
+#else
+#define cntr		uint32_t
+#define cntr_max	UINT_MAX
+#endif
+
+struct netflow_v9_template
+{
+	int	field_id;
+	int	field_length;
+};
+
+/* Template ID for tcp/udp v4 streams ID:257 (0x100 + NETFLOW_V9_FLOW_V4_L4) */
+struct netflow_v9_record_ipv4_tcp
+{
+  uint32_t src_addr;	/* Source IPv4 address (IPV4_SRC_ADDR) */
+  uint32_t dst_addr;	/* Destination IPv4 address (IPV4_DST_ADDR) */
+  uint32_t next_hop;	/* Next hop IPv4 address (IPV4_NEXT_HOP) */  
+  uint16_t i_ifx;	/* Source interface index (INPUT_SNMP) */
+  uint16_t o_ifx;	/* Destination interface index (OUTPUT_SNMP) */
+  cntr i_packets;	/* Number of incoming packets in a flow (IN_PKTS) */
+  cntr i_octets;	/* Number of incoming octets in a flow (IN_BYTES) */
+  cntr o_packets;	/* Number of outgoing packets in a flow (OUT_PKTS) */
+  cntr o_octets;	/* Number of outgoing octets in a flow (OUT_BYTES) */
+  uint32_t first;	/* System uptime at start of a flow (FIRST_SWITCHED) */
+  uint32_t last;	/* System uptime at end of a flow (LAST_SWITCHED) */
+  uint16_t s_port;	/* Source port (L4_SRC_PORT) */
+  uint16_t d_port;	/* Destination port (L4_DST_PORT) */
+  uint8_t flags;	/* Cumulative OR of tcp flags (TCP_FLAGS) */
+  uint8_t prot;		/* IP protocol */
+  uint8_t tos;		/* IP type of service IN (or OUT) (TOS) */
+  uint32_t src_as;	/* Src peer/origin Autonomous System (SRC_AS) */  
+  uint32_t dst_as;	/* Dst peer/origin Autonomous System (DST_AS) */
+  uint8_t src_mask;	/* Source route's mask bits (SRC_MASK) */
+  uint8_t dst_mask; 	/* Destination route's mask bits (DST_MASK) */
+} __attribute__((__packed__));
+
+
+/* Template ID for tcp/udp v6 streams ID: 260 (0x100 + NETFLOW_V9_FLOW_V6_L4) */
+struct netflow_v9_record_ipv6_tcp
+{
+  struct in6_addr src_addr;	/* Source IPv6 address (IPV6_SRC_ADDR) */
+  struct in6_addr dst_addr;	/* Destination IPv6 address (IPV6_DST_ADDR) */
+  struct in6_addr next_hop;	/* Next hop IPv6 address (IPV6_NEXT_HOP) */  
+  uint16_t i_ifx;	/* Source interface index (INPUT_SNMP) */
+  uint16_t o_ifx;	/* Destination interface index (OUTPUT_SNMP) */
+  cntr i_packets;	/* Number of incoming packets in a flow (IN_PKTS) */
+  cntr i_octets;	/* Number of incoming octets in a flow (IN_BYTES) */
+  cntr o_packets;	/* Number of outgoing packets in a flow (OUT_PKTS) */
+  cntr o_octets;	/* Number of outgoing octets in a flow (OUT_BYTES) */
+  uint32_t first;	/* System uptime at start of a flow (FIRST_SWITCHED) */
+  uint32_t last;	/* System uptime at end of a flow (LAST_SWITCHED) */
+  uint16_t s_port;	/* Source port (L4_SRC_PORT) */
+  uint16_t d_port;	/* Destination port (L4_DST_PORT) */
+  uint8_t flags;	/* Cumulative OR of tcp flags (TCP_FLAGS) */
+  uint8_t prot;		/* IP protocol */
+  uint8_t tos;		/* IP type of service IN (or OUT) (TOS) */
+  uint32_t src_as;	/* Src peer/origin Autonomous System (SRC_AS) */  
+  uint32_t dst_as;	/* Dst peer/origin Autonomous System (DST_AS) */
+  uint8_t src_mask;	/* Source route's mask bits (SRC_MASK) */
+  uint8_t dst_mask; 	/* Destination route's mask bits (DST_MASK) */
+} __attribute__((__packed__));
+
+#define vlog(x, ...)	log(LOG_DEBUG, "%s:%d " x "\n", __FUNCTION__, __LINE__, ##__VA_ARGS__)
+
 #define NETFLOW_V1_MAX_RECORDS 24
 #define NETFLOW_V5_MAX_RECORDS 30
 
@@ -123,7 +270,50 @@
 #define NETFLOW_V5_MAX_SIZE (sizeof(netflow_v5_header)+ \
 			     sizeof(netflow_v5_record)*NETFLOW_V5_MAX_RECORDS)
 
+#define BASE_MTU	1500
+#define MIN_MTU		sizeof(struct netflow_v5_header)
+#define MAX_MTU		16384
+#define NETFLOW_V9_MAX_SIZE	_NETFLOW_V9_MAX_SIZE(BASE_MTU)
+#define _NETFLOW_V9_MAX_SIZE(x)	(x) - sizeof(struct ip6_hdr) - sizeof(struct udphdr)
+#define NETFLOW_V9_MAX_FLOWSETS	2
+
+#define NETFLOW_V9_MAX_RECORD_SIZE	sizeof(struct netflow_v9_record_ipv6_tcp)
+#define NETFLOW_V9_MAX_PACKETS_TEMPL	500	/* Send data templates every ... packets */
+#define NETFLOW_V9_MAX_TIME_TEMPL	600	/* Send data templates every ... seconds */
+#define NETFLOW_V9_MAX_TEMPLATES	16	/* Not a real value */
+#define _NETFLOW_V9_TEMPLATE_SIZE(x)	(sizeof(x) / sizeof(struct netflow_v9_template)) * 4
+//#define _NETFLOW_V9_TEMPLATE_SIZE(x)	((x) + 1) * 4
+
+/* Flow Templates */
+#define NETFLOW_V9_FLOW_V4_L4	1 /* IPv4 TCP/UDP packet */
+#define NETFLOW_V9_FLOW_V4_ICMP	2 /* IPv4 ICMP packet, currently unused */
+#define NETFLOW_V9_FLOW_V4_L3	3 /* IPv4 IP packet */
+#define NETFLOW_V9_FLOW_V6_L4	4 /* IPv6 TCP/UDP packet */
+#define NETFLOW_V9_FLOW_V6_ICMP	5 /* IPv6 ICMP packet, currently unused */
+#define NETFLOW_V9_FLOW_V6_L3	6 /* IPv6 IP packet */
+
+#define NETFLOW_V9_FLOW_FAKE	65535 /* Not uset used in real flowsets! */
+
 struct netflow_v5_export_dgram {
 	struct netflow_v5_header	header;
 	struct netflow_v5_record	r[NETFLOW_V5_MAX_RECORDS];
 } __attribute__((__packed__));
+
+struct netflow_v9_export_dgram {
+	struct netflow_v9_header	header;
+	char				data; /* MTU can change, record length is dynamic */
+};
+
+struct netflow_v9_flowset_header {
+	uint16_t	id; /* FlowSet id */
+	uint16_t	length; /* FlowSet length */
+} __attribute__((__packed__));
+
+struct netflow_v9_mbuf_tag {
+	struct m_tag	tag; /* pointer to mbuf tag */
+	uint16_t	length; /* Current packet length */
+	uint16_t	count; /* current records count */
+	uint16_t	mtu; /* max MTU shapshot */
+	uint16_t	flow_type; /* current flowset */
+	uint16_t	flow_header; /* offset pointing to current flow header */
+};
diff -urN sys/netgraph/_netflow.orig/ng_netflow.h sys/netgraph/netflow/ng_netflow.h
--- sys/netgraph/_netflow.orig/ng_netflow.h	2009-09-01 02:37:44.000000000 +0400
+++ sys/netgraph/netflow/ng_netflow.h	2009-09-06 16:36:17.000000000 +0400
@@ -51,6 +51,9 @@
     NGM_NETFLOW_SETIFINDEX	= 5, 	/* set interface index */
     NGM_NETFLOW_SETTIMEOUTS	= 6, 	/* set active/inactive flow timeouts */
     NGM_NETFLOW_SETCONFIG	= 7, 	/* set flow generation options */
+    NGM_NETFLOW_SETVERSION	= 8, 	/* set flow export version  */
+    NGM_NETFLOW_SETTEMPLATEPERIODIC	= 9, 	/* set v9 flow template periodic */
+    NGM_NETFLOW_SETMTU		= 10, 	/* set outgoing interface MTU */
 };
 
 /* This structure is returned by the NGM_NETFLOW_INFO message */
@@ -105,10 +108,34 @@
 	u_int32_t conf;			/* new config */
 };
 
+/* This structure is passed to NGM_NETFLOW_SETVERSION */
+struct ng_netflow_setversion {
+	u_int8_t version;		/* netflow version */
+};
+
+/* This structure is passed to NGM_NETFLOW_SETTEMPLATEPERIODIC */
+struct ng_netflow_settemplateperiodic {
+	u_int16_t time;		/* max time between announce */
+	u_int16_t packets;	/* max packets between announce */
+};
+
+/* This structure is passed to NGM_NETFLOW_SETMTU */
+struct ng_netflow_setmtu {
+	u_int16_t mtu;		/* MTU for packet */
+};
+
 /* This is unique data, which identifies flow */
 struct flow_rec {
-	struct in_addr	r_src;
-	struct in_addr	r_dst;
+	uint16_t	flow_type; /* IPv4 L4/L3 Ipv6 L4/L3 flow, see NETFLOW_V9_FLOW* */
+	uint16_t	ether_proto; /* unused */
+	union {
+		struct in_addr	r_src;
+		struct in6_addr	r_src6;
+	} src;
+	union {
+		struct in_addr	r_dst;
+		struct in6_addr	r_dst6;
+	} dst;
 	union {
 		struct {
 			uint16_t	s_port;	/* source TCP/UDP port */
@@ -137,7 +164,10 @@
 /* A flow entry which accumulates statistics */
 struct flow_entry_data {
 	struct flow_rec		r;
-	struct in_addr		next_hop;
+	union {
+		struct in_addr		next_hop;
+		struct in6_addr		next_hop6;
+	} n;
 	uint16_t		fle_o_ifx;	/* output interface index */
 #define				fle_i_ifx	r.misc.i.i_ifx
 	uint8_t		dst_mask;	/* destination route mask bits */
@@ -146,6 +176,7 @@
 	u_long			bytes;
 	long			first;	/* uptime on first packet */
 	long			last;	/* uptime on last packet */
+	uint16_t		proto; /* IP/IPv6 */
 	u_char			tcp_flags;	/* cumulative OR */
 };
 
@@ -227,6 +258,26 @@
 	{ NULL }					\
 }
 
+/* Parse the setversion structure */
+#define	NG_NETFLOW_SETVERSION_TYPE {			\
+	{ "version",	&ng_parse_uint8_type },		\
+	{ NULL }					\
+}
+
+/* Parse the settemplateperiodic structure */
+#define	NG_NETFLOW_SETTEMPLATEPERIODIC_TYPE {			\
+	{ "time",	&ng_parse_uint16_type },		\
+	{ "packets",	&ng_parse_uint16_type },		\
+	{ NULL }					\
+}
+
+/* Parse the setmtu structure */
+#define	NG_NETFLOW_SETMTU_TYPE {			\
+	{ "mtu",	&ng_parse_uint16_type },		\
+	{ NULL }					\
+}
+
+
 /* Private hook data */
 struct ng_netflow_iface {
 	hook_p		hook;		/* NULL when disconnected */
@@ -270,6 +321,20 @@
 	item_p			export_item;
 	struct mtx		export_mtx;
 	uint32_t		flow_seq;	/* current flow sequence */
+	/* 
+	 * RFC 3954 clause 7.3
+	 * "Both options MUST be configurable by the user on the Exporter."
+	 */
+	uint16_t		templ_time;	/* time between sending templates */
+	uint16_t		templ_packets;	/* packets between sending templates */
+	uint32_t		templ_last_ts;	/* unixtime of last template announce */
+	uint32_t		templ_last_pkt;	/* packets count on last template announce */
+	uint32_t		sent_packets;	/* packets sent by exporeter; can be reached another way ? */
+	u_char			version;	/* Netflow export version */
+	u_char			flowsets_count; /* current flowsets used */
+	u_char			flowset_records[NETFLOW_V9_MAX_FLOWSETS - 1]; /* Count of records in each flowset */
+	uint16_t		mtu;		/* export interface MTU */
+	struct netflow_v9_flowset_header	*v9_flowsets[NETFLOW_V9_MAX_FLOWSETS - 1]; /* Pointers to pre-compiled flowsets */
 
 	struct ng_netflow_iface	ifaces[NG_NETFLOW_MAXIFACES];
 };
@@ -286,14 +351,15 @@
 
 #define MTAG_NETFLOW		1221656444
 #define MTAG_NETFLOW_CALLED	0
+#define MTAG_NETFLOW_V9		1
 
 /* Prototypes for netflow.c */
 int	ng_netflow_cache_init(priv_p);
 void	ng_netflow_cache_flush(priv_p);
 void	ng_netflow_copyinfo(priv_p, struct ng_netflow_info *);
 timeout_t ng_netflow_expire;
-int	ng_netflow_flow_add(priv_p, struct ip *, unsigned int src_if_index);
+int	ng_netflow_flow_add(priv_p, caddr_t ip_ptr, caddr_t upper_ptr, uint8_t upper_proto, uint8_t is_frag, unsigned int src_if_index);
 int	ng_netflow_flow_show(priv_p, uint32_t last, struct ng_mesg *);
-
+void	ng_netflow_switch_version(priv_p priv, int ver, int boot);
 #endif	/* _KERNEL */
 #endif	/* _NG_NETFLOW_H_ */
diff -urN sys/modules/netgraph/netflow/Makefile.orig sys/modules/netgraph/netflow/Makefile
--- sys/modules/netgraph/netflow/Makefile.orig	2009-09-06 16:31:18.000000000 +0400
+++ sys/modules/netgraph/netflow/Makefile	2009-09-06 16:33:32.000000000 +0400
@@ -3,9 +3,19 @@
 # Author: Gleb Smirnoff <glebius@freebsd.org>
 #
 
+.include <bsd.own.mk>
+
 .PATH: ${.CURDIR}/../../../netgraph/netflow
 
 KMOD=   ng_netflow
-SRCS=   ng_netflow.c netflow.c
+SRCS=   ng_netflow.c netflow.c opt_inet6.h
+
+.if !defined(KERNBUILDDIR)
+
+.if ${MK_INET6_SUPPORT} != "no"
+opt_inet6.h:
+	echo "#define INET6 1" > ${.TARGET}
+.endif
+.endif
 
 .include <bsd.kmod.mk>
From grarpamp at gmail.com  Sun Sep  6 22:31:53 2009
From: grarpamp at gmail.com (grarpamp)
Date: Sun Sep  6 22:31:59 2009
Subject: Call for testers: ng_netflow with v9 and IPv6 support
Message-ID: <d2e731a10909061511q35447425s6cec18460fb48bd1@mail.gmail.com>

Wouldn't it be better to support the obvious formal emergent standards
track protocol instead of the legacy informational one? Or to perform
both via sysctl or other arguments/defines, with the standard IPFIX
being the default mode? Have you reviewed the nProbe code for other
various ideas? Thanks for working on netflow :) And any form of v6
is good to have finally.

=========================================================================

Network Working Group                                     B. Claise, Ed.
Request for Comments: 5101                           Cisco Systems, Inc.
Category: Standards Track                                   January 2008
Specification of the IP Flow Information Export (IPFIX) Protocol
for the Exchange of IP Traffic Flow Information
   This document specifies an Internet standards track protocol for the
   Internet community


Network Working Group                                         J. Quittek
Request for Comments: 5102                                           NEC
Category: Standards Track                                      S. Bryant
                                                               B. Claise
                                                               P. Aitken
                                                     Cisco Systems, Inc.
                                                                J. Meyer
                                                                  PayPal
                                                            January 2008
Information Model for IP Flow Information Export
   This document specifies an Internet standards track protocol for the
   Internet community


Network Working Group                                        B. Trammell
Request for Comments: 5103                                    CERT/NetSA
Category: Standards Track                                      E. Boschi
                                                          Hitachi Europe
                                                            January 2008
Bidirectional Flow Export Using IP Flow Information Export (IPFIX)
   This document specifies an Internet standards track protocol for the
   Internet community


Network Working Group                                          E. Boschi
Request for Comments: 5153                                Hitachi Europe
Category: Informational                                          L. Mark
                                                        Fraunhofer FOKUS
                                                              J. Quittek
                                                          M. Stiemerling
                                                                     NEC
                                                               P. Aitken
                                                     Cisco Systems, Inc.
                                                              April 2008
IP Flow Information Export (IPFIX) Implementation Guidelines
   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.


Network Working Group                                          S. Leinen
Request for Comments: 3955                                        SWITCH
Category: Informational                                     October 2004
Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)
   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.


Network Working Group                                         J. Quittek
Request for Comments: 3917                               NEC Europe Ltd.
Category: Informational                                         T. Zseby
                                                        Fraunhofer FOKUS
                                                               B. Claise
                                                           Cisco Systems
                                                               S. Zander
                                                    Swinburne University
                                                            October 2004
Requirements for IP Flow Information Export (IPFIX)
   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.


And others...

=========================================================================

Network Working Group                                     B. Claise, Ed.
Request for Comments: 3954                                 Cisco Systems
Category: Informational                                     October 2004
            Cisco Systems NetFlow Services Export Version 9
   This RFC documents the NetFlow services export protocol Version 9 as
   it was when submitted to the IETF as a basis for further work in the
   IPFIX WG.
   This RFC itself is not a candidate for any level of Internet
   Standard.  The IETF disclaims any knowledge of the fitness of this
   RFC for any purpose...

And others...

=========================================================================
From julian at elischer.org  Mon Sep  7 01:25:25 2009
From: julian at elischer.org (Julian Elischer)
Date: Mon Sep  7 01:25:57 2009
Subject: Call for testers: ng_netflow with v9 and IPv6 support
In-Reply-To: <d2e731a10909061511q35447425s6cec18460fb48bd1@mail.gmail.com>
References: <d2e731a10909061511q35447425s6cec18460fb48bd1@mail.gmail.com>
Message-ID: <4AA46103.9000108@elischer.org>

grarpamp wrote:
> Wouldn't it be better to support the obvious formal emergent standards
> track protocol instead of the legacy informational one? Or to perform
> both via sysctl or other arguments/defines, with the standard IPFIX
> being the default mode? Have you reviewed the nProbe code for other
> various ideas? Thanks for working on netflow :) And any form of v6
> is good to have finally.

if you have time it sounds like you know enough about it to be 
useful.. get involved :-)


> 
> =========================================================================
> 
> Network Working Group                                     B. Claise, Ed.
> Request for Comments: 5101                           Cisco Systems, Inc.
> Category: Standards Track                                   January 2008
> Specification of the IP Flow Information Export (IPFIX) Protocol
> for the Exchange of IP Traffic Flow Information
>    This document specifies an Internet standards track protocol for the
>    Internet community
> 
> 
> Network Working Group                                         J. Quittek
> Request for Comments: 5102                                           NEC
> Category: Standards Track                                      S. Bryant
>                                                                B. Claise
>                                                                P. Aitken
>                                                      Cisco Systems, Inc.
>                                                                 J. Meyer
>                                                                   PayPal
>                                                             January 2008
> Information Model for IP Flow Information Export
>    This document specifies an Internet standards track protocol for the
>    Internet community
> 
> 
> Network Working Group                                        B. Trammell
> Request for Comments: 5103                                    CERT/NetSA
> Category: Standards Track                                      E. Boschi
>                                                           Hitachi Europe
>                                                             January 2008
> Bidirectional Flow Export Using IP Flow Information Export (IPFIX)
>    This document specifies an Internet standards track protocol for the
>    Internet community
> 
> 
> Network Working Group                                          E. Boschi
> Request for Comments: 5153                                Hitachi Europe
> Category: Informational                                          L. Mark
>                                                         Fraunhofer FOKUS
>                                                               J. Quittek
>                                                           M. Stiemerling
>                                                                      NEC
>                                                                P. Aitken
>                                                      Cisco Systems, Inc.
>                                                               April 2008
> IP Flow Information Export (IPFIX) Implementation Guidelines
>    This memo provides information for the Internet community.  It does
>    not specify an Internet standard of any kind.
> 
> 
> Network Working Group                                          S. Leinen
> Request for Comments: 3955                                        SWITCH
> Category: Informational                                     October 2004
> Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)
>    This memo provides information for the Internet community.  It does
>    not specify an Internet standard of any kind.
> 
> 
> Network Working Group                                         J. Quittek
> Request for Comments: 3917                               NEC Europe Ltd.
> Category: Informational                                         T. Zseby
>                                                         Fraunhofer FOKUS
>                                                                B. Claise
>                                                            Cisco Systems
>                                                                S. Zander
>                                                     Swinburne University
>                                                             October 2004
> Requirements for IP Flow Information Export (IPFIX)
>    This memo provides information for the Internet community.  It does
>    not specify an Internet standard of any kind.
> 
> 
> And others...
> 
> =========================================================================
> 
> Network Working Group                                     B. Claise, Ed.
> Request for Comments: 3954                                 Cisco Systems
> Category: Informational                                     October 2004
>             Cisco Systems NetFlow Services Export Version 9
>    This RFC documents the NetFlow services export protocol Version 9 as
>    it was when submitted to the IETF as a basis for further work in the
>    IPFIX WG.
>    This RFC itself is not a candidate for any level of Internet
>    Standard.  The IETF disclaims any knowledge of the fitness of this
>    RFC for any purpose...
> 
> And others...
> 
> =========================================================================
> _______________________________________________
> 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 bugmaster at FreeBSD.org  Mon Sep  7 11:07:05 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Sep  7 11:09:07 2009
Subject: Current problem reports assigned to freebsd-net@FreeBSD.org
Message-ID: <200909071107.n87B74p7010317@freefall.freebsd.org>

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/138427  net        [wpi] [panic] Kernel panic after trying set monitor wl
o kern/138407  net        [gre] gre(4) interface does not come up after reboot
o kern/138390  net        [gif] [patch] NULL pointer dereference in gif_input() 
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/113432  net        [ucom] WARNING: attempt to net_add_domain(netgraph) af
o kern/112722  net        [ipsec] [udp] IP v4 udp fragmented packet reject
o kern/112686  net        [patm] patm driver freezes System (FreeBSD 6.2-p4) i38
o kern/112570  net        [bge] packet loss with bge driver on BCM5704 chipset
o bin/112557   net        [patch] ppp(8) lock file should not use symlink name
o kern/112528  net        [nfs] NFS over TCP under load hangs with "impossible p
o kern/111457  net        [ral] ral(4) freeze
o kern/110140  net        [ipw] ipw fails under load
o kern/109733  net        [bge] bge link state issues [regression]
o kern/109470  net        [wi] Orinoco Classic Gold PC Card Can't Channel Hop
o kern/109308  net        [pppd] [panic] Multiple panics kernel ppp suspected [r
o kern/109251  net        [re] [patch] if_re cardbus card won't attach
o bin/108895   net        pppd(8): PPPoE dead connections on 6.2 [regression]
o kern/108542  net        [bce] Huge network latencies with 6.2-RELEASE / STABLE
o kern/107944  net        [wi] [patch] Forget to unlock mutex-locks
o kern/107850  net        [bce] bce driver link negotiation is faulty
o conf/107035  net        [patch] bridge(8): bridge interface given in rc.conf n
o kern/106438  net        [ipf] ipfilter: keep state does not seem to allow repl
o kern/106316  net        [dummynet] dummynet with multipass ipfw drops packets 
o kern/106243  net        [nve] double fault panic in if_nve.c on high loads
o kern/105945  net        Address can disappear from network interface
s kern/105943  net        Network stack may modify read-only mbuf chain copies
o bin/105925   net        problems with ifconfig(8) and vlan(4) [regression]
o kern/105348  net        [ath] ath device stopps TX
o kern/104851  net        [inet6] [patch] On link routes not configured when usi
o kern/104751  net        [netgraph] kernel panic, when getting info about my tr
o kern/104485  net        [bge] Broadcom BCM5704C: Intermittent on newer chip ve
o kern/103191  net        Unpredictable reboot
o kern/103135  net        [ipsec] ipsec with ipfw divert (not NAT) encodes a pac
o conf/102502  net        [netgraph] [patch] ifconfig name does't rename netgrap
o kern/102035  net        [plip] plip networking disables parallel port printing
o kern/101948  net        [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau
o kern/100709  net        [libc] getaddrinfo(3) should return TTL info
o kern/100519  net        [netisr] suggestion to fix suboptimal network polling
o kern/98978   net        [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel
o kern/98597   net        [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu
o bin/98218    net        wpa_supplicant(8) blacklist not working
f bin/97392    net        ppp(8) hangs instead terminating
o kern/97306   net        [netgraph] NG_L2TP locks after connection with failed 
f kern/96268   net        [socket] TCP socket performance drops by 3000% if pack
o kern/96030   net        [bfe] [patch] Install hangs with Broadcomm 440x NIC in
o kern/95519   net        [ral] ral0 could not map mbuf
o kern/95288   net        [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr
o kern/95277   net        [netinet] [patch] IP Encapsulation mask_match() return
o kern/95267   net        packet drops periodically appear
s kern/94863   net        [bge] [patch] hack to get bge(4) working on IBM e326m
o kern/94162   net        [bge] 6.x kenel stale with bge(4)
o kern/93886   net        [ath] Atheros/D-Link DWL-G650 long delay to associate 
f kern/93378   net        [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo
o kern/93019   net        [ppp] ppp and tunX problems: no traffic after restarti
o kern/92880   net        [libc] [patch] almost rewritten inet_network(3) functi
f kern/92552   net        A serious bug in most network drivers from 5.X to 6.X 
s kern/92279   net        [dc] Core faults everytime I reboot, possible NIC issu
o kern/92090   net        [bge] bge0: watchdog timeout -- resetting
o kern/91859   net        [ndis] if_ndis does not work with Asus WL-138
s kern/91777   net        [ipf] [patch] wrong behaviour with skip rule inside an
o kern/91594   net        [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10
o kern/91364   net        [ral] [wep] WF-511 RT2500 Card PCI and WEP
o kern/91311   net        [aue] aue interface hanging
o kern/90890   net        [vr] Problems with network: vr0: tx shutdown timeout
s kern/90086   net        [hang] 5.4p8 on supermicro P8SCT hangs during boot if 
f kern/88082   net        [ath] [panic] cts protection for ath0 causes panic
o kern/87521   net        [ipf] [panic] using ipfilter "auth" keyword leads to k
o kern/87506   net        [vr] [patch] Fix alias support on vr interfaces
s kern/86920   net        [ndis] ifconfig: SIOCS80211: Invalid argument [regress
o kern/86103   net        [ipf] Illegal NAT Traversal in IPFilter
o kern/85780   net        'panic: bogus refcnt 0' in routing/ipv6
o bin/85445    net        ifconfig(8): deprecated keyword to ifconfig inoperativ
o kern/85266   net        [xe] [patch] xe(4) driver does not recognise Xircom XE
o kern/84202   net        [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre
o bin/82975    net        route change does not parse classfull network as given
o kern/82497   net        [vge] vge(4) on AMD64 only works when loaded late, not
f kern/81644   net        [vge] vge(4) does not work properly when loaded as a K
s kern/81147   net        [net] [patch] em0 reinitialization while adding aliase
o kern/80853   net        [ed] [patch] add support for Compex RL2000/ISA in PnP 
o kern/79895   net        [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph 
f kern/79262   net        [dc] Adaptec ANA-6922 not fully supported
o bin/79228    net        [patch] extend arp(8) to be able to create blackhole r
o kern/78090   net        [ipf] ipf filtering on bridged packets doesn't work if
p kern/77913   net        [wi] [patch] Add the APDL-325 WLAN pccard to wi(4)
o kern/77341   net        [ip6] problems with IPV6 implementation
o kern/77273   net        [ipf] ipfilter breaks ipv6 statefull filtering on 5.3
s kern/77195   net        [ipf] [patch] ipfilter ioctl SIOCGNATL does not match 
o kern/75873   net        Usability problem with non-RFC-compliant IP spoof prot
s kern/75407   net        [an] an(4): no carrier after short time
f kern/73538   net        [bge] problem with the Broadcom BCM5788 Gigabit Ethern
o kern/71469   net        default route to internet magically disappears with mu
o kern/70904   net        [ipf] ipfilter ipnat problem with h323 proxy support
o kern/64556   net        [sis] 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

335 problems total.

From wjw at digiware.nl  Mon Sep  7 11:40:17 2009
From: wjw at digiware.nl (Willem Jan Withagen)
Date: Mon Sep  7 11:40:24 2009
Subject: UDP output performance
In-Reply-To: <5bc218350909041002x670460c8nf202a714182d1bf6@mail.gmail.com>
References: <4AA14018.3010102@digiware.nl>
	<5bc218350909041002x670460c8nf202a714182d1bf6@mail.gmail.com>
Message-ID: <4AA4F11C.4060200@digiware.nl>

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.
> 
> 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?
> 
> Oh, also, what kind of machine are you running on?

Well this turns out to be a pilot error, in that I created such a complex 
bandwidth evaluation that on buffer full the packet got tossed in the 
application.
:(

Just stripping that out, and just do a

try send
while(not send) {
	usleep(1 packet-time);
	try again;
}
	
Reduced my packet loss to < 0.1% and I'm able to squeeze a nice > 900 Mbit/s 
  out of a single em(4) port. Still no packets begin dropped in netstat -i.

So now I'm off hunting for 'bugs' in snmp, cacti, mrtg to see why they don't 
like the counters. Even when I'm using the 64bit counters I get really spiky 
  bandwidth results. Equal to those when using 32 bits counters, so 
certainly things are not as I think they are.

Other thing is to see how Lin* is performing on this test.
So trying to install ubuntu 9.04.

--WjW
From mike at sentex.net  Mon Sep  7 13:39:08 2009
From: mike at sentex.net (Mike Tancsa)
Date: Mon Sep  7 13:39:15 2009
Subject: UDP output performance
In-Reply-To: <4AA4F11C.4060200@digiware.nl>
References: <4AA14018.3010102@digiware.nl>
	<5bc218350909041002x670460c8nf202a714182d1bf6@mail.gmail.com>
	<4AA4F11C.4060200@digiware.nl>
Message-ID: <200909071301.n87D1kqY062913@lava.sentex.ca>

At 07:40 AM 9/7/2009, Willem Jan Withagen wrote:

>Well this turns out to be a pilot error, in that I created such a 
>complex bandwidth evaluation that on buffer full the packet got 
>tossed in the application.
>:(
>
>Just stripping that out, and just do a
>
>try send
>while(not send) {
>         usleep(1 packet-time);
>         try again;
>}

There are some nice simples tool in /usr/src/tools/tools/netrate that 
are great for generating arbitrary bandwidth via udp packets you 
might want to have a look at.

         ---Mike


>
>Reduced my packet loss to < 0.1% and I'm able to squeeze a nice > 
>900 Mbit/s  out of a single em(4) port. Still no packets begin 
>dropped in netstat -i.
>
>So now I'm off hunting for 'bugs' in snmp, cacti, mrtg to see why 
>they don't like the counters. Even when I'm using the 64bit counters 
>I get really spiky  bandwidth results. Equal to those when using 32 
>bits counters, so certainly things are not as I think they are.
>
>Other thing is to see how Lin* is performing on this test.
>So trying to install ubuntu 9.04.
>
>--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"

--------------------------------------------------------------------
Mike Tancsa,                                      tel +1 519 651 3400
Sentex Communications,                            mike@sentex.net
Providing Internet since 1994                    www.sentex.net
Cambridge, Ontario Canada                         www.sentex.net/mike

From wjw at digiware.nl  Mon Sep  7 13:49:19 2009
From: wjw at digiware.nl (Willem Jan Withagen)
Date: Mon Sep  7 13:49:26 2009
Subject: UDP output performance
In-Reply-To: <200909071301.n87D1kqY062913@lava.sentex.ca>
References: <4AA14018.3010102@digiware.nl>
	<5bc218350909041002x670460c8nf202a714182d1bf6@mail.gmail.com>
	<4AA4F11C.4060200@digiware.nl>
	<200909071301.n87D1kqY062913@lava.sentex.ca>
Message-ID: <4AA50F5B.1080600@digiware.nl>

Mike Tancsa wrote:
> At 07:40 AM 9/7/2009, Willem Jan Withagen wrote:
> 
>> Well this turns out to be a pilot error, in that I created such a 
>> complex bandwidth evaluation that on buffer full the packet got tossed 
>> in the application.
>> :(
>>
>> Just stripping that out, and just do a
>>
>> try send
>> while(not send) {
>>         usleep(1 packet-time);
>>         try again;
>> }
> 
> There are some nice simples tool in /usr/src/tools/tools/netrate that 
> are great for generating arbitrary bandwidth via udp packets you might 
> want to have a look at.

Thanx Mike, I'll have a look. Always better well copied, than badly self 
invented. (free to an old dutch proverb). :)

Reason I'm home growing, is that these tests are for really specific 
applications we're developing.
And the actual purpose is to find hardware combo's that will do UDP packets 
a fast at we can get it out of the ports.
Preferably with a 10Gbit card at close to 10Gb/s.

But thus far I'm only getting the intel hardware on 1Gbit close to the line 
max. But I've got several boards still to test.

As I side note:
If anybody had experience with 10Gb hardware, I would appreciate 
recommandations for that as well.

One of the piexes of hardware I'm currently evaluating is:
Which does a nice job, with 2mbit udp in on em0 and 1Gbit udp out on port em6.

--WjW
From dyr at homelink.ru  Mon Sep  7 14:35:45 2009
From: dyr at homelink.ru (Dennis Yusupoff)
Date: Mon Sep  7 14:54:46 2009
Subject: Call for testers: ng_netflow with v9 and IPv6 support
In-Reply-To: <4AA46103.9000108@elischer.org>
References: <d2e731a10909061511q35447425s6cec18460fb48bd1@mail.gmail.com>
	<4AA46103.9000108@elischer.org>
Message-ID: <1116202669.20090907115455@homelink.ru>

By the way, what's about this one:

---
     The ng_netflow node type does not fill in AS numbers.  This is due to the
     lack of necessary information in the kernel routing table.  However, this
     information can be injected into the kernel from a routing daemon such as
     GNU Zebra.  This functionality may become available in future releases.
---

Is any chance to see it in, for example, 8.0?


-- 
? ?????????,
 ????????? ????????????? 
 Ozerki.Net/Cifracom.Ru
 ?????? ?????                           mailto:dyr@homelink.ru

From gnn at neville-neil.com  Mon Sep  7 16:33:57 2009
From: gnn at neville-neil.com (George Neville-Neil)
Date: Mon Sep  7 16:34:04 2009
Subject: Crash in ether_input
In-Reply-To: <20090904223123.GD16213@hal.rescomp.berkeley.edu>
References: <20090904223123.GD16213@hal.rescomp.berkeley.edu>
Message-ID: <723505E9-96C6-401C-A844-3D9BA2033795@neville-neil.com>


On Sep 4, 2009, at 18:31 , Chris Cowart wrote:

> 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.
>
> 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.
>
> From uname:
>
> | 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:
> |
> | Fatal trap 27: stack fault while in kernel mode
> | cpuid = 0; apic id = 00
> | instruction pointer     = 0x8:0xffffffff80559fb4
> | stack pointer           = 0x10:0xffffffffae39faf0
> | frame pointer           = 0x10:0xf85ecc37f9239402
> | code segment            = base 0x0, limit 0xfffff, type 0x1b
> |                         = DPL 0, pres 1, long 1, def32 0, gran 1
> | processor eflags        = interrupt enabled, resume, IOPL = 0
> | current process         = 27 (em0 taskq)
> | trap number             = 27
> | panic: stack fault
> | cpuid = 0
> | Uptime: 43m44s
> | Physical memory: 4082 MB
> | Dumping 361 MB: 346 330 314 298 282 266 250 234 218 202em0:  
> watchdog timeout -- resetting
>
> | (kgdb) bt
> | #0  doadump () at pcpu.h:195
> | #1  0x0000000000000004 in ?? ()
> | #2  0xffffffff804bd9b9 in boot (howto=260) at /usr/src/sys/kern/ 
> kern_shutdown.c:418
> | #3  0xffffffff804bddc2 in panic (fmt=0x104 <Address 0x104 out of  
> bounds>) at /usr/src/sys/kern/kern_shutdown.c:574
> | #4  0xffffffff807b9f23 in trap_fatal (frame=0xffffff00012d66e0,  
> eva=Variable "eva" is not available.
> | ) at /usr/src/sys/amd64/amd64/trap.c:764
> | #5  0xffffffff807baa75 in trap (frame=0xffffffffae39fa40) at /usr/ 
> src/sys/amd64/amd64/trap.c:565
> | #6  0xffffffff807a042e in calltrap () at /usr/src/sys/amd64/amd64/ 
> exception.S:209
> | #7  0xffffffff80559fb4 in ether_input (ifp=0xffffff00012bf000,  
> m=0xffffff0003576000) at /usr/src/sys/net/if_ethersubr.c:545
> | #8  0xffffffff802bd645 in em_rxeof (adapter=0xffffffff80e4c000,  
> count=99) at /usr/src/sys/dev/e1000/if_em.c:4539
> | #9  0xffffffff802be55e in em_handle_rxtx (context=Variable  
> "context" is not available.
> | ) at /usr/src/sys/dev/e1000/if_em.c:1702
> | #10 0xffffffff804f2afd in taskqueue_run (queue=0xffffff00012c8c80)  
> at /usr/src/sys/kern/subr_taskqueue.c:282
> | #11 0xffffffff804f2da6 in taskqueue_thread_loop (arg=Variable  
> "arg" is not available.
> | ) at /usr/src/sys/kern/subr_taskqueue.c:401
> | #12 0xffffffff8049b2f3 in fork_exit (callout=0xffffffff804f2d40  
> <taskqueue_thread_loop>, arg=0xffffffff80e50588,  
> frame=0xffffffffae39fc80) 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=0xffffff00012bf000,  
> m=0xffffff0003576000) at /usr/src/sys/net/if_ethersubr.c:545
> | 545             eh = mtod(m, struct ether_header *);
> | (kgdb) info locals
> | eh = (struct ether_header *) 0xf85ecc37f9239402
> | (kgdb) info args
> | ifp = (struct ifnet *) 0xffffff00012bf000
> | m = (struct mbuf *) 0xffffff0003576000
> | (kgdb) mbuf m
> | 0xffffff0003576000: 125 bytes ext 0xaf29dcb45d53e701 packet: 125  
> bytes received via em0
> | 0xbb763383e10eda22Cannot access memory at address 0xbb763383e10eda3a
> | (kgdb)
>
> 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.
>
> 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.
>

Hi Chris,

Sorry to hear y'all are having problems.  You mention that you  
switched to
GENERIC?  Can you send out a copy of your modified kernel config?  I'm  
a bit confused
because the kernel panic you do show looks like it's from a GENERIC  
kernel.

Are you setting any of the em device's kernel tunables?

How is your IPSEC stuff built in to the kernel and are you setting any
kernel variables for it?

My best guess from the stack trace is a buffer that is not being  
returned
properly somewhere between the device and the IPsec subsystem.

Best,
George



From ccowart at rescomp.berkeley.edu  Mon Sep  7 19:10:07 2009
From: ccowart at rescomp.berkeley.edu (Chris Cowart)
Date: Mon Sep  7 19:10:13 2009
Subject: Crash in ether_input
In-Reply-To: <723505E9-96C6-401C-A844-3D9BA2033795@neville-neil.com>
References: <20090904223123.GD16213@hal.rescomp.berkeley.edu>
	<723505E9-96C6-401C-A844-3D9BA2033795@neville-neil.com>
Message-ID: <20090907191001.GA37291@hal.rescomp.berkeley.edu>

George Neville-Neil wrote:
> On Sep 4, 2009, at 18:31 , Chris Cowart wrote:
> > 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.
> >
> > 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.
> >
> > From uname:
> >
> > | 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:
> > |
> > | Fatal trap 27: stack fault while in kernel mode
> > | cpuid = 0; apic id = 00
> > | instruction pointer     = 0x8:0xffffffff80559fb4
> > | stack pointer           = 0x10:0xffffffffae39faf0
> > | frame pointer           = 0x10:0xf85ecc37f9239402
> > | code segment            = base 0x0, limit 0xfffff, type 0x1b
> > |                         = DPL 0, pres 1, long 1, def32 0, gran 1
> > | processor eflags        = interrupt enabled, resume, IOPL = 0
> > | current process         = 27 (em0 taskq)
> > | trap number             = 27
> > | panic: stack fault
> > | cpuid = 0
> > | Uptime: 43m44s
> > | Physical memory: 4082 MB
> > | Dumping 361 MB: 346 330 314 298 282 266 250 234 218 202em0:  
> > watchdog timeout -- resetting
> >
> > | (kgdb) bt
> > | #0  doadump () at pcpu.h:195
> > | #1  0x0000000000000004 in ?? ()
> > | #2  0xffffffff804bd9b9 in boot (howto=260) at /usr/src/sys/kern/ 
> > kern_shutdown.c:418
> > | #3  0xffffffff804bddc2 in panic (fmt=0x104 <Address 0x104 out of  
> > bounds>) at /usr/src/sys/kern/kern_shutdown.c:574
> > | #4  0xffffffff807b9f23 in trap_fatal (frame=0xffffff00012d66e0,  
> > eva=Variable "eva" is not available.
> > | ) at /usr/src/sys/amd64/amd64/trap.c:764
> > | #5  0xffffffff807baa75 in trap (frame=0xffffffffae39fa40) at /usr/ 
> > src/sys/amd64/amd64/trap.c:565
> > | #6  0xffffffff807a042e in calltrap () at /usr/src/sys/amd64/amd64/ 
> > exception.S:209
> > | #7  0xffffffff80559fb4 in ether_input (ifp=0xffffff00012bf000,  
> > m=0xffffff0003576000) at /usr/src/sys/net/if_ethersubr.c:545
> > | #8  0xffffffff802bd645 in em_rxeof (adapter=0xffffffff80e4c000,  
> > count=99) at /usr/src/sys/dev/e1000/if_em.c:4539
> > | #9  0xffffffff802be55e in em_handle_rxtx (context=Variable  
> > "context" is not available.
> > | ) at /usr/src/sys/dev/e1000/if_em.c:1702
> > | #10 0xffffffff804f2afd in taskqueue_run (queue=0xffffff00012c8c80)  
> > at /usr/src/sys/kern/subr_taskqueue.c:282
> > | #11 0xffffffff804f2da6 in taskqueue_thread_loop (arg=Variable  
> > "arg" is not available.
> > | ) at /usr/src/sys/kern/subr_taskqueue.c:401
> > | #12 0xffffffff8049b2f3 in fork_exit (callout=0xffffffff804f2d40  
> > <taskqueue_thread_loop>, arg=0xffffffff80e50588,  
> > frame=0xffffffffae39fc80) 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=0xffffff00012bf000,  
> > m=0xffffff0003576000) at /usr/src/sys/net/if_ethersubr.c:545
> > | 545             eh = mtod(m, struct ether_header *);
> > | (kgdb) info locals
> > | eh = (struct ether_header *) 0xf85ecc37f9239402
> > | (kgdb) info args
> > | ifp = (struct ifnet *) 0xffffff00012bf000
> > | m = (struct mbuf *) 0xffffff0003576000
> > | (kgdb) mbuf m
> > | 0xffffff0003576000: 125 bytes ext 0xaf29dcb45d53e701 packet: 125  
> > bytes received via em0
> > | 0xbb763383e10eda22Cannot access memory at address 0xbb763383e10eda3a
> > | (kgdb)
> >
> > 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.
> >
> > 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.
> >
> 
> Hi Chris,
> 
> Sorry to hear y'all are having problems.  You mention that you
> switched to GENERIC?  Can you send out a copy of your modified kernel
> config?  I'm  a bit confused because the kernel panic you do show
> looks like it's from a GENERIC  kernel.

Sorry, the uname was from a stable boot after we had switched to
GENERIC. 

The config from the crashing kernel:

| include		GENERIC
| 
| ident		RCBSD_REL7
| 
| # Enabling IPSec (see SysAdmin.IPSec in TWiki)
| options         IPSEC                                         
| options         IPSEC_FILTERTUNNEL
| device		crypto
| 
| # Enabling quota support
| options		QUOTA

> Are you setting any of the em device's kernel tunables?

Nope. Some more details on the hardware:

| [ccowart@mug /usr/local/rescomp/etc/online-helpdesk]$ dmesg | grep em0
| em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0xece0-0xecff mem 0xfc3e0000-0xfc3fffff,0xfc3c0000-0xfc3dffff irq 16 at device 0.0 on pci14
| em0: Using MSI interrupt
| em0: [FILTER]
| em0: Ethernet address: 00:15:17:7a:b5:e0
| em0: link state changed to UP

> How is your IPSEC stuff built in to the kernel and are you setting any
> kernel variables for it?

See the kernel config above. We are not tuning via sysctls or the
loader.conf. All of that should be stock for IPSEC. The host is
configured with 2 peers for IPSec communication. We use racoon and x509
certificates.

> My best guess from the stack trace is a buffer that is not being
> returned properly somewhere between the device and the IPsec
> subsystem.

One of my coworkers has been able to reproduce the crash by syslogging
really long lines. I'm planning to spend some time today to try to
create a smaller example case on a couple of vms.

-- 
Chris Cowart
Network Technical Lead
Network & Infrastructure Services, RSSP-IT
UC Berkeley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090907/7abf37c6/attachment.pgp
From peterjeremy at acm.org  Mon Sep  7 21:03:34 2009
From: peterjeremy at acm.org (Peter Jeremy)
Date: Mon Sep  7 21:03:40 2009
Subject: Call for testers: ng_netflow with v9 and IPv6 support
In-Reply-To: <1116202669.20090907115455@homelink.ru>
References: <d2e731a10909061511q35447425s6cec18460fb48bd1@mail.gmail.com>
	<4AA46103.9000108@elischer.org>
	<1116202669.20090907115455@homelink.ru>
Message-ID: <20090907195636.GB35275@server.vk2pj.dyndns.org>

On 2009-Sep-07 11:54:55 +0400, Dennis Yusupoff <dyr@homelink.ru> wrote:
>By the way, what's about this one:
>---
>     The ng_netflow node type does not fill in AS numbers.  This is due to the
...
>---
>
>Is any chance to see it in, for example, 8.0?

New feature cutoff for 8.0 was several months ago.  Once the code
exists, it may be a candidate for inclusion in a future 8.x release.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090907/88198fc6/attachment.pgp
From stef-list at memberwebs.com  Tue Sep  8 00:08:37 2009
From: stef-list at memberwebs.com (Stef Walter)
Date: Tue Sep  8 00:08:44 2009
Subject: Panic in imo_match_source (netinet/in_mcast.c)
Message-ID: <mailman.8.1252368524.1066.freebsd-net@freebsd.org>

Stef Walter wrote:
> On a new VPN server, running OSPF, I'm experiencing regular panics at:
> 
> imo_match_source: !AF_INET

BTW, src->sa_family is 0

Moved back to FreeBSD 7.1 i386 and the problem goes away.

Cheers,

Stef

From john at dnepro.net  Tue Sep  8 07:50:34 2009
From: john at dnepro.net (Eugene Perevyazko)
Date: Tue Sep  8 07:50:41 2009
Subject: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link
In-Reply-To: <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>
	<20090904212223.GA9950@michelle.cdnetworks.com>
Message-ID: <20090908075030.GA6644@traktor.dnepro.net>

On Fri, Sep 04, 2009 at 02:22:23PM -0700, Pyun YongHyeon wrote:
> 
> 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.
>

Still no success.
 
mskc0: <D-Link 560SX Gigabit Ethernet> port 0xd800-0xd8ff mem 0xfeafc000-0xfeafffff irq 16 at device 0.0 on pci1
msk0: <Marvell Technology Group Ltd. Yukon XL Id 0xb3 Rev 0x03> on mskc0
msk0: Ethernet address: 00:21:91:52:4f:09
miibus0: <MII bus> on msk0
e1000phy0: <Marvell 88E1112 Gigabit PHY> PHY 0 on miibus0
e1000phy0:  1000baseSX, 1000baseSX-FDX, auto
mskc0: [FILTER]

ifconfig -m msk0
msk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=11a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4>
        capabilities=11a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4>
        ether 00:21:91:52:4f:09
        inet 10.2.3.1 netmask 0xffffff00 broadcast 10.2.3.255
        media: Ethernet autoselect (autoselect <full-duplex>)
        status: active
        supported media:
                media autoselect
                media 1000baseSX mediaopt full-duplex
                media 1000baseSX
                media none

Switch shows no link on the port.

# ifconfig msk0 media 1000baseSX mediaopt full-duplex
# ifconfig msk0
msk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=11a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4>
        ether 00:21:91:52:4f:09
        inet 10.2.3.1 netmask 0xffffff00 broadcast 10.2.3.255
        media: Ethernet 1000baseSX <full-duplex> (autoselect <full-duplex>)
        status: active

Switch shows no link again.

All dev.msk.0.stats counters are zero even after trying broadcast ping.

I can arrange you root access to the host with this NIC if you have time/wish.

-- 
Eugene Perevyazko
From bms at incunabulum.net  Tue Sep  8 13:04:41 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Tue Sep  8 13:04:48 2009
Subject: Panic in imo_match_source (netinet/in_mcast.c)
Message-ID: <4AA65663.8050106@incunabulum.net>

Stef Walter wrote:
> Stef Walter wrote:
>   
>> On a new VPN server, running OSPF, I'm experiencing regular panics at:
>>
>> imo_match_source: !AF_INET
>>     
>
> BTW, src->sa_family is 0
>
> Moved back to FreeBSD 7.1 i386 and the problem goes away.
>   

Full OS version, dmesg, panic and backtrace please, when reporting this 
kind of issue... otherwise folk can't help. Are you using SSM multicast 
features?
From bms at incunabulum.net  Tue Sep  8 13:13:12 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Tue Sep  8 13:13:18 2009
Subject: Panic in imo_match_source (netinet/in_mcast.c)
In-Reply-To: <4AA65663.8050106@incunabulum.net>
References: <4AA65663.8050106@incunabulum.net>
Message-ID: <4AA65861.8@incunabulum.net>

[Brief reply as I'm meant to be doing a zillion other things...]

Bruce Simpson wrote:
>
> Full OS version, dmesg, panic and backtrace please, when reporting 
> this kind of issue... otherwise folk can't help. Are you using SSM 
> multicast features?

P.S. You might want to try demoting the KASSERT to a conditional error 
return (return no match if src is NULL or src->sa_family != AF_INET), 
and see if that fix 'just works' for you. Sometimes the asserts I 
sprinkle into code are too paranoid for what's going on, and syrinx@ 
recently caught one of those.

I can see some situations where this could kick off, so that is probably 
the right fix. Please do let me know. If that fix works for you then it 
can probably be checked in. There is an RC cutoff looming, so if I can't 
do it in time, someone else may be able to check it in.

thanks,
BMS
From shteryana at gmail.com  Tue Sep  8 14:21:42 2009
From: shteryana at gmail.com (Shteryana Shopova)
Date: Tue Sep  8 14:21:49 2009
Subject: Panic in imo_match_source (netinet/in_mcast.c)
In-Reply-To: <4AA65861.8@incunabulum.net>
References: <4AA65663.8050106@incunabulum.net> <4AA65861.8@incunabulum.net>
Message-ID: <61b573980909080654x50670168x39001267ad81c6a3@mail.gmail.com>

Hi,

I actually managed to get the same kernel dump using the following
sample code - http://people.freebsd.org/~syrinx/mcast/mcast_crash.c
and the crash is 100% reproducable. A temporary fix is here -
http://people.freebsd.org/~syrinx/mcast/in_mcast.c-20090908-01.diff
but I actually prefer that we go over the logic in inp_join_group()
again before proposing a patch for head as this is the second assert
panic I am seeing it causes in the last few days. I can try making up
a proper fix if Bruce is busy, but it will take a day or two until I'm
able to fully test it.

cheers,
Shteryana

On Tue, Sep 8, 2009 at 4:13 PM, Bruce Simpson<bms@incunabulum.net> wrote:
> [Brief reply as I'm meant to be doing a zillion other things...]
>
> Bruce Simpson wrote:
>>
>> Full OS version, dmesg, panic and backtrace please, when reporting this
>> kind of issue... otherwise folk can't help. Are you using SSM multicast
>> features?
>
> P.S. You might want to try demoting the KASSERT to a conditional error
> return (return no match if src is NULL or src->sa_family != AF_INET), and
> see if that fix 'just works' for you. Sometimes the asserts I sprinkle into
> code are too paranoid for what's going on, and syrinx@ recently caught one
> of those.
>
> I can see some situations where this could kick off, so that is probably the
> right fix. Please do let me know. If that fix works for you then it can
> probably be checked in. There is an RC cutoff looming, so if I can't do it
> in time, someone else may be able to check it in.
>
> thanks,
> BMS
> _______________________________________________
> 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 bms at incunabulum.net  Tue Sep  8 15:11:30 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Tue Sep  8 15:11:36 2009
Subject: Panic in imo_match_source (netinet/in_mcast.c)
In-Reply-To: <61b573980909080654x50670168x39001267ad81c6a3@mail.gmail.com>
References: <4AA65663.8050106@incunabulum.net> <4AA65861.8@incunabulum.net>
	<61b573980909080654x50670168x39001267ad81c6a3@mail.gmail.com>
Message-ID: <4AA6741B.9020403@incunabulum.net>

Shteryana Shopova wrote:
> Hi,
>
> I actually managed to get the same kernel dump using the following
> sample code - http://people.freebsd.org/~syrinx/mcast/mcast_crash.c
> and the crash is 100% reproducable. A temporary fix is here -
> http://people.freebsd.org/~syrinx/mcast/in_mcast.c-20090908-01.diff
> but I actually prefer that we go over the logic in inp_join_group()
> again before proposing a patch for head as this is the second assert
> panic I am seeing it causes in the last few days. I can try making up
> a proper fix if Bruce is busy, but it will take a day or two until I'm
> able to fully test it.
>   

Good catch. Yes, IP_ADD_MEMBERSHIP on an existing exclusive mode group 
with filters is an error. The comment calls it out, but you are right, a 
normal case could hit the KASSERT.

The code in the start of inp_join_group() handles all join requests, by 
mapping 3 possible sets of inbound ioctls onto 1, to make the ioctl 
processing code smaller.

So I could rephrase the fix to: explicitly check for ssa->ss.ss_family 
being AF_UNSPEC before trying to perform a search with ssa as the key, 
as this will be set by the code above.  Or commit your fix, which is a 
bit more explicit.

The assertion in imo_match_source() existed to catch v4/v6 operations 
being mixed in similar code paths. Originally I'd planned to keep v4 and 
v6 code together, but as time went on, it became clear that just 
branching the code for v6 was the right way to keep the code managable. 
v6 and v4 have a bunch of special conditions for address handling which 
just plain need to stay separate...
From gnn at neville-neil.com  Tue Sep  8 15:50:13 2009
From: gnn at neville-neil.com (George Neville-Neil)
Date: Tue Sep  8 15:50:20 2009
Subject: Crash in ether_input
In-Reply-To: <20090907191001.GA37291@hal.rescomp.berkeley.edu>
References: <20090904223123.GD16213@hal.rescomp.berkeley.edu>
	<723505E9-96C6-401C-A844-3D9BA2033795@neville-neil.com>
	<20090907191001.GA37291@hal.rescomp.berkeley.edu>
Message-ID: <54FDC10A-EAE3-4AE2-BF36-2C5F7D141C3A@neville-neil.com>


On Sep 7, 2009, at 15:10 , Chris Cowart wrote:

> George Neville-Neil wrote:
>> On Sep 4, 2009, at 18:31 , Chris Cowart wrote:
>>> 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.
>>>
>>> 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.
>>>
>>> From uname:
>>>
>>> | 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:
>>> |
>>> | Fatal trap 27: stack fault while in kernel mode
>>> | cpuid = 0; apic id = 00
>>> | instruction pointer     = 0x8:0xffffffff80559fb4
>>> | stack pointer           = 0x10:0xffffffffae39faf0
>>> | frame pointer           = 0x10:0xf85ecc37f9239402
>>> | code segment            = base 0x0, limit 0xfffff, type 0x1b
>>> |                         = DPL 0, pres 1, long 1, def32 0, gran 1
>>> | processor eflags        = interrupt enabled, resume, IOPL = 0
>>> | current process         = 27 (em0 taskq)
>>> | trap number             = 27
>>> | panic: stack fault
>>> | cpuid = 0
>>> | Uptime: 43m44s
>>> | Physical memory: 4082 MB
>>> | Dumping 361 MB: 346 330 314 298 282 266 250 234 218 202em0:
>>> watchdog timeout -- resetting
>>>
>>> | (kgdb) bt
>>> | #0  doadump () at pcpu.h:195
>>> | #1  0x0000000000000004 in ?? ()
>>> | #2  0xffffffff804bd9b9 in boot (howto=260) at /usr/src/sys/kern/
>>> kern_shutdown.c:418
>>> | #3  0xffffffff804bddc2 in panic (fmt=0x104 <Address 0x104 out of
>>> bounds>) at /usr/src/sys/kern/kern_shutdown.c:574
>>> | #4  0xffffffff807b9f23 in trap_fatal (frame=0xffffff00012d66e0,
>>> eva=Variable "eva" is not available.
>>> | ) at /usr/src/sys/amd64/amd64/trap.c:764
>>> | #5  0xffffffff807baa75 in trap (frame=0xffffffffae39fa40) at /usr/
>>> src/sys/amd64/amd64/trap.c:565
>>> | #6  0xffffffff807a042e in calltrap () at /usr/src/sys/amd64/amd64/
>>> exception.S:209
>>> | #7  0xffffffff80559fb4 in ether_input (ifp=0xffffff00012bf000,
>>> m=0xffffff0003576000) at /usr/src/sys/net/if_ethersubr.c:545
>>> | #8  0xffffffff802bd645 in em_rxeof (adapter=0xffffffff80e4c000,
>>> count=99) at /usr/src/sys/dev/e1000/if_em.c:4539
>>> | #9  0xffffffff802be55e in em_handle_rxtx (context=Variable
>>> "context" is not available.
>>> | ) at /usr/src/sys/dev/e1000/if_em.c:1702
>>> | #10 0xffffffff804f2afd in taskqueue_run (queue=0xffffff00012c8c80)
>>> at /usr/src/sys/kern/subr_taskqueue.c:282
>>> | #11 0xffffffff804f2da6 in taskqueue_thread_loop (arg=Variable
>>> "arg" is not available.
>>> | ) at /usr/src/sys/kern/subr_taskqueue.c:401
>>> | #12 0xffffffff8049b2f3 in fork_exit (callout=0xffffffff804f2d40
>>> <taskqueue_thread_loop>, arg=0xffffffff80e50588,
>>> frame=0xffffffffae39fc80) 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=0xffffff00012bf000,
>>> m=0xffffff0003576000) at /usr/src/sys/net/if_ethersubr.c:545
>>> | 545             eh = mtod(m, struct ether_header *);
>>> | (kgdb) info locals
>>> | eh = (struct ether_header *) 0xf85ecc37f9239402
>>> | (kgdb) info args
>>> | ifp = (struct ifnet *) 0xffffff00012bf000
>>> | m = (struct mbuf *) 0xffffff0003576000
>>> | (kgdb) mbuf m
>>> | 0xffffff0003576000: 125 bytes ext 0xaf29dcb45d53e701 packet: 125
>>> bytes received via em0
>>> | 0xbb763383e10eda22Cannot access memory at address  
>>> 0xbb763383e10eda3a
>>> | (kgdb)
>>>
>>> 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.
>>>
>>> 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.
>>>
>>
>> Hi Chris,
>>
>> Sorry to hear y'all are having problems.  You mention that you
>> switched to GENERIC?  Can you send out a copy of your modified kernel
>> config?  I'm  a bit confused because the kernel panic you do show
>> looks like it's from a GENERIC  kernel.
>
> Sorry, the uname was from a stable boot after we had switched to
> GENERIC.
>
> The config from the crashing kernel:
>
> | include		GENERIC
> |
> | ident		RCBSD_REL7
> |
> | # Enabling IPSec (see SysAdmin.IPSec in TWiki)
> | options         IPSEC
> | options         IPSEC_FILTERTUNNEL
> | device		crypto
> |
> | # Enabling quota support
> | options		QUOTA
>
>> Are you setting any of the em device's kernel tunables?
>
> Nope. Some more details on the hardware:
>
> | [ccowart@mug /usr/local/rescomp/etc/online-helpdesk]$ dmesg | grep  
> em0
> | em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port  
> 0xece0-0xecff mem 0xfc3e0000-0xfc3fffff,0xfc3c0000-0xfc3dffff irq 16  
> at device 0.0 on pci14
> | em0: Using MSI interrupt
> | em0: [FILTER]
> | em0: Ethernet address: 00:15:17:7a:b5:e0
> | em0: link state changed to UP
>
>> How is your IPSEC stuff built in to the kernel and are you setting  
>> any
>> kernel variables for it?
>
> See the kernel config above. We are not tuning via sysctls or the
> loader.conf. All of that should be stock for IPSEC. The host is
> configured with 2 peers for IPSec communication. We use racoon and  
> x509
> certificates.
>
>> My best guess from the stack trace is a buffer that is not being
>> returned properly somewhere between the device and the IPsec
>> subsystem.
>
> One of my coworkers has been able to reproduce the crash by syslogging
> really long lines. I'm planning to spend some time today to try to
> create a smaller example case on a couple of vms.

Sounds great.  One more thought.  Can you try this without  
IPSEC_FILTERTUNNEL?
Since that copies packets I'm suspicious of it.

Best,
George

From stef-list at memberwebs.com  Tue Sep  8 16:15:29 2009
From: stef-list at memberwebs.com (Stef Walter)
Date: Tue Sep  8 16:15:46 2009
Subject: Panic in imo_match_source (netinet/in_mcast.c)
References: <4AA65663.8050106@incunabulum.net>
Message-ID: <mailman.9.1252426546.1066.freebsd-net@freebsd.org>

Bruce Simpson wrote:
> Full OS version, dmesg, panic and backtrace please, when reporting this
> kind of issue... otherwise folk can't help. 

Thanks for taking a look. It was linked in the parent post:
> This is the stack trace:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/137164&cat=


> Are you using SSM multicast
> features?

Not that I know of. This is IPv4 OSPF which as far as I know sends
simple multicast to 224.0.0.5. I'm using quagga 0.99.15 to run OSPF.

Cheers,

Stef

From stef-list at memberwebs.com  Tue Sep  8 16:15:30 2009
From: stef-list at memberwebs.com (Stef Walter)
Date: Tue Sep  8 16:15:46 2009
Subject: Panic in imo_match_source (netinet/in_mcast.c)
References: <4AA65663.8050106@incunabulum.net> <4AA65861.8@incunabulum.net>
Message-ID: <mailman.10.1252426546.1066.freebsd-net@freebsd.org>

Bruce Simpson wrote:
> [Brief reply as I'm meant to be doing a zillion other things...]
> 
> Bruce Simpson wrote:
>>
>> Full OS version, dmesg, panic and backtrace please, when reporting
>> this kind of issue... otherwise folk can't help. Are you using SSM
>> multicast features?
> 
> P.S. You might want to try demoting the KASSERT to a conditional error
> return (return no match if src is NULL or src->sa_family != AF_INET),
> and see if that fix 'just works' for you. Sometimes the asserts I
> sprinkle into code are too paranoid for what's going on, and syrinx@
> recently caught one of those.

Yes, I patched that out and have been testing. However in this case OSPF
(quagga) stops running. Maybe quagga is doing something unexpected. I've
been slowly trying to corner this issue.

Cheers,

Stef

From stef-list at memberwebs.com  Tue Sep  8 16:15:31 2009
From: stef-list at memberwebs.com (Stef Walter)
Date: Tue Sep  8 16:15:47 2009
Subject: Panic in imo_match_source (netinet/in_mcast.c)
References: <4AA65663.8050106@incunabulum.net> <4AA65861.8@incunabulum.net>
	<61b573980909080654x50670168x39001267ad81c6a3@mail.gmail.com>
Message-ID: <mailman.11.1252426547.1066.freebsd-net@freebsd.org>

Shteryana Shopova wrote:
> I actually managed to get the same kernel dump using the following
> sample code - http://people.freebsd.org/~syrinx/mcast/mcast_crash.c
> and the crash is 100% reproducable. A temporary fix is here -
> http://people.freebsd.org/~syrinx/mcast/in_mcast.c-20090908-01.diff
> but I actually prefer that we go over the logic in inp_join_group()
> again before proposing a patch for head as this is the second assert
> panic I am seeing it causes in the last few days. I can try making up
> a proper fix if Bruce is busy, but it will take a day or two until I'm
> able to fully test it.

Hmmmm, EADDRINUSE ... This sounds very familiar. Here's an old quagga
bug that I don't think got patched properly. It does an unexpected
double IP_ADD_MEMBERSHIP:

http://bugzilla.quagga.net/show_bug.cgi?id=212

I'll test the patch here. Thanks!

Cheers,

Stef




From linimon at FreeBSD.org  Tue Sep  8 18:03:16 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Tue Sep  8 18:03:27 2009
Subject: kern/138620: [lagg] [patch] lagg port bpf-writes blocked
Message-ID: <200909081803.n88I3GBB036805@freefall.freebsd.org>

Old Synopsis: lagg port bpf-writes blocked
New Synopsis: [lagg] [patch] lagg port bpf-writes blocked

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue Sep 8 18:02:22 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=138620
From linimon at FreeBSD.org  Tue Sep  8 18:09:35 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Tue Sep  8 18:09:45 2009
Subject: kern/138632: [ndis] [patch] race at vap destroy
Message-ID: <200909081809.n88I9ZRt037160@freefall.freebsd.org>

Old Synopsis: race at vap destroy
New Synopsis: [ndis] [patch] race at vap destroy

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Tue Sep 8 18:08:44 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=138632
From melifaro at ipfw.ru  Tue Sep  8 18:39:37 2009
From: melifaro at ipfw.ru (Alexander V. Chernikov)
Date: Tue Sep  8 18:39:52 2009
Subject: Call for testers: ng_netflow with v9 and IPv6 support
In-Reply-To: <d2e731a10909061511q35447425s6cec18460fb48bd1@mail.gmail.com>
References: <d2e731a10909061511q35447425s6cec18460fb48bd1@mail.gmail.com>
Message-ID: <4AA6A4C8.4090200@ipfw.ru>

grarpamp wrote:
> Wouldn't it be better to support the obvious formal emergent standards
> track protocol instead of the legacy informational one? Or to perform
> both via sysctl or other arguments/defines, with the standard IPFIX
> being the default mode? Have you reviewed the nProbe code for other
> various ideas? Thanks for working on netflow :) And any form of v6
> is good to have finally.
>   
Thanks for pointing out those RFCs. We're still using v5 for accounting, 
so my behavior was quite straightforward:
can v5 count ipv6 ? No, what's next netflow version can ? v9? Ok, let's 
implement v9.

However, IPFIX seems to be very much like v9 at a first glance. 
Moreover, ng_ksocket can handle udp/tcp/sctp exports.

> =========================================================================
>
> Network Working Group                                     B. Claise, Ed.
> Request for Comments: 5101                           Cisco Systems, Inc.
> Category: Standards Track                                   January 2008
> Specification of the IP Flow Information Export (IPFIX) Protocol
> for the Exchange of IP Traffic Flow Information
>    This document specifies an Internet standards track protocol for the
>    Internet community
>
>
> Network Working Group                                         J. Quittek
> Request for Comments: 5102                                           NEC
> Category: Standards Track                                      S. Bryant
>                                                                B. Claise
>                                                                P. Aitken
>                                                      Cisco Systems, Inc.
>                                                                 J. Meyer
>                                                                   PayPal
>                                                             January 2008
> Information Model for IP Flow Information Export
>    This document specifies an Internet standards track protocol for the
>    Internet community
>
>
> Network Working Group                                        B. Trammell
> Request for Comments: 5103                                    CERT/NetSA
> Category: Standards Track                                      E. Boschi
>                                                           Hitachi Europe
>                                                             January 2008
> Bidirectional Flow Export Using IP Flow Information Export (IPFIX)
>    This document specifies an Internet standards track protocol for the
>    Internet community
>
>
> Network Working Group                                          E. Boschi
> Request for Comments: 5153                                Hitachi Europe
> Category: Informational                                          L. Mark
>                                                         Fraunhofer FOKUS
>                                                               J. Quittek
>                                                           M. Stiemerling
>                                                                      NEC
>                                                                P. Aitken
>                                                      Cisco Systems, Inc.
>                                                               April 2008
> IP Flow Information Export (IPFIX) Implementation Guidelines
>    This memo provides information for the Internet community.  It does
>    not specify an Internet standard of any kind.
>
>
> Network Working Group                                          S. Leinen
> Request for Comments: 3955                                        SWITCH
> Category: Informational                                     October 2004
> Evaluation of Candidate Protocols for IP Flow Information Export (IPFIX)
>    This memo provides information for the Internet community.  It does
>    not specify an Internet standard of any kind.
>
>
> Network Working Group                                         J. Quittek
> Request for Comments: 3917                               NEC Europe Ltd.
> Category: Informational                                         T. Zseby
>                                                         Fraunhofer FOKUS
>                                                                B. Claise
>                                                            Cisco Systems
>                                                                S. Zander
>                                                     Swinburne University
>                                                             October 2004
> Requirements for IP Flow Information Export (IPFIX)
>    This memo provides information for the Internet community.  It does
>    not specify an Internet standard of any kind.
>
>
> And others...
>
> =========================================================================
>
> Network Working Group                                     B. Claise, Ed.
> Request for Comments: 3954                                 Cisco Systems
> Category: Informational                                     October 2004
>             Cisco Systems NetFlow Services Export Version 9
>    This RFC documents the NetFlow services export protocol Version 9 as
>    it was when submitted to the IETF as a basis for further work in the
>    IPFIX WG.
>    This RFC itself is not a candidate for any level of Internet
>    Standard.  The IETF disclaims any knowledge of the fitness of this
>    RFC for any purpose...
>
> And others...
>
> =========================================================================
> _______________________________________________
> 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 weongyo at FreeBSD.org  Tue Sep  8 20:39:51 2009
From: weongyo at FreeBSD.org (weongyo@FreeBSD.org)
Date: Tue Sep  8 20:39:58 2009
Subject: kern/138292: [zyd] [usb8] "zyd0: device timeout" with ZyXEL
	G-202
Message-ID: <200909082039.n88KdpDQ088586@freefall.freebsd.org>

Synopsis: [zyd] [usb8] "zyd0: device timeout" with ZyXEL G-202

Responsible-Changed-From-To: freebsd-net->weongyo
Responsible-Changed-By: weongyo
Responsible-Changed-When: Tue Sep 8 20:39:37 UTC 2009
Responsible-Changed-Why: 
grap.

http://www.freebsd.org/cgi/query-pr.cgi?pr=138292
From pyunyh at gmail.com  Tue Sep  8 21:34:33 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Tue Sep  8 21:34:39 2009
Subject: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link
In-Reply-To: <20090908075030.GA6644@traktor.dnepro.net>
References: <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>
	<20090904212223.GA9950@michelle.cdnetworks.com>
	<20090908075030.GA6644@traktor.dnepro.net>
Message-ID: <20090908213335.GE1520@michelle.cdnetworks.com>

On Tue, Sep 08, 2009 at 10:50:30AM +0300, Eugene Perevyazko wrote:
> On Fri, Sep 04, 2009 at 02:22:23PM -0700, Pyun YongHyeon wrote:
> > 
> > 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.
> >
> 
> Still no success.
>  
> mskc0: <D-Link 560SX Gigabit Ethernet> port 0xd800-0xd8ff mem 0xfeafc000-0xfeafffff irq 16 at device 0.0 on pci1
> msk0: <Marvell Technology Group Ltd. Yukon XL Id 0xb3 Rev 0x03> on mskc0
> msk0: Ethernet address: 00:21:91:52:4f:09
> miibus0: <MII bus> on msk0
> e1000phy0: <Marvell 88E1112 Gigabit PHY> PHY 0 on miibus0
> e1000phy0:  1000baseSX, 1000baseSX-FDX, auto
> mskc0: [FILTER]
> 
> ifconfig -m msk0
> msk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>         options=11a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4>
>         capabilities=11a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4>
>         ether 00:21:91:52:4f:09
>         inet 10.2.3.1 netmask 0xffffff00 broadcast 10.2.3.255
>         media: Ethernet autoselect (autoselect <full-duplex>)
>         status: active
>         supported media:
>                 media autoselect
>                 media 1000baseSX mediaopt full-duplex
>                 media 1000baseSX
>                 media none
> 
> Switch shows no link on the port.
> 
> # ifconfig msk0 media 1000baseSX mediaopt full-duplex
> # ifconfig msk0
> msk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
>         options=11a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4>
>         ether 00:21:91:52:4f:09
>         inet 10.2.3.1 netmask 0xffffff00 broadcast 10.2.3.255
>         media: Ethernet 1000baseSX <full-duplex> (autoselect <full-duplex>)
>         status: active
> 
> Switch shows no link again.
> 
> All dev.msk.0.stats counters are zero even after trying broadcast ping.
> 
> I can arrange you root access to the host with this NIC if you have time/wish.
> 

I've sent mail in private.

> -- 
> Eugene Perevyazko
From barney_cordoba at yahoo.com  Tue Sep  8 21:42:40 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Tue Sep  8 21:42:46 2009
Subject: em driver input errors
In-Reply-To: <5bc218350909041041x49ec9765k81346e90bbfe891a@mail.gmail.com>
Message-ID: <324031.44935.qm@web63904.mail.re1.yahoo.com>



--- On Fri, 9/4/09, Manish Vachharajani <manishv@lineratesystems.com> wrote:

> From: Manish Vachharajani <manishv@lineratesystems.com>
> Subject: Re: em driver input errors
> To: alexpalias-bsdnet@yahoo.com
> Cc: freebsd-net@freebsd.org, "Artis Caune" <artis.caune@gmail.com>
> Date: Friday, September 4, 2009, 1:41 PM
> 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

What specific kinds of input errors are you getting?

How many PPS are you doing, what is the size of the ring, and
the interrupt modulation rate?

Are the NICs PCIe or PCIx?

Barney




      
From mike at sentex.net  Tue Sep  8 22:21:39 2009
From: mike at sentex.net (Mike Tancsa)
Date: Tue Sep  8 22:21:46 2009
Subject: em driver input errors
In-Reply-To: <324031.44935.qm@web63904.mail.re1.yahoo.com>
References: <5bc218350909041041x49ec9765k81346e90bbfe891a@mail.gmail.com>
	<324031.44935.qm@web63904.mail.re1.yahoo.com>
Message-ID: <200909082218.n88MI7TH073975@lava.sentex.ca>

At 05:42 PM 9/8/2009, Barney Cordoba wrote:
>Manish What specific kinds of input errors are you getting? How many 
>PPS are you doing, what is the size of the ring, and the interrupt 
>modulation rate? Are the NICs PCIe or PCIx? Barney

In my case, our backup server (mix of dump via nfs and some dumps 
through ssh as well as writes via samba mounts) has a fairly low pps 
rate and starts to see input errors at about 100Mb.  Adding

hw.em.rxd=4096
hw.em.txd=4096

and

net.inet.tcp.recvbuf_max=16777216
net.inet.tcp.recvspace=131072
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.sendspace=131072
net.inet.udp.recvspace=65536
kern.ipc.somaxconn=1024
kern.ipc.maxsockbuf=4194304
net.inet.ip.redirect=0
net.inet.ip.intr_queue_maxlen=4096
net.route.netisr_maxqlen=1024
kern.ipc.nmbclusters=655360

didnt seem to make a difference in the amount of errors I was seeing


em1@pci0:7:5:0: class=0x020000 card=0x348f8086 chip=0x10768086 
rev=0x05 hdr=0x00
     vendor     = 'Intel Corporation'
     device     = 'Gigabit Ethernet Controller (82541EI)'
     class      = network
     subclass   = ethernet
     cap 01[dc] = powerspec 2  supports D0 D3  current D0
     cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction

  Core(TM)2 Quad CPU    Q6600  @ 2.40GHz, AMD64, RELENG_7 from Jun 18th

Plenty of disk IO left and the CPUs doent seem to be taxed that much.

Sep  8 00:02:01 backup3 kernel: em1: Excessive collisions = 0
Sep  8 00:02:01 backup3 kernel: em1: Sequence errors = 0
Sep  8 00:02:01 backup3 kernel: em1: Defer count = 0
Sep  8 00:02:01 backup3 kernel: em1: Missed Packets = 61316
Sep  8 00:02:01 backup3 kernel: em1: Receive No Buffers = 0
Sep  8 00:02:01 backup3 kernel: em1: Receive Length Errors = 0
Sep  8 00:02:01 backup3 kernel: em1: Receive errors = 0
Sep  8 00:02:01 backup3 kernel: em1: Crc errors = 0
Sep  8 00:02:01 backup3 kernel: em1: Alignment errors = 0
Sep  8 00:02:01 backup3 kernel: em1: Collision/Carrier extension errors = 0
Sep  8 00:02:01 backup3 kernel: em1: RX overruns = 22397
Sep  8 00:02:01 backup3 kernel: em1: watchdog timeouts = 0
Sep  8 00:02:01 backup3 kernel: em1: RX MSIX IRQ = 0 TX MSIX IRQ = 0 
LINK MSIX IRQ = 0
Sep  8 00:02:01 backup3 kernel: em1: XON Rcvd = 0
Sep  8 00:02:01 backup3 kernel: em1: XON Xmtd = 0
Sep  8 00:02:01 backup3 kernel: em1: XOFF Rcvd = 0
Sep  8 00:02:01 backup3 kernel: em1: XOFF Xmtd = 0
Sep  8 00:02:01 backup3 kernel: em1: Good Packets Rcvd = 544276980
Sep  8 00:02:01 backup3 kernel: em1: Good Packets Xmtd = 490475071
Sep  8 00:02:01 backup3 kernel: em1: TSO Contexts Xmtd = 0
Sep  8 00:02:01 backup3 kernel: em1: TSO Contexts Failed = 0


pf is in the kernel as well

>_______________________________________________
>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"

--------------------------------------------------------------------
Mike Tancsa,                                      tel +1 519 651 3400
Sentex Communications,                            mike@sentex.net
Providing Internet since 1994                    www.sentex.net
Cambridge, Ontario Canada                         www.sentex.net/mike

From grarpamp at gmail.com  Wed Sep  9 02:05:15 2009
From: grarpamp at gmail.com (grarpamp)
Date: Wed Sep  9 02:05:27 2009
Subject: Call for testers: ng_netflow with v9 and IPv6 support
In-Reply-To: <4AA6A4C8.4090200@ipfw.ru>
References: <d2e731a10909061511q35447425s6cec18460fb48bd1@mail.gmail.com>
	<4AA6A4C8.4090200@ipfw.ru>
Message-ID: <d2e731a10909081905l2ebc6d0dredda67a885df96d0@mail.gmail.com>

>  Thanks for pointing out those RFCs.

Sure. There are more I probably missed.
Search rfc-editor or ietf for netflow or ipfix.

>  can v5 count ipv6 ? No, what's next netflow version can ? v9? Ok, let's
> implement v9.

Yep, ipv6 is becoming really important, definitely on backbones. nProbe
has had it for a while. nProbe is a bpf flow sniffer and exporter. I don't
know about any other open source ones that do, besides your patch :)

>  However, IPFIX seems to be very much like v9 at a first glance.

v9 was the first that came out, mostly a defacto cisco proprietary
thing as was v5. Netflow needed to be opened up / standardized. So
ipfix group was started.
cisco v9 was submitted to ietf ipfix working group as one of proposed
ipfix methods. v9 was then modified in the group a bit and called
IPFIX. Some of
this is in rfc 3955.

Ipfix is probably the way to go. Of course others on the lists could
input whether they see more of v9 or ipfix now and in future.
From stef-list at memberwebs.com  Wed Sep  9 03:37:35 2009
From: stef-list at memberwebs.com (Stef Walter)
Date: Wed Sep  9 03:37:41 2009
Subject: [patch] Multicast: IP_DROP_MEMBERSHIP should return EADDRNOTAVAIL
 for invalid address
Message-ID: <mailman.12.1252467461.1066.freebsd-net@freebsd.org>

After an interface goes down and its addresses go away, if a caller
calls setsockopt/IP_DROP_MEMBERSHIP with a simple in_mreq input
containing the address that no longer exists, the kernel should return
EADDRNOTAVAIL.

However the current behavior in 8.0-BETA3 is to remove a membership to
the same multicast group from the 'first' interface instead. You can see
the results below in the ifmcstat output below.

Before northstar1 (tunnel) interface goes away, both bge0 and northstar1
 are on the 224.0.0.5 (ie: OSPF-ALL.MCAST.NET) group.

> bge0:
> 	inet 172.27.5.18
> 	igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group 224.0.0.5 mode exclude
> 			mcast-macaddr 01:00:5e:00:00:05
> 		group 224.0.0.1 mode exclude
> 			mcast-macaddr 01:00:5e:00:00:01
> rl0:
> 	inet 192.168.1.70
> 	igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group 224.0.0.1 mode exclude
> 			mcast-macaddr 01:00:5e:00:00:01
> lo0:
> 	inet 127.0.0.1
> 	igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group 224.0.0.1 mode exclude
> 	inet6 fe80::1%lo0
> 	mldv2 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group ff01::1%lo0 mode exclude
> 		group ff02::2:e78c:f513%lo0 mode exclude
> 		group ff02::1%lo0 mode exclude
> 		group ff02::1:ff00:1%lo0 mode exclude
> northstar1:
> 	inet 172.28.1.66
> 	igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group 224.0.0.5 mode exclude
> 		group 224.0.0.1 mode exclude

After northstar1 goes down, and setsockopt(..., IP_DROP_MEMBERSHIP, ...)
is called for the 172.28.1.66 address, we see that the group has been
dropped from bge0 instead. No error was returned from setsockopt.

> bge0:
> 	inet 172.27.5.18
> 	igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group 224.0.0.1 mode exclude
> 			mcast-macaddr 01:00:5e:00:00:01
> rl0:
> 	inet 192.168.1.70
> 	igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group 224.0.0.1 mode exclude
> 			mcast-macaddr 01:00:5e:00:00:01
> lo0:
> 	inet 127.0.0.1
> 	igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group 224.0.0.1 mode exclude
> 	inet6 fe80::1%lo0
> 	mldv2 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group ff01::1%lo0 mode exclude
> 		group ff02::2:e78c:f513%lo0 mode exclude
> 		group ff02::1%lo0 mode exclude
> 		group ff02::1:ff00:1%lo0 mode exclude
> northstar1:

UNAME: FreeBSD portillo-gate.ws.local 8.0-BETA3 FreeBSD 8.0-BETA3 #19:
Wed Sep  9 01:27:39 UTC 2009
root@portillo-gate.ws.local:/usr/src/sys/i386/compile/PORTILLO  i386

Patch is attached which fixes the problem. Is this the right approach?

BTW, the behavior of FreeBSD has always been that after northstar1 comes
back up with the same address, it is a member of 224.0.0.5 group.
Memberships are retained across interfaces and addresses going away. Not
sure if this is the best behavior, but it has been the historical
behavior. One can see people coding against this in routing software [2].

Besides fixing the problem of dropping membership on the first
interface, the effect of this patch is to restore the previous freebsd
behavior.

Cheers,

Stef

PS: BTW, I've been using the patch [1] for the imo_match_source panic,
that Shteryana posted. That fixes problems calling IP_ADD_MEMBERSHIP
twice with the same info.

[1] http://people.freebsd.org/~syrinx/mcast/in_mcast.c-20090908-01.diff

[2]
http://code.quagga.net/cgi-bin/gitweb.cgi?p=quagga.git;a=blob;f=lib/sockopt.c;h=55c6226b711e6386ef0378eb6def992af281082e;hb=HEAD#l196


-------------- next part --------------
A non-text attachment was scrubbed...
Name: freebsd-mcast-drop-eaddrnotavail.patch
Type: text/x-diff
Size: 401 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090909/5e59c357/freebsd-mcast-drop-eaddrnotavail.bin
From barney_cordoba at yahoo.com  Wed Sep  9 11:40:28 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Wed Sep  9 11:40:35 2009
Subject: em driver input errors
In-Reply-To: <200909082218.n88MI7TH073975@lava.sentex.ca>
Message-ID: <992693.15985.qm@web63902.mail.re1.yahoo.com>



--- On Tue, 9/8/09, Mike Tancsa <mike@sentex.net> wrote:

> From: Mike Tancsa <mike@sentex.net>
> Subject: Re: em driver input errors
> To: "Barney Cordoba" <barney_cordoba@yahoo.com>
> Cc: freebsd-net@freebsd.org
> Date: Tuesday, September 8, 2009, 6:21 PM
> At 05:42 PM 9/8/2009, Barney Cordoba
> wrote:
> > Manish What specific kinds of input errors are you
> getting? How many PPS are you doing, what is the size of the
> ring, and the interrupt modulation rate? Are the NICs PCIe
> or PCIx? Barney
> 
> In my case, our backup server (mix of dump via nfs and some
> dumps through ssh as well as writes via samba mounts) has a
> fairly low pps rate and starts to see input errors at about
> 100Mb.? Adding
> 
> hw.em.rxd=4096
> hw.em.txd=4096
> 
> and
> 
> net.inet.tcp.recvbuf_max=16777216
> net.inet.tcp.recvspace=131072
> net.inet.tcp.sendbuf_max=16777216
> net.inet.tcp.sendspace=131072
> net.inet.udp.recvspace=65536
> kern.ipc.somaxconn=1024
> kern.ipc.maxsockbuf=4194304
> net.inet.ip.redirect=0
> net.inet.ip.intr_queue_maxlen=4096
> net.route.netisr_maxqlen=1024
> kern.ipc.nmbclusters=655360
> 
> didnt seem to make a difference in the amount of errors I
> was seeing
> 
> 
> em1@pci0:7:5:0: class=0x020000 card=0x348f8086
> chip=0x10768086 rev=0x05 hdr=0x00
> ? ? vendor? ???= 'Intel
> Corporation'
> ? ? device? ???= 'Gigabit
> Ethernet Controller (82541EI)'
> ? ? class? ? ? = network
> ? ? subclass???= ethernet
> ? ? cap 01[dc] = powerspec 2? supports D0
> D3? current D0
> ? ? cap 07[e4] = PCI-X supports 2048 burst read,
> 1 split transaction
> 
>  Core(TM)2 Quad CPU? ? Q6600? @ 2.40GHz,
> AMD64, RELENG_7 from Jun 18th
> 
> Plenty of disk IO left and the CPUs doent seem to be taxed
> that much.
> 
> Sep? 8 00:02:01 backup3 kernel: em1: Excessive
> collisions = 0
> Sep? 8 00:02:01 backup3 kernel: em1: Sequence errors =
> 0
> Sep? 8 00:02:01 backup3 kernel: em1: Defer count = 0
> Sep? 8 00:02:01 backup3 kernel: em1: Missed Packets =
> 61316
> Sep? 8 00:02:01 backup3 kernel: em1: Receive No
> Buffers = 0
> Sep? 8 00:02:01 backup3 kernel: em1: Receive Length
> Errors = 0
> Sep? 8 00:02:01 backup3 kernel: em1: Receive errors =
> 0
> Sep? 8 00:02:01 backup3 kernel: em1: Crc errors = 0
> Sep? 8 00:02:01 backup3 kernel: em1: Alignment errors
> = 0
> Sep? 8 00:02:01 backup3 kernel: em1: Collision/Carrier
> extension errors = 0
> Sep? 8 00:02:01 backup3 kernel: em1: RX overruns =
> 22397
> Sep? 8 00:02:01 backup3 kernel: em1: watchdog timeouts
> = 0
> Sep? 8 00:02:01 backup3 kernel: em1: RX MSIX IRQ = 0
> TX MSIX IRQ = 0 LINK MSIX IRQ = 0
> Sep? 8 00:02:01 backup3 kernel: em1: XON Rcvd = 0
> Sep? 8 00:02:01 backup3 kernel: em1: XON Xmtd = 0
> Sep? 8 00:02:01 backup3 kernel: em1: XOFF Rcvd = 0
> Sep? 8 00:02:01 backup3 kernel: em1: XOFF Xmtd = 0
> Sep? 8 00:02:01 backup3 kernel: em1: Good Packets Rcvd
> = 544276980
> Sep? 8 00:02:01 backup3 kernel: em1: Good Packets Xmtd
> = 490475071
> Sep? 8 00:02:01 backup3 kernel: em1: TSO Contexts Xmtd
> = 0
> Sep? 8 00:02:01 backup3 kernel: em1: TSO Contexts
> Failed = 0
> 
> 
> pf is in the kernel as well
> 
> > _______________________________________________
> > 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"
> 
> --------------------------------------------------------------------
> Mike Tancsa,? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? tel +1 519 651 3400
> Sentex Communications,? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? mike@sentex.net
> Providing Internet since 1994? ? ? ?
> ? ? ? ? ? ? www.sentex.net
> Cambridge, Ontario Canada? ? ? ? ?
> ? ? ? ? ? ?
> ???www.sentex.net/mike
> 
> 

The 8241GI may not be able to handle full gigabit flows if its only
wired at 32-bit 33Mhz, which is only capable of bursting to 1Gb/s. With
a single NIC it likely just fine, but it a bridged or firewall type 
config you may just be seeing bus failures.

Barney



      
From barney_cordoba at yahoo.com  Wed Sep  9 11:47:56 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Wed Sep  9 11:48:02 2009
Subject: em driver input errors
In-Reply-To: <992693.15985.qm@web63902.mail.re1.yahoo.com>
Message-ID: <62894.21638.qm@web63904.mail.re1.yahoo.com>



--- On Wed, 9/9/09, Barney Cordoba <barney_cordoba@yahoo.com> wrote:

> From: Barney Cordoba <barney_cordoba@yahoo.com>
> Subject: Re: em driver input errors
> To: "Mike Tancsa" <mike@sentex.net>
> Cc: freebsd-net@freebsd.org
> Date: Wednesday, September 9, 2009, 7:40 AM
> 
> 
> --- On Tue, 9/8/09, Mike Tancsa <mike@sentex.net>
> wrote:
> 
> > From: Mike Tancsa <mike@sentex.net>
> > Subject: Re: em driver input errors
> > To: "Barney Cordoba" <barney_cordoba@yahoo.com>
> > Cc: freebsd-net@freebsd.org
> > Date: Tuesday, September 8, 2009, 6:21 PM
> > At 05:42 PM 9/8/2009, Barney Cordoba
> > wrote:
> > > Manish What specific kinds of input errors are
> you
> > getting? How many PPS are you doing, what is the size
> of the
> > ring, and the interrupt modulation rate? Are the NICs
> PCIe
> > or PCIx? Barney
> > 
> > In my case, our backup server (mix of dump via nfs and
> some
> > dumps through ssh as well as writes via samba mounts)
> has a
> > fairly low pps rate and starts to see input errors at
> about
> > 100Mb.? Adding
> > 
> > hw.em.rxd=4096
> > hw.em.txd=4096
> > 
> > and
> > 
> > net.inet.tcp.recvbuf_max=16777216
> > net.inet.tcp.recvspace=131072
> > net.inet.tcp.sendbuf_max=16777216
> > net.inet.tcp.sendspace=131072
> > net.inet.udp.recvspace=65536
> > kern.ipc.somaxconn=1024
> > kern.ipc.maxsockbuf=4194304
> > net.inet.ip.redirect=0
> > net.inet.ip.intr_queue_maxlen=4096
> > net.route.netisr_maxqlen=1024
> > kern.ipc.nmbclusters=655360
> > 
> > didnt seem to make a difference in the amount of
> errors I
> > was seeing
> > 
> > 
> > em1@pci0:7:5:0: class=0x020000 card=0x348f8086
> > chip=0x10768086 rev=0x05 hdr=0x00
> > ? ? vendor? ???= 'Intel
> > Corporation'
> > ? ? device? ???= 'Gigabit
> > Ethernet Controller (82541EI)'
> > ? ? class? ? ? = network
> > ? ? subclass???= ethernet
> > ? ? cap 01[dc] = powerspec 2? supports D0
> > D3? current D0
> > ? ? cap 07[e4] = PCI-X supports 2048 burst read,
> > 1 split transaction
> > 
> >? Core(TM)2 Quad CPU? ? Q6600? @ 2.40GHz,
> > AMD64, RELENG_7 from Jun 18th
> > 
> > Plenty of disk IO left and the CPUs doent seem to be
> taxed
> > that much.
> > 
> > Sep? 8 00:02:01 backup3 kernel: em1: Excessive
> > collisions = 0
> > Sep? 8 00:02:01 backup3 kernel: em1: Sequence errors
> =
> > 0
> > Sep? 8 00:02:01 backup3 kernel: em1: Defer count = 0
> > Sep? 8 00:02:01 backup3 kernel: em1: Missed Packets
> =
> > 61316
> > Sep? 8 00:02:01 backup3 kernel: em1: Receive No
> > Buffers = 0
> > Sep? 8 00:02:01 backup3 kernel: em1: Receive Length
> > Errors = 0
> > Sep? 8 00:02:01 backup3 kernel: em1: Receive errors
> =
> > 0
> > Sep? 8 00:02:01 backup3 kernel: em1: Crc errors = 0
> > Sep? 8 00:02:01 backup3 kernel: em1: Alignment
> errors
> > = 0
> > Sep? 8 00:02:01 backup3 kernel: em1:
> Collision/Carrier
> > extension errors = 0
> > Sep? 8 00:02:01 backup3 kernel: em1: RX overruns =
> > 22397
> > Sep? 8 00:02:01 backup3 kernel: em1: watchdog
> timeouts
> > = 0
> > Sep? 8 00:02:01 backup3 kernel: em1: RX MSIX IRQ = 0
> > TX MSIX IRQ = 0 LINK MSIX IRQ = 0
> > Sep? 8 00:02:01 backup3 kernel: em1: XON Rcvd = 0
> > Sep? 8 00:02:01 backup3 kernel: em1: XON Xmtd = 0
> > Sep? 8 00:02:01 backup3 kernel: em1: XOFF Rcvd = 0
> > Sep? 8 00:02:01 backup3 kernel: em1: XOFF Xmtd = 0
> > Sep? 8 00:02:01 backup3 kernel: em1: Good Packets
> Rcvd
> > = 544276980
> > Sep? 8 00:02:01 backup3 kernel: em1: Good Packets
> Xmtd
> > = 490475071
> > Sep? 8 00:02:01 backup3 kernel: em1: TSO Contexts
> Xmtd
> > = 0
> > Sep? 8 00:02:01 backup3 kernel: em1: TSO Contexts
> > Failed = 0
> > 
> > 
> > pf is in the kernel as well
> > 
> > > _______________________________________________
> > > 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"
> > 
> >
> --------------------------------------------------------------------
> > Mike Tancsa,? ? ? ? ? ?
> > ? ? ? ? ? ? ? ?
> > ? ? ? ? ? tel +1 519 651 3400
> > Sentex Communications,? ? ? ? ?
> > ? ? ? ? ? ? ? ?
> > ? mike@sentex.net
> > Providing Internet since 1994? ? ? ?
> > ? ? ? ? ? ? www.sentex.net
> > Cambridge, Ontario Canada? ? ? ? ?
> > ? ? ? ? ? ?
> > ???www.sentex.net/mike
> > 
> > 
> 
> The 8241GI may not be able to handle full gigabit flows if
> its only
> wired at 32-bit 33Mhz, which is only capable of bursting to
> 1Gb/s. With
> a single NIC it likely just fine, but it a bridged or
> firewall type 
> config you may just be seeing bus failures.
> 
> Barney

I meant 82541EI...Same answer.


      
From nevtic at area51.capnet.state.tx.us  Wed Sep  9 13:20:02 2009
From: nevtic at area51.capnet.state.tx.us (stuart cur)
Date: Wed Sep  9 13:20:29 2009
Subject: 8.0-B4, Broadcom bge0 not working, HP Proliant DL385, amd64
Message-ID: <alpine.BSF.2.00.0909081113220.98111@area51.capnet.state.tx.us>

In 8.0-B4 for amd64, bge does not recognize that there is an active 
ethernet connection on bge0.  Switching the cable to bge1 works correctly.

This seems to be the same issue as reported on July 21 by Oyvind Rakvag, 
but I saw no response to that report.

Attached are the dmesg.boot, /var/log/messages, and output of pciconf -lv 
from the very first boot.

stu
-------------- next part --------------
Sep  8 15:51:17  newsyslog[775]: logfile first created
Sep  8 15:51:17  syslogd: kernel boot file is /boot/kernel/kernel
Sep  8 15:51:17  kernel: Copyright (c) 1992-2009 The FreeBSD Project.
Sep  8 15:51:17  kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
Sep  8 15:51:17  kernel: The Regents of the University of California. All rights reserved.
Sep  8 15:51:17  kernel: FreeBSD is a registered trademark of The FreeBSD Foundation.
Sep  8 15:51:17  kernel: FreeBSD 8.0-BETA4 #0: Sun Sep  6 04:44:31 UTC 2009
Sep  8 15:51:17  kernel: root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
Sep  8 15:51:17  kernel: WARNING: WITNESS option enabled, expect reduced performance.
Sep  8 15:51:17  kernel: Timecounter "i8254" frequency 1193182 Hz quality 0
Sep  8 15:51:17  kernel: CPU: AMD Opteron(tm) Processor 270 (2004.55-MHz K8-class CPU)
Sep  8 15:51:17  kernel: Origin = "AuthenticAMD"  Id = 0x20f12  Stepping = 2
Sep  8 15:51:17  kernel: Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
Sep  8 15:51:17  kernel: Features2=0x1<SSE3>
Sep  8 15:51:17  kernel: AMD Features=0xe2500800<SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow!>
Sep  8 15:51:17  kernel: AMD Features2=0x2<CMP>
Sep  8 15:51:17  kernel: real memory  = 2147483648 (2048 MB)
Sep  8 15:51:17  kernel: avail memory = 2054406144 (1959 MB)
Sep  8 15:51:17  kernel: ACPI APIC Table: <HP     00000083>
Sep  8 15:51:17  kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
Sep  8 15:51:17  kernel: FreeBSD/SMP: 1 package(s) x 2 core(s)
Sep  8 15:51:17  kernel: cpu0 (BSP): APIC ID:  0
Sep  8 15:51:17  kernel: cpu1 (AP): APIC ID:  1
Sep  8 15:51:17  kernel: ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16 20090521 tbfadt-707
Sep  8 15:51:17  kernel: ACPI Warning: Invalid length for Pm1bControlBlock: 32, using default 16 20090521 tbfadt-707
Sep  8 15:51:17  kernel: MADT: Forcing active-low polarity and level trigger for SCI
Sep  8 15:51:17  kernel: ioapic0 <Version 1.1> irqs 0-23 on motherboard
Sep  8 15:51:17  kernel: ioapic1 <Version 1.1> irqs 24-27 on motherboard
Sep  8 15:51:17  kernel: ioapic2 <Version 1.1> irqs 28-31 on motherboard
Sep  8 15:51:17  kernel: ioapic3 <Version 1.1> irqs 32-35 on motherboard
Sep  8 15:51:17  kernel: ioapic4 <Version 1.1> irqs 36-39 on motherboard
Sep  8 15:51:17  kernel: kbd1 at kbdmux0
Sep  8 15:51:17  kernel: acpi0: <HP A05> on motherboard
Sep  8 15:51:17  kernel: acpi0: [ITHREAD]
Sep  8 15:51:17  kernel: acpi0: Power Button (fixed)
Sep  8 15:51:17  kernel: Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
Sep  8 15:51:17  kernel: acpi_timer0: <32-bit timer at 3.579545MHz> port 0x908-0x90b on acpi0
Sep  8 15:51:17  kernel: pcib0: <ACPI Host-PCI bridge> on acpi0
Sep  8 15:51:17  kernel: pci0: <ACPI PCI bus> on pcib0
Sep  8 15:51:17  kernel: pcib1: <ACPI PCI-PCI bridge> at device 3.0 on pci0
Sep  8 15:51:17  kernel: pci1: <ACPI PCI bus> on pcib1
Sep  8 15:51:17  kernel: ohci0: <OHCI (generic) USB controller> mem 0xf7cf0000-0xf7cf0fff irq 19 at device 0.0 on pci1
Sep  8 15:51:17  kernel: ohci0: [ITHREAD]
Sep  8 15:51:17  kernel: usbus0: <OHCI (generic) USB controller> on ohci0
Sep  8 15:51:17  kernel: ohci1: <OHCI (generic) USB controller> mem 0xf7ce0000-0xf7ce0fff irq 19 at device 0.1 on pci1
Sep  8 15:51:17  kernel: ohci1: [ITHREAD]
Sep  8 15:51:17  kernel: usbus1: <OHCI (generic) USB controller> on ohci1
Sep  8 15:51:17  kernel: pci1: <base peripheral> at device 2.0 (no driver attached)
Sep  8 15:51:17  kernel: pci1: <base peripheral> at device 2.2 (no driver attached)
Sep  8 15:51:17  kernel: vgapci0: <VGA-compatible display> port 0x4400-0x44ff mem 0xf6000000-0xf6ffffff,0xf5ff0000-0xf5ff0fff at device 3.0 on pci1
Sep  8 15:51:17  kernel: isab0: <PCI-ISA bridge> at device 4.0 on pci0
Sep  8 15:51:17  kernel: isa0: <ISA bus> on isab0
Sep  8 15:51:17  kernel: atapci0: <AMD 8111 UDMA133 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x2000-0x200f at device 4.1 on pci0
Sep  8 15:51:17  kernel: ata0: <ATA channel 0> on atapci0
Sep  8 15:51:17  kernel: ata0: [ITHREAD]
Sep  8 15:51:17  kernel: ata1: <ATA channel 1> on atapci0
Sep  8 15:51:17  kernel: ata1: [ITHREAD]
Sep  8 15:51:17  kernel: pci0: <bridge> at device 4.3 (no driver attached)
Sep  8 15:51:17  kernel: pcib2: <ACPI PCI-PCI bridge> at device 7.0 on pci0
Sep  8 15:51:17  kernel: pci2: <ACPI PCI bus> on pcib2
Sep  8 15:51:17  kernel: ciss0: <HP Smart Array 6i> port 0x5000-0x50ff mem 0xf7df0000-0xf7df1fff,0xf7d80000-0xf7dbffff irq 24 at device 4.0 on pci2
Sep  8 15:51:17  kernel: ciss0: PERFORMANT Transport
Sep  8 15:51:17  kernel: ciss0: [ITHREAD]
Sep  8 15:51:17  kernel: pcib3: <ACPI PCI-PCI bridge> at device 8.0 on pci0
Sep  8 15:51:17  kernel: pci3: <ACPI PCI bus> on pcib3
Sep  8 15:51:17  kernel: bge0: <HP NC7782 Gigabit Server Adapter, ASIC rev. 0x2100> mem 0xf7ef0000-0xf7efffff irq 28 at device 6.0 on pci3
Sep  8 15:51:17  kernel: miibus0: <MII bus> on bge0
Sep  8 15:51:17  kernel: brgphy0: <BCM5704 10/100/1000baseTX PHY> PHY 1 on miibus0
Sep  8 15:51:17  kernel: brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
Sep  8 15:51:17  kernel: bge0: Ethernet address: 00:17:a4:a7:eb:e4
Sep  8 15:51:17  kernel: bge0: [ITHREAD]
Sep  8 15:51:17  kernel: bge1: <HP NC7782 Gigabit Server Adapter, ASIC rev. 0x2100> mem 0xf7ee0000-0xf7eeffff irq 29 at device 6.1 on pci3
Sep  8 15:51:17  kernel: miibus1: <MII bus> on bge1
Sep  8 15:51:17  kernel: brgphy1: <BCM5704 10/100/1000baseTX PHY> PHY 1 on miibus1
Sep  8 15:51:17  kernel: brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
Sep  8 15:51:17  kernel: bge1: Ethernet address: 00:17:a4:a7:eb:e3
Sep  8 15:51:17  kernel: bge1: [ITHREAD]
Sep  8 15:51:17  kernel: pcib4: <ACPI Host-PCI bridge> on acpi0
Sep  8 15:51:17  kernel: pci4: <ACPI PCI bus> on pcib4
Sep  8 15:51:17  kernel: pcib5: <ACPI PCI-PCI bridge> at device 9.0 on pci4
Sep  8 15:51:17  kernel: pci5: <ACPI PCI bus> on pcib5
Sep  8 15:51:17  kernel: rl0: <RealTek 8139 10/100BaseTX> port 0x6000-0x60ff mem 0xf7ff0000-0xf7ff00ff irq 32 at device 8.0 on pci5
Sep  8 15:51:17  kernel: miibus2: <MII bus> on rl0
Sep  8 15:51:17  kernel: rlphy0: <RealTek internal media interface> PHY 0 on miibus2
Sep  8 15:51:17  kernel: rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
Sep  8 15:51:17  kernel: rl0: Ethernet address: 00:40:f4:ed:99:ec
Sep  8 15:51:17  kernel: rl0: [ITHREAD]
Sep  8 15:51:17  kernel: pcib6: <ACPI PCI-PCI bridge> at device 10.0 on pci4
Sep  8 15:51:17  kernel: pci6: <ACPI PCI bus> on pcib6
Sep  8 15:51:17  kernel: atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
Sep  8 15:51:17  kernel: atkbd0: <AT Keyboard> irq 1 on atkbdc0
Sep  8 15:51:17  kernel: kbd0 at atkbd0
Sep  8 15:51:17  kernel: atkbd0: [GIANT-LOCKED]
Sep  8 15:51:17  kernel: atkbd0: [ITHREAD]
Sep  8 15:51:17  kernel: psm0: <PS/2 Mouse> irq 12 on atkbdc0
Sep  8 15:51:17  kernel: psm0: [GIANT-LOCKED]
Sep  8 15:51:17  kernel: psm0: [ITHREAD]
Sep  8 15:51:17  kernel: psm0: model Generic PS/2 mouse, device ID 0
Sep  8 15:51:17  kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
Sep  8 15:51:17  kernel: uart0: [FILTER]
Sep  8 15:51:17  kernel: fdc0: <floppy drive controller (FDE)> port 0x3f2-0x3f5 irq 6 drq 2 on acpi0
Sep  8 15:51:17  kernel: fdc0: [FILTER]
Sep  8 15:51:17  kernel: cpu0: <ACPI CPU> on acpi0
Sep  8 15:51:17  kernel: powernow0: <Cool`n'Quiet K8> on cpu0
Sep  8 15:51:17  kernel: cpu1: <ACPI CPU> on acpi0
Sep  8 15:51:17  kernel: powernow1: <Cool`n'Quiet K8> on cpu1
Sep  8 15:51:17  kernel: orm0: <ISA Option ROMs> at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff,0xee000-0xeffff on isa0
Sep  8 15:51:17  kernel: sc0: <System console> at flags 0x100 on isa0
Sep  8 15:51:17  kernel: sc0: VGA <16 virtual consoles, flags=0x300>
Sep  8 15:51:17  kernel: vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
Sep  8 15:51:17  kernel: atrtc0: <AT Real Time Clock> at port 0x70 irq 8 on isa0
Sep  8 15:51:17  kernel: ppc0: cannot reserve I/O port range
Sep  8 15:51:17  kernel: uart1: <Non-standard ns8250 class UART with FIFOs> at port 0x2f8-0x2ff irq 3 on isa0
Sep  8 15:51:17  kernel: uart1: [FILTER]
Sep  8 15:51:17  kernel: Timecounters tick every 1.000 msec
Sep  8 15:51:17  kernel: usbus0: 12Mbps Full Speed USB v1.0
Sep  8 15:51:17  kernel: usbus1: 12Mbps Full Speed USB v1.0
Sep  8 15:51:17  kernel: ugen0.1: <AMD> at usbus0
Sep  8 15:51:17  kernel: uhub0: <AMD OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
Sep  8 15:51:17  kernel: ugen1.1: <AMD> at usbus1
Sep  8 15:51:17  kernel: uhub1: <AMD OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
Sep  8 15:51:17  kernel: acd0: CDRW <DW-224E-R/C.AB> at ata0-master UDMA33
Sep  8 15:51:17  kernel: uhub0: 3 ports with 3 removable, self powered
Sep  8 15:51:17  kernel: uhub1: 3 ports with 3 removable, self powered
Sep  8 15:51:17  kernel: da0 at ciss0 bus 0 target 0 lun 0
Sep  8 15:51:17  kernel: da0: <COMPAQ RAID 1  VOLUME OK> Fixed Direct Access SCSI-4 device 
Sep  8 15:51:17  kernel: da0: 135.168MB/s transfers
Sep  8 15:51:17  kernel: da0: Command Queueing enabled
Sep  8 15:51:17  kernel: da0: 70001MB (143363040 512 byte sectors: 255H 32S/T 17569C)
Sep  8 15:51:17  kernel: da1 at ciss0 bus 0 target 1 lun 0
Sep  8 15:51:17  kernel: da1: <COMPAQ RAID 1  VOLUME OK> Fixed Direct Access SCSI-4 device 
Sep  8 15:51:17  kernel: da1: 135.168MB/s transfers
Sep  8 15:51:17  kernel: da1: Command Queueing enabled
Sep  8 15:51:17  kernel: da1: 286097MB (585928220 512 byte sectors: 255H 32S/T 65535C)
Sep  8 15:51:17  kernel: SMP: AP CPU #1 Launched!
Sep  8 15:51:17  kernel: WARNING: WITNESS option enabled, expect reduced performance.
Sep  8 15:51:17  kernel: GEOM: da0: partition 1 does not start on a track boundary.
Sep  8 15:51:17  kernel: GEOM: da0: partition 1 does not end on a track boundary.
Sep  8 15:51:17  kernel: GEOM: da0s1: geometry does not match label (255h,63s != 255h,32s).
Sep  8 15:51:17  kernel: GEOM: da1: partition 1 does not start on a track boundary.
Sep  8 15:51:17  kernel: GEOM: da1: partition 1 does not end on a track boundary.
Sep  8 15:51:17  kernel: GEOM: da1s1: geometry does not match label (255h,63s != 255h,32s).
Sep  8 15:51:17  kernel: Trying to mount root from ufs:/dev/da0s1a
Sep  8 15:51:28  login: ROOT LOGIN (root) ON ttyv1
Sep  8 15:52:12  kernel: bge1: link state changed to UP
Sep  8 15:52:51  kernel: bge1: link state changed to DOWN
Sep  8 15:52:53  kernel: bge1: link state changed to UP
Sep  8 15:53:49  kernel: bge1: promiscuous mode enabled
Sep  8 15:54:12  kernel: bge1: promiscuous mode disabled
Sep  8 15:59:19  root: Unknown USB device: vendor 0x13fe product 0x1a21 bus uhub1
Sep  8 15:59:19  kernel: ugen1.2: <vendor 0x13fe> at usbus1
Sep  8 15:59:19  kernel: umass0: <vendor 0x13fe USB DISK Pro, class 0/0, rev 2.00/1.00, addr 2> on usbus1
Sep  8 15:59:19  kernel: umass0:  SCSI over Bulk-Only; quirks = 0x0000
Sep  8 15:59:20  kernel: umass0:3:0:-1: Attached to scbus3
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:0): CAM Status: SCSI Status Error
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:0): SCSI Status: Check Condition
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:0): UNIT ATTENTION asc:28,0
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:0): Not ready to ready change, medium may have changed
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:0): Retrying Command (per Sense Data)
Sep  8 15:59:21  kernel: da2 at umass-sim0 bus 0 target 0 lun 0
Sep  8 15:59:21  kernel: da2: < USB DISK Pro PMAP> Removable Direct Access SCSI-0 device 
Sep  8 15:59:21  kernel: da2: 1.000MB/s transfers
Sep  8 15:59:21  kernel: da2: 1941MB (3976192 512 byte sectors: 255H 63S/T 247C)
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:1): TEST UNIT READY. CDB: 0 20 0 0 0 0 
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:1): CAM Status: SCSI Status Error
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:1): SCSI Status: Check Condition
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:1): UNIT ATTENTION asc:28,0
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:1): Not ready to ready change, medium may have changed
Sep  8 15:59:21  kernel: (probe0:umass-sim0:0:0:1): Retrying Command (per Sense Data)
Sep  8 15:59:21  kernel: da3 at umass-sim0 bus 0 target 0 lun 1
Sep  8 15:59:21  kernel: da3: < USB DISK Pro PMAP> Removable Direct Access SCSI-0 device 
Sep  8 15:59:21  kernel: da3: 1.000MB/s transfers
Sep  8 15:59:21  kernel: da3: 24MB (50176 512 byte sectors: 64H 32S/T 24C)
Sep  8 15:59:22  kernel: GEOM: da2: partition 1 does not start on a track boundary.
Sep  8 15:59:22  kernel: GEOM: da2: partition 1 does not end on a track boundary.
-------------- next part --------------
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-BETA4 #0: Sun Sep  6 04:44:31 UTC 2009
    root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
WARNING: WITNESS option enabled, expect reduced performance.
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: AMD Opteron(tm) Processor 270 (2004.55-MHz K8-class CPU)
  Origin = "AuthenticAMD"  Id = 0x20f12  Stepping = 2
  Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x1<SSE3>
  AMD Features=0xe2500800<SYSCALL,NX,MMX+,FFXSR,LM,3DNow!+,3DNow!>
  AMD Features2=0x2<CMP>
real memory  = 2147483648 (2048 MB)
avail memory = 2054406144 (1959 MB)
ACPI APIC Table: <HP     00000083>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1
ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16 20090521 tbfadt-707
ACPI Warning: Invalid length for Pm1bControlBlock: 32, using default 16 20090521 tbfadt-707
MADT: Forcing active-low polarity and level trigger for SCI
ioapic0 <Version 1.1> irqs 0-23 on motherboard
ioapic1 <Version 1.1> irqs 24-27 on motherboard
ioapic2 <Version 1.1> irqs 28-31 on motherboard
ioapic3 <Version 1.1> irqs 32-35 on motherboard
ioapic4 <Version 1.1> irqs 36-39 on motherboard
kbd1 at kbdmux0
acpi0: <HP A05> on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
acpi_timer0: <32-bit timer at 3.579545MHz> port 0x908-0x90b on acpi0
pcib0: <ACPI Host-PCI bridge> on acpi0
pci0: <ACPI PCI bus> on pcib0
pcib1: <ACPI PCI-PCI bridge> at device 3.0 on pci0
pci1: <ACPI PCI bus> on pcib1
ohci0: <OHCI (generic) USB controller> mem 0xf7cf0000-0xf7cf0fff irq 19 at device 0.0 on pci1
ohci0: [ITHREAD]
usbus0: <OHCI (generic) USB controller> on ohci0
ohci1: <OHCI (generic) USB controller> mem 0xf7ce0000-0xf7ce0fff irq 19 at device 0.1 on pci1
ohci1: [ITHREAD]
usbus1: <OHCI (generic) USB controller> on ohci1
pci1: <base peripheral> at device 2.0 (no driver attached)
pci1: <base peripheral> at device 2.2 (no driver attached)
vgapci0: <VGA-compatible display> port 0x4400-0x44ff mem 0xf6000000-0xf6ffffff,0xf5ff0000-0xf5ff0fff at device 3.0 on pci1
isab0: <PCI-ISA bridge> at device 4.0 on pci0
isa0: <ISA bus> on isab0
atapci0: <AMD 8111 UDMA133 controller> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x2000-0x200f at device 4.1 on pci0
ata0: <ATA channel 0> on atapci0
ata0: [ITHREAD]
ata1: <ATA channel 1> on atapci0
ata1: [ITHREAD]
pci0: <bridge> at device 4.3 (no driver attached)
pcib2: <ACPI PCI-PCI bridge> at device 7.0 on pci0
pci2: <ACPI PCI bus> on pcib2
ciss0: <HP Smart Array 6i> port 0x5000-0x50ff mem 0xf7df0000-0xf7df1fff,0xf7d80000-0xf7dbffff irq 24 at device 4.0 on pci2
ciss0: PERFORMANT Transport
ciss0: [ITHREAD]
pcib3: <ACPI PCI-PCI bridge> at device 8.0 on pci0
pci3: <ACPI PCI bus> on pcib3
bge0: <HP NC7782 Gigabit Server Adapter, ASIC rev. 0x2100> mem 0xf7ef0000-0xf7efffff irq 28 at device 6.0 on pci3
miibus0: <MII bus> on bge0
brgphy0: <BCM5704 10/100/1000baseTX PHY> PHY 1 on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
bge0: Ethernet address: 00:17:a4:a7:eb:e4
bge0: [ITHREAD]
bge1: <HP NC7782 Gigabit Server Adapter, ASIC rev. 0x2100> mem 0xf7ee0000-0xf7eeffff irq 29 at device 6.1 on pci3
miibus1: <MII bus> on bge1
brgphy1: <BCM5704 10/100/1000baseTX PHY> PHY 1 on miibus1
brgphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
bge1: Ethernet address: 00:17:a4:a7:eb:e3
bge1: [ITHREAD]
pcib4: <ACPI Host-PCI bridge> on acpi0
pci4: <ACPI PCI bus> on pcib4
pcib5: <ACPI PCI-PCI bridge> at device 9.0 on pci4
pci5: <ACPI PCI bus> on pcib5
rl0: <RealTek 8139 10/100BaseTX> port 0x6000-0x60ff mem 0xf7ff0000-0xf7ff00ff irq 32 at device 8.0 on pci5
miibus2: <MII bus> on rl0
rlphy0: <RealTek internal media interface> PHY 0 on miibus2
rlphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
rl0: Ethernet address: 00:40:f4:ed:99:ec
rl0: [ITHREAD]
pcib6: <ACPI PCI-PCI bridge> at device 10.0 on pci4
pci6: <ACPI PCI bus> on pcib6
atkbdc0: <Keyboard controller (i8042)> port 0x60,0x64 irq 1 on acpi0
atkbd0: <AT Keyboard> irq 1 on atkbdc0
kbd0 at atkbd0
atkbd0: [GIANT-LOCKED]
atkbd0: [ITHREAD]
psm0: <PS/2 Mouse> irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
psm0: [ITHREAD]
psm0: model Generic PS/2 mouse, device ID 0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: [FILTER]
fdc0: <floppy drive controller (FDE)> port 0x3f2-0x3f5 irq 6 drq 2 on acpi0
fdc0: [FILTER]
cpu0: <ACPI CPU> on acpi0
powernow0: <Cool`n'Quiet K8> on cpu0
cpu1: <ACPI CPU> on acpi0
powernow1: <Cool`n'Quiet K8> on cpu1
orm0: <ISA Option ROMs> at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff,0xee000-0xeffff on isa0
sc0: <System console> at flags 0x100 on isa0
sc0: VGA <16 virtual consoles, flags=0x300>
vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
atrtc0: <AT Real Time Clock> at port 0x70 irq 8 on isa0
ppc0: cannot reserve I/O port range
uart1: <Non-standard ns8250 class UART with FIFOs> at port 0x2f8-0x2ff irq 3 on isa0
uart1: [FILTER]
Timecounters tick every 1.000 msec
usbus0: 12Mbps Full Speed USB v1.0
usbus1: 12Mbps Full Speed USB v1.0
ugen0.1: <AMD> at usbus0
uhub0: <AMD OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
ugen1.1: <AMD> at usbus1
uhub1: <AMD OHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
acd0: CDRW <DW-224E-R/C.AB> at ata0-master UDMA33
uhub0: 3 ports with 3 removable, self powered
uhub1: 3 ports with 3 removable, self powered
da0 at ciss0 bus 0 target 0 lun 0
da0: <COMPAQ RAID 1  VOLUME OK> Fixed Direct Access SCSI-4 device 
da0: 135.168MB/s transfers
da0: Command Queueing enabled
da0: 70001MB (143363040 512 byte sectors: 255H 32S/T 17569C)
da1 at ciss0 bus 0 target 1 lun 0
da1: <COMPAQ RAID 1  VOLUME OK> Fixed Direct Access SCSI-4 device 
da1: 135.168MB/s transfers
da1: Command Queueing enabled
da1: 286097MB (585928220 512 byte sectors: 255H 32S/T 65535C)
SMP: AP CPU #1 Launched!
WARNING: WITNESS option enabled, expect reduced performance.
GEOM: da0: partition 1 does not start on a track boundary.
GEOM: da0: partition 1 does not end on a track boundary.
GEOM: da0s1: geometry does not match label (255h,63s != 255h,32s).
GEOM: da1: partition 1 does not start on a track boundary.
GEOM: da1: partition 1 does not end on a track boundary.
GEOM: da1s1: geometry does not match label (255h,63s != 255h,32s).
Trying to mount root from ufs:/dev/da0s1a
-------------- next part --------------
pcib1@pci0:0:3:0:	class=0x060400 card=0x00000000 chip=0x74601022 rev=0x07 hdr=0x01
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI Bridge (AMD-8111)'
    class      = bridge
    subclass   = PCI-PCI
isab0@pci0:0:4:0:	class=0x060100 card=0x32030e11 chip=0x74681022 rev=0x05 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'LPC Bridge (AMD-8111)'
    class      = bridge
    subclass   = PCI-ISA
atapci0@pci0:0:4:1:	class=0x01018a card=0x32040e11 chip=0x74691022 rev=0x03 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'UltraATA/133 Controller (AMD-8111)'
    class      = mass storage
    subclass   = ATA
none0@pci0:0:4:3:	class=0x068000 card=0x32050e11 chip=0x746b1022 rev=0x05 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'AMD-8111 ACPI System Management Controller'
    class      = bridge
pcib2@pci0:0:7:0:	class=0x060400 card=0x00000000 chip=0x74501022 rev=0x12 hdr=0x01
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI-X Bridge (AMD-8131)'
    class      = bridge
    subclass   = PCI-PCI
ioapic0@pci0:0:7:1:	class=0x080010 card=0x00000000 chip=0x74511022 rev=0x01 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI-X IOAPIC (AMD-8131)'
    class      = base peripheral
    subclass   = interrupt controller
pcib3@pci0:0:8:0:	class=0x060400 card=0x00000000 chip=0x74501022 rev=0x12 hdr=0x01
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI-X Bridge (AMD-8131)'
    class      = bridge
    subclass   = PCI-PCI
ioapic1@pci0:0:8:1:	class=0x080010 card=0x00000000 chip=0x74511022 rev=0x01 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI-X IOAPIC (AMD-8131)'
    class      = base peripheral
    subclass   = interrupt controller
hostb0@pci0:0:24:0:	class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'Athlon64/Opteron/Sempron (K8 Family) HyperTransport Technology Configuration'
    class      = bridge
    subclass   = HOST-PCI
hostb1@pci0:0:24:1:	class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'Athlon64/Opteron/Sempron (K8 Family) Address Map'
    class      = bridge
    subclass   = HOST-PCI
hostb2@pci0:0:24:2:	class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'Athlon64/Opteron/Sempron (K8 Family) DRAM Controller'
    class      = bridge
    subclass   = HOST-PCI
hostb3@pci0:0:24:3:	class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'Athlon64/Opteron/Sempron (K8 Family) Miscellaneous Control'
    class      = bridge
    subclass   = HOST-PCI
ohci0@pci0:1:0:0:	class=0x0c0310 card=0x32020e11 chip=0x74641022 rev=0x0b hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'USB OpenHCI Host Controller (AMD-8111)'
    class      = serial bus
    subclass   = USB
ohci1@pci0:1:0:1:	class=0x0c0310 card=0x32020e11 chip=0x74641022 rev=0x0b hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'USB OpenHCI Host Controller (AMD-8111)'
    class      = serial bus
    subclass   = USB
none1@pci0:1:2:0:	class=0x088000 card=0xb2060e11 chip=0xb2030e11 rev=0x01 hdr=0x00
    vendor     = 'Compaq Computer Corp (Now owned by Hewlett-Packard)'
    device     = 'Integrated Lights Out Processor (iLo)'
    class      = base peripheral
none2@pci0:1:2:2:	class=0x088000 card=0xb2060e11 chip=0xb2040e11 rev=0x01 hdr=0x00
    vendor     = 'Compaq Computer Corp (Now owned by Hewlett-Packard)'
    device     = 'Integrated Lights Out Processor (iLo)'
    class      = base peripheral
vgapci0@pci0:1:3:0:	class=0x030000 card=0x001e0e11 chip=0x47521002 rev=0x27 hdr=0x00
    vendor     = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.'
    device     = 'ATI On-Board VGA for HP Proliant 350 G3 (Rage XL PCI)'
    class      = display
    subclass   = VGA
ciss0@pci0:2:4:0:	class=0x010400 card=0x40910e11 chip=0x00460e11 rev=0x01 hdr=0x00
    vendor     = 'Compaq Computer Corp (Now owned by Hewlett-Packard)'
    device     = 'Smart Array 64xx/6i Controller'
    class      = mass storage
    subclass   = RAID
bge0@pci0:3:6:0:	class=0x020000 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00
    vendor     = 'Broadcom Corporation'
    device     = 'NetXtreme Dual Gigabit Adapter (BCM5704)'
    class      = network
    subclass   = ethernet
bge1@pci0:3:6:1:	class=0x020000 card=0x00d00e11 chip=0x164814e4 rev=0x10 hdr=0x00
    vendor     = 'Broadcom Corporation'
    device     = 'NetXtreme Dual Gigabit Adapter (BCM5704)'
    class      = network
    subclass   = ethernet
pcib5@pci0:4:9:0:	class=0x060400 card=0x00000000 chip=0x74501022 rev=0x12 hdr=0x01
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI-X Bridge (AMD-8131)'
    class      = bridge
    subclass   = PCI-PCI
ioapic2@pci0:4:9:1:	class=0x080010 card=0x00000000 chip=0x74511022 rev=0x01 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI-X IOAPIC (AMD-8131)'
    class      = base peripheral
    subclass   = interrupt controller
pcib6@pci0:4:10:0:	class=0x060400 card=0x00000000 chip=0x74501022 rev=0x12 hdr=0x01
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI-X Bridge (AMD-8131)'
    class      = bridge
    subclass   = PCI-PCI
ioapic3@pci0:4:10:1:	class=0x080010 card=0x00000000 chip=0x74511022 rev=0x01 hdr=0x00
    vendor     = 'Advanced Micro Devices (AMD)'
    device     = 'PCI-X IOAPIC (AMD-8131)'
    class      = base peripheral
    subclass   = interrupt controller
rl0@pci0:5:8:0:	class=0x020000 card=0xc10f1259 chip=0x813910ec rev=0x10 hdr=0x00
    vendor     = 'Realtek Semiconductor'
    device     = 'Realtek RTL8139 Family PCI Fast Ethernet NIC (RTL-8139/8139C/8139C)'
    class      = network
    subclass   = ethernet
From mike at sentex.net  Wed Sep  9 13:55:57 2009
From: mike at sentex.net (Mike Tancsa)
Date: Wed Sep  9 13:56:03 2009
Subject: em driver input errors
In-Reply-To: <62894.21638.qm@web63904.mail.re1.yahoo.com>
References: <992693.15985.qm@web63902.mail.re1.yahoo.com>
	<62894.21638.qm@web63904.mail.re1.yahoo.com>
Message-ID: <200909091352.n89DqQDx079631@lava.sentex.ca>

At 07:47 AM 9/9/2009, Barney Cordoba wrote:
>    www.sentex.net/mike > > > > > > The 8241GI may not be able to 
> handle full gigabit flows if > its only > wired at 32-bit 33Mhz, 
> which is only capable of bursting to > 1Gb/s. With > a single NIC 
> it likely just fine, but it a bridged or > firewall type > config 
> you may just be seeing bus failures. > > Barney I meant 
> 82541EI...Same answer.


Both of the NICs on this motherboard are wired in.  I will see if 
there is a spare pcie slot and try a different em nic.  Its also a 
single nic. No bridge or forwarding as all the packets are destined 
to the machine itself.

         ---Mike

>_______________________________________________
>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"

--------------------------------------------------------------------
Mike Tancsa,                                      tel +1 519 651 3400
Sentex Communications,                            mike@sentex.net
Providing Internet since 1994                    www.sentex.net
Cambridge, Ontario Canada                         www.sentex.net/mike

From barney_cordoba at yahoo.com  Wed Sep  9 14:19:32 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Wed Sep  9 14:19:39 2009
Subject: em driver input errors
In-Reply-To: <200909091352.n89DqQDx079631@lava.sentex.ca>
Message-ID: <538232.7388.qm@web63901.mail.re1.yahoo.com>



--- On Wed, 9/9/09, Mike Tancsa <mike@sentex.net> wrote:

> From: Mike Tancsa <mike@sentex.net>
> Subject: Re: em driver input errors
> To: "Barney Cordoba" <barney_cordoba@yahoo.com>
> Cc: freebsd-net@freebsd.org
> Date: Wednesday, September 9, 2009, 9:55 AM
> At 07:47 AM 9/9/2009, Barney Cordoba
> wrote:
> >? ? www.sentex.net/mike > > > >
> > > The 8241GI may not be able to handle full gigabit
> flows if > its only > wired at 32-bit 33Mhz, which is
> only capable of bursting to > 1Gb/s. With > a single
> NIC it likely just fine, but it a bridged or > firewall
> type > config you may just be seeing bus failures. >
> > Barney I meant 82541EI...Same answer.
> 
> 
> Both of the NICs on this motherboard are wired in.? I
> will see if there is a spare pcie slot and try a different
> em nic.? Its also a single nic. No bridge or forwarding
> as all the packets are destined to the machine itself.
> 
> ? ? ? ? ---Mike
> 
> > _______________________________________________
> > 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"
> 
> --------------------------------------------------------------------
> Mike Tancsa,? ? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? ? ? ? ? tel +1 519 651 3400
> Sentex Communications,? ? ? ? ?
> ? ? ? ? ? ? ? ?
> ? mike@sentex.net
> Providing Internet since 1994? ? ? ?
> ? ? ? ? ? ? www.sentex.net
> Cambridge, Ontario Canada? ? ? ? ?

A quick test would be to force it to 100Mb/s to see if the problem goes
away.  I see you are using em1 which implies another NIC...if you have
traffic on the other lan its not much different than

Also, realize that most pciX busses are shared. So your disk and other
devices may be sharing. Its really derilect for these MB manufacturers
to sell dual gig nic systems and them wire them to a slow bus. But its
what they do.

Barney


      
From gavin at FreeBSD.org  Wed Sep  9 14:29:02 2009
From: gavin at FreeBSD.org (gavin@FreeBSD.org)
Date: Wed Sep  9 14:29:11 2009
Subject: kern/138652: TCP window scaling value calculated incorrectly?
Message-ID: <200909091429.n89ET1Ce010630@freefall.freebsd.org>

Old Synopsis: TCP window scaling value
New Synopsis: TCP window scaling value calculated incorrectly?

State-Changed-From-To: feedback->open
State-Changed-By: gavin
State-Changed-When: Wed Sep 9 14:24:24 UTC 2009
State-Changed-Why: 
Over to maintainer(s) for investigation


Responsible-Changed-From-To: gavin->freebsd-net
Responsible-Changed-By: gavin
Responsible-Changed-When: Wed Sep 9 14:24:24 UTC 2009
Responsible-Changed-Why: 
Feedback was received, thanks!

http://www.freebsd.org/cgi/query-pr.cgi?pr=138652
From linimon at FreeBSD.org  Wed Sep  9 14:29:56 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Wed Sep  9 14:30:02 2009
Subject: kern/138660: [igb] igb driver troubles in 8.0-BETA4
Message-ID: <200909091429.n89ETujh010695@freefall.freebsd.org>

Old Synopsis: igb driver troubles in 8.0-BETA4
New Synopsis: [igb] igb driver troubles in 8.0-BETA4

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Sep 9 14:29:34 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=138660
From gaurav0287 at gmail.com  Wed Sep  9 14:30:03 2009
From: gaurav0287 at gmail.com (Gaurav Goel)
Date: Wed Sep  9 14:30:13 2009
Subject: kern/138652: TCP window scaling value
Message-ID: <200909091430.n89EU2Rn010762@freefall.freebsd.org>

The following reply was made to PR kern/138652; it has been noted by GNATS.

From: Gaurav Goel <gaurav0287@gmail.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/138652: TCP window scaling value
Date: Wed, 9 Sep 2009 19:19:58 +0530

 --000feaef6808cf00280473255b4d
 Content-Type: text/plain; charset=UTF-8
 
 Dear Gavin,
 
 Version- Revision *1.192.2.1 *(check it on link "
 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_usrreq.c")
 File- "src/sys/netinet/tcp_usrreq.c"
 Line No- 1101
 
 Problem described as above
 
 Thanks,
 Gaurav Goel
 
 On Wed, Sep 9, 2009 at 6:13 PM, <gavin@freebsd.org> wrote:
 
 > Synopsis: TCP window scaling value
 >
 > State-Changed-From-To: open->feedback
 > State-Changed-By: gavin
 > State-Changed-When: Wed Sep 9 12:38:16 UTC 2009
 > State-Changed-Why:
 > To submitter: Firstly, tcp_input.c-orig is not a file distributed with
 > FreeBSD.  I suspect this is left over from a failed patch attempt to
 > src/sys/netinet/tcp_input.c.  Can you confirm that the problem exists
 > in that file?  Can you also please give the version number of the copy
 > you are looking at, and the line numbers where the problem occurs?
 > Thanks!
 >
 >
 > Responsible-Changed-From-To: freebsd-bugs->gavin
 > Responsible-Changed-By: gavin
 > Responsible-Changed-When: Wed Sep 9 12:38:16 UTC 2009
 > Responsible-Changed-Why:
 > Track
 >
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=138652
 >
 
 
 
 -- 
 Gaurav Goel
 
 --000feaef6808cf00280473255b4d
 Content-Type: text/html; charset=UTF-8
 Content-Transfer-Encoding: quoted-printable
 
 Dear Gavin,<br><br>Version- Revision <b>1.192.2.1 </b>(check it on link &qu=
 ot;<a href=3D"http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_usr=
 req.c">http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/netinet/tcp_usrreq.c</=
 a>&quot;)<br>
 File- &quot;src/sys/netinet/tcp_usrreq.c&quot;<br>Line No- 1101<br><br>Prob=
 lem described as above<br><br>Thanks,<br>Gaurav Goel<br><br><div class=3D"g=
 mail_quote">On Wed, Sep 9, 2009 at 6:13 PM,  <span dir=3D"ltr">&lt;<a href=
 =3D"mailto:gavin@freebsd.org">gavin@freebsd.org</a>&gt;</span> wrote:<br>
 <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Synopsis: TCP win=
 dow scaling value<br>
 <br>
 State-Changed-From-To: open-&gt;feedback<br>
 State-Changed-By: gavin<br>
 State-Changed-When: Wed Sep 9 12:38:16 UTC 2009<br>
 State-Changed-Why:<br>
 To submitter: Firstly, tcp_input.c-orig is not a file distributed with<br>
 FreeBSD. =C2=A0I suspect this is left over from a failed patch attempt to<b=
 r>
 src/sys/netinet/tcp_input.c. =C2=A0Can you confirm that the problem exists<=
 br>
 in that file? =C2=A0Can you also please give the version number of the copy=
 <br>
 you are looking at, and the line numbers where the problem occurs?<br>
 Thanks!<br>
 <br>
 <br>
 Responsible-Changed-From-To: freebsd-bugs-&gt;gavin<br>
 Responsible-Changed-By: gavin<br>
 Responsible-Changed-When: Wed Sep 9 12:38:16 UTC 2009<br>
 Responsible-Changed-Why:<br>
 Track<br>
 <br>
 <a href=3D"http://www.freebsd.org/cgi/query-pr.cgi?pr=3D138652" target=3D"_=
 blank">http://www.freebsd.org/cgi/query-pr.cgi?pr=3D138652</a><br>
 </blockquote></div><br><br clear=3D"all"><br>-- <br>Gaurav Goel<br>
 
 --000feaef6808cf00280473255b4d--
From mike at sentex.net  Wed Sep  9 15:17:13 2009
From: mike at sentex.net (Mike Tancsa)
Date: Wed Sep  9 15:17:20 2009
Subject: em driver input errors
In-Reply-To: <538232.7388.qm@web63901.mail.re1.yahoo.com>
References: <200909091352.n89DqQDx079631@lava.sentex.ca>
	<538232.7388.qm@web63901.mail.re1.yahoo.com>
Message-ID: <200909091513.n89FDgdf080109@lava.sentex.ca>

At 10:19 AM 9/9/2009, Barney Cordoba wrote:
>test would be to force it to 100Mb/s to see if the problem goes 
>away.  I see you are using em1 which implies another NIC...if you 
>have traffic on the other lan its not much different than Also, 
>realize that most pciX busses are shared. So your disk and other 
>devices may be sharing. Its really derilect for these MB 
>manufacturers to sell dual gig nic systems and them wire them to a 
>slow bus. But its what they do. Barney


The other nic is not in use right now. I tried switching them so see 
if one would work better than the other, but I didnt see any difference.

The board is an intel

http://www.intel.com/support/motherboards/server/s3000ah/

Not sure if its wired as PCI-X or just a 32bit bus.  I am just 
popping in an em pcie nic to see if that makes a difference.  I have 
an igb as well as bge I can try later.

         ---Mike





>_______________________________________________
>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"

--------------------------------------------------------------------
Mike Tancsa,                                      tel +1 519 651 3400
Sentex Communications,                            mike@sentex.net
Providing Internet since 1994                    www.sentex.net
Cambridge, Ontario Canada                         www.sentex.net/mike

From mike at sentex.net  Wed Sep  9 15:29:01 2009
From: mike at sentex.net (Mike Tancsa)
Date: Wed Sep  9 15:29:11 2009
Subject: em driver input errors
In-Reply-To: <200909091513.n89FDgdf080109@lava.sentex.ca>
References: <200909091352.n89DqQDx079631@lava.sentex.ca>
	<538232.7388.qm@web63901.mail.re1.yahoo.com>
	<200909091513.n89FDgdf080109@lava.sentex.ca>
Message-ID: <200909091525.n89FPUv3080170@lava.sentex.ca>

At 11:17 AM 9/9/2009, Mike Tancsa wrote:
>The board is an intel
>
>http://www.intel.com/support/motherboards/server/s3000ah/
>
>Not sure if its wired as PCI-X or just a 32bit bus.  I am just 
>popping in an em pcie nic to see if that makes a difference.  I have 
>an igb as well as bge I can try later.

OK, now there is

em0@pci0:5:0:0: class=0x020000 card=0xa01f8086 chip=0x10d38086 
rev=0x00 hdr=0x00
     vendor     = 'Intel Corporation'
     class      = network
     subclass   = ethernet
     cap 01[c8] = powerspec 2  supports D0 D3  current D0
     cap 05[d0] = MSI supports 1 message, 64 bit
     cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
     cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled


em0: <Intel(R) PRO/1000 Network Connection 6.9.6> port 0x3000-0x301f 
mem 0xea680000-0xea69ffff,0xea600000-0xea67ffff,0xea6a0000-0xea6a3fff 
irq 16 at device 0.0 on pci5
em0: Using MSIX interrupts
em0: [ITHREAD]
em0: [ITHREAD]
em0: [ITHREAD]
em0: Ethernet address: ....

0[backup3]# vmstat -i
interrupt                          total       rate
irq1: atkbd0                           6          0
irq4: sio0                           692          1
irq16: twa0 uhci3                   3841         10
irq18: arcmsr0+                     7825         20
irq19: uhci1+                      13144         34
irq23: uhci0 ehci0                     1          0
cpu0: timer                       755553       1988
irq256: em0                         3890         10
irq257: em0                         3607          9
irq258: em0                            1          0
cpu1: timer                       745924       1962
cpu2: timer                       747100       1966
cpu3: timer                       747671       1967
Total                            3029255       7971


Lets see how it does :)

         ---Mike


--------------------------------------------------------------------
Mike Tancsa,                                      tel +1 519 651 3400
Sentex Communications,                            mike@sentex.net
Providing Internet since 1994                    www.sentex.net
Cambridge, Ontario Canada                         www.sentex.net/mike

From universite at ukr.net  Wed Sep  9 19:04:54 2009
From: universite at ukr.net (Vladislav V. Prodan)
Date: Wed Sep  9 19:05:05 2009
Subject: misc/138676: after buildworld not work local routes
Message-ID: <4AA7FC4B.6090601@ukr.net>

>Number:         138676
>Category:       misc
>Synopsis:       after buildworld not work local routes
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Sep 09 19:00:04 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator:     Vladislav V. Prodan
>Release:        FreeBSD 8.0-BETA4 #0: Wed Sep  9 00:53:41 EEST 2009 amd64
>Organization:
>Environment:
FreeBSD mary-teresa.otrada.od.ua 8.0-BETA4 FreeBSD 8.0-BETA4 #0: Wed Sep 
  9 00:53:41 EEST 2009 
vlad11@mary-teresa.otrada.od.ua:/usr/obj/usr/src/sys/mary-teresa.17  amd64

>Description:
home PC --> FreeBSD [ squid --> apache ]

These url are on the external interface of the server.
http://otrada.od.ua/blog/
http://otrada.od.ua/phpmyadmin/
http://otrada.od.ua/cacti/

After upgrade the system now gives the squid:
     (51) Network is unreachable

In logs:
sep  9 18:39:10 128 10.0.0.10 TCP_MISS/503 1317 GET 
http://otrada.od.ua/blog/ - DIRECT/otrada.od.ua text/html
sep  9 18:39:18 126 10.0.0.10 TCP_MISS/503 1329 GET 
http://otrada.od.ua/phpmyadmin/ - DIRECT/otrada.od.ua text/html
sep  9 18:39:39 117 10.0.0.10 TCP_MISS/503 1319 GET 
http://otrada.od.ua/cacti/ - DIRECT/otrada.od.ua text/html

Out all three url normally give details.
At queries from outside, all url are working properly.

similar problem was previously:
http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001581.html
>How-To-Repeat:

>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:





From qing.li at bluecoat.com  Wed Sep  9 19:14:47 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Wed Sep  9 19:14:53 2009
Subject: misc/138676: after buildworld not work local routes
In-Reply-To: <4AA7FC4B.6090601@ukr.net>
References: <4AA7FC4B.6090601@ukr.net>
Message-ID: <B583FBF374231F4A89607B4D08578A43053CEBA7@bcs-mail03.internal.cacheflow.com>

Thanks for the report. I will work you off list for now.

-- Qing


> -----Original Message-----
> From: Vladislav V. Prodan [mailto:universite@ukr.net]
> Sent: Wednesday, September 09, 2009 12:05 PM
> To: freebsd-current@freebsd.org; freebsd-net@freebsd.org
> Cc: Li, Qing
> Subject: misc/138676: after buildworld not work local routes
> 
> >Number:         138676
> >Category:       misc
> >Synopsis:       after buildworld not work local routes
> >Confidential:   no
> >Severity:       serious
> >Priority:       medium
> >Responsible:    freebsd-bugs
> >State:          open
> >Quarter:
> >Keywords:
> >Date-Required:
> >Class:          sw-bug
> >Submitter-Id:   current-users
> >Arrival-Date:   Wed Sep 09 19:00:04 UTC 2009
> >Closed-Date:
> >Last-Modified:
> >Originator:     Vladislav V. Prodan
> >Release:        FreeBSD 8.0-BETA4 #0: Wed Sep  9 00:53:41 EEST 2009
> amd64
> >Organization:
> >Environment:
> FreeBSD mary-teresa.otrada.od.ua 8.0-BETA4 FreeBSD 8.0-BETA4 #0: Wed
> Sep
>   9 00:53:41 EEST 2009
> vlad11@mary-teresa.otrada.od.ua:/usr/obj/usr/src/sys/mary-teresa.17
> amd64
> 
> >Description:
> home PC --> FreeBSD [ squid --> apache ]
> 
> These url are on the external interface of the server.
> http://otrada.od.ua/blog/
> http://otrada.od.ua/phpmyadmin/
> http://otrada.od.ua/cacti/
> 
> After upgrade the system now gives the squid:
>      (51) Network is unreachable
> 
> In logs:
> sep  9 18:39:10 128 10.0.0.10 TCP_MISS/503 1317 GET
> http://otrada.od.ua/blog/ - DIRECT/otrada.od.ua text/html
> sep  9 18:39:18 126 10.0.0.10 TCP_MISS/503 1329 GET
> http://otrada.od.ua/phpmyadmin/ - DIRECT/otrada.od.ua text/html
> sep  9 18:39:39 117 10.0.0.10 TCP_MISS/503 1319 GET
> http://otrada.od.ua/cacti/ - DIRECT/otrada.od.ua text/html
> 
> Out all three url normally give details.
> At queries from outside, all url are working properly.
> 
> similar problem was previously:
> http://lists.freebsd.org/pipermail/freebsd-current/2008-
> December/001581.html
> >How-To-Repeat:
> 
> >Fix:
> 
> 
> >Release-Note:
> >Audit-Trail:
> >Unformatted:
> 
> 
> 
> 

From linimon at FreeBSD.org  Wed Sep  9 19:21:02 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Wed Sep  9 19:21:14 2009
Subject: kern/138666: [multicast] [panic] not working multicast through
	igmpproxy
Message-ID: <200909091921.n89JL2wr014985@freefall.freebsd.org>

Old Synopsis: Do not working multicast through igmpproxy
New Synopsis: [multicast] [panic] not working multicast through igmpproxy

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Sep 9 19:19:45 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=138666
From linimon at FreeBSD.org  Wed Sep  9 19:23:57 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Wed Sep  9 19:24:03 2009
Subject: kern/138676: [route] after buildworld not work local routes
	[regression]
Message-ID: <200909091923.n89JNuvu015158@freefall.freebsd.org>

Old Synopsis: after buildworld not work local routes
New Synopsis: [route] after buildworld not work local routes [regression]

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Sep 9 19:23:00 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=138676
From gonzo at bluezbox.com  Wed Sep  9 19:39:16 2009
From: gonzo at bluezbox.com (Oleksandr Tymoshenko)
Date: Wed Sep  9 19:39:23 2009
Subject: NFSROOT is broken after r196714 
Message-ID: <4AA7FFC0.6070302@bluezbox.com>

r196714 breaks NFSROOT in -CURRENT. When nfsclient tries to
initialize interface calling ifioctl at nfsclient/nfs_vfsops.c:466
it fails with EEXIST (because route is already present I guess).

I fixed it in my tree by checking for error code in mount_nfsroot,
but may be it's ifioctl(SIOCAIFADDR) that should handle this case.

-- 
gonzo
From qing.li at bluecoat.com  Wed Sep  9 19:47:52 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Wed Sep  9 19:47:58 2009
Subject: NFSROOT is broken after r196714 
In-Reply-To: <4AA7FFC0.6070302@bluezbox.com>
References: <4AA7FFC0.6070302@bluezbox.com>
Message-ID: <B583FBF374231F4A89607B4D08578A43053CEBE2@bcs-mail03.internal.cacheflow.com>

Do you know what IP address nfsclient/nfs_vfsops.c:466 is trying to 
insert and do you have an output of the "ifconfig" and route 
table you can send to me privately?

At the moment I am suspecting r196714 uncovered an issue that has
always been there. But that's an assumption at the moment.

Thanks,

-- Qing


> -----Original Message-----
> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-
> net@freebsd.org] On Behalf Of Oleksandr Tymoshenko
> Sent: Wednesday, September 09, 2009 12:19 PM
> To: freebsd-net@freebsd.org
> Subject: NFSROOT is broken after r196714
> 
> r196714 breaks NFSROOT in -CURRENT. When nfsclient tries to
> initialize interface calling ifioctl at nfsclient/nfs_vfsops.c:466
> it fails with EEXIST (because route is already present I guess).
> 
> I fixed it in my tree by checking for error code in mount_nfsroot,
> but may be it's ifioctl(SIOCAIFADDR) that should handle this case.
> 
> --
> gonzo
> _______________________________________________
> 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 linimon at FreeBSD.org  Wed Sep  9 20:06:34 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Wed Sep  9 20:06:43 2009
Subject: kern/138678: [lo] FreeBSD does not assign linklocal address to
	loopbacks >0
Message-ID: <200909092006.n89K6YwU054690@freefall.freebsd.org>

Old Synopsis: FreeBSD does not assign linklocal address to loopbacks >0
New Synopsis: [lo] FreeBSD does not assign linklocal address to loopbacks >0

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Sep 9 20:05:49 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=138678
From universite at ukr.net  Wed Sep  9 20:20:05 2009
From: universite at ukr.net (Vladislav V. Prodan)
Date: Wed Sep  9 20:20:16 2009
Subject: misc/138676: after buildworld not work local routes
Message-ID: <200909092020.n89KK5Xb065434@freefall.freebsd.org>

The following reply was made to PR kern/138676; it has been noted by GNATS.

From: "Vladislav V. Prodan" <universite@ukr.net>
To: "Li, Qing" <qing.li@bluecoat.com>, freebsd-current@freebsd.org
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: misc/138676: after buildworld not work local routes
Date: Wed, 09 Sep 2009 23:18:34 +0300

 Li, Qing пишет:
 > Okay, perhaps I didn't understand your issue correctly. In
 
 > http://lists.freebsd.org/pipermail/freebsd-current/2008-December/001581.html
 
 > the errors are route insertion related. Those routes are not
 > visible inside the kernel. Now these routes show up in the
 > table but Squid reports
 
 > " After upgrade the system now gives the squid:
 >      (51) Network is unreachable"
 
 > Which IP address is not reachable?
 
 Do not operate sites on IP 89.209.81.54, when you walk through the squid.
 If you go to the sites, bypassing squid, then everything works.
 
 It seems, squid does not "see" the table of the form:
 Destination        Gateway            Flags    Refs      Use  Netif Expire
 89.209.81.54       link#4             UHS         0    30161    lo0
From stef-list at memberwebs.com  Wed Sep  9 21:11:29 2009
From: stef-list at memberwebs.com (Stef Walter)
Date: Wed Sep  9 21:11:36 2009
Subject: [patch] Multicast: uninited memory used in filter at
 IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP
Message-ID: <mailman.13.1252530696.1066.freebsd-net@freebsd.org>

If a multicast caller does an IP_DROP_MEMBERSHIP followed by a
IP_ADD_MEMBERSHIP, often an uninitialized filter is used for the
in_mfilter passed to in_joingroup_locked() in netinet/in_mcast.c.

The IP_ADD_MEMBERSHIP and IP_DROP_MEMBERSHIP have simple in_mreq input,
and are not using SSM or any of the new IGMPv3 features.

This results in the following behavior shown by ifmcstat. Before the
drop + add you can see the following groups for the northstar1
interface. Note that 224.0.0.5 (ie: OSPF-ALL.MCAST.NET) is subscribed
with an empty exclude filter as you would expect from simple ASM mode:

> # ifmcstat -i northstar1
> northstar1:
> 	inet 172.28.1.66
> 	igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group 224.0.0.5 mode exclude
> 		group 224.0.0.1 mode exclude

After the drop + add, it looks like the following. Note that now
224.0.0.5 is subscribed with an empty *include* filter which results in
no packets received.

> # ifmcstat -i northstar1
> northstar1:
> 	inet 172.28.1.66
> 	igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group 224.0.0.1 mode exclude
> 		group 224.0.0.5 mode include

uname: FreeBSD portillo-gate.ws.local 8.0-BETA3 FreeBSD 8.0-BETA3 #24:
Wed Sep  9 15:01:39 UTC 2009
root@portillo-gate.ws.local:/usr/src/sys/i386/compile/PORTILLO  i386

Patch is attached which fixes the problem. Is this the right approach?
If not, I hope it helps highlight the problem area.

Cheers,

Stef

-------------- next part --------------
A non-text attachment was scrubbed...
Name: freebsd-mcast-uninited.patch
Type: text/x-diff
Size: 339 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090909/48be30e2/freebsd-mcast-uninited.bin
From bms at incunabulum.net  Wed Sep  9 22:54:49 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Wed Sep  9 22:54:55 2009
Subject: [patch] Multicast: uninited memory used in filter at
 IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP
Message-ID: <4AA83230.4070405@incunabulum.net>

Stef Walter wrote:
> ...
> Patch is attached which fixes the problem. Is this the right approach?
> If not, I hope it helps highlight the problem area.
>   

Good catch; thanks for the fix. I used to depend on imf being 
initialized to NULL in this function, however, I opted to keep the old 
vector-style allocation scheme for in_mfilter and track it with in_multi 
on the socket. If the descriptor slot got recycled, then the imf 
contents will be invalid as you saw.

I think this can probably go right in as-is. I'm supposed to be looking 
at other stuff now, so hopefully syrinx@ can check this in if I don't 
get around to it.

thanks,
BMS
From stef-list at memberwebs.com  Wed Sep  9 23:42:17 2009
From: stef-list at memberwebs.com (Stef Walter)
Date: Wed Sep  9 23:42:23 2009
Subject: [patch] Multicast: uninited memory used in filter at
 IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP
References: <4AA83230.4070405@incunabulum.net>
Message-ID: <mailman.14.1252539743.1066.freebsd-net@freebsd.org>

Bruce Simpson wrote:
> I think this can probably go right in as-is. I'm supposed to be looking
> at other stuff now, so hopefully syrinx@ can check this in if I don't
> get around to it.

Great news. Should I just make a PR for this? Or is there somewhere I
should put it for the 8.0 BETA?

After these various (posted) multicast patches OSPF (with quagga) is now
far more stable on 8.0-BETA4. However I'm still seeing intermittent
problems. I need help in knowing how to debug the following. Once it's
figured out, I'd like to make a patch.

Specifically:

Quagga has a sockets open on em0, portillo1, and northstar1 below on the
224.0.0.5 group. ifmcstat output:

> em0:
> 	inet 172.27.2.1
> 	igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group 224.0.0.5 mode exclude
> 			mcast-macaddr 01:00:5e:00:00:05
> 		group 224.0.0.1 mode exclude
> 			mcast-macaddr 01:00:5e:00:00:01
> em1:
> 	inet 189.162.25.187
> 	igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group 224.0.0.1 mode exclude
> 			mcast-macaddr 01:00:5e:00:00:01
> lo0:
> 	inet 127.0.0.1
> 	igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group 224.0.0.1 mode exclude
> 	inet6 fe80::1%lo0
> 	mldv2 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group ff01::1%lo0 mode exclude
> 		group ff02::2:10c2:bd48%lo0 mode exclude
> 		group ff02::1%lo0 mode exclude
> 		group ff02::1:ff00:1%lo0 mode exclude
> leaseweb0:
> 	inet 10.94.75.3
> 	igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group 224.0.0.1 mode exclude
> 			mcast-macaddr 01:00:5e:00:00:01
> portillo1:
> 	inet 172.28.1.65
> 	igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group 224.0.0.5 mode exclude
> 		group 224.0.0.1 mode exclude
> eaglecrest1:
> 	inet 172.28.1.70
> 	igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group 224.0.0.5 mode exclude
> 		group 224.0.0.1 mode exclude

After a while and a few interface ups and downs, quagga stops getting
OSPF packets on one of the interfaces. I can verify with tcpdump that
these packets are seen by the machine. For example, on em0:

> # tcpdump -pnti em0 proto ospf
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes
> IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44
> IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48
> IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44
> IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48
> IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44
> IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48
> IP 172.27.2.1 > 224.0.0.5: OSPFv2, Hello, length 44
> IP 172.27.2.2 > 224.0.0.5: OSPFv2, Hello, length 48

The packets from 172.27.2.2 are not being delivered to the ospfd process
socket (verified via userland debugging and logging). Even though, as
you can see above the em0 interface is part of the group.

Where and how could I see what's preventing these packets from being
delivered to the ospfd process socket? Which code is involved in the
dispatch?

Thanks for your help and time. Much appreciated.

Cheers,

Stef

From bruce at cran.org.uk  Thu Sep 10 01:30:06 2009
From: bruce at cran.org.uk (Bruce Cran)
Date: Thu Sep 10 01:30:17 2009
Subject: kern/64556: [sis] if_sis short cable fix problems with NetGear
 FA311's
Message-ID: <200909100130.n8A1U6Es077696@freefall.freebsd.org>

The following reply was made to PR kern/64556; it has been noted by GNATS.

From: Bruce Cran <bruce@cran.org.uk>
To: bug-followup@FreeBSD.org, tom@hur.st
Cc:  
Subject: Re: kern/64556: [sis] if_sis short cable fix problems with NetGear
 FA311's
Date: Thu, 10 Sep 2009 02:24:17 +0100

 I'm still seeing this problem on 8.0-BETA4. Running two ttcp's (one rx,
 one tx) causes the system to print lots of "Applying short cable fix"
 messages.  I've had a look through the NetBSD driver, the original
 Linux driver from http://www.soekris.com/downloads.htm and also the
 latest Linux sources.  
 
 When the issue occurs, I see throughput drop to around 5Mb.  The first
 issues seems to be the 100ms delay. From the other code I've looked at,
 it looks like it should be 100us which would speed up the reset
 process. Secondly, it seems that only FreeBSD resets the chip when an
 RX overrun occurs; on NetBSD it does a printf and continues, and Linux
 increments the error statistics.  Both only apply the short cable fix
 when a media change occurs.
 
 -- 
 Bruce Cran
From stef-list at memberwebs.com  Thu Sep 10 03:09:32 2009
From: stef-list at memberwebs.com (Stef Walter)
Date: Thu Sep 10 03:09:38 2009
Subject: Multicast SSM bug?
References: <4AA83230.4070405@incunabulum.net> 
Message-ID: <mailman.15.1252552178.1066.freebsd-net@freebsd.org>

Stef Walter wrote:
> The packets from 172.27.2.2 are not being delivered to the ospfd process
> socket (verified via userland debugging and logging). Even though, as
> you can see above the em0 interface is part of the group.

I've done more research on this.

Each time a packet is not delivered, I can see this counter being
incremented:

> # netstat -s -p ip | grep multicast
> 	885 packets received for unknown multicast group

That counter originates from this block of code in raw_ip.c:

>   354               blocked = imo_multi_filter(inp->inp_moptions, ifp,
>   355                   (struct sockaddr *)&group,
>   356                   (struct sockaddr *)&ripsrc);
>   357               if (blocked != MCAST_PASS) {
>   358                       IPSTAT_INC(ips_notmember);
>   359                       continue;
>   360               }

After instrumenting it with this printf:

> printf("not member: group = %s, ", inet_ntoa (group.sin_addr));
> printf("src = %s, why = %d\n", inet_ntoa (ripsrc.sin_addr), (int)blocked);

Then wait, then up down some interfaces, etc.... quagga adds/drops
memberships, eventually I see the following output:

> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2
> not member: group = 224.0.0.5, src = 172.28.1.66, why = 2

The why = 2 is MCAST_NOTSMEMBER. 172.28.1.66 is the tunnel peer sending
OSPF multicast packets. Somehow imo_multi_filter is limiting via packet
source for this membership. However, this is what the interface looks
like via ifmcstat (ie: no SSM memberships):

> portillo1:
> 	inet 172.28.1.65
> 	igmpv3 flags=0<> rv 2 qi 125 qri 10 uri 3
> 		group 224.0.0.5 mode exclude
> 		group 224.0.0.1 mode exclude

Any of the above ring a bell? If not, I'll keep poking around and see
what I find.

Cheers,

Stef

From randy at psg.com  Thu Sep 10 05:21:37 2009
From: randy at psg.com (Randy Bush)
Date: Thu Sep 10 05:21:43 2009
Subject: forwarding when two rip defaults
Message-ID: <m21vmfs7c0.wl%randy@psg.com>

say i run routed and receive rip default from two routers, on the same
local ether.  what is the forwarding?  i presume it's not smart enough
to balance flows.  i hope not alternating packets.  clue, please?

fwiw, the routers each have full bgp exits.  vrrp would force all
traffic to one.  so i am looking at rip or quagga's isisd.

thanks.

randy
From julian at elischer.org  Thu Sep 10 05:31:51 2009
From: julian at elischer.org (Julian Elischer)
Date: Thu Sep 10 05:31:59 2009
Subject: forwarding when two rip defaults
In-Reply-To: <m21vmfs7c0.wl%randy@psg.com>
References: <m21vmfs7c0.wl%randy@psg.com>
Message-ID: <4AA88F45.8000407@elischer.org>

Randy Bush wrote:
> say i run routed and receive rip default from two routers, on the same
> local ether.  what is the forwarding?  i presume it's not smart enough
> to balance flows.  i hope not alternating packets.  clue, please?
> 
> fwiw, the routers each have full bgp exits.  vrrp would force all
> traffic to one.  so i am looking at rip or quagga's isisd.
> 
> thanks.
> 
> randy
> _______________________________________________
> 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 can't speak for routed but the base system, given two default routes 
would use a hashing schemem to send data to both.

more details depend on what options you have turned on.

From randy at psg.com  Thu Sep 10 05:35:45 2009
From: randy at psg.com (Randy Bush)
Date: Thu Sep 10 05:35:51 2009
Subject: forwarding when two rip defaults
In-Reply-To: <4AA88F45.8000407@elischer.org>
References: <m21vmfs7c0.wl%randy@psg.com>
	<4AA88F45.8000407@elischer.org>
Message-ID: <m2zl93qs40.wl%randy@psg.com>

>> say i run routed and receive rip default from two routers, on the same
>> local ether.  what is the forwarding?  i presume it's not smart enough
>> to balance flows.  i hope not alternating packets.  clue, please?
> I can't speak for routed

routed is just the routing protocol used to garner the routes installed
in the fib.  so it should not be of concern.

> the base system, given two default routes would use a hashing schemem
> to send data to both.  more details depend on what options you have
> turned on.

is there a doc page somewhere?

thanks.

randy
From stef-list at memberwebs.com  Thu Sep 10 05:58:58 2009
From: stef-list at memberwebs.com (Stef Walter)
Date: Thu Sep 10 05:59:06 2009
Subject: [patch] Multicast: Keep membership and filters in sync
Message-ID: <mailman.16.1252562346.1066.freebsd-net@freebsd.org>

When removing multicast membership from a socket (ie:
IP_DROP_MEMBERSHIP) that has multiple multicast memberships, the
internal list of memberships and filters are not kept in sync.

This results in dropped packets that are not delivered to the socket
that has the multicast membership. This was experienced with OSPF
(running quagga).

Besides the obvious non-functional multicast, the following command is
another way to see an indication of the problem:

> # netstat -s -p ip | grep multicast
> 	7 packets received for unknown multicast group

Patch attached which fixes the problem.

Cheers,

Stef
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freebsd-mcast-filter-array-in-sync.patch
Type: text/x-diff
Size: 546 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090910/714e62bb/freebsd-mcast-filter-array-in-sync.bin
From qing.li at bluecoat.com  Thu Sep 10 06:05:48 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Thu Sep 10 06:05:55 2009
Subject: forwarding when two rip defaults
In-Reply-To: <m21vmfs7c0.wl%randy@psg.com>
References: <m21vmfs7c0.wl%randy@psg.com>
Message-ID: <B583FBF374231F4A89607B4D08578A43054539B1@bcs-mail03.internal.cacheflow.com>

What release are you running ?

-- Qing

> -----Original Message-----
> From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-
> net@freebsd.org] On Behalf Of Randy Bush
> Sent: Wednesday, September 09, 2009 10:22 PM
> To: freebsd-net
> Subject: forwarding when two rip defaults
> 
> say i run routed and receive rip default from two routers, on the same
> local ether.  what is the forwarding?  i presume it's not smart enough
> to balance flows.  i hope not alternating packets.  clue, please?
> 
> fwiw, the routers each have full bgp exits.  vrrp would force all
> traffic to one.  so i am looking at rip or quagga's isisd.
> 
> thanks.
> 
> randy
> _______________________________________________
> 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 stef-list at memberwebs.com  Thu Sep 10 07:22:26 2009
From: stef-list at memberwebs.com (Stef Walter)
Date: Thu Sep 10 07:22:33 2009
Subject: forwarding when two rip defaults
References: <m21vmfs7c0.wl%randy@psg.com>
Message-ID: <mailman.17.1252567353.1066.freebsd-net@freebsd.org>

Randy Bush wrote:
> say i run routed and receive rip default from two routers, on the same
> local ether.  what is the forwarding?  i presume it's not smart enough
> to balance flows.  i hope not alternating packets.  clue, please?

Unless you have RADIX_MPATH in your kernel (with a recent FreeBSD, ie:
8.0) it'll choose one at random. Unless one route has a better metric.

Cheers,

Stef

From ccowart at rescomp.berkeley.edu  Thu Sep 10 07:37:40 2009
From: ccowart at rescomp.berkeley.edu (Chris Cowart)
Date: Thu Sep 10 07:37:54 2009
Subject: IPSEC + long UDP causes reproducible crash [was: Crash in
 ether_input]
In-Reply-To: <54FDC10A-EAE3-4AE2-BF36-2C5F7D141C3A@neville-neil.com>
References: <20090904223123.GD16213@hal.rescomp.berkeley.edu>
	<723505E9-96C6-401C-A844-3D9BA2033795@neville-neil.com>
	<20090907191001.GA37291@hal.rescomp.berkeley.edu>
	<54FDC10A-EAE3-4AE2-BF36-2C5F7D141C3A@neville-neil.com>
Message-ID: <20090910073739.GB37291@hal.rescomp.berkeley.edu>

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090910/2e345cfe/attachment.pgp
From vanhu at FreeBSD.org  Thu Sep 10 08:13:43 2009
From: vanhu at FreeBSD.org (VANHULLEBUS Yvan)
Date: Thu Sep 10 08:13:49 2009
Subject: IPSEC + long UDP causes reproducible crash [was: Crash in
	ether_input]
In-Reply-To: <20090910073739.GB37291@hal.rescomp.berkeley.edu>
References: <20090904223123.GD16213@hal.rescomp.berkeley.edu>
	<723505E9-96C6-401C-A844-3D9BA2033795@neville-neil.com>
	<20090907191001.GA37291@hal.rescomp.berkeley.edu>
	<54FDC10A-EAE3-4AE2-BF36-2C5F7D141C3A@neville-neil.com>
	<20090910073739.GB37291@hal.rescomp.berkeley.edu>
Message-ID: <20090910081337.GA66528@zeninc.net>

On Thu, Sep 10, 2009 at 12:37:39AM -0700, Chris Cowart wrote:
[...]
> Hi,

Hi.


[...]
> I have been using i386 and amd64 virtual machines as well as an amd64
> physical machine; this problem can be reproduced fairly reliably on all
> of them for 7.0 and 7.1 (and we're pretty sure we saw it in 6.x and
> didn't know what it was at the time).

I fixed in FreeBSD 7.2+ a bug which looks to be related with your
crashes (kernel panic with big packets), could you please try again
with FreeBSD 7.2 and report us the result ?


Thanks,

Yvan.
From patfbsd at davenulle.org  Thu Sep 10 08:32:33 2009
From: patfbsd at davenulle.org (Patrick Lamaiziere)
Date: Thu Sep 10 08:32:39 2009
Subject: IPSEC + long UDP causes reproducible crash [was: Crash in
 ether_input]
In-Reply-To: <20090910073739.GB37291@hal.rescomp.berkeley.edu>
References: <20090904223123.GD16213@hal.rescomp.berkeley.edu>
	<723505E9-96C6-401C-A844-3D9BA2033795@neville-neil.com>
	<20090907191001.GA37291@hal.rescomp.berkeley.edu>
	<54FDC10A-EAE3-4AE2-BF36-2C5F7D141C3A@neville-neil.com>
	<20090910073739.GB37291@hal.rescomp.berkeley.edu>
Message-ID: <20090910101449.0fa714bd@baby-jane.lamaiziere.net>

Le Thu, 10 Sep 2009 00:37:39 -0700,
Chris Cowart <ccowart@rescomp.berkeley.edu> a ?crit :

Hello,

> A C program that sends long UDP messages is attached (there's a
> hardcoded remote IP in there). The program sends 2 UDP message of size
> 1960, sleeping for 3 seconds in between. Most of the time, on a clean
> boot, the first message is enough to cause a kernel panic. The second
> message almost always causes a kernel panic. I have never been able to
> run the program a second time without the system crashing.
> 
> The exact point of the panic tends to vary. I've seen it frequently
> occurring in in_cksumdata, but it's all been really close to
> ip_output.
> 
> I've been poking around in the debugger for hours over the past couple
> of days. I can't tell if the mbuf is being corrupted as it's passing
> through the crypto system or if it's happening in ip_fragment. I'm in
> a bit over my head in terms of trying to isolate and patch the bug. If
> anyone has the time to squash it or at least give me some pointers as
> to where I might look, that would help.

I'm not sure if it will help, but that reminds me this problem :
http://www.freebsd.org/cgi/query-pr.cgi?pr=124609

This is fixed in 7.1-STABLE and after.
From gaurav0287 at gmail.com  Thu Sep 10 13:40:02 2009
From: gaurav0287 at gmail.com (Gaurav Goel)
Date: Thu Sep 10 13:40:08 2009
Subject: kern/138652: TCP window scaling value calculated incorrectly?
Message-ID: <200909101340.n8ADe1cZ058871@freefall.freebsd.org>

The following reply was made to PR kern/138652; it has been noted by GNATS.

From: Gaurav Goel <gaurav0287@gmail.com>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: kern/138652: TCP window scaling value calculated incorrectly?
Date: Thu, 10 Sep 2009 19:00:37 +0530

 --000feae95a4f797c710473393423
 Content-Type: text/plain; charset=UTF-8
 
 Dear Gavin,
 
 Please find the fix for the problem:
 
 *Replace*
 *    while (tp->request_r_scale < TCP_MAX_WINSHIFT &&
         (TCP_MAXWIN << tp->request_r_scale) < sb_max)
         tp->request_r_scale++;*
 
 *With*
 *unsigned int new_TCP_MAXWIN = TCP_MAXWIN;
 while (tp->request_r_scale < TCP_MAX_WINSHIFT)
 {
     if(new_TCP_MAXWIN < sb_max)
         tp->request_r_scale++;
     else
         break;**
 **    new_TCP_MAXWIN <<=1;**
 **    new_TCP_MAXWIN |=1;**
 **}*
 
 Please inform me if I am right/wrong.
 
 Thanks,
 Gaurav Goel
 
 On Wed, Sep 9, 2009 at 7:59 PM, <gavin@freebsd.org> wrote:
 
 > Old Synopsis: TCP window scaling value
 > New Synopsis: TCP window scaling value calculated incorrectly?
 >
 > State-Changed-From-To: feedback->open
 > State-Changed-By: gavin
 > State-Changed-When: Wed Sep 9 14:24:24 UTC 2009
 > State-Changed-Why:
 > Over to maintainer(s) for investigation
 >
 >
 > Responsible-Changed-From-To: gavin->freebsd-net
 > Responsible-Changed-By: gavin
 > Responsible-Changed-When: Wed Sep 9 14:24:24 UTC 2009
 > Responsible-Changed-Why:
 > Feedback was received, thanks!
 >
 > http://www.freebsd.org/cgi/query-pr.cgi?pr=138652
 >
 
 
 
 -- 
 Gaurav Goel
 
 --000feae95a4f797c710473393423
 Content-Type: text/html; charset=UTF-8
 Content-Transfer-Encoding: quoted-printable
 
 Dear Gavin,<br><br>Please find the fix for the problem:<br><br><u><b>Replac=
 e</b></u><br><b><span style=3D"color: rgb(153, 0, 0); background-color: rgb=
 (255, 255, 255);">=C2=A0=C2=A0=C2=A0 while (tp-&gt;request_r_scale &lt; TCP=
 _MAX_WINSHIFT &amp;&amp;</span><br style=3D"color: rgb(153, 0, 0); backgrou=
 nd-color: rgb(255, 255, 255);">
 <span style=3D"color: rgb(153, 0, 0); background-color: rgb(255, 255, 255);=
 ">=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 (TCP_MAXWIN &lt;&lt; tp-&gt;request=
 _r_scale) &lt; sb_max)</span><br style=3D"color: rgb(153, 0, 0); background=
 -color: rgb(255, 255, 255);"><span style=3D"color: rgb(153, 0, 0); backgrou=
 nd-color: rgb(255, 255, 255);">=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 tp-&gt=
 ;request_r_scale++;</span></b><br>
 <br><u><b>With</b></u><br><b><span style=3D"color: rgb(0, 153, 0);">unsigne=
 d int new_TCP_MAXWIN =3D TCP_MAXWIN;</span><br style=3D"color: rgb(0, 153, =
 0);"><span style=3D"color: rgb(0, 153, 0);">while (tp-&gt;request_r_scale &=
 lt; TCP_MAX_WINSHIFT)</span><br style=3D"color: rgb(0, 153, 0);">
 <span style=3D"color: rgb(0, 153, 0);">{</span><span style=3D"color: rgb(0,=
  153, 0);"></span><br style=3D"color: rgb(0, 153, 0);"><span style=3D"color=
 : rgb(0, 153, 0);">=C2=A0=C2=A0=C2=A0 if(new_TCP_MAXWIN &lt; sb_max)</span>=
 <br style=3D"color: rgb(0, 153, 0);">
 <span style=3D"color: rgb(0, 153, 0);">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 =C2=A0 tp-&gt;request_r_scale++;</span><br style=3D"color: rgb(0, 153, 0);"=
 ><span style=3D"color: rgb(0, 153, 0);">=C2=A0=C2=A0=C2=A0 else</span><br s=
 tyle=3D"color: rgb(0, 153, 0);"><span style=3D"color: rgb(0, 153, 0);">=C2=
 =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 break;</span></b><b><span style=3D"=
 color: rgb(0, 153, 0);"></span><br style=3D"color: rgb(0, 153, 0);">
 
 <span style=3D"color: rgb(0, 153, 0);"></span></b><b><span style=3D"color: =
 rgb(0, 153, 0);">=C2=A0=C2=A0=C2=A0 new_TCP_MAXWIN &lt;&lt;=3D1;</span></b>=
 <b><br style=3D"color: rgb(0, 153, 0);"></b><b><span style=3D"color: rgb(0,=
  153, 0);">=C2=A0=C2=A0=C2=A0 new_TCP_MAXWIN |=3D1;</span></b><b><br style=
 =3D"color: rgb(0, 153, 0);">
 
 </b><b><span style=3D"color: rgb(0, 153, 0);">}</span></b><br><br>Please in=
 form me if I am right/wrong.<br><br>Thanks,<br>Gaurav Goel<br><br><div clas=
 s=3D"gmail_quote">On Wed, Sep 9, 2009 at 7:59 PM,  <span dir=3D"ltr">&lt;<a=
  href=3D"mailto:gavin@freebsd.org">gavin@freebsd.org</a>&gt;</span> wrote:<=
 br>
 <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, =
 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Old Synopsis: TCP=
  window scaling value<br>
 New Synopsis: TCP window scaling value calculated incorrectly?<br>
 <br>
 State-Changed-From-To: feedback-&gt;open<br>
 State-Changed-By: gavin<br>
 State-Changed-When: Wed Sep 9 14:24:24 UTC 2009<br>
 State-Changed-Why:<br>
 Over to maintainer(s) for investigation<br>
 <br>
 <br>
 Responsible-Changed-From-To: gavin-&gt;freebsd-net<br>
 Responsible-Changed-By: gavin<br>
 Responsible-Changed-When: Wed Sep 9 14:24:24 UTC 2009<br>
 Responsible-Changed-Why:<br>
 Feedback was received, thanks!<br>
 <br>
 <a href=3D"http://www.freebsd.org/cgi/query-pr.cgi?pr=3D138652" target=3D"_=
 blank">http://www.freebsd.org/cgi/query-pr.cgi?pr=3D138652</a><br>
 </blockquote></div><br><br clear=3D"all"><br>-- <br>Gaurav Goel<br>
 
 --000feae95a4f797c710473393423--
From randy at psg.com  Thu Sep 10 13:46:32 2009
From: randy at psg.com (Randy Bush)
Date: Thu Sep 10 13:46:38 2009
Subject: forwarding when two rip defaults
In-Reply-To: <B583FBF374231F4A89607B4D08578A43054539B1@bcs-mail03.internal.cacheflow.com>
References: <m21vmfs7c0.wl%randy@psg.com>
	<B583FBF374231F4A89607B4D08578A43054539B1@bcs-mail03.internal.cacheflow.com>
Message-ID: <m2y6omrjyh.wl%randy@psg.com>

> What release are you running ?
>> say i run routed and receive rip default from two routers, on the same
>> local ether.  what is the forwarding?  i presume it's not smart enough
>> to balance flows.  i hope not alternating packets.  clue, please?
>> 
>> fwiw, the routers each have full bgp exits.  vrrp would force all
>> traffic to one.  so i am looking at rip or quagga's isisd.

the hosts i care about generally run 8/9

randy
From randy at psg.com  Thu Sep 10 14:31:13 2009
From: randy at psg.com (Randy Bush)
Date: Thu Sep 10 14:31:20 2009
Subject: forwarding when two rip defaults
References: <m21vmfs7c0.wl%randy@psg.com>
Message-ID: <m2ljkmrhvz.wl%randy@psg.com>

>> say i run routed and receive rip default from two routers, on the same
>> local ether.  what is the forwarding?  i presume it's not smart enough
>> to balance flows.  i hope not alternating packets.  clue, please?
> Unless you have RADIX_MPATH in your kernel (with a recent FreeBSD, ie:
> 8.0) it'll choose one at random

aha!  that was the clue.  docs are a bit thin, still looking.  but thank
you.

randy
From bynkaay at gmail.com  Thu Sep 10 14:48:01 2009
From: bynkaay at gmail.com (WWW BYNKAAY COM)
Date: Thu Sep 10 14:48:08 2009
Subject: RevoFlash 3 ChipTuning by OBD2 with tuning maps @www.bynkaay.com
Message-ID: <20090910144523.B223E39B173@mx20.turkticaret.net>

Newsletter NKAAY CO., HK LTD
 w w w . b y n k a a y . c o m -

Welcome to BYNKAAY Newsletter

RevoFlash 3 ChipTuning by OBD2 with tuning maps.
Product Price  (in Euro) : 250

REVO is a Car Chip-Turning, specially designed for all kinds of modern
cars. 
Nowadays almost all the manufactures of cars are international groups or
enterprises, they have sold their cars to world-widely......more...

Engineered Performance for Your Cars 
REVO WORKS FOR VW AUDI SEAT SKODA DO A CAR ONLY NEED 10-MINUTE ONLY NEED
PUT THE SPP CABLE TO THE SOCKET OF DIANGOSTIC IN YOUR CAR AND OPEN THE SOFTWARE

REVO is a Car Chip-Turning, specially designed for all kinds of modern
cars. Nowadays almost all the manufactures of cars are international groups or
enterprises, 
they have sold their cars to world-widely. Due to the obvious differences
of fuel quality, temperature, air pressure, humidity, emission regulations and
so on in 
different countries and areas, the manufacturer must develop his vehicles
for a world wide market and must take into account the above different
circumstances.

DOWNLOAD DETAIL INFO


 BUY NOW!    Shipping by DHL 
Please visit our web site www.bynkaay.com   to see all products.

-CONTACTS INSTANT:


Mail : info@bynkaay.com
MSN :bynkaay@hotmail.com
YAHOO :bynkaay@yahoo.com
Skype : bynkaay
ICQ : 208344566

Support:
info@nkaay.com

Copyright (C) 2009 All Right Reserved
NKAAY CO., HK LIMITED | http://www.nkaay.com
Unsubscription : If you do not want to receive this newsletter please Click
Here

From cjeker at diehard.n-r-g.com  Thu Sep 10 14:56:28 2009
From: cjeker at diehard.n-r-g.com (Claudio Jeker)
Date: Thu Sep 10 14:56:34 2009
Subject: forwarding when two rip defaults
In-Reply-To: <m2ljkmrhvz.wl%randy@psg.com>
References: <m21vmfs7c0.wl%randy@psg.com>
 <m2ljkmrhvz.wl%randy@psg.com>
Message-ID: <20090910145626.GE23661@diehard.n-r-g.com>

On Thu, Sep 10, 2009 at 07:31:12AM -0700, Randy Bush wrote:
> >> say i run routed and receive rip default from two routers, on the same
> >> local ether.  what is the forwarding?  i presume it's not smart enough
> >> to balance flows.  i hope not alternating packets.  clue, please?
> > Unless you have RADIX_MPATH in your kernel (with a recent FreeBSD, ie:
> > 8.0) it'll choose one at random
> 
> aha!  that was the clue.  docs are a bit thin, still looking.  but thank
> you.
> 

I don't want to disrupt the party but I seriously doubt that routed
supports multipath routing. Routed's radix code is unable to handle
multipath routes.

-- 
:wq Claudio
From mailing at ekomedya.com  Thu Sep 10 15:18:52 2009
From: mailing at ekomedya.com (=?utf-8?Q?Eko_Bilgisayar_ve_=C4=B0leti=C5=9Fim_Hizmetleri_Ltd=2E_=C5=9Eti?=)
Date: Thu Sep 10 15:20:27 2009
Subject: Turkey Calling You To Visit - The Trade SHOW- In Las Vegas
Message-ID: <ee9f60b32dab590a6e5f8925834ed0ef@localhost.localdomain>

[http://www.turkeycalling.us]

[http://www.turkeycalling.us]

[http://www.turkeycalling.us]

[http://www.turkeycalling.us/turkey-fam/turkeyfam.htm]

Global Access Travel invites you to the Tradeshow in Las Vegas on September 13-15, 2009. Please visit us to get more information about our organization and services at our booth. If you fill the registration form or leave the business card when you visit us at our booth, you might be lucky visitor who is going to win our daily draw prize; Free inspection trip to Turkey. 

Yasal Uyar?;
Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini
hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir,
yasalar ya da anlasmalar geregi ?c?nc? kisiler ile paylasilmasi m?mk?n
olmayabilir.Mesaji alan kisi, mesajin g?nderilmek istendigi kisi veya
kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj
tarafiniza yanlislikla ulasmissa l?tfen mesaji geri g?nderiniz ve
sisteminizden siliniz. Global Access Travel bu mesajin icerigi ile ilgili
olarak hicbir hukuksal sorumlulugu kabul etmez

Disclaimer
This e-mail communication is intended only for the use of the individual
or entity to which it is addressed, and may contain information that is
privileged, confidential and that may not be made public by law or
agreement. If the recipient of this message is not the intended recipient
or entity, you are hereby notified that any further dissemination,
distribution or copying of this information is strictly prohibited. If you
have received this message in error, please immediately notify the sender
and delete it from your system. The Global Access Traveldoes not accept
legal responsibility for the contents of this message. Yasal Uyar?;
Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini
hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir,
yasalar ya da anlasmalar geregi ?c?nc? kisiler ile paylasilmasi m?mk?n
olmayabilir.Mesaji alan kisi, mesajin g?nderilmek istendigi kisi veya
kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj
tarafiniza yanlislikla ulasmissa l?tfen mesaji geri g?nderiniz ve
sisteminizden siliniz. Global Access Travel bu mesajin icerigi ile ilgili
olarak hicbir hukuksal sorumlulugu kabul etmez

Disclaimer
This e-mail communication is intended only for the use of the individual
or entity to which it is addressed, and may contain information that is
privileged, confidential and that may not be made public by law or
agreement. If the recipient of this message is not the intended recipient
or entity, you are hereby notified that any further dissemination,
distribution or copying of this information is strictly prohibited. If you
have received this message in error, please immediately notify the sender
and delete it from your system. The Global Access Traveldoes not accept
legal responsibility for the contents of this message. Yasal Uyar?;
Bu e-posta, sadece adreste belirtilen kisi veya kurulusun kullanimini
hedeflemekte olup,mesajda yer alan bilgiler kisiye ozel ve gizli olabilir,
yasalar ya da anlasmalar geregi ?c?nc? kisiler ile paylasilmasi m?mk?n
olmayabilir.Mesaji alan kisi, mesajin g?nderilmek istendigi kisi veya
kurulus degilse,bu mesaji yaymak,dagitmak veya kopyalamak yasaktir Mesaj
tarafiniza yanlislikla ulasmissa l?tfen mesaji geri g?nderiniz ve
sisteminizden siliniz. Global Access Travel bu mesajin icerigi ile ilgili
olarak hicbir hukuksal sorumlulugu kabul etmez

Disclaimer
This e-mail communication is intended only for the use of the individual
or entity to which it is addressed, and may contain information that is
privileged, confidential and that may not be made public by law or
agreement. If the recipient of this message is not the intended recipient
or entity, you are hereby notified that any further dissemination,
distribution or copying of this information is strictly prohibited. If you
have received this message in error, please immediately notify the sender
and delete it from your system. The Global Access Traveldoes not accept
legal responsibility for the contents of this message.
This message was sent by: TURKEY CALLING YOU TO VISIT "THE TRADE SHOW"  IN LAS VEGAS, N?zhetiye Cad, istanbul, Besiktas 34357, Turkey

Manage your subscription:
http://app.icontact.com/icp/mmail-mprofile.pl?r=47622556&l=82253&s=P83L&m=587775&c=305227


From randy at psg.com  Thu Sep 10 16:07:18 2009
From: randy at psg.com (Randy Bush)
Date: Thu Sep 10 16:07:24 2009
Subject: forwarding when two rip defaults
In-Reply-To: <20090910145626.GE23661@diehard.n-r-g.com>
References: <m21vmfs7c0.wl%randy@psg.com> <m2ljkmrhvz.wl%randy@psg.com>
	<20090910145626.GE23661@diehard.n-r-g.com>
Message-ID: <m2fxaurdfw.wl%randy@psg.com>

>>>> say i run routed and receive rip default from two routers, on the same
>>>> local ether.  what is the forwarding?  i presume it's not smart enough
>>>> to balance flows.  i hope not alternating packets.  clue, please?
>>> Unless you have RADIX_MPATH in your kernel (with a recent FreeBSD, ie:
>>> 8.0) it'll choose one at random
>> aha!  that was the clue.  docs are a bit thin, still looking.  but thank
>> you.
> I don't want to disrupt the party but I seriously doubt that routed
> supports multipath routing. Routed's radix code is unable to handle
> multipath routes.

maybe i am confused.  but my momma told me that routing != forwarding.

i.e. routed will receive two default routes and i hope would install
them in the fib, where RADIX_MPATH forwarding would take over.  am i
wrong about what routed will do?  will it choose only one to install in
the fib?

randy
From qing.li at bluecoat.com  Thu Sep 10 17:19:09 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Thu Sep 10 17:19:15 2009
Subject: forwarding when two rip defaults
References: <m21vmfs7c0.wl%randy@psg.com> <m2ljkmrhvz.wl%randy@psg.com>
	<20090910145626.GE23661@diehard.n-r-g.com>
	<m2fxaurdfw.wl%randy@psg.com>
Message-ID: <B583FBF374231F4A89607B4D08578A430467369C@bcs-mail03.internal.cacheflow.com>


>> I don't want to disrupt the party but I seriously doubt that routed
>> supports multipath routing. Routed's radix code is unable to handle
>> multipath routes.
>
> maybe i am confused.  but my momma told me that routing != forwarding.
>
> i.e. routed will receive two default routes and i hope would install
> them in the fib, where RADIX_MPATH forwarding would take over.  am i
> wrong about what routed will do?  will it choose only one to install in
> the fib?
>

  Yes, FIB is a subset of a RIB for the most part, but I think what Claudio 
  is referring to, is the "radix" code inside the "routed" implementation, 
  which is incapable of storing multiple routes to the same destination. 

  That version of the "radix" code is very similar to the original kernel 
  "radix" code. So although "routed" may be receiving multiple advertisements
  about the default routes, but because it's incapable of holding more 
  than 1 such entry in its RIB, how would it be able to install more 
  than 1 entry into the FIB ?

  When ECMP routes are present, the route selection for forwarding is 
  based on a simple hash key generated from the source and destination 
  IP addresses.
  
  Regarding the documentation, you can get some usage text from my original
  commit message. I agree more text in a man page form is warranted.
  At the time I did not receive much input so didn't bother to spend
  the cycles on more formal writeup. 

  http://svn.freebsd.org/viewvc/base?view=revision&revision=178167
  http://svn.freebsd.org/viewvc/base?view=revision&revision=178168

  -- Qing

From pyunyh at gmail.com  Thu Sep 10 21:16:44 2009
From: pyunyh at gmail.com (Pyun YongHyeon)
Date: Thu Sep 10 21:16:51 2009
Subject: D-Link DGE-560SX (Marvell 88E8061-based) doesn't see link
In-Reply-To: <20090908213335.GE1520@michelle.cdnetworks.com>
References: <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>
	<20090904212223.GA9950@michelle.cdnetworks.com>
	<20090908075030.GA6644@traktor.dnepro.net>
	<20090908213335.GE1520@michelle.cdnetworks.com>
Message-ID: <20090910211549.GK3298@michelle.cdnetworks.com>

On Tue, Sep 08, 2009 at 02:33:35PM -0700, Pyun YongHyeon wrote:
> On Tue, Sep 08, 2009 at 10:50:30AM +0300, Eugene Perevyazko wrote:
> > On Fri, Sep 04, 2009 at 02:22:23PM -0700, Pyun YongHyeon wrote:
> > > 
> > > 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.
> > >
> > 
> > Still no success.
> >  
> > mskc0: <D-Link 560SX Gigabit Ethernet> port 0xd800-0xd8ff mem 0xfeafc000-0xfeafffff irq 16 at device 0.0 on pci1
> > msk0: <Marvell Technology Group Ltd. Yukon XL Id 0xb3 Rev 0x03> on mskc0
> > msk0: Ethernet address: 00:21:91:52:4f:09
> > miibus0: <MII bus> on msk0
> > e1000phy0: <Marvell 88E1112 Gigabit PHY> PHY 0 on miibus0
> > e1000phy0:  1000baseSX, 1000baseSX-FDX, auto
> > mskc0: [FILTER]
> > 
> > ifconfig -m msk0
> > msk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> >         options=11a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4>
> >         capabilities=11a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4>
> >         ether 00:21:91:52:4f:09
> >         inet 10.2.3.1 netmask 0xffffff00 broadcast 10.2.3.255
> >         media: Ethernet autoselect (autoselect <full-duplex>)
> >         status: active
> >         supported media:
> >                 media autoselect
> >                 media 1000baseSX mediaopt full-duplex
> >                 media 1000baseSX
> >                 media none
> > 
> > Switch shows no link on the port.
> > 
> > # ifconfig msk0 media 1000baseSX mediaopt full-duplex
> > # ifconfig msk0
> > msk0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
> >         options=11a<TXCSUM,VLAN_MTU,VLAN_HWTAGGING,TSO4>
> >         ether 00:21:91:52:4f:09
> >         inet 10.2.3.1 netmask 0xffffff00 broadcast 10.2.3.255
> >         media: Ethernet 1000baseSX <full-duplex> (autoselect <full-duplex>)
> >         status: active
> > 
> > Switch shows no link again.
> > 
> > All dev.msk.0.stats counters are zero even after trying broadcast ping.
> > 
> > I can arrange you root access to the host with this NIC if you have time/wish.
> > 
> 
> I've sent mail in private.
> 

With the help of original poster, I think I've fixed it. If you're
msk(4) user and couldn't send/receive frames on fiber media, please
try the patch at the following URL and let me know how it goes.
http://people.freebsd.org/~yongari/msk/msk.DGE560.diff4
From ccowart at rescomp.berkeley.edu  Thu Sep 10 23:19:09 2009
From: ccowart at rescomp.berkeley.edu (Chris Cowart)
Date: Thu Sep 10 23:19:17 2009
Subject: IPSEC + long UDP causes reproducible crash [was: Crash in
 ether_input]
In-Reply-To: <20090910081337.GA66528@zeninc.net>
References: <20090904223123.GD16213@hal.rescomp.berkeley.edu>
	<723505E9-96C6-401C-A844-3D9BA2033795@neville-neil.com>
	<20090907191001.GA37291@hal.rescomp.berkeley.edu>
	<54FDC10A-EAE3-4AE2-BF36-2C5F7D141C3A@neville-neil.com>
	<20090910073739.GB37291@hal.rescomp.berkeley.edu>
	<20090910081337.GA66528@zeninc.net>
Message-ID: <20090910231908.GD37291@hal.rescomp.berkeley.edu>

VANHULLEBUS Yvan wrote:
> On Thu, Sep 10, 2009 at 12:37:39AM -0700, Chris Cowart wrote:
>> I have been using i386 and amd64 virtual machines as well as an amd64
>> physical machine; this problem can be reproduced fairly reliably on all
>> of them for 7.0 and 7.1 (and we're pretty sure we saw it in 6.x and
>> didn't know what it was at the time).
> 
> I fixed in FreeBSD 7.2+ a bug which looks to be related with your
> crashes (kernel panic with big packets), could you please try again
> with FreeBSD 7.2 and report us the result ?

The problem does indeed seem to be gone with 7.2.

Given that any unprivileged user could compile and run such a program on
an IPSEC-enabled pre-7.2 box and crash the system, isn't this a local
DoS exploit that should be fixed in the supported security branches
(including 7.1)?

-- 
Chris Cowart
Network Technical Lead
Network & Infrastructure Services, RSSP-IT
UC Berkeley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090910/78c85c83/attachment.pgp
From gavin at FreeBSD.org  Fri Sep 11 11:03:51 2009
From: gavin at FreeBSD.org (gavin@FreeBSD.org)
Date: Fri Sep 11 11:03:58 2009
Subject: amd64/138688: [rum] possibly broken on 8 Beta 4 amd64: able to
	wpa authenticate + obtain dhclient address, no communication though.
Message-ID: <200909111103.n8BB3pU5073637@freefall.freebsd.org>

Old Synopsis: rum possibly broken on 8 Beta 4 amd64: Linksys WUSB54GC v1 device appears as rum, clonable to wlan0, able to wpa authenticate + obtain dhclient address, no communication though.
New Synopsis: [rum] possibly broken on 8 Beta 4 amd64: able to wpa authenticate + obtain dhclient address, no communication though.

Responsible-Changed-From-To: freebsd-amd64->freebsd-net
Responsible-Changed-By: gavin
Responsible-Changed-When: Fri Sep 11 11:02:12 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s)

http://www.freebsd.org/cgi/query-pr.cgi?pr=138688
From mike at sentex.net  Fri Sep 11 11:46:39 2009
From: mike at sentex.net (Mike Tancsa)
Date: Fri Sep 11 11:46:46 2009
Subject: em driver input errors
In-Reply-To: <200909091525.n89FPUv3080170@lava.sentex.ca>
References: <200909091352.n89DqQDx079631@lava.sentex.ca>
	<538232.7388.qm@web63901.mail.re1.yahoo.com>
	<200909091513.n89FDgdf080109@lava.sentex.ca>
	<200909091525.n89FPUv3080170@lava.sentex.ca>
Message-ID: <200909111143.n8BBh7wm095653@lava.sentex.ca>

At 11:28 AM 9/9/2009, Mike Tancsa wrote:
>At 11:17 AM 9/9/2009, Mike Tancsa wrote:
>>The board is an intel
>>
>>http://www.intel.com/support/motherboards/server/s3000ah/
>>
>>Not sure if its wired as PCI-X or just a 32bit bus.  I am just 
>>popping in an em pcie nic to see if that makes a difference.  I 
>>have an igb as well as bge I can try later.
>
>OK, now there is
>
>em0@pci0:5:0:0: class=0x020000 card=0xa01f8086 chip=0x10d38086 
>rev=0x00 hdr=0x00
>     vendor     = 'Intel Corporation'
>     class      = network
>     subclass   = ethernet
>     cap 01[c8] = powerspec 2  supports D0 D3  current D0
>     cap 05[d0] = MSI supports 1 message, 64 bit
>     cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
>     cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled
>
>


OK, much better.  Two nights in a row without errors, and Friday AM 
has a lot of level0 dumps.  Perhaps as you speculated, the onboard 
NICs were wired to a slower bus...  The pcie 1x hasnt shown any errors yet.

Sep 11 00:01:00 backup3 kernel: em0: Excessive collisions = 0
Sep 11 00:01:00 backup3 kernel: em0: Sequence errors = 0
Sep 11 00:01:00 backup3 kernel: em0: Defer count = 0
Sep 11 00:01:00 backup3 kernel: em0: Missed Packets = 0
Sep 11 00:01:00 backup3 kernel: em0: Receive No Buffers = 0
Sep 11 00:01:00 backup3 kernel: em0: Receive Length Errors = 0
Sep 11 00:01:00 backup3 kernel: em0: Receive errors = 0
Sep 11 00:01:00 backup3 kernel: em0: Crc errors = 0
Sep 11 00:01:00 backup3 kernel: em0: Alignment errors = 0
Sep 11 00:01:00 backup3 kernel: em0: Collision/Carrier extension errors = 0
Sep 11 00:01:00 backup3 kernel: em0: RX overruns = 0
Sep 11 00:01:00 backup3 kernel: em0: watchdog timeouts = 0
Sep 11 00:01:00 backup3 kernel: em0: RX MSIX IRQ = 50004846 TX MSIX 
IRQ = 40678847 LINK MSIX IRQ = 1
Sep 11 00:01:00 backup3 kernel: em0: XON Rcvd = 0
Sep 11 00:01:00 backup3 kernel: em0: XON Xmtd = 0
Sep 11 00:01:00 backup3 kernel: em0: XOFF Rcvd = 0
Sep 11 00:01:00 backup3 kernel: em0: XOFF Xmtd = 0
Sep 11 00:01:00 backup3 kernel: em0: Good Packets Rcvd = 73064815
Sep 11 00:01:00 backup3 kernel: em0: Good Packets Xmtd = 52479296
Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts Xmtd = 0
Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts Failed = 0


Name    Mtu Network       Address              Ipkts Ierrs    Opkts Oerrs  Coll
em0    1500 <Link#1>      00:1b:21:3f:62:72 193269942     0 
133269168     0     0
em0    1500 10.45.129.132 10.45.129.133            0     -        0     -     -
em1    1500 <Link#2>      00:15:17:57:31:8a        0     0        0     0     0
em1    1500 10.45.129.128 10.45.129.129            0     -        0     -     -
em2*   1500 <Link#3>      00:15:17:57:31:8b        0     0        0     0     0

         ---Mike

--------------------------------------------------------------------
Mike Tancsa,                                      tel +1 519 651 3400
Sentex Communications,                            mike@sentex.net
Providing Internet since 1994                    www.sentex.net
Cambridge, Ontario Canada                         www.sentex.net/mike

From nao at tom-yam.or.jp  Fri Sep 11 12:03:02 2009
From: nao at tom-yam.or.jp (Naoki Hamada)
Date: Fri Sep 11 12:03:08 2009
Subject: FIB for RELENG_6?
Message-ID: <2da2ec620909110441o2575dcd4tc8498ecff59caf03@mail.gmail.com>

Hello, guys!

Is there a patch set of FIB for RELENG_6 (now 6.4-STABLE)?
If there is any, I want apply it to my multi-homed server in preparation for
a forthcoming IP address transition process and mitigate its complication.
I tried a FIB enabled 7.2 machine with recent changes and found it perfectly
fits my purpose.

Regards,

Naoki Hamada
nao@tom-yam.or.jp
From julian at elischer.org  Fri Sep 11 15:29:35 2009
From: julian at elischer.org (Julian Elischer)
Date: Fri Sep 11 15:29:41 2009
Subject: FIB for RELENG_6?
In-Reply-To: <2da2ec620909110441o2575dcd4tc8498ecff59caf03@mail.gmail.com>
References: <2da2ec620909110441o2575dcd4tc8498ecff59caf03@mail.gmail.com>
Message-ID: <4AAA6CDC.2060406@elischer.org>

Naoki Hamada wrote:
> Hello, guys!
> 
> Is there a patch set of FIB for RELENG_6 (now 6.4-STABLE)?
> If there is any, I want apply it to my multi-homed server in preparation for
> a forthcoming IP address transition process and mitigate its complication.
> I tried a FIB enabled 7.2 machine with recent changes and found it perfectly
> fits my purpose.
> 
> Regards,
> 
> Naoki Hamada
> nao@tom-yam.or.jp
> _______________________________________________
> 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"


multi fib support in 6 was not released from Ironport.

if you have 7 why do you want to stay with 6?

From jfvogel at gmail.com  Fri Sep 11 16:38:31 2009
From: jfvogel at gmail.com (Jack Vogel)
Date: Fri Sep 11 16:38:37 2009
Subject: em driver input errors
In-Reply-To: <200909111143.n8BBh7wm095653@lava.sentex.ca>
References: <200909091352.n89DqQDx079631@lava.sentex.ca>
	<538232.7388.qm@web63901.mail.re1.yahoo.com>
	<200909091513.n89FDgdf080109@lava.sentex.ca>
	<200909091525.n89FPUv3080170@lava.sentex.ca>
	<200909111143.n8BBh7wm095653@lava.sentex.ca>
Message-ID: <2a41acea0909110938l2348e35ah11bd1876fbe22dd3@mail.gmail.com>

Glad to hear this.

Jack


On Fri, Sep 11, 2009 at 4:46 AM, Mike Tancsa <mike@sentex.net> wrote:

> At 11:28 AM 9/9/2009, Mike Tancsa wrote:
>
>> At 11:17 AM 9/9/2009, Mike Tancsa wrote:
>>
>>> The board is an intel
>>>
>>> http://www.intel.com/support/motherboards/server/s3000ah/
>>>
>>> Not sure if its wired as PCI-X or just a 32bit bus.  I am just popping in
>>> an em pcie nic to see if that makes a difference.  I have an igb as well as
>>> bge I can try later.
>>>
>>
>> OK, now there is
>>
>> em0@pci0:5:0:0: class=0x020000 card=0xa01f8086 chip=0x10d38086 rev=0x00
>> hdr=0x00
>>    vendor     = 'Intel Corporation'
>>    class      = network
>>    subclass   = ethernet
>>    cap 01[c8] = powerspec 2  supports D0 D3  current D0
>>    cap 05[d0] = MSI supports 1 message, 64 bit
>>    cap 10[e0] = PCI-Express 1 endpoint max data 128(256) link x1(x1)
>>    cap 11[a0] = MSI-X supports 5 messages in map 0x1c enabled
>>
>>
>>
>
> OK, much better.  Two nights in a row without errors, and Friday AM has a
> lot of level0 dumps.  Perhaps as you speculated, the onboard NICs were wired
> to a slower bus...  The pcie 1x hasnt shown any errors yet.
>
> Sep 11 00:01:00 backup3 kernel: em0: Excessive collisions = 0
> Sep 11 00:01:00 backup3 kernel: em0: Sequence errors = 0
> Sep 11 00:01:00 backup3 kernel: em0: Defer count = 0
> Sep 11 00:01:00 backup3 kernel: em0: Missed Packets = 0
> Sep 11 00:01:00 backup3 kernel: em0: Receive No Buffers = 0
> Sep 11 00:01:00 backup3 kernel: em0: Receive Length Errors = 0
> Sep 11 00:01:00 backup3 kernel: em0: Receive errors = 0
> Sep 11 00:01:00 backup3 kernel: em0: Crc errors = 0
> Sep 11 00:01:00 backup3 kernel: em0: Alignment errors = 0
> Sep 11 00:01:00 backup3 kernel: em0: Collision/Carrier extension errors = 0
> Sep 11 00:01:00 backup3 kernel: em0: RX overruns = 0
> Sep 11 00:01:00 backup3 kernel: em0: watchdog timeouts = 0
> Sep 11 00:01:00 backup3 kernel: em0: RX MSIX IRQ = 50004846 TX MSIX IRQ =
> 40678847 LINK MSIX IRQ = 1
> Sep 11 00:01:00 backup3 kernel: em0: XON Rcvd = 0
> Sep 11 00:01:00 backup3 kernel: em0: XON Xmtd = 0
> Sep 11 00:01:00 backup3 kernel: em0: XOFF Rcvd = 0
> Sep 11 00:01:00 backup3 kernel: em0: XOFF Xmtd = 0
> Sep 11 00:01:00 backup3 kernel: em0: Good Packets Rcvd = 73064815
> Sep 11 00:01:00 backup3 kernel: em0: Good Packets Xmtd = 52479296
> Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts Xmtd = 0
> Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts Failed = 0
>
>
> Name    Mtu Network       Address              Ipkts Ierrs    Opkts Oerrs
>  Coll
> em0    1500 <Link#1>      00:1b:21:3f:62:72 193269942     0 133269168     0
>     0
> em0    1500 10.45.129.132 10.45.129.133            0     -        0     -
>   -
> em1    1500 <Link#2>      00:15:17:57:31:8a        0     0        0     0
>   0
> em1    1500 10.45.129.128 10.45.129.129            0     -        0     -
>   -
> em2*   1500 <Link#3>      00:15:17:57:31:8b        0     0        0     0
>   0
>
>
>        ---Mike
>
> --------------------------------------------------------------------
> Mike Tancsa,                                      tel +1 519 651 3400
> Sentex Communications,                            mike@sentex.net
> Providing Internet since 1994                    www.sentex.net
> Cambridge, Ontario Canada                         www.sentex.net/mike
>
> _______________________________________________
> 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 peterjeremy at acm.org  Fri Sep 11 21:50:10 2009
From: peterjeremy at acm.org (Peter Jeremy)
Date: Fri Sep 11 21:50:17 2009
Subject: New tcpdump in 8.x
Message-ID: <20090911215006.GA31432@server.vk2pj.dyndns.org>

[Please excuse long lines]

Who has used tcpdump on FreeBSD 8.x and likes it?  Is it just me or is
it now far harder to investigate network problems using it?

Prior to 8.x, the default output includes SEQ number ranges for any
TCP packets with data, so a 'tcpdump -n' looks like the following and
it's immediately obvious that there's 2920 bytes of data missing:

08:48:32.137596 IP 134.159.99.234.60834 > 122.106.250.30.2202: . 221537:222997(1460) ack 2609 win 65535
08:48:32.138492 IP 134.159.99.234.60834 > 122.106.250.30.2202: . 222997:224457(1460) ack 2609 win 65535
08:48:32.139601 IP 122.106.250.30.2202 > 134.159.99.234.60834: . ack 224457 win 64240
08:48:32.145623 IP 134.159.99.234.60834 > 122.106.250.30.2202: . 227377:228837(1460) ack 2609 win 65535
08:48:32.146703 IP 122.106.250.30.2202 > 134.159.99.234.60834: . ack 224457 win 65535

The same output on 8.x looks like the following.  Whilst the last ACK
packet looks anomolous, there's no useful information to analyse further.

08:48:32.137596 IP 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], ack 2609, win 65535, length 1460
08:48:32.138492 IP 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], ack 2609, win 65535, length 1460
08:48:32.139601 IP 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], ack 224457, win 64240, length 0
08:48:32.145623 IP 134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], ack 2609, win 65535, length 1460
08:48:32.146703 IP 122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], ack 224457, win 65535, length 0

In order to see the SEQ numbers (which are essential to make sense of
the capture), you need to add '-vv' - which turns the output into:

08:48:32.137596 IP (tos 0x0, ttl 52, id 32485, offset 0, flags [DF], proto TCP (6), length 1500)
    134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], seq 221537:222997, ack 2609, win 65535, length 1460
08:48:32.138492 IP (tos 0x0, ttl 52, id 32486, offset 0, flags [DF], proto TCP (6), length 1500)
    134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], seq 222997:224457, ack 2609, win 65535, length 1460
08:48:32.139601 IP (tos 0x8, ttl 63, id 46554, offset 0, flags [DF], proto TCP (6), length 40)
    122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], cksum 0xe759 (correct), seq 2609, ack 224457, win 64240, length 0
08:48:32.145623 IP (tos 0x0, ttl 52, id 32489, offset 0, flags [DF], proto TCP (6), length 1500)
    134.159.99.234.60834 > 122.106.250.30.2202: Flags [.], seq 227377:228837, ack 2609, win 65535, length 1460
08:48:32.146703 IP (tos 0x8, ttl 63, id 46555, offset 0, flags [DF], proto TCP (6), length 40)
    122.106.250.30.2202 > 134.159.99.234.60834: Flags [.], cksum 0xe24a (correct), seq 2609, ack 224457, win 65535, length 0

Whilst it's now possible to work out that there's 2920 bytes of data
missing, this information is mixed up in so much other extraneous
information that the dump is almost useless.  In particular, it's no
longer possible to scan a tcpdump output and easily see packet loss or
out-of-order delivery.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090911/76742e73/attachment.pgp
From sthaug at nethelp.no  Fri Sep 11 22:12:08 2009
From: sthaug at nethelp.no (sthaug@nethelp.no)
Date: Fri Sep 11 22:12:15 2009
Subject: New tcpdump in 8.x
In-Reply-To: <20090911215006.GA31432@server.vk2pj.dyndns.org>
References: <20090911215006.GA31432@server.vk2pj.dyndns.org>
Message-ID: <20090912.001205.74713342.sthaug@nethelp.no>

> Who has used tcpdump on FreeBSD 8.x and likes it?  Is it just me or is
> it now far harder to investigate network problems using it?
> 
> Prior to 8.x, the default output includes SEQ number ranges for any
> TCP packets with data, so a 'tcpdump -n' looks like the following and
> it's immediately obvious that there's 2920 bytes of data missing:
...
> The same output on 8.x looks like the following.  Whilst the last ACK
> packet looks anomolous, there's no useful information to analyse further.

I agree that this change is rather unhelpful. However, this is the
default for tcpdump 4.0.0. Thus the choice is between the old tcpdump,
the new one (with bugfixes and more protocol decoding), or possibly
the new one plus local patches. Not an easy choice, is it?

The place to discuss this change is probably the tcpdump-workers list,

    tcpdump-workers@lists.tcpdump.org

Steinar Haug, Nethelp consulting, sthaug@nethelp.no
From edwin at mavetju.org  Fri Sep 11 22:56:49 2009
From: edwin at mavetju.org (Edwin Groothuis)
Date: Fri Sep 11 22:56:56 2009
Subject: New tcpdump in 8.x
In-Reply-To: <20090912.001205.74713342.sthaug@nethelp.no>
References: <20090911215006.GA31432@server.vk2pj.dyndns.org>
	<20090912.001205.74713342.sthaug@nethelp.no>
Message-ID: <20090911223702.GA4562@mavetju.org>

On Sat, Sep 12, 2009 at 12:12:05AM +0200, sthaug@nethelp.no wrote:
> > Who has used tcpdump on FreeBSD 8.x and likes it?  Is it just me or is
> > it now far harder to investigate network problems using it?
> > 
> > Prior to 8.x, the default output includes SEQ number ranges for any
> > TCP packets with data, so a 'tcpdump -n' looks like the following and
> > it's immediately obvious that there's 2920 bytes of data missing:
> ...
> > The same output on 8.x looks like the following.  Whilst the last ACK
> > packet looks anomolous, there's no useful information to analyse further.
> 
> I agree that this change is rather unhelpful. However, this is the
> default for tcpdump 4.0.0. Thus the choice is between the old tcpdump,
> the new one (with bugfixes and more protocol decoding), or possibly
> the new one plus local patches. Not an easy choice, is it?

While I agree with the original poster that you are missing some
data, I also agree that talking to the "vendors" of tcpdump is a
better way.

Peter, if you are keen on it, submit a port (net/tcpdump39) which
gives you the old functionality and alert me about it.

Edwin, who at least now knows why tcpdump on 8.0B3 did look so trange.

-- 
Edwin Groothuis		Website: http://www.mavetju.org/
edwin@mavetju.org	Weblog:  http://www.mavetju.org/weblog/
From linimon at FreeBSD.org  Sat Sep 12 00:53:39 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Sat Sep 12 00:53:46 2009
Subject: kern/138739: [wpi] wpi(4) does not work very well under
	8.0-BETA4
Message-ID: <200909120053.n8C0rcbZ005357@freefall.freebsd.org>

Old Synopsis: wpi(4) does not work very well under 8.0-BETA4
New Synopsis: [wpi] wpi(4) does not work very well under 8.0-BETA4

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Sep 12 00:53:04 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=138739
From linimon at FreeBSD.org  Sat Sep 12 03:37:29 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Sat Sep 12 03:37:35 2009
Subject: kern/138689: [netinet] patch] Multicast: IP_DROP_MEMBERSHIP
	should return EADDRNOTAVAIL for invalid address
Message-ID: <200909120337.n8C3bSRU066603@freefall.freebsd.org>

Old Synopsis: [patch] Multicast: IP_DROP_MEMBERSHIP should return EADDRNOTAVAIL for invalid address
New Synopsis: [netinet] patch] Multicast: IP_DROP_MEMBERSHIP should return EADDRNOTAVAIL for invalid address

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Sep 12 03:36:23 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=138689
From linimon at FreeBSD.org  Sat Sep 12 03:38:17 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Sat Sep 12 03:38:29 2009
Subject: kern/138690: [netinet] [patch] multicast: uninited memory used
	in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP
Message-ID: <200909120338.n8C3cHj3066687@freefall.freebsd.org>

Old Synopsis: Multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP
New Synopsis: [netinet] [patch] multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Sep 12 03:37:52 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=138690
From linimon at FreeBSD.org  Sat Sep 12 03:38:59 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Sat Sep 12 03:39:11 2009
Subject: kern/137164: [netinet] [patch] assert panic imo_match_source()
Message-ID: <200909120338.n8C3cxeu066770@freefall.freebsd.org>

Old Synopsis: [socket] [panic] assert panic imo_match_source()
New Synopsis: [netinet] [patch] assert panic imo_match_source()

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Sep 12 03:38:26 UTC 2009
Responsible-Changed-Why: 
A patch is now included.  Reassign to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=137164
From linimon at FreeBSD.org  Sat Sep 12 03:39:28 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Sat Sep 12 03:39:35 2009
Subject: kern/138691: [netinet] [patch] Multicast: Keep membership and
	filters in sync
Message-ID: <200909120339.n8C3dRPA066851@freefall.freebsd.org>

Old Synopsis: Multicast: Keep membership and filters in sync
New Synopsis: [netinet] [patch] Multicast: Keep membership and filters in sync

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Sep 12 03:39:08 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=138691
From linimon at FreeBSD.org  Sat Sep 12 03:45:36 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Sat Sep 12 03:45:49 2009
Subject: kern/138694: [bge] FreeBSD 6.3 release does not recognize
	Broadcom BCM5709C card on IBM X3550 M2
Message-ID: <200909120345.n8C3jaWG076306@freefall.freebsd.org>

Synopsis: [bge] FreeBSD 6.3 release does not recognize Broadcom BCM5709C card on IBM X3550 M2

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Sep 12 03:45:23 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=138694
From rihad at mail.ru  Sat Sep 12 09:07:56 2009
From: rihad at mail.ru (rihad)
Date: Sat Sep 12 09:08:04 2009
Subject: [POLLING] strange interrupt/system load
Message-ID: <4AAB4D56.30207@mail.ru>

The box experiences ~230 mbit/s traffic flow through it. I've doubled 
some sysctls after reading polling(4):
kern.polling.each_burst=10 # was: 5
kern.polling.burst_max=350 # was: 150

FreeBSD 7.2-RELEASE-p3 amd64
HZ=1000

Now for the fun part.

With kern.polling.idle_poll = 1 top shows:
CPU:  0.0% user,  0.0% nice, 26.9% system,  3.1% interrupt, 70.0% idle
~8000 interrupts/s total according to systat -vmstat:
1999 cpu0: time
2000 cpu1: time
1999 cpu2: time
1999 cpu3: time

With kern.polling.idle_poll = 0 top shows:
CPU:  0.0% user,  0.0% nice,  0.0% system, 13.9% interrupt, 86.0% idle
Still the same ~8000 clock interrupts/s.

Under both scenarios polling is enabled on both em0 and em1 through 
ifconfig.


1) Why is the interrupt load relatively high with polling enabled?
2) How come 13.9% interrupts are not also in the first scenario if their 
total rate is the same (~8000)?

Thanks.
From brde at optusnet.com.au  Sat Sep 12 10:59:32 2009
From: brde at optusnet.com.au (Bruce Evans)
Date: Sat Sep 12 10:59:40 2009
Subject: [POLLING] strange interrupt/system load
In-Reply-To: <4AAB4D56.30207@mail.ru>
References: <4AAB4D56.30207@mail.ru>
Message-ID: <20090912202529.X1569@besplex.bde.org>

On Sat, 12 Sep 2009, rihad wrote:

> The box experiences ~230 mbit/s traffic flow through it. I've doubled some 
> sysctls after reading polling(4):
> kern.polling.each_burst=10 # was: 5
> kern.polling.burst_max=350 # was: 150
>
> FreeBSD 7.2-RELEASE-p3 amd64
> HZ=1000

How much better does it work without POLLING?

> Now for the fun part.
>
> With kern.polling.idle_poll = 1 top shows:
> CPU:  0.0% user,  0.0% nice, 26.9% system,  3.1% interrupt, 70.0% idle
> ~8000 interrupts/s total according to systat -vmstat:
> 1999 cpu0: time
> 2000 cpu1: time
> 1999 cpu2: time
> 1999 cpu3: time

I think the poll thread is still single-threaded.  It takes all the
available time from 1 idle CPU (possibly not always the same one), and
thus makes an average of 1 CPU 100% not-really-idle, and thus ensures
a CPU utlization of at lease 25% with 4 CPUs.  Here you have slightly
more than 25%.

> With kern.polling.idle_poll = 0 top shows:
> CPU:  0.0% user,  0.0% nice,  0.0% system, 13.9% interrupt, 86.0% idle
> Still the same ~8000 clock interrupts/s.

The actual overhead seems to be 14% of 4 CPUs or 56% of 1 CPU.  Polling in
idle is mostly wasting 44% of 1 CPU.  (The wastage is not quite complete
since polling may improve latency).

> Under both scenarios polling is enabled on both em0 and em1 through ifconfig.

POLLING is especially useless for em since its hardware has better
interrupt moderation than most NICs.  In non-old versions of FreeBSD
em should be configured so as to not use it, and then em will use fast
interrupts and threads, a method that has a chance of working much
better than both POLLING and normal interrupts (but I haven't actually
seen it working much better).  However, em's configuration of this is
bad: you have to not configure POLLING, and this prevents use of polling
on NICs that might actually benefit from it.

> 1) Why is the interrupt load relatively high with polling enabled?

3.1% is already high.  Probably there are a lot of software interrupts
(netisrs).

> 2) How come 13.9% interrupts are not also in the first scenario if their 
> total rate is the same (~8000)?

Possibly there are even more software interrupts, due to the polling thread
running into itself.  Look at %CPU for each individual thread.

Without polling, but with non-fast em interrupts, there will be lots
of em interrupts, and the interrupt overhead will be more evenly
distributed between the em interrupt thread and swi thread(s), so it
is easier to see where the cycles are going (still quite hard, since
lots of the cycles are for cache misses and a badly-behaved thread or
hardware may cause the slowness to appear to be in a different thread
due to it pushing the cache misses there...).  Without polling, but
with fast em interrupts and em non-interrupt threads, the interrupt
overhead should be nearly 0, but the overhead will mostly just have
moved, but with real or potential gains to latency and throughput from
parallelism (parallellism probably increases overheads a little but
improves network throughput and latency at a cost to other concurrent
uses of the CPUs that don't matter iff there ar CPU cycles to spare).
(Overhead for fast interrupts is not accounted for accurately -- it
will be charged to the interrupted context.  The non-interrupt threads
will be charged as "system".)

Bruce
From rizzo at iet.unipi.it  Sat Sep 12 13:36:26 2009
From: rizzo at iet.unipi.it (Luigi Rizzo)
Date: Sat Sep 12 13:36:33 2009
Subject: [POLLING] strange interrupt/system load
In-Reply-To: <4AAB4D56.30207@mail.ru>
References: <4AAB4D56.30207@mail.ru>
Message-ID: <20090912134226.GD46135@onelab2.iet.unipi.it>

On Sat, Sep 12, 2009 at 12:27:18PM +0500, rihad wrote:
> The box experiences ~230 mbit/s traffic flow through it. I've doubled 
> some sysctls after reading polling(4):
> kern.polling.each_burst=10 # was: 5
> kern.polling.burst_max=350 # was: 150
> 
> FreeBSD 7.2-RELEASE-p3 amd64
> HZ=1000
> 
> Now for the fun part.
> 
> With kern.polling.idle_poll = 1 top shows:
> CPU:  0.0% user,  0.0% nice, 26.9% system,  3.1% interrupt, 70.0% idle
> ~8000 interrupts/s total according to systat -vmstat:
> 1999 cpu0: time
> 2000 cpu1: time
> 1999 cpu2: time
> 1999 cpu3: time
> 
> With kern.polling.idle_poll = 0 top shows:
> CPU:  0.0% user,  0.0% nice,  0.0% system, 13.9% interrupt, 86.0% idle
> Still the same ~8000 clock interrupts/s.
> 
> Under both scenarios polling is enabled on both em0 and em1 through 
> ifconfig.
> 
> 
> 1) Why is the interrupt load relatively high with polling enabled?
> 2) How come 13.9% interrupts are not also in the first scenario if their 
> total rate is the same (~8000)?

Polling enabled means that at every tick (and in the idle loop if you
also have idle_poll enabled) you are checking the status of the
interface even if there is no traffic. The polling handler is probably
accounted for as 'interrupt'. The load you see shoud not be too
different to what you see without polling.

Enabling idle_poll moves part of the work to the idle loop(s) which
are accounted as 'system' time. What happens here is that part of
the work is taken away from the polling handlers that run on each
tick so you see a reduction on the interrupt time, whereas as
Bruce said, one CPU is using 100% of its time (or 25% of the total
work capacity) to run the idle_poll loop.

cheers
luigi
From rihad at mail.ru  Sat Sep 12 15:02:56 2009
From: rihad at mail.ru (rihad)
Date: Sat Sep 12 15:03:03 2009
Subject: [POLLING] strange interrupt/system load
In-Reply-To: <20090912202529.X1569@besplex.bde.org>
References: <4AAB4D56.30207@mail.ru> <20090912202529.X1569@besplex.bde.org>
Message-ID: <4AABB81D.9070907@mail.ru>

Bruce Evans wrote:
> How much better does it work without POLLING?
I'm not sure. It just works, How to measure it? I haven't noticed it
adding any unacceptable latency to users' experience, making TCP/IP
work less than optimal (we're an ISP). Once thing I did notice with
POLLING enabled was that kern.polling.lost_polls was growing at a rate
of2-3 per second, but after I enabled idle_poll the rate decreased to 1
lost poll every 10-15 seconds (burst_max & each_burst have been doubled
in both scenarios).

> On Sat, 12 Sep 2009, rihad wrote:
> 
> POLLING is especially useless for em since its hardware has better 
> interrupt moderation than most NICs.  In non-old versions of FreeBSD 
> em should be configured so as to not use it, and then em will use 
> fast interrupts and threads, a method that has a chance of working 
> much better than both POLLING and normal interrupts (but I haven't 
> actually seen it working much better).  However, em's configuration 
> of this is bad: you have to not configure POLLING, and this prevents
>  use of polling on NICs that might actually benefit from it.
> 
I understand it's not enough to just strip off the -polling part from
the rc.conf line, but I also absolutely must rebuild the kernel with
DEVICE_POLLING removed to get "fast em interrupts" working? Why, in
theory, would ifconfigging some other nic, say, bce0, with polling
alongside em0 without, not let em0 work without POLLING and bce0 with
it? Mind you, I'm not using the deprecated kern.polling.enable sysctl:
kern.polling.enable: 0
kern.polling.handlers: 2
I might as well have configured one interface with polling and one 
without. Or not?
From ralph at imada.sdu.dk  Sat Sep 12 18:58:13 2009
From: ralph at imada.sdu.dk (Ralph Zitz)
Date: Sat Sep 12 18:58:21 2009
Subject: bwi driver
Message-ID: <4AABE908.5020201@imada.sdu.dk>

Hello

I'm the unfortunate owner of the unsupported "Intel WiFi Link 5100 AGN" 
card. Looking through some old hardware I found the following: "Linksys 
WPC54G version 3.1" pccard. I realize that the bwi driver lists as only 
supporting version 3, but might there be a chance my card works with the 
driver as well?

When the card is inserted the kernel outputs the following:
bwi0: <Broadcom BCM4318 802.11b/g Wireless Lan> mem 
0xbf8a2000-0xbf8a3fff irq 16 at device 0.0 on cardbus0
bwi0: [ITHREAD]
bwi0: no BBP id for device id 0x4318
device_attach: bwi0 attach returned 6

Regards,
Ralph.
From dfilter at FreeBSD.ORG  Sat Sep 12 19:00:18 2009
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Sat Sep 12 19:00:25 2009
Subject: kern/138689: commit references a PR
Message-ID: <200909121900.n8CJ0HJu030374@freefall.freebsd.org>

The following reply was made to PR kern/138689; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/138689: commit references a PR
Date: Sat, 12 Sep 2009 18:55:27 +0000 (UTC)

 Author: bms
 Date: Sat Sep 12 18:55:15 2009
 New Revision: 197129
 URL: http://svn.freebsd.org/changeset/base/197129
 
 Log:
   Fix an API issue in leave processing for IPv4 multicast groups.
    * Do not assume that the group lookup performed by imo_match_group()
      is valid when ifp is NULL in this case.
    * Instead, return EADDRNOTAVAIL if the ifp cannot be resolved for the
      membership we are being asked to leave.
   
   Caveat user:
    * The way IPv4 multicast memberships are implemented in the inpcb layer
      at the moment, has the side-effect that struct ip_moptions will
      still hold the membership, under the old ifp, until ip_freemoptions()
      is called for the parent inpcb.
    * The underlying issue is: the inpcb layer does not get notification
      of ifp being detached going away in a thread-safe manner.
      This is non-trivial to fix.
   
   But hey, at least the kernel should't panic when you unplug a card.
   
   PR:		138689
   Submitted by:	Stef Walter
   MFC after:	5 days
 
 Modified:
   head/sys/netinet/in_mcast.c
 
 Modified: head/sys/netinet/in_mcast.c
 ==============================================================================
 --- head/sys/netinet/in_mcast.c	Sat Sep 12 18:24:31 2009	(r197128)
 +++ head/sys/netinet/in_mcast.c	Sat Sep 12 18:55:15 2009	(r197129)
 @@ -2189,6 +2189,9 @@ inp_leave_group(struct inpcb *inp, struc
  	if (!IN_MULTICAST(ntohl(gsa->sin.sin_addr.s_addr)))
  		return (EINVAL);
  
 +	if (ifp == NULL)
 +		return (EADDRNOTAVAIL);
 +
  	/*
  	 * Find the membership in the membership array.
  	 */
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
From bms at FreeBSD.org  Sat Sep 12 19:01:42 2009
From: bms at FreeBSD.org (bms@FreeBSD.org)
Date: Sat Sep 12 19:01:54 2009
Subject: kern/138689: [netinet] patch] Multicast: IP_DROP_MEMBERSHIP
	should return EADDRNOTAVAIL for invalid address
Message-ID: <200909121901.n8CJ1fEG039523@freefall.freebsd.org>

Synopsis: [netinet] patch] Multicast: IP_DROP_MEMBERSHIP should return EADDRNOTAVAIL for invalid address

State-Changed-From-To: open->patched
State-Changed-By: bms
State-Changed-When: Sat 12 Sep 2009 19:00:58 UTC
State-Changed-Why: 
Committed to HEAD as rev 197129.·
Thanks for your work in tracking down and fixing this issue.

This fix deals with the POLA violation in the userland API,
but doesn't fix the underlying issue, which requires a bit more thought.

The inpcb layer will not learn about interfaces going down, even
though the netinet stack cleans up its references to link-layer
structures.

To be frank: this situation comes about largely because getting the BSD
network stack right for hot-swappable interfaces, requires swinging a big
hammer around in a number of APIs and structures.
In short, it's the sort of thing which gets chewed over at developer
summits. ;-)

IPv4 multicast structures are keyed by ifp. Should ifp be invalidated
due to an interface being detached at runtime, and a userland consumer
later tries to delete a membership, the lookup will fail.

The membership will however still exist. There isn't really an easy
way to deal with this, without implementing a full walk of all socket(s)
with memberships on the ifp, and invalidating the inpcb's reference
to the group, when in_ifdetach() is actually called on interface detach.

The membership is eventually cleaned up by the call to inp_freemoptions()
during the PCB cleanup when the socket is closed. It is a non-trivial
issue to resolve, because it would involve taking socket-layer locks
from a lower level path, leading to a lock order violation.

Coding around issues in the stack is not really the right approach--
the better approach is to fix problems at source. Unfortunately,
the project(s) involved are all separate, and communication hasn't
really been that great between them in the past. That, and it takes
a while for fixes to percolate into kernels because of release schedules.

The code in Quagga looks really ugly, but I suppose this is what
ends up happening in situations like this, where the development of
stack components is not that cohesive.


http://www.freebsd.org/cgi/query-pr.cgi?pr=138689
From bms at FreeBSD.org  Sat Sep 12 19:07:52 2009
From: bms at FreeBSD.org (bms@FreeBSD.org)
Date: Sat Sep 12 19:07:58 2009
Subject: kern/138691: [netinet] [patch] Multicast: Keep membership and
	filters in sync
Message-ID: <200909121907.n8CJ7qtM039675@freefall.freebsd.org>

Synopsis: [netinet] [patch] Multicast: Keep membership and filters in sync

State-Changed-From-To: open->patched
State-Changed-By: bms
State-Changed-When: Sat 12 Sep 2009 19:07:33 UTC
State-Changed-Why: 
Committed to HEAD as SVN rev 197130, thanks!

This is an obvious logic error that crept in during SSM refactoring,
and should get MFCed as soon as possible.


http://www.freebsd.org/cgi/query-pr.cgi?pr=138691
From dfilter at FreeBSD.ORG  Sat Sep 12 19:10:04 2009
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Sat Sep 12 19:10:10 2009
Subject: kern/138691: commit references a PR
Message-ID: <200909121910.n8CJA3oB039795@freefall.freebsd.org>

The following reply was made to PR kern/138691; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/138691: commit references a PR
Date: Sat, 12 Sep 2009 19:07:15 +0000 (UTC)

 Author: bms
 Date: Sat Sep 12 19:07:03 2009
 New Revision: 197130
 URL: http://svn.freebsd.org/changeset/base/197130
 
 Log:
   Fix an obvious logic error in the IPv4 multicast leave processing,
   where the filter mode vector was not updated correctly after the leave.
   
   PR:		138691
   Submitted by:	Stef Walter
   MFC after:	5 days
 
 Modified:
   head/sys/netinet/in_mcast.c
 
 Modified: head/sys/netinet/in_mcast.c
 ==============================================================================
 --- head/sys/netinet/in_mcast.c	Sat Sep 12 18:55:15 2009	(r197129)
 +++ head/sys/netinet/in_mcast.c	Sat Sep 12 19:07:03 2009	(r197130)
 @@ -2278,9 +2278,11 @@ out_imf_rollback:
  	imf_reap(imf);
  
  	if (is_final) {
 -		/* Remove the gap in the membership array. */
 -		for (++idx; idx < imo->imo_num_memberships; ++idx)
 +		/* Remove the gap in the membership and filter array. */
 +		for (++idx; idx < imo->imo_num_memberships; ++idx) {
  			imo->imo_membership[idx-1] = imo->imo_membership[idx];
 +			imo->imo_mfilters[idx-1] = imo->imo_mfilters[idx];
 +		}
  		imo->imo_num_memberships--;
  	}
  
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
From ralph at imada.sdu.dk  Sat Sep 12 19:10:19 2009
From: ralph at imada.sdu.dk (Ralph Zitz)
Date: Sat Sep 12 19:10:29 2009
Subject: bwi driver
In-Reply-To: <4AABE908.5020201@imada.sdu.dk>
References: <4AABE908.5020201@imada.sdu.dk>
Message-ID: <4AABF215.10203@imada.sdu.dk>

Oh and this is on: FreeBSD 9.0-CURRENT #4 r197120 amd64

Ralph Zitz wrote:
> Hello
>
> I'm the unfortunate owner of the unsupported "Intel WiFi Link 5100 
> AGN" card. Looking through some old hardware I found the following: 
> "Linksys WPC54G version 3.1" pccard. I realize that the bwi driver 
> lists as only supporting version 3, but might there be a chance my 
> card works with the driver as well?
>
> When the card is inserted the kernel outputs the following:
> bwi0: <Broadcom BCM4318 802.11b/g Wireless Lan> mem 
> 0xbf8a2000-0xbf8a3fff irq 16 at device 0.0 on cardbus0
> bwi0: [ITHREAD]
> bwi0: no BBP id for device id 0x4318
> device_attach: bwi0 attach returned 6
>
> Regards,
> Ralph.
> _______________________________________________
> 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 bms at FreeBSD.org  Sat Sep 12 19:48:03 2009
From: bms at FreeBSD.org (bms@FreeBSD.org)
Date: Sat Sep 12 19:48:10 2009
Subject: kern/138690: [netinet] [patch] multicast: uninited memory used
	in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP
Message-ID: <200909121948.n8CJm2LL080375@freefall.freebsd.org>

Synopsis: [netinet] [patch] multicast: uninited memory used in filter at IP_DROP_MEMBERSHIP + IP_ADD_MEMBERSHIP

State-Changed-From-To: open->patched
State-Changed-By: bms
State-Changed-When: Sat 12 Sep 2009 19:46:44 UTC
State-Changed-Why: 
An appropriate fix has been committed to HEAD as SVN rev 197132.
[There was a potential issue further up with the handling of unspecified
 source on an existing inclusive group.]


http://www.freebsd.org/cgi/query-pr.cgi?pr=138690
From dfilter at FreeBSD.ORG  Sat Sep 12 19:50:04 2009
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Sat Sep 12 19:50:11 2009
Subject: kern/138690: commit references a PR
Message-ID: <200909121950.n8CJo4bA080455@freefall.freebsd.org>

The following reply was made to PR kern/138690; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/138690: commit references a PR
Date: Sat, 12 Sep 2009 19:46:12 +0000 (UTC)

 Author: bms
 Date: Sat Sep 12 19:45:55 2009
 New Revision: 197132
 URL: http://svn.freebsd.org/changeset/base/197132
 
 Log:
   Tighten input checking in inp_join_group():
    * Don't try to use the source address, when its family is unspecified.
    * If we get a join without a source, on an existing inclusive
      mode group, this is an error, as it would change the filter mode.
   
   Fix a problem with the handling of in_mfilter for new memberships:
    * Do not rely on imf being NULL; it is explicitly initialized to a
      non-NULL pointer when constructing a membership.
    * Explicitly initialize *imf to EX mode when the source address
      is unspecified.
   
   This fixes a problem with in_mfilter slot recycling in the join path.
   
   PR:		138690
   Submitted by:	Stef Walter
   MFC after:	5 days
 
 Modified:
   head/sys/netinet/in_mcast.c
 
 Modified: head/sys/netinet/in_mcast.c
 ==============================================================================
 --- head/sys/netinet/in_mcast.c	Sat Sep 12 19:27:54 2009	(r197131)
 +++ head/sys/netinet/in_mcast.c	Sat Sep 12 19:45:55 2009	(r197132)
 @@ -1957,11 +1957,6 @@ inp_join_group(struct inpcb *inp, struct
  	if (ifp == NULL || (ifp->if_flags & IFF_MULTICAST) == 0)
  		return (EADDRNOTAVAIL);
  
 -	/*
 -	 * MCAST_JOIN_SOURCE on an exclusive membership is an error.
 -	 * On an existing inclusive membership, it just adds the
 -	 * source to the filter list.
 -	 */
  	imo = inp_findmoptions(inp);
  	idx = imo_match_group(imo, ifp, &gsa->sa);
  	if (idx == -1) {
 @@ -1969,15 +1964,33 @@ inp_join_group(struct inpcb *inp, struct
  	} else {
  		inm = imo->imo_membership[idx];
  		imf = &imo->imo_mfilters[idx];
 -		if (ssa->ss.ss_family != AF_UNSPEC &&
 -		    imf->imf_st[1] != MCAST_INCLUDE) {
 -			error = EINVAL;
 -			goto out_inp_locked;
 -		}
 -		lims = imo_match_source(imo, idx, &ssa->sa);
 -		if (lims != NULL) {
 -			error = EADDRNOTAVAIL;
 -			goto out_inp_locked;
 +		if (ssa->ss.ss_family != AF_UNSPEC) {
 +			/*
 +			 * MCAST_JOIN_SOURCE on an exclusive membership
 +			 * is an error. On an existing inclusive membership,
 +			 * it just adds the source to the filter list.
 +			 */
 +			if (imf->imf_st[1] != MCAST_INCLUDE) {
 +				error = EINVAL;
 +				goto out_inp_locked;
 +			}
 +			/* Throw out duplicates. */
 +			lims = imo_match_source(imo, idx, &ssa->sa);
 +			if (lims != NULL) {
 +				error = EADDRNOTAVAIL;
 +				goto out_inp_locked;
 +			}
 +		} else {
 +			/*
 +			 * MCAST_JOIN_GROUP on an existing inclusive
 +			 * membership is an error; if you want to change
 +			 * filter mode, you must use the userland API
 +			 * setsourcefilter().
 +			 */
 +			if (imf->imf_st[1] == MCAST_INCLUDE) {
 +				error = EINVAL;
 +				goto out_inp_locked;
 +			}
  		}
  	}
  
 @@ -2010,7 +2023,8 @@ inp_join_group(struct inpcb *inp, struct
  	/*
  	 * Graft new source into filter list for this inpcb's
  	 * membership of the group. The in_multi may not have
 -	 * been allocated yet if this is a new membership.
 +	 * been allocated yet if this is a new membership, however,
 +	 * the in_mfilter slot will be allocated and must be initialized.
  	 */
  	if (ssa->ss.ss_family != AF_UNSPEC) {
  		/* Membership starts in IN mode */
 @@ -2027,6 +2041,12 @@ inp_join_group(struct inpcb *inp, struct
  			error = ENOMEM;
  			goto out_imo_free;
  		}
 +	} else {
 +		/* No address specified; Membership starts in EX mode */
 +		if (is_new) {
 +			CTR1(KTR_IGMPV3, "%s: new join w/o source", __func__);
 +			imf_init(imf, MCAST_UNDEFINED, MCAST_EXCLUDE);
 +		}
  	}
  
  	/*
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
From bms at FreeBSD.org  Sat Sep 12 20:18:52 2009
From: bms at FreeBSD.org (bms@FreeBSD.org)
Date: Sat Sep 12 20:18:58 2009
Subject: kern/137164: [netinet] [patch] assert panic imo_match_source()
Message-ID: <200909122018.n8CKIpqu009729@freefall.freebsd.org>

Synopsis: [netinet] [patch] assert panic imo_match_source()

State-Changed-From-To: open->patched
State-Changed-By: bms
State-Changed-When: Sat 12 Sep 2009 20:17:38 UTC
State-Changed-Why: 
Actually should be resolved by SVN rev 197132.
See SVN rev 197135 for further tightening of the logic in this case.


http://www.freebsd.org/cgi/query-pr.cgi?pr=137164
From dfilter at FreeBSD.ORG  Sat Sep 12 20:20:03 2009
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Sat Sep 12 20:20:11 2009
Subject: kern/137164: commit references a PR
Message-ID: <200909122020.n8CKK3nO009806@freefall.freebsd.org>

The following reply was made to PR kern/137164; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/137164: commit references a PR
Date: Sat, 12 Sep 2009 20:18:37 +0000 (UTC)

 Author: bms
 Date: Sat Sep 12 20:18:23 2009
 New Revision: 197135
 URL: http://svn.freebsd.org/changeset/base/197135
 
 Log:
   Don't allow joins w/o source on an existing group.
   This is almost always pilot error.
   
   We don't need to check for group filter UNDEFINED state at t1,
   because we only ever allocate filters with their groups, so we
   unconditionally reject such calls with EINVAL.
   Trying to change the active filter mode w/o going through IP_MSFILTER
   is also disallowed.
   
   Deals with the case described in PR 137164 upfront, cumulative
   with the fix in svn rev 197132 which only calls imo_match_source()
   if the source address family was not unspecified.
   
   PR:		137164
   MFC after:	5 days
 
 Modified:
   head/sys/netinet/in_mcast.c
 
 Modified: head/sys/netinet/in_mcast.c
 ==============================================================================
 --- head/sys/netinet/in_mcast.c	Sat Sep 12 20:03:45 2009	(r197134)
 +++ head/sys/netinet/in_mcast.c	Sat Sep 12 20:18:23 2009	(r197135)
 @@ -1982,15 +1982,18 @@ inp_join_group(struct inpcb *inp, struct
  			}
  		} else {
  			/*
 -			 * MCAST_JOIN_GROUP on an existing inclusive
 -			 * membership is an error; if you want to change
 -			 * filter mode, you must use the userland API
 -			 * setsourcefilter().
 +			 * MCAST_JOIN_GROUP alone, on any existing membership,
 +			 * is rejected, to stop the same inpcb tying up
 +			 * multiple refs to the in_multi.
 +			 * On an existing inclusive membership, this is also
 +			 * an error; if you want to change filter mode,
 +			 * you must use the userland API setsourcefilter().
 +			 * XXX We don't reject this for imf in UNDEFINED
 +			 * state at t1, because allocation of a filter
 +			 * is atomic with allocation of a membership.
  			 */
 -			if (imf->imf_st[1] == MCAST_INCLUDE) {
 -				error = EINVAL;
 -				goto out_inp_locked;
 -			}
 +			error = EINVAL;
 +			goto out_inp_locked;
  		}
  	}
  
 @@ -2025,6 +2028,9 @@ inp_join_group(struct inpcb *inp, struct
  	 * membership of the group. The in_multi may not have
  	 * been allocated yet if this is a new membership, however,
  	 * the in_mfilter slot will be allocated and must be initialized.
 +	 *
 +	 * Note: Grafting of exclusive mode filters doesn't happen
 +	 * in this path.
  	 */
  	if (ssa->ss.ss_family != AF_UNSPEC) {
  		/* Membership starts in IN mode */
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
From bms at incunabulum.net  Sun Sep 13 01:04:59 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Sun Sep 13 01:05:05 2009
Subject: kern/138666: [multicast] [panic] not working multicast through
 igmpproxy
In-Reply-To: <200909091921.n89JL2wr014985@freefall.freebsd.org>
References: <200909091921.n89JL2wr014985@freefall.freebsd.org>
Message-ID: <4AAC4534.9040606@incunabulum.net>

I did a quick pass over ip_mroute.c to see if I could have introduced 
any obvious errors during refactoring; didn't see anything obvious.

The backtrace which was posted points towards a trashed rte->m pointer, 
assuming it's accurate and the arguments didn't get trashed on-stack. 
The MFC lock should be held in expire_mfc(). I'll add a lock assertion 
there for now. The VIF lock shouldn't be needed in this path.
From dfilter at FreeBSD.ORG  Sun Sep 13 01:10:04 2009
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Sun Sep 13 01:10:10 2009
Subject: kern/138666: commit references a PR
Message-ID: <200909130110.n8D1A3Y5001215@freefall.freebsd.org>

The following reply was made to PR kern/138666; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/138666: commit references a PR
Date: Sun, 13 Sep 2009 01:00:39 +0000 (UTC)

 Author: bms
 Date: Sun Sep 13 01:00:24 2009
 New Revision: 197148
 URL: http://svn.freebsd.org/changeset/base/197148
 
 Log:
   In expire_mfc(), add an assert on the multicast forwarding cache mutex.
   
   PR:		138666
 
 Modified:
   head/sys/netinet/ip_mroute.c
 
 Modified: head/sys/netinet/ip_mroute.c
 ==============================================================================
 --- head/sys/netinet/ip_mroute.c	Sat Sep 12 23:01:36 2009	(r197147)
 +++ head/sys/netinet/ip_mroute.c	Sun Sep 13 01:00:24 2009	(r197148)
 @@ -1025,6 +1025,8 @@ expire_mfc(struct mfc *rt)
  {
  	struct rtdetq *rte, *nrte;
  
 +	MFC_LOCK_ASSERT();
 +
  	free_bw_list(rt->mfc_bw_meter);
  
  	TAILQ_FOREACH_SAFE(rte, &rt->mfc_stall, rte_link, nrte) {
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
From bms at incunabulum.net  Sun Sep 13 01:30:07 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Sun Sep 13 01:30:13 2009
Subject: kern/138666: [multicast] [panic] not working multicast through
 igmpproxy
Message-ID: <200909130130.n8D1U6pc021189@freefall.freebsd.org>

The following reply was made to PR kern/138666; it has been noted by GNATS.

From: Bruce Simpson <bms@incunabulum.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc: freebsd-net@FreeBSD.org
Subject: Re: kern/138666: [multicast] [panic] not working multicast through
 igmpproxy
Date: Sun, 13 Sep 2009 02:04:52 +0100

 I did a quick pass over ip_mroute.c to see if I could have introduced 
 any obvious errors during refactoring; didn't see anything obvious.
 
 The backtrace which was posted points towards a trashed rte->m pointer, 
 assuming it's accurate and the arguments didn't get trashed on-stack. 
 The MFC lock should be held in expire_mfc(). I'll add a lock assertion 
 there for now. The VIF lock shouldn't be needed in this path.
From eugen at kuzbass.ru  Sun Sep 13 04:46:24 2009
From: eugen at kuzbass.ru (Eugene Grosbein)
Date: Sun Sep 13 04:46:31 2009
Subject: host(1) coredumps
Message-ID: <20090913042742.GA32897@svzserv.kemerovo.su>

Hi!

For 8.0-BETA3:

% host -l grosbein.pp.ru. ns2.rucable.net.
; Transfer failed.
/usr/local/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:2486:
REQUIRE((((sock) != ((void *)0)) && (((const isc__magic_t *)(sock))->magic
== ((('I') << 24 | ('O') << 16 | ('i') << 8 | ('o')))))) failed.
zsh: abort (core dumped)  host -l grosbein.pp.ru. ns2.rucable.net.

Shoud I send PR?

Eugene Grosbein
From barney_cordoba at yahoo.com  Sun Sep 13 12:18:47 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Sun Sep 13 12:18:55 2009
Subject: [POLLING] strange interrupt/system load
In-Reply-To: <4AAB4D56.30207@mail.ru>
Message-ID: <651317.63257.qm@web63901.mail.re1.yahoo.com>



--- On Sat, 9/12/09, rihad <rihad@mail.ru> wrote:

> From: rihad <rihad@mail.ru>
> Subject: [POLLING] strange interrupt/system load
> To: freebsd-net@freebsd.org
> Date: Saturday, September 12, 2009, 3:27 AM
> The box experiences ~230 mbit/s
> traffic flow through it. I've doubled some sysctls after
> reading polling(4):
> kern.polling.each_burst=10 # was: 5
> kern.polling.burst_max=350 # was: 150
> 
> FreeBSD 7.2-RELEASE-p3 amd64
> HZ=1000
> 
> Now for the fun part.
> 
> With kern.polling.idle_poll = 1 top shows:
> CPU:? 0.0% user,? 0.0% nice, 26.9% system,?
> 3.1% interrupt, 70.0% idle
> ~8000 interrupts/s total according to systat -vmstat:
> 1999 cpu0: time
> 2000 cpu1: time
> 1999 cpu2: time
> 1999 cpu3: time
> 
> With kern.polling.idle_poll = 0 top shows:
> CPU:? 0.0% user,? 0.0% nice,? 0.0% system,
> 13.9% interrupt, 86.0% idle
> Still the same ~8000 clock interrupts/s.
> 
> Under both scenarios polling is enabled on both em0 and em1
> through ifconfig.
> 
> 
> 1) Why is the interrupt load relatively high with polling
> enabled?
> 2) How come 13.9% interrupts are not also in the first
> scenario if their total rate is the same (~8000)?
> 
> Thanks.

The more important questions are:

1) Why are you polling with a NIC that can be precisely set to
interrupt as often or as little as you like?
2) Why do so many people run systems with high network load with
AMD64 builds when its significantly slower to do so? Do you have
google sized databases so you need 64-bit pointers?

As to why you get interrupt load, how do you think that polling is 
implemented? By Magic? You are merely shifting the interrupt load
from the em driver to the software interrupts. Running em drivers
with AIM is essentially the same as polling without the associated
system overhead that polling introduces.

Barney


      

From barney_cordoba at yahoo.com  Sun Sep 13 12:30:25 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Sun Sep 13 12:30:31 2009
Subject: em driver input errors
In-Reply-To: <2a41acea0909110938l2348e35ah11bd1876fbe22dd3@mail.gmail.com>
Message-ID: <116612.47408.qm@web63908.mail.re1.yahoo.com>



--- On Fri, 9/11/09, Jack Vogel <jfvogel@gmail.com> wrote:

> From: Jack Vogel <jfvogel@gmail.com>
> Subject: Re: em driver input errors
> To: "Mike Tancsa" <mike@sentex.net>
> Cc: "Barney Cordoba" <barney_cordoba@yahoo.com>, freebsd-net@freebsd.org
> Date: Friday, September 11, 2009, 12:38 PM
> Glad to hear this.
> 
> Jack
> 
> 
> On Fri, Sep 11, 2009 at 4:46 AM,
> Mike Tancsa <mike@sentex.net>
> wrote:
> 
> At 11:28 AM 9/9/2009, Mike Tancsa wrote:
> 
> 
> At 11:17 AM 9/9/2009, Mike Tancsa wrote:
> 
> 
> The board is an intel
> 
> 
> 
> http://www.intel.com/support/motherboards/server/s3000ah/
> 
> 
> 
> Not sure if its wired as PCI-X or just a 32bit bus. ?I am
> just popping in an em pcie nic to see if that makes a
> difference. ?I have an igb as well as bge I can try later.
> 
> 
> 
> 
> OK, now there is
> 
> 
> 
> em0@pci0:5:0:0: class=0x020000 card=0xa01f8086
> chip=0x10d38086 rev=0x00 hdr=0x00
> 
>  ? ?vendor ? ? = 'Intel Corporation'
> 
>  ? ?class ? ? ?= network
> 
>  ? ?subclass ? = ethernet
> 
>  ? ?cap 01[c8] = powerspec 2 ?supports D0 D3 ?current
> D0
> 
>  ? ?cap 05[d0] = MSI supports 1 message, 64 bit
> 
>  ? ?cap 10[e0] = PCI-Express 1 endpoint max data 128(256)
> link x1(x1)
> 
>  ? ?cap 11[a0] = MSI-X supports 5 messages in map 0x1c
> enabled
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> OK, much better. ?Two nights in a row without errors, and
> Friday AM has a lot of level0 dumps. ?Perhaps as you
> speculated, the onboard NICs were wired to a slower bus...
> ?The pcie 1x hasnt shown any errors yet.
> 
> 
> 
> Sep 11 00:01:00 backup3 kernel: em0: Excessive collisions =
> 0
> 
> Sep 11 00:01:00 backup3 kernel: em0: Sequence errors = 0
> 
> Sep 11 00:01:00 backup3 kernel: em0: Defer count = 0
> 
> Sep 11 00:01:00 backup3 kernel: em0: Missed Packets = 0
> 
> Sep 11 00:01:00 backup3 kernel: em0: Receive No Buffers =
> 0
> 
> Sep 11 00:01:00 backup3 kernel: em0: Receive Length Errors
> = 0
> 
> Sep 11 00:01:00 backup3 kernel: em0: Receive errors = 0
> 
> Sep 11 00:01:00 backup3 kernel: em0: Crc errors = 0
> 
> Sep 11 00:01:00 backup3 kernel: em0: Alignment errors = 0
> 
> Sep 11 00:01:00 backup3 kernel: em0: Collision/Carrier
> extension errors = 0
> 
> Sep 11 00:01:00 backup3 kernel: em0: RX overruns = 0
> 
> Sep 11 00:01:00 backup3 kernel: em0: watchdog timeouts = 0
> 
> Sep 11 00:01:00 backup3 kernel: em0: RX MSIX IRQ = 50004846
> TX MSIX IRQ = 40678847 LINK MSIX IRQ = 1
> 
> Sep 11 00:01:00 backup3 kernel: em0: XON Rcvd = 0
> 
> Sep 11 00:01:00 backup3 kernel: em0: XON Xmtd = 0
> 
> Sep 11 00:01:00 backup3 kernel: em0: XOFF Rcvd = 0
> 
> Sep 11 00:01:00 backup3 kernel: em0: XOFF Xmtd = 0
> 
> Sep 11 00:01:00 backup3 kernel: em0: Good Packets Rcvd =
> 73064815
> 
> Sep 11 00:01:00 backup3 kernel: em0: Good Packets Xmtd =
> 52479296
> 
> Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts Xmtd = 0
> 
> Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts Failed =
> 0
> 
> 
> 
> 
> 
> Name ? ?Mtu Network ? ? ? Address ? ? ? ? ? ?
> ?Ipkts Ierrs ? ?Opkts Oerrs ?Coll
> 
> em0 ? ?1500 <Link#1> ? ? ?00:1b:21:3f:62:72
> 193269942 ? ? 0 133269168 ? ? 0 ? ? 0
> 
> em0 ? ?1500 10.45.129.132 10.45.129.133 ? ? ? ? ?
> ?0 ? ? - ? ? ? ?0 ? ? - ? ? -
> 
> em1 ? ?1500 <Link#2> ? ? ?00:15:17:57:31:8a ?
> ? ? ?0 ? ? 0 ? ? ? ?0 ? ? 0 ? ? 0
> 
> em1 ? ?1500 10.45.129.128 10.45.129.129 ? ? ? ? ?
> ?0 ? ? - ? ? ? ?0 ? ? - ? ? -
> 
> em2* ? 1500 <Link#3> ? ? ?00:15:17:57:31:8b ? ?
> ? ?0 ? ? 0 ? ? ? ?0 ? ? 0 ? ?
> 0
> 
> 
> 
>  ? ? ? ?---Mike
> 

Intel really shouldn't let MB manufacturers market dual gigabit 
systems with 32bit controllers. The NICs aren't intended to be
used that way, and it makes them look bad, when its really the fault
of the MB manufacturer for cheaping out on the design.

Barney


      

From barney_cordoba at yahoo.com  Sun Sep 13 12:40:31 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Sun Sep 13 12:40:38 2009
Subject: em driver input errors
In-Reply-To: <116612.47408.qm@web63908.mail.re1.yahoo.com>
Message-ID: <132674.73051.qm@web63901.mail.re1.yahoo.com>



--- On Sun, 9/13/09, Barney Cordoba <barney_cordoba@yahoo.com> wrote:

> From: Barney Cordoba <barney_cordoba@yahoo.com>
> Subject: Re: em driver input errors
> To: "Mike Tancsa" <mike@sentex.net>, "Jack Vogel" <jfvogel@gmail.com>
> Cc: freebsd-net@freebsd.org
> Date: Sunday, September 13, 2009, 8:30 AM
> 
> 
> --- On Fri, 9/11/09, Jack Vogel <jfvogel@gmail.com>
> wrote:
> 
> > From: Jack Vogel <jfvogel@gmail.com>
> > Subject: Re: em driver input errors
> > To: "Mike Tancsa" <mike@sentex.net>
> > Cc: "Barney Cordoba" <barney_cordoba@yahoo.com>,
> freebsd-net@freebsd.org
> > Date: Friday, September 11, 2009, 12:38 PM
> > Glad to hear this.
> > 
> > Jack
> > 
> > 
> > On Fri, Sep 11, 2009 at 4:46 AM,
> > Mike Tancsa <mike@sentex.net>
> > wrote:
> > 
> > At 11:28 AM 9/9/2009, Mike Tancsa wrote:
> > 
> > 
> > At 11:17 AM 9/9/2009, Mike Tancsa wrote:
> > 
> > 
> > The board is an intel
> > 
> > 
> > 
> > http://www.intel.com/support/motherboards/server/s3000ah/
> > 
> > 
> > 
> > Not sure if its wired as PCI-X or just a 32bit bus.
> ?I am
> > just popping in an em pcie nic to see if that makes a
> > difference. ?I have an igb as well as bge I can try
> later.
> > 
> > 
> > 
> > 
> > OK, now there is
> > 
> > 
> > 
> > em0@pci0:5:0:0: class=0x020000 card=0xa01f8086
> > chip=0x10d38086 rev=0x00 hdr=0x00
> > 
> >? ? ?vendor ? ? = 'Intel Corporation'
> > 
> >? ? ?class ? ? ?= network
> > 
> >? ? ?subclass ? = ethernet
> > 
> >? ? ?cap 01[c8] = powerspec 2 ?supports D0 D3
> ?current
> > D0
> > 
> >? ? ?cap 05[d0] = MSI supports 1 message, 64
> bit
> > 
> >? ? ?cap 10[e0] = PCI-Express 1 endpoint max
> data 128(256)
> > link x1(x1)
> > 
> >? ? ?cap 11[a0] = MSI-X supports 5 messages in
> map 0x1c
> > enabled
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > OK, much better. ?Two nights in a row without errors,
> and
> > Friday AM has a lot of level0 dumps. ?Perhaps as you
> > speculated, the onboard NICs were wired to a slower
> bus...
> > ?The pcie 1x hasnt shown any errors yet.
> > 
> > 
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: Excessive
> collisions =
> > 0
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: Sequence errors =
> 0
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: Defer count = 0
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: Missed Packets =
> 0
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: Receive No
> Buffers =
> > 0
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: Receive Length
> Errors
> > = 0
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: Receive errors =
> 0
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: Crc errors = 0
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: Alignment errors
> = 0
> > 
> > Sep 11 00:01:00 backup3 kernel: em0:
> Collision/Carrier
> > extension errors = 0
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: RX overruns = 0
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: watchdog timeouts
> = 0
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: RX MSIX IRQ =
> 50004846
> > TX MSIX IRQ = 40678847 LINK MSIX IRQ = 1
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: XON Rcvd = 0
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: XON Xmtd = 0
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: XOFF Rcvd = 0
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: XOFF Xmtd = 0
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: Good Packets Rcvd
> =
> > 73064815
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: Good Packets Xmtd
> =
> > 52479296
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts Xmtd
> = 0
> > 
> > Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts
> Failed =
> > 0
> > 
> > 
> > 
> > 
> > 
> > Name ? ?Mtu Network ? ? ? Address ? ? ? ? ?
> ?
> > ?Ipkts Ierrs ? ?Opkts Oerrs ?Coll
> > 
> > em0 ? ?1500 <Link#1> ? ?
> ?00:1b:21:3f:62:72
> > 193269942 ? ? 0 133269168 ? ? 0 ? ? 0
> > 
> > em0 ? ?1500 10.45.129.132 10.45.129.133 ? ? ? ?
> ?
> > ?0 ? ? - ? ? ? ?0 ? ? - ? ? -
> > 
> > em1 ? ?1500 <Link#2> ? ? ?00:15:17:57:31:8a
> ?
> > ? ? ?0 ? ? 0 ? ? ? ?0 ? ? 0 ? ? 0
> > 
> > em1 ? ?1500 10.45.129.128 10.45.129.129 ? ? ? ?
> ?
> > ?0 ? ? - ? ? ? ?0 ? ? - ? ? -
> > 
> > em2* ? 1500 <Link#3> ? ? ?00:15:17:57:31:8b
> ? ?
> > ? ?0 ? ? 0 ? ? ? ?0 ? ? 0 ? ?
> > 0
> > 
> > 
> > 
> >? ? ? ? ?---Mike
> > 
> 
> Intel really shouldn't let MB manufacturers market dual
> gigabit 
> systems with 32bit controllers. The NICs aren't intended to
> be
> used that way, and it makes them look bad, when its really
> the fault
> of the MB manufacturer for cheaping out on the design.
> 
> Barney
> 

I take that back. I see now that Intel is the MB manufacturer, 
which is really outrageous and irresponsible. Jack, feel free to
pass that on.

Barney


      

From barney_cordoba at yahoo.com  Sun Sep 13 13:01:26 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Sun Sep 13 13:03:00 2009
Subject: em driver input errors
In-Reply-To: <132674.73051.qm@web63901.mail.re1.yahoo.com>
Message-ID: <883232.31223.qm@web63902.mail.re1.yahoo.com>



--- On Sun, 9/13/09, Barney Cordoba <barney_cordoba@yahoo.com> wrote:

> From: Barney Cordoba <barney_cordoba@yahoo.com>
> Subject: Re: em driver input errors
> To: "Mike Tancsa" <mike@sentex.net>, "Jack Vogel" <jfvogel@gmail.com>
> Cc: freebsd-net@freebsd.org
> Date: Sunday, September 13, 2009, 8:40 AM
> 
> 
> --- On Sun, 9/13/09, Barney Cordoba <barney_cordoba@yahoo.com>
> wrote:
> 
> > From: Barney Cordoba <barney_cordoba@yahoo.com>
> > Subject: Re: em driver input errors
> > To: "Mike Tancsa" <mike@sentex.net>,
> "Jack Vogel" <jfvogel@gmail.com>
> > Cc: freebsd-net@freebsd.org
> > Date: Sunday, September 13, 2009, 8:30 AM
> > 
> > 
> > --- On Fri, 9/11/09, Jack Vogel <jfvogel@gmail.com>
> > wrote:
> > 
> > > From: Jack Vogel <jfvogel@gmail.com>
> > > Subject: Re: em driver input errors
> > > To: "Mike Tancsa" <mike@sentex.net>
> > > Cc: "Barney Cordoba" <barney_cordoba@yahoo.com>,
> > freebsd-net@freebsd.org
> > > Date: Friday, September 11, 2009, 12:38 PM
> > > Glad to hear this.
> > > 
> > > Jack
> > > 
> > > 
> > > On Fri, Sep 11, 2009 at 4:46 AM,
> > > Mike Tancsa <mike@sentex.net>
> > > wrote:
> > > 
> > > At 11:28 AM 9/9/2009, Mike Tancsa wrote:
> > > 
> > > 
> > > At 11:17 AM 9/9/2009, Mike Tancsa wrote:
> > > 
> > > 
> > > The board is an intel
> > > 
> > > 
> > > 
> > > http://www.intel..com/support/motherboards/server/s3000ah/
> > > 
> > > 
> > > 
> > > Not sure if its wired as PCI-X or just a 32bit
> bus.
> > ?I am
> > > just popping in an em pcie nic to see if that
> makes a
> > > difference. ?I have an igb as well as bge I can
> try
> > later.
> > > 
> > > 
> > > 
> > > 
> > > OK, now there is
> > > 
> > > 
> > > 
> > > em0@pci0:5:0:0: class=0x020000 card=0xa01f8086
> > > chip=0x10d38086 rev=0x00 hdr=0x00
> > > 
> > >? ? ?vendor ? ? = 'Intel Corporation'
> > > 
> > >? ? ?class ? ? ?= network
> > > 
> > >? ? ?subclass ? = ethernet
> > > 
> > >? ? ?cap 01[c8] = powerspec 2 ?supports D0 D3
> > ?current
> > > D0
> > > 
> > >? ? ?cap 05[d0] = MSI supports 1 message, 64
> > bit
> > > 
> > >? ? ?cap 10[e0] = PCI-Express 1 endpoint max
> > data 128(256)
> > > link x1(x1)
> > > 
> > >? ? ?cap 11[a0] = MSI-X supports 5 messages in
> > map 0x1c
> > > enabled
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > OK, much better. ?Two nights in a row without
> errors,
> > and
> > > Friday AM has a lot of level0 dumps. ?Perhaps as
> you
> > > speculated, the onboard NICs were wired to a
> slower
> > bus...
> > > ?The pcie 1x hasnt shown any errors yet.
> > > 
> > > 
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: Excessive
> > collisions =
> > > 0
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: Sequence
> errors =
> > 0
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: Defer count
> = 0
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: Missed
> Packets =
> > 0
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: Receive No
> > Buffers =
> > > 0
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: Receive
> Length
> > Errors
> > > = 0
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: Receive
> errors =
> > 0
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: Crc errors =
> 0
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: Alignment
> errors
> > = 0
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0:
> > Collision/Carrier
> > > extension errors = 0
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: RX overruns
> = 0
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: watchdog
> timeouts
> > = 0
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: RX MSIX IRQ
> =
> > 50004846
> > > TX MSIX IRQ = 40678847 LINK MSIX IRQ = 1
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: XON Rcvd =
> 0
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: XON Xmtd =
> 0
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: XOFF Rcvd =
> 0
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: XOFF Xmtd =
> 0
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: Good Packets
> Rcvd
> > =
> > > 73064815
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: Good Packets
> Xmtd
> > =
> > > 52479296
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: TSO Contexts
> Xmtd
> > = 0
> > > 
> > > Sep 11 00:01:00 backup3 kernel: em0: TSO
> Contexts
> > Failed =
> > > 0
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Name ? ?Mtu Network ? ? ? Address ? ? ?
> ? ?
> > ?
> > > ?Ipkts Ierrs ? ?Opkts Oerrs ?Coll
> > > 
> > > em0 ? ?1500 <Link#1> ? ?
> > ?00:1b:21:3f:62:72
> > > 193269942 ? ? 0 133269168 ? ? 0 ? ? 0
> > > 
> > > em0 ? ?1500 10.45.129.132 10.45.129.133 ? ?
> ? ?
> > ?
> > > ?0 ? ? - ? ? ? ?0 ? ? - ? ? -
> > > 
> > > em1 ? ?1500 <Link#2> ? ?
> ?00:15:17:57:31:8a
> > ?
> > > ? ? ?0 ? ? 0 ? ? ? ?0 ? ? 0 ? ? 0
> > > 
> > > em1 ? ?1500 10.45.129.128 10.45.129.129 ? ?
> ? ?
> > ?
> > > ?0 ? ? - ? ? ? ?0 ? ? - ? ? -
> > > 
> > > em2* ? 1500 <Link#3> ? ?
> ?00:15:17:57:31:8b
> > ? ?
> > > ? ?0 ? ? 0 ? ? ? ?0 ? ? 0 ? ?
> > > 0
> > > 
> > > 
> > > 
> > >? ? ? ? ?---Mike
> > > 
> > 
> > Intel really shouldn't let MB manufacturers market
> dual
> > gigabit 
> > systems with 32bit controllers. The NICs aren't
> intended to
> > be
> > used that way, and it makes them look bad, when its
> really
> > the fault
> > of the MB manufacturer for cheaping out on the
> design.
> > 
> > Barney
> > 
> 
> I take that back. I see now that Intel is the MB
> manufacturer, 
> which is really outrageous and irresponsible. Jack, feel
> free to
> pass that on.
> 
> Barney
> 

Ok, I spoke too soon. In reviewing the spec, the main controller is 
pciE, and the second controller clearly isn't designed to be used as
a loaded port. Im not quite sure why the 2nd nic is on there. This
MB seems more like a science project with both pciE and pciX controllers
on it. But the spec clearly says that the PCIx bus is 32big/33Mhz, so
there's really no excuse for not knowing.

Barney


      

From rihad at mail.ru  Sun Sep 13 13:12:01 2009
From: rihad at mail.ru (rihad)
Date: Sun Sep 13 13:12:08 2009
Subject: [POLLING] strange interrupt/system load
In-Reply-To: <651317.63257.qm@web63901.mail.re1.yahoo.com>
References: <651317.63257.qm@web63901.mail.re1.yahoo.com>
Message-ID: <4AACEF9E.90303@mail.ru>

Barney Cordoba wrote:

> 1) Why are you polling with a NIC that can be precisely set to
> interrupt as often or as little as you like?
How?

> 2) Why do so many people run systems with high network load with
> AMD64 builds when its significantly slower to do so? Do you have
> google sized databases so you need 64-bit pointers?
What's wrong with 64 bits?

From barney_cordoba at yahoo.com  Sun Sep 13 14:32:18 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Sun Sep 13 14:32:25 2009
Subject: [POLLING] strange interrupt/system load
In-Reply-To: <4AACEF9E.90303@mail.ru>
Message-ID: <94372.57247.qm@web63906.mail.re1.yahoo.com>



--- On Sun, 9/13/09, rihad <rihad@mail.ru> wrote:

> From: rihad <rihad@mail.ru>
> Subject: Re: [POLLING] strange interrupt/system load
> To: "Barney Cordoba" <barney_cordoba@yahoo.com>
> Cc: freebsd-net@freebsd.org
> Date: Sunday, September 13, 2009, 9:11 AM
> Barney Cordoba wrote:
> 
> > 1) Why are you polling with a NIC that can be
> precisely set to
> > interrupt as often or as little as you like?
> How?
> 
> > 2) Why do so many people run systems with high network
> load with
> > AMD64 builds when its significantly slower to do so?
> Do you have
> > google sized databases so you need 64-bit pointers?
> What's wrong with 64 bits?

I haven't spent a large portion of my life trying to figure
it out exactly, but I'd guess that the larger size of the 
structures and code results in fewer cache hits. It certainly 
makes sense to try both with your workload, as the notion that 
64bits must be faster than 32bits is patently misguided. My rule of 
thumb is that if I don't need 64bits for something, I avoid it.

Barney

 


      

From rihad at mail.ru  Sun Sep 13 14:33:11 2009
From: rihad at mail.ru (rihad)
Date: Sun Sep 13 14:33:18 2009
Subject: [POLLING] strange interrupt/system load
In-Reply-To: <94372.57247.qm@web63906.mail.re1.yahoo.com>
References: <94372.57247.qm@web63906.mail.re1.yahoo.com>
Message-ID: <4AAD02A2.5060207@mail.ru>

Barney Cordoba wrote:
> 
> --- On Sun, 9/13/09, rihad <rihad@mail.ru> wrote:
>> What's wrong with 64 bits?
> 
> I haven't spent a large portion of my life trying to figure
> it out exactly, but I'd guess that the larger size of the 
> structures and code results in fewer cache hits.

Then what's wrong with also doubling cache sizes?
Besides, apart from other benefits, 64-bit makes every-day big number 
arithmetic a single CPU instruction as opposed to several instructions 
required on 32-bit CPUs through bignum emulation.
From ertr1013 at student.uu.se  Sun Sep 13 15:41:48 2009
From: ertr1013 at student.uu.se (Erik Trulsson)
Date: Sun Sep 13 15:41:54 2009
Subject: [POLLING] strange interrupt/system load
In-Reply-To: <4AAD02A2.5060207@mail.ru>
References: <94372.57247.qm@web63906.mail.re1.yahoo.com>
	<4AAD02A2.5060207@mail.ru>
Message-ID: <20090913152618.GA1618@owl.midgard.homeip.net>

On Sun, Sep 13, 2009 at 07:33:06PM +0500, rihad wrote:
> Barney Cordoba wrote:
> > 
> > --- On Sun, 9/13/09, rihad <rihad@mail.ru> wrote:
> >> What's wrong with 64 bits?
> > 
> > I haven't spent a large portion of my life trying to figure
> > it out exactly, but I'd guess that the larger size of the 
> > structures and code results in fewer cache hits.
> 
> Then what's wrong with also doubling cache sizes?

Increasing the size of the CPU cache not only makes it more expensive to
manufacture, but also makes it slightly slower to access.

> Besides, apart from other benefits, 64-bit makes every-day big number 
> arithmetic a single CPU instruction as opposed to several instructions 
> required on 32-bit CPUs through bignum emulation.

True, and if you need to perform a lot of 64-bit arithmetic then the extra
register width can indeed be a major win.
Most people, on most systems, have very limited need of 64-bit arithmetic.



-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
From volker at vwsoft.com  Sun Sep 13 15:59:04 2009
From: volker at vwsoft.com (volker@vwsoft.com)
Date: Sun Sep 13 15:59:11 2009
Subject: host(1) coredumps
In-Reply-To: <20090913042742.GA32897@svzserv.kemerovo.su>
References: <20090913042742.GA32897@svzserv.kemerovo.su>
Message-ID: <4AAD12BE.1090600@vwsoft.com>

On 09/13/09 06:27, Eugene Grosbein wrote:
> Hi!
> 
> For 8.0-BETA3:
> 
> % host -l grosbein.pp.ru. ns2.rucable.net.
> ; Transfer failed.
> /usr/local/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:2486:
> REQUIRE((((sock) != ((void *)0)) && (((const isc__magic_t *)(sock))->magic
> == ((('I') << 24 | ('O') << 16 | ('i') << 8 | ('o')))))) failed.
> zsh: abort (core dumped)  host -l grosbein.pp.ru. ns2.rucable.net.
> 
> Shoud I send PR?
> 
> Eugene Grosbein

Eugene,

the attached patch works around the error for me. As this is contributed
code, it should be fixed upstream (no need to file a PR).

Volker

-------------- next part --------------
--- contrib/bind9/bin/dig/dighost.c.orig	2009-09-13 14:24:13.000000000 +0000
+++ contrib/bind9/bin/dig/dighost.c	2009-09-13 14:31:52.000000000 +0000
@@ -2604,11 +2604,13 @@
 
 	if (sevent->result == ISC_R_CANCELED) {
 		debug("in cancel handler");
-		isc_socket_detach(&query->sock);
-		sockcount--;
-		INSIST(sockcount >= 0);
-		debug("sockcount=%d", sockcount);
-		query->waiting_connect = ISC_FALSE;
+		if (query->sock != NULL) {
+			isc_socket_detach(&query->sock);
+			sockcount--;
+			INSIST(sockcount >= 0);
+			debug("sockcount=%d", sockcount);
+			query->waiting_connect = ISC_FALSE;
+		}
 		isc_event_free(&event);
 		l = query->lookup;
 		clear_query(query);
From eugen at kuzbass.ru  Sun Sep 13 17:16:46 2009
From: eugen at kuzbass.ru (Eugene Grosbein)
Date: Sun Sep 13 17:16:53 2009
Subject: host(1) coredumps
In-Reply-To: <4AAD12BE.1090600@vwsoft.com>
References: <20090913042742.GA32897@svzserv.kemerovo.su>
	<4AAD12BE.1090600@vwsoft.com>
Message-ID: <20090913171643.GA69039@svzserv.kemerovo.su>

On Sun, Sep 13, 2009 at 05:41:50PM +0200, volker@vwsoft.com wrote:

> > % host -l grosbein.pp.ru. ns2.rucable.net.
> > ; Transfer failed.
> > /usr/local/src/lib/bind/isc/../../../contrib/bind9/lib/isc/unix/socket.c:2486:
> > REQUIRE((((sock) != ((void *)0)) && (((const isc__magic_t *)(sock))->magic
> > == ((('I') << 24 | ('O') << 16 | ('i') << 8 | ('o')))))) failed.
> > zsh: abort (core dumped)  host -l grosbein.pp.ru. ns2.rucable.net.
> > 
> > Shoud I send PR?

> Eugene,
> 
> the attached patch works around the error for me. As this is contributed
> code, it should be fixed upstream (no need to file a PR).
> 
> Volker
> 

> --- contrib/bind9/bin/dig/dighost.c.orig	2009-09-13 14:24:13.000000000 +0000
> +++ contrib/bind9/bin/dig/dighost.c	2009-09-13 14:31:52.000000000 +0000

Indeed, the patch helps. Thank you.

Eugene
From gavin at FreeBSD.org  Sun Sep 13 20:45:55 2009
From: gavin at FreeBSD.org (gavin@FreeBSD.org)
Date: Sun Sep 13 20:46:07 2009
Subject: kern/138782: [panic] sbflush_internal: cc 0 || mb
	0xffffff004127b000 || mbcnt 2304
Message-ID: <200909132045.n8DKjt9i076487@freefall.freebsd.org>

Old Synopsis: [panic] sbflush_internal
New Synopsis: [panic] sbflush_internal: cc 0 || mb 0xffffff004127b000 || mbcnt 2304

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: gavin
Responsible-Changed-When: Sun Sep 13 20:41:07 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).  Not sure if there's enough info here at the
moment, but the submitter has a core.

To submitter: Can you run crashinfo(8) on the kernel core file and
provide the complete output please?

http://www.freebsd.org/cgi/query-pr.cgi?pr=138782
From rihad at mail.ru  Mon Sep 14 07:38:04 2009
From: rihad at mail.ru (rihad)
Date: Mon Sep 14 07:38:11 2009
Subject: [POLLING] strange interrupt/system load
In-Reply-To: <20090912202529.X1569@besplex.bde.org>
References: <4AAB4D56.30207@mail.ru> <20090912202529.X1569@besplex.bde.org>
Message-ID: <4AADF2D8.5050505@mail.ru>

Bruce Evans wrote:
> On Sat, 12 Sep 2009, rihad wrote:
> 
>> The box experiences ~230 mbit/s traffic flow through it. I've doubled 
>> some sysctls after reading polling(4):
>> kern.polling.each_burst=10 # was: 5
>> kern.polling.burst_max=350 # was: 150
>>
>> FreeBSD 7.2-RELEASE-p3 amd64
>> HZ=1000
> 
> How much better does it work without POLLING?
> 
Without polling (current load around 190-200 mbit/s, around 24-26 kpps):

top:
CPU:  0.0% user,  0.0% nice,  8.4% system,  0.0% interrupt, 91.6% idle

Interrupts/s: 18322 total
28 mpt0 irq16
1999 cpu0: time
6906 em0 irq256
3392 em1 irq257
1999 cpu1: time
1999 cpu2: time
1999 cpu3: time
From andrew at modulus.org  Mon Sep 14 07:42:19 2009
From: andrew at modulus.org (Andrew Snow)
Date: Mon Sep 14 07:42:26 2009
Subject: Intel Dual port pro/1000: watchdog timeouts and no packets received
Message-ID: <4AADF381.8090000@modulus.org>


This is a very new card which I haven't seen before on the market until 
recently.

Card: E1G42ET (Intel Gigabit PCIe ET Dual Port  Adapter 82576)
Server: Supermicro X7SLA-H
Operating system:  FreeBSD 7.2-RELEASE and 7.2-STABLE
IGB Drivers: 1.4.1 and updated 1.7.3 from intel website



igb0: <Intel(R) PRO/1000 Network Connection version - 1.7.3> port 
0xcc00-0xcc1f mem 
0xfe9e0000-0xfe9fffff,0xfe400000-0xfe7fffff,0xfe9dc000-0xfe9dffff irq 10 
at device 0.0 on pci1
igb0: Using MSIX interrupts with 0 vectors
igb0: [FILTER]
igb0: Ethernet address: 00:1b:21:43:2f:a0

igb1: <Intel(R) PRO/1000 Network Connection version - 1.7.3> port 
0xc880-0xc89f mem 
0xfe9a0000-0xfe9bffff,0xfdc00000-0xfdffffff,0xfe9d8000-0xfe9dbfff irq 11 
at device 0.1 on pci1
igb1: Using MSIX interrupts with 0 vectors
igb1: [FILTER]
igb1: Ethernet address: 00:1b:21:43:2f:a1

igb0@pci0:1:0:0:        class=0x020000 card=0xa03c8086 chip=0x10c98086 
rev=0x01 hdr=0x00
     vendor     = 'Intel Corporation'
     class      = network
     subclass   = ethernet

igb1@pci0:1:0:1:        class=0x020000 card=0xa03c8086 chip=0x10c98086 
rev=0x01 hdr=0x00
     vendor     = 'Intel Corporation'
     class      = network
     subclass   = ethernet

Card detects OK but when you assign an IP and try to ping, no packets 
are received, not even ARP replies.

This appears on the console:

igb0: watchdog timeout -- resetting
igb0: Queue(0) tdh = 9, tdt = 9
igb0: Queue(0) desc avail = 247, Next Desc to Clean = 0
igb0: link state changed to DOWN
igb0: link state changed to UP



Thanks,

- Andrew
From barney_cordoba at yahoo.com  Mon Sep 14 08:39:35 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Mon Sep 14 08:39:47 2009
Subject: [POLLING] strange interrupt/system load
In-Reply-To: <4AACEF9E.90303@mail.ru>
Message-ID: <604691.33140.qm@web63905.mail.re1.yahoo.com>



--- On Sun, 9/13/09, rihad <rihad@mail.ru> wrote:

> From: rihad <rihad@mail.ru>
> Subject: Re: [POLLING] strange interrupt/system load
> To: "Barney Cordoba" <barney_cordoba@yahoo.com>
> Cc: freebsd-net@freebsd.org
> Date: Sunday, September 13, 2009, 9:11 AM
> Barney Cordoba wrote:
> 
> > 1) Why are you polling with a NIC that can be
> precisely set to
> > interrupt as often or as little as you like?
> How?
> 
> > 2) Why do so many people run systems with high network
> load with
> > AMD64 builds when its significantly slower to do so?
> Do you have
> > google sized databases so you need 64-bit pointers?
> What's wrong with 64 bits?

Suit yourself, but the empirical evidence suggests otherwise.

Barney


      

From barney_cordoba at yahoo.com  Mon Sep 14 08:58:41 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Mon Sep 14 08:58:48 2009
Subject: [POLLING] strange interrupt/system load
In-Reply-To: <4AADF2D8.5050505@mail.ru>
Message-ID: <676338.40771.qm@web63905.mail.re1.yahoo.com>



--- On Mon, 9/14/09, rihad <rihad@mail.ru> wrote:

> From: rihad <rihad@mail.ru>
> Subject: Re: [POLLING] strange interrupt/system load
> To: "Bruce Evans" <brde@optusnet.com.au>
> Cc: freebsd-net@FreeBSD.org
> Date: Monday, September 14, 2009, 3:38 AM
> Bruce Evans wrote:
> > On Sat, 12 Sep 2009, rihad wrote:
> > 
> >> The box experiences ~230 mbit/s traffic flow
> through it. I've doubled some sysctls after reading
> polling(4):
> >> kern.polling.each_burst=10 # was: 5
> >> kern.polling.burst_max=350 # was: 150
> >> 
> >> FreeBSD 7.2-RELEASE-p3 amd64
> >> HZ=1000
> > 
> > How much better does it work without POLLING?
> > 
> Without polling (current load around 190-200 mbit/s, around
> 24-26 kpps):
> 
> top:
> CPU:? 0.0% user,? 0.0% nice,? 8.4%
> system,? 0.0% interrupt, 91.6% idle
> 
> Interrupts/s: 18322 total
> 28 mpt0 irq16
> 1999 cpu0: time
> 6906 em0 irq256
> 3392 em1 irq257
> 1999 cpu1: time
> 1999 cpu2: time
> 1999 cpu3: time

You really need to look at the taskq usage as averaging on a 4 core
system muddies things up. em will generally run on 1 core per NIC, and
interrupts are filtered so you won't see any interrupt usage. On a 
4 core system you could exhaust a core and still be at 25% overall, so 
you need to watch the max usage per core.

Things aren't measured properly in polling mode so its difficult to
compare them one to one. You really don't need to; intuitively it makes
zero sense to use polling with em.

You'll do a lot better setting your ITR to 2000 or so. You really don't
need an interrupt every 4 packets at those traffic levels.

Barney


      

From barney_cordoba at yahoo.com  Mon Sep 14 09:10:46 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Mon Sep 14 09:10:52 2009
Subject: Intel Dual port pro/1000: watchdog timeouts and no packets
	received
In-Reply-To: <4AADF381.8090000@modulus.org>
Message-ID: <8835.46679.qm@web63905.mail.re1.yahoo.com>



--- On Mon, 9/14/09, Andrew Snow <andrew@modulus.org> wrote:

> From: Andrew Snow <andrew@modulus.org>
> Subject: Intel Dual port pro/1000: watchdog timeouts and no packets received
> To: "FreeBSD Net" <freebsd-net@freebsd.org>
> Cc: "Jack Vogel" <jfvogel@gmail.com>
> Date: Monday, September 14, 2009, 3:40 AM
> 
> This is a very new card which I haven't seen before on the
> market until recently.
> 
> Card: E1G42ET (Intel Gigabit PCIe ET Dual Port?
> Adapter 82576)
> Server: Supermicro X7SLA-H
> Operating system:? FreeBSD 7.2-RELEASE and 7.2-STABLE
> IGB Drivers: 1.4.1 and updated 1.7.3 from intel website
> 
> 
> 
> igb0: <Intel(R) PRO/1000 Network Connection version -
> 1.7.3> port 0xcc00-0xcc1f mem
> 0xfe9e0000-0xfe9fffff,0xfe400000-0xfe7fffff,0xfe9dc000-0xfe9dffff
> irq 10 at device 0.0 on pci1
> igb0: Using MSIX interrupts with 0 vectors
> igb0: [FILTER]
> igb0: Ethernet address: 00:1b:21:43:2f:a0
> 
> igb1: <Intel(R) PRO/1000 Network Connection version -
> 1.7.3> port 0xc880-0xc89f mem
> 0xfe9a0000-0xfe9bffff,0xfdc00000-0xfdffffff,0xfe9d8000-0xfe9dbfff
> irq 11 at device 0.1 on pci1
> igb1: Using MSIX interrupts with 0 vectors
> igb1: [FILTER]
> igb1: Ethernet address: 00:1b:21:43:2f:a1
> 
> igb0@pci0:1:0:0:? ? ? ? class=0x020000
> card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00
> ? ? vendor? ???= 'Intel
> Corporation'
> ? ? class? ? ? = network
> ? ? subclass???= ethernet
> 
> igb1@pci0:1:0:1:? ? ? ? class=0x020000
> card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00
> ? ? vendor? ???= 'Intel
> Corporation'
> ? ? class? ? ? = network
> ? ? subclass???= ethernet
> 
> Card detects OK but when you assign an IP and try to ping,
> no packets are received, not even ARP replies.
> 
> This appears on the console:
> 
> igb0: watchdog timeout -- resetting
> igb0: Queue(0) tdh = 9, tdt = 9
> igb0: Queue(0) desc avail = 247, Next Desc to Clean = 0
> igb0: link state changed to DOWN
> igb0: link state changed to UP
> 

0 MSI/X vectors can't be a good thing. Another late night for Jack...


BC


      

From barney_cordoba at yahoo.com  Mon Sep 14 09:21:00 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Mon Sep 14 09:21:06 2009
Subject: [POLLING] strange interrupt/system load
In-Reply-To: <4AAD02A2.5060207@mail.ru>
Message-ID: <401488.48353.qm@web63902.mail.re1.yahoo.com>



--- On Sun, 9/13/09, rihad <rihad@mail.ru> wrote:

> From: rihad <rihad@mail.ru>
> Subject: Re: [POLLING] strange interrupt/system load
> To: "Barney Cordoba" <barney_cordoba@yahoo.com>
> Cc: freebsd-net@freebsd.org
> Date: Sunday, September 13, 2009, 10:33 AM
> Barney Cordoba wrote:
> > 
> > --- On Sun, 9/13/09, rihad <rihad@mail.ru>
> wrote:
> >> What's wrong with 64 bits?
> > 
> > I haven't spent a large portion of my life trying to
> figure
> > it out exactly, but I'd guess that the larger size of
> the structures and code results in fewer cache hits.
> 
> Then what's wrong with also doubling cache sizes?

Your logic is faulty here. Doubling the cache size also would 
increase the performance of the 32 bit version. In fact you'd 
probably increase the advantage of running in 32 bit mode.

> Besides, apart from other benefits, 64-bit makes every-day
> big number arithmetic a single CPU instruction as opposed to
> several instructions required on 32-bit CPUs through bignum
> emulation.


You move a lot more memory than you do math in an OS. Perhaps
a benchmark to calculate the US national debt would benefit, but
its not going to do much for the FreeBSD network stack.

Barney


      

From bugmaster at FreeBSD.org  Mon Sep 14 11:07:05 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Sep 14 11:08:54 2009
Subject: Current problem reports assigned to freebsd-net@FreeBSD.org
Message-ID: <200909141107.n8EB747J072418@freefall.freebsd.org>

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/138782  net        [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00
o kern/138739  net        [wpi] wpi(4) does not work very well under 8.0-BETA4
o kern/138694  net        [bge] FreeBSD 6.3 release does not recognize Broadcom 
p kern/138691  net        [netinet] [patch] Multicast: Keep membership and filte
p kern/138690  net        [netinet] [patch] multicast: uninited memory used in f
p kern/138689  net        [netinet] patch] Multicast: IP_DROP_MEMBERSHIP should 
o amd64/138688 net        [rum] possibly broken on 8 Beta 4 amd64: able to wpa a
o kern/138678  net        [lo] FreeBSD does not assign linklocal address to loop
o kern/138676  net        [route] after buildworld not work local routes [regres
o kern/138666  net        [multicast] [panic] not working multicast through igmp
o kern/138660  net        [igb] igb driver troubles in 8.0-BETA4
o kern/138652  net        TCP window scaling value calculated incorrectly?
o kern/138632  net        [ndis] [patch] race at vap destroy
o kern/138620  net        [lagg] [patch] lagg port bpf-writes blocked
o kern/138427  net        [wpi] [panic] Kernel panic after trying set monitor wl
o kern/138407  net        [gre] gre(4) interface does not come up after reboot
o kern/138390  net        [gif] [patch] NULL pointer dereference in gif_input() 
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/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
p kern/137164  net        [netinet] [patch] assert panic imo_match_source()
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/113432  net        [ucom] WARNING: attempt to net_add_domain(netgraph) af
o kern/112722  net        [ipsec] [udp] IP v4 udp fragmented packet reject
o kern/112686  net        [patm] patm driver freezes System (FreeBSD 6.2-p4) i38
o kern/112570  net        [bge] packet loss with bge driver on BCM5704 chipset
o bin/112557   net        [patch] ppp(8) lock file should not use symlink name
o kern/112528  net        [nfs] NFS over TCP under load hangs with "impossible p
o kern/111457  net        [ral] ral(4) freeze
o kern/110140  net        [ipw] ipw fails under load
o kern/109733  net        [bge] bge link state issues [regression]
o kern/109470  net        [wi] Orinoco Classic Gold PC Card Can't Channel Hop
o kern/109308  net        [pppd] [panic] Multiple panics kernel ppp suspected [r
o kern/109251  net        [re] [patch] if_re cardbus card won't attach
o bin/108895   net        pppd(8): PPPoE dead connections on 6.2 [regression]
o kern/108542  net        [bce] Huge network latencies with 6.2-RELEASE / STABLE
o kern/107944  net        [wi] [patch] Forget to unlock mutex-locks
o kern/107850  net        [bce] bce driver link negotiation is faulty
o conf/107035  net        [patch] bridge(8): bridge interface given in rc.conf n
o kern/106438  net        [ipf] ipfilter: keep state does not seem to allow repl
o kern/106316  net        [dummynet] dummynet with multipass ipfw drops packets 
o kern/106243  net        [nve] double fault panic in if_nve.c on high loads
o kern/105945  net        Address can disappear from network interface
s kern/105943  net        Network stack may modify read-only mbuf chain copies
o bin/105925   net        problems with ifconfig(8) and vlan(4) [regression]
o kern/105348  net        [ath] ath device stopps TX
o kern/104851  net        [inet6] [patch] On link routes not configured when usi
o kern/104751  net        [netgraph] kernel panic, when getting info about my tr
o kern/104485  net        [bge] Broadcom BCM5704C: Intermittent on newer chip ve
o kern/103191  net        Unpredictable reboot
o kern/103135  net        [ipsec] ipsec with ipfw divert (not NAT) encodes a pac
o conf/102502  net        [netgraph] [patch] ifconfig name does't rename netgrap
o kern/102035  net        [plip] plip networking disables parallel port printing
o kern/101948  net        [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau
o kern/100709  net        [libc] getaddrinfo(3) should return TTL info
o kern/100519  net        [netisr] suggestion to fix suboptimal network polling
o kern/98978   net        [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel
o kern/98597   net        [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu
o bin/98218    net        wpa_supplicant(8) blacklist not working
f bin/97392    net        ppp(8) hangs instead terminating
o kern/97306   net        [netgraph] NG_L2TP locks after connection with failed 
f kern/96268   net        [socket] TCP socket performance drops by 3000% if pack
o kern/96030   net        [bfe] [patch] Install hangs with Broadcomm 440x NIC in
o kern/95519   net        [ral] ral0 could not map mbuf
o kern/95288   net        [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr
o kern/95277   net        [netinet] [patch] IP Encapsulation mask_match() return
o kern/95267   net        packet drops periodically appear
s kern/94863   net        [bge] [patch] hack to get bge(4) working on IBM e326m
o kern/94162   net        [bge] 6.x kenel stale with bge(4)
o kern/93886   net        [ath] Atheros/D-Link DWL-G650 long delay to associate 
f kern/93378   net        [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo
o kern/93019   net        [ppp] ppp and tunX problems: no traffic after restarti
o kern/92880   net        [libc] [patch] almost rewritten inet_network(3) functi
f kern/92552   net        A serious bug in most network drivers from 5.X to 6.X 
s kern/92279   net        [dc] Core faults everytime I reboot, possible NIC issu
o kern/92090   net        [bge] bge0: watchdog timeout -- resetting
o kern/91859   net        [ndis] if_ndis does not work with Asus WL-138
s kern/91777   net        [ipf] [patch] wrong behaviour with skip rule inside an
o kern/91594   net        [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10
o kern/91364   net        [ral] [wep] WF-511 RT2500 Card PCI and WEP
o kern/91311   net        [aue] aue interface hanging
o kern/90890   net        [vr] Problems with network: vr0: tx shutdown timeout
s kern/90086   net        [hang] 5.4p8 on supermicro P8SCT hangs during boot if 
f kern/88082   net        [ath] [panic] cts protection for ath0 causes panic
o kern/87521   net        [ipf] [panic] using ipfilter "auth" keyword leads to k
o kern/87506   net        [vr] [patch] Fix alias support on vr interfaces
s kern/86920   net        [ndis] ifconfig: SIOCS80211: Invalid argument [regress
o kern/86103   net        [ipf] Illegal NAT Traversal in IPFilter
o kern/85780   net        'panic: bogus refcnt 0' in routing/ipv6
o bin/85445    net        ifconfig(8): deprecated keyword to ifconfig inoperativ
o kern/85266   net        [xe] [patch] xe(4) driver does not recognise Xircom XE
o kern/84202   net        [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre
o bin/82975    net        route change does not parse classfull network as given
o kern/82497   net        [vge] vge(4) on AMD64 only works when loaded late, not
f kern/81644   net        [vge] vge(4) does not work properly when loaded as a K
s kern/81147   net        [net] [patch] em0 reinitialization while adding aliase
o kern/80853   net        [ed] [patch] add support for Compex RL2000/ISA in PnP 
o kern/79895   net        [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph 
f kern/79262   net        [dc] Adaptec ANA-6922 not fully supported
o bin/79228    net        [patch] extend arp(8) to be able to create blackhole r
o kern/78090   net        [ipf] ipf filtering on bridged packets doesn't work if
p kern/77913   net        [wi] [patch] Add the APDL-325 WLAN pccard to wi(4)
o kern/77341   net        [ip6] problems with IPV6 implementation
o kern/77273   net        [ipf] ipfilter breaks ipv6 statefull filtering on 5.3
s kern/77195   net        [ipf] [patch] ipfilter ioctl SIOCGNATL does not match 
o kern/75873   net        Usability problem with non-RFC-compliant IP spoof prot
s kern/75407   net        [an] an(4): no carrier after short time
f kern/73538   net        [bge] problem with the Broadcom BCM5788 Gigabit Ethern
o kern/71469   net        default route to internet magically disappears with mu
o kern/70904   net        [ipf] ipfilter ipnat problem with h323 proxy support
o kern/64556   net        [sis] 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

349 problems total.

From rihad at mail.ru  Mon Sep 14 11:23:40 2009
From: rihad at mail.ru (rihad)
Date: Mon Sep 14 11:23:51 2009
Subject: [POLLING] strange interrupt/system load
In-Reply-To: <676338.40771.qm@web63905.mail.re1.yahoo.com>
References: <676338.40771.qm@web63905.mail.re1.yahoo.com>
Message-ID: <4AAE27B8.6050006@mail.ru>

Barney Cordoba wrote:
> 
>> Without polling (current load around 190-200 mbit/s, around
>> 24-26 kpps):
>>
>> top:
>> CPU:  0.0% user,  0.0% nice,  8.4%
>> system,  0.0% interrupt, 91.6% idle
>>
>> Interrupts/s: 18322 total
>> 28 mpt0 irq16
>> 1999 cpu0: time
>> 6906 em0 irq256
>> 3392 em1 irq257
>> 1999 cpu1: time
>> 1999 cpu2: time
>> 1999 cpu3: time
> 
> You really need to look at the taskq usage as averaging on a 4 core
CPU:  0.0% user,  0.0% nice, 10.0% system,  0.0% interrupt, 90.0% idle
    27 root        1 -68    -     0K    16K -      1 137:47 40.28% em0 taskq
    28 root        1 -68    -     0K    16K -      2   5:05  0.88% em1 taskq

> You'll do a lot better setting your ITR to 2000 or so. You really don't
> need an interrupt every 4 packets at those traffic levels.

Sorry, how would I do that? And how do I find the current ITR value?
From m.matthieu at gmail.com  Mon Sep 14 13:10:03 2009
From: m.matthieu at gmail.com (matthieu)
Date: Mon Sep 14 13:10:11 2009
Subject: kern/127587: [bge] [request] if_bge(4) doesn't support BCM576X 
	family
Message-ID: <200909141310.n8EDA2jD098091@freefall.freebsd.org>

The following reply was made to PR kern/127587; it has been noted by GNATS.

From: matthieu <m.matthieu@gmail.com>
To: bug-followup@FreeBSD.org, nork@FreeBSD.org
Cc:  
Subject: Re: kern/127587: [bge] [request] if_bge(4) doesn't support BCM576X 
	family
Date: Mon, 14 Sep 2009 14:38:16 +0200

 --0016364c76519f4566047388f05a
 Content-Type: text/plain; charset=ISO-8859-1
 
 Hi,
 
 Here a minimalist patch against 8.0-BETA1 to make it works on dell
 E5400 (BCM5761, dev_id=0x1680).
 
 It may be useful for someone.
 
 -- 
 matthieu
 
 --0016364c76519f4566047388f05a
 Content-Type: application/octet-stream; name="patch_5761.patch"
 Content-Disposition: attachment; filename="patch_5761.patch"
 Content-Transfer-Encoding: base64
 X-Attachment-Id: file0
 
 LS0tIGlmX2JnZS5jLmJhY2sJMjAwOS0wNy0wOCAyMDozNjo0NS4wMDAwMDAwMDAgKzAyMDAKKysr
 IGlmX2JnZS5jCTIwMDktMDktMTIgMDA6MTI6NTMuMDAwMDAwMDAwICswMjAwCkBAIC0yNzIsNiAr
 MjcyLDcgQEAKIAl7IEJHRV9DSElQSURfQkNNNTc1NV9BMSwJIkJDTTU3NTUgQTEiIH0sCiAJeyBC
 R0VfQ0hJUElEX0JDTTU3NTVfQTIsCSJCQ001NzU1IEEyIiB9LAogCXsgQkdFX0NISVBJRF9CQ001
 NzIyX0EwLAkiQkNNNTcyMiBBMCIgfSwKKwl7IEJHRV9DSElQSURfQkNNNTc2MSwJCSJCQ001NzYx
 IiB9LCAKIAkvKiA1NzU0IGFuZCA1Nzg3IHNoYXJlIHRoZSBzYW1lIEFTSUMgSUQgKi8KIAl7IEJH
 RV9DSElQSURfQkNNNTc4N19BMCwJIkJDTTU3NTQvNTc4NyBBMCIgfSwgCiAJeyBCR0VfQ0hJUElE
 X0JDTTU3ODdfQTEsCSJCQ001NzU0LzU3ODcgQTEiIH0sCkBAIC0yNDE3LDYgKzI0MTgsMTIgQEAK
 IAlzYy0+YmdlX2FzaWNyZXYgPSBCR0VfQVNJQ1JFVihzYy0+YmdlX2NoaXBpZCk7CiAJc2MtPmJn
 ZV9jaGlwcmV2ID0gQkdFX0NISVBSRVYoc2MtPmJnZV9jaGlwaWQpOwogCisJaWYgKHNjLT5iZ2Vf
 YXNpY3JldiA9PSBCR0VfQVNJQ1JFVl9QUk9EX0lEX1JFRykKKwkgIHsKKwkgICAgc2MtPmJnZV9j
 aGlwaWQgPSBwY2lfcmVhZF9jb25maWcoZGV2LCBCR0VfUENJX1BST0RJRF9BU0lDUkVWLCA0KTsK
 KwkgIH0KKworCiAJLyoKIAkgKiBEb24ndCBlbmFibGUgRXRoZXJuZXRAV2lyZVNwZWVkIGZvciB0
 aGUgNTcwMCwgNTkwNiwgb3IgdGhlCiAJICogNTcwNSBBMCBhbmQgQTEgY2hpcHMuCkBAIC0yNDI0
 LDggKzI0MzEsOSBAQAogCWlmIChzYy0+YmdlX2FzaWNyZXYgIT0gQkdFX0FTSUNSRVZfQkNNNTcw
 MCAmJgogCSAgICBzYy0+YmdlX2FzaWNyZXYgIT0gQkdFX0FTSUNSRVZfQkNNNTkwNiAmJgogCSAg
 ICBzYy0+YmdlX2NoaXBpZCAhPSBCR0VfQ0hJUElEX0JDTTU3MDVfQTAgJiYKLQkgICAgc2MtPmJn
 ZV9jaGlwaWQgIT0gQkdFX0NISVBJRF9CQ001NzA1X0ExKQotCQlzYy0+YmdlX2ZsYWdzIHw9IEJH
 RV9GTEFHX1dJUkVTUEVFRDsKKwkgICAgc2MtPmJnZV9jaGlwaWQgIT0gQkdFX0NISVBJRF9CQ001
 NzA1X0ExICYmCisJICAgIHNjLT5iZ2VfY2hpcGlkICE9IEJHRV9DSElQSURfQkNNNTc2MSkKKwkg
 IHNjLT5iZ2VfZmxhZ3MgfD0gQkdFX0ZMQUdfV0lSRVNQRUVEOwogCiAJaWYgKGJnZV9oYXNfZWFk
 ZHIoc2MpKQogCQlzYy0+YmdlX2ZsYWdzIHw9IEJHRV9GTEFHX0VBRERSOwpAQCAtMjQ3NCw2ICsy
 NDgyLDEwIEBACiAJCQlzYy0+YmdlX2ZsYWdzIHw9IEJHRV9GTEFHX0JFUl9CVUc7CiAJfQogCisJ
 aWYgKHNjLT5iZ2VfY2hpcGlkID09IEJHRV9DSElQSURfQkNNNTc2MSkKKwkgIHsKKwkgICAgc2Mt
 PmJnZV9mbGFncyB8PSBCR0VfRkxBR181NzA1X1BMVVM7CisJICB9CiAKIAkvKgogCSAqIFdlIGNv
 dWxkIHBvc3NpYmx5IGNoZWNrIGZvciBCQ09NX0RFVklDRUlEX0JDTTU3ODggaW4gYmdlX3Byb2Jl
 KCkKLS0tIGlmX2JnZXJlZy5oLm9sZAkyMDA5LTAzLTIzIDE1OjM2OjUwLjAwMDAwMDAwMCArMDEw
 MAorKysgaWZfYmdlcmVnLmgJMjAwOS0wOS0xNCAxMjoyMzozOC4wMDAwMDAwMDAgKzAyMDAKQEAg
 LTIxOCw2ICsyMTgsNyBAQAogI2RlZmluZQlCR0VfUENJX1VORElfVFhfQkRfUFJPRElEWF9MTwkw
 eEFDCiAjZGVmaW5lCUJHRV9QQ0lfSVNSX01CWF9ISQkJMHhCMAogI2RlZmluZQlCR0VfUENJX0lT
 Ul9NQlhfTE8JCTB4QjQKKyNkZWZpbmUJQkdFX1BDSV9QUk9ESURfQVNJQ1JFVgkJMHhCQwogCiAv
 KiBQQ0kgTWlzYy4gSG9zdCBjb250cm9sIHJlZ2lzdGVyICovCiAjZGVmaW5lCUJHRV9QQ0lNSVND
 Q1RMX0NMRUFSX0lOVEEJMHgwMDAwMDAwMQpAQCAtMzAyLDYgKzMwMyw3IEBACiAjZGVmaW5lCUJH
 RV9DSElQSURfQkNNNTc4N19BMgkJMHhiMDAyMDAwMAogI2RlZmluZQlCR0VfQ0hJUElEX0JDTTU5
 MDZfQTEJCTB4YzAwMTAwMDAKICNkZWZpbmUJQkdFX0NISVBJRF9CQ001OTA2X0EyCQkweGMwMDIw
 MDAwCisjZGVmaW5lCUJHRV9DSElQSURfQkNNNTc2MQkJMHgwNTc2MTEwMAogCiAvKiBzaG9ydGhh
 bmQgb25lICovCiAjZGVmaW5lCUJHRV9BU0lDUkVWKHgpCQkJKCh4KSA+PiAyOCkKQEAgLTMxOSw2
 ICszMjEsOSBAQAogI2RlZmluZQlCR0VfQVNJQ1JFVl9CQ001NzU0CQkweDBiCiAjZGVmaW5lCUJH
 RV9BU0lDUkVWX0JDTTU3ODcJCTB4MGIKICNkZWZpbmUJQkdFX0FTSUNSRVZfQkNNNTkwNgkJMHgw
 YworI2RlZmluZQlCR0VfQVNJQ1JFVl9QUk9EX0lEX1JFRwkJMHgwZgorCisjZGVmaW5lCUJHRV9B
 U0lDUkVWX0JDTTU3NjEJCTB4NTc2MQogCiAvKiBjaGlwIHJldmlzaW9ucyAqLwogI2RlZmluZQlC
 R0VfQ0hJUFJFVih4KQkJCSgoeCkgPj4gMjQpCkBAIC0yMDk4LDYgKzIxMDMsNyBAQAogI2RlZmlu
 ZQlCQ09NX0RFVklDRUlEX0JDTTU3MTRTCQkweDE2NjkKICNkZWZpbmUJQkNPTV9ERVZJQ0VJRF9C
 Q001NzE1CQkweDE2NzgKICNkZWZpbmUJQkNPTV9ERVZJQ0VJRF9CQ001NzE1UwkJMHgxNjc5Cisj
 ZGVmaW5lCUJDT01fREVWSUNFSURfQkNNNTc2MUUJCTB4MTY4MAogI2RlZmluZQlCQ09NX0RFVklD
 RUlEX0JDTTU3MjAJCTB4MTY1OAogI2RlZmluZQlCQ09NX0RFVklDRUlEX0JDTTU3MjEJCTB4MTY1
 OQogI2RlZmluZQlCQ09NX0RFVklDRUlEX0JDTTU3MjIJCTB4MTY1QQo=
 --0016364c76519f4566047388f05a--
From barney_cordoba at yahoo.com  Mon Sep 14 15:10:33 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Mon Sep 14 15:10:40 2009
Subject: [POLLING] strange interrupt/system load
In-Reply-To: <4AAE27B8.6050006@mail.ru>
Message-ID: <409746.70532.qm@web63901.mail.re1.yahoo.com>



--- On Mon, 9/14/09, rihad <rihad@mail.ru> wrote:

> From: rihad <rihad@mail.ru>
> Subject: Re: [POLLING] strange interrupt/system load
> To: "Barney Cordoba" <barney_cordoba@yahoo.com>
> Cc: freebsd-net@FreeBSD.org
> Date: Monday, September 14, 2009, 7:23 AM
> Barney Cordoba wrote:
> > 
> >> Without polling (current load around 190-200
> mbit/s, around
> >> 24-26 kpps):
> >>
> >> top:
> >> CPU:? 0.0% user,? 0.0% nice,? 8.4%
> >> system,? 0.0% interrupt, 91.6% idle
> >>
> >> Interrupts/s: 18322 total
> >> 28 mpt0 irq16
> >> 1999 cpu0: time
> >> 6906 em0 irq256
> >> 3392 em1 irq257
> >> 1999 cpu1: time
> >> 1999 cpu2: time
> >> 1999 cpu3: time
> > 
> > You really need to look at the taskq usage as
> averaging on a 4 core
> CPU:? 0.0% user,? 0..0% nice, 10.0% system,?
> 0.0% interrupt, 90.0% idle
> ? ? 27 root? ? ? ? 1
> -68? ? -? ???0K? ?
> 16K -? ? ? 1 137:47 40.28% em0 taskq
> ? ? 28 root? ? ? ? 1
> -68? ? -? ???0K? ?
> 16K -? ? ? 2???5:05?
> 0.88% em1 taskq
> 
> > You'll do a lot better setting your ITR to 2000 or so.
> You really don't
> > need an interrupt every 4 packets at those traffic
> levels.
> 
> Sorry, how would I do that? And how do I find the current
> ITR value?
> 
I made mine a sysctl long ago, so I'm not sure what the current state
of em is. It used to be a macro MAX_INTS_PER_SEC

Barney


      

From universite at ukr.net  Mon Sep 14 16:18:45 2009
From: universite at ukr.net (Vladislav V. Prodan)
Date: Mon Sep 14 16:24:24 2009
Subject: kern/138782: [panic] sbflush_internal: cc 0 || mb
 0xffffff004127b000 || mbcnt 2304
Message-ID: <4AAE6CB0.3010404@ukr.net>

mary-teresa.otrada.od.ua dumped core - see /var/crash/vmcore.12

ÐÏÎÅÄÅÌØÎÉË, 14 ÓÅÎÔÑÂÒÑ 2009 Ç. 19:13:35 (EEST)

FreeBSD mary-teresa.otrada.od.ua 8.0-BETA4 FreeBSD 8.0-BETA4 #0: Sun Sep 13 03:05:09 EEST 2009     vlad11@mary-teresa.otrada.od.ua:/usr/obj/usr/src/sys/mary-teresa.18  amd64

panic: sbflush_internal: cc 0 || mb 0xffffff004127b000 || mbcnt 2304

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 "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
panic: sbflush_internal: cc 0 || mb 0xffffff004127b000 || mbcnt 2304
cpuid = 1
Uptime: 14h42m52s
Physical memory: 6098 MB
Dumping 1729 MB: 1714 1698 1682 1666 1650 1634 1618 1602 1586 1570 1554 1538 1522 1506 1490 1474 1458 1442 1426 1410 1394 1378 1362 1346 1330 1314 1298 1282 1266 1250 1234 1218 1202 1186 1170 1154 1138 1122 1106 1090 1074 1058 1042 1026 1010 994 978 962 946 930 914 898 882 866 850 834 818 802 786 770 754 738 722 706 690 674 658 642 626 610 594 578 562 546 530 514 498 482 466 450 434 418 402 386 370 354 338 322 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2

Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/zfs.ko
Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/opensolaris.ko
Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from /boot/kernel/accf_http.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/accf_http.ko
#0  doadump () at pcpu.h:223
223	pcpu.h: îÅÔ ÔÁËÏÇÏ ÆÁÊÌÁ ÉÌÉ ËÁÔÁÌÏÇÁ.
	in pcpu.h
(kgdb) #0  doadump () at pcpu.h:223
#1  0xffffffff803a5089 in boot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:416
#2  0xffffffff803a54dc in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:579
#3  0xffffffff80401a44 in sbflush_internal (sb=0xffffff01250e9180)
    at /usr/src/sys/kern/uipc_sockbuf.c:824
#4  0xffffffff80401b3c in sbrelease_internal (sb=0xffffff01250e9180, 
    so=0xffffff01250e9000) at /usr/src/sys/kern/uipc_sockbuf.c:339
#5  0xffffffff8040335c in sofree (so=0xffffff01250e9000)
    at /usr/src/sys/kern/uipc_socket.c:632
#6  0xffffffff80552fa8 in tcp_close (tp=0x0)
    at /usr/src/sys/netinet/tcp_subr.c:937
#7  0xffffffff8054bc15 in tcp_do_segment (m=0xffffff0197fae300, 
    th=0xffffff0197fae37c, so=0xffffff01250e9000, tp=0xffffff0125111a50, 
    drop_hdrlen=52, tlen=0, iptos=0 '\0', ti_locked=3)
    at /usr/src/sys/netinet/tcp_input.c:2467
#8  0xffffffff8054ddbb in tcp_input (m=0xffffff0197fae300, off0=Variable "off0" is not available.
)
    at /usr/src/sys/netinet/tcp_input.c:1047
#9  0xffffffff804d8d7b in ip_input (m=0xffffff0197fae300)
    at /usr/src/sys/netinet/ip_input.c:775
#10 0xffffffff80471042 in swi_net (arg=Variable "arg" is not available.
) at /usr/src/sys/net/netisr.c:716
#11 0xffffffff8037f360 in intr_event_execute_handlers (p=Variable "p" is not available.
)
    at /usr/src/sys/kern/kern_intr.c:1165
#12 0xffffffff803808de in ithread_loop (arg=0xffffff00013926a0)
    at /usr/src/sys/kern/kern_intr.c:1178
#13 0xffffffff8037d367 in fork_exit (
    callout=0xffffffff80380850 <ithread_loop>, arg=0xffffff00013926a0, 
    frame=0xffffff8000037c80) at /usr/src/sys/kern/kern_fork.c:843
#14 0xffffffff806457ee in fork_trampoline ()
    at /usr/src/sys/amd64/amd64/exception.S:561
#15 0x0000000000000000 in ?? ()
#16 0x0000000000000000 in ?? ()
#17 0x0000000000000001 in ?? ()
#18 0x0000000000000000 in ?? ()
#19 0x0000000000000000 in ?? ()
#20 0x0000000000000000 in ?? ()
#21 0x0000000000000000 in ?? ()
#22 0x0000000000000000 in ?? ()
#23 0x0000000000000000 in ?? ()
#24 0x0000000000000000 in ?? ()
#25 0x0000000000000000 in ?? ()
#26 0x0000000000000000 in ?? ()
#27 0x0000000000000000 in ?? ()
#28 0x0000000000000000 in ?? ()
#29 0x0000000000000000 in ?? ()
#30 0x0000000000000000 in ?? ()
#31 0x0000000000000000 in ?? ()
#32 0x0000000000000000 in ?? ()
#33 0x0000000000000000 in ?? ()
#34 0x0000000000000000 in ?? ()
#35 0x0000000000000000 in ?? ()
#36 0x0000000000000000 in ?? ()
#37 0x0000000000000000 in ?? ()
#38 0x0000000000000000 in ?? ()
#39 0x0000000000c6c000 in ?? ()
#40 0x000000000000000b in ?? ()
#41 0xffffffff808cf280 in affinity ()
#42 0xffffffff808cf280 in affinity ()
#43 0xffffff000150d720 in ?? ()
#44 0xffffff8000037230 in ?? ()
#45 0xffffff80000371e8 in ?? ()
#46 0xffffff0001399000 in ?? ()
#47 0xffffffff803c7f99 in sched_switch (td=0xffffff00013926a0, 
    newtd=0xffffffff80380850, flags=Variable "flags" is not available.
) at /usr/src/sys/kern/sched_ule.c:1858
Previous frame inner to this frame (corrupt stack?)
(kgdb) 

------------------------------------------------------------------------
ps -axl

Segmentation fault (core dumped)

------------------------------------------------------------------------
vmstat -s

        0 cpu context switches
        0 device interrupts
        0 software interrupts
        0 traps
        0 system calls
        0 kernel threads created
        0  fork() calls
        0 vfork() calls
        0 rfork() calls
        0 swap pager pageins
        0 swap pager pages paged in
        0 swap pager pageouts
        0 swap pager pages paged out
        0 vnode pager pageins
        0 vnode pager pages paged in
        0 vnode pager pageouts
        0 vnode pager pages paged out
       51 page daemon wakeups
  1981145 pages examined by the page daemon
  2010517 pages reactivated
        0 copy-on-write faults
        0 copy-on-write optimized faults
        0 zero fill pages zeroed
        0 zero fill pages prezeroed
        0 intransit blocking page faults
        0 total VM faults taken
        0 pages affected by kernel thread creation
        0 pages affected by  fork()
        0 pages affected by vfork()
        0 pages affected by rfork()
  8898755 pages cached
        0 pages freed
        0 pages freed by daemon
  9491705 pages freed by exiting processes
   961187 pages active
   336034 pages inactive
    18114 pages in VM cache
   132377 pages wired down
    63524 pages free
     4096 bytes per page
121899488 total name lookups
          cache hits (95% pos + 2% neg) system 0% per-directory
          deletions 0%, falsehits 0%, toolong 0%

------------------------------------------------------------------------
vmstat -m

         Type InUse MemUse HighUse Requests  Size(s)
         cdev    10     3K       -       10  256
      acpidev    70     5K       -       70  64
        sigio     1     1K       -     7033  64
     filedesc   209   779K       -    57597  16,32,64,128,256,512,1024,2048,4096
         kenv    82    11K       -       89  16,32,64,128
       kqueue    70   245K       -    30235  256,2048
    proc-args    78     5K       -    93780  16,32,64,128,256
      ithread    79    13K       -       79  32,128,256
      entropy  1024    64K       -     1024  64
       KTRACE   100    13K       -      100  128
       linker   139   153K       -      183  16,32,64,128,256,512,1024,2048
        lockf    84     9K       -   632543  64,128,256
       ip6ndp    11     1K       -       21  64,128
       ip6opt     1     1K       -      357  32,256
         temp    53    14K       -   237974  16,32,64,128,256,512,1024,2048,4096
       devbuf 19085 39313K       -    20729  16,32,64,128,256,512,1024,2048,4096
         UART     3     2K       -        3  16,512,1024
       module   332    42K       -      332  128
CAM dev queue     1     1K       -        1  128
     mtx_pool     2    16K       -        2  
          osd     3     1K       -        6  16,64,128
       USBdev    28     9K       -       28  64,128,1024
      subproc   449   729K       -    54150  512,4096
         proc     2    32K       -        2  
      session    54     7K       -     4589  128
         pgrp    59     8K       -     4669  128
         cred   212    34K       -  2850434  64,256
      uidinfo    13     6K       -     4245  128,4096
       plimit    37    10K       -     6835  256
          USB    49    16K       -       49  16,32,64,2048
    sysctltmp     0     0K       -     5991  16,32,64,128,256
    sysctloid  4027   198K       -     4143  16,32,64,128
       sysctl     0     0K       -    36821  16,32,64
      callout     1   512K       -        1  
         umtx   528    66K       -      528  128
     p1003.1b     1     1K       -        1  16
         SWAP     2  2189K       -        2  64
       DEVFS1   115    58K       -      197  512
       bus-sc    86   215K       -     2034  16,32,64,128,256,512,1024,2048,4096
          bus   835    79K       -     5088  16,32,64,128,256,512,1024
      devstat    90   182K       -       90  32,4096
 eventhandler    95     8K       -       95  64,128
       DEVFS3   253    64K       -      577  256
         kobj   155   620K       -      312  4096
      Per-cpu     1     1K       -        1  32
       DEVFS2   110     2K       -      110  16
   DEVFS_RULE    40    18K       -      114  64,512
         rman   220    27K       -      651  16,32,128
        DEVFS    32     1K       -       63  16,128
         sbuf     0     0K       -     8390  16,32,64,128,256,512,1024,2048,4096
       DEVFSP     2     1K       -        2  64
        stack     0     0K       -        2  256
    taskqueue    39     4K       -       65  16,32,64,128
       Unitno    16     1K       -    18822  32,64
          iov     0     0K       -  1245473  16,32,64,128,256,512
       select   333    42K       -      333  128
     ioctlops     0     0K       -    59626  16,32,64,128,256,512,1024,4096
          msg     4    54K       -        4  2048
          sem     4    11K       -        4  512,1024
          shm    13     7K       -     2461  256,4096
          tty    23    23K       -       27  1024,2048
          pts     5     2K       -        7  256
         accf     2     1K       -        3  32,64
     mbuf_tag     1     1K       -  6874132  32,64,128
        shmfd     1     8K       -        1  
          pcb   501   172K       -   419505  16,32,64,128,1024,2048,4096
       soname    33     4K       - 49414343  16,32,128
          acl     0     0K       -    15916  4096
       biobuf     0     0K       -      514  2048
     vfscache     1  1024K       -        1  
   cl_savebuf     0     0K       -     2068  64,128
     vfs_hash     1   512K       -        1  
       vnodes    10     1K       -       17  64,256
  vnodemarker     0     0K       -    22347  512
        mount   111     5K       -      257  16,32,64,128,256
          BPF    18    75K       -       20  16,64,128,512,4096
  ether_multi    55     3K       -      102  16,32,64
       ifaddr   112    29K       -      127  16,32,64,128,256,512,2048,4096
        ifnet    10    19K       -       11  128,2048
        clone    14    53K       -       18  16,256,4096
       arpcom     3     1K       -        3  16
          gif     1     1K       -        2  256
      lltable    44    16K       -      639  256,512
         sppp     2     4K       -        2  2048
          tun     2     1K       -        2  256
  nullfs_hash     1     1K       -        1  128
    pfs_nodes    20     5K       -       20  256
    CAM queue     3     1K       -        7  16
     pci_link    16     2K       -       16  32,128
     routetbl   261    81K       -     6251  32,64,128,256,512,1024
 netflow_hash     1  3072K       -        2  
         GEOM   176   102K       -    11438  16,32,64,128,256,512,1024,2048
    acpi_perf     2     1K       -        2  128
 netgraph_msg     0     0K       -       75  64,128,256,1024,2048,4096
netgraph_node    17     5K       -       17  256
netgraph_hook    38     5K       -       38  128
     netgraph    16  2053K       -       17  16,32,64
netgraph_ksock     1     1K       -        1  128
netgraph_parse     0     0K       -        6  16
netgraph_pppoe     4    25K       -        6  64,512
netgraph_sock     3     1K       -        7  128
netgraph_path     0     0K       -       50  16
         igmp     9     3K       -       10  256
     in_multi     5     2K       -        6  256
encap_export_host     3     3K       -        4  1024
       acpica  3276   322K       -   129171  16,32,64,128,256,512,1024,2048,4096
     ipfw_tbl    65    17K       -       65  256
  IpFw/IpAcct    98    15K       -      100  64,128,256,2048
    mroutetbl     1     1K       -        1  256
    sctp_iter     0     0K       -       14  256
     sctp_ifn     6     1K       -        9  128
     sctp_ifa     9     2K       -       13  128
     sctp_vrf     1     1K       -        1  64
    sctp_a_it     0     0K       -       14  16
    hostcache     1    28K       -        1  
     syncache     1    96K       -        1  
     libalias  2410   429K       -   442720  128
      sctpnat     6    80K       -        6  
     acpitask     1     2K       -        1  2048
      CAM SIM     1     1K       -        1  256
 ip6_moptions     2     1K       -        4  32,256
    in6_multi    29     4K       -       59  32,256
  in6_mfilter     1     1K       -        2  1024
          mld     9     2K       -       10  128
      NFS FHA     1     2K       -        1  2048
          rpc     2     9K       -        2  256
audit_evclass   172     6K       -      211  32
     savedino     0     0K       -     1653  256
    newdirblk     0     0K       -        1  64
       dirrem     0     0K       -     7458  64
        mkdir     0     0K       -      960  64
       diradd     0     0K       -     8503  64
     freefile     0     0K       -     5795  64
     freeblks     0     0K       -    11078  256
     freefrag     0     0K       -    11482  64
   allocindir     4     1K       -   207197  128
     indirdep     4     1K       -     4661  64
  allocdirect     3     1K       -    25430  256
    bmsafemap     0     0K       -    10881  128
       newblk     1     1K       -   232628  64,512
     inodedep     4   513K       -    13477  256
      pagedep     1   128K       -     3923  128
  ufs_dirhash    77    33K       -     1300  16,32,64,128,256,512
    ufs_quota     1   512K       -        1  
    ufs_mount    16    77K       -       25  128,512,1024,2048,4096
      UMAHash     2     4K       -        6  512,1024,2048
      acpisem    18     3K       -       18  128
  ata_generic     7     7K       -        7  1024
    vm_pgdata     2   129K       -        2  128
    ad_driver     7     1K       -        7  32
    ar_driver     0     0K       -       42  512,2048
      io_apic     1     2K       -        1  2048
       kbdmux     6    10K       -        6  16,512,1024,2048,4096
      memdesc     1     4K       -        1  4096
          msi     1     1K       -        1  128
     nexusdev     3     1K       -        3  16
       isadev     9     2K       -        9  128
     atkbddev     2     1K       -        2  64
      md_disk     1     2K       -        1  2048
      CAM XPT    11     3K       -       30  32,64,128,2048
   CAM periph     2     1K       -       11  16,32,64,128,256
      solaris 95684 147007K       - 326258831  16,32,64,128,256,512,1024,2048,4096
   kstat_data     2     1K       -        2  64
        linux    12     1K       -       12  64

------------------------------------------------------------------------
vmstat -z

ITEM                     SIZE     LIMIT      USED      FREE  REQUESTS  FAILURES

UMA Kegs:                 208,        0,      117,        2,      118,        0
UMA Zones:                256,        0,      117,        3,      118,        0
UMA Slabs:                568,        0,     6213,     2026,  6240074,        0
UMA RCntSlabs:            568,        0,     3083,        4,    19522,        0
UMA Hash:                 256,        0,        3,       12,        5,        0
16 Bucket:                152,        0,       14,       86,      133,        0
32 Bucket:                280,        0,       32,       52,      205,        0
64 Bucket:                536,        0,       52,       18,      484,       55
128 Bucket:              1048,        0,     1662,       12,    49082,    12937
VM OBJECT:                216,        0,    30784,    36428,  2173748,        0
MAP:                      232,        0,        7,       25,        7,        0
KMAP ENTRY:               120,   221805,      616,     2329, 16433723,        0
MAP ENTRY:                120,        0,     9661,     2770,  5704862,        0
DP fakepg:                120,        0,        0,        0,        0,        0
SG fakepg:                120,        0,        0,        0,        0,        0
mt_zone:                 2056,        0,      283,       39,      283,        0
16:                        16,        0,     7356,    14316, 57538583,        0
32:                        32,        0,     3346,     1300, 13576784,        0
64:                        64,        0,    39662,    21658, 123656572,        0
128:                      128,        0,    10042,    23830, 52547978,        0
256:                      256,        0,     3658,     4202, 88424437,        0
512:                      512,        0,    55218,    38414, 42049768,        0
1024:                    1024,        0,      102,     1846,  1661880,        0
2048:                    2048,        0,      220,     2200,  2665732,        0
4096:                    4096,        0,      458,      395,  1194549,        0
Files:                     80,        0,    19961,      604,  3066611,        0
TURNSTILE:                136,        0,      529,       51,      529,        0
umtx pi:                   96,        0,        0,        0,        0,        0
PROC:                    1120,        0,      143,      160,    53844,        0
THREAD:                   912,        0,      414,      114,     9730,        0
SLEEPQUEUE:                64,        0,      529,       87,      529,        0
VMSPACE:                  392,        0,      109,      161,    53803,        0
cpuset:                    72,        0,        2,       98,        2,        0
audit_record:             952,        0,        0,        0,        0,        0
mbuf_packet:              256,        0,      748,      587, 44826150,        0
mbuf:                     256,        0,     2515,      697, 119951923,        0
mbuf_cluster:            2048,    33792,     1024,      236,     6912,        0
mbuf_jumbo_page:         4096,    16896,     1934,      519,  7094338,        0
mbuf_jumbo_9k:           9216,    25344,        0,        0,        0,        0
mbuf_jumbo_16k:         16384,    16896,        0,        0,        0,        0
mbuf_ext_refcnt:            4,        0,        0,        0,        0,        0
NetGraph items:           104,     4118,        0,      116,    11414,        0
NetGraph data items:      104,      522,        1,      203, 44689891,        0
g_bio:                    232,        0,        0,      976, 21136234,        0
ttyinq:                   160,        0,      195,       69,      420,        0
ttyoutq:                  256,        0,      104,       46,      224,        0
ata_request:              312,        0,        1,      573, 10421236,        0
ata_composite:            336,        0,        0,        0,        0,        0
taskq_zone:                48,        0,        0,      432, 10400641,        0
VNODE:                    472,        0,    52189,    25899,  2979538,        0
VNODEPOLL:                112,        0,        5,       94,        9,        0
NAMEI:                   1024,        0,        0,       92, 18893246,        0
S VFS Cache:              108,        0,    41861,    37801,  2813422,        0
L VFS Cache:              328,        0,    12788,      904,   305699,        0
NFSMOUNT:                 608,        0,        0,        0,        0,        0
NFSNODE:                  648,        0,        0,        0,        0,        0
DIRHASH:                 1024,        0,       16,      136,     1779,        0
zio_cache:                720,        0,        1,     7529, 45835634,        0
dmu_buf_impl_t:           224,        0,    56630,    64699,  7158133,        0
dnode_t:                  768,        0,    54318,    38462,  2663461,        0
arc_buf_hdr_t:            208,        0,     3651,     6573,  2680769,        0
arc_buf_t:                 72,        0,     2347,     4503,  4915367,        0
zil_lwb_cache:            200,        0,        0,        0,        0,        0
zfs_znode_cache:          376,        0,    47057,      313,  2720595,        0
pipe:                     728,        0,       45,       90,    40871,        0
ksiginfo:                 112,        0,      288,       75,      303,        0
itimer:                   344,        0,        1,       21,        1,        0
KNOTE:                    120,        0,      555,      716, 16225963,        0
bridge_rtnode:             64,        0,        0,        0,        0,        0
socket:                   680,    33792,      648,      570,   570888,        0
unpcb:                    240,    33792,      117,      155,    34952,        0
ipq:                       56,     1071,        0,      189,       19,        0
udp_inpcb:                336,    33792,       34,      186,    91766,        0
udpcb:                     16,    33936,       34,      470,    91766,        0
tcp_inpcb:                336,    33792,      723,      674,   442028,        0
tcpcb:                    880,    33792,      468,      588,   442028,        0
tcptw:                     72,     6800,      255,      545,   188909,        0
syncache:                 144,    15366,       18,      216,   149489,        0
hostcache:                136,    15372,     5982,      598,    24943,        0
tcpreass:                  40,     2184,        2,      418,    25399,        0
sackhole:                  32,        0,       39,      466,  2105812,        0
sctp_ep:                 1248,    33792,        0,        0,        0,        0
sctp_asoc:               2176,    40000,        0,        0,        0,        0
sctp_laddr:                48,    80064,        0,      216,       16,        0
sctp_raddr:               592,    80004,        0,        0,        0,        0
sctp_chunk:               144,   400010,        0,        0,        0,        0
sctp_readq:               104,   400032,        0,        0,        0,        0
sctp_stream_msg_out:       96,   400026,        0,        0,        0,        0
sctp_asconf:               40,   400008,        0,        0,        0,        0
sctp_asconf_ack:           48,   400032,        0,        0,        0,        0
ripcb:                    336,    33792,        4,       51,     2035,        0
rtentry:                  200,        0,       94,       58,      117,        0
pfsrctrpl:                152,        0,        0,        0,        0,        0
pfrulepl:                 912,        0,        0,        0,        0,        0
pfstatepl:                392,    10000,        0,        0,        0,        0
pfaltqpl:                 240,        0,        0,        0,        0,        0
pfpooladdrpl:              88,        0,        0,        0,        0,        0
pfrktable:               1296,        0,        0,        0,        0,        0
pfrkentry:                216,        0,        0,        0,        0,        0
pfrkentry2:               216,        0,        0,        0,        0,        0
pffrent:                   32,     5050,        0,        0,        0,        0
pffrag:                    80,        0,        0,        0,        0,        0
pffrcache:                 80,    10035,        0,        0,        0,        0
pffrcent:                  24,    50022,        0,        0,        0,        0
pfstatescrub:              40,        0,        0,        0,        0,        0
pfiaddrpl:                120,        0,        0,        0,        0,        0
pfospfen:                 112,        0,        0,        0,        0,        0
pfosfp:                    40,        0,        0,        0,        0,        0
IPFW dynamic rule:        120,        0,      645,      660,  2288059,        0
divcb:                    336,    33792,        1,       32,        2,        0
g_shsec_zone:          131072,     3200,        0,        0,        0,        0
g_stripe_zone:         131072,     3200,        0,        0,        0,        0
selfd:                     56,        0,      545,      400, 146835784,        0
SWAPMETA:                 288,   116519,        7,       32,        7,        0
Mountpoints:              752,        0,        8,        7,       10,        0
FFS inode:                168,        0,     5089,    12379,   258762,        0
FFS1 dinode:              128,        0,        0,        0,        0,        0
FFS2 dinode:              256,        0,     5089,     8801,   258759,        0
NetFlow cache:             80,   262160,      264,      635,   338533,        0


------------------------------------------------------------------------
vmstat -i

interrupt                          total       rate
irq16: atapci0++                  497328          5
irq18: ohci2 ohci+                     5          0
irq20: vr0                      34736093        389
irq21: vr1                       7651334         85
irq22: atapci1                   8414069         94
cpu0: timer                    105979207       1187
irq256: re0                      6203960         69
cpu1: timer                    105978762       1187
Total                          269460758       3020

------------------------------------------------------------------------
pstat -T

19961/65536 files
0M/16383M swap space

------------------------------------------------------------------------
pstat -s

Device          1K-blocks     Used    Avail Capacity
/dev/ad6s1b      16777088       28 16777060     0%

------------------------------------------------------------------------
iostat

iostat: kvm_read(_tk_nin): invalid address (0x0)
iostat: disabling TTY statistics
iostat: kvm_getcptime: invalid address (0x0)
iostat: disabling CPU time statistics
             md0              ad6              ad8 
  KB/t tps  MB/s   KB/t tps  MB/s   KB/t tps  MB/s 
  1.27   0  0.00  26.04   6  0.14  26.08  15  0.37 

------------------------------------------------------------------------
ipcs -a

Message Queues:
T           ID          KEY MODE        OWNER    GROUP    CREATOR  CGROUP                 CBYTES                 QNUM               QBYTES        LSPID        LRPID STIME    RTIME    CTIME   

Shared Memory:
T           ID          KEY MODE        OWNER    GROUP    CREATOR  CGROUP         NATTCH        SEGSZ         CPID         LPID ATIME    DTIME    CTIME   
m        65536            0 --rw------- root     wheel    root     wheel              12       524288         1950         1950  3:44:19 18:20:30  3:44:19

Semaphores:
T           ID          KEY MODE        OWNER    GROUP    CREATOR  CGROUP          NSEMS OTIME    CTIME   


------------------------------------------------------------------------
ipcs -T

msginfo:
	msgmax:        32784	(max characters in a message)
	msgmni:           41	(# of message queues)
	msgmnb:         2049	(max characters in a message queue)
	msgtql:           41	(max # of messages in system)
	msgssz:           16	(size of a message segment)
	msgseg:         2049	(# of message segments in system)

shminfo:
	shmmax:      8388608	(max shared memory segment size)
	shmmin:            2	(min shared memory segment size)
	shmmni:           33	(max number of shared memory identifiers)
	shmseg:            9	(max shared memory segments per process)
	shmall:         2048	(max amount of shared memory in pages)

seminfo:
	semmap:           31	(# of entries in semaphore map)
	semmni:           11	(# of semaphore identifiers)
	semmns:           61	(# of semaphores in system)
	semmnu:           31	(# of undo structures in system)
	semmsl:           61	(max # of semaphores per id)
	semopm:          101	(max # of operations per semop call)
	semume:           11	(max # of undo entries per process)
	semusz:          160	(size in bytes of undo structure)
	semvmx:        32767	(semaphore maximum value)
	semaem:        16384	(adjust on exit max value)


------------------------------------------------------------------------
nfsstat

Client Info:
Rpc Counts:
  Getattr   Setattr    Lookup  Readlink      Read     Write    Create    Remove
        0         0         0         0         0         0         0         0
   Rename      Link   Symlink     Mkdir     Rmdir   Readdir  RdirPlus    Access
        0         0         0         0         0         0         0         0
    Mknod    Fsstat    Fsinfo  PathConf    Commit
        0         0         0         0         0
Rpc Info:
 TimedOut   Invalid X Replies   Retries  Requests
        0         0         0         0         0
Cache Info:
Attr Hits    Misses Lkup Hits    Misses BioR Hits    Misses BioW Hits    Misses
        0         0         0         0         0         0         0         0
BioRLHits    Misses BioD Hits    Misses DirE Hits    Misses
        0         0         0         0         0         0

Server Info:
  Getattr   Setattr    Lookup  Readlink      Read     Write    Create    Remove
        0         0         0         0         0         0         0         0
   Rename      Link   Symlink     Mkdir     Rmdir   Readdir  RdirPlus    Access
        0         0         0         0         0         0         0         0
    Mknod    Fsstat    Fsinfo  PathConf    Commit
        0         0         0         0         0
Server Ret-Failed
                0
Server Faults
            0
Server Cache Stats:
   Inprog      Idem  Non-idem    Misses
        0         0         0         0
Server Write Gathering:
 WriteOps  WriteRPC   Opsaved
        0         0         0

------------------------------------------------------------------------
netstat -s

tcp:
	31314668 packets sent
		21225719 data packets (28312857376 bytes)
		5836005 data packets (8142721842 bytes) retransmitted
		147692 data packets unnecessarily retransmitted
		14 resends initiated by MTU discovery
		3448705 ack-only packets (739873 delayed)
		0 URG only packets
		1004 window probe packets
		191749 window update packets
		612139 control packets
	19243743 packets received
		10912612 acks (for 28298020208 bytes)
		3956102 duplicate acks
		90 acks for unsent data
		4756804 packets (3502751830 bytes) received in-sequence
		80063 completely duplicate packets (5393792 bytes)
		437 old duplicate packets
		4543 packets with some dup. data (474716 bytes duped)
		25377 out-of-order packets (24303887 bytes)
		14 packets (0 bytes) of data after window
		0 window probes
		263486 window update packets
		1677 packets received after close
		347 discarded for bad checksums
		0 discarded for bad header offset fields
		0 discarded because packet too short
		23 discarded due to memory problems
	337478 connection requests
	103492 connection accepts
	133 bad connection attempts
	0 listen queue overflows
	2788 ignored RSTs in the windows
	298020 connections established (including accepts)
	441305 connections closed (including 8773 drops)
		131750 connections updated cached RTT on close
		134550 connections updated cached RTT variance on close
		67713 connections updated cached ssthresh on close
	40093 embryonic connections dropped
	7944361 segments updated rtt (of 8091867 attempts)
	3131465 retransmit timeouts
		2047 connections dropped by rexmit timeout
	1342 persist timeouts
		1 connection dropped by persist timeout
	0 Connections (fin_wait_2) dropped because of timeout
	200 keepalive timeouts
		0 keepalive probes sent
		200 connections dropped by keepalive
	574449 correct ACK header predictions
	3396753 correct data packet header predictions
	149489 syncache entries added
		85748 retransmitted
		38546 dupsyn
		0 dropped
		103492 completed
		0 bucket overflow
		0 cache overflow
		26123 reset
		19641 stale
		0 aborted
		0 badack
		213 unreach
		0 zone failures
	149489 cookies sent
	5 cookies received
	655017 SACK recovery episodes
	1222348 segment rexmits in SACK recovery episodes
	1716303971 byte rexmits in SACK recovery episodes
	4793281 SACK options (SACK blocks) received
	28930 SACK options (SACK blocks) sent
	0 SACK scoreboard overflow
	0 packets with ECN CE bit set
	0 packets with ECN ECT(0) bit set
	0 packets with ECN ECT(1) bit set
	0 successful ECN handshakes
	0 times ECN reduced the congestion window
udp:
	493508 datagrams received
	0 with incomplete header
	0 with bad data length field
	3193 with bad checksum
	9183 with no checksum
	72368 dropped due to no socket
	22081 broadcast/multicast datagrams undelivered
	0 dropped due to full socket buffers
	0 not for hashed pcb
	395866 delivered
	380952 datagrams output
	0 times multicast source filter matched
ip:
	24528581 total packets received
	28 bad header checksums
	0 with size smaller than minimum
	0 with data size < data length
	0 with ip length > max ip packet size
	0 with header length < data size
	0 with data length < header length
	0 with bad options
	1 with incorrect version number
	30 fragments received
	0 fragments dropped (dup or out of space)
	8 fragments dropped after timeout
	11 packets reassembled ok
	19806237 packets for this host
	248666 packets for unknown/unsupported protocol
	529420 packets forwarded (0 packets fast forwarded)
	5060 packets not forwardable
	0 packets received for unknown multicast group
	0 redirects sent
	32289815 packets sent from this host
	10382 packets sent with fabricated ip header
	2164 output packets dropped due to no bufs, etc.
	0 output packets discarded due to no route
	1 output datagram fragmented
	2 fragments created
	0 datagrams that can't be fragmented
	0 tunneling packets that can't find gif
	0 datagrams with bad address in header
icmp:
	72376 calls to icmp_error
	0 errors not generated in response to an icmp message
	Output histogram:
		echo reply: 469
		destination unreachable: 72375
		time exceeded: 1
	0 messages with bad code fields
	0 messages less than the minimum length
	546 messages with bad checksum
	0 messages with bad length
	4 multicast echo requests ignored
	0 multicast timestamp requests ignored
	Input histogram:
		echo reply: 2968
		destination unreachable: 47235
		source quench: 1488
		routing redirect: 186
		echo: 473
		time exceeded: 5502
	469 message responses generated
	0 invalid return addresses
	1 no return route
igmp:
	248102 messages received
	0 messages received with too few bytes
	0 messages received with wrong TTL
	0 messages received with bad checksum
	36098 V1/V2 membership queries received
	455 V3 membership queries received
	0 membership queries received with invalid field(s)
	338 general queries received
	36215 group queries received
	0 group-source queries received
	0 group-source queries dropped
	0 membership reports received
	0 membership reports received with invalid field(s)
	0 membership reports received for groups to which we belong
	147 V3 reports received without Router Alert
	0 membership reports sent
pim:
	0 messages received
	0 bytes received
	0 messages received with too few bytes
	0 messages received with bad checksum
	0 messages received with bad version
	0 data register messages received
	0 data register bytes received
	0 data register messages received on wrong iif
	0 bad registers received
	0 data register messages sent
	0 data register bytes sent
carp:
	0 packets received (IPv4)
	0 packets received (IPv6)
		0 packets discarded for wrong TTL
		0 packets shorter than header
		0 discarded for bad checksums
		0 discarded packets with a bad version
		0 discarded because packet too short
		0 discarded for bad authentication
		0 discarded for bad vhid
		0 discarded because of a bad address list
	0 packets sent (IPv4)
	0 packets sent (IPv6)
		0 send failed due to mbuf memory error
pfsync:
	0 packets received (IPv4)
	0 packets received (IPv6)
		0 packets discarded for bad interface
		0 packets discarded for bad ttl
		0 packets shorter than header
		0 packets discarded for bad version
		0 packets discarded for bad HMAC
		0 packets discarded for bad action
		0 packets discarded for short packet
		0 states discarded for bad values
		0 stale states
		0 failed state lookup/inserts
	0 packets sent (IPv4)
	0 packets sent (IPv6)
		0 send failed due to mbuf memory error
		0 send error
ip6:
	12188 total packets received
	0 with size smaller than minimum
	0 with data size < data length
	0 with bad options
	0 with incorrect version number
	0 fragments received
	0 fragments dropped (dup or out of space)
	0 fragments dropped after timeout
	0 fragments that exceeded limit
	0 packets reassembled ok
	11389 packets for this host
	799 packets forwarded
	0 packets not forwardable
	0 redirects sent
	15780 packets sent from this host
	0 packets sent with fabricated ip header
	0 output packets dropped due to no bufs, etc.
	6 output packets discarded due to no route
	0 output datagrams fragmented
	0 fragments created
	0 datagrams that can't be fragmented
	0 packets that violated scope rules
	10 multicast packets which we don't join
	Input histogram:
		hop by hop: 7
		TCP: 178
		UDP: 1484
		ICMP6: 10519
	Mbuf statistics:
		7118 one mbuf
		5070 one ext mbuf
		0 two or more ext mbuf
	0 packets whose headers are not continuous
	0 tunneling packets that can't find gif
	0 packets discarded because of too many headers
	0 failures of source address selection
	Source addresses selection rule applied:
		15380 first candidate
		15 same address
		13537 outgoing interface
icmp6:
	562 calls to icmp6_error
	0 errors not generated in response to an icmp6 message
	0 errors not generated because of rate limitation
	Output histogram:
		unreach: 562
		echo: 10332
		router advertisement: 142
		neighbor solicitation: 3235
		MLDv2 listener report: 8
	0 messages with bad code fields
	0 messages < minimum length
	0 bad checksums
	0 messages with bad length
	Input histogram:
		unreach: 6
		time exceed: 4743
		echo reply: 3500
		router solicitation: 6
		router advertisement: 142
		neighbor advertisement: 1535
	Histogram of error messages to be generated:
		0 no route
		0 administratively prohibited
		0 beyond scope
		562 address unreachable
		0 port unreachable
		0 packet too big
		0 time exceed transit
		0 time exceed reassembly
		0 erroneous header field
		0 unrecognized next header
		0 unrecognized option
		0 redirect
		0 unknown
	0 message responses generated
	0 messages with too many ND options
	0 messages with bad ND options
	0 bad neighbor solicitation messages
	0 bad neighbor advertisement messages
	0 bad router solicitation messages
	0 bad router advertisement messages
	0 bad redirect messages
	0 path MTU changes
rip6:
	0 messages received
	0 checksum calculations on inbound
	0 messages with bad checksum
	0 messages dropped due to no socket
	0 multicast messages dropped due to no socket
	0 messages dropped due to full socket buffers
	0 delivered
	0 datagrams output

------------------------------------------------------------------------
netstat -m

3263/1284/4547 mbufs in use (current/cache/total)
437/823/1260/33792 mbuf clusters in use (current/cache/total/max)
748/587 mbuf+clusters out of packet secondary zone in use (current/cache)
1934/519/2453/16896 4k (page size) jumbo clusters in use (current/cache/total/max)
0/0/0/25344 9k jumbo clusters in use (current/cache/total/max)
0/0/0/16896 16k jumbo clusters in use (current/cache/total/max)
9425K/4043K/13468K bytes allocated to network (current/cache/total)
0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters)
0/0/0 requests for jumbo clusters denied (4k/9k/16k)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
0 calls to protocol drain routines

------------------------------------------------------------------------
netstat -id

Name    Mtu Network       Address              Ipkts Ierrs    Opkts Oerrs  Coll Drop
re0    1500 <Link#1>      00:e0:4d:7b:69:0c  3745007     0  5334114     0     0    0 
re0    1500 10.0.0.0      otrada.local       3535942     -  5148440     -     -    - 
re0    1500 2001:5c0:1503 2001:5c0:1503:340        0     -     1828     -     -    - 
vr0    1500 <Link#2>      00:11:95:ff:a7:c0 13512626     0 22240854     0     0    0 
vr1    1500 <Link#3>      00:02:44:8b:89:40  3041154     0  4706644     0     0    0 
vr1    1500 192.168.60.0/ 192.168.60.194       49217     -    26603     -     -    - 
lo0   16384 <Link#4>                          551881     0   551882     0     0    0 
lo0   16384 fe80:4::1     fe80:4::1                0     -        0     -     -    - 
lo0   16384 localhost     ::1                      0     -        4     -     -    - 
lo0   16384 your-net      localhost           227952     -   551878     -     -    - 
pfsyn  1460 <Link#5>                               0     0        0     0     0    0 
pflog 33152 <Link#6>                               0     0        0     0     0    0 
tun1   1492 <Link#7>                        13476852     0 22232049     0     0 2164 
tun1   1492 89.209.81.54/ otrada.od.ua      13486297     - 21900597     -     -    - 
tun2   1492 <Link#8>                         2488245     0  4671095     0     0    0 
tun2   1492 188.115.128.3 188-115-128-3.bro  2481576     -  4671093     -     -    - 
gif0   1280 <Link#9>                           12031     0    13936     0     0    0 
gif0   1280 universite.br 2001:5c0:1400:b::        0     -    13933     -     -    - 

------------------------------------------------------------------------
netstat -anr

Routing tables

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            89.209.95.254      UGS         0 22561291   tun1
10.0.0.0/24        link#1             U           0  5332189    re0 =>
10.0.0.0/8         192.168.61.250     UGS         0    14425    vr1
10.0.0.1           link#4             UHS         0   141038    lo0
62.16.0.0/19       tun2               US          0     1946   tun2
64.12.0.0/16       tun2               US          0       33   tun2
64.151.123.78      tun2               UHS         0        0   tun2
74.63.32.0/19      tun2               US          0     1451   tun2
77.91.192.0/21     tun2               US          0     2181   tun2
77.176.0.0/12      tun2               US          0     2377   tun2
77.241.34.0/24     tun2               US          0      626   tun2
78.25.32.0/22      tun2               US          0      111   tun2
78.36.0.0/15       tun2               US          0  1123494   tun2
78.48.0.0/13       tun2               US          0    37596   tun2
78.106.0.0/15      tun2               US          0   257759   tun2
79.135.128.0/19    tun2               US          0       29   tun2
79.140.0.0/20      tun2               US          0    13048   tun2
80.93.176.0/20     tun2               US          0      347   tun2
81.25.224.0/24     tun2               US          0      113   tun2
81.25.225.0/24     tun2               US          0       18   tun2
83.237.0.0/16      tun2               US          0    58313   tun2
83.239.32.0/19     tun2               US          0     5400   tun2
84.32.240.0/21     tun2               US          0        4   tun2
84.58.0.0/16       tun2               US          0      282   tun2
85.21.0.0/16       tun2               US          0    11867   tun2
85.30.224.0/20     tun2               US          0      669   tun2
85.140.0.0/15      tun2               US          0   339329   tun2
85.159.0.0/21      tun2               US          0      158   tun2
85.176.0.0/13      tun2               US          0   155342   tun2
85.238.96.0/19     tun2               US          0   619791   tun2
86.57.128.0/17     tun2               US          0   103035   tun2
87.249.56.0/24     tun2               US          0      574   tun2
89.110.0.0/18      tun2               US          0     7147   tun2
89.163.0.0/17      tun2               US          0    46730   tun2
89.179.72.0/21     tun2               US          0      469   tun2
89.209.81.54       link#4             UHS         0   167210    lo0
89.218.0.0/16      tun2               US          0    14139   tun2
89.239.128.0/18    tun2               US          0      958   tun2
90.151.16.0/20     tun2               US          0    33325   tun2
91.76.0.0/14       tun2               US          0   727745   tun2
92.112.0.0/15      tun2               US          0   552598   tun2
127.0.0.1          link#4             UH          0   227952    lo0
159.148.0.0/16     tun2               US          0     1511   tun2
188.115.128.3      link#4             UHS         0    15261    lo0
192.168.0.0/16     192.168.61.250     UGS         0     3630    vr1
192.168.60.0/23    link#3             U           0      116    vr1
192.168.60.194     link#4             UHS         0      417    lo0
192.168.152.0/24   10.0.0.20          UGS         0        0    re0
193.22.84.0/24     tun2               US          0        0   tun2
194.44.30.0/24     tun2               US          0        0   tun2
194.204.0.0/19     tun2               US          0        1   tun2
195.66.192.0/19    tun2               US          0       70   tun2
195.72.156.0/22    tun2               US          0      280   tun2
195.114.128.0/19   tun2               US          0       82   tun2
195.138.64.0/19    tun2               US          0     6126   tun2
195.138.68.88/29   192.168.61.250     UGS         0        0    vr1
195.138.78.64/28   192.168.61.250     UGS         0      270    vr1
195.138.80.24/32   192.168.61.250     UGS         0        0    vr1
195.138.80.33/32   192.168.61.250     UGS         0     8237    vr1
195.138.80.40/32   192.168.61.250     UGS         0        0    vr1
195.138.80.50/32   192.168.61.250     UGS         0        0    vr1
195.138.80.54/32   192.168.61.250     UGS         0        0    vr1
195.138.80.175     link#8             UHS         0        0   tun2
208.93.0.0/22      tun2               US          0     6122   tun2
208.113.64.0/18    tun1               US          0        0   tun1
212.178.0.0/19     tun2               US          0   407962   tun2
212.220.64.0/18    tun2               US          0     1087   tun2
213.87.61.0/24     tun2               US          0        0   tun2
213.171.32.0/19    tun2               US          0     9475   tun2
217.224.0.0/11     tun2               US          0   129756   tun2

Internet6:
Destination                       Gateway                       Flags      Netif Expire
default                           2001:5c0:1400:b::27e8         UGS        gif0
::1                               ::1                           UH          lo0
2001:5c0:1400:b::27e8             2001:5c0:1400:b::27e9         UH         gif0
2001:5c0:1503:3400::/64           link#1                        U           re0 =>
2001:5c0:1503:3400::/56           lo0                           US          lo0
2001:5c0:1503:3400::1             link#1                        UHS         lo0
fe80::%lo0/64                     link#4                        U           lo0
fe80::1%lo0                       link#4                        UHS         lo0
ff01:1::/32                       2001:5c0:1503:3400::1         U           re0
ff01:4::/32                       fe80::1%lo0                   U           lo0
ff01:9::/32                       2001:5c0:1400:b::27e9         U          gif0
ff02::%re0/32                     2001:5c0:1503:3400::1         U           re0
ff02::%lo0/32                     fe80::1%lo0                   U           lo0
ff02::%gif0/32                    2001:5c0:1400:b::27e9         U          gif0

------------------------------------------------------------------------
netstat -anA

Active Internet connections (including servers)
Tcpcb    Proto Recv-Q Send-Q  Local Address      Foreign Address   (state)
ffffff01251aa370 tcp4       0      0 89.209.81.54.80    89.209.81.54.16617 ESTABLISHED
ffffff0044aa5000 tcp4       0      0 89.209.81.54.16617 89.209.81.54.80    ESTABLISHED
ffffff00a7e6fa50 tcp4       0      0 10.0.0.1.3128      10.0.0.10.2379     ESTABLISHED
ffffff01251936e0 tcp4       0      0 89.209.81.54.80    89.209.81.54.16616 ESTABLISHED
ffffff00461b4000 tcp4       0      0 89.209.81.54.16616 89.209.81.54.80    ESTABLISHED
ffffff01251e16e0 tcp4       0      0 10.0.0.1.3128      10.0.0.10.2378     ESTABLISHED
ffffff0005ad6a68 tcp4       0      0 89.209.81.54.80    89.209.81.54.16615 TIME_WAIT
ffffff010070a000 tcp4       0   1781 10.0.0.1.3128      10.0.0.10.2377     FIN_WAIT_1
ffffff01252553f0 tcp4       0      0 89.209.81.54.80    89.209.81.54.16614 TIME_WAIT
ffffff004492b000 tcp4       0   1622 10.0.0.1.3128      10.0.0.10.2376     FIN_WAIT_1
ffffff018d89b000 tcp4       0      0 89.209.81.54.80    89.209.81.54.16613 ESTABLISHED
ffffff01250ada50 tcp4       0      0 89.209.81.54.16613 89.209.81.54.80    ESTABLISHED
ffffff00058bc750 tcp4       0      0 89.209.81.54.80    89.209.81.54.16612 TIME_WAIT
ffffff00c9b3e370 tcp4       0      0 10.0.0.1.3128      10.0.0.10.2375     ESTABLISHED
ffffff004faad000 tcp4       0    657 10.0.0.1.3128      10.0.0.10.2374     ESTABLISHED
ffffff012525da20 tcp4       0      0 89.209.81.54.80    89.209.81.54.16611 TIME_WAIT
ffffff012525d5e8 tcp4       0      0 10.0.0.1.3128      10.0.0.10.2373     TIME_WAIT
ffffff0125100a50 tcp4       0      0 10.0.0.1.3128      10.0.0.10.2372     ESTABLISHED
ffffff01251356e0 tcp4       0      0 89.209.81.54.80    89.209.81.54.16610 FIN_WAIT_2
ffffff012511ba50 tcp4       0      0 89.209.81.54.16610 89.209.81.54.80    CLOSE_WAIT
ffffff012526bab0 tcp4       0      0 10.0.0.1.3128      10.0.0.10.2371     TIME_WAIT
ffffff0124b25a50 tcp4      68      0 89.209.81.54.6933  95.133.214.208.496 ESTABLISHED
ffffff0055ce2a50 tcp4      68      0 89.209.81.54.6933  95.134.217.100.249 ESTABLISHED
ffffff012519aa50 tcp4      68      0 89.209.81.54.6933  94.26.169.67.53619 ESTABLISHED
ffffff0125255ab0 tcp4       0      0 89.209.81.54.80    89.209.81.54.16609 TIME_WAIT
ffffff012526c5e8 tcp4       0      0 10.0.0.1.3128      10.0.0.10.2369     TIME_WAIT
ffffff01252625e8 tcp4       0      0 89.209.81.54.6933  84.240.25.169.2004 TIME_WAIT
ffffff0005ad6438 tcp4       0      0 10.0.0.1.16608     10.0.0.1.80        TIME_WAIT
ffffff0125262b88 tcp4       0      0 127.0.0.1.16607    127.0.0.1.3306     TIME_WAIT
ffffff004fd611f8 tcp4       0      0 127.0.0.1.16606    127.0.0.1.3306     TIME_WAIT
ffffff0125255900 tcp4       0      0 127.0.0.1.16605    127.0.0.1.53       TIME_WAIT
ffffff01252551b0 tcp4       0      0 127.0.0.1.16604    127.0.0.1.21       TIME_WAIT
ffffff012526bd80 tcp4       0      0 10.0.0.1.16603     10.0.0.1.3128      TIME_WAIT
ffffff0125242a20 tcp4       0      0 127.0.0.1.16602    127.0.0.1.22       TIME_WAIT
ffffff0125255bd0 tcp4       0      0 89.209.81.54.6933  78.152.188.22.4324 TIME_WAIT
ffffff01252740d8 tcp4       0      0 89.209.81.54.6933  217.15.199.58.6410 TIME_WAIT
ffffff0125274b40 tcp4       0      0 89.209.81.54.6933  188.186.21.209.393 TIME_WAIT
ffffff00a75dfaf8 tcp4       0      0 89.209.81.54.6933  77.123.96.38.4389  TIME_WAIT
ffffff0125262168 tcp4       0      0 89.209.81.54.6933  217.15.199.58.6017 TIME_WAIT
ffffff0125242438 tcp4       0      0 89.209.81.54.6933  80.66.242.109.2077 TIME_WAIT
ffffff012526c828 tcp4       0      0 89.209.81.54.6933  89.209.81.54.16601 TIME_WAIT
ffffff004feb7a50 tcp4       0      0 89.209.81.54.6933  87.119.235.230.159 ESTABLISHED
ffffff00a7e70370 tcp4       0    339 89.209.81.54.16600 195.82.146.120.80  ESTABLISHED
ffffff012525dc60 tcp4       0      0 89.209.81.54.6933  95.53.144.113.1160 TIME_WAIT
ffffff004fd619d8 tcp4       0      0 89.209.81.54.6933  94.26.169.67.52894 TIME_WAIT
ffffff00058bb9d8 tcp4       0      0 89.209.81.54.6933  95.134.217.100.236 TIME_WAIT
ffffff01252f3318 tcp4       0      0 89.209.81.54.6933  89.235.215.222.345 TIME_WAIT
ffffff0125255cf0 tcp4       0      0 89.209.81.54.6933  217.15.199.58.6296 TIME_WAIT
ffffff012526c438 tcp4       0      0 89.209.81.54.6933  78.152.188.22.4193 TIME_WAIT
ffffff004fd61480 tcp4       0      0 89.209.81.54.6933  77.123.96.38.4307  TIME_WAIT
ffffff0125255090 tcp4       0      0 89.209.81.54.6933  188.186.21.209.378 TIME_WAIT
ffffff012525d318 tcp4       0      0 89.209.81.54.6933  217.15.199.58.5952 TIME_WAIT
ffffff0125275048 tcp4       0      0 89.209.81.54.16599 195.82.146.120.80  TIME_WAIT
ffffff0125275750 tcp4       0      0 188.115.128.3.1659 92.112.23.19.12952 TIME_WAIT
ffffff012526b798 tcp4       0      0 89.209.81.54.16596 94.25.214.84.36881 TIME_WAIT
ffffff0125262438 tcp4       0      0 89.209.81.54.16594 86.62.109.82.17314 TIME_WAIT
ffffff01251b2000 tcp4       0     68 89.209.81.54.16592 85.232.125.21.3696 ESTABLISHED
ffffff012525d558 tcp4       0      0 89.209.81.54.16591 89.252.36.150.5337 TIME_WAIT
ffffff01252f3c60 tcp4       0      0 89.209.81.54.16590 79.173.85.125.3405 TIME_WAIT
ffffff00058bc3a8 tcp4       0      0 89.209.81.54.16589 212.98.191.230.292 TIME_WAIT
ffffff00a75df3a8 tcp4       0      0 188.115.128.3.1658 80.93.186.90.50924 TIME_WAIT
ffffff012511a6e0 tcp4       0      0 89.209.81.54.16587 79.181.9.29.2087   SYN_SENT
ffffff0055ce2370 tcp4       0      0 89.209.81.54.16586 85.249.72.117.6279 SYN_SENT
ffffff00058bc168 tcp4       0      0 89.209.81.54.16585 77.37.131.104.5782 TIME_WAIT
ffffff01252750d8 tcp4       0      0 89.209.81.54.16584 24.16.28.93.12721  TIME_WAIT
ffffff01252f34c8 tcp4       0      0 89.209.81.54.16583 79.111.160.81.5318 TIME_WAIT
ffffff004fd30370 tcp4       0      0 188.115.128.3.1658 85.140.55.229.2175 SYN_SENT
ffffff01250ed000 tcp4       0      0 89.209.81.54.16581 88.84.200.2.19956  SYN_SENT
ffffff0124b26a50 tcp4       0      0 89.209.81.54.16580 95.221.47.205.6283 SYN_SENT
ffffff004fd61510 tcp4       0      0 89.209.81.54.16574 92.255.207.69.4762 TIME_WAIT
ffffff004fd61d80 tcp4       0      0 89.209.81.54.16573 92.124.107.43.1385 TIME_WAIT
ffffff00a75df798 tcp4       0      0 89.209.81.54.16572 78.60.101.130.6149 TIME_WAIT
ffffff00058bc090 tcp4       0      0 89.209.81.54.16571 95.72.48.140.63780 TIME_WAIT
ffffff00649de370 tcp4       0      0 89.209.81.54.16568 194.150.140.176.64 SYN_SENT
ffffff01250dfa50 tcp4       0      0 89.209.81.54.16566 93.185.185.10.1908 SYN_SENT
ffffff01251c36e0 tcp4       0      0 89.209.81.54.16565 195.189.80.52.4931 SYN_SENT
ffffff012511f370 tcp4       0      0 89.209.81.54.16564 82.193.97.145.4227 SYN_SENT
ffffff01252757e0 tcp4       0      0 89.209.81.54.16563 94.188.49.183.5141 TIME_WAIT
ffffff0063de56e0 tcp4       0      0 89.209.81.54.16562 90.190.29.43.113   SYN_SENT
ffffff012516f6e0 tcp4       0      0 89.209.81.54.16559 85.113.158.57.5555 SYN_SENT
ffffff015240a6e0 tcp4       0      0 89.209.81.54.16558 94.41.28.210.18543 SYN_SENT
ffffff004fd93000 tcp4       0      0 89.209.81.54.16557 212.55.66.111.5916 SYN_SENT
ffffff012525d990 tcp4       0      0 89.209.81.54.16555 77.247.167.241.303 TIME_WAIT
ffffff004b94d6e0 tcp4       0      0 89.209.81.54.16550 91.122.46.47.40224 SYN_SENT
ffffff004fd61b88 tcp4       0      0 89.209.81.54.16549 79.165.217.24.3836 TIME_WAIT
ffffff01252744c8 tcp4       0      0 188.115.128.3.1654 78.107.237.146.304 TIME_WAIT
ffffff012525d240 tcp4       0      0 89.209.81.54.6933  89.209.81.54.16546 TIME_WAIT
ffffff004fd7c370 tcp4       0      0 89.209.81.54.16547 79.194.89.219.1977 SYN_SENT
ffffff0124b236e0 tcp4       0      0 89.209.81.54.16545 212.45.15.2.22095  SYN_SENT
ffffff0005ad63a8 tcp4       0      0 89.209.81.54.16542 95.104.72.82.40972 TIME_WAIT
ffffff00058bc480 tcp4       0      0 89.209.81.54.16540 79.164.91.168.4549 TIME_WAIT
ffffff00a75dfd38 tcp4       0      0 89.209.81.54.16539 85.174.20.150.5352 TIME_WAIT
ffffff017bd466e0 tcp4       0      0 89.209.81.54.16537 94.25.8.222.27027  SYN_SENT
ffffff01251b9370 tcp4       0      0 89.209.81.54.16536 79.120.120.132.496 SYN_SENT
ffffff0125190370 tcp4       0      0 89.209.81.54.16534 93.153.159.172.252 SYN_SENT
ffffff012512b370 tcp4       0      0 89.209.81.54.16533 86.62.105.17.38040 SYN_SENT
ffffff004fd7c000 tcp4       0      0 89.209.81.54.16531 89.169.111.105.161 SYN_SENT
ffffff00058bb3f0 tcp4       0      0 89.209.81.54.16530 213.154.192.106.47 TIME_WAIT
ffffff0126befa50 tcp4       0      0 89.209.81.54.16528 193.111.246.28.80  ESTABLISHED
ffffff00a75df0d8 tcp4       0      0 89.209.81.54.16527 81.21.247.109.3336 TIME_WAIT
ffffff01252f3288 tcp4       0      0 89.209.81.54.16526 62.122.70.6.63789  TIME_WAIT
ffffff012515a000 tcp4       0      0 89.209.81.54.16525 95.52.115.84.22666 SYN_SENT
ffffff01250c7a50 tcp4       0      0 188.115.128.3.1652 85.140.65.243.1804 LAST_ACK
ffffff0125262798 tcp4       0      0 89.209.81.54.16522 95.25.75.153.10102 TIME_WAIT
ffffff0152409370 tcp4       0      0 89.209.81.54.16520 77.239.239.140.175 SYN_SENT
ffffff00a7e6e370 tcp4       0      0 89.209.81.54.16519 79.139.158.150.554 SYN_SENT
ffffff004fd7d000 tcp4       0      0 89.209.81.54.16514 94.25.72.111.26616 SYN_SENT
ffffff01250d7370 tcp4       0      0 89.209.81.54.16513 95.133.78.182.2905 SYN_SENT
ffffff00058bc000 tcp4       0      0 89.209.81.54.16512 78.94.93.143.13344 TIME_WAIT
ffffff00bb5b1a50 tcp4       0      0 89.209.81.54.16510 94.198.0.10.54456  SYN_SENT
ffffff0125188000 tcp4       0      0 188.115.128.3.1650 78.37.114.241.6383 SYN_SENT
ffffff0005ad6120 tcp4       0      0 188.115.128.3.1650 89.163.114.143.688 TIME_WAIT
ffffff01884df000 tcp4       0      0 89.209.81.54.16507 82.193.97.81.41753 SYN_SENT
ffffff012517c6e0 tcp4     433    114 188.115.128.3.1650 78.36.14.100.51413 ESTABLISHED
ffffff00a75df6c0 tcp4       0      0 89.209.81.54.16504 92.115.35.40.11811 TIME_WAIT
ffffff002c13b370 tcp4       0      0 89.209.81.54.16503 89.191.106.194.185 SYN_SENT
ffffff0062176370 tcp4       0      0 89.209.81.54.16502 94.178.65.89.17049 SYN_SENT
ffffff01252620d8 tcp4       0      0 89.209.81.54.16501 89.112.49.165.2950 TIME_WAIT
ffffff012526bcf0 tcp4       0      0 89.209.81.54.16500 77.236.32.41.36947 TIME_WAIT
ffffff00b5051370 tcp4       0      0 89.209.81.54.16499 82.193.97.139.6197 SYN_SENT
ffffff012516a000 tcp4       0      0 89.209.81.54.16498 62.182.108.6.58360 SYN_SENT
ffffff01251aa6e0 tcp4       0      0 89.209.81.54.16494 90.191.177.151.550 SYN_SENT
ffffff01509e36e0 tcp4       0      0 89.209.81.54.16493 91.202.111.31.5418 SYN_SENT
ffffff0125275510 tcp4       0      0 89.209.81.54.16490 195.189.82.128.151 TIME_WAIT
ffffff005b1906e0 tcp4       0      0 89.209.81.54.16489 89.222.150.42.1212 SYN_SENT
ffffff00a75df2d0 tcp4       0      0 89.209.81.54.16488 85.17.138.135.5141 TIME_WAIT
ffffff01250d4000 tcp4       0      0 188.115.128.3.1648 78.36.178.151.2321 SYN_SENT
ffffff0125255d38 tcp4       0      0 89.209.81.54.16486 85.64.24.140.30871 TIME_WAIT
ffffff0044aa56e0 tcp4       0      0 89.209.81.54.16485 195.91.231.1.47078 SYN_SENT
ffffff0005ad6480 tcp4       0      0 89.209.81.54.16482 77.87.38.119.56727 TIME_WAIT
ffffff01252628b8 tcp4       0      0 89.209.81.54.16481 79.104.195.188.561 TIME_WAIT
ffffff012513e370 tcp4       0      0 89.209.81.54.16480 95.134.87.101.3850 SYN_SENT
ffffff01250dc000 tcp4       0      0 89.209.81.54.16478 188.134.32.248.614 SYN_SENT
ffffff012526c120 tcp4       0      0 89.209.81.54.16476 62.148.128.140.378 TIME_WAIT
ffffff0125274b88 tcp4       0      0 89.209.81.54.6933  89.209.81.54.16474 TIME_WAIT
ffffff012525d6c0 tcp4       0      0 89.209.81.54.16475 87.250.199.63.4273 TIME_WAIT
ffffff004fd61318 tcp4       0      0 89.209.81.54.16472 95.37.157.159.2371 TIME_WAIT
ffffff004fd610d8 tcp4       0      0 89.209.81.54.16471 93.157.18.138.9000 TIME_WAIT
ffffff0125262510 tcp4       0      0 89.209.81.54.16470 83.219.136.126.140 TIME_WAIT
ffffff0064f73000 tcp4       0      0 89.209.81.54.16469 85.113.139.17.5555 SYN_SENT
ffffff01250eca50 tcp4       0      0 89.209.81.54.16468 188.134.32.245.465 SYN_SENT
ffffff01250dc6e0 tcp4       0      0 89.209.81.54.16467 79.120.121.143.222 SYN_SENT
ffffff012525d048 tcp4       0      0 89.209.81.54.16466 188.163.44.226.656 TIME_WAIT
ffffff0158d10000 tcp4       0      0 89.209.81.54.16465 95.30.43.137.47794 SYN_SENT
ffffff0125242d80 tcp4       0      0 89.209.81.54.16462 91.202.160.211.438 TIME_WAIT
ffffff00a75df480 tcp4       0      0 89.209.81.54.16461 77.37.242.173.1328 TIME_WAIT
ffffff0125185370 tcp4       0      0 89.209.81.54.16460 85.254.216.103.514 SYN_SENT
ffffff001f8d36e0 tcp4       0      0 188.115.128.3.1645 92.112.191.43.6327 SYN_SENT
ffffff01252745a0 tcp4       0      0 89.209.81.54.16457 89.222.155.51.5647 TIME_WAIT
ffffff0125274630 tcp4       0      0 89.209.81.54.16456 89.20.129.34.10001 TIME_WAIT
ffffff00b2c65a50 tcp4       0      0 89.209.81.54.16454 195.218.197.16.286 SYN_SENT
ffffff012526c480 tcp4       0      0 188.115.128.3.1645 78.106.111.185.454 TIME_WAIT
ffffff0172656000 tcp4       0      0 188.115.128.3.1645 91.77.8.102.35691  SYN_SENT
ffffff0125255ca8 tcp4       0      0 89.209.81.54.16451 213.79.110.218.455 TIME_WAIT
ffffff00d1b76a50 tcp4       0      0 89.209.81.54.16449 62.220.33.90.33460 SYN_SENT
ffffff00058bb090 tcp4       0      0 188.115.128.3.1644 212.178.26.86.2441 TIME_WAIT
ffffff01250cfa50 tcp4       0      0 89.209.81.54.16447 89.179.201.181.389 SYN_SENT
ffffff012526c8b8 tcp4       0      0 89.209.81.54.6933  89.209.81.54.16445 TIME_WAIT
ffffff012511fa50 tcp4       0      0 188.115.128.3.1644 78.37.63.125.64984 ESTABLISHED
ffffff012526cdc8 tcp4       0      0 89.209.81.54.16443 195.234.110.8.2156 TIME_WAIT
ffffff01250c7000 tcp4       0      0 89.209.81.54.16442 92.243.181.163.123 SYN_SENT
ffffff0125147a50 tcp4       0      0 89.209.81.54.16441 95.26.39.205.18546 SYN_SENT
ffffff0125255828 tcp4       0      0 89.209.81.54.16440 77.37.204.8.59560  TIME_WAIT
ffffff012525d678 tcp4       0      0 89.209.81.54.16439 94.41.36.84.11730  TIME_WAIT
ffffff0125152000 tcp4       0      0 89.209.81.54.16438 94.143.240.205.546 SYN_SENT
ffffff012526b558 tcp4       0      0 89.209.81.54.16437 87.224.239.38.5796 TIME_WAIT
ffffff00058bb750 tcp4       0      0 89.209.81.54.16436 217.27.129.31.1072 TIME_WAIT
ffffff01251c46e0 tcp4       0      0 89.209.81.54.16435 95.32.29.223.46326 SYN_SENT
ffffff01251e0000 tcp4       0      0 89.209.81.54.16434 217.117.112.152.19 SYN_SENT
ffffff0125275708 tcp4       0      0 89.209.81.54.16433 195.5.152.137.4242 TIME_WAIT
ffffff01251856e0 tcp4       0      0 89.209.81.54.16432 194.187.204.55.442 SYN_SENT
ffffff01250ce000 tcp4       0      0 89.209.81.54.16431 91.210.156.13.3862 SYN_SENT
ffffff012526c090 tcp4       0      0 89.209.81.54.16429 93.81.100.1.23456  TIME_WAIT
ffffff00058bcaf8 tcp4       0      0 89.209.81.54.16428 86.62.104.228.3085 TIME_WAIT
ffffff004190b370 tcp4       0      0 89.209.81.54.16427 95.28.193.133.2327 SYN_SENT
ffffff0158d11a50 tcp4       0      0 89.209.81.54.16426 212.92.153.154.443 SYN_SENT
ffffff0125190a50 tcp4       0      0 89.209.81.54.16425 95.32.85.73.16846  SYN_SENT
ffffff01250d1000 tcp4       0      0 89.209.81.54.16424 212.16.19.242.2485 SYN_SENT
ffffff01252626c0 tcp4       0      0 89.209.81.54.16423 93.100.189.52.3681 TIME_WAIT
ffffff0125169370 tcp4       0      0 89.209.81.54.16422 213.21.37.133.1988 SYN_SENT
ffffff01252558b8 tcp4       0      0 89.209.81.54.16421 79.111.41.63.16497 TIME_WAIT
ffffff0005ad6990 tcp4       0      0 89.209.81.54.6933  89.209.81.54.16420 TIME_WAIT
ffffff012525d3a8 tcp4       0      0 89.209.81.54.16419 95.161.9.5.55006   TIME_WAIT
ffffff0125255288 tcp4       0      0 89.209.81.54.16415 91.124.203.171.280 TIME_WAIT
ffffff001cf586e0 tcp4       0      0 188.115.128.3.1641 92.113.180.170.641 SYN_SENT
ffffff012526b828 tcp4       0      0 89.209.81.54.16413 80.237.74.17.59273 TIME_WAIT
ffffff01250ae370 tcp4       0      0 89.209.81.54.16411 94.178.166.200.459 SYN_SENT
ffffff0124b25000 tcp4       0      0 89.209.81.54.16408 91.203.60.217.3289 FIN_WAIT_2
ffffff00a75df558 tcp4       0      0 89.209.81.54.16405 79.104.217.139.564 TIME_WAIT
ffffff0080c656e0 tcp4       0     68 89.209.81.54.16404 80.80.202.190.3099 ESTABLISHED
ffffff012526baf8 tcp4       0      0 89.209.81.54.16401 89.31.115.83.64662 TIME_WAIT
ffffff012526b438 tcp4       0      0 89.209.81.54.16398 80.240.11.212.2115 TIME_WAIT
ffffff01252f3ca8 tcp4       0      0 89.209.81.54.16397 85.175.82.77.18151 TIME_WAIT
ffffff012526c1f8 tcp4       0      0 89.209.81.54.16396 83.99.253.125.5852 TIME_WAIT
ffffff01252551f8 tcp4       0      0 89.209.81.54.16395 94.240.170.21.1859 TIME_WAIT
ffffff01252f3630 tcp4       0      0 89.209.81.54.16394 94.180.242.133.198 TIME_WAIT
ffffff012526b5a0 tcp4       0      0 89.209.81.54.16393 89.209.82.95.15943 TIME_WAIT
ffffff01250cf000 tcp4       0      0 89.209.81.54.16391 212.98.183.163.582 SYN_SENT
ffffff01252f32d0 tcp4       0      0 89.209.81.54.16388 95.67.134.70.22149 TIME_WAIT
ffffff00a75df750 tcp4       0      0 89.209.81.54.16385 84.42.27.45.53711  TIME_WAIT
ffffff00058bc828 tcp4       0      0 89.209.81.54.16384 95.72.151.53.14260 TIME_WAIT
ffffff0125242900 tcp4       0      0 89.209.81.54.16383 92.115.10.188.3485 TIME_WAIT
ffffff0124b2d000 tcp4       0      0 188.115.128.3.1638 89.218.104.111.220 ESTABLISHED
ffffff0124b2e370 tcp4       0      0 89.209.81.54.16380 92.125.225.186.300 SYN_SENT
ffffff01252f3af8 tcp4       0      0 89.209.81.54.16379 91.193.255.123.880 TIME_WAIT
ffffff01252553a8 tcp4       0      0 89.209.81.54.16377 93.81.184.74.53607 TIME_WAIT
ffffff004fd61cf0 tcp4       0      0 89.209.81.54.16375 95.154.138.36.3785 TIME_WAIT
ffffff00058bcc18 tcp4       0      0 188.115.128.3.1637 78.106.107.247.125 TIME_WAIT
ffffff012526ccf0 tcp4       0      0 89.209.81.54.16373 79.126.15.82.6881  TIME_WAIT
ffffff0125275c60 tcp4       0      0 89.209.81.54.16370 87.236.27.47.18810 TIME_WAIT
ffffff012526c708 tcp4       0      0 89.209.81.54.16369 95.25.243.107.4643 TIME_WAIT
ffffff0125274750 tcp4       0      0 89.209.81.54.16368 90.155.173.168.392 TIME_WAIT
ffffff004fd61048 tcp4       0      0 89.209.81.54.6933  89.209.81.54.16366 TIME_WAIT
ffffff00058bb240 tcp4       0      0 89.209.81.54.16367 89.208.82.101.1189 TIME_WAIT
ffffff01252425a0 tcp4       0      0 89.209.81.54.16364 95.134.242.209.534 TIME_WAIT
ffffff01251cfa50 tcp4       0      0 89.209.81.54.16363 91.190.79.131.1316 SYN_SENT
ffffff0005ad65e8 tcp4       0      0 89.209.81.54.16362 95.165.101.48.2980 TIME_WAIT
ffffff0125275b88 tcp4       0      0 89.209.81.54.16360 95.25.249.98.51000 TIME_WAIT
ffffff004fd61948 tcp4       0      0 89.209.81.54.16359 94.27.97.13.38147  TIME_WAIT
ffffff01252621b0 tcp4       0      0 89.209.81.54.16358 80.73.11.179.27022 TIME_WAIT
ffffff012526c168 tcp4       0      0 89.209.81.54.16355 212.192.128.101.40 TIME_WAIT
ffffff0125255510 tcp4       0      0 89.209.81.54.16354 92.62.52.226.25425 TIME_WAIT
ffffff01250de6e0 tcp4       0      0 89.209.81.54.16352 91.124.213.35.1395 SYN_SENT
ffffff012525dd38 tcp4       0      0 89.209.81.54.16351 95.24.38.231.55347 TIME_WAIT
ffffff01250ce6e0 tcp4       0      0 89.209.81.54.16348 92.100.160.190.493 SYN_SENT
ffffff0146dcb6e0 tcp4       0      0 89.209.81.54.16346 138.88.1.25.2701   SYN_SENT
ffffff01250df370 tcp4       0      0 89.209.81.54.16344 79.120.120.70.2319 SYN_SENT
ffffff012526b900 tcp4       0      0 89.209.81.54.16343 90.150.218.227.514 TIME_WAIT
ffffff01252555a0 tcp4       0      0 89.209.81.54.6933  94.26.169.67.52157 TIME_WAIT
ffffff012513e000 tcp4       0    218 89.209.81.54.6933  90.151.224.164.132 ESTABLISHED
ffffff0125242cf0 tcp4       0      0 89.209.81.54.6933  80.66.242.109.2074 TIME_WAIT
ffffff0005ad6c60 tcp4       0      0 89.209.81.54.6933  95.134.217.100.228 TIME_WAIT
ffffff0125274558 tcp4       0      0 10.0.0.1.16342     10.0.0.1.80        TIME_WAIT
ffffff012526b3f0 tcp4       0      0 127.0.0.1.16341    127.0.0.1.3306     TIME_WAIT
ffffff012525d0d8 tcp4       0      0 127.0.0.1.16340    127.0.0.1.3306     TIME_WAIT
ffffff0125262090 tcp4       0      0 127.0.0.1.16339    127.0.0.1.53       TIME_WAIT
ffffff004fd611b0 tcp4       0      0 127.0.0.1.16338    127.0.0.1.21       TIME_WAIT
ffffff00058bbd38 tcp4       0      0 10.0.0.1.16337     10.0.0.1.3128      TIME_WAIT
ffffff0125255c18 tcp4       0      0 127.0.0.1.16336    127.0.0.1.22       TIME_WAIT
ffffff012524b828 tcp4       0      0 89.209.81.54.6933  89.235.215.222.298 TIME_WAIT
ffffff0005ad61f8 tcp4       0      0 89.209.81.54.6933  78.152.188.22.4079 TIME_WAIT
ffffff0125255750 tcp4       0      0 89.209.81.54.6933  217.15.199.58.5630 TIME_WAIT
ffffff01252f3b40 tcp4       0      0 89.209.81.54.6933  95.24.175.116.1500 TIME_WAIT
ffffff01252f37e0 tcp4       0      0 89.209.81.54.6933  91.200.139.216.304 TIME_WAIT
ffffff0005ad6b40 tcp4       0      0 89.209.81.54.6933  77.123.96.38.4222  TIME_WAIT
ffffff012524b948 tcp4       0      0 89.209.81.54.6933  188.186.21.209.360 TIME_WAIT
ffffff00058bc558 tcp4       0      0 89.209.81.54.6933  217.15.199.58.6335 TIME_WAIT
ffffff004fd617e0 tcp4       0      0 89.209.81.54.6933  95.134.217.100.215 TIME_WAIT
ffffff012526b708 tcp4       0      0 89.209.81.54.6933  89.235.215.222.257 TIME_WAIT
ffffff0005ad6510 tcp4       0      0 89.209.81.54.6933  94.26.169.67.50898 TIME_WAIT
ffffff00058bc3f0 tcp4       0      0 89.209.81.54.6933  217.15.199.58.5485 TIME_WAIT
ffffff012525d948 tcp4       0      0 89.209.81.54.6933  78.152.188.22.3965 TIME_WAIT
ffffff01250afa50 tcp4       0  44545 89.209.81.54.6933  93.175.205.45.3136 ESTABLISHED
ffffff012526bb88 tcp4       0      0 89.209.81.54.6933  188.186.21.209.344 TIME_WAIT
ffffff0125242000 tcp4       0      0 89.209.81.54.6933  77.123.96.38.4142  TIME_WAIT
ffffff012526cb88 tcp4       0      0 89.209.81.54.6933  217.15.199.58.6316 TIME_WAIT
ffffff01252629d8 tcp4       0      0 89.209.81.54.6933  92.255.81.187.4346 TIME_WAIT
ffffff00646a6000 tcp4      17 118524 89.209.81.54.6933  81.200.24.143.3451 ESTABLISHED
ffffff01252741b0 tcp4       0      0 89.209.81.54.6933  94.26.169.67.50192 TIME_WAIT
ffffff012525d7e0 tcp4       0      0 89.209.81.54.6933  80.66.242.109.2065 TIME_WAIT
ffffff00058bcd38 tcp4       0      0 89.209.81.54.6933  95.134.217.100.199 TIME_WAIT
ffffff012526c360 tcp4       0      0 10.0.0.1.16335     10.0.0.1.80        TIME_WAIT
ffffff01252f3678 tcp4       0      0 127.0.0.1.3306     127.0.0.1.16334    TIME_WAIT
ffffff012526b948 tcp4       0      0 127.0.0.1.16334    127.0.0.1.3306     TIME_WAIT
ffffff0125242318 tcp4       0      0 127.0.0.1.3306     127.0.0.1.16333    TIME_WAIT
ffffff004fd61a20 tcp4       0      0 127.0.0.1.16333    127.0.0.1.3306     TIME_WAIT
ffffff00a75df7e0 tcp4       0      0 127.0.0.1.16332    127.0.0.1.53       TIME_WAIT
ffffff01252f3828 tcp4       0      0 127.0.0.1.16331    127.0.0.1.21       TIME_WAIT
ffffff0125242120 tcp4       0      0 10.0.0.1.16330     10.0.0.1.3128      TIME_WAIT
ffffff01252f33a8 tcp4       0      0 127.0.0.1.16329    127.0.0.1.22       TIME_WAIT
ffffff012524bdc8 tcp4       0      0 89.209.81.54.6933  89.235.215.222.212 TIME_WAIT
ffffff01252f31f8 tcp4       0      0 89.209.81.54.6933  217.15.199.58.6440 TIME_WAIT
ffffff0125242d38 tcp4       0      0 89.209.81.54.6933  95.24.10.239.56394 TIME_WAIT
ffffff01252741f8 tcp4       0      0 89.209.81.54.6933  78.152.188.22.3841 TIME_WAIT
ffffff012526ca20 tcp4       0      0 89.209.81.54.6933  95.24.10.239.56388 TIME_WAIT
ffffff00058bb510 tcp4       0      0 89.209.81.54.16328 89.189.176.177.230 TIME_WAIT
ffffff012526caf8 tcp4       0      0 188.115.128.3.1632 85.141.115.208.323 TIME_WAIT
ffffff014b98f370 tcp4       0      0 89.209.81.54.16326 94.41.23.135.59919 SYN_SENT
ffffff0125255c60 tcp4       0      0 89.209.81.54.16325 80.252.252.221.281 TIME_WAIT
ffffff004f348000 tcp4       0      0 89.209.81.54.16324 62.33.232.246.2581 SYN_SENT
ffffff0125186000 tcp4       0      0 89.209.81.54.16323 89.19.160.226.6246 SYN_SENT
ffffff00a7e6ea50 tcp4       0      0 89.209.81.54.16321 89.251.68.147.4133 SYN_SENT
ffffff0125242480 tcp4       0      0 89.209.81.54.16320 89.112.111.138.111 TIME_WAIT
ffffff012526b7e0 tcp4       0      0 89.209.81.54.16317 95.79.2.9.35641    TIME_WAIT
ffffff0158d11000 tcp4       0      0 89.209.81.54.16315 95.133.103.57.2272 SYN_SENT
ffffff00ca13f6e0 tcp4       0      0 89.209.81.54.16314 88.205.185.169.558 SYN_SENT
ffffff0125275ab0 tcp4       0      0 89.209.81.54.16313 92.255.152.28.5953 TIME_WAIT
ffffff013ead26e0 tcp4       0      0 89.209.81.54.16312 83.167.112.32.2672 SYN_SENT
ffffff012513c000 tcp4       0      0 89.209.81.54.16311 193.227.97.3.25987 SYN_SENT
ffffff0125100370 tcp4       0      0 89.209.81.54.16310 188.17.216.3.55883 SYN_SENT
ffffff00058bc870 tcp4       0      0 89.209.81.54.16309 92.124.160.104.291 TIME_WAIT
ffffff004fd61990 tcp4       0      0 89.209.81.54.16308 79.172.82.181.2740 TIME_WAIT
ffffff012526b168 tcp4       0      0 89.209.81.54.16307 90.188.39.29.43948 TIME_WAIT
ffffff00058bb3a8 tcp4       0      0 89.209.81.54.16304 89.179.81.34.6891  TIME_WAIT
ffffff01251f5370 tcp4       0      0 89.209.81.54.16303 95.133.199.153.500 SYN_SENT
ffffff00a75df090 tcp4       0      0 89.209.81.54.16302 95.135.41.53.11331 TIME_WAIT
ffffff00a75df948 tcp4       0      0 89.209.81.54.16301 93.133.200.160.610 TIME_WAIT
ffffff0005ad63f0 tcp4       0      0 89.209.81.54.16298 80.73.161.245.6159 TIME_WAIT
ffffff00058bc1b0 tcp4       0      0 89.209.81.54.16297 85.175.103.131.574 TIME_WAIT
ffffff0125275d38 tcp4       0      0 89.209.81.54.16295 84.240.52.219.2592 TIME_WAIT
ffffff012526b3a8 tcp4       0      0 89.209.81.54.16294 92.127.65.128.2684 TIME_WAIT
ffffff004fd61438 tcp4       0      0 89.209.81.54.16293 77.41.59.125.32358 TIME_WAIT
ffffff01252426c0 tcp4       0      0 89.209.81.54.16292 77.66.209.82.42007 TIME_WAIT
ffffff004faac000 tcp4       0      0 89.209.81.54.16291 188.114.5.159.5725 SYN_SENT
ffffff004fd61240 tcp4       0      0 89.209.81.54.16290 77.232.5.242.15660 TIME_WAIT
ffffff002719da50 tcp4       0      0 89.209.81.54.16287 80.92.96.42.36935  SYN_SENT
ffffff012519fa50 tcp4       0      0 188.115.128.3.1628 89.218.24.89.14110 SYN_SENT
ffffff01252f3090 tcp4       0      0 89.209.81.54.16284 94.178.172.122.550 TIME_WAIT
ffffff0125262990 tcp4       0      0 89.209.81.54.16283 95.188.92.0.51001  TIME_WAIT
ffffff0125275990 tcp4       0      0 89.209.81.54.16282 94.178.92.249.5910 TIME_WAIT
ffffff0005ad6870 tcp4       0      0 89.209.81.54.16281 84.52.45.79.22593  TIME_WAIT
ffffff00a75df630 tcp4       0      0 89.209.81.54.6933  77.123.96.38.4059  TIME_WAIT
ffffff0005ad69d8 tcp4       0      0 89.209.81.54.6933  188.186.21.209.328 TIME_WAIT
ffffff012524b8b8 tcp4       0      0 89.209.81.54.6933  80.233.136.74.1370 TIME_WAIT
ffffff0125255d80 tcp4       0      0 89.209.81.54.6933  89.252.15.166.4663 TIME_WAIT
ffffff01252f3bd0 tcp4       0      0 89.209.81.54.6933  217.15.199.58.5133 TIME_WAIT
ffffff00a75df8b8 tcp4       0      0 89.209.81.54.6933  94.26.169.67.49411 TIME_WAIT
ffffff00a75df990 tcp4       0      0 89.209.81.54.6933  81.200.25.206.2284 TIME_WAIT
ffffff01252749d8 tcp4       0      0 89.209.81.54.6933  217.15.199.58.6281 TIME_WAIT
ffffff01252f3b88 tcp4       0      0 89.209.81.54.6933  80.66.242.109.2055 TIME_WAIT
ffffff00a75df000 tcp4       0      0 89.209.81.54.6933  95.134.217.100.185 TIME_WAIT
ffffff012526b510 tcp4       0      0 89.209.81.54.6933  89.235.215.222.168 TIME_WAIT
ffffff01250ed370 tcp4       0  34778 89.209.81.54.6933  89.107.195.113.137 ESTABLISHED
ffffff01252555e8 tcp4       0      0 89.209.81.54.6933  78.152.188.22.3728 TIME_WAIT
ffffff01251336e0 tcp4       0    166 89.209.81.54.16280 98.103.194.136.561 FIN_WAIT_1
ffffff0125274cf0 tcp4       0      0 89.209.81.54.16279 91.124.78.95.19651 TIME_WAIT
ffffff0117e8d370 tcp4       0  31353 89.209.81.54.16276 79.126.48.165.6969 ESTABLISHED
ffffff01252f3240 tcp4       0      0 188.115.128.3.1627 78.106.80.146.1663 TIME_WAIT
ffffff004fd61558 tcp4       0      0 89.209.81.54.16273 84.242.255.109.273 TIME_WAIT
ffffff0125262120 tcp4       0      0 89.209.81.54.16269 92.255.217.42.4917 TIME_WAIT
ffffff0125262d38 tcp4       0      0 89.209.81.54.16266 88.222.4.40.49397  TIME_WAIT
ffffff0125274168 tcp4       0      0 89.209.81.54.6933  89.209.81.54.16263 TIME_WAIT
ffffff0125162370 tcp4       0      0 89.209.81.54.16262 87.228.93.41.33773 ESTABLISHED
ffffff0063de5a50 tcp4       0      0 89.209.81.54.16261 212.45.15.2.22095  SYN_SENT
ffffff00d1b76370 tcp4       0      0 188.115.128.3.1625 78.37.5.138.55756  SYN_SENT
ffffff0005ad6c18 tcp4       0      0 188.115.128.3.1625 91.76.111.171.1665 TIME_WAIT
ffffff01252421f8 tcp4       0      0 89.209.81.54.16249 88.82.80.219.51800 TIME_WAIT
ffffff01250f66e0 tcp4       0  32781 89.209.81.54.16243 217.12.66.139.4128 ESTABLISHED
ffffff01251346e0 tcp4       0      0 89.209.81.54.16239 93.185.180.169.116 ESTABLISHED
ffffff012516f000 tcp4       0      0 89.209.81.54.16238 188.134.38.103.150 SYN_SENT
ffffff0125147370 tcp4       0      0 89.209.81.54.16236 89.107.33.19.12799 SYN_SENT
ffffff01251a7a50 tcp4       0      0 89.209.81.54.16234 90.150.116.224.630 SYN_SENT
ffffff012517d370 tcp4       0  34109 89.209.81.54.16231 92.100.8.215.48602 ESTABLISHED
ffffff012524b750 tcp4       0      0 89.209.81.54.16228 79.172.66.146.4253 TIME_WAIT
ffffff01251206e0 tcp4       0      0 89.209.81.54.16225 77.50.18.184.15266 SYN_SENT
ffffff012526c4c8 tcp4       0      0 89.209.81.54.16224 195.93.128.244.425 TIME_WAIT
ffffff012517b000 tcp4       0      0 188.115.128.3.1622 78.37.144.152.2850 SYN_SENT
ffffff0125275dc8 tcp4       0      0 89.209.81.54.6933  94.26.169.67.65099 TIME_WAIT
ffffff00a75df048 tcp4       0      0 89.209.81.54.6933  77.123.96.38.3974  TIME_WAIT
ffffff01252752d0 tcp4       0      0 89.209.81.54.6933  188.186.21.209.311 TIME_WAIT
ffffff0125275900 tcp4       0      0 89.209.81.54.6933  217.15.199.58.5077 TIME_WAIT
ffffff01250ae000 tcp4       0  29901 89.209.81.54.6933  85.173.26.170.5966 ESTABLISHED
ffffff01250ff370 tcp4       0      0 89.209.81.54.6933  88.215.186.155.352 ESTABLISHED
ffffff012526b090 tcp4       0      0 10.0.0.1.16220     10.0.0.1.80        TIME_WAIT
ffffff012526bca8 tcp4       0      0 127.0.0.1.16219    127.0.0.1.3306     TIME_WAIT
ffffff01252427e0 tcp4       0      0 127.0.0.1.16218    127.0.0.1.3306     TIME_WAIT
ffffff01252f3ab0 tcp4       0      0 127.0.0.1.16217    127.0.0.1.53       TIME_WAIT
ffffff0125255000 tcp4       0      0 127.0.0.1.16216    127.0.0.1.21       TIME_WAIT
ffffff01252556c0 tcp4       0      0 10.0.0.1.16215     10.0.0.1.3128      TIME_WAIT
ffffff0125274048 tcp4       0      0 127.0.0.1.16214    127.0.0.1.22       TIME_WAIT
ffffff0125242b88 tcp4       0      0 89.209.81.54.16213 195.82.146.120.80  TIME_WAIT
ffffff012526cc18 tcp4       0      0 89.209.81.54.6933  80.66.242.109.2035 TIME_WAIT
ffffff004fd61000 tcp4       0      0 89.209.81.54.6933  195.91.164.34.2923 TIME_WAIT
ffffff0125274090 tcp4       0      0 89.209.81.54.6933  95.134.217.100.171 TIME_WAIT
ffffff01252f3798 tcp4       0      0 89.209.81.54.6933  78.152.188.22.3618 TIME_WAIT
ffffff012526c240 tcp4       0      0 89.209.81.54.6933  94.26.169.67.64356 TIME_WAIT
ffffff012525d630 tcp4       0      0 89.209.81.54.6933  217.15.199.58.5434 TIME_WAIT
ffffff00a75df288 tcp4       0      0 89.209.81.54.6933  188.186.21.209.296 TIME_WAIT
ffffff0005ad6ab0 tcp4       0      0 89.209.81.54.6933  217.15.199.58.5802 TIME_WAIT
ffffff012524bbd0 tcp4       0      0 89.209.81.54.6933  77.123.96.38.3895  TIME_WAIT
ffffff004fdec370 tcp4       0  45312 89.209.81.54.6933  92.125.69.3.2329   ESTABLISHED
ffffff01252f3900 tcp4       0      0 89.209.81.54.6933  217.15.199.58.5457 TIME_WAIT
ffffff004fd61750 tcp4       0      0 89.209.81.54.6933  95.134.217.100.162 TIME_WAIT
ffffff012526c3a8 tcp4       0      0 89.209.81.54.6933  80.66.242.109.2027 TIME_WAIT
ffffff012524b510 tcp4       0      0 89.209.81.54.6933  94.26.169.67.63647 TIME_WAIT
ffffff0125255048 tcp4       0      0 89.209.81.54.6933  94.75.4.254.4576   TIME_WAIT
ffffff0125242630 tcp4       0      0 89.209.81.54.6933  78.152.188.22.3506 TIME_WAIT
ffffff012526c318 tcp4       0      0 89.209.81.54.6933  92.243.166.101.639 TIME_WAIT
ffffff0036e2a6e0 tcp4       0      0 89.209.81.54.16212 195.82.146.120.80  SYN_SENT
ffffff004fd61678 tcp4       0      0 89.209.81.54.6933  87.245.133.113.603 TIME_WAIT
ffffff0005ad65a0 tcp4       0      0 89.209.81.54.6933  77.123.96.38.3812  TIME_WAIT
ffffff012526b048 tcp4       0      0 89.209.81.54.6933  188.186.21.209.279 TIME_WAIT
ffffff00058bb798 tcp4       0      0 89.209.81.54.6933  217.15.199.58.6405 TIME_WAIT
ffffff014b98f6e0 tcp4       0  23258 89.209.81.54.6933  212.106.45.83.3720 ESTABLISHED
ffffff0125262480 tcp4       0      0 89.209.81.54.16181 85.250.123.74.4740 TIME_WAIT
ffffff012512b000 tcp4       0     68 89.209.81.54.16175 80.92.225.94.28494 FIN_WAIT_1
ffffff012526c750 tcp4       0      0 89.209.81.54.16133 80.249.95.121.3507 TIME_WAIT
ffffff0063de5370 tcp4       0  31353 89.209.81.54.16132 79.126.34.151.80   ESTABLISHED
ffffff0125275af8 tcp4       0      0 89.209.81.54.16077 93.81.95.214.63483 TIME_WAIT
ffffff01251b16e0 tcp4       0  34683 89.209.81.54.6933  188.114.1.214.1174 ESTABLISHED
ffffff01251a9000 tcp4       0      0 89.209.81.54.16035 98.103.194.136.561 FIN_WAIT_2
ffffff0124b1aa50 tcp4       0    341 89.209.81.54.16008 195.82.146.120.80  ESTABLISHED
ffffff0036e2a370 tcp4       0  28710 89.209.81.54.6933  62.192.233.227.481 ESTABLISHED
ffffff004fdec6e0 tcp4       0     68 89.209.81.54.15984 80.240.1.218.29085 FIN_WAIT_1
ffffff00a75df240 tcp4       0      0 89.209.81.54.15914 95.28.73.103.39027 TIME_WAIT
ffffff01250bca50 tcp4       0  53928 89.209.81.54.15911 94.27.65.4.32527   ESTABLISHED
ffffff0055ce1a50 tcp4       0      0 89.209.81.54.6933  89.169.114.20.1254 ESTABLISHED
ffffff001f8d3000 tcp4       0  25938 89.209.81.54.6933  95.110.35.130.6471 ESTABLISHED
ffffff004fd61090 tcp4       0      0 89.209.81.54.15843 92.50.165.81.35691 TIME_WAIT
ffffff01251c4370 tcp4       0  31357 89.209.81.54.15814 92.47.224.254.2759 ESTABLISHED
ffffff0158d12370 tcp4       0  22034 89.209.81.54.15747 62.141.64.115.6070 ESTABLISHED
ffffff0124b1a000 tcp4       0  23303 89.209.81.54.6933  78.111.152.61.4329 ESTABLISHED
ffffff00a76f96e0 tcp4       0  58135 89.209.81.54.6933  95.107.112.245.327 ESTABLISHED
ffffff010a6cb6e0 tcp4       0   6865 89.209.81.54.6933  93.175.208.1.3877  ESTABLISHED
ffffff01250b3370 tcp4       0  18385 89.209.81.54.6933  92.47.231.23.2895  ESTABLISHED
ffffff0124d12000 tcp4       0  21183 89.209.81.54.6933  95.70.79.58.44302  ESTABLISHED
ffffff012512c000 tcp4       0  85104 89.209.81.54.6933  124.231.94.44.3811 ESTABLISHED
ffffff012510fa50 tcp4       0  33437 89.209.81.54.6933  94.96.168.94.14765 ESTABLISHED
ffffff00649dea50 tcp4       0  29909 89.209.81.54.6933  88.200.198.92.4017 ESTABLISHED
ffffff001f8d3a50 tcp4       0  33043 89.209.81.54.15255 95.110.88.212.3230 ESTABLISHED
ffffff0124b2ea50 tcp4       0      0 89.209.81.54.15231 61.21.196.253.4453 FIN_WAIT_2
ffffff004fd7e6e0 tcp4       0  50658 89.209.81.54.6933  83.139.145.244.287 ESTABLISHED
ffffff00ce6b9000 tcp4       0  16990 89.209.81.54.6933  89.139.242.47.1544 ESTABLISHED
ffffff004fdeda50 tcp4       0      0 89.209.81.54.6933  94.24.133.58.48752 ESTABLISHED
ffffff0124b2d370 tcp4       0  96421 89.209.81.54.6933  95.134.132.104.261 ESTABLISHED
ffffff004fd7e370 tcp4       0      0 89.209.81.54.6933  95.32.31.152.2130  LAST_ACK
ffffff00ac5f8000 tcp4       0  94614 89.209.81.54.6933  95.32.105.56.3852  ESTABLISHED
ffffff004fd30a50 tcp4       0  32050 89.209.81.54.15130 95.54.203.179.4905 ESTABLISHED
ffffff01251ce000 tcp4      17  42620 89.209.81.54.15073 94.253.41.43.17153 ESTABLISHED
ffffff012519f000 tcp4       0  31906 89.209.81.54.6933  95.106.60.237.1316 ESTABLISHED
ffffff01251096e0 tcp4       0  41978 89.209.81.54.6933  95.107.85.21.1407  ESTABLISHED
ffffff01251e9000 tcp4       0  18377 89.209.81.54.14896 95.79.93.66.14787  ESTABLISHED
ffffff004feb66e0 tcp4       0      0 89.209.81.54.14826 93.90.228.188.3090 ESTABLISHED
ffffff01251f56e0 tcp4       0      0 89.209.81.54.14824 89.235.245.220.640 ESTABLISHED
ffffff0125150000 tcp4       0    218 89.209.81.54.6933  90.151.224.164.238 FIN_WAIT_1
ffffff0124b1c000 tcp4       0  28649 89.209.81.54.6933  62.192.233.227.556 ESTABLISHED
ffffff01251b9a50 tcp4       0      0 89.209.81.54.14730 62.33.169.221.3127 LAST_ACK
ffffff0063de5000 tcp4       0  29783 89.209.81.54.14686 92.127.88.2.29373  ESTABLISHED
ffffff01251b8000 tcp4       0 106388 89.209.81.54.6933  87.237.139.6.55254 ESTABLISHED
ffffff01251d8370 tcp4       0  26913 89.209.81.54.6933  93.80.166.45.1394  ESTABLISHED
ffffff0125161a50 tcp4       0 129600 188.115.128.3.6933 78.36.253.219.4299 ESTABLISHED
ffffff01250b5370 tcp4       0      0 89.209.81.54.6933  95.32.31.152.4483  LAST_ACK
ffffff01250e7a50 tcp4       0  89072 89.209.81.54.6933  95.134.132.104.254 ESTABLISHED
ffffff01251c6000 tcp4       0      0 89.209.81.54.14541 91.139.192.207.583 LAST_ACK
ffffff0124b2f6e0 tcp4       0      0 89.209.81.54.14529 94.180.195.216.538 LAST_ACK
ffffff01250ac000 tcp4       0  44426 89.209.81.54.14512 94.181.106.17.3569 ESTABLISHED
ffffff01250b9000 tcp4       0 131224 89.209.81.54.6933  94.27.65.199.60570 ESTABLISHED
ffffff004190b6e0 tcp4       0      0 89.209.81.54.14347 83.99.135.2.49968  LAST_ACK
ffffff01251456e0 tcp4       0 132104 89.209.81.54.6933  83.167.82.9.36015  ESTABLISHED
ffffff01251516e0 tcp4       0    218 89.209.81.54.6933  95.32.31.152.3415  FIN_WAIT_1
ffffff01250d7000 tcp4       0      0 89.209.81.54.14109 94.28.159.151.4353 FIN_WAIT_2
ffffff01251aaa50 tcp4       0  20424 89.209.81.54.6933  78.29.86.26.3101   ESTABLISHED
ffffff01250c6370 tcp4       0  36009 89.209.81.54.6933  94.51.123.145.1218 ESTABLISHED
ffffff0125235a50 tcp4       0      0 89.209.81.54.6933  89.235.215.222.438 LAST_ACK
ffffff01252366e0 tcp4       0  25267 89.209.81.54.6933  95.32.21.201.2628  ESTABLISHED
ffffff012519b6e0 tcp4       0  32781 89.209.81.54.6933  86.110.172.29.1704 ESTABLISHED
ffffff01251e36e0 tcp4       0   3436 89.209.81.54.6933  92.47.231.23.2028  ESTABLISHED
ffffff0091299370 tcp4       0  81711 89.209.81.54.13895 59.54.77.106.12686 ESTABLISHED
ffffff00b2c65000 tcp4       0  31347 89.209.81.54.13890 151.49.222.213.628 ESTABLISHED
ffffff0125135a50 tcp4       0  75373 188.115.128.3.1387 85.140.16.94.55000 ESTABLISHED
ffffff01250ed6e0 tcp4       0  14138 89.209.81.54.6933  94.51.150.83.58714 ESTABLISHED
ffffff012511b370 tcp4       0  36218 89.209.81.54.6933  91.211.28.250.1093 ESTABLISHED
ffffff017b748370 tcp4       0  22884 89.209.81.54.6933  86.26.102.91.62732 ESTABLISHED
ffffff01250d4370 tcp4      17  16397 89.209.81.54.13661 95.52.128.35.16856 ESTABLISHED
ffffff00649de000 tcp4       0      0 89.209.81.54.6933  88.215.157.105.219 ESTABLISHED
ffffff01250d6a50 tcp4       0  32959 89.209.81.54.13455 92.101.6.251.24436 ESTABLISHED
ffffff012510a000 tcp4      94  19072 89.209.81.54.13395 92.244.236.148.422 ESTABLISHED
ffffff01250cea50 tcp4       0  35875 89.209.81.54.13392 93.81.63.47.13401  ESTABLISHED
ffffff0125107000 tcp4       0  34715 89.209.81.54.6933  84.240.25.169.1105 ESTABLISHED
ffffff0124b1c6e0 tcp4       0  12717 89.209.81.54.6933  113.96.19.62.4903  FIN_WAIT_1
ffffff01251ea370 tcp4       0  14104 89.209.81.54.13270 90.151.151.235.303 ESTABLISHED
ffffff01250cf370 tcp4       0  30718 89.209.81.54.13177 91.214.136.60.2400 ESTABLISHED
ffffff01251e3370 tcp4       0  34399 89.209.81.54.6933  87.253.3.183.62121 ESTABLISHED
ffffff0125102370 tcp4       0  17821 89.209.81.54.6933  79.134.25.87.2428  ESTABLISHED
ffffff01250f7370 tcp4       0      0 188.115.128.3.1290 85.238.127.88.1829 ESTABLISHED
ffffff01251c5a50 tcp4       0  39564 89.209.81.54.6933  95.69.208.186.1242 ESTABLISHED
ffffff006988f000 tcp4       0  29335 89.209.81.54.12819 92.49.156.112.5999 ESTABLISHED
ffffff01251a86e0 tcp4       0  43051 89.209.81.54.6933  89.232.105.61.2527 ESTABLISHED
ffffff01251b8a50 tcp4       0  21488 89.209.81.54.12790 92.127.110.196.566 FIN_WAIT_1
ffffff0044aa5370 tcp4       0  38260 89.209.81.54.12782 95.54.61.170.26210 ESTABLISHED
ffffff00ac5f8370 tcp4       0  40668 89.209.81.54.12761 95.132.93.156.3280 ESTABLISHED
ffffff0125135370 tcp4       0      0 89.209.81.54.12476 77.35.174.44.10659 ESTABLISHED
ffffff00a7e71000 tcp4       0  24962 89.209.81.54.6933  90.151.32.94.62350 ESTABLISHED
ffffff012510e6e0 tcp4       0  38180 89.209.81.54.11997 93.90.208.228.5903 ESTABLISHED
ffffff012517da50 tcp4       0  40739 89.209.81.54.6933  89.251.107.30.3422 ESTABLISHED
ffffff00a7e6e6e0 tcp4       0  38872 89.209.81.54.6933  95.110.5.51.11956  ESTABLISHED
ffffff0125118370 tcp4     117  23650 89.209.81.54.6933  92.101.133.76.2228 ESTABLISHED
ffffff004b94d370 tcp4       0  18937 89.209.81.54.6933  60.241.182.53.5343 ESTABLISHED
ffffff012515f6e0 tcp4       0 131376 89.209.81.54.10589 213.167.214.155.22 ESTABLISHED
ffffff01251c4a50 tcp4      35  25557 89.209.81.54.10104 93.81.166.218.6281 ESTABLISHED
ffffff012515f000 tcp4       0  17006 89.209.81.54.6933  94.96.168.94.14110 FIN_WAIT_1
ffffff012511b000 tcp4       0  12981 89.209.81.54.6933  89.112.111.89.1895 ESTABLISHED
ffffff0125159000 tcp4      17  16397 89.209.81.54.65312 92.126.64.228.5597 ESTABLISHED
ffffff00057f1000 tcp4       0  19354 89.209.81.54.65280 89.103.137.8.64639 ESTABLISHED
ffffff00646a6370 tcp4       0  46897 89.209.81.54.6933  24.14.51.6.64097   ESTABLISHED
ffffff012519e370 tcp4       0 104384 89.209.81.54.6933  62.33.232.45.59825 ESTABLISHED
ffffff01251d96e0 tcp4       0      0 89.209.81.54.64815 95.78.139.87.14567 ESTABLISHED
ffffff0125170000 tcp4       0  48284 89.209.81.54.6933  78.153.26.116.2569 ESTABLISHED
ffffff01251d9a50 tcp4       0  10374 89.209.81.54.6933  91.200.139.216.268 ESTABLISHED
ffffff01250c6000 tcp4       0  37880 89.209.81.54.64333 125.26.115.81.5198 ESTABLISHED
ffffff01250e4000 tcp4      34  40494 89.209.81.54.6933  95.25.90.174.4450  ESTABLISHED
ffffff01251c3a50 tcp4       0  17446 89.209.81.54.6933  95.139.178.20.6416 ESTABLISHED
ffffff012512ca50 tcp4       0  40771 89.209.81.54.64202 91.214.136.60.2400 ESTABLISHED
ffffff0125119a50 tcp4       0  33187 89.209.81.54.64178 92.244.236.148.422 ESTABLISHED
ffffff0125121370 tcp4       0  25160 89.209.81.54.6933  79.218.150.195.590 ESTABLISHED
ffffff01250dea50 tcp4       0  19194 89.209.81.54.6933  95.110.104.176.264 ESTABLISHED
ffffff0125236000 tcp4       0   1984 89.209.81.54.6933  188.128.88.170.644 ESTABLISHED
ffffff01250eb000 tcp4       0   6304 89.209.81.54.6933  77.120.56.17.1734  ESTABLISHED
ffffff0125136a50 tcp4       0   3532 89.209.81.54.62009 91.124.244.230.299 ESTABLISHED
ffffff01250b26e0 tcp4       0  19428 89.209.81.54.6933  94.51.150.83.58158 ESTABLISHED
ffffff01251e0a50 tcp4       0  24702 89.209.81.54.6933  88.205.174.218.150 ESTABLISHED
ffffff012516a6e0 tcp4       0  15917 89.209.81.54.61612 188.243.250.5.1759 ESTABLISHED
ffffff01250bc370 tcp4       0      0 89.209.81.54.61593 93.84.74.62.47186  ESTABLISHED
ffffff00bb5b1370 tcp4       0  82325 89.209.81.54.61180 188.4.217.176.6000 ESTABLISHED
ffffff0124b2f370 tcp4       0  30538 89.209.81.54.6933  85.159.225.161.101 ESTABLISHED
ffffff01251a9a50 tcp4       0  20064 89.209.81.54.6933  79.140.78.22.1613  ESTABLISHED
ffffff0125111000 tcp4       0  33047 89.209.81.54.60232 79.132.72.86.61785 ESTABLISHED
ffffff0124b2fa50 tcp4       0  42975 89.209.81.54.59749 94.27.65.127.32527 FIN_WAIT_1
ffffff0055ce16e0 tcp4       0 129948 89.209.81.54.59602 94.24.133.58.6881  ESTABLISHED
ffffff014238ba50 tcp4      17  28206 89.209.81.54.6933  94.251.84.2.1876   ESTABLISHED
ffffff01251cca50 tcp4       0   7782 89.209.81.54.6933  94.243.6.77.56982  ESTABLISHED
ffffff0080c65000 tcp4       0  11784 89.209.81.54.6933  85.174.56.228.2379 ESTABLISHED
ffffff01250df6e0 tcp4       0  29557 89.209.81.54.59089 85.173.22.65.59039 ESTABLISHED
ffffff016c4f9370 tcp4       0  53783 89.209.81.54.57065 95.25.219.28.52595 ESTABLISHED
ffffff0125151a50 tcp4       9  68435 89.209.81.54.6933  95.132.22.248.5383 ESTABLISHED
ffffff0125236a50 tcp4       0 129948 89.209.81.54.6933  85.172.123.33.3299 ESTABLISHED
ffffff00542d7000 tcp4       0      0 89.209.81.54.56600 89.251.145.69.5000 FIN_WAIT_2
ffffff0125172000 tcp4       0      0 89.209.81.54.55859 91.122.160.47.3333 FIN_WAIT_2
ffffff01250ec000 tcp4       0  83009 89.209.81.54.6933  89.179.242.253.220 ESTABLISHED
ffffff01251a7000 tcp4       0   1462 89.209.81.54.6933  91.210.201.1.3443  ESTABLISHED
ffffff00a7e70000 tcp4       0  16635 89.209.81.54.52344 95.67.159.244.1428 ESTABLISHED
ffffff012512aa50 tcp4       0  31354 89.209.81.54.51752 91.124.233.146.368 ESTABLISHED
ffffff01251ba6e0 tcp4     209  41203 89.209.81.54.51739 195.46.187.74.3333 ESTABLISHED
ffffff01251d76e0 tcp4       0  33680 89.209.81.54.51730 95.161.18.6.30315  ESTABLISHED
ffffff012517e370 tcp4       0  42362 89.209.81.54.51466 91.124.194.192.109 ESTABLISHED
ffffff0125108a50 tcp4       0      0 10.0.0.1.993       10.0.0.10.4407     ESTABLISHED
ffffff01884df6e0 tcp4       0      0 89.209.81.54.50935 89.251.145.69.5000 FIN_WAIT_2
ffffff004f348a50 tcp4       0      0 89.209.81.54.6933  93.120.143.142.451 ESTABLISHED
ffffff012515f370 tcp4       0      0 89.209.81.54.50171 69.143.10.41.38838 FIN_WAIT_2
ffffff0125110a50 tcp4       0  25871 89.209.81.54.6933  93.116.218.118.120 ESTABLISHED
ffffff0158d116e0 tcp4       0  18672 89.209.81.54.6933  90.150.246.69.2170 ESTABLISHED
ffffff004f9b7000 tcp4       0 117096 188.115.128.3.4898 217.229.118.74.254 ESTABLISHED
ffffff00b5051a50 tcp4       0      0 89.209.81.54.48089 89.251.145.69.5000 FIN_WAIT_2
ffffff01250eba50 tcp4       0  31115 89.209.81.54.48011 87.69.43.40.16068  ESTABLISHED
ffffff01251a7370 tcp4       0  35114 89.209.81.54.6933  92.245.212.154.144 ESTABLISHED
ffffff0062176a50 tcp4       0  18620 89.209.81.54.47224 95.134.250.187.158 ESTABLISHED
ffffff003b94e370 tcp4       0  47845 89.209.81.54.47080 95.25.10.20.38013  ESTABLISHED
ffffff012517b6e0 tcp4       0  17424 89.209.81.54.46875 79.139.177.231.175 ESTABLISHED
ffffff012510a370 tcp4       0  14956 89.209.81.54.46821 95.78.33.34.57980  ESTABLISHED
ffffff01251eca50 tcp4      17 114240 89.209.81.54.6933  195.218.244.22.121 ESTABLISHED
ffffff01251b2370 tcp4       0  62870 188.115.128.3.4603 92.113.97.148.1505 ESTABLISHED
ffffff01250b2000 tcp4       0  37522 89.209.81.54.6933  68.106.30.245.5505 ESTABLISHED
ffffff012514f000 tcp4       0      0 89.209.81.54.45979 93.109.7.56.52661  ESTABLISHED
ffffff01251b8370 tcp4       0  79594 89.209.81.54.6933  221.202.121.28.643 ESTABLISHED
ffffff01251ba370 tcp4       0  17560 89.209.81.54.45638 195.69.249.38.3750 ESTABLISHED
ffffff012519f370 tcp4      35  31020 89.209.81.54.6933  91.206.110.4.4663  ESTABLISHED
ffffff012516b000 tcp4       0  21990 89.209.81.54.6933  195.112.233.172.11 ESTABLISHED
ffffff0124b1b370 tcp4       0 107100 188.115.128.3.4500 91.78.170.208.1703 ESTABLISHED
ffffff0055ce1000 tcp4       0  56208 89.209.81.54.44131 79.170.164.70.2069 ESTABLISHED
ffffff001ae9ca50 tcp4       0  34139 89.209.81.54.6933  83.149.24.119.1924 ESTABLISHED
ffffff00461b4a50 tcp4       0  31535 89.209.81.54.6933  77.45.182.106.2430 ESTABLISHED
ffffff01250c7370 tcp4       0  34736 89.209.81.54.41165 79.135.79.2.27924  ESTABLISHED
ffffff0125160370 tcp4       0   6547 89.209.81.54.6933  195.222.126.10.300 ESTABLISHED
ffffff01251b4000 tcp4       0  14957 89.209.81.54.6933  95.165.99.202.5178 ESTABLISHED
ffffff01250f8370 tcp4       0      0 89.209.81.54.36896 89.251.145.69.5000 FIN_WAIT_2
ffffff01251e9a50 tcp4       0   1415 89.209.81.54.36607 77.35.159.174.1783 ESTABLISHED
ffffff01251eaa50 tcp4       0   5951 89.209.81.54.36606 79.212.96.46.8080  ESTABLISHED
ffffff01251086e0 tcp4       0  37839 89.209.81.54.36237 69.172.119.68.2387 ESTABLISHED
ffffff01251016e0 tcp4       0  31136 89.209.81.54.36210 62.183.96.94.6900  ESTABLISHED
ffffff0124b2c6e0 tcp4       0  41154 89.209.81.54.34952 193.239.143.37.183 ESTABLISHED
ffffff001cf58a50 tcp4       0  47833 89.209.81.54.33885 77.51.139.158.1233 ESTABLISHED
ffffff017b7486e0 tcp4       0  35736 89.209.81.54.33253 78.60.19.242.26193 ESTABLISHED
ffffff01251b1370 tcp4       0      0 10.0.0.1.993       10.0.0.10.2430     ESTABLISHED
ffffff014238b6e0 tcp4       0  39149 89.209.81.54.6933  123.243.229.25.574 ESTABLISHED
ffffff012515b370 tcp4       0      0 89.209.81.54.29672 78.132.181.193.150 ESTABLISHED
ffffff01251506e0 tcp4       0  34581 89.209.81.54.29257 92.100.132.185.423 ESTABLISHED
ffffff012512a6e0 tcp4       0      0 10.0.0.1.22        10.0.0.10.2012     ESTABLISHED
ffffff00057eba50 tcp4       0  31074 89.209.81.54.6933  79.133.136.149.392 ESTABLISHED
ffffff01251216e0 tcp4       0      0 10.0.0.1.993       10.0.0.10.1952     ESTABLISHED
ffffff004fded6e0 tcp4       0      0 10.0.0.1.993       10.0.0.10.1926     ESTABLISHED
ffffff01251d7a50 tcp4       0      0 89.209.81.54.28192 89.251.145.69.5000 FIN_WAIT_2
ffffff01250f5000 tcp4       0      0 89.209.81.54.28135 95.31.4.28.51776   FIN_WAIT_2
ffffff004feb5a50 tcp4       0  31180 89.209.81.54.6933  91.151.242.207.202 ESTABLISHED
ffffff01250ac370 tcp4       0  36168 89.209.81.54.6933  84.102.220.128.407 ESTABLISHED
ffffff0125172a50 tcp4       0      0 89.209.81.54.6933  88.147.217.229.412 ESTABLISHED
ffffff00584376e0 tcp4       0  34999 188.115.128.3.6933 86.57.132.211.3286 ESTABLISHED
ffffff012512c6e0 tcp4       0      0 89.209.81.54.23511 205.188.9.51.443   ESTABLISHED
ffffff01250eda50 tcp4       0      0 10.0.0.1.3128      10.0.0.10.1128     ESTABLISHED
ffffff00542d7a50 tcp4       0      0 89.209.81.54.23510 205.188.8.199.443  ESTABLISHED
ffffff00912996e0 tcp4       0      0 10.0.0.1.3128      10.0.0.10.1127     ESTABLISHED
ffffff0125111370 tcp4       0      0 89.209.81.54.23509 205.188.8.7.443    ESTABLISHED
ffffff00ac5f86e0 tcp4       0      0 10.0.0.1.3128      10.0.0.10.1126     ESTABLISHED
ffffff0125158370 tcp4       0      0 188.115.128.3.2344 208.93.0.128.5222  ESTABLISHED
ffffff0125145000 tcp4       0      0 10.0.0.1.3128      10.0.0.10.1098     ESTABLISHED
ffffff01250e7370 tcp4       0      0 89.209.81.54.23446 209.85.137.125.522 ESTABLISHED
ffffff01607e3000 tcp4       0      0 10.0.0.1.3128      10.0.0.10.1097     ESTABLISHED
ffffff0125233a50 tcp4       0      0 188.115.128.3.2344 74.63.57.77.5223   ESTABLISHED
ffffff01251b86e0 tcp4       0      0 10.0.0.1.3128      10.0.0.10.1096     ESTABLISHED
ffffff01250d46e0 tcp4       0      0 10.0.0.1.139       10.0.0.10.1038     ESTABLISHED
ffffff01250ad370 tcp4      26  45214 89.209.81.54.22640 95.28.199.66.39304 ESTABLISHED
ffffff0125152a50 tcp4       0  44345 89.209.81.54.21584 206.248.165.165.42 ESTABLISHED
ffffff0125129000 tcp4       0  26762 89.209.81.54.21190 62.217.153.63.6465 ESTABLISHED
ffffff0030b8e370 tcp4       0  35863 89.209.81.54.20034 93.81.104.254.6260 ESTABLISHED
ffffff0124b1ca50 tcp4       0  20397 89.209.81.54.18275 95.110.99.25.57944 ESTABLISHED
ffffff01251aa000 tcp4       0      0 89.209.81.54.17873 89.251.145.69.5000 FIN_WAIT_2
ffffff00b50516e0 tcp4       0  36291 89.209.81.54.6933  86.155.119.134.452 ESTABLISHED
ffffff0124b266e0 tcp4       0      0 89.209.81.54.16762 99.240.217.88.4969 FIN_WAIT_2
ffffff01251b4a50 tcp4       0  25605 89.209.81.54.16430 93.84.212.48.62550 ESTABLISHED
ffffff00c9b3e000 tcp4      26  28872 89.209.81.54.6933  92.37.213.139.5561 ESTABLISHED
ffffff01251a06e0 tcp4       0      0 89.209.81.54.13638 77.35.171.220.6178 ESTABLISHED
ffffff0125170370 tcp4       0  20341 89.209.81.54.6933  94.158.32.111.1580 ESTABLISHED
ffffff0125108000 tcp4       0      0 89.209.81.54.10991 94.231.76.161.6390 ESTABLISHED
ffffff01251d6000 tcp4       0  43702 89.209.81.54.6933  88.222.168.144.630 ESTABLISHED
ffffff004feb6a50 tcp4       0   6864 89.209.81.54.6933  94.27.96.255.1724  ESTABLISHED
ffffff004fd7d370 tcp4       0  28873 89.209.81.54.63148 92.126.102.99.6192 ESTABLISHED
ffffff01250b4370 tcp4       0      0 89.209.81.54.62156 87.247.87.109.4385 ESTABLISHED
ffffff004fd93370 tcp4       0      0 89.209.81.54.61424 83.241.5.220.50001 FIN_WAIT_2
ffffff0124b24a50 tcp4       0  44336 89.209.81.54.60631 95.139.102.113.621 ESTABLISHED
ffffff006988f6e0 tcp4       0  20382 89.209.81.54.6933  77.236.210.176.110 ESTABLISHED
ffffff01250d0a50 tcp4       0      0 89.209.81.54.6933  91.207.210.62.5716 ESTABLISHED
ffffff0125150370 tcp4       0   6330 89.209.81.54.6933  94.178.209.249.452 ESTABLISHED
ffffff015240a370 tcp4      17  42988 89.209.81.54.6933  94.251.14.53.1048  ESTABLISHED
ffffff0125147000 tcp4       0  37286 89.209.81.54.6933  90.189.154.252.641 ESTABLISHED
ffffff0125233000 tcp4       0      0 89.209.81.54.56854 89.251.145.69.5000 FIN_WAIT_2
ffffff01250c66e0 tcp4       0  38533 89.209.81.54.56236 95.134.74.42.19160 ESTABLISHED
ffffff01251466e0 tcp4       0  12340 89.209.81.54.54323 95.24.178.72.20861 ESTABLISHED
ffffff0124d12a50 tcp4       0      0 89.209.81.54.53696 89.251.145.69.5000 FIN_WAIT_2
ffffff01250f7a50 tcp4       0  39588 89.209.81.54.52690 82.12.9.33.55254   ESTABLISHED
ffffff0124b24000 tcp4       0   4973 89.209.81.54.6933  85.172.100.68.2551 ESTABLISHED
ffffff0125146000 tcp4       0  60053 89.209.81.54.49361 122.71.35.201.80   ESTABLISHED
ffffff0158d12000 tcp4       0  52515 89.209.81.54.47447 93.80.84.90.34435  ESTABLISHED
ffffff01251b1000 tcp4       0  34349 89.209.81.54.43414 92.115.152.172.567 ESTABLISHED
ffffff004faad6e0 tcp4       0      0 89.209.81.54.41578 83.241.5.220.50001 FIN_WAIT_2
ffffff004fded000 tcp4       0      0 188.115.128.3.4074 92.113.192.10.4497 FIN_WAIT_2
ffffff01251a16e0 tcp4       0      0 188.115.128.3.3709 78.36.27.190.29646 ESTABLISHED
ffffff0125162a50 tcp4       0   4197 89.209.81.54.6933  194.187.105.22.377 ESTABLISHED
ffffff0125191370 tcp4       0      0 89.209.81.54.31322 94.75.45.196.60431 ESTABLISHED
ffffff0124b1c370 tcp4       0   1327 89.209.81.54.29471 95.67.213.186.1838 ESTABLISHED
ffffff01251986e0 tcp4       0  46457 89.209.81.54.29013 213.187.116.242.38 ESTABLISHED
ffffff012519f6e0 tcp4       0      0 89.209.81.54.21105 83.241.5.220.50001 FIN_WAIT_2
ffffff015240a000 tcp4       0      0 89.209.81.54.17223 89.251.145.69.5000 FIN_WAIT_2
ffffff004fd7ea50 tcp4       0  67814 89.209.81.54.6933  92.243.181.39.4348 ESTABLISHED
ffffff01250e66e0 tcp4       0      0 89.209.81.54.6933  91.200.137.80.1963 ESTABLISHED
ffffff004fd7e000 tcp4       0  35222 89.209.81.54.6933  195.93.155.12.1051 ESTABLISHED
ffffff01250dd370 tcp4       0      0 89.209.81.54.6933  95.135.81.214.2870 ESTABLISHED
ffffff005205ca50 tcp4       0      0 188.115.128.3.5854 78.106.35.45.51413 FIN_WAIT_2
ffffff012513da50 tcp4       0      0 89.209.81.54.54088 79.171.121.99.2303 FIN_WAIT_2
ffffff01250ba370 tcp4       0  20275 89.209.81.54.6933  89.133.162.54.1056 ESTABLISHED
ffffff0124b2e000 tcp4       0  37047 89.209.81.54.51230 95.139.247.84.4729 ESTABLISHED
ffffff01250ac6e0 tcp4       0      0 89.209.81.54.6933  85.202.113.41.5335 ESTABLISHED
ffffff0124b2f000 tcp4       0      0 89.209.81.54.50969 79.165.190.4.54016 FIN_WAIT_2
ffffff012515aa50 tcp4       0   2909 89.209.81.54.49951 95.32.47.194.15570 ESTABLISHED
ffffff004feb5370 tcp4       0  44363 89.209.81.54.6933  93.197.145.74.4957 ESTABLISHED
ffffff012515a6e0 tcp4       0      0 89.209.81.54.35070 83.241.5.220.50001 FIN_WAIT_2
ffffff012516aa50 tcp4       0  37868 89.209.81.54.30849 79.185.229.69.6886 ESTABLISHED
ffffff01250bb370 tcp4       0      0 89.209.81.54.6933  91.203.82.66.14179 ESTABLISHED
ffffff0124b1da50 tcp4       0      0 89.209.81.54.23865 85.234.174.41.5761 FIN_WAIT_2
ffffff0125109370 tcp4       0      0 89.209.81.54.13572 83.99.135.158.5548 FIN_WAIT_2
ffffff01251a0370 tcp4       0      0 188.115.128.3.1230 92.113.192.10.4497 FIN_WAIT_2
ffffff0117e8da50 tcp4       0  33541 89.209.81.54.60964 95.32.123.159.2423 ESTABLISHED
ffffff0124b246e0 tcp4       0      0 89.209.81.54.55283 96.49.177.133.1311 FIN_WAIT_2
ffffff01250bba50 tcp4       0  71473 89.209.81.54.6933  217.173.21.5.57861 FIN_WAIT_1
ffffff0125198a50 tcp4       0      0 89.209.81.54.41557 90.134.56.94.42748 ESTABLISHED
ffffff01251616e0 tcp4       0      0 89.209.81.54.40079 77.45.202.207.3245 FIN_WAIT_2
ffffff01250f6370 tcp4       0      0 89.209.81.54.37370 212.152.50.140.158 FIN_WAIT_2
ffffff012519a000 tcp4       0      0 89.209.81.54.6933  94.77.145.195.2464 ESTABLISHED
ffffff0125118a50 tcp4       0      0 89.209.81.54.6933  95.135.101.10.7115 ESTABLISHED
ffffff01251d8000 tcp4       0  40279 89.209.81.54.28982 85.175.54.243.1959 ESTABLISHED
ffffff0125134000 tcp4       0      0 89.209.81.54.26032 78.29.94.58.31804  FIN_WAIT_2
ffffff012519a370 tcp4       0      0 89.209.81.54.10054 99.240.217.88.4969 FIN_WAIT_2
ffffff01250c76e0 tcp4       0      0 89.209.81.54.64400 78.29.94.58.31804  FIN_WAIT_2
ffffff01250dc370 tcp4       0      0 89.209.81.54.60487 77.87.171.195.3569 FIN_WAIT_2
ffffff0125121a50 tcp4       0      0 89.209.81.54.48582 78.29.94.58.31804  FIN_WAIT_2
ffffff01250d0000 tcp4       0  57636 188.115.128.3.4813 78.37.49.226.37432 ESTABLISHED
ffffff012516b370 tcp4       0      0 89.209.81.54.29282 78.29.94.58.31804  FIN_WAIT_2
ffffff0125133a50 tcp4       0      0 89.209.81.54.6933  81.88.124.102.2832 ESTABLISHED
ffffff0124b25370 tcp4       0      0 89.209.81.54.6933  213.227.246.162.11 ESTABLISHED
ffffff004fd7d6e0 tcp4       0      0 89.209.81.54.10042 78.29.94.58.31804  FIN_WAIT_2
ffffff01251b7370 tcp4       0      0 89.209.81.54.64264 80.237.14.206.3199 FIN_WAIT_2
ffffff01251b26e0 tcp4       0      0 89.209.81.54.61098 80.237.14.206.3199 FIN_WAIT_2
ffffff012513ea50 tcp4       0      0 89.209.81.54.60514 95.161.6.2.31239   ESTABLISHED
ffffff0125134370 tcp4       0      0 89.209.81.54.42634 78.29.94.58.31804  FIN_WAIT_2
ffffff01251c5000 tcp4       0  16397 89.209.81.54.42396 93.88.212.16.35691 ESTABLISHED
ffffff01250d1a50 tcp4       0      0 89.209.81.54.41045 95.24.223.227.2706 ESTABLISHED
ffffff01251d7370 tcp4       0      0 89.209.81.54.6933  94.178.221.252.413 ESTABLISHED
ffffff01250d4a50 tcp4       0      0 89.209.81.54.34171 94.181.13.195.5177 ESTABLISHED
ffffff01251076e0 tcp4       0  28192 89.209.81.54.6933  80.73.162.91.4423  ESTABLISHED
ffffff01251ba000 tcp4       0      0 89.209.81.54.30504 78.29.94.58.31804  FIN_WAIT_2
ffffff01251ea6e0 tcp4       0      0 89.209.81.54.30379 78.29.94.58.31804  FIN_WAIT_2
ffffff0125118000 tcp4       0  27733 89.209.81.54.29037 94.137.200.231.279 ESTABLISHED
ffffff01250ae6e0 tcp4       0  42440 89.209.81.54.6933  91.192.98.231.3752 ESTABLISHED
ffffff004faad370 tcp4       0      0 89.209.81.54.20345 94.180.160.109.132 ESTABLISHED
ffffff012513f370 tcp4      17      0 89.209.81.54.6933  79.180.141.132.420 ESTABLISHED
ffffff012515ba50 tcp4       0      0 10.0.0.1.3128      *.*                LISTEN
ffffff01250ee6e0 tcp4       0      0 89.209.81.54.15379 91.121.153.32.4915 ESTABLISHED
ffffff01250dca50 tcp4       0      0 89.209.81.54.6933  194.242.100.100.50 ESTABLISHED
ffffff004feb6000 tcp4       0      0 *.6933             *.*                LISTEN
ffffff004f458370 tcp4       0      0 *.587              *.*                LISTEN
ffffff004f4586e0 tcp6       0      0 *.25               *.*                LISTEN
ffffff004f458a50 tcp4       0      0 *.25               *.*                LISTEN
ffffff0005c336e0 tcp4       0      0 127.0.0.1.3306     *.*                LISTEN
ffffff004f458000 tcp4       0      0 127.0.0.1.783      *.*                LISTEN
ffffff0005fde370 tcp4       0      0 *.10000            *.*                LISTEN
ffffff0005fde000 tcp4       0      0 10.0.0.1.139       *.*                LISTEN
ffffff0005b47370 tcp4       0      0 10.0.0.1.445       *.*                LISTEN
ffffff0005ab3a50 tcp6       0      0 *.995              *.*                LISTEN
ffffff004f47e000 tcp4       0      0 *.995              *.*                LISTEN
ffffff004f47e370 tcp6       0      0 *.110              *.*                LISTEN
ffffff004f47e6e0 tcp4       0      0 *.110              *.*                LISTEN
ffffff004f47ea50 tcp6       0      0 *.993              *.*                LISTEN
ffffff004f4bd000 tcp4       0      0 *.993              *.*                LISTEN
ffffff004f4bd370 tcp6       0      0 *.143              *.*                LISTEN
ffffff004f4bd6e0 tcp4       0      0 *.143              *.*                LISTEN
ffffff0005b386e0 tcp4       0      0 127.0.0.1.953      *.*                LISTEN
ffffff0005fde6e0 tcp4       0      0 188.115.128.3.53   *.*                LISTEN
ffffff0005fdea50 tcp4       0      0 89.209.81.54.53    *.*                LISTEN
ffffff0005ab3000 tcp4       0      0 127.0.0.1.53       *.*                LISTEN
ffffff0005ab3370 tcp6       0      0 ::1.53             *.*                LISTEN
ffffff0005ab36e0 tcp4       0      0 192.168.60.194.53  *.*                LISTEN
ffffff0005b476e0 tcp4       0      0 10.0.0.1.53        *.*                LISTEN
ffffff00057eb000 tcp4       0      0 *.21               *.*                LISTEN
ffffff0005b38370 tcp4       0      0 *.6950             *.*                LISTEN
ffffff0005b47a50 tcp4       0      0 *.7456             *.*                LISTEN
ffffff0005c32000 tcp4       0      0 *.6112             *.*                LISTEN
ffffff0005c32370 tcp4       0      0 *.6991             *.*                LISTEN
ffffff0005c326e0 tcp4       0      0 *.1513             *.*                LISTEN
ffffff0005c32a50 tcp4       0      0 *.6113             *.*                LISTEN
ffffff0005c33000 tcp4       0      0 *.6200             *.*                LISTEN
ffffff0005c33370 tcp4       0      0 *.6110             *.*                LISTEN
ffffff00057ec000 tcp4       0      0 *.2802             *.*                LISTEN
ffffff00057eb6e0 tcp4       0      0 *.80               *.*                LISTEN
ffffff00057eca50 tcp4       0      0 *.22               *.*                LISTEN
ffffff00057ec370 tcp6       0      0 *.22               *.*                LISTEN
ffffff0125285000 udp4       0      0 *.3401             *.*                
ffffff000556cbd0 udp4       0      0 *.31114            *.*                
ffffff000554f690 udp4       0      0 *.*                *.*                
ffffff000554e2a0 udp4       0      0 127.0.0.1.41061    127.0.0.1.162      
ffffff00057fd7e0 udp4       0      0 89.209.81.54.10944 81.171.72.11.3653  
ffffff000554f150 udp6       0      0 2001:5c0:1400:b:.1 *.*                
ffffff000554fd20 udp6       0      0 2001:5c0:1503:34.1 *.*                
ffffff000554e540 udp4       0      0 *.10000            *.*                
ffffff00057f7d20 udp4       0      0 10.0.0.1.138       *.*                
ffffff00057e7690 udp4       0      0 10.0.0.1.137       *.*                
ffffff00057fd690 udp4       0      0 *.138              *.*                
ffffff00057fd3f0 udp4    1056      0 *.137              *.*                
ffffff00057ab2a0 udp4       0      0 188.115.128.3.123  *.*                
ffffff000554ea80 udp4       0      0 89.209.81.54.123   *.*                
ffffff00057e7d20 udp4       0      0 127.0.0.1.123      *.*                
ffffff00057f72a0 udp6       0      0 ::1.123            *.*                
ffffff000554e690 udp6       0      0 fe80:4::1.123      *.*                
ffffff00057f7690 udp4       0      0 192.168.60.194.123 *.*                
ffffff00057fda80 udp4       0      0 10.0.0.1.123       *.*                
ffffff00057d87e0 udp6       0      0 *.123              *.*                
ffffff000554fa80 udp4       0      0 *.123              *.*                
ffffff00057f7bd0 udp4       0      0 89.209.81.54.61791 81.171.72.11.3653  
ffffff00057d8a80 udp4       0      0 *.161              *.*                
ffffff00057f73f0 udp4       0      0 *.*                *.*                
ffffff00057fd930 udp4       0      0 127.0.0.1.49768    127.0.0.1.162      
ffffff000556c690 udp4       0      0 188.115.128.3.53   *.*                
ffffff000554e930 udp4       0      0 89.209.81.54.53    *.*                
ffffff000556c000 udp4       0      0 127.0.0.1.53       *.*                
ffffff00057d8930 udp6       0      0 ::1.53             *.*                
ffffff00057ab3f0 udp4       0      0 192.168.60.194.53  *.*                
ffffff000556cd20 udp4       0      0 10.0.0.1.53        *.*                
ffffff00057d8150 udp4       0      0 127.0.0.1.49431    127.0.0.1.9999     
ffffff000554ed20 udp4       0      0 *.514              *.*                
ffffff000554ebd0 udp6       0      0 *.514              *.*                
ffffff00056cd000 div4       0      0 *.8668             *.*                
ffffff00056cf000 icm4       0      0 *.*                *.*                
ffffff00056cf690 icm6      92      0 *.*                *.*                
ffffff00056ce930 icm6       0      0 *.*                *.*                
ffffff00056ce7e0 icm6       0      0 *.*                *.*                
Active UNIX domain sockets
Address  Type   Recv-Q Send-Q    Inode     Conn     Refs  Nextref Addr
ffffff004fcb0000 stream      0      0        0 ffffff004ff6d1e0        0        0
ffffff004ff6d1e0 stream      0      0        0 ffffff004fcb0000        0        0
ffffff004f7b8a50 stream      0      0        0 ffffff0003ea7a50        0        0 /var/run/dovecot/login/default
ffffff0003ea7a50 stream      0      0        0 ffffff004f7b8a50        0        0
ffffff004fcb0b40 stream      0      0        0 ffffff004fca3780        0        0
ffffff004fca3780 stream      0      0        0 ffffff004fcb0b40        0        0
ffffff004fca30f0 stream      0      0        0 ffffff017b8225a0        0        0
ffffff017b8225a0 stream      0      0        0 ffffff004fca30f0        0        0
ffffff0003e7cd20 stream      0      0        0 ffffff004fca3870        0        0
ffffff004fca3870 stream      0      0        0 ffffff0003e7cd20        0        0
ffffff004ff6d5a0 stream      0      0        0 ffffff004fca3a50        0        0 /tmp/mysql.sock
ffffff004fca3a50 stream      0      0        0 ffffff004ff6d5a0        0        0
ffffff004fca3000 stream      0      0        0 ffffff004fcb0690        0        0
ffffff004fcb0690 stream      0      0        0 ffffff004fca3000        0        0
ffffff004fcb01e0 stream      0      0        0 ffffff017b822000        0        0
ffffff017b822000 stream      0      0        0 ffffff004fcb01e0        0        0
ffffff01688995a0 stream      0      0        0 ffffff004fca35a0        0        0
ffffff004fca35a0 stream      0      0        0 ffffff01688995a0        0        0
ffffff004fca31e0 stream      0      0        0 ffffff00a764fa50        0        0
ffffff00a764fa50 stream      0      0        0 ffffff004fca31e0        0        0
ffffff017b822690 stream      0      0        0 ffffff017b822780        0        0
ffffff017b822780 stream      0      0        0 ffffff017b822690        0        0
ffffff00a764f870 stream      0      0        0 ffffff004ff6c0f0        0        0 /var/run/dovecot/login/default
ffffff004ff6c0f0 stream      0      0        0 ffffff00a764f870        0        0
ffffff004fcb0780 stream      0      0        0 ffffff00054f0780        0        0
ffffff00054f0780 stream      0      0        0 ffffff004fcb0780        0        0
ffffff004ff6c2d0 stream      0      0        0 ffffff004fcb00f0        0        0
ffffff004fcb00f0 stream      0      0        0 ffffff004ff6c2d0        0        0
ffffff004fca3960 stream      0      0        0 ffffff004ff6d870        0        0
ffffff004ff6d870 stream      0      0        0 ffffff004fca3960        0        0
ffffff017b822870 stream      0      0        0 ffffff0168899000        0        0 /tmp/mysql.sock
ffffff0168899000 stream      0      0        0 ffffff017b822870        0        0
ffffff004ff6de10 stream      0      0        0 ffffff00054f04b0        0        0 /tmp/mysql.sock
ffffff00054f04b0 stream      0      0        0 ffffff004ff6de10        0        0
ffffff00054f0870 stream      0      0        0 ffffff004ff6c780        0        0 /tmp/mysql.sock
ffffff004ff6c780 stream      0      0        0 ffffff00054f0870        0        0
ffffff017b8221e0 stream      0      0        0 ffffff004f553c30        0        0 /tmp/mysql.sock
ffffff004f553c30 stream      0      0        0 ffffff017b8221e0        0        0
ffffff00a764fe10 stream      0      0        0 ffffff004fcb0d20        0        0 /tmp/mysql.sock
ffffff004fcb0d20 stream      0      0        0 ffffff00a764fe10        0        0
ffffff00a764f3c0 stream      0      0        0 ffffff004ff6dc30        0        0
ffffff004ff6dc30 stream      0      0        0 ffffff00a764f3c0        0        0
ffffff004ff6c4b0 stream      0      0        0 ffffff004f553690        0        0
ffffff004f553690 stream      0      0        0 ffffff004ff6c4b0        0        0
ffffff004f7b84b0 stream      0      0        0 ffffff004f7b8000        0        0
ffffff004f7b8000 stream      0      0        0 ffffff004f7b84b0        0        0
ffffff004f7b8b40 stream      0      0        0 ffffff004f574000        0        0 /tmp/mysql.sock
ffffff004f574000 stream      0      0        0 ffffff004f7b8b40        0        0
ffffff004ff6c870 stream      0      0        0 ffffff004ff6c960        0        0 /tmp/mysql.sock
ffffff004ff6c960 stream      0      0        0 ffffff004ff6c870        0        0
ffffff004ff6ca50 stream      0      0        0 ffffff004ff6cb40        0        0 /tmp/mysql.sock
ffffff004ff6cb40 stream      0      0        0 ffffff004ff6ca50        0        0
ffffff004f7b83c0 stream      0      0        0 ffffff004f7b82d0        0        0 /tmp/mysql.sock
ffffff004f7b82d0 stream      0      0        0 ffffff004f7b83c0        0        0
ffffff004f574d20 stream      0      0 ffffff004fd683b0        0        0        0 /var/run/snmpd.sock
ffffff004f553780 stream      0      0 ffffff004fab6ce8        0        0        0 /var/run/clamav/clmilter.sock
ffffff004f7b8870 stream      0      0 ffffff004fab1ce8        0        0        0 /var/run/clamav/clamd.sock
ffffff004f7b8780 stream      0      0        0 ffffff004f7b8690        0        0
ffffff004f7b8690 stream      0      0        0 ffffff004f7b8780        0        0
ffffff004f553e10 stream      0      0        0 ffffff004f553d20        0        0
ffffff004f553d20 stream      0      0        0 ffffff004f553e10        0        0
ffffff004f574e10 stream      0      0 ffffff004f9ec3b0        0        0        0 /tmp/mysql.sock
ffffff004f7b8c30 stream      0      0 ffffff004f75c3b0        0        0        0 /var/run/saslauthd/mux
ffffff004f5742d0 stream      0      0 ffffff004f7571d8        0        0        0 /var/run/spamass-milter.sock
ffffff004f5745a0 stream      0      0        0 ffffff004f574690        0        0 /var/run/dovecot/login/default
ffffff004f574690 stream      0      0        0 ffffff004f5745a0        0        0
ffffff004f574780 stream      0      0        0 ffffff004f574870        0        0 /var/run/dovecot/login/default
ffffff004f574870 stream      0      0        0 ffffff004f574780        0        0
ffffff0003e7c780 stream      0      0        0 ffffff0003e7c870        0        0 /var/run/dovecot/login/default
ffffff0003e7c870 stream      0      0        0 ffffff0003e7c780        0        0
ffffff0003ea72d0 stream      0      0        0 ffffff0003e7c0f0        0        0 /var/run/dovecot/login/default
ffffff0003e7c0f0 stream      0      0        0 ffffff0003ea72d0        0        0
ffffff004f5531e0 stream      0      0        0 ffffff004f5532d0        0        0
ffffff004f5532d0 stream      0      0        0 ffffff004f5531e0        0        0
ffffff004f5533c0 stream      0      0        0 ffffff004f5534b0        0        0
ffffff004f5534b0 stream      0      0        0 ffffff004f5533c0        0        0
ffffff00054f0000 stream      0      0        0 ffffff0003ea7960        0        0
ffffff0003ea7960 stream      0      0        0 ffffff00054f0000        0        0
ffffff0003ea70f0 stream      0      0        0 ffffff0003ea71e0        0        0
ffffff0003ea71e0 stream      0      0        0 ffffff0003ea70f0        0        0
ffffff0003ea7000 stream      0      0 ffffff004f402b10        0        0        0 /var/run/dovecot/auth-worker.2553
ffffff00054f0e10 stream      0      0        0 ffffff0003ea7690        0        0
ffffff0003ea7690 stream      0      0        0 ffffff00054f0e10        0        0
ffffff0003ea7780 stream      0      0 ffffff004f402ce8        0        0        0 /var/run/dovecot/login/default
ffffff0003ea7d20 stream      0      0 ffffff004f48b000        0        0        0 /var/run/dovecot/dict-server
ffffff00054f0c30 stream      0      0        0 ffffff0003ea75a0        0        0 /var/run/devd.pipe
ffffff0003ea75a0 stream      0      0        0 ffffff00054f0c30        0        0
ffffff0003ea7c30 stream      0      0 ffffff0005d413b0        0        0        0 /var/run/snmpd.sock
ffffff00054f0a50 stream      0      0 ffffff0005da8000        0        0        0 /var/run/proftpd/proftpd.sock
ffffff0003ea7870 stream      0      0 ffffff000554d760        0        0        0 /var/run/devd.pipe
ffffff004fca32d0 dgram       0      0        0 ffffff00054f00f0        0 ffffff004f574c30
ffffff004f574c30 dgram       0      0        0 ffffff00054f00f0        0 ffffff004f553960
ffffff0003e7c3c0 dgram       0      0        0 ffffff00054f02d0        0 ffffff004f7b8960
ffffff004f553960 dgram       0      0        0 ffffff00054f00f0        0 ffffff004f5535a0
ffffff004f5535a0 dgram       0      0        0 ffffff00054f00f0        0 ffffff004f7b85a0
ffffff004f7b85a0 dgram       0      0        0 ffffff00054f00f0        0 ffffff004f553a50
ffffff004f553a50 dgram       0      0        0 ffffff00054f00f0        0 ffffff004f7b8d20
ffffff004f7b8960 dgram       0      0        0 ffffff00054f02d0        0 ffffff0003e7c2d0
ffffff004f7b8d20 dgram       0      0        0 ffffff00054f00f0        0 ffffff004f5741e0
ffffff004f5741e0 dgram       0      0        0 ffffff00054f00f0        0 ffffff0003e7cc30
ffffff0003e7c2d0 dgram       0      0        0 ffffff00054f02d0        0 ffffff00054f0960
ffffff0003e7cc30 dgram       0      0        0 ffffff00054f00f0        0 ffffff0003e7c4b0
ffffff0003e7c4b0 dgram       0      0        0 ffffff00054f00f0        0 ffffff004f5744b0
ffffff004f5744b0 dgram       0      0        0 ffffff00054f00f0        0 ffffff0003ea7e10
ffffff00054f0960 dgram       0      0        0 ffffff00054f02d0        0 ffffff0003e7c1e0
ffffff0003ea7e10 dgram       0      0        0 ffffff00054f00f0        0 ffffff0003ea74b0
ffffff0003ea74b0 dgram       0      0        0 ffffff00054f00f0        0 ffffff0003ea73c0
ffffff0003ea73c0 dgram       0      0        0 ffffff00054f00f0        0 ffffff00054f0b40
ffffff00054f0b40 dgram       0      0        0 ffffff00054f00f0        0 ffffff0003ea7b40
ffffff0003ea7b40 dgram       0      0        0 ffffff00054f00f0        0 ffffff00054f0d20
ffffff0003e7c1e0 dgram       0      0        0 ffffff00054f02d0        0        0
ffffff00054f0d20 dgram       0      0        0 ffffff00054f00f0        0 ffffff00054f0690
ffffff00054f0690 dgram       0      0        0 ffffff00054f00f0        0        0
ffffff00054f03c0 dgram       0      0 ffffff0005692588        0        0        0 /var/named/var/run/log
ffffff00054f02d0 dgram       0      0 ffffff000569e760        0 ffffff0003e7c3c0        0 /var/run/log
ffffff00054f00f0 dgram       0      0 ffffff000569e938        0 ffffff004fca32d0        0 /var/run/logpriv
ffffff00054f01e0 dgram       0      0 ffffff000569eb10        0        0        0 /var/run/log

------------------------------------------------------------------------
netstat -aL

Current listen queue sizes (qlen/incqlen/maxqlen)
Proto Listen         Local Address         
tcp4  0/0/2048       otrada.local.3128      
tcp4  1/0/50         *.6933                 
tcp4  0/0/10         *.submission           
tcp6  0/0/10         *.smtp                 
tcp4  0/0/10         *.smtp                 
tcp4  0/0/50         localhost.3306         
tcp4  0/0/128        localhost.783          
tcp4  0/0/128        *.10000                
tcp4  0/0/50         otrada.local.netbios-s 
tcp4  0/0/50         otrada.local.microsoft 
tcp6  0/0/128        *.pop3s                
tcp4  0/0/128        *.pop3s                
tcp6  0/0/128        *.pop3                 
tcp4  0/0/128        *.pop3                 
tcp6  0/0/128        *.imaps                
tcp4  0/0/128        *.imaps                
tcp6  0/0/128        *.imap                 
tcp4  0/0/128        *.imap                 
tcp4  0/0/128        localhost.rndc         
tcp4  0/0/3          188-115-128-3.br.domai 
tcp4  0/0/3          otrada.od.ua.domain    
tcp4  0/0/3          localhost.domain       
tcp6  0/0/3          localhost.domain       
tcp4  0/0/3          192.168.60.194.domain  
tcp4  0/0/3          otrada.local.domain    
tcp4  0/0/5          *.ftp                  
tcp4  0/0/3          *.6950                 
tcp4  0/0/3          *.7456                 
tcp4  0/0/3          *.6112                 
tcp4  0/0/3          *.6991                 
tcp4  0/0/3          *.fujitsu-dtc          
tcp4  0/0/3          *.6113                 
tcp4  0/0/3          *.6200                 
tcp4  0/0/3          *.softcm               
tcp4  0/0/3          *.2802                 
tcp4  0/0/511        *.http                 
tcp4  0/0/128        *.ssh                  
tcp6  0/0/128        *.ssh                  
unix  0/0/10         /var/run/snmpd.sock
unix  0/0/2048       /var/run/clamav/clmilter.sock
unix  0/0/15         /var/run/clamav/clamd.sock
unix  0/0/50         /tmp/mysql.sock
unix  0/0/32         /var/run/saslauthd/mux
unix  0/0/2048       /var/run/spamass-milter.sock
unix  0/0/128        /var/run/dovecot/auth-worker.2553
unix  0/0/128        /var/run/dovecot/login/default
unix  0/0/128        /var/run/dovecot/dict-server
unix  0/0/10         /var/run/snmpd.sock
unix  0/0/5          /var/run/proftpd/proftpd.sock
unix  0/0/4          /var/run/devd.pipe

------------------------------------------------------------------------
fstat

Segmentation fault

------------------------------------------------------------------------
dmesg

al ABI support:
/etc/rc: DEBUG: checkyesno: sysvipc_enable is set to NO.
/etc/rc: DEBUG: checkyesno: linux_enable is set to YES.
 linux
/etc/rc: INFO: linux kernel module loaded.
/etc/rc: DEBUG: checkyesno: svr4_enable is set to NO.
.
/etc/rc: DEBUG: pid file (/var/run/named.pid): not readable.
/etc/rc: DEBUG: checkyesno: named_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: start_precmd: named_precmd 
/etc/rc: DEBUG: checkyesno: named_chroot_autoupdate is set to YES.
/etc/rc: DEBUG: devfs_domount(): mount-point is (/var/named/dev), ruleset is (devfsrules_hide_all)
/etc/rc: DEBUG: reading rulesets from file (/etc/defaults/devfs.rules)
/etc/rc: DEBUG: found ruleset: devfsrules_hide_all=1
/etc/rc: DEBUG: adding rule (add hide)
/etc/rc: DEBUG: found ruleset: devfsrules_unhide_basic=2
/etc/rc: DEBUG: adding rule (add path null unhide)
/etc/rc: DEBUG: adding rule (add path zero unhide)
/etc/rc: DEBUG: adding rule (add path crypto unhide)
/etc/rc: DEBUG: adding rule (add path random unhide)
/etc/rc: DEBUG: adding rule (add path urandom unhide)
/etc/rc: DEBUG: found ruleset: devfsrules_unhide_login=3
/etc/rc: DEBUG: adding rule (add path 'ptyp*' unhide)
/etc/rc: DEBUG: adding rule (add path 'ptyq*' unhide)
/etc/rc: DEBUG: adding rule (add path 'ptyr*' unhide)
/etc/rc: DEBUG: adding rule (add path 'ptys*' unhide)
/etc/rc: DEBUG: adding rule (add path 'ptyP*' unhide)
/etc/rc: DEBUG: adding rule (add path 'ptyQ*' unhide)
/etc/rc: DEBUG: adding rule (add path 'ptyR*' unhide)
/etc/rc: DEBUG: adding rule (add path 'ptyS*' unhide)
/etc/rc: DEBUG: adding rule (add path 'ttyp*' unhide)
/etc/rc: DEBUG: adding rule (add path 'ttyq*' unhide)
/etc/rc: DEBUG: adding rule (add path 'ttyr*' unhide)
/etc/rc: DEBUG: adding rule (add path 'ttys*' unhide)
/etc/rc: DEBUG: adding rule (add path 'ttyP*' unhide)
/etc/rc: DEBUG: adding rule (add path 'ttyQ*' unhide)
/etc/rc: DEBUG: adding rule (add path 'ttyR*' unhide)
/etc/rc: DEBUG: adding rule (add path 'ttyS*' unhide)
/etc/rc: DEBUG: adding rule (add path ptmx unhide)
/etc/rc: DEBUG: adding rule (add path pts unhide)
/etc/rc: DEBUG: adding rule (add path 'pts/*' unhide)
/etc/rc: DEBUG: adding rule (add path fd unhide)
/etc/rc: DEBUG: adding rule (add path 'fd/*' unhide)
/etc/rc: DEBUG: adding rule (add path stdin unhide)
/etc/rc: DEBUG: adding rule (add path stdout unhide)
/etc/rc: DEBUG: adding rule (add path stderr unhide)
/etc/rc: DEBUG: found ruleset: devfsrules_jail=4
/etc/rc: DEBUG: adding rule (add include $devfsrules_hide_all)
/etc/rc: DEBUG: adding rule (add include $devfsrules_unhide_basic)
/etc/rc: DEBUG: adding rule (add include $devfsrules_unhide_login)
/etc/rc: DEBUG: reading rulesets from file (/etc/devfs.rules)
/etc/rc: DEBUG: found ruleset: nut_usb=10
/etc/rc: DEBUG: adding rule (add path 'ugen0' group wheel user uucp mode 0660)
/etc/rc: DEBUG: adding rule (add path 'uhid0' group wheel user uucp mode 0660)
/etc/rc: DEBUG: devfs_init_rulesets: devfs rulesets initialized
/etc/rc: DEBUG: devfs_set_ruleset: setting ruleset (1) on mount-point (/var/named/dev)
/etc/rc: DEBUG: checkyesno: named_auto_forward is set to NO.
/etc/rc: DEBUG: run_rc_command: doit: /usr/sbin/named -c /etc/namedb/named.conf -t /var/named -u bind
re0: link state changed to UP
Sep 13 03:44:05 mary-teresa named[1577]: the working directory is not writable
/etc/rc: DEBUG: run_rc_command: start_postcmd: named_poststart 
/etc/rc: DEBUG: checkyesno: named_symlink_enable is set to YES.
/etc/rc: DEBUG: checkyesno: named_wait is set to NO.
/etc/rc: DEBUG: checkyesno: ntpdate_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: ntpdate_start 
Setting date via ntp.
Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host europe.pool.ntp.org

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host europe.pool.ntp.org

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host europe.pool.ntp.org

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host montpelier.ilan.caltech.edu

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host clock.via.net

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host vega.cbk.poznan.pl

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host time-A.timefreq.bldrdoc.gov

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host ntp.nasa.gov

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host pool.ntp.org

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host clock.redhat.com

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host clock3.redhat.com

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host ntp0.linx.net

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host ntp.time.in.ua

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host 0.freebsd.pool.ntp.org

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host 1.freebsd.pool.ntp.org

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host 2.freebsd.pool.ntp.org

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host ntp.colocall.net

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host burka.carrier.kiev.ua

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host ua.pool.ntp.org

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host ntp2.time.in.ua

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host ns2.infomir.com.ua

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host time6.ipv6.uni-muenster.de

Error : hostname nor servname provided, or not known
13 Sep 03:44:06 
ntpdate[1595]: can't find host ntp.rhrk.uni-kl.de

13 Sep 03:44:06 
ntpdate[1595]: no servers can be used, exiting
/etc/rc: DEBUG: checkyesno: rpcbind_enable is set to NO.
/etc/rc: DEBUG: checkyesno: nfs_client_enable is set to YES.
/etc/rc: DEBUG: load_kld: nfsclient kernel module already loaded.
/etc/rc: DEBUG: run_rc_command: doit: nfsclient_start 
/etc/rc: DEBUG: run_rc_command: doit: nisdomain_start 
/etc/rc: DEBUG: checkyesno: nis_server_enable is set to NO.
/etc/rc: DEBUG: checkyesno: nis_client_enable is set to NO.
/etc/rc: DEBUG: checkyesno: nis_ypset_enable is set to NO.
/etc/rc: DEBUG: checkyesno: amd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: atm_enable is set to NO.
/etc/rc: DEBUG: checkyesno: auditd_enable is set to NO.
/etc/rc: DEBUG: run_rc_command: doit: cleartmp_start 
/etc/rc: DEBUG: checkyesno: clear_tmp_enable is set to NO.
/etc/rc: DEBUG: checkyesno: clear_tmp_X is set to YES.
/etc/rc: DEBUG: checkyesno: clear_tmp_X is set to YES.
/etc/rc: DEBUG: checkyesno: dmesg_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: do_dmesg 
/etc/rc: DEBUG: checkyesno: ipxrouted_enable is set to NO.
/etc/rc: DEBUG: checkyesno: kerberos5_server_enable is set to NO.
/etc/rc: DEBUG: checkyesno: kadmind5_server_enable is set to NO.
/etc/rc: DEBUG: checkyesno: keyserv_enable is set to NO.
/etc/rc: DEBUG: checkyesno: kpasswdd_server_enable is set to NO.
/etc/rc: DEBUG: checkyesno: nfsuserd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: gssd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: quota_enable is set to NO.
/etc/rc: DEBUG: checkyesno: nfs_server_enable is set to NO.
/etc/rc: DEBUG: pid file (/var/run/mountd.pid): not readable.
/etc/rc: DEBUG: checkyesno: mountd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: nfs_server_enable is set to NO.
/etc/rc: DEBUG: checkyesno: rpc_statd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: rpc_lockd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: rpc_statd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: rpc_lockd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: pppoed_enable is set to NO.
/etc/rc: DEBUG: run_rc_command: doit: pwcheck_start 
/etc/rc: DEBUG: checkyesno: virecover_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: virecover_start 
/etc/rc: DEBUG: pid file (/var/run/monit.pid): not readable.
/etc/rc: DEBUG: checkyesno: monit_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: /usr/local/bin/monit  -c /usr/local/etc/monitrc
Starting monit daemon
/etc/rc: DEBUG: pid file (/var/run/mpd5.pid): not readable.
/etc/rc: DEBUG: checkyesno: mpd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: apm_enable is set to NO.
/etc/rc: DEBUG: checkyesno: apmd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: bootparamd_enable is set to NO.
/etc/rc: DEBUG: pid file (/var/run/hcsecd.pid): not readable.
/etc/rc: DEBUG: checkyesno: hcsecd_enable is set to NO.
/etc/rc: DEBUG: pid file (/var/run/bthidd.pid): not readable.
/etc/rc: DEBUG: checkyesno: bthidd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: cached_enable is set to NO.
/etc/rc: DEBUG: run_rc_command: doit: local_start 
Starting local daemons:
DHCPREQUEST on vr1 to 255.255.255.255 port 67

DHCPACK from 192.168.60.1

bound to 192.168.60.194 -- renewal in 5400 seconds.

Loading /lib/libalias_cuseeme.so
Loading /lib/libalias_ftp.so
Loading /lib/libalias_irc.so
Loading /lib/libalias_nbt.so
Loading /lib/libalias_pptp.so
Loading /lib/libalias_skinny.so
Loading /lib/libalias_smedia.so
natd: 
Unable to bind divert socket.
: 
Address already in use
tun1: link state changed to UP
tun2: link state changed to UP
Sep 13 03:44:10 portfwd[2013]: line    2, token  262 ';'
Sep 13 03:44:10 portfwd[2013]: line    3, token  258 '2802'
Sep 13 03:44:10 portfwd[2013]: line    3, token  266 '{'
Sep 13 03:44:10 portfwd[2013]: line    3, token  268 '=>'
Sep 13 03:44:10 portfwd[2013]: line    3, token  258 '10.0.0.10'
Sep 13 03:44:10 portfwd[2013]: line    3, token  261 ':'
Sep 13 03:44:10 portfwd[2013]: line    3, token  258 '2802'
Sep 13 03:44:10 portfwd[2013]: line    3, token  267 '}'
Sep 13 03:44:10 portfwd[2013]: line    3, token  262 ';'
Sep 13 03:44:10 portfwd[2013]: line    4, token  258 '6991'
Sep 13 03:44:10 portfwd[2013]: line    4, token  266 '{'
Sep 13 03:44:10 portfwd[2013]: line    4, token  268 '=>'
Sep 13 03:44:10 portfwd[2013]: line    4, token  258 '10.0.0.2'
Sep 13 03:44:10 portfwd[2013]: line    4, token  261 ':'
Sep 13 03:44:10 portfwd[2013]: line    4, token  258 '6991'
Sep 13 03:44:10 portfwd[2013]: line    4, token  267 '}'
Sep 13 03:44:10 portfwd[2013]: line    9, token  268 '=>'
Sep 13 03:44:10 portfwd[2013]: line    9, token  258 '10.0.0.10'
Sep 13 03:44:10 portfwd[2013]: line    9, token  258 '6113-6119'
Sep 13 03:44:10 portfwd[2013]: line    9, token  267 '}'
Sep 13 03:44:10 portfwd[2013]: line    9, token  262 ';'
Sep 13 03:44:10 portfwd[2013]: line   10, token  258 '6950-6990'
Sep 13 03:44:10 portfwd[2013]: 0.0.0.0
Sep 13 03:44:10 portfwd[2013]: /0
Sep 13 03:44:10 portfwd[2013]: :
Sep 13 03:44:10 portfwd[2013]: 0+65535
Sep 13 03:44:10 portfwd[2013]:  => 
Sep 13 03:44:10 portfwd[2013]: 10.0.0.10
Sep 13 03:44:10 portfwd[2013]: :6112
Sep 13 03:44:10 portfwd[2013]: 
}
Sep 13 03:44:10 portfwd[2013]: 
Sep 13 03:44:10 portfwd[2013]: 6200
Sep 13 03:44:10 portfwd[2013]:  /* uid: -1, gid: -1 */
Sep 13 03:44:10 portfwd[2013]:  /* listen: 0.0.0.0 */
Sep 13 03:44:10 portfwd[2013]: 
{
Sep 13 03:44:10 portfwd[2013]: 0.0.0.0
Sep 13 03:44:10 portfwd[2013]: /0
Sep 13 03:44:10 portfwd[2013]: :
Sep 13 03:44:10 portfwd[2013]: 0+65535
Sep 13 03:44:10 portfwd[2013]:  => 
Sep 13 03:44:10 portfwd[2013]: 10.0.0.10
Sep 13 03:44:10 portfwd[2013]: :6200
Sep 13 03:44:10 portfwd[2013]: 
}
Sep 13 03:44:10 portfwd[2013]: 
Sep 13 03:44:10 portfwd[2013]: 7456
Sep 13 03:44:10 portfwd[2013]:  /* uid: -1, gid: -1 */
Sep 13 03:44:10 portfwd[2013]:  /* listen: 0.0.0.0 */
Sep 13 03:44:10 portfwd[2013]: 
{
Sep 13 03:44:10 portfwd[2013]: 0.0.0.0
Sep 13 03:44:10 portfwd[2013]: /0
Sep 13 03:44:10 portfwd[2013]: :
Sep 13 03:44:10 portfwd[2013]: 0+65535
Sep 13 03:44:10 portfwd[2013]:  => 
Sep 13 03:44:10 portfwd[2013]: 10.0.0.10
Sep 13 03:44:10 portfwd[2013]: :7456
Sep 13 03:44:10 portfwd[2013]: 
}
Sep 13 03:44:10 portfwd[2013]: 
Sep 13 03:44:10 portfwd[2013]: 6113
Sep 13 03:44:10 portfwd[2013]:  /* uid: -1, gid: -1 */
Sep 13 03:44:10 portfwd[2013]:  /* listen: 0.0.0.0 */
Sep 13 03:44:10 portfwd[2013]: 
{
Sep 13 03:44:10 portfwd[2013]: 0.0.0.0
Sep 13 03:44:10 portfwd[2013]: /0
Sep 13 03:44:10 portfwd[2013]: :
Sep 13 03:44:10 portfwd[2013]: 0+65535
Sep 13 03:44:10 portfwd[2013]:  => 
Sep 13 03:44:10 portfwd[2013]: 10.0.0.10
Sep 13 03:44:10 portfwd[2013]: :6113
Sep 13 03:44:10 portfwd[2013]: 
}
Sep 13 03:44:10 portfwd[2013]: 
Sep 13 03:44:10 portfwd[2013]: 6950
Sep 13 03:44:11 portfwd[2013]:  /* uid: -1, gid: -1 */
Sep 13 03:44:11 portfwd[2013]:  /* listen: 0.0.0.0 */
Sep 13 03:44:11 portfwd[2013]: 
{
Sep 13 03:44:11 portfwd[2013]: 0.0.0.0
Sep 13 03:44:11 portfwd[2013]: /0
Sep 13 03:44:11 portfwd[2013]: :
Please set a terminal type.
/usr/local/etc/rc.d/ngnat.sh: DEBUG: checkyesno: ngnat_enable is set to YES.
/usr/local/etc/rc.d/ngnat.sh: DEBUG: run_rc_command: doit: ngnat_start 
Setup ng_nat and ng_netflow
ngctl: 
send msg
: 
Invalid argument
ngctl: 
line 29: error in file

Sep 13 03:44:12 mary-teresa named[2276]: the working directory is not writable
Sep 13 03:44:13 mary-teresa named[2392]: could not listen on UDP socket: address in use
Sep 13 03:44:13 mary-teresa named[2392]: creating IPv4 interface re0 failed; interface ignored
Sep 13 03:44:13 mary-teresa named[2392]: could not listen on UDP socket: address in use
Sep 13 03:44:13 mary-teresa named[2392]: creating IPv4 interface vr1 failed; interface ignored
Sep 13 03:44:13 mary-teresa named[2392]: could not listen on UDP socket: address in use
Sep 13 03:44:13 mary-teresa named[2392]: creating IPv6 interface lo0 failed; interface ignored
Sep 13 03:44:13 mary-teresa named[2392]: could not listen on UDP socket: address in use
Sep 13 03:44:13 mary-teresa named[2392]: creating IPv4 interface lo0 failed; interface ignored
Sep 13 03:44:13 mary-teresa named[2392]: could not listen on UDP socket: address in use
Sep 13 03:44:13 mary-teresa named[2392]: creating IPv4 interface tun1 failed; interface ignored
Sep 13 03:44:13 mary-teresa named[2392]: could not listen on UDP socket: address in use
Sep 13 03:44:13 mary-teresa named[2392]: creating IPv4 interface tun2 failed; interface ignored
Sep 13 03:44:13 mary-teresa named[2392]: the working directory is not writable
vr1: promiscuous mode enabled
/etc/rc.d/cron: DEBUG: checkyesno: cron_dst is set to YES.
/etc/rc.d/cron: DEBUG: pid file (/var/run/cron.pid): not readable.
/etc/rc.d/cron: DEBUG: checkyesno: cron_enable is set to YES.
/etc/rc.d/cron: DEBUG: pid file (/var/run/cron.pid): not readable.
/etc/rc.d/cron: DEBUG: checkyesno: cron_enable is set to YES.
cron not running? (check /var/run/cron.pid).
/etc/rc.d/cron: DEBUG: pid file (/var/run/cron.pid): not readable.
/etc/rc.d/cron: DEBUG: checkyesno: cron_enable is set to YES.
Starting cron.
/etc/rc.d/cron: DEBUG: run_rc_command: doit: /usr/sbin/cron  -s 
/etc/rc.d/bsnmpd: DEBUG: pid file (/var/run/snmpd.pid): not readable.
/etc/rc.d/bsnmpd: DEBUG: checkyesno: bsnmpd_enable is set to YES.
/etc/rc.d/bsnmpd: DEBUG: pid file (/var/run/snmpd.pid): not readable.
/etc/rc.d/bsnmpd: DEBUG: checkyesno: bsnmpd_enable is set to YES.
bsnmpd not running? (check /var/run/snmpd.pid).
/etc/rc.d/bsnmpd: DEBUG: pid file (/var/run/snmpd.pid): not readable.
/etc/rc.d/bsnmpd: DEBUG: checkyesno: bsnmpd_enable is set to YES.
Starting bsnmpd.
/etc/rc.d/bsnmpd: DEBUG: run_rc_command: doit: /usr/sbin/bsnmpd -D dump 
/usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/   /usr/share/sendmail/cf/m4/cf.m4 mary-teresa.otrada.od.ua.mc > mary-teresa.otrada.od.ua.cf
/usr/bin/m4 -D_CF_DIR_=/usr/share/sendmail/cf/   /usr/share/sendmail/cf/m4/cf.m4 mary-teresa.otrada.od.ua.submit.mc > mary-teresa.otrada.od.ua.submit.cf
Restarting:
/etc/rc.sendmail: restart-mta: /var/run/sendmail.pid not found
/etc/rc.sendmail: restart-mspq: /var/spool/clientmqueue/sm-client.pid not found
.
/usr/local/etc/rc.d/dovecot: DEBUG: checkyesno: dovecot_enable is set to YES.
/usr/local/etc/rc.d/dovecot: DEBUG: pid file (/var/run/dovecot/master.pid): not readable.
/usr/local/etc/rc.d/dovecot: DEBUG: checkyesno: dovecot_enable is set to YES.
/usr/local/etc/rc.d/dovecot: DEBUG: run_rc_command: doit: restart_cmd 
/usr/local/etc/rc.d/dovecot: DEBUG: pid file (/var/run/dovecot/master.pid): not readable.
/usr/local/etc/rc.d/dovecot: DEBUG: checkyesno: dovecot_enable is set to YES.
dovecot not running? (check /var/run/dovecot/master.pid).
/usr/local/etc/rc.d/dovecot: DEBUG: pid file (/var/run/dovecot/master.pid): not readable.
/usr/local/etc/rc.d/dovecot: DEBUG: checkyesno: dovecot_enable is set to YES.
/usr/local/etc/rc.d/dovecot: DEBUG: run_rc_command: start_precmd: start_precmd 
Starting dovecot.
/usr/local/etc/rc.d/dovecot: DEBUG: run_rc_command: doit: /usr/local/sbin/dovecot  -c /usr/local/etc/dovecot.conf
/usr/local/etc/rc.d/fetchmail: DEBUG: pid file (/var/run/fetchmail/fetchmail.pid): not readable.
/usr/local/etc/rc.d/fetchmail: DEBUG: checkyesno: fetchmail_enable is set to YES.
/usr/local/etc/rc.d/fetchmail: DEBUG: pid file (/var/run/fetchmail/fetchmail.pid): not readable.
/usr/local/etc/rc.d/fetchmail: DEBUG: checkyesno: fetchmail_enable is set to YES.
fetchmail not running? (check /var/run/fetchmail/fetchmail.pid).
/usr/local/etc/rc.d/fetchmail: DEBUG: pid file (/var/run/fetchmail/fetchmail.pid): not readable.
/usr/local/etc/rc.d/fetchmail: DEBUG: checkyesno: fetchmail_enable is set to YES.
Starting fetchmail.
/usr/local/etc/rc.d/fetchmail: DEBUG: run_rc_command: doit: su -m fetchmail -c 'sh -c "/usr/local/bin/fetchmail -f /usr/local/etc/fetchmailrc 				--pidfile /var/run/fetchmail/fetchmail.pid 				-d 900 				--syslog "'
fetchmail: Warning: syslog and logfile are set. Check both for logs!
/usr/local/etc/rc.d/gateway6: DEBUG: checkyesno: gateway6_enable is set to YES.
/usr/local/etc/rc.d/gateway6: DEBUG: checkyesno: gateway6_enable is set to YES.
gateway6 not running?
/usr/local/etc/rc.d/gateway6: DEBUG: checkyesno: gateway6_enable is set to YES.
Starting gateway6.
/usr/local/etc/rc.d/gateway6: DEBUG: run_rc_command: doit: /usr/local/bin/gw6c  
Gateway6 Client v5.0-RELEASE build May 31 2009-00:11:26 
Sep 13 03:44:24 mary-teresa gw6c: Gateway6 Client v5.0-RELEASE build May 31 2009-00:11:26 
Received a TSP redirection message from broker authenticated.freenet6.net (1200 Redirection).
Sep 13 03:44:25 mary-teresa gw6c: Received a TSP redirection message from broker authenticated.freenet6.net (1200 Redirection^M).
The broker redirection list is [ amsterdam.freenet6.net, montreal.freenet6.net ].
Sep 13 03:44:25 mary-teresa gw6c: The broker redirection list is [ amsterdam.freenet6.net, montreal.freenet6.net ].
Sep 13 03:44:25 mary-teresa su: vlad11 to root on /dev/pts/1
The optimized broker redirection list is [ amsterdam.freenet6.net, montreal.freenet6.net ].
Sep 13 03:44:25 mary-teresa gw6c: The optimized broker redirection list is [ amsterdam.freenet6.net, montreal.freenet6.net ].
Connection to amsterdam.freenet6.net established.
Sep 13 03:44:25 mary-teresa gw6c: Connection to amsterdam.freenet6.net established.
.
/etc/rc: DEBUG: checkyesno: lpd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: update_motd is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: motd_start 
re0: link state changed to DOWN
/etc/rc: DEBUG: run_rc_command: doit: mountlate_start 
/etc/rc: DEBUG: checkyesno: nscd_enable is set to NO.
/etc/rc: DEBUG: pid file (/var/run/ntpd.pid): not readable.
/etc/rc: DEBUG: checkyesno: ntpd_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: start_precmd: ntpd_precmd 
/etc/rc: DEBUG: checkyesno: ntpd_sync_on_start is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: /usr/sbin/ntpd -g -c /etc/ntp.conf -p /var/run/ntpd.pid 
Sep 13 03:44:26 mary-teresa gw6c: Your IPv6 address is 2001:05c0:1400:000b:0000:0000:0000:27e9.
Sep 13 03:44:26 mary-teresa gw6c: Your IPv6 prefix is 2001:05c0:1503:3400:0000:0000:0000:0000/56.
/etc/rc: DEBUG: checkyesno: powerd_enable is set to NO.
/etc/rc: DEBUG: pid file (/var/run/rarpd.pid): not readable.
/etc/rc: DEBUG: checkyesno: rarpd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: sdpd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: rfcomm_pppd_server_enable is set to NO.
/etc/rc: DEBUG: checkyesno: rtadvd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: rwhod_enable is set to NO.
/etc/rc: DEBUG: checkyesno: timed_enable is set to NO.
/etc/rc: DEBUG: checkyesno: ugidfw_enable is set to NO.
Sep 13 03:44:27 mary-teresa ntpd[2669]: bind() fd 23, family 28, port 123, scope 0, addr 2001:5c0:1503:3400::1, in6_is_addr_multicast=0 flags=0x11 fails: Can't assign requested address
Sep 13 03:44:27 mary-teresa ntpd[2669]: unable to create socket on re0 (3) for 2001:5c0:1503:3400::1#123
Sep 13 03:44:27 mary-teresa ntpd[2669]: bind() fd 29, family 28, port 123, scope 0, addr 2001:5c0:1400:b::27e9, in6_is_addr_multicast=0 flags=0x13 fails: Can't assign requested address
Sep 13 03:44:27 mary-teresa ntpd[2669]: unable to create socket on gif0 (10) for 2001:5c0:1400:b::27e9#123
/etc/rc: DEBUG: checkyesno: nis_yppasswdd_enable is set to NO.
/etc/rc: DEBUG: pid file (/var/db/nut/upsd.pid): not readable.
/etc/rc: DEBUG: checkyesno: nut_enable is set to NO.
/etc/rc: DEBUG: checkyesno: nut_upslog_enable is set to NO.
/etc/rc: DEBUG: pid file (/var/db/nut/upsmon.pid): not readable.
/etc/rc: DEBUG: checkyesno: nut_upsmon_enable is set to NO.
/etc/rc: DEBUG: checkyesno: proftpd_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: /usr/local/sbin/proftpd  
/etc/rc: DEBUG: checkyesno: samba_enable is set to YES.
/etc/rc: DEBUG: checkyesno: samba_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: start_precmd: samba_start_precmd 
Removing stale Samba tdb files: 
.
.
.
.
.
.
.
.
 done
/etc/rc: DEBUG: run_rc_command: doit: samba_cmd 
/etc/rc: DEBUG: pid file (/var/run/nmbd.pid): not readable.
/etc/rc: DEBUG: checkyesno: nmbd_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: /usr/local/sbin/nmbd "-D" -s /usr/local/etc/smb.conf
/etc/rc: DEBUG: pid file (/var/run/smbd.pid): not readable.
/etc/rc: DEBUG: checkyesno: smbd_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: /usr/local/sbin/smbd "-D" -s /usr/local/etc/smb.conf
re0: link state changed to UP
/etc/rc: DEBUG: pid file (/var/run/winbindd.pid): not readable.
/etc/rc: DEBUG: checkyesno: winbindd_enable is set to NO.
/etc/rc: DEBUG: pid file (/var/run/smartd.pid): not readable.
/etc/rc: DEBUG: checkyesno: smartd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: webmin_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: /usr/local/etc/webmin/start  
/etc/rc: DEBUG: checkyesno: squid_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: su -m squid -c 'sh -c "cd /usr/local/squid/logs && /usr/local/sbin/squid -D "'
/etc/rc: WARNING: failed to start squid
/etc/rc: DEBUG: checkyesno: spamass_milter_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: /usr/local/sbin/spamass-milter -f -p /var/run/spamass-milter.sock  
/etc/rc: DEBUG: run_rc_command: start_postcmd: start_postcmd 
/etc/rc: DEBUG: pid file (/var/run/snmptrapd.pid): not readable.
/etc/rc: DEBUG: checkyesno: snmptrapd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: snmpd_enable is set to NO.
/etc/rc: DEBUG: pid file (/var/run/saslauthd/saslauthd.pid): not readable.
/etc/rc: DEBUG: checkyesno: saslauthd_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: /usr/local/sbin/saslauthd -a getpwent 
/etc/rc: DEBUG: pid file (/var/run/spamd/spamd.pid): not readable.
/etc/rc: DEBUG: checkyesno: spamd_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: /usr/local/bin/spamd -c -d  -r  -u spamd  -d -r /var/run/spamd/spamd.pid
/etc/rc: DEBUG: pid file (/var/run/rsyncd.pid): not readable.
/etc/rc: DEBUG: checkyesno: rsyncd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: netgraph_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: start_precmd: netgraph_prevar 
/etc/rc: DEBUG: check netflow
/etc/rc: DEBUG: run_rc_command: doit: netgraph_start 
/etc/rc: DEBUG: tos for re0 require to set to 
/etc/rc: DEBUG: checkyes netflow_re0
/etc/rc: DEBUG: checking require set tos:  , tos_set is 0
/etc/rc: DEBUG: tos for vr0 require to set to 
/etc/rc: DEBUG: checkyes netflow_vr0
/etc/rc: DEBUG: checking require set tos:  , tos_set is 0
/etc/rc: DEBUG: tos for vr1 require to set to 
/etc/rc: DEBUG: checkyes netflow_vr1
/etc/rc: DEBUG: checking require set tos:  , tos_set is 0
/etc/rc: DEBUG: pid file (/var/db/mysql/mary-teresa.otrada.od.ua.pid): not readable.
/etc/rc: DEBUG: checkyesno: mysql_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: start_precmd: mysql_prestart 
/etc/rc: DEBUG: checkyesno: mysql_limits is set to NO.
/etc/rc: DEBUG: run_rc_command: doit: su -m mysql -c 'sh -c "/usr/local/bin/mysqld_safe  --defaults-extra-file=/var/db/mysql/my.cnf --user=mysql --datadir=/var/db/mysql --pid-file=/var/db/mysql/mary-teresa.otrada.od.ua.pid --default-character-set=utf8 --character-set-server=utf8 --collation-server=utf8_unicode_ci > /dev/null 2>&1 &"'
/etc/rc: DEBUG: run_rc_command: start_postcmd: mysql_poststart 
/etc/rc: DEBUG: pid file (/var/spool/MIMEDefang/mimedefang-multiplexor.pid): not readable.
/etc/rc: DEBUG: checkyesno: mimedefang_enable is set to NO.
/etc/rc: DEBUG: checkyesno: mbmon_enable is set to NO.
/etc/rc: DEBUG: checkyesno: igmpproxy_enable is set to NO.
/etc/rc: DEBUG: checkyesno: htcacheclean_enable is set to NO.
/etc/rc: DEBUG: pid file (/var/run/dbus/dbus.pid): not readable.
/etc/rc: DEBUG: checkyesno: dbus_enable is set to NO.
/etc/rc: DEBUG: pid file (/var/run/hald/hald.pid): not readable.
/etc/rc: DEBUG: checkyesno: hald_enable is set to NO.
/etc/rc: DEBUG: checkyesno: gateway6_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: /usr/local/bin/gw6c  
Gateway6 Client v5.0-RELEASE build May 31 2009-00:11:26 
Sep 13 03:44:35 mary-teresa gw6c: Gateway6 Client v5.0-RELEASE build May 31 2009-00:11:26 
Received a TSP redirection message from broker authenticated.freenet6.net (1200 Redirection).
Sep 13 03:44:35 mary-teresa gw6c: Received a TSP redirection message from broker authenticated.freenet6.net (1200 Redirection^M).
The broker redirection list is [ amsterdam.freenet6.net, montreal.freenet6.net ].
Sep 13 03:44:35 mary-teresa gw6c: The broker redirection list is [ amsterdam.freenet6.net, montreal.freenet6.net ].
The optimized broker redirection list is [ amsterdam.freenet6.net, montreal.freenet6.net ].
Sep 13 03:44:35 mary-teresa gw6c: The optimized broker redirection list is [ amsterdam.freenet6.net, montreal.freenet6.net ].
Connection to amsterdam.freenet6.net established.
Sep 13 03:44:35 mary-teresa gw6c: Connection to amsterdam.freenet6.net established.
/etc/rc: DEBUG: pid file (/var/run/clamav/clamd.pid): not readable.
/etc/rc: DEBUG: checkyesno: clamav_clamd_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: start_precmd: clamav_clamd_precmd 
in6_purgeaddr: deletion failed
/etc/rc: DEBUG: run_rc_command: doit: /usr/local/sbin/clamd  
re0: link state changed to DOWN
Sep 13 03:44:36 mary-teresa snmpd[2447]: send: Connection refused
Sep 13 03:44:36 mary-teresa rtadvd[2660]: <ra_output> sendmsg on re0: Can't assign requested address
Sep 13 03:44:36 mary-teresa gw6c: Your IPv6 address is 2001:05c0:1400:000b:0000:0000:0000:27e9.
Sep 13 03:44:36 mary-teresa gw6c: Your IPv6 prefix is 2001:05c0:1503:3400:0000:0000:0000:0000/56.
LibClamAV Warning: ***********************************************************
LibClamAV Warning: ***  This version of the ClamAV engine is outdated.     ***
LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/support/faq ***
LibClamAV Warning: ***********************************************************
LibClamAV Warning: ***********************************************************
LibClamAV Warning: ***  This version of the ClamAV engine is outdated.     ***
LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/support/faq ***
LibClamAV Warning: ***********************************************************
/etc/rc: DEBUG: pid file (/var/run/clamav/freshclam.pid): not readable.
/etc/rc: DEBUG: checkyesno: clamav_freshclam_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: /usr/local/bin/freshclam  --daemon -p /var/run/clamav/freshclam.pid
/etc/rc: DEBUG: pid file (/var/run/clamav/clamav-milter.pid): not readable.
/etc/rc: DEBUG: checkyesno: clamav_milter_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: start_precmd: start_precmd 
/etc/rc: DEBUG: checkyesno: clamav_clamd_enable is set to YES.
Waiting for clamd socket.. 

/etc/rc: DEBUG: run_rc_command: doit: /usr/local/sbin/clamav-milter --pidfile /var/run/clamav/clamav-milter.pid --headers --postmaster-only --external --outgoing --max-children=50 /var/run/clamav/clmilter.sock 
/etc/rc: DEBUG: run_rc_command: start_postcmd: start_postcmd 
Waiting for clamav-milter socket.. 

/etc/rc: DEBUG: checkyesno: sendmail_enable is set to YES.
/etc/rc: DEBUG: checkyesno: sendmail_submit_enable is set to NO.
/etc/rc: DEBUG: pid file (/var/run/sendmail.pid): not readable.
/etc/rc: DEBUG: checkyesno: sendmail_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: start_precmd: sendmail_precmd 
/etc/rc: DEBUG: checkyesno: sendmail_enable is set to YES.
/etc/rc: DEBUG: checkyesno: sendmail_rebuild_aliases is set to NO.
/etc/rc: DEBUG: run_rc_command: doit: /usr/sbin/sendmail -L sm-mta -bd -q30m 
re0: link state changed to UP
/etc/rc: DEBUG: checkyesno: sendmail_submit_enable is set to NO.
/etc/rc: DEBUG: checkyesno: sendmail_outbound_enable is set to NO.
/etc/rc: DEBUG: pid file (/var/spool/clientmqueue/sm-client.pid): not readable.
/etc/rc: DEBUG: checkyesno: sendmail_msp_queue_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: start_precmd: sendmail_precmd 
/etc/rc: DEBUG: checkyesno: sendmail_msp_queue_enable is set to YES.
/etc/rc: DEBUG: checkyesno: sendmail_rebuild_aliases is set to NO.
/etc/rc: DEBUG: run_rc_command: doit: /usr/sbin/sendmail -L sm-msp-queue -Ac -q30m 
/usr/local/etc/rc.d/fetchmail: DEBUG: checkyesno: fetchmail_enable is set to YES.
/usr/local/etc/rc.d/fetchmail: DEBUG: run_rc_command: doit: su -m fetchmail -c 'sh -c "/usr/local/bin/fetchmail -f /usr/local/etc/fetchmailrc 				--pidfile /var/run/fetchmail/fetchmail.pid 				-d 900 				--syslog "'
fetchmail: can't accept options while a background fetchmail is running.
/usr/local/etc/rc.d/fetchmail: WARNING: failed to start fetchmail
/etc/rc: DEBUG: checkyesno: dovecot_enable is set to YES.
/etc/rc: DEBUG: checkyesno: dovecot_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: start_precmd: start_precmd 
/etc/rc: DEBUG: run_rc_command: doit: /usr/local/sbin/dovecot  -c /usr/local/etc/dovecot.conf
Fatal: Dovecot is already running with PID 2521 (read from /var/run/dovecot/master.pid)
/etc/rc: WARNING: failed to start dovecot
/etc/rc: DEBUG: checkyesno: ddclient_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: /usr/local/sbin/ddclient -daemon 300 
/etc/rc: DEBUG: checkyesno: bsdstats_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: /usr/local/etc/periodic/monthly/300.statistics -nodelay 
Posting monthly OS statistics to rpt.bsdstats.org
meuh
/etc/rc: DEBUG: checkyesno: arpwatch_enable is set to NO.
/etc/rc: DEBUG: checkyesno: apache22_http_accept_enable is set to YES.
/etc/rc: DEBUG: checkyesno: apache22_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: start_precmd: apache22_prestart 
Performing sanity check on apache22 configuration:
Syntax OK
/etc/rc: DEBUG: checkyesno: apache22limits_enable is set to NO.
/etc/rc: DEBUG: run_rc_command: doit: /usr/local/sbin/httpd  
(48)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
/etc/rc: WARNING: failed to start apache22
/etc/rc: DEBUG: checkyesno: nis_ypxfrd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: rpc_ypupdated_enable is set to NO.
/etc/rc: DEBUG: pid file (/var/run/watchdogd.pid): not readable.
/etc/rc: DEBUG: checkyesno: watchdogd_enable is set to NO.
/etc/rc: DEBUG: run_rc_command: start_precmd: syscons_precmd 
/etc/rc: DEBUG: run_rc_command: doit: syscons_start 
Configuring syscons:
 keymap
 blanktime
.
/etc/rc: DEBUG: checkyesno: sshd_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: start_precmd: sshd_precmd 
/etc/rc: DEBUG: run_rc_command: doit: /usr/sbin/sshd  
Sep 13 03:44:43 mary-teresa sshd[3321]: error: Bind to port 22 on :: failed: Address already in use.
/etc/rc: DEBUG: checkyesno: cron_dst is set to YES.
/etc/rc: DEBUG: checkyesno: cron_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: /usr/sbin/cron  -s 
cron: cron already running, pid: 2429
/etc/rc: WARNING: failed to start cron
Sep 13 03:44:43 mary-teresa sshd[3321]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Sep 13 03:44:43 mary-teresa sshd[3321]: fatal: Cannot bind any address.
/etc/rc: DEBUG: checkyesno: jail_enable is set to NO.
/etc/rc: DEBUG: run_rc_command: doit: pkg_start 
Local package initialization:
/usr/local/etc/rc.d/ngnat.sh: DEBUG: checkyesno: ngnat_enable is set to YES.
/usr/local/etc/rc.d/ngnat.sh: DEBUG: run_rc_command: doit: ngnat_start 
Setup ng_nat and ng_netflow
ngctl: 
send msg
: 
File exists
ngctl: 
line 1: error in file

.
/etc/rc.d/sysctl: DEBUG: run_rc_command: doit: sysctl_start last 
/etc/rc: DEBUG: checkyesno: kern_securelevel_enable is set to NO.
/etc/rc: DEBUG: checkyesno: nfscbd_enable is set to NO.
/etc/rc: DEBUG: pid file (/var/run/moused.pid): not readable.
/etc/rc: DEBUG: checkyesno: moused_enable is set to NO.
/etc/rc: DEBUG: checkyesno: mixer_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: mixer_start 
/etc/rc: DEBUG: run_rc_command: doit: kernel_start 
/etc/rc: DEBUG: pid file (/var/run/isdnd.pid): not readable.
/etc/rc: DEBUG: checkyesno: isdn_enable is set to .
/etc/rc: WARNING: $isdn_enable is not set properly - see rc.conf(5).
/etc/rc: DEBUG: pid file (/var/run/inetd.pid): not readable.
/etc/rc: DEBUG: checkyesno: inetd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: idmapd_enable is set to .
/etc/rc: WARNING: $idmapd_enable is not set properly - see rc.conf(5).
/etc/rc: DEBUG: pid file (/var/run/hostapd.pid): not readable.
/etc/rc: DEBUG: checkyesno: hostapd_enable is set to NO.
/etc/rc: DEBUG: run_rc_command: doit: geli2_start 
/etc/rc: DEBUG: pid file (/var/run/ftpd.pid): not readable.
/etc/rc: DEBUG: checkyesno: ftpd_enable is set to NO.
/etc/rc: DEBUG: checkyesno: ftpproxy_enable is set to NO.
/etc/rc: DEBUG: checkyesno: bsnmpd_enable is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: /usr/sbin/bsnmpd -D dump 
Sep 13 03:44:43 mary-teresa snmpd[3433]: bind: 0.0.0.0:161 Address already in use
Sep 13 03:44:43 mary-teresa snmpd[3433]: NgMkSockNode: Address already in use
Sep 13 03:44:43 mary-teresa snmpd[3433]: assignment to begemotNgControlNodeName.0 returns 5
Sep 13 03:44:43 mary-teresa snmpd[3433]:   in file /etc/snmpd.config line 81
Sep 13 03:44:43 mary-teresa snmpd[3433]: error in config file
/etc/rc: DEBUG: run_rc_command: doit: bridge_start 
/etc/rc: DEBUG: checkyesno: background_fsck is set to YES.
/etc/rc: DEBUG: run_rc_command: doit: bgfsck_start 

Sun Sep 13 03:44:43 EEST 2009
pid 4216 (isoqlog), uid 0: exited on signal 11 (core dumped)
pid 8279 (isoqlog), uid 0: exited on signal 11 (core dumped)
pid 11094 (isoqlog), uid 0: exited on signal 11 (core dumped)
pid 15230 (isoqlog), uid 0: exited on signal 11 (core dumped)
pid 17978 (isoqlog), uid 0: exited on signal 11 (core dumped)
pid 22069 (isoqlog), uid 0: exited on signal 11 (core dumped)
pid 24756 (isoqlog), uid 0: exited on signal 11 (core dumped)
pid 28731 (isoqlog), uid 0: exited on signal 11 (core dumped)
pid 31422 (isoqlog), uid 0: exited on signal 11 (core dumped)
pid 35370 (isoqlog), uid 0: exited on signal 11 (core dumped)
pid 38046 (isoqlog), uid 0: exited on signal 11 (core dumped)
pid 42019 (isoqlog), uid 0: exited on signal 11 (core dumped)
pid 44689 (isoqlog), uid 0: exited on signal 11 (core dumped)
Sep 13 16:50:12 mary-teresa su: vlad11 to root on /dev/pts/1
pid 48233 (host), uid 0: exited on signal 6 (core dumped)
pid 48257 (host), uid 0: exited on signal 6 (core dumped)
pid 48261 (host), uid 0: exited on signal 6 (core dumped)
pid 48506 (isoqlog), uid 0: exited on signal 11 (core dumped)
pid 51245 (isoqlog), uid 0: exited on signal 11 (core dumped)
panic: sbflush_internal: cc 0 || mb 0xffffff004127b000 || mbcnt 2304
cpuid = 1
Uptime: 14h42m52s
Physical memory: 6098 MB
Dumping 1729 MB: 1714 1698 1682 1666 1650 1634 1618 1602 1586 1570 1554 1538 1522 1506 1490 1474 1458 1442 1426 1410 1394 1378 1362 1346 1330 1314 1298 1282 1266 1250 1234 1218 1202 1186 1170 1154 1138 1122 1106 1090 1074 1058 1042 1026 1010 994 978 962 946 930 914 898 882 866 850 834 818 802 786 770 754 738 722 706 690 674 658 642 626 610 594 578 562 546 530 514 498 482 466 450 434 418 402 386 370 354 338 322 306 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 34 18 2

------------------------------------------------------------------------
kernel config

config: File /boot/kernel/kernel doesn't contain configuration file. Either unsupported, or not compiled with INCLUDE_CONFIG_FILE
From vlad11 at otrada.od.ua  Mon Sep 14 16:30:09 2009
From: vlad11 at otrada.od.ua (Vladislav V. Prodan)
Date: Mon Sep 14 16:30:21 2009
Subject: kern/138782: [panic] sbflush_internal: cc 0 || mb
 0xffffff004127b000 || mbcnt 2304
Message-ID: <200909141630.n8EGU9Om096939@freefall.freebsd.org>

The following reply was made to PR kern/138782; it has been noted by GNATS.

From: "Vladislav V. Prodan" <vlad11@otrada.od.ua>
To: bug-followup@FreeBSD.org, universite@ukr.net
Cc:  
Subject: Re: kern/138782: [panic] sbflush_internal: cc 0 || mb 0xffffff004127b000
 || mbcnt 2304
Date: Mon, 14 Sep 2009 19:27:14 +0300

 http://otrada.od.ua/FreeBSD/crash/core.txt.gz
From universite at ukr.net  Mon Sep 14 16:30:12 2009
From: universite at ukr.net (Vladislav V. Prodan)
Date: Mon Sep 14 16:30:22 2009
Subject: kern/138782: [panic] sbflush_internal: cc 0 || mb
 0xffffff004127b000 || mbcnt 2304
Message-ID: <200909141630.n8EGUBhL097106@freefall.freebsd.org>

The following reply was made to PR kern/138782; it has been noted by GNATS.

From: "Vladislav V. Prodan" <universite@ukr.net>
To: bug-followup@FreeBSD.org, universite@ukr.net
Cc:  
Subject: Re: kern/138782: [panic] sbflush_internal: cc 0 || mb 0xffffff004127b000
 || mbcnt 2304
Date: Mon, 14 Sep 2009 19:27:21 +0300

 http://otrada.od.ua/FreeBSD/crash/core.txt.gz
From universite at ukr.net  Mon Sep 14 16:20:03 2009
From: universite at ukr.net (Vladislav V. Prodan)
Date: Mon Sep 14 16:34:59 2009
Subject: kern/138782: [panic] sbflush_internal: cc 0 || mb
 0xffffff004127b000 || mbcnt 2304
Message-ID: <200909141620.n8EGK30B087477@freefall.freebsd.org>

The following reply was made to PR kern/138782; it has been noted by GNATS.

From: "Vladislav V. Prodan" <universite@ukr.net>
To: bug-followup@FreeBSD.org
Cc: freebsd-net@FreeBSD.org, freebsd-bugs@FreeBSD.org, gavin@FreeBSD.org
Subject: Re: kern/138782: [panic] sbflush_internal: cc 0 || mb 0xffffff004127b000
 || mbcnt 2304
Date: Mon, 14 Sep 2009 19:17:52 +0300

 This is a multi-part message in MIME format.
 --------------000404040105020802090300
 Content-Type: text/plain; charset=UTF-8; format=flowed
 Content-Transfer-Encoding: 7bit
 
 
 --------------000404040105020802090300
 Content-Type: text/plain;
  name="core.txt"
 Content-Transfer-Encoding: base64
 Content-Disposition: inline;
  filename="core.txt"
 
 bWFyeS10ZXJlc2Eub3RyYWRhLm9kLnVhIGR1bXBlZCBjb3JlIC0gc2VlIC92YXIvY3Jhc2gv
 dm1jb3JlLjEyCgrQz87FxMXM2M7JyywgMTQg08XO1NHC0tEgMjAwOSDHLiAxOToxMzozNSAo
 RUVTVCkKCkZyZWVCU0QgbWFyeS10ZXJlc2Eub3RyYWRhLm9kLnVhIDguMC1CRVRBNCBGcmVl
 QlNEIDguMC1CRVRBNCAjMDogU3VuIFNlcCAxMyAwMzowNTowOSBFRVNUIDIwMDkgICAgIHZs
 YWQxMUBtYXJ5LXRlcmVzYS5vdHJhZGEub2QudWE6L3Vzci9vYmovdXNyL3NyYy9zeXMvbWFy
 eS10ZXJlc2EuMTggIGFtZDY0CgpwYW5pYzogc2JmbHVzaF9pbnRlcm5hbDogY2MgMCB8fCBt
 YiAweGZmZmZmZjAwNDEyN2IwMDAgfHwgbWJjbnQgMjMwNAoKR05VIGdkYiA2LjEuMSBbRnJl
 ZUJTRF0KQ29weXJpZ2h0IDIwMDQgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uLCBJbmMuCkdE
 QiBpcyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVkIGJ5IHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMg
 TGljZW5zZSwgYW5kIHlvdSBhcmUKd2VsY29tZSB0byBjaGFuZ2UgaXQgYW5kL29yIGRpc3Ry
 aWJ1dGUgY29waWVzIG9mIGl0IHVuZGVyIGNlcnRhaW4gY29uZGl0aW9ucy4KVHlwZSAic2hv
 dyBjb3B5aW5nIiB0byBzZWUgdGhlIGNvbmRpdGlvbnMuClRoZXJlIGlzIGFic29sdXRlbHkg
 bm8gd2FycmFudHkgZm9yIEdEQi4gIFR5cGUgInNob3cgd2FycmFudHkiIGZvciBkZXRhaWxz
 LgpUaGlzIEdEQiB3YXMgY29uZmlndXJlZCBhcyAiYW1kNjQtbWFyY2VsLWZyZWVic2QiLi4u
 CgpVbnJlYWQgcG9ydGlvbiBvZiB0aGUga2VybmVsIG1lc3NhZ2UgYnVmZmVyOgpwYW5pYzog
 c2JmbHVzaF9pbnRlcm5hbDogY2MgMCB8fCBtYiAweGZmZmZmZjAwNDEyN2IwMDAgfHwgbWJj
 bnQgMjMwNApjcHVpZCA9IDEKVXB0aW1lOiAxNGg0Mm01MnMKUGh5c2ljYWwgbWVtb3J5OiA2
 MDk4IE1CCkR1bXBpbmcgMTcyOSBNQjogMTcxNCAxNjk4IDE2ODIgMTY2NiAxNjUwIDE2MzQg
 MTYxOCAxNjAyIDE1ODYgMTU3MCAxNTU0IDE1MzggMTUyMiAxNTA2IDE0OTAgMTQ3NCAxNDU4
 IDE0NDIgMTQyNiAxNDEwIDEzOTQgMTM3OCAxMzYyIDEzNDYgMTMzMCAxMzE0IDEyOTggMTI4
 MiAxMjY2IDEyNTAgMTIzNCAxMjE4IDEyMDIgMTE4NiAxMTcwIDExNTQgMTEzOCAxMTIyIDEx
 MDYgMTA5MCAxMDc0IDEwNTggMTA0MiAxMDI2IDEwMTAgOTk0IDk3OCA5NjIgOTQ2IDkzMCA5
 MTQgODk4IDg4MiA4NjYgODUwIDgzNCA4MTggODAyIDc4NiA3NzAgNzU0IDczOCA3MjIgNzA2
 IDY5MCA2NzQgNjU4IDY0MiA2MjYgNjEwIDU5NCA1NzggNTYyIDU0NiA1MzAgNTE0IDQ5OCA0
 ODIgNDY2IDQ1MCA0MzQgNDE4IDQwMiAzODYgMzcwIDM1NCAzMzggMzIyIDMwNiAyOTAgMjc0
 IDI1OCAyNDIgMjI2IDIxMCAxOTQgMTc4IDE2MiAxNDYgMTMwIDExNCA5OCA4MiA2NiA1MCAz
 NCAxOCAyCgpSZWFkaW5nIHN5bWJvbHMgZnJvbSAvYm9vdC9rZXJuZWwvemZzLmtvLi4uUmVh
 ZGluZyBzeW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL3pmcy5rby5zeW1ib2xzLi4uZG9uZS4K
 ZG9uZS4KTG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC96ZnMua28KUmVhZGluZyBz
 eW1ib2xzIGZyb20gL2Jvb3Qva2VybmVsL29wZW5zb2xhcmlzLmtvLi4uUmVhZGluZyBzeW1i
 b2xzIGZyb20gL2Jvb3Qva2VybmVsL29wZW5zb2xhcmlzLmtvLnN5bWJvbHMuLi5kb25lLgpk
 b25lLgpMb2FkZWQgc3ltYm9scyBmb3IgL2Jvb3Qva2VybmVsL29wZW5zb2xhcmlzLmtvClJl
 YWRpbmcgc3ltYm9scyBmcm9tIC9ib290L2tlcm5lbC9saW51eC5rby4uLlJlYWRpbmcgc3lt
 Ym9scyBmcm9tIC9ib290L2tlcm5lbC9saW51eC5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4K
 TG9hZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9saW51eC5rbwpSZWFkaW5nIHN5bWJv
 bHMgZnJvbSAvYm9vdC9rZXJuZWwvYWNjZl9odHRwLmtvLi4uUmVhZGluZyBzeW1ib2xzIGZy
 b20gL2Jvb3Qva2VybmVsL2FjY2ZfaHR0cC5rby5zeW1ib2xzLi4uZG9uZS4KZG9uZS4KTG9h
 ZGVkIHN5bWJvbHMgZm9yIC9ib290L2tlcm5lbC9hY2NmX2h0dHAua28KIzAgIGRvYWR1bXAg
 KCkgYXQgcGNwdS5oOjIyMwoyMjMJcGNwdS5oOiDuxdQg1MHLz8fPIMbByszBIMnMySDLwdTB
 zM/HwS4KCWluIHBjcHUuaAooa2dkYikgIzAgIGRvYWR1bXAgKCkgYXQgcGNwdS5oOjIyMwoj
 MSAgMHhmZmZmZmZmZjgwM2E1MDg5IGluIGJvb3QgKGhvd3RvPTI2MCkKICAgIGF0IC91c3Iv
 c3JjL3N5cy9rZXJuL2tlcm5fc2h1dGRvd24uYzo0MTYKIzIgIDB4ZmZmZmZmZmY4MDNhNTRk
 YyBpbiBwYW5pYyAoZm10PVZhcmlhYmxlICJmbXQiIGlzIG5vdCBhdmFpbGFibGUuCikgYXQg
 L3Vzci9zcmMvc3lzL2tlcm4va2Vybl9zaHV0ZG93bi5jOjU3OQojMyAgMHhmZmZmZmZmZjgw
 NDAxYTQ0IGluIHNiZmx1c2hfaW50ZXJuYWwgKHNiPTB4ZmZmZmZmMDEyNTBlOTE4MCkKICAg
 IGF0IC91c3Ivc3JjL3N5cy9rZXJuL3VpcGNfc29ja2J1Zi5jOjgyNAojNCAgMHhmZmZmZmZm
 ZjgwNDAxYjNjIGluIHNicmVsZWFzZV9pbnRlcm5hbCAoc2I9MHhmZmZmZmYwMTI1MGU5MTgw
 LCAKICAgIHNvPTB4ZmZmZmZmMDEyNTBlOTAwMCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4vdWlw
 Y19zb2NrYnVmLmM6MzM5CiM1ICAweGZmZmZmZmZmODA0MDMzNWMgaW4gc29mcmVlIChzbz0w
 eGZmZmZmZjAxMjUwZTkwMDApCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi91aXBjX3NvY2tl
 dC5jOjYzMgojNiAgMHhmZmZmZmZmZjgwNTUyZmE4IGluIHRjcF9jbG9zZSAodHA9MHgwKQog
 ICAgYXQgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX3N1YnIuYzo5MzcKIzcgIDB4ZmZmZmZm
 ZmY4MDU0YmMxNSBpbiB0Y3BfZG9fc2VnbWVudCAobT0weGZmZmZmZjAxOTdmYWUzMDAsIAog
 ICAgdGg9MHhmZmZmZmYwMTk3ZmFlMzdjLCBzbz0weGZmZmZmZjAxMjUwZTkwMDAsIHRwPTB4
 ZmZmZmZmMDEyNTExMWE1MCwgCiAgICBkcm9wX2hkcmxlbj01MiwgdGxlbj0wLCBpcHRvcz0w
 ICdcMCcsIHRpX2xvY2tlZD0zKQogICAgYXQgL3Vzci9zcmMvc3lzL25ldGluZXQvdGNwX2lu
 cHV0LmM6MjQ2NwojOCAgMHhmZmZmZmZmZjgwNTRkZGJiIGluIHRjcF9pbnB1dCAobT0weGZm
 ZmZmZjAxOTdmYWUzMDAsIG9mZjA9VmFyaWFibGUgIm9mZjAiIGlzIG5vdCBhdmFpbGFibGUu
 CikKICAgIGF0IC91c3Ivc3JjL3N5cy9uZXRpbmV0L3RjcF9pbnB1dC5jOjEwNDcKIzkgIDB4
 ZmZmZmZmZmY4MDRkOGQ3YiBpbiBpcF9pbnB1dCAobT0weGZmZmZmZjAxOTdmYWUzMDApCiAg
 ICBhdCAvdXNyL3NyYy9zeXMvbmV0aW5ldC9pcF9pbnB1dC5jOjc3NQojMTAgMHhmZmZmZmZm
 ZjgwNDcxMDQyIGluIHN3aV9uZXQgKGFyZz1WYXJpYWJsZSAiYXJnIiBpcyBub3QgYXZhaWxh
 YmxlLgopIGF0IC91c3Ivc3JjL3N5cy9uZXQvbmV0aXNyLmM6NzE2CiMxMSAweGZmZmZmZmZm
 ODAzN2YzNjAgaW4gaW50cl9ldmVudF9leGVjdXRlX2hhbmRsZXJzIChwPVZhcmlhYmxlICJw
 IiBpcyBub3QgYXZhaWxhYmxlLgopCiAgICBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2lu
 dHIuYzoxMTY1CiMxMiAweGZmZmZmZmZmODAzODA4ZGUgaW4gaXRocmVhZF9sb29wIChhcmc9
 MHhmZmZmZmYwMDAxMzkyNmEwKQogICAgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9pbnRy
 LmM6MTE3OAojMTMgMHhmZmZmZmZmZjgwMzdkMzY3IGluIGZvcmtfZXhpdCAoCiAgICBjYWxs
 b3V0PTB4ZmZmZmZmZmY4MDM4MDg1MCA8aXRocmVhZF9sb29wPiwgYXJnPTB4ZmZmZmZmMDAw
 MTM5MjZhMCwgCiAgICBmcmFtZT0weGZmZmZmZjgwMDAwMzdjODApIGF0IC91c3Ivc3JjL3N5
 cy9rZXJuL2tlcm5fZm9yay5jOjg0MwojMTQgMHhmZmZmZmZmZjgwNjQ1N2VlIGluIGZvcmtf
 dHJhbXBvbGluZSAoKQogICAgYXQgL3Vzci9zcmMvc3lzL2FtZDY0L2FtZDY0L2V4Y2VwdGlv
 bi5TOjU2MQojMTUgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMxNiAweDAwMDAwMDAw
 MDAwMDAwMDAgaW4gPz8gKCkKIzE3IDB4MDAwMDAwMDAwMDAwMDAwMSBpbiA/PyAoKQojMTgg
 MHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMxOSAweDAwMDAwMDAwMDAwMDAwMDAgaW4g
 Pz8gKCkKIzIwIDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMjEgMHgwMDAwMDAwMDAw
 MDAwMDAwIGluID8/ICgpCiMyMiAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzIzIDB4
 MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMjQgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/
 ICgpCiMyNSAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzI2IDB4MDAwMDAwMDAwMDAw
 MDAwMCBpbiA/PyAoKQojMjcgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMyOCAweDAw
 MDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzI5IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAo
 KQojMzAgMHgwMDAwMDAwMDAwMDAwMDAwIGluID8/ICgpCiMzMSAweDAwMDAwMDAwMDAwMDAw
 MDAgaW4gPz8gKCkKIzMyIDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMzMgMHgwMDAw
 MDAwMDAwMDAwMDAwIGluID8/ICgpCiMzNCAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkK
 IzM1IDB4MDAwMDAwMDAwMDAwMDAwMCBpbiA/PyAoKQojMzYgMHgwMDAwMDAwMDAwMDAwMDAw
 IGluID8/ICgpCiMzNyAweDAwMDAwMDAwMDAwMDAwMDAgaW4gPz8gKCkKIzM4IDB4MDAwMDAw
 MDAwMDAwMDAwMCBpbiA/PyAoKQojMzkgMHgwMDAwMDAwMDAwYzZjMDAwIGluID8/ICgpCiM0
 MCAweDAwMDAwMDAwMDAwMDAwMGIgaW4gPz8gKCkKIzQxIDB4ZmZmZmZmZmY4MDhjZjI4MCBp
 biBhZmZpbml0eSAoKQojNDIgMHhmZmZmZmZmZjgwOGNmMjgwIGluIGFmZmluaXR5ICgpCiM0
 MyAweGZmZmZmZjAwMDE1MGQ3MjAgaW4gPz8gKCkKIzQ0IDB4ZmZmZmZmODAwMDAzNzIzMCBp
 biA/PyAoKQojNDUgMHhmZmZmZmY4MDAwMDM3MWU4IGluID8/ICgpCiM0NiAweGZmZmZmZjAw
 MDEzOTkwMDAgaW4gPz8gKCkKIzQ3IDB4ZmZmZmZmZmY4MDNjN2Y5OSBpbiBzY2hlZF9zd2l0
 Y2ggKHRkPTB4ZmZmZmZmMDAwMTM5MjZhMCwgCiAgICBuZXd0ZD0weGZmZmZmZmZmODAzODA4
 NTAsIGZsYWdzPVZhcmlhYmxlICJmbGFncyIgaXMgbm90IGF2YWlsYWJsZS4KKSBhdCAvdXNy
 L3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxODU4ClByZXZpb3VzIGZyYW1lIGlubmVyIHRv
 IHRoaXMgZnJhbWUgKGNvcnJ1cHQgc3RhY2s/KQooa2dkYikgCgotLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0KcHMgLWF4bAoKU2VnbWVudGF0aW9uIGZhdWx0IChjb3JlIGR1bXBlZCkKCi0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLQp2bXN0YXQgLXMKCiAgICAgICAgMCBjcHUgY29udGV4dCBzd2l0Y2hlcwog
 ICAgICAgIDAgZGV2aWNlIGludGVycnVwdHMKICAgICAgICAwIHNvZnR3YXJlIGludGVycnVw
 dHMKICAgICAgICAwIHRyYXBzCiAgICAgICAgMCBzeXN0ZW0gY2FsbHMKICAgICAgICAwIGtl
 cm5lbCB0aHJlYWRzIGNyZWF0ZWQKICAgICAgICAwICBmb3JrKCkgY2FsbHMKICAgICAgICAw
 IHZmb3JrKCkgY2FsbHMKICAgICAgICAwIHJmb3JrKCkgY2FsbHMKICAgICAgICAwIHN3YXAg
 cGFnZXIgcGFnZWlucwogICAgICAgIDAgc3dhcCBwYWdlciBwYWdlcyBwYWdlZCBpbgogICAg
 ICAgIDAgc3dhcCBwYWdlciBwYWdlb3V0cwogICAgICAgIDAgc3dhcCBwYWdlciBwYWdlcyBw
 YWdlZCBvdXQKICAgICAgICAwIHZub2RlIHBhZ2VyIHBhZ2VpbnMKICAgICAgICAwIHZub2Rl
 IHBhZ2VyIHBhZ2VzIHBhZ2VkIGluCiAgICAgICAgMCB2bm9kZSBwYWdlciBwYWdlb3V0cwog
 ICAgICAgIDAgdm5vZGUgcGFnZXIgcGFnZXMgcGFnZWQgb3V0CiAgICAgICA1MSBwYWdlIGRh
 ZW1vbiB3YWtldXBzCiAgMTk4MTE0NSBwYWdlcyBleGFtaW5lZCBieSB0aGUgcGFnZSBkYWVt
 b24KICAyMDEwNTE3IHBhZ2VzIHJlYWN0aXZhdGVkCiAgICAgICAgMCBjb3B5LW9uLXdyaXRl
 IGZhdWx0cwogICAgICAgIDAgY29weS1vbi13cml0ZSBvcHRpbWl6ZWQgZmF1bHRzCiAgICAg
 ICAgMCB6ZXJvIGZpbGwgcGFnZXMgemVyb2VkCiAgICAgICAgMCB6ZXJvIGZpbGwgcGFnZXMg
 cHJlemVyb2VkCiAgICAgICAgMCBpbnRyYW5zaXQgYmxvY2tpbmcgcGFnZSBmYXVsdHMKICAg
 ICAgICAwIHRvdGFsIFZNIGZhdWx0cyB0YWtlbgogICAgICAgIDAgcGFnZXMgYWZmZWN0ZWQg
 Ynkga2VybmVsIHRocmVhZCBjcmVhdGlvbgogICAgICAgIDAgcGFnZXMgYWZmZWN0ZWQgYnkg
 IGZvcmsoKQogICAgICAgIDAgcGFnZXMgYWZmZWN0ZWQgYnkgdmZvcmsoKQogICAgICAgIDAg
 cGFnZXMgYWZmZWN0ZWQgYnkgcmZvcmsoKQogIDg4OTg3NTUgcGFnZXMgY2FjaGVkCiAgICAg
 ICAgMCBwYWdlcyBmcmVlZAogICAgICAgIDAgcGFnZXMgZnJlZWQgYnkgZGFlbW9uCiAgOTQ5
 MTcwNSBwYWdlcyBmcmVlZCBieSBleGl0aW5nIHByb2Nlc3NlcwogICA5NjExODcgcGFnZXMg
 YWN0aXZlCiAgIDMzNjAzNCBwYWdlcyBpbmFjdGl2ZQogICAgMTgxMTQgcGFnZXMgaW4gVk0g
 Y2FjaGUKICAgMTMyMzc3IHBhZ2VzIHdpcmVkIGRvd24KICAgIDYzNTI0IHBhZ2VzIGZyZWUK
 ICAgICA0MDk2IGJ5dGVzIHBlciBwYWdlCjEyMTg5OTQ4OCB0b3RhbCBuYW1lIGxvb2t1cHMK
 ICAgICAgICAgIGNhY2hlIGhpdHMgKDk1JSBwb3MgKyAyJSBuZWcpIHN5c3RlbSAwJSBwZXIt
 ZGlyZWN0b3J5CiAgICAgICAgICBkZWxldGlvbnMgMCUsIGZhbHNlaGl0cyAwJSwgdG9vbG9u
 ZyAwJQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnZtc3RhdCAtbQoKICAgICAgICAgVHlwZSBJblVz
 ZSBNZW1Vc2UgSGlnaFVzZSBSZXF1ZXN0cyAgU2l6ZShzKQogICAgICAgICBjZGV2ICAgIDEw
 ICAgICAzSyAgICAgICAtICAgICAgIDEwICAyNTYKICAgICAgYWNwaWRldiAgICA3MCAgICAg
 NUsgICAgICAgLSAgICAgICA3MCAgNjQKICAgICAgICBzaWdpbyAgICAgMSAgICAgMUsgICAg
 ICAgLSAgICAgNzAzMyAgNjQKICAgICBmaWxlZGVzYyAgIDIwOSAgIDc3OUsgICAgICAgLSAg
 ICA1NzU5NyAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICAgICAg
 a2VudiAgICA4MiAgICAxMUsgICAgICAgLSAgICAgICA4OSAgMTYsMzIsNjQsMTI4CiAgICAg
 ICBrcXVldWUgICAgNzAgICAyNDVLICAgICAgIC0gICAgMzAyMzUgIDI1NiwyMDQ4CiAgICBw
 cm9jLWFyZ3MgICAgNzggICAgIDVLICAgICAgIC0gICAgOTM3ODAgIDE2LDMyLDY0LDEyOCwy
 NTYKICAgICAgaXRocmVhZCAgICA3OSAgICAxM0sgICAgICAgLSAgICAgICA3OSAgMzIsMTI4
 LDI1NgogICAgICBlbnRyb3B5ICAxMDI0ICAgIDY0SyAgICAgICAtICAgICAxMDI0ICA2NAog
 ICAgICAgS1RSQUNFICAgMTAwICAgIDEzSyAgICAgICAtICAgICAgMTAwICAxMjgKICAgICAg
 IGxpbmtlciAgIDEzOSAgIDE1M0sgICAgICAgLSAgICAgIDE4MyAgMTYsMzIsNjQsMTI4LDI1
 Niw1MTIsMTAyNCwyMDQ4CiAgICAgICAgbG9ja2YgICAgODQgICAgIDlLICAgICAgIC0gICA2
 MzI1NDMgIDY0LDEyOCwyNTYKICAgICAgIGlwNm5kcCAgICAxMSAgICAgMUsgICAgICAgLSAg
 ICAgICAyMSAgNjQsMTI4CiAgICAgICBpcDZvcHQgICAgIDEgICAgIDFLICAgICAgIC0gICAg
 ICAzNTcgIDMyLDI1NgogICAgICAgICB0ZW1wICAgIDUzICAgIDE0SyAgICAgICAtICAgMjM3
 OTc0ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICAgZGV2YnVm
 IDE5MDg1IDM5MzEzSyAgICAgICAtICAgIDIwNzI5ICAxNiwzMiw2NCwxMjgsMjU2LDUxMiwx
 MDI0LDIwNDgsNDA5NgogICAgICAgICBVQVJUICAgICAzICAgICAySyAgICAgICAtICAgICAg
 ICAzICAxNiw1MTIsMTAyNAogICAgICAgbW9kdWxlICAgMzMyICAgIDQySyAgICAgICAtICAg
 ICAgMzMyICAxMjgKQ0FNIGRldiBxdWV1ZSAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAg
 MSAgMTI4CiAgICAgbXR4X3Bvb2wgICAgIDIgICAgMTZLICAgICAgIC0gICAgICAgIDIgIAog
 ICAgICAgICAgb3NkICAgICAzICAgICAxSyAgICAgICAtICAgICAgICA2ICAxNiw2NCwxMjgK
 ICAgICAgIFVTQmRldiAgICAyOCAgICAgOUsgICAgICAgLSAgICAgICAyOCAgNjQsMTI4LDEw
 MjQKICAgICAgc3VicHJvYyAgIDQ0OSAgIDcyOUsgICAgICAgLSAgICA1NDE1MCAgNTEyLDQw
 OTYKICAgICAgICAgcHJvYyAgICAgMiAgICAzMksgICAgICAgLSAgICAgICAgMiAgCiAgICAg
 IHNlc3Npb24gICAgNTQgICAgIDdLICAgICAgIC0gICAgIDQ1ODkgIDEyOAogICAgICAgICBw
 Z3JwICAgIDU5ICAgICA4SyAgICAgICAtICAgICA0NjY5ICAxMjgKICAgICAgICAgY3JlZCAg
 IDIxMiAgICAzNEsgICAgICAgLSAgMjg1MDQzNCAgNjQsMjU2CiAgICAgIHVpZGluZm8gICAg
 MTMgICAgIDZLICAgICAgIC0gICAgIDQyNDUgIDEyOCw0MDk2CiAgICAgICBwbGltaXQgICAg
 MzcgICAgMTBLICAgICAgIC0gICAgIDY4MzUgIDI1NgogICAgICAgICAgVVNCICAgIDQ5ICAg
 IDE2SyAgICAgICAtICAgICAgIDQ5ICAxNiwzMiw2NCwyMDQ4CiAgICBzeXNjdGx0bXAgICAg
 IDAgICAgIDBLICAgICAgIC0gICAgIDU5OTEgIDE2LDMyLDY0LDEyOCwyNTYKICAgIHN5c2N0
 bG9pZCAgNDAyNyAgIDE5OEsgICAgICAgLSAgICAgNDE0MyAgMTYsMzIsNjQsMTI4CiAgICAg
 ICBzeXNjdGwgICAgIDAgICAgIDBLICAgICAgIC0gICAgMzY4MjEgIDE2LDMyLDY0CiAgICAg
 IGNhbGxvdXQgICAgIDEgICA1MTJLICAgICAgIC0gICAgICAgIDEgIAogICAgICAgICB1bXR4
 ICAgNTI4ICAgIDY2SyAgICAgICAtICAgICAgNTI4ICAxMjgKICAgICBwMTAwMy4xYiAgICAg
 MSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMTYKICAgICAgICAgU1dBUCAgICAgMiAgMjE4
 OUsgICAgICAgLSAgICAgICAgMiAgNjQKICAgICAgIERFVkZTMSAgIDExNSAgICA1OEsgICAg
 ICAgLSAgICAgIDE5NyAgNTEyCiAgICAgICBidXMtc2MgICAgODYgICAyMTVLICAgICAgIC0g
 ICAgIDIwMzQgIDE2LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OCw0MDk2CiAgICAgICAg
 ICBidXMgICA4MzUgICAgNzlLICAgICAgIC0gICAgIDUwODggIDE2LDMyLDY0LDEyOCwyNTYs
 NTEyLDEwMjQKICAgICAgZGV2c3RhdCAgICA5MCAgIDE4MksgICAgICAgLSAgICAgICA5MCAg
 MzIsNDA5NgogZXZlbnRoYW5kbGVyICAgIDk1ICAgICA4SyAgICAgICAtICAgICAgIDk1ICA2
 NCwxMjgKICAgICAgIERFVkZTMyAgIDI1MyAgICA2NEsgICAgICAgLSAgICAgIDU3NyAgMjU2
 CiAgICAgICAgIGtvYmogICAxNTUgICA2MjBLICAgICAgIC0gICAgICAzMTIgIDQwOTYKICAg
 ICAgUGVyLWNwdSAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAgMzIKICAgICAgIERF
 VkZTMiAgIDExMCAgICAgMksgICAgICAgLSAgICAgIDExMCAgMTYKICAgREVWRlNfUlVMRSAg
 ICA0MCAgICAxOEsgICAgICAgLSAgICAgIDExNCAgNjQsNTEyCiAgICAgICAgIHJtYW4gICAy
 MjAgICAgMjdLICAgICAgIC0gICAgICA2NTEgIDE2LDMyLDEyOAogICAgICAgIERFVkZTICAg
 IDMyICAgICAxSyAgICAgICAtICAgICAgIDYzICAxNiwxMjgKICAgICAgICAgc2J1ZiAgICAg
 MCAgICAgMEsgICAgICAgLSAgICAgODM5MCAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwy
 MDQ4LDQwOTYKICAgICAgIERFVkZTUCAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAg
 NjQKICAgICAgICBzdGFjayAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAgMiAgMjU2CiAg
 ICB0YXNrcXVldWUgICAgMzkgICAgIDRLICAgICAgIC0gICAgICAgNjUgIDE2LDMyLDY0LDEy
 OAogICAgICAgVW5pdG5vICAgIDE2ICAgICAxSyAgICAgICAtICAgIDE4ODIyICAzMiw2NAog
 ICAgICAgICAgaW92ICAgICAwICAgICAwSyAgICAgICAtICAxMjQ1NDczICAxNiwzMiw2NCwx
 MjgsMjU2LDUxMgogICAgICAgc2VsZWN0ICAgMzMzICAgIDQySyAgICAgICAtICAgICAgMzMz
 ICAxMjgKICAgICBpb2N0bG9wcyAgICAgMCAgICAgMEsgICAgICAgLSAgICA1OTYyNiAgMTYs
 MzIsNjQsMTI4LDI1Niw1MTIsMTAyNCw0MDk2CiAgICAgICAgICBtc2cgICAgIDQgICAgNTRL
 ICAgICAgIC0gICAgICAgIDQgIDIwNDgKICAgICAgICAgIHNlbSAgICAgNCAgICAxMUsgICAg
 ICAgLSAgICAgICAgNCAgNTEyLDEwMjQKICAgICAgICAgIHNobSAgICAxMyAgICAgN0sgICAg
 ICAgLSAgICAgMjQ2MSAgMjU2LDQwOTYKICAgICAgICAgIHR0eSAgICAyMyAgICAyM0sgICAg
 ICAgLSAgICAgICAyNyAgMTAyNCwyMDQ4CiAgICAgICAgICBwdHMgICAgIDUgICAgIDJLICAg
 ICAgIC0gICAgICAgIDcgIDI1NgogICAgICAgICBhY2NmICAgICAyICAgICAxSyAgICAgICAt
 ICAgICAgICAzICAzMiw2NAogICAgIG1idWZfdGFnICAgICAxICAgICAxSyAgICAgICAtICA2
 ODc0MTMyICAzMiw2NCwxMjgKICAgICAgICBzaG1mZCAgICAgMSAgICAgOEsgICAgICAgLSAg
 ICAgICAgMSAgCiAgICAgICAgICBwY2IgICA1MDEgICAxNzJLICAgICAgIC0gICA0MTk1MDUg
 IDE2LDMyLDY0LDEyOCwxMDI0LDIwNDgsNDA5NgogICAgICAgc29uYW1lICAgIDMzICAgICA0
 SyAgICAgICAtIDQ5NDE0MzQzICAxNiwzMiwxMjgKICAgICAgICAgIGFjbCAgICAgMCAgICAg
 MEsgICAgICAgLSAgICAxNTkxNiAgNDA5NgogICAgICAgYmlvYnVmICAgICAwICAgICAwSyAg
 ICAgICAtICAgICAgNTE0ICAyMDQ4CiAgICAgdmZzY2FjaGUgICAgIDEgIDEwMjRLICAgICAg
 IC0gICAgICAgIDEgIAogICBjbF9zYXZlYnVmICAgICAwICAgICAwSyAgICAgICAtICAgICAy
 MDY4ICA2NCwxMjgKICAgICB2ZnNfaGFzaCAgICAgMSAgIDUxMksgICAgICAgLSAgICAgICAg
 MSAgCiAgICAgICB2bm9kZXMgICAgMTAgICAgIDFLICAgICAgIC0gICAgICAgMTcgIDY0LDI1
 NgogIHZub2RlbWFya2VyICAgICAwICAgICAwSyAgICAgICAtICAgIDIyMzQ3ICA1MTIKICAg
 ICAgICBtb3VudCAgIDExMSAgICAgNUsgICAgICAgLSAgICAgIDI1NyAgMTYsMzIsNjQsMTI4
 LDI1NgogICAgICAgICAgQlBGICAgIDE4ICAgIDc1SyAgICAgICAtICAgICAgIDIwICAxNiw2
 NCwxMjgsNTEyLDQwOTYKICBldGhlcl9tdWx0aSAgICA1NSAgICAgM0sgICAgICAgLSAgICAg
 IDEwMiAgMTYsMzIsNjQKICAgICAgIGlmYWRkciAgIDExMiAgICAyOUsgICAgICAgLSAgICAg
 IDEyNyAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMjA0OCw0MDk2CiAgICAgICAgaWZuZXQgICAg
 MTAgICAgMTlLICAgICAgIC0gICAgICAgMTEgIDEyOCwyMDQ4CiAgICAgICAgY2xvbmUgICAg
 MTQgICAgNTNLICAgICAgIC0gICAgICAgMTggIDE2LDI1Niw0MDk2CiAgICAgICBhcnBjb20g
 ICAgIDMgICAgIDFLICAgICAgIC0gICAgICAgIDMgIDE2CiAgICAgICAgICBnaWYgICAgIDEg
 ICAgIDFLICAgICAgIC0gICAgICAgIDIgIDI1NgogICAgICBsbHRhYmxlICAgIDQ0ICAgIDE2
 SyAgICAgICAtICAgICAgNjM5ICAyNTYsNTEyCiAgICAgICAgIHNwcHAgICAgIDIgICAgIDRL
 ICAgICAgIC0gICAgICAgIDIgIDIwNDgKICAgICAgICAgIHR1biAgICAgMiAgICAgMUsgICAg
 ICAgLSAgICAgICAgMiAgMjU2CiAgbnVsbGZzX2hhc2ggICAgIDEgICAgIDFLICAgICAgIC0g
 ICAgICAgIDEgIDEyOAogICAgcGZzX25vZGVzICAgIDIwICAgICA1SyAgICAgICAtICAgICAg
 IDIwICAyNTYKICAgIENBTSBxdWV1ZSAgICAgMyAgICAgMUsgICAgICAgLSAgICAgICAgNyAg
 MTYKICAgICBwY2lfbGluayAgICAxNiAgICAgMksgICAgICAgLSAgICAgICAxNiAgMzIsMTI4
 CiAgICAgcm91dGV0YmwgICAyNjEgICAgODFLICAgICAgIC0gICAgIDYyNTEgIDMyLDY0LDEy
 OCwyNTYsNTEyLDEwMjQKIG5ldGZsb3dfaGFzaCAgICAgMSAgMzA3MksgICAgICAgLSAgICAg
 ICAgMiAgCiAgICAgICAgIEdFT00gICAxNzYgICAxMDJLICAgICAgIC0gICAgMTE0MzggIDE2
 LDMyLDY0LDEyOCwyNTYsNTEyLDEwMjQsMjA0OAogICAgYWNwaV9wZXJmICAgICAyICAgICAx
 SyAgICAgICAtICAgICAgICAyICAxMjgKIG5ldGdyYXBoX21zZyAgICAgMCAgICAgMEsgICAg
 ICAgLSAgICAgICA3NSAgNjQsMTI4LDI1NiwxMDI0LDIwNDgsNDA5NgpuZXRncmFwaF9ub2Rl
 ICAgIDE3ICAgICA1SyAgICAgICAtICAgICAgIDE3ICAyNTYKbmV0Z3JhcGhfaG9vayAgICAz
 OCAgICAgNUsgICAgICAgLSAgICAgICAzOCAgMTI4CiAgICAgbmV0Z3JhcGggICAgMTYgIDIw
 NTNLICAgICAgIC0gICAgICAgMTcgIDE2LDMyLDY0Cm5ldGdyYXBoX2tzb2NrICAgICAxICAg
 ICAxSyAgICAgICAtICAgICAgICAxICAxMjgKbmV0Z3JhcGhfcGFyc2UgICAgIDAgICAgIDBL
 ICAgICAgIC0gICAgICAgIDYgIDE2Cm5ldGdyYXBoX3BwcG9lICAgICA0ICAgIDI1SyAgICAg
 ICAtICAgICAgICA2ICA2NCw1MTIKbmV0Z3JhcGhfc29jayAgICAgMyAgICAgMUsgICAgICAg
 LSAgICAgICAgNyAgMTI4Cm5ldGdyYXBoX3BhdGggICAgIDAgICAgIDBLICAgICAgIC0gICAg
 ICAgNTAgIDE2CiAgICAgICAgIGlnbXAgICAgIDkgICAgIDNLICAgICAgIC0gICAgICAgMTAg
 IDI1NgogICAgIGluX211bHRpICAgICA1ICAgICAySyAgICAgICAtICAgICAgICA2ICAyNTYK
 ZW5jYXBfZXhwb3J0X2hvc3QgICAgIDMgICAgIDNLICAgICAgIC0gICAgICAgIDQgIDEwMjQK
 ICAgICAgIGFjcGljYSAgMzI3NiAgIDMyMksgICAgICAgLSAgIDEyOTE3MSAgMTYsMzIsNjQs
 MTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAgICBpcGZ3X3RibCAgICA2NSAgICAxN0sg
 ICAgICAgLSAgICAgICA2NSAgMjU2CiAgSXBGdy9JcEFjY3QgICAgOTggICAgMTVLICAgICAg
 IC0gICAgICAxMDAgIDY0LDEyOCwyNTYsMjA0OAogICAgbXJvdXRldGJsICAgICAxICAgICAx
 SyAgICAgICAtICAgICAgICAxICAyNTYKICAgIHNjdHBfaXRlciAgICAgMCAgICAgMEsgICAg
 ICAgLSAgICAgICAxNCAgMjU2CiAgICAgc2N0cF9pZm4gICAgIDYgICAgIDFLICAgICAgIC0g
 ICAgICAgIDkgIDEyOAogICAgIHNjdHBfaWZhICAgICA5ICAgICAySyAgICAgICAtICAgICAg
 IDEzICAxMjgKICAgICBzY3RwX3ZyZiAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMSAg
 NjQKICAgIHNjdHBfYV9pdCAgICAgMCAgICAgMEsgICAgICAgLSAgICAgICAxNCAgMTYKICAg
 IGhvc3RjYWNoZSAgICAgMSAgICAyOEsgICAgICAgLSAgICAgICAgMSAgCiAgICAgc3luY2Fj
 aGUgICAgIDEgICAgOTZLICAgICAgIC0gICAgICAgIDEgIAogICAgIGxpYmFsaWFzICAyNDEw
 ICAgNDI5SyAgICAgICAtICAgNDQyNzIwICAxMjgKICAgICAgc2N0cG5hdCAgICAgNiAgICA4
 MEsgICAgICAgLSAgICAgICAgNiAgCiAgICAgYWNwaXRhc2sgICAgIDEgICAgIDJLICAgICAg
 IC0gICAgICAgIDEgIDIwNDgKICAgICAgQ0FNIFNJTSAgICAgMSAgICAgMUsgICAgICAgLSAg
 ICAgICAgMSAgMjU2CiBpcDZfbW9wdGlvbnMgICAgIDIgICAgIDFLICAgICAgIC0gICAgICAg
 IDQgIDMyLDI1NgogICAgaW42X211bHRpICAgIDI5ICAgICA0SyAgICAgICAtICAgICAgIDU5
 ICAzMiwyNTYKICBpbjZfbWZpbHRlciAgICAgMSAgICAgMUsgICAgICAgLSAgICAgICAgMiAg
 MTAyNAogICAgICAgICAgbWxkICAgICA5ICAgICAySyAgICAgICAtICAgICAgIDEwICAxMjgK
 ICAgICAgTkZTIEZIQSAgICAgMSAgICAgMksgICAgICAgLSAgICAgICAgMSAgMjA0OAogICAg
 ICAgICAgcnBjICAgICAyICAgICA5SyAgICAgICAtICAgICAgICAyICAyNTYKYXVkaXRfZXZj
 bGFzcyAgIDE3MiAgICAgNksgICAgICAgLSAgICAgIDIxMSAgMzIKICAgICBzYXZlZGlubyAg
 ICAgMCAgICAgMEsgICAgICAgLSAgICAgMTY1MyAgMjU2CiAgICBuZXdkaXJibGsgICAgIDAg
 ICAgIDBLICAgICAgIC0gICAgICAgIDEgIDY0CiAgICAgICBkaXJyZW0gICAgIDAgICAgIDBL
 ICAgICAgIC0gICAgIDc0NTggIDY0CiAgICAgICAgbWtkaXIgICAgIDAgICAgIDBLICAgICAg
 IC0gICAgICA5NjAgIDY0CiAgICAgICBkaXJhZGQgICAgIDAgICAgIDBLICAgICAgIC0gICAg
 IDg1MDMgIDY0CiAgICAgZnJlZWZpbGUgICAgIDAgICAgIDBLICAgICAgIC0gICAgIDU3OTUg
 IDY0CiAgICAgZnJlZWJsa3MgICAgIDAgICAgIDBLICAgICAgIC0gICAgMTEwNzggIDI1Ngog
 ICAgIGZyZWVmcmFnICAgICAwICAgICAwSyAgICAgICAtICAgIDExNDgyICA2NAogICBhbGxv
 Y2luZGlyICAgICA0ICAgICAxSyAgICAgICAtICAgMjA3MTk3ICAxMjgKICAgICBpbmRpcmRl
 cCAgICAgNCAgICAgMUsgICAgICAgLSAgICAgNDY2MSAgNjQKICBhbGxvY2RpcmVjdCAgICAg
 MyAgICAgMUsgICAgICAgLSAgICAyNTQzMCAgMjU2CiAgICBibXNhZmVtYXAgICAgIDAgICAg
 IDBLICAgICAgIC0gICAgMTA4ODEgIDEyOAogICAgICAgbmV3YmxrICAgICAxICAgICAxSyAg
 ICAgICAtICAgMjMyNjI4ICA2NCw1MTIKICAgICBpbm9kZWRlcCAgICAgNCAgIDUxM0sgICAg
 ICAgLSAgICAxMzQ3NyAgMjU2CiAgICAgIHBhZ2VkZXAgICAgIDEgICAxMjhLICAgICAgIC0g
 ICAgIDM5MjMgIDEyOAogIHVmc19kaXJoYXNoICAgIDc3ICAgIDMzSyAgICAgICAtICAgICAx
 MzAwICAxNiwzMiw2NCwxMjgsMjU2LDUxMgogICAgdWZzX3F1b3RhICAgICAxICAgNTEySyAg
 ICAgICAtICAgICAgICAxICAKICAgIHVmc19tb3VudCAgICAxNiAgICA3N0sgICAgICAgLSAg
 ICAgICAyNSAgMTI4LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICBVTUFIYXNoICAgICAyICAg
 ICA0SyAgICAgICAtICAgICAgICA2ICA1MTIsMTAyNCwyMDQ4CiAgICAgIGFjcGlzZW0gICAg
 MTggICAgIDNLICAgICAgIC0gICAgICAgMTggIDEyOAogIGF0YV9nZW5lcmljICAgICA3ICAg
 ICA3SyAgICAgICAtICAgICAgICA3ICAxMDI0CiAgICB2bV9wZ2RhdGEgICAgIDIgICAxMjlL
 ICAgICAgIC0gICAgICAgIDIgIDEyOAogICAgYWRfZHJpdmVyICAgICA3ICAgICAxSyAgICAg
 ICAtICAgICAgICA3ICAzMgogICAgYXJfZHJpdmVyICAgICAwICAgICAwSyAgICAgICAtICAg
 ICAgIDQyICA1MTIsMjA0OAogICAgICBpb19hcGljICAgICAxICAgICAySyAgICAgICAtICAg
 ICAgICAxICAyMDQ4CiAgICAgICBrYmRtdXggICAgIDYgICAgMTBLICAgICAgIC0gICAgICAg
 IDYgIDE2LDUxMiwxMDI0LDIwNDgsNDA5NgogICAgICBtZW1kZXNjICAgICAxICAgICA0SyAg
 ICAgICAtICAgICAgICAxICA0MDk2CiAgICAgICAgICBtc2kgICAgIDEgICAgIDFLICAgICAg
 IC0gICAgICAgIDEgIDEyOAogICAgIG5leHVzZGV2ICAgICAzICAgICAxSyAgICAgICAtICAg
 ICAgICAzICAxNgogICAgICAgaXNhZGV2ICAgICA5ICAgICAySyAgICAgICAtICAgICAgICA5
 ICAxMjgKICAgICBhdGtiZGRldiAgICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgNjQK
 ICAgICAgbWRfZGlzayAgICAgMSAgICAgMksgICAgICAgLSAgICAgICAgMSAgMjA0OAogICAg
 ICBDQU0gWFBUICAgIDExICAgICAzSyAgICAgICAtICAgICAgIDMwICAzMiw2NCwxMjgsMjA0
 OAogICBDQU0gcGVyaXBoICAgICAyICAgICAxSyAgICAgICAtICAgICAgIDExICAxNiwzMiw2
 NCwxMjgsMjU2CiAgICAgIHNvbGFyaXMgOTU2ODQgMTQ3MDA3SyAgICAgICAtIDMyNjI1ODgz
 MSAgMTYsMzIsNjQsMTI4LDI1Niw1MTIsMTAyNCwyMDQ4LDQwOTYKICAga3N0YXRfZGF0YSAg
 ICAgMiAgICAgMUsgICAgICAgLSAgICAgICAgMiAgNjQKICAgICAgICBsaW51eCAgICAxMiAg
 ICAgMUsgICAgICAgLSAgICAgICAxMiAgNjQKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQp2bXN0YXQg
 LXoKCklURU0gICAgICAgICAgICAgICAgICAgICBTSVpFICAgICBMSU1JVCAgICAgIFVTRUQg
 ICAgICBGUkVFICBSRVFVRVNUUyAgRkFJTFVSRVMKClVNQSBLZWdzOiAgICAgICAgICAgICAg
 ICAgMjA4LCAgICAgICAgMCwgICAgICAxMTcsICAgICAgICAyLCAgICAgIDExOCwgICAgICAg
 IDAKVU1BIFpvbmVzOiAgICAgICAgICAgICAgICAyNTYsICAgICAgICAwLCAgICAgIDExNywg
 ICAgICAgIDMsICAgICAgMTE4LCAgICAgICAgMApVTUEgU2xhYnM6ICAgICAgICAgICAgICAg
 IDU2OCwgICAgICAgIDAsICAgICA2MjEzLCAgICAgMjAyNiwgIDYyNDAwNzQsICAgICAgICAw
 ClVNQSBSQ250U2xhYnM6ICAgICAgICAgICAgNTY4LCAgICAgICAgMCwgICAgIDMwODMsICAg
 ICAgICA0LCAgICAxOTUyMiwgICAgICAgIDAKVU1BIEhhc2g6ICAgICAgICAgICAgICAgICAy
 NTYsICAgICAgICAwLCAgICAgICAgMywgICAgICAgMTIsICAgICAgICA1LCAgICAgICAgMAox
 NiBCdWNrZXQ6ICAgICAgICAgICAgICAgIDE1MiwgICAgICAgIDAsICAgICAgIDE0LCAgICAg
 ICA4NiwgICAgICAxMzMsICAgICAgICAwCjMyIEJ1Y2tldDogICAgICAgICAgICAgICAgMjgw
 LCAgICAgICAgMCwgICAgICAgMzIsICAgICAgIDUyLCAgICAgIDIwNSwgICAgICAgIDAKNjQg
 QnVja2V0OiAgICAgICAgICAgICAgICA1MzYsICAgICAgICAwLCAgICAgICA1MiwgICAgICAg
 MTgsICAgICAgNDg0LCAgICAgICA1NQoxMjggQnVja2V0OiAgICAgICAgICAgICAgMTA0OCwg
 ICAgICAgIDAsICAgICAxNjYyLCAgICAgICAxMiwgICAgNDkwODIsICAgIDEyOTM3ClZNIE9C
 SkVDVDogICAgICAgICAgICAgICAgMjE2LCAgICAgICAgMCwgICAgMzA3ODQsICAgIDM2NDI4
 LCAgMjE3Mzc0OCwgICAgICAgIDAKTUFQOiAgICAgICAgICAgICAgICAgICAgICAyMzIsICAg
 ICAgICAwLCAgICAgICAgNywgICAgICAgMjUsICAgICAgICA3LCAgICAgICAgMApLTUFQIEVO
 VFJZOiAgICAgICAgICAgICAgIDEyMCwgICAyMjE4MDUsICAgICAgNjE2LCAgICAgMjMyOSwg
 MTY0MzM3MjMsICAgICAgICAwCk1BUCBFTlRSWTogICAgICAgICAgICAgICAgMTIwLCAgICAg
 ICAgMCwgICAgIDk2NjEsICAgICAyNzcwLCAgNTcwNDg2MiwgICAgICAgIDAKRFAgZmFrZXBn
 OiAgICAgICAgICAgICAgICAxMjAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg
 ICAgICAwLCAgICAgICAgMApTRyBmYWtlcGc6ICAgICAgICAgICAgICAgIDEyMCwgICAgICAg
 IDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCm10X3pvbmU6ICAg
 ICAgICAgICAgICAgICAyMDU2LCAgICAgICAgMCwgICAgICAyODMsICAgICAgIDM5LCAgICAg
 IDI4MywgICAgICAgIDAKMTY6ICAgICAgICAgICAgICAgICAgICAgICAgMTYsICAgICAgICAw
 LCAgICAgNzM1NiwgICAgMTQzMTYsIDU3NTM4NTgzLCAgICAgICAgMAozMjogICAgICAgICAg
 ICAgICAgICAgICAgICAzMiwgICAgICAgIDAsICAgICAzMzQ2LCAgICAgMTMwMCwgMTM1NzY3
 ODQsICAgICAgICAwCjY0OiAgICAgICAgICAgICAgICAgICAgICAgIDY0LCAgICAgICAgMCwg
 ICAgMzk2NjIsICAgIDIxNjU4LCAxMjM2NTY1NzIsICAgICAgICAwCjEyODogICAgICAgICAg
 ICAgICAgICAgICAgMTI4LCAgICAgICAgMCwgICAgMTAwNDIsICAgIDIzODMwLCA1MjU0Nzk3
 OCwgICAgICAgIDAKMjU2OiAgICAgICAgICAgICAgICAgICAgICAyNTYsICAgICAgICAwLCAg
 ICAgMzY1OCwgICAgIDQyMDIsIDg4NDI0NDM3LCAgICAgICAgMAo1MTI6ICAgICAgICAgICAg
 ICAgICAgICAgIDUxMiwgICAgICAgIDAsICAgIDU1MjE4LCAgICAzODQxNCwgNDIwNDk3Njgs
 ICAgICAgICAwCjEwMjQ6ICAgICAgICAgICAgICAgICAgICAxMDI0LCAgICAgICAgMCwgICAg
 ICAxMDIsICAgICAxODQ2LCAgMTY2MTg4MCwgICAgICAgIDAKMjA0ODogICAgICAgICAgICAg
 ICAgICAgIDIwNDgsICAgICAgICAwLCAgICAgIDIyMCwgICAgIDIyMDAsICAyNjY1NzMyLCAg
 ICAgICAgMAo0MDk2OiAgICAgICAgICAgICAgICAgICAgNDA5NiwgICAgICAgIDAsICAgICAg
 NDU4LCAgICAgIDM5NSwgIDExOTQ1NDksICAgICAgICAwCkZpbGVzOiAgICAgICAgICAgICAg
 ICAgICAgIDgwLCAgICAgICAgMCwgICAgMTk5NjEsICAgICAgNjA0LCAgMzA2NjYxMSwgICAg
 ICAgIDAKVFVSTlNUSUxFOiAgICAgICAgICAgICAgICAxMzYsICAgICAgICAwLCAgICAgIDUy
 OSwgICAgICAgNTEsICAgICAgNTI5LCAgICAgICAgMAp1bXR4IHBpOiAgICAgICAgICAgICAg
 ICAgICA5NiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAg
 ICAwClBST0M6ICAgICAgICAgICAgICAgICAgICAxMTIwLCAgICAgICAgMCwgICAgICAxNDMs
 ICAgICAgMTYwLCAgICA1Mzg0NCwgICAgICAgIDAKVEhSRUFEOiAgICAgICAgICAgICAgICAg
 ICA5MTIsICAgICAgICAwLCAgICAgIDQxNCwgICAgICAxMTQsICAgICA5NzMwLCAgICAgICAg
 MApTTEVFUFFVRVVFOiAgICAgICAgICAgICAgICA2NCwgICAgICAgIDAsICAgICAgNTI5LCAg
 ICAgICA4NywgICAgICA1MjksICAgICAgICAwClZNU1BBQ0U6ICAgICAgICAgICAgICAgICAg
 MzkyLCAgICAgICAgMCwgICAgICAxMDksICAgICAgMTYxLCAgICA1MzgwMywgICAgICAgIDAK
 Y3B1c2V0OiAgICAgICAgICAgICAgICAgICAgNzIsICAgICAgICAwLCAgICAgICAgMiwgICAg
 ICAgOTgsICAgICAgICAyLCAgICAgICAgMAphdWRpdF9yZWNvcmQ6ICAgICAgICAgICAgIDk1
 MiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCm1i
 dWZfcGFja2V0OiAgICAgICAgICAgICAgMjU2LCAgICAgICAgMCwgICAgICA3NDgsICAgICAg
 NTg3LCA0NDgyNjE1MCwgICAgICAgIDAKbWJ1ZjogICAgICAgICAgICAgICAgICAgICAyNTYs
 ICAgICAgICAwLCAgICAgMjUxNSwgICAgICA2OTcsIDExOTk1MTkyMywgICAgICAgIDAKbWJ1
 Zl9jbHVzdGVyOiAgICAgICAgICAgIDIwNDgsICAgIDMzNzkyLCAgICAgMTAyNCwgICAgICAy
 MzYsICAgICA2OTEyLCAgICAgICAgMAptYnVmX2p1bWJvX3BhZ2U6ICAgICAgICAgNDA5Niwg
 ICAgMTY4OTYsICAgICAxOTM0LCAgICAgIDUxOSwgIDcwOTQzMzgsICAgICAgICAwCm1idWZf
 anVtYm9fOWs6ICAgICAgICAgICA5MjE2LCAgICAyNTM0NCwgICAgICAgIDAsICAgICAgICAw
 LCAgICAgICAgMCwgICAgICAgIDAKbWJ1Zl9qdW1ib18xNms6ICAgICAgICAgMTYzODQsICAg
 IDE2ODk2LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMAptYnVmX2V4
 dF9yZWZjbnQ6ICAgICAgICAgICAgNCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwg
 ICAgICAgIDAsICAgICAgICAwCk5ldEdyYXBoIGl0ZW1zOiAgICAgICAgICAgMTA0LCAgICAg
 NDExOCwgICAgICAgIDAsICAgICAgMTE2LCAgICAxMTQxNCwgICAgICAgIDAKTmV0R3JhcGgg
 ZGF0YSBpdGVtczogICAgICAxMDQsICAgICAgNTIyLCAgICAgICAgMSwgICAgICAyMDMsIDQ0
 Njg5ODkxLCAgICAgICAgMApnX2JpbzogICAgICAgICAgICAgICAgICAgIDIzMiwgICAgICAg
 IDAsICAgICAgICAwLCAgICAgIDk3NiwgMjExMzYyMzQsICAgICAgICAwCnR0eWlucTogICAg
 ICAgICAgICAgICAgICAgMTYwLCAgICAgICAgMCwgICAgICAxOTUsICAgICAgIDY5LCAgICAg
 IDQyMCwgICAgICAgIDAKdHR5b3V0cTogICAgICAgICAgICAgICAgICAyNTYsICAgICAgICAw
 LCAgICAgIDEwNCwgICAgICAgNDYsICAgICAgMjI0LCAgICAgICAgMAphdGFfcmVxdWVzdDog
 ICAgICAgICAgICAgIDMxMiwgICAgICAgIDAsICAgICAgICAxLCAgICAgIDU3MywgMTA0MjEy
 MzYsICAgICAgICAwCmF0YV9jb21wb3NpdGU6ICAgICAgICAgICAgMzM2LCAgICAgICAgMCwg
 ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKdGFza3Ffem9uZTogICAg
 ICAgICAgICAgICAgNDgsICAgICAgICAwLCAgICAgICAgMCwgICAgICA0MzIsIDEwNDAwNjQx
 LCAgICAgICAgMApWTk9ERTogICAgICAgICAgICAgICAgICAgIDQ3MiwgICAgICAgIDAsICAg
 IDUyMTg5LCAgICAyNTg5OSwgIDI5Nzk1MzgsICAgICAgICAwClZOT0RFUE9MTDogICAgICAg
 ICAgICAgICAgMTEyLCAgICAgICAgMCwgICAgICAgIDUsICAgICAgIDk0LCAgICAgICAgOSwg
 ICAgICAgIDAKTkFNRUk6ICAgICAgICAgICAgICAgICAgIDEwMjQsICAgICAgICAwLCAgICAg
 ICAgMCwgICAgICAgOTIsIDE4ODkzMjQ2LCAgICAgICAgMApTIFZGUyBDYWNoZTogICAgICAg
 ICAgICAgIDEwOCwgICAgICAgIDAsICAgIDQxODYxLCAgICAzNzgwMSwgIDI4MTM0MjIsICAg
 ICAgICAwCkwgVkZTIENhY2hlOiAgICAgICAgICAgICAgMzI4LCAgICAgICAgMCwgICAgMTI3
 ODgsICAgICAgOTA0LCAgIDMwNTY5OSwgICAgICAgIDAKTkZTTU9VTlQ6ICAgICAgICAgICAg
 ICAgICA2MDgsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAg
 ICAgMApORlNOT0RFOiAgICAgICAgICAgICAgICAgIDY0OCwgICAgICAgIDAsICAgICAgICAw
 LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCkRJUkhBU0g6ICAgICAgICAgICAgICAg
 ICAxMDI0LCAgICAgICAgMCwgICAgICAgMTYsICAgICAgMTM2LCAgICAgMTc3OSwgICAgICAg
 IDAKemlvX2NhY2hlOiAgICAgICAgICAgICAgICA3MjAsICAgICAgICAwLCAgICAgICAgMSwg
 ICAgIDc1MjksIDQ1ODM1NjM0LCAgICAgICAgMApkbXVfYnVmX2ltcGxfdDogICAgICAgICAg
 IDIyNCwgICAgICAgIDAsICAgIDU2NjMwLCAgICA2NDY5OSwgIDcxNTgxMzMsICAgICAgICAw
 CmRub2RlX3Q6ICAgICAgICAgICAgICAgICAgNzY4LCAgICAgICAgMCwgICAgNTQzMTgsICAg
 IDM4NDYyLCAgMjY2MzQ2MSwgICAgICAgIDAKYXJjX2J1Zl9oZHJfdDogICAgICAgICAgICAy
 MDgsICAgICAgICAwLCAgICAgMzY1MSwgICAgIDY1NzMsICAyNjgwNzY5LCAgICAgICAgMAph
 cmNfYnVmX3Q6ICAgICAgICAgICAgICAgICA3MiwgICAgICAgIDAsICAgICAyMzQ3LCAgICAg
 NDUwMywgIDQ5MTUzNjcsICAgICAgICAwCnppbF9sd2JfY2FjaGU6ICAgICAgICAgICAgMjAw
 LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKemZz
 X3pub2RlX2NhY2hlOiAgICAgICAgICAzNzYsICAgICAgICAwLCAgICA0NzA1NywgICAgICAz
 MTMsICAyNzIwNTk1LCAgICAgICAgMApwaXBlOiAgICAgICAgICAgICAgICAgICAgIDcyOCwg
 ICAgICAgIDAsICAgICAgIDQ1LCAgICAgICA5MCwgICAgNDA4NzEsICAgICAgICAwCmtzaWdp
 bmZvOiAgICAgICAgICAgICAgICAgMTEyLCAgICAgICAgMCwgICAgICAyODgsICAgICAgIDc1
 LCAgICAgIDMwMywgICAgICAgIDAKaXRpbWVyOiAgICAgICAgICAgICAgICAgICAzNDQsICAg
 ICAgICAwLCAgICAgICAgMSwgICAgICAgMjEsICAgICAgICAxLCAgICAgICAgMApLTk9URTog
 ICAgICAgICAgICAgICAgICAgIDEyMCwgICAgICAgIDAsICAgICAgNTU1LCAgICAgIDcxNiwg
 MTYyMjU5NjMsICAgICAgICAwCmJyaWRnZV9ydG5vZGU6ICAgICAgICAgICAgIDY0LCAgICAg
 ICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKc29ja2V0OiAg
 ICAgICAgICAgICAgICAgICA2ODAsICAgIDMzNzkyLCAgICAgIDY0OCwgICAgICA1NzAsICAg
 NTcwODg4LCAgICAgICAgMAp1bnBjYjogICAgICAgICAgICAgICAgICAgIDI0MCwgICAgMzM3
 OTIsICAgICAgMTE3LCAgICAgIDE1NSwgICAgMzQ5NTIsICAgICAgICAwCmlwcTogICAgICAg
 ICAgICAgICAgICAgICAgIDU2LCAgICAgMTA3MSwgICAgICAgIDAsICAgICAgMTg5LCAgICAg
 ICAxOSwgICAgICAgIDAKdWRwX2lucGNiOiAgICAgICAgICAgICAgICAzMzYsICAgIDMzNzky
 LCAgICAgICAzNCwgICAgICAxODYsICAgIDkxNzY2LCAgICAgICAgMAp1ZHBjYjogICAgICAg
 ICAgICAgICAgICAgICAxNiwgICAgMzM5MzYsICAgICAgIDM0LCAgICAgIDQ3MCwgICAgOTE3
 NjYsICAgICAgICAwCnRjcF9pbnBjYjogICAgICAgICAgICAgICAgMzM2LCAgICAzMzc5Miwg
 ICAgICA3MjMsICAgICAgNjc0LCAgIDQ0MjAyOCwgICAgICAgIDAKdGNwY2I6ICAgICAgICAg
 ICAgICAgICAgICA4ODAsICAgIDMzNzkyLCAgICAgIDQ2OCwgICAgICA1ODgsICAgNDQyMDI4
 LCAgICAgICAgMAp0Y3B0dzogICAgICAgICAgICAgICAgICAgICA3MiwgICAgIDY4MDAsICAg
 ICAgMjU1LCAgICAgIDU0NSwgICAxODg5MDksICAgICAgICAwCnN5bmNhY2hlOiAgICAgICAg
 ICAgICAgICAgMTQ0LCAgICAxNTM2NiwgICAgICAgMTgsICAgICAgMjE2LCAgIDE0OTQ4OSwg
 ICAgICAgIDAKaG9zdGNhY2hlOiAgICAgICAgICAgICAgICAxMzYsICAgIDE1MzcyLCAgICAg
 NTk4MiwgICAgICA1OTgsICAgIDI0OTQzLCAgICAgICAgMAp0Y3ByZWFzczogICAgICAgICAg
 ICAgICAgICA0MCwgICAgIDIxODQsICAgICAgICAyLCAgICAgIDQxOCwgICAgMjUzOTksICAg
 ICAgICAwCnNhY2tob2xlOiAgICAgICAgICAgICAgICAgIDMyLCAgICAgICAgMCwgICAgICAg
 MzksICAgICAgNDY2LCAgMjEwNTgxMiwgICAgICAgIDAKc2N0cF9lcDogICAgICAgICAgICAg
 ICAgIDEyNDgsICAgIDMzNzkyLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAg
 ICAgMApzY3RwX2Fzb2M6ICAgICAgICAgICAgICAgMjE3NiwgICAgNDAwMDAsICAgICAgICAw
 LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnNjdHBfbGFkZHI6ICAgICAgICAgICAg
 ICAgIDQ4LCAgICA4MDA2NCwgICAgICAgIDAsICAgICAgMjE2LCAgICAgICAxNiwgICAgICAg
 IDAKc2N0cF9yYWRkcjogICAgICAgICAgICAgICA1OTIsICAgIDgwMDA0LCAgICAgICAgMCwg
 ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApzY3RwX2NodW5rOiAgICAgICAgICAgICAg
 IDE0NCwgICA0MDAwMTAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw
 CnNjdHBfcmVhZHE6ICAgICAgICAgICAgICAgMTA0LCAgIDQwMDAzMiwgICAgICAgIDAsICAg
 ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKc2N0cF9zdHJlYW1fbXNnX291dDogICAgICAg
 OTYsICAgNDAwMDI2LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApz
 Y3RwX2FzY29uZjogICAgICAgICAgICAgICA0MCwgICA0MDAwMDgsICAgICAgICAwLCAgICAg
 ICAgMCwgICAgICAgIDAsICAgICAgICAwCnNjdHBfYXNjb25mX2FjazogICAgICAgICAgIDQ4
 LCAgIDQwMDAzMiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKcmlw
 Y2I6ICAgICAgICAgICAgICAgICAgICAzMzYsICAgIDMzNzkyLCAgICAgICAgNCwgICAgICAg
 NTEsICAgICAyMDM1LCAgICAgICAgMApydGVudHJ5OiAgICAgICAgICAgICAgICAgIDIwMCwg
 ICAgICAgIDAsICAgICAgIDk0LCAgICAgICA1OCwgICAgICAxMTcsICAgICAgICAwCnBmc3Jj
 dHJwbDogICAgICAgICAgICAgICAgMTUyLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw
 LCAgICAgICAgMCwgICAgICAgIDAKcGZydWxlcGw6ICAgICAgICAgICAgICAgICA5MTIsICAg
 ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApwZnN0YXRl
 cGw6ICAgICAgICAgICAgICAgIDM5MiwgICAgMTAwMDAsICAgICAgICAwLCAgICAgICAgMCwg
 ICAgICAgIDAsICAgICAgICAwCnBmYWx0cXBsOiAgICAgICAgICAgICAgICAgMjQwLCAgICAg
 ICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKcGZwb29sYWRk
 cnBsOiAgICAgICAgICAgICAgODgsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg
 ICAgICAwLCAgICAgICAgMApwZnJrdGFibGU6ICAgICAgICAgICAgICAgMTI5NiwgICAgICAg
 IDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnBmcmtlbnRyeTog
 ICAgICAgICAgICAgICAgMjE2LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAg
 ICAgMCwgICAgICAgIDAKcGZya2VudHJ5MjogICAgICAgICAgICAgICAyMTYsICAgICAgICAw
 LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApwZmZyZW50OiAgICAg
 ICAgICAgICAgICAgICAzMiwgICAgIDUwNTAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg
 IDAsICAgICAgICAwCnBmZnJhZzogICAgICAgICAgICAgICAgICAgIDgwLCAgICAgICAgMCwg
 ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKcGZmcmNhY2hlOiAgICAg
 ICAgICAgICAgICAgODAsICAgIDEwMDM1LCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAw
 LCAgICAgICAgMApwZmZyY2VudDogICAgICAgICAgICAgICAgICAyNCwgICAgNTAwMjIsICAg
 ICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCnBmc3RhdGVzY3J1YjogICAg
 ICAgICAgICAgIDQwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwg
 ICAgICAgIDAKcGZpYWRkcnBsOiAgICAgICAgICAgICAgICAxMjAsICAgICAgICAwLCAgICAg
 ICAgMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApwZm9zcGZlbjogICAgICAgICAg
 ICAgICAgIDExMiwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAg
 ICAgICAwCnBmb3NmcDogICAgICAgICAgICAgICAgICAgIDQwLCAgICAgICAgMCwgICAgICAg
 IDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAKSVBGVyBkeW5hbWljIHJ1bGU6ICAg
 ICAgICAxMjAsICAgICAgICAwLCAgICAgIDY0NSwgICAgICA2NjAsICAyMjg4MDU5LCAgICAg
 ICAgMApkaXZjYjogICAgICAgICAgICAgICAgICAgIDMzNiwgICAgMzM3OTIsICAgICAgICAx
 LCAgICAgICAzMiwgICAgICAgIDIsICAgICAgICAwCmdfc2hzZWNfem9uZTogICAgICAgICAg
 MTMxMDcyLCAgICAgMzIwMCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAg
 IDAKZ19zdHJpcGVfem9uZTogICAgICAgICAxMzEwNzIsICAgICAzMjAwLCAgICAgICAgMCwg
 ICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMApzZWxmZDogICAgICAgICAgICAgICAgICAg
 ICA1NiwgICAgICAgIDAsICAgICAgNTQ1LCAgICAgIDQwMCwgMTQ2ODM1Nzg0LCAgICAgICAg
 MApTV0FQTUVUQTogICAgICAgICAgICAgICAgIDI4OCwgICAxMTY1MTksICAgICAgICA3LCAg
 ICAgICAzMiwgICAgICAgIDcsICAgICAgICAwCk1vdW50cG9pbnRzOiAgICAgICAgICAgICAg
 NzUyLCAgICAgICAgMCwgICAgICAgIDgsICAgICAgICA3LCAgICAgICAxMCwgICAgICAgIDAK
 RkZTIGlub2RlOiAgICAgICAgICAgICAgICAxNjgsICAgICAgICAwLCAgICAgNTA4OSwgICAg
 MTIzNzksICAgMjU4NzYyLCAgICAgICAgMApGRlMxIGRpbm9kZTogICAgICAgICAgICAgIDEy
 OCwgICAgICAgIDAsICAgICAgICAwLCAgICAgICAgMCwgICAgICAgIDAsICAgICAgICAwCkZG
 UzIgZGlub2RlOiAgICAgICAgICAgICAgMjU2LCAgICAgICAgMCwgICAgIDUwODksICAgICA4
 ODAxLCAgIDI1ODc1OSwgICAgICAgIDAKTmV0RmxvdyBjYWNoZTogICAgICAgICAgICAgODAs
 ICAgMjYyMTYwLCAgICAgIDI2NCwgICAgICA2MzUsICAgMzM4NTMzLCAgICAgICAgMAoKCi0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLQp2bXN0YXQgLWkKCmludGVycnVwdCAgICAgICAgICAgICAgICAg
 ICAgICAgICAgdG90YWwgICAgICAgcmF0ZQppcnExNjogYXRhcGNpMCsrICAgICAgICAgICAg
 ICAgICAgNDk3MzI4ICAgICAgICAgIDUKaXJxMTg6IG9oY2kyIG9oY2krICAgICAgICAgICAg
 ICAgICAgICAgNSAgICAgICAgICAwCmlycTIwOiB2cjAgICAgICAgICAgICAgICAgICAgICAg
 MzQ3MzYwOTMgICAgICAgIDM4OQppcnEyMTogdnIxICAgICAgICAgICAgICAgICAgICAgICA3
 NjUxMzM0ICAgICAgICAgODUKaXJxMjI6IGF0YXBjaTEgICAgICAgICAgICAgICAgICAgODQx
 NDA2OSAgICAgICAgIDk0CmNwdTA6IHRpbWVyICAgICAgICAgICAgICAgICAgICAxMDU5Nzky
 MDcgICAgICAgMTE4NwppcnEyNTY6IHJlMCAgICAgICAgICAgICAgICAgICAgICA2MjAzOTYw
 ICAgICAgICAgNjkKY3B1MTogdGltZXIgICAgICAgICAgICAgICAgICAgIDEwNTk3ODc2MiAg
 ICAgICAxMTg3ClRvdGFsICAgICAgICAgICAgICAgICAgICAgICAgICAyNjk0NjA3NTggICAg
 ICAgMzAyMAoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnBzdGF0IC1UCgoxOTk2MS82NTUzNiBmaWxl
 cwowTS8xNjM4M00gc3dhcCBzcGFjZQoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCnBzdGF0IC1zCgpE
 ZXZpY2UgICAgICAgICAgMUstYmxvY2tzICAgICBVc2VkICAgIEF2YWlsIENhcGFjaXR5Ci9k
 ZXYvYWQ2czFiICAgICAgMTY3NzcwODggICAgICAgMjggMTY3NzcwNjAgICAgIDAlCgotLS0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0KaW9zdGF0Cgppb3N0YXQ6IGt2bV9yZWFkKF90a19uaW4pOiBpbnZh
 bGlkIGFkZHJlc3MgKDB4MCkKaW9zdGF0OiBkaXNhYmxpbmcgVFRZIHN0YXRpc3RpY3MKaW9z
 dGF0OiBrdm1fZ2V0Y3B0aW1lOiBpbnZhbGlkIGFkZHJlc3MgKDB4MCkKaW9zdGF0OiBkaXNh
 YmxpbmcgQ1BVIHRpbWUgc3RhdGlzdGljcwogICAgICAgICAgICAgbWQwICAgICAgICAgICAg
 ICBhZDYgICAgICAgICAgICAgIGFkOCAKICBLQi90IHRwcyAgTUIvcyAgIEtCL3QgdHBzICBN
 Qi9zICAgS0IvdCB0cHMgIE1CL3MgCiAgMS4yNyAgIDAgIDAuMDAgIDI2LjA0ICAgNiAgMC4x
 NCAgMjYuMDggIDE1ICAwLjM3IAoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCmlwY3MgLWEKCk1lc3Nh
 Z2UgUXVldWVzOgpUICAgICAgICAgICBJRCAgICAgICAgICBLRVkgTU9ERSAgICAgICAgT1dO
 RVIgICAgR1JPVVAgICAgQ1JFQVRPUiAgQ0dST1VQICAgICAgICAgICAgICAgICBDQllURVMg
 ICAgICAgICAgICAgICAgIFFOVU0gICAgICAgICAgICAgICBRQllURVMgICAgICAgIExTUElE
 ICAgICAgICBMUlBJRCBTVElNRSAgICBSVElNRSAgICBDVElNRSAgIAoKU2hhcmVkIE1lbW9y
 eToKVCAgICAgICAgICAgSUQgICAgICAgICAgS0VZIE1PREUgICAgICAgIE9XTkVSICAgIEdS
 T1VQICAgIENSRUFUT1IgIENHUk9VUCAgICAgICAgIE5BVFRDSCAgICAgICAgU0VHU1ogICAg
 ICAgICBDUElEICAgICAgICAgTFBJRCBBVElNRSAgICBEVElNRSAgICBDVElNRSAgIAptICAg
 ICAgICA2NTUzNiAgICAgICAgICAgIDAgLS1ydy0tLS0tLS0gcm9vdCAgICAgd2hlZWwgICAg
 cm9vdCAgICAgd2hlZWwgICAgICAgICAgICAgIDEyICAgICAgIDUyNDI4OCAgICAgICAgIDE5
 NTAgICAgICAgICAxOTUwICAzOjQ0OjE5IDE4OjIwOjMwICAzOjQ0OjE5CgpTZW1hcGhvcmVz
 OgpUICAgICAgICAgICBJRCAgICAgICAgICBLRVkgTU9ERSAgICAgICAgT1dORVIgICAgR1JP
 VVAgICAgQ1JFQVRPUiAgQ0dST1VQICAgICAgICAgIE5TRU1TIE9USU1FICAgIENUSU1FICAg
 CgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tCmlwY3MgLVQKCm1zZ2luZm86Cgltc2dtYXg6ICAgICAg
 ICAzMjc4NAkobWF4IGNoYXJhY3RlcnMgaW4gYSBtZXNzYWdlKQoJbXNnbW5pOiAgICAgICAg
 ICAgNDEJKCMgb2YgbWVzc2FnZSBxdWV1ZXMpCgltc2dtbmI6ICAgICAgICAgMjA0OQkobWF4
 IGNoYXJhY3RlcnMgaW4gYSBtZXNzYWdlIHF1ZXVlKQoJbXNndHFsOiAgICAgICAgICAgNDEJ
 KG1heCAjIG9mIG1lc3NhZ2VzIGluIHN5c3RlbSkKCW1zZ3NzejogICAgICAgICAgIDE2CShz
 aXplIG9mIGEgbWVzc2FnZSBzZWdtZW50KQoJbXNnc2VnOiAgICAgICAgIDIwNDkJKCMgb2Yg
 bWVzc2FnZSBzZWdtZW50cyBpbiBzeXN0ZW0pCgpzaG1pbmZvOgoJc2htbWF4OiAgICAgIDgz
 ODg2MDgJKG1heCBzaGFyZWQgbWVtb3J5IHNlZ21lbnQgc2l6ZSkKCXNobW1pbjogICAgICAg
 ICAgICAyCShtaW4gc2hhcmVkIG1lbW9yeSBzZWdtZW50IHNpemUpCglzaG1tbmk6ICAgICAg
 ICAgICAzMwkobWF4IG51bWJlciBvZiBzaGFyZWQgbWVtb3J5IGlkZW50aWZpZXJzKQoJc2ht
 c2VnOiAgICAgICAgICAgIDkJKG1heCBzaGFyZWQgbWVtb3J5IHNlZ21lbnRzIHBlciBwcm9j
 ZXNzKQoJc2htYWxsOiAgICAgICAgIDIwNDgJKG1heCBhbW91bnQgb2Ygc2hhcmVkIG1lbW9y
 eSBpbiBwYWdlcykKCnNlbWluZm86CglzZW1tYXA6ICAgICAgICAgICAzMQkoIyBvZiBlbnRy
 aWVzIGluIHNlbWFwaG9yZSBtYXApCglzZW1tbmk6ICAgICAgICAgICAxMQkoIyBvZiBzZW1h
 cGhvcmUgaWRlbnRpZmllcnMpCglzZW1tbnM6ICAgICAgICAgICA2MQkoIyBvZiBzZW1hcGhv
 cmVzIGluIHN5c3RlbSkKCXNlbW1udTogICAgICAgICAgIDMxCSgjIG9mIHVuZG8gc3RydWN0
 dXJlcyBpbiBzeXN0ZW0pCglzZW1tc2w6ICAgICAgICAgICA2MQkobWF4ICMgb2Ygc2VtYXBo
 b3JlcyBwZXIgaWQpCglzZW1vcG06ICAgICAgICAgIDEwMQkobWF4ICMgb2Ygb3BlcmF0aW9u
 cyBwZXIgc2Vtb3AgY2FsbCkKCXNlbXVtZTogICAgICAgICAgIDExCShtYXggIyBvZiB1bmRv
 IGVudHJpZXMgcGVyIHByb2Nlc3MpCglzZW11c3o6ICAgICAgICAgIDE2MAkoc2l6ZSBpbiBi
 eXRlcyBvZiB1bmRvIHN0cnVjdHVyZSkKCXNlbXZteDogICAgICAgIDMyNzY3CShzZW1hcGhv
 cmUgbWF4aW11bSB2YWx1ZSkKCXNlbWFlbTogICAgICAgIDE2Mzg0CShhZGp1c3Qgb24gZXhp
 dCBtYXggdmFsdWUpCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCm5mc3N0YXQKCkNsaWVudCBJbmZv
 OgpScGMgQ291bnRzOgogIEdldGF0dHIgICBTZXRhdHRyICAgIExvb2t1cCAgUmVhZGxpbmsg
 ICAgICBSZWFkICAgICBXcml0ZSAgICBDcmVhdGUgICAgUmVtb3ZlCiAgICAgICAgMCAgICAg
 ICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAg
 MCAgICAgICAgIDAKICAgUmVuYW1lICAgICAgTGluayAgIFN5bWxpbmsgICAgIE1rZGlyICAg
 ICBSbWRpciAgIFJlYWRkaXIgIFJkaXJQbHVzICAgIEFjY2VzcwogICAgICAgIDAgICAgICAg
 ICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAg
 ICAgICAgICAwCiAgICBNa25vZCAgICBGc3N0YXQgICAgRnNpbmZvICBQYXRoQ29uZiAgICBD
 b21taXQKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAg
 MApScGMgSW5mbzoKIFRpbWVkT3V0ICAgSW52YWxpZCBYIFJlcGxpZXMgICBSZXRyaWVzICBS
 ZXF1ZXN0cwogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAg
 ICAwCkNhY2hlIEluZm86CkF0dHIgSGl0cyAgICBNaXNzZXMgTGt1cCBIaXRzICAgIE1pc3Nl
 cyBCaW9SIEhpdHMgICAgTWlzc2VzIEJpb1cgSGl0cyAgICBNaXNzZXMKICAgICAgICAwICAg
 ICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAg
 ICAwICAgICAgICAgMApCaW9STEhpdHMgICAgTWlzc2VzIEJpb0QgSGl0cyAgICBNaXNzZXMg
 RGlyRSBIaXRzICAgIE1pc3NlcwogICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAg
 ICAgIDAgICAgICAgICAwICAgICAgICAgMAoKU2VydmVyIEluZm86CiAgR2V0YXR0ciAgIFNl
 dGF0dHIgICAgTG9va3VwICBSZWFkbGluayAgICAgIFJlYWQgICAgIFdyaXRlICAgIENyZWF0
 ZSAgICBSZW1vdmUKICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAg
 ICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMAogICBSZW5hbWUgICAgICBM
 aW5rICAgU3ltbGluayAgICAgTWtkaXIgICAgIFJtZGlyICAgUmVhZGRpciAgUmRpclBsdXMg
 ICAgQWNjZXNzCiAgICAgICAgMCAgICAgICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAg
 ICAgIDAgICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKICAgIE1rbm9kICAgIEZzc3Rh
 dCAgICBGc2luZm8gIFBhdGhDb25mICAgIENvbW1pdAogICAgICAgIDAgICAgICAgICAwICAg
 ICAgICAgMCAgICAgICAgIDAgICAgICAgICAwClNlcnZlciBSZXQtRmFpbGVkCiAgICAgICAg
 ICAgICAgICAwClNlcnZlciBGYXVsdHMKICAgICAgICAgICAgMApTZXJ2ZXIgQ2FjaGUgU3Rh
 dHM6CiAgIElucHJvZyAgICAgIElkZW0gIE5vbi1pZGVtICAgIE1pc3NlcwogICAgICAgIDAg
 ICAgICAgICAwICAgICAgICAgMCAgICAgICAgIDAKU2VydmVyIFdyaXRlIEdhdGhlcmluZzoK
 IFdyaXRlT3BzICBXcml0ZVJQQyAgIE9wc2F2ZWQKICAgICAgICAwICAgICAgICAgMCAgICAg
 ICAgIDAKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpuZXRzdGF0IC1zCgp0Y3A6CgkzMTMxNDY2OCBw
 YWNrZXRzIHNlbnQKCQkyMTIyNTcxOSBkYXRhIHBhY2tldHMgKDI4MzEyODU3Mzc2IGJ5dGVz
 KQoJCTU4MzYwMDUgZGF0YSBwYWNrZXRzICg4MTQyNzIxODQyIGJ5dGVzKSByZXRyYW5zbWl0
 dGVkCgkJMTQ3NjkyIGRhdGEgcGFja2V0cyB1bm5lY2Vzc2FyaWx5IHJldHJhbnNtaXR0ZWQK
 CQkxNCByZXNlbmRzIGluaXRpYXRlZCBieSBNVFUgZGlzY292ZXJ5CgkJMzQ0ODcwNSBhY2st
 b25seSBwYWNrZXRzICg3Mzk4NzMgZGVsYXllZCkKCQkwIFVSRyBvbmx5IHBhY2tldHMKCQkx
 MDA0IHdpbmRvdyBwcm9iZSBwYWNrZXRzCgkJMTkxNzQ5IHdpbmRvdyB1cGRhdGUgcGFja2V0
 cwoJCTYxMjEzOSBjb250cm9sIHBhY2tldHMKCTE5MjQzNzQzIHBhY2tldHMgcmVjZWl2ZWQK
 CQkxMDkxMjYxMiBhY2tzIChmb3IgMjgyOTgwMjAyMDggYnl0ZXMpCgkJMzk1NjEwMiBkdXBs
 aWNhdGUgYWNrcwoJCTkwIGFja3MgZm9yIHVuc2VudCBkYXRhCgkJNDc1NjgwNCBwYWNrZXRz
 ICgzNTAyNzUxODMwIGJ5dGVzKSByZWNlaXZlZCBpbi1zZXF1ZW5jZQoJCTgwMDYzIGNvbXBs
 ZXRlbHkgZHVwbGljYXRlIHBhY2tldHMgKDUzOTM3OTIgYnl0ZXMpCgkJNDM3IG9sZCBkdXBs
 aWNhdGUgcGFja2V0cwoJCTQ1NDMgcGFja2V0cyB3aXRoIHNvbWUgZHVwLiBkYXRhICg0NzQ3
 MTYgYnl0ZXMgZHVwZWQpCgkJMjUzNzcgb3V0LW9mLW9yZGVyIHBhY2tldHMgKDI0MzAzODg3
 IGJ5dGVzKQoJCTE0IHBhY2tldHMgKDAgYnl0ZXMpIG9mIGRhdGEgYWZ0ZXIgd2luZG93CgkJ
 MCB3aW5kb3cgcHJvYmVzCgkJMjYzNDg2IHdpbmRvdyB1cGRhdGUgcGFja2V0cwoJCTE2Nzcg
 cGFja2V0cyByZWNlaXZlZCBhZnRlciBjbG9zZQoJCTM0NyBkaXNjYXJkZWQgZm9yIGJhZCBj
 aGVja3N1bXMKCQkwIGRpc2NhcmRlZCBmb3IgYmFkIGhlYWRlciBvZmZzZXQgZmllbGRzCgkJ
 MCBkaXNjYXJkZWQgYmVjYXVzZSBwYWNrZXQgdG9vIHNob3J0CgkJMjMgZGlzY2FyZGVkIGR1
 ZSB0byBtZW1vcnkgcHJvYmxlbXMKCTMzNzQ3OCBjb25uZWN0aW9uIHJlcXVlc3RzCgkxMDM0
 OTIgY29ubmVjdGlvbiBhY2NlcHRzCgkxMzMgYmFkIGNvbm5lY3Rpb24gYXR0ZW1wdHMKCTAg
 bGlzdGVuIHF1ZXVlIG92ZXJmbG93cwoJMjc4OCBpZ25vcmVkIFJTVHMgaW4gdGhlIHdpbmRv
 d3MKCTI5ODAyMCBjb25uZWN0aW9ucyBlc3RhYmxpc2hlZCAoaW5jbHVkaW5nIGFjY2VwdHMp
 Cgk0NDEzMDUgY29ubmVjdGlvbnMgY2xvc2VkIChpbmNsdWRpbmcgODc3MyBkcm9wcykKCQkx
 MzE3NTAgY29ubmVjdGlvbnMgdXBkYXRlZCBjYWNoZWQgUlRUIG9uIGNsb3NlCgkJMTM0NTUw
 IGNvbm5lY3Rpb25zIHVwZGF0ZWQgY2FjaGVkIFJUVCB2YXJpYW5jZSBvbiBjbG9zZQoJCTY3
 NzEzIGNvbm5lY3Rpb25zIHVwZGF0ZWQgY2FjaGVkIHNzdGhyZXNoIG9uIGNsb3NlCgk0MDA5
 MyBlbWJyeW9uaWMgY29ubmVjdGlvbnMgZHJvcHBlZAoJNzk0NDM2MSBzZWdtZW50cyB1cGRh
 dGVkIHJ0dCAob2YgODA5MTg2NyBhdHRlbXB0cykKCTMxMzE0NjUgcmV0cmFuc21pdCB0aW1l
 b3V0cwoJCTIwNDcgY29ubmVjdGlvbnMgZHJvcHBlZCBieSByZXhtaXQgdGltZW91dAoJMTM0
 MiBwZXJzaXN0IHRpbWVvdXRzCgkJMSBjb25uZWN0aW9uIGRyb3BwZWQgYnkgcGVyc2lzdCB0
 aW1lb3V0CgkwIENvbm5lY3Rpb25zIChmaW5fd2FpdF8yKSBkcm9wcGVkIGJlY2F1c2Ugb2Yg
 dGltZW91dAoJMjAwIGtlZXBhbGl2ZSB0aW1lb3V0cwoJCTAga2VlcGFsaXZlIHByb2JlcyBz
 ZW50CgkJMjAwIGNvbm5lY3Rpb25zIGRyb3BwZWQgYnkga2VlcGFsaXZlCgk1NzQ0NDkgY29y
 cmVjdCBBQ0sgaGVhZGVyIHByZWRpY3Rpb25zCgkzMzk2NzUzIGNvcnJlY3QgZGF0YSBwYWNr
 ZXQgaGVhZGVyIHByZWRpY3Rpb25zCgkxNDk0ODkgc3luY2FjaGUgZW50cmllcyBhZGRlZAoJ
 CTg1NzQ4IHJldHJhbnNtaXR0ZWQKCQkzODU0NiBkdXBzeW4KCQkwIGRyb3BwZWQKCQkxMDM0
 OTIgY29tcGxldGVkCgkJMCBidWNrZXQgb3ZlcmZsb3cKCQkwIGNhY2hlIG92ZXJmbG93CgkJ
 MjYxMjMgcmVzZXQKCQkxOTY0MSBzdGFsZQoJCTAgYWJvcnRlZAoJCTAgYmFkYWNrCgkJMjEz
 IHVucmVhY2gKCQkwIHpvbmUgZmFpbHVyZXMKCTE0OTQ4OSBjb29raWVzIHNlbnQKCTUgY29v
 a2llcyByZWNlaXZlZAoJNjU1MDE3IFNBQ0sgcmVjb3ZlcnkgZXBpc29kZXMKCTEyMjIzNDgg
 c2VnbWVudCByZXhtaXRzIGluIFNBQ0sgcmVjb3ZlcnkgZXBpc29kZXMKCTE3MTYzMDM5NzEg
 Ynl0ZSByZXhtaXRzIGluIFNBQ0sgcmVjb3ZlcnkgZXBpc29kZXMKCTQ3OTMyODEgU0FDSyBv
 cHRpb25zIChTQUNLIGJsb2NrcykgcmVjZWl2ZWQKCTI4OTMwIFNBQ0sgb3B0aW9ucyAoU0FD
 SyBibG9ja3MpIHNlbnQKCTAgU0FDSyBzY29yZWJvYXJkIG92ZXJmbG93CgkwIHBhY2tldHMg
 d2l0aCBFQ04gQ0UgYml0IHNldAoJMCBwYWNrZXRzIHdpdGggRUNOIEVDVCgwKSBiaXQgc2V0
 CgkwIHBhY2tldHMgd2l0aCBFQ04gRUNUKDEpIGJpdCBzZXQKCTAgc3VjY2Vzc2Z1bCBFQ04g
 aGFuZHNoYWtlcwoJMCB0aW1lcyBFQ04gcmVkdWNlZCB0aGUgY29uZ2VzdGlvbiB3aW5kb3cK
 dWRwOgoJNDkzNTA4IGRhdGFncmFtcyByZWNlaXZlZAoJMCB3aXRoIGluY29tcGxldGUgaGVh
 ZGVyCgkwIHdpdGggYmFkIGRhdGEgbGVuZ3RoIGZpZWxkCgkzMTkzIHdpdGggYmFkIGNoZWNr
 c3VtCgk5MTgzIHdpdGggbm8gY2hlY2tzdW0KCTcyMzY4IGRyb3BwZWQgZHVlIHRvIG5vIHNv
 Y2tldAoJMjIwODEgYnJvYWRjYXN0L211bHRpY2FzdCBkYXRhZ3JhbXMgdW5kZWxpdmVyZWQK
 CTAgZHJvcHBlZCBkdWUgdG8gZnVsbCBzb2NrZXQgYnVmZmVycwoJMCBub3QgZm9yIGhhc2hl
 ZCBwY2IKCTM5NTg2NiBkZWxpdmVyZWQKCTM4MDk1MiBkYXRhZ3JhbXMgb3V0cHV0CgkwIHRp
 bWVzIG11bHRpY2FzdCBzb3VyY2UgZmlsdGVyIG1hdGNoZWQKaXA6CgkyNDUyODU4MSB0b3Rh
 bCBwYWNrZXRzIHJlY2VpdmVkCgkyOCBiYWQgaGVhZGVyIGNoZWNrc3VtcwoJMCB3aXRoIHNp
 emUgc21hbGxlciB0aGFuIG1pbmltdW0KCTAgd2l0aCBkYXRhIHNpemUgPCBkYXRhIGxlbmd0
 aAoJMCB3aXRoIGlwIGxlbmd0aCA+IG1heCBpcCBwYWNrZXQgc2l6ZQoJMCB3aXRoIGhlYWRl
 ciBsZW5ndGggPCBkYXRhIHNpemUKCTAgd2l0aCBkYXRhIGxlbmd0aCA8IGhlYWRlciBsZW5n
 dGgKCTAgd2l0aCBiYWQgb3B0aW9ucwoJMSB3aXRoIGluY29ycmVjdCB2ZXJzaW9uIG51bWJl
 cgoJMzAgZnJhZ21lbnRzIHJlY2VpdmVkCgkwIGZyYWdtZW50cyBkcm9wcGVkIChkdXAgb3Ig
 b3V0IG9mIHNwYWNlKQoJOCBmcmFnbWVudHMgZHJvcHBlZCBhZnRlciB0aW1lb3V0CgkxMSBw
 YWNrZXRzIHJlYXNzZW1ibGVkIG9rCgkxOTgwNjIzNyBwYWNrZXRzIGZvciB0aGlzIGhvc3QK
 CTI0ODY2NiBwYWNrZXRzIGZvciB1bmtub3duL3Vuc3VwcG9ydGVkIHByb3RvY29sCgk1Mjk0
 MjAgcGFja2V0cyBmb3J3YXJkZWQgKDAgcGFja2V0cyBmYXN0IGZvcndhcmRlZCkKCTUwNjAg
 cGFja2V0cyBub3QgZm9yd2FyZGFibGUKCTAgcGFja2V0cyByZWNlaXZlZCBmb3IgdW5rbm93
 biBtdWx0aWNhc3QgZ3JvdXAKCTAgcmVkaXJlY3RzIHNlbnQKCTMyMjg5ODE1IHBhY2tldHMg
 c2VudCBmcm9tIHRoaXMgaG9zdAoJMTAzODIgcGFja2V0cyBzZW50IHdpdGggZmFicmljYXRl
 ZCBpcCBoZWFkZXIKCTIxNjQgb3V0cHV0IHBhY2tldHMgZHJvcHBlZCBkdWUgdG8gbm8gYnVm
 cywgZXRjLgoJMCBvdXRwdXQgcGFja2V0cyBkaXNjYXJkZWQgZHVlIHRvIG5vIHJvdXRlCgkx
 IG91dHB1dCBkYXRhZ3JhbSBmcmFnbWVudGVkCgkyIGZyYWdtZW50cyBjcmVhdGVkCgkwIGRh
 dGFncmFtcyB0aGF0IGNhbid0IGJlIGZyYWdtZW50ZWQKCTAgdHVubmVsaW5nIHBhY2tldHMg
 dGhhdCBjYW4ndCBmaW5kIGdpZgoJMCBkYXRhZ3JhbXMgd2l0aCBiYWQgYWRkcmVzcyBpbiBo
 ZWFkZXIKaWNtcDoKCTcyMzc2IGNhbGxzIHRvIGljbXBfZXJyb3IKCTAgZXJyb3JzIG5vdCBn
 ZW5lcmF0ZWQgaW4gcmVzcG9uc2UgdG8gYW4gaWNtcCBtZXNzYWdlCglPdXRwdXQgaGlzdG9n
 cmFtOgoJCWVjaG8gcmVwbHk6IDQ2OQoJCWRlc3RpbmF0aW9uIHVucmVhY2hhYmxlOiA3MjM3
 NQoJCXRpbWUgZXhjZWVkZWQ6IDEKCTAgbWVzc2FnZXMgd2l0aCBiYWQgY29kZSBmaWVsZHMK
 CTAgbWVzc2FnZXMgbGVzcyB0aGFuIHRoZSBtaW5pbXVtIGxlbmd0aAoJNTQ2IG1lc3NhZ2Vz
 IHdpdGggYmFkIGNoZWNrc3VtCgkwIG1lc3NhZ2VzIHdpdGggYmFkIGxlbmd0aAoJNCBtdWx0
 aWNhc3QgZWNobyByZXF1ZXN0cyBpZ25vcmVkCgkwIG11bHRpY2FzdCB0aW1lc3RhbXAgcmVx
 dWVzdHMgaWdub3JlZAoJSW5wdXQgaGlzdG9ncmFtOgoJCWVjaG8gcmVwbHk6IDI5NjgKCQlk
 ZXN0aW5hdGlvbiB1bnJlYWNoYWJsZTogNDcyMzUKCQlzb3VyY2UgcXVlbmNoOiAxNDg4CgkJ
 cm91dGluZyByZWRpcmVjdDogMTg2CgkJZWNobzogNDczCgkJdGltZSBleGNlZWRlZDogNTUw
 MgoJNDY5IG1lc3NhZ2UgcmVzcG9uc2VzIGdlbmVyYXRlZAoJMCBpbnZhbGlkIHJldHVybiBh
 ZGRyZXNzZXMKCTEgbm8gcmV0dXJuIHJvdXRlCmlnbXA6CgkyNDgxMDIgbWVzc2FnZXMgcmVj
 ZWl2ZWQKCTAgbWVzc2FnZXMgcmVjZWl2ZWQgd2l0aCB0b28gZmV3IGJ5dGVzCgkwIG1lc3Nh
 Z2VzIHJlY2VpdmVkIHdpdGggd3JvbmcgVFRMCgkwIG1lc3NhZ2VzIHJlY2VpdmVkIHdpdGgg
 YmFkIGNoZWNrc3VtCgkzNjA5OCBWMS9WMiBtZW1iZXJzaGlwIHF1ZXJpZXMgcmVjZWl2ZWQK
 CTQ1NSBWMyBtZW1iZXJzaGlwIHF1ZXJpZXMgcmVjZWl2ZWQKCTAgbWVtYmVyc2hpcCBxdWVy
 aWVzIHJlY2VpdmVkIHdpdGggaW52YWxpZCBmaWVsZChzKQoJMzM4IGdlbmVyYWwgcXVlcmll
 cyByZWNlaXZlZAoJMzYyMTUgZ3JvdXAgcXVlcmllcyByZWNlaXZlZAoJMCBncm91cC1zb3Vy
 Y2UgcXVlcmllcyByZWNlaXZlZAoJMCBncm91cC1zb3VyY2UgcXVlcmllcyBkcm9wcGVkCgkw
 IG1lbWJlcnNoaXAgcmVwb3J0cyByZWNlaXZlZAoJMCBtZW1iZXJzaGlwIHJlcG9ydHMgcmVj
 ZWl2ZWQgd2l0aCBpbnZhbGlkIGZpZWxkKHMpCgkwIG1lbWJlcnNoaXAgcmVwb3J0cyByZWNl
 aXZlZCBmb3IgZ3JvdXBzIHRvIHdoaWNoIHdlIGJlbG9uZwoJMTQ3IFYzIHJlcG9ydHMgcmVj
 ZWl2ZWQgd2l0aG91dCBSb3V0ZXIgQWxlcnQKCTAgbWVtYmVyc2hpcCByZXBvcnRzIHNlbnQK
 cGltOgoJMCBtZXNzYWdlcyByZWNlaXZlZAoJMCBieXRlcyByZWNlaXZlZAoJMCBtZXNzYWdl
 cyByZWNlaXZlZCB3aXRoIHRvbyBmZXcgYnl0ZXMKCTAgbWVzc2FnZXMgcmVjZWl2ZWQgd2l0
 aCBiYWQgY2hlY2tzdW0KCTAgbWVzc2FnZXMgcmVjZWl2ZWQgd2l0aCBiYWQgdmVyc2lvbgoJ
 MCBkYXRhIHJlZ2lzdGVyIG1lc3NhZ2VzIHJlY2VpdmVkCgkwIGRhdGEgcmVnaXN0ZXIgYnl0
 ZXMgcmVjZWl2ZWQKCTAgZGF0YSByZWdpc3RlciBtZXNzYWdlcyByZWNlaXZlZCBvbiB3cm9u
 ZyBpaWYKCTAgYmFkIHJlZ2lzdGVycyByZWNlaXZlZAoJMCBkYXRhIHJlZ2lzdGVyIG1lc3Nh
 Z2VzIHNlbnQKCTAgZGF0YSByZWdpc3RlciBieXRlcyBzZW50CmNhcnA6CgkwIHBhY2tldHMg
 cmVjZWl2ZWQgKElQdjQpCgkwIHBhY2tldHMgcmVjZWl2ZWQgKElQdjYpCgkJMCBwYWNrZXRz
 IGRpc2NhcmRlZCBmb3Igd3JvbmcgVFRMCgkJMCBwYWNrZXRzIHNob3J0ZXIgdGhhbiBoZWFk
 ZXIKCQkwIGRpc2NhcmRlZCBmb3IgYmFkIGNoZWNrc3VtcwoJCTAgZGlzY2FyZGVkIHBhY2tl
 dHMgd2l0aCBhIGJhZCB2ZXJzaW9uCgkJMCBkaXNjYXJkZWQgYmVjYXVzZSBwYWNrZXQgdG9v
 IHNob3J0CgkJMCBkaXNjYXJkZWQgZm9yIGJhZCBhdXRoZW50aWNhdGlvbgoJCTAgZGlzY2Fy
 ZGVkIGZvciBiYWQgdmhpZAoJCTAgZGlzY2FyZGVkIGJlY2F1c2Ugb2YgYSBiYWQgYWRkcmVz
 cyBsaXN0CgkwIHBhY2tldHMgc2VudCAoSVB2NCkKCTAgcGFja2V0cyBzZW50IChJUHY2KQoJ
 CTAgc2VuZCBmYWlsZWQgZHVlIHRvIG1idWYgbWVtb3J5IGVycm9yCnBmc3luYzoKCTAgcGFj
 a2V0cyByZWNlaXZlZCAoSVB2NCkKCTAgcGFja2V0cyByZWNlaXZlZCAoSVB2NikKCQkwIHBh
 Y2tldHMgZGlzY2FyZGVkIGZvciBiYWQgaW50ZXJmYWNlCgkJMCBwYWNrZXRzIGRpc2NhcmRl
 ZCBmb3IgYmFkIHR0bAoJCTAgcGFja2V0cyBzaG9ydGVyIHRoYW4gaGVhZGVyCgkJMCBwYWNr
 ZXRzIGRpc2NhcmRlZCBmb3IgYmFkIHZlcnNpb24KCQkwIHBhY2tldHMgZGlzY2FyZGVkIGZv
 ciBiYWQgSE1BQwoJCTAgcGFja2V0cyBkaXNjYXJkZWQgZm9yIGJhZCBhY3Rpb24KCQkwIHBh
 Y2tldHMgZGlzY2FyZGVkIGZvciBzaG9ydCBwYWNrZXQKCQkwIHN0YXRlcyBkaXNjYXJkZWQg
 Zm9yIGJhZCB2YWx1ZXMKCQkwIHN0YWxlIHN0YXRlcwoJCTAgZmFpbGVkIHN0YXRlIGxvb2t1
 cC9pbnNlcnRzCgkwIHBhY2tldHMgc2VudCAoSVB2NCkKCTAgcGFja2V0cyBzZW50IChJUHY2
 KQoJCTAgc2VuZCBmYWlsZWQgZHVlIHRvIG1idWYgbWVtb3J5IGVycm9yCgkJMCBzZW5kIGVy
 cm9yCmlwNjoKCTEyMTg4IHRvdGFsIHBhY2tldHMgcmVjZWl2ZWQKCTAgd2l0aCBzaXplIHNt
 YWxsZXIgdGhhbiBtaW5pbXVtCgkwIHdpdGggZGF0YSBzaXplIDwgZGF0YSBsZW5ndGgKCTAg
 d2l0aCBiYWQgb3B0aW9ucwoJMCB3aXRoIGluY29ycmVjdCB2ZXJzaW9uIG51bWJlcgoJMCBm
 cmFnbWVudHMgcmVjZWl2ZWQKCTAgZnJhZ21lbnRzIGRyb3BwZWQgKGR1cCBvciBvdXQgb2Yg
 c3BhY2UpCgkwIGZyYWdtZW50cyBkcm9wcGVkIGFmdGVyIHRpbWVvdXQKCTAgZnJhZ21lbnRz
 IHRoYXQgZXhjZWVkZWQgbGltaXQKCTAgcGFja2V0cyByZWFzc2VtYmxlZCBvawoJMTEzODkg
 cGFja2V0cyBmb3IgdGhpcyBob3N0Cgk3OTkgcGFja2V0cyBmb3J3YXJkZWQKCTAgcGFja2V0
 cyBub3QgZm9yd2FyZGFibGUKCTAgcmVkaXJlY3RzIHNlbnQKCTE1NzgwIHBhY2tldHMgc2Vu
 dCBmcm9tIHRoaXMgaG9zdAoJMCBwYWNrZXRzIHNlbnQgd2l0aCBmYWJyaWNhdGVkIGlwIGhl
 YWRlcgoJMCBvdXRwdXQgcGFja2V0cyBkcm9wcGVkIGR1ZSB0byBubyBidWZzLCBldGMuCgk2
 IG91dHB1dCBwYWNrZXRzIGRpc2NhcmRlZCBkdWUgdG8gbm8gcm91dGUKCTAgb3V0cHV0IGRh
 dGFncmFtcyBmcmFnbWVudGVkCgkwIGZyYWdtZW50cyBjcmVhdGVkCgkwIGRhdGFncmFtcyB0
 aGF0IGNhbid0IGJlIGZyYWdtZW50ZWQKCTAgcGFja2V0cyB0aGF0IHZpb2xhdGVkIHNjb3Bl
 IHJ1bGVzCgkxMCBtdWx0aWNhc3QgcGFja2V0cyB3aGljaCB3ZSBkb24ndCBqb2luCglJbnB1
 dCBoaXN0b2dyYW06CgkJaG9wIGJ5IGhvcDogNwoJCVRDUDogMTc4CgkJVURQOiAxNDg0CgkJ
 SUNNUDY6IDEwNTE5CglNYnVmIHN0YXRpc3RpY3M6CgkJNzExOCBvbmUgbWJ1ZgoJCTUwNzAg
 b25lIGV4dCBtYnVmCgkJMCB0d28gb3IgbW9yZSBleHQgbWJ1ZgoJMCBwYWNrZXRzIHdob3Nl
 IGhlYWRlcnMgYXJlIG5vdCBjb250aW51b3VzCgkwIHR1bm5lbGluZyBwYWNrZXRzIHRoYXQg
 Y2FuJ3QgZmluZCBnaWYKCTAgcGFja2V0cyBkaXNjYXJkZWQgYmVjYXVzZSBvZiB0b28gbWFu
 eSBoZWFkZXJzCgkwIGZhaWx1cmVzIG9mIHNvdXJjZSBhZGRyZXNzIHNlbGVjdGlvbgoJU291
 cmNlIGFkZHJlc3NlcyBzZWxlY3Rpb24gcnVsZSBhcHBsaWVkOgoJCTE1MzgwIGZpcnN0IGNh
 bmRpZGF0ZQoJCTE1IHNhbWUgYWRkcmVzcwoJCTEzNTM3IG91dGdvaW5nIGludGVyZmFjZQpp
 Y21wNjoKCTU2MiBjYWxscyB0byBpY21wNl9lcnJvcgoJMCBlcnJvcnMgbm90IGdlbmVyYXRl
 ZCBpbiByZXNwb25zZSB0byBhbiBpY21wNiBtZXNzYWdlCgkwIGVycm9ycyBub3QgZ2VuZXJh
 dGVkIGJlY2F1c2Ugb2YgcmF0ZSBsaW1pdGF0aW9uCglPdXRwdXQgaGlzdG9ncmFtOgoJCXVu
 cmVhY2g6IDU2MgoJCWVjaG86IDEwMzMyCgkJcm91dGVyIGFkdmVydGlzZW1lbnQ6IDE0MgoJ
 CW5laWdoYm9yIHNvbGljaXRhdGlvbjogMzIzNQoJCU1MRHYyIGxpc3RlbmVyIHJlcG9ydDog
 OAoJMCBtZXNzYWdlcyB3aXRoIGJhZCBjb2RlIGZpZWxkcwoJMCBtZXNzYWdlcyA8IG1pbmlt
 dW0gbGVuZ3RoCgkwIGJhZCBjaGVja3N1bXMKCTAgbWVzc2FnZXMgd2l0aCBiYWQgbGVuZ3Ro
 CglJbnB1dCBoaXN0b2dyYW06CgkJdW5yZWFjaDogNgoJCXRpbWUgZXhjZWVkOiA0NzQzCgkJ
 ZWNobyByZXBseTogMzUwMAoJCXJvdXRlciBzb2xpY2l0YXRpb246IDYKCQlyb3V0ZXIgYWR2
 ZXJ0aXNlbWVudDogMTQyCgkJbmVpZ2hib3IgYWR2ZXJ0aXNlbWVudDogMTUzNQoJSGlzdG9n
 cmFtIG9mIGVycm9yIG1lc3NhZ2VzIHRvIGJlIGdlbmVyYXRlZDoKCQkwIG5vIHJvdXRlCgkJ
 MCBhZG1pbmlzdHJhdGl2ZWx5IHByb2hpYml0ZWQKCQkwIGJleW9uZCBzY29wZQoJCTU2MiBh
 ZGRyZXNzIHVucmVhY2hhYmxlCgkJMCBwb3J0IHVucmVhY2hhYmxlCgkJMCBwYWNrZXQgdG9v
 IGJpZwoJCTAgdGltZSBleGNlZWQgdHJhbnNpdAoJCTAgdGltZSBleGNlZWQgcmVhc3NlbWJs
 eQoJCTAgZXJyb25lb3VzIGhlYWRlciBmaWVsZAoJCTAgdW5yZWNvZ25pemVkIG5leHQgaGVh
 ZGVyCgkJMCB1bnJlY29nbml6ZWQgb3B0aW9uCgkJMCByZWRpcmVjdAoJCTAgdW5rbm93bgoJ
 MCBtZXNzYWdlIHJlc3BvbnNlcyBnZW5lcmF0ZWQKCTAgbWVzc2FnZXMgd2l0aCB0b28gbWFu
 eSBORCBvcHRpb25zCgkwIG1lc3NhZ2VzIHdpdGggYmFkIE5EIG9wdGlvbnMKCTAgYmFkIG5l
 aWdoYm9yIHNvbGljaXRhdGlvbiBtZXNzYWdlcwoJMCBiYWQgbmVpZ2hib3IgYWR2ZXJ0aXNl
 bWVudCBtZXNzYWdlcwoJMCBiYWQgcm91dGVyIHNvbGljaXRhdGlvbiBtZXNzYWdlcwoJMCBi
 YWQgcm91dGVyIGFkdmVydGlzZW1lbnQgbWVzc2FnZXMKCTAgYmFkIHJlZGlyZWN0IG1lc3Nh
 Z2VzCgkwIHBhdGggTVRVIGNoYW5nZXMKcmlwNjoKCTAgbWVzc2FnZXMgcmVjZWl2ZWQKCTAg
 Y2hlY2tzdW0gY2FsY3VsYXRpb25zIG9uIGluYm91bmQKCTAgbWVzc2FnZXMgd2l0aCBiYWQg
 Y2hlY2tzdW0KCTAgbWVzc2FnZXMgZHJvcHBlZCBkdWUgdG8gbm8gc29ja2V0CgkwIG11bHRp
 Y2FzdCBtZXNzYWdlcyBkcm9wcGVkIGR1ZSB0byBubyBzb2NrZXQKCTAgbWVzc2FnZXMgZHJv
 cHBlZCBkdWUgdG8gZnVsbCBzb2NrZXQgYnVmZmVycwoJMCBkZWxpdmVyZWQKCTAgZGF0YWdy
 YW1zIG91dHB1dAoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCm5ldHN0YXQgLW0KCjMyNjMvMTI4NC80
 NTQ3IG1idWZzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbCkKNDM3LzgyMy8xMjYwLzMz
 NzkyIG1idWYgY2x1c3RlcnMgaW4gdXNlIChjdXJyZW50L2NhY2hlL3RvdGFsL21heCkKNzQ4
 LzU4NyBtYnVmK2NsdXN0ZXJzIG91dCBvZiBwYWNrZXQgc2Vjb25kYXJ5IHpvbmUgaW4gdXNl
 IChjdXJyZW50L2NhY2hlKQoxOTM0LzUxOS8yNDUzLzE2ODk2IDRrIChwYWdlIHNpemUpIGp1
 bWJvIGNsdXN0ZXJzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbC9tYXgpCjAvMC8wLzI1
 MzQ0IDlrIGp1bWJvIGNsdXN0ZXJzIGluIHVzZSAoY3VycmVudC9jYWNoZS90b3RhbC9tYXgp
 CjAvMC8wLzE2ODk2IDE2ayBqdW1ibyBjbHVzdGVycyBpbiB1c2UgKGN1cnJlbnQvY2FjaGUv
 dG90YWwvbWF4KQo5NDI1Sy80MDQzSy8xMzQ2OEsgYnl0ZXMgYWxsb2NhdGVkIHRvIG5ldHdv
 cmsgKGN1cnJlbnQvY2FjaGUvdG90YWwpCjAvMC8wIHJlcXVlc3RzIGZvciBtYnVmcyBkZW5p
 ZWQgKG1idWZzL2NsdXN0ZXJzL21idWYrY2x1c3RlcnMpCjAvMC8wIHJlcXVlc3RzIGZvciBq
 dW1ibyBjbHVzdGVycyBkZW5pZWQgKDRrLzlrLzE2aykKMCByZXF1ZXN0cyBmb3Igc2ZidWZz
 IGRlbmllZAowIHJlcXVlc3RzIGZvciBzZmJ1ZnMgZGVsYXllZAowIHJlcXVlc3RzIGZvciBJ
 L08gaW5pdGlhdGVkIGJ5IHNlbmRmaWxlCjAgY2FsbHMgdG8gcHJvdG9jb2wgZHJhaW4gcm91
 dGluZXMKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpuZXRzdGF0IC1pZAoKTmFtZSAgICBNdHUgTmV0
 d29yayAgICAgICBBZGRyZXNzICAgICAgICAgICAgICBJcGt0cyBJZXJycyAgICBPcGt0cyBP
 ZXJycyAgQ29sbCBEcm9wCnJlMCAgICAxNTAwIDxMaW5rIzE+ICAgICAgMDA6ZTA6NGQ6N2I6
 Njk6MGMgIDM3NDUwMDcgICAgIDAgIDUzMzQxMTQgICAgIDAgICAgIDAgICAgMCAKcmUwICAg
 IDE1MDAgMTAuMC4wLjAgICAgICBvdHJhZGEubG9jYWwgICAgICAgMzUzNTk0MiAgICAgLSAg
 NTE0ODQ0MCAgICAgLSAgICAgLSAgICAtIApyZTAgICAgMTUwMCAyMDAxOjVjMDoxNTAzIDIw
 MDE6NWMwOjE1MDM6MzQwICAgICAgICAwICAgICAtICAgICAxODI4ICAgICAtICAgICAtICAg
 IC0gCnZyMCAgICAxNTAwIDxMaW5rIzI+ICAgICAgMDA6MTE6OTU6ZmY6YTc6YzAgMTM1MTI2
 MjYgICAgIDAgMjIyNDA4NTQgICAgIDAgICAgIDAgICAgMCAKdnIxICAgIDE1MDAgPExpbmsj
 Mz4gICAgICAwMDowMjo0NDo4Yjo4OTo0MCAgMzA0MTE1NCAgICAgMCAgNDcwNjY0NCAgICAg
 MCAgICAgMCAgICAwIAp2cjEgICAgMTUwMCAxOTIuMTY4LjYwLjAvIDE5Mi4xNjguNjAuMTk0
 ICAgICAgIDQ5MjE3ICAgICAtICAgIDI2NjAzICAgICAtICAgICAtICAgIC0gCmxvMCAgIDE2
 Mzg0IDxMaW5rIzQ+ICAgICAgICAgICAgICAgICAgICAgICAgICA1NTE4ODEgICAgIDAgICA1
 NTE4ODIgICAgIDAgICAgIDAgICAgMCAKbG8wICAgMTYzODQgZmU4MDo0OjoxICAgICBmZTgw
 OjQ6OjEgICAgICAgICAgICAgICAgMCAgICAgLSAgICAgICAgMCAgICAgLSAgICAgLSAgICAt
 IApsbzAgICAxNjM4NCBsb2NhbGhvc3QgICAgIDo6MSAgICAgICAgICAgICAgICAgICAgICAw
 ICAgICAtICAgICAgICA0ICAgICAtICAgICAtICAgIC0gCmxvMCAgIDE2Mzg0IHlvdXItbmV0
 ICAgICAgbG9jYWxob3N0ICAgICAgICAgICAyMjc5NTIgICAgIC0gICA1NTE4NzggICAgIC0g
 ICAgIC0gICAgLSAKcGZzeW4gIDE0NjAgPExpbmsjNT4gICAgICAgICAgICAgICAgICAgICAg
 ICAgICAgICAgMCAgICAgMCAgICAgICAgMCAgICAgMCAgICAgMCAgICAwIApwZmxvZyAzMzE1
 MiA8TGluayM2PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAwICAgICAg
 ICAwICAgICAwICAgICAwICAgIDAgCnR1bjEgICAxNDkyIDxMaW5rIzc+ICAgICAgICAgICAg
 ICAgICAgICAgICAgMTM0NzY4NTIgICAgIDAgMjIyMzIwNDkgICAgIDAgICAgIDAgMjE2NCAK
 dHVuMSAgIDE0OTIgODkuMjA5LjgxLjU0LyBvdHJhZGEub2QudWEgICAgICAxMzQ4NjI5NyAg
 ICAgLSAyMTkwMDU5NyAgICAgLSAgICAgLSAgICAtIAp0dW4yICAgMTQ5MiA8TGluayM4PiAg
 ICAgICAgICAgICAgICAgICAgICAgICAyNDg4MjQ1ICAgICAwICA0NjcxMDk1ICAgICAwICAg
 ICAwICAgIDAgCnR1bjIgICAxNDkyIDE4OC4xMTUuMTI4LjMgMTg4LTExNS0xMjgtMy5icm8g
 IDI0ODE1NzYgICAgIC0gIDQ2NzEwOTMgICAgIC0gICAgIC0gICAgLSAKZ2lmMCAgIDEyODAg
 PExpbmsjOT4gICAgICAgICAgICAgICAgICAgICAgICAgICAxMjAzMSAgICAgMCAgICAxMzkz
 NiAgICAgMCAgICAgMCAgICAwIApnaWYwICAgMTI4MCB1bml2ZXJzaXRlLmJyIDIwMDE6NWMw
 OjE0MDA6Yjo6ICAgICAgICAwICAgICAtICAgIDEzOTMzICAgICAtICAgICAtICAgIC0gCgot
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLS0KbmV0c3RhdCAtYW5yCgpSb3V0aW5nIHRhYmxlcwoKSW50ZXJu
 ZXQ6CkRlc3RpbmF0aW9uICAgICAgICBHYXRld2F5ICAgICAgICAgICAgRmxhZ3MgICAgUmVm
 cyAgICAgIFVzZSAgTmV0aWYgRXhwaXJlCmRlZmF1bHQgICAgICAgICAgICA4OS4yMDkuOTUu
 MjU0ICAgICAgVUdTICAgICAgICAgMCAyMjU2MTI5MSAgIHR1bjEKMTAuMC4wLjAvMjQgICAg
 ICAgIGxpbmsjMSAgICAgICAgICAgICBVICAgICAgICAgICAwICA1MzMyMTg5ICAgIHJlMCA9
 PgoxMC4wLjAuMC84ICAgICAgICAgMTkyLjE2OC42MS4yNTAgICAgIFVHUyAgICAgICAgIDAg
 ICAgMTQ0MjUgICAgdnIxCjEwLjAuMC4xICAgICAgICAgICBsaW5rIzQgICAgICAgICAgICAg
 VUhTICAgICAgICAgMCAgIDE0MTAzOCAgICBsbzAKNjIuMTYuMC4wLzE5ICAgICAgIHR1bjIg
 ICAgICAgICAgICAgICBVUyAgICAgICAgICAwICAgICAxOTQ2ICAgdHVuMgo2NC4xMi4wLjAv
 MTYgICAgICAgdHVuMiAgICAgICAgICAgICAgIFVTICAgICAgICAgIDAgICAgICAgMzMgICB0
 dW4yCjY0LjE1MS4xMjMuNzggICAgICB0dW4yICAgICAgICAgICAgICAgVUhTICAgICAgICAg
 MCAgICAgICAgMCAgIHR1bjIKNzQuNjMuMzIuMC8xOSAgICAgIHR1bjIgICAgICAgICAgICAg
 ICBVUyAgICAgICAgICAwICAgICAxNDUxICAgdHVuMgo3Ny45MS4xOTIuMC8yMSAgICAgdHVu
 MiAgICAgICAgICAgICAgIFVTICAgICAgICAgIDAgICAgIDIxODEgICB0dW4yCjc3LjE3Ni4w
 LjAvMTIgICAgICB0dW4yICAgICAgICAgICAgICAgVVMgICAgICAgICAgMCAgICAgMjM3NyAg
 IHR1bjIKNzcuMjQxLjM0LjAvMjQgICAgIHR1bjIgICAgICAgICAgICAgICBVUyAgICAgICAg
 ICAwICAgICAgNjI2ICAgdHVuMgo3OC4yNS4zMi4wLzIyICAgICAgdHVuMiAgICAgICAgICAg
 ICAgIFVTICAgICAgICAgIDAgICAgICAxMTEgICB0dW4yCjc4LjM2LjAuMC8xNSAgICAgICB0
 dW4yICAgICAgICAgICAgICAgVVMgICAgICAgICAgMCAgMTEyMzQ5NCAgIHR1bjIKNzguNDgu
 MC4wLzEzICAgICAgIHR1bjIgICAgICAgICAgICAgICBVUyAgICAgICAgICAwICAgIDM3NTk2
 ICAgdHVuMgo3OC4xMDYuMC4wLzE1ICAgICAgdHVuMiAgICAgICAgICAgICAgIFVTICAgICAg
 ICAgIDAgICAyNTc3NTkgICB0dW4yCjc5LjEzNS4xMjguMC8xOSAgICB0dW4yICAgICAgICAg
 ICAgICAgVVMgICAgICAgICAgMCAgICAgICAyOSAgIHR1bjIKNzkuMTQwLjAuMC8yMCAgICAg
 IHR1bjIgICAgICAgICAgICAgICBVUyAgICAgICAgICAwICAgIDEzMDQ4ICAgdHVuMgo4MC45
 My4xNzYuMC8yMCAgICAgdHVuMiAgICAgICAgICAgICAgIFVTICAgICAgICAgIDAgICAgICAz
 NDcgICB0dW4yCjgxLjI1LjIyNC4wLzI0ICAgICB0dW4yICAgICAgICAgICAgICAgVVMgICAg
 ICAgICAgMCAgICAgIDExMyAgIHR1bjIKODEuMjUuMjI1LjAvMjQgICAgIHR1bjIgICAgICAg
 ICAgICAgICBVUyAgICAgICAgICAwICAgICAgIDE4ICAgdHVuMgo4My4yMzcuMC4wLzE2ICAg
 ICAgdHVuMiAgICAgICAgICAgICAgIFVTICAgICAgICAgIDAgICAgNTgzMTMgICB0dW4yCjgz
 LjIzOS4zMi4wLzE5ICAgICB0dW4yICAgICAgICAgICAgICAgVVMgICAgICAgICAgMCAgICAg
 NTQwMCAgIHR1bjIKODQuMzIuMjQwLjAvMjEgICAgIHR1bjIgICAgICAgICAgICAgICBVUyAg
 ICAgICAgICAwICAgICAgICA0ICAgdHVuMgo4NC41OC4wLjAvMTYgICAgICAgdHVuMiAgICAg
 ICAgICAgICAgIFVTICAgICAgICAgIDAgICAgICAyODIgICB0dW4yCjg1LjIxLjAuMC8xNiAg
 ICAgICB0dW4yICAgICAgICAgICAgICAgVVMgICAgICAgICAgMCAgICAxMTg2NyAgIHR1bjIK
 ODUuMzAuMjI0LjAvMjAgICAgIHR1bjIgICAgICAgICAgICAgICBVUyAgICAgICAgICAwICAg
 ICAgNjY5ICAgdHVuMgo4NS4xNDAuMC4wLzE1ICAgICAgdHVuMiAgICAgICAgICAgICAgIFVT
 ICAgICAgICAgIDAgICAzMzkzMjkgICB0dW4yCjg1LjE1OS4wLjAvMjEgICAgICB0dW4yICAg
 ICAgICAgICAgICAgVVMgICAgICAgICAgMCAgICAgIDE1OCAgIHR1bjIKODUuMTc2LjAuMC8x
 MyAgICAgIHR1bjIgICAgICAgICAgICAgICBVUyAgICAgICAgICAwICAgMTU1MzQyICAgdHVu
 Mgo4NS4yMzguOTYuMC8xOSAgICAgdHVuMiAgICAgICAgICAgICAgIFVTICAgICAgICAgIDAg
 ICA2MTk3OTEgICB0dW4yCjg2LjU3LjEyOC4wLzE3ICAgICB0dW4yICAgICAgICAgICAgICAg
 VVMgICAgICAgICAgMCAgIDEwMzAzNSAgIHR1bjIKODcuMjQ5LjU2LjAvMjQgICAgIHR1bjIg
 ICAgICAgICAgICAgICBVUyAgICAgICAgICAwICAgICAgNTc0ICAgdHVuMgo4OS4xMTAuMC4w
 LzE4ICAgICAgdHVuMiAgICAgICAgICAgICAgIFVTICAgICAgICAgIDAgICAgIDcxNDcgICB0
 dW4yCjg5LjE2My4wLjAvMTcgICAgICB0dW4yICAgICAgICAgICAgICAgVVMgICAgICAgICAg
 MCAgICA0NjczMCAgIHR1bjIKODkuMTc5LjcyLjAvMjEgICAgIHR1bjIgICAgICAgICAgICAg
 ICBVUyAgICAgICAgICAwICAgICAgNDY5ICAgdHVuMgo4OS4yMDkuODEuNTQgICAgICAgbGlu
 ayM0ICAgICAgICAgICAgIFVIUyAgICAgICAgIDAgICAxNjcyMTAgICAgbG8wCjg5LjIxOC4w
 LjAvMTYgICAgICB0dW4yICAgICAgICAgICAgICAgVVMgICAgICAgICAgMCAgICAxNDEzOSAg
 IHR1bjIKODkuMjM5LjEyOC4wLzE4ICAgIHR1bjIgICAgICAgICAgICAgICBVUyAgICAgICAg
 ICAwICAgICAgOTU4ICAgdHVuMgo5MC4xNTEuMTYuMC8yMCAgICAgdHVuMiAgICAgICAgICAg
 ICAgIFVTICAgICAgICAgIDAgICAgMzMzMjUgICB0dW4yCjkxLjc2LjAuMC8xNCAgICAgICB0
 dW4yICAgICAgICAgICAgICAgVVMgICAgICAgICAgMCAgIDcyNzc0NSAgIHR1bjIKOTIuMTEy
 LjAuMC8xNSAgICAgIHR1bjIgICAgICAgICAgICAgICBVUyAgICAgICAgICAwICAgNTUyNTk4
 ICAgdHVuMgoxMjcuMC4wLjEgICAgICAgICAgbGluayM0ICAgICAgICAgICAgIFVIICAgICAg
 ICAgIDAgICAyMjc5NTIgICAgbG8wCjE1OS4xNDguMC4wLzE2ICAgICB0dW4yICAgICAgICAg
 ICAgICAgVVMgICAgICAgICAgMCAgICAgMTUxMSAgIHR1bjIKMTg4LjExNS4xMjguMyAgICAg
 IGxpbmsjNCAgICAgICAgICAgICBVSFMgICAgICAgICAwICAgIDE1MjYxICAgIGxvMAoxOTIu
 MTY4LjAuMC8xNiAgICAgMTkyLjE2OC42MS4yNTAgICAgIFVHUyAgICAgICAgIDAgICAgIDM2
 MzAgICAgdnIxCjE5Mi4xNjguNjAuMC8yMyAgICBsaW5rIzMgICAgICAgICAgICAgVSAgICAg
 ICAgICAgMCAgICAgIDExNiAgICB2cjEKMTkyLjE2OC42MC4xOTQgICAgIGxpbmsjNCAgICAg
 ICAgICAgICBVSFMgICAgICAgICAwICAgICAgNDE3ICAgIGxvMAoxOTIuMTY4LjE1Mi4wLzI0
 ICAgMTAuMC4wLjIwICAgICAgICAgIFVHUyAgICAgICAgIDAgICAgICAgIDAgICAgcmUwCjE5
 My4yMi44NC4wLzI0ICAgICB0dW4yICAgICAgICAgICAgICAgVVMgICAgICAgICAgMCAgICAg
 ICAgMCAgIHR1bjIKMTk0LjQ0LjMwLjAvMjQgICAgIHR1bjIgICAgICAgICAgICAgICBVUyAg
 ICAgICAgICAwICAgICAgICAwICAgdHVuMgoxOTQuMjA0LjAuMC8xOSAgICAgdHVuMiAgICAg
 ICAgICAgICAgIFVTICAgICAgICAgIDAgICAgICAgIDEgICB0dW4yCjE5NS42Ni4xOTIuMC8x
 OSAgICB0dW4yICAgICAgICAgICAgICAgVVMgICAgICAgICAgMCAgICAgICA3MCAgIHR1bjIK
 MTk1LjcyLjE1Ni4wLzIyICAgIHR1bjIgICAgICAgICAgICAgICBVUyAgICAgICAgICAwICAg
 ICAgMjgwICAgdHVuMgoxOTUuMTE0LjEyOC4wLzE5ICAgdHVuMiAgICAgICAgICAgICAgIFVT
 ICAgICAgICAgIDAgICAgICAgODIgICB0dW4yCjE5NS4xMzguNjQuMC8xOSAgICB0dW4yICAg
 ICAgICAgICAgICAgVVMgICAgICAgICAgMCAgICAgNjEyNiAgIHR1bjIKMTk1LjEzOC42OC44
 OC8yOSAgIDE5Mi4xNjguNjEuMjUwICAgICBVR1MgICAgICAgICAwICAgICAgICAwICAgIHZy
 MQoxOTUuMTM4Ljc4LjY0LzI4ICAgMTkyLjE2OC42MS4yNTAgICAgIFVHUyAgICAgICAgIDAg
 ICAgICAyNzAgICAgdnIxCjE5NS4xMzguODAuMjQvMzIgICAxOTIuMTY4LjYxLjI1MCAgICAg
 VUdTICAgICAgICAgMCAgICAgICAgMCAgICB2cjEKMTk1LjEzOC44MC4zMy8zMiAgIDE5Mi4x
 NjguNjEuMjUwICAgICBVR1MgICAgICAgICAwICAgICA4MjM3ICAgIHZyMQoxOTUuMTM4Ljgw
 LjQwLzMyICAgMTkyLjE2OC42MS4yNTAgICAgIFVHUyAgICAgICAgIDAgICAgICAgIDAgICAg
 dnIxCjE5NS4xMzguODAuNTAvMzIgICAxOTIuMTY4LjYxLjI1MCAgICAgVUdTICAgICAgICAg
 MCAgICAgICAgMCAgICB2cjEKMTk1LjEzOC44MC41NC8zMiAgIDE5Mi4xNjguNjEuMjUwICAg
 ICBVR1MgICAgICAgICAwICAgICAgICAwICAgIHZyMQoxOTUuMTM4LjgwLjE3NSAgICAgbGlu
 ayM4ICAgICAgICAgICAgIFVIUyAgICAgICAgIDAgICAgICAgIDAgICB0dW4yCjIwOC45My4w
 LjAvMjIgICAgICB0dW4yICAgICAgICAgICAgICAgVVMgICAgICAgICAgMCAgICAgNjEyMiAg
 IHR1bjIKMjA4LjExMy42NC4wLzE4ICAgIHR1bjEgICAgICAgICAgICAgICBVUyAgICAgICAg
 ICAwICAgICAgICAwICAgdHVuMQoyMTIuMTc4LjAuMC8xOSAgICAgdHVuMiAgICAgICAgICAg
 ICAgIFVTICAgICAgICAgIDAgICA0MDc5NjIgICB0dW4yCjIxMi4yMjAuNjQuMC8xOCAgICB0
 dW4yICAgICAgICAgICAgICAgVVMgICAgICAgICAgMCAgICAgMTA4NyAgIHR1bjIKMjEzLjg3
 LjYxLjAvMjQgICAgIHR1bjIgICAgICAgICAgICAgICBVUyAgICAgICAgICAwICAgICAgICAw
 ICAgdHVuMgoyMTMuMTcxLjMyLjAvMTkgICAgdHVuMiAgICAgICAgICAgICAgIFVTICAgICAg
 ICAgIDAgICAgIDk0NzUgICB0dW4yCjIxNy4yMjQuMC4wLzExICAgICB0dW4yICAgICAgICAg
 ICAgICAgVVMgICAgICAgICAgMCAgIDEyOTc1NiAgIHR1bjIKCkludGVybmV0NjoKRGVzdGlu
 YXRpb24gICAgICAgICAgICAgICAgICAgICAgIEdhdGV3YXkgICAgICAgICAgICAgICAgICAg
 ICAgIEZsYWdzICAgICAgTmV0aWYgRXhwaXJlCmRlZmF1bHQgICAgICAgICAgICAgICAgICAg
 ICAgICAgICAyMDAxOjVjMDoxNDAwOmI6OjI3ZTggICAgICAgICBVR1MgICAgICAgIGdpZjAK
 OjoxICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDo6MSAgICAgICAgICAgICAgICAg
 ICAgICAgICAgIFVIICAgICAgICAgIGxvMAoyMDAxOjVjMDoxNDAwOmI6OjI3ZTggICAgICAg
 ICAgICAgMjAwMTo1YzA6MTQwMDpiOjoyN2U5ICAgICAgICAgVUggICAgICAgICBnaWYwCjIw
 MDE6NWMwOjE1MDM6MzQwMDo6LzY0ICAgICAgICAgICBsaW5rIzEgICAgICAgICAgICAgICAg
 ICAgICAgICBVICAgICAgICAgICByZTAgPT4KMjAwMTo1YzA6MTUwMzozNDAwOjovNTYgICAg
 ICAgICAgIGxvMCAgICAgICAgICAgICAgICAgICAgICAgICAgIFVTICAgICAgICAgIGxvMAoy
 MDAxOjVjMDoxNTAzOjM0MDA6OjEgICAgICAgICAgICAgbGluayMxICAgICAgICAgICAgICAg
 ICAgICAgICAgVUhTICAgICAgICAgbG8wCmZlODA6OiVsbzAvNjQgICAgICAgICAgICAgICAg
 ICAgICBsaW5rIzQgICAgICAgICAgICAgICAgICAgICAgICBVICAgICAgICAgICBsbzAKZmU4
 MDo6MSVsbzAgICAgICAgICAgICAgICAgICAgICAgIGxpbmsjNCAgICAgICAgICAgICAgICAg
 ICAgICAgIFVIUyAgICAgICAgIGxvMApmZjAxOjE6Oi8zMiAgICAgICAgICAgICAgICAgICAg
 ICAgMjAwMTo1YzA6MTUwMzozNDAwOjoxICAgICAgICAgVSAgICAgICAgICAgcmUwCmZmMDE6
 NDo6LzMyICAgICAgICAgICAgICAgICAgICAgICBmZTgwOjoxJWxvMCAgICAgICAgICAgICAg
 ICAgICBVICAgICAgICAgICBsbzAKZmYwMTo5OjovMzIgICAgICAgICAgICAgICAgICAgICAg
 IDIwMDE6NWMwOjE0MDA6Yjo6MjdlOSAgICAgICAgIFUgICAgICAgICAgZ2lmMApmZjAyOjol
 cmUwLzMyICAgICAgICAgICAgICAgICAgICAgMjAwMTo1YzA6MTUwMzozNDAwOjoxICAgICAg
 ICAgVSAgICAgICAgICAgcmUwCmZmMDI6OiVsbzAvMzIgICAgICAgICAgICAgICAgICAgICBm
 ZTgwOjoxJWxvMCAgICAgICAgICAgICAgICAgICBVICAgICAgICAgICBsbzAKZmYwMjo6JWdp
 ZjAvMzIgICAgICAgICAgICAgICAgICAgIDIwMDE6NWMwOjE0MDA6Yjo6MjdlOSAgICAgICAg
 IFUgICAgICAgICAgZ2lmMAoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCm5ldHN0YXQgLWFuQQoKQWN0
 aXZlIEludGVybmV0IGNvbm5lY3Rpb25zIChpbmNsdWRpbmcgc2VydmVycykKVGNwY2IgICAg
 UHJvdG8gUmVjdi1RIFNlbmQtUSAgTG9jYWwgQWRkcmVzcyAgICAgIEZvcmVpZ24gQWRkcmVz
 cyAgIChzdGF0ZSkKZmZmZmZmMDEyNTFhYTM3MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIw
 OS44MS41NC44MCAgICA4OS4yMDkuODEuNTQuMTY2MTcgRVNUQUJMSVNIRUQKZmZmZmZmMDA0
 NGFhNTAwMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjYxNyA4OS4yMDku
 ODEuNTQuODAgICAgRVNUQUJMSVNIRUQKZmZmZmZmMDBhN2U2ZmE1MCB0Y3A0ICAgICAgIDAg
 ICAgICAwIDEwLjAuMC4xLjMxMjggICAgICAxMC4wLjAuMTAuMjM3OSAgICAgRVNUQUJMSVNI
 RUQKZmZmZmZmMDEyNTE5MzZlMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC44
 MCAgICA4OS4yMDkuODEuNTQuMTY2MTYgRVNUQUJMSVNIRUQKZmZmZmZmMDA0NjFiNDAwMCB0
 Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjYxNiA4OS4yMDkuODEuNTQuODAg
 ICAgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTFlMTZlMCB0Y3A0ICAgICAgIDAgICAgICAwIDEw
 LjAuMC4xLjMxMjggICAgICAxMC4wLjAuMTAuMjM3OCAgICAgRVNUQUJMSVNIRUQKZmZmZmZm
 MDAwNWFkNmE2OCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC44MCAgICA4OS4y
 MDkuODEuNTQuMTY2MTUgVElNRV9XQUlUCmZmZmZmZjAxMDA3MGEwMDAgdGNwNCAgICAgICAw
 ICAgMTc4MSAxMC4wLjAuMS4zMTI4ICAgICAgMTAuMC4wLjEwLjIzNzcgICAgIEZJTl9XQUlU
 XzEKZmZmZmZmMDEyNTI1NTNmMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC44
 MCAgICA4OS4yMDkuODEuNTQuMTY2MTQgVElNRV9XQUlUCmZmZmZmZjAwNDQ5MmIwMDAgdGNw
 NCAgICAgICAwICAgMTYyMiAxMC4wLjAuMS4zMTI4ICAgICAgMTAuMC4wLjEwLjIzNzYgICAg
 IEZJTl9XQUlUXzEKZmZmZmZmMDE4ZDg5YjAwMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIw
 OS44MS41NC44MCAgICA4OS4yMDkuODEuNTQuMTY2MTMgRVNUQUJMSVNIRUQKZmZmZmZmMDEy
 NTBhZGE1MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjYxMyA4OS4yMDku
 ODEuNTQuODAgICAgRVNUQUJMSVNIRUQKZmZmZmZmMDAwNThiYzc1MCB0Y3A0ICAgICAgIDAg
 ICAgICAwIDg5LjIwOS44MS41NC44MCAgICA4OS4yMDkuODEuNTQuMTY2MTIgVElNRV9XQUlU
 CmZmZmZmZjAwYzliM2UzNzAgdGNwNCAgICAgICAwICAgICAgMCAxMC4wLjAuMS4zMTI4ICAg
 ICAgMTAuMC4wLjEwLjIzNzUgICAgIEVTVEFCTElTSEVECmZmZmZmZjAwNGZhYWQwMDAgdGNw
 NCAgICAgICAwICAgIDY1NyAxMC4wLjAuMS4zMTI4ICAgICAgMTAuMC4wLjEwLjIzNzQgICAg
 IEVTVEFCTElTSEVECmZmZmZmZjAxMjUyNWRhMjAgdGNwNCAgICAgICAwICAgICAgMCA4OS4y
 MDkuODEuNTQuODAgICAgODkuMjA5LjgxLjU0LjE2NjExIFRJTUVfV0FJVApmZmZmZmYwMTI1
 MjVkNWU4IHRjcDQgICAgICAgMCAgICAgIDAgMTAuMC4wLjEuMzEyOCAgICAgIDEwLjAuMC4x
 MC4yMzczICAgICBUSU1FX1dBSVQKZmZmZmZmMDEyNTEwMGE1MCB0Y3A0ICAgICAgIDAgICAg
 ICAwIDEwLjAuMC4xLjMxMjggICAgICAxMC4wLjAuMTAuMjM3MiAgICAgRVNUQUJMSVNIRUQK
 ZmZmZmZmMDEyNTEzNTZlMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC44MCAg
 ICA4OS4yMDkuODEuNTQuMTY2MTAgRklOX1dBSVRfMgpmZmZmZmYwMTI1MTFiYTUwIHRjcDQg
 ICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NjEwIDg5LjIwOS44MS41NC44MCAgICBD
 TE9TRV9XQUlUCmZmZmZmZjAxMjUyNmJhYjAgdGNwNCAgICAgICAwICAgICAgMCAxMC4wLjAu
 MS4zMTI4ICAgICAgMTAuMC4wLjEwLjIzNzEgICAgIFRJTUVfV0FJVApmZmZmZmYwMTI0YjI1
 YTUwIHRjcDQgICAgICA2OCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDk1LjEzMy4yMTQu
 MjA4LjQ5NiBFU1RBQkxJU0hFRApmZmZmZmYwMDU1Y2UyYTUwIHRjcDQgICAgICA2OCAgICAg
 IDAgODkuMjA5LjgxLjU0LjY5MzMgIDk1LjEzNC4yMTcuMTAwLjI0OSBFU1RBQkxJU0hFRApm
 ZmZmZmYwMTI1MTlhYTUwIHRjcDQgICAgICA2OCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMg
 IDk0LjI2LjE2OS42Ny41MzYxOSBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MjU1YWIwIHRjcDQg
 ICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjgwICAgIDg5LjIwOS44MS41NC4xNjYwOSBU
 SU1FX1dBSVQKZmZmZmZmMDEyNTI2YzVlOCB0Y3A0ICAgICAgIDAgICAgICAwIDEwLjAuMC4x
 LjMxMjggICAgICAxMC4wLjAuMTAuMjM2OSAgICAgVElNRV9XQUlUCmZmZmZmZjAxMjUyNjI1
 ZTggdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAgODQuMjQwLjI1LjE2
 OS4yMDA0IFRJTUVfV0FJVApmZmZmZmYwMDA1YWQ2NDM4IHRjcDQgICAgICAgMCAgICAgIDAg
 MTAuMC4wLjEuMTY2MDggICAgIDEwLjAuMC4xLjgwICAgICAgICBUSU1FX1dBSVQKZmZmZmZm
 MDEyNTI2MmI4OCB0Y3A0ICAgICAgIDAgICAgICAwIDEyNy4wLjAuMS4xNjYwNyAgICAxMjcu
 MC4wLjEuMzMwNiAgICAgVElNRV9XQUlUCmZmZmZmZjAwNGZkNjExZjggdGNwNCAgICAgICAw
 ICAgICAgMCAxMjcuMC4wLjEuMTY2MDYgICAgMTI3LjAuMC4xLjMzMDYgICAgIFRJTUVfV0FJ
 VApmZmZmZmYwMTI1MjU1OTAwIHRjcDQgICAgICAgMCAgICAgIDAgMTI3LjAuMC4xLjE2NjA1
 ICAgIDEyNy4wLjAuMS41MyAgICAgICBUSU1FX1dBSVQKZmZmZmZmMDEyNTI1NTFiMCB0Y3A0
 ICAgICAgIDAgICAgICAwIDEyNy4wLjAuMS4xNjYwNCAgICAxMjcuMC4wLjEuMjEgICAgICAg
 VElNRV9XQUlUCmZmZmZmZjAxMjUyNmJkODAgdGNwNCAgICAgICAwICAgICAgMCAxMC4wLjAu
 MS4xNjYwMyAgICAgMTAuMC4wLjEuMzEyOCAgICAgIFRJTUVfV0FJVApmZmZmZmYwMTI1MjQy
 YTIwIHRjcDQgICAgICAgMCAgICAgIDAgMTI3LjAuMC4xLjE2NjAyICAgIDEyNy4wLjAuMS4y
 MiAgICAgICBUSU1FX1dBSVQKZmZmZmZmMDEyNTI1NWJkMCB0Y3A0ICAgICAgIDAgICAgICAw
 IDg5LjIwOS44MS41NC42OTMzICA3OC4xNTIuMTg4LjIyLjQzMjQgVElNRV9XQUlUCmZmZmZm
 ZjAxMjUyNzQwZDggdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAgMjE3
 LjE1LjE5OS41OC42NDEwIFRJTUVfV0FJVApmZmZmZmYwMTI1Mjc0YjQwIHRjcDQgICAgICAg
 MCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDE4OC4xODYuMjEuMjA5LjM5MyBUSU1FX1dB
 SVQKZmZmZmZmMDBhNzVkZmFmOCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42
 OTMzICA3Ny4xMjMuOTYuMzguNDM4OSAgVElNRV9XQUlUCmZmZmZmZjAxMjUyNjIxNjggdGNw
 NCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAgMjE3LjE1LjE5OS41OC42MDE3
 IFRJTUVfV0FJVApmZmZmZmYwMTI1MjQyNDM4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5
 LjgxLjU0LjY5MzMgIDgwLjY2LjI0Mi4xMDkuMjA3NyBUSU1FX1dBSVQKZmZmZmZmMDEyNTI2
 YzgyOCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42OTMzICA4OS4yMDkuODEu
 NTQuMTY2MDEgVElNRV9XQUlUCmZmZmZmZjAwNGZlYjdhNTAgdGNwNCAgICAgICAwICAgICAg
 MCA4OS4yMDkuODEuNTQuNjkzMyAgODcuMTE5LjIzNS4yMzAuMTU5IEVTVEFCTElTSEVECmZm
 ZmZmZjAwYTdlNzAzNzAgdGNwNCAgICAgICAwICAgIDMzOSA4OS4yMDkuODEuNTQuMTY2MDAg
 MTk1LjgyLjE0Ni4xMjAuODAgIEVTVEFCTElTSEVECmZmZmZmZjAxMjUyNWRjNjAgdGNwNCAg
 ICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAgOTUuNTMuMTQ0LjExMy4xMTYwIFRJ
 TUVfV0FJVApmZmZmZmYwMDRmZDYxOWQ4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5Ljgx
 LjU0LjY5MzMgIDk0LjI2LjE2OS42Ny41Mjg5NCBUSU1FX1dBSVQKZmZmZmZmMDAwNThiYjlk
 OCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42OTMzICA5NS4xMzQuMjE3LjEw
 MC4yMzYgVElNRV9XQUlUCmZmZmZmZjAxMjUyZjMzMTggdGNwNCAgICAgICAwICAgICAgMCA4
 OS4yMDkuODEuNTQuNjkzMyAgODkuMjM1LjIxNS4yMjIuMzQ1IFRJTUVfV0FJVApmZmZmZmYw
 MTI1MjU1Y2YwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDIxNy4x
 NS4xOTkuNTguNjI5NiBUSU1FX1dBSVQKZmZmZmZmMDEyNTI2YzQzOCB0Y3A0ICAgICAgIDAg
 ICAgICAwIDg5LjIwOS44MS41NC42OTMzICA3OC4xNTIuMTg4LjIyLjQxOTMgVElNRV9XQUlU
 CmZmZmZmZjAwNGZkNjE0ODAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkz
 MyAgNzcuMTIzLjk2LjM4LjQzMDcgIFRJTUVfV0FJVApmZmZmZmYwMTI1MjU1MDkwIHRjcDQg
 ICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDE4OC4xODYuMjEuMjA5LjM3OCBU
 SU1FX1dBSVQKZmZmZmZmMDEyNTI1ZDMxOCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44
 MS41NC42OTMzICAyMTcuMTUuMTk5LjU4LjU5NTIgVElNRV9XQUlUCmZmZmZmZjAxMjUyNzUw
 NDggdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY1OTkgMTk1LjgyLjE0Ni4x
 MjAuODAgIFRJTUVfV0FJVApmZmZmZmYwMTI1Mjc1NzUwIHRjcDQgICAgICAgMCAgICAgIDAg
 MTg4LjExNS4xMjguMy4xNjU5IDkyLjExMi4yMy4xOS4xMjk1MiBUSU1FX1dBSVQKZmZmZmZm
 MDEyNTI2Yjc5OCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjU5NiA5NC4y
 NS4yMTQuODQuMzY4ODEgVElNRV9XQUlUCmZmZmZmZjAxMjUyNjI0MzggdGNwNCAgICAgICAw
 ICAgICAgMCA4OS4yMDkuODEuNTQuMTY1OTQgODYuNjIuMTA5LjgyLjE3MzE0IFRJTUVfV0FJ
 VApmZmZmZmYwMTI1MWIyMDAwIHRjcDQgICAgICAgMCAgICAgNjggODkuMjA5LjgxLjU0LjE2
 NTkyIDg1LjIzMi4xMjUuMjEuMzY5NiBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MjVkNTU4IHRj
 cDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NTkxIDg5LjI1Mi4zNi4xNTAuNTMz
 NyBUSU1FX1dBSVQKZmZmZmZmMDEyNTJmM2M2MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIw
 OS44MS41NC4xNjU5MCA3OS4xNzMuODUuMTI1LjM0MDUgVElNRV9XQUlUCmZmZmZmZjAwMDU4
 YmMzYTggdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY1ODkgMjEyLjk4LjE5
 MS4yMzAuMjkyIFRJTUVfV0FJVApmZmZmZmYwMGE3NWRmM2E4IHRjcDQgICAgICAgMCAgICAg
 IDAgMTg4LjExNS4xMjguMy4xNjU4IDgwLjkzLjE4Ni45MC41MDkyNCBUSU1FX1dBSVQKZmZm
 ZmZmMDEyNTExYTZlMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjU4NyA3
 OS4xODEuOS4yOS4yMDg3ICAgU1lOX1NFTlQKZmZmZmZmMDA1NWNlMjM3MCB0Y3A0ICAgICAg
 IDAgICAgICAwIDg5LjIwOS44MS41NC4xNjU4NiA4NS4yNDkuNzIuMTE3LjYyNzkgU1lOX1NF
 TlQKZmZmZmZmMDAwNThiYzE2OCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4x
 NjU4NSA3Ny4zNy4xMzEuMTA0LjU3ODIgVElNRV9XQUlUCmZmZmZmZjAxMjUyNzUwZDggdGNw
 NCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY1ODQgMjQuMTYuMjguOTMuMTI3MjEg
 IFRJTUVfV0FJVApmZmZmZmYwMTI1MmYzNGM4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5
 LjgxLjU0LjE2NTgzIDc5LjExMS4xNjAuODEuNTMxOCBUSU1FX1dBSVQKZmZmZmZmMDA0ZmQz
 MDM3MCB0Y3A0ICAgICAgIDAgICAgICAwIDE4OC4xMTUuMTI4LjMuMTY1OCA4NS4xNDAuNTUu
 MjI5LjIxNzUgU1lOX1NFTlQKZmZmZmZmMDEyNTBlZDAwMCB0Y3A0ICAgICAgIDAgICAgICAw
 IDg5LjIwOS44MS41NC4xNjU4MSA4OC44NC4yMDAuMi4xOTk1NiAgU1lOX1NFTlQKZmZmZmZm
 MDEyNGIyNmE1MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjU4MCA5NS4y
 MjEuNDcuMjA1LjYyODMgU1lOX1NFTlQKZmZmZmZmMDA0ZmQ2MTUxMCB0Y3A0ICAgICAgIDAg
 ICAgICAwIDg5LjIwOS44MS41NC4xNjU3NCA5Mi4yNTUuMjA3LjY5LjQ3NjIgVElNRV9XQUlU
 CmZmZmZmZjAwNGZkNjFkODAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY1
 NzMgOTIuMTI0LjEwNy40My4xMzg1IFRJTUVfV0FJVApmZmZmZmYwMGE3NWRmNzk4IHRjcDQg
 ICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NTcyIDc4LjYwLjEwMS4xMzAuNjE0OSBU
 SU1FX1dBSVQKZmZmZmZmMDAwNThiYzA5MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44
 MS41NC4xNjU3MSA5NS43Mi40OC4xNDAuNjM3ODAgVElNRV9XQUlUCmZmZmZmZjAwNjQ5ZGUz
 NzAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY1NjggMTk0LjE1MC4xNDAu
 MTc2LjY0IFNZTl9TRU5UCmZmZmZmZjAxMjUwZGZhNTAgdGNwNCAgICAgICAwICAgICAgMCA4
 OS4yMDkuODEuNTQuMTY1NjYgOTMuMTg1LjE4NS4xMC4xOTA4IFNZTl9TRU5UCmZmZmZmZjAx
 MjUxYzM2ZTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY1NjUgMTk1LjE4
 OS44MC41Mi40OTMxIFNZTl9TRU5UCmZmZmZmZjAxMjUxMWYzNzAgdGNwNCAgICAgICAwICAg
 ICAgMCA4OS4yMDkuODEuNTQuMTY1NjQgODIuMTkzLjk3LjE0NS40MjI3IFNZTl9TRU5UCmZm
 ZmZmZjAxMjUyNzU3ZTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY1NjMg
 OTQuMTg4LjQ5LjE4My41MTQxIFRJTUVfV0FJVApmZmZmZmYwMDYzZGU1NmUwIHRjcDQgICAg
 ICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NTYyIDkwLjE5MC4yOS40My4xMTMgICBTWU5f
 U0VOVApmZmZmZmYwMTI1MTZmNmUwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0
 LjE2NTU5IDg1LjExMy4xNTguNTcuNTU1NSBTWU5fU0VOVApmZmZmZmYwMTUyNDBhNmUwIHRj
 cDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NTU4IDk0LjQxLjI4LjIxMC4xODU0
 MyBTWU5fU0VOVApmZmZmZmYwMDRmZDkzMDAwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5
 LjgxLjU0LjE2NTU3IDIxMi41NS42Ni4xMTEuNTkxNiBTWU5fU0VOVApmZmZmZmYwMTI1MjVk
 OTkwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NTU1IDc3LjI0Ny4xNjcu
 MjQxLjMwMyBUSU1FX1dBSVQKZmZmZmZmMDA0Yjk0ZDZlMCB0Y3A0ICAgICAgIDAgICAgICAw
 IDg5LjIwOS44MS41NC4xNjU1MCA5MS4xMjIuNDYuNDcuNDAyMjQgU1lOX1NFTlQKZmZmZmZm
 MDA0ZmQ2MWI4OCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjU0OSA3OS4x
 NjUuMjE3LjI0LjM4MzYgVElNRV9XQUlUCmZmZmZmZjAxMjUyNzQ0YzggdGNwNCAgICAgICAw
 ICAgICAgMCAxODguMTE1LjEyOC4zLjE2NTQgNzguMTA3LjIzNy4xNDYuMzA0IFRJTUVfV0FJ
 VApmZmZmZmYwMTI1MjVkMjQwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5
 MzMgIDg5LjIwOS44MS41NC4xNjU0NiBUSU1FX1dBSVQKZmZmZmZmMDA0ZmQ3YzM3MCB0Y3A0
 ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjU0NyA3OS4xOTQuODkuMjE5LjE5Nzcg
 U1lOX1NFTlQKZmZmZmZmMDEyNGIyMzZlMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44
 MS41NC4xNjU0NSAyMTIuNDUuMTUuMi4yMjA5NSAgU1lOX1NFTlQKZmZmZmZmMDAwNWFkNjNh
 OCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjU0MiA5NS4xMDQuNzIuODIu
 NDA5NzIgVElNRV9XQUlUCmZmZmZmZjAwMDU4YmM0ODAgdGNwNCAgICAgICAwICAgICAgMCA4
 OS4yMDkuODEuNTQuMTY1NDAgNzkuMTY0LjkxLjE2OC40NTQ5IFRJTUVfV0FJVApmZmZmZmYw
 MGE3NWRmZDM4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NTM5IDg1LjE3
 NC4yMC4xNTAuNTM1MiBUSU1FX1dBSVQKZmZmZmZmMDE3YmQ0NjZlMCB0Y3A0ICAgICAgIDAg
 ICAgICAwIDg5LjIwOS44MS41NC4xNjUzNyA5NC4yNS44LjIyMi4yNzAyNyAgU1lOX1NFTlQK
 ZmZmZmZmMDEyNTFiOTM3MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjUz
 NiA3OS4xMjAuMTIwLjEzMi40OTYgU1lOX1NFTlQKZmZmZmZmMDEyNTE5MDM3MCB0Y3A0ICAg
 ICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjUzNCA5My4xNTMuMTU5LjE3Mi4yNTIgU1lO
 X1NFTlQKZmZmZmZmMDEyNTEyYjM3MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41
 NC4xNjUzMyA4Ni42Mi4xMDUuMTcuMzgwNDAgU1lOX1NFTlQKZmZmZmZmMDA0ZmQ3YzAwMCB0
 Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjUzMSA4OS4xNjkuMTExLjEwNS4x
 NjEgU1lOX1NFTlQKZmZmZmZmMDAwNThiYjNmMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIw
 OS44MS41NC4xNjUzMCAyMTMuMTU0LjE5Mi4xMDYuNDcgVElNRV9XQUlUCmZmZmZmZjAxMjZi
 ZWZhNTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY1MjggMTkzLjExMS4y
 NDYuMjguODAgIEVTVEFCTElTSEVECmZmZmZmZjAwYTc1ZGYwZDggdGNwNCAgICAgICAwICAg
 ICAgMCA4OS4yMDkuODEuNTQuMTY1MjcgODEuMjEuMjQ3LjEwOS4zMzM2IFRJTUVfV0FJVApm
 ZmZmZmYwMTI1MmYzMjg4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NTI2
 IDYyLjEyMi43MC42LjYzNzg5ICBUSU1FX1dBSVQKZmZmZmZmMDEyNTE1YTAwMCB0Y3A0ICAg
 ICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjUyNSA5NS41Mi4xMTUuODQuMjI2NjYgU1lO
 X1NFTlQKZmZmZmZmMDEyNTBjN2E1MCB0Y3A0ICAgICAgIDAgICAgICAwIDE4OC4xMTUuMTI4
 LjMuMTY1MiA4NS4xNDAuNjUuMjQzLjE4MDQgTEFTVF9BQ0sKZmZmZmZmMDEyNTI2Mjc5OCB0
 Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjUyMiA5NS4yNS43NS4xNTMuMTAx
 MDIgVElNRV9XQUlUCmZmZmZmZjAxNTI0MDkzNzAgdGNwNCAgICAgICAwICAgICAgMCA4OS4y
 MDkuODEuNTQuMTY1MjAgNzcuMjM5LjIzOS4xNDAuMTc1IFNZTl9TRU5UCmZmZmZmZjAwYTdl
 NmUzNzAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY1MTkgNzkuMTM5LjE1
 OC4xNTAuNTU0IFNZTl9TRU5UCmZmZmZmZjAwNGZkN2QwMDAgdGNwNCAgICAgICAwICAgICAg
 MCA4OS4yMDkuODEuNTQuMTY1MTQgOTQuMjUuNzIuMTExLjI2NjE2IFNZTl9TRU5UCmZmZmZm
 ZjAxMjUwZDczNzAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY1MTMgOTUu
 MTMzLjc4LjE4Mi4yOTA1IFNZTl9TRU5UCmZmZmZmZjAwMDU4YmMwMDAgdGNwNCAgICAgICAw
 ICAgICAgMCA4OS4yMDkuODEuNTQuMTY1MTIgNzguOTQuOTMuMTQzLjEzMzQ0IFRJTUVfV0FJ
 VApmZmZmZmYwMGJiNWIxYTUwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2
 NTEwIDk0LjE5OC4wLjEwLjU0NDU2ICBTWU5fU0VOVApmZmZmZmYwMTI1MTg4MDAwIHRjcDQg
 ICAgICAgMCAgICAgIDAgMTg4LjExNS4xMjguMy4xNjUwIDc4LjM3LjExNC4yNDEuNjM4MyBT
 WU5fU0VOVApmZmZmZmYwMDA1YWQ2MTIwIHRjcDQgICAgICAgMCAgICAgIDAgMTg4LjExNS4x
 MjguMy4xNjUwIDg5LjE2My4xMTQuMTQzLjY4OCBUSU1FX1dBSVQKZmZmZmZmMDE4ODRkZjAw
 MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjUwNyA4Mi4xOTMuOTcuODEu
 NDE3NTMgU1lOX1NFTlQKZmZmZmZmMDEyNTE3YzZlMCB0Y3A0ICAgICA0MzMgICAgMTE0IDE4
 OC4xMTUuMTI4LjMuMTY1MCA3OC4zNi4xNC4xMDAuNTE0MTMgRVNUQUJMSVNIRUQKZmZmZmZm
 MDBhNzVkZjZjMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjUwNCA5Mi4x
 MTUuMzUuNDAuMTE4MTEgVElNRV9XQUlUCmZmZmZmZjAwMmMxM2IzNzAgdGNwNCAgICAgICAw
 ICAgICAgMCA4OS4yMDkuODEuNTQuMTY1MDMgODkuMTkxLjEwNi4xOTQuMTg1IFNZTl9TRU5U
 CmZmZmZmZjAwNjIxNzYzNzAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY1
 MDIgOTQuMTc4LjY1Ljg5LjE3MDQ5IFNZTl9TRU5UCmZmZmZmZjAxMjUyNjIwZDggdGNwNCAg
 ICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY1MDEgODkuMTEyLjQ5LjE2NS4yOTUwIFRJ
 TUVfV0FJVApmZmZmZmYwMTI1MjZiY2YwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5Ljgx
 LjU0LjE2NTAwIDc3LjIzNi4zMi40MS4zNjk0NyBUSU1FX1dBSVQKZmZmZmZmMDBiNTA1MTM3
 MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjQ5OSA4Mi4xOTMuOTcuMTM5
 LjYxOTcgU1lOX1NFTlQKZmZmZmZmMDEyNTE2YTAwMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5
 LjIwOS44MS41NC4xNjQ5OCA2Mi4xODIuMTA4LjYuNTgzNjAgU1lOX1NFTlQKZmZmZmZmMDEy
 NTFhYTZlMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjQ5NCA5MC4xOTEu
 MTc3LjE1MS41NTAgU1lOX1NFTlQKZmZmZmZmMDE1MDllMzZlMCB0Y3A0ICAgICAgIDAgICAg
 ICAwIDg5LjIwOS44MS41NC4xNjQ5MyA5MS4yMDIuMTExLjMxLjU0MTggU1lOX1NFTlQKZmZm
 ZmZmMDEyNTI3NTUxMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjQ5MCAx
 OTUuMTg5LjgyLjEyOC4xNTEgVElNRV9XQUlUCmZmZmZmZjAwNWIxOTA2ZTAgdGNwNCAgICAg
 ICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY0ODkgODkuMjIyLjE1MC40Mi4xMjEyIFNZTl9T
 RU5UCmZmZmZmZjAwYTc1ZGYyZDAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQu
 MTY0ODggODUuMTcuMTM4LjEzNS41MTQxIFRJTUVfV0FJVApmZmZmZmYwMTI1MGQ0MDAwIHRj
 cDQgICAgICAgMCAgICAgIDAgMTg4LjExNS4xMjguMy4xNjQ4IDc4LjM2LjE3OC4xNTEuMjMy
 MSBTWU5fU0VOVApmZmZmZmYwMTI1MjU1ZDM4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5
 LjgxLjU0LjE2NDg2IDg1LjY0LjI0LjE0MC4zMDg3MSBUSU1FX1dBSVQKZmZmZmZmMDA0NGFh
 NTZlMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjQ4NSAxOTUuOTEuMjMx
 LjEuNDcwNzggU1lOX1NFTlQKZmZmZmZmMDAwNWFkNjQ4MCB0Y3A0ICAgICAgIDAgICAgICAw
 IDg5LjIwOS44MS41NC4xNjQ4MiA3Ny44Ny4zOC4xMTkuNTY3MjcgVElNRV9XQUlUCmZmZmZm
 ZjAxMjUyNjI4YjggdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY0ODEgNzku
 MTA0LjE5NS4xODguNTYxIFRJTUVfV0FJVApmZmZmZmYwMTI1MTNlMzcwIHRjcDQgICAgICAg
 MCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NDgwIDk1LjEzNC44Ny4xMDEuMzg1MCBTWU5fU0VO
 VApmZmZmZmYwMTI1MGRjMDAwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2
 NDc4IDE4OC4xMzQuMzIuMjQ4LjYxNCBTWU5fU0VOVApmZmZmZmYwMTI1MjZjMTIwIHRjcDQg
 ICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NDc2IDYyLjE0OC4xMjguMTQwLjM3OCBU
 SU1FX1dBSVQKZmZmZmZmMDEyNTI3NGI4OCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44
 MS41NC42OTMzICA4OS4yMDkuODEuNTQuMTY0NzQgVElNRV9XQUlUCmZmZmZmZjAxMjUyNWQ2
 YzAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY0NzUgODcuMjUwLjE5OS42
 My40MjczIFRJTUVfV0FJVApmZmZmZmYwMDRmZDYxMzE4IHRjcDQgICAgICAgMCAgICAgIDAg
 ODkuMjA5LjgxLjU0LjE2NDcyIDk1LjM3LjE1Ny4xNTkuMjM3MSBUSU1FX1dBSVQKZmZmZmZm
 MDA0ZmQ2MTBkOCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjQ3MSA5My4x
 NTcuMTguMTM4LjkwMDAgVElNRV9XQUlUCmZmZmZmZjAxMjUyNjI1MTAgdGNwNCAgICAgICAw
 ICAgICAgMCA4OS4yMDkuODEuNTQuMTY0NzAgODMuMjE5LjEzNi4xMjYuMTQwIFRJTUVfV0FJ
 VApmZmZmZmYwMDY0ZjczMDAwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2
 NDY5IDg1LjExMy4xMzkuMTcuNTU1NSBTWU5fU0VOVApmZmZmZmYwMTI1MGVjYTUwIHRjcDQg
 ICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NDY4IDE4OC4xMzQuMzIuMjQ1LjQ2NSBT
 WU5fU0VOVApmZmZmZmYwMTI1MGRjNmUwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5Ljgx
 LjU0LjE2NDY3IDc5LjEyMC4xMjEuMTQzLjIyMiBTWU5fU0VOVApmZmZmZmYwMTI1MjVkMDQ4
 IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NDY2IDE4OC4xNjMuNDQuMjI2
 LjY1NiBUSU1FX1dBSVQKZmZmZmZmMDE1OGQxMDAwMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5
 LjIwOS44MS41NC4xNjQ2NSA5NS4zMC40My4xMzcuNDc3OTQgU1lOX1NFTlQKZmZmZmZmMDEy
 NTI0MmQ4MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjQ2MiA5MS4yMDIu
 MTYwLjIxMS40MzggVElNRV9XQUlUCmZmZmZmZjAwYTc1ZGY0ODAgdGNwNCAgICAgICAwICAg
 ICAgMCA4OS4yMDkuODEuNTQuMTY0NjEgNzcuMzcuMjQyLjE3My4xMzI4IFRJTUVfV0FJVApm
 ZmZmZmYwMTI1MTg1MzcwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NDYw
 IDg1LjI1NC4yMTYuMTAzLjUxNCBTWU5fU0VOVApmZmZmZmYwMDFmOGQzNmUwIHRjcDQgICAg
 ICAgMCAgICAgIDAgMTg4LjExNS4xMjguMy4xNjQ1IDkyLjExMi4xOTEuNDMuNjMyNyBTWU5f
 U0VOVApmZmZmZmYwMTI1Mjc0NWEwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0
 LjE2NDU3IDg5LjIyMi4xNTUuNTEuNTY0NyBUSU1FX1dBSVQKZmZmZmZmMDEyNTI3NDYzMCB0
 Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjQ1NiA4OS4yMC4xMjkuMzQuMTAw
 MDEgVElNRV9XQUlUCmZmZmZmZjAwYjJjNjVhNTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4y
 MDkuODEuNTQuMTY0NTQgMTk1LjIxOC4xOTcuMTYuMjg2IFNZTl9TRU5UCmZmZmZmZjAxMjUy
 NmM0ODAgdGNwNCAgICAgICAwICAgICAgMCAxODguMTE1LjEyOC4zLjE2NDUgNzguMTA2LjEx
 MS4xODUuNDU0IFRJTUVfV0FJVApmZmZmZmYwMTcyNjU2MDAwIHRjcDQgICAgICAgMCAgICAg
 IDAgMTg4LjExNS4xMjguMy4xNjQ1IDkxLjc3LjguMTAyLjM1NjkxICBTWU5fU0VOVApmZmZm
 ZmYwMTI1MjU1Y2E4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NDUxIDIx
 My43OS4xMTAuMjE4LjQ1NSBUSU1FX1dBSVQKZmZmZmZmMDBkMWI3NmE1MCB0Y3A0ICAgICAg
 IDAgICAgICAwIDg5LjIwOS44MS41NC4xNjQ0OSA2Mi4yMjAuMzMuOTAuMzM0NjAgU1lOX1NF
 TlQKZmZmZmZmMDAwNThiYjA5MCB0Y3A0ICAgICAgIDAgICAgICAwIDE4OC4xMTUuMTI4LjMu
 MTY0NCAyMTIuMTc4LjI2Ljg2LjI0NDEgVElNRV9XQUlUCmZmZmZmZjAxMjUwY2ZhNTAgdGNw
 NCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY0NDcgODkuMTc5LjIwMS4xODEuMzg5
 IFNZTl9TRU5UCmZmZmZmZjAxMjUyNmM4YjggdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDku
 ODEuNTQuNjkzMyAgODkuMjA5LjgxLjU0LjE2NDQ1IFRJTUVfV0FJVApmZmZmZmYwMTI1MTFm
 YTUwIHRjcDQgICAgICAgMCAgICAgIDAgMTg4LjExNS4xMjguMy4xNjQ0IDc4LjM3LjYzLjEy
 NS42NDk4NCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MjZjZGM4IHRjcDQgICAgICAgMCAgICAg
 IDAgODkuMjA5LjgxLjU0LjE2NDQzIDE5NS4yMzQuMTEwLjguMjE1NiBUSU1FX1dBSVQKZmZm
 ZmZmMDEyNTBjNzAwMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjQ0MiA5
 Mi4yNDMuMTgxLjE2My4xMjMgU1lOX1NFTlQKZmZmZmZmMDEyNTE0N2E1MCB0Y3A0ICAgICAg
 IDAgICAgICAwIDg5LjIwOS44MS41NC4xNjQ0MSA5NS4yNi4zOS4yMDUuMTg1NDYgU1lOX1NF
 TlQKZmZmZmZmMDEyNTI1NTgyOCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4x
 NjQ0MCA3Ny4zNy4yMDQuOC41OTU2MCAgVElNRV9XQUlUCmZmZmZmZjAxMjUyNWQ2NzggdGNw
 NCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY0MzkgOTQuNDEuMzYuODQuMTE3MzAg
 IFRJTUVfV0FJVApmZmZmZmYwMTI1MTUyMDAwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5
 LjgxLjU0LjE2NDM4IDk0LjE0My4yNDAuMjA1LjU0NiBTWU5fU0VOVApmZmZmZmYwMTI1MjZi
 NTU4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NDM3IDg3LjIyNC4yMzku
 MzguNTc5NiBUSU1FX1dBSVQKZmZmZmZmMDAwNThiYjc1MCB0Y3A0ICAgICAgIDAgICAgICAw
 IDg5LjIwOS44MS41NC4xNjQzNiAyMTcuMjcuMTI5LjMxLjEwNzIgVElNRV9XQUlUCmZmZmZm
 ZjAxMjUxYzQ2ZTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY0MzUgOTUu
 MzIuMjkuMjIzLjQ2MzI2IFNZTl9TRU5UCmZmZmZmZjAxMjUxZTAwMDAgdGNwNCAgICAgICAw
 ICAgICAgMCA4OS4yMDkuODEuNTQuMTY0MzQgMjE3LjExNy4xMTIuMTUyLjE5IFNZTl9TRU5U
 CmZmZmZmZjAxMjUyNzU3MDggdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY0
 MzMgMTk1LjUuMTUyLjEzNy40MjQyIFRJTUVfV0FJVApmZmZmZmYwMTI1MTg1NmUwIHRjcDQg
 ICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NDMyIDE5NC4xODcuMjA0LjU1LjQ0MiBT
 WU5fU0VOVApmZmZmZmYwMTI1MGNlMDAwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5Ljgx
 LjU0LjE2NDMxIDkxLjIxMC4xNTYuMTMuMzg2MiBTWU5fU0VOVApmZmZmZmYwMTI1MjZjMDkw
 IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NDI5IDkzLjgxLjEwMC4xLjIz
 NDU2ICBUSU1FX1dBSVQKZmZmZmZmMDAwNThiY2FmOCB0Y3A0ICAgICAgIDAgICAgICAwIDg5
 LjIwOS44MS41NC4xNjQyOCA4Ni42Mi4xMDQuMjI4LjMwODUgVElNRV9XQUlUCmZmZmZmZjAw
 NDE5MGIzNzAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY0MjcgOTUuMjgu
 MTkzLjEzMy4yMzI3IFNZTl9TRU5UCmZmZmZmZjAxNThkMTFhNTAgdGNwNCAgICAgICAwICAg
 ICAgMCA4OS4yMDkuODEuNTQuMTY0MjYgMjEyLjkyLjE1My4xNTQuNDQzIFNZTl9TRU5UCmZm
 ZmZmZjAxMjUxOTBhNTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY0MjUg
 OTUuMzIuODUuNzMuMTY4NDYgIFNZTl9TRU5UCmZmZmZmZjAxMjUwZDEwMDAgdGNwNCAgICAg
 ICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY0MjQgMjEyLjE2LjE5LjI0Mi4yNDg1IFNZTl9T
 RU5UCmZmZmZmZjAxMjUyNjI2YzAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQu
 MTY0MjMgOTMuMTAwLjE4OS41Mi4zNjgxIFRJTUVfV0FJVApmZmZmZmYwMTI1MTY5MzcwIHRj
 cDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NDIyIDIxMy4yMS4zNy4xMzMuMTk4
 OCBTWU5fU0VOVApmZmZmZmYwMTI1MjU1OGI4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5
 LjgxLjU0LjE2NDIxIDc5LjExMS40MS42My4xNjQ5NyBUSU1FX1dBSVQKZmZmZmZmMDAwNWFk
 Njk5MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42OTMzICA4OS4yMDkuODEu
 NTQuMTY0MjAgVElNRV9XQUlUCmZmZmZmZjAxMjUyNWQzYTggdGNwNCAgICAgICAwICAgICAg
 MCA4OS4yMDkuODEuNTQuMTY0MTkgOTUuMTYxLjkuNS41NTAwNiAgIFRJTUVfV0FJVApmZmZm
 ZmYwMTI1MjU1Mjg4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2NDE1IDkx
 LjEyNC4yMDMuMTcxLjI4MCBUSU1FX1dBSVQKZmZmZmZmMDAxY2Y1ODZlMCB0Y3A0ICAgICAg
 IDAgICAgICAwIDE4OC4xMTUuMTI4LjMuMTY0MSA5Mi4xMTMuMTgwLjE3MC42NDEgU1lOX1NF
 TlQKZmZmZmZmMDEyNTI2YjgyOCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4x
 NjQxMyA4MC4yMzcuNzQuMTcuNTkyNzMgVElNRV9XQUlUCmZmZmZmZjAxMjUwYWUzNzAgdGNw
 NCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY0MTEgOTQuMTc4LjE2Ni4yMDAuNDU5
 IFNZTl9TRU5UCmZmZmZmZjAxMjRiMjUwMDAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDku
 ODEuNTQuMTY0MDggOTEuMjAzLjYwLjIxNy4zMjg5IEZJTl9XQUlUXzIKZmZmZmZmMDBhNzVk
 ZjU1OCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjQwNSA3OS4xMDQuMjE3
 LjEzOS41NjQgVElNRV9XQUlUCmZmZmZmZjAwODBjNjU2ZTAgdGNwNCAgICAgICAwICAgICA2
 OCA4OS4yMDkuODEuNTQuMTY0MDQgODAuODAuMjAyLjE5MC4zMDk5IEVTVEFCTElTSEVECmZm
 ZmZmZjAxMjUyNmJhZjggdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY0MDEg
 ODkuMzEuMTE1LjgzLjY0NjYyIFRJTUVfV0FJVApmZmZmZmYwMTI1MjZiNDM4IHRjcDQgICAg
 ICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2Mzk4IDgwLjI0MC4xMS4yMTIuMjExNSBUSU1F
 X1dBSVQKZmZmZmZmMDEyNTJmM2NhOCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41
 NC4xNjM5NyA4NS4xNzUuODIuNzcuMTgxNTEgVElNRV9XQUlUCmZmZmZmZjAxMjUyNmMxZjgg
 dGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYzOTYgODMuOTkuMjUzLjEyNS41
 ODUyIFRJTUVfV0FJVApmZmZmZmYwMTI1MjU1MWY4IHRjcDQgICAgICAgMCAgICAgIDAgODku
 MjA5LjgxLjU0LjE2Mzk1IDk0LjI0MC4xNzAuMjEuMTg1OSBUSU1FX1dBSVQKZmZmZmZmMDEy
 NTJmMzYzMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjM5NCA5NC4xODAu
 MjQyLjEzMy4xOTggVElNRV9XQUlUCmZmZmZmZjAxMjUyNmI1YTAgdGNwNCAgICAgICAwICAg
 ICAgMCA4OS4yMDkuODEuNTQuMTYzOTMgODkuMjA5LjgyLjk1LjE1OTQzIFRJTUVfV0FJVApm
 ZmZmZmYwMTI1MGNmMDAwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2Mzkx
 IDIxMi45OC4xODMuMTYzLjU4MiBTWU5fU0VOVApmZmZmZmYwMTI1MmYzMmQwIHRjcDQgICAg
 ICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2Mzg4IDk1LjY3LjEzNC43MC4yMjE0OSBUSU1F
 X1dBSVQKZmZmZmZmMDBhNzVkZjc1MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41
 NC4xNjM4NSA4NC40Mi4yNy40NS41MzcxMSAgVElNRV9XQUlUCmZmZmZmZjAwMDU4YmM4Mjgg
 dGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYzODQgOTUuNzIuMTUxLjUzLjE0
 MjYwIFRJTUVfV0FJVApmZmZmZmYwMTI1MjQyOTAwIHRjcDQgICAgICAgMCAgICAgIDAgODku
 MjA5LjgxLjU0LjE2MzgzIDkyLjExNS4xMC4xODguMzQ4NSBUSU1FX1dBSVQKZmZmZmZmMDEy
 NGIyZDAwMCB0Y3A0ICAgICAgIDAgICAgICAwIDE4OC4xMTUuMTI4LjMuMTYzOCA4OS4yMTgu
 MTA0LjExMS4yMjAgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNGIyZTM3MCB0Y3A0ICAgICAgIDAg
 ICAgICAwIDg5LjIwOS44MS41NC4xNjM4MCA5Mi4xMjUuMjI1LjE4Ni4zMDAgU1lOX1NFTlQK
 ZmZmZmZmMDEyNTJmM2FmOCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjM3
 OSA5MS4xOTMuMjU1LjEyMy44ODAgVElNRV9XQUlUCmZmZmZmZjAxMjUyNTUzYTggdGNwNCAg
 ICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYzNzcgOTMuODEuMTg0Ljc0LjUzNjA3IFRJ
 TUVfV0FJVApmZmZmZmYwMDRmZDYxY2YwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5Ljgx
 LjU0LjE2Mzc1IDk1LjE1NC4xMzguMzYuMzc4NSBUSU1FX1dBSVQKZmZmZmZmMDAwNThiY2Mx
 OCB0Y3A0ICAgICAgIDAgICAgICAwIDE4OC4xMTUuMTI4LjMuMTYzNyA3OC4xMDYuMTA3LjI0
 Ny4xMjUgVElNRV9XQUlUCmZmZmZmZjAxMjUyNmNjZjAgdGNwNCAgICAgICAwICAgICAgMCA4
 OS4yMDkuODEuNTQuMTYzNzMgNzkuMTI2LjE1LjgyLjY4ODEgIFRJTUVfV0FJVApmZmZmZmYw
 MTI1Mjc1YzYwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2MzcwIDg3LjIz
 Ni4yNy40Ny4xODgxMCBUSU1FX1dBSVQKZmZmZmZmMDEyNTI2YzcwOCB0Y3A0ICAgICAgIDAg
 ICAgICAwIDg5LjIwOS44MS41NC4xNjM2OSA5NS4yNS4yNDMuMTA3LjQ2NDMgVElNRV9XQUlU
 CmZmZmZmZjAxMjUyNzQ3NTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYz
 NjggOTAuMTU1LjE3My4xNjguMzkyIFRJTUVfV0FJVApmZmZmZmYwMDRmZDYxMDQ4IHRjcDQg
 ICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDg5LjIwOS44MS41NC4xNjM2NiBU
 SU1FX1dBSVQKZmZmZmZmMDAwNThiYjI0MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44
 MS41NC4xNjM2NyA4OS4yMDguODIuMTAxLjExODkgVElNRV9XQUlUCmZmZmZmZjAxMjUyNDI1
 YTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYzNjQgOTUuMTM0LjI0Mi4y
 MDkuNTM0IFRJTUVfV0FJVApmZmZmZmYwMTI1MWNmYTUwIHRjcDQgICAgICAgMCAgICAgIDAg
 ODkuMjA5LjgxLjU0LjE2MzYzIDkxLjE5MC43OS4xMzEuMTMxNiBTWU5fU0VOVApmZmZmZmYw
 MDA1YWQ2NWU4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2MzYyIDk1LjE2
 NS4xMDEuNDguMjk4MCBUSU1FX1dBSVQKZmZmZmZmMDEyNTI3NWI4OCB0Y3A0ICAgICAgIDAg
 ICAgICAwIDg5LjIwOS44MS41NC4xNjM2MCA5NS4yNS4yNDkuOTguNTEwMDAgVElNRV9XQUlU
 CmZmZmZmZjAwNGZkNjE5NDggdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYz
 NTkgOTQuMjcuOTcuMTMuMzgxNDcgIFRJTUVfV0FJVApmZmZmZmYwMTI1MjYyMWIwIHRjcDQg
 ICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2MzU4IDgwLjczLjExLjE3OS4yNzAyMiBU
 SU1FX1dBSVQKZmZmZmZmMDEyNTI2YzE2OCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44
 MS41NC4xNjM1NSAyMTIuMTkyLjEyOC4xMDEuNDAgVElNRV9XQUlUCmZmZmZmZjAxMjUyNTU1
 MTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYzNTQgOTIuNjIuNTIuMjI2
 LjI1NDI1IFRJTUVfV0FJVApmZmZmZmYwMTI1MGRlNmUwIHRjcDQgICAgICAgMCAgICAgIDAg
 ODkuMjA5LjgxLjU0LjE2MzUyIDkxLjEyNC4yMTMuMzUuMTM5NSBTWU5fU0VOVApmZmZmZmYw
 MTI1MjVkZDM4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2MzUxIDk1LjI0
 LjM4LjIzMS41NTM0NyBUSU1FX1dBSVQKZmZmZmZmMDEyNTBjZTZlMCB0Y3A0ICAgICAgIDAg
 ICAgICAwIDg5LjIwOS44MS41NC4xNjM0OCA5Mi4xMDAuMTYwLjE5MC40OTMgU1lOX1NFTlQK
 ZmZmZmZmMDE0NmRjYjZlMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjM0
 NiAxMzguODguMS4yNS4yNzAxICAgU1lOX1NFTlQKZmZmZmZmMDEyNTBkZjM3MCB0Y3A0ICAg
 ICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjM0NCA3OS4xMjAuMTIwLjcwLjIzMTkgU1lO
 X1NFTlQKZmZmZmZmMDEyNTI2YjkwMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41
 NC4xNjM0MyA5MC4xNTAuMjE4LjIyNy41MTQgVElNRV9XQUlUCmZmZmZmZjAxMjUyNTU1YTAg
 dGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAgOTQuMjYuMTY5LjY3LjUy
 MTU3IFRJTUVfV0FJVApmZmZmZmYwMTI1MTNlMDAwIHRjcDQgICAgICAgMCAgICAyMTggODku
 MjA5LjgxLjU0LjY5MzMgIDkwLjE1MS4yMjQuMTY0LjEzMiBFU1RBQkxJU0hFRApmZmZmZmYw
 MTI1MjQyY2YwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDgwLjY2
 LjI0Mi4xMDkuMjA3NCBUSU1FX1dBSVQKZmZmZmZmMDAwNWFkNmM2MCB0Y3A0ICAgICAgIDAg
 ICAgICAwIDg5LjIwOS44MS41NC42OTMzICA5NS4xMzQuMjE3LjEwMC4yMjggVElNRV9XQUlU
 CmZmZmZmZjAxMjUyNzQ1NTggdGNwNCAgICAgICAwICAgICAgMCAxMC4wLjAuMS4xNjM0MiAg
 ICAgMTAuMC4wLjEuODAgICAgICAgIFRJTUVfV0FJVApmZmZmZmYwMTI1MjZiM2YwIHRjcDQg
 ICAgICAgMCAgICAgIDAgMTI3LjAuMC4xLjE2MzQxICAgIDEyNy4wLjAuMS4zMzA2ICAgICBU
 SU1FX1dBSVQKZmZmZmZmMDEyNTI1ZDBkOCB0Y3A0ICAgICAgIDAgICAgICAwIDEyNy4wLjAu
 MS4xNjM0MCAgICAxMjcuMC4wLjEuMzMwNiAgICAgVElNRV9XQUlUCmZmZmZmZjAxMjUyNjIw
 OTAgdGNwNCAgICAgICAwICAgICAgMCAxMjcuMC4wLjEuMTYzMzkgICAgMTI3LjAuMC4xLjUz
 ICAgICAgIFRJTUVfV0FJVApmZmZmZmYwMDRmZDYxMWIwIHRjcDQgICAgICAgMCAgICAgIDAg
 MTI3LjAuMC4xLjE2MzM4ICAgIDEyNy4wLjAuMS4yMSAgICAgICBUSU1FX1dBSVQKZmZmZmZm
 MDAwNThiYmQzOCB0Y3A0ICAgICAgIDAgICAgICAwIDEwLjAuMC4xLjE2MzM3ICAgICAxMC4w
 LjAuMS4zMTI4ICAgICAgVElNRV9XQUlUCmZmZmZmZjAxMjUyNTVjMTggdGNwNCAgICAgICAw
 ICAgICAgMCAxMjcuMC4wLjEuMTYzMzYgICAgMTI3LjAuMC4xLjIyICAgICAgIFRJTUVfV0FJ
 VApmZmZmZmYwMTI1MjRiODI4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5
 MzMgIDg5LjIzNS4yMTUuMjIyLjI5OCBUSU1FX1dBSVQKZmZmZmZmMDAwNWFkNjFmOCB0Y3A0
 ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42OTMzICA3OC4xNTIuMTg4LjIyLjQwNzkg
 VElNRV9XQUlUCmZmZmZmZjAxMjUyNTU3NTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDku
 ODEuNTQuNjkzMyAgMjE3LjE1LjE5OS41OC41NjMwIFRJTUVfV0FJVApmZmZmZmYwMTI1MmYz
 YjQwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDk1LjI0LjE3NS4x
 MTYuMTUwMCBUSU1FX1dBSVQKZmZmZmZmMDEyNTJmMzdlMCB0Y3A0ICAgICAgIDAgICAgICAw
 IDg5LjIwOS44MS41NC42OTMzICA5MS4yMDAuMTM5LjIxNi4zMDQgVElNRV9XQUlUCmZmZmZm
 ZjAwMDVhZDZiNDAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAgNzcu
 MTIzLjk2LjM4LjQyMjIgIFRJTUVfV0FJVApmZmZmZmYwMTI1MjRiOTQ4IHRjcDQgICAgICAg
 MCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDE4OC4xODYuMjEuMjA5LjM2MCBUSU1FX1dB
 SVQKZmZmZmZmMDAwNThiYzU1OCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42
 OTMzICAyMTcuMTUuMTk5LjU4LjYzMzUgVElNRV9XQUlUCmZmZmZmZjAwNGZkNjE3ZTAgdGNw
 NCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAgOTUuMTM0LjIxNy4xMDAuMjE1
 IFRJTUVfV0FJVApmZmZmZmYwMTI1MjZiNzA4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5
 LjgxLjU0LjY5MzMgIDg5LjIzNS4yMTUuMjIyLjI1NyBUSU1FX1dBSVQKZmZmZmZmMDAwNWFk
 NjUxMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42OTMzICA5NC4yNi4xNjku
 NjcuNTA4OTggVElNRV9XQUlUCmZmZmZmZjAwMDU4YmMzZjAgdGNwNCAgICAgICAwICAgICAg
 MCA4OS4yMDkuODEuNTQuNjkzMyAgMjE3LjE1LjE5OS41OC41NDg1IFRJTUVfV0FJVApmZmZm
 ZmYwMTI1MjVkOTQ4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDc4
 LjE1Mi4xODguMjIuMzk2NSBUSU1FX1dBSVQKZmZmZmZmMDEyNTBhZmE1MCB0Y3A0ICAgICAg
 IDAgIDQ0NTQ1IDg5LjIwOS44MS41NC42OTMzICA5My4xNzUuMjA1LjQ1LjMxMzYgRVNUQUJM
 SVNIRUQKZmZmZmZmMDEyNTI2YmI4OCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41
 NC42OTMzICAxODguMTg2LjIxLjIwOS4zNDQgVElNRV9XQUlUCmZmZmZmZjAxMjUyNDIwMDAg
 dGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAgNzcuMTIzLjk2LjM4LjQx
 NDIgIFRJTUVfV0FJVApmZmZmZmYwMTI1MjZjYjg4IHRjcDQgICAgICAgMCAgICAgIDAgODku
 MjA5LjgxLjU0LjY5MzMgIDIxNy4xNS4xOTkuNTguNjMxNiBUSU1FX1dBSVQKZmZmZmZmMDEy
 NTI2MjlkOCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42OTMzICA5Mi4yNTUu
 ODEuMTg3LjQzNDYgVElNRV9XQUlUCmZmZmZmZjAwNjQ2YTYwMDAgdGNwNCAgICAgIDE3IDEx
 ODUyNCA4OS4yMDkuODEuNTQuNjkzMyAgODEuMjAwLjI0LjE0My4zNDUxIEVTVEFCTElTSEVE
 CmZmZmZmZjAxMjUyNzQxYjAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkz
 MyAgOTQuMjYuMTY5LjY3LjUwMTkyIFRJTUVfV0FJVApmZmZmZmYwMTI1MjVkN2UwIHRjcDQg
 ICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDgwLjY2LjI0Mi4xMDkuMjA2NSBU
 SU1FX1dBSVQKZmZmZmZmMDAwNThiY2QzOCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44
 MS41NC42OTMzICA5NS4xMzQuMjE3LjEwMC4xOTkgVElNRV9XQUlUCmZmZmZmZjAxMjUyNmMz
 NjAgdGNwNCAgICAgICAwICAgICAgMCAxMC4wLjAuMS4xNjMzNSAgICAgMTAuMC4wLjEuODAg
 ICAgICAgIFRJTUVfV0FJVApmZmZmZmYwMTI1MmYzNjc4IHRjcDQgICAgICAgMCAgICAgIDAg
 MTI3LjAuMC4xLjMzMDYgICAgIDEyNy4wLjAuMS4xNjMzNCAgICBUSU1FX1dBSVQKZmZmZmZm
 MDEyNTI2Yjk0OCB0Y3A0ICAgICAgIDAgICAgICAwIDEyNy4wLjAuMS4xNjMzNCAgICAxMjcu
 MC4wLjEuMzMwNiAgICAgVElNRV9XQUlUCmZmZmZmZjAxMjUyNDIzMTggdGNwNCAgICAgICAw
 ICAgICAgMCAxMjcuMC4wLjEuMzMwNiAgICAgMTI3LjAuMC4xLjE2MzMzICAgIFRJTUVfV0FJ
 VApmZmZmZmYwMDRmZDYxYTIwIHRjcDQgICAgICAgMCAgICAgIDAgMTI3LjAuMC4xLjE2MzMz
 ICAgIDEyNy4wLjAuMS4zMzA2ICAgICBUSU1FX1dBSVQKZmZmZmZmMDBhNzVkZjdlMCB0Y3A0
 ICAgICAgIDAgICAgICAwIDEyNy4wLjAuMS4xNjMzMiAgICAxMjcuMC4wLjEuNTMgICAgICAg
 VElNRV9XQUlUCmZmZmZmZjAxMjUyZjM4MjggdGNwNCAgICAgICAwICAgICAgMCAxMjcuMC4w
 LjEuMTYzMzEgICAgMTI3LjAuMC4xLjIxICAgICAgIFRJTUVfV0FJVApmZmZmZmYwMTI1MjQy
 MTIwIHRjcDQgICAgICAgMCAgICAgIDAgMTAuMC4wLjEuMTYzMzAgICAgIDEwLjAuMC4xLjMx
 MjggICAgICBUSU1FX1dBSVQKZmZmZmZmMDEyNTJmMzNhOCB0Y3A0ICAgICAgIDAgICAgICAw
 IDEyNy4wLjAuMS4xNjMyOSAgICAxMjcuMC4wLjEuMjIgICAgICAgVElNRV9XQUlUCmZmZmZm
 ZjAxMjUyNGJkYzggdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAgODku
 MjM1LjIxNS4yMjIuMjEyIFRJTUVfV0FJVApmZmZmZmYwMTI1MmYzMWY4IHRjcDQgICAgICAg
 MCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDIxNy4xNS4xOTkuNTguNjQ0MCBUSU1FX1dB
 SVQKZmZmZmZmMDEyNTI0MmQzOCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42
 OTMzICA5NS4yNC4xMC4yMzkuNTYzOTQgVElNRV9XQUlUCmZmZmZmZjAxMjUyNzQxZjggdGNw
 NCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAgNzguMTUyLjE4OC4yMi4zODQx
 IFRJTUVfV0FJVApmZmZmZmYwMTI1MjZjYTIwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5
 LjgxLjU0LjY5MzMgIDk1LjI0LjEwLjIzOS41NjM4OCBUSU1FX1dBSVQKZmZmZmZmMDAwNThi
 YjUxMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjMyOCA4OS4xODkuMTc2
 LjE3Ny4yMzAgVElNRV9XQUlUCmZmZmZmZjAxMjUyNmNhZjggdGNwNCAgICAgICAwICAgICAg
 MCAxODguMTE1LjEyOC4zLjE2MzIgODUuMTQxLjExNS4yMDguMzIzIFRJTUVfV0FJVApmZmZm
 ZmYwMTRiOThmMzcwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2MzI2IDk0
 LjQxLjIzLjEzNS41OTkxOSBTWU5fU0VOVApmZmZmZmYwMTI1MjU1YzYwIHRjcDQgICAgICAg
 MCAgICAgIDAgODkuMjA5LjgxLjU0LjE2MzI1IDgwLjI1Mi4yNTIuMjIxLjI4MSBUSU1FX1dB
 SVQKZmZmZmZmMDA0ZjM0ODAwMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4x
 NjMyNCA2Mi4zMy4yMzIuMjQ2LjI1ODEgU1lOX1NFTlQKZmZmZmZmMDEyNTE4NjAwMCB0Y3A0
 ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjMyMyA4OS4xOS4xNjAuMjI2LjYyNDYg
 U1lOX1NFTlQKZmZmZmZmMDBhN2U2ZWE1MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44
 MS41NC4xNjMyMSA4OS4yNTEuNjguMTQ3LjQxMzMgU1lOX1NFTlQKZmZmZmZmMDEyNTI0MjQ4
 MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjMyMCA4OS4xMTIuMTExLjEz
 OC4xMTEgVElNRV9XQUlUCmZmZmZmZjAxMjUyNmI3ZTAgdGNwNCAgICAgICAwICAgICAgMCA4
 OS4yMDkuODEuNTQuMTYzMTcgOTUuNzkuMi45LjM1NjQxICAgIFRJTUVfV0FJVApmZmZmZmYw
 MTU4ZDExMDAwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2MzE1IDk1LjEz
 My4xMDMuNTcuMjI3MiBTWU5fU0VOVApmZmZmZmYwMGNhMTNmNmUwIHRjcDQgICAgICAgMCAg
 ICAgIDAgODkuMjA5LjgxLjU0LjE2MzE0IDg4LjIwNS4xODUuMTY5LjU1OCBTWU5fU0VOVApm
 ZmZmZmYwMTI1Mjc1YWIwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2MzEz
 IDkyLjI1NS4xNTIuMjguNTk1MyBUSU1FX1dBSVQKZmZmZmZmMDEzZWFkMjZlMCB0Y3A0ICAg
 ICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjMxMiA4My4xNjcuMTEyLjMyLjI2NzIgU1lO
 X1NFTlQKZmZmZmZmMDEyNTEzYzAwMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41
 NC4xNjMxMSAxOTMuMjI3Ljk3LjMuMjU5ODcgU1lOX1NFTlQKZmZmZmZmMDEyNTEwMDM3MCB0
 Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjMxMCAxODguMTcuMjE2LjMuNTU4
 ODMgU1lOX1NFTlQKZmZmZmZmMDAwNThiYzg3MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIw
 OS44MS41NC4xNjMwOSA5Mi4xMjQuMTYwLjEwNC4yOTEgVElNRV9XQUlUCmZmZmZmZjAwNGZk
 NjE5OTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYzMDggNzkuMTcyLjgy
 LjE4MS4yNzQwIFRJTUVfV0FJVApmZmZmZmYwMTI1MjZiMTY4IHRjcDQgICAgICAgMCAgICAg
 IDAgODkuMjA5LjgxLjU0LjE2MzA3IDkwLjE4OC4zOS4yOS40Mzk0OCBUSU1FX1dBSVQKZmZm
 ZmZmMDAwNThiYjNhOCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjMwNCA4
 OS4xNzkuODEuMzQuNjg5MSAgVElNRV9XQUlUCmZmZmZmZjAxMjUxZjUzNzAgdGNwNCAgICAg
 ICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYzMDMgOTUuMTMzLjE5OS4xNTMuNTAwIFNZTl9T
 RU5UCmZmZmZmZjAwYTc1ZGYwOTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQu
 MTYzMDIgOTUuMTM1LjQxLjUzLjExMzMxIFRJTUVfV0FJVApmZmZmZmYwMGE3NWRmOTQ4IHRj
 cDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2MzAxIDkzLjEzMy4yMDAuMTYwLjYx
 MCBUSU1FX1dBSVQKZmZmZmZmMDAwNWFkNjNmMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIw
 OS44MS41NC4xNjI5OCA4MC43My4xNjEuMjQ1LjYxNTkgVElNRV9XQUlUCmZmZmZmZjAwMDU4
 YmMxYjAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYyOTcgODUuMTc1LjEw
 My4xMzEuNTc0IFRJTUVfV0FJVApmZmZmZmYwMTI1Mjc1ZDM4IHRjcDQgICAgICAgMCAgICAg
 IDAgODkuMjA5LjgxLjU0LjE2Mjk1IDg0LjI0MC41Mi4yMTkuMjU5MiBUSU1FX1dBSVQKZmZm
 ZmZmMDEyNTI2YjNhOCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjI5NCA5
 Mi4xMjcuNjUuMTI4LjI2ODQgVElNRV9XQUlUCmZmZmZmZjAwNGZkNjE0MzggdGNwNCAgICAg
 ICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYyOTMgNzcuNDEuNTkuMTI1LjMyMzU4IFRJTUVf
 V0FJVApmZmZmZmYwMTI1MjQyNmMwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0
 LjE2MjkyIDc3LjY2LjIwOS44Mi40MjAwNyBUSU1FX1dBSVQKZmZmZmZmMDA0ZmFhYzAwMCB0
 Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjI5MSAxODguMTE0LjUuMTU5LjU3
 MjUgU1lOX1NFTlQKZmZmZmZmMDA0ZmQ2MTI0MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIw
 OS44MS41NC4xNjI5MCA3Ny4yMzIuNS4yNDIuMTU2NjAgVElNRV9XQUlUCmZmZmZmZjAwMjcx
 OWRhNTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYyODcgODAuOTIuOTYu
 NDIuMzY5MzUgIFNZTl9TRU5UCmZmZmZmZjAxMjUxOWZhNTAgdGNwNCAgICAgICAwICAgICAg
 MCAxODguMTE1LjEyOC4zLjE2MjggODkuMjE4LjI0Ljg5LjE0MTEwIFNZTl9TRU5UCmZmZmZm
 ZjAxMjUyZjMwOTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYyODQgOTQu
 MTc4LjE3Mi4xMjIuNTUwIFRJTUVfV0FJVApmZmZmZmYwMTI1MjYyOTkwIHRjcDQgICAgICAg
 MCAgICAgIDAgODkuMjA5LjgxLjU0LjE2MjgzIDk1LjE4OC45Mi4wLjUxMDAxICBUSU1FX1dB
 SVQKZmZmZmZmMDEyNTI3NTk5MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4x
 NjI4MiA5NC4xNzguOTIuMjQ5LjU5MTAgVElNRV9XQUlUCmZmZmZmZjAwMDVhZDY4NzAgdGNw
 NCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYyODEgODQuNTIuNDUuNzkuMjI1OTMg
 IFRJTUVfV0FJVApmZmZmZmYwMGE3NWRmNjMwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5
 LjgxLjU0LjY5MzMgIDc3LjEyMy45Ni4zOC40MDU5ICBUSU1FX1dBSVQKZmZmZmZmMDAwNWFk
 NjlkOCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42OTMzICAxODguMTg2LjIx
 LjIwOS4zMjggVElNRV9XQUlUCmZmZmZmZjAxMjUyNGI4YjggdGNwNCAgICAgICAwICAgICAg
 MCA4OS4yMDkuODEuNTQuNjkzMyAgODAuMjMzLjEzNi43NC4xMzcwIFRJTUVfV0FJVApmZmZm
 ZmYwMTI1MjU1ZDgwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDg5
 LjI1Mi4xNS4xNjYuNDY2MyBUSU1FX1dBSVQKZmZmZmZmMDEyNTJmM2JkMCB0Y3A0ICAgICAg
 IDAgICAgICAwIDg5LjIwOS44MS41NC42OTMzICAyMTcuMTUuMTk5LjU4LjUxMzMgVElNRV9X
 QUlUCmZmZmZmZjAwYTc1ZGY4YjggdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQu
 NjkzMyAgOTQuMjYuMTY5LjY3LjQ5NDExIFRJTUVfV0FJVApmZmZmZmYwMGE3NWRmOTkwIHRj
 cDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDgxLjIwMC4yNS4yMDYuMjI4
 NCBUSU1FX1dBSVQKZmZmZmZmMDEyNTI3NDlkOCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIw
 OS44MS41NC42OTMzICAyMTcuMTUuMTk5LjU4LjYyODEgVElNRV9XQUlUCmZmZmZmZjAxMjUy
 ZjNiODggdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAgODAuNjYuMjQy
 LjEwOS4yMDU1IFRJTUVfV0FJVApmZmZmZmYwMGE3NWRmMDAwIHRjcDQgICAgICAgMCAgICAg
 IDAgODkuMjA5LjgxLjU0LjY5MzMgIDk1LjEzNC4yMTcuMTAwLjE4NSBUSU1FX1dBSVQKZmZm
 ZmZmMDEyNTI2YjUxMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42OTMzICA4
 OS4yMzUuMjE1LjIyMi4xNjggVElNRV9XQUlUCmZmZmZmZjAxMjUwZWQzNzAgdGNwNCAgICAg
 ICAwICAzNDc3OCA4OS4yMDkuODEuNTQuNjkzMyAgODkuMTA3LjE5NS4xMTMuMTM3IEVTVEFC
 TElTSEVECmZmZmZmZjAxMjUyNTU1ZTggdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEu
 NTQuNjkzMyAgNzguMTUyLjE4OC4yMi4zNzI4IFRJTUVfV0FJVApmZmZmZmYwMTI1MTMzNmUw
 IHRjcDQgICAgICAgMCAgICAxNjYgODkuMjA5LjgxLjU0LjE2MjgwIDk4LjEwMy4xOTQuMTM2
 LjU2MSBGSU5fV0FJVF8xCmZmZmZmZjAxMjUyNzRjZjAgdGNwNCAgICAgICAwICAgICAgMCA4
 OS4yMDkuODEuNTQuMTYyNzkgOTEuMTI0Ljc4Ljk1LjE5NjUxIFRJTUVfV0FJVApmZmZmZmYw
 MTE3ZThkMzcwIHRjcDQgICAgICAgMCAgMzEzNTMgODkuMjA5LjgxLjU0LjE2Mjc2IDc5LjEy
 Ni40OC4xNjUuNjk2OSBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MmYzMjQwIHRjcDQgICAgICAg
 MCAgICAgIDAgMTg4LjExNS4xMjguMy4xNjI3IDc4LjEwNi44MC4xNDYuMTY2MyBUSU1FX1dB
 SVQKZmZmZmZmMDA0ZmQ2MTU1OCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4x
 NjI3MyA4NC4yNDIuMjU1LjEwOS4yNzMgVElNRV9XQUlUCmZmZmZmZjAxMjUyNjIxMjAgdGNw
 NCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYyNjkgOTIuMjU1LjIxNy40Mi40OTE3
 IFRJTUVfV0FJVApmZmZmZmYwMTI1MjYyZDM4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5
 LjgxLjU0LjE2MjY2IDg4LjIyMi40LjQwLjQ5Mzk3ICBUSU1FX1dBSVQKZmZmZmZmMDEyNTI3
 NDE2OCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42OTMzICA4OS4yMDkuODEu
 NTQuMTYyNjMgVElNRV9XQUlUCmZmZmZmZjAxMjUxNjIzNzAgdGNwNCAgICAgICAwICAgICAg
 MCA4OS4yMDkuODEuNTQuMTYyNjIgODcuMjI4LjkzLjQxLjMzNzczIEVTVEFCTElTSEVECmZm
 ZmZmZjAwNjNkZTVhNTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYyNjEg
 MjEyLjQ1LjE1LjIuMjIwOTUgIFNZTl9TRU5UCmZmZmZmZjAwZDFiNzYzNzAgdGNwNCAgICAg
 ICAwICAgICAgMCAxODguMTE1LjEyOC4zLjE2MjUgNzguMzcuNS4xMzguNTU3NTYgIFNZTl9T
 RU5UCmZmZmZmZjAwMDVhZDZjMTggdGNwNCAgICAgICAwICAgICAgMCAxODguMTE1LjEyOC4z
 LjE2MjUgOTEuNzYuMTExLjE3MS4xNjY1IFRJTUVfV0FJVApmZmZmZmYwMTI1MjQyMWY4IHRj
 cDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2MjQ5IDg4LjgyLjgwLjIxOS41MTgw
 MCBUSU1FX1dBSVQKZmZmZmZmMDEyNTBmNjZlMCB0Y3A0ICAgICAgIDAgIDMyNzgxIDg5LjIw
 OS44MS41NC4xNjI0MyAyMTcuMTIuNjYuMTM5LjQxMjggRVNUQUJMSVNIRUQKZmZmZmZmMDEy
 NTEzNDZlMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjIzOSA5My4xODUu
 MTgwLjE2OS4xMTYgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTE2ZjAwMCB0Y3A0ICAgICAgIDAg
 ICAgICAwIDg5LjIwOS44MS41NC4xNjIzOCAxODguMTM0LjM4LjEwMy4xNTAgU1lOX1NFTlQK
 ZmZmZmZmMDEyNTE0NzM3MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjIz
 NiA4OS4xMDcuMzMuMTkuMTI3OTkgU1lOX1NFTlQKZmZmZmZmMDEyNTFhN2E1MCB0Y3A0ICAg
 ICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjIzNCA5MC4xNTAuMTE2LjIyNC42MzAgU1lO
 X1NFTlQKZmZmZmZmMDEyNTE3ZDM3MCB0Y3A0ICAgICAgIDAgIDM0MTA5IDg5LjIwOS44MS41
 NC4xNjIzMSA5Mi4xMDAuOC4yMTUuNDg2MDIgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTI0Yjc1
 MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjIyOCA3OS4xNzIuNjYuMTQ2
 LjQyNTMgVElNRV9XQUlUCmZmZmZmZjAxMjUxMjA2ZTAgdGNwNCAgICAgICAwICAgICAgMCA4
 OS4yMDkuODEuNTQuMTYyMjUgNzcuNTAuMTguMTg0LjE1MjY2IFNZTl9TRU5UCmZmZmZmZjAx
 MjUyNmM0YzggdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYyMjQgMTk1Ljkz
 LjEyOC4yNDQuNDI1IFRJTUVfV0FJVApmZmZmZmYwMTI1MTdiMDAwIHRjcDQgICAgICAgMCAg
 ICAgIDAgMTg4LjExNS4xMjguMy4xNjIyIDc4LjM3LjE0NC4xNTIuMjg1MCBTWU5fU0VOVApm
 ZmZmZmYwMTI1Mjc1ZGM4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMg
 IDk0LjI2LjE2OS42Ny42NTA5OSBUSU1FX1dBSVQKZmZmZmZmMDBhNzVkZjA0OCB0Y3A0ICAg
 ICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42OTMzICA3Ny4xMjMuOTYuMzguMzk3NCAgVElN
 RV9XQUlUCmZmZmZmZjAxMjUyNzUyZDAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEu
 NTQuNjkzMyAgMTg4LjE4Ni4yMS4yMDkuMzExIFRJTUVfV0FJVApmZmZmZmYwMTI1Mjc1OTAw
 IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDIxNy4xNS4xOTkuNTgu
 NTA3NyBUSU1FX1dBSVQKZmZmZmZmMDEyNTBhZTAwMCB0Y3A0ICAgICAgIDAgIDI5OTAxIDg5
 LjIwOS44MS41NC42OTMzICA4NS4xNzMuMjYuMTcwLjU5NjYgRVNUQUJMSVNIRUQKZmZmZmZm
 MDEyNTBmZjM3MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42OTMzICA4OC4y
 MTUuMTg2LjE1NS4zNTIgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTI2YjA5MCB0Y3A0ICAgICAg
 IDAgICAgICAwIDEwLjAuMC4xLjE2MjIwICAgICAxMC4wLjAuMS44MCAgICAgICAgVElNRV9X
 QUlUCmZmZmZmZjAxMjUyNmJjYTggdGNwNCAgICAgICAwICAgICAgMCAxMjcuMC4wLjEuMTYy
 MTkgICAgMTI3LjAuMC4xLjMzMDYgICAgIFRJTUVfV0FJVApmZmZmZmYwMTI1MjQyN2UwIHRj
 cDQgICAgICAgMCAgICAgIDAgMTI3LjAuMC4xLjE2MjE4ICAgIDEyNy4wLjAuMS4zMzA2ICAg
 ICBUSU1FX1dBSVQKZmZmZmZmMDEyNTJmM2FiMCB0Y3A0ICAgICAgIDAgICAgICAwIDEyNy4w
 LjAuMS4xNjIxNyAgICAxMjcuMC4wLjEuNTMgICAgICAgVElNRV9XQUlUCmZmZmZmZjAxMjUy
 NTUwMDAgdGNwNCAgICAgICAwICAgICAgMCAxMjcuMC4wLjEuMTYyMTYgICAgMTI3LjAuMC4x
 LjIxICAgICAgIFRJTUVfV0FJVApmZmZmZmYwMTI1MjU1NmMwIHRjcDQgICAgICAgMCAgICAg
 IDAgMTAuMC4wLjEuMTYyMTUgICAgIDEwLjAuMC4xLjMxMjggICAgICBUSU1FX1dBSVQKZmZm
 ZmZmMDEyNTI3NDA0OCB0Y3A0ICAgICAgIDAgICAgICAwIDEyNy4wLjAuMS4xNjIxNCAgICAx
 MjcuMC4wLjEuMjIgICAgICAgVElNRV9XQUlUCmZmZmZmZjAxMjUyNDJiODggdGNwNCAgICAg
 ICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYyMTMgMTk1LjgyLjE0Ni4xMjAuODAgIFRJTUVf
 V0FJVApmZmZmZmYwMTI1MjZjYzE4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0
 LjY5MzMgIDgwLjY2LjI0Mi4xMDkuMjAzNSBUSU1FX1dBSVQKZmZmZmZmMDA0ZmQ2MTAwMCB0
 Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42OTMzICAxOTUuOTEuMTY0LjM0LjI5
 MjMgVElNRV9XQUlUCmZmZmZmZjAxMjUyNzQwOTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4y
 MDkuODEuNTQuNjkzMyAgOTUuMTM0LjIxNy4xMDAuMTcxIFRJTUVfV0FJVApmZmZmZmYwMTI1
 MmYzNzk4IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDc4LjE1Mi4x
 ODguMjIuMzYxOCBUSU1FX1dBSVQKZmZmZmZmMDEyNTI2YzI0MCB0Y3A0ICAgICAgIDAgICAg
 ICAwIDg5LjIwOS44MS41NC42OTMzICA5NC4yNi4xNjkuNjcuNjQzNTYgVElNRV9XQUlUCmZm
 ZmZmZjAxMjUyNWQ2MzAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAg
 MjE3LjE1LjE5OS41OC41NDM0IFRJTUVfV0FJVApmZmZmZmYwMGE3NWRmMjg4IHRjcDQgICAg
 ICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDE4OC4xODYuMjEuMjA5LjI5NiBUSU1F
 X1dBSVQKZmZmZmZmMDAwNWFkNmFiMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41
 NC42OTMzICAyMTcuMTUuMTk5LjU4LjU4MDIgVElNRV9XQUlUCmZmZmZmZjAxMjUyNGJiZDAg
 dGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAgNzcuMTIzLjk2LjM4LjM4
 OTUgIFRJTUVfV0FJVApmZmZmZmYwMDRmZGVjMzcwIHRjcDQgICAgICAgMCAgNDUzMTIgODku
 MjA5LjgxLjU0LjY5MzMgIDkyLjEyNS42OS4zLjIzMjkgICBFU1RBQkxJU0hFRApmZmZmZmYw
 MTI1MmYzOTAwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDIxNy4x
 NS4xOTkuNTguNTQ1NyBUSU1FX1dBSVQKZmZmZmZmMDA0ZmQ2MTc1MCB0Y3A0ICAgICAgIDAg
 ICAgICAwIDg5LjIwOS44MS41NC42OTMzICA5NS4xMzQuMjE3LjEwMC4xNjIgVElNRV9XQUlU
 CmZmZmZmZjAxMjUyNmMzYTggdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkz
 MyAgODAuNjYuMjQyLjEwOS4yMDI3IFRJTUVfV0FJVApmZmZmZmYwMTI1MjRiNTEwIHRjcDQg
 ICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDk0LjI2LjE2OS42Ny42MzY0NyBU
 SU1FX1dBSVQKZmZmZmZmMDEyNTI1NTA0OCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44
 MS41NC42OTMzICA5NC43NS40LjI1NC40NTc2ICAgVElNRV9XQUlUCmZmZmZmZjAxMjUyNDI2
 MzAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAgNzguMTUyLjE4OC4y
 Mi4zNTA2IFRJTUVfV0FJVApmZmZmZmYwMTI1MjZjMzE4IHRjcDQgICAgICAgMCAgICAgIDAg
 ODkuMjA5LjgxLjU0LjY5MzMgIDkyLjI0My4xNjYuMTAxLjYzOSBUSU1FX1dBSVQKZmZmZmZm
 MDAzNmUyYTZlMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjIxMiAxOTUu
 ODIuMTQ2LjEyMC44MCAgU1lOX1NFTlQKZmZmZmZmMDA0ZmQ2MTY3OCB0Y3A0ICAgICAgIDAg
 ICAgICAwIDg5LjIwOS44MS41NC42OTMzICA4Ny4yNDUuMTMzLjExMy42MDMgVElNRV9XQUlU
 CmZmZmZmZjAwMDVhZDY1YTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkz
 MyAgNzcuMTIzLjk2LjM4LjM4MTIgIFRJTUVfV0FJVApmZmZmZmYwMTI1MjZiMDQ4IHRjcDQg
 ICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDE4OC4xODYuMjEuMjA5LjI3OSBU
 SU1FX1dBSVQKZmZmZmZmMDAwNThiYjc5OCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44
 MS41NC42OTMzICAyMTcuMTUuMTk5LjU4LjY0MDUgVElNRV9XQUlUCmZmZmZmZjAxNGI5OGY2
 ZTAgdGNwNCAgICAgICAwICAyMzI1OCA4OS4yMDkuODEuNTQuNjkzMyAgMjEyLjEwNi40NS44
 My4zNzIwIEVTVEFCTElTSEVECmZmZmZmZjAxMjUyNjI0ODAgdGNwNCAgICAgICAwICAgICAg
 MCA4OS4yMDkuODEuNTQuMTYxODEgODUuMjUwLjEyMy43NC40NzQwIFRJTUVfV0FJVApmZmZm
 ZmYwMTI1MTJiMDAwIHRjcDQgICAgICAgMCAgICAgNjggODkuMjA5LjgxLjU0LjE2MTc1IDgw
 LjkyLjIyNS45NC4yODQ5NCBGSU5fV0FJVF8xCmZmZmZmZjAxMjUyNmM3NTAgdGNwNCAgICAg
 ICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTYxMzMgODAuMjQ5Ljk1LjEyMS4zNTA3IFRJTUVf
 V0FJVApmZmZmZmYwMDYzZGU1MzcwIHRjcDQgICAgICAgMCAgMzEzNTMgODkuMjA5LjgxLjU0
 LjE2MTMyIDc5LjEyNi4zNC4xNTEuODAgICBFU1RBQkxJU0hFRApmZmZmZmYwMTI1Mjc1YWY4
 IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE2MDc3IDkzLjgxLjk1LjIxNC42
 MzQ4MyBUSU1FX1dBSVQKZmZmZmZmMDEyNTFiMTZlMCB0Y3A0ICAgICAgIDAgIDM0NjgzIDg5
 LjIwOS44MS41NC42OTMzICAxODguMTE0LjEuMjE0LjExNzQgRVNUQUJMSVNIRUQKZmZmZmZm
 MDEyNTFhOTAwMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNjAzNSA5OC4x
 MDMuMTk0LjEzNi41NjEgRklOX1dBSVRfMgpmZmZmZmYwMTI0YjFhYTUwIHRjcDQgICAgICAg
 MCAgICAzNDEgODkuMjA5LjgxLjU0LjE2MDA4IDE5NS44Mi4xNDYuMTIwLjgwICBFU1RBQkxJ
 U0hFRApmZmZmZmYwMDM2ZTJhMzcwIHRjcDQgICAgICAgMCAgMjg3MTAgODkuMjA5LjgxLjU0
 LjY5MzMgIDYyLjE5Mi4yMzMuMjI3LjQ4MSBFU1RBQkxJU0hFRApmZmZmZmYwMDRmZGVjNmUw
 IHRjcDQgICAgICAgMCAgICAgNjggODkuMjA5LjgxLjU0LjE1OTg0IDgwLjI0MC4xLjIxOC4y
 OTA4NSBGSU5fV0FJVF8xCmZmZmZmZjAwYTc1ZGYyNDAgdGNwNCAgICAgICAwICAgICAgMCA4
 OS4yMDkuODEuNTQuMTU5MTQgOTUuMjguNzMuMTAzLjM5MDI3IFRJTUVfV0FJVApmZmZmZmYw
 MTI1MGJjYTUwIHRjcDQgICAgICAgMCAgNTM5MjggODkuMjA5LjgxLjU0LjE1OTExIDk0LjI3
 LjY1LjQuMzI1MjcgICBFU1RBQkxJU0hFRApmZmZmZmYwMDU1Y2UxYTUwIHRjcDQgICAgICAg
 MCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDg5LjE2OS4xMTQuMjAuMTI1NCBFU1RBQkxJ
 U0hFRApmZmZmZmYwMDFmOGQzMDAwIHRjcDQgICAgICAgMCAgMjU5MzggODkuMjA5LjgxLjU0
 LjY5MzMgIDk1LjExMC4zNS4xMzAuNjQ3MSBFU1RBQkxJU0hFRApmZmZmZmYwMDRmZDYxMDkw
 IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE1ODQzIDkyLjUwLjE2NS44MS4z
 NTY5MSBUSU1FX1dBSVQKZmZmZmZmMDEyNTFjNDM3MCB0Y3A0ICAgICAgIDAgIDMxMzU3IDg5
 LjIwOS44MS41NC4xNTgxNCA5Mi40Ny4yMjQuMjU0LjI3NTkgRVNUQUJMSVNIRUQKZmZmZmZm
 MDE1OGQxMjM3MCB0Y3A0ICAgICAgIDAgIDIyMDM0IDg5LjIwOS44MS41NC4xNTc0NyA2Mi4x
 NDEuNjQuMTE1LjYwNzAgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNGIxYTAwMCB0Y3A0ICAgICAg
 IDAgIDIzMzAzIDg5LjIwOS44MS41NC42OTMzICA3OC4xMTEuMTUyLjYxLjQzMjkgRVNUQUJM
 SVNIRUQKZmZmZmZmMDBhNzZmOTZlMCB0Y3A0ICAgICAgIDAgIDU4MTM1IDg5LjIwOS44MS41
 NC42OTMzICA5NS4xMDcuMTEyLjI0NS4zMjcgRVNUQUJMSVNIRUQKZmZmZmZmMDEwYTZjYjZl
 MCB0Y3A0ICAgICAgIDAgICA2ODY1IDg5LjIwOS44MS41NC42OTMzICA5My4xNzUuMjA4LjEu
 Mzg3NyAgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTBiMzM3MCB0Y3A0ICAgICAgIDAgIDE4Mzg1
 IDg5LjIwOS44MS41NC42OTMzICA5Mi40Ny4yMzEuMjMuMjg5NSAgRVNUQUJMSVNIRUQKZmZm
 ZmZmMDEyNGQxMjAwMCB0Y3A0ICAgICAgIDAgIDIxMTgzIDg5LjIwOS44MS41NC42OTMzICA5
 NS43MC43OS41OC40NDMwMiAgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTEyYzAwMCB0Y3A0ICAg
 ICAgIDAgIDg1MTA0IDg5LjIwOS44MS41NC42OTMzICAxMjQuMjMxLjk0LjQ0LjM4MTEgRVNU
 QUJMSVNIRUQKZmZmZmZmMDEyNTEwZmE1MCB0Y3A0ICAgICAgIDAgIDMzNDM3IDg5LjIwOS44
 MS41NC42OTMzICA5NC45Ni4xNjguOTQuMTQ3NjUgRVNUQUJMSVNIRUQKZmZmZmZmMDA2NDlk
 ZWE1MCB0Y3A0ICAgICAgIDAgIDI5OTA5IDg5LjIwOS44MS41NC42OTMzICA4OC4yMDAuMTk4
 LjkyLjQwMTcgRVNUQUJMSVNIRUQKZmZmZmZmMDAxZjhkM2E1MCB0Y3A0ICAgICAgIDAgIDMz
 MDQzIDg5LjIwOS44MS41NC4xNTI1NSA5NS4xMTAuODguMjEyLjMyMzAgRVNUQUJMSVNIRUQK
 ZmZmZmZmMDEyNGIyZWE1MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNTIz
 MSA2MS4yMS4xOTYuMjUzLjQ0NTMgRklOX1dBSVRfMgpmZmZmZmYwMDRmZDdlNmUwIHRjcDQg
 ICAgICAgMCAgNTA2NTggODkuMjA5LjgxLjU0LjY5MzMgIDgzLjEzOS4xNDUuMjQ0LjI4NyBF
 U1RBQkxJU0hFRApmZmZmZmYwMGNlNmI5MDAwIHRjcDQgICAgICAgMCAgMTY5OTAgODkuMjA5
 LjgxLjU0LjY5MzMgIDg5LjEzOS4yNDIuNDcuMTU0NCBFU1RBQkxJU0hFRApmZmZmZmYwMDRm
 ZGVkYTUwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDk0LjI0LjEz
 My41OC40ODc1MiBFU1RBQkxJU0hFRApmZmZmZmYwMTI0YjJkMzcwIHRjcDQgICAgICAgMCAg
 OTY0MjEgODkuMjA5LjgxLjU0LjY5MzMgIDk1LjEzNC4xMzIuMTA0LjI2MSBFU1RBQkxJU0hF
 RApmZmZmZmYwMDRmZDdlMzcwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5
 MzMgIDk1LjMyLjMxLjE1Mi4yMTMwICBMQVNUX0FDSwpmZmZmZmYwMGFjNWY4MDAwIHRjcDQg
 ICAgICAgMCAgOTQ2MTQgODkuMjA5LjgxLjU0LjY5MzMgIDk1LjMyLjEwNS41Ni4zODUyICBF
 U1RBQkxJU0hFRApmZmZmZmYwMDRmZDMwYTUwIHRjcDQgICAgICAgMCAgMzIwNTAgODkuMjA5
 LjgxLjU0LjE1MTMwIDk1LjU0LjIwMy4xNzkuNDkwNSBFU1RBQkxJU0hFRApmZmZmZmYwMTI1
 MWNlMDAwIHRjcDQgICAgICAxNyAgNDI2MjAgODkuMjA5LjgxLjU0LjE1MDczIDk0LjI1My40
 MS40My4xNzE1MyBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTlmMDAwIHRjcDQgICAgICAgMCAg
 MzE5MDYgODkuMjA5LjgxLjU0LjY5MzMgIDk1LjEwNi42MC4yMzcuMTMxNiBFU1RBQkxJU0hF
 RApmZmZmZmYwMTI1MTA5NmUwIHRjcDQgICAgICAgMCAgNDE5NzggODkuMjA5LjgxLjU0LjY5
 MzMgIDk1LjEwNy44NS4yMS4xNDA3ICBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MWU5MDAwIHRj
 cDQgICAgICAgMCAgMTgzNzcgODkuMjA5LjgxLjU0LjE0ODk2IDk1Ljc5LjkzLjY2LjE0Nzg3
 ICBFU1RBQkxJU0hFRApmZmZmZmYwMDRmZWI2NmUwIHRjcDQgICAgICAgMCAgICAgIDAgODku
 MjA5LjgxLjU0LjE0ODI2IDkzLjkwLjIyOC4xODguMzA5MCBFU1RBQkxJU0hFRApmZmZmZmYw
 MTI1MWY1NmUwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE0ODI0IDg5LjIz
 NS4yNDUuMjIwLjY0MCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTUwMDAwIHRjcDQgICAgICAg
 MCAgICAyMTggODkuMjA5LjgxLjU0LjY5MzMgIDkwLjE1MS4yMjQuMTY0LjIzOCBGSU5fV0FJ
 VF8xCmZmZmZmZjAxMjRiMWMwMDAgdGNwNCAgICAgICAwICAyODY0OSA4OS4yMDkuODEuNTQu
 NjkzMyAgNjIuMTkyLjIzMy4yMjcuNTU2IEVTVEFCTElTSEVECmZmZmZmZjAxMjUxYjlhNTAg
 dGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTQ3MzAgNjIuMzMuMTY5LjIyMS4z
 MTI3IExBU1RfQUNLCmZmZmZmZjAwNjNkZTUwMDAgdGNwNCAgICAgICAwICAyOTc4MyA4OS4y
 MDkuODEuNTQuMTQ2ODYgOTIuMTI3Ljg4LjIuMjkzNzMgIEVTVEFCTElTSEVECmZmZmZmZjAx
 MjUxYjgwMDAgdGNwNCAgICAgICAwIDEwNjM4OCA4OS4yMDkuODEuNTQuNjkzMyAgODcuMjM3
 LjEzOS42LjU1MjU0IEVTVEFCTElTSEVECmZmZmZmZjAxMjUxZDgzNzAgdGNwNCAgICAgICAw
 ICAyNjkxMyA4OS4yMDkuODEuNTQuNjkzMyAgOTMuODAuMTY2LjQ1LjEzOTQgIEVTVEFCTElT
 SEVECmZmZmZmZjAxMjUxNjFhNTAgdGNwNCAgICAgICAwIDEyOTYwMCAxODguMTE1LjEyOC4z
 LjY5MzMgNzguMzYuMjUzLjIxOS40Mjk5IEVTVEFCTElTSEVECmZmZmZmZjAxMjUwYjUzNzAg
 dGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAgOTUuMzIuMzEuMTUyLjQ0
 ODMgIExBU1RfQUNLCmZmZmZmZjAxMjUwZTdhNTAgdGNwNCAgICAgICAwICA4OTA3MiA4OS4y
 MDkuODEuNTQuNjkzMyAgOTUuMTM0LjEzMi4xMDQuMjU0IEVTVEFCTElTSEVECmZmZmZmZjAx
 MjUxYzYwMDAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTQ1NDEgOTEuMTM5
 LjE5Mi4yMDcuNTgzIExBU1RfQUNLCmZmZmZmZjAxMjRiMmY2ZTAgdGNwNCAgICAgICAwICAg
 ICAgMCA4OS4yMDkuODEuNTQuMTQ1MjkgOTQuMTgwLjE5NS4yMTYuNTM4IExBU1RfQUNLCmZm
 ZmZmZjAxMjUwYWMwMDAgdGNwNCAgICAgICAwICA0NDQyNiA4OS4yMDkuODEuNTQuMTQ1MTIg
 OTQuMTgxLjEwNi4xNy4zNTY5IEVTVEFCTElTSEVECmZmZmZmZjAxMjUwYjkwMDAgdGNwNCAg
 ICAgICAwIDEzMTIyNCA4OS4yMDkuODEuNTQuNjkzMyAgOTQuMjcuNjUuMTk5LjYwNTcwIEVT
 VEFCTElTSEVECmZmZmZmZjAwNDE5MGI2ZTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDku
 ODEuNTQuMTQzNDcgODMuOTkuMTM1LjIuNDk5NjggIExBU1RfQUNLCmZmZmZmZjAxMjUxNDU2
 ZTAgdGNwNCAgICAgICAwIDEzMjEwNCA4OS4yMDkuODEuNTQuNjkzMyAgODMuMTY3LjgyLjku
 MzYwMTUgIEVTVEFCTElTSEVECmZmZmZmZjAxMjUxNTE2ZTAgdGNwNCAgICAgICAwICAgIDIx
 OCA4OS4yMDkuODEuNTQuNjkzMyAgOTUuMzIuMzEuMTUyLjM0MTUgIEZJTl9XQUlUXzEKZmZm
 ZmZmMDEyNTBkNzAwMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNDEwOSA5
 NC4yOC4xNTkuMTUxLjQzNTMgRklOX1dBSVRfMgpmZmZmZmYwMTI1MWFhYTUwIHRjcDQgICAg
 ICAgMCAgMjA0MjQgODkuMjA5LjgxLjU0LjY5MzMgIDc4LjI5Ljg2LjI2LjMxMDEgICBFU1RB
 QkxJU0hFRApmZmZmZmYwMTI1MGM2MzcwIHRjcDQgICAgICAgMCAgMzYwMDkgODkuMjA5Ljgx
 LjU0LjY5MzMgIDk0LjUxLjEyMy4xNDUuMTIxOCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MjM1
 YTUwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDg5LjIzNS4yMTUu
 MjIyLjQzOCBMQVNUX0FDSwpmZmZmZmYwMTI1MjM2NmUwIHRjcDQgICAgICAgMCAgMjUyNjcg
 ODkuMjA5LjgxLjU0LjY5MzMgIDk1LjMyLjIxLjIwMS4yNjI4ICBFU1RBQkxJU0hFRApmZmZm
 ZmYwMTI1MTliNmUwIHRjcDQgICAgICAgMCAgMzI3ODEgODkuMjA5LjgxLjU0LjY5MzMgIDg2
 LjExMC4xNzIuMjkuMTcwNCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MWUzNmUwIHRjcDQgICAg
 ICAgMCAgIDM0MzYgODkuMjA5LjgxLjU0LjY5MzMgIDkyLjQ3LjIzMS4yMy4yMDI4ICBFU1RB
 QkxJU0hFRApmZmZmZmYwMDkxMjk5MzcwIHRjcDQgICAgICAgMCAgODE3MTEgODkuMjA5Ljgx
 LjU0LjEzODk1IDU5LjU0Ljc3LjEwNi4xMjY4NiBFU1RBQkxJU0hFRApmZmZmZmYwMGIyYzY1
 MDAwIHRjcDQgICAgICAgMCAgMzEzNDcgODkuMjA5LjgxLjU0LjEzODkwIDE1MS40OS4yMjIu
 MjEzLjYyOCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTM1YTUwIHRjcDQgICAgICAgMCAgNzUz
 NzMgMTg4LjExNS4xMjguMy4xMzg3IDg1LjE0MC4xNi45NC41NTAwMCBFU1RBQkxJU0hFRApm
 ZmZmZmYwMTI1MGVkNmUwIHRjcDQgICAgICAgMCAgMTQxMzggODkuMjA5LjgxLjU0LjY5MzMg
 IDk0LjUxLjE1MC44My41ODcxNCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTFiMzcwIHRjcDQg
 ICAgICAgMCAgMzYyMTggODkuMjA5LjgxLjU0LjY5MzMgIDkxLjIxMS4yOC4yNTAuMTA5MyBF
 U1RBQkxJU0hFRApmZmZmZmYwMTdiNzQ4MzcwIHRjcDQgICAgICAgMCAgMjI4ODQgODkuMjA5
 LjgxLjU0LjY5MzMgIDg2LjI2LjEwMi45MS42MjczMiBFU1RBQkxJU0hFRApmZmZmZmYwMTI1
 MGQ0MzcwIHRjcDQgICAgICAxNyAgMTYzOTcgODkuMjA5LjgxLjU0LjEzNjYxIDk1LjUyLjEy
 OC4zNS4xNjg1NiBFU1RBQkxJU0hFRApmZmZmZmYwMDY0OWRlMDAwIHRjcDQgICAgICAgMCAg
 ICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDg4LjIxNS4xNTcuMTA1LjIxOSBFU1RBQkxJU0hF
 RApmZmZmZmYwMTI1MGQ2YTUwIHRjcDQgICAgICAgMCAgMzI5NTkgODkuMjA5LjgxLjU0LjEz
 NDU1IDkyLjEwMS42LjI1MS4yNDQzNiBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTBhMDAwIHRj
 cDQgICAgICA5NCAgMTkwNzIgODkuMjA5LjgxLjU0LjEzMzk1IDkyLjI0NC4yMzYuMTQ4LjQy
 MiBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MGNlYTUwIHRjcDQgICAgICAgMCAgMzU4NzUgODku
 MjA5LjgxLjU0LjEzMzkyIDkzLjgxLjYzLjQ3LjEzNDAxICBFU1RBQkxJU0hFRApmZmZmZmYw
 MTI1MTA3MDAwIHRjcDQgICAgICAgMCAgMzQ3MTUgODkuMjA5LjgxLjU0LjY5MzMgIDg0LjI0
 MC4yNS4xNjkuMTEwNSBFU1RBQkxJU0hFRApmZmZmZmYwMTI0YjFjNmUwIHRjcDQgICAgICAg
 MCAgMTI3MTcgODkuMjA5LjgxLjU0LjY5MzMgIDExMy45Ni4xOS42Mi40OTAzICBGSU5fV0FJ
 VF8xCmZmZmZmZjAxMjUxZWEzNzAgdGNwNCAgICAgICAwICAxNDEwNCA4OS4yMDkuODEuNTQu
 MTMyNzAgOTAuMTUxLjE1MS4yMzUuMzAzIEVTVEFCTElTSEVECmZmZmZmZjAxMjUwY2YzNzAg
 dGNwNCAgICAgICAwICAzMDcxOCA4OS4yMDkuODEuNTQuMTMxNzcgOTEuMjE0LjEzNi42MC4y
 NDAwIEVTVEFCTElTSEVECmZmZmZmZjAxMjUxZTMzNzAgdGNwNCAgICAgICAwICAzNDM5OSA4
 OS4yMDkuODEuNTQuNjkzMyAgODcuMjUzLjMuMTgzLjYyMTIxIEVTVEFCTElTSEVECmZmZmZm
 ZjAxMjUxMDIzNzAgdGNwNCAgICAgICAwICAxNzgyMSA4OS4yMDkuODEuNTQuNjkzMyAgNzku
 MTM0LjI1Ljg3LjI0MjggIEVTVEFCTElTSEVECmZmZmZmZjAxMjUwZjczNzAgdGNwNCAgICAg
 ICAwICAgICAgMCAxODguMTE1LjEyOC4zLjEyOTAgODUuMjM4LjEyNy44OC4xODI5IEVTVEFC
 TElTSEVECmZmZmZmZjAxMjUxYzVhNTAgdGNwNCAgICAgICAwICAzOTU2NCA4OS4yMDkuODEu
 NTQuNjkzMyAgOTUuNjkuMjA4LjE4Ni4xMjQyIEVTVEFCTElTSEVECmZmZmZmZjAwNjk4OGYw
 MDAgdGNwNCAgICAgICAwICAyOTMzNSA4OS4yMDkuODEuNTQuMTI4MTkgOTIuNDkuMTU2LjEx
 Mi41OTk5IEVTVEFCTElTSEVECmZmZmZmZjAxMjUxYTg2ZTAgdGNwNCAgICAgICAwICA0MzA1
 MSA4OS4yMDkuODEuNTQuNjkzMyAgODkuMjMyLjEwNS42MS4yNTI3IEVTVEFCTElTSEVECmZm
 ZmZmZjAxMjUxYjhhNTAgdGNwNCAgICAgICAwICAyMTQ4OCA4OS4yMDkuODEuNTQuMTI3OTAg
 OTIuMTI3LjExMC4xOTYuNTY2IEZJTl9XQUlUXzEKZmZmZmZmMDA0NGFhNTM3MCB0Y3A0ICAg
 ICAgIDAgIDM4MjYwIDg5LjIwOS44MS41NC4xMjc4MiA5NS41NC42MS4xNzAuMjYyMTAgRVNU
 QUJMSVNIRUQKZmZmZmZmMDBhYzVmODM3MCB0Y3A0ICAgICAgIDAgIDQwNjY4IDg5LjIwOS44
 MS41NC4xMjc2MSA5NS4xMzIuOTMuMTU2LjMyODAgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTEz
 NTM3MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xMjQ3NiA3Ny4zNS4xNzQu
 NDQuMTA2NTkgRVNUQUJMSVNIRUQKZmZmZmZmMDBhN2U3MTAwMCB0Y3A0ICAgICAgIDAgIDI0
 OTYyIDg5LjIwOS44MS41NC42OTMzICA5MC4xNTEuMzIuOTQuNjIzNTAgRVNUQUJMSVNIRUQK
 ZmZmZmZmMDEyNTEwZTZlMCB0Y3A0ICAgICAgIDAgIDM4MTgwIDg5LjIwOS44MS41NC4xMTk5
 NyA5My45MC4yMDguMjI4LjU5MDMgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTE3ZGE1MCB0Y3A0
 ICAgICAgIDAgIDQwNzM5IDg5LjIwOS44MS41NC42OTMzICA4OS4yNTEuMTA3LjMwLjM0MjIg
 RVNUQUJMSVNIRUQKZmZmZmZmMDBhN2U2ZTZlMCB0Y3A0ICAgICAgIDAgIDM4ODcyIDg5LjIw
 OS44MS41NC42OTMzICA5NS4xMTAuNS41MS4xMTk1NiAgRVNUQUJMSVNIRUQKZmZmZmZmMDEy
 NTExODM3MCB0Y3A0ICAgICAxMTcgIDIzNjUwIDg5LjIwOS44MS41NC42OTMzICA5Mi4xMDEu
 MTMzLjc2LjIyMjggRVNUQUJMSVNIRUQKZmZmZmZmMDA0Yjk0ZDM3MCB0Y3A0ICAgICAgIDAg
 IDE4OTM3IDg5LjIwOS44MS41NC42OTMzICA2MC4yNDEuMTgyLjUzLjUzNDMgRVNUQUJMSVNI
 RUQKZmZmZmZmMDEyNTE1ZjZlMCB0Y3A0ICAgICAgIDAgMTMxMzc2IDg5LjIwOS44MS41NC4x
 MDU4OSAyMTMuMTY3LjIxNC4xNTUuMjIgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTFjNGE1MCB0
 Y3A0ICAgICAgMzUgIDI1NTU3IDg5LjIwOS44MS41NC4xMDEwNCA5My44MS4xNjYuMjE4LjYy
 ODEgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTE1ZjAwMCB0Y3A0ICAgICAgIDAgIDE3MDA2IDg5
 LjIwOS44MS41NC42OTMzICA5NC45Ni4xNjguOTQuMTQxMTAgRklOX1dBSVRfMQpmZmZmZmYw
 MTI1MTFiMDAwIHRjcDQgICAgICAgMCAgMTI5ODEgODkuMjA5LjgxLjU0LjY5MzMgIDg5LjEx
 Mi4xMTEuODkuMTg5NSBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTU5MDAwIHRjcDQgICAgICAx
 NyAgMTYzOTcgODkuMjA5LjgxLjU0LjY1MzEyIDkyLjEyNi42NC4yMjguNTU5NyBFU1RBQkxJ
 U0hFRApmZmZmZmYwMDA1N2YxMDAwIHRjcDQgICAgICAgMCAgMTkzNTQgODkuMjA5LjgxLjU0
 LjY1MjgwIDg5LjEwMy4xMzcuOC42NDYzOSBFU1RBQkxJU0hFRApmZmZmZmYwMDY0NmE2Mzcw
 IHRjcDQgICAgICAgMCAgNDY4OTcgODkuMjA5LjgxLjU0LjY5MzMgIDI0LjE0LjUxLjYuNjQw
 OTcgICBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTllMzcwIHRjcDQgICAgICAgMCAxMDQzODQg
 ODkuMjA5LjgxLjU0LjY5MzMgIDYyLjMzLjIzMi40NS41OTgyNSBFU1RBQkxJU0hFRApmZmZm
 ZmYwMTI1MWQ5NmUwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY0ODE1IDk1
 Ljc4LjEzOS44Ny4xNDU2NyBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTcwMDAwIHRjcDQgICAg
 ICAgMCAgNDgyODQgODkuMjA5LjgxLjU0LjY5MzMgIDc4LjE1My4yNi4xMTYuMjU2OSBFU1RB
 QkxJU0hFRApmZmZmZmYwMTI1MWQ5YTUwIHRjcDQgICAgICAgMCAgMTAzNzQgODkuMjA5Ljgx
 LjU0LjY5MzMgIDkxLjIwMC4xMzkuMjE2LjI2OCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MGM2
 MDAwIHRjcDQgICAgICAgMCAgMzc4ODAgODkuMjA5LjgxLjU0LjY0MzMzIDEyNS4yNi4xMTUu
 ODEuNTE5OCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MGU0MDAwIHRjcDQgICAgICAzNCAgNDA0
 OTQgODkuMjA5LjgxLjU0LjY5MzMgIDk1LjI1LjkwLjE3NC40NDUwICBFU1RBQkxJU0hFRApm
 ZmZmZmYwMTI1MWMzYTUwIHRjcDQgICAgICAgMCAgMTc0NDYgODkuMjA5LjgxLjU0LjY5MzMg
 IDk1LjEzOS4xNzguMjAuNjQxNiBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTJjYTUwIHRjcDQg
 ICAgICAgMCAgNDA3NzEgODkuMjA5LjgxLjU0LjY0MjAyIDkxLjIxNC4xMzYuNjAuMjQwMCBF
 U1RBQkxJU0hFRApmZmZmZmYwMTI1MTE5YTUwIHRjcDQgICAgICAgMCAgMzMxODcgODkuMjA5
 LjgxLjU0LjY0MTc4IDkyLjI0NC4yMzYuMTQ4LjQyMiBFU1RBQkxJU0hFRApmZmZmZmYwMTI1
 MTIxMzcwIHRjcDQgICAgICAgMCAgMjUxNjAgODkuMjA5LjgxLjU0LjY5MzMgIDc5LjIxOC4x
 NTAuMTk1LjU5MCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MGRlYTUwIHRjcDQgICAgICAgMCAg
 MTkxOTQgODkuMjA5LjgxLjU0LjY5MzMgIDk1LjExMC4xMDQuMTc2LjI2NCBFU1RBQkxJU0hF
 RApmZmZmZmYwMTI1MjM2MDAwIHRjcDQgICAgICAgMCAgIDE5ODQgODkuMjA5LjgxLjU0LjY5
 MzMgIDE4OC4xMjguODguMTcwLjY0NCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MGViMDAwIHRj
 cDQgICAgICAgMCAgIDYzMDQgODkuMjA5LjgxLjU0LjY5MzMgIDc3LjEyMC41Ni4xNy4xNzM0
 ICBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTM2YTUwIHRjcDQgICAgICAgMCAgIDM1MzIgODku
 MjA5LjgxLjU0LjYyMDA5IDkxLjEyNC4yNDQuMjMwLjI5OSBFU1RBQkxJU0hFRApmZmZmZmYw
 MTI1MGIyNmUwIHRjcDQgICAgICAgMCAgMTk0MjggODkuMjA5LjgxLjU0LjY5MzMgIDk0LjUx
 LjE1MC44My41ODE1OCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MWUwYTUwIHRjcDQgICAgICAg
 MCAgMjQ3MDIgODkuMjA5LjgxLjU0LjY5MzMgIDg4LjIwNS4xNzQuMjE4LjE1MCBFU1RBQkxJ
 U0hFRApmZmZmZmYwMTI1MTZhNmUwIHRjcDQgICAgICAgMCAgMTU5MTcgODkuMjA5LjgxLjU0
 LjYxNjEyIDE4OC4yNDMuMjUwLjUuMTc1OSBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MGJjMzcw
 IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjYxNTkzIDkzLjg0Ljc0LjYyLjQ3
 MTg2ICBFU1RBQkxJU0hFRApmZmZmZmYwMGJiNWIxMzcwIHRjcDQgICAgICAgMCAgODIzMjUg
 ODkuMjA5LjgxLjU0LjYxMTgwIDE4OC40LjIxNy4xNzYuNjAwMCBFU1RBQkxJU0hFRApmZmZm
 ZmYwMTI0YjJmMzcwIHRjcDQgICAgICAgMCAgMzA1MzggODkuMjA5LjgxLjU0LjY5MzMgIDg1
 LjE1OS4yMjUuMTYxLjEwMSBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MWE5YTUwIHRjcDQgICAg
 ICAgMCAgMjAwNjQgODkuMjA5LjgxLjU0LjY5MzMgIDc5LjE0MC43OC4yMi4xNjEzICBFU1RB
 QkxJU0hFRApmZmZmZmYwMTI1MTExMDAwIHRjcDQgICAgICAgMCAgMzMwNDcgODkuMjA5Ljgx
 LjU0LjYwMjMyIDc5LjEzMi43Mi44Ni42MTc4NSBFU1RBQkxJU0hFRApmZmZmZmYwMTI0YjJm
 YTUwIHRjcDQgICAgICAgMCAgNDI5NzUgODkuMjA5LjgxLjU0LjU5NzQ5IDk0LjI3LjY1LjEy
 Ny4zMjUyNyBGSU5fV0FJVF8xCmZmZmZmZjAwNTVjZTE2ZTAgdGNwNCAgICAgICAwIDEyOTk0
 OCA4OS4yMDkuODEuNTQuNTk2MDIgOTQuMjQuMTMzLjU4LjY4ODEgIEVTVEFCTElTSEVECmZm
 ZmZmZjAxNDIzOGJhNTAgdGNwNCAgICAgIDE3ICAyODIwNiA4OS4yMDkuODEuNTQuNjkzMyAg
 OTQuMjUxLjg0LjIuMTg3NiAgIEVTVEFCTElTSEVECmZmZmZmZjAxMjUxY2NhNTAgdGNwNCAg
 ICAgICAwICAgNzc4MiA4OS4yMDkuODEuNTQuNjkzMyAgOTQuMjQzLjYuNzcuNTY5ODIgIEVT
 VEFCTElTSEVECmZmZmZmZjAwODBjNjUwMDAgdGNwNCAgICAgICAwICAxMTc4NCA4OS4yMDku
 ODEuNTQuNjkzMyAgODUuMTc0LjU2LjIyOC4yMzc5IEVTVEFCTElTSEVECmZmZmZmZjAxMjUw
 ZGY2ZTAgdGNwNCAgICAgICAwICAyOTU1NyA4OS4yMDkuODEuNTQuNTkwODkgODUuMTczLjIy
 LjY1LjU5MDM5IEVTVEFCTElTSEVECmZmZmZmZjAxNmM0ZjkzNzAgdGNwNCAgICAgICAwICA1
 Mzc4MyA4OS4yMDkuODEuNTQuNTcwNjUgOTUuMjUuMjE5LjI4LjUyNTk1IEVTVEFCTElTSEVE
 CmZmZmZmZjAxMjUxNTFhNTAgdGNwNCAgICAgICA5ICA2ODQzNSA4OS4yMDkuODEuNTQuNjkz
 MyAgOTUuMTMyLjIyLjI0OC41MzgzIEVTVEFCTElTSEVECmZmZmZmZjAxMjUyMzZhNTAgdGNw
 NCAgICAgICAwIDEyOTk0OCA4OS4yMDkuODEuNTQuNjkzMyAgODUuMTcyLjEyMy4zMy4zMjk5
 IEVTVEFCTElTSEVECmZmZmZmZjAwNTQyZDcwMDAgdGNwNCAgICAgICAwICAgICAgMCA4OS4y
 MDkuODEuNTQuNTY2MDAgODkuMjUxLjE0NS42OS41MDAwIEZJTl9XQUlUXzIKZmZmZmZmMDEy
 NTE3MjAwMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC41NTg1OSA5MS4xMjIu
 MTYwLjQ3LjMzMzMgRklOX1dBSVRfMgpmZmZmZmYwMTI1MGVjMDAwIHRjcDQgICAgICAgMCAg
 ODMwMDkgODkuMjA5LjgxLjU0LjY5MzMgIDg5LjE3OS4yNDIuMjUzLjIyMCBFU1RBQkxJU0hF
 RApmZmZmZmYwMTI1MWE3MDAwIHRjcDQgICAgICAgMCAgIDE0NjIgODkuMjA5LjgxLjU0LjY5
 MzMgIDkxLjIxMC4yMDEuMS4zNDQzICBFU1RBQkxJU0hFRApmZmZmZmYwMGE3ZTcwMDAwIHRj
 cDQgICAgICAgMCAgMTY2MzUgODkuMjA5LjgxLjU0LjUyMzQ0IDk1LjY3LjE1OS4yNDQuMTQy
 OCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTJhYTUwIHRjcDQgICAgICAgMCAgMzEzNTQgODku
 MjA5LjgxLjU0LjUxNzUyIDkxLjEyNC4yMzMuMTQ2LjM2OCBFU1RBQkxJU0hFRApmZmZmZmYw
 MTI1MWJhNmUwIHRjcDQgICAgIDIwOSAgNDEyMDMgODkuMjA5LjgxLjU0LjUxNzM5IDE5NS40
 Ni4xODcuNzQuMzMzMyBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MWQ3NmUwIHRjcDQgICAgICAg
 MCAgMzM2ODAgODkuMjA5LjgxLjU0LjUxNzMwIDk1LjE2MS4xOC42LjMwMzE1ICBFU1RBQkxJ
 U0hFRApmZmZmZmYwMTI1MTdlMzcwIHRjcDQgICAgICAgMCAgNDIzNjIgODkuMjA5LjgxLjU0
 LjUxNDY2IDkxLjEyNC4xOTQuMTkyLjEwOSBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTA4YTUw
 IHRjcDQgICAgICAgMCAgICAgIDAgMTAuMC4wLjEuOTkzICAgICAgIDEwLjAuMC4xMC40NDA3
 ICAgICBFU1RBQkxJU0hFRApmZmZmZmYwMTg4NGRmNmUwIHRjcDQgICAgICAgMCAgICAgIDAg
 ODkuMjA5LjgxLjU0LjUwOTM1IDg5LjI1MS4xNDUuNjkuNTAwMCBGSU5fV0FJVF8yCmZmZmZm
 ZjAwNGYzNDhhNTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAgOTMu
 MTIwLjE0My4xNDIuNDUxIEVTVEFCTElTSEVECmZmZmZmZjAxMjUxNWYzNzAgdGNwNCAgICAg
 ICAwICAgICAgMCA4OS4yMDkuODEuNTQuNTAxNzEgNjkuMTQzLjEwLjQxLjM4ODM4IEZJTl9X
 QUlUXzIKZmZmZmZmMDEyNTExMGE1MCB0Y3A0ICAgICAgIDAgIDI1ODcxIDg5LjIwOS44MS41
 NC42OTMzICA5My4xMTYuMjE4LjExOC4xMjAgRVNUQUJMSVNIRUQKZmZmZmZmMDE1OGQxMTZl
 MCB0Y3A0ICAgICAgIDAgIDE4NjcyIDg5LjIwOS44MS41NC42OTMzICA5MC4xNTAuMjQ2LjY5
 LjIxNzAgRVNUQUJMSVNIRUQKZmZmZmZmMDA0ZjliNzAwMCB0Y3A0ICAgICAgIDAgMTE3MDk2
 IDE4OC4xMTUuMTI4LjMuNDg5OCAyMTcuMjI5LjExOC43NC4yNTQgRVNUQUJMSVNIRUQKZmZm
 ZmZmMDBiNTA1MWE1MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC40ODA4OSA4
 OS4yNTEuMTQ1LjY5LjUwMDAgRklOX1dBSVRfMgpmZmZmZmYwMTI1MGViYTUwIHRjcDQgICAg
 ICAgMCAgMzExMTUgODkuMjA5LjgxLjU0LjQ4MDExIDg3LjY5LjQzLjQwLjE2MDY4ICBFU1RB
 QkxJU0hFRApmZmZmZmYwMTI1MWE3MzcwIHRjcDQgICAgICAgMCAgMzUxMTQgODkuMjA5Ljgx
 LjU0LjY5MzMgIDkyLjI0NS4yMTIuMTU0LjE0NCBFU1RBQkxJU0hFRApmZmZmZmYwMDYyMTc2
 YTUwIHRjcDQgICAgICAgMCAgMTg2MjAgODkuMjA5LjgxLjU0LjQ3MjI0IDk1LjEzNC4yNTAu
 MTg3LjE1OCBFU1RBQkxJU0hFRApmZmZmZmYwMDNiOTRlMzcwIHRjcDQgICAgICAgMCAgNDc4
 NDUgODkuMjA5LjgxLjU0LjQ3MDgwIDk1LjI1LjEwLjIwLjM4MDEzICBFU1RBQkxJU0hFRApm
 ZmZmZmYwMTI1MTdiNmUwIHRjcDQgICAgICAgMCAgMTc0MjQgODkuMjA5LjgxLjU0LjQ2ODc1
 IDc5LjEzOS4xNzcuMjMxLjE3NSBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTBhMzcwIHRjcDQg
 ICAgICAgMCAgMTQ5NTYgODkuMjA5LjgxLjU0LjQ2ODIxIDk1Ljc4LjMzLjM0LjU3OTgwICBF
 U1RBQkxJU0hFRApmZmZmZmYwMTI1MWVjYTUwIHRjcDQgICAgICAxNyAxMTQyNDAgODkuMjA5
 LjgxLjU0LjY5MzMgIDE5NS4yMTguMjQ0LjIyLjEyMSBFU1RBQkxJU0hFRApmZmZmZmYwMTI1
 MWIyMzcwIHRjcDQgICAgICAgMCAgNjI4NzAgMTg4LjExNS4xMjguMy40NjAzIDkyLjExMy45
 Ny4xNDguMTUwNSBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MGIyMDAwIHRjcDQgICAgICAgMCAg
 Mzc1MjIgODkuMjA5LjgxLjU0LjY5MzMgIDY4LjEwNi4zMC4yNDUuNTUwNSBFU1RBQkxJU0hF
 RApmZmZmZmYwMTI1MTRmMDAwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjQ1
 OTc5IDkzLjEwOS43LjU2LjUyNjYxICBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MWI4MzcwIHRj
 cDQgICAgICAgMCAgNzk1OTQgODkuMjA5LjgxLjU0LjY5MzMgIDIyMS4yMDIuMTIxLjI4LjY0
 MyBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MWJhMzcwIHRjcDQgICAgICAgMCAgMTc1NjAgODku
 MjA5LjgxLjU0LjQ1NjM4IDE5NS42OS4yNDkuMzguMzc1MCBFU1RBQkxJU0hFRApmZmZmZmYw
 MTI1MTlmMzcwIHRjcDQgICAgICAzNSAgMzEwMjAgODkuMjA5LjgxLjU0LjY5MzMgIDkxLjIw
 Ni4xMTAuNC40NjYzICBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTZiMDAwIHRjcDQgICAgICAg
 MCAgMjE5OTAgODkuMjA5LjgxLjU0LjY5MzMgIDE5NS4xMTIuMjMzLjE3Mi4xMSBFU1RBQkxJ
 U0hFRApmZmZmZmYwMTI0YjFiMzcwIHRjcDQgICAgICAgMCAxMDcxMDAgMTg4LjExNS4xMjgu
 My40NTAwIDkxLjc4LjE3MC4yMDguMTcwMyBFU1RBQkxJU0hFRApmZmZmZmYwMDU1Y2UxMDAw
 IHRjcDQgICAgICAgMCAgNTYyMDggODkuMjA5LjgxLjU0LjQ0MTMxIDc5LjE3MC4xNjQuNzAu
 MjA2OSBFU1RBQkxJU0hFRApmZmZmZmYwMDFhZTljYTUwIHRjcDQgICAgICAgMCAgMzQxMzkg
 ODkuMjA5LjgxLjU0LjY5MzMgIDgzLjE0OS4yNC4xMTkuMTkyNCBFU1RBQkxJU0hFRApmZmZm
 ZmYwMDQ2MWI0YTUwIHRjcDQgICAgICAgMCAgMzE1MzUgODkuMjA5LjgxLjU0LjY5MzMgIDc3
 LjQ1LjE4Mi4xMDYuMjQzMCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MGM3MzcwIHRjcDQgICAg
 ICAgMCAgMzQ3MzYgODkuMjA5LjgxLjU0LjQxMTY1IDc5LjEzNS43OS4yLjI3OTI0ICBFU1RB
 QkxJU0hFRApmZmZmZmYwMTI1MTYwMzcwIHRjcDQgICAgICAgMCAgIDY1NDcgODkuMjA5Ljgx
 LjU0LjY5MzMgIDE5NS4yMjIuMTI2LjEwLjMwMCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MWI0
 MDAwIHRjcDQgICAgICAgMCAgMTQ5NTcgODkuMjA5LjgxLjU0LjY5MzMgIDk1LjE2NS45OS4y
 MDIuNTE3OCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MGY4MzcwIHRjcDQgICAgICAgMCAgICAg
 IDAgODkuMjA5LjgxLjU0LjM2ODk2IDg5LjI1MS4xNDUuNjkuNTAwMCBGSU5fV0FJVF8yCmZm
 ZmZmZjAxMjUxZTlhNTAgdGNwNCAgICAgICAwICAgMTQxNSA4OS4yMDkuODEuNTQuMzY2MDcg
 NzcuMzUuMTU5LjE3NC4xNzgzIEVTVEFCTElTSEVECmZmZmZmZjAxMjUxZWFhNTAgdGNwNCAg
 ICAgICAwICAgNTk1MSA4OS4yMDkuODEuNTQuMzY2MDYgNzkuMjEyLjk2LjQ2LjgwODAgIEVT
 VEFCTElTSEVECmZmZmZmZjAxMjUxMDg2ZTAgdGNwNCAgICAgICAwICAzNzgzOSA4OS4yMDku
 ODEuNTQuMzYyMzcgNjkuMTcyLjExOS42OC4yMzg3IEVTVEFCTElTSEVECmZmZmZmZjAxMjUx
 MDE2ZTAgdGNwNCAgICAgICAwICAzMTEzNiA4OS4yMDkuODEuNTQuMzYyMTAgNjIuMTgzLjk2
 Ljk0LjY5MDAgIEVTVEFCTElTSEVECmZmZmZmZjAxMjRiMmM2ZTAgdGNwNCAgICAgICAwICA0
 MTE1NCA4OS4yMDkuODEuNTQuMzQ5NTIgMTkzLjIzOS4xNDMuMzcuMTgzIEVTVEFCTElTSEVE
 CmZmZmZmZjAwMWNmNThhNTAgdGNwNCAgICAgICAwICA0NzgzMyA4OS4yMDkuODEuNTQuMzM4
 ODUgNzcuNTEuMTM5LjE1OC4xMjMzIEVTVEFCTElTSEVECmZmZmZmZjAxN2I3NDg2ZTAgdGNw
 NCAgICAgICAwICAzNTczNiA4OS4yMDkuODEuNTQuMzMyNTMgNzguNjAuMTkuMjQyLjI2MTkz
 IEVTVEFCTElTSEVECmZmZmZmZjAxMjUxYjEzNzAgdGNwNCAgICAgICAwICAgICAgMCAxMC4w
 LjAuMS45OTMgICAgICAgMTAuMC4wLjEwLjI0MzAgICAgIEVTVEFCTElTSEVECmZmZmZmZjAx
 NDIzOGI2ZTAgdGNwNCAgICAgICAwICAzOTE0OSA4OS4yMDkuODEuNTQuNjkzMyAgMTIzLjI0
 My4yMjkuMjUuNTc0IEVTVEFCTElTSEVECmZmZmZmZjAxMjUxNWIzNzAgdGNwNCAgICAgICAw
 ICAgICAgMCA4OS4yMDkuODEuNTQuMjk2NzIgNzguMTMyLjE4MS4xOTMuMTUwIEVTVEFCTElT
 SEVECmZmZmZmZjAxMjUxNTA2ZTAgdGNwNCAgICAgICAwICAzNDU4MSA4OS4yMDkuODEuNTQu
 MjkyNTcgOTIuMTAwLjEzMi4xODUuNDIzIEVTVEFCTElTSEVECmZmZmZmZjAxMjUxMmE2ZTAg
 dGNwNCAgICAgICAwICAgICAgMCAxMC4wLjAuMS4yMiAgICAgICAgMTAuMC4wLjEwLjIwMTIg
 ICAgIEVTVEFCTElTSEVECmZmZmZmZjAwMDU3ZWJhNTAgdGNwNCAgICAgICAwICAzMTA3NCA4
 OS4yMDkuODEuNTQuNjkzMyAgNzkuMTMzLjEzNi4xNDkuMzkyIEVTVEFCTElTSEVECmZmZmZm
 ZjAxMjUxMjE2ZTAgdGNwNCAgICAgICAwICAgICAgMCAxMC4wLjAuMS45OTMgICAgICAgMTAu
 MC4wLjEwLjE5NTIgICAgIEVTVEFCTElTSEVECmZmZmZmZjAwNGZkZWQ2ZTAgdGNwNCAgICAg
 ICAwICAgICAgMCAxMC4wLjAuMS45OTMgICAgICAgMTAuMC4wLjEwLjE5MjYgICAgIEVTVEFC
 TElTSEVECmZmZmZmZjAxMjUxZDdhNTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEu
 NTQuMjgxOTIgODkuMjUxLjE0NS42OS41MDAwIEZJTl9XQUlUXzIKZmZmZmZmMDEyNTBmNTAw
 MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4yODEzNSA5NS4zMS40LjI4LjUx
 Nzc2ICAgRklOX1dBSVRfMgpmZmZmZmYwMDRmZWI1YTUwIHRjcDQgICAgICAgMCAgMzExODAg
 ODkuMjA5LjgxLjU0LjY5MzMgIDkxLjE1MS4yNDIuMjA3LjIwMiBFU1RBQkxJU0hFRApmZmZm
 ZmYwMTI1MGFjMzcwIHRjcDQgICAgICAgMCAgMzYxNjggODkuMjA5LjgxLjU0LjY5MzMgIDg0
 LjEwMi4yMjAuMTI4LjQwNyBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTcyYTUwIHRjcDQgICAg
 ICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDg4LjE0Ny4yMTcuMjI5LjQxMiBFU1RB
 QkxJU0hFRApmZmZmZmYwMDU4NDM3NmUwIHRjcDQgICAgICAgMCAgMzQ5OTkgMTg4LjExNS4x
 MjguMy42OTMzIDg2LjU3LjEzMi4yMTEuMzI4NiBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTJj
 NmUwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjIzNTExIDIwNS4xODguOS41
 MS40NDMgICBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MGVkYTUwIHRjcDQgICAgICAgMCAgICAg
 IDAgMTAuMC4wLjEuMzEyOCAgICAgIDEwLjAuMC4xMC4xMTI4ICAgICBFU1RBQkxJU0hFRApm
 ZmZmZmYwMDU0MmQ3YTUwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjIzNTEw
 IDIwNS4xODguOC4xOTkuNDQzICBFU1RBQkxJU0hFRApmZmZmZmYwMDkxMjk5NmUwIHRjcDQg
 ICAgICAgMCAgICAgIDAgMTAuMC4wLjEuMzEyOCAgICAgIDEwLjAuMC4xMC4xMTI3ICAgICBF
 U1RBQkxJU0hFRApmZmZmZmYwMTI1MTExMzcwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5
 LjgxLjU0LjIzNTA5IDIwNS4xODguOC43LjQ0MyAgICBFU1RBQkxJU0hFRApmZmZmZmYwMGFj
 NWY4NmUwIHRjcDQgICAgICAgMCAgICAgIDAgMTAuMC4wLjEuMzEyOCAgICAgIDEwLjAuMC4x
 MC4xMTI2ICAgICBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTU4MzcwIHRjcDQgICAgICAgMCAg
 ICAgIDAgMTg4LjExNS4xMjguMy4yMzQ0IDIwOC45My4wLjEyOC41MjIyICBFU1RBQkxJU0hF
 RApmZmZmZmYwMTI1MTQ1MDAwIHRjcDQgICAgICAgMCAgICAgIDAgMTAuMC4wLjEuMzEyOCAg
 ICAgIDEwLjAuMC4xMC4xMDk4ICAgICBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MGU3MzcwIHRj
 cDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjIzNDQ2IDIwOS44NS4xMzcuMTI1LjUy
 MiBFU1RBQkxJU0hFRApmZmZmZmYwMTYwN2UzMDAwIHRjcDQgICAgICAgMCAgICAgIDAgMTAu
 MC4wLjEuMzEyOCAgICAgIDEwLjAuMC4xMC4xMDk3ICAgICBFU1RBQkxJU0hFRApmZmZmZmYw
 MTI1MjMzYTUwIHRjcDQgICAgICAgMCAgICAgIDAgMTg4LjExNS4xMjguMy4yMzQ0IDc0LjYz
 LjU3Ljc3LjUyMjMgICBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MWI4NmUwIHRjcDQgICAgICAg
 MCAgICAgIDAgMTAuMC4wLjEuMzEyOCAgICAgIDEwLjAuMC4xMC4xMDk2ICAgICBFU1RBQkxJ
 U0hFRApmZmZmZmYwMTI1MGQ0NmUwIHRjcDQgICAgICAgMCAgICAgIDAgMTAuMC4wLjEuMTM5
 ICAgICAgIDEwLjAuMC4xMC4xMDM4ICAgICBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MGFkMzcw
 IHRjcDQgICAgICAyNiAgNDUyMTQgODkuMjA5LjgxLjU0LjIyNjQwIDk1LjI4LjE5OS42Ni4z
 OTMwNCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTUyYTUwIHRjcDQgICAgICAgMCAgNDQzNDUg
 ODkuMjA5LjgxLjU0LjIxNTg0IDIwNi4yNDguMTY1LjE2NS40MiBFU1RBQkxJU0hFRApmZmZm
 ZmYwMTI1MTI5MDAwIHRjcDQgICAgICAgMCAgMjY3NjIgODkuMjA5LjgxLjU0LjIxMTkwIDYy
 LjIxNy4xNTMuNjMuNjQ2NSBFU1RBQkxJU0hFRApmZmZmZmYwMDMwYjhlMzcwIHRjcDQgICAg
 ICAgMCAgMzU4NjMgODkuMjA5LjgxLjU0LjIwMDM0IDkzLjgxLjEwNC4yNTQuNjI2MCBFU1RB
 QkxJU0hFRApmZmZmZmYwMTI0YjFjYTUwIHRjcDQgICAgICAgMCAgMjAzOTcgODkuMjA5Ljgx
 LjU0LjE4Mjc1IDk1LjExMC45OS4yNS41Nzk0NCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MWFh
 MDAwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjE3ODczIDg5LjI1MS4xNDUu
 NjkuNTAwMCBGSU5fV0FJVF8yCmZmZmZmZjAwYjUwNTE2ZTAgdGNwNCAgICAgICAwICAzNjI5
 MSA4OS4yMDkuODEuNTQuNjkzMyAgODYuMTU1LjExOS4xMzQuNDUyIEVTVEFCTElTSEVECmZm
 ZmZmZjAxMjRiMjY2ZTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMTY3NjIg
 OTkuMjQwLjIxNy44OC40OTY5IEZJTl9XQUlUXzIKZmZmZmZmMDEyNTFiNGE1MCB0Y3A0ICAg
 ICAgIDAgIDI1NjA1IDg5LjIwOS44MS41NC4xNjQzMCA5My44NC4yMTIuNDguNjI1NTAgRVNU
 QUJMSVNIRUQKZmZmZmZmMDBjOWIzZTAwMCB0Y3A0ICAgICAgMjYgIDI4ODcyIDg5LjIwOS44
 MS41NC42OTMzICA5Mi4zNy4yMTMuMTM5LjU1NjEgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTFh
 MDZlMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xMzYzOCA3Ny4zNS4xNzEu
 MjIwLjYxNzggRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTE3MDM3MCB0Y3A0ICAgICAgIDAgIDIw
 MzQxIDg5LjIwOS44MS41NC42OTMzICA5NC4xNTguMzIuMTExLjE1ODAgRVNUQUJMSVNIRUQK
 ZmZmZmZmMDEyNTEwODAwMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xMDk5
 MSA5NC4yMzEuNzYuMTYxLjYzOTAgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTFkNjAwMCB0Y3A0
 ICAgICAgIDAgIDQzNzAyIDg5LjIwOS44MS41NC42OTMzICA4OC4yMjIuMTY4LjE0NC42MzAg
 RVNUQUJMSVNIRUQKZmZmZmZmMDA0ZmViNmE1MCB0Y3A0ICAgICAgIDAgICA2ODY0IDg5LjIw
 OS44MS41NC42OTMzICA5NC4yNy45Ni4yNTUuMTcyNCAgRVNUQUJMSVNIRUQKZmZmZmZmMDA0
 ZmQ3ZDM3MCB0Y3A0ICAgICAgIDAgIDI4ODczIDg5LjIwOS44MS41NC42MzE0OCA5Mi4xMjYu
 MTAyLjk5LjYxOTIgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTBiNDM3MCB0Y3A0ICAgICAgIDAg
 ICAgICAwIDg5LjIwOS44MS41NC42MjE1NiA4Ny4yNDcuODcuMTA5LjQzODUgRVNUQUJMSVNI
 RUQKZmZmZmZmMDA0ZmQ5MzM3MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42
 MTQyNCA4My4yNDEuNS4yMjAuNTAwMDEgRklOX1dBSVRfMgpmZmZmZmYwMTI0YjI0YTUwIHRj
 cDQgICAgICAgMCAgNDQzMzYgODkuMjA5LjgxLjU0LjYwNjMxIDk1LjEzOS4xMDIuMTEzLjYy
 MSBFU1RBQkxJU0hFRApmZmZmZmYwMDY5ODhmNmUwIHRjcDQgICAgICAgMCAgMjAzODIgODku
 MjA5LjgxLjU0LjY5MzMgIDc3LjIzNi4yMTAuMTc2LjExMCBFU1RBQkxJU0hFRApmZmZmZmYw
 MTI1MGQwYTUwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDkxLjIw
 Ny4yMTAuNjIuNTcxNiBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTUwMzcwIHRjcDQgICAgICAg
 MCAgIDYzMzAgODkuMjA5LjgxLjU0LjY5MzMgIDk0LjE3OC4yMDkuMjQ5LjQ1MiBFU1RBQkxJ
 U0hFRApmZmZmZmYwMTUyNDBhMzcwIHRjcDQgICAgICAxNyAgNDI5ODggODkuMjA5LjgxLjU0
 LjY5MzMgIDk0LjI1MS4xNC41My4xMDQ4ICBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTQ3MDAw
 IHRjcDQgICAgICAgMCAgMzcyODYgODkuMjA5LjgxLjU0LjY5MzMgIDkwLjE4OS4xNTQuMjUy
 LjY0MSBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MjMzMDAwIHRjcDQgICAgICAgMCAgICAgIDAg
 ODkuMjA5LjgxLjU0LjU2ODU0IDg5LjI1MS4xNDUuNjkuNTAwMCBGSU5fV0FJVF8yCmZmZmZm
 ZjAxMjUwYzY2ZTAgdGNwNCAgICAgICAwICAzODUzMyA4OS4yMDkuODEuNTQuNTYyMzYgOTUu
 MTM0Ljc0LjQyLjE5MTYwIEVTVEFCTElTSEVECmZmZmZmZjAxMjUxNDY2ZTAgdGNwNCAgICAg
 ICAwICAxMjM0MCA4OS4yMDkuODEuNTQuNTQzMjMgOTUuMjQuMTc4LjcyLjIwODYxIEVTVEFC
 TElTSEVECmZmZmZmZjAxMjRkMTJhNTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEu
 NTQuNTM2OTYgODkuMjUxLjE0NS42OS41MDAwIEZJTl9XQUlUXzIKZmZmZmZmMDEyNTBmN2E1
 MCB0Y3A0ICAgICAgIDAgIDM5NTg4IDg5LjIwOS44MS41NC41MjY5MCA4Mi4xMi45LjMzLjU1
 MjU0ICAgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNGIyNDAwMCB0Y3A0ICAgICAgIDAgICA0OTcz
 IDg5LjIwOS44MS41NC42OTMzICA4NS4xNzIuMTAwLjY4LjI1NTEgRVNUQUJMSVNIRUQKZmZm
 ZmZmMDEyNTE0NjAwMCB0Y3A0ICAgICAgIDAgIDYwMDUzIDg5LjIwOS44MS41NC40OTM2MSAx
 MjIuNzEuMzUuMjAxLjgwICAgRVNUQUJMSVNIRUQKZmZmZmZmMDE1OGQxMjAwMCB0Y3A0ICAg
 ICAgIDAgIDUyNTE1IDg5LjIwOS44MS41NC40NzQ0NyA5My44MC44NC45MC4zNDQzNSAgRVNU
 QUJMSVNIRUQKZmZmZmZmMDEyNTFiMTAwMCB0Y3A0ICAgICAgIDAgIDM0MzQ5IDg5LjIwOS44
 MS41NC40MzQxNCA5Mi4xMTUuMTUyLjE3Mi41NjcgRVNUQUJMSVNIRUQKZmZmZmZmMDA0ZmFh
 ZDZlMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC40MTU3OCA4My4yNDEuNS4y
 MjAuNTAwMDEgRklOX1dBSVRfMgpmZmZmZmYwMDRmZGVkMDAwIHRjcDQgICAgICAgMCAgICAg
 IDAgMTg4LjExNS4xMjguMy40MDc0IDkyLjExMy4xOTIuMTAuNDQ5NyBGSU5fV0FJVF8yCmZm
 ZmZmZjAxMjUxYTE2ZTAgdGNwNCAgICAgICAwICAgICAgMCAxODguMTE1LjEyOC4zLjM3MDkg
 NzguMzYuMjcuMTkwLjI5NjQ2IEVTVEFCTElTSEVECmZmZmZmZjAxMjUxNjJhNTAgdGNwNCAg
 ICAgICAwICAgNDE5NyA4OS4yMDkuODEuNTQuNjkzMyAgMTk0LjE4Ny4xMDUuMjIuMzc3IEVT
 VEFCTElTSEVECmZmZmZmZjAxMjUxOTEzNzAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDku
 ODEuNTQuMzEzMjIgOTQuNzUuNDUuMTk2LjYwNDMxIEVTVEFCTElTSEVECmZmZmZmZjAxMjRi
 MWMzNzAgdGNwNCAgICAgICAwICAgMTMyNyA4OS4yMDkuODEuNTQuMjk0NzEgOTUuNjcuMjEz
 LjE4Ni4xODM4IEVTVEFCTElTSEVECmZmZmZmZjAxMjUxOTg2ZTAgdGNwNCAgICAgICAwICA0
 NjQ1NyA4OS4yMDkuODEuNTQuMjkwMTMgMjEzLjE4Ny4xMTYuMjQyLjM4IEVTVEFCTElTSEVE
 CmZmZmZmZjAxMjUxOWY2ZTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuMjEx
 MDUgODMuMjQxLjUuMjIwLjUwMDAxIEZJTl9XQUlUXzIKZmZmZmZmMDE1MjQwYTAwMCB0Y3A0
 ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xNzIyMyA4OS4yNTEuMTQ1LjY5LjUwMDAg
 RklOX1dBSVRfMgpmZmZmZmYwMDRmZDdlYTUwIHRjcDQgICAgICAgMCAgNjc4MTQgODkuMjA5
 LjgxLjU0LjY5MzMgIDkyLjI0My4xODEuMzkuNDM0OCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1
 MGU2NmUwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5MzMgIDkxLjIwMC4x
 MzcuODAuMTk2MyBFU1RBQkxJU0hFRApmZmZmZmYwMDRmZDdlMDAwIHRjcDQgICAgICAgMCAg
 MzUyMjIgODkuMjA5LjgxLjU0LjY5MzMgIDE5NS45My4xNTUuMTIuMTA1MSBFU1RBQkxJU0hF
 RApmZmZmZmYwMTI1MGRkMzcwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjY5
 MzMgIDk1LjEzNS44MS4yMTQuMjg3MCBFU1RBQkxJU0hFRApmZmZmZmYwMDUyMDVjYTUwIHRj
 cDQgICAgICAgMCAgICAgIDAgMTg4LjExNS4xMjguMy41ODU0IDc4LjEwNi4zNS40NS41MTQx
 MyBGSU5fV0FJVF8yCmZmZmZmZjAxMjUxM2RhNTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4y
 MDkuODEuNTQuNTQwODggNzkuMTcxLjEyMS45OS4yMzAzIEZJTl9XQUlUXzIKZmZmZmZmMDEy
 NTBiYTM3MCB0Y3A0ICAgICAgIDAgIDIwMjc1IDg5LjIwOS44MS41NC42OTMzICA4OS4xMzMu
 MTYyLjU0LjEwNTYgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNGIyZTAwMCB0Y3A0ICAgICAgIDAg
 IDM3MDQ3IDg5LjIwOS44MS41NC41MTIzMCA5NS4xMzkuMjQ3Ljg0LjQ3MjkgRVNUQUJMSVNI
 RUQKZmZmZmZmMDEyNTBhYzZlMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42
 OTMzICA4NS4yMDIuMTEzLjQxLjUzMzUgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNGIyZjAwMCB0
 Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC41MDk2OSA3OS4xNjUuMTkwLjQuNTQw
 MTYgRklOX1dBSVRfMgpmZmZmZmYwMTI1MTVhYTUwIHRjcDQgICAgICAgMCAgIDI5MDkgODku
 MjA5LjgxLjU0LjQ5OTUxIDk1LjMyLjQ3LjE5NC4xNTU3MCBFU1RBQkxJU0hFRApmZmZmZmYw
 MDRmZWI1MzcwIHRjcDQgICAgICAgMCAgNDQzNjMgODkuMjA5LjgxLjU0LjY5MzMgIDkzLjE5
 Ny4xNDUuNzQuNDk1NyBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTVhNmUwIHRjcDQgICAgICAg
 MCAgICAgIDAgODkuMjA5LjgxLjU0LjM1MDcwIDgzLjI0MS41LjIyMC41MDAwMSBGSU5fV0FJ
 VF8yCmZmZmZmZjAxMjUxNmFhNTAgdGNwNCAgICAgICAwICAzNzg2OCA4OS4yMDkuODEuNTQu
 MzA4NDkgNzkuMTg1LjIyOS42OS42ODg2IEVTVEFCTElTSEVECmZmZmZmZjAxMjUwYmIzNzAg
 dGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAgOTEuMjAzLjgyLjY2LjE0
 MTc5IEVTVEFCTElTSEVECmZmZmZmZjAxMjRiMWRhNTAgdGNwNCAgICAgICAwICAgICAgMCA4
 OS4yMDkuODEuNTQuMjM4NjUgODUuMjM0LjE3NC40MS41NzYxIEZJTl9XQUlUXzIKZmZmZmZm
 MDEyNTEwOTM3MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xMzU3MiA4My45
 OS4xMzUuMTU4LjU1NDggRklOX1dBSVRfMgpmZmZmZmYwMTI1MWEwMzcwIHRjcDQgICAgICAg
 MCAgICAgIDAgMTg4LjExNS4xMjguMy4xMjMwIDkyLjExMy4xOTIuMTAuNDQ5NyBGSU5fV0FJ
 VF8yCmZmZmZmZjAxMTdlOGRhNTAgdGNwNCAgICAgICAwICAzMzU0MSA4OS4yMDkuODEuNTQu
 NjA5NjQgOTUuMzIuMTIzLjE1OS4yNDIzIEVTVEFCTElTSEVECmZmZmZmZjAxMjRiMjQ2ZTAg
 dGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNTUyODMgOTYuNDkuMTc3LjEzMy4x
 MzExIEZJTl9XQUlUXzIKZmZmZmZmMDEyNTBiYmE1MCB0Y3A0ICAgICAgIDAgIDcxNDczIDg5
 LjIwOS44MS41NC42OTMzICAyMTcuMTczLjIxLjUuNTc4NjEgRklOX1dBSVRfMQpmZmZmZmYw
 MTI1MTk4YTUwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjQxNTU3IDkwLjEz
 NC41Ni45NC40Mjc0OCBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTYxNmUwIHRjcDQgICAgICAg
 MCAgICAgIDAgODkuMjA5LjgxLjU0LjQwMDc5IDc3LjQ1LjIwMi4yMDcuMzI0NSBGSU5fV0FJ
 VF8yCmZmZmZmZjAxMjUwZjYzNzAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQu
 MzczNzAgMjEyLjE1Mi41MC4xNDAuMTU4IEZJTl9XQUlUXzIKZmZmZmZmMDEyNTE5YTAwMCB0
 Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42OTMzICA5NC43Ny4xNDUuMTk1LjI0
 NjQgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTExOGE1MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5
 LjIwOS44MS41NC42OTMzICA5NS4xMzUuMTAxLjEwLjcxMTUgRVNUQUJMSVNIRUQKZmZmZmZm
 MDEyNTFkODAwMCB0Y3A0ICAgICAgIDAgIDQwMjc5IDg5LjIwOS44MS41NC4yODk4MiA4NS4x
 NzUuNTQuMjQzLjE5NTkgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTEzNDAwMCB0Y3A0ICAgICAg
 IDAgICAgICAwIDg5LjIwOS44MS41NC4yNjAzMiA3OC4yOS45NC41OC4zMTgwNCAgRklOX1dB
 SVRfMgpmZmZmZmYwMTI1MTlhMzcwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0
 LjEwMDU0IDk5LjI0MC4yMTcuODguNDk2OSBGSU5fV0FJVF8yCmZmZmZmZjAxMjUwYzc2ZTAg
 dGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjQ0MDAgNzguMjkuOTQuNTguMzE4
 MDQgIEZJTl9XQUlUXzIKZmZmZmZmMDEyNTBkYzM3MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5
 LjIwOS44MS41NC42MDQ4NyA3Ny44Ny4xNzEuMTk1LjM1NjkgRklOX1dBSVRfMgpmZmZmZmYw
 MTI1MTIxYTUwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjQ4NTgyIDc4LjI5
 Ljk0LjU4LjMxODA0ICBGSU5fV0FJVF8yCmZmZmZmZjAxMjUwZDAwMDAgdGNwNCAgICAgICAw
 ICA1NzYzNiAxODguMTE1LjEyOC4zLjQ4MTMgNzguMzcuNDkuMjI2LjM3NDMyIEVTVEFCTElT
 SEVECmZmZmZmZjAxMjUxNmIzNzAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQu
 MjkyODIgNzguMjkuOTQuNTguMzE4MDQgIEZJTl9XQUlUXzIKZmZmZmZmMDEyNTEzM2E1MCB0
 Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42OTMzICA4MS44OC4xMjQuMTAyLjI4
 MzIgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNGIyNTM3MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5
 LjIwOS44MS41NC42OTMzICAyMTMuMjI3LjI0Ni4xNjIuMTEgRVNUQUJMSVNIRUQKZmZmZmZm
 MDA0ZmQ3ZDZlMCB0Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xMDA0MiA3OC4y
 OS45NC41OC4zMTgwNCAgRklOX1dBSVRfMgpmZmZmZmYwMTI1MWI3MzcwIHRjcDQgICAgICAg
 MCAgICAgIDAgODkuMjA5LjgxLjU0LjY0MjY0IDgwLjIzNy4xNC4yMDYuMzE5OSBGSU5fV0FJ
 VF8yCmZmZmZmZjAxMjUxYjI2ZTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQu
 NjEwOTggODAuMjM3LjE0LjIwNi4zMTk5IEZJTl9XQUlUXzIKZmZmZmZmMDEyNTEzZWE1MCB0
 Y3A0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC42MDUxNCA5NS4xNjEuNi4yLjMxMjM5
 ICAgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTEzNDM3MCB0Y3A0ICAgICAgIDAgICAgICAwIDg5
 LjIwOS44MS41NC40MjYzNCA3OC4yOS45NC41OC4zMTgwNCAgRklOX1dBSVRfMgpmZmZmZmYw
 MTI1MWM1MDAwIHRjcDQgICAgICAgMCAgMTYzOTcgODkuMjA5LjgxLjU0LjQyMzk2IDkzLjg4
 LjIxMi4xNi4zNTY5MSBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MGQxYTUwIHRjcDQgICAgICAg
 MCAgICAgIDAgODkuMjA5LjgxLjU0LjQxMDQ1IDk1LjI0LjIyMy4yMjcuMjcwNiBFU1RBQkxJ
 U0hFRApmZmZmZmYwMTI1MWQ3MzcwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0
 LjY5MzMgIDk0LjE3OC4yMjEuMjUyLjQxMyBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MGQ0YTUw
 IHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjM0MTcxIDk0LjE4MS4xMy4xOTUu
 NTE3NyBFU1RBQkxJU0hFRApmZmZmZmYwMTI1MTA3NmUwIHRjcDQgICAgICAgMCAgMjgxOTIg
 ODkuMjA5LjgxLjU0LjY5MzMgIDgwLjczLjE2Mi45MS40NDIzICBFU1RBQkxJU0hFRApmZmZm
 ZmYwMTI1MWJhMDAwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjMwNTA0IDc4
 LjI5Ljk0LjU4LjMxODA0ICBGSU5fV0FJVF8yCmZmZmZmZjAxMjUxZWE2ZTAgdGNwNCAgICAg
 ICAwICAgICAgMCA4OS4yMDkuODEuNTQuMzAzNzkgNzguMjkuOTQuNTguMzE4MDQgIEZJTl9X
 QUlUXzIKZmZmZmZmMDEyNTExODAwMCB0Y3A0ICAgICAgIDAgIDI3NzMzIDg5LjIwOS44MS41
 NC4yOTAzNyA5NC4xMzcuMjAwLjIzMS4yNzkgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTBhZTZl
 MCB0Y3A0ICAgICAgIDAgIDQyNDQwIDg5LjIwOS44MS41NC42OTMzICA5MS4xOTIuOTguMjMx
 LjM3NTIgRVNUQUJMSVNIRUQKZmZmZmZmMDA0ZmFhZDM3MCB0Y3A0ICAgICAgIDAgICAgICAw
 IDg5LjIwOS44MS41NC4yMDM0NSA5NC4xODAuMTYwLjEwOS4xMzIgRVNUQUJMSVNIRUQKZmZm
 ZmZmMDEyNTEzZjM3MCB0Y3A0ICAgICAgMTcgICAgICAwIDg5LjIwOS44MS41NC42OTMzICA3
 OS4xODAuMTQxLjEzMi40MjAgRVNUQUJMSVNIRUQKZmZmZmZmMDEyNTE1YmE1MCB0Y3A0ICAg
 ICAgIDAgICAgICAwIDEwLjAuMC4xLjMxMjggICAgICAqLiogICAgICAgICAgICAgICAgTElT
 VEVOCmZmZmZmZjAxMjUwZWU2ZTAgdGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQu
 MTUzNzkgOTEuMTIxLjE1My4zMi40OTE1IEVTVEFCTElTSEVECmZmZmZmZjAxMjUwZGNhNTAg
 dGNwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQuNjkzMyAgMTk0LjI0Mi4xMDAuMTAw
 LjUwIEVTVEFCTElTSEVECmZmZmZmZjAwNGZlYjYwMDAgdGNwNCAgICAgICAwICAgICAgMCAq
 LjY5MzMgICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIExJU1RFTgpmZmZmZmYwMDRm
 NDU4MzcwIHRjcDQgICAgICAgMCAgICAgIDAgKi41ODcgICAgICAgICAgICAgICouKiAgICAg
 ICAgICAgICAgICBMSVNURU4KZmZmZmZmMDA0ZjQ1ODZlMCB0Y3A2ICAgICAgIDAgICAgICAw
 ICouMjUgICAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgTElTVEVOCmZmZmZmZjAw
 NGY0NThhNTAgdGNwNCAgICAgICAwICAgICAgMCAqLjI1ICAgICAgICAgICAgICAgKi4qICAg
 ICAgICAgICAgICAgIExJU1RFTgpmZmZmZmYwMDA1YzMzNmUwIHRjcDQgICAgICAgMCAgICAg
 IDAgMTI3LjAuMC4xLjMzMDYgICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4KZmZmZmZm
 MDA0ZjQ1ODAwMCB0Y3A0ICAgICAgIDAgICAgICAwIDEyNy4wLjAuMS43ODMgICAgICAqLiog
 ICAgICAgICAgICAgICAgTElTVEVOCmZmZmZmZjAwMDVmZGUzNzAgdGNwNCAgICAgICAwICAg
 ICAgMCAqLjEwMDAwICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIExJU1RFTgpmZmZm
 ZmYwMDA1ZmRlMDAwIHRjcDQgICAgICAgMCAgICAgIDAgMTAuMC4wLjEuMTM5ICAgICAgICou
 KiAgICAgICAgICAgICAgICBMSVNURU4KZmZmZmZmMDAwNWI0NzM3MCB0Y3A0ICAgICAgIDAg
 ICAgICAwIDEwLjAuMC4xLjQ0NSAgICAgICAqLiogICAgICAgICAgICAgICAgTElTVEVOCmZm
 ZmZmZjAwMDVhYjNhNTAgdGNwNiAgICAgICAwICAgICAgMCAqLjk5NSAgICAgICAgICAgICAg
 Ki4qICAgICAgICAgICAgICAgIExJU1RFTgpmZmZmZmYwMDRmNDdlMDAwIHRjcDQgICAgICAg
 MCAgICAgIDAgKi45OTUgICAgICAgICAgICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4K
 ZmZmZmZmMDA0ZjQ3ZTM3MCB0Y3A2ICAgICAgIDAgICAgICAwICouMTEwICAgICAgICAgICAg
 ICAqLiogICAgICAgICAgICAgICAgTElTVEVOCmZmZmZmZjAwNGY0N2U2ZTAgdGNwNCAgICAg
 ICAwICAgICAgMCAqLjExMCAgICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIExJU1RF
 TgpmZmZmZmYwMDRmNDdlYTUwIHRjcDYgICAgICAgMCAgICAgIDAgKi45OTMgICAgICAgICAg
 ICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4KZmZmZmZmMDA0ZjRiZDAwMCB0Y3A0ICAg
 ICAgIDAgICAgICAwICouOTkzICAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgTElT
 VEVOCmZmZmZmZjAwNGY0YmQzNzAgdGNwNiAgICAgICAwICAgICAgMCAqLjE0MyAgICAgICAg
 ICAgICAgKi4qICAgICAgICAgICAgICAgIExJU1RFTgpmZmZmZmYwMDRmNGJkNmUwIHRjcDQg
 ICAgICAgMCAgICAgIDAgKi4xNDMgICAgICAgICAgICAgICouKiAgICAgICAgICAgICAgICBM
 SVNURU4KZmZmZmZmMDAwNWIzODZlMCB0Y3A0ICAgICAgIDAgICAgICAwIDEyNy4wLjAuMS45
 NTMgICAgICAqLiogICAgICAgICAgICAgICAgTElTVEVOCmZmZmZmZjAwMDVmZGU2ZTAgdGNw
 NCAgICAgICAwICAgICAgMCAxODguMTE1LjEyOC4zLjUzICAgKi4qICAgICAgICAgICAgICAg
 IExJU1RFTgpmZmZmZmYwMDA1ZmRlYTUwIHRjcDQgICAgICAgMCAgICAgIDAgODkuMjA5Ljgx
 LjU0LjUzICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4KZmZmZmZmMDAwNWFiMzAwMCB0
 Y3A0ICAgICAgIDAgICAgICAwIDEyNy4wLjAuMS41MyAgICAgICAqLiogICAgICAgICAgICAg
 ICAgTElTVEVOCmZmZmZmZjAwMDVhYjMzNzAgdGNwNiAgICAgICAwICAgICAgMCA6OjEuNTMg
 ICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIExJU1RFTgpmZmZmZmYwMDA1YWIzNmUw
 IHRjcDQgICAgICAgMCAgICAgIDAgMTkyLjE2OC42MC4xOTQuNTMgICouKiAgICAgICAgICAg
 ICAgICBMSVNURU4KZmZmZmZmMDAwNWI0NzZlMCB0Y3A0ICAgICAgIDAgICAgICAwIDEwLjAu
 MC4xLjUzICAgICAgICAqLiogICAgICAgICAgICAgICAgTElTVEVOCmZmZmZmZjAwMDU3ZWIw
 MDAgdGNwNCAgICAgICAwICAgICAgMCAqLjIxICAgICAgICAgICAgICAgKi4qICAgICAgICAg
 ICAgICAgIExJU1RFTgpmZmZmZmYwMDA1YjM4MzcwIHRjcDQgICAgICAgMCAgICAgIDAgKi42
 OTUwICAgICAgICAgICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4KZmZmZmZmMDAwNWI0
 N2E1MCB0Y3A0ICAgICAgIDAgICAgICAwICouNzQ1NiAgICAgICAgICAgICAqLiogICAgICAg
 ICAgICAgICAgTElTVEVOCmZmZmZmZjAwMDVjMzIwMDAgdGNwNCAgICAgICAwICAgICAgMCAq
 LjYxMTIgICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIExJU1RFTgpmZmZmZmYwMDA1
 YzMyMzcwIHRjcDQgICAgICAgMCAgICAgIDAgKi42OTkxICAgICAgICAgICAgICouKiAgICAg
 ICAgICAgICAgICBMSVNURU4KZmZmZmZmMDAwNWMzMjZlMCB0Y3A0ICAgICAgIDAgICAgICAw
 ICouMTUxMyAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgTElTVEVOCmZmZmZmZjAw
 MDVjMzJhNTAgdGNwNCAgICAgICAwICAgICAgMCAqLjYxMTMgICAgICAgICAgICAgKi4qICAg
 ICAgICAgICAgICAgIExJU1RFTgpmZmZmZmYwMDA1YzMzMDAwIHRjcDQgICAgICAgMCAgICAg
 IDAgKi42MjAwICAgICAgICAgICAgICouKiAgICAgICAgICAgICAgICBMSVNURU4KZmZmZmZm
 MDAwNWMzMzM3MCB0Y3A0ICAgICAgIDAgICAgICAwICouNjExMCAgICAgICAgICAgICAqLiog
 ICAgICAgICAgICAgICAgTElTVEVOCmZmZmZmZjAwMDU3ZWMwMDAgdGNwNCAgICAgICAwICAg
 ICAgMCAqLjI4MDIgICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIExJU1RFTgpmZmZm
 ZmYwMDA1N2ViNmUwIHRjcDQgICAgICAgMCAgICAgIDAgKi44MCAgICAgICAgICAgICAgICou
 KiAgICAgICAgICAgICAgICBMSVNURU4KZmZmZmZmMDAwNTdlY2E1MCB0Y3A0ICAgICAgIDAg
 ICAgICAwICouMjIgICAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgTElTVEVOCmZm
 ZmZmZjAwMDU3ZWMzNzAgdGNwNiAgICAgICAwICAgICAgMCAqLjIyICAgICAgICAgICAgICAg
 Ki4qICAgICAgICAgICAgICAgIExJU1RFTgpmZmZmZmYwMTI1Mjg1MDAwIHVkcDQgICAgICAg
 MCAgICAgIDAgKi4zNDAxICAgICAgICAgICAgICouKiAgICAgICAgICAgICAgICAKZmZmZmZm
 MDAwNTU2Y2JkMCB1ZHA0ICAgICAgIDAgICAgICAwICouMzExMTQgICAgICAgICAgICAqLiog
 ICAgICAgICAgICAgICAgCmZmZmZmZjAwMDU1NGY2OTAgdWRwNCAgICAgICAwICAgICAgMCAq
 LiogICAgICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIApmZmZmZmYwMDA1NTRlMmEw
 IHVkcDQgICAgICAgMCAgICAgIDAgMTI3LjAuMC4xLjQxMDYxICAgIDEyNy4wLjAuMS4xNjIg
 ICAgICAKZmZmZmZmMDAwNTdmZDdlMCB1ZHA0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41
 NC4xMDk0NCA4MS4xNzEuNzIuMTEuMzY1MyAgCmZmZmZmZjAwMDU1NGYxNTAgdWRwNiAgICAg
 ICAwICAgICAgMCAyMDAxOjVjMDoxNDAwOmI6LjEgKi4qICAgICAgICAgICAgICAgIApmZmZm
 ZmYwMDA1NTRmZDIwIHVkcDYgICAgICAgMCAgICAgIDAgMjAwMTo1YzA6MTUwMzozNC4xICou
 KiAgICAgICAgICAgICAgICAKZmZmZmZmMDAwNTU0ZTU0MCB1ZHA0ICAgICAgIDAgICAgICAw
 ICouMTAwMDAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZjAwMDU3Zjdk
 MjAgdWRwNCAgICAgICAwICAgICAgMCAxMC4wLjAuMS4xMzggICAgICAgKi4qICAgICAgICAg
 ICAgICAgIApmZmZmZmYwMDA1N2U3NjkwIHVkcDQgICAgICAgMCAgICAgIDAgMTAuMC4wLjEu
 MTM3ICAgICAgICouKiAgICAgICAgICAgICAgICAKZmZmZmZmMDAwNTdmZDY5MCB1ZHA0ICAg
 ICAgIDAgICAgICAwICouMTM4ICAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgCmZm
 ZmZmZjAwMDU3ZmQzZjAgdWRwNCAgICAxMDU2ICAgICAgMCAqLjEzNyAgICAgICAgICAgICAg
 Ki4qICAgICAgICAgICAgICAgIApmZmZmZmYwMDA1N2FiMmEwIHVkcDQgICAgICAgMCAgICAg
 IDAgMTg4LjExNS4xMjguMy4xMjMgICouKiAgICAgICAgICAgICAgICAKZmZmZmZmMDAwNTU0
 ZWE4MCB1ZHA0ICAgICAgIDAgICAgICAwIDg5LjIwOS44MS41NC4xMjMgICAqLiogICAgICAg
 ICAgICAgICAgCmZmZmZmZjAwMDU3ZTdkMjAgdWRwNCAgICAgICAwICAgICAgMCAxMjcuMC4w
 LjEuMTIzICAgICAgKi4qICAgICAgICAgICAgICAgIApmZmZmZmYwMDA1N2Y3MmEwIHVkcDYg
 ICAgICAgMCAgICAgIDAgOjoxLjEyMyAgICAgICAgICAgICouKiAgICAgICAgICAgICAgICAK
 ZmZmZmZmMDAwNTU0ZTY5MCB1ZHA2ICAgICAgIDAgICAgICAwIGZlODA6NDo6MS4xMjMgICAg
 ICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZjAwMDU3Zjc2OTAgdWRwNCAgICAgICAwICAg
 ICAgMCAxOTIuMTY4LjYwLjE5NC4xMjMgKi4qICAgICAgICAgICAgICAgIApmZmZmZmYwMDA1
 N2ZkYTgwIHVkcDQgICAgICAgMCAgICAgIDAgMTAuMC4wLjEuMTIzICAgICAgICouKiAgICAg
 ICAgICAgICAgICAKZmZmZmZmMDAwNTdkODdlMCB1ZHA2ICAgICAgIDAgICAgICAwICouMTIz
 ICAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZjAwMDU1NGZhODAgdWRw
 NCAgICAgICAwICAgICAgMCAqLjEyMyAgICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAg
 IApmZmZmZmYwMDA1N2Y3YmQwIHVkcDQgICAgICAgMCAgICAgIDAgODkuMjA5LjgxLjU0LjYx
 NzkxIDgxLjE3MS43Mi4xMS4zNjUzICAKZmZmZmZmMDAwNTdkOGE4MCB1ZHA0ICAgICAgIDAg
 ICAgICAwICouMTYxICAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZjAw
 MDU3ZjczZjAgdWRwNCAgICAgICAwICAgICAgMCAqLiogICAgICAgICAgICAgICAgKi4qICAg
 ICAgICAgICAgICAgIApmZmZmZmYwMDA1N2ZkOTMwIHVkcDQgICAgICAgMCAgICAgIDAgMTI3
 LjAuMC4xLjQ5NzY4ICAgIDEyNy4wLjAuMS4xNjIgICAgICAKZmZmZmZmMDAwNTU2YzY5MCB1
 ZHA0ICAgICAgIDAgICAgICAwIDE4OC4xMTUuMTI4LjMuNTMgICAqLiogICAgICAgICAgICAg
 ICAgCmZmZmZmZjAwMDU1NGU5MzAgdWRwNCAgICAgICAwICAgICAgMCA4OS4yMDkuODEuNTQu
 NTMgICAgKi4qICAgICAgICAgICAgICAgIApmZmZmZmYwMDA1NTZjMDAwIHVkcDQgICAgICAg
 MCAgICAgIDAgMTI3LjAuMC4xLjUzICAgICAgICouKiAgICAgICAgICAgICAgICAKZmZmZmZm
 MDAwNTdkODkzMCB1ZHA2ICAgICAgIDAgICAgICAwIDo6MS41MyAgICAgICAgICAgICAqLiog
 ICAgICAgICAgICAgICAgCmZmZmZmZjAwMDU3YWIzZjAgdWRwNCAgICAgICAwICAgICAgMCAx
 OTIuMTY4LjYwLjE5NC41MyAgKi4qICAgICAgICAgICAgICAgIApmZmZmZmYwMDA1NTZjZDIw
 IHVkcDQgICAgICAgMCAgICAgIDAgMTAuMC4wLjEuNTMgICAgICAgICouKiAgICAgICAgICAg
 ICAgICAKZmZmZmZmMDAwNTdkODE1MCB1ZHA0ICAgICAgIDAgICAgICAwIDEyNy4wLjAuMS40
 OTQzMSAgICAxMjcuMC4wLjEuOTk5OSAgICAgCmZmZmZmZjAwMDU1NGVkMjAgdWRwNCAgICAg
 ICAwICAgICAgMCAqLjUxNCAgICAgICAgICAgICAgKi4qICAgICAgICAgICAgICAgIApmZmZm
 ZmYwMDA1NTRlYmQwIHVkcDYgICAgICAgMCAgICAgIDAgKi41MTQgICAgICAgICAgICAgICou
 KiAgICAgICAgICAgICAgICAKZmZmZmZmMDAwNTZjZDAwMCBkaXY0ICAgICAgIDAgICAgICAw
 ICouODY2OCAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgCmZmZmZmZjAwMDU2Y2Yw
 MDAgaWNtNCAgICAgICAwICAgICAgMCAqLiogICAgICAgICAgICAgICAgKi4qICAgICAgICAg
 ICAgICAgIApmZmZmZmYwMDA1NmNmNjkwIGljbTYgICAgICA5MiAgICAgIDAgKi4qICAgICAg
 ICAgICAgICAgICouKiAgICAgICAgICAgICAgICAKZmZmZmZmMDAwNTZjZTkzMCBpY202ICAg
 ICAgIDAgICAgICAwICouKiAgICAgICAgICAgICAgICAqLiogICAgICAgICAgICAgICAgCmZm
 ZmZmZjAwMDU2Y2U3ZTAgaWNtNiAgICAgICAwICAgICAgMCAqLiogICAgICAgICAgICAgICAg
 Ki4qICAgICAgICAgICAgICAgIApBY3RpdmUgVU5JWCBkb21haW4gc29ja2V0cwpBZGRyZXNz
 ICBUeXBlICAgUmVjdi1RIFNlbmQtUSAgICBJbm9kZSAgICAgQ29ubiAgICAgUmVmcyAgTmV4
 dHJlZiBBZGRyCmZmZmZmZjAwNGZjYjAwMDAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAg
 IDAgZmZmZmZmMDA0ZmY2ZDFlMCAgICAgICAgMCAgICAgICAgMApmZmZmZmYwMDRmZjZkMWUw
 IHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAwNGZjYjAwMDAgICAgICAg
 IDAgICAgICAgIDAKZmZmZmZmMDA0ZjdiOGE1MCBzdHJlYW0gICAgICAwICAgICAgMCAgICAg
 ICAgMCBmZmZmZmYwMDAzZWE3YTUwICAgICAgICAwICAgICAgICAwIC92YXIvcnVuL2RvdmVj
 b3QvbG9naW4vZGVmYXVsdApmZmZmZmYwMDAzZWE3YTUwIHN0cmVhbSAgICAgIDAgICAgICAw
 ICAgICAgICAwIGZmZmZmZjAwNGY3YjhhNTAgICAgICAgIDAgICAgICAgIDAKZmZmZmZmMDA0
 ZmNiMGI0MCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYwMDRmY2EzNzgw
 ICAgICAgICAwICAgICAgICAwCmZmZmZmZjAwNGZjYTM3ODAgc3RyZWFtICAgICAgMCAgICAg
 IDAgICAgICAgIDAgZmZmZmZmMDA0ZmNiMGI0MCAgICAgICAgMCAgICAgICAgMApmZmZmZmYw
 MDRmY2EzMGYwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAxN2I4MjI1
 YTAgICAgICAgIDAgICAgICAgIDAKZmZmZmZmMDE3YjgyMjVhMCBzdHJlYW0gICAgICAwICAg
 ICAgMCAgICAgICAgMCBmZmZmZmYwMDRmY2EzMGYwICAgICAgICAwICAgICAgICAwCmZmZmZm
 ZjAwMDNlN2NkMjAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZmMDA0ZmNh
 Mzg3MCAgICAgICAgMCAgICAgICAgMApmZmZmZmYwMDRmY2EzODcwIHN0cmVhbSAgICAgIDAg
 ICAgICAwICAgICAgICAwIGZmZmZmZjAwMDNlN2NkMjAgICAgICAgIDAgICAgICAgIDAKZmZm
 ZmZmMDA0ZmY2ZDVhMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYwMDRm
 Y2EzYTUwICAgICAgICAwICAgICAgICAwIC90bXAvbXlzcWwuc29jawpmZmZmZmYwMDRmY2Ez
 YTUwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAwNGZmNmQ1YTAgICAg
 ICAgIDAgICAgICAgIDAKZmZmZmZmMDA0ZmNhMzAwMCBzdHJlYW0gICAgICAwICAgICAgMCAg
 ICAgICAgMCBmZmZmZmYwMDRmY2IwNjkwICAgICAgICAwICAgICAgICAwCmZmZmZmZjAwNGZj
 YjA2OTAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZmMDA0ZmNhMzAwMCAg
 ICAgICAgMCAgICAgICAgMApmZmZmZmYwMDRmY2IwMWUwIHN0cmVhbSAgICAgIDAgICAgICAw
 ICAgICAgICAwIGZmZmZmZjAxN2I4MjIwMDAgICAgICAgIDAgICAgICAgIDAKZmZmZmZmMDE3
 YjgyMjAwMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYwMDRmY2IwMWUw
 ICAgICAgICAwICAgICAgICAwCmZmZmZmZjAxNjg4OTk1YTAgc3RyZWFtICAgICAgMCAgICAg
 IDAgICAgICAgIDAgZmZmZmZmMDA0ZmNhMzVhMCAgICAgICAgMCAgICAgICAgMApmZmZmZmYw
 MDRmY2EzNWEwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAxNjg4OTk1
 YTAgICAgICAgIDAgICAgICAgIDAKZmZmZmZmMDA0ZmNhMzFlMCBzdHJlYW0gICAgICAwICAg
 ICAgMCAgICAgICAgMCBmZmZmZmYwMGE3NjRmYTUwICAgICAgICAwICAgICAgICAwCmZmZmZm
 ZjAwYTc2NGZhNTAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZmMDA0ZmNh
 MzFlMCAgICAgICAgMCAgICAgICAgMApmZmZmZmYwMTdiODIyNjkwIHN0cmVhbSAgICAgIDAg
 ICAgICAwICAgICAgICAwIGZmZmZmZjAxN2I4MjI3ODAgICAgICAgIDAgICAgICAgIDAKZmZm
 ZmZmMDE3YjgyMjc4MCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYwMTdi
 ODIyNjkwICAgICAgICAwICAgICAgICAwCmZmZmZmZjAwYTc2NGY4NzAgc3RyZWFtICAgICAg
 MCAgICAgIDAgICAgICAgIDAgZmZmZmZmMDA0ZmY2YzBmMCAgICAgICAgMCAgICAgICAgMCAv
 dmFyL3J1bi9kb3ZlY290L2xvZ2luL2RlZmF1bHQKZmZmZmZmMDA0ZmY2YzBmMCBzdHJlYW0g
 ICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYwMGE3NjRmODcwICAgICAgICAwICAgICAg
 ICAwCmZmZmZmZjAwNGZjYjA3ODAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZm
 ZmZmMDAwNTRmMDc4MCAgICAgICAgMCAgICAgICAgMApmZmZmZmYwMDA1NGYwNzgwIHN0cmVh
 bSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAwNGZjYjA3ODAgICAgICAgIDAgICAg
 ICAgIDAKZmZmZmZmMDA0ZmY2YzJkMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBm
 ZmZmZmYwMDRmY2IwMGYwICAgICAgICAwICAgICAgICAwCmZmZmZmZjAwNGZjYjAwZjAgc3Ry
 ZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZmMDA0ZmY2YzJkMCAgICAgICAgMCAg
 ICAgICAgMApmZmZmZmYwMDRmY2EzOTYwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAw
 IGZmZmZmZjAwNGZmNmQ4NzAgICAgICAgIDAgICAgICAgIDAKZmZmZmZmMDA0ZmY2ZDg3MCBz
 dHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYwMDRmY2EzOTYwICAgICAgICAw
 ICAgICAgICAwCmZmZmZmZjAxN2I4MjI4NzAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAg
 IDAgZmZmZmZmMDE2ODg5OTAwMCAgICAgICAgMCAgICAgICAgMCAvdG1wL215c3FsLnNvY2sK
 ZmZmZmZmMDE2ODg5OTAwMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYw
 MTdiODIyODcwICAgICAgICAwICAgICAgICAwCmZmZmZmZjAwNGZmNmRlMTAgc3RyZWFtICAg
 ICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZmMDAwNTRmMDRiMCAgICAgICAgMCAgICAgICAg
 MCAvdG1wL215c3FsLnNvY2sKZmZmZmZmMDAwNTRmMDRiMCBzdHJlYW0gICAgICAwICAgICAg
 MCAgICAgICAgMCBmZmZmZmYwMDRmZjZkZTEwICAgICAgICAwICAgICAgICAwCmZmZmZmZjAw
 MDU0ZjA4NzAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZmMDA0ZmY2Yzc4
 MCAgICAgICAgMCAgICAgICAgMCAvdG1wL215c3FsLnNvY2sKZmZmZmZmMDA0ZmY2Yzc4MCBz
 dHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYwMDA1NGYwODcwICAgICAgICAw
 ICAgICAgICAwCmZmZmZmZjAxN2I4MjIxZTAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAg
 IDAgZmZmZmZmMDA0ZjU1M2MzMCAgICAgICAgMCAgICAgICAgMCAvdG1wL215c3FsLnNvY2sK
 ZmZmZmZmMDA0ZjU1M2MzMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYw
 MTdiODIyMWUwICAgICAgICAwICAgICAgICAwCmZmZmZmZjAwYTc2NGZlMTAgc3RyZWFtICAg
 ICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZmMDA0ZmNiMGQyMCAgICAgICAgMCAgICAgICAg
 MCAvdG1wL215c3FsLnNvY2sKZmZmZmZmMDA0ZmNiMGQyMCBzdHJlYW0gICAgICAwICAgICAg
 MCAgICAgICAgMCBmZmZmZmYwMGE3NjRmZTEwICAgICAgICAwICAgICAgICAwCmZmZmZmZjAw
 YTc2NGYzYzAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZmMDA0ZmY2ZGMz
 MCAgICAgICAgMCAgICAgICAgMApmZmZmZmYwMDRmZjZkYzMwIHN0cmVhbSAgICAgIDAgICAg
 ICAwICAgICAgICAwIGZmZmZmZjAwYTc2NGYzYzAgICAgICAgIDAgICAgICAgIDAKZmZmZmZm
 MDA0ZmY2YzRiMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYwMDRmNTUz
 NjkwICAgICAgICAwICAgICAgICAwCmZmZmZmZjAwNGY1NTM2OTAgc3RyZWFtICAgICAgMCAg
 ICAgIDAgICAgICAgIDAgZmZmZmZmMDA0ZmY2YzRiMCAgICAgICAgMCAgICAgICAgMApmZmZm
 ZmYwMDRmN2I4NGIwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAwNGY3
 YjgwMDAgICAgICAgIDAgICAgICAgIDAKZmZmZmZmMDA0ZjdiODAwMCBzdHJlYW0gICAgICAw
 ICAgICAgMCAgICAgICAgMCBmZmZmZmYwMDRmN2I4NGIwICAgICAgICAwICAgICAgICAwCmZm
 ZmZmZjAwNGY3YjhiNDAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZmMDA0
 ZjU3NDAwMCAgICAgICAgMCAgICAgICAgMCAvdG1wL215c3FsLnNvY2sKZmZmZmZmMDA0ZjU3
 NDAwMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYwMDRmN2I4YjQwICAg
 ICAgICAwICAgICAgICAwCmZmZmZmZjAwNGZmNmM4NzAgc3RyZWFtICAgICAgMCAgICAgIDAg
 ICAgICAgIDAgZmZmZmZmMDA0ZmY2Yzk2MCAgICAgICAgMCAgICAgICAgMCAvdG1wL215c3Fs
 LnNvY2sKZmZmZmZmMDA0ZmY2Yzk2MCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBm
 ZmZmZmYwMDRmZjZjODcwICAgICAgICAwICAgICAgICAwCmZmZmZmZjAwNGZmNmNhNTAgc3Ry
 ZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZmMDA0ZmY2Y2I0MCAgICAgICAgMCAg
 ICAgICAgMCAvdG1wL215c3FsLnNvY2sKZmZmZmZmMDA0ZmY2Y2I0MCBzdHJlYW0gICAgICAw
 ICAgICAgMCAgICAgICAgMCBmZmZmZmYwMDRmZjZjYTUwICAgICAgICAwICAgICAgICAwCmZm
 ZmZmZjAwNGY3YjgzYzAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZmMDA0
 ZjdiODJkMCAgICAgICAgMCAgICAgICAgMCAvdG1wL215c3FsLnNvY2sKZmZmZmZmMDA0Zjdi
 ODJkMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYwMDRmN2I4M2MwICAg
 ICAgICAwICAgICAgICAwCmZmZmZmZjAwNGY1NzRkMjAgc3RyZWFtICAgICAgMCAgICAgIDAg
 ZmZmZmZmMDA0ZmQ2ODNiMCAgICAgICAgMCAgICAgICAgMCAgICAgICAgMCAvdmFyL3J1bi9z
 bm1wZC5zb2NrCmZmZmZmZjAwNGY1NTM3ODAgc3RyZWFtICAgICAgMCAgICAgIDAgZmZmZmZm
 MDA0ZmFiNmNlOCAgICAgICAgMCAgICAgICAgMCAgICAgICAgMCAvdmFyL3J1bi9jbGFtYXYv
 Y2xtaWx0ZXIuc29jawpmZmZmZmYwMDRmN2I4ODcwIHN0cmVhbSAgICAgIDAgICAgICAwIGZm
 ZmZmZjAwNGZhYjFjZTggICAgICAgIDAgICAgICAgIDAgICAgICAgIDAgL3Zhci9ydW4vY2xh
 bWF2L2NsYW1kLnNvY2sKZmZmZmZmMDA0ZjdiODc4MCBzdHJlYW0gICAgICAwICAgICAgMCAg
 ICAgICAgMCBmZmZmZmYwMDRmN2I4NjkwICAgICAgICAwICAgICAgICAwCmZmZmZmZjAwNGY3
 Yjg2OTAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZmMDA0ZjdiODc4MCAg
 ICAgICAgMCAgICAgICAgMApmZmZmZmYwMDRmNTUzZTEwIHN0cmVhbSAgICAgIDAgICAgICAw
 ICAgICAgICAwIGZmZmZmZjAwNGY1NTNkMjAgICAgICAgIDAgICAgICAgIDAKZmZmZmZmMDA0
 ZjU1M2QyMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYwMDRmNTUzZTEw
 ICAgICAgICAwICAgICAgICAwCmZmZmZmZjAwNGY1NzRlMTAgc3RyZWFtICAgICAgMCAgICAg
 IDAgZmZmZmZmMDA0ZjllYzNiMCAgICAgICAgMCAgICAgICAgMCAgICAgICAgMCAvdG1wL215
 c3FsLnNvY2sKZmZmZmZmMDA0ZjdiOGMzMCBzdHJlYW0gICAgICAwICAgICAgMCBmZmZmZmYw
 MDRmNzVjM2IwICAgICAgICAwICAgICAgICAwICAgICAgICAwIC92YXIvcnVuL3Nhc2xhdXRo
 ZC9tdXgKZmZmZmZmMDA0ZjU3NDJkMCBzdHJlYW0gICAgICAwICAgICAgMCBmZmZmZmYwMDRm
 NzU3MWQ4ICAgICAgICAwICAgICAgICAwICAgICAgICAwIC92YXIvcnVuL3NwYW1hc3MtbWls
 dGVyLnNvY2sKZmZmZmZmMDA0ZjU3NDVhMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAg
 MCBmZmZmZmYwMDRmNTc0NjkwICAgICAgICAwICAgICAgICAwIC92YXIvcnVuL2RvdmVjb3Qv
 bG9naW4vZGVmYXVsdApmZmZmZmYwMDRmNTc0NjkwIHN0cmVhbSAgICAgIDAgICAgICAwICAg
 ICAgICAwIGZmZmZmZjAwNGY1NzQ1YTAgICAgICAgIDAgICAgICAgIDAKZmZmZmZmMDA0ZjU3
 NDc4MCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYwMDRmNTc0ODcwICAg
 ICAgICAwICAgICAgICAwIC92YXIvcnVuL2RvdmVjb3QvbG9naW4vZGVmYXVsdApmZmZmZmYw
 MDRmNTc0ODcwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAwNGY1NzQ3
 ODAgICAgICAgIDAgICAgICAgIDAKZmZmZmZmMDAwM2U3Yzc4MCBzdHJlYW0gICAgICAwICAg
 ICAgMCAgICAgICAgMCBmZmZmZmYwMDAzZTdjODcwICAgICAgICAwICAgICAgICAwIC92YXIv
 cnVuL2RvdmVjb3QvbG9naW4vZGVmYXVsdApmZmZmZmYwMDAzZTdjODcwIHN0cmVhbSAgICAg
 IDAgICAgICAwICAgICAgICAwIGZmZmZmZjAwMDNlN2M3ODAgICAgICAgIDAgICAgICAgIDAK
 ZmZmZmZmMDAwM2VhNzJkMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYw
 MDAzZTdjMGYwICAgICAgICAwICAgICAgICAwIC92YXIvcnVuL2RvdmVjb3QvbG9naW4vZGVm
 YXVsdApmZmZmZmYwMDAzZTdjMGYwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZm
 ZmZmZjAwMDNlYTcyZDAgICAgICAgIDAgICAgICAgIDAKZmZmZmZmMDA0ZjU1MzFlMCBzdHJl
 YW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYwMDRmNTUzMmQwICAgICAgICAwICAg
 ICAgICAwCmZmZmZmZjAwNGY1NTMyZDAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAg
 ZmZmZmZmMDA0ZjU1MzFlMCAgICAgICAgMCAgICAgICAgMApmZmZmZmYwMDRmNTUzM2MwIHN0
 cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAwNGY1NTM0YjAgICAgICAgIDAg
 ICAgICAgIDAKZmZmZmZmMDA0ZjU1MzRiMCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAg
 MCBmZmZmZmYwMDRmNTUzM2MwICAgICAgICAwICAgICAgICAwCmZmZmZmZjAwMDU0ZjAwMDAg
 c3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZmMDAwM2VhNzk2MCAgICAgICAg
 MCAgICAgICAgMApmZmZmZmYwMDAzZWE3OTYwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAg
 ICAwIGZmZmZmZjAwMDU0ZjAwMDAgICAgICAgIDAgICAgICAgIDAKZmZmZmZmMDAwM2VhNzBm
 MCBzdHJlYW0gICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYwMDAzZWE3MWUwICAgICAg
 ICAwICAgICAgICAwCmZmZmZmZjAwMDNlYTcxZTAgc3RyZWFtICAgICAgMCAgICAgIDAgICAg
 ICAgIDAgZmZmZmZmMDAwM2VhNzBmMCAgICAgICAgMCAgICAgICAgMApmZmZmZmYwMDAzZWE3
 MDAwIHN0cmVhbSAgICAgIDAgICAgICAwIGZmZmZmZjAwNGY0MDJiMTAgICAgICAgIDAgICAg
 ICAgIDAgICAgICAgIDAgL3Zhci9ydW4vZG92ZWNvdC9hdXRoLXdvcmtlci4yNTUzCmZmZmZm
 ZjAwMDU0ZjBlMTAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZmMDAwM2Vh
 NzY5MCAgICAgICAgMCAgICAgICAgMApmZmZmZmYwMDAzZWE3NjkwIHN0cmVhbSAgICAgIDAg
 ICAgICAwICAgICAgICAwIGZmZmZmZjAwMDU0ZjBlMTAgICAgICAgIDAgICAgICAgIDAKZmZm
 ZmZmMDAwM2VhNzc4MCBzdHJlYW0gICAgICAwICAgICAgMCBmZmZmZmYwMDRmNDAyY2U4ICAg
 ICAgICAwICAgICAgICAwICAgICAgICAwIC92YXIvcnVuL2RvdmVjb3QvbG9naW4vZGVmYXVs
 dApmZmZmZmYwMDAzZWE3ZDIwIHN0cmVhbSAgICAgIDAgICAgICAwIGZmZmZmZjAwNGY0OGIw
 MDAgICAgICAgIDAgICAgICAgIDAgICAgICAgIDAgL3Zhci9ydW4vZG92ZWNvdC9kaWN0LXNl
 cnZlcgpmZmZmZmYwMDA1NGYwYzMwIHN0cmVhbSAgICAgIDAgICAgICAwICAgICAgICAwIGZm
 ZmZmZjAwMDNlYTc1YTAgICAgICAgIDAgICAgICAgIDAgL3Zhci9ydW4vZGV2ZC5waXBlCmZm
 ZmZmZjAwMDNlYTc1YTAgc3RyZWFtICAgICAgMCAgICAgIDAgICAgICAgIDAgZmZmZmZmMDAw
 NTRmMGMzMCAgICAgICAgMCAgICAgICAgMApmZmZmZmYwMDAzZWE3YzMwIHN0cmVhbSAgICAg
 IDAgICAgICAwIGZmZmZmZjAwMDVkNDEzYjAgICAgICAgIDAgICAgICAgIDAgICAgICAgIDAg
 L3Zhci9ydW4vc25tcGQuc29jawpmZmZmZmYwMDA1NGYwYTUwIHN0cmVhbSAgICAgIDAgICAg
 ICAwIGZmZmZmZjAwMDVkYTgwMDAgICAgICAgIDAgICAgICAgIDAgICAgICAgIDAgL3Zhci9y
 dW4vcHJvZnRwZC9wcm9mdHBkLnNvY2sKZmZmZmZmMDAwM2VhNzg3MCBzdHJlYW0gICAgICAw
 ICAgICAgMCBmZmZmZmYwMDA1NTRkNzYwICAgICAgICAwICAgICAgICAwICAgICAgICAwIC92
 YXIvcnVuL2RldmQucGlwZQpmZmZmZmYwMDRmY2EzMmQwIGRncmFtICAgICAgIDAgICAgICAw
 ICAgICAgICAwIGZmZmZmZjAwMDU0ZjAwZjAgICAgICAgIDAgZmZmZmZmMDA0ZjU3NGMzMApm
 ZmZmZmYwMDRmNTc0YzMwIGRncmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAw
 MDU0ZjAwZjAgICAgICAgIDAgZmZmZmZmMDA0ZjU1Mzk2MApmZmZmZmYwMDAzZTdjM2MwIGRn
 cmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAwMDU0ZjAyZDAgICAgICAgIDAg
 ZmZmZmZmMDA0ZjdiODk2MApmZmZmZmYwMDRmNTUzOTYwIGRncmFtICAgICAgIDAgICAgICAw
 ICAgICAgICAwIGZmZmZmZjAwMDU0ZjAwZjAgICAgICAgIDAgZmZmZmZmMDA0ZjU1MzVhMApm
 ZmZmZmYwMDRmNTUzNWEwIGRncmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAw
 MDU0ZjAwZjAgICAgICAgIDAgZmZmZmZmMDA0ZjdiODVhMApmZmZmZmYwMDRmN2I4NWEwIGRn
 cmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAwMDU0ZjAwZjAgICAgICAgIDAg
 ZmZmZmZmMDA0ZjU1M2E1MApmZmZmZmYwMDRmNTUzYTUwIGRncmFtICAgICAgIDAgICAgICAw
 ICAgICAgICAwIGZmZmZmZjAwMDU0ZjAwZjAgICAgICAgIDAgZmZmZmZmMDA0ZjdiOGQyMApm
 ZmZmZmYwMDRmN2I4OTYwIGRncmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAw
 MDU0ZjAyZDAgICAgICAgIDAgZmZmZmZmMDAwM2U3YzJkMApmZmZmZmYwMDRmN2I4ZDIwIGRn
 cmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAwMDU0ZjAwZjAgICAgICAgIDAg
 ZmZmZmZmMDA0ZjU3NDFlMApmZmZmZmYwMDRmNTc0MWUwIGRncmFtICAgICAgIDAgICAgICAw
 ICAgICAgICAwIGZmZmZmZjAwMDU0ZjAwZjAgICAgICAgIDAgZmZmZmZmMDAwM2U3Y2MzMApm
 ZmZmZmYwMDAzZTdjMmQwIGRncmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAw
 MDU0ZjAyZDAgICAgICAgIDAgZmZmZmZmMDAwNTRmMDk2MApmZmZmZmYwMDAzZTdjYzMwIGRn
 cmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAwMDU0ZjAwZjAgICAgICAgIDAg
 ZmZmZmZmMDAwM2U3YzRiMApmZmZmZmYwMDAzZTdjNGIwIGRncmFtICAgICAgIDAgICAgICAw
 ICAgICAgICAwIGZmZmZmZjAwMDU0ZjAwZjAgICAgICAgIDAgZmZmZmZmMDA0ZjU3NDRiMApm
 ZmZmZmYwMDRmNTc0NGIwIGRncmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAw
 MDU0ZjAwZjAgICAgICAgIDAgZmZmZmZmMDAwM2VhN2UxMApmZmZmZmYwMDA1NGYwOTYwIGRn
 cmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAwMDU0ZjAyZDAgICAgICAgIDAg
 ZmZmZmZmMDAwM2U3YzFlMApmZmZmZmYwMDAzZWE3ZTEwIGRncmFtICAgICAgIDAgICAgICAw
 ICAgICAgICAwIGZmZmZmZjAwMDU0ZjAwZjAgICAgICAgIDAgZmZmZmZmMDAwM2VhNzRiMApm
 ZmZmZmYwMDAzZWE3NGIwIGRncmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAw
 MDU0ZjAwZjAgICAgICAgIDAgZmZmZmZmMDAwM2VhNzNjMApmZmZmZmYwMDAzZWE3M2MwIGRn
 cmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAwMDU0ZjAwZjAgICAgICAgIDAg
 ZmZmZmZmMDAwNTRmMGI0MApmZmZmZmYwMDA1NGYwYjQwIGRncmFtICAgICAgIDAgICAgICAw
 ICAgICAgICAwIGZmZmZmZjAwMDU0ZjAwZjAgICAgICAgIDAgZmZmZmZmMDAwM2VhN2I0MApm
 ZmZmZmYwMDAzZWE3YjQwIGRncmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAw
 MDU0ZjAwZjAgICAgICAgIDAgZmZmZmZmMDAwNTRmMGQyMApmZmZmZmYwMDAzZTdjMWUwIGRn
 cmFtICAgICAgIDAgICAgICAwICAgICAgICAwIGZmZmZmZjAwMDU0ZjAyZDAgICAgICAgIDAg
 ICAgICAgIDAKZmZmZmZmMDAwNTRmMGQyMCBkZ3JhbSAgICAgICAwICAgICAgMCAgICAgICAg
 MCBmZmZmZmYwMDA1NGYwMGYwICAgICAgICAwIGZmZmZmZjAwMDU0ZjA2OTAKZmZmZmZmMDAw
 NTRmMDY5MCBkZ3JhbSAgICAgICAwICAgICAgMCAgICAgICAgMCBmZmZmZmYwMDA1NGYwMGYw
 ICAgICAgICAwICAgICAgICAwCmZmZmZmZjAwMDU0ZjAzYzAgZGdyYW0gICAgICAgMCAgICAg
 IDAgZmZmZmZmMDAwNTY5MjU4OCAgICAgICAgMCAgICAgICAgMCAgICAgICAgMCAvdmFyL25h
 bWVkL3Zhci9ydW4vbG9nCmZmZmZmZjAwMDU0ZjAyZDAgZGdyYW0gICAgICAgMCAgICAgIDAg
 ZmZmZmZmMDAwNTY5ZTc2MCAgICAgICAgMCBmZmZmZmYwMDAzZTdjM2MwICAgICAgICAwIC92
 YXIvcnVuL2xvZwpmZmZmZmYwMDA1NGYwMGYwIGRncmFtICAgICAgIDAgICAgICAwIGZmZmZm
 ZjAwMDU2OWU5MzggICAgICAgIDAgZmZmZmZmMDA0ZmNhMzJkMCAgICAgICAgMCAvdmFyL3J1
 bi9sb2dwcml2CmZmZmZmZjAwMDU0ZjAxZTAgZGdyYW0gICAgICAgMCAgICAgIDAgZmZmZmZm
 MDAwNTY5ZWIxMCAgICAgICAgMCAgICAgICAgMCAgICAgICAgMCAvdmFyL3J1bi9sb2cKCi0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLQpuZXRzdGF0IC1hTAoKQ3VycmVudCBsaXN0ZW4gcXVldWUgc2l6
 ZXMgKHFsZW4vaW5jcWxlbi9tYXhxbGVuKQpQcm90byBMaXN0ZW4gICAgICAgICBMb2NhbCBB
 ZGRyZXNzICAgICAgICAgCnRjcDQgIDAvMC8yMDQ4ICAgICAgIG90cmFkYS5sb2NhbC4zMTI4
 ICAgICAgCnRjcDQgIDEvMC81MCAgICAgICAgICouNjkzMyAgICAgICAgICAgICAgICAgCnRj
 cDQgIDAvMC8xMCAgICAgICAgICouc3VibWlzc2lvbiAgICAgICAgICAgCnRjcDYgIDAvMC8x
 MCAgICAgICAgICouc210cCAgICAgICAgICAgICAgICAgCnRjcDQgIDAvMC8xMCAgICAgICAg
 ICouc210cCAgICAgICAgICAgICAgICAgCnRjcDQgIDAvMC81MCAgICAgICAgIGxvY2FsaG9z
 dC4zMzA2ICAgICAgICAgCnRjcDQgIDAvMC8xMjggICAgICAgIGxvY2FsaG9zdC43ODMgICAg
 ICAgICAgCnRjcDQgIDAvMC8xMjggICAgICAgICouMTAwMDAgICAgICAgICAgICAgICAgCnRj
 cDQgIDAvMC81MCAgICAgICAgIG90cmFkYS5sb2NhbC5uZXRiaW9zLXMgCnRjcDQgIDAvMC81
 MCAgICAgICAgIG90cmFkYS5sb2NhbC5taWNyb3NvZnQgCnRjcDYgIDAvMC8xMjggICAgICAg
 ICoucG9wM3MgICAgICAgICAgICAgICAgCnRjcDQgIDAvMC8xMjggICAgICAgICoucG9wM3Mg
 ICAgICAgICAgICAgICAgCnRjcDYgIDAvMC8xMjggICAgICAgICoucG9wMyAgICAgICAgICAg
 ICAgICAgCnRjcDQgIDAvMC8xMjggICAgICAgICoucG9wMyAgICAgICAgICAgICAgICAgCnRj
 cDYgIDAvMC8xMjggICAgICAgICouaW1hcHMgICAgICAgICAgICAgICAgCnRjcDQgIDAvMC8x
 MjggICAgICAgICouaW1hcHMgICAgICAgICAgICAgICAgCnRjcDYgIDAvMC8xMjggICAgICAg
 ICouaW1hcCAgICAgICAgICAgICAgICAgCnRjcDQgIDAvMC8xMjggICAgICAgICouaW1hcCAg
 ICAgICAgICAgICAgICAgCnRjcDQgIDAvMC8xMjggICAgICAgIGxvY2FsaG9zdC5ybmRjICAg
 ICAgICAgCnRjcDQgIDAvMC8zICAgICAgICAgIDE4OC0xMTUtMTI4LTMuYnIuZG9tYWkgCnRj
 cDQgIDAvMC8zICAgICAgICAgIG90cmFkYS5vZC51YS5kb21haW4gICAgCnRjcDQgIDAvMC8z
 ICAgICAgICAgIGxvY2FsaG9zdC5kb21haW4gICAgICAgCnRjcDYgIDAvMC8zICAgICAgICAg
 IGxvY2FsaG9zdC5kb21haW4gICAgICAgCnRjcDQgIDAvMC8zICAgICAgICAgIDE5Mi4xNjgu
 NjAuMTk0LmRvbWFpbiAgCnRjcDQgIDAvMC8zICAgICAgICAgIG90cmFkYS5sb2NhbC5kb21h
 aW4gICAgCnRjcDQgIDAvMC81ICAgICAgICAgICouZnRwICAgICAgICAgICAgICAgICAgCnRj
 cDQgIDAvMC8zICAgICAgICAgICouNjk1MCAgICAgICAgICAgICAgICAgCnRjcDQgIDAvMC8z
 ICAgICAgICAgICouNzQ1NiAgICAgICAgICAgICAgICAgCnRjcDQgIDAvMC8zICAgICAgICAg
 ICouNjExMiAgICAgICAgICAgICAgICAgCnRjcDQgIDAvMC8zICAgICAgICAgICouNjk5MSAg
 ICAgICAgICAgICAgICAgCnRjcDQgIDAvMC8zICAgICAgICAgICouZnVqaXRzdS1kdGMgICAg
 ICAgICAgCnRjcDQgIDAvMC8zICAgICAgICAgICouNjExMyAgICAgICAgICAgICAgICAgCnRj
 cDQgIDAvMC8zICAgICAgICAgICouNjIwMCAgICAgICAgICAgICAgICAgCnRjcDQgIDAvMC8z
 ICAgICAgICAgICouc29mdGNtICAgICAgICAgICAgICAgCnRjcDQgIDAvMC8zICAgICAgICAg
 ICouMjgwMiAgICAgICAgICAgICAgICAgCnRjcDQgIDAvMC81MTEgICAgICAgICouaHR0cCAg
 ICAgICAgICAgICAgICAgCnRjcDQgIDAvMC8xMjggICAgICAgICouc3NoICAgICAgICAgICAg
 ICAgICAgCnRjcDYgIDAvMC8xMjggICAgICAgICouc3NoICAgICAgICAgICAgICAgICAgCnVu
 aXggIDAvMC8xMCAgICAgICAgIC92YXIvcnVuL3NubXBkLnNvY2sKdW5peCAgMC8wLzIwNDgg
 ICAgICAgL3Zhci9ydW4vY2xhbWF2L2NsbWlsdGVyLnNvY2sKdW5peCAgMC8wLzE1ICAgICAg
 ICAgL3Zhci9ydW4vY2xhbWF2L2NsYW1kLnNvY2sKdW5peCAgMC8wLzUwICAgICAgICAgL3Rt
 cC9teXNxbC5zb2NrCnVuaXggIDAvMC8zMiAgICAgICAgIC92YXIvcnVuL3Nhc2xhdXRoZC9t
 dXgKdW5peCAgMC8wLzIwNDggICAgICAgL3Zhci9ydW4vc3BhbWFzcy1taWx0ZXIuc29jawp1
 bml4ICAwLzAvMTI4ICAgICAgICAvdmFyL3J1bi9kb3ZlY290L2F1dGgtd29ya2VyLjI1NTMK
 dW5peCAgMC8wLzEyOCAgICAgICAgL3Zhci9ydW4vZG92ZWNvdC9sb2dpbi9kZWZhdWx0CnVu
 aXggIDAvMC8xMjggICAgICAgIC92YXIvcnVuL2RvdmVjb3QvZGljdC1zZXJ2ZXIKdW5peCAg
 MC8wLzEwICAgICAgICAgL3Zhci9ydW4vc25tcGQuc29jawp1bml4ICAwLzAvNSAgICAgICAg
 ICAvdmFyL3J1bi9wcm9mdHBkL3Byb2Z0cGQuc29jawp1bml4ICAwLzAvNCAgICAgICAgICAv
 dmFyL3J1bi9kZXZkLnBpcGUKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpmc3RhdAoKU2VnbWVudGF0
 aW9uIGZhdWx0CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KZG1lc2cKCmFsIEFCSSBzdXBwb3J0Ogov
 ZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogc3lzdmlwY19lbmFibGUgaXMgc2V0IHRvIE5P
 LgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogbGludXhfZW5hYmxlIGlzIHNldCB0byBZ
 RVMuCiBsaW51eAovZXRjL3JjOiBJTkZPOiBsaW51eCBrZXJuZWwgbW9kdWxlIGxvYWRlZC4K
 L2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IHN2cjRfZW5hYmxlIGlzIHNldCB0byBOTy4K
 LgovZXRjL3JjOiBERUJVRzogcGlkIGZpbGUgKC92YXIvcnVuL25hbWVkLnBpZCk6IG5vdCBy
 ZWFkYWJsZS4KL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IG5hbWVkX2VuYWJsZSBpcyBz
 ZXQgdG8gWUVTLgovZXRjL3JjOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6IHN0YXJ0X3ByZWNt
 ZDogbmFtZWRfcHJlY21kIAovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogbmFtZWRfY2hy
 b290X2F1dG91cGRhdGUgaXMgc2V0IHRvIFlFUy4KL2V0Yy9yYzogREVCVUc6IGRldmZzX2Rv
 bW91bnQoKTogbW91bnQtcG9pbnQgaXMgKC92YXIvbmFtZWQvZGV2KSwgcnVsZXNldCBpcyAo
 ZGV2ZnNydWxlc19oaWRlX2FsbCkKL2V0Yy9yYzogREVCVUc6IHJlYWRpbmcgcnVsZXNldHMg
 ZnJvbSBmaWxlICgvZXRjL2RlZmF1bHRzL2RldmZzLnJ1bGVzKQovZXRjL3JjOiBERUJVRzog
 Zm91bmQgcnVsZXNldDogZGV2ZnNydWxlc19oaWRlX2FsbD0xCi9ldGMvcmM6IERFQlVHOiBh
 ZGRpbmcgcnVsZSAoYWRkIGhpZGUpCi9ldGMvcmM6IERFQlVHOiBmb3VuZCBydWxlc2V0OiBk
 ZXZmc3J1bGVzX3VuaGlkZV9iYXNpYz0yCi9ldGMvcmM6IERFQlVHOiBhZGRpbmcgcnVsZSAo
 YWRkIHBhdGggbnVsbCB1bmhpZGUpCi9ldGMvcmM6IERFQlVHOiBhZGRpbmcgcnVsZSAoYWRk
 IHBhdGggemVybyB1bmhpZGUpCi9ldGMvcmM6IERFQlVHOiBhZGRpbmcgcnVsZSAoYWRkIHBh
 dGggY3J5cHRvIHVuaGlkZSkKL2V0Yy9yYzogREVCVUc6IGFkZGluZyBydWxlIChhZGQgcGF0
 aCByYW5kb20gdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBwYXRo
 IHVyYW5kb20gdW5oaWRlKQovZXRjL3JjOiBERUJVRzogZm91bmQgcnVsZXNldDogZGV2ZnNy
 dWxlc191bmhpZGVfbG9naW49MwovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBw
 YXRoICdwdHlwKicgdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBw
 YXRoICdwdHlxKicgdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBw
 YXRoICdwdHlyKicgdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBw
 YXRoICdwdHlzKicgdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBw
 YXRoICdwdHlQKicgdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBw
 YXRoICdwdHlRKicgdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBw
 YXRoICdwdHlSKicgdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBw
 YXRoICdwdHlTKicgdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBw
 YXRoICd0dHlwKicgdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBw
 YXRoICd0dHlxKicgdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBw
 YXRoICd0dHlyKicgdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBw
 YXRoICd0dHlzKicgdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBw
 YXRoICd0dHlQKicgdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBw
 YXRoICd0dHlRKicgdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBw
 YXRoICd0dHlSKicgdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBw
 YXRoICd0dHlTKicgdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBw
 YXRoIHB0bXggdW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBwYXRo
 IHB0cyB1bmhpZGUpCi9ldGMvcmM6IERFQlVHOiBhZGRpbmcgcnVsZSAoYWRkIHBhdGggJ3B0
 cy8qJyB1bmhpZGUpCi9ldGMvcmM6IERFQlVHOiBhZGRpbmcgcnVsZSAoYWRkIHBhdGggZmQg
 dW5oaWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBwYXRoICdmZC8qJyB1
 bmhpZGUpCi9ldGMvcmM6IERFQlVHOiBhZGRpbmcgcnVsZSAoYWRkIHBhdGggc3RkaW4gdW5o
 aWRlKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBwYXRoIHN0ZG91dCB1bmhp
 ZGUpCi9ldGMvcmM6IERFQlVHOiBhZGRpbmcgcnVsZSAoYWRkIHBhdGggc3RkZXJyIHVuaGlk
 ZSkKL2V0Yy9yYzogREVCVUc6IGZvdW5kIHJ1bGVzZXQ6IGRldmZzcnVsZXNfamFpbD00Ci9l
 dGMvcmM6IERFQlVHOiBhZGRpbmcgcnVsZSAoYWRkIGluY2x1ZGUgJGRldmZzcnVsZXNfaGlk
 ZV9hbGwpCi9ldGMvcmM6IERFQlVHOiBhZGRpbmcgcnVsZSAoYWRkIGluY2x1ZGUgJGRldmZz
 cnVsZXNfdW5oaWRlX2Jhc2ljKQovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1bGUgKGFkZCBp
 bmNsdWRlICRkZXZmc3J1bGVzX3VuaGlkZV9sb2dpbikKL2V0Yy9yYzogREVCVUc6IHJlYWRp
 bmcgcnVsZXNldHMgZnJvbSBmaWxlICgvZXRjL2RldmZzLnJ1bGVzKQovZXRjL3JjOiBERUJV
 RzogZm91bmQgcnVsZXNldDogbnV0X3VzYj0xMAovZXRjL3JjOiBERUJVRzogYWRkaW5nIHJ1
 bGUgKGFkZCBwYXRoICd1Z2VuMCcgZ3JvdXAgd2hlZWwgdXNlciB1dWNwIG1vZGUgMDY2MCkK
 L2V0Yy9yYzogREVCVUc6IGFkZGluZyBydWxlIChhZGQgcGF0aCAndWhpZDAnIGdyb3VwIHdo
 ZWVsIHVzZXIgdXVjcCBtb2RlIDA2NjApCi9ldGMvcmM6IERFQlVHOiBkZXZmc19pbml0X3J1
 bGVzZXRzOiBkZXZmcyBydWxlc2V0cyBpbml0aWFsaXplZAovZXRjL3JjOiBERUJVRzogZGV2
 ZnNfc2V0X3J1bGVzZXQ6IHNldHRpbmcgcnVsZXNldCAoMSkgb24gbW91bnQtcG9pbnQgKC92
 YXIvbmFtZWQvZGV2KQovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogbmFtZWRfYXV0b19m
 b3J3YXJkIGlzIHNldCB0byBOTy4KL2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBk
 b2l0OiAvdXNyL3NiaW4vbmFtZWQgLWMgL2V0Yy9uYW1lZGIvbmFtZWQuY29uZiAtdCAvdmFy
 L25hbWVkIC11IGJpbmQKcmUwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKU2VwIDEzIDAz
 OjQ0OjA1IG1hcnktdGVyZXNhIG5hbWVkWzE1NzddOiB0aGUgd29ya2luZyBkaXJlY3Rvcnkg
 aXMgbm90IHdyaXRhYmxlCi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFuZDogc3RhcnRf
 cG9zdGNtZDogbmFtZWRfcG9zdHN0YXJ0IAovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzog
 bmFtZWRfc3ltbGlua19lbmFibGUgaXMgc2V0IHRvIFlFUy4KL2V0Yy9yYzogREVCVUc6IGNo
 ZWNreWVzbm86IG5hbWVkX3dhaXQgaXMgc2V0IHRvIE5PLgovZXRjL3JjOiBERUJVRzogY2hl
 Y2t5ZXNubzogbnRwZGF0ZV9lbmFibGUgaXMgc2V0IHRvIFlFUy4KL2V0Yy9yYzogREVCVUc6
 IHJ1bl9yY19jb21tYW5kOiBkb2l0OiBudHBkYXRlX3N0YXJ0IApTZXR0aW5nIGRhdGUgdmlh
 IG50cC4KRXJyb3IgOiBob3N0bmFtZSBub3Igc2Vydm5hbWUgcHJvdmlkZWQsIG9yIG5vdCBr
 bm93bgoxMyBTZXAgMDM6NDQ6MDYgCm50cGRhdGVbMTU5NV06IGNhbid0IGZpbmQgaG9zdCBl
 dXJvcGUucG9vbC5udHAub3JnCgpFcnJvciA6IGhvc3RuYW1lIG5vciBzZXJ2bmFtZSBwcm92
 aWRlZCwgb3Igbm90IGtub3duCjEzIFNlcCAwMzo0NDowNiAKbnRwZGF0ZVsxNTk1XTogY2Fu
 J3QgZmluZCBob3N0IGV1cm9wZS5wb29sLm50cC5vcmcKCkVycm9yIDogaG9zdG5hbWUgbm9y
 IHNlcnZuYW1lIHByb3ZpZGVkLCBvciBub3Qga25vd24KMTMgU2VwIDAzOjQ0OjA2IApudHBk
 YXRlWzE1OTVdOiBjYW4ndCBmaW5kIGhvc3QgZXVyb3BlLnBvb2wubnRwLm9yZwoKRXJyb3Ig
 OiBob3N0bmFtZSBub3Igc2Vydm5hbWUgcHJvdmlkZWQsIG9yIG5vdCBrbm93bgoxMyBTZXAg
 MDM6NDQ6MDYgCm50cGRhdGVbMTU5NV06IGNhbid0IGZpbmQgaG9zdCBtb250cGVsaWVyLmls
 YW4uY2FsdGVjaC5lZHUKCkVycm9yIDogaG9zdG5hbWUgbm9yIHNlcnZuYW1lIHByb3ZpZGVk
 LCBvciBub3Qga25vd24KMTMgU2VwIDAzOjQ0OjA2IApudHBkYXRlWzE1OTVdOiBjYW4ndCBm
 aW5kIGhvc3QgY2xvY2sudmlhLm5ldAoKRXJyb3IgOiBob3N0bmFtZSBub3Igc2Vydm5hbWUg
 cHJvdmlkZWQsIG9yIG5vdCBrbm93bgoxMyBTZXAgMDM6NDQ6MDYgCm50cGRhdGVbMTU5NV06
 IGNhbid0IGZpbmQgaG9zdCB2ZWdhLmNiay5wb3puYW4ucGwKCkVycm9yIDogaG9zdG5hbWUg
 bm9yIHNlcnZuYW1lIHByb3ZpZGVkLCBvciBub3Qga25vd24KMTMgU2VwIDAzOjQ0OjA2IApu
 dHBkYXRlWzE1OTVdOiBjYW4ndCBmaW5kIGhvc3QgdGltZS1BLnRpbWVmcmVxLmJsZHJkb2Mu
 Z292CgpFcnJvciA6IGhvc3RuYW1lIG5vciBzZXJ2bmFtZSBwcm92aWRlZCwgb3Igbm90IGtu
 b3duCjEzIFNlcCAwMzo0NDowNiAKbnRwZGF0ZVsxNTk1XTogY2FuJ3QgZmluZCBob3N0IG50
 cC5uYXNhLmdvdgoKRXJyb3IgOiBob3N0bmFtZSBub3Igc2Vydm5hbWUgcHJvdmlkZWQsIG9y
 IG5vdCBrbm93bgoxMyBTZXAgMDM6NDQ6MDYgCm50cGRhdGVbMTU5NV06IGNhbid0IGZpbmQg
 aG9zdCBwb29sLm50cC5vcmcKCkVycm9yIDogaG9zdG5hbWUgbm9yIHNlcnZuYW1lIHByb3Zp
 ZGVkLCBvciBub3Qga25vd24KMTMgU2VwIDAzOjQ0OjA2IApudHBkYXRlWzE1OTVdOiBjYW4n
 dCBmaW5kIGhvc3QgY2xvY2sucmVkaGF0LmNvbQoKRXJyb3IgOiBob3N0bmFtZSBub3Igc2Vy
 dm5hbWUgcHJvdmlkZWQsIG9yIG5vdCBrbm93bgoxMyBTZXAgMDM6NDQ6MDYgCm50cGRhdGVb
 MTU5NV06IGNhbid0IGZpbmQgaG9zdCBjbG9jazMucmVkaGF0LmNvbQoKRXJyb3IgOiBob3N0
 bmFtZSBub3Igc2Vydm5hbWUgcHJvdmlkZWQsIG9yIG5vdCBrbm93bgoxMyBTZXAgMDM6NDQ6
 MDYgCm50cGRhdGVbMTU5NV06IGNhbid0IGZpbmQgaG9zdCBudHAwLmxpbngubmV0CgpFcnJv
 ciA6IGhvc3RuYW1lIG5vciBzZXJ2bmFtZSBwcm92aWRlZCwgb3Igbm90IGtub3duCjEzIFNl
 cCAwMzo0NDowNiAKbnRwZGF0ZVsxNTk1XTogY2FuJ3QgZmluZCBob3N0IG50cC50aW1lLmlu
 LnVhCgpFcnJvciA6IGhvc3RuYW1lIG5vciBzZXJ2bmFtZSBwcm92aWRlZCwgb3Igbm90IGtu
 b3duCjEzIFNlcCAwMzo0NDowNiAKbnRwZGF0ZVsxNTk1XTogY2FuJ3QgZmluZCBob3N0IDAu
 ZnJlZWJzZC5wb29sLm50cC5vcmcKCkVycm9yIDogaG9zdG5hbWUgbm9yIHNlcnZuYW1lIHBy
 b3ZpZGVkLCBvciBub3Qga25vd24KMTMgU2VwIDAzOjQ0OjA2IApudHBkYXRlWzE1OTVdOiBj
 YW4ndCBmaW5kIGhvc3QgMS5mcmVlYnNkLnBvb2wubnRwLm9yZwoKRXJyb3IgOiBob3N0bmFt
 ZSBub3Igc2Vydm5hbWUgcHJvdmlkZWQsIG9yIG5vdCBrbm93bgoxMyBTZXAgMDM6NDQ6MDYg
 Cm50cGRhdGVbMTU5NV06IGNhbid0IGZpbmQgaG9zdCAyLmZyZWVic2QucG9vbC5udHAub3Jn
 CgpFcnJvciA6IGhvc3RuYW1lIG5vciBzZXJ2bmFtZSBwcm92aWRlZCwgb3Igbm90IGtub3du
 CjEzIFNlcCAwMzo0NDowNiAKbnRwZGF0ZVsxNTk1XTogY2FuJ3QgZmluZCBob3N0IG50cC5j
 b2xvY2FsbC5uZXQKCkVycm9yIDogaG9zdG5hbWUgbm9yIHNlcnZuYW1lIHByb3ZpZGVkLCBv
 ciBub3Qga25vd24KMTMgU2VwIDAzOjQ0OjA2IApudHBkYXRlWzE1OTVdOiBjYW4ndCBmaW5k
 IGhvc3QgYnVya2EuY2Fycmllci5raWV2LnVhCgpFcnJvciA6IGhvc3RuYW1lIG5vciBzZXJ2
 bmFtZSBwcm92aWRlZCwgb3Igbm90IGtub3duCjEzIFNlcCAwMzo0NDowNiAKbnRwZGF0ZVsx
 NTk1XTogY2FuJ3QgZmluZCBob3N0IHVhLnBvb2wubnRwLm9yZwoKRXJyb3IgOiBob3N0bmFt
 ZSBub3Igc2Vydm5hbWUgcHJvdmlkZWQsIG9yIG5vdCBrbm93bgoxMyBTZXAgMDM6NDQ6MDYg
 Cm50cGRhdGVbMTU5NV06IGNhbid0IGZpbmQgaG9zdCBudHAyLnRpbWUuaW4udWEKCkVycm9y
 IDogaG9zdG5hbWUgbm9yIHNlcnZuYW1lIHByb3ZpZGVkLCBvciBub3Qga25vd24KMTMgU2Vw
 IDAzOjQ0OjA2IApudHBkYXRlWzE1OTVdOiBjYW4ndCBmaW5kIGhvc3QgbnMyLmluZm9taXIu
 Y29tLnVhCgpFcnJvciA6IGhvc3RuYW1lIG5vciBzZXJ2bmFtZSBwcm92aWRlZCwgb3Igbm90
 IGtub3duCjEzIFNlcCAwMzo0NDowNiAKbnRwZGF0ZVsxNTk1XTogY2FuJ3QgZmluZCBob3N0
 IHRpbWU2LmlwdjYudW5pLW11ZW5zdGVyLmRlCgpFcnJvciA6IGhvc3RuYW1lIG5vciBzZXJ2
 bmFtZSBwcm92aWRlZCwgb3Igbm90IGtub3duCjEzIFNlcCAwMzo0NDowNiAKbnRwZGF0ZVsx
 NTk1XTogY2FuJ3QgZmluZCBob3N0IG50cC5yaHJrLnVuaS1rbC5kZQoKMTMgU2VwIDAzOjQ0
 OjA2IApudHBkYXRlWzE1OTVdOiBubyBzZXJ2ZXJzIGNhbiBiZSB1c2VkLCBleGl0aW5nCi9l
 dGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBycGNiaW5kX2VuYWJsZSBpcyBzZXQgdG8gTk8u
 Ci9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBuZnNfY2xpZW50X2VuYWJsZSBpcyBzZXQg
 dG8gWUVTLgovZXRjL3JjOiBERUJVRzogbG9hZF9rbGQ6IG5mc2NsaWVudCBrZXJuZWwgbW9k
 dWxlIGFscmVhZHkgbG9hZGVkLgovZXRjL3JjOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6IGRv
 aXQ6IG5mc2NsaWVudF9zdGFydCAKL2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBk
 b2l0OiBuaXNkb21haW5fc3RhcnQgCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBuaXNf
 c2VydmVyX2VuYWJsZSBpcyBzZXQgdG8gTk8uCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25v
 OiBuaXNfY2xpZW50X2VuYWJsZSBpcyBzZXQgdG8gTk8uCi9ldGMvcmM6IERFQlVHOiBjaGVj
 a3llc25vOiBuaXNfeXBzZXRfZW5hYmxlIGlzIHNldCB0byBOTy4KL2V0Yy9yYzogREVCVUc6
 IGNoZWNreWVzbm86IGFtZF9lbmFibGUgaXMgc2V0IHRvIE5PLgovZXRjL3JjOiBERUJVRzog
 Y2hlY2t5ZXNubzogYXRtX2VuYWJsZSBpcyBzZXQgdG8gTk8uCi9ldGMvcmM6IERFQlVHOiBj
 aGVja3llc25vOiBhdWRpdGRfZW5hYmxlIGlzIHNldCB0byBOTy4KL2V0Yy9yYzogREVCVUc6
 IHJ1bl9yY19jb21tYW5kOiBkb2l0OiBjbGVhcnRtcF9zdGFydCAKL2V0Yy9yYzogREVCVUc6
 IGNoZWNreWVzbm86IGNsZWFyX3RtcF9lbmFibGUgaXMgc2V0IHRvIE5PLgovZXRjL3JjOiBE
 RUJVRzogY2hlY2t5ZXNubzogY2xlYXJfdG1wX1ggaXMgc2V0IHRvIFlFUy4KL2V0Yy9yYzog
 REVCVUc6IGNoZWNreWVzbm86IGNsZWFyX3RtcF9YIGlzIHNldCB0byBZRVMuCi9ldGMvcmM6
 IERFQlVHOiBjaGVja3llc25vOiBkbWVzZ19lbmFibGUgaXMgc2V0IHRvIFlFUy4KL2V0Yy9y
 YzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBkb2l0OiBkb19kbWVzZyAKL2V0Yy9yYzogREVC
 VUc6IGNoZWNreWVzbm86IGlweHJvdXRlZF9lbmFibGUgaXMgc2V0IHRvIE5PLgovZXRjL3Jj
 OiBERUJVRzogY2hlY2t5ZXNubzoga2VyYmVyb3M1X3NlcnZlcl9lbmFibGUgaXMgc2V0IHRv
 IE5PLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzoga2FkbWluZDVfc2VydmVyX2VuYWJs
 ZSBpcyBzZXQgdG8gTk8uCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBrZXlzZXJ2X2Vu
 YWJsZSBpcyBzZXQgdG8gTk8uCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBrcGFzc3dk
 ZF9zZXJ2ZXJfZW5hYmxlIGlzIHNldCB0byBOTy4KL2V0Yy9yYzogREVCVUc6IGNoZWNreWVz
 bm86IG5mc3VzZXJkX2VuYWJsZSBpcyBzZXQgdG8gTk8uCi9ldGMvcmM6IERFQlVHOiBjaGVj
 a3llc25vOiBnc3NkX2VuYWJsZSBpcyBzZXQgdG8gTk8uCi9ldGMvcmM6IERFQlVHOiBjaGVj
 a3llc25vOiBxdW90YV9lbmFibGUgaXMgc2V0IHRvIE5PLgovZXRjL3JjOiBERUJVRzogY2hl
 Y2t5ZXNubzogbmZzX3NlcnZlcl9lbmFibGUgaXMgc2V0IHRvIE5PLgovZXRjL3JjOiBERUJV
 RzogcGlkIGZpbGUgKC92YXIvcnVuL21vdW50ZC5waWQpOiBub3QgcmVhZGFibGUuCi9ldGMv
 cmM6IERFQlVHOiBjaGVja3llc25vOiBtb3VudGRfZW5hYmxlIGlzIHNldCB0byBOTy4KL2V0
 Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IG5mc19zZXJ2ZXJfZW5hYmxlIGlzIHNldCB0byBO
 Ty4KL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IHJwY19zdGF0ZF9lbmFibGUgaXMgc2V0
 IHRvIE5PLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogcnBjX2xvY2tkX2VuYWJsZSBp
 cyBzZXQgdG8gTk8uCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBycGNfc3RhdGRfZW5h
 YmxlIGlzIHNldCB0byBOTy4KL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IHJwY19sb2Nr
 ZF9lbmFibGUgaXMgc2V0IHRvIE5PLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogcHBw
 b2VkX2VuYWJsZSBpcyBzZXQgdG8gTk8uCi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFu
 ZDogZG9pdDogcHdjaGVja19zdGFydCAKL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IHZp
 cmVjb3Zlcl9lbmFibGUgaXMgc2V0IHRvIFlFUy4KL2V0Yy9yYzogREVCVUc6IHJ1bl9yY19j
 b21tYW5kOiBkb2l0OiB2aXJlY292ZXJfc3RhcnQgCi9ldGMvcmM6IERFQlVHOiBwaWQgZmls
 ZSAoL3Zhci9ydW4vbW9uaXQucGlkKTogbm90IHJlYWRhYmxlLgovZXRjL3JjOiBERUJVRzog
 Y2hlY2t5ZXNubzogbW9uaXRfZW5hYmxlIGlzIHNldCB0byBZRVMuCi9ldGMvcmM6IERFQlVH
 OiBydW5fcmNfY29tbWFuZDogZG9pdDogL3Vzci9sb2NhbC9iaW4vbW9uaXQgIC1jIC91c3Iv
 bG9jYWwvZXRjL21vbml0cmMKU3RhcnRpbmcgbW9uaXQgZGFlbW9uCi9ldGMvcmM6IERFQlVH
 OiBwaWQgZmlsZSAoL3Zhci9ydW4vbXBkNS5waWQpOiBub3QgcmVhZGFibGUuCi9ldGMvcmM6
 IERFQlVHOiBjaGVja3llc25vOiBtcGRfZW5hYmxlIGlzIHNldCB0byBOTy4KL2V0Yy9yYzog
 REVCVUc6IGNoZWNreWVzbm86IGFwbV9lbmFibGUgaXMgc2V0IHRvIE5PLgovZXRjL3JjOiBE
 RUJVRzogY2hlY2t5ZXNubzogYXBtZF9lbmFibGUgaXMgc2V0IHRvIE5PLgovZXRjL3JjOiBE
 RUJVRzogY2hlY2t5ZXNubzogYm9vdHBhcmFtZF9lbmFibGUgaXMgc2V0IHRvIE5PLgovZXRj
 L3JjOiBERUJVRzogcGlkIGZpbGUgKC92YXIvcnVuL2hjc2VjZC5waWQpOiBub3QgcmVhZGFi
 bGUuCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBoY3NlY2RfZW5hYmxlIGlzIHNldCB0
 byBOTy4KL2V0Yy9yYzogREVCVUc6IHBpZCBmaWxlICgvdmFyL3J1bi9idGhpZGQucGlkKTog
 bm90IHJlYWRhYmxlLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogYnRoaWRkX2VuYWJs
 ZSBpcyBzZXQgdG8gTk8uCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBjYWNoZWRfZW5h
 YmxlIGlzIHNldCB0byBOTy4KL2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBkb2l0
 OiBsb2NhbF9zdGFydCAKU3RhcnRpbmcgbG9jYWwgZGFlbW9uczoKREhDUFJFUVVFU1Qgb24g
 dnIxIHRvIDI1NS4yNTUuMjU1LjI1NSBwb3J0IDY3CgpESENQQUNLIGZyb20gMTkyLjE2OC42
 MC4xCgpib3VuZCB0byAxOTIuMTY4LjYwLjE5NCAtLSByZW5ld2FsIGluIDU0MDAgc2Vjb25k
 cy4KCkxvYWRpbmcgL2xpYi9saWJhbGlhc19jdXNlZW1lLnNvCkxvYWRpbmcgL2xpYi9saWJh
 bGlhc19mdHAuc28KTG9hZGluZyAvbGliL2xpYmFsaWFzX2lyYy5zbwpMb2FkaW5nIC9saWIv
 bGliYWxpYXNfbmJ0LnNvCkxvYWRpbmcgL2xpYi9saWJhbGlhc19wcHRwLnNvCkxvYWRpbmcg
 L2xpYi9saWJhbGlhc19za2lubnkuc28KTG9hZGluZyAvbGliL2xpYmFsaWFzX3NtZWRpYS5z
 bwpuYXRkOiAKVW5hYmxlIHRvIGJpbmQgZGl2ZXJ0IHNvY2tldC4KOiAKQWRkcmVzcyBhbHJl
 YWR5IGluIHVzZQp0dW4xOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKdHVuMjogbGluayBz
 dGF0ZSBjaGFuZ2VkIHRvIFVQClNlcCAxMyAwMzo0NDoxMCBwb3J0ZndkWzIwMTNdOiBsaW5l
 ICAgIDIsIHRva2VuICAyNjIgJzsnClNlcCAxMyAwMzo0NDoxMCBwb3J0ZndkWzIwMTNdOiBs
 aW5lICAgIDMsIHRva2VuICAyNTggJzI4MDInClNlcCAxMyAwMzo0NDoxMCBwb3J0ZndkWzIw
 MTNdOiBsaW5lICAgIDMsIHRva2VuICAyNjYgJ3snClNlcCAxMyAwMzo0NDoxMCBwb3J0Zndk
 WzIwMTNdOiBsaW5lICAgIDMsIHRva2VuICAyNjggJz0+JwpTZXAgMTMgMDM6NDQ6MTAgcG9y
 dGZ3ZFsyMDEzXTogbGluZSAgICAzLCB0b2tlbiAgMjU4ICcxMC4wLjAuMTAnClNlcCAxMyAw
 Mzo0NDoxMCBwb3J0ZndkWzIwMTNdOiBsaW5lICAgIDMsIHRva2VuICAyNjEgJzonClNlcCAx
 MyAwMzo0NDoxMCBwb3J0ZndkWzIwMTNdOiBsaW5lICAgIDMsIHRva2VuICAyNTggJzI4MDIn
 ClNlcCAxMyAwMzo0NDoxMCBwb3J0ZndkWzIwMTNdOiBsaW5lICAgIDMsIHRva2VuICAyNjcg
 J30nClNlcCAxMyAwMzo0NDoxMCBwb3J0ZndkWzIwMTNdOiBsaW5lICAgIDMsIHRva2VuICAy
 NjIgJzsnClNlcCAxMyAwMzo0NDoxMCBwb3J0ZndkWzIwMTNdOiBsaW5lICAgIDQsIHRva2Vu
 ICAyNTggJzY5OTEnClNlcCAxMyAwMzo0NDoxMCBwb3J0ZndkWzIwMTNdOiBsaW5lICAgIDQs
 IHRva2VuICAyNjYgJ3snClNlcCAxMyAwMzo0NDoxMCBwb3J0ZndkWzIwMTNdOiBsaW5lICAg
 IDQsIHRva2VuICAyNjggJz0+JwpTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogbGlu
 ZSAgICA0LCB0b2tlbiAgMjU4ICcxMC4wLjAuMicKU2VwIDEzIDAzOjQ0OjEwIHBvcnRmd2Rb
 MjAxM106IGxpbmUgICAgNCwgdG9rZW4gIDI2MSAnOicKU2VwIDEzIDAzOjQ0OjEwIHBvcnRm
 d2RbMjAxM106IGxpbmUgICAgNCwgdG9rZW4gIDI1OCAnNjk5MScKU2VwIDEzIDAzOjQ0OjEw
 IHBvcnRmd2RbMjAxM106IGxpbmUgICAgNCwgdG9rZW4gIDI2NyAnfScKU2VwIDEzIDAzOjQ0
 OjEwIHBvcnRmd2RbMjAxM106IGxpbmUgICAgOSwgdG9rZW4gIDI2OCAnPT4nClNlcCAxMyAw
 Mzo0NDoxMCBwb3J0ZndkWzIwMTNdOiBsaW5lICAgIDksIHRva2VuICAyNTggJzEwLjAuMC4x
 MCcKU2VwIDEzIDAzOjQ0OjEwIHBvcnRmd2RbMjAxM106IGxpbmUgICAgOSwgdG9rZW4gIDI1
 OCAnNjExMy02MTE5JwpTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogbGluZSAgICA5
 LCB0b2tlbiAgMjY3ICd9JwpTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogbGluZSAg
 ICA5LCB0b2tlbiAgMjYyICc7JwpTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogbGlu
 ZSAgIDEwLCB0b2tlbiAgMjU4ICc2OTUwLTY5OTAnClNlcCAxMyAwMzo0NDoxMCBwb3J0Zndk
 WzIwMTNdOiAwLjAuMC4wClNlcCAxMyAwMzo0NDoxMCBwb3J0ZndkWzIwMTNdOiAvMApTZXAg
 MTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogOgpTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3ZFsy
 MDEzXTogMCs2NTUzNQpTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogID0+IApTZXAg
 MTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogMTAuMC4wLjEwClNlcCAxMyAwMzo0NDoxMCBw
 b3J0ZndkWzIwMTNdOiA6NjExMgpTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogCn0K
 U2VwIDEzIDAzOjQ0OjEwIHBvcnRmd2RbMjAxM106IApTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3
 ZFsyMDEzXTogNjIwMApTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogIC8qIHVpZDog
 LTEsIGdpZDogLTEgKi8KU2VwIDEzIDAzOjQ0OjEwIHBvcnRmd2RbMjAxM106ICAvKiBsaXN0
 ZW46IDAuMC4wLjAgKi8KU2VwIDEzIDAzOjQ0OjEwIHBvcnRmd2RbMjAxM106IAp7ClNlcCAx
 MyAwMzo0NDoxMCBwb3J0ZndkWzIwMTNdOiAwLjAuMC4wClNlcCAxMyAwMzo0NDoxMCBwb3J0
 ZndkWzIwMTNdOiAvMApTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogOgpTZXAgMTMg
 MDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogMCs2NTUzNQpTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3
 ZFsyMDEzXTogID0+IApTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogMTAuMC4wLjEw
 ClNlcCAxMyAwMzo0NDoxMCBwb3J0ZndkWzIwMTNdOiA6NjIwMApTZXAgMTMgMDM6NDQ6MTAg
 cG9ydGZ3ZFsyMDEzXTogCn0KU2VwIDEzIDAzOjQ0OjEwIHBvcnRmd2RbMjAxM106IApTZXAg
 MTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogNzQ1NgpTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3
 ZFsyMDEzXTogIC8qIHVpZDogLTEsIGdpZDogLTEgKi8KU2VwIDEzIDAzOjQ0OjEwIHBvcnRm
 d2RbMjAxM106ICAvKiBsaXN0ZW46IDAuMC4wLjAgKi8KU2VwIDEzIDAzOjQ0OjEwIHBvcnRm
 d2RbMjAxM106IAp7ClNlcCAxMyAwMzo0NDoxMCBwb3J0ZndkWzIwMTNdOiAwLjAuMC4wClNl
 cCAxMyAwMzo0NDoxMCBwb3J0ZndkWzIwMTNdOiAvMApTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3
 ZFsyMDEzXTogOgpTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogMCs2NTUzNQpTZXAg
 MTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogID0+IApTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3
 ZFsyMDEzXTogMTAuMC4wLjEwClNlcCAxMyAwMzo0NDoxMCBwb3J0ZndkWzIwMTNdOiA6NzQ1
 NgpTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogCn0KU2VwIDEzIDAzOjQ0OjEwIHBv
 cnRmd2RbMjAxM106IApTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogNjExMwpTZXAg
 MTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogIC8qIHVpZDogLTEsIGdpZDogLTEgKi8KU2Vw
 IDEzIDAzOjQ0OjEwIHBvcnRmd2RbMjAxM106ICAvKiBsaXN0ZW46IDAuMC4wLjAgKi8KU2Vw
 IDEzIDAzOjQ0OjEwIHBvcnRmd2RbMjAxM106IAp7ClNlcCAxMyAwMzo0NDoxMCBwb3J0Zndk
 WzIwMTNdOiAwLjAuMC4wClNlcCAxMyAwMzo0NDoxMCBwb3J0ZndkWzIwMTNdOiAvMApTZXAg
 MTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogOgpTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3ZFsy
 MDEzXTogMCs2NTUzNQpTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogID0+IApTZXAg
 MTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogMTAuMC4wLjEwClNlcCAxMyAwMzo0NDoxMCBw
 b3J0ZndkWzIwMTNdOiA6NjExMwpTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3ZFsyMDEzXTogCn0K
 U2VwIDEzIDAzOjQ0OjEwIHBvcnRmd2RbMjAxM106IApTZXAgMTMgMDM6NDQ6MTAgcG9ydGZ3
 ZFsyMDEzXTogNjk1MApTZXAgMTMgMDM6NDQ6MTEgcG9ydGZ3ZFsyMDEzXTogIC8qIHVpZDog
 LTEsIGdpZDogLTEgKi8KU2VwIDEzIDAzOjQ0OjExIHBvcnRmd2RbMjAxM106ICAvKiBsaXN0
 ZW46IDAuMC4wLjAgKi8KU2VwIDEzIDAzOjQ0OjExIHBvcnRmd2RbMjAxM106IAp7ClNlcCAx
 MyAwMzo0NDoxMSBwb3J0ZndkWzIwMTNdOiAwLjAuMC4wClNlcCAxMyAwMzo0NDoxMSBwb3J0
 ZndkWzIwMTNdOiAvMApTZXAgMTMgMDM6NDQ6MTEgcG9ydGZ3ZFsyMDEzXTogOgpQbGVhc2Ug
 c2V0IGEgdGVybWluYWwgdHlwZS4KL3Vzci9sb2NhbC9ldGMvcmMuZC9uZ25hdC5zaDogREVC
 VUc6IGNoZWNreWVzbm86IG5nbmF0X2VuYWJsZSBpcyBzZXQgdG8gWUVTLgovdXNyL2xvY2Fs
 L2V0Yy9yYy5kL25nbmF0LnNoOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6IGRvaXQ6IG5nbmF0
 X3N0YXJ0IApTZXR1cCBuZ19uYXQgYW5kIG5nX25ldGZsb3cKbmdjdGw6IApzZW5kIG1zZwo6
 IApJbnZhbGlkIGFyZ3VtZW50Cm5nY3RsOiAKbGluZSAyOTogZXJyb3IgaW4gZmlsZQoKU2Vw
 IDEzIDAzOjQ0OjEyIG1hcnktdGVyZXNhIG5hbWVkWzIyNzZdOiB0aGUgd29ya2luZyBkaXJl
 Y3RvcnkgaXMgbm90IHdyaXRhYmxlClNlcCAxMyAwMzo0NDoxMyBtYXJ5LXRlcmVzYSBuYW1l
 ZFsyMzkyXTogY291bGQgbm90IGxpc3RlbiBvbiBVRFAgc29ja2V0OiBhZGRyZXNzIGluIHVz
 ZQpTZXAgMTMgMDM6NDQ6MTMgbWFyeS10ZXJlc2EgbmFtZWRbMjM5Ml06IGNyZWF0aW5nIElQ
 djQgaW50ZXJmYWNlIHJlMCBmYWlsZWQ7IGludGVyZmFjZSBpZ25vcmVkClNlcCAxMyAwMzo0
 NDoxMyBtYXJ5LXRlcmVzYSBuYW1lZFsyMzkyXTogY291bGQgbm90IGxpc3RlbiBvbiBVRFAg
 c29ja2V0OiBhZGRyZXNzIGluIHVzZQpTZXAgMTMgMDM6NDQ6MTMgbWFyeS10ZXJlc2EgbmFt
 ZWRbMjM5Ml06IGNyZWF0aW5nIElQdjQgaW50ZXJmYWNlIHZyMSBmYWlsZWQ7IGludGVyZmFj
 ZSBpZ25vcmVkClNlcCAxMyAwMzo0NDoxMyBtYXJ5LXRlcmVzYSBuYW1lZFsyMzkyXTogY291
 bGQgbm90IGxpc3RlbiBvbiBVRFAgc29ja2V0OiBhZGRyZXNzIGluIHVzZQpTZXAgMTMgMDM6
 NDQ6MTMgbWFyeS10ZXJlc2EgbmFtZWRbMjM5Ml06IGNyZWF0aW5nIElQdjYgaW50ZXJmYWNl
 IGxvMCBmYWlsZWQ7IGludGVyZmFjZSBpZ25vcmVkClNlcCAxMyAwMzo0NDoxMyBtYXJ5LXRl
 cmVzYSBuYW1lZFsyMzkyXTogY291bGQgbm90IGxpc3RlbiBvbiBVRFAgc29ja2V0OiBhZGRy
 ZXNzIGluIHVzZQpTZXAgMTMgMDM6NDQ6MTMgbWFyeS10ZXJlc2EgbmFtZWRbMjM5Ml06IGNy
 ZWF0aW5nIElQdjQgaW50ZXJmYWNlIGxvMCBmYWlsZWQ7IGludGVyZmFjZSBpZ25vcmVkClNl
 cCAxMyAwMzo0NDoxMyBtYXJ5LXRlcmVzYSBuYW1lZFsyMzkyXTogY291bGQgbm90IGxpc3Rl
 biBvbiBVRFAgc29ja2V0OiBhZGRyZXNzIGluIHVzZQpTZXAgMTMgMDM6NDQ6MTMgbWFyeS10
 ZXJlc2EgbmFtZWRbMjM5Ml06IGNyZWF0aW5nIElQdjQgaW50ZXJmYWNlIHR1bjEgZmFpbGVk
 OyBpbnRlcmZhY2UgaWdub3JlZApTZXAgMTMgMDM6NDQ6MTMgbWFyeS10ZXJlc2EgbmFtZWRb
 MjM5Ml06IGNvdWxkIG5vdCBsaXN0ZW4gb24gVURQIHNvY2tldDogYWRkcmVzcyBpbiB1c2UK
 U2VwIDEzIDAzOjQ0OjEzIG1hcnktdGVyZXNhIG5hbWVkWzIzOTJdOiBjcmVhdGluZyBJUHY0
 IGludGVyZmFjZSB0dW4yIGZhaWxlZDsgaW50ZXJmYWNlIGlnbm9yZWQKU2VwIDEzIDAzOjQ0
 OjEzIG1hcnktdGVyZXNhIG5hbWVkWzIzOTJdOiB0aGUgd29ya2luZyBkaXJlY3RvcnkgaXMg
 bm90IHdyaXRhYmxlCnZyMTogcHJvbWlzY3VvdXMgbW9kZSBlbmFibGVkCi9ldGMvcmMuZC9j
 cm9uOiBERUJVRzogY2hlY2t5ZXNubzogY3Jvbl9kc3QgaXMgc2V0IHRvIFlFUy4KL2V0Yy9y
 Yy5kL2Nyb246IERFQlVHOiBwaWQgZmlsZSAoL3Zhci9ydW4vY3Jvbi5waWQpOiBub3QgcmVh
 ZGFibGUuCi9ldGMvcmMuZC9jcm9uOiBERUJVRzogY2hlY2t5ZXNubzogY3Jvbl9lbmFibGUg
 aXMgc2V0IHRvIFlFUy4KL2V0Yy9yYy5kL2Nyb246IERFQlVHOiBwaWQgZmlsZSAoL3Zhci9y
 dW4vY3Jvbi5waWQpOiBub3QgcmVhZGFibGUuCi9ldGMvcmMuZC9jcm9uOiBERUJVRzogY2hl
 Y2t5ZXNubzogY3Jvbl9lbmFibGUgaXMgc2V0IHRvIFlFUy4KY3JvbiBub3QgcnVubmluZz8g
 KGNoZWNrIC92YXIvcnVuL2Nyb24ucGlkKS4KL2V0Yy9yYy5kL2Nyb246IERFQlVHOiBwaWQg
 ZmlsZSAoL3Zhci9ydW4vY3Jvbi5waWQpOiBub3QgcmVhZGFibGUuCi9ldGMvcmMuZC9jcm9u
 OiBERUJVRzogY2hlY2t5ZXNubzogY3Jvbl9lbmFibGUgaXMgc2V0IHRvIFlFUy4KU3RhcnRp
 bmcgY3Jvbi4KL2V0Yy9yYy5kL2Nyb246IERFQlVHOiBydW5fcmNfY29tbWFuZDogZG9pdDog
 L3Vzci9zYmluL2Nyb24gIC1zIAovZXRjL3JjLmQvYnNubXBkOiBERUJVRzogcGlkIGZpbGUg
 KC92YXIvcnVuL3NubXBkLnBpZCk6IG5vdCByZWFkYWJsZS4KL2V0Yy9yYy5kL2Jzbm1wZDog
 REVCVUc6IGNoZWNreWVzbm86IGJzbm1wZF9lbmFibGUgaXMgc2V0IHRvIFlFUy4KL2V0Yy9y
 Yy5kL2Jzbm1wZDogREVCVUc6IHBpZCBmaWxlICgvdmFyL3J1bi9zbm1wZC5waWQpOiBub3Qg
 cmVhZGFibGUuCi9ldGMvcmMuZC9ic25tcGQ6IERFQlVHOiBjaGVja3llc25vOiBic25tcGRf
 ZW5hYmxlIGlzIHNldCB0byBZRVMuCmJzbm1wZCBub3QgcnVubmluZz8gKGNoZWNrIC92YXIv
 cnVuL3NubXBkLnBpZCkuCi9ldGMvcmMuZC9ic25tcGQ6IERFQlVHOiBwaWQgZmlsZSAoL3Zh
 ci9ydW4vc25tcGQucGlkKTogbm90IHJlYWRhYmxlLgovZXRjL3JjLmQvYnNubXBkOiBERUJV
 RzogY2hlY2t5ZXNubzogYnNubXBkX2VuYWJsZSBpcyBzZXQgdG8gWUVTLgpTdGFydGluZyBi
 c25tcGQuCi9ldGMvcmMuZC9ic25tcGQ6IERFQlVHOiBydW5fcmNfY29tbWFuZDogZG9pdDog
 L3Vzci9zYmluL2Jzbm1wZCAtRCBkdW1wIAovdXNyL2Jpbi9tNCAtRF9DRl9ESVJfPS91c3Iv
 c2hhcmUvc2VuZG1haWwvY2YvICAgL3Vzci9zaGFyZS9zZW5kbWFpbC9jZi9tNC9jZi5tNCBt
 YXJ5LXRlcmVzYS5vdHJhZGEub2QudWEubWMgPiBtYXJ5LXRlcmVzYS5vdHJhZGEub2QudWEu
 Y2YKL3Vzci9iaW4vbTQgLURfQ0ZfRElSXz0vdXNyL3NoYXJlL3NlbmRtYWlsL2NmLyAgIC91
 c3Ivc2hhcmUvc2VuZG1haWwvY2YvbTQvY2YubTQgbWFyeS10ZXJlc2Eub3RyYWRhLm9kLnVh
 LnN1Ym1pdC5tYyA+IG1hcnktdGVyZXNhLm90cmFkYS5vZC51YS5zdWJtaXQuY2YKUmVzdGFy
 dGluZzoKL2V0Yy9yYy5zZW5kbWFpbDogcmVzdGFydC1tdGE6IC92YXIvcnVuL3NlbmRtYWls
 LnBpZCBub3QgZm91bmQKL2V0Yy9yYy5zZW5kbWFpbDogcmVzdGFydC1tc3BxOiAvdmFyL3Nw
 b29sL2NsaWVudG1xdWV1ZS9zbS1jbGllbnQucGlkIG5vdCBmb3VuZAouCi91c3IvbG9jYWwv
 ZXRjL3JjLmQvZG92ZWNvdDogREVCVUc6IGNoZWNreWVzbm86IGRvdmVjb3RfZW5hYmxlIGlz
 IHNldCB0byBZRVMuCi91c3IvbG9jYWwvZXRjL3JjLmQvZG92ZWNvdDogREVCVUc6IHBpZCBm
 aWxlICgvdmFyL3J1bi9kb3ZlY290L21hc3Rlci5waWQpOiBub3QgcmVhZGFibGUuCi91c3Iv
 bG9jYWwvZXRjL3JjLmQvZG92ZWNvdDogREVCVUc6IGNoZWNreWVzbm86IGRvdmVjb3RfZW5h
 YmxlIGlzIHNldCB0byBZRVMuCi91c3IvbG9jYWwvZXRjL3JjLmQvZG92ZWNvdDogREVCVUc6
 IHJ1bl9yY19jb21tYW5kOiBkb2l0OiByZXN0YXJ0X2NtZCAKL3Vzci9sb2NhbC9ldGMvcmMu
 ZC9kb3ZlY290OiBERUJVRzogcGlkIGZpbGUgKC92YXIvcnVuL2RvdmVjb3QvbWFzdGVyLnBp
 ZCk6IG5vdCByZWFkYWJsZS4KL3Vzci9sb2NhbC9ldGMvcmMuZC9kb3ZlY290OiBERUJVRzog
 Y2hlY2t5ZXNubzogZG92ZWNvdF9lbmFibGUgaXMgc2V0IHRvIFlFUy4KZG92ZWNvdCBub3Qg
 cnVubmluZz8gKGNoZWNrIC92YXIvcnVuL2RvdmVjb3QvbWFzdGVyLnBpZCkuCi91c3IvbG9j
 YWwvZXRjL3JjLmQvZG92ZWNvdDogREVCVUc6IHBpZCBmaWxlICgvdmFyL3J1bi9kb3ZlY290
 L21hc3Rlci5waWQpOiBub3QgcmVhZGFibGUuCi91c3IvbG9jYWwvZXRjL3JjLmQvZG92ZWNv
 dDogREVCVUc6IGNoZWNreWVzbm86IGRvdmVjb3RfZW5hYmxlIGlzIHNldCB0byBZRVMuCi91
 c3IvbG9jYWwvZXRjL3JjLmQvZG92ZWNvdDogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBzdGFy
 dF9wcmVjbWQ6IHN0YXJ0X3ByZWNtZCAKU3RhcnRpbmcgZG92ZWNvdC4KL3Vzci9sb2NhbC9l
 dGMvcmMuZC9kb3ZlY290OiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6IGRvaXQ6IC91c3IvbG9j
 YWwvc2Jpbi9kb3ZlY290ICAtYyAvdXNyL2xvY2FsL2V0Yy9kb3ZlY290LmNvbmYKL3Vzci9s
 b2NhbC9ldGMvcmMuZC9mZXRjaG1haWw6IERFQlVHOiBwaWQgZmlsZSAoL3Zhci9ydW4vZmV0
 Y2htYWlsL2ZldGNobWFpbC5waWQpOiBub3QgcmVhZGFibGUuCi91c3IvbG9jYWwvZXRjL3Jj
 LmQvZmV0Y2htYWlsOiBERUJVRzogY2hlY2t5ZXNubzogZmV0Y2htYWlsX2VuYWJsZSBpcyBz
 ZXQgdG8gWUVTLgovdXNyL2xvY2FsL2V0Yy9yYy5kL2ZldGNobWFpbDogREVCVUc6IHBpZCBm
 aWxlICgvdmFyL3J1bi9mZXRjaG1haWwvZmV0Y2htYWlsLnBpZCk6IG5vdCByZWFkYWJsZS4K
 L3Vzci9sb2NhbC9ldGMvcmMuZC9mZXRjaG1haWw6IERFQlVHOiBjaGVja3llc25vOiBmZXRj
 aG1haWxfZW5hYmxlIGlzIHNldCB0byBZRVMuCmZldGNobWFpbCBub3QgcnVubmluZz8gKGNo
 ZWNrIC92YXIvcnVuL2ZldGNobWFpbC9mZXRjaG1haWwucGlkKS4KL3Vzci9sb2NhbC9ldGMv
 cmMuZC9mZXRjaG1haWw6IERFQlVHOiBwaWQgZmlsZSAoL3Zhci9ydW4vZmV0Y2htYWlsL2Zl
 dGNobWFpbC5waWQpOiBub3QgcmVhZGFibGUuCi91c3IvbG9jYWwvZXRjL3JjLmQvZmV0Y2ht
 YWlsOiBERUJVRzogY2hlY2t5ZXNubzogZmV0Y2htYWlsX2VuYWJsZSBpcyBzZXQgdG8gWUVT
 LgpTdGFydGluZyBmZXRjaG1haWwuCi91c3IvbG9jYWwvZXRjL3JjLmQvZmV0Y2htYWlsOiBE
 RUJVRzogcnVuX3JjX2NvbW1hbmQ6IGRvaXQ6IHN1IC1tIGZldGNobWFpbCAtYyAnc2ggLWMg
 Ii91c3IvbG9jYWwvYmluL2ZldGNobWFpbCAtZiAvdXNyL2xvY2FsL2V0Yy9mZXRjaG1haWxy
 YyAJCQkJLS1waWRmaWxlIC92YXIvcnVuL2ZldGNobWFpbC9mZXRjaG1haWwucGlkIAkJCQkt
 ZCA5MDAgCQkJCS0tc3lzbG9nICInCmZldGNobWFpbDogV2FybmluZzogc3lzbG9nIGFuZCBs
 b2dmaWxlIGFyZSBzZXQuIENoZWNrIGJvdGggZm9yIGxvZ3MhCi91c3IvbG9jYWwvZXRjL3Jj
 LmQvZ2F0ZXdheTY6IERFQlVHOiBjaGVja3llc25vOiBnYXRld2F5Nl9lbmFibGUgaXMgc2V0
 IHRvIFlFUy4KL3Vzci9sb2NhbC9ldGMvcmMuZC9nYXRld2F5NjogREVCVUc6IGNoZWNreWVz
 bm86IGdhdGV3YXk2X2VuYWJsZSBpcyBzZXQgdG8gWUVTLgpnYXRld2F5NiBub3QgcnVubmlu
 Zz8KL3Vzci9sb2NhbC9ldGMvcmMuZC9nYXRld2F5NjogREVCVUc6IGNoZWNreWVzbm86IGdh
 dGV3YXk2X2VuYWJsZSBpcyBzZXQgdG8gWUVTLgpTdGFydGluZyBnYXRld2F5Ni4KL3Vzci9s
 b2NhbC9ldGMvcmMuZC9nYXRld2F5NjogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBkb2l0OiAv
 dXNyL2xvY2FsL2Jpbi9ndzZjICAKR2F0ZXdheTYgQ2xpZW50IHY1LjAtUkVMRUFTRSBidWls
 ZCBNYXkgMzEgMjAwOS0wMDoxMToyNiAKU2VwIDEzIDAzOjQ0OjI0IG1hcnktdGVyZXNhIGd3
 NmM6IEdhdGV3YXk2IENsaWVudCB2NS4wLVJFTEVBU0UgYnVpbGQgTWF5IDMxIDIwMDktMDA6
 MTE6MjYgClJlY2VpdmVkIGEgVFNQIHJlZGlyZWN0aW9uIG1lc3NhZ2UgZnJvbSBicm9rZXIg
 YXV0aGVudGljYXRlZC5mcmVlbmV0Ni5uZXQgKDEyMDAgUmVkaXJlY3Rpb24pLgpTZXAgMTMg
 MDM6NDQ6MjUgbWFyeS10ZXJlc2EgZ3c2YzogUmVjZWl2ZWQgYSBUU1AgcmVkaXJlY3Rpb24g
 bWVzc2FnZSBmcm9tIGJyb2tlciBhdXRoZW50aWNhdGVkLmZyZWVuZXQ2Lm5ldCAoMTIwMCBS
 ZWRpcmVjdGlvbl5NKS4KVGhlIGJyb2tlciByZWRpcmVjdGlvbiBsaXN0IGlzIFsgYW1zdGVy
 ZGFtLmZyZWVuZXQ2Lm5ldCwgbW9udHJlYWwuZnJlZW5ldDYubmV0IF0uClNlcCAxMyAwMzo0
 NDoyNSBtYXJ5LXRlcmVzYSBndzZjOiBUaGUgYnJva2VyIHJlZGlyZWN0aW9uIGxpc3QgaXMg
 WyBhbXN0ZXJkYW0uZnJlZW5ldDYubmV0LCBtb250cmVhbC5mcmVlbmV0Ni5uZXQgXS4KU2Vw
 IDEzIDAzOjQ0OjI1IG1hcnktdGVyZXNhIHN1OiB2bGFkMTEgdG8gcm9vdCBvbiAvZGV2L3B0
 cy8xClRoZSBvcHRpbWl6ZWQgYnJva2VyIHJlZGlyZWN0aW9uIGxpc3QgaXMgWyBhbXN0ZXJk
 YW0uZnJlZW5ldDYubmV0LCBtb250cmVhbC5mcmVlbmV0Ni5uZXQgXS4KU2VwIDEzIDAzOjQ0
 OjI1IG1hcnktdGVyZXNhIGd3NmM6IFRoZSBvcHRpbWl6ZWQgYnJva2VyIHJlZGlyZWN0aW9u
 IGxpc3QgaXMgWyBhbXN0ZXJkYW0uZnJlZW5ldDYubmV0LCBtb250cmVhbC5mcmVlbmV0Ni5u
 ZXQgXS4KQ29ubmVjdGlvbiB0byBhbXN0ZXJkYW0uZnJlZW5ldDYubmV0IGVzdGFibGlzaGVk
 LgpTZXAgMTMgMDM6NDQ6MjUgbWFyeS10ZXJlc2EgZ3c2YzogQ29ubmVjdGlvbiB0byBhbXN0
 ZXJkYW0uZnJlZW5ldDYubmV0IGVzdGFibGlzaGVkLgouCi9ldGMvcmM6IERFQlVHOiBjaGVj
 a3llc25vOiBscGRfZW5hYmxlIGlzIHNldCB0byBOTy4KL2V0Yy9yYzogREVCVUc6IGNoZWNr
 eWVzbm86IHVwZGF0ZV9tb3RkIGlzIHNldCB0byBZRVMuCi9ldGMvcmM6IERFQlVHOiBydW5f
 cmNfY29tbWFuZDogZG9pdDogbW90ZF9zdGFydCAKcmUwOiBsaW5rIHN0YXRlIGNoYW5nZWQg
 dG8gRE9XTgovZXRjL3JjOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6IGRvaXQ6IG1vdW50bGF0
 ZV9zdGFydCAKL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IG5zY2RfZW5hYmxlIGlzIHNl
 dCB0byBOTy4KL2V0Yy9yYzogREVCVUc6IHBpZCBmaWxlICgvdmFyL3J1bi9udHBkLnBpZCk6
 IG5vdCByZWFkYWJsZS4KL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IG50cGRfZW5hYmxl
 IGlzIHNldCB0byBZRVMuCi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFuZDogc3RhcnRf
 cHJlY21kOiBudHBkX3ByZWNtZCAKL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IG50cGRf
 c3luY19vbl9zdGFydCBpcyBzZXQgdG8gWUVTLgovZXRjL3JjOiBERUJVRzogcnVuX3JjX2Nv
 bW1hbmQ6IGRvaXQ6IC91c3Ivc2Jpbi9udHBkIC1nIC1jIC9ldGMvbnRwLmNvbmYgLXAgL3Zh
 ci9ydW4vbnRwZC5waWQgClNlcCAxMyAwMzo0NDoyNiBtYXJ5LXRlcmVzYSBndzZjOiBZb3Vy
 IElQdjYgYWRkcmVzcyBpcyAyMDAxOjA1YzA6MTQwMDowMDBiOjAwMDA6MDAwMDowMDAwOjI3
 ZTkuClNlcCAxMyAwMzo0NDoyNiBtYXJ5LXRlcmVzYSBndzZjOiBZb3VyIElQdjYgcHJlZml4
 IGlzIDIwMDE6MDVjMDoxNTAzOjM0MDA6MDAwMDowMDAwOjAwMDA6MDAwMC81Ni4KL2V0Yy9y
 YzogREVCVUc6IGNoZWNreWVzbm86IHBvd2VyZF9lbmFibGUgaXMgc2V0IHRvIE5PLgovZXRj
 L3JjOiBERUJVRzogcGlkIGZpbGUgKC92YXIvcnVuL3JhcnBkLnBpZCk6IG5vdCByZWFkYWJs
 ZS4KL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IHJhcnBkX2VuYWJsZSBpcyBzZXQgdG8g
 Tk8uCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBzZHBkX2VuYWJsZSBpcyBzZXQgdG8g
 Tk8uCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiByZmNvbW1fcHBwZF9zZXJ2ZXJfZW5h
 YmxlIGlzIHNldCB0byBOTy4KL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IHJ0YWR2ZF9l
 bmFibGUgaXMgc2V0IHRvIE5PLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogcndob2Rf
 ZW5hYmxlIGlzIHNldCB0byBOTy4KL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IHRpbWVk
 X2VuYWJsZSBpcyBzZXQgdG8gTk8uCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiB1Z2lk
 ZndfZW5hYmxlIGlzIHNldCB0byBOTy4KU2VwIDEzIDAzOjQ0OjI3IG1hcnktdGVyZXNhIG50
 cGRbMjY2OV06IGJpbmQoKSBmZCAyMywgZmFtaWx5IDI4LCBwb3J0IDEyMywgc2NvcGUgMCwg
 YWRkciAyMDAxOjVjMDoxNTAzOjM0MDA6OjEsIGluNl9pc19hZGRyX211bHRpY2FzdD0wIGZs
 YWdzPTB4MTEgZmFpbHM6IENhbid0IGFzc2lnbiByZXF1ZXN0ZWQgYWRkcmVzcwpTZXAgMTMg
 MDM6NDQ6MjcgbWFyeS10ZXJlc2EgbnRwZFsyNjY5XTogdW5hYmxlIHRvIGNyZWF0ZSBzb2Nr
 ZXQgb24gcmUwICgzKSBmb3IgMjAwMTo1YzA6MTUwMzozNDAwOjoxIzEyMwpTZXAgMTMgMDM6
 NDQ6MjcgbWFyeS10ZXJlc2EgbnRwZFsyNjY5XTogYmluZCgpIGZkIDI5LCBmYW1pbHkgMjgs
 IHBvcnQgMTIzLCBzY29wZSAwLCBhZGRyIDIwMDE6NWMwOjE0MDA6Yjo6MjdlOSwgaW42X2lz
 X2FkZHJfbXVsdGljYXN0PTAgZmxhZ3M9MHgxMyBmYWlsczogQ2FuJ3QgYXNzaWduIHJlcXVl
 c3RlZCBhZGRyZXNzClNlcCAxMyAwMzo0NDoyNyBtYXJ5LXRlcmVzYSBudHBkWzI2NjldOiB1
 bmFibGUgdG8gY3JlYXRlIHNvY2tldCBvbiBnaWYwICgxMCkgZm9yIDIwMDE6NWMwOjE0MDA6
 Yjo6MjdlOSMxMjMKL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IG5pc195cHBhc3N3ZGRf
 ZW5hYmxlIGlzIHNldCB0byBOTy4KL2V0Yy9yYzogREVCVUc6IHBpZCBmaWxlICgvdmFyL2Ri
 L251dC91cHNkLnBpZCk6IG5vdCByZWFkYWJsZS4KL2V0Yy9yYzogREVCVUc6IGNoZWNreWVz
 bm86IG51dF9lbmFibGUgaXMgc2V0IHRvIE5PLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNu
 bzogbnV0X3Vwc2xvZ19lbmFibGUgaXMgc2V0IHRvIE5PLgovZXRjL3JjOiBERUJVRzogcGlk
 IGZpbGUgKC92YXIvZGIvbnV0L3Vwc21vbi5waWQpOiBub3QgcmVhZGFibGUuCi9ldGMvcmM6
 IERFQlVHOiBjaGVja3llc25vOiBudXRfdXBzbW9uX2VuYWJsZSBpcyBzZXQgdG8gTk8uCi9l
 dGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBwcm9mdHBkX2VuYWJsZSBpcyBzZXQgdG8gWUVT
 LgovZXRjL3JjOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6IGRvaXQ6IC91c3IvbG9jYWwvc2Jp
 bi9wcm9mdHBkICAKL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IHNhbWJhX2VuYWJsZSBp
 cyBzZXQgdG8gWUVTLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogc2FtYmFfZW5hYmxl
 IGlzIHNldCB0byBZRVMuCi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFuZDogc3RhcnRf
 cHJlY21kOiBzYW1iYV9zdGFydF9wcmVjbWQgClJlbW92aW5nIHN0YWxlIFNhbWJhIHRkYiBm
 aWxlczogCi4KLgouCi4KLgouCi4KLgogZG9uZQovZXRjL3JjOiBERUJVRzogcnVuX3JjX2Nv
 bW1hbmQ6IGRvaXQ6IHNhbWJhX2NtZCAKL2V0Yy9yYzogREVCVUc6IHBpZCBmaWxlICgvdmFy
 L3J1bi9ubWJkLnBpZCk6IG5vdCByZWFkYWJsZS4KL2V0Yy9yYzogREVCVUc6IGNoZWNreWVz
 bm86IG5tYmRfZW5hYmxlIGlzIHNldCB0byBZRVMuCi9ldGMvcmM6IERFQlVHOiBydW5fcmNf
 Y29tbWFuZDogZG9pdDogL3Vzci9sb2NhbC9zYmluL25tYmQgIi1EIiAtcyAvdXNyL2xvY2Fs
 L2V0Yy9zbWIuY29uZgovZXRjL3JjOiBERUJVRzogcGlkIGZpbGUgKC92YXIvcnVuL3NtYmQu
 cGlkKTogbm90IHJlYWRhYmxlLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogc21iZF9l
 bmFibGUgaXMgc2V0IHRvIFlFUy4KL2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBk
 b2l0OiAvdXNyL2xvY2FsL3NiaW4vc21iZCAiLUQiIC1zIC91c3IvbG9jYWwvZXRjL3NtYi5j
 b25mCnJlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIFVQCi9ldGMvcmM6IERFQlVHOiBwaWQg
 ZmlsZSAoL3Zhci9ydW4vd2luYmluZGQucGlkKTogbm90IHJlYWRhYmxlLgovZXRjL3JjOiBE
 RUJVRzogY2hlY2t5ZXNubzogd2luYmluZGRfZW5hYmxlIGlzIHNldCB0byBOTy4KL2V0Yy9y
 YzogREVCVUc6IHBpZCBmaWxlICgvdmFyL3J1bi9zbWFydGQucGlkKTogbm90IHJlYWRhYmxl
 LgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogc21hcnRkX2VuYWJsZSBpcyBzZXQgdG8g
 Tk8uCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiB3ZWJtaW5fZW5hYmxlIGlzIHNldCB0
 byBZRVMuCi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFuZDogZG9pdDogL3Vzci9sb2Nh
 bC9ldGMvd2VibWluL3N0YXJ0ICAKL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IHNxdWlk
 X2VuYWJsZSBpcyBzZXQgdG8gWUVTLgovZXRjL3JjOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6
 IGRvaXQ6IHN1IC1tIHNxdWlkIC1jICdzaCAtYyAiY2QgL3Vzci9sb2NhbC9zcXVpZC9sb2dz
 ICYmIC91c3IvbG9jYWwvc2Jpbi9zcXVpZCAtRCAiJwovZXRjL3JjOiBXQVJOSU5HOiBmYWls
 ZWQgdG8gc3RhcnQgc3F1aWQKL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IHNwYW1hc3Nf
 bWlsdGVyX2VuYWJsZSBpcyBzZXQgdG8gWUVTLgovZXRjL3JjOiBERUJVRzogcnVuX3JjX2Nv
 bW1hbmQ6IGRvaXQ6IC91c3IvbG9jYWwvc2Jpbi9zcGFtYXNzLW1pbHRlciAtZiAtcCAvdmFy
 L3J1bi9zcGFtYXNzLW1pbHRlci5zb2NrICAKL2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21t
 YW5kOiBzdGFydF9wb3N0Y21kOiBzdGFydF9wb3N0Y21kIAovZXRjL3JjOiBERUJVRzogcGlk
 IGZpbGUgKC92YXIvcnVuL3NubXB0cmFwZC5waWQpOiBub3QgcmVhZGFibGUuCi9ldGMvcmM6
 IERFQlVHOiBjaGVja3llc25vOiBzbm1wdHJhcGRfZW5hYmxlIGlzIHNldCB0byBOTy4KL2V0
 Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IHNubXBkX2VuYWJsZSBpcyBzZXQgdG8gTk8uCi9l
 dGMvcmM6IERFQlVHOiBwaWQgZmlsZSAoL3Zhci9ydW4vc2FzbGF1dGhkL3Nhc2xhdXRoZC5w
 aWQpOiBub3QgcmVhZGFibGUuCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBzYXNsYXV0
 aGRfZW5hYmxlIGlzIHNldCB0byBZRVMuCi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFu
 ZDogZG9pdDogL3Vzci9sb2NhbC9zYmluL3Nhc2xhdXRoZCAtYSBnZXRwd2VudCAKL2V0Yy9y
 YzogREVCVUc6IHBpZCBmaWxlICgvdmFyL3J1bi9zcGFtZC9zcGFtZC5waWQpOiBub3QgcmVh
 ZGFibGUuCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBzcGFtZF9lbmFibGUgaXMgc2V0
 IHRvIFlFUy4KL2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBkb2l0OiAvdXNyL2xv
 Y2FsL2Jpbi9zcGFtZCAtYyAtZCAgLXIgIC11IHNwYW1kICAtZCAtciAvdmFyL3J1bi9zcGFt
 ZC9zcGFtZC5waWQKL2V0Yy9yYzogREVCVUc6IHBpZCBmaWxlICgvdmFyL3J1bi9yc3luY2Qu
 cGlkKTogbm90IHJlYWRhYmxlLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogcnN5bmNk
 X2VuYWJsZSBpcyBzZXQgdG8gTk8uCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBuZXRn
 cmFwaF9lbmFibGUgaXMgc2V0IHRvIFlFUy4KL2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21t
 YW5kOiBzdGFydF9wcmVjbWQ6IG5ldGdyYXBoX3ByZXZhciAKL2V0Yy9yYzogREVCVUc6IGNo
 ZWNrIG5ldGZsb3cKL2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBkb2l0OiBuZXRn
 cmFwaF9zdGFydCAKL2V0Yy9yYzogREVCVUc6IHRvcyBmb3IgcmUwIHJlcXVpcmUgdG8gc2V0
 IHRvIAovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXMgbmV0Zmxvd19yZTAKL2V0Yy9yYzogREVC
 VUc6IGNoZWNraW5nIHJlcXVpcmUgc2V0IHRvczogICwgdG9zX3NldCBpcyAwCi9ldGMvcmM6
 IERFQlVHOiB0b3MgZm9yIHZyMCByZXF1aXJlIHRvIHNldCB0byAKL2V0Yy9yYzogREVCVUc6
 IGNoZWNreWVzIG5ldGZsb3dfdnIwCi9ldGMvcmM6IERFQlVHOiBjaGVja2luZyByZXF1aXJl
 IHNldCB0b3M6ICAsIHRvc19zZXQgaXMgMAovZXRjL3JjOiBERUJVRzogdG9zIGZvciB2cjEg
 cmVxdWlyZSB0byBzZXQgdG8gCi9ldGMvcmM6IERFQlVHOiBjaGVja3llcyBuZXRmbG93X3Zy
 MQovZXRjL3JjOiBERUJVRzogY2hlY2tpbmcgcmVxdWlyZSBzZXQgdG9zOiAgLCB0b3Nfc2V0
 IGlzIDAKL2V0Yy9yYzogREVCVUc6IHBpZCBmaWxlICgvdmFyL2RiL215c3FsL21hcnktdGVy
 ZXNhLm90cmFkYS5vZC51YS5waWQpOiBub3QgcmVhZGFibGUuCi9ldGMvcmM6IERFQlVHOiBj
 aGVja3llc25vOiBteXNxbF9lbmFibGUgaXMgc2V0IHRvIFlFUy4KL2V0Yy9yYzogREVCVUc6
 IHJ1bl9yY19jb21tYW5kOiBzdGFydF9wcmVjbWQ6IG15c3FsX3ByZXN0YXJ0IAovZXRjL3Jj
 OiBERUJVRzogY2hlY2t5ZXNubzogbXlzcWxfbGltaXRzIGlzIHNldCB0byBOTy4KL2V0Yy9y
 YzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBkb2l0OiBzdSAtbSBteXNxbCAtYyAnc2ggLWMg
 Ii91c3IvbG9jYWwvYmluL215c3FsZF9zYWZlICAtLWRlZmF1bHRzLWV4dHJhLWZpbGU9L3Zh
 ci9kYi9teXNxbC9teS5jbmYgLS11c2VyPW15c3FsIC0tZGF0YWRpcj0vdmFyL2RiL215c3Fs
 IC0tcGlkLWZpbGU9L3Zhci9kYi9teXNxbC9tYXJ5LXRlcmVzYS5vdHJhZGEub2QudWEucGlk
 IC0tZGVmYXVsdC1jaGFyYWN0ZXItc2V0PXV0ZjggLS1jaGFyYWN0ZXItc2V0LXNlcnZlcj11
 dGY4IC0tY29sbGF0aW9uLXNlcnZlcj11dGY4X3VuaWNvZGVfY2kgPiAvZGV2L251bGwgMj4m
 MSAmIicKL2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBzdGFydF9wb3N0Y21kOiBt
 eXNxbF9wb3N0c3RhcnQgCi9ldGMvcmM6IERFQlVHOiBwaWQgZmlsZSAoL3Zhci9zcG9vbC9N
 SU1FRGVmYW5nL21pbWVkZWZhbmctbXVsdGlwbGV4b3IucGlkKTogbm90IHJlYWRhYmxlLgov
 ZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogbWltZWRlZmFuZ19lbmFibGUgaXMgc2V0IHRv
 IE5PLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogbWJtb25fZW5hYmxlIGlzIHNldCB0
 byBOTy4KL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IGlnbXBwcm94eV9lbmFibGUgaXMg
 c2V0IHRvIE5PLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogaHRjYWNoZWNsZWFuX2Vu
 YWJsZSBpcyBzZXQgdG8gTk8uCi9ldGMvcmM6IERFQlVHOiBwaWQgZmlsZSAoL3Zhci9ydW4v
 ZGJ1cy9kYnVzLnBpZCk6IG5vdCByZWFkYWJsZS4KL2V0Yy9yYzogREVCVUc6IGNoZWNreWVz
 bm86IGRidXNfZW5hYmxlIGlzIHNldCB0byBOTy4KL2V0Yy9yYzogREVCVUc6IHBpZCBmaWxl
 ICgvdmFyL3J1bi9oYWxkL2hhbGQucGlkKTogbm90IHJlYWRhYmxlLgovZXRjL3JjOiBERUJV
 RzogY2hlY2t5ZXNubzogaGFsZF9lbmFibGUgaXMgc2V0IHRvIE5PLgovZXRjL3JjOiBERUJV
 RzogY2hlY2t5ZXNubzogZ2F0ZXdheTZfZW5hYmxlIGlzIHNldCB0byBZRVMuCi9ldGMvcmM6
 IERFQlVHOiBydW5fcmNfY29tbWFuZDogZG9pdDogL3Vzci9sb2NhbC9iaW4vZ3c2YyAgCkdh
 dGV3YXk2IENsaWVudCB2NS4wLVJFTEVBU0UgYnVpbGQgTWF5IDMxIDIwMDktMDA6MTE6MjYg
 ClNlcCAxMyAwMzo0NDozNSBtYXJ5LXRlcmVzYSBndzZjOiBHYXRld2F5NiBDbGllbnQgdjUu
 MC1SRUxFQVNFIGJ1aWxkIE1heSAzMSAyMDA5LTAwOjExOjI2IApSZWNlaXZlZCBhIFRTUCBy
 ZWRpcmVjdGlvbiBtZXNzYWdlIGZyb20gYnJva2VyIGF1dGhlbnRpY2F0ZWQuZnJlZW5ldDYu
 bmV0ICgxMjAwIFJlZGlyZWN0aW9uKS4KU2VwIDEzIDAzOjQ0OjM1IG1hcnktdGVyZXNhIGd3
 NmM6IFJlY2VpdmVkIGEgVFNQIHJlZGlyZWN0aW9uIG1lc3NhZ2UgZnJvbSBicm9rZXIgYXV0
 aGVudGljYXRlZC5mcmVlbmV0Ni5uZXQgKDEyMDAgUmVkaXJlY3Rpb25eTSkuClRoZSBicm9r
 ZXIgcmVkaXJlY3Rpb24gbGlzdCBpcyBbIGFtc3RlcmRhbS5mcmVlbmV0Ni5uZXQsIG1vbnRy
 ZWFsLmZyZWVuZXQ2Lm5ldCBdLgpTZXAgMTMgMDM6NDQ6MzUgbWFyeS10ZXJlc2EgZ3c2Yzog
 VGhlIGJyb2tlciByZWRpcmVjdGlvbiBsaXN0IGlzIFsgYW1zdGVyZGFtLmZyZWVuZXQ2Lm5l
 dCwgbW9udHJlYWwuZnJlZW5ldDYubmV0IF0uClRoZSBvcHRpbWl6ZWQgYnJva2VyIHJlZGly
 ZWN0aW9uIGxpc3QgaXMgWyBhbXN0ZXJkYW0uZnJlZW5ldDYubmV0LCBtb250cmVhbC5mcmVl
 bmV0Ni5uZXQgXS4KU2VwIDEzIDAzOjQ0OjM1IG1hcnktdGVyZXNhIGd3NmM6IFRoZSBvcHRp
 bWl6ZWQgYnJva2VyIHJlZGlyZWN0aW9uIGxpc3QgaXMgWyBhbXN0ZXJkYW0uZnJlZW5ldDYu
 bmV0LCBtb250cmVhbC5mcmVlbmV0Ni5uZXQgXS4KQ29ubmVjdGlvbiB0byBhbXN0ZXJkYW0u
 ZnJlZW5ldDYubmV0IGVzdGFibGlzaGVkLgpTZXAgMTMgMDM6NDQ6MzUgbWFyeS10ZXJlc2Eg
 Z3c2YzogQ29ubmVjdGlvbiB0byBhbXN0ZXJkYW0uZnJlZW5ldDYubmV0IGVzdGFibGlzaGVk
 LgovZXRjL3JjOiBERUJVRzogcGlkIGZpbGUgKC92YXIvcnVuL2NsYW1hdi9jbGFtZC5waWQp
 OiBub3QgcmVhZGFibGUuCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBjbGFtYXZfY2xh
 bWRfZW5hYmxlIGlzIHNldCB0byBZRVMuCi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFu
 ZDogc3RhcnRfcHJlY21kOiBjbGFtYXZfY2xhbWRfcHJlY21kIAppbjZfcHVyZ2VhZGRyOiBk
 ZWxldGlvbiBmYWlsZWQKL2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBkb2l0OiAv
 dXNyL2xvY2FsL3NiaW4vY2xhbWQgIApyZTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dO
 ClNlcCAxMyAwMzo0NDozNiBtYXJ5LXRlcmVzYSBzbm1wZFsyNDQ3XTogc2VuZDogQ29ubmVj
 dGlvbiByZWZ1c2VkClNlcCAxMyAwMzo0NDozNiBtYXJ5LXRlcmVzYSBydGFkdmRbMjY2MF06
 IDxyYV9vdXRwdXQ+IHNlbmRtc2cgb24gcmUwOiBDYW4ndCBhc3NpZ24gcmVxdWVzdGVkIGFk
 ZHJlc3MKU2VwIDEzIDAzOjQ0OjM2IG1hcnktdGVyZXNhIGd3NmM6IFlvdXIgSVB2NiBhZGRy
 ZXNzIGlzIDIwMDE6MDVjMDoxNDAwOjAwMGI6MDAwMDowMDAwOjAwMDA6MjdlOS4KU2VwIDEz
 IDAzOjQ0OjM2IG1hcnktdGVyZXNhIGd3NmM6IFlvdXIgSVB2NiBwcmVmaXggaXMgMjAwMTow
 NWMwOjE1MDM6MzQwMDowMDAwOjAwMDA6MDAwMDowMDAwLzU2LgpMaWJDbGFtQVYgV2Fybmlu
 ZzogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
 KioqKioqKioKTGliQ2xhbUFWIFdhcm5pbmc6ICoqKiAgVGhpcyB2ZXJzaW9uIG9mIHRoZSBD
 bGFtQVYgZW5naW5lIGlzIG91dGRhdGVkLiAgICAgKioqCkxpYkNsYW1BViBXYXJuaW5nOiAq
 KiogRE9OJ1QgUEFOSUMhIFJlYWQgaHR0cDovL3d3dy5jbGFtYXYubmV0L3N1cHBvcnQvZmFx
 ICoqKgpMaWJDbGFtQVYgV2FybmluZzogKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
 KioqKioqKioqKioqKioqKioqKioqKioqKioqKioKTGliQ2xhbUFWIFdhcm5pbmc6ICoqKioq
 KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
 CkxpYkNsYW1BViBXYXJuaW5nOiAqKiogIFRoaXMgdmVyc2lvbiBvZiB0aGUgQ2xhbUFWIGVu
 Z2luZSBpcyBvdXRkYXRlZC4gICAgICoqKgpMaWJDbGFtQVYgV2FybmluZzogKioqIERPTidU
 IFBBTklDISBSZWFkIGh0dHA6Ly93d3cuY2xhbWF2Lm5ldC9zdXBwb3J0L2ZhcSAqKioKTGli
 Q2xhbUFWIFdhcm5pbmc6ICoqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
 KioqKioqKioqKioqKioqKioqKioqCi9ldGMvcmM6IERFQlVHOiBwaWQgZmlsZSAoL3Zhci9y
 dW4vY2xhbWF2L2ZyZXNoY2xhbS5waWQpOiBub3QgcmVhZGFibGUuCi9ldGMvcmM6IERFQlVH
 OiBjaGVja3llc25vOiBjbGFtYXZfZnJlc2hjbGFtX2VuYWJsZSBpcyBzZXQgdG8gWUVTLgov
 ZXRjL3JjOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6IGRvaXQ6IC91c3IvbG9jYWwvYmluL2Zy
 ZXNoY2xhbSAgLS1kYWVtb24gLXAgL3Zhci9ydW4vY2xhbWF2L2ZyZXNoY2xhbS5waWQKL2V0
 Yy9yYzogREVCVUc6IHBpZCBmaWxlICgvdmFyL3J1bi9jbGFtYXYvY2xhbWF2LW1pbHRlci5w
 aWQpOiBub3QgcmVhZGFibGUuCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBjbGFtYXZf
 bWlsdGVyX2VuYWJsZSBpcyBzZXQgdG8gWUVTLgovZXRjL3JjOiBERUJVRzogcnVuX3JjX2Nv
 bW1hbmQ6IHN0YXJ0X3ByZWNtZDogc3RhcnRfcHJlY21kIAovZXRjL3JjOiBERUJVRzogY2hl
 Y2t5ZXNubzogY2xhbWF2X2NsYW1kX2VuYWJsZSBpcyBzZXQgdG8gWUVTLgpXYWl0aW5nIGZv
 ciBjbGFtZCBzb2NrZXQuLiAKCi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFuZDogZG9p
 dDogL3Vzci9sb2NhbC9zYmluL2NsYW1hdi1taWx0ZXIgLS1waWRmaWxlIC92YXIvcnVuL2Ns
 YW1hdi9jbGFtYXYtbWlsdGVyLnBpZCAtLWhlYWRlcnMgLS1wb3N0bWFzdGVyLW9ubHkgLS1l
 eHRlcm5hbCAtLW91dGdvaW5nIC0tbWF4LWNoaWxkcmVuPTUwIC92YXIvcnVuL2NsYW1hdi9j
 bG1pbHRlci5zb2NrIAovZXRjL3JjOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6IHN0YXJ0X3Bv
 c3RjbWQ6IHN0YXJ0X3Bvc3RjbWQgCldhaXRpbmcgZm9yIGNsYW1hdi1taWx0ZXIgc29ja2V0
 Li4gCgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogc2VuZG1haWxfZW5hYmxlIGlzIHNl
 dCB0byBZRVMuCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBzZW5kbWFpbF9zdWJtaXRf
 ZW5hYmxlIGlzIHNldCB0byBOTy4KL2V0Yy9yYzogREVCVUc6IHBpZCBmaWxlICgvdmFyL3J1
 bi9zZW5kbWFpbC5waWQpOiBub3QgcmVhZGFibGUuCi9ldGMvcmM6IERFQlVHOiBjaGVja3ll
 c25vOiBzZW5kbWFpbF9lbmFibGUgaXMgc2V0IHRvIFlFUy4KL2V0Yy9yYzogREVCVUc6IHJ1
 bl9yY19jb21tYW5kOiBzdGFydF9wcmVjbWQ6IHNlbmRtYWlsX3ByZWNtZCAKL2V0Yy9yYzog
 REVCVUc6IGNoZWNreWVzbm86IHNlbmRtYWlsX2VuYWJsZSBpcyBzZXQgdG8gWUVTLgovZXRj
 L3JjOiBERUJVRzogY2hlY2t5ZXNubzogc2VuZG1haWxfcmVidWlsZF9hbGlhc2VzIGlzIHNl
 dCB0byBOTy4KL2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBkb2l0OiAvdXNyL3Ni
 aW4vc2VuZG1haWwgLUwgc20tbXRhIC1iZCAtcTMwbSAKcmUwOiBsaW5rIHN0YXRlIGNoYW5n
 ZWQgdG8gVVAKL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IHNlbmRtYWlsX3N1Ym1pdF9l
 bmFibGUgaXMgc2V0IHRvIE5PLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogc2VuZG1h
 aWxfb3V0Ym91bmRfZW5hYmxlIGlzIHNldCB0byBOTy4KL2V0Yy9yYzogREVCVUc6IHBpZCBm
 aWxlICgvdmFyL3Nwb29sL2NsaWVudG1xdWV1ZS9zbS1jbGllbnQucGlkKTogbm90IHJlYWRh
 YmxlLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogc2VuZG1haWxfbXNwX3F1ZXVlX2Vu
 YWJsZSBpcyBzZXQgdG8gWUVTLgovZXRjL3JjOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6IHN0
 YXJ0X3ByZWNtZDogc2VuZG1haWxfcHJlY21kIAovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNu
 bzogc2VuZG1haWxfbXNwX3F1ZXVlX2VuYWJsZSBpcyBzZXQgdG8gWUVTLgovZXRjL3JjOiBE
 RUJVRzogY2hlY2t5ZXNubzogc2VuZG1haWxfcmVidWlsZF9hbGlhc2VzIGlzIHNldCB0byBO
 Ty4KL2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBkb2l0OiAvdXNyL3NiaW4vc2Vu
 ZG1haWwgLUwgc20tbXNwLXF1ZXVlIC1BYyAtcTMwbSAKL3Vzci9sb2NhbC9ldGMvcmMuZC9m
 ZXRjaG1haWw6IERFQlVHOiBjaGVja3llc25vOiBmZXRjaG1haWxfZW5hYmxlIGlzIHNldCB0
 byBZRVMuCi91c3IvbG9jYWwvZXRjL3JjLmQvZmV0Y2htYWlsOiBERUJVRzogcnVuX3JjX2Nv
 bW1hbmQ6IGRvaXQ6IHN1IC1tIGZldGNobWFpbCAtYyAnc2ggLWMgIi91c3IvbG9jYWwvYmlu
 L2ZldGNobWFpbCAtZiAvdXNyL2xvY2FsL2V0Yy9mZXRjaG1haWxyYyAJCQkJLS1waWRmaWxl
 IC92YXIvcnVuL2ZldGNobWFpbC9mZXRjaG1haWwucGlkIAkJCQktZCA5MDAgCQkJCS0tc3lz
 bG9nICInCmZldGNobWFpbDogY2FuJ3QgYWNjZXB0IG9wdGlvbnMgd2hpbGUgYSBiYWNrZ3Jv
 dW5kIGZldGNobWFpbCBpcyBydW5uaW5nLgovdXNyL2xvY2FsL2V0Yy9yYy5kL2ZldGNobWFp
 bDogV0FSTklORzogZmFpbGVkIHRvIHN0YXJ0IGZldGNobWFpbAovZXRjL3JjOiBERUJVRzog
 Y2hlY2t5ZXNubzogZG92ZWNvdF9lbmFibGUgaXMgc2V0IHRvIFlFUy4KL2V0Yy9yYzogREVC
 VUc6IGNoZWNreWVzbm86IGRvdmVjb3RfZW5hYmxlIGlzIHNldCB0byBZRVMuCi9ldGMvcmM6
 IERFQlVHOiBydW5fcmNfY29tbWFuZDogc3RhcnRfcHJlY21kOiBzdGFydF9wcmVjbWQgCi9l
 dGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFuZDogZG9pdDogL3Vzci9sb2NhbC9zYmluL2Rv
 dmVjb3QgIC1jIC91c3IvbG9jYWwvZXRjL2RvdmVjb3QuY29uZgpGYXRhbDogRG92ZWNvdCBp
 cyBhbHJlYWR5IHJ1bm5pbmcgd2l0aCBQSUQgMjUyMSAocmVhZCBmcm9tIC92YXIvcnVuL2Rv
 dmVjb3QvbWFzdGVyLnBpZCkKL2V0Yy9yYzogV0FSTklORzogZmFpbGVkIHRvIHN0YXJ0IGRv
 dmVjb3QKL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IGRkY2xpZW50X2VuYWJsZSBpcyBz
 ZXQgdG8gWUVTLgovZXRjL3JjOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6IGRvaXQ6IC91c3Iv
 bG9jYWwvc2Jpbi9kZGNsaWVudCAtZGFlbW9uIDMwMCAKL2V0Yy9yYzogREVCVUc6IGNoZWNr
 eWVzbm86IGJzZHN0YXRzX2VuYWJsZSBpcyBzZXQgdG8gWUVTLgovZXRjL3JjOiBERUJVRzog
 cnVuX3JjX2NvbW1hbmQ6IGRvaXQ6IC91c3IvbG9jYWwvZXRjL3BlcmlvZGljL21vbnRobHkv
 MzAwLnN0YXRpc3RpY3MgLW5vZGVsYXkgClBvc3RpbmcgbW9udGhseSBPUyBzdGF0aXN0aWNz
 IHRvIHJwdC5ic2RzdGF0cy5vcmcKbWV1aAovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzog
 YXJwd2F0Y2hfZW5hYmxlIGlzIHNldCB0byBOTy4KL2V0Yy9yYzogREVCVUc6IGNoZWNreWVz
 bm86IGFwYWNoZTIyX2h0dHBfYWNjZXB0X2VuYWJsZSBpcyBzZXQgdG8gWUVTLgovZXRjL3Jj
 OiBERUJVRzogY2hlY2t5ZXNubzogYXBhY2hlMjJfZW5hYmxlIGlzIHNldCB0byBZRVMuCi9l
 dGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFuZDogc3RhcnRfcHJlY21kOiBhcGFjaGUyMl9w
 cmVzdGFydCAKUGVyZm9ybWluZyBzYW5pdHkgY2hlY2sgb24gYXBhY2hlMjIgY29uZmlndXJh
 dGlvbjoKU3ludGF4IE9LCi9ldGMvcmM6IERFQlVHOiBjaGVja3llc25vOiBhcGFjaGUyMmxp
 bWl0c19lbmFibGUgaXMgc2V0IHRvIE5PLgovZXRjL3JjOiBERUJVRzogcnVuX3JjX2NvbW1h
 bmQ6IGRvaXQ6IC91c3IvbG9jYWwvc2Jpbi9odHRwZCAgCig0OClBZGRyZXNzIGFscmVhZHkg
 aW4gdXNlOiBtYWtlX3NvY2s6IGNvdWxkIG5vdCBiaW5kIHRvIGFkZHJlc3MgMC4wLjAuMDo4
 MApubyBsaXN0ZW5pbmcgc29ja2V0cyBhdmFpbGFibGUsIHNodXR0aW5nIGRvd24KVW5hYmxl
 IHRvIG9wZW4gbG9ncwovZXRjL3JjOiBXQVJOSU5HOiBmYWlsZWQgdG8gc3RhcnQgYXBhY2hl
 MjIKL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IG5pc195cHhmcmRfZW5hYmxlIGlzIHNl
 dCB0byBOTy4KL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IHJwY195cHVwZGF0ZWRfZW5h
 YmxlIGlzIHNldCB0byBOTy4KL2V0Yy9yYzogREVCVUc6IHBpZCBmaWxlICgvdmFyL3J1bi93
 YXRjaGRvZ2QucGlkKTogbm90IHJlYWRhYmxlLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNu
 bzogd2F0Y2hkb2dkX2VuYWJsZSBpcyBzZXQgdG8gTk8uCi9ldGMvcmM6IERFQlVHOiBydW5f
 cmNfY29tbWFuZDogc3RhcnRfcHJlY21kOiBzeXNjb25zX3ByZWNtZCAKL2V0Yy9yYzogREVC
 VUc6IHJ1bl9yY19jb21tYW5kOiBkb2l0OiBzeXNjb25zX3N0YXJ0IApDb25maWd1cmluZyBz
 eXNjb25zOgoga2V5bWFwCiBibGFua3RpbWUKLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNu
 bzogc3NoZF9lbmFibGUgaXMgc2V0IHRvIFlFUy4KL2V0Yy9yYzogREVCVUc6IHJ1bl9yY19j
 b21tYW5kOiBzdGFydF9wcmVjbWQ6IHNzaGRfcHJlY21kIAovZXRjL3JjOiBERUJVRzogcnVu
 X3JjX2NvbW1hbmQ6IGRvaXQ6IC91c3Ivc2Jpbi9zc2hkICAKU2VwIDEzIDAzOjQ0OjQzIG1h
 cnktdGVyZXNhIHNzaGRbMzMyMV06IGVycm9yOiBCaW5kIHRvIHBvcnQgMjIgb24gOjogZmFp
 bGVkOiBBZGRyZXNzIGFscmVhZHkgaW4gdXNlLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNu
 bzogY3Jvbl9kc3QgaXMgc2V0IHRvIFlFUy4KL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86
 IGNyb25fZW5hYmxlIGlzIHNldCB0byBZRVMuCi9ldGMvcmM6IERFQlVHOiBydW5fcmNfY29t
 bWFuZDogZG9pdDogL3Vzci9zYmluL2Nyb24gIC1zIApjcm9uOiBjcm9uIGFscmVhZHkgcnVu
 bmluZywgcGlkOiAyNDI5Ci9ldGMvcmM6IFdBUk5JTkc6IGZhaWxlZCB0byBzdGFydCBjcm9u
 ClNlcCAxMyAwMzo0NDo0MyBtYXJ5LXRlcmVzYSBzc2hkWzMzMjFdOiBlcnJvcjogQmluZCB0
 byBwb3J0IDIyIG9uIDAuMC4wLjAgZmFpbGVkOiBBZGRyZXNzIGFscmVhZHkgaW4gdXNlLgpT
 ZXAgMTMgMDM6NDQ6NDMgbWFyeS10ZXJlc2Egc3NoZFszMzIxXTogZmF0YWw6IENhbm5vdCBi
 aW5kIGFueSBhZGRyZXNzLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogamFpbF9lbmFi
 bGUgaXMgc2V0IHRvIE5PLgovZXRjL3JjOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6IGRvaXQ6
 IHBrZ19zdGFydCAKTG9jYWwgcGFja2FnZSBpbml0aWFsaXphdGlvbjoKL3Vzci9sb2NhbC9l
 dGMvcmMuZC9uZ25hdC5zaDogREVCVUc6IGNoZWNreWVzbm86IG5nbmF0X2VuYWJsZSBpcyBz
 ZXQgdG8gWUVTLgovdXNyL2xvY2FsL2V0Yy9yYy5kL25nbmF0LnNoOiBERUJVRzogcnVuX3Jj
 X2NvbW1hbmQ6IGRvaXQ6IG5nbmF0X3N0YXJ0IApTZXR1cCBuZ19uYXQgYW5kIG5nX25ldGZs
 b3cKbmdjdGw6IApzZW5kIG1zZwo6IApGaWxlIGV4aXN0cwpuZ2N0bDogCmxpbmUgMTogZXJy
 b3IgaW4gZmlsZQoKLgovZXRjL3JjLmQvc3lzY3RsOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6
 IGRvaXQ6IHN5c2N0bF9zdGFydCBsYXN0IAovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzog
 a2Vybl9zZWN1cmVsZXZlbF9lbmFibGUgaXMgc2V0IHRvIE5PLgovZXRjL3JjOiBERUJVRzog
 Y2hlY2t5ZXNubzogbmZzY2JkX2VuYWJsZSBpcyBzZXQgdG8gTk8uCi9ldGMvcmM6IERFQlVH
 OiBwaWQgZmlsZSAoL3Zhci9ydW4vbW91c2VkLnBpZCk6IG5vdCByZWFkYWJsZS4KL2V0Yy9y
 YzogREVCVUc6IGNoZWNreWVzbm86IG1vdXNlZF9lbmFibGUgaXMgc2V0IHRvIE5PLgovZXRj
 L3JjOiBERUJVRzogY2hlY2t5ZXNubzogbWl4ZXJfZW5hYmxlIGlzIHNldCB0byBZRVMuCi9l
 dGMvcmM6IERFQlVHOiBydW5fcmNfY29tbWFuZDogZG9pdDogbWl4ZXJfc3RhcnQgCi9ldGMv
 cmM6IERFQlVHOiBydW5fcmNfY29tbWFuZDogZG9pdDoga2VybmVsX3N0YXJ0IAovZXRjL3Jj
 OiBERUJVRzogcGlkIGZpbGUgKC92YXIvcnVuL2lzZG5kLnBpZCk6IG5vdCByZWFkYWJsZS4K
 L2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IGlzZG5fZW5hYmxlIGlzIHNldCB0byAuCi9l
 dGMvcmM6IFdBUk5JTkc6ICRpc2RuX2VuYWJsZSBpcyBub3Qgc2V0IHByb3Blcmx5IC0gc2Vl
 IHJjLmNvbmYoNSkuCi9ldGMvcmM6IERFQlVHOiBwaWQgZmlsZSAoL3Zhci9ydW4vaW5ldGQu
 cGlkKTogbm90IHJlYWRhYmxlLgovZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogaW5ldGRf
 ZW5hYmxlIGlzIHNldCB0byBOTy4KL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IGlkbWFw
 ZF9lbmFibGUgaXMgc2V0IHRvIC4KL2V0Yy9yYzogV0FSTklORzogJGlkbWFwZF9lbmFibGUg
 aXMgbm90IHNldCBwcm9wZXJseSAtIHNlZSByYy5jb25mKDUpLgovZXRjL3JjOiBERUJVRzog
 cGlkIGZpbGUgKC92YXIvcnVuL2hvc3RhcGQucGlkKTogbm90IHJlYWRhYmxlLgovZXRjL3Jj
 OiBERUJVRzogY2hlY2t5ZXNubzogaG9zdGFwZF9lbmFibGUgaXMgc2V0IHRvIE5PLgovZXRj
 L3JjOiBERUJVRzogcnVuX3JjX2NvbW1hbmQ6IGRvaXQ6IGdlbGkyX3N0YXJ0IAovZXRjL3Jj
 OiBERUJVRzogcGlkIGZpbGUgKC92YXIvcnVuL2Z0cGQucGlkKTogbm90IHJlYWRhYmxlLgov
 ZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogZnRwZF9lbmFibGUgaXMgc2V0IHRvIE5PLgov
 ZXRjL3JjOiBERUJVRzogY2hlY2t5ZXNubzogZnRwcHJveHlfZW5hYmxlIGlzIHNldCB0byBO
 Ty4KL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86IGJzbm1wZF9lbmFibGUgaXMgc2V0IHRv
 IFlFUy4KL2V0Yy9yYzogREVCVUc6IHJ1bl9yY19jb21tYW5kOiBkb2l0OiAvdXNyL3NiaW4v
 YnNubXBkIC1EIGR1bXAgClNlcCAxMyAwMzo0NDo0MyBtYXJ5LXRlcmVzYSBzbm1wZFszNDMz
 XTogYmluZDogMC4wLjAuMDoxNjEgQWRkcmVzcyBhbHJlYWR5IGluIHVzZQpTZXAgMTMgMDM6
 NDQ6NDMgbWFyeS10ZXJlc2Egc25tcGRbMzQzM106IE5nTWtTb2NrTm9kZTogQWRkcmVzcyBh
 bHJlYWR5IGluIHVzZQpTZXAgMTMgMDM6NDQ6NDMgbWFyeS10ZXJlc2Egc25tcGRbMzQzM106
 IGFzc2lnbm1lbnQgdG8gYmVnZW1vdE5nQ29udHJvbE5vZGVOYW1lLjAgcmV0dXJucyA1ClNl
 cCAxMyAwMzo0NDo0MyBtYXJ5LXRlcmVzYSBzbm1wZFszNDMzXTogICBpbiBmaWxlIC9ldGMv
 c25tcGQuY29uZmlnIGxpbmUgODEKU2VwIDEzIDAzOjQ0OjQzIG1hcnktdGVyZXNhIHNubXBk
 WzM0MzNdOiBlcnJvciBpbiBjb25maWcgZmlsZQovZXRjL3JjOiBERUJVRzogcnVuX3JjX2Nv
 bW1hbmQ6IGRvaXQ6IGJyaWRnZV9zdGFydCAKL2V0Yy9yYzogREVCVUc6IGNoZWNreWVzbm86
 IGJhY2tncm91bmRfZnNjayBpcyBzZXQgdG8gWUVTLgovZXRjL3JjOiBERUJVRzogcnVuX3Jj
 X2NvbW1hbmQ6IGRvaXQ6IGJnZnNja19zdGFydCAKClN1biBTZXAgMTMgMDM6NDQ6NDMgRUVT
 VCAyMDA5CnBpZCA0MjE2IChpc29xbG9nKSwgdWlkIDA6IGV4aXRlZCBvbiBzaWduYWwgMTEg
 KGNvcmUgZHVtcGVkKQpwaWQgODI3OSAoaXNvcWxvZyksIHVpZCAwOiBleGl0ZWQgb24gc2ln
 bmFsIDExIChjb3JlIGR1bXBlZCkKcGlkIDExMDk0IChpc29xbG9nKSwgdWlkIDA6IGV4aXRl
 ZCBvbiBzaWduYWwgMTEgKGNvcmUgZHVtcGVkKQpwaWQgMTUyMzAgKGlzb3Fsb2cpLCB1aWQg
 MDogZXhpdGVkIG9uIHNpZ25hbCAxMSAoY29yZSBkdW1wZWQpCnBpZCAxNzk3OCAoaXNvcWxv
 ZyksIHVpZCAwOiBleGl0ZWQgb24gc2lnbmFsIDExIChjb3JlIGR1bXBlZCkKcGlkIDIyMDY5
 IChpc29xbG9nKSwgdWlkIDA6IGV4aXRlZCBvbiBzaWduYWwgMTEgKGNvcmUgZHVtcGVkKQpw
 aWQgMjQ3NTYgKGlzb3Fsb2cpLCB1aWQgMDogZXhpdGVkIG9uIHNpZ25hbCAxMSAoY29yZSBk
 dW1wZWQpCnBpZCAyODczMSAoaXNvcWxvZyksIHVpZCAwOiBleGl0ZWQgb24gc2lnbmFsIDEx
 IChjb3JlIGR1bXBlZCkKcGlkIDMxNDIyIChpc29xbG9nKSwgdWlkIDA6IGV4aXRlZCBvbiBz
 aWduYWwgMTEgKGNvcmUgZHVtcGVkKQpwaWQgMzUzNzAgKGlzb3Fsb2cpLCB1aWQgMDogZXhp
 dGVkIG9uIHNpZ25hbCAxMSAoY29yZSBkdW1wZWQpCnBpZCAzODA0NiAoaXNvcWxvZyksIHVp
 ZCAwOiBleGl0ZWQgb24gc2lnbmFsIDExIChjb3JlIGR1bXBlZCkKcGlkIDQyMDE5IChpc29x
 bG9nKSwgdWlkIDA6IGV4aXRlZCBvbiBzaWduYWwgMTEgKGNvcmUgZHVtcGVkKQpwaWQgNDQ2
 ODkgKGlzb3Fsb2cpLCB1aWQgMDogZXhpdGVkIG9uIHNpZ25hbCAxMSAoY29yZSBkdW1wZWQp
 ClNlcCAxMyAxNjo1MDoxMiBtYXJ5LXRlcmVzYSBzdTogdmxhZDExIHRvIHJvb3Qgb24gL2Rl
 di9wdHMvMQpwaWQgNDgyMzMgKGhvc3QpLCB1aWQgMDogZXhpdGVkIG9uIHNpZ25hbCA2IChj
 b3JlIGR1bXBlZCkKcGlkIDQ4MjU3IChob3N0KSwgdWlkIDA6IGV4aXRlZCBvbiBzaWduYWwg
 NiAoY29yZSBkdW1wZWQpCnBpZCA0ODI2MSAoaG9zdCksIHVpZCAwOiBleGl0ZWQgb24gc2ln
 bmFsIDYgKGNvcmUgZHVtcGVkKQpwaWQgNDg1MDYgKGlzb3Fsb2cpLCB1aWQgMDogZXhpdGVk
 IG9uIHNpZ25hbCAxMSAoY29yZSBkdW1wZWQpCnBpZCA1MTI0NSAoaXNvcWxvZyksIHVpZCAw
 OiBleGl0ZWQgb24gc2lnbmFsIDExIChjb3JlIGR1bXBlZCkKcGFuaWM6IHNiZmx1c2hfaW50
 ZXJuYWw6IGNjIDAgfHwgbWIgMHhmZmZmZmYwMDQxMjdiMDAwIHx8IG1iY250IDIzMDQKY3B1
 aWQgPSAxClVwdGltZTogMTRoNDJtNTJzClBoeXNpY2FsIG1lbW9yeTogNjA5OCBNQgpEdW1w
 aW5nIDE3MjkgTUI6IDE3MTQgMTY5OCAxNjgyIDE2NjYgMTY1MCAxNjM0IDE2MTggMTYwMiAx
 NTg2IDE1NzAgMTU1NCAxNTM4IDE1MjIgMTUwNiAxNDkwIDE0NzQgMTQ1OCAxNDQyIDE0MjYg
 MTQxMCAxMzk0IDEzNzggMTM2MiAxMzQ2IDEzMzAgMTMxNCAxMjk4IDEyODIgMTI2NiAxMjUw
 IDEyMzQgMTIxOCAxMjAyIDExODYgMTE3MCAxMTU0IDExMzggMTEyMiAxMTA2IDEwOTAgMTA3
 NCAxMDU4IDEwNDIgMTAyNiAxMDEwIDk5NCA5NzggOTYyIDk0NiA5MzAgOTE0IDg5OCA4ODIg
 ODY2IDg1MCA4MzQgODE4IDgwMiA3ODYgNzcwIDc1NCA3MzggNzIyIDcwNiA2OTAgNjc0IDY1
 OCA2NDIgNjI2IDYxMCA1OTQgNTc4IDU2MiA1NDYgNTMwIDUxNCA0OTggNDgyIDQ2NiA0NTAg
 NDM0IDQxOCA0MDIgMzg2IDM3MCAzNTQgMzM4IDMyMiAzMDYgMjkwIDI3NCAyNTggMjQyIDIy
 NiAyMTAgMTk0IDE3OCAxNjIgMTQ2IDEzMCAxMTQgOTggODIgNjYgNTAgMzQgMTggMgoKLS0t
 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
 LS0tLS0tLS0tLS0tLS0tCmtlcm5lbCBjb25maWcKCmNvbmZpZzogRmlsZSAvYm9vdC9rZXJu
 ZWwva2VybmVsIGRvZXNuJ3QgY29udGFpbiBjb25maWd1cmF0aW9uIGZpbGUuIEVpdGhlciB1
 bnN1cHBvcnRlZCwgb3Igbm90IGNvbXBpbGVkIHdpdGggSU5DTFVERV9DT05GSUdfRklMRQo=
 --------------000404040105020802090300--
From ccowart at rescomp.berkeley.edu  Mon Sep 14 17:43:10 2009
From: ccowart at rescomp.berkeley.edu (Chris Cowart)
Date: Mon Sep 14 17:43:16 2009
Subject: 8.0-BETA4 not responding to ARP for published entries
Message-ID: <20090914174309.GF37291@hal.rescomp.berkeley.edu>

Hello,

We have a system which makes heavy use of published arp entries. I know
the arp code has been significantly overhauled in 8, but it looks like
this functionality is now broken.

$ arp -s 172.16.132.100 00:0c:29:16:bd:49 pub

If I watch tcpdump on the interface, I see arp requests come in but no
replies are sent. This is a clean build with no firewalls enabled.

The syntax and descriptions don't appear to have changed in the man
page, so I would expect this to still work as it has in the past.

Please let me know if you need any other information and/or if I should
get a PR open for this. If this is a regression, it would be great if it
could get committed before the 8.0 release.

Thanks,

-- 
Chris Cowart
Network Technical Lead
Network & Infrastructure Services, RSSP-IT
UC Berkeley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090914/1e828f95/attachment.pgp
From qing.li at bluecoat.com  Mon Sep 14 17:54:55 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Mon Sep 14 17:55:01 2009
Subject: 8.0-BETA4 not responding to ARP for published entries
References: <20090914174309.GF37291@hal.rescomp.berkeley.edu>
Message-ID: <B583FBF374231F4A89607B4D08578A43046736AA@bcs-mail03.internal.cacheflow.com>


Could you please email me your routing table privately?

Thanks,

-- Qing


-----Original Message-----
From: owner-freebsd-net@freebsd.org on behalf of Chris Cowart
Sent: Mon 9/14/2009 10:43 AM
To: freebsd-net@freebsd.org
Subject: 8.0-BETA4 not responding to ARP for published entries
 
Hello,

We have a system which makes heavy use of published arp entries. I know
the arp code has been significantly overhauled in 8, but it looks like
this functionality is now broken.

$ arp -s 172.16.132.100 00:0c:29:16:bd:49 pub

If I watch tcpdump on the interface, I see arp requests come in but no
replies are sent. This is a clean build with no firewalls enabled.

The syntax and descriptions don't appear to have changed in the man
page, so I would expect this to still work as it has in the past.

Please let me know if you need any other information and/or if I should
get a PR open for this. If this is a regression, it would be great if it
could get committed before the 8.0 release.

Thanks,

-- 
Chris Cowart
Network Technical Lead
Network & Infrastructure Services, RSSP-IT
UC Berkeley

From edwarddean3 at gmail.com  Mon Sep 14 18:06:22 2009
From: edwarddean3 at gmail.com (Edward Dean)
Date: Mon Sep 14 18:06:31 2009
Subject: bpf issues
Message-ID: <d8a11c3b0909141040o5a3d7f81t79525485bfe8a9ad@mail.gmail.com>

Good day,

I hope this is the appropriate list.  I am having issues using BPFs to
filter out traffic captures.  If I want to block a specific host by IP, the
traffic is still recorded.  I tried tcpdump and get the same results.

Am I missing something?

Examples:

# tcpdump -nt -i igb2 -w tcpdump.pcap not host 10.100.66.31
# tcpdump -nt -r tcpdump.pcap | less
IP 10.100.66.31.13724 > 10.100.66.30.3090: . 42904:44352(1448) ack 1 win
64340 <nop,nop,timestamp 1324022 586994>
IP 10.100.66.31.13724 > 10.100.66.30.3090: . 44352:45800(1448) ack 1 win
64340 <nop,nop,timestamp 1324022 586994>
IP 10.100.66.30.3090 > 10.100.66.31.13724: . ack 5792 win 65535
<nop,nop,timestamp 587015 1324022>
IP 10.100.66.31.13724 > 10.100.66.30.3090: . 45800:47248(1448) ack 1 win
64340 <nop,nop,timestamp 1324022 586994>

It gets stranger, if I read the pcap file and filter for the host it returns
blank:

# tcpdump -nt -r tcpdump.pcap host 10.100.66.31
reading from file tcpdump.pcap, link-type EN10MB (Ethernet)
#

I have tried several variations of syntax and had no luck.  Also used
several tools (tcpdump, tshark, daemonlogger) and have had the  same results
so I suspect it may be libpcap related.  The system is running FreeBSD 7.2
GENERIC amd64

Any suggestions would be much appreciated.

Cheers!
From sthaug at nethelp.no  Mon Sep 14 19:23:33 2009
From: sthaug at nethelp.no (sthaug@nethelp.no)
Date: Mon Sep 14 19:24:15 2009
Subject: bpf issues
In-Reply-To: <d8a11c3b0909141040o5a3d7f81t79525485bfe8a9ad@mail.gmail.com>
References: <d8a11c3b0909141040o5a3d7f81t79525485bfe8a9ad@mail.gmail.com>
Message-ID: <20090914.212330.74729619.sthaug@nethelp.no>

> I hope this is the appropriate list.  I am having issues using BPFs to
> filter out traffic captures.  If I want to block a specific host by IP, the
> traffic is still recorded.  I tried tcpdump and get the same results.
> 
> Am I missing something?

Does your igb2 interface use VLAN encapsulation? If it does, you won't
see it in the tcpdump output unless you use -e, but you still need to
specify it together with your IP based filters - or tcpdump will apply
the wrong (off by 4 bytes) offset.

E.g. "tcpdump -nt -r tcpdump.pcap vlan and host 10.100.66.31"

Steinar Haug, Nethelp consulting, sthaug@nethelp.no
From tamaru at myn.rcast.u-tokyo.ac.jp  Tue Sep 15 02:09:16 2009
From: tamaru at myn.rcast.u-tokyo.ac.jp (Hiroharu Tamaru)
Date: Tue Sep 15 02:09:23 2009
Subject: 8.0-BETA4 not responding to ARP for published entries
In-Reply-To: <20090914174309.GF37291@hal.rescomp.berkeley.edu>
	<sa6ws9ba7pc.wl%tamaru@myn.rcast.u-tokyo.ac.jp>
References: <20090914174309.GF37291@hal.rescomp.berkeley.edu>
Message-ID: <sa61vm97zyk.wl%tamaru@myn.rcast.u-tokyo.ac.jp>


At Mon, 14 Sep 2009 10:43:09 -0700, Chris Cowart wrote:
> We have a system which makes heavy use of published arp entries. I know
> the arp code has been significantly overhauled in 8, but it looks like
> this functionality is now broken.
> 
> $ arp -s 172.16.132.100 00:0c:29:16:bd:49 pub
> 
> If I watch tcpdump on the interface, I see arp requests come in but no
> replies are sent. This is a clean build with no firewalls enabled.

Just for another datapoint, I see the same symptom.
I am currently running ports/net-mgmt/choparp as a workaround.

At Thu, 23 Apr 2009 21:13:51 +0900, Hiroharu Tamaru wrote:
> Subject: proxy arp on 8.0-current?
> Date: Thu, 23 Apr 2009 21:13:51 +0900
> To: freebsd-net@freebsd.org
>
> Hi,
> 
> I'm trying to setup an proxy arp on a dual homed host.
> 
> I noticed that I cannot set it up on 8.0-current the same way as I
> could on 6.2; hence the question: have the setup procedure changed
> recently (when the arp table was separated from the routing table,
> maybe?)?  My 8.0-current is from 200902 snapshot.
> 
> Here is a simple demonstration using two single-interfaced hosts:
> 
> setup:
> host6.2# ifconfig em0 inet 192.168.0.1/24
> host6.2# arp -s 192.168.0.11 auto pub
> host6.2# arp -an | grep permanent
> ? (192.168.0.1) at 00:16:d3:xx:xx:xx on em0 permanent [ethernet]
> ? (192.168.0.11) at 00:16:d3:xx:xx:xx on em0 permanent published [ethernet]
> host6.2# tcpdump -np arp
> 
> host8.0# ifconfig em0 inet 192.168.0.2/24
> host8.0# arp -s 192.168.0.12 auto pub
> host8.0# arp -an | grep permanent
> ? (192.168.0.2) at 00:0c:29:xx:xx:xx on em0 permanent [ethernet]
> ? (192.168.0.12) at 00:0c:29:xx:xx:xx on em0 permanent published [ethernet]
> host8.0# tcpdump -np arp
> 
> then, I do:
> host6.2# arp -d 192.168.0.2;  ping -c 1 192.168.0.2
> host6.2# arp -d 192.168.0.12; ping -c 1 192.168.0.12
> host8.0# arp -d 192.168.0.1;  ping -c 1 192.168.0.1
> host8.0# arp -d 192.168.0.11; ping -c 1 192.168.0.11
> 
> I am not caring about 'arp -d' errors (cannot locate) nor ping not
> responding (for proxied addresses).  I just cared about arp requests and
> replys for now.  The output of tcpdump on both sides are like this:
> 
>  arp who-has 192.168.0.2 tell 192.168.0.1
>  arp reply 192.168.0.2 is-at 00:0c:29:xx:xx:xx
> 
>  arp who-has 192.168.0.12 tell 192.168.0.1
> ---->no reply
> 
>  arp who-has 192.168.0.1 tell 192.168.0.2
>  arp reply 192.168.0.1 is-at 00:16:d3:xx:xx:xx
> 
>  arp who-has 192.168.0.11 tell 192.168.0.2
>  arp reply 192.168.0.11 is-at 00:16:d3:xx:xx:xx
> 
> As you can see from the above,
> 'arp -s 192.168.0.12 auto pub' on 8.0-current host
> seems not to be producing proxy arp's.
> 
> What am I missing?
> 
> Thanks.
> -- 
> Hiroharu Tamaru
From qing.li at bluecoat.com  Tue Sep 15 04:58:53 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Tue Sep 15 04:59:06 2009
Subject: 8.0-BETA4 not responding to ARP for published entries
References: <20090914174309.GF37291@hal.rescomp.berkeley.edu>
	<sa61vm97zyk.wl%tamaru@myn.rcast.u-tokyo.ac.jp>
Message-ID: <B583FBF374231F4A89607B4D08578A43046736AD@bcs-mail03.internal.cacheflow.com>


Hi,

Please try patch at 

   http://people.freebsd.org/~qingli/proxy-arp-patch.diff

-- Qing



-----Original Message-----
From: owner-freebsd-net@freebsd.org on behalf of Hiroharu Tamaru
Sent: Mon 9/14/2009 6:34 PM
To: freebsd-net@freebsd.org
Subject: Re: 8.0-BETA4 not responding to ARP for published entries
 

At Mon, 14 Sep 2009 10:43:09 -0700, Chris Cowart wrote:
> We have a system which makes heavy use of published arp entries. I know
> the arp code has been significantly overhauled in 8, but it looks like
> this functionality is now broken.
> 
> $ arp -s 172.16.132.100 00:0c:29:16:bd:49 pub
> 
> If I watch tcpdump on the interface, I see arp requests come in but no
> replies are sent. This is a clean build with no firewalls enabled.

Just for another datapoint, I see the same symptom.
I am currently running ports/net-mgmt/choparp as a workaround.

At Thu, 23 Apr 2009 21:13:51 +0900, Hiroharu Tamaru wrote:
> Subject: proxy arp on 8.0-current?
> Date: Thu, 23 Apr 2009 21:13:51 +0900
> To: freebsd-net@freebsd.org
>
> Hi,
> 
> I'm trying to setup an proxy arp on a dual homed host.
> 
> I noticed that I cannot set it up on 8.0-current the same way as I
> could on 6.2; hence the question: have the setup procedure changed
> recently (when the arp table was separated from the routing table,
> maybe?)?  My 8.0-current is from 200902 snapshot.
> 
> Here is a simple demonstration using two single-interfaced hosts:
> 
> setup:
> host6.2# ifconfig em0 inet 192.168.0.1/24
> host6.2# arp -s 192.168.0.11 auto pub
> host6.2# arp -an | grep permanent
> ? (192.168.0.1) at 00:16:d3:xx:xx:xx on em0 permanent [ethernet]
> ? (192.168.0.11) at 00:16:d3:xx:xx:xx on em0 permanent published [ethernet]
> host6.2# tcpdump -np arp
> 
> host8.0# ifconfig em0 inet 192.168.0.2/24
> host8.0# arp -s 192.168.0.12 auto pub
> host8.0# arp -an | grep permanent
> ? (192.168.0.2) at 00:0c:29:xx:xx:xx on em0 permanent [ethernet]
> ? (192.168.0.12) at 00:0c:29:xx:xx:xx on em0 permanent published [ethernet]
> host8.0# tcpdump -np arp
> 
> then, I do:
> host6.2# arp -d 192.168.0.2;  ping -c 1 192.168.0.2
> host6.2# arp -d 192.168.0.12; ping -c 1 192.168.0.12
> host8.0# arp -d 192.168.0.1;  ping -c 1 192.168.0.1
> host8.0# arp -d 192.168.0.11; ping -c 1 192.168.0.11
> 
> I am not caring about 'arp -d' errors (cannot locate) nor ping not
> responding (for proxied addresses).  I just cared about arp requests and
> replys for now.  The output of tcpdump on both sides are like this:
> 
>  arp who-has 192.168.0.2 tell 192.168.0.1
>  arp reply 192.168.0.2 is-at 00:0c:29:xx:xx:xx
> 
>  arp who-has 192.168.0.12 tell 192.168.0.1
> ---->no reply
> 
>  arp who-has 192.168.0.1 tell 192.168.0.2
>  arp reply 192.168.0.1 is-at 00:16:d3:xx:xx:xx
> 
>  arp who-has 192.168.0.11 tell 192.168.0.2
>  arp reply 192.168.0.11 is-at 00:16:d3:xx:xx:xx
> 
> As you can see from the above,
> 'arp -s 192.168.0.12 auto pub' on 8.0-current host
> seems not to be producing proxy arp's.
> 
> What am I missing?
> 
> Thanks.
> -- 
> Hiroharu Tamaru
_______________________________________________
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 peterjeremy at acm.org  Tue Sep 15 07:38:33 2009
From: peterjeremy at acm.org (peterjeremy@acm.org)
Date: Tue Sep 15 07:38:40 2009
Subject: [POLLING] strange interrupt/system load
In-Reply-To: <94372.57247.qm@web63906.mail.re1.yahoo.com>
References: <4AACEF9E.90303@mail.ru>
	<94372.57247.qm@web63906.mail.re1.yahoo.com>
Message-ID: <20090915073830.GC48679@server.vk2pj.dyndns.org>

On 2009-Sep-13 07:19:24 -0700, Barney Cordoba <barney_cordoba@yahoo.com> wrote:
>64bits must be faster than 32bits is patently misguided. My rule of 
>thumb is that if I don't need 64bits for something, I avoid it.

It's not quite that cut-and-dry.  The 64-bit ISA is significantly
different to the 32-bit ISA and has different subroutine calling
conventions.  Yes, you do need to lug 64-bit pointers around but the
overall codesize is comparable (looking at /usr/bin and /lib suggests
about a 5% increase in size going from i386 to amd64) - a lot of this
is probably because amd64 has a 16-bit offset mode so there's much
less need for 32-bit offsets.  Having twice as many registers is a
win in some areas (less spilling to memory) and a loss in others (more
state to save/restore on a context switch).

If performance is critical, it's probably worthwhile benchmarking
both i386 and amd64 variants and seeing which works best for you.

-- 
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090915/7eb6d826/attachment.pgp
From barney_cordoba at yahoo.com  Tue Sep 15 11:33:09 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Tue Sep 15 11:33:16 2009
Subject: [POLLING] strange interrupt/system load
In-Reply-To: <20090915073830.GC48679@server.vk2pj.dyndns.org>
Message-ID: <518979.77721.qm@web63907.mail.re1.yahoo.com>



--- On Tue, 9/15/09, peterjeremy@acm.org <peterjeremy@acm.org> wrote:

> From: peterjeremy@acm.org <peterjeremy@acm.org>
> Subject: Re: [POLLING] strange interrupt/system load
> To: "Barney Cordoba" <barney_cordoba@yahoo.com>
> Cc: freebsd-net@freebsd.org
> Date: Tuesday, September 15, 2009, 3:38 AM
> On 2009-Sep-13 07:19:24 -0700, Barney
> Cordoba <barney_cordoba@yahoo.com>
> wrote:
> >64bits must be faster than 32bits is patently
> misguided. My rule of 
> >thumb is that if I don't need 64bits for something, I
> avoid it.
> 
> It's not quite that cut-and-dry.? The 64-bit ISA is
> significantly
> different to the 32-bit ISA and has different subroutine
> calling
> conventions.? Yes, you do need to lug 64-bit pointers
> around but the
> overall codesize is comparable (looking at /usr/bin and
> /lib suggests
> about a 5% increase in size going from i386 to amd64) - a
> lot of this
> is probably because amd64 has a 16-bit offset mode so
> there's much
> less need for 32-bit offsets.? Having twice as many
> registers is a
> win in some areas (less spilling to memory) and a loss in
> others (more
> state to save/restore on a context switch).
> 
> If performance is critical, it's probably worthwhile
> benchmarking
> both i386 and amd64 variants and seeing which works best
> for you.
> 
"Rules of Thumb" are generally for those times when you don't have
a pressing preference and you don't want to spend your life endlessly
benchmarking.

I don't think its the code, necessarity, but rather the significant
increase in the size of data structures, and the memory that has to
be moved around.

I haven't tried with the latest compiler but I can't see why it would
have any benefit for systems used for high capacity networking other than
incrementing counters. 

Barney


      

From tamaru at myn.rcast.u-tokyo.ac.jp  Tue Sep 15 14:03:20 2009
From: tamaru at myn.rcast.u-tokyo.ac.jp (Hiroharu Tamaru)
Date: Tue Sep 15 14:03:27 2009
Subject: 8.0-BETA4 not responding to ARP for published entries
In-Reply-To: <B583FBF374231F4A89607B4D08578A43046736AD@bcs-mail03.internal.cacheflow.com>
References: <20090914174309.GF37291@hal.rescomp.berkeley.edu>
	<sa61vm97zyk.wl%tamaru@myn.rcast.u-tokyo.ac.jp>
	<B583FBF374231F4A89607B4D08578A43046736AD@bcs-mail03.internal.cacheflow.com>
Message-ID: <sa6zl8w71bf.wl%tamaru@myn.rcast.u-tokyo.ac.jp>

Hi,

At Mon, 14 Sep 2009 21:50:47 -0700, Li, Qing wrote:
> Hi,
> 
> Please try patch at 
> 
>    http://people.freebsd.org/~qingli/proxy-arp-patch.diff
> 
> -- Qing

Thanks for taking care of it.

I tried it, and now proxy arp works on the patched FreeBSD
8.0-CURRENT-200902/amd64 as expected.  Thanks!

Could it be considered important enough to make it into
8.0-RELEASE at this final stage?  Hope it will, but if not,
please consider to point it out in the release note.

Hiroharu Tamaru


> -----Original Message-----
> From: owner-freebsd-net@freebsd.org on behalf of Hiroharu Tamaru
> Sent: Mon 9/14/2009 6:34 PM
> To: freebsd-net@freebsd.org
> Subject: Re: 8.0-BETA4 not responding to ARP for published entries
>  
> 
> At Mon, 14 Sep 2009 10:43:09 -0700, Chris Cowart wrote:
> > We have a system which makes heavy use of published arp entries. I know
> > the arp code has been significantly overhauled in 8, but it looks like
> > this functionality is now broken.
> > 
> > $ arp -s 172.16.132.100 00:0c:29:16:bd:49 pub
> > 
> > If I watch tcpdump on the interface, I see arp requests come in but no
> > replies are sent. This is a clean build with no firewalls enabled.
> 
> Just for another datapoint, I see the same symptom.
> I am currently running ports/net-mgmt/choparp as a workaround.
> 
> At Thu, 23 Apr 2009 21:13:51 +0900, Hiroharu Tamaru wrote:
> > Subject: proxy arp on 8.0-current?
> > Date: Thu, 23 Apr 2009 21:13:51 +0900
> > To: freebsd-net@freebsd.org
> >
> > Hi,
> > 
> > I'm trying to setup an proxy arp on a dual homed host.
> > 
> > I noticed that I cannot set it up on 8.0-current the same way as I
> > could on 6.2; hence the question: have the setup procedure changed
> > recently (when the arp table was separated from the routing table,
> > maybe?)?  My 8.0-current is from 200902 snapshot.
> > 
> > Here is a simple demonstration using two single-interfaced hosts:
> > 
> > setup:
> > host6.2# ifconfig em0 inet 192.168.0.1/24
> > host6.2# arp -s 192.168.0.11 auto pub
> > host6.2# arp -an | grep permanent
> > ? (192.168.0.1) at 00:16:d3:xx:xx:xx on em0 permanent [ethernet]
> > ? (192.168.0.11) at 00:16:d3:xx:xx:xx on em0 permanent published [ethernet]
> > host6.2# tcpdump -np arp
> > 
> > host8.0# ifconfig em0 inet 192.168.0.2/24
> > host8.0# arp -s 192.168.0.12 auto pub
> > host8.0# arp -an | grep permanent
> > ? (192.168.0.2) at 00:0c:29:xx:xx:xx on em0 permanent [ethernet]
> > ? (192.168.0.12) at 00:0c:29:xx:xx:xx on em0 permanent published [ethernet]
> > host8.0# tcpdump -np arp
> > 
> > then, I do:
> > host6.2# arp -d 192.168.0.2;  ping -c 1 192.168.0.2
> > host6.2# arp -d 192.168.0.12; ping -c 1 192.168.0.12
> > host8.0# arp -d 192.168.0.1;  ping -c 1 192.168.0.1
> > host8.0# arp -d 192.168.0.11; ping -c 1 192.168.0.11
> > 
> > I am not caring about 'arp -d' errors (cannot locate) nor ping not
> > responding (for proxied addresses).  I just cared about arp requests and
> > replys for now.  The output of tcpdump on both sides are like this:
> > 
> >  arp who-has 192.168.0.2 tell 192.168.0.1
> >  arp reply 192.168.0.2 is-at 00:0c:29:xx:xx:xx
> > 
> >  arp who-has 192.168.0.12 tell 192.168.0.1
> > ---->no reply
> > 
> >  arp who-has 192.168.0.1 tell 192.168.0.2
> >  arp reply 192.168.0.1 is-at 00:16:d3:xx:xx:xx
> > 
> >  arp who-has 192.168.0.11 tell 192.168.0.2
> >  arp reply 192.168.0.11 is-at 00:16:d3:xx:xx:xx
> > 
> > As you can see from the above,
> > 'arp -s 192.168.0.12 auto pub' on 8.0-current host
> > seems not to be producing proxy arp's.
> > 
> > What am I missing?
> > 
> > Thanks.
> > -- 
> > Hiroharu Tamaru
From m.matthieu at gmail.com  Tue Sep 15 15:30:08 2009
From: m.matthieu at gmail.com (matthieu)
Date: Tue Sep 15 15:30:15 2009
Subject: kern/127587: [bge] [request] if_bge(4) doesn't support BCM576X 
	family
Message-ID: <200909151530.n8FFU8Yd024287@freefall.freebsd.org>

The following reply was made to PR kern/127587; it has been noted by GNATS.

From: matthieu <m.matthieu@gmail.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/127587: [bge] [request] if_bge(4) doesn't support BCM576X 
	family
Date: Tue, 15 Sep 2009 17:25:35 +0200

 --0016e6d7e06cd8875604739f640b
 Content-Type: text/plain; charset=ISO-8859-1
 
 --- if_bge.c.back       2009-07-08 20:36:45.000000000 +0200
 +++ if_bge.c    2009-09-12 00:12:53.000000000 +0200
 @@ -272,6 +272,7 @@
         { BGE_CHIPID_BCM5755_A1,        "BCM5755 A1" },
         { BGE_CHIPID_BCM5755_A2,        "BCM5755 A2" },
         { BGE_CHIPID_BCM5722_A0,        "BCM5722 A0" },
 +       { BGE_CHIPID_BCM5761,           "BCM5761" },
         /* 5754 and 5787 share the same ASIC ID */
         { BGE_CHIPID_BCM5787_A0,        "BCM5754/5787 A0" },
         { BGE_CHIPID_BCM5787_A1,        "BCM5754/5787 A1" },
 @@ -2417,6 +2418,12 @@
         sc->bge_asicrev = BGE_ASICREV(sc->bge_chipid);
         sc->bge_chiprev = BGE_CHIPREV(sc->bge_chipid);
 
 +       if (sc->bge_asicrev == BGE_ASICREV_PROD_ID_REG)
 +         {
 +           sc->bge_chipid = pci_read_config(dev, BGE_PCI_PRODID_ASICREV, 4);
 +         }
 +
 +
         /*
          * Don't enable Ethernet@WireSpeed for the 5700, 5906, or the
          * 5705 A0 and A1 chips.
 @@ -2424,8 +2431,9 @@
         if (sc->bge_asicrev != BGE_ASICREV_BCM5700 &&
             sc->bge_asicrev != BGE_ASICREV_BCM5906 &&
             sc->bge_chipid != BGE_CHIPID_BCM5705_A0 &&
 -           sc->bge_chipid != BGE_CHIPID_BCM5705_A1)
 -               sc->bge_flags |= BGE_FLAG_WIRESPEED;
 +           sc->bge_chipid != BGE_CHIPID_BCM5705_A1 &&
 +           sc->bge_chipid != BGE_CHIPID_BCM5761)
 +         sc->bge_flags |= BGE_FLAG_WIRESPEED;
 
         if (bge_has_eaddr(sc))
                 sc->bge_flags |= BGE_FLAG_EADDR;
 @@ -2474,6 +2482,10 @@
                         sc->bge_flags |= BGE_FLAG_BER_BUG;
         }
 
 +       if (sc->bge_chipid == BGE_CHIPID_BCM5761)
 +         {
 +           sc->bge_flags |= BGE_FLAG_5705_PLUS;
 +         }
 
         /*
          * We could possibly check for BCOM_DEVICEID_BCM5788 in bge_probe()
 --- if_bgereg.h.old     2009-03-23 15:36:50.000000000 +0100
 +++ if_bgereg.h 2009-09-14 12:23:38.000000000 +0200
 @@ -218,6 +218,7 @@
  #define        BGE_PCI_UNDI_TX_BD_PRODIDX_LO   0xAC
  #define        BGE_PCI_ISR_MBX_HI              0xB0
  #define        BGE_PCI_ISR_MBX_LO              0xB4
 +#define        BGE_PCI_PRODID_ASICREV          0xBC
 
  /* PCI Misc. Host control register */
  #define        BGE_PCIMISCCTL_CLEAR_INTA       0x00000001
 @@ -302,6 +303,7 @@
  #define        BGE_CHIPID_BCM5787_A2           0xb0020000
  #define        BGE_CHIPID_BCM5906_A1           0xc0010000
  #define        BGE_CHIPID_BCM5906_A2           0xc0020000
 +#define        BGE_CHIPID_BCM5761              0x05761100
 
  /* shorthand one */
  #define        BGE_ASICREV(x)                  ((x) >> 28)
 @@ -319,6 +321,9 @@
  #define        BGE_ASICREV_BCM5754             0x0b
  #define        BGE_ASICREV_BCM5787             0x0b
  #define        BGE_ASICREV_BCM5906             0x0c
 +#define        BGE_ASICREV_PROD_ID_REG         0x0f
 +
 +#define        BGE_ASICREV_BCM5761             0x5761
 
  /* chip revisions */
  #define        BGE_CHIPREV(x)                  ((x) >> 24)
 @@ -2098,6 +2103,7 @@
 
 --0016e6d7e06cd8875604739f640b
 Content-Type: text/plain; charset=US-ASCII; name="patch_5761.patch.txt"
 Content-Disposition: attachment; filename="patch_5761.patch.txt"
 Content-Transfer-Encoding: base64
 X-Attachment-Id: file0
 
 LS0tIGlmX2JnZS5jLmJhY2sJMjAwOS0wNy0wOCAyMDozNjo0NS4wMDAwMDAwMDAgKzAyMDAKKysr
 IGlmX2JnZS5jCTIwMDktMDktMTIgMDA6MTI6NTMuMDAwMDAwMDAwICswMjAwCkBAIC0yNzIsNiAr
 MjcyLDcgQEAKIAl7IEJHRV9DSElQSURfQkNNNTc1NV9BMSwJIkJDTTU3NTUgQTEiIH0sCiAJeyBC
 R0VfQ0hJUElEX0JDTTU3NTVfQTIsCSJCQ001NzU1IEEyIiB9LAogCXsgQkdFX0NISVBJRF9CQ001
 NzIyX0EwLAkiQkNNNTcyMiBBMCIgfSwKKwl7IEJHRV9DSElQSURfQkNNNTc2MSwJCSJCQ001NzYx
 IiB9LCAKIAkvKiA1NzU0IGFuZCA1Nzg3IHNoYXJlIHRoZSBzYW1lIEFTSUMgSUQgKi8KIAl7IEJH
 RV9DSElQSURfQkNNNTc4N19BMCwJIkJDTTU3NTQvNTc4NyBBMCIgfSwgCiAJeyBCR0VfQ0hJUElE
 X0JDTTU3ODdfQTEsCSJCQ001NzU0LzU3ODcgQTEiIH0sCkBAIC0yNDE3LDYgKzI0MTgsMTIgQEAK
 IAlzYy0+YmdlX2FzaWNyZXYgPSBCR0VfQVNJQ1JFVihzYy0+YmdlX2NoaXBpZCk7CiAJc2MtPmJn
 ZV9jaGlwcmV2ID0gQkdFX0NISVBSRVYoc2MtPmJnZV9jaGlwaWQpOwogCisJaWYgKHNjLT5iZ2Vf
 YXNpY3JldiA9PSBCR0VfQVNJQ1JFVl9QUk9EX0lEX1JFRykKKwkgIHsKKwkgICAgc2MtPmJnZV9j
 aGlwaWQgPSBwY2lfcmVhZF9jb25maWcoZGV2LCBCR0VfUENJX1BST0RJRF9BU0lDUkVWLCA0KTsK
 KwkgIH0KKworCiAJLyoKIAkgKiBEb24ndCBlbmFibGUgRXRoZXJuZXRAV2lyZVNwZWVkIGZvciB0
 aGUgNTcwMCwgNTkwNiwgb3IgdGhlCiAJICogNTcwNSBBMCBhbmQgQTEgY2hpcHMuCkBAIC0yNDI0
 LDggKzI0MzEsOSBAQAogCWlmIChzYy0+YmdlX2FzaWNyZXYgIT0gQkdFX0FTSUNSRVZfQkNNNTcw
 MCAmJgogCSAgICBzYy0+YmdlX2FzaWNyZXYgIT0gQkdFX0FTSUNSRVZfQkNNNTkwNiAmJgogCSAg
 ICBzYy0+YmdlX2NoaXBpZCAhPSBCR0VfQ0hJUElEX0JDTTU3MDVfQTAgJiYKLQkgICAgc2MtPmJn
 ZV9jaGlwaWQgIT0gQkdFX0NISVBJRF9CQ001NzA1X0ExKQotCQlzYy0+YmdlX2ZsYWdzIHw9IEJH
 RV9GTEFHX1dJUkVTUEVFRDsKKwkgICAgc2MtPmJnZV9jaGlwaWQgIT0gQkdFX0NISVBJRF9CQ001
 NzA1X0ExICYmCisJICAgIHNjLT5iZ2VfY2hpcGlkICE9IEJHRV9DSElQSURfQkNNNTc2MSkKKwkg
 IHNjLT5iZ2VfZmxhZ3MgfD0gQkdFX0ZMQUdfV0lSRVNQRUVEOwogCiAJaWYgKGJnZV9oYXNfZWFk
 ZHIoc2MpKQogCQlzYy0+YmdlX2ZsYWdzIHw9IEJHRV9GTEFHX0VBRERSOwpAQCAtMjQ3NCw2ICsy
 NDgyLDEwIEBACiAJCQlzYy0+YmdlX2ZsYWdzIHw9IEJHRV9GTEFHX0JFUl9CVUc7CiAJfQogCisJ
 aWYgKHNjLT5iZ2VfY2hpcGlkID09IEJHRV9DSElQSURfQkNNNTc2MSkKKwkgIHsKKwkgICAgc2Mt
 PmJnZV9mbGFncyB8PSBCR0VfRkxBR181NzA1X1BMVVM7CisJICB9CiAKIAkvKgogCSAqIFdlIGNv
 dWxkIHBvc3NpYmx5IGNoZWNrIGZvciBCQ09NX0RFVklDRUlEX0JDTTU3ODggaW4gYmdlX3Byb2Jl
 KCkKLS0tIGlmX2JnZXJlZy5oLm9sZAkyMDA5LTAzLTIzIDE1OjM2OjUwLjAwMDAwMDAwMCArMDEw
 MAorKysgaWZfYmdlcmVnLmgJMjAwOS0wOS0xNCAxMjoyMzozOC4wMDAwMDAwMDAgKzAyMDAKQEAg
 LTIxOCw2ICsyMTgsNyBAQAogI2RlZmluZQlCR0VfUENJX1VORElfVFhfQkRfUFJPRElEWF9MTwkw
 eEFDCiAjZGVmaW5lCUJHRV9QQ0lfSVNSX01CWF9ISQkJMHhCMAogI2RlZmluZQlCR0VfUENJX0lT
 Ul9NQlhfTE8JCTB4QjQKKyNkZWZpbmUJQkdFX1BDSV9QUk9ESURfQVNJQ1JFVgkJMHhCQwogCiAv
 KiBQQ0kgTWlzYy4gSG9zdCBjb250cm9sIHJlZ2lzdGVyICovCiAjZGVmaW5lCUJHRV9QQ0lNSVND
 Q1RMX0NMRUFSX0lOVEEJMHgwMDAwMDAwMQpAQCAtMzAyLDYgKzMwMyw3IEBACiAjZGVmaW5lCUJH
 RV9DSElQSURfQkNNNTc4N19BMgkJMHhiMDAyMDAwMAogI2RlZmluZQlCR0VfQ0hJUElEX0JDTTU5
 MDZfQTEJCTB4YzAwMTAwMDAKICNkZWZpbmUJQkdFX0NISVBJRF9CQ001OTA2X0EyCQkweGMwMDIw
 MDAwCisjZGVmaW5lCUJHRV9DSElQSURfQkNNNTc2MQkJMHgwNTc2MTEwMAogCiAvKiBzaG9ydGhh
 bmQgb25lICovCiAjZGVmaW5lCUJHRV9BU0lDUkVWKHgpCQkJKCh4KSA+PiAyOCkKQEAgLTMxOSw2
 ICszMjEsOSBAQAogI2RlZmluZQlCR0VfQVNJQ1JFVl9CQ001NzU0CQkweDBiCiAjZGVmaW5lCUJH
 RV9BU0lDUkVWX0JDTTU3ODcJCTB4MGIKICNkZWZpbmUJQkdFX0FTSUNSRVZfQkNNNTkwNgkJMHgw
 YworI2RlZmluZQlCR0VfQVNJQ1JFVl9QUk9EX0lEX1JFRwkJMHgwZgorCisjZGVmaW5lCUJHRV9B
 U0lDUkVWX0JDTTU3NjEJCTB4NTc2MQogCiAvKiBjaGlwIHJldmlzaW9ucyAqLwogI2RlZmluZQlC
 R0VfQ0hJUFJFVih4KQkJCSgoeCkgPj4gMjQpCkBAIC0yMDk4LDYgKzIxMDMsNyBAQAogI2RlZmlu
 ZQlCQ09NX0RFVklDRUlEX0JDTTU3MTRTCQkweDE2NjkKICNkZWZpbmUJQkNPTV9ERVZJQ0VJRF9C
 Q001NzE1CQkweDE2NzgKICNkZWZpbmUJQkNPTV9ERVZJQ0VJRF9CQ001NzE1UwkJMHgxNjc5Cisj
 ZGVmaW5lCUJDT01fREVWSUNFSURfQkNNNTc2MUUJCTB4MTY4MAogI2RlZmluZQlCQ09NX0RFVklD
 RUlEX0JDTTU3MjAJCTB4MTY1OAogI2RlZmluZQlCQ09NX0RFVklDRUlEX0JDTTU3MjEJCTB4MTY1
 OQogI2RlZmluZQlCQ09NX0RFVklDRUlEX0JDTTU3MjIJCTB4MTY1QQo=
 --0016e6d7e06cd8875604739f640b--
From ccowart at rescomp.berkeley.edu  Tue Sep 15 18:18:45 2009
From: ccowart at rescomp.berkeley.edu (Chris Cowart)
Date: Tue Sep 15 18:18:52 2009
Subject: 8.0-BETA4 not responding to ARP for published entries
In-Reply-To: <sa6zl8w71bf.wl%tamaru@myn.rcast.u-tokyo.ac.jp>
References: <20090914174309.GF37291@hal.rescomp.berkeley.edu>
	<sa61vm97zyk.wl%tamaru@myn.rcast.u-tokyo.ac.jp>
	<B583FBF374231F4A89607B4D08578A43046736AD@bcs-mail03.internal.cacheflow.com>
	<sa6zl8w71bf.wl%tamaru@myn.rcast.u-tokyo.ac.jp>
Message-ID: <20090915181844.GI37291@hal.rescomp.berkeley.edu>

Hiroharu Tamaru wrote:
> At Mon, 14 Sep 2009 21:50:47 -0700, Li, Qing wrote:
>> Please try patch at 
>> 
>>    http://people.freebsd.org/~qingli/proxy-arp-patch.diff
> 
> Thanks for taking care of it.
> 
> I tried it, and now proxy arp works on the patched FreeBSD
> 8.0-CURRENT-200902/amd64 as expected.  Thanks!
> 
> Could it be considered important enough to make it into
> 8.0-RELEASE at this final stage?  Hope it will, but if not,
> please consider to point it out in the release note.

The patch works for me too. I would like to second the hope that this
makes it into the 8.0-RELEASE. Otherwise, the regression would seriously
complicate our upgrade path.

Thanks,

-- 
Chris Cowart
Network Technical Lead
Network & Infrastructure Services, RSSP-IT
UC Berkeley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20090915/12708177/attachment.pgp
From qing.li at bluecoat.com  Wed Sep 16 00:06:16 2009
From: qing.li at bluecoat.com (Li, Qing)
Date: Wed Sep 16 00:06:22 2009
Subject: 8.0-BETA4 not responding to ARP for published entries
In-Reply-To: <20090915181844.GI37291@hal.rescomp.berkeley.edu>
References: <20090914174309.GF37291@hal.rescomp.berkeley.edu>
	<sa61vm97zyk.wl%tamaru@myn.rcast.u-tokyo.ac.jp>
	<B583FBF374231F4A89607B4D08578A43046736AD@bcs-mail03.internal.cacheflow.com>
	<sa6zl8w71bf.wl%tamaru@myn.rcast.u-tokyo.ac.jp>
	<20090915181844.GI37291@hal.rescomp.berkeley.edu>
Message-ID: <B583FBF374231F4A89607B4D08578A4305547E70@bcs-mail03.internal.cacheflow.com>

Hi,

I have committed the code into -CURRENT and it's now merged into 8
Release
branch. So RC1 should contain the fix.

-- Qing


> -----Original Message-----
> From: Chris Cowart [mailto:ccowart@rescomp.berkeley.edu]
> Sent: Tuesday, September 15, 2009 11:19 AM
> To: Hiroharu Tamaru
> Cc: Li, Qing; freebsd-net@freebsd.org; erikk@berkeley.edu; freebsd-
> current@freebsd.org
> Subject: Re: 8.0-BETA4 not responding to ARP for published entries
> 
> Hiroharu Tamaru wrote:
> > At Mon, 14 Sep 2009 21:50:47 -0700, Li, Qing wrote:
> >> Please try patch at
> >>
> >>    http://people.freebsd.org/~qingli/proxy-arp-patch.diff
> >
> > Thanks for taking care of it.
> >
> > I tried it, and now proxy arp works on the patched FreeBSD
> > 8.0-CURRENT-200902/amd64 as expected.  Thanks!
> >
> > Could it be considered important enough to make it into
> > 8.0-RELEASE at this final stage?  Hope it will, but if not,
> > please consider to point it out in the release note.
> 
> The patch works for me too. I would like to second the hope that this
> makes it into the 8.0-RELEASE. Otherwise, the regression would
> seriously
> complicate our upgrade path.
> 
> Thanks,
> 
> --
> Chris Cowart
> Network Technical Lead
> Network & Infrastructure Services, RSSP-IT
> UC Berkeley
From linimon at FreeBSD.org  Wed Sep 16 01:08:12 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Wed Sep 16 01:08:23 2009
Subject: kern/138850: [dummynet] dummynet doesn't work correctly on a
	bridge
Message-ID: <200909160108.n8G18Bo6011718@freefall.freebsd.org>

Old Synopsis: dummynet doesn't work correctly on a bridge
New Synopsis: [dummynet] dummynet doesn't work correctly on a bridge

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Wed Sep 16 01:07:55 UTC 2009
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=138850
From psteele at maxiscale.com  Wed Sep 16 01:23:34 2009
From: psteele at maxiscale.com (Peter Steele)
Date: Wed Sep 16 01:23:40 2009
Subject: Can lagg0 failback be prevented?
Message-ID: <7B9397B189EB6E46A5EE7B4C8A4BB7CB3042DBE7@MBX03.exg5.exghost.com>

We're using the lag driver to provide automatic failover in case of a network outage. The default configuration looks like this:

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
        ether 00:a0:d1:e3:58:26
        inet 192.168.17.40 netmask 0xfffff000 broadcast 192.168.31.255
        inet 192.168.22.11 netmask 0xffffff00 broadcast 192.168.22.255
        media: Ethernet autoselect
        status: active
        laggproto failover
        laggport: nfe1 flags=0<>
        laggport: nfe0 flags=5<MASTER,ACTIVE>

If nfe0 was to fail, we get an (almost) automatic failover to nfe1:

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
        ether 00:a0:d1:e3:58:26
        inet 192.168.17.40 netmask 0xfffff000 broadcast 192.168.31.255
        inet 192.168.22.11 netmask 0xffffff00 broadcast 192.168.22.255
        media: Ethernet autoselect
        status: active
        laggproto failover
        laggport: nfe1 flags=4<ACTIVE>
        laggport: nfe0 flags=1<MASTER>

The problem we're having is when nfe0 comes online again, a failback occurs making nfe0 active again. This causes a momentary network outage that we want to prevent. Is there a way to configure the lagg device to stay with the currently active interface, even if the MASTER interface comes back online?

From tamaru at myn.rcast.u-tokyo.ac.jp  Wed Sep 16 01:49:04 2009
From: tamaru at myn.rcast.u-tokyo.ac.jp (Hiroharu Tamaru)
Date: Wed Sep 16 01:49:18 2009
Subject: 8.0-BETA4 not responding to ARP for published entries
In-Reply-To: <B583FBF374231F4A89607B4D08578A4305547E70@bcs-mail03.internal.cacheflow.com>
References: <20090914174309.GF37291@hal.rescomp.berkeley.edu>
	<sa61vm97zyk.wl%tamaru@myn.rcast.u-tokyo.ac.jp>
	<B583FBF374231F4A89607B4D08578A43046736AD@bcs-mail03.internal.cacheflow.com>
	<sa6zl8w71bf.wl%tamaru@myn.rcast.u-tokyo.ac.jp>
	<20090915181844.GI37291@hal.rescomp.berkeley.edu>
	<B583FBF374231F4A89607B4D08578A4305547E70@bcs-mail03.internal.cacheflow.com>
Message-ID: <sa6y6of7j76.wl%tamaru@myn.rcast.u-tokyo.ac.jp>

Hi,

At Tue, 15 Sep 2009 17:05:46 -0700, Li, Qing wrote:
> Hi,
> 
> I have committed the code into -CURRENT and it's now merged into 8
> Release
> branch. So RC1 should contain the fix.
> 
> -- Qing

Excellent!  I'll try RC1 when it comes out.  Thanks.

Hiroharu Tamaru

> > -----Original Message-----
> > From: Chris Cowart [mailto:ccowart@rescomp.berkeley.edu]
> > Sent: Tuesday, September 15, 2009 11:19 AM
> > To: Hiroharu Tamaru
> > Cc: Li, Qing; freebsd-net@freebsd.org; erikk@berkeley.edu; freebsd-
> > current@freebsd.org
> > Subject: Re: 8.0-BETA4 not responding to ARP for published entries
> > 
> > Hiroharu Tamaru wrote:
> > > At Mon, 14 Sep 2009 21:50:47 -0700, Li, Qing wrote:
> > >> Please try patch at
> > >>
> > >>    http://people.freebsd.org/~qingli/proxy-arp-patch.diff
> > >
> > > Thanks for taking care of it.
> > >
> > > I tried it, and now proxy arp works on the patched FreeBSD
> > > 8.0-CURRENT-200902/amd64 as expected.  Thanks!
> > >
> > > Could it be considered important enough to make it into
> > > 8.0-RELEASE at this final stage?  Hope it will, but if not,
> > > please consider to point it out in the release note.
> > 
> > The patch works for me too. I would like to second the hope that this
> > makes it into the 8.0-RELEASE. Otherwise, the regression would
> > seriously
> > complicate our upgrade path.
> > 
> > Thanks,
> > 
> > --
> > Chris Cowart
> > Network Technical Lead
> > Network & Infrastructure Services, RSSP-IT
> > UC Berkeley
From erikk at berkeley.edu  Wed Sep 16 01:59:13 2009
From: erikk at berkeley.edu (Erik Klavon)
Date: Wed Sep 16 01:59:19 2009
Subject: 8.0-BETA4 not responding to ARP for published entries
In-Reply-To: <B583FBF374231F4A89607B4D08578A4305547E70@bcs-mail03.internal.cacheflow.com>
References: <20090914174309.GF37291@hal.rescomp.berkeley.edu>
	<sa61vm97zyk.wl%tamaru@myn.rcast.u-tokyo.ac.jp>
	<B583FBF374231F4A89607B4D08578A43046736AD@bcs-mail03.internal.cacheflow.com>
	<sa6zl8w71bf.wl%tamaru@myn.rcast.u-tokyo.ac.jp>
	<20090915181844.GI37291@hal.rescomp.berkeley.edu>
	<B583FBF374231F4A89607B4D08578A4305547E70@bcs-mail03.internal.cacheflow.com>
Message-ID: <20090916015910.GA11794@malcolm.berkeley.edu>

Hi Qing,

On Tue, Sep 15, 2009 at 05:05:46PM -0700, Li, Qing wrote:
> I have committed the code into -CURRENT and it's now merged into 8
> Release branch. So RC1 should contain the fix.

The patch worked for me as well. Thanks for fixing this so quickly and
for getting it in for RC1. I'll test again when RC1 comes out.

Erik
From dokas at oitsec.umn.edu  Wed Sep 16 02:29:52 2009
From: dokas at oitsec.umn.edu (Paul Dokas)
Date: Wed Sep 16 02:30:04 2009
Subject: kern/138739: [wpi] wpi(4) does not work very well
	under	8.0-BETA4
In-Reply-To: <200909120053.n8C0rcbZ005357@freefall.freebsd.org>
References: <200909120053.n8C0rcbZ005357@freefall.freebsd.org>
Message-ID: <4AB04A25.501@oitsec.umn.edu>

linimon@FreeBSD.org wrote:
> Old Synopsis: wpi(4) does not work very well under 8.0-BETA4
> New Synopsis: [wpi] wpi(4) does not work very well under 8.0-BETA4
> 
> Responsible-Changed-From-To: freebsd-bugs->freebsd-net
> Responsible-Changed-By: linimon
> Responsible-Changed-When: Sat Sep 12 00:53:04 UTC 2009
> Responsible-Changed-Why: 
> Over to maintainer(s).
> 
> http://www.freebsd.org/cgi/query-pr.cgi?pr=138739


I was just looking for possible sol'ns to a very similar problem that I
have with my FreeBSD 7.2 laptop, a Dell D820 with a 3945abg card:

wpi0: <Intel(R) PRO/Wireless 3945ABG> mem 0xecfff000-0xecffffff irq 17 at device 0.0 on pci12

I've had what looks like exactly this same problem for ages.  Back into
the FreeBSD 6.X days when the wpi driver was first added.  Also, I think that
PR 127102 is probably related.

I've noticed problems when I'm in an area with lots of SSIDs and APs.
I get this particularly bad when at work where there are 5 SSIDs present
on each AP and at least 4+ APs always within range.  At home where I see
only 3 SSIDs on 3 APs, I can associate with my Linksys "router" just fine,
but I see the slow throughput problem.  This might be because I'm only
associated at 1Mbps:

wpi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	inet 172.16.23.65 netmask 0xffffff80 broadcast 172.16.23.127
	media: IEEE 802.11 Wireless Ethernet autoselect (DS/1Mbps)
	status: associated
	ssid SSID channel 6 (2437 Mhz 11g) bssid 00:21:19:ae:00:00
	authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit
	txpower 50 bmiss 7 scanvalid 60 protmode CTS roaming MANUAL


Anyway, at work today, I did a bunch of testing.  I attempted to associate
first with a WPA2-enterprise SSID and then with an open SSID.  In both
cases, my laptop went into a spiral of doom:  associate, spew errors,
disassociate, repeat:

Sep 15 15:21:13 yog kernel: wpi0: link state changed to UP
Sep 15 15:21:13 yog kernel: wpi0: fatal firmware error
Sep 15 15:21:13 yog kernel: wpi0: timeout resetting Rx ring
Sep 15 15:21:13 yog kernel: wpi0: link state changed to DOWN
Sep 15 15:21:17 yog kernel: wpi0: link state changed to UP
Sep 15 15:21:17 yog kernel: wpi0: fatal firmware error
Sep 15 15:21:17 yog kernel: wpi0: timeout resetting Rx ring
Sep 15 15:21:17 yog kernel: wpi0: link state changed to DOWN
...


A network engineer pulled the logs from the network gear (Trapeze ABGN
APs) and saw that my laptop was repeatedly roaming between all of the
available APs.  I strongly suspect that there's a bug lurking in wpi
firmware related to roaming.

A possible pointer for this problem might be here:

   http://www.openbsd.org/plus41.html

   "Fix firmware fatal errors on re-associations in wpi(4)."


I'm willing to provide more data and test any possible fixes for 7.2,
but I'm lacking the time and experience necessary to track this one down
myself.


Paul
-- 
Paul Dokas                                     dokas at oitsec.umn.edu
======================================================================
Don Juan Matus:  "an enigma wrapped in mystery wrapped in a tortilla."
From linimon at lonesome.com  Wed Sep 16 02:40:06 2009
From: linimon at lonesome.com (Mark Linimon)
Date: Wed Sep 16 02:40:14 2009
Subject: kern/138739: [wpi] wpi(4) does not work very well
	under?8.0-BETA4
Message-ID: <200909160240.n8G2e69X002944@freefall.freebsd.org>

The following reply was made to PR kern/138739; it has been noted by GNATS.

From: Mark Linimon <linimon@lonesome.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/138739: [wpi] wpi(4) does not work very well
	under?8.0-BETA4
Date: Tue, 15 Sep 2009 21:38:23 -0500

 ----- Forwarded message from Paul Dokas <dokas@oitsec.umn.edu> -----
 
 From: Paul Dokas <dokas@oitsec.umn.edu>
 Reply-To: Paul Dokas <dokas@oitsec.umn.edu>
 Organization: OIT Security & Assurance, University of Minnesota
 To: linimon@FreeBSD.org
 CC: freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org
 Subject: Re: kern/138739: [wpi] wpi(4) does not work very well under 8.0-BETA4
 
 I was just looking for possible sol'ns to a very similar problem that I
 have with my FreeBSD 7.2 laptop, a Dell D820 with a 3945abg card:
 
 wpi0: <Intel(R) PRO/Wireless 3945ABG> mem 0xecfff000-0xecffffff irq 17 at device 0.0 on pci12
 
 I've had what looks like exactly this same problem for ages.  Back into
 the FreeBSD 6.X days when the wpi driver was first added.  Also, I think that
 PR 127102 is probably related.
 
 I've noticed problems when I'm in an area with lots of SSIDs and APs.
 I get this particularly bad when at work where there are 5 SSIDs present
 on each AP and at least 4+ APs always within range.  At home where I see
 only 3 SSIDs on 3 APs, I can associate with my Linksys "router" just fine,
 but I see the slow throughput problem.  This might be because I'm only
 associated at 1Mbps:
 
 wpi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
 	inet 172.16.23.65 netmask 0xffffff80 broadcast 172.16.23.127
 	media: IEEE 802.11 Wireless Ethernet autoselect (DS/1Mbps)
 	status: associated
 	ssid SSID channel 6 (2437 Mhz 11g) bssid 00:21:19:ae:00:00
 	authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit
 	txpower 50 bmiss 7 scanvalid 60 protmode CTS roaming MANUAL
 
 
 Anyway, at work today, I did a bunch of testing.  I attempted to associate
 first with a WPA2-enterprise SSID and then with an open SSID.  In both
 cases, my laptop went into a spiral of doom:  associate, spew errors,
 disassociate, repeat:
 
 Sep 15 15:21:13 yog kernel: wpi0: link state changed to UP
 Sep 15 15:21:13 yog kernel: wpi0: fatal firmware error
 Sep 15 15:21:13 yog kernel: wpi0: timeout resetting Rx ring
 Sep 15 15:21:13 yog kernel: wpi0: link state changed to DOWN
 Sep 15 15:21:17 yog kernel: wpi0: link state changed to UP
 Sep 15 15:21:17 yog kernel: wpi0: fatal firmware error
 Sep 15 15:21:17 yog kernel: wpi0: timeout resetting Rx ring
 Sep 15 15:21:17 yog kernel: wpi0: link state changed to DOWN
 ...
 
 
 A network engineer pulled the logs from the network gear (Trapeze ABGN
 APs) and saw that my laptop was repeatedly roaming between all of the
 available APs.  I strongly suspect that there's a bug lurking in wpi
 firmware related to roaming.
 
 A possible pointer for this problem might be here:
 
   http://www.openbsd.org/plus41.html
 
   "Fix firmware fatal errors on re-associations in wpi(4)."
 
 
 I'm willing to provide more data and test any possible fixes for 7.2,
 but I'm lacking the time and experience necessary to track this one down
 myself.
 
 
 Paul
 -- 
 Paul Dokas                                     dokas at oitsec.umn.edu
 ======================================================================
 Don Juan Matus:  "an enigma wrapped in mystery wrapped in a tortilla."
 
 ----- End forwarded message -----
From ferdinand.goldmann at jku.at  Wed Sep 16 13:28:41 2009
From: ferdinand.goldmann at jku.at (Ferdinand Goldmann)
Date: Wed Sep 16 13:28:49 2009
Subject: Problem with Dell R410 & bce driver :-(
Message-ID: <4AB0E3D4.8050306@jku.at>

Hi

Tried installing FreeBSD 7.2 on two shiny new Dell R410 servers ...
The system booted up fine from the install CD and I did a network install
from an FTP server.

Upon rebooting, however, the network interface stopped working, and I am
getting loads of error messages on the console, like:

Watchdog timeout occured, resetting
Unable to write CTX memory
PHY write timeout

The chip is a BCM5716 which according to the man page should work. An upgrade
to 7.2-p3 did not help.
I also tried disabling hw.bce.msi_enable and hw.bce.tso_enable. This did not
help either.

What puzzles me is that the FTP install went just fine.

Anyone here who has experience with a Dell R410 under FreeBSD?

TIA,
ferdinand
-- 
>> Ferdinand Goldmann
>> Johannes Kepler University Linz - Server Systems/Information Management
>> Mail: Ferdinand.Goldmann@jku.at Phone: 00437024689398 Fax: 00437024689397
From spawk at acm.poly.edu  Thu Sep 17 02:36:24 2009
From: spawk at acm.poly.edu (Boris Kochergin)
Date: Thu Sep 17 02:36:31 2009
Subject: kmem_map too small panics with Soekris/Atheros access point
In-Reply-To: <4AA03A41.1080200@acm.poly.edu> 
References: <4A8C3557.20002@acm.poly.edu> <4AA03A41.1080200@acm.poly.edu> 
Message-ID: <4AB1A086.4090303@acm.poly.edu>

Stef Walter wrote:
> Boris Kochergin wrote:
>   
>>> _______________________________________________
>>> 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.
>>     
>
> This might be a long shot:
>
> Back when I deployed some similar devices on FreeBSD 6.0 there was a
> leak when using oddball ath_rate driver. I believe it went away when I
> used ath_rate_sample. But according to 'man 4 ath' nothing else besides
> ath_rate_sample exists anymore.
>
> 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"
>   
I, too, recall the days when you had multiple rate-control algorithms to 
choose from, but that doesn't appear to be the case anymore. As a 
workaround, I wrote a little script that checks if that part of the 
driver is using more than 200 KiB of memory and run it every minute via 
cron. It seems to be doing its job so far:

#!/bin/sh

memory=`vmstat -m | grep "80211node " | tr -s ' ' | cut -f4 -d' ' | sed 
's/[^0-9]//g'`

if [ $memory -gt 200 ]; then
  ifconfig ath0 down && ifconfig ath0 up
fi

-Boris
From sam at freebsd.org  Thu Sep 17 06:31:41 2009
From: sam at freebsd.org (Sam Leffler)
Date: Thu Sep 17 06:32:15 2009
Subject: kmem_map too small panics with Soekris/Atheros access point [ath
 rate control]
In-Reply-To: <4AB1A086.4090303@acm.poly.edu>
References: <4A8C3557.20002@acm.poly.edu> <4AA03A41.1080200@acm.poly.edu>
	<4AB1A086.4090303@acm.poly.edu>
Message-ID: <4AB1D7C2.5010403@freebsd.org>

Boris Kochergin wrote:
> Stef Walter wrote:
>> Boris Kochergin wrote:
>>  
> I, too, recall the days when you had multiple rate-control algorithms to
> choose from, but that doesn't appear to be the case anymore. As a
> workaround, I wrote a little script that checks if that part of the
> driver is using more than 200 KiB of memory and run it every minute via
> cron. It seems to be doing its job so far:

You can still select the ath rate control module.  Static kernel config
is unchanged; for modules you must export ATH_RATE=onoe or similar
(check modules/ath/Makefile).  Please file a PR if this does not work.

	Sam

From shilpa at khushipromotions.com  Thu Sep 17 09:27:09 2009
From: shilpa at khushipromotions.com (Shilpa's World)
Date: Thu Sep 17 09:27:17 2009
Subject: New Portal for the Beauty Tips
Message-ID: <35627663390386@hp-dd73e390af3d.mshome.net>

Hi,

Visit my website http://shilpasworld.com <http://shilpasworld.com/>. The site discuss about various topics, which is related to daily life and of utmost concern. To know whether this site topics interests you or not, please visit the site at least once.

Topics of interest

* Beauty Advise & Fashion Tips 
* Men's Section 
* Women's Health Guide 
* And many more... 


Visit the site http://shilpasworld.com <http://shilpasworld.com/> 

 Regards, 

Shilpa

*************************************************************************
Shilpa's World Disclaimer Policy

This email has been sent to freebsd-net@freebsd.org Dated : 17/09/2009 Time : 3:26:11 AM

This email is not spam, you have received this email because your email id is listed in our database. In case if you have received this email accidently and If you prefer not to receive future emails of this type please Unsubscribe Now <mailto:meramail2004@yahoo.in?subject=Please unsubscribe from future mails> . If this link does not works reply with the subject "Remove" .

Report Spam <mailto:abuse@khushipromotions.com?subject=Spam Reported> or forward a copy of this email to abuse@khushipromotions.com <mailto:abuse@khushipromotions.com> 

The following physical address is associated with this mailing list

Shilpas World
Vaddem Vasco-da-gama Goa (India)
+91-9403880804

****************************************************************************
From dfilter at FreeBSD.ORG  Thu Sep 17 13:50:03 2009
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Thu Sep 17 13:58:38 2009
Subject: kern/137164: commit references a PR
Message-ID: <200909171350.n8HDo2Bu010232@freefall.freebsd.org>

The following reply was made to PR kern/137164; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/137164: commit references a PR
Date: Thu, 17 Sep 2009 13:42:09 +0000 (UTC)

 Author: bms
 Date: Thu Sep 17 13:41:59 2009
 New Revision: 197280
 URL: http://svn.freebsd.org/changeset/base/197280
 
 Log:
   MFC revs 197129,197130,197132:
    Fixes to mcast userland API.
   --
     Fix an API issue in leave processing for IPv4 multicast groups.
      * Do not assume that the group lookup performed by imo_match_group()
        is valid when ifp is NULL in this case.
      * Instead, return EADDRNOTAVAIL if the ifp cannot be resolved for the
        membership we are being asked to leave.
   
     Caveat user:
      * The way IPv4 multicast memberships are implemented in the inpcb layer
        at the moment, has the side-effect that struct ip_moptions will
        still hold the membership, under the old ifp, until ip_freemoptions()
        is called for the parent inpcb.
      * The underlying issue is: the inpcb layer does not get notification
        of ifp being detached going away in a thread-safe manner.
        This is non-trivial to fix.
   --
     Fix an obvious logic error in the IPv4 multicast leave processing,
     where the filter mode vector was not updated correctly after the leave.
   --
     Tighten input checking in inp_join_group():
      * Don't try to use the source address, when its family is unspecified.
      * If we get a join without a source, on an existing inclusive
        mode group, this is an error, as it would change the filter mode.
   
     Fix a problem with the handling of in_mfilter for new memberships:
      * Do not rely on imf being NULL; it is explicitly initialized to a
        non-NULL pointer when constructing a membership.
      * Explicitly initialize *imf to EX mode when the source address
        is unspecified.
     This fixes a problem with in_mfilter slot recycling in the join path.
   --
     Don't allow joins w/o source on an existing group.
     This is almost always pilot error.
   
     We don't need to check for group filter UNDEFINED state at t1,
     because we only ever allocate filters with their groups, so we
     unconditionally reject such calls with EINVAL.
     Trying to change the active filter mode w/o going through IP_MSFILTER
     is also disallowed.
   
     Deals with the case described in PR 137164 upfront, cumulative
     with the fix in svn rev 197132 which only calls imo_match_source()
     if the source address family was not unspecified.
   --
   
   Revision 197136 has a text conflict, however it is a comment only change.
   
   PR:		137164, 138689, 138690, 138691
   Submitted by:	Stef Walter (with fixups)
   Approved by:	re (kib)
 
 Modified:
   stable/8/sys/   (props changed)
   stable/8/sys/amd64/include/xen/   (props changed)
   stable/8/sys/cddl/contrib/opensolaris/   (props changed)
   stable/8/sys/contrib/dev/acpica/   (props changed)
   stable/8/sys/contrib/pf/   (props changed)
   stable/8/sys/dev/ciss/   (props changed)
   stable/8/sys/dev/xen/xenpci/   (props changed)
   stable/8/sys/netinet/in_mcast.c
 
 Modified: stable/8/sys/netinet/in_mcast.c
 ==============================================================================
 --- stable/8/sys/netinet/in_mcast.c	Thu Sep 17 13:33:40 2009	(r197279)
 +++ stable/8/sys/netinet/in_mcast.c	Thu Sep 17 13:41:59 2009	(r197280)
 @@ -1957,11 +1957,6 @@ inp_join_group(struct inpcb *inp, struct
  	if (ifp == NULL || (ifp->if_flags & IFF_MULTICAST) == 0)
  		return (EADDRNOTAVAIL);
  
 -	/*
 -	 * MCAST_JOIN_SOURCE on an exclusive membership is an error.
 -	 * On an existing inclusive membership, it just adds the
 -	 * source to the filter list.
 -	 */
  	imo = inp_findmoptions(inp);
  	idx = imo_match_group(imo, ifp, &gsa->sa);
  	if (idx == -1) {
 @@ -1969,15 +1964,33 @@ inp_join_group(struct inpcb *inp, struct
  	} else {
  		inm = imo->imo_membership[idx];
  		imf = &imo->imo_mfilters[idx];
 -		if (ssa->ss.ss_family != AF_UNSPEC &&
 -		    imf->imf_st[1] != MCAST_INCLUDE) {
 -			error = EINVAL;
 -			goto out_inp_locked;
 -		}
 -		lims = imo_match_source(imo, idx, &ssa->sa);
 -		if (lims != NULL) {
 -			error = EADDRNOTAVAIL;
 -			goto out_inp_locked;
 +		if (ssa->ss.ss_family != AF_UNSPEC) {
 +			/*
 +			 * MCAST_JOIN_SOURCE on an exclusive membership
 +			 * is an error. On an existing inclusive membership,
 +			 * it just adds the source to the filter list.
 +			 */
 +			if (imf->imf_st[1] != MCAST_INCLUDE) {
 +				error = EINVAL;
 +				goto out_inp_locked;
 +			}
 +			/* Throw out duplicates. */
 +			lims = imo_match_source(imo, idx, &ssa->sa);
 +			if (lims != NULL) {
 +				error = EADDRNOTAVAIL;
 +				goto out_inp_locked;
 +			}
 +		} else {
 +			/*
 +			 * MCAST_JOIN_GROUP on an existing inclusive
 +			 * membership is an error; if you want to change
 +			 * filter mode, you must use the userland API
 +			 * setsourcefilter().
 +			 */
 +			if (imf->imf_st[1] == MCAST_INCLUDE) {
 +				error = EINVAL;
 +				goto out_inp_locked;
 +			}
  		}
  	}
  
 @@ -2010,7 +2023,8 @@ inp_join_group(struct inpcb *inp, struct
  	/*
  	 * Graft new source into filter list for this inpcb's
  	 * membership of the group. The in_multi may not have
 -	 * been allocated yet if this is a new membership.
 +	 * been allocated yet if this is a new membership, however,
 +	 * the in_mfilter slot will be allocated and must be initialized.
  	 */
  	if (ssa->ss.ss_family != AF_UNSPEC) {
  		/* Membership starts in IN mode */
 @@ -2027,6 +2041,12 @@ inp_join_group(struct inpcb *inp, struct
  			error = ENOMEM;
  			goto out_imo_free;
  		}
 +	} else {
 +		/* No address specified; Membership starts in EX mode */
 +		if (is_new) {
 +			CTR1(KTR_IGMPV3, "%s: new join w/o source", __func__);
 +			imf_init(imf, MCAST_UNDEFINED, MCAST_EXCLUDE);
 +		}
  	}
  
  	/*
 @@ -2189,6 +2209,9 @@ inp_leave_group(struct inpcb *inp, struc
  	if (!IN_MULTICAST(ntohl(gsa->sin.sin_addr.s_addr)))
  		return (EINVAL);
  
 +	if (ifp == NULL)
 +		return (EADDRNOTAVAIL);
 +
  	/*
  	 * Find the membership in the membership array.
  	 */
 @@ -2275,9 +2298,11 @@ out_imf_rollback:
  	imf_reap(imf);
  
  	if (is_final) {
 -		/* Remove the gap in the membership array. */
 -		for (++idx; idx < imo->imo_num_memberships; ++idx)
 +		/* Remove the gap in the membership and filter array. */
 +		for (++idx; idx < imo->imo_num_memberships; ++idx) {
  			imo->imo_membership[idx-1] = imo->imo_membership[idx];
 +			imo->imo_mfilters[idx-1] = imo->imo_mfilters[idx];
 +		}
  		imo->imo_num_memberships--;
  	}
  
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
From dfilter at FreeBSD.ORG  Thu Sep 17 13:50:05 2009
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Thu Sep 17 13:58:38 2009
Subject: kern/138689: commit references a PR
Message-ID: <200909171350.n8HDo5ph010262@freefall.freebsd.org>

The following reply was made to PR kern/138689; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/138689: commit references a PR
Date: Thu, 17 Sep 2009 13:42:09 +0000 (UTC)

 Author: bms
 Date: Thu Sep 17 13:41:59 2009
 New Revision: 197280
 URL: http://svn.freebsd.org/changeset/base/197280
 
 Log:
   MFC revs 197129,197130,197132:
    Fixes to mcast userland API.
   --
     Fix an API issue in leave processing for IPv4 multicast groups.
      * Do not assume that the group lookup performed by imo_match_group()
        is valid when ifp is NULL in this case.
      * Instead, return EADDRNOTAVAIL if the ifp cannot be resolved for the
        membership we are being asked to leave.
   
     Caveat user:
      * The way IPv4 multicast memberships are implemented in the inpcb layer
        at the moment, has the side-effect that struct ip_moptions will
        still hold the membership, under the old ifp, until ip_freemoptions()
        is called for the parent inpcb.
      * The underlying issue is: the inpcb layer does not get notification
        of ifp being detached going away in a thread-safe manner.
        This is non-trivial to fix.
   --
     Fix an obvious logic error in the IPv4 multicast leave processing,
     where the filter mode vector was not updated correctly after the leave.
   --
     Tighten input checking in inp_join_group():
      * Don't try to use the source address, when its family is unspecified.
      * If we get a join without a source, on an existing inclusive
        mode group, this is an error, as it would change the filter mode.
   
     Fix a problem with the handling of in_mfilter for new memberships:
      * Do not rely on imf being NULL; it is explicitly initialized to a
        non-NULL pointer when constructing a membership.
      * Explicitly initialize *imf to EX mode when the source address
        is unspecified.
     This fixes a problem with in_mfilter slot recycling in the join path.
   --
     Don't allow joins w/o source on an existing group.
     This is almost always pilot error.
   
     We don't need to check for group filter UNDEFINED state at t1,
     because we only ever allocate filters with their groups, so we
     unconditionally reject such calls with EINVAL.
     Trying to change the active filter mode w/o going through IP_MSFILTER
     is also disallowed.
   
     Deals with the case described in PR 137164 upfront, cumulative
     with the fix in svn rev 197132 which only calls imo_match_source()
     if the source address family was not unspecified.
   --
   
   Revision 197136 has a text conflict, however it is a comment only change.
   
   PR:		137164, 138689, 138690, 138691
   Submitted by:	Stef Walter (with fixups)
   Approved by:	re (kib)
 
 Modified:
   stable/8/sys/   (props changed)
   stable/8/sys/amd64/include/xen/   (props changed)
   stable/8/sys/cddl/contrib/opensolaris/   (props changed)
   stable/8/sys/contrib/dev/acpica/   (props changed)
   stable/8/sys/contrib/pf/   (props changed)
   stable/8/sys/dev/ciss/   (props changed)
   stable/8/sys/dev/xen/xenpci/   (props changed)
   stable/8/sys/netinet/in_mcast.c
 
 Modified: stable/8/sys/netinet/in_mcast.c
 ==============================================================================
 --- stable/8/sys/netinet/in_mcast.c	Thu Sep 17 13:33:40 2009	(r197279)
 +++ stable/8/sys/netinet/in_mcast.c	Thu Sep 17 13:41:59 2009	(r197280)
 @@ -1957,11 +1957,6 @@ inp_join_group(struct inpcb *inp, struct
  	if (ifp == NULL || (ifp->if_flags & IFF_MULTICAST) == 0)
  		return (EADDRNOTAVAIL);
  
 -	/*
 -	 * MCAST_JOIN_SOURCE on an exclusive membership is an error.
 -	 * On an existing inclusive membership, it just adds the
 -	 * source to the filter list.
 -	 */
  	imo = inp_findmoptions(inp);
  	idx = imo_match_group(imo, ifp, &gsa->sa);
  	if (idx == -1) {
 @@ -1969,15 +1964,33 @@ inp_join_group(struct inpcb *inp, struct
  	} else {
  		inm = imo->imo_membership[idx];
  		imf = &imo->imo_mfilters[idx];
 -		if (ssa->ss.ss_family != AF_UNSPEC &&
 -		    imf->imf_st[1] != MCAST_INCLUDE) {
 -			error = EINVAL;
 -			goto out_inp_locked;
 -		}
 -		lims = imo_match_source(imo, idx, &ssa->sa);
 -		if (lims != NULL) {
 -			error = EADDRNOTAVAIL;
 -			goto out_inp_locked;
 +		if (ssa->ss.ss_family != AF_UNSPEC) {
 +			/*
 +			 * MCAST_JOIN_SOURCE on an exclusive membership
 +			 * is an error. On an existing inclusive membership,
 +			 * it just adds the source to the filter list.
 +			 */
 +			if (imf->imf_st[1] != MCAST_INCLUDE) {
 +				error = EINVAL;
 +				goto out_inp_locked;
 +			}
 +			/* Throw out duplicates. */
 +			lims = imo_match_source(imo, idx, &ssa->sa);
 +			if (lims != NULL) {
 +				error = EADDRNOTAVAIL;
 +				goto out_inp_locked;
 +			}
 +		} else {
 +			/*
 +			 * MCAST_JOIN_GROUP on an existing inclusive
 +			 * membership is an error; if you want to change
 +			 * filter mode, you must use the userland API
 +			 * setsourcefilter().
 +			 */
 +			if (imf->imf_st[1] == MCAST_INCLUDE) {
 +				error = EINVAL;
 +				goto out_inp_locked;
 +			}
  		}
  	}
  
 @@ -2010,7 +2023,8 @@ inp_join_group(struct inpcb *inp, struct
  	/*
  	 * Graft new source into filter list for this inpcb's
  	 * membership of the group. The in_multi may not have
 -	 * been allocated yet if this is a new membership.
 +	 * been allocated yet if this is a new membership, however,
 +	 * the in_mfilter slot will be allocated and must be initialized.
  	 */
  	if (ssa->ss.ss_family != AF_UNSPEC) {
  		/* Membership starts in IN mode */
 @@ -2027,6 +2041,12 @@ inp_join_group(struct inpcb *inp, struct
  			error = ENOMEM;
  			goto out_imo_free;
  		}
 +	} else {
 +		/* No address specified; Membership starts in EX mode */
 +		if (is_new) {
 +			CTR1(KTR_IGMPV3, "%s: new join w/o source", __func__);
 +			imf_init(imf, MCAST_UNDEFINED, MCAST_EXCLUDE);
 +		}
  	}
  
  	/*
 @@ -2189,6 +2209,9 @@ inp_leave_group(struct inpcb *inp, struc
  	if (!IN_MULTICAST(ntohl(gsa->sin.sin_addr.s_addr)))
  		return (EINVAL);
  
 +	if (ifp == NULL)
 +		return (EADDRNOTAVAIL);
 +
  	/*
  	 * Find the membership in the membership array.
  	 */
 @@ -2275,9 +2298,11 @@ out_imf_rollback:
  	imf_reap(imf);
  
  	if (is_final) {
 -		/* Remove the gap in the membership array. */
 -		for (++idx; idx < imo->imo_num_memberships; ++idx)
 +		/* Remove the gap in the membership and filter array. */
 +		for (++idx; idx < imo->imo_num_memberships; ++idx) {
  			imo->imo_membership[idx-1] = imo->imo_membership[idx];
 +			imo->imo_mfilters[idx-1] = imo->imo_mfilters[idx];
 +		}
  		imo->imo_num_memberships--;
  	}
  
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
From dfilter at FreeBSD.ORG  Thu Sep 17 13:50:07 2009
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Thu Sep 17 13:58:39 2009
Subject: kern/138690: commit references a PR
Message-ID: <200909171350.n8HDo7e1010367@freefall.freebsd.org>

The following reply was made to PR kern/138690; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/138690: commit references a PR
Date: Thu, 17 Sep 2009 13:42:09 +0000 (UTC)

 Author: bms
 Date: Thu Sep 17 13:41:59 2009
 New Revision: 197280
 URL: http://svn.freebsd.org/changeset/base/197280
 
 Log:
   MFC revs 197129,197130,197132:
    Fixes to mcast userland API.
   --
     Fix an API issue in leave processing for IPv4 multicast groups.
      * Do not assume that the group lookup performed by imo_match_group()
        is valid when ifp is NULL in this case.
      * Instead, return EADDRNOTAVAIL if the ifp cannot be resolved for the
        membership we are being asked to leave.
   
     Caveat user:
      * The way IPv4 multicast memberships are implemented in the inpcb layer
        at the moment, has the side-effect that struct ip_moptions will
        still hold the membership, under the old ifp, until ip_freemoptions()
        is called for the parent inpcb.
      * The underlying issue is: the inpcb layer does not get notification
        of ifp being detached going away in a thread-safe manner.
        This is non-trivial to fix.
   --
     Fix an obvious logic error in the IPv4 multicast leave processing,
     where the filter mode vector was not updated correctly after the leave.
   --
     Tighten input checking in inp_join_group():
      * Don't try to use the source address, when its family is unspecified.
      * If we get a join without a source, on an existing inclusive
        mode group, this is an error, as it would change the filter mode.
   
     Fix a problem with the handling of in_mfilter for new memberships:
      * Do not rely on imf being NULL; it is explicitly initialized to a
        non-NULL pointer when constructing a membership.
      * Explicitly initialize *imf to EX mode when the source address
        is unspecified.
     This fixes a problem with in_mfilter slot recycling in the join path.
   --
     Don't allow joins w/o source on an existing group.
     This is almost always pilot error.
   
     We don't need to check for group filter UNDEFINED state at t1,
     because we only ever allocate filters with their groups, so we
     unconditionally reject such calls with EINVAL.
     Trying to change the active filter mode w/o going through IP_MSFILTER
     is also disallowed.
   
     Deals with the case described in PR 137164 upfront, cumulative
     with the fix in svn rev 197132 which only calls imo_match_source()
     if the source address family was not unspecified.
   --
   
   Revision 197136 has a text conflict, however it is a comment only change.
   
   PR:		137164, 138689, 138690, 138691
   Submitted by:	Stef Walter (with fixups)
   Approved by:	re (kib)
 
 Modified:
   stable/8/sys/   (props changed)
   stable/8/sys/amd64/include/xen/   (props changed)
   stable/8/sys/cddl/contrib/opensolaris/   (props changed)
   stable/8/sys/contrib/dev/acpica/   (props changed)
   stable/8/sys/contrib/pf/   (props changed)
   stable/8/sys/dev/ciss/   (props changed)
   stable/8/sys/dev/xen/xenpci/   (props changed)
   stable/8/sys/netinet/in_mcast.c
 
 Modified: stable/8/sys/netinet/in_mcast.c
 ==============================================================================
 --- stable/8/sys/netinet/in_mcast.c	Thu Sep 17 13:33:40 2009	(r197279)
 +++ stable/8/sys/netinet/in_mcast.c	Thu Sep 17 13:41:59 2009	(r197280)
 @@ -1957,11 +1957,6 @@ inp_join_group(struct inpcb *inp, struct
  	if (ifp == NULL || (ifp->if_flags & IFF_MULTICAST) == 0)
  		return (EADDRNOTAVAIL);
  
 -	/*
 -	 * MCAST_JOIN_SOURCE on an exclusive membership is an error.
 -	 * On an existing inclusive membership, it just adds the
 -	 * source to the filter list.
 -	 */
  	imo = inp_findmoptions(inp);
  	idx = imo_match_group(imo, ifp, &gsa->sa);
  	if (idx == -1) {
 @@ -1969,15 +1964,33 @@ inp_join_group(struct inpcb *inp, struct
  	} else {
  		inm = imo->imo_membership[idx];
  		imf = &imo->imo_mfilters[idx];
 -		if (ssa->ss.ss_family != AF_UNSPEC &&
 -		    imf->imf_st[1] != MCAST_INCLUDE) {
 -			error = EINVAL;
 -			goto out_inp_locked;
 -		}
 -		lims = imo_match_source(imo, idx, &ssa->sa);
 -		if (lims != NULL) {
 -			error = EADDRNOTAVAIL;
 -			goto out_inp_locked;
 +		if (ssa->ss.ss_family != AF_UNSPEC) {
 +			/*
 +			 * MCAST_JOIN_SOURCE on an exclusive membership
 +			 * is an error. On an existing inclusive membership,
 +			 * it just adds the source to the filter list.
 +			 */
 +			if (imf->imf_st[1] != MCAST_INCLUDE) {
 +				error = EINVAL;
 +				goto out_inp_locked;
 +			}
 +			/* Throw out duplicates. */
 +			lims = imo_match_source(imo, idx, &ssa->sa);
 +			if (lims != NULL) {
 +				error = EADDRNOTAVAIL;
 +				goto out_inp_locked;
 +			}
 +		} else {
 +			/*
 +			 * MCAST_JOIN_GROUP on an existing inclusive
 +			 * membership is an error; if you want to change
 +			 * filter mode, you must use the userland API
 +			 * setsourcefilter().
 +			 */
 +			if (imf->imf_st[1] == MCAST_INCLUDE) {
 +				error = EINVAL;
 +				goto out_inp_locked;
 +			}
  		}
  	}
  
 @@ -2010,7 +2023,8 @@ inp_join_group(struct inpcb *inp, struct
  	/*
  	 * Graft new source into filter list for this inpcb's
  	 * membership of the group. The in_multi may not have
 -	 * been allocated yet if this is a new membership.
 +	 * been allocated yet if this is a new membership, however,
 +	 * the in_mfilter slot will be allocated and must be initialized.
  	 */
  	if (ssa->ss.ss_family != AF_UNSPEC) {
  		/* Membership starts in IN mode */
 @@ -2027,6 +2041,12 @@ inp_join_group(struct inpcb *inp, struct
  			error = ENOMEM;
  			goto out_imo_free;
  		}
 +	} else {
 +		/* No address specified; Membership starts in EX mode */
 +		if (is_new) {
 +			CTR1(KTR_IGMPV3, "%s: new join w/o source", __func__);
 +			imf_init(imf, MCAST_UNDEFINED, MCAST_EXCLUDE);
 +		}
  	}
  
  	/*
 @@ -2189,6 +2209,9 @@ inp_leave_group(struct inpcb *inp, struc
  	if (!IN_MULTICAST(ntohl(gsa->sin.sin_addr.s_addr)))
  		return (EINVAL);
  
 +	if (ifp == NULL)
 +		return (EADDRNOTAVAIL);
 +
  	/*
  	 * Find the membership in the membership array.
  	 */
 @@ -2275,9 +2298,11 @@ out_imf_rollback:
  	imf_reap(imf);
  
  	if (is_final) {
 -		/* Remove the gap in the membership array. */
 -		for (++idx; idx < imo->imo_num_memberships; ++idx)
 +		/* Remove the gap in the membership and filter array. */
 +		for (++idx; idx < imo->imo_num_memberships; ++idx) {
  			imo->imo_membership[idx-1] = imo->imo_membership[idx];
 +			imo->imo_mfilters[idx-1] = imo->imo_mfilters[idx];
 +		}
  		imo->imo_num_memberships--;
  	}
  
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
From dfilter at FreeBSD.ORG  Thu Sep 17 13:50:10 2009
From: dfilter at FreeBSD.ORG (dfilter service)
Date: Thu Sep 17 13:58:40 2009
Subject: kern/138691: commit references a PR
Message-ID: <200909171350.n8HDoAwG010641@freefall.freebsd.org>

The following reply was made to PR kern/138691; it has been noted by GNATS.

From: dfilter@FreeBSD.ORG (dfilter service)
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: kern/138691: commit references a PR
Date: Thu, 17 Sep 2009 13:42:10 +0000 (UTC)

 Author: bms
 Date: Thu Sep 17 13:41:59 2009
 New Revision: 197280
 URL: http://svn.freebsd.org/changeset/base/197280
 
 Log:
   MFC revs 197129,197130,197132:
    Fixes to mcast userland API.
   --
     Fix an API issue in leave processing for IPv4 multicast groups.
      * Do not assume that the group lookup performed by imo_match_group()
        is valid when ifp is NULL in this case.
      * Instead, return EADDRNOTAVAIL if the ifp cannot be resolved for the
        membership we are being asked to leave.
   
     Caveat user:
      * The way IPv4 multicast memberships are implemented in the inpcb layer
        at the moment, has the side-effect that struct ip_moptions will
        still hold the membership, under the old ifp, until ip_freemoptions()
        is called for the parent inpcb.
      * The underlying issue is: the inpcb layer does not get notification
        of ifp being detached going away in a thread-safe manner.
        This is non-trivial to fix.
   --
     Fix an obvious logic error in the IPv4 multicast leave processing,
     where the filter mode vector was not updated correctly after the leave.
   --
     Tighten input checking in inp_join_group():
      * Don't try to use the source address, when its family is unspecified.
      * If we get a join without a source, on an existing inclusive
        mode group, this is an error, as it would change the filter mode.
   
     Fix a problem with the handling of in_mfilter for new memberships:
      * Do not rely on imf being NULL; it is explicitly initialized to a
        non-NULL pointer when constructing a membership.
      * Explicitly initialize *imf to EX mode when the source address
        is unspecified.
     This fixes a problem with in_mfilter slot recycling in the join path.
   --
     Don't allow joins w/o source on an existing group.
     This is almost always pilot error.
   
     We don't need to check for group filter UNDEFINED state at t1,
     because we only ever allocate filters with their groups, so we
     unconditionally reject such calls with EINVAL.
     Trying to change the active filter mode w/o going through IP_MSFILTER
     is also disallowed.
   
     Deals with the case described in PR 137164 upfront, cumulative
     with the fix in svn rev 197132 which only calls imo_match_source()
     if the source address family was not unspecified.
   --
   
   Revision 197136 has a text conflict, however it is a comment only change.
   
   PR:		137164, 138689, 138690, 138691
   Submitted by:	Stef Walter (with fixups)
   Approved by:	re (kib)
 
 Modified:
   stable/8/sys/   (props changed)
   stable/8/sys/amd64/include/xen/   (props changed)
   stable/8/sys/cddl/contrib/opensolaris/   (props changed)
   stable/8/sys/contrib/dev/acpica/   (props changed)
   stable/8/sys/contrib/pf/   (props changed)
   stable/8/sys/dev/ciss/   (props changed)
   stable/8/sys/dev/xen/xenpci/   (props changed)
   stable/8/sys/netinet/in_mcast.c
 
 Modified: stable/8/sys/netinet/in_mcast.c
 ==============================================================================
 --- stable/8/sys/netinet/in_mcast.c	Thu Sep 17 13:33:40 2009	(r197279)
 +++ stable/8/sys/netinet/in_mcast.c	Thu Sep 17 13:41:59 2009	(r197280)
 @@ -1957,11 +1957,6 @@ inp_join_group(struct inpcb *inp, struct
  	if (ifp == NULL || (ifp->if_flags & IFF_MULTICAST) == 0)
  		return (EADDRNOTAVAIL);
  
 -	/*
 -	 * MCAST_JOIN_SOURCE on an exclusive membership is an error.
 -	 * On an existing inclusive membership, it just adds the
 -	 * source to the filter list.
 -	 */
  	imo = inp_findmoptions(inp);
  	idx = imo_match_group(imo, ifp, &gsa->sa);
  	if (idx == -1) {
 @@ -1969,15 +1964,33 @@ inp_join_group(struct inpcb *inp, struct
  	} else {
  		inm = imo->imo_membership[idx];
  		imf = &imo->imo_mfilters[idx];
 -		if (ssa->ss.ss_family != AF_UNSPEC &&
 -		    imf->imf_st[1] != MCAST_INCLUDE) {
 -			error = EINVAL;
 -			goto out_inp_locked;
 -		}
 -		lims = imo_match_source(imo, idx, &ssa->sa);
 -		if (lims != NULL) {
 -			error = EADDRNOTAVAIL;
 -			goto out_inp_locked;
 +		if (ssa->ss.ss_family != AF_UNSPEC) {
 +			/*
 +			 * MCAST_JOIN_SOURCE on an exclusive membership
 +			 * is an error. On an existing inclusive membership,
 +			 * it just adds the source to the filter list.
 +			 */
 +			if (imf->imf_st[1] != MCAST_INCLUDE) {
 +				error = EINVAL;
 +				goto out_inp_locked;
 +			}
 +			/* Throw out duplicates. */
 +			lims = imo_match_source(imo, idx, &ssa->sa);
 +			if (lims != NULL) {
 +				error = EADDRNOTAVAIL;
 +				goto out_inp_locked;
 +			}
 +		} else {
 +			/*
 +			 * MCAST_JOIN_GROUP on an existing inclusive
 +			 * membership is an error; if you want to change
 +			 * filter mode, you must use the userland API
 +			 * setsourcefilter().
 +			 */
 +			if (imf->imf_st[1] == MCAST_INCLUDE) {
 +				error = EINVAL;
 +				goto out_inp_locked;
 +			}
  		}
  	}
  
 @@ -2010,7 +2023,8 @@ inp_join_group(struct inpcb *inp, struct
  	/*
  	 * Graft new source into filter list for this inpcb's
  	 * membership of the group. The in_multi may not have
 -	 * been allocated yet if this is a new membership.
 +	 * been allocated yet if this is a new membership, however,
 +	 * the in_mfilter slot will be allocated and must be initialized.
  	 */
  	if (ssa->ss.ss_family != AF_UNSPEC) {
  		/* Membership starts in IN mode */
 @@ -2027,6 +2041,12 @@ inp_join_group(struct inpcb *inp, struct
  			error = ENOMEM;
  			goto out_imo_free;
  		}
 +	} else {
 +		/* No address specified; Membership starts in EX mode */
 +		if (is_new) {
 +			CTR1(KTR_IGMPV3, "%s: new join w/o source", __func__);
 +			imf_init(imf, MCAST_UNDEFINED, MCAST_EXCLUDE);
 +		}
  	}
  
  	/*
 @@ -2189,6 +2209,9 @@ inp_leave_group(struct inpcb *inp, struc
  	if (!IN_MULTICAST(ntohl(gsa->sin.sin_addr.s_addr)))
  		return (EINVAL);
  
 +	if (ifp == NULL)
 +		return (EADDRNOTAVAIL);
 +
  	/*
  	 * Find the membership in the membership array.
  	 */
 @@ -2275,9 +2298,11 @@ out_imf_rollback:
  	imf_reap(imf);
  
  	if (is_final) {
 -		/* Remove the gap in the membership array. */
 -		for (++idx; idx < imo->imo_num_memberships; ++idx)
 +		/* Remove the gap in the membership and filter array. */
 +		for (++idx; idx < imo->imo_num_memberships; ++idx) {
  			imo->imo_membership[idx-1] = imo->imo_membership[idx];
 +			imo->imo_mfilters[idx-1] = imo->imo_mfilters[idx];
 +		}
  		imo->imo_num_memberships--;
  	}
  
 _______________________________________________
 svn-src-all@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/svn-src-all
 To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
 
From linimon at FreeBSD.org  Fri Sep 18 06:00:37 2009
From: linimon at FreeBSD.org (linimon@FreeBSD.org)
Date: Fri Sep 18 06:00:48 2009
Subject: kern/133213: arp and sshd errors on 7.1-PRERELEASE
Message-ID: <200909180600.n8I60aB1098068@freefall.freebsd.org>

Old Synopsis: arp and sshd errors
New Synopsis: arp and sshd errors on 7.1-PRERELEASE

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Sep 18 05:07:29 UTC 2009
Responsible-Changed-Why: 
Fix up Synopsis.

To submitter: do you still see this error with 7.2 or 8.0-BETA3?

http://www.freebsd.org/cgi/query-pr.cgi?pr=133213
From e280s4ever at gmail.com  Fri Sep 18 13:08:11 2009
From: e280s4ever at gmail.com (e280s 4ever)
Date: Fri Sep 18 13:08:18 2009
Subject: [if_em.c] ping cause system crash
Message-ID: <600614150909180542t3895bf4ybf1e02392fe8131d@mail.gmail.com>

discription:

1. before the system crash, i have excuted these commands:
ipfw add 00100 nat 100 all from any to any
ipfw nat 100 config redirect_addr 192.168.1.100 10.10.10.10
192.168.1.100 is my em0, and 10.10.10.10 is a alias address of lo0.

2. then run ping some_addr, the system to be crashed.

3. the follow lines is the result of  kgdb

localhost# kgdb kernel.debug /var/crash/vmcore.3
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
cpuid = 0; apic id = 00
fault virtual address = 0xc
fault code = supervisor write, page not present
instruction pointer = 0x20:0xc04ccd7d
stack pointer = 0x28:0xe648d6c4
frame pointer = 0x28:0xe648d96c
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 = 1574 (ping)
trap number = 12
panic: page fault
cpuid = 0
Uptime: 23s
Physical memory: 990 MB
Dumping 59 MB: 44 28 12

Reading symbols from /boot/kernel/if_wpi.ko...Reading symbols from
/boot/kernel/if_wpi.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/if_wpi.ko
Reading symbols from /boot/kernel/snd_hda.ko...Reading symbols from
/boot/kernel/snd_hda.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/snd_hda.ko
Reading symbols from /boot/kernel/sound.ko...Reading symbols from
/boot/kernel/sound.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/sound.ko
Reading symbols from /boot/kernel/acpi_ibm.ko...Reading symbols from
/boot/kernel/acpi_ibm.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/acpi_ibm.ko
Reading symbols from /boot/kernel/ng_ubt.ko...Reading symbols from
/boot/kernel/ng_ubt.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_ubt.ko
Reading symbols from /boot/kernel/netgraph.ko...Reading symbols from
/boot/kernel/netgraph.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/netgraph.ko
Reading symbols from /boot/kernel/ng_hci.ko...Reading symbols from
/boot/kernel/ng_hci.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_hci.ko
Reading symbols from /boot/kernel/ng_bluetooth.ko...Reading symbols from
/boot/kernel/ng_bluetooth.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/ng_bluetooth.ko
Reading symbols from /boot/modules/vboxdrv.ko...done.
Loaded symbols for /boot/modules/vboxdrv.ko
Reading symbols from /boot/kernel/procfs.ko...Reading symbols from
/boot/kernel/procfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/procfs.ko
Reading symbols from /boot/kernel/pseudofs.ko...Reading symbols from
/boot/kernel/pseudofs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/pseudofs.ko
#0 doadump () at pcpu.h:246
246 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) list *0xc04ccd7d
0xc04ccd7d is in em_xmit (/usr/src/sys/dev/e1000/if_em.c:3800).
3795 }
3796 default:
3797 break;
3798 }
3799
3800 TXD->tcp_seg_setup.data = htole32(0);
3801 TXD->cmd_and_length =
3802 htole32(adapter->txd_cmd | E1000_TXD_CMD_DEXT | cmd);
3803 tx_buffer = &adapter->tx_buffer_area[curr_txd];
3804 tx_buffer->m_head = NULL;
(kgdb) backtrace
#0 doadump () at pcpu.h:246
#1 0xc05ec913 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416
#2 0xc05ecbf0 in panic (fmt=Variable "fmt" is not available.
) at /usr/src/sys/kern/kern_shutdown.c:579
#3 0xc07931e1 in trap_fatal (frame=0xe648d684, eva=12) at
/usr/src/sys/i386/i386/trap.c:933
#4 0xc0793431 in trap_pfault (frame=0xe648d684, usermode=0, eva=12) at
/usr/src/sys/i386/i386/trap.c:846
#5 0xc0793d31 in trap (frame=0xe648d684) at
/usr/src/sys/i386/i386/trap.c:528
#6 0xc0778dab in calltrap () at /usr/src/sys/i386/i386/exception.s:165
#7 0xc04ccd7d in em_xmit (adapter=0xc3e71000, m_headp=Variable "m_headp" is
not available.
) at /usr/src/sys/dev/e1000/if_em.c:3791
#8 0xc04d0090 in em_mq_start_locked (ifp=0xc3e66c00, m=0xc3ed9000) at
/usr/src/sys/dev/e1000/if_em.c:1037
#9 0xc04d06b6 in em_mq_start (ifp=0xc3e66c00, m=0xc3ed9000) at
/usr/src/sys/dev/e1000/if_em.c:1097
#10 0xc06891c0 in ether_output_frame (ifp=0xc3e66c00, m=0xc3ed9000) at
/usr/src/sys/net/if_ethersubr.c:452
#11 0xc0689adb in ether_output (ifp=0xc3e66c00, m=0xc3ed9000,
dst=0xc42592b0, ro=0xe648dac4)
at /usr/src/sys/net/if_ethersubr.c:423
#12 0xc06ddf9a in ip_output (m=0xc46b2400, opt=0x0, ro=0xe648dac4,
flags=Variable "flags" is not available.
) at /usr/src/sys/netinet/ip_output.c:620
#13 0xc06f217e in udp_send (so=0xc4424670, flags=0, m=0xc3ed9100, addr=0x0,
control=0x0, td=0xc42a96c0)
at /usr/src/sys/netinet/udp_usrreq.c:1236
#14 0xc0645909 in sosend_dgram (so=0xc4424670, addr=0x0, uio=0xe648dbec,
top=0xc3ed9100, control=0x0, flags=Variable "flags" is not available.
)
at /usr/src/sys/kern/uipc_socket.c:1072
#15 0xc06418f7 in sosend (so=0xc4424670, addr=0x0, uio=0xe648dbec, top=0x0,
control=0x0, flags=0, td=0xc42a96c0)
at /usr/src/sys/kern/uipc_socket.c:1303
#16 0xc06489b3 in kern_sendit (td=0xc42a96c0, s=5, mp=0xe648dc60, flags=0,
control=0x0, segflg=UIO_USERSPACE)
at /usr/src/sys/kern/uipc_syscalls.c:783
#17 0xc0648b9a in sendit (td=0xc42a96c0, s=5, mp=0xe648dc60, flags=0) at
/usr/src/sys/kern/uipc_syscalls.c:719
#18 0xc0648c8f in sendto (td=0xc42a96c0, uap=0xe648dcf8) at
/usr/src/sys/kern/uipc_syscalls.c:835
#19 0xc079371b in syscall (frame=0xe648dd38) at
/usr/src/sys/i386/i386/trap.c:1073
#20 0xc0778e10 in Xint0x80_syscall () at
/usr/src/sys/i386/i386/exception.s:261
#21 0x00000033 in ?? ()
Previous frame inner to this frame (corrupt stack?)
From ed at FreeBSD.org  Fri Sep 18 13:46:15 2009
From: ed at FreeBSD.org (ed@FreeBSD.org)
Date: Fri Sep 18 13:46:22 2009
Subject: kern/133786: [netinet] [patch] ip_input might cause kernel panic
Message-ID: <200909181346.n8IDkEUP086368@freefall.freebsd.org>

Synopsis: [netinet] [patch] ip_input might cause kernel panic

Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: ed
Responsible-Changed-When: Fri Sep 18 13:45:51 UTC 2009
Responsible-Changed-Why: 
This looks like a networking issue.

http://www.freebsd.org/cgi/query-pr.cgi?pr=133786
From bms at incunabulum.net  Fri Sep 18 15:50:03 2009
From: bms at incunabulum.net (Bruce Simpson)
Date: Fri Sep 18 15:50:11 2009
Subject: kern/133786: [netinet] [patch] ip_input might cause kernel panic
Message-ID: <200909181550.n8IFo3gu006351@freefall.freebsd.org>

The following reply was made to PR kern/133786; it has been noted by GNATS.

From: Bruce Simpson <bms@incunabulum.net>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: kern/133786: [netinet] [patch] ip_input might cause kernel panic
Date: Fri, 18 Sep 2009 16:40:20 +0100

 Interesting... the input checks in ip_input() should really have 
 screened this out, however, if m->m_len is indeed smaller than mcopy 
 (temporary mbuf created in the ip_forward() slow path), then 
 m_copydata() may well stomp on memory not owned by the mbuf chain.
 
 
 
 
From morganw at chemikals.org  Sat Sep 19 12:44:31 2009
From: morganw at chemikals.org (Wes Morgan)
Date: Sat Sep 19 12:44:37 2009
Subject: bwi driver
In-Reply-To: <4AABE908.5020201@imada.sdu.dk>
References: <4AABE908.5020201@imada.sdu.dk>
Message-ID: <alpine.BSF.2.00.0909190743110.19904@ibyngvyr.purzvxnyf.bet>

On Sat, 12 Sep 2009, Ralph Zitz wrote:

> Hello
>
> I'm the unfortunate owner of the unsupported "Intel WiFi Link 5100 AGN" card. 
> Looking through some old hardware I found the following: "Linksys WPC54G 
> version 3.1" pccard. I realize that the bwi driver lists as only supporting 
> version 3, but might there be a chance my card works with the driver as well?
>
> When the card is inserted the kernel outputs the following:
> bwi0: <Broadcom BCM4318 802.11b/g Wireless Lan> mem 0xbf8a2000-0xbf8a3fff irq 
> 16 at device 0.0 on cardbus0
> bwi0: [ITHREAD]
> bwi0: no BBP id for device id 0x4318
> device_attach: bwi0 attach returned 6

You probably need to install the firmware port in 
/usr/ports/net/bwi-firmware-kmod.

From bruce.cran at gmail.com  Sat Sep 19 13:00:24 2009
From: bruce.cran at gmail.com (Bruce Cran)
Date: Sat Sep 19 13:00:38 2009
Subject: kern/64556: [sis] if_sis short cable fix problems with NetGear 
	FA311's
Message-ID: <200909191300.n8JD0NsX062669@freefall.freebsd.org>

The following reply was made to PR kern/64556; it has been noted by GNATS.

From: Bruce Cran <bruce.cran@gmail.com>
To: bug-followup@FreeBSD.org, tom@hur.st
Cc:  
Subject: Re: kern/64556: [sis] if_sis short cable fix problems with NetGear 
	FA311's
Date: Sat, 19 Sep 2009 13:52:43 +0100

 --0016e6dd98d78297b20473edb9f4
 Content-Type: text/plain; charset=ISO-8859-1
 
 The problem is caused when the CPU can't keep up with packet
 processing, causing an RX overrun to occur.  On a 1.2GHz AthlonXP
 based system I can get errors to occur if for example I run a grep
 over /usr/src - with a 500MHz CPU I guess it would have trouble
 keeping up at all.  With both ttcp's running, 50% of the CPU time is
 taken up processing interrupts from the card.  Not resetting the card
 when an error occurs seems to have no detrimental effect, so I've put
 together a patch which just logs the error in the if_ierrors interface
 field.   The patch also reduces the delay when setting the short cable
 fix from 100ms to 100us.
 
 -- 
 Bruce Cran
 
 --0016e6dd98d78297b20473edb9f4
 Content-Type: text/plain; charset=US-ASCII; name="if_sis.c.diff.txt"
 Content-Disposition: attachment; filename="if_sis.c.diff.txt"
 Content-Transfer-Encoding: base64
 X-Attachment-Id: f_fzscswvn0
 
 LS0tIHN5cy9kZXYvc2lzL2lmX3Npcy5jLm9yaWcJMjAwOS0wOS0xOCAyMDozMTo1My4wMDAwMDAw
 MDAgKzAxMDAKKysrIHN5cy9kZXYvc2lzL2lmX3Npcy5jCTIwMDktMDktMTkgMDI6NDI6NTcuMDAw
 MDAwMDAwICswMTAwCkBAIC0xNDgzLDE1ICsxNDgzLDYgQEAKIAlyZXR1cm4gKHJ4X25wa3RzKTsK
 IH0KIAotc3RhdGljIHZvaWQKLXNpc19yeGVvYyhzdHJ1Y3Qgc2lzX3NvZnRjICpzYykKLXsKLQot
 CVNJU19MT0NLX0FTU0VSVChzYyk7Ci0Jc2lzX3J4ZW9mKHNjKTsKLQlzaXNfaW5pdGwoc2MpOwot
 fQotCiAvKgogICogQSBmcmFtZSB3YXMgZG93bmxvYWRlZCB0byB0aGUgY2hpcC4gSXQncyBzYWZl
 IGZvciB1cyB0byBjbGVhbiB1cAogICogdGhlIGxpc3QgYnVmZmVycy4KQEAgLTE2MTQsNyArMTYw
 NSw3IEBACiAJCXN0YXR1cyA9IENTUl9SRUFEXzQoc2MsIFNJU19JU1IpOwogCiAJCWlmIChzdGF0
 dXMgJiAoU0lTX0lTUl9SWF9FUlJ8U0lTX0lTUl9SWF9PRkxPVykpCi0JCQlzaXNfcnhlb2Moc2Mp
 OworCQkJaWZwLT5pZl9pZXJyb3JzKys7CiAKIAkJaWYgKHN0YXR1cyAmIChTSVNfSVNSX1JYX0lE
 TEUpKQogCQkJU0lTX1NFVEJJVChzYywgU0lTX0NTUiwgU0lTX0NTUl9SWF9FTkFCTEUpOwpAQCAt
 MTY3Miw3ICsxNjYzLDcgQEAKIAkJCXNpc19yeGVvZihzYyk7CiAKIAkJaWYgKHN0YXR1cyAmIFNJ
 U19JU1JfUlhfT0ZMT1cpCi0JCQlzaXNfcnhlb2Moc2MpOworCQkJaWZwLT5pZl9pZXJyb3JzKys7
 CiAKIAkJaWYgKHN0YXR1cyAmIChTSVNfSVNSX1JYX0lETEUpKQogCQkJU0lTX1NFVEJJVChzYywg
 U0lTX0NTUiwgU0lTX0NTUl9SWF9FTkFCTEUpOwpAQCAtMjAxNyw3ICsyMDA4LDcgQEAKIAkJQ1NS
 X1dSSVRFXzQoc2MsIE5TX1BIWV9QQUdFLCAweDAwMDEpOwogCQlyZWcgPSBDU1JfUkVBRF80KHNj
 LCBOU19QSFlfRFNQQ0ZHKSAmIDB4ZmZmOwogCQlDU1JfV1JJVEVfNChzYywgTlNfUEhZX0RTUENG
 RywgcmVnIHwgMHgxMDAwKTsKLQkJREVMQVkoMTAwMDAwKTsKKwkJREVMQVkoMTAwKTsKIAkJcmVn
 ID0gQ1NSX1JFQURfNChzYywgTlNfUEhZX1REQVRBKSAmIDB4ZmY7CiAJCWlmICgocmVnICYgMHgw
 MDgwKSA9PSAwIHx8IChyZWcgPiAweGQ4ICYmIHJlZyA8PSAweGZmKSkgewogCQkJZGV2aWNlX3By
 aW50ZihzYy0+c2lzX2RldiwK
 --0016e6dd98d78297b20473edb9f4--
From bruce.cran at gmail.com  Sat Sep 19 13:30:11 2009
From: bruce.cran at gmail.com (Bruce Cran)
Date: Sat Sep 19 13:30:17 2009
Subject: kern/64556: [sis] [patch] if_sis short cable fix problems with 
	NetGear FA311's
Message-ID: <200909191330.n8JDUAHj092140@freefall.freebsd.org>

The following reply was made to PR kern/64556; it has been noted by GNATS.

From: Bruce Cran <bruce.cran@gmail.com>
To: bug-followup@FreeBSD.org, tom@hur.st
Cc:  
Subject: Re: kern/64556: [sis] [patch] if_sis short cable fix problems with 
	NetGear FA311's
Date: Sat, 19 Sep 2009 14:21:58 +0100

 The patch is available from http://www.cran.org.uk/~brucec/freebsd/if_sis.c.diff
From barney_cordoba at yahoo.com  Sat Sep 19 20:36:05 2009
From: barney_cordoba at yahoo.com (Barney Cordoba)
Date: Sat Sep 19 20:36:11 2009
Subject: Can lagg0 failback be prevented?
In-Reply-To: <7B9397B189EB6E46A5EE7B4C8A4BB7CB3042DBE7@MBX03.exg5.exghost.com>
Message-ID: <491701.32471.qm@web63901.mail.re1.yahoo.com>



--- On Tue, 9/15/09, Peter Steele <psteele@maxiscale.com> wrote:

> From: Peter Steele <psteele@maxiscale.com>
> Subject: Can lagg0 failback be prevented?
> To: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>
> Date: Tuesday, September 15, 2009, 8:23 PM
> We're using the lag driver to provide
> automatic failover in case of a network outage. The default
> configuration looks like this:
> 
> lagg0:
> flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
> metric 0 mtu 1500
> ? ? ? ?
> options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
> ? ? ? ? ether 00:a0:d1:e3:58:26
> ? ? ? ? inet 192.168.17.40 netmask
> 0xfffff000 broadcast 192.168.31.255
> ? ? ? ? inet 192.168.22.11 netmask
> 0xffffff00 broadcast 192.168.22.255
> ? ? ? ? media: Ethernet autoselect
> ? ? ? ? status: active
> ? ? ? ? laggproto failover
> ? ? ? ? laggport: nfe1 flags=0<>
> ? ? ? ? laggport: nfe0
> flags=5<MASTER,ACTIVE>
> 
> If nfe0 was to fail, we get an (almost) automatic failover
> to nfe1:
> 
> lagg0:
> flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST>
> metric 0 mtu 1500
> ? ? ? ?
> options=19b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4>
> ? ? ? ? ether 00:a0:d1:e3:58:26
> ? ? ? ? inet 192.168.17.40 netmask
> 0xfffff000 broadcast 192.168.31.255
> ? ? ? ? inet 192.168.22.11 netmask
> 0xffffff00 broadcast 192.168.22.255
> ? ? ? ? media: Ethernet autoselect
> ? ? ? ? status: active
> ? ? ? ? laggproto failover
> ? ? ? ? laggport: nfe1
> flags=4<ACTIVE>
> ? ? ? ? laggport: nfe0
> flags=1<MASTER>
> 
> The problem we're having is when nfe0 comes online again, a
> failback occurs making nfe0 active again. This causes a
> momentary network outage that we want to prevent. Is there a
> way to configure the lagg device to stay with the currently
> active interface, even if the MASTER interface comes back
> online?

Why don't you just load balance? Usually fallback implies that 
one link is preferred (such as a more favorable path, or higher 
speed). 

Barney



      

From brucec at FreeBSD.org  Sat Sep 19 22:28:45 2009
From: brucec at FreeBSD.org (brucec@FreeBSD.org)
Date: Sat Sep 19 22:28:52 2009
Subject: kern/137795: [sctp] [panic] mtx_lock() of destroyed mutex
Message-ID: <200909192228.n8JMSi9T043135@freefall.freebsd.org>

Synopsis: [sctp] [panic] mtx_lock() of destroyed mutex

State-Changed-From-To: open->patched 
State-Changed-By: brucec
State-Changed-When: Sat Sep 19 22:27:50 UTC 2009
State-Changed-Why: 
The fix has been committed to HEAD and RELENG_8.

http://www.freebsd.org/cgi/query-pr.cgi?pr=137795
From Brian.Jacobs at lodgenet.com  Sun Sep 20 14:40:03 2009
From: Brian.Jacobs at lodgenet.com (Jacobs, Brian)
Date: Sun Sep 20 14:40:10 2009
Subject: Large scale GRE
Message-ID: <126E45722B459248997856ECB72DEB7701286109@host.lodgenet.com>

As promised, I'm dropping an on-list update of our GRE migration
project.  We're running just under 1,000 GRE interfaces (with ipsec
inside) with no problems on a dualproc/quadcore xeon 2.8 under 7.2-REL
(can't sup to anything later as someone broke the Compaq RAID driver).
We're only pushing about 15mb/s through the tunnels at peak, no drops or
errors that I've seen.  We do notice that ESP SA's for IKE tunnels don't
establish as expected (the farend network routes never "appear" like
they do in OpenBSD isakmpd, nor is the kernel grabbing the packets to
send down the IKE tunnel (though the OBSD/FBSD and farend configs are
identical), but I'm not done quadruple-checking to see if there's some
functional difference I've missed.  If anyone has any morsels of wisdom,
feel free to drop me a line.

 

Cheers!

 

/b

From bugmaster at FreeBSD.org  Mon Sep 21 11:07:01 2009
From: bugmaster at FreeBSD.org (FreeBSD bugmaster)
Date: Mon Sep 21 11:08:58 2009
Subject: Current problem reports assigned to freebsd-net@FreeBSD.org
Message-ID: <200909211107.n8LB70UQ030357@freefall.freebsd.org>

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/138850  net        [dummynet] dummynet doesn't work correctly on a bridge
o kern/138782  net        [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00
o kern/138739  net        [wpi] wpi(4) does not work very well under 8.0-BETA4
o kern/138694  net        [bge] FreeBSD 6.3 release does not recognize Broadcom 
p kern/138691  net        [netinet] [patch] Multicast: Keep membership and filte
p kern/138690  net        [netinet] [patch] multicast: uninited memory used in f
p kern/138689  net        [netinet] patch] Multicast: IP_DROP_MEMBERSHIP should 
o amd64/138688 net        [rum] possibly broken on 8 Beta 4 amd64: able to wpa a
o kern/138678  net        [lo] FreeBSD does not assign linklocal address to loop
o kern/138676  net        [route] after buildworld not work local routes [regres
o kern/138666  net        [multicast] [panic] not working multicast through igmp
o kern/138660  net        [igb] igb driver troubles in 8.0-BETA4
o kern/138652  net        TCP window scaling value calculated incorrectly?
o kern/138632  net        [ndis] [patch] race at vap destroy
o kern/138620  net        [lagg] [patch] lagg port bpf-writes blocked
o kern/138427  net        [wpi] [panic] Kernel panic after trying set monitor wl
o kern/138407  net        [gre] gre(4) interface does not come up after reboot
o kern/138390  net        [gif] [patch] NULL pointer dereference in gif_input() 
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/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 
p kern/137795  net        [sctp] [panic] mtx_lock() of destroyed mutex
o kern/137776  net        [rum] panic in rum(4) driver on 8.0-BETA2
o kern/137775  net        [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many
o bin/137641   net        ifconfig(8): various problems with "vlan_device.vlan_i
o kern/137592  net        [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne
o bin/137484   net        [patch] Integer overflow in wpa_supplicant(8) base64 e
o kern/137392  net        [ip] [panic] crash in ip_nat.c line 2577
o kern/137372  net        [ral] FreeBSD doesn't support wireless interface from 
o kern/137317  net        [tcp] logs full of syncache problems
o kern/137292  net        [ste] DFE-580TX not working properly
o kern/137279  net        [bge] [panic] Page fault (fatal trap 12) NFS server w/
o kern/137170  net        [ath] atheros AR9285 not recognised
p kern/137164  net        [netinet] [patch] assert panic imo_match_source()
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/133786  net        [netinet] [patch] ip_input might cause kernel panic
o kern/133736  net        [udp] ip_id not protected ...
o kern/133613  net        [wpi] [panic] kernel panic in wpi(4)
o kern/133595  net        [panic] Kernel Panic at pcpu.h:195
o kern/133572  net        [ppp] [hang] incoming PPTP connection hangs the system
o kern/133490  net        [bpf] [panic] 'kmem_map too small' panic on Dell r900 
o kern/133328  net        [bge] [panic] Kernel panics with Windows7 client
o kern/133235  net        [netinet] [patch] Process SIOCDLIFADDR command incorre
o kern/133218  net        [carp] [hang] use of carp(4) causes system to freeze
f kern/133213  net        arp and sshd errors on 7.1-PRERELEASE
o kern/133204  net        [msk] msk driver timeouts
o kern/133060  net        [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs
o kern/132991  net        [bge] if_bge low performance problem
f bin/132911   net        ip6fw(8): argument type of fill_icmptypes is wrong and
o kern/132889  net        [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d
o kern/132885  net        [wlan] 802.1x broken after SVN rev 189592
o conf/132851  net        [fib] [patch] allow to setup fib for service running f
o kern/132832  net        [netinet] [patch] tcp_output() might generate invalid 
o bin/132798   net        [patch] ggatec(8): ggated/ggatec connection slowdown p
o kern/132734  net        [ifmib] [panic] panic in net/if_mib.c
o kern/132722  net        [ath] Wifi ath0 associates fine with AP, but DHCP or I
o kern/132705  net        [libwrap] [patch] libwrap - infinite loop if hosts.all
o kern/132672  net        [ndis] [panic] ndis with rt2860.sys causes kernel pani
o kern/132669  net        [xl] 3c905-TX send DUP! in reply on ping (sometime)
o kern/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/113432  net        [ucom] WARNING: attempt to net_add_domain(netgraph) af
o kern/112722  net        [ipsec] [udp] IP v4 udp fragmented packet reject
o kern/112686  net        [patm] patm driver freezes System (FreeBSD 6.2-p4) i38
o kern/112570  net        [bge] packet loss with bge driver on BCM5704 chipset
o bin/112557   net        [patch] ppp(8) lock file should not use symlink name
o kern/112528  net        [nfs] NFS over TCP under load hangs with "impossible p
o kern/111457  net        [ral] ral(4) freeze
o kern/110140  net        [ipw] ipw fails under load
o kern/109733  net        [bge] bge link state issues [regression]
o kern/109470  net        [wi] Orinoco Classic Gold PC Card Can't Channel Hop
o kern/109308  net        [pppd] [panic] Multiple panics kernel ppp suspected [r
o kern/109251  net        [re] [patch] if_re cardbus card won't attach
o bin/108895   net        pppd(8): PPPoE dead connections on 6.2 [regression]
o kern/108542  net        [bce] Huge network latencies with 6.2-RELEASE / STABLE
o kern/107944  net        [wi] [patch] Forget to unlock mutex-locks
o kern/107850  net        [bce] bce driver link negotiation is faulty
o conf/107035  net        [patch] bridge(8): bridge interface given in rc.conf n
o kern/106438  net        [ipf] ipfilter: keep state does not seem to allow repl
o kern/106316  net        [dummynet] dummynet with multipass ipfw drops packets 
o kern/106243  net        [nve] double fault panic in if_nve.c on high loads
o kern/105945  net        Address can disappear from network interface
s kern/105943  net        Network stack may modify read-only mbuf chain copies
o bin/105925   net        problems with ifconfig(8) and vlan(4) [regression]
o kern/105348  net        [ath] ath device stopps TX
o kern/104851  net        [inet6] [patch] On link routes not configured when usi
o kern/104751  net        [netgraph] kernel panic, when getting info about my tr
o kern/104485  net        [bge] Broadcom BCM5704C: Intermittent on newer chip ve
o kern/103191  net        Unpredictable reboot
o kern/103135  net        [ipsec] ipsec with ipfw divert (not NAT) encodes a pac
o conf/102502  net        [netgraph] [patch] ifconfig name does't rename netgrap
o kern/102035  net        [plip] plip networking disables parallel port printing
o kern/101948  net        [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau
o kern/100709  net        [libc] getaddrinfo(3) should return TTL info
o kern/100519  net        [netisr] suggestion to fix suboptimal network polling
o kern/98978   net        [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel
o kern/98597   net        [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu
o bin/98218    net        wpa_supplicant(8) blacklist not working
f bin/97392    net        ppp(8) hangs instead terminating
o kern/97306   net        [netgraph] NG_L2TP locks after connection with failed 
f kern/96268   net        [socket] TCP socket performance drops by 3000% if pack
o kern/96030   net        [bfe] [patch] Install hangs with Broadcomm 440x NIC in
o kern/95519   net        [ral] ral0 could not map mbuf
o kern/95288   net        [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr
o kern/95277   net        [netinet] [patch] IP Encapsulation mask_match() return
o kern/95267   net        packet drops periodically appear
s kern/94863   net        [bge] [patch] hack to get bge(4) working on IBM e326m
o kern/94162   net        [bge] 6.x kenel stale with bge(4)
o kern/93886   net        [ath] Atheros/D-Link DWL-G650 long delay to associate 
f kern/93378   net        [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo
o kern/93019   net        [ppp] ppp and tunX problems: no traffic after restarti
o kern/92880   net        [libc] [patch] almost rewritten inet_network(3) functi
f kern/92552   net        A seri