(Consolidating replies to three messages.)
>recvmsg() gets you the interface index, not name. If you want to filter by
>name, you have to maintain a index to name array. Doing that once is
>probably reasonably clean. Keeping it up to date might get interesting.
You're talking about case ALPHA
e...@thyrsus.com said:
> >Is there a clean way to get notified when an interface comes or goes?
> Yes, that's what routing sockets gives you - notification when there's a
> routing change. (I don't understand the details well, but this seems to be
> the big picture.)
Are routing sockets availa
On 29-05-18 17:44, Mark Atwood, Project Manager via devel wrote:
There are a couple of different but very similar angles of approach to
explain why a network security experts will not trust a userspace daemon to
control it's own defensive packet filtering.
Cool.
So what iptables (etc) filter ru
Hal Murray :
>
> e...@thyrsus.com said:
> > >Is there a clean way to get notified when an interface comes or goes?
> > Yes, that's what routing sockets gives you - notification when there's a
> > routing change. (I don't understand the details well, but this seems to be
> > the big picture.)
>
On Wed, May 30, 2018 at 05:11:23AM -0400, Eric S. Raymond via devel wrote:
> >If you were an admin and wanted to take packets from the red cable and
> >ignore packets from the blue cable, how would you set things up? Would you
> >filter by interface name or IP Address?
>
> Ask a large-site admin
As much as I'd like to clean up this area, I think we should put it on the
back burner for now.
Maybe we should put a note in devel/ with a summary of what we have learned.
Actually, I'd like to see a class of notes there. We should use this as a
good example. I'm interested in things that a
Matthew Selsky :
> We use "-L" on hosts with hundreds of virtual IPs to avoid errors
> about "out of file descriptors".
I see. OK, that problem would go away under SINGLESOCK - just one socket
for all IP addresses.
> We also use "-I address" on multi-homed hosts to attempt to ensure
> that ntpd
Hal Murray:
>As much as I'd like to clean up this area, I think we should put it on the
>back burner for now.
What makes it a better idea to wait?
>There is a slightly related area that needs cleaning up. There are no
>externally visible impacts so there is no reason not to do it. I don't hav
> What makes it a better idea to wait?
I don't see any clean solution.
There are actually two separate areas. One is a single socket. The other is
interface tracking.
FreeBSD doesn't support single socket.
The interface cleanup gets tangled up with cleaning up the UI. I don't see
any clean
Let's step back from SINGLESOCK for a bit and focus on security.
Is the NTS draft-RFC in good enough shape that we can write code now?
I've studied it, but didn't understand things. My criteria for "understand"
is that I could explain it to somebody else. "Write code" might be another
test.
Hal Murray :
>
> Let's step back from SINGLESOCK for a bit and focus on security.
>
> Is the NTS draft-RFC in good enough shape that we can write code now?
>
> I've studied it, but didn't understand things. My criteria for "understand"
> is that I could explain it to somebody else. "Write cod
Hal Murray :
> > What makes it a better idea to wait?
>
> I don't see any clean solution.
>
> There are actually two separate areas. One is a single socket. The other is
> interface tracking.
>
> FreeBSD doesn't support single socket.
>
> The interface cleanup gets tangled up with cleaning up
12 matches
Mail list logo
