nabijaczleweli

наб

@nabijaczleweli

Dazed and confused, but trying to continue 🇵🇱/🏴󠁧󠁢󠁥󠁮󠁧󠁿/🇷🇺 ⚧ they

Maintains homie/hoe stasis. Store horizontally when not in use. Contains sulfites.

log in
nabijaczleweli
@nabijaczleweli
nabijaczleweli
@nabijaczleweli
nabijaczleweli
@nabijaczleweli

ran into the same openbsd df bug as i did in august because theo apparently hates his users too much to spend 3 seconds applying a patch

even after a taste-only revision

every time i write a system-comparison test for some voreutils bit i end up actually testing openbsd because 30 years is not enough to "divide integers" or "have locales" or "have standard utmp" or fucking work at all apparently

here's the original thread, my new reply will probably appear here when i get through the greylist

see all
nabijaczleweli
@nabijaczleweli

how they get you, of course, is that this isn't quantifiable; freebsd at least has a bugzilla instance, tech@ is post-to-ignore

so yes i have more Fx bugs but im a pedant and most of those were "yeag; applied as [SHA]" or "nice POSIX reading, dipshit; fixed in [SHA]"; 0% success rate with Ox + i will send de raadt to brazil

You must log in to comment.

in reply to @nabijaczleweli's post:

in reply to @nabijaczleweli's post:

nabijaczleweli
@nabijaczleweli

startlingly low bar for a system whose stated goal is "Our efforts emphasize portability, standardization, correctness"; this reminds me, i should repost my script(1) patchset that makes it actually fit for purpose, its apparently been a full year as of yesterday

login to reply
atax1a
@atax1a

we have a hacked copy of pf_norm.c that we want to send somewhere to start discussion on, though

the reassemble tcp option does 3 things, 2 of which are okay on a modern internet, and the third thing causes problems with hosts behind load balancers that change their tcp timestamp behavior

so we have to do this kind of shit:

===================================================================
RCS file: /cvs/src/sys/net/pf_norm.c,v
retrieving revision 1.224
diff -u -p -u -r1.224 pf_norm.c
--- net/pf_norm.c	22 Aug 2022 20:35:39 -0000	1.224
+++ net/pf_norm.c	3 Jan 2023 17:28:32 -0000
@@ -1294,8 +1294,8 @@ pf_normalize_tcp_stateful(struct pf_pdes
 
 			if (got_ts) {
 				/* Huh?  Multiple timestamps!? */
-				if (pf_status.debug >= LOG_NOTICE) {
-					log(LOG_NOTICE,
+				if (pf_status.debug >= LOG_ERR) {
+					log(LOG_ERR,
 					    "pf: %s: multiple TS??", __func__);
 					pf_print_state(state);
 					addlog("\n");
@@ -1469,23 +1469,23 @@ pf_normalize_tcp_stateful(struct pf_pdes
 			 *   an old timestamp.
 			 */
 
-			DPFPRINTF(LOG_NOTICE, "Timestamp failed %c%c%c%c",
+			DPFPRINTF(LOG_ERR, "Timestamp failed %c%c%c%c",
 			    SEQ_LT(tsval, dst->scrub->pfss_tsecr) ? '0' : ' ',
 			    SEQ_GT(tsval, src->scrub->pfss_tsval +
 			    tsval_from_last) ? '1' : ' ',
 			    SEQ_GT(tsecr, dst->scrub->pfss_tsval) ? '2' : ' ',
 			    SEQ_LT(tsecr, dst->scrub->pfss_tsval0)? '3' : ' ');
-			DPFPRINTF(LOG_NOTICE, " tsval: %u  tsecr: %u  "
+			DPFPRINTF(LOG_ERR, " tsval: %u  tsecr: %u  "
 			    "+ticks: %u  idle: %llu.%06lus", tsval, tsecr,
 			    tsval_from_last, (long long)delta_ts.tv_sec,
 			    delta_ts.tv_usec);
-			DPFPRINTF(LOG_NOTICE, " src->tsval: %u  tsecr: %u",
+			DPFPRINTF(LOG_ERR, " src->tsval: %u  tsecr: %u",
 			    src->scrub->pfss_tsval, src->scrub->pfss_tsecr);
-			DPFPRINTF(LOG_NOTICE, " dst->tsval: %u  tsecr: %u  "
+			DPFPRINTF(LOG_ERR, " dst->tsval: %u  tsecr: %u  "
 			    "tsval0: %u", dst->scrub->pfss_tsval,
 			    dst->scrub->pfss_tsecr, dst->scrub->pfss_tsval0);
-			if (pf_status.debug >= LOG_NOTICE) {
-				log(LOG_NOTICE, "pf: ");
+			if (pf_status.debug >= LOG_ERR) {
+				log(LOG_ERR, "pf: ");
 				pf_print_state(state);
 				pf_print_flags(th->th_flags);
 				addlog("\n");
@@ -1531,16 +1531,14 @@ pf_normalize_tcp_stateful(struct pf_pdes
 			 * Hey!  Someone tried to sneak a packet in.  Or the
 			 * stack changed its RFC1323 behavior?!?!
 			 */
-			if (pf_status.debug >= LOG_NOTICE) {
-				log(LOG_NOTICE,
+			if (pf_status.debug >= LOG_ERR) {
+				log(LOG_ERR,
 				    "pf: did not receive expected RFC1323 "
 				    "timestamp");
 				pf_print_state(state);
 				pf_print_flags(th->th_flags);
 				addlog("\n");
 			}
-			REASON_SET(reason, PFRES_TS);
-			return (PF_DROP);
 		}
 	}
login to reply
nabijaczleweli
@nabijaczleweli

we may be observing the first patch in cohost comments. soon we may see the first patch sent upstream via the same method

i mean, im not subscribed either, you just click through/reply to a confirmation mail from the list, people usually group-reply when you tell them to ime

idk i like logically understand what the option does and how the diff changes it but i dont get why you'd care in the first place. maybe im not infosec/tcppilled enough
always a good sign when something that hinges on "current host behaviour" blames to 20 years ago and cites solaris 2 tho

login to reply
atax1a
@atax1a

really for this patch to be mature it needs to split those three reassembly features controlled by reassemble tcp out into their own options.

the reason we care is that, apparently, some load balancers will start off connections with timestamps and then pass to backends without them, or with fucky timestamps, which makes client connections stall and time out.

we want the other reassembly features, though, so we dike out this one

because we also have to rebuild our kernel to enable PPPOE_TERM_UNKNOWN_SESSIONS, and we eventually also want to patch it such that this option becomes a link-time flag on the interface instead of a compile-time flag on the entire pppoe driver. but also effort.

login to reply
nabijaczleweli
@nabijaczleweli

that was more of a royal you, because the manual is phrased as "Attacker Might" and that usually means an impossible scenario one needs to be infosec brain-poisoned to be concerned with. am I right to read that gaining/losing the parameter mid-session is legal and would Just Work, but the normaliser considers it an Attacker Might and drops the packet ⇒ clients time out?

hm, maybe my ISP is better-behaved since I've never observed this with rp-pppoe, which just tries 3 PADIs for up to 30 seconds total, and I don't see any termination code in the discovery path; maybe if you see that a lot it may make sense to pick up the connection instead of re-discovering à la rp_pppoe_sess/pppoe -e (i cant believe being the only rp-pppoe poster in 20 years is somehow relevant; a cursory glance at Ox ifconfig(8) shows that's impossible but maybe i cant read)

login to reply
atax1a
@atax1a

oh! we only see this when we're doing CARP failover — ifstated on each box takes the physical upstream interface up or down based on CARP status.

Without TERMing the unknown session, during failover, there's a 60 second lacuna where the old session is still active on the PPPoEAC and the new one won't establish. With TERMing the unknown session, the failover becomes almost completely transparent. At most a minor pause.

Truly the correct solution here would be to teach CARP how to float the PPP session ID across the link.

login to reply
Pinned Tags