From sharath at alcatel-lucent.com Thu Nov 1 18:16:20 2007 From: sharath at alcatel-lucent.com (K, Sharath (Sharath)) Date: Thu Nov 1 14:22:47 2007 Subject: [snmp] Need way to re-discover timeline info to recover fromusmStatsNotInTimeWindows In-Reply-To: <472894D9.20702@westhawk.co.uk> References: <472894D9.20702@westhawk.co.uk> Message-ID: Thanks Birgit, This is exactly what I was looking for. I will test with this new code, and see how it goes. Any idea when it will be available in a public release? Thanks, Sharath -----Original Message----- From: snmp-bounces@snmp.westhawk.co.uk [mailto:snmp-bounces@snmp.westhawk.co.uk] On Behalf Of Birgit Arkesteijn Sent: Wednesday, October 31, 2007 8:15 PM To: List for discussion of the Westhawk SNMP stack Cc: Nookala, Sridevi (Sridevi) Subject: Re: [snmp] Need way to re-discover timeline info to recover fromusmStatsNotInTimeWindows Hi Sharath, We added: public void TimeWindow.clearTimeWindow(java.lang.String snmpEngineId) but haven't (yet) turned that change into a public release. You can download the code, however, from SourceForge. http://sourceforge.net/projects/westhawksnmp/ I don't think keeping the SNMPv3 discovery details when a context is destroyed is wasteful. It saves (potential) two discovery PDUs when a new context is created and a new request PDU sent. We're not talking about bulk data either, so it won't take up that much space. Cheers, Birgit On 31/10/07 12:18, K, Sharath (Sharath) wrote: > Hello, > We are using the westhawk stack version 5.0 in one of our management > applications, which connect to SNMPv3 based network elements (NEs). > > We create the NE on the manager application and use the stack to > heartbeat (GET a couple of SNMP scalar attributes) the NE every 1 > minute. > Once the NE is created on the manager, a new SnmpContext is also created > and cached till the NE is deleted from the application. Upon deleting > the NE, the context is also destroyed. > We are facing a situation where-in the engineId, engineBoots and > engineTime are in synch between the manager and the NE (authoritative > engine), up until some commands are executed on the NE which update the > snmp configuration. When these commands are executed on the NE, the > engineTime is being reset to 0 on the NE, but the engineBoots remains > the same. > When the manager now sends out the next heartbeat SNMP GET request, we > get a usmStatsNotInTimeWindows error since the local engineTime is > greater than the NE's engineTime. > The only way to recover from this situation is to restart the manager > application (and hence the stack), which we cannot afford to do. I > initially thought that once the context corresponding to the NE was > destroyed and re-created, it would re-discover by sending engineBoots=0 > and engineTime=0, but the stack still retains the old values of > engineBoots and engineTime even if there is no corresponding context. > > I tried to do a forced discovery whenever usmStatsNotInTimeWindows > exception was detected, but this does not update the timeline info. > I see from TimeWindow.updateTimeWindow(), that timeline is updated only > if (bootsA > bootsL || > (bootsA == bootsL && timeA > latestL)) > > But in our case, bootsA == bootsL, but timeA < latestL. > > Is there a way to recover from this situation? > > Can you provide some public methods in TimeWindow.java to clear the > engineId and/or engineBoots and engineTime entries from the "hostLookup" > and "engineLookup" Hashtables? > This will enable us to re-initate a discovery and recover from this > situation. > > Or > > How about removing the corresponding entries in the hostLookup and > engineLookup Hashtables upon a context getting destroyed? > Because once the entries are stored for a given ip:port combination, > they remain for the lifetime of the stack, even if there is no context > associated with the given ip and port. Doesn't this seem wasteful? > > Any other suggestions to overcome this situation will be helpful. > > Thanks, > Sharath > > _______________________________________________ > 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 birgit at westhawk.co.uk Wed Nov 7 11:39:58 2007 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Wed Nov 7 11:41:30 2007 Subject: [snmp] Need way to re-discover timeline info to recover fromusmStatsNotInTimeWindows In-Reply-To: <47319F4E.5030101@westhawk.co.uk> Message-ID: <26245582.63011194435598567.JavaMail.root@zimbra> Hi Sharath, We haven't got a date yet for a public release, sorry. Cheers, Birgit K, Sharath (Sharath) wrote: > Thanks Birgit, > This is exactly what I was looking for. > I will test with this new code, and see how it goes. > > Any idea when it will be available in a public release? > > Thanks, > Sharath > > -----Original Message----- > From: snmp-bounces@snmp.westhawk.co.uk > [mailto:snmp-bounces@snmp.westhawk.co.uk] On Behalf Of Birgit Arkesteijn > Sent: Wednesday, October 31, 2007 8:15 PM > To: List for discussion of the Westhawk SNMP stack > Cc: Nookala, Sridevi (Sridevi) > Subject: Re: [snmp] Need way to re-discover timeline info to recover > fromusmStatsNotInTimeWindows > > Hi Sharath, > > We added: > public void TimeWindow.clearTimeWindow(java.lang.String snmpEngineId) > > but haven't (yet) turned that change into a public release. > > You can download the code, however, from SourceForge. > http://sourceforge.net/projects/westhawksnmp/ > > I don't think keeping the SNMPv3 discovery details when a context is > destroyed is wasteful. It saves (potential) two discovery PDUs when a > new context is created and a new request PDU sent. We're not talking > about bulk data either, so it won't take up that much space. > > Cheers, Birgit > > > On 31/10/07 12:18, K, Sharath (Sharath) wrote: >> Hello, >> We are using the westhawk stack version 5.0 in one of our management >> applications, which connect to SNMPv3 based network elements (NEs). >> >> We create the NE on the manager application and use the stack to >> heartbeat (GET a couple of SNMP scalar attributes) the NE every 1 >> minute. >> Once the NE is created on the manager, a new SnmpContext is also > created >> and cached till the NE is deleted from the application. Upon deleting >> the NE, the context is also destroyed. >> We are facing a situation where-in the engineId, engineBoots and >> engineTime are in synch between the manager and the NE (authoritative >> engine), up until some commands are executed on the NE which update > the >> snmp configuration. When these commands are executed on the NE, the >> engineTime is being reset to 0 on the NE, but the engineBoots remains >> the same. >> When the manager now sends out the next heartbeat SNMP GET request, we >> get a usmStatsNotInTimeWindows error since the local engineTime is >> greater than the NE's engineTime. >> The only way to recover from this situation is to restart the manager >> application (and hence the stack), which we cannot afford to do. I >> initially thought that once the context corresponding to the NE was >> destroyed and re-created, it would re-discover by sending > engineBoots=0 >> and engineTime=0, but the stack still retains the old values of >> engineBoots and engineTime even if there is no corresponding context. >> >> I tried to do a forced discovery whenever usmStatsNotInTimeWindows >> exception was detected, but this does not update the timeline info. >> I see from TimeWindow.updateTimeWindow(), that timeline is updated > only >> if (bootsA > bootsL || >> (bootsA == bootsL && timeA > latestL)) >> >> But in our case, bootsA == bootsL, but timeA < latestL. >> >> Is there a way to recover from this situation? >> >> Can you provide some public methods in TimeWindow.java to clear the >> engineId and/or engineBoots and engineTime entries from the > "hostLookup" >> and "engineLookup" Hashtables? >> This will enable us to re-initate a discovery and recover from this >> situation. >> >> Or >> >> How about removing the corresponding entries in the hostLookup and >> engineLookup Hashtables upon a context getting destroyed? >> Because once the entries are stored for a given ip:port combination, >> they remain for the lifetime of the stack, even if there is no context >> associated with the given ip and port. Doesn't this seem wasteful? >> >> Any other suggestions to overcome this situation will be helpful. >> >> Thanks, >> Sharath >> >> _______________________________________________ >> 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 snmp at linglink.com Mon Nov 26 12:05:59 2007 From: snmp at linglink.com (Maurice Ling) Date: Mon Nov 26 22:57:56 2007 Subject: [snmp] SNMP Inform response support in Westhawk SNMP stack 6.0 Message-ID: <58de34330711261205t524a0989nbd1a11f7c1e71954@mail.gmail.com> Hi Everyone, I would like to get clarification on the status of Inform support in Westhawk SNMP 6.0. According to the web site: http://snmp.westhawk.co.uk/, SNMP Inform receiving and sending is supported. In addition, other discussions on the mailing list indicate some support for Inform responses: http://snmp.westhawk.co.uk/pipermail/snmp/2006-November/000444.html However, when I run the examplev3 ReceiveTrap program and generate informs to it using net-snmp's sendinform program, the program times out, which indicates that there are no Inform responses being generated. My main question is does the Westhawk SNMP stack send responses to Informs, or is that is a capability that the user has to implement? It sounds like Gejo Thayil in the above referenced thread had come up with a solution. Is that source available to the general public? Thank you in advance for your responses! Regards, -Maurice From birgit at westhawk.co.uk Tue Nov 27 10:14:16 2007 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Tue Nov 27 10:15:35 2007 Subject: [snmp] SNMP Inform response support in Westhawk SNMP stack 6.0 In-Reply-To: <58de34330711261205t524a0989nbd1a11f7c1e71954@mail.gmail.com> References: <58de34330711261205t524a0989nbd1a11f7c1e71954@mail.gmail.com> Message-ID: <474BEDF8.3050100@westhawk.co.uk> Hi Maurice, The stack is capable of sending responses, but unfortunately it's all up to the user to implement this. As to Gejo Thayil's post, his actual issue was with the "received and sending PORT mismatch". He implemented sending the response himself. No, unfortunately we haven't done anything about this issue. Cheers, Birgit On 26/11/07 20:05, Maurice Ling wrote: > Hi Everyone, > > I would like to get clarification on the status of Inform support in > Westhawk SNMP 6.0. According to the web site: > http://snmp.westhawk.co.uk/, SNMP Inform receiving and sending is > supported. In addition, other discussions on the mailing list > indicate some support for Inform responses: > http://snmp.westhawk.co.uk/pipermail/snmp/2006-November/000444.html > > However, when I run the examplev3 ReceiveTrap program and generate > informs to it using net-snmp's sendinform program, the program times > out, which indicates that there are no Inform responses being > generated. > > My main question is does the Westhawk SNMP stack send responses to > Informs, or is that is a capability that the user has to implement? > It sounds like Gejo Thayil in the above referenced thread had come up > with a solution. Is that source available to the general public? > > Thank you in advance for your responses! > > Regards, > > -Maurice > _______________________________________________ > 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 Tue Nov 27 22:59:43 2007 From: jbers at bbn.com (Josh Bers) Date: Wed Nov 28 04:00:42 2007 Subject: [snmp] retrieving stack version Message-ID: <004101c83173$2051c910$010010ac@JBERS2> How would I query the stack for the implementation version? I noted that the manifest uses the following non-standard attributes: Name: uk/co/westhawk version: 6_0 However, these cannot be retrieved via the Package class. thanks, Josh From birgit at westhawk.co.uk Wed Nov 28 11:17:14 2007 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Wed Nov 28 11:18:34 2007 Subject: [snmp] retrieving stack version In-Reply-To: <004101c83173$2051c910$010010ac@JBERS2> References: <004101c83173$2051c910$010010ac@JBERS2> Message-ID: <474D4E3A.4060203@westhawk.co.uk> Hi Josh, That's a very interesting question. We've not use Package in the stack, but it would not be too hard to change it. I read http://www.javaspecialists.eu/archive/Issue026.html to get a bit more insight. We could amend build.xml so it adds to the manifest of section Name: uk/co/westhawk Implementation-Title: Westhawk Java SNMP Stack Implementation-Version: 6.0 That should do the trick? Cheers, Birgit On 28/11/07 03:59, Josh Bers wrote: > How would I query the stack for the implementation version? I noted that the > manifest uses the following non-standard attributes: > > Name: uk/co/westhawk > version: 6_0 > > However, these cannot be retrieved via the Package class. > > thanks, > > 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 Wed Nov 28 18:08:19 2007 From: jbers at bbn.com (Josh Bers) Date: Wed Nov 28 23:09:48 2007 Subject: [snmp] retrieving stack version In-Reply-To: <474D4E3A.4060203@westhawk.co.uk> Message-ID: <006b01c83213$94f5c000$010010ac@JBERS2> Birgit, I believe that putting the version/title properties at the top of the manifest, after the standard headers but before any Name: sections should work better. The problem of putting it under /uk/co/westhawk is that there are no classes in that package and I'm not sure that they pass the properties down to child packages.. However, in my experience, if you put it at the top it applies to all classes in the jar. Regards, Josh > -----Original Message----- > From: snmp-bounces@snmp.westhawk.co.uk > [mailto:snmp-bounces@snmp.westhawk.co.uk] On Behalf Of Birgit > Arkesteijn > Sent: Wednesday, November 28, 2007 6:17 AM > To: List for discussion of the Westhawk SNMP stack > Subject: Re: [snmp] retrieving stack version > > > Hi Josh, > > That's a very interesting question. We've not use Package in > the stack, > but it would not be too hard to change it. > > I read > http://www.javaspecialists.eu/archive/Issue026.html > to get a bit more insight. > > We could amend build.xml so it adds to the manifest of section > Name: uk/co/westhawk > > Implementation-Title: Westhawk Java SNMP Stack > Implementation-Version: 6.0 > > That should do the trick? > > Cheers, Birgit > > > On 28/11/07 03:59, Josh Bers wrote: > > How would I query the stack for the implementation version? I noted > > that the manifest uses the following non-standard attributes: > > > > Name: uk/co/westhawk > > version: 6_0 > > > > However, these cannot be retrieved via the Package class. > > > > thanks, > > > > 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 > -- > _______________________________________________ > snmp mailing list > snmp@snmp.westhawk.co.uk > http://snmp.westhawk.co.uk/mailman/listinfo/snmp > From birgit at westhawk.co.uk Thu Nov 29 12:02:11 2007 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Thu Nov 29 12:03:33 2007 Subject: [snmp] retrieving stack version In-Reply-To: <006b01c83213$94f5c000$010010ac@JBERS2> References: <006b01c83213$94f5c000$010010ac@JBERS2> Message-ID: <474EAA43.9090805@westhawk.co.uk> Hi Josh, I see. The only downside is that the Version than will apply to the bouncycastle packages as well, and that isn't our code. Cheers, Birgit On 28/11/07 23:08, Josh Bers wrote: > Birgit, > > I believe that putting the version/title properties at the top of the > manifest, after the standard headers but before any Name: sections should > work better. > > The problem of putting it under /uk/co/westhawk is that there are no classes > in that package and I'm not sure that they pass the properties down to child > packages.. > > However, in my experience, if you put it at the top it applies to all > classes in the jar. > > Regards, > > Josh > >> -----Original Message----- >> From: snmp-bounces@snmp.westhawk.co.uk >> [mailto:snmp-bounces@snmp.westhawk.co.uk] On Behalf Of Birgit >> Arkesteijn >> Sent: Wednesday, November 28, 2007 6:17 AM >> To: List for discussion of the Westhawk SNMP stack >> Subject: Re: [snmp] retrieving stack version >> >> >> Hi Josh, >> >> That's a very interesting question. We've not use Package in >> the stack, >> but it would not be too hard to change it. >> >> I read >> http://www.javaspecialists.eu/archive/Issue026.html >> to get a bit more insight. >> >> We could amend build.xml so it adds to the manifest of section >> Name: uk/co/westhawk >> >> Implementation-Title: Westhawk Java SNMP Stack >> Implementation-Version: 6.0 >> >> That should do the trick? >> >> Cheers, Birgit >> >> >> On 28/11/07 03:59, Josh Bers wrote: >>> How would I query the stack for the implementation version? I noted >>> that the manifest uses the following non-standard attributes: >>> >>> Name: uk/co/westhawk >>> version: 6_0 >>> >>> However, these cannot be retrieved via the Package class. >>> >>> thanks, >>> >>> Josh -- -- 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 andy at riftware.com Thu Nov 29 07:56:30 2007 From: andy at riftware.com (Andrew Chandler) Date: Thu Nov 29 13:57:22 2007 Subject: [snmp] retrieving stack version In-Reply-To: <474EAA43.9090805@westhawk.co.uk> Message-ID: <200711291349.lATDmsBe009693@dedicated.riftware.com> I believe it does pass down to child packages much like the logging facilities do - easy enough to try anyhow isn't it? -----Original Message----- From: snmp-bounces@snmp.westhawk.co.uk [mailto:snmp-bounces@snmp.westhawk.co.uk] On Behalf Of Birgit Arkesteijn Sent: Thursday, November 29, 2007 6:02 AM To: List for discussion of the Westhawk SNMP stack Subject: Re: [snmp] retrieving stack version Hi Josh, I see. The only downside is that the Version than will apply to the bouncycastle packages as well, and that isn't our code. Cheers, Birgit On 28/11/07 23:08, Josh Bers wrote: > Birgit, > > I believe that putting the version/title properties at the top of the > manifest, after the standard headers but before any Name: sections should > work better. > > The problem of putting it under /uk/co/westhawk is that there are no classes > in that package and I'm not sure that they pass the properties down to child > packages.. > > However, in my experience, if you put it at the top it applies to all > classes in the jar. > > Regards, > > Josh > >> -----Original Message----- >> From: snmp-bounces@snmp.westhawk.co.uk >> [mailto:snmp-bounces@snmp.westhawk.co.uk] On Behalf Of Birgit >> Arkesteijn >> Sent: Wednesday, November 28, 2007 6:17 AM >> To: List for discussion of the Westhawk SNMP stack >> Subject: Re: [snmp] retrieving stack version >> >> >> Hi Josh, >> >> That's a very interesting question. We've not use Package in >> the stack, >> but it would not be too hard to change it. >> >> I read >> http://www.javaspecialists.eu/archive/Issue026.html >> to get a bit more insight. >> >> We could amend build.xml so it adds to the manifest of section >> Name: uk/co/westhawk >> >> Implementation-Title: Westhawk Java SNMP Stack >> Implementation-Version: 6.0 >> >> That should do the trick? >> >> Cheers, Birgit >> >> >> On 28/11/07 03:59, Josh Bers wrote: >>> How would I query the stack for the implementation version? I noted >>> that the manifest uses the following non-standard attributes: >>> >>> Name: uk/co/westhawk >>> version: 6_0 >>> >>> However, these cannot be retrieved via the Package class. >>> >>> thanks, >>> >>> Josh -- -- 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 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.