From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 27F3021F1B0 for ; Fri, 4 Jan 2013 17:59:55 -0800 (PST) Received: by mail-ie0-f179.google.com with SMTP id k14so20320414iea.38 for ; Fri, 04 Jan 2013 17:59:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=S9UaqIBIUrK20OXkWz0rKmDf9yBc9TtjxXD4Z52AJFY=; b=c5R0noKkSLjP2yeD5Q0N7lN4zLGJ7GlGV+a4Ld4yITvj7n7az7v0mt30G2eL/jjweb l1OxPqU4fXD6JZ3qtcwxLLOEcu6mL9mBuG4NUCIftKjQUb8l3i7FdH7Q5WpLrcZsWnaP 51ALwyo19PCLtsGYfcz6CFAnGxRMgUkCaEdkT42r0X+b3E0pw4hvEwvY4wRmKqzkYt+2 isgsEfCOeXfPsmiZO3E8s6DebF92Ceyv9lWZ5Sdnc468jwDQuO2cjxpDbVR9EDTMVyPr lU9F/y8Htce7kW66j+rtD7Kb37ekh2MiuotTyFqOs0pFF0johuET6GMhxlRUfqqovS73 Tmcw== MIME-Version: 1.0 Received: by 10.50.53.196 with SMTP id d4mr332817igp.88.1357351194359; Fri, 04 Jan 2013 17:59:54 -0800 (PST) Received: by 10.64.53.105 with HTTP; Fri, 4 Jan 2013 17:59:53 -0800 (PST) Received: by 10.64.53.105 with HTTP; Fri, 4 Jan 2013 17:59:53 -0800 (PST) In-Reply-To: References: Date: Sat, 5 Jan 2013 07:29:53 +0530 Message-ID: From: Ketan Kulkarni To: Jerry Chu , Dave Taht , Yuchung Cheng Content-Type: multipart/mixed; boundary=f46d042fdeb2c6794c04d280f38b Cc: Eric Dumazet , cerowrt-devel Subject: Re: [Cerowrt-devel] TFO crashes cerowrt 3.7.1-1 X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 01:59:55 -0000 --f46d042fdeb2c6794c04d280f38b Content-Type: multipart/alternative; boundary=f46d042fdeb2c6794704d280f389 --f46d042fdeb2c6794704d280f389 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, I was trying polipo server on cero box and httping from laptop. On both the boxes I set 3 in tcp_fastopen. The panic is seen only when server is on cero box. If I run server on my laptop and httping from cero all TFO connections are successful. So I doubt its the only problem is SYN+DATA. Unfortunately I don't have the serial cable right now, and logread or dmesg didn't print any logs before the cero router restarted. Attached is the tcpdump capture on lo when client and server both run on cero box. HTH! If you (or anyone) can suggest more diagnostics, I will be glad to provide. On Jan 5, 2013 2:49 AM, "Jerry Chu" wrote: > +ycheng > > > On Fri, Jan 4, 2013 at 1:11 PM, Dave Taht wrote: > >> Hmm. I would lean towards there being an issue with the new (freshly >> ported forward to 3.7.1) unaligned checksum code for mips based on >> what you say here. Or an offload... >> >> As for the 239.x multicast issue, hmm... separate issue entirely. >> Probably... >> >> And then there's TFO. I note that in order to use it properly you need >> to turn it on in proc. Last I remember that was >> >> echo 3 > /proc/sys/net/ipv4/tcp_fastopen >> > > Correct - to enable the normal use of TFO for both client and server. > There are other flags for advanced usage: > /* Bit Flags for sysctl_tcp_fastopen */ > #define TFO_CLIENT_ENABLE 1 > #define TFO_SERVER_ENABLE 2 > #define TFO_CLIENT_NO_COOKIE 4 /* Send data-in-SYN w/o cookie */ > > /* Process SYN data but skip cookie validation */ > #define TFO_SERVER_COOKIE_NOT_CHKED 0x100 > /* Accept SYN data w/o any cookie option */ > #define TFO_SERVER_COOKIE_NOT_REQD 0x200 > > /* Force enable TFO on all listeners, i.e., not requiring the > * TCP_FASTOPEN socket option. SOCKOPT1/2 determine how to set max_qlen. > */ > #define TFO_SERVER_WO_SOCKOPT1 0x400 > #define TFO_SERVER_WO_SOCKOPT2 0x800 > /* Always create TFO child sockets on a TFO listener even when > * cookie/data not present. (For testing purpose!) > */ > #define TFO_SERVER_ALWAYS 0x1000 > > >> However that's an old memory and there is this tcp_fastopen_key file I >> don't know anything about yet (this is such bleeding edge stuff!) >> >> ... and with tcp_fastopen disabled things should still work right... >> so I'm thinking something else is busted in the stack. >> >> I've also observed a dns slowdown in what I've been testing but hadn't >> dug into packet dumps. (and was assuming, until now, it was due to me >> fiddling with ULAs inside the network) Thanks for digging this deep! >> >> I never said this first attempt at 3.7 for cero was going to be >> perfect, but we've entered a new age of subtle problems here. >> >> I strongly suggest nobody else try this dev build as a default gw, and >> that the TFO folk ignore the noise for now. >> > > SG. > > Jerry > > >> >> I just got a 3.7.1 box built on x86_64 so as to a/b some captures. >> Regrettably I'm short on time through the weekend... >> >> On Fri, Jan 4, 2013 at 12:42 PM, Maciej Soltysiak >> wrote: >> > I am seeing something strange here, with polipo related to TFO but als= o >> DNS. >> > When I just took 3.7.1-1 and set my windows 7 laptop to use >> gw.home.lan:8123 >> > as http proxy it didn't work. What I observed was: >> > A) after quite a while polipo's response to browser was 504 Host >> > www.osnews.com lookup failed: Timeout >> > b) this error in ssh console: Host osnews.com lookup failed: Timeout >> > (131072) >> > c) Disabling TFO by adding option useTCPFastOpen 'false' to config >> 'polipo' >> > 'general' works around the problem >> > d) Alternatively, you can keep TFO enabled in polipo but change option >> > 'dnsUseGethostbyname' from 'reluctantly' to 'true' (!) >> > This is very weird, because TFO is TCP and the DNS queries fired off b= y >> > polipo are UDP: >> > root@OpenWrt:/tmp/log# tcpdump -n -v -vv -vvv -x -X -s 1500 -i lo >> > 20:21:56.160245 IP (tos 0x0, ttl 64, id 50129, offset 0, flags [DF], >> proto >> > UDP (17), length 60) >> > 127.0.0.1.47304 > 127.0.0.1.53: [bad udp cksum 0xfe3b -> 0xd17f!] >> 55396+ A? >> > www.osnews.com. (32) >> > 0x0000: 4500 003c c3d1 4000 4011 78dd 7f00 0001 E..<..@.@.x..... >> > 0x0010: 7f00 0001 b8c8 0035 0028 fe3b d864 0100 .......5.(.;.d.. >> > 0x0020: 0001 0000 0000 0000 0377 7777 066f 736e .........www.osn >> > 0x0030: 6577 7303 636f 6d00 0001 0001 ews.com..... >> > 20:21:56.160319 IP (tos 0x0, ttl 64, id 50130, offset 0, flags [DF], >> proto >> > UDP (17), length 60) >> > 127.0.0.1.47304 > 127.0.0.1.53: [bad udp cksum 0xfe3b -> 0xd164!] 5539= 6+ >> > AAAA? www.osnews.com. (32) >> > 0x0000: 4500 003c c3d2 4000 4011 78dc 7f00 0001 E..<..@.@.x..... >> > 0x0010: 7f00 0001 b8c8 0035 0028 fe3b d864 0100 .......5.(.;.d.. >> > 0x0020: 0001 0000 0000 0000 0377 7777 066f 736e .........www.osn >> > 0x0030: 6577 7303 636f 6d00 001c 0001 ews.com..... >> > 20:21:56.169942 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto >> UDP >> > (17), length 123) >> > 127.0.0.1.53 > 127.0.0.1.47304: [bad udp cksum 0xfe7a -> 0x5f73!] 5539= 6 >> q: >> > A? www.osnews.com. 1/2/0 www.osnews.com. [29m3s] A 74.86.31.159 ns: >> > osnews.com. [29m3s] NS ns2.swelter.net., osnews.com. [29m3s] NS >> > ns1.swelter.net. (95) >> > 0x0000: 4500 007b 0000 4000 4011 3c70 7f00 0001 E..{..@.@.> > 0x0010: 7f00 0001 0035 b8c8 0067 fe7a d864 8180 .....5...g.z.d.. >> > 0x0020: 0001 0001 0002 0000 0377 7777 066f 736e .........www.osn >> > 0x0030: 6577 7303 636f 6d00 0001 0001 c00c 0001 ews.com......... >> > 0x0040: 0001 0000 06cf 0004 4a56 1f9f c010 0002 ........JV...... >> > 0x0050: 0001 0000 06cf 0011 036e 7332 0773 7765 .........ns2.swe >> > 0x0060: 6c74 6572 036e 6574 00c0 1000 0200 0100 lter.net........ >> > 0x0070: 0006 cf00 0603 6e73 31c0 40 ......ns1.@ >> > 20:21:56.173901 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto >> UDP >> > (17), length 135) >> > 127.0.0.1.53 > 127.0.0.1.47304: [bad udp cksum 0xfe86 -> 0x8ecb!] 5539= 6 >> q: >> > AAAA? www.osnews.com. 1/2/0 www.osnews.com. [54m44s] AAAA >> > 2607:f0d0:1002:62::3 ns: osnews.com. [29m3s] NS ns1.swelter.net., >> > osnews.com. [29m3s] NS ns2.swelter.net. (107) >> > 0x0000: 4500 0087 0000 4000 4011 3c64 7f00 0001 E.....@.@.> > 0x0010: 7f00 0001 0035 b8c8 0073 fe86 d864 8180 .....5...s...d.. >> > 0x0020: 0001 0001 0002 0000 0377 7777 066f 736e .........www.osn >> > 0x0030: 6577 7303 636f 6d00 001c 0001 c00c 001c ews.com......... >> > 0x0040: 0001 0000 0cd4 0010 2607 f0d0 1002 0062 ........&......b >> > 0x0050: 0000 0000 0000 0003 c010 0002 0001 0000 ................ >> > 0x0060: 06cf 0011 036e 7331 0773 7765 6c74 6572 .....ns1.swelter >> > 0x0070: 036e 6574 00c0 1000 0200 0100 0006 cf00 .net............ >> > 0x0080: 0603 6e73 32c0 4c ..ns2.L >> > This is the only DNS traffic I saw during the attempts. The tcpdumps >> have >> > udp bad checksum but when I disabled TFO in polipo, the UDP where stil= l >> bad >> > checksum but they worked. >> > Really weird. >> > p.s. UPNP still works for port forwarding negotiation as it did in >> 3.6.11-4 >> > I still couldn't get the UPNP/SSDP broadcasts (udp to 239.255.255.250) >> to >> > being forwarded between se00 and sw00/sw10. Last time it worked was >> ~3.3.8. >> > I'm starting not to question why it doesn't work, I'm starting to >> wonder why >> > it did work then ;-) >> > Regards, >> > Maciej >> > On Fri, Jan 4, 2013 at 6:33 PM, Dave Taht wrote: >> >> >> >> On Fri, Jan 4, 2013 at 9:27 AM, Eric Dumazet >> wrote: >> >> > Sorry, could you give us a copy of the panic stack trace ? >> >> >> >> I will get a serial console up on a wndr3800 by sunday. (sorry, just >> >> landed in california, am in disarray) >> >> >> >> The latest dev build of cero for the wndr3800 and wndr3700v2 is at: >> >> >> >> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.7.1-1/ >> >> >> >> -- >> >> Dave T=E4ht >> >> >> >> Fixing bufferbloat with cerowrt: >> >> http://www.teklibre.com/cerowrt/subscribe.html >> >> _______________________________________________ >> >> Cerowrt-devel mailing list >> >> Cerowrt-devel@lists.bufferbloat.net >> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > >> > >> >> >> >> -- >> Dave T=E4ht >> >> Fixing bufferbloat with cerowrt: >> http://www.teklibre.com/cerowrt/subscribe.html >> > > --f46d042fdeb2c6794704d280f389 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Well, I was trying polipo server on cero box and httping from laptop. On= both the boxes I set 3 in tcp_fastopen.

The panic is seen only when server is on cero box.
If I run server on my laptop and httping from cero all TFO connections are = successful.
So I doubt its the only problem is SYN+DATA.

Unfortunately I don't have the serial cable right now, and logread o= r dmesg didn't print any logs before the cero router=A0 restarted.

Attached is the tcpdump capture on lo when client and server both run on= cero box.
HTH!

If you (or anyone) can suggest more diagnostics, I will be glad to provi= de.

On Jan 5, 2013 2:49 AM, "Jerry Chu" &l= t;hkchu@google.com> wrote:
+ycheng


On Fri, Jan 4, 2013 at 1:11 P= M, Dave Taht <dave.taht@gmail.com> wrote:
Hmm. I would lean towards there being an issue with the ne= w (freshly
ported forward to 3.7.1) unaligned checksum code for mips based on
what you say here. Or an offload...

As for the 239.x multicast issue, hmm... separate issue entirely. Probably.= ..

And then there's TFO. I note that in order to use it properly you need<= br> to turn it on in proc. Last I remember that was

echo 3 > /proc/sys/net/ipv4/tcp_fastopen

=
Correct - to enable the normal use of TFO for both client and server. = There are other flags for advanced usage:
=A0/* Bit Flags for sys= ctl_tcp_fastopen */
#define TFO_CLIENT_ENABLE =A0 =A0 =A0 1
#define TFO_SERVER_E= NABLE =A0 =A0 =A0 2
#define TFO_CLIENT_NO_COOKIE =A0 =A04 /* Send= data-in-SYN w/o cookie */

/* Process SYN data but= skip cookie validation */
#define TFO_SERVER_COOKIE_NOT_CHKED =A0 =A0 0x100
/* Accept = SYN data w/o any cookie option */
#define TFO_SERVER_COOKIE_NOT_R= EQD =A0 =A0 =A00x200

/* Force enable TFO on all li= steners, i.e., not requiring the
=A0* TCP_FASTOPEN socket option. SOCKOPT1/2 determine how to set max_q= len.
=A0*/
#define TFO_SERVER_WO_SOCKOPT1 =A00x400
#define TFO_SERVER_WO_SOCKOPT2 =A00x800
/* Always create TF= O child sockets on a TFO listener even when
=A0* cookie/data not present. (For testing purpose!)
=A0*/
#define TFO_SERVER_ALWAYS =A0 =A0 =A0 0x1000

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
However that's an old memory and there is this tcp_fastopen_key file I<= br> don't know anything about yet (this is such bleeding edge stuff!)

... and with tcp_fastopen disabled things should still work right...
so I'm thinking something else is busted in the stack.

I've also observed a dns slowdown in what I've been testing but had= n't
dug into packet dumps. (and was assuming, until now, it was due to me
fiddling with ULAs inside the network) Thanks for digging this deep!

I never said this first attempt at 3.7 for cero was going to be
perfect, but we've entered a new age of subtle problems here.

I strongly suggest nobody else try this dev build as a default gw, and
that the TFO folk ignore the noise for now.

=
SG.

Jerry
=A0

I just got a 3.7.1 box built on x86_64 so as to a/b some captures.
Regrettably I'm short on time through the weekend...

On Fri, Jan 4, 2013 at 12:42 PM, Maciej Soltysiak <maciej@soltysiak.com> wrote: > I am seeing something strange here, with polipo related to TFO but als= o DNS.
> When I just took 3.7.1-1 and set my windows 7 laptop to use gw.home.la= n:8123
> as http proxy it didn't work. What I observed was:
> A) after quite a while polipo's response to browser was 504 Host > www.osnews.com= lookup failed: Timeout
> b) this error in ssh console: Host osnews.com lookup failed: Timeout
> (131072)
> c) Disabling TFO by adding option useTCPFastOpen 'false' to co= nfig 'polipo'
> 'general' works around the problem
> d) Alternatively, you can keep TFO enabled in polipo but change option=
> 'dnsUseGethostbyname' from 'reluctantly' to 'true&= #39; (!)
> This is very weird, because TFO is TCP and the DNS queries fired off b= y
> polipo are UDP:
> root@OpenWrt:/tmp/log# tcpdump -n -v -vv -vvv -x -X -s 1500 -i lo
> 20:21:56.160245 IP (tos 0x0, ttl 64, id 50129, offset 0, flags [DF], p= roto
> UDP (17), length 60)
> 127.0.0.1.47304 > 127.0.0.1.53: [bad udp cksum 0xfe3b -> 0xd17f!= ] 55396+ A?
> www.osnews.com= . (32)
> 0x0000: 4500 003c c3d1 4000 4011 78dd 7f00 0001 E..<..@.@.x..... > 0x0010: 7f00 0001 b8c8 0035 0028 fe3b d864 0100 .......5.(.;.d..
> 0x0020: 0001 0000 0000 0000 0377 7777 066f 736e .........www.osn
> 0x0030: 6577 7303 636f 6d00 0001 0001 ews.com.....
> 20:21:56.160319 IP (tos 0x0, ttl 64, id 50130, offset 0, flags [DF], p= roto
> UDP (17), length 60)
> 127.0.0.1.47304 > 127.0.0.1.53: [bad udp cksum 0xfe3b -> 0xd164!= ] 55396+
> AAAA? www.osnews.c= om. (32)
> 0x0000: 4500 003c c3d2 4000 4011 78dc 7f00 0001 E..<..@.@.x..... > 0x0010: 7f00 0001 b8c8 0035 0028 fe3b d864 0100 .......5.(.;.d..
> 0x0020: 0001 0000 0000 0000 0377 7777 066f 736e .........www.osn
> 0x0030: 6577 7303 636f 6d00 001c 0001 ews.com.....
> 20:21:56.169942 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto= UDP
> (17), length 123)
> 127.0.0.1.53 > 127.0.0.1.47304: [bad udp cksum 0xfe7a -> 0x5f73!= ] 55396 q:
> A? www.osnews.com<= /a>. 1/2/0 www.osnews.c= om. [29m3s] A 74.86.31.159 ns:
> osnews.com. [29m3s= ] NS ns2.swelter.net., osnews.com. [29m3s= ] NS
> ns1.swelter.net. (95)
> 0x0000: 4500 007b 0000 4000 4011 3c70 7f00 0001 E..{..@.@.<p.... > 0x0010: 7f00 0001 0035 b8c8 0067 fe7a d864 8180 .....5...g.z.d..
> 0x0020: 0001 0001 0002 0000 0377 7777 066f 736e .........www.osn
> 0x0030: 6577 7303 636f 6d00 0001 0001 c00c 0001 ews.com.........
> 0x0040: 0001 0000 06cf 0004 4a56 1f9f c010 0002 ........JV......
> 0x0050: 0001 0000 06cf 0011 036e 7332 0773 7765 .........ns2.swe
> 0x0060: 6c74 6572 036e 6574 00c0 1000 0200 0100 lter.net........
> 0x0070: 0006 cf00 0603 6e73 31c0 40 ......ns1.@
> 20:21:56.173901 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto= UDP
> (17), length 135)
> 127.0.0.1.53 > 127.0.0.1.47304: [bad udp cksum 0xfe86 -> 0x8ecb!= ] 55396 q:
> AAAA? www.osnews.c= om. 1/2/0 www.osnew= s.com. [54m44s] AAAA
> 2607:f0d0:1002:62::3 ns: osnews.com. [29m3s] NS ns1.swelter.net.,
> osnews.com. [29m3s= ] NS ns2.swelter.net. (107)
> 0x0000: 4500 0087 0000 4000 4011 3c64 7f00 0001 E.....@.@.<d.... > 0x0010: 7f00 0001 0035 b8c8 0073 fe86 d864 8180 .....5...s...d..
> 0x0020: 0001 0001 0002 0000 0377 7777 066f 736e .........www.osn
> 0x0030: 6577 7303 636f 6d00 001c 0001 c00c 001c ews.com.........
> 0x0040: 0001 0000 0cd4 0010 2607 f0d0 1002 0062 ........&......b > 0x0050: 0000 0000 0000 0003 c010 0002 0001 0000 ................
> 0x0060: 06cf 0011 036e 7331 0773 7765 6c74 6572 .....ns1.swelter
> 0x0070: 036e 6574 00c0 1000 0200 0100 0006 cf00 .net............
> 0x0080: 0603 6e73 32c0 4c ..ns2.L
> This is the only DNS traffic I saw during the attempts. The tcpdumps h= ave
> udp bad checksum but when I disabled TFO in polipo, the UDP where stil= l bad
> checksum but they worked.
> Really weird.
> p.s. UPNP still works for port forwarding negotiation as it did in 3.6= .11-4
> I still couldn't get the UPNP/SSDP broadcasts (udp to 239.255.255.= 250) to
> being forwarded between se00 and sw00/sw10. Last time it worked was ~3= .3.8.
> I'm starting not to question why it doesn't work, I'm star= ting to wonder why
> it did work then ;-)
> Regards,
> Maciej
> On Fri, Jan 4, 2013 at 6:33 PM, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> On Fri, Jan 4, 2013 at 9:27 AM, Eric Dumazet <edumazet@google.com> wrote:<= br> >> > Sorry, could you give us a copy of the panic stack trace ? >>
>> I will get a serial console up on a wndr3800 by sunday. (sorry, ju= st
>> landed in california, am in disarray)
>>
>> The latest dev build of cero for the wndr3800 and wndr3700v2 is at= :
>>
>> http://snapon.lab.bufferbloat.net/~cero2/cerowrt= /wndr/3.7.1-1/
>>
>> --
>> Dave T=E4ht
>>
>> Fixing bufferbloat with cerowrt:
>> http://www.teklibre.com/cerowrt/subscribe.html
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >
>



--
Dave T=E4ht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscrib= e.html

--f46d042fdeb2c6794704d280f389-- --f46d042fdeb2c6794c04d280f38b Content-Type: text/plain; charset=US-ASCII; name="lo_capture.txt" Content-Disposition: attachment; filename="lo_capture.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: 1423284948845985792-1 cm9vdEBPcGVuV3J0On4jIGh0dHBpbmcgLUYgLWcgaHR0cDovLzEyNy4wLjAuMTo4MTIzClBJTkcg MTI3LjAuMC4xOjgxMjMgKGh0dHA6Ly8xMjcuMC4wLjE6ODEyMyk6CjE2OjM2OjM2LjAzMzQ2NiBJ UCBsb2NhbGhvc3QuMzk0NDMgPiBsb2NhbGhvc3QuODEyMzogRmxhZ3MgW1NFV10sIHNlcSAyOTQ2 Mjg4MzQxLCB3aW4gNDM2OTAsIG9wdGlvbnMgW21zcyA2NTQ5NSxzYWNrT0ssVFMgdmFsIDQyOTQ5 NjQ4OTMgZWNyIDAsbm9wLHdzY2FsZSA2LFVua25vd24gT3B0aW9uIDI1NGY5ODldLCBsZW5ndGgg MCAtLT4gU1lOICsgQ29vY2tpZSBhbmQgbm8gRGF0YS4KY29ubmVjdGVkIHRvIDEyNy4wLjAuMTo4 MTIzICgxODMgYnl0ZXMpLCBzZXE9MCB0aW1lPTMuMTUgbXMgCjE2OjM2OjM2LjAzMzU4NCBJUCBs b2NhbGhvc3QuODEyMyA+IGxvY2FsaG9zdC4zOTQ0MzogRmxhZ3MgW1MuRV0sIHNlcSA2NTQ5NDE4 NzYsIGFjayAyOTQ2Mjg4MzQyLCB3aW4gNDM2OTAsIG9wdGlvbnMgW21zcyA2NTQ5NSxzYWNrT0ss VFMgdmFsIDQyOTQ5NjQ4OTMgZWNyIDQyOTQ5NjQ4OTMsbm9wLHdzY2FsZSA2LFVua25vd24gT3B0 aW9uIDI1NGY5ODlkZjA4NzIxNDkzOTczMmVmXSwgbGVuZ3RoIDAgIC0tPiBTWU4rQUNLK0Nvb2tp ZQoxNjozNjozNi4wMzM2MzggSVAgbG9jYWxob3N0LjM5NDQzID4gbG9jYWxob3N0LjgxMjM6IEZs YWdzIFsuXSwgYWNrIDEsIHdpbiA2ODMsIG9wdGlvbnMgW25vcCxub3AsVFMgdmFsIDQyOTQ5NjQ4 OTMgZWNyIDQyOTQ5NjQ4OTNdLCBsZW5ndGggMAoxNjozNjozNi4wMzQ5NzEgSVAgbG9jYWxob3N0 LjM5NDQzID4gbG9jYWxob3N0LjgxMjM6IEZsYWdzIFtQLl0sIHNlcSAxOjY1LCBhY2sgMSwgd2lu IDY4Mywgb3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgNDI5NDk2NDg5NCBlY3IgNDI5NDk2NDg5M10s IGxlbmd0aCA2NCAtLT4gSFRUUCBSZXF1ZXN0IEhFQUQKMTY6MzY6MzYuMDM1MTEyIElQIGxvY2Fs aG9zdC44MTIzID4gbG9jYWxob3N0LjM5NDQzOiBGbGFncyBbLl0sIGFjayA2NSwgd2luIDY4Mywg b3B0aW9ucyBbbm9wLG5vcCxUUyB2YWwgNDI5NDk2NDg5NCBlY3IgNDI5NDk2NDg5NF0sIGxlbmd0 aCAwCjE2OjM2OjM2LjAzNTgwOCBJUCBsb2NhbGhvc3QuODEyMyA+IGxvY2FsaG9zdC4zOTQ0Mzog RmxhZ3MgW1AuXSwgc2VxIDE6MTg0LCBhY2sgNjUsIHdpbiA2ODMsIG9wdGlvbnMgW25vcCxub3As VFMgdmFsIDQyOTQ5NjQ4OTQgZWNyIDQyOTQ5NjQ4OTRdLCBsZW5ndGggMTgzICAtLT4gSFRUUCBS ZXNwb25zZQoxNjozNjozNi4wMzU5NjUgSVAgbG9jYWxob3N0LjgxMjMgPiBsb2NhbGhvc3QuMzk0 NDM6IEZsYWdzIFtGLl0sIHNlcSAxODQsIGFjayA2NSwgd2luIDY4Mywgb3B0aW9ucyBbbm9wLG5v cCxUUyB2YWwgNDI5NDk2NDg5NCBlY3IgNDI5NDk2NDg5NF0sIGxlbmd0aCAwCjE2OjM2OjM2LjAz NjA4MiBJUCBsb2NhbGhvc3QuMzk0NDMgPiBsb2NhbGhvc3QuODEyMzogRmxhZ3MgWy5dLCBhY2sg MTg0LCB3aW4gNzAwLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCA0Mjk0OTY0ODk0IGVjciA0Mjk0 OTY0ODk0XSwgbGVuZ3RoIDAKMTY6MzY6MzYuMDM2MzUwIElQIGxvY2FsaG9zdC4zOTQ0MyA+IGxv Y2FsaG9zdC44MTIzOiBGbGFncyBbRi5dLCBzZXEgNjUsIGFjayAxODUsIHdpbiA3MDAsIG9wdGlv bnMgW25vcCxub3AsVFMgdmFsIDQyOTQ5NjQ4OTQgZWNyIDQyOTQ5NjQ4OTRdLCBsZW5ndGggMAox NjozNjozNi4wMzY0NjIgSVAgbG9jYWxob3N0LjgxMjMgPiBsb2NhbGhvc3QuMzk0NDM6IEZsYWdz IFsuXSwgYWNrIDY2LCB3aW4gNjgzLCBvcHRpb25zIFtub3Asbm9wLFRTIHZhbCA0Mjk0OTY0ODk0 IGVjciA0Mjk0OTY0ODk0XSwgbGVuZ3RoIDAgIC0tPiBDb25uZWN0aW9uIENvbXBsZXRlcwoKIyMj IE5vIHBhY2tldHMgc2VlbiBsYXRlciAtIFByb2JhYmx5IFNZTitEYXRhIENyYXNoZWQgdGhlIGJv eCAjIyMK --f46d042fdeb2c6794c04d280f38b--