pf: keep src track for route-to while its state exists

Hi, The source address tracking (sticky-address) is kept dulring there are states which refer it. This is mentioned in pf.conf(5). This is true for translation(nat-to, rdr-to) but it was not true for routing(route-to). ok? Link the state and the source track to keep the source track while

move to interface rx queue backpressure for if_rxr livelock detection

interface rx queue processing includes detection of when the stack becomes too busy to process packets. there's three stages to this mechanism. firstly, everything is fine and the packets are simply queued for processing. the second is the "pressure_return" stage where the interface has queued a

let sysctl tweak interface rx queue backpressure cutoffs

this lets read and write the backpressure variables in the interface rx queue (ifiq) handling: dlg@ix ~$ sysctl net.link.ifrxq net.link.ifrxq.pressure_return=6 net.link.ifrxq.pressure_drop=8 ideally this would be temporary, ie, id remove it from the tree once everyone's happy with these numbers.

Re: sleep(1): simplify argument parsing

Hi Scott, Scott Cheloha wrote on Sun, Jun 30, 2019 at 06:49:28AM -0500: > This is cleaner, shorter. > > - Remove the intermediate variables and just build the timespec >directly. > > - Use for-loops to consolidate initialization/incrementation of cp >into one spot in each loop. > >

smtpd fix proc filter chaining with proceed

Found by Mischa Peters by running some experimental code of mine. When chaining two proc-based filters together the second proc will not get its parameter correctly, since lka_filter_process_response won't get a parameter from the proceed keyword, resulting in a "...|(null)" The solution seems

Re: Thermal zone support for arm64

On Saturday, 29 June 2019 18:08, Mark Kettenis wrote: > Many of the cheap arm64 (and armv7) boards will overheat if you run > the CPU cores at full throttle for a while. Adding a heatsink may > help a little bit, but not enough. Some boards have a microcontroller > that monitors the temperature

Re: ldomctl: improve usage

Hi Klemens, Klemens Nanni wrote on Sun, Jun 30, 2019 at 01:04:17PM +0200: > On Sat, Jun 22, 2019 at 11:20:10AM -0600, Theo de Raadt wrote: >> The problem is when I'm on screens that don't have scroll-back, those 9 >> lines have scrolled other information off the top, and then I've had to >>

Re: ldomctl: improve usage

As an ldomctl user, I would be happy for usage to be reasonably terse, provided help gives a fuller description - provided the usage mentions the help option. If your screen does not have scroll back, the solution is a screen program that does. It is not 1978 any more. (Incidentally, do others

sleep(1): simplify argument parsing

This is cleaner, shorter. - Remove the intermediate variables and just build the timespec directly. - Use for-loops to consolidate initialization/incrementation of cp into one spot in each loop. - Use one loop to parse fractions of a second: less duplicate code keeps the fraction

Re: ldomctl: improve usage

On Sat, Jun 22, 2019 at 11:20:10AM -0600, Theo de Raadt wrote: > The problem is when I'm on screens that don't have scroll-back, those 9 > lines have scrolled other information off the top, and then I've had to > repeat the operations, or if not possible, been more frustrated. Should we change

Re: bgpd, unify ref counting code

Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.06.25 11:13:55 +0200: > In bgpd there are a few objects that use reference counts to keep track on > how many things point to them. Those are struct pt_entry, rde_aspath, > rde_communities, and nexthop. The way this reference counting is done and >

Re: fix for spinning bgpd session engine

Claudio Jeker(cje...@diehard.n-r-g.com) on 2019.06.28 09:44:35 +0200: > It is possible that a session is going down while peer->rpending (the flag > indicating that there is more data to process) is set. If that is > happening the session engine is spinning until the session comes back up > or the