It's handy and otherwise easily missed when reading up on routing
domains and tables; wording taken from netstat(1) as is.
Not listing pgrep(1)'s `-T' because examples don't have to be exhaustive
and ps(1) is already demonstrated; same for top(1) users which more
likely come across its `t' and
On Sun, Sep 20, 2020 at 06:01:08PM +, Miod Vallat wrote:
> I had noticed for years that eeprom(8) always reported failure when
> attempting to change OpenFirmware environment variables on macppc.
>
> Upon further examination, it doesn't - the variables get changed, but
> error is reported.
On Tue, Sep 15, 2020 at 02:31:24AM +0200, Klemens Nanni wrote:
> On Tue, Sep 15, 2020 at 12:30:35AM +0200, Klemens Nanni wrote:
> > Actually, that should just work regardless of whether the rounting
> > domain exists at ruleset creation time; just like it is the case with
>
On Sun, Sep 20, 2020 at 06:14:22AM -0600, Todd C. Miller wrote:
> On Sun, 20 Sep 2020 05:39:02 +0200, Theo Buehler wrote:
>
> > This works and appears to match bash's behavior in that it only works
> > in normal mode. I would slightly prefer to also add the command to the
> > nonstandard vi
On Sun, Sep 20, 2020 at 05:39:02AM +0200, Theo Buehler wrote:
> On Sat, Sep 19, 2020 at 03:50:52PM -0600, Todd C. Miller wrote:
> > The vi and emacs edit code are completely separate. Try the following
> > diff. I had to rename a few things to avoid clashing with ncurses.h.
>
> This works and
On Wed, Sep 16, 2020 at 07:49:19PM +0900, YASUOKA Masahiko wrote:
> New diff is using -1 for ENOENT.
>
> Also domainid == 0 is a valid domain id, but previous diff cannot make
> a cache of it since 0 is the default value. So new diff is doing
>
> - static u_int
On Wed, Sep 16, 2020 at 06:22:00PM +0900, YASUOKA Masahiko wrote:
> Let me continue this separetely.
Yes, let's get your diff in for release and then work out the other
approach.
> Make pfctl check if the rtable really exists when parsing the config.
The diff is a bit hard to read (nothing you
On Tue, Sep 15, 2020 at 12:42:27PM +0900, YASUOKA Masahiko wrote:
> It's not clear for me why non-existing rdomain is accepted but
> non-existing rtable is rejected. I suppose we can make pf(4) can
> handle a packet for the non-existing routing table as if the routing
> table is empty.
Probably
On Mon, Sep 14, 2020 at 10:57:16AM +0200, Klemens Nanni wrote:
> I tested removing a single port from trunk and observed that both
> interfaces do end up with the same MAC address, but this happens without
> my diff already - I still don't see any behaviour after my diff wrt. MAC
&g
On Tue, Sep 15, 2020 at 12:30:35AM +0200, Klemens Nanni wrote:
> Actually, that should just work regardless of whether the rounting
> domain exists at ruleset creation time; just like it is the case with
> interface names/groups which may come and go at runtime without
> requi
On Mon, Sep 14, 2020 at 02:09:27PM +0900, YASUOKA Masahiko wrote:
> When pf rule with a "on rdomain n" with nonexisting rdomain n causes
>
> /etc/pf.conf:XXX: rdomain n does not exist
Actually, that should just work regardless of whether the rounting
domain exists at ruleset creation time;
On Wed, Sep 02, 2020 at 04:58:39PM +0200, Stefan Sperling wrote:
> I would like to suggest an example for the EXAMPLES section which
> illustrates how a suitable stride factor can be determined (divide the
> number of desired "unused" cpus by the number of desired "used" cpus):
We can do with an
I'm going through the pppoeintr() code path wrt. KERNEL_LOCK(), first
step is discovery packet handling.
Reading the code makes me want to clean/simplify it a bit by zapping
needless variable assignments (dead store because next usage is another
assign) and merging initializations into
On Mon, Sep 14, 2020 at 02:09:27PM +0900, YASUOKA Masahiko wrote:
> Make pfctl check if the rtable really exists when parsing the config.
I concur, but you can do this with less (duplicated) code.
Instead of copying rdomain_exists() into rtable_exists() with the
`rti_domainid' check omitted,
On Sun, Sep 13, 2020 at 06:44:13PM +0100, Stuart Henderson wrote:
> I can't test at the moment, but the other case is removing a port from
> the trunk without destroying the trunk interface itself. That's almost
> certainly what I was testing at the time.
Right, that's different from destroying
This is my first try trading global locks for interface specific ones.
pppoe(4) keeps a list of all its interfaces which is then obviously
traversed during create and destroy.
Currently, the net lock is grabbed for this, but there seems to be no
justification other than reusing^Wabusing an
On Sun, Sep 13, 2020 at 01:23:59PM +0200, Klemens Nanni wrote:
> On Sun, Sep 13, 2020 at 11:31:12AM +0100, Stuart Henderson wrote:
> > On 2020/09/13 11:12, Stuart Henderson wrote:
> > > This has been tried before, I forget what but there were problems
> >
> &g
On Sun, Sep 13, 2020 at 11:31:12AM +0100, Stuart Henderson wrote:
> On 2020/09/13 11:12, Stuart Henderson wrote:
> > This has been tried before, I forget what but there were problems
>
> from chat logs when I tried this before:
>
> 14:52 < sthen> if i kill the if_down, no crash, but the mac
On Sun, Sep 13, 2020 at 12:23:50PM +0200, Martin Pieuchot wrote:
> Without doing another audit but with the fact that pseudo-device are
> generally run by a thread holding the NET_LOCK() I'd assume it's ok.
Thanks, I'll put it in as its an improvement and comment only (safe);
rest can happen
Here's a start at struct pppoe_softc; for every member I went through
code paths looking for *_LOCK() or *_ASSERT_LOCKED().
Pretty much all members are under the net lock, some are proctected by
both net and kernel lock, e.g. the start routine is called with
KERNEL_LOCK().
I did not go
Unconfiguring a member interface from trunk(4) or simply destroying the
trunk pulls the member down for no reason, both comment and code are
there since import, but I see no justification for doing so.
aggr(4) does not pull its member down upon removal either.
I came across this after
$
On Sat, Sep 12, 2020 at 05:11:00PM +0200, Klemens Nanni wrote:
> Bit hard to read, what about aligning like this?
>
> + if ((rdns_proposal->src == 0 ||
> + rdns_proposal->src == tmp->src) &&
> +
On Sat, Sep 12, 2020 at 04:36:28PM +0200, Florian Obser wrote:
> ... say if you pull a usb stick.
...or if you play with^W^Wrecreate your trunk0 { em0 athn0 } uplink
without checking unwind.
Without this diff, unwind cannot recover; with it, stuff just works for
me across destroy/create.
OK kn
These are the last free(buf, 0) occurences in if_pppoe.c and
if_spppsubr.c changing to non-zero sizes.
I've been running with this the last week without any issues.
Feedback? OK?
Index: if_spppsubr.c
===
RCS file:
On Sat, Aug 29, 2020 at 05:13:00PM +0200, Klemens Nanni wrote:
> NOTES stays unused unless pf.conf(5) contains `set loginterface ...' in
> which case it merely amends what can otherwise be part of the NAME
> column.
>
> Merge the constant NOTES values for conditional counters
On Thu, Sep 03, 2020 at 06:13:41PM +0200, Florian Obser wrote:
> Then reload the ruleset and restart unwind:
>
> # pfctl -f /etc/pf.conf
> # rcctl restart unwind
>
> You can now get stats on how often your machine talks to the root name
> servers:
>
> # pfctl -s label
> rootdns_tcp 2730 0 0 0
On Wed, Sep 02, 2020 at 04:12:33PM +1000, Matt Dunwoodie wrote:
> The patch isn't fully correct. When you remove a peer, sc_peer_num
> will decrement, and if you add a new peer afterwards you will have
> duplicate IDs. This is likely to create further headaches. A dedicated
> ID counter in
They way strides work is everything but intuitive and the manual doesn't
really help; I've had multiple hackers/users ask me how to use them.
`vcpu 8' assigns eight virtual CPUs to a domain.
`vcpu 8:2' allocates eight VCPUs two times but assigns eight VCPUs
only once, leaving the other eight
The driver increases a static peer counter across all wg interfaces when
creating peers, the peer number is only used in debug output, though.
Output from console around recreating an interface (2 and 4 are the same):
wg1: Receiving handshake response from peer 2
wg1: Receiving
NOTES stays unused unless pf.conf(5) contains `set loginterface ...' in
which case it merely amends what can otherwise be part of the NAME
column.
Merge the constant NOTES values for conditional counters into their NAME
values to make the `pf' view look a little nicer and less empty by
default;
On Wed, Aug 26, 2020 at 12:20:27PM +1000, Matt Dunwoodie wrote:
> I doing some IPv6 setup, I came across an issue with wg(4) and ndp. The
> local route is created with RTF_LLINFO, which ndp attempts to print. As
> wg is a layer3 tunnel it won't have any link-local information.
>
> This patch just
On Mon, Aug 24, 2020 at 12:52:46AM +0200, Klemens Nanni wrote:
> Add `t' to swap the WAIT column with RTABLE (and vice versa); WAIT
> is wide enough to fit RTABLE, somewhat adds additional value to STATE
> and seems therefore most appropiate to hide in favour of RTABLE.
>
> Intern
ifconfig(8)'s TRUNK (LINK AGGREGATION) nicely combines the two drivers
and I'd like to further omit common stuff from the drive specific
manuals.
This aids in the overall design of having options documented in
ifconfig(8) alone unless they're inherently driver specific, e.g.
`trunkproto' which
Add `t' to swap the WAIT column with RTABLE (and vice versa); WAIT
is wide enough to fit RTABLE, somewhat adds additional value to STATE
and seems therefore most appropiate to hide in favour of RTABLE.
Internally, I renamed the existing CMD_rtable command to filter routing
tables into
On Sun, Aug 23, 2020 at 10:39:21PM +0200, Remi Locherer wrote:
> I like the feature and it works as advertised.
>
> It would be nice to have a column that displays the rtable id of
> each process when T is used. When I type "T-0" I see a list of procs
> not in rtable 0. But I still do not know
On Mon, Jul 20, 2020 at 05:07:03PM +0200, Klemens Nanni wrote:
> On Mon, Jul 20, 2020 at 01:14:00PM +0200, Alexandr Nedvedicky wrote:
> > I took a closer look at your change and related area. Below is an alternate
> > way to fix the bug you've found.
> Thanks for bringing it
On Sun, Aug 09, 2020 at 09:02:14PM +0200, Klemens Nanni wrote:
> Sometimes I want to see processes outside the default routing table with
> `-T -0', sometimes those in in a specific one with `-T 3' (for testing).
>
> Since others have poked around with routing tables and/or domains
On Sat, Aug 22, 2020 at 02:32:17PM +0200, Klemens Nanni wrote:
> Another round, this time obvious sizes which are in immediate scope of
> the free() call, e.g. right below the malloc() call.
>
> This leaves only a few selected free() calls with size zero in
> if_spppsubr.c
Another round, this time obvious sizes which are in immediate scope of
the free() call, e.g. right below the malloc() call.
This leaves only a few selected free() calls with size zero in
if_spppsubr.c due to the fact that there is currently no variable to
keep track of username and password
Creating a cloned interface requires attaching it in the end, that's how
it works.
All clonable interfaces start with a fresh softc structure that all
zeros after allocation due to malloc(9)'s M_ZERO flag.
After driver dependent setup, all drivers call if_attach() to present
the new interface to
On Thu, Aug 20, 2020 at 03:33:17PM +0200, Klemens Nanni wrote:
> These are straight forward as we either maintain a size variable all the
> way or can reuse strlen() for free() just like it's done during malloc().
>
> One exception is freeing the softc structure, which is f
These are straight forward as we either maintain a size variable all the
way or can reuse strlen() for free() just like it's done during malloc().
One exception is freeing the softc structure, which is fixed in size;
`ifconfig pppoe1 create; ifconfig pppoe1 destroy' exercises this code
path and
On Tue, Aug 18, 2020 at 09:58:56AM +0200, Sasha Romijn wrote:
> The current openrsync client is not able to connect to dual-stack remote
> hosts, when the local host does not have any IPv4 connectivity. This is
> because connect() fails with EADDRNOTAVAIL when trying to connect to the
> remote
On Tue, Aug 18, 2020 at 06:14:30PM +0200, Florian Obser wrote:
> When sending a router solicitation use the link-layer (mac) address of
> the outgoing interface in the source link-layer address ICMPv6 option
> instead of the address of the last configured autoconf interface.
>
> It is not the
On Sun, Aug 16, 2020 at 07:04:46PM +0200, Klemens Nanni wrote:
> Make sppp(4)/pppoe(4) use the ifq API to send packets outside the big
> lock.
>
> As far as I understand, pppoe_output() does not require NET_LOCK() since
> if_get(9)/if_put(9) guarantee the validity of the in
Make sppp(4)/pppoe(4) use the ifq API to send packets outside the big
lock.
As far as I understand, pppoe_output() does not require NET_LOCK() since
if_get(9)/if_put(9) guarantee the validity of the interface pointer and
no `struct ifnet' member is written to; similar to how vlan(4) does it.
On Fri, Jul 31, 2020 at 06:28:32AM +0200, Klemens Nanni wrote:
> ifconfig(8) detects switch(4) through its unique SIOCSWSDPID ioctl and
> further does another switch specific ioctl for the default output
> regardless of configuration and/or members:
>
> SIOCSWSDPID s
Unused since
revision 1.138
date: 2015/09/30 09:45:20; author: sthen; state: Exp; lines: +50
-279; commitid: 0pACTtU
Sw4WmBBBr;
remove cisco hdlc code from sppp(4), it's no longer used - pppoe(4)
only uses
ppp framing, and the drivers for sync serial
On Sat, Aug 08, 2020 at 04:12:31AM +0200, Klemens Nanni wrote:
> This is OK with me as it fixes the default view, but I think other views
> need fixing as well, e.g.
>
> $ iostat -I
> ttysd0 sd1
> cpu
>
Sometimes I want to see processes outside the default routing table with
`-T -0', sometimes those in in a specific one with `-T 3' (for testing).
Since others have poked around with routing tables and/or domains as of
late, perhaps this deemed useful enough?
Semantically, filtering is identical
On Sun, Aug 09, 2020 at 06:42:07PM +0300, Vitaliy Makkoveev wrote:
> Does `IFXF_MPSAFE' bit assume that pfsyncioctl() should not rely to
> kernel lock and pfsync(4) related data structures already have their own
> protection?
I say it does not.
There's PF_LOCK(), but it a) has to be enabled
mvs's vnet(4) diff reminded me of pfsync(4).
This works on my my pair of amd64 firewalls.
Feedback? OK?
Index: if_pfsync.c
===
RCS file: /cvs/src/sys/net/if_pfsync.c,v
retrieving revision 1.275
diff -u -p -r1.275 if_pfsync.c
---
On Sun, Aug 09, 2020 at 07:48:21PM +1000, Jonathan Gray wrote:
> Thinking about this some more the problem is really the choice of errno.
> It used to be EINVAL but was changed to EFTYPE in
>
>
> revision 1.7
> date: 1997/06/20 14:04:30; author: kstailey; state:
On Sun, Aug 09, 2020 at 03:16:50AM +0300, Vitaliy Makkoveev wrote:
> vether(4) is pretty dummy. Nothing denies it to be `IFXF_MPSAFE'.
OK kn
On Wed, Jul 29, 2020 at 07:39:43PM +0200, Klemens Nanni wrote:
>
> Poking and testing around in brconfig.c for tpmr(4) stuff, I noticed a
> lot of old code around strto*l(3).
>
> Many pass unbounded `long' values into the `[u]int32_t' struct members
> without limiting them to
On Fri, Aug 07, 2020 at 12:59:00PM -0700, jo...@armadilloaerospace.com wrote:
> Perform an explicit check for the unsupported exFAT MSDOS filesystem
> instead of letting it fail mysteriously when it gets cluster sizes
> of 0 from the normal fields.
>
> This causes mount_msdos to report:
>
On Fri, Aug 07, 2020 at 12:04:59PM -0700, jo...@armadilloaerospace.com wrote:
> IO rates above 100 MB/s are common with SSD; this patch expands the
> column so it stays neatly printed.
This is OK with me as it fixes the default view, but I think other views
need fixing as well, e.g.
$
On Wed, Aug 05, 2020 at 03:24:57PM +0100, Jason McIntyre wrote:
> this is in line with all our other pages, so ok. while you're poking
> around in there, the first example in tpmr.4 EXAMPLES would be a whole
> lot nicer with -indent on the display. care to fix that too?
Sure, I'll commit with `.Bd
Add missing TPMR section to ifconfig(8) by moving the commands from
the driver's manual to it (copy/paste) and document the ioctl(2)
interface in tpmr(4).
Feedback? OK?
Index: sbin/ifconfig/ifconfig.8
===
RCS file:
On Wed, Aug 05, 2020 at 11:00:00AM +1000, David Gwynne wrote:
> can't they be caught by the default case now?
Obviously...
Index: net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.617
diff -u -p -r1.617 if.c
---
On Sat, Aug 01, 2020 at 06:06:32PM +0100, Jason McIntyre wrote:
> hmm. so then the current text ("the last background process") already
> covers all these cases. why single out co-processes?
Yes, "background process" technically covers co-processes, but at least
for me "background processes" aka.
On Sat, Aug 01, 2020 at 05:40:07PM +0100, Jason McIntyre wrote:
> i'm worried that you're blurring the distinction between asynchronous
> and co-process for the reader. i think that's relevant because, as you
> say, a page like sh(1) does not document co-processes, whereas ksh(1)
> does.
You raise
Otherwise it is not clear whether $! will be set or not. This way,
`/Co-proc' brings me to *all* relevant spots in the manual.
Snippet to demonstrate how $! is set for an asynchronous process:
$ ksh -c ': |& echo $!'
67163
FWIW, sh(1) doesn't document Co-processes (whis is
This diff is to be applied on top of my other diff on tech@ with subject
"ifconfig: merge switch_status() into bridge_status()".
It hooks completes the output of tpmr intefaces in what I think is the
simplest and least intrusive way.
tpmr is a trivial bridge and has no specific ioctls, so to
On Wed, Jul 29, 2020 at 02:21:42PM +0200, Klemens Nanni wrote:
> This is to reduce duplicate code and pave the way for a single
> bridge_status() that covers all bridge like interfaces: bridge(4),
> switch(4) and tpmr(4).
A duplicate bridge_cfg() call snuck in, fixed diff below.
Fee
On Fri, Jul 31, 2020 at 06:28:32AM +0200, Klemens Nanni wrote:
> ifconfig(8) detects switch(4) through its unique SIOCSWSDPID ioctl and
> further does another switch specific ioctl for the default output
> regardless of configuration and/or members:
>
> SIOCSWSDPID s
ifconfig(8) detects switch(4) through its unique SIOCSWSDPID ioctl and
further does another switch specific ioctl for the default output
regardless of configuration and/or members:
SIOCSWSDPID struct ifbrparam
Set the datapath_id in the OpenFlow protocol of the switch
Multiple rtables may exist in the default rdomain (0), that is their
corresponding rdomains/lo(4) interfaces do not have to exist.
This demonstrates it; first, nothing but default, so route(8) fails:
# netstat -R
Rdomain 0
Interfaces: lo0 vio0 enc0
Routing
Poking and testing around in brconfig.c for tpmr(4) stuff, I noticed a
lot of old code around strto*l(3).
Many pass unbounded `long' values into the `[u]int32_t' struct members
without limiting them to at least the type size the value is stored in,
some report wrong commands in error messages,
On Wed, Jul 29, 2020 at 09:05:14AM -0600, Theo de Raadt wrote:
> Claudio Jeker wrote:
> > But:
> > $ route -T2 exec id -R
> > 2
> > $ route -T2 exec route -T0 exec id -R
> > route: setrtable: Operation not permitted
> >
> > Only root can change the rdomain if it is currently !=
On Wed, Jul 29, 2020 at 05:33:14PM +0300, Kapetanakis Giannis wrote:
> Wouldn't this break those who already have
> !route -T2
>
> in their hostname.if files?
No,
$ route -T1 exec id -R
1
$ route -T0 exec route -T1 exec id -R
1
On Wed, Jul 29, 2020 at 11:54:17AM +0200, Matthieu Herrb wrote:
> When I'm configuring an interface with a spécific rdomain, I'd assume
> that '!' commands (especially /sbin/route commands) are executed in
> the rdomain for this interface.
I see where you're coming from, but the diff seems flawed.
This is to reduce duplicate code and pave the way for a single
bridge_status() that covers all bridge like interfaces: bridge(4),
switch(4) and tpmr(4).
Feedback? OK?
Index: brconfig.c
===
RCS file:
On Tue, Jul 28, 2020 at 07:09:17PM +0200, Klemens Nanni wrote:
> bridge_status() and switch_status() do the regular sanity check with
> SIOCGIFFLAGS, but both functions also call is_switch(), bridge_status()
> also calls is_bridge().
>
> Those is_*() helpers do the same SIOCGIFFLA
bridge_status() and switch_status() do the regular sanity check with
SIOCGIFFLAGS, but both functions also call is_switch(), bridge_status()
also calls is_bridge().
Those is_*() helpers do the same SIOCGIFFLAGS sanity check, making those
in *_status() entirely redundant, so I'd like to remove
There since import from NetBSD, but we have no iommu(4).
OK?
Index: share/man/man4/sbus.4
===
RCS file: /cvs/src/share/man/man4/sbus.4,v
retrieving revision 1.53
diff -u -p -r1.53 sbus.4
--- share/man/man4/sbus.4 18 Jun 2018
Those are for the gateway sockaddrs which get allocated in rt_setgate()
with the same ROUNDUP(sa_len) approach.
mpi already added a sizes for a few rt_gateway sockaddrs in two commits,
these are the last one in route.c leaving only ifafree() behind.
Also tested on a few machines during last
On Sun, Jul 26, 2020 at 06:47:14PM +0100, Jason McIntyre wrote:
> certainly ok by me. i think this commit could add aggr to the list of
> devices in "create".
Right, thanks.
> bridge is a bit different i think. i wouldn;t like to have those
> synopses dropped because i think they're useful. but
Except for `trunkproto' wich his trunk(4) specific, aggr(4) has the same
options so I'd like to merge it into the same section just like TUNNEL
documents mostly identical interfaces with differences mentioned in at
specific options.
The wording "trunk" seems clear under OpenBSD, but other vendors
On Sun, Jul 26, 2020 at 06:07:07PM +0200, Mark Kettenis wrote:
> Booted up the old v210 to test something and noticed that it prints a
> couple of:
>
> bge0: nvram lock timed out
>
> warnings when booting up. These are the on-board network interfaces
> and we already established in the past
On Sat, Jul 25, 2020 at 04:27:44PM +0900, YASUOKA Masahiko wrote:
> When an unicast address is specified for carppeer, if the peer is
> down, sending out advertisemnent packets will fail, this failure is
> treated as an error of the sending host, then the error counter is
> incremented and
On Thu, Jul 23, 2020 at 10:25:01PM +0100, Jason McIntyre wrote:
> yes, i supplied feedback to this diff on the day you mailed it. my reply
> was:
>
> sendmail. they add compatibility for sendmail-compatible mailers. some
> folks are used to having them around.
>
> i guess
I've somehow hit the slash way to often for searching a particular
command, would anyone object if I added it as a command character?
While here, what's up with the weird markup in top.1 for `n|# count'?
I've simplified that before adopting it, `mandoc -Tlint ./top.1' is
happy with it.
Feedback?
On Mon, Jun 22, 2020 at 04:09:49AM +0200, Klemens Nanni wrote:
> Doing "*stat " in my shell I came across those two entries
> under /usr/bin/ which are undocumented:
>
> $ man -k any~'^(host|purge)stat$'
> man: nothing appropriate
>
> /etc/mail
On Thu, Jul 16, 2020 at 03:02:25PM +0200, Klemens Nanni wrote:
> On Thu, Jul 16, 2020 at 10:23:20AM +0100, Stuart Henderson wrote:
> > On 2020/07/15 10:02, Theo de Raadt wrote:
> > > It is extremely unwise to use DNS names at this level (or things which
> > > look
On Mon, Jul 20, 2020 at 01:14:00PM +0200, Alexandr Nedvedicky wrote:
> I took a closer look at your change and related area. Below is an alternate
> way to fix the bug you've found.
Thanks for bringing it up again, I forgot to reply earlier.
> there are few details worth to note:
>
>
Getting the checksum with pfctl(8) is either in your finger's muscle
memory or takes guess work as the manual doesn't mention it.
I grepped the code to see that I need `-s info' with `-v'.
(Setting) hostid is described in pf.conf(5) but pfctl(8) doesn't tell us
how to print it, there's merely an
Without /etc/hostname.pfsync0 there will be no such interface upon boot.
Feedback? OK?
Index: faq/pf/carp.html
===
RCS file: /cvs/www/faq/pf/carp.html,v
retrieving revision 1.63
diff -u -p -r1.63 carp.html
--- faq/pf/carp.html28
On Thu, Jul 16, 2020 at 09:49:21PM +0200, Ingo Schwarze wrote:
> That allows a nice cleanup, simplifying the code and getting rid
> of several headers and several calls to complicated functions.
OK kn
On Thu, Jul 16, 2020 at 10:23:20AM +0100, Stuart Henderson wrote:
> On 2020/07/15 10:02, Theo de Raadt wrote:
> > It is extremely unwise to use DNS names at this level (or things which
> > look like DNS names). The same problems that pf has with DNS, are
> > present here. You really don't want
Here's an addition to EXAMPLES for one of my frequent use cases that
finally "just works".
First transport mode for child SAs was implemented, then a few
interoperability issues have been identified with peers other than iked,
now tobhe fixed pubkey (`rsa' ikeauth, default) usage based on this.
There are more, but these ones are obvious as the size is already used
to clear the buffers' contents beforehand.
Feedback? OK?
Index: sys/net/pfkeyv2.c
===
RCS file: /cvs/src/sys/net/pfkeyv2.c,v
retrieving revision 1.200
diff -u -p
Each ruleset's rules are stored in a TAILQ called `ptr' with `rcount'
representing the number of rules in the ruleset; `ptr_array' points to
an array of the same length:
struct pf_ruleset {
struct {
...
struct {
On Sun, Jul 12, 2020 at 10:31:49PM +0300, Vitaliy Makkoveev wrote:
> I like to have "sizeof(*omi)" in corresponding malloc(9) too.
>
> cut begin
> 827 omi = malloc(sizeof(struct sr_meta_opt_item), M_DEVBUF,
> 828 M_WAITOK | M_ZERO);
> cut end
While omi->omi_som seems variable in size, omi is only ever allocated
with one size and softraid.c uses the same size for free(9) as well.
Tested with cryto softraid and keydisk.
Feedback? OK?
Index: dev/softraid_crypto.c
===
RCS
We overallocate by quite a bit for bootable disks; spotted while
reading the code and tested by installboot(8)ing onto vnd(4) backed
softraid disks (after booting a kernel with this diff).
$ egdb --quiet obj/bsd.gdb
Reading symbols from obj/bsd.gdb...done.
(gdb) p
Feedback? OK?
Index: sys/net/if_wg.c
===
RCS file: /cvs/src/sys/net/if_wg.c,v
retrieving revision 1.9
diff -u -p -r1.9 if_wg.c
--- sys/net/if_wg.c 10 Jul 2020 13:26:42 - 1.9
+++ sys/net/if_wg.c 12 Jul 2020 16:31:03
On Thu, Jul 09, 2020 at 05:08:01PM +1000, David Gwynne wrote:
> if i accidentally `ifconfig bridge add gre0` instead of egre0, having
> bridge create gre0 and then not like it is not what i expect to happen.
> especially when it leaves me with an extra gre0 interface lying around
> afterwards.
>
Is there any particular reason why an interface's *public* key is only
shown to the root user in ifconfig?
Similar to `wgport', I'd like to see the public key as non-root user as
well for convenience:
$ ifconfig wg0
wg0: flags=80c3 mtu 1420
index 5 priority 0
On Fri, Jun 26, 2020 at 04:48:53PM +0200, Klemens Nanni wrote:
> The internal handle used to pass process information is a needless
> abstraction, after previously removing an unused member, it now only has
> one member pointing to a pointer to a process struct, i.e. a simple list
>
1 - 100 of 922 matches
Mail list logo
