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
