From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0069.outbound.protection.outlook.com [157.56.112.69]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id B598D21F3C3 for ; Sun, 12 Apr 2015 11:32:09 -0700 (PDT) Authentication-Results: lists.bufferbloat.net; dkim=none (message not signed) header.d=none; Received: from [IPv6:2001:470:183f:da2c::6f83:3b88] (2001:470:183f:da2c::6f83:3b88) by HE1PR07MB0937.eurprd07.prod.outlook.com (25.162.27.143) with Microsoft SMTP Server (TLS) id 15.1.136.25; Sun, 12 Apr 2015 18:32:03 +0000 Message-ID: <552ABA14.3090209@darbyshire-bryant.me.uk> Date: Sun, 12 Apr 2015 19:31:48 +0100 From: Kevin Darbyshire-Bryant User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alan Jenkins References: <55295373.507@darbyshire-bryant.me.uk> <552A7ECC.1080303@gmail.com> In-Reply-To: <552A7ECC.1080303@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080309060902090806020907" X-Originating-IP: [2001:470:183f:da2c::6f83:3b88] X-ClientProxiedBy: BY2PR08CA0016.namprd08.prod.outlook.com (25.163.62.154) To HE1PR07MB0937.eurprd07.prod.outlook.com (25.162.27.143) X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB0937; X-Microsoft-Antispam-PRVS: X-Forefront-Antispam-Report: BMV:1; SFV:NSPM; SFS:(10009020)(6009001)(24454002)(479174004)(51704005)(50986999)(65816999)(59896002)(54356999)(87266999)(76176999)(568964001)(92566002)(2950100001)(64126003)(65956001)(65806001)(36756003)(110136001)(122386002)(15975445007)(40100003)(80316001)(19580395003)(87976001)(4001350100001)(5890100001)(83506001)(77156002)(62966003)(86362001)(42186005)(512944002)(33656002)(84326002)(46102003)(74482002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB0937; H:[IPv6:2001:470:183f:da2c::6f83:3b88]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:HE1PR07MB0937; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB0937; X-Forefront-PRVS: 0544D934E1 X-OriginatorOrg: darbyshire-bryant.me.uk X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Apr 2015 18:32:03.2238 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB0937 Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] Routed LANs vs WOL & Windows troubles 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: Sun, 12 Apr 2015 18:32:38 -0000 --------------ms080309060902090806020907 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 12/04/2015 15:18, Alan Jenkins wrote: > On 11/04/15 18:01, Kevin Darbyshire-Bryant wrote: >> >> >> 1) I've a central Windows based Home Server (WHS) with a Wake On Lan >> facility - it dozes until a client appears on LAN/WLAN, sends a WOL >> Magic packet. Unfortunately the WOL Magic packets don't cross subnets= >> and the vast majority of clients are of the wireless variety. Some so= rt >> of WOL forwarding/proxying on the router would seem the way to go. Ha= s >> anyone been here/solved it already? > > In theory wol is (optionally) used over udp. I guess you need to set > a static arp entry on the router. Otherwise it will forget what the > MAC address was for the IP you're sending to. I've used `arp -f > /etc/ethers` at boot on debian. Not tested it on openwrt, or for wol > and I know wol can be annoying. > > Apple (at least used to, I read some complaints recently) got wol > working with Mac servers, Airport routers and mdns magic; I think the > client didn't need to know wol (maybe just required some part of > standardized mdns or dns-sd?). I don't expect cross-subnet clients > was a big selling point, but it sounded like there was potential there.= > > Problem is home servers didn't really take off in a big way before > Cloud, and modern products (like NAS, or my plug-computer) are lower > power things that don't benefit so much from wol. When/if subnetting > gets popular I'm not sure anyone's going to be fixing up wol. Outside > of managing corporate PCs, hmm, where some form of "wol relay agent" > sounds plausible enough it'll exist already. > It acts not just as a file store but also as a Windows update server, consolidating & updating a 5 or so Windows boxes. > >> 2) I have a 'WSD' printer/multifunction device on the LAN, an Epson >> something or other. It can communicate across subnets (ping) without >> issue but it always appears 'offline' as a WSD printer. I can use the= >> scanner functionality no problem at all :-) > > pass :). > This appears to have been solved - removed & readded the device. My guess is that despite using dns (via dnsmasq) that windows doesn't like the underlying IP changing. Requires a bit more investigating on the 4 other windows clients to see if the issue is replicated. > >> 3) Windows and its firewall. Windows likes its firewall on. It only >> likes to talk to things on the local attached subnet. Windows by >> default won't reply to pings across subnets and it certainly doesn't >> like doing file sharing. It would be wonderful if there was a nice ea= sy >> way (via DHCP?) of telling it 'trust 172.30.42/24' (or even my IPV6 >> equivalent /56) Has anyone else fallen in to this? Solved it? > > You only need to "unblock" on the server side, right? Which is > annoying, but shouldn't be too bad for someone who does WHS? I assume > you found a way to configure this manually, that's not your question.=20 > I think there isn't a fully-automatic way to "unblock" for a home > network. Actually not just server side. Client to client file sharing across subnets is broken. So the quick'n'dirty solution is to turn windows firewall off to evaluate if things will work if other impediments are solved (samba provided WINS on the router) I've both Samba & avahi running on the router, in theory configured to do the required SMB/WINS name collecting/forwarding. Similar with Avahi for mDNS stuff. I'm still struggling but will put more effort in.=20 > > Discovery & name resolution is a potential issue. > > The "easy answer" is to forget discovery aka "network neighborhood" > between different subnets. Just use IP addresses or DNS names.=20 > dnsmasq seems to take care of name resolution nicely for me, I get DNS > names for my hosts without manually configuring dnsmasq. If you don't > use DHCP for the WHS (i.e. purely static IP), you'll need to add a > manual entry to dnsmasq. You don't get p2p name resolution (LLMNR > nowadays) between different subnets. > > Discovery is done in "enterprise", so there must be a modern > mechanism. I'd expect using DNS, although I think there's some > craziness about making different things visible to different users. I > don't know how hard it is to admin and/or whether samba serves it. > > The slightly harder answer: Samba says there's a hack for > discovery[1], but that the best solution is to run a WINS server. You > then set a WINS server option in DHCP.[2] I expect it works, but > myself I've only really used it for name resolution in a single > subnet. (So I could disable a bunch of windows name-resolution > broadcasts with regedit). Don't know if your WHS will do WINS for you, > it's kinda deprecated, you could always run samba on the router. > > [1] > https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrow= sing.html#id2585378 > [2] > http://wiki.openwrt.org/doc/howto/dhcp.dnsmasq#configuring_dnsmasq_to_b= roadcast_wins_server_information The Samba WINS server is almost working, seems to be advertising every other box...except the server. So close! > > >> 4) (A bonus Monty Python question) I've a second wireless access poin= t >> at the other end of the garden, attached by a suitable length of Cat 6= =2E >> Devices at mid travel point ideally roam from House wifi to Shed >> wifi...but now they change IP address as well. To be honest I'm not >> sure how this actually works in a bridged environment either since the= >> MAC now migrates from local wireless bridge interface to local wired >> interface and potentially back again as I wander around the garden...h= ow >> does it really know where to send frames to this magically roaming >> device? > > Yes they can't keep the same IP address on a different subnet :).=20 > There are common cases where you don't notice and it wouldn't matter. > > There are references for bridging. Basically it's an optimization > over flooding packets to every single port (old-style dumb hub). As > soon as you send a frame from your MAC, all the bridges/switches in > between "learn" where you are now. If the target isn't known yet, the > frame is just flooded. > > Maybe this helps: http://computer.howstuffworks.com/ethernet12.htm > Toke has given some instruction on this. After some sleep I may even understand it :-) > >> It appears a lot of 'it just works' functionality is designed for >> bridged LAN/WLAN scenarios and hates routed but maybe I've got the wro= ng >> end of a stick. > > I think you're right & it's all built on sand :). It's not obvious to > me either though. If I actually used any network devices, like you > do, I probably wouldn't be bothering. Not outside of r&d. > > It'd be interesting if we had a simple writeup to show how more > efficient discovery should be, and the impact on wireless to justify > the change. You can see in principle e.g. resolving names through > dnsmasq instead of mdns can avoid broadcasting to everyone to get data > that's already known by the router. But the impact that has on > wireless is less obvious - the broadcasts have to use a minimal > wireless rate, lower by orders of magnitude. And that it affects > everyone in range sharing that channel. > > And when people want to just make it work across subnets without extra > development, they just re-implement flooding over IP. Cough, I think > I have Avahi configured that way on my router, for linux service > discovery... Optimistically, someone will get it right, standardize > it (DNS), and then vendors _have_ to use the efficient protocol > because that's what the routers implement. Discovered that a couple of iphone based apps for my Sky set top box, Yamaha AV Receiver & TV won't do device discovery either. Battling on, Kevin --------------ms080309060902090806020907 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINnDCC BjQwggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDE1NVoXDTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOr lr6KMoOMpohBllVHrdRvEg/q6r8jR+EK75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSM zR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC+y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6 qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxDz2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSD kOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr/+N2JLKutIxMYqQOJebr/f/h5t95 m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFcfH6WNU7y1LhRgjAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqD CH14qywGXLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy 6QMVQjbbMXltUfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPI zKKR9tQW8gGK+2+RHxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKf KSETEPrHh7p5shuuNktvsv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HOR z9v3vQwR4e3ksLc2JZOAFK+ssS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9 sIPP7ON0fz095HdThKjiVJe6vofq+n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCie uoBJ9OlqmsVWQvifIYf40dJPZkk9YgGTzWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7t w1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGqUp/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQ G2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb19mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t 5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHYDCCBkigAwIBAgIDCm0/MA0GCSqGSIb3DQEB BQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcNMTQwNzAzMTE1NjM5 WhcNMTUwNzA0MTc0MjQ1WjBxMRkwFwYDVQQNExA2dVNGb1pMU1d2dGgyd2tNMSYwJAYDVQQD DB1rZXZpbkBkYXJieXNoaXJlLWJyeWFudC5tZS51azEsMCoGCSqGSIb3DQEJARYda2V2aW5A ZGFyYnlzaGlyZS1icnlhbnQubWUudWswggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoIC AQDqCZMbkat9lukbtY+VQ4HBVkcHtcUU1sWZlg7foJ6XEQXCb3ArlyY7V+AldkNY6qRlrlVt YZmSFtDsors5e3Z1VWlEYBZEbnR57t5jmfGYmaaDzc8YsWr5gsUTa+MV/MNHpuAlf9GwgQCQ e7SC7kEzkQZApfB8/zG/a5JxgVXD9c3vK40p3OW27ZqVN9rie5SoLi1KEfQbA//VyPPeDpus oDwYGq6AA82lLFvgBxi1JPlS7M9zToUQCXpvDexQPiok1iqhwYBwX3qmSInlVWnudgaJ25iL m8/9bG5nCIo+dOEZP/bOCEsMzV8n9RaCNu8ilpjMXsHbkgrlvng81CTUFlYWhdMg58CM7N9y gSBjCKuHmJwQbIdsCmuKEOFVLZR8OZzoue6e/HAQlunWEfrr/H4+UYp8yTNLybqfcyZ3k7Sg i207jicY5dVKKFFY8eSB8Ps2svxj6BgrNPZMGzW36zRwaK1MpOZxHItCcuyXo+WkI3/61BZ5 mg34ejrgalQ04887n+4u3XPKnM/IwXfivlOD+n8bOOAGR8iZVlLTVmvypMdX3+wL/yB/w8g1 Ojj9Bk5/ksZb9Eh+3q1cVOOuXa/hcCLLqetNFzlxHjbVXzBKwO9pOs50DVxtv070KalD3iqz 8hCwnDt7odkGHwXyZAErmUSjc6tqVMivid/1swIDAQABo4IC4zCCAt8wCQYDVR0TBAIwADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSg QyTrQHiayWJq77xyyu7kpPmJ2jAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAo BgNVHREEITAfgR1rZXZpbkBkYXJieXNoaXJlLWJyeWFudC5tZS51azCCAUwGA1UdIASCAUMw ggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFj Y29yZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUg U3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVy cG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2 BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3Js MIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5j b20vc3ViL2NsYXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRz c2wuY29tL2NlcnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAChYSPOI6HHjtB2zQSGb 7vqo2f/QAum648uoNCFXf/ZmpU42ca6hq/JqsugqbnCY72hNTpCh3JZwTTaBWBvj1vzjjMra pLixIvceaAqMj6vd+L43APuMMmTH9tUUNS1ksXdA2r6STVIbr4p2sbVV3WktLGFnNAy5uXbr mLHay5w6jcmSfTAh1aA49sSvp+8CB6q6uDef2j9X8OE9Ajr5l0mcnGdVOkLZU6Zq20G8jb3p sdqoO9MU5UbKfZCN4/ibr+/0Pj3VZIE3jCEW2DwguN6DIDAYVc6b7RFGf3cWadJrSa887Sc/ 9wzXymTKAyBvfgRQeWcZ+5w4RlOI/TmpNfwxggTdMIIE2QIBATCBlDCBjDELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJ bnRlcm1lZGlhdGUgQ2xpZW50IENBAgMKbT8wCQYFKw4DAhoFAKCCAh0wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwNDEyMTgzMTQ4WjAjBgkqhkiG9w0B CQQxFgQUrR41obQBA5NFOiMl0f32K3ol1LkwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQME ASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpQYJKwYBBAGCNxAEMYGXMIGUMIGMMQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQ cmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwptPzCBpwYLKoZIhvcNAQkQAgsxgZeg gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDCm0/MA0GCSqGSIb3DQEB AQUABIICALCNXzgJKDq/SpXLvWRe/1bdGk9wG7L8gx9SBV4pcdjUhd+75v+PI0rbLqn2ikRC +F345VZ6iKRWozO6wQS3gswTkFNkjt/a+1o4/AGixYwrjZ/x28OIQtZ9ZUs2dQAsBpf6mZRR rYSL3y5ErbbK06a88wDqKCGi0Ui5nmrAPwVAHnhXP82mOm/NG9NMhXCMP8R9OHGwDtCvidtS ZzEh3mHoRCWkqPhO8PERTpB1rO2sjwg8cWPZjv8fT7PbTLo2C4OO+nyi1yHLKs6mBytH/6l0 O9LKLS57ncs8NPojoCNVAOt+WwxrdBNLnN5r3LxxCYF9WGG8uYZpLaHDBT5aevNWUQ9Fj8B6 oIMogICFK17BaXUDITu8KAKXi2HP590as24ylsfefNu+A8fVuAoEKqSwhsGoHiQubE33zO/c UCI3Z6fJveCTeUaBX+VGAYdgI61FQfMbOkEW+EkM42DLS+Wp+kWrhDmwDqpwF0+r5+hqeLUl XldpcBGw5p9Lk3KNIrUNkYJWqvr1gGAC6fVzjfZOMblKl2nRpk11sNslGdDjbOw/QoMapvMD mxdLn5+x8OrKYtTi9JGOM6pJWpYvc9C8FmI/KDscn9O2TgJOu7vIc5+EbCZuzTMuPvY/EYxy Ttj9iaLhkXsSQUFKcB7WOBRVXi0O6PUU8sYFleZgiYY8AAAAAAAA --------------ms080309060902090806020907--