Bug #1857
closed
LAN-if does not check if there is already another host using that address
0%
Description
when a new installation is booting it should check if there is already another host using the default ip of 192.168.1.1
Updated by Michal Fresel almost 14 years ago
maybe we set the LAN-if to DHCP to test if there is already a server and that way we obtain an IP (this way we know there is a dhcp-server ;)
Afterwards a ping to 192.168.1.1 and parsing the output of
arp 192.168.1.1
if the output is
192.168.1.1 (192.168.1.1) -- no entrywe can use the default IP and maybe also inform the user we are working in a different subnet (when the DHCP-subnet is different)
Updated by Jim Pingle almost 14 years ago
- Status changed from New to Rejected
It's a lot of work and a lot to go wrong for very little benefit there. If someone is concerned about it taking over an existing address, they should be plugging straight in with a crossover cable from a laptop and not into a live network. Or change the IP on the console before plugging it into a live network.
So if it can't use .1, should it just keep arping until it finds a free IP? That could take ages.
Odds are if the IP is already in use there may even be a DHCP server running, but no guarantees there.
I don't see the point is changing how it operates from now. At best it would be confusing since it lands on a non-default IP (and you'd have to check the console to see it anyhow, and if you're there already why not change it). At worst it would take forever to locate an IP or break in some other way that leaves you without a LAN IP.
Updated by Michal Fresel almost 14 years ago
hi Jim,
x) send just 1 (one) ICMP package for ping
x) single pings to the whole subnet concurrently and wait for 1 second
-> afterwards we have a full arp-table (of the subnet) and work on the results
so the process would take .. 2 sec.?
the benefit is - admin does not need to run around to explain why he has to delete all arp-entries on the clients and internet is not working :)
- no race-condition on dhcp (as the new box knows there is already a dhcp-server) and we can turn off the LAN-DHCP
- for an admin who wants to test pfSense this makes testing easier
- for an admin looking for bugs it's nice as he just looks on console and sees the address
another benefit would be:
the code can be reused for a feature like "topology-overview" (additional to "dhcp-server-leases")
this way admin can get an overview of all hosts-mac combinations in use (even when ping is disabled on the client :)
Updated by Jim Pingle almost 14 years ago
Still too many things to go wrong. It is not that simple.
And the real fix is even simpler: Just don't plug a new router into a live network.
The default address is well documented, and shown on the console.
Updated by Michal Fresel almost 14 years ago
hi Jim,
somehow i still do not understand WHAT can get wrong?
I know it is not simple and some coding is needed
Just explained you some "real-live" experience … and yes-documentation is good.
the reason for opening this bug is my current testing:
forgetting to detach LAN in the virtual machines makes my NET stand still ;)
so pfSense breaks my net by default as the .1 is also my default-GW :/
Think of names: would it be nice if somebody else is allowed to "hijack" your "nick" just because he is using it by default?
So "hijacking" IP's is not a nice feature either :)
Maybe we change it to a "feature" and re-open it?
Updated by Scott Ullrich almost 14 years ago
I agree with Jim. This is not going in but thanks for the suggestion.
Updated by Jim Pingle almost 14 years ago
We can't stop everyone from shooting themselves in the feet.
Changing the default LAN behavior to anything but static would be disruptive. Any kind of automation (why not just use DHCP?) is a bad idea for a default. What we use now is well known, well documented, and works for nearly everyone in every scenario as a default.
Adding that much code to support something that is only a problem for a very, very, very small number of people in a very avoidable scenario is just not going to happen.
Updated by Michal Fresel almost 14 years ago
so expecting a "feature" for the console would not be implemented either:
##external management-host##
creates new ruleset to permit 1 (one) IP-adress on WAN to access the management-interface using SSH, HTTP and HTTPS
well .. these were just ideas … so we keep it closed :/
Anyway …
Thank you for your efforts!