Re: ld.so speedup (part 2)
On Sat, Apr 27 2019, Nathanael Rensen wrote: > The diff below speeds up ld.so library intialisation where the dependency > tree is broad and deep, such as samba's smbd which links over 100 libraries. > > See for example https://marc.info/?l=openbsd-misc=155007285712913=2 > > See https://marc.info/?l=openbsd-tech=155637285221396=2 for part 1 > that speeds up library loading. > > The timings below are for /usr/local/sbin/smbd --version: > > Timing without either diff : 6m45.67s real 6m45.65s user 0m00.02s system > Timing with part 1 diff only: 4m42.88s real 4m42.85s user 0m00.02s system > Timing with part 2 diff only: 2m02.61s real 2m02.60s user 0m00.01s system > Timing with both diffs : 0m00.03s real 0m00.03s user 0m00.00s system First off, thanks a lot for solving this long outstanding issue. The use of ld --as-needed hides the problem but it looks like ld.lld isn't as good as ld.bfd at eliminating extra inter-library references. As I told mpi@ earlier today, I think your changes are correct as is, and are good to be committed. So this counts as an ok jca@. But I'd expect other developers to chime in soon, maybe they'll spot something that I didn't. -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
less(1) UTF-8 cleanup: pshift()
Hi,
thanks for checking the pappend() and filename.c patches,
those are now committed.
Here is basic cleanup of the last major function in line.c, pshift().
Several minor issues still remain in the file, but those are for later.
This gets rid of two LWCHAR variables, one call to utf_len(),
get_wchar(), is_composing_char(), is_combining_char(), and
control_char() each and two calls to is_wide_char().
Note the change from "continue" to "break" in the "width == 2"
block. It is an improvement because the double-width character did
not move off-screen completely, its second half is still there,
represented as a single-width space. So whatever follows it does
absolutely not move off-screen, not even if what follows is zero
width, so it must not be inspected by the loop.
Since the variable names are far from intuitive, improve and add
comments. Also, the comment above pshift() is simply wrong.
The function does not discard a specific number of characters.
Tested by running
LC_CTYPE=en_US.UTF-8 less -# 1
LC_CTYPE=en_US.UTF-8 less -# 1 -R
LC_CTYPE=C less -# 1
on my set of test files containing a wide variety of combinations
of valid and invalid UTF-8 and control sequences, then scrolling
horizontally with the arrow keys.
OK?
Ingo
Index: line.c
===
RCS file: /cvs/src/usr.bin/less/line.c,v
retrieving revision 1.29
diff -u -p -r1.29 line.c
--- line.c 7 May 2019 14:16:16 - 1.29
+++ line.c 7 May 2019 20:52:26 -
@@ -32,11 +32,11 @@ int ntabstops = 1; /* Number of tabstop
int tabdefault = 8;/* Default repeated tabstops */
off_t highest_hilite; /* Pos of last hilite in file found so far */
-static int curr; /* Index into linebuf */
-static int column; /* Printable length, accounting for backspaces, etc. */
+static int curr; /* Total number of bytes in linebuf */
+static int column; /* Display columns needed to show linebuf */
static int overstrike; /* Next char should overstrike previous char */
static int is_null_line; /* There is no current line */
-static int lmargin;/* Left margin */
+static int lmargin;/* Index in linebuf of start of content */
static char pendc;
static off_t pendpos;
static char *end_ansi_chars;
@@ -202,20 +202,21 @@ plinenum(off_t pos)
/*
* Shift the input line left.
- * This means discarding N printable chars at the start of the buffer.
+ * Starting at lmargin, some bytes are discarded from the linebuf,
+ * until the number of display columns needed to show these bytes
+ * would exceed the argument.
*/
static void
pshift(int shift)
{
- LWCHAR prev_ch = 0;
- unsigned char c;
- int shifted = 0;
- int to;
- int from;
- int len;
- int width;
- int prev_attr;
- int next_attr;
+ int shifted = 0; /* Number of display columns already discarded. */
+ int from; /* Index in linebuf of the current character. */
+ int to; /* Index in linebuf to move this character to. */
+ int len; /* Number of bytes in this character. */
+ int width = 0;/* Display columns needed for this character. */
+ int prev_attr;/* Attributes of the preceding character. */
+ int next_attr;/* Attributes of the following character. */
+ unsigned char c; /* First byte of current character. */
if (shift > column - lmargin)
shift = column - lmargin;
@@ -241,44 +242,41 @@ pshift(int shift)
}
continue;
}
-
- width = 0;
-
if (!IS_ASCII_OCTET(c) && utf_mode) {
- /* Assumes well-formedness validation already done. */
- LWCHAR ch;
-
- len = utf_len(c);
- if (from + len > curr)
- break;
- ch = get_wchar(linebuf + from);
- if (!is_composing_char(ch) &&
- !is_combining_char(prev_ch, ch))
- width = is_wide_char(ch) ? 2 : 1;
- prev_ch = ch;
+ wchar_t ch;
+ /*
+* Before this point, UTF-8 validity was already
+* checked, but for additional safety, treat
+* invalid bytes as single-width characters
+* if they ever make it here. Similarly, treat
+* non-printable characters as width 1.
+*/
+ len = mbtowc(, linebuf + from, curr - from);
+ if (len == -1)
+ len = width = 1;
+ else if ((width = wcwidth(ch)) == -1)
+ width
Re: libevent: prevent integer overflow in kqueue
Tobias Stoeckmann wrote: > This patch avoids a possible integer overflow on excessively large > amount of events added to an event base in kqueue mode (default). > > Just as with previous changes, this is very unlikely to trigger and > is a just a defensive measure. > > Changes in this diff: > > * KNF (sorted imports and added limits.h for INT_MAX) > * recallocarray instead of reallocarray, in sync with minheap change > * adjusted error messages from malloc to recallocarray > > Okay? ok
libevent: prevent integer overflow in kqueue
This patch avoids a possible integer overflow on excessively large
amount of events added to an event base in kqueue mode (default).
Just as with previous changes, this is very unlikely to trigger and
is a just a defensive measure.
Changes in this diff:
* KNF (sorted imports and added limits.h for INT_MAX)
* recallocarray instead of reallocarray, in sync with minheap change
* adjusted error messages from malloc to recallocarray
Okay?
Tobias
Index: kqueue.c
===
RCS file: /cvs/src/lib/libevent/kqueue.c,v
retrieving revision 1.40
diff -u -p -u -p -r1.40 kqueue.c
--- kqueue.c10 Jul 2017 21:37:26 - 1.40
+++ kqueue.c7 May 2019 19:49:53 -
@@ -32,14 +32,15 @@
#include
#include
+#include
+#include
+#include
+#include
#include
#include
#include
#include
#include
-#include
-#include
-#include
#include "event.h"
#include "event-internal.h"
@@ -133,25 +134,29 @@ kq_insert(struct kqop *kqop, struct keve
struct kevent *newchange;
struct kevent *newresult;
+ if (nevents > INT_MAX / 2) {
+ event_warnx("%s: integer overflow", __func__);
+ return (-1);
+ }
nevents *= 2;
- newchange = reallocarray(kqop->changes,
- nevents, sizeof(struct kevent));
+ newchange = recallocarray(kqop->changes,
+ kqop->nevents, nevents, sizeof(struct kevent));
if (newchange == NULL) {
- event_warn("%s: malloc", __func__);
+ event_warn("%s: recallocarray", __func__);
return (-1);
}
kqop->changes = newchange;
- newresult = reallocarray(kqop->events,
- nevents, sizeof(struct kevent));
+ newresult = recallocarray(kqop->events,
+ kqop->nevents, nevents, sizeof(struct kevent));
/*
* If we fail, we don't have to worry about freeing,
* the next realloc will pick it up.
*/
if (newresult == NULL) {
- event_warn("%s: malloc", __func__);
+ event_warn("%s: recallocarray", __func__);
return (-1);
}
kqop->events = newresult;
Re: Employment verification – request for contact details
On Tue, May 7, 2019 at 2:07 PM Anders Andersson wrote: > > ...[snip]... What they probably did not realize is that the OpenBSD foundation is openbsdfoundation.org and not openbsd.org, so for the nature of their e-mail message, the To: domain is going to tech@openbsd.org of the OpenBSD Project, but they were trying to find someone at the OpenBSD Foundation, instead. And by definition all information contained in e-mail messages sent to tech@openbsd.org nearly instantly became public information, since any of the thousands of people who use OpenBSD or discuss its development subscribed who are subscribed to this technical discussion mailing list will have already received any message. "tech@openbsd.org - Discussion of technical topics for OpenBSD developers and advanced users." " This communication contains information that may be c If you have received this communication in error, please immediately... " Such generic language as that at the footer of an e-mail has no weight or affect on the content made public by the sender choosing an inherently-public To: address, and is spurious and especially annoying to have such spurious disclaimer within normal correspondence, but doubly so, when posting to public mailing lists such as tech@openbsd.org Obviously, the sender of an e-mail cannot command the deletion of an e-mail message in any case, AFTER they have already sent it in any case, which isn't even possible for many recipients that permanently and automatically archive every e-mail message received (and the original message will likely appear in publicly accessible mailing list archives). The burden of correct delivery is on the sender of an e-mail communication to verify their To: address list is 100% correct, before instructing their e-mail software to send that message. Even then, it is readily apparent from the e-mail related IETF standards which give the basic operation of internet email protocols such as SMTP: That the security or privacy of a message content is not assured and cannot reasonably be relied upon when e-mail is sent traversing internet-connected systems, and the use of an additional encryption solution such as PGP or GNUpg would be necessary to encrypt and secure the information PRIOR to placing into an e-mail message, in order to have a chance at adequately preventing potential display or logging of a sensitive or confidential e-mail message body to all potentially unauthorized 3rd parties: with at least a minimal level of security reliability.. > > On Tue, May 7, 2019 at 12:47 PM Lipinska, Sara > wrote: > > > > HireRight Limited is a limited liability company incorporated in England > > (registered number 4036193) whose registered office is at Gun Court, 70 > > Wapping Lane, London, E1W 2RD. > > > > This communication contains information that may be confidential, > > proprietary in nature, and may also be attorney-client privileged and/or > > work product privileged. It is for the exclusive use of the intended > > recipient(s). If you are not the intended recipient(s) or the person > > responsible for delivering it to the intended recipient(s), please note > > that any form of dissemination, distribution or copying of this > > communication is strictly prohibited and may be unlawful. If you have > > received this communication in error, please immediately notify the sender > > by replying to this message and delete this e-mail immediately. Thank you > > for your cooperation. Please be advised that neither HireRight, its > > affiliates, its employees or agents accept liability for any errors, > > omissions or damages caused by delays of receipt or by any virus infection > > in this message or its attachments, or which may otherwise arise as a > > result of this e-mail transmission. > > It's not polite to post legal threats. If you don't want people to > disseminate, distribute or copy what you write, you should probably > not send it out to a mailing list. > Regards, -- -JH
[PATCH] Parallelize sysupgrade downloads
Hello,
thanks for the great new tool, sysupgrade. Works like a charm.
While on it, I came with this patch to speed up the downloading.
It uses xargs -P to parallelize downloads (max 6, chosen from top of my head).
Also, removed trailing spaces in two lines.
Without parallel patch:
4m20.91s real 0m00.44s user 0m24.26s system
With parallel patch:
3m14.14s real 0m00.32s user 0m13.80s system
diff --git usr.sbin/sysupgrade/sysupgrade.sh usr.sbin/sysupgrade/sysupgrade.sh
index 87de9ccf432..635b48186f5 100644
--- usr.sbin/sysupgrade/sysupgrade.sh
+++ usr.sbin/sysupgrade/sysupgrade.sh
@@ -44,7 +44,7 @@ unpriv()
_file=$2
shift 2
fi
- if [[ -n ${_file} ]]; then
+if [[ -n ${_file} ]]; then
>${_file}
chown "${_user}" "${_file}"
fi
@@ -69,6 +69,16 @@ rmel() {
echo -n "$_c"
}
+generate_urls()
+{
+OFS=$IFS
+IFS=$'\n'
+printf "${2}\n" | while read -r f; do
+printf "%s%s\n" "${1}" "${f}"
+done
+IFS=$OFS
+}
+
RELEASE=false
SNAP=false
FORCE=false
@@ -122,7 +132,7 @@ if [[ -e ${SETSDIR} ]]; then
ug_err "${SETSDIR} needs to be owned by root:wheel"
[[ $st_gid -eq 0 ]] ||
ug_err "${SETSDIR} needs to be owned by root:wheel"
-[[ $st_mode -eq 040755 ]] ||
+[[ $st_mode -eq 040755 ]] ||
ug_err "${SETSDIR} is not a directory with permissions 0755"
else
mkdir -p ${SETSDIR}
@@ -167,9 +177,13 @@ for f in $SETS; do
done
[[ -n ${OLD_FILES} ]] && rm ${OLD_FILES}
+cd ${SETSDIR}
+generate_urls $URL "$(echo ${DL} |tr ' ' '\n')" \
+| xargs -P 6 -n 1 ftp -VCm
for f in ${DL}; do
-unpriv -f $f ftp -Vmo ${f} ${URL}${f}
+unpriv -f $f
done
+cd -
echo Verifying sets.
[[ -n ${DL} ]] && unpriv cksum -qC SHA256 ${DL}
--
Kind regards,
Ville Valkonen
Re: Employment verification – request for contact details
On Tue, May 7, 2019 at 12:47 PM Lipinska, Sara wrote: > > HireRight Limited is a limited liability company incorporated in England > (registered number 4036193) whose registered office is at Gun Court, 70 > Wapping Lane, London, E1W 2RD. > > This communication contains information that may be confidential, proprietary > in nature, and may also be attorney-client privileged and/or work product > privileged. It is for the exclusive use of the intended recipient(s). If you > are not the intended recipient(s) or the person responsible for delivering it > to the intended recipient(s), please note that any form of dissemination, > distribution or copying of this communication is strictly prohibited and may > be unlawful. If you have received this communication in error, please > immediately notify the sender by replying to this message and delete this > e-mail immediately. Thank you for your cooperation. Please be advised that > neither HireRight, its affiliates, its employees or agents accept liability > for any errors, omissions or damages caused by delays of receipt or by any > virus infection in this message or its attachments, or which may otherwise > arise as a result of this e-mail transmission. It's not polite to post legal threats. If you don't want people to disseminate, distribute or copy what you write, you should probably not send it out to a mailing list.
Re: tmux: cannot select pane after prefix-b q
On Tue, May 07, 2019 at 11:55:51AM +0100, Nicholas Marriott wrote: > Hi > > You have the right idea general idea of the problem. display-panes > blocks the queue until it is finished, so the key press isn't processed > until then, which is too late. > > But your change defeats the purpose, the idea is that new key presses > should be queued after the commands inserted by previous key presses, > not before them. > > Identify mode (display-panes) can just be treated specially I think. > > Please try the diff below. > Thank you Nicholas, it works like a charm !
Re: tmux: cannot select pane after prefix-b q
On Tue, May 07, 2019 at 11:55:51AM +0100, Nicholas Marriott wrote:
> Hi
>
> You have the right idea general idea of the problem. display-panes
> blocks the queue until it is finished, so the key press isn't processed
> until then, which is too late.
>
> But your change defeats the purpose, the idea is that new key presses
> should be queued after the commands inserted by previous key presses,
> not before them.
>
> Identify mode (display-panes) can just be treated specially I think.
>
> Please try the diff below.
>
> Thanks!
>
>
> Index: server-client.c
> ===
> RCS file: /cvs/src/usr.bin/tmux/server-client.c,v
> retrieving revision 1.279
> diff -u -p -r1.279 server-client.c
> --- server-client.c 3 May 2019 20:44:24 - 1.279
> +++ server-client.c 7 May 2019 10:50:07 -
> @@ -986,7 +986,7 @@ server_client_assume_paste(struct sessio
> * Handle data key input from client. This owns and can modify the key event
> it
> * is given and is responsible for freeing it.
> */
> -enum cmd_retval
> +static enum cmd_retval
> server_client_key_callback(struct cmdq_item *item, void *data)
> {
> struct client *c = item->client;
> @@ -1204,6 +1204,44 @@ forward_key:
> out:
> free(event);
> return (CMD_RETURN_NORMAL);
> +}
> +
> +/* Handle a key event. */
> +int
> +server_client_handle_key(struct client *c, struct key_event *event)
> +{
> + struct session *s = c->session;
> + struct window *w;
> + struct window_pane *wp = NULL;
> + struct cmdq_item*item;
> +
> + /* Check the client is good to accept input. */
> + if (s == NULL || (c->flags & (CLIENT_DEAD|CLIENT_SUSPENDED)) != 0)
> + return (0);
> + w = s->curw->window;
> +
> + /*
> + * Key presses in identify mode are a special case. The queue might be
> + * blocked so they need to processed immediately rather than queued.
> + */
> + if (c->flags & CLIENT_IDENTIFY) {
> + if (c->flags & CLIENT_READONLY)
> + return (0);
> + if (event->key >= '0' && event->key <= '9') {
> + window_unzoom(w);
> + wp = window_pane_at_index(w, event->key - '0');
> + }
> + server_client_clear_identify(c, wp);
> + return (0);
> + }
> +
> + /*
> + * Add the key to the queue so it happens after any commands queued by
> + * previous keys.
> + */
> + item = cmdq_get_callback(server_client_key_callback, event);
> + cmdq_append(c, item);
> + return (1);
> }
>
> /* Client functions that need to happen every loop. */
> Index: tmux.h
> ===
> RCS file: /cvs/src/usr.bin/tmux/tmux.h,v
> retrieving revision 1.888
> diff -u -p -r1.888 tmux.h
> --- tmux.h7 May 2019 10:25:15 - 1.888
> +++ tmux.h7 May 2019 10:50:09 -
> @@ -2012,7 +2012,7 @@ void server_client_set_identify(struct
> void server_client_set_key_table(struct client *, const char *);
> const char *server_client_get_key_table(struct client *);
> int server_client_check_nested(struct client *);
> -enum cmd_retval server_client_key_callback(struct cmdq_item *, void *);
> +int server_client_handle_key(struct client *, struct key_event *);
> struct client *server_client_create(int);
> int server_client_open(struct client *, char **);
> void server_client_unref(struct client *);
> Index: tty-keys.c
> ===
> RCS file: /cvs/src/usr.bin/tmux/tty-keys.c,v
> retrieving revision 1.112
> diff -u -p -r1.112 tty-keys.c
> --- tty-keys.c3 May 2019 18:00:19 - 1.112
> +++ tty-keys.c7 May 2019 10:50:09 -
> @@ -573,7 +573,6 @@ tty_keys_next(struct tty *tty)
> cc_t bspace;
> int delay, expired = 0, n;
> key_code key;
> - struct cmdq_item*item;
> struct mouse_event m = { 0 };
> struct key_event*event;
>
> @@ -732,9 +731,8 @@ complete_key:
> event = xmalloc(sizeof *event);
> event->key = key;
> memcpy(>m, , sizeof event->m);
> -
> - item = cmdq_get_callback(server_client_key_callback, event);
> - cmdq_append(c, item);
> + if (!server_client_handle_key(c, event))
> + free(event);
> }
>
> return (1);
Works for me!
ok solene@
Re: tmux: cannot select pane after prefix-b q
Hi
You have the right idea general idea of the problem. display-panes
blocks the queue until it is finished, so the key press isn't processed
until then, which is too late.
But your change defeats the purpose, the idea is that new key presses
should be queued after the commands inserted by previous key presses,
not before them.
Identify mode (display-panes) can just be treated specially I think.
Please try the diff below.
Thanks!
Index: server-client.c
===
RCS file: /cvs/src/usr.bin/tmux/server-client.c,v
retrieving revision 1.279
diff -u -p -r1.279 server-client.c
--- server-client.c 3 May 2019 20:44:24 - 1.279
+++ server-client.c 7 May 2019 10:50:07 -
@@ -986,7 +986,7 @@ server_client_assume_paste(struct sessio
* Handle data key input from client. This owns and can modify the key event it
* is given and is responsible for freeing it.
*/
-enum cmd_retval
+static enum cmd_retval
server_client_key_callback(struct cmdq_item *item, void *data)
{
struct client *c = item->client;
@@ -1204,6 +1204,44 @@ forward_key:
out:
free(event);
return (CMD_RETURN_NORMAL);
+}
+
+/* Handle a key event. */
+int
+server_client_handle_key(struct client *c, struct key_event *event)
+{
+ struct session *s = c->session;
+ struct window *w;
+ struct window_pane *wp = NULL;
+ struct cmdq_item*item;
+
+ /* Check the client is good to accept input. */
+ if (s == NULL || (c->flags & (CLIENT_DEAD|CLIENT_SUSPENDED)) != 0)
+ return (0);
+ w = s->curw->window;
+
+ /*
+* Key presses in identify mode are a special case. The queue might be
+* blocked so they need to processed immediately rather than queued.
+*/
+ if (c->flags & CLIENT_IDENTIFY) {
+ if (c->flags & CLIENT_READONLY)
+ return (0);
+ if (event->key >= '0' && event->key <= '9') {
+ window_unzoom(w);
+ wp = window_pane_at_index(w, event->key - '0');
+ }
+ server_client_clear_identify(c, wp);
+ return (0);
+ }
+
+ /*
+* Add the key to the queue so it happens after any commands queued by
+* previous keys.
+*/
+ item = cmdq_get_callback(server_client_key_callback, event);
+ cmdq_append(c, item);
+ return (1);
}
/* Client functions that need to happen every loop. */
Index: tmux.h
===
RCS file: /cvs/src/usr.bin/tmux/tmux.h,v
retrieving revision 1.888
diff -u -p -r1.888 tmux.h
--- tmux.h 7 May 2019 10:25:15 - 1.888
+++ tmux.h 7 May 2019 10:50:09 -
@@ -2012,7 +2012,7 @@ void server_client_set_identify(struct
voidserver_client_set_key_table(struct client *, const char *);
const char *server_client_get_key_table(struct client *);
int server_client_check_nested(struct client *);
-enum cmd_retval server_client_key_callback(struct cmdq_item *, void *);
+int server_client_handle_key(struct client *, struct key_event *);
struct client *server_client_create(int);
int server_client_open(struct client *, char **);
voidserver_client_unref(struct client *);
Index: tty-keys.c
===
RCS file: /cvs/src/usr.bin/tmux/tty-keys.c,v
retrieving revision 1.112
diff -u -p -r1.112 tty-keys.c
--- tty-keys.c 3 May 2019 18:00:19 - 1.112
+++ tty-keys.c 7 May 2019 10:50:09 -
@@ -573,7 +573,6 @@ tty_keys_next(struct tty *tty)
cc_t bspace;
int delay, expired = 0, n;
key_code key;
- struct cmdq_item*item;
struct mouse_event m = { 0 };
struct key_event*event;
@@ -732,9 +731,8 @@ complete_key:
event = xmalloc(sizeof *event);
event->key = key;
memcpy(>m, , sizeof event->m);
-
- item = cmdq_get_callback(server_client_key_callback, event);
- cmdq_append(c, item);
+ if (!server_client_handle_key(c, event))
+ free(event);
}
return (1);
Employment verification – request for contact details
Dear Sir/Madam, We are the appointed pre-employment screening representatives and have been asked to confirm that our Candidate was employed at OpenBSD Foundation, Paris. I would be grateful if you could provide contact details to you HR or to the person who would be able to confirm the dates of employment and position held and I will send a request for verification with the Candidate's details. Thank you in advance for your kind assistance. Kind regards, Sara Lipinska | Service Delivery Team | Gun Court, 70 Wapping Lane | London, E1W 2RD +44 (0) 1273 760 200 Tel | 501 2415 Internal Direct | [HireRight logo. All caps. The word HIRE is all black. The word RIGHT is all red. There are black brackets at the bottom left corner and the top right corner of the word RIGHT.] HireRight Limited is a limited liability company incorporated in England (registered number 4036193) whose registered office is at Gun Court, 70 Wapping Lane, London, E1W 2RD. This communication contains information that may be confidential, proprietary in nature, and may also be attorney-client privileged and/or work product privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by replying to this message and delete this e-mail immediately. Thank you for your cooperation. Please be advised that neither HireRight, its affiliates, its employees or agents accept liability for any errors, omissions or damages caused by delays of receipt or by any virus infection in this message or its attachments, or which may otherwise arise as a result of this e-mail transmission.
Re: OpenBSD 6.4 - Simple multicast routing
On 2019/05/06 01:05, Luthing wrote: > I finally got something working with the igmp-proxy package. > > But I am not sur this is stable because : > - I guess only multicast traffic advertised with IGMP packets will be > forwarded. > - The process sometimes crashes > > Somebody has an experience feedback on multicast routing within OpenBSD to > share? > And with igmpproxy? I'm no longer using an ISP with multicast, but I think you should try mcast-proxy instead of igmpproxy. (igmpproxy used to work, but maybe some changes in the network stack have broken things). These do all need IGMP to work.
Re: [PATCH] [www] faq/pf/pools.html - simplify loadbalancing section
On Mon, May 06, 2019 at 10:47:39PM +0200, Thomas Huber wrote: > Hi tech@, > > after struggeling a while to setup a load-balancer, I´ve finaly managed it. > At least not as I originally had in mind but it works. > > During this kind of learning process I read the faq quite often and over > again. > Now, after I dived into the rabit-hole of pf I think the /faq/pf/pools.html > site is little outdated and leads in the wrong directions when getting > started. > > My attached diff basically simplifies (from my point of view) the sections > for > loadbalancing outgoing traffic. I make havy use of interface modifiers - > which > are awesome btw - in the examples and removed some unnecessary rules in the > pf.conf example at the bottom. For me it gets more clear to read an example > with > this modifiers than an random IP adress or named macros. > Also I removed the special treatment of https connections. I´ld say that the > majority of http connections are https and the there are less "broken" > webapps > out there that utilize the IP for a login-session. Actually I didn´t came > across > this problems in the wild. But I put a hint how to handle it a the bottom > (stolen from the NAT section) but I would give this a priority anymore. > > And and I added the 'least-state' method to introduction. > > And it my first diff and my first contribution... hope its technicaly done > right > The diff is created wit git from the repo hosted on github.com: > > diff --git faq/pf/pools.html faq/pf/pools.html [...] > > -lan_net = "192.168.0.0/24" > -int_if = "dc0" > -ext_if1 = "fxp0" > -ext_if2 = "fxp1" > -ext_gw1 = "198.51.100.100" > -ext_gw2 = "203.0.113.200" > - > -# nat outgoing connections on each internet interface > -match out on $ext_if1 from $lan_net nat-to ($ext_if1) > -match out on $ext_if2 from $lan_net nat-to ($ext_if2) > +match out on pppoe0 from em0:network nat-to (pppoe0:0) > +match out on em2 from em0:network nat-to (em2:0) Hi I have no opinion about the technical changes, but you must keep the macros instead of adding your interface names and addresses everywhere in the examples instead of using the macros.
