*** From dhcp-server -- To unsubscribe, see the end of this message. ***
BTW, I said that the DHCP server will Just Work with the configuration
you described, but that's not quite true - you do need to write a
subnet declaration for both of the subnets you're running on the
network wire
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
You have an old draft. The relay agent information option now
encompasses both the agent circuit ID and the agent remote ID. This
option is in fact supported, although you can't get the server to
generate it - it's
I'm running ISC DHCP 2.0bpl6 server and am using 7 day lease times. I
would like to change these to 4 hour lease times. Are there any negative
ramifications to just making the change in the dhcpd.conf file, stopping and
starting the DHCP service?
No, that's exactly how you're supposed to do
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
You should upgrade to patchlevel 27 - patchlevel 6 is obsolete.
However, that won't solve your problem - the error message that you're
reporting means that although your kernel is configured with the
Berkeley Packet
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
What follows is an example portion of the /usr/etc/bootptab from the Indigo:
-
# root of boot subtree...
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Using DHCP I can see how to configure the DNS servers and the domain that
a host belongs to. But how can I configure DHCP so that I can supply a
list of domains for DNS to search through? Thanks.
Unfortunately,
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
*** Error code 1
make: Fatal error: Command failed for target `dhcpd.o'
That doesn't mean anything to me. What did it print before that, if
anything? And BTW, why 1.0pl2?
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Can you send us the output of ``tcpdump -e -x -s 1500 udp port 67''
while you're trying to get the DHCP client to boot? Also, WRT your
ipchains configuration, make sure you aren't blocking packets from
0.0.0.0 or to
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
It is a book that is currently being written. Hey Ted, any
release date for the book?
I don't know if the publisher would allow me to say, so I won't.
"Soon" is probably the safest thing to say. :')
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
I couldn't find any other reference to DHCP Handbook in the archives. Is it
something not yet available/accessible? Thanks.
It's not out yet, no. That's why I'm writing on it... :') Ralph
Droms and I are both
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
The DHCP static-routes option is broken anyway because it doesn't
allow you to specify a subnet mask for the network to which the route
goes. So yes, you have to hack it up. You can't change the
static-routes
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
You need to define the option on the client side as well as the server
side to get it to come out pretty-printed.
_MelloN_
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
You need to define a routers option in order to get routing to the
Internet to work. Probably you should write a statement like
``option routers wallaby.brain-tree.com;'' in place of the
commented-out entry for
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
You need to upgrade to a more recent version of the DHCP server - pl6
is hopelessly obsolete at this point, even though it's only about a
year old. Sorry about that! You can get more recent versions at
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
I'm writing a chapter in the DHCP Handbook on automatic registration
of DHCP clients. I know that RIT has an implementation of this. I
also know that a number of other people have worked on such things in
the past.
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
The linux dhclient-script doesn't have support for the static routes
option. The NetBSD one does. There's no particular reason for this
- I just haven't propogated the changes. You should be able to pull
the code
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
"/etc/dhcpd.conf line 12: Expecting class name
class customer
You need to put it in quotes! :')
_MelloN_
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
BTW, after receiving probably the third "how come I keep getting
errors when I try to declare classes" message, I realized that maybe
the man page was wrong. Of course, it is. Sorry about that.
It will be fixed in
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
It sounds like the answer from the DNS server isn't getting back to
the DHCP server. I'm afraid I don't have any specific suggestions to
fix it, but hopefully somebody else on the mailing list will.
BTW, It's not
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
The behaviour you're describing is definitely suboptimal. What
version are you running right now? Is the server hearing the
DHCPREQUEST? What message does it log?
_MelloN_
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
This actually sounds like a problem with your Linux machine, not
dhcpd. When the DHCP server unicasts a DHCPACK to a particular IP
address, it is up to the kernel's IP routing subsystem to figure out
where to send it.
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
- Use netmask from subnet if no netmask option specified.
I thought it did this all along?
In some cases yes, in some cases no. This just made it happen in all
cases. The main case where it didn't happen
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
I think the following in dhcpdiscover() requires parentheses around it:
Yipe! Thanks for catching that!
_MelloN_
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Since we moved to Redhat 5.2, with Linux-2.2.3 kernel, our OS/2 machines
receive no longer their addresses with BOOTP. I used several version
between dhcp2pl17-pl27, without difference. tcpdump on the server shows
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
I'm not a significant person, but maybe I can do it? ;)
Of course you're a significant person! :')
You can try, and if you succeed, I'll be interested in what you come
up with, but at this point I'm suspicious that
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
You need to set up relay agents on any network segment to which your
DHCP server is not directly connected. If you are using a commercial
router to connect these subnets, it probably already has a built-in
relay agent
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Are you sure you want to have this functionality subsumed within the
dhcp server? Next you'll want macros and conditional compilation and
diversions and everything else.
Um. 3.0 does have conditionals. And
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
I am trying to hack the V2 code a bit and have a question. In ack_lease()
is there any way I can determine if the ack being sent is in response to
the REQUEST for a new lease vs. the REQUEST for a renewal of an
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
We are looking for a way to have DHCP hand out the
gateway IP addresses in a flipflop order every time a system makes a
request.
Currently this is not supported, although it should be. It could be
complicated to
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Is this just my misunderstanding of the conf file? Or
is the server 2.0b1pl27 not obeying the netmask defined
there on passback? (Solaris 2.6). By the way, we have lots
of subnets that are 255.255.254.0, so it's
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
While I'm pretty sure this was the intended behavior (judging by the code in
supersede_lease() that creates a hash table entry for a new or updated
lease) I wonder if it is the best strategy in this circumstance? It
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Don't be skeptical, I couldn't get dhcpd V2.0b1pl27 to work without
tossing it into sockets mode.
I did ask people to report problems they were having. At this point
I'd say don't bother, though - if it works for
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
than ICMP echo request (from dhcpd as I guess), and after that -
packet of type IEEE 802.3 (LLC/802.3) of size 22 bytes. When I use
Solaris's dhcpd, snoop shows
It sounds like you're using token ring or something.
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
I'm assuming this would require two servers. Is anyone is doing something
like this with one server?
This doesn't require two servers - with version 3 of the DHCP server,
you can get this behaviour with one server
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
What you are reporting is probably a packet delivery problem, not a
server configuration problem. What we need to see are server logs
for the period where the client is failing to boot, and if that
doesn't turn
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
There are about a thousand different reasons why Win95 might say
"Access denied renewing adapter," which is why you haven't seen a
definitive answer about it. The "already acking" message means that
Win95 sent a second
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
I have a user who is running dhcp on his NT 4.0 laptop. When his machine
boots up and requests an IP address he is getting the broadcast address for
one of our subnets. Does anyone have any information about why
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
There's nothing obviously wrong with your configuration. I am
assuming that you have the broadcast address route set up as
documented in the README - without that, you won't win. Also, in a
subsequent message, you
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Did you restart your server after you changed the config file? I'm
sorry to ask such an obvious question, but the server is clearly
finding the host entry, which contains the always_reply_rfc1048 flag,
but is not
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
In 3.0, you can create a host entry for the printer and override all
the options you don't want to send with null values:
option domain-name-server ns1.foo.org, ns2.foo.org;
option domain-name "foo.org";
subnet
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
What I was wondering was why the server decided to give out a 2
minute lease period in each case. Is there a timer based on number
of discover messages received, in which it hands out a default
lease period, or is
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Okay, try adding "always-reply-rfc1048 true;" to the host
declaration.
_MelloN_
--
To unsubscribe from this
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Can you send me a hex dump of the packets? The snoop trace you send
is missing some key information - what did the packet the client sent
look like, the contents of the BOOTP packet header, and so on.
Unfortunately,
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
I have some patches to tcpdump to do this too Ted. I decode everthing I
have seen or wanted to see in a DHCP packet.
I would really encourage you to get these changes back to the tcpdump
maintainers. Have you
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
From the 2.0b1pl27 man page:
option netbios-name-servers ip-address [, ip-address... ];
The NetBIOS name server (NBNS) option specifies a list
of RFC 1001/1002 NBNS name servers listed
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Is there a way to force clients to pick up this
information? What am I missing?
I would expect that Windows would get the new information when next it
renewed the lease. There's no way to force renewals to occur
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Would this second dhcp server be sending something back to my test 95
box saying "sorry - no leases" and the 95 box is just giving up? I
think I just answered my own question - I unplugged the production
dhcp
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Not really. I am running it on 2.0.36 and didn't have that problem.
Seems that even distributions based on the same kernel differ in
that respect. (I have SuSE 6.0)
You won because you had a system library in your
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
this
is a real M$ solution... add hardware to fix the software...
I think the word you're looking for here is "kludge." I don't know
why you're singling out Microsoft - we're talking about a Linux
kludge here.
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Can you help to find out what does it mean ???
It means you're sending the broadcast-address option to the NT DHCP
client, and the NT DHCP client doesn't know what to do with it. It's
not a problem - you can safely
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
/tmp/dhcp-3.0.alpha-19990424/common/socket.c:124: undefined reference to
'error'
I've included a patch below that corrects the problem. I guess
you're the first person to compile 3.0 on Linux 2.0... Sorry about
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Nothing is wrong with your mail configuration - it just takes a long
time for the mail server to cycle through all 2000 subscribers, given
that many subscribers are in locations with slow internet service.
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Oh dear. The code under HAVE_SIOCGIFHWADDR !HAVE_IF_LINK is
supposed to take care of that. Is that not getting compiled on your
version of Linux? What version do you have?
_MelloN_
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
I have to disagree with you Ted. I have actually succesfully handed out
IPs to RAS ports and I have:
Yeah, yeah, yeah. So I was wrong. So sue me! :')
_MelloN_
P.S. No, please
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Never mind, I appreciate you're fast response. I would be lucky getting
such a fast support on commercial product!
So are you saying it worked? :')
Thanks for the script modifications - I'll take a look at them as
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
default-lease-time 600;
max-lease-time 7200;
The win95 client is getting your default lease time, which is 10
minutes, and renewing after five. That's why it loses touch with the
server so quickly.
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
I don't see anything wrong in your bpf configuration. Maybe you can
turn on promiscuous mode and copyall mode on your fta0 manually.
I think dhcpd daemon does this at startup automaticaly, so turning it on
manually
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Would it be possible to set the option time-offset to a unix
timezone file instead of hard-coding a time offset value into
the config file?
There's no way to portably support time zones in the lease file. I
just
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Is there a way to include (require) a file into the dhcpd.conf file?
Not currently. It would certainly be handy.
_MelloN_
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Is there a document somewhere that describes what the conf relationships
are between groups, pools, subnets, hosts and shared networks?
The manual page is the best that's currently available, although there
will be
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Oops. Try this patch (on top of the other).
_MelloN_
Index: options.c
===
RCS file:
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Argh. Okay, third time's the charm, maybe? :') I'm sorry to be
making you test these changes, but I don't have a way to test them
myself right at the moment.
_MelloN_
Index:
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Eh? I haven't used linux for bridging, but the entire point behind
bridging is that a bridge DOESN'T indiscriminately pass packets.
No, a bridge makes two network segments look like they are physically
connected.
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
new_host_name=62:61:67:68:65:65:72:61
^^^ This should have been the string
"bagheera", the hex values are correct.
I'm not that firm with the sourcecode, so I didn't
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Hm, actually, could you give the following patch a try?
_MelloN_
Index: options.c
===
RCS file:
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Which version of dhclient is that? It works just fine for me
(2.0pl6 - still)
It was changed after pl6 because some people using cable modems ran
into trouble with servers that wanted the hostname option to be NUL
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Also, I understand that the ISC DHCPd software will ping addresses before
assigning them. Does it report that an address is in use and not
legitimately leased? I could use this in a pinch to track stolen
addresses.
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
I am using PXE bootroms in a remote-boot environment. PXE bootroms set
the DHCP tag 55 (PARAM_REQ_LIST) and specify a minimum priority list. This
list does not include any of my site specific tags (128).
From
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
So here's the problem, on my sun server I have
the in.dhcpd that came with the OS and I which to convert it to isc's.
A slice from my dhcptab:
I'm not entirely sure how to read those definitions, but I'll take a
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Argh. Sorry about that. This is the problem with new features.
Sigh. Well, on the bright side, thanks for testing the DHCPINFORM
code for me - you're the first person to actually send me any
information on it dumping
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Apr 23 18:21:20 arachne dhcpd: Non-null pointer in buffer_reference
(evaluate_option_cache)
This could be the DHCPINFORM core dump that was fixed in 19990424, but
if so, that would only have gotten you a little bit
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
BOOTREQUEST from 00:00:81:5a:3e:97 via lane1
No applicable record for BOOTP host 00:00:81:5a:3e:97 via lane1
in which way can i disable this message?
This is logged at the LOG_INFO level. If you don't want to
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Are you sure the ethernet address is correct? What version of the
DHCP server are you running?
_MelloN_
--
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Till this point it works... but whenever a client on eth0 issues
a dhcprequest, it gets bridged eth1 catches it to dhcpd, dhcpd sends it
out on eth1 and it's never to be seen on the eth0 segment...
Hm. I would
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
No, I meant 169.254 - I just didn't feel like looking it up. Thanks
for exercising due diligince on my behalf! :')
_MelloN_
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Oops, now that I think about it, it's stupider than gcc not catching
the error - I just didn't try to compile it on Solaris, so dlpi.c was
an empty file to the compiler. Sigh. It's a poor workman who
blames his
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
I don't actually see anything bad about the packet that's being sent
to the client, but it's possible that the checksum is screwed up. I
will be releasing a new patchlevel that fixes the UDP checksum bug
shortly, but
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
I've come up with my own change to the checksum code based on the BSD
checksum code. My reasoning is that the current code is a bit more
complicated than it needs to be. Can you try this patch out and let
me know if
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Option domain-name length 7 overflows input buffer
Our Domain entry look like this:
option domain-name"zkm.de";
Whats wrong?
A DHCP client on your network is sending a domain-name option
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Diff generates patches (diff files). Patch applies them. So if
you're trying to upgrade, use patch. But unless you have a bandwidth
shortage, save yourself the effort and just ftp the distribution.
The ISC ftp
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
You're making this way too easy for us.
No such thing. :')
_MelloN_
--
To unsubscribe from this list,
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Running DHCP on a different port won't help you. You should just
configure the DHCP server to serve the BOOTP clients as well as the
DHCP clients. To do this, create a host declaration for each BOOTP
client with a
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
I use ISC-DHCP version2 and my Platform is Solaris 2.6(INTEL).
Can this version DHCP server respond 'DHCP NACK'?
If this function is available, would you tell me how to start it?
The server will send a DHCPNAK when
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
In unrelated items, since v3 can do known/unknown pooling, where might
it store the list/db of known or unknown addrs ? I've been perusing the
code looking for it but have looked right over it or something...
It
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Put "ras-clients" in quotes.
_MelloN_
--
To unsubscribe from this list, please visit
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
The toughest problems that I have run in to on the OSX system is
where to find things and what are they using?! Their GUI account
manager is a case in point. It sure doesn't seem to use the
/etc/passwd and
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
I have checked my kernel configuration and YES both CONFIG_PACKE=
T and CONFIG_FILTER are set to "y". And I have
recompiled the kernel with this configuration and installed =
it.=20
A lot of
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
By the way, what version of 2.0b1 is recomended currently? I haven't
seen a "stable-ish" announcement since pl18.
Patchlevel 26 is as stable as Patchlevel 18, AFAIK. I haven't been
doing announcements
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Hmm, I just looked at what I was running, 2.0b1pl6 :) Guess I should
upgrade!
PL6 was around so long that it got swept into a lot of Linux
distributions - that's probably why you have it... :') Upgrading
sounds
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
this actually seems like a useful feature... this might be something with
somewhat wider applicability than masking on NIC addresses
I sure hope so! It was a lot of work to implement, after all! :')
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
I"m very eager to play with this, what's the time frame look like for
stable releases of version 3?
Never, if nobody tries it now. Seriously, the April 12 snapshot is
pretty stable - you shouldn't feel major
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
So... here's the REQUEST from the client,
and the NAK from the server, and the lease in
the database for reference. Can anyone tell
off the top of their heads if this is a broken
client or a server oddity?
The
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
This is just a theory, but have you tried declaring a bootfile option
instead of using the filename declaration? It's possible that the
Intel prom won't use the filename field in the bootp packet. Try
this:
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
What sort of errors are you getting? Logs, man, we need logs! :')
_MelloN_
--
To unsubscribe from this
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Is the version 3 code stable enough at this point to use the "option picking
apart" feature?
I think so.
Also, what's the future look like on the failover protocol, i.e. when do you
expect that to be available?
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Yup, looks like a bug. It'll be fixed in the next snapshot. Thanks
for the bug report!
_MelloN_
--
To
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Here's a few ideas:
Hm. Okay, but I think forking subprocesses is probably the right
thing to do. It's just a matter of having the time to do it. You can
already watch the lease file, the syslog output or
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Has anyone compiled DHCP on Apple's OSX Server? Any help would be
great. Thanks in advance.
Nobody's mentioned it here. Have you tried just doing it? It might
well build using the Rhapsody configuration files.
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Hm. Dare I ask why/how you're unicasting a DHCPDISCOVER message?
Not that this should be a problem, mind you. I just took apart the
packet and couldn't find any other blatant problems with it, though.
I
*** From dhcp-server -- To unsubscribe, see the end of this message. ***
Argh. I accidentally tagged 2.0b1pl26 as 2.0b1pl21, so that's what
wound up in the tar files. I've re-tagged and put up a new tar file
and difference file. Sorry about the confusion.
1 - 100 of 145 matches
Mail list logo
