Hi Chris,
> Just a comment to your idea of using RADIUS accounting in place of
> locationlog ; is there some way of duplicating the RADIUS traffic flow
> ? Perhaps duplicating then diverting it (a T-connection), perhaps
> setting up a socket arrangement ...
With RADIUS proxying and Huntgroups you can do stuff similar to that.
For the record, we do not plan on replacing locationlog with RADIUS
accounting, we plan on having RADIUS accounting information update the
locationlog.
>
> As a current workaround, we are thinking of setting up an automatic
> deauthentication daily at, say, 2 or 3 am and closing all locationlog
> entries. Anyone still connected at that time would be forced to
> reauthenticate. Is there an easy way of configuring this in pf.conf ?
> (Otherwise it shouldn't be a big deal to write a small script for
> cron.) Of course, this timing would work for us as a university - it
> might not be very practical for a globally diversified business.
>
We have done that several times and there are several ways to do it ;)
For something like a semester massive de-registration the
expire_deadline in pf.conf can do. However for daily deadlines it is not
convenient.
Another configuration parameter is the expire_window. For example, if
you put it to 1d then all users will be unregistered 1 day after their
registration so someone registering at noon on the 18th would be
un-registered at noon on the 19th. Not exactly as you want but not far
from it and it's all built-in.
Another thing you can do is to use the new lib/pf/web/custom.pm
mechanism to customize node registration. Override
pf::web::web_node_register to set unregdate to
POSIX::strftime("%Y-%m-%d 02:00:00", localtime(time + 60 * 60 * 24));
See lib/pf/web/custom.pm there is an example that is commented out that
does session duration for guests.
Lastly, a cron job that does pfcmd node view all then awk then pfcmd
manage deregister ... would also do the trick.
So, there's more than one way to do it. Personally I would go with
lib/pf/web/custom.pm modifications.
>
> Yes, the pfcmd_vlan (pfsetvlan) log entries aren't there ... !
>
Not good.
> To answer your 127.0.0.1 questions :
> - Yes, the 'local trap' is in switches.conf
> - However, the local trap appears just *once* in logs/snmptrapd.log !
> That can't be correct ... Any further ideas of what, if anything,
> in the Debian port, might be causing that ? snmptrapd seems to be
> functioning ok otherwise ... why would it choke on 127.0.0.1 ?
What's in your conf/snmptrapd.conf?
> - Just ran a tcpdump scan on the PF server loopback and there was
> just *one* trap sent between the AP and the server - nothing to
> loopback
When you *registered* there was no trap from 127.0.0.1? It's not normal
and it won't work if you don't get one.
On your last test when you registered was there a call to flip.pl in the
logs? flip.pl should send a local (127.0.0.1) trap then pfsetvlan acts
on it calling pfcmd_vlan. Help me figure out what's not working properly
please. I'm thinking it might be snmptrapd or maybe firewall running on
the loopback?
>
> On another issue (but related to traps), from the time v2 was
> installed we had difficulty reading some traps with the routine
> reading complaining of 'bad' or 'incomplete' records. (Sorry, I no
> longer have the log entries for this.) The error cascaded into the
> database, which refused to accept a null field. A colleague, more
> versed in SNMP than I am, wrote a patch that seemingly fixes this. I'd
> like to send this on to you, in case it's useful.
>
> Please find the Cisco.pm perl modules attached - both the new and the
> original : do a diff between them ...
Not sure why we are not grabbing the ifIndex out of this trap in the
original.. I'll look into it. Thanks for letting me know.
>
> Finally, there is a new version of the 'installation of PF on Debian'
> doc coming soon. Please just throw away the former one I sent some
> months ago - it was preliminary and is full of errors and
> inaccuracies. This one is quite a bit 'tighter'. Also, the
> accompanying scripts - httpd, etc. - have been rewritten.
Great! Can't wait to get it. On our side of things the debian packaging
is on the horizon (post 2.0.1) so your guide will definitely help us get
that done quicker. And we will need testers ;)
Cheers!
--
Olivier Bilodeau
[email protected] :: +1.514.447.4918 *115 :: www.inverse.ca
Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Packetfence-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/packetfence-users
