Anonymous | Login | 2024-09-01 03:25 EDT | ![]() |
Main | My View | View Issues | Change Log | Roadmap |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | |||||||
ID | Project | Category | View Status | Date Submitted | Last Update | |||
0001098 | PacketFence | core | public | 2010-10-22 10:21 | 2011-10-24 20:24 | |||
Reporter | rafamiga | |||||||
Assigned To | obilodeau | |||||||
Priority | high | Severity | minor | Reproducibility | always | |||
Status | closed | Resolution | fixed | |||||
Platform | OS | OS Version | ||||||
Product Version | ||||||||
Target Version | 3.0.0 | Fixed in Version | 3.0.0 | |||||
Summary | 0001098: hard-coded snmptrapd invocation fails on "printable" MAC addresses | |||||||
Description | When 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. | |||||||
Tags | No tags attached. | |||||||
fixed in git revision | ||||||||
fixed in mtn revision | 69347a6378a28890628a182b3348b1e1524aacf8 | |||||||
Attached Files | ![]() | |||||||
![]() |
||||||
|
![]() |
|
(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 |
![]() |
|||
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 |