Date: Mon, 28 Aug 1995 08:59:53 -240 From: "Pavlov's Cat" <Pavlov's.Cat> To: hackers@freebsd.org Cc: apuzzo@alumni.cs.colorado.edu, davep@extendsys.com, rgrimes@gndrsh.aac.dev.com Subject: Re: ARP'ing [Summary of responses] Message-ID: <199508281259.FAA29765@freefall.FreeBSD.org>
next in thread | raw e-mail | index | archive | help
On the subject of discovering IP addresses on a local network segment, I said: : > I figured that I could cobble up a little hack that works kind of like the : > following nugget of meta-code: [my pseudo-arp code snipped] to which Tony Apuzzo <apuzzo@alumni.cs.colorado.edu> said: : I just do the following: : : # ping 9.99.2.255 : PING 9.99.2.255 (9.99.2.255): 56 data bytes : 64 bytes from 9.99.2.37: icmp_seq=0 ttl=255 time=11 ms : 64 bytes from 9.99.2.83: icmp_seq=0 ttl=255 time=27 ms (DUP!) [snip] : This [...] should work on any network segment that passes broadcast packets. Tony's right -- this does perform an interface discovery "sweep" on the local segment. But the *bad* news is that this is how my semi-net-literate (ab)users are "discovering" available IP addresses. This issue is not that a sysadmin can't find addresses in use, but rather that a sysadmin can't discover the IP addresses in use that have "legally" been assigned to a particular workstation (i.e.: by MAC hardware address). Rod Grimes followed up with a post that describes an approach very similar to Tony's which immediately does an "arp -a" to dump the arp cache. I think that this has merit as well, but the problem remains that many (non-BSD) workstations don't appear to respond to a broadcast ping. (NT is a notable example.) Regarding DHCP Services & Servers, David Poole <davep@extendsys.com> offered: : FTP Software has a WinSock DHCP server for ~$100. You do have to be : running their PC/TCP OnNet WinSock stack for it to work, though. We've : done some testing with it and found it mildly flakey but it works. : : There's also the WIDE DHCP server & client implementation. It's source : for a DHCP server and client. I got the client to compile, but ran into : some problems with the server. : : (From the DHCP FAQ) : 950630 WIDE Project: : Akihiro Tominaga (tomy@sfc.wide.ad.jp) : WIDE Project : Keio Univ. : Japan : ftp://sh.wide.ad.jp/WIDE/free-ware/dhcp/dhcp-1.2.1.tar.gz : Check Archie for dhcp-1.2.1 because lots of sites distribute it. While I appreciate the pointer to the DHCP server, the problem isn't, again, a problem in assigning addresses per-se, but rather an approach for monitoring the IP addresses that have been ifconfig'ed (or equivalent) on workstations attached to the segment. Let me be anally pedantic and re-iterate the problem as I see it.... Let's assume that I have set up a DHCP server and am leasing addresses 192.168.254.101 to 192.168.254.200. (100 addresses in the DHCP pool.) These addresses aren't "in use", but they're out there on the server reserved for DHCP clients to lease upon request. This means that bona-fide DHCP clients have a pretty good chance of leasing a valid IP for the duration of their connection to the segment. (This *works* with NT, but the management of the server is AWFUL. I'm going to look at a FreeBSD-based solution RSN. I'll keep you posted...) The problem occurs when J. Random Hacker configures his new FreeBSD box to add it to the net. He "knows" that the net address is "192.168.254.something" so he says to himself, "OK, it's 1:30 in the morning, I guess I'll ifconfig my net adapter as "192.168.254.130." Boots up and goes. A few minutes (or hours) later the DHCP server offers a "new" DHCP client the same address (192.168.254.130) because it's the first free entry in it's dynamic pool. (N.B.: DHCP servers don't have a way to monitor addresses which are "in use" but weren't asssigned by the DHCP server.) The client accepts the offered address and (at least with WinDoze clients) attempts to ARP the wire for "192.168.254.130" since it doesn't explicitly "trust" the server. Whoops! The client "discovers" that the address is already in use! Result: The client, having done everything "by the book" and playing by the rules is denied IP services and access to the net because some renegade user broke the rules and hard-coded a conflicting address. I recognize that this is a weakness of the DHCP spec and RFC's. The question I'm asking is, esentially, what management tools can I use under FreeBSD to monitor (and attempt to enforce some level of sanity in) an environment where the Linux and WinDoze users can go to "Books 'n More" and pick up a copy of "The Compleat Idjit's Guide to Netwerking" and now they're experts. My search for a solution continues..... Thanks to all for the replies thus far... -- ...sjs... Steve Sims (SJS7) SimsS@Infi.Net Systems Engineer, IPC Technologies, Inc. Virginia Beach, VA "Everyone wants to save the Earth; Nobody wants to help Mom do the dishes." ...P.J. O'Roarke
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508281259.FAA29765>