Bug 276 - WCF on Mono can't seem to communicate with .NET 4.0's WCF on Windows
Summary: WCF on Mono can't seem to communicate with .NET 4.0's WCF on Windows
Status: NEW
Alias: None
Product: Class Libraries
Classification: Mono
Component: WCF assemblies (show other bugs)
Version: master
Hardware: PC Linux
: Normal major
Target Milestone: Untriaged
Assignee: Bugzilla
URL:
Depends on:
Blocks:
 
Reported: 2011-08-12 03:03 UTC by Stephen Kou
Modified: 2012-01-20 17:26 UTC (History)
2 users (show)

See Also:
Tags: mono-ms.net interop
Is this bug a regression?: ---
Last known good build:


Attachments
Repro testcase (3.91 KB, application/x-zip-compressed)
2011-08-13 06:24 UTC, Stephen Kou
Details

Description Stephen Kou 2011-08-12 03:03:07 UTC
A service running on .NET 4.0 on windows with a client attempting to connect from mono on linux causes exceptions to be thrown during connection setup (on the mono side).  The server never sees the connection attempt.  Looks like perhaps some net.tcp protocol bug where the ms .net doesn't like, and closes the socket.  Exception trace follows.  This is duplex channel, BTW.

Unhandled Exception: System.IO.IOException: Read failure ---> System.Net.Sockets.SocketException: Connection reset by peer
  at System.Net.Sockets.Socket.Receive (System.Byte[] buffer, Int32 offset, Int32 size, SocketFlags flags) [0x00000] in <filename unknown>:0 
  at System.Net.Sockets.NetworkStream.Read (System.Byte[] buffer, Int32 offset, Int32 size) [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at System.Net.Sockets.NetworkStream.Read (System.Byte[] buffer, Int32 offset, Int32 size) [0x00000] in <filename unknown>:0 
  at System.IO.Stream.ReadByte () [0x00000] in <filename unknown>:0 
  at System.ServiceModel.Channels.NetTcp.TcpBinaryFrameManager.ProcessPreambleAckInitiator () [0x00000] in <filename unknown>:0 
  at System.ServiceModel.Channels.NetTcp.TcpDuplexSessionChannel.OnOpen (TimeSpan timeout) [0x00000] in <filename unknown>:0 
  at System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan timeout) [0x00000] in <filename unknown>:0 
  at System.ServiceModel.MonoInternal.ClientRuntimeChannel.OnOpen (TimeSpan timeout) [0x00000] in <filename unknown>:0 
  at System.ServiceModel.MonoInternal.DuplexClientRuntimeChannel.OnOpen (TimeSpan timeout) [0x00000] in <filename unknown>:0 
  at System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan timeout) [0x00000] in <filename unknown>:0 
  at System.ServiceModel.Channels.CommunicationObject.Open () [0x00000] in <filename unknown>:0 
  at System.ServiceModel.MonoInternal.ClientRuntimeChannel.DoProcess (System.Reflection.MethodBase method, System.String operationName, System.Object[] parameters) [0x00000] in <filename unknown>:0 
  at System.ServiceModel.MonoInternal.ClientRuntimeChannel.Process (System.Reflection.MethodBase method, System.String operationName, System.Object[] parameters) [0x00000] in <filename unknown>:0 
[ERROR] FATAL UNHANDLED EXCEPTION: System.IO.IOException: Read failure ---> System.Net.Sockets.SocketException: Connection reset by peer
  at System.Net.Sockets.Socket.Receive (System.Byte[] buffer, Int32 offset, Int32 size, SocketFlags flags) [0x00000] in <filename unknown>:0 
  at System.Net.Sockets.NetworkStream.Read (System.Byte[] buffer, Int32 offset, Int32 size) [0x00000] in <filename unknown>:0 
  --- End of inner exception stack trace ---
  at System.Net.Sockets.NetworkStream.Read (System.Byte[] buffer, Int32 offset, Int32 size) [0x00000] in <filename unknown>:0 
  at System.IO.Stream.ReadByte () [0x00000] in <filename unknown>:0 
  at System.ServiceModel.Channels.NetTcp.TcpBinaryFrameManager.ProcessPreambleAckInitiator () [0x00000] in <filename unknown>:0 
  at System.ServiceModel.Channels.NetTcp.TcpDuplexSessionChannel.OnOpen (TimeSpan timeout) [0x00000] in <filename unknown>:0 
  at System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan timeout) [0x00000] in <filename unknown>:0 
  at System.ServiceModel.MonoInternal.ClientRuntimeChannel.OnOpen (TimeSpan timeout) [0x00000] in <filename unknown>:0 
  at System.ServiceModel.MonoInternal.DuplexClientRuntimeChannel.OnOpen (TimeSpan timeout) [0x00000] in <filename unknown>:0 
  at System.ServiceModel.Channels.CommunicationObject.Open (TimeSpan timeout) [0x00000] in <filename unknown>:0 
  at System.ServiceModel.Channels.CommunicationObject.Open () [0x00000] in <filename unknown>:0 
  at System.ServiceModel.MonoInternal.ClientRuntimeChannel.DoProcess (System.Reflection.MethodBase method, System.String operationName, System.Object[] parameters) [0x00000] in <filename unknown>:0 
  at System.ServiceModel.MonoInternal.ClientRuntimeChannel.Process (System.Reflection.MethodBase method, System.String operationName, System.Object[] parameters) [0x00000] in <filename unknown>:0
Comment 1 Stephen Kou 2011-08-13 06:24:54 UTC
Created attachment 121 [details]
Repro testcase

Run the server.exe (gmcs -r:System.ServiceModel.dll Interface.cs Server.cs) on windows -- it will listen at 0.0.0.0:58000, and run Client.exe (gmcs -r:System.ServiceModel.dll Client.cs Interface.cs) with "net.tcp://<serverip>:58000/add" as the command-line parameter.  It SHOULD print out 11.  Instead it dies and exceptions on some "Preamble Ack record is expected, got FFFFFFFF".

The client-server works fine from mono->mono, but not mono->ms.net.

Didnt test other direction (ms.net -> mono).  But since mono can't listen on 0.0.0.0 (see other bug), this wasn't easy to test.  Would require SSH tunneling onto localhost or something to achieve connectivity with the mono server.
Comment 2 Stephen Kou 2011-08-20 16:02:29 UTC
Amendment:

After using wireshark and reading the spec, it seems to work fine if I turn off net.tcp's security -- the default on MS's implementation is to turn it on, while mono's default is to turn it off.  The MS implementation then expects an UpgradeProtocol record requesting for application/negotiate; mono fails to send this and the MS side then closes the connection.

Explicitly setting binding.Security.Mode = None (on both server and client side) makes the above sample work.

Perhaps it would be best to throw a NotImplementedException explaining this.

Note You need to log in before you can comment on or make changes to this bug.