Hi Olivier,
Thanks for all the good comment !
> 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.
This sounds brilliant to me and really worth doing - it gets around
many of the semi-spooky timing issues that have appeared and should
significantly simplify things. Looking forward to it. At the moment
I'm socked into scrambling to get our installation working, but would
like to participate in the testing when this change begins to take
shape ...
For our daily deauthentication :
> So, there's more than one way to do it. Personally I would go with
> lib/pf/web/custom.pm modifications.
Agreed ; seems the best approach ; although,
> Lastly, a cron job that does pfcmd node view all then awk then pfcmd
> manage deregister ... would also do the trick.
while a bit kludgy should work nicely, as well, as there won't be
*that* many people around at 2am ... (There are unlikely to be any
mass deauthentications at that hour.)
Eventually, it would be a nice config option ...
> What's in your conf/snmptrapd.conf?
Thanks ; attached ...
> 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.
Yes, that's the current state - it's not working.
> 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?
Ah ! Grepped through the logs - and the records for flip.pl seem to
have been moved to pf.send.log ... hadn't noticed that before. Well,
the last entry is from 11th January. I don't remember what, if
anything, I changed at that time in the PF config.
All iptables on the server are entirely open ; no entries ; universal
ACCEPT, as a development setup. So no firewall issues
... snmptrapd.log shows virtually nothing - very far from any
diagnostics ... sending it also, just in case, but I don't think it's
interesting.
As I recall, some months ago the 'testing' version of Debian's
snmptrapd had issues with snmp security ... Will take another look at
the relevant versions. (Thanks for the idea ...)
> 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.
Glad the workaround was useful.
> 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 ;)
Good to hear about the official Debian packaging ! For me, a major
(and not totally resolved) issue has been the complement of necessary
Perl mods. We *seem* to have everything necessary but I'm afraid that
there has been massive duplication - and I won't even begin to
speculate about Perl mods versions differences ... A scan of the list
(Debian vs. CPAN packaging) by you Perl gurus would be a major
improvement. My docs, etc. need a final scan and a little copy editing
- will try to get them out to you by the end of this week.
Thanks again for the attention Olivier ; I'm curious to find out
what's rattling around on the snmp level ; will let you know about the
Debian snmp versions question.
Cheers - and best wishes,
Chris
authCommunity log pub_siav
format1 %V|%#04.4y-%#02.2m-%02.2l|%#02.2h:%#02.2j:%#02.2k|%b|%a|BEGIN
TYPE %w END TYPE BEGIN SUBTYPE %q END SUBTYPE BEGIN VARIABLEBINDINGS %v END
VARIABLEBINDINGS\n
format2 %V|%#04.4y-%#02.2m-%02.2l|%#02.2h:%#02.2j:%#02.2k|%b|%a|BEGIN
TYPE %w END TYPE BEGIN SUBTYPE %q END SUBTYPE BEGIN VARIABLEBINDINGS %v END
VARIABLEBINDINGS\n
NET-SNMP version 5.4.1
2011-01-18|19:44:39|UDP: [137.194.50.147]:161|137.194.50.147|BEGIN TYPE 2 END
TYPE BEGIN SUBTYPE 0 END SUBTYPE BEGIN VARIABLEBINDINGS .1.3.6.1.2.1.2.2.1.1.50
= INTEGER: 50 END VARIABLEBINDINGS
2011-01-18|19:44:58|UDP: [137.194.50.147]:161|137.194.50.147|BEGIN TYPE 3 END
TYPE BEGIN SUBTYPE 0 END SUBTYPE BEGIN VARIABLEBINDINGS .1.3.6.1.2.1.2.2.1.1.50
= INTEGER: 50 END VARIABLEBINDINGS
2011-01-18|20:10:27|UDP: [137.194.50.147]:161|137.194.50.147|BEGIN TYPE 2 END
TYPE BEGIN SUBTYPE 0 END SUBTYPE BEGIN VARIABLEBINDINGS .1.3.6.1.2.1.2.2.1.1.50
= INTEGER: 50 END VARIABLEBINDINGS
2011-01-18|20:10:43|UDP: [137.194.50.147]:161|137.194.50.147|BEGIN TYPE 3 END
TYPE BEGIN SUBTYPE 0 END SUBTYPE BEGIN VARIABLEBINDINGS .1.3.6.1.2.1.2.2.1.1.50
= INTEGER: 50 END VARIABLEBINDINGS
2011-01-19|09:21:26|UDP: [137.194.51.157]:57877|137.194.51.157|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .2 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.2.840.10036.1.1.1.17.1 = INTEGER: 23|.1.2.840.10036.1.1.1.18.1 = Hex-STRING:
CC 08 E0 D2 01 81 END VARIABLEBINDINGS
2011-01-19|09:21:27|UDP: [137.194.51.157]:57877|137.194.51.157|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .2 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.2.840.10036.1.1.1.17.1 = INTEGER: 23|.1.2.840.10036.1.1.1.18.1 = Hex-STRING:
CC 08 E0 D2 01 81 END VARIABLEBINDINGS
2011-01-19|09:21:28|UDP: [137.194.51.157]:57877|137.194.51.157|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .2 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.2.840.10036.1.1.1.17.1 = INTEGER: 23|.1.2.840.10036.1.1.1.18.1 = Hex-STRING:
CC 08 E0 D2 01 81 END VARIABLEBINDINGS
------------------------------------------------------------------------------
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
