Menu
▾
▴
net-snmp-coders
|
From: Vivek N. <nag...@gm...> - 2011-09-28 06:56:23
|
Hello all, I am building an application which sends SNMP trap which executes 'snmptrap' command. Since I see that the 162 port is used by many other applications, the port is rarely left free so that I can send the traps. Is there anyway that I can make it send to custom port other than 162??? I just got a linux machine and I am ok to compile the net-snmp source if it involves that. Thanks, Vivek |
|
From: Dave S. <D.T...@li...> - 2011-09-28 07:17:01
|
On 28 September 2011 07:56, Vivek Nagaraj <nag...@gm...> wrote:
> I am building an application which sends SNMP trap which executes
> 'snmptrap' command.
> Is there anyway that I can make it send to custom port other than
> 162???
$ man snmpcmd
AGENT SPECIFICATION
<transport-specifier> <transport-address> format
udp hostname[:port] or IPv4-address[:port]
Note the ':port' element.
So if you specify a trap destination of someHost:99162
the trap will be sent to that port, instead of the default 162
Dave
|
|
From: Vivek N. <nag...@gm...> - 2011-09-28 07:49:53
|
Ok. That seems to be good one. But cant I just change the default port to some other other than 162 in the net-snmp code and get it compiled? |
|
From: Niels B. <nb...@us...> - 2011-10-03 05:41:25
|
On Mon, Oct 03, 2011 at 08:44:50AM +0530, Vivek Nagaraj wrote: > Response to your previous mail: > > 1) Could not find 'snmp.conf' You have to create it yourself. > 2) And options you have mentioned to be used with 'snmptrap' command > is not working > [root@localhost snmp]# snmptrap -v 1 -m ALL -c public 135.36.115.62 .1.3.6.1.6.3 169.254.1.1 6 1 20071105 udp:169.254.1.1:30617 > udp:169.254.1.1:30617: Missing type/value for variable That last udp:169... parameter does not make sense. You probably meant snmptrap -v 1 -m ALL -c public 135.36.115.62:30617 .1.3.6.1.6.3 169.254.1.1 6 1 20071105 /Niels -- Niels Baggesen - @home - Århus - Denmark - nb...@us... The purpose of computing is insight, not numbers --- R W Hamming |
|
From: Magnus F. <ma...@ly...> - 2011-09-28 08:22:54
|
On Wed, 2011-09-28 at 13:19 +0530, Vivek Nagaraj wrote: > Ok. That seems to be good one. > > But cant I just change the default port to some other other than 162 > in the net-snmp code and get it compiled? You do not need to recompile to change the default port. Put the following line in your snmp.conf to change the default port for udp over ipv4 trap connections to 50162: defTarget snmptrap udp :50162 /MF |
|
From: Vivek N. <nag...@gm...> - 2011-09-28 09:02:58
|
Thanks a lot!!! That worked like a charm on the first go! But the problem I faced was that the first time I got the trap at the right port (not 162), but subsequent traps were still sent to the default port i.e., 162. Can you please help me on this??? Thanks a ton. |
|
From: Vivek N. <nag...@gm...> - 2011-10-03 06:41:56
|
Thanks a lot Niels! snmptrap -v 1 -m ALL -c public 135.36.115.62:30617 .1.3.6.1.6.3 169.254.1.1 6 1 20071105 >> Worked like magic on custom ports on RHEL 6.1! Is there any net-snmp issue (you are aware of) regarding this in older net-snmp binaries placed in RHEL 4.7?! In simple words, its working fine in RHEL 6.1 but not in RHEL 4.7. Any idea why? |
|
From: Niels B. <nb...@us...> - 2011-10-03 13:12:19
|
On Mon, Oct 03, 2011 at 12:11:50PM +0530, Vivek Nagaraj wrote: > Is there any net-snmp issue (you are aware of) regarding this in older > net-snmp binaries placed in RHEL 4.7?! > > In simple words, its working fine in RHEL 6.1 but not in RHEL 4.7. Any idea why? Define "not working"! Any error message, or what happens? It works for me with the stock snmptrap on RedHat 4.9 /Niels -- Niels Baggesen - @home - Århus - Denmark - nb...@us... The purpose of computing is insight, not numbers --- R W Hamming |
|
From: Vivek N. <nag...@gm...> - 2011-10-03 14:21:04
|
Ok. I am sorry. Not working in the sense, if I provide custom ports other than 162, I am not receiving any traps at those custom ports. I am not seeing any error message after the execution of the command mentioned by you. My server administrator says that the backward compatibility needs to be maintained with older server OS too. I am kind of stuck. I tried and tried and tried but could not receive traps at the ports other than 162. snmptrap -v 1 -m ALL -c public 135.36.115.62:30617 .1.3.6.1.6.3 169.254.1.1 6 1 20071105 >> Works well and traps are received in port no 30617 in RHEL 5.X upwards snmptrap -v 1 -m ALL -c public 135.36.115.62:30617 .1.3.6.1.6.3 169.254.1.1 6 1 20071105 >> Not receiving traps in port no 30617 in RHEL 4.X (tried with RHEL 4.7 x86 and x64) <and I am not seeing traps even in port no 162; quite dangerous I think> <Problem at sending or receiving side?! Any tweaks to be made at the sender or receiver?> snmptrap -v 1 -m ALL -c public 135.36.115.62:162 .1.3.6.1.6.3 169.254.1.1 6 1 20071105 >> Works well and traps are received in port no 162 in RHEL 4.X Was there a known issue earlier with SNMP rectified at a later stage? Thanks a ton guys! |
|
From: Niels B. <nb...@us...> - 2011-10-03 15:44:39
|
On Mon, Oct 03, 2011 at 07:50:57PM +0530, Vivek Nagaraj wrote: > My server administrator says that the backward compatibility needs to > be maintained with older server OS too. I am kind of stuck. I tried > and tried and tried but could not receive traps at the ports other > than 162. With an up2date RHEL4, which is 4.9, it works. On 4.7, which currently installs net-snmp-utils 5.1.2-18.el4, it also works. That is the best verification I can do. I do not remember a problem with specifying the trap port. Are you sure it isn't a firewall issue for your RHEL system? Can you run tcpdump when you send the trap? Anyway, why are you running 4.7 which is several moons out of date? /Niels -- Niels Baggesen - @home - Århus - Denmark - nb...@us... The purpose of computing is insight, not numbers --- R W Hamming |
|
From: Magnus F. <ma...@ly...> - 2011-10-03 21:20:17
|
On Mon, 2011-10-03 at 19:50 +0530, Vivek Nagaraj wrote: > Ok. I am sorry. Not working in the sense, if I provide custom ports > other than 162, I am not receiving any traps at those custom ports. > > I am not seeing any error message after the execution of the command > mentioned by you. > > My server administrator says that the backward compatibility needs to > be maintained with older server OS too. I am kind of stuck. I tried > and tried and tried but could not receive traps at the ports other > than 162. > > snmptrap -v 1 -m ALL -c public 135.36.115.62:30617 .1.3.6.1.6.3 > 169.254.1.1 6 1 20071105 > >> Works well and traps are received in port no 30617 in RHEL 5.X upwards > > snmptrap -v 1 -m ALL -c public 135.36.115.62:30617 .1.3.6.1.6.3 > 169.254.1.1 6 1 20071105 > >> Not receiving traps in port no 30617 in RHEL 4.X (tried with RHEL 4.7 x86 and x64) <and I am not seeing traps even in port no 162; quite dangerous I think> > <Problem at sending or receiving side?! Any tweaks to be made at the > sender or receiver?> > > snmptrap -v 1 -m ALL -c public 135.36.115.62:162 .1.3.6.1.6.3 > 169.254.1.1 6 1 20071105 > >> Works well and traps are received in port no 162 in RHEL 4.X Could you please check the version of net-snmp on those platforms. snmptrap -V should output that. I do not know what versions all the different redhats are using. > Was there a known issue earlier with SNMP rectified at a later stage? The defTarget/defDomains stuff have only existed since 2006-09 and the first release it was part of was Net-SNMP 5.4 and IIRC RHEL4 is using something earlier than that. /MF |
|
From: Magnus F. <ma...@ly...> - 2011-10-01 10:12:36
|
On Wed, 2011-09-28 at 14:32 +0530, Vivek Nagaraj wrote: > Thanks a lot!!! That worked like a charm on the first go! But the > problem I faced was that the first time I got the trap at the right > port (not 162), but subsequent traps were still sent to the default > port i.e., 162. > > Can you please help me on this??? This sounds odd as there is nothing in there that should reset the target port. Could you please walk me through the problem you are seeing step by step so that I can reproduce it. /MF |
|
From: Vivek N. <nag...@gm...> - 2011-10-01 14:14:38
|
All I did was added this line in 'snmpd.conf': "defTarget snmptrap udp :50162" and restarted the snmpd service using: 'service snmpd restart'. I used to get the first trap at the UDP port 50162. And I used to receive trap on my client Windows machine where the trap receiver was running at the default port 162 rather than the mentioned port. Any setting/tweaks (you remember) to be done on the client/server?! The command used to send dummy trap was 'snmptrap'. The server from which snmptrap was generated was RHEL 6.1 x64. Any idea why am I still not receiving traps at default port?! Thanks a ton for the response. |
|
From: Magnus F. <ma...@ly...> - 2011-10-01 15:10:04
|
On Sat, 2011-10-01 at 19:44 +0530, Vivek Nagaraj wrote: > All I did was added this line in 'snmpd.conf': "defTarget snmptrap udp > :50162" and restarted the snmpd service using: 'service snmpd > restart'. > > I used to get the first trap at the UDP port 50162. And I used to > receive trap on my client Windows machine where the trap receiver was > running at the default port 162 rather than the mentioned port. Any > setting/tweaks (you remember) to be done on the client/server?! > > The command used to send dummy trap was 'snmptrap'. The server from > which snmptrap was generated was RHEL 6.1 x64. > > Any idea why am I still not receiving traps at default port?! Yes. > Thanks a ton for the response. You added defTarget snmptrap udp :50162 to snmpd.conf snmpd.conf is the config file for the snmp agent (snmpd). Then you use snmptrap to send a trap. Since snmptrap isn't reading snmpd.conf that explains why it didn't affect that program. To change it for all programs you should put it in snmp.conf. /MF |
|
From: Vivek N. <nag...@gm...> - 2011-10-02 05:07:19
|
Ok. That sounds reasonable. Thanks a lot! Hope you can can answer my following questions: 1) What is the difference between snmp.conf and snmpd.conf files in '/etc/snmp/' directory? 2) When I execl 'snmptrap' command from my program, which of the above two *.conf files are actually used? Thanks, Vivek |
|
From: Vivek N. <nag...@gm...> - 2011-10-04 02:50:03
|
The RHEL 4.6 32-bit I am using has net-SNMP version 5.1.2. So, I hope this would not support ports mentioned with the snmptrap command. Please correct me if I am wrong. The RHEL 6.1 has version 5.5 installed. So, you mean to say any net-SNMP version above and including net-SNMP 5.4 supports mentioning ports along with host name? Thanks, Vivek |
|
From: Niels B. <nb...@us...> - 2011-10-04 05:01:14
|
On Tue, Oct 04, 2011 at 08:19:57AM +0530, Vivek Nagaraj wrote: > So, you mean to say any net-SNMP version above and including net-SNMP > 5.4 supports mentioning ports along with host name? No, Magnus is telling you about the defTarget directive. I just told you that using portnumber with hostname works with the 5.1.2 version that comes with a RHEL 4.5 as I just installed it (5.1.2-18.el4). /Niels -- Niels Baggesen - @home - Århus - Denmark - nb...@us... The purpose of computing is insight, not numbers --- R W Hamming |
|
From: Vivek N. <nag...@gm...> - 2011-10-04 05:51:09
|
I just tried it on RHEL 4.6 x86. Here is the more detailed OS info: Linux dhcp-135-24-228-150 2.6.9-67.EL #1 Wed Nov 7 13:41:13 EST 2007 i686 i686 i386 GNU/Linux Red Hat Enterprise Linux AS release 4 (Nahant Update 6) NET-SNMP version: 5.1.2 When I executed this command on RHEL 4.6 x86 snmptrap -v 1 -m ALL -c public 135.36.115.62:250 .1.3.6.1.6.3 169.254.1.1 6 1 20071105 I didnt see any trap message on myclient machine at port 250. No error message in '/var/log/messages' either. Any reason why? Need to down firewall. Did that. Any idea? Thanks a lot! |
|
From: Magnus F. <ma...@ly...> - 2011-10-04 06:27:33
|
On Tue, 2011-10-04 at 11:21 +0530, Vivek Nagaraj wrote: > I just tried it on RHEL 4.6 x86. Here is the more detailed OS info: > Linux dhcp-135-24-228-150 2.6.9-67.EL #1 Wed Nov 7 13:41:13 EST 2007 > i686 i686 i386 GNU/Linux > Red Hat Enterprise Linux AS release 4 (Nahant Update 6) > NET-SNMP version: 5.1.2 > > When I executed this command on RHEL 4.6 x86 > snmptrap -v 1 -m ALL -c public 135.36.115.62:250 .1.3.6.1.6.3 > 169.254.1.1 6 1 20071105 > > I didnt see any trap message on myclient machine at port 250. I assume that myclient is 135.36.115.62. > No error message in '/var/log/messages' either. Any reason why? I tried that command. I got a long message about syntax error on standard error. Try with snmptrap -v 1 -m ALL -c public \ 135.36.115.62:5000 .1.3.6.1.6.3169.254.1.1 127.128.129.130 6 1 20071105 i.e. you had forgotten to add the agent address to the trap specifier. /MF |
|
From: Vivek N. <nag...@gm...> - 2011-10-04 06:33:40
|
I have added my agent address to the snmpd.conf file. Or else I would have not received the trap at port no 162. snmptrap -v 1 -m ALL -c public \ 135.36.115.62:5000 .1.3.6.1.6.3169.254.1.1 127.128.129.130 6 1 20071105 >> Yes. The agent is 135.36.115.62. I still didn't receive traps at port no 500. Note: If I change the port no to 162 or not provide the value at all for port, I RECEIVE traps at the default port 162. |
|
From: Magnus F. <ma...@ly...> - 2011-10-04 07:03:54
|
On Tue, 2011-10-04 at 12:03 +0530, Vivek Nagaraj wrote: > I have added my agent address to the snmpd.conf file. Or else I would > have not received the trap at port no 162. Read my lips. snmptrap *DOES NOT OPEN* snmpd.conf! You can write anything you like in that file and it won't affect the operation of snmptrap. I posit that if you perform the following command: snmptrap -v 1 -m ALL -c public \ 135.36.115.62:162 .1.3.6.1.6.3169.254.1.1 127.128.129.130 6 1 20071105 you won't receive anything on the target machine either. Also, please try these commands in a console and not from within your program as they normally logs to standard output/error as they are intended to be interactive. There are flags to redirect the logs to other places. These are also described in the manual. |
|
From: Vivek N. <nag...@gm...> - 2011-10-04 07:15:13
|
I shall provide you some of my findings now. Please correct me if I am wrong. 1) I 'DID' receive the trap message on my trap receiver (another server in the network) on port no 162 if mentioned hostname:portno 2) I 'DID NOT' receive the trap message on my trap receiver (another server in the network) on port no other than 162 if mentioned hostname:portno in the following cmd: >> snmptrap -v 1 -m ALL -c public \ 135.36.115.62:<port no> .1.3.6.1.6.3169.254.1.1 127.128.129.130 6 1 20071105 3) Since you say that the 'defTarget' was introduced in netSNMP v5.4 (I have netSNMP v5.1 pre-installed with the RHEL 4.6 OS) or later, I shall not touch configuration files. Lets leave that for the moment. 4) I am not seeing any snmp errors in '/var/log/message' either. If you know a place where the SNMP logs are generated, can you please let me know the same? |
|
From: Magnus F. <ma...@ly...> - 2011-10-05 05:41:13
|
On Tue, 2011-10-04 at 12:45 +0530, Vivek Nagaraj wrote:
> I shall provide you some of my findings now. Please correct me if I am wrong.
>
> 1) I 'DID' receive the trap message on my trap receiver (another
> server in the network) on port no 162 if mentioned hostname:portno
What command, exactly, did you issue to send this message?
> 2) I 'DID NOT' receive the trap message on my trap receiver (another
> server in the network) on port no other than 162 if mentioned
> hostname:portno in the following cmd:
> >> snmptrap -v 1 -m ALL -c public \
> 135.36.115.62:<port no> .1.3.6.1.6.3169.254.1.1 127.128.129.130 6 1 20071105
Ok. I am assuming that you ran this from the command line. Did it say
anything on standard output/standard error?
What happened if you did use port number 162?
If you adds the flag -d, does it say anything then?
> 3) Since you say that the 'defTarget' was introduced in netSNMP v5.4
> (I have netSNMP v5.1 pre-installed with the RHEL 4.6 OS) or later, I
> shall not touch configuration files. Lets leave that for the moment.
Agreed.
> 4) I am not seeing any snmp errors in '/var/log/message' either. If
> you know a place where the SNMP logs are generated, can you please let
> me know the same?
Since you are running a user tool it defaults to logging on standard
error. You can redirect the logs to a file with -Lf <filename> or to
syslog with -Ls. From the man page snmpcmd(1):
LOGGING OPTIONS
The mechanism and destination to use for logging of warning and
error messages can be controlled by passing various parameters
to the -L flag.
-Le Log messages to the standard error stream.
-Lf FILE
Log messages to the specified file.
-Lo Log messages to the standard output stream.
-Ls FACILITY
Log messages via syslog, using the specified facility
('d' for LOG_DAEMON, 'u' for LOG_USER, or '0'-'7' for
LOG_LOCAL0 through LOG_LOCAL7).
/MF
|
|
From: Vivek N. <nag...@gm...> - 2011-10-06 16:57:46
|
This might seem a lot strange or rather a shock for you guys out there! I am receiving SNMP traps on custom ports from RHEL 4.6 x86. Tried installing trap receiver in one of the client servers in the same subnet as that of the RHEL server. Outside the subnet, I couldn't see traps on my machine though. Not clear why! I couldn't believe it myself. Blame UDP protocol?! Or a firewall issue in the network?! I executed this command at RHEL server: > snmptrap -v 1 -m ALL -c public 135.36.115.62:<any port no> .1.3.6.1.6.3169.254.1.1 127.128.129.130 6 1 20071105 |
|
From: Dave S. <D.T...@li...> - 2011-10-10 12:45:31
|
On 6 October 2011 17:57, Vivek Nagaraj <nag...@gm...> wrote: > I am receiving SNMP traps on custom ports from RHEL 4.6 x86. Tried > installing trap receiver in one of the client servers in the same > subnet as that of the RHEL server. Outside the subnet, I couldn't see > traps on my machine though. Not clear why! > > I couldn't believe it myself. Blame UDP protocol?! Or a firewall issue > in the network?! The two most likely causes would be routing problems, or firewall settings. A missing route would normally trigger an error from the client application. so my money would be on firewalls blocking the packet somewhere. You could try temporarily turning off 'iptables' on the receiving host (assuming this is a Linux system), and see if you can see the incoming traps then. Failing that, have a look at the configuration of any intermediate routers, to see what filtering they might be doing. Dave |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X