Newbie help - DHCP

I'm a networking newbie although have administrated various networks in the
past, so know the terminology.

If I want to set up a DHCP network under Linux, I presume I have to assign
the Ethernet port a localhost-style address (ie 192.168.1.1) and then
assign addresses above this to the DHCP lease range?

I then plug this machine into a hub with the rest of the machines and they
somehow sniff out the DHCP machine when they boot and ask for an address...
right?

Might sound obvious to you but most tutorials assume you already know this
bit and go into detail on all the rest of the setting up stuff.

.... and if I want to turn this into an Internet router, I can add a second
network card, plug that into a WAN router (ie a cable modem box), and share
the connection...? What configuration in Linux is necessary to let this
happen?

On Fri, 16 Jul 2004 19:07:43 +0000 (UTC), Randy Sparks wrote:

> I'm a networking newbie although have administrated various networks in the
> past, so know the terminology.
>
> If I want to set up a DHCP network under Linux, I presume I have to assign
> the Ethernet port a localhost-style address (ie 192.168.1.1) and then
> assign addresses above this to the DHCP lease range?
>
> I then plug this machine into a hub with the rest of the machines and they
> somehow sniff out the DHCP machine when they boot and ask for an address...
> right?
>
> Might sound obvious to you but most tutorials assume you already know this
> bit and go into detail on all the rest of the setting up stuff.
>
> ... and if I want to turn this into an Internet router, I can add a second
> network card, plug that into a WAN router (ie a cable modem box), and share
> the connection...? What configuration in Linux is necessary to let this
> happen?

Smoothwall is a fine Linux distribution that is perfectly suited for your
goal, that is, if you have an old machine laying around somewehere. It will
then act as a stand alone firewall between the RED zone (the internet) and
the GREEN zone (your then protected network).

In my setup, I wired the GREEN nic to a hub.

Given a third nic, you also have the option to implement a DMZ.

Apart from the DHCP server, the system also has an intrusion detection
system, a web proxy, a caching dns, port forwarding possibilities,
etcetera.

Best of all: it's freeware!

Have a look at their website: http://www.smoothwall.org

--
There's no place like 127.0.0.1
Gerard Wassink http://linux.family.filternet.nl
Linux counter #360967, "In a world without fences, who needs gates?"

Well, setting up dhcpd won't be much of a problem for you, at least
.... when I see your detail posting. Now, whatever your distro would
be, find a file name as dhcpd.conf. If it's not there, you have to
install that from rpmfind.net, if you are using any rpm based distro.
Here is a sample entry for that conf file from Brian W. Carver. He
wrote that in details. Just have a look.

# dhcpd.conf
#
# Brian's configuration file for ISC dhcpd
#
# April 4 2002
# option definitions common to all supported networks...
# Change domain-name to your domain name. I just preceeded my ISP with
# the name of my Linux computer.
option domain-name "debian.charterpipeline.com";

# The domain-name-servers you enter here will be used by all other
# computers on your LAN. They are ip addresses of your ISP's.
option domain-name-servers 24.205.1.62;

# This just tells all the other computers that you're a Class C
network.
# If you're using the 192.168.x.x address, you're Class C. Don't
change
# the IP address for this. It really should be 255.255.255.0
option subnet-mask 255.255.255.0;

# I went with the default lease times. I guess they could be longer.
default-lease-time 600;
max-lease-time 7200;

# These next two are important. They are your primary computer, I
think.
option broadcast-address 192.168.0.255;
option routers 192.168.0.1;

# Here's where you set up your range of Dynamic IP Addresses. I set
mine
# for 10 because I don't honestly think I'll have more than 10
computers
# hooked up. It is in this range that your Laptop will have an IP
Address
# of. You could certainly set it to a range of 100-255 if you want,
# reserving the first 100 IPs for Static.
subnet 192.168.0.0 netmask 255.255.255.0 {
range 192.168.0.1 192.168.0.10;
}

# And here's where you can start setting up your Desktop computers and
# their static IP addresses. I honestly don't know what the "host" is
used
# for, so I decided to make it a "Tag" so I know what computer it is.
I
# don't have the MAC addresses memorized!
#
# When you do a winipcfg on your Windows boxen, the MAC Address is the
# hardware address given here. The fixed address is the Static IP you
want
# to assign to that computer.
host debian.charterpipeline.com {
hardware ethernet 00:C0:F0:56:2E:E9;
fixed-address 192.168.0.1;
}
host JSDESKTOP {
hardware ethernet 00:A0:CC:76:76:AB;
fixed-address 192.168.0.2;
}

host LAPTOP {
hardware ethernet 00:E0:98:73:5E:F7;
fixed-address 192.168.0.3;
}
host JSLAPTOP {
hardware ethernet 00:00:00:00:00:00;
fixed-address 192.168.0.4;
}

## eof

hth

raqueeb hassan
kinshasa (drc)

Randy Sparks wrote:

> I'm a networking newbie although have administrated various networks
> in the past, so know the terminology.
>
> If I want to set up a DHCP network under Linux, I presume I have to
> assign the Ethernet port a localhost-style address (ie 192.168.1.1)
> and then assign addresses above this to the DHCP lease range?
>
> I then plug this machine into a hub with the rest of the machines and
> they somehow sniff out the DHCP machine when they boot and ask for an
> address... right?
>
> Might sound obvious to you but most tutorials assume you already know
> this bit and go into detail on all the rest of the setting up stuff.
>
> ... and if I want to turn this into an Internet router, I can add a
> second network card, plug that into a WAN router (ie a cable modem
> box), and share the connection...? What configuration in Linux is
> necessary to let this happen?


If you are talking about the client machines, you don't have to give
them any ip address. The client machine has a dhcp client daemon that
broadcasts ip 0.0.0.0 to port 67. The router listens on that port and
it's dhcp server daemon broadcasts an offer to port 68. The ip address
that it offers is from its pool of ip addresses, probably in a private
range such as 192.168.1.0. The client machine is listening on that port
and accepts the offered ip address and sets up the connection. From
that point on until it is time to renew the lease that was given by the
server the client behaves like any client with a static ip addrss.

The above is a gross over-simplification but it gives the general idea.

Why not simply get an inexpensive router such as the Linksys BEFSR41 and
plug the client machines into it. Such routers use DHCP by default but
they can be configured to use static ip. Current linux distributions
use DHCP by default and so the DHCP client is installed by default.


Clive

"Clive Dove" <(E-Mail Removed)> wrote in message
news:_sgPc.40$(E-Mail Removed) gers.com...
<snip>
>
> If you are talking about the client machines, you don't have to give
> them any ip address. The client machine has a dhcp client daemon that
> broadcasts ip 0.0.0.0 to port 67. The router listens on that port and
> it's dhcp server daemon broadcasts an offer to port 68. The ip address
> that it offers is from its pool of ip addresses, probably in a private
> range such as 192.168.1.0. The client machine is listening on that port
> and accepts the offered ip address and sets up the connection. From
> that point on until it is time to renew the lease that was given by the
> server the client behaves like any client with a static ip addrss.
>
> The above is a gross over-simplification but it gives the general idea.
>

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..


================================================== =====================
Beemer Biker (E-Mail Removed)
Seti WU 45K Seti Years 43 Ask about my 99'R1100RT
New Boneher V-Twin...
http://pages.sbcglobal.net/jstateson...hisherbike.jpg
================================================== =====================

Beemer Biker wrote:

>
> "Clive Dove" <(E-Mail Removed)> wrote in message
> news:_sgPc.40$(E-Mail Removed) gers.com...
> <snip>
>>
>> If you are talking about the client machines, you don't have to give
>> them any ip address. The client machine has a dhcp client daemon
>> that
>> broadcasts ip 0.0.0.0 to port 67. The router listens on that port
>> and it's dhcp server daemon broadcasts an offer to port 68. The ip
>> address that it offers is from its pool of ip addresses, probably in
>> a private range such as 192.168.1.0. The client machine is listening
>> on that port and accepts the offered ip address and sets up the
>> connection. From that point on until it is time to renew the lease
>> that was given by the server the client behaves like any client with
>> a static ip addrss.
>>
>> The above is a gross over-simplification but it gives the general
>> idea.
>>
>
> 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

"Clive Dove" <(E-Mail Removed)> wrote in message
news:RFLQc.1487402$(E-Mail Removed) t.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.

<snip again>

>
> 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.
>

Thanks Clive, I think windows works the same way in that once I get a 169.x
and later the network comes up, I have to issue a renew to get the proper
192.x from the router.

However, I was wondering if linux has the capability of retrying the network
until it finally comes up. The example I gave with the ethernet cable being
disconnected was oversimplified. Actually, we have a wireless modem on a
mobile system with a linux box http://tinyurl.com/4ucvr. I would like to
use dhcp instead of fixed ip addresses. In the event the system reboots
(for whatever reason) and the mobile unit is out of range of the dhcp
server, I never get an ip address. I assume I can always write some code to
perodically retry the connection but thought that linux could handle this
for me. Notebook systems with XP and WIN2K seem to do a better job of
establishing a connection.

Clive Dove <(E-Mail Removed)> wrote in message news:<RFLQc.1487402$(E-Mail Removed) et.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

Beemer Biker wrote:

>
> "Clive Dove" <(E-Mail Removed)> wrote in message
>
news:RFLQc.1487402$(E-Mail Removed) t.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.
>
> <snip again>
>
>>
>> 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.
>>
>
> Thanks Clive, I think windows works the same way in that once I get a
> 169.x and later the network comes up, I have to issue a renew to get
> the proper 192.x from the router.
>
> However, I was wondering if linux has the capability of retrying the
> network
> until it finally comes up. The example I gave with the ethernet cable
> being
> disconnected was oversimplified. Actually, we have a wireless modem
> on a
> mobile system with a linux box http://tinyurl.com/4ucvr. I would like
> to
> use dhcp instead of fixed ip addresses. In the event the system
> reboots (for whatever reason) and the mobile unit is out of range of
> the dhcp
> server, I never get an ip address. I assume I can always write some
> code to perodically retry the connection but thought that linux could
> handle this
> for me. Notebook systems with XP and WIN2K seem to do a better job of
> establishing a connection.


The following may help:

You may wish to review the documentation on the ISP dhcp client
"dhclient" and its configuration file "dhclient.conf"

In mandrake the package name is dhcp-client-3.0.1-5mdk which installs
these files:
/sbin/dhclient
/sbin/dhclient-script
/usr/share/doc/dhcp-client-3.0.1
/usr/share/doc/dhcp-client-3.0.1/dhclient.conf
/usr/share/man/man5/dhclient.conf.5.bz2
/usr/share/man/man5/dhclient.leases.5.bz2
/usr/share/man/man8/dhclient-script.8.bz2
/usr/share/man/man8/dhclient.8.bz2

Note that /etc/dhclient.conf is not installed by the rpm package and
therefor the dhcp client by default in Mandrake uses only the default
values.

However, the file contains parameters to set the retry timeout and the
retry interval. Note the manner in which the retry interval lengthens
after the first retry until it hits the timeout.

Read this man page
man dhclient.conf

And read the man pages that are referred to in that man page.

Also, in Mandrake there is documentation
in /usr/share/doc/chdp-clinet-3.0.1/dhclient.conf

I assume that the man page and similar documentation will be available
in your distribution.

Clive