New Access Point installed on home LAN - I'm lost

[YrbkMgr]

I can't emphasise enough that using static IP addresses within the DHCP pool is asking for trouble.

With a pool of 2 to 254 and three camera's there is a 3 in 253 chance that the first DHCP client will get assigned a conflicting IP address. When the second DHCP client connects there is a 3 in 252 chance. The third client, a 3 in 251 chance, etc, etc.

If you really want to do this then you should create a DHCP reservation for each of the cameras on the router. Go to LAN - DHCP Server, enable Manual Assignment and add an entry for each cameras MAC address with its appropriate IP. This has two benefits. First, if you accidental/deliberately change the camera to DHCP it will still get the same IP address. Second (and more importantly), even if the camera isn't using DHCP by reserving its IP address it stops the router giving that address to another client.

Naw, you're right. I don't have Zen with networking (obviously) and if that is your "best practices" recommendation, I'll do that. Eliminate the variables as it were...

Stay tuned...

 

[YrbkMgr]

I can't emphasise enough that using static IP addresses within the DHCP pool is asking for trouble.

With a pool of 2 to 254 and three cameras there is a 3 in 253 chance that the first DHCP client will get assigned a conflicting IP address. When the second DHCP client connects there is a 3 in 252 chance. The third client, a 3 in 251 chance, etc, etc.

If you really want to do this then you should create a DHCP reservation for each of the cameras on the router. Go to LAN - DHCP Server, enable Manual Assignment and add an entry for each camera's MAC address with its appropriate IP. This has two benefits. First, if you accidental/deliberately change the camera to DHCP it will still get the same IP address. Second (and more importantly), even if the camera isn't using DHCP by reserving its IP address it stops the router giving that address to another client.

I got everything back to the way it was before the issue of two IP addresses assigned to the same MAC as seen from the router client list. I used different software to access the camera (.160) and saved the necessary changes using *that* software. I brought down Jurassic Park --> all systems go - one IP address one MAC for that camera on the router's client list. So this convinced me of two things: My camera brand is shirte (long story)... and I should really configure my LAN properly as you have been emphasizing. It's just not practical - it would be starting from scratch and take days.

If I create a DHCP reservation for 5 specific clients instead, what are the downsides?

 

[ColinTaylor]

If I create a DHCP reservation for 5 specific clients instead, what are the downsides?

None. You just need to remember to update the reservations if you change the IP addresses of those clients.

I don't know anything about cameras so I'm curious why changing their IP addresses would "take days". Presumably it's not actually the changing of the addresses (which you've already been doing) but some other part of the system that would need to be reconfigured?

 

[YrbkMgr]

None. You just need to remember to update the reservations if you change the IP addresses of those clients.

I don't know anything about cameras so I'm curious why changing their IP addresses would "take days". Presumably it's not actually the changing of the addresses (which you've already been doing) but some other part of the system that would need to be reconfigured?

As is likely abundantly clear, I'm not a "network guy" - Ever since my first LAN in Windows 3.x, it's been the literal definition of "ad hoc". Plug stuff in, guess and check - learn on the fly. Kind of a "if it ain't broke" mentality, although fully aware that it's ad hoc.

I exaggerated by saying "3 days", but functionally, I'll have to make sure nothing broke. I'll be changing the IP addresses of six clients - And if something happens that I don't understand, I won't know if it's because of my change or something else that I don't understand. Here's how dumb I am about networking - if I launch my Plex app on the FireTV Stick and it says that it can't find the server... whatever I'm doing has to stop to figure that out and if it was caused by my change. And for the cameras, that means my monitoring is "down" until I resolve it - I hate that and I can't be down for a day while I figure it out. (chuckling) I can fix things, but neither look forward to nor take pride in it.

Here's an image of the security software, Blue Iris, with my three cameras. Once the IP changes I'm going to have to reconfigure BI to find them. BI also acts as a server for being able to access the camera's remotely via web UI, by entering the IP/Port of the server machine (which will also have changed). In this case "remotely" only means on my LAN - I do not allow for camera's to be viewed over the internet, but one could.


In consideration of my paranoia and small skill set with networking theory, I ask myself this: should I change the IP addresses of static clients OR just make the ones I have removed from consideration when new addresses are handed out? If there's no downside to manual IP assignments at the router, why change the clients and anything that references those IP addresses?

If I understand right, once I tell the router not to use specific IP addresses when assigning new ones, the only downside is having to do it again if I get a new router. I don't have to reconfigure my security software (Blue Iris) nor worry that anything breaks.

I'll add just a little more color to the issue at hand... remember when I said my camera's were shirte? I recently discovered that the mfr of my cameras (Amcrest) doesn't make the cameras, they are rebranding another OEM's camera. That means different support, no firmware development, ipso facto... no firmware updates, and different software tools. It is only through my recent troubles with the AP that I discovered this and am a bit soured by the fact. Also, remember when I said that I couldn't change the preferred/Alternate DNS servers on the camera to match my other cameras? I was able to make and save the changes with a different tool - why did that tool work and the main web UI didn't? Don't know. Wonky.

Suffice to say, that changing camera settings is neither consistent nor reliable. It is best to avoid it if possible. So I vote for removing existing static IP clients from the DHCP pool.

You ask me what time it is and I tell you how to build a watch, but yeah... those are my thoughts on it.

 

[ColinTaylor]

Thanks for the explanation of your Camera setup. Like I said, it's not something that I've used and it does sound like it can be a pain in the arse.

I'm also a great believer in "if it ain't broke don't fix it". Although in your case it was broke but it just hadn't manifested itself yet.

If I understand right, once I tell the router not to use specific IP addresses when assigning new ones, the only downside is having to do it again if I get a new router. I don't have to reconfigure my security software (Blue Iris) nor worry that anything breaks.

Correct.

Suffice to say, that changing camera settings is neither consistent nor reliable. It is best to avoid it if possible. So I vote for removing existing static IP clients from the DHCP pool.

Makes sense.

At the risk of adding unnecessary confusion.... Another option for you might be to shrink your current DHCP pool so that it doesn't overlap with your camera addresses. So if all your current static addresses were from .155 upwards you could change the DHCP range to be 2 to 150. That way you wouldn't need to bother about adding individual reservations into DHCP for the static devices. This assumes that you're not going to have more than 149 DHCP clients connected to you network.

 

[YrbkMgr]

Oh hey, great idea. Only one thing.... why? Ya know?

Today I will be starting the IP pool at 20 and re-adding that access point so that I can now see if I get better signal from the camera.

Dude... I really appreciate you. Thanks.

 

[ColinTaylor]

Oh hey, great idea. Only one thing.... why? Ya know?

I'm not sure if that's a rhetorical question, or whether I understood it. But if you're asking "why should I use a smaller pool vs. reserving static devices within a bigger pool" the answer is... use whatever method makes more sense to you. One way is no better or worse than the other.

 

[YrbkMgr]

I'm not sure if that's a rhetorical question, or whether I understood it. But if you're asking "why should I use a smaller pool vs. reserving static devices within a bigger pool" the answer is... use whatever method makes more sense to you. One way is no better or worse than the other.

It was rhetorical - thanks for making me chuckle. A thought occurred to me....

If I configure network clients to have static IP addresses at the client, why do I need to set it at the router? Wouldn't DHCP automatically know? Look at this client table AFTER I manually assigned IP around the DHCP list.



Note that my manual assignments show up as "Manual" yet other devices with static addresses just show up as "Static". So clearly the router knows that there are static clients. Why then, do I need to manually assign IP around the DHCP list?

 

[ColinTaylor]

Wouldn't DHCP automatically know?

No. Read the second paragraph of post #14 again.

The client list is completely different from the DHCP server. The client list is separate piece of closed source code from Asus that does network discovery. The DHCP server only knows about addresses that it is managing.

 

[YrbkMgr]

No. Read the second paragraph of post #14 again.

The client list is completely different from the DHCP server. The client list is separate piece of closed source code from Asus that does network discovery. The DHCP server only knows about addresses that it is managing.

Yeah, I intentionally risked a tongue lashing with that one when I omitted the phrase "I know you said..." - so I'm sorry, and appreciate your patience and diligence. Got it - Client List and DHCP don't work together.

I'm going to reconfigure the DHCP pool to start at .100 - So I'll have from .2 - .99 for static IP addressing. Then I'll go about changing the static IP addresses on each device to be outside the pool. Here's where I need your advice... what gets changed first - each device or the router DHCP settings?

I now have manual assignments from the pool, should I get rid of them before changing the pool starting address? I don't want to muck things up, so and thoughts on best practices from a procedural standpoint would be appreciated.

 

[L&LD]

Remove all manual assignments first. Change the DHCP Pool range. Reboot the router.

Change the static IPs on the devices you want. Reboot the router.

Verify that all IPs are assigned as expected and that everything is reachable. If not, reboot the whole network, including client devices.

 

[ColinTaylor]

I now have manual assignments from the pool, should I get rid of them before changing the pool starting address?

No, leave the manual assignments for now. Change the pool starting address and apply that change. Afterwards, if you have any DHCP clients that aren't directly connected to the router by wire or wireless (i.e. they're connected via an intermediate switch) reboot them now.

You can now take your time changing the static addresses on your cameras. Once you have changed all the addresses and the cameras are working with them you can remove the old DHCP reservations. This will again cause the DHCP server to be restarted, so as before if you have any devices connected via a switch they need to be rebooted afterwards.

That's it.

Correction: The way the DHCP server is restarted has changed since I last looked at it. You should no longer need to restart any clients connected via a switch.

 

[YrbkMgr]

Ahhhh... just change the pool, everything stays the same as it is until I change client ip addresses at my leisure. Just to be clear... there won't be a clash between the new IP/MAC and the reserved IP/MAC after changing it? That is to say, does order of operation matter here?

 

[ColinTaylor]

Ahhhh... just change the pool, everything stays the same as it is until I change client ip addresses at my leisure. Just to be clear... there won't be a clash between the new IP/MAC and the reserved IP/MAC after changing it? That is to say, does order of operation matter here?

No there won't be a clash. Although I did forget to explicitly say that you do need to check that the new static addresses you're using aren't currently being used by a DHCP client. Look in the Client List and reboot any conflicting clients after changing the pool size.

 

[YrbkMgr]

Roger that. Stay tuned.

 

[L&LD]

Or, post 31.

 

[YrbkMgr]

Or, post 31.

No doubt, and I apologize for not acknowledging your post. I hope you'll forgive me for that - so far it's only been Colin and me in the thread and I'm at the precipice of changing everything on my router. After 30 posts, and a week of good will, I didn't want to frustrate anyone further with my confusion - I hope you understand.

I appreciate you taking the time to put your head into this in the first place.

With said gratitude in mind, let me share a story as a small attempt to make up for it. It's about True Justice: Dr. Calvin Rickson, a scientist from Texas A&M University has invented a bra that keeps women's breasts from jiggling and prevents the nipples from pushing through the fabric when cold weather sets in. At a news conference announcing the invention, a large group of men took Dr. Rickson outside and kicked the shirt out of him.

 

[ColinTaylor]

Don't use the suggestion in post #31. It would require you to make all the changes at the same time. Otherwise it risks exactly the kind of conflicting IP address problem we've been at pains to avoid.

 

[L&LD]

@ColinTaylor, no it doesn't (after that first reboot).

After more than 7 days of working on a known issue, it is time to take bigger steps towards a resolution.

But I also don't want to have the shirt kicked out of me either!

 

[ColinTaylor]

@ColinTaylor, no it doesn't (after that first reboot).

Yes it does. Please don't post about things you don't fully understand.