In article <[EMAIL PROTECTED]>,
Hellmuth Michaelis <[EMAIL PROTECTED]> wrote:
>
> In the process of tracing down the problem of the kernel panic when booting
> a kernel with pcvt enabled, i tried to compile a kernel without the -O
> option to gcc and got this compile failure (sources from 18.7.20
* John Polstra <[EMAIL PROTECTED]> [000719 18:32] wrote:
> Alfred Perlstein wrote:
> >
> > I needed to add 'cp' to src/Makefile.inc1, Marcel explained it to me
>
> Oh, so it was "cp" that wasn't found, I take it. We should change
> the message in make so it's more like what shells say ("command
Alfred Perlstein wrote:
>
> I needed to add 'cp' to src/Makefile.inc1, Marcel explained it to me
Oh, so it was "cp" that wasn't found, I take it. We should change
the message in make so it's more like what shells say ("command not
found").
> but I'm sorry I did, -current is terribly broken. I
On Fri, Jul 14, 2000 at 08:46:40AM +0200, Wilko Bulte wrote:
>That theory is not correct, I have seen multiple Alpha machines reporting
>buffer underruns as well. No ATA disk in sight there..
I get the same thing on AS4000/AS4100 machines running Tru64. I'm
inclined to believe it's a design fla
* John Polstra <[EMAIL PROTECTED]> [000719 17:45] wrote:
> In article <[EMAIL PROTECTED]>,
> Alfred Perlstein <[EMAIL PROTECTED]> wrote:
> > ===> libexec/rtld-elf
> > chflags noschg /usr/libexec/ld-elf.so.1
> > chflags noschg /usr/libexec/ld-elf.so.1.old
> > cp -p /usr/libexec/ld-elf.so.1 /usr/li
In article <[EMAIL PROTECTED]>,
Alfred Perlstein <[EMAIL PROTECTED]> wrote:
> ===> libexec/rtld-elf
> chflags noschg /usr/libexec/ld-elf.so.1
> chflags noschg /usr/libexec/ld-elf.so.1.old
> cp -p /usr/libexec/ld-elf.so.1 /usr/libexec/ld-elf.so.1.old
> cp:No such file or directory
^
|
Why
On Wed, 19 Jul 2000, Mike Smith wrote:
> > No response to this on -stable. The actual error message is:
> >
> > Disk error 0x1 (lba=0x7004c)
> > No /boot/loader
>
> Disk geometry stuffup, or a 'real' disk error.
Well, I put my money on real disk error, but only because it
vindicate
> No response to this on -stable. The actual error message is:
>
> Disk error 0x1 (lba=0x7004c)
> No /boot/loader
Disk geometry stuffup, or a 'real' disk error.
> Also, on a whim I decided to try running /boot/loader. I got a
It's not a FreeBSD executable (obviously enough), so you
On Tue, 18 Jul 2000, Leif Neland wrote:
> This works nicely in Windows (Outlook Express), but I'd like to try using
> the same key with openssl to generate crypted (to myself) or signed
> messages.
>
> I can export the key as a .cer, .p7b or .pfx, but openssl seems to want it
> in .pem format.
Could people try this out and see whether this solves any problems with
detection of Zip drives?
You might have to add flags=0x01 to ppc to use NIBBLE mode.
If enough people respond I'll try and get this into 4.1-RC.
Nick
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Alfred Perlstein wrote:
>
> ===> libexec/rtld-elf
> chflags noschg /usr/libexec/ld-elf.so.1
> chflags noschg /usr/libexec/ld-elf.so.1.old
> cp -p /usr/libexec/ld-elf.so.1 /usr/libexec/ld-elf.so.1.old
> cp:No such file or directory
> *** Error code 1
I think we need to copy 'cp' in installworld a
===> libexec/rtld-elf
chflags noschg /usr/libexec/ld-elf.so.1
chflags noschg /usr/libexec/ld-elf.so.1.old
cp -p /usr/libexec/ld-elf.so.1 /usr/libexec/ld-elf.so.1.old
cp:No such file or directory
*** Error code 1
Stop in /usr/src/libexec/rtld-elf.
*** Error code 1
Stop in /usr/src/libexec.
*** Er
On Wed, Jul 19, 2000 at 02:38:14PM -0700, Doug White wrote:
> > > [A] $ ifconfig add default 192.168.1.1
> >
> > Try 'route' instead of 'ifconfig' and you might have better luck.
Oops! Sorry, it was a typo. :-( The command I used is 'route'.
I have no problem with my routing table (which I can
> >If the attacker is on your computer (he us a user, say), he might know
> >a lot about the current frequency of your xtal. He can also get the same
> >(remote) time offsets as you. What does that give him? Not much, but it
> >could reduce the bits that he needs to guess. By how much? I don't
> >
> : If the attacker is on your computer (he us a user, say), he might know
> : a lot about the current frequency of your xtal. He can also get the same
> : (remote) time offsets as you. What does that give him? Not much, but it
> : could reduce the bits that he needs to guess. By how much? I don't
> The trick here is to actually measure the quality of our entropy.
> I have asked Markm to provide us with some kernel option which can
> be used to get a copy of the entropy so we can study the quality
> off it.
I have something that is _very_ crude, and definitely not
commitworthy, but it is u
On Thu, 20 Jul 2000, Elias Athanasopoulos wrote:
>
> Hi,
>
> I have the following network:
>
> A (FreeBSD-CURRENT) - ethernet - B (Linux) - ppp - Internet
> 192.168.1.2 192.168.1.1
>
> I have enabled IP Masq. in 'B' and set it as the default gateway
> for A, issuing the com
On Wed, 19 Jul 2000, Sam Xie wrote:
> Hi! There,
> My trafshow doesn't work. Whenever I tried to run trafshow, it gave me
> error message says, "trafshow: : Device not configured" I check my
>Kernel configuration file, a line
>"device bpf 4 #Berkeley pac
Hi,
I have the following network:
A (FreeBSD-CURRENT) - ethernet - B (Linux) - ppp - Internet
192.168.1.2 192.168.1.1
I have enabled IP Masq. in 'B' and set it as the default gateway
for A, issuing the command below:
[A] $ ifconfig add default 192.168.1.1
When the Intern
On Wed, 19 Jul 2000, Sam Xie wrote:
> Hi! There,
> My trafshow doesn't work. Whenever I tried to run trafshow, it gave me
> error message says, "trafshow: : Device not configured" I check my
>Kernel configuration file, a line
Fallout from the malloc.conf changes. tcpdump ha
Hi! There,
My trafshow doesn't work. Whenever I tried to run trafshow, it gave me
error message says, "trafshow: : Device not configured" I check my
Kernel configuration file, a line
"device bpf 4 #Berkeley packet filter"
is there and device drivers bpf0, bp
On Mon, Jul 17, 2000, Tony Johnson wrote:
> One thing that I just noticed on the python mailing list is a portable way
> of retrieving an ip addy. Why not start using eth0 (unfortunately as they
> do in Linuxland) eth1 ... For nic cards instead of fxp0 for an intel,
> etc...
>
> The fxp0 way
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Is it just me, or is make release broken?
>
> I've been getting a bomb-out whilst making the boot crunch (in /bin/sh, I
> think. Its at home, I'm not.) I haven't seen anybody kvetching (I *do* read
> current...) Just to sanity check, I ran
> In message <[EMAIL PROTECTED]> Peter Dufault writes:
> : > The reason why ntp is interesting is that we compare the received data
> : > with our unpredictable local clock. It is the result of this comparison
> : > which is good entropy bits.
> :
> : Is the resolution of thermal sensors on many
In message <[EMAIL PROTECTED]>, Mark Murray writes:
>[ A whole bunch of sane stuff removed ]
>
>> It certainly would be better than nothing and would be a decent source
>> of randomness. It would be my expectation that if tests were run to
>> measure this randomness and the crypto random tests w
Is it just me, or is make release broken?
I've been getting a bomb-out whilst making the boot crunch (in /bin/sh, I
think. Its at home, I'm not.) I haven't seen anybody kvetching (I *do* read
current...) Just to sanity check, I ran a 4.0 make release last night, that
worked just fine.
To Unsubs
In message <[EMAIL PROTECTED]> Mark Murray writes:
: The randomness is good, no doubt; I worry about how accessible that
: randomness is to an attacker?
That's a good thing to worry about.
: If the attacker is on your computer (he us a user, say), he might know
: a lot about the current frequenc
In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: A geiger counter and a smoke-detector would be *so much* cheaper
: and give more bits per second :-)
Agreed. And a lot less hassle. A *LOT* less hassle. :-)
: >It certainly would be better than nothing and would be a decent source
: >
[ A whole bunch of sane stuff removed ]
> It certainly would be better than nothing and would be a decent source
> of randomness. It would be my expectation that if tests were run to
> measure this randomness and the crypto random tests were applied,
> we'd find a fairly good source.
The rando
In message <[EMAIL PROTECTED]>, Warner Losh writes:
>Another good source would be if you had a Cesium clock and a GPS
>receiver. The delay due to atmospherics is another good source of
>random data. This varies +- 25ns and is highly locale dependent. One
>can measure this variance down to the
In message <[EMAIL PROTECTED]> Peter Dufault writes:
: > The reason why ntp is interesting is that we compare the received data
: > with our unpredictable local clock. It is the result of this comparison
: > which is good entropy bits.
:
: Is the resolution of thermal sensors on many new motherb
I am using fwtk-2.1 on a firewall, and with the latest builds, fetch
seems to have changed behaviors such that it no longer works with it.
I have FTP_PROXY set to "red:9696"
the difference in behavior seems that older versions of fetch would
send a USER command like this:
USER [EMAIL PROTECTED]
In message <[EMAIL PROTECTED]> Alexander Leidinger writes:
: systems which have a more or less precise clock attached (e.g. GPS or
: atomic clocks which sync the system clock via nptd)? And what are the
: numbers for this solution (for those people which are interested in
: numbers to be their own
In message <[EMAIL PROTECTED]> Poul-Henning Kamp writes:
: In message <[EMAIL PROTECTED]>, Mark Murray writes:
: >> No, he doesn't have access to the offset from the machines local clock.
: >>
: >> I ran a quick & dirty test here on some logfiles: that offset is
: >> very close to white noise.
:
Yevmenkin, Maksim N, CSCIO writes:
> again, here is one of the millions of possible patches that works for me :)
>
> *** ng_ether.c.old Tue Jul 18 21:17:54 2000
> --- ng_ether.c Tue Jul 18 21:48:46 2000
> ***
> *** 293,298
> --- 293,299
> bzero(priv, sizeof(*pr
On Wed, 19 Jul 2000, Steve O'Hara-Smith wrote:
>
> On 19-Jul-00 Peter Dufault wrote:
> > Is the resolution of thermal sensors on many new motherboards and
> > CPU high enough to get thermal randomness?
>
> The voltage sensors have some noise too (maybe not enough).
>
Fan speed too.
In the process of tracing down the problem of the kernel panic when booting
a kernel with pcvt enabled, i tried to compile a kernel without the -O
option to gcc and got this compile failure (sources from 18.7.2000 9:00 MET):
cc -c -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototype
On 19-Jul-00 Peter Dufault wrote:
> Is the resolution of thermal sensors on many new motherboards and
> CPU high enough to get thermal randomness?
The voltage sensors have some noise too (maybe not enough).
--
Steve O'Hara-Smith <[EMAIL PROTECTED]>
http://sohara.webhop.net/ A
[...]
> From: Archie Cobbs [mailto:[EMAIL PROTECTED]]
> Julian Elischer writes:
> > > i was working on integration of Ethernet TAP driver and NETGRAPH
> > > and found strange thing. the problem is that NG_ETHER nodes do not
> > > detach correctly when interface is gone. i was taking a very quick
> The reason why ntp is interesting is that we compare the received data
> with our unpredictable local clock. It is the result of this comparison
> which is good entropy bits.
Is the resolution of thermal sensors on many new motherboards and
CPU high enough to get thermal randomness?
Peter
--
cvsup'ed 1 hour ago
cc -O -pipe -I. -Dyylval=pcap_lval -DHAVE_SYS_IOCCOM_H=1 -DHAVE_SYS_SOCKIO_H=1
-DHAVE_ETHER_HOSTTON=1 -DHAVE_STRERROR=1 -DHAVE_SOCKADDR_SA_LEN=1 -DLBL_ALIGN=1
-DINET6 -I/usr/src/lib/libpcap/../../contrib/libpcap
-I/usr/src/lib/libpcap/../../contrib/libpcap/lbl -I/usr/obj/
And (the last) one more patch to make
'buildworld' successfull:
Index: usr.sbin/wlconfig/wlconfig.c
===
RCS file: /store/CVS/src/usr.sbin/wlconfig/wlconfig.c,v
retrieving revision 1.8
diff -b -u -r1.8 wlconfig.c
--- usr.sbin
42 matches
Mail list logo
