Hub Two not resolving local host names

[#1]

On my Hub Two I can see the host names of all connected devices when I go into Home -> My devices page of the hub's manager. However, none of these devices can contact each other by their host names. So it would appear that the Hub Two isn't resolving the local hosts. 

My IPv4 configuration is attached as a screenshot.

When I was on PN FTTC I used my own router and it was able to resolve local hosts so I'm assuming there is some configuration I am missing.

[#2]

@ksaro1 are you saying your windows devices are not discovering other windows devices?

See here

Dan

[#3]

I have a vague recollection that the actual device hostname stored in the hub's config is not necessarily the same as the 'friendly' name visible in the network map.

If this is the case, then I wouldn't expect you to be able to communicate with other LAN devices using the name that is displayed (assuming it's possible in the first place).

Assume you are using the hub for DNS resolution?

Edit: I've answered my own question by looking at your screengrab - you are not. You are assigning Cloudflare's DNS addresses to local devices via DHCP. This means anything connected the the hub will be going direct to Cloudflare and Cloudflare has no awareness of your local network.

[#4]

---

@Dan_the_Van wrote:

@ksaro1 are you saying your windows devices are not discovering other windows devices?

See here

Dan

---

No. None of my devices are WIndows. I can see all devices if I use their IP address. I can't see them if I use their host name.

For example, I have a USB stick attached to my TP-Link access point (AP). The  AP has a host name on the home network. But if I try to access the USB storage from my Mac or Raspberry PI using the host name it's not found. I have to use the IP address, which is OK for this device since the AP is ethernet connected and therefore has a static IP address. However, my Raspberry PI is wireless, so each time it reboots it gets a new IP address.

[#5]

---

@bobpullen wrote:

Edit: I've answered my own question by looking at your screengrab - you are not. You are assigning Cloudflare's DNS addresses to local devices via DHCP. This means anything connected the the hub will be going direct to Cloudflare and Cloudflare has no awareness of your local network.

---

Yes, that is correct. However, when on the FTTC service with PN and using my own Billion router, I also pointed that router to Cloudflare's DNS nameservers. However, for the internal network the Billion resolved the names of hosts since no external DNS server would know the local names. I would assume/hope that the Hub Two router had a similar function in that it could/should resolve the hosts on the local, 192.168.1.xxx, network and pass other requests to the Cloudflare DNS nameservers.

What i'm saying is that all worked fine before my move to Full Fibre and the Hub Two router. And I'm hoping I can achieve the same with the new set up somehow.

[#6]

The Billion router may have handled the DNS assignment differently by allocating the Cloudflare addresses to the WAN interface. In this configuration, local devices would still use the Billion router for lookups which would then get forwarded to Cloudflare where appropriate.

This is not how the custom DNS implmentation on the Hub Two works.

You could elect to give all of your devices static DHCP assignments so the local IP doesn't change and then reference devices by IP instead. If you must use hostnames then you could achieve something via local host file entries on each machine or run something like Pi-hole on the Raspberry Pi and have that look after DNS (with Cloudflare as the upstream resolver).

[#7]

---

@bobpullen wrote:

You could elect to give all of your devices static DHCP assignments so the local IP doesn't change and then reference devices by IP instead. 

---

See attached screenshots. For some reason on my Hub Two it looks like you can't have DHCP assign static IP addresses to a wireless connection.

[#8 · Accepted solution]

Is the host PITV the same hardware with randomise MAC address switched enabled? You'll need to disable to keep the same IP Address, new MAC address will result in a new IP Address

or do you have two PITV. I never like having the same hostname as its confusing

Dan

[#9]

---

@Dan_the_Van wrote:

Is the host PITV the same hardware with randomise MAC address switched enabled? You'll need to disable to keep the same IP Address, new MAC address will result in a new IP Address

or do you have two PITV. I never like having the same hostname as its confusing

Dan

---

Ok, I checked and the RPI4 randomises the mac address by default. I've now configured it not to do this and I'll reboot and then set the new mac address's IP address as the static IP address.

However, the uploaded screenshots show that even for the existing mac address, the Hub Two router doesn't actually save the change to the DHCP assignment. It's hard to show just with the screenshots, but the sequence was 

1. Changed the DHCP assignment to be permanent
2. Saved the change.
3. Re-listed the devices
4. re-selected the pitv device
5. it showed the DHCP assignment had reverted to Always use this IP address as No.

[#10]

I will admit I gave up with the Hub Two, I needed something more configurable which also supported a mesh system, I also found the DHCP GUI rather clunky and caused me unnecessary frustration while attempting to set up static IP Address.

Does the issue still happen now you have a static MAC address?

Edit: I would delete any duplicate entries keeping the real (current) MAC address

[#11]

...bosh... OK, configuring the RPI4 to use a static mac address did the trick. Oddly too, the Hub Two seemed to detect this and it automatically set the Always use IP address to true. Bizarre.....

Yes, I think the Hub Two is very primitive compared to many routers out there in terms of its capabilities. However, I am sticking with it for now because its 5gHz antennas have a much better coverage than any of the other routers I've used so far. I've had Netgear, Billion, TP-link and the old sagemm one from PN and they all failed to cover as much of my property with 5gHz as the Hub Two. However, they all (other than the old PN one) had many many more functions than the Hub Two does.

Once I start getting wifi 6/6E devices I may rethink the use of the Hub Two though.

Thanks for the tips!

[#12]

CORRECTION - I discovered that my local computers were bypassing the Hub Two for DNS resolution. Once I pointed all local computers to my Hub Two then local name resolution, as well as global name resolution, worked as expected.

[#13]

...What steps did you take to direct all your computers at the Hub Two for DNS?

TIA

I just received my new Hub Two router today. It started up and worked easily, but I am finding similar types of problems. 

On my Win8 notebook with the Technicolor TG582n router I used to be able to ping the router by name as 'router' (or 'dsldevice.lan' - the latter seemingly something to do with the OS or router) whereas now I seem only to be able to ping the router by IP address. It's hosts file is the default with no entries added by me. (So how did it do it?)

Also, if I try to telnet to the new router all I get is: "Connecting To 192.168.1.254...Could not open connection to the host, on port 23: Connect failed"

Is there anything that can be done about this?

[#14]

@pvmb 

The Hub 2 doesn’t support Telnet instructions.

Why would you need multiple ways to ping your router?

[#15]

Telnet not available on Hub Two? Oh dear! that means we are stuck with what we can/can't do via the configuration web page. Unless we can download configuration/edit/upload configuration file.

Why would I not want to ping devices by name? That's what DNS is for... I have no idea where the notebook picked up it's names for the old router, it just did it by itself.

Actually, I am confused now over what exactly I could do and what I couldn't (I also have a very old networked HP LaserJet with a fixed IP). I think I may have to temporarily restore the TG 582n as the router to check out exactly what I could do.