lost pf state - disappeared before expiration?

2020-05-17 Thread Paul B. Henson
I'm trying to set a longer timeout on a udp state, and for some reason it
seems to be disappearing before the expiration 8-/.

There are 3 rules involved:

pass in quick on vlan110 proto udp from any to port = 9430 tag VOIP_UDP keep 
state (udp.multiple 360)

pass out quick on $ext_if proto udp tagged VOIP_UDP keep state (udp.multiple 
360)

match out on $ext_if from 10.128.0.0/16 nat-to { $ext_vip } sticky-address

I turned on pf debugging, when the connection is created I see:


May 17 15:36:39 lisa /bsd: pf: key search, in on vlan110: UDP wire: (0) 
10.128.110.73:9430 198.148.6.55:9430
May 17 15:36:39 lisa /bsd: pf: key setup: UDP wire: (0) 10.128.110.73:9430 
198.148.6.55:9430 stack: (0) -
May 17 15:36:39 lisa /bsd: pf: key search, out on em2: UDP wire: (0) 
198.148.6.55:9430 10.128.110.73:9430
May 17 15:36:39 lisa /bsd: pf: key setup: UDP wire: (0) 198.148.6.55:9430 
96.251.22.157:63529 stack: (0) 198.148.6.55:9430 10.128.110.73:9430

and there are state entries:

all udp 198.148.6.55:9430 <- 10.128.110.73:9430   MULTIPLE:MULTIPLE
   age 00:02:21, expires in 00:05:00, 29:29 pkts, 14166:18501 bytes, rule 63
all udp 96.251.22.157:55205 (10.128.110.73:9430) -> 198.148.6.55:9430   
MULTIPLE:MULTIPLE
   age 00:02:21, expires in 00:05:00, 29:29 pkts, 14166:18501 bytes, rule 48, 
source-track

However, right after the 5 minute mark the states disappear. The last pf log
entries are;

May 17 15:38:47 lisa /bsd: pf: key search, in on vlan110: UDP wire: (0) 
10.128.110.73:9430 198.148.6.55:9430
May 17 15:38:47 lisa /bsd: pf: key search, out on em2: UDP wire: (0) 
198.148.6.55:9430 10.128.110.73:9430

I was hoping to see something about expiration in the pf debug logs but
this is all that appears to be available.

Any idea why these states would go away when there is 5 minutes left
before the expiration?

Thanks much...



67.html doesn't mention removal of rebound

2020-05-17 Thread jungle boogie

Hi,

rebound(8) was remove in January, but I don't see an entry in 
plus67.html or 67.html.


Should it be mentioned in either one these pages?

https://www.openbsd.org/plus67.html
https://www.openbsd.org/faq/current.html

thanks,
j.b.



Re: RT_TABLEID_MAX behavior changed?

2020-05-17 Thread Bars Bars
it seems the things work just when i rebuild userland completely (im pretty
sure i did it only with compiling kernel in past, correct me if i wrong?).

btw, questions for the Devs.
Looking at the cvs history, i really worried that you do not expand
rt_tableid_max limit for the years, moreover now its actually 8 bits
shorter than it was before loopback to rdomain map. There are many people
with more than such a number of vpns, for example if they setup centralized
vpns setup, or border inter AS router role on the box.


вс, 17 мая 2020 г., 10:25 Bars Bars :

> Hey, guys.
>
> I always used the rt_tableid_max expanded to 16 bit range in past releases
> 5.x and after rebuilding the kernel it worked immediately.
> But now I installed 6.6 on the new system, and after changing
> rt_tableid_max (and new rt_tableid_mask and bits values too), my whole
> userland throw an rtable / rdomain too large error.
> Is there behaviour change?
> The only thing changed (as i know) it is news net/trable.c struct to map
> loopback to domain, where there is only 8 unused bits to which i can expand
> tableid value.
>
>


Re: [www] list of associated projects: adding rpki-client

2020-05-17 Thread Ingo Schwarze
Hi Alex,

Alex Naumov wrote on Wed, May 13, 2020 at 01:10:47PM +0200:

> since rpki-client has its own home page like other "associated projects",
> it makes sense to add a new link.

Committed with a tweak; i put it next to OpenBGPD.

Thanks for the suggestion,
  Ingo


> Index: index.html
> ===
> RCS file: /cvs/www/index.html,v
> retrieving revision 1.740
> diff -u -p -r1.740 index.html
> --- index.html24 Apr 2020 12:33:07 -  1.740
> +++ index.html13 May 2020 11:08:11 -
> @@ -106,5 +106,6 @@
>OpenIKED,
>https://mandoc.bsd.lv;>mandoc,
>https://www.libressl.org;>LibreSSL
> +  https://www.rpki-client.org/;>rpki-client
>  
>



Re: setsockopt(2): weird behavior

2020-05-17 Thread Theo de Raadt
I've misinterpreted the situation.

Previous to 6.7, and probably in most other operating systems, this
was limited to 65535 / 100 or 644.

But now the range is extended.  Wait about 3 days, upgrade, etc.



Theo de Raadt  wrote:

> We supply source code, so this took under 60 seconds to find:
> 
> SO_RCVTIMEO is in uipc_socket.c
> 
> memcpy(, mtod(m, struct timeval *), sizeof tv);
> if (!timerisvalid())
> return (EINVAL);
> nsecs = TIMEVAL_TO_NSEC();
> if (nsecs == UINT64_MAX)
> return (EDOM);
> 
> The timeout is handled as nseconds.  Here is the diff which changes it.
> 
> revision 1.239
> date: 2020/01/15 13:17:35;  author: mpi;  state: Exp;  lines: +30 -14;  
> commitid: rd4e6hacw84gya1H;
> Keep socket timeout intervals in nsecs and use them with tsleep_nsec(9).
> 
> Introduce and use TIMEVAL_TO_NSEC() to convert SO_RCVTIMEO/SO_SNDTIMEO
> specified values into nanoseconds.  As a side effect it is now possible
> to specify a timeout larger that (USHRT_MAX / 100) seconds.
> 
> To keep code simple `so_linger' now represents a number of seconds with
> 0 meaning no timeout or 'infinity'.
> 
> Yes, the 0 -> INFSLP API change makes conversions complicated as many
> timeout holders are still memset()'d.
> 
> Inputs from cheloha@ and bluhm@, ok bluhm@
> 
> 
> --
> Martin I think that change is wrong.  The precision increase loses far
> too much range, and this should be converted back to a lower-resolution
> value.  The tradeoff is wrong, The range should remain HUGE.  The range
> is far more important than the precision.
> 
> I also think the addition of an EDOM errno here is unreasonable. 
> 
>  33 EDOM Numerical argument out of domain. A numerical input argument was
>  outside the defined domain of the mathematical function.
> 
> This is the only time this errno is returned from the kernel, and I really
> dislike it.
> 
> 
> Matthias  wrote:
> 
> > Hi,
> > 
> > I've noticed some weird behavior of the setsockopt(2) system call.
> > 
> > Given the following little test program ...
> > 
> > 
> > 
> > 
> > #include 
> > #include 
> > 
> > #include 
> > 
> > int
> > main(int argc, char *argv[])
> > {
> > int  fd[2];
> > struct timeval   t = { .tv_sec = 650, .tv_usec = 0 };
> > 
> > if (socketpair(AF_UNIX, SOCK_STREAM, PF_UNSPEC, fd) == -1)
> > err(1, "socketpair");
> > 
> > while (1) {
> > if (setsockopt(fd[0], SOL_SOCKET, SO_RCVTIMEO, ,
> > sizeof(t)) == -1)
> > err(1, "setsockopt");
> > 
> > printf("%llu: OK.\n", t.tv_sec++);
> > }
> > 
> > return (0);
> > }
> > 
> > 
> > 
> > ... this is the output:
> > 
> > # ./test
> > 650: OK.
> > 651: OK.
> > 652: OK.
> > 653: OK.
> > 654: OK.
> > 655: OK.
> > test: setsockopt: Numerical argument out of domain
> > #
> > 
> > Does anybody know why tv_sec=656 an illegal value for SO_RCVTIMEO while
> > 655 still appears to be alright? I was expecting this to happen for much
> > larger tv_sec values, something like ULLONG_MAX / 10ULL.
> > 
> > I was using an amd64 machine running 6.6-stable to compile and run the
> > test code.
> > 
> > Any help is being appreciated.
> > 
> > Matthias
> > 
> > 
> 



Re: setsockopt(2): weird behavior

2020-05-17 Thread Theo de Raadt
We supply source code, so this took under 60 seconds to find:

SO_RCVTIMEO is in uipc_socket.c

memcpy(, mtod(m, struct timeval *), sizeof tv);
if (!timerisvalid())
return (EINVAL);
nsecs = TIMEVAL_TO_NSEC();
if (nsecs == UINT64_MAX)
return (EDOM);

The timeout is handled as nseconds.  Here is the diff which changes it.

revision 1.239
date: 2020/01/15 13:17:35;  author: mpi;  state: Exp;  lines: +30 -14;  
commitid: rd4e6hacw84gya1H;
Keep socket timeout intervals in nsecs and use them with tsleep_nsec(9).

Introduce and use TIMEVAL_TO_NSEC() to convert SO_RCVTIMEO/SO_SNDTIMEO
specified values into nanoseconds.  As a side effect it is now possible
to specify a timeout larger that (USHRT_MAX / 100) seconds.

To keep code simple `so_linger' now represents a number of seconds with
0 meaning no timeout or 'infinity'.

Yes, the 0 -> INFSLP API change makes conversions complicated as many
timeout holders are still memset()'d.

Inputs from cheloha@ and bluhm@, ok bluhm@


--
Martin I think that change is wrong.  The precision increase loses far
too much range, and this should be converted back to a lower-resolution
value.  The tradeoff is wrong, The range should remain HUGE.  The range
is far more important than the precision.

I also think the addition of an EDOM errno here is unreasonable. 

 33 EDOM Numerical argument out of domain. A numerical input argument was
 outside the defined domain of the mathematical function.

This is the only time this errno is returned from the kernel, and I really
dislike it.


Matthias  wrote:

> Hi,
> 
> I've noticed some weird behavior of the setsockopt(2) system call.
> 
> Given the following little test program ...
> 
> 
> 
> 
> #include 
> #include 
> 
> #include 
> 
> int
> main(int argc, char *argv[])
> {
> int  fd[2];
> struct timeval   t = { .tv_sec = 650, .tv_usec = 0 };
> 
> if (socketpair(AF_UNIX, SOCK_STREAM, PF_UNSPEC, fd) == -1)
> err(1, "socketpair");
> 
> while (1) {
> if (setsockopt(fd[0], SOL_SOCKET, SO_RCVTIMEO, ,
> sizeof(t)) == -1)
> err(1, "setsockopt");
> 
> printf("%llu: OK.\n", t.tv_sec++);
> }
> 
> return (0);
> }
> 
> 
> 
> ... this is the output:
> 
> # ./test
> 650: OK.
> 651: OK.
> 652: OK.
> 653: OK.
> 654: OK.
> 655: OK.
> test: setsockopt: Numerical argument out of domain
> #
> 
> Does anybody know why tv_sec=656 an illegal value for SO_RCVTIMEO while
> 655 still appears to be alright? I was expecting this to happen for much
> larger tv_sec values, something like ULLONG_MAX / 10ULL.
> 
> I was using an amd64 machine running 6.6-stable to compile and run the
> test code.
> 
> Any help is being appreciated.
> 
> Matthias
> 
> 



setsockopt(2): weird behavior

2020-05-17 Thread Matthias

Hi,

I've noticed some weird behavior of the setsockopt(2) system call.

Given the following little test program ...




#include 
#include 

#include 

int
main(int argc, char *argv[])
{
int  fd[2];
struct timeval   t = { .tv_sec = 650, .tv_usec = 0 };

if (socketpair(AF_UNIX, SOCK_STREAM, PF_UNSPEC, fd) == -1)
err(1, "socketpair");

while (1) {
if (setsockopt(fd[0], SOL_SOCKET, SO_RCVTIMEO, ,
sizeof(t)) == -1)
err(1, "setsockopt");

printf("%llu: OK.\n", t.tv_sec++);
}

return (0);
}



... this is the output:

# ./test
650: OK.
651: OK.
652: OK.
653: OK.
654: OK.
655: OK.
test: setsockopt: Numerical argument out of domain
#

Does anybody know why tv_sec=656 an illegal value for SO_RCVTIMEO while
655 still appears to be alright? I was expecting this to happen for much
larger tv_sec values, something like ULLONG_MAX / 10ULL.

I was using an amd64 machine running 6.6-stable to compile and run the
test code.

Any help is being appreciated.

Matthias




Re: BIOS/MBR vs UEFI/GPT install

2020-05-17 Thread Andinus

Mihai Popescu @ 2020-05-16 20:24 IST:

> I tried UEFI/GPT but things went wrong and I was not able to boot OpenBSD's
> kernel after install.

Check if you are actually booting into UEFI mode, both during & after
installation.

> Is there any penalty using BIOS/MBR versus UEFI/GPT?
> Are there any extra steps to be taken if one uses UEFI/GPT other than dd
> minirootXX.iso to an USB disk?

Maybe try formatting the installation drive during installation.


signature.asc
Description: PGP signature


RT_TABLEID_MAX behavior changed?

2020-05-17 Thread Bars Bars
Hey, guys.

I always used the rt_tableid_max expanded to 16 bit range in past releases
5.x and after rebuilding the kernel it worked immediately.
But now I installed 6.6 on the new system, and after changing
rt_tableid_max (and new rt_tableid_mask and bits values too), my whole
userland throw an rtable / rdomain too large error.
Is there behaviour change?
The only thing changed (as i know) it is news net/trable.c struct to map
loopback to domain, where there is only 8 unused bits to which i can expand
tableid value.