UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 63: ordinal not in range(128) about sshuttle

[brianmay]

Oh, of course, locale dependant. I never even considered this as a possibility. Seems so obvious now...

Guessing we should set LC_ALL to C (as LC_ALL overrides all other environment variables including LANG) when running this external command (and possibly other external commands too).

[maronemoraes]

Guys,

I edited server.py file in my system.

Original:

69 cols = re.split(r'\s+', line.decode("ascii"))

Edited:

69 cols = re.split(r'\s+', line.decode("utf-8"))

Apparently the problem was solved.
You can test whether it works for you too?

[vieira]

I will try again when I get home as I am at work right now, but my first attempt to reproduce did not result in any errors:

# sshuttle -vvv --dns -r root@vulcan 0/0 root@vulcan 0/0
Starting sshuttle proxy.
firewall manager: Starting firewall with Python version 2.7.6
firewall manager: ready method name nat.
IPv6 enabled: False
UDP enabled: False
DNS enabled: True
Binding redirector: 12300
TCP redirector listening on ('127.0.0.1', 12300).
TCP redirector listening with <socket._socketobject object at 0x7f5fd7d4ff30>.
Binding DNS: 12300
DNS listening on ('127.0.0.1', 12300).
DNS listening with <socket._socketobject object at 0x7f5fd7d4ffa0>.
Starting client with Python version 2.7.6
c : connecting to server...
c : executing: ['ssh', 'root@vulcan', '--', 'exec /bin/sh -c \'P=python3.5; $P -V 2>/dev/null || P=python; exec "$P" -c \'"\'"\'import sys, os; verbosity=3; sys.stdin = os.fdopen(0, "rb"); exec(compile(sys.stdin.read(958), "assembler.py", "exec"))\'"\'"\'\'']
c :  > channel=0 cmd=PING len=7 (fullness=0)
server: assembling 'sshuttle' (7 bytes)
server: assembling 'sshuttle.cmdline_options' (27 bytes)
server: assembling 'sshuttle.helpers' (949 bytes)
server: assembling 'sshuttle.ssnet' (5544 bytes)
server: assembling 'sshuttle.hostwatch' (2361 bytes)
server: assembling 'sshuttle.server' (3091 bytes)
Starting server with Python version 3.5.1+
 s: latency control setting = True
 s: available routes:
 s:   2/192.168.23.0/24
 s:   2/192.168.64.0/20
 s:   2/192.168.200.0/24
c : Connected.
c : Waiting: 3 r=[4, 7, 9] w=[9] x=[] (fullness=7/0)
c :   Ready: 3 r=[] w=[9] x=[]
c : mux wrote: 15/15
c : Waiting: 3 r=[4, 7, 9] w=[] x=[] (fullness=7/0)
 s:  > channel=0 cmd=PING len=7 (fullness=0)
 s:  > channel=0 cmd=ROUTES len=55 (fullness=7)
 s: Waiting: 1 r=[4] w=[5] x=[] (fullness=62/0)
 s:   Ready: 1 r=[] w=[5] x=[]
 s: <  channel=0 cmd=PING len=7
 s:  > channel=0 cmd=PONG len=7 (fullness=62)
 s: mux wrote: 15/15
 s: Waiting: 1 r=[4] w=[5] x=[] (fullness=69/0)
c :   Ready: 3 r=[9] w=[] x=[]
 s:   Ready: 1 r=[] w=[5] x=[]
 s: mux wrote: 63/63
 s: Waiting: 1 r=[4] w=[5] x=[] (fullness=69/0)
 s:   Ready: 1 r=[] w=[5] x=[]
 s: mux wrote: 15/15
 s: Waiting: 1 r=[4] w=[] x=[] (fullness=69/0)
c : <  channel=0 cmd=PING len=7
c :  > channel=0 cmd=PONG len=7 (fullness=7)
c : <  channel=0 cmd=ROUTES len=55
firewall manager: Got subnets: [(2, 0, False, '0.0.0.0'), (2, 8, True, '127.0.0.1')]
firewall manager: Got partial nslist: [(2, '127.0.1.1')]
firewall manager: Got nslist: [(2, '127.0.1.1')]
firewall manager: Got ports: 0,12300,0,12300
firewall manager: Got udp: False
firewall manager: setting up.
firewall manager: setting up IPv4.
>> iptables -t nat -N sshuttle-12300
>> iptables -t nat -F sshuttle-12300
>> iptables -t nat -I OUTPUT 1 -j sshuttle-12300
>> iptables -t nat -I PREROUTING 1 -j sshuttle-12300
>> iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.1/8 -p tcp
>> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 0.0.0.0/0 -p tcp --to-ports 12300 -m ttl ! --ttl 42
>> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 127.0.1.1/32 -p udp --dport 53 --to-ports 12300 -m ttl ! --ttl 42
c : <  channel=0 cmd=PONG len=7
c : received PING response
c : mux wrote: 15/15
c : Waiting: 3 r=[4, 7, 9] w=[] x=[] (fullness=0/0)
 s:   Ready: 1 r=[4] w=[] x=[]
 s: <  channel=0 cmd=PONG len=7
 s: received PING response
 s: Waiting: 1 r=[4] w=[] x=[] (fullness=0/0)
c :   Ready: 3 r=[7] w=[] x=[]
c : Accept UDP using recvfrom.
c : DNS request from ('127.0.0.1', 57691) to None: 33 bytes
c :  > channel=1 cmd=DNS_REQ len=33 (fullness=0)
c : Remaining DNS requests: 1
c : Remaining UDP channels: 0
c : Waiting: 3 r=[4, 7, 9] w=[9] x=[] (fullness=33/0)
c :   Ready: 3 r=[7] w=[9] x=[]
c : mux wrote: 41/41
c : Accept UDP using recvfrom.
c : DNS request from ('127.0.0.1', 57691) to None: 33 bytes
c :  > channel=2 cmd=DNS_REQ len=33 (fullness=33)
c : Remaining DNS requests: 2
c : Remaining UDP channels: 0
c : Waiting: 3 r=[4, 7, 9] w=[9] x=[] (fullness=66/0)
c :   Ready: 3 r=[] w=[9] x=[]
c : mux wrote: 41/41
c : Waiting: 3 r=[4, 7, 9] w=[] x=[] (fullness=66/0)
 s:   Ready: 1 r=[4] w=[] x=[]
 s: <  channel=1 cmd=DNS_REQ len=33
 s: Incoming DNS request channel=1.
 s: DNS: sending to '192.168.69.245' (try 1)
 s: <  channel=2 cmd=DNS_REQ len=33
 s: Incoming DNS request channel=2.
 s: DNS: sending to '192.168.69.246' (try 1)
 s: Waiting: 3 r=[4, 7, 8] w=[] x=[] (fullness=0/0)
 s:   Ready: 3 r=[7] w=[] x=[]
 s: DNS response: 212 bytes
 s:  > channel=1 cmd=DNS_RESPONSE len=212 (fullness=0)
 s: expiring dnsreqs channel=1
 s: Waiting: 2 r=[4, 8] w=[5] x=[] (fullness=212/0)
 s:   Ready: 2 r=[8] w=[5] x=[]
 s: mux wrote: 220/220
 s: DNS response: 224 bytes
 s:  > channel=2 cmd=DNS_RESPONSE len=224 (fullness=212)
c :   Ready: 3 r=[9] w=[] x=[]
c : <  channel=1 cmd=DNS_RESPONSE len=212
 s: expiring dnsreqs channel=2
 s: Waiting: 1 r=[4] w=[5] x=[] (fullness=436/0)
 s:   Ready: 1 r=[] w=[5] x=[]
 s: mux wrote: 232/232
 s: Waiting: 1 r=[4] w=[] x=[] (fullness=436/0)
c : dns_done: channel=1 src=None dst=('127.0.0.1', 57691)
c : <  channel=2 cmd=DNS_RESPONSE len=224
c : dns_done: channel=2 src=None dst=('127.0.0.1', 57691)
c : Waiting: 3 r=[4, 7, 9] w=[] x=[] (fullness=66/0)

[alphazo]

I forgot to mention that downgrading to sshuttle 0.77.2 on my Archlinux client fixes the problem with this particular server (Debian 7.1, Python 2.7.3). I have other servers running Debian 8.4 with Python 2.7.9 and that work with both sshuttle 0.77.2 and 0.78.0.

[vieira]

Oops, I mixed the versions. I was testing 2.7 on the client and 3.5 on the server when you are reporting the reverse. Unfortunately I don't have a machine with 3.5 and iptables at hand. When I get home I will try to reproduce. Weird that a minor difference in Python (2.7.3 to 2.7.9) makes the problem go away 😲

[brianmay]

There is a report on the mailing list that looks identical. https://groups.google.com/forum/#!topic/sshuttle/HNzO5iuYvzQ

[brianmay]

To me it looks that the output of netstat -rn has non-ASCII characters, in particular 0xc3. However this makes no sense to me as it should be ASCII only.

So if you can reproduce the problem, please check the output of netstat -rn on the server and check for non-ASCII characters.

[alphazo]

The working server (Debian 8.4 with Python 2.7.9) that works with both sshuttle 0.77.2 and 0.78.0 has its locale set to English:

# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         217.14.122.1    0.0.0.0         UG        0 0          0 eth0
10.8.0.0        0.0.0.0         255.255.255.0   U         0 0          0 tun0
217.14.122.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0

And the non working one (only with shuttle 0.78 though) running Debian 7.1, Python 2.7.3 has its locale set to French. Could the weird accent found on the word "Fenêtre" be a problem?

# netstat -rn
Table de routage IP du noyau
Destination     Passerelle              Genmask         Indic   MSS Fenêtre    irtt    Iface
192.168.1.100   0.0.0.0             255.255.255.255 UH  0 0         0   venet0
10.8.0.2        0.0.0.0             255.255.255.255 UH  0 0         0   tun0
192.168.1.104   0.0.0.0             255.255.255.255 UH  0 0         0   venet0
62.208.42.0     0.0.0.0             255.255.255.0   U   0 0         0   vmbr0
10.8.0.0        10.8.0.2            255.255.255.0   UG  0 0         0   tun0
0.0.0.0         62.2O8.42.1         0.0.0.0         UG  0 0         0   vmbr0

[maronemoraes]

Hi folks!

In my remote system i got this output:

[suporte@mylocation ~]$ netstat -rn
Tabela de Roteamento IP do Kernel
Destino Roteador MáscaraGen. Opções MSS Janela irtt Iface
192.168.20.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 192.168.20.1 0.0.0.0 UG 0 0 0 eth0

The affirmation of alphazo makes a sense. The problem are in accent character in "netstat" output.

[brianmay]

@maronemoraes that is not a good solution because you are assuming utf-8. Not to mention there could be other changes due to locale. Far better to change the locale to C I think. About to commit a change to do this.

[brianmay]

Fixed in 8fad282. Would appreciate if somebody could test this.

[alphazo]

I confirm that it fixes the issue. I recompiled the latest git version 0.78.1.dev6<+ng1d64879 that includes your commit and I had no issue connecting to servers with non English locale. Thanks.

[brianmay]

Marking this as closed. Guess I need to do a new release soon.