RE: [PATCH] Add ioctl to disable bpf timestamping

From: Ed Maste (emaste_at_sandvine.com)
Date: 09/08/04

  • Next message: Forrest Aldrich: "Re: VoIP and IPFW"
    Date: Wed, 8 Sep 2004 11:40:17 -0400
    To: <freebsd-net@FreeBSD.org>, <tcpdump-workers@tcpdump.org>
    
    

    BMS wrote:
    > Here's a patch against 5.3 to add a per-instance switch which allows
    > the user to specify if captured packets should be timestamped (and,
    > if so, whether microtime() or the faster but less accurate
    > getmicrotime() call should be used).

    We've implemented this internally on 4.7, and have seen quite
    impressive results. I have a test case that sends 512 byte
    packets and has the snap length set to get the whole packet.
    Using microtime(), I am able to get about 120 kpps to my test
    app. With no timestamp I can get 200 kpps. Without context
    the absolute numbers don't mean much but the relative
    improvement is quite impressive.

    Guy Helmer wrote:
    > I like the idea (I've been using a hack to call getmicrotime()
    > in bpf in my own kernels), but I wonder if it would be better as a
    > sysctl? Then it wouldn't require changes to libpcap and/or tcpdump,
    > and would work with any application.

    I think an ioctl is the right way to do it, since you could have
    multiple BPF listeners with different requirements. For example,
    realtime inspection like Snort may not care about timestamps while
    manual inspection with tcpdump would.

    One way to allow the user to control this behaviour on a per-
    application basis would be to have libpcap check an env var in
    order to decide if the ioctl should be set.

    Ed Maste
    Sandvine Inc.
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"


  • Next message: Forrest Aldrich: "Re: VoIP and IPFW"

    Relevant Pages

    • [REVS] TCP Timestamp and Advanced Fingerprinting
      ... The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com ... current and average uptime of specific operating systems running on the ... By grabbing the value of timestamp of such operating system ... TCP timestamps values are inserted in many TCP packets (such as SYN, ...
      (Securiteam)
    • Re: time stamping 802.11n miniport tx packets
      ... NdisGetCurrentSystemTimefunction should be used to timestamp packets. ... However the documentation also indicates that NdisGetCurrentSystemTimeis ... Can a miniport driver make this call and still pass WHQL? ...
      (microsoft.public.development.device.drivers)
    • TCP timestamp & advanced fingerprinting
      ... attached is a paper from one of our students about using the TCP ... analysis of various operating systems should reveal how analyzing timestamps ... the timestamp value of one point each 500 milliseconds. ... value in their SYN packets, but Windows-based operating systems does not. ...
      (Bugtraq)
    • Re: cwnd and sstresh monitor
      ... (kernel patch, kernel module, etc?), and how would this be done best? ... but there is a TCPDEBUG kernel option that gathers TCP state information for debugging and tracing purposes. ... I also modified the iptimefunction to provide microsecond resolution instead of miliseconds, because most of the packets have the same timestamp attached. ...
      (freebsd-hackers)
    • Re: Miniports IOCTL interface performance issue.
      ... note that aggressive interrupt coalescing can hurt latency. ... NetXtreme Longhorn Miniport Prime ... > A similar problem arose years ago when the number of packets per second ... >> packets from a usermode application via Direct IOCTL interface. ...
      (microsoft.public.development.device.drivers)