Linksys Velop network: changing from "automatic DHCP" to "bridge" mode removes ability to see which nodes are connected

[martinund]

I used to have my Linksys Velop nodes configured as Automatic DHCP, with the primary node connected by Ethernet to a router (a TPlink TD9980) which was acting as an ordinary NAT/DHCP router. To avoid double-NAT problems, I've now put the Velop system into bridge mode which turns off its NAT and DHCP, with those functions being performed only by the router.

Everything appeared to be working fine, but I've just noticed that nodes which used
to connect automatically to each other now have to be turned on one at a time, when (with
a couple of exceptions) the same nodes in the same locations used to connect
automatically if the system was rebooted or all the nodes turned on at the
same time after a power cut. Failure to do this means that all/most of the nodes stay in flash-red state.

Also, the Linksys app, talking to the Velop network, does not give "disconnected" indications
for other nodes so there is no easy way to tell whether a node has gone offline, other than by
walking around and looking at the lights - or waiting for people to say "there isn't a good
signal in this room".

This came to light because I accidentally turned the router off (I dislodged
its PSU from the wall socket) and so the Velop had nothing to talk to. All
the nodes had then gone into flashing-red-light mode and simply rebooting
the primary node did not fix it.

Does bridge mode affect the ability of nodes to talk to each other and to
handle the common situation where the nodes are positioned far enough away
that they are just within the limit of 5 GHz connectivity, which means that
there is a lot of overlap of longer-range 2.4 GHz and therefore competition for free
channels. It's a crying shame that the Velop nodes can't have 2.4 turned on
selectively so it's only on for the nodes which have devices nearby that
cannot talk 5 GHz.

 

[mickevh]

There's no good reason why switching the method by which traffic is forwarded to the rest of the network (bridged or routed) should affect any of the Wi-Fi functionality as the two are unrelated. However, in a consumer product sold on a "appliance" basis, there's no way to know for sure unless you ask the manufacturer. The software that's handling the Wi-FI functions and the software that's handling the network functions may or may not have been written by the same people, may or may not be "integrated" and so on. It's possible the "connection status" could be hanging off the DHCP functionality and if your Velop is not handling DHCP itself, maybe it's not too clever at monitoring presence of other nodes. (I wouldn't design it this way, but I can see why someone would.) But I'm just guessing, in the absence of information from the Velop development team, it's all we can really do.

If you've literally only just made the change, you might like to leave it for a day as the IP addressing will have changed and that can take (typically) 12-24 hours to sort itself out. So maybe leave it alone for a day and come back and test again. (I would also "fix" the DHCP Leases the Wi-Fi nodes use so they always get the same IP address.)

I suppose you could de-mount the AP's and test them closer together in a "lab" environment, but obviously that's a real ball ache if they are more or less permanently installed.

If your nodes are so far apart they are only just getting connection, then maybe they are too far apart in the first place. Of course, getting out the drill and putting in "proper" wired backhauls negates the problem (and is faster and more reliable)

You are correct that 2.4GHz propagates further than 5GHz - that's just simple physics, low frequencies get through stuff better than high frequencies. Thusly channel planning is harder for 2.4Ghz, not least because there's much less frequency spectrum available in 2.4GHz in the first place, (effectively only 3x20MHz channels are available.)

Unfortunately, the granularity of control available in cheap SOHO kit is much less than availed in professional equipment because the expectation is that SOHO users lack the expertise to set anything up for themselves and just want a turnkey solution. We just have to be a bit "zen" about that and if we want more toys to play with, they we are probably going to have to put our hands in out pockets and buy something more feature rich, which will probably cost a bit more, and be prepared for the learning curve involved in understanding how to use it.

 

[martinund]

Yes I've only just made the change. I spent several weeks a couple of years ago working out the best positions of the nodes using the Linksys app so they weren't too close together: using the shorter-range frequency for the backhall is a bugger because you have to have the nodes close enough together that they can all see the primary node and ideally neighbouring ones can see each other so there is an opportunity for daisy-chaining if a node loses its first-hop connection to the primary node. But that means great overlap at 2.4 GHz, and there are only three channels 1, 6, 11 which are non-overlapping so any auto-channel-selection algorithm is going to complain. I'd turn off 2.4, but we've got some security cameras that only talk 2.4, and also occasionally laptops and tablets drop back to 2.4 if they aren't close enough to a node for 5 GHz: slower 2.4 is better than total loss of connection in 5 GHz dead zones.

Unfortunately my house has thick walls (internal as well as external) so I need six nodes to give coverage in all the rooms where it is needed, as well as into the garage and part of the garden so things like Alexas (for "drop-in" intercom) and phones (for occasional browsing while sitting in the garden). I also need to position the Hive bridge (which can only be connected by Ethernet) so it can simultaneously see the Hive boiler-controllers and the Hive thermostats (two of each for two different central heating zones) so that restricts where one of the nodes can be placed.

But I though I'd got it all worked out. When there's a power-cut, all the devices turn on simultaneously and I presume this is why some nodes don't connect automatically. But I had got used to which nodes (only two of them) needed manual intervention.

But after I changed the Velop system from DHCP/NAT to bridge (where they use the parent router's NAT/DHCP) all the nodes are reluctant to connect: even the primary one would not turn blue (everything OK) and remained at flashing red (can't connect). I had to turn all the nodes off and then turn every one of them on separately, waiting for it to connect before I could turn the next one on.

It's annoying because it was working so well (with the proviso about two nodes needing a bit of hand-holding) but after a couple of years of everything working fine, and without making any chnages that I'm aware of, I started to get isolated instances of some devices failing to browse to some web sites (timed out as if no response): my Android phone wouldn't access some external webspace that we rent, and my wife's iPads wouldn't access a web server on a Raspberry Pi which is within our LAN so it doesn't even involve external DNS and WAN, and this was being accessed by its IP address rather than its domain name address.

When I asked on forums, people said that the double-NAT setup might be to blame. I originally wanted to configure the router as a bare modem, and keep the NAT/DHCP settings on the Velop which I changed to PPPoE mode, but I couldn't get the router (modem) to connect to the ISP, so evidently the username/password/VPID that I'd been using successfully when the router was acting as a router, weren't being fed correctly when I instead configured them on the Velop. So I reverted to Plan B: keep the router as a NAT router and put the Velop into bridge mode.

Ethernet, at least between mesh nodes, would be so much better, but it would involve trying to route cable through the loft and then (the hard part) feeding cable from the ceiling down the wall to a node while not making a mess of the wallpaper etc. The alternative is to run Cat 6 tucked down between carpet and skirting board and through doorways.



I agree that changing from Auto DHCP to Bridge shouldn't affect wifi node-to-node comms at all. And I can't see why Linksys should have made it disable the info about which nodes are connected together and the flagging of a node which has lost comms. But for some reason it has done.

I'm tempted to go back to Plan A (DHCP/NAT on Velop, TPlink router as modem-only) if I can find out what I might have configured wrongly. It's a shame that the PPPoE credentials have to be supplied by the Velop rather than remaining as they were previously, defined on the router, but just turn off NAT and DHCP. But the TPlink doesn't allow those to be disabled individually, only as a package called Bridge Mode. And there's very little documentation about how to do it. I'd be happy to keep playing, but I keep getting "how much longer is the internet going to be down" hints from my wife.

 

[mickevh]

I don't think I've ever heard of a SOHO router that will let users just turn NAT on/off - though I don't see much SOHO kit. Unfortunately the NAT needs to be in the device that terminates the ISP link due to IP address exhaustion, so I guess we're just stuck with that.

You might want to persist with getting your Velop to perform the PPP sessions initiation and maintenance if that looks like the better solution. It might just be a case of finding the correct credentials and/or setting for your ISP. Maybe have a hunt around the ISP forum for your ISP (IIRC there are some here at AVF.) However, you might need a "router" that has a "modem mode" to make it fly - I'm not sure "bridge mode" would do, though it depends somewhat on what the vendor means by this as it's a bit of an overloaded term.