Re: ls -R bug?

2020-07-04 Thread Greg Thomas
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?

2020-07-04 Thread Stuart Longland
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?

2020-07-04 Thread Ottavio Caruso
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?

2020-07-04 Thread Brian Brombacher


> 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?

2020-07-04 Thread Richard Ipsum
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?

2020-07-04 Thread Brian Brombacher
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?

2020-07-04 Thread Todd C . Miller
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?

2020-07-04 Thread Stuart Henderson
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

2020-07-04 Thread Lyndon Nerenberg
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

2020-07-04 Thread Greg Thomas
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?

2020-07-04 Thread Brian Brombacher



> 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?

2020-07-04 Thread Brian Brombacher
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?

2020-07-04 Thread Richard Ipsum
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

2020-07-04 Thread Austin Hook


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

2020-07-04 Thread Brian Brombacher


> 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

2020-07-04 Thread Brian Brombacher


> 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?

2020-07-04 Thread Otto Moerbeek
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?

2020-07-04 Thread Brian Brombacher


>> 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

2020-07-04 Thread Brian Brombacher


> 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