cvs commit: src/sys/net bpf.c

[Jung-uk Kim]

On Tuesday 25 July 2006 12:18 pm, Sam Leffler wrote:
> Jung-uk Kim wrote:
> > On Monday 24 July 2006 08:52 pm, Sam Leffler wrote:
> >> Jung-uk Kim wrote:
> >>> On Monday 24 July 2006 01:38 pm, David Malone wrote:
> >>>>> Thanks for taking care of this! It is not very desirable for
> >>>>> the same packet to have different timestamps associated with
> >>>>> it across different bpf peers. It certainly could cause a
> >>>>> problem if people are using timestamps to correlate events
> >>>>> from different programs on the same system.
> >>>>
> >>>> Indeed - calling microtime more than necessary and generating
> >>>> inconsistent timestamps just didn't seem good.
> >>>>
> >>>> I think jkim@ has interesting work related to this that might
> >>>> allow us to exploit hardware that does hardware timestamping
> >>>> of packets. It is some way down the road though.
> >>>
> >>> Darn, I guess I have to finish the work now since you said it.
> >>> ;-) The idea is simply to pass timeval to bpf_tap() from
> >>> network drivers when it is available and bpf is attached. 
> >>> (Something like bpf_*tap_ts()?)   Additionally we may add an
> >>> ioctl for bpf to select timestamping method, e.g.,
> >>> microtime(9),
> >>> getmicrotime(9), timestamping from lower layer, or no
> >>> timestamping at all because we don't need (accurate) timestamps
> >>> in many places.  For the hardware-based accurate timestamping,
> >>> the big challenge is actually timecounter to timeval
> >>> conversion, not the bpf API itself because we can only select
> >>> one hardware timecounter at a given time if the controller does
> >>> not give us timeval, bintime, or something similar. We have to
> >>> come up with some API to register additional timecounter, which
> >>> is not primary timecounter but synchronized with system uptime.
> >>> On top of that, the timecounter in the given descriptor is not
> >>> current timecounter.  So we need 'what time was it then', not
> >>> 'what time is it now.'
> >>
> >> Why not leverage something like radiotap?  It already has a
> >> mechanism for associating a 64-bit microsecond timestamp w/ each
> >> packet.  It's presently somewhat wireless-oriented but could be
> >> used w/ wired devices too and tools like ethereal and tcpdump
> >> already grok it.
> >
> > Yes, we can do that but I see at least two immediate problems. 
> > First we still call microtime(9) from catchpacket() (or from
> > bpf_mtap2(9) now) because bpf does not know anything about this
> > *special* header. It surely beats the purpose.  Second, libpcap
> > has to be modified to understand the header format and the trace
> > will be incompatible with old apps.  AFAIK, this means they have
> > to introduce another DLT for each supported DLT just because we
> > added the timestamp, which is impractical IMHO.  Basically I want
> > something more generic. :-)
>
> bpf should not need to know anything.  If you want a common routine
> to build the radiotap header that's easy.  bpf_mtap2 already works
> fine to capture radiotap encapsulated frames for wireless.

I know it works because I use it occasionally. :-) My point was it 
still calls microtime() because it doesn't know it is already 
timestamped.  We need to turn it off, manually or automatically.  If 
we want to do it automatically, bpf_mtap2(9) has to know whether it 
is timestamped already or not, e.g., additional flag in bpf 
descriptor.  Actually, I want both manual (via ioctl) and automatic 
(via bpf descriptor flag).

> libpcap does not need to be modified; it works already for
> wireless. The fact that the DLT is named DLT_IEEE802_11_RADIO is a
> bit of a misnomer; it's not entirely 802.11-specific.

Ah, you mean we just exploit DLT_IEEE802_11_RADIO.  Hmm...  How about 
processing overhead?  Can we synchronize the timestamping with system 
time?

> There is no incompatibility w/ old apps.  If old apps don't set the
> DLT they get the old format.  If they set the DLT to get radiotap
> then presumably they've also been modified to extract the
> timestamp.

Okay.  But I am worried about timecounter <-> timeval conversion 
because I want to know timeval delta from system time, not just some 
timer value.

> Take a look first please.  It may not be appropriate but I think
> what you want is already there.

Sure I will.

Thanks!

Jung-uk Kim