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 >> >> >> > ---------------------------------------------------------------------------- > -- >> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! >> Finally, a world-class log management solution at an even better > price-free! >> Download using promo code Free_Logger_4_Dev2Dev. Offer expires >> February 28th, so secure your free ArcSight Logger TODAY! >> http://p.sf.net/sfu/arcsight-sfd2d >> _______________________________________________ >> Packetfence-users mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/packetfence-users > > > > > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > > > > _______________________________________________ > Packetfence-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/packetfence-users -- 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) ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Packetfence-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/packetfence-users
