有人有 *.pcap 操作库的经验吗?
我正在使用 SharpPcap + PacketDotNet 库来处理一些 .pcap 文件,并在计算时间戳的方式中遇到了错误。
采用这个 Timeval 属性,它是这样的:
PosixTimeval Timeval
{
DateTime Date;
ulong Seconds;
ulong MicroSeconds;
}
问题如下:假设您在 Wireshark 中打开了一个跟踪,其中一个数据包的时间戳为“0.002”。一旦您在某个程序中打开它,它就会检索数据包并设置其 Timeval,以便 Seconds = 0
和 MicroSeconds = 002 = 2
。这是在幕后完成的,所以据我所知,没有办法避免它。
我的问题是,这个问题对于其他操作 pcap 文件格式的库(也许是所有库?)来说是否是常见的,我认为这些文件格式是围绕相同的 c/c++ 函数集合构建的,或者如果这只是与我正在使用的。
I'm using the SharpPcap + PacketDotNet libraries to process some .pcap files and came across a bug in the way the timestamps are calculated.
Take this Timeval property, which is something along these lines:
PosixTimeval Timeval
{
DateTime Date;
ulong Seconds;
ulong MicroSeconds;
}
The problem is as follows: Suppose you have a trace open in Wireshark with one of the packets with a timestamp of "0.002". Once you open it within one of your programs, it retrieves the packet and its Timeval is setup such that Seconds = 0
and MicroSeconds = 002 = 2
. This is done under the hood, so there is no way to avoid it as far as I can tell.
My question is if that problem is common to other libraries (and maybe all of them?) who manipulate the pcap file format, which I think are built around the same collection of c/c++ functions, or if this is a problem only with the ones I'm using.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我是 Sharppcap/packet.net 的作者。
您在时间戳值中看到的错误是什么?您提到的转换似乎是正确的。 0.002 秒是 2 毫秒。
时间戳值应该是捕获数据包时的完整 unix timeval。当然,0.002 的 timeval 作为绝对时间没有意义,而只是相对时间。
如果还没有,我将向 Sharppcap 添加一个单元测试来验证数据包时间。
I'm the author of sharppcap/packet.net.
What is the bug that you are seeing with the timestamp values? The conversion you mentioned seems correct. 0.002 seconds is 2 milliseconds.
The timestamp values should be the full unix timeval when the packet was captured. Certainly a timeval of 0.002 doesn't make sense as an absolute time, only a relative one.
I'll add a unit test to sharppcap to validate the packet timeval if there isn't one already.