Fw: [SLUG] DHCPCD diagnostic assistance needed

From: Ter (ter450@tampabay.rr.com)
Date: Fri May 17 2002 - 22:55:22 EDT


FW: [SLUG] DHCPCD diagnostic assistance neededPaul..
I was not sure if you ever resolved your problem, but wanted to give you
some feed back on what maybe causing it...
A dhcp request should always be a broadcast... 255.255.255.255 (hey I need
an IP)
the "ack" is a directed broadcast... to 255.255.255.255 but you got to have
the mac of the guy that requested an IP or your stack discards the
packet..if you are the right mac then boom, you have an IP and can do
tcp/ip. Remember until this process completes a client machine has no way to
communicate other than with broadcasts
"... broadcasting DHCP_REQUEST for 4.47.192.209"
How can this be?? evidently a machine(s)have cached the ip of the DHCP
server and it is no longer there. I see several networks refered to below
there should only be two from the routers perspective
if this is a router the DHCP server should only be bound to the private IP
nic. and that nic should be static you can't mix private and public ips on
the same segment. Logicaly the network should look like
Client----DHCP Server----router----internet (the way I do it at home).
in this example everything to the left of the router has a private IP
(192.0.0.X) and is on the same physical segment. the router can then foward
these requests by stamping the packet with it's IP. A returned packet would
contain the routers IP but the MAC of the requesting machine. the router
would then foward the packet to the requesting machine because it knows it's
mac and the IP that goes with it from it's arp table.
Next example: (the way I do it at work)
Client PC in CLW----local servers----router--WAN----router-----st.pete
lan---DHCP Server
The cleint sends a broadcast to 255.255.255.255 but there is no DHCP server
in it's broadcast domain...The router hears the broadcast and picks it up.
we use a cisco command called DHCP-Helper. it takes the request and fowards
it to the IP specified in the router config (DHCP-HELPER=167.78.164.5) but
stamps the packet with it's own IP when the packet arrives at the dhcp
server it determines what IP to assign based on the network address
166.78.167.1 255.255.255.0 would tell the DHCP server that you want a class
C address on the 166.78.167.0 network. it looks at the available scopes to
see if it has that network if it does it sends the ack back to the router
which in turn sends it to the client. This allows me to control all the
scopes of addresses (we have two sets of 16 class C's each) from one
location. If it recieves a request from 255.255.255.255 it knows that the
machine must be on it local segment and "acks" accordingly (notice network
pun "acks")
the router has two nics one should only go to the dsl the other should have
the DHCP server or service and all the clients attached.
Blow out all the reservations, release all the IPs, and dump the arp table
in the router. statically assign the dhcp servers IP and all should be well
(baring any hardware issues). Few other things I am assuming is that you
are using 1 external NIC (as a DHCP server client) and one internal NIC
(that goes to the internal network). The internal NIC should have a static
IP and act as a DHCP server, or have another box acting as a DHCP server (on
the LAN). Private IP classes usually start with 10.x.x.x or 192.168.x.x.
The internal network (LAN) should have no other external connections to the
WAN, (unless you are talking about a RAS server, but that is another
adventure).

Pete

----- Original Message -----
From: "Glen" <gurensan@tampabay.rr.com>
To: <slug@nks.net>
Sent: Thursday, May 16, 2002 6:42 PM
Subject: Re: [SLUG] DHCPCD diagnostic assistance needed

> Paul,
>
> Here's the dhcpd.conf from my server at work:
>
> authoritative;
> default-lease-time 3000;
> max-lease-time 7200;
> option subnet-mask 255.255.255.0;
> option broadcast-address 192.168.1.255;
> option routers 192.168.1.1;
> option domain-name-servers 207.155.184.72, 206.173.119.72;
> ddns-update-style none;
>
> subnet 192.168.1.0 netmask 255.255.255.0{
> range 192.168.1.10 192.168.1.100;
> }
>
> I'm thinking that you don't have the 'option broadcast-address' line in
> there.
>
> Glen
>
> On Wednesday 15 May 2002 10:00 pm, you wrote:
> > Got some log entries for my firewall, roughly:
> >
> > ... broadcasting DHCP_REQUEST for 4.47.192.209
> > ... broadcastAddr option is missing in DHCP server response. Assuming
> > 4.47.207.255
> > ... DHCP_ACK received from (199.94.214.3)
> >
> > That second line disturbs me a little, and the connection is acting a
> > little flaky. Anyone know what this might mean?
> >
> > Paul



This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 18:55:56 EDT