Thanks for your reply! But I was trying to measure the time difference between the SYN and SYN-ACK. Even though it may not be exactly accurate but getting packets out-of-order makes the whole idea moot.
On Friday, July 28, 2017 at 2:26:28 AM UTC-4, feilengcui008 wrote: > > Not sure whether understand your need, but if your need is the reassembly > of TCP packets, you can use the tcpassembly packet in gopacket, I recently > used it in my traffic replay project tcplayer > <https://github.com/feilengcui008/tcplayer>, it seems working just fine. > > 在 2017年7月28日星期五 UTC+8上午5:20:05，Chun Zhang写道： >> >> Hi, All, >> >> I am trying to write a small program to sniff packets off the wire. These >> packets are most TCP flows, so I'd expect SYN arrives earlier than SYN-ACK, >> ACK etc. >> >> I used gopacket and basically followed the official guide to get the >> packet and then read its metadata for timing. But to my surprise, there >> were a few SYN-ACKs arrived before the SYNs, which did not make any sense. >> I used only one goroutine, and locked it to os thread. >> >> Then I tried tcpdump and checked the pcap, same thing happened, even >> though much less abnormalities showed up. >> >> As far as my understanding goes, the packet is timestamped when it is >> read off the wire, so, when the following line is executed, the packet is >> already timestamped and decoded >> >> packet, err := packetSource.NextPacket() >> >> >> >> That seems to suggest that libpcap is ultimately the one that is >> responsible for the stamping. If things go wrong, then most likely it is >> libpcap or something between libdpi and the above line. But given that >> tcpdump also has the same issue, I feel that libpcap is more suspicious. >> >> The only other suspect is that I enabled lazy and NoCopy option for the >> packetSource, not sure whether that plays a role here. >> >> So, the question is anybody has encountered this issue? If so, have you >> tried to improve its timing accuracy? Is there anything else that I can do >> to remedy the issue? Even though the host machine is multi-core, >> muti-thread, but I have locked the reading goroutine to one particular >> os.thread, so technically, that should not be a factor anymore, correct? >> >> PS: I have used IXIA to capture the packets, and there were no >> out-of-order SYN and SYN-ACK. So the device is reliably sending these >> packets up. >> >> Thanks, >> Chun >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
