maybe "sudo /etc/netstart"

i don't think netstart would clear pending SYN packets, because why would it

but also a syn flood won't cause ping times to increase unless you're actually running out of bandwidth, in which case a reboot won't help

i find it bizarre that you "get lots of synfloods" - do you have any why? syn flood is pretty ineffective nowadays and it would be unusual to see that in a DDoS

s/any why/any idea why/

its a very popular website thats been around for decades

aaand people are assholes

All of the public servers I admin get SYN flood attacks routinely. Because people are the problem.

i know there are several systems you can use to resist synfloods

i'm specifically looking for what i can do when all else fails

So far the use of syncookies has been sufficient to mitigate the attacks. (shrug)

thats good, hopefully once i switch to a freebsd server, i don' thave any trouble anymore

The Linux kernel also implements syncookies and should also not have any problems. I fear that because you have had problems even on Linux that the problem is actually something different and therefore the problem will persist.

you incorrectly assume i use linux

Not that moving to FreeBSD isn't an excellent choice regardless.

Oh! Okay. Sorry. Most people switching to FreeBSD are coming from GNU/Linux so that is a typical path.

i'm coming from macos x

the only syn flood protection on this os is in the pf firewall, but surprise, it is broken

I know little to nothing about Mac OS X but thought they used a form of BSD kernel too. So I am surprised.

so i'm basically wide open

GoSox: have a look at man.freebsd.org/syncookies this may help you

they used a bsd kernel when it forked 25 years ago, but they didnt' carry over many updates over the years

IIRC syncookies are also available on Linux, so maybe you can experiment there before

Linux kernel definitely implements syncookies. FreeBSD does too.

if i were using linux, that would be useful for me :P

Which "that" is the that to which you are referring?

GoSox: and also freebsdfoundation.org/wp-content/up…f-syncookie-Code-to-FreeBSDs-pf.pdf for some newer tricks

the fact that linux has syn cookies

dch, Interesting article! Now I am off to read it.

so my overall question here is not 'how do i resist synfloods', it is - is there a way i can fully halt and reset my tcp stack on the fly if i need to, for any reason

hopefully syncookies works perfectly and i never have to use this ability

on macosx, i have to take both ethernet interfaces down using weird mac specific commands, then wait a few seconds, then bring them back up. but it all happens slow, i assume because its waiting for connections to either close or timeout.

GoSox: if thats what you want to do, just `ifconfig igb0 down; sleep 3; ifconfig igb0 up` for whatever your interface name is

for what its worth in 14 or more years of running public facing BSD systems I've never needed to "reset the tcp stack"

and this includes dealing with real-world DDOS and similar attacks

i never did for many many years, until the syn floods started

if i never have to reset it, that will be great

I would run pf firewall, and restart pf, this will be (a) fast, (b) common practice, (c) drop all stateful connections

`service pf restart`

will that instant-axe all connections?

all tcp connections yes

udp, icmp etc being stateless, no

more to the point syncookie handling is done in pf

hmm maybe ill try that on my current server just to see what happens

that PDF I linked above is good

if you really want to restart the network stack, which I would not advise, then something like this probably is sufficient

run in a tmux or similar so you don't lose the connection partway through

i REALLY need to find the time to set up a new bsd server

I have never needed to "restart the network stack" either.

GoSox: dch it will remove the connection state from the firewall, but not kill the connections on the host

tcp should recover

[tj]: I tried kldunloading my nic, but thats not very successful either

damn network is awfully good at reconnecting after transient intended outages

dch: just now reading your link, this is pretty interesting. I don't use bootenvs currently but might try them.

egwynn: zfs + boot environments are pure sysadmin crack, you'll never go back.

I'm currently git bisecting a kernel panic with each branch ending up as a boot env

it would be almost impossible on any other setup to do this without being onsite

yeah, the only thing stopping me is being too lazy to move/split-up all of my data to match the required layout

default freebsd install is all you need

zroot/ROOT/default -> this is "/"

and then yeah your own data needs to be split up

the rest of the zfs mountpoints are niceties

I'll investigate again

you're welcome to post questions & get some help migrating

ah, that's right, I don't have a dataset that root sits under. it sits right on the pool. `tank/root`

I followed a zfs migration guide back in the 10.X days before zfs was part of the default

but honestly it wouldn't be THAT big a deal to move root

i'm trying out iocage, vnet for a jail is 0, ifconfig shows the host adapters, but netstat -rn is empty and i can't get packets out... what am i missing? when i make the jail with jail(8) and ip4=inherit it works fine

ah, set ip4=inherit in iocage too, it's new by default

did freebsd just drop support for SPARC?

UltraSPARC is a Tier 2 architecture through FreeBSD 12.x. It is no longer supported in FreeBSD 13.0 and later.

i wouldn't say "just"

On the platform page I only see a reference to SPARC where it mentions that SPARCv9 was dropped after 12.4 (which was EoL end of 2022)

ah, no the EOL list is confusing, it lists the release date there

mmm

yeah I guess it's for the best instead of letting it rot

i can't remember what version i tried last, maybe 9.2? but i had it dual booting with Solaris 8

after logging in, i'd get program loading errors on basic utilities included from /bin

i just expected more from tier 2 heh

cautionary tale of what would probably happen if i were to port bsd to some random obscure platform. it's already been done before, rotted away, and got dropped. :/

Hmm, I'm having some problems with the bird routing daemon doing BGP on FreeBSD. After an hour or two, my routes stop being announced. bird says "Socket: Connection closed" when I look at the protocol status. If I restart bird, it reconnects just fine and comes back up.

Any way I can make it... not do that, or tell it to autoreconnect?

and you're having this problem "on FreeBSD"

Yes?

implying that on other platforms, you've done BGP with BIRD in the past and not had this problem

Nope

so then do a diff on the packaged versions of default config files

this sounds like some kind of inactivity timeout

I'm saying I've never used it on other platforms :p

then it's not really a freebsd question, is it...

If you can't help me, just don't say anything.

wouldn't be the first time we've found someone helpful with software available on freebsd here

i can't help you but i can offer some helpFUL advice

try /j #bird ?

ivy was doing some bird stuff.. sorry for the ping if not a good time

hello, what's up

appledash: i've never seen that, but i'd start by looking at tcpdump. also, make sure you're specifying the local address

Is anybody successfully using dl_iterate_phdr(3)?

For me it hangs when acquiring a mutex, although I don't call it multiple times.

cracauer: in waht context are you trying to use it?

there may be some, e.g., pthread or fork scenarios where you recurse on the lock

The Clasp Common Lisp compiler uses it to find the base of loaded libraries.

let me look up a github link.