Archived
This forum has been archived. Please start a new discussion on GitHub.
Odd "No route to host" error
Hi,
We're having the strangest issue communicating through ICE between a Python 3 script and a Mumble server. The python script and the ice file are all part of the Chrooms software by Jonas Olson.
And what's really strange about it is that we're getting a ConnectFailedException with the message "No route to host" on line 30 even though ICE has already connected to the Mumble server. This becomes evident if one shuts down the Mumble server upon which one gets a Connection refused error instead on line 28.
The thing is that there's a perfectly working route from the machine that runs the python script and the machine that runs the Mumble server. One can run, and so can you, "telnet mu.rovanion.se 6502" and get "IceP" as response on the server with the script on.
So does anyone know why this error is occurring even though there's evidently a route to the destination host?
The machine running the python script is running Debian Wheezy, kernel 3.2, Python 3.4.2 and python3-zeroc-ice 3.5.1. The machine running mumble is running Ubuntu 14.04, kernel 3.13 and zeroc-ice 3.5.1.
We're having the strangest issue communicating through ICE between a Python 3 script and a Mumble server. The python script and the ice file are all part of the Chrooms software by Jonas Olson.
And what's really strange about it is that we're getting a ConnectFailedException with the message "No route to host" on line 30 even though ICE has already connected to the Mumble server. This becomes evident if one shuts down the Mumble server upon which one gets a Connection refused error instead on line 28.
Traceback (most recent call last): File "./move_user.py", line 30, in <module> users = server.getUsers() File "murmur.ice", line 2867, in getUsers Ice.ConnectFailedException: Ice.ConnectFailedException: No route to host
The thing is that there's a perfectly working route from the machine that runs the python script and the machine that runs the Mumble server. One can run, and so can you, "telnet mu.rovanion.se 6502" and get "IceP" as response on the server with the script on.
So does anyone know why this error is occurring even though there's evidently a route to the destination host?
The machine running the python script is running Debian Wheezy, kernel 3.2, Python 3.4.2 and python3-zeroc-ice 3.5.1. The machine running mumble is running Ubuntu 14.04, kernel 3.13 and zeroc-ice 3.5.1.
0
Comments
-
Enable network tracing in move_user.py around line 22 add Ice.Trace.Network and post the traces
props.setProperty('Ice.ImplicitContext', 'Shared') [B]props.setProperty('Ice.Trace.Network', '3')[/B]
0 -
This is the output we get with debugging turned on:
-- 12/30/14 20:46:35.758 Network: trying to establish tcp connection to 94.254.72.129:6502
-- 12/30/14 20:46:35.766 Network: tcp connection established
local address = 130.236.245.45:55372
remote address = 94.254.72.129:6502
-- 12/30/14 20:46:35.774 Network: received 14 of 14 bytes via tcp
local address = 130.236.245.45:55372
remote address = 94.254.72.129:6502
-- 12/30/14 20:46:35.774 Network: sent 76 of 76 bytes via tcp
local address = 130.236.245.45:55372
remote address = 94.254.72.129:6502
-- 12/30/14 20:46:35.782 Network: received 14 of 14 bytes via tcp
local address = 130.236.245.45:55372
remote address = 94.254.72.129:6502
-- 12/30/14 20:46:35.782 Network: received 12 of 12 bytes via tcp
local address = 130.236.245.45:55372
remote address = 94.254.72.129:6502
-- 12/30/14 20:46:35.783 Network: sent 67 of 67 bytes via tcp
local address = 130.236.245.45:55372
remote address = 94.254.72.129:6502
-- 12/30/14 20:46:35.791 Network: received 14 of 14 bytes via tcp
local address = 130.236.245.45:55372
remote address = 94.254.72.129:6502
-- 12/30/14 20:46:35.791 Network: received 49 of 49 bytes via tcp
local address = 130.236.245.45:55372
remote address = 94.254.72.129:6502
-- 12/30/14 20:46:35.791 Network: trying to establish tcp connection to 10.0.0.2:6502
-- 12/30/14 20:46:35.793 Network: failed to establish tcp connection
local address = 130.236.245.45:60953
remote address = 10.0.0.2:6502
Network.cpp:2175: Ice::ConnectFailedException:
connect failed: No route to host
-- 12/30/14 20:46:35.793 Network: trying to establish tcp connection to 10.0.0.2:6502
-- 12/30/14 20:46:36.792 Network: failed to establish tcp connection
local address = 130.236.245.45:60954
remote address = 10.0.0.2:6502
Network.cpp:2175: Ice::ConnectFailedException:
connect failed: No route to host
Traceback (most recent call last):
File "./move_user.py", line 31, in <module>
users = server.getUsers()
File "murmur.ice", line 2867, in getUsers
Ice.ConnectFailedException: Ice.ConnectFailedException:
No route to host
The intestering thing is that it first successfully connects to the NAT:ed mumble servers external IP. But then attempts to connect to the mumble servers internal IP instead resulting, since the two machines aren't on the same LAN, no route being available.
I guess that the Mumble ICE in some way communicates the address it's bound to which results in the Python script trying that for it's next connection attempt. I've tried setting up ICE on the mumble server end so that it binds to the external address 94.254.72.129, but that wouldn't work. Neither could I set it up to bind to a domain name. So I'm out of ideas for now.0 -
You can control the endpoints published in your proxies setting the adapter PublishedEndpoints see Object Adapter Endpoints
This also mentioned in the Mumble documentation Murmur.ini . If you have more Mumble questions is better to ask directly in Mumble Forums.
Regards,
José0 -
Now I'm curious; why is it that ICE switches over to using the address specified by the receiving end halfway through the communication?0
-
The script is using two different proxies and those proxies have different endpoints, in move_user.py
[code]
proxy = comm.stringToProxy('Meta:tcp -h {0} -p {1}'.format(mumble_host, mumble_port))
server = Murmur.MetaPrx.checkedCast(proxy).getServer(1)
users = server.getUsers()
[code]
The proxy variable holds a proxy created locally with the public ip passed to the script.
The server variable holds a proxy returned by the call to getServer, that proxy contains the internal ip in its endpoints.
When you call on the second proxy Ice try to create a new connection and fails because there isn't a route.0