How does setting a static IP on a mobile device prevent linux router from assigning that IP address?

which is issued by the dhcp server.

as i said, leave the device set to dhcp and all is good.

ssid passwords are separate and not relevant.

Reply to
nospam
Loading thread data ...

Yeah, sure.

Yeah, sure.

Yeah, sure.

Yeah, sure.

Your opinion noted :-P

>
Reply to
Carlos E.R.

In , Pat suggested:

This was very well written, as was Carlos' reply! Thanks.

Key takeaways... a. If the device is set to DHCP they get what the router gives them. b. But if set to static, that's it - they are that IP address. c. The router can give that same IP address to some other device also.

Reply to
Tomos Davies

Uh, no -- sorry, it was a typo on my part. I was looking at the details for the R7*5*00. According to the FCC docs, it has 6 dBi antennas.

20-23 dBm conducted power seems to be pretty standard across the "better" kit since about 2014 or so (though, admittedly, I've stopped keeping up since discovering UBNT kit).

Well, provided you don't tick the "I know what I'm doing" box where you can set the conducted power yourself ... though that may have been taken out on the 'US' kit. They accidentally shipped me a 'world' model once (test 5ac unit, once I realized it wasn't a US unit, it got stuck in the corner... while I can set it to 'US', would rather not goof and have the FCC come knocking ;) ).

Most modern SOHO kit is 5-6 dBi. That being said, omni vs. directional doesn't really matter in the scope of our "on paper" maths. Obviously, the real world will throw a monkey wrench into the works.

Typically they default (or lock, with "standard" firmware) to about this, so that you don't create a situation where the AP is vastly overpowering the client devices.

If you're using airmax kit with the airmax protocol enabled, it's not WiFi though ;). Yes, it's still *wireless*, but ... different things. I guess a parallel would be oranges and lemons -- they both fall under the 'citrus' umbrella, but you wouldn't really use lemons when you need oranges.

Point being though, it's very easy to make this kit sound like it does something wildly different than what it's been designed to do.

You may want to check your local fire codes concerning that -- it's against them here (Eastern US), due to the differences in ground-potential, and that in the event of a short, the mains voltage may decide the best path to ground is via the ethernet cabling.

My comment was more intended for others who may be reading our discussion -- seems you have enough of a handle on things to understand the caveats, even if you're not saying them. Someone else ... probably not so much.

Wouldn't know, TBH -- UniFi all over the house for the last 2.25 years, after I came across their kit when searching for a replacement for the WRT54G I had (WAN was stupid slow, so even a 10/100 router could keep up and WiFi is really just for the phones / tablets ... PCs / consoles / whatever are all cabled in).

Reply to
Dan Purgert

I suspect it's neither -- rather, it's an informal street-talk description of the device with the given MAC address. HTH. Cheers, -- tlvp

Reply to
tlvp

you suspect wrong.

Reply to
nospam

yeah, like I said, it seem(ed) to just be a psuedo-random number. Who knows how they came up with it, and how large the pool actually is. :)

Reply to
Dan Purgert

Actually, they can and do. The caveat is that they MUST[1] have already received an IP address from somewhere. In addition, I believe the address also has to have some lease time remaining (although, this may not be a hard requirement).

For example, you take your phone to work every day. When you get home, and the phone re-connects to your home's wifi, the DHCP DISCOVER packet will (typically) include the last known IP address as part of the request -- essentially "I had 10.11.12.13 before, can I have it again?"

The DHCP OFFER (server response to the client's discover) will either confirm the client can use its requested IP address, or tell it to use something else (e.g. 192.168.1.144).

To wrap up, the client sends the DHCP REQUEST and server sends DHCP ACK packets.

Same thing happens if you reboot your computer (though with a higher chance of the DHCP server allowing re-use of the requested IP address).

[1] as per RFC2119 --
formatting link
Reply to
Dan Purgert

a. Yes (though they can request IP addresses) b. Yes c. If and only if the static IP is part of the DHCP Pool.

Reply to
Dan Purgert

An AP is just a "dumb" bridge between your wired network, and wireless devices. It has no say in DHCP addressing.

If it does, then you've got something misconfigured somewhere.

Reply to
Dan Purgert

Tomos Davies wrote in news:ocrlb3$143$2 @news.mixmin.net:

As long as one doesn't have too many devices using the router/AP, the dynamic IPs handed out by the DHCP server should remain associated with the MAC address that last had that IP. The only thing that would upset that would be if a device that is not normally on that network requests an IP from the DHCP server, it could provide an IP that had been in use by a different defive.

What you are all missing is that a DHCP 'lease' has a time value associated with it. [That is what a DHCP server does, it 'leases' IPs out to devices that request them until its lease pool is depleted] The server keeps track of which dynamic IPs it has assigned by recording the MAC of the device, the IP assigned, and the date and time of the 'lease'. [For you Windows users, that is what the ipconfig option 'release'is for, to release an assigned IP before the lease expires] For as long as the lease is in effect, that IP will not be leased out to a different MAC address. A simple solution would be to go into the router configeration for the DHCP address and set the lease time to some large value like a year or more. Then every time a device requests an IP, the server will look at its list of existing leases, and if the device's MAC address is on the list, it will receive the same IP it had before, AND reset the timer for the lease duration. It is only when the lease timer expires that the IP address becomes available for reassignment.

One place where I helped manage the network we had the opposite problem. We had more devices than there were available IP addresses. Most of the devices were desktops, but some were laptops. We wanted the leases to expire after a short period of time so that they would be available to be leased to a laptop 'visiting' the network. But if we set the lease duration too short, we ran the risk of one of the permanent desktops not being able to obtain an IP address when it powered up. What we did was set the lease duration to four days. That way the lease wouldn't expire over a weekend when the desktops were turned off, and it would cover those weekends that were 'three day holidays'. There was a slight risk that if a user was out of the office for more than four days their desktop would not receive an IP when it powered up, but to my knowledge that never happened while I was there.

Reply to
Tim

Dan, I think he's just using terms "AP" and "router" interchangeably :-) .

HTH. Cheers, -- tlvp

Reply to
tlvp

aka nickname. Cheers, -- tlvp

Reply to
tlvp

Why didn't you switch to another IP range? Say 10.*.*.*?

Reply to
Carlos E.R.

At those distances, I would thing fibre. At least, optical couplers.

Reply to
Carlos E.R.

excuse me while I reboot my brain :/

Reply to
Dan Purgert

Yeah, I didn't even catch he said 500' on first read ... surprised it works, being 50% over the length limits imposed by the specs for copper cabling.

Reply to
Dan Purgert

*Except* for the key/password for the SSID in question.

Of course, but you *still* need, *multiple* "independent configs".

SSID password/keys are part of the "config" on the device and because most if not all SSID/password combinations will be unique, you *will* have *multiple* "independent configs", whether nospam likes/admits it or not.

QED.

HTH.HAND. EOD. NK.

Reply to
Frank Slootweg

Opinion noted.

Sigh! You're not very good at this, are you!?

You may want to at least *try* to keep track of *who* holds *which* argument!

The 'DNS is a better solution" argument is *yours*. The OP does *not* need/want it and I am *not* the OP.

So why on earth would my equipment be "shitty" if it does not have certain functionality which I do *not* need nor want!?

So what we have is that nospam considers a consumer-type (NAT) router "shitty" if it doesn't have the functionality which *he* wants! Duh! And why would *we* care!?

QED.

HTH. HAND. EOD. NK.

Reply to
Frank Slootweg

I previous provided a few of the mechanisms designed to prevent that from happening. However, the most common mechanism is for the router to maintain a table of recently assigned IP's and their associated MAC addresses for as long as the router has power. When a device disappears for a while (which could be weeks), upon its return, the router dives into this table, extracts the previously assigned IP, and hands it back to the client device. It's quite common for me to drag my laptop or Chromebook around to customers, connect to all manner of different networks, and come home to find that my router has assigned my laptop the same address (unless the power and UPS have died).

However, RFC7819 has a different playbook. Random allocation: A server can pick a resource randomly out of an available pool. This allocation scheme essentially prevents returning clients from getting the same address again. On the other hand, it is beneficial from a privacy perspective as addresses generated that way are not susceptible to correlation attacks, OS/vendor discovery attacks, or identity discovery attacks. This is quite the opposite of repetitively renewing the same IP address. As I understand it (might be wrong), if the connection times out AND the DHCP lease time is exceeded, you get a shiny new randomized IP address when you return. If the lease time has not been exceeded or you disconnect for a while, you get the same IP.

Incidentally, most home routers give a connected client a 2nd chance to keep its IP address. If the renewal time is exceeded, there's the rebind time, which is about twice the renewal time. How this is implemented depends on your router manufacturers vision of security and level of paranoia.

I have no easy way to tell how some random router might handle this. I've also spent no time investigating this feature, simply because it takes so long for things to time out. The original minimum lease time was 1 hr, but that's been tweaked by most router vendors to solve specific problems.

Your Android can only ask for a DHCP lease renewal, or a new address. It's up to the DHCP server in the router to decide if it's going to get a renewal or a new IP, and what that IP might be.

The DHCP server in the router detects that it has already assigned that IP address and delivers a different IP to the device. I've previously listed various mechanism that are used. If you're getting duplicate IP address errors, then update your router firmware.

This might help: From my Linksys EA2700 router: 53 (DHCP Message Type): offer 54 (Server Identifier): 192.168.1.1 51 (IP Address Lease Time): 86400 (1 day) 58 (Renewal (T1) Time Value): 43200 (12 hours) 59 (Rebinding (T2) Time Value): 75600 (21 hours) 1 (Subnet Mask): 255.255.255.0 28 (Broadcast Address Option): 192.168.1.255 6 (Domain Name Server Option): 192.168.1.1 3 (Router Option): 192.168.1.1 I have some better programs for this, but they're company proprietary and I promised not to leak them.

The lease and renewal timing process is complexicated: More:

I guess I have to ask. Have you experienced a real problems with DHCP and duplicate IP's, or is this a theoretical or educational question?

Reply to
Jeff Liebermann

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.