the iplog_history table keeps getting bigger and bigger, so the webui shows the same IP again and again and again and again. IMHO, it should only show another entry if the IP changes.
On Thu, May 21, 2015 at 9:37 AM, Derek Wuelfrath <[email protected]> wrote: > 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 >>> >>> >> >
------------------------------------------------------------------------------
_______________________________________________ PacketFence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
