Closed robertwayne closed 1 month ago
Hey, sorry this kinda flew under my radar for a little bit.
This should be fixed on the master branch, I will be doing a (major) release soon.
It's a slightly different access, where you'll need to call glisten.get_client_info(connection)
to get it, but it should now be "correct". I'm putting this in quotes because I did my best to make sure it's the correct version, but I might have missed something.
If you're able to test this, I would love to know if it resolves the issue :)
I think fixed in v4.0.0
. Let me know if it doesn't work!
From out brief Discord convo, I figured I'd open an issue.
The
client_ip
onconnection
is (sometimes? always?) returning an unexpected type.ClientIp
is defined aspub type ClientIp = Result(#(#(Int, Int, Int, Int), Int), Nil)
. So, we expect a tuple of 4Int
's but I am receiving a tuple of 8Int
's.Reproduction
Given a basic TCP server:
Running
ncat -4 127.0.0.1 3000
gives a debug output of#(#(0, 0, 0, 0, 0, 65535, 32512, 1), 58988)
, which is incorrect. Specifically, this is 8 u16's representing an IpV6, when we want 4 u8's for an IpV4.From digging, this looks like there just needs to be some check after calling the erlang
inet.peername
function to ensure the correctly sized values are being shoved into the connection state.