Re: Portmap non-local set / unset attempt
Martin SchrC6der <[EMAIL PROTECTED]> writes: > On 2005-09-23 00:05:14 -0700, Wolfgang S. Rupprecht wrote: >> appreciable added risk. The only loose end is that sshd doesn't >> currently log the RSA/DSA key that is used to gain access. Ideally it > > Hu? Try > LogLevel VERBOSE Your eloquent reply aside, setting the loglevel to versbose doesn't add proper key accounting to the sshd login record. What it does is add yet more clutter to /var/log/authlog by emitting quite a few more lines per login. Sshd's logs seem more like debug printfs, scattered willy-nilly around the code. The information one would expect from a security program is never gathered in one spot and output in a single audit line to see who logged in as what user. -wolfgang
Re: Portmap non-local set / unset attempt
hmm, on Thu, Sep 22, 2005 at 07:09:12PM -0600, Theo de Raadt said that > It IS POSSIBLE to set something up and have it be secure and NOT TOUCH > IT, because many people have OpenBSD machines running older releases > running without any modification for YEARS now, RISK FREE, without > having to update ANY THING. all right! let the uptime pi**ing contest begin! ;-) integer> uptime 2:12PM up 186 days, 1:11, 1 user, load averages: 0.23, 0.22, 0.17 integer> sysctl kern.version kern.version=OpenBSD 3.7 (GENERIC) #38: Wed Mar 16 13:57:54 MST 2005 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC -f ps. i think this is still a baby ;-) -- save a tree. eat a beaver.
RE: Re: Portmap non-local set / unset attempt
Making is a process.
Toast is not a process.
>- --- Original Message --- -
>From: [EMAIL PROTECTED]
>To: misc@openbsd.org
>Sent: Fri, 23 Sep 2005 02:30:10
>
>[EMAIL PROTECTED] wrote:
>
>>> Security is everything you've ever said, plus a
>process.
>>
>> If it is secure, it doesn't need a process. So
>why would security be a
>> process again? Because of the vendors making
>"mistakes" and fix it later?
>>
>> Jimmy Scott
>
>It is a "process" in the same way that "making
>toast" is a process.
>The purchase of a "bread-crisping solution" that is
>UL-certified to not
>set your house on fire is the contribution of the
>"engineering" and
>"product development" stages. In common usage,
>using this "solution"
>to toast your morning snack will produce crispy
>bread and will not
>produce a howling conflagration. However, note
>that it is still very
>much possible to ignite your domicile by soaking a
>rag in lighter fluid,
>stuffing it into the bread-toasting slot, and
>jamming the switch closed
>with a butter knife. For a less extreme example,
>it _may_ be possible
>to cause a fire by leaving a towel too near the
>toaster while it is
>operating, something which is easy to do and all
>too common.
>
>Having a morning snack and an un-burnt house at the
>same time, then, is
>contingent upon two things - possessing a toaster
>of adequate quality,
>and using it properly. You don't get to have the
>whole package without
>a) looking for a good toaster in the first place,
>and b) learning how
>to use it. Security operates similarly: one boner
>mistake on anybody's
>part - coder, engineer or administrator - and your
>"security" vaporizes
>_instantly_. Go read some of Bruce Schneier's
>screeds on the subject,
>they're informative.
>
>So yes, security most certainly _is_ partly a
>"process", various
>opinions to the contrary notwithstanding. It is
>identical to the
>process of locking your doors and checking your
>windows before you
>go to bed at night, or of making sure that you're
>not stuffing a paper
>towel or a cardboard box top in your toaster in the
>morning before
>you've had coffee. You could call it "habitual
>prudence", I suppose.
>
>Of course, computers being based on hard-core
>determinism and Boolean
>logic, a higher standard is possible. I note in
>passing that the
>security of every operating system in common use
>(including OpenBSD) is
>_unproven_ [1], with the possible exception of
>Coyotos. Asserting
>something that is unproven and which may actually
>be impossible to prove
>("X is more secure than Y") is not a good idea. In
>other words, don't
>toss shit at the vendors unless you can _prove_,
>from a chain of
>irrefutable deduction, that your proposed solution
>is "more secure" than
>theirs. (Something which is likely impossible, due
>to OpenBSD's design
>and the language in which it is written.) Hint:
>the manpower,
>brainpower, and computing power needed to
>accomplish this task _even if_
>it is possible is probably going to exceed anything
>you're willing to
>marshal to that end.
>
>Theo is right about one thing, however: Bugs and
>security flaws arise
>from mistakes, every one of which is avoidable.
>There are no "new"
>classes of bugs or design flaws, essentially every
>one has been
>generally known of and understood for decades. It
>is only sloppy
>practices - dare I say it, "bad processes" - that
>permit these bugs
>to creep into various codebases and multiply. The
>cure for this
>problem is "better processes". The "easy" cure is
>for these processes
>to entail continuous auditing (the OBSD solution).
>The harder cure
>is to work on establishing and maintaining a
>process that incorporates
>rigorous proof as a necessary component. We may
>not ever see that, but
>hey - it's nice to dream, isn't it?
>
>--
>(c) 2005 Unscathed Haze via Central Plexus
><[EMAIL PROTECTED]>
>I am Chaos. I am alive, and I tell you that you
>are Free. -Eris
>Big Brother is watching you. Learn to become
>Invisible.
>| Your message must be this wide to ride
>the Internet. |
>
>[1] Rigorous proof, that is. Anecdotal evidence
>does not establish
>proof of anything whatsoever.
Re: Portmap non-local set / unset attempt
[EMAIL PROTECTED] wrote:
Security is everything you've ever said, plus a process.
If it is secure, it doesn't need a process. So why would security be a
process again? Because of the vendors making "mistakes" and fix it later?
Jimmy Scott
It is a "process" in the same way that "making toast" is a process.
The purchase of a "bread-crisping solution" that is UL-certified to not
set your house on fire is the contribution of the "engineering" and
"product development" stages. In common usage, using this "solution"
to toast your morning snack will produce crispy bread and will not
produce a howling conflagration. However, note that it is still very
much possible to ignite your domicile by soaking a rag in lighter fluid,
stuffing it into the bread-toasting slot, and jamming the switch closed
with a butter knife. For a less extreme example, it _may_ be possible
to cause a fire by leaving a towel too near the toaster while it is
operating, something which is easy to do and all too common.
Having a morning snack and an un-burnt house at the same time, then, is
contingent upon two things - possessing a toaster of adequate quality,
and using it properly. You don't get to have the whole package without
a) looking for a good toaster in the first place, and b) learning how
to use it. Security operates similarly: one boner mistake on anybody's
part - coder, engineer or administrator - and your "security" vaporizes
_instantly_. Go read some of Bruce Schneier's screeds on the subject,
they're informative.
So yes, security most certainly _is_ partly a "process", various
opinions to the contrary notwithstanding. It is identical to the
process of locking your doors and checking your windows before you
go to bed at night, or of making sure that you're not stuffing a paper
towel or a cardboard box top in your toaster in the morning before
you've had coffee. You could call it "habitual prudence", I suppose.
Of course, computers being based on hard-core determinism and Boolean
logic, a higher standard is possible. I note in passing that the
security of every operating system in common use (including OpenBSD) is
_unproven_ [1], with the possible exception of Coyotos. Asserting
something that is unproven and which may actually be impossible to prove
("X is more secure than Y") is not a good idea. In other words, don't
toss shit at the vendors unless you can _prove_, from a chain of
irrefutable deduction, that your proposed solution is "more secure" than
theirs. (Something which is likely impossible, due to OpenBSD's design
and the language in which it is written.) Hint: the manpower,
brainpower, and computing power needed to accomplish this task _even if_
it is possible is probably going to exceed anything you're willing to
marshal to that end.
Theo is right about one thing, however: Bugs and security flaws arise
from mistakes, every one of which is avoidable. There are no "new"
classes of bugs or design flaws, essentially every one has been
generally known of and understood for decades. It is only sloppy
practices - dare I say it, "bad processes" - that permit these bugs
to creep into various codebases and multiply. The cure for this
problem is "better processes". The "easy" cure is for these processes
to entail continuous auditing (the OBSD solution). The harder cure
is to work on establishing and maintaining a process that incorporates
rigorous proof as a necessary component. We may not ever see that, but
hey - it's nice to dream, isn't it?
--
(c) 2005 Unscathed Haze via Central Plexus <[EMAIL PROTECTED]>
I am Chaos. I am alive, and I tell you that you are Free. -Eris
Big Brother is watching you. Learn to become Invisible.
| Your message must be this wide to ride the Internet. |
[1] Rigorous proof, that is. Anecdotal evidence does not establish
proof of anything whatsoever.
Re: Portmap non-local set / unset attempt
On 2005-09-23 00:05:14 -0700, Wolfgang S. Rupprecht wrote: > appreciable added risk. The only loose end is that sshd doesn't > currently log the RSA/DSA key that is used to gain access. Ideally it Hu? Try LogLevel VERBOSE Best Martin -- http://www.tm.oneiros.de
Re: Portmap non-local set / unset attempt
Tim Hammerquist <[EMAIL PROTECTED]> writes: > [*] I would consider leaving PermitRootLogin enabled a firing > offense in itself. PermitRootLogin is needed for rdisting. Without that you end up having to maintain N systems. /etc/ssh/sshd_config: Protocol 2 PermitRootLogin without-password PasswordAuthentication no ChallengeResponseAuthentication no X11Forwarding yes ClientAliveInterval 60 ClientAliveCountMax 30 If you only allow 2k RSA/DSA passwords you aren't exposing yourself to appreciable added risk. The only loose end is that sshd doesn't currently log the RSA/DSA key that is used to gain access. Ideally it would record the comment field from ~/ssh/authorized_keys into /var/log/authlog. That way, as long as everyone had their own key, you could always tell who logged in as root, same as the case of trampoline logins via a normal use account. -wolfgang -- Wolfgang S. Rupprechthttp://www.wsrcc.com/wolfgang/ Microsoft Vista - because "Virus Installer" was too long.
Re: Portmap non-local set / unset attempt
Quoting "Clint M. Sand" <[EMAIL PROTECTED]>: > On Thu, Sep 22, 2005 at 07:09:12PM -0600, Theo de Raadt wrote: > > > > People keep yammering this bullshit about "Security is a process". > > > > Bullshit! Lies! It's about paying attention to the frigging details > > > > when they are right in front of your face. And it is very clear other > > > > vendors do not pay attention to the details, considering the work I > > > > did here was talked about all over BUGTRAQ back in that month. No > > > > wonder these vendors and their blogboys have to have this "Security is > > > > a process" mantra to protect themselves from looking bad. > > > > > > > > > > > > > "Security is a process" is intended to mean 2 things. One is that the > > > idea that you can "set and forget" anything and think it's somehow > > > "secure" is a joke. To "secure" a network includes at a minimum, keeping > > > up with vendor patches for example. Processes like patch management help > > > keep systems secure. It does not say "Security is ONLY a process". > > > > > > Secondly, it is meant to refute the moronic idea that some admins seem > > > to have is that buying any product makes you "secure". Prevelant is the > > > idea for example that if you have a "firewall" then you are now "secure". > > > Or, "I have Norton AntiVirus so now my PC is secured". > > > > No, no no. > > > > You are playing the same semantic games that avoid responsibility at > > the ENGINEERING and PRODUCT DEVELOPMENT STAGES. > > > > It's so very very Microsoft. > > > > Just like the air-conditioning technicians I keep firing because they > > can't read schematics and charts. > > > > Which is why I now know MORE about air-conditioners than most of the > > technicians who come here. > > > > The phrase, and everything you said, is all excuses for the vendors. > > > > It IS POSSIBLE to set something up and have it be secure and NOT TOUCH > > IT, because many people have OpenBSD machines running older releases > > running without any modification for YEARS now, RISK FREE, without > > having to update ANY THING. > > No, you can put an openbsd box up and leave it for years with root login > enabled and password for a password. It takes more than correct code. > It's correct code plus correct usage. I think the GOBBLES sshd exploit > is proof enough that "set and forget" is not "risk free". > > Security is everything you've ever said, plus a process. > > If it is secure, it doesn't need a process. So why would security be a process again? Because of the vendors making "mistakes" and fix it later? Jimmy Scott This message has been sent through ihosting.be To report spamming or other unaccepted behavior by a iHosting customer, please send a message to [EMAIL PROTECTED]
Re: Portmap non-local set / unset attempt
Clint M. Sand wrote: > > > Theo de Raadt wrote: > > > > It's about paying attention to the frigging details when > > > > they are right in front of your face. [ snippage ] > > No, you can put an openbsd box up and leave it for years with > root login enabled and password for a password. It takes more > than correct code. It's correct code plus correct usage. Wouldn't setting a root password of "password" (aside from being grounds for immediate termination[*]) be a *prime* example of *ignoring* the "frigging details when they are right in front of your face"? [*] I would consider leaving PermitRootLogin enabled a firing offense in itself. Tim Hammerquist
RE: Re: Portmap non-local set / unset attempt
>Security is everything you've ever said, plus a >process. No. security does not require the process. Attempted security (that doesn't quite work) requires a process. Like the difference between does work and should work.
Re: Portmap non-local set / unset attempt
On Thu, Sep 22, 2005 at 07:09:12PM -0600, Theo de Raadt wrote: > > > People keep yammering this bullshit about "Security is a process". > > > Bullshit! Lies! It's about paying attention to the frigging details > > > when they are right in front of your face. And it is very clear other > > > vendors do not pay attention to the details, considering the work I > > > did here was talked about all over BUGTRAQ back in that month. No > > > wonder these vendors and their blogboys have to have this "Security is > > > a process" mantra to protect themselves from looking bad. > > > > > > > > > "Security is a process" is intended to mean 2 things. One is that the > > idea that you can "set and forget" anything and think it's somehow > > "secure" is a joke. To "secure" a network includes at a minimum, keeping > > up with vendor patches for example. Processes like patch management help > > keep systems secure. It does not say "Security is ONLY a process". > > > > Secondly, it is meant to refute the moronic idea that some admins seem > > to have is that buying any product makes you "secure". Prevelant is the > > idea for example that if you have a "firewall" then you are now "secure". > > Or, "I have Norton AntiVirus so now my PC is secured". > > No, no no. > > You are playing the same semantic games that avoid responsibility at > the ENGINEERING and PRODUCT DEVELOPMENT STAGES. > > It's so very very Microsoft. > > Just like the air-conditioning technicians I keep firing because they > can't read schematics and charts. > > Which is why I now know MORE about air-conditioners than most of the > technicians who come here. > > The phrase, and everything you said, is all excuses for the vendors. > > It IS POSSIBLE to set something up and have it be secure and NOT TOUCH > IT, because many people have OpenBSD machines running older releases > running without any modification for YEARS now, RISK FREE, without > having to update ANY THING. No, you can put an openbsd box up and leave it for years with root login enabled and password for a password. It takes more than correct code. It's correct code plus correct usage. I think the GOBBLES sshd exploit is proof enough that "set and forget" is not "risk free". Security is everything you've ever said, plus a process.
Re: Portmap non-local set / unset attempt
> Which is why I now know MORE about air-conditioners than most of the > technicians who come here. > > The phrase, and everything you said, is all excuses for the vendors. I bet that the air-conditoner technicians believe that "Air-conditioner maintainance is a process". Which is why they can never do a proper job. It is a cop-out when they say it, it is a cop-out when a unix vendor says it, and it is a copout whenever ANYONE SAYS IT.
Re: Portmap non-local set / unset attempt
> > People keep yammering this bullshit about "Security is a process". > > Bullshit! Lies! It's about paying attention to the frigging details > > when they are right in front of your face. And it is very clear other > > vendors do not pay attention to the details, considering the work I > > did here was talked about all over BUGTRAQ back in that month. No > > wonder these vendors and their blogboys have to have this "Security is > > a process" mantra to protect themselves from looking bad. > > > > > "Security is a process" is intended to mean 2 things. One is that the > idea that you can "set and forget" anything and think it's somehow > "secure" is a joke. To "secure" a network includes at a minimum, keeping > up with vendor patches for example. Processes like patch management help > keep systems secure. It does not say "Security is ONLY a process". > > Secondly, it is meant to refute the moronic idea that some admins seem > to have is that buying any product makes you "secure". Prevelant is the > idea for example that if you have a "firewall" then you are now "secure". > Or, "I have Norton AntiVirus so now my PC is secured". No, no no. You are playing the same semantic games that avoid responsibility at the ENGINEERING and PRODUCT DEVELOPMENT STAGES. It's so very very Microsoft. Just like the air-conditioning technicians I keep firing because they can't read schematics and charts. Which is why I now know MORE about air-conditioners than most of the technicians who come here. The phrase, and everything you said, is all excuses for the vendors. It IS POSSIBLE to set something up and have it be secure and NOT TOUCH IT, because many people have OpenBSD machines running older releases running without any modification for YEARS now, RISK FREE, without having to update ANY THING.
Re: Portmap non-local set / unset attempt
On Thu, Sep 22, 2005 at 02:02:13PM -0600, Theo de Raadt wrote: > People keep yammering this bullshit about "Security is a process". > Bullshit! Lies! It's about paying attention to the frigging details > when they are right in front of your face. And it is very clear other > vendors do not pay attention to the details, considering the work I > did here was talked about all over BUGTRAQ back in that month. No > wonder these vendors and their blogboys have to have this "Security is > a process" mantra to protect themselves from looking bad. > "Security is a process" is intended to mean 2 things. One is that the idea that you can "set and forget" anything and think it's somehow "secure" is a joke. To "secure" a network includes at a minimum, keeping up with vendor patches for example. Processes like patch management help keep systems secure. It does not say "Security is ONLY a process". Secondly, it is meant to refute the moronic idea that some admins seem to have is that buying any product makes you "secure". Prevelant is the idea for example that if you have a "firewall" then you are now "secure". Or, "I have Norton AntiVirus so now my PC is secured".
Re: Portmap non-local set / unset attempt
That's what I thought. I have no idea why Legato continues to use portmapper
at all. They've been telling me they're going to stop using it since at
least 1999.
I actually came up with a workaround that I think might expose a potential
issue in rpcinfo.
Since I couldn't get nsrexecd to automatically register with the portmapper,
I tried to register it manually using rpcinfo -s. An entry was added, but it
made the protocol number 2 instead of tcp (6), which is what I need.
# rpcinfo -s 390113 1 7937
# rpcinfo -p localhost
program vers proto port
102 tcp111 portmapper
102 udp111 portmapper
3901131 2 7937
# rpcinfo -t localhost 390113
rpcinfo: RPC: Program not registered
program 390113 is not available
I looked and couldn't find any way to set the protocol to TCP (6). Looking
at the source for rpcinfo, I found the following:
if ((pmap_set(prog_num, version_num, PF_INET,
(u_short)port_num)) == 0) {
fprintf(stderr, "rpcinfo: Could not set registration "
"for prog %s version %s port %s\n",
argv[0], argv[1], argv[2]);
exit(1);
}
Seems like rpcinfo will always set the protocol to the constant PF_INET,
which is actually AF_INET, which is actually 2.
In order to work around this, I created the following short program:
#include
main()
{
pmap_set(390113, 1, 6, 7937);
}
Notice the 6 in the 3rd argument to pmap_set, rather than the constant
PF_INET (2).
After deleting the previous portmapper entry and running my little kludge, I
get the following:
# rpcinfo -p localhost
program vers proto port
102 tcp111 portmapper
102 udp111 portmapper
3901131 tcp 7937
# rpcinfo -t localhost 390113
program 390113 version 1 ready and waiting
Which brings me to ask: Should an additional argument be added to rpcinfo -s
to specify a protocol, rather than forcing the constant PF_INET?
-Original Message-
From: Theo de Raadt [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 22, 2005 1:02 PM
To: Michael Favinsky
Cc: 'misc@openbsd.org'
Subject: Re: Portmap non-local set / unset attempt
> I'm receiving the following messages from portmap when starting Legato
> Networker's nsrexecd. The nsrexecd I'm running is the Linux version
> under
> emulation:
>
> portmap[16083]: non-local unset attempt (might be from 127.0.0.1)
> portmap[16083]: non-local set attempt (might be from 127.0.0.1)
>
> The program (number 390113) does not successfully register with the
> portmapper:
>
> # rpcinfo -p localhost
>program vers proto port
> 102 tcp111 portmapper
> 102 udp111 portmapper
>
> Is this a security "feature?"
Yes, most definately.
Changes made years ago slightly changed the communications API between
libc/rpc and the portmap daemon, to make it much harder to generate spoofed
RPC mappings. An attacker would make such mappings point one RPC service at
another RPC service, and with the right forwarding games you can get
mis-interpretation by an end point reulting in some risks.
Therefore our portmap sets up special 127.0.0.1 local bound sockets, and
only accepts set/unset operations on those sockets. The *:111 sockets can
still be used to make other requests, but not deal with binding
establishment.
The program you are using is linked against a RPC library that is using your
external address to change the mappings, ie. perhaps your external IP
address. That is the old legacy way that the Sun code used to do it, and it
was a bug, and it is full of risk.
It's astounding that other people have not fixed this yet, considering that
I did the work on that nearly 10 years ago.
revision 1.3
date: 1996/06/29 19:03:50; author: deraadt; state: Exp; lines: +135 -64
multiple receivers, port checking. testing help from bitblt
People keep yammering this bullshit about "Security is a process".
Bullshit! Lies! It's about paying attention to the frigging details when
they are right in front of your face. And it is very clear other vendors do
not pay attention to the details, considering the work I did here was talked
about all over BUGTRAQ back in that month. No wonder these vendors and
their blogboys have to have this "Security is a process" mantra to protect
themselves from looking bad.
> Is there a way to get nrsexecd to register with the portmapper?
You cannot get a Linux binary to talk to our portmap, without modifying our
portmap code to not have this security check. And that would be a shame.
Sorry...
This message may contain information that is privileged, confidential and
exempt from disclosure under applicable law. If you are not the intended
recipient of this message you may not store, disclo
Re: Portmap non-local set / unset attempt
> I'm receiving the following messages from portmap when starting Legato > Networker's nsrexecd. The nsrexecd I'm running is the Linux version under > emulation: > > portmap[16083]: non-local unset attempt (might be from 127.0.0.1) > portmap[16083]: non-local set attempt (might be from 127.0.0.1) > > The program (number 390113) does not successfully register with the > portmapper: > > # rpcinfo -p localhost >program vers proto port > 102 tcp111 portmapper > 102 udp111 portmapper > > Is this a security "feature?" Yes, most definately. Changes made years ago slightly changed the communications API between libc/rpc and the portmap daemon, to make it much harder to generate spoofed RPC mappings. An attacker would make such mappings point one RPC service at another RPC service, and with the right forwarding games you can get mis-interpretation by an end point reulting in some risks. Therefore our portmap sets up special 127.0.0.1 local bound sockets, and only accepts set/unset operations on those sockets. The *:111 sockets can still be used to make other requests, but not deal with binding establishment. The program you are using is linked against a RPC library that is using your external address to change the mappings, ie. perhaps your external IP address. That is the old legacy way that the Sun code used to do it, and it was a bug, and it is full of risk. It's astounding that other people have not fixed this yet, considering that I did the work on that nearly 10 years ago. revision 1.3 date: 1996/06/29 19:03:50; author: deraadt; state: Exp; lines: +135 -64 multiple receivers, port checking. testing help from bitblt People keep yammering this bullshit about "Security is a process". Bullshit! Lies! It's about paying attention to the frigging details when they are right in front of your face. And it is very clear other vendors do not pay attention to the details, considering the work I did here was talked about all over BUGTRAQ back in that month. No wonder these vendors and their blogboys have to have this "Security is a process" mantra to protect themselves from looking bad. > Is there a way to get nrsexecd to register > with the portmapper? You cannot get a Linux binary to talk to our portmap, without modifying our portmap code to not have this security check. And that would be a shame. Sorry...
Portmap non-local set / unset attempt
I'm receiving the following messages from portmap when starting Legato
Networker's nsrexecd. The nsrexecd I'm running is the Linux version under
emulation:
portmap[16083]: non-local unset attempt (might be from 127.0.0.1)
portmap[16083]: non-local set attempt (might be from 127.0.0.1)
The program (number 390113) does not successfully register with the
portmapper:
# rpcinfo -p localhost
program vers proto port
102 tcp111 portmapper
102 udp111 portmapper
Is this a security "feature?" Is there a way to get nrsexecd to register
with the portmapper?
Although it's probably not necessary, here's a dmesg from the server in
question:
OpenBSD 3.6 (GENERIC) #59: Fri Sep 17 12:32:57 MDT 2004
[EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium II ("GenuineIntel" 686-class, 512KB L2 cache) 267 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,MMX
real mem = 100245504 (97896K)
avail mem = 84336640 (82360K)
using 1249 buffers containing 5115904 bytes (4996K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(d4) BIOS, date 03/06/98, BIOS32 rev. 0 @ 0xfd7ad
apm0 at bios0: Power Management spec V1.2
apm0: AC on, battery charge unknown
pcibios0 at bios0: rev 2.1 @ 0xfd740/0x8c0
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdf50/160 (8 entries)
pcibios0: PCI Interrupt Router at 000:04:0 ("Intel 82371FB ISA" rev 0x00)
pcibios0: PCI bus #1 is the last bus
WARNING: can't reserve area for I/O APIC.
bios0: ROM list: 0xc/0x8000
cpu0 at mainbus0
pci0 at mainbus0 bus 0: configuration mode 1 (no bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443LX AGP" rev 0x03
ppb0 at pci0 dev 1 function 0 "Intel 82443LX AGP" rev 0x03
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "Cirrus Logic CL-GD5465" rev 0x03
wsdisplay0 at vga1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 4 function 0 "Intel 82371AB PIIX4 ISA" rev 0x01
pciide0 at pci0 dev 4 function 1 "Intel 82371AB IDE" rev 0x01: DMA, channel
0 wired to compatibility, channel 1 wired to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 16-sector PIO, LBA, 3079MB, 6306048 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
atapiscsi0 at pciide0 channel 1 drive 0
scsibus0 at atapiscsi0: 2 targets
cd0 at scsibus0 targ 0 lun 0: SCSI0 5/cdrom
removable
cd0(pciide0:1:0): using PIO mode 4, DMA mode 2
uhci0 at pci0 dev 4 function 2 "Intel 82371AB USB" rev 0x01: irq 11
usb0 at uhci0: USB revision 1.0
uhub0 at usb0
uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
uhub0: 2 ports with 2 removable, self powered
"Intel 82371AB Power Mgmt" rev 0x01 at pci0 dev 4 function 3 not configured
le1 at pci0 dev 6 function 0 "AMD 79c970 PCnet-PCI" rev 0x25: irq 5
le1: address 00:60:b0:f7:1d:a8
le1: 8 receive buffers, 2 transmit buffers
le2 at pci0 dev 10 function 0 "AMD 79c970 PCnet-PCI" rev 0x25: irq 10
le2: address 00:60:b0:cd:39:8f
le2: 8 receive buffers, 2 transmit buffers
le3 at pci0 dev 12 function 0 "AMD 79c970 PCnet-PCI" rev 0x25: irq 11
le3: address 00:60:b0:ee:fa:b3
le3: 8 receive buffers, 2 transmit buffers
isa0 at pcib0
isadma0 at isa0
pckbc0 at isa0 port 0x60/5
pckbd0 at pckbc0 (kbd slot)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pcppi0 at isa0 port 0x61
midi0 at pcppi0:
sysbeep0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom0: console
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
biomask fb4d netmask ff6d ttymask ffef
pctr: 686-class user-level performance counters enabled
mtrr: Pentium Pro MTRR support
dkcsum: wd0 matched BIOS disk 80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302
Thanks for the feedback/help.
I don't control the following disclaimer so no flaming please.
This message may contain information that is privileged, confidential and
exempt from disclosure under applicable law. If you are not the intended
recipient of this message you may not store, disclose, copy, forward,
distribute or use this message or its contents for any purpose. If you have
received this communication in error, please notify us immediately by return
e-mail and delete the original message and any attachments from your e-mail
system. Thank you.
