socat udp via tcp tunneling not working as expected

[gdamich]

Please fill out the below information:

• Your Windows build number: (Type ver at a Windows Command Prompt)

Microsoft Windows [Version 10.0.17763.253]

• What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)

$ sudo socat -d -d -d -d -T15 -t5 udp4-recvfrom:161,reuseaddr,fork tcp:127.0.0.1:30033
2019/01/21 15:56:35 socat[5792] D getpid()
2019/01/21 15:56:35 socat[5792] D getpid() -> 5792
2019/01/21 15:56:35 socat[5792] D setenv("SOCAT_PID", "5792", 1)
2019/01/21 15:56:35 socat[5792] D setenv() -> 0
2019/01/21 15:56:35 socat[5792] D setenv("SOCAT_PPID", "5792", 1)
2019/01/21 15:56:35 socat[5792] D setenv() -> 0
2019/01/21 15:56:35 socat[5792] I socat by Gerhard Rieger - see www.dest-unreach.org
2019/01/21 15:56:35 socat[5792] I This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)
2019/01/21 15:56:35 socat[5792] I This product includes software written by Tim Hudson ([email protected])
2019/01/21 15:56:35 socat[5792] D socat version 1.7.3.1 on Feb 2 2016 21:25:06
2019/01/21 15:56:35 socat[5792] D setenv("SOCAT_VERSION", "1.7.3.1", 1)
2019/01/21 15:56:35 socat[5792] D setenv() -> 0
2019/01/21 15:56:35 socat[5792] D running on Linux version #253-Microsoft Mon Dec 31 17:49:00 PST 2018, release 4.4.0-17763-Microsoft, machine x86_64

2019/01/21 15:56:35 socat[5792] D argv[0]: "socat"
2019/01/21 15:56:35 socat[5792] D argv[1]: "-d"
2019/01/21 15:56:35 socat[5792] D argv[2]: "-d"
2019/01/21 15:56:35 socat[5792] D argv[3]: "-d"
2019/01/21 15:56:35 socat[5792] D argv[4]: "-d"
2019/01/21 15:56:35 socat[5792] D argv[5]: "-T15"
2019/01/21 15:56:35 socat[5792] D argv[6]: "-t5"
2019/01/21 15:56:35 socat[5792] D argv[7]: "udp4-recvfrom:161,reuseaddr,fork"
2019/01/21 15:56:35 socat[5792] D argv[8]: "tcp:127.0.0.1:30033"
2019/01/21 15:56:35 socat[5792] D sigaction(1, 0x7fffc91329f0, 0x0)
2019/01/21 15:56:35 socat[5792] D sigaction() -> 0
2019/01/21 15:56:35 socat[5792] D sigaction(2, 0x7fffc91329f0, 0x0)
2019/01/21 15:56:35 socat[5792] D sigaction() -> 0
2019/01/21 15:56:35 socat[5792] D sigaction(3, 0x7fffc91329f0, 0x0)
2019/01/21 15:56:35 socat[5792] D sigaction() -> 0
2019/01/21 15:56:35 socat[5792] D sigaction(4, 0x7fffc91329f0, 0x0)
2019/01/21 15:56:35 socat[5792] D sigaction() -> 0
2019/01/21 15:56:35 socat[5792] D sigaction(6, 0x7fffc91329f0, 0x0)
2019/01/21 15:56:35 socat[5792] D sigaction() -> 0
2019/01/21 15:56:35 socat[5792] D sigaction(7, 0x7fffc91329f0, 0x0)
2019/01/21 15:56:35 socat[5792] D sigaction() -> 0
2019/01/21 15:56:35 socat[5792] D sigaction(8, 0x7fffc91329f0, 0x0)
2019/01/21 15:56:35 socat[5792] D sigaction() -> 0
2019/01/21 15:56:35 socat[5792] D sigaction(11, 0x7fffc91329f0, 0x0)
2019/01/21 15:56:35 socat[5792] D sigaction() -> 0
2019/01/21 15:56:35 socat[5792] D sigaction(15, 0x7fffc91329f0, 0x0)
2019/01/21 15:56:35 socat[5792] D sigaction() -> 0
2019/01/21 15:56:35 socat[5792] D signal(13, 0x1)
2019/01/21 15:56:35 socat[5792] D signal() -> 0x0
2019/01/21 15:56:35 socat[5792] D atexit(0x4066e0)
2019/01/21 15:56:35 socat[5792] D atexit() -> 0
2019/01/21 15:56:35 socat[5792] D calloc(1, 848)
2019/01/21 15:56:35 socat[5792] D calloc() -> 0xc50240
2019/01/21 15:56:35 socat[5792] D malloc(1024)
2019/01/21 15:56:35 socat[5792] D malloc() -> 0xc505c0
2019/01/21 15:56:35 socat[5792] I setting option "so-reuseaddr" to 1
2019/01/21 15:56:35 socat[5792] I setting option "fork" to 1
2019/01/21 15:56:35 socat[5792] D socket(2, 2, 17)
2019/01/21 15:56:35 socat[5792] I socket(2, 2, 17) -> 5
2019/01/21 15:56:35 socat[5792] D fcntl(5, 2, 1)
2019/01/21 15:56:35 socat[5792] D fcntl() -> 0
2019/01/21 15:56:35 socat[5792] D setsockopt(5, 1, 2, {0x1}, 4)
2019/01/21 15:56:35 socat[5792] D setsockopt() -> 0
2019/01/21 15:56:35 socat[5792] D bind(5, AF=2 0.0.0.0:161, 16)
2019/01/21 15:56:35 socat[5792] D bind() -> 0
2019/01/21 15:56:35 socat[5792] I starting recvfrom loop
2019/01/21 15:56:35 socat[5792] D sigaction(10, 0x7fffc9131df0, 0x0)
2019/01/21 15:56:35 socat[5792] D sigaction() -> 0
2019/01/21 15:56:35 socat[5792] D sigaction(17, 0x7fffc9131df0, 0x0)
2019/01/21 15:56:35 socat[5792] D sigaction() -> 0
2019/01/21 15:56:35 socat[5792] N receiving on AF=2 0.0.0.0:161
2019/01/21 15:56:35 socat[5792] D select(6, &0x20, &0x0, &0x0, NULL/0.000000)
2019/01/21 15:57:12 socat[5792] D select -> (, 0x20, 0x0, 0x0, NULL/0.000000), 1
2019/01/21 15:57:12 socat[5792] D recvmsg(5, 0x7fffc9131cd0{0x7fffc9131d10,112,0x7fffc9131c70,1,0x7fffc9132390,1024,0}, 34)
2019/01/21 15:57:12 socat[5792] D recvmsg(, {AF=2 0.0.0.0:0,112,,1,,1024,}, ) -> -1
2019/01/21 15:57:12 socat[5792] W recvmsg(): Invalid argument
2019/01/21 15:57:12 socat[5792] N exiting with status -1
2019/01/21 15:57:12 socat[5792] D exit(-1)
2019/01/21 15:57:12 socat[5792] D starting xioexit()
2019/01/21 15:57:12 socat[5792] D finished xioexit()

• What's wrong / what should be happening instead:

It should listen UDP snmp requests on 161 and tunnel it via ssh tcp to remote machine

• Strace of the failing command, if applicable: (If some_command is failing, then run strace -o some_command.strace -f some_command some_args, and link the contents of some_command.strace in a gist here).

Not applicable

• For WSL launch issues, please collect detailed logs.

Not applicable

[therealkenc]

Cannot repro here on 18317 and socat 1.7.3.2.

Not applicable

How you figure. You've got an EINVAL on recvmsg() for some reason.

[gdamich]

Cannot repro here on 18317 and socat 1.7.3.2.

Not applicable

How you figure. You've got an EINVAL on recvmsg() for some reason.

Not applicable to strace? Never use it before, but if I follow the command template it does return nothing.

Yes. Do not know the internals (neither do want to know), but as I get it, it has something with nature of snmp.
My another attempt was nc on the local machine. Read somewhere on SO: "I couldn't get nc to work for SNMP, because SNMP clients keep choosing a new source UDP port, and several can be active at once." (not sure if I can reference to SO here)

I tried with "nc" and "fifo", and when there is only one snmpget it went through, but for another one, it kills an existing process (sorry for vague description).

local# mkfifo /tmp/fifo
local# sudo nc -l -u -p 161 < /tmp/fifo | nc localhost 30333 > /tmp/fifo

on another end of the tunnel, I used socat (so my success for one snmp get was fifo local, and socat remote)

Ill today getup vm (debian stretch) so will verbose socat on that one for comparison.

UPDATE:
straces gist (hope this helps, sorry for not sending straces before):
https://gist.github.com/gdamich/b5c2e50853aa9acb786b7cb8d38325d5
https://gist.github.com/gdamich/7d3b553fd89c99f0f5b0cdfcb3b5ce0c

UPDATE2:
When I change udp4-recvfrom to udp4-listen snmp get goes through if I wait for few seconds between firing those, if not its timeout...
From SO: "You should try udp-listen instead of udp-recvfrom. udp-recvfrom will create a new TCP connection for each of the UDP packets. I've had similar problems with UDP tunnelling through an SSH PuTTy connection and for me, UDP-LISTEN did the trick."

[gdamich]

Why did you close it?

[therealkenc]

The line in your OP doesn't reproduce. The first strace(1) log you linked contains no EINVAL. It isn't threaded (-f) which might be why it is missing, but would be academic because the OP doesn't reproduce. Then you switched gears to /usr/bin/snmpget and something about something you read on SO, and hope of making it to a WSL actionable became slim enough to close.

[gdamich]

Fair enough. I was merely hoping that it will give you hints about a potential issue based on you knowing internals.
I do not have a new Windows insider build, so I'll wait for it. Meanwhile will move back to the VMs.
Thx

[therealkenc]

Tell you what it has only been a couple of days and agree it was a quick close. I'll leave it open for the customary couple of weeks and maybe there will be some community input.