Re: [patch] cleaner checksum modification for pf

2015-06-22 Thread Richard Procter
On 16/06/2015, at 1:09 PM, Richard Procter wrote: - I was unable to test af-to, which does a lot of packet fiddling. I've now tested this without obvious issue. Note: a couple of one-line changes in icmp af-translation remain untested. Details attached. - I haven't tested modification

Re: [patch] cleaner checksum modification for pf

2015-06-16 Thread Richard Procter
On 17/06/2015, at 4:26 AM, Mike Belopuhov wrote: You didn't read the pf.conf manual page carefully: [...] Because address family translation overrides the routing table, it's only possible to use af-to on inbound rules, and a source address for

[patch] cleaner checksum modification for pf

2015-06-15 Thread Richard Procter
Hi, These patches against HEAD re-instate the pf algorithm of OpenBSD 5.4 for preserving payload checksums end-to-end but rewritten without the ugly and error-prone (but speedy!) nested pf_cksum_fixup calls. I have been running this code on a small Alix (i386) IPv4 gateway for a month with no

[Patch] pf refactoring

2015-08-16 Thread Richard Procter
Hi, This series of 29 small diffs slims pf.o by 2640 bytes and pf.c by 113 non-comment lines. pf_translate(), in particular, is now much shorter and clearer[0]. I've tested it by running on my home router (alix, i386, inet4) for a week or so without issue, and by profiling it under stress. I

Re: [patch] cleaner checksum modification for pf

2015-07-18 Thread Richard Procter
Hi, On 16/06/2015, at 1:09 PM, Richard Procter wrote: - I was unable to test af-to, which does a lot of packet fiddling. I've now tested this without obvious issue. I neglected checksum regeneration within icmp af-to, which masked a couple of icmp af-to errata in my last patch. I've re

[patch] tsec(4): enable TX interrupt coalescing

2015-11-09 Thread Richard Procter
Hi, This reduces tsec(4) TX interrupts by over a factor of four per interface, boosting throughput by a couple of percent for $ dd if=/dev/zero bs=4096 | nc ${host} ${port} It does this by reducing TX interrupts notifications to one per frame, from one per mbuf fragment, and by

Re: [PATCH] PF: cksum modification & refactor [3/24]

2015-09-01 Thread Richard Procter
Hi Sasha, On 1/09/2015, at 12:47 AM, Alexandr Nedvedicky wrote: > the code in patch looks good for the first glance. However it seems to me > the newly introduced pf_cksum_fixup*() are not called yet. Do you think you > can reshuffle changes between your set of patches a bit, so the newly >

Re: [PATCH] PF: cksum modification & refactor [3/24]

2015-09-02 Thread Richard Procter
On 2/09/2015, at 4:02 PM, Richard Procter wrote: > > Testing: Same code as in my email "[patch] cleaner checksum modification for > pf", > see my testing notes there. > > Just to be sure/anal retentive, I have retested the more involved changes: But anal

Re: [PATCH] PF: cksum modification & refactor [3/24]

2015-09-10 Thread Richard Procter
On 3/09/2015, at 10:41 AM, Richard Procter wrote: > [...] or for that matter just unit-test the pf_change() calls. I > think I'll rustle up some of the later. That was a useful exercise. The pf_change_*() code is fine. However, pf_cksum_fixup_a() reliably faulted a couple of times ov

Re: [patch] cleaner checksum modification for pf

2015-09-30 Thread Richard Procter
On 29/09/2015, at 11:14 PM, Alexandr Nedvedicky wrote: > Hello, > > I've tried Richard's patch on sparc. I took a brief look at its source code. > It's essentially what PF is doing on Solaris. Thanks for doing that. Just for the record, I look at PF's patched checksum handling as follows.

Re: [patch] cleaner checksum modification for pf

2015-09-27 Thread Richard Procter
On 25/09/2015, at 9:33 PM, Stuart Henderson wrote: > > [snip comment; I completely agree] > >> Another (home) router I administer was seeing IIRC five [bad TCP checksums] a >> day on average over 42 days, something we expect of a globe-spanning >> internetwork. >> Passing one of these damaged

Re: [patch] cleaner checksum modification for pf

2015-09-24 Thread Richard Procter
On 14/09/2015, at 11:51 PM, Henning Brauer wrote: > * Martin Pieuchot [2015-09-11 13:54]: >> On 11/09/15(Fri) 13:28, Henning Brauer wrote: >>> Ryan pointed me to this diff and we briefly discussed it; we remain >>> convinced that the in-tree approach is better than this. >>

Re: [patch] tsec(4): enable TX interrupt coalescing

2015-12-03 Thread Richard Procter
Refreshed patch against HEAD appears below, best, Richard. PS. Apologies for the quoted-printable encoding...looking now for an email client capable of 7-bit... On 10/11/2015, at 5:18 PM, Richard Procter wrote: > This reduces tsec(4) TX interrupts by over a factor of four per interf

Re: removing expired once rules in pf_purge_thread()

2015-12-13 Thread Richard Procter
If I understand this patch: Rule removal requires the consistency lock but to acquire it one must be able to sleep. pf_test_rule() cannot sleep as it executes in a (soft) interrupt handler, so it passes the expired rule to a thread which can. However, the code to remove a 'once' rule may wish

Re: removing expired once rules in pf_purge_thread()

2015-12-15 Thread Richard Procter
On Tue, 15 Dec 2015, Mike Belopuhov wrote: > >Yet another possibility is to drop 'once' rules as too complex to > >implement for multiprocessor but I have no idea if this is viable. > > It is. And I have said that before with an authority of the implementor > of "once" rules: since we

Re: removing expired once rules in pf_purge_thread()

2015-12-18 Thread Richard Procter
Hi Sasha, On Fri, 18 Dec 2015, Alexandr Nedvedicky wrote: > > Right. I'll just note though that the patch as it stands allows > > multiple winners [...] Whether that's a realistic issue, I don't know. > > I have though been bitten by enough edge cases like this to be very > > wary of them.

Re: socppc/fdt: fix fdt_find_node for the case we don't find a node

2016-02-28 Thread Richard Procter
Hi Patrick, On Sun, 28 Feb 2016, Patrick Wildt wrote: > Hi, > > If we're calling fdt_find_node() and do not actually find the node we're > looking for, we call strncmp with a NULL value. > [...] Tested on RB600A: boots fine, dmesg unchanged (mod banner). Patch applied to HEAD, fdt.c:1.12.

Re: socppc/fdt: fix end signature check (again)

2016-02-28 Thread Richard Procter
Hi Patrick, On Sun, 28 Feb 2016, Patrick Wildt wrote: > Hi, > > unfortunately the end signature check is still not correct. Consulting > the spec cleared the confusion of why the check does not work on my ARM > machines. > [...] Tested on RB600A: boots fine, dmesg unchanged (mod banner).

Re: fdt: move code from socppc to sys/dev/fdt/

2016-03-02 Thread Richard Procter
On Wed, 2 Mar 2016, Patrick Wildt wrote: > Hi, > > to allow FDT to be used on ARM I think we should move the FDT code from > socppc to sys/dev/fdt/. Opinions? > > Could someone test this diff for me? Sure --- it compiles and boots on socppc (RB600A). I applied patch to HEAD and removed the

[PATCH] [0/11] pf checksum modification / refactoring

2016-08-10 Thread Richard Procter
Here is the first step in the pf checksum modification / refactoring series. The complete series is available at http://203.79.107.124/. It differs from what I presented at the hackathon only by a small optimisation [0]. Overview The series is broken into two phases. Phase1 is a

Re: [PATCH] [0/11] pf checksum modification / refactoring

2016-08-16 Thread Richard Procter
On Tue, 9 Aug 2016, Richard Procter wrote: > > Here is the first step in the pf checksum modification / refactoring > series. > > The complete series is available at http://203.79.107.124/. It differs > from what I presented at the hackathon only by a small optimisation [0

refactor PF option parsing loops

2017-01-23 Thread Richard Procter
Hi, PF implements six distinct TCP option parsing loops. This patch converts these to one inline function in pfvar_priv.h, normalises their semantics, and strips ~100 lines. I've laid out the existing semantics below. The new loop implements the timestamp parser's semantics of "(s-b) (v-3)

Re: refactor PF option parsing loops

2017-01-23 Thread Richard Procter
PS Find this patch broken down for easier review here: http://203.79.107.124/opts/ On Tue, 24 Jan 2017, Richard Procter wrote: > Hi, > > PF implements six distinct TCP option parsing loops. This patch converts > these to one inline function in pfvar_priv.h, normalises the

Re: iwm: fix a timeout race

2017-01-20 Thread Richard Procter
Hi, On 18/01/2017, Stefan Sperling wrote: > I managed to trigger the following uvm fault by continously switching an > iwm(4) client between two APs on different channels, i.e. a loop that runs: > ifconfig iwm0 chan X; sleep 10; ifconfig iwm chan Y; sleep 10; > >

[PATCH] [0/1] pf refactoring

2016-08-19 Thread Richard Procter
Hi, I've reduced the pf refactor (phase two) to two patches, which I'll be committing in 24 hours or so unless there are any objections. I'm confident it won't, but supposing post-commit these have in fact blown up, my first suspect would be the afto paths. This patch removes

[PATCH] [1/1] pf refactoring

2016-08-19 Thread Richard Procter
The final patch in the pf series. Will commit when I do the previous one in around 24 hours unless there are objections. - pushes the 'field changed' guards into the 'change field' functions. This lets us normalise many of the existing guards and eliminate lots of code from pf_translate().

Re: [PATCH] [0/1] pf refactoring

2016-08-19 Thread Richard Procter
Hi Mike, On Fri, 19 Aug 2016, Mike Belopuhov wrote: > I've looked through it and couldn't find anything wrong with it. Thanks. > I do however find pacthing of values in pf_translate_icmp_af > unneccessary since we'll be throwing away the original header > anyway. Do you mean e.g. circa line

Re: pf_route pf_pdesc

2016-10-22 Thread Richard Procter
On Fri, 21 Oct 2016, Alexander Bluhm wrote: > We could put the union pf_headers into a separate header file. > Henning, I hope you don't mind that I used a current license.template > with your old pf_headers code. > > Do we want to go this way? You got me thinking how else this might be done.

Re: pf af-to route output

2016-11-19 Thread Richard Procter
On Mon, 14 Nov 2016, Alexander Bluhm wrote: > Hi, > > The !r->rt case is only used by af-to. pf_route6() calls ip6_output() > to do the work while pf_route() has some custom implementation for > that. It is simpler to call ip_output() or ip6_output() from > pf_test() directly. > > ok? Note,

[PATCH] pf: fold pf_headers into pf_pdesc

2016-11-19 Thread Richard Procter
Hi, This patch folds pf_headers into pf_pdesc, and eliminates pf_pdesc's header pointers. It's mostly mechanical except for strengthening a guard in pf_socket_lookup(). I've an OK from bluhm@ but to give others a heads-up I won't commit for another 48 hours. +ve removes the header buffer

Re: allow iwm_stop to sleep

2017-08-26 Thread Richard Procter
Hi Stefan, On 14/08/2017, at 7:07 PM, Stefan Sperling wrote: > This diff makes iwm_stop() always run in a process context. > I want iwm_stop() to be able to sleep so that it can wait for asynchronous > driver tasks, and perhaps even wait for firmware commands, in the future. > > If the

Re: ping.c minor bug discrepancy between reported size of icmp packet

2018-06-09 Thread Richard Procter
Hi, On 9/06/2018, at 7:52 AM, Tom Smyth wrote: > Hello I see a small discrepancy between the measurement > of sent and received packets as displayed by ping command > > on the wire the sent and received packets are the same size > I had a brief go > > foo# ping 5.134.88.1 > PING 5.134.88.1

Re: ksh "clear-screen" editing command

2018-06-18 Thread Richard Procter
On 6/06/2018, at 10:20 AM, Alexander Hall wrote: > This adds a "clear-screen" editing command to the emacs editing mode. > This is the same name as bash and zsh uses, and then I stopped looking. > > Thoughts? OK? It's unclear to me what need is being being addressed here --- are you wanting a

Re: ipsec ah_massage_headers cleanup

2018-02-05 Thread Richard Procter
On Mon, 5 Feb 2018, Alexander Bluhm wrote: > Hi, > > While reading ah_massage_headers() for the erratas, I found some > issues which are ugly, but not security relevant. > > - Declare global array ipseczeroes with zeroes constant. > - The proto parameter contains the address family, so call

Re: pfctl: use mnemonic macros, terminate string with null char

2019-01-19 Thread Richard Procter
Hi, Comments below, > On 19/01/2019, at 2:32 PM, Klemens Nanni wrote: > > A few assorted nits for consistency and proper format, no object change. > > OK? > > Index: pfctl.c > === > RCS file: /cvs/src/sbin/pfctl/pfctl.c,v >

Re: iwm(4) WPA2 crypto hardware offload

2019-08-04 Thread Richard Procter
Hi Stefan, > On 2/08/2019, at 11:13 PM, Stefan Sperling wrote: > > This diff enables HW offload for WPA2 CCMP (AES) encrypted unicast > frames in iwm(4). This is in preparation for Tx aggregation support. Lightly tested on: iwm0 at pci1 dev 0 function 0 "Intel Dual Band Wireless AC 7265" rev

Re: iwm: two small Rx code path fixes

2019-08-29 Thread Richard Procter
Hi Stefan, On 28/08/2019, Stefan Sperling wrote: > 1) Fix max frame length check to account for the firmware's Rx result >header in the buffer, which contains two uint16_t fields. >Frame data begins after this header. > > 2) Do not write to mbuf length fields before the mbuf has been

Re: iwm(4) WPA2 crypto hardware offload

2019-08-05 Thread Richard Procter
> On 4/08/2019, at 11:21 PM, Stefan Sperling wrote: > On Sun, Aug 04, 2019 at 10:20:24PM +1200, Richard Procter wrote: >> >>> + >>> + return iwm_send_cmd_pdu(sc, IWM_ADD_STA_KEY, IWM_CMD_ASYNC, >>> + sizeof(cmd), ); >> >> Might

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

2020-05-03 Thread Richard Procter
> On 4/05/2020, at 9:30 AM, Stuart Henderson wrote: > > On 2020/05/04 09:23, Richard Procter wrote: >> I like it. >> >> Assuming a mention in tcpbench.1 - ok procter > > ok like this? text stolen from ping. the server has an small edge case: it refuses t

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

2020-05-03 Thread Richard Procter
I like it. Assuming a mention in tcpbench.1 - ok procter > On 4/05/2020, at 4:25 AM, Stuart Henderson wrote: > > Is it worth triggering this on SIGINFO? I use that often with ping(1). > > Index: tcpbench.c > === > RCS file:

Re: mcx(4) checksum offload

2020-05-19 Thread Richard Procter
> On 19/05/2020, at 11:19 AM, Alexandr Nedvedicky > wrote: > > I'm not sure about outbound path. chksum offload on outbound side got killed > back in 2016 (I think). All that logic behind dealing with various HW did not > pay off. If PF is doing NAT it's far more simple and reliable if we

Re: Donation of Power PC Based boards RB800 I have 5x if they are any use for training / testing

2020-05-19 Thread Richard Procter
Hi Tom, Thanks for offering. I built a personal OpenBSD/socppc 6.5 release last year for my RB600A and continue to use it. I tried building 6.6 but found compiling clang infeasible on a platform with only 128MB of memory and PIO compact flash. I tried to improve the swap experience by adding an

Re: TCP congestion window pinned by integer arithmetic

2020-06-09 Thread Richard Procter
Hi, > On 2/06/2020, at 9:41 AM, Brian Brombacher wrote: > > Hi, > > RFC 5681 Section 3.1 has an Implementation Note that covers the bug fixed by > the following patch. I ran into this bug testing on a high latency link. My > congestion window was pinned to a specific value and could not

Re: bgpd refactor timer code

2020-12-10 Thread Richard Procter
Hi Claudio, > On 10/12/2020, at 1:13 AM, Claudio Jeker wrote: > > This diff makes the timer code independent from struct peer. This way > it can be used in different places without too much issues. ok procter@ > OK? > -- > :wq Claudio > > Index: control.c >

Re: Wireguard: can't remove multiple peers at once.

2021-01-24 Thread Richard Procter
Hi, > On 14/01/2021, at 8:33 PM, YASUOKA Masahiko wrote: > > Hi, > > On Thu, 14 Jan 2021 08:54:36 +0900 > Yuichiro NAITO wrote: >> Does anybody please review my code? >> >> Yasuoka-san is my coleague of my work. >> So, he is interested in this topic. That’s why I CCed this mail. >> I don’t

Re: broadcast simplex checksum

2021-01-31 Thread Richard Procter
>> On 20/01/2021, at 1:56 PM, Alexander Bluhm wrote: >> >> Hi, >> >> Simplex interfaces reinject broadcast packets back into the IP >> stack. As this is a software features, no hardware checksumming >> occurs. So local broadcast packets are dropped with wrong checksum >> if the underlying