Problem with UDP transparent mode

[chrissyan0]

Hello,
Thank you for providing shapeshifter.
It seems that with the current build UDP mode is not transparent at all:
Running the server:
./shapeshifter-dispatcher -transparent -udp -server -state state-server -orport 127.0.0.1:11940 -transports obfs2 -bindaddr obfs2-0.0.0.0:441
and the client (same machine):
./shapeshifter-dispatcher -transparent -udp -client -state state -transports obfs2 -target 10.1.1.130:441 -proxylistenaddr 127.0.0.1:11941
# nc -u 127.0.0.1 11941
1234
56789
(nc still open)
results in
root@pi4a:/home/pi/go/bin # nc -u -l -p 11940
56789
root@pi4a:/home/pi/go/bin #
(connection broken)
shapeshifter-dispatcher client output:

@@@ Listening obfs2 127.0.0.1:11941
@@@ handling...
Transport is obfs2
Received 1234
from 127.0.0.1:38638
map[]
Opening connection to 10.1.1.130:441
Making dialer...
recv: Open
Dialing....
Dialing 10.1.1.130:441
Success
Received 56789
from 127.0.0.1:38638
map[127.0.0.1:38638:{0x1916200 false}]
recv: write
writing...
6
[6 0]

shapeshifter-dispatcher server output:

ServerSetup
bindaddr {obfs2 0.0.0.0:441 map[]}
accepted
### handling obfs2
pumping
reading...
2
reading data
reading...
2
reading data
reading...
2
reading data
reading...
2

(and so on until connection breaks)
Same happens with obfs4.

go version 1.11.6 @ raspbian buster

Kind regards,
Chris

[vanohaker]

I confirm. I have the same problem with obfs4.
Client

./shapeshifter-dispatcher -transparent -udp -client -state state -target 45.xx.xx.50:443 -transports obfs4 -proxylistenaddr 127.0.0.1:1443 -options '{"cert": "****************************************************************************************", "iat-mode": "0"}' -logLevel DEBUG -enableLogging
map[]
Dialing....
Dialing  45.76.91.50:443
Success
map[127.0.0.1:39022:{0x1d9e040 false}]
writing data to server
2
writing data to server
148
map[127.0.0.1:39022:{0x1d9e040 false}]
writing data to server
2
writing data to server
148
^C

tcpdump

sudo tcpdump -i lo -nn dst port 1443 or src port 1443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
09:38:03.898295 IP 127.0.0.1.39022 > 127.0.0.1.1443: UDP, length 148
09:38:09.098255 IP 127.0.0.1.39022 > 127.0.0.1.1443: UDP, length 148
09:38:14.298246 IP 127.0.0.1.39022 > 127.0.0.1.1443: UDP, length 148
09:38:19.498196 IP 127.0.0.1.39022 > 127.0.0.1.1443: UDP, length 148
09:38:24.698169 IP 127.0.0.1.39022 > 127.0.0.1.1443: UDP, length 148
09:38:29.898195 IP 127.0.0.1.39022 > 127.0.0.1.1443: UDP, length 148
09:38:35.098227 IP 127.0.0.1.39022 > 127.0.0.1.1443: UDP, length 148
09:38:40.138153 IP 127.0.0.1.39022 > 127.0.0.1.1443: UDP, length 148
09:38:45.498213 IP 127.0.0.1.39022 > 127.0.0.1.1443: UDP, length 148

go version go1.15.2 linux/arm
raspbian 10 buster

Server

./shapeshifter-dispatcher -transparent -udp -server -state state -orport 127.0.0.1:51820 -transports obfs4 -bindaddr obfs4-45.xx.xx.50:443 -logLevel DEBUG -enableLogging
accepted
### handling obfs4
pumping
reading...
2
reading data
148
reading...
2
reading data
148
reading...
^C

tcpdump

tcpdump -i lo -nn dst port 51820 or src port 51820
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lo, link-type EN10MB (Ethernet), capture size 262144 bytes
06:23:35.520963 IP 127.0.0.1.52300 > 127.0.0.1.51820: UDP, length 148
06:23:35.521600 IP 127.0.0.1.51820 > 127.0.0.1.52300: UDP, length 92
06:23:40.720640 IP 127.0.0.1.52300 > 127.0.0.1.51820: UDP, length 148
06:23:40.721381 IP 127.0.0.1.51820 > 127.0.0.1.52300: UDP, length 92
06:23:45.920922 IP 127.0.0.1.52300 > 127.0.0.1.51820: UDP, length 148
06:23:45.921994 IP 127.0.0.1.51820 > 127.0.0.1.52300: UDP, length 92
06:23:51.121032 IP 127.0.0.1.52300 > 127.0.0.1.51820: UDP, length 148

go version go1.15.2 linux/amd64
Ubuntu 20.04.1 LTS

[HugoFlorentino]

Actually after compiling the project with latest golang, when starting the server, even if I specifically use the options -transparent -udp, when I check with ss -plunt the socket is listening using TCP. Sounds like a bug.