[Bug 281125] ixl: fix multicast filters handling regression

2024-08-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=281125 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@freebsd.org -- You are receiv

SO_SPLICE implementation

2024-08-29 Thread Mark Johnston
Hello, Drew Gallatin and I have been working on an implementation of SO_SPLICE, an interface which allows TCP connections to be spliced together. This is intended for use in proxy applications to reduce the overhead of copying data between connections. At the moment the interface isn't widely us

Re: dropping udp fragments with ipfw

2024-08-29 Thread Ronald Klop
Van: mike tancsa Datum: donderdag, 29 augustus 2024 20:51 Aan: FreeBSD Net Onderwerp: dropping udp fragments with ipfw I was working on some firewall rules to drop large UDP fragment attacks and noticed there is no easy way to drop fragments based on port ? e.g. if someone sends a UDP packet

Re: dropping udp fragments with ipfw

2024-08-29 Thread mike tancsa
On 8/29/2024 3:45 PM, Olivier Cochard-Labbé wrote: On Thu, Aug 29, 2024 at 8:52 PM mike tancsa wrote: But this would kill all UDP fragments.  If the host has some other UDP application that needs to deal with fragmented packets, is there a way to get around that and only dr

Re: dropping udp fragments with ipfw

2024-08-29 Thread Olivier Cochard-Labbé
On Thu, Aug 29, 2024 at 8:52 PM mike tancsa wrote: > But this would kill all UDP fragments. If the host has some other UDP > application that needs to deal with fragmented packets, is there a way > to get around that and only drop packets with a certain port in the > first fragment ? > > When a

dropping udp fragments with ipfw

2024-08-29 Thread mike tancsa
I was working on some firewall rules to drop large UDP fragment attacks and noticed there is no easy way to drop fragments based on port ? e.g. if someone sends a UDP packet of 1400 bytes, I can drop it with TARGET=192.168.1.1 ipfw add 5 deny log udp from any 53 to $TARGET But if that packet

[Bug 279245] igc(4) I226 (and I225) TX hangups

2024-08-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279245 Dr. Uwe Meyer-Gruhl changed: What|Removed |Added Status|New |Closed Resolution|--

Re: wait link up before route configuration

2024-08-29 Thread Baptiste Daroussin
On Wed 28 Aug 08:40, Freddie Cash wrote: > On Wed, Aug 28, 2024 at 1:21 AM yann.mas...@thehomecave.fr < > yann.mas...@thehomecave.fr> wrote: > > > After configuring interfaces and routes, and triggering a 'service netif > > restart && service routing restart' is there a way to wait for the 'carrie

[Bug 275001] if_wg: Missing radix unlock can cause deadlock

2024-08-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275001 Mark Johnston changed: What|Removed |Added Status|In Progress |Closed Resolution|---

[Bug 279245] igc(4) I226 (and I225) TX hangups

2024-08-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=279245 CrazyWolf13 changed: What|Removed |Added CC||freebsdforums.lurch729@pass

[Bug 278306] service netif start doesn't bring up the wireless interface if /etc/wpa_supplicant.conf is missing

2024-08-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278306 --- Comment #11 from Chris Hutchinson --- (In reply to Bjoern A. Zeeb from comment #10) I think you're on the right track, Bjoern. But as I examined this approach, I discovered what may be hints to the problem here: libexec/rc/netif @ 152

[Bug 278306] service netif start doesn't bring up the wireless interface if /etc/wpa_supplicant.conf is missing

2024-08-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278306 Bjoern A. Zeeb changed: What|Removed |Added CC||n...@freebsd.org -- You are rece

[Bug 280701] FreeBSD-SA-24:05 fix breaks ICMP/ICMP6 states handling in pf firewall (ping, traceroute)

2024-08-29 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280701 --- Comment #61 from Natalino Picone --- (In reply to doktornotor from comment #60) Sorry for the missing details. This is a very long thread, and it's unclear whether an official FreeBSD patch is now in the base or not to fix the issues c