[Cerowrt-devel] Routed LANs vs WOL & Windows troubles

[Cerowrt-devel] Routed LANs vs WOL & Windows troubles

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 2380 bytes --]

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?

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 :-)

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?

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?


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.

Thanks for your time,

Kevin


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4791 bytes --]

Re: [Cerowrt-devel] Routed LANs vs WOL & Windows troubles

[Toke Høiland-Jørgensen]

Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:

> 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?

Dunno about the rest of your list, but I have successfully set up
multiple access points with roaming by using VLANs between them. Of
course VLAN-aware switches help, but if you have the access points
connected directly via a wire, you can use the VLAN support in openwrt,
to basically bridge the wifi interfaces of the two access points. That
way you avoid the problems with broadcasting across the LAN/WLAN border,
but can still get roaming on the same IP subnet. You'll want to have one
access point running DHCP, and the other just being passively serving as
the access point.

This can be setup via openwrt config files; can share my config if
you're interested.

> 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.

For some things, having the reflector functionality of avahi-daemon
turned on somewhere it can see both subnets helps on discovery and 'just
works'-iness :)

-Toke

Re: [Cerowrt-devel] Routed LANs vs WOL & Windows troubles

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 1943 bytes --]

Yes please!

--
Cheers,

Kevin@Darbyshire-Bryant.me.uk
Sent from my phone, apologies for brevity, spelling & top posting

> On 12 Apr 2015, at 12:57, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> 
> Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:
> 
>> 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?
> 
> Dunno about the rest of your list, but I have successfully set up
> multiple access points with roaming by using VLANs between them. Of
> course VLAN-aware switches help, but if you have the access points
> connected directly via a wire, you can use the VLAN support in openwrt,
> to basically bridge the wifi interfaces of the two access points. That
> way you avoid the problems with broadcasting across the LAN/WLAN border,
> but can still get roaming on the same IP subnet. You'll want to have one
> access point running DHCP, and the other just being passively serving as
> the access point.
> 
> This can be setup via openwrt config files; can share my config if
> you're interested.
> 
>> 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.
> 
> For some things, having the reflector functionality of avahi-daemon
> turned on somewhere it can see both subnets helps on discovery and 'just
> works'-iness :)
> 
> -Toke

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3089 bytes --]

Re: [Cerowrt-devel] Routed LANs vs WOL & Windows troubles

[Alan Jenkins]

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

Re: [Cerowrt-devel] Routed LANs vs WOL & Windows troubles

[Toke Høiland-Jørgensen]

Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:

> Yes please!

Right, well you can do it in two ways - depending on whether you want to
use the switch VLAN functionality (this is on the WNDR3800 - no idea
what the Archer has). I happen to have one box use the switch VLANs and
the other not, so both are included below:

This is all in /etc/config/network:

On the gateway device, I changed each of the sw* and gw* interfaces so
they use the VLANs:

config interface sw00
        option 'type' 'bridge'
        option 'ifname' 'se00.2'
        option 'proto'  'static'


The 'bridge' turns the interface into a bridge connected to the 'se00.2'
interface. The '.2' means 'use VLAN 2' on that interface, so in this
case, use VLAN 2 on the se00 interface. You need to use separate VLANS
for each of the interfaces you want to bridge in this way.

On this box, I then activate the switch VLAN functionality as follows:

config switch
        option name     rtl8366s
        option reset    1
        option enable_vlan 1
        option enable_vlan4k 1
        # Blinkrate: 0=43ms; 1=84ms; 2=120ms; 3=170ms; 4=340ms; 5=670ms
        option blinkrate        2
        option max_length 3

Note the 'enable_vlan' and 'enable_vlan4k' options - both are needed!

Then, modify the existing switch_vlan section:

config switch_vlan
        option device   rtl8366s
        option vlan     1
        option ports    "0 1 2t 3t 5t"
#       option ports    "0 1 2 3 5t"

The commented out option was the original setting. The 't' is for
'tagged', meaning that in this case, ports 0 and 1 are on VLAN 1
untagged (so traffic is considered to be part of VLAN 1, but no tags go
out on the wire), while ports 2 and 3 have VLAN tags on them (so the
equipment at the other end need to understand them). Port 5 is the
internal port that the WNDR itself sees all the traffic on, so should
always be tagged.

Now, add a section for each additional VLAN that you want to use:

config switch_vlan
        option device   rtl8366s
        option vlan     2
        option ports    "2t 3t 5t"

Here I define VLAN 2 active on ports 2 and 3 with VLAN tags. I have
identical sections for VLANs 3, 4 and 5.

Finally, I have sections:

config switch_port
        option port 0
        option pvid 1

Which basically tells the switch that the default VLAN for port 0 is
vlan 1. I have those for ports 0 and 1, but not entirely sure they're
absolutely needed.


The above config (repeated appropriately for all the wireless interfaces
you want this to work for) should get your wireless interfaces setup to
be bridged with a VLAN each. No changes are needed in
/etc/config/wireless, as long as you keep the 'config interface sw00'
part the same.


Now, on the secondary AP, I use the WAN port as the VLAN-aware 'uplink'
port to the primary gateway, and I don't use the switch VLAN support. So
this config is a bit simpler, and may be applicable to your setup if you
don't have a hardware switch in your device (or just don't want to use
it).

So what I do on the secondary AP is just, in /etc/config/network, set up
the bridging similar to on the primary AP:

config interface sw00
        option 'type' 'bridge'
        option 'ifname' 'ge00.2'

(again, repeat for all the sw* and gw* interfaces).

Make sure to match the VLAN number with what you had at the other end.
Also, I bridge the LAN ports with VLAN1:

config interface se00
        option 'ifname' 'se00 ge00.1'
        option 'type' 'bridge'

so anything connecting to the other side of the secondary AP will work
as though they're just on the LAN.

Also, on the secondary AP, I turn off all services (only ntpd, dropbear
and hostapd are running), and assign different IPs to the interfaces
(just add one to the last octet). The wireless config on the secondary
AP is identical to the primary, except I change the wireless channels to
minimise interference. If you're using PSKs for encrypted wifi, just use
the same key. If you're using WPA enterprise-type setups, just point the
secondary AP at the primary in the auth_server directive.


Hope the above explanation makes sense; if not, feel free to ask more
questions :P

-Toke

Re: [Cerowrt-devel] Routed LANs vs WOL & Windows troubles

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 906 bytes --]

On 12/04/2015 15:29, Toke Høiland-Jørgensen wrote:
> Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:
>
>> Yes please!
> Right, well you can do it in two ways - depending on whether you want to
> use the switch VLAN functionality (this is on the WNDR3800 - no idea
> what the Archer has). I happen to have one box use the switch VLANs and
> the other not, so both are included below:
<snip>

Owww, my head hurts!  I'll look at this after I'd had some sleep and
don't have the distractions of the in-laws visiting.  I was on the verge
of giving up on 'routed', it has a few days reprieve whilst I think.

The other access point is a Netgear WNR3500lv2 which doesn't do Openwrt
as far as I can tell :-(  The default firmware in incapable of
understanding /27 subnets via DHCP, so VLANS are probably too much to
hope for :-)  Much thought to be done but not today!

Kevin


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4791 bytes --]

Re: [Cerowrt-devel] Routed LANs vs WOL & Windows troubles

[Toke Høiland-Jørgensen]

On 12 April 2015 20:18:42 CEST, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
> On 12/04/2015 15:29, Toke Høiland-Jørgensen wrote:
> > Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> writes:
> >
> >> Yes please!
> > Right, well you can do it in two ways - depending on whether you
> want to
> > use the switch VLAN functionality (this is on the WNDR3800 - no idea
> > what the Archer has). I happen to have one box use the switch VLANs
> and
> > the other not, so both are included below:
> <snip>
> 
> Owww, my head hurts!  I'll look at this after I'd had some sleep and
> don't have the distractions of the in-laws visiting.  I was on the
> verge
> of giving up on 'routed', it has a few days reprieve whilst I think.

Heh, sorry if that was a bit verbose. It is definitely more involved than it should, but once you get the right config, it does work...

> 
> The other access point is a Netgear WNR3500lv2 which doesn't do
> Openwrt
> as far as I can tell :-(  The default firmware in incapable of
> understanding /27 subnets via DHCP, so VLANS are probably too much to
> hope for :-)  Much thought to be done but not today!

Well, in that case it probably also only handles one ssid? If so, you can most probably get away with configuring it for that and plugging it into an interface on the main gateway that you can then isolate (either via switch and vlan config, or straight interface name) and bridge to the appropriate Wi-Fi interface on the gateway...

-Toke

Re: [Cerowrt-devel] Routed LANs vs WOL & Windows troubles

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 7843 bytes --]

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 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.
>
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 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.
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. 
>
> 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
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 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
>
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 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.

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


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4791 bytes --]

Re: [Cerowrt-devel] Routed LANs vs WOL & Windows troubles

[Dave Taht]

You are right that you can achieve the roaming better with bridged, in
all the scenarios you mention below. Some of these problems are
solved, others not.

On Sat, Apr 11, 2015 at 10:01 AM, Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk> 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?


> 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 :-)

in cerowrt we used multicas
> 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?
>
> 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?
>
>
> 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.
>
> Thanks for your time,
>
> Kevin
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: [Cerowrt-devel] Routed LANs vs WOL & Windows troubles

[Kevin Darbyshire-Bryant]

[-- Attachment #1.1: Type: text/plain, Size: 7224 bytes --]

Ooops forgot to include my reply to Alan on the list, forwarded for the
'benefit' of everyone.  You'll be pleased to know I've concluded my
experiments with routed home networks :-)


-------- Forwarded Message --------
Subject: 	Re: Routed LANs vs WOL & Windows troubles
Date: 	Tue, 14 Apr 2015 10:28:25 +0100
From: 	Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
To: 	Alan Jenkins <alan.christopher.jenkins@gmail.com>



On 13/04/2015 23:25, Alan Jenkins wrote:
> O
<snip>
> Discovered that a couple of iphone based apps for my Sky set top box,
>
>     Yamaha AV Receiver & TV won't do device discovery either.
>
>
> Sounds about right :-).
>  
>
>
>     Battling on,
>
>     Kevin
>
>  
> In case I'm being stupidly ambiguous: I hear pain without a specific
> gain here.
>
> We haven't given you a number to say it makes your life better.  Also
> we know wifi needs a bunch more work.
You're absolutely right which is why later today things are going back
to firmware defaults and I shall be retreating to 192.168.230/24 with
the default bridging across LAN & WAN ports.
>
> If you _can_ see a subjective difference from the blocking of
> multicast in a home network, or something?  I think everyone would
> love to hear it.
No, of course I can't.  It was just theoretically the 'right thing to
do' and I suppose some idiot has to try it....I don't mind being an
idiot, comes naturally :-)
>
> Thanks for the firewall explanation in particular, personally I found
> that interesting.
Something useful has come out of this experience/experiment then :-) 
I'm probably a little more aware of windows firewall behaviour than the
average home user after my experiences with IPv6.  Windows may acquire
IPv6 addresses via DHCPv6 but since this protocol doesn't propagate a
'netmask' it has to treat each address as a /128.  It then
solicits/looks out for RA broadcasts that tell it which IPv6 prefixes
are 'on-link' (ie prefix length/local subnet)  There was an early bug in
dnsmasq's RA broadcasts which didn't have the relevant bit set (and I
was experimenting using dnsmasq for all my dns/dhcp4/6 needs and
ditching radvd) the net result was that I couldn't ping local IPv6
Windows boxes because they weren't considered 'on-link alias
local-subnet'.  Windows limits a number of services to local subnet only
including file sharing.

At present, without an obvious automatic mechanism for servers to expand
the 'local subnet' pool, Windows file sharing is going to be very
problematic in the home across subnets.
>
> Ah.  I meant server in the technical sense: the PC providing the file
> service.
>
> So I believe there is no automatic solution for this case in Windows.
>
> I'm sure sysadmins could script or gpo it, deploying to managed pcs. 
> But not the kind of scripts pcs will run automatically on a given IP
> network :).  Even if the network is marked as trusted ("home" / "work"
> / "private network").
>
> Also if anyone tries to use "Homegroup" - the wizard stuff in win 7+ -
> AFAICT it specifically only works on a single subnet.
Agreed.
>
>     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.
>
>
>     The Samba WINS server is almost working, seems to be advertising every
>     other box...except the server.  So close!
>
>
> Annoying!
>
> Obviously, like I mentioned about dnsmasq, if WHS isn't configured
> through DHCP & you set it with a purely static IP instead - it's not
> going to pick up WINS from DHCP.  It can be configured statically. 
> https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/ClientConfig.html#id2575612
I've a static mapping within dnsmasq, so all servers get everything they
need via DHCP4/6/RA but they do all stay at the same address....I have
to nail *something* down (well in IPv4 at least.  Don't get me started
on IPv6 SLAAC/Privacy addresses/DUID...and name resolution, oh yes and
IPv6 firewall 'pin hole' solutions)
>
> `ipconfig /all` will show name resolution config somewhere, which
> includes the WINS server.
>
> If WHS 2011 denies the existence of your WINS, there is a hack to
> create static entries in samba[1].  There is also a deprecated
> config[2] to forward wins queries to dns (I do not endorse this, but
> it means you could use a dns entry).
>
> [1]
> https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.html#id2584250
> [2]
> https://www.samba.org/samba/docs/using_samba/ch07.html#samba2-CHP-7-SECT-1.4.1
Thanks for that - it may yet come in handy.
>
>     >
>     >> 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
>     >
>     Toke has given some instruction on this.  After some sleep I may even
>     understand it :-)
>
>
> Toke's setup sounds like a commercial "wireless controller".  Each
> wifi AP is trunked back to the main router, which bridges all the wifi
> together (but doesn't bridge to wired access).  Wifi is a single
> subnet again.  IPs don't change when roaming between APs anymore.

I get what you're saying.  The 'gain' is that 5Ghz(1 AP) & 2.5Ghz (2 AP)
& Wired (2 'AP') are still different subnets.  I sort of got this
working by messing with vlans (effectively partitioning a LAN port out
of the LAN group and placing in it in a bridge with local 2.5Ghz &
remote AP 2.5Ghz)  Unfortunately due to some Archer C7 strangeness with
the vlan process it started dropping packets, no matter which wireless
or wired port, so I gave up on that idea.  There have been many hurdles
on this journey and I've pretty much smashed into every one.  So in
short, I shall now stop trying to be so darn clever (ha!) and hit the
factory reset button :-)   Single subnet, bridged WLANs/LANs here I
come.........phuuut!

Kevin

-- 
Thanks,

Kevin@Darbyshire-Bryant.me.uk




[-- Attachment #1.2: Type: text/html, Size: 15898 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4791 bytes --]