Charles Sprickman wrote:
I'd really like to move past the duplex issues. I'm very very
familiar with that and already chased my tail on that one here and in
my many years of working at an ISP. I did a back-to-back test with
speed/duplex locked and I get the same result. All the switch ports
On Fri, 4 Mar 2005, Bill Vermillion wrote:
"Ang utong ko ay sasabog sa sarap!" exclaimed Charles Sprickman
while reading this message on Fri, Mar 04, 2005 at 18:43
and then responded with:
On Fri, 4 Mar 2005, Darcy Buskermolen wrote:
On Friday 04 March 2005 14:34, Charles Sprickman wrote:
Howdy,
> AFAIK, this can only be done if the original process calls execve() on a
> setuid binary and has not marked the socket descriptor as close-on-exec.
i'm developing a gtk+ based equivalent to 'sockstat'.
when a user is proposed to run a process, which creates a socket, the
sockstat printout is for
Hi everyone,
I have a FreeBSD firewall. I get this fatal trap while
in kernel mode.
I experienced this every time I use dc++ on my pc from
the private network.
-
Here is my dmesg output :
Copyright (c) 1992-2004 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986,
On 2005-03-06 12:04, Andreas Bachmann <[EMAIL PROTECTED]> wrote:
> can a socket, which created by a user over a process (xfile.xf_uid,
> xfile.xf_pid), suddenly have another user or another process (maybee
> with setuid() or fork()) or does the socket clone?
AFAIK, this can only be done if the ori
hi!
can a socket, which created by a user over a process (xfile.xf_uid,
xfile.xf_pid), suddenly have another user or another process (maybee
with setuid() or fork()) or does the socket clone?
greets
Andreas Bachmann
___
freebsd-net@freebsd.org mailing
