We are using Packetfence 5.7.0 (Debian) with Hostapd (OpenWRT 15.05) for
WiFi access control.
In the instance we are testing, our clients connect to an Open SSID, are
directed to a portal profile based on the SSID and perform guest
registration using email (role=guest) via client captive portal detection.
For some reason unknown to us, every once in a while a client is falling
back on the default profile and we don't know why. Details follow,
cheers,
Ian
For testing portal profiles, we re-unregister nodes or let their temporary
registration expire and then connect them as if they were new clients. We
use one Ubuntu laptop (chrome 49) and an Android 6 phone (my devices) for
testing on the same AP which only has a single SSID on the 2.4Ghz band
enabled with CoA.
For an unknown reason, the Android 6 smartphone is connecting to the
default portal profile instead of the "swim2wifi" profile that matches the
SSID; but only on infrequent occasions. It is not clear why this is
happening as it has worked correctly in the majority of cases. In the
Nodes list, both devices are still in role guest. The logs show them
connecting to the same SSID (SwimClub2) which matches a specific portal
profile (swim2wifi).
In the last occurrence shown below, it was the first connection of the day
for the device, and the wrong(default) portal login.html persisted across
turning on/off WiFi on the client, however it did correct itself
(swim2wifi) once we 'Forgot' the SSID on the phone and reconnected. We
don't understand how this could impact the PF's decision process which
should be based solely on the SSID, at least by our understanding.
What could cause the Android 6 Phone to match the wrong(default) profile;
The only significant difference between these clients, other than
platform, include
a) Different past registration state history
b) Mobile phone has the ability to try and reach the captive portal via
public Internet (which is enabled for email activation via mobile carrier
networks) and can be left in a captive portal detection state as it leaves
the service area, possibly confusing PF (we will try and test this).
Any help appreciated while we continue to test and figure this out.
Android 6 Phone
packetfence.log:Mar 16 09:27:06 httpd.aaa(3224) INFO:
[mac:10:a5:d0:00:7b:8d] handling radius autz request: from switch_ip =>
(10.3.1.3), connection_type => Wireless-802.11-NoEAP,switch_mac =>
(60:e3:27:a4:6b:39), mac => [10:a5:d0:00:7b:8d], port => 0, username =>
"10a5d0007b8d", ssid => *SwimClub2_WiFi* (pf::radius::authorize)
packetfence.log:Mar 16 09:27:06 httpd.aaa(3224) INFO:
[mac:10:a5:d0:00:7b:8d] is of status unreg; belongs into registration VLAN
(pf::role::getRegistrationRole)
packetfence.log:Mar 16 09:27:06 httpd.aaa(3224) INFO:
[mac:10:a5:d0:00:7b:8d] (10.3.1.3) Added VLAN 84 to the returned RADIUS
reply (pf::Switch::returnRadiusAccessAccept)
packetfence.log:Mar 16 09:27:06 httpd.aaa(3224) INFO:
[mac:10:a5:d0:00:7b:8d] (10.3.1.3) Returning ACCEPT with VLAN 84
(pf::Switch::returnRadiusAccessAccept)
packetfence.log:Mar 16 09:27:11 httpd.portal(7376) INFO:
[mac:10:a5:d0:00:7b:8d] Instantiate *profile default*
(pf::Portal::ProfileFactory::_from_profile)
packetfence.log:Mar 16 09:27:11 httpd.portal(7376) INFO:
[mac:10:a5:d0:00:7b:8d] redirected to authentication page on *default
portal*
(captiveportal::PacketFence::Controller::CaptivePortal::checkIfNeedsToRegister)
Ubuntu 16.04 Laptop
packetfence.log:Mar 16 09:27:42 httpd.aaa(3224) INFO:
[mac:f8:16:54:cd:36:0c] handling radius autz request: from switch_ip =>
(10.3.1.3), connection_type => Wireless-802.11-NoEAP,switch_mac =>
(60:e3:27:a4:6b:39), mac => [f8:16:54:cd:36:0c], port => 0, username =>
"f81654cd360c", ssid => *SwimClub2_WiFi* (pf::radius::authorize)
packetfence.log:Mar 16 09:27:42 httpd.aaa(3224) INFO:
[mac:f8:16:54:cd:36:0c] is of status unreg; belongs into registration VLAN
(pf::role::getRegistrationRole)
packetfence.log:Mar 16 09:27:42 httpd.aaa(3224) INFO:
[mac:f8:16:54:cd:36:0c] (10.3.1.3) Added VLAN 84 to the returned RADIUS
reply (pf::Switch::returnRadiusAccessAccept)
packetfence.log:Mar 16 09:27:42 httpd.aaa(3224) INFO:
[mac:f8:16:54:cd:36:0c] (10.3.1.3) Returning ACCEPT with VLAN 84
(pf::Switch::returnRadiusAccessAccept)
packetfence.log:Mar 16 09:28:17 httpd.portal(7337) INFO:
[mac:f8:16:54:cd:36:0c] Instantiate *profile swim2wifi*
(pf::Portal::ProfileFactory::_from_profile)
packetfence.log:Mar 16 09:28:17 httpd.portal(7337) WARN:
[mac:f8:16:54:cd:36:0c] ^* matches null string many times in regex; marked
by <-- HERE in m/^* <-- HERE $/ at
/usr/local/pf/html/captive-portal/lib/captiveportal/PacketFence/Controller/Root.pm
line 193.
packetfence.log:Mar 16 09:28:17 httpd.portal(7337) WARN:
[mac:f8:16:54:cd:36:0c] ^* matches null string many times in regex; marked
by <-- HERE in m/^* <-- HERE / at
/usr/local/pf/html/captive-portal/lib/captiveportal/PacketFence/Controller/Root.pm
line 125.
packetfence.log:Mar 16 09:28:17 httpd.portal(7337) INFO:
[mac:f8:16:54:cd:36:0c] Updating node user_agent with useragent:
'Mozilla/5.0 (Linux) mirall/2.1.0'
(captiveportal::PacketFence::Controller::CaptivePortal::nodeRecordUserAgent)
packetfence.log:Mar 16 09:28:17 httpd.portal(7337) INFO:
[mac:f8:16:54:cd:36:0c] Static User-Agent lookup data initialized
(pf::useragent::_init)
packetfence.log:Mar 16 09:28:17 httpd.portal(7333) INFO:
[mac:f8:16:54:cd:36:0c] Instantiate profile swim2wifi
(pf::Portal::ProfileFactory::_from_profile)
packetfence.log:Mar 16 09:28:17 httpd.portal(7333) INFO:
[mac:f8:16:54:cd:36:0c] Updating node user_agent with useragent:
'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/49.0.2623.87 Safari/537.36'
(captiveportal::PacketFence::Controller::CaptivePortal::nodeRecordUserAgent)
packetfence.log:Mar 16 09:28:17 httpd.portal(7347) INFO:
[mac:f8:16:54:cd:36:0c] Instantiate profile swim2wifi
(pf::Portal::ProfileFactory::_from_profile)
packetfence.log:Mar 16 09:28:17 httpd.portal(7364) INFO:
[mac:f8:16:54:cd:36:0c] Instantiate profile swim2wifi
(pf::Portal::ProfileFactory::_from_profile)
packetfence.log:Mar 16 09:28:18 httpd.portal(7352) INFO:
[mac:f8:16:54:cd:36:0c] Instantiate profile swim2wifi
(pf::Portal::ProfileFactory::_from_profile)
packetfence.log:Mar 16 09:28:21 httpd.portal(7347) INFO:
[mac:f8:16:54:cd:36:0b] redirected to authentication page on *polo2wifi
portal*
(captiveportal::PacketFence::Controller::CaptivePortal::checkIfNeedsT
oRegister)
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users