Discussion:
Sending SNMP traps to custom ports from Linux
Vivek Nagaraj
2011-09-28 06:56:17 UTC
Permalink
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
Dave Shield
2011-09-28 07:16:54 UTC
Permalink
Post by Vivek Nagaraj
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
Vivek Nagaraj
2011-09-28 07:49:47 UTC
Permalink
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?
Magnus Fromreide
2011-09-28 08:22:44 UTC
Permalink
Post by Vivek Nagaraj
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
Vivek Nagaraj
2011-09-28 09:02:52 UTC
Permalink
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.
Magnus Fromreide
2011-10-01 10:12:27 UTC
Permalink
Post by Vivek Nagaraj
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
Vivek Nagaraj
2011-10-01 14:14:32 UTC
Permalink
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.
Magnus Fromreide
2011-10-01 15:09:55 UTC
Permalink
Post by Vivek Nagaraj
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.
Post by Vivek Nagaraj
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
Vivek Nagaraj
2011-10-02 05:07:13 UTC
Permalink
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
Magnus Fromreide
2011-10-02 07:33:25 UTC
Permalink
Post by Vivek Nagaraj
Ok. That sounds reasonable. Thanks a lot! Hope you can can answer my
1) What is the difference between snmp.conf and snmpd.conf files in
'/etc/snmp/' directory?
snmp.conf is used by all snmp*-programs
snmpd.conf is only used by snmpd

The items you can specify in each of them also differs. Please see the
man pages snmp.conf(5) and snmpd.conf(5) for more discussion.
Post by Vivek Nagaraj
2) When I execl 'snmptrap' command from my program, which of the above
two *.conf files are actually used?
snmp.conf.

You could ask snmptrap this using the -H command line option. That lists
the available configuration items as well as the files were they can be
placed.

Another thing to consider is that you can control this on the command
line of snmptrap as well.

snmptrap ... udp:host:port ...

sends a trap to host:port. If you really want to do it like you have up
til now then

snmptrap ... --defTarget="snmptrap udp :port" host ...

also would send the trap to host:port.



When you starts talking about execl snmptrap I also have to say that I
wouldn't have done it that way...
I would probably either embed the library to send the traps directly or
let the program act as an AgentX subagent and use that to make the agent
send the traps to the places that are specified in it's configuration
file.
But I admit that your solution is quicker to get started with.

/MF
Vivek Nagaraj
2011-10-02 11:32:28 UTC
Permalink
When you starts talking about execl snmptrap I also have to say that I
wouldn't have done it that way...
I would probably either embed the library to send the traps directly or
let the program act as an AgentX subagent and use that to make the agent
send the traps to the places that are specified in it's configuration
file.
But I admit that your solution is quicker to get started with.
Can you pls pls pls elaborate on this? Let me try that out, if feasible. :) You seem to be a SNMP guru!
Thanks,
Vivek
Vivek Nagaraj
2011-10-03 03:14:50 UTC
Permalink
Response to your previous mail:

1) Could not find 'snmp.conf'

2) And options you have mentioned to be used with 'snmptrap' command
is not working

Please refer the attachments for more details.

Thanks a lot for your time and response.
Niels Baggesen
2011-10-03 05:41:16 UTC
Permalink
Post by Vivek Nagaraj
1) Could not find 'snmp.conf'
You have to create it yourself.
Post by Vivek Nagaraj
2) And options you have mentioned to be used with 'snmptrap' command
is not working
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 - ***@users.sourceforge.net
The purpose of computing is insight, not numbers --- R W Hamming
Vivek Nagaraj
2011-10-03 06:41:50 UTC
Permalink
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?
Niels Baggesen
2011-10-03 13:12:06 UTC
Permalink
Post by Vivek Nagaraj
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 - ***@users.sourceforge.net
The purpose of computing is insight, not numbers --- R W Hamming
Vivek Nagaraj
2011-10-03 14:20:57 UTC
Permalink
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!
Niels Baggesen
2011-10-03 15:44:29 UTC
Permalink
Post by Vivek Nagaraj
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 - ***@users.sourceforge.net
The purpose of computing is insight, not numbers --- R W Hamming
Magnus Fromreide
2011-10-03 21:20:07 UTC
Permalink
Post by Vivek Nagaraj
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.
Post by Vivek Nagaraj
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
Vivek Nagaraj
2011-10-04 02:49:57 UTC
Permalink
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
Niels Baggesen
2011-10-04 05:01:05 UTC
Permalink
Post by Vivek Nagaraj
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 - ***@users.sourceforge.net
The purpose of computing is insight, not numbers --- R W Hamming
Vivek Nagaraj
2011-10-04 05:51:01 UTC
Permalink
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!
Magnus Fromreide
2011-10-04 06:27:25 UTC
Permalink
Post by Vivek Nagaraj
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.
Post by Vivek Nagaraj
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
Vivek Nagaraj
2011-10-04 06:33:33 UTC
Permalink
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.
Magnus Fromreide
2011-10-04 07:03:46 UTC
Permalink
Post by Vivek Nagaraj
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.
Vivek Nagaraj
2011-10-04 07:15:02 UTC
Permalink
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
Post by Magnus Fromreide
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?
Magnus Fromreide
2011-10-05 05:41:03 UTC
Permalink
Post by Vivek Nagaraj
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?
Post by Vivek Nagaraj
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
Post by Magnus Fromreide
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?
Post by Vivek Nagaraj
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.
Post by Vivek Nagaraj
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.
Vivek Nagaraj
2011-10-06 16:57:40 UTC
Permalink
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?!
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
Dave Shield
2011-10-10 12:45:25 UTC
Permalink
Post by Vivek Nagaraj
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
Vivek Nagaraj
2011-10-10 13:43:17 UTC
Permalink
Ok. Check this out!

I am connecting the snmp trap sender server directly to my machine
which has a trap receiver server and assigning the IP addresses
manually to each of them.

Only one of the trap receiver software (named webnms) is showing the
received trap (at custom ports) but none other after repeated futile
attempts. Now that I imply that the server is sending the traps
properly but the receiver is somewhat kind of 'filtering' them. I have
set the trap receiver to listen to the proper port too.

See attachment for details.

How could this be possible?! Any suggestions?! Any tweeks to be done
at the receiver end? What snmp trap receivers you guys used?

Thanks,
Vivek

Magnus Fromreide
2011-10-03 21:08:07 UTC
Permalink
Post by Vivek Nagaraj
1) Could not find 'snmp.conf'
As Niels said, you have to make it yourself.
Post by Vivek Nagaraj
2) And options you have mentioned to be used with 'snmptrap' command
is not working
--defTarget="udp:169.254.1.1:30617"

That is wrong. defTarget takes three arguments. Try with

--defTarget="snmptrap udp 169.254.1.1:30617"

/MF
Loading...