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.