none
"Unable to read data from the transport connection" error with SSL connection

    Question

  •  

    I have an app on a WM6 device that when I try to connect to a certain web site over SSL a WebException is thrown that says "Unable to read data from the transport connection."  The Status of the WebException is "ReceiveFailure" and the Response is null.

     

    The error occurs here:

    response = (HttpWebResponse)request.GetResponse();

     

    Also this is only happening on a server using SSL.  On a different server that is non SSL, the request works correctly.

    Wednesday, November 14, 2007 6:39 PM

All replies

  •  

    I have even tried updating the certs on the device and that wasn't helping.
    Thursday, November 15, 2007 1:40 PM
  • Hi Tony,

     

    I'm not aware of any bugs connecting to an SSL source on WM6.  Are you sure your connection can talk to the server using port 443?  Have you tried browsing the site using pocket IE?  I think I would try and prove at a socket level that the connection can be made.  What type of connection is getting made?  WM6 can support more than one connection via connection manager, are you using the connection source you need?

     

    NozFx

    Sunday, November 18, 2007 12:27 PM
  • i am facing same problem..same code works fine with WM5 but gives error in WM6....n its kind of very frustratin.
    Monday, November 19, 2007 6:13 AM
  • Yes I can connect through a browser just fine.  I also discovered that if the web server, which in this case is IIS, has Require client certificates enabled I get this error with my program.  If the setting is changed to Ignore Client Certificates the program works fine.

    Monday, November 19, 2007 2:09 PM
  • What version of .NET Compact Framework are you using? (always useful to know)

     

    We recently found a bug in NetCF's SSL stack where if a server sends empty encryption packets to the NetCF client that NetCF can misinterpret the server's intentions and terminate the connection, resulting in the error you describe.  Because this encryption is very low-level and out of most coders' control, the workaround would typically be to find a different server to call that somehow is configured to not send those empty encryption packets.  (I have not yet narrowed down what settings cause the server to behave this way.  The client certficate demand is an interesting possibility).

     

    Anyway, this bug appears in NetCF 2.0 and 3.5.  If you can share the https URL that is failing I can check it to see if it exposes the behavior that causes this bug.  Otherwise, I may be able to distribute a test app that will allow you to detect this on your own computer.

    Monday, November 19, 2007 9:19 PM
  • I am using 2.0 on the device.  Since this is a problem for a client of our company I can't give out the address of their server.  However, I could use the test app you mentioned.

     

    Thanks.

    Monday, November 19, 2007 9:50 PM
  • I totally understand the need to keep servers internal.  I have completed the test app that should be able to identify whether this documented bug is the problem you are experiencing.  However, I am waiting for clearance from our attorneys to publish it.  I probably won't have an answer before Monday due to the Thanksgiving holiday.  When I do get it published, it will be linked to from the end of this blog post on the subject:

     

    http://blogs.msdn.com/andrewarnottms/archive/2007/11/19/why-net-compact-framework-fails-to-call-some-https-web-servers.aspx

    Tuesday, November 20, 2007 5:40 PM
  • Awesome.  Monday will be good.

     

    Thank you.

    Tuesday, November 20, 2007 7:55 PM
  • Was there an offical bug posted for this as well?  Can you post the link?

    Tuesday, November 20, 2007 8:55 PM
  • m getting same problem with this link    https://login.yahoo.com

                    HttpWebRequest HttpWReq = (HttpWebRequest)WebRequest.Create(
    "https://login.yahoo.com");
                    HttpWReq.Method = "Get";
                    HttpWReq.ContentType = "text/plain";
                    HttpWReq.UserAgent = ".NETCF";
                    HttpWReq.Accept = "*/*";
                    HttpWReq.Timeout = -1;
                    HttpWReq.ProtocolVersion = HttpVersion.Version10;
                   
                    HttpWebResponse HttpWResp = (HttpWebResponse)HttpWReq.GetResponse();

    fires Exception "Unable to read data from the transport connection..."
    at System.Net.HttpWebRequest.finishGetResponse()
    at System.Net.HttpWebRequest.GetResponse()
    Thursday, November 22, 2007 9:56 AM
  •  Tony_NTFY wrote:

    Was there an offical bug posted for this as well?  Can you post the link?


    Are you looking for a Connect bug?  To my knowledge one hasn't been created.  But there is a bug in our internal bug database tracking this, yes.
    Monday, December 03, 2007 5:42 PM
  •  vinaychavan22 wrote:
    m getting same problem with this link    https://login.yahoo.com

    I've checked this URL, and indeed this site is sending the empty encryption packets that cause NetCF to fail.
    Monday, December 03, 2007 5:50 PM
  • I have tried the app on a test server and had a couple of problems.  When I run it, I get an error "DecryptMessage failed with error code 0x90321."

     

    If i comment out line 486 ( scRet = SEC_E_INCOMPLETE_MESSAGE; ) I can get a message "0 bytes in decryted packet (EMPTY). No extra data. Waiting for more..." and the program hangs.

     

    Could that indicate the empty packet problem?  This happens with the option to require cloent certs or accept client certs enabled.

    Monday, December 03, 2007 8:30 PM
  •  Tony_NTFY wrote:

    I have tried the app on a test server and had a couple of problems.  When I run it, I get an error "DecryptMessage failed with error code 0x90321."

     

    If i comment out line 486 ( scRet = SEC_E_INCOMPLETE_MESSAGE; ) I can get a message "0 bytes in decryted packet (EMPTY). No extra data. Waiting for more..." and the program hangs.

     

    Could that indicate the empty packet problem?  This happens with the option to require cloent certs or accept client certs enabled.

    The hang is probably resulting from the change in logic that results from commenting out the line.  The error is from a buffer being too small.  Please try downloading the code again (I just posted V2 of the code on the same blog post).  Let me know if it's still a problem.  If it is, and if you can possibly give the address of the server (if it's public) that causes this I can debug the client that way.

    Monday, December 03, 2007 8:49 PM
  • I had the same issue with the V2 code.

    Tuesday, December 04, 2007 7:07 PM
  • Tony,

     

    I mistakenly identified 0x90321 as a buffer overflow, but that's actually 0x80090321.  The error code you're seeing is actually a "success" message that the server wants to renegotiate the security.  This test app doesn't support renegotiate.  It could be enhanced to support it, but I may not have time to do it myself this week.

     

    Feel free to enhance the app yourself if you wish in the meantime.

     

    Wednesday, December 05, 2007 3:38 PM
  • Any news on thie issue?

    Thursday, December 20, 2007 8:25 PM
  • I added some level of renegotiation support, but because ultimately the server in question was actually challenging for user credentials I couldn't get any further.  Since you need to provide a client cert, you'll have to modify the code to load client credentials that include that.  If you do that for the initial request, I believe you can avoid the renegotiation challenge altogether.
    In short, I don't think renegotiation support will buy you anything, since you have to provide the client cert anyway and can probably avoid renegotiation by providing it up front.
    Thursday, December 20, 2007 10:56 PM
  • Do you know if and when there will be a fix for this?  Also do you know of a work-around?
    Wednesday, January 02, 2008 8:13 PM
  •  Tony_NTFY wrote:
    Do you know if and when there will be a fix for this?  Also do you know of a work-around?

    The fix for this is slated to be included in NetCF 3.5 SP1.  I can't comment on when SP1 will ship though. 

    The workarounds are listed on my blog, but I added one today for you (a device-side native web proxy that would decrypt the data and pass it on to your managed app).  This new workaround has the advantage of allowing you to leverage all your existing managed code, avoid rewriting a web service client in native code, but still eliminates the empty SSL packets that cause NetCF to close the connection.
    Wednesday, January 02, 2008 11:02 PM
  • Hi, any update for the fix of this bug?
    I have tested whti the Emulator and got the same problem. Then I donwloaded the USA version and it works witout problem... but now I'm testing a new PDA with WM6 and I got the problem but don't found any update or patch for the PDA. Why it works fine in one version of the Emulator, what was fixed on it, both are WM6?

    Thanks.
    Thursday, February 21, 2008 4:26 PM
  • Various builds of Windows Mobile seem to expose NetCF's SSL bug to a lesser or greater extent, but the bug can appear (technically) in any version of Windows Mobile.  It seems that later versions exhibit the bug more frequently.

    I don't know why some emulator images of WM6 are more likely to exhibit the bug than others.  Microsoft hasn't released a fix for the problem yet. It is slated for NetCF 3.5 SP1, and we're evaluating a QFE for NetCF 2.0 SP2 users to fix the bug.
    The fix will work equally well across all versions of Windows Mobile as the bug is actually in NetCF, even though different versions of Windows Mobile can cause the bug to show up or remain unnoticed.
    Thursday, February 21, 2008 4:57 PM
  • Thank for your anwer. I looks that we need to wait for the update or the patch.

    Well I found a solution to me problem, may be this can help somebody:
    - My project is for Visual Stuido 2005. Then I install Visual Stuidio 2008 (more support for WM6)
    - After upgrade my project to Visual studio 2008 I try a deploy with 2005, just for testing... it upload to my PDA a new version of the Compact Framework. Then the problem dissapeared!

    Useful Information:

    - Compact Framework with the problem: 2.0.6129.00
    - Compact Framework without the problem: 2.0.7045.00 (Path: C:\Program Files\Microsoft.NET\SDK\CompactFramework\v2.0\WindowsCE\wce500\armv4i\NETCFv2.wm.armv4i.cab)

    Regards!
    Thursday, February 21, 2008 10:42 PM
  • i am facing the same problem that you had mentioned, i needed to know if there

    is anyway we could reset the ServicePointManager.CertificatePolicy after we have initialize with the certificate policy.

    Because what is happening is in the first request in Https works fine, only in request after that the problem arises.what i was thinking of reseting or disposing the ServicePointManager.CertificatePolicy  object and create it before every request.

     

    please can you tell me if this can be done and how?

     

    Regards

    shaikh leeyaqat

    Friday, February 29, 2008 5:34 AM
  • Hi Andrew,

    Any update for the NetCF's SSL bug?

    You said you're evaluating a QFE for NetCF 2.0 SP2 users to fix the bug, 
    is there any positive result?

    Thanks.

    Jason
    Monday, October 06, 2008 4:00 AM
  • Hi Andrew
    I'm getting the same exception (Unknown exception 0x0,Unable to read data from the transport connection)
    Have you developed any solution for this problem...
    Perhaps some ideas on how to solve it might help.
    I'm using CF 2.0, and the standard PocketPC 2003 Emulator.
    My web service, on hitting which I get this exception, is on Java Platform.

    Monday, February 23, 2009 7:56 AM
  • DONE! OVER! FINITO!

    Microsoft released a HotFix for NETCF v3.5 on Windows Mobile: now you can use Web Services over SSL (without worrying about empty packets)
    http://blogs.msdn.com/raffael/archive/2009/05/20/microsoft-released-a-hotfix-for-netcf-v3-5-on-windows-mobile-now-you-can-use-web-services-over-ssl-without-worrying-about-empty-packets.aspx

    ---> direct link:
    FIX: A System.Net.WebException occurs when you run an application to send HTTPS Web requests to a server in an embedded device
    http://support.microsoft.com/kb/970549

    WARNING! Remember that analogously to every other hotfix you can ask to Technical Support about whatever Microsoft’s product, you should install it only if you're sure it’s for the problem you're being affected by. This is because a hotfix is meant to address a specific issue and has been tested precisely for that: it didn't go through the whole regression testing that it's usually done when packaging many hotfixes into a Service Pack. So, you don’t have to install this hotfix if you’re not interested on Web Services over SSL (sending empty packets).

    Happy fixing! :-)
    ~raffaele


    Thanks,
    ~raffaele
    http://blogs.msdn.com/raffael

    This posting is provided 'as is' with no warranties and confers no rights.
    Thursday, May 21, 2009 6:39 AM
  • I tried to get the hotfix and the kb article had no download link!  I tried going to the support site and it said there should be a "View and request hotfix downloads", but for me, there isn't.  Am I missing something?  
    Sunday, October 25, 2009 6:34 AM
  • There's no direct download available (at least at this time): you should contact Microsoft Technical Support and open a free Service Request asking to receive the hotfix. Why is this required? In general, purely to help you verifying that the hotfix you're requesting is the right one for the problem you're experiencing. It happens sometimes that a user requests for a fix (after having done his own troubleshooting) and after applying it discovers it doesn't address the problem (and might have added new ones, considering that it didn't do through the whole regression testing that is usually done when packaging many hotfixes into a Service Pack): that simply means that the hotfix was not intended for his specific issue -- not that the fix doesn't work. Microsoft Technical Support helps verifying that, so preventing possible problems.

    If you don't know how to open a Service Request, apart from following instructions on http://support.microsoft.com, you may also read my post http://blogs.msdn.com/raffael/archive/2008/05/14/get-what-you-paid-for.aspx.

    HTH!
    Thanks,
    ~raffaele
    http://blogs.msdn.com/raffael

    This posting is provided 'as is' with no warranties and confers no rights.
    Monday, October 26, 2009 8:05 AM