Bug Tracking System

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001050PacketFencecaptive portalpublic2010-08-24 13:532015-02-13 15:26
Assigned Toobilodeau 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0001050: Force DHCP to send DHCPNACKs to client that juste changed VLAN that insist on getting an invalid IP
DescriptionProblem description:

In /var/log/messages you see errors like:

dhcpd: DHCPREQUEST for <IP> from <MAC> via eth1: unknown lease <IP>.

This will happen with some devices when they are moved from a production VLAN into a registration or isolation VLAN in a non IP-Helper setup. The device will do it's REQUEST with the prod IP and the dhcpd will say unknown because it's not under it's authority.

By default ISC's dhcpd will not reply with a DHCPNACK to allow several dhcp servers to co-exist on the same LAN without NACKin' each other. This is not the usual PacketFence setup so we can be more aggressive on NACKin' the clients.

To solve the problem, we need to deny production scopes

For example, add the following to /etc/dhcpd.conf:

subnet netmask {
  pool {
    deny all clients;

where production network is

A proper implementation would be to alter the dhcpd.conf template so it will automatically generate such a config.

See [^] for details.
TagsNo tags attached.
fixed in git revision
fixed in mtn revision
Attached Files

- Relationships
related to 0001132resolvedobilodeau Mac OS X DHCP issues after a VLAN change on wireless networks 

-  Notes
obilodeau (reporter)
2010-09-02 01:53

Problem reproduced today, switching was longer than supposed to. Windows apparently does 3 DHCPREQUEST first with it's old IP before going back to a DHCPDISCOVER so it takes longer to get an IP.

Problem was worse due to the fact that all DHCP scopes (prod and pf's) were running on the same server.

we should look into having a shared {} statement that would bind tightly to an interface and NACK everything else in order to provide faster switching from VLAN
2011-04-19 11:04

quick update... example of syntax for the deny all clients... : a pool must be define to allow a NACK...

subnet netmask {

        option routers;
        option subnet-mask;
        option broadcast-address;

        pool {
                deny all clients;
        pool {

fgaudreault (viewer)
2011-09-09 15:38

Just doing some round up on tickets.

This issue will only happen if PF is the production DHCP or if you switch between registration <-> isolation.

I think we should only care about the registration<-> isolation part, and make the proper changes in the dhcpd.conf template. You are technically not supposed to use PF as your enterprise server.
fgaudreault (viewer)
2011-09-12 15:46

It will imply to change the way we start dhcpd process, and build the configuration.

Won't be for 3.0.
lmunro (administrator)
2015-02-13 15:26

Old issues.
Most are not relevant to PF 4 and up.

Let's reopen the ones that matter when we move to github.

- Issue History
Date Modified Username Field Change
2010-08-24 13:53 obilodeau New Issue
2010-08-24 13:53 obilodeau Status new => assigned
2010-08-24 13:53 obilodeau Assigned To => obilodeau
2010-09-02 01:53 obilodeau Note Added: 0001637
2010-11-19 14:25 obilodeau Target Version 1.10.0 => 2.0.0
2010-12-01 12:07 obilodeau Relationship added related to 0001132
2011-01-18 09:47 obilodeau Target Version 2.0.0 => 2.1.0
2011-03-03 15:15 obilodeau Target Version 2.1.0 => +1
2011-03-03 15:18 obilodeau Target Version +1 => +2
2011-04-19 11:04 user201 Note Added: 0002033
2011-09-09 15:38 fgaudreault Note Added: 0002193
2011-09-12 15:46 fgaudreault Note Added: 0002197
2015-02-13 15:26 lmunro Note Added: 0003727
2015-02-13 15:26 lmunro Status assigned => closed

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker