PacketFence - BTS - PacketFence
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001354PacketFenceconfigurationpublic2012-01-03 06:422012-02-28 14:31
Reporterdwygodzki 
Assigned Toobilodeau 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version3.1.0 
Target Version3.2.0Fixed in Version3.2.0 
fixed in git revision
fixed in mtn revision952e9a756e05770a295ae2d53b112381d575df48
Summary0001354: snmp V3 multiple switch one username
Descriptiongenerating only one user line in /usr/local/pf/var/snmptrapd.con

Several switches, each with different EngineId but same user ( pfv3read : read ;
pfv3write : write; pfv3read: trap)

The file /usr/local/pf/var/conf/snmptrapd.conf contains only two line of the
type“creatuser”:

createUser -e 0017837EEA21 pfv3write MD5 mypasswd AES mypasswd

createUser -e 001794094680 pfv3read MD5 mypasswd AES mypasswd

Steps To Reproduce
Additional InformationIf changing username for one switch (user: pfvr3test)
then one more line in generated snmptrad.conf ...

For purpose of the test we try to launch snmptrapd manually after adding
a creatuser line with the EngineID configured for other switchs

Snmptrapd did not complains.

/usr/sbin/snmptrapd -n -c /tmp/snmptrapd.conf -C -A
-Lf /tmp/log_snmp.log -p /tmp/snmpd.pid -On

Seem to be a pf issue.

The process that generate the snmptrapd.conf from templates
(services.pm : sub generate_snmptrapd_conf on line 333 ) reads only one
section from switch.conf

Workaround:
1) snmp V2 (not really an option)
2) Different username for each switch.


Tagssnmp, snmpv3
Relationships
related to 0001386closed obilodeau SNMPv3 different users and different engine Ids on different switches 
Attached Filespatch snmptrapd-snmpv3-engineid-per-user-fix.patch (8,013) 2012-01-10 09:42
https://www.packetfence.org/bugs/file_download.php?file_id=125&type=bug
Issue History
Date ModifiedUsernameFieldChange
2012-01-03 06:42dwygodzkiNew Issue
2012-01-03 10:42dwygodzkiNote Added: 0002508
2012-01-05 06:22dwygodzkiTag Attached: snmp
2012-01-05 06:22dwygodzkiTag Attached: snmpv3
2012-01-05 07:48dwygodzkiNote Added: 0002511
2012-01-05 08:41obilodeauNote Added: 0002512
2012-01-05 08:41obilodeauStatusnew => confirmed
2012-01-05 08:41obilodeauTarget Version => +1
2012-01-05 08:41obilodeauAdditional Information Updated
2012-01-05 19:52obilodeauStatusconfirmed => assigned
2012-01-05 19:52obilodeauAssigned To => obilodeau
2012-01-05 20:02obilodeauNote Added: 0002516
2012-01-05 21:31obilodeauNote Added: 0002517
2012-01-10 09:15obilodeauNote Added: 0002522
2012-01-10 09:42obilodeauFile Added: snmptrapd-snmpv3-engineid-per-user-fix.patch
2012-01-10 09:46obilodeaumtn revision => 952e9a756e05770a295ae2d53b112381d575df48
2012-01-10 09:46obilodeauNote Added: 0002523
2012-01-10 09:46obilodeauStatusassigned => resolved
2012-01-10 09:46obilodeauFixed in Version => trunk
2012-01-10 09:46obilodeauResolutionopen => fixed
2012-01-18 08:29dwygodzkiNote Added: 0002540
2012-01-18 08:29dwygodzkiStatusresolved => feedback
2012-01-18 08:29dwygodzkiResolutionfixed => reopened
2012-01-18 08:49obilodeauNote Added: 0002541
2012-01-18 12:10dwygodzkiNote Added: 0002542
2012-02-28 14:11obilodeauNote Added: 0002579
2012-02-28 14:11obilodeauFixed in Versiontrunk =>
2012-02-28 14:18obilodeauNote Added: 0002580
2012-02-28 14:18obilodeauStatusfeedback => resolved
2012-02-28 14:18obilodeauFixed in Version => trunk
2012-02-28 14:18obilodeauResolutionreopened => fixed
2012-02-28 14:20obilodeauRelationship addedrelated to 0001386
2012-02-28 14:22obilodeauTarget Version+1 => 3.2.0
2012-02-28 14:22obilodeauFixed in Versiontrunk => 3.2.0
2012-02-28 14:31obilodeauNote Added: 0002591
2012-02-28 14:31obilodeauStatusresolved => closed

Notes
(0002508)
dwygodzki   
2012-01-03 10:42   
from snmptrapd doc :
...
authUser TYPES [-s MODEL] USER [LEVEL [OID | -v VIEW ]]
    authorises SNMPv3 notifications with the specified user to trigger the types of processing listed. By default, this will accept authenticated requests. (authNoPriv or authPriv). The LEVEL field can be used to allow unauthenticated notifications (noauth), or to require encryption (priv), just as for the SNMP agent.
    With both of these directives, the OID (or -v VIEW) field can be used to retrict this configuration to the processing of particular notifications.
    Note:
    Unlike the VACM processing described in RFC 3415, this view is only matched against the snmpTrapOID value of the incoming notification. It is not applied to the payload varbinds held within that notification.
...
createUser username (MD5|SHA) authpassphrase [DES|AES]
    See the snmpd.conf(5) manual page for a description of how to create SNMPv3 users. This is roughly the same, but the file name changes to snmptrapd.conf from snmpd.conf.
...
(0002511)
dwygodzki   
2012-01-05 07:48   
Bug fixed ...


 diff -u orig/services.pm services.pm


--- orig/services.pm 2012-01-05 13:42:50.000000000 +0100
+++ services.pm 2012-01-05 13:39:50.000000000 +0100
@@ -336,6 +336,7 @@
     $tags{'authLines'} = '';
     $tags{'userLines'} = '';
     my %SNMPv3Users;
+ my %SNMPv3EngineID; # Important in SNMPV3
     my %SNMPCommunities;
     my $switchFactory = pf::SwitchFactory->getInstance();
     my %switchConfig = %{ $switchFactory->{_config} };
@@ -352,7 +353,13 @@
                 $logger->error("Can not instantiate switch $key!");
             } else {
                 if ( $switch->{_SNMPVersionTrap} eq '3' ) {
- $SNMPv3Users{ $switch->{_SNMPUserNameTrap} }
+ #Modified so we have the username @ engineID , diferent key for the case same user differnt engineID
+ my $EngineID = $switch->{_SNMPEngineID};
+ $SNMPv3Users{ $switch->{_SNMPUserNameTrap} }
+ = $switch->{_SNMPUserNameTrap} ;
+ #obviously it's quiet verbose a hash where value=key ..
+ #but if so we can add option to the line like for the other hash with the EngineID...
+ $SNMPv3EngineID{ $EngineID }
                         = '-e ' . $switch->{_SNMPEngineID} . ' '
                         . $switch->{_SNMPUserNameTrap} . ' '
                         . $switch->{_SNMPAuthProtocolTrap} . ' '
@@ -365,11 +372,17 @@
             }
         }
     }
- foreach my $userName ( sort keys %SNMPv3Users ) {
+ foreach my $userName ( sort keys %SNMPv3EngineID ) {
         $tags{'userLines'}
- .= "createUser " . $SNMPv3Users{$userName} . "\n";
+ .= "createUser " . $SNMPv3EngineID{$userName} . "\n";
+ }
+ #several creatuser line that differ by the engineID only
+ #but about the authlines they aren't differing ...
+ #so if we index by engine id , we receive some identical line
+foreach my $userName ( sort keys %SNMPv3Users ) {
         $tags{'authLines'} .= "authUser log $userName priv\n";
     }
+
     foreach my $community ( sort keys %SNMPCommunities ) {
         $tags{'authLines'} .= "authCommunity log $community\n";
     }
(0002512)
obilodeau   
2012-01-05 08:41   
Thanks for the report and fix! We will integrate it for our next release.
(0002516)
obilodeau   
2012-01-05 20:02   
Be careful with patch formatting. Next time attach the patch instead of pasting it as a note. Fixing it now.
(0002517)
obilodeau   
2012-01-05 21:31   
Ok, I'm taking the opportunity to do regression testing here and thus I need to split things up to make them testable. I've made a lot of progress but it's not quite finished.
(0002522)
obilodeau   
2012-01-10 09:15   
Only trap users are added to snmptrapd.conf. Is the engine ID mandatory? Does it work without it?
(0002523)
obilodeau   
2012-01-10 09:46   
Here's patch against 3.1.0. It's larger because I've refactored things to make them testable.

The revision which fixes the issue (952e9a756e05770a295ae2d53b112381d575df48) contains a regression test also.

Please re-open the bug if it doesn't work for you.

Also, if you would test without the '-e engineid' and start your snmptrapd by hand and report if it works or not I would appreciate it.
(0002540)
dwygodzki   
2012-01-18 08:29   
running snmptrapd by hand without the "-e"
nothing poped up in the log.
Quiet logical in snmpV3 engineid is mandatory ...

Wireshark have seen all the snmp trap on the correct interface, however.

By the way, if you want decrypted packet in wireshark , you have to configure it: edit, preferences, protocols, snmp,usertable:edit,new... put there username, password , engineid....

and snmp packet in the clear in wireshark.
(0002541)
obilodeau   
2012-01-18 08:49   
Have you tried the patch attached to this ticket? It does provide the -e parameter.
(0002542)
dwygodzki   
2012-01-18 12:10   
ok just tried the patch...
seems that now it doesn't manage the case where we put a different user for different engineid ...
now it generate a conf file withe the good "creatuser -e <engineid> lines" but use the same user each time.

I changed the username for one switch in switches.conf but then it keep the previous lines in the generated snmptrad.conf.

actually with "our" patch it works ;)

good idea to have service/snmptrapd.pm now

snmptrapd needs "-e <engineid>" lines , without them the /usr/local/pf/log/snmptrapd.log keep empty , it needs it to decipher the traps .
(0002579)
obilodeau   
2012-02-28 14:11   
re-opened will re-look at it. sorry for the delay, it slipped under the radar
(0002580)
obilodeau   
2012-02-28 14:18   
Re-reading your comment made it clear that this is not the same issue: "snmp V3 multiple switch one username". Closing this one and opening a new one.
(0002591)
obilodeau   
2012-02-28 14:31   
Fixed in recently released 3.2.0.