Re: ARGUSBug Argus server occasionally generates an invalid meter DSR in a flow record
Carter Bullard <[email protected]> Mon, 18 Mar 2019 08:39:11 -0400
| Newsgroups | gmane.network.argus |
|---|---|
| Message-ID | <[email protected]> |
--Apple-Mail=_4E5C3CB5-6395-42EF-BFAD-681897ED1C5C Content-Type: multipart/alternative; boundary="Apple-Mail=_4A2E2237-AE67-4416-85DF-4B54928A88BF" --Apple-Mail=_4A2E2237-AE67-4416-85DF-4B54928A88BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hey Joel, Sorry for the delayed response. =20 A few things regarding your bug. The reason the errant flow record = print previous record contents is because we don=E2=80=99t zero out the = buffers as we read each record, so we can get the performance up. So we = parse the record, update the new metrics dsr header, and then we don=E2=80= =99t fill in any values, which leaves the data from the previous record = in the buffer. That is an easy fix, once we figure out why you=E2=80=99re putting a = zero in the qualifier bit. Still working on that. Hopefully this week. I=E2=80=99ve got 3.0.8.3 almost ready to put up, so the fixes will be = there, but I=E2=80=99ll send you a diff with your fixes for testing. Sorry for any inconvenience, Carter > On Feb 27, 2019, at 3:56 PM, Reed, Joel <[email protected]> wrote: >=20 > Hey Carter, >=20 > I have attached a binary argus file with the problem record. It was = captured directly from Argus. =20 >=20 > When the record has been put in a file by itself, the bytes and = packets are 0 like below. When the record is in the file with another = record before it, the client prints the bytes and packet values from the = previous record. >=20 > $ ra -r prob_rec.argus > StartTime Flgs Proto SrcAddr = Sport SrcPkts SrcBytes Dir DstAddr Dport DstPkts = DstBytes State > 2019-02-27T10:33:36.493615 EST * * tcp = 160.91.94.169.2049 0 0 ? 160.91.86.74.1023 = 0 0 CON >=20 >=20 > All is well here. Hope all is well with you! >=20 > Thanks, > Joel >=20 >=20 >=20 >=20 >=20 >> On Feb 27, 2019, at 2:14 PM, [email protected] = <mailto:[email protected]> wrote: >>=20 >> Hey Joel, >> Can you send a binary argus file that has one of the records in it = ??? Is this record coming directly from argus or is it coming from a = client =E2=80=A6 radium.1 ??? >>=20 >> There is a lot of data compression going on with the Meter DSR, and = the client library will attempt to pack the metrics into as little space = as possible, such that, if all the values are less than 256, then all = the metrics are reported as a char array. I suspect that the Meter DSR = has been compressed, but the final type description is getting dropped. >>=20 >> What do the argus-clients do with this record =E2=80=A6 do they print = out anything at all or do they jump past this DSR ??? >> Hope all is going well down in Tennesseeeeeeeeeee land !!!! >>=20 >> Carter >> =20 >>=20 >>> On Feb 27, 2019, at 2:01 PM, Reed, Joel via Argus-info = <[email protected] = <mailto:[email protected]>> wrote: >>>=20 >>> >Description: >>> The Argus server occasionally generates a flow record with a = meter DSR that is not properly parsed by the ra client. This causes the = packet, byte, and appbytes counts to be incorrect, usually containing at = least some count values from the previous flow record. Below I have = included a partial dump of the of the problematic flow record. The = meter DSR subtype 0x04 (includes app bytes) has a qualifier of 0x00. = The meter DSR parser (common/argus_client.c:~2223) does not have a case = to process a meter DSR subtype 0x04, qualifier of 0x00. >>>=20 >>> Partial hex dump of the flow record: >>>=20 >>> 01: 13 20 00 39 -- Type 0x10 (FAR), version 3, 0x20 = continuation, length 0x39 >>> 02: 01 03 00 03 -- Transport DSR=20 >>> 03: 00 00 00 00 | >>> 04: e1 12 61 ff | >>> 05: 02 01 01 05 -- Flow DSR >>> 06: a0 5b 56 4a | >>> 07: a0 5b 5e a9 | >>> 08: 06 00 03 ff | >>> 09: 08 01 00 00 | >>> 0a: 03 02 18 05 -- Time DSR >>> 0b: 5c 76 ad d0 | >>> 0c: 00 07 88 2f | >>> 0d: 5c 76 ad f0 | >>> 0e: 00 05 41 67 | >>> 0f: 10 04 00 05 -- Meter DSR, subtype 0x04, qualifier 0x00, = length 0x05 >>> 10: 30 00 00 01 | >>> 11: 40 00 01 02 | >>> 12: 01 f4 00 00 | >>> 13: 48 00 01 02 | >>> 14: 30 05 00 1e -- Network DSR >>> 15: ... >>>=20 >>> >How-To-Repeat: >>> Unknown. We see approximately one of these per hour. >>>=20 >>> >Fix: >>> Unknown. >>>=20 >>> >Originator: Joel Reed <[email protected] <mailto:[email protected]>> >>> >Organization: >>> ORNL >>> >ARGUS support: none >>> >Release: argus-3.0 >>> >Product: argus >>> >Synopsis: Argus server occasionally generates an invalid meter = DSR in a flow record >>> >Class: sw-bug >>> >Severity: non-critical >>> >Priority: low >>>=20 >>> >Environment: =20 >>>=20 >>> ARGUS: Argus Version 3.0.8.2 >>> RA: Ra Version 3.0.8.2 >>>=20 >>=20 >=20 > <prob_rec.argus> --Apple-Mail=_4A2E2237-AE67-4416-85DF-4B54928A88BF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">Hey = Joel,<div class=3D"">Sorry for the delayed response. </div><div = class=3D"">A few things regarding your bug. The reason the errant = flow record print previous record contents is because we don=E2=80=99t = zero out the buffers as we read each record, so we can get the = performance up. So we parse the record, update the new metrics dsr = header, and then we don=E2=80=99t fill in any values, which leaves the = data from the previous record in the buffer.</div><div class=3D""><br = class=3D""></div><div class=3D"">That is an easy fix, once we figure out = why you=E2=80=99re putting a zero in the qualifier bit. Still = working on that. Hopefully this week.</div><div class=3D""><br = class=3D""></div><div class=3D"">I=E2=80=99ve got 3.0.8.3 almost ready = to put up, so the fixes will be there, but I=E2=80=99ll send you a diff = with your fixes for testing.</div><div class=3D"">Sorry for any = inconvenience,</div><div class=3D""><br class=3D""><div = class=3D"">Carter</div><div class=3D""><br class=3D""><div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Feb = 27, 2019, at 3:56 PM, Reed, Joel <<a href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div class=3D"" = style=3D"caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: = 12px; font-style: normal; font-variant-caps: normal; font-weight: = normal; letter-spacing: normal; text-align: start; text-indent: 0px; = text-transform: none; white-space: normal; word-spacing: 0px; = -webkit-text-stroke-width: 0px; text-decoration: none; word-wrap: = break-word; line-break: after-white-space;">Hey Carter,<div class=3D""><br= class=3D""></div><div class=3D"">I have attached a binary argus file = with the problem record. It was captured directly from Argus. = </div><div class=3D""><br class=3D""></div><div class=3D"">When = the record has been put in a file by itself, the bytes and packets are 0 = like below. When the record is in the file with another record = before it, the client prints the bytes and packet values from the = previous record.</div><div class=3D""><br class=3D""></div><div = class=3D""><div class=3D"">$ ra -r prob_rec.argus</div><div = class=3D""> = StartTime Flgs = Proto SrcAddr Sport = SrcPkts SrcBytes Dir = DstAddr Dport DstPkts = DstBytes State</div><div class=3D""> = 2019-02-27T10:33:36.493615 EST * * = tcp 160.91.94.169.2049 = 0 0 ? = 160.91.86.74.1023 = 0 0 = CON</div></div><div class=3D""><br class=3D""></div><div class=3D""><br = class=3D""></div><div class=3D"">All is well here. Hope all is = well with you!</div><div class=3D""><br class=3D""></div><div = class=3D"">Thanks,</div><div class=3D"">Joel</div><div class=3D""><br = class=3D""></div><div class=3D""><br class=3D""></div><div = class=3D""></div></div><div class=3D"" style=3D"caret-color: rgb(0, 0, = 0); font-family: Helvetica; font-size: 12px; font-style: normal; = font-variant-caps: normal; font-weight: normal; letter-spacing: normal; = text-align: start; text-indent: 0px; text-transform: none; white-space: = normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; = text-decoration: none; word-wrap: break-word; line-break: = after-white-space;"><div class=3D""></div><div class=3D""><br = class=3D""><div class=3D""><br class=3D""></div><div class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Feb = 27, 2019, at 2:14 PM,<span class=3D"Apple-converted-space"> </span><a= href=3D"mailto:[email protected]" class=3D"">[email protected]</a><span= class=3D"Apple-converted-space"> </span>wrote:</div><br = class=3D"x_Apple-interchange-newline"><div class=3D""><div class=3D"" = style=3D"word-wrap: break-word; line-break: after-white-space;">Hey = Joel,<div class=3D"">Can you send a binary argus file that has one of = the records in it ??? Is this record coming directly from argus = or is it coming from a client =E2=80=A6 radium.1 ???</div><div = class=3D""><br class=3D""></div><div class=3D"">There is a lot of data = compression going on with the Meter DSR, and the client library will = attempt to pack the metrics into as little space as possible, such that, = if all the values are less than 256, then all the metrics are reported = as a char array. I suspect that the Meter DSR has been compressed, = but the final type description is getting dropped.</div><div = class=3D""><br class=3D""></div><div class=3D"">What do the = argus-clients do with this record =E2=80=A6 do they print out anything = at all or do they jump past this DSR ???</div><div class=3D"">Hope = all is going well down in Tennesseeeeeeeeeee land !!!!</div><div = class=3D""><br class=3D""><div class=3D"">Carter<div class=3D""><div = dir=3D"auto" class=3D"" style=3D"letter-spacing: normal; text-align: = start; text-indent: 0px; text-transform: none; white-space: normal; = word-spacing: 0px; text-decoration: none; word-wrap: break-word; = line-break: after-white-space;"> </div></div><div class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Feb = 27, 2019, at 2:01 PM, Reed, Joel via Argus-info <<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:</div><br = class=3D"x_Apple-interchange-newline"><div class=3D""><div class=3D"" = style=3D"word-wrap: break-word; line-break: after-white-space;"><div = class=3D"">>Description:</div><div class=3D""> The Argus = server occasionally generates a flow record with a meter DSR that is not = properly parsed by the ra client. This causes the packet, byte, = and appbytes counts to be incorrect, usually containing at least some = count values from the previous flow record. Below I have included = a partial dump of the of the problematic flow record. The meter = DSR subtype 0x04 (includes app bytes) has a qualifier of 0x00. The = meter DSR parser (common/argus_client.c:~2223) does not have a case to = process a meter DSR subtype 0x04, qualifier of 0x00.</div><div = class=3D""><br class=3D""></div><div class=3D""> Partial hex = dump of the flow record:</div><div class=3D""><br class=3D""></div><div = class=3D""> <span class=3D"Apple-converted-space"> </span><font = face=3D"Courier New" class=3D""> 01: 13 20 00 39 -- Type 0x10 = (FAR), version 3, 0x20 continuation, length 0x39</font></div><div = class=3D""><font face=3D"Courier New" class=3D""> 02: 01 03 = 00 03 -- Transport DSR </font></div><div class=3D""><font = face=3D"Courier New" class=3D""> 03: 00 00 00 00 = |</font></div><div class=3D""><font face=3D"Courier New" = class=3D""> 04: e1 12 61 ff |</font></div><div = class=3D""><font face=3D"Courier New" class=3D""> 05: 02 01 = 01 05 -- Flow DSR</font></div><div class=3D""><font face=3D"Courier New" = class=3D""> 06: a0 5b 56 4a |</font></div><div = class=3D""><font face=3D"Courier New" class=3D""> 07: a0 5b = 5e a9 |</font></div><div class=3D""><font face=3D"Courier New" = class=3D""> 08: 06 00 03 ff |</font></div><div = class=3D""><font face=3D"Courier New" class=3D""> 09: 08 01 = 00 00 |</font></div><div class=3D""><font face=3D"Courier New" = class=3D""> 0a: 03 02 18 05 -- Time DSR</font></div><div = class=3D""><font face=3D"Courier New" class=3D""> 0b: 5c 76 = ad d0 |</font></div><div class=3D""><font face=3D"Courier New" = class=3D""> 0c: 00 07 88 2f |</font></div><div = class=3D""><font face=3D"Courier New" class=3D""> 0d: 5c 76 = ad f0 |</font></div><div class=3D""><font face=3D"Courier New" = class=3D""> 0e: 00 05 41 67 |</font></div><div = class=3D""><font face=3D"Courier New" class=3D""> 0f: 10 04 = 00 05 -- Meter DSR, subtype 0x04, qualifier 0x00, length = 0x05</font></div><div class=3D""><font face=3D"Courier New" = class=3D""> 10: 30 00 00 01 |</font></div><div = class=3D""><font face=3D"Courier New" class=3D""> 11: 40 00 = 01 02 |</font></div><div class=3D""><font face=3D"Courier New" = class=3D""> 12: 01 f4 00 00 |</font></div><div = class=3D""><font face=3D"Courier New" class=3D""> 13: 48 00 = 01 02 |</font></div><div class=3D""><font face=3D"Courier New" = class=3D""> 14: 30 05 00 1e -- Network DSR</font></div><div = class=3D""><font face=3D"Courier New" class=3D""> 15: = ...</font></div><div class=3D""><br class=3D""></div><div = class=3D"">>How-To-Repeat:</div><div class=3D""> Unknown. = We see approximately one of these per hour.</div><div class=3D""><br= class=3D""></div><div class=3D"">>Fix:</div><div class=3D""> = Unknown.</div><div class=3D""><br class=3D""></div><div = class=3D"">>Originator: Joel Reed <<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>></div><div = class=3D"">>Organization:</div><div class=3D""> = ORNL</div><div class=3D"">>ARGUS support: none</div><div = class=3D"">>Release: argus-3.0</div><div = class=3D"">>Product: argus</div><div = class=3D"">>Synopsis: Argus server occasionally = generates an invalid meter DSR in a flow record</div><div = class=3D"">>Class:<span class=3D"x_Apple-tab-span" = style=3D"white-space: pre;"> </span><span = class=3D"Apple-converted-space"> </span> = sw-bug</div><div class=3D"">>Severity: = non-critical</div><div class=3D"">>Priority: = low</div><div class=3D""><br class=3D""></div><div = class=3D"">>Environment: </div><div class=3D""><br = class=3D""></div><div class=3D"">ARGUS: Argus Version = 3.0.8.2</div><div class=3D"">RA: Ra Version = 3.0.8.2</div><div class=3D""><br = class=3D""></div></div></div></blockquote></div><br = class=3D""></div></div></div></div></blockquote></div><br = class=3D""></div></div><span = id=3D"cid:[email protected]"><= prob_rec.argus></span></div></blockquote></div><br = class=3D""></div></div></body></html>= --Apple-Mail=_4A2E2237-AE67-4416-85DF-4B54928A88BF-- --Apple-Mail=_4E5C3CB5-6395-42EF-BFAD-681897ED1C5C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDH8w ggY5MIIFIaADAgECAgIvSjANBgkqhkiG9w0BAQUFADBwMQswCQYDVQQGEwJVUzEYMBYGA1UEChMP VS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNFQ0ExIjAgBgNVBAsTGUNlcnRpZmljYXRpb24gQXV0 aG9yaXRpZXMxFTATBgNVBAMTDE9SQyBFQ0EgU1cgNTAeFw0xNjA0MjExNDUyMjBaFw0xOTA0MjAx NDUyMjBaMIGGMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQL EwNFQ0ExDDAKBgNVBAsTA09SQzEUMBIGA1UECxMLUW9TaWVudCBMTEMxKzApBgNVBAMTIkJ1bGxh cmQuV2lsbGlhbS5DLk9SQzEwMDAwMzcxMDEuSUQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQDR+sBZYyKk0htuIgoLkSkV7lUnfo/inem6rqWzWZerA26V5lh6j1LQIxLA00NfiHVJ2nkv p9/2CcRljNV81LignnEi0Pp7QXYAgd+wYfHqy0Q2ZuFHnbEmqd8djJxGKGdYvD8krVeVJeouS5iu 2YcC4Me7jO6za8TFmwcTf/lr9oMl+xbXIVtk8YPsyLTZBmUWvdb9/wfipTTX6Om3NzTNCvSl6wdz ct56alGAi/dk+n3fUUo9SNethjr7LFWM/VTePlyLDkavdXINFs/H8uyWr+SjgwnfLnKv+zfxbw4k by1Ah/D18l36IdLEHPSIEDCtQGUJXF0qwWKEd2ZF/wLDAgMBAAGjggLEMIICwDAfBgNVHSMEGDAW gBS8D3cLjaOzhUPCNpNmrAKpd8M9UjAdBgNVHQ4EFgQUNnz7myAzDSiIqtxRyqe4NoLE4hcwggEj BggrBgEFBQcBAQSCARUwggERMB4GCCsGAQUFBzABhhJodHRwOi8vZXZhLm9yYy5jb20wMgYIKwYB BQUHMAKGJmh0dHA6Ly9lY2Eub3JjLmNvbS9jYUNlcnRzL0VDQS1TVzUucDdjMIG6BggrBgEFBQcw AoaBrWxkYXA6Ly9lY2EtZHMub3JjLmNvbS9jbiUzZE9SQyUyMEVDQSUyMFNXJTIwNSUyY291JTNk Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzJTJjb3UlM2RFQ0ElMmNvJTNkVS5TLiUyMEdvdmVy bm1lbnQlMmNjJTNkVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnksY3Jvc3NDZXJ0aWZpY2F0ZVBhaXI7 YmluYXJ5MA4GA1UdDwEB/wQEAwIGwDAdBgNVHREEFjAUgRJjYXJ0ZXJAcW9zaWVudC5jb20wFwYD VR0gBBAwDjAMBgpghkgBZQMCAQwBMIHxBgNVHR8EgekwgeYwK6ApoCeGJWh0dHA6Ly9lY2Eub3Jj LmNvbS9DUkxzL09SQ0VDQVNXNS5jcmwwgbaggbOggbCGga1sZGFwOi8vZWNhLWRzLm9yYy5jb206 Mzg5L2NuJTNET1JDJTIwRUNBJTIwU1clMjA1JTJDJTIwb3UlM0RDZXJ0aWZpY2F0aW9uJTIwQXV0 aG9yaXRpZXMlMkMlMjBvdSUzREVDQSUyQyUyMG8lM0RVLlMuJTIwR292ZXJubWVudCUyQyUyMGMl M0RVUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTAbBgNVHQkEFDASMBAGCCsGAQUF BwkEMQQTAlVTMA0GCSqGSIb3DQEBBQUAA4IBAQAJDKDhb7K8Gr2zCF4ItwIiA/mxi1H7CscUq76N EtZHoyoUnbfi15fgQnX/ZFPEsAVxx/Isupmi8RChTj67FxqfWZ8jsdb38PifUtI2Kqf31PSBU0jz 5vCobxb/K3y9dRGwLWx5ufOq6zLD3thYcFmUyJto4tEKWJds4/xjurAulr8EESeZvm5KmzzxohfL CbjJTlIGrVpUmeTYT3AwVdnNrNCdsVSCjyZWvAVId6LNheWpkPBVaHUO7VleWGqmiW9E79kQJ2V0 dn8Fg1kB85jv2lzrOpB43LiIK354h69mhAQZiR4QahY1gQFVnKb+Yspd53J8lg7yBWuNene9xlz1 MIIGPjCCBSagAwIBAgICL0swDQYJKoZIhvcNAQEFBQAwcDELMAkGA1UEBhMCVVMxGDAWBgNVBAoT D1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRUNBMSIwIAYDVQQLExlDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0aWVzMRUwEwYDVQQDEwxPUkMgRUNBIFNXIDUwHhcNMTYwNDIxMTQ1MzQwWhcNMTkwNDIw MTQ1MzQwWjCBizELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UE CxMDRUNBMQwwCgYDVQQLEwNPUkMxFDASBgNVBAsTC1FvU2llbnQgTExDMTAwLgYDVQQDEydCdWxs YXJkLldpbGxpYW0uQy5PUkMxMDAwMDM3MTAxLkVuY3J5cHQwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDIiywwq6YQSFJnhXYGQ+bwZUmjYQaNXWTNrEfnhw+L3aFBc5z4fO8wbSCsLigm JpVNDF/+ScNcB54IpVisD505AuXmY4AlF8/5n17+RWTWLXCXJ87YwKSPyD2orEGEoSF1oK3t3twA J4R+6zOMnG3LvFmXxeF2XuHRx9hpiE3XDo4PmdErNFFOfgtDhTHKXattg7rLEfxSFVYoheBaC2O1 C4ZWsel/T38dH/LFIMuQQdKyJODLCD+pBhDBTr4Ds7w98VOyq0HTmJ9vRZJffwzQnp25bGiSJXDW OU+mz9DRg7TrqlufWIjUbNd6ZhMDoup0yQ3Hr+IEGmi/qG8uz4GdAgMBAAGjggLEMIICwDAfBgNV HSMEGDAWgBS8D3cLjaOzhUPCNpNmrAKpd8M9UjAdBgNVHQ4EFgQUb/317FYu4hc3AFJyq7wwfWLC bFcwggEjBggrBgEFBQcBAQSCARUwggERMB4GCCsGAQUFBzABhhJodHRwOi8vZXZhLm9yYy5jb20w MgYIKwYBBQUHMAKGJmh0dHA6Ly9lY2Eub3JjLmNvbS9jYUNlcnRzL0VDQS1TVzUucDdjMIG6Bggr BgEFBQcwAoaBrWxkYXA6Ly9lY2EtZHMub3JjLmNvbS9jbiUzZE9SQyUyMEVDQSUyMFNXJTIwNSUy Y291JTNkQ2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzJTJjb3UlM2RFQ0ElMmNvJTNkVS5TLiUy MEdvdmVybm1lbnQlMmNjJTNkVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnksY3Jvc3NDZXJ0aWZpY2F0 ZVBhaXI7YmluYXJ5MA4GA1UdDwEB/wQEAwIFIDAdBgNVHREEFjAUgRJjYXJ0ZXJAcW9zaWVudC5j b20wFwYDVR0gBBAwDjAMBgpghkgBZQMCAQwBMIHxBgNVHR8EgekwgeYwK6ApoCeGJWh0dHA6Ly9l Y2Eub3JjLmNvbS9DUkxzL09SQ0VDQVNXNS5jcmwwgbaggbOggbCGga1sZGFwOi8vZWNhLWRzLm9y Yy5jb206Mzg5L2NuJTNET1JDJTIwRUNBJTIwU1clMjA1JTJDJTIwb3UlM0RDZXJ0aWZpY2F0aW9u JTIwQXV0aG9yaXRpZXMlMkMlMjBvdSUzREVDQSUyQyUyMG8lM0RVLlMuJTIwR292ZXJubWVudCUy QyUyMGMlM0RVUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTAbBgNVHQkEFDASMBAG CCsGAQUFBwkEMQQTAlVTMA0GCSqGSIb3DQEBBQUAA4IBAQAdNjcNYhcXvCHSn3F8XG9FdgIKJuc3 hjOsGmMTi/ChkSBi/511IdCqDwJEWnc8wH9mYJKYyiaDtCTyboYos9bIcgq2sHjIlAJK3DMfyBsi PJxg6LemVBojaPu4AAa8qi4BkLRkRPazsYQdGDioo8cXHRLWVvJIIVTPln3tPjUvD/o1OWYKIqUb p3HB7CtP3lIGOtklNL69Gc1om/fPPPxVeDQzUoYtQ5DDBMxTZz3L9TLNjD+7MAIFtgq5QobpLSNT Nbpo8VfwQZRU4yy0XwdtgESywzFyB0OVTO0upbRc8Vg+0VFw0W9lrx6Et7tF0y1fxEu9v5Mjicca KRmnxKFEMYIDIDCCAxwCAQEwdjBwMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5t ZW50MQwwCgYDVQQLEwNFQ0ExIjAgBgNVBAsTGUNlcnRpZmljYXRpb24gQXV0aG9yaXRpZXMxFTAT BgNVBAMTDE9SQyBFQ0EgU1cgNQICL0owDQYJYIZIAWUDBAIBBQCgggF7MBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MDMxODEyMzkxMlowLwYJKoZIhvcNAQkEMSIE ICwOrubIGSCEk8VyLOEENue22tQlNtNTQ2lscohdX+b9MIGFBgkrBgEEAYI3EAQxeDB2MHAxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0VDQTEiMCAGA1UE CxMZQ2VydGlmaWNhdGlvbiBBdXRob3JpdGllczEVMBMGA1UEAxMMT1JDIEVDQSBTVyA1AgIvSzCB hwYLKoZIhvcNAQkQAgsxeKB2MHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1l bnQxDDAKBgNVBAsTA0VDQTEiMCAGA1UECxMZQ2VydGlmaWNhdGlvbiBBdXRob3JpdGllczEVMBMG A1UEAxMMT1JDIEVDQSBTVyA1AgIvSzANBgkqhkiG9w0BAQEFAASCAQClH7WFylNb4vUVPLPqR3Fk AwXdkWb+d8Z6l0BJzStkvxthaVK9RB0K/x5uASkBMrV0YayfPoc9kp5y13KE6lYisG1ip+pX8ETw 3bukT4FvATvmJs9wfqUlEwojnzQYNj0M4Z50xoC27H6ylVOjObOE1bRbNP5WQZPlwqTS/rppc8Vi yu2nIYfKxAjFq8ZHMWUm9vTSKE9Z+uWkBMA32sshMwk0PvGC/KTZz6WOwD/PfYLAbPo9YEfLjLgv QYBREoW6QZ6odlXb6dZMCEk51TzQ34bTb0jg3IpTHVFp+WjNSB2CN1fnbxyAjNl/pNXWUZkFi2s9 KBQxHz45ArZzqN+8AAAAAAAA --Apple-Mail=_4E5C3CB5-6395-42EF-BFAD-681897ED1C5C--