This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Failed at emulating browser’s packets

Hi,

I'm writing a program with raw-sockets and i'm trying to emulate my browser's "syn" packets to a socks server. My program's packets and my browser's packets are almost alike, but the socks server answers only my browser's packets and not my generated packets. My browser sends 5 or 3 syns (with no or very little delay between each of them), and then the socks server sends the "syn,ack" packet. The only difference between the browsers packets and mine is the timestamp in the TCP layer.

Can anyone help me with that? I can provide a packet file if necessary. Thanks :)

raw socket socks packet wireshark

asked 20 Nov '10, 09:09

toothpick
1●1●1●1
accept rate: 0%

I guess you'll have to provide traces for both connections, browser and your raw socket, maybe someone can spot the difference that makes the socks server go stubborn and not answering your SYN packet... Do you have a download location?

(20 Nov '10, 11:32) Jasper ♦♦

2 Answers:

Ok, I compared your traces and the only thing that seems to be "off" in the raw socket version is that the TCP checksum is not correct. This is something that could be a result of TCP Checksum offloading (which is why many people turn off TCP checksum validation in Wireshark), but I think it is the problem in this case. Here's why:

your browser trace shows that the SYN packets have a correct TCP checksum
your raw socket trace shows that the SYN packets have an incorrect TCP checksum
that means that your checksum is not always incorrect, so probably you do not have TCP checksum offloading trouble
if we assume your computer is usually sending correct TCP checksums for "normal" browser communication and your raw socket communication doesn't, we can assume (with just some doubt, see last paragraph) that
your raw socket program calculates the TCP checksum incorrectly and thus
the incorrect checksum is transmitted to the server which then will
drop the packet because it has to assume it is damaged and
not reply with a SYN/ACK

I hope this makes sense to you. Steps to take are:

capture your computer's traffic with another passive computer to verify if incorrect checksums are in fact sent out the NIC for your raw socket program
if it turns out they are, you have to
fix the raw socket program

If your raw socket program does in fact calculate correct TCP checksums and Wireshark only says they're wrong because of checksum offloading I can't tell why your packets aren't answered, since everything else looks pretty much the same as the browser's packets.

answered 04 Dec '10, 13:52

Jasper ♦♦
23.8k●5●51●284
accept rate: 18%

yes, here are the traces of both my program and the browser.

http://rapidshare.com/files/434905180/my-packets http://rapidshare.com/files/434905209/browser

my wireshark saved those files without extension, but I guess they are .cap files.

answered 04 Dec '10, 11:51

toothpick
1●1●1●1
accept rate: 0%