From andy at riftware.com Wed Mar 5 11:05:37 2008 From: andy at riftware.com (Andrew Chandler) Date: Wed Mar 5 17:06:28 2008 Subject: [snmp] Context Listeners and Enterprise Beans Message-ID: <200803051649.m25Gn9wM018399@dedicated.riftware.com> Hi folks - one of our other development groups has had to create a trap listener which is a part of the stack I haven't really used much. What they have run into is that the trap listener is in the J2EE Bean and when they go to redeploy the port 162 isn't being relinquished. They do have code on deploy that says if the context isn't null they should call destroy on it but I can't remember what circumstances could cause that port to be locked open even temporarily - is there anything we should be watching out for? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From birgit at westhawk.co.uk Wed Mar 5 18:06:09 2008 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Wed Mar 5 18:07:38 2008 Subject: [snmp] Context Listeners and Enterprise Beans In-Reply-To: <200803051649.m25Gn9wM018399@dedicated.riftware.com> References: <200803051649.m25Gn9wM018399@dedicated.riftware.com> Message-ID: <47CEE111.2050300@westhawk.co.uk> Hi Andy, I assume they add the trap listener to the context? So: SnmpContextX context = new SnmpContextX(..); context.addTrapListener(this, ListeningContextPool.DEFAULT_TRAP_PORT); They should call: context.removeTrapListener(this, ListeningContextPool.DEFAULT_TRAP_PORT); Port 162 will remain open as long as there is a single listener. In order to remove all listeners, use ListeningContextPool.destroyPool() There was a bug in earlier versions with the listener object. Version 4.14 solved: - Destroying a context no longer creates a listener object that listens for incoming traps (or PDUs in general). We haven't had report of new bugs regarding to the ListenerContext(Pool). Hope the above helps. Cheers, Birgit On 05/03/08 17:05, Andrew Chandler wrote: > Hi folks - one of our other development groups has had to create a trap > listener which is a part of the stack I haven't really used much. What > they have run into is that the trap listener is in the J2EE Bean and when > they go to redeploy the port 162 isn't being relinquished. They do have > code on deploy that says if the context isn't null they should call destroy > on it but I can't remember what circumstances could cause that port to be > locked open even temporarily - is there anything we should be watching out > for? > > -- -- 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 Wed Mar 5 12:57:01 2008 From: andy at riftware.com (Andrew Chandler) Date: Wed Mar 5 18:59:56 2008 Subject: [snmp] Context Listeners and Enterprise Beans In-Reply-To: <47CEE111.2050300@westhawk.co.uk> Message-ID: <200803051841.m25IektH019657@dedicated.riftware.com> Sounds like that is exactly what they needed to know! Thanks as always Birgit. -----Original Message----- From: snmp-bounces@snmp.westhawk.co.uk [mailto:snmp-bounces@snmp.westhawk.co.uk] On Behalf Of Birgit Arkesteijn Sent: Wednesday, March 05, 2008 12:06 PM To: List for discussion of the Westhawk SNMP stack Cc: Andrew Maxwell Subject: Re: [snmp] Context Listeners and Enterprise Beans Hi Andy, I assume they add the trap listener to the context? So: SnmpContextX context = new SnmpContextX(..); context.addTrapListener(this, ListeningContextPool.DEFAULT_TRAP_PORT); They should call: context.removeTrapListener(this, ListeningContextPool.DEFAULT_TRAP_PORT); Port 162 will remain open as long as there is a single listener. In order to remove all listeners, use ListeningContextPool.destroyPool() There was a bug in earlier versions with the listener object. Version 4.14 solved: - Destroying a context no longer creates a listener object that listens for incoming traps (or PDUs in general). We haven't had report of new bugs regarding to the ListenerContext(Pool). Hope the above helps. Cheers, Birgit On 05/03/08 17:05, Andrew Chandler wrote: > Hi folks - one of our other development groups has had to create a trap > listener which is a part of the stack I haven't really used much. What > they have run into is that the trap listener is in the J2EE Bean and when > they go to redeploy the port 162 isn't being relinquished. They do have > code on deploy that says if the context isn't null they should call > destroy on it but I can't remember what circumstances could cause that > port to be locked open even temporarily - is there anything we should > be watching out for? > > -- -- 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. From jbers at bbn.com Wed Mar 5 13:58:29 2008 From: jbers at bbn.com (Josh Bers) Date: Wed Mar 5 19:00:20 2008 Subject: [snmp] Context Listeners and Enterprise Beans In-Reply-To: <200803051649.m25Gn9wM018399@dedicated.riftware.com> Message-ID: <004201c87ef2$ec32d980$6601a8c0@7C911> Andy, I've run into this problem as well. If I remember right, you have to be very careful about removing all trap listeners from a context. The trick is to specify the same port number on which you originally setup the trap listener in the remove method. If you don't specify the port then the default method does not remove it from port 162... Josh -----Original Message----- From: snmp-bounces@snmp.westhawk.co.uk [mailto:snmp-bounces@snmp.westhawk.co.uk] On Behalf Of Andrew Chandler Sent: Wednesday, March 05, 2008 12:06 PM To: snmp@snmp.westhawk.co.uk Cc: Andrew Maxwell Subject: [snmp] Context Listeners and Enterprise Beans Hi folks - one of our other development groups has had to create a trap listener which is a part of the stack I haven't really used much. What they have run into is that the trap listener is in the J2EE Bean and when they go to redeploy the port 162 isn't being relinquished. They do have code on deploy that says if the context isn't null they should call destroy on it but I can't remember what circumstances could cause that port to be locked open even temporarily - is there anything we should be watching out for? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ snmp mailing list snmp@snmp.westhawk.co.uk http://snmp.westhawk.co.uk/mailman/listinfo/snmp From birgit at westhawk.co.uk Thu Mar 6 11:20:57 2008 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Thu Mar 6 11:23:36 2008 Subject: [snmp] Context Listeners and Enterprise Beans In-Reply-To: <004201c87ef2$ec32d980$6601a8c0@7C911> References: <004201c87ef2$ec32d980$6601a8c0@7C911> Message-ID: <47CFD399.2040802@westhawk.co.uk> Hi, I thought about a bit more: Looking at AbstractSnmpContext.run(), I notice that at the end it stops listening on ListeningContextFace.DEFAULT_TRAP_PORT (162): ListeningContextPool lcontext = new ListeningContextPool(ListeningContextFace.DEFAULT_TRAP_PORT, bindAddr, typeSocket); lcontext.removeRawPduListenerFromPool(this); The loop in run() should stop a bit after destroy() is called. This should mean that calling destroy() on a context should be enough. Apparently it doesn't, what surprises me. Cheers, Birgit On 05/03/08 18:58, Josh Bers wrote: > Andy, > > I've run into this problem as well. If I remember right, you have to be very > careful about removing all trap listeners from a context. The trick is to > specify the same port number on which you originally setup the trap listener > in the remove method. If you don't specify the port then the default method > does not remove it from port 162... > > Josh > > -----Original Message----- > From: snmp-bounces@snmp.westhawk.co.uk > [mailto:snmp-bounces@snmp.westhawk.co.uk] On Behalf Of Andrew Chandler > Sent: Wednesday, March 05, 2008 12:06 PM > To: snmp@snmp.westhawk.co.uk > Cc: Andrew Maxwell > Subject: [snmp] Context Listeners and Enterprise Beans > > Hi folks - one of our other development groups has had to create a trap > listener which is a part of the stack I haven't really used much. What > they have run into is that the trap listener is in the J2EE Bean and when > they go to redeploy the port 162 isn't being relinquished. They do have > code on deploy that says if the context isn't null they should call destroy > on it but I can't remember what circumstances could cause that port to be > locked open even temporarily - is there anything we should be watching out > for? > > -- -- 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 snookala at alcatel-lucent.com Wed Mar 19 12:57:08 2008 From: snookala at alcatel-lucent.com (Nookala, Sridevi (Sridevi)) Date: Thu Mar 20 11:04:49 2008 Subject: [snmp] decoding traps from a mulit homed host - raw pdu listener Message-ID: Dear westhawk, In my code I am listening for traps on a specific port using Listening context pool, I am using my own trap listener this way New ListeningContextPool( port).addListener( listener); Where listener = new MyRawPduListenerImp(); public class MyRawPduListenerImp implements RawPduListener { public void rawPduReceived(RawPduEvent evt) { try { //RawPduEvent is always undecoded //If it is an undecoded trap, then the version number, the hostAddress and the byte array is available //The SNMP version number of the trap. The version is part of an undecoded trap event. int version = evt.getVersion(); //The IP address of the host where the trap came from. The host address is part of an undecoded the trap event . String host = evt.getHostAddress(); //To decode an undecoded trap event, you create a context on the fly and call processIncomingPdu //The context should contain all the parameters needed to decode the message. if ( ( version == SnmpConstants.SNMP_VERSION_1 ) || ( version == SnmpConstants.SNMP_VERSION_2c ) ) { SnmpContextBasisFace context = getSnmpContext( host, port,version ); System.err.println("context is " + context.toString() ); if( context instanceof SnmpContextv2c ) ((SnmpContextv2c)context).setCommunity( getCommunity(host) ); else if ( context instanceof SnmpContext ) ((SnmpContext)context).setCommunity( getCommunity(host) ); System.err.println("context again is " + context.toString() ); Pdu trapPdu = context.processIncomingPdu(evt.getMessage()); } } Catch(Exception e) { } } Now the trap sender for me is a multihomed host. So the "FROM ADDRESS" got via evt.getHostAddress() is header. The actual instance address/ Ethernet address is not available until I have a PDU as it is one of the varbinds. The trap pdu is not available unless I decode it and for decoding the trap from raw byte array, I need the correct community. I don't have the community for this Header IP. I have the community configured only for each of its "interface address" So I kind of have a chicken / egg issue. I need the community to get pdu on the fly and I do not know the community unless I have the pdu as one of the varbinds is the interface address. Is there any way, I can get the actual interface address from RawPduEvt and not the base address/ header ip Thx, Sri From birgit at westhawk.co.uk Thu Mar 20 11:59:10 2008 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Thu Mar 20 12:00:45 2008 Subject: [snmp] decoding traps from a mulit homed host - raw pdu listener In-Reply-To: References: Message-ID: <47E2518E.5040100@westhawk.co.uk> Dear Sri, This "chicken and egg" is a recurring problem. The philosophy is that a trap listener always knows who sends traps and what the parameters are (like community name) of that trap. After all, the community name is a security measure (albeit a poor one). I understand from your email that the community name that is sent with each trap request will differ from machine to machine. Is that correct? It's a slightly surprising setup, but I'm sure it has its reasons. If that's the case, yes, you have a problem. However, when using SNMPv1 and v2c, you can change the stack easily to decode those traps. For example, you can change uk.co.westhawk.snmp.stack.AsnDecoderv1.DecodeSNMP(InputStream in, String community) and omit the community parameter and remove the test on the community name. You could even make a version that joins v1 & v2c, by omitting the test on the SNMP version as well. You run the risk of accepting malicious traps, but it sounds like you're not that bothered about the community name anyway. Hope the above helps, Birgit On 19/03/08 17:57, Nookala, Sridevi (Sridevi) wrote: > Dear westhawk, > > > > In my code I am listening for traps on a specific port using Listening > context pool, I am using my own trap listener this way > > > > New ListeningContextPool( port).addListener( listener); > > > > Where listener = new MyRawPduListenerImp(); > > > > public class MyRawPduListenerImp implements RawPduListener > > { > > public void rawPduReceived(RawPduEvent evt) > > { > > try > > { > > //RawPduEvent is always undecoded > > //If it is an undecoded trap, then the version number, the > hostAddress and the byte array is available > > > > //The SNMP version number of the trap. The version is part of > an undecoded trap event. > > > > int version = evt.getVersion(); > > > > //The IP address of the host where the trap came from. The > host address is part of an undecoded the trap event > > . > > String host = evt.getHostAddress(); > > > > //To decode an undecoded trap event, you create a context on > the fly and call processIncomingPdu > > //The context should contain all the parameters needed to > decode the message. > > > > if ( ( version == SnmpConstants.SNMP_VERSION_1 ) || > > ( version == SnmpConstants.SNMP_VERSION_2c ) ) > > { > > SnmpContextBasisFace context = getSnmpContext( host, > port,version ); > > > > System.err.println("context is " + context.toString() ); > > > > if( context instanceof SnmpContextv2c ) > > ((SnmpContextv2c)context).setCommunity( > getCommunity(host) ); > > else if ( context instanceof SnmpContext ) > > ((SnmpContext)context).setCommunity( getCommunity(host) > ); > > > > System.err.println("context again is " + > context.toString() ); > > > > Pdu trapPdu = > context.processIncomingPdu(evt.getMessage()); > > } > > } > > Catch(Exception e) { } > > } > > > > Now the trap sender for me is a multihomed host. So the "FROM ADDRESS" > got via evt.getHostAddress() is header. The actual instance address/ > Ethernet address is not available until I have a PDU as it is one of the > varbinds. > > > > The trap pdu is not available unless I decode it and for decoding the > trap from raw byte array, I need the correct community. > > > > I don't have the community for this Header IP. I have the community > configured only for each of its "interface address" > > > > So I kind of have a chicken / egg issue. I need the community to get > pdu on the fly and I do not know the community unless I have the pdu as > one of the varbinds is the interface address. > > > > Is there any way, I can get the actual interface address from > RawPduEvt and not the base address/ header ip > > > > Thx, > > Sri > > _______________________________________________ > 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 Mar 25 13:09:11 2008 From: jbers at bbn.com (Josh Bers) Date: Tue Mar 25 17:47:02 2008 Subject: [snmp] mailing list archives In-Reply-To: <47CFD399.2040802@westhawk.co.uk> Message-ID: <001e01c88e9b$0501fab0$05fe5980@7C911> The mailing list archives are not accessible via the url below: http://snmp.westhawk.co.uk/mailman/listinfo/snmp thanks, Josh From birgit at westhawk.co.uk Tue Mar 25 17:56:40 2008 From: birgit at westhawk.co.uk (Birgit Arkesteijn) Date: Tue Mar 25 17:57:56 2008 Subject: [snmp] Re: mailing list archives In-Reply-To: <001e01c88e9b$0501fab0$05fe5980@7C911> References: <001e01c88e9b$0501fab0$05fe5980@7C911> Message-ID: <47E93CD8.2040703@westhawk.co.uk> Hi Josh, Thanks for noticing and telling us! The machine run out of disk space. I created a bit more space and rebooted. The mailinglists are now accessible again. Tomorrow I'll add a script that will warn us in advance. Sorry for the inconvenience. Cheers, Birgit On 25/03/08 17:09, Josh Bers wrote: > The mailing list archives are not accessible via the url below: > > http://snmp.westhawk.co.uk/mailman/listinfo/snmp > > 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 --