To close this thread off,
The package issues are being handled in
https://github.com/inverse-inc/packetfence/issues/7473
On the 1813 bindings; It looks like I just had not yet noticed that there
are now two accounting options; pfacct and radius-acct and although they
are both present, the
le
>>>>> is not active in this test environment.
>>>>> >
>>>>> > In production, there was a redirection URL in the Captive Portal
>>>>> configuration that goes to a web site; Provided by the ISP that is
>>>>> provi
p://captive.apple.com/hotspot-detect.html before it tries to follow
>>> the redirect that page returns. Also your DNS is returning the same IP
>>> (66.70.255.147) for captive.apple.com as for pf4.dotto-one.com. Are you
>>> doing DNS enforcement on the portal? Then on the def
d re-using that on the
> default network instead of looking at the cappport:unrestricted value
> returned on the default network.
> >> >
> >> > So was the iPhone not re-DHCPing problem solved by very short lease
> times on the registration network?
> >> &
gt; So was the iPhone not re-DHCPing problem solved by very short lease
> times on the registration network?
> >
> > Thanks,
> >
> > --
> > James Andrewartha
> > Network & Projects Engineer
> > Christ Church Grammar School
> > Claremont, Western Austr
In an upgrade of a PF environment from 11.0 to 12.1, following the upgrade
instructions, we stumbled on a bug due to some package dependencies.
These redudant packages are being tracked in a bug here
https://github.com/inverse-inc/packetfence/issues/7246 however they cause
an upgrade from 11.0 to
gt;> 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
t;/rfc7710"
>
> if so.. it might be that the clients are too fast re-accessing that url
> and determining they are still locked
>
> in my case, forcing a disconnect via the COA will cause the client to
> re-issue a dhcp request.. and thus, a new portal request?
>
&g
It seems that the firewall protecting our management portal was responsible
for the issue we were having.
As noted in another thread we were experiencing timeout issues pulling the
PF images during the installation process; We were able to resolve this
issue with our firewall. What is not
After ruling out DNS and IPv6, we were able to isolate the timeout issues
to our firewall.
We are no longer seeing issues related to the pulling of the images,
similar to this one below.
error pulling image configuration: Get "
We restaged our environment
https://github.com/inverse-inc/packetfence/issues/7403 describes some
similar symptoms, so I have added some additional debug below from
cat /etc/network/interfaces
/usr/local/pf/sbin/pfperl-api get /api/v1/config/interfaces | jq
ip -br a
docker container ls
Hello Packetfence Users,
We tested a fresh install of v12.1 on a freshly spun up Debian 11.6 today.
packetfence_12.1.0+20230116163629+748667390+0011+maintenance~12~1+bullseye1_all.deb
Prior to installing packetfence, we deployed some basic packages, listed
here as part of our default staging
Hey PF Users,
Our environment is PF 12.1 on Debian 11. It is in our lab. Our production
is still on 11.0.
We recently upgraded this lab from 11.0, right through to 12.1. We did
some light testing of our captive portal at each stage to make sure the
basic functions were working properly, and
An update,
A maintenance release on 12.1 available today provided an opportunity to
catch this timeout issue again, so we tcpdumped our DNS traffic during the
apt upgrade process.
The issue did not occur. All we saw were what appeared to be normal
requests for ghcr.io and
://www.facebook.com/AkamaiTechnologies>
> <http://www.linkedin.com/company/akamai-technologies>
> <http://www.youtube.com/user/akamaitechnologies?feature=results_main>
>
> On Jan 10, 2023, at 3:27 PM, Ian MacDonald via PacketFence-users <
> packetfence-users@lists.s
>
> Tel.: (85) 3477.3302
>
>
>
> Em qua., 11 de jan. de 2023 às 10:52, Ian MacDonald via PacketFence-users <
> packetfence-users@lists.sourceforge.net> escreveu:
>
>> Hi Packetfence,
>>
>> We have been struggling with some newer model mobile devices w
Hi Packetfence,
We have been struggling with some newer model mobile devices with our WiFi
captive portal implementation using Packetfence, and have not seen any
change in the behavior on 11.0 thru 12.1 with our current connection
profile.
We do not use an inline configuration, and now we are
Hey PF Users,
For recent versions; I believe 11.1, 12.0 and now 12.1 and possibly 11.0
(Fairly certain since the images below were downloaded from Inverse repos
all at once during the installation or upgrade process) We have been having
to restart the upgrade process due to timeout related
We are using an OpenWRT 21.02.0 Hostapd client as a switch.
Our PF is Debian 11 with PF 11 on the most recent stable production build:
11.0.0+20211019052209+390787654+0011+maintenance~11.0+bullseye1
Our PF server is configured with management IP 10.2.1.2 and our switch
10.2.1.60 in the
Attached is a modified /lib/netifd/hostapd.sh that will allow you have a
captive portal on a single radio with OpenWRT authenticating by email.
Seems to work with just about any OpenWRT device allowing a lot of
flexibility across hardware and wireless radios. Maybe this will be useful
for others.
We just completed a long overdue upgrade from 9.3 to 11.0. We are happy to
share that at least one of our instances has been evergreening since PF 6
on Debian 8.
A few things we noted during the upgrade, consistently across our
environments that might be noteworthy for Debian users
1) The 10.1
We just rolled back to a fresh image of 11.0 and re-imported from prior to
the 11.1 as we had just come from 10.3 and we really need the parity
between the environments for testing future upgrades.
I don't think you need to worry about anyone else doing this; without
release notes it was obvious
Okay,
I suspected that was the case, but possibly we were just hours ahead of the
release notes. We seem to have forgotten dev was in the same repository.
The intent was just to test the latest stable.
We ran the export / import anyways in the 11.1 and noted there was no
schema migration
I noticed 11.1 packages are available, and v11.1 appeared in the coverpage
for some docs
https://www.inverse.ca/downloads/PacketFence/doc/11.0.0/PacketFence_Template_Guide.pdf
so we decided to see how the new upgrade process >11.0 went on our dev
packetfence environment after recently bringing
; 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
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
is change then it will be
> integrate to PacketFence for the next release.
>
> And also thank for the support :-)
>
> Le 2018-03-07 à 17:08, Ian MacDonald via PacketFence-users a écrit :
>
> Below is a quick addendum to the current Hostapd Quick Install Guide.
>
> Hopefully it will help new users
Eugene,
On the note of patch application; Are you sure you applied the entire
patch? The output of your patching below indicates 3 hunks that still need
to be manually applied.
cheers,
Ian
[root@PacketFence-ZEN pf]# patch -p1 <
./34405d44b203ce2fd4a4dac435ff62d69c4ed00f.diff
patching file
7.3.0 to 7.4.0 sorry ;-)
>
> mybrowserinfo.com shows the correct language. When I set locale= I
> get the english version of the profile preview and the preview of the html
> files like layout.html. When I set the locale=de_DE in the profiles.conf
> file, I get the profile preview i
Below is a quick addendum to the current Hostapd Quick Install Guide.
Hopefully it will help new users looking to leverage the flexibility of
OpenWRT (aka LEDE) with the powerful captive portal functionality of
Packetfence.
There is a great guide from Inverse, and this email just adds a few
before
> # switching VLAN.
> wait_for_redirect = 31
>
> Regards
>
> Fabrice
>
>
>
> Le 2018-03-06 à 13:54, Ian MacDonald via PacketFence-users a écrit :
>
> Well,
>
> We easily narrowed this down to a timing issue related to the
> Access-Accept(2) messages an
Well,
We easily narrowed this down to a timing issue related to the
Access-Accept(2) messages and how long an authorization is considered valid
by hostapd.
In short, we need to make sure that the CoA from portal activation is NOT
sent to the AP within 30 seconds of the initial connection to the
Eugene,
I think a good old fashioned network diagram could be of help here. I am
not sure which linux flavour your running, but I can see one problem that
might be confusing your forwarding/arp/iptables.
You have two IP addresses on the same subnet configured both on the raw
device (eth0) and a
We have packetfence 7.4 instances out-of-band running on Debian 8, and use
the captive portal with hostapd for WiFi client access.
Our clients register using an email source for activation.
Our configuration uses all captive_portal defaults except for the network
detection IP, shown below.
Hubert,
I would assume you mean upgraded from 7.3.0 to 7.4.0;
I think by default, connection profiles support whatever locale your
browser requests. Maybe confirm your local setup using mybrowserinfo.com
and make sure you are requesting the language you want.
Using locale= will let your
It seems patience was the only culprit here; About 5 minutes after I sent
this, likely a good 10 minutes after I tried to re-initialize the DB and
re-import the Fingerbank data, I received an email from PF indicating
success.
Our last action to stop pf services, re-install fingerbank and then
Hello,
We are running current v7.4 on Debian 8.
On one of our servers, it seems the fingerbank db will not initialize
properly.
In our logs, we see similar to below:
Mar 4 14:51:08 pf2 packetfence_httpd.aaa: httpd.aaa(1142) ERROR:
[mac:fc:c2:de:9e:7e:3b] Unable to compute Fingerbank device
Further to my last post,
A big thanks to William McLeod; His response instantly fixed our issue
with Android 7.x clients.
The fix is simple to implement directly through the GUI.
It sounds like a small tweak to packetfence might be prudent, as I am sure
Android 7 is well within the scope of a
In addition to below,
It looks like this might be this issue, previously resolved with mariadb
but possibly not with packetfence-dhcpd.
https://github.com/inverse-inc/packetfence/issues/2792
Our short term workaround was to just turn off the broken systemd process
notification by changing the
Hello,
We have two pf instances running 7.4.0 on Debian 9, both recently upgraded
from 7.3.0. They both have been running packetfence since 6.5.0.
In both cases, they have the following in pf.conf that has been retained
over the upgrades:
[fencing]
#
# trapping.redirtimer
#
# How long to
Hello,
Our PF instance(s) run in an out-of-band configuration, providing a captive
portal to hostapd/CoA enabled switches using connection profiles with SSID
filters and an email source for activation.
We are not clustering, but instead have a qa instance where we stage and
test upgrades and
Louis,
Thanks for your input on the issue, some responses to your request for
info below,
>> The main problem seems to be that that the haproxy service is not
starting.
>> In the syslog we just get a generic service failure with no details
>>
>> May 29 16:51:08 pf2 systemd[1]: Started
42 matches
Mail list logo
