Bug 28018 - Under certain circumstances XamarinVS aborts build host handshake early with RST ACK packet
Summary: Under certain circumstances XamarinVS aborts build host handshake early with ...
Status: RESOLVED FIXED
Alias: None
Product: Visual Studio Extensions
Classification: Xamarin
Component: iOS ()
Version: 3.9
Hardware: PC Windows
: --- major
Target Milestone: ---
Assignee: Brendan Zagaeski (Xamarin Team, assistant)
URL:
Depends on:
Blocks:
 
Reported: 2015-03-13 14:44 UTC by Brendan Zagaeski (Xamarin Team, assistant)
Modified: 2015-09-28 15:09 UTC (History)
4 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED FIXED

Description Brendan Zagaeski (Xamarin Team, assistant) 2015-03-13 14:44:11 UTC
Under certain circumstances XamarinVS aborts build host handshake early with RST ACK packet



## Steps followed by customer to reproduce

1. Ensure mtbserver is running on the Mac build host, and make sure port 5000 is accessible from the Windows machine.

2. Attempt to pair to the build host from "Tools -> Options -> Xamarin -> iOS Settings -> Find Mac Build Host".



## Results

With the customer's particular configuration, the connection fails every time. An error appears in the "Error List":

> Build server with address 192.168.1.1 is too old to be used with
> this version of Xamarin.iOS extension. Double click here to select a
> new server.


### Packet capture traffic comparison

A "good" handshake from my computer appears to produce the following set of packets (see also "GoodHanshake.pcap" in the attached logs):

>  1. Windows -> Build Host (port 5000):  [SYN]
>  2. Build Host (port 5000) -> Windows:  [SYN, ACK]
>  3. Windows -> Build Host (port 5000):  [ACK]
>  4. Build Host (port 5000) -> Windows:  [TCP Window Update] [ACK]
>  5. Windows -> Build Host (port 5000):  [PSH, ACK] "HELO"
>  6. Build Host (port 5000) -> Windows:  [ACK]
>  7. Build Host (port 5000) -> Windows:  [PSH, ACK] "MTBSERVERPORTS 56428;56429"
>  8. Windows -> Build Host (port 5000):  [ACK]
>  9. Build Host (port 5000) -> Windows:  [PSH, ACK] (some binary data)
> 10. Windows -> Build Host (port 5000):  [PSH, ACK] (some binary data)
> 11. Build Host (port 5000) -> Windows:  [ACK]
> 12. Windows -> Build Host (port 56428): [SYN]
> 13. Build Host (port 56428) -> Windows: [SYN, ACK]
> 14. Windows -> Build Host (port 56428): [ACK]


The "bad" handshake from the customer's computer produces the following packets (see also "BadHanshake.pcap" in the attached logs):

>  1. Windows -> Build Host (port 5000):  [SYN]
>  2. Build Host (port 5000) -> Windows:  [SYN, ACK]
>  3. Windows -> Build Host (port 5000):  [ACK]
>  4. Windows -> Build Host (port 5000):  [PSH, ACK] "HELO"
>  5. Build Host (port 5000) -> Windows:  [TCP Window Update] [ACK]
>  6. Build Host (port 5000) -> Windows:  [ACK]
>  7. Build Host (port 5000) -> Windows:  [PSH, ACK] "MTBSERVERPORTS 49220;49221"
>  8. Windows -> Build Host (port 5000):  [ACK]
>  9. Build Host (port 5000) -> Windows:  [PSH, ACK] (some binary data)
> 10. Windows -> Build Host (port 5000):  [PSH, ACK] (some binary data)
> 11. Build Host (port 5000) -> Windows:  [ACK]
> 12. Windows -> Build Host (port 5000):  [RST, ACK]


The result is almost identical up until the twelfth packet. For some reason rather than attempting to send a [SYN] packet to the build host on one the MTBSERVERPORTS, the Windows side sends a [RST, ACK] packet on port 5000, shutting down the connection.


### Corresponding lines from `mtbserver.log` for the bad handshake

> [10-Mar-2015 13:06:54] Server IP Address : 192.168.1.1
> [10-Mar-2015 13:06:54] Error: An error occurred (no details available)
> [10-Mar-2015 13:06:54] Got connection from Visual Studio (log)


### Corresponding lines from `devenv*.log` for the bad handshake

> Xamarin.VisualStudio.IOS.Utilities.BuildServer Information: 0 : [2015-03-10 13:06:52.2] Opening control connection
> Xamarin.VisualStudio.IOS.Utilities.BuildServer Information: 0 : [2015-03-10 13:06:55.0] Control connection to 192.168.1.1 established
> Xamarin.VisualStudio.IOS.Utilities.BuildServer Error: 0 : [2015-03-10 13:06:55.0] Exception caught.
> Xamarin.VisualStudio.IOS.Utilities.BuildServer Error: 0 : [2015-03-10 13:06:55.0] Server returned an error. Unable to connect to the remote server
> 
> Xamarin.VisualStudio.IOS.Utilities.BuildServer Error: 0 : [2015-03-10 13:06:55.1] Build server control connection failed
> Xamarin.VisualStudio.IOS.Utilities.BuildServer Error: 0 : [2015-03-10 13:06:55.1] Server 192.168.1.1 hung up connection. Unable to read data from the transport connection: A blocking operation was interrupted by a call to WSACancelBlockingCall. (System.IO.IOException)



## Customer's version information

Microsoft Visual Studio Professional 2013
Version 12.0.31101.00 Update 4
Microsoft .NET Framework
Version 4.5.51650

Xamarin   3.9.347.0 (056cf9e)
Xamarin.Android   4.20.0.37 (9e05e39f02bafe8fc0b7ab025d99f3b446835ad4)
Xamarin.iOS   8.6.3.0 (90e32d01b5960ef8487d3b0a865cb3301dfd95f4)


### OS X 10.9.5
Xamarin.iOS 8.6.3.3 (Business Edition)
Hash: 90e32d0
Build date: 2015-03-06 12:27:17-0500
Comment 2 Brendan Zagaeski (Xamarin Team, assistant) 2015-03-18 21:20:44 UTC
One small note: the symptoms of this case are distinct from the "classic" case where an HTTP proxy on the Windows side causes an inaccurate "too old to be used" message.

I have just filed a bug for the inaccurate error message associated with that fairly well-known HTTP proxy scenario here: bug 28177. As noted there, the handshake in that case completes successfully, and the Windows side starts sending HTTP requests to the MTBSERVERPORTS of the Mac build host.

In _this_ bug, the Windows side does _not_ complete the handshake, and never sends any HTTP requests to the Mac build host.
Comment 3 Brendan Zagaeski (Xamarin Team, assistant) 2015-03-27 16:35:43 UTC
The customer who was originally hitting this issue has fortunately worked around the problem for now by installing Xamarin on a different (Windows 7) computer. The problem on the original (Windows 8.1) computer might be related to fairly particular networking settings.