Mono/ubuntu/TcpChannel weird redirect to 127.0.1.1

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance



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.
.



Relevant Pages

  • RE: Printing from Win9x clients stops
    ... Open Server Management. ... then right-click the name of the computer running Windows Small Business ... >From the client computer: ... The Select Network Component Type ...
    (microsoft.public.windows.server.sbs)
  • RE: Printing from Win9x clients stops
    ... The printers with 9x drivers on the server appeared automatically in the ... > then right-click the name of the computer running Windows Small Business ... > From the client computer: ... The Select Network Component Type ...
    (microsoft.public.windows.server.sbs)
  • Re: after installing KB011829 OWA is not working anymore
    ... Based on my research, after you install hotfix KB911829, I suggest we ... Profile WMI Provider to each client computer that is running Windows Vista ... If you are running the Premium Edition of Windows Small Business Server ...
    (microsoft.public.exchange.connectivity)
  • Re: DHCP Issues. Very strange
    ... I understand the issue to be: some client computers ... can not obtain IP from SBS server. ... it is most possible a client side issue of Windows ... since you have join it to SBS domain and the Windows XP SP2 ...
    (microsoft.public.windows.server.sbs)
  • Authentication flaw in microsoft SMB protocol
    ... Microsoft uses SMB Protocol for “File and Printer sharing service” in all ... Authentication is used to authenticate the client on the server. ... logged-in user requests for a network share on the server, Windows ...
    (Bugtraq)