The remotes broadcast on the network (collision domain).
So remotes should find the Core without knowing it’s IP address.
I suspect the Core is not on the same subnet.
… but need more info to be sure.
1 Like
Maybe it’s on a fixed IP, so it does not work with the new router?
1 Like
That may well be the case.
Many routers refuse to work with devices with a fixed IP address. Fine with a DHCP reservation from the router, which is how it should be done…
This is not correct.
If the ip address is valid than a router does not care.
A valid ip in the correct subnet configured correctly will be routed if destination is not local.
Usually the core and remote do communicate without the router involved.
When a router wil not send a packet to another network there is something wrong with either the router or the network infrastructure/configuration.
Sorry, but it is. I replaced the router functionality of my ISPs modem/router with an Asus router and put the ISP’s unit inmodem mode.
All of the IP addresses were of the 192.168.1.xxx subnet. The ISPs router was a pain to fix IP addresses, so I allocated a couple of devices fixed IP addresses within the devices themselves.
The Asus router wouldn’t allow the devices with fixed IPs to connect to the internet. A DHCP reserved address on the other hand, worked just fine. Another Asus router behaved in the same way.
Then the router is not funtioning properly if it behaves that way. Routers can not have opnions about packets they have to route, if the source and destinations are valid they just have to do what they are suppost to do.
Dhcp assigned or configured manually, valid is valid.
I have moved these posts from a #support thread because this discussion offered no assistance to the OP. Please keep in mind that support threads are there to assist a user, and not to debate the internal working of a router. Thanks.
Who knows, maybe Asus routers have security functionality that stops them routing to devices to which they haven’t allocated the IP address within the network subnet?
1 Like
Was this topic broken out from somewhere else? The OP seems like half a thought but I’ll give it a go.
This is correct and the discovery will discover the IP Address. However, that doesn’t mean the client and the core can actually communicate. For example, if the Core isn’t configured correctly it could return an IP the Client cannot reach. Discovery is one step but IP+TCP is still required to function.
A packet capture at the client can help here so you can see what IP the Core is advertising.
That would be kind of strange, really, and there should be a way to turn it off. Serving up IP addresses isn’t a required functionality for the router (most I know allow you to turn DHCP server off altogether).
I appreciate that you can turn off DHCP functionality. The Asus routers in question were the DHCP servers for the network. For some reason they didn’t seem happy with an IP address that they hadn’t allocated…
It does seem kinda weird. The only way I ever allocate a “fixed” IP address now is to set up a DHCP reservation based on the device’s MAC address.
The Ubiquiti UDM Pro I’m now using allows me to “ban” certain devices from the network based on the MAC address.
Kinda cool feature - if you have kids, you can turn off their internet access at bed time!
You can also set up wi-fi networks with schedules to do the same thing.
They shouldn’t be happy with an address which matches the pool(s) for that zone.
But, statically assigning an address from a DHCP pool directly on a device is poor practice so I kind of agree with Asus here (if, in fact, that is what we’re talking about).
If one wants to assign addresses statically, on the device, they need to shrink their pool and grab an address which is outside of the pool. This is (predominantly but not entirely) why, if you run DHCP for address allocation of an IP subnet, you want to use static allocations in the zone and not config at device. Then the DHCP server can manage the pool correctly and you avoid potential chaos.
1 Like
Most routers I’ve seen allow you to white- or blacklist MAC addresses, at least within some reason.
If you are using DHCP server on the router, and do not (as mentioned by @ipeverywhere ) assign static addresses from outside the DHCP pool, then yes, MAC reservation is the proper way of doing it. But unless there is an IP address collision, router still should route packets properly regardless of how that address was assigned…
2 Likes