"u.peer.connection.ssl is nil" after a successful sslhandshake on ARMv7

[Evengard]

Hello!

I am trying to get the server certificate from a tcp socket.
I do (roughly):

local openssl = require("resty.openssl");
openssl.load_modules();
local serv = ngx.socket.tcp();
local ok, err=serv:connect(dest_addr, dest_port);
local session, err = serv:sslhandshake(nil, "example.com");
local sslsess, err = openssl.ssl.from_socket(serv);
local cert = sslsess:get_peer_certificate();

And at the last stage I am getting "u.peer.connection.ssl is nil" and sslsess is actually nil. I've checked all the other errors - and there are no errors before the "from_socket" call. What am I doing wrong?

[Evengard]

It works fine when using the auxiliary module (which is an acceptable workaround), but without it the bug is present.

[fffonion]

Hi, which version of openresty/nginx version are you using?

--

Regards fffonion (B607 2745 84E8 D5E5 <https://yooooo.us/gpg.txt>)

[Evengard]

I'm using openresty source code tarball 1.19.3.1 compiled on an ARMv7 armel platform (not ARM64).

[fffonion]

@Evengard I see, that's probably the reason, the FFI magic to get u.peer.connection.ssl is hacky and based on offset calculated by given struct, so it might get wrong in different arch. Right now we don't have arm based CI running, so I would strongly suggest to use the aux C module (actually even so if you are using x86/x64). I will try to test it on my raspeberry pi just to see what goes wrong.

[Evengard]

That's actually my current solution I'm using which works fine.

[fffonion]

@Evengard This is now fixed and will be included in next release. Turns out Nginx always sets _FILE_OFFSET_BITS to 64
and that changes the size of off_t on 32bit arch.

[Evengard]

Wow, that's one tricky bug... Thank you for the fix!