Re: kernel compile failure without -O option
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.2000 9:00 MET): > > cc -c -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include > -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 > -fomit-frame-pointer ../../i386/i386/atomic.c > In file included from ../../i386/i386/atomic.c:47: > machine/atomic.h: In function `atomic_set_char': > machine/atomic.h:106: inconsistent operand constraints in an `asm' > machine/atomic.h: In function `atomic_clear_char': > machine/atomic.h:107: inconsistent operand constraints in an `asm' [...] I have seen that same problem recently in a slightly different context. After staring at the code for a very long time, I could only conclude that the problem was a bug in gcc. John -- John Polstra [EMAIL PROTECTED] John D. Polstra & Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libexec/rtld-elf install broken?
* 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 not
> found").
>
> > but I'm sorry I did, -current is terribly broken. I now have two
> > machines in unusable state.
>
> Ugh. Sorry to hear that. Man, -current ain't what it used to be.
> But then it never was ... :-)
but.. but.. but... it _was_ working out so well ;(
-Alfred
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: libexec/rtld-elf install broken?
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 now have two
> machines in unusable state.
Ugh. Sorry to hear that. Man, -current ain't what it used to be.
But then it never was ... :-)
John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: dc driver and underruns (was: Strangeness with 4.0-S)
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 flaw in the chip. Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libexec/rtld-elf install broken?
* 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/libexec/ld-elf.so.1.old > > cp:No such file or directory > ^ > | > Why is the space missing that is supposed to be in this message? > > I added this to the Makefile 11 days ago, and haven't heard any > other reports of problems. > > > boggles! > > Yep, I'm baffled too. Have you got a rogue "cp" program somewhere > in your path? I needed to add 'cp' to src/Makefile.inc1, Marcel explained it to me but I'm sorry I did, -current is terribly broken. I now have two machines in unusable state. -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libexec/rtld-elf install broken?
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 is the space missing that is supposed to be in this message?
> # ls -l /usr/libexec/ld-elf.so.1 /usr/libexec/ld-elf.so.1.old
> -r-xr-xr-x 1 root wheel 74512 Jul 19 15:13 /usr/libexec/ld-elf.so.1
> -r-xr-xr-x 1 root wheel 74160 Jul 10 04:47 /usr/libexec/ld-elf.so.1.old
I can't figure out what is going on here. The whole set of commands
in the Makefile is inside an ".if exists" block:
beforeinstall:
.if exists(${DESTDIR}${BINDIR}/${PROG})
-chflags noschg ${DESTDIR}${BINDIR}/${PROG}
.if exists(${DESTDIR}${BINDIR}/${PROG}.old)
-chflags noschg ${DESTDIR}${BINDIR}/${PROG}.old
.endif
cp -p ${DESTDIR}${BINDIR}/${PROG} ${DESTDIR}${BINDIR}/${PROG}.old
.endif
I added this to the Makefile 11 days ago, and haven't heard any
other reports of problems.
> boggles!
Yep, I'm baffled too. Have you got a rogue "cp" program somewhere
in your path?
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: No /boot/loader
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 vindicates my position that we shouldn't have switched to this new kind of disk in the first place. As for geometry, I tried both with and without "dangerously dedicated." My understanding was that if I used the dos partition entry method that we should be able to pick up the geometry correctly, but should I try the old dos fdisk trick as well? Also, would the adaptec setting to translate >1G be affecting this? It's on currently, which it is on all my other motherboards of similar vintage. Finally, the other thing that's confusing me is that the error message mentions "lba," which I thought was strictly an IDE thing. Just for grins I tried toggling LBA and CHS mode in the bios, but no joy. > > Also, on a whim I decided to try running /boot/loader. I got a > > It's not a FreeBSD executable (obviously enough), so you can't do this. Yeah... it was born out of frustration, since nothing else was working anyway. I was kind of surprised that it did anything at all, to be honest. Thanks for your response, Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: No /boot/loader
> 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 can't do this. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cer/b7b/pfc -> pem
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. You need to export your private key (too). Without OE5, this is an option when you attempt to save a cert as a file. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
cvs commit: src/sys/dev/ppbus ppb_base.c (fwd)
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] USB project http://www.etla.net/~n_hibma/ -- Forwarded message -- Date: Tue, 18 Jul 2000 13:16:16 -0700 (PDT) From: Nick Hibma <[EMAIL PROTECTED]> To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: cvs commit: src/sys/dev/ppbus ppb_base.c n_hibma 2000/07/18 13:16:16 PDT Modified files: sys/dev/ppbusppb_base.c Log: Fix the detection of parallel port Zip drives. Submitted by: j mckitrick <[EMAIL PROTECTED]> Reviewed by: nsouchu Revision ChangesPath 1.11 +6 -5 src/sys/dev/ppbus/ppb_base.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: libexec/rtld-elf install broken?
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 as well. I didn't catch it because it will probably only copy ld-elf.so if an existing version is present (I tested with an empty DESTDIR). I'll fix it. -- Marcel Moolenaar mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] tel: (408) 447-4222 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
libexec/rtld-elf install broken?
===> 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. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 # ls -l /usr/libexec/ld-elf.so.1 /usr/libexec/ld-elf.so.1.old -r-xr-xr-x 1 root wheel 74512 Jul 19 15:13 /usr/libexec/ld-elf.so.1 -r-xr-xr-x 1 root wheel 74160 Jul 10 04:47 /usr/libexec/ld-elf.so.1.old boggles! -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Default Gateway problem.
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 show you if you want). Regards, Elias -- Elias Athanasopoulos | I bet the human brain is | H.E.P & Apps. Lab. http://www.uoa.gr/~eatha | a kludge. -Marvin Minsky | University Of Athens To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
> >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 > >know. > > Mark, this is one of the reasons why we need a way to measure the > quality of our entropy, please I understand 100%! That's why I'm doing it :-) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
> : 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 > : know. > > I don't know the answers to that either. > > Of course, if the attaker has root access to your machine, then you > have bigtime problems with keeping the random bits secret anyway... My scenario assumed that the attacker/user was not root. Of course if he is root, he knows a bit more, but even a non-root attacker can make a statistical study of the local clock and some hand-rolled ntp code. (I'm not suggesting it is easy, just possible :-) ) M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
> 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 up to the doing the job above. As soon as I've prettyfied it a bit, I'll give y'all some patches. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Default Gateway problem.
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 command below: > > [A] $ ifconfig add default 192.168.1.1 > Try 'route' instead of 'ifconfig' and you might have better luck. Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: trafshow doesn't work?
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 packet filter" I get the same message when running arpwatch which also uses bpf. It still works, though. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Default Gateway problem.
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 Internet connection is alive everything is ok. When no Internet connection exists I cannot make local telnets/ftps from FreeBSD to Linux, using hostnames instead of raw IP addresses. It seems that A (FreeBSD) tries to locate the nameservers specified in /etc/resolv.conf. My /etc/hosts: 192.168.1.1 B 192.168.1.2 A My /etc/host.conf: hosts bind Any hints? Regards, Elias -- Elias Athanasopoulos | I bet the human brain is | H.E.P & Apps. Lab. http://www.uoa.gr/~eatha | a kludge. -Marvin Minsky | University Of Athens To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: trafshow doesn't work?
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 has the same bug. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
trafshow doesn't work?
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, bpf1, bpf2, and bpf3 are in /dev. I don't know whatelse I should configure. Can someone help me? My OS is FreeBSD 5.0-CURRENT #21. Thanks! Sam To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: nic cards
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 is too hardware and implementation dependant. ifconfig -a ? Adrian -- Adrian ChaddNow 17-year-olds can't play a _video game_ <[EMAIL PROTECTED]>because its called violent - and real violence is still called dinner. -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make release?
[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 a 4.0 make release last night, that > worked just fine. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message Hmm, it built fine yesterday morning (July 18), but died this morning as follows: 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/usr/src/i386/usr/include -c /usr/src/lib/libpc ap/../../contrib/libpcap/nametoaddr.c -o nametoaddr.o /usr/src/lib/libpcap/../../contrib/libpcap/nametoaddr.c:370: conflicting types f or `ether_hostton' /usr/obj/usr/src/i386/usr/include/net/ethernet.h:111: previous declaration of `e ther_hostton' *** Error code 1 Stop in /usr/src/lib/libpcap. *** Error code 1 Stop in /usr/src/release. release started at 00:30:00 on 07/19/00 release died at 02:30:39 on 07/19/00 -- John Baldwin <[EMAIL PROTECTED]> To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
> 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 motherboards and > : CPU high enough to get thermal randomness? > > Yes. You'll also find that the voltage drifts as well. However, I > doubt you'd be able to get more than 1 bit out of the voltage > readings. The thermal readings, depending on their precision, would > also yield several random bits. But this several may be only 3 or 4. > The temperature varies based on work load and on the climate controls > in place at the site. I actually meant can you get real randomness, measuring the thermal noise in the on-chip temperature diode should be a good source of randomness. Except they are probably "kind" enough to fully filter it out. Peter -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
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 were applied, >> we'd find a fairly good source. > >The randomness is good, no doubt; I worry about how accessible that >randomness is to an attacker? > >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 >know. Mark, this is one of the reasons why we need a way to measure the quality of our entropy, please -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make release?
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 Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
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 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 : know. I don't know the answers to that either. Of course, if the attaker has root access to your machine, then you have bigtime problems with keeping the random bits secret anyway... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
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 : >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 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. Yes. That's the hard part. that's one area where my knowledge is somewhat weak. : BTW: You have *no* idea how much I envy your access to high quality : timing hardware :-) Well, there are hidden benefits working here that I never knew :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
[ 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 randomness is good, no doubt; I worry about how accessible that randomness is to an attacker? 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 know. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
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 nanosecond easily (giving about >5 bits of randomness) and with a lot of effort down to the pico second >level, which would give you about 15 bits of randomness. A geiger counter and a smoke-detector would be *so much* cheaper and give more bits per second :-) >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 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. BTW: You have *no* idea how much I envy your access to high quality timing hardware :-) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
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 motherboards and : CPU high enough to get thermal randomness? Yes. You'll also find that the voltage drifts as well. However, I doubt you'd be able to get more than 1 bit out of the voltage readings. The thermal readings, depending on their precision, would also yield several random bits. But this several may be only 3 or 4. The temperature varies based on work load and on the climate controls in place at the site. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fetch problem with fwtk
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] the latest fetch sends this: USER [EMAIL PROTECTED]@21 which fwtk apparently interprets as username "[EMAIL PROTECTED]" at IP address "0.0.0.21" What is incorrect here? Should FWTK understand this or is fetch wrong? dave -- Dave Cornejo @ Dogwood Media, Fremont, California To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
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 judge)? I can tell you right now that the variation between GPS and a good cesium clock is on the order of +- 25ns. With nanosecond resolution, this gives you about 5 bits. The variation of the system clock when synchronized to the GPS receiver is on the order of +-10us as measured with a parallel port interrupt and a pps line from the gps receiver. The pps interrupt is measured using a fast interrupt (we hacked ppc to do fast interrupts for this), so the latency is fairly small and fairly constant. I don't have datasets that I can point people at, however. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
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. : > : >With what amplitude? : : Depends on the termal environment of your xtal obviously :-) Poul, what's the Allen Variance for the sample that you measured? That's going to be the quality of the two oscillators under measure. Here we see correleations on the order of 10e-15, but that's for really good cesium clocks :-). For PC hardware, these differences are going to be effectively random. Why? The quartz xtals in them are usually really really bad. They drift all over the place with temprature, humidity and all kinds of other factors. Even tiny changes in temperature can be measured in the resulting frequency change of the OSC. Temperature near the xtal can vary quite a bit due to the vagaries of PC hardware. The drift of your clock is going to be effectively random. Sure, you know that what range it will be in, but from moment to moment, you don't know what the silly thing will do. I'm not sure how many random bits we can harvest from these measurements, but they are a good source of at least a few bits. All the data I've looked at is for high precision clocks or at least temp controlled xtals, which have much smaller variations. 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 nanosecond easily (giving about 5 bits of randomness) and with a lot of effort down to the pico second level, which would give you about 15 bits of randomness. When you are measuring the offset of two clocks that have been operating independently for a period of time, you'll find that the offset is effectively random. Since I think that ntp uses a one way time measurement, you will know the original time, the time on the remote, and maybe the approximate time that the packet returns. You can make low resolution estimates of the total delay and calculate an offset based on that. However, if the clocks are already close the delay almost always swamps the offset and your estimates of delay will be so far off that you'll not be able to estimate more than a few of the high order bits, if you are lucky. 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. Warner Losh Timing Solutions http://www.timing.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: possible NETGRAPH/NG_ETHER bug
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(*priv)); > FREE(priv, M_NETGRAPH); > node->private = NULL; > + ng_unname(node);/* remove node name */ > ng_unref(node); /* free node itself */ > } I think that is the right patch. Thanks! -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
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. Leif To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel compile failure without -O option
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-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I../../../include -D_KERNEL -include opt_global.h -elf -mpreferred-stack-boundary=2 -fomit-frame-pointer ../../i386/i386/atomic.c In file included from ../../i386/i386/atomic.c:47: machine/atomic.h: In function `atomic_set_char': machine/atomic.h:106: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_char': machine/atomic.h:107: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_add_char': machine/atomic.h:108: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_subtract_char': machine/atomic.h:109: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_set_short': machine/atomic.h:111: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_short': machine/atomic.h:112: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_add_short': machine/atomic.h:113: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_subtract_short': machine/atomic.h:114: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_set_int': machine/atomic.h:116: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_int': machine/atomic.h:117: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_add_int': machine/atomic.h:118: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_subtract_int': machine/atomic.h:119: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_set_long': machine/atomic.h:121: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_clear_long': machine/atomic.h:122: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_add_long': machine/atomic.h:123: inconsistent operand constraints in an `asm' machine/atomic.h: In function `atomic_subtract_long': machine/atomic.h:124: inconsistent operand constraints in an `asm' *** Error code 1 hellmuth -- Hellmuth MichaelisTel +49 40 55 97 47-70 HCS Hanseatischer Computerservice GmbHFax +49 40 55 97 47-77 Oldesloer Strasse 97-99 Mail hm [at] hcs.de D-22457 Hamburg WWW http://www.hcs.de To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
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 Better Way To Focus The Sun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: possible NETGRAPH/NG_ETHER bug
[...] > 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 > > > look at it, and, it seems to me that we are missing one reference > > > to a node. i think it is ng_name_node/ng_unname pair. > > > > This is quite possible because until recently interfaces could never > > be removed. Therefore the act of removing a node was really > > just a case of RESETTING the node. It was not removed. > > Here's some more info that may be helpful. [...] the problem still exists :( i tried to collect some information that, i think, could be helpful. first, my system fly# uname -a FreeBSD fly.private.org 5.0-CURRENT FreeBSD 5.0-CURRENT #2: Tue Jul 18 20:21:57 EST 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/FLY i386 now modules and interfaces fly# kldstat Id Refs AddressSize Name 13 0xc010 1cd99c kernel 21 0xc0974000 4000 logo_saver.ko fly# ifconfig -a lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff00 now i will load if_tap module and create virtual interface fly# kldload -v ./if_tap.ko Loaded ./if_tap.ko, id=3 fly# cat /dev/tap0 ^C fly# ifconfig -a lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff00 tap0: flags=8802 mtu 1500 ether 00:bd:dd:25:00:00 now i will load ng_ether and check NETGRAPH nodes fly# kldload -v ng_ether Loaded ng_ether, id=4 fly# ngctl list There are 2 total nodes: Name: ngctl183Type: socket ID: 0002 Num hooks: 0 Name: tap0Type: ether ID: 0001 Num hooks: 0 fly# ngctl types There are 2 total types: Type name Number of living nodes - -- socket 1 ether 1 so far so good :) now i will unload if_tap module fly# kldunload if_tap fly# ifconfig -a lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff00 fly# cat /dev/tap0 cat: /dev/tap0: Device not configured ok, both device and interface are gone, what about NETGRAPH nodes fly# ngctl list There are 1 total nodes: Name: ngctl210Type: socket ID: 0004 Num hooks: 0 fly# ngctl types There are 2 total types: Type name Number of living nodes - -- socket 1 ether 1 fly# kldunload ng_ether kldunload: can't unload file: Device busy ooops :( there is still 1 ``ether'' node :( i did put some debug printf in ng_base and ng_ether. here is an output ng_ether_detach: start node->refs = 2 --- ng_ether_detach() ng_unref: node->refs = 3 --- ng_unfer(). ng_rmnode() it will add one extra reference ng_ether_detach: before final ng_unref() node->refs = 2 --- ng_ether_detach() just before last ng_unref() ng_unref: node->refs = 2 --- ng_unref() so i think that shows that last ng_unref() was called with node->refs equal to 2, and, i think, that is not correct :( 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(*priv)); FREE(priv, M_NETGRAPH); node->private = NULL; + ng_unname(node);/* remove node name */ ng_unref(node); /* free node itself */ } if_tap module sources can be found at http://home.earthlink.net/~evmax/tap-fbsd5b1.tar.gz sorry for long letter :) hope that helps :) thanks, emax To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: randomdev entropy gathering is really weak
> 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 -- Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control, HD Associates, Inc. Fail-Safe systems, Agency approval To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
world broken in libpcap
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/usr/src/i386/usr/include -c /usr/src/lib/libpcap/../../contrib/libpcap/nametoaddr.c -o nametoaddr.o /usr/src/lib/libpcap/../../contrib/libpcap/nametoaddr.c:370: conflicting types for `ether_hostton' /usr/obj/usr/src/i386/usr/include/net/ethernet.h:111: previous declaration of `ether_hostton' *** Error code 1 Stop in /usr/src/lib/libpcap. -- Samuel Tardieu -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/sys/net ethernet.h
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/wlconfig/wlconfig.c1999/08/28 01:20:39 1.8 +++ usr.sbin/wlconfig/wlconfig.c2000/07/19 06:06:24 @@ -69,7 +69,6 @@ #include #include #include -extern struct ether_addr *ether_aton(char *a); #include #include In <[EMAIL PROTECTED]> Nickolay Dudorov <[EMAIL PROTECTED]> wrote: > There is one more 'buildworld' problem - in > 'src/usr.sbin/ipsend'. The (analogous) patch correct it: > > Index: contrib/ipfilter/iplang/iplang_y.y > === > RCS file: /store/CVS/src/contrib/ipfilter/iplang/iplang_y.y,v > retrieving revision 1.1.1.6 > diff -b -u -r1.1.1.6 iplang_y.y > --- contrib/ipfilter/iplang/iplang_y.y2000/05/24 02:14:18 1.1.1.6 > +++ contrib/ipfilter/iplang/iplang_y.y2000/07/19 04:59:38 > @@ -48,7 +48,7 @@ > #include "ipf.h" > #include "iplang.h" > > -#ifndef __NetBSD__ > +#if !defined(__NetBSD__) && ! defined(__FreeBSD__) > extern struct ether_addr *ether_aton __P((char *)); > #endif > >> In <[EMAIL PROTECTED]> Archie Cobbs <[EMAIL PROTECTED]> >wrote: >>> archie 2000/07/18 15:44:52 PDT >>> >>> Modified files: >>> sys/net ethernet.h >>> Log: >>> Const'ify parameters to ethers(3) routines as appropriate. >>> >>> Revision ChangesPath >>> 1.16 +6 -6 src/sys/net/ethernet.h >> >> This breaks 'buildworld' in the 'lib/libpcap'. >> >> The next patch seems to correct the error. >> >> N.Dudorov >> >> Index: contrib/libpcap/nametoaddr.c >> === >> RCS file: /store/CVS/src/contrib/libpcap/nametoaddr.c,v >> retrieving revision 1.6 >> diff -b -u -r1.6 nametoaddr.c >> --- contrib/libpcap/nametoaddr.c 2000/01/30 00:43:34 1.6 >> +++ contrib/libpcap/nametoaddr.c 2000/07/19 04:02:27 >> @@ -366,7 +366,7 @@ >> } >> #else >> >> -#if !defined(sgi) && !defined(__NetBSD__) >> +#if !defined(sgi) && !defined(__NetBSD__) && !defined(__FreeBSD__) >> extern int ether_hostton(char *, struct ether_addr *); >> #endif >> >> >> > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
