Re: relayd multiple listen on same redirect
On 04/07/2020 14:59, Brian Brombacher wrote:
On Jul 3, 2020, at 3:34 AM, Kapetanakis Giannis
wrote:
Hi,
My setup in relayd is like this:
redirect radius {
listen on $radius_addr udp port radius interface $ext_if
pftag RELAYD_radius
sticky-address
forward to mode least-states check icmp demote carp
}
redirect radacct {
listen on $radius_addr udp port radacct interface $ext_if
pftag RELAYD_radius
sticky-address
forward to mode least-states check icmp demote carp
}
I want to combine it in one redirect but the redirect forwards it to the first
port defined in listen for both radius and radacct ports.
redirect radius {
listen on $radius_addr udp port radius interface $ext_if
listen on $radius_addr udp port radacct interface $ext_if
pftag RELAYD_radius
sticky-address
forward to mode least-states check icmp demote carp
}
Is there another way to do this or do I have to stick with two redirects?
thanks,
Giannis
Hi Giannis,
I have not tested your config or my advice for your config; however, my
assumptions are sticky-address is needed per udp port conversation for radius.
By contrast, if sticky was needed for the combination of both radius/radacct on
same backend host per source address or address/port, you cannot achieve that
reliably with least-states. I don’t know the radius protocols enough to know
the requirements.
Here’s my question after all that dribbling:
Have you tried using either of the following config options?
forward to destination
forward to nat
IIRC, in the past I had multiple TCP relay ports going to their specified ports
on the backend. I only needed to split things by address family (v4/6) for my
own purposes. I cannot remember if the directives above took port into
consideration. It might not be a far stretch to make that feasible with code
changes but I haven’t seen the relayd code paths in question so that’s a
complete guess (but I’m on my way to check ;). Also since I concentrated on
TCP relays, I don’t know how effective these directives would be for redirects.
My end config has separate relays per TCP service except passive FTP relaying.
Also, make sure your pf.conf has the right anchor. Only mentioning it because
your original email skips this detail. I doubt this would be missing if you
have a working setup already, so ignore if so.
Cheers,
Brian
Thanks for the answer Brian,
You 're probabaly right and least-states might not be the best choice.
My setup is a working one, but it only has one server (for now) in the
backend table so this hasn't come up so far.
I guess the best one would be
mode source-hash [key]
least-states [sticky-address]
The least-states option selects the address with the least active
states from a given address pool and considers given weights
associated with address(es). Weights can be specified between 1
and 65535. Addresses with higher weights are selected more often.
sticky-address can be specified to ensure that multiple connections
from the same source are mapped to the same redirection address.
Associations are destroyed as soon as there are no longer states
which refer to them; in order to make the mappings last beyond the
lifetime of the states, increase the global options with set
timeout src.track.
source-hash [key] [sticky-address]
The source-hash option uses a hash of the source address to
determine the redirection address, ensuring that the redirection
address is always the same for a given source. An optional key can
be specified after this keyword either in hex or as a string; by
default pfctl(8) randomly generates a key for source-hash every
time the ruleset is reloaded. sticky-address is as described
above.
G
Re: ls -R bug?
Man, it goes to show you that with complex systems it's still worth reporting potential bugs even with heavily used utilities. On Sat, Jul 4, 2020 at 2:23 PM Brian Brombacher wrote: > > > On Jul 4, 2020, at 3:10 PM, Brian Brombacher > wrote: > > > > Hmm... > > > > /bin/ls, a utility that has existed since 1960’s. > > > > This is not a bug. > > > > https://en.m.wikipedia.org/wiki/Ls > > > > Please disregard this poor advice. Obviously this isn’t the 1960’s and it > ain’t the same code :) > > There was a bug as you identified correctly. > >
Re: strlcpy version speed tests?
On 1/7/20 10:05 pm, Luke Small wrote: > Are you clinging to traditions for some purpose? Are you posting random pieces of code and asking for critique on them for no apparent reason for some purpose? To be clear, this was the sum and total of your first message in this thread (excluding attachment for brevity): > I made a couple different versions if anybody is interested! > -Luke Why? Why strlcpy? Why not strcpy? Or memcpy? Why not the whole libc? Zero context. The email headers and the C source code attachment are 99% of the whole email. None of those headers start with 'References:' or 'In-Reply-To:', it was a completely detached email with no link to any existing discussion, either declared explicitly or implied by its content. Your single line message seemed like it was asking: "Am I allowed to bench-test this?" As if we have the power to stop you. Go ahead, bench-test away! As to why the stock OpenBSD implementation is written a particular way? Well, likely a big part of it is wanting the code to behave the same way in multiple scenarios, e.g. gcc vs clang, AMD64 vs ARM64 vs i386 vs mips64 vs sparc vs … you get the picture. Assembly is the "fastest" option, but requires one "implementation" for each processor architecture, and receives no benefit from improvements in optimising compilers. C means it's written *once* and ideally will perform identically for all systems, whilst also being easier to understand and maintain. If a problem is found on AMD64 for example, it's merely testing a fix already committed there on other architectures to ensure they don't break. Versus fixing it about 6 or 7 times, each time figuring out how to express the same "fix" in _that_ processor's assembly dialect. I think it naïve to assume that an implementation written to run faster on one processor architecture and compiled with one compiler will universally run faster on all other processor+compiler combinations. Anyway, I've spent more words on this than I care to. So if you don't mind, I'll be instructing my email client to ignore this thread from here on in. Regards, -- Stuart Longland (aka Redhatter, VK4MSL) I haven't lost my mind... ...it's backed up on a tape somewhere.
Re: ls -R bug?
On Sat, 4 Jul 2020 at 19:59, Richard Ipsum wrote: > > Hi, > > Output of ls -R between OpenBSD and GNU coreutils seems to differ, > OpenBSD ls -R will apparently list "hidden" directories like .git, > whereas GNU coreutils will not, is this expected behaviour or a bug? > Funny, because this seems to validate what you are reporting: oc@OpenBSD:~$ ls -R oc-backup test ./.local/share: xorg ./.local/share/xorg: Xorg.0.log Xorg.0.log.old ./oc-backup: docs mbox ./oc-backup/docs: bgpd.confman-todo patch.patch root-mail bug oc-mail robots.txt sudo.log ./test: dmesg fstab index.html uyiuyi filefstab.dos ls.ps file.bakfstab.tropenbsd-tips-wip file.orig fstab.unix test.wav However: oc@OpenBSD:~$ mkdir .hidden oc@OpenBSD:~$ touch .hidden/test-file oc@OpenBSD:~$ ls -R It looks like "ls -R" is showing some hidden directories but not all. -- Ottavio Caruso
Re: ls -R bug?
> On Jul 4, 2020, at 3:10 PM, Brian Brombacher wrote: > > Hmm... > > /bin/ls, a utility that has existed since 1960’s. > > This is not a bug. > > https://en.m.wikipedia.org/wiki/Ls > Please disregard this poor advice. Obviously this isn’t the 1960’s and it ain’t the same code :) There was a bug as you identified correctly.
Re: ls -R bug?
On Sat, Jul 04, 2020 at 02:16:29PM -0600, Todd C. Miller wrote: > On Sat, 04 Jul 2020 20:59:08 +0200, Richard Ipsum wrote: > > > Output of ls -R between OpenBSD and GNU coreutils seems to differ, > > OpenBSD ls -R will apparently list "hidden" directories like .git, > > whereas GNU coreutils will not, is this expected behaviour or a bug? > > I think this is actually a bug. Historic behavior is to not descend > into directories that begin with a '.'. Our existing ls code looks > like it is written to support that behavior but is missing one > thing. Hi Todd, Thanks for the explanation! Richard
Re: ls -R bug?
I’ll be explicit. Did the OP run ls(1) as superuser? See -A flag in man ls We have no idea. > On Jul 4, 2020, at 3:44 PM, Brian Brombacher wrote: > > > >>> On Jul 4, 2020, at 3:38 PM, Ottavio Caruso >>> wrote: >>> >>> On Sat, 4 Jul 2020 at 19:59, Richard Ipsum wrote: >>> >>> Hi, >>> >>> Output of ls -R between OpenBSD and GNU coreutils seems to differ, >>> OpenBSD ls -R will apparently list "hidden" directories like .git, >>> whereas GNU coreutils will not, is this expected behaviour or a bug? >>> >> >> Funny, because this seems to validate what you are reporting: >> >> oc@OpenBSD:~$ ls -R >> oc-backup test >> >> ./.local/share: >> xorg >> >> ./.local/share/xorg: >> Xorg.0.log Xorg.0.log.old >> >> ./oc-backup: >> docs mbox >> >> ./oc-backup/docs: >> bgpd.confman-todo patch.patch root-mail >> bug oc-mail robots.txt sudo.log >> >> ./test: >> dmesg fstab index.html uyiuyi >> filefstab.dos ls.ps >> file.bakfstab.tropenbsd-tips-wip >> file.orig fstab.unix test.wav >> >> >> >> However: >> >> oc@OpenBSD:~$ mkdir .hidden >> oc@OpenBSD:~$ touch .hidden/test-file >> oc@OpenBSD:~$ ls -R >> >> >> >> It looks like "ls -R" is showing some hidden directories but not all. >> >> -- >> Ottavio Caruso >> > > man ls > man ksh > >
Re: ls -R bug?
On Sat, 04 Jul 2020 20:59:08 +0200, Richard Ipsum wrote:
> Output of ls -R between OpenBSD and GNU coreutils seems to differ,
> OpenBSD ls -R will apparently list "hidden" directories like .git,
> whereas GNU coreutils will not, is this expected behaviour or a bug?
I think this is actually a bug. Historic behavior is to not descend
into directories that begin with a '.'. Our existing ls code looks
like it is written to support that behavior but is missing one
thing.
- todd
Index: bin/ls/ls.c
===
RCS file: /cvs/src/bin/ls/ls.c,v
retrieving revision 1.51
diff -u -p -u -r1.51 ls.c
--- bin/ls/ls.c 13 Sep 2018 15:23:32 - 1.51
+++ bin/ls/ls.c 4 Jul 2020 20:13:39 -
@@ -369,8 +369,11 @@ traverse(int argc, char *argv[], int opt
switch (p->fts_info) {
case FTS_D:
if (p->fts_name[0] == '.' &&
- p->fts_level != FTS_ROOTLEVEL && !f_listdot)
+ p->fts_level != FTS_ROOTLEVEL && !f_listdot) {
+ if (fts_set(ftsp, p, FTS_SKIP))
+ err(1, "%s", p->fts_path);
break;
+ }
/*
* If already output something, put out a newline as
Re: ls -R bug?
On 2020-07-04, Ottavio Caruso wrote: > On Sat, 4 Jul 2020 at 19:59, Richard Ipsum wrote: >> >> Hi, >> >> Output of ls -R between OpenBSD and GNU coreutils seems to differ, >> OpenBSD ls -R will apparently list "hidden" directories like .git, >> whereas GNU coreutils will not, is this expected behaviour or a bug? Try "/bin/ls" to avoid the effects of whatever you have "ls" aliased to. > Funny, because this seems to validate what you are reporting: > > oc@OpenBSD:~$ ls -R > oc-backup test > > ./.local/share: > xorg > > ./.local/share/xorg: > Xorg.0.log Xorg.0.log.old > > ./oc-backup: > docs mbox > > ./oc-backup/docs: > bgpd.confman-todo patch.patch root-mail > bug oc-mail robots.txt sudo.log > > ./test: > dmesg fstab index.html uyiuyi > filefstab.dos ls.ps > file.bakfstab.tropenbsd-tips-wip > file.orig fstab.unix test.wav > > .local is a "hidden" directory (starts with .) .local/share is not Note you do not get a directory listing of .local, only of the contents > > However: > > oc@OpenBSD:~$ mkdir .hidden > oc@OpenBSD:~$ touch .hidden/test-file > oc@OpenBSD:~$ ls -R .hidden is a hidden directory > > > > It looks like "ls -R" is showing some hidden directories but not all. > This pretty much all matches between base and coreutils ls as long as they are given the same options. Slight difference in that coreutils print .: on the first line and base ls doesn't.
Re: Relayd with TLS and non-TLS backends - bug
Henry Bonath writes: > I would like to chime in here and confirm that I am seeing very > similar behavior with HAProxy on OpenBSD 6.7, > I was preparing to create my own post on this issue until I saw your thread. > I too believe this is a bug. We saw the same thing after upgrading our proxy host from 6.5 -> 6.7. Since our use case was such a simple one, we tossed haproxy overboard and moved things over to relayd. --lyndon
Re: It's been awhile
Happy Birthday Austin On Sat, Jul 4, 2020 at 9:08 AM Austin Hook wrote: > > Just noticed your post about, among other things, the old big puffy > wireframe stickers. Nice story about getting back into OpenBSD. > > There are quite a few of those stickers left over from the old days, when > we ran the first version of the OpenBSD store. Lifetime warrantee on > anything we ever sold -- well if there's still any left; but it's my > lifetime I'm talking about, so wish me well, birthday coming up next week > or so -- getting very close to 80. Will mail you one. > > Casual discussions sometimes still occur on the advocacy@ mailing list. > but few folks subscribe any more. It should be revived. > > Austin > > > On Wed, 10 Jun 2020, Greg Thomas wrote: > > > Hey all, > > > > Wow, it looks like I haven't run OpenBSD since 2006 according to the misc > > archives. I guess I got too busy with my shit corporate job which I quit > > in 2014 to roast coffee full time. And then I guess I got too busy to > move > > on from my comfort zone as my old OpenBSD laptops died. But with the > > current lockdown in Los Angeles giving me a little bit of time to explore > > tech along with Windows 7 being unsupported I figured I'd try to move > back > > to my favorite OS. I bought a pretty much unused Thinkpad X220 on Ebay > > (it's in better shape than the last X220 was when I bought that one 6 > years > > ago, so super score). > > > > So, I'm still refamiliarizing myself with OpenBSD and was wondering what > > the biggest changes have been for a regular user since 4.0? The first > > thing I've seen is rcctl. > > > > Also, has anybody ever reprinted the large wireframe Puffy sticker from > > around 15 years ago, or still have one for trade/sale? I still have the > > T40 with my last one stuck to it. > > > > https://photos.app.goo.gl/QTPhKrMraZ4m4oPUA > > > > I'm thinking about trying to pull it off to stick it on to this X220 > > somehow. > > > > I also did a little poking around last night for window managers/desktop > > environments. I used to use WindowMaker but I'm thinking about trying > > something more featureful. So far during my searching I've seen > > recommendations for cwm in base, and then stuff like spectrwm and MATE. > > I'm pretty sure I'm *not *going to stick with fvwm. Is there anything I > > absolutely have to check out before I add windowmaker (or maybe xfce)?. > > > > The only problem I've had so far is I have no wired Ethernet here, urndis > > was failing me with my OnePlus 6t phone and I just couldn't take the time > > to troubleshoot, and I just couldn't seem to add the iwn firmware after > > copying it to /tmp from my USB stick (I got "file:/tmp/: empty" after > > running fw_update -v -p /tmp iwn) so I took my laptop to my neighbor's > > ethernet and easily added iwn. Running fw_update -vn -p /tmp now seems > to > > work fine, I'm not sure what I was doing wrong previously. > > > > I've added chrome obviously, and am happy to see my label app on > Avery.com > > works fine which is the only thing other than email and Google Docs that > I > > really need for the coffee business. > > > > I also just installed Audacity because I started a noise project about a > > year ago so I need to do some basic sound editing. I'll give the GIMP a > > try again for my photography but I may hang on to my old X220 to use > > Windows 7 and CS4 PS offline. And now that I'm done with this email I'm > > going to watch the end of Charlie Jade with VLC. > > > > Thanks folks! If this is inappropriate for misc let me know which forums > > are best to join, for whatever reasons I'm not a reddit user yet but if > > need be I'll start an account there for OpenBSD, coffee, and noise. > > > > Greg > > > > get.misc.open...@gmail.com /home/austin/mail/newmisc 56199 > > >
Re: ls -R bug?
> On Jul 4, 2020, at 3:38 PM, Ottavio Caruso > wrote: > > On Sat, 4 Jul 2020 at 19:59, Richard Ipsum wrote: >> >> Hi, >> >> Output of ls -R between OpenBSD and GNU coreutils seems to differ, >> OpenBSD ls -R will apparently list "hidden" directories like .git, >> whereas GNU coreutils will not, is this expected behaviour or a bug? >> > > Funny, because this seems to validate what you are reporting: > > oc@OpenBSD:~$ ls -R > oc-backup test > > ./.local/share: > xorg > > ./.local/share/xorg: > Xorg.0.log Xorg.0.log.old > > ./oc-backup: > docs mbox > > ./oc-backup/docs: > bgpd.confman-todo patch.patch root-mail > bug oc-mail robots.txt sudo.log > > ./test: > dmesg fstab index.html uyiuyi > filefstab.dos ls.ps > file.bakfstab.tropenbsd-tips-wip > file.orig fstab.unix test.wav > > > > However: > > oc@OpenBSD:~$ mkdir .hidden > oc@OpenBSD:~$ touch .hidden/test-file > oc@OpenBSD:~$ ls -R > > > > It looks like "ls -R" is showing some hidden directories but not all. > > -- > Ottavio Caruso > man ls man ksh
Re: ls -R bug?
Hmm... /bin/ls, a utility that has existed since 1960’s. This is not a bug. https://en.m.wikipedia.org/wiki/Ls > On Jul 4, 2020, at 3:02 PM, Richard Ipsum wrote: > > Hi, > > Output of ls -R between OpenBSD and GNU coreutils seems to differ, > OpenBSD ls -R will apparently list "hidden" directories like .git, > whereas GNU coreutils will not, is this expected behaviour or a bug? > > Thanks, > Richard >
ls -R bug?
Hi, Output of ls -R between OpenBSD and GNU coreutils seems to differ, OpenBSD ls -R will apparently list "hidden" directories like .git, whereas GNU coreutils will not, is this expected behaviour or a bug? Thanks, Richard
Re: It's been awhile
Just noticed your post about, among other things, the old big puffy wireframe stickers. Nice story about getting back into OpenBSD. There are quite a few of those stickers left over from the old days, when we ran the first version of the OpenBSD store. Lifetime warrantee on anything we ever sold -- well if there's still any left; but it's my lifetime I'm talking about, so wish me well, birthday coming up next week or so -- getting very close to 80. Will mail you one. Casual discussions sometimes still occur on the advocacy@ mailing list. but few folks subscribe any more. It should be revived. Austin On Wed, 10 Jun 2020, Greg Thomas wrote: > Hey all, > > Wow, it looks like I haven't run OpenBSD since 2006 according to the misc > archives. I guess I got too busy with my shit corporate job which I quit > in 2014 to roast coffee full time. And then I guess I got too busy to move > on from my comfort zone as my old OpenBSD laptops died. But with the > current lockdown in Los Angeles giving me a little bit of time to explore > tech along with Windows 7 being unsupported I figured I'd try to move back > to my favorite OS. I bought a pretty much unused Thinkpad X220 on Ebay > (it's in better shape than the last X220 was when I bought that one 6 years > ago, so super score). > > So, I'm still refamiliarizing myself with OpenBSD and was wondering what > the biggest changes have been for a regular user since 4.0? The first > thing I've seen is rcctl. > > Also, has anybody ever reprinted the large wireframe Puffy sticker from > around 15 years ago, or still have one for trade/sale? I still have the > T40 with my last one stuck to it. > > https://photos.app.goo.gl/QTPhKrMraZ4m4oPUA > > I'm thinking about trying to pull it off to stick it on to this X220 > somehow. > > I also did a little poking around last night for window managers/desktop > environments. I used to use WindowMaker but I'm thinking about trying > something more featureful. So far during my searching I've seen > recommendations for cwm in base, and then stuff like spectrwm and MATE. > I'm pretty sure I'm *not *going to stick with fvwm. Is there anything I > absolutely have to check out before I add windowmaker (or maybe xfce)?. > > The only problem I've had so far is I have no wired Ethernet here, urndis > was failing me with my OnePlus 6t phone and I just couldn't take the time > to troubleshoot, and I just couldn't seem to add the iwn firmware after > copying it to /tmp from my USB stick (I got "file:/tmp/: empty" after > running fw_update -v -p /tmp iwn) so I took my laptop to my neighbor's > ethernet and easily added iwn. Running fw_update -vn -p /tmp now seems to > work fine, I'm not sure what I was doing wrong previously. > > I've added chrome obviously, and am happy to see my label app on Avery.com > works fine which is the only thing other than email and Google Docs that I > really need for the coffee business. > > I also just installed Audacity because I started a noise project about a > year ago so I need to do some basic sound editing. I'll give the GIMP a > try again for my photography but I may hang on to my old X220 to use > Windows 7 and CS4 PS offline. And now that I'm done with this email I'm > going to watch the end of Charlie Jade with VLC. > > Thanks folks! If this is inappropriate for misc let me know which forums > are best to join, for whatever reasons I'm not a reddit user yet but if > need be I'll start an account there for OpenBSD, coffee, and noise. > > Greg > > get.misc.open...@gmail.com /home/austin/mail/newmisc 56199 >
Re: Relayd with TLS and non-TLS backends - bug
> On Jul 3, 2020, at 7:17 PM, Henry Bonath wrote: > > Daniel, > > Thanks for taking the time to test this out. > I just reloaded a test machine from scratch with -current and > installed the HAProxy 2.0.15-4f39279 package. > I loaded a very basic config file, and am also seeing the same exact > issue on this one as well. > Very strange that you are not - > Would you mind sharing any additional details of your config file? > Is there anything special about the certificate you have on the backend > server? > > I would love to understand what is going on here and what the > difference is with my experience. > >> On Thu, Jul 2, 2020 at 4:38 PM Daniel Jakots wrote: >> >> On Thu, 2 Jul 2020 14:00:48 -0400, Henry Bonath >> wrote: >> >>> Note the missing Client Hello on the 6.7 machine as it jumps to >>> Application Data straight away. >>> Configuration files for HAProxy are identical on both systems. >>> >>> I'm currently spinning up a machine on -CURRENT just to see if there >>> is any difference, >>> as there is a newer version of HAProxy in packages under Snapshots. >>> >>> I was initially going to try to reach out to the package maintainer >>> for HAProxy but if this is happening in Relayd, then this "feels >>> like" a de-facto bug. I wonder if NGINX would exhibit the same >>> behavior. >>> >>> Has anyone else experienced such behavior with Load-Balancing TLS >>> Backends since upgrading to 6.7? >> >> I don't use TLS for my backend (the only backend I use nowadays is on >> localhost) so I can't speak for 6.7 (I only use -current, and when >> -current was 6.7, I didn't test that). >> >> I just tested my -current haproxy using another -current host of mine >> running nginx as a backend with TLS and it worked fine. >> >> backend https >> option forwardfor >> server web1 ln.chown.me:443 check ssl verify none >> >> and also with "verify required ca-file /etc/ssl/cert.pem" >> >> >> Maybe some libressl fix happened on -current was not deemed critical >> enough to be backported to 6.7? >> >> Cheers, >> Daniel > This thread is conflating two issues: 1) Henry’s original relayd.conf is wrong. Notice the TLS connection attempt to port 80 in his relayd logs. This will never work. See my email regarding two relays required. 2) There was conversation about a compatibility issue with LibreSSL in 6.7 release. Check the archives.
Re: Relayd with TLS and non-TLS backends - bug
> On Jun 11, 2020, at 4:28 PM, Toyam Cox wrote:
>
> Hello Misc,
>
> Full config at end of email.
>
> I've discussed the below in #openbsd on freenode, and was told to come
> here. At present, I have a setup where I need multiple unrelated
> servers under a single IP address. I used relayd to do https
> interception, read the Host header, and make decisions.
>
> The very relevant part of my config is this:
>
> forward to port 80
> forward with tls to port 443
>
> The order here does not matter (unlike most relayd configs, I know,
> but I've tested in my configuration and it works).
>
> When I have "with tls" on that second line, I see error lines like:
> relay web, session 3 (1 active), 0, [redacted] -> 10.0.0.102:80, TLS
> handshake error: handshake failed: error:14FFF3E7:SSL
> routines:(UNKNOWN)SSL_internal:unknown failure occurred, GET:
> Undefined error: 0
>
> and, unhelpfully, relayd responds with no response. There is no
> return. Or, as curl puts it: curl: (52) Empty reply from server
>
> When I remove "with tls" then I successfully reach the http backend,
> but since the https backend requires ssl, that connection no longer
> works. So it seems that 'with tls" affects all "forward" clauses, not
> just the one to which it's attached.
>
> I believe this to be a bug.
>
> cat >/etc/relayd.conf < table { "10.0.0.101" }
> table { "10.0.0.102" }
> # obviously obfuscated some values
>
> interval 5
> timeout 1000
>
> log connection
>
> http protocol web {
> return error
>
> match header set "X-Client-IP" value "$REMOTE_ADDR:$REMOTE_PORT"
> match header set "X-Forwarded-For" value "$REMOTE_ADDR"
> match header set "X-Forwarded-By" value "$SERVER_ADDR:$SERVER_PORT"
>
> http websockets
> pass request quick header "Host" value "myhost.example.com" path
> "/Client/*" forward to
> pass request quick header "Host" value "otherhost.example.com" forward
> to
>
> block
> }
>
> relay web {
> listen on 10.0.0.100 port 443 tls
> protocol web
>
> forward to port 80 check http "/webservice.asmx" code 405
> forward with tls to port 443 check https
> "/Client/SupportedBrowsers.html" host "myhost.example.com" code 200
> }
> EOF
>
Hi Toyam,
Split http and https into two separate relay stanzas.
The “with tls” will be needed on your https relay and not the http backhaul. I
believe this gets what you want.
I do not think this is a bug, but perhaps a design choice by the developers.
Cheers,
Brian
Re: strlcpy version speed tests?
On Sat, Jul 04, 2020 at 09:07:35AM -0400, Brian Brombacher wrote: > > >> On Jul 1, 2020, at 1:14 PM, gwes wrote: > >> > >> On 7/1/20 8:05 AM, Luke Small wrote: > >> I spoke to my favorite university computer science professor who said > >> ++n is faster than n++ because the function needs to store the initial > >> value, increment, then return the stored value in the former case, > >> while the later merely increments, and returns the value. Apparently, > >> he is still correct on modern hardware. > > For decades the ++ and *p could be out of order, in different > > execution units, writes speculatively queued, assigned to aliased registers, > > etc, etc, etc. > > > > Geoff Steckel > > Hey Luke, > > I love the passion but try to focus your attention on the fact that their are > multiple architectures supported and compiler optimizations are key here. Go > with Marc’s approach using arch/ asm. Implementations can be made over time > for the various arch’s, if such an approach is desirable by the project. You > can pull a well-optimized version based on your code, for your arch, and then > slim it down a bunch. > > Cheers, > Brian > > [Not a project developer. Just an observer.] > > Another data point for consideration: the pdp11 instruction set had post-increment and pre-decrement indirect memory reference instructions. If I'm not mistaken, using pre-increment or post decrement on this architecture would impose a penalty. So your university computer science professor making such sweeping statements maybe doesn't deserve to be your favorite. -Otto
Re: strlcpy version speed tests?
>> On Jul 1, 2020, at 1:14 PM, gwes wrote: >> >> On 7/1/20 8:05 AM, Luke Small wrote: >> I spoke to my favorite university computer science professor who said >> ++n is faster than n++ because the function needs to store the initial >> value, increment, then return the stored value in the former case, >> while the later merely increments, and returns the value. Apparently, >> he is still correct on modern hardware. > For decades the ++ and *p could be out of order, in different > execution units, writes speculatively queued, assigned to aliased registers, > etc, etc, etc. > > Geoff Steckel Hey Luke, I love the passion but try to focus your attention on the fact that their are multiple architectures supported and compiler optimizations are key here. Go with Marc’s approach using arch/ asm. Implementations can be made over time for the various arch’s, if such an approach is desirable by the project. You can pull a well-optimized version based on your code, for your arch, and then slim it down a bunch. Cheers, Brian [Not a project developer. Just an observer.]
Re: relayd multiple listen on same redirect
> On Jul 3, 2020, at 3:34 AM, Kapetanakis Giannis
> wrote:
>
> Hi,
>
> My setup in relayd is like this:
>
> redirect radius {
> listen on $radius_addr udp port radius interface $ext_if
> pftag RELAYD_radius
> sticky-address
> forward to mode least-states check icmp demote carp
> }
>
> redirect radacct {
> listen on $radius_addr udp port radacct interface $ext_if
> pftag RELAYD_radius
> sticky-address
> forward to mode least-states check icmp demote carp
> }
>
> I want to combine it in one redirect but the redirect forwards it to the
> first port defined in listen for both radius and radacct ports.
>
> redirect radius {
> listen on $radius_addr udp port radius interface $ext_if
> listen on $radius_addr udp port radacct interface $ext_if
> pftag RELAYD_radius
> sticky-address
> forward to mode least-states check icmp demote carp
> }
>
> Is there another way to do this or do I have to stick with two redirects?
>
> thanks,
>
> Giannis
Hi Giannis,
I have not tested your config or my advice for your config; however, my
assumptions are sticky-address is needed per udp port conversation for radius.
By contrast, if sticky was needed for the combination of both radius/radacct on
same backend host per source address or address/port, you cannot achieve that
reliably with least-states. I don’t know the radius protocols enough to know
the requirements.
Here’s my question after all that dribbling:
Have you tried using either of the following config options?
forward to destination
forward to nat
IIRC, in the past I had multiple TCP relay ports going to their specified ports
on the backend. I only needed to split things by address family (v4/6) for my
own purposes. I cannot remember if the directives above took port into
consideration. It might not be a far stretch to make that feasible with code
changes but I haven’t seen the relayd code paths in question so that’s a
complete guess (but I’m on my way to check ;). Also since I concentrated on
TCP relays, I don’t know how effective these directives would be for redirects.
My end config has separate relays per TCP service except passive FTP relaying.
Also, make sure your pf.conf has the right anchor. Only mentioning it because
your original email skips this detail. I doubt this would be missing if you
have a working setup already, so ignore if so.
Cheers,
Brian
