IP tunnel
Hello!
What about ${subj} in current?
Or maybe someone know how to make
ip tunnel on current using patches, tools, etc.?
Thanx.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: feedback on CD install of 4.0-RC2
On Fri, 18 Feb 2000 23:28:45 +0900, "Daniel C. Sobral" [EMAIL PROTECTED] said: Novice is ok, it's the other two that are problematic. Well, particularly "custom". "Custom" does not scare away anyone, and is actually actractive to Windows users. It should be called "death trap" or something like that... Huh? -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: repost of procfs crashes in -CURRENT (no html)..
Kernel:
===
FreeBSD karma.afterthought.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Mon Feb
14 23:00:42 GMT 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/KARMA i386
Background:
3 users. One with X running me, and two users running breakwidgets
binary testing script, which make use of a minimized version of the
"killall" perl script which reads procfs.
This crash appears to be the old one where when two processes read procfs
simultaneously, ugly things can happen. mdillon described this in more
depth to me once but I've since lost the e-mail. I posted similar crash
reports in late November early december. He suggested having my
programs "lock" procfs reads so only one could do it's killall function at
a time. Unfortunatly, the binary testing script is very time sensitive and
this would slow things down my current run-through is about 48 hours
paralleled on 4 machines
I don't believe that's the cause.
The kernel is a GENERIC one with ipv6, softupdates, and pcm added to it.
Crash #1:
=
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc014e194 in poweroff_wait (junk=0xc02b9480, howto=-871862272) at
../../kern/kern_shutdown.c:554
#2 0xc022d064 in vm_fault (map=0xc031ee28, vaddr=3423105024, fault_type=1
'\001', fault_flags=0) at ../../vm/vm_fault.c:240
#3 0xc02810d2 in trap_pfault (frame=0xcc136cc4, usermode=0,
eva=3423108180) at ../../i386/i386/trap.c:788
#4 0xc0280d37 in trap (frame={tf_fs = -871170032, tf_es = -871170032,
tf_ds = 16, tf_edi = -871142055, tf_esi = -871142025,
tf_ebp = -871141804, tf_isp = -871142160, tf_ebx = -872323392,
tf_edx = 0, tf_ecx = -872323392, tf_eax = -871859336,
tf_trapno = 12, tf_err = 0, tf_eip = -1072160861, tf_cs = 8,
tf_eflags = 66118, tf_esp = 0, tf_ss = 0})
at ../../i386/i386/trap.c:423
#5 0xc0181fa3 in procfs_dostatus (curp=0xcc145e00, p=0xcc0166c0,
pfs=0xc14abf60, uio=0xcc136eec)
at ../../miscfs/procfs/procfs_status.c:115
The fault is taken when trying to access the target process' p_stats which
resides in the u area. What's interesting here is the code checks P_INMEM
flag prior to accessing p_stats, so there shouldn't be a fault. My guess is
this is an embryonic process, the p_stats field is inherited from the corpse
of another process which points to no where. Would you print out p-p_stat
(not p_stats) and check if it is 1 (SIDL)? That would confirm my theory.
If this indeed is the case, the fix should be delaying setting P_INMEM flags
in fork() until after the u area is allocated. It maybe also a good idea to
skip embryonic processes in procfs altogether.
#6 0xc0182590 in procfs_rw (ap=0xcc136ea0) at
../../miscfs/procfs/procfs_subr.c:277
#7 0xc017dc0a in vn_read (fp=0xc14431c0, uio=0xcc136eec, cred=0xc1450700,
flags=0, p=0xcc145e00) at vnode_if.h:334
#8 0xc015ac50 in dofileread (p=0xcc145e00, fp=0xc14431c0, fd=6,
buf=0x8235000, nbyte=4096, offset=-1, flags=0)
at ../../sys/file.h:140
#9 0xc015ab57 in read (p=0xcc145e00, uap=0xcc136f80) at
../../kern/sys_generic.c:111
#10 0xc028167e in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077946820, tf_esi = 672915688,
tf_ebp = -1077946996, tf_isp = -871141420, tf_ebx = 672858084,
tf_edx = 672809512, tf_ecx = 136531968, tf_eax = 3,
tf_trapno = 0, tf_err = 2, tf_eip = 672818732, tf_cs = 31, tf_eflags
= 659, tf_esp = -1077947040, tf_ss = 47})
at ../../i386/i386/trap.c:1055
Crash #2:
=
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc014e194 in poweroff_wait (junk=0xc02b9480, howto=-873472000) at
../../kern/kern_shutdown.c:554
#2 0xc022d064 in vm_fault (map=0xc031ee28, vaddr=3421495296, fault_type=1
'\001', fault_flags=0) at ../../vm/vm_fault.c:240
#3 0xc02810d2 in trap_pfault (frame=0xcbe0ccc4, usermode=0,
eva=3421498452) at ../../i386/i386/trap.c:788
#4 0xc0280d37 in trap (frame={tf_fs = -874512368, tf_es = -874512368,
tf_ds = 16, tf_edi = -874459817, tf_esi = -874459788,
tf_ebp = -874459564, tf_isp = -874459920, tf_ebx = -873997056,
tf_edx = 0, tf_ecx = -873997056, tf_eax = -873469064,
tf_trapno = 12, tf_err = 0, tf_eip = -1072160861, tf_cs = 8,
tf_eflags = 66118, tf_esp = 0, tf_ss = 0})
at ../../i386/i386/trap.c:423
#5 0xc0181fa3 in procfs_dostatus (curp=0xcbd7df20, p=0xcbe7dd00,
pfs=0xc154ac20, uio=0xcbe0ceec)
at ../../miscfs/procfs/procfs_status.c:115
#6 0xc0182590 in procfs_rw (ap=0xcbe0cea0) at
../../miscfs/procfs/procfs_subr.c:277
#7 0xc017dc0a in vn_read (fp=0xc1469200, uio=0xcbe0ceec, cred=0xc153d180,
flags=0, p=0xcbd7df20) at vnode_if.h:334
#8 0xc015ac50 in dofileread (p=0xcbd7df20, fp=0xc1469200, fd=5,
buf=0x8253000, nbyte=4096, offset=-1, flags=0)
at ../../sys/file.h:140
#9 0xc015ab57 in read (p=0xcbd7df20, uap=0xcbe0cf80) at
../../kern/sys_generic.c:111
#10 0xc028167e in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077945828, tf_esi =
Fix for -CURRENT breakage in libc_r
Please people. If you think you don't need a make world during a code freeze, then please at least read the patched files... Index: Makefile.inc === RCS file: /usr/home/ncvs/src/lib/libc_r/man/Makefile.inc,v retrieving revision 1.10 diff -u -r1.10 Makefile.inc --- Makefile.inc2000/02/18 05:31:26 1.10 +++ Makefile.inc2000/02/18 10:49:38 @@ -37,9 +37,6 @@ pthread_rwlockattr_init.3 \ pthread_rwlockattr_setpshared.3 \ pthread_self.3 \ - -MLINKS+=pthread_rwlock_wrlock.3 pthread_rwlock_trywrlock.3 -MLINKS+=pthread_rwlock_rdlock.3 pthread_rwlock_tryrdlock.3 \ pthread_setspecific.3 \ pthread_testcancel.3 \ sem_destroy.3 \ @@ -49,8 +46,10 @@ sem_post.3 \ sem_wait.3 -MLINKS+= pthread_cancel.3 pthread_setcancelstate.3 \ - pthread_cancel.3 pthread_getcancelstate.3 \ +MLINKS+= pthread_cancel.3 pthread_getcancelstate.3 \ + pthread_cancel.3 pthread_setcancelstate.3 \ + pthread_rwlock_rdlock.3 pthread_rwlock_tryrdlock.3 \ + pthread_rwlock_wrlock.3 pthread_rwlock_trywrlock.3 \ sem_open.3 sem_close.3 \ sem_open.3 sem_unlink.3 \ sem_wait.3 sem_trywait.3 -Jeremy -- FreeBSD - Because the best things in life are free... http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto progress! (And a Biiiig TODO list)
On Fri, 18 Feb 2000 09:43:03 +0200, Mark Murray [EMAIL PROTECTED] said: o A username may only be checked $number times per $timeperiod; after that, _all_ answers are silently converted to "no". Easier: a username may only be checked by a process running as $uid or by root. ... etc. There are possibilities for DoS attacks, but the daemon talks only to a Unix Domain Socket, so finding the perp is easy. And what happens when the daemon is dead, has crashed, or was never started? -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: Crypto progress! (And a Biiiig TODO list)
"Mark" == Mark Murray [EMAIL PROTECTED] writes: Mark o A username may only be checked $number times per Mark $timeperiod; after that, _all_ answers are silently Mark converted to "no". Umm, massive DOS hole. Mark o Daemon may only be invoked $number times per $timeperiod; Mark refuses to fork after that. Another massive DOS hole. Mark o Daemon will delay $timeperiod before returning answer. This is the correct way to deal with (perceived) attacks. Mark ... etc. There are possibilities for DoS attacks, but the Mark daemon talks only to a Unix Domain Socket, so finding the Mark perp is easy. Not if the daemon has shut itself off due to load (#1 or #2 above) and you aren't currently logged in to the box. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto progress! (And a Biiiig TODO list)
Lyndon Nerenberg wrote: "Mark" == Mark Murray [EMAIL PROTECTED] writes: Mark o A username may only be checked $number times per Mark $timeperiod; after that, _all_ answers are silently Mark converted to "no". Umm, massive DOS hole. Per username. If you publish your userlist, you're an idiot. The daemon should also immediately go into "breakin evasion mode" for all invalid usernames, answering the requests very slowly. Mark o Daemon may only be invoked $number times per $timeperiod; Mark refuses to fork after that. Another massive DOS hole. Right, this one doesn't fly. Mark o Daemon will delay $timeperiod before returning answer. This is the correct way to deal with (perceived) attacks. Please, not for a single valid request, or even two. Let's give the user the opportunity to login, and perhaps to goober their password once, before screwing them. Mark ... etc. There are possibilities for DoS attacks, but the Mark daemon talks only to a Unix Domain Socket, so finding the Mark perp is easy. Not if the daemon has shut itself off due to load (#1 or #2 above) and you aren't currently logged in to the box. Sure there is, it's called logging. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
strange code in ftp.c
Around ftp.c line 383 I see now:
} else if (code == 229) {
/* result for EPSV */
pflag = 1;
pflag = 100;
break;
} else
Please left only one 'pflag' assignment.
--
Andrey A. Chernov
[EMAIL PROTECTED]
http://nagual.pp.ru/~ache/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
No getty on ttyd0 after install on serial port ??
Hi, I just installed a box (2208 -CURRENT snapshot) using a serial console, worked fine (a bit slow in redrawing), but after booting the installed system there was no getty on the serial port ... /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work:Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek@ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-RC Broken driver?: matcd
On Mon, 14 Feb 2000, Jake Burkholder wrote: On Mon, Feb 14, 2000 at 02:39:09PM -0700, Doug Russell wrote: Does anyone have a Panasonic 526/563 CD-ROM drive working under 4.0-C? I have not had one working for may weeks, however, I wasn't sure if it was a hardware problem here, or something. 3.4 still finds them, so I beleive it is something with the move to newbus or driver compatibility shims. I think this driver is a casualty of newbus; mine stopped being probed last year when the conversion was made. I'm certain that is the problem, but there are supposed to be shims in place to make it work. They just don't seem to be working at all. I'm trying to fix it, I just can't find where it's broken! :) Later.. Doug To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tentitive complete patch for MAP_GUARDED available
Ok, this time for sure... version 3 of the MAP_GUARDED patch is out. http://www.backplane.com/FreeBSD4/ http://www.backplane.com/FreeBSD4/guard-3.diff http://www.backplane.com/FreeBSD4/guard3.c MAP_GUARDED mmap(addr/NULL, len, prot, MAP_GUARDED, fd, offset) The offset field specifies the number of bytes at the base of the returned map which are guarded and should be a multiple of the system page size. Pages at the end of the map are not guarded (any more). MAP_STACK Works as per normal except that the per-process stack resource limit applies to each mmap() separately. MAP_GUARDED|MAP_STACK Useful combination to place guard page(s) at the beginning of a thread stack. Also in this patch set I optimized vm_map_entry creation during normal stack growth operations. Normally the system tries to chunk vm_map_entry allocation for stacks by SGROWSIZ, which is typically 128K. But now the vm_map_entry_insert() optimization is able to optimize standard stack growth, which means that the actual vm_map_entry creation is governed by the more generous vm.map_entry_blk_opt value (512K by default). I like this implementation a lot better. By removing the guard pages at the end of the map MAP_GUARDED|MAP_STACK operation is much, much more intuitive. You don't have to do a blessed thing to the threading code except change MAP_STACK to MAP_STACK|MAP_GUARDED, and bump up the size of the mmap() allocation to include what used to be the skipped 'dead' page. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FreeBSD-current question re: binutils
Hello,I'm Takehiro Suzuki,a FreeBSD user. :-) In article [EMAIL PROTECTED] [EMAIL PROTECTED] writes: It is available from http://www.bsdclub.org/~takehiro/binutils.tar.gz . I am taking a look at it now. Since you did not rename any of the bits (such as `as', `ld', etc..) what is the impact of installing this port? I correct it as following. /usr/local/bin/as - /usr/local/bin/as295 /usr/local/bin/ld - /usr/local/bin/ld295 /usr/local/bin/objcopy - /usr/local/bin/objcopy295 If source code is available from CVS automatically,Maxim's port is better. And such way to get source code is done in ports/openssh. Thanks, Takehiro Suzuki [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tentitive complete patch for MAP_GUARDED available
On Fri, Feb 18, 2000 at 11:05:31AM -0800, Matthew Dillon wrote: I also think that a single guard page at the base of the stack may be insufficient for some applications. I'm considering adding yet another field to vm_map_entry 'vm_pindex_t guard_pages' which allows the number of guard pages to be specified (we can use mmap()'s offset argument to pass the parameter). In general, a given number of guard pages is insufficient for some (perhaps non-existent) applications. The basic idea is to catch typical stack overflow. Trying to always catch stack overflow is not practical. Since this is a heuristic error detection technique, I'm not sure how much work/complexity it's worth to paramaterize the number of guard pages for each mapping. Jason To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pstat(8) depends on loader(8)???
Hi! Why then it works on 3.4-STABLE (booting without loader(8) and having kvm(3) programs like pstat(8) and top(1) working). What makes a difference here? On Sun, Feb 06, 2000 at 09:38:41PM -0500, Garrett Wollman wrote: On Mon, 7 Feb 2000 00:25:51 +0200, Ruslan Ermilov [EMAIL PROTECTED] said: If I boot with loader(8), everything is ok. Ideas? loader loads the kernel symbol table; boot2 does not. -GAWollman On Mon, Feb 07, 2000 at 03:22:36PM +1100, Bruce Evans wrote: On Mon, 7 Feb 2000, Ruslan Ermilov wrote: If I boot the system without loader(8), e.g. with /boot.config=kernel, or by interrupting boot blocks and typing /kernel, swapinfo(8) fails: swapinfo: undefined symbol: _numvnodes This is because the elf format puts static symbols in an out-of-the-way section, and the boot2 stage of the bootstrap loads sections naively. Static symbols end up in a place where the kernel linker can't find them. `numvnodes' is a static symbol... Global symbols are found correctly. This bug has affected ddb for more than a year. I don't believe in or use loader(8), and have "fixed" the problem in ddb by not using the kernel linker for ddb symbol lookup. This also fixes the nonexistence of ddb symbols on booting with -d. Bruce On Mon, Feb 07, 2000 at 10:14:29PM +0800, Peter Wemm wrote: Garrett Wollman wrote: On Mon, 7 Feb 2000 00:25:51 +0200, Ruslan Ermilov [EMAIL PROTECTED] said: If I boot with loader(8), everything is ok. Ideas? loader loads the kernel symbol table; boot2 does not. -GAWollman More to the point, a non-stripped kernel has *two* symbol tables. One that has the global symbols and is used for dynamic linking, and the other that has the debugging info in it including static symbols. loader(8) goes to a great deal of trouble to get the second table - it's very hard to get it when reading from a zlib decompression stream that can't be seek'ed. The ELF format defines a convenient 'load segment' table which defines (usually) two chunks of the file to be loaded into memory and at what addresses. The verbose symbol table is not part of this, but the global table is and we get it for free. Anyway, the correct fix is to make numvnodes global or to change it to a sysctl. Nothing that is referred to by the common libkvm applications should be static - this warning has been given before. running a strip on / kernel has the same effect as using boot2 - only global symbols are accessible. Cheers, -Peter -- Ruslan Ermilov Sysadmin and DBA of the [EMAIL PROTECTED]United Commercial Bank, [EMAIL PROTECTED] FreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6
I fixed it and other problems, and added another changes. (In
particular, I mistakenly left my testing part in router
case. Sorry.)
I'll attach the new diffs.
I still made more several fixes to IPv6 configuration scripts.
-changed the file rc.net6 to rc.network6
-changed the func net6_pass1 to network6_pass1
-changed several var name more unlikely to confilict
-changed if several sentenses in rc.network6 to case sentence
like in rc.network
-wrapped many var names by {}
-and other fixes
I believe now it successfully configure each of router and
host case, very well.
Please try it anyone interested.
Thanks,
Yoshinobu Inoue
Index: defaults/rc.conf
===
RCS file: /home/ncvs/src/etc/defaults/rc.conf,v
retrieving revision 1.48
diff -u -r1.48 rc.conf
--- defaults/rc.conf2000/02/06 19:25:00 1.48
+++ defaults/rc.conf2000/02/18 12:53:06
@@ -184,6 +184,32 @@
### Miscellaneous network options: ###
icmp_bmcastecho="NO" # respond to broadcast ping packets
+### IPv6 options: ###
+ipv6_enable="NO" # Set to YES to set up for IPv6.
+ipv6_network_interfaces="auto" # List of network interfaces (or "auto").
+ipv6_gateway_enable="NO" # Set to YES if this host will be a gateway.
+ipv6_router_enable="NO"# Set to YES to enable an IPv6 routing daemon.
+ipv6_router="/usr/sbin/route6d"# Name of IPv6 routing daemon.
+ipv6_router_flags="" # Flags to IPv6 routing daemon.
+#ipv6_router_flags="-l"# Example for route6d with only IPv6 site local
+ # addrs.
+#ipv6_network_interfaces="ed0 ep0" # Examples for router.
+ # Choose correct prefix value.
+#ipv6_prefix_ed0="fec0:::0001 fec0:::0002" # Examples for rtr.
+#ipv6_prefix_ep0="fec0:::0003 fec0:::0004" # Examples for rtr.
+prefixcmd_enable="YES" # Use prefix command to assigne router prefix.
+rtadvd_enable="NO" # Set to YES to enable an IPv6 router
+ # advertisement daemon.
+mroute6d_enable="NO" # Do IPv6 multicast routing.
+mroute6d_program="/usr/sbin/pim6dd"# Name of IPv6 multicast routing
+ # daemon.
+mroute6d_flags="" # Flags to IPv6 multicast routing daemon.
+gif_interfaces="NO"# List of GIF tunnels (or "NO").
+#gif_interfaces="gif0 gif1"# Examples typically for a router.
+ # Choose correct tunnel addrs.
+#gifconfig_gif0="10.1.1.1 10.1.2.1"# Examples typically for a router.
+#gifconfig_gif1="10.1.1.2 10.1.2.2"# Examples typically for a router.
+ipv6_default_interface="lo0" # Default output interface for scoped addrs.
##
### System console options #
Index: rc
===
RCS file: /home/ncvs/src/etc/rc,v
retrieving revision 1.210
diff -u -r1.210 rc
--- rc 2000/02/03 06:06:36 1.210
+++ rc 2000/02/18 12:53:07
@@ -191,6 +191,15 @@
network_pass1
fi
+case ${ipv6_enable} in
+[Yy][Ee][Ss])
+ if [ -r /etc/rc.network6 ]; then
+ . /etc/rc.network6 # We only need to do this once also.
+ network6_pass1
+ fi
+ ;;
+esac
+
# Mount NFS filesystems.
echo -n "Mounting NFS file systems"
mount -a -t nfs
Index: rc.network6
===
RCS file: rc.network6
diff -N rc.network6
--- /dev/null Fri Feb 18 03:29:51 2000
+++ rc.network6 Fri Feb 18 04:53:07 2000
@@ -0,0 +1,219 @@
+#! /bin/sh
+# $FreeBSD$
+
+# Note that almost all of the user-configurable behavior is no longer in
+# this file, but rather in /etc/defaults/rc.conf. Please check that file
+# first before contemplating any changes here. If you do need to change
+# this file for some reason, we would like to know about it.
+
+# IPv6 startup
+
+network6_pass1() {
+ echo -n 'Doing IPv6 network setup:'
+
+ case ${ipv6_gateway_enable} in
+ [Yy][Ee][Ss])
+ #
+ # list of interfaces, and prefix for interfaces
+ #
+ case ${ipv6_network_interfaces} in
+ [Aa][Uu][Tt][Oo])
+ ipv6_network_interfaces="`ifconfig -l`"
+ ;;
+ esac
+ ;;
+ *)
+ #
+ # manual configurations - in case ip6_gateway_enable=NO
+ # you can configure only single interface,
+ # as specification assumes that
+ # autoconfigured host has single interface only.
+ #
+ case ${ipv6_network_interfaces} in
+ [Aa][Uu][Tt][Oo])
+ ipv6_network_interfaces="`ifconfig -l \
+
Re: feedback on CD install of 4.0-RC2
Doug Barton wrote: "Jordan K. Hubbard" wrote: Hmmm. Odd, I've always noted the opposite. If you do the novice install (which everyone should if they're trying to test the "typical case"), I've always found the term "novice" to be a little off-putting. Perhaps "Standard Install" would be a better choice? Novice is ok, it's the other two that are problematic. Well, particularly "custom". "Custom" does not scare away anyone, and is actually actractive to Windows users. It should be called "death trap" or something like that... -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "If you consider our help impolite, you should see the manager." To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
repost of procfs crashes in -CURRENT (no html)..
Sorry about the html posting, it seems that Mozilla M13 decided to rape my
message. I hate html postings just as much as you do (thank god for
procmail filters), and will send this one using pine so Mozilla doesn't
try to rethink my e-mail for me.
Kernel:
===
FreeBSD karma.afterthought.org 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Mon Feb
14 23:00:42 GMT 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/KARMA i386
Background:
3 users. One with X running me, and two users running breakwidgets
binary testing script, which make use of a minimized version of the
"killall" perl script which reads procfs.
This crash appears to be the old one where when two processes read procfs
simultaneously, ugly things can happen. mdillon described this in more
depth to me once but I've since lost the e-mail. I posted similar crash
reports in late November early december. He suggested having my
programs "lock" procfs reads so only one could do it's killall function at
a time. Unfortunatly, the binary testing script is very time sensitive and
this would slow things down my current run-through is about 48 hours
paralleled on 4 machines
The kernel is a GENERIC one with ipv6, softupdates, and pcm added to it.
Crash #1:
=
(kgdb) bt
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc014e194 in poweroff_wait (junk=0xc02b9480, howto=-871862272) at
../../kern/kern_shutdown.c:554
#2 0xc022d064 in vm_fault (map=0xc031ee28, vaddr=3423105024, fault_type=1
'\001', fault_flags=0) at ../../vm/vm_fault.c:240
#3 0xc02810d2 in trap_pfault (frame=0xcc136cc4, usermode=0,
eva=3423108180) at ../../i386/i386/trap.c:788
#4 0xc0280d37 in trap (frame={tf_fs = -871170032, tf_es = -871170032,
tf_ds = 16, tf_edi = -871142055, tf_esi = -871142025,
tf_ebp = -871141804, tf_isp = -871142160, tf_ebx = -872323392,
tf_edx = 0, tf_ecx = -872323392, tf_eax = -871859336,
tf_trapno = 12, tf_err = 0, tf_eip = -1072160861, tf_cs = 8,
tf_eflags = 66118, tf_esp = 0, tf_ss = 0})
at ../../i386/i386/trap.c:423
#5 0xc0181fa3 in procfs_dostatus (curp=0xcc145e00, p=0xcc0166c0,
pfs=0xc14abf60, uio=0xcc136eec)
at ../../miscfs/procfs/procfs_status.c:115
#6 0xc0182590 in procfs_rw (ap=0xcc136ea0) at
../../miscfs/procfs/procfs_subr.c:277
#7 0xc017dc0a in vn_read (fp=0xc14431c0, uio=0xcc136eec, cred=0xc1450700,
flags=0, p=0xcc145e00) at vnode_if.h:334
#8 0xc015ac50 in dofileread (p=0xcc145e00, fp=0xc14431c0, fd=6,
buf=0x8235000, nbyte=4096, offset=-1, flags=0)
at ../../sys/file.h:140
#9 0xc015ab57 in read (p=0xcc145e00, uap=0xcc136f80) at
../../kern/sys_generic.c:111
#10 0xc028167e in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077946820, tf_esi = 672915688,
tf_ebp = -1077946996, tf_isp = -871141420, tf_ebx = 672858084,
tf_edx = 672809512, tf_ecx = 136531968, tf_eax = 3,
tf_trapno = 0, tf_err = 2, tf_eip = 672818732, tf_cs = 31, tf_eflags
= 659, tf_esp = -1077947040, tf_ss = 47})
at ../../i386/i386/trap.c:1055
Crash #2:
=
#0 boot (howto=256) at ../../kern/kern_shutdown.c:304
#1 0xc014e194 in poweroff_wait (junk=0xc02b9480, howto=-873472000) at
../../kern/kern_shutdown.c:554
#2 0xc022d064 in vm_fault (map=0xc031ee28, vaddr=3421495296, fault_type=1
'\001', fault_flags=0) at ../../vm/vm_fault.c:240
#3 0xc02810d2 in trap_pfault (frame=0xcbe0ccc4, usermode=0,
eva=3421498452) at ../../i386/i386/trap.c:788
#4 0xc0280d37 in trap (frame={tf_fs = -874512368, tf_es = -874512368,
tf_ds = 16, tf_edi = -874459817, tf_esi = -874459788,
tf_ebp = -874459564, tf_isp = -874459920, tf_ebx = -873997056,
tf_edx = 0, tf_ecx = -873997056, tf_eax = -873469064,
tf_trapno = 12, tf_err = 0, tf_eip = -1072160861, tf_cs = 8,
tf_eflags = 66118, tf_esp = 0, tf_ss = 0})
at ../../i386/i386/trap.c:423
#5 0xc0181fa3 in procfs_dostatus (curp=0xcbd7df20, p=0xcbe7dd00,
pfs=0xc154ac20, uio=0xcbe0ceec)
at ../../miscfs/procfs/procfs_status.c:115
#6 0xc0182590 in procfs_rw (ap=0xcbe0cea0) at
../../miscfs/procfs/procfs_subr.c:277
#7 0xc017dc0a in vn_read (fp=0xc1469200, uio=0xcbe0ceec, cred=0xc153d180,
flags=0, p=0xcbd7df20) at vnode_if.h:334
#8 0xc015ac50 in dofileread (p=0xcbd7df20, fp=0xc1469200, fd=5,
buf=0x8253000, nbyte=4096, offset=-1, flags=0)
at ../../sys/file.h:140
#9 0xc015ab57 in read (p=0xcbd7df20, uap=0xcbe0cf80) at
../../kern/sys_generic.c:111
#10 0xc028167e in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077945828, tf_esi = 136638564,
tf_ebp = -1077946004, tf_isp = -874459180, tf_ebx = 672858084,
tf_edx = 672809512, tf_ecx = 136654848, tf_eax = 3,
tf_trapno = 0, tf_err = 2, tf_eip = 672818732, tf_cs = 31, tf_eflags
= 663, tf_esp = -1077946048, tf_ss = 47})
at ../../i386/i386/trap.c:1055
#11 0xc0276646 in Xint0x80_syscall ()
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: repost of procfs crashes in -CURRENT (no html)..
The real solution is to make killall(1)s funtionality part of kill(1) and avoid reading /proc so that we don't even have to mount /proc. Poul-Henning In message [EMAIL PROTECTED], Thomas Stromberg writes: 3 users. One with X running me, and two users running breakwidgets binary testing script, which make use of a minimized version of the "killall" perl script which reads procfs. This crash appears to be the old one where when two processes read procfs simultaneously, ugly things can happen. -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Rc2 install
I've come to the conclusion that the -current stuff really doesn't install on an 8 Meg machine anymore. I have an old 486/66 machine I'm using to play with the current-RC's, and it consistantly dies loading the 'bin' stuff. This isn't really a complaint -- after the load boot cycle, there is only 2.4M free according to the boot messages, so I can see why this would fill up. (I wound up loading the drive on another box that usually drives my printer, 386/25 and 24M, talk about S.L.O.W). And it can't quite compile a kernel in one go, either. Perhaps the release notes, or hardware file need to note you really do need more than 8M ? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
break in libcrypto?
Was wondering if anyone else was seeing this one. I'm following the jail(8) build directions on the 02-14 snapshot. I've had the build directions work previously, so I'm a little puzzled. During the make all phase, I get the errors below. I cvsup'd this morning, but still get the same results. Here's the output from make all: cc -fpic -DPIC -O -pipe -DTERMIOS -DANSI_SOURCE -DNO_IDEA -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DL_ENDIAN -DDEVRANDOM=\"/dev/urandom\" -DNO_RSA -DNO_SSL2 -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/cversion.c -o cversion.So /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/cversion.c:64: buildinf.h: No such file or directory /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/cversion.c:64: buildinf.h: No such file or directory /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/cversion.c:64: buildinf.h: No such file or directory *** Error code 1 *** Error code 1 *** Error code 1 3 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: break in libcrypto?
A further data point: I was building with a -j, so maybe there's a dependency mixup with the beforedepend target? If I manually cd to the directory and do a make beforedepend, things continue naturally from there. On Fri, 18 Feb 2000, Robert Watson wrote: Was wondering if anyone else was seeing this one. I'm following the jail(8) build directions on the 02-14 snapshot. I've had the build directions work previously, so I'm a little puzzled. During the make all phase, I get the errors below. I cvsup'd this morning, but still get the same results. Here's the output from make all: cc -fpic -DPIC -O -pipe -DTERMIOS -DANSI_SOURCE -DNO_IDEA -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DL_ENDIAN -DDEVRANDOM=\"/dev/urandom\" -DNO_RSA -DNO_SSL2 -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/cversion.c -o cversion.So /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/cversion.c:64: buildinf.h: No such file or directory /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/cversion.c:64: buildinf.h: No such file or directory /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/cversion.c:64: buildinf.h: No such file or directory *** Error code 1 *** Error code 1 *** Error code 1 3 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto progress! (And a Biiiig TODO list)
"Garrett" == Garrett Wollman [EMAIL PROTECTED] writes: Garrett And what happens when the daemon is dead, has crashed, or Garrett was never started? You incorporate my patches to inetd that teach it to listen on named sockets, and then run the daemon from there in wait mode. If inetd dies you're pretty much hosed, anyway. --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto progress! (And a Biiiig TODO list)
On Fri, 18 Feb 2000 09:30:43 -0700, Lyndon Nerenberg [EMAIL PROTECTED] said: You incorporate my patches to inetd that teach it to listen on named sockets, and then run the daemon from there in wait mode. If inetd dies you're pretty much hosed, anyway. Think ``single-user mode''. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: feedback on CD install of 4.0-RC2
On Fri, Feb 18, 2000 at 11:28:45PM +0900, Daniel C. Sobral wrote: Novice is ok, it's the other two that are problematic. Well, particularly "custom". "Custom" does not scare away anyone, and is actually actractive to Windows users. It should be called "death trap" or something like that... I'm actually scared by "novice" because it would be inflicting on me defaults I would almost probably not want. I never run anything but "custom", and I suspect many people do the same. -- Anatoly Vorobey, [EMAIL PROTECTED] http://pobox.com/~mellon/ "Angels can fly because they take themselves lightly" - G.K.Chesterton To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto progress! (And a Biiiig TODO list)
"Garrett" == Garrett Wollman [EMAIL PROTECTED] writes: You incorporate my patches to inetd that teach it to listen on named sockets, and then run the daemon from there in wait mode. If inetd dies you're pretty much hosed, anyway. Garrett Think ``single-user mode''. In single user mode you're root by definition. If init wants roots password before going single user it can certainly go directly to the password file. (It's really no different than if you're serving up passwords via NIS.) --lyndon To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto progress! (And a Biiiig TODO list)
Another technique that could be used, and gets discussed occasionally on -security, is passing authentication information via ancillary data transfer on UNIX domain sockets. You could limit the effectiveness of DOS attacks by rate limiting per-uid, for example. It should be noted that both the old and new schemes are subject to denial of service--the old due to locking, and the new due to socket/IPC limits, among other things. I would argue, however, that the new mechanism reduces risk as it would allow us to remove the setuid bit from a number of binaries, instead relying on a single auditable code base in the password file manager. If we plan to move to more daemons using IPC to communicate in this style, we might want to think about consistency guidelines for doing this. For example, mandating an LPC structure of some sort, or managing parallelism on a single pipe, etc. Also, documenting techniques that tend to reduce the risk of denial of service for daemons offering IPC services. Robert On Fri, 18 Feb 2000, Lyndon Nerenberg wrote: "Mark" == Mark Murray [EMAIL PROTECTED] writes: Mark o A username may only be checked $number times per Mark $timeperiod; after that, _all_ answers are silently Mark converted to "no". Umm, massive DOS hole. Mark o Daemon may only be invoked $number times per $timeperiod; Mark refuses to fork after that. Another massive DOS hole. Mark o Daemon will delay $timeperiod before returning answer. This is the correct way to deal with (perceived) attacks. Mark ... etc. There are possibilities for DoS attacks, but the Mark daemon talks only to a Unix Domain Socket, so finding the Mark perp is easy. Not if the daemon has shut itself off due to load (#1 or #2 above) and you aren't currently logged in to the box. --lyndon Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
pccardd and mapping memory descriptors
Hi,
I'm writing a driver that talks to a card that has some SRAM.
In the driver I'm trying to get a handle to the memory by doing the
following:
rid = 0;
sc-mem = bus_alloc_resource(dev, SYS_RES_MEMORY, rid,
0ul, ~0ul, 0, RF_ACTIVE);
which fails. Treking through the kernel and userland, I've decided
that what's missing is that pccardd never configures the memory region
using ioctl(PIOCSMEM). It never does that because the
code block in assign_io() that determines that the card does have a
memory descriptor, doesn't set the MEM_ASSIGNED bit in sp-flags.
I believe setting MEM_ASSIGNED is the proper fix and attached is the
one line patch.
-Ted
PS: anybody know why cardaddr is set to 16k?
Index: cardd.c
===
RCS file: /home/ncvs/src/usr.sbin/pccard/pccardd/cardd.c,v
retrieving revision 1.46
diff -c -r1.46 cardd.c
*** cardd.c 2000/01/26 17:53:59 1.46
--- cardd.c 2000/02/18 01:30:25
***
*** 487,492
--- 487,493
sp-config-driver-mem = sp-mem.addr;
}
sp-mem.cardaddr = 0x4000;
+ sp-flags |= MEM_ASSIGNED;
if (debug_level 0) {
logmsg("Using mem addr 0x%x, size %d, card addr 0x%x\n",
sp-mem.addr, sp-mem.size, sp-mem.cardaddr);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
HELP! Can not build kernel ... :-(
Hello. I followed up the stuff posted here and this evening I want to change one of our smaller server towards FBSD 4.0. Got the CD, have a complete new source tree cvsuped this day and now I make a cd /sys/i386/conf ... Within this directory, I only have the GENERIC, LINT NEWCARD files and my own system's configuration file for building kernel. When typing config MACHINE-NAME the command exits with error config: can't open ../conf/devices.i386 Well, theses files have gone? I thought this could be an cvsupdate error, so I installed the stuff for /sys again from CD. The same! What's new? What's the problem? I got the ISO Image of 4.0-RC2-2214 and cvsupdated today. Can anybody help? Gruss O. Hartmann --- [EMAIL PROTECTED] Klimadatenserver des IPA, Universitaet Mainz Netzwerk- und Systembetreuung To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tentitive complete patch for MAP_GUARDED available
... Resource limits are still an issue. It turns out that the MAP_STACK code does not deal with the stack resource limit well at all -- sometimes it catches it, sometimes it doesn't. In what sense? My recollection is that resource limits are enforced on the "regular" process stack but not (except perhaps by accident of placement) on other stacks, such as those created by pthreads. At a higher level, it's not been obvious to me how the resource limit on stack size should be interpreted in a multithreaded program. In other words, I don't see one interpretation as obviously best, much less correct. At least three possibilies are: 1. It represents the maximum size of the "legacy" process stack and nothing else, which is what the code currently implements. (pthreads stacks are bounded by other means.) 2. It represents the maximum size of each and every stack, whether it's the "legacy" process stack or for example a pthreads stack. 3. It represents the sum of the size of all of the stacks. There are problems/drawbacks to each and every possibility. So, in conclusion, I think the first order of business is to determine what semantics (1) there may be good precedent for and (2) that threads programmers are comfortable with. Alan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Broken FTP
On Thu, Feb 17, 2000 at 06:06:22PM +0900, Yoshinobu Inoue wrote: But maybe it is better to print out the first error, as the fact? I have nothing against EPSV itself, I am against additional verbosity and performance degradation since it is tried before _each_ command. OK I'll change not to try it once it fails. It seems your last patch _not_ fix the problem. Now I got: ftp dir 500 'EPSV': command not understood. on first 'dir' command issued. This is with wu-ftpd. Remember that different ftpd's could have slightly different format for response so you should not relay on it much. Could you please try EPSV automatically on _login_ and eat predictable response instead of trying on first user command? In that way you can reflect EPSV-able status in ftp's 'status' command to give user info is remote ftpd EPSV-compatible or not, as I already describe in previous messages. -- Andrey A. Chernov [EMAIL PROTECTED] http://nagual.pp.ru/~ache/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: feedback on CD install of 4.0-RC2
it makes sense to slice it that way. Also, as far as teaching new users how to install it, I _always_ show them the custom route. While this may sound harsh, its used to familarize them with all of sub-components, and I really kinda wish you'd point them to Novice^H^H^H^H^HStandard instead since it does more than be a bit more verbose, it also makes sure that all the appropriate steps are covered and prevents even relatively skilled people from hanging themselves. Let's take the case someone recently reported: He went and added a user or two using the user configuration tool, THEN went and configured X and the default desktop. Since the default desktop configuration writes the new skeleton files, adding the user(s) first means they all get the stock twm environment since the Desktop config tool is hardly going to go back retroactively and frob every user it can find on the system - that would be evil and bad even if I wanted to add the code to do this. Using the Standard installation, you're presented with all the appropriate checklist items in the *right order* so you don't shoot parts of your anatomy off like this. I will also say here and now that even I use the Standard installation since I don't like having to remember all the canonical steps in setting up a "stock" system and if anybody should remember them, it should be me - I've probably installed FreeBSD at least 50,000 times. :-) Do your friends a favor, point them at the now-not-so-embarassingly-named Standard installation as a matter of course. Custom installation is for those who both understand what they're doing and what they're *not* doing as a consequence of using it. As our desktop friend proved, not even those who think they know the full set of "nots" can escape being proven wrong by Custom. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Rc2 install
Perhaps the release notes, or hardware file need to note you really do need more than 8M ? The CD boxes all say 16MB and the release notes/hardware guide don't say anything at all about this. :) - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tentitive complete patch for MAP_GUARDED available
: : ... :Resource limits are still an issue. It turns out that the :MAP_STACK code does not deal with the stack resource limit :well at all -- sometimes it catches it, sometimes it doesn't. : :In what sense? My recollection is that resource limits are :enforced on the "regular" process stack but not (except :perhaps by accident of placement) on other stacks, such as :those created by pthreads. It's because the threads library is allocating the thread stacks *ON* the user stack. Stacks created with MAP_STACK, including the user stack, are not entirely reserved at creation time. So if you have an 8m stack resource limit your user stack is actually only as large (growing from the top down) as the lowest address you have yet allocated from it. The kernel can't tell the difference between the default user stack and new MAP_STACK stacks the threads library allocates when they fall within the resource limit. On the otherhand if you mmap a stack well outside the resource limit, the kernel doesn't care either. It's only when you try to 'grow' a stack (any MAP_STACK stack) that is sitting within the resource such that it would grow beyond the resource limit that an error is generated. :At a higher level, it's not been obvious to me how the resource limit :on stack size should be interpreted in a multithreaded program. In :other words, I don't see one interpretation as obviously best, much :less correct. At least three possibilies are: : :1. It represents the maximum size of the "legacy" process stack :and nothing else, which is what the code currently implements. :(pthreads stacks are bounded by other means.) : :2. It represents the maximum size of each and every stack, whether :it's the "legacy" process stack or for example a pthreads stack. : :3. It represents the sum of the size of all of the stacks. : :There are problems/drawbacks to each and every possibility. : :So, in conclusion, I think the first order of business is :to determine what semantics (1) there may be good precedent :for and (2) that threads programmers are comfortable with. : :Alan I think the issue is plain and simply that our implementation is broken. I think the resource limit should only apply to the main user stack and not to any old MAP_STACK one happens to mmap(). Thread stacks should not in any way fall under the system stack resource. It just doesn't apply. I also think that a single guard page at the base of the stack may be insufficient for some applications. I'm considering adding yet another field to vm_map_entry 'vm_pindex_t guard_pages' which allows the number of guard pages to be specified (we can use mmap()'s offset argument to pass the parameter). I also think we should get rid of the avail_ssize field in vm_map_entry and instead simply have a flag for the main user stack's vm_map_entry that allows it to grow downward to be sized up to the resource limit in size. Should the resource limit apply to any MAP_STACK mapping (separately and independantly)? Yes, I think so. It shouldn't matter at all for threads but I can see using MAP_STACK mmaping's to dynamically load programs and run them (rather then fork/exec), in certain cases. What do you think? The above changes would be easy to add, I've already done the hard work of optimizing the VM system. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HELP! Can not build kernel ... :-(
On Fri, Feb 18, 2000 at 07:11:00PM +0100, O. Hartmann wrote: Hello. I followed up the stuff posted here and this evening I want to change one of our smaller server towards FBSD 4.0. Got the CD, have a complete new source tree cvsuped this day and now I make a cd /sys/i386/conf ... Within this directory, I only have the GENERIC, LINT NEWCARD files and my own system's configuration file for building kernel. When typing config MACHINE-NAME the command exits with error config: can't open ../conf/devices.i386 Well, theses files have gone? I thought this could be an cvsupdate error, so I installed the stuff for /sys again from CD. The same! What's new? What's the problem? I got the ISO Image of 4.0-RC2-2214 and cvsupdated today. Can anybody help? They have been removed. You need up update your config and genassym before you can build a 4.0 kernel. Also, I hope your kernel config file is based on a new config and isn't just a copy of a 3.x config since that likely won't work. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: break in libcrypto?
On Fri, 18 Feb 2000, Robert Watson wrote: A further data point: I was building with a -j, so maybe there's a dependency mixup with the beforedepend target? If I manually cd to the directory and do a make beforedepend, things continue naturally from there. What value of -j? I've built fine with -j4 and -j8, but this says that the depend target hadn't run before the all target did. Did you 'make depend' before building? Kris "How many roads must a man walk down, before you call him a man?" "Eight!" "That was a rhetorical question!" "Oh..then, seven!" -- Homer Simpson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Broken FTP
OK I'll change not to try it once it fails. It seems your last patch _not_ fix the problem. Now I got: ftp dir 500 'EPSV': command not understood. on first 'dir' command issued. This is with wu-ftpd. Remember that different ftpd's could have slightly different format for response so you should not relay on it much. Could you please try EPSV automatically on _login_ and eat predictable response instead of trying on first user command? In that way you can reflect EPSV-able status in ftp's 'status' command to give user info is remote ftpd EPSV-compatible or not, as I already describe in previous messages. But the change to do it seems to be not so simple as can be done in this code freeze phase. (At least with my level of understanding of ftp code.) Somewhat no printing version of getreply() seems to be necessary. Could you please create the patch which seems to be safely committed? That will be very much help. Thanks, Yoshinobu Inoue Andrey A. Chernov [EMAIL PROTECTED] http://nagual.pp.ru/~ache/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IPv6
The only changes I have for you are small typos... /etc/rc.conf: "assigne router prefix" should be: "assign router prefix" /etc/rc.network6: "if you instead want to route such packets to a "default" interface": Looks to me like this comment is not applicable anymore. "Enable Router Renumbering, unicaset case" should be: "Enable Router Renumbering, unicast case" Unfortunately I can't give you any good comments about functionality...I want to do a buildworld/installworld on my test box to pick up all of the changes regarding scoped addresses...I'm doing a cvs update now to bring the sources over. Once I'm back up and running, I'll let you know how it works for me. Thanks! Bruce. PGP signature
Re: break in libcrypto?
On Fri, 18 Feb 2000, Robert Watson wrote: What value of -j? I've built fine with -j4 and -j8, but this says that the depend target hadn't run before the all target did. Did you 'make depend' before building? Nope -- my make was in the top level /usr/src tree, in the form of ``make -j 3 all''. It was only after the build failed that I cd'd to the directory, looked around, and did a make beforedepend to generate the missing include file. I don't know that much about the current build infrastructure--was just following Poul's building instructions from jail(8). You need to make depend first..perhaps the makefile could be improved (I'm no guru) but I've seen lots of other parts of the tree sporadically break if you don't do this. Kris "How many roads must a man walk down, before you call him a man?" "Eight!" "That was a rhetorical question!" "Oh..then, seven!" -- Homer Simpson To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tentitive complete patch for MAP_GUARDED available
Ok, I just finished making the modifications, essentially rewriting vm_map_growstack() and vm_map_stack(). http://www.backplane.com/FreeBSD4/ http://www.backplane.com/FreeBSD4/guard-3.diff http://www.backplane.com/FreeBSD4/guard3.c Here are the proposed semantics: * When you mmap() with MAP_STACK, the stack you map is limited to the number of bytes specified in the mmap() AND ALSO limited by the process stack resource limit (on a per-mmap basis). That is, *EACH* MAP_STACK mmaping may utilize up to the process stack resource and no more, even if you mmap a larger area. This may be a little controversial but it's basically how the kernel allocates the default user stack -- it allocates the maximum kernel limit and assumes the stack will be limited by the stack resource. I think it could be useful for debugging, too. (Also, with MAP_STACK, a fixed address and an anonymous mmap is implied, and the mmap() will fail if the specified region already contains mappings). * When you mmap() with MAP_GUARDED, the offset field in the mmap() call specifies the number of guard pages at the beginning and end of the map. If you specify 0, you don't get any guard pages (which is kinda useless). Normally getpagesize() bytes is specified. An anonymous mmap is implied. * When you mmap() with MAP_GUARDED|MAP_STACK, you get a guarded stack. The system will not create a growable stack, though, it pre-reserves the space (but, of course, does not allocate physical pages for things you haven't touched). The new semantics use the offset field in the mmap to indicate the number of guard pages at the beginning and end of the map, in bytes, so the semantics of MAP_GUARDED mmap's has been changed somewhat. You nominally have to call it with an offset of getpagesize() to get the 'single guard page at beginning and end' behavior. So, to make the threads library use this you mmap MAP_STACK|MAP_GUARDED with an offset of getpagesize() (or more). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: IP tunnel
Hello!
What about ${subj} in current?
Or maybe someone know how to make
ip tunnel on current using patches, tools, etc.?
Thanx.
Maybe there are several ways, and one thing I know is gif
interface recently added.
It can be used by adding following entry in your kernel
config. (Any number can be specified.)
pseudo-device gif 4
It can do,
IPv6 over IPv4
IPv4 over IPv6
IPv4 over IPv4
IPv6 over IPv6
tunnelings.
To configure outer addresses, use gifconfig, like,
gifconfig gif0 10.1.1.1 10.1.1.2
You need to do opposite on the 10.1.1.2 machine.
And to configure inner addresses, just use ifconfig for gif
interfaces.
Also please take care not to create infinite loop tunnel, when
you do,
IPv4 over IPv4
IPv6 over IPv6
Please check man for gifconfig for details.
Yoshinobu Inoue
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: freezing
On Fri, 18 Feb 2000, Adam wrote: I do not mean to throw blame on freebsd at all (unless tons of people also see this) but I had a freeze earlier today. I had several windows open, netscape, and was compiling qt2 with not much disk activity at all when it just froze hard as a rock in all ways I can think of. If it happens again I'll look into ddc and serial console or perhaps recreating on normal console. I dont suspect hardware fault but I wouldn't dismiss it. On Thu, 17 Feb 2000, Joao Pedras wrote: Hello all While making -j 4 buildworld and moving a netscape window, everything frozen. Happens often if do other things while cpu and disk are very active. Happens quite often. Anyone else has noticed this ? I have had a number of freezes, during a rm -rf and a find at the same time, during a cvs checkout, during a fsck on reboot. The fsck caused a message about an "SCB Timeout" I think. I have returned to slightly older 4.0-Current kernel and was going to build a new kernel. I can try to get more information this evening, if anybody is interested. For me the trigger seems to be heavy disk activity. configuration summary: K6-2 333, 80MB, aha2940(I think, adaptec PCI ultra), 4 2GB segate SCSI drives. Brian Beattie| The only problem with [EMAIL PROTECTED] | winning the rat race ... www.aracnet.com/~beattie | in the end you're still a rat To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto progress! (And a Biiiig TODO list)
In message [EMAIL PROTECTED], Wes Peters wrote: } Lyndon Nerenberg wrote: } } "Mark" == Mark Murray [EMAIL PROTECTED] writes: } } Mark o A username may only be checked $number times per } Mark $timeperiod; after that, _all_ answers are silently } Mark converted to "no". } } Umm, massive DOS hole. } } Per username. If you publish your userlist, you're an idiot. The } daemon should also immediately go into "breakin evasion mode" for } all invalid usernames, answering the requests very slowly. You don't have to publish a userlist in order for some of that kind of information to leak out. Besides, by answering very slowly for invalid usernames you just gave the bad guys a way to deduce your user list anyway. -- Jon Hamilton [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tentitive complete patch for MAP_GUARDED available
:Currently, the threads library only creates one guard page :at the top (or bottom depending on how you look at it) of :each threads stack (for stacks of default size). Thread :stacks are allocated in sequential zones, so they are always :placed on top of the previous threads stack, and thus already :have a guard page below the stack. : :Correct me if I'm wrong, but using MAP_STACK|MAP_GUARDED :would allocate one additional guard page for each threads :stack. : :DanE. Correct. At the moment MAP_GUARDED is a 'generic' guarding flag and makes no assumptions about the areas being adjoining. It doesn't cost us anything. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: feedback on CD install of 4.0-RC2
"Jordan K. Hubbard" [EMAIL PROTECTED] writes: I really kinda wish you'd point them to Novice^H^H^H^H^HStandard instead since it does more than be a bit more verbose, it also makes sure that all the appropriate steps are covered and prevents even relatively skilled people from hanging themselves. Does this mean that this option should be called `guided'? I know a little bit about Unix but haven't installed FreeBSD more than five times or so. And I always thought that the novice install meant that I didn't get as many choices... kai -- ~/.signature: No such file or directory To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: break in libcrypto?
On Fri, 18 Feb 2000, Kris Kennaway wrote: On Fri, 18 Feb 2000, Robert Watson wrote: What value of -j? I've built fine with -j4 and -j8, but this says that the depend target hadn't run before the all target did. Did you 'make depend' before building? Nope -- my make was in the top level /usr/src tree, in the form of ``make -j 3 all''. It was only after the build failed that I cd'd to the directory, looked around, and did a make beforedepend to generate the missing include file. I don't know that much about the current build infrastructure--was just following Poul's building instructions from jail(8). You need to make depend first..perhaps the makefile could be improved (I'm no guru) but I've seen lots of other parts of the tree sporadically break if you don't do this. Ok, is this a make depend in the top /usr/src, or in directories thjat specifically require it. Or more practically speaking--I want the directions in jail(8) to work every time. :-) How can this be fixed? They currently read: Setting up a Jail Directory Tree This shows how to setup a jail directory tree: D=/here/is/the/jail cd /usr/src make hierarchy DESTDIR=$D make obj make all make install DESTDIR=$D cd etc make distribution DESTDIR=$D NO_MAKEDEV=yes cd $D/dev sh MAKEDEV jail cd $D ln -sf dev/null kernel Robert N M Watson [EMAIL PROTECTED] http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tentitive complete patch for MAP_GUARDED available
* When you mmap() with MAP_GUARDED|MAP_STACK, you get a guarded stack. The system will not create a growable stack, though, it pre-reserves the space (but, of course, does not allocate physical pages for things you haven't touched). The new semantics use the offset field in the mmap to indicate the number of guard pages at the beginning and end of the map, in bytes, so the semantics of MAP_GUARDED mmap's has been changed somewhat. You nominally have to call it with an offset of getpagesize() to get the 'single guard page at beginning and end' behavior. So, to make the threads library use this you mmap MAP_STACK|MAP_GUARDED with an offset of getpagesize() (or more). Currently, the threads library only creates one guard page at the top (or bottom depending on how you look at it) of each threads stack (for stacks of default size). Thread stacks are allocated in sequential zones, so they are always placed on top of the previous threads stack, and thus already have a guard page below the stack. Correct me if I'm wrong, but using MAP_STACK|MAP_GUARDED would allocate one additional guard page for each threads stack. DanE. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tentitive complete patch for MAP_GUARDED available
:Ok, I just finished making the modifications, essentially :rewriting vm_map_growstack() and vm_map_stack(). : : http://www.backplane.com/FreeBSD4/ : http://www.backplane.com/FreeBSD4/guard-3.diff : http://www.backplane.com/FreeBSD4/guard3.c Oops, withdrawn... I muffed it up. I'll get it up later today. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: tentitive complete patch for MAP_GUARDED available
On Fri, 18 Feb 2000, Matthew Dillon wrote: :Currently, the threads library only creates one guard page :at the top (or bottom depending on how you look at it) of :each threads stack (for stacks of default size). Thread :stacks are allocated in sequential zones, so they are always :placed on top of the previous threads stack, and thus already :have a guard page below the stack. : :Correct me if I'm wrong, but using MAP_STACK|MAP_GUARDED :would allocate one additional guard page for each threads :stack. : :DanE. Correct. At the moment MAP_GUARDED is a 'generic' guarding flag and makes no assumptions about the areas being adjoining. It doesn't cost us anything. Any problem if we overlay a previously MAP_GUARDED page with another (to save an extra guard page)? Dan Eischen [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ipv6 default in current ports?
I've come up against a number of ports lately assume IPv6 support if
you're running:
.if ${OSVERSION} = 400014
CONFIGURE_ARGS+= --enable-ipv6
.endif
... I don't see INET6 in my GENERIC kernel. This affects at least
net/mtr and lang/ruby.
Dave.
--
|David Gilbert, Velocet Communications. | Two things can only be |
|Mail: [EMAIL PROTECTED] | equal if and only if they |
|http://www.velocet.net/~dgilbert | are precisely opposite. |
=GLO
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: BIOS and PERC 2/SC (was Re: Perc 2/SC problems (aka MegaRAID 466) )
OK, I took a chance and flashed the card's BIOS to the latest from the AMI site I had been suspecting BIOS, as the readme.txt mentioned problems with newer motherboards. Lo and Behold, it seems to have done the trick amr0: AMI MegaRAID mem 0xe900-0xe93f irq 11 at device 12.1 on pci0 amr0: firmware GH6D bios 1.43 32MB memory amrd0: MegaRAID logical drive on amr0 amrd0: 17522MB (35885056 sectors) RAID 5 (optimal) As I mentioned, the card came as a Dell unit. I tried the latest BIOS from Dell, but that was a year old. The BIOS from megaraid.com 1.43, which is in there now *seems* to work so far At least I can now get a disklable on the drive and newfs the drive Hmm. I did some testing, and I can lock both the G6HC and G6HD firmware up within a few minutes. The Dell 3.00 firmware remains stable under the same load (20 simultaneous 'bonnie -s 100's). I'm fairly sure it's a firmware lockup - the SCSI bus is hung and usually the PCI bus as well. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
su(1) and PAM
Is it planned to make su(1) support authentication via PAM? -- Dominik - http://www.saargate.de/~domi/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ipv6 default in current ports?
On Fri, Feb 18, 2000 at 05:26:45PM -0500, David Gilbert wrote:
I've come up against a number of ports lately assume IPv6 support if
you're running:
.if ${OSVERSION} = 400014
CONFIGURE_ARGS+= --enable-ipv6
.endif
... I don't see INET6 in my GENERIC kernel. This affects at least
net/mtr and lang/ruby.
It doesn't need kernel support to build with ipv6 support. Trying
to use the ipv6 support without it in the kernel is the only problem.
-Chris
--
[EMAIL PROTECTED] [EMAIL PROTECTED]
Abbotsford, BC, Canada
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ipv6 default in current ports?
"Chris" == Chris Piazza [EMAIL PROTECTED] writes:
Chris On Fri, Feb 18, 2000 at 05:26:45PM -0500, David Gilbert wrote:
I've come up against a number of ports lately assume IPv6 support
if you're running:
.if ${OSVERSION} = 400014 CONFIGURE_ARGS+= --enable-ipv6 .endif
... I don't see INET6 in my GENERIC kernel. This affects at least
net/mtr and lang/ruby.
Chris It doesn't need kernel support to build with ipv6 support.
Chris Trying to use the ipv6 support without it in the kernel is the
Chris only problem.
Well... ruby refuses to build with IPv6 if it's not enabled and mtr
dies with a "cannot open socket".
In escence, both ports (and possibly others) don't work in 4.0 without
INET6 in your kernel.
Dave.
--
|David Gilbert, Velocet Communications. | Two things can only be |
|Mail: [EMAIL PROTECTED] | equal if and only if they |
|http://www.velocet.net/~dgilbert | are precisely opposite. |
=GLO
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: break in libcrypto?
On Fri, 18 Feb 2000, Robert Watson wrote:
Ok, is this a make depend in the top /usr/src, or in directories thjat
specifically require it. Or more practically speaking--I want the
directions in jail(8) to work every time. :-) How can this be fixed?
Specifically, 'make depend' in secure/lib/lib{crypto,ssl,rsaglue} and
secure/usr.bin/openssl, a covering set of which is 'make depend' in
/usr/src :-)
Kris
"How many roads must a man walk down, before you call him a man?"
"Eight!"
"That was a rhetorical question!"
"Oh..then, seven!" -- Homer Simpson
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Supported ways to do RSA/OpenSSL on 4.0?
On Fri, 18 Feb 2000, Robert Watson wrote:
I was pointed to you for questions regarding whether or not certain ports
would be working udner 4.0-RELEASE -- specifically, OpenSSH and related
applications which depend on SSL/RSA.
All of the ports which explicitly depend on openssl should be working on
all supported versions of FreeBSD, modulo screwups :) Jim Bloom has been
putting a lot of work into getting these working - I have a couple of
patches to commit, but they mostly seem to work fine as far as I've
heard.
However, Jordan mailed me this morning about a build problem with openssh
on a fresh installation which looks very strange - it's like the test for
a RSA-enabled openssl is falsely passing, which causes the build to die.
This may be the problem you're seeing - as yet I don't have any real clues
about why. Could you send me a build log from one of the failing ports as
well as the output of 'nm /usr/lib/libcrypto.a | grep RSA_free'? Is this a
fresh installation, i.e. with no older cruft possibly lying around?
Do we plan to provide a consistent and documented way for users of
FreeBSD to go from the RSA-disabled base library set to the
RSA-enabled set, and in a way that provides adequate instruction? I
get rather uninformative errors when trying to compile
See chapter 6.5 in the handbook.
OpenSSH, SSLproxy, and Apache13-modssl, none of which is discovered by the
ports mechanism, rather the application makefiles. While I understand
that you are not the maintainer for these ports,... :-)
It might be nice, for example, to have a stage in sysinstall for
crypto-configuration--it would also be accessible post-install, and would
provide easy access to install via package the underlying RSA libraries,
with appropriate documentation of licensing issues and confirmation of
location, etc. Presumably one could back-end this onto a set of ports or
packages, so there would be more scalable command line/scriptable
interface.
The packages already exist and are described in the handbook, except they
haven't yet made it onto the ftp site. You can pick them up from
http://www.freebsd.org/~kris/openssl in the meantime. Sysinstall support
is something I'd definitely like to see, but not something I have time (or
knowledge) to do right now.
I'll be adding some instructions to the release notes this weekend, and it
should be giving a helpful error message if you try and install a port
which requires RSA and you have a non-RSA library:
.if ${USE_OPENSSL} == RSA
_HASRSA= "`/usr/bin/nm /usr/lib/libcrypto.a | /usr/bin/grep RSA_free`"
.if empty(_HASRSA)
.BEGIN:
@${ECHO} "This port requires RSA crypto, which is not present in
your"
@${ECHO} "version of OpenSSL. Please see Chapter 6.5 in the
handbook"
@${ECHO} "for a description of the problem and alternative
solutions."
@${FALSE}
.endif
.endif
Kris
"How many roads must a man walk down, before you call him a man?"
"Eight!"
"That was a rhetorical question!"
"Oh..then, seven!" -- Homer Simpson
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Installing linux_base 6.1
: I am currently having a problem installing linux_base, both the port and the : package on -current. I used to lurk to discover these problems by browsing : the mailing list, but they are down. :-( : : I just cvsupped and rebuilt the world today and it still fails. Here are the : messages: : :Yes, I've seen this also. For some reason, either the linux_base :package or pkg_add is broken here, and I'm tending to suspect the :latter at this point since there shouldn't be any attempt to cd to :/compat, nowhere in the packing list does it say to do that. Methinks :a buffer is overflowing somewhere. : :- Jordan I had similar problems trying to install the latest linux_base onto a system which previously had the old (/compat/linux) version. I wound up having to rm -rf /compat/linux and /usr/compat/linux and then doing the make install, which worked. It created /usr/compat/linux and didn't seem to care that no /compat/linux existed. However, other linux programs (e.g. the linux netscape) still look in /compat so I had to create a softlink from /compat/linux to /usr/compat/linux in order for netscape to run. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
devices under 4.0
I recently upgraded from 3.2 to 4.0. I use an ide hard disk, and would like to know how to change over the devices. I created the new devices by copying over /usr/src/etc/MAKEDEV to a new /dev directory and running it, but it didn't create any ata* devices such as is shown in the kernel config file. It did make devices ada1, ada2, ada3, and ada4, which would correspond to the four slices on my disk, but if there are no freebsd partitions shown, such as ada4a, etc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Crypto progress! (And a Biiiig TODO list)
Jon Hamilton wrote: In message [EMAIL PROTECTED], Wes Peters wrote: } Lyndon Nerenberg wrote: } } "Mark" == Mark Murray [EMAIL PROTECTED] writes: } } Mark o A username may only be checked $number times per } Mark $timeperiod; after that, _all_ answers are silently } Mark converted to "no". } } Umm, massive DOS hole. } } Per username. If you publish your userlist, you're an idiot. The } daemon should also immediately go into "breakin evasion mode" for } all invalid usernames, answering the requests very slowly. You don't have to publish a userlist in order for some of that kind of information to leak out. Besides, by answering very slowly for invalid usernames you just gave the bad guys a way to deduce your user list anyway. And how exactly are they supposed to tell the difference between answering slowly due to breakin evasion vs. answering slowly because the system is a 386sx/16? You would want to answer all "mistakes" slowly, but valid logins quickly. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC [EMAIL PROTECTED] http://softweyr.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Big ATA problems
The latest ata commits left my system completely unbootable. No disks were probed. I have on the motherboard's Alladin controller: HP 4x4x24 CD burner as master primary channel 40x CD as slave primary channel HP Colorado 8 Gig ATAPI tape as master secondary channel On a Promise Ultra66: WDC AC29100D WDC AC32500H each on thier own channel. Here are the boot messages (I had to write them down) ata0-slave: WARNING: WAIT_INTR active=ATA_WAIT_READY ata0-slave: timeout waiting for intr ata0-slave: identify failed these were repeated once and when attempting to mount / no devsw(msgdev=0 bootdev=0xa20) no such device 'ad' Prior the the commit, the motherboard ide controllers were numbered ata0,1 and the Promise was ata2,3. After the commit it is switched around. Now the controllers probe as Promise ata0,1 and the motherboard as ata2,3. Bryan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
