> > > Do you happen to have the > 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 ? > We do not use this sensor; It looks like it just puts the DHCP packets into the PF Server accounting; I don't think it changes the nature of the DHCP requests, which we can see.
We did shorten my registration VLAN dhcp lease time, and lease max time from 30s to 15s, but it did not appear to have any impact on how the iPhone handles things. [10.2.2.0] netmask=255.255.255.0 type=vlan-registration split_network=disabled fake_mac_enabled=disabled coa=disabled netflow_accounting_enabled=disabled dns=10.2.2.2 named=enabled gateway=10.2.2.2 dhcp_end=10.2.2.246 nat_enabled=disabled dhcp_default_lease_time=15 dhcpd=enabled dhcp_max_lease_time=15 nat_dns=disabled domain-name=vlan-registration.test.com dhcp_start=10.2.2.10 pool_backend=memory id=10.2.2.0 > > 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> 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> 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 >>> <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", 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 >>> 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", 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 >>> 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$ > > >
_______________________________________________ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
