• Cryptlib "internal consistency check" failures cause SSH and TLS conne

    From Rob Swindell@1:103/705 to GitLab issue in main/sbbs on Wed Nov 3 18:27:14 2021
    open https://gitlab.synchro.net/main/sbbs/-/issues/302

    /var/log/sbbs.log.1:Oct 28 13:03:53 cvs sbbs: term 1296 SSH note 'Internal consistency check failed' (-16) setting session active from bbs_thread/var/log/sbbs.log.1:Oct 28 13:04:27 cvs sbbs: mail 1311 SMTPS note 'Internal consistency check failed' (-16) setting session active/var/log/sbbs.log.1:Oct 28 13:05:36 cvs sbbs: web 1339 TLS note 'Internal consistency check failed' (-16) setting session activeWork-around: restarting sbbs allows the connections to start working again.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Sun Nov 7 23:16:36 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/302#note_2133

    I wonder if this is related to the certificate expiring when using LetSyncrypt. It's possible on a busy system for the certificate to never be reloaded.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Sun Nov 7 23:26:48 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/302#note_2134

    Added code to reload the certificate if the file time changes. Not sure if it will do anything for *this* problem, it it should do something for some problem.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Mon Nov 15 10:30:56 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/302#note_2150

    With the latest code change to reload the cert, problem still happens after a while:Nov 15 10:29:12 cvs sbbs: web 1062 TLS note 'Internal consistency check failed' (-16) setting session active
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Mon Nov 15 10:32:02 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/302#note_2151

    Recycling sbbs enables TLS to start working again.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Tue Dec 7 12:37:30 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/302#note_2159

    Likely fixed (for non-Windows platforms and socket descriptor values > 1024) with Deuce's commit fd214111dc767858264bffec7886c7680dd7cf95.
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Wed Dec 8 09:42:40 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/302#note_2162

    Unfortunately, with this latest change, now getting these errors (and no HTTPS connections working) when the socket descriptor value is > 1024:Dec 8 09:40:48 cvs sbbs: web 1335 TLS dbg 'No data was read because the remote system closed the connection (recv() == 0)' (-41) setting session activeDec 8 09:40:49 cvs sbbs: web 1336 TLS dbg 'No data was read because the remote system closed the connection (recv() == 0)' (-41) setting session activeDec 8 09:40:49 cvs sbbs: web 1340 TLS dbg 'No data was read because the remote system closed the connection (recv() == 0)' (-41) setting session activeDec 8 09:40:51 cvs sbbs: web 1338 TLS dbg 'No data was read because the remote system closed the connection (recv() == 0)' (-41) setting session activeDec 8 09:40:52 cvs sbbs: web 1339 TLS dbg 'No data was read because the remote system closed the connection (recv() == 0)' (-41) setting session activeDec 8 09:40:53 cvs sbbs: web 1341 TLS dbg 'No data was read because the remote system closed the connection (recv() == 0)' (-41) setting session activeDec 8 09:40:55 cvs sbbs: web 1342 TLS dbg 'No data was read because the remote system closed the connection (recv() == 0)' (-41) setting session activeDec 8 09:40:58 cvs sbbs: web 1343 TLS dbg 'No data was read because the remote system closed the connection (recv() == 0)' (-41) setting session active
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Deucе@1:103/705 to GitLab note in main/sbbs on Tue Dec 14 14:20:08 2021
    https://gitlab.synchro.net/main/sbbs/-/issues/302#note_2173

    May be resolved by commit 3adb964d
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab note in main/sbbs on Thu Feb 3 20:04:20 2022
    https://gitlab.synchro.net/main/sbbs/-/issues/302#note_2253

    Still seeing this error on occasion, but not nearly at the previous rate and it doesn't appear to be fatal (and the socket descriptor is not >=1024):```/var/log/sbbs.log:Feb 1 17:16:31 cvs sbbs: web 0166 TLS note 'Internal consistency check failed' (-16) setting session active/var/log/sbbs.log.1:Jan 27 20:57:23 cvs sbbs: web 0115 TLS note 'Internal consistency check failed' (-16) setting session active/var/log/sbbs.log.1:Jan 28 11:44:51 cvs sbbs: mail 0163 SEND/TLS [mail.eternet.cc] note 'Internal consistency check failed' (-16) setting session active/var/log/sbbs.log.10:Jan 28 09:56:21 cvs sbbs: web 0047 TLS note 'Internal consistency check failed' (-16) setting session active/var/log/sbbs.log.11:Jan 18 16:46:22 cvs sbbs: mail 0139 SEND/TLS [mail.protectivesupplyplus.com] note 'Internal consistency check failed' (-16) setting session active```... so closing the issue. Thank you!
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell@1:103/705 to GitLab issue in main/sbbs on Thu Feb 3 20:04:22 2022
    close https://gitlab.synchro.net/main/sbbs/-/issues/302
    --- SBBSecho 3.14-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)