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 <http://daemon.info>
hostapd: wlan0: STA f2:ef:bb:22:8c:62 *RADIUS: VLAN ID 81*
Wed Jan 18 14:54:55 2023 daemon.info <http://daemon.info>
hostapd: wlan0: STA f2:ef:bb:22:8c:62 IEEE 802.11: authenticated
Wed Jan 18 14:54:55 2023 daemon.info <http://daemon.info>
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 <http://daemon.info>
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 <http://10.2.2.178:54627>
[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
<http://captive.apple.com>} "GET /hotspot-detect.html HTTP/1.0"
Jan 18 14:55:01 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62360 <http://10.2.2.178:62360>
[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
<http://captive.apple.com>} "GET /hotspot-detect.html HTTP/1.1"
Jan 18 14:55:01 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:54632 <http://10.2.2.178:54632>
[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
<http://captive.apple.com>} "GET /hotspot-detect.html HTTP/1.0"
Jan 18 14:55:01 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62361 <http://10.2.2.178:62361>
[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
<http://pf4.test.com>} "GET
/captive-portal?destination_url=http://captive.apple.com/hotspot-detect.html
<http://captive.apple.com/hotspot-detect.html> HTTP/1.1"
Jan 18 14:55:01 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62361 <http://10.2.2.178:62361>
[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
<http://pf4.test.com>} "GET /common/styles.css HTTP/1.1"
Jan 18 14:55:02 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62364 <http://10.2.2.178:62364>
[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
<http://pf4.test.com>} "GET /common/qrcode.min.js HTTP/1.1"
Jan 18 14:55:02 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62365 <http://10.2.2.178:62365>
[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
<http://pf4.test.com>} "GET /common/jquery-shim.js HTTP/1.1"
Jan 18 14:55:02 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62362 <http://10.2.2.178:62362>
[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
<http://pf4.test.com>} "GET /common/pf.js HTTP/1.1"
Jan 18 14:55:02 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62363 <http://10.2.2.178:62363>
[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
<http://pf4.test.com>} "GET /content/captiveportal.js HTTP/1.1"
Jan 18 14:55:02 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62361 <http://10.2.2.178:62361>
[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
<http://pf4.test.com>} "GET /common/packetfence-cp.png HTTP/1.1"
Jan 18 14:55:02 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62365 <http://10.2.2.178:62365>
[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
<http://pf4.test.com>} "GET /common/img/sprite.svg HTTP/1.1"
Jan 18 14:55:02 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62364 <http://10.2.2.178:62364>
[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
<http://pf4.test.com>} "POST /record_destination_url HTTP/1.1"
Jan 18 14:55:04 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:54633 <http://10.2.2.178:54633>
[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 <http://captive.apple.com>} "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 <http://10.2.2.178:62361>
[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
<http://pf4.test.com>} "POST /signup HTTP/1.1"
Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62366 <http://10.2.2.178:62366>
[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
<http://pf4.test.com>} "GET /access?lang= HTTP/1.1"
Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62366 <http://10.2.2.178:62366>
[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
<http://pf4.test.com>} "GET /common/styles.css HTTP/1.1"
Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62367 <http://10.2.2.178:62367>
[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
<http://pf4.test.com>} "GET /common/pf.js HTTP/1.1"
Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62369 <http://10.2.2.178:62369>
[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
<http://pf4.test.com>} "GET /common/qrcode.min.js HTTP/1.1"
Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62370 <http://10.2.2.178:62370>
[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
<http://pf4.test.com>} "GET /common/jquery-shim.js HTTP/1.1"
Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62368 <http://10.2.2.178:62368>
[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
<http://pf4.test.com>} "GET /content/captiveportal.js HTTP/1.1"
Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62366 <http://10.2.2.178:62366>
[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
<http://pf4.test.com>} "GET /content/timerbar.js HTTP/1.1"
Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62371 <http://10.2.2.178:62371>
[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
<http://pf4.test.com>} "GET /content/release.js HTTP/1.1"
Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62366 <http://10.2.2.178:62366>
[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
<http://pf4.test.com>} "GET /common/packetfence-cp.png HTTP/1.1"
Jan 18 14:55:13 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:62367 <http://10.2.2.178:62367>
[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
<http://pf4.test.com>} "GET /common/img/sprite.svg HTTP/1.1"
Jan 18 14:55:16 pf4 haproxy-portal-docker-wrapper[1141]:
10.2.2.178:54634 <http://10.2.2.178:54634>
[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 <http://captive.apple.com>} "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 <http://daemon.info>
hostapd: wlan0: STA f2:ef:bb:22:8c:62 RADIUS: stopped accounting
session 2DB2C59D34BD1998
Wed Jan 18 *14:55:28* 2023 daemon.info <http://daemon.info>
hostapd: wlan0: STA f2:ef:bb:22:8c:62 RADIUS: *VLAN ID 83*
Wed Jan 18 14:55:29 2023 daemon.info <http://daemon.info>
hostapd: wlan0: STA f2:ef:bb:22:8c:62 IEEE 802.11: authenticated
Wed Jan 18 14:55:29 2023 daemon.info <http://daemon.info>
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 <http://daemon.info>
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 <http://10.2.4.0/24> 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 <http://test.com>"
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 <http://daemon.info>
hostapd: wlan0: STA f2:ef:bb:22:8c:62 IEEE 802.11: disassociated
Wed Jan 18 14:56:05 2023 daemon.info <http://daemon.info>
hostapd: wlan0: STA f2:ef:bb:22:8c:62 RADIUS: stopped accounting
session 2DB2C59D34BD1998
Wed Jan 18 14:56:06 2023 daemon.info <http://daemon.info>
hostapd: wlan0: STA f2:ef:bb:22:8c:62 RADIUS: VLAN ID 83
Wed Jan 18 14:56:06 2023 daemon.info <http://daemon.info>
hostapd: wlan0: STA f2:ef:bb:22:8c:62 IEEE 802.11: authenticated
Wed Jan 18 14:56:06 2023 daemon.info <http://daemon.info>
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 <http://daemon.info>
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 <http://daemon.info>
hostapd: wlan0: STA f2:ef:bb:22:8c:62 IEEE 802.11: disassociated
Wed Jan 18 14:56:07 2023 daemon.info <http://daemon.info>
hostapd: wlan0: STA f2:ef:bb:22:8c:62 RADIUS: stopped accounting
session 2DB2C59D34BD1998
Wed Jan 18 14:56:08 2023 daemon.info <http://daemon.info>
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 locationlogfrom
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://lists.sourceforge.net/lists/listinfo/packetfence-users>
_______________________________________________
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users
