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. -----Original Message----- From: Olivier Bilodeau [mailto:[email protected]] Sent: March-18-11 6:26 PM To: [email protected] Subject: Re: [Packetfence-users] invalid traps for adapters of oui=64:31:50 Hi Kevin, I was able to successfully reproduce this issue today. The fix won't be an easy one as it involves rewriting all our trap parsers' regular expressions to be able to handle both Hex-String and String formats so it won't be in 2.1.1 but more likely in 2.2.0. I added a work-around in the ticket if you would want to code around the issue yourself. http://www.packetfence.org/bugs/bug_view_advanced_page.php?bug_id=1098#c1968 Thanks for your report! On 15/02/11 2:04 PM, Olivier Bilodeau wrote: > Hi Kevin, > > Based on your feedback, we will reproduce the issue in our lab. I > re-opened issue #1098 to track this. I suggest that you subscribe to the > bug if you want to follow its status. > http://www.packetfence.org/bugs/view.php?id=1098 > > I'm afraid that the only viable solution I can see is to install > Nortel's MIB in your environment which should give a clue to the > snmptrapd daemon what the underlying format of the trap should be. > However we have not tested this. > > Thanks for the info. > > On 08/02/11 10:15 AM, Kevin Manuel wrote: >> 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|%#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 >> >> >>>> - 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. >> >> Kevin >> >> >> -----Original Message----- >> From: Francois Gaudreault [mailto:[email protected]] >> Sent: January-31-11 10:44 AM >> To: [email protected] >> Cc: Kevin Manuel >> Subject: Re: [Packetfence-users] invalid traps for adapters of oui=64:31:50 >> >> Hi Kevin, >> >> This is not the first time we are facing this problem, but we never been >> able to reproduce it in our lab. >> >> Can you send us the following info: >> - What is the model of the device that send this kind of traps? >> - What is its firmware version? >> - Are you running PF on CentOS? >> - Can you send us your generated snmptrapd.conf? >> - Can you do a tcpdump using tshark and send us the .pcap file of this trap. >> >> Thanks! >> >> On 11-01-31 9:37 AM, Kevin Manuel wrote: >>> Hi, >>> >>> There are a couple of machines on our network that are not able to >> authorize >>> because our switches are sending invalid security traps when they connect >> to >>> the otherwise working port. The trap should include a Hex-STRING with the >>> adapter mac address, but instead includes a String containing unknown >> info. >>> The adapters causing the issue all have the same OUI - 64:31:50. >>> >>> 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 >>> >>> >>> Any suggestions would be greatly appreciated. >>> >>> Kevin >>> -- 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) ---------------------------------------------------------------------------- -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Packetfence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Packetfence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
