From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey.Brodkin@synopsys.com (Alexey Brodkin) Date: Tue, 16 Aug 2016 05:57:28 +0000 Subject: [LEDE-DEV] DHCP via bridge in case of IPv4 In-Reply-To: <1468217682.5588.4.camel@synopsys.com> References: <1468053400.5007.5.camel@synopsys.com> <1468065830.5007.10.camel@synopsys.com> <87shviklio.fsf@husum.klickitat.com> <1468217682.5588.4.camel@synopsys.com> List-ID: Message-ID: <1471326942.3980.3.camel@synopsys.com> To: linux-snps-arc@lists.infradead.org Hello, On Mon, 2016-07-11@06:15 +0000, Alexey Brodkin wrote: > Hi Russel, > > On Sun, 2016-07-10@00:19 -0700, Russell Senior wrote: > >? > > > > > > > "Alexey" == Alexey Brodkin writes: > > Alexey> Hi Aaron, > > Alexey> On Sat, 2016-07-09@07:47 -0400, Aaron Z wrote: > > >? > > > > On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin > > > > wrote: > > > > >? > > > > > Hello, > > > > > > > > > > I was playing with quite simple bridged setup on different boards > > > > with > very recent kernels (4.6.3 as of this writing) and found one > > > > interesting > behavior that I cannot yet understand and googling > > > > din't help here as well. > > > > >? > > > > > My setup is pretty simple: > > > > > -------------???????------------------???????------------------------- > > > > >? > > > > > > HOST??????|???????| "Dumb AP"??????|???????| Wireless > > > > client???????| > > with DHCP |<----->(eth0)?????(wlan0)<----->| > > > > attempting to?????????| > > server????|???????|????\ br0 > > > > /?????|???????| get settings via DHCP | > > > > > -------------???????------------------???????------------------------- > > > > > * HOST is my laptop with DHCP server that works for sure.??> * > > > > "Dumb AP" is a separate board (I tried ARM-based Wandboard and > > > > ARC-based > ? AXS10x boards but results are exactly the same) with > > > > wired (eth0) and wireless > ? (wlan0) network controllers bridged > > > > together (br0). That "br0" bridge flawlessly > ? gets its settings > > > > from DHCP server on host.??> * Wireless client could be either a > > > > smatrphone or another laptop etc but > ? what's important it should > > > > be configured to get network settings by DHCP as well. > > > > > > > > > > So what happens "br0" always gets network settings from DHCP server > > > > on HOST.??> That's fine. But wireless client only reliably gets > > > > settings from DHCP server > if IPv6 is enabled on "Dumb AP" board. If > > > > IPv6 is disabled I may see that > wireless client sends "DHCP > > > > Discover" then server replies with "DHCP Offer" but > that offer > > > > never reaches wireless client. > > > > > > > > Do you have WDS enabled? If not, DHCP has issues in that scenario: > > > > https://wiki.openwrt.org/doc/howto/clientmode > > If the Dumb AP's wireless interface is in ap-mode, then this shouldn't > > be an issue.??It's only client-mode interfaces that have trouble with bridging. > > > > I'd suggest running tcpdump on the Dumb AP's wireless interface and the > > client's wireless interface and see which of them sees the various parts > > of the DHCP handshake. > > So I did but for DHCP server and wireless client (had no tcpdump on Dump AP > at the moment). > > That's what I see on the server: > ----------------------------->8------------------------------- > No. Time????????Source?????Destination??????Protocol Length Info > ?3 0.151181000??0.0.0.0????255.255.255.255??DHCP?????342????DHCP Discover - Transaction ID 0x31dc321f > 11 2.760796000??10.42.0.1??10.42.0.13???????DHCP?????342????DHCP Offer????- Transaction ID 0x31dc321f > 14 5.220985000??0.0.0.0????255.255.255.255??DHCP?????342????DHCP Discover - Transaction ID 0x31dc321f > 15 5.221150000??10.42.0.1??10.42.0.13???????DHCP?????342????DHCP Offer????- Transaction ID 0x31dc321f > 23 15.649835000 0.0.0.0????255.255.255.255??DHCP?????342????DHCP Discover - Transaction ID 0x31dc321f > 24 15.650017000 10.42.0.1??10.42.0.13???????DHCP?????342????DHCP Offer????- Transaction ID 0x31dc321f > 32 25.648589000 0.0.0.0????255.255.255.255??DHCP?????342????DHCP Discover - Transaction ID 0x31dc321f > 33 25.648758000 10.42.0.1??10.42.0.13???????DHCP?????342????DHCP Offer????- Transaction ID 0x31dc321f > 43 35.864567000 0.0.0.0????255.255.255.255??DHCP?????342????DHCP Discover - Transaction ID 0x31dc321f > 48 38.832837000 10.42.0.1??10.42.0.13???????DHCP?????342????DHCP Offer????- Transaction ID 0x31dc321f > ----------------------------->8------------------------------- > > That's on the wireless client: > ----------------------------->8------------------------------- > No.??Time???????????Source???Destination??????Protocol Length Info > 1171 94.192971000???0.0.0.0??255.255.255.255??DHCP?????342????DHCP Discover - Transaction ID 0x31dc321f > 1182 99.263686000???0.0.0.0??255.255.255.255??DHCP?????342????DHCP Discover - Transaction ID 0x31dc321f > 1185 109.692642000??0.0.0.0??255.255.255.255??DHCP?????342????DHCP Discover - Transaction ID 0x31dc321f > 1186 119.691474000??0.0.0.0??255.255.255.255??DHCP?????342????DHCP Discover - Transaction ID 0x31dc321f > 1190 129.907507000??0.0.0.0??255.255.255.255??DHCP?????342????DHCP Discover - Transaction ID 0x31dc321f > ----------------------------->8------------------------------- > > I'll try to capture data from Dumb AP sometime soon and will reply to the thread. So finally after quite some time I figured out what happens in my setup. Basically it all boils down to the fact that DW GMAC doesn't enter promiscuous mode when bridge gets created. To be more precise GMAC's MAC filter fail to enter promiscuous mode and so packets from DHCP server sent to Wi-Fi clien are discarded by GMAC - that's why I cannot see those packets in tcpdump output - CPU never gets any information about them. I noticed that problem only happens if Ethernet PHY (in my case this is DP83865) doesn't have link established. I.e. either: ?1) Cable is disconnected ?2) PHY is still negotiation link mode Once PHY got link established GMAC happily enters promisq mode and all works as expected. Unfortunately I cannot figure out why GMAC behaves that way. As per GMAC's databook the only reason for it to not react on a register being written is missing input clock but there's no reason for the clock to be missing and I don't seem to have a way to check if there's a problem with clock or not. -Alexey From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753073AbcHPF5k (ORCPT ); Tue, 16 Aug 2016 01:57:40 -0400 Received: from us01smtprelay-2.synopsys.com ([198.182.47.9]:37805 "EHLO smtprelay.synopsys.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750940AbcHPF5i (ORCPT ); Tue, 16 Aug 2016 01:57:38 -0400 From: Alexey Brodkin To: "netdev@vger.kernel.org" CC: "russell@personaltelco.net" , "lede-dev@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "davem@davemloft.net" , "aczlan+ledev@gmail.com" , "linux-snps-arc@lists.infradead.org" Subject: Re: [LEDE-DEV] DHCP via bridge in case of IPv4 Thread-Topic: [LEDE-DEV] DHCP via bridge in case of IPv4 Thread-Index: AQHR2nttP3SlCVXWzEuA1iaa0r9rVKASoIgAgDiOnwA= Date: Tue, 16 Aug 2016 05:57:28 +0000 Message-ID: <1471326942.3980.3.camel@synopsys.com> References: <1468053400.5007.5.camel@synopsys.com> <1468065830.5007.10.camel@synopsys.com> <87shviklio.fsf@husum.klickitat.com> <1468217682.5588.4.camel@synopsys.com> In-Reply-To: <1468217682.5588.4.camel@synopsys.com> Accept-Language: en-US, ru-RU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.121.14.110] Content-Type: text/plain; charset="utf-8" Content-ID: <5F4F46A5F2421345866798C3CC893D0D@internal.synopsys.com> MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u7G5vqVP006935 Hello, On Mon, 2016-07-11 at 06:15 +0000, Alexey Brodkin wrote: > Hi Russel, > > On Sun, 2016-07-10 at 00:19 -0700, Russell Senior wrote: > >  > > > > > > > "Alexey" == Alexey Brodkin writes: > > Alexey> Hi Aaron, > > Alexey> On Sat, 2016-07-09 at 07:47 -0400, Aaron Z wrote: > > >  > > > > On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin > > > > wrote: > > > > >  > > > > > Hello, > > > > > > > > > > I was playing with quite simple bridged setup on different boards > > > > with > very recent kernels (4.6.3 as of this writing) and found one > > > > interesting > behavior that I cannot yet understand and googling > > > > din't help here as well. > > > > >  > > > > > My setup is pretty simple: > > > > > -------------       ------------------       ------------------------- > > > > >  > > > > > > HOST      |       | "Dumb AP"      |       | Wireless > > > > client       | > > with DHCP |<----->(eth0)     (wlan0)<----->| > > > > attempting to         | > > server    |       |    \ br0 > > > > /     |       | get settings via DHCP | > > > > > -------------       ------------------       ------------------------- > > > > > * HOST is my laptop with DHCP server that works for sure.  > * > > > > "Dumb AP" is a separate board (I tried ARM-based Wandboard and > > > > ARC-based >   AXS10x boards but results are exactly the same) with > > > > wired (eth0) and wireless >   (wlan0) network controllers bridged > > > > together (br0). That "br0" bridge flawlessly >   gets its settings > > > > from DHCP server on host.  > * Wireless client could be either a > > > > smatrphone or another laptop etc but >   what's important it should > > > > be configured to get network settings by DHCP as well. > > > > > > > > > > So what happens "br0" always gets network settings from DHCP server > > > > on HOST.  > That's fine. But wireless client only reliably gets > > > > settings from DHCP server > if IPv6 is enabled on "Dumb AP" board. If > > > > IPv6 is disabled I may see that > wireless client sends "DHCP > > > > Discover" then server replies with "DHCP Offer" but > that offer > > > > never reaches wireless client. > > > > > > > > Do you have WDS enabled? If not, DHCP has issues in that scenario: > > > > https://wiki.openwrt.org/doc/howto/clientmode > > If the Dumb AP's wireless interface is in ap-mode, then this shouldn't > > be an issue.  It's only client-mode interfaces that have trouble with bridging. > > > > I'd suggest running tcpdump on the Dumb AP's wireless interface and the > > client's wireless interface and see which of them sees the various parts > > of the DHCP handshake. > > So I did but for DHCP server and wireless client (had no tcpdump on Dump AP > at the moment). > > That's what I see on the server: > ----------------------------->8------------------------------- > No. Time        Source     Destination      Protocol Length Info >  3 0.151181000  0.0.0.0    255.255.255.255  DHCP     342    DHCP Discover - Transaction ID 0x31dc321f > 11 2.760796000  10.42.0.1  10.42.0.13       DHCP     342    DHCP Offer    - Transaction ID 0x31dc321f > 14 5.220985000  0.0.0.0    255.255.255.255  DHCP     342    DHCP Discover - Transaction ID 0x31dc321f > 15 5.221150000  10.42.0.1  10.42.0.13       DHCP     342    DHCP Offer    - Transaction ID 0x31dc321f > 23 15.649835000 0.0.0.0    255.255.255.255  DHCP     342    DHCP Discover - Transaction ID 0x31dc321f > 24 15.650017000 10.42.0.1  10.42.0.13       DHCP     342    DHCP Offer    - Transaction ID 0x31dc321f > 32 25.648589000 0.0.0.0    255.255.255.255  DHCP     342    DHCP Discover - Transaction ID 0x31dc321f > 33 25.648758000 10.42.0.1  10.42.0.13       DHCP     342    DHCP Offer    - Transaction ID 0x31dc321f > 43 35.864567000 0.0.0.0    255.255.255.255  DHCP     342    DHCP Discover - Transaction ID 0x31dc321f > 48 38.832837000 10.42.0.1  10.42.0.13       DHCP     342    DHCP Offer    - Transaction ID 0x31dc321f > ----------------------------->8------------------------------- > > That's on the wireless client: > ----------------------------->8------------------------------- > No.  Time           Source   Destination      Protocol Length Info > 1171 94.192971000   0.0.0.0  255.255.255.255  DHCP     342    DHCP Discover - Transaction ID 0x31dc321f > 1182 99.263686000   0.0.0.0  255.255.255.255  DHCP     342    DHCP Discover - Transaction ID 0x31dc321f > 1185 109.692642000  0.0.0.0  255.255.255.255  DHCP     342    DHCP Discover - Transaction ID 0x31dc321f > 1186 119.691474000  0.0.0.0  255.255.255.255  DHCP     342    DHCP Discover - Transaction ID 0x31dc321f > 1190 129.907507000  0.0.0.0  255.255.255.255  DHCP     342    DHCP Discover - Transaction ID 0x31dc321f > ----------------------------->8------------------------------- > > I'll try to capture data from Dumb AP sometime soon and will reply to the thread. So finally after quite some time I figured out what happens in my setup. Basically it all boils down to the fact that DW GMAC doesn't enter promiscuous mode when bridge gets created. To be more precise GMAC's MAC filter fail to enter promiscuous mode and so packets from DHCP server sent to Wi-Fi clien are discarded by GMAC - that's why I cannot see those packets in tcpdump output - CPU never gets any information about them. I noticed that problem only happens if Ethernet PHY (in my case this is DP83865) doesn't have link established. I.e. either:  1) Cable is disconnected  2) PHY is still negotiation link mode Once PHY got link established GMAC happily enters promisq mode and all works as expected. Unfortunately I cannot figure out why GMAC behaves that way. As per GMAC's databook the only reason for it to not react on a register being written is missing input clock but there's no reason for the clock to be missing and I don't seem to have a way to check if there's a problem with clock or not. -Alexey From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Brodkin Subject: Re: [LEDE-DEV] DHCP via bridge in case of IPv4 Date: Tue, 16 Aug 2016 05:57:28 +0000 Message-ID: <1471326942.3980.3.camel@synopsys.com> References: <1468053400.5007.5.camel@synopsys.com> <1468065830.5007.10.camel@synopsys.com> <87shviklio.fsf@husum.klickitat.com> <1468217682.5588.4.camel@synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Cc: "lede-dev@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "russell@personaltelco.net" , "aczlan+ledev@gmail.com" , "linux-snps-arc@lists.infradead.org" , "davem@davemloft.net" To: "netdev@vger.kernel.org" Return-path: In-Reply-To: <1468217682.5588.4.camel@synopsys.com> Content-Language: en-US Content-ID: <5F4F46A5F2421345866798C3CC893D0D@internal.synopsys.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+gla-linux-snps-arc=m.gmane.org@lists.infradead.org List-Id: netdev.vger.kernel.org SGVsbG8sDQoNCk9uIE1vbiwgMjAxNi0wNy0xMSBhdCAwNjoxNSArMDAwMCwgQWxleGV5IEJyb2Rr aW4gd3JvdGU6DQo+IEhpIFJ1c3NlbCwNCj4gDQo+IE9uIFN1biwgMjAxNi0wNy0xMCBhdCAwMDox OSAtMDcwMCwgUnVzc2VsbCBTZW5pb3Igd3JvdGU6DQo+ID7CoA0KPiA+ID4gPiA+ID4gPiAiQWxl eGV5IiA9PSBBbGV4ZXkgQnJvZGtpbiA8QWxleGV5LkJyb2RraW5Ac3lub3BzeXMuY29tPiB3cml0 ZXM6DQo+ID4gQWxleGV5PiBIaSBBYXJvbiwNCj4gPiBBbGV4ZXk+IE9uIFNhdCwgMjAxNi0wNy0w OSBhdCAwNzo0NyAtMDQwMCwgQWFyb24gWiB3cm90ZToNCj4gPiA+wqANCj4gPiA+ID4gT24gU2F0 LCBKdWwgOSwgMjAxNiBhdCA0OjM3IEFNLCBBbGV4ZXkgQnJvZGtpbg0KPiA+ID4gPiA8QWxleGV5 LkJyb2RraW5Ac3lub3BzeXMuY29tPiB3cm90ZToNCj4gPiA+ID4gPsKgDQo+ID4gPiA+ID4gSGVs bG8sDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gSSB3YXMgcGxheWluZyB3aXRoIHF1aXRlIHNpbXBs ZSBicmlkZ2VkIHNldHVwIG9uIGRpZmZlcmVudCBib2FyZHMNCj4gPiA+ID4gd2l0aCA+IHZlcnkg cmVjZW50IGtlcm5lbHMgKDQuNi4zIGFzIG9mIHRoaXMgd3JpdGluZykgYW5kIGZvdW5kIG9uZQ0K PiA+ID4gPiBpbnRlcmVzdGluZyA+IGJlaGF2aW9yIHRoYXQgSSBjYW5ub3QgeWV0IHVuZGVyc3Rh bmQgYW5kIGdvb2dsaW5nDQo+ID4gPiA+IGRpbid0IGhlbHAgaGVyZSBhcyB3ZWxsLg0KPiA+ID4g PiA+wqANCj4gPiA+ID4gPiBNeSBzZXR1cCBpcyBwcmV0dHkgc2ltcGxlOiA+DQo+ID4gPiA+IC0t LS0tLS0tLS0tLS3CoMKgwqDCoMKgwqDCoC0tLS0tLS0tLS0tLS0tLS0tLcKgwqDCoMKgwqDCoMKg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gPiA+wqANCj4gPiA+ID4gPiA+IEhPU1TC oMKgwqDCoMKgwqB8wqDCoMKgwqDCoMKgwqB8ICJEdW1iIEFQIsKgwqDCoMKgwqDCoHzCoMKgwqDC oMKgwqDCoHwgV2lyZWxlc3MNCj4gPiA+ID4gY2xpZW50wqDCoMKgwqDCoMKgwqB8ID4gPiB3aXRo IERIQ1AgfDwtLS0tLT4oZXRoMCnCoMKgwqDCoMKgKHdsYW4wKTwtLS0tLT58DQo+ID4gPiA+IGF0 dGVtcHRpbmcgdG/CoMKgwqDCoMKgwqDCoMKgwqB8ID4gPiBzZXJ2ZXLCoMKgwqDCoHzCoMKgwqDC oMKgwqDCoHzCoMKgwqDCoFwgYnIwDQo+ID4gPiA+IC/CoMKgwqDCoMKgfMKgwqDCoMKgwqDCoMKg fCBnZXQgc2V0dGluZ3MgdmlhIERIQ1AgfCA+DQo+ID4gPiA+IC0tLS0tLS0tLS0tLS3CoMKgwqDC oMKgwqDCoC0tLS0tLS0tLS0tLS0tLS0tLcKgwqDCoMKgwqDCoMKgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiA+ID4gPiA+ICogSE9TVCBpcyBteSBsYXB0b3Agd2l0aCBESENQIHNlcnZlciB0 aGF0IHdvcmtzIGZvciBzdXJlLsKgwqA+ICoNCj4gPiA+ID4gIkR1bWIgQVAiIGlzIGEgc2VwYXJh dGUgYm9hcmQgKEkgdHJpZWQgQVJNLWJhc2VkIFdhbmRib2FyZCBhbmQNCj4gPiA+ID4gQVJDLWJh c2VkID4gwqAgQVhTMTB4IGJvYXJkcyBidXQgcmVzdWx0cyBhcmUgZXhhY3RseSB0aGUgc2FtZSkg d2l0aA0KPiA+ID4gPiB3aXJlZCAoZXRoMCkgYW5kIHdpcmVsZXNzID4gwqAgKHdsYW4wKSBuZXR3 b3JrIGNvbnRyb2xsZXJzIGJyaWRnZWQNCj4gPiA+ID4gdG9nZXRoZXIgKGJyMCkuIFRoYXQgImJy MCIgYnJpZGdlIGZsYXdsZXNzbHkgPiDCoCBnZXRzIGl0cyBzZXR0aW5ncw0KPiA+ID4gPiBmcm9t IERIQ1Agc2VydmVyIG9uIGhvc3QuwqDCoD4gKiBXaXJlbGVzcyBjbGllbnQgY291bGQgYmUgZWl0 aGVyIGENCj4gPiA+ID4gc21hdHJwaG9uZSBvciBhbm90aGVyIGxhcHRvcCBldGMgYnV0ID4gwqAg d2hhdCdzIGltcG9ydGFudCBpdCBzaG91bGQNCj4gPiA+ID4gYmUgY29uZmlndXJlZCB0byBnZXQg bmV0d29yayBzZXR0aW5ncyBieSBESENQIGFzIHdlbGwuDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4g U28gd2hhdCBoYXBwZW5zICJicjAiIGFsd2F5cyBnZXRzIG5ldHdvcmsgc2V0dGluZ3MgZnJvbSBE SENQIHNlcnZlcg0KPiA+ID4gPiBvbiBIT1NULsKgwqA+IFRoYXQncyBmaW5lLiBCdXQgd2lyZWxl c3MgY2xpZW50IG9ubHkgcmVsaWFibHkgZ2V0cw0KPiA+ID4gPiBzZXR0aW5ncyBmcm9tIERIQ1Ag c2VydmVyID4gaWYgSVB2NiBpcyBlbmFibGVkIG9uICJEdW1iIEFQIiBib2FyZC4gSWYNCj4gPiA+ ID4gSVB2NiBpcyBkaXNhYmxlZCBJIG1heSBzZWUgdGhhdCA+IHdpcmVsZXNzIGNsaWVudCBzZW5k cyAiREhDUA0KPiA+ID4gPiBEaXNjb3ZlciIgdGhlbiBzZXJ2ZXIgcmVwbGllcyB3aXRoICJESENQ IE9mZmVyIiBidXQgPiB0aGF0IG9mZmVyDQo+ID4gPiA+IG5ldmVyIHJlYWNoZXMgd2lyZWxlc3Mg Y2xpZW50Lg0KPiA+ID4gPiANCj4gPiA+ID4gRG8geW91IGhhdmUgV0RTIGVuYWJsZWQ/IElmIG5v dCwgREhDUCBoYXMgaXNzdWVzIGluIHRoYXQgc2NlbmFyaW86DQo+ID4gPiA+IGh0dHBzOi8vd2lr aS5vcGVud3J0Lm9yZy9kb2MvaG93dG8vY2xpZW50bW9kZQ0KPiA+IElmIHRoZSBEdW1iIEFQJ3Mg d2lyZWxlc3MgaW50ZXJmYWNlIGlzIGluIGFwLW1vZGUsIHRoZW4gdGhpcyBzaG91bGRuJ3QNCj4g PiBiZSBhbiBpc3N1ZS7CoMKgSXQncyBvbmx5IGNsaWVudC1tb2RlIGludGVyZmFjZXMgdGhhdCBo YXZlIHRyb3VibGUgd2l0aCBicmlkZ2luZy4NCj4gPiANCj4gPiBJJ2Qgc3VnZ2VzdCBydW5uaW5n IHRjcGR1bXAgb24gdGhlIER1bWIgQVAncyB3aXJlbGVzcyBpbnRlcmZhY2UgYW5kIHRoZQ0KPiA+ IGNsaWVudCdzIHdpcmVsZXNzIGludGVyZmFjZSBhbmQgc2VlIHdoaWNoIG9mIHRoZW0gc2VlcyB0 aGUgdmFyaW91cyBwYXJ0cw0KPiA+IG9mIHRoZSBESENQIGhhbmRzaGFrZS4NCj4gDQo+IFNvIEkg ZGlkIGJ1dCBmb3IgREhDUCBzZXJ2ZXIgYW5kIHdpcmVsZXNzIGNsaWVudCAoaGFkIG5vIHRjcGR1 bXAgb24gRHVtcCBBUA0KPiBhdCB0aGUgbW9tZW50KS4NCj4gDQo+IFRoYXQncyB3aGF0IEkgc2Vl IG9uIHRoZSBzZXJ2ZXI6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPjgtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IE5vLiBUaW1lwqDCoMKgwqDCoMKgwqDCoFNvdXJj ZcKgwqDCoMKgwqBEZXN0aW5hdGlvbsKgwqDCoMKgwqDCoFByb3RvY29sIExlbmd0aCBJbmZvDQo+ IMKgMyAwLjE1MTE4MTAwMMKgwqAwLjAuMC4wwqDCoMKgwqAyNTUuMjU1LjI1NS4yNTXCoMKgREhD UMKgwqDCoMKgwqAzNDLCoMKgwqDCoERIQ1AgRGlzY292ZXIgLSBUcmFuc2FjdGlvbiBJRCAweDMx ZGMzMjFmDQo+IDExIDIuNzYwNzk2MDAwwqDCoDEwLjQyLjAuMcKgwqAxMC40Mi4wLjEzwqDCoMKg wqDCoMKgwqBESENQwqDCoMKgwqDCoDM0MsKgwqDCoMKgREhDUCBPZmZlcsKgwqDCoMKgLSBUcmFu c2FjdGlvbiBJRCAweDMxZGMzMjFmDQo+IDE0IDUuMjIwOTg1MDAwwqDCoDAuMC4wLjDCoMKgwqDC oDI1NS4yNTUuMjU1LjI1NcKgwqBESENQwqDCoMKgwqDCoDM0MsKgwqDCoMKgREhDUCBEaXNjb3Zl ciAtIFRyYW5zYWN0aW9uIElEIDB4MzFkYzMyMWYNCj4gMTUgNS4yMjExNTAwMDDCoMKgMTAuNDIu MC4xwqDCoDEwLjQyLjAuMTPCoMKgwqDCoMKgwqDCoERIQ1DCoMKgwqDCoMKgMzQywqDCoMKgwqBE SENQIE9mZmVywqDCoMKgwqAtIFRyYW5zYWN0aW9uIElEIDB4MzFkYzMyMWYNCj4gMjMgMTUuNjQ5 ODM1MDAwIDAuMC4wLjDCoMKgwqDCoDI1NS4yNTUuMjU1LjI1NcKgwqBESENQwqDCoMKgwqDCoDM0 MsKgwqDCoMKgREhDUCBEaXNjb3ZlciAtIFRyYW5zYWN0aW9uIElEIDB4MzFkYzMyMWYNCj4gMjQg MTUuNjUwMDE3MDAwIDEwLjQyLjAuMcKgwqAxMC40Mi4wLjEzwqDCoMKgwqDCoMKgwqBESENQwqDC oMKgwqDCoDM0MsKgwqDCoMKgREhDUCBPZmZlcsKgwqDCoMKgLSBUcmFuc2FjdGlvbiBJRCAweDMx ZGMzMjFmDQo+IDMyIDI1LjY0ODU4OTAwMCAwLjAuMC4wwqDCoMKgwqAyNTUuMjU1LjI1NS4yNTXC oMKgREhDUMKgwqDCoMKgwqAzNDLCoMKgwqDCoERIQ1AgRGlzY292ZXIgLSBUcmFuc2FjdGlvbiBJ RCAweDMxZGMzMjFmDQo+IDMzIDI1LjY0ODc1ODAwMCAxMC40Mi4wLjHCoMKgMTAuNDIuMC4xM8Kg wqDCoMKgwqDCoMKgREhDUMKgwqDCoMKgwqAzNDLCoMKgwqDCoERIQ1AgT2ZmZXLCoMKgwqDCoC0g VHJhbnNhY3Rpb24gSUQgMHgzMWRjMzIxZg0KPiA0MyAzNS44NjQ1NjcwMDAgMC4wLjAuMMKgwqDC oMKgMjU1LjI1NS4yNTUuMjU1wqDCoERIQ1DCoMKgwqDCoMKgMzQywqDCoMKgwqBESENQIERpc2Nv dmVyIC0gVHJhbnNhY3Rpb24gSUQgMHgzMWRjMzIxZg0KPiA0OCAzOC44MzI4MzcwMDAgMTAuNDIu MC4xwqDCoDEwLjQyLjAuMTPCoMKgwqDCoMKgwqDCoERIQ1DCoMKgwqDCoMKgMzQywqDCoMKgwqBE SENQIE9mZmVywqDCoMKgwqAtIFRyYW5zYWN0aW9uIElEIDB4MzFkYzMyMWYNCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0+OC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g DQo+IFRoYXQncyBvbiB0aGUgd2lyZWxlc3MgY2xpZW50Og0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLT44LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBOby7CoMKgVGlt ZcKgwqDCoMKgwqDCoMKgwqDCoMKgwqBTb3VyY2XCoMKgwqBEZXN0aW5hdGlvbsKgwqDCoMKgwqDC oFByb3RvY29sIExlbmd0aCBJbmZvDQo+IDExNzEgOTQuMTkyOTcxMDAwwqDCoMKgMC4wLjAuMMKg wqAyNTUuMjU1LjI1NS4yNTXCoMKgREhDUMKgwqDCoMKgwqAzNDLCoMKgwqDCoERIQ1AgRGlzY292 ZXIgLSBUcmFuc2FjdGlvbiBJRCAweDMxZGMzMjFmDQo+IDExODIgOTkuMjYzNjg2MDAwwqDCoMKg MC4wLjAuMMKgwqAyNTUuMjU1LjI1NS4yNTXCoMKgREhDUMKgwqDCoMKgwqAzNDLCoMKgwqDCoERI Q1AgRGlzY292ZXIgLSBUcmFuc2FjdGlvbiBJRCAweDMxZGMzMjFmDQo+IDExODUgMTA5LjY5MjY0 MjAwMMKgwqAwLjAuMC4wwqDCoDI1NS4yNTUuMjU1LjI1NcKgwqBESENQwqDCoMKgwqDCoDM0MsKg wqDCoMKgREhDUCBEaXNjb3ZlciAtIFRyYW5zYWN0aW9uIElEIDB4MzFkYzMyMWYNCj4gMTE4NiAx MTkuNjkxNDc0MDAwwqDCoDAuMC4wLjDCoMKgMjU1LjI1NS4yNTUuMjU1wqDCoERIQ1DCoMKgwqDC oMKgMzQywqDCoMKgwqBESENQIERpc2NvdmVyIC0gVHJhbnNhY3Rpb24gSUQgMHgzMWRjMzIxZg0K PiAxMTkwIDEyOS45MDc1MDcwMDDCoMKgMC4wLjAuMMKgwqAyNTUuMjU1LjI1NS4yNTXCoMKgREhD UMKgwqDCoMKgwqAzNDLCoMKgwqDCoERIQ1AgRGlzY292ZXIgLSBUcmFuc2FjdGlvbiBJRCAweDMx ZGMzMjFmDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPjgtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBJJ2xsIHRyeSB0byBjYXB0dXJlIGRhdGEgZnJvbSBEdW1i IEFQIHNvbWV0aW1lIHNvb24gYW5kIHdpbGwgcmVwbHkgdG8gdGhlIHRocmVhZC4NCg0KU28gZmlu YWxseSBhZnRlciBxdWl0ZSBzb21lIHRpbWUgSSBmaWd1cmVkIG91dCB3aGF0IGhhcHBlbnMgaW4g bXkgc2V0dXAuDQpCYXNpY2FsbHkgaXQgYWxsIGJvaWxzIGRvd24gdG8gdGhlIGZhY3QgdGhhdCBE VyBHTUFDIGRvZXNuJ3QgZW50ZXIgcHJvbWlzY3VvdXMgbW9kZQ0Kd2hlbiBicmlkZ2UgZ2V0cyBj cmVhdGVkLiBUbyBiZSBtb3JlIHByZWNpc2UgR01BQydzIE1BQyBmaWx0ZXIgZmFpbCB0byBlbnRl ciBwcm9taXNjdW91cyBtb2RlDQphbmQgc28gcGFja2V0cyBmcm9tIERIQ1Agc2VydmVyIHNlbnQg dG8gV2ktRmkgY2xpZW4gYXJlIGRpc2NhcmRlZCBieSBHTUFDIC0gdGhhdCdzIHdoeSBJIGNhbm5v dA0Kc2VlIHRob3NlIHBhY2tldHMgaW4gdGNwZHVtcCBvdXRwdXQgLSBDUFUgbmV2ZXIgZ2V0cyBh bnkgaW5mb3JtYXRpb24gYWJvdXQgdGhlbS4NCg0KSSBub3RpY2VkIHRoYXQgcHJvYmxlbSBvbmx5 IGhhcHBlbnMgaWYgRXRoZXJuZXQgUEhZIChpbiBteSBjYXNlIHRoaXMgaXMgRFA4Mzg2NSkgZG9l c24ndCBoYXZlDQpsaW5rIGVzdGFibGlzaGVkLiBJLmUuIGVpdGhlcjoNCsKgMSkgQ2FibGUgaXMg ZGlzY29ubmVjdGVkDQrCoDIpIFBIWSBpcyBzdGlsbCBuZWdvdGlhdGlvbiBsaW5rIG1vZGUNCg0K T25jZSBQSFkgZ290IGxpbmsgZXN0YWJsaXNoZWQgR01BQyBoYXBwaWx5IGVudGVycyBwcm9taXNx IG1vZGUgYW5kIGFsbCB3b3JrcyBhcyBleHBlY3RlZC4NCg0KVW5mb3J0dW5hdGVseSBJIGNhbm5v dCBmaWd1cmUgb3V0IHdoeSBHTUFDIGJlaGF2ZXMgdGhhdCB3YXkuIEFzIHBlciBHTUFDJ3MgZGF0 YWJvb2sgdGhlIG9ubHkgcmVhc29uDQpmb3IgaXQgdG8gbm90IHJlYWN0IG9uIGEgcmVnaXN0ZXIg YmVpbmcgd3JpdHRlbiBpcyBtaXNzaW5nIGlucHV0IGNsb2NrIGJ1dCB0aGVyZSdzIG5vIHJlYXNv biBmb3IgdGhlDQpjbG9jayB0byBiZSBtaXNzaW5nIGFuZCBJIGRvbid0IHNlZW0gdG8gaGF2ZSBh IHdheSB0byBjaGVjayBpZiB0aGVyZSdzIGEgcHJvYmxlbSB3aXRoIGNsb2NrIG9yIG5vdC4NCg0K LUFsZXhleQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XwpsaW51eC1zbnBzLWFyYyBtYWlsaW5nIGxpc3QKbGludXgtc25wcy1hcmNAbGlzdHMuaW5mcmFk ZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4 LXNucHMtYXJj