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
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
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
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
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
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
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
>
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
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
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.
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
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.
>>
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
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
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
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.
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.
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).
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
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
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
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)
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
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;
>
>
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
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().
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
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.
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,
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
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
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
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
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
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
>
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
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
> 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
> 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
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:
> 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
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
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
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
>
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
>> 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
46 matches
Mail list logo