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

In , Dan Purgert suggested:

While my Ubiquiti equipment has, as you noted, few country options:

My Mikrotik equipment has *hundreds* of countries to choose from!

I can't explain why - but there's every country you could want to choose in the list. Even multiple ones for various areas of Brazil, for example (dunno why).

In , nospam suggested:

Heh heh ... and still no references.

In , Carlos E.R. suggested:

I can't answer that question. I don't think anyone ever considered any other solution.

The bucket routers work. I don't think we ever considered anything else.

The main problem is electrical power. Some routers work over POE but we prefer 120VAC when we can get it.

In , Jeff Liebermann suggested:

You brought up an issue that makes complete sense. I had *assumed* that the mobile device was on the network.

So, for example, this solution should work in the local library, or if I visited you at your house (simply because nothing needs to be loaded on the computer).

In both situations, I would already have the FTP server on my mobile device, so I would just hop onto the library computer or your computer, and enter in whatever IP address and port the local network gave me.

And it would work!

Contrast that with a solution which requires software (e.g., iTunes bloatware) and an account (e.g., an "initialized iPad") which stands far less of a chance of working on "any" computer.

That article explains good things to do with a spare Android phone.

Did you notice that the number-2 suggestion of that article was exactly what we have set up here?

1. Web server
2. File server

several were given and i've found even more options today.

you just refuse to learn.

In , nospam suggested:

We all believe you ... because you supply so many references all the time.

Well, with fibre you would not need routers nor power for repeaters.

In fact, assuming that you don't really need high speed on those lines, you could just use a plain telephone line (2 wires) and transmit with a method similar to ADSL. You might achieve perhaps 10 Mbps, maybe 30, at distances of a mile, perhaps 5.

But I don't know how to achieve that, I've never needed to investigate.

i *always* can back up what i say.

you're just begging to look even more stupid than you already have.

In , nospam suggested:

Do you expect people here to be as gullible as iOS users are?

I know you know that Apple deprecated the private API for this feature. So all you can do is find screen shots on the web of very old releases! Apple won't let the apps through anymore.

And you know that. Read this for example: How to get bssid in iPhone without private library?

Answer: You can't anymore. Apple will reject the code.

I know you knew that (because we discussed this in depth on the iOS newsgroups, so, you're just hoping everyone here is as gullible as most iOS users seem to be.

i expect people to see just how stupid you truly are.

apple did no such thing.

the first link from apple is *current*. if it was deprecated it would say deprecated. it does not.

they aren't old at all. not only are the apps *current*, but they've been updated as recently as *4* *weeks* ago. that's last month.

absolutely false.

i know way more than you do, that much is clear.

try reading them yourself, because they don't say what you think they do.

It seems Apple deprecated CaptiveNetwork but then migrated to NEHotspotHelper

in other words, new api. no big deal.

CaptiveNetwork is still working. Due to many requests Apple may have reinstated the API's.

in other words, not deprecated after all.

Any usage of this code won't get your app rejected by Apple.

in other words, no rejections if used.

nonsense, and *your* links prove that.

you really are stupid.

the only idiot is you.

Well, not "any" device. It has to be running an open FTP server and you have to know its address.

ES File Explorer is sometimes considered to be "additional software". ;-)

I used a spare WRT54G v5, running a small version of dd-wrt, as an access point, client, and repeater for quite a few years. (Not all at the same time, of course). If I had known it wasn't capable I probably wouldn't have tried it and found that it was fully capable. Actually, that's not quite right. The dd-wrt site had detailed instructions that were specific to the v5.

I don't think router designers care that much about ISP DNS. A DNS resolver located locally, within the gateway router, *should* be faster than a DNS located either within the ISP or elsewhere on the Internet, although what's a few milliseconds among friends.

They do care, because those routers are installed "free" by the ISPs, and the default configuration is defined by the ISP. So either they are built to spec from the ISP, or the ISP chooses one that is appropriate from those available.

No, those DNS servers can never be faster than one outside (for a non cached query), because they always ask the same DNS server outside to do the query; they don't query the DNS chain outside from the roots and up. If the answer is cached it will be instant, if not, it has to wait for the ISP DNS to find out the answer and reply.

Ie, if it is bind, it has "forwarders()" defined, and also "forward first;".

yeah, they do a lot in the soho market...

To be fair, the "firewall" feature is immensely useful, and I honestly can't see any manufacturer (incl. the enterprise brands) not including at least an ACL firewall on the router.

That being said, examples welcome, if you know of any.

Due to the vast majority of "mesh" APs (exceptions exist) utilizing the same radio for backhaul as they do client access; and that WiFi is half-duplex (only one device can transmit at a time), the losses for adding "mesh" hops hover around 50%. Sure, newer wifi protocols may drop that a bit; but you're not gonna get less than about 40% loss on each hop.

I've not seen "mesh" setups with multiple 5 GHz radios (i.e. "backhaul + client access").

Far as wired backhaul is concerned, those APs are either the edges of your mesh (and not the source so much of the losses), or your network doesn't use "mesh" at all.

Because the UBNT radio(s) you have / use are following 47 CFR, Chapter 1, Subchapeer A, Part 15, Section 202: | Master devices marketed within the United States must be limited to | permissible part 15 frequencies. The section goes on further to define "master device" | For the purposes of this section, a master device is defined as a | device operating in a mode in which it has the capability to transmit | without receiving an enabling signal. In this mode, it is able to | select a channel and initiate a network by sending enabling signals | to other devices.

I believe this section was amended in the mid-2000s ('04 or '05 or thereabouts), so either:

A) The 'tik unit pre-dates that (and, IIRC, gets grandfathered in) OR B) The 'tik unit is willfully ignoring US regulations

nope. the new mesh routers not only have little to no degradation, but the end result is actually *faster* because there is a strong signal throughout the house rather than only at one part.

then you are completely unfamiliar with the new mesh routers.

if someone uses mesh routers, their network is using mesh.

simple concept.

Have any links to these "mesh routers"?