Some LAN IPs stopped working with Giga Hub

[trolley]

I have a Giga Hub with IP 192.168.2.1. I have a Linux PC plugged into the Giga Hub with an ethernet cable, and statically assigned IP 192.168.2.2 which is outside the DHCP range.

This worked fine for a while, then out of the blue the Linux PC was having internet connectivity issues and I found that from the PC I couldn't ping the Giga Hub IP. I couldn't find any good reason why, and out of desperation changed the static IP assigned to the PC and it started working again. I thought that was weird, so I tried switching the static IP back to 192.168.2.2 and sure enough I couldn't ping 192.168.2.1 anymore.

I went to another computer, a wi-fi connected Mac, and manually assigned it IP 192.168.2.2 and sure enough, same thing: it can't ping 192.168.2.1. 192.168.2.2 is simply unusable on my LAN now to get internet access.

Even stranger, other devices on the network can ping 192.168.2.2 fine so that host is up and reachable on the network, but can't communicate with the Giga Hub. The same problem happens in reverse as well: using the ping tool in the Giga Hub web interface can't ping 192.168.2.2.

This was a while back, and now the same thing has happened again. The updated static IP address I'd assigned to the Linux PC can no longer be used on my LAN either. Pings to the Giga Hub from any device that has that IP assigned to it don't work, and the Giga Hub can't ping it.

I'm stumped. I think I understand this stuff, but have no idea how two devices on the same subnet can't see each other.

[Vanadiel]

192.168.2.1 is the default gateway

DHCP range has a start and end address. Typically 192.168.2.2 would be the start of the DHCP table.

Not sure why you want to use a static assigned IP on your Linux box, but you have to make sure the starting address of the Home hub's DHCP server is 192.168.2.3 or higher, to avoid a network collision by having 192.168.2.2 assigned twice on your network (1 time static and 1 time from DHCP server assigned device).

Each device needs it's own IP, and by the sound of it you sometimes have 192.168.2.2 assigned twice.

[trolley]

I have a handful of devices I want to assign static IPs to so I changed the DHCP lease range to 192.168.2.100-192.168.2.254.

[Vanadiel]

Even stranger, other devices on the network can ping 192.168.2.2 fine so that host is up and reachable on the network, but can't communicate with the Giga Hub.

So what host is assigned that IP? I noticed you also have issues with your pods, so I am thinking you have a network configuration error somewhere in your setup.

[trolley]

I also just used the arp command to check from the Linux box and there's no entries with the same IP so there shouldn't be any other device on the network with that IP.

Also, during my troubleshooting when I had left the static 192.168.2.2 IP on the Linux system then tried to also assign it statically on the Mac I got an error on the Mac that it was already in use. When I disabled it on the Linux system I didn't get that error on the Mac, but got the same problem symptoms: no internet access, and unable to ping 192.168.2.1.

I was just on the phone with Bell tech support and they're raising a level 2 support ticket about it, so if I get a useful update that way I'll post it.

[trolley]

I've been having nothing but problems with the pods. They haven't worked right since I got the Giga Hub. Before that I had a HH 2000 with 2 pods and they all worked fine with all the same configuration. All my problems started since I got the Giga Hub.

And this particular problem started spontaneously. Everything had worked fine as it was configured until all of the sudden it didn't, with no changes made.

[Vanadiel]

The MAC address in the ARP table will show the MAC of the device that is assigned 192.168.2.2

arp -a 192.168.2.2

You should then be able to find out the device since each MAC address should be unique. If you have cloned a MAC address somewhere that can also lead to issues.

Remember that local communication between devices is based on MAC address, not IP address. IP address is only used when you communicate with a device on another network.

[trolley]

On the host with that IP:

❯ arp -a 192.168.2.2
arp: in 35 entries no match found.

[trolley]

Reading some threads on Reddit narrowed it down I think. The problem IPs are ones that I tried to set as the DNS servers in the Giga Hub DNS config. I run Pi-Hole and want to use it as my DNS server on my LAN, so I put the IP address of the system running it in the Giga Hub DNS settings. When I did that, that IP loses ability to communicate with the Giga Hub somehow. I tried switching the Pi-Hole system's IP a few times and trying each one in turn in the Giga Hub DNS settings and every time I did I'd eventually not be able to ping the Giga Hub from the Pi-Hole system again.

[ZaneP · Accepted solution]

You can't run a DNS server successfully on the Giga Hub. Bell has possibly put in routing rules which require the Giga as the primary DNS resolver. So the Pi-Hole can't be on your LAN (with a local IP address) and configured as the DNS server.

You could attach your Pi-Hole to the Giga, configured with PPPoE (if you're in Ontario or Quebec). Turn off DHCP on the Giga and use the Pi-Hole for DHCP and DNS requests. But that opens up the issues that come with PPPoE or DMZ configuration when attaching a separate router. There's no true bridge mode on the Giga Hub.

I do need to add that the Bell Community Forum is primarily a user-to-user q&a setting, to help on issues relating to Bell services. We don't get too deep into issues involving our own network gear connecting to Bell-provided equipment. Reddit r/Bell has a discussion on exactly your problem.

Let us know how it goes. Good luck!

[trolley]

Totally understood. I moved the question to Reddit.

[irowell]

Just one question for this. If this has happened to us, how do those IP addresses get unblocked? Only through factory reset?

[trolley]

I am no longer a Bell customer, but if I remember right some amount of time without that IP set as the DNS server would allow it to start working again, but I can’t say how long. No factory reset was required.