Hello Tim,
As far as I can tell, it has always been a field that requires minutes instead
of seconds on any version of the Palo.
I filled an “issue” in the Github repo
(https://github.com/inverse-inc/packetfence/issues/571) to make sure we check
that out.
Maybe its just what I feel are a lot of entries. It has an entry for every
lease. So on the registration network with a 5 minute lease time, if someone
is just camped out there for an hour, i get 12 iplog entries for the same ip.
Seems to me that it should only be one entry.
Starting in PFv5, entries in iplog have IP as unique key. Every time a lease is
renewed, the existing entry will be updated and a new one will be added to
iplog_history. Is this what you see ?
(
https://github.com/inverse-inc/packetfence/blob/devel/db/upgrade-4.7.0-5.0.0.sql#L55
)
Cheers!
dw.
--
Derek Wuelfrath
[email protected] :: +1.514.447.4918 (x110) :: +1.866.353.6153 (x110)
Inverse inc. (www.inverse.ca) :: Leaders behind SOGo (www.sogo.nu) and
PacketFence (www.packetfence.org)
On May 20, 2015 at 05:12:37, Tim DeNike ([email protected]) wrote:
As far as I can tell, it has always been a field that requires minutes instead
of seconds on any version of the Palo.
Maybe its just what I feel are a lot of entries. It has an entry for every
lease. So on the registration network with a 5 minute lease time, if someone
is just camped out there for an hour, i get 12 iplog entries for the same ip.
Seems to me that it should only be one entry.
On Wed, May 20, 2015 at 1:36 AM, Derek Wuelfrath <[email protected]> wrote:
I am using 6.1, but Ive been using a custom perl script to update from RADIUS
accounting since 5.0 so it hasn't changed.
So that means that, from what you can experience, it is broken ? I'll have a
deeper look at it because we do have some clients with which it is working fine.
Im on 5.0. Maybe it was the short lease times for the registration/isolation
network?
Since PacketFence v.5, DB entries for iplog are handled differently. I'm not
sure I understand what kind of "a lot of entries" you were getting.
Cheers!
dw.
--
Derek Wuelfrath
[email protected] :: +1.514.447.4918 (x110) :: +1.866.353.6153 (x110)
Inverse inc. (www.inverse.ca) :: Leaders behind SOGo (www.sogo.nu) and
PacketFence (www.packetfence.org)
On May 19, 2015 at 10:48:06, Tim DeNike ([email protected]) wrote:
I am using 6.1, but Ive been using a custom perl script to update from RADIUS
accounting since 5.0 so it hasn't changed.
Im using the UDP reflector for L3 DHCP messages now. This wouldn't have worked
when I was using DHCP Relay before.
Im on 5.0. Maybe it was the short lease times for the registration/isolation
network?
On Tue, May 19, 2015 at 10:00 AM, Derek Wuelfrath <[email protected]> wrote:
Hello Tim,
First of all, thanks for reporting!
Problem: Palo Alto timeout expects minutes, not seconds (At least on 6.1,
can't say for sure, so the timeout is set WAY higher than it should be.
Resolution: $timeout = ( $timeout / 60); in PaloAlto.pm
Were you using Palo Alto before 6.1 ? I’d change it but I don’t want it to
break previous versions. I’ll have a look at their “Changelog”.
Problem: SSO (And update_iplog in general from pfdhcplistener) use the clients
REQUESTED lease time for SSO updates. For an iPhone, I see 7776000. This
isn't what the DHCP server said to use, so its inaccurate.
Solution: Move the call to firewallsso from the parse_dhcp_request sub to
parse_dhcp_ack sub.
You are effecively right. We should consider the ACK in that case. The problem
that I see would be when PacketFence is configured to receive a copy of the
DHCP traffic in L3 environment… in thoses cases, ACK is sent unicast to the
requesting client which means that PacketFence wouldn’t receive a copy of it...
Also. I actually disabled update_iplog in parse_dhcp_request, and for DHCPACK
CIADDR in parse_dhcp_ack because it seems to generate a TON of extra iplog
entries every time devices rebind. Ive never seen one with a lease time
defined, so it seems redundant.
Which version of PacketFence are you running ? Starting with v5, we modified
iplog so that there’s no new entry beeing created and we are “updating”
existing ones.
Cheers!
dw.
--
Derek Wuelfrath
[email protected] :: +1.514.447.4918 (x110) :: +1.866.353.6153 (x110)
Inverse inc. (www.inverse.ca) :: Leaders behind SOGo (www.sogo.nu) and
PacketFence (www.packetfence.org)
On May 15, 2015 at 12:53:45, Tim DeNike ([email protected]) wrote:
Problem: Palo Alto timeout expects minutes, not seconds (At least on 6.1,
can't say for sure, so the timeout is set WAY higher than it should be.
Resolution: $timeout = ( $timeout / 60); in PaloAlto.pm
Problem: SSO (And update_iplog in general from pfdhcplistener) use the clients
REQUESTED lease time for SSO updates. For an iPhone, I see 7776000. This
isn't what the DHCP server said to use, so its inaccurate.
Solution: Move the call to firewallsso from the parse_dhcp_request sub to
parse_dhcp_ack sub.
Also. I actually disabled update_iplog in parse_dhcp_request, and for DHCPACK
CIADDR in parse_dhcp_ack because it seems to generate a TON of extra iplog
entries every time devices rebind. Ive never seen one with a lease time
defined, so it seems redundant.
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
PacketFence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
