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

In , Jeff Liebermann suggested:

I realize I'm coming into the middle of a conversation with you and Frank, but I wish to reiterate what I said in the OP which is the only reason for wanting a static IP address is so that the "mount point" (or whatever it's called in Windows terms) to the "My Network Neighborhood" icon remains at "ftp://192.168.1.15:3721" for the Android mobile device.

Sure, I can *change* that "mount-point string" each time the IP address changes - but if I can keep the IP address from changing - then I don't have to change the "mount-point string" (I don't know what it's correctly called in Windows networking terms).

The question is how to not have to change the "mount point" string when/if the mobile device IP address changes.

One solution would be to *add* a server/client to Windows (such as Kies, or AirDroid, or AndSMB or whatever) but the goal is to have ZERO additional software on either platform (if possible).

In this case, the gizmo is a mobile device which is "mounted" onto Windows (or Linux) using the static "mount string" of "ftp://192.168.1.15:3721".

Now is the time for that! :)

I'm perfectly fine with dynamic IP addressing if it allows *zero* additional software on both Android & the computer.

Do you know of any way to "mount" the entire Android device onto the computer without adding *anything* to the computer?

The only other way I know is by using SMB but that requires adding software that isn't on the Android device already (whereas ES File Explorer was already there).

I think SMB might work with dynamic IP addresses though... so it's another option.

:)

In , Carlos E.R. suggested:

Correct. It was my fault for not being clear that the Android phone is set up to "request" a certain IP address (i.e., 192.168.1.15) whenever it connects to a given named access point.

I agree with all of you that it's more elegant to assigned a fixed IP at the DHCP configuration of the access point.

One open question I have is what happens under the current circumstances when the Android device requests an IP address of 192.168.1.15 of the access point ... if ... if the access point has already handed out that IP address to another device?

In , Jeff Liebermann suggested:

It's my fault for not being clear.

While the "lease" seems to make all the difference in practical terms, by default there is nothing (other than the continuingly re-extended lease) to stop the router from assigning the IP address that is currently assigned to the phone to some other device on the local network.

There are multiple ways to make the IP address remain at 192.168.1.15 on the device, only one of which is done on the phone, and that one is done "per access point" ... which was what "C" was all about.

Item "C" was really what this question was all about, because I was wondering what "magic" enabled the mobile device to have a say in what its IP address was going to be.

The "magic" is how an Android mobile device can "ask" for a certain IP address from the access point (e.g., 192.168.1.15).

A question might be what happens if that access point has already handed out 192.168.1.5 to another device?

In your - as usual misguided - opinion.

In your - as usual misguided - opinion.

Red herring. He needs only one.

Tell us - oh wise one - exactly *where* and *how* it "probably is already set up"? In the real world these things don't happen automagically.

When spouting your next response: The context is an Android device, a Windows computer and a simple consumer-type (NAT) router.

Yes, because the IP in question is reported by the FTP server when you start it and it can be configured in the router.

OTOH, your imaginary DNS server is blissfully absent in the described set up, so it *can* not even be set up.

nothing imaginary about it and is likely already active, so nothing to set up.

you're well over your head, again.

Ever heard of keys/passwords?

Indeed. Each SSID gets its own independent configuration in every system I know, and that includes of course setting up the different password for each SSID.

As usual no specifics, so you claim can't be verified, so it's false until proven (by you) otherwise.

Also you've not catered for - and silentlu snipped - the specified context (Android device, Windows computer and a simple consumer-type (NAT) router).

QED.

HTH. HAND. EOD. NK.

Notice that in your configuration your device does not request an IP. It just uses that IP straight away, no matter if it has been given by DHCP to another machine by chance. What happens? Collisions. None works.

Notice also that the AP does not hand out addresses. That's the job of the router.

I'm jumping in here without having read the whole thread, but I want to comment on your "open" question:

Devices do NOT request a certain IP address. They can be set to DHCP and request an IP address OR they can be set to a static IP. If DHCP, they get whatever the router/AP decides to give them. That could change every time they join the network or (more likely) end up being the same each time unless that address has been handed out to another device. It is often the same each time because the router/AP sees the MAC address of the device and tried to give it the same IP address it gave it the last time it saw that MAC. Newer routers often have a feature which consistently does that called "reserving an IP address". If you set your device to a static IP, that's what it is. The router/AP has nothing to do with it. Nothing is requested. Nothing is provided. If you select a static IP that is the same address your router/AP assigned to another device, you end up with two devices using the same IP address and your network will become very erratic. If you want or need a static IP, learn what range of addresses your router/AP hands out and pick something outside that range. For example, if your router/AP's DHCP service assigns addresses from

Apparently he is lucky to have a router where you can assign names to the reservations, so he thinks we all have.

Assuming that is a DNS name and not a BIOS name.

Not a short number, though. Seems quite long for a repeat. :-?

sure. what about it? that has nothing to do with leaving it on dhcp.

already explained.

most routers do, but if for some reason the router does not, all is not lost. there are other ways to use dns rather than ips.

bios has nothing to do with it.

Yeah, I saw that. And indeed we (TINW) do not all have that.

Also it's a far, far stretch to call that functionality "DNS"!

For someone who's so hung up about using 'standard' terminology, that's yet another massive fsck-up of his.

That's the main reason I do it that way (and that particular device that won't work with stetting it for static).

most people have it in some form.

if you don't, then replace your router with one that is more modern. don't blame others because you use s***ty equipment.

it's dns.

no fuckup at all.

Sigh!

Maybe the fact that they *do* need "independent configs"?