Snmp4j 2.6.3jar for snmpv3 and TCP

We have application which uses snmp4j 2.6.3jar for snmpv3 and TCP integration
Application listnes on port 10118

Our application able to porcess snmp traps from socket connection for source port 14621 but not other socket connections i.e for source port 43970,50762,54771

we have cross checked tcpdump and we see traps are recived from other source ports sockets i.e 43970,50762,54771 are valid and there is no issue in trap format

We see our application listens on port 10118 and connections are established for all source ports . Below is o/p of netstat on port 10118 when application is running

Let us know way to troubleshoot this issue further

netstat -anp | grep 10118
tcp 0 0 x.x.76.50:10118 0.0.0.0:* LISTEN 1578617/java
tcp 0 0 x.x.76.50:10118 x.x.199.168:43970 TIME_WAIT -
tcp 0 0 x.x.76.50:10118 x.x.199.168:14621 ESTABLISHED 1578617/java
tcp 0 0 x.x.76.50:10118 x.x.199.168:50762 ESTABLISHED 1578617/java
tcp 0 0 x.x.76.50:10118 x.x.199.168:54771 ESTABLISHED 1578617/java

Most likely, there is an issue with the SNMPv3 authentication or privacy because for the sender agents for which no traps are processed there are no localized auth or priv pass keys stored in the USM.
You will find more information in the DEBUG log.

We are able see all traps are getting encoded using same SNMPV3 credentials in Wireshark. there is no messages are written in DEBUG level in application logs

Then these traps are not received by SNMP4J. Are ports correctly specified?

SNMP4J application is configured to listen on 10118 port and able to process traps from one tcp connection i.e (tcp 0 0 x.x.76.50:10118 x.x.199.168:14621 ESTABLISHED 1578617/java) but not from other connections. Below is netstat o/p

Do you suspect still its network or firewall issue ? since our application is shows as connection established in netstat o/p

or using latest snmp4j jar will resolve issue ?. Since we are using snmp4j 2.6.3jar

netstat -anp | grep 10118
tcp 0 0 x.x.76.50:10118 0.0.0.0:* LISTEN 1578617/java
tcp 0 0 x.x.76.50:10118 x.x.199.168:3970 TIME_WAIT -
tcp 0 0 x.x.76.50:10118 x.x.199.168:14621 ESTABLISHED 1578617/java
tcp 0 0 x.x.76.50:10118 x.x.199.168:50762 ESTABLISHED 1578617/java
tcp 0 0 x.x.76.50:10118 x.x.199.168:54771 ESTABLISHED 1578617/java

So again, you see the connection established on OS level, but do not see any output in the DEBUG log of SNMP4J related to these connections?

This cannot be the case, from my point of view.

What I have seen in the past, are half-closed connections, where one peer did not recognise the closing of the inbound or outbound direction. Sometimes firewalls are closing connections this way if they run out of memory, for example.