To all PacketFence users,
Due to the release of CentOS 7.7 the Inverse team had to perform some
packaging adjustments in order to make PacketFence compatible with the
latest release of CentOS 7.7. For this reason it is not suggested to
upgrade your operating system to CentOS 7.7 without
Hi Eric,
I've adjusted the code, it was just a case of casting the hashref to a hash.
You can see the adjustment here:
https://github.com/inverse-inc/packetfence/commit/312941eee61707ba34c1a05f2ac3104cb73dc643
Its been pushed in the maintenance/9.0 branch meaning it can be applied
via the
To all PacketFence users,
The first version of the Fingerbank API hosted on fingerbank.inverse.ca
will be shutdown completely on July 1st 2019 after it was officially
deprecated more than 1 year ago.
You will want to ensure you upgrade to a PacketFence version higher than
8.0 which supports
Hi Max,
The sad thing is, Fingerbank is limited in the sense that when devices
don't exhibit behaviors that seperate them from other devices, then its
hard to accurately profile a device.
On top of this, the manufacturer (MAC vendor) who created the device is
keeping its privacy, that makes
Yes attachment is fine if its under 10MB
On 2018-06-26 04:35 PM, Steve Pfister wrote:
Just the fingerbank.log? It looks like it's a couple mb compressed.
Can I email it to you as an attachment?
On 6/26/2018 4:31 PM, Julien Semaan wrote:
Can you post the logs that you're seeing for this MAC
Can you post the logs that you're seeing for this MAC
--
Julien Semaan
jsem...@inverse.ca :: +1 (866) 353-6153 *155 ::www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)
On 2018-06-26 04:02 PM, Steve Pfister wrote:
Still seems
I'd check in the pfdhcplistener.log and packetfence.log if you see
multiple occurrences of this MAC address and what type of traffic is
driving this high usage of Fingerbank. Very likely to be this device
performing DHCP extremelly often.
Cheers!
--
Julien Semaan
jsem...@inverse.ca :: +1
Likely, PacketFence is seeing DHCP traffic from your production networks
which trigger device profiling.
You could obtain unlimited access to the API by having a valid support
contract with Inverse
The available options are documented here: http://inverse.ca/#support-plans
It is recommended
Ownership is fine this way, pf is part of the fingerbank group so when
the PacketFence processes start writing/updating the files after they're
installed, it takes ownership of them.
As for the Local DB, it contains the overrides you create, so unless
you're creating Fingerbank combinations
Hi Steve,
We managed to track this down to a recent issue with the update of
api.fingerbank.org
We have corrected the issue upstream, it should start updating again
automatically.
Also, I confirmed I'm able to get a confirmation email, in the event its
not working for you, I would say
Hi Yan,
Thanks for the very detailed explanations, not sure we could have got
there ourselves without the support seeing how advanced the
troubleshooting was.
I've opened an issue to get this bug more "official" and tracked in our
official BTS.
That will be included in PacketFence 8.0,
Hi Yan,
Actually this was easier to fix than I expected.
Here is the link to the patch:
https://github.com/inverse-inc/packetfence/commit/123dc79e7b8e72952a5963caebbbfd151947855e.diff
I tested it and I'm still able to perform the sync with the updated
script, we'll have to see if the MSFT
Hi Yan,
First, of all, thanks a lot for this very advanced troubleshooting. We
tried without success to get this problem reported to Microsoft by our
users without success.
For my personal curiosity, did you get this issue looked at through
Microsoft support directly ? Or through a
Ah,
I think I might guess what is happening, the new file is lacking the
executable bit.
Do this before restarting the process:
# chmod +x /usr/local/pf/bin/pfhttpd
On 2017-12-22 07:33 AM, Julien Semaan via PacketFence-users wrote:
Hi Yan,
Could you do it again, but then, providing
Hi Yan,
Could you do it again, but then, providing the output of this command
after doing it so I have more context
# journalctl -u packetfence-pfsso --since="5 minutes ago"
Thanks,
--
Julien Semaan
jsem...@inverse.ca :: +1 (866) 353-6153 *155 ::www.inverse.ca
Inverse inc. :: Leaders
Hi Yan,
Turns out the issue was easier to replicate than expected and even
better, the fix was easier than expected.
I've uploaded a new binary with the fix here:
https://support.inverse.ca/~jsemaan/pfhttpd
Here is how to apply the fix:
# mv /usr/local/pf/bin/pfhttpd
Hi Yan,
That config confirms my theory, having user/IP mapping sent to your
firewall is what we call SSO in PacketFence so you're technically doing it.
I've opened the following Github issue to track this problem:
https://github.com/inverse-inc/packetfence/issues/2847
I should be able to
I have a theory of what could be happening.
Seems like the formatting of the usernames might be causing issues with
multiple firewalls which you do seems to have.
Could you send me your /usr/local/pf/conf/firewall_sso.conf (with
obfuscated secrets obviously)
Regards,
--
Julien Semaan
Hi Yan,
Could you provide your PacketFence version?
Thanks
--
Julien Semaan
jsem...@inverse.ca :: +1 (866) 353-6153 *155 ::www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)
On 2017-12-21 09:56 AM, Yan via PacketFence-users wrote:
Hi
19 matches
Mail list logo
