Re: DHCPD and Windows question
On 02/15/2010 11:56 PM, Benjamin Scott wrote: My guess is your /etc/hosts file is misconfigured. And plenty of distros will cheerfully misconfigure /etc/hosts for you. For machines with static IP's, I've found the most reliable setup is like: 127.0.0.1 localhost localhost.localdomain 10.1.1.1foobox foobox.example.com -Bill -- Bill McGonigle, Owner BFC Computing, LLC http://bfccomputing.com/ Telephone: +1.603.448.4440 Email, IM, VOIP: b...@bfccomputing.com VCard: http://bfccomputing.com/vcard/bill.vcf Social networks: bill_mcgonigle/bill.mcgonigle ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: DHCPD and Windows question
On Sun, Feb 14, 2010 at 12:26 PM, Todd Littlefield t.littlefi...@comcast.net wrote: The server-identifier statement ... So, it needs to be set to the --hostname-- but they really mean --IP-- They really mean your hostname. Your hostname should resolve to an IP address unique to your host. Your hostname should not resolve to the loopback address (127.0.0.1). My guess is your /etc/hosts file is misconfigured. -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: DHCPD and Windows question
I finally got some time to sit down with Wireshark and compare the bootp packets between the D-Link and the Linux box... The first thing that jumped out as different was the source address on the DHCP Offer packets. D-Link: 192.168.1.1 Linux: 127.0.0.1 So, something wasn't right. I began mucking around with a bunch of different settings based on the dhcpd.conf(5) pages. None seemed to work... After looking a little closer at the server-identifier tag, it was misconfigured... I was using the name instead of IP address. The man pages are a bit confusing though... It states: Theserver-identifier statement *server-identifier* hostname*;* The server-identifier statement can be used to define the value that is sent in the DHCP Server Identifier option for a given scope. The value specified*must* be an IP address for the DHCP server, and must be reachable by all clients served by a particular scope. So, it needs to be set to the --hostname-- but they really mean --IP-- Why they didn't just specify it as: Theserver-identifier statement *server-identifier* *address;* I guess we will never know... Right below that is the server-name tag, which really is the name. So, if anyone else runs into this problem, the answer is RTFM --Carefully-- before adding things to the config. Thanks to everyone for their help! - Todd On 1/30/2010 11:03 PM, Brian St. Pierre wrote: On Fri, January 29, 2010 7:10 pm, Todd Littlefield wrote: If I disable the daemon on the server and use the one on the router, the Windows boxes are happy... But that makes me unhappy. I'm at my wits end trying to get it figured out. Can you get a wireshark capture of (a) the broken request and (b) the working request? Then compare the two and change whatever is needed in your config (one thing at a time) to make (a) look more like (b). -- Brian St. Pierre ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: DHCPD and Windows question
On 2/14/2010 12:26 PM, Todd Littlefield wrote: I finally got some time to sit down with Wireshark and compare the bootp packets between the D-Link and the Linux box... The first thing that jumped out as different was the source address on the DHCP Offer packets. D-Link: 192.168.1.1 Linux: 127.0.0.1 So, something wasn't right. I began mucking around with a bunch of different settings based on the dhcpd.conf(5) pages. None seemed to work... After looking a little closer at the server-identifier tag, it was misconfigured... I was using the name instead of IP address. The man pages are a bit confusing though... It states: Theserver-identifier statement *server-identifier* hostname*;* The server-identifier statement can be used to define the value that is sent in the DHCP Server Identifier option for a given scope. The value specified*must* be an IP address for the DHCP server, and must be reachable by all clients served by a particular scope. So, it needs to be set to the --hostname-- but they really mean --IP-- Why they didn't just specify it as: Theserver-identifier statement *server-identifier* *address;* I guess we will never know... Right below that is the server-name tag, which really is the name. So, if anyone else runs into this problem, the answer is RTFM --Carefully-- before adding things to the config. In the man page for dhcpd.conf, after the paragraph above, it says: The use of the server-identifier statement is not recommended - the only reason to use it is to force a value other than the default value to be sent on occasions where the default value would be incorrect.The default value is the first IP address associated with the physical network interface on which the request arrived. The usual case where the server-identifier statement needs to be sent is when a physical interface has more than one IP address, and the one being sent by default isn't appropriate for some or all clients served by that interface. Another common case is when an alias is defined for the purpose of having a consistent IP address for the DHCP server, and it is desired that the clients use this IP address when contacting the server. So, you would not normally use it at all. I've never had a reason to use it myself. I suspect, if you had an entry in /etc/hosts mapping your desired IP to that hostname, and used that hostname in server-identifier, it would work. An IP derived from a DNS lookup wouldn't, however. -- Dan Jenkins, Rastech Inc. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: DHCPD and Windows question
On 01/29/2010 07:10 PM, Todd Littlefield wrote:
The server in question is running CentOS 5.4 with dhcp-3.0.5-21 running.
I have a similar server running fine for those kinds of clients. The
config looks like:
ddns-update-style interim;
ignore client-updates;
allow booting;
allow bootp;
subnet 10.1.1.0 netmask 255.255.255.0 {
authoritative;
...
host ...
host ...
}
-Bill
--
Bill McGonigle, Owner
BFC Computing, LLC
http://bfccomputing.com/
Telephone: +1.603.448.4440
Email, IM, VOIP: b...@bfccomputing.com
VCard: http://bfccomputing.com/vcard/bill.vcf
Social networks: bill_mcgonigle/bill.mcgonigle
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: DHCPD and Windows question
On Fri, January 29, 2010 7:10 pm, Todd Littlefield wrote: If I disable the daemon on the server and use the one on the router, the Windows boxes are happy... But that makes me unhappy. I'm at my wits end trying to get it figured out. Can you get a wireshark capture of (a) the broken request and (b) the working request? Then compare the two and change whatever is needed in your config (one thing at a time) to make (a) look more like (b). -- Brian St. Pierre ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
DHCPD and Windows question
Hello,
I have a stupid question about how to configure the ISC DHCPD to
work with
Vista/Win7. At home I have XP and Linux systems running. They all will
broadcast
out to the network to find the server and request and address/lease.
The DHCPD server is configured to hand out the same address, based
on MAC
to all the machines/switches/etc. that are running internally. The
problem comes in when someone with a laptop running Vista or Win7 comes
over. According to M$ they
changed their DHCP client in Vista and 7 to rely on broadcasting to get
address.
From digging on the network, it seems to be that the broadcast flag
needs
to be enabled on the server side. Otherwise when clients beacon out to
get an
address, the server doesn't respond to it. (perhaps the incorrect choice of
words for the behavior)
I've dug through the ISC docs for the daemon. I thought the
always-broadcast command would do it... Unfortunately that is not the
case. There didn't seem to
be anything in the GNHLUG email archives about this problem.
If I disable the daemon on the server and use the one on the router,
the Windows
boxes are happy... But that makes me unhappy. I'm at my wits end
trying to get it
figured out.
The server in question is running CentOS 5.4 with dhcp-3.0.5-21
running. The running config is attached. I'm sure I there are multiple
things that could be set up better but it passes parsing and works, at
least until someone visits.
Any and all help is greatly appreciated. Thanks in advance!
- Todd
#
# dhcpd.conf
#
server-identifier my.domain.net;
default-lease-time 86400;
ddns-update-style ad-hoc;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.1;
option domain-name my.domain.net;
option domain-name-servers 192.168.1.10,68.87.71.226,68.87.73.242;
option netbios-name-servers 192.168.1.10;
always-broadcast on;
authoritative;
# these were for setting up the comcast modem... ignore
#option domain-name-servers 68.87.64.140,68.87.66.135;
subnet 192.168.1.0 netmask 255.255.255.0 {
range dynamic-bootp 192.168.1.101 192.168.1.200;
}
host dd-wrt.my.domain.net {
hardware ethernet 00:1A:70:71:6E:66;
fixed-address 192.168.1.2;
}
host dgs-1224t.my.domain.net {
hardware ethernet 00:24:01:63:9a:4b;
fixed-address 192.168.1.5;
}
host chaos.my.domain.net {
hardware ethernet 00:50:DA:7D:66:42;
fixed-address 192.168.1.10;
}
host iscsi.my.domain.net {
hardware ethernet 00:0f:3d:88:2c:a3;
fixed-address 192.168.1.11;
}
host myth-backend.my.domain.net {
hardware ethernet 00:13:D3:E9:DD:0D;
fixed-address 192.168.1.12;
}
host linkstation.my.domain.net {
hardware ethernet 00:16:01:bc:3c:54;
fixed-address 192.168.1.13;
}
host epson810.my.domain.net {
hardware ethernet 00:00:48:76:b1:c9;
fixed-address 192.168.1.18;
}
host ps20fe54.my.domain.net {
hardware ethernet 00:c0:02:20:fe:54;
fixed-address 192.168.1.19;
}
host mayhem.my.domain.net {
hardware ethernet 00:a1:b0:80:37:6b;
fixed-address 192.168.1.21;
}
host entropy.my.domain.net {
hardware ethernet 00:0c:76:c0:37:90;
fixed-address 192.168.1.22;
}
host delta-s.my.domain.net {
hardware ethernet 00:0F:3D:88:2C:99;
fixed-address 192.168.1.23;
}
host mythtv.my.domain.net {
hardware ethernet 00:E0:18:BF:2A:D8;
fixed-address 192.168.1.24;
}
host myth-bedroom.my.domain.net {
hardware ethernet 00:16:44:86:72:67;
fixed-address 192.168.1.25;
}
host myth-livingroom.my.domain.net {
option broadcast-address 192.168.1.255;
hardware ethernet 00:26:2d:10:b9:5c;
fixed-address 192.168.1.26;
}
host jenlaptop.my.domain.net {
hardware ethernet 00:13:E8:87:68:97;
fixed-address 192.168.1.100;
}
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: DHCPD and Windows question
Hi! After perusing your e-mail, I have a few things to say, and one idea: First, to the best of my knowledge, *no* major OS requires a broadcast response from a DHCP server in response to a request, as per RFC 2131. (It does leave some wiggle room, but this is almost certainly for clients that were having trouble modifying their TCP stacks to implement DHCP correctly -- HP/UX comes to mind -- and not for modern-day OSes. (See RFC 2131, near the end of section 2.0, for two pertinent paragraphs.) I'd be very interested to see an MS page that says that any current version of Windows requires a broadcast from the server. One thing that *does* seem to stand out is the authoritative parameter. According to the manpage, If the server finds the address the client is requesting, and that address is available to the client, the server will send a DHCPACK. If the address is no longer available, or the client isn't permitted to have it, the server will send a DHCPNAK. If the server knows nothing about the address, it will remain silent, unless the address is incor- rect for the network segment to which the client has been attached and the server is authoritative for that network segment, in which case the server will send a DHCPNAK even though it doesn't know about the address. My interpretation of this is that the client, already having a lease from some other network, requests an IP address -- apparently, one incorrect for the network segment (I'm not sure if that means it's for a different subnet, or conflicts with one of the current addresses), and the server sends out a DHCPNAK, telling the client to fly a kite. I'd take out the authoritative bit -- as well as the always-broadcast -- and give it another try. $.02, YMMV, etc. -Ken On Fri, January 29, 2010 7:10 pm, Todd Littlefield wrote: Hello, I have a stupid question about how to configure the ISC DHCPD to work with Vista/Win7. At home I have XP and Linux systems running. They all will broadcast out to the network to find the server and request and address/lease. The DHCPD server is configured to hand out the same address, based on MAC to all the machines/switches/etc. that are running internally. The problem comes in when someone with a laptop running Vista or Win7 comes over. According to M$ they changed their DHCP client in Vista and 7 to rely on broadcasting to get address. From digging on the network, it seems to be that the broadcast flag needs to be enabled on the server side. Otherwise when clients beacon out to get an address, the server doesn't respond to it. (perhaps the incorrect choice of words for the behavior) I've dug through the ISC docs for the daemon. I thought the always-broadcast command would do it... Unfortunately that is not the case. There didn't seem to be anything in the GNHLUG email archives about this problem. If I disable the daemon on the server and use the one on the router, the Windows boxes are happy... But that makes me unhappy. I'm at my wits end trying to get it figured out. The server in question is running CentOS 5.4 with dhcp-3.0.5-21 running. The running config is attached. I'm sure I there are multiple things that could be set up better but it passes parsing and works, at least until someone visits. Any and all help is greatly appreciated. Thanks in advance! - Todd -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
