#Ip checksum windows#

The output from wireshark is only two packtes with verbose packet information, but with every SYN packet that comes in from the client, the server tries to reply with a SYN,ACK but it fails, so those two packets are the ones I have provided, and you can imagine they just repeat over and over until the connection times out :-) The service is a Windows Service application, and the client is an ASP.NET Web application, just FYI. Below I have pasted my WCF configurations and an output from wireshark. I wanted to provide additional information/proof. I really appreciate any help or advice that could be given! This just sounds like a very fundamental problem for WCF to be having. It's failing at the lowest and earliest stage of communication. This entire setup works perfectly fine when the client and the service are running on the same machine (my Vista development box), but when I deploy it to my Windows Server 2003 servers, it doesn't work. Every single one of them! The reason is because of a bad IP header checksum where the value is 0x00 instead of being 0x5338 (for example).ĭoes anyone have any clue what could be wrong? There's nothing abnormal about my setup.I'm using standard netTcpBinding w/ reliableSessions enabled and ordered. From the service side, SYN packets come in from the client, and SYN ACK packets try to go out from the service, but they are marked as bad packets.

From the client side, SYN packets are sent out to the service, but nothing comes back in from the service. I installed Wireshark and did packet capturing on both the client and the server when the WCF message is sent.

Here's some background information: Both systems are having zero network/internet connectivity issue, and both systems have no firewall installed. The client and the service are both running on Windows Server 2003 R2 SP2 w/. I also have a client that's on a different computer that's trying to connect to the service. This problem is very strange, and it's killing me! I have a WCF ServiceHost using netTcpBinding and successfully listening on port 21435 (netstat shows it in the listening state).

Ip checksum