*** From dhcp-server -- To unsubscribe, see the end of this message. ***

> 1) Which version is the latest (most stable) 2x version? I see 
> 2.0b1pl18 on the ftp site but someone recently mentioned a newer 
> version (24?). Where do I get that? Do I want to get that?

I would encourage you to run pl25, although pl18 is a good choice
too.   pl24 is not a good choice.   You can see the changes in the
RELNOTES file at the top of the distribution if you want to know the
difference.   Actually, I'll include them below so you don't have to
go fetch it just to decide not to use the later version.

> 2) Are there any problems/concerns/cautions converting from 1x to 
> 2x? (Of course I'll back up the leases and executables). Does 
> DHCPD.LEASES format change? I haven't found any 
> documentation that discusses 1-->2 upgrade (but I could have 
> missed it).

Version 2 has a lot of features that are missing in Version 1, but the
lease files and configuration files should be upward-compatible (they
are definitely _not_ downward-compatible).  The main difference you'll
probably notice immediately is that the DHCP server tries to ping IP
addresses before it assignes them in response to DHCPDISCOVER
messages.   This introduces a 1-second delay in responding to
DHCPDISCOVER messages, but has the nice effect of preventing the
server from assigning addresses to clients that will cause IP address
conflicts.

> 3) Is it as easy as moving the new DHCPD into place and 
> restarting the server?

Pretty much.

> If you think I should stick with the latest 1.x instead that's OK too.

It's really a judgement call on your part.  2.0 is bigger and whizzier
than 1.0, and if you don't need the new features, you may regret
upgrading, but there are a lot of new features that have to do with
usability rather than new functionality - better error messages,
better documentation, better correctness WRT the DHCP protocol, actual
bug fixes, and so on.  In particular, the handling of duplicate leases
is much better.  I would never run 1.0 personally, but there's a lot
to be said for "if it ain't busted, don't fix it."

                               _MelloN_

            CHANGES FROM VERSION 2.0 BETA 1 PATCHLEVEL 24

- D'oh!   Fix a really stupid mistake in hash.c.

            CHANGES FROM VERSION 2.0 BETA 1 PATCHLEVEL 23

- Support an always-reply-rfc1048 flag, which says to reply with an
  RFC1048-style vendor extensions buffer even if the client didn't
  send an RFC1048-style magic number.

- Fix a null pointer dereference.

- Use netmask from subnet if no netmask option specified.

- IRIX support (thanks to Don Badrak).

- Install unformatted manual pages on Linux.

- Add note in README about zcat vs. gzcat on BSD/os.

            CHANGES FROM VERSION 2.0 BETA 1 PATCHLEVEL 22

- Test for lease before dereferencing it in dhcprequest.

- Free the client parameter request list in dhcpnak if there is one. 

            CHANGES FROM VERSION 2.0 BETA 1 PATCHLEVEL 21

- Fix a pasto in options.c that will cause a core dump whenever a
  client sends in a request without a parameter request list.

            CHANGES FROM VERSION 2.0 BETA 1 PATCHLEVEL 20

- Actually do the client fix mentioned below - Patchlevel 20 only contained
  half of the fix.

            CHANGES FROM VERSION 2.0 BETA 1 PATCHLEVEL 19

- Removed arp table clearing code from solaris client script.

- Document Linux "protocol not configured" error more thoroughly.

- Clean up some unused variables.

- Add entry and exit hooks to all dhcp client scripts, along with a
  make_resolv_conf function that can be redefined in the entry hooks.
  Document this new feature set.

- Fix client to take advantage of network APIs that allow it to
  receive a unicast instead of requesting that the DHCP server
  broadcast its response.

- Add -pf flag to all daemons allowing user to specify PID file name
  on command line.

- Undo a previous change that attempted to be clever about testing
  interface flags but wound up being stupid instead.

- Enforce access control on DHCPREQUEST messages as well as
  DHCPDISCOVER messages.

            CHANGES FROM VERSION 2.0 BETA 1 PATCHLEVEL 18

- Support added for AIX 4.1.5.0 (and hopefully other versions).

- Use /var/run instead of /etc on Digital Unix.

- Change DHCP client exponential backoff code to back off more slowly,
  so that it is more robust in lossy environments, at the expense of
  being a bit less polite to the server.

- Don't request a specific lease interval in the client unless the
  user says to do so.

- Don't print DHCPXXX in wrong xxx messages unless DEBUG is defined.

- Fix handling of secs field.

- Fix handling of append statement.

- Fix documentation for append and prepend statements.

- Fix server support for parameter request list and maximum message
  size.

- Parameterize more hardware types in discover_interfaces.   Check for
  IFF_BROADCAST instead of !IFF_POINTOPOINT

- Print kernel configuration warning message if we get EINVAL when
  opening or configuring the Linux packet filter.

- Fix a bug in UDP checksum code (thanks to John Nemeth for figuring
  this out) and re-enable UDP checksumming.   This allows the client
  to work with some buggy DHCP servers that can't handle zero
  checksums in the UDP header - in particular, the one John's cable
  modem ISP is using.

- Don't report packet header checksum errors unless we see a lot of
  them.   It's perfectly normal for some number of checksum errors to
  occur.

- Refer to the dhcpd.leases man page when printing an error message
  prior to exiting because there's no lease database.

- Add information to the README telling the reader how to get to the
  manual pages.

- Fix the server packet transmission code to unicast when it can.

- Fix a typo in the dhcpd.conf manual page.



------------------------------------------------------------------------------
To unsubscribe from this list, please visit http://www.fugue.com/dhcp/lists
If you are without web access, or if you are having trouble with the web page,
please send mail to [EMAIL PROTECTED]   Please try to use the web
page first - it will take a long time for your request to be processed by hand.
------------------------------------------------------------------------------

Reply via email to