Re: ftp vs. nfs install times

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], John Hay write
s:
 
I've tested last nights make release built
 install via both ftp and nfs and am seeing
 some rather strange results timeing wise:
 
A full install (ie: select ALL) w/ ports.
 
NFS:  about 18 minutes. (ave. about 1000KB/sec)
 
FTP:  about 70 minutes. (ave. about 45KB/sec)
 

Maybe just as a datapoint. My -current snap building machine is running
a kernel of Oct 24 and I noticed this morning that it is taking a very
long time to scp the snap to internat.

Try disabling newreno in both ends:

sysctl -w net.inet.tcp.newreno=0

On my laptop with Wavelan cards this increases TCP throughput by a
factor of 5.


--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | 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: XFree86 3.3.6_3 build dies on -current

[Marcel Moolenaar]

Patrick Gardella wrote:
 
 In file included from /usr/include/sys/wait.h:93,
  from vgaHW.c:44:
 /usr/include/machine/endian.h:72: syntax error before
 `__uint16_swap_unit32'
 /usr/include/machine/endian.h:72: syntax error before `__x'
 snip
 

The following 2 patches solve the problem when building XFree86-3.3.6
with only the VGA16 and SVGA servers. Building other servers may still
be broken.

The patches are relative to .../XFree86/work

FYI,

-- 
Marcel Moolenaar
  mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
  tel:  (408) 447-4222

--- xc/programs/Xserver/hw/xfree86/vga16/vga/vgaHW.c~   Wed Oct 25 23:08:19 2000
+++ xc/programs/Xserver/hw/xfree86/vga16/vga/vgaHW.cWed Oct 25 23:05:33 2000
@@ -38,7 +38,7 @@
 #include sys/wait.h
 #undef _POSIX_SOURCE
 #else
-#if defined(MINIX) || defined(AMOEBA) || (defined(ISC)  defined(_POSIX_SOURCE)) || 
defined(Lynx)
+#if defined(MINIX) || defined(AMOEBA) || (defined(ISC)  defined(_POSIX_SOURCE)) || 
+defined(Lynx) || defined(__FreeBSD__)
 #include sys/types.h
 #endif
 #include sys/wait.h


--- xc/programs/Xserver/hw/xfree86/vga256/drivers/tdfx/vb_vgahw.c~  Wed Oct 25 
23:11:33 2000
+++ xc/programs/Xserver/hw/xfree86/vga256/drivers/tdfx/vb_vgahw.c   Wed Oct 25 
+23:12:10 2000
@@ -40,7 +40,7 @@
 #include sys/wait.h
 #undef _POSIX_SOURCE
 #else
-#if defined(MINIX) || defined(AMOEBA) || (defined(ISC)  defined(_POSIX_SOURCE)) || 
defined(Lynx)
+#if defined(MINIX) || defined(AMOEBA) || (defined(ISC)  defined(_POSIX_SOURCE)) || 
+defined(Lynx) || defined(__FreeBSD__)
 #include sys/types.h
 #endif
 #include sys/wait.h

Re: ftp vs. nfs install times

[John Hay]

  
 I've tested last nights make release built
  install via both ftp and nfs and am seeing
  some rather strange results timeing wise:
  
 A full install (ie: select ALL) w/ ports.
  
 NFS:  about 18 minutes. (ave. about 1000KB/sec)
  
 FTP:  about 70 minutes. (ave. about 45KB/sec)
  
 
 Maybe just as a datapoint. My -current snap building machine is running
 a kernel of Oct 24 and I noticed this morning that it is taking a very
 long time to scp the snap to internat.
 
 Try disabling newreno in both ends:
 
   sysctl -w net.inet.tcp.newreno=0
 
 On my laptop with Wavelan cards this increases TCP throughput by a
 factor of 5.

Yes, that makes a HUGE difference. I only did it on the current box.
Internat is still running 4.x and don't have it. I think it made more
than a factor of 5 difference here. :-)

John
-- 
John Hay -- [EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

FREE! Get A Great Price On A New Car! (1ea77451)

[fast_ride2001]

Get A Great Price On A New Car!

Absolutely Free!

Want to save time and money? 

Want to have quick access to car quotes?

Want to have all makes and models available to you?

If you answered yes to any of these, then take advantage of this free, no-hassle 
service. Simply click on the link below to get low prices on all makes and models of 
new and used cars, without having to negotiate with a dealer. It’s painless and 
stress-free!



CLICK-HERE--  http://3627528622/  --CLICK-HERE

** 
If you wish to unsubscribe from this list, simply
go to http://3627528622/remove.html and follow
the instructions. You will be removed immediately.
PLEASE NOTE: replying to this message will not 
remove you, you MUST follow the link above. 
Thank you.
** 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: strange problem of PPPoE + NAT

[Terry Lambert]

  the other problem i had after switch that system to -current
  is that after a random time, the connection will frzzed.
  the routing table still exist, connection is still up.
  just cant connect to anywhere outside the network. no error
  or anything been loged in ppp.log.
 
 Interestingly enough, I've been having the same problem with PPPoE ever since
 it hit the tree 'bout a year ago. It happens infrequently enough that I tend
 to blame my provider, rather than ppp.
 
 When it happens, killing ppp and restarting it is usually enough. 

Drop Julian or Archie a line; Julian wrote the code for netgraph
for PPPoE, and Archie modified it most recently.

BTW: I believe PPPoE in both Julian and Archie's cases specifically
uses the netgraph PPP implementation, so it's an "all in the
kernel" approach; the problem may be your use of user space code
(i.e. killable code, since you can't kill it in the kernel, only
unlink or unload it).


Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ftp vs. nfs install times

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], John Hay write
s:

 Try disabling newreno in both ends:
 
  sysctl -w net.inet.tcp.newreno=0
 
 On my laptop with Wavelan cards this increases TCP throughput by a
 factor of 5.

Yes, that makes a HUGE difference. I only did it on the current box.
Internat is still running 4.x and don't have it. I think it made more
than a factor of 5 difference here. :-)

I sent packet traces to yan some time back, but have not heard from him
since.  I wonder if we should disable newrene for now...

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | 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: entropy reseeding is totally broken

[Ed Hall]

In real life, machines don't always get rebooted in a completely
controlled fashion (panic, power failure, etc.).  Anything that
makes a reboot longer or less reliable is a definite non-starter.

I can guarantee you, if the current /dev/random code isn't fixed before
it makes STABLE, folks running servers 24/7 are going to rip it right
out.

-Ed




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[David O'Brien]

On Wed, Oct 25, 2000 at 09:28:31PM -0700, Doug Barton wrote:
 
   How exactly are you rebooting? If you're using the 'reboot' command,

That is my standard rebooting method.  ``reboot'' really has to be
tolerated and something useful happen (ie, the next booting up doesn't
hang (or delay for a long time) waiting for entropy, etc)

-- 
-- David  ([EMAIL PROTECTED])
  GNU is Not Unix / Linux Is Not UniX


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: XFree86 3.3.6_3 build dies on -current

[Satoshi - Ports Wraith - Asami]

 * From: Marcel Moolenaar [EMAIL PROTECTED]

 * The following 2 patches solve the problem when building XFree86-3.3.6
 * with only the VGA16 and SVGA servers. Building other servers may still
 * be broken.

Yikes.  The same problem is killing (at least) all the emacsen too.

  http://bento.FreeBSD.org/errorlogs/errorlogs/e.5.20001025/

===
## grep -l 'syntax error before `__uint16_swap' *.log
a2ps-a4-4.13.log
a2ps-letter-4.13.log
bladeenc-0.92.log
cook-2.15.log
emacs-19.34b.log
emacs-20.7.log
expect-5.32.1.log
gnats-3.113.log
mswordview-0.5.14.6.log
mule-common-2.3.log
sdl_mixer-1.0.6.log
timidity++-2.10.1.log
===

and we are only 1/4 through the 5-current package build.

Do we really have to change things like this? :

Satoshi


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: sysinstall's console keymap menu

[Jose M. Alcaide]

Jordan Hubbard wrote:
 
  Jordan, what do you think about making the keymap selection the first
  step of the "Standard" installation?
 
 Most people don't need to set it, and the Standard install is all
 about trying to take the "most general" path.  If I'm wildly wrong
 about this anywhere but Spain, I'm certainly willing to revisit the
 decision. :)
 

H... There are many countries/languages which use keyboards with
different layouts. This affects the location of some important signs
such as "/". It's very annoying for a new FreeBSD user typing "/"
while getting "" in the disklabel screen, for example.

Cheers,
-- JMA
** Jose M. Alcaide  //  [EMAIL PROTECTED]  //  [EMAIL PROTECTED] **
** "Beware of Programmers who carry screwdrivers" --  Leonard Brandwein **


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

On Wed, Oct 25, 2000 at 05:01:44PM -0700, Mark Murray wrote:
 I need logs.

What logs you expect? It is just standard -current rc.* files.

 What is "did not work"?

The same fortune quote again.

 What is "it worked"?

Different fortune quote.

 What was the line you commented out?

His situation apparently the same as mine. If entropy file is NOT used "it
worked" just because amount of data for seeding (junk from /var/run) is
bigger than 16384 bytes.

I suggest to try my rc.shutdown 16384 workaround too.

-- 
Andrey A. Chernov
http://ache.pp.ru/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Kris Kennaway]

On Wed, Oct 25, 2000 at 10:35:55AM +, Terry Lambert wrote:
  I see the opposite.  I see that without writing to the /dev/random
  device I get a cons is an object that cares fortune 99+% of the time
  on my first login.  With it, I see more decently random fortunes (but
  I haven't done a statistical analysis of them to see how random things 
  are).
 
 Is it just me, or have there been more problems achieving
 real statistical randomness since /dev/random went in, than
 at any other time in BSD history?
 
 I booted a 1.5 system a couple of times for grins.
 
 It gives you a different fortune each time.

The issue is one of seeding the device strongly. If all you care about
is getting a different fortune when you boot then seeding with
e.g. the system boot time would be enough, but obviously it doesnt
make /dev/random cryptographically secure.

Kris


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Kris Kennaway]

On Wed, Oct 25, 2000 at 02:50:29PM +0400, Andrej Cernov wrote:

 It is because /dev/random totally ignore _time_ and not reseed from it,
 but no other randomness source available at boot time. 

We should probably be using the time since boot as ONE thing we seed
with, but it only provides maybe 3-4 bits of randomness - meaning if
thats all you seed with then your attacker has to brute-force 3-4 bits
of state to break the PRNG state as it was at boot time, hardly a
difficult challenge :-)

Kris


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

On Thu, Oct 26, 2000 at 12:48:19PM +0400, áÎÄÒÅÊ þÅÒÎÏ× wrote:
 On Wed, Oct 25, 2000 at 05:01:44PM -0700, Mark Murray wrote:
  I need logs.
 
 What logs you expect? It is just standard -current rc.* files.

Here they are, in anycase, set -x as you requested (entropy-related lines
only):

+ [ -w /dev/random ]
+ [ -f /var/db/entropy -a -r /var/db/entropy -a -s /var/db/entropy ]
+ echo Using /var/db/entropy as an entropy file
+ cat /var/db/entropy
+ entropy_reseeded=yes
+ rm -f /var/db/entropy /var/db/entropy


-- 
Andrey A. Chernov
http://ache.pp.ru/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

On Thu, Oct 26, 2000 at 02:21:22AM -0700, Kris Kennaway wrote:
 On Wed, Oct 25, 2000 at 02:50:29PM +0400, Andrej Cernov wrote:
 
  It is because /dev/random totally ignore _time_ and not reseed from it,
  but no other randomness source available at boot time. 
 
 We should probably be using the time since boot as ONE thing we seed
 with, but it only provides maybe 3-4 bits of randomness - meaning if
 thats all you seed with then your attacker has to brute-force 3-4 bits
 of state to break the PRNG state as it was at boot time, hardly a
 difficult challenge :-)

This issue not about cryptographically strong randomness but about
/dev/random seeding totally not worked, even 3-4 bits of time not used
across the boot. Guessing 0 bits for your attacker is much easy then 3-4
bits :-)

-- 
Andrey A. Chernov
http://ache.pp.ru/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Rod Taylor]

Doug Barton wrote:
 
 Wesley Morgan wrote:
 
  I'm not knocking anyone or any code, especially considering this IS
  -current... BUT... I don't need to read the code to know that I am seeing
  the same fortunes on first login after reboot more often than I can
  attribute to random chance. Maybe nanotime is being harvested, but it
  seems that there is a time lag between system startup and reaching a state
  of "true pseudo-entropy". Also, every reboot has entropy caching failing
  to work. I don't know if this is a product of the broken reseeding or
  what, because the /etc/rc files seem to be fine.
 
 How exactly are you rebooting? If you're using the 'reboot' command,
 that explains why entropy reseeding is not working. As has been
 discussed several times on -current, you only run rc.shutdown if you use
 another method, like 'shutdown -r now', 'init 6', or even the trust
 three-finger salute.

How about when I hit the reset button?  That case SHOULD be taken care
of too!  Would it not be possible to sample /dev/random to store the
entropy every hour or so that the system runs?  Atleast that way you
would be guarenteed to have something.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

On Wed, Oct 25, 2000 at 07:50:28PM -0400, Wesley Morgan wrote:
 Now, the problem I am seeing is that not only do I get the same fortunes
 between reboots, but it is _always_ the same one:
 
 "Be ALERT (the world needs more lerts"

BTW, my always-the-same fortune is different:

"Adore, v.: To venerate expectantly."

(I don't think it helps much, the bug is definitely in the kernel random
module, not in rc files or fortune)

--
Andrey A. Chernov
http://ache.pp.ru/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: XFree86 3.3.6_3 build dies on -current

[Bruce Evans]

On 26 Oct 2000, Satoshi - Ports Wraith - Asami wrote:

  * From: Marcel Moolenaar [EMAIL PROTECTED]
 
  * The following 2 patches solve the problem when building XFree86-3.3.6
  * with only the VGA16 and SVGA servers. Building other servers may still
  * be broken.
 
 Yikes.  The same problem is killing (at least) all the emacsen too.
 
   http://bento.FreeBSD.org/errorlogs/errorlogs/e.5.20001025/
 
 ===
 ## grep -l 'syntax error before `__uint16_swap' *.log
 a2ps-a4-4.13.log
 a2ps-letter-4.13.log
 bladeenc-0.92.log
 cook-2.15.log
 emacs-19.34b.log
 emacs-20.7.log
 expect-5.32.1.log
 gnats-3.113.log
 mswordview-0.5.14.6.log
 mule-common-2.3.log
 sdl_mixer-1.0.6.log
 timidity++-2.10.1.log
 ===
 
 and we are only 1/4 through the 5-current package build.
 
 Do we really have to change things like this? :

No.  It is a bug in machine/endian.h, although strictly, all the
above applications are broken because sys/types.h is a documented
prerequisite of sys/wait.h (if they include the undocumented header
machine/endian.h then they are even more broken).  sys/wait.h just
happened to not actually have this prerequisite.

Bruce



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Jordan Hubbard]

 The issue is one of seeding the device strongly. If all you care about
 is getting a different fortune when you boot then seeding with
 e.g. the system boot time would be enough, but obviously it doesnt
 make /dev/random cryptographically secure.

I think there's a more general point being made here - if we're
not seeding /dev/random effectively at startup, fortune is the
least of our worries since all the other startup services will
be unrandom as well.

This situation I see with /dev/random is kind of disturbing since I
think we're running the danger of falling into the following
all-too-common scenario in engineering:

1) Person X falls in love with a new algorithm or technique and
   implements it in a fairly key service with quite a few rough
   edges.

2) The users fail to embrace this new technology all that fervently
   since those same rough edges make it a promising but annoying or
   downright non-functional implementation.

3) Person X vigorously defends himself and/or the algorithm since
   he knows it's really a much better thing in the long run and
   simply needs "tweaking" to make it fully work.

4) The users see this as an attempt to cram broken bits down their
   throats and just as vigorously fight back against what they see
   as someone's fancy solution in search of a problem to solve.

5) Constructive dialog breaks down and it all turns into an exchange
   of increasingly irritated words as each side feels the other isn't
   hearing what it's trying to say or appreciating the bigger pictures.

Let's try not to go there with /dev/random, please. :)

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[John W. De Boskey]

Jordan writes a nice piece of mail... 

If this was happening in -stable I'd be in total agreement.
However, we're talking -current, and is not -current the
integration area for new technologies, whether they be
rough or round edged?

This reminds me of the old development arguement:

   Don't do that, it hurts me.

which has caused alot of good code to never see the
light of day.

-John

- Jordan Hubbard's Original Message -
  The issue is one of seeding the device strongly. If all you care about
  is getting a different fortune when you boot then seeding with
  e.g. the system boot time would be enough, but obviously it doesnt
  make /dev/random cryptographically secure.
 
 I think there's a more general point being made here - if we're
 not seeding /dev/random effectively at startup, fortune is the
 least of our worries since all the other startup services will
 be unrandom as well.
 
 This situation I see with /dev/random is kind of disturbing since I
 think we're running the danger of falling into the following
 all-too-common scenario in engineering:
 
 1) Person X falls in love with a new algorithm or technique and
implements it in a fairly key service with quite a few rough
edges.
 
 2) The users fail to embrace this new technology all that fervently
since those same rough edges make it a promising but annoying or
downright non-functional implementation.
 
 3) Person X vigorously defends himself and/or the algorithm since
he knows it's really a much better thing in the long run and
simply needs "tweaking" to make it fully work.
 
 4) The users see this as an attempt to cram broken bits down their
throats and just as vigorously fight back against what they see
as someone's fancy solution in search of a problem to solve.
 
 5) Constructive dialog breaks down and it all turns into an exchange
of increasingly irritated words as each side feels the other isn't
hearing what it's trying to say or appreciating the bigger pictures.
 
 Let's try not to go there with /dev/random, please. :)
 
 - Jordan
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: strange problem of PPPoE + NAT

[Josh Tiefenbach]

 BTW: I believe PPPoE in both Julian and Archie's cases specifically
 uses the netgraph PPP implementation, so it's an "all in the
 kernel" approach; the problem may be your use of user space code
 (i.e. killable code, since you can't kill it in the kernel, only
 unlink or unload it).

Actually, I dont believe so. At least, ppp(8) merely uses the PPPoE netgraph
node, and does all PPP processing in user space, AFAICT.

If, however, you're referring to mpd, then yes, that uses the netgraph PPP
implementation.

   Terry Lambert

josh

-- 
"Watching those 2 guys [Bush and Gore] debate is like watching Ben Stein read
'The Story of O'" -- Dennis Miller


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Bug in ip_fw.c?

[Harti Brandt]

Hi,

I stumbled over an interesting problem: the current kernel's NFS client
code blocks when reading files of size 2828 byte over NFSv3 (see
kern/22309). Today I tracked the problem down. It appears, that an IP
packet cannot be reassembled, when the last fragment of it is from 1 to 7
bytes long.

For some reason I have IP_FIREWALL and IP_FIREWALL_DEFAULT_TO_ACCEPT in my
kernel config (well, the reason is, that I wanted to play with
'sting'). Although there is a comment in ip_fw.c that it is not a problem,
when an incoming packet is a fragment with off!=0, it appears to be a
problem, if the packet is too short to contain a UDP header. ip_fw insists
on having an UDP header (around line 1002) and drops the packet as a bogus
fragment, if it is too short for a header. I think, this is wrong.

Because I'm not too firm with the firewall code, I have no fix.

Regards,
harti
-- 
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
  [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ftp vs. nfs install times

[Andrew Gallatin]

Poul-Henning Kamp writes:
  In message [EMAIL PROTECTED], John Hay write
  s:
  
   Try disabling newreno in both ends:
   
 sysctl -w net.inet.tcp.newreno=0
   
   On my laptop with Wavelan cards this increases TCP throughput by a
   factor of 5.
  
  Yes, that makes a HUGE difference. I only did it on the current box.
  Internat is still running 4.x and don't have it. I think it made more
  than a factor of 5 difference here. :-)
  
  I sent packet traces to yan some time back, but have not heard from him
  since.  I wonder if we should disable newrene for now...

That would be a shame.  

It makes a huge difference when shovling bits across my DSL line to my
-stable laptop.  Running netperf from a -current alpha with newreno, I
consistantly see 650-700Kb/s.  From a -stable i386 without newreno, I
see variable results from 300-500Kb/sec with large stutters, so to
speak, where there is no traffic at all for one second (or at least I
don't see any packets in systat -tcp 1).  

I hope this problem can be fixed -- I was actually hoping that newreno
could be MFC'ed.

Drew

--
Andrew Gallatin, Sr Systems Programmer  http://www.cs.duke.edu/~gallatin
Duke University Email: [EMAIL PROTECTED]
Department of Computer Science  Phone: (919) 660-6590




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

fsck in -current

[Dmitry Valdov]

Hello!

fsck tries to run fsck_msdos for MSDOS partition, but there is no
fsck_msdos in -current.


Also fsck(8) says:
SEE ALSO
 mount(8),  fstab(5),  fsck_msdos(8),  fsck_ffs(8)

...
 man fsck_msdos
No manual entry for fsck_msdos


Dmitry.





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Bug in ip_fw.c?

[Ruslan Ermilov]

[redirected to freebsd-ipfw]

Certainly, there is a bug.
Please test with attached patch.

On Thu, Oct 26, 2000 at 04:01:07PM +0200, Harti Brandt wrote:
 
 Hi,
 
 I stumbled over an interesting problem: the current kernel's NFS client
 code blocks when reading files of size 2828 byte over NFSv3 (see
 kern/22309). Today I tracked the problem down. It appears, that an IP
 packet cannot be reassembled, when the last fragment of it is from 1 to 7
 bytes long.
 
 For some reason I have IP_FIREWALL and IP_FIREWALL_DEFAULT_TO_ACCEPT in my
 kernel config (well, the reason is, that I wanted to play with
 'sting'). Although there is a comment in ip_fw.c that it is not a problem,
 when an incoming packet is a fragment with off!=0, it appears to be a
 problem, if the packet is too short to contain a UDP header. ip_fw insists
 on having an UDP header (around line 1002) and drops the packet as a bogus
 fragment, if it is too short for a header. I think, this is wrong.
 
 Because I'm not too firm with the firewall code, I have no fix.
 

-- 
Ruslan Ermilov  Oracle Developer/DBA,
[EMAIL PROTECTED]   Sunbay Software AG,
[EMAIL PROTECTED]  FreeBSD committer,
+380.652.512.251Simferopol, Ukraine

http://www.FreeBSD.org  The Power To Serve
http://www.oracle.com   Enabling The Information Age


Index: ip_fw.c
===
RCS file: /home/ncvs/src/sys/netinet/ip_fw.c,v
retrieving revision 1.146
diff -u -p -w -r1.146 ip_fw.c
--- ip_fw.c 2000/10/26 00:16:12 1.146
+++ ip_fw.c 2000/10/26 15:57:53
@@ -970,21 +970,20 @@ ip_fw_chk(struct ip **pip, int hlen,
goto bogusfrag; \
ip = mtod(*m, struct ip *); \
*pip = ip;  \
-   offset = (ip-ip_off  IP_OFFMASK); \
}   \
} while (0)
 
/*
 * Collect parameters into local variables for faster matching.
 */
+   proto = ip-ip_p;
+   src_ip = ip-ip_src;
+   dst_ip = ip-ip_dst;
offset = (ip-ip_off  IP_OFFMASK);
-   {
+   if (offset == 0) {
struct tcphdr *tcp;
struct udphdr *udp;
 
-   dst_ip = ip-ip_dst ;
-   src_ip = ip-ip_src ;
-   proto = ip-ip_p ;
/*
 * warning - if offset != 0, port values are bogus.
 * Not a problem for ipfw, but could be for dummynet.
@@ -1014,6 +1013,7 @@ ip_fw_chk(struct ip **pip, int hlen,
default :
break;
}
+   }
 #undef PULLUP_TO
last_pkt.src_ip = ntohl(src_ip.s_addr) ;
last_pkt.dst_ip = ntohl(dst_ip.s_addr) ;
@@ -1021,7 +1021,6 @@ ip_fw_chk(struct ip **pip, int hlen,
last_pkt.src_port = ntohs(src_port) ;
last_pkt.dst_port = ntohs(dst_port) ;
last_pkt.flags = flags ;
-   }
 
if (*flow_id) {
/* Accept if passed first test */

Re: fsck in -current

[Johan Karlsson]

At Thu, 26 Oct 2000 19:23:27 +0400, Dmitry Valdov wrote:
 Hello!
 
 fsck tries to run fsck_msdos for MSDOS partition, but there is no
 fsck_msdos in -current.
 
 
 Also fsck(8) says:
 SEE ALSO
  mount(8),  fstab(5),  fsck_msdos(8),  fsck_ffs(8)
 
 ...
  man fsck_msdos
 No manual entry for fsck_msdos
 
 
 Dmitry.

Hi

Adrian sent this HEADS UP to current a while ago:
==
Date: Fri, 13 Oct 2000 17:17:37 +0200
From: Adrian Chadd [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: HEADS UP: fsck wrappers gotcha


As pointed out by mr Sobolev, the fsck wrappers will blindly try to execute
fsck_$FS regardless of whether its there or not, and fail if it isn't.
This is a gotcha for non-fsck'able fses right now, such as nfs and ntfs.

The solution, which I forgot to add in my email, is to set pass to 0. This
forces fsck to NOT consider the FS for fsck-on-boot, and should make things
quieter.

Note that swap / procfs in /etc/fstab already use dump/pass = 0, but this is
just to make sure.

Just FYI,


Adrian
===


/Johan K


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Problem in fetch

[Andrea Campi]

When trying to install ports, very often I find everything freezes just
after fetch completes. If I hit ^C and type "make install" again, the
tarball is there, that's why I say that fetch is already done.
If I hit ^T, I see fetch sitting in sbwait, the time not increasing.

Any idea?

--
You can have it soon, cheap and working. Choose *two*, not three!

Andrea Campi
Network Administrator
World Online S.rl.
V. Montecuccoli, 20 - 20132 Milano, Italy

Tel. +39 02 483293.1
Fax. +39 02 483293.601
--


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: fsck in -current

[Andrea Campi]

joke
ln -sf /bin/true /sbin/fsck_msdos
/joke

Sorry, today I'm quite exausted... ;-)

 -Original Message-
 From: Dmitry Valdov [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, October 26, 2000 5:23 PM
 To: [EMAIL PROTECTED]
 Subject: fsck in -current
 
 
 Hello!
 
 fsck tries to run fsck_msdos for MSDOS partition, but there is no
 fsck_msdos in -current.
 
 
 Also fsck(8) says:
 SEE ALSO
  mount(8),  fstab(5),  fsck_msdos(8),  fsck_ffs(8)
 
 ...
  man fsck_msdos
 No manual entry for fsck_msdos
 
 
 Dmitry.
 
 
 
 
 
 To Unsubscribe: send mail to [EMAIL PROTECTED]
 with "unsubscribe freebsd-current" in the body of the message
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: smp instability

[Patrick Hartling]

Patrick Hartling [EMAIL PROTECTED] wrote:

} John Baldwin [EMAIL PROTECTED] wrote:
} 
} } 
} } On 25-Oct-00 Chuck Robey wrote:
} }  I'm having rather extreme problems with stability on my dual PIII
} }  setup.  I know this is to be expected, but it's gotten so extreme on my
} }  system, I can't spend more than a few minutes before it locks up.
} }  
} }  Is there any chance that I could make things better by using a sysctl to
} }  tell the box it's now a single-cpu system?  I can't read man pages at the
} }  moment (I'm composing this on my Sparc Ultra-5) so if this might work, an
*** d
} }  someone knows the exact command to use, I'd appreciate a bit of help.
} } 
} } You can use kernel.old to compile a UP kernel.  I always keep a UP kernel
} } around just in case.  Also, when did your SMP box become unstable?  There
} } was a known problem with SMP boxes when the vm page zero'ing during the idl
*** e
} } loop was first turned on that has since been fixed with the latest commit t
*** o
} } vm_machdep.c yesterday.  Symptoms were frequent kernel panic 12's with
} } interrupts disabled .
} 
} I am having the same lockup problems as Chuck with SMP kernels built since
} October 21.  The system completely locks up after a short period of time.
} If I'm running X, it does it within 10-15 minutes, but if I don't run X
} and just leave it at the console, it can go for a few hours.  It does
} eventually lock up, though.  I haven't tried building a UP kernel, but I
} will try the latest vm_machdep.c changes.  If that doesn't work, I'll go
} the UP route since I'm tired of being unable to list my processes.  :\

To follow up on this, I rebuilt everything using sources from
approximately 11:00 am CDT yesterday (10/26), and everything is great
again.  Hooray!

 -Patrick


Patrick L. Hartling | Research Assistant, VRAC
[EMAIL PROTECTED] | 2624 Howe Hall -- (515)294-4916
http://www.137.org/patrick/ | http://www.vrac.iastate.edu/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Matt Dillon]

:In real life, machines don't always get rebooted in a completely
:controlled fashion (panic, power failure, etc.).  Anything that
:makes a reboot longer or less reliable is a definite non-starter.
:
:I can guarantee you, if the current /dev/random code isn't fixed before
:it makes STABLE, folks running servers 24/7 are going to rip it right
:out.
:
:   -Ed

I don't understand why /dev/random has to be reseeded with so many
bytes in the first place... 64 or 128 bytes ought to do it, and if they
don't then there is something fundamentally wrong with /dev/random
that needs to be addressed.  The proper way to address is NOT to try
to push a larger seed into it.  Hell, a *4* byte reseeding should
generate sufficient randomness for our purposes (though obviously it is
not cryptographically secure enough).

I am certainly not willing to wait more then 500ms on boot for /dev/random
to seed, and I doubt very many other people would be either.

In regards to 'reboot' verses 'shutdown' ... the solution here is
simple:  don't try to save the random seed from the shutdown script.  I
would argue that the very *LAST* thing you want to do when shutting a
machine down is start writing out files.  And, frankly, depending on
people using 'shutdown' is silly since most people run their machines
either until they drop, or use 'reboot' rather then 'shutdown'.

The solution is to deal with entropy at boot time, and also regenerate
the file from /etc/periodic/daily.

At boot time you do this:

* load the entropy file (128 bytes is plenty!)
* fold in the current time (including microseconds)
* fold in the "/" directory's mtime
* fold in some junk from /var/log and dmesg.
* save the entropy file
* done.

From /etc/periodic/daily you do this:

* generate a random number
* store it as the entropy file (128 bytes is plenty!)

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: Problem in fetch

[Andrea Campi]

Sorry to follow up on myself... I forgot to mention this is -CURRENT,
updated to a couple of days ago...

 -Original Message-
 From: Andrea Campi 
 Sent: Thursday, October 26, 2000 6:44 PM
 To: '[EMAIL PROTECTED]'
 Subject: Problem in fetch
 
 
 When trying to install ports, very often I find everything 
 freezes just after fetch completes. If I hit ^C and type 
 "make install" again, the tarball is there, that's why I say 
 that fetch is already done.
 If I hit ^T, I see fetch sitting in sbwait, the time not increasing.
 
 Any idea?
 
 --
 You can have it soon, cheap and working. Choose *two*, not three!
 
 Andrea Campi
 Network Administrator
 World Online S.rl.
 V. Montecuccoli, 20 - 20132 Milano, Italy
 
 Tel. +39 02 483293.1
 Fax. +39 02 483293.601
 --
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Mark Murray]

  What logs you expect? It is just standard -current rc.* files.
 
 Here they are, in anycase, set -x as you requested (entropy-related lines
 only):
 
 + [ -w /dev/random ]
 + [ -f /var/db/entropy -a -r /var/db/entropy -a -s /var/db/entropy ]
 + echo Using /var/db/entropy as an entropy file
 + cat /var/db/entropy
 + entropy_reseeded=yes
 + rm -f /var/db/entropy /var/db/entropy

This is what I needed to see!

Next; please see if you can capture a few /var/db/entropy files. You'll
need to cp(1) them in /etc/rc - DON'T drop to single-user.

Please see if you can get about 5 of them. DON'T mail them to me, put
them somewhere where I can ftp of http them.

Thanks!

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: entropy reseeding is totally broken

[Mark Murray]

  What logs you expect? It is just standard -current rc.* files.
 
 Here they are, in anycase, set -x as you requested (entropy-related lines
 only):
 
 + [ -w /dev/random ]
 + [ -f /var/db/entropy -a -r /var/db/entropy -a -s /var/db/entropy ]
 + echo Using /var/db/entropy as an entropy file
 + cat /var/db/entropy
 + entropy_reseeded=yes
 + rm -f /var/db/entropy /var/db/entropy

Could you please build the random.ko module with -DDEBUG and let me know
at what stage the first reseed event happens?

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: XFree86 3.3.6_3 build dies on -current

[Marcel Moolenaar]

Satoshi - Ports Wraith - Asami wrote:
 
  * From: Marcel Moolenaar [EMAIL PROTECTED]
 
  * The following 2 patches solve the problem when building XFree86-3.3.6
  * with only the VGA16 and SVGA servers. Building other servers may still
  * be broken.
 
 Yikes.  The same problem is killing (at least) all the emacsen too.

The modula-3-socks port as well (I happen to know that because I need to
install cvsup with socks support :-)

 and we are only 1/4 through the 5-current package build.
 
 Do we really have to change things like this? :

Eventually yes, but not this way. According to Bruce sys/types is a
prerequisite for sys/wait. Technically speaking, that makes the ports
broken, but the "brokenness" of the ports was caused by FreeBSD not
really enforcing this. If we do make sys/types a prerequisite for
sys/wait, then we need to give porters the time to change their code and
thus need to make sure it still works, albeit with warnings.

So far I haven't seen any direct inclusion of sys/endian.h. It seems
that not including sys/types before sys/wait is by far the most common
case (ie 3 out of 3 :-)

-- 
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

Re: pccard_ether wouldn't kill dhclient when card is removed

[Motomichi Matsuzaki]

Please, please commit this.

At Wed, 25 Oct 2000 01:31:57 +0900,
Motomichi Matsuzaki [EMAIL PROTECTED] wrote:
 patch for revision 1.20:
 
 --- /etc/pccard_ether Thu Oct 19 16:24:35 2000
 +++ pccard_ether  Wed Oct 25 01:27:05 2000
 @@ -46,7 +46,7 @@
  
  interface=$1
  shift
 -startstop=$2
 +startstop=$1
  shift
  
  case ${startstop} in
 @@ -101,7 +101,7 @@
   ;;
  # Stop the interface
  *)
 - /sbin/ifconfig $device delete
 + /sbin/ifconfig ${interface} delete
   stop_dhcp
   ;;
  esac

-- 
Motomichi Matsuzaki [EMAIL PROTECTED] 
Dept. of Biological Sciences, Grad. School of Science, Univ. of Tokyo, Japan 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[John Baldwin]

On 26-Oct-00 Rod Taylor wrote:
 Doug Barton wrote:
 
 Wesley Morgan wrote:
 
  I'm not knocking anyone or any code, especially considering this IS
  -current... BUT... I don't need to read the code to know that I am seeing
  the same fortunes on first login after reboot more often than I can
  attribute to random chance. Maybe nanotime is being harvested, but it
  seems that there is a time lag between system startup and reaching a state
  of "true pseudo-entropy". Also, every reboot has entropy caching failing
  to work. I don't know if this is a product of the broken reseeding or
  what, because the /etc/rc files seem to be fine.
 
 How exactly are you rebooting? If you're using the 'reboot' command,
 that explains why entropy reseeding is not working. As has been
 discussed several times on -current, you only run rc.shutdown if you use
 another method, like 'shutdown -r now', 'init 6', or even the trust
 three-finger salute.
 
 How about when I hit the reset button?  That case SHOULD be taken care
 of too!  Would it not be possible to sample /dev/random to store the
 entropy every hour or so that the system runs?  Atleast that way you
 would be guarenteed to have something.

And if a malicious user on your machine grabs the saved entropy file
and then reboots your machine using some exploit of some sort?  Granted
neither of these tasks may be easy, and it could be done in such a way
that the first requires root access.

-- 

John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

buildkernel error

[Igor Timkin]

check outed 1 hour ago.
=== ipfilter
cc -O -pipe -DIPFILTER=1 -DIPFILTER_LKM -DIPFILTER_LOG  -D_KERNEL -Wall 
-Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes 
-Wpointer-arith -Winline -Wcast-qual  -fformat-extensions -ansi -DKLD_MODULE -nostdinc 
-I-  -I. -I@ -I@/../include  -mpreferred-stack-boundary=2 -c 
/usr/src/sys/modules/ipfilter/../../netinet/mlfk_ipl.c
In file included from /usr/src/sys/modules/ipfilter/../../netinet/mlfk_ipl.c:44:
@/netinet/ip_compat.h:268: osreldate.h: No such file or directory
*** Error code 1

Stop in /usr/src/sys/modules/ipfilter.
*** Error code 1

Stop in /usr/src/sys/modules.
*** Error code 1

Stop in /usr/src/sys/compile/MAIL.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

On Thu, Oct 26, 2000 at 09:56:00AM -0700, Matt Dillon wrote:
 simple:  don't try to save the random seed from the shutdown script.  I
 would argue that the very *LAST* thing you want to do when shutting a
 machine down is start writing out files.  And, frankly, depending on

I agree. Cron job to build entropy is much lesser evil than writting any
files at reboot stage.

-- 
Andrey A. Chernov
http://ache.pp.ru/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: new rc.network6 and rc.firewall6

[Nik Clayton]

On Tue, Oct 24, 2000 at 02:56:07PM -0700, Jordan Hubbard wrote:
 [redirected to just -current; I'm not sure what this has to do with -net]
 
  I agree.  I've been using them for a while on my dog slow Windows CE
  machine.  There were some minor issues when they were first committed
  to NetBSD on some platforms (due to a too early use of ps and some
  brokeness in ps on pmax, for example), but these were quickly
  resolved.
 
 So, who wants to do a proof-of-concept implementation for -current
 which integrates with our existing rc.conf mechanism?  In order to
 obey POLA, we should at least have the separate scripts switch off the
 same knobs whenever possible.

As far as I'm aware, Neil Blakey-Milner is doing just that (I'm surprised
he hasn't said so himself, although I think this week/fortnight's quite
hectic for him in the real world).

N


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: strange problem of PPPoE + NAT

[Terry Lambert]

  BTW: I believe PPPoE in both Julian and Archie's cases specifically
  uses the netgraph PPP implementation, so it's an "all in the
  kernel" approach; the problem may be your use of user space code
  (i.e. killable code, since you can't kill it in the kernel, only
  unlink or unload it).
 
 Actually, I dont believe so. At least, ppp(8) merely uses the PPPoE netgraph
 node, and does all PPP processing in user space, AFAICT.
 
 If, however, you're referring to mpd, then yes, that uses the netgraph PPP
 implementation.

Yes, mpd.  Both Archie and Julian were running pure netgraph
systems with different PPPoE cable modem provider configurations;
I can't vouch for Archie's configuration, but I'm positive that
Julian had it going, since he was using it at his apartment in SFO
before he went back to OZ.


Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: new rc.network6 and rc.firewall6

[Warner Losh]

In message [EMAIL PROTECTED] Nik Clayton writes:
: On Tue, Oct 24, 2000 at 02:56:07PM -0700, Jordan Hubbard wrote:
:  [redirected to just -current; I'm not sure what this has to do with -net]
:  
:   I agree.  I've been using them for a while on my dog slow Windows CE
:   machine.  There were some minor issues when they were first committed
:   to NetBSD on some platforms (due to a too early use of ps and some
:   brokeness in ps on pmax, for example), but these were quickly
:   resolved.
:  
:  So, who wants to do a proof-of-concept implementation for -current
:  which integrates with our existing rc.conf mechanism?  In order to
:  obey POLA, we should at least have the separate scripts switch off the
:  same knobs whenever possible.
: 
: As far as I'm aware, Neil Blakey-Milner is doing just that (I'm surprised
: he hasn't said so himself, although I think this week/fortnight's quite
: hectic for him in the real world).

I'm looking forward to it.  NetBSD does have an rc.conf already and
they have recently moved to the two teir /etc/defaults/rc.conf and
/etc/rc.conf after much gnashing of teeth and beating of breasts...  I
suspect that if we move to their rc files, a similar gnashing of
teeth and beating of breasts will be played out in the mailing
lists. :-)

Warner
 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Terry Lambert]

  It is because /dev/random totally ignore _time_ and not reseed from it,
  but no other randomness source available at boot time. 
 
 We should probably be using the time since boot as ONE thing we seed
 with, but it only provides maybe 3-4 bits of randomness - meaning if
 thats all you seed with then your attacker has to brute-force 3-4 bits
 of state to break the PRNG state as it was at boot time, hardly a
 difficult challenge :-)

The actual time would probably be more useful than the time since
boot.

I still have a problem with what I see as a fundamental weakness
in storing "randomness" across reboots.

Logically, given a sufficiently large amount of time between a
crash and the subsequent reboot, one could predict the random
state, and attack immediately after a reboot... just like one
could guess the fortune now, following a reboot.

The state save in the shutdown -- besides not working unless you
hopping on one leg, pat your head, and rub your tummy while
singinging "Danny Boy" (or the moral equivalent of not being
allowed to crash or use the "halt" or "reboot" commands) -- seems
to me to be an inherent security flaw.

Matt's points about compromise, number of random bits, as well
as the amount of time it's OK to take, are also salient.

Bottom line: any algorithm predicated only on saved state and
based on predictable progression over a large period of time in
which a compromise may be effected, is a problem.


Jordan's points are good ones as well.

I think that if /dev/random can be shown to be a solid foundation,
it could be a keystone in an overall security strategy that can
then be used to build large, sturdy, secure, edifices.

But _unless_ it's shown to be a solid foundation, using it as a
keystone is going to turn everything else into a house of cards,
where if you compromise /dev/random, then you have a skeleton
key to everything.  I'm not too worried about people seeing
fortunes before their time... they could always look at the
fortunes.dat file anyway.  But the implication in randomness
used elsewhere in the system is nowhere so obvious when it is
broken as when getting the same fortune each time you boot.


Perhaps it's time to draft a "big gun"?  Someone who knows
enough about number theory to know that multiplying two
random numbers together results in less randomness, not more?

Or perhaps it's time to use a "tried but true" algorithm,
like the 48 bit linear congruential algorithm, with a polynomial
preterbation based on the current time at the time of reseeding,
until the random ducks get (not) in a row?  Pseudorandom seeding
with a hidden key has got to be better than anything that opens
a computation window for as long as your system is down after a
crash... after all, we _are_ talking about security through
obscurity (of the next number in a pseudorandom sequence), here.

Nothing wrong with finding a handy giant, and standing on its
shoulders... it's a time honored scientific tradition.

I'm not really volunteering here, since I'm just an applied
mathematician, and only ever got off on theory as it applied
to real problems in physics and computer science and elsewhere.
I just know enough to know that it'd be dangerous to trust me to
do the job 100% correctly.  8-).  But I also see this as getting
more important as /dev/random gets more and more central to
security and authentication policy and enforcement.


Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: new rc.network6 and rc.firewall6

[Gerhard Sittig]

On Wed, Oct 25, 2000 at 15:17 -0500, Mike Meyer wrote:
 Gerhard Sittig writes:
  What's new is:
  - include the general config at the start (and yes, in every
single script -- but this should be neglectable in terms of
speed penalty and makes them work separately, too -- which is a
real big gain!)
 
 This isn't really new; it's been nagging me for a while. Also,
 periodic.conf does this now.  I'm not convined it's negligible when
 added up over dozens of scripts.  I'm planning on taking some
 measurements to see how much this really costs. I believe I have a
 solution if it turns out to be non-negligible.

The "negligible" (you finally got what I meant :) comes IMO from
considering how often this would happen.  I really dont mind at
all if booting would take 10 more seconds or shutdown would do.
An hourly cronjob eating two more seconds (under heavy load) is
no problem at all.  And I feel these time ranges to be estimated
in a very generous way and expect them to be much lower in real
life.  I really would be surprised to be totally wrong in this
respect.  We're talking about "source"ing config and subroutine
files -- the shell text is shared and the script code (file data)
already in the cache, we just create a new process and allocate
data (copy on write helps here) and stack.

  - maybe include (source) some common code like
- determining pids belonging to program names
- starting processes in an supervised or backgrounded or any
  other special way
- have some printouts, error level summary, etc
  but I don't see FreeBSD having this level of "rc lib" as NetBSD
  has in rc.subr or even RedHat has in /etc/rc.d/functions(sp?).
  So only the sourced rc.conf (default and customized) remains.
 
 Said solutions works shell functions as well.

When you're really afraid of speed you can always do what's
usually done with C header files:

[ -z "$SOURCED_FLAG" ]  . $SOURCE_FILE

When clearing the SOURCED_FLAG variable at boot's / shutdown's
end you aren't very confused later and who fiddles with those
variables at the command line by hand gets what he deserves. :

 [ ... lib function and service script skeleton snipped ... ]


virtually yours   82D1 9B9C 01DC 4FB4 D7B4  61BE 3F49 4F77 72DE DA76
Gerhard Sittig   true | mail -s "get gpg key" [EMAIL PROTECTED]
-- 
 If you don't understand or are scared by any of the above
 ask your parents or an adult to help you.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Mark Murray]

 The actual time would probably be more useful than the time since
 boot.

Heck - I can use both. Its cheap enough.

 I still have a problem with what I see as a fundamental weakness
 in storing "randomness" across reboots.

Schneier recommends this in his Yarrow paper.

 Logically, given a sufficiently large amount of time between a
 crash and the subsequent reboot, one could predict the random
 state, and attack immediately after a reboot... just like one
 could guess the fortune now, following a reboot.

Sure. If you followed the complete thread, you'll see we are
trying to deal with this.

 The state save in the shutdown -- besides not working unless you
 hopping on one leg, pat your head, and rub your tummy while
 singinging "Danny Boy" (or the moral equivalent of not being
 allowed to crash or use the "halt" or "reboot" commands) -- seems
 to me to be an inherent security flaw.

Not really. To exploit it, you need to be either root or have the
console. It would be easier to get the state out of /dev/kmem at
that stage. We covered this _months_ ago.

 Matt's points about compromise, number of random bits, as well
 as the amount of time it's OK to take, are also salient.
 
 Bottom line: any algorithm predicated only on saved state and
 based on predictable progression over a large period of time in
 which a compromise may be effected, is a problem.

The relevance to Yarrow is...?

And your solution is.?

 Perhaps it's time to draft a "big gun"?  Someone who knows
 enough about number theory to know that multiplying two
 random numbers together results in less randomness, not more?

Bruce Schneier good enough?

 Or perhaps it's time to use a "tried but true" algorithm,
 like the 48 bit linear congruential algorithm, with a polynomial
 preterbation based on the current time at the time of reseeding,
 until the random ducks get (not) in a row?  Pseudorandom seeding
 with a hidden key has got to be better than anything that opens
 a computation window for as long as your system is down after a
 crash... after all, we _are_ talking about security through
 obscurity (of the next number in a pseudorandom sequence), here.

Yarrow not good enough for you? Why not? What cryptanalysis of
it are you aware of that leads to a compromise?

Where is your rebuttal of Schneier's "Attacking PRNG's" paper?

 Nothing wrong with finding a handy giant, and standing on its
 shoulders... it's a time honored scientific tradition.

And I didn't do this how?

 I'm not really volunteering here, since I'm just an applied
 mathematician, and only ever got off on theory as it applied
 to real problems in physics and computer science and elsewhere.
 I just know enough to know that it'd be dangerous to trust me to
 do the job 100% correctly.  8-).  But I also see this as getting
 more important as /dev/random gets more and more central to
 security and authentication policy and enforcement.

Isn't theory wonderful?

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: entropy reseeding is totally broken

[Doug Barton]

On Thu, 26 Oct 2000, John Baldwin wrote:

  How about when I hit the reset button?  That case SHOULD be taken care
  of too!  Would it not be possible to sample /dev/random to store the
  entropy every hour or so that the system runs?  Atleast that way you
  would be guarenteed to have something.
 
 And if a malicious user on your machine grabs the saved entropy file
 and then reboots your machine using some exploit of some sort?  Granted
 neither of these tasks may be easy, and it could be done in such a way
 that the first requires root access.

I stated this same objection until I actually attended Mark's
presentation at the 'con. The yarrow algorithm uses an encrypted hash for
the entropy on the way in, and encrypts the output on the way out. This
would make it extremely difficult to guess the state at reboot, even if we
weren't picking up new entropy sources during the boot process. 

Pending Mark's approval, I'd like to suggest we add a cron job to
dump X k of data from /dev/random to a file (/boot/.periodic_entropy
maybe?) and use that, AND ${entropy_file:/var/db/entropy} to reseed at
boot, and only do the "long, annoying" failover process if neither file
exists. The only remaining questions would be how many k of data to dump
how often.

Doug
-- 
"The dead cannot be seduced."
- Kai, "Lexx"

Do YOU Yahoo!?





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Problem in fetch

[Jeroen Ruigrok van der Werven]

[Making sure Dag-Erling gets the mail]

-On [20001026 18:45], Andrea Campi ([EMAIL PROTECTED]) wrote:
When trying to install ports, very often I find everything freezes just
after fetch completes. If I hit ^C and type "make install" again, the
tarball is there, that's why I say that fetch is already done.
If I hit ^T, I see fetch sitting in sbwait, the time not increasing.

Just a note, I got the same thing under 4-STABLE with the latest
sources.

You can run fetch with more verbosity.  See what that does.

I'll get a debug/verbose dump for you tomorrow DES.

-- 
Jeroen Ruigrok van der Werven  Network- and systemadministrator
[EMAIL PROTECTED]VIA Net.Works The Netherlands
BSD: Technical excellence at its best  http://www.via-net-works.nl
There is such a thing as a man being too proud to fight...


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

$B$O$8$a$^$7$F!#(B

[$B%^%D%P%i(B]

$B$O$8$a$^$7$F!#(B$BFMA3$N%a!=%k!"<:NiCW$7$^$9!#(B

$B;d$N%a!<%k%\%C%/%9$K!"#1#0%v7n0LA0$+$i(B$B!V#4#0#0#01_$r?6$j9~$`$H!"<+J,$N8}:B$K!"$*6b$,?6$j9~$^$l$k$h$&$K$J$k!W(B$B$H$$$C$?35N,$N%M%C%H%2!<%`$NM6$$$,FO$/$h$&$K$J$C$FMh$^$7$?!#(B

$B$3$N$h$&$J%a!<%k$K$O6=L#$,L5$+$C$?$N$G!"Ev=i$OL5;k$7$FB(%4%_H"9T$-$K$7$F$$$^$7$?!#(B$B$3$N5=$N$h$&$J46$8$b$7$^$7$?$7!#(B$B$7$+$7!"$3$N%2!<%`$,#1#0%v7n$bB3$$$F$$$k;v$K!">/$76=L#$r;}$D$h$&$K$J$C$F$-$^$7$?!#(B$B!V#1#0%v7n$bB3$$$F$$$k$N$J$i0cK!@-$OL5$5$=$&$@$J!A!W$d!V:#!"N.9T$C$F$$$k$N$+$J!A!)!W(B$B$J$I$H;W$$!"FO$$$?%a!<%k$r!"$h!<$/FI$s$G8+$k$H!"#1HV>e$N?M$OH4$1$F9T$/$N$G!"(B$B3N$+$K0cK!@-$OL5$/!"LLGr$=$&$K;W$($^$7$?!#(B$B$=$N>e!"$&$^$/=PMh$F$$$k%7%9%F%`$@$H46?4$7$^$7$?!#(B$B!J%a!<%k$N:G8e$NJ}$KK!E*$J;v9`$r5-:\$7$F$$$^$9!#!K(B

$B$=$3$G!";d$b;22C$9$k$3$H$K7h$a!">/$7A0$+$i3hF0$7$F$$$^$9!#(B$B$9$k$H!"#1=54VDx$G$*6b$,?6$j9~$^$l$F$/$k$h$&$K$J$C$?$N$G$9!#(B$B@5D>!"6C$-$^$7$?!#(B

$B:#$^$G!"KhG/%8%c%s%\Ju$/$8$rGc$C$F$$$F$b!":G9b$G#3#0#0#01_$7$+Ev$?$C$?;v$,L5$$$N$K!*(B$B$3$l$O!"Ju$/$8$h$j3NN)$O@dBP$K9b$$$H;W$$$^$9!#(B

$B0J2<$K!":#$^$GD:$$$?%a!<%k$NCf$+$iJ8LL$r(B3$B$DH4?h$7$F7G:\$5$;$FD:$-$^$9!#(B$B;29M$K$J$k$H;W$$$^$9$N$G!"$h$1$l$P#1EY!"L\$rDL$7$FD:$1$l$P9,$$$G$9!#(B

$B$J$*!"$3$N$h$&$J%a!<%k$,I,MW$GL5$+$C$?>l9g$O?=$7Lu$"$j$^$;$s$G$7$?!#(B

$B!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z(B---$B!c;22C/;qK\$GG|Bg$JMx1W;O$a$^$;$s$+!*(B

$B@hF|!"2<5-$N$h$&$J%a!<%k$re$N?69~$"$j!K(B$BM7$S?4$r8f;}$A$NJ}$@$1!"@'Hs;22C$7$F2<$5$$!#(B

$B#4?M$N%j%9%H$K!o#1(B,$B#0#0#01_$E$D$rAw$k$@$1$GEj;q3[0J>e$NBg6b(B$B!J!o#1#0#0K|1_0J>e!K$rP!K!#(B

$B$"$/$^$G%2!<%`$H$$$&463P$G!&!&!&!#(B

$B!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z(B---$B!c;22Cl9g$O>eN&$7$F$^$@?t%v7n!#(B$B$"$H#1G/$A$g$C$H$O2T$2$k%>!*(B  
$B!J(B12.5.26$B!!El5~!!F?L>!!(B24$B:P!K(B

$B!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z(B---$B!c;22C?.H>5?$GBT$C$F$$$k$H!"MbF|$K#17o$NF~6b$,$"$j$^$7$?!#(B$B$BB3$-$^$7$?!##2=54V$r2a$.$?$3$m$K$O(B30$B7o0J>e$NF~6b$,!"KhF|!"%?%P$K$J$C$F$/$k$h(B$B$&$K$J$j$^$7$?!##4!A#5=54V$GF~6b$,$H$.$l$F$-$^$7$?$N$G!"(B$B$U$?$?$S%a!<%k$rAw$C$F$$$k$H$3$m$G$9!#!J(B12.6.25$B!!KL3$F;!!9,;R!!(B34$B:P!K(B

-

$B!!"#;22CJ}K!"#(B

$B$^$:!"2<5-(B4$B?M$N8}:B$K$*6b$r?6$j9~$s$G$/$@$5$$!#!J6d9T$N?6$j9~(B$B$_5!$G?6$j9~$_$^$9!K(B

$B$B%Z!<%9%H$7$F!"%j%9%H$K$"$k(B4$B$D$N8}:B$N0lHV>e$N?M$r:o=|$7$^$9!#(B$B$=$7$F!"%j%9%H$N0lHV2<$K$"$J$?$N8}:B$r=q$-$^$9!#(B$B$"$H$O!"(B4$B$D$N8}:B$K!"HV9f$r>e$+$i=g$K?6$j$J$*$7$^$9!#(B

$B$=$l$r!"$G$-$k$@$1$?$/$5$s%$%s%?!<%M%C%H$N7G<(HD$N%"%I%l%9$KAw(B$B$C$F$/$@$5$$!#$=$&$9$l$P!"$"$H$O$=$l$re$N?69~$,L5$$>l9g$O$b$&$R$H$U$s$P$j$7$^(B$B$9!#(B

$B0lHV>e$N8}:B$r:o=|$9$k$+$i!"K!N'$K?($l$J$$$G:Q$`$N$G$9!#$=$l$@(B$B$1$O@dBP$Ke$G0u:~$7$F$=$N;f$r;}$C$F$$$/$H$$$A$$$A=q$-(B$BJ$1$FJXMx$G$9$h!#(B

$B$?$H$($P!"%3%s%S%K$r3+6H$9$k$?$a$K$b3+6H;q6b$H$$$&$N$,MW$j$^$9(B$B$M!#$9$J$o$A>$N$*J[Ev$rGc$C$?$j!"4L%8%e!<%9$rGc$C$?$j!#$@$+(B$B$i!"$I$s$J%S%8%M%9$K$b3+6H;q6b$H$$$&$N$OI,MW$J$N$G$9!#$"$J$?$,(B$B?6$j9~$`(B4$B@i1_$O!"3+6H;q6b$H$*9M$(2<$5$$!#(B

Re: entropy reseeding is totally broken

[David O'Brien]

On Thu, Oct 26, 2000 at 09:25:05AM -0400, John W. De Boskey wrote:
 If this was happening in -stable I'd be in total agreement.
 However, we're talking -current, and is not -current the
 integration area for new technologies, whether they be
 rough or round edged?

Yes, -CURRENT is for new technologies and integration, even with rough
edges.  However, such integration should not cause major pain for more
than 3-4 days.  Anything more than 3 days or so, can really impact
other's work.  devrandom has taken a little longer than this.  Over the
past 3 weeks (or so), I've I've lost a day to this, and others piped up
saying they've lost a lot of time too.  This does not make me happy when
writing my status reports to my boss, or others who really hoped to spend
their Sunday afternoon developing their favorite new feature and instead
couldn't.

-- 
-- David  ([EMAIL PROTECTED])
  Disclaimer: Not speaking for FreeBSD, just expressing my own opinion.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

ipfw question.

[Glen Gross]

I built a 4.1.1 kernel, and the module was built, but when I load the ipfw 
module with

#kldload ipfw

it defaults to a deny_all policy, even though I have default_to_accept in my 
kernel configuration.
This makes it difficult to configure remotely without getting locked out of the 
system.
Is there a way to cause the ipfw module to default to a different policy upon 
loading?
For now it appears that I am locked out, until I can access the console.

Regards,

Glen M. Gross
Unix Technical Support Specialist
Symark Software
5716 Corsa Avenue, Suite 200
Westlake Village, CA  91362
http://www.symark.com
[EMAIL PROTECTED]
Main: 800-234-9072 or 818-865-6100
Main fax: 818-889-1894





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Mark Murray]

   I stated this same objection until I actually attended Mark's
 presentation at the 'con. The yarrow algorithm uses an encrypted hash for
 the entropy on the way in, and encrypts the output on the way out. This
 would make it extremely difficult to guess the state at reboot, even if we
 weren't picking up new entropy sources during the boot process. 

There is an angle; an attacker can attack by replaying, but this requires
strong privelige.

   Pending Mark's approval, I'd like to suggest we add a cron job to
 dump X k of data from /dev/random to a file (/boot/.periodic_entropy
 maybe?) and use that, AND ${entropy_file:/var/db/entropy} to reseed at
 boot, and only do the "long, annoying" failover process if neither file
 exists. The only remaining questions would be how many k of data to dump
 how often.

I like that, but I'd like to see more than one file. This avoids the race
where fsck may blat an incompletely written file after a (in)convenient
crash.

We are really headed towards saving state in the first swap partition
(if there is one).

On a related note, I'd like to see mergemaster rebuild /dev if it is not
DEVFS (obviously taking into account user preferences in MAKEDEV.local).

I believe that users are shootin their feet by not tracking /dev properly.

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: ipfw question.

[Bill Fumerola]

On Thu, Oct 26, 2000 at 01:31:03PM -0700, Glen Gross wrote:
 
 I built a 4.1.1 kernel, and the module was built, but when I load the ipfw 
 module with
 
 #kldload ipfw
 
 it defaults to a deny_all policy, even though I have default_to_accept in my 
 kernel configuration.
 This makes it difficult to configure remotely without getting locked out of the 
 system.
 Is there a way to cause the ipfw module to default to a different policy upon 
 loading?
 For now it appears that I am locked out, until I can access the console.

Your kernel configuration has ABSOLUTLY NOTHING to do with your module builds.

[hawk-billf] /usr/src  cat sys/modules/ipfw/Makefile
# $FreeBSD: src/sys/modules/ipfw/Makefile,v 1.13 2000/05/27 01:13:50 peter Exp $

.PATH:  ${.CURDIR}/../../netinet
KMOD=   ipfw
SRCS=   ip_fw.c
NOMAN=
CFLAGS+= -DIPFIREWALL
#
#If you want it verbose
#CFLAGS+= -DIPFIREWALL_VERBOSE
#CFLAGS+= -DIPFIREWALL_VERBOSE_LIMIT=100
#
#If you want it to pass all packets by default
#CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT
#

Guess what you should uncomment

-- 
Bill Fumerola - Network Architect, BOFH / Chimes, Inc.
[EMAIL PROTECTED] / [EMAIL PROTECTED]





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: ipfw question.

[Glen Gross]

Thanks, I suppose I should have been able to figure that one out... if I could 
log in!  I will fix it when I get home.  :-)

On Thursday, October 26, 2000 1:32 PM, Bill Fumerola [SMTP:[EMAIL PROTECTED]] 
wrote:
 On Thu, Oct 26, 2000 at 01:31:03PM -0700, Glen Gross wrote:
 
  I built a 4.1.1 kernel, and the module was built, but when I load the ipfw
  module with
 
  #kldload ipfw
 
  it defaults to a deny_all policy, even though I have default_to_accept in 
my
 
  kernel configuration.
  This makes it difficult to configure remotely without getting locked out of
  the
  system.
  Is there a way to cause the ipfw module to default to a different policy
  upon
  loading?
  For now it appears that I am locked out, until I can access the console.

 Your kernel configuration has ABSOLUTLY NOTHING to do with your module 
builds.


 [hawk-billf] /usr/src  cat sys/modules/ipfw/Makefile
 # $FreeBSD: src/sys/modules/ipfw/Makefile,v 1.13 2000/05/27 01:13:50 peter 
Exp
 $

 .PATH:  ${.CURDIR}/../../netinet
 KMOD=   ipfw
 SRCS=   ip_fw.c
 NOMAN=
 CFLAGS+= -DIPFIREWALL
 #
 #If you want it verbose
 #CFLAGS+= -DIPFIREWALL_VERBOSE
 #CFLAGS+= -DIPFIREWALL_VERBOSE_LIMIT=100
 #
 #If you want it to pass all packets by default
 #CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT
 #

 Guess what you should uncomment

 --
 Bill Fumerola - Network Architect, BOFH / Chimes, Inc.
 [EMAIL PROTECTED] / [EMAIL PROTECTED]




Glen M. Gross
Unix Technical Support Specialist
Symark Software
5716 Corsa Avenue, Suite 200
Westlake Village, CA  91362
http://www.symark.com
[EMAIL PROTECTED]
Main: 800-234-9072 or 818-865-6100
Main fax: 818-889-1894





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

A few issues I ran into (and a quick question)

[Rogier R. Mulhuijzen]

First of all (using -current of 26 October) I was not able to attach pcm to 
my Yamaha OPL-SAx soundcard in my Toshiba Tecra8000 when using snd_pcm.ko. 
Using a statically compiled driver though I had no trouble whatsoever. The 
module was pre-loaded at boot time.

2nd with a working pcm driver I get sound glitches with display activity 
under X (4.0). This was something I had before with both pcm and OSS's 
sounddriver so it's not really an issue with the pcm driver but with the 
X-server I assume. I DO have additional glitches occaisionally, that I 
didn't have before and they are accompanied by the following kernel message:

pcm0: hwptr went backwards nnn - mmm

Where nnn and mmm are numbers. nnn is not always bigger than mmm but I have 
not seen either value above 4096.

Any pointers in what to attack in the X-server and/or pcm driver would be 
appreciated.

My 3rd point is that I can't access any files on my NTFS partition. I have 
3 partitions, one NTFS, one FAT16 and one BSD. FAT16 works fine, I can read 
and write to it and all, but NTFS is being a bitch.

I can use 'ls' fine, no trouble there, I get all my directory listings and 
I can change directories etc. etc. But I can't open any files at all. Even 
'cat' fails. The error I get is 'Inappropriate ioctl for device'

It's been a long day so I'm not going to look into it further right now, 
but if no one jumps up and says "D'oh I know what that is, let me fix 
that..here's your patch, commit in 5 minutes" I'll go dig. In looking 
for heads-up posts I ran across a single cvs-all post on the 1st of Oct 
about ntfs.h, so I'm guessing that's where I will start. (The last time I 
tried to access files on my NTFS drive was with a september build of -current).

That's it for now.

Oh, just out of curiosity, I build both my kernel and world with 
-mcpu=pentiumpro and -march=pentiumpro. Would there be any reasons not to?

DocWilco



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ipfw question.

[Bill Fumerola]

On Thu, Oct 26, 2000 at 01:36:40PM -0700, Glen Gross wrote:
 Thanks, I suppose I should have been able to figure that one out... if I could 
 log in!  I will fix it when I get home.  :-)

Playing with firewalls without out-of-band (serial console, nocmonkey, etc) is 
dangerous.

-- 
Bill Fumerola - Network Architect, BOFH / Chimes, Inc.
[EMAIL PROTECTED] / [EMAIL PROTECTED]





To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: $B$O$8$a$^$7$F!#(B

[Rogier R. Mulhuijzen]

Does this look like english to anyone and is my mailer messed, or is this 
gobbledegook to anyone not using Outlook + japanese character set?

 DocWilco

At 05:12 27-10-00 +0900, you wrote:
$B$O$8$a$^$7$F!#(B
$BFMA3$N%a!=%k!":NiCW$7$^$9!#(B

$B;d$N%a!%k%\%C%/%9$K!"#1#0%v7n0LA0$+$i(B
$B!V#4#0#0#01_$r?6$j9~$`$H!"+J,$N8}:B$K!"$*6b$,?6$j9~$^$l$k$h$$K$J$k!W(B
$B$H$$$C$?35N,$N%M%C%H%2!%`$NM6$$$,FO$/$h$$K$J$C$FMh$^$7$?!#(B

$B$3$N$h$$J%a!%k$K$O6=L#$,L5$+$C$?$N$G!"Ev=i$OL5;k$7$FB(%4%_H"9T$-$K$7$F$$$^$7$?!#(B
$B$3$N5=$N$h$$J46$8$b$7$^$7$?$7!#(B
$B$7$+$7!"$3$N%2!%`$,#1#0%v7n$bB3$$$F$$$k;v$K!"/$76=L#$r;}$D$h$$K$J$C$F$-$^$7$?!#(B
$B!V#1#0%v7n$bB3$$$F$$$k$N$J$i0cK!@-$OL5$5$=$$@$J!A!W$d!V:#!"N.9T$C$F$$$k$N$+$J!A!)!W(B
$B$J$I$H;W$$!"FO$$$?%a!%k$r!"$h!$/FI$s$G8+$k$H!"#1HVe$N?M$OH4$1$F9T$/$N$G!"(B
$B3N$+$K0cK!@-$OL5$/!"LLGr$=$ W$($^$7$?!#(B
$B$=$Ne!"$$^$/=PMh$F$$$k%7%9%F%`$@$H46?4$7$^$7$?!#(B
$B!J%a!%k$N:G8e$NJ}$KK!E*$J;v9`$r5-:\$7$F$$$^$9!#!K(B

$B$=$3$G!";d$b;22C$9$k$3$H$K7h$a!"/$7A0$+$i3hF0$7$F$$$^$9!#(B
$B$9$k$H!"#1=54VDx$G$*6b$,?6$j9~$^$l$F$/$k$h$$K$J$C$?$N$G$9!#(B
$B@5D!"6C$-$^$7$?!#(B

$B:#$^$G!"KhG/%8%c%s%\Ju$/$8$rGc$C$F$$$F$b!":G9b$G#3#0#0#01_$7$+Ev$?$C$?;v$,L5$$$N$K!*(B
$B$3$l$O!"Ju$/$8$h$j3NN)$O@dBP$K9b$$$H;W$$$^$9!#(B

$B0J2$K!":#$^$GD:$$$?%a!%k$NCf$+$iJ8LL$r(B3$B$DH4?h$7$F7G:\$5$;$FD:$-$^$9!#(B
$B;29M$K$J$k$H;W$$$^$9$N$G!"$h$1$l$P#1EY!"L\$rDL$7$FD:$1$l$P9,$$$G$9!#(B

$B$J$*!"$3$N$h$$J%a!%k$,I,MW$GL5$+$C$?l9g$O?=$7Lu$"$j$^$;$s$G$7$?!#(B

$B!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z(B
---$B!c;22C$B@dBP3N/;qK\$GG|Bg$JMx1W;O$a$^$;$s$+!*(B

$B@hF|!"25-$N$h$$J%a!%k$r$B!o#4!$#0#0#01_$NEj;q$J$i$H;W$$;n$7$K;22C$7$F$_$?$i!"#2F|L\(B
$B$G:G=i$NEj;qJ,$r$9$0$K2s}$G$-$?$N$G!"$3$l$OLLGr$$$H;W$$0F(B
$BFb$5$;$FD:$-$^$7$?!#(B
$B!o#4!$#0#0#01_$N6b3[$J$iC/$G$b$,!XK!N'$K?($l$J$1$l$P$,!Y(B
$B$H$$$46$8$N$h$$G$9!#$I$$G$9$+!)!!(B
$B5.J}$bM7$S?4$G;22C$7$F$_$F$O!D!JKhF|#1#07o0Je$N?69~$"$j!K(B
$BM7$S?4$r8f;}$A$NJ}$@$1!"@'Hs;22C$7$F2$5$$!#(B

$B#4?M$N%j%9%H$K!o#1(B,$B#0#0#01_$E$D$rAw$k$@$1$GEj;q3[0Je$NBg6b(B
$B!J!o#1#0#0K|1_0Je!K$r$B!X$=$s$J4E$$OC$,$"$k$+$$$J!Y$=$l$,:G=i$N46A[$G$7$?!#EvA3$G$7(B
$B$g$!#$^$H$b$J?M4V$J$i(B...$B!#$G$b!"$h!A$/9M$($F$_$k$H!"$J$+$J$+(B
$BLLGr$$%^%M!=%2!=%`$@$7!"$O$:$l$F$P$+$j$$$kJu$/$8$KHf$Y$?$i3N(B
$BN($Ot#$K9b$$$+$b!"$H;W$($?$N$G;n$7$K;22C$7$F$_$k;v$K$7$^$7$?!#(B

$B$7$+$7%O%^$j2a$.$F;E;v$r(B
$B-$a$k$N$O$d$a$^$7$g$!JP!K!#(B

$B$"$/$^$G%2!%`$H$$$463P$G#(B

$B!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z(B
---$B!c;22C$B$[$s$H$$K$*6b$,$[$7$+$C$?$i%*%9%9%a!*(B
$B$\$/$NM'?M$b#3=54V$G#2#0K|1_$A$+$/2T$$$G$7$^$$$^$7$?$+$i!*!*(B
4,000$B1_$,Bg6b$K$J$C$?$h!*$3$N!V%j%T!%H!%U%)!$B$KBg%V!%`$r$*$3$7!"8=:_$O?jB`4|$KF~$C$F$$$k$HJ9$-$^$7$?!#!!(B
$B%V!%`$O#2!A#3G/B3$/$H$N$3$H$G$9$,!"F|K\$Nl9g$OeN$7$F$^$@?t%v7n!#(B
$B$"$H#1G/$A$g$C$H$O2T$2$k%!*(B 
$B!J(B12.5.26$B!!El5~!!F?L!!(B24$B:P!K(B

$B!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z!y!z(B
---$B!c;22C$B!X$=$s$J4E$$OC$,$"$k$@$m$$+!*!Y$=$l$,:G=i$N46A[$G$7$?!#(B
$B$H$$$s$G$7$g$!*$G$b!"$h!$/FI$s$G$_$k$HG$B$O$:$l$F$P$+$j$$$kJu%/%8$K$/$i$Y$?$i3NN($O$O$k$+$K9b$$$+$b!)(B
$B$=$ 22C$7$F$_$k$3$H$K$7$^$7$?!#(B
$B$=$7$FH?.H5?$GBT$C$F$$$k$H!"MbF|$K#17o$NF~6b$,$"$j$^$7$?!#(B
$B$BB3$-$^$7$?!##2=54V$r2a$.$?$3$m$K$O(B30$B7o0Je$NF~6b$,!"KhF|!"%?%P$K$J$C$F$/$k$h(B
$B$$K$J$j$^$7$?!##4!A#5=54V$GF~6b$,$H$.$l$F$-$^$7$?$N$G!"(B
$B$U$?$?$S%a!%k$rAw$C$F$$$k$H$3$m$G$9!#!J(B12.6.25$B!!KL3$F;!!9,;R!!(B34$B:P!K(B


-

$B!!"#;22CJ}K!"#(B

$B$^$:!"25-(B4$B?M$N8}:B$K$*6b$r?6$j9~$s$G$/$@$5$$!#!J6d9T$N?6$j9~(B
$B$_5!$G?6$j9~$_$^$9!K(B

$B$B%Z!%9%H$7$F!"%j%9%H$K$"$k(B4$B$D$N8}:B$N0lHVe$N?M$r:o=|$7$^$9!#(B
$B$=$7$F!"%j%9%H$N0lHV2$K$"$J$?$N8}:B$r=q$-$^$9!#(B
$B$"$H$O!"(B4$B$D$N8}:B$K!"HV9f$re$+$i=g$K?6$j$J$*$7$^$9!#(B

$B$=$l$r!"$G$-$k$@$1$?$/$5$s%$%s%?!%M%C%H$N7G(HD$N%"%I%l%9$KAw(B
$B$C$F$/$@$5$$!#$=$$9$l$P!"$"$H$O$=$l$r$B$j$3$s$G$/$l$^$9!#(B
$B:G=i$N#1=54V$G#1#07o0Je$N?69~$,L5$$l9g$O$b$$R$H$U$s$P$j$7$^(B
$B$9!#(B

$B0lHVe$N8}:B$r:o=|$9$k$+$i!"K!N'$K?($l$J$$$G:Q$`$N$G$9!#$=$l$@(B
$B$1$O@dBP$K

$B$J$*!"6d9T$K9T$/;~!"(B4$B?M$N8}:B$H8}:BHV9f$r%3%T!$7!"%o!%W%m%=(B
$B%U%H$K%Z!%9%H$7$?e$G0u:~$7$F$=$N;f$r;}$C$F$$$/$H$$$A$$$A=q$-(B
$BJ$1$FJXMx$G$9$h!#(B

$B$?$H$($P!"%3%s%S%K$r3+6H$9$k$?$a$K$b3+6H;q6b$HN$,MW$j$^$9(B
$B$M!#$9$J$o$AIJ$N$*J[Ev$rGc$C$?$j!"4L%8%e!%9$rGc$C$?$j!#$@$+(B
$B$i!"$I$s$J%S%8%M%9$K$b3+6H;q6b$HN$OI,MW$J$N$G$9!#$"$J$?$,(B
$B?6$j9~$`(B4$B@i1_$O!"3+6H;q6b$H$*9M$(2$5$$!#(B

$B!!#D#M$NJ?6QE*@.2L$O(B0.3$B!A(B0.5$B!s0L$G$9!#!J(B1/200$B!A(B1/300$B!K(B
$B!!8e$O!"8=6b!o#1!$#0#0#01_$,?69~$^$l$k$N$rBT$D$@$1!#(B
$B!!#1CJL\$N@.2L!)(B
$B!J!o#1!$#0#0#01_!_#1#0?M!a!o#1K|1_!)!K(B
$B!!#2CJL\$N@.2L!)(B
$B!J!o#1!$#0#0#01_!_#1#0?M!_#1#0?M!a!o#1#0K|1_!)!K(B
$B!!#3CJL\$N@.2L!)(B
$B!J!o#1!$#0#0#01_!_#1#0?M!_#1#0?M!_#1#0?M!a!o#1#0#0K|1_!)!K(B
   $B#4CJL\$N@.2L!)(B
$B!J!o#1!$#0#0#01_!_#1#0?M!_#1#0?M!_#1#0?M!_#1#0?M!a!o#1#0#0#0K|1_!)!K(B
$B"($*6b$rAw$i$J$$$G%j%9%H$K+J,$NLA0$r:\$;$k$H!"D$0$K$P$l$^$9(B

subscribe

[Leonardo Magallon]

subscribe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ipfw question.

[Rogier R. Mulhuijzen]

This makes it difficult to configure remotely without getting locked out 
of the
system.
Is there a way to cause the ipfw module to default to a different policy upon
loading?

I'm not sure about influencing modules with options in kernel config, I'll 
leave that to the pro's but you could as a workaround use:

echo kldload ipfw  load_ipfw.sh
echo ipfw add 65000 allow all from any to any  load_ipfw.sh
nohup sh load_ipfw.sh

I vaguely remember stuffing them both on one commandline fails because the 
shell dies due to the block before the ipfw command is executed. Hence the 
nohup.

For now it appears that I am locked out, until I can access the console.

That's what all the warnings about doing ipfw stuff remotely are for =)

 Doc "I have shot myself in the foot doing ipfw remotely too" Wilco




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

No Subject

[Ed Hall]

Doug Barton wrote:
:   Pending Mark's approval, I'd like to suggest we add a cron job to
: dump X k of data from /dev/random to a file (/boot/.periodic_entropy
: maybe?) and use that, AND ${entropy_file:/var/db/entropy} to reseed at
: boot, and only do the "long, annoying" failover process if neither file
: exists. The only remaining questions would be how many k of data to dump
: how often.

How about skipping the "long, annoying failover process" altogether and
simply logging to the console that the entropy reseeding process was
incomplete?  Forcing an indeterminate delay to gather entropy is more
than a little paternalistic.

I've little doubt of /dev/random's theoretical soundness.  But a
theoretical boost in security won't justify an actual reduction in
availability to many folks.

-Ed




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Matt Dillon]

:I like that, but I'd like to see more than one file. This avoids the race
:where fsck may blat an incompletely written file after a (in)convenient
:crash.
:
:We are really headed towards saving state in the first swap partition
:(if there is one).
:M
:--
:Mark Murray
:Join the anti-SPAM movement: http://www.cauce.org

This would be trivial, you can use the swap allocation code (example:
see the VN device, dev/vn/vn.c) to reserve, read, and write the swap.

However, I don't see much of a point in doing this.  Not everyone
configures swap, so you can't count on it, and a system dump will
overwrite swap, so you would have to mess around with that as well
and I can tell you it just isn't worth the effort.  Maintaining an entropy
file in /var/db has no downside at all and is a whole lot easier
to manage.

This /dev/random stuff is a little wild -- I think the premis is sound,
but you really need to look towards implementing more straightforward
solutions rather then hacking up unrelated parts of the system.  Forget
doing special magic in the kernel.  Forget using swap.  Forget having
ridiculously huge entropy files.  Simplify it and everyone will be a whole
lot happier.

-Matt




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Ed Hall]

Doug Barton wrote:
:   Pending Mark's approval, I'd like to suggest we add a cron job to
: dump X k of data from /dev/random to a file (/boot/.periodic_entropy
: maybe?) and use that, AND ${entropy_file:/var/db/entropy} to reseed at
: boot, and only do the "long, annoying" failover process if neither file
: exists. The only remaining questions would be how many k of data to dump
: how often.

How about skipping the "long, annoying failover process" altogether and
simply logging to the console that the entropy reseeding process was
incomplete?  Forcing an indeterminate delay to gather entropy is more
than a little paternalistic.

I've little doubt of /dev/random's theoretical soundness.  But a
theoretical boost in security won't justify an actual reduction in
availability to many folks.

-Ed




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Mark Murray]

 This would be trivial, you can use the swap allocation code (example:
 see the VN device, dev/vn/vn.c) to reserve, read, and write the swap.

Thanks! :-)

 However, I don't see much of a point in doing this.  Not everyone
 configures swap, so you can't count on it, and a system dump will
 overwrite swap, so you would have to mess around with that as well
 and I can tell you it just isn't worth the effort.  Maintaining an entropy
 file in /var/db has no downside at all and is a whole lot easier
 to manage.

There is the problem that for each setup, there are many admins who
will have a non-writable filesapce for at least one of (/ /var /boot /etc).

Sure, there may not be a $PRIMARYSWAP, but if there is, it is IMO the best
place to put stashed entropy.

 This /dev/random stuff is a little wild -- I think the premis is sound,
 but you really need to look towards implementing more straightforward
 solutions rather then hacking up unrelated parts of the system.  Forget
 doing special magic in the kernel.  Forget using swap.  Forget having
 ridiculously huge entropy files.  Simplify it and everyone will be a whole
 lot happier.

:-) I'd like your suggestion a lot more if you supplied some more concrete
hints. I like KISS, and current evolution is looking a little wierd. I'd
enjoy seeing a true/beautiful/simple solution - patches welcome. :-)

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: entropy reseeding is totally broken

[Matt Dillon]

: This would be trivial, you can use the swap allocation code (example:
: see the VN device, dev/vn/vn.c) to reserve, read, and write the swap.
:
:Thanks! :-)
:
: However, I don't see much of a point in doing this.  Not everyone
: configures swap, so you can't count on it, and a system dump will
: overwrite swap, so you would have to mess around with that as well
: and I can tell you it just isn't worth the effort.  Maintaining an entropy
: file in /var/db has no downside at all and is a whole lot easier
: to manage.
:
:There is the problem that for each setup, there are many admins who
:will have a non-writable filesapce for at least one of (/ /var /boot /etc).
:
:Sure, there may not be a $PRIMARYSWAP, but if there is, it is IMO the best
:place to put stashed entropy.

/etc/rc already assumes that /var is writable.  I recommend that you make
that assumption by default... have the default entropy file be something
like "/var/db/entropy_seed" and allow the administrator to override it
with an RC variable.  You could allow the administrator to select a
different entropy file and you could have another RC variable which allows
the administrator to set a command which, when executed, returns an
arbitrary sequence of bytes on its stdout to initialize entropy with.

defaults (in /etc/defaults/rc.conf)  (this is an example)

entropy_file="/var/db/entropy_seed"
entropy_program="/sbin/gather_entropy -time -hostname -rootstatfs"
entropy_file_mode="RW"

Example override:

entropy_file="NO"
entropy_program="/usr/local/bin/my_special_entropy_program"

Another example override:

# seed with read-only entropy file and then gather additional
# entropy from other sources, like the time.
#
entropy_file_mode="RO"
entropy_program="/sbin/gather_entropy -network -time -keyboard_if_insufficient"

etc...

This would give us maximum flexibility, yet provide suitable defaults
for most sysinstall-based configurations.  For example, this gives you
the ability to write an /sbin utility to do the more complex (or more
secure) entropy gathering as part of the boot process and then allow
the administrator to specify it with appropriate options to suit his
tastes, rather then having to build it into the kernel.  

Your /sbin program could deal with things like using swap instead of
an entropy file and so forth.  I think if you did things this way it
would remove virtually all the pain developers are feeling from the
current state of affairs.

: lot happier.
:
::-) I'd like your suggestion a lot more if you supplied some more concrete
:hints. I like KISS, and current evolution is looking a little wierd. I'd
:enjoy seeing a true/beautiful/simple solution - patches welcome. :-)
:
:M

See above.

-Matt

:--
: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

Is this a typo?

[Julian Elischer]

in the bus_alloc_resource() man page it states:


 dev is the device that requests ownership of the resource.  Before
allo-
 cation, the device is owned by the parent bus.

should that be:
"Before allocation, the resource is owned by the parent bus."  ?
(It doesn't make sense t me as it is..)

-- 
  __--_|\  Julian Elischer
 /   \ [EMAIL PROTECTED]
(   OZ) World tour 2000
--- X_.---._/  presently in:  Budapest
v




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Doug Barton]

On Thu, 26 Oct 2000, Ed Hall wrote:

 How about skipping the "long, annoying failover process" altogether and
 simply logging to the console that the entropy reseeding process was
 incomplete?  Forcing an indeterminate delay to gather entropy is more
 than a little paternalistic.

The problem is, it's going to block somewhere. If we don't
"block" while creating the entropy, the first thing that needs random bits
is going to block for real because /dev/random isn't going to have
anything to feed it. 

We must come up with an entropy reseeding mechanism that has a
reasonably high degree of success for a reasonably high number of cases. 

Doug



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: A few issues I ran into (and a quick question)

[Cameron Grant]

 First of all (using -current of 26 October) I was not able to attach pcm
to
 my Yamaha OPL-SAx soundcard in my Toshiba Tecra8000 when using snd_pcm.ko.
 Using a statically compiled driver though I had no trouble whatsoever. The
 module was pre-loaded at boot time.

snd_pcm is the core module, it requires other driver modules before it will
be activated.  currently, loading snd_driver will load all drivers and the
core, but this will change.

 2nd with a working pcm driver I get sound glitches with display activity
 under X (4.0). This was something I had before with both pcm and OSS's
 sounddriver so it's not really an issue with the pcm driver but with the
 X-server I assume. I DO have additional glitches occaisionally, that I
 didn't have before and they are accompanied by the following kernel
message:

this is an artifact of the smpng work increasing irq latency.  it will go
away in time.

-cg




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Poul-Henning Kamp]

In message [EMAIL PROTECTED], Doug
 Barton writes:
On Thu, 26 Oct 2000, Ed Hall wrote:

 How about skipping the "long, annoying failover process" altogether and
 simply logging to the console that the entropy reseeding process was
 incomplete?  Forcing an indeterminate delay to gather entropy is more
 than a little paternalistic.

   The problem is, it's going to block somewhere. If we don't
"block" while creating the entropy, the first thing that needs random bits
is going to block for real because /dev/random isn't going to have
anything to feed it. 

   We must come up with an entropy reseeding mechanism that has a
reasonably high degree of success for a reasonably high number of cases. 

I think the strategy here is to feed it as much as we can from the
kernel during device-probe/attach as possible.

I don't really care that much how good my random bits are right after
boot, but I do care about my machine coming up quickly.

Add a /etc/rc.conf knob which says

wait_until_entropy_collected=YES

which people who care a lot about randomness can set.

--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | 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: ipfw question.

[David O'Brien]

On Thu, Oct 26, 2000 at 04:31:57PM -0400, Bill Fumerola wrote:
 #If you want it verbose
 #CFLAGS+= -DIPFIREWALL_VERBOSE
 #CFLAGS+= -DIPFIREWALL_VERBOSE_LIMIT=100
 #
 #If you want it to pass all packets by default
 #CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT

So one doesn't have to change the source, would you be willing to add
WANT_foo logic so one could just set it in /etc/make.conf?  Or add
${IPFIREWALL_OPTS} to CFLAGS and then IPFIREWALL_OPTS could be set in
/etc/make.conf?

-- 
-- David  ([EMAIL PROTECTED])


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Wesley Morgan]

On Thu, 26 Oct 2000, Poul-Henning Kamp wrote:

 I don't really care that much how good my random bits are right after
 boot, but I do care about my machine coming up quickly.

I don't know about that, look at your boot logs:

Oct 26 17:32:19 catalyst /boot/kernel/kernel: Copyright (c) 1992-2000 The FreeBSD 
Project.
Oct 26 17:32:19 catalyst /boot/kernel/kernel: Copyright (c) 1979, 1980, 1983, 1986, 
1988, 1989, 1991, 1992, 1993, 1994
Oct 26 17:32:23 catalyst sshd[193]: Generating 768 bit RSA key.
Oct 26 17:32:23 catalyst sshd[193]: RSA key generation complete.

Those times aren't correct I'm sure, but if I can't get enough entropy for 
a 768 bit key _very soon_ after boot, we could have a problem.

Somehow, I think everyone should care about that.

 
 Add a /etc/rc.conf knob which says
 
   wait_until_entropy_collected=YES

Why not be secure by default and have

i_dont_care_about_entropy=NO

-- 
   _ __ ___   ___ ___ ___
  Wesley N Morgan   _ __ ___ | _ ) __|   \
  [EMAIL PROTECTED]  _ __ | _ \._ \ |) |
  FreeBSD: The Power To Serve  _ |___/___/___/
  6bone: 3ffe:1ce3:7::b4ff:fe53:c297
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[David O'Brien]

On Thu, Oct 26, 2000 at 02:25:58PM -0700, Matt Dillon wrote:
 /etc/rc already assumes that /var is writable.  I recommend that you make
 that assumption by default... have the default entropy file be something
 like "/var/db/entropy_seed" and allow the administrator to override it
 with an RC variable.  You could allow the administrator to select a
 different entropy file and you could have another RC variable which allows
 the administrator to set a command which, when executed, returns an
 arbitrary sequence of bytes on its stdout to initialize entropy with.

This is sweet!  Seems it would give us the full benefits of Mark's
randomdev, and fit nicely with our normal configuration framework and
gives good flexibility.

-- 
-- David  ([EMAIL PROTECTED])
  GNU is Not Unix / Linux Is Not UniX


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Poul-Henning Kamp]

In message [EMAIL PROTECTED]
om, Wesley Morgan writes:
On Thu, 26 Oct 2000, Poul-Henning Kamp wrote:

 I don't really care that much how good my random bits are right after
 boot, but I do care about my machine coming up quickly.

I don't know about that, look at your boot logs:

Oct 26 17:32:19 catalyst /boot/kernel/kernel: Copyright (c) 1992-2000 The FreeBSD 
Project.
Oct 26 17:32:19 catalyst /boot/kernel/kernel: Copyright (c) 1979, 1980, 1983, 1986, 
1988, 1989, 1991, 1992, 1993, 1994
Oct 26 17:32:23 catalyst sshd[193]: Generating 768 bit RSA key.
Oct 26 17:32:23 catalyst sshd[193]: RSA key generation complete.

Those times aren't correct I'm sure, but if I can't get enough entropy for 
a 768 bit key _very soon_ after boot, we could have a problem.

Somehow, I think everyone should care about that.

You know, I think this thing is being blown out of proportion.

WAY out of proportion.

Yes, there are systems which the administrator will want to set to
ultra_paranoid=YESDAMNIT!

but for all the machines I have behind firewalls I would like to have
act_like_a_normal_unix_and_boot_in_finite_time=YESPLEASE


--
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | 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: ipfw question.

[John Baldwin]

On 26-Oct-00 David O'Brien wrote:
 On Thu, Oct 26, 2000 at 04:31:57PM -0400, Bill Fumerola wrote:
 #If you want it verbose
 #CFLAGS+= -DIPFIREWALL_VERBOSE
 #CFLAGS+= -DIPFIREWALL_VERBOSE_LIMIT=100
 #
 #If you want it to pass all packets by default
 #CFLAGS+= -DIPFIREWALL_DEFAULT_TO_ACCEPT
 
 So one doesn't have to change the source, would you be willing to add
 WANT_foo logic so one could just set it in /etc/make.conf?  Or add
 ${IPFIREWALL_OPTS} to CFLAGS and then IPFIREWALL_OPTS could be set in
 /etc/make.conf?

Ugh, no.  Peter's forthcoming config(8) changes will allow you to
specify kernel options to use when building modules (actually, it
builds modules in the same environment as the kernel) to properly
handle this.  Just be patient until we have the right solution
finished and in the tree.

-- 

John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

No Subject

[vtycer]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ipfw question.

[David O'Brien]

On Thu, Oct 26, 2000 at 03:18:55PM -0700, John Baldwin wrote:
 Ugh, no.  Peter's forthcoming config(8) changes will allow you to
 specify kernel options to use when building modules (actually, it
 builds modules in the same environment as the kernel) to properly
 handle this.  Just be patient until we have the right solution
 finished and in the tree.

I disagree.  Vaporware (example Son of Sysinstall) has kept us from
improving things until the fabled newstuff arrives.

Unless you have a strong commitment from Peter on a time frame, we need
to offer an easy way to control the functionality of the ipfw module.

-- 
-- David  ([EMAIL PROTECTED])
  GNU is Not Unix / Linux Is Not UniX


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Jim Bryant]

hmmm...  I just got a message from chris, he said he will be adding
AES/Rijndael to the kernel ASAP...

According to the Rijndael spec, it seems to also function as an
excellant pseudo-random number generator...

You can find this info at:

http://www.esat.kuleuven.ac.be/~rijmen/rijndael

Section 13.4 of the Rijndael Block Cipher AES Proposal [version 2],
describes this functionality.  Based on the benchmark times of this
process, I don't think it would be a serious performance hit to do
this.  If it's going to be in the kernel anyway...

Just a constructive suggestion.

In reply:
 In real life, machines don't always get rebooted in a completely
 controlled fashion (panic, power failure, etc.).  Anything that
 makes a reboot longer or less reliable is a definite non-starter.
 
 I can guarantee you, if the current /dev/random code isn't fixed before
 it makes STABLE, folks running servers 24/7 are going to rip it right
 out.
 
   -Ed

jim
-- 
All opinions expressed are mine, if you|  "I will not be pushed, stamped,
think otherwise, then go jump into turbid  |  briefed, debriefed, indexed, or
radioactive waters and yell WAHOO !!!  |  numbered!" - #1, "The Prisoner"
--
[EMAIL PROTECTED]  KC5VDJ - HF to 23cm  KC5VDJ@NW0I.#NEKS.KS.USA.NOAM
HF/VHF: IC-706MkII   VHF/UHF/SHF: IC-T81AKPC3+  PK-232MBXGrid: EM28px
--
  ET has one helluva sense of humor, always anal-probing right-wing schizos!


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ipfw question.

[John Baldwin]

On 26-Oct-00 David O'Brien wrote:
 On Thu, Oct 26, 2000 at 03:18:55PM -0700, John Baldwin wrote:
 Ugh, no.  Peter's forthcoming config(8) changes will allow you to
 specify kernel options to use when building modules (actually, it
 builds modules in the same environment as the kernel) to properly
 handle this.  Just be patient until we have the right solution
 finished and in the tree.
 
 I disagree.  Vaporware (example Son of Sysinstall) has kept us from
 improving things until the fabled newstuff arrives.

Code that is in his tree != vaporware (yes, I have seen an actual
modified src tree with it in there)

 Unless you have a strong commitment from Peter on a time frame, we need
 to offer an easy way to control the functionality of the ipfw module.

a) This is current.  5.0-release isn't next week, so we have time to get
   this done right.
b) Any hacks we add now we have to then be backward compatibile with
   later on which increases the maintenance load.

-- 

John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!"  -  http://www.FreeBSD.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Mark Murray]

Hi

Very wonderful ideas! It will take me a bit of time to implement this
cleanly as I am not close enough to my Prime Development Platform, but
I will do something as soon as possible. Consider it to be not less
than two weeks, unless someone submits patches first.

:-)

M

 :There is the problem that for each setup, there are many admins who
 :will have a non-writable filesapce for at least one of (/ /var /boot /etc).
 :
 :Sure, there may not be a $PRIMARYSWAP, but if there is, it is IMO the best
 :place to put stashed entropy.
 
 /etc/rc already assumes that /var is writable.  I recommend that you make
 that assumption by default... have the default entropy file be something
 like "/var/db/entropy_seed" and allow the administrator to override it
 with an RC variable.  You could allow the administrator to select a
 different entropy file and you could have another RC variable which allows
 the administrator to set a command which, when executed, returns an
 arbitrary sequence of bytes on its stdout to initialize entropy with.
 
 defaults (in /etc/defaults/rc.conf)  (this is an example)
 
   entropy_file="/var/db/entropy_seed"
   entropy_program="/sbin/gather_entropy -time -hostname -rootstatfs"
   entropy_file_mode="RW"
 
 Example override:
 
   entropy_file="NO"
   entropy_program="/usr/local/bin/my_special_entropy_program"
 
 Another example override:
 
   # seed with read-only entropy file and then gather additional
   # entropy from other sources, like the time.
   #
   entropy_file_mode="RO"
   entropy_program="/sbin/gather_entropy -network -time -keyboard_if_insufficient"
 
 etc...
 
 This would give us maximum flexibility, yet provide suitable defaults
 for most sysinstall-based configurations.  For example, this gives you
 the ability to write an /sbin utility to do the more complex (or more
 secure) entropy gathering as part of the boot process and then allow
 the administrator to specify it with appropriate options to suit his
 tastes, rather then having to build it into the kernel.  
 
 Your /sbin program could deal with things like using swap instead of
 an entropy file and so forth.  I think if you did things this way it
 would remove virtually all the pain developers are feeling from the
 current state of affairs.
 
 : lot happier.
 :
 ::-) I'd like your suggestion a lot more if you supplied some more concrete
 :hints. I like KISS, and current evolution is looking a little wierd. I'd
 :enjoy seeing a true/beautiful/simple solution - patches welcome. :-)
 :
 :M
 
 See above.
 
   -Matt
 
 :--
 :Mark Murray
 :Join the anti-SPAM movement: http://www.cauce.org
 
--
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: A few issues I ran into (and a quick question)

[Dan Papasian]

On Thu, Oct 26, 2000 at 10:43:44PM +0200, Rogier R. Mulhuijzen wrote:
 Oh, just out of curiosity, I build both my kernel and world with 
 -mcpu=pentiumpro and -march=pentiumpro. Would there be any reasons not to?

Anything above -O -pipe is not offically supported.  While you didn't
give your optimization level, it's probably -O2 or so, and that has
burned people in the past who built their kernels as such.

So the offical answer is no, you can't do that.  But the unoffical answer
is if it works for you, count your blessings and continue.  But
when something breaks, before you complain with a problem, go back
and compile your kernel with no more than -O -pipe.

-- 
  Dan Papasian
  ([EMAIL PROTECTED])

"How are we to distinguish the difference between
reality and dream?  Dreams result from a relationship
of atoms.  So do our bodies."
--Charles Augustus Lindbergh


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: XFree86 3.3.6_3 build dies on -current

[Garrett Wollman]

On Thu, 26 Oct 2000 13:58:09 -0400, Marcel Moolenaar [EMAIL PROTECTED] said:

 Eventually yes, but not this way. According to Bruce sys/types is a
 prerequisite for sys/wait.

This is currently true, but should be fixed this year (probably not
this month -- it depends on how much energy I have).

Draft 4 (draft 5 isn't out yet) of POSIX.1-200x says the following
(p. 411, ll. 13759 et seq):

The id_t and pid_t types shall be defined as described in
sys/types.h.
[begin XSI]
The siginfo_t type shall be defined as described in
signal.h.
The rusage structure shall be defined as described in
sys/resource.h.
Inclusion of the sys/wait.h header may also make visible all
symbols from signal.h and sys/resource.h.
[end XSI]

So, sys/types.h is not a prerequisite for 1003.1-200x's
sys/wait.h.  For the XSI extension, implementors are given special
license for certain XSI-required data types (which, being structures,
are somewhat impractical to define in the usual way); in a pure-POSIX
environment sys/types.h is not permitted.  According to the revision
history (p. 412), this is a requirement carried over from SUSv2 and
dates back to XPG4v2.

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
[EMAIL PROTECTED]  | O Siem / The fires of freedom 
Opinions not those of| Dance in the burning flame
MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ipfw question.

[Jordan Hubbard]

 I disagree.  Vaporware (example Son of Sysinstall) has kept us from
 improving things until the fabled newstuff arrives.

That's actually a bad example since just a brief glance at the cvs
commit logs for sysinstall will show that a number of fingers have
dived into it over the years and "improved" it (sometimes to the point
of unusability! :).

I've also sent out numerous appeals to the various mailing lists for
someone, anyone, to come up with something better than sysinstall
which was somehow less grandiose than my own follow-on designs or,
failing that, to significantly revamp sysinstall itself.  The fact
that nobody has stepped up to the plate has, I feel, nothing to do
with vaporware, it has to do with certain problems simply being icky
and unpleasant to deal with.  If such was not the case, you'd think
one of the other *BSDs would have done it if not us.

Let's also not forget that Caldera had to PAY Trolltech to do their
fancy installer and then Red Hat came along and substantially pinched
off of that one, so even the vastly better-funded and staffed Linux
projects haven't really managed to crack the nut just on volunteer
labor alone.

G.  Hot button. :)

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: $B$O$8$a$^$7$F!#(B

[Jun Kuriyama]

At 26 Oct 2000 20:37:48 GMT,
Rogier R. Mulhuijzen [EMAIL PROTECTED] wrote:
 Does this look like english to anyone and is my mailer messed, or is this 
 gobbledegook to anyone not using Outlook + japanese character set?

That is spam like a "get money fast!" written in Japanese.  That is
not related to FreeBSD so please ignore.


-- 
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
 [EMAIL PROTECTED] // FreeBSD Project


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: entropy reseeding is totally broken

[Doug Barton]

David O'Brien wrote:
 
 On Thu, Oct 26, 2000 at 02:25:58PM -0700, Matt Dillon wrote:
  /etc/rc already assumes that /var is writable.  I recommend that you make
  that assumption by default... have the default entropy file be something
  like "/var/db/entropy_seed" and allow the administrator to override it
  with an RC variable.  You could allow the administrator to select a
  different entropy file and you could have another RC variable which allows
  the administrator to set a command which, when executed, returns an
  arbitrary sequence of bytes on its stdout to initialize entropy with.
 
 This is sweet!  Seems it would give us the full benefits of Mark's
 randomdev, and fit nicely with our normal configuration framework and
 gives good flexibility.

It also describes just what we have currently, except it misses the
advantages of putting the entropy file on the root partition which makes
it available immediately, and doesn't have mounting races built in. 

Doug
-- 
"The dead cannot be seduced."
- Kai, "Lexx"

Do YOU Yahoo!?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

AMD broken in -current?

[Jordan Hubbard]

It use to work in early October, but now I get the following using
the stock (/etc/defaults/rc.conf) amd flags:

amd[321]: /host: mount: Operation not supported by device
amd[322]: /net: mount: Operation not supported by device
amd[321]: /host: mount: No such file or directory
amd[322]: /net: mount: No such file or directory
amd[321]: extra mkdirs required for /host
amd[321]: mount_amfs_toplvl: Operation not supported by device
amd[322]: extra mkdirs required for /net
amd[322]: mount_amfs_toplvl: Operation not supported by device
amd[320]: /host: mount (amfs_auto_cont): Operation not supported by device
amd[320]: /net: mount (amfs_auto_cont): Operation not supported by device

After which amd continues to run but is essentially useless since
it has no hooks into the filesystem.

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: ipfw question.

[David O'Brien]

On Thu, Oct 26, 2000 at 08:47:35PM -0700, Jordan Hubbard wrote:

 G.  Hot button. :)

Quite sorry, didn't mean to push any buttons.  But once again I just got
hit by having a anchient /stand/sysinstall not be able to find any
devices when I wanted to use it's Fdisk editor.  Way back when I wanted
to hook both sysinstall and the instalation of its manpage into `make
world', you said not to bother because it was going to be OBE'ed soon.
 
-- 
-- David  ([EMAIL PROTECTED])


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: AMD broken in -current?

[David O'Brien]

On Thu, Oct 26, 2000 at 09:04:45PM -0700, Jordan Hubbard wrote:
 It use to work in early October, but now I get the following using
 the stock (/etc/defaults/rc.conf) amd flags:

It works on my Oct 22nd world.
 
-- David  ([EMAIL PROTECTED])


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message