[Oisf-users] hardware timestamping with af-packet/suricata

[jason taylor]

Issue #1954 has been created for this feature.

Thank you everyone for your feedback.

JT

On Sun, 2016-11-13 at 14:10 -0500, Michał Purzyński wrote:
> Given how the hardware timestamps are sometimes constructed, I'd say,
> let's give users a choice 
> 
> > 
> > On 13 Nov 2016, at 13:44, jason taylor <jtfas90 at gmail.com> wrote:
> > 
> > Hi Michal,
> > 
> > I have not opened a ticket yet. I wanted to make sure this wasn't
> > an
> > edge case type request/situation before I opened one.
> > 
> > JT
> > 
> > > 
> > > On Sun, 2016-11-13 at 13:06 -0500, Michał Purzyński wrote:
> > > We should, by all means, support a choice here and give users an
> > > option what they want to do. I'm filing a similar bug for bro
> > > now.
> > > 
> > > Have you opened Suricata by already?
> > > 
> > > > 
> > > > 
> > > > On 11 Nov 2016, at 11:31, jason taylor <jtfas90 at gmail.com>
> > > > wrote:
> > > > 
> > > > After talking with Victor a little bit at the conference he
> > > > suggested
> > > > seeing what others have to say.
> > > > 
> > > > In our environment we recently discovered an issue related to
> > > > hardware
> > > > timestamping. 
> > > > 
> > > > After a period of time post NIC driver load, we will see a
> > > > drift
> > > > forward and/or back in time. The forward or back is depedant on
> > > > the
> > > > frequency of the chip on the NIC. In our case we have 10g and
> > > > 40g
> > > > cards
> > > > we see the issue with. This results in our suricata alerts
> > > > being
> > > > stamped with the errant time since suricata/af-packet uses
> > > > hardware
> > > > timestamping if it's available.
> > > > 
> > > > Looking into possible solutions while waiting on a response
> > > > from
> > > > the
> > > > vendor I noted that netsniff-ng also by default uses hardware
> > > > timestamping but added a --no-hwtimestamp runtime option to
> > > > account
> > > > for
> > > > situations where hardware timestamping is buggy or what have
> > > > you.
> > > > 
> > > > While realizing this isn't a suricata issue, (we should have
> > > > chosen
> > > > our
> > > > hardware a bit more carefully). Aside from hardware/driver
> > > > issues
> > > > are
> > > > there other situations where one might want to disable hardware
> > > > timestamping at runtime (.e.g. --no-hwtimestamp) in suricata?
> > > > Is
> > > > this
> > > > something that would be worth adding as a configuration option
> > > > in
> > > > suricata?
> > > > 
> > > > TIA,
> > > > 
> > > > JT
> > > > 
> > > > _______________________________________________
> > > > Suricata IDS Users mailing list: oisf-users at openinfosecfoundati
> > > > on.o
> > > > rg
> > > > Site: http://suricata-ids.org | Support: http://suricata-
> > > > ids.org/support/
> > > > List: https://lists.openinfosecfoundation.org/mailman/listinfo/
> > > > oisf
> > > > -users
> > > > Suricata User Conference November 9-11 in Washington, DC: http:
> > > > //su
> > > > ricon.net
> >