r228732 | glebius | 2011-12-20 16:34:16 +0400 (вт, 20 дек 2011) | 3 lines

- Cover pfsync callouts deletion with PF_LOCK().
- Cover setting up interface between pf and pfsync with PF_LOCK().

r228811 | glebius | 2011-12-22 22:31:47 +0400 (чт, 22 дек 2011) | 3 lines

In FreeBSD we always have bpf(4) API, either real or stub. No need
in detecting presense of 'device bpf'.

r228813 | glebius | 2011-12-22 22:51:35 +0400 (чт, 22 дек 2011) | 2 lines

We really mean MTU of the real interface here, not of our pseudo.

r228814 | glebius | 2011-12-22 22:56:27 +0400 (чт, 22 дек 2011) | 16 lines

Merge couple more fixes from OpenBSD to bulk processing:

  revision 1.118
  date: 2009/03/23 06:19:59;  author: dlg;  state: Exp;  lines: +8 -6
  wait an appropriate amount of time before giving up on a bulk update,
  rather than giving up after a hardcoded 5 seconds (which is generally much
  too short an interval for a bulk update).
  pointed out by david@, eyeballed by mcbride@

  revision 1.171
  date: 2011/10/31 22:02:52;  author: mikeb;  state: Exp;  lines: +2 -1
  Don't forget to cancel bulk update failure timeout when destroying an
  interface.  Problem report and fix from Erik Lax, thanks!

Start a brief note of revisions merged from OpenBSD.

r228815 | glebius | 2011-12-22 23:05:58 +0400 (чт, 22 дек 2011) | 12 lines

Merge from OpenBSD:
  revision 1.120
  date: 2009/04/04 13:09:29;  author: dlg;  state: Exp;  lines: +5 -5
  use time_uptime instead of time_second internally. time_uptime isnt
  affected by adjusting the clock.

  revision 1.175
  date: 2011/11/25 12:52:10;  author: dlg;  state: Exp;  lines: +3 -3
  use time_uptime to set state creation values as time_second can be
  skewed at runtime by things like date(1) and ntpd. time_uptime is
  monotonic and therefore more useful to compare against.

r228816 | glebius | 2011-12-22 23:09:55 +0400 (чт, 22 дек 2011) | 11 lines

Merge from OpenBSD:
  revision 1.122
  date: 2009/05/13 01:01:34;  author: dlg;  state: Exp;  lines: +6 -4
  only keep track of the number of updates on tcp connections. state sync on
  all the other protocols is simply pushing the timeouts along which has a
  resolution of 1 second, so it isnt going to be hurt by pfsync taking up
  to a second to send it over.

  keep track of updates on tcp still though, their windows need constant
  attention.