PF: minor changes to TCP option parsing

2018-06-18 Thread richard . n . procter
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.

witness report: vmmaplk, inode

2018-06-12 Thread richard . n . procter
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

Re: witness report: vmmaplk, inode

2018-06-13 Thread richard . n . procter
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,

Re: ftp: don't close fin or s twice

2018-02-05 Thread richard . n . procter
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

Re: ipsec ah_massage_headers cleanup

2018-02-07 Thread richard . n . procter
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

Re: iwm(4): fix ccmp decrypt edge cases

2019-08-14 Thread richard . n . procter
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

Re: iwm(4): fix ccmp decrypt edge cases

2019-08-14 Thread richard . n . procter
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

Re: iwm(4): fix ccmp decrypt edge cases

2019-08-16 Thread richard . n . procter
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

Re: once again: iwm(4) multi-frame rx + monitor mode

2019-09-04 Thread richard . n . procter
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

remove spurious checksumming attempts

2020-01-23 Thread richard . n . procter
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

npppd(4) normalise checksum update method

2020-01-24 Thread richard . n . procter
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

pf: remove 'one shot rules'

2020-01-24 Thread richard . n . procter
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

Re: fix possible nexthop list corruption in bgpd

2020-01-24 Thread richard . n . procter
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

[PATCH] add ping(1)-like stats to tcpbench(1)

2020-05-01 Thread richard . n . procter
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

Re: [PATCH] add ping(1)-like stats to tcpbench(1)

2020-05-02 Thread richard . n . procter
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 =

Re: [PATCH] add ping(1)-like stats to tcpbench(1)

2020-05-02 Thread richard . n . procter
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 >

wg(4): encapsulated transport checksums

2020-06-26 Thread richard . n . procter
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

Re: wg(4): encapsulated transport checksums

2020-06-29 Thread richard . n . procter
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