PacketFence
Bug Tracking System
Main | My View | View Issues | Change Log | Roadmap
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001098PacketFencecorepublic2010-10-22 10:212011-10-24 20:24
Reporterrafamiga 
Assigned Toobilodeau 
PriorityhighSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version3.0.0Fixed in Version3.0.0 
Summary0001098: hard-coded snmptrapd invocation fails on "printable" MAC addresses
DescriptionWhen a node has a MAC address that is "printable" (it "fits" into the locale's perception of "printable string") it gets reported as STRING, not HEX-STRING. Example:

Oct 20 16:29:38 pfsetvlan(0) DEBUG: adding trapline 2010-10-20|14:29:36|
UDP: [192.168.251.37]:58414|0.0.0.0|BEGIN TYPE 0 END TYPE BEGIN SUBTYPE
0 END SUBTYPE BEGIN VARIABLEBINDINGS .1.3.6.1.2.1.1.3.0
= Timeticks: (464278347) 53 days, 17:39:43.47|.1.3.6.1.6.3.1.1.4.1.0 =
OID: .1.3.6.1.4.1.9.9.315.0.0.1|.1.3.6.1.2.1.2.2.1.1.10041 = Wrong Type
(should be INTEGER): Gauge32: 10041|.1.3.6.1.2.1.31.1.1.1
.1.10041 = STRING:
FastEthernet0/41|.1.3.6.1.4.1.9.9.315.1.2.1.1.10.10041 = STRING:
"pZ??Am" END VARIABLEBINDINGS to queued trapList
(main::addTrapLineToQueue)

The "pZ??Am" is, in fact, a MAC-address of the node causing violation.

This happens because snmptrapd is launched with no HEX-STRING enforcement.

This can be fixed by altering $flags{'snmptrapd'} in lib/pf/lib/services.pm option "-On" to "-Onx".

OTOH I'm not 100% sure altering this won't break other stuff. You'd check it.
TagsNo tags attached.
fixed in git revision
fixed in mtn revision69347a6378a28890628a182b3348b1e1524aacf8
Attached Filespatch file icon snmptrapd-stringified-mac-parsing-fix.patch [^] (26,601 bytes) 2011-08-19 15:33 [Show Content]

- Relationships
related to 0001495resolveddwuelfrath Printable MAC bug on SNMP GETs 

-  Notes
(0001730)
rafamiga (reporter)
2010-10-22 10:24

 See //www.opensubscriber.com/message/net-snmp-users@lists.sourceforge.net/290834.html">http://www.opensubscriber.com/message/net-snmp-users@lists.sourceforge.net/290834.html [//www.opensubscriber.com/message/net-snmp-users@lists.sourceforge.net/290834.html" target="_blank">^]
(0001764)
obilodeau (reporter)
2010-11-18 14:01

 Can you tell me your:
- exact MAC address causing the problem?
- Net-SNMP version
- OS distribution (are you using CentOS?)

With the number of deployments we made I'm surprised to see such a strange issue appear so late, I'll definitely try to reproduce first. Then if using -Onx instead of -On fixes it and introduce no regression we will go with that.

Thanks again for your report!
(0001770)
obilodeau (reporter)
2010-11-19 17:09

 Faced a regression today where someone tried the '-Onx' fix.

Local traps are sent in String format and the -Onx explicitly changed it to Hex-String which caused the trap parser to fail. Impact: no wireless deauthentication possible for all hardware types.

So I would really like to get the MAC you had the problem with and try to reproduce the issue first.
(0001771)
rafamiga (reporter)
2010-11-22 05:06

 Yup, it's Centos 5.

Linux niach.non.3dart.com 2.6.18-164.6.1.el5xen 0000001 SMP Tue Nov 3 16:48:13 EST 2009 x86_64 x86_64 x86_64 GNU/Linux

I'm using -Onx for some time and it looks that setting it didn't break a thing.

# snmptrapd --version

NET-SNMP Version: 5.3.2.2

net-snmp-utils-5.3.2.2-7.el5_4.2
net-snmp-libs-5.3.2.2-7.el5_4.2
net-snmp-5.3.2.2-7.el5_4.2

MAC is the one from the submission -- 70:5a:b6:af:41:6d [pZ..Am].
(0001772)
rafamiga (reporter)
2010-11-22 05:09

 Although I'm using Cisco WLC 4402, I don't have traps set for WLAN deassociation so I might have missed the problem you've described.
(0001773)
obilodeau (reporter)
2010-11-22 09:31

 Thanks for the info, I'll try to reproduce.

WLAN deassociation is not a trap sent by the WLC. It's a local trap sent by PacketFence to itself when a VLAN change is required (or a wireless deassociation). This is used when a node changes states. For example, when a node registers it needs to be migrated from the registration VLAN into the normal VLAN. The trap is only used as an internal messaging mechanism (thread-related).

With -Onx the trap was encoded as an Hex-String instead of a String causing PacketFence not to recognize the trap so no deassociation happened.
(0001774)
rafamiga (reporter)
2010-11-22 09:39

 Yeah, I remember it now. AFAIR it's also used by "flip" script.
(0001775)
obilodeau (reporter)
2010-11-22 09:40

 Yes, flip generates that trap actually.
(0001828)
fgaudreault (viewer)
2011-01-21 15:34

 I cannot reproduce the issue, even by hard coding the MAC on the interface :

2011-01-21|20:26:35|UDP: [10.0.0.2]:62097|0.0.0.0|BEGIN TYPE 0 END TYPE BEGIN SUBTYPE 0 END SUBTYPE BEGIN VARIABLEBINDINGS .1.3.6.1.2.1.1.3.0 = Timeticks: (338932487) 39 days, 5:28:44.87|.1.3.6.1.6.3.1.1.4.1.0 = OID: .1.3.6.1.4.1.9.9.315.0.0.1|.1.3.6.1.2.1.2.2.1.1.10007 = Wrong Type (should be INTEGER): Gauge32: 10007|.1.3.6.1.2.1.31.1.1.1.1.10007 = STRING: FastEthernet0/7|.1.3.6.1.4.1.9.9.315.1.2.1.1.10.10007 = Hex-STRING: 70 A5 B6 AF 41 6D END VARIABLEBINDINGS

The problematic trap seems to be sent by the WLC itself. It's possible that your WLC is running an old code version...

If you can provide more informations, we could test a little more. For now, I guess this issue is closed.
(0001847)
obilodeau (reporter)
2011-02-02 16:53

 We had a report of another instance of the problem on our mailing list. We are waiting for more information from the client before re-opening this ticket.

Here are the content of the trap on snmptrapd.log:

2011-01-28|13:45:16|UDP: [10.10.10.252]:1025|10.10.10.252|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.3.6.1.4.1.45.1.6.5.3.12.1.1.2.46 = INTEGER:
2|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.2.46 = INTEGER:
46|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.2.46 = STRING: "d1P_xv" END
VARIABLEBINDINGS


But we should be receiving something like this:

2011-01-28|13:45:16|UDP: [10.10.10.252]:1025|10.10.10.252|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.3.6.1.4.1.45.1.6.5.3.12.1.1.2.46 = INTEGER:
2|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.2.46 = INTEGER:
46|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.2.46 = Hex-STRING: 64 31 50 5f 77 77 END
VARIABLEBINDINGS
(0001866)
obilodeau (reporter)
2011-02-15 13:58

 More information from the mailing list about the issue. It happens on Nortel switches. We should look into adding the MIB to snmptrapd and see if it resolves the problem.

Lets say it does resolve the problem. Are we able to redistribute these files?

Hi, to answer your questions:

>> >>- What is the model of the device that send this kind of traps?
The switches that are sending the traps are Nortel 470's and 5500's. The
computers that are generating the traps are mostly hp's: their ethernet
adapters are RealTek PCIE gbe family controller's with mac addrs=
64:31:50:xx:xx:xx


>> >>- What is its firmware version?
Firmware/software versions are 6.0.0.9/6.1.1.017 for 5500's and
3.6.0.7/3.7.4.15 for 470's


>> >>- Are you running PF on CentOS?
No, we are running PF on Linux


>> >>- Can you send us your generated snmptrapd.conf?
our snmptrapd.conf is as follows: 

authCommunity log public
format1       %V|%0000004.4y-%0000002.2m-%02.2l|%0000002.2h:%0000002.2j:%0000002.2k|%b|%a|BEGIN
TYPE %w END TYPE BEGIN SUBTYPE %q END SUBTYPE BEGIN VARIABLEBINDINGS %v END
VARIABLEBINDINGS\n
format2       %V|%0000004.4y-%0000002.2m-%02.2l|%0000002.2h:%0000002.2j:%0000002.2k|%b|%a|BEGIN
TYPE %w END TYPE BEGIN SUBTYPE %q END SUBTYPE BEGIN VARIABLEBINDINGS %v END
VARIABLEBINDINGS\n


>> >>- Can you do a tcpdump using tshark and send us the .pcap file of this
trap.

I have attached a packet capture of the trap that is sent from our switch to
our packetfence server. There doesn't appear to any differences between this
trap and the traps for other working mac addresses, so it is looking like
the issue might be with how the snmptrapd process is interpreting the traps,
not the trap itself (see below). 



Some additional info:

We have found that the mac address in the trap is being interpreted as a
String instead of a Hex-String in the problem cases, with each hex-char pair
being converted to an ASCII char. Some combinations of hex characters in the
mac address seems to cause issues while others do not - it appears to depend
on the first pair and the last 2 pairs of mac addr hex chars. We determined
this by making minor modifications of the mac address characters (at the
adapter) and found that some are interpreted properly. The snmptrapd logs
included below show some mac addresses that work and others that do not. You
can see that:

- 61 31 50 5F 0C 35 = d1P_(new page)5  ... note hex to ascii: 61=d, 31=1,
50=P, 5F=_, 0C=new page, 35=5
- 00 31 50 5F 0C 35 works
- 64 31 50 01 01 01 works
- 64 31 50 5F 1C 35 works
- 61 31 50 5e 0C 35 = d1P^(new page)5
- 64 00 00 00 0C 00 works
- 64 31 00 00 0C 00 works
- 64 00 50 00 0C 00 works
- 64 00 00 5F 0C 00 works
- 64 31 50 5F 0A 00 works
- 64 31 50 5F 0D 00 works
- 64 31 50 5F 0C 00 works
- 64 31 50 5F 0A 35 = d1P^(new line)5
 

Snmptrapd logs:

2011-02-07|14:25:55|UDP: [172.16.75.75]:1024|172.16.75.75|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.3.6.1.4.1.45.1.6.5.3.12.1.1.1.1 = INTEGER:
1|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.1.1 = INTEGER:
1|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.1.1 = STRING: "d1P_
5" END VARIABLEBINDINGS
2011-02-07|14:31:42|UDP: [172.16.75.75]:1024|172.16.75.75|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.3.6.1.4.1.45.1.6.5.3.12.1.1.1.3 = INTEGER:
1|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.1.3 = INTEGER:
3|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.1.3 = Hex-STRING: 00 31 50 5F 0C 35  END
VARIABLEBINDINGS

2011-02-07|17:26:29|UDP: [172.16.75.75]:1025|172.16.75.75|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.3.6.1.4.1.45.1.6.5.3.12.1.1.1.5 = INTEGER:
1|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.1.5 = INTEGER:
5|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.1.5 = Hex-STRING: 64 31 50 01 01 01  END
VARIABLEBINDINGS

2011-02-07|17:30:46|UDP: [172.16.75.75]:1025|172.16.75.75|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.3.6.1.4.1.45.1.6.5.3.12.1.1.1.7 = INTEGER:
1|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.1.7 = INTEGER:
7|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.1.7 = Hex-STRING: 64 31 50 5F 1C 35  END
VARIABLEBINDINGS

2011-02-07|17:33:28|UDP: [172.16.75.75]:1025|172.16.75.75|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.3.6.1.4.1.45.1.6.5.3.12.1.1.1.7 = INTEGER:
1|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.1.7 = INTEGER:
7|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.1.7 = STRING: "d1P^
5" END VARIABLEBINDINGS

2011-02-07|17:35:06|UDP: [172.16.75.75]:1025|172.16.75.75|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.3.6.1.4.1.45.1.6.5.3.12.1.1.1.9 = INTEGER:
1|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.1.9 = INTEGER:
9|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.1.9 = Hex-STRING: 64 00 00 00 0C 00  END
VARIABLEBINDINGS

2011-02-07|17:35:40|UDP: [172.16.75.75]:1025|172.16.75.75|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.3.6.1.4.1.45.1.6.5.3.12.1.1.1.9 = INTEGER:
1|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.1.9 = INTEGER:
9|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.1.9 = Hex-STRING: 64 31 00 00 0C 00  END
VARIABLEBINDINGS

2011-02-07|17:36:19|UDP: [172.16.75.75]:1025|172.16.75.75|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.3.6.1.4.1.45.1.6.5.3.12.1.1.1.9 = INTEGER:
1|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.1.9 = INTEGER:
9|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.1.9 = Hex-STRING: 64 00 50 00 0C 00  END
VARIABLEBINDINGS

2011-02-07|17:36:48|UDP: [172.16.75.75]:1025|172.16.75.75|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.3.6.1.4.1.45.1.6.5.3.12.1.1.1.9 = INTEGER:
1|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.1.9 = INTEGER:
9|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.1.9 = Hex-STRING: 64 31 50 00 0C 00  END
VARIABLEBINDINGS

2011-02-07|17:37:58|UDP: [172.16.75.75]:1025|172.16.75.75|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.3.6.1.4.1.45.1.6.5.3.12.1.1.1.9 = INTEGER:
1|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.1.9 = INTEGER:
9|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.1.9 = Hex-STRING: 64 00 00 5F 0C 00  END
VARIABLEBINDINGS

2011-02-07|17:39:25|UDP: [172.16.75.75]:1025|172.16.75.75|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.3.6.1.4.1.45.1.6.5.3.12.1.1.1.9 = INTEGER:
1|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.1.9 = INTEGER:
9|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.1.9 = Hex-STRING: 64 31 50 5F 0A 00  END
VARIABLEBINDINGS

2011-02-07|17:40:03|UDP: [172.16.75.75]:1025|172.16.75.75|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.3.6.1.4.1.45.1.6.5.3.12.1.1.1.9 = INTEGER:
1|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.1.9 = INTEGER:
9|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.1.9 = Hex-STRING: 64 31 50 5F 0D 00  END
VARIABLEBINDINGS

2011-02-07|17:40:55|UDP: [172.16.75.75]:1025|172.16.75.75|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.3.6.1.4.1.45.1.6.5.3.12.1.1.1.9 = INTEGER:
1|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.1.9 = INTEGER:
9|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.1.9 = Hex-STRING: 64 31 50 5F 0C 00  END
VARIABLEBINDINGS

2011-02-07|17:42:29|UDP: [172.16.75.75]:1025|172.16.75.75|BEGIN TYPE 6 END
TYPE BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.3.6.1.4.1.45.1.6.5.3.12.1.1.1.9 = INTEGER:
1|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.1.9 = INTEGER:
9|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.1.9 = STRING: "d1P_
5" END VARIABLEBINDINGS


Let me know if you would like any additional info.
(0001867)
obilodeau (reporter)
2011-02-15 14:00

 Reminder sent to: fgaudreault, user201

Whenever you have a minute can you guys try to reproduce the issue. Thanks.
(0001911)
user201
2011-03-09 18:15

 Can't reproduce this issue...

switch 470-24T
No SNMP issue with firmware : 3.7.2.12 ( running in our lab )
No SNMP Issue with firmware: 3.7.1.08 ( running @ customer site )

Found in release note: 3.7.5.X : Q02082410: The status of the stack ports are now correctly displayed when interrogating the MIB for the stack (Q02082410)

Suspecting an issue with this specific version of firmware ( 3.7.3 and 3.7.4 )- Suggestion: Don't use 3.7.3 or 3.7.4, try to upgrade your 470 to 3.7.5 or downgrade it to 3.7.2

ref: http://support.avaya.com/css/P8/documents/100115005 [^]

M-A
(0001964)
obilodeau (reporter)
2011-03-18 15:27

 Ok, I was able to reproduce the issue on our 470:

Mar 18 15:08:42 pfsetvlan(24) INFO: ignoring unknown trap: 2011-03-18|19:08:39|UDP: [10.0.0.51]:1024|10.0.0.51|BEGIN 
TYPE 6 END TYPE BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS .1.3.6.1.4.1.45.1.6.5.3.12.1.1.1.16 
= INTEGER: 1|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.1.16 = INTEGER: 16|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.1.16 = 
STRING: "d1P_ww" END VARIABLEBINDINGS (main::parseTrap)


Unfortunately, it seems to be the case for our Cisco 2950 as well..

Mar 18 15:25:33 pfsetvlan(23) INFO: ignoring unknown trap: 2011-03-18|19:25:30|UDP: [10.0.0.15]:53586|0.0.0.0|BEGIN 
TYPE 0 END TYPE BEGIN SUBTYPE 0 END SUBTYPE BEGIN VARIABLEBINDINGS .1.3.6.1.2.1.1.3.0 = Timeticks: (1035585663) 
119 days, 20:37:36.63|.1.3.6.1.6.3.1.1.4.1.0 = OID: .1.3.6.1.4.1.9.9.315.0.0.1|.1.3.6.1.2.1.2.2.1.1.12 
= Wrong Type (should be INTEGER): Gauge32: 12|.1.3.6.1.2.1.2.2.1.2.12 = STRING: FastEthernet0/12|.1.3.6.1.4.1.9.9.315.1.2.1.1.10.12 
= STRING: "d1P_ww" END VARIABLEBINDINGS (main::parseTrap)
(0001968)
obilodeau (reporter)
2011-03-18 17:16

 Ok, it's going to be an intrusive fix.. if we don't want to rely on MIBs we will need to modify our trap parsers so that they can deal with the STRING or Hex-STRING forms. So, all switch modules will be affected by this change. For this reason we will not do it in a minor cycle but in a major cycle.

For those interested in implementing a fix themselves, here's the strategy that I tested today and that works fine:

- change your switch's parseTrap from Hex-STRING: ([0-9A-Z]{2} [0-9A-Z]{2} [0-9A-Z]{2} [0-9A-Z]{2} [0-9A-Z]{2} [0-9A-Z]{2}) to (?:Hex-STRING:\ ([0-9A-Z]{2}\ [0-9A-Z]{2}\ [0-9A-Z]{2}\ [0-9A-Z]{2}\ [0-9A-Z]{2}\ [0-9A-Z]{2})|STRING:\ "(.+)")

then handle both cases. for ex:
        if (defined($2)) {
            $trapHashRef->{'trapMac'} = lc($2);
            $trapHashRef->{'trapMac'} =~ s/ /:/g;
        } elsif (defined($3)) {
            $trapHashRef->{'trapMac'} = unpack("H*", $3);
            $trapHashRef->{'trapMac'} =~ s/([a-f0-9]{2})(?!$)/$1:/g; # builds groups of two separated 
by :
        } else {
            $trapHashRef->{'trapType'} = 'unknown';
        }
        $trapHashRef->{'trapVlan'} = $this->getVlan( $trapHashRef->{'trapIfIndex'} );


The real fix will be cleaner. Probably involving a utility method.
(0002086)
obilodeau (reporter)
2011-06-17 09:12

 More consequences of the to-string interpolation:

I tried the work around but I still encountered a couple of issues.

For example 5c:26:0a:38:78:47 produces this trap:

2011-05-19|19:36:21|UDP: [10.10.75.1]:1025|10.10.75.1|BEGIN TYPE 6 END TYPE
BEGIN SUBTYPE .5 END SUBTYPE BEGIN VARIABLEBINDINGS
.1.3.6.1.4.1.45.1.6.5.3.12.1.1.1.24 = INTEGER:
1|.1.3.6.1.4.1.45.1.6.5.3.12.1.2.1.24 = INTEGER:
24|.1.3.6.1.4.1.45.1.6.5.3.12.1.3.1.24 = STRING: "\\&
8xG" END VARIABLEBINDINGS

The fix you provided me translates the mac address into:
5c:5c:26:20:38:78:47. Two problems:

1) it is an invalid 14-char mac address because of the "\\" = 5c5c. No big
deal, I added a line to substitute all "\\" with "\" ... fixed that one

2) the ascii representation for new line (0a) is being interpreted as an
ascii space (20) in the provided fix, so it gives the wrong mac address:

5c:26:20:38:78:47 instead of
5c:26:0a:38:78:47

Not sure how to code this one to interpret the new line from the snmptrap -
any suggestions? 

I tried searching for /\n/ in the parseTrap subroutine $3 variable, but by
that time it is being depicted as a space in the variable.

Is this something that Net-SNMP should be trying to fix in their snmptrapd
process?

Hope you were able to follow all that.

Thanks.
(0002141)
obilodeau (reporter)
2011-08-18 15:19

 Multiline traps' newline characters are no longer replaced by a space. Turns out this was done by pfsetvlan.

With the backslash escaping trick, this allows me to properly parse this guy here: "\\&
8xG".

Attached a patch to the issue. Now I'm going to fix all the trap parsers..
(0002142)
obilodeau (reporter)
2011-08-19 15:23

 Fixed in current stable branch (2_2).

Another fix was added into the mix: hex 22 (ascii: ") was turned into \" since snmptrapd uses " as string delimiters. Utility function updated to handle that.

Affected hardware: 3Com, Aruba, Cisco, Dlink, Enterasys, HP, Nortel, SMC, Xirrus

I will provide a patch that will hopefully apply semi-cleanly on 1.9-2.2.
(0002277)
obilodeau (reporter)
2011-09-21 22:20

 fix released in 3.0

- Issue History
Date Modified Username Field Change
2010-10-22 10:21 rafamiga New Issue
2010-10-22 10:24 rafamiga Note Added: 0001730
2010-11-18 13:55 obilodeau Status new => assigned
2010-11-18 13:55 obilodeau Assigned To => obilodeau
2010-11-18 14:01 obilodeau Note Added: 0001764
2010-11-18 14:02 obilodeau Priority normal => high
2010-11-18 14:02 obilodeau Target Version => 1.10.0
2010-11-19 14:25 obilodeau Target Version 1.10.0 => 2.0.0
2010-11-19 17:09 obilodeau Note Added: 0001770
2010-11-22 05:06 rafamiga Note Added: 0001771
2010-11-22 05:09 rafamiga Note Added: 0001772
2010-11-22 09:31 obilodeau Note Added: 0001773
2010-11-22 09:39 rafamiga Note Added: 0001774
2010-11-22 09:40 obilodeau Note Added: 0001775
2011-01-18 09:47 obilodeau Target Version 2.0.0 => 2.0.1
2011-01-21 15:34 fgaudreault Note Added: 0001828
2011-01-21 15:34 fgaudreault Status assigned => resolved
2011-01-21 15:34 fgaudreault Resolution open => unable to reproduce
2011-02-02 16:53 obilodeau Note Added: 0001847
2011-02-15 13:58 obilodeau Note Added: 0001866
2011-02-15 13:58 obilodeau Status resolved => feedback
2011-02-15 13:58 obilodeau Resolution unable to reproduce => reopened
2011-02-15 14:00 obilodeau Note Added: 0001867
2011-02-16 09:25 obilodeau Target Version 2.0.1 => 2.0.2
2011-03-03 15:19 obilodeau Target Version 2.0.2 => +1
2011-03-09 18:15 user201 Note Added: 0001911
2011-03-18 15:27 obilodeau Note Added: 0001964
2011-03-18 15:27 obilodeau Status feedback => assigned
2011-03-18 15:27 obilodeau Status assigned => confirmed
2011-03-18 17:16 obilodeau Note Added: 0001968
2011-06-17 09:12 obilodeau Note Added: 0002086
2011-08-18 14:03 obilodeau Status confirmed => assigned
2011-08-18 15:19 obilodeau Note Added: 0002141
2011-08-18 15:19 obilodeau File Added: multiline-trap-fix-on-2.2.patch
2011-08-19 15:23 obilodeau mtn revision => 69347a6378a28890628a182b3348b1e1524aacf8
2011-08-19 15:23 obilodeau Note Added: 0002142
2011-08-19 15:23 obilodeau Status assigned => resolved
2011-08-19 15:23 obilodeau Fixed in Version => +1
2011-08-19 15:23 obilodeau Resolution reopened => fixed
2011-08-19 15:33 obilodeau File Deleted: multiline-trap-fix-on-2.2.patch
2011-08-19 15:33 obilodeau File Added: snmptrapd-stringified-mac-parsing-fix.patch
2011-09-21 22:20 obilodeau Fixed in Version +1 => 3.0.0
2011-09-21 22:20 obilodeau Note Added: 0002277
2011-09-21 22:21 obilodeau Status resolved => closed
2011-10-24 20:24 obilodeau Target Version +1 => 3.0.0
2012-08-07 09:44 obilodeau Relationship added related to 0001495

Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker