Windows 8 MessageWebSocket http request garbage - windows-8

Question

I'm developing a Windows 8 app that communicates with a node.js server using node.js/socket.io, and have ran into a pile of issues with connecting. I decided to run a tcp sniffer application (microsoft network monitor 3.4), and noticed that before sending the http request, there is a bunch of garbage in my string:
C8 D7 19 87 09 1C C8 60 00 13 8C FA 08 00 45 00 00 C3 37 78 40 00 80 06 00 00 C0 A8 01 71 17 17 5C 67 C2 4F 01 BB 06 1A 36 71 A2 8B 48 C7 50 18 04 00 36 4D 00 00 47 45 54 20 2F 20 48 54 54 50 2F 31 2E 31 0D 0A 53 65 63 2D 57 65 62 53 6F 63 6B 65 74 2D 4B 65 79 3A 20 76 46 46 30 4F 4C 2F 55 63 53 49 6E 6F 70 46 67 52 69 6F 52 73 77 3D 3D 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 55 70 67 72 61 64 65 0D 0A 55 70 67 72 61 64 65 3A 20 57 65 62 73 6F 63 6B 65 74 0D 0A 53 65 63 2D 57 65 62 53 6F 63 6B 65 74 2D 56 65 72 73 69 6F 6E 3A 20 31 33 0D 0A 48 6F 73 74 3A 20 32 33 2E 32 33 2E 39 32 2E 31 30 33 3A 34 34 33 0D 0A 0D 0A
È×.‡..È`..Œú..E..Ã7x#.€...À¨.q..\gÂO.»..6q¢‹HÇP...6M..GET / HTTP/1.1..Sec-WebSocket-Key: vFF0OL/UcSInopFgRioRsw==..Connection: Upgrade..Upgrade: Websocket..Sec-WebSocket-Version: 13..Host: 192.168.1.1:443.... (the dots are \r\n in most cases)
Although I am using port 443, this is not a secured websocket - I am forced to use 443 because some smart phones only allow websockets to create socket connections on that port.
In C++, I am creating the websocket like so:
void Websocket::Connect(Platform::String ^host)
{
if ( this->socket != nullptr ) return;
try
{
Uri^ address = ref new Uri(host);
readBuffer = ref new Buffer(1000);
this->socket = ref new MessageWebSocket();
this->socket->Control->MessageType = SocketMessageType::Utf8;
this->socket->Control->MaxMessageSize = 512;
this->socket->Closed += ref new TypedEventHandler<IWebSocket^, WebSocketClosedEventArgs^>( this, &Websocket::ServerClosed );
this->socket->MessageReceived += ref new TypedEventHandler<MessageWebSocket^, MessageWebSocketMessageReceivedEventArgs^>( this, &Websocket::MessageRecv );
create_task(this->socket->ConnectAsync(address)).then([this](task<void> previousTask)
{
try
{
concurrency::task_status status = previousTask.wait();
switch( status ) {
case concurrency::task_status::completed:
this->connected = true;
break;
default:
socketErrorString = ref new Platform::String( L"Connection was cancelled" );
}
}
catch(Exception^ exception)
{
this->connected = false;
socketErrorString = ref new Platform::String( exception->Message->Data() );
this->socket = nullptr;
} catch( ... ) {
this->connected = false;
socketErrorString = ref new Platform::String( L"Unknown exception caught (inside connect)" );
this->socket = nullptr;
}
});
} catch( Exception ^exc ) {
this->connected = false;
socketErrorString = exc->Message; //ref new Platform::String( L"Unknown exception caught (outside connect)" );
this->socket = nullptr;
}
}
I can't see any sort of issue in the code, so I was hoping a few other sets of eyes may be able to. Thanks.

Answer 1

What you've pasted appears to be an Ethernet frame, but with 8 bytes stripped (7-byte preamble and 1-byte Start Frame Delimiter) because the network interface doesn't receive it.
The first fourteen bytes are the Ethernet header: 6 bytes for the destination MAC address, 6 bytes for the source MAC address, and 2 bytes for the EtherType, with 08 00 denoting that it is IPv4 packet.
The Ethernet payload follows the Ethernet header and, in this case, is an IP datagram, so it starts with an IP header at offset 14 with byte 45 denoting an IPv4 header with a header length of 20 bytes. At offset 23 you'll find the IP protocol of 06 denoting TCP. At offset 26 you'll find the source IP address (C0 A8 01 71, i.e. 192.168.1.113). At offset 30 you'll find the destination IP address.
The IP payload follows the IP header, and, in this case, it is a TCP segment starting with a TCP header at offset 34 with bytes C2 4F denoting a source port of 49743 and bytes 01 BB denoting a destination port of 443. At offset 46 you have 50 denoting a TCP header length of 20 bytes.
The TCP payload follows the TCP header, and, in this case, is HTTP starting at offset 54 with bytes 47 45 54 ... being "GET...".
This request packet appears to be wellformed. I believe your problem lies elsewhere.