Re: wsmouse(4): Apple-like multi-touch buttons
If we consider it as a work in progress, is it a good idea then to "publish" it via wsconsctl immediately? Shouldn't we leave wsconsctl as it is until we have figured out what to do, or at least hide that new field? And, speaking of hiding, it is for a feature that's only useful for a subset of touchpads: MT-clickpads with MT-support in our kernel. How do you want to handle the cases where it is useless? And MT-clickpads without MT-support? It may raise wrong expectations. Without MT-data reasonable filtering won't be possible. On 2/8/23 00:48, Patrick Wildt wrote: > On Tue, Feb 07, 2023 at 10:07:56PM +0100, Ulf Brosziewski wrote: >> I wouldn't mind seeing such a feature in the driver, but I think there's more >> to do than counting contacts. The start of a click-and-drag gesture may >> involve >> two contacts and a button-press event, or people who place a thumb in the >> lower >> clickpad area and use it for pressing the clickpad button might leave the >> index >> finger in the main area. In both cases you probably shouldn't generate a >> middle- >> button event, and I guess it doesn't happen on MacOS, or does it? >> >> There may be various means to distinguish the gestures. The driver might >> check >> the positions and the distance of the contacts, or identify their duration, >> their initial position or the current direction and speed of movement, etc. >> >> I don't know which strategies work well and can be implemented with >> reasonable >> effort, it might not be easy to figure that out. It seems that libinput uses >> distances (see >> >> https://wayland.freedesktop.org/libinput/doc/1.22.0/clickpad-softbuttons.html >> ) as well as additional means for identifying "thumbs", but I'm not familiar >> with the details. > > Sounds like this good be something one could improve upon in-tree? The > diff already feels much better than the current default. > > Cheers, > Patrick >
Re: omit ksh MAIL* bits in SMALL builds
Peter Stuge wrote: > Klemens Nanni wrote: > > Anyone checking their mailboxes in the installer's interactive shell? > > The installer creates some mails, right? Do they only ever go into > a newly installed system, never into a mailbox within the installer? It does not use any mechanism close to this.
Re: omit ksh MAIL* bits in SMALL builds
Klemens Nanni wrote: > Anyone checking their mailboxes in the installer's interactive shell? The installer creates some mails, right? Do they only ever go into a newly installed system, never into a mailbox within the installer? //Peter
add table-procexec to smtpd
Hi,
This is another try to add table-procexec to smtpd. This allows for table
backends to communicate with smtpd with a very simple line protocol, similar to
filter proc-exec.
The code is simple enough and after a bit of time can be used as a replace for
table-proc (which uses imsg). Currently it is not replacing anything and is
just available as an extra. I have a WIP perl-ldap table which can talk this
line protocol and its on github right now (quite old) -
https://github.com/bsd-ac/table-ldap_perl
OK to import?
Cheers,
Aisha
diff --git a/usr.sbin/smtpd/smtpctl/Makefile b/usr.sbin/smtpd/smtpctl/Makefile
index ef8148be8c9..2e8beff1ad1 100644
--- a/usr.sbin/smtpd/smtpctl/Makefile
+++ b/usr.sbin/smtpd/smtpctl/Makefile
@@ -48,6 +48,7 @@ SRCS+=table_static.c
SRCS+= table_db.c
SRCS+= table_getpwnam.c
SRCS+= table_proc.c
+SRCS+= table_procexec.c
SRCS+= unpack_dns.c
SRCS+= spfwalk.c
diff --git a/usr.sbin/smtpd/smtpd.h b/usr.sbin/smtpd/smtpd.h
index 125a6a5dfbe..ca54d54ea66 100644
--- a/usr.sbin/smtpd/smtpd.h
+++ b/usr.sbin/smtpd/smtpd.h
@@ -1662,6 +1662,7 @@ int table_regex_match(const char *, const char *);
void table_open_all(struct smtpd *);
void table_dump_all(struct smtpd *);
void table_close_all(struct smtpd *);
+const char *table_service_name(enum table_service );
/* to.c */
diff --git a/usr.sbin/smtpd/smtpd/Makefile b/usr.sbin/smtpd/smtpd/Makefile
index d914b43f705..3fcfcd1c19d 100644
--- a/usr.sbin/smtpd/smtpd/Makefile
+++ b/usr.sbin/smtpd/smtpd/Makefile
@@ -63,6 +63,7 @@ SRCS+=compress_gzip.c
SRCS+= table_db.c
SRCS+= table_getpwnam.c
SRCS+= table_proc.c
+SRCS+= table_procexec.c
SRCS+= table_static.c
SRCS+= queue_fs.c
diff --git a/usr.sbin/smtpd/table.c b/usr.sbin/smtpd/table.c
index 7328cf5df6e..4f9adfe4c57 100644
--- a/usr.sbin/smtpd/table.c
+++ b/usr.sbin/smtpd/table.c
@@ -36,8 +36,8 @@ extern struct table_backend table_backend_static;
extern struct table_backend table_backend_db;
extern struct table_backend table_backend_getpwnam;
extern struct table_backend table_backend_proc;
+extern struct table_backend table_backend_procexec;
-static const char * table_service_name(enum table_service);
static int table_parse_lookup(enum table_service, const char *, const char *,
union lookup *);
static int parse_sockaddr(struct sockaddr *, int, const char *);
@@ -49,6 +49,7 @@ static struct table_backend *backends[] = {
_backend_db,
_backend_getpwnam,
_backend_proc,
+ _backend_procexec,
NULL
};
@@ -67,7 +68,7 @@ table_backend_lookup(const char *backend)
return NULL;
}
-static const char *
+const char *
table_service_name(enum table_service s)
{
switch (s) {
diff --git a/usr.sbin/smtpd/table_procexec.c b/usr.sbin/smtpd/table_procexec.c
new file mode 100644
index 000..9375da5c0ad
--- /dev/null
+++ b/usr.sbin/smtpd/table_procexec.c
@@ -0,0 +1,326 @@
+/* $OpenBSD$ */
+
+/*
+ * Copyright (c) 2023 Aisha Tammy
+ * Copyright (c) 2020 Gilles Chehade
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "log.h"
+#include "smtpd.h"
+
+#define PROCEXEC_VERSION "1"
+#define PROCEXEC_TIMEOUT 500
+
+static int table_procexec_open(struct table *);
+static int table_procexec_update(struct table *);
+static void table_procexec_close(struct table *);
+static int table_procexec_lookup(struct table *, enum table_service,
+ const char *, char **);
+static int table_procexec_fetch(struct table *, enum table_service, char **);
+
+enum procexec_query;
+static int table_procexec_helper(struct table *, enum procexec_query,
+ enum table_service, const char *, char **);
+
+struct table_backend table_backend_procexec = {
+"proc-exec",
+K_ANY,
+NULL,
+NULL,
+NULL,
+table_procexec_open,
+table_procexec_update,
+table_procexec_close,
+table_procexec_lookup,
+table_procexec_fetch,
+};
+
+struct procexec_handle {
+ FILE
Re: bgpd reduce size of internal ctl message
On Thu, Feb 09, 2023 at 10:56:03AM +0100, Claudio Jeker wrote: > In IMSG_CTL_SHOW_NEIGHBOR a struct peer is sent from the SE to the RDE to > fill out 10 values. This is a waste of IO, struct peer is over 1000 bytes > large. Instead just pass the peerid to the RDE, let the rde send back a > stats object and have the control code do the merge. > Introduce struct rde_peer_stats to hold all these values and adjust the > code accordingly. Makes a lot of sense and reads fine. Just one thing: > @@ -348,7 +348,7 @@ struct peer *getpeerbyip(struct bgpd_con > struct peer *getpeerbyid(struct bgpd_config *, uint32_t); > int peer_matched(struct peer *, struct ctl_neighbor *); > int imsg_ctl_parent(int, uint32_t, pid_t, void *, uint16_t); > -int imsg_ctl_rde(int, pid_t, void *, uint16_t); > +int imsg_ctl_rde(int, pid_t, uint32_t, void *, uint16_t); Would it not be better to sort the peerid before the pid like in the other functions that have both? If you prefer to keep it this way, ok tb
Re: pf max-src-{states,conn} without overload/flush useless?
Hello,
On Wed, Feb 08, 2023 at 09:42:11PM -0600, joshua stein wrote:
> $ for i in `seq 5` ; do nc 192.168.1.240 22 & done
> [2] 68892
> [3] 6303
> [4] 63554
> [5] 87833
> [6] 49997
> $ SSH-2.0-OpenSSH_9.1
> SSH-2.0-OpenSSH_9.1
> SSH-2.0-OpenSSH_9.1
> SSH-2.0-OpenSSH_9.1
> SSH-2.0-OpenSSH_9.1
>
> vm:~$ doas pfctl -sr
> block return all
> pass out all flags S/SA
> pass in on egress inet6 proto tcp from any to ::1 port = 22 flags S/SA keep
> state (source-track rule, max-src-conn 3)
> pass in on egress inet proto tcp from any to 127.0.0.1 port = 22 flags S/SA
> keep state (source-track rule, max-src-conn 3)
> pass in on egress inet proto tcp from any to 192.168.1.240 port = 22 flags
> S/SA keep state (source-track rule, max-src-conn 3)
>
> This is with:
>
> OpenBSD 7.2-current (GENERIC.MP) #2014: Tue Feb 7 16:24:04 MST 2023
> dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP
I gave it a try after doing a sysupgrade to:
penBSD 7.2-current (GENERIC.MP) #1025: Wed Feb 8 19:16:09 MST 2023
it still works for me as expected:
disk$ for i in `seq 5` ; do nc 192.168.2.175 22 & done
[1] 51566
[2] 78983
[3] 77864
[4] 37474
[5] 98599
disk$ SSH-2.0-OpenSSH_9.2
SSH-2.0-OpenSSH_9.2
SSH-2.0-OpenSSH_9.2
my connection arrives over iwn0 interface which is in egress group
so our environments are almost identical.
>
> > > diff --git sys/net/pf.c sys/net/pf.c
> > > index 8cb1326a160..89703feab12 100644
> > > --- sys/net/pf.c
> > > +++ sys/net/pf.c
> > > @@ -481,12 +481,10 @@ pf_src_connlimit(struct pf_state **stp)
> > > if ((sn = pf_get_src_node((*stp), PF_SN_NONE)) == NULL)
> > > return (0);
> > >
> > > - sn->conn++;
> > > - (*stp)->src.tcp_est = 1;
> > > pf_add_threshold(>conn_rate);
> > >
> > > if ((*stp)->rule.ptr->max_src_conn &&
> > > - (*stp)->rule.ptr->max_src_conn < sn->conn) {
> > > + sn->conn >= (*stp)->rule.ptr->max_src_conn) {
> > > pf_status.lcounters[LCNT_SRCCONN]++;
> > > bad++;
> > > }
> > > @@ -497,8 +495,11 @@ pf_src_connlimit(struct pf_state **stp)
> > > bad++;
> > > }
> > >
> > > - if (!bad)
> > > + if (!bad) {
> > > + sn->conn++;
> > > + (*stp)->src.tcp_est = 1;
> > > return (0);
> > > + }
> > >
> > > if ((*stp)->rule.ptr->overload_tbl) {
> > > struct pfr_addr p;
> >
> > it seems to me the change to pf_src_connlimit() does
> > not alter behavior. I think change to pf_src_connlimit()
> > can be dropped.
>
> But don't we not want to increment the source node's connection
> count since we're not going to accept the connection (in the !bad
> case)? I'm not sure what kind of bookkeeping that would screw up.
>
what we currently do is we always bump connection count
for source node we found. then we are going to check limit
(*stp)->rule.ptr->max_src_conn < sn->conn
if the limit is exceeded we mark as closed and expired (timeout
PFTM_PURGE). We also report that to caller which should close the
connection.
your change stops counting connections as soon as limit is
reached. So now I see there is a change in behavior. I've missed
that yesterday. I'm not able to tell if we want go that way or not.
> > currently we do conn limit check in step (4). Your change moves this
> > to earlier step (3) (given I understand things right here).
> > It's awfully early here I need sleep on this.
>
> Yes, that was my understanding too. We wait until the remote has
> done enough work to be a valid connection but then block it before
> sending the final ack.
>
> > can you give it a try with your slightly modified diff? just drop
> > changes to pf_src_connlimit() and keep those in pf_tcp_track_full() which
> > I believe is the only relevant part.
>
> Yes, it still works, and only allows me 3 connections with the final
> 2 timing out as expected:
>
> $ for i in `seq 5` ; do nc 192.168.1.240 22 & done
> [2] 10193
> [3] 30197
> [4] 72235
> [5] 69900
> [6] 99044
> $ SSH-2.0-OpenSSH_9.1
> SSH-2.0-OpenSSH_9.1
> SSH-2.0-OpenSSH_9.1
> [5] - exit 1 nc 192.168.1.240 22
> $
> [6] + exit 1 nc 192.168.1.240 22
>
the only explanation why it does not work for you is latency. The packets which
match state run as a readers. so if we call pf_set_protostate() before we
actually check the limit then it might be the cause here. I admit it's
rather a speculation.
can you give a try to diff below?
thanks and
regards
sashan
8<---8<---8<--8<
diff --git a/sys/net/pf.c b/sys/net/pf.c
index 8cb1326a160..f81b0c793ce 100644
--- a/sys/net/pf.c
+++ b/sys/net/pf.c
@@ -4919,14 +4919,14 @@ pf_tcp_track_full(struct pf_pdesc *pd, struct pf_state
**stp, u_short *reason,
pf_set_protostate(*stp, psrc, TCPS_CLOSING);
if (th->th_flags & TH_ACK) {
if (dst->state ==
bgpd reduce size of internal ctl message
In IMSG_CTL_SHOW_NEIGHBOR a struct peer is sent from the SE to the RDE to
fill out 10 values. This is a waste of IO, struct peer is over 1000 bytes
large. Instead just pass the peerid to the RDE, let the rde send back a
stats object and have the control code do the merge.
Introduce struct rde_peer_stats to hold all these values and adjust the
code accordingly.
This should improve calls like bgpctl show and bgpctl metrics.
--
:wq Claudio
Index: bgpd.h
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
retrieving revision 1.460
diff -u -p -r1.460 bgpd.h
--- bgpd.h 24 Jan 2023 14:13:11 - 1.460
+++ bgpd.h 8 Feb 2023 17:36:34 -
@@ -480,6 +480,19 @@ struct peer_config {
#define PEERFLAG_EVALUATE_ALL 0x04
#define PEERFLAG_NO_AS_SET 0x08
+struct rde_peer_stats {
+ uint64_t prefix_rcvd_update;
+ uint64_t prefix_rcvd_withdraw;
+ uint64_t prefix_rcvd_eor;
+ uint64_t prefix_sent_update;
+ uint64_t prefix_sent_withdraw;
+ uint64_t prefix_sent_eor;
+ uint32_t prefix_cnt;
+ uint32_t prefix_out_cnt;
+ uint32_t pending_update;
+ uint32_t pending_withdraw;
+};
+
enum network_type {
NETWORK_DEFAULT,/* from network statements */
NETWORK_STATIC,
@@ -1301,7 +1314,7 @@ void set_pollfd(struct pollfd *, struc
int handle_pollfd(struct pollfd *, struct imsgbuf *);
/* control.c */
-intcontrol_imsg_relay(struct imsg *);
+intcontrol_imsg_relay(struct imsg *, struct peer *);
/* config.c */
struct bgpd_config *new_config(void);
Index: control.c
===
RCS file: /cvs/src/usr.sbin/bgpd/control.c,v
retrieving revision 1.108
diff -u -p -r1.108 control.c
--- control.c 17 Aug 2022 15:15:26 - 1.108
+++ control.c 8 Feb 2023 17:36:19 -
@@ -219,7 +219,7 @@ int
control_close(struct ctl_conn *c)
{
if (c->terminate && c->ibuf.pid)
- imsg_ctl_rde(IMSG_CTL_TERMINATE, c->ibuf.pid, NULL, 0);
+ imsg_ctl_rde(IMSG_CTL_TERMINATE, c->ibuf.pid, 0, NULL, 0);
msgbuf_clear(>ibuf.w);
TAILQ_REMOVE(_conns, c, entry);
@@ -250,7 +250,8 @@ control_dispatch_msg(struct pollfd *pfd,
if (msgbuf_write(>ibuf.w) <= 0 && errno != EAGAIN)
return control_close(c);
if (c->throttled && c->ibuf.w.queued < CTL_MSG_LOW_MARK) {
- if (imsg_ctl_rde(IMSG_XON, c->ibuf.pid, NULL, 0) != -1)
+ if (imsg_ctl_rde(IMSG_XON, c->ibuf.pid, 0, NULL, 0) !=
+ -1)
c->throttled = 0;
}
}
@@ -324,8 +325,7 @@ control_dispatch_msg(struct pollfd *pfd,
matched = 1;
if (!neighbor || !neighbor->show_timers) {
imsg_ctl_rde(imsg.hdr.type,
- imsg.hdr.pid,
- p, sizeof(struct peer));
+ imsg.hdr.pid, p->conf.id, NULL, 0);
} else {
u_inti;
time_t d;
@@ -349,7 +349,7 @@ control_dispatch_msg(struct pollfd *pfd,
if (!matched && RB_EMPTY(peers)) {
control_result(c, CTL_RES_NOSUCHPEER);
} else if (!neighbor || !neighbor->show_timers) {
- imsg_ctl_rde(IMSG_CTL_END, imsg.hdr.pid,
+ imsg_ctl_rde(IMSG_CTL_END, imsg.hdr.pid, 0,
NULL, 0);
} else {
imsg_compose(>ibuf, IMSG_CTL_END, 0, 0, -1,
@@ -494,7 +494,7 @@ control_dispatch_msg(struct pollfd *pfd,
c->ibuf.pid = imsg.hdr.pid;
c->terminate = 1;
- imsg_ctl_rde(imsg.hdr.type, imsg.hdr.pid,
+ imsg_ctl_rde(imsg.hdr.type, imsg.hdr.pid, 0,
imsg.data, imsg.hdr.len - IMSG_HEADER_SIZE);
break;
case IMSG_CTL_SHOW_NETWORK:
@@ -503,7 +503,7 @@ control_dispatch_msg(struct pollfd *pfd,
case IMSG_CTL_SHOW_RIB_MEM:
case IMSG_CTL_SHOW_SET:
c->ibuf.pid = imsg.hdr.pid;
- imsg_ctl_rde(imsg.hdr.type, imsg.hdr.pid,
+ imsg_ctl_rde(imsg.hdr.type, imsg.hdr.pid, 0,
