sha256 of the install67.img is missing in the snapshot
The sha256 checksum data of the install67.img file is missing in the snapshot.
Re: sha256 of the install67.img is missing in the snapshot
Andre S wrote: > The sha256 checksum data of the install67.img file is missing in the > snapshot. Fixed.
Re: Why isn't src included with OpenBSD? (documentation)
On Mon, 18 May 2020 at 18:07, Andras Farkas wrote: > > Not sure whether to post this on misc@ or tech@, so trying misc@ first: > > Why isn't src included on OpenBSD, perhaps as an install fileset? > Lots of documentation is unavailable outside of the /usr/src tree. > > For example, today I had a server mishap which had me using fsck_ffs > after. I needed to figure out what > PARTIALLY TRUNCATED INODE I= > meant. > I saw in fsck_ffs.8 > https://man.openbsd.org/fsck_ffs.8 > that the answers could be found in > Fsck_ffs - The UNIX File System Check Program > This is perfectly fine. Not every piece of information belongs in a > man page. Man pages are the right format for some sorts of info, and > absolutely the wrong format for some other sorts. > BUT: I looked and couldn't find it, and ended up using > https://docs.freebsd.org/44doc/smm/03.fsck/paper.pdf > which is where I found my answer. > Only after I already solved the problem did I find that the mentioned > file exists here: > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/fsck_ffs/SMM.doc/ > This is a situation I occasionally run into, where useful > documentation isn't included with OpenBSD, nor is available on > OpenBSD's website (FAQ, etc). It's occasional, but it's frustrating > every time. > > Not only are the USD, PSD, and SMM missing, but other bits of info > often are, too. For example, I first learnt vi a few years ago, back > when I was first learning Unix, with these files: > https://cvsweb.openbsd.org/src/usr.bin/vi/docs/tutorial/ > Without them, or if I didn't find them, I'd have had a much more > difficult time learning vi. > > People too young to have grown up with Unix need this sort of > documentation. We can't live on man pages alone. > I believe you are referring to the historic 4.4 BSD lite documents. These are interesting for their historical value, and in some cases (for example vi and the lpd tutorials) are somewhat still relevant. Some of these documents have a proprietary licence attached to it and I believe it's due to the 1994 AT settlement. There are third party collections (like this: https://github.com/sergev/4.4BSD-Lite2) but I'm not sure if one could import them all in the source tree or in the ports tree without violating some copyright here and there. -- Ottavio Caruso
Re: lost pf state - disappeared before expiration?
On 5/17/2020 8:40 PM, Strahil Nikolov wrote: > What is your conf having as a timeout ? Both of the rules explicitly override the default timeout with a six minute rule level timeout: 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) Which is being successfully applied, as shown by the states, which start out with a six minute expiration: all udp 198.148.6.55:9430 <- 10.128.110.73:9430 MULTIPLE:MULTIPLE age 00:00:02, expires in 00:06:00, 24:23 pkts, 12163:13840 bytes, rule 63 all udp 96.251.22.157:55205 (10.128.110.73:9430) -> 198.148.6.55:9430 MULTIPLE:MULTIPLE age 00:00:02, expires in 00:06:00, 24:23 pkts, 12163:13840 bytes, rule 48, source-track However, once a minute has passed, and the expiration shows five minutes left: 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 Both of the rules simply disappear. Interestingly, I believe the default multiple:multiple timeout is one minute. Which makes me wonder if for some reason the default timeout is being applied to these rules which have an explicit longer timeout? That seems buggy, unless there is something wrong with my configuration. Even so, for a state that says it has five minutes left to go away doesn't seem right. Thanks for the input…
dmesg spam bsd: cannot forward from 2601:283... to fe80:8... nxt 58 received on inteface 8
I've tracked this down to a misbehaving Chrome OS device. Since I cannot fix the issue with the device itself (already on the latest version), what's the best way to keep this seemingly broken device from spamming dmesg and related on my IPv6/v4 router? Thank you!
Re: Why isn't src included with OpenBSD? (documentation)
On Monday, May 18, 2020, Frank Beuth wrote: > On Mon, May 18, 2020 at 11:10:59AM -0600, Theo de Raadt wrote: > >> People too young to have grown up with Unix need this sort of >>> documentation. We can't live on man pages alone. >>> >> >> YES WE CAN. >> > > Proposed release poster design: > > Puffy with puffed out cheeks & paper sticking out of his mouth. > > Headline: "Man pages are all you need to live!" > > Alternate headlines: > "We *can* live on man pages alone!" > "Man pages: a complete breakfast!" > "Man pages: they're delicious and nutritious!" The man pages are excellent! Even a total noob like me found them well written with plenty of examples. There is also the mailing lists and you know, $SEARCHENGINE of your choice.
Re: Why isn't src included with OpenBSD? (documentation)
On Mon, May 18, 2020 at 11:10:59AM -0600, Theo de Raadt wrote: People too young to have grown up with Unix need this sort of documentation. We can't live on man pages alone. YES WE CAN. Proposed release poster design: Puffy with puffed out cheeks & paper sticking out of his mouth. Headline: "Man pages are all you need to live!" Alternate headlines: "We *can* live on man pages alone!" "Man pages: a complete breakfast!" "Man pages: they're delicious and nutritious!"
Re: Why isn't src included with OpenBSD? (documentation)
On Mon, May 18, 2020 at 01:07:36PM -0400, Andras Farkas wrote: > I saw in fsck_ffs.8 > https://man.openbsd.org/fsck_ffs.8 > that the answers could be found in > Fsck_ffs - The UNIX File System Check Program > This is perfectly fine. Not every piece of information belongs in a > man page. Man pages are the right format for some sorts of info, and > absolutely the wrong format for some other sorts. > BUT: I looked and couldn't find it, and ended up using > https://docs.freebsd.org/44doc/smm/03.fsck/paper.pdf > which is where I found my answer. > Only after I already solved the problem did I find that the mentioned > file exists here: > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/fsck_ffs/SMM.doc/ Most of these files haven't been updated in ages. The few remaining in the source tree are there as reference for people when writing documentation and updating the source. Each time we see them, we cringe, and keep tidying the source code and the man page. Speaking for personal experience working on make. If you really want the source code for documentation purposes, what prevents you from getting it off cvs or a github mirror ? Seriously, *none* of those files are necessary *for beginners*. Once you reach the stage where you might benefit from them (say, because you actually want to become a developer, and could learn from worse sources), you should be able to figure out how to get them. Having an extra set here means... more options... more code that can go wrong, and thus a SLOWER turn-around for snapshots, which is definitely a bad thing.
Re: Why isn't src included with OpenBSD? (documentation)
Hi Andras, Andras Farkas wrote on Mon, May 18, 2020 at 01:07:36PM -0400: > Lots of documentation is unavailable outside of the /usr/src tree. It isn't "lots", it's only a tiny number of documents. > that the answers could be found in > Fsck_ffs - The UNIX File System Check Program > This is perfectly fine. Not really. If it's reference documentation, it would be better to have it in the manual page. Of course, in some cases, whether some piece of information should be part of the reference documentation or whether it is theoretical background that would exceed the scope of documentation and be more adequately explained in a research paper may be a matter of debate. Explaining the meaning of messages that are displayed to the user is, IMHO, usually in scope for documentation, unless the meaning of these messages is totally obvious in the first place. > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/fsck_ffs/SMM.doc/ The ancient non-manual-page roff(7) documents were sacrificed a decade ago because: (1) We want the base system self-contained, and keeping groff - which is piece of GNU "C with classes" software - in base just to format a handful of historical documents felt excessive. Similarly, writing an -ms input mode for mandoc - which would cause a few weeks of work, and add probably a few thousand lines of code to the tree - also felt excessive for such a small set of documents: nobody has been writing new documentation in -ms or -me or even -mm for decades. [kettenis@ did say that he'd appreciate a BSD-licensed roff in base, but that would cause even more work, so nobody tackled that, either. The licensing of the main modern roff implementations (and even those unmaintained historical ones that i'm aware of) is non-free: groff is GPL (viral), Heirloom and Solaris 10 troff are both CDDL (viral), Plan9 is Lucent Public License (polluted by verbiage about patents and explicitly asserting U.S. law), DWB is Eclipse Public License (viral).] (2) While no one denies that some parts of these ancient documents can occasionally still be useful, many parts are probably outdated since they haven't been maintained for deacdes. No one volunteered so far to check their content and properly add those parts that still apply to the respective manual pages. (3) Since they are unmaintained anyway, pointing to old copies on the web is not that much worse than having them installed, in this special case. Of course, having the content installed would be even better, but it's not trivial to achieve. > This is a situation I occasionally run into, where useful > documentation isn't included with OpenBSD, nor is available on > OpenBSD's website (FAQ, etc). It's occasional, but it's frustrating > every time. > > Not only are the USD, PSD, and SMM missing, but other bits of info > often are, too. In such cases, as an immediate measure to improve the situation, please submit a patch to the SEE ALSO section of the respective manual page. I'd consider it a documnetation bug if a useful supplemental document exists, no matter whether in the tree or elsewehere, but isn't mentioned. > For example, I first learnt vi a few years ago, back > when I was first learning Unix, with these files: > https://cvsweb.openbsd.org/src/usr.bin/vi/docs/tutorial/ Hum, looks like a reference to those files is indeed missing from the manual page. Also, i don't see what would be wrong with installing them to /usr/share/doc/vi/tutorial/ Yes, the tutorial is painfully slow and extremely wordy, and some parts are hilariously antiquated, like this: "Learning a new computer system implies learning a new text editor." That wasn't even accurate at the time it was presumably written, probably around 4.4BSD (i.e. almost 30 years ago). It may have been more or less true 40 years ago, though. Can somebody work through the tutorial and confirm that everything still works as described with our -current vi(1)? It is too wordy for my personal taste, so i would hate having to read it all. Yours, Ingo
ULTRASPARC vs ARMv7 (Sun Netra T1 vs Orange PI ONE) from ONLY a security point of view
Dear Riccardo, >MIPS is in a little better shape, but there too you need to resort to Little >Endian if you want something cheap as ARM. Are all: https://www.openbsd.org/octeon.html little endian? According to: https://www.debian.org/releases/stretch/ppc64el/ch02s01.html.en 32bit MIPS (big-endian) mips MIPS Malta 4kc-malta Cavium Octeon octeon Not sure if OpenBSD supports anything like it? What do you think about hardware security level of Octeon based routers? Is there any difference between the oldest obsolete ER3 Light and newer models? MIPS is mentioned as a very resistant to SPECTRE issues, the manufacturer lists even only a couple of affected CPUs: https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/ But what about SoC models? Discussion at: https://community.ui.com/questions/Meltdown-and-Spectre-Exploits/a9caa545-96f3-404b-aff8-2cdc8836bfd0 concludes there are no SPECTRE issues with their router devices?
ULTRASPARC vs ARMv7 (Sun Netra T1 vs Orange PI ONE) from ONLY a security point of view
>MIPS is in a little better shape, but there too you need to resort to Little >Endian if you want something cheap as ARM. Dear Riccardo, Are all: https://www.openbsd.org/octeon.html little endian? According to: https://www.debian.org/releases/stretch/ppc64el/ch02s01.html.en 32bit MIPS (big-endian) mips MIPS Malta 4kc-malta Cavium Octeon octeon Not sure if OpenBSD supports anything like it? What do you think about hardware security level of Octeon based routers? Is there any difference between the oldest obsolete ER3 Light and newer models? MIPS is mentioned as a very resistant to SPECTRE issues, the manufacturer lists even only a couple of affected CPUs: https://www.mips.com/blog/mips-response-on-speculative-execution-and-side-channel-vulnerabilities/ But what about SoC models? Discussion at: https://community.ui.com/questions/Meltdown-and-Spectre-Exploits/a9caa545-96f3-404b-aff8-2cdc8836bfd0 concludes there are no SPECTRE issues with their router devices?
Re: Why isn't src included with OpenBSD? (documentation)
Andras Farkas wrote: > Not sure whether to post this on misc@ or tech@, so trying misc@ first: > > Why isn't src included on OpenBSD, perhaps as an install fileset? Because then we'd need to adjust the disk-layout expectations on every architecture, and consider and match a variety of build patterns. We do not want to do that. > Lots of documentation is unavailable outside of the /usr/src tree. Lots of documentation isn't in your brain at birth either, and you learn where to find it. > People too young to have grown up with Unix need this sort of > documentation. We can't live on man pages alone. YES WE CAN.
Why isn't src included with OpenBSD? (documentation)
Not sure whether to post this on misc@ or tech@, so trying misc@ first: Why isn't src included on OpenBSD, perhaps as an install fileset? Lots of documentation is unavailable outside of the /usr/src tree. For example, today I had a server mishap which had me using fsck_ffs after. I needed to figure out what PARTIALLY TRUNCATED INODE I= meant. I saw in fsck_ffs.8 https://man.openbsd.org/fsck_ffs.8 that the answers could be found in Fsck_ffs - The UNIX File System Check Program This is perfectly fine. Not every piece of information belongs in a man page. Man pages are the right format for some sorts of info, and absolutely the wrong format for some other sorts. BUT: I looked and couldn't find it, and ended up using https://docs.freebsd.org/44doc/smm/03.fsck/paper.pdf which is where I found my answer. Only after I already solved the problem did I find that the mentioned file exists here: https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sbin/fsck_ffs/SMM.doc/ This is a situation I occasionally run into, where useful documentation isn't included with OpenBSD, nor is available on OpenBSD's website (FAQ, etc). It's occasional, but it's frustrating every time. Not only are the USD, PSD, and SMM missing, but other bits of info often are, too. For example, I first learnt vi a few years ago, back when I was first learning Unix, with these files: https://cvsweb.openbsd.org/src/usr.bin/vi/docs/tutorial/ Without them, or if I didn't find them, I'd have had a much more difficult time learning vi. People too young to have grown up with Unix need this sort of documentation. We can't live on man pages alone.
segmentation fault when useing libmongoc call to strlen
Hi, Really often application core dumped, when sending mongodb query with some mongoc driver writing function like insert or update, or even when iterating cursor returned frome the mongoc driver. Moreover, it may complete with no issues with the absolutely identical queries. Following the gdb trace (may be question is not so correct, but) is it possible to identify which side the issue on systems or driver? It seems that the issue somewhere between mongoc makes strlen call. Sorry, if i missed something. gdb trace here #0 strlen () at /usr/src/lib/libc/arch/amd64/string/strlen.S:125 #1 0x01ccf0f4db22 in _mongoc_handshake_build_doc_with_application () from /usr/local/lib/libmongoc-1.0.so.0.0 #2 0x01ccf0f816d1 in _build_ismaster_with_handshake () from /usr/local/lib/libmongoc-1.0.so.0.0 #3 0x01ccf0f815af in _mongoc_topology_scanner_get_ismaster () from /usr/local/lib/libmongoc-1.0.so.0.0 #4 0x01ccf0f82c08 in _begin_ismaster_cmd () from /usr/local/lib/libmongoc-1.0.so.0.0 #5 0x01ccf0f82a7d in mongoc_topology_scanner_node_setup_tcp () from /usr/local/lib/libmongoc-1.0.so.0.0 #6 0x01ccf0f82203 in mongoc_topology_scanner_node_setup () from /usr/local/lib/libmongoc-1.0.so.0.0 #7 0x01ccf0f8336b in mongoc_topology_scanner_start () from /usr/local/lib/libmongoc-1.0.so.0.0 #8 0x01ccf0f7b2dc in mongoc_topology_scan_once () from /usr/local/lib/libmongoc-1.0.so.0.0 #9 0x01ccf0f7b244 in _mongoc_topology_do_blocking_scan () from /usr/local/lib/libmongoc-1.0.so.0.0 #10 0x01ccf0f7b88c in mongoc_topology_select_server_id () from /usr/local/lib/libmongoc-1.0.so.0.0 #11 0x01ccf0f290c0 in _mongoc_cluster_select_server_id () from /usr/local/lib/libmongoc-1.0.so.0.0 #12 0x01ccf0f24f14 in _mongoc_cluster_stream_for_optype () from /usr/local/lib/libmongoc-1.0.so.0.0 #13 0x01ccf0f25029 in mongoc_cluster_stream_for_writes () from /usr/local/lib/libmongoc-1.0.so.0.0 #14 0x01ccf0f2e2ad in _mongoc_collection_write_command_execute () from /usr/local/lib/libmongoc-1.0.so.0.0 #15 0x01ccf0f30785 in mongoc_collection_remove () from /usr/local/lib/libmongoc-1.0.so.0.0 different mongoc latest versions tried # mongod --version db version v3.2.22 git version: 105acca0d443f9a47c1a5bd608fd7133840a58dd OpenSSL version: LibreSSL 3.0.2 allocator: system modules: none build environment: distarch: x86_64 target_arch: x86_64 # gcc -v Reading specs from /usr/lib/gcc-lib/amd64-unknown-openbsd6.6/4.2.1/specs Target: amd64-unknown-openbsd6.6 Configured with: OpenBSD/amd64 system compiler Thread model: posix gcc version 4.2.1 20070719 # uname -a OpenBSD m10-csvpn.rt.ru 6.6 GENERIC.MP#3 amd64
[www] wrong release date of rpki-client 6.6p2
Hey, there is a typo on /cvs/www/rpki-client/portable.html Cheers, Alex Index: portable.html === RCS file: /cvs/www/rpki-client/portable.html,v retrieving revision 1.8 diff -u -p -r1.8 portable.html --- portable.html 21 Apr 2020 01:55:36 - 1.8 +++ portable.html 18 May 2020 12:54:53 - @@ -18,7 +18,7 @@ Portable Release -rpki-client 6.6p2 portable: released April 19, 2019 +rpki-client 6.6p2 portable: released April 19, 2020 The portable version of rpki-client adds support for other Unix flavors by adding
Re: ULTRASPARC vs ARMv7 (Sun Netra T1 vs Orange PI ONE) from ONLY a security point of view
Hi, Глеб Рахмановский wrote: > > Dear Gurus, > Please let me know, are there any advantages of UltraSparc IIe over Cortex A7 > AllWinner H3 for a secure communication host ignoring a factor of power > efficiency, size and loud noise? > IMHO the only feature OpenBSD can benefit from UltraSparc is StackGhost ? > The comparison is a little far fetched. I prefer the Big-Endian CPU of SPARC where sometimes just a 1-byte off in a string or a badly aligned or initialized struct segfaults your program: hapy debugging. Do that on ARM. Also, you can fully load your Netra T1, yet connect via ssh, do some work and just notice it is slower. Do the same on your PI or similar or even (compared to the higher CPU performance) on laptop it cringes. What would be lovable would be a cheap, modern, multi-core SPARC. You could do that, but commercially nobody does it because it is a complex architecture. But there is the LEON, modern 32bit CPU for Aerospace and Russia also has several iterations of the SPARC, dating back to the Elbrus. Of course, for us "mortals" not available and not as cheap as an ARM. MIPS is in a little better shape, but there too you need to resort to Little Endian if you want something cheap as ARM. Sad, but true... right now you have an ARM/i386/amd64 monoculture, but it reflects in the cheap prices of the CPUs. Riccardo
Re: RT_TABLEID_MAX behavior changed?
To be more convinient, when i said about that its limit became shorter its
relevant to sys/net/rtable.c struct dommp.
struct dommp {
unsigned int limit;
/*
* Array to get the routing domain and loopback interface related to
* a routing table. Format:
*
* 8 unused bits | 16 bits for loopback index | 8 bits for rdomain
*/
unsigned int *value;
};
In past the maxumum value was limited to u_int16_t in some deep places,
but nowadays there is only 8 bits allocated to it based on the struct + 8
unused bits which i hop i can safely add to allocation.
I worried these unused bits are not guaranteed to users, so actually the
limit is 8 bits instead of 16 in earlier releases.
пн, 18 мая 2020 г. в 11:51, Bars Bars :
> Hi, Claudio
>
> I mean these in sys/socket.h
> /*
> * Maximum number of alternate routing tables
> */
> #define RT_TABLEID_MAX 8000
> #define RT_TABLEID_BITS 16
> #define RT_TABLEID_MASK 0x
>
>
> пн, 18 мая 2020 г. в 10:18, Claudio Jeker :
>
>> On Sun, May 17, 2020 at 10:16:28PM +0300, Bars Bars wrote:
>> > 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.
>>
>> Sorry your mail is incredibly inprecise and unclear. There is no
>> rt_tableid_max in OpenBSD at least not in my tree (grep -r rt_tableid_max
>> returned nothing). So I have no idea what you are talking about and am
>> therefor not able to give you a better answer.
>>
>> > вс, 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.
>> > >
>> > >
>>
>> --
>> :wq Claudio
>>
>
Re: RT_TABLEID_MAX behavior changed?
Hi, Claudio I mean these in sys/socket.h /* * Maximum number of alternate routing tables */ #define RT_TABLEID_MAX 8000 #define RT_TABLEID_BITS 16 #define RT_TABLEID_MASK 0x пн, 18 мая 2020 г. в 10:18, Claudio Jeker : > On Sun, May 17, 2020 at 10:16:28PM +0300, Bars Bars wrote: > > 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. > > Sorry your mail is incredibly inprecise and unclear. There is no > rt_tableid_max in OpenBSD at least not in my tree (grep -r rt_tableid_max > returned nothing). So I have no idea what you are talking about and am > therefor not able to give you a better answer. > > > вс, 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. > > > > > > > > -- > :wq Claudio >
Re: lost pf state - disappeared before expiration?
On May 18, 2020 1:58:49 AM GMT+03:00, "Paul B. Henson" wrote:
>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...
Short googling shows me:
In the case of protocols without "start" and "end" packets, PF simply keeps
track of how long it has been since a matching packet has gone through. If the
timeout is reached, the state is cleared. The timeout values can be set in the
options section of the pf.conf file.
What is your conf having as a timeout ?
Best Regards,
Strahil Nikolov
Re: RT_TABLEID_MAX behavior changed?
On Sun, May 17, 2020 at 10:16:28PM +0300, Bars Bars wrote: > 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. Sorry your mail is incredibly inprecise and unclear. There is no rt_tableid_max in OpenBSD at least not in my tree (grep -r rt_tableid_max returned nothing). So I have no idea what you are talking about and am therefor not able to give you a better answer. > вс, 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. > > > > -- :wq Claudio
