org.bouncycastle.tls.TlsFatalAlert: internal_error(80)
when I run jitsi-meet on debian12 system, the dtls negotiation failed . is there any tool to check the cause of the error?
openssl version
OpenSSL 3.0.15 3 Sep 2024 (Library: OpenSSL 3.0.15 3 Sep 2024)
JVB 2024-12-31 09:27:32.455 SEVERE: [107] [confId=7385f3f5c75d0150 [email protected] meeting_id=764f6f8e epId=431019ef stats_id=Kenya-QG5 local_ufrag=cdaam1igehqn00] IceTransport.send#272: Error sending packet java.io.IOException: No socket found to send on. at org.ice4j.ice.Component.send(Component.java:1227) at org.jitsi.videobridge.transport.ice.IceTransport.send(IceTransport.kt:269) at org.jitsi.videobridge.Endpoint$setupDtlsTransport$2.sendData(Endpoint.kt:461) at org.jitsi.videobridge.transport.dtls.DtlsTransport$dtlsStack$1$2.sendData(DtlsTransport.kt:106) at org.jitsi.nlj.dtls.DtlsStack$DatagramTransportImpl.send(DtlsStack.kt:291) at org.bouncycastle.tls.DTLSRecordLayer.sendDatagram(Unknown Source) at org.bouncycastle.tls.DTLSRecordLayer.sendRecord(Unknown Source) at org.bouncycastle.tls.DTLSRecordLayer.raiseAlert(Unknown Source) at org.bouncycastle.tls.DTLSRecordLayer.fail(Unknown Source) at org.bouncycastle.tls.DTLSServerProtocol.abortServerHandshake(Unknown Source) at org.bouncycastle.tls.DTLSServerProtocol.accept(Unknown Source) at org.bouncycastle.tls.DTLSServerProtocol.accept(Unknown Source) at org.jitsi.nlj.dtls.DtlsServer.accept(DtlsServer.kt:45) at org.jitsi.nlj.dtls.DtlsServer.start(DtlsServer.kt:41) at org.jitsi.nlj.dtls.DtlsStack.start(DtlsStack.kt:151) at org.jitsi.videobridge.transport.dtls.DtlsTransport.startDtlsHandshake(DtlsTransport.kt:137) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) JVB 2024-12-31 09:27:32.456 SEVERE: [107] [confId=7385f3f5c75d0150 [email protected] meeting_id=764f6f8e epId=431019ef stats_id=Kenya-QG5] DtlsServer.accept#64: Error during DTLS connection: org.bouncycastle.tls.TlsFatalAlert: internal_error(80) JVB 2024-12-31 09:27:32.456 SEVERE: [107] [confId=7385f3f5c75d0150 [email protected] meeting_id=764f6f8e epId=431019ef stats_id=Kenya-QG5] DtlsTransport.startDtlsHandshake#140: Error during DTLS negotiation, closing this transport manager org.bouncycastle.tls.TlsFatalAlert: internal_error(80) at org.bouncycastle.tls.DTLSServerProtocol.accept(Unknown Source) at org.bouncycastle.tls.DTLSServerProtocol.accept(Unknown Source) at org.jitsi.nlj.dtls.DtlsServer.accept(DtlsServer.kt:45) at org.jitsi.nlj.dtls.DtlsServer.start(DtlsServer.kt:41) at org.jitsi.nlj.dtls.DtlsStack.start(DtlsStack.kt:151) at org.jitsi.videobridge.transport.dtls.DtlsTransport.startDtlsHandshake(DtlsTransport.kt:137) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: java.lang.RuntimeException at org.jitsi.videobridge.transport.ice.IceTransport.send(IceTransport.kt:273) at org.jitsi.videobridge.Endpoint$setupDtlsTransport$2.sendData(Endpoint.kt:461) at org.jitsi.videobridge.transport.dtls.DtlsTransport$dtlsStack$1$2.sendData(DtlsTransport.kt:106) at org.jitsi.nlj.dtls.DtlsStack$DatagramTransportImpl.send(DtlsStack.kt:291) at org.bouncycastle.tls.DTLSRecordLayer.sendDatagram(Unknown Source) at org.bouncycastle.tls.DTLSRecordLayer.sendRecord(Unknown Source) at org.bouncycastle.tls.DTLSRecordLayer.send(Unknown Source) at org.bouncycastle.tls.DTLSReliableHandshake$RecordLayerBuffer.sendToRecordLayer(Unknown Source) at org.bouncycastle.tls.DTLSReliableHandshake.writeHandshakeFragment(Unknown Source) at org.bouncycastle.tls.DTLSReliableHandshake.writeMessage(Unknown Source) at org.bouncycastle.tls.DTLSReliableHandshake.sendMessage(Unknown Source) at org.bouncycastle.tls.DTLSServerProtocol.serverHandshake(Unknown Source) ... 9 more
For a large number of TLS errors the peer will simply close its connection and that is likely what this stack trace reflects, although it's hard to be certain. I am a bit curious what version of BC jars this is using too, since DTLSRecordLayer.fail would be expected to catch and ignore an IOException generated while trying to deliver a fatal alert.
For a large number of TLS errors the peer will simply close its connection and that is likely what this stack trace reflects, although it's hard to be certain. I am a bit curious what version of BC jars this is using too, since DTLSRecordLayer.fail would be expected to catch and ignore an IOException generated while trying to deliver a fatal alert.
version info in pom.xml: <bouncycastle.version>1.78.1</bouncycastle.version>
Hi, have you been able to solve this problem? I've been experiencing the same issue for several days.