From jbers at bbn.com Sun Mar 18 12:25:42 2007 From: jbers at bbn.com (Josh Bers) Date: Sun Mar 18 16:28:06 2007 Subject: [snmp] next release Message-ID: <001601c7697a$15aa2ff0$010010ac@JBERS2> when is the next release of the stack scheduled? 5.2? Josh From birgit at westhawk.co.uk Tue Mar 20 11:18:14 2007 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Tue Mar 20 11:45:22 2007 Subject: [snmp] next release In-Reply-To: <001601c7697a$15aa2ff0$010010ac@JBERS2> References: <001601c7697a$15aa2ff0$010010ac@JBERS2> Message-ID: <20070320111814.GH28615@westhawk.co.uk> Hi Josh, All our available code is on SourceForge, see http://sourceforge.net/projects/westhawksnmp/ We are in the process of moving over documentation as well, but as always paid work gets in the way. :-) Tim hasn't had time (yet) to fix the deadlock problem you reported a while ago: Date: Tue, 23 Jan 2007 13:48:25 -0500 Subject: [snmp] deadlock when destroying a context We haven't scheduled a release yet. As I said, all our code is now available as soon as we change it (and do a cvs commit), but testing the full features of the stack always takes close to a week. Unfortunately we don't have that time available the next few months, sorry. Cheers, Birgit On Sun, Mar 18, 2007 at 12:25:42PM -0400, Josh Bers wrote: > when is the next release of the stack scheduled? > > 5.2? > > Josh > _______________________________________________ > snmp mailing list > snmp@snmp.westhawk.co.uk > http://snmp.westhawk.co.uk/mailman/listinfo/snmp -- -- Birgit Arkesteijn, birgit@westhawk.co.uk, -- Westhawk Ltd, Albion Wharf, 19 Albion Street, Manchester M1 5LN, UK -- Company no: 1769350 -- Registered Office: -- 15 London Road, Stockton Heath, Warrington WA4 6SJ. UK. -- tel.: +44 (0)161 237 0660 -- From jbers at bbn.com Fri Mar 23 17:16:35 2007 From: jbers at bbn.com (Josh Bers) Date: Fri Mar 23 21:18:49 2007 Subject: [snmp] Problem with the snmpv3 context Message-ID: <005d01c76d90$896c1ab0$010010ac@JBERS2> I am seeing a problem while using version 5.1 of the stack (running on linux, java 1.4.2_12) talking to an SNMP agent with version 3 with privacy and authentication turned on. The scenario is the following: The program repeatedly attempts to contact an agent that is unreachable (network cable unplugged). After a long period of time (>3 minutes) the network cable is plugged back in. The stack behavior is: While disconnected, we see messages about USMDiscovery Bean timing out trying to connect to the agent. The stack dump show 2 receivers associated with the disconnected target IP address (?) These timeouts are repeated for each attempt (timeouts take ~20 seconds). When the cable is reconnected, the 2 receiver threads suddenly die. No more USMDiscoveryBean timeouts are seen, however, no every PDU that is sent times out waiting for a response (makes sense given that the receiver has died). Anyone else seen this? Know why? Any workaround? Swapping to Version 1 context solves the problem (but this is not desireable). Theory: USMDiscovery Creates its own v3 context (not sure why it can't reuse the one created for the original PDU??) Somehow when it kills this context it kills the context (or at least the receiver thread) of the PDU's context... (notify issue?)... Josh From thp at westhawk.co.uk Mon Mar 26 10:36:47 2007 From: thp at westhawk.co.uk (Tim Panton) Date: Mon Mar 26 09:43:59 2007 Subject: [snmp] Problem with the snmpv3 context In-Reply-To: <005d01c76d90$896c1ab0$010010ac@JBERS2> References: <005d01c76d90$896c1ab0$010010ac@JBERS2> Message-ID: <8412F231-22D4-4D3F-882F-F944D42264E7@westhawk.co.uk> On 23 Mar 2007, at 21:16, Josh Bers wrote: > I am seeing a problem while using version 5.1 of the stack (running on > linux, java 1.4.2_12) talking to an SNMP agent with version 3 with > privacy > and authentication turned on. > > The scenario is the following: > > The program repeatedly attempts to contact an agent that is > unreachable > (network cable unplugged). After a long period of time (>3 minutes) > the > network cable is plugged back in. > > The stack behavior is: > > While disconnected, we see messages about USMDiscovery Bean timing out > trying to connect to the agent. The stack dump show 2 receivers > associated > with the disconnected target IP address (?) These timeouts are > repeated for > each attempt (timeouts take ~20 seconds). When the cable is > reconnected, the > 2 receiver threads suddenly die. No more USMDiscoveryBean timeouts > are seen, > however, no every PDU that is sent times out waiting for a response > (makes > sense given that the receiver has died). > > Anyone else seen this? Know why? Any workaround? Swapping to Version 1 > context solves the problem (but this is not desireable). > > Theory: > USMDiscovery Creates its own v3 context (not sure why it can't > reuse the one > created for the original PDU??) Somehow when it kills this context > it kills > the context (or at least the receiver thread) of the PDU's context... > (notify issue?)... Ah, Interesting. Do you have an ethereal trace of the packets - including ICMP ? Combined with a debug log we should be able to find the problem pretty fast. (other pressures permitting :-) ) I dimly remember hearing that different UDP implementations throw different exceptions when an intermediate router sends an 'unreachable' or the local system reports 'no-route-to-host'. I'll ask the folks who reported the problem what they did. Tim. From birgit at westhawk.co.uk Mon Mar 26 11:33:46 2007 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Mon Mar 26 10:55:13 2007 Subject: [snmp] Problem with the snmpv3 context In-Reply-To: <8412F231-22D4-4D3F-882F-F944D42264E7@westhawk.co.uk> References: <005d01c76d90$896c1ab0$010010ac@JBERS2> <8412F231-22D4-4D3F-882F-F944D42264E7@westhawk.co.uk> Message-ID: <20070326093346.GA19005@westhawk.co.uk> On Mon, Mar 26, 2007 at 09:36:47AM +0100, Tim Panton wrote: > > On 23 Mar 2007, at 21:16, Josh Bers wrote: > > >I am seeing a problem while using version 5.1 of the stack (running > >on > >linux, java 1.4.2_12) talking to an SNMP agent with version 3 with > >privacy > >and authentication turned on. > > > >The scenario is the following: > > > >The program repeatedly attempts to contact an agent that is > >unreachable > >(network cable unplugged). After a long period of time (>3 minutes) > >the > >network cable is plugged back in. > > > >The stack behavior is: > > > >While disconnected, we see messages about USMDiscovery Bean timing > >out > >trying to connect to the agent. The stack dump show 2 receivers > >associated > >with the disconnected target IP address (?) These timeouts are > >repeated for > >each attempt (timeouts take ~20 seconds). When the cable is > >reconnected, the > >2 receiver threads suddenly die. No more USMDiscoveryBean timeouts > >are seen, > >however, no every PDU that is sent times out waiting for a response > >(makes > >sense given that the receiver has died). > > > >Anyone else seen this? Know why? Any workaround? Swapping to Version > >1 > >context solves the problem (but this is not desirable). > > > >Theory: > >USMDiscovery Creates its own v3 context (not sure why it can't > >reuse the one > >created for the original PDU??) Somehow when it kills this context > >it kills > >the context (or at least the receiver thread) of the PDU's context... > >(notify issue?)... > > Ah, Interesting. > > Do you have an ethereal trace of the packets - including ICMP ? > Combined with a debug log we should be able to find the problem > pretty fast. > (other pressures permitting :-) ) > > I dimly remember hearing that different UDP implementations throw > different > exceptions when an intermediate router sends an 'unreachable' or the > local > system reports 'no-route-to-host'. I'll ask the folks who reported > the problem what > they did. > > Tim. Hi Josh, To add to Tim's reply .. See if you get anything useful when setting the debug level quite high ( AsnObject.setDebug(13); ) As to why the v3 context cannot use the original PDU: EngineId (and then Timeline) discovery requires different context parameters. Cheers, Birgit -- -- Birgit Arkesteijn, birgit@westhawk.co.uk, -- Westhawk Ltd, Albion Wharf, 19 Albion Street, Manchester M1 5LN, UK -- Company no: 1769350 -- Registered Office: -- 15 London Road, Stockton Heath, Warrington WA4 6SJ. UK. -- tel.: +44 (0)161 237 0660 -- From tausifk at hotmail.com Mon Mar 26 17:04:56 2007 From: tausifk at hotmail.com (tausifk) Date: Mon Mar 26 11:47:51 2007 Subject: [snmp] Recieved Engine ID is not correct Message-ID: All, I am getting an exception - "Received engine Id ('80001F88800C330000999E0746') is not correct" The scenario is, I run my snmp manager (Westhawk API) and fetched the snmpv3 information from an Net-SNMP agent running on a perticular device. Now my manager is still up and running and I re-install the Net-SNMP agent and configure the same user with same credentials as before. Now I again try to do snmpv3 ping and get this exception: ================================================================================= snmpgetV3.start() PduException: Received engine Id ('80001F88800C330000999E0746') is not correct. amIAuthoritative == false snmpgetV3.start() PduException: uk.co.westhawk.snmp.stack.DecodingException: Received engine Id ('80001F88800C330000999E0746') is not correct. amIAuthoritative == false at uk.co.westhawk.snmp.stack.AsnDecoderv3.processSNMPv3(AsnDecoderv3.java:176) at uk.co.westhawk.snmp.stack.SnmpContextv3Basis.processIncomingResponse(SnmpContextv3Basis.java:812) at uk.co.westhawk.snmp.stack.AbstractSnmpContext.run(AbstractSnmpContext.java:545) at java.lang.Thread.run(Thread.java:534) ================================================================================= I understand that the re-installation of Net-SNMP agent re-generate the engine-id and my snmp manager chached the engine-ID before when I did snmpv3 ping and there is a mis-match. Please do let me know is there any bug with SNMP-Westhawk API or it is a wrong behaviour of Net-SNMP agent which is re-generating the different enging-id? I am using Westhawk SNMP 5.1 version for my snmp Manager. Thanks in advance Tausif From birgit at westhawk.co.uk Mon Mar 26 14:01:13 2007 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Mon Mar 26 13:07:05 2007 Subject: [snmp] Recieved Engine ID is not correct In-Reply-To: References: Message-ID: <20070326120113.GD19005@westhawk.co.uk> Hi Tausif, When using SNMPv3, the stack discovers the engineId by asking the authoritative engine for it. If authentication or privacy is used, it will then ask for the timeline details as well. It does this once at the beginning. (It will repeat it only when unsuccessful.) The details are stored for the remaining of the stack lifetime. In your case, the stack complains that the discovered engineId and the one sent (by the authoritative engine) as part of a subsequent request are not the same. However, you said so yourself: there is a mis-match. The engineId is supposed to uniquely identify an authoritative engine, i.e. it's not supposed to change. The only option I see is to stop/start the stack. If that doesn't work: Call AsnObject.setDebug(5), the stack will then print the engineId (and timeline details if using authentication or privacy) it stores. See what you get when doing discovery. Cheers, Birgit On Mon, Mar 26, 2007 at 04:04:56PM +0530, tausifk wrote: > All, > > I am getting an exception - "Received engine Id ('80001F88800C330000999E0746') is not correct" > > The scenario is, I run my snmp manager (Westhawk API) and fetched the snmpv3 information from an Net-SNMP agent running on a particular device. Now my manager is still up and running and I re-install the Net-SNMP agent and configure the same user with same credentials as before. Now I again try to do snmpv3 ping and get this exception: > > ================================================================================= > snmpgetV3.start() PduException: Received engine Id ('80001F88800C330000999E0746') is not correct. amIAuthoritative == false > snmpgetV3.start() PduException: > uk.co.westhawk.snmp.stack.DecodingException: Received engine Id ('80001F88800C330000999E0746') is not correct. amIAuthoritative == false > at uk.co.westhawk.snmp.stack.AsnDecoderv3.processSNMPv3(AsnDecoderv3.java:176) > at uk.co.westhawk.snmp.stack.SnmpContextv3Basis.processIncomingResponse(SnmpContextv3Basis.java:812) > at uk.co.westhawk.snmp.stack.AbstractSnmpContext.run(AbstractSnmpContext.java:545) > at java.lang.Thread.run(Thread.java:534) > > ================================================================================= > > > I understand that the re-installation of Net-SNMP agent re-generate the engine-id and my snmp manager cached the engine-ID before when I did snmpv3 ping and there is a mis-match. > > Please do let me know is there any bug with SNMP-Westhawk API or it is a wrong behaviour of Net-SNMP agent which is re-generating the different engine-id? > > I am using Westhawk SNMP 5.1 version for my snmp Manager. > > Thanks in advance > Tausif > > _______________________________________________ > snmp mailing list > snmp@snmp.westhawk.co.uk > http://snmp.westhawk.co.uk/mailman/listinfo/snmp -- -- Birgit Arkesteijn, birgit@westhawk.co.uk, -- Westhawk Ltd, Albion Wharf, 19 Albion Street, Manchester M1 5LN, UK -- Company no: 1769350 -- Registered Office: -- 15 London Road, Stockton Heath, Warrington WA4 6SJ. UK. -- tel.: +44 (0)161 237 0660 -- From jbers at bbn.com Mon Mar 26 13:51:23 2007 From: jbers at bbn.com (Josh Bers) Date: Mon Mar 26 17:55:05 2007 Subject: [snmp] Problem with the snmpv3 context In-Reply-To: <8412F231-22D4-4D3F-882F-F944D42264E7@westhawk.co.uk> Message-ID: <003101c76fc6$ff5ab190$010010ac@JBERS2> Tim and Birgit, I hope to get some debug output to send you soon on this issue. Tim, I'm not sure how it could be a UDP issue since the behavior changes for SNMPv1 (it works fine). Josh > I dimly remember hearing that different UDP implementations throw > different > exceptions when an intermediate router sends an 'unreachable' or the > local > system reports 'no-route-to-host'. I'll ask the folks who reported > the problem what > they did. > > -----Original Message----- > From: snmp-bounces@snmp.westhawk.co.uk > [mailto:snmp-bounces@snmp.westhawk.co.uk] On Behalf Of Tim Panton > Sent: Monday, March 26, 2007 4:37 AM > To: List for discussion of the Westhawk SNMP stack > Subject: Re: [snmp] Problem with the snmpv3 context > > > > On 23 Mar 2007, at 21:16, Josh Bers wrote: > > > I am seeing a problem while using version 5.1 of the stack > (running on > > linux, java 1.4.2_12) talking to an SNMP agent with version 3 with > > privacy > > and authentication turned on. > > > > The scenario is the following: > > > > The program repeatedly attempts to contact an agent that is > > unreachable > > (network cable unplugged). After a long period of time (>3 > minutes) > > the > > network cable is plugged back in. > > > > The stack behavior is: > > > > While disconnected, we see messages about USMDiscovery Bean > timing out > > trying to connect to the agent. The stack dump show 2 receivers > > associated > > with the disconnected target IP address (?) These timeouts are > > repeated for > > each attempt (timeouts take ~20 seconds). When the cable is > > reconnected, the > > 2 receiver threads suddenly die. No more USMDiscoveryBean timeouts > > are seen, > > however, no every PDU that is sent times out waiting for a > response > > (makes > > sense given that the receiver has died). > > > > Anyone else seen this? Know why? Any workaround? Swapping > to Version 1 > > context solves the problem (but this is not desireable). > > > > Theory: > > USMDiscovery Creates its own v3 context (not sure why it can't > > reuse the one > > created for the original PDU??) Somehow when it kills this context > > it kills > > the context (or at least the receiver thread) of the PDU's > context... > > (notify issue?)... > > Ah, Interesting. > > Do you have an ethereal trace of the packets - including ICMP > ? Combined with a debug log we should be able to find the problem > pretty fast. > (other pressures permitting :-) ) > > I dimly remember hearing that different UDP implementations throw > different > exceptions when an intermediate router sends an 'unreachable' or the > local > system reports 'no-route-to-host'. I'll ask the folks who reported > the problem what > they did. > > Tim. > > > > _______________________________________________ > snmp mailing list > snmp@snmp.westhawk.co.uk > http://snmp.westhawk.co.uk/mailman/listinfo/snmp > From thp at westhawk.co.uk Mon Mar 26 19:04:54 2007 From: thp at westhawk.co.uk (Tim Panton) Date: Mon Mar 26 18:11:39 2007 Subject: [snmp] Problem with the snmpv3 context In-Reply-To: <003101c76fc6$ff5ab190$010010ac@JBERS2> References: <003101c76fc6$ff5ab190$010010ac@JBERS2> Message-ID: <233C9F03-5221-435F-B201-54F23F44714D@westhawk.co.uk> I'm not sure either, it's just that the 'no route to host' issue rang an alarm bell, so I wanted to be sure that any packet trace contained the ICMPs too. Tim. On 26 Mar 2007, at 17:51, Josh Bers wrote: > Tim and Birgit, > > I hope to get some debug output to send you soon on this issue. > > Tim, I'm not sure how it could be a UDP issue since the behavior > changes for > SNMPv1 (it works fine). > > Josh > >> I dimly remember hearing that different UDP implementations throw >> different >> exceptions when an intermediate router sends an 'unreachable' or the >> local >> system reports 'no-route-to-host'. I'll ask the folks who reported >> the problem what >> they did. >> > >> -----Original Message----- >> From: snmp-bounces@snmp.westhawk.co.uk >> [mailto:snmp-bounces@snmp.westhawk.co.uk] On Behalf Of Tim Panton >> Sent: Monday, March 26, 2007 4:37 AM >> To: List for discussion of the Westhawk SNMP stack >> Subject: Re: [snmp] Problem with the snmpv3 context >> >> >> >> On 23 Mar 2007, at 21:16, Josh Bers wrote: >> >>> I am seeing a problem while using version 5.1 of the stack >> (running on >>> linux, java 1.4.2_12) talking to an SNMP agent with version 3 with >>> privacy >>> and authentication turned on. >>> >>> The scenario is the following: >>> >>> The program repeatedly attempts to contact an agent that is >>> unreachable >>> (network cable unplugged). After a long period of time (>3 >> minutes) >>> the >>> network cable is plugged back in. >>> >>> The stack behavior is: >>> >>> While disconnected, we see messages about USMDiscovery Bean >> timing out >>> trying to connect to the agent. The stack dump show 2 receivers >>> associated >>> with the disconnected target IP address (?) These timeouts are >>> repeated for >>> each attempt (timeouts take ~20 seconds). When the cable is >>> reconnected, the >>> 2 receiver threads suddenly die. No more USMDiscoveryBean timeouts >>> are seen, >>> however, no every PDU that is sent times out waiting for a >> response >>> (makes >>> sense given that the receiver has died). >>> >>> Anyone else seen this? Know why? Any workaround? Swapping >> to Version 1 >>> context solves the problem (but this is not desireable). >>> >>> Theory: >>> USMDiscovery Creates its own v3 context (not sure why it can't >>> reuse the one >>> created for the original PDU??) Somehow when it kills this context >>> it kills >>> the context (or at least the receiver thread) of the PDU's >> context... >>> (notify issue?)... >> >> Ah, Interesting. >> >> Do you have an ethereal trace of the packets - including ICMP >> ? Combined with a debug log we should be able to find the problem >> pretty fast. >> (other pressures permitting :-) ) >> >> I dimly remember hearing that different UDP implementations throw >> different >> exceptions when an intermediate router sends an 'unreachable' or the >> local >> system reports 'no-route-to-host'. I'll ask the folks who reported >> the problem what >> they did. >> >> Tim. >> >> >> >> _______________________________________________ >> snmp mailing list >> snmp@snmp.westhawk.co.uk >> http://snmp.westhawk.co.uk/mailman/listinfo/snmp >> > > > > _______________________________________________ > snmp mailing list > snmp@snmp.westhawk.co.uk > http://snmp.westhawk.co.uk/mailman/listinfo/snmp From jbers at bbn.com Thu Mar 29 17:27:32 2007 From: jbers at bbn.com (Josh Bers) Date: Thu Mar 29 21:29:37 2007 Subject: [snmp] Problem with the snmpv3 context In-Reply-To: <20070326093346.GA19005@westhawk.co.uk> Message-ID: <009501c77240$b0c6f210$010010ac@JBERS2> Birgit and Tim, Here is the output from the stack when debug set at level 15. The scenario here is slightly different than I described before: Here we do the test on the loopback interface (since it's easier to test than with two machines and produces the same results) Look for "Bringing down the loopback interface" Then it starts to query for sysName among other OID's about 2 minutes later it Brings the loopback interface up Then the stack stops receiving data. Josh > -----Original Message----- > From: snmp-bounces@snmp.westhawk.co.uk > [mailto:snmp-bounces@snmp.westhawk.co.uk] On Behalf Of Birgit > Arkesteijn > Sent: Monday, March 26, 2007 5:34 AM > To: List for discussion of the Westhawk SNMP stack > Subject: Re: [snmp] Problem with the snmpv3 context > > > On Mon, Mar 26, 2007 at 09:36:47AM +0100, Tim Panton wrote: > > > > On 23 Mar 2007, at 21:16, Josh Bers wrote: > > > > >I am seeing a problem while using version 5.1 of the stack (running > > >on > > >linux, java 1.4.2_12) talking to an SNMP agent with > version 3 with > > >privacy > > >and authentication turned on. > > > > > >The scenario is the following: > > > > > >The program repeatedly attempts to contact an agent that is > > >unreachable > > >(network cable unplugged). After a long period of time (>3 > minutes) > > >the > > >network cable is plugged back in. > > > > > >The stack behavior is: > > > > > >While disconnected, we see messages about USMDiscovery Bean timing > > >out > > >trying to connect to the agent. The stack dump show 2 receivers > > >associated > > >with the disconnected target IP address (?) These timeouts are > > >repeated for > > >each attempt (timeouts take ~20 seconds). When the cable is > > >reconnected, the > > >2 receiver threads suddenly die. No more USMDiscoveryBean > timeouts > > >are seen, > > >however, no every PDU that is sent times out waiting for a > response > > >(makes > > >sense given that the receiver has died). > > > > > >Anyone else seen this? Know why? Any workaround? Swapping > to Version > > >1 > > >context solves the problem (but this is not desirable). > > > > > >Theory: > > >USMDiscovery Creates its own v3 context (not sure why it can't > > >reuse the one > > >created for the original PDU??) Somehow when it kills this > context > > >it kills > > >the context (or at least the receiver thread) of the PDU's > context... > > >(notify issue?)... > > > > Ah, Interesting. > > > > Do you have an ethereal trace of the packets - including ICMP ? > > Combined with a debug log we should be able to find the problem > > pretty fast. > > (other pressures permitting :-) ) > > > > I dimly remember hearing that different UDP implementations throw > > different > > exceptions when an intermediate router sends an > 'unreachable' or the > > local > > system reports 'no-route-to-host'. I'll ask the folks who reported > > the problem what > > they did. > > > > Tim. > > > Hi Josh, > > To add to Tim's reply .. > > See if you get anything useful when setting the debug level > quite high > ( AsnObject.setDebug(13); ) > > As to why the v3 context cannot use the original PDU: > EngineId (and then Timeline) discovery requires different > context parameters. > > Cheers, Birgit > > -- > -- Birgit Arkesteijn, birgit@westhawk.co.uk, > -- Westhawk Ltd, Albion Wharf, 19 Albion Street, Manchester M1 5LN, UK > -- Company no: 1769350 > -- Registered Office: > -- 15 London Road, Stockton Heath, Warrington WA4 6SJ. UK. > -- tel.: +44 (0)161 237 0660 > -- > _______________________________________________ > snmp mailing list > snmp@snmp.westhawk.co.uk > http://snmp.westhawk.co.uk/mailman/listinfo/snmp > From jbers at bbn.com Thu Mar 29 17:38:51 2007 From: jbers at bbn.com (Josh Bers) Date: Thu Mar 29 21:40:47 2007 Subject: [snmp] Problem with the snmpv3 context In-Reply-To: <20070326093346.GA19005@westhawk.co.uk> Message-ID: <009f01c77242$45ed0e00$010010ac@JBERS2> Retrying the attachment: please rename extension to .zip From tausifk at rediffmail.com Fri Mar 30 06:43:57 2007 From: tausifk at rediffmail.com (tausif tausif) Date: Fri Mar 30 09:21:07 2007 Subject: [snmp] Recieved Engine ID is not correct Message-ID: <20070330053824.29604.qmail@webmail26.rediffmail.com> ? Hi Birgit, Thanks for the reply. I have few more doubts regarding the same. I think after re-installation of snmp engine it is possble of getting set the different engineid. and in this case the engine boots value will get assign to 1 and time must be zero? (please correct me if i m wrong) i have not seen the time-stamp value in NET-SNMP's conf files though. in this case my snmp-manager should not treat it as unauthorized packet/call and should process my request. I checked the TimeWindow.isEngineIdOK() code which just match the engineid and does not bother about the engineBoots and timeStamp. Should't it check thess variablesz as well? I think if we check these variables as well, our code should work fine? Waiting for your response Thanks & regards Tausif On Mon, 26 Mar 2007 Birgit Arkesteijn wrote : >Hi Tausif, > >When using SNMPv3, the stack discovers the engineId by asking the >authoritative engine for it. If authentication or privacy is used, it >will then ask for the timeline details as well. > >It does this once at the beginning. (It will repeat it only when >unsuccessful.) The details are stored for the remaining of the stack >lifetime. > >In your case, the stack complains that the discovered engineId and the >one sent (by the authoritative engine) as part of a subsequent request >are not the same. > >However, you said so yourself: there is a mis-match. > >The engineId is supposed to uniquely identify an authoritative engine, >i.e. it's not supposed to change. > >The only option I see is to stop/start the stack. > >If that doesn't work: >Call AsnObject.setDebug(5), the stack will then print the engineId (and >timeline details if using authentication or privacy) it stores. See >what you get when doing discovery. > >Cheers, Birgit > > >On Mon, Mar 26, 2007 at 04:04:56PM +0530, tausifk wrote: > > All, > > > > I am getting an exception - "Received engine Id ('80001F88800C330000999E0746') is not correct" > > > > The scenario is, I run my snmp manager (Westhawk API) and fetched the snmpv3 information from an Net-SNMP agent running on a particular device. Now my manager is still up and running and I re-install the Net-SNMP agent and configure the same user with same credentials as before. Now I again try to do snmpv3 ping and get this exception: > > > > ================================================================================= > > snmpgetV3.start() PduException: Received engine Id ('80001F88800C330000999E0746') is not correct. amIAuthoritative == false > > snmpgetV3.start() PduException: > > uk.co.westhawk.snmp.stack.DecodingException: Received engine Id ('80001F88800C330000999E0746') is not correct. amIAuthoritative == false > > at uk.co.westhawk.snmp.stack.AsnDecoderv3.processSNMPv3(AsnDecoderv3.java:176) > > at uk.co.westhawk.snmp.stack.SnmpContextv3Basis.processIncomingResponse(SnmpContextv3Basis.java:812) > > at uk.co.westhawk.snmp.stack.AbstractSnmpContext.run(AbstractSnmpContext.java:545) > > at java.lang.Thread.run(Thread.java:534) > > > > ================================================================================= > > > > > > I understand that the re-installation of Net-SNMP agent re-generate the engine-id and my snmp manager cached the engine-ID before when I did snmpv3 ping and there is a mis-match. > > > > Please do let me know is there any bug with SNMP-Westhawk API or it is a wrong behaviour of Net-SNMP agent which is re-generating the different engine-id? > > > > I am using Westhawk SNMP 5.1 version for my snmp Manager. > > > > Thanks in advance > > Tausif > > > > _______________________________________________ > > snmp mailing list > > snmp@snmp.westhawk.co.uk > > http://snmp.westhawk.co.uk/mailman/listinfo/snmp > >-- >-- Birgit Arkesteijn, birgit@westhawk.co.uk, >-- Westhawk Ltd, Albion Wharf, 19 Albion Street, Manchester M1 5LN, UK >-- Company no: 1769350 >-- Registered Office: >-- 15 London Road, Stockton Heath, Warrington WA4 6SJ. UK. >-- tel.: +44 (0)161 237 0660 >-- >_______________________________________________ >snmp mailing list >snmp@snmp.westhawk.co.uk >http://snmp.westhawk.co.uk/mailman/listinfo/snmp From thp at westhawk.co.uk Fri Mar 30 10:18:37 2007 From: thp at westhawk.co.uk (Tim Panton) Date: Fri Mar 30 09:23:44 2007 Subject: [snmp] Problem with the snmpv3 context In-Reply-To: <009501c77240$b0c6f210$010010ac@JBERS2> References: <009501c77240$b0c6f210$010010ac@JBERS2> Message-ID: <1CC0283A-2B4F-4266-A19A-5026AC335CBB@westhawk.co.uk> On 29 Mar 2007, at 21:27, Josh Bers wrote: > Birgit and Tim, > > Here is the output from the stack when debug set at level 15. > > The scenario here is slightly different than I described before: > Here we do the test on the loopback interface (since it's easier > to test > than with two machines and produces the same results) > > Look for > "Bringing down the loopback interface" > > Then it starts to query for sysName among other OID's about 2 > minutes later > it > Brings the loopback interface up > > Then the stack stops receiving data. > > Josh Sorry - our mail software is set to strip attachments (and drop large messages) Anyhow, I've saved the attachment at: http://snmp.westhawk.co.uk/logs/snmpv3killReceiverThread.txt I'll take a look later today. Tim. From jbers at bbn.com Fri Mar 30 17:38:15 2007 From: jbers at bbn.com (Josh Bers) Date: Fri Mar 30 21:40:35 2007 Subject: [snmp] snmpv3 context receiver thread destoyed Message-ID: <004d01c7730b$5aab78d0$010010ac@JBERS2> Birgit and Tim, I believe that the problem I am seeing is compounded by the long timeouts enforced by the UsmDiscoveryBean ~20 seconds.. say I am polling for data every 5 seconds, but the device is down so the discovery bean retries 4 times at 2 4 8 seconds that means that i'll have a backlog of USmDiscoveryBean requests outstanding when one finally, goes through..and then another.. How does the stack respond to multiple USM discovery requests comming back from the same snmp agent? Josh