Hello Paul, i think 12s is really to short and i remember that some device doesn't support it (lower than 30s) and are not able to use the ip address sent by the dhcp server.
In my opinion raise the dhcp lease time and retry. Also do you have any log in the device about the dhcp ? Regards Fabrice Le 2016-08-26 à 09:24, Paul Coates a écrit : > We are preparing PacketFence ready for the start of term running various > tests and have come across a reproducible fault. After successfully > registering via the captive portal we unplug the test laptops network > cable, use the admin site to de-register it, wait a bit (between a few > seconds and a few minutes) then plug the test laptop back in to go > through the process again (without rebooting). Almost everytime we end > up with a 169.254 address on the laptop. Unplugging then replugging the > network cable again ends up assigning the correct address on the > registration vlan, and the registration process goes on to succeed. > > A wireshark of the traffic shows the sequence of events seems to be that > the PC initially starts using its last successfully obtained DHCP IP > address. In the case of a PC that has been deregistered this is an > address on the registered user network, this fails because the switch > port it connects to is now in the registration vlan. After a few seconds > the PC gives up and goes through the DHCP > Discover/Offer/Request/Acknowledgement process and is successfully > allocated an IP address on the registration VLAN along with the correct > gateway and the IP address of the PF server as DNS. Our DHCP lease time > is set low at 12 seconds for the registration vlan. > > Initially it looks like the captive portal process is going to work, > sometimes the Captive portal web page even starts up automatically, > however, this is as far as you can get because at this point the PC > stops using the DHCP IP and reverts back to the automatic 169.254.x.x > address that Windows uses when it can’t get an IP address by any other > means. > > Immediately before the change to the 169 address there are a number of > TLSv1.2 encrypted alerts with ‘Content Type: Alert (21)’ sent from the > PF server to the client. From what I can gather these alerts will result > in the termination of the associated SSL session but don’t know why this > would also cause the laptop to ‘lose’ its IP address. > > Disconnecting the laptop, waiting 15-20 seconds and reconnecting usually > resolves the problem with the laptop going through the DHCP process > again and the captive portal page opening automatically, allowing the > registration process to proceed. > > We are testing with Windows 10 laptops on PacketFence 6.0.3 (OOB/MAC > Auth) running on a fresh CentOS 6 install. We have tried both DHCP > running alone on PacketFence, and with it running on PacketFence along > side our central servers with identical results. > > Is this normal behaviour? We believe this is an edge case and won't hit > most users since they won't be registering/deregistering/registering > devices, but we are seeing it as testers. > > Paul > > -- > > Paul Coates, Newcastle University, Network Team > > > ------------------------------------------------------------------------------ > _______________________________________________ > PacketFence-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/packetfence-users ------------------------------------------------------------------------------ _______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
