Re: Newbie help - DHCP

From: P Gentry (rdgentry1_at_cablelynx.com)
Date: 08/07/04


Date: 6 Aug 2004 15:14:57 -0700

Clive Dove <chdove@rogers.com> wrote in message news:<RFLQc.1487402$Ar.465235@twister01.bloor.is.net.cable.rogers.com>...
> Beemer Biker wrote:
>
[snip]
> >
> > I saw this response and have a question. (i am no linux expert) When
> > powering up several red hat 9 linux boxes set to use dhcp services, if
> > I forget to connect the ethernet cable it seems I never get assigned
> > an ip
> > address. To get the ip address i issue an "ifdown eth0" followed by
> > an
> > "ifup eth0". Why do i have to do this? How long is the delay between
> > those
> > broadcasts? Maybe I am not waiting long enough?
> >
> > ..thanks..
> >
>
> The whole thing works with the exchange of 4 packets each having less
> than 400 bytes, so it is fast if both sides are working at the same
> time.
>
> Your boot process invokes a dhcp client daemon that sends out a
> DISCOVERY packet to UDP port 67. Broadcast is needed because the
> client does not yet have an ip address and does not yet know the ip
> address of the server. There will be a retry schedule and a retry
> timeout.
>
> Every DHCP server daemon on the local subnet is listening (note that the
> broadcast is not routable so daemons on the larger net will not hear
> the broadcast). When a server daemon hears a broadcast on port 67 it
> broadcasts an OFFER packet to UDP port 68, Which is the port on which
> the DHCP client daemon is listening. The offer contains an ip address
> which is taken from the server daemon's pool.
>
> Note that both have to be working else the server won't hear the
> DISCOVERY packet and therefor will not send an OFFER packet.
>
> So when you booted a machine that did not have its cable connected, the
> DISCOVERY packet went nowhere and so the OFFER packet was not sent. By
> the time that you had connected in the cable, the DHCP client daemon
> had stopped sending and therefore there was no broadcast OFFER for it
> to hear.
>
> When you then issued an ifdown and an ifup, you caused the client daemon
> to again send out an OFFER packet, just as if you had rebooted.
>
> All DHCP server daemons on the local net will be sending out OFFER
> packets (in most local nets, this means the only server that is on the
> net, but it is possible for more than one daemon to respond) and the
> client will usually accept the first offer that it hears but on more
> complicated nets, there may be a set of criteria to determine which
> offer will be accepted.
>
> The client daemon will then broadcast a REQUEST packet which accepts the
> offer and requests the parameters needed to communicate.
>
> The server daemon will then broadcast an ACKNOWLEDGE packet which
> assigns the necessary parameters for a preset lease duration.
>
> Any other servers that have made an offer will have heard the request
> packet and will have returned their offered ip addresses to their
> pools.
>
> Everything up to this point is done using UDP broadcasts. Up to this
> point there is no direct connection between client and server.
>
> At this point the client machine sets up the connection, using the
> assigned parameters, in the same manner as a static ip connection. The
> DHCP client daemon has nothing further to do until time comes to seek
> to renew the lease or until you reboot.
>
>
> Clive
>
>
> Clive

Just a note to let you know this is about as succinct and clear an
explanation as I've seen.

Wish I wrote it ;-)

regards,
prg
email above disabled



Relevant Pages

  • Packet cap diff... for classic dhcp over winxp s/w bridge prob.
    ... the server simultaneously. ... DHCP Discover - Transaction ID 0xe5448fbb ... Time delta from previous packet: ... Time since reference or first frame: ...
    (comp.os.linux.networking)
  • Interesting TCP behaviour with large sends/small buffers
    ... The server, upon connection, sends a configurable number of bytes to ... I set the client's receive buffer size to 1MBps, ... packet before sending the next packet. ... ACK, according to the delayed ACK algorithm - 50KB bytes means 34 MSS- ...
    (microsoft.public.win32.programmer.networks)
  • Re: How to terminate a socket in CLOSE_WAIT state
    ... FTP Server fixed for certain FTP clients who use both passive ... This was causing a PASSIVE opened socket to be left ... but instead expect the "half close" from the receiver. ... this sends a TCP/IP FIN packet to the ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Sockets class question - sending TCP data
    ... Announcement DEV02, Workstation, Server, SQL Server, NT Workstation, NT ... Time delta from previous packet: ... Receiver's Name: DYNAMICSYSTEMS(Local Master Browser) ... You say that you did this in a Java applet. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: peer to peer messaging
    ... attempts to open a connection to port 80 of the server at that IP address. ... For example a packet from my machine might have source IP ... Packets from the sever to my laptop would have those reversed. ...
    (comp.lang.java.programmer)