Hello Ian, Do you happen to have the https://www.packetfence.org/doc/PacketFence_Installation_Guide.html#_dhcp_remote_sensor <https://www.packetfence.org/doc/PacketFence_Installation_Guide.html#_dhcp_remote_sensor> installed on your DHCP server?
On a side note, what is the DHCP max lease time in your registration network ? Thanks, Ludovic Zammit Product Support Engineer Principal Lead Cell: +1.613.670.8432 Akamai Technologies - Inverse 145 Broadway Cambridge, MA 02142 Connect with Us: <https://community.akamai.com/> <http://blogs.akamai.com/> <https://twitter.com/akamai> <http://www.facebook.com/AkamaiTechnologies> <http://www.linkedin.com/company/akamai-technologies> <http://www.youtube.com/user/akamaitechnologies?feature=results_main> > On Jan 19, 2023, at 12:37 AM, Ian MacDonald via PacketFence-users > <packetfence-users@lists.sourceforge.net> wrote: > > Well, > > I guess we are stuck without more insight on how to get the iPhone to update > it's IP after the WiFi disconnect/reconnect to the Default VLAN. > > The only scenario I can think of, is that the iPhone believes it is on the > same network, and behaves like it is moving between different ESSIDs on a > mesh network which would not initiate a DHCP request; which isn't the case > here. > > I wonder if we plugged the iPhone into a USB dongle and tried the same thing > on a wired connection, if it would behave the same way.I'm not going to test > this as it doesn't solve anything. > > Ideas > > - shorten registration DHCP to inside the captive portal delay seems like a > good option to try > - I am wondering if there is any way I can get our DHCP server to respond to > the request we saw from the iPhone on the old registration VLAN .. that may > have actually been due to the lease expiring; at 30s as you suggested it may > be configured. Hopefully expiring at 10s before the disconnect creates a > DISCOVER rather than request for refresh on old registration VLAN subnet to a > DHCP server that is unreachable > - I am wondering if there is any signal PF can send after registration via > captive portal URL to help - like tell it to behave like an old device > - I am thinking maybe including a forced redirect URL in the connection > profile might help the trigger - I don't quite understand how it is passed, > but must be from the portal server URL to exist after the VLAN switch > - double check there are no authoritative setting for DHCP on my Default > network that would allow it to signal to the iPhone when it sees any DHCP > traffic, like the frame you saw requesting a URL. > - is there a wifi feature we can turn off at a lower layer that would ensure > all wifi disconnects are treated like an interface up/down - like disabling > roaming features on the AP > > Maybe the PF team are aware of this scenario; it would be nice to know we are > near the end of the road. > > Any help appreciated > > Cheers, > Ian > > > On Wed., Jan. 18, 2023, 10:57 p.m. Diego Garcia del Rio, <garc...@gmail.com > <mailto:garc...@gmail.com>> wrote: > Hi Ian > > thanks for the extremely thorough troubleshooting. > > Its very weird that the client is not requesting dhcp after re-connecting. On > the AP side, it seems like its disconnecting the client, so im surprised its > not doing a new DHCP request, > > An option you might have is to change the dhcp lease time of the registration > server. By default, its setup for 30 seconds, but it _might_ be editable.. I > would try setting it for maybe 10 seconds? > > the client is requesting the dhcp option 114 (you can see the mention to > "URL" in the dhcp capture below) > Parameter-Request Option 55, length 9: > Subnet-Mask, Classless-Static-Route, Default-Gateway, Domain-Name-Server > Domain-Name, Option 108, URL, Option 119 > Option 252 > > > And your reply is correct... (with the urn saying no portal/unrestricted) > > also, regarding iphone 7..it can go up to IOS15, and the captive portal url > via dhcp was added in IOS14, so the fact it matches newer iphones is not as > strange... > > Unfortunately, I dont think PF can issue dhcp disconnects (and most clients > ignore it). (It would actually be a "FORCERENEW" message from the server, but > it would still be a race condition against the radius disconnect) > > > > > > > > On Thu, Jan 19, 2023 at 3:27 AM Ian MacDonald via PacketFence-users > <packetfence-users@lists.sourceforge.net > <mailto:packetfence-users@lists.sourceforge.net>> wrote: > Hello PF, > > I have started a new thread after posting to "Newer Model iPhones and Android > Devices showing MAC:0 in Captive Portal" as the problem we are having seems > to be different then we initially described, and we have modified our > configuration to resolve some related potential issues along the way. Thanks > Diego for some insights that helped us narrow our problem scope and eliminate > a few potential other causes. > > Our narrowed down problem scope seems to be that some devices (iPhone 7, > iPhone 12 Pro) are not are not properly requesting a new DHCP lease on the > Default network after they have been WiFi disconnected from the Registration > VLAN and reconnected to the Default VLAN. Details follow as well as some > logs from a recent capture of an iPhone 12 Pro. We see identical behaviour > on iPhone 7. This issue does not seem to impact the iPhone 5s and Samsung > Galaxy S10. > > We are wondering if there is more PF can do on the Registration VLAN, like a > DHCP Release to help clients be ready when they arrive on the Default VLAN. > > Our PF setup in the lab where we are having issues is described in the > diagram below > <image.png> > [fencing] > wait_for_redirect = 25 > [captive_portal] > network_redirect_delay=35s > [interface eth0] > type=management,portal > mask=255.255.255.0 > ip=10.2.1.2 > [interface eth1] > type=internal > mask=255.255.255.0 > ip=10.2.2.2 > enforcement=vlan > [interface eth2] > enforcement=vlan > ip=10.2.3.2 > mask=255.255.255.0 > type=internal > > The process starts with an Unregistered node, and no remembered local wifi > networks on the iPhone 12 Pro. The events happen as follows: > > First we connect the PF4_Office:TestOne_WiFi SSID where the device connects > to VLAN 81 and is presented the Registration portal page with AUP and a > prompt for email based authentication. > On the NAS/AP we see the established connection: > > Wed Jan 18 14:54:55 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 RADIUS: VLAN ID 81 > Wed Jan 18 14:54:55 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 IEEE 802.11: authenticated > Wed Jan 18 14:54:55 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 IEEE 802.11: associated (aid 2) > Wed Jan 18 14:54:55 2023 daemon.notice hostapd: wlan0: AP-STA-CONNECTED > f2:ef:bb:22:8c:62 > Wed Jan 18 14:54:55 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 RADIUS: starting accounting session > 2DB2C59D34BD1998 > > And on our management network the matching authorized RADIUS messages between > the NAS/AP and PF server on our management network > 14:54:55.204084 IP 10.2.1.11.49421 > 10.2.1.2.1812: RADIUS, Access-Request > (1), id: 0x1c length: 164 > 14:54:55.251883 IP 10.2.1.2.1812 > 10.2.1.11.49421: RADIUS, Access-Accept > (2), id: 0x1c length: 36 > 14:54:55.261410 IP 10.2.1.11.48577 > 10.2.1.2.1813: RADIUS, > Accounting-Request (4), id: 0x1d length: 182 > 14:54:55.263588 IP 10.2.1.2.1813 > 10.2.1.11.48577: RADIUS, > Accounting-Response (5), id: 0x1d length: 35 > > In our packetfence logs we see the client connect to to the registration vlan > 81 and match our connection profile by ssid TestOne_WiFi > Jan 18 14:54:55 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] handling radius autz request: from switch_ip => > (10.2.1.11), connection_type => Wireless-802.11-NoEAP,switch_mac => > (ec:08:6b:6a:63:5a), mac => [f2:ef:bb:22:8c:62], port => 0, username => > "f2efbb228c62", ssid => TestOne_WiFi (pf::radius::authorize) > Jan 18 14:54:55 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] Instantiate profile Test_WiFi > (pf::Connection::ProfileFactory::_from_profile) > Jan 18 14:54:55 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] is of status unreg; belongs into registration VLAN > (pf::role::getRegistrationRole) > Jan 18 14:54:55 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] (10.2.1.11) Added VLAN 81 to the returned RADIUS > Access-Accept (pf::Switch::returnRadiusAccessAccept) > Jan 18 14:54:55 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] Updating locationlog from accounting request > (pf::api::handle_accounting_metadata) > Jan 18 14:54:59 pf4 pfqueue[64840]: pfqueue(64840) INFO: > [mac:f2:ef:bb:22:8c:62] Sending a firewall SSO 'Update' request for MAC > 'f2:ef:bb:22:8c:62' and IP '10.2.2.178' (pf::firewallsso::do_sso) > Jan 18 14:54:59 pf4 pfqueue[64840]: pfqueue(64840) WARN: > [mac:f2:ef:bb:22:8c:62] Unable to match MAC address to IP '10.2.2.178' > (pf::ip4log::ip2mac) > Jan 18 14:54:59 pf4 pfqueue[65681]: pfqueue(65681) INFO: > [mac:f2:ef:bb:22:8c:62] Instantiate profile Test_WiFi > (pf::Connection::ProfileFactory::_from_profile) > Jan 18 14:54:59 pf4 pfqueue[64476]: pfqueue(64476) WARN: > [mac:f2:ef:bb:22:8c:62] Unable to pull accounting history for device > f2:ef:bb:22:8c:62. The history set doesn't exist yet. > (pf::accounting_events_history::latest_mac_history) > Jan 18 14:54:59 pf4 pfqueue[64476]: pfqueue(64476) WARN: > [mac:f2:ef:bb:22:8c:62] Unable to pull accounting history for device > f2:ef:bb:22:8c:62. The history set doesn't exist yet. > (pf::accounting_events_history::latest_mac_history) > Jan 18 14:55:01 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(94) INFO: > [mac:f2:ef:bb:22:8c:62] Instantiate profile Test_WiFi > (pf::Connection::ProfileFactory::_from_profile) > Jan 18 14:55:02 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(96) INFO: > [mac:f2:ef:bb:22:8c:62] Instantiate profile Test_WiFi > (pf::Connection::ProfileFactory::_from_profile) > Jan 18 14:55:02 pf4 pfqueue[64520]: pfqueue(64520) WARN: > [mac:f2:ef:bb:22:8c:62] Unable to pull accounting history for device > f2:ef:bb:22:8c:62. The history set doesn't exist yet. > (pf::accounting_events_history::latest_mac_history) > Jan 18 14:55:02 pf4 pfqueue[64469]: pfqueue(64469) WARN: > [mac:f2:ef:bb:22:8c:62] Unable to pull accounting history for device > f2:ef:bb:22:8c:62. The history set doesn't exist yet. > (pf::accounting_events_history::latest_mac_history) > Jan 18 14:55:09 pf4 pfperl-api-docker-wrapper[1130]: pfperl-api(17) INFO: > [mac:[undef]] Using 300 resolution threshold > (pf::pfcron::task::cluster_check::run) > Jan 18 14:55:09 pf4 pfperl-api-docker-wrapper[1130]: pfperl-api(17) INFO: > [mac:[undef]] All cluster members are running the same configuration version > (pf::pfcron::task::cluster_check::run) > Jan 18 14:55:10 pf4 pfperl-api-docker-wrapper[1130]: pfperl-api(17) INFO: > [mac:[undef]] processed 0 security_events during security_event maintenance > (1674071710.15351 1674071710.16509) > (pf::security_event::security_event_maintenance) > Jan 18 14:55:10 pf4 pfperl-api-docker-wrapper[1130]: pfperl-api(17) INFO: > [mac:[undef]] getting security_events triggers for accounting cleanup > (pf::accounting::acct_maintenance) > Jan 18 14:55:12 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(96) INFO: > [mac:f2:ef:bb:22:8c:62] Instantiate profile Test_WiFi > (pf::Connection::ProfileFactory::_from_profile) > Jan 18 14:55:12 pf4 pfqueue[64520]: pfqueue(64520) WARN: > [mac:f2:ef:bb:22:8c:62] Unable to pull accounting history for device > f2:ef:bb:22:8c:62. The history set doesn't exist yet. > (pf::accounting_events_history::latest_mac_history) > > We can see the Registration VLAN portal interactions for the client on > 10.2.2.178 > Jan 18 14:55:00 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:54627 > <https://urldefense.com/v3/__http://10.2.2.178:54627__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gGQik2ThQ$> > [18/Jan/2023:14:55:00.140] portal-http-10.2.1.2 proxy/proxy 0/0/0/452/452 > 200 644 - - ---- 2/1/0/0/0 0/0 {captive.apple.com > <https://urldefense.com/v3/__http://captive.apple.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gHRHamHbA$>} > "GET /hotspot-detect.html HTTP/1.0" > Jan 18 14:55:01 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62360 > <https://urldefense.com/v3/__http://10.2.2.178:62360__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gGz9sN7cg$> > [18/Jan/2023:14:55:01.513] portal-http-10.2.1.2 proxy/proxy 0/0/1/5/6 200 > 644 - - ---- 2/1/0/0/0 0/0 {captive.apple.com > <https://urldefense.com/v3/__http://captive.apple.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gHRHamHbA$>} > "GET /hotspot-detect.html HTTP/1.1" > Jan 18 14:55:01 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:54632 > <https://urldefense.com/v3/__http://10.2.2.178:54632__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gE3JIlG9g$> > [18/Jan/2023:14:55:01.538] portal-http-10.2.1.2 proxy/proxy 0/0/0/4/4 200 > 644 - - ---- 3/2/0/0/0 0/0 {captive.apple.com > <https://urldefense.com/v3/__http://captive.apple.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gHRHamHbA$>} > "GET /hotspot-detect.html HTTP/1.0" > Jan 18 14:55:01 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62361 > <https://urldefense.com/v3/__http://10.2.2.178:62361__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gFD5Fmauw$> > [18/Jan/2023:14:55:01.762] portal-https-10.2.1.2~ > 10.2.1.2-backend/containers-gateway.internal:8080 0/0/1/138/139 200 6858 - - > ---- 3/1/0/0/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET > /captive-portal?destination_url=http://captive.apple.com/hotspot-detect.html > <https://urldefense.com/v3/__http://captive.apple.com/hotspot-detect.html__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gE5Gbm3cA$> > HTTP/1.1" > Jan 18 14:55:01 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62361 > <https://urldefense.com/v3/__http://10.2.2.178:62361__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gFD5Fmauw$> > [18/Jan/2023:14:55:01.930] portal-https-10.2.1.2~ static/static 0/0/0/1/1 > 200 42006 - - ---- 4/1/0/0/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET /common/styles.css HTTP/1.1" > Jan 18 14:55:02 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62364 > <https://urldefense.com/v3/__http://10.2.2.178:62364__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gGesjoB7g$> > [18/Jan/2023:14:55:02.003] portal-https-10.2.1.2~ static/static 0/0/0/1/2 > 200 20248 - - ---- 8/5/0/0/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET /common/qrcode.min.js HTTP/1.1" > Jan 18 14:55:02 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62365 > <https://urldefense.com/v3/__http://10.2.2.178:62365__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gHmYPBwLg$> > [18/Jan/2023:14:55:02.016] portal-https-10.2.1.2~ static/static 0/0/1/1/2 > 200 1506 - - ---- 8/5/0/0/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET /common/jquery-shim.js HTTP/1.1" > Jan 18 14:55:02 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62362 > <https://urldefense.com/v3/__http://10.2.2.178:62362__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gH3lpCqUg$> > [18/Jan/2023:14:55:02.019] portal-https-10.2.1.2~ static/static 0/0/0/1/1 > 200 6157 - - ---- 8/5/1/1/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET /common/pf.js HTTP/1.1" > Jan 18 14:55:02 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62363 > <https://urldefense.com/v3/__http://10.2.2.178:62363__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gGuhAhkdg$> > [18/Jan/2023:14:55:02.019] portal-https-10.2.1.2~ static/static 0/0/0/2/2 > 200 8239 - - ---- 8/5/0/0/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET /content/captiveportal.js HTTP/1.1" > Jan 18 14:55:02 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62361 > <https://urldefense.com/v3/__http://10.2.2.178:62361__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gFD5Fmauw$> > [18/Jan/2023:14:55:02.027] portal-https-10.2.1.2~ static/static 0/0/0/1/1 > 200 4480 - - ---- 8/5/0/0/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET /common/packetfence-cp.png HTTP/1.1" > Jan 18 14:55:02 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62365 > <https://urldefense.com/v3/__http://10.2.2.178:62365__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gHmYPBwLg$> > [18/Jan/2023:14:55:02.033] portal-https-10.2.1.2~ static/static 0/0/0/2/2 > 200 39912 - - ---- 8/5/0/0/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET /common/img/sprite.svg HTTP/1.1" > Jan 18 14:55:02 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62364 > <https://urldefense.com/v3/__http://10.2.2.178:62364__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gGesjoB7g$> > [18/Jan/2023:14:55:02.032] portal-https-10.2.1.2~ > 10.2.1.2-backend/containers-gateway.internal:8080 0/0/0/58/58 200 852 - - > ---- 8/5/0/0/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "POST /record_destination_url HTTP/1.1" > Jan 18 14:55:04 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:54633 > <https://urldefense.com/v3/__http://10.2.2.178:54633__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gGxd_zGdg$> > [18/Jan/2023:14:55:01.930] portal-http-10.2.1.2 proxy/proxy 0/0/0/2671/2671 > 200 644 - - ---- 8/2/0/0/0 0/0 {captive.apple.com > <https://urldefense.com/v3/__http://captive.apple.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gHRHamHbA$>} > "GET /hotspot-detect.html HTTP/1.0" > > In our packetfence.log, the client sends the email address from the > Registration Portal page that appears on the iPhone and the VLAN reevaluation > is started > Jan 18 14:55:13 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(96) INFO: > [mac:f2:ef:bb:22:8c:62] User endu...@gmail.com <mailto:endu...@gmail.com> has > authenticated on the portal. > (captiveportal::PacketFence::DynamicRouting::Module::_username_set) > Jan 18 14:55:13 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(96) INFO: > [mac:f2:ef:bb:22:8c:62] new activation code successfully generated > (pf::activation::create) > Jan 18 14:55:13 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(96) WARN: > [mac:f2:ef:bb:22:8c:62] Calling match with empty/invalid rule class. > Defaulting to 'authentication' (pf::authentication::match) > Jan 18 14:55:13 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(96) INFO: > [mac:f2:ef:bb:22:8c:62] Using sources email for matching > (pf::authentication::match) > Jan 18 14:55:13 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(96) INFO: > [mac:f2:ef:bb:22:8c:62] Matched rule (catchall) in source email, returning > actions. (pf::Authentication::Source::match_rule) > Jan 18 14:55:13 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(96) INFO: > [mac:f2:ef:bb:22:8c:62] Matched rule (catchall) in source email, returning > actions. (pf::Authentication::Source::match) > Jan 18 14:55:13 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(96) INFO: > [mac:f2:ef:bb:22:8c:62] Using sources email for matching > (pf::authentication::match) > Jan 18 14:55:13 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(96) INFO: > [mac:f2:ef:bb:22:8c:62] security_event 1300003 force-closed for > f2:ef:bb:22:8c:62 (pf::security_event::security_event_force_close) > Jan 18 14:55:13 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(96) INFO: > [mac:f2:ef:bb:22:8c:62] Instantiate profile Test_WiFi > (pf::Connection::ProfileFactory::_from_profile) > Jan 18 14:55:13 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(95) INFO: > [mac:f2:ef:bb:22:8c:62] Instantiate profile Test_WiFi > (pf::Connection::ProfileFactory::_from_profile) > Jan 18 14:55:13 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(95) WARN: > [mac:f2:ef:bb:22:8c:62] locale from the URL is not supported > (captiveportal::PacketFence::Controller::Root::getLanguages) > Jan 18 14:55:13 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(95) INFO: > [mac:f2:ef:bb:22:8c:62] Releasing device > (captiveportal::PacketFence::DynamicRouting::Module::Root::release) > Jan 18 14:55:13 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(95) INFO: > [mac:f2:ef:bb:22:8c:62] re-evaluating access (manage_register called) > (pf::enforcement::reevaluate_access) > Jan 18 14:55:13 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(95) INFO: > [mac:f2:ef:bb:22:8c:62] Instantiate profile Test_WiFi > (pf::Connection::ProfileFactory::_from_profile) > Jan 18 14:55:13 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(95) INFO: > [mac:f2:ef:bb:22:8c:62] VLAN reassignment is forced. > (pf::enforcement::_should_we_reassign_vlan) > Jan 18 14:55:13 pf4 httpd.portal-docker-wrapper[4460]: httpd.portal(95) INFO: > [mac:f2:ef:bb:22:8c:62] switch port is (10.2.1.11) ifIndex 0connection type: > WiFi MAC Auth (pf::enforcement::_vlan_reevaluation) > Jan 18 14:55:13 pf4 pfqueue[64911]: pfqueue(64911) WARN: > [mac:f2:ef:bb:22:8c:62] Unable to pull accounting history for device > f2:ef:bb:22:8c:62. The history set doesn't exist yet. > (pf::accounting_events_history::latest_mac_history) > Jan 18 14:55:14 pf4 pfqueue[64476]: pfqueue(64476) INFO: > [mac:f2:ef:bb:22:8c:62] Sending a firewall SSO 'Update' request for MAC > 'f2:ef:bb:22:8c:62' and IP '10.2.2.178' (pf::firewallsso::do_sso) > Jan 18 14:55:14 pf4 pfqueue[65697]: pfqueue(65697) INFO: > [mac:f2:ef:bb:22:8c:62] Instantiate profile Test_WiFi > (pf::Connection::ProfileFactory::_from_profile) > Jan 18 14:55:14 pf4 pfqueue[64469]: pfqueue(64469) WARN: > [mac:f2:ef:bb:22:8c:62] Unable to pull accounting history for device > f2:ef:bb:22:8c:62. The history set doesn't exist yet. > (pf::accounting_events_history::latest_mac_history) > > In the haproxy_portal.log we see some final activity on the Registration > portal waiting for the fencing delay to send the Radius Disconnect. > > Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62361 > <https://urldefense.com/v3/__http://10.2.2.178:62361__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gFD5Fmauw$> > [18/Jan/2023:14:55:12.224] portal-https-10.2.1.2~ > 10.2.1.2-backend/containers-gateway.internal:8080 0/0/0/1214/1214 302 1090 - > - ---- 7/5/0/0/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "POST /signup HTTP/1.1" > Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62366 > <https://urldefense.com/v3/__http://10.2.2.178:62366__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gHhaMHzuA$> > [18/Jan/2023:14:55:13.498] portal-http-10.2.1.2 > 10.2.1.2-backend/containers-gateway.internal:8080 0/0/0/139/139 200 7800 - - > ---- 8/2/0/0/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET /access?lang= HTTP/1.1" > Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62366 > <https://urldefense.com/v3/__http://10.2.2.178:62366__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gHhaMHzuA$> > [18/Jan/2023:14:55:13.668] portal-http-10.2.1.2 static/static 0/0/0/1/2 200 > 42006 - - ---- 9/3/0/0/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET /common/styles.css HTTP/1.1" > Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62367 > <https://urldefense.com/v3/__http://10.2.2.178:62367__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEOhKeA9g$> > [18/Jan/2023:14:55:13.677] portal-http-10.2.1.2 static/static 0/0/0/3/3 200 > 6157 - - ---- 13/7/3/3/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET /common/pf.js HTTP/1.1" > Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62369 > <https://urldefense.com/v3/__http://10.2.2.178:62369__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEb8G44tQ$> > [18/Jan/2023:14:55:13.677] portal-http-10.2.1.2 static/static 0/0/0/2/2 200 > 20248 - - ---- 13/7/2/2/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET /common/qrcode.min.js HTTP/1.1" > Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62370 > <https://urldefense.com/v3/__http://10.2.2.178:62370__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gFhtYnOUQ$> > [18/Jan/2023:14:55:13.677] portal-http-10.2.1.2 static/static 0/0/0/3/3 200 > 1506 - - ---- 13/7/1/1/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET /common/jquery-shim.js HTTP/1.1" > Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62368 > <https://urldefense.com/v3/__http://10.2.2.178:62368__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gG6YLN3yw$> > [18/Jan/2023:14:55:13.677] portal-http-10.2.1.2 static/static 0/0/0/3/3 200 > 8239 - - ---- 13/7/0/0/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET /content/captiveportal.js HTTP/1.1" > Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62366 > <https://urldefense.com/v3/__http://10.2.2.178:62366__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gHhaMHzuA$> > [18/Jan/2023:14:55:13.681] portal-http-10.2.1.2 static/static 0/0/0/5/5 200 > 837 - - ---- 14/8/1/1/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET /content/timerbar.js HTTP/1.1" > Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62371 > <https://urldefense.com/v3/__http://10.2.2.178:62371__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gHIGDDhPA$> > [18/Jan/2023:14:55:13.681] portal-http-10.2.1.2 static/static 0/0/0/5/5 200 > 1640 - - ---- 14/8/0/0/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET /content/release.js HTTP/1.1" > Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62366 > <https://urldefense.com/v3/__http://10.2.2.178:62366__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gHhaMHzuA$> > [18/Jan/2023:14:55:13.692] portal-http-10.2.1.2 static/static 0/0/0/1/1 200 > 4480 - - ---- 14/8/0/0/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET /common/packetfence-cp.png HTTP/1.1" > Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:62367 > <https://urldefense.com/v3/__http://10.2.2.178:62367__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEOhKeA9g$> > [18/Jan/2023:14:55:13.697] portal-http-10.2.1.2 static/static 0/0/0/1/1 200 > 39912 - - ---- 14/8/0/0/0 0/0 {pf4.test.com > <https://urldefense.com/v3/__http://pf4.test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEpp14xvA$>} > "GET /common/img/sprite.svg HTTP/1.1" > Jan 18 14:55:16 pf4 haproxy-portal-docker-wrapper[1141]: 10.2.2.178:54634 > <https://urldefense.com/v3/__http://10.2.2.178:54634__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gE6NrMnLg$> > [18/Jan/2023:14:55:13.663] portal-http-10.2.1.2 proxy/proxy 0/0/1/2974/2975 > 200 644 - - ---- 14/8/0/0/0 0/0 {captive.apple.com > <https://urldefense.com/v3/__http://captive.apple.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gHRHamHbA$>} > "GET /hotspot-detect.html HTTP/1.0" > > In the packetfence.log after the fencing delay we see the disconnect request > > Jan 18 14:55:28 pf4 pfqueue[65695]: pfqueue(65695) INFO: > [mac:f2:ef:bb:22:8c:62] [f2:ef:bb:22:8c:62] DesAssociating mac on switch > (10.2.1.11) (pf::api::desAssociate) > Jan 18 14:55:28 pf4 pfqueue[65695]: pfqueue(65695) INFO: > [mac:f2:ef:bb:22:8c:62] deauthenticating f2:ef:bb:22:8c:62 > (pf::Switch::Hostapd::radiusDisconnect) > Jan 18 14:55:28 pf4 pfqueue[65695]: pfqueue(65695) INFO: > [mac:f2:ef:bb:22:8c:62] Will be using connnector local_connector to perform > the deauth (pf::Switch::radius_deauth_connection_info) > Jan 18 14:55:28 pf4 pfqueue[65695]: pfqueue(65695) WARN: > [mac:f2:ef:bb:22:8c:62] Warning: 1366: Incorrect string value: > '\xE3\xD1`=\x04\xC7...' for column `pf`.`radius_audit_log`.`radius_reply` at > row 1 (pf::dal::db_execute) > Jan 18 14:55:28 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] handling radius autz request: from switch_ip => > (10.2.1.11), connection_type => Wireless-802.11-NoEAP,switch_mac => > (ec:08:6b:6a:63:5a), mac => [f2:ef:bb:22:8c:62], port => 0, username => > "f2efbb228c62", ssid => TestOne_WiFi (pf::radius::authorize) > Jan 18 14:55:28 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] Instantiate profile Test_WiFi > (pf::Connection::ProfileFactory::_from_profile) > Jan 18 14:55:28 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] Found authentication source(s) : '' for realm 'null' > (pf::config::util::filter_authentication_sources) > Jan 18 14:55:28 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] Connection type is MAC-AUTH. Getting role from > node_info (pf::role::getRegisteredRole) > Jan 18 14:55:28 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] Username was defined "f2efbb228c62" - returning role > 'guest' (pf::role::getRegisteredRole) > Jan 18 14:55:28 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] PID: "endu...@gmail.com <mailto:endu...@gmail.com>", > Status: reg Returned VLAN: (undefined), Role: guest > (pf::role::fetchRoleForNode) > Jan 18 14:55:28 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] (10.2.1.11) Added VLAN 83 to the returned RADIUS > Access-Accept (pf::Switch::returnRadiusAccessAccept) > Jan 18 14:55:29 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] Updating locationlog from accounting request > (pf::api::handle_accounting_metadata) > Jan 18 14:55:29 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) WARN: > [mac:f2:ef:bb:22:8c:62] Cannot find any combination ID in any schemas > (fingerbank::Source::LocalDB::_getCombinationID) > Jan 18 14:55:29 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] Upstream is configured and unable to fullfil an exact > match locally. Will ignore result from local database > (fingerbank::Source::LocalDB::match) > Jan 18 14:55:29 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] Successfully interrogate upstream Fingerbank project > for matching. Got device : 264 (fingerbank::Source::Collector::match) > Jan 18 14:55:29 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) WARN: > [mac:f2:ef:bb:22:8c:62] Unable to pull accounting history for device > f2:ef:bb:22:8c:62. The history set doesn't exist yet. > (pf::accounting_events_history::latest_mac_history) > Jan 18 14:55:29 pf4 pfqueue[64775]: pfqueue(64775) INFO: > [mac:f2:ef:bb:22:8c:62] Sending a firewall SSO 'Update' request for MAC > 'f2:ef:bb:22:8c:62' and IP '10.2.2.178' (pf::firewallsso::do_sso) > Jan 18 14:55:29 pf4 pfqueue[65705]: pfqueue(65705) INFO: > [mac:f2:ef:bb:22:8c:62] Instantiate profile Test_WiFi > (pf::Connection::ProfileFactory::_from_profile) > > > We see the VLAN change initiated from PF applied in the NAS/AP logs and the > client connection onto the Default VLAN 83 > > Wed Jan 18 14:55:28 2023 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED > f2:ef:bb:22:8c:62 > Wed Jan 18 14:55:28 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 RADIUS: stopped accounting session > 2DB2C59D34BD1998 > Wed Jan 18 14:55:28 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 RADIUS: VLAN ID 83 > Wed Jan 18 14:55:29 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 IEEE 802.11: authenticated > Wed Jan 18 14:55:29 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 IEEE 802.11: associated (aid 2) > Wed Jan 18 14:55:29 2023 daemon.notice hostapd: wlan0: AP-STA-CONNECTED > f2:ef:bb:22:8c:62 > Wed Jan 18 14:55:29 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 RADIUS: starting accounting session > 2DB2C59D34BD1998 > > With matching tcpdump capture showing the Disconnect and ACK from the NAS/AP > > 14:55:28.794094 IP 10.2.1.2.44286 > 10.2.1.11.3799: RADIUS, > Disconnect-Request (40), id: 0x7d length: 39 > 14:55:28.795785 IP 10.2.1.11.48577 > 10.2.1.2.1813: RADIUS, > Accounting-Request (4), id: 0x1e length: 224 > 14:55:28.796071 IP 10.2.1.11.3799 > 10.2.1.2.44286: RADIUS, Disconnect-ACK > (41), id: 0x7d length: 44 > 14:55:28.796386 IP 10.2.1.2.1813 > 10.2.1.11.48577: RADIUS, > Accounting-Response (5), id: 0x1e length: 35 > 14:55:28.885006 IP 10.2.1.11.49421 > 10.2.1.2.1812: RADIUS, Access-Request > (1), id: 0x1f length: 164 > 14:55:28.920956 IP 10.2.1.2.1812 > 10.2.1.11.49421: RADIUS, Access-Accept > (2), id: 0x1f length: 36 > 14:55:29.075666 IP 10.2.1.11.48577 > 10.2.1.2.1813: RADIUS, > Accounting-Request (4), id: 0x20 length: 182 > 14:55:29.076067 IP 10.2.1.2.1813 > 10.2.1.11.48577: RADIUS, > Accounting-Response (5), id: 0x20 length: 35 > > At this point the client is now on the Default VLAN 83 as of 14:55:29 > > On our Default Network, we immediately start to see traffic from the client. > The issue seems to be that the client is still using the IP from the > Registration network (10.2.2.178); Almost like it did not detect the wifi > disconnect and reconnect. > It should be on a 10.2.4.0/24 > <https://urldefense.com/v3/__http://10.2.4.0/24__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gGtiUcqww$> > IP address > > tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 > bytes > 14:55:29.071416 f2:ef:bb:22:8c:62 (oui Unknown) > Broadcast Null Unnumbered, > xid, Flags [Response], length 42: 01 00 > 14:55:29.725195 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP > (6), length 64) > 10.2.2.178.62377 > web.inverse.ca.80: Flags [S], cksum 0x1fc6 (correct), > seq 1176141384, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val > 2334978519 ecr 0,sackOK,eol], length 0 > 14:55:29.725195 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP > (6), length 64) > 10.2.2.178.62374 > web.inverse.ca.80: Flags [S], cksum 0x231d (correct), > seq 1612822294, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val > 1377096902 ecr 0,sackOK,eol], length 0 > 14:55:29.726606 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP > (6), length 64) > 10.2.2.178.62372 > web.inverse.ca.80: Flags [S], cksum 0x8e90 (correct), > seq 2169278132, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val > 1248622644 ecr 0,sackOK,eol], length 0 > 14:55:29.728233 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP > (6), length 64) > .... > > The client gets to the end of the captive portal connection progress bar, and > gets an obvious error, because it has not requested a new IP, as seen in the > tcpdump, with the half-open connection attempts to web.inverse.ca > <http://web.inverse.ca/> > This continues for 20 seconds during this period and we see this frame in > tcpdump below, still from a Registration VLAN IP but on the Default VLAN83 > > 14:55:43.749310 IP (tos 0x0, ttl 64, id 50181, offset 0, flags [none], proto > UDP (17), length 328) > 10.2.2.178.68 > 10.2.2.2.67: [udp sum ok] BOOTP/DHCP, Request from > f2:ef:bb:22:8c:62 (oui Unknown), length 300, xid 0xc683af32, Flags [none] > (0x0000) > Client-IP 10.2.2.178 > Client-Ethernet-Address f2:ef:bb:22:8c:62 (oui Unknown) > Vendor-rfc1048 Extensions > Magic Cookie 0x63825363 > DHCP-Message Option 53, length 1: Request > Parameter-Request Option 55, length 9: > Subnet-Mask, Classless-Static-Route, Default-Gateway, Domain-Name-Server > Domain-Name, Option 108, URL, Option 119 > Option 252 > MSZ Option 57, length 2: 1500 > Client-ID Option 61, length 7: ether f2:ef:bb:22:8c:62 > Lease-Time Option 51, length 4: 7776000 > END Option 255, length 0 > PAD Option 0, length 0, occurs 26 > > The half open connections from the client continue on the Default VLAN > ... > 14:55:45.742728 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP > (6), length 64) > 10.2.2.178.62376 > web.inverse.ca.80: Flags [S], cksum 0xcf45 (correct), > seq 3811680306, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val > 4007600036 ecr 0,sackOK,eol], length 0 > > At this point we turn off and on the wifi on the client, and it just > reconnects and is fine on the Default network as shown in the tcpdump on > VLAN83 below. > > 14:56:06.692580 f2:ef:bb:22:8c:62 (oui Unknown) > Broadcast Null Unnumbered, > xid, Flags [Response], length 42: 01 00 > 14:56:07.090206 IP (tos 0x0, ttl 255, id 10306, offset 0, flags [none], proto > UDP (17), length 328) > 0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from > f2:ef:bb:22:8c:62 (oui Unknown), length 300, xid 0xc683af33, Flags [none] > (0x0000) > Client-Ethernet-Address f2:ef:bb:22:8c:62 (oui Unknown) > Vendor-rfc1048 Extensions > Magic Cookie 0x63825363 > DHCP-Message Option 53, length 1: Discover > Parameter-Request Option 55, length 9: > Subnet-Mask, Classless-Static-Route, Default-Gateway, Domain-Name-Server > Domain-Name, Option 108, URL, Option 119 > Option 252 > MSZ Option 57, length 2: 1500 > Client-ID Option 61, length 7: ether f2:ef:bb:22:8c:62 > Lease-Time Option 51, length 4: 7776000 > END Option 255, length 0 > PAD Option 0, length 0, occurs 26 > 14:56:07.090596 IP (tos 0xc0, ttl 64, id 61257, offset 0, flags [none], proto > UDP (17), length 368) > pf4-user.lan.67 > 10.2.4.186.68: [bad udp cksum 0x1e2c -> 0x42ca!] > BOOTP/DHCP, Reply, length 340, xid 0xc683af33, Flags [none] (0x0000) > Your-IP 10.2.4.186 > Server-IP pf4-user.lan > Client-Ethernet-Address f2:ef:bb:22:8c:62 (oui Unknown) > Vendor-rfc1048 Extensions > Magic Cookie 0x63825363 > DHCP-Message Option 53, length 1: Offer > Server-ID Option 54, length 4: pf4-user.lan > Lease-Time Option 51, length 4: 43200 > RN Option 58, length 4: 21600 > RB Option 59, length 4: 37800 > Subnet-Mask Option 1, length 4: 255.255.255.0 > BR Option 28, length 4: 10.2.4.255 > Default-Gateway Option 3, length 4: pf4-user.lan > Domain-Name-Server Option 6, length 4: pf4-user.lan > URL Option 114, length 36: "urn:ietf:params:capport:unrestricted" > Domain-Name Option 15, length 8: "test.com > <https://urldefense.com/v3/__http://test.com__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gHbNFsyQg$>" > END Option 255, length 0 > > We See the matching activity of our manually disconnection and reassociation, > both still on VLAN 83, our Default network as seen in the NAS/AP logs: > Wed Jan 18 14:56:05 2023 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED > f2:ef:bb:22:8c:62 > Wed Jan 18 14:56:05 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 IEEE 802.11: disassociated > Wed Jan 18 14:56:05 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 RADIUS: stopped accounting session > 2DB2C59D34BD1998 > Wed Jan 18 14:56:06 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 RADIUS: VLAN ID 83 > Wed Jan 18 14:56:06 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 IEEE 802.11: authenticated > Wed Jan 18 14:56:06 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 IEEE 802.11: associated (aid 2) > Wed Jan 18 14:56:06 2023 daemon.notice hostapd: wlan0: AP-STA-CONNECTED > f2:ef:bb:22:8c:62 > Wed Jan 18 14:56:06 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 RADIUS: starting accounting session > 2DB2C59D34BD1998 > Wed Jan 18 14:56:07 2023 daemon.warn dnsmasq-dhcp[2691]: DHCP packet received > on br-vlan83 which has no address > Wed Jan 18 14:56:07 2023 daemon.notice hostapd: wlan0: AP-STA-DISCONNECTED > f2:ef:bb:22:8c:62 > Wed Jan 18 14:56:07 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 IEEE 802.11: disassociated > Wed Jan 18 14:56:07 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 RADIUS: stopped accounting session > 2DB2C59D34BD1998 > Wed Jan 18 14:56:08 2023 daemon.info > <https://urldefense.com/v3/__http://daemon.info__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gEoIfX2ig$> > hostapd: wlan0: STA f2:ef:bb:22:8c:62 IEEE 802.11: deauthenticated due to > inactivity (timer DEAUTH/REMOVE) > > And in our packetfence log, the manual change is accounted for, but this is > just like a device returning, that has previously been authorized. > Jan 18 14:56:06 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] handling radius autz request: from switch_ip => > (10.2.1.11), connection_type => Wireless-802.11-NoEAP,switch_mac => > (ec:08:6b:6a:63:5a), mac => [f2:ef:bb:22:8c:62], port => 0, username => > "f2efbb228c62", ssid => TestOne_WiFi (pf::radius::authorize) > Jan 18 14:56:06 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] Instantiate profile Test_WiFi > (pf::Connection::ProfileFactory::_from_profile) > Jan 18 14:56:06 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] Found authentication source(s) : '' for realm 'null' > (pf::config::util::filter_authentication_sources) > Jan 18 14:56:06 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] Connection type is MAC-AUTH. Getting role from > node_info (pf::role::getRegisteredRole) > Jan 18 14:56:06 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] Username was defined "f2efbb228c62" - returning role > 'guest' (pf::role::getRegisteredRole) > Jan 18 14:56:06 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] PID: "endu...@gmail.com <mailto:endu...@gmail.com>", > Status: reg Returned VLAN: (undefined), Role: guest > (pf::role::fetchRoleForNode) > Jan 18 14:56:06 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] (10.2.1.11) Added VLAN 83 to the returned RADIUS > Access-Accept (pf::Switch::returnRadiusAccessAccept) > Jan 18 14:56:06 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] Updating locationlog from accounting request > (pf::api::handle_accounting_metadata) > Jan 18 14:56:06 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) WARN: > [mac:f2:ef:bb:22:8c:62] Cannot find any combination ID in any schemas > (fingerbank::Source::LocalDB::_getCombinationID) > Jan 18 14:56:06 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] Upstream is configured and unable to fullfilan exact > match locally. Will ignore result from local database > (fingerbank::Source::LocalDB::match) > Jan 18 14:56:06 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) INFO: > [mac:f2:ef:bb:22:8c:62] Successfully interrogate upstream Fingerbank project > for matching. Got device : 264 (fingerbank::Source::Collector::match) > Jan 18 14:56:06 pf4 httpd.aaa-docker-wrapper[2299]: httpd.aaa(7) WARN: > [mac:f2:ef:bb:22:8c:62] Unable to pull accounting history for device > f2:ef:bb:22:8c:62. The history set doesn't exist yet. > (pf::accounting_events_history::latest_mac_history) > Jan 18 14:56:10 pf4 pfperl-api-docker-wrapper[1130]: pfperl-api(14) INFO: > [mac:[undef]] Using 300 resolution threshold > (pf::pfcron::task::cluster_check::run) > Jan 18 14:56:10 pf4 pfperl-api-docker-wrapper[1130]: pfperl-api(14) INFO: > [mac:[undef]] All cluster members are running the same configuration version > (pf::pfcron::task::cluster_check::run) > Jan 18 14:56:10 pf4 pfperl-api-docker-wrapper[1130]: pfperl-api(14) INFO: > [mac:[undef]] processed 0 security_events during security_event maintenance > (1674071770.27209 1674071770.28315) > (pf::security_event::security_event_maintenance) > Jan 18 14:56:10 pf4 pfperl-api-docker-wrapper[1130]: pfperl-api(14) INFO: > [mac:[undef]] getting security_events triggers for accounting cleanup > (pf::accounting::acct_maintenance) > > In summary, our problem appears to be that some clients are not requesting a > new lease when reconnecting, and are trying to continue with their > Registration VLAN configuration when put onto the Default VLAN after and > AP-Disconnect, which we would assume requires a new lease update. Is it > possible to have the PF server send a DHCP Disconnect, prior to the RADIUS > Disconnect to help the client refresh. > > It is also worth noting we do have Option 114 defined in our DHCP response on > the Default Network as shown above. So having overcome some timing issues > between RADIUS Disconnects and our APs, and adding Option 114 to our Default > network, we still seem to be stuck on this issue where some clients are not > updating their network lease when being disconnected and reconnected on the > Default Network VLAN > > URL Option 114, length 36: "urn:ietf:params:capport:unrestricted" > > Any help appreciated > _______________________________________________ > PacketFence-users mailing list > PacketFence-users@lists.sourceforge.net > <mailto:PacketFence-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/packetfence-users > <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/packetfence-users__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gH7G8u1hA$> > _______________________________________________ > PacketFence-users mailing list > PacketFence-users@lists.sourceforge.net > https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/packetfence-users__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gH7G8u1hA$ > > <https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/packetfence-users__;!!GjvTz_vk!RPQlYqvAU8mZUpbCXLbAj9YIOxCD_K1Zxif9CTrlZB_-I5ZvHB3oxdOTBu3zVk8av2aniBme9MHIOC7X6Y4n_iIAW63i9gH7G8u1hA$>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
