than
perhaps logging the inbound messages to the file system, a normal blocking
socket is all you need.
Paul Vixie
noting that we can't get rid of the conditional branch no matter whether we
assign twice or assign once, regardless of whether the condition is expressed
as a trinary expression or an if-else chain. i didn't mean to imply otherwise.
On Monday, June 9, 2025 5:19:53 PM UTC Mark Johnston wrote:
> On Mon, Jun 09, 2025 at 04:42:55AM +0000, Paul Vixie wrote:
> > ...
> I've made a number of inline comments.
tyvm! this is precisely the kind of review i'd hoped for. see inline.
> > - so->so_fibnu
On Monday, May 19, 2025 6:09:08 PM UTC Patrick M. Hausen wrote:
> Hi all,
>
> > Am 19.05.2025 um 19:28 schrieb Paul Vixie :
> >
> > If we move all member ifaddrs to the bridge itself, then will arp requests
> > always have to be broadcast on all member interfaces?
If we move all member ifaddrs to the bridge itself, then will arp requests
always have to be broadcast on all member interfaces? If so this is intolerable
from a security perspective, a complete nonstarter.
On Friday, March 21, 2025 8:22:56 AM UTC Paul Vixie wrote:
> This is a reply to the second of two of Julian's recent messages.
>
> On Friday, March 14, 2025 4:45:48 AM UTC Julian Elischer wrote:
>
> > I think the order of evaluation would be Process FIB highest pr
This is a reply to the second of two of Julian's recent messages.
On Friday, March 14, 2025 4:45:48 AM UTC Julian Elischer wrote:
> On 2/21/25 8:35 AM, Paul Vixie wrote:
> > On Thursday, February 20, 2025 4:47:41 PM UTC Mark Johnston wrote:
> >> On Tue, Feb 18, 2025 at
This is a reply to the first of two of Julian's recent messages.
On Friday, March 14, 2025 4:26:30 AM UTC Julian Elischer wrote:
> On 1/28/25 12:09 AM, Mark Johnston wrote:
> > On Sat, Jan 25, 2025 at 08:44:25PM +0000, Paul Vixie wrote:
> >> does anyone remember why the FIB
On Friday, February 21, 2025 12:35:17 AM UTC Paul Vixie wrote:
> On Thursday, February 20, 2025 4:47:41 PM UTC Mark Johnston wrote:
> > On Tue, Feb 18, 2025 at 05:16:07AM +0000, Paul Vixie wrote:
> > > this is the second fibnum patch, ...
now third, having ported the work to
On Thursday, February 20, 2025 4:47:41 PM UTC Mark Johnston wrote:
> On Tue, Feb 18, 2025 at 05:16:07AM +0000, Paul Vixie wrote:
> > this is the second fibnum patch, ...
>
> The high-level changes seem to be:
> - If a TCP listening socket's FIB is 0, then the FIB of i
-
On Monday, January 6, 2025 3:56:55 PM UTC Mark Johnston wrote:
> On Fri, Dec 27, 2024 at 08:48:48AM +0000, Paul Vixie wrote:
> > On Tuesday, December 24, 2024 3:34:45 AM UTC Santiago Martinez wrote:
> > > here’s another user of fibs. Each of our servers have multiple fibs and
> &
On Monday, January 13, 2025 6:59:20 PM UTC Mark Johnston wrote:
> On Sun, Jan 12, 2025 at 07:17:48AM +0000, Paul Vixie wrote:
> > On Saturday, January 11, 2025 4:51:07 PM UTC Mark Johnston wrote:
> > > On Sat, Jan 11, 2025 at 06:25:22AM +, Paul Vixie wrote:
> >
On Saturday, January 11, 2025 4:51:07 PM UTC Mark Johnston wrote:
> On Sat, Jan 11, 2025 at 06:25:22AM +0000, Paul Vixie wrote:
> > On Monday, January 6, 2025 3:56:55 PM UTC Mark Johnston wrote:
> > > On Fri, Dec 27, 2024 at 08:48:48AM +, Paul Vixie wrote:
> > ...
On Monday, January 6, 2025 3:56:55 PM UTC Mark Johnston wrote:
> On Fri, Dec 27, 2024 at 08:48:48AM +0000, Paul Vixie wrote:
> > ...
> I think the patch is probably a good idea, and the trick of only
> inheriting the packet's FIB if the socket's is non-zero would avoid
at the form it takes in the source code (all those
macros) could
be simplified.
> FIBs are useful as is, but also can be used with "ipfw setfib" that make
> it irreplaceable.
For my primary FIB use case, ipfw is OK, but I think we need a different
default. To that
end, see Message-ID <38589000.xm6rczx...@dhcp-151.access.rits.tisf.net>.
--
Paul Vixie
On Tuesday, December 24, 2024 3:34:45 AM UTC Santiago Martinez wrote:
> Hi,
> here’s another user of fibs. Each of our servers have multiple fibs and
> jails with fibs. I like the proposed.
> Santi
Cool. Read on.
On Tuesday, December 24, 2024 5:06:32 AM UTC Jamie Landeg-Jones wrote:
so interesting but is a separate matter since
those
servers already have to maintain socket-per-interface in order to get their
source
addresses to match the client's destination address.)
--
Paul Vixie
with "add pass udp" one creates a rule that permits initial fragments of a
datagram, or unfragmented datagram, to pass. if this doesn't happen, then no
subsequent fragment will matter even if allowed through -- because there will
be no endpoint state to allow those fragments to be reassembled. s
<>
That's been a very workable system.
p vixie
On May 17, 2024 21:32, "Rodney W. Grimes" wrote:
> Scott writes:
> > Anyway, fun's over. Perhaps this is a greater lesson that the Foundation
> > provide the rules under which code is added or removed from base and then
> > we'd all be
i think it's not too soon for the bsd community to become less
reactionary. (yes, i know that's ironic coming from me.)
https://nomadbsd.org/
i'd like freebsd to be fit for a lot of purposes. a complete OS is one
of those that i will use the most. but not the only one for me, and not
the only
agreed. and one of my mods to the ultrix (~4.3bsd) kernel for
gatekeeper.dec.com back in ~1990 was to use the result of gethostid(3)
if that result was nonzero and if a socket was not already bound. so
named(8) and ntpd(8) and anything else that used explicit binding got
what they expected, but
You don't need L2 for this. The firewall pattern when your bare metal host has
an address in the vlan you use for guests is:
Allow the specific things you want the bare metal host to do;
Deny all else involving the bare metal host;
Allow all else involving the guest subnet.
p vixie
ed maste pointed me here after he saw me post the following on twixter:
>
to be clear, i can fix this and submit a patch, but won't if there ar
24 matches
Mail list logo
