lost pf state - disappeared before expiration?
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
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?
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
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
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
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
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
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?
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.