Hi,
I have committed a patch to -current which refactors the six ways that PF
finds TCP options into one new function.
I expect no side-effects, and the minor changes to finding MSS and WSCALE
options that this involved were immaterial to the large sample of live
traffic that I've examined.
Hi,
I found this witness log on my computestick but not here.
I was doing little at the time besides using emacs and some vanilla
chrome and possibly firefox. Hope it's of use.
cheers,
Richard.
OpenBSD 6.3-current (GENERIC.MP) #10: Mon Jun 11 14:02:36 NZST 2018
On Wed, 13 Jun 2018, richard.n.proc...@gmail.com wrote:
> I found this witness log on my computestick but not here.
>
> OpenBSD 6.3-current (GENERIC.MP) #10: Mon Jun 11 14:02:36 NZST 2018
> procter@dill.internal:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>
> (CVS checkout on this date,
On Tue, 6 Feb 2018, Theo Buehler wrote:
> In cleanup_url_get, fin and s will be closed a second time, so mark them
> as invalid after closing them the first time.
>
> Another option might be to remove the fclose/close calls, but since this
> happens right before the recursive call, I'm not
On Tue, 6 Feb 2018, Alexander Bluhm wrote:
> On Tue, Feb 06, 2018 at 11:04:51AM +1300, Richard Procter wrote:
> > > @@ -657,12 +667,13 @@ ah_input(struct mbuf *m, struct tdb *tdb
> > > m_copyback(m, skip + rplen, ahx->authsize, ipseczeroes, M_NOWAIT);
> > >
> > > /* "Massage" the packet
Hi Stefan,
On Wed, 14 Aug 2019, Stefan Sperling wrote:
> On Tue, Aug 13, 2019 at 10:47:24AM -0300, Martin Pieuchot wrote:
> > if the crash is because of a missing key, put one :)
>
> Yes, you've convinced me. With this patch we install the CCMP key
> to both firmware and net80211. Until
On Thu, 15 Aug 2019, richard.n.proc...@gmail.com wrote:
> Hi Stefan,
>
> On Wed, 14 Aug 2019, Stefan Sperling wrote:
>
> > On Tue, Aug 13, 2019 at 10:47:24AM -0300, Martin Pieuchot wrote:
> > > if the crash is because of a missing key, put one :)
> >
> > Yes, you've convinced me. With this
On Thu, 15 Aug 2019, Stefan Sperling wrote:
> On Thu, Aug 15, 2019 at 03:47:02PM +1200, richard.n.proc...@gmail.com wrote:
> > > I agree we should handle a missing key but suggest an alternative
> > > approach
> > > below.
>
> Hmm... your patch is surprisingly simple. I like it :)
>
> I am
On Fri, 30 Aug 2019, Stefan Sperling wrote:
> I would like to try this again: In iwm(4), process more than one frame
> per Rx interrupt, and enable monitor mode.
>
> Monitor mode triggers "unhandled fimware response" errors without multi-Rx
> support. We have seen these infamous errors in other
Hi,
dlg@ pointed out what looks to be a spurious call in the bridge to
in_proto_cksum_out(). I've checked the stack and found eight such calls
I think can be safely removed.
in_proto_cksum_out() computes, for packets flagged as needing it, the
transport checksum. It skips if the output
Hi,
npppd(8) and pipex(4) can clamp TCP MSS independently of pf(4)
and so tweak the TCP checksum, too.
Substitute pf's algorithm to reduce the diversity of checksum-tweaking
algorithms in the tree.
Compiled but untested.
oks or test reports welcome (enable mss clamping by adding
Hi,
PF supports 'one shot rules'. Quoting pf.conf(5) "once - Creates a one
shot rule that will remove itself from an active ruleset after the first
match."
I'd like to simplify pf by removing them, unless there's a compelling
reason not to.
Particularly as there is no 'first match' under
On Sat, 25 Jan 2020, Claudio Jeker wrote:
> Adam Thompson reported a bgpd crash he sees in 6.6. Using
> kern.nosuidcoredump=3 he was able to get me a back trace of the crash.
> The RDE chokes on the TAILQ_REMOVE in nexthop_runner() which indicates
> that the nexthop_runners list gets
Hi,
This implements ping(1)-like summary statistics for tcpbench(1), e.g.
^C
--- localhost tcpbench statistics ---
1099642814 bytes sent over 4.126 seconds
bandwidth min/avg/max/std-dev = 1228.131/2117.309/2491.399/517.779 Mbps
The std-dev especially would have helped me catch a TCP
On Fri, 1 May 2020, j...@bitminer.ca wrote:
> > From: richard.n.procter () gmail ! com
> > This implements ping(1)-like summary statistics for tcpbench(1), e.g.
> >
> > ^C
> > --- localhost tcpbench statistics ---
> > 1099642814 bytes sent over 4.126 seconds
> > bandwidth min/avg/max/std-dev =
On Sat, 2 May 2020, j...@bitminer.ca wrote:
> A couple of further questions embedded:
>
> A question on the std-dev -- is this for "n" measures as defined
> by -r interval? "ping" reports an N packets transmitted. Maybe
> this is obvious but your revised manpage doesn't say. Could this
>
Hi Jason,
On 27/06/2020, at 10:09 PM, Jason A. Donenfeld wrote:
> [...] I thought I'd lay out my understanding of the matter,
> and you can let me know whether or not this corresponds with what you
> had in mind:
> [...]
My main concern is the end-to-end TCP or UDP transport checksum of the
Hi,
On its receive path, wg(4) uses the same mbuf for both the encrypted
capsule and its encapsulated packet, which it passes up to the stack. We
must therefore clear this mbuf's checksum status flags, as although the
capsule may have been subject to hardware offload, its encapsulated packet
Hi,
Thanks for the background.
I'm ok with your latest diff as-is. I prefer a slightly different
direction, see below, but not enough to object.
On Mon, 1 Feb 2021, Alexander Bluhm wrote:
> On Mon, Feb 01, 2021 at 08:08:56AM +1300, Richard Procter wrote:
> > - Might the rule disabling
19 matches
Mail list logo
