Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Doesn't work at all with Vista? #5

Open
ovidkafka opened this issue Feb 7, 2011 · 4 comments
Open

Doesn't work at all with Vista? #5

ovidkafka opened this issue Feb 7, 2011 · 4 comments

Comments

@ovidkafka
Copy link

Attempting to use tcpcrypt to access any web site under Windows Vista SP2 does not work. It just times out.

Running tcpcryptd with verbose output yields e.g.

Added ARP entry for 171.66.3.211 [00:13:46:f4:d4:fc] table size 1
Gotta malloc 40

192.168.36.6:49174->171.66.3.211:80 52 S [out] tc 000236D8
Can't find session for host

192.168.36.6:49174->171.66.3.211:80 52 S [out] tc 000236D8
Can't find session for host

192.168.36.6:49174->171.66.3.211:80 48 S [out] tc 000236D8
Can't find session for host

The above is for accessing tcpcrypt.org but no web sites, whether supporting tcpcrypt or not, are accessible until I turn off tcpcrypt.

Any ideas what's going wrong?

@sqs
Copy link
Collaborator

sqs commented Feb 7, 2011

Thanks for this report, too. Are you running the Windows GUI app or the Windows command-line executable? Can you send over a dump of the network traffic using something like http://www.winpcap.org/windump/ (never used it before, but it looks similar to tcpdump)?

@ovidkafka
Copy link
Author

Initially I was just using the Windows GUI app to start the daemon. When that wasn't working at all, I fished around and decided to run it manually, which is how I obtained the above trace info. However the result was the same (connection not possible).

I'll see about getting a dump.

@ovidkafka
Copy link
Author

I think the problem is IP checksum offload.

(using windump)Coming in to tcpcryptd the IP header checksum is 0000. In routine set_ip_len you carefully adjust the checksum in order to account for the changing IP total length field, which leaves a bogus non-zero value in the checksum. Ideally you would interrogate the OS to find out whether IP header checksum offload is enabled (on transmit) and if so leave the 0000 untouched.

To test this hypothesis, I (temporarily!) disabled IP checksum offload in my NIC - and now I can more or less use tcpcrypt on the Vista PC.

Theoretically Windows XP is supposed to be able to use IP checksum offload so perhaps this is not a Vista problem as such but rather a reflection of the different network hardware on the two PCs.

Similar issues might exist with the TCP checksum but for reasons unknown to me that appears to be filled in on entry to tcpcryptd.

@sqs
Copy link
Collaborator

sqs commented May 4, 2011

Thanks for identifying the bug here. We're much slower to fix the Windows bugs than Linux/Mac/FreeBSD bugs, but I'll leave this open for when we do get around to it (or someone else submits a patch).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants