Hello Ian,
you can try the devel version to see if it fix the issue.
echo 'deb http://inverse.ca/downloads/PacketFence/debian-devel stretch
stretch' > /etc/apt/sources.list.d/packetfence.list
echo 'deb http://inverse.ca/downloads/PacketFence/debian stretch
stretch' > /etc/apt/sources.list.d/packetfence.list
apt update
apt install packetfence
Regards
Fabrice
Le 20-03-20 à 16 h 29, Ian MacDonald via PacketFence-users a écrit :
Thanks,
I was actually just reviewing the commits; There are a bunch. I am
hoping to just grab the one for the popup.
Our registration is same layer 2 network as the server's captive
portal; so we wait for PF10 on Debian or cherry pick the pop-up stuff
from the rest.
If you want to point us to the critical commits, as we don't really
know what Samsung changed, and it looks like a bunch of stuff was
fixed and added in that change.
cheers,
Ian
On Fri, Mar 20, 2020 at 2:49 PM Fabrice Durand via PacketFence-users
<packetfence-users@lists.sourceforge.net
<mailto:packetfence-users@lists.sourceforge.net>> wrote:
Hello Ian,
it's a know issue with Samsung devices, in fact if the device
won't pop the portal if the device is on the same layer 2 network.
It has been fixed in
https://github.com/inverse-inc/packetfence/pull/5086 and will be
part in the incoming packetfence v10.
Btw if the registration network is a layer 3 network then it
should work.
I don't know why Samsung did that ...
Regards
Fabrice
Le 20-03-20 à 13 h 58, Ian MacDonald via PacketFence-users a écrit :
Hi,
We noticed Samsung Devices on Android 10 are no longer being
redirected to our Packetfence portal on the registration network.
Up until now we have our portal configured with,
a) Secure redirect ON
b) WISPr redirection capabilities ON
We do not use the detection mechanism bypass.
When the devices connect to the registration VLAN, they simply
note "Connected without Internet" and never detect the portal and
redirect to the registration page.
Is anyone successfully capturing new Galaxy devices / Android 10,
and do they have any insights as to what mechanism we can use, or
DNS filters we can apply?
We are hoping to shortcut the next step of looking at the traffic
and trying to determine what/how to intercept.
We also seem to have good compatibility with many other existing
devices and platforms, so we are hesitant to start bypassing the
Captive Portal detection, which would likely stop a lot of other
platforms from working effectively.
We are using PF9.3
(9.3.0+20200113144930+108928498+0009+v9.3.0+stretch1) with
hostapd + CoA/Disconnect, Out of Band.
cheers,
Ian
_______________________________________________
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
<mailto:PacketFence-users@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/packetfence-users
--
Fabrice Durand
fdur...@inverse.ca <mailto:fdur...@inverse.ca> :: +1.514.447.4918 (x135)
::www.inverse.ca <http://www.inverse.ca>
Inverse inc. :: Leaders behind SOGo (http://www.sogo.nu) and PacketFence
(http://packetfence.org)
_______________________________________________
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
<mailto:PacketFence-users@lists.sourceforge.net>
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
_______________________________________________
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users
