Thank you for the quick update
Hi Frank ,
The issue is still observed with SNMP4J 2.8.11 SNAPSHOT .And this is mostly observed when the agent closes the connection during initial connection request in invalid case .
One of the scenario which we captured this log is the Client has TLSv1.2 and agent restricted TLS min to 1.3.
IP ending with 82 is the client and the one ending with 60 is the agent .
SNMP4J logs
SSL context initializing with TrustManagers: [org.bouncycastle.jsse.provider.ExportX509TrustManager_7@5e905f2c] and factory org.snmp4j.transport.TLSTM$DefaultTLSTMTrustManagerFactory
Configuring SSL engine, supported protocols are [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, SSLv3], supported ciphers are [TLS_AES_128_CCM_8_SHA256, …(values)…], https defaults are null
Configured SSL engine, enabled protocols are [TLSv1.2], enabled ciphers are [TLS_CHACHA20_POLY1305_SHA256, …(values)…]
Trying to connect to 10.20.219.60/10161
Adding operation 8 for: SocketEntry[peerAddress=10.20.219.60/10161,socket=Socket[unconnected],lastUse=Wed Feb 11 23:57:55 EST 1970,inNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],inAppBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],outNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],socketTimeout=null]
Key is connectable
Connected to 10.20.219.60/10161
Adding operation 4 for: SocketEntry[peerAddress=10.20.219.60/10161,socket=Socket[addr=10.20.219.60/10.20.219.60,port=10161,localport=57112],lastUse=Wed Feb 11 23:57:55 EST 1970,inNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],inAppBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],outNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],socketTimeout=null]
Fire connected event for 10.20.219.60/10161
Firing transport state event: org.snmp4j.transport.TransportStateEvent[source=org.snmp4j.transport.TLSTM@485e2a67,peerAddress=10.20.219.60/10161,newState=1,cancelled=false,causingException=null]
TLS state change org.snmp4j.transport.TransportStateEvent[source=org.snmp4j.transport.TLSTM@485e2a67,peerAddress=10.20.219.60/10161,newState=1,cancelled=false,causingException=null]
Key is writable
Sending message with length 69 to 10.20.219.60/10161: 30:43:02:01:03:30:11:02:04:3c:4b:ac:e0:02:03:00:80:00:04:01:04:02:01:04:04:00:30:29:04:05:80:00:00:00:06:04:00:a0:1e:02:04:0e:89:60:1a:02:01:00:02:01:00:30:10:30:0e:06:0a:2b:06:01:06:03:0a:02:01:01:00:05:00
Writing TLS outNetBuffer(PAYLOAD): java.nio.HeapByteBuffer[pos=0 lim=205 cap=32768]
Wrote TLS 205 bytes from outNetBuffer(PAYLOAD)
Nothing to write to network, removing write key
Message sent for SocketEntry[peerAddress=10.20.219.60/10161,socket=Socket[addr=10.20.219.60/10.20.219.60,port=10161,localport=57112],lastUse=Wed Feb 11 23:57:55 EST 1970,inNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],inAppBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],outNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],socketTimeout=null]
Adding operation 1 for: SocketEntry[peerAddress=10.20.219.60/10161,socket=Socket[addr=10.20.219.60/10.20.219.60,port=10161,localport=57112],lastUse=Wed Feb 11 23:57:55 EST 1970,inNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],inAppBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],outNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],socketTimeout=null]
Idle socket entry removed from pending message queue: SocketEntry[peerAddress=10.20.219.60/10161,socket=Socket[addr=10.20.219.60/10.20.219.60,port=10161,localport=57112],lastUse=Wed Feb 11 23:57:55 EST 1970,inNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],inAppBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],outNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],socketTimeout=null]
Key is readable
Key is reading
Read 7 bytes from 10.20.219.60/10161
TLS inNetBuffer: java.nio.HeapByteBuffer[pos=7 lim=32768 cap=32768]
Running delegated task on SocketEntry[peerAddress=10.20.219.60/10161,socket=Socket[addr=10.20.219.60/10.20.219.60,port=10161,localport=57112],lastUse=Wed Feb 11 23:58:05 EST 1970,inNetBuffer=java.nio.HeapByteBuffer[pos=7 lim=7 cap=32768],inAppBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],outNetBuffer=java.nio.HeapByteBuffer[pos=0 lim=32768 cap=32768],socketTimeout=null]: Status = OK HandshakeStatus = NEED_WRAP
bytesConsumed = 0 bytesProduced = 0
Key is readable
Key is reading
Read 0 bytes from 10.20.219.60/10161
TLS inNetBuffer: java.nio.HeapByteBuffer[pos=7 lim=7 cap=32768]
Key is readable
Key is reading
Read 0 bytes from 10.20.219.60/10161
TLS inNetBuffer: java.nio.HeapByteBuffer[pos=7 lim=7 cap=32768]
Key is readable
Key is reading
Read 0 bytes from 10.20.219.60/10161
TLS inNetBuffer: java.nio.HeapByteBuffer[pos=7 lim=7 cap=32768]
Key is readable
Key is reading
Read 0 bytes from 10.20.219.60/10161
TLS inNetBuffer: java.nio.HeapByteBuffer[pos=7 lim=7 cap=32768]
Key is readable
The looping issue remains the same even in case of 2.8.11 https://snmp.app/dist/release/org/snmp4j/snmp4j/2.8.11/snmp4j-2.8.11-distribution.zip
The issue is always reproducible in the above mentioned specified scenario .
Hi,
I think this is an error of the SslEngine. The status of NEED_WRAP while not generating any net bytes cannot be better handled by the SNMP4J API. if there is not protocol acceptable by the server, the server should terminate the connection. Alternatively, the client, But for that, the client need an error report from the server. Thus, during handshaking, the client needs to keep the read key.
The only question is why the NIO selector indicates data to be received. Maybe there is a wake-up call that needs to be removed to improve that. But then the behavior would be still not as it should be.
Best regards,
Frank
OK, wakeup was not the problem.
As indicated initially in my reply on this thread: https://forum.snmp.app/t/snmp4j-over-tls-stuck-at-key-is-writable/732/5:
With TLS v1.3 half closed sessions are possible. In your case, the TLS v1.3 agent seems to be closing the outbound channel causing the inbound of the TLS v1.2 client to be “done”.
SNMP4J 2.8.11/3.6.7 and earlier do not detect that state and still try to read from that “done” inbound channel, because handshake is not finished yet. In later JREs SslEngine is handling this differently and this this issue cannot be observed there.
Instead of keeping outbound open, SNMP4J should send a CLOSE PDU and then close channels and remove the socket entry, from the connection pool.
These changes are included in the latest 2.8.12 snapshot:
https://snmp.app/dist/snapshot/org/snmp4j/snmp4j/2.8.12-SNAPSHOT/snmp4j-2.8.12-20220502.211854-2.jar
Hi Frank ,
The issue w.r.t looping during Client with TLS v1.2 and S agent with TLSv1.3 is fixed with the latest snapshot which you have provided.
https://snmp.app/dist/snapshot/org/snmp4j/snmp4j/2.8.12-SNAPSHOT/snmp4j-2.8.12-20220502.211854-2.jar
Thank you for the support . Can you please let us know when can we expect the official load of snp4j 2.8.12 ?
SNMP4J 2.8.12 and 3.7.0 will be available on 2022-05-08T22:00:00Z
1 Like