00:43:37 i kind of wish fbsd installed wayland/kde(plasma) 00:49:03 Macer: even if we shipped a desktop in base somehow, you'd still have issues with e.g. your web browser randomly vanishing from packages 00:49:48 i think this happens fairly often with the various Chromium rebuilds 01:18:48 vanishing? 01:21:42 i installed wayland no problem 02:08:37 good day #freebsd 02:09:01 is 14.4-RELEASE coming out tomorrow? 02:10:35 zerotime: the release is tagged, the build has started and it should be pushed to mirrors today (March 6th) but the release notes aren't finalised and it won't be officially released until the 10th, assuming no issues are found 02:12:23 thanks ivy - I really appreciate all the work that goes into the release cycle 02:12:34 hope all goes well 02:12:42 !inspire 02:12:43 Inspiration exists, but it has to find you working. -Pablo Picasso [https://zenquotes.io/] 03:46:48 how do you get the fn brightness keys on a dell laptop to work 03:48:11 also when is kde going to be put back in the pkg repository 04:25:38 .14 05:22:48 bz: What FreeBSD version are you running? 05:23:41 bz: you can probably check in with jhale and arrowd about the status of KDE Plasma they are the main to folks that test builds and push them up to the official boxes 05:23:53 They hang out in #FreeBSD-Desktop 05:34:57 Macer: you around ? 06:54:59 bz: probably some dependency failed to build, it wasn't manually removed by someone, it will be back when all dependencies build successfully again 07:04:03 seems like a dependency that failed to build is qt6-webengine https://portsfallout.com/fallout?port=www%2Fqt6-webengine%24 07:19:11 Can anyone explain to me what all of these download options actually are? 07:19:12 https://download.freebsd.org/releases/amd64/amd64/ISO-IMAGES/15.0/ 07:27:19 GoSox: see here: https://www.freebsd.org/releases/15.0R/announce/ 07:27:33 (Under “Availability”.) 09:58:49 so i’m trying to block all malformed packets with pf firewall. I keep finding examples but it doesn’t really explain in enough detail what its doing. Anyone know anything on this topic? 10:00:30 <[tj]> some reflection on how software would implement this might help you understand the difficultly of the task 10:01:21 well, ok i don’t mean “all malformed packets” i guess, what i mean is packets with bad flags set, that cannot be valid packets 10:03:41 <[tj]> it is opposed to performance in a network forwarding device, as far as I know if pf looks at a packet and fields are invalid then it won't forward them 10:03:45 <[tj]> but it doesn't want to look at packets 10:09:10 i don’t *think* thats true, but i guess I don’t know and i also don’t know how to determine if it is or not 10:09:23 this sounds like a job for.... 10:09:25 another day 10:10:04 <[tj]> I'd love to know why you think that 10:10:23 <[tj]> like it depends, pf can do tcp segment normalisation, but you don't really want your firewall doing such things 10:10:36 posts i’ve read suggest that if you want to block packets with bad flags set, you have to explicitely do that 10:10:47 <[tj]> oh sure, which flags? 10:11:01 all combinations of flags that are bad/invalid 10:11:06 <[tj]> but just a general "avoid anything bad" isn't really possible 10:12:39 ok forget ‘bad’ and just go with ‘invalid’ 10:30:25 hmm the manpage on openbsd says that using `scrub` will junk all of the invalid flagged packets. But I didn’t read that on any other pf docs i could find 10:30:51 this server has more CPU than anything else so no harm in trying I guess 10:56:56 Hurray, the desing defect I discussed here one-and-a-half years ago is finally removed: . 13:27:51 GoSox: I have problems to understand your question, but, uhm, .iso is the normal ISO9660 file you could write to a CD, or to something that can bootload them (like Ventoy). .iso.xz is the xz compressed version of that file. .img is the USB image you can write directly to a USB-stick (without the need for Ventoy or the like), and .img.xz one, well you guessed it already. 13:28:45 GoSox: mini-memstick is like memstick but without the sets (iirc), so you need to connect to the internet to download these from there during installation, which is almost never an issue. 13:30:06 GoSox: I don't know if that answered your initial question about those images, but hey, trying to help. 13:36:29 does freebsd make not run a shell? 13:36:31 GoSox: are you talking about TCP flags? my understanding was that pf will only accept flags which are valid for the current connection state... is that wrong? 13:37:14 "false; echo hi" in freebsd make doesn't print the hi 13:37:35 in gnu make it does 13:41:46 makr: paragraph 'Makefile Execution' in https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html 13:42:03 "... if errors are not being ignored then the shell -e option shall also be in effect" 13:44:20 gbon121: hmm this is strange 13:44:24 so gnu is non-compliant? 13:45:48 okay if I set the POSIX: target it behaves the same...interesting 13:46:18 it does seem that FreeBSD doesn't bother with a shell in some cases. eg. `set -o` doesn't work 13:46:29 make: exec(set): No such file or directory 13:47:01 armin@bsd:~ false; echo hi 13:47:01 hi 13:47:01 armin@bsd:~ uname -a 13:47:01 FreeBSD bsd.pm 15.0-RELEASE-p4 FreeBSD 15.0-RELEASE-p4 GENERIC amd64 13:47:02 armin@bsd:~ 13:47:17 the effect must be the same as /bin/sh -e -c 'false; echo hi' 14:00:03 well you specified -e 14:09:18 makr: exec(set): No such file... because according to the standard, the implementation is free to use execve() directly, and apparently freebsd's make execs simple commands directly but delegates complex ones (perhap those with a semicolon?) to /bin/sh 14:10:07 if you place the command "set -o; set -x", it works as expected 14:12:13 TIL 14:12:58 the RATIONALE section seems to mention this 14:13:42 i guess I should also use the POSIX: target more to get some consistency 14:18:48 there is also the -B option which affects shell behaviour, but i don't think that has any impact on this specifically 14:28:32 makr: also note that each *line* of a target will be executed in its own shell, so just set by itself is useless 14:31:56 ant-x: huh. I’d been using “shutdown” for years, but recently saw “reboot” in some online doc and thought “huh, i guess i should be using that” and switched. 🤣 14:32:15 Thanks for getting that change to happen! 14:34:52 anth, np (the problem is np-complete :-) 15:06:50 Yay, internet is back! 15:14:24 nimaje: i was actually trying to run `set -o` to see if errexit was set somehow, then gbon121 helpfully pointed out to the POSIX page 15:15:10 nice to see reboot now working as one might think...just after i got used to `shutdown -r now` :D 15:19:09 unfortunately this breaks the historical behaviour of nearly all Unix systems going back 50 years... but we already had inconsistent behaviour with poweroff(8) there so i can see the argument for making all those tools work the same 16:02:57 SponiX: ? 20:17:47 I'm getting DDoS'd again, starting almost exactly at noon, port 43 again like last time. I just blocked all 443 for now. No apparent source, seems to be a botnet. Anyone else? 20:18:04 er port 443 - SYN flood 20:18:12 Is it from Meta's servers, by any chance? 20:18:31 not sure - I'll analyze the IP's 20:23:50 earlier one was from AT&T in Texas. Another is from Cloudflare in San Francisco 20:24:12 so Meta might have been compromised, yeah 20:25:15 I'll have to get a list of IP addresses from wireshark to filter, but it looks like if cloud networks are behind it, blocking port 443 is smarter. for now. 20:25:50 maybe I can get ipfw to log them... 20:27:14 I've heard that Meta has been spamming AI bots around unsuspecting websites. 20:27:28 I doubt they're actually compromised. 20:30:57 I think Meta is trying to scrape the sites for data to train their AI, but of course they go about it in the worst way possible. 20:33:13 "i have received from HTTP requests from Meta, so Meta might be compromised" does not seem like a rigorous train of thought 20:34:17 like, what % of requests were from Meta? what was the incoming packet rate? did the traffic have any other characterists of a DoS? 20:34:59 also, if you actually think Meta is compromised, you should mail their abuse team with your evidence 20:35:31 heh - my wireshark filter was wrong. it stopped... 20:37:02 but yeah I was trying to verify what was happening. was going to start logginh it, but it stopped, and having a wrong filter in wireshark misdirected me 20:38:04 a week or so ago i got (for 2nd time) a similar DDoS from Brazilian IP addresses. They're still in the block list 20:38:37 anyway it just seemeed too convenient, "right at noon" like that 20:39:08 you can't usually just block a DDoS, you need to contact upstream ISPs to filter the traffic... are you sure it wasn't just a misconfiguration or some crawler gone wrong? 20:39:23 ipfw logginmg seems pretty powerful. i figured oput the syntax from the man page just fine 20:39:45 when you say DDoS and syn-flood, about how many syn per second we talk? 20:52:03 shbrngdo, It would be easier for me to say when we are NOT getting DDOS'd by bad-actor botnets. Almost never. The bad-actor botnets out there are always hammering away. Sometimes it is worse. Sometimes it is better. But they are always hammering these days. 21:01:57 con irc.tilde.chat 21:01:59 oops 23:04:21 satanist - it's wenough to make outgoing requests fail - maybe 50 to 100/sec? I did not catch the rate. I DID see it again a short time ago and wrote some scripts to use the ipfw log to generate a set of netblocks, even do whois on them. Source is from Uraguay I think - country code UY 23:05:04 isnead of running for over 24 hrs like the Brazilian ones, this runs for maybe half an hour after I block it. 23:06:18 100 syn packets per second is not a "DDoS" 23:06:43 typical DDoS nowadays is at least many Gbit/s of traffic and often measures in Tbit/s range 23:06:47 rwp - good point - it is just supicious with currebnt wvwbnts but that could be a coincidence. he latin american ISP's, though... many /24 netblocks involved 23:07:24 current events (stoopid keyboard cannor type) 23:08:21 ivy - it's enough to shut down my network, on a ATT U-Verse - 30Mbit. It quickly gets killed with hundreds of waiting requests 23:08:31 One of the problems with trying to know these rates is that up to a point we can tell by looking at web logs as each query is logged. But at some point the web server fails to serve all requests and those that fall off the queue never getting serviced timed out never get logged. But those do still impact the system. 23:09:30 yes - ipfw logs help. I logged 1000 of them within a few seconds 23:10:12 then gep through security log file for ipfw: and the rule 23:10:18 In theory the ISP will have a monitored switch logging total bandwidth. But that's usually something they can see but we can't see. So we are left guessing at the raw bandwidth totals. 23:11:17 in any ase I added about 30 new netblocks and it's quiet again. But thanks. Now I wasted a couple o' hours... 23:11:47 still nice about ipfw log. I need to investigate how to use that better 23:12:55 this sounds more like some bad implemented content scanner, you might want to check for some ratelimiting solutions 23:13:48 That sounds pretty typical to me. I am seeing it on all of the servers I admin. Just an overwhelming number of bad-actor botnets using every possible hiding technique to avoid being blocked.