- jir ji jimaria j...@logx.com irc#tokyo15 icq jir 3941247-
http://www.enjoynight.com/cgi-bin/friends/ji/familychat.cgi
VAIO PCG-C1 FreeBSD
be late sorry
Thunks kindness to Mr Dirk GOUDERS
From: Dirk GOUDERS
Subject: Re: [FreeBSD-net-jp 1746] [FYI] Adaptec AIC-6915 "Starfire"
ethernet controll
On Fri, 30 Jul 1999, Alex Zepeda wrote:
> On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
>
> > http://features.linuxtoday.com/stories/8191.html
> >
> > A story on upcoming plans for the Linux 2.4 kernel. Since they're
> > going after a lot of the same performance goals we are, it's worth a
> > r
- jir ji jimaria [EMAIL PROTECTED] irc#tokyo15 icq jir 3941247-
http://www.enjoynight.com/cgi-bin/friends/ji/familychat.cgi
VAIO$B!!(BPCG-C1$B!!(BFreeBSD
be$B!!(Blate$B!!(Bsorry
Thunks kindness to Mr Dirk GOUDERS
From: Dirk GOUDERS <[EMAIL PROTECTED]>
Subject: Re: [FreeBSD-net-jp 1746]
On Fri, 30 Jul 1999, Alex Zepeda wrote:
> On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
>
> > http://features.linuxtoday.com/stories/8191.html
> >
> > A story on upcoming plans for the Linux 2.4 kernel. Since they're
> > going after a lot of the same performance goals we are, it's worth a
> >
If memory serves, didn't John Reynolds~ say:
>
> 1) The sound card make and model/chipset. Please be as specific as you
> can with board rev numbers if possible. Please include wether the card is
> ISA or PCI.
Crystal Tidalwave32 -- plug-n-play ISA card
CSN 1 Vendor ID: XTL0005 [0x05008c62]
> 2)
On Sat, 31 Jul 1999, kylee wrote:
> Unsubscribe
No.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
> http://features.linuxtoday.com/stories/8191.html
>
> A story on upcoming plans for the Linux 2.4 kernel. Since they're
> going after a lot of the same performance goals we are, it's worth a
> read.
It seems to me that a lot of the features mention
http://features.linuxtoday.com/stories/8191.html
A story on upcoming plans for the Linux 2.4 kernel. Since they're
going after a lot of the same performance goals we are, it's worth a
read.
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the bo
If memory serves, didn't John Reynolds~ say:
>
> 1) The sound card make and model/chipset. Please be as specific as you
> can with board rev numbers if possible. Please include wether the card is
> ISA or PCI.
Crystal Tidalwave32 -- plug-n-play ISA card
CSN 1 Vendor ID: XTL0005 [0x05008c62]
> 2
On Sat, 31 Jul 1999, kylee wrote:
> Unsubscribe
No.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
> http://features.linuxtoday.com/stories/8191.html
>
> A story on upcoming plans for the Linux 2.4 kernel. Since they're
> going after a lot of the same performance goals we are, it's worth a
> read.
It seems to me that a lot of the features mentio
http://features.linuxtoday.com/stories/8191.html
A story on upcoming plans for the Linux 2.4 kernel. Since they're
going after a lot of the same performance goals we are, it's worth a
read.
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body
Unsubscribe
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Unsubscribe
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Unsubscribe
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
In message <37a25361.34799...@bellatlantic.net> Sergey Babkin writes:
: Disabling bpf it will break rarpd (and also rbootd but it is less
: important). I think such a thing should be mentioned in documentation.
Not if they are started before the secure level is raised.
Warner
To Unsubscribe: s
On Fri, Jul 30, 1999 at 03:27:20PM +0200, Dag-Erling Smorgrav wrote:
>
> Funnily, I experience a near-doubling of running time with similar
> patches.
Incidentally, it seems that it's not possible to assume that our
regex library is even anywhere in the same league as the GNU regex
library.
b$ t
Unsubscribe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Unsubscribe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Unsubscribe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Fri, 30 Jul 1999, Matthew Dillon wrote:
> The only other major feature is the nq leasing stuff for cache coherency,
> but it is highly experimental and you probably shouldn't use it. Plus
> very few other OS's support it.
heh... I'm just happy when the stuff works that's s
In message <[EMAIL PROTECTED]> Sergey Babkin writes:
: Disabling bpf it will break rarpd (and also rbootd but it is less
: important). I think such a thing should be mentioned in documentation.
Not if they are started before the secure level is raised.
Warner
To Unsubscribe: send mail to [EMA
:> consistant with the meaning of "raw devices".
:
:Disabling bpf it will break rarpd (and also rbootd but it is less
:important). I think such a thing should be mentioned in documentation.
:
:-SB
Not if rarpd is started via the rc files... it would hook up to bpf
prior to the secureleve
Warner Losh wrote:
>
> In message
> "Brian F. Feldman" writes:
> : And how about having
> : if (securelevel > 3)
> : return (EPERM);
> : in bpf_open()?
>
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with the meaning of "raw devices".
Dis
:Anyway, Mr. Dillon, once I have a development box to smack around, I
:intend to start with your suggestion of implementing a filesystem
:of my own concoction by returning an error for all VOP calls and
:issuing a kernel printf. How visible will the new VOP code be to
:me at this level? The Peng
On Fri, Jul 30, 1999 at 03:27:20PM +0200, Dag-Erling Smorgrav wrote:
>
> Funnily, I experience a near-doubling of running time with similar
> patches.
Incidentally, it seems that it's not possible to assume that our
regex library is even anywhere in the same league as the GNU regex
library.
b$
:
:> amd.Interfaces:
:>
:> /defaults type:=nfs;opts:=rw,vers=3,readdirplus,intr,proto=udp
:>
:> * rhost:=IP${key};rfs:=/Space/${key}
:
:Not to rain on your parade, but Dag-Erling informed me that there
:was problems using NFSv3 over the loopback interface that can cause
:locku
: Spent quite a bit of time today playing around with the newly
:repaired readdirplus option for nfs clients in -current. My thanks to Matt
:Dillon and Bill Paul. For those that don't remember, I'm trying to use
:amd/nfs client stuff on some freebsd web servers that read their data from
:our
On Fri, 30 Jul 1999, Matthew Dillon wrote:
> The only other major feature is the nq leasing stuff for cache coherency,
> but it is highly experimental and you probably shouldn't use it. Plus
> very few other OS's support it.
heh... I'm just happy when the stuff works that's
:In message <9518.933378...@zippy.cdrom.com> "Jordan K. Hubbard" writes:
:: > There are no security levels > 3. I'd be happy with > 0. This is
:: > consistant with the meaning of "raw devices".
::
:: Would you be willing to make this change?
:
:Yes. I will make this change tomorrow unless there
:> consistant with the meaning of "raw devices".
:
:Disabling bpf it will break rarpd (and also rbootd but it is less
:important). I think such a thing should be mentioned in documentation.
:
:-SB
Not if rarpd is started via the rc files... it would hook up to bpf
prior to the securelev
On Fri, 30 Jul 1999, Doug wrote:
> Spent quite a bit of time today playing around with the newly
> repaired readdirplus option for nfs clients in -current. My thanks to Matt
> Dillon and Bill Paul. For those that don't remember, I'm trying to use
> amd/nfs client stuff on some freebsd web se
Warner Losh wrote:
>
> In message <[EMAIL PROTECTED]> "Brian F.
>Feldman" writes:
> : And how about having
> : if (securelevel > 3)
> : return (EPERM);
> : in bpf_open()?
>
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with the meaning of
:Anyway, Mr. Dillon, once I have a development box to smack around, I
:intend to start with your suggestion of implementing a filesystem
:of my own concoction by returning an error for all VOP calls and
:issuing a kernel printf. How visible will the new VOP code be to
:me at this level? The Pen
:
:> amd.Interfaces:
:>
:> /defaults type:=nfs;opts:=rw,vers=3,readdirplus,intr,proto=udp
:>
:> * rhost:=IP${key};rfs:=/Space/${key}
:
:Not to rain on your parade, but Dag-Erling informed me that there
:was problems using NFSv3 over the loopback interface that can cause
:lock
Spent quite a bit of time today playing around with the newly
repaired readdirplus option for nfs clients in -current. My thanks to Matt
Dillon and Bill Paul. For those that don't remember, I'm trying to use
amd/nfs client stuff on some freebsd web servers that read their data from
our sun
: Spent quite a bit of time today playing around with the newly
:repaired readdirplus option for nfs clients in -current. My thanks to Matt
:Dillon and Bill Paul. For those that don't remember, I'm trying to use
:amd/nfs client stuff on some freebsd web servers that read their data from
:our
:In message <[EMAIL PROTECTED]> "Jordan K. Hubbard" writes:
:: > There are no security levels > 3. I'd be happy with > 0. This is
:: > consistant with the meaning of "raw devices".
::
:: Would you be willing to make this change?
:
:Yes. I will make this change tomorrow unless there is signific
In message <9518.933378...@zippy.cdrom.com> "Jordan K. Hubbard" writes:
: > There are no security levels > 3. I'd be happy with > 0. This is
: > consistant with the meaning of "raw devices".
:
: Would you be willing to make this change?
Yes. I will make this change tomorrow unless there is sig
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with the meaning of "raw devices".
Would you be willing to make this change?
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
On Fri, 30 Jul 1999, Doug wrote:
> Spent quite a bit of time today playing around with the newly
> repaired readdirplus option for nfs clients in -current. My thanks to Matt
> Dillon and Bill Paul. For those that don't remember, I'm trying to use
> amd/nfs client stuff on some freebsd web s
In message
Alfred Perlstein writes:
: What about the one-way sysctls that have been suggested?
They need to be implemente dfirst. A quick securelevel > 0 in bpf_open
would allow many people's objections to bpf in the kernel by default.
Warner
To Unsubscribe: send mail to majord...@freebsd.o
On Fri, 30 Jul 1999, Warner Losh wrote:
> In message
> "Brian F. Feldman" writes:
> : And how about having
> : if (securelevel > 3)
> : return (EPERM);
> : in bpf_open()?
>
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with the meaning of "raw
In message "Brian
F. Feldman" writes:
: And how about having
: if (securelevel > 3)
: return (EPERM);
: in bpf_open()?
There are no security levels > 3. I'd be happy with > 0. This is
consistant with the meaning of "raw devices".
Warner
To Unsubscribe: send mail to ma
In message <8605.933365...@zippy.cdrom.com> "Jordan K. Hubbard" writes:
: It already is. That's not the question under discussion here - we're
: talking about how to make things work in the post-installation boot
: scenario.
I'm in favor of having it in the kernel by default. With one
proviso.
On Fri, 30 Jul 1999, Guy Helmer wrote:
# Have you tried booting with the "-v" flag to see the driver's probe
# messages? Did you configure the card using the configuration "pnp"
# commands before the kernel starts booting? For example,
I did the former but not the latter. I'll stick it in a
ma
Spent quite a bit of time today playing around with the newly
repaired readdirplus option for nfs clients in -current. My thanks to Matt
Dillon and Bill Paul. For those that don't remember, I'm trying to use
amd/nfs client stuff on some freebsd web servers that read their data from
our sun
In message <[EMAIL PROTECTED]> "Jordan K. Hubbard" writes:
: > There are no security levels > 3. I'd be happy with > 0. This is
: > consistant with the meaning of "raw devices".
:
: Would you be willing to make this change?
Yes. I will make this change tomorrow unless there is significant
obj
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with the meaning of "raw devices".
Would you be willing to make this change?
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
On Fri, Jul 30, 1999 at 03:27:20PM +0200, Dag-Erling Smorgrav wrote:
>
> > it was VERY simple to do... and attached is the patch... this uses the
> > option REG_STARTEND to do what the copy was trying to do... all of the
> > code to use REG_STARTEND was already there, it just needed to be enabled..
In message <[EMAIL PROTECTED]>
Alfred Perlstein writes:
: What about the one-way sysctls that have been suggested?
They need to be implemente dfirst. A quick securelevel > 0 in bpf_open
would allow many people's objections to bpf in the kernel by default.
Warner
To Unsubscribe: send mail to
On Fri, 30 Jul 1999, Warner Losh wrote:
> In message <[EMAIL PROTECTED]> "Brian F.
>Feldman" writes:
> : And how about having
> : if (securelevel > 3)
> : return (EPERM);
> : in bpf_open()?
>
> There are no security levels > 3. I'd be happy with > 0. This is
> consistant with
In message <[EMAIL PROTECTED]> "Brian F.
Feldman" writes:
: And how about having
: if (securelevel > 3)
: return (EPERM);
: in bpf_open()?
There are no security levels > 3. I'd be happy with > 0. This is
consistant with the meaning of "raw devices".
Warner
To Unsubscr
In message <[EMAIL PROTECTED]> "Jordan K. Hubbard" writes:
: It already is. That's not the question under discussion here - we're
: talking about how to make things work in the post-installation boot
: scenario.
I'm in favor of having it in the kernel by default. With one
proviso. Any place wh
On Fri, 30 Jul 1999, Guy Helmer wrote:
# Have you tried booting with the "-v" flag to see the driver's probe
# messages? Did you configure the card using the configuration "pnp"
# commands before the kernel starts booting? For example,
I did the former but not the latter. I'll stick it in a
m
On Fri, Jul 30, 1999 at 10:56:55PM +0900, Daniel C. Sobral wrote:
>
> I said that I did not care whether the thing is inside or outside
> the regexp library.
Yes, although I think at this point it's obvious we're coming at this
discussion from fairly different perspectives. By the time you
broug
On Fri, 30 Jul 1999, Doug wrote:
> The -n option to trafshow disables number->name translation for
> both addresses and ports, although that might be more than what is wanted.
> I do know what you mean though. On some of the machines I administer I
> have some custom entries for /etc/service
On Thu, 29 Jul 1999, Ben Rosengart wrote:
> On Thu, 29 Jul 1999, Josef Karthauser wrote:
>
> > Ok - but it's a bit misleading having both values in /etc/services..
> >
> > Shouldn't be:
> > http 80/tcpwww www-http #World Wide Web HTTP
> > http 80/udpwww ww
On Wed, 28 Jul 1999, Matthew Dillon wrote:
> :> Sheldon Hearn writes:
> :> > I plan to mention in the comments for each service in /etc/services, the
> :> > latest RFC describing the service.
> :>
> :> Good idea.
> :
> : H... I'm not sure what this gets us. Wouldn't it be better to
> :pl
On Fri, Jul 30, 1999 at 03:27:20PM +0200, Dag-Erling Smorgrav wrote:
>
> > it was VERY simple to do... and attached is the patch... this uses the
> > option REG_STARTEND to do what the copy was trying to do... all of the
> > code to use REG_STARTEND was already there, it just needed to be enabled.
* Nik Clayton (n...@nothing-going-on.demon.co.uk) [990730 23:37]:
> -hackers,
>
> Is the FreeBSD Device Driver Writers Guide at
>
> http://www.freebsd.org/tutorials/ddwg/ddwg.html
>
> still correct? I know there have been changes to this area of the tree
> over the past 6 months or so, but
* Nik Clayton (n...@nothing-going-on.demon.co.uk) [990730 23:37]:
> Hi folks,
>
> We have an a.out(5), but no elf(5) (as pointed out in docs/7914).
>
> Does anyone feel up to writing one?
Saw it before, noticed it, placed on my to-do list. If no-one objects
I'll submit a manpage per a.out(5) sty
On Fri, Jul 30, 1999 at 10:56:55PM +0900, Daniel C. Sobral wrote:
>
> I said that I did not care whether the thing is inside or outside
> the regexp library.
Yes, although I think at this point it's obvious we're coming at this
discussion from fairly different perspectives. By the time you
brou
On Fri, 30 Jul 1999, Doug wrote:
> The -n option to trafshow disables number->name translation for
> both addresses and ports, although that might be more than what is wanted.
> I do know what you mean though. On some of the machines I administer I
> have some custom entries for /etc/servic
On Thu, 29 Jul 1999, Ben Rosengart wrote:
> On Thu, 29 Jul 1999, Josef Karthauser wrote:
>
> > Ok - but it's a bit misleading having both values in /etc/services..
> >
> > Shouldn't be:
> > http 80/tcpwww www-http #World Wide Web HTTP
> > http 80/udpwww w
I prefer to work in flat ASCII. Perhaps the doc project can HTMLize
the final product.
Currently, I'm hatching a plan to free up an AMD386/40 running
FreeBSD 2.1.5 for use as a 4.x sandbox. The little thing has been
faithfully and unerringly natd-ing my whole Solaris/NetBSD/Linux/
UNIXWare LAN o
On Wed, 28 Jul 1999, Matthew Dillon wrote:
> :> Sheldon Hearn <[EMAIL PROTECTED]> writes:
> :> > I plan to mention in the comments for each service in /etc/services, the
> :> > latest RFC describing the service.
> :>
> :> Good idea.
> :
> : H... I'm not sure what this gets us. Wouldn't i
On Fri, 30 Jul 1999, Steve Price wrote:
> Anyone have detailed docs for 3Com's 3C515 NIC? I found
> Guy Helmer's driver, http://www.freebsd.org/~ghelmer/3c515/
> but it didn't recognize the card I have. I was going to
> spend some time this weekend to see if I could figure out
> what was up. Ju
> I thought we decided that the networking gurus we're going to make it
> possible to send out broadcast packets on an unconfigured interface so
> that DHCP would work, so that bpf wasn't required.
I believe we decided that this would be the preferred method, yes. I
don't think, however, that we
On Fri, 30 Jul 1999, Nate Williams wrote:
> > This is a clear security vs functionality issue and I need to get a
> > good feel for which "cause" is ascendent here in knowing which way to
> > jump on the matter. Can we now hear the closing arguments from the
> > pro and con folks?
>
> I thought
* Nik Clayton ([EMAIL PROTECTED]) [990730 23:37]:
> -hackers,
>
> Is the FreeBSD Device Driver Writers Guide at
>
> http://www.freebsd.org/tutorials/ddwg/ddwg.html
>
> still correct? I know there have been changes to this area of the tree
> over the past 6 months or so, but I don't know ho
* Nik Clayton ([EMAIL PROTECTED]) [990730 23:37]:
> Hi folks,
>
> We have an a.out(5), but no elf(5) (as pointed out in docs/7914).
>
> Does anyone feel up to writing one?
Saw it before, noticed it, placed on my to-do list. If no-one objects
I'll submit a manpage per a.out(5) style tomorrow for
Anyone have detailed docs for 3Com's 3C515 NIC? I found
Guy Helmer's driver, http://www.freebsd.org/~ghelmer/3c515/
but it didn't recognize the card I have. I was going to
spend some time this weekend to see if I could figure out
what was up. Just thought it might be easier if I had
a little lig
:> BTW, I wrote this section because a hacker actually installed the bpf
:> device via the module loader during one of the root compromises at BEST,
:> a year or two ago. He had gotten it from a hackers cookbook of exploits
:> which he convieniently left on-disk long enough for ou
> This is a clear security vs functionality issue and I need to get a
> good feel for which "cause" is ascendent here in knowing which way to
> jump on the matter. Can we now hear the closing arguments from the
> pro and con folks?
I thought we decided that the networking gurus we're going to mak
> : But even if you turn off the bpf device, you still have /dev/mem and
> : /dev/kmem to worry about. For that matter, the intruder can still write
> : raw devices. Also, there is another kernel feature called kldload(8).
>
> BTW, I wrote this section because a hacker actually i
On Fri, 30 Jul 1999, Matthew Dillon wrote:
> : But even if you turn off the bpf device, you still have /dev/mem and
> : /dev/kmem to worry about. For that matter, the intruder can still write
> : raw devices. Also, there is another kernel feature called kldload(8).
>
> BTW, I wr
: But even if you turn off the bpf device, you still have /dev/mem and
: /dev/kmem to worry about. For that matter, the intruder can still write
: raw devices. Also, there is another kernel feature called kldload(8).
BTW, I wrote this section because a hacker actually installed t
On Fri, 30 Jul 1999, Brian F. Feldman wrote:
> On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
>
> > > There's no good reason to not have bpf in at least the boot disk kernel.
> >
> > It already is. That's not the question under discussion here - we're
> > talking about how to make things work in
I prefer to work in flat ASCII. Perhaps the doc project can HTMLize
the final product.
Currently, I'm hatching a plan to free up an AMD386/40 running
FreeBSD 2.1.5 for use as a 4.x sandbox. The little thing has been
faithfully and unerringly natd-ing my whole Solaris/NetBSD/Linux/
UNIXWare LAN
On Fri, 30 Jul 1999, Steve Price wrote:
> Anyone have detailed docs for 3Com's 3C515 NIC? I found
> Guy Helmer's driver, http://www.freebsd.org/~ghelmer/3c515/
> but it didn't recognize the card I have. I was going to
> spend some time this weekend to see if I could figure out
> what was up. J
> I thought we decided that the networking gurus we're going to make it
> possible to send out broadcast packets on an unconfigured interface so
> that DHCP would work, so that bpf wasn't required.
I believe we decided that this would be the preferred method, yes. I
don't think, however, that we
On Fri, 30 Jul 1999, Jordan K. Hubbard wrote:
> > There's no good reason to not have bpf in at least the boot disk kernel.
>
> It already is. That's not the question under discussion here - we're
> talking about how to make things work in the post-installation boot
> scenario.
When did that hap
On Fri, 30 Jul 1999, Nate Williams wrote:
> > This is a clear security vs functionality issue and I need to get a
> > good feel for which "cause" is ascendent here in knowing which way to
> > jump on the matter. Can we now hear the closing arguments from the
> > pro and con folks?
>
> I thought
> There's no good reason to not have bpf in at least the boot disk kernel.
It already is. That's not the question under discussion here - we're
talking about how to make things work in the post-installation boot
scenario.
- Jordan
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubs
> It will let us use a dhcp client in the install programs, this is of
> tremendous use to many people as DHCP starts to become much more
> popular. I cannot net install a machine at home since that is on a
> DHCP cable modem service.
Well, just to clarify this, if you're installing a 4.0 snapsho
If root is compromised, that's the only way bpf can be gotten to by
default. When root's compromised, if no bpf is available, the mem devices
can still be created (if not there) and network queues can be listened to.
And can't IFF_PROMISC be turned on too?
There's no good reason to not have bpf in
Time for this oppressed person to go ln -s H /etc/malloc.conf...
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___
Here is a pro vote for enabling BPF in GENERIC:
It will let us use a dhcp client in the install programs, this is of tremendous
use to many people as DHCP starts to become much more popular. I cannot
net install a machine at home since that is on a DHCP cable modem service.
Also, if root is comp
Anyone have detailed docs for 3Com's 3C515 NIC? I found
Guy Helmer's driver, http://www.freebsd.org/~ghelmer/3c515/
but it didn't recognize the card I have. I was going to
spend some time this weekend to see if I could figure out
what was up. Just thought it might be easier if I had
a little li
On Fri, Jul 30, 1999 at 09:13:52AM -0700, a little birdie told me
that Mike Smith remarked
>
> I think that the administrator should be forced to override the warning
> manually to indicate that they are aware of the issues they are getting
> themselves in for, or at the very least that there sh
:> BTW, I wrote this section because a hacker actually installed the bpf
:> device via the module loader during one of the root compromises at BEST,
:> a year or two ago. He had gotten it from a hackers cookbook of exploits
:> which he convieniently left on-disk long enough for o
> This is a clear security vs functionality issue and I need to get a
> good feel for which "cause" is ascendent here in knowing which way to
> jump on the matter. Can we now hear the closing arguments from the
> pro and con folks?
I thought we decided that the networking gurus we're going to ma
> : But even if you turn off the bpf device, you still have /dev/mem and
> : /dev/kmem to worry about. For that matter, the intruder can still write
> : raw devices. Also, there is another kernel feature called kldload(8).
>
> BTW, I wrote this section because a hacker actually
On Thu, Jul 29, 1999 at 10:45:51AM -0500, Alton, Matthew wrote:
> I ran screaming into the woods last year from trying to grok VOP_foo. The
> prospect of a rewrite fills me with warmth and fuzziness. I hereby volunteer
> to maintain the VOP(9) man pages and to flesh out my notes into a big, beefy
We got off onto a big tangent about switches and vlans and stuff and I
learned a number of interesting things, don't get me wrong, but we
still haven't established any consensus on the trade-offs of enabling
bpf. This wasn't meant to be a hypothetical discussion, I'm truly
trying to measure the tr
On Fri, 30 Jul 1999, Matthew Dillon wrote:
> : But even if you turn off the bpf device, you still have /dev/mem and
> : /dev/kmem to worry about. For that matter, the intruder can still write
> : raw devices. Also, there is another kernel feature called kldload(8).
>
> BTW, I w
: But even if you turn off the bpf device, you still have /dev/mem and
: /dev/kmem to worry about. For that matter, the intruder can still write
: raw devices. Also, there is another kernel feature called kldload(8).
BTW, I wrote this section because a hacker actually installed
Hi folks,
We have an a.out(5), but no elf(5) (as pointed out in docs/7914).
Does anyone feel up to writing one?
N
--
[intentional self-reference] can be easily accommodated using a blessed,
non-self-referential dummy head-node whose own object destructor severs
the links.
-- Tom Christia
-hackers,
Is the FreeBSD Device Driver Writers Guide at
http://www.freebsd.org/tutorials/ddwg/ddwg.html
still correct? I know there have been changes to this area of the tree
over the past 6 months or so, but I don't know how much of that document
is still appropriate for what we have now.
1 - 100 of 178 matches
Mail list logo
