Jono
2009-03-06 23:06:28 UTC
Hi Everyone,
I'm tearing the last strands of my hair out. I'm using .NET TCP/binary
remoting between ubuntu and Windows, but when I run the remoting
server on ubuntu, with a Windows client, I get the following error:
System.Net.Sockets.SocketException: No connection could be made
because the target machine actively refused it 127.0.1.1:9092
Weird thing is that the url I'm trying to get the remote object from
is tcp://192.168.1.70:9092/Explorer.rem, at no point do I try and do
anything with the loopback 127.* address. Is there some kind of server
redirection in .NET remoting that might do this, and if so, how do I
control it to avoid crazy (and potentially insecure) problems like
this. If not, please read on...
More info about my network setup: there are two machines on my lan -
one has ubuntu/Mono (ip 192.168.1.70); the other Windows XP/.NET 3.5
(ip 192.168.1.65). The problem only occurs when the server is on the
ubuntu box (client on Windows). If I swap the roles around and run the
server on Windows (client on ubuntu) everything works fine.
I downloaded and fired up wireshark to see what was happening on the
network. It shows the TCP connection gets made correctly to
192.168.1.70 on port 9092, and then the ubuntu box sends back some
data with contents that immediately made me suspicious - the last few
bytes of data are "tcp://127.0.1.1:9092"
Just for a laugh, I wrote and ran a plain console app up on the
Windows box, listening on a System.Net.Sockets.Socket to localhost TCP
9092 - I just wanted to see if anything would try to connect to it. I
fired up wireshark again, started the real server on ubuntu and then
started the Windows client. Immediately, wireshark picked up the same
mysterious tcp://127.0.1.1:9092 response from ubuntu, and then my
breakpoint in the plain socket test app got hit - it had accepted an
incoming TCP connection from 127.0.1.1:4286. The wireshark trace
indicated that the original request to tcp://192.168.1.70:9092 came
from 127.0.1.1:4285.
So, it appears to me that:
1) the client makes the intended call from some random port
2) the remoting server under ubuntu/Mono incorrectly requests the
client to redirect somewhere else
3) the client makes a second call from its original port + 1, which
fails
Please somebody help me! How can I stop this madness?
As a little bit of extra information: I have tried the reverse - and
it works - using my Windows box as the server. The the last few bytes
of the wireshark trace are "tcp://192.168.0.65:9092" - as expected.
<code>
IChannel serverChannel = new TcpChannel(port);
ChannelServices.RegisterChannel(serverChannel);
RemotingConfiguration.RegisterWellKnownServiceType(typeof(Explorer),
"Explorer.rem", WellKnownObjectMode.SingleCall);
</code>
I note that I don't specify an ethernet interface anywhere when I set
up the server channel. I do have multiple NICs on the ubuntu server
machine.
I'm tearing the last strands of my hair out. I'm using .NET TCP/binary
remoting between ubuntu and Windows, but when I run the remoting
server on ubuntu, with a Windows client, I get the following error:
System.Net.Sockets.SocketException: No connection could be made
because the target machine actively refused it 127.0.1.1:9092
Weird thing is that the url I'm trying to get the remote object from
is tcp://192.168.1.70:9092/Explorer.rem, at no point do I try and do
anything with the loopback 127.* address. Is there some kind of server
redirection in .NET remoting that might do this, and if so, how do I
control it to avoid crazy (and potentially insecure) problems like
this. If not, please read on...
More info about my network setup: there are two machines on my lan -
one has ubuntu/Mono (ip 192.168.1.70); the other Windows XP/.NET 3.5
(ip 192.168.1.65). The problem only occurs when the server is on the
ubuntu box (client on Windows). If I swap the roles around and run the
server on Windows (client on ubuntu) everything works fine.
I downloaded and fired up wireshark to see what was happening on the
network. It shows the TCP connection gets made correctly to
192.168.1.70 on port 9092, and then the ubuntu box sends back some
data with contents that immediately made me suspicious - the last few
bytes of data are "tcp://127.0.1.1:9092"
Just for a laugh, I wrote and ran a plain console app up on the
Windows box, listening on a System.Net.Sockets.Socket to localhost TCP
9092 - I just wanted to see if anything would try to connect to it. I
fired up wireshark again, started the real server on ubuntu and then
started the Windows client. Immediately, wireshark picked up the same
mysterious tcp://127.0.1.1:9092 response from ubuntu, and then my
breakpoint in the plain socket test app got hit - it had accepted an
incoming TCP connection from 127.0.1.1:4286. The wireshark trace
indicated that the original request to tcp://192.168.1.70:9092 came
from 127.0.1.1:4285.
So, it appears to me that:
1) the client makes the intended call from some random port
2) the remoting server under ubuntu/Mono incorrectly requests the
client to redirect somewhere else
3) the client makes a second call from its original port + 1, which
fails
Please somebody help me! How can I stop this madness?
As a little bit of extra information: I have tried the reverse - and
it works - using my Windows box as the server. The the last few bytes
of the wireshark trace are "tcp://192.168.0.65:9092" - as expected.
<code>
IChannel serverChannel = new TcpChannel(port);
ChannelServices.RegisterChannel(serverChannel);
RemotingConfiguration.RegisterWellKnownServiceType(typeof(Explorer),
"Explorer.rem", WellKnownObjectMode.SingleCall);
</code>
I note that I don't specify an ethernet interface anywhere when I set
up the server channel. I do have multiple NICs on the ubuntu server
machine.