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

"Carlos E.R." wrote in news: snipped-for-privacy@Telcontar.valinor:

Corporate told us we had to stay with 102.168.nnn.nnn. We actually had several subnets in use, differentiated by the third octet. I realized later we could have had a larger pool of addresses if we had changed the subnet to something other than 255.255.255.000. We did want to segregate the shop floor network from the office network, but I think it still would have worked out that way.

We had enough IP addresses for all the desktops and printers on that network, but not enough if everyone who also had a laptop wanted to connect. Since the laptop connections did not happen every day we felt that this was the best way to handle the situation. If a laptop was connected several times in a week, it would tend to maintain its leased address, but if it was only an occasional connection, like a visiting engineer from another plant, its lease would expire and free up the IP after four days. It worked well, which is the final criteria.

Reply to
Tim
Loading thread data ...

To get off this Tower of Babel, I have to go back to the basics. "What problem are you trying to solve here"? The problem is not how to make a static IP address work on your network, or understanding how DHCP operates. It's setting up your overly smart phone on your network so that other devices can find it by IP address. Normally, such things are done using a local DNS (or RADIUS) server, but those would add far too much complexity. Therefore, you use a pre-assigned or pre-allocated static DHCP IP address and you're done. If your router has this feature, I can assure you that its DHCP server will not hand out a pre-assigned IP to any other device (unless someone spoofs the MAC address and untangles the TCP and IP sequence numbers).

You remind me of one of my customers. This is an exact quote from him: "Fix it, but don't change anything". You're suggesting increasing the complexity by adding yet another layer acronyms to your problem, while demanding no changes. That's not going to happen.

Nope. I just got off the phone with a customer. "Drop everything and come over. All my files have disappeared". There went my afternoon.

Nope. Mounting a filesystem or directory structure requires a server running somewhere. SMB (SAMBA), Netbios, ftp server, TFTP, etc running on the PC. All these will require client software on the phone. Or, you could buy/build an NAS (network attached storage) server, which usually has a half dozen assorted servers built in (including ftp): Plenty of others available, some which are specialized for entertainment media, such as: which unfortunately requires additional software on both the client and server, but which might be worth the effort. As you may have noticed, I'm not a fan of using a desktop as if it were a server.

Reply to
Jeff Liebermann

that's separate from dhcp.

dhcp takes care of that.

that's not part of the dhcp config.

Reply to
nospam

translated: you can't refute it.

actually, very good at it. much better than you are, that's for sure.

there's really only one argument: those who insist static ip = reserved dhcp versus those that know the difference.

because he's ignorant about networking (among many other things) and insists on doing things in the most complex way possible.

you do realize it's the nymshifting troll, do you not?

i never said you were.

you like doing things the hard way too?

it's not just me who wants it. hundreds of millions of people want and use that functionality every single day and would complain loudly if it didn't work.

what you're saying is you like being stuck in the past.

Reply to
nospam
[snip]

Yes. Some people will get AP mixed up with ROUTER, since they're often in the same package. They are still logically different things. In you need one or more additional APs on your network, the router (and DHCP server) should be disabled on all but the first. It needs a static IP for configuration.

Reply to
Mark Lloyd
[snip]

IIRC, if you have multiple APs on your network, you should use the same SSID and security settings on each.

[snip]
Reply to
Sam E

usually yes, but there are reasons not to.

a better option is get a mesh network.

Reply to
nospam

unless the access point is just an access point and doesn't have a dhcp server at all.

Reply to
nospam

In , Dan Purgert suggested:

Thanks for the clarification.

Even if a SOHO router did have a powerful transmitter, most of them have omni antennas which dissipate the energy in all directions.

So I prefer the directional stuff for the areas like the barn or the pool or the neighbor's house a mile away! :)

So right now I'm working with this 23 decibel transmitter in my living room:

formatting link
formatting link

I've never touched Mikrotik equipment before so I'm having trouble getting the RB411 motherboard with a R52n-M WiFi board (both 2GHz and 5GHz) running as yet another access point, as I'm running into setup issues that I never had with Ubiquiti equipment before.

formatting link

I think I'll ask about them separately because I don't know the first thing of this Microtik setup stuff.

formatting link

While the Ubiquiti radios only allow a few country settings, this Mikrotik RB411 R52n-M transceiver I'm working on at this very moment seems to have a couple hundred countries to choose from!

formatting link

Other than frequencies (which can be set separately), I wonder which country allows for the strongest EIRP?

I suspect it's already the United States that allows the strongest EIRP for any given frequency band. Does anyone here know if that is correct?

In general, omni works for routers because they're generally put in the middle of the house (or thereabouts) but in general, if you want to go a few hundred feet to the barn, a directional antenna has more bang for the buck (IMHO).

Of course, decibels are decibels, so, a more powerful transmitter never hurts either, nor a more sensitive receiver.

This is the transceiver power & sensitivity, for example, on the radio at my feet, roughly 20 decibels of power into roughly 14 to whatever more decibels of antenna gain with roughly -95 decibels of sensitivity.

formatting link

True. I have to turn off AirMax when using the Ubiquiti transceivers as access points!

I agree. Everything is in the settings where "pairing" is important.

We are both using professional equipment, where my main point is that the professional stuff costs just about the same as a home SOHO router does!

formatting link

What this professional stuff is designed to do is carry WiFi signals for miles, but what I'm using the transceivers for is to only beam my signal less than a kilometer from the SOHO router that they're connected to.

Indoors they don't go far - but outdoors - in the clear air - they go pretty far (a lot better than a "cantenna", for example!)

That's a good point but we do lay cable on the ground all the time out here. Your point is well taken though, and is sensible.

You are doing the others a good service. If they want to "extend" the range of their SOHO router, they can do it using these things far better than what I'm using:

They should use something like this:

formatting link

I am using this simply because I have them lying around doing nothing else:

formatting link

Reply to
Tomos Davies

In , Sam E suggested:

A problem, as I already stated it, but I only stated it in passing, is that the iOS equipment is far less capable than the Android or Linux or Windows equipment, in that iOS doesn't have a way to easily discern the unique BSSID when I use the same SSID for the access points.

So, for example, these two 2.4GHz and 5GHz radios *could* be set up to use the same SSID, but I find it more useful to set them up with different SSIDs to easily tell which one I'm connected to at any particular moment

formatting link

The two routers, on the other hand, are set up with the same SSID, so my network has a mix of the two configurations.

I would think my home network is pretty typical in that most people out here have multiple access points (at least a half dozen in most cases).

Reply to
Tomos Davies

In , tlvp suggested:

I think I'm using the right term when I use the words "access point"; but I could be wrong - so I'll explain further.

Here is a screenshot of how I have one of the access points set up.

formatting link

Notice that it's set up as an "access point" with the network set up in "bridge mode".

formatting link

What would *you* call that? A router? Or an access point?

For additional information, it's connected by wire to a router which itself is connected by wire to the main router in the house which itself is connected by wire to the transceiver on the roof.

It's the larger of the two transceivers in this photo.

formatting link

Am I incorrect in calling that an "access point"?

Reply to
Tomos Davies

In , Jeff Liebermann suggested:

The main goal is to "mount" any Android or iOS device, whether or not I have an "account" on that device and without adding any additional software.

This is easy to do, if we just think about the problem set, and use native solutions.

So I used native solutions.

That's really all there is to the problem set. It works just fine.

I was just asking WHY it worked so well. Turns out, I was just lucky.

As stated, the problem is just to make it so that Windows or Linux can "mount" the entire mobile device, whether it's Android or iOS, and without adding anything on the computer (because that's what gives the solution its universality).

Too complex. I agree. This solution of FTP server on the device & ftp mount point on the computer is simpler.

And it works.

Reply to
Tomos Davies

In , Dan Purgert suggested:

I think I mentioned it, but if I didn't, we use "bucket routers" every few hundred feet, which are simply cheap routers inside of a bucket, to keep the rain out.

It's pretty common out here in the sticks.

Reply to
Tomos Davies

In , Dan Purgert suggested:

A predictable salt is a bad thing, so I just want to reiterate that the salt for the most common WiFi security "is" the SSID.

Hence, it's a good idea to do two things:

  1. Use a unique (SSID) salt, and,
  2. Stay out of rainbow tables (with a unique passphrase).
Reply to
Tomos Davies

What... ROTFL!

That's inventive.

Why don't you use fibre?

Reply to
Carlos E.R.

Don't ask me -- ask Jeff or nospam, our resident experts :-) . I just reported an impression I was getting.

Cheers, -- tlvp

Reply to
tlvp

it can, but you refuse to learn.

Reply to
nospam

Any? Please look in a mirror and check for signs of temporary insanity. There must be a reason why you want to invite every drive by smartphone onto your network. The problem is not in mounting the device. It's that said device needs to first connect, associate, authenticate, etc with your wireless AP. An inconvenient detail is that the user of the smartphone has to configure their phone to do this, along with knowing all the necessary pass phrases and incantations to successfully connect, they are now on your network. Please modify your "Any" to "One of my devices" so we can blunder onwards.

This is beginning to look like my "Fix it, but don't change anything".

Now that the new device is properly connected and running on your network, it now has to invite your client machinery to connect to it. That invitation is usually provided by some kind of server. Lots of choices, none of which come stock with Android OS, but do come with various "enhancements" to the OS in the form of various connection sharing schemes. In all cases, the user of the client machine has to do something to login, and the owner of the smartphone server has to do something to allow that user to login. Either way, it's not going to happen automagically. It's likely that the vendor supplied connection sharing software isn't what you want because it's designed to share cellular data, not act as an access point for your WLAN. So, you have to perform and un-natural act and actually download some kind of server app from the Play store or APK from the evil hacker web site in order to provide this feature. In other words, this isn't going to happen without additional software.

If you change your mind on not adding anything to the smartphone, this looks interesting:

There's also the option of doing things in the other direction, where you run a server on your client machine, and connect to it with your smartphone. Setting up a server of some sorts on your Linux box is easy enough. Finding a suitable client that runs on your smartphone is also easy, but does require adding additional software to the smarthone. You could use the phones native web browser for FTP if you must, but I find that painful.

Yep. Why did you totally ignore using a pre-assigned DHCP static address? It does not add software, is quite automatic, does not require anything more than the MAC address of the smartphone, and can be fairly easily configured with your Linux router in dhcpd.conf: It does everything you want, in the manner that you want, as long as you know the MAC address of the smartphone.

It's fine to believe in luck. Just don't try to rely on it.

OK, so this is not a problem solving question, but rather an academic exercise. Not a problem for me as you may have noticed that I don't really just answer questions with "do this" type answers, but prefer to explain how things work and let you decide what to do next. Please note that you're mostly discussing implementation details, while I'm ranting about topology.

Umm... I visit your house, wave my smartphone in the air, it connects and mounts automagically. Now your Windoze or Linux server can suck everything out of my phone? I don't think I like that. Perhaps you might want to rethink how you are going to use this thing.

Reply to
Jeff Liebermann

Those are called Excess Points.

Reply to
Jeff Liebermann

We are talking of the client config. It is in the same place.

You are deaf. Or a troll.

Reply to
Carlos E.R.

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.