i kind of wish fbsd installed wayland/kde(plasma)

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

i think this happens fairly often with the various Chromium rebuilds

vanishing?

i installed wayland no problem

good day #freebsd

is 14.4-RELEASE coming out tomorrow?

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

thanks ivy - I really appreciate all the work that goes into the release cycle

hope all goes well

!inspire

Inspiration exists, but it has to find you working. -Pablo Picasso [zenquotes.io]

how do you get the fn brightness keys on a dell laptop to work

also when is kde going to be put back in the pkg repository

.14

bz: What FreeBSD version are you running?

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

They hang out in #FreeBSD-Desktop

Macer: you around ?

bz: probably some dependency failed to build, it wasn't manually removed by someone, it will be back when all dependencies build successfully again

seems like a dependency that failed to build is qt6-webengine portsfallout.com/fallout?port=www%2Fqt6-webengine%24

Can anyone explain to me what all of these download options actually are?

GoSox: see here: freebsd.org/releases/15.0R/announce

(Under “Availability”.)

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?

some reflection on how software would implement this might help you understand the difficultly of the task

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

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

but it doesn't want to look at packets

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

this sounds like a job for....

another day

I'd love to know why you think that

like it depends, pf can do tcp segment normalisation, but you don't really want your firewall doing such things

posts i’ve read suggest that if you want to block packets with bad flags set, you have to explicitely do that

oh sure, which flags?

all combinations of flags that are bad/invalid

but just a general "avoid anything bad" isn't really possible

ok forget ‘bad’ and just go with ‘invalid’

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

this server has more CPU than anything else so no harm in trying I guess

Hurray, the desing defect I discussed here one-and-a-half years ago is finally removed: <bugs.freebsd.org/bugzilla/show_bug.cgi?id=280941> .

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.

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.

GoSox: I don't know if that answered your initial question about those images, but hey, trying to help.

does freebsd make not run a shell?

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?

"false; echo hi" in freebsd make doesn't print the hi

in gnu make it does

makr: paragraph 'Makefile Execution' in pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html

"... if errors are not being ignored then the shell -e option shall also be in effect"

gbon121: hmm this is strange

so gnu is non-compliant?

okay if I set the POSIX: target it behaves the same...interesting

it does seem that FreeBSD doesn't bother with a shell in some cases. eg. `set -o` doesn't work

make: exec(set): No such file or directory

armin@bsd:~ false; echo hi

hi

armin@bsd:~ uname -a

FreeBSD bsd.pm 15.0-RELEASE-p4 FreeBSD 15.0-RELEASE-p4 GENERIC amd64

armin@bsd:~

the effect must be the same as /bin/sh -e -c 'false; echo hi'

well you specified -e

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

if you place the command "set -o; set -x", it works as expected

TIL

the RATIONALE section seems to mention this

i guess I should also use the POSIX: target more to get some consistency

there is also the -B option which affects shell behaviour, but i don't think that has any impact on this specifically

makr: also note that each *line* of a target will be executed in its own shell, so just set by itself is useless

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. 🤣

Thanks for getting that change to happen!

anth, np (the problem is np-complete :-)

Yay, internet is back!

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

nice to see reboot now working as one might think...just after i got used to `shutdown -r now` :D

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

SponiX: ?

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?

er port 443 - SYN flood

Is it from Meta's servers, by any chance?

not sure - I'll analyze the IP's

earlier one was from AT&T in Texas. Another is from Cloudflare in San Francisco

so Meta might have been compromised, yeah

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.

maybe I can get ipfw to log them...

I've heard that Meta has been spamming AI bots around unsuspecting websites.

I doubt they're actually compromised.

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.

"i have received from HTTP requests from Meta, so Meta might be compromised" does not seem like a rigorous train of thought

like, what % of requests were from Meta? what was the incoming packet rate? did the traffic have any other characterists of a DoS?

also, if you actually think Meta is compromised, you should mail their abuse team with your evidence

heh - my wireshark filter was wrong. it stopped...

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

a week or so ago i got (for 2nd time) a similar DDoS from Brazilian IP addresses. They're still in the block list

anyway it just seemeed too convenient, "right at noon" like that

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?

ipfw logginmg seems pretty powerful. i figured oput the syntax from the man page just fine

when you say DDoS and syn-flood, about how many syn per second we talk?

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.

con irc.tilde.chat

oops

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

isnead of running for over 24 hrs like the Brazilian ones, this runs for maybe half an hour after I block it.

100 syn packets per second is not a "DDoS"

typical DDoS nowadays is at least many Gbit/s of traffic and often measures in Tbit/s range

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

current events (stoopid keyboard cannor type)

ivy - it's enough to shut down my network, on a ATT U-Verse - 30Mbit. It quickly gets killed with hundreds of waiting requests

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.

yes - ipfw logs help. I logged 1000 of them within a few seconds

then gep through security log file for ipfw: and the rule

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.

in any ase I added about 30 new netblocks and it's quiet again. But thanks. Now I wasted a couple o' hours...

still nice about ipfw log. I need to investigate how to use that better

this sounds more like some bad implemented content scanner, you might want to check for some ratelimiting solutions

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.