From ameen.shajahan at wipro.com Mon Apr 2 11:03:45 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Mon, 2 Apr 2012 11:03:45 +0000 Subject: Client has not able to get IPv6 address?? Message-ID: Hi all, I have tested the dhcpv6 server using ISC dhcp-4.2.3. while issuing ipconfig /renew from client side it shows the below output. Its not assigning IPv6 address to the client. Also there is a subnet declaration 3ffe:501:ffff:101::/64 in conf file. What could be the problem?? Please let me know . ./dhcpd -6 -d -f -cf /etc/dhcpd-dhcpv6.conf -lf /var/db/dhcpd6.leases eth0 Internet Systems Consortium DHCP Server 4.2.3 Copyright 2004-2011 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Wrote 0 deleted host decls to leases file. Wrote 0 new dynamic host decls to leases file. Wrote 0 leases to leases file. Bound to *:547 Listening on Socket/5/ixp0/3ffe:501:ffff:101::/64 Sending on Socket/5/ixp0/3ffe:501:ffff:101::/64 Solicit message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0x9EE956 Unable to pick client address: no addresses available Sending Advertise to fe80::c8b0:62f6:fd72:7074 port 546 send_packet6: Cannot assign requested address dhcpv6: send_packet6() sent -1 of 88 bytes Solicit message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0x9EE956 Unable to pick client address: no addresses available Sending Advertise to fe80::c8b0:62f6:fd72:7074 port 546 send_packet6: Cannot assign requested address dhcpv6: send_packet6() sent -1 of 88 bytes Regards, Ameen S Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From oskar.berggren at gmail.com Mon Apr 2 11:41:17 2012 From: oskar.berggren at gmail.com (Oskar Berggren) Date: Mon, 2 Apr 2012 13:41:17 +0200 Subject: Client has not able to get IPv6 address?? In-Reply-To: References: Message-ID: Den 2 april 2012 13:03 skrev : > Hi all, > > ??????????????? I have tested the dhcpv6 server using ISC dhcp-4.2.3. while > issuing ipconfig /renew from client side it shows the below output. > > ??????????????? Its not assigning IPv6 address to the client. > > ??????????????? Also there is a subnet declaration 3ffe:501:ffff:101::/64 in > conf file. > > > Unable to pick client address: no addresses available > Have you used the range6 declaration? Also, have you considered just using stateless autoconfiguration for IPv6 addresses? /Oskar From gator_ml at yahoo.de Mon Apr 2 13:12:10 2012 From: gator_ml at yahoo.de (Peter Daum) Date: Mon, 2 Apr 2012 14:12:10 +0100 (BST) Subject: No subject Message-ID: <1333372330.86745.YahooMailMobile@web171601.mail.ir2.yahoo.com> http://gamereviews.co.in/wp-post-thumbnail/02efpk.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andre.Albsmeier at siemens.com Mon Apr 2 16:10:09 2012 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Mon, 2 Apr 2012 18:10:09 +0200 Subject: How to make dhcpd send NAKs instead of silently ignoring DHCPREQUESTS? Message-ID: <20120402161009.GA11723@bali> Using isc-dhcpd (now 4.2.3-P2) for years, I am now stuck with a problem I can't fix. First the relevant parts of dhcp.conf: authoritative; ddns-update-style none; default-lease-time 300; max-lease-time 600; min-lease-time 0; use-host-decl-names on; deny duplicates; one-lease-per-client on; subnet 192.168.24.0 netmask 255.255.255.0 { range 192.168.24.200 192.168.24.254; option broadcast-address 192.168.24.255; } host host1.domain.org { hardware ethernet 0:90:27:35:66:a2; fixed-address 192.168.24.11; default-lease-time 14400; min-lease-time 14100; max-lease-time 14700; } host host2.domain.org { hardware ethernet 0:18:f3:87:86:60; fixed-address 192.168.24.23; default-lease-time 14400; min-lease-time 14100; max-lease-time 14700; } (There are more host definitions scattered across the range 1 - 199 but for this example two are enough). When an unknown client does a DHCPDISCOVER it properly gets an address within the range 192.168.24.200 to 192.168.24.254. When one of the two known client comes, it gets its fixed address as stated above. But now an unknown client does a DHCPREQUEST of, let's say, 192.168.24.55 (an address where no host definitions exists). In this case the server remains silent and ignores the request as it is also documented in dhcpd.conf(5). But I want to NAK this address and force the client to do a DHCPDISCOVER (so it gets one from the range 192.168.24.200 to 192.168.24.254 above in turn). I added pool { range 192.168.24.1 192.168.24.199; deny unknown-clients; } which works w.r.t. to the DHCPREQUEST mentioned above but now when host2 wants to renew its (static) address I get this in the logfile: Apr 2 16:51:18 server dhcpd: Dynamic and static leases present for 192.168.24.23. Apr 2 16:51:18 server dhcpd: Remove host declaration host2.domain.org or remove 192.16 8.24.23 Apr 2 16:51:18 server dhcpd: from the dynamic address pool for 192.168.24.0/24 since 192.168.24.23 lies within the (now existing) pool ranging from 192.168.24.1 to 192.168.24.199. Since I may not use "deny unknown-clients;" outside of pools (as stated by dhcpd.conf(5)) how can I restrict the addresses in the range from 192.168.24.1 to 192.168.24.199 which are not taken by fixed-address statements from being ignored but instead NAK ack'ed on a DHCPREQUEST of 192.168.24.55? Thanks! From dhcp1 at thehobsons.co.uk Mon Apr 2 17:47:16 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Mon, 2 Apr 2012 18:47:16 +0100 Subject: How to make dhcpd send NAKs instead of silently ignoring DHCPREQUESTS? In-Reply-To: <20120402161009.GA11723@bali> References: <20120402161009.GA11723@bali> Message-ID: Andre Albsmeier wrote: >But now an unknown client does a DHCPREQUEST of, let's say, >192.168.24.55 (an address where no host definitions exists). >In this case the server remains silent and ignores the request >as it is also documented in dhcpd.conf(5). But I want to NAK >this address and force the client to do a DHCPDISCOVER (so >it gets one from the range 192.168.24.200 to 192.168.24.254 >above in turn). > >I added > >pool { > range 192.168.24.1 192.168.24.199; > deny unknown-clients; >} > >which works w.r.t. to the DHCPREQUEST mentioned above but now >when host2 wants to renew its (static) address I get this in >the logfile: > >Apr 2 16:51:18 server dhcpd: Dynamic and static leases >present for 192.168.24.23. >Apr 2 16:51:18 server dhcpd: Remove host declaration >host2.domain.org or remove 192.16 >8.24.23 >Apr 2 16:51:18 server dhcpd: from the dynamic address >pool for 192.168.24.0/24 > >since 192.168.24.23 lies within the (now existing) pool ranging >from 192.168.24.1 to 192.168.24.199. Firstly, is it a problem ? The client will either give up and revert to doing Discovers, or it will fail to connect to the network. As long as it doesn't try and use an address it's not been leased, then that isn't your problem as the administrator of the DHCP server. Unless the client is broken, it will only take a few extra seconds to get a network address - once it's realised it isn't getting an answer to it's requests. If it fails to revert to Discovers then it's broken and not your responsibility as the DHCP admin. If you are responsible for the client then take it up with the vendor. As to the rest, well you cannot include an address used in a fixed-address statement in any pool. The error message you quote was added in response to the numerous threads from people who expected the same operation as a Windows server and then complained that their "static assignments" were being leased out to other clients. There isn't a way to force NACKs of such addresses without triggering this error message - though I suppose you could comment that bit out in the code and recompile. There is potentially another way to do things. The ISC server now supports reserved leases - these are "normal" leases but even if expired will never be re-allocated to other clients. If you create reserved leases for your fixed address clients instead of using host statements then the addresses cannot be given to anything else and will result in a NACK in the circumstances you describe. You can either just extend your main range, or add small ranges to just include the addresses in question. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From oscars at mail.utexas.edu Mon Apr 2 20:30:50 2012 From: oscars at mail.utexas.edu (Oscar Ricardo Silva) Date: Mon, 02 Apr 2012 15:30:50 -0500 Subject: Upgrading server hardware on existing failover pair In-Reply-To: References: Message-ID: <4F7A0C7A.1080105@mail.utexas.edu> We currently have a pair of servers running ISC 3.1.3 in a failover configuration. Both physical servers are scheduled to be replaced with newer hardware and I'd like to bounce my plan off the list to be sure it's sane. 1. Shut down dhcpd on the secondary (gracefully). The primary should go into partner-down 2. Copy configuration and leases file from old secondary to new secondary 3. Bring up *NEW* secondary, make sure it can communicate on the network 4. Start dhcpd on the *NEW secondary and it should communicate with the primary and get updates 5. Wait until both servers are in the *NORMAL* state 6. Repeat these steps for the primary *SHOULD* this work without an expected interruption in service? I know during upgrades, things can and will go wrong but I'd like to avoid the obvious things as much as possible. Oscar From rgrimsha at syr.edu Mon Apr 2 20:58:16 2012 From: rgrimsha at syr.edu (Randall C Grimshaw) Date: Mon, 2 Apr 2012 20:58:16 +0000 Subject: Upgrading server hardware on existing failover pair In-Reply-To: <4F7A0C7A.1080105@mail.utexas.edu> References: , <4F7A0C7A.1080105@mail.utexas.edu> Message-ID: Technically, I think that at the time you gracefully shut down the peer, that you will not be in partner down mode. If you plan to be down long you will want to manually put the host into partner down mode or risk exhausting the half of your pool that is still available. This may not affect your transition, but it is a technical issue you should be aware of in an outage. - self inflicted or otherwise. Randall Grimshaw rgrimsha at syr.edu ________________________________________ From: dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org [dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org] on behalf of Oscar Ricardo Silva [oscars at mail.utexas.edu] Sent: Monday, April 02, 2012 4:30 PM To: dhcp-users at lists.isc.org Subject: Upgrading server hardware on existing failover pair We currently have a pair of servers running ISC 3.1.3 in a failover configuration. Both physical servers are scheduled to be replaced with newer hardware and I'd like to bounce my plan off the list to be sure it's sane. 1. Shut down dhcpd on the secondary (gracefully). The primary should go into partner-down 2. Copy configuration and leases file from old secondary to new secondary 3. Bring up *NEW* secondary, make sure it can communicate on the network 4. Start dhcpd on the *NEW secondary and it should communicate with the primary and get updates 5. Wait until both servers are in the *NORMAL* state 6. Repeat these steps for the primary *SHOULD* this work without an expected interruption in service? I know during upgrades, things can and will go wrong but I'd like to avoid the obvious things as much as possible. Oscar _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users From dhcp1 at thehobsons.co.uk Mon Apr 2 21:29:16 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Mon, 2 Apr 2012 22:29:16 +0100 Subject: Upgrading server hardware on existing failover pair In-Reply-To: <4F7A0C7A.1080105@mail.utexas.edu> References: <4F7A0C7A.1080105@mail.utexas.edu> Message-ID: Oscar Ricardo Silva wrote: >1. Shut down dhcpd on the secondary (gracefully). The primary >should go into partner-down As Randall points out, you need to do this state change manually. >2. Copy configuration and leases file from old secondary to new secondary You should only need to copy config, the "new" secondary will sync it's leases from the primary. Dunno which (if any) is considered "better", or if there's a speed difference. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From stenc at s-carlsen.dk Tue Apr 3 00:24:29 2012 From: stenc at s-carlsen.dk (Sten Carlsen) Date: Tue, 03 Apr 2012 02:24:29 +0200 Subject: Upgrading server hardware on existing failover pair In-Reply-To: References: <4F7A0C7A.1080105@mail.utexas.edu> Message-ID: <4F7A433D.3040907@s-carlsen.dk> Will there be complete communication between the servers? (I assume you will use newest versions on new servers) I seem to recall changes in protocol between some versions. On 02/04/12 23:29, Simon Hobson wrote: > Oscar Ricardo Silva wrote: > >> 1. Shut down dhcpd on the secondary (gracefully). The primary >> should go into partner-down > > As Randall points out, you need to do this state change manually. > >> 2. Copy configuration and leases file from old secondary to new >> secondary > > You should only need to copy config, the "new" secondary will sync > it's leases from the primary. > Dunno which (if any) is considered "better", or if there's a speed > difference. > > -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE MANURE!!!" -------------- next part -------------- An HTML attachment was scrubbed... URL: From henson at acm.org Tue Apr 3 00:45:35 2012 From: henson at acm.org (Paul B. Henson) Date: Mon, 2 Apr 2012 17:45:35 -0700 Subject: Upgrading server hardware on existing failover pair In-Reply-To: <4F7A433D.3040907@s-carlsen.dk> References: <4F7A0C7A.1080105@mail.utexas.edu> <4F7A433D.3040907@s-carlsen.dk> Message-ID: <20120403004535.GG19223@bender.csupomona.edu> On Mon, Apr 02, 2012 at 05:24:29PM -0700, Sten Carlsen wrote: > I seem to recall changes in protocol between some versions. Sorry to jump into the thread :), but we're planning on upgrading a failover pair from dhcpd 4.1.2 to 4.2.3 soon, and I've been trying to determine if we can upgrade one half at a time, or if we have to upgrade them both at the same time. Failover compatibility between versions doesn't seem well documented, at least I haven't found any. Can one half of a failover pair run 4.1 and other other 4.2 for a short interval without breaking things horribly? Thanks... -- Paul B. Henson | (909) 979-6361 | http://www.csupomona.edu/~henson/ Operating Systems and Network Analyst | henson at csupomona.edu California State Polytechnic University | Pomona CA 91768 From Andre.Albsmeier at siemens.com Tue Apr 3 05:41:50 2012 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Tue, 3 Apr 2012 07:41:50 +0200 Subject: How to make dhcpd send NAKs instead of silently ignoring DHCPREQUESTS? In-Reply-To: References: <20120402161009.GA11723@bali> Message-ID: <20120403054150.GA14829@bali> On Mon, 02-Apr-2012 at 19:47:16 +0200, Simon Hobson wrote: > Andre Albsmeier wrote: > > >But now an unknown client does a DHCPREQUEST of, let's say, > >192.168.24.55 (an address where no host definitions exists). > >In this case the server remains silent and ignores the request > >as it is also documented in dhcpd.conf(5). But I want to NAK > >this address and force the client to do a DHCPDISCOVER (so > >it gets one from the range 192.168.24.200 to 192.168.24.254 > >above in turn). > > > >I added > > > >pool { > > range 192.168.24.1 192.168.24.199; > > deny unknown-clients; > >} > > > >which works w.r.t. to the DHCPREQUEST mentioned above but now > >when host2 wants to renew its (static) address I get this in > >the logfile: > > > >Apr 2 16:51:18 server dhcpd: Dynamic and static leases > >present for 192.168.24.23. > >Apr 2 16:51:18 server dhcpd: Remove host declaration > >host2.domain.org or remove 192.16 > >8.24.23 > >Apr 2 16:51:18 server dhcpd: from the dynamic address > >pool for 192.168.24.0/24 > > > >since 192.168.24.23 lies within the (now existing) pool ranging > >from 192.168.24.1 to 192.168.24.199. > > Firstly, is it a problem ? The client will either give up and revert Yes, see below ;-) > to doing Discovers, or it will fail to connect to the network. As > long as it doesn't try and use an address it's not been leased, then This is exactly what it is doing: This is what happened: I have a client (WinXP Professional) which has been used in our net before and had been abandoned a few months ago. But now the need to use it again reappeared and so we decided to connect it. Instead of DHCPDISCOVERing and getting one of the IPs from the dynamic range it started to DHCPREQUEST the 192.168.24.55 and the server remained silent. It turned out that the client thought that it had a valid IP of 192.168.24.55 and that the lease would end on 2012-09-10(!). I have no idea how this happened (my static leases last a few hours). > that isn't your problem as the administrator of the DHCP server. Well, I am administrator of the whole net with all (not only DHCP) servers and clients ;-). In our case things were simply: I manually released the address and DHCPDISCOVERed the new correct one and things were well. But I also want to find a way so that the DHCP server automatically NAKs those request. > Unless the client is broken, it will only take a few extra seconds to > get a network address - once it's realised it isn't getting an answer > to it's requests. > If it fails to revert to Discovers then it's broken and not your > responsibility as the DHCP admin. If you are responsible for the > client then take it up with the vendor. > > As to the rest, well you cannot include an address used in a > fixed-address statement in any pool. The error message you quote was > added in response to the numerous threads from people who expected > the same operation as a Windows server and then complained that their > "static assignments" were being leased out to other clients. There > isn't a way to force NACKs of such addresses without triggering this > error message - though I suppose you could comment that bit out in > the code and recompile. I fear this is the way I have to go ;-(. > > > There is potentially another way to do things. > The ISC server now supports reserved leases - these are "normal" > leases but even if expired will never be re-allocated to other > clients. If you create reserved leases for your fixed address clients > instead of using host statements then the addresses cannot be given > to anything else and will result in a NACK in the circumstances you > describe. You can either just extend your main range, or add small > ranges to just include the addresses in question. But from what I have seen I have to hack the dhcpd.leases file for this. (BTW, I found this possibility before but found it quite ugly so I decided to ask on the list ;-)). In my personal opinion (I am no DHCP expert, just a user with the above observations) I think that if a server is authoritative one should be able to NAK unknown client's DHCPREQUESTs for addresses not in dynamic ranges. Thanks, -Andre From ameen.shajahan at wipro.com Tue Apr 3 05:51:39 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Tue, 3 Apr 2012 05:51:39 +0000 Subject: stateless support for DHCPv6? Message-ID: Hi all, I am using ISC dhcp-4.2.3 for ipv4 and ipv6. Is ISC code have support for stateless DHCPv6 functionality? Thanks, Ameen S Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From 18905913309 at 189.cn Tue Apr 3 06:25:26 2012 From: 18905913309 at 189.cn (18905913309) Date: Tue, 3 Apr 2012 14:25:26 +0800 Subject: Can't open lease database /dev/shm/dhcpd/dhcpd.leases: Permission denied -- Message-ID: <201204031425256719806@189.cn> hi,friends: i encounter a strange things, when i try to move dhcpd.leases file from default path to a customed path, after system boot,the dhcpd daemon can not start, message like that: Can't open lease database /tmp/dhcpd/dhcpd.leases: Permission denied -- my OS is redhat enterprise linux 6.1,the following is my operation step: i stopped the dhcpd service autostart,and add the following line to /etc/rc.local: cp /var/lib/dhcpd/dhcpd.leases /tmp/dhcpd.leases /sbin/dhcpd -lf /tmp/dhcpd.leases then,i reboot system,but dhcpd didnt start. i found a messages in system log files: Can't open lease database /tmp/dhcpd/dhcpd.leases: Permission denied -- but if i run the two lines by manual,it can work. # cp /var/lib/dhcpd/dhcpd.leases /tmp/dhcpd.leases # /sbin/dhcpd -lf /tmp/dhcpd.leases why? 2012-04-03 18905913309 -------------- next part -------------- An HTML attachment was scrubbed... URL: From 18905913309 at 189.cn Tue Apr 3 06:27:10 2012 From: 18905913309 at 189.cn (18905913309) Date: Tue, 3 Apr 2012 14:27:10 +0800 Subject: Can't open lease database /tmp/dhcpd/dhcpd.leases: Permission denied -- Message-ID: <201204031427105151727@189.cn> hi,friends: i encounter a strange things, when i try to move dhcpd.leases file from default path to a customed path, after system boot,the dhcpd daemon can not start, message like that: Can't open lease database /tmp/dhcpd/dhcpd.leases: Permission denied -- my OS is redhat enterprise linux 6.1, dhcpd version is 4.2.3; the following is my operation step: i stopped the dhcpd service autostart,and add the following line to /etc/rc.local: cp /var/lib/dhcpd/dhcpd.leases /tmp/dhcpd.leases /sbin/dhcpd -lf /tmp/dhcpd.leases then,i reboot system,but dhcpd didnt start. i found a messages in system log files: Can't open lease database /tmp/dhcpd/dhcpd.leases: Permission denied -- but if i run the two lines by manual,it can work. # cp /var/lib/dhcpd/dhcpd.leases /tmp/dhcpd.leases # /sbin/dhcpd -lf /tmp/dhcpd.leases why? 2012-04-03 18905913309 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oskar.berggren at gmail.com Tue Apr 3 06:29:14 2012 From: oskar.berggren at gmail.com (Oskar Berggren) Date: Tue, 3 Apr 2012 08:29:14 +0200 Subject: stateless support for DHCPv6? In-Reply-To: References: Message-ID: Den 3 april 2012 07:51 skrev : > Hi all, > > ??????????????? I am using ISC dhcp-4.2.3 for ipv4 and ipv6. Is ISC code > have support for stateless DHCPv6 functionality? > Yes. [Gargantuan irrelevant obnoxious boilerplate legalese removed.] /Oskar From dhcp1 at thehobsons.co.uk Tue Apr 3 07:04:34 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Tue, 3 Apr 2012 08:04:34 +0100 Subject: How to make dhcpd send NAKs instead of silently ignoring DHCPREQUESTS? In-Reply-To: <20120403054150.GA14829@bali> References: <20120402161009.GA11723@bali> <20120403054150.GA14829@bali> Message-ID: Andre Albsmeier wrote: >I have a client (WinXP Professional) Well, enough said. We've had people at work with related problems where their laptop has failed to work out that it's moved between their home and our office networks. I think I had them change the subnet on their home network to be different to ours. > > There is potentially another way to do things. >> The ISC server now supports reserved leases - these are "normal" >> leases but even if expired will never be re-allocated to other >> clients. If you create reserved leases for your fixed address clients >> instead of using host statements then the addresses cannot be given >> to anything else and will result in a NACK in the circumstances you >> describe. You can either just extend your main range, or add small >> ranges to just include the addresses in question. > >But from what I have seen I have to hack the dhcpd.leases file >for this. (BTW, I found this possibility before but found it >quite ugly so I decided to ask on the list ;-)). I believe you can also do it via OMAPI - but I've never used it myself. >In my personal opinion (I am no DHCP expert, just a user with the >above observations) I think that if a server is authoritative one >should be able to NAK unknown client's DHCPREQUESTs for addresses >not in dynamic ranges. It's valid for there to be multiple, independent, authoritative DHCP servers on a network as long as they have non-overlapping ranges. Unless you tell the server that an address is explicitly not available, it will remain silent regarding those it's not responsible for. It's just unfortunate that you've found a corner case where it is valid to have a fixed-address and a dynamic range which overlap. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From dhcp1 at thehobsons.co.uk Tue Apr 3 07:10:31 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Tue, 3 Apr 2012 08:10:31 +0100 Subject: Can't open lease database /dev/shm/dhcpd/dhcpd.leases: Permission denied -- In-Reply-To: <201204031425256719806@189.cn> References: <201204031425256719806@189.cn> Message-ID: 18905913309 wrote: >i stopped the dhcpd service autostart,and add the following line to >/etc/rc.local: > cp /var/lib/dhcpd/dhcpd.leases /tmp/dhcpd.leases > /sbin/dhcpd -lf /tmp/dhcpd.leases > >then,i reboot system,but dhcpd didnt start. >i found a messages in system log files: > Can't open lease database /tmp/dhcpd/dhcpd.leases: Permission denied -- > >but if i run the two lines by manual,it can work. > ># cp /var/lib/dhcpd/dhcpd.leases /tmp/dhcpd.leases ># /sbin/dhcpd -lf /tmp/dhcpd.leases Have you looked at the permissions of the source and copied files ? That might just give you a clue ! You might want to add the "-p" flag to cp to preserve permissions. Also, there are inconsistencies : /tmp/dhcpd/dhcpd.leases is different to /tmp/dhcpd.leases and both are different to /dev/shm/dhcpd/dhcpd.leases - is that just a copy & paste error while you've been experimenting ? I trust you've also modified your scripts to copy the leases file back again before stopping the daemon ? Even so, putting the leases file somewhere volatile (/dev/shm/dhcpd/dhcpd.leases) is very dangerous since if you lose the leases file your server has no memory of promises it made in the past and that can lead to a world of hurt. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From 18905913309 at 189.cn Tue Apr 3 09:49:18 2012 From: 18905913309 at 189.cn (18905913309) Date: Tue, 3 Apr 2012 17:49:18 +0800 Subject: Can't open lease database /dev/shm/dhcpd/dhcpd.leases: Message-ID: <201204031749160629005@189.cn> thanks for your reply. >/tmp/dhcpd/dhcpd.leases is different to /tmp/dhcpd.leases and both >are different to /dev/shm/dhcpd/dhcpd.leases no matter with /dev/shm,or /tmp,or anywhere,it doesn't work. the key point is : when the leases file in default path /var/lib/dhcpd/,everything is ok. when i put the leases file in different path( not the default /var/lib/dhcpd/), for example:/tmp/dhcpd.leases,even if i used "cp -p" when system reboot,the dhcpd daemon can not start ,and report the permission deny error but if i log on,and run dhcpd -lf /tmp/dhcpd.leases, i can work! 2012-04-03 18905913309 -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at rathlev.dk Tue Apr 3 10:10:20 2012 From: peter at rathlev.dk (Peter Rathlev) Date: Tue, 03 Apr 2012 12:10:20 +0200 Subject: Can't open lease database /dev/shm/dhcpd/dhcpd.leases: In-Reply-To: <201204031749160629005@189.cn> References: <201204031749160629005@189.cn> Message-ID: <1333447820.3943.17.camel@abehat.dyn.net.rm.dk> On Tue, 2012-04-03 at 17:49 +0800, 18905913309 wrote: > when system reboot,the dhcpd daemon can not start ,and report the > permission deny error > > but if i log on,and run dhcpd -lf /tmp/dhcpd.leases, i can work! Maybe SELinux related? Does it work with "SELINUX=permissive" in /etc/selinux/config? If that is the case then take a look at /var/log/audit/audit.log and maybe use "audit2allow" (from the "policycoreutils-python" package) to build a local policy. Redhat has some documentation here: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/sec-sel-building-policy-module.html#sec-sel-use-audit2allow -- Peter From 18905913309 at 189.cn Tue Apr 3 10:24:26 2012 From: 18905913309 at 189.cn (18905913309) Date: Tue, 3 Apr 2012 18:24:26 +0800 Subject: Can't open lease database /dev/shm/dhcpd/dhcpd.leases: Message-ID: <201204031824255316348@189.cn> >Maybe SELinux related? Does it work with "SELINUX=permissive" >in /etc/selinux/config? thks,i disabled selinux,everything is ok thanks friends! 2012-04-03 18905913309 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cra at WPI.EDU Tue Apr 3 12:33:43 2012 From: cra at WPI.EDU (Chuck Anderson) Date: Tue, 3 Apr 2012 08:33:43 -0400 Subject: Can't open lease database /dev/shm/dhcpd/dhcpd.leases: In-Reply-To: <201204031824255316348@189.cn> References: <201204031824255316348@189.cn> Message-ID: <20120403123343.GF10800@angus.ind.WPI.EDU> On Tue, Apr 03, 2012 at 06:24:26PM +0800, 18905913309 wrote: > >Maybe SELinux related? Does it work with "SELINUX=permissive" > >in /etc/selinux/config? > thks,i disabled selinux,everything is ok > > thanks friends! It is an extremely bad idea to put the leases file on volitile storage. If the server reboots it will forget about all the promises it has made to clients, which will cause it to lease the same IP addresses to different clients, causing IP conflicts. From perl-list at network1.net Tue Apr 3 12:34:07 2012 From: perl-list at network1.net (perl-list) Date: Tue, 03 Apr 2012 08:34:07 -0400 (EDT) Subject: Can't open lease database /tmp/dhcpd/dhcpd.leases: Permission denied -- In-Reply-To: <201204031427105151727@189.cn> Message-ID: I see why. The server is trying to open /tmp/dhcpd/dhcpd.leases but you said you copied to /tmp/dhcpd.leases mkdir /tmp/dhcpd; cp /tmp/dhcpd.leases /tmp/dhcpd/; should do the trick. ----- Original Message ----- > From: "18905913309" <18905913309 at 189.cn> > To: "dhcp-users" > Sent: Tuesday, April 3, 2012 2:27:10 AM > Subject: Can't open lease database /tmp/dhcpd/dhcpd.leases: > Permission denied -- > hi,friends: > i encounter a strange things, > when i try to move dhcpd.leases file from default path to a customed > path, > after system boot,the dhcpd daemon can not start, message like that: > Can't open lease database /tmp/dhcpd/dhcpd.leases: Permission denied > -- > my OS is redhat enterprise linux 6.1, dhcpd version is 4.2.3; > the following is my operation step: > i stopped the dhcpd service autostart,and add the following line to > /etc/rc.local: > cp /var/lib/dhcpd/dhcpd.leases /tmp/dhcpd.leases > /sbin/dhcpd -lf /tmp/dhcpd.leases > then,i reboot system,but dhcpd didnt start. > i found a messages in system log files: > Can't open lease database /tmp/dhcpd/dhcpd.leases: Permission denied > -- > but if i run the two lines by manual,it can work. > # cp /var/lib/dhcpd/dhcpd.leases /tmp/dhcpd.leases > # /sbin/dhcpd -lf /tmp/dhcpd.leases > why? > 2012-04-03 > 18905913309 > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From oscars at mail.utexas.edu Tue Apr 3 14:43:43 2012 From: oscars at mail.utexas.edu (Oscar Ricardo Silva) Date: Tue, 03 Apr 2012 09:43:43 -0500 Subject: Upgrading server hardware on existing failover pair Message-ID: <4F7B0C9F.4000504@mail.utexas.edu> Thanks for the responses. I forgot to mention that I use omshell to "gracefully" bring down the server and it notifies the partner. Whenever we need to reload for a new configuration I bring one server down this way, the partner is notified of the state change and goes into "partner-down". For now I'll be keeping both servers on 3.1.3. We've written some patches that our developers need to check against new versions. Oscar ------------------------------ Message: 5 Date: Mon, 2 Apr 2012 20:58:16 +0000 From: Randall C Grimshaw To: Users of ISC DHCP Subject: RE: Upgrading server hardware on existing failover pair Message-ID: Content-Type: text/plain; charset="us-ascii" Technically, I think that at the time you gracefully shut down the peer, that you will not be in partner down mode. If you plan to be down long you will want to manually put the host into partner down mode or risk exhausting the half of your pool that is still available. This may not affect your transition, but it is a technical issue you should be aware of in an outage. - self inflicted or otherwise. Randall Grimshaw rgrimsha at syr.edu ________________________________________ From: dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org [dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org] on behalf of Oscar Ricardo Silva [oscars at mail.utexas.edu] Sent: Monday, April 02, 2012 4:30 PM To: dhcp-users at lists.isc.org Subject: Upgrading server hardware on existing failover pair We currently have a pair of servers running ISC 3.1.3 in a failover configuration. Both physical servers are scheduled to be replaced with newer hardware and I'd like to bounce my plan off the list to be sure it's sane. 1. Shut down dhcpd on the secondary (gracefully). The primary should go into partner-down 2. Copy configuration and leases file from old secondary to new secondary 3. Bring up *NEW* secondary, make sure it can communicate on the network 4. Start dhcpd on the *NEW secondary and it should communicate with the primary and get updates 5. Wait until both servers are in the *NORMAL* state 6. Repeat these steps for the primary *SHOULD* this work without an expected interruption in service? I know during upgrades, things can and will go wrong but I'd like to avoid the obvious things as much as possible. Oscar From hck at utk.edu Tue Apr 3 14:48:38 2012 From: hck at utk.edu (King, Harold Clyde (Hal)) Date: Tue, 3 Apr 2012 14:48:38 +0000 Subject: Upgrading server hardware on existing failover pair In-Reply-To: <4F7B0C9F.4000504@mail.utexas.edu> Message-ID: Hi I inherited some DHCP servers and I'd kile to know the "graceful" shutdown sequence. Would you folks mind sharing that? We're just killing the service. -- Hal King - hck at utk.edu Systems Administrator Office of Information Technology Systems: Business Information Systems The University of Tennessee 135D Kingston Pike Building 2309 Kingston Pk. Knoxville, TN 37996 Phone: 974-1599 On 4/3/12 10:43 AM, "Oscar Ricardo Silva" wrote: >Thanks for the responses. I forgot to mention that I use omshell to >"gracefully" bring down the server and it notifies the partner. >Whenever we need to reload for a new configuration I bring one server >down this way, the partner is notified of the state change and goes into >"partner-down". > >For now I'll be keeping both servers on 3.1.3. We've written some >patches that our developers need to check against new versions. > > > > >Oscar > > > > >------------------------------ > >Message: 5 >Date: Mon, 2 Apr 2012 20:58:16 +0000 >From: Randall C Grimshaw >To: Users of ISC DHCP >Subject: RE: Upgrading server hardware on existing failover pair >Message-ID: > >Content-Type: text/plain; charset="us-ascii" > > >Technically, I think that at the time you gracefully shut down the peer, >that you will not be in partner down mode. If you plan to be down long >you will want to manually put the host into partner down mode or risk >exhausting the half of your pool that is still available. >This may not affect your transition, but it is a technical issue you >should be aware of in an outage. - self inflicted or otherwise. > > >Randall Grimshaw rgrimsha at syr.edu >________________________________________ >From: dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org >[dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org] on behalf of Oscar >Ricardo Silva [oscars at mail.utexas.edu] >Sent: Monday, April 02, 2012 4:30 PM >To: dhcp-users at lists.isc.org >Subject: Upgrading server hardware on existing failover pair > >We currently have a pair of servers running ISC 3.1.3 in a failover >configuration. Both physical servers are scheduled to be replaced with >newer hardware and I'd like to bounce my plan off the list to be sure >it's sane. > > >1. Shut down dhcpd on the secondary (gracefully). The primary should >go into partner-down > >2. Copy configuration and leases file from old secondary to new secondary > >3. Bring up *NEW* secondary, make sure it can communicate on the network > >4. Start dhcpd on the *NEW secondary and it should communicate with the >primary and get updates > >5. Wait until both servers are in the *NORMAL* state > >6. Repeat these steps for the primary > > >*SHOULD* this work without an expected interruption in service? I know >during upgrades, things can and will go wrong but I'd like to avoid the >obvious things as much as possible. > > >Oscar >_______________________________________________ >dhcp-users mailing list >dhcp-users at lists.isc.org >https://lists.isc.org/mailman/listinfo/dhcp-users > From glen.neff at emc.com Tue Apr 3 15:00:11 2012 From: glen.neff at emc.com (glen.neff at emc.com) Date: Tue, 3 Apr 2012 11:00:11 -0400 Subject: Upgrading server hardware on existing failover pair In-Reply-To: References: <4F7B0C9F.4000504@mail.utexas.edu>, Message-ID: > Hi I inherited some DHCP servers and I'd kile to know the "graceful" > shutdown sequence. Would you folks mind sharing that? We're just killing > the service. That really depends on the OS/distribution and/or how the dhcpd software was installed. For starters try 'service dhcpd stop'. There could also be a script called /etc/rc.d/dhcpd, /etc/init.d/dhcpd, /etc/rc3.d/dhcpd, /usr/local/etc/rc.d/dhcpd, etc. The script could also be called something like isc-dhcpd. It could be any combination of the above, but if it exists, you should be able to pass a 'stop' parameter to it. -G /* * Glen R. J. Neff * USD Lab Operations Infrastructure Team * glen.neff at emc.com * * EMC^2 == E^2 */ From ameen.shajahan at wipro.com Tue Apr 3 15:23:36 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Tue, 3 Apr 2012 15:23:36 +0000 Subject: IPv6 relay not working?? Message-ID: In relay side ./dhcrelay -6 -d -I -l eth0 -u eth1 Internet Systems Consortium DHCP Relay Agent 4.2.3 Copyright 2004-2011 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Bound to *:547 Listening on Socket/eth1 Sending on Socket/eth1 Listening on Socket/eth0 Sending on Socket/eth0 Relaying Solicit from fe80::c8b0:6456:f443:7543 port 546 going up. send_packet6: Cannot assign requested address Relaying Solicit from fe80::c8b0:6456:fd72:7074 port 546 going up. send_packet6: Cannot assign requested address In server side ./dhcpd -6 -d -f -cf /etc/dhcpd-dhcpv6.conf -lf /var/db/dhcpd6.leases eth0 Internet Systems Consortium DHCP Server 4.2.3 Copyright 2004-2011 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/ Wrote 0 deleted host decls to leases file. Wrote 0 new dynamic host decls to leases file. Wrote 0 leases to leases file. Bound to *:547 Listening on Socket/5/eth0/3ffe:501:ffff:100::/64 Sending on Socket/5/eth0/3ffe:501:ffff:100::/64 What could be the problem. Please let me know. Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kratky at fzu.cz Tue Apr 3 16:40:32 2012 From: kratky at fzu.cz (Michal Kratky) Date: Tue, 3 Apr 2012 18:40:32 +0200 (CEST) Subject: dhcrelay doubling DHCPREQUEST unicasts Message-ID: Hi, we have a linux router like this: eth0.200 at eth0: mtu 1500 qdisc noqueue state UP link/ether 00:0f:20:7a:e7:8a brd ff:ff:ff:ff:ff:ff inet 147.231.26.77/23 brd 147.231.27.255 scope global eth0.200 eth0.5 at eth0: mtu 1500 qdisc noqueue state UP link/ether 00:0f:20:7a:e7:8a brd ff:ff:ff:ff:ff:ff inet 10.26.5.31/24 brd 10.26.5.255 scope global eth0.5 Note that we are using just one physical interface and route between two VLANs. There is a DHCP server in the VLAN 200 and many Windows in the private network VLAN 5. All the Windows stations have fixed IP adresses bound to their MAC addresses. There is a dhcrelay running on the router which relays to the DHCP server. At the startup Windows broadcasts DHCPDISCOVER, dhcrelay relays and it works fine. But one hour later Windows station sends DHCPREQUEST by unicast to the DHCP server. This request passes through the router, reaches DHCP server and the server replies DHCPACK. Still fine. But dhcrelay somehow catches the DHCPREQUEST and relays it to the DHCP server ones more. Even worse it uses source address in the VLAN 200 instead VLAN 5. It makes the server to reply DHCPNAK because of "wrong network". Thus the DHCP server receives one DHCPREQUEST twice, answer one ACK and one NAK and the station receives both replies. Windows somehow can cope with it and they stay alive, but I am not at ease. Please how to stop this strange behaviour? Thanks From oscars at mail.utexas.edu Tue Apr 3 23:01:01 2012 From: oscars at mail.utexas.edu (Oscar Ricardo Silva) Date: Tue, 03 Apr 2012 18:01:01 -0500 Subject: Upgrading server hardware on existing failover pair In-Reply-To: References: Message-ID: <4F7B812D.60907@mail.utexas.edu> To gracefully bring down the server and notify the partner I use this script: #!/bin/sh omshell << EOF connect new control open set state = 2 update EOF which I found at . If you look at the logs of the server that stays up you'll see that it gets the notification and moves into a "partner-down" state. On 04/03/2012 10:24 AM, dhcp-users-request at lists.isc.org wrote: > Message: 4 > Date: Tue, 3 Apr 2012 14:48:38 +0000 > From: "King, Harold Clyde (Hal)" > To: Users of ISC DHCP > Subject: Re: Upgrading server hardware on existing failover pair > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Hi I inherited some DHCP servers and I'd kile to know the "graceful" > shutdown sequence. Would you folks mind sharing that? We're just killing > the service. > > -- Hal King - hck at utk.edu Systems Administrator Office of Information > Technology Systems: Business Information Systems The University of > Tennessee 135D Kingston Pike Building 2309 Kingston Pk. Knoxville, TN > 37996 Phone: 974-1599 From Andre.Albsmeier at siemens.com Wed Apr 4 05:28:44 2012 From: Andre.Albsmeier at siemens.com (Andre Albsmeier) Date: Wed, 4 Apr 2012 07:28:44 +0200 Subject: How to make dhcpd send NAKs instead of silently ignoring DHCPREQUESTS? In-Reply-To: References: <20120402161009.GA11723@bali> <20120403054150.GA14829@bali> Message-ID: <20120404052844.GA62380@bali> On Tue, 03-Apr-2012 at 09:04:34 +0200, Simon Hobson wrote: > Andre Albsmeier wrote: > > >I have a client (WinXP Professional) > > Well, enough said. We've had people at work with related problems Yes ;-) > where their laptop has failed to work out that it's moved between > their home and our office networks. I think I had them change the > subnet on their home network to be different to ours. > > > > There is potentially another way to do things. > >> The ISC server now supports reserved leases - these are "normal" > >> leases but even if expired will never be re-allocated to other > >> clients. If you create reserved leases for your fixed address clients > >> instead of using host statements then the addresses cannot be given > >> to anything else and will result in a NACK in the circumstances you > >> describe. You can either just extend your main range, or add small > >> ranges to just include the addresses in question. > > > >But from what I have seen I have to hack the dhcpd.leases file > >for this. (BTW, I found this possibility before but found it > >quite ugly so I decided to ask on the list ;-)). > > I believe you can also do it via OMAPI - but I've never used it myself. > > >In my personal opinion (I am no DHCP expert, just a user with the > >above observations) I think that if a server is authoritative one > >should be able to NAK unknown client's DHCPREQUESTs for addresses > >not in dynamic ranges. > > It's valid for there to be multiple, independent, authoritative DHCP > servers on a network as long as they have non-overlapping ranges. Yes, sure. I just _thought_ that if I am responsible for, let's say, subnet 192.168.10.0/24 I should be able to control this in a way that lets me clearly decide between: 1. if known client -> give him his known and fixed address 2. if unknown client -> be sure he gets an address in a specific range. > Unless you tell the server that an address is explicitly not > available, it will remain silent regarding those it's not responsible > for. That's what I have learned now ;-(. Again, in my eyes it should be possible to tell the server: Yes, you are responsible for subnet 192.168.10.0/24 _entirely_ and _alone_ and you NAK everything that is not fixed and wants something not in the dynamic range. > It's just unfortunate that you've found a corner case where it is > valid to have a fixed-address and a dynamic range which overlap. Right, but I use a different approach now. The patch below NAKs requests from unknown clients that want to use an address outside the dynamic range. No idea if it is correct but it seems to do the trick. Just, in case anyone else is interested... --- ./includes/dhcpd.h.ORI 2011-12-31 00:17:04.000000000 +0100 +++ ./includes/dhcpd.h 2012-04-03 14:08:29.000000000 +0200 @@ -713,6 +713,9 @@ # define SV_LDAP_TLS_RANDFILE 77 #endif #endif +#define SV_AA_NAK_UNKNOWN 78 + +extern unsigned char AA_nak_unknown; #if !defined (DEFAULT_PING_TIMEOUT) # define DEFAULT_PING_TIMEOUT 1 --- ./includes/dhctoken.h.ORI 2011-09-21 22:43:10.000000000 +0200 +++ ./includes/dhctoken.h 2012-04-03 14:09:41.000000000 +0200 @@ -364,6 +364,7 @@ GETHOSTBYNAME = 665, PRIMARY6 = 666, SECONDARY6 = 667 + , AA_NAK_UNKNOWN = 668 }; #define is_identifier(x) ((x) >= FIRST_TOKEN && \ --- ./server/stables.c.ORI 2011-10-14 21:49:48.000000000 +0200 +++ ./server/stables.c 2012-04-03 14:11:13.000000000 +0200 @@ -266,6 +266,7 @@ { "ldap-tls-randfile", "t", &server_universe, 77, 1 }, #endif /* LDAP_USE_SSL */ #endif /* LDAP_CONFIGURATION */ + { "nak-unknown", "f", &server_universe, 78, 1 }, { NULL, NULL, NULL, 0, 0 } }; --- ./server/confpars.c.ORI 2011-07-01 13:58:53.000000000 +0200 +++ ./server/confpars.c 2012-04-03 14:29:19.000000000 +0200 @@ -4104,6 +4104,10 @@ code = SV_LEASEQUERY; break; + case AA_NAK_UNKNOWN: + code = SV_AA_NAK_UNKNOWN; + break; + default: parse_warn (cfile, "expecting allow/deny key"); skip_to_semi (cfile); --- ./server/dhcpd.c.ORI 2011-12-31 01:55:22.000000000 +0100 +++ ./server/dhcpd.c 2012-04-03 14:24:18.000000000 +0200 @@ -157,6 +157,8 @@ #endif /* NSUPDATE */ int ddns_update_style; +unsigned char AA_nak_unknown = 0; + const char *path_dhcpd_conf = _PATH_DHCPD_CONF; const char *path_dhcpd_db = _PATH_DHCPD_DB; const char *path_dhcpd_pid = _PATH_DHCPD_PID; @@ -1135,6 +1137,10 @@ data_string_forget(&db, MDL); } + AA_nak_unknown = 0; + if( (oc = lookup_option( &server_universe, options, SV_AA_NAK_UNKNOWN )) != 0 ) + AA_nak_unknown = evaluate_boolean_option_cache( NULL, NULL, NULL, NULL, options, NULL, &global_scope, oc, MDL ); + /* Don't need the options anymore. */ option_state_dereference (&options, MDL); --- ./server/dhcp.c.ORI 2012-04-03 14:26:20.000000000 +0200 +++ ./server/dhcp.c 2012-04-03 14:25:46.000000000 +0200 @@ -676,6 +676,10 @@ ack_lease (packet, lease, DHCPACK, 0, msgbuf, ms_nulltp, (struct host_decl *)0); } else + if( AA_nak_unknown ) { + log_info( "%s: unknown lease %s, sending NAK.", msgbuf, piaddr( cip )); + nak_lease( packet, &cip ); + } else log_info ("%s: unknown lease %s.", msgbuf, piaddr (cip)); out: From dhcp1 at thehobsons.co.uk Wed Apr 4 07:00:21 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Wed, 4 Apr 2012 08:00:21 +0100 Subject: How to make dhcpd send NAKs instead of silently ignoring DHCPREQUESTS? In-Reply-To: <20120404052844.GA62380@bali> References: <20120402161009.GA11723@bali> <20120403054150.GA14829@bali> <20120404052844.GA62380@bali> Message-ID: Andre Albsmeier wrote: >Yes, sure. I just _thought_ that if I am responsible for, let's >say, subnet 192.168.10.0/24 I should be able to control this I think this used to be possible in earlier versions, but we used to get people coming here on a semi regular basis who were using a Windows Server* approach and couldn't understand why they were getting duplicate leases (dynamic leases for addresses "reserved" for fixed address hosts). I know at some point a warning was added, so if there were overlaps then a warning would be spat out during startup, but I wasn't aware that the more specific warning/error you've seen had been added - but then I'm no longer a heavy user of this code, and I don't have such overlaps in my config. * Don't know if you've used it, but (from memory) on Windows the admin is very very different. You can't modify a scope once created, so it's custom to create a scope that covers the entire subnet. You then "block out" ranges you don't want included, and reserve leases for specific clients. So more or less the opposite of how you configure the ISC server. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From rgrimsha at syr.edu Wed Apr 4 13:05:44 2012 From: rgrimsha at syr.edu (Randall C Grimshaw) Date: Wed, 4 Apr 2012 13:05:44 +0000 Subject: netreg Revisited In-Reply-To: References: <201103221627.p2MGRPgM023282@dc.cis.okstate.edu>, Message-ID: Ditto, with the exception that we did use omapi in a captive portal implementation which required custom coded middleware to work around a memory leak in omapi.... thus I feel justified in avoiding omapi when possible. Randall Grimshaw rgrimsha at syr.edu ________________________________________ From: dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org [dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org] on behalf of John Wobus [jw354 at cornell.edu] Sent: Friday, March 25, 2011 10:34 AM To: Users of ISC DHCP Subject: Re: netreg Revisited We rolled our own system years ago that's pretty much as you describe netreg and we have never changed from restarting dhcpd to using OMAPI. I was influenced by an on-list dhcpd developer comment that they'd like to replace OMAPI, and also I was uncomfortable with host configs in the lease file rather than the config file. Also, by regenerating the entire config file, we easily eliminate the possibility of dhcpd and our database getting out of synch. But obviously OMAPI's worked very well for many sites, who probably laugh at the hoops we jump through to avoid using it. We run a redundant pair and we restart dhcpd every 2 minutes when there are config changes awaiting deployment. I think we assist ISC by exercising dhcpd in a somewhat-extreme manner. John Wobus Cornell On Mar 22, 2011, at 12:27 PM, Martin McCormick wrote: > Some years ago, Carnegie Mellon University built a > clever use of dhcp and DNS called netreg to authenticate clients > who wanted to connect to their networks. It looks like nobody > has done much to it since about 2005 and there is no mention of > failover or omapi. All updates are done the old fashioned-way. > Modify dhcpd.conf. Stop the server. Say a prayer and restart > dhcpd. > > We've been asked to investigate netreg so I am asking > whether there is a modernized version that exists and makes use > of omapi for dynamic updates. > > The original idea was that each network had a small pool > of dynamic leases with very short lifetimes. A client is sent to > the authentication server and, if approved, he gets put in to > the known pool. By using omapi, he could also be given a bootP > entry if the magic between authentication and approval can do > that. > We are basically looking to make sure we don't re-envent > any good wheels that have already been proven to roll. > > Thanks for all constructive ideas. > > Martin McCormick WB5AGZ Stillwater, OK > Systems Engineer > OSU Information Technology Department Telecommunications Services > Group > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users From riepel at networking.stanford.edu Wed Apr 4 17:10:04 2012 From: riepel at networking.stanford.edu (Rob Riepel) Date: Wed, 4 Apr 2012 10:10:04 -0700 Subject: netreg Revisited In-Reply-To: References: <201103221627.p2MGRPgM023282@dc.cis.okstate.edu>, Message-ID: <66F4FC09-FC8E-4E1F-8190-9269D2BAAFC4@networking.stanford.edu> Ditto here. We regenerate dhcpd.conf every 10 minutes and restart whenever there are changes (which is almost every 10 minutes during the day - our IP management system has hundreds of users, so changes are frequent). The servers are restarted one minute apart as it takes 10 seconds for dhcpd to digest the configuration and start doing its thing. Works like a charm. My only wish is a way to declare reserved leases in the config file. (Maybe I've missed that?) FWIW, our config file represents virtually the entire campus network and has ~1300 shared-networks and over 200k host statements. On Apr 4, 2012, at 6:05 AM, Randall C Grimshaw wrote: > Ditto, with the exception that we did use omapi in a captive portal implementation which required custom coded middleware to work around a memory leak in omapi.... thus I feel justified in avoiding omapi when possible. > > Randall Grimshaw rgrimsha at syr.edu > ________________________________________ > From: dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org [dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org] on behalf of John Wobus [jw354 at cornell.edu] > Sent: Friday, March 25, 2011 10:34 AM > To: Users of ISC DHCP > Subject: Re: netreg Revisited > > We rolled our own system years ago that's pretty > much as you describe netreg and we have never > changed from restarting dhcpd to using OMAPI. I was > influenced by an on-list dhcpd developer comment that > they'd like to replace OMAPI, and also I was > uncomfortable with host configs in the lease file > rather than the config file. Also, by regenerating > the entire config file, we easily eliminate the > possibility of dhcpd and our database getting out > of synch. But obviously OMAPI's worked very > well for many sites, who probably laugh at the > hoops we jump through to avoid using it. > > We run a redundant pair and we restart dhcpd every 2 > minutes when there are config changes awaiting > deployment. I think we assist ISC by exercising > dhcpd in a somewhat-extreme manner. > > John Wobus > Cornell > > > On Mar 22, 2011, at 12:27 PM, Martin McCormick wrote: > >> Some years ago, Carnegie Mellon University built a >> clever use of dhcp and DNS called netreg to authenticate clients >> who wanted to connect to their networks. It looks like nobody >> has done much to it since about 2005 and there is no mention of >> failover or omapi. All updates are done the old fashioned-way. >> Modify dhcpd.conf. Stop the server. Say a prayer and restart >> dhcpd. >> >> We've been asked to investigate netreg so I am asking >> whether there is a modernized version that exists and makes use >> of omapi for dynamic updates. >> >> The original idea was that each network had a small pool >> of dynamic leases with very short lifetimes. A client is sent to >> the authentication server and, if approved, he gets put in to >> the known pool. By using omapi, he could also be given a bootP >> entry if the magic between authentication and approval can do >> that. >> We are basically looking to make sure we don't re-envent >> any good wheels that have already been proven to roll. >> >> Thanks for all constructive ideas. >> >> Martin McCormick WB5AGZ Stillwater, OK >> Systems Engineer >> OSU Information Technology Department Telecommunications Services >> Group >> _______________________________________________ >> dhcp-users mailing list >> dhcp-users at lists.isc.org >> https://lists.isc.org/mailman/listinfo/dhcp-users > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users From sscdvp at gmail.com Wed Apr 4 17:13:07 2012 From: sscdvp at gmail.com (sscdvp at gmail.com) Date: Wed, 4 Apr 2012 20:13:07 +0300 Subject: netreg Revisited In-Reply-To: References: <201103221627.p2MGRPgM023282@dc.cis.okstate.edu> Message-ID: In 2011 I've opened ISC-Bug #23069 (Memory leak in handling OMAPI messages OMAPI_OP_STATUS) and posted patch which solves OMAPI memory leak problem. Patch is attached. Serghei Samsi 2012/4/4 Randall C Grimshaw > Ditto, with the exception that we did use omapi in a captive portal > implementation which required custom coded middleware to work around a > memory leak in omapi.... thus I feel justified in avoiding omapi when > possible. > > Randall Grimshaw rgrimsha at syr.edu > ________________________________________ > From: dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org[dhcp-users-bounces+rgrimsha= > syr.edu at lists.isc.org] on behalf of John Wobus [jw354 at cornell.edu] > Sent: Friday, March 25, 2011 10:34 AM > To: Users of ISC DHCP > Subject: Re: netreg Revisited > > We rolled our own system years ago that's pretty > much as you describe netreg and we have never > changed from restarting dhcpd to using OMAPI. I was > influenced by an on-list dhcpd developer comment that > they'd like to replace OMAPI, and also I was > uncomfortable with host configs in the lease file > rather than the config file. Also, by regenerating > the entire config file, we easily eliminate the > possibility of dhcpd and our database getting out > of synch. But obviously OMAPI's worked very > well for many sites, who probably laugh at the > hoops we jump through to avoid using it. > > We run a redundant pair and we restart dhcpd every 2 > minutes when there are config changes awaiting > deployment. I think we assist ISC by exercising > dhcpd in a somewhat-extreme manner. > > John Wobus > Cornell > > > On Mar 22, 2011, at 12:27 PM, Martin McCormick wrote: > > > Some years ago, Carnegie Mellon University built a > > clever use of dhcp and DNS called netreg to authenticate clients > > who wanted to connect to their networks. It looks like nobody > > has done much to it since about 2005 and there is no mention of > > failover or omapi. All updates are done the old fashioned-way. > > Modify dhcpd.conf. Stop the server. Say a prayer and restart > > dhcpd. > > > > We've been asked to investigate netreg so I am asking > > whether there is a modernized version that exists and makes use > > of omapi for dynamic updates. > > > > The original idea was that each network had a small pool > > of dynamic leases with very short lifetimes. A client is sent to > > the authentication server and, if approved, he gets put in to > > the known pool. By using omapi, he could also be given a bootP > > entry if the magic between authentication and approval can do > > that. > > We are basically looking to make sure we don't re-envent > > any good wheels that have already been proven to roll. > > > > Thanks for all constructive ideas. > > > > Martin McCormick WB5AGZ Stillwater, OK > > Systems Engineer > > OSU Information Technology Department Telecommunications Services > > Group > > _______________________________________________ > > dhcp-users mailing list > > dhcp-users at lists.isc.org > > https://lists.isc.org/mailman/listinfo/dhcp-users > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: dhcp-4.2.0-P2-omapi-messages-memleaks.patch Type: application/octet-stream Size: 1481 bytes Desc: not available URL: From G.Eustace at massey.ac.nz Thu Apr 5 03:28:33 2012 From: G.Eustace at massey.ac.nz (Eustace, Glen) Date: Thu, 5 Apr 2012 03:28:33 +0000 Subject: Dual stack DDNS behaviour Message-ID: <1F91433173A402459EEA5B7AC5AC6331033FBC@tur-exch-node2.massey.ac.nz> I am struggling with trying to understand what is supposed to happen with dynamic DNS updates when the client is running dual stack. Has anyone dug deep enough to give an overview of expected behaviour. I am starting to suspect that the IPv4 daemon is removing the AAAAs but have no evidence yet to back that up (e.g. named debug logs ) I currently have update-conflict-detection to false for the IPv6 daemon. What I am seeing; 1. DDNS for PTR always succeeds - as expected. 2. DDNS for A resource would appear to succeed when attempted - probably as expected. 3. DDNS for AAAA not always attempted appears to succeed when it is. 4. AAAA resources mysteriously disappear, sometimes almost instantly (assuming the update did in fact work ) and sometime some time later. 05-Apr-2012 15:11:03.883 update: info: client 130.123.131.13#61475: updating zone 'massey.ac.nz/IN': deleting rrset at 'tur-applrnd4.massey.ac.nz' AAAA 05-Apr-2012 15:11:03.883 update: info: client 130.123.131.13#61475: updating zone 'massey.ac.nz/IN': adding an RR at 'tur-applrnd4.massey.ac.nz' AAAA ; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.2.rc1.fc16 <<>> tur-applrnd4.massey.ac.nz any ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16881 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 6 ;; QUESTION SECTION: ;tur-applrnd4.massey.ac.nz. IN ANY ;; ANSWER SECTION: tur-applrnd4.massey.ac.nz. 3600 IN TXT "02a11823540d172503543bd1ba7b275308" tur-applrnd4.massey.ac.nz. 7200 IN A 130.123.131.60 ;; AUTHORITY SECTION: -- Glen Eustace, Infrastructure Development Engineer (BC/DR) Information Technology Services, Massey University PN460 Private Bag 11222, Palmerston North, New Zealand. Ph: +64-6-3569099 x 81005, Mob: +64-27-4500321 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhcp at nryc.fr Thu Apr 5 08:17:56 2012 From: dhcp at nryc.fr (Nicolas C.) Date: Thu, 05 Apr 2012 10:17:56 +0200 Subject: Dual stack DDNS behaviour In-Reply-To: <1F91433173A402459EEA5B7AC5AC6331033FBC@tur-exch-node2.massey.ac.nz> References: <1F91433173A402459EEA5B7AC5AC6331033FBC@tur-exch-node2.massey.ac.nz> Message-ID: <4F7D5534.6040104@nryc.fr> Le 05/04/2012 05:28, Eustace, Glen a ?crit : > I am struggling with trying to understand what is supposed to happen > with dynamic DNS updates when the client is running dual stack. Has > anyone dug deep enough to give an overview of expected behaviour. I am > starting to suspect that the IPv4 daemon is removing the AAAAs but have > no evidence yet to back that up (e.g. named debug logs ) > > I currently have update-conflict-detection to false for the IPv6 daemon. I think you'll have a better idea of what's going on by looking on the DHCP logs instead of bind. DHCP will log what's it's trying to update or delete. From ameen.shajahan at wipro.com Mon Apr 9 09:59:37 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Mon, 9 Apr 2012 09:59:37 +0000 Subject: DHCPv6 query Message-ID: Hi all, I need clarification for a below output. Consider the scenario, I have run two dhcpv6 servers in two different eservers. Server1 subnet is 3ffe:501:ffff:105::15 Server2 subnet is 3ffe:501:ffff:116::15 These two servers connected to 1 switch , from that switch its connected to Windows7PC(client) Cisco switch Client(Windows7PC) [cid:image001.png at 01CD1664.B020C250][cid:image002.png at 01CD1664.B020C250] DHCPV6 server1 [cid:image003.png at 01CD1664.B020C250] DHCPv6 server 2 Ran the two servers at a sametime , Client got the IPv6 address in the subnet range3ffe:501:ffff:105::15 not in 3ffe:501:ffff:116::15 Then I stopped both the server , restarted both the servers again. Again Client getting the IPv6 address in the range 3ffe:501:ffff:105::14 not in 3ffe:501:ffff:116::15 Conceptuall it could be correct , because client get a single IP address at a time. I would like to know , why its not assigning to this range(3ffe:501:ffff:116::15) eventhough I restarted both the servers 4 to 5 times. Is there any priority following for assigning IPv6 address. What could be the reason . Please let me know. Output 1(IP assigned output) Jan 13 03:22:30 ameen daemon.info dhcpd: Solicit message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0xDCE659 Jan 13 03:22:30 ameen daemon.debug dhcpd: Picking pool address 3ffe:501:ffff:105::15 Jan 13 03:22:30 ameen daemon.info dhcpd: Sending Advertise to fe80::c8b0:62f6:fd72:7074 port 546 Jan 13 03:22:31 ameen daemon.info dhcpd: Request message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0xDCE659 Jan 13 03:22:31 ameen daemon.info dhcpd: Sending Reply to fe80::c8b0:62f6:fd72:7074 port 546 Jan 13 03:23:25 ameen daemon.info dhcpd: Release message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0x74B40B Jan 13 03:23:25 ameen daemon.info dhcpd: Client 00:01:00:01:14:d3:bd:62:90:fb:a6:ec:74:35 releases address 3ffe:501:ffff:105::15, which is not leased to it. Jan 13 03:23:25 ameen daemon.info dhcpd: Sending Reply to fe80::c8b0:62f6:fd72:7074 port 546 Output2(unassigned IP output) feb 20 03:56:05 ameen daemon.info dhcpd: Solicit message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0xDCE659 Feb 20 03:56:05 ameen daemon.debug dhcpd: Picking pool address 3ffe:501:ffff:116::15 Feb 20 03:56:05 ameen daemon.info dhcpd: Sending Advertise to fe80::c8b0:62f6:fd72:7074 port 546 Feb 20 03:56:06 ameen daemon.notice dhcpd: SFR: Init = 1C71 UP = 9C95 LOW = 9C4C Feb 20 03:56:06 ameen daemon.info dhcpd: Request message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0xDCE659 Feb 20 03:56:06 ameen daemon.debug dhcpd: Discarding Request from fe80::c8b0:62f6:fd72:7074; not our server identifier (CLIENTID 00:01:00:01:14:d3:bd:62:90:fb:a6:ec:74:35, SERVERID 00:01:00:01:16:a2:5f:70:00:60:43:60:ca:99, server DUID 00:01:00:01:16:d4:80:52:00:60:43: Feb 20 03:56:17 ameen daemon.notice dhcpd: SFR: Init = 1C71 UP = 9C95 LOW = 9C4C Feb 20 03:57:01 ameen daemon.info dhcpd: Release message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0x74B40B Feb 20 03:57:01 ameen daemon.debug dhcpd: Discarding Release from fe80::c8b0:62f6:fd72:7074; not our server identifier (CLIENTID 00:01:00:01:14:d3:bd:62:90:fb:a6:ec:74:35, SERVERID 00:01:00:01:16:a2:5f:70:00:60:43:60:ca:99, server DUID 00:01:00:01:16:d4:80:52:00:60:43: Feb 20 03:57:12 ameen daemon.notice dhcpd: SFR: Init = 1C71 UP = 9C95 LOW = 9C4C Regards, Ameen S Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 264 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 286 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 280 bytes Desc: image003.png URL: From ameen.shajahan at wipro.com Mon Apr 9 12:05:12 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Mon, 9 Apr 2012 12:05:12 +0000 Subject: Query in DHCPv6 multiple server running scenario ?? Message-ID: Hi all, I need clarification for a below output. Consider the scenario, I have run two dhcpv6 servers in two different eservers. Server1 subnet is 3ffe:501:ffff:105::15 Server2 subnet is 3ffe:501:ffff:116::15 These two servers connected to 1 switch , from that switch its connected to Windows7PC(client) Cisco switch Client(Windows7PC) [cid:image001.png at 01CD1664.B020C250][cid:image002.png at 01CD1664.B020C250] DHCPV6 server1 [cid:image003.png at 01CD1664.B020C250] DHCPv6 server 2 Ran the two servers at a sametime , Client got the IPv6 address in the subnet range3ffe:501:ffff:105::15 not in 3ffe:501:ffff:116::15 Then I stopped both the server , restarted both the servers again. Again Client getting the IPv6 address in the range 3ffe:501:ffff:105::14 not in 3ffe:501:ffff:116::15 Conceptuall it could be correct , because client get a single IP address at a time. I would like to know , why its not assigning to this range(3ffe:501:ffff:116::15) eventhough I restarted both the servers 4 to 5 times. Is there any priority following for assigning IPv6 address. What could be the reason . Please let me know. Output 1(IP assigned output) Jan 13 03:22:30 ameen daemon.info dhcpd: Solicit message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0xDCE659 Jan 13 03:22:30 ameen daemon.debug dhcpd: Picking pool address 3ffe:501:ffff:105::15 Jan 13 03:22:30 ameen daemon.info dhcpd: Sending Advertise to fe80::c8b0:62f6:fd72:7074 port 546 Jan 13 03:22:31 ameen daemon.info dhcpd: Request message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0xDCE659 Jan 13 03:22:31 ameen daemon.info dhcpd: Sending Reply to fe80::c8b0:62f6:fd72:7074 port 546 Jan 13 03:23:25 ameen daemon.info dhcpd: Release message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0x74B40B Jan 13 03:23:25 ameen daemon.info dhcpd: Client 00:01:00:01:14:d3:bd:62:90:fb:a6:ec:74:35 releases address 3ffe:501:ffff:105::15, which is not leased to it. Jan 13 03:23:25 ameen daemon.info dhcpd: Sending Reply to fe80::c8b0:62f6:fd72:7074 port 546 Output2(unassigned IP output) feb 20 03:56:05 ameen daemon.info dhcpd: Solicit message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0xDCE659 Feb 20 03:56:05 ameen daemon.debug dhcpd: Picking pool address 3ffe:501:ffff:116::15 Feb 20 03:56:05 ameen daemon.info dhcpd: Sending Advertise to fe80::c8b0:62f6:fd72:7074 port 546 Feb 20 03:56:06 ameen daemon.notice dhcpd: SFR: Init = 1C71 UP = 9C95 LOW = 9C4C Feb 20 03:56:06 ameen daemon.info dhcpd: Request message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0xDCE659 Feb 20 03:56:06 ameen daemon.debug dhcpd: Discarding Request from fe80::c8b0:62f6:fd72:7074; not our server identifier (CLIENTID 00:01:00:01:14:d3:bd:62:90:fb:a6:ec:74:35, SERVERID 00:01:00:01:16:a2:5f:70:00:60:43:60:ca:99, server DUID 00:01:00:01:16:d4:80:52:00:60:43: Feb 20 03:56:17 ameen daemon.notice dhcpd: SFR: Init = 1C71 UP = 9C95 LOW = 9C4C Feb 20 03:57:01 ameen daemon.info dhcpd: Release message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0x74B40B Feb 20 03:57:01 ameen daemon.debug dhcpd: Discarding Release from fe80::c8b0:62f6:fd72:7074; not our server identifier (CLIENTID 00:01:00:01:14:d3:bd:62:90:fb:a6:ec:74:35, SERVERID 00:01:00:01:16:a2:5f:70:00:60:43:60:ca:99, server DUID 00:01:00:01:16:d4:80:52:00:60:43: Feb 20 03:57:12 ameen daemon.notice dhcpd: SFR: Init = 1C71 UP = 9C95 LOW = 9C4C Regards, Ameen S Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 264 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 286 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 280 bytes Desc: image003.png URL: From perl-list at network1.net Mon Apr 9 12:59:48 2012 From: perl-list at network1.net (perl-list) Date: Mon, 09 Apr 2012 08:59:48 -0400 (EDT) Subject: DHCPv6 query In-Reply-To: Message-ID: <084eb713-2edc-4a81-8837-2dfabd84ce4e@zimbra.network1.net> In the test-case that you setup, the client is going to accept whichever packet gets there first. It could have just as easily got a packet from server 2 if that packet had arrived first. If you shut of server 1 long enough that the client's lease runs out, it will get an address from server 2. There is no failover support yet in DHCPv6 (although there is a draft for it that is currently worming its way through the IETF). If you have a relay agent in the middle, you can set priorities on which server should have preference etc... ----- Original Message ----- > From: "ameen shajahan" > To: dhcp-users at lists.isc.org > Sent: Monday, April 9, 2012 5:59:37 AM > Subject: DHCPv6 query > Hi all, > I need clarification for a below output. > Consider the scenario, I have run two dhcpv6 servers in two different > eservers. > Server1 subnet is 3ffe:501:ffff:105::15 > Server2 subnet is 3ffe:501:ffff:116::15 > These two servers connected to 1 switch , from that switch its > connected to Windows7PC(client) > > > > Cisco switch > > > Client(Windows7PC) > > DHCPV6 server1 > DHCPv6 server 2 > Ran the two servers at a sametime , Client got the IPv6 address in > the subnet range 3ffe:501:ffff:105::15 not in 3ffe:501:ffff:116::15 > Then I stopped both the server , restarted both the servers again. > Again Client getting the IPv6 address in the range > 3ffe:501:ffff:105::14 not in 3ffe:501:ffff:116::15 > Conceptuall it could be correct , because client get a single IP > address at a time. > I would like to know , why its not assigning to this > range(3ffe:501:ffff:116::15) eventhough I restarted both the servers > 4 to 5 times. > Is there any priority following for assigning IPv6 address. > What could be the reason . > Please let me know. > Output 1(IP assigned output) > Jan 13 03:22:30 ameen daemon.info dhcpd: Solicit message from > fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0xDCE659 > Jan 13 03:22:30 ameen daemon.debug dhcpd: Picking pool address > 3ffe:501:ffff:105::15 > Jan 13 03:22:30 ameen daemon.info dhcpd: Sending Advertise to > fe80::c8b0:62f6:fd72:7074 port 546 > Jan 13 03:22:31 ameen daemon.info dhcpd: Request message from > fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0xDCE659 > Jan 13 03:22:31 ameen daemon.info dhcpd: Sending Reply to > fe80::c8b0:62f6:fd72:7074 port 546 > Jan 13 03:23:25 ameen daemon.info dhcpd: Release message from > fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0x74B40B > Jan 13 03:23:25 ameen daemon.info dhcpd: Client > 00:01:00:01:14:d3:bd:62:90:fb:a6:ec:74:35 releases address > 3ffe:501:ffff:105::15, which is not leased to it. > Jan 13 03:23:25 ameen daemon.info dhcpd: Sending Reply to > fe80::c8b0:62f6:fd72:7074 port 546 > Output2(unassigned IP output) > feb 20 03:56:05 ameen daemon.info dhcpd: Solicit message from > fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0xDCE659 > Feb 20 03:56:05 ameen daemon.debug dhcpd: Picking pool address > 3ffe:501:ffff:116::15 > Feb 20 03:56:05 ameen daemon.info dhcpd: Sending Advertise to > fe80::c8b0:62f6:fd72:7074 port 546 > Feb 20 03:56:06 ameen daemon.notice dhcpd: SFR: Init = 1C71 UP = 9C95 > LOW = 9C4C > Feb 20 03:56:06 ameen daemon.info dhcpd: Request message from > fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0xDCE659 > Feb 20 03:56:06 ameen daemon.debug dhcpd: Discarding Request from > fe80::c8b0:62f6:fd72:7074; not our server identifier (CLIENTID > 00:01:00:01:14:d3:bd:62:90:fb:a6:ec:74:35, SERVERID > 00:01:00:01:16:a2:5f:70:00:60:43:60:ca:99, server DUID > 00:01:00:01:16:d4:80:52:00:60:43: > Feb 20 03:56:17 ameen daemon.notice dhcpd: SFR: Init = 1C71 UP = 9C95 > LOW = 9C4C > Feb 20 03:57:01 ameen daemon.info dhcpd: Release message from > fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0x74B40B > Feb 20 03:57:01 ameen daemon.debug dhcpd: Discarding Release from > fe80::c8b0:62f6:fd72:7074; not our server identifier (CLIENTID > 00:01:00:01:14:d3:bd:62:90:fb:a6:ec:74:35, SERVERID > 00:01:00:01:16:a2:5f:70:00:60:43:60:ca:99, server DUID > 00:01:00:01:16:d4:80:52:00:60:43: > Feb 20 03:57:12 ameen daemon.notice dhcpd: SFR: Init = 1C71 UP = 9C95 > LOW = 9C4C > Regards, > Ameen S > Please do not print this email unless it is absolutely necessary. > The information contained in this electronic message and any > attachments to this message are intended for the exclusive use of > the addressee(s) and may contain proprietary, confidential or > privileged information. If you are not the intended recipient, you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately and destroy all copies of this message > and any attachments. > WARNING: Computer viruses can be transmitted via email. The recipient > should check this email and any attachments for the presence of > viruses. The company accepts no liability for any damage caused by > any virus transmitted by this email. > www.wipro.com > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 264 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 286 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 280 bytes Desc: image003.png URL: From ameen.shajahan at wipro.com Thu Apr 12 11:46:55 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Thu, 12 Apr 2012 11:46:55 +0000 Subject: DHCPv6 query In-Reply-To: <084eb713-2edc-4a81-8837-2dfabd84ce4e@zimbra.network1.net> References: <084eb713-2edc-4a81-8837-2dfabd84ce4e@zimbra.network1.net> Message-ID: Hi all, I would like to know the IETF draft number for DHCPv6 failover support so that i can refer the document. Thanks, Ameen S From: dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org [mailto:dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org] On Behalf Of perl-list Sent: 09 April 2012 18:30 To: Users of ISC DHCP Subject: Re: DHCPv6 query In the test-case that you setup, the client is going to accept whichever packet gets there first. It could have just as easily got a packet from server 2 if that packet had arrived first. If you shut of server 1 long enough that the client's lease runs out, it will get an address from server 2. There is no failover support yet in DHCPv6 (although there is a draft for it that is currently worming its way through the IETF). If you have a relay agent in the middle, you can set priorities on which server should have preference etc... ________________________________ From: "ameen shajahan" To: dhcp-users at lists.isc.org Sent: Monday, April 9, 2012 5:59:37 AM Subject: DHCPv6 query Hi all, I need clarification for a below output. Consider the scenario, I have run two dhcpv6 servers in two different eservers. Server1 subnet is 3ffe:501:ffff:105::15 Server2 subnet is 3ffe:501:ffff:116::15 These two servers connected to 1 switch , from that switch its connected to Windows7PC(client) Cisco switch Client(Windows7PC) [cid:image001.png at 01CD18D0.2CDE9020][cid:image002.png at 01CD18D0.2CDE9020] DHCPV6 server1 [cid:image003.png at 01CD18D0.2CDE9020] DHCPv6 server 2 Ran the two servers at a sametime , Client got the IPv6 address in the subnet range3ffe:501:ffff:105::15 not in 3ffe:501:ffff:116::15 Then I stopped both the server , restarted both the servers again. Again Client getting the IPv6 address in the range 3ffe:501:ffff:105::14 not in 3ffe:501:ffff:116::15 Conceptuall it could be correct , because client get a single IP address at a time. I would like to know , why its not assigning to this range(3ffe:501:ffff:116::15) eventhough I restarted both the servers 4 to 5 times. Is there any priority following for assigning IPv6 address. What could be the reason . Please let me know. Output 1(IP assigned output) Jan 13 03:22:30 ameen daemon.info dhcpd: Solicit message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0xDCE659 Jan 13 03:22:30 ameen daemon.debug dhcpd: Picking pool address 3ffe:501:ffff:105::15 Jan 13 03:22:30 ameen daemon.info dhcpd: Sending Advertise to fe80::c8b0:62f6:fd72:7074 port 546 Jan 13 03:22:31 ameen daemon.info dhcpd: Request message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0xDCE659 Jan 13 03:22:31 ameen daemon.info dhcpd: Sending Reply to fe80::c8b0:62f6:fd72:7074 port 546 Jan 13 03:23:25 ameen daemon.info dhcpd: Release message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0x74B40B Jan 13 03:23:25 ameen daemon.info dhcpd: Client 00:01:00:01:14:d3:bd:62:90:fb:a6:ec:74:35 releases address 3ffe:501:ffff:105::15, which is not leased to it. Jan 13 03:23:25 ameen daemon.info dhcpd: Sending Reply to fe80::c8b0:62f6:fd72:7074 port 546 Output2(unassigned IP output) feb 20 03:56:05 ameen daemon.info dhcpd: Solicit message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0xDCE659 Feb 20 03:56:05 ameen daemon.debug dhcpd: Picking pool address 3ffe:501:ffff:116::15 Feb 20 03:56:05 ameen daemon.info dhcpd: Sending Advertise to fe80::c8b0:62f6:fd72:7074 port 546 Feb 20 03:56:06 ameen daemon.notice dhcpd: SFR: Init = 1C71 UP = 9C95 LOW = 9C4C Feb 20 03:56:06 ameen daemon.info dhcpd: Request message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0xDCE659 Feb 20 03:56:06 ameen daemon.debug dhcpd: Discarding Request from fe80::c8b0:62f6:fd72:7074; not our server identifier (CLIENTID 00:01:00:01:14:d3:bd:62:90:fb:a6:ec:74:35, SERVERID 00:01:00:01:16:a2:5f:70:00:60:43:60:ca:99, server DUID 00:01:00:01:16:d4:80:52:00:60:43: Feb 20 03:56:17 ameen daemon.notice dhcpd: SFR: Init = 1C71 UP = 9C95 LOW = 9C4C Feb 20 03:57:01 ameen daemon.info dhcpd: Release message from fe80::c8b0:62f6:fd72:7074 port 546, transaction ID 0x74B40B Feb 20 03:57:01 ameen daemon.debug dhcpd: Discarding Release from fe80::c8b0:62f6:fd72:7074; not our server identifier (CLIENTID 00:01:00:01:14:d3:bd:62:90:fb:a6:ec:74:35, SERVERID 00:01:00:01:16:a2:5f:70:00:60:43:60:ca:99, server DUID 00:01:00:01:16:d4:80:52:00:60:43: Feb 20 03:57:12 ameen daemon.notice dhcpd: SFR: Init = 1C71 UP = 9C95 LOW = 9C4C Regards, Ameen S Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 264 bytes Desc: image001.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.png Type: image/png Size: 286 bytes Desc: image002.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 280 bytes Desc: image003.png URL: From glen.neff at emc.com Thu Apr 12 12:48:37 2012 From: glen.neff at emc.com (glen.neff at emc.com) Date: Thu, 12 Apr 2012 08:48:37 -0400 Subject: DHCPv6 query In-Reply-To: References: <084eb713-2edc-4a81-8837-2dfabd84ce4e@zimbra.network1.net>, Message-ID: http://lmgtfy.com/?q=ietf+draft+dhcpv6+failover&l=1 -G /* * Glen R. J. Neff * USD Lab Operations Infrastructure Team * glen.neff at emc.com EMC^2 == E^2 */ ________________________________________ From: dhcp-users-bounces+glen.neff=emc.com at lists.isc.org [dhcp-users-bounces+glen.neff=emc.com at lists.isc.org] On Behalf Of ameen.shajahan at wipro.com [ameen.shajahan at wipro.com] Sent: Thursday, April 12, 2012 7:46 AM To: dhcp-users at lists.isc.org Subject: RE: DHCPv6 query Hi all, I would like to know the IETF draft number for DHCPv6 failover support so that i can refer the document. Thanks, Ameen S From Ted.Lemon at nominum.com Thu Apr 12 12:56:24 2012 From: Ted.Lemon at nominum.com (Ted Lemon) Date: Thu, 12 Apr 2012 12:56:24 +0000 Subject: DHCPv6 query In-Reply-To: References: <084eb713-2edc-4a81-8837-2dfabd84ce4e@zimbra.network1.net>, Message-ID: <0D8AD52C-5119-402C-9115-28903D2583CF@nominum.com> On Apr 12, 2012, at 8:48 AM, > wrote: http://lmgtfy.com/?q=ietf+draft+dhcpv6+failover&l=1 That gets me the most recent version of the DHCPv4 failover draft. The WG has not yet formally adopted the work, so it's http://www.ietf.org/internet-drafts/draft-mrugalski-dhc-dhcpv6-failover-design-01.txt -------------- next part -------------- An HTML attachment was scrubbed... URL: From M.Kueppers at douglas-informatik.de Fri Apr 13 11:28:05 2012 From: M.Kueppers at douglas-informatik.de (=?iso-8859-1?Q?=22K=FCppers=2C_Malte=22?=) Date: Fri, 13 Apr 2012 13:28:05 +0200 Subject: DHCP Failover and dhcpd.leases Message-ID: Hello! I'm currently using a single DHCP server from which I periodically sync the dhcpd.leases file to a second backup DHCP where the deamon is not started. That's my cold standby failover. Now I want to use the ISC-DHCPs build-in failover system which I already successfully configured and tested in a testing environment. My question is, what happens to the leases database when the server is in failover mode? Are all leases written to the file on both server peers or only those which were handed out by the failover peer? Clearly, do both servers have the same leases file? I built some software around the leases database an so I rely on having all active leases in it. Another question is, if I change my running config on the productive server to do ISC failover, how does this affect already given out leases? Are they simply synced to the secondary peer? Thanks in advance! Regards Malte -------------- next part -------------- An HTML attachment was scrubbed... URL: From glenn.satchell at uniq.com.au Fri Apr 13 13:01:14 2012 From: glenn.satchell at uniq.com.au (Glenn Satchell) Date: Fri, 13 Apr 2012 23:01:14 +1000 Subject: DHCP Failover and dhcpd.leases In-Reply-To: References: Message-ID: <0680039470abe84073145ca0d37675f4.squirrel@mail.uniq.com.au> > Hello! > > I'm currently using a single DHCP server from which I periodically sync > the dhcpd.leases file to a second backup DHCP where the deamon is not > started. That's my cold standby failover. > Now I want to use the ISC-DHCPs build-in failover system which I already > successfully configured and tested in a testing environment. > My question is, what happens to the leases database when the server is in > failover mode? > Are all leases written to the file on both server peers or only those > which were handed out by the failover peer? Clearly, do both servers have > the same leases file? > I built some software around the leases database an so I rely on having > all active leases in it. The lease files are not identical - new lease records are appended by the daemon on each system. Leases issues by one server are sent to the other server, but may not be written in exactly the same order. The net result, however, is that the same leases should be in both files. > Another question is, if I change my running config on the productive > server to do ISC failover, how does this affect already given out leases? > Are they simply synced to the secondary peer? When the new secondary starts up, it requests a copy of all the leases on the other server. so, yes, it will synchronise automatically. The failover protocol is documented, there is a References file in the doc subdirectory of the source distribution which points to draft-ietf-dhc-failover-12.txt. You can google for this file to download a copy. The dhcpd.conf man page also describes the operational aspects of the failover protocol in the sections titled DHCP FAILOVER and FAILOVER STARTUP. I hope this helps. regards, -glenn > Thanks in advance! > > Regards > Malte > From rgrimsha at syr.edu Fri Apr 13 13:17:01 2012 From: rgrimsha at syr.edu (Randall C Grimshaw) Date: Fri, 13 Apr 2012 13:17:01 +0000 Subject: DHCP Failover and dhcpd.leases In-Reply-To: <0680039470abe84073145ca0d37675f4.squirrel@mail.uniq.com.au> References: , <0680039470abe84073145ca0d37675f4.squirrel@mail.uniq.com.au> Message-ID: You should also be aware, [I believe this is still true], that leases to machines with static assignments are not kept in the leases file. For this reason you might consider tracking leases and pool states using syslog. Randall Grimshaw rgrimsha at syr.edu ________________________________________ From: dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org [dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org] on behalf of Glenn Satchell [glenn.satchell at uniq.com.au] Sent: Friday, April 13, 2012 9:01 AM To: Users of ISC DHCP Subject: Re: DHCP Failover and dhcpd.leases > Hello! > > I'm currently using a single DHCP server from which I periodically sync > the dhcpd.leases file to a second backup DHCP where the deamon is not > started. That's my cold standby failover. > Now I want to use the ISC-DHCPs build-in failover system which I already > successfully configured and tested in a testing environment. > My question is, what happens to the leases database when the server is in > failover mode? > Are all leases written to the file on both server peers or only those > which were handed out by the failover peer? Clearly, do both servers have > the same leases file? > I built some software around the leases database an so I rely on having > all active leases in it. The lease files are not identical - new lease records are appended by the daemon on each system. Leases issues by one server are sent to the other server, but may not be written in exactly the same order. The net result, however, is that the same leases should be in both files. > Another question is, if I change my running config on the productive > server to do ISC failover, how does this affect already given out leases? > Are they simply synced to the secondary peer? When the new secondary starts up, it requests a copy of all the leases on the other server. so, yes, it will synchronise automatically. The failover protocol is documented, there is a References file in the doc subdirectory of the source distribution which points to draft-ietf-dhc-failover-12.txt. You can google for this file to download a copy. The dhcpd.conf man page also describes the operational aspects of the failover protocol in the sections titled DHCP FAILOVER and FAILOVER STARTUP. I hope this helps. regards, -glenn > Thanks in advance! > > Regards > Malte > _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users From jw354 at cornell.edu Fri Apr 13 20:07:02 2012 From: jw354 at cornell.edu (John Wobus) Date: Fri, 13 Apr 2012 16:07:02 -0400 Subject: DHCP Failover and dhcpd.leases In-Reply-To: References: Message-ID: <2F60808B-58E6-42F8-B632-1CD4A4B9CD2A@cornell.edu> > I?m currently using a single DHCP server from which I periodically > sync the dhcpd.leases file to a second backup DHCP where the deamon > is not started. That?s my cold standby failover. > Now I want to use the ISC-DHCPs build-in failover system which I > already successfully configured and tested in a testing environment. > My question is, what happens to the leases database when the server > is in failover mode? > Are all leases written to the file on both server peers or only > those which were handed out by the failover peer? Clearly, do both > servers have the same leases file? > I built some software around the leases database an so I rely on > having all active leases in it. > > Another question is, if I change my running config on the productive > server to do ISC failover, how does this affect already given out > leases? Are they simply synced to the secondary peer? Each server sends info about the leases it grants to the peer server so the peer server can add it to its lease file. This communication is done asynchronously, i.e., though servers wait for their own lease file update to finish before sending the ACK, they do NOT make the ACK wait until the info is on the peer server's disk. We periodically scan the leases file to tell us about pool usage, basically to warn us of full pools and to give us data to help make adjustments. We scan only one lease file, and just keep in mind that our results aren't watertight, just very helpful. John Wobus Cornell IT From rgrimsha at syr.edu Fri Apr 13 20:32:33 2012 From: rgrimsha at syr.edu (Randall C Grimshaw) Date: Fri, 13 Apr 2012 20:32:33 +0000 Subject: DHCP Failover and dhcpd.leases In-Reply-To: <2F60808B-58E6-42F8-B632-1CD4A4B9CD2A@cornell.edu> References: , <2F60808B-58E6-42F8-B632-1CD4A4B9CD2A@cornell.edu> Message-ID: John: we have two techniques in play to monitor pool usage based on syslog in one report we tabulate leases granted in another we monitor the lts counts as the peers balance their pools - this is very accurate i.e. $pattern = "/^(.+) (.+):(.+):(.+) (.+) dhcpd: pool (.+) (.+) total (.+) free (.+) backup (.+) lts (.+)$/"; if( preg_match( $pattern, $line, $matches ) ) { $month = $matches[0]; $day = $matches[1]; $hr = $matches[2]; $min = $matches[3]; $sec = $matches[4]; $srv = $matches[5]; $pool = $matches[6]; $netname = $matches[7]; $total = $matches[8]; $free = $matches[9]; $backup = $matches[10]; $lts = $match es[11]; // a problem with ISC DHCP is that pool id can be dynamic so only the larger pools (>10) can be monitored if( $total > 10 && ( $free + $backup < 3 || ( ( $free + $backup ) / $total ) * 100 < 3 ) ) { // SEND AN ALERT // Randall Grimshaw rgrimsha at syr.edu ________________________________________ From: dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org [dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org] on behalf of John Wobus [jw354 at cornell.edu] Sent: Friday, April 13, 2012 4:07 PM To: Users of ISC DHCP Subject: Re: DHCP Failover and dhcpd.leases > I?m currently using a single DHCP server from which I periodically > sync the dhcpd.leases file to a second backup DHCP where the deamon > is not started. That?s my cold standby failover. > Now I want to use the ISC-DHCPs build-in failover system which I > already successfully configured and tested in a testing environment. > My question is, what happens to the leases database when the server > is in failover mode? > Are all leases written to the file on both server peers or only > those which were handed out by the failover peer? Clearly, do both > servers have the same leases file? > I built some software around the leases database an so I rely on > having all active leases in it. > > Another question is, if I change my running config on the productive > server to do ISC failover, how does this affect already given out > leases? Are they simply synced to the secondary peer? Each server sends info about the leases it grants to the peer server so the peer server can add it to its lease file. This communication is done asynchronously, i.e., though servers wait for their own lease file update to finish before sending the ACK, they do NOT make the ACK wait until the info is on the peer server's disk. We periodically scan the leases file to tell us about pool usage, basically to warn us of full pools and to give us data to help make adjustments. We scan only one lease file, and just keep in mind that our results aren't watertight, just very helpful. John Wobus Cornell IT _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users From teva at viti.pf Fri Apr 13 21:25:00 2012 From: teva at viti.pf (Teva AVRIL-TEIPOARII) Date: Fri, 13 Apr 2012 11:25:00 -1000 Subject: DHCPD issue parameters Message-ID: <012e01cd19bb$e22c3860$a684a920$@pf> Greetings, I've got a dhcpd server, which is working good. However i've got an issue: i've modified one parameter on the dhcpd.conf for one subnet (i've changed option domain-name-servers ip), i've restarted the dhcpd service. My issue is i've got an ip address, but not the update DNS-servers. Here below configuration of the dhcpd.conf before modification: shared-network test { option domain-name "test.com"; option domain-name-servers 192.168.1.2, 192.168.1.3; default-lease-time 360; max-lease-time 360; subnet 192.168.10.0 netmask 255.255.255.0 { option routers 192.168.10.254; option subnet-mask 255.255.255.0; option broadcast-address 192.168.10.255; } pool { range 192.168.10.1 192.168.10.253; } } And now after modification: shared-network test { option domain-name "test.com"; option domain-name-servers 192.168.45.1, 192.168.1.3; default-lease-time 360; max-lease-time 360; subnet 192.168.10.0 netmask 255.255.255.0 { option routers 192.168.10.254; option subnet-mask 255.255.255.0; option broadcast-address 192.168.10.255; } pool { range 192.168.10.1 192.168.10.253; } } And here below global parameters applied to all subnets: ddns-update-style none; authoritative; log-facility local7; update-static-leases on; The result is that instead of having 192.168.45.1 and 192.168.1.3 as primary and secondary DNS, i still got 192.168.1.2 and 192.168.1.3 as primary and secondary DNS. I've deleted dhcpd.leases , thinking that maybe the issue could come from some leases not expired, but result is the same. I've performed a wireshark capture, and during the DORA process, i see that the DHCP server is sending the update DNS as it should. However on my PC (on Windows), i still see old DNS servers attributed (attribution is automatic, it's not in static on network configuration of the PC). I don't understand where this problem come from, if you have an idea, please let me know. From sar at isc.org Fri Apr 13 22:23:58 2012 From: sar at isc.org (Shawn Routhier) Date: Fri, 13 Apr 2012 15:23:58 -0700 Subject: ISC 4.1-ESV-R5b1 is now available Message-ID: <26209B28-FE2A-4B15-A676-62C30F0210C6@isc.org> ISC DHCP 4.1-ESV-R5b1 is now available for download. This is the FIRST BETA of ISC DHCP 4.1-ESV-R5, a maintenance release which contains many bug fixes including some previously released security patches. A list of the changes in this release has been appended to the end of this message. This release includes changes to the code to allocate and manage IPv6 addresses, please pay particular attention to this area in any testing you do. For a complete list of changes from any previous release, please consult the RELNOTES file within the source distribution, or on our website: http://www.isc.org/software/dhcp/41-esv-r5b1 This release, and its OpenPGP-signatures are available now from: ftp://ftp.isc.org/isc/dhcp/4.1-ESV-R5b1/dhcp-4.1-ESV-R5b1.tar.gz ftp://ftp.isc.org/isc/dhcp/4.1-ESV-R5b1/dhcp-4.1-ESV-R5b1.tar.gz.sha512.asc ftp://ftp.isc.org/isc/dhcp/4.1-ESV-R5b1/dhcp-4.1-ESV-R5b1.tar.gz.sha256.asc ftp://ftp.isc.org/isc/dhcp/4.1-ESV-R5b1/dhcp-4.1-ESV-R5b1.tar.gz.sha1.asc ISC's Release Signing Key can be obtained at: http://www.isc.org/about/openpgp/ Changes since 4.1-ESV-R4 - Fixed the code that checks if an address the server is planning to hand out is in a reserved range. This would appear as the server being out of addresses in pools with particular ranges. [ISC-Bugs #26498] - Tidy up the receive calls and eliminate the need for found_pkt [ISC-Bugs #25066] - Add support for Infiniband over sockets to the server and relay code. We've tested this on Solaris and hope to expand support for Infiniband in the future. This patch also corrects some issues we found in the socket code. [ISC-Bugs #24245] - Add a compile time check for the presence of the noreturn attribute and use it for log_fatal if it's available. This will help code checking programs to eliminate false positives. [ISC-Bugs #27539] - Fixed many compilation problems ("set, but not used" warnings) for gcc 4.6 that may affect Ubuntu 11.10 users. [ISC-Bugs #27588] - Remove outdated note in the bootp keyword about the option not satisfying the requirement of failover peers for denying dynamic bootp clients. [ISC-bugs #28574] - Multiple items to clean up IPv6 address processing. When processing an IA that we've seen check to see if the addresses are usable (not in use by somebody else) before handing it out. When reading in leases from the file discard expired addresses. When picking an address for a client include the IA ID in addition to the client ID to generally pick different addresses for different IAs. [ISC-Bugs #23138] [ISC-Bugs #27945] [ISC-Bugs #25586] [ISC-Bugs #27684] - Remove unnecessary checks in the lease query code and clean up several compiler issues (some dereferences of NULL and treating an int as a boolean). [ISC-Bugs #26203] - Fix the NA and PD allocation code to handle the case where a client provides a preference and the server doesn't have any addresses or prefixes available. Previoulsy the server ignored the request with this patch it replies with a NoAddrsAvail or NoPrefixAvai respone. By default the code performs according to the errata of August 2010 for RFC 3315 section 17.2.2, to enable the previous style see the seciton on RFC3315_PRE_ERRATA_2010_08 in includes/site.h. This option may be removed in the future. Thanks to Jiri Popelka at Red Hat for the patch. [ISC-Bugs #22676] - Fix up some issues found by static analysis A potential memory leak and NULL dereference in omapi. The use of a boolean test instead of a bitwise test in dst. [ISC-Bugs #28941] From sar at isc.org Fri Apr 13 22:33:48 2012 From: sar at isc.org (Shawn Routhier) Date: Fri, 13 Apr 2012 15:33:48 -0700 Subject: ISC DHCP 4.2.4b1 is now available Message-ID: <8359E31E-A5B8-4668-8117-A31A125AF430@isc.org> ISC DHCP 4.2.4b1 is now available for download. This is the FIRST BETA of ISC DHCP 4.2.4, a maintenance release which contains many bug fixes including some previously released security patches. A list of the changes in this release has been appended to the end of this message. This release includes changes to the code to allocate and manage IPv6 addresses, please pay particular attention to this area in any testing you do. For a complete list of changes from any previous release, please consult the RELNOTES file within the source distribution, or on our website: http://www.isc.org/software/dhcp/424b1 This release, and its OpenPGP-signatures are available now from: ftp://ftp.isc.org/isc/dhcp/4.2.4b1/dhcp-4.2.4b1.tar.gz ftp://ftp.isc.org/isc/dhcp/4.2.4b1/dhcp-4.2.4b1.tar.gz.sha512.asc ftp://ftp.isc.org/isc/dhcp/4.2.4b1/dhcp-4.2.4b1.tar.gz.sha256.asc ftp://ftp.isc.org/isc/dhcp/4.2.4b1/dhcp-4.2.4b1.tar.gz.sha1.asc ISC's Release Signing Key can be obtained at: http://www.isc.org/about/openpgp/ Changes since 4.2.3 ! Add a check for a null pointer before calling the regexec function. Without this check we could, under some circumstances, pass a null pointer to the regexec function causing it to segfault. Thanks to a report from BlueCat Networks. [ISC-Bugs #26704]. CVE: CVE-2011-4539 ! Modify the DDNS handling code. In a previous patch we added logging code to the DDNS handling. This code included a bug that caused it to attempt to dereference a NULL pointer and eventually segfault. While reviewing the code as we addressed this problem, we determined that some of the updates to the lease structures would not work as planned since the structures being updated were in the process of being freed: these updates were removed. In addition we removed an incorrect call to the DDNS removal function that could cause a failure during the removal of DDNS information from the DNS server. Thanks to Jasper Jongmans for reporting this issue. [ISC-Bugs #27078] CVE: CVE-2011-4868 - Fixed the code that checks if an address the server is planning to hand out is in a reserved range. This would appear as the server being out of addresses in pools with particular ranges. [ISC-Bugs #26498] - In the DDNS code handle error conditions more gracefully and add more logging code. The major change is to handle unexpected cancel events from the DNS client code. [ISC-Bugs #26287]. - Tidy up the receive calls and eliminate the need for found_pkt [ISC-Bugs #25066] - Add support for Infiniband over sockets to the server and relay code. We've tested this on Solaris and hope to expand support for Infiniband in the future. This patch also corrects some issues we found in the socket code. [ISC-Bugs #24245] - Add a compile time check for the presence of the noreturn attribute and use it for log_fatal if it's available. This will help code checking programs to eliminate false positives. [ISC-Bugs #27539] - Fixed many compilation problems ("set, but not used" warnings) for gcc 4.6 that may affect Ubuntu 11.10 users. [ISC-Bugs #27588] - Modify the code that determines if an outstanding DDNS request should be cancelled. This patch results in cancelling the outstanding request less often. It fixes the problem caused by a client doing a release where the txt and ptr records weren't removed from the DNS. [ISC-BUGS #27858] - Use offsetof() instead of sizeof() to get the sizes for dhcpv6_relay_packet and dhcpv6_packet in several more places. Thanks to a report from Bruno Verstuyft and Vincent Demaertelaere of Excentis. [ISC-Bugs #27941] - Remove outdated note in the bootp keyword about the option not satisfying the requirement of failover peers for denying dynamic bootp clients. [ISC-bugs #28574] - Multiple items to clean up IPv6 address processing. When processing an IA that we've seen check to see if the addresses are usable (not in use by somebody else) before handing it out. When reading in leases from the file discard expired addresses. When picking an address for a client include the IA ID in addition to the client ID to generally pick different addresses for different IAs. [ISC-Bugs #23138] [ISC-Bugs #27945] [ISC-Bugs #25586] [ISC-Bugs #27684] - Remove unnecessary checks in the lease query code and clean up several compiler issues (some dereferences of NULL and treating an int as a boolean). [ISC-Bugs #26203] - Fix the NA and PD allocation code to handle the case where a client provides a preference and the server doesn't have any addresses or prefixes available. Previoulsy the server ignored the request with this patch it replies with a NoAddrsAvail or NoPrefixAvai respone. By default the code performs according to the errata of August 2010 for RFC 3315 section 17.2.2, to enable the previous style see the seciton on RFC3315_PRE_ERRATA_2010_08 in includes/site.h. This option may be removed in the future. Thanks to Jiri Popelka at Red Hat for the patch. [ISC-Bugs #22676] - Fix up some issues found by static analysis A potential memory leak and NULL dereference in omapi. The use of a boolean test instead of a bitwise test in dst. [ISC-Bugs #28941] From harald.schoener at mygate.net Sat Apr 14 12:32:55 2012 From: harald.schoener at mygate.net (=?ISO-8859-1?Q?Harald_Sch=F6ner?=) Date: Sat, 14 Apr 2012 14:32:55 +0200 Subject: DHCPD issue parameters In-Reply-To: <012e01cd19bb$e22c3860$a684a920$@pf> References: <012e01cd19bb$e22c3860$a684a920$@pf> Message-ID: This is a misbehavior of the DHCP client, as it doesn't look at the changed options during a renew of its lease. This has been observed with many dhcp clients, even the isc one. On 13 April 2012 23:25, Teva AVRIL-TEIPOARII wrote: > > Greetings, > > I've got a dhcpd server, which is working good. However i've got an issue: > i've modified one parameter on the dhcpd.conf for one subnet (i've changed > option domain-name-servers ip), i've restarted the dhcpd service. > > My issue is i've got an ip address, but not the update DNS-servers. > > Here below configuration of the dhcpd.conf before modification: > > shared-network test { > option domain-name "test.com"; > option domain-name-servers 192.168.1.2, 192.168.1.3; > default-lease-time 360; > max-lease-time 360; > > subnet 192.168.10.0 netmask 255.255.255.0 { > option routers 192.168.10.254; > option subnet-mask 255.255.255.0; > option broadcast-address 192.168.10.255; > } > > pool { > range 192.168.10.1 192.168.10.253; > } > } > > And now after modification: > > shared-network test { > option domain-name "test.com"; > option domain-name-servers 192.168.45.1, 192.168.1.3; > default-lease-time 360; > max-lease-time 360; > > subnet 192.168.10.0 netmask 255.255.255.0 { > option routers 192.168.10.254; > option subnet-mask 255.255.255.0; > option broadcast-address 192.168.10.255; > } > > pool { > range 192.168.10.1 192.168.10.253; > } > } > > And here below global parameters applied to all subnets: > > > ddns-update-style none; > authoritative; > log-facility local7; > update-static-leases on; > > > > > The result is that instead of having 192.168.45.1 and 192.168.1.3 as > primary > and secondary DNS, i still got 192.168.1.2 and 192.168.1.3 as primary and > secondary DNS. > > I've deleted dhcpd.leases , thinking that maybe the issue could come from > some leases not expired, but result is the same. > > I've performed a wireshark capture, and during the DORA process, i see that > the DHCP server is sending the update DNS as it should. However on my PC > (on > Windows), i still see old DNS servers attributed (attribution is automatic, > it's not in static on network configuration of the PC). > > I don't understand where this problem come from, if you have an idea, > please > let me know. > > > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thilo.bangert at gmail.com Sat Apr 14 20:21:10 2012 From: thilo.bangert at gmail.com (Thilo Bangert) Date: Sat, 14 Apr 2012 22:21:10 +0200 Subject: monitoring Message-ID: <63550769.sYVJMKd9Z0@marsupilami> Hi, regarding monitoring of isc dhcp servers, i have thus far only found tools which monitor pool exhaustion[*]. has somebody developed tools to monitor other metrics, like number and/or type of requests processed or similar? from the looks of it, it appears dhcpd does not collect metrics like this by itself, so my current plan of action would be to parse the logfile... if anybody has a better idea, it would be much appreciated ;-) thanks kind regards Thilo [*] like http://dhcpd-pools.sourceforge.net/ From rgrimsha at syr.edu Sun Apr 15 01:18:07 2012 From: rgrimsha at syr.edu (Randall C Grimshaw) Date: Sun, 15 Apr 2012 01:18:07 +0000 Subject: monitoring In-Reply-To: <63550769.sYVJMKd9Z0@marsupilami> References: <63550769.sYVJMKd9Z0@marsupilami> Message-ID: We parse the syslog for many things, but do not find those metrics interesting. Randall Grimshaw rgrimsha at syr.edu ________________________________________ From: dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org [dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org] on behalf of Thilo Bangert [thilo.bangert at gmail.com] Sent: Saturday, April 14, 2012 4:21 PM To: dhcp-users at lists.isc.org Subject: monitoring Hi, regarding monitoring of isc dhcp servers, i have thus far only found tools which monitor pool exhaustion[*]. has somebody developed tools to monitor other metrics, like number and/or type of requests processed or similar? from the looks of it, it appears dhcpd does not collect metrics like this by itself, so my current plan of action would be to parse the logfile... if anybody has a better idea, it would be much appreciated ;-) thanks kind regards Thilo [*] like http://dhcpd-pools.sourceforge.net/ _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users From sscdvp at gmail.com Sun Apr 15 16:35:31 2012 From: sscdvp at gmail.com (sscdvp at gmail.com) Date: Sun, 15 Apr 2012 19:35:31 +0300 Subject: monitoring In-Reply-To: <63550769.sYVJMKd9Z0@marsupilami> References: <63550769.sYVJMKd9Z0@marsupilami> Message-ID: Following the link http://sscdvp.blogspot.com/2011/11/dhcp-traffic-statistics-datasheet.html shows some DHCP traffic metrics exposed via KSTAT (DHCPv4 Filtering STREAMS module). Regards, Serghei Samsi 2012/4/14 Thilo Bangert > Hi, > > regarding monitoring of isc dhcp servers, i have thus far only found tools > which monitor pool exhaustion[*]. > > has somebody developed tools to monitor other metrics, like number and/or > type > of requests processed or similar? > > from the looks of it, it appears dhcpd does not collect metrics like this > by > itself, so my current plan of action would be to parse the logfile... > > if anybody has a better idea, it would be much appreciated ;-) > > thanks > kind regards > Thilo > > > [*] like http://dhcpd-pools.sourceforge.net/ > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ameen.shajahan at wipro.com Mon Apr 16 05:24:12 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Mon, 16 Apr 2012 05:24:12 +0000 Subject: testing DHCPv6 stateless ?? Message-ID: Hi all, How to test the DHCPv6 stateless functionality using ISC DHCP-4.2.3 If anybody tested means , Please let me know the test case scenario. Thanks, Ameen S Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Wim.Nelis at nlr.nl Mon Apr 16 06:00:39 2012 From: Wim.Nelis at nlr.nl (W.J.M. Nelis) Date: Mon, 16 Apr 2012 08:00:39 +0200 Subject: monitoring In-Reply-To: <63550769.sYVJMKd9Z0@marsupilami> References: <63550769.sYVJMKd9Z0@marsupilami> Message-ID: <4F8BB587.4000309@nlr.nl> Hello, > regarding monitoring of isc dhcp servers, i have thus far only found tools > which monitor pool exhaustion[*]. > > has somebody developed tools to monitor other metrics, like number and/or type > of requests processed or similar? We use a Perl script to incrementally scan the logfile of a ISC dhcp server, and report the number of dhcp actions since the last run of the script. The results are reported to Xymon. The output generated by Xymon is shown in the attachment. Please ignore message type 'netmon': that is a NLR specific extension. Is that what you are looking for? Regards, Wim Nelis. ****************************************************************************************************************** The NLR disclaimer is valid for NLR e-mail messages. This message is only meant for providing information. Nothing in this e-mail message amounts to a contractual or legal commitment on the part of the sender. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. Sender accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. ****************************************************************************************************************** -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot.png Type: image/png Size: 161319 bytes Desc: not available URL: From M.Kueppers at douglas-informatik.de Mon Apr 16 06:29:36 2012 From: M.Kueppers at douglas-informatik.de (=?iso-8859-1?Q?=22K=FCppers=2C_Malte=22?=) Date: Mon, 16 Apr 2012 08:29:36 +0200 Subject: DHCP Failover and dhcpd.leases Message-ID: Hi there and thanks a lot for your replies! There are just some questions left: - I guess thats ok then, so I can safely enable failover mode without losing leases?! - How long does it take until the leases files are synchronized and equal on both servers? Until next update is pushed ? - Will I have to start the second server with a copy of the leases file? Or does a blank file work fine? Because while testing, I ran into the problem that if I wiped the leases files on both sides the both server got stuck in some "waiting for update" state an neither primary nor secondary was handing out leases anymore... How can I wipe out the files safely if needed? Thanks in advance Regards Malte -------------- next part -------------- An HTML attachment was scrubbed... URL: From ameen.shajahan at wipro.com Mon Apr 16 07:13:48 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Mon, 16 Apr 2012 07:13:48 +0000 Subject: testing DHCPv6 stateless ?? Message-ID: Hi all, How to test the DHCPv6 stateless functionality using ISC DHCP-4.2.3 If anybody tested means , Please let me know the test case scenario. Thanks, Ameen S Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From cathya at isc.org Mon Apr 16 12:57:54 2012 From: cathya at isc.org (Cathy Almond) Date: Mon, 16 Apr 2012 13:57:54 +0100 Subject: DHCPD issue parameters In-Reply-To: References: <012e01cd19bb$e22c3860$a684a920$@pf> Message-ID: <4F8C1752.1030906@isc.org> On 14/04/12 13:32, Harald Sch?ner wrote: > This is a misbehavior of the DHCP client, as it doesn't look at the changed > options during > a renew of its lease. > > This has been observed with many dhcp clients, even the isc one. Hi Harald, We're not aware of this misbehaviour occurring with the ISC DHCP client - it observes the updated domain-name-servers in our tests. What version were you using when you encountered this? Are you able to confirm that this doesn't work properly with a current production version of DHCP client? If so, we'd very much appreciate a bug report with configuration files and other supporting information (resulting client /etc/resolv.conf, wireshark tracing etc..) Many thanks Cathy > On 13 April 2012 23:25, Teva AVRIL-TEIPOARII wrote: > >> >> Greetings, >> >> I've got a dhcpd server, which is working good. However i've got an issue: >> i've modified one parameter on the dhcpd.conf for one subnet (i've changed >> option domain-name-servers ip), i've restarted the dhcpd service. >> >> My issue is i've got an ip address, but not the update DNS-servers. >> >> Here below configuration of the dhcpd.conf before modification: >> >> shared-network test { >> option domain-name "test.com"; >> option domain-name-servers 192.168.1.2, 192.168.1.3; >> default-lease-time 360; >> max-lease-time 360; >> >> subnet 192.168.10.0 netmask 255.255.255.0 { >> option routers 192.168.10.254; >> option subnet-mask 255.255.255.0; >> option broadcast-address 192.168.10.255; >> } >> >> pool { >> range 192.168.10.1 192.168.10.253; >> } >> } >> >> And now after modification: >> >> shared-network test { >> option domain-name "test.com"; >> option domain-name-servers 192.168.45.1, 192.168.1.3; >> default-lease-time 360; >> max-lease-time 360; >> >> subnet 192.168.10.0 netmask 255.255.255.0 { >> option routers 192.168.10.254; >> option subnet-mask 255.255.255.0; >> option broadcast-address 192.168.10.255; >> } >> >> pool { >> range 192.168.10.1 192.168.10.253; >> } >> } >> >> And here below global parameters applied to all subnets: >> >> >> ddns-update-style none; >> authoritative; >> log-facility local7; >> update-static-leases on; >> >> >> >> >> The result is that instead of having 192.168.45.1 and 192.168.1.3 as >> primary >> and secondary DNS, i still got 192.168.1.2 and 192.168.1.3 as primary and >> secondary DNS. >> >> I've deleted dhcpd.leases , thinking that maybe the issue could come from >> some leases not expired, but result is the same. >> >> I've performed a wireshark capture, and during the DORA process, i see that >> the DHCP server is sending the update DNS as it should. However on my PC >> (on >> Windows), i still see old DNS servers attributed (attribution is automatic, >> it's not in static on network configuration of the PC). >> >> I don't understand where this problem come from, if you have an idea, >> please >> let me know. >> >> >> >> _______________________________________________ >> dhcp-users mailing list >> dhcp-users at lists.isc.org >> https://lists.isc.org/mailman/listinfo/dhcp-users >> > > > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users From glenn.satchell at uniq.com.au Mon Apr 16 14:23:16 2012 From: glenn.satchell at uniq.com.au (Glenn Satchell) Date: Tue, 17 Apr 2012 00:23:16 +1000 Subject: DHCP Failover and dhcpd.leases In-Reply-To: References: Message-ID: <4F8C2B54.2030908@uniq.com.au> On 04/16/12 16:29, "K?ppers, Malte" wrote: > Hi there and thanks a lot for your replies! > > There are just some questions left: > > -I guess thats ok then, so I can safely enable failover mode without > losing leases?! Yes. > -How long does it take until the leases files are synchronized and equal > on both servers? Until next update is pushed ? As quickly as the leases can be copied over the network. FOr a small lease file it could be a few 10s of seconds, a large (few MB) might take a couple of minutes. > -Will I have to start the second server with a copy of the leases file? > Or does a blank file work fine? Because while testing, I ran into the > problem that if I wiped the leases files on both sides the > both server got stuck in some ?waiting for update? state an neither > primary nor secondary was handing out leases anymore. How can I wipe out > the files safely if needed? No. Start existing server with existing lease file. Start new server with empty lease file. New server will request a lease update from the other server. This is covered in the section titled FAILOVER STARTUP in the dhcpd.conf man page. If you wipe the lease files on both sides then both servers go into a state where they will wait before issuing new leases. Generally this is a bad thing to do, so you shouldn't wipe both lease files in production. Even though the servers have no concept of any leases after wiping the lease files, all the clients *do* have leases, but the servers are now out of synch with the clients, so the servers wait for the current leases to expire before handing out new leases. If the two systems get out of synch with each other (network error where they can't communicate for example) you can pick one system with the "best" lease file, and wipe out the other one, but really it's best to avoid that and let the systems heal themselves. It's best to arrange for syslog from your dhcp servers to go to the same host so you can see messages from both together. The other thing you'll see which may seem odd is initially a new client will get a lease that is half of the MCLT setting. Next time it renews it will get the full lease time. regards, -glenn > Thanks in advance > > Regards > > Malte > > > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users -- regards, -glenn -- Glenn Satchell | Miss 9: What do you Uniq Advances Pty Ltd, Sydney Australia | do at work Dad? mailto:glenn.satchell at uniq.com.au | Miss 6: He just http://www.uniq.com.au tel:0409-458-580 | types random stuff. From teva at viti.pf Mon Apr 16 21:25:33 2012 From: teva at viti.pf (Teva AVRIL-TEIPOARII) Date: Mon, 16 Apr 2012 11:25:33 -1000 Subject: DHCPD issue parameters In-Reply-To: References: Message-ID: <037301cd1c17$750ffce0$5f2ff6a0$@pf> Hi, What could be done so the DHCP client would look at the changed options during a renew of its lease ? It really seems something like this indeed:After 2 days off, i'm trying again, and then DNS parameters has been updated, but now client has 192.168.45.1 as primary AND secondary DNS servers, instead of 192.168.45.1 and 192.168.1.3. I've tested different computers, and result is the same for all of them now: every client get 192.168.45.1 as DNS servers as primary and secondary. I could understand that one client could misbehave DHCP Offer from the DHCP server, however when all clients has the same behavior... Really weird... If anyone has an idea, i'd be glad to read it. Regards, ---------------------------------------------------------------------- Message: 1 Date: Sat, 14 Apr 2012 14:32:55 +0200 From: Harald Sch?ner To: Users of ISC DHCP Subject: Re: DHCPD issue parameters Message-ID: Content-Type: text/plain; charset="iso-8859-1" This is a misbehavior of the DHCP client, as it doesn't look at the changed options during a renew of its lease. This has been observed with many dhcp clients, even the isc one. On 13 April 2012 23:25, Teva AVRIL-TEIPOARII wrote: > > Greetings, > > I've got a dhcpd server, which is working good. However i've got an issue: > i've modified one parameter on the dhcpd.conf for one subnet (i've > changed option domain-name-servers ip), i've restarted the dhcpd service. > > My issue is i've got an ip address, but not the update DNS-servers. > > Here below configuration of the dhcpd.conf before modification: > > shared-network test { > option domain-name "test.com"; > option domain-name-servers 192.168.1.2, 192.168.1.3; > default-lease-time 360; max-lease-time 360; > > subnet 192.168.10.0 netmask 255.255.255.0 { option routers > 192.168.10.254; option subnet-mask 255.255.255.0; option > broadcast-address 192.168.10.255; } > > pool { > range 192.168.10.1 192.168.10.253; > } > } > > And now after modification: > > shared-network test { > option domain-name "test.com"; > option domain-name-servers 192.168.45.1, 192.168.1.3; > default-lease-time 360; max-lease-time 360; > > subnet 192.168.10.0 netmask 255.255.255.0 { option routers > 192.168.10.254; option subnet-mask 255.255.255.0; option > broadcast-address 192.168.10.255; } > > pool { > range 192.168.10.1 192.168.10.253; > } > } > > And here below global parameters applied to all subnets: > > > ddns-update-style none; > authoritative; > log-facility local7; > update-static-leases on; > > > > > The result is that instead of having 192.168.45.1 and 192.168.1.3 as > primary and secondary DNS, i still got 192.168.1.2 and 192.168.1.3 as > primary and secondary DNS. > > I've deleted dhcpd.leases , thinking that maybe the issue could come > from some leases not expired, but result is the same. > > I've performed a wireshark capture, and during the DORA process, i see > that the DHCP server is sending the update DNS as it should. However > on my PC (on Windows), i still see old DNS servers attributed > (attribution is automatic, it's not in static on network configuration > of the PC). > > I don't understand where this problem come from, if you have an idea, > please let me know. > > > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users > From M.Kueppers at douglas-informatik.de Tue Apr 17 13:52:30 2012 From: M.Kueppers at douglas-informatik.de (=?iso-8859-1?Q?=22K=FCppers=2C_Malte=22?=) Date: Tue, 17 Apr 2012 15:52:30 +0200 Subject: DHCP Failover and dhcpd.leases Message-ID: Thanks a lot! I now have it fully functional with failover active. I initially had some issues with the leases db, but after wiping the one on the secondary server everthing works fine now. On 04/16/12 16:29, "K?ppers, Malte" wrote: > Hi there and thanks a lot for your replies! > > There are just some questions left: > > -I guess thats ok then, so I can safely enable failover mode without > losing leases?! Yes. > -How long does it take until the leases files are synchronized and > equal on both servers? Until next update is pushed ? As quickly as the leases can be copied over the network. FOr a small lease file it could be a few 10s of seconds, a large (few MB) might take a couple of minutes. > -Will I have to start the second server with a copy of the leases file? > Or does a blank file work fine? Because while testing, I ran into the > problem that if I wiped the leases files on both sides the both server > got stuck in some ?waiting for update? state an neither primary nor > secondary was handing out leases anymore. How can I wipe out the files > safely if needed? No. Start existing server with existing lease file. Start new server with empty lease file. New server will request a lease update from the other server. This is covered in the section titled FAILOVER STARTUP in the dhcpd.conf man page. If you wipe the lease files on both sides then both servers go into a state where they will wait before issuing new leases. Generally this is a bad thing to do, so you shouldn't wipe both lease files in production. Even though the servers have no concept of any leases after wiping the lease files, all the clients *do* have leases, but the servers are now out of synch with the clients, so the servers wait for the current leases to expire before handing out new leases. If the two systems get out of synch with each other (network error where they can't communicate for example) you can pick one system with the "best" lease file, and wipe out the other one, but really it's best to avoid that and let the systems heal themselves. It's best to arrange for syslog from your dhcp servers to go to the same host so you can see messages from both together. The other thing you'll see which may seem odd is initially a new client will get a lease that is half of the MCLT setting. Next time it renews it will get the full lease time. regards, -glenn > Thanks in advance > > Regards > > Malte > > > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users -- regards, -glenn -- Glenn Satchell | Miss 9: What do you Uniq Advances Pty Ltd, Sydney Australia | do at work Dad? mailto:glenn.satchell at uniq.com.au | Miss 6: He just http://www.uniq.com.au tel:0409-458-580 | types random stuff. From teva at viti.pf Wed Apr 18 00:11:44 2012 From: teva at viti.pf (Teva AVRIL-TEIPOARII) Date: Tue, 17 Apr 2012 14:11:44 -1000 Subject: DHCPD issue parameters In-Reply-To: References: Message-ID: <000801cd1cf7$d70dfb50$8529f1f0$@pf> The version of DHCP i'm using is isc-dhcpd-V3.0.5-RedHat. I'm not able to confirm if it works with the last version of dhcpd, I will test it and see how it works. In the meantime if everyone has some idea about it, don't hesitate. -----Message d'origine----- De?: dhcp-users-bounces+teva=viti.pf at lists.isc.org [mailto:dhcp-users-bounces+teva=viti.pf at lists.isc.org] De la part de dhcp-users-request at lists.isc.org Envoy??: mardi 17 avril 2012 02:00 ??: dhcp-users at lists.isc.org Objet?: dhcp-users Digest, Vol 42, Issue 18 Send dhcp-users mailing list submissions to dhcp-users at lists.isc.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.isc.org/mailman/listinfo/dhcp-users or, via email, send a message with subject or body 'help' to dhcp-users-request at lists.isc.org You can reach the person managing the list at dhcp-users-owner at lists.isc.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dhcp-users digest..." Today's Topics: 1. Re: DHCPD issue parameters (Cathy Almond) 2. Re: DHCP Failover and dhcpd.leases (Glenn Satchell) 3. Re: DHCPD issue parameters (Teva AVRIL-TEIPOARII) ---------------------------------------------------------------------- Message: 1 Date: Mon, 16 Apr 2012 13:57:54 +0100 From: Cathy Almond To: dhcp-users at lists.isc.org Subject: Re: DHCPD issue parameters Message-ID: <4F8C1752.1030906 at isc.org> Content-Type: text/plain; charset=ISO-8859-1 On 14/04/12 13:32, Harald Sch?ner wrote: > This is a misbehavior of the DHCP client, as it doesn't look at the changed > options during > a renew of its lease. > > This has been observed with many dhcp clients, even the isc one. Hi Harald, We're not aware of this misbehaviour occurring with the ISC DHCP client - it observes the updated domain-name-servers in our tests. What version were you using when you encountered this? Are you able to confirm that this doesn't work properly with a current production version of DHCP client? If so, we'd very much appreciate a bug report with configuration files and other supporting information (resulting client /etc/resolv.conf, wireshark tracing etc..) Many thanks Cathy > On 13 April 2012 23:25, Teva AVRIL-TEIPOARII wrote: > >> >> Greetings, >> >> I've got a dhcpd server, which is working good. However i've got an issue: >> i've modified one parameter on the dhcpd.conf for one subnet (i've changed >> option domain-name-servers ip), i've restarted the dhcpd service. >> >> My issue is i've got an ip address, but not the update DNS-servers. >> >> Here below configuration of the dhcpd.conf before modification: >> >> shared-network test { >> option domain-name "test.com"; >> option domain-name-servers 192.168.1.2, 192.168.1.3; >> default-lease-time 360; >> max-lease-time 360; >> >> subnet 192.168.10.0 netmask 255.255.255.0 { >> option routers 192.168.10.254; >> option subnet-mask 255.255.255.0; >> option broadcast-address 192.168.10.255; >> } >> >> pool { >> range 192.168.10.1 192.168.10.253; >> } >> } >> >> And now after modification: >> >> shared-network test { >> option domain-name "test.com"; >> option domain-name-servers 192.168.45.1, 192.168.1.3; >> default-lease-time 360; >> max-lease-time 360; >> >> subnet 192.168.10.0 netmask 255.255.255.0 { >> option routers 192.168.10.254; >> option subnet-mask 255.255.255.0; >> option broadcast-address 192.168.10.255; >> } >> >> pool { >> range 192.168.10.1 192.168.10.253; >> } >> } >> >> And here below global parameters applied to all subnets: >> >> >> ddns-update-style none; >> authoritative; >> log-facility local7; >> update-static-leases on; >> >> >> >> >> The result is that instead of having 192.168.45.1 and 192.168.1.3 as >> primary >> and secondary DNS, i still got 192.168.1.2 and 192.168.1.3 as primary and >> secondary DNS. >> >> I've deleted dhcpd.leases , thinking that maybe the issue could come from >> some leases not expired, but result is the same. >> >> I've performed a wireshark capture, and during the DORA process, i see that >> the DHCP server is sending the update DNS as it should. However on my PC >> (on >> Windows), i still see old DNS servers attributed (attribution is automatic, >> it's not in static on network configuration of the PC). >> >> I don't understand where this problem come from, if you have an idea, >> please >> let me know. >> >> >> >> _______________________________________________ >> dhcp-users mailing list >> dhcp-users at lists.isc.org >> https://lists.isc.org/mailman/listinfo/dhcp-users >> > > > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users ------------------------------ Message: 2 Date: Tue, 17 Apr 2012 00:23:16 +1000 From: Glenn Satchell To: Users of ISC DHCP Subject: Re: DHCP Failover and dhcpd.leases Message-ID: <4F8C2B54.2030908 at uniq.com.au> Content-Type: text/plain; charset=windows-1252; format=flowed On 04/16/12 16:29, "K?ppers, Malte" wrote: > Hi there and thanks a lot for your replies! > > There are just some questions left: > > -I guess thats ok then, so I can safely enable failover mode without > losing leases?! Yes. > -How long does it take until the leases files are synchronized and equal > on both servers? Until next update is pushed ? As quickly as the leases can be copied over the network. FOr a small lease file it could be a few 10s of seconds, a large (few MB) might take a couple of minutes. > -Will I have to start the second server with a copy of the leases file? > Or does a blank file work fine? Because while testing, I ran into the > problem that if I wiped the leases files on both sides the > both server got stuck in some ?waiting for update? state an neither > primary nor secondary was handing out leases anymore. How can I wipe out > the files safely if needed? No. Start existing server with existing lease file. Start new server with empty lease file. New server will request a lease update from the other server. This is covered in the section titled FAILOVER STARTUP in the dhcpd.conf man page. If you wipe the lease files on both sides then both servers go into a state where they will wait before issuing new leases. Generally this is a bad thing to do, so you shouldn't wipe both lease files in production. Even though the servers have no concept of any leases after wiping the lease files, all the clients *do* have leases, but the servers are now out of synch with the clients, so the servers wait for the current leases to expire before handing out new leases. If the two systems get out of synch with each other (network error where they can't communicate for example) you can pick one system with the "best" lease file, and wipe out the other one, but really it's best to avoid that and let the systems heal themselves. It's best to arrange for syslog from your dhcp servers to go to the same host so you can see messages from both together. The other thing you'll see which may seem odd is initially a new client will get a lease that is half of the MCLT setting. Next time it renews it will get the full lease time. regards, -glenn > Thanks in advance > > Regards > > Malte > > > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users -- regards, -glenn -- Glenn Satchell | Miss 9: What do you Uniq Advances Pty Ltd, Sydney Australia | do at work Dad? mailto:glenn.satchell at uniq.com.au | Miss 6: He just http://www.uniq.com.au tel:0409-458-580 | types random stuff. ------------------------------ Message: 3 Date: Mon, 16 Apr 2012 11:25:33 -1000 From: "Teva AVRIL-TEIPOARII" To: Subject: Re: DHCPD issue parameters Message-ID: <037301cd1c17$750ffce0$5f2ff6a0$@pf> Content-Type: text/plain; charset="us-ascii" Hi, What could be done so the DHCP client would look at the changed options during a renew of its lease ? It really seems something like this indeed:After 2 days off, i'm trying again, and then DNS parameters has been updated, but now client has 192.168.45.1 as primary AND secondary DNS servers, instead of 192.168.45.1 and 192.168.1.3. I've tested different computers, and result is the same for all of them now: every client get 192.168.45.1 as DNS servers as primary and secondary. I could understand that one client could misbehave DHCP Offer from the DHCP server, however when all clients has the same behavior... Really weird... If anyone has an idea, i'd be glad to read it. Regards, ---------------------------------------------------------------------- Message: 1 Date: Sat, 14 Apr 2012 14:32:55 +0200 From: Harald Sch?ner To: Users of ISC DHCP Subject: Re: DHCPD issue parameters Message-ID: Content-Type: text/plain; charset="iso-8859-1" This is a misbehavior of the DHCP client, as it doesn't look at the changed options during a renew of its lease. This has been observed with many dhcp clients, even the isc one. On 13 April 2012 23:25, Teva AVRIL-TEIPOARII wrote: > > Greetings, > > I've got a dhcpd server, which is working good. However i've got an issue: > i've modified one parameter on the dhcpd.conf for one subnet (i've > changed option domain-name-servers ip), i've restarted the dhcpd service. > > My issue is i've got an ip address, but not the update DNS-servers. > > Here below configuration of the dhcpd.conf before modification: > > shared-network test { > option domain-name "test.com"; > option domain-name-servers 192.168.1.2, 192.168.1.3; > default-lease-time 360; max-lease-time 360; > > subnet 192.168.10.0 netmask 255.255.255.0 { option routers > 192.168.10.254; option subnet-mask 255.255.255.0; option > broadcast-address 192.168.10.255; } > > pool { > range 192.168.10.1 192.168.10.253; > } > } > > And now after modification: > > shared-network test { > option domain-name "test.com"; > option domain-name-servers 192.168.45.1, 192.168.1.3; > default-lease-time 360; max-lease-time 360; > > subnet 192.168.10.0 netmask 255.255.255.0 { option routers > 192.168.10.254; option subnet-mask 255.255.255.0; option > broadcast-address 192.168.10.255; } > > pool { > range 192.168.10.1 192.168.10.253; > } > } > > And here below global parameters applied to all subnets: > > > ddns-update-style none; > authoritative; > log-facility local7; > update-static-leases on; > > > > > The result is that instead of having 192.168.45.1 and 192.168.1.3 as > primary and secondary DNS, i still got 192.168.1.2 and 192.168.1.3 as > primary and secondary DNS. > > I've deleted dhcpd.leases , thinking that maybe the issue could come > from some leases not expired, but result is the same. > > I've performed a wireshark capture, and during the DORA process, i see > that the DHCP server is sending the update DNS as it should. However > on my PC (on Windows), i still see old DNS servers attributed > (attribution is automatic, it's not in static on network configuration > of the PC). > > I don't understand where this problem come from, if you have an idea, > please let me know. > > > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users > ------------------------------ _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users End of dhcp-users Digest, Vol 42, Issue 18 ****************************************** From sujataverma3 at yahoo.com Wed Apr 18 04:45:28 2012 From: sujataverma3 at yahoo.com (Sujata Verma) Date: Tue, 17 Apr 2012 21:45:28 -0700 (PDT) Subject: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST Message-ID: <1334724328.46142.YahooMailClassic@web121303.mail.ne1.yahoo.com> Hi, I am using dhcp-4.2.2rc1. I have started the dhcp relay with options dhcrelay -d -i eth0 -i eth1 serverip everything is working fine except that when client release the ip and send DHCPRELEASE packet on server side i get 3 packets for each DHCPRELEASE. One is directly sent to server ( which is valid packet) the other two are duplicate of this packet which is generated by relay agent with giaddr as address of eth0 and eth1 interface. Is this normal behavior? The same is observed with unicast DHCPREQUEST . While searching for related things i came across RFC 1542, section 4.1.1 BOOTREQUEST Messages If the relay agent does decide to relay the request, it MUST examine the 'giaddr' ("gateway" IP address) field. If this field is zero, the relay agent MUST fill this field with the IP address of the interface on which the request was received. If the interface has more than one IP address logically associated with it, the relay agent SHOULD choose one IP address associated with that interface and use it consistently for all BOOTP messages it relays. Here in this case my client is connected to "eth0" interface so initial DHCPDISCOVER and DHCPREQUEST message is going through proper giaddr i.e eth0 interface. I think the messages which are broadcast from the client are considering only one giaddr i.e. incoming addr but for unicast message behavior is different and considering both the interfaces, why is it so ? And as per this RFC, is the behavior incorrect ? Please help me understand it. Thanks for any help. Regards, Sujata -------------- next part -------------- An HTML attachment was scrubbed... URL: From ameen.shajahan at wipro.com Wed Apr 18 07:03:53 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Wed, 18 Apr 2012 07:03:53 +0000 Subject: DHCP query Message-ID: Hi all, Consider the scenario below. [cid:image001.png at 01CD1D5E.C164EA40] Client(PC) Server Have connected the server and client directly. Started the DHCP server in server side. Gave ipconfig /renew in client(PC) , IP address assigned to client PC . Then I stopped the DHCP server(dhcpd) in server side and gave ipconfig in client side to check whether it has the assigned IPaddress by the dhcp server. Yes client has IP address still. Eventhough we stopped the server , client still has IP address assigned by the server. How it is possible , without server how client is having the IP address given by the server. Also we can able to ping to the server because client having the IP address still. I think this could create a serious problem. Please let me know. Thanks, Ameen S Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 272 bytes Desc: image001.png URL: From A.L.M.Buxey at lboro.ac.uk Wed Apr 18 07:15:01 2012 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Wed, 18 Apr 2012 08:15:01 +0100 Subject: DHCP query Message-ID: That's how it works. Client told to use an address and will keep it until either its released ipconfig /release , its turned off, disconnected/recollected (eg to new network) or when it queries/informs the server again (usually halfway through its current lease) alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From thilo.bangert at gmail.com Wed Apr 18 07:22:28 2012 From: thilo.bangert at gmail.com (Thilo Bangert) Date: Wed, 18 Apr 2012 09:22:28 +0200 Subject: monitoring In-Reply-To: <4F8BB587.4000309@nlr.nl> References: <63550769.sYVJMKd9Z0@marsupilami> <4F8BB587.4000309@nlr.nl> Message-ID: <13351478.k0yay2X83c@gaston> On Monday, April 16, 2012 08:00:39 AM W.J.M. Nelis wrote: > Hello, > > > regarding monitoring of isc dhcp servers, i have thus far only found tools > > which monitor pool exhaustion[*]. > > > > has somebody developed tools to monitor other metrics, like number and/or > > type of requests processed or similar? > > We use a Perl script to incrementally scan the logfile of a ISC dhcp > server, and report the number of dhcp actions since the last run of the > script. The results are reported to Xymon. The output generated by Xymon is > shown in the attachment. Please ignore message type 'netmon': that is a NLR > specific extension. > > Is that what you are looking for? > yes - thank for sharing. very inspiring. i came up with the following munin plugin which does something similar. this has only been tested with an age old dhcpd server (3.x). it uses logtail. newer install may prefer to use logtail2. kind regards Thilo -------------- next part -------------- A non-text attachment was scrubbed... Name: dhcpd_stats-day.png Type: image/png Size: 28105 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: munin-dhcpd_stats Type: application/x-shellscript Size: 4279 bytes Desc: not available URL: From dhcp1 at thehobsons.co.uk Wed Apr 18 08:59:38 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Wed, 18 Apr 2012 09:59:38 +0100 Subject: DHCP query In-Reply-To: References: Message-ID: ameen.shajahan at wipro.com wrote: >Started the DHCP server in server side. >Gave ipconfig /renew in client(PC) , IP address assigned to client PC . >Then I stopped the DHCP server(dhcpd) in server side and gave >ipconfig in client side to check whether it has the assigned >IPaddress by the dhcp server. Yes client has IP address still. That is correct. When the server issues a lease, it basically tells the client "you can use this address (and other settings), and you can have it until ". Until that time arrives, the client is free to use that lease without further reference to the server. If the client has persistent storage and real time clock, it can even keep that address across restarts. After a period, typically about half the lease time) the client will attempt to renew the lease. Even when it gets no reply, it can still continue using the address. It only has to stop when the lease expires - at which point the client will remove the address and stop using it, and if it's failed to get another address then it will lose connectivity. I strongly suggest you track down the book "The DHCP Handbook" by Ralph Droms and Ted Lemon. ISBN 9781578701377 for the first edition, though there is a second edition out. This explains everything you've asked and a lot more besides (including the historical context of why some things are done as they are) - and it's very readable too. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From dhcp1 at thehobsons.co.uk Wed Apr 18 09:08:55 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Wed, 18 Apr 2012 10:08:55 +0100 Subject: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST In-Reply-To: <1334724328.46142.YahooMailClassic@web121303.mail.ne1.yahoo.com> References: <1334724328.46142.YahooMailClassic@web121303.mail.ne1.yahoo.com> Message-ID: Sujata Verma wrote: >I am using dhcp-4.2.2rc1. I have started the dhcp relay with options > >dhcrelay -d -i eth0 -i eth1 serverip > >everything is working fine except that when client release the ip >and send DHCPRELEASE packet on server side i get 3 packets for each >DHCPRELEASE. > >One is directly sent to server ( which is valid packet) the other >two are duplicate of this packet which is generated by relay agent >with giaddr as address of eth0 and eth1 interface. > >Is this normal behavior? The same is observed with unicast DHCPREQUEST . Are you sure about the unicast packets ? On a switched network, the packet should only ever bee seen by the server - it shouldn't reach the relay agent. For any boradcast packets, I'd expect to see two copies - one picked up directly by the server, and one picked up by the relay agent. This is inherent in the way the relay agent needs (due to the way it's built) to listen on both interfaces. I wouldn't expect to see a packet with the relay's eth1 address in it - they aren't connected to the same network are they ? -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From sujataverma3 at yahoo.com Wed Apr 18 10:46:28 2012 From: sujataverma3 at yahoo.com (Sujata Verma) Date: Wed, 18 Apr 2012 03:46:28 -0700 (PDT) Subject: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST Message-ID: <1334745988.54514.YahooMailClassic@web121301.mail.ne1.yahoo.com> Thanks for reply. My setup is like this :???????????????????????????????????????? ????????????????????????????????????????????????????????????????????? eth1 ? Windows 2003 server ( 192.168.9.2/23)-------------------(192.168.8.177/23) Linux PC(Relay) (80.1.1.1/24----------eth0----Windows XP Client ( DHCP client getting IP 80.1.1.2/24) In windows server the default gw is 192.168.8.177. The DHCP pool configured gateway is 80.1.1.1 ( relay agent ip) I am attaching the wireshark capture for both client and server. In this we can see that the DHCPDISCOVER is only being sent once to the server which relay is forwarding while adding giaddr field as 80.1.1.1 . When DHCPRELEASE packet is being sent, it is sent directly to the server and with other two packets as duplicates with giaddr as of two interfaces. In linux pc i have only enabled ipv4_forward and disabled iptables completely. Is there any other configuration which can result in my observation like this ? Please let me know your observations, after seeing the captures. I have tried many times with similar observation. Regards, Sujata ???????????????????????????????? --- On Wed, 4/18/12, Simon Hobson wrote: From: Simon Hobson Subject: Re: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST To: "Users of ISC DHCP" Date: Wednesday, April 18, 2012, 2:38 PM Sujata Verma wrote: > I am using dhcp-4.2.2rc1. I have started the dhcp relay with options > > dhcrelay -d -i eth0 -i eth1 serverip > > everything is working fine except that when client release the ip and send DHCPRELEASE packet on server side i get 3 packets for each DHCPRELEASE. > > One is directly sent to server ( which is valid packet) the other two are duplicate of this packet which is generated by relay agent with giaddr as address of eth0 and eth1 interface. > > Is this normal behavior? The same is observed with unicast DHCPREQUEST . Are you sure about the unicast packets ? On a switched network, the packet should only ever bee seen by the server - it shouldn't reach the relay agent. For any boradcast packets, I'd expect to see two copies - one picked up directly by the server, and one picked up by the relay agent. This is inherent in the way the relay agent needs (due to the way it's built) to listen on both interfaces. I wouldn't expect to see a packet with the relay's eth1 address in it - they aren't connected to the same network are they ? -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Client_DHCP_Relay.pcap Type: application/octet-stream Size: 3638 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Server_Dhcp_Relay.pcap Type: application/octet-stream Size: 5070 bytes Desc: not available URL: From arunprasad at pointred.co Wed Apr 18 11:05:05 2012 From: arunprasad at pointred.co (arunprasad) Date: Wed, 18 Apr 2012 16:35:05 +0530 Subject: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST In-Reply-To: <1334745988.54514.YahooMailClassic@web121301.mail.ne1.yahoo.com> References: <1334745988.54514.YahooMailClassic@web121301.mail.ne1.yahoo.com> Message-ID: <002101cd1d53$1f828170$5e878450$@pointred.co> Hi Sujitha, Try keeping DHCP-Server & DHCP-relay in different subnet. Regards Arun. From: dhcp-users-bounces+arunprasad=pointred.co at lists.isc.org [mailto:dhcp-users-bounces+arunprasad=pointred.co at lists.isc.org] On Behalf Of Sujata Verma Sent: Wednesday, April 18, 2012 4:16 PM To: Users of ISC DHCP Subject: Re: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST Thanks for reply. My setup is like this : eth1 Windows 2003 server ( 192.168.9.2/23)-------------------(192.168.8.177/23) Linux PC(Relay) (80.1.1.1/24----------eth0----Windows XP Client ( DHCP client getting IP 80.1.1.2/24) In windows server the default gw is 192.168.8.177. The DHCP pool configured gateway is 80.1.1.1 ( relay agent ip) I am attaching the wireshark capture for both client and server. In this we can see that the DHCPDISCOVER is only being sent once to the server which relay is forwarding while adding giaddr field as 80.1.1.1 . When DHCPRELEASE packet is being sent, it is sent directly to the server and with other two packets as duplicates with giaddr as of two interfaces. In linux pc i have only enabled ipv4_forward and disabled iptables completely. Is there any other configuration which can result in my observation like this ? Please let me know your observations, after seeing the captures. I have tried many times with similar observation. Regards, Sujata --- On Wed, 4/18/12, Simon Hobson wrote: From: Simon Hobson Subject: Re: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST To: "Users of ISC DHCP" Date: Wednesday, April 18, 2012, 2:38 PM Sujata Verma wrote: > I am using dhcp-4.2.2rc1. I have started the dhcp relay with options > > dhcrelay -d -i eth0 -i eth1 serverip > > everything is working fine except that when client release the ip and send DHCPRELEASE packet on server side i get 3 packets for each DHCPRELEASE. > > One is directly sent to server ( which is valid packet) the other two are duplicate of this packet which is generated by relay agent with giaddr as address of eth0 and eth1 interface. > > Is this normal behavior? The same is observed with unicast DHCPREQUEST . Are you sure about the unicast packets ? On a switched network, the packet should only ever bee seen by the server - it shouldn't reach the relay agent. For any boradcast packets, I'd expect to see two copies - one picked up directly by the server, and one picked up by the relay agent. This is inherent in the way the relay agent needs (due to the way it's built) to listen on both interfaces. I wouldn't expect to see a packet with the relay's eth1 address in it - they aren't connected to the same network are they ? -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users DISCLAIMER: The information contained in this message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and permanently delete this message and any attachments from your system. Any dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. PointRed Telecom Ltd (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system and does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interferences. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arunprasad at pointred.co Wed Apr 18 11:11:58 2012 From: arunprasad at pointred.co (arunprasad) Date: Wed, 18 Apr 2012 16:41:58 +0530 Subject: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST References: <1334745988.54514.YahooMailClassic@web121301.mail.ne1.yahoo.com> Message-ID: <002601cd1d54$16024bc0$4206e340$@pointred.co> If setup is connected in L2-Switch, use VLAN, ensure client broadcast messages should not hit directly to server. Regards Arun. From: arunprasad [mailto:arunprasad at pointred.co] Sent: Wednesday, April 18, 2012 4:35 PM To: 'Users of ISC DHCP' Subject: RE: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST Hi Sujitha, Try keeping DHCP-Server & DHCP-relay in different subnet. Regards Arun. From: dhcp-users-bounces+arunprasad=pointred.co at lists.isc.org [mailto:dhcp-users-bounces+arunprasad=pointred.co at lists.isc.org] On Behalf Of Sujata Verma Sent: Wednesday, April 18, 2012 4:16 PM To: Users of ISC DHCP Subject: Re: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST Thanks for reply. My setup is like this : eth1 Windows 2003 server ( 192.168.9.2/23)-------------------(192.168.8.177/23) Linux PC(Relay) (80.1.1.1/24----------eth0----Windows XP Client ( DHCP client getting IP 80.1.1.2/24) In windows server the default gw is 192.168.8.177. The DHCP pool configured gateway is 80.1.1.1 ( relay agent ip) I am attaching the wireshark capture for both client and server. In this we can see that the DHCPDISCOVER is only being sent once to the server which relay is forwarding while adding giaddr field as 80.1.1.1 . When DHCPRELEASE packet is being sent, it is sent directly to the server and with other two packets as duplicates with giaddr as of two interfaces. In linux pc i have only enabled ipv4_forward and disabled iptables completely. Is there any other configuration which can result in my observation like this ? Please let me know your observations, after seeing the captures. I have tried many times with similar observation. Regards, Sujata --- On Wed, 4/18/12, Simon Hobson wrote: From: Simon Hobson Subject: Re: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST To: "Users of ISC DHCP" Date: Wednesday, April 18, 2012, 2:38 PM Sujata Verma wrote: > I am using dhcp-4.2.2rc1. I have started the dhcp relay with options > > dhcrelay -d -i eth0 -i eth1 serverip > > everything is working fine except that when client release the ip and send DHCPRELEASE packet on server side i get 3 packets for each DHCPRELEASE. > > One is directly sent to server ( which is valid packet) the other two are duplicate of this packet which is generated by relay agent with giaddr as address of eth0 and eth1 interface. > > Is this normal behavior? The same is observed with unicast DHCPREQUEST . Are you sure about the unicast packets ? On a switched network, the packet should only ever bee seen by the server - it shouldn't reach the relay agent. For any boradcast packets, I'd expect to see two copies - one picked up directly by the server, and one picked up by the relay agent. This is inherent in the way the relay agent needs (due to the way it's built) to listen on both interfaces. I wouldn't expect to see a packet with the relay's eth1 address in it - they aren't connected to the same network are they ? -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users DISCLAIMER: The information contained in this message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and permanently delete this message and any attachments from your system. Any dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. PointRed Telecom Ltd (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system and does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interferences. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhcp1 at thehobsons.co.uk Wed Apr 18 11:51:06 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Wed, 18 Apr 2012 12:51:06 +0100 Subject: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST In-Reply-To: <1334745988.54514.YahooMailClassic@web121301.mail.ne1.yahoo.com> References: <1334745988.54514.YahooMailClassic@web121301.mail.ne1.yahoo.com> Message-ID: Sujata Verma wrote: >My setup is like this : > eth1 > Windows 2003 server ( >192.168.9.2/23)-------------------(192.168.8.177/23) Linux PC(Relay) >(80.1.1.1/24----------eth0----Windows XP Client ( DHCP client >getting IP 80.1.1.2/24) That's better >I am attaching the wireshark capture for both client and server. In >this we can see that the DHCPDISCOVER is only being sent once to the >server which relay is forwarding while adding giaddr field as >80.1.1.1 . > >When DHCPRELEASE packet is being sent, it is sent directly to the >server and with other two packets as duplicates with giaddr as of >two interfaces. My guess (I've not actually used the ISC relay) is that it's sniffing the packets and picking up the unicast packet from the client to the server both when it enters the relay on eth0 and when it exits via eth1. That, to my understanding, is wrong. It would be interesting to see what happens to a unicast DHCP-Request packet ? The Request packet in your captures is a broadcast packet which is being relayed by the Relay Agent (correctly). You will need to (temporarily) tweak your server config down to a short lease time so that the client will renew in a timescale that's workable. Based on the above, I suspect you'll see those packets duplicated as well. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From sujataverma3 at yahoo.com Wed Apr 18 13:05:48 2012 From: sujataverma3 at yahoo.com (Sujata Verma) Date: Wed, 18 Apr 2012 06:05:48 -0700 (PDT) Subject: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST In-Reply-To: Message-ID: <1334754348.73781.YahooMailClassic@web121301.mail.ne1.yahoo.com> Thanks for the reply. Yes, it is duplicating the unicast DHCPREQUEST packets as well. So is it a bug, is there anything i can do to stop doing it ( in code ) ,? any pointers? @Arun, There is no switch in between, the setup to be precise is Win Server-----------cross cable--------------Linux PC------------hub-------Win XP client 192.168.9.1/24?????? ?? ? 192.168.9.2/24??????????????? 10.1.1.2/8????????????? 10.1.1.3/8 ( from server) I changed the subnet as? above but same behavior. One more observation : if i disable ip_forward flag , the DHCP relay agent is sending only one DHCPRELEASE packet with correct giaddr ( incoming eth0 interface ). But as forwarding is disabled it is understood that the client DHCPRELEASE? message is not forwarded to the server but why the other "eth1" interface DHCPRELEASE message is not being generated from relay agent? Any pointers? Regards, Sujata --- On Wed, 4/18/12, Simon Hobson wrote: From: Simon Hobson Subject: Re: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST To: "Users of ISC DHCP" Date: Wednesday, April 18, 2012, 5:21 PM Sujata Verma wrote: > My setup is like this :? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? eth1 >???Windows 2003 server ( 192.168.9.2/23)-------------------(192.168.8.177/23) Linux PC(Relay) (80.1.1.1/24----------eth0----Windows XP Client ( DHCP client getting IP 80.1.1.2/24) That's better > I am attaching the wireshark capture for both client and server. In this we can see that the DHCPDISCOVER is only being sent once to the server which relay is forwarding while adding giaddr field as 80.1.1.1 . > > When DHCPRELEASE packet is being sent, it is sent directly to the server and with other two packets as duplicates with giaddr as of two interfaces. My guess (I've not actually used the ISC relay) is that it's sniffing the packets and picking up the unicast packet from the client to the server both when it enters the relay on eth0 and when it exits via eth1. That, to my understanding, is wrong. It would be interesting to see what happens to a unicast DHCP-Request packet ? The Request packet in your captures is a broadcast packet which is being relayed by the Relay Agent (correctly). You will need to (temporarily) tweak your server config down to a short lease time so that the client will renew in a timescale that's workable. Based on the above, I suspect you'll see those packets duplicated as well. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From ameen.shajahan at wipro.com Wed Apr 18 14:44:48 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Wed, 18 Apr 2012 14:44:48 +0000 Subject: ISC has support for DHCP IPv4 and IPv6 at a single time Message-ID: Hi all, I am using DHCP-4.2.3 for DHCPv4 and v6 support. But I can't able to run DHCPv4 or DHCPv6 at a single time. I would like to know whether ISC implementing this dual facility or they will provide in the future. If they already provided this dual facility means please let me know the package name. Please let me know. Thanks, Ameen S Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From oskar.berggren at gmail.com Wed Apr 18 14:49:25 2012 From: oskar.berggren at gmail.com (Oskar Berggren) Date: Wed, 18 Apr 2012 16:49:25 +0200 Subject: ISC has support for DHCP IPv4 and IPv6 at a single time In-Reply-To: References: Message-ID: The software can handle both protocols, however a running instance can only handle one protocol at a time. The defined solution to this is to run dhcpd twice, one instance for IPv4 and one instance for IPv6. You can do this on the same machine without problems. /Oskar Den 18 april 2012 16:44 skrev : > Hi all, > > I am using DHCP-4.2.3 for DHCPv4 and v6 support. > > But I can?t able to run DHCPv4 or DHCPv6 at a single time. > > I would like to know whether ISC implementing this dual facility or they > will provide in the future. > > If they already provided this dual facility means please let me know the > package name. > > Please let me know. > > > > > > Thanks, > > Ameen S > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any attachments to > this message are intended for the exclusive use of the addressee(s) and may > contain proprietary, confidential or privileged information. If you are not > the intended recipient, you should not disseminate, distribute or copy this > e-mail. Please notify the sender immediately and destroy all copies of this > message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient should > check this email and any attachments for the presence of viruses. The > company accepts no liability for any damage caused by any virus transmitted > by this email. > > www.wipro.com > > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users From ameen.shajahan at wipro.com Wed Apr 18 14:51:38 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Wed, 18 Apr 2012 14:51:38 +0000 Subject: Regarding DHCP-4.2.3-P2?? Message-ID: Hi all, Is ISC DHCP-4.2.3-P2 has dual support like running DHCPv4 and DHCPv6 at a time. Please let me know. Thanks, Ameen S Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From perl-list at network1.net Wed Apr 18 15:42:19 2012 From: perl-list at network1.net (perl-list) Date: Wed, 18 Apr 2012 11:42:19 -0400 (EDT) Subject: Regarding DHCP-4.2.3-P2?? In-Reply-To: Message-ID: <1cc6e6e6-14b8-4dc5-b2ac-68185d34689b@zimbra.network1.net> Someone already answered you. You run dhcpd twice - once for DHCPv4 and once for DHCPv6. ----- Original Message ----- > From: "ameen shajahan" > To: dhcp-users at lists.isc.org, dhcp-suggest at isc.org > Sent: Wednesday, April 18, 2012 10:51:38 AM > Subject: Regarding DHCP-4.2.3-P2?? > Hi all, > Is ISC DHCP-4.2.3-P2 has dual support like running DHCPv4 and DHCPv6 > at a time. > Please let me know. > Thanks, > Ameen S > Please do not print this email unless it is absolutely necessary. > The information contained in this electronic message and any > attachments to this message are intended for the exclusive use of > the addressee(s) and may contain proprietary, confidential or > privileged information. If you are not the intended recipient, you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately and destroy all copies of this message > and any attachments. > WARNING: Computer viruses can be transmitted via email. The recipient > should check this email and any attachments for the presence of > viruses. The company accepts no liability for any damage caused by > any virus transmitted by this email. > www.wipro.com > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From A.L.M.Buxey at lboro.ac.uk Wed Apr 18 16:14:46 2012 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Wed, 18 Apr 2012 17:14:46 +0100 Subject: Regarding DHCP-4.2.3-P2?? Message-ID: <3F842186-1D38-4166-8999-2039F567197F@lboro.ac.uk> Yes and its really easy to do, you can just duplicate your current sysinit script and then edit it to use different config file. ...I haven't done the same under systemd yet... alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From arunprasad at pointred.co Wed Apr 18 16:35:26 2012 From: arunprasad at pointred.co (arunprasad) Date: Wed, 18 Apr 2012 22:05:26 +0530 Subject: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST In-Reply-To: <1334754348.73781.YahooMailClassic@web121301.mail.ne1.yahoo.com> References: <1334754348.73781.YahooMailClassic@web121301.mail.ne1.yahoo.com> Message-ID: <001e01cd1d81$4c95ba00$e5c12e00$@pointred.co> Hi Sujata, dhcrelay -d -i eth0 -i eth1 serverip -i ifname Listen for DHCPv4/BOOTP queries on interface ifname. Multiple interfaces may be specified by using more than one -i option. If no interfaces are specified on the command line, dhcrelay will identify all network interfaces, eliminating non-broadcast interfaces if possible, and attempt to listen on all of them. So try running dhrelay on your downstream interface only i.e.. 80.1.1.1/24 interface. PS:- IP Forwarding needs to enable. If your setup is as below. Windows 2003 server ( 192.168.9.2/23)-------------------(192.168.8.177/23) Linux PC(Relay) (80.1.1.1/24----------eth0----Windows XP Client ( DHCP client getting IP 80.1.1.2/24) Regards Arun. From: dhcp-users-bounces+arunprasad=pointred.co at lists.isc.org [mailto:dhcp-users-bounces+arunprasad=pointred.co at lists.isc.org] On Behalf Of Sujata Verma Sent: Wednesday, April 18, 2012 6:36 PM To: Users of ISC DHCP Subject: Re: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST Thanks for the reply. Yes, it is duplicating the unicast DHCPREQUEST packets as well. So is it a bug, is there anything i can do to stop doing it ( in code ) , any pointers? @Arun, There is no switch in between, the setup to be precise is Win Server-----------cross cable--------------Linux PC------------hub-------Win XP client 192.168.9.1/24 192.168.9.2/24 10.1.1.2/8 10.1.1.3/8 ( from server) I changed the subnet as above but same behavior. One more observation : if i disable ip_forward flag , the DHCP relay agent is sending only one DHCPRELEASE packet with correct giaddr ( incoming eth0 interface ). But as forwarding is disabled it is understood that the client DHCPRELEASE message is not forwarded to the server but why the other "eth1" interface DHCPRELEASE message is not being generated from relay agent? Any pointers? Regards, Sujata --- On Wed, 4/18/12, Simon Hobson wrote: From: Simon Hobson Subject: Re: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST To: "Users of ISC DHCP" Date: Wednesday, April 18, 2012, 5:21 PM Sujata Verma wrote: > My setup is like this : eth1 > Windows 2003 server ( 192.168.9.2/23)-------------------(192.168.8.177/23) Linux PC(Relay) (80.1.1.1/24----------eth0----Windows XP Client ( DHCP client getting IP 80.1.1.2/24) That's better > I am attaching the wireshark capture for both client and server. In this we can see that the DHCPDISCOVER is only being sent once to the server which relay is forwarding while adding giaddr field as 80.1.1.1 . > > When DHCPRELEASE packet is being sent, it is sent directly to the server and with other two packets as duplicates with giaddr as of two interfaces. My guess (I've not actually used the ISC relay) is that it's sniffing the packets and picking up the unicast packet from the client to the server both when it enters the relay on eth0 and when it exits via eth1. That, to my understanding, is wrong. It would be interesting to see what happens to a unicast DHCP-Request packet ? The Request packet in your captures is a broadcast packet which is being relayed by the Relay Agent (correctly). You will need to (temporarily) tweak your server config down to a short lease time so that the client will renew in a timescale that's workable. Based on the above, I suspect you'll see those packets duplicated as well. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users DISCLAIMER: The information contained in this message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and permanently delete this message and any attachments from your system. Any dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. PointRed Telecom Ltd (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system and does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interferences. -------------- next part -------------- An HTML attachment was scrubbed... URL: From arunprasad at pointred.co Wed Apr 18 17:17:00 2012 From: arunprasad at pointred.co (arunprasad) Date: Wed, 18 Apr 2012 22:47:00 +0530 Subject: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST References: <1334754348.73781.YahooMailClassic@web121301.mail.ne1.yahoo.com> Message-ID: <002301cd1d87$259e6360$70db2a20$@pointred.co> Use this command:- dhcrelay -d -i eth0 192.168.9.2 ensure that from 80.1.1.1/24 your DHCP-Server is reachable (vice versa). Regards Arun. From: arunprasad [mailto:arunprasad at pointred.co] Sent: Wednesday, April 18, 2012 10:05 PM To: 'Users of ISC DHCP' Subject: RE: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST Hi Sujata, dhcrelay -d -i eth0 -i eth1 serverip -i ifname Listen for DHCPv4/BOOTP queries on interface ifname. Multiple interfaces may be specified by using more than one -i option. If no interfaces are specified on the command line, dhcrelay will identify all network interfaces, eliminating non-broadcast interfaces if possible, and attempt to listen on all of them. So try running dhrelay on your downstream interface only i.e.. 80.1.1.1/24 interface. PS:- IP Forwarding needs to enable. If your setup is as below. Windows 2003 server ( 192.168.9.2/23)-------------------(192.168.8.177/23) Linux PC(Relay) (80.1.1.1/24----------eth0----Windows XP Client ( DHCP client getting IP 80.1.1.2/24) Regards Arun. From: dhcp-users-bounces+arunprasad=pointred.co at lists.isc.org [mailto:dhcp-users-bounces+arunprasad=pointred.co at lists.isc.org] On Behalf Of Sujata Verma Sent: Wednesday, April 18, 2012 6:36 PM To: Users of ISC DHCP Subject: Re: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST Thanks for the reply. Yes, it is duplicating the unicast DHCPREQUEST packets as well. So is it a bug, is there anything i can do to stop doing it ( in code ) , any pointers? @Arun, There is no switch in between, the setup to be precise is Win Server-----------cross cable--------------Linux PC------------hub-------Win XP client 192.168.9.1/24 192.168.9.2/24 10.1.1.2/8 10.1.1.3/8 ( from server) I changed the subnet as above but same behavior. One more observation : if i disable ip_forward flag , the DHCP relay agent is sending only one DHCPRELEASE packet with correct giaddr ( incoming eth0 interface ). But as forwarding is disabled it is understood that the client DHCPRELEASE message is not forwarded to the server but why the other "eth1" interface DHCPRELEASE message is not being generated from relay agent? Any pointers? Regards, Sujata --- On Wed, 4/18/12, Simon Hobson wrote: From: Simon Hobson Subject: Re: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST To: "Users of ISC DHCP" Date: Wednesday, April 18, 2012, 5:21 PM Sujata Verma wrote: > My setup is like this : eth1 > Windows 2003 server ( 192.168.9.2/23)-------------------(192.168.8.177/23) Linux PC(Relay) (80.1.1.1/24----------eth0----Windows XP Client ( DHCP client getting IP 80.1.1.2/24) That's better > I am attaching the wireshark capture for both client and server. In this we can see that the DHCPDISCOVER is only being sent once to the server which relay is forwarding while adding giaddr field as 80.1.1.1 . > > When DHCPRELEASE packet is being sent, it is sent directly to the server and with other two packets as duplicates with giaddr as of two interfaces. My guess (I've not actually used the ISC relay) is that it's sniffing the packets and picking up the unicast packet from the client to the server both when it enters the relay on eth0 and when it exits via eth1. That, to my understanding, is wrong. It would be interesting to see what happens to a unicast DHCP-Request packet ? The Request packet in your captures is a broadcast packet which is being relayed by the Relay Agent (correctly). You will need to (temporarily) tweak your server config down to a short lease time so that the client will renew in a timescale that's workable. Based on the above, I suspect you'll see those packets duplicated as well. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users DISCLAIMER: The information contained in this message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and permanently delete this message and any attachments from your system. Any dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. PointRed Telecom Ltd (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system and does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interferences. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cathya at isc.org Wed Apr 18 17:43:18 2012 From: cathya at isc.org (Cathy Almond) Date: Wed, 18 Apr 2012 18:43:18 +0100 Subject: ISC has support for DHCP IPv4 and IPv6 at a single time In-Reply-To: References: Message-ID: <4F8EFD36.1070002@isc.org> On 18/04/12 15:44, ameen.shajahan at wipro.com wrote: > Hi all, > I am using DHCP-4.2.3 for DHCPv4 and v6 support. > But I can't able to run DHCPv4 or DHCPv6 at a single time. > I would like to know whether ISC implementing this dual facility or they will provide in the future. > If they already provided this dual facility means please let me know the package name. > Please let me know. I'm replying to this with the email address for creating new feature request tickets removed from the distribution - please can anyone else responding on the thread do the same. Many thanks. (Just one instance of the feature request is fine - the follow-on discusson on dhcp-users in support of it or otherwise discussing behaviour and workarounds, we can link to from our internal ticket :-) ) Cathy Almond ISC Support From cathya at isc.org Wed Apr 18 17:45:39 2012 From: cathya at isc.org (Cathy Almond) Date: Wed, 18 Apr 2012 18:45:39 +0100 Subject: Regarding DHCP-4.2.3-P2?? In-Reply-To: <3F842186-1D38-4166-8999-2039F567197F@lboro.ac.uk> References: <3F842186-1D38-4166-8999-2039F567197F@lboro.ac.uk> Message-ID: <4F8EFDC3.20504@isc.org> On 18/04/12 17:14, Alan Buxey wrote: > Yes and its really easy to do, you can just duplicate your current sysinit script and then edit it to use different config file. > > ...I haven't done the same under systemd yet... > > alan > > > > > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users (Repeating as on the similar/other thread): I'm replying to this with the email address for creating new feature request tickets removed from the distribution - please can anyone else responding make sure they've done the same - if replying to an older post directly. Many thanks. (Just one instance of the feature request is fine - the follow-on discusson on dhcp-users in support of it or otherwise discussing behaviour and workarounds, we can link to from our internal ticket :-) ) Cathy Almond ISC Support From dhcp1 at thehobsons.co.uk Wed Apr 18 14:08:33 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Wed, 18 Apr 2012 15:08:33 +0100 Subject: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST In-Reply-To: <1334754348.73781.YahooMailClassic@web121301.mail.ne1.yahoo.com> References: <1334754348.73781.YahooMailClassic@web121301.mail.ne1.yahoo.com> Message-ID: Sujata Verma wrote: >Yes, it is duplicating the unicast DHCPREQUEST packets as well. > >So is it a bug, is there anything i can do to stop doing it ( in >code ) , any pointers? Sounds like a bug. I'm not a coder so I can't comment of what might be required to fix it. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From ameen.shajahan at wipro.com Thu Apr 19 05:53:39 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Thu, 19 Apr 2012 05:53:39 +0000 Subject: Regarding DHCP-4.2.3-P2?? In-Reply-To: <4F8EFDC3.20504@isc.org> References: <3F842186-1D38-4166-8999-2039F567197F@lboro.ac.uk> <4F8EFDC3.20504@isc.org> Message-ID: Hi all, I have downloaded and checked the dual support like dhcpv4 and dhcpv6 at a time. No its not allowing to run both the modes(ipv4 and ipv6) at a time. Also I read in RELEASE notes and they have mentioned like (The client and server can only operate DHCPv4 or DHCPv6 at a time, not both. To use both protocols simultaneously, two instances of the relevant daemon are required, one with the '-6' command line option.) Is there any way to support DHCPv4 and DHCPv6 at a time using a single executable. I would like to know can we expect this dual support facility in near future in ISC code. Please let me know. Thanks, Ameen S -----Original Message----- From: dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org [mailto:dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org] On Behalf Of Cathy Almond Sent: 18 April 2012 23:16 To: dhcp-users at lists.isc.org Subject: Re: Regarding DHCP-4.2.3-P2?? On 18/04/12 17:14, Alan Buxey wrote: > Yes and its really easy to do, you can just duplicate your current sysinit script and then edit it to use different config file. > > ...I haven't done the same under systemd yet... > > alan > > > > > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users (Repeating as on the similar/other thread): I'm replying to this with the email address for creating new feature request tickets removed from the distribution - please can anyone else responding make sure they've done the same - if replying to an older post directly. Many thanks. (Just one instance of the feature request is fine - the follow-on discusson on dhcp-users in support of it or otherwise discussing behaviour and workarounds, we can link to from our internal ticket :-) ) Cathy Almond ISC Support _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com From vogt at spamcop.net Thu Apr 19 06:20:20 2012 From: vogt at spamcop.net (Gerald Vogt) Date: Thu, 19 Apr 2012 08:20:20 +0200 Subject: Regarding DHCP-4.2.3-P2?? In-Reply-To: References: <3F842186-1D38-4166-8999-2039F567197F@lboro.ac.uk> <4F8EFDC3.20504@isc.org> Message-ID: <4F8FAEA4.4060609@spamcop.net> On 19.04.12 07:53, ameen.shajahan at wipro.com wrote: > Hi all, > I have downloaded and checked the dual support like dhcpv4 and dhcpv6 at a time. > No its not allowing to run both the modes(ipv4 and ipv6) at a time. > Also I read in RELEASE notes and they have mentioned like (The client and server can only operate DHCPv4 or DHCPv6 at a time, not both. To use both protocols simultaneously, two instances of the relevant daemon are required, one with the '-6' command line option.) > > Is there any way to support DHCPv4 and DHCPv6 at a time using a single executable. What is the problem with running two instances at the same time, one for DHCPv4 and one for DHCPv6? Why do you think you absolutely need a single instance providing both DHCPv4 and DHCPv6? Gerald From ameen.shajahan at wipro.com Thu Apr 19 06:35:03 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Thu, 19 Apr 2012 06:35:03 +0000 Subject: Regarding DHCP-4.2.3-P2?? In-Reply-To: <4F8FAEA4.4060609@spamcop.net> References: <3F842186-1D38-4166-8999-2039F567197F@lboro.ac.uk> <4F8EFDC3.20504@isc.org> <4F8FAEA4.4060609@spamcop.net> Message-ID: We can't run two instance at a single time. We have only one executable dhcpd. Is there any way to run two instances at a time. If I give ./dhcpd -d -4 -6 eth0 (it throw a message called Server cannot run in both IPv4 and IPv6 mode at the same time.) Please let me know. Thanks, Ameen S -----Original Message----- From: dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org [mailto:dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org] On Behalf Of Gerald Vogt Sent: 19 April 2012 11:50 To: dhcp-users at lists.isc.org Subject: Re: Regarding DHCP-4.2.3-P2?? On 19.04.12 07:53, ameen.shajahan at wipro.com wrote: > Hi all, > I have downloaded and checked the dual support like dhcpv4 and dhcpv6 at a time. > No its not allowing to run both the modes(ipv4 and ipv6) at a time. > Also I read in RELEASE notes and they have mentioned like (The client and server can only operate DHCPv4 or DHCPv6 at a time, not both. To use both protocols simultaneously, two instances of the relevant daemon are required, one with the '-6' command line option.) > > Is there any way to support DHCPv4 and DHCPv6 at a time using a single executable. What is the problem with running two instances at the same time, one for DHCPv4 and one for DHCPv6? Why do you think you absolutely need a single instance providing both DHCPv4 and DHCPv6? Gerald _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com From brock.brad at gmail.com Thu Apr 19 06:40:44 2012 From: brock.brad at gmail.com (brad brock) Date: Thu, 19 Apr 2012 13:40:44 +0700 Subject: Regarding DHCP-4.2.3-P2?? In-Reply-To: References: <3F842186-1D38-4166-8999-2039F567197F@lboro.ac.uk> <4F8EFDC3.20504@isc.org> <4F8FAEA4.4060609@spamcop.net> Message-ID: On Apr 19, 2012 1:35 PM, wrote: > > We can't run two instance at a single time. > We have only one executable dhcpd. > Is there any way to run two instances at a time. > > If I give ./dhcpd -d -4 -6 eth0 (it throw a message called Server cannot run in both IPv4 and IPv6 mode at the same time.) > > Please let me know. > > Thanks, > Ameen S > An executable file can be executed twice. It means two instances. Just run dhcpd twice with different options or configuration. Regard, Brad Brock -------------- next part -------------- An HTML attachment was scrubbed... URL: From oskar.berggren at gmail.com Thu Apr 19 06:40:23 2012 From: oskar.berggren at gmail.com (Oskar Berggren) Date: Thu, 19 Apr 2012 08:40:23 +0200 Subject: Regarding DHCP-4.2.3-P2?? In-Reply-To: References: <3F842186-1D38-4166-8999-2039F567197F@lboro.ac.uk> <4F8EFDC3.20504@isc.org> <4F8FAEA4.4060609@spamcop.net> Message-ID: Den 19 april 2012 08:35 skrev : > We can't run two instance at a single time. > We have only one executable dhcpd. > Is there any way to run two instances at a time. I really don't understand the weird assumptions you seem to make here? What makes you say you cannot run the same binary twice? Hundreds (thousands) of installations already do so. $ ./dhcpd -d -4 eth0 $ ./dhcpd -d -6 eth0 There, now you have two running processes. If you by some weird system setup cannot execute the same binary twice, how about: $ cp dhcpd dhcpd4 $ mv dhcpd dhcpd6 $ dhcpd6 -d -6 eth0 $ dhcpd4 -d -4 eth0 /Oskar From vogt at spamcop.net Thu Apr 19 06:42:28 2012 From: vogt at spamcop.net (Gerald Vogt) Date: Thu, 19 Apr 2012 08:42:28 +0200 Subject: Regarding DHCP-4.2.3-P2?? In-Reply-To: References: <3F842186-1D38-4166-8999-2039F567197F@lboro.ac.uk> <4F8EFDC3.20504@isc.org> <4F8FAEA4.4060609@spamcop.net> Message-ID: <4F8FB3D4.5000301@spamcop.net> On 19.04.12 08:35, ameen.shajahan at wipro.com wrote: > We can't run two instance at a single time. > We have only one executable dhcpd. > Is there any way to run two instances at a time. > > If I give ./dhcpd -d -4 -6 eth0 (it throw a message called Server cannot run in both IPv4 and IPv6 mode at the same time.) You can run the dhcpd binary twice. One instance for DHCPv4 and one for DHCPv6. You create two different config files. The first contains the configuration for DHCPv4 and the second contains the configuration for DHCPv6. For example, you call the first one /etc/dhcpd.conf and the second one dhcp6d.conf. Then you run dhcpd twice: # dhcpd -4 -cf /etc/dhcpd.conf # dhcpd -6 -cf /etc/dhcp6d.conf Now you have two instances of dhcpd running: one is serving dhcpv4 leases and one is serving dhcpv6 leases. Regards, Gerald From sujataverma3 at yahoo.com Thu Apr 19 08:01:30 2012 From: sujataverma3 at yahoo.com (Sujata Verma) Date: Thu, 19 Apr 2012 01:01:30 -0700 (PDT) Subject: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST In-Reply-To: Message-ID: <1334822490.55888.YahooMailClassic@web121304.mail.ne1.yahoo.com> Thanks. I have submitted the bug report to ISC and it has been assigned this no: ISC-Bugs #29053 I hope somebody will look into it. Thanks you very much for your help. Regards, Sujata --- On Wed, 4/18/12, Simon Hobson wrote: From: Simon Hobson Subject: Re: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST To: "Users of ISC DHCP" Date: Wednesday, April 18, 2012, 7:38 PM Sujata Verma wrote: > Yes, it is duplicating the unicast DHCPREQUEST packets as well. > > So is it a bug, is there anything i can do to stop doing it ( in code ) ,? any pointers? Sounds like a bug. I'm not a coder so I can't comment of what might be required to fix it. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From sujataverma3 at yahoo.com Thu Apr 19 08:05:28 2012 From: sujataverma3 at yahoo.com (Sujata Verma) Date: Thu, 19 Apr 2012 01:05:28 -0700 (PDT) Subject: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST In-Reply-To: <002301cd1d87$259e6360$70db2a20$@pointred.co> Message-ID: <1334822728.87683.YahooMailClassic@web121302.mail.ne1.yahoo.com> Thanks for your reply . We cannot run the command giving only one interface , either it has to be all or none. So it can be like dhcrelay ?d 192.168.9.2 or dhcrelay ?d ?i eth0 -i eth1 192.168.9.2 If we give only one interface it will silently discard the packet. I have tested it. Please see below bug for more information. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648401 Regards, Sujata --- On Wed, 4/18/12, arunprasad wrote: From: arunprasad Subject: RE: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST To: "'Users of ISC DHCP'" Date: Wednesday, April 18, 2012, 10:47 PM Use this command:- ?dhcrelay ?d ?i eth0 192.168.9.2 ?ensure that from 80.1.1.1/24 your DHCP-Server is reachable (vice versa). ?RegardsArun. ? ?From: arunprasad [mailto:arunprasad at pointred.co] Sent: Wednesday, April 18, 2012 10:05 PM To: 'Users of ISC DHCP' Subject: RE: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST ?Hi Sujata, ?dhcrelay -d -i eth0 -i eth1 serverip ?-i ifname Listen for DHCPv4/BOOTP queries on interface ifname. Multiple interfaces may be specified by using more than one -i option. If no interfaces are specified on the command line, dhcrelay will identify all network interfaces, eliminating non-broadcast interfaces if possible, and attempt to listen on all of them. ?So try running dhrelay on your downstream interface only i.e.. 80.1.1.1/24 interface. ?PS:- IP Forwarding needs to enable. If your setup is as below. ?Windows 2003 server ( 192.168.9.2/23)-------------------(192.168.8.177/23) Linux PC(Relay) (80.1.1.1/24----------eth0----Windows XP Client ( DHCP client getting IP 80.1.1.2/24) ?RegardsArun. ? ? ? ?From: dhcp-users-bounces+arunprasad=pointred.co at lists.isc.org [mailto:dhcp-users-bounces+arunprasad=pointred.co at lists.isc.org] On Behalf Of Sujata Verma Sent: Wednesday, April 18, 2012 6:36 PM To: Users of ISC DHCP Subject: Re: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST ? Thanks for the reply. Yes, it is duplicating the unicast DHCPREQUEST packets as well. So is it a bug, is there anything i can do to stop doing it ( in code ) ,? any pointers? @Arun, There is no switch in between, the setup to be precise is Win Server-----------cross cable--------------Linux PC------------hub-------Win XP client 192.168.9.1/24?????? ?? ? 192.168.9.2/24??????????????? 10.1.1.2/8????????????? 10.1.1.3/8 ( from server) I changed the subnet as? above but same behavior. One more observation : if i disable ip_forward flag , the DHCP relay agent is sending only one DHCPRELEASE packet with correct giaddr ( incoming eth0 interface ). But as forwarding is disabled it is understood that the client DHCPRELEASE? message is not forwarded to the server but why the other "eth1" interface DHCPRELEASE message is not being generated from relay agent? Any pointers? Regards, Sujata --- On Wed, 4/18/12, Simon Hobson wrote: From: Simon Hobson Subject: Re: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST To: "Users of ISC DHCP" Date: Wednesday, April 18, 2012, 5:21 PMSujata Verma wrote: > My setup is like this :? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? eth1 >???Windows 2003 server ( 192.168.9.2/23)-------------------(192.168.8.177/23) Linux PC(Relay) (80.1.1.1/24----------eth0----Windows XP Client ( DHCP client getting IP 80.1.1.2/24) That's better > I am attaching the wireshark capture for both client and server. In this we can see that the DHCPDISCOVER is only being sent once to the server which relay is forwarding while adding giaddr field as 80.1.1.1 . > > When DHCPRELEASE packet is being sent, it is sent directly to the server and with other two packets as duplicates with giaddr as of two interfaces. My guess (I've not actually used the ISC relay) is that it's sniffing the packets and picking up the unicast packet from the client to the server both when it enters the relay on eth0 and when it exits via eth1. That, to my understanding, is wrong. It would be interesting to see what happens to a unicast DHCP-Request packet ? The Request packet in your captures is a broadcast packet which is being relayed by the Relay Agent (correctly). You will need to (temporarily) tweak your server config down to a short lease time so that the client will renew in a timescale that's workable. Based on the above, I suspect you'll see those packets duplicated as well. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users ? DISCLAIMER: The information contained in this message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and permanently delete this message and any attachments from your system. Any dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. PointRed Telecom Ltd (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system and does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interferences. -----Inline Attachment Follows----- _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From arunprasad at pointred.co Thu Apr 19 08:30:57 2012 From: arunprasad at pointred.co (arunprasad) Date: Thu, 19 Apr 2012 14:00:57 +0530 Subject: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST In-Reply-To: <1334822728.87683.YahooMailClassic@web121302.mail.ne1.yahoo.com> References: <002301cd1d87$259e6360$70db2a20$@pointred.co> <1334822728.87683.YahooMailClassic@web121302.mail.ne1.yahoo.com> Message-ID: <002501cd1e06$c1ce9230$456bb690$@pointred.co> Hi Sujata, Thanks for the clarification. Regards Arun. From: dhcp-users-bounces+arunprasad=pointred.co at lists.isc.org [mailto:dhcp-users-bounces+arunprasad=pointred.co at lists.isc.org] On Behalf Of Sujata Verma Sent: Thursday, April 19, 2012 1:35 PM To: Users of ISC DHCP Subject: RE: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST Thanks for your reply . We cannot run the command giving only one interface , either it has to be all or none. So it can be like dhcrelay ?d 192.168.9.2 or dhcrelay ?d ?i eth0 -i eth1 192.168.9.2 If we give only one interface it will silently discard the packet. I have tested it. Please see below bug for more information. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648401 Regards, Sujata --- On Wed, 4/18/12, arunprasad wrote: From: arunprasad Subject: RE: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST To: "'Users of ISC DHCP'" Date: Wednesday, April 18, 2012, 10:47 PM Use this command:- dhcrelay ?d ?i eth0 192.168.9.2 ensure that from 80.1.1.1/24 your DHCP-Server is reachable (vice versa). Regards Arun. From: arunprasad [mailto:arunprasad at pointred.co] Sent: Wednesday, April 18, 2012 10:05 PM To: 'Users of ISC DHCP' Subject: RE: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST Hi Sujata, dhcrelay -d -i eth0 -i eth1 serverip -i ifname Listen for DHCPv4/BOOTP queries on interface ifname. Multiple interfaces may be specified by using more than one -i option. If no interfaces are specified on the command line, dhcrelay will identify all network interfaces, eliminating non-broadcast interfaces if possible, and attempt to listen on all of them. So try running dhrelay on your downstream interface only i.e.. 80.1.1.1/24 interface. PS:- IP Forwarding needs to enable. If your setup is as below. Windows 2003 server ( 192.168.9.2/23)-------------------(192.168.8.177/23) Linux PC(Relay) (80.1.1.1/24----------eth0----Windows XP Client ( DHCP client getting IP 80.1.1.2/24) Regards Arun. From: dhcp-users-bounces+arunprasad=pointred.co at lists.isc.org [mailto:dhcp-users-bounces+arunprasad=pointred.co at lists.isc.org] On Behalf Of Sujata Verma Sent: Wednesday, April 18, 2012 6:36 PM To: Users of ISC DHCP Subject: Re: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST Thanks for the reply. Yes, it is duplicating the unicast DHCPREQUEST packets as well. So is it a bug, is there anything i can do to stop doing it ( in code ) , any pointers? @Arun, There is no switch in between, the setup to be precise is Win Server-----------cross cable--------------Linux PC------------hub-------Win XP client 192.168.9.1/24 192.168.9.2/24 10.1.1.2/8 10.1.1.3/8 ( from server) I changed the subnet as above but same behavior. One more observation : if i disable ip_forward flag , the DHCP relay agent is sending only one DHCPRELEASE packet with correct giaddr ( incoming eth0 interface ). But as forwarding is disabled it is understood that the client DHCPRELEASE message is not forwarded to the server but why the other "eth1" interface DHCPRELEASE message is not being generated from relay agent? Any pointers? Regards, Sujata --- On Wed, 4/18/12, Simon Hobson wrote: From: Simon Hobson Subject: Re: DHCP Relay: Duplicate packets for DHCPRELEASE and DHCPREQUEST To: "Users of ISC DHCP" Date: Wednesday, April 18, 2012, 5:21 PM Sujata Verma wrote: > My setup is like this : eth1 > Windows 2003 server ( 192.168.9.2/23)-------------------(192.168.8.177/23) Linux PC(Relay) (80.1.1.1/24----------eth0----Windows XP Client ( DHCP client getting IP 80.1.1.2/24) That's better > I am attaching the wireshark capture for both client and server. In this we can see that the DHCPDISCOVER is only being sent once to the server which relay is forwarding while adding giaddr field as 80.1.1.1 . > > When DHCPRELEASE packet is being sent, it is sent directly to the server and with other two packets as duplicates with giaddr as of two interfaces. My guess (I've not actually used the ISC relay) is that it's sniffing the packets and picking up the unicast packet from the client to the server both when it enters the relay on eth0 and when it exits via eth1. That, to my understanding, is wrong. It would be interesting to see what happens to a unicast DHCP-Request packet ? The Request packet in your captures is a broadcast packet which is being relayed by the Relay Agent (correctly). You will need to (temporarily) tweak your server config down to a short lease time so that the client will renew in a timescale that's workable. Based on the above, I suspect you'll see those packets duplicated as well. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users DISCLAIMER: The information contained in this message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and permanently delete this message and any attachments from your system. Any dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. PointRed Telecom Ltd (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system and does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interferences. -----Inline Attachment Follows----- _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users DISCLAIMER: The information contained in this message (including any attachments) is confidential and may be privileged. If you have received it by mistake please notify the sender by return e-mail and permanently delete this message and any attachments from your system. Any dissemination, use, review, distribution, printing or copying of this message in whole or in part is strictly prohibited. Please note that e-mails are susceptible to change. PointRed Telecom Ltd (including its group companies) shall not be liable for the improper or incomplete transmission of the information contained in this communication nor for any delay in its receipt or damage to your system and does not guarantee that the integrity of this communication has been maintained or that this communication is free of viruses, interceptions or interferences. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.meredith at port.ac.uk Thu Apr 19 14:29:26 2012 From: mike.meredith at port.ac.uk (Mike Meredith) Date: Thu, 19 Apr 2012 15:29:26 +0100 Subject: Crash! With DHCP 4.2.3-P2 Message-ID: <20120419152926.4b7c7ce3@port.ac.uk> Hi! On a dhcp server I run, we have been getting very occasional crashes (segmentation faults - reported in the system log with "XXX"). These occur many days appart on a moderately busy network (18000 leases and about 20,000-90,000 DHCPDISCOVERs per day). Environment:- ISC DHCPD 4.2.3-P2 (self compiled) SLES 11SP1 on x86_64 Crash trace :- (gdb) bt #0 dns_client_cancelupdate (trans=0xdededededededede) at ../../../lib/dns/client.c:2808 #1 0x00000000004499dd in ddns_cancel (ddns_cb=0x1cac1f0) at dns.c:1744 #2 0x00000000004311ff in ddns_updates (packet=0x1c85ed0, lease=0x7f7d771b4a40, old=0x7f7d774b9d28, lease6=0x0, old6=0x0, options=0x1cae290) at ddns.c:106 #3 0x0000000000409cf0 in ack_lease (packet=0x1c85ed0, lease=0x7f7d774b9d28, offer=5, when=0, msg=0x7ffffc7c1fe0 "DHCPREQUEST for 148.197.107.122 from d0:27:88:XX:XX:XX (XXXXXXXX) via 148.197.107.254", ms_nulltp=0, hp=0x0) at dhcp.c:2438 #4 0x000000000040df0b in dhcprequest (packet=0x1c85ed0, ms_nulltp=0, ip_lease=) at dhcp.c:676 #5 0x000000000040eb6f in dhcp (packet=0x1c85ed0) at dhcp.c:229 #6 0x0000000000457755 in do_packet (interface=0x86af50, packet=0x7ffffc7c2590, len=326, from_port=17152, from=..., hfrom=0x7ffffc7c3630) at options.c:3759 #7 0x00000000004477b2 in got_one (h=0x86af50) at discover.c:1441 #8 0x0000000000472e6c in omapi_iscsock_cb (task=, socket=, cbarg=0xf8c8f0, flags=1) at dispatch.c:174 #9 0x00000000005491e8 in internal_fdwatch_read (me=0x7f7d7a6fb010, ev=0x7f7d7a7014d8) at ../../../../lib/isc/unix/socket.c:3442 #10 0x000000000054d15b in dispatch (manager=) at ../../../lib/isc/task.c:1012 #11 isc__taskmgr_dispatch (manager0=) at ../../../lib/isc/task.c:1436 #12 0x000000000053c8bf in evloop (ctx=0x7f7d7a6f4010) at ../../../../lib/isc/unix/app.c:497 #13 0x000000000053caf7 in isc__app_ctxrun (ctx0=) at ../../../../lib/isc/unix/app.c:696 #14 0x00000000004498f0 in dispatch () at dispatch.c:113 #15 0x0000000000404ef7 in main (argc=7, argv=0x7ffffc7c3998) at dhcpd.c:863 From what I read, there's a new maintenance release of dhcp due sometime soon, and it appears it may be sorting out stuff in this area. Can I ask if this crash looks as if it may be caused by known issues in this area ? -- Mike Meredith, University of Portsmouth Principle Systems Engineer, Hostmaster, Postmaster and Security -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From cathya at isc.org Fri Apr 20 07:08:41 2012 From: cathya at isc.org (Cathy Almond) Date: Fri, 20 Apr 2012 08:08:41 +0100 Subject: Crash! With DHCP 4.2.3-P2 In-Reply-To: <20120419152926.4b7c7ce3@port.ac.uk> References: <20120419152926.4b7c7ce3@port.ac.uk> Message-ID: <4F910B79.1090901@isc.org> On 19/04/12 15:29, Mike Meredith wrote: > Hi! > > On a dhcp server I run, we have been getting very occasional crashes > (segmentation faults - reported in the system log with "XXX"). These > occur many days appart on a moderately busy network (18000 leases and > about 20,000-90,000 DHCPDISCOVERs per day). > > Environment:- > > ISC DHCPD 4.2.3-P2 (self compiled) > SLES 11SP1 on x86_64 > > Crash trace :- > > (gdb) bt > #0 dns_client_cancelupdate (trans=0xdededededededede) at ../../../lib/dns/client.c:2808 > #1 0x00000000004499dd in ddns_cancel (ddns_cb=0x1cac1f0) at dns.c:1744 > #2 0x00000000004311ff in ddns_updates (packet=0x1c85ed0, lease=0x7f7d771b4a40, old=0x7f7d774b9d28, lease6=0x0, old6=0x0, options=0x1cae290) at ddns.c:106 > #3 0x0000000000409cf0 in ack_lease (packet=0x1c85ed0, lease=0x7f7d774b9d28, offer=5, when=0, > msg=0x7ffffc7c1fe0 "DHCPREQUEST for 148.197.107.122 from d0:27:88:XX:XX:XX (XXXXXXXX) via 148.197.107.254", ms_nulltp=0, hp=0x0) at dhcp.c:2438 > #4 0x000000000040df0b in dhcprequest (packet=0x1c85ed0, ms_nulltp=0, ip_lease=) at dhcp.c:676 > #5 0x000000000040eb6f in dhcp (packet=0x1c85ed0) at dhcp.c:229 > #6 0x0000000000457755 in do_packet (interface=0x86af50, packet=0x7ffffc7c2590, len=326, from_port=17152, from=..., hfrom=0x7ffffc7c3630) at options.c:3759 > #7 0x00000000004477b2 in got_one (h=0x86af50) at discover.c:1441 > #8 0x0000000000472e6c in omapi_iscsock_cb (task=, socket=, cbarg=0xf8c8f0, flags=1) at dispatch.c:174 > #9 0x00000000005491e8 in internal_fdwatch_read (me=0x7f7d7a6fb010, ev=0x7f7d7a7014d8) at ../../../../lib/isc/unix/socket.c:3442 > #10 0x000000000054d15b in dispatch (manager=) at ../../../lib/isc/task.c:1012 > #11 isc__taskmgr_dispatch (manager0=) at ../../../lib/isc/task.c:1436 > #12 0x000000000053c8bf in evloop (ctx=0x7f7d7a6f4010) at ../../../../lib/isc/unix/app.c:497 > #13 0x000000000053caf7 in isc__app_ctxrun (ctx0=) at ../../../../lib/isc/unix/app.c:696 > #14 0x00000000004498f0 in dispatch () at dispatch.c:113 > #15 0x0000000000404ef7 in main (argc=7, argv=0x7ffffc7c3998) at dhcpd.c:863 > > > From what I read, there's a new maintenance release of dhcp due sometime > soon, and it appears it may be sorting out stuff in this area. > > Can I ask if this crash looks as if it may be caused by known issues in > this area ? Yes it does. 4.2.4b1 is currently available on our website. We're anticipating that the production release will be early/mid May. Cathy From lsching17 at gmail.com Fri Apr 20 23:50:05 2012 From: lsching17 at gmail.com (ching) Date: Sat, 21 Apr 2012 07:50:05 +0800 Subject: enquiry on validation of dhcp offered address Message-ID: <4F91F62D.1080808@gmail.com> Hi all, Does anyone knows how to validate an address offered by dhcp server? e.g. i want dhclient to reject if offered address is in 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 or offered IPv6 prefix is in fc::00/7 Thanks ching From dhcp1 at thehobsons.co.uk Sat Apr 21 08:12:18 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Sat, 21 Apr 2012 09:12:18 +0100 Subject: enquiry on validation of dhcp offered address In-Reply-To: <4F91F62D.1080808@gmail.com> References: <4F91F62D.1080808@gmail.com> Message-ID: ching wrote: >Does anyone knows how to validate an address offered by dhcp server? > >e.g. i want dhclient to reject if offered address is in 10.0.0.0/8, >172.16.0.0/12, 192.168.0.0/16 > or offered IPv6 >prefix is in fc::00/7 Why ? I can see why you might want to reject accepting a non-routable address, but surely it's the job of the DHCP server (and the admin that configured it) to configure the network, not the client to second guess what it's connected to ? -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From lsching17 at gmail.com Sat Apr 21 13:01:53 2012 From: lsching17 at gmail.com (ching) Date: Sat, 21 Apr 2012 21:01:53 +0800 Subject: dhcp-users Digest, Vol 42, Issue 29 In-Reply-To: References: Message-ID: <4F92AFC1.6050106@gmail.com> i am trying to tune a general purpose router (OpenWRT), which provide WAN access to VLANs. In the point of view of a router, ISP's DHCP server cannot be full-trusted. If those servers get compromised, they may assign some non-routable IP to the WAN interface, and my route table may be "polluted" by those IPs. >> Does anyone knows how to validate an address offered by dhcp server? >> >> e.g. i want dhclient to reject if offered address is in 10.0.0.0/8, >> 172.16.0.0/12, 192.168.0.0/16 >> or offered IPv6 >> prefix is in fc::00/7 > Why ? > I can see why you might want to reject accepting a non-routable > address, but surely it's the job of the DHCP server (and the admin > that configured it) to configure the network, not the client to > second guess what it's connected to ? > From sthaug at nethelp.no Sat Apr 21 13:42:04 2012 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sat, 21 Apr 2012 15:42:04 +0200 (CEST) Subject: dhcp-users Digest, Vol 42, Issue 29 In-Reply-To: <4F92AFC1.6050106@gmail.com> References: <4F92AFC1.6050106@gmail.com> Message-ID: <20120421.154204.74738791.sthaug@nethelp.no> > i am trying to tune a general purpose router (OpenWRT), which provide > WAN access to VLANs. > > In the point of view of a router, ISP's DHCP server cannot be full-trusted. > > If those servers get compromised, they may assign some non-routable IP > to the WAN interface, and my route table may be "polluted" by those IPs. If you don't trust the server you shouldn't run a DHCP service on the server. DHCPv4 is by nature a service which depends on the DHCP server and the router (usually DHCP relay agent) trusting each other. DHCPv6 is slightly different in that the DHCP server cannot assign a default gateway, it has to come from RA. However, it is still the case that a compromised server can do a lot of damage. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From dhcp1 at thehobsons.co.uk Sat Apr 21 18:41:15 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Sat, 21 Apr 2012 19:41:15 +0100 Subject: enquiry on validation of dhcp offered address In-Reply-To: <4F92AFC1.6050106@gmail.com> References: <4F92AFC1.6050106@gmail.com> Message-ID: Subject corrected ... ching wrote: >i am trying to tune a general purpose router (OpenWRT), which >provide WAN access to VLANs. > >In the point of view of a router, ISP's DHCP server cannot be full-trusted. > >If those servers get compromised, they may assign some non-routable >IP to the WAN interface, and my route table may be "polluted" by >those IPs. I'll put this as delicately as I can. If you don't trust your ISP, then the address you get is the least of your worries. If someone is going to compromise the ISPs DHCP servers, they'd be more likely to keep the IPs correct and redirect your DNS or something like that. If they give you a non-routable address then the ISP would soon have it's helpdesk swamped by a deluge of calls and it would be spotted. So anyone with enough intelligence to actually do anything to worry about would not do that - they'd do their best to make your connection appear to work normally while doing something else (such as redirecting DNS so they can do man in the middle attacks on your traffic). Such things would not be easily detectable from your end. So, if you have that little trust in your ISP - you need to find a different ISP. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From lsching17 at gmail.com Sun Apr 22 00:55:43 2012 From: lsching17 at gmail.com (ching) Date: Sun, 22 Apr 2012 08:55:43 +0800 Subject: dhcp-users Digest, Vol 42, Issue 29 In-Reply-To: <20120421.154204.74738791.sthaug@nethelp.no> References: <4F92AFC1.6050106@gmail.com> <20120421.154204.74738791.sthaug@nethelp.no> Message-ID: <4F93570F.9030306@gmail.com> if dhclient can fully trust dhcp server, this kind of report should not exists. http://www.kb.cert.org/vuls/id/107886 On Saturday, April 21, 2012 09:42 PM, sthaug at nethelp.no wrote: >> i am trying to tune a general purpose router (OpenWRT), which provide >> WAN access to VLANs. >> >> In the point of view of a router, ISP's DHCP server cannot be full-trusted. >> >> If those servers get compromised, they may assign some non-routable IP >> to the WAN interface, and my route table may be "polluted" by those IPs. > If you don't trust the server you shouldn't run a DHCP service on the > server. > > DHCPv4 is by nature a service which depends on the DHCP server and > the router (usually DHCP relay agent) trusting each other. DHCPv6 is > slightly different in that the DHCP server cannot assign a default > gateway, it has to come from RA. However, it is still the case that > a compromised server can do a lot of damage. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > From A.L.M.Buxey at lboro.ac.uk Sun Apr 22 07:47:54 2012 From: A.L.M.Buxey at lboro.ac.uk (Alan Buxey) Date: Sun, 22 Apr 2012 08:47:54 +0100 Subject: dhcp-users Digest, Vol 42, Issue 29 Message-ID: This bug reset is for a client. all code may contain bugs or assumptions. If you don't trust dhcp enough then make your network like that from early 1990s and just use static addresses. If your ISP gives addresses by DHCP and you can't get given a static address then you don't have a choice. Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhcp1 at thehobsons.co.uk Sun Apr 22 08:25:23 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Sun, 22 Apr 2012 09:25:23 +0100 Subject: enquiry on validation of dhcp offered address In-Reply-To: <4F93570F.9030306@gmail.com> References: <4F92AFC1.6050106@gmail.com> <20120421.154204.74738791.sthaug@nethelp.no> <4F93570F.9030306@gmail.com> Message-ID: If you are going to reply to the digest, PLEASE FIX THE SUBJECT ! A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ching wrote: >if dhclient can fully trust dhcp server, this kind of report should >not exists. > >http://www.kb.cert.org/vuls/id/107886 And what on earth does that have to do with your query - absolutely nothing. That is a vulnerability in terms of being sent "bad" data and executing code. Your query is about validating the address because you don't trust your ISP to hand out a correct one. The ability of another user on a shared network to setup a rogue DHCP serveer is well known - it's been a known security issue since before DHCP was around (it was known about back when BOOTP was 'new'). Depending on the environment, anyone running a DHCP service in a 'hostile" environment should be aware of this and have measures in place to avoid it (block DHCP traffic) or at least detect it so it can be dealt with. In general, I'd be surprised to see any competent ISP not block DHCP server traffic from clients to make it physically impossible to do - if they don't do this then find a competent ISP. Simply ignoring RFC1918 addresses will not protect you - if I had access to run a rogue DHCP server then I could just as easily hand out some random block of addresses which your check wouldn't complain about - and you'd be none the wiser. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From lsching17 at gmail.com Sun Apr 22 10:07:11 2012 From: lsching17 at gmail.com (ching) Date: Sun, 22 Apr 2012 18:07:11 +0800 Subject: enquiry on validation of dhcp offered address In-Reply-To: References: Message-ID: <4F93D84F.1080808@gmail.com> Oh i see, currently i have no choice Thanks for your clarification anyway. ching On Sunday, April 22, 2012 03:47 PM, Alan Buxey wrote: > This bug reset is for a client. all code may contain bugs or > assumptions. If you don't trust dhcp enough then make your network > like that from early 1990s and just use static addresses. > > If your ISP gives addresses by DHCP and you can't get given a static > address then you don't have a choice. > > Alan > From lsching17 at gmail.com Sun Apr 22 12:35:37 2012 From: lsching17 at gmail.com (ching) Date: Sun, 22 Apr 2012 20:35:37 +0800 Subject: enquiry on validation of dhcp offered addres In-Reply-To: References: Message-ID: <4F93FB19.3070007@gmail.com> Dear all, Thank you for the information provided. So validation on dhcp address seems a wrong direction. I will look for other way to prevent routing intranet traffic to outside. ching From dhcp1 at thehobsons.co.uk Sun Apr 22 21:23:30 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Sun, 22 Apr 2012 22:23:30 +0100 Subject: enquiry on validation of dhcp offered addres In-Reply-To: <4F93FB19.3070007@gmail.com> References: <4F93FB19.3070007@gmail.com> Message-ID: ching wrote: >I will look for other way to prevent routing intranet traffic to outside. Hang on ... you never said anything about that before ! If all you are interested in is preventing routing certain traffic outside of your network then just apply a few firewall rules to block it. That too is nothing to do with DHCP. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From ameen.shajahan at wipro.com Mon Apr 23 05:55:31 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Mon, 23 Apr 2012 05:55:31 +0000 Subject: Is ISC DHCP server will take dynamically changing value?? Message-ID: Hi all, Consider the scenario below. If I am running dhcp server ie dhcpd and I have a conf file at /etc/dhcpd.conf I would like to know if change the conf file for example lease time and lease range changes dynamically without stopping the dhcp server. So that the dhcp server(dhcpd) will take the changed value from conf file and will give the new IP address change. Is ISC code have this kind of support. Please let me know. Regards, Ameen S Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ameen.shajahan at wipro.com Mon Apr 23 06:01:43 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Mon, 23 Apr 2012 06:01:43 +0000 Subject: ISC DHCP-4.2.3 query?? Message-ID: Hi all, I want to know the below queries. 1. Is ISC code has support for finding the status of DHCP server/relay for example running or stopped or terminated . Is there any interface or option available to find . 2. We can find the status of any process by using ps -ef command. But I want to know ISC code has support internally without using the default commands. Thanks, Ameen S Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhcp1 at thehobsons.co.uk Mon Apr 23 07:08:01 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Mon, 23 Apr 2012 08:08:01 +0100 Subject: Is ISC DHCP server will take dynamically changing value?? In-Reply-To: References: Message-ID: ameen.shajahan at wipro.com wrote: >I would like to know if change the conf file for example lease time >and lease range changes dynamically without stopping the dhcp server. No, the conf file is only read at startup. But as the server does (or should unless you've got an incredibly large setup) start up in seconds, it should be no big problem to restart it to reload the config. That's what a number of people are doing where they have an external system to build/update their config. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From dhcp1 at thehobsons.co.uk Mon Apr 23 07:09:18 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Mon, 23 Apr 2012 08:09:18 +0100 Subject: ISC DHCP-4.2.3 query?? In-Reply-To: References: Message-ID: ameen.shajahan at wipro.com wrote: >ISC code has support for finding the status of DHCP server/relay >for example running or stopped or terminated . Is there any >interface or option available to find . Yes, look up OMAPI, I belive their's a man page for it in the DHCP package, but it's not something I've had occasion to use. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From ameen.shajahan at wipro.com Mon Apr 23 07:13:48 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Mon, 23 Apr 2012 07:13:48 +0000 Subject: ISC DHCP query? Message-ID: Hi all, I want to know the below queries. 1. ISC DHCP-4.2.3 allows to run DHCP server as DHCPv4 or v6 at a single time. So client can able to get IPv4 or IPv6 address at a time not both. 2. Is ISC will support this dual IP facility to clients in near future? 3. Is there any draft available if they are implementing this dual support feature currently . Thanks, Ameen S Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ameen.shajahan at wipro.com Mon Apr 23 09:04:44 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Mon, 23 Apr 2012 09:04:44 +0000 Subject: ISC DHCP query? Message-ID: Please respond to the below mail. From: Ameen Shajahan (WT01 - GMT-Telecom Equipment) Sent: 23 April 2012 12:44 To: 'Users of ISC DHCP' Subject: ISC DHCP query? Hi all, I want to know the below queries. 1. ISC DHCP-4.2.3 allows to run DHCP server as DHCPv4 or v6 at a single time. So client can able to get IPv4 or IPv6 address at a time not both. 2. Is ISC will support this dual IP facility to clients in near future? 3. Is there any draft available if they are implementing this dual support feature currently . Thanks, Ameen S Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ameen.shajahan at wipro.com Mon Apr 23 09:05:23 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Mon, 23 Apr 2012 09:05:23 +0000 Subject: FW: ISC DHCP-4.2.3 query?? Message-ID: Please respond to the below mail. From: Ameen Shajahan (WT01 - GMT-Telecom Equipment) Sent: 23 April 2012 11:32 To: 'Users of ISC DHCP' Subject: ISC DHCP-4.2.3 query?? Hi all, I want to know the below queries. 1. Is ISC code has support for finding the status of DHCP server/relay for example running or stopped or terminated . Is there any interface or option available to find . 2. We can find the status of any process by using ps -ef command. But I want to know ISC code has support internally without using the default commands. Thanks, Ameen S Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ameen.shajahan at wipro.com Mon Apr 23 09:08:23 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Mon, 23 Apr 2012 09:08:23 +0000 Subject: How to enable and disable DHCP ?? Message-ID: Hi all, I am using ISC DHCP-4.2.3 for DHCP. Is there any option available for enabling and disabling DHCP. How to do with ISC code. If anybody done this means, Please reply. Thanks, Ameen S Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt at spamcop.net Mon Apr 23 09:55:27 2012 From: vogt at spamcop.net (Gerald Vogt) Date: Mon, 23 Apr 2012 11:55:27 +0200 Subject: ISC DHCP query? In-Reply-To: References: Message-ID: <4F95270F.5060700@spamcop.net> On 23.04.12 09:13, ameen.shajahan at wipro.com wrote: > Hi all, > > I want to know the below queries. > > 1. ISC DHCP-4.2.3 allows to run DHCP server as DHCPv4 or v6 at a > single time. So client can able to get IPv4 or IPv6 address at a time > not both. You can ask as often as you want: Any instance of dhcpd is either v4 or v6. Never both. You can run one dhcpd to serve IPv4 and one dhcpd to serve IPv6. Why would you want to assign only an IPv6 address but no IPv4? > 2. Is ISC will support this dual IP facility to clients in near > future? What would be the purpose of that? Doesn't make any sense to me. > 3. Is there any draft available if they are implementing this > dual support feature currently . There is no draft. Gerald From vogt at spamcop.net Mon Apr 23 09:57:25 2012 From: vogt at spamcop.net (Gerald Vogt) Date: Mon, 23 Apr 2012 11:57:25 +0200 Subject: FW: ISC DHCP-4.2.3 query?? In-Reply-To: References: Message-ID: <4F952785.5060408@spamcop.net> Please stop spamming this list. There is no purpose posting every 2 hours demanding answers. Your mail has been answered. I would suggest reading the answer... https://lists.isc.org/pipermail/dhcp-users/2012-April/015356.html Gerald On 23.04.12 11:05, ameen.shajahan at wipro.com wrote: > Please respond to the below mail. > > > > *From:*Ameen Shajahan (WT01 - GMT-Telecom Equipment) > *Sent:* 23 April 2012 11:32 > *To:* 'Users of ISC DHCP' > *Subject:* ISC DHCP-4.2.3 query?? > > > > Hi all, > > I want to know the below queries. > > 1. Is ISC code has support for finding the status of DHCP > server/relay for example running or stopped or terminated . Is there > any interface or option available to find . > > 2. We can find the status of any process by using ps ?ef command. > But I want to know ISC code has support internally without using the > default commands. > > > > Thanks, > > Ameen S From ameen.shajahan at wipro.com Mon Apr 23 10:02:38 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Mon, 23 Apr 2012 10:02:38 +0000 Subject: ISC DHCP query? In-Reply-To: <4F95270F.5060700@spamcop.net> References: <4F95270F.5060700@spamcop.net> Message-ID: Because we are using this ISC DHCP api's and libraries in our code to support DHCP. We have to support both ipv4 and ipv6 at a same time , using a single process. So I have raised a query to forum for response. Thanks for the reply. -----Original Message----- From: dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org [mailto:dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org] On Behalf Of Gerald Vogt Sent: 23 April 2012 15:25 To: dhcp-users at lists.isc.org Subject: Re: ISC DHCP query? On 23.04.12 09:13, ameen.shajahan at wipro.com wrote: > Hi all, > > I want to know the below queries. > > 1. ISC DHCP-4.2.3 allows to run DHCP server as DHCPv4 or v6 at a > single time. So client can able to get IPv4 or IPv6 address at a time > not both. You can ask as often as you want: Any instance of dhcpd is either v4 or v6. Never both. You can run one dhcpd to serve IPv4 and one dhcpd to serve IPv6. Why would you want to assign only an IPv6 address but no IPv4? > 2. Is ISC will support this dual IP facility to clients in near > future? What would be the purpose of that? Doesn't make any sense to me. > 3. Is there any draft available if they are implementing this > dual support feature currently . There is no draft. Gerald _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com From vogt at spamcop.net Mon Apr 23 10:16:12 2012 From: vogt at spamcop.net (Gerald Vogt) Date: Mon, 23 Apr 2012 12:16:12 +0200 Subject: ISC DHCP query? In-Reply-To: References: <4F95270F.5060700@spamcop.net> Message-ID: <4F952BEC.7050502@spamcop.net> On 23.04.12 12:02, ameen.shajahan at wipro.com wrote: > Because we are using this ISC DHCP api's and libraries in our code to support DHCP. > We have to support both ipv4 and ipv6 at a same time , using a single process. That's not supported with ISC DHCP. You know that by now. > So I have raised a query to forum for response. It's not supported. Don't use ISC DHCP if you think you absolutely need IPv4 and IPv6 support at the same time in the same process. Gerald > Thanks for the reply. > > -----Original Message----- > From: dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org [mailto:dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org] On Behalf Of Gerald Vogt > Sent: 23 April 2012 15:25 > To: dhcp-users at lists.isc.org > Subject: Re: ISC DHCP query? > > On 23.04.12 09:13, ameen.shajahan at wipro.com wrote: >> Hi all, >> >> I want to know the below queries. >> >> 1. ISC DHCP-4.2.3 allows to run DHCP server as DHCPv4 or v6 at a >> single time. So client can able to get IPv4 or IPv6 address at a time >> not both. > > You can ask as often as you want: Any instance of dhcpd is either v4 or > v6. Never both. You can run one dhcpd to serve IPv4 and one dhcpd to > serve IPv6. > > Why would you want to assign only an IPv6 address but no IPv4? > >> 2. Is ISC will support this dual IP facility to clients in near >> future? > > What would be the purpose of that? Doesn't make any sense to me. > >> 3. Is there any draft available if they are implementing this >> dual support feature currently . > > There is no draft. > > Gerald > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. > > www.wipro.com > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users From dhcp1 at thehobsons.co.uk Mon Apr 23 10:32:01 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Mon, 23 Apr 2012 11:32:01 +0100 Subject: ISC DHCP query? In-Reply-To: References: <4F95270F.5060700@spamcop.net> Message-ID: ameen.shajahan at wipro.com wrote: >Because we are using this ISC DHCP api's and libraries in our code >to support DHCP. >We have to support both ipv4 and ipv6 at a same time , using a single process. So why didn't you say so in the first place ? You've been spamming this list with the same question, getting the same answer, and seemingly ignoring it - only now do we find out that the reason the answer was wrong was because you didn't ask the right question. You should have said what you were trying to do instead of annoying everyone with your spam. I'm guessing this is a for a commercial setup, in which case you might consider approaching ISC for paid support. If you can offer a business case then they may consider combining the code to suit your requirements - but you'd have to offer a business case for it. Alternatively, the source is available to you so there's nothing to stop you attempting this yourself. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From dhcp1 at thehobsons.co.uk Mon Apr 23 10:40:27 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Mon, 23 Apr 2012 11:40:27 +0100 Subject: How to enable and disable DHCP ?? In-Reply-To: References: Message-ID: ameen.shajahan at wipro.com wrote: >I am using ISC DHCP-4.2.3 for DHCP. >Is there any option available for enabling and disabling DHCP. >How to do with ISC code. If you mean, can you turn on and off the DHCP service ... Do you not have a single person in your group (I'm assuming you work for Wipro ?) with a clue about computers, and unix-like systems ? To enable the service you start the DHCP daemon. To disable the service you stop the DHCP daemon. How you configure whether the daemon starts automatically on system boot (or on any other system event) is OS/variant dependant. Ie hwo you do it on Debian Linux is different to Red Hat (or Fedora) Linux, is different to FreeBSD, is different to Solaris, and so on. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From alex at alex.org.uk Mon Apr 23 10:49:24 2012 From: alex at alex.org.uk (Alex Bligh) Date: Mon, 23 Apr 2012 11:49:24 +0100 Subject: Is ISC DHCP server will take dynamically changing value?? In-Reply-To: References: Message-ID: <5BA9639261104A420FE1D20F@Ximines.local> --On 23 April 2012 05:55:31 +0000 ameen.shajahan at wipro.com wrote: > I would like to know if change the conf file for example lease time and > lease range changes dynamically without stopping the dhcp server. You can either reload the config file which involves restarting dhcpd, or (to a limited extent) use the database backends (e.g. LDAP or my sql patch). >From the manpage: > Whenever changes are made to the dhcpd.conf file, dhcpd must be > restarted. To restart dhcpd, send a SIGTERM (signal 15) to the > process ID contained in /var/run/dhcpd.pid, and then re-invoke dhcpd. > Because the DHCP server database is not as light?weight as a BOOTP > database, dhcpd does not automatically restart itself when it sees a > change to the dhcpd.conf file. > > Note: We get a lot of complaints about this. We realize that it would > be nice if one could send a SIGHUP to the server and have it reload > the database. This is not technically impossible, but it would require > a great deal of work, our resources are extremely limited, and they can > be better spent elsewhere. So please don't complain about this on the > mailing list unless you're prepared to fund a project to implement this > feature, or prepared to do it yourself. -- Alex Bligh From lsching17 at gmail.com Mon Apr 23 11:17:39 2012 From: lsching17 at gmail.com (ching) Date: Mon, 23 Apr 2012 19:17:39 +0800 Subject: enquiry on validation of dhcp offered addres In-Reply-To: References: Message-ID: <4F953A53.8030309@gmail.com> I will look for other way to prevent routing intranet traffic to outside. > Hang on ... you never said anything about that before ! > > If all you are interested in is preventing routing certain traffic > outside of your network then just apply a few firewall rules to block > it. That too is nothing to do with DHCP. > This partially solve the problem as dropping internal traffic can result in a denial of service attack. From glenn.satchell at uniq.com.au Mon Apr 23 12:51:15 2012 From: glenn.satchell at uniq.com.au (Glenn Satchell) Date: Mon, 23 Apr 2012 22:51:15 +1000 Subject: ISC DHCP query? In-Reply-To: References: Message-ID: <4F955043.1040001@uniq.com.au> Hello Ameen This question was answered last week, and the answer was no. It is not possible to have a single instance of dhcpd handling both IPv4 and IPv6. The documented method is to have two processes running, one for each protocol. Each instance requires its own configuration, pid and lease files. regards, -glenn On 04/23/12 19:04, ameen.shajahan at wipro.com wrote: > Please respond to the below mail. > > *From:*Ameen Shajahan (WT01 - GMT-Telecom Equipment) > *Sent:* 23 April 2012 12:44 > *To:* 'Users of ISC DHCP' > *Subject:* ISC DHCP query? > > Hi all, > > I want to know the below queries. > > 1.ISC DHCP-4.2.3 allows to run DHCP server as DHCPv4 or v6 at a single > time. So client can able to get IPv4 or IPv6 address at a time not both. > > 2.Is ISC will support this dual IP facility to clients in near future? > > 3.Is there any draft available if they are implementing this dual > support feature currently . > > Thanks, > > Ameen S > > *Please do not print this email unless it is absolutely necessary. * > > The information contained in this electronic message and any attachments > to this message are intended for the exclusive use of the addressee(s) > and may contain proprietary, confidential or privileged information. If > you are not the intended recipient, you should not disseminate, > distribute or copy this e-mail. Please notify the sender immediately and > destroy all copies of this message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient > should check this email and any attachments for the presence of viruses. > The company accepts no liability for any damage caused by any virus > transmitted by this email. > > www.wipro.com > > From glenn.satchell at uniq.com.au Mon Apr 23 12:59:14 2012 From: glenn.satchell at uniq.com.au (Glenn Satchell) Date: Mon, 23 Apr 2012 22:59:14 +1000 Subject: enquiry on validation of dhcp offered addres In-Reply-To: <4F953A53.8030309@gmail.com> References: <4F953A53.8030309@gmail.com> Message-ID: <4F955222.6060603@uniq.com.au> On 04/23/12 21:17, ching wrote: > > I will look for other way to prevent routing intranet traffic to outside. > >> Hang on ... you never said anything about that before ! >> >> If all you are interested in is preventing routing certain traffic >> outside of your network then just apply a few firewall rules to block >> it. That too is nothing to do with DHCP. >> > This partially solve the problem as dropping internal traffic can result > in a denial of service attack. You could add firewall rules to block outbound traffic on your WAN interface to addresses that match your internal network. This is called anti-spoofing, and is (or used to be) common practise when setting up a firewall. So, if someone outside your LAN pretends to have an internal IP you ignore that. That's not denial of service, since it's only going to block invalid IP destinations. -- regards, -glenn From srinivasreddyambati66 at gmail.com Mon Apr 23 15:30:55 2012 From: srinivasreddyambati66 at gmail.com (srinivas reddy) Date: Mon, 23 Apr 2012 21:00:55 +0530 Subject: How to enable link selection option in dhcp relay Message-ID: Hi all, How to enable link selection option in dhcp relay while sending packets to dhcp server? Regards, A.Srinivas Reddy -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomasz at isc.org Mon Apr 23 18:28:52 2012 From: tomasz at isc.org (Tomek Mrugalski) Date: Mon, 23 Apr 2012 18:28:52 +0000 Subject: Is ISC DHCP server will take dynamically changing value?? In-Reply-To: References: Message-ID: <4F959F64.8020506@isc.org> On 12-04-23 05:55, ameen.shajahan at wipro.com wrote: > Hi all, > > Consider the scenario below. > > If I am running dhcp server ie dhcpd and I have a conf > file at /etc/dhcpd.conf > > I would like to know if change the conf file for example > lease time and lease range changes dynamically without stopping the dhcp > server. > > So that the dhcp server(dhcpd) will take the changed value from conf > file and will give the new IP address change. Is ISC code have this kind > of support. Depends on what kind of configuration change you want to do. Some things can be modified on-line and some can't. man 1 omshell man 3 omapi -- Tomek Mrugalski ISC DHCP Engineer From lists at malte.homeip.net Mon Apr 23 20:51:18 2012 From: lists at malte.homeip.net (Malte Starostik) Date: Mon, 23 Apr 2012 22:51:18 +0200 Subject: (Multicast) DHCP relaying, or what happened to draft-hall-lemon-bootp-multicast-relays-02.txt? Message-ID: <26723452.E9J8dfuuDy@hal> Hello, while simulating some setups in GNS3, I was considering some options for how to handle DHCP relaying with dhcpd running on two servers w/ failover configured. It basically boiled down to hard-cofiguring either two (locally assigned) well-known addresses for whatever servers will provide DHCP and let those servers advertise via some IGP one of these IPs each - or devise some multicast setup. During research, a long expired draft, http://www.eric-a- hall.com/specs/draft-hall-lemon-bootp-multicast-relays-02.txt caught my attention. What's described in there pretty much seems like what I wanted - but I totally failed to find any later version of the draft or any other information about what happened to it :( Has this ever been implemented? In ISC DHCP? Seems like the only thing to add would be for dhcpd to join a configurable multicast group and listen accordingly? If the draft really went into oblivion, is there any info as to why this happened? Apart from that I'm definately also interested in additional approaches besides configuring the servers' actual and possibly changing IPs into every router. Thanks in advance for your time and knowledge, Malte From romulobil at gmail.com Tue Apr 24 02:48:18 2012 From: romulobil at gmail.com (romulo albuquerque) Date: Mon, 23 Apr 2012 23:48:18 -0300 Subject: DHCP ACK WITHOUT LEASE OPTION Message-ID: Hello, Let's suppose we have a client requesting a valid IP for that network, for example in INIT-BOOT state. A dhcp client can accept normally dhcp_ack message without a new lease and so continue to use the last one, if that lease still has validity? Is DHCP client machine prepared to handle this situation? -- R?mulo Albuquerque -------------- next part -------------- An HTML attachment was scrubbed... URL: From ameen.shajahan at wipro.com Tue Apr 24 05:18:34 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Tue, 24 Apr 2012 05:18:34 +0000 Subject: Is ISC DHCP server will take dynamically changing value?? In-Reply-To: <4F959F64.8020506@isc.org> References: <4F959F64.8020506@isc.org> Message-ID: Can you please explain the below scenario. I want to change the subnet , lease range and lease time. I haven't tried using omshell and omapi. Can u just give a brief description for changing values. -----Original Message----- From: dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org [mailto:dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org] On Behalf Of Tomek Mrugalski Sent: 23 April 2012 23:59 To: dhcp-users at lists.isc.org Subject: Re: Is ISC DHCP server will take dynamically changing value?? On 12-04-23 05:55, ameen.shajahan at wipro.com wrote: > Hi all, > > Consider the scenario below. > > If I am running dhcp server ie dhcpd and I have a conf > file at /etc/dhcpd.conf > > I would like to know if change the conf file for example > lease time and lease range changes dynamically without stopping the dhcp > server. > > So that the dhcp server(dhcpd) will take the changed value from conf > file and will give the new IP address change. Is ISC code have this kind > of support. Depends on what kind of configuration change you want to do. Some things can be modified on-line and some can't. man 1 omshell man 3 omapi -- Tomek Mrugalski ISC DHCP Engineer _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com From srinivasreddyambati66 at gmail.com Tue Apr 24 06:16:34 2012 From: srinivasreddyambati66 at gmail.com (srinivas reddy) Date: Tue, 24 Apr 2012 11:46:34 +0530 Subject: How to enable link selection option in dhcp relay In-Reply-To: References: Message-ID: Do we need to add any code for Link selection sub option in dhcrelay.c to support it? On Mon, Apr 23, 2012 at 9:00 PM, srinivas reddy < srinivasreddyambati66 at gmail.com> wrote: > Hi all, > > How to enable link selection option in dhcp relay while sending packets to > dhcp server? > > Regards, > A.Srinivas Reddy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sthaug at nethelp.no Tue Apr 24 06:37:20 2012 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 24 Apr 2012 08:37:20 +0200 (CEST) Subject: Is ISC DHCP server will take dynamically changing value?? In-Reply-To: References: <4F959F64.8020506@isc.org> Message-ID: <20120424.083720.74738619.sthaug@nethelp.no> > Can you please explain the below scenario. > I want to change the subnet , lease range and lease time. > I haven't tried using omshell and omapi. > Can u just give a brief description for changing values. I'm afraid your incessant whining to this list may have made people slightly less interested in helping you. You have already been given good advice, namely looking at the man pages > man 1 omshell > man 3 omapi In addition you might want to check out the dhcp-users archives, at https://lists.isc.org/pipermail/dhcp-users/ Steinar Haug, Nethelp consulting, sthaug at nethelp.no From vogt at spamcop.net Tue Apr 24 07:27:18 2012 From: vogt at spamcop.net (Gerald Vogt) Date: Tue, 24 Apr 2012 09:27:18 +0200 Subject: Is ISC DHCP server will take dynamically changing value?? In-Reply-To: References: <4F959F64.8020506@isc.org> Message-ID: <4F9655D6.701@spamcop.net> On 24.04.12 07:18, ameen.shajahan at wipro.com wrote: > Can you please explain the below scenario. > I want to change the subnet , lease range and lease time. You want to change the subnet? And what do you expect to happen with all those leases on the server that were assigned in the old subnet? And what do you expect to happen with all those leases on the clients which have an active lease from the old subnet? Gerald > I haven't tried using omshell and omapi. > Can u just give a brief description for changing values. > > > > -----Original Message----- > From: dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org [mailto:dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org] On Behalf Of Tomek Mrugalski > Sent: 23 April 2012 23:59 > To: dhcp-users at lists.isc.org > Subject: Re: Is ISC DHCP server will take dynamically changing value?? > > On 12-04-23 05:55, ameen.shajahan at wipro.com wrote: >> Hi all, >> >> Consider the scenario below. >> >> If I am running dhcp server ie dhcpd and I have a conf >> file at /etc/dhcpd.conf >> >> I would like to know if change the conf file for example >> lease time and lease range changes dynamically without stopping the dhcp >> server. >> >> So that the dhcp server(dhcpd) will take the changed value from conf >> file and will give the new IP address change. Is ISC code have this kind >> of support. > Depends on what kind of configuration change you want to do. Some things > can be modified on-line and some can't. > > man 1 omshell > man 3 omapi > From ameen.shajahan at wipro.com Tue Apr 24 08:28:41 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Tue, 24 Apr 2012 08:28:41 +0000 Subject: Is ISC DHCP server will take dynamically changing value?? In-Reply-To: <4F9655D6.701@spamcop.net> References: <4F959F64.8020506@isc.org> <4F9655D6.701@spamcop.net> Message-ID: My expectation is I have to change the subnet , lease range and lease time . So that the client will get the changed subnet , lease range and its corresponding lease time. In simple words, whenever the changes happened in conf file client can able to get the changes without restarting the server. Can we able to do this kind of functionality using ISC code? If ISC code allows to do the changes then how to proceed for that? Please let me know -----Original Message----- From: dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org [mailto:dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org] On Behalf Of Gerald Vogt Sent: 24 April 2012 12:57 To: dhcp-users at lists.isc.org Subject: Re: Is ISC DHCP server will take dynamically changing value?? On 24.04.12 07:18, ameen.shajahan at wipro.com wrote: > Can you please explain the below scenario. > I want to change the subnet , lease range and lease time. You want to change the subnet? And what do you expect to happen with all those leases on the server that were assigned in the old subnet? And what do you expect to happen with all those leases on the clients which have an active lease from the old subnet? Gerald > I haven't tried using omshell and omapi. > Can u just give a brief description for changing values. > > > > -----Original Message----- > From: dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org [mailto:dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org] On Behalf Of Tomek Mrugalski > Sent: 23 April 2012 23:59 > To: dhcp-users at lists.isc.org > Subject: Re: Is ISC DHCP server will take dynamically changing value?? > > On 12-04-23 05:55, ameen.shajahan at wipro.com wrote: >> Hi all, >> >> Consider the scenario below. >> >> If I am running dhcp server ie dhcpd and I have a conf >> file at /etc/dhcpd.conf >> >> I would like to know if change the conf file for example >> lease time and lease range changes dynamically without stopping the dhcp >> server. >> >> So that the dhcp server(dhcpd) will take the changed value from conf >> file and will give the new IP address change. Is ISC code have this kind >> of support. > Depends on what kind of configuration change you want to do. Some things > can be modified on-line and some can't. > > man 1 omshell > man 3 omapi > _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com From vogt at spamcop.net Tue Apr 24 08:32:34 2012 From: vogt at spamcop.net (Gerald Vogt) Date: Tue, 24 Apr 2012 10:32:34 +0200 Subject: Is ISC DHCP server will take dynamically changing value?? In-Reply-To: References: <4F959F64.8020506@isc.org> <4F9655D6.701@spamcop.net> Message-ID: <4F966522.4010002@spamcop.net> On 24.04.12 10:28, ameen.shajahan at wipro.com wrote: > My expectation is I have to change the subnet , lease range and lease time . > So that the client will get the changed subnet , lease range and its corresponding lease time. > In simple words, whenever the changes happened in conf file client can able to get the changes without restarting the server. > Can we able to do this kind of functionality using ISC code? This kind of functionality is not supported by DHCP. It's not supported by any DHCP server. No DHCP server can force a DHCP client to simply move to another subnet by another DHCP lease. I would say what you are trying to do is impossible. It's not covered by the DHCP RFC and is not supported by any DHCP server you'll find out there. Gerald > If ISC code allows to do the changes then how to proceed for that? > Please let me know > > -----Original Message----- > From: dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org [mailto:dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org] On Behalf Of Gerald Vogt > Sent: 24 April 2012 12:57 > To: dhcp-users at lists.isc.org > Subject: Re: Is ISC DHCP server will take dynamically changing value?? > > On 24.04.12 07:18, ameen.shajahan at wipro.com wrote: >> Can you please explain the below scenario. >> I want to change the subnet , lease range and lease time. > > You want to change the subnet? > > And what do you expect to happen with all those leases on the server > that were assigned in the old subnet? > > And what do you expect to happen with all those leases on the clients > which have an active lease from the old subnet? > > Gerald > > > >> I haven't tried using omshell and omapi. >> Can u just give a brief description for changing values. >> >> >> >> -----Original Message----- >> From: dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org [mailto:dhcp-users-bounces+ameen.shajahan=wipro.com at lists.isc.org] On Behalf Of Tomek Mrugalski >> Sent: 23 April 2012 23:59 >> To: dhcp-users at lists.isc.org >> Subject: Re: Is ISC DHCP server will take dynamically changing value?? >> >> On 12-04-23 05:55, ameen.shajahan at wipro.com wrote: >>> Hi all, >>> >>> Consider the scenario below. >>> >>> If I am running dhcp server ie dhcpd and I have a conf >>> file at /etc/dhcpd.conf >>> >>> I would like to know if change the conf file for example >>> lease time and lease range changes dynamically without stopping the dhcp >>> server. >>> >>> So that the dhcp server(dhcpd) will take the changed value from conf >>> file and will give the new IP address change. Is ISC code have this kind >>> of support. >> Depends on what kind of configuration change you want to do. Some things >> can be modified on-line and some can't. >> >> man 1 omshell >> man 3 omapi >> > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. > > www.wipro.com > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users From dhcp1 at thehobsons.co.uk Tue Apr 24 06:52:28 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Tue, 24 Apr 2012 07:52:28 +0100 Subject: Is ISC DHCP server will take dynamically changing value?? In-Reply-To: <20120424.083720.74738619.sthaug@nethelp.no> References: <4F959F64.8020506@isc.org> <20120424.083720.74738619.sthaug@nethelp.no> Message-ID: ameen.shajahan at wipro.com wrote: >Can you please explain the below scenario. >I want to change the subnet , lease range and lease time. >I haven't tried using omshell and omapi. >Can u just give a brief description for changing values. I'm fairly sure that subnet and lease range won't be alterable via OMAPI, don't know about lease time. sthaug at nethelp.no wrote: > > Can you please explain the below scenario. >> I want to change the subnet , lease range and lease time. >> I haven't tried using omshell and omapi. >> Can u just give a brief description for changing values. > >I'm afraid your incessant whining to this list may have made people >slightly less interested in helping you. I think you could be right. From this and other lists I'm on, it does seem to be a cultural thing from some parts of the world. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From dhcp1 at thehobsons.co.uk Tue Apr 24 09:01:43 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Tue, 24 Apr 2012 10:01:43 +0100 Subject: Is ISC DHCP server will take dynamically changing value?? In-Reply-To: References: <4F959F64.8020506@isc.org> <4F9655D6.701@spamcop.net> Message-ID: ameen.shajahan at wipro.com wrote: >My expectation is I have to change the subnet , lease range and lease time . >So that the client will get the changed subnet , lease range and its >corresponding lease time. >In simple words, whenever the changes happened in conf file client >can able to get the changes without restarting the server. Firstly, you really need to understand the difference between "restart servICE" (ie restart the DHCP service) and "restart servER" (ie reboot the host). For typical size configurations, restarting the servICE with the ISC DHCP server takes a matter of seconds vs potentially minutes for the servER (ie host OS) to restart. There really, really, REALLY is no problem restarting the DHCP servICE to reconfigure it - except in some very large and complicated setups which I very much doubt you are going to be using. As Gerald says, just changing the configuration on the server will **NOT** reconfigure the clients - it just does not work like that. Once the server has issued a lease, teh client is free to use that address (and other information) for the lifetime of that lease (which may be anything from a few minutes to a few years depending on how the administrator has configured the server. Changing the subnet on a network is not something you do lightly. I've done it a couple of times at work and it's a pian to do - it really is not something you should be doing very often (if at all). It takes time, and a lot of work - it's not just a matter of changing your DHCP ... You need to reconfigure your router(s), including keeping both subnets active with routing between them. Change all your DNS. Reconfigure all your statically configured devices. Reconfigured everything that refers to the address of a statically configured device (eg changing the address of the printer(s) on every client - been there, got the tee shirt !). And then spend the next few weeks on the tail end of support calls for things you've missed. So, a few seconds to restart the DHCP service is neither here nor there. I would suggest that instead of trying to figure out how to reconfigure a network quickly, you would be better off learning how to plan a network properly so you don't have to. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From lsching17 at gmail.com Tue Apr 24 12:00:58 2012 From: lsching17 at gmail.com (ching) Date: Tue, 24 Apr 2012 20:00:58 +0800 Subject: enquiry on validation of dhcp offered addres In-Reply-To: References: Message-ID: <4F9695FA.3080807@gmail.com> On Tuesday, April 24, 2012 02:16 PM, dhcp-users-request at lists.isc.org wrote: >> I will look for other way to prevent routing intranet traffic to outside. >> >>> Hang on ... you never said anything about that before ! >>> >>> If all you are interested in is preventing routing certain traffic >>> outside of your network then just apply a few firewall rules to block >>> it. That too is nothing to do with DHCP. >>> >> This partially solve the problem as dropping internal traffic can result >> in a denial of service attack. > You could add firewall rules to block outbound traffic on your WAN > interface to addresses that match your internal network. This is called > anti-spoofing, and is (or used to be) common practise when setting up a > firewall. So, if someone outside your LAN pretends to have an internal > IP you ignore that. That's not denial of service, since it's only going > to block invalid IP destinations. > if internal server's ip is 192.168.2.2/255.255.255.0 and the invalid wan address 192.168.2.1/255.255.255.128 if firewall is not blocking, then a faked server may be waiting at the WAN interface, ready to receive confidential information. if firewall is blocking, then the real server may have a downtime (all 192.168.2.2 traffic are routed to WAN interface and then dropped), resulting in a denial of service. From glenn.satchell at uniq.com.au Tue Apr 24 12:15:16 2012 From: glenn.satchell at uniq.com.au (Glenn Satchell) Date: Tue, 24 Apr 2012 22:15:16 +1000 Subject: enquiry on validation of dhcp offered addres In-Reply-To: <4F9695FA.3080807@gmail.com> References: <4F9695FA.3080807@gmail.com> Message-ID: <4F969954.5060607@uniq.com.au> On 04/24/12 22:00, ching wrote: > On Tuesday, April 24, 2012 02:16 PM, dhcp-users-request at lists.isc.org > wrote: >>> I will look for other way to prevent routing intranet traffic to >>> outside. >>> >>>> Hang on ... you never said anything about that before ! >>>> >>>> If all you are interested in is preventing routing certain traffic >>>> outside of your network then just apply a few firewall rules to block >>>> it. That too is nothing to do with DHCP. >>>> >>> This partially solve the problem as dropping internal traffic can result >>> in a denial of service attack. >> You could add firewall rules to block outbound traffic on your WAN >> interface to addresses that match your internal network. This is called >> anti-spoofing, and is (or used to be) common practise when setting up a >> firewall. So, if someone outside your LAN pretends to have an internal >> IP you ignore that. That's not denial of service, since it's only going >> to block invalid IP destinations. >> > > if internal server's ip is 192.168.2.2/255.255.255.0 and the invalid wan > address 192.168.2.1/255.255.255.128 > > if firewall is not blocking, then a faked server may be waiting at the > WAN interface, ready to receive confidential information. > if firewall is blocking, then the real server may have a downtime (all > 192.168.2.2 traffic are routed to WAN interface and then dropped), > resulting in a denial of service. > So the traffic would be blocked to the fake external server. That's what you want isn't it? If your WAN interface is re-configured with 192.168.2.1 then unless the whole ISP network routing changes then no traffic will be able to get out to the Internet anyway. You could also add outbound firewall rules blocking NFS, Microsoft SMB ports and the like, which should never need to go outside your network. But this is straying far from the topic of the DHCP list I think. regards, -glenn From Ted.Lemon at nominum.com Tue Apr 24 12:39:10 2012 From: Ted.Lemon at nominum.com (Ted Lemon) Date: Tue, 24 Apr 2012 12:39:10 +0000 Subject: (Multicast) DHCP relaying, or what happened to draft-hall-lemon-bootp-multicast-relays-02.txt? In-Reply-To: <26723452.E9J8dfuuDy@hal> References: <26723452.E9J8dfuuDy@hal> Message-ID: <13D14014-5BCC-4498-96DA-A368C142045C@nominum.com> It died due to lack of interest, I think. DHCPv4 is, after all, obsolete... :) From sai.mukund.sagar at gmail.com Tue Apr 24 13:30:36 2012 From: sai.mukund.sagar at gmail.com (Mukund Deshpande) Date: Tue, 24 Apr 2012 19:00:36 +0530 Subject: Network Address getting assigned to client and ping not working (ver 4.2.2) Message-ID: Hi All, I am facing two issues when using ISC DHCP (Using version 4.2.2). When I keep a network address like 7.7.7.0 in range it gets assigned on client. Is this correct behavior? Also when i try to ping on the address assigned by dhclient on an interface i get error "connect: Invalid Argument" , even when i have host addresses in range. Can any body please provide me with pointers as to why ping doesn't work? # # /etc/dhcpd.conf - DHCP Server Setup File. # # DHCP Pool sms subnet 7.7.7.0 netmask 255.255.255.0 { option subnet-mask 255.255.255.0; range 7.7.7.0; default-lease-time 86400; max-lease-time 86400; } ddns-update-style none; Running dhclient as [root at Marvell1 ~]#/usr/sbin/dhclient -4 -cf /etc/dhclient-eth1.conf -lf /etc/dhclient-eth1.leases -pf /var/run/dhclient-eth1.pid eth1 Captured on Client -------------------------------- [root at Marvell1 ~]# tethereal -i eth1 Running as user "root" and group "root". This could be dangerous. Capturing on eth1 0.000000 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - Transaction ID 0xf7d8ad21 1.016566 7.7.7.1 -> 7.7.7.0 DHCP DHCP Offer - Transaction ID 0xf7d8ad21 1.016965 0.0.0.0 -> 255.255.255.255 DHCP DHCP Request - Transaction ID 0xf7d8ad21 * 1.037018 7.7.7.1 -> 7.7.7.0 DHCP DHCP ACK - Transaction ID 0xf7d8ad21 * <<<<<<<<<<<<< Assigning Network Address ^C4 packets captured [root at Marvell1 ~]# ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:1B:21:52:AD:69 inet addr:7.7.7.0 Bcast:7.7.7.255 Mask:255.255.255.0 inet6 addr: fe80::21b:21ff:fe52:ad69/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:19583 errors:2 dropped:0 overruns:0 frame:2 TX packets:66453 errors:11 dropped:0 overruns:0 carrier:11 collisions:0 txqueuelen:1000 RX bytes:1854865 (1.7 MiB) TX bytes:5472310 (5.2 MiB) *[root at Marvell1 ~]# ping 7.7.7.0 <<< This happens whenever dhclient is running...* *connect: Invalid argument* Lease File ------------------- [root at Marvell1 etc]# cat dhclient-eth1.leases lease { interface "eth1"; fixed-address 7.7.7.0; option subnet-mask 255.255.255.0; option dhcp-lease-time 86400; option dhcp-message-type 5; option dhcp-server-identifier 7.7.7.1; renew 4 2012/04/26 21:10:20; rebind 5 2012/04/27 08:32:20; expire 5 2012/04/27 11:32:20; } Captured on Server -------------------------------- /mukund/home/zebos # /tcpdump -i ge1 device ge1 entered promiscuous mode tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ge1, link-type EN10MB (Ethernet), capture size 65535 bytes 16:57:39.482239 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 000 16:57:40.498253 IP 7.7.7.1.67 > 7.7.7.0.68: BOOTP/DHCP, Reply, length 300 16:57:40.499162 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 000 16:57:40.518704 IP 7.7.7.1.67 > 7.7.7.0.68: BOOTP/DHCP, Reply, length 300 -- Regards, Mukund -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhcp1 at thehobsons.co.uk Tue Apr 24 13:34:22 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Tue, 24 Apr 2012 14:34:22 +0100 Subject: enquiry on validation of dhcp offered addres In-Reply-To: <4F9695FA.3080807@gmail.com> References: <4F9695FA.3080807@gmail.com> Message-ID: ching wrote: >if internal server's ip is 192.168.2.2/255.255.255.0 and the invalid >wan address 192.168.2.1/255.255.255.128 > >if firewall is not blocking, then a faked server may be waiting at >the WAN interface, ready to receive confidential information. >if firewall is blocking, then the real server may have a downtime >(all 192.168.2.2 traffic are routed to WAN interface and then >dropped), resulting in a denial of service. Err, no - or rather, it depends. If there is only the one subnet internal to your network, then traffic WITHIN THAT NETWORK will not be routed outside of the gateway. It will be local traffic, not need the use of a router, and so will never need to go through the gateway at all. No internal device will have traffic routed to the external device. Only traffic originating within the gateway device itself will be routed externally. You are correct however that if you have multiple subnets, AND traffic between subnets is routed via the same router that provides your external connectivity, then traffic from internal subnets **other than 192.168.1.0/24** to 192.158.1.0/25 would get incorrectly routed externally. Some simple egress filtering rules (it's generally considered good practice to drop RFC1918 traffic on your external interface anyway) will prevent information leakage. But you are correct that it will cause a loss of access to certain internal devices to certain other devices depending on your internal network setup. You could of course minimise the issue by adding host routes to your gateway - these /32 routes would take precedence over any practical external route. You would however, no matter what you do, lose all external connectivity unless the miscreant also took care of providing a NAT gateway to a real IP address. If someone has that level of skill, and the level of access to your ISPs network to do that, then you do have bigger issues to worry about. I see your point, but I have to question whether it's a significant risk. You may want to look at the script used by the DHCP client to configure the system - though from memory I'm not sure whether it is called at the right times for the checks you want to do. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From lyle at lcrcomputer.net Tue Apr 24 13:50:03 2012 From: lyle at lcrcomputer.net (Lyle Giese) Date: Tue, 24 Apr 2012 08:50:03 -0500 Subject: Network Address getting assigned to client and ping not working (ver 4.2.2) In-Reply-To: References: Message-ID: <4F96AF8B.10700@lcrcomputer.net> On 04/24/12 08:30, Mukund Deshpande wrote: > Hi All, > > I am facing two issues when using ISC DHCP (Using version 4.2.2). > > When I keep a network address like 7.7.7.0 in range it gets assigned > on client. > Is this correct behavior? > > Also when i try to ping on the address assigned by dhclient on an > interface i get error "connect: Invalid Argument" , even when i have > host addresses in range. > Can any body please provide me with pointers as to why ping doesn't work? > > > # > # /etc/dhcpd.conf - DHCP Server Setup File. > # > > # DHCP Pool sms > subnet 7.7.7.0 netmask 255.255.255.0 { > option subnet-mask 255.255.255.0; > range 7.7.7.0; > default-lease-time 86400; > max-lease-time 86400; > } > ddns-update-style none; > > > Running dhclient as > > [root at Marvell1 ~]#/usr/sbin/dhclient -4 -cf /etc/dhclient-eth1.conf > -lf /etc/dhclient-eth1.leases -pf /var/run/dhclient-eth1.pid eth1 > > Captured on Client > -------------------------------- > > [root at Marvell1 ~]# tethereal -i eth1 > Running as user "root" and group "root". This could be dangerous. > Capturing on eth1 > 0.000000 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - > Transaction ID 0xf7d8ad21 > 1.016566 7.7.7.1 -> 7.7.7.0 DHCP DHCP Offer - > Transaction ID 0xf7d8ad21 > 1.016965 0.0.0.0 -> 255.255.255.255 DHCP DHCP Request - > Transaction ID 0xf7d8ad21 > * 1.037018 7.7.7.1 -> 7.7.7.0 DHCP DHCP ACK - > Transaction ID 0xf7d8ad21 * <<<<<<<<<<<<< Assigning Network Address > ^C4 packets captured > [root at Marvell1 ~]# ifconfig eth1 > eth1 Link encap:Ethernet HWaddr 00:1B:21:52:AD:69 > inet addr:7.7.7.0 Bcast:7.7.7.255 Mask:255.255.255.0 > inet6 addr: fe80::21b:21ff:fe52:ad69/64 Scope:Link > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > RX packets:19583 errors:2 dropped:0 overruns:0 frame:2 > TX packets:66453 errors:11 dropped:0 overruns:0 carrier:11 > collisions:0 txqueuelen:1000 > RX bytes:1854865 (1.7 MiB) TX bytes:5472310 (5.2 MiB) > > *[root at Marvell1 ~]# ping 7.7.7.0 <<< This happens whenever dhclient is > running...* > *connect: Invalid argument* > > > Lease File > ------------------- > > [root at Marvell1 etc]# cat dhclient-eth1.leases > lease { > interface "eth1"; > fixed-address 7.7.7.0; > option subnet-mask 255.255.255.0; > option dhcp-lease-time 86400; > option dhcp-message-type 5; > option dhcp-server-identifier 7.7.7.1; > renew 4 2012/04/26 21:10:20; > rebind 5 2012/04/27 08:32:20; > expire 5 2012/04/27 11:32:20; > } > > > Captured on Server > -------------------------------- > /mukund/home/zebos # /tcpdump -i ge1 > device ge1 entered promiscuous mode > tcpdump: verbose output suppressed, use -v or -vv for full protocol decode > listening on ge1, link-type EN10MB (Ethernet), capture size 65535 bytes > 16:57:39.482239 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, > Request from 000 > 16:57:40.498253 IP 7.7.7.1.67 > 7.7.7.0.68: BOOTP/DHCP, Reply, length 300 > 16:57:40.499162 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, > Request from 000 > 16:57:40.518704 IP 7.7.7.1.67 > 7.7.7.0.68: BOOTP/DHCP, Reply, length 300 > -- > Regards, > Mukund > > > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users 1) Range = Subnet in your config. Results will be indeterminate because of that. It has also been suggested that using .0 or .255 in the last octet of an IPv4 address can be problematic because of assumptions/bugs in IPv4 implementations in various OS/devices. 2) Newer windows OS's block icmp packets by default. Make sure the target OS is not firewalling ping packets. Lyle Giese LCR Computer Services, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter at rathlev.dk Tue Apr 24 13:59:16 2012 From: peter at rathlev.dk (Peter Rathlev) Date: Tue, 24 Apr 2012 15:59:16 +0200 Subject: Network Address getting assigned to client and ping not working (ver 4.2.2) In-Reply-To: References: Message-ID: <1335275956.11015.5.camel@abehat.dyn.net.rm.dk> On Tue, 2012-04-24 at 19:00 +0530, Mukund Deshpande wrote: > # DHCP Pool sms > subnet 7.7.7.0 netmask 255.255.255.0 { > option subnet-mask 255.255.255.0; > range 7.7.7.0; > default-lease-time 86400; > max-lease-time 86400; > } > ddns-update-style none; ... > [root at Marvell1 ~]# ping 7.7.7.0 <<< This happens whenever dhclient is running... > connect: Invalid argument The network address (all 0's in the host part) is not a valid host address for an ethernet network. The same goes for the limited broadcast address (all 1's in the host part). For a /24 network those two addresses are always .0 and .255. If you want to use 7.7.7.0 as a host address (on ethernet) you need to use 7.7.6.0/23 or larger where it would be valid. You always need to not include network, broadcast and gateway addresses in the range statement. Assuming you use .1 as gateway address and maybe .2 and .3 for first hop redundancy, the range statement for 7.7.7.0/24 should be: range 7.7.7.4 7.7.7.254; That dhclient actually accepts this address might be seen as a "bug", but it's just doing what you tell it. :-) -- Peter From A.L.M.Buxey at lboro.ac.uk Tue Apr 24 14:08:57 2012 From: A.L.M.Buxey at lboro.ac.uk (alan buxey) Date: Tue, 24 Apr 2012 15:08:57 +0100 Subject: Network Address getting assigned to client and ping not working (ver 4.2.2) In-Reply-To: <1335275956.11015.5.camel@abehat.dyn.net.rm.dk> References: <1335275956.11015.5.camel@abehat.dyn.net.rm.dk> Message-ID: <20120424140857.GA12480@lboro.ac.uk> hi, as peter says, the 7.7.7.0 address would be the network address....you shouldnt be handing it out as part of a range... which is what you are doing. dhcpd is only doing what you told it to do :-| ideally you would have something like range 7.7.7.2 7.7.7.253; (this would allow you to have either the .1 or the .254 as the gateway address.. and as also said, you need to hand the client some other options alan From flex.banana at bluewin.ch Tue Apr 24 14:10:51 2012 From: flex.banana at bluewin.ch (Flex Banana) Date: Tue, 24 Apr 2012 16:10:51 +0200 Subject: Network Address getting assigned to client and ping not working (ver 4.2.2) In-Reply-To: <1335275956.11015.5.camel@abehat.dyn.net.rm.dk> References: <1335275956.11015.5.camel@abehat.dyn.net.rm.dk> Message-ID: I think you can not use .0 as host address. We have a lot of /23 subnet and never a .0 will be assigned. Best regards Banana On Apr 24, 2012, at 3:59 PM, Peter Rathlev wrote: > If you want to use 7.7.7.0 as a host address (on ethernet) you need to > use 7.7.6.0/23 or larger where it would be valid. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sai.mukund.sagar at gmail.com Tue Apr 24 14:31:29 2012 From: sai.mukund.sagar at gmail.com (Mukund Deshpande) Date: Tue, 24 Apr 2012 20:01:29 +0530 Subject: Network Address getting assigned to client and ping not working (ver 4.2.2) In-Reply-To: References: <1335275956.11015.5.camel@abehat.dyn.net.rm.dk> Message-ID: Hi All, Thanks for clarifying my doubt. I have one query here. If my subnet is say 7.7.0.0/16 and in range if i specify range 7.7.0.1 7.7.77.77; Then 7.7.1.0 , 7.7.2.0 , 7.7.3.0 7.7.77.0 or 7.7.5.255 are part of this range. Will have to explicitly exclude all the addresses from this range ? That would be so many addresses to exclude. And if we were to exclude the .0 's and .255's it would be many ranges we would end up specifying. Please correct me if I am wrong. Regards, Mukund On Tue, Apr 24, 2012 at 7:40 PM, Flex Banana wrote: > I think you can not use .0 as host address. > > We have a lot of /23 subnet and never a .0 will be assigned. > > Best regards > Banana > > On Apr 24, 2012, at 3:59 PM, Peter Rathlev wrote: > > If you want to use 7.7.7.0 as a host address (on ethernet) you need to > use 7.7.6.0/23 or larger where it would be valid. > > > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users > -- Regards, Mukund -------------- next part -------------- An HTML attachment was scrubbed... URL: From flex.banana at bluewin.ch Tue Apr 24 14:36:50 2012 From: flex.banana at bluewin.ch (Flex Banana) Date: Tue, 24 Apr 2012 16:36:50 +0200 Subject: Network Address getting assigned to client and ping not working (ver 4.2.2) In-Reply-To: References: <1335275956.11015.5.camel@abehat.dyn.net.rm.dk> Message-ID: subnet 7.7.0.0/16 is equal to a range from 7.7.0.0 to 7.7.255.254 7.7.0.0 is the network address 7.7.255.255 is the broadcast address you don't have to exclude all .0 and .255 because there will not be assigned Banana On Apr 24, 2012, at 4:31 PM, Mukund Deshpande wrote: > Hi All, > > Thanks for clarifying my doubt. > > I have one query here. > > If my subnet is say 7.7.0.0/16 > > and in range if i specify > > range 7.7.0.1 7.7.77.77; > > > Then 7.7.1.0 , 7.7.2.0 , 7.7.3.0 7.7.77.0 or 7.7.5.255 are part of this range. Will have to explicitly exclude all the addresses from this range ? That would be so many addresses to exclude. > > And if we were to exclude the .0 's and .255's it would be many ranges we would end up specifying. > > Please correct me if I am wrong. > > Regards, > Mukund > > > On Tue, Apr 24, 2012 at 7:40 PM, Flex Banana wrote: > I think you can not use .0 as host address. > > We have a lot of /23 subnet and never a .0 will be assigned. > > Best regards > Banana > > On Apr 24, 2012, at 3:59 PM, Peter Rathlev wrote: > >> If you want to use 7.7.7.0 as a host address (on ethernet) you need to >> use 7.7.6.0/23 or larger where it would be valid. > > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users > > > > -- > Regards, > Mukund > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jmglass at iup.edu Tue Apr 24 14:43:42 2012 From: jmglass at iup.edu (Jim Glassford) Date: Tue, 24 Apr 2012 10:43:42 -0400 Subject: Network Address getting assigned to client and ping not working (ver 4.2.2) In-Reply-To: References: <1335275956.11015.5.camel@abehat.dyn.net.rm.dk> Message-ID: <4F96BC1E.6000205@iup.edu> Hi, The .0 and .255 are valid IP addresses within the network but ~some~ clients do have problems with these IP addresses. To avoid any chance of this, I do exclude the .0 and .255 addresses just to save any problems. Might be better ways but seems to work well here, sample for one below. subnet 7.7.123.0 netmask 255.255.248.0 { option routers 7.7.123.4; deny bootp; pool { range 7.7.123.22 7.7.123.254; range 7.7.124.1 7.7.124.254; range 7.7.125.1 7.7.125.254; range 7.7.126.1 7.7.126.254; range 7.7.127.1 7.7.127.254; range 7.7.128.1 7.7.128.254; range 7.7.129.1 7.7.129.254; range 7.7.130.1 7.7.130.254; default-lease-time 3600; max-lease-time 3600; ignore client-updates; ddns-updates on; ddns-rev-domainname "in-addr.arpa."; ddns-hostname = binary-to-ascii (16, 8, "-",substring (hardware, 1, 6)); ddns-domainname "x.y.z"; deny members of "badboys"; } } On 4/24/2012 10:31 AM, Mukund Deshpande wrote: > Hi All, > > Thanks for clarifying my doubt. > > I have one query here. > > If my subnet is say 7.7.0.0/16 > > and in range if i specify > > range 7.7.0.1 7.7.77.77; > > > Then 7.7.1.0 , 7.7.2.0 , 7.7.3.0 7.7.77.0 or 7.7.5.255 are part of this > range. Will have to explicitly exclude all the addresses from this range > ? That would be so many addresses to exclude. > > And if we were to exclude the .0 's and .255's it would be many ranges > we would end up specifying. > > Please correct me if I am wrong. > > Regards, > Mukund > > > On Tue, Apr 24, 2012 at 7:40 PM, Flex Banana > wrote: > > I think you can not use .0 as host address. > > We have a lot of /23 subnet and never a .0 will be assigned. > > Best regards > Banana > > On Apr 24, 2012, at 3:59 PM, Peter Rathlev wrote: > >> If you want to use 7.7.7.0 as a host address (on ethernet) you need to >> use 7.7.6.0/23 or larger where it would be valid. > > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users > > > > > -- > Regards, > Mukund > > > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users From peter at rathlev.dk Tue Apr 24 14:55:02 2012 From: peter at rathlev.dk (Peter Rathlev) Date: Tue, 24 Apr 2012 16:55:02 +0200 Subject: Network Address getting assigned to client and ping not working (ver 4.2.2) In-Reply-To: References: <1335275956.11015.5.camel@abehat.dyn.net.rm.dk> Message-ID: <1335279302.12702.11.camel@abehat.dyn.net.rm.dk> On Tue, 2012-04-24 at 20:01 +0530, Mukund Deshpande wrote: > If my subnet is say 7.7.0.0/16 > and in range if i specify > range 7.7.0.1 7.7.77.77; > > Then 7.7.1.0 , 7.7.2.0 , 7.7.3.0 7.7.77.0 or 7.7.5.255 are part of > this range. Will have to explicitly exclude all the addresses from > this range ? That would be so many addresses to exclude. > > And if we were to exclude the .0 's and .255's it would be many ranges > we would end up specifying. You don't have to exclude those addresses. We have many networks larger than /24 (typically /22) and we have had no problems with hosts being assigned .0 og .255. These hosts include Avaya 1220 and 1140E phones and Windows XP clients. The DHCP server will not automatically exclude those addresses, at least not the ISC DHCPd. If there ever was a problem with using .0 og .255 it would have been within supernets of the "class C" range, i.e. 192.0.0.0-223.255.255.255. Subnets of class A or class B addresses (e.g. 10.2.16.0/22 or 172.26.0.0/23) Keep in mind that the original[*] IPv4 specification described classful addressing where class A (0.0.0.0-127.255.255.255) and class B (128.0.0.0-191.255.255.255) networks were always supposed to allow for the last eight bits to be all 0's or all 1's. The host part could of course never be all 0's or all 1's, but in e.g. a class B network you would have 255 valid host addresses with the last octet equal to 0 and similarly 255 valid host addresses with the last octet equal to 255. I cannot rule out that certain less-than-optimal implementations of the IP stack would break when using those (valid) addresses, but I'm faily certain that at least Windows XP does not have these problems today. [*]: Per RFC791. There was an even earlier version of the protocol where all networks were what we call /8 today. -- Peter From sai.mukund.sagar at gmail.com Tue Apr 24 15:02:02 2012 From: sai.mukund.sagar at gmail.com (Mukund Deshpande) Date: Tue, 24 Apr 2012 20:32:02 +0530 Subject: Network Address getting assigned to client and ping not working (ver 4.2.2) In-Reply-To: <4F96BC1E.6000205@iup.edu> References: <1335275956.11015.5.camel@abehat.dyn.net.rm.dk> <4F96BC1E.6000205@iup.edu> Message-ID: Thank you all for clarifying my query :-) Regards, Mukund -------------- next part -------------- An HTML attachment was scrubbed... URL: From A.L.M.Buxey at lboro.ac.uk Tue Apr 24 15:06:15 2012 From: A.L.M.Buxey at lboro.ac.uk (alan buxey) Date: Tue, 24 Apr 2012 16:06:15 +0100 Subject: Network Address getting assigned to client and ping not working (ver 4.2.2) In-Reply-To: <4F96BC1E.6000205@iup.edu> References: <1335275956.11015.5.camel@abehat.dyn.net.rm.dk> <4F96BC1E.6000205@iup.edu> Message-ID: <20120424150615.GD12685@lboro.ac.uk> Hi, > The .0 and .255 are valid IP addresses within the network but ~some~ ONLY of the network spans over those addresses - ie only if they are NOT network or broadcast addresses for the subnet (as was in this case where is was a /24 so they were used for IP ) we give out .0 and .255 within bigger subnets and have done so for years. any device/kit that doesnt like that is turned off, burnt , smashed or skipped. alan From peter at rathlev.dk Tue Apr 24 15:08:09 2012 From: peter at rathlev.dk (Peter Rathlev) Date: Tue, 24 Apr 2012 17:08:09 +0200 Subject: Network Address getting assigned to client and ping not working (ver 4.2.2) In-Reply-To: <1335279302.12702.11.camel@abehat.dyn.net.rm.dk> References: <1335275956.11015.5.camel@abehat.dyn.net.rm.dk> <1335279302.12702.11.camel@abehat.dyn.net.rm.dk> Message-ID: <1335280089.12702.20.camel@abehat.dyn.net.rm.dk> On Tue, 2012-04-24 at 16:55 +0200, Peter Rathlev wrote: > You don't have to exclude those addresses. We have many networks larger > than /24 (typically /22) and we have had no problems with hosts being > assigned .0 og .255. These hosts include Avaya 1220 and 1140E phones and > Windows XP clients. The DHCP server will not automatically exclude those > addresses, at least not the ISC DHCPd. Examples for these: >From 10.104.0.0/22 we have an Avaya 1140E running firware "0625C7M": lease 10.104.1.0 { starts 2 2012/04/24 14:21:07; ends 3 2012/04/25 02:21:07; tstp 5 2012/04/20 05:00:30; tsfp 3 2012/04/25 08:21:07; atsfp 3 2012/04/25 08:21:07; cltt 4 2012/04/19 11:00:30; binding state active; next binding state expired; hardware ethernet 3c:b1:5b:53:06:a8; set commit-vendor-class = "Nortel-i2004-A"; client-hostname "T3CB15B5306A8"; } >From 10.22.72.0/22 we have a Windows XP client: lease 10.22.74.0 { starts 2 2012/04/24 09:45:03; ends 2 2012/04/24 21:45:03; tstp 1 2012/04/23 15:45:00; tsfp 3 2012/04/25 03:45:03; atsfp 3 2012/04/25 03:45:03; cltt 0 2012/04/22 21:45:00; binding state active; next binding state expired; hardware ethernet 00:21:6a:20:e4:fc; uid "\001\000!j \344\374"; set commit-vendor-class = "MSFT 5.0"; client-hostname "A70219"; } Plenty of Android devices, Juniper/Trapeze access points (MP-82 and MP-522) and Linux Ubuntu or Fedora hosts besides these have had no problems. -- Peter From rgrimsha at syr.edu Tue Apr 24 15:13:32 2012 From: rgrimsha at syr.edu (Randall C Grimshaw) Date: Tue, 24 Apr 2012 15:13:32 +0000 Subject: Network Address getting assigned to client and ping not working (ver 4.2.2) In-Reply-To: <1335280089.12702.20.camel@abehat.dyn.net.rm.dk> References: <1335275956.11015.5.camel@abehat.dyn.net.rm.dk> <1335279302.12702.11.camel@abehat.dyn.net.rm.dk>, <1335280089.12702.20.camel@abehat.dyn.net.rm.dk> Message-ID: Your internet ISP however may be filtering the addresses.. which was our case for anything .0 and .255 on the class C boundary despite the fact that we have a Class B space. Randall Grimshaw rgrimsha at syr.edu ________________________________________ From: dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org [dhcp-users-bounces+rgrimsha=syr.edu at lists.isc.org] on behalf of Peter Rathlev [peter at rathlev.dk] Sent: Tuesday, April 24, 2012 11:08 AM To: Users of ISC DHCP Subject: Re: Network Address getting assigned to client and ping not working (ver 4.2.2) On Tue, 2012-04-24 at 16:55 +0200, Peter Rathlev wrote: > You don't have to exclude those addresses. We have many networks larger > than /24 (typically /22) and we have had no problems with hosts being > assigned .0 og .255. These hosts include Avaya 1220 and 1140E phones and > Windows XP clients. The DHCP server will not automatically exclude those > addresses, at least not the ISC DHCPd. Examples for these: >From 10.104.0.0/22 we have an Avaya 1140E running firware "0625C7M": lease 10.104.1.0 { starts 2 2012/04/24 14:21:07; ends 3 2012/04/25 02:21:07; tstp 5 2012/04/20 05:00:30; tsfp 3 2012/04/25 08:21:07; atsfp 3 2012/04/25 08:21:07; cltt 4 2012/04/19 11:00:30; binding state active; next binding state expired; hardware ethernet 3c:b1:5b:53:06:a8; set commit-vendor-class = "Nortel-i2004-A"; client-hostname "T3CB15B5306A8"; } >From 10.22.72.0/22 we have a Windows XP client: lease 10.22.74.0 { starts 2 2012/04/24 09:45:03; ends 2 2012/04/24 21:45:03; tstp 1 2012/04/23 15:45:00; tsfp 3 2012/04/25 03:45:03; atsfp 3 2012/04/25 03:45:03; cltt 0 2012/04/22 21:45:00; binding state active; next binding state expired; hardware ethernet 00:21:6a:20:e4:fc; uid "\001\000!j \344\374"; set commit-vendor-class = "MSFT 5.0"; client-hostname "A70219"; } Plenty of Android devices, Juniper/Trapeze access points (MP-82 and MP-522) and Linux Ubuntu or Fedora hosts besides these have had no problems. -- Peter _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users From A.L.M.Buxey at lboro.ac.uk Tue Apr 24 15:19:08 2012 From: A.L.M.Buxey at lboro.ac.uk (alan buxey) Date: Tue, 24 Apr 2012 16:19:08 +0100 Subject: Network Address getting assigned to client and ping not working (ver 4.2.2) In-Reply-To: References: <1335275956.11015.5.camel@abehat.dyn.net.rm.dk> <1335279302.12702.11.camel@abehat.dyn.net.rm.dk> <1335280089.12702.20.camel@abehat.dyn.net.rm.dk> Message-ID: <20120424151908.GI12685@lboro.ac.uk> Hi, > Your internet ISP however may be filtering the addresses.. which was our case for anything .0 and .255 on the class C boundary despite the fact that we have a Class B space. ..and if our ISP did that we'd leave them and go to a new ISP. fortunately WE are the ISP for these clients :-) alan From Robert.C.Drye at hitchcock.org Tue Apr 24 19:01:58 2012 From: Robert.C.Drye at hitchcock.org (Robert C. Drye) Date: Tue, 24 Apr 2012 19:01:58 +0000 Subject: DDNS updates fail after moving server Message-ID: <8B1F9D8F33CA2148B895DCE2171F05E5024C0E@DH207.DHMCMaster.DH.Hitchcock.org> We recently moved our DHCP-3.0 configuration to DHCP-4.2.3-P2 on new hardware but with the same IP address. Updates are done against the same DNS server. We get this kind of message in the log (addresses changed to protect the innocent...). There is no rndc key in use. Manual updates using nsupdate from the dhcpd server work fine. BIND version on DNS server is 9.7.5 . Apr 24 14:55:42 dhcpd dhcpd: Unable to add forward map from T7CL43626.dhcp.hitchcock.org. to 192.168.62.125: not found. Here are some relevant snips from dhcpd.conf ddns-update-style interim; ignore client-updates; do-forward-updates on; And in the zone: subnet 192.168.62.0 netmask 255.255.255.0 { pool { range 192.168.62.51 192.168.62.254 ; deny members of "ras-clients"; } option broadcast-address 192.168.62.255 ; option routers 192.168.62.1 ; option domain-name "hitchcock.org" ; option domain-name-servers 192.168.240.100, 192.168.241.68 ; option netbios-name-servers 192.168.240.87, 192.168.240.86 ; option netbios-node-type 8 ; ddns-domainname "dhcp.hitchcock.org."; ddns-rev-domainname "in-addr.arpa."; default-lease-time 7200; max-lease-time 7200; } IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE: This message is intended for the use of the person to whom it is addressed and may contain information that is privileged, confidential, and protected from disclosure under applicable law. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudy at grumpydevil.homelinux.org Tue Apr 24 19:11:21 2012 From: rudy at grumpydevil.homelinux.org (Rudy Zijlstra) Date: Tue, 24 Apr 2012 21:11:21 +0200 Subject: DDNS updates fail after moving server In-Reply-To: <8B1F9D8F33CA2148B895DCE2171F05E5024C0E@DH207.DHMCMaster.DH.Hitchcock.org> References: <8B1F9D8F33CA2148B895DCE2171F05E5024C0E@DH207.DHMCMaster.DH.Hitchcock.org> Message-ID: <1335294681.4059.32.camel@belgarath.office.romunt.nl> Hi Robert, Robert C. Drye schreef op di 24-04-2012 om 19:01 [+0000]: > We recently moved our DHCP-3.0 configuration to DHCP-4.2.3-P2 on new > hardware but with the same IP address. Updates are done against the > same DNS server. We get this kind of message in the log (addresses > changed to protect the innocent?). There is no rndc key in use. > Manual updates using nsupdate from the dhcpd server work fine. BIND > version on DNS server is 9.7.5 . > > > > Apr 24 14:55:42 dhcpd dhcpd: Unable to add forward map from > T7CL43626.dhcp.hitchcock.org. to 192.168.62.125: not found. > > > > Here are some relevant snips from dhcpd.conf How are your zone statements in the dhcpd.conf? Cheers, Rudy From Robert.C.Drye at hitchcock.org Tue Apr 24 19:35:18 2012 From: Robert.C.Drye at hitchcock.org (Robert C. Drye) Date: Tue, 24 Apr 2012 19:35:18 +0000 Subject: DDNS updates fail after moving server In-Reply-To: <1335294681.4059.32.camel@belgarath.office.romunt.nl> References: <8B1F9D8F33CA2148B895DCE2171F05E5024C0E@DH207.DHMCMaster.DH.Hitchcock.org> <1335294681.4059.32.camel@belgarath.office.romunt.nl> Message-ID: <8B1F9D8F33CA2148B895DCE2171F05E5024C38@DH207.DHMCMaster.DH.Hitchcock.org> Zone statements (in fact the entire dhcpd.conf) were unchanged between the old and new servers. Missing info: New server is redhat 6.2. -----Original Message----- From: dhcp-users-bounces+robert.c.drye=hitchcock.org at lists.isc.org [mailto:dhcp-users-bounces+robert.c.drye=hitchcock.org at lists.isc.org] On Behalf Of Rudy Zijlstra Sent: Tuesday, April 24, 2012 3:11 PM To: Users of ISC DHCP Subject: Re: DDNS updates fail after moving server Hi Robert, Robert C. Drye schreef op di 24-04-2012 om 19:01 [+0000]: > We recently moved our DHCP-3.0 configuration to DHCP-4.2.3-P2 on new > hardware but with the same IP address. Updates are done against the > same DNS server. We get this kind of message in the log (addresses > changed to protect the innocent?). There is no rndc key in use. > Manual updates using nsupdate from the dhcpd server work fine. BIND > version on DNS server is 9.7.5 . > > > > Apr 24 14:55:42 dhcpd dhcpd: Unable to add forward map from > T7CL43626.dhcp.hitchcock.org. to 192.168.62.125: not found. > > > > Here are some relevant snips from dhcpd.conf How are your zone statements in the dhcpd.conf? Cheers, Rudy _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE: This message is intended for the use of the person to whom it is addressed and may contain information that is privileged, confidential, and protected from disclosure under applicable law. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. From dhcp1 at thehobsons.co.uk Tue Apr 24 19:51:29 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Tue, 24 Apr 2012 20:51:29 +0100 Subject: DDNS updates fail after moving server In-Reply-To: <8B1F9D8F33CA2148B895DCE2171F05E5024C38@DH207.DHMCMaster.DH.Hitchcock.org> References: <8B1F9D8F33CA2148B895DCE2171F05E5024C0E@DH207.DHMCMaster.DH.Hitchcock.org> <1335294681.4059.32.camel@belgarath.office.romunt.nl> <8B1F9D8F33CA2148B895DCE2171F05E5024C38@DH207.DHMCMaster.DH.Hitchcock.org> Message-ID: Robert C. Drye wrote: >Zone statements (in fact the entire dhcpd.conf) were unchanged >between the old and new servers. That is the answer to a different question than the one that was asked. What are your zone statements ? What is the IP address of the DNS server ? Does your DNS server log anything ? If so, what ? If you use a packet sniffer (tcpdump, ethereal, ...), do you see any DNS traffic between the two servers ? Alternatively, it's possible to run without zone entries in your DHCP config if your DNS and SOA records are all correctly set up - the DCHP server can use the SOA record to work out where to send updates automagically. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From Robert.C.Drye at hitchcock.org Tue Apr 24 21:00:22 2012 From: Robert.C.Drye at hitchcock.org (Robert C. Drye) Date: Tue, 24 Apr 2012 21:00:22 +0000 Subject: DDNS updates fail after moving server In-Reply-To: <8B1F9D8F33CA2148B895DCE2171F05E5024C38@DH207.DHMCMaster.DH.Hitchcock.org> References: <8B1F9D8F33CA2148B895DCE2171F05E5024C0E@DH207.DHMCMaster.DH.Hitchcock.org> <1335294681.4059.32.camel@belgarath.office.romunt.nl>, <8B1F9D8F33CA2148B895DCE2171F05E5024C38@DH207.DHMCMaster.DH.Hitchcock.org> Message-ID: <8B1F9D8F33CA2148B895DCE2171F05E5024C5C@DH207.DHMCMaster.DH.Hitchcock.org> Adding the zone statements took care of it. None were required on the old RedHat 5 server. Thanks for your quick help. ________________________________________ From: dhcp-users-bounces+robert.c.drye=hitchcock.org at lists.isc.org [dhcp-users-bounces+robert.c.drye=hitchcock.org at lists.isc.org] on behalf of Robert C. Drye [Robert.C.Drye at hitchcock.org] Sent: Tuesday, April 24, 2012 3:35 PM To: 'Users of ISC DHCP' Subject: RE: DDNS updates fail after moving server Zone statements (in fact the entire dhcpd.conf) were unchanged between the old and new servers. Missing info: New server is redhat 6.2. -----Original Message----- From: dhcp-users-bounces+robert.c.drye=hitchcock.org at lists.isc.org [mailto:dhcp-users-bounces+robert.c.drye=hitchcock.org at lists.isc.org] On Behalf Of Rudy Zijlstra Sent: Tuesday, April 24, 2012 3:11 PM To: Users of ISC DHCP Subject: Re: DDNS updates fail after moving server Hi Robert, Robert C. Drye schreef op di 24-04-2012 om 19:01 [+0000]: > We recently moved our DHCP-3.0 configuration to DHCP-4.2.3-P2 on new > hardware but with the same IP address. Updates are done against the > same DNS server. We get this kind of message in the log (addresses > changed to protect the innocent?). There is no rndc key in use. > Manual updates using nsupdate from the dhcpd server work fine. BIND > version on DNS server is 9.7.5 . > > > > Apr 24 14:55:42 dhcpd dhcpd: Unable to add forward map from > T7CL43626.dhcp.hitchcock.org. to 192.168.62.125: not found. > > > > Here are some relevant snips from dhcpd.conf How are your zone statements in the dhcpd.conf? Cheers, Rudy _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE: This message is intended for the use of the person to whom it is addressed and may contain information that is privileged, confidential, and protected from disclosure under applicable law. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. _______________________________________________ dhcp-users mailing list dhcp-users at lists.isc.org https://lists.isc.org/mailman/listinfo/dhcp-users IMPORTANT NOTICE REGARDING THIS ELECTRONIC MESSAGE: This message is intended for the use of the person to whom it is addressed and may contain information that is privileged, confidential, and protected from disclosure under applicable law. If you are not the intended recipient, your use of this message for any purpose is strictly prohibited. If you have received this communication in error, please delete the message and notify the sender so that we may correct our records. From lsching17 at gmail.com Tue Apr 24 23:49:44 2012 From: lsching17 at gmail.com (ching) Date: Wed, 25 Apr 2012 07:49:44 +0800 Subject: enquiry on validation of dhcp offered addres In-Reply-To: References: Message-ID: <4F973C18.3080401@gmail.com> On Tuesday, April 24, 2012 09:50 PM, dhcp-users-request at lists.isc.org wrote: > On 04/24/12 22:00, ching wrote: >> > On Tuesday, April 24, 2012 02:16 PM, dhcp-users-request at lists.isc.org >> > wrote: >>>> >>> I will look for other way to prevent routing intranet traffic to >>>> >>> outside. >>>> >>> >>>>> >>>> Hang on ... you never said anything about that before ! >>>>> >>>> >>>>> >>>> If all you are interested in is preventing routing certain traffic >>>>> >>>> outside of your network then just apply a few firewall rules to block >>>>> >>>> it. That too is nothing to do with DHCP. >>>>> >>>> >>>> >>> This partially solve the problem as dropping internal traffic can result >>>> >>> in a denial of service attack. >>> >> You could add firewall rules to block outbound traffic on your WAN >>> >> interface to addresses that match your internal network. This is called >>> >> anti-spoofing, and is (or used to be) common practise when setting up a >>> >> firewall. So, if someone outside your LAN pretends to have an internal >>> >> IP you ignore that. That's not denial of service, since it's only going >>> >> to block invalid IP destinations. >>> >> >> > >> > if internal server's ip is 192.168.2.2/255.255.255.0 and the invalid wan >> > address 192.168.2.1/255.255.255.128 >> > >> > if firewall is not blocking, then a faked server may be waiting at the >> > WAN interface, ready to receive confidential information. >> > if firewall is blocking, then the real server may have a downtime (all >> > 192.168.2.2 traffic are routed to WAN interface and then dropped), >> > resulting in a denial of service. >> > > So the traffic would be blocked to the fake external server. That's what > you want isn't it? > > If your WAN interface is re-configured with 192.168.2.1 then unless the > whole ISP network routing changes then no traffic will be able to get > out to the Internet anyway. > > You could also add outbound firewall rules blocking NFS, Microsoft SMB > ports and the like, which should never need to go outside your network. > > But this is straying far from the topic of the DHCP list I think. > > regards, > -glenn my goal is to protect intranet traffic. Neither information leakage nor service interruption is expected. From lsching17 at gmail.com Wed Apr 25 00:05:06 2012 From: lsching17 at gmail.com (ching) Date: Wed, 25 Apr 2012 08:05:06 +0800 Subject: enquiry on validation of dhcp offered addres In-Reply-To: References: Message-ID: <4F973FB2.1070401@gmail.com> On Tuesday, April 24, 2012 09:50 PM, dhcp-users-request at lists.isc.org wrote: > Err, no - or rather, it depends. > > If there is only the one subnet internal to your network, then > traffic WITHIN THAT NETWORK will not be routed outside of the > gateway. It will be local traffic, not need the use of a router, and > so will never need to go through the gateway at all. > No internal device will have traffic routed to the external device. > Only traffic originating within the gateway device itself will be > routed externally. > > You are correct however that if you have multiple subnets, AND > traffic between subnets is routed via the same router that provides > your external connectivity, then traffic from internal subnets > **other than 192.168.1.0/24** to 192.158.1.0/25 would get incorrectly > routed externally. > > Some simple egress filtering rules (it's generally considered good > practice to drop RFC1918 traffic on your external interface anyway) > will prevent information leakage. But you are correct that it will > cause a loss of access to certain internal devices to certain other > devices depending on your internal network setup. You could of course > minimise the issue by adding host routes to your gateway - these /32 > routes would take precedence over any practical external route. > > You would however, no matter what you do, lose all external > connectivity unless the miscreant also took care of providing a NAT > gateway to a real IP address. If someone has that level of skill, and > the level of access to your ISPs network to do that, then you do have > bigger issues to worry about. > I see your point, but I have to question whether it's a significant > risk. You may want to look at the script used by the DHCP client to > configure the system - though from memory I'm not sure whether it is > called at the right times for the checks you want to do. Current scripts seems no validation at all. They "trust" everything from DHCP. I have several ideas in mind: 1. dhcp validation on dhclient - reject ipv4 class A,B,C private addresses and ipv6 ULA prefix - i think it is the most "clean" way 2. validation on network config scripts - reject ipv4 class A,B,C private addresses and ipv6 ULA prefix - it is quite hard for me, i do not know how to manipulate ipv4 subnet and ipv6 prefix in shell script 3. hard code the topology of internal LAN into a static route table - the quick and dirty trick if dhcp validation on dhclient is not possible, i will try to hard code route table. So back to my question, can dhclient validate offered address at all? From glenn.satchell at uniq.com.au Wed Apr 25 01:42:43 2012 From: glenn.satchell at uniq.com.au (Glenn Satchell) Date: Wed, 25 Apr 2012 11:42:43 +1000 Subject: Network Address getting assigned to client and ping not working (ver 4.2.2) In-Reply-To: <1335280089.12702.20.camel@abehat.dyn.net.rm.dk> References: <1335275956.11015.5.camel@abehat.dyn.net.rm.dk> <1335279302.12702.11.camel@abehat.dyn.net.rm.dk> <1335280089.12702.20.camel@abehat.dyn.net.rm.dk> Message-ID: <4F975693.9080009@uniq.com.au> This was the case many years ago, like mid 1990s, where some dhcp clients couldn't handle a valid address ending in .0 or .255. I seem to remember this was a recommendation in the early Cisco configuration instructions. These days it shouldn't be a problem any more. regards, -glenn On 04/25/12 01:08, Peter Rathlev wrote: > On Tue, 2012-04-24 at 16:55 +0200, Peter Rathlev wrote: >> You don't have to exclude those addresses. We have many networks larger >> than /24 (typically /22) and we have had no problems with hosts being >> assigned .0 og .255. These hosts include Avaya 1220 and 1140E phones and >> Windows XP clients. The DHCP server will not automatically exclude those >> addresses, at least not the ISC DHCPd. > > Examples for these: > > From 10.104.0.0/22 we have an Avaya 1140E running firware "0625C7M": > > lease 10.104.1.0 { > starts 2 2012/04/24 14:21:07; > ends 3 2012/04/25 02:21:07; > tstp 5 2012/04/20 05:00:30; > tsfp 3 2012/04/25 08:21:07; > atsfp 3 2012/04/25 08:21:07; > cltt 4 2012/04/19 11:00:30; > binding state active; > next binding state expired; > hardware ethernet 3c:b1:5b:53:06:a8; > set commit-vendor-class = "Nortel-i2004-A"; > client-hostname "T3CB15B5306A8"; > } > > From 10.22.72.0/22 we have a Windows XP client: > > lease 10.22.74.0 { > starts 2 2012/04/24 09:45:03; > ends 2 2012/04/24 21:45:03; > tstp 1 2012/04/23 15:45:00; > tsfp 3 2012/04/25 03:45:03; > atsfp 3 2012/04/25 03:45:03; > cltt 0 2012/04/22 21:45:00; > binding state active; > next binding state expired; > hardware ethernet 00:21:6a:20:e4:fc; > uid "\001\000!j \344\374"; > set commit-vendor-class = "MSFT 5.0"; > client-hostname "A70219"; > } > > Plenty of Android devices, Juniper/Trapeze access points (MP-82 and > MP-522) and Linux Ubuntu or Fedora hosts besides these have had no > problems. > From vogt at spamcop.net Wed Apr 25 04:39:37 2012 From: vogt at spamcop.net (Gerald Vogt) Date: Wed, 25 Apr 2012 06:39:37 +0200 Subject: enquiry on validation of dhcp offered addres In-Reply-To: <4F973FB2.1070401@gmail.com> References: <4F973FB2.1070401@gmail.com> Message-ID: <4F978009.6000909@spamcop.net> On 25.04.12 02:05, ching wrote: > Current scripts seems no validation at all. They "trust" everything > from DHCP. That's the design of DHCP. There is no authentication of the server nor the client. > I have several ideas in mind: 1. dhcp validation on dhclient - reject > ipv4 class A,B,C private addresses and ipv6 ULA prefix - i think it > is the most "clean" way That breaks DHCP. If you implement that you have to do it yourself. DHCP has no requirement on the client to be able to filter something. And for instance for all mobile clients you don't want that anyway because there are a lot of networks out there with private addresses. > 2. validation on network config scripts - reject ipv4 class A,B,C > private addresses and ipv6 ULA prefix - it is quite hard for me, i do > not know how to manipulate ipv4 subnet and ipv6 prefix in shell > script Again this goes beyond standard implementations of DHCP clients. You have to write that script yourself and make sure it works the way you intend it to. > 3. hard code the topology of internal LAN into a static route table - > the quick and dirty trick That's one way. Other way: set up firewalls on all clients to filter DHCP requests except from/to the MAC addresses of your own DHCP servers. Another solution would be in the switches: get managed switches (unless you have it already) and filter DHCP requests on all switch ports except the server ports. Filter DHCP, DHCPv6 and ICMPv6 RA (router announcements). I think that's the best solution as it doesn't require any changes on the client nor the server. > if dhcp validation on dhclient is not possible, i will try to hard > code route table. > > So back to my question, can dhclient validate offered address at > all? man dhclient-script >From dhclient.conf: "The script statement is used to specify the pathname of the dhcp client configuration script. This script is used by the dhcp client to set each interface?s initial configuration prior to requesting an address, to test the address once it has been offered, and to set the interface?s final configuration once a lease has been acquired. If no lease is acquired, the script is used to test predefined leases, if any, and also called once if no valid lease can be identified. For more information, see dhclient-script(8)." Gerald From sthaug at nethelp.no Wed Apr 25 06:35:29 2012 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 25 Apr 2012 08:35:29 +0200 (CEST) Subject: enquiry on validation of dhcp offered addres In-Reply-To: <4F973FB2.1070401@gmail.com> References: <4F973FB2.1070401@gmail.com> Message-ID: <20120425.083529.41696219.sthaug@nethelp.no> > Current scripts seems no validation at all. They "trust" everything from DHCP. This is indeed how DHCP is designed to work. If your DHCP server is untrustworthy, it can do a *lot* of damage. And the client cannot protect against all such damage, because it cannot (in general) know whether a DHCP lease is correct or not - it has to trust the server. > I have several ideas in mind: > 1. dhcp validation on dhclient - reject ipv4 class A,B,C private addresses and ipv6 ULA prefix > - i think it is the most "clean" way > 2. validation on network config scripts - reject ipv4 class A,B,C private addresses and ipv6 ULA prefix > - it is quite hard for me, i do not know how to manipulate ipv4 subnet and ipv6 prefix in shell script Rejecting IPv4 private addresses and IPv6 ULA addresses may be correct in *your* configuration - and should be correct in general for Internet connected hosts. It will obviously not be correct in all configurations and therefore cannot be a standard part of dhclient. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From dhcp1 at thehobsons.co.uk Wed Apr 25 07:07:33 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Wed, 25 Apr 2012 08:07:33 +0100 Subject: enquiry on validation of dhcp offered addres In-Reply-To: <4F973FB2.1070401@gmail.com> References: <4F973FB2.1070401@gmail.com> Message-ID: ching wrote: >I have several ideas in mind: >1. dhcp validation on dhclient - reject ipv4 class A,B,C private >addresses and ipv6 ULA prefix > - i think it is the most "clean" way >2. validation on network config scripts - reject ipv4 class A,B,C >private addresses and ipv6 ULA prefix > - it is quite hard for me, i do not know how to manipulate >ipv4 subnet and ipv6 prefix in shell script >3. hard code the topology of internal LAN into a static route table > - the quick and dirty trick There si another way. Simply arrange your network so that intranet traffic does not traverse your outside gateway. I've no idea what your current topology is as you've given no clues, but if internal traffic doesn't go through your external gateway, then the problem disappears. There is probably stuff you can do to split the routing tables - so the internal traffic uses a table the external DHCP cannot influence - but I've no idea where you'd start with that. >So back to my question, can dhclient validate offered address at all? Dunno, you'll have to study the code/scripts and see what happens when. Gerald Vogt wrote: >set up firewalls on all clients to filter DHCP requests except from/to >the MAC addresses of your own DHCP servers. > >Another solution would be in the switches: get managed switches (unless >you have it already) and filter DHCP requests on all switch ports except >the server ports. I'm not sure you've got the essence of the problem here. It's not internal DHCP that's an issue. The problem the OP is looking at is that if the IP/subnet assigned to his outside interface clashes with his internal network, then that will affect the routing table - and may result in the gateway sending "internal" traffic through the outside interface. This would result in some internal devices being unable to communicate with some other devices - only where the traffic goes through the gateway to get between internal networks/subnets, and only where one of the devices is within the subnet falsely allocated to the outside interface, and only where the outside subnet is more specific (longer subnet mask) (or possibly the same) as an internal subnet. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From ameen.shajahan at wipro.com Wed Apr 25 11:08:22 2012 From: ameen.shajahan at wipro.com (ameen.shajahan at wipro.com) Date: Wed, 25 Apr 2012 11:08:22 +0000 Subject: DHCP query Message-ID: Hi, In ISC DHCP-4.2.3 , Is there are any ways to identify that the DHCP process(dhcpd) is hanging on a deadlock or infinite loop , though the process state is running. Is there any interface available or methods available? Regards, Ameen S Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt at spamcop.net Wed Apr 25 11:30:05 2012 From: vogt at spamcop.net (Gerald Vogt) Date: Wed, 25 Apr 2012 13:30:05 +0200 Subject: DHCP query In-Reply-To: References: Message-ID: Send a DHCP request to the server and wait for the answer. That's the best method to find out whether it's responding or not... Gerald On Wednesday, April 25, 2012, wrote: > Hi,**** > > In ISC DHCP-4.2.3 , Is there are any ways to identify that the DHCP > process(dhcpd) is hanging on a deadlock or infinite loop , though the > process state is running.**** > > Is there any interface available or methods available?**** > > ** ** > > Regards,**** > > Ameen S**** > > * Please do not print this email unless it is absolutely necessary. ***** > > The information contained in this electronic message and any attachments > to this message are intended for the exclusive use of the addressee(s) and > may contain proprietary, confidential or privileged information. If you are > not the intended recipient, you should not disseminate, distribute or copy > this e-mail. Please notify the sender immediately and destroy all copies of > this message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient > should check this email and any attachments for the presence of viruses. > The company accepts no liability for any damage caused by any virus > transmitted by this email. > > www.wipro.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thilo.bangert at gmail.com Wed Apr 25 12:22:45 2012 From: thilo.bangert at gmail.com (Thilo Bangert) Date: Wed, 25 Apr 2012 14:22:45 +0200 Subject: DHCP query In-Reply-To: References: Message-ID: <1438300.LV9DuajZP2@gaston> On Wednesday, April 25, 2012 01:30:05 PM Gerald Vogt wrote: > Send a DHCP request to the server and wait for the answer. That's the best > method to find out whether it's responding or not... > and to do that you could use dhcping http://www.mavetju.org/unix/general.php kind regards Thilo > Gerald > > On Wednesday, April 25, 2012, wrote: > > Hi,**** > > > > In ISC DHCP-4.2.3 , Is there are any ways to identify that the DHCP > > process(dhcpd) is hanging on a deadlock or infinite loop , though the > > process state is running.**** > > > > Is there any interface available or methods available?**** > > > > ** ** > > > > Regards,**** > > > > Ameen S**** > > > > * Please do not print this email unless it is absolutely necessary. ***** > > > > The information contained in this electronic message and any attachments > > to this message are intended for the exclusive use of the addressee(s) and > > may contain proprietary, confidential or privileged information. If you > > are > > not the intended recipient, you should not disseminate, distribute or copy > > this e-mail. Please notify the sender immediately and destroy all copies > > of > > this message and any attachments. > > > > WARNING: Computer viruses can be transmitted via email. The recipient > > should check this email and any attachments for the presence of viruses. > > The company accepts no liability for any damage caused by any virus > > transmitted by this email. > > > > www.wipro.com From ptwinn at cimtel.net Wed Apr 25 15:23:51 2012 From: ptwinn at cimtel.net (Patrick Winn) Date: Wed, 25 Apr 2012 10:23:51 -0500 Subject: DHCP query In-Reply-To: References: Message-ID: <4F981707.8080007@cimtel.net> Gerald, You could also use this PHP code I wrote a while back to send a DHCPLEASEQUERY packet to a server and ask it about a lease like 1.1.1.1 or something you know is invalid. This will cause the server to send back a packet stating it has no info on that lease..which in turn shows you it is alive and responding. Then just run a cron job on a remote box or two which lives in a loop that wakes up periodically, sends a DHCPLEASEQUERY packet, then if it gets a response, goes back to sleep. Otherwise, it starts sending out emails to the appropriate admins to say that it's unresponsive. ..or you could be a tad more elaborate and do like I did...write a PHP daemon that stays resident on a remote box and makes use of the class above to talk to the DHCP servers you want to monitor instead of running a cron job. The PHP code for creating/sending DHCPLEASEQUERY packets lives here: http://www.phpclasses.org/package/6621-PHP-Send-queries-to-a-DHCP-server.html Coincidentally, I wrote that class in order to poll the DHCP daemon each time I receive a DHCPREQUEST packet with option-82 info in it in order to get timers, etc. that I otherwise can't get from tailing the leases file. This lends towards better (and database driven) lease tracking.. Enjoy. -------------------------------------- Patrick T. Winn Senior Systems Engineer Cimarron Telephone, Co. Desk: 918-865-3311 x280 Cell: 918-606-6602 On 04/25/2012 06:30 AM, Gerald Vogt wrote: > Send a DHCP request to the server and wait for the answer. That's the > best method to find out whether it's responding or not... > > Gerald > > On Wednesday, April 25, 2012, wrote: > > Hi, > > In ISC DHCP-4.2.3 , Is there are any ways to identify that the > DHCP process(dhcpd) is hanging on a deadlock or infinite loop , > though the process state is running. > > Is there any interface available or methods available? > > Regards, > > Ameen S > > * Please do not print this email unless it is absolutely necessary. * > > The information contained in this electronic message and any > attachments to this message are intended for the exclusive use of > the addressee(s) and may contain proprietary, confidential or > privileged information. If you are not the intended recipient, you > should not disseminate, distribute or copy this e-mail. Please > notify the sender immediately and destroy all copies of this > message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The > recipient should check this email and any attachments for the > presence of viruses. The company accepts no liability for any > damage caused by any virus transmitted by this email. > > www.wipro.com > > > _______________________________________________ > dhcp-users mailing list > dhcp-users at lists.isc.org > https://lists.isc.org/mailman/listinfo/dhcp-users -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From flamana at gmail.com Wed Apr 25 17:34:52 2012 From: flamana at gmail.com (Franz) Date: Wed, 25 Apr 2012 13:34:52 -0400 Subject: on-commit execute a script and update lease end time Message-ID: Hi, This is my first post on this list, i have isc-dhcp-4.2.3 running on FreeBSD 8.1. I give leases of 1 hour to everyone. User need to authenticate against freeradius groups, now each group has a different Session-Timeout in seconds, what I want is on renew, run a script check the session-timeout in the MySQL db and update the end time to now() + session-timeout or reserve that lease for that amount of seconds. Would this require to restart the service everytime or this information can be updated on the fly? What I want to avoid with this is for user A (5 day session-timeout) to loose his ip assignment while he was offline for 2 days and someone else got that ip as it did not respond to ping from dhcp server. Thank you for your answers and suggestions. Franz From bramkuma at cisco.com Wed Apr 25 19:12:35 2012 From: bramkuma at cisco.com (bramkuma) Date: Wed, 25 Apr 2012 12:12:35 -0700 Subject: feeding events to dhcp client state machine Message-ID: Hi Everyone, I?m using the isc-dhcp-4.2.1 source-code. I?ve integrated the dhcp-client as a library whose functions I can call from some applications in my OS (running a customized version of linux). I have 2 questions 1. I want to feed events to the dhcp-client state machine from the outside-system, as a response to some stimuli. How do I go about doing this ? I see the omapi listener objects defined in dhcp_common_objects_setup() under comon/comapi.c, but I don?t see the events getting used anywhere ( For example: dhcp_control_set_value). Can someone throw some light on this ? 2. Also, how do I make the dhcp-client dynamically add and remove interfaces ? I see that the main() goes through a discover_interfaces() call. This flow is actually common to client, server and relay. The only way I can think of doing this is to return without doing discover_interfaces() and then feed events to the state-machine for a new add or remove. Is there a better way to handle this situation ? Thanks Bhuvana -------------- next part -------------- An HTML attachment was scrubbed... URL: From diego at woitasen.com.ar Thu Apr 26 13:05:20 2012 From: diego at woitasen.com.ar (Diego Woitasen) Date: Thu, 26 Apr 2012 10:05:20 -0300 Subject: Set a specific reply address Message-ID: Hi, Is there a way to configure DHCPD to use a specificic source IP address for replies? I have 4 IP addresses in my server and want to use one of them only for DHCP traffic. All the clients in my network are behind routers, which are relays pointing to the right IP address. The problem is that DHCPD is replying with the wrong IP address (the primary on the interface). Regards, Diego -- Diego Woitasen From glenn.satchell at uniq.com.au Thu Apr 26 13:13:50 2012 From: glenn.satchell at uniq.com.au (Glenn Satchell) Date: Thu, 26 Apr 2012 23:13:50 +1000 Subject: Set a specific reply address In-Reply-To: References: Message-ID: > Hi, > Is there a way to configure DHCPD to use a specific source IP > address for replies? I have 4 IP addresses in my server and want to > use one of them only for DHCP traffic. All the clients in my network > are behind routers, which are relays pointing to the right IP address. > The problem is that DHCPD is replying with the wrong IP address (the > primary on the interface). > > Regards, > Diego > > -- > Diego Woitasen I think "server-identifier" might be what you want. It fills in the server's IP address in the right field in the DHCP packet, so that clients will reply to that address. The server-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 reach- able by all clients served by a particular scope. 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 occa- sions 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. There is also "local-address" which changes the behaviour somewhat, but may also help. Note that the code is in older versions, but was only added to the man page more recently. regards, -glenn From lsching17 at gmail.com Thu Apr 26 23:42:26 2012 From: lsching17 at gmail.com (ching) Date: Fri, 27 Apr 2012 07:42:26 +0800 Subject: enquiry on validation of dhcp offered addres In-Reply-To: References: Message-ID: <4F99DD62.5010308@gmail.com> thank you for all the information, i will go for static route table. From vincent.demaertelaere at excentis.com Fri Apr 27 09:22:20 2012 From: vincent.demaertelaere at excentis.com (Vincent De Maertelaere) Date: Fri, 27 Apr 2012 11:22:20 +0200 Subject: ISC Dhcp and CableLabs vendor specific option 2171 Message-ID: <4F9A654C.9020001@excentis.com> Hi, I'm trying to configure the ISC dhcp server (4.2.3) to hand out option 2171 for cable modems. I am using a configuration file like this: option space docsis code width 2 length width 2 hash size 100; option docsis.tftp-servers code 32 = array of ip6-address; option docsis.cablelabs-configuraiton-file code 33 = text; option docsis.syslog-servers code 34 = array of ip6-address; option docsis.time-servers code 37 = array of ip6-address; option docsis.time-offset code 38 = signed integer 32; option docsis.ip-prev code 39 = unsigned integer 8; option space cccv6 code width 2 length width 2 hash size 100; option cccv6.primary-dhcp code 1 = ip6-address; option cccv6.prov-server code 3 = { ingeger 8, text }; option cccv6.krb-realm code 6 = text; option docsis.cccv6 code 2171 = encapsulate cccv6; option vsio.docsis code 4491 = encapsulate docsis; option cccv6.primary-dhcp When I start the DHCP server with this config, it does not complain about the config. But when a device requests option 2171, the server does not include the option 2171 in the vendor specific options. What am I doing wrong? Best Regards, --- Vincent De Maertelaere Excentis N.V. Gildestraat 8 9000 Ghent Belgium From TomSchmitt at gmx.de Fri Apr 27 12:15:30 2012 From: TomSchmitt at gmx.de (Tom Schmitt) Date: Fri, 27 Apr 2012 14:15:30 +0200 Subject: Set a specific reply address In-Reply-To: References: Message-ID: <20120427121530.203380@gmx.net> -------- Original-Nachricht -------- > > Is there a way to configure DHCPD to use a specific source IP > > address for replies? > I think "server-identifier" might be what you want. > There is also "local-address" which changes the behaviour somewhat, but > may also help. I had (actually have) the same problem, tried both and they didn't help. Like Glenn wrote, dhcpd then writes the wanted address in some fields of the DHCP paket, but the IP packet still uses the wrong source IP. I found no way to solve this with dhcpd, you can only work around it on an OS-level. -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a From dhcp1 at thehobsons.co.uk Fri Apr 27 13:06:58 2012 From: dhcp1 at thehobsons.co.uk (Simon Hobson) Date: Fri, 27 Apr 2012 14:06:58 +0100 Subject: Set a specific reply address In-Reply-To: <20120427121530.203380@gmx.net> References: <20120427121530.203380@gmx.net> Message-ID: Tom Schmitt wrote: >I had (actually have) the same problem, tried both and they didn't help. >Like Glenn wrote, dhcpd then writes the wanted address in some >fields of the DHCP paket, but the IP packet still uses the wrong >source IP. Why is that a problem ? As long as it comes out of the right interface, and has the right destination address, then it should work. That is, of course, if your network is properly set up. Now, if you run multiple subnets, with separate routers, and nothing to route between them, then that's a broken network IMO. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. From dhcp at nryc.fr Mon Apr 30 19:06:01 2012 From: dhcp at nryc.fr (Nicolas C.) Date: Mon, 30 Apr 2012 21:06:01 +0200 Subject: "raw packet not available" when execute() on release Message-ID: <4F9EE299.6010305@nryc.fr> Hello, I'm using the "execute" functionality to perform updates in our DNS using a script. The idea is to achieve this : http://www.gelato.unsw.edu.au/IA64wiki/IPv6DDNS It works when DHCP gives an address but it sometimes fails when the lease expires. The error message is "data: hardware: raw packet not available" and the mac address and IPv4 address (needed by my script) are missing. I saw somebody having a similar problem but no answer was given. I'm using the official "isc-dhcp-server" package on Debian Squeeze (4.1.1-P1), maybe this issue is corrected in a newer version of dhcpd? I tried compiling 4.2.3-P2 to test but it fails : comapi.c:878:25: error: variable 'shared_network' set but not used [-Werror=unused-but-set-variable] cc1: all warnings being treated as errors make[2]: *** [comapi.o] Error 1 make[2]: Leaving directory `/usr/src/dhcp-4.2.3-P2/common' Any help on the "execute" or compiling issue? This is quite a problem for me. Regards, Nicolas From bramkuma at cisco.com Mon Apr 30 19:19:20 2012 From: bramkuma at cisco.com (bramkuma) Date: Mon, 30 Apr 2012 12:19:20 -0700 Subject: Resending: feeding events to dhcp client state machine In-Reply-To: Message-ID: Resending this question : Do you have some thoughts on this ? Thanks Bhuvana On 4/25/12 12:12 PM, "bramkuma" wrote: > Hi Everyone, > > I?m using the isc-dhcp-4.2.1 source-code. I?ve integrated the dhcp-client as a > library whose functions I can call from some applications in my OS (running a > customized version of linux). I have 2 questions > > 1. I want to feed events to the dhcp-client state machine from the > outside-system, as a response to some stimuli. How do I go about doing this ? > I see the omapi listener objects defined in dhcp_common_objects_setup() under > comon/comapi.c, but I don?t see the events getting used anywhere ( For > example: dhcp_control_set_value). > > Can someone throw some light on this ? > > 2. Also, how do I make the dhcp-client dynamically add and remove interfaces ? > I see that the main() goes through a discover_interfaces() call. This flow is > actually common to client, server and relay. The only way I can think of doing > this is to return without doing discover_interfaces() and then feed events to > the state-machine for a new add or remove. > > Is there a better way to handle this situation ? > > > Thanks > Bhuvana > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhcp at nryc.fr Mon Apr 30 20:42:37 2012 From: dhcp at nryc.fr (Nicolas C.) Date: Mon, 30 Apr 2012 22:42:37 +0200 Subject: "raw packet not available" when execute() on release In-Reply-To: <4F9EE299.6010305@nryc.fr> References: <4F9EE299.6010305@nryc.fr> Message-ID: <4F9EF93D.2060206@nryc.fr> On 30/04/2012 21:06, Nicolas C. wrote: > I'm using the official "isc-dhcp-server" package on Debian Squeeze > (4.1.1-P1), maybe this issue is corrected in a newer version of dhcpd? I > tried compiling 4.2.3-P2 to test but it fails : > > comapi.c:878:25: error: variable 'shared_network' set but not used > [-Werror=unused-but-set-variable] > cc1: all warnings being treated as errors > > make[2]: *** [comapi.o] Error 1 > make[2]: Leaving directory `/usr/src/dhcp-4.2.3-P2/common' > > Any help on the "execute" or compiling issue? This is quite a problem > for me. Compiling problem solved, I had to delete every occurrence of -Werror in Makefiles after "configure" : find . -name Makefile | xargs sed -e "s/-Werror //" -i DHCPD 4.2.3-P2 is now running, I have to wait & see if my "raw packet not available" error is still there. Nicolas From sar at isc.org Mon Apr 30 21:30:32 2012 From: sar at isc.org (Shawn Routhier) Date: Mon, 30 Apr 2012 14:30:32 -0700 Subject: ISC DHCP 4.1-ESV-R5rc1 is now available Message-ID: <409AFF89-0AD3-458F-AF8A-FBA73029D50B@isc.org> ISC DHCP 4.1-ESV-R5rc1 is now available for download. This is the first release candidate of ISC DHCP 4.1-ESV-R5, a maintenance release which contains many bug fixes including some previously released security patches. A list of the changes in this release has been appended to the end of this message. This release includes changes to the code to allocate and manage IPv6 addresses, please pay particular attention to this area in any testing you do. For a complete list of changes from any previous release, please consult the RELNOTES file within the source distribution, or on our website: http://www.isc.org/software/dhcp/41-esv-r5rc1 This release, and its OpenPGP-signatures are available now from: ftp://ftp.isc.org/isc/dhcp/4.1-ESV-R5rc1/dhcp-4.1-ESV-R5rc1.tar.gz ftp://ftp.isc.org/isc/dhcp/4.1-ESV-R5rc1/dhcp-4.1-ESV-R5rc1.tar.gz.sha512.asc ftp://ftp.isc.org/isc/dhcp/4.1-ESV-R5rc1/dhcp-4.1-ESV-R5rc1.tar.gz.sha256.asc ftp://ftp.isc.org/isc/dhcp/4.1-ESV-R5rc1/dhcp-4.1-ESV-R5rc1.tar.gz.sha1.asc ISC's Release Signing Key can be obtained at: http://www.isc.org/about/openpgp/ Changes since 4.1-ESV-R5b1 - None Changes since 4.1-ESV-R4 - Fixed the code that checks if an address the server is planning to hand out is in a reserved range. This would appear as the server being out of addresses in pools with particular ranges. [ISC-Bugs #26498] - Tidy up the receive calls and eliminate the need for found_pkt [ISC-Bugs #25066] - Add support for Infiniband over sockets to the server and relay code. We've tested this on Solaris and hope to expand support for Infiniband in the future. This patch also corrects some issues we found in the socket code. [ISC-Bugs #24245] - Add a compile time check for the presence of the noreturn attribute and use it for log_fatal if it's available. This will help code checking programs to eliminate false positives. [ISC-Bugs #27539] - Fixed many compilation problems ("set, but not used" warnings) for gcc 4.6 that may affect Ubuntu 11.10 users. [ISC-Bugs #27588] - Remove outdated note in the bootp keyword about the option not satisfying the requirement of failover peers for denying dynamic bootp clients. [ISC-bugs #28574] - Multiple items to clean up IPv6 address processing. When processing an IA that we've seen check to see if the addresses are usable (not in use by somebody else) before handing it out. When reading in leases from the file discard expired addresses. When picking an address for a client include the IA ID in addition to the client ID to generally pick different addresses for different IAs. [ISC-Bugs #23138] [ISC-Bugs #27945] [ISC-Bugs #25586] [ISC-Bugs #27684] - Remove unnecessary checks in the lease query code and clean up several compiler issues (some dereferences of NULL and treating an int as a boolean). [ISC-Bugs #26203] - Fix the NA and PD allocation code to handle the case where a client provides a preference and the server doesn't have any addresses or prefixes available. Previoulsy the server ignored the request with this patch it replies with a NoAddrsAvail or NoPrefixAvai respone. By default the code performs according to the errata of August 2010 for RFC 3315 section 17.2.2, to enable the previous style see the seciton on RFC3315_PRE_ERRATA_2010_08 in includes/site.h. This option may be removed in the future. Thanks to Jiri Popelka at Red Hat for the patch. [ISC-Bugs #22676] - Fix up some issues found by static analysis A potential memory leak and NULL dereference in omapi. The use of a boolean test instead of a bitwise test in dst. [ISC-Bugs #28941] From sar at isc.org Mon Apr 30 21:50:56 2012 From: sar at isc.org (Shawn Routhier) Date: Mon, 30 Apr 2012 14:50:56 -0700 Subject: ISC DHCP 4.2.4rc1 is now available Message-ID: ISC DHCP 4.2.4rc1 is now available for download. This is the first release candidate of ISC DHCP 4.2.4, a maintenance release which contains many bug fixes including some previously released security patches. This release of ISC DHCP 4.2.4rc1 includes source code from ISC BIND 9.8.2, which has been recently found to contain a bug that can cause a segmentation fault. (Please see the advisory at: https://kb.isc.org/article/AA-00664 ) The BIND bug does not affect the portions of code used by DHCP, but can affect recursive resolvers. As a result, the copy of BIND provided with this distribution of DHCP source should not be used to build standalone DNS programs but only to produce the server and utilities built by the DHCP package. If you need to build BIND for recursive nameservice purposes, please download a version from http://www.isc.org/software/bind ISC is producing a new release to replace BIND 9.8.2 but it was not available in time to meet the schedule for this release. We shall release another release candidate (rc2) containing the corrected version of BIND when the updated BIND tarball is available. A list of the changes in this release has been appended to the end of this message. This release includes changes to the code to allocate and manage IPv6 addresses, please pay particular attention to this area in any testing you do. For a complete list of changes from any previous release, please consult the RELNOTES file within the source distribution, or on our website: http://www.isc.org/software/dhcp/424rc1 This release, and its OpenPGP-signatures are available now from: ftp://ftp.isc.org/isc/dhcp/4.2.4rc1/dhcp-4.2.4rc1.tar.gz ftp://ftp.isc.org/isc/dhcp/4.2.4rc1/dhcp-4.2.4rc1.tar.gz.sha512.asc ftp://ftp.isc.org/isc/dhcp/4.2.4rc1/dhcp-4.2.4rc1.tar.gz.sha256.asc ftp://ftp.isc.org/isc/dhcp/4.2.4rc1/dhcp-4.2.4rc1.tar.gz.sha1.asc ISC's Release Signing Key can be obtained at: http://www.isc.org/about/openpgp/ Changes since 4.2.4b1 - None Changes since 4.2.3 ! Add a check for a null pointer before calling the regexec function. Without this check we could, under some circumstances, pass a null pointer to the regexec function causing it to segfault. Thanks to a report from BlueCat Networks. [ISC-Bugs #26704]. CVE: CVE-2011-4539 ! Modify the DDNS handling code. In a previous patch we added logging code to the DDNS handling. This code included a bug that caused it to attempt to dereference a NULL pointer and eventually segfault. While reviewing the code as we addressed this problem, we determined that some of the updates to the lease structures would not work as planned since the structures being updated were in the process of being freed: these updates were removed. In addition we removed an incorrect call to the DDNS removal function that could cause a failure during the removal of DDNS information from the DNS server. Thanks to Jasper Jongmans for reporting this issue. [ISC-Bugs #27078] CVE: CVE-2011-4868 - Fixed the code that checks if an address the server is planning to hand out is in a reserved range. This would appear as the server being out of addresses in pools with particular ranges. [ISC-Bugs #26498] - In the DDNS code handle error conditions more gracefully and add more logging code. The major change is to handle unexpected cancel events from the DNS client code. [ISC-Bugs #26287]. - Tidy up the receive calls and eliminate the need for found_pkt [ISC-Bugs #25066] - Add support for Infiniband over sockets to the server and relay code. We've tested this on Solaris and hope to expand support for Infiniband in the future. This patch also corrects some issues we found in the socket code. [ISC-Bugs #24245] - Add a compile time check for the presence of the noreturn attribute and use it for log_fatal if it's available. This will help code checking programs to eliminate false positives. [ISC-Bugs #27539] - Fixed many compilation problems ("set, but not used" warnings) for gcc 4.6 that may affect Ubuntu 11.10 users. [ISC-Bugs #27588] - Modify the code that determines if an outstanding DDNS request should be cancelled. This patch results in cancelling the outstanding request less often. It fixes the problem caused by a client doing a release where the txt and ptr records weren't removed from the DNS. [ISC-BUGS #27858] - Use offsetof() instead of sizeof() to get the sizes for dhcpv6_relay_packet and dhcpv6_packet in several more places. Thanks to a report from Bruno Verstuyft and Vincent Demaertelaere of Excentis. [ISC-Bugs #27941] - Remove outdated note in the bootp keyword about the option not satisfying the requirement of failover peers for denying dynamic bootp clients. [ISC-bugs #28574] - Multiple items to clean up IPv6 address processing. When processing an IA that we've seen check to see if the addresses are usable (not in use by somebody else) before handing it out. When reading in leases from the file discard expired addresses. When picking an address for a client include the IA ID in addition to the client ID to generally pick different addresses for different IAs. [ISC-Bugs #23138] [ISC-Bugs #27945] [ISC-Bugs #25586] [ISC-Bugs #27684] - Remove unnecessary checks in the lease query code and clean up several compiler issues (some dereferences of NULL and treating an int as a boolean). [ISC-Bugs #26203] - Fix the NA and PD allocation code to handle the case where a client provides a preference and the server doesn't have any addresses or prefixes available. Previoulsy the server ignored the request with this patch it replies with a NoAddrsAvail or NoPrefixAvai respone. By default the code performs according to the errata of August 2010 for RFC 3315 section 17.2.2, to enable the previous style see the seciton on RFC3315_PRE_ERRATA_2010_08 in includes/site.h. This option may be removed in the future. Thanks to Jiri Popelka at Red Hat for the patch. [ISC-Bugs #22676] - Fix up some issues found by static analysis A potential memory leak and NULL dereference in omapi. The use of a boolean test instead of a bitwise test in dst. [ISC-Bugs #28941] -------------- next part -------------- An HTML attachment was scrubbed... URL: