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 golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
