> Offhand I'd say this has nothing to do with truncation, since the
> truncated packet shouldn't be included in the clean pcap file. My guess
> would be that you've found a bug in one of ethereal's protocol dissectors.
Jefferson,
I finally got a chance to work on this. You are correct, there was
On Thu, Mar 30, 2006 at 12:17:47PM +0200, Debrei Gabor wrote:
>
>
> Hello!
>
> We want to compare 802.11 MAC schedulers performance, to decide
> how much the Media Access takes.
Many 802.11 MACs put a microsecond timestamp on received frames.
Some wireless drivers in *BSD will load that timest
Hi,
> We want to know where/when does PCAP put the timestamp (from not
> so accurate kernel time) on to the packets. I already know, it does
> when the kernel "sees" the packet. The question is: Is it after or before
> the MAC scheduler? I mean, does it in TR or RX buffers or at higher
> pro
On Thu, Mar 30, 2006 at 12:17:47PM +0200, Debrei Gabor wrote:
> We want to compare 802.11 MAC schedulers performance, to decide
> how much the Media Access takes.
>
> We want to know where/when does PCAP put the timestamp (from not
> so accurate kernel time) on to the packets. I already know, i
Hello!
We want to compare 802.11 MAC schedulers performance, to decide
how much the Media Access takes.
We want to know where/when does PCAP put the timestamp (from not
so accurate kernel time) on to the packets. I already know, it does
when the kernel "sees" the packet. The question is: Is