Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gen_tcp:connect/3 fails when addr in the SockAddr map is loopback #9541

Open
ptome opened this issue Mar 5, 2025 · 0 comments
Open

gen_tcp:connect/3 fails when addr in the SockAddr map is loopback #9541

ptome opened this issue Mar 5, 2025 · 0 comments
Assignees
Labels
bug Issue is reported as a bug team:PS Assigned to OTP team PS

Comments

@ptome
Copy link

ptome commented Mar 5, 2025

Describe the bug
gen_tcp:connect/3 fails when addr in the SockAddr map is loopback.

To Reproduce
Open a listening socket:

$ nc -vv -l -p 4321
listening on [any] 4321 ...

Open a TCP connection to loopback, from Erlang:

$ erl
Erlang/OTP 28 [RELEASE CANDIDATE 1] [erts-15.2.2] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] [jit:ns]

Eshell V15.2.2 (press Ctrl+G to abort, type help(). for help)
1> {ok, Sock} = gen_tcp:connect(#{family => inet, addr => loopback, port => 4321}, [binary, {packet, 0}]).
** exception exit: {function_clause,[{inet_tcp,do_connect,
                                               [#{port => 4321,addr => loopback,family => inet},
                                                [binary,{packet,0}],
                                                infinity],
                                               [{file,"inet_tcp.erl"},{line,119}]},
                                     {gen_tcp,connect,3,[{file,"gen_tcp.erl"},{line,464}]},
                                     {erl_eval,do_apply,7,[{file,"erl_eval.erl"},{line,922}]},
                                     {erl_eval,expr,6,[{file,"erl_eval.erl"},{line,666}]},
                                     {shell,exprs,7,[{file,"shell.erl"},{line,935}]},
                                     {shell,eval_exprs,7,[{file,"shell.erl"},{line,891}]},
                                     {shell,eval_loop,4,[{file,"shell.erl"},{line,876}]}]}
     in function  gen_tcp:connect/3 (gen_tcp.erl, line 469)
2> 

Expected behavior
gen_tcp:connect/3 should work with a sockaddr_in() when addr is loopback.

-type sockaddr_in() ::
          #{family := inet, port := port_number(), addr := any | broadcast | loopback | in_addr()}.

Affected versions
Tested on OTP 28 RC1, current master. Likely affects previous versions since 24.3 (commit 94e68e5).

Additional context
I was trying to understand if #5044 was solved by the OTP 24.3 change to gen_tcp:connect/3. I'm not sure if I'm doing something wrong, but I can't get it to work with loopback.

From the stack strace, inet_tcp:do_connect doesn't have a clause for the atoms. It only matches {A,B,C,D} tuples (IP address).

This is called from inet_tcp:connect after gen_tcp:connect2 in:

connect2(SockAddr, Opts0, Timer) ->
{Mod, Opts} = inet:tcp_module(Opts0, SockAddr),
Mod:connect(SockAddr, Opts, inet:timeout(Timer)).

I can solve the problem by calling inet:translate_ip/2 before Mod:connect in connect2, but I'm not sure if this is the correct way to fix it.

connect2(#{addr := Addr, family := Family} = SockAddr, Opts0, Timer) ->
    {Mod, Opts} = inet:tcp_module(Opts0, SockAddr),
    SockAddr2 = SockAddr#{addr := inet:translate_ip(Addr, Family)},
    Mod:connect(SockAddr2, Opts, inet:timeout(Timer)).

If it is a bug, I would like to work on a PR, including documentation and tests if needed. I may need some guidance on the correct way of fixing it.

@ptome ptome added the bug Issue is reported as a bug label Mar 5, 2025
@IngelaAndin IngelaAndin added the team:VM Assigned to OTP team VM label Mar 10, 2025
@rickard-green rickard-green added team:PS Assigned to OTP team PS and removed team:VM Assigned to OTP team VM labels Mar 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue is reported as a bug team:PS Assigned to OTP team PS
Projects
None yet
Development

No branches or pull requests

5 participants