PacketFence - BTS - PacketFence
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001050PacketFencecaptive portalpublic2010-08-24 13:532015-02-13 15:26
Reporterobilodeau 
Assigned Toobilodeau 
PrioritynormalSeverityminorReproducibilityrandom
StatusclosedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
fixed in git revision
fixed in mtn revision
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 192.168.0.0 netmask 255.255.255.0 {
  pool {
    range 192.168.0.1 192.168.0.255;
    deny all clients;
  }
}

where production network is 192.168.0.0/24.

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

See http://www.isc.org/files/auth.html [^] for details.
Steps To Reproduce
Additional Information
TagsNo tags attached.
Relationships
related to 0001132resolved obilodeau Mac OS X DHCP issues after a VLAN change on wireless networks 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2010-08-24 13:53obilodeauNew Issue
2010-08-24 13:53obilodeauStatusnew => assigned
2010-08-24 13:53obilodeauAssigned To => obilodeau
2010-09-02 01:53obilodeauNote Added: 0001637
2010-11-19 14:25obilodeauTarget Version1.10.0 => 2.0.0
2010-12-01 12:07obilodeauRelationship addedrelated to 0001132
2011-01-18 09:47obilodeauTarget Version2.0.0 => 2.1.0
2011-03-03 15:15obilodeauTarget Version2.1.0 => +1
2011-03-03 15:18obilodeauTarget Version+1 => +2
2011-04-19 11:04user201Note Added: 0002033
2011-09-09 15:38fgaudreaultNote Added: 0002193
2011-09-12 15:46fgaudreaultNote Added: 0002197
2015-02-13 15:26lmunroNote Added: 0003727
2015-02-13 15:26lmunroStatusassigned => closed

Notes
(0001637)
obilodeau   
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
(0002033)
user201   
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 192.168.61.0 netmask 255.255.255.0 {

        option routers 192.168.61.1;
        option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.61.255;

        pool {
                range 192.168.61.0 192.168.61.40;
                deny all clients;
        }
        pool {
                range 192.168.61.41 192.168.61.199;

        }
}
(0002193)
fgaudreault   
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.
(0002197)
fgaudreault   
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.
(0003727)
lmunro   
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.