Hi again Olivier,
Continuing this thread, I searched further into what PF and the AP
were doing with snmp and discovered that the issue we had with the
Debian implementation of snmptrapd some months ago has
reappeared. When I moved our development environment from a normal
server to the 'production' (KVM) VM, the system there is Debian stable
(with some backports, of course). The previous version had been
'testing'. Using an earlier version of snmptrapd seemed to work well
and didn't have the glitch. I guess what has happened is that the
older version has had an incremental upgrade on the production machine
- which brought in the original buggy behaviour. This has become a
major obstacle to the Debian implementation. So I redid the kludgy
patch, allowing snmp traps to function but they are without security -
ok for a development environment, not so great for production. The
patch was to change the conf/templates/snmptrapd.conf file to
eliminate the %%userLines%% and %%authLines%% entries and to add a
'disableAuthorization yes' line. Now it works - but not very securely
- we definitely need to find a way to work around this one ... Do you
think it might help to get the source of the newest version and
compile it here ?
Other small (?) things which may or may not affect the issues I am
currently having with PF and freeradius is the following, which
appears *once* after freeradius is started on the first authentication
attempt :
--------------------------------------------------------
Found Auth-Type = Perl
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group Perl {...}
Use of uninitialized value (#1)
(W uninitialized) An undefined value was used as if it were
already defined. It was interpreted as a "" or a 0, but maybe it
was a mistake. To suppress this warning assign a defined value to
your variables.
To help you figure out what was undefined, perl will try to tell
you the name of the variable (if any) that was undefined. In some
cases it cannot do this, so it also tells you what operation you
used the undefined value in. Note, however, that perl optimizes
your program and the operation displayed in the warning may not
necessarily appear literally in your program. For example, "that
$foo" is usually optimized into "that " . $foo, and the warning
will refer to the concatenation (.) operator, even though there
is no . in your program.
--------------------------------------------------------
After its first appearance, it doesn't appear again for the duration
of the session but reappears (once) when freeradius is started. Don't
know whether or not it's meaningful.
Finally, probably due to the mess in my assembly of Perl modules
(mixing the Debian versions with CPAN), I can't start *any* Perl
related program - including PF itself and freeradius (because of
packetfence.pm) - without the following prefix :
LD_PRELOAD='/usr/lib/libperl.so.5.10'
Normally, something like this would mean that there was a symlink
missing somewhere, but I suppose that it could as well be some sort of
central config, paths, etc., in the Perl setup.
Any idea ?
Thanks Olivier, for the attention.
Best wishes,
Chris
On Tue 18.Jan'11 at 16:19:32 -0500, Olivier Bilodeau wrote:
> Hi Chris,
>
> >>
> >> 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.
> >
>
> Filed and fixed #1157: dot11Deauthentication traps causing warnings and
> potentially crashing threads
> http://www.packetfence.org/bugs/view.php?id=1157
>
> I committed a fix in pfsetvlan but no need for you to update as your fix
> works around the problem. Thanks for the report!
>
> 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
>
------------------------------------------------------------------------------
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
