Why snmp traps that are generating from the same machines are getting missed in RHEL6.5 ?
What could be the problem ?
Same code is ran on RHEL5.5 traps are not getting missed.
I think that firewall is cause of this behaviour. Try to service iptables stop and service iptables6 stop
Related
I'm trying to get my head around SNMP for a project I'm working on. After I failed miserably getting it to work in my company's network, I set up a simple 3-device network to test things on, consisting of two Windows 10 PCs and a manageable switch between them.
I installed the optional feature "SNMP" on both PCs, made sure the service is running correctly and configured both services to accept SNMP queries from each other. I made sure to open up UDP port 161 in both PCs firewalls. Then I got the Net-SNMP binaries in order to use SNMPGET and SNMPWALK. As an alternative, I set up the SNMP extension for PHP through xampp (since I want to use PHP in my project once I get SNMP to work). Finally, I installed wireshark to monitor what exactly is going on and this is what I found:
When I try SNMPGET or SNMPWALK either through cmd or as a PHP command, I always get a timeout message. Wireshark is showing the get-next-request leaving one PC and arriving correctly on the other, so the network connection itself is working fine. But the receiving PC never sends a response. As I said, I'm pretty new to SNMP and I'm at a loss as to why this is happening. As I understand it, the optional feature for Windows 10 comes with its own SNMP agent, correct? If so, what could cause it to simply ignore an incoming request from a valid source IP?
The funny thing is that this even happens when I try to send an SNMP query to 127.0.0.1. I have no idea what I'm doing wrong...
Thanks to the comment of Lex Li, I was able to finally figure out which step I made a mistake with:
When setting up the SNMP service, under the security tab, I had to add 'public' as an accepted community name (with READ-ONLY rights). I figured since 'public' is sort of the standard read-only community, it would be accepted by default, which apparently it is not.
Alternatively, I guess I could have added my own communtiy name, but I didn't try that since I only want to read some values through SNMP anyways and read-only access is all I need for that.
Thank you very much Lex Li, I'm off to continue my project now!
About 5 days ago, OpenNMS Horizon 22.02 on Ubuntu 18.04.1 LTS stopped accepting traps from network elements. No changes were made to configuration or underlying operating system to my knowledge.
There are about 125 network elements, all Cisco, sending traps.
So far I have checked the following:
tcpdump shows the traps coming into the interface on port 162
Turned on Debug for trapd.log and incoming traps from network elements do not create any log entries
Traps sent with send-trap.pl from the localhost create traps that flow all the way to events
Traps sent with snmptrap either on localhost or another host create log entries that flow all the way to events. The other host is using the same interface that the network elements are using.
ss -lnpu sport = :162 shows an open UPD "UNCONN"
sudo lsof -i :162 shows a single listener java process
Startup of trapd does not seem to show any warnings in the log
I have verified that the ufw and iptables are off
I have updated OpenNMS to 22.04 and updated Ubunutu with no relief
Restarted OpenNMS many many times...
I moved Trapd startup after Asterisk in service-configuration.xml based on this
All of this seems similar to this. I think the last commenter on that thread asked about comparing the successful and unsuccessful traps in Wireshark which I have not done but all of the traps that are being sent have worked hundreds if not thousands of times until November 6th.
Is there anywhere else to look for errors as to why Trapd is not accepting traps? I think I have ruled out network issues.
I created a new Ubuntu 18.04 VM, updated it and then installed Horizon 23.01 fresh. I pointed my stream of traps at it and it behaves the exactly the same way, none of the traps create any log entries on the trapd.log with the level set to debug. Tcpdump shows the traps coming to the interface.
Issue Resolved.
The underlying operating system lost its static route for the subnet that the traps were coming from. OpenNMS had a route back to the subnet but not via the path that the traps were coming in from. Once the static route was restored, traps started working again and were flowing all the way to events.
I'm using SNMP (agent) and server but executing snmp agent (snmpwalk or snmpget) on centos,ubuntu system occurs that failure 'Bad operator (DEFINITIONS):'
Confirm if it a problem with your (manager-side) SNMP installation (rather than agent-side) by walking a host on the internet as described at https://stackoverflow.com/a/31615975/449347
If that fails maybe try reinstall your net-snmp.
I am running Centos 6.3 and attempting to use snmp v3 to query OID's on this server. Running Paessler's snmp tester 5.1.3 I get a no response from host. I have made sure that my iptables do not have any odd firewall settings. I can verify that snmpd is listening on port 161. I have also made sure that SELinux is fully disabled. I am able to install this on Centos 7.1 without any issue. I have done a tail on the messages in var/log/messages and can see incoming traffic for snmpd. I am stumped and have no idea why this will work on one version of this OS but not another. I wonder if anyone has any suggestions.
Thank you
I'm trying to use Putty 0.60 to log in to an OpenSSH 5.3 server. Connections with openssh from another Linux server are possible, but Putty fails. Putty's event log tells me "software caused connection abort" right after the DH key exchange, the server log doesn't report anything (set to INFO). I analyzed the traffic with Wireshark and got a whole bunch of "TCP retransmission" and "TCP DUP ACK" after said key exchange.
Sometimes I was able to log in, but at some point (usually < 2 min.) the connection froze without any logged messages. Sadly, I didn't capture a trace.
The server is my own (Funtoo with genkernel and gentoo-sources 2.6.34), so I may tweak it, but I'd still like to know what causes the error. Any suggestions? Thank you!
Ok, that was weird.
The problems cause was a network BIOS setting: a specified static IP and NIC = shared (Broadcom Extreme II) - system in question is a Dell Blade. By these settings, I somehow ended up with multiple MAC addresses for the IP - which killed my SSH connections. I honestly hope this helps somebody else...