From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id ECFA621F402 for ; Sun, 12 Apr 2015 07:18:59 -0700 (PDT) Received: by widjs5 with SMTP id js5so46679939wid.1 for ; Sun, 12 Apr 2015 07:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=HBKRO5mXh7vWbODpEJSkcsvEcu5VU+0T+heB0yEXfLU=; b=GYU2Im6AKxMi1D3b30THLVHPU/Yw7qPSynsRTjbDA/TG1goXyZ9Lcs5EoLLPwyArNE ef4VgWKxZfjCAT4N7fTkUxCTArrwJlKM5znkEATlMEeQdql5U7dncafVU6T1bxeJFYyF lrlhnShz1a5Kag54ngHGaLVTM+kLSg0OOVOuWbG0MZUoSJ3VUyrKSLurxI3L0zeIdl96 KmZNMbIBqVdwp76G7dSjg/7Q7SkDFYzLfWHlSwCIk75DSSzJmYyScFYk4gJnrg6USiyv /qYwo28KBPrdajeqG/KlUulLUi83jRxDICC5Du66iRTyGaUkVNSZMXEd8NPgaQh/ZnhO J9yw== X-Received: by 10.180.77.170 with SMTP id t10mr13323422wiw.5.1428848335897; Sun, 12 Apr 2015 07:18:55 -0700 (PDT) Received: from volcano.localdomain (host-92-11-217-205.as43234.net. [92.11.217.205]) by mx.google.com with ESMTPSA id e18sm7178122wjz.27.2015.04.12.07.18.54 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Apr 2015 07:18:55 -0700 (PDT) Message-ID: <552A7ECC.1080303@gmail.com> Date: Sun, 12 Apr 2015 15:18:52 +0100 From: Alan Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Kevin Darbyshire-Bryant References: <55295373.507@darbyshire-bryant.me.uk> In-Reply-To: <55295373.507@darbyshire-bryant.me.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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 14:19:30 -0000 On 11/04/15 18:01, Kevin Darbyshire-Bryant wrote: > Chaps, > > Newcomer to Openwrt & the Cerowrt concepts so bear with me. I've built > an Openwrt environment based on Archer C7 hardware and 'Cerowrt' > principles of 'Routed LANs' for GigE LAN, Wireless LAN1 & Wireless > LAN2. I get the design idea of limiting broadcast/multicast traffic on > the wireless LANs however for a vaguely technical home I'm hitting > problems that make things 'just not work', to the extent of thinking > about going back to bridged LAN/WLAN. So the 3 problems in ascending > order of annoyance/confusion. > > 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 sort > of WOL forwarding/proxying on the router would seem the way to go. Has > 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. > 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 :). Printers can often be made to work without the newest stuff, e.g. you can try adding it's IP address with the raw INF driver file, or maybe setting the exact model & it'll pick up the already installed driver. Whether there's some way to use "WS" printing over something slightly closer to the real W than a 1980s LAN, I don't know. > 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 easy > 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. I think there isn't a fully-automatic way to "unblock" for a home network. 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. 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/NetworkBrowsing.html#id2585378 [2] http://wiki.openwrt.org/doc/howto/dhcp.dnsmasq#configuring_dnsmasq_to_broadcast_wins_server_information > 4) (A bonus Monty Python question) I've a second wireless access point > at the other end of the garden, attached by a suitable length of Cat 6. > 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...how > 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 :). 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 > 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 wrong > 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. Alan