OT: Networking problem - NSLOOKUP and other DNS queries fails on *LAN* hostname-to-address mapping after router rebooted

[NY]

I've got a mesh network using Linksys Velop devices, and a Plusnet router
connected as follows:

https://i.postimg.cc/RVGJYqnn/Scan-20-05-2021-1250.png

(I've not shown the other Velop nodes which are connected by wifi to the
parent node)


Until a power cut just now, computers on the LAN have been able to browse to
web servers on a couple of LAN computers (Raspberry Pis), using either the
"web server computer" IP (eg 10.120.1.73:9981) or its hostname
(martin-pi4:9981).

Now address-by-name is failing for some computers - I imagine it only still
works for a PC that has the web-server as an entry in its own local DNS
cache.

And indeed "nslookup martin-pi4" is failing with "<parent Velop hostname>
cannot find martin-pi4".

This affects the web servers and the PC trying to access them are all
connected by Ethernet; the same symptom is seen for computers that are
connected by wifi.


Can I just check that computers on a LAN *should* be able to resolve each
other using DNS, such as "nslookup hostname" or web-browse to "hostname".
Certainly it's worked for a year or so, surviving various power cuts and
thus enforced reboots.

Rebooting the parent node makes no difference. Windows PCs, even after
"ipconfig /flushdns" can browse to a local "web server" by name, but Android
(Dolphin or Firefox browser) fails to resolve.


Nothing seems to have changed in the Velop config: it is still configured to
use 8.8.8.8 and 4.4.4.4 as its *external* DNS servers (overriding the one
that my ISP provides - forget the reason for that, but its been like that
for years), though an internal DNS query shouldn't go near those.

Bloody power blips - we go through phases of getting short 5-second power
cuts. Normally there's just the hassle of starting all the Velop nodes in
the right order so they deign to talk to each other, but this time something
has screwed internal DNS queries.

[Graham J]

NY wrote:
> I've got a mesh network using Linksys Velop devices, and a Plusnet router
> connected as follows:
>
> https://i.postimg.cc/RVGJYqnn/Scan-20-05-2021-1250.png

[snip problem description]

ipconfig /all
... on a windows PC will show you its DNS server IP. Normally it gets
this by DHCP from a router.

Why does the Velop have DNS server entries? I would expect it to get a
DNS server IP from the router in the same way as the clients.

If you do not use this convention I suspect you have done so for a
reason. My suspicion is that the router (as with many provided by the
ISP) does not implement a DNS server - it only forwards to the one
operated by the ISP or the servers you manually put into the DHCP
settings. What this means is that name resolution does not work on a
Windows network as you would expect. It is summarised at:

<https://support.microsoft.com/en-us/topic/microsoft-tcp-ip-host-name-resolution-order-dae00cc9-7e9c-c0cc-8360-477b99cb978a>

... which effectively means for a domestic network with a simple router
that name resolution does not work at all, most of the time. If you
want it to work reliably, you have to implement something to achieve it
- either provide every client with a copy of the hosts file, or provide
a proper local DNS server.

My guess is that you have disabled the DHCP server in your router and
are using the Velop device for DHCP - or you configured your router to
tell its clients that the DNS server is the Velop device.

So, for all the clients, what DNS server are they configured for? Is
that DNS server supposed to do local name resolution? How? For example
when a MS Windows Small Business Server provides DNS it learns the
various hostnames when it responds to their DHCP requests for an IP address.

Can you tell us more about how you set this up?


--
Graham J

[NY]

"Graham J" <nob...@nowhere.co.uk> wrote in message
news:s860mi$p3k$1...@dont-email.me...

The setup with Velops and a router is a bit of a mess. Initially I had a
router (Plusnet Hub One) which was DHCP and DNS server, and did WAN-to-LAN
NAT (network address translation). And it had 2.4 and 5 GHz wifi access
point. The router's DHCP used 192.168.1.x. All bog-standard stuff.

But the wifi coverage would not cover our L-shaped house (with the router
having to be at the remote end of one of the legs of the L so as to be close
to my PCs/Pis connected by Ethernet - I don't trust wifi to work 24/7
without hiccups).

So we got Velop devices and I set up a mesh network. I followed the
instructions to the letter, because I'd read that any departure from them
may well break things. So I turned off DHCP and wifi on the router,
connected router to primary Velop by Ethernet (with all other Ethernet
connections being via the other socket on the Velop rather than the ones on
the router).

So now the primary Velop acts as DHCP and DNS server. Its own address is
10.120.1.1 and its DHCP scope is 10.120.1.x. This issue with DHCP scope on
one subnet (10.120.1.x) and router's admin IP on another (192.168.1.x) has
always worried me, but I haven't wanted to rationalise the for fear of
breaking it.

It does mean that there is double NAT on the network: 10.120.1.x to
192.168.1.x in the Velop and 192.168.1.x to the ISP-supplied public IP on
the router, but apparently that is how it's supposed to be. I haven't dared
turn off NAT on the router (ie just using it as a bare modem) because I
don't like the thought of public WAN traffic on one Ethernet socket and
private LAN traffic on the other Ethernet socket of the primary node: I'm
sure that is a situation to avoid like the pox!


So "ipconfig /all" on a Windows computer (or "ifconfig /all" on Linux -
which can't they both use the same command!) gives

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : lan
Link-local IPv6 Address . . . . . : (an iPv6 address)
IPv4 Address. . . . . . . . . . . : 10.120.1.70
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.120.1.1

[Graham J]

NY wrote:

[snip]

> The setup with Velops and a router is a bit of a mess. Initially I had a > router (Plusnet Hub One) which was DHCP and DNS server, and did >
WAN-to-LAN NAT (network address translation). And it had 2.4 and 5 GHz >
wifi access point. The router's DHCP used 192.168.1.x. All bog-standard
> stuff.

OK understood

> But the wifi coverage would not cover our L-shaped house (with the
> router having to be at the remote end of one of the legs of the L so as
> to be close to my PCs/Pis connected by Ethernet - I don't trust wifi to
> work 24/7 without hiccups).

I don't trust WiFi at all ....

> So we got Velop devices and I set up a mesh network. I followed the
> instructions to the letter, because I'd read that any departure from
> them may well break things. So I turned off DHCP and wifi on the router,
> connected router to primary Velop by Ethernet (with all other Ethernet
> connections being via the other socket on the Velop rather than the ones
> on the router).

Router WiFi off = correct

So how does the Velop's WAN interface know what IP to use for the
router? Surely it expects to find a DHCP server to tell it?

> So now the primary Velop acts as DHCP and DNS server. Its own address is
> 10.120.1.1 and its DHCP scope is 10.120.1.x. This issue with DHCP scope
> on one subnet (10.120.1.x) and router's admin IP on another
> (192.168.1.x) has always worried me, but I haven't wanted to rationalise
> the for fear of breaking it.
>
> It does mean that there is double NAT on the network: 10.120.1.x to
> 192.168.1.x in the Velop and 192.168.1.x to the ISP-supplied public IP
> on the router, but apparently that is how it's supposed to be. I haven't
> dared turn off NAT on the router (ie just using it as a bare modem)
> because I don't like the thought of public WAN traffic on one Ethernet
> socket and private LAN traffic on the other Ethernet socket of the
> primary node: I'm sure that is a situation to avoid like the pox!

If the Velop is a proper router with a firewall that should be OK. It's
no different to any Ethernet router arrangement where there is an
Ethernet modem. A typical example would be an Ethernet router connected
to one of Openreach's Huawei FTTC modems. The advantage is that your
router can still tell you useful things about your ADSL or FTTC
connection (if you connect a dedicated PC directly to it). By contrast
you can't get any useful diagnostic info out of the Huawei FTTC modem.

Double-NAT should not matter. Some specific apps may object to
double-NAT, but these will be ones which try to manipulate the router's
firewall for their own purposes.

You could either configure the Velop with an IP in the 192.168.1.0
network, or configure the router with an IP in the 10.120.1.0 network;
then modify the default gateway setting published by the DHCP server in
the Velop (if it allows you to configure it) to point to the IP of the
router.

But none of the above affects your problem with local name resolution.

> So "ipconfig /all" on a Windows computer (or "ifconfig /all" on Linux -
> which can't they both use the same command!) gives

"Innovation breeds incompatibility" - catch phrase from one of my early
workplaces ...

> Ethernet adapter Local Area Connection:
>
>   Connection-specific DNS Suffix  . : lan
>   Link-local IPv6 Address . . . . . : (an iPv6 address)
>   IPv4 Address. . . . . . . . . . . : 10.120.1.70
>   Subnet Mask . . . . . . . . . . . : 255.255.255.0
>   Default Gateway . . . . . . . . . : 10.120.1.1

Mine shows Lease obtained/expires, Default gateway, DHCP server, DNS
servers. Have you omitted them, or does yours not show them?

What does the Velop documentation say about its DNS server and local
name resolution? Unless it is explicit about this, I suspect it is
really just a DNS relay, not a server at all; in which case name
resolution is really happening via NetBIOS


--
Graham J

[NY]

"Graham J" <nob...@nowhere.co.uk> wrote in message

news:s86f3t$33l$1...@dont-email.me...

> I don't trust WiFi at all ....

Wifi is great for mobile devices such as phones, tablets, laptops. But I
wouldn't trust it for always-on computers that need to be accessed from
outside the house (eg using TeamViewer or RealVNC), where you can't just nip
home to reboot a router or a computer if wifi comms have been lost. Hence
all my computers are on Ethernet, and the "client" devices like phones,
tablets and laptops use wifi.

Our house is not a nice square/cubic design where one access point - or one
per floor - will cover everywhere. We needed *six* to cover the whole house,
on account of the thick stone walls in the older part. After a lot of
faffing around experimenting with placement, I've managed to get almost all
the nodes to see the primary node; previously everything was daisy-chained A
could see B but no other; B could see A and C; C could see B but no other,
etc. The only exception is the one which covers the garden, which cannot
directly see the primary.

>> So we got Velop devices and I set up a mesh network. I followed the
>> instructions to the letter, because I'd read that any departure from them
>> may well break things. So I turned off DHCP and wifi on the router,
>> connected router to primary Velop by Ethernet (with all other Ethernet
>> connections being via the other socket on the Velop rather than the ones
>> on the router).
>
> Router WiFi off = correct
>
> So how does the Velop's WAN interface know what IP to use for the router?
> Surely it expects to find a DHCP server to tell it?

I got it slightly wrong: I left DHCP on at the router, and configured a
reserved 192.168.1.x address for the primary Velop (identified by its MAC).
Since nothing else is plugged into the router and its wifi is turned off,
this is the *only* address that the router's DHCP hands out. Computers that
are connected to the Velop (Ethernet or wifi) only get a DHCP response from
the Velop; the DHCP traffic doesn't get through to the router's DHCP.

>> So now the primary Velop acts as DHCP and DNS server. Its own address is
>> 10.120.1.1 and its DHCP scope is 10.120.1.x. This issue with DHCP scope
>> on one subnet (10.120.1.x) and router's admin IP on another (192.168.1.x)
>> has always worried me, but I haven't wanted to rationalise the for fear
>> of breaking it.
>>
>> It does mean that there is double NAT on the network: 10.120.1.x to
>> 192.168.1.x in the Velop and 192.168.1.x to the ISP-supplied public IP on
>> the router, but apparently that is how it's supposed to be. I haven't
>> dared turn off NAT on the router (ie just using it as a bare modem)
>> because I don't like the thought of public WAN traffic on one Ethernet
>> socket and private LAN traffic on the other Ethernet socket of the
>> primary node: I'm sure that is a situation to avoid like the pox!
>
> If the Velop is a proper router with a firewall that should be OK. It's
> no different to any Ethernet router arrangement where there is an Ethernet
> modem. A typical example would be an Ethernet router connected to one of
> Openreach's Huawei FTTC modems. The advantage is that your router can
> still tell you useful things about your ADSL or FTTC connection (if you
> connect a dedicated PC directly to it). By contrast you can't get any
> useful diagnostic info out of the Huawei FTTC modem.
>
> Double-NAT should not matter. Some specific apps may object to
> double-NAT, but these will be ones which try to manipulate the router's
> firewall for their own purposes.

Yes, our security cameras come with a lifetime subscription to dynamic DNS
service, but this won't work via double-NAT. I have to hard-code the
router's public IP address (rather than its DDNS name) as a shortcut on my
phone/laptop to access the security camera from outside, and if it doesn't
work it's a case of VNC-ing to a computer on the network and browsing to the
router, to see what public address it now has, if not the one I'd
hard-coded. Not ideal :-(

> You could either configure the Velop with an IP in the 192.168.1.0
> network, or configure the router with an IP in the 10.120.1.0 network;
> then modify the default gateway setting published by the DHCP server in
> the Velop (if it allows you to configure it) to point to the IP of the
> router.
>
> But none of the above affects your problem with local name resolution.
>
>> So "ipconfig /all" on a Windows computer (or "ifconfig /all" on Linux -
>> which can't they both use the same command!) gives
>
> "Innovation breeds incompatibility" - catch phrase from one of my early
> workplaces ...
>
>> Ethernet adapter Local Area Connection:
>>
>> Connection-specific DNS Suffix . : lan
>> Link-local IPv6 Address . . . . . : (an iPv6 address)
>> IPv4 Address. . . . . . . . . . . : 10.120.1.70
>> Subnet Mask . . . . . . . . . . . : 255.255.255.0
>> Default Gateway . . . . . . . . . : 10.120.1.1
>
> Mine shows Lease obtained/expires, Default gateway, DHCP server, DNS
> servers. Have you omitted them, or does yours not show them?

I'm an idiot: I copied the output from "ipconfig" rather than "ipconfig
/all".


Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : lan

Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit
Ethernet
Physical Address. . . . . . . . . : [MAC]
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Link-local IPv6 Address . . . . . : [IPv6] (Preferred)
IPv4 Address. . . . . . . . . . . : 10.120.1.70(Preferred)

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Lease Obtained. . . . . . . . . . : 20 May 2021 11:44:22
Lease Expires . . . . . . . . . . : 21 May 2021 11:44:22

Default Gateway . . . . . . . . . : 10.120.1.1

DHCP Server . . . . . . . . . . . : 10.120.1.1
DHCPv6 IAID . . . . . . . . . . . : []
DHCPv6 Client DUID. . . . . . . . : []
DNS Servers . . . . . . . . . . . : 10.120.1.1
NetBIOS over Tcpip. . . . . . . . : Enabled

> What does the Velop documentation say about its DNS server and local name
> resolution? Unless it is explicit about this, I suspect it is really just
> a DNS relay, not a server at all; in which case name resolution is really
> happening via NetBIOS

The documentation is pretty non-existent - marketing but not technical.

You are probably right about it not being a proper DNS server. I'd not
realised that some DHCP servers in routers didn't act as DNS servers for
local name resolution of the names/addresses that DHCP has handed out.

I'd love to know what has suddenly changed that has killed name resolution
on non-Windows computers, when it had worked for so long. (*) My wife's
Android phone and her Apple iPad also fail like my Android phone does. I
discovered that it had also killed VNC connections from my phone to the
Raspberry Pis. RealVNC server on Windows can only access computers over the
cloud (traffic goes from the LAN to a RealVNC server and then back to the
LAN) which can be slow. But the Pi is a special beast: its server can be
accessed by IP or hostname *locally*. Except that direct access by hostname
no longer works on an Android client, so I had to redefine the connections
to use IP instead. I suppose I could have guessed that it would be affected
;-)

Thinking about it, I believe initially web-browsing or VNC by LAN name
didn't work, then one day a couple of years ago I tried and found it now did
work - and continued to work for the next year or so, until today.


(*) I almost wonder if there was a firmware upgrade that I wasn't aware of,
and *any* reboot, whether graceful or not, would have triggered the change.
Like the firmware upgrade to our smart TV which killed the ability to define
"favourite channels", selected from the hundreds that are available on
satellite. Philips said that they and all other TV vendors had been ordered
by Ofcom to remove the "favourites" feature and to force-feed the change to
all TVs. The "fix" is to redo the initial setup but to say I'm in a country
other than the UK. That still gets the proper firmware without Ofcom's
nobbling.

[Graham J]

NY wrote:

[snip]

I think you've explained about your WiFi arrangement before here.

>>> So we got Velop devices and I set up a mesh network. I followed the

[snip]

The "proper" solution is to connect all the Wifi nodes via Ethernet, and
use a router that manages the client connections, directing the node
with the strongest signal to connect to the client and changing the
setting when the client moves about. All the nodes could use PoE and be
powered from a UPS, so the power outage problem goes away. Also useful
if you get any VoIP phones.

Difficult if running Ethernet cables is politically impossible.

Some mesh devices use a private radio channel to implement the backhaul
between themselves and the master device. Does the Velop do this?

>> So how does the Velop's WAN interface know what IP to use for the >> router? Surely it expects to find a DHCP server to tell it?>> I got
it slightly wrong: I left DHCP on at the router, and configured a >
reserved 192.168.1.x address for the primary Velop (identified by its >
MAC).

That makes much more sense.

[snip about double-nat]

>
> Yes, our security cameras come with a lifetime subscription to dynamic
> DNS service, but this won't work via double-NAT.

In theory you could use the DDNS subscription in your router. But some
routers don't support DDNS or are limited as to the the DDNS servers
they can use.

You then have to port-forward traffic through both routers - probably
impossible for what you need.

[snip]

> I'm an idiot: I copied the output from "ipconfig" rather than "ipconfig
> /all".
>
>
> Microsoft Windows [Version 6.1.7601]
> Copyright (c) 2009 Microsoft Corporation.  All rights reserved.
>
> Ethernet adapter Local Area Connection:
>
>   Connection-specific DNS Suffix  . : lan
>   Description . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit
> Ethernet
>   Physical Address. . . . . . . . . : [MAC]
>   DHCP Enabled. . . . . . . . . . . : Yes
>   Autoconfiguration Enabled . . . . : Yes
>   Link-local IPv6 Address . . . . . : [IPv6] (Preferred)
>   IPv4 Address. . . . . . . . . . . : 10.120.1.70(Preferred)
>   Subnet Mask . . . . . . . . . . . : 255.255.255.0
>   Lease Obtained. . . . . . . . . . : 20 May 2021 11:44:22
>   Lease Expires . . . . . . . . . . : 21 May 2021 11:44:22
>   Default Gateway . . . . . . . . . : 10.120.1.1
>   DHCP Server . . . . . . . . . . . : 10.120.1.1
>   DHCPv6 IAID . . . . . . . . . . . : []
>   DHCPv6 Client DUID. . . . . . . . : []
>   DNS Servers . . . . . . . . . . . : 10.120.1.1
>   NetBIOS over Tcpip. . . . . . . . : Enabled

OK so all the clients (if using DHCP) get the Velop as DNS server.

I think NetBIOS collects information off the LAN and may build a name
table - so some devices will resolve some others by name.

> You are probably right about it not being a proper DNS server. I'd not
> realised that some DHCP servers in routers didn't act as DNS servers for
> local name resolution of the names/addresses that DHCP has handed out.

Somebody here often comments about routers not implementing local DNS
resolution - even respected up-market models. You might try getting
another Pi and running it as a local DNS server. Where I've configured
DNS servers (Windows SBS) the DHCP server provides the info for the DNS
and you can add addresses by binding or reservation. So probably your
Pi would have to implement DHCP also.

[snip wondering why it ever worked]


--
Graham J

[Tweed]

I’ve not read through all the ins and outs of this thread, so apologies if
this does not help:

I too have a Velop system. Mine are hooked up to a Virgin Media cable
modem/router.

By default the Velop system is also configured as a router and DHCP server.
If you want your original router to be in control you need to turn off the
router functionality in the primary Velop node. This is what I have done,
so my VM router is the one and only router and DHCP server on my network.

This means the Velop nodes are simply acting as wireless access points,
though still retaining their mesh network functionality. They work
extremely well. Ive separated out the naming of the 2.4GHz and 5GHz radios,
so I know exactly what I’m connecting to from the client.

Allied to your original query, I was much surprised to discover that I
could VNC to one of my Raspberry Pi computers by using <raspberry pi
name>.local , eg octopi.local

My understanding of tcp/ip started (and probably ended!) in the late 1980s
with the seminal O’Reilly book, so this .local thing took me by surprise. A
bit of digging led to me discovering multicast DNS

https://en.wikipedia.org/wiki/Multicast_DNS

which seems to be supported by most operating systems.

[Graham J]

Tweed wrote:

[snip]

> Allied to your original query, I was much surprised to discover that I > could VNC to one of my Raspberry Pi computers by using <raspberry pi>
name>.local , eg octopi.local

VNC is irrelevant, it is the name resolution in the local PC that you
are relying on.

> My understanding of tcp/ip started (and probably ended!) in the late
1980s> with the seminal O’Reilly book, so this .local thing took me by
surprise. A> bit of digging led to me discovering multicast DNS> >
https://en.wikipedia.org/wiki/Multicast_DNS> > which seems to be
supported by most operating systems.

So this might work for some clients some of the time.

I suspect that from a PC something like:

ping <name>.local

... will initially fail, but will after a time invoke mDNS. The PC will
try whatever other name resolution methods is has (in the order
described in the link I posted earlier, which might be user
configurable). So there may be several seconds delay; and it would
account for name resolution having appeared to work in the past.

So next time you try ping <name>.local it will resolve the name.

If this does behave as I describe, you perhaps should run a startup
script on every PC to ping all your various devices - this might force
the name resolution.

--
Graham J

[NY]

"Graham J" <nob...@nowhere.co.uk> wrote in message

news:s87lcf$a22$1...@dont-email.me...

> The "proper" solution is to connect all the Wifi nodes via Ethernet, and
> use a router that manages the client connections, directing the node with
> the strongest signal to connect to the client and changing the setting
> when the client moves about. All the nodes could use PoE and be powered
> from a UPS, so the power outage problem goes away. Also useful if you get
> any VoIP phones.
>
> Difficult if running Ethernet cables is politically impossible.

Yes, the "SWMBO (Rumpole)" test ;-)

Before we thought of a true mesh network, I'd considered using the router's
wifi to cover one part of the house, and then running a long Ethernet cable
in the loft to the other leg where I'd put one (or maybe two) access points.
But it would have involved the age-old problem of how to run a Cat 7 cable
(even one of the new flat ones) up the wall and through the ceiling into the
loft, without disturbing the decoration by chasing a groove into the wall
and then having a hole in the ceiling, a couple of inches from the corner
because of the diameter of the drill chuck. And then work out how to get the
cable through a floor-to-ceiling breezeblock firebreak wall which divides
one part of the loft from another (maybe when different parts of the house
were added on). And cope with the fact that there are some very
awkwardly-placed diagonal beams in the loft, where a smaller internal roof
has been enveloped in a larger one as the house was extended. Oh, and avoid
stepping through the ceiling because the strips of loft insulation don't
just run *between* the rafters, but another layer has been laid at right
angles *across* the rafters, so it's very difficult to see the damn things
when stepping from one rafter to the next. And a collection of access points
wouldn't have been as seamless when roaming around the house: with the Velop
I can be playing a video on my Win 10 laptop, accessed by SMB from another
computer on the network. And as I roam around the house, going out of range
of one node and into range of another, the video plays seamlessly. The
handoff between nodes is pretty impressive. Not that walking around the
house streaming video is an every day occupation, but I have sometimes
started a large download of an installation file from the internet while my
laptop is in the bedroom and then taken the laptop through to my study, and
it's nice when this doesn't break the download.

In the ideal world, I agree: mesh nodes linked by Ethernet rather than 5 GHz
would be a good idea. Occasionally I've seen data transfer rates over wifi
fall from around 200-300 Mbps to about 20 Mbps, and when I look, I see that
the node which my laptop is connected to is itself connected to the primary
via one or two other nodes (daisy-chaining) rather than directly. Assuming
that all the backhaul links are on different on-overlapping channels (and
with 5 GHz that's easy to achieve) does multi-hop
PC-node1-node2-node3-node4-server run any slower than PC-node1-node4-server?
Are there overheads for receiving and then retransmitting on a different
channel?

> Some mesh devices use a private radio channel to implement the backhaul
> between themselves and the master device. Does the Velop do this?

Yes they do. Therein lies the problem. The backhaul uses 5 GHz for extra
speed. But this has a shorter range than 2.4 GHz, so the nodes must be
fairly close together - close enough that the 2.4 GHz signals from several
nodes overlap. When the devices start up, they auto-negotiate which 2.4 and
5 GHz channels they will use to avoid interfering with each other. And they
have filled the whole 2.4 GHz spectrum from Ch 1 to Ch 14. That is why nodes
sometimes remain in the flashing-red "negotiating" phase permanently if they
are all started simultaneously - eg after a power cut. I know now to turn
them all off, turn on just the primary, then one of them, then (after the
first is happy) the next, and so on. The only things that *must* use 2.4 are
the security cameras (unless they are within Ethernet distance of a node);
apart from those, I could disable 2.4 altogether and probably eliminate the
startup hassle. But it would be nice to be able to turn on 2.4 on a per-node
rather than a per-network level, so I could have the node that covers the
garden able to use 2.4 GHz for extra range at the expense of (maybe) lower
transfer rate at the fringes.

What I really *should* do [being facetious] is erect a 20 m mast on the
patio, where the whole house can see it, and crank up the power way beyond
the permitted limits for wifi. ;-) No need for mesh or Ethernet around the
house - just dig a channel under the patio stones for its Ethernet feed. As
if...

>>> So how does the Velop's WAN interface know what IP to use for the >>
>>> router? Surely it expects to find a DHCP server to tell it?>> I got
> it slightly wrong: I left DHCP on at the router, and configured a >
> reserved 192.168.1.x address for the primary Velop (identified by its >
> MAC).
> That makes much more sense.
>
> [snip about double-nat]
>
>>
>> Yes, our security cameras come with a lifetime subscription to dynamic
>> DNS service, but this won't work via double-NAT.
>
> In theory you could use the DDNS subscription in your router. But some
> routers don't support DDNS or are limited as to the the DDNS servers they
> can use.
>
> You then have to port-forward traffic through both routers - probably
> impossible for what you need

Ah, port forwarding... Yes, that was fun!

I have a couple of security cameras which can be accessed for live video by
web interface. And port-forwarding allows this to be done from outside the
LAN. With the old single-router config, it was fairly easy to map
<public-IP>:81 -> <camera1>:80 and <public-IP>:82 -> <camera2>:80. When I
added the Velops, I had to have a two-stage port forwarding:
<public-IP>:81 -> <router's IP>:81 and <public-IP>:82 -> <router's IP>:82
(at the router), and then (at the Velop) <router's IP>:81 -> <camera1>:80
and <router's IP>:82 -> <camera2>:80. In other words, the Velop is
port-fowarding not from a WAN IP but from a 192.168.1.x address used for
comms between Velop and router. Took a bit of working out how to configure
it in the UIs for the two devices. since Velop FAQs were a bit vague.

But the lack of DDNS is a pain.

I had wondered about configuring one of the Pis as a DNS server, and had
come to the conclusion that it needs to run DHCP as well and that the two
programs need to talk to each other as they share a common list: MAC-IP and
IP-hostname. It would be interesting to try and get it working, as a class
exercise, even if I don't use it. But I'd need to make up my own private LAN
for testing, otherwise as soon as I disabled the Velop's DHCP server I run
the risk of new computers not being able to get IP addresses, until I've got
the Pi DHCP/DNS working.


I've looked at the DNS cache of my Windows 7 PC, and other LAN PCs are not
listed in it, even though the PC can web-browse to all others and RealVNC
client can access the Pis directly (not via cloud) using hostname. So it
looks as if NetBIOS is being used by Windows as the name service for general
name-IP mapping, not just the SMB access for which it was originally
designed.

But there's more. I have an SMB client app (Network Browser, Brandon
Stecklein - from Android App Store) on my Android phone. And after using it
to look at the shares on my Pis, to see if that still worked, name-to-IP
mapping for web browsing and RealVNC client started to work again. I imagine
that the SMB client announced itself on NetBIOS and got replies from all the
SMB-capable computers on the network from which NetBIOS was able to build
its own list. But I'm not going to rely on that. I've modified browser
shortcuts and RealVNC client configs to refer to LAN computers by IP address
rather than hostname, for added resilience.

The strange thing is not that it's failed now, but that it ever worked
reliably in the past without me explicitly (and unwittingly!) make the
phone's NetBIOS force a LAN-wide poll.

[NY]

"Tweed" <usenet...@gmail.com> wrote in message
news:s87pr4$4or$1...@dont-email.me...

> I’ve not read through all the ins and outs of this thread, so apologies if
> this does not help:

Sorry, it *is* all rather convoluted ;-)

> I too have a Velop system. Mine are hooked up to a Virgin Media cable
> modem/router.
>
> By default the Velop system is also configured as a router and DHCP
> server.
> If you want your original router to be in control you need to turn off the
> router functionality in the primary Velop node. This is what I have done,
> so my VM router is the one and only router and DHCP server on my network.
>
> This means the Velop nodes are simply acting as wireless access points,
> though still retaining their mesh network functionality. They work
> extremely well. Ive separated out the naming of the 2.4GHz and 5GHz
> radios,
> so I know exactly what I’m connecting to from the client.

Ah! That's possible, is it? That makes life a lot more simple: one DHCP (and
hopefully one local DNS) server on the router, simpler port-forwarding
rules, everything on the same IP range - I instinctively start to type
"192.168" before I remember that our network uses 10.120.x.x for everything
except the router's config pages. DO you also turn off NAT on the Velop, and
let the router's NAT be the only one, to avoid the problems of double-NAT?

One day when I psyche myself up to it, and after I've made copious notes in
case I have to restore the current setup, I might try turning off DHCP and
NAT on the Velop, and turn DHCP back on at the router. Maybe also dig out my
TPLink router instead of the Plusnet Hub One, since the TPLink was easier to
configure and gave better diagnostics.

I suppose I could name the 2.4 and 5 GHz networks differently and configure
portable devices to connect automatically to either. I imagine most devices
try 5 GHz in preference to 2.4 GHz. As you say, it means it is easy to look
at a client to see which network it has connected to, rather than having to
look in the client list on the Velop app to see this info.

> Allied to your original query, I was much surprised to discover that I
> could VNC to one of my Raspberry Pi computers by using <raspberry pi
> name>.local , eg octopi.local

Yes, I was pleasantly surprised that the RealVNC server package for the Pi
(built into Raspian) has direct LAN connections turned on, given that I knew
this feature was disabled in the free server package for Windows and for
Linux Ubuntu/Mint. Useful because it means I can access more computers than
the five that you can have in your "address book" with the free version of
RealVNC.

> My understanding of tcp/ip started (and probably ended!) in the late 1980s
> with the seminal O’Reilly book, so this .local thing took me by surprise.
> A
> bit of digging led to me discovering multicast DNS
>
> https://en.wikipedia.org/wiki/Multicast_DNS
>
> which seems to be supported by most operating systems.

I'll look into multicast DNS.


My knowledge of TCP was acquired on-the-job when I worked as a software
developer at ICL in the 90s, in a team that was porting an SMB server
package "LAN Manager for Unix" from Intel to SPARC (lots of correcting
hard-coded assumptions about hi-endian versus lo-endian ordering of bytes!)
so as to allow a network of Windows PCs (Windows 3 or Me, with Windows NT
server) to also access UNIX servers "as if they were a Windows NT server".
Ironic that we charged for a product which effectively is the SAMBA package
that is available for free on Linux nowadays.

I can vaguely remember the days before DHCP, when every single PC that
needed to talk to another by name had to have its own HOSTS file (list of
hostnames versus IP addresses) and these all had to be kept in sync by
periodically (manually) downloading an update from a master copy that was
maintained. Woe betide anyone who needed to add another PC to the network
which needed its own IP, and they chose an unlisted one, only to find that
someone else had done the same thing and the addresses clashed. And that was
in the days of thin Ethernet: coax cable that was daisy-chained from one PC
to the next, with a terminator on the far end, with segments of cable joined
by T pieces that connected to PCs. It was almost guaranteed that if anyone
plugged/unplugged a T piece from their computer, there would be glitches in
everyone's comms. The modern star-topology, where every PC is connected by
its own cable back to the router or switch may use a *lot* more cable, but
it's pretty bullet-proof as long as you don't do anything silly like giving
your PC a static PC address which is within the "scope" (range) of addresses
that DHCP allocates, and don't flood the LAN with traffic. I was developing
a solution which used Norton Ghost to send a large disk-image file from a
server to a PC that had become corrupted and needed to be restored to a
factory state. Ghost would use as much LAN bandwidth as it could find. On a
private test network, that's not a problem, but I made the mistake of doing
it on the company LAN and brought comms to a halt - at least in our office
where everything was on the same switch (*). I got Norton to enhance their
product to add a configurable parameter to limit the bandwidth that it used,
so as not to saturate the LAN. At least I wasn't the person who connected a
customer's server to the company LAN, forgetting that the build process
configures a DHCP server using a totally different range of IP addresses -
and two DHCP servers on the same LAN which allocate the same range of
addresses independently of each other, or which use different ranges that
are not routed between each other, is a very quick way to make *lots* of
enemies ;-) You only make that mistake once! After that, we made labels
which we stuck on customer-build servers to warn "do not connect to company
LAN unless DHCP is turned off".


(*) Come to think of it, if it affected everyone, it must have been a hub,
where every port sees all traffic, rather than a switch where what comes out
of a port is restricted to traffic for the computer on the other end of the
cable. Maybe the switch *was* doing its job properly, but the processor
inside it was unable to cope.

[NY]

"Graham J" <nob...@nowhere.co.uk> wrote in message

news:s87sdn$kjh$1...@dont-email.me...

> VNC is irrelevant, it is the name resolution in the local PC that you are
> relying on.
> My understanding of tcp/ip started (and probably ended!) in the late
> 1980s with the seminal O’Reilly book, so this .local thing took me by
> surprise. A bit of digging led to me discovering multicast DNS
> https://en.wikipedia.org/wiki/Multicast_DNS> > which seems to be supported
> by most operating systems.
> So this might work for some clients some of the time.
>
> I suspect that from a PC something like:
>
> ping <name>.local
>
> ... will initially fail, but will after a time invoke mDNS. The PC will
> try whatever other name resolution methods is has (in the order described
> in the link I posted earlier, which might be user configurable). So there
> may be several seconds delay; and it would account for name resolution
> having appeared to work in the past.
>
> So next time you try ping <name>.local it will resolve the name.
>
> If this does behave as I describe, you perhaps should run a startup script
> on every PC to ping all your various devices - this might force the name
> resolution.

I wonder if I change web addresses from martin-pi:9981 to martin-pi.lan:9981
(or martin-pi.local:9981) and likewise for VNC names, it would have solved
the problem. Sod's Law - the bloody thing is working again now on my phone,
possibly since I accessed the RasPi computers by an SMB client and forced
NetBIOS name resolution to build a name-IP list. If it fails again in the
future, I'll try the .lan or .local suffix and see if it makes any
difference. Now it's working, I can't break it (to test .lan or .local) even
by rebooting my phone.

On my Windows PCs, "nslookup martin-pi" fails, but "nslookup martin-pi.lan"
works as expected (but .local does not). Probably using mDNS rather than
DNS. (*) Interestingly, "ping martin-pi" returns its IPv4 address but "ping
martin-pi.local" (or .lan) returns an IPv6 address. I didn't even know I'd
got IPv6 turned on at my Win 7 PC till I looked just now.

IPv6 is a great wasted opportunity. It should have remained as a WAN-only
addressing system, so PCs on a LAN still use IPv4 addresses in a private,
non-routable range which is NATted to either IPv4 or IPv6 on the WAN. It is
WAN addresses which are in short supply. With a default 255.255.255.0 Class
C LAN address, you have 253 device addresses (**) which is usually enough
(though all these internet of things devices start to use up addresses! With
a 255.255.0.0 Class B LAN address, you can have 64K computers - probably
enough for most organisations on the same WAN connection :-) But IPv6 does
away with the concept of NAT, and the protection it gives, and places more
of the firewall onus on every single computer. It also uses unwieldy 8-byte
addresses which are more difficult to memorise and to refer to in speech
than 4-byte IPv4 addresses. There is a tendency to refer to an IP address
colloquially as "dot 47", with the "192.168.1" being assumed if you are on
the same subnet. I wonder if IPv6 addresses of computers on the same LAN are
as neatly organised that you only need to quote least-significant byte(s) to
be unambiguous within the LAN. When looking at a LAN trace (Wireshark) it is
trivially easy to distinguish a LAN address (which starts 192.168.x.x or
10.x.x.x) from a WAN address which starts with anything else, and which is
often mapped to the gateway address of the router which says "this is
to/from the outside world".

Or am I being an old dog, not willing to learn the new tricks of IPv6 as it
is actually implemented?



This whole saga has proved one thing: there are times when simply solving a
problem with a workaround (eg changing hostname to IP address) isn't the
ending point, and geeks with enquiring minds have to go one step further and
investigate what is/isn't happening behind the scenes. ;-)



(*) Time to look in Wireshark at what each address notation generates in LAN
traffic.

(**) 256 minus .0 and .255, and also a reserved address for the router's
config page, typically .1 or .254

[Tweed]

Graham J <nob...@nowhere.co.uk> wrote:
> Tweed wrote:
>
> [snip]
>
>> Allied to your original query, I was much surprised to discover that I >
>> could VNC to one of my Raspberry Pi computers by using <raspberry pi>

>> .local , eg octopi.local
>
> VNC is irrelevant, it is the name resolution in the local PC that you
> are relying on.
> > My understanding of tcp/ip started (and probably ended!) in the late
> 1980s> with the seminal O’Reilly book, so this .local thing took me by
> surprise. A> bit of digging led to me discovering multicast DNS> >
> https://en.wikipedia.org/wiki/Multicast_DNS> > which seems to be
> supported by most operating systems.
> So this might work for some clients some of the time.
>
> I suspect that from a PC something like:
>
> ping <name>.local
>
> ... will initially fail, but will after a time invoke mDNS. The PC will
> try whatever other name resolution methods is has (in the order
> described in the link I posted earlier, which might be user
> configurable). So there may be several seconds delay; and it would
> account for name resolution having appeared to work in the past.
>
> So next time you try ping <name>.local it will resolve the name.
>
> If this does behave as I describe, you perhaps should run a startup
> script on every PC to ping all your various devices - this might force
> the name resolution.
>

I know that VNC is irrelevant - it’s just the way that I discovered that
multicast DNS was a thing. There’s no delay, it just works:)

[Tweed]

NY <m...@privacy.invalid> wrote:
> "Tweed" <usenet...@gmail.com> wrote in message
> news:s87pr4$4or$1...@dont-email.me...
>> I’ve not read through all the ins and outs of this thread, so apologies if
>> this does not help:
>
> Sorry, it *is* all rather convoluted ;-)
>
>
>> I too have a Velop system. Mine are hooked up to a Virgin Media cable
>> modem/router.
>>
>> By default the Velop system is also configured as a router and DHCP
>> server.
>> If you want your original router to be in control you need to turn off the
>> router functionality in the primary Velop node. This is what I have done,
>> so my VM router is the one and only router and DHCP server on my network.
>>
>> This means the Velop nodes are simply acting as wireless access points,
>> though still retaining their mesh network functionality. They work
>> extremely well. Ive separated out the naming of the 2.4GHz and 5GHz
>> radios,
>> so I know exactly what I’m connecting to from the client.
>
>
> Ah! That's possible, is it? That makes life a lot more simple: one DHCP (and
> hopefully one local DNS) server on the router, simpler port-forwarding
> rules, everything on the same IP range - I instinctively start to type
> "192.168" before I remember that our network uses 10.120.x.x for everything
> except the router's config pages. DO you also turn off NAT on the Velop, and
> let the router's NAT be the only one, to avoid the problems of double-NAT?

Yes it is possible. The magic phrase is “bridge mode”

https://www.linksys.com/us/support-article?articleNum=243548

That turns off all router type functions, so no NAT, dhcp, firewall etc. So
conceptually your Velop nodes are just extensions of your original router’s
LAN. So treat any client connected via a Velop Wi-Fi link as though it were
connected to your router’s LAN, which is exactly what is happening.

It’s not obvious to me why bridge mode isn’t the default. I imagine that
99% of users will plug their system into an existing home router. If you
haven’t already done so, it’s a good idea to turn off the router’s own
WiFi.

[NY]

"Tweed" <usenet...@gmail.com> wrote in message

news:s883p2$dq2$1...@dont-email.me...
> NY <m...@privacy.invalid> wrote:
>> Ah! That's [turning off Velop DHCP] possible, is it? That makes life a

>> lot more simple: one DHCP (and hopefully one local DNS) server on the
>> router, simpler port-forwarding rules, everything on the same IP range -
>> I instinctively start to type "192.168" before I remember that our
>> network uses 10.120.x.x for everything except the router's config pages.

>> Do you also turn off NAT on the Velop, and let the router's NAT be the

>> only one, to avoid the problems of double-NAT?
>
> Yes it is possible. The magic phrase is “bridge mode”
>
> https://www.linksys.com/us/support-article?articleNum=243548
>
> That turns off all router type functions, so no NAT, dhcp, firewall etc.
> So
> conceptually your Velop nodes are just extensions of your original router’s
> LAN. So treat any client connected via a Velop Wi-Fi link as though it
> were
> connected to your router’s LAN, which is exactly what is happening.
>
> It’s not obvious to me why bridge mode isn’t the default. I imagine that
> 99% of users will plug their system into an existing home router.

Yes almost everyone will be adding Velop to an existing router, given that
the Velop doesn't include its own ADSL/VDSL modem for direct connection to a
phone lin. I initially wondered whether it might, and careful pre-sales
reading of literature proved that it didn't. I do wonder whether Velops
ought to be sold in two forms: with and without an xDSL modem, so you buy
one with a modem and n without.

Bridge mode sounds a damn good idea. I'll investigate it. Makes life a lot
simpler - which is always a good idea. Who knows, my router might even
implement "real DNS".

> If you haven’t already done so, it’s a good idea to turn off the router’s
> own WiFi.

Yes, one of the first things I did before running the Velop configuration
was to disable the router's wifi so there was only a single SSID and nothing
else within the house was using any of the precious 2.4 GHz channels.


Before I got Velops, I investigated power-over-mains Homeplug devices to do
the backhaul between access points. That was a dead loss. Our house has two
"fuse boxes" to cover circuits in different parts of the house. They both
lead back to a common meter and company fuse, but I'm not sure how they are
connected. Suffice it to say that backhaul between different ring mains on
the same fuse box was pretty ropey in terms of speed and dropped pings, and
from one fuse box to another it got worse than that. But the backhaul wiring
is already in place (as ring mains wiring) so it's a shame not to use it *if
it works*. When I found it didn't, and Ethernet up in the loft was going to
be a pain (especially neatly running cables from ceiling to sockets in
rooms), I considered Velop.

I'm still not sure whether I need all the nodes. I have six, of which one is
the primary that can see four of the others by direct connection, and only
one needs to connect via daisy chain rather than directly. I suppose that's
pretty good going, but can I eliminate a node somewhere and move others
around so they are still covering all the areas of the house and can still
see the primary? If I could remove a node, that would be one less 2.4 GHz
channel used so there may be less problem at simultaneous reboot (after
power cut) while they all try to auto-negotiate 2.4 channels.



Can I check something which I've never known for certain? This is assuming I
*am* using the NAT in the Velop. Am I right in constraining myself to
connecting all computers via one of the Ethernet ports on the primary node
(maybe via switches), and *only* connecting one port on the router - to the
other port on the primary Velop? Or would the situation as regards NAT and
firewalls be the same if some computers were connected by the other Ethernet
sockets on the router?

[Tweed]

I can’t really,help you on the last point as I’ve only ever used bridge
mode. It seems to be a very bad idea to chain NAT routers.

I’m surprised you need 6 units - you must have a very big house or have rf
proof internal construction. Three units floods my property. My first floor
floors are wooden, which appears to be transparent to 5GHz. I’ve found that
the best coverage is obtained by placing the units in the first floor
rooms. Ground floor rooms then get coverage through the ceiling. I’ve
placed one of the units on a small box on the rear room window sill, so it
looks directly through glass to the garden. This gives perfect coverage
across the back garden.

[Graham J]

NY wrote:

[snip]

> Can I check something which I've never known for certain? This is
> assuming I *am* using the NAT in the Velop. Am I right in constraining
> myself to connecting all computers via one of the Ethernet ports on the
> primary node (maybe via switches), and *only* connecting one port on the
> router - to the other port on the primary Velop? Or would the situation
> as regards NAT and firewalls be the same if some computers were
> connected by the other Ethernet sockets on the router?

If you use NAT in the Velop, it function as a router. It therefore has
two Ethernet connections: one for its LAN (which may have several
sockets) and one for its WAN. The LAN connection also includes the WiFi
access point. The DHCP service implements the 10.120.x.x network on the
LAN. There would be no problem in connecting any computer to any of the
LAN sockets on the Velop. How many are there?

The WAN connection on the Velop you use for the cable to the (Plusnet?)
router. The Plusnet router has its own DHCP server and creates its own
LAN on 192.168.1.x

From a PC on the Velop LAN you can connect to the router, simply by IP
address (probably 192.168.1.1). The PC identifies (by subnet mask) the
192.168.1.x address as being external to the Velop LAN, so sends the
packets to the default gateway (i.e. the Velop itself). There the Velop
passes packets through NAT (by editing them) to its WAN port and
therefore to the Plusnet router. Reply packets arrive at the Velop WAN
port and are recognised by the NAT translation table as being in
response to valid outgoing packets so are edited and sent to the
originating PC.

You could connect another PC directly to the Plusnet router. It would
see the internet etc. perfectly OK. From the Velop LAN you could
communicate with that PC as described above for the router. **BUT** the
reverse would not be true; no PC on the Plusnet router's LAN can see the
Velop LAN. There might be circumstances where this is intentional, but
I doubt it in your circumstances.

So yes, you have your system configured appropriately.

You could reconfigure it either as:

a) Velop as switch (so no DHCP) and connect Plusnet router to Velop LAN
port;

b) Velop as router and Plusnet router as modem only (aka bridge mode)

The choice depends on the router features. My guess is that the Velop
as a router may be better and there may be hidden WiFi features that
rely on its configuration as a router, so the Plusnet router should be
configured in bridge mode. This means that you edit the Velop's WAN
settings to include the Plusnet login name and password.


--
Graham J