socket/connect: Invalid argument about microsocks HOT 19 CLOSED

can you provide the relevant snippets of strace -f output when this happens ?

from microsocks.

It seemed to only be on one of my VPS's but it works on others, thanks :)

from microsocks.

what's different on that one VPS compared to the others?

from microsocks.

There seems to be no difference
The one that is having issues is from servercheap.net
The ones that work are from ionos.com

from microsocks.

iirc those cheap VPS use openvz, which can be restricted in various ways (for example, may not create more than X processes or X threads etc). there's a command available that lists these (iirc it was vzctl something). would be interesting to compare the restrictions.

from microsocks.

@rofl0r

Hitting same on a cheap linode server. How to fix this?

from microsocks.

But sites seems works..

from microsocks.

@jeffRTC please provide strace -f output for when this happens

when you say "sites seems works", what doesn't work ?

from microsocks.

I'm getting socket/connect: Invalid argument errors. The errors only occur when I use the -b bindaddr option.

I was trying to bind outgoing connections to an IPv4 address to prevent the use of outbound IPv6.

So maybe this error (at least in my case) is due to an IPv4 versus IPv6 issue? Hmm.

I built from master.zip on Ubuntu 20.04.

Any advice would be appreciated.

from microsocks.

@parke can you show full commandline you use and strace -f microsocks ... log of a session exposing this behaviour ?

from microsocks.

The command that generates errors is:
./microsocks -i $private_ipv4 -p $port -b $public_ipv4

The command that succeeds is:
./microsocks -i $private_ipv4 -p $port

Both IPv4 addresses are of the form x.x.x.x (obviously).

$private_ipv4 is the address of a Wireguard interface.

I'll try to generate an strace log tomorrow.

from microsocks.

Here is a redacted portion of the strace log.

I as I suspected, microsocks is attempting to bind() an AF_INET6 socket to the IPv4 address I provided via -b. This results in EINVAL.

[pid 743635] socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 4
[pid 743635] bind(4, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("xx.xx.xx.xx")}, 16) = -1 EINVAL (Invalid argument)
[pid 743635] close(4)                   = 0
[pid 743635] write(2, "socket/connect: Invalid argument"..., 33socket/connect: Invalid argument
) = 33
[pid 743635] write(5, "\5\1\0\1\0\0\0\0\0\0", 10) = 10
[pid 743635] close(5)                   = 0
[pid 743635] madvise([snip], [snip], MADV_DONTNEED) = 0
[pid 743635] exit(0)                    = ?
[pid 743635] +++ exited with 0 +++

Does this provide you with enough information?

from microsocks.

Does this provide you with enough information?

thanks, this is useful. so what do you suggest how microsocks should behave in this case?
should it refrain from calling bind() at all when the -b parameter is an ipv4 address?
or would it be preferable to be able to specify multiple bind addresses, that are tried one after other ?
related: #40
it might be interesting to study what other mainstream server applications do in similar scenarios.

from microsocks.

I guess first I should ask, can I specify multiple -b bind addresses, or only one?

Ideally (from my perspective as a user), if one (or more?) -b bind address(es) is(are) specified, then microsocks would ignore any DNS records that were of a different type (IPv4 vs. IPv6) than the type of the specified -b bind address(es).

So, the call to resolve() here ...

https://github.com/rofl0r/microsocks/blob/master/sockssrv.c#L148

... needs to know the available -b address(es) (or at least the types of those address(es)), so that resolve() can decide which DNS records to skip, and which DNS record(s) to return.

(Or, alternatively, some filter after resolve() but before socket() needs to skip incompatible addresses.)

It seems pretty obvious to me that this is the best way to address (ha! ha!) this issue. But maybe I am missing something?

Let me know if you have more questions. I'm happy to offer more advice. If you twist my arm, I might be willing to try writing a patch myself. I don't think it would be that difficult to fix. Something somewhere needs to skip/reject DNS records that are incompatible with the -b bind address.

from microsocks.

I have realized that I failed to fully read and comprehend your questions before answering. Here are some additional answers.

thanks, this is useful. so what do you suggest how microsocks should behave in this case?
should it refrain from calling bind() at all when the -b parameter is an ipv4 address?

Yes. Ideally microsocks would only call bind() when the socket type and address type match.

More specifically: Ideally micosocks would ignore DNS records whose domain(?) type (i.e. IPv4 vs. IPv6) does not match the domain type of the -b bind address.

or would it be preferable to be able to specify multiple bind addresses,

Personally, I have no need at present for multiple bind addresses. Nor do I expect to need multiple bind addresses in the foreseeable future. I was only using -b in hopes forcing IPv4 connections (and never using IPv6 connections).

At the same time, I can imagine some users might find multiple -b addresses useful in certain situations. But I am not requesting multiple -b addresses.

from microsocks.

I guess first I should ask, can I specify multiple -b bind addresses, or only one?

To answer my own question, at present it appears that:

When multiple -b addresses are specified, each -b address will "overwrite" any previous -b address(es).

In other words: Only the last -b address will have any effect, and all previous -b addresses will be silently discarded/ignored.

from microsocks.

Related: pull request #50

from microsocks.

closed via 6ecc398

from microsocks.

Thanks.

Fyi, I recommend considering renaming the variable remote to something like addr_list. I think addr_list is a better description of how the variable is used. I tried to keep my patch small, so I did not make this change. If you want me to submit a PR with this renaming let me know.

from microsocks.