Jeff Bogatay <[email protected]> writes: > At some point last night, the connection dropped. (Not sure why). The > drive was still mounted, but dead. > > Umounted the drive, tried to remount, was corrupt requiring a fsck. > > Same error on fsck (OSError: [Errno 14] Bad address). > > I ran wireshark and it gets an Encrypted Alert 21 just before it dies. > > I have a wireshark capture of the end activity (after the "Checking > Objects" part). If it would be helpful I will gladly sent it to you > offline.
Thanks for the traffic dump. The remote server sends you a TLS alert code with code 21 and (probably in response to that) S3QL (or more precisely OpenSSL) resets the TCP connection. Errorcode 21 means "Decryption failed", i.e. the server was unable to decrypt a message from the client. I'm not well versed in TLS, but I believe resetting the connection is the proper thing to do in this situation. However, it seems that OpenSSL isn't coping well with this, thus the "Bad Address" error that it signals to S3QL. Which OpenSSL version are you using? Could you be affected by https://github.com/excon/excon/issues/467? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- You received this message because you are subscribed to the Google Groups "s3ql" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
