TCP programming with .NET

views:

119

answers:

TCP programming with .NET

Hey,

I'm having an issue with a socket programming job. I wrote a TCP client that sends commands via sockets/networkstream. I'm using Wireshark to look at the raw data that goes through the wires. Everytime I send a "command" (meaning I Flush() the networkstream), the Wireshark application tells me that the checksum in the TCP Header is incorrect (says "it should be 0x2440, but is 0x0000). I do get an ACK back. I don't understand why at the application layer I would have to care about the TCP header. That can't be right. Would anyone know why I am getting this "error". Is there a setting I'm not aware of? I'm using .NET 2.0 sockets with Tcp. Thank you.

+6 A:

Are you looking at a Wireshark dump from the machine that is sending the data? If so, it may just be that the checksum hasn't been calculated at the point in the stack where Wireshark is seeing it. Many network cards these days have TCP Checksum Offload, where the checksum is done by hardware, and so the checksum field will be zero on the way out (Wireshark gets the packet just before it is sent to the hardware). Since you're getting ACKs, the receiving end is clearly cool with it. Also, if you're talking to localhost, your stack may not be bothering with checksums at all (they aren't strictly necessary for a host talking to itself).

Andrew McGregor 2010-02-03 07:03:46

Thanks for the explanation. I didn't know that. Since you're familiar with that stuff, can I ask how I can use Wireshark to make sense of the byte stream that is sent? According to the proprietary protocol I'm implementing the packets contain text. But when I try to decode the packets I only get gibberish. Thanks again.

John 2010-02-03 07:12:19

@John: Without knowing which protocol you're looking at, we can't really tell. If you do "Follow TCP stream" in Wireshark, does it not show you any useful data?

Jon Skeet 2010-02-03 07:14:16

@Jon: this is standard TCP streaming. Does "Follow TCP Stream" glue the packets back together somehow. The data I'm supposed to receive is a plain text file. I will look into Wireshark more. Thanks.

John 2010-02-03 07:25:16

Follow TCP Stream gives you a transcript of what the protocol did on the socket (in both directions). You should see any control exchange at the beginning, followed by whatever the data was.

Andrew McGregor 2010-02-03 07:31:15

In my case each packet I recieve starts with a DLE,STX and ends with a DLE,ETX, CRC, CRC (2 bytes checksum). Everything in between is data (ASCII text). The byte stream still shows up as binary gibberish in Wireshark. Can I convince it to make sense of the data by, for instance, dumping the head and tail and glueing the data (text) back together? Of would "follow tcp stream" show me the plain text somehow? Thanks.

John 2010-02-03 12:47:38

You could write your own wireshark disector plugin for your protocol, then it would decode it however you want it to... They're not that hard to write and can save lots of time if you need to look at your protocol for any length of time...

Len Holgate 2010-02-03 17:56:49

Follow TCP stream will show you the stream of bytes that went through that connection. There will still be gibberish on the beginning and end, but you should be able to simply cut-and-paste the text out from the middle. Or yes, you could write a dissector, that would extract the text, and you could even have it check the CRCs.

Andrew McGregor 2010-02-03 22:39:03

ansaurus

tags:

views:

answers:

TCP programming with .NET

related questions