Re: FS tuning (Was: File system gets too fragmented ???)
Joel Ray Holveck jo...@gnu.org writes: About five minutes ago, I realized that one problem is that I recently installed a new disk, and forgot to enable softupdates on it (doh!). From the little I know, I don't quite understand why softupdates is a tunefs parameter, instead of a mount flag. You shouldn't switch back and forth between soft updates and normal operation in a single mount session. Mount flags let you do that. Anyway, all you're actually intersted in is knowing if a crashed file system was running with soft updates before the crash, because it eliminates the need for fsck (all you need to do is recover blocks which are incorrectly marked as allocated; this can be done in the background on a live file system - maybe even by the fs code itself?) Maybe the right thing would be a soft updates bit similar to the dirty bit. You set the SU bit upon mounting a file system with soft updates, and clear it otherwise. If the user tries to mount a dirty SU file system, you silently clear the dirty bit, mount the file system and recover lost blocks in the background. If the user tries to mount a dirty non-SU file system, you refuse as usual. Can a fs with softupdates turned on in the superblock work on a non-softupdates kernel without trouble? Yes. I believe there might be a slight performance hit, but it shouldn't be too noticeable. If so, would it be a good idea to have newfs turn it on by default? No, I don't think there's much point in doing that before Kirk McKusick removes the restrictions on the soft updates code. When that happens, we can make soft updates non-optional and turn on soft updates on all file systems by default. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: UID Limits
Ayan George a...@kiwi.datasys.net writes: Yes, pwd_mkdb compares the UID with USHRT_MAX. I wonder if there is a macro that defines the maximum GID and UID like: It's just a warning which was put there because some software incorrectly stores UIDs in unsigned short ints rather than uid_ts and thus does not grok large UIDs. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: UID Limits
[gack, let's get the Cc: right this time around] Steve Ames st...@cioe.com writes: The question is What is the maximum UID?. Its either a 2 or 4 byte unsigned integer. The filesystem seems to accept 4, pwd_mkdb complains about larger than 2 but lets you do it... pwd_mkdb warns about UIDs greater than USHRT_MAX because some old (third-party) software stores UIDs in unsigned short ints instead of uid_t and therefore does not grok large UIDs. The warning is harmless (unless you run some of that old software) and should most certainly not be changed or removed. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Kernel config script:
Wes Peters w...@softweyr.com writes: David Scheidt wrote: I should point out that UNIX's suitably as a document processing enviornment is one of the reasons that UNIX received support from BTL management. The fact that it was stable, ran on cheap hardware, and a cool programing enviornment were bonuses. [...] The ongoing text processing work became one of several projects that were developed at Bell Labs on UNIX, but it was not the reason UNIX was created. Umm, how does UNIX's suitability as a document processing system is one of the reasons UNIX received support from BTL management translate into UNIX was created to run a word processor? DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: xl driver for 3Com
Dennis den...@etinc.com writes: We have thousands of boards installedmaking them work back to back in a non-standard configuration does not make the product *better*, particularly when working with someone who cant provide useful info on *why* it doesnt work. I wish I could stop what I was doing every time someone had a problem, but I dont have that kind of time. Wow... lemme pull out my replace-o-matic: We have thousands of FreeBSD installations. Making them work with broken hardware / software does not make the OS *better*, particularly when working with someone who can't provide useful info on *why* it doesn't work. I wish I could stop what I was doing every time someone had a problem, but I don't have that kind of time. Neat. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM: Undefined symbols at runtime
Matthew Hunt m...@astro.caltech.edu writes: Confusinger and confusinger. Somehow, perl and login, the two programs with which I had dynamic linking problems, had been stripped. I don't know how that happened, since I didn't do it. Using make install from their source directories installed them unstripped, as they should be. Do you perchance have something like INSTALL=install -s in your /etc/make.conf? DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
devstat_end_transaction: HELP!! busy_count for wd0 0 (-1)
I'm getting tons of these in an IDE-only box. They started appearing after I put in an IBM DTTA371010 to replace the old (and dying) Quantum Fireball ST. Trying to newfs a 9 GB file system on the IBM, newfs got wedged in physst. At that point I had to reset (since I ran newfs on the serial console in single-user mode, and could neither interrupt nor background it, I had no shell). Upon reboot, fsck -p produced a shitload of busy_count 0 messages. (newfs still gets wedged, btw) DES -- Dag-Erling Smorgrav - d...@ifi.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: devstat_end_transaction: HELP!! busy_count for wd0 0 (-1)
Dag-Erling Smorgrav d...@ifi.uio.no writes: I'm getting tons of these in an IDE-only box. They started appearing after I put in an IBM DTTA371010 to replace the old (and dying) Quantum Fireball ST. Following up on myself, the box just panicked (softdep_write_complete: lock held). DES -- Dag-Erling Smorgrav - d...@ifi.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: devstat_end_transaction: HELP!! busy_count for wd0 0 (-1)
Dag-Erling Smorgrav d...@ifi.uio.no writes: Dag-Erling Smorgrav d...@ifi.uio.no writes: I'm getting tons of these in an IDE-only box. They started appearing after I put in an IBM DTTA371010 to replace the old (and dying) Quantum Fireball ST. Following up on myself, the box just panicked (softdep_write_complete: lock held). Following up on myself again, a May 4 kernel (with the exact same configuration) works fine and dandy. The problems only show up with a June 3 kernel. DES -- Dag-Erling Smorgrav - d...@ifi.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: devstat_end_transaction: HELP!! busy_count for wd0 0 (-1)
Dag-Erling Smorgrav d...@ifi.uio.no writes: Dag-Erling Smorgrav d...@ifi.uio.no writes: Dag-Erling Smorgrav d...@ifi.uio.no writes: I'm getting tons of these in an IDE-only box. They started appearing after I put in an IBM DTTA371010 to replace the old (and dying) Quantum Fireball ST. Following up on myself, the box just panicked (softdep_write_complete: lock held). Following up on myself again, a May 4 kernel (with the exact same configuration) works fine and dandy. The problems only show up with a June 3 kernel. Argh! I forgot to mention - this is a RELENG_3 box. DES -- Dag-Erling Smorgrav - d...@ifi.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: devstat_end_transaction: HELP!! busy_count for wd0 0 (-1)
Dag-Erling Smorgrav d...@ifi.uio.no writes: Dag-Erling Smorgrav d...@ifi.uio.no writes: Dag-Erling Smorgrav d...@ifi.uio.no writes: Dag-Erling Smorgrav d...@ifi.uio.no writes: I'm getting tons of these in an IDE-only box. They started appearing after I put in an IBM DTTA371010 to replace the old (and dying) Quantum Fireball ST. Following up on myself, the box just panicked (softdep_write_complete: lock held). Following up on myself again, a May 4 kernel (with the exact same configuration) works fine and dandy. The problems only show up with a June 3 kernel. Argh! I forgot to mention - this is a RELENG_3 box. I hang my head in shame; the June 3 kernel was compiled from the wrong config file. All's well :) DES -- Dag-Erling Smorgrav - d...@ifi.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 3.2-stable, panic #12
Bill Huey bi...@mag.ucsd.edu writes: It's been rumored that CVS itself is the technical factor limiting one's ability to fork the tree because of the nature of how CVS update files by clobbering them. That is correct. Creating branches in CVS is very expensive. I had a talk to someone the the #freebsd IRC channel about this. The name slips my mind right now. Almost certainly EE (Eivind Eklund). DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: sgmlformat making release
Wilko Bulte wi...@yedi.iaf.nl writes: sgmlformat-1.7.tar.gz doesn't seem to exist on this system. Attempting to fetch from http://fallout.campusview.indiana.edu/ports/distfiles/. fetch: reading reply from fallout.campusview.indiana.edu: Operation timed out Attempting to fetch from ftp://ftp.freebsd.org/pub/FreeBSD/ports/distfiles/. fetch: ftp.freebsd.org: Host name lookup failure Couldn't fetch it - please try to retrieve this port manually into /usr/ports/distfiles/ and try again. *** Error code 1 Stop. *** Error code 1 The build is running in a chroot tree which does not have a valid /etc/resolv.conf. yedi#ls /usr/ports/distfiles docbk241.tar.Z isoENTS.zip linuxdoc-1.1.tar.gz docbk30.tar.Z jade-1.2.1.tar.gz sgmlformat-1.7.tar.gz This is outside the chroot tree. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Extra text modes via vidcontrol...
Kazutaka YOKOTA yok...@zodiac.mech.utsunomiya-u.ac.jp writes: su-2.02# config BANTU BANTU:135: unknown option VM86 Unknown option used - it is VERY important that you do make clean make depend before recompiling Kernel build directory is ../../compile/BANTU Umm, this means that your source tree is not as current as it should be, in order to be called 4.0-CURRENT. The VM86 option was added to the -CURRENT branch long before 3.0-RELEASE! How are you updating your source tree in /usr/src? VM86 is no longer an option. Remove it, and everything will be fine. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: linux and freebsd kernels conceptually different?
Arun Sharma adsha...@home.com writes: I'd say most of the differences are in implementation and development methodology. Linux camp seems to be proud of breaking traditions and concepts invented after lengthy research. I haven't seen that many iconoclasts in my short encounter with FreeBSD. You say that as if it's a good thing... I'd amend it to The Linux camp seems to think it's a good idea to ignore countless man-years of research and development in the field of OS design, and make the same mistakes other people have made, corrected and documented years before them. I haven't seen that many ignorants in my short encounter with FreeBSD. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: select(2) breakage
Brian Feldman gr...@unixhelp.org writes: Another problem that came up with this: I originally started at port 1024. I monopolized 3 ports (almost all consecutive, of course). When I try to connect() a TCP socket as non-root, it fails with EAGAIN (I only tracked it far enough down as in_pcbbind().) It seems that eventually it gives up trying to find a port... :-/ What kind of connects are you doing? If you try to connect all your sockets to the same destination,port tuple you'll quickly run out of source ports, since there are only a little less than 4,000 ports available: d...@des ~% sysctl -A | grep portrange net.inet.ip.portrange.lowfirst: 1023 net.inet.ip.portrange.lowlast: 600 net.inet.ip.portrange.first: 1024 net.inet.ip.portrange.last: 5000 net.inet.ip.portrange.hifirst: 49152 net.inet.ip.portrange.hilast: 65535 connect() normally uses the 1024-5000 range. Try the following: # sysctl -w net.inet.ip.portrange.last=4 and see if it solves the EAGAIN problem. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: select(2) breakage
Brian Feldman gr...@unixhelp.org writes: On 13 Jun 1999, Dag-Erling Smorgrav wrote: connect() normally uses the 1024-5000 range. Try the following: # sysctl -w net.inet.ip.portrange.last=4 and see if it solves the EAGAIN problem. Actually, this is the perfect explanation. I think that this should go in the FAQ. Why in the world are we limiting the ports we can use other than from 1-1023? I have no idea. The only use I've ever had for this is the predictability of FTP data port numbers, since ftpd will normally use the high range (49152-65535). Useful for designing firewalls, and if you don't like opening such a wide port range, you can whittle it down to a handful (say, one thousand) of ports with judicious use of sysctl. I couldn't find any reference to this in RFC 793, 1122, 1123, 1700 or 2577. Remind me to build a glimpse index of my RFC collection... This still doesn't explain select()'s failure to time out, although I should point out that you forgot to increase FD_SETSIZE before including sys/types.h, and I'm not sure your computation of highestsock is correct, since there's no guarantee that fdvec is sorted. I haven't tested your code though, I just looked over it quickly. BTW, you should check for errno == EINTR when select() returns -1. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: select(2) breakage
Dag-Erling Smorgrav d...@flood.ping.uio.no writes: This still doesn't explain select()'s failure to time out Found it! If you change: printf(no select() action); to: fprintf(stderr, no select() action\n); you'll see that select() does time out. The moral of this story is to always use an unbuffered stream for logging and debugging messages. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: select(2) breakage
Brian Feldman gr...@unixhelp.org writes: On 13 Jun 1999, Dag-Erling Smorgrav wrote: BTW, you should check for errno == EINTR when select() returns -1. The perror() is the status report for select() when -1. Yeah, but EINTR is a normal condition, so I'd ignore it silently instead of logging it. Of course, the purpose of this program is to demonstrate select() behaviour, so logging EINTR is valid. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: vn swapfiles deleted while in use
Matthew Dillon dil...@apollo.backplane.com writes: On the otherhand, if you *truncate* the file or unconfigure the vn node, you will blow the system up when the system tries to swap something in or out on that file. Is there any possibility of adding a reference count to the vn device so it can't be unconfigured if it's still referenced? Is there any possibility of implementing a compulsory (as opposed to advisory) file locking system, so vn swapfiles can't be truncated or written to by any other process while it's in use? DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: problem for the VM gurus
Matthew Dillon dil...@apollo.backplane.com writes: :A permanent vnode locking fix is many months away because core :decided to ask Kirk to fix it, which was news to me at the time. :However, I agree with the idea of having Kirk fix VNode locking. : : Actually, core did no such thing. Kirk told me a month or so ago that he :intended to fix the vnode locking. Not that this is particularly important, :but people shouldn't get the idea that Kirk's involvement had anything to :do with core since it did not. Let me put it this way: You didn't bother to inform anyone else who might have reason to be interested until it came up as an offhand comment at USENIX. Perhaps you should consider not keeping such important events to yourself, eh? Frankly, I am rather miffed -- if I had known that Kirk had expressed an interest a month ago I would have been able to pool our interests earlier. Instead I've been working in a vacuum for a month because I didn't know that someone else was considering trying to solve the problem. This does not fill me with rosy feelings. Eivind Eklund has also been working on this. It is my understanding that he has a working Perl version of vnode_if.sh, and is about halfway through adding invariants to the locking code to track down locking errors. He stopped working on it about a month or two ago for lack of time; I seem to recall that he had managed to get the kernel to boot and was working on panics (from violated invariants) which occurred during fsck. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: umapfs...
David E. Cross cro...@cs.rpi.edu writes: I have been looking at the code for UMAPfs... I am trying to understand conceptually why it is so unstable... You're looking in the wrong place. It's unstable because of infrastructure problems which require fairly substantial amounts of work to correct. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: umapfs...
David E. Cross cro...@cs.rpi.edu writes: That is my interpretation of the code. It would *seem* to just pass the call off to the next FS layer as if the VFS system of the kernel had done it directly Conceptually I must be missing something. Umm, umapfs rewrites the owner/group of vnodes if I'm not mistaken. That's the whole point with it. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Call for review] init(8): new feature
san...@sanpei.org (MIHIRA Yoshiro) writes: # Yes, We modify some ports to support start,stop. And others to no longer support it. The Apache 1.2 port used to support it, the Apache 1.3 port doesn't. Here's a replacement: #!/bin/sh if [ ! -x /usr/local/sbin/apachectl ] ; then echo apachectl not found exit 1 fi case $1 in start|stop|restart) /usr/local/sbin/apachectl $1 ;; *) echo Usage: $(basename $0) start|stop|restart exit 1 ;; esac DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: how do I install driver examples?
David Scheidt dsche...@enteract.com writes: # cd /; (cd /cdrom; tar cvf - usr/share/examples/drivers ) | tar xvf - should work. # cd /cdrom tar cvf - usr/share/examples/drivers | tar xvf - -C / DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Introduction
Ruslan Ermilov r...@ucb.crimea.ua writes: * Clean the existing code (both userland and kernel) (10-20% done) * Re-design the ipfw's API * Port the existing functionality to the new API * Proceed with new features Pretty please with sugar on top, design an API that can be extended without breaking binary compatibility. We've had too much of that for no good reason (at least once between 2.2.7 and 2.2.8, and once between 3.1 and 3.2). DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Introduction
Brian F. Feldman gr...@unixhelp.org writes: It might be worth (discussion of) making ipfilter the firewall of choice for 4.0. There would of course be rule conversion scripts/programs (ipfw-ipf(5)), and ipfilter would be converted to a KLD, cruft removed (I'm going to work on these), and ipfilter KLD support (currently options IPFILTER_LKM) made a non-option. It seems that our pretty proprietary ipfw is no longer a good idea. If ipfilter can to everything ipfw can (judging from ipf(5), it can) and you even manage to keep an ipfw(8) command around so those who want kan keep using the old syntax still can, then I for one have no objections. Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a simple Perl script should be sufficient. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Firewalls (was Re: Introduction)
Brian F. Feldman gr...@unixhelp.org writes: On 19 Jun 1999, Dag-Erling Smorgrav wrote: Rewriting ipfw rules to ipfilter rules on the fly should be trivial; a simple Perl script should be sufficient. Not quite as trivial as you think. ipfw and ipf are completely backwards when it comes to rule order: in ipfw, the first rule matched takes effect; in ipf, the last rule matched takes effect. Just throw in 'quick' and ipfilter behaves just like ipfw. Note that Luigi's extra ipfw functionality and my extra ipfw functionality _will_ be wanted in ipf before everyone is necessarily willing to switch. Divert sockets, dummynet and credential-based filtering would be sorely missed if they weren't ported to ipfilter. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Beware of UnixWare 7
Thomas Good t...@nrnet.org writes: Many conf tasks remain non-trivial as compared to BSD or Linux due to inexpertise on SCO's end...as the red Sytem Admin Handbook once stated (Neveth, Snyder et al.) SCO Unix* is `perverse'. Nemeth, Snyder, Seebass, Hein. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Beware of UnixWare 7...And Lysdexia?
Thomas Good t...@nrnet.org writes: The part that compares system initialisation is especially useful. I use both getty and ttymon and the book does a good job comparing the two strategies...I wish they'd do a new edition. I like Aeleen Frisch (SP? ;-) You got that one right :) and her `Essential System Administration' from Tim O'Reilly but the red sysadm guide is my favourite. Actually, I didn't like it very much. It's been a long time though; I was 17 when I read it. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Fwd: Re: misc/11796: Bad lines in 3.2-RELEASE inetd.conf]
Doug d...@gorean.org writes:
In my experience, and in the experience of the PR poster it *is*
necessary to use the canonical name of the service, however if you can
check the code, test it thoroughly and determine that inetd works
perfectly well with aliases, then feel free to change the man page for
inetd.
Empirical evidence as well as the source code say you're both wrong.
The builtin ident service is listed as ident in inetd's table over
internal services.
d...@des ~% telnet localhost auth
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
des
des:ERROR:HIDDEN-USER
Connection closed by foreign host.
d...@des ~% grep ident /etc/inetd.conf
# Return error for all ident requests
ident stream tcp nowait rootinternal
# example entry for the optional ident server
#ident stream tcp waitkmem:kmem /usr/local/sbin/identd identd
-w -t120
d...@des ~% grep ident /usr/src/usr.sbin/inetd/inetd.c
voidident_stream __P((int, struct servtab *));
{ ident, SOCK_STREAM,1, -1, ident_stream },
ident_stream(s, sep)/* Ident service */
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: [Fwd: Re: misc/11796: Bad lines in 3.2-RELEASE inetd.conf]
Doug d...@gorean.org writes: You are really really missing my point here, so I will state it again. If you have carefully examined the code for *every* case of *every* internal service, and you have tested it thoroughly, and you are 100% sure that the man page is in error, change the man page. The confusion arises from the fact that inetd and /etc/services disagree on what the canonical name for the ident service is. Inetd has these canonical names hardcoded in an array of structs, so changing the canonical name in /etc/services does not affect inetd's belief of what the canonical name is. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Fwd: Re: misc/11796: Bad lines in 3.2-RELEASE inetd.conf]
Doug d...@gorean.org writes: It doesn't work with the conf file that came with the system, but it does work if I change the conf file to match the documentation is pretty good content in my book. Obviously he doesn't include information on how to repeat the problem in a verifiable way, but that doesn't (in my book anyway) invalidate the PR. The PR is wrong. Sheldon is right. It *does* work the way it ships. If he experienced problems, I bet the real bug was that he edited inetd.conf, HUPed inetd, and hit the HUP clobbers the service table bug. I urge you, again, to try and understand my point. There is no reason to have the man page and the example conf file out of synch. Also, as Dag-Erling pointed out, the real problem is much deeper than either, however bringing the documentation up to date *should* be a priority regardless of how many of the other problems you choose to fix. The right way to fix the documentation is simply to mention what inetd thinks the canonical names are. The alternative solution is to extend the format of inetd.conf to allow specifying the service name after the 'internal' keyword, so you could change /etc/services to read: fooglorb113/tcp and inetd.conf to read: fooglorbstream tcp nowait rootinternal ident and inetd would know what service to provide on port 113, even if /etc/services doesn't call it 'ident'. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: [Fwd: Re: misc/11796: Bad lines in 3.2-RELEASE inetd.conf]
Alex Charalabidis a...@wnm.net writes: On 21 Jun 1999, Dag-Erling Smorgrav wrote: The PR is wrong. Sheldon is right. It *does* work the way it ships. If he experienced problems, I bet the real bug was that he edited inetd.conf, HUPed inetd, and hit the HUP clobbers the service table bug. I'll accept this as an explanation, since it sounds much more reasonable than telling me I have no clue what I'm talking about. I edit inetd.conf and HUP, like pretty much everyone else in the world and will keep HUPing for many years to come. If it clobbers the service table on the odd occasion and keeps it clobbered until you change the service's name, well duh, please document it, I'm not psychic. :) We have no intention of documenting it, since the bug has been fixed. If it also breaks on the first machine I install 3.2-R on and coincides with my discovery of aforementioned discrepancy, my guilt is limited to accepting an open invitation to jump to conclusions and I will redeem myself through a weekend penance of listening to the Spice Girls and watching Celine Dion. We're not *that* mad at you. Just ten 'power to the world' and five 'Mmmm-bop' will do. The alternative solution is to extend the format of inetd.conf to allow specifying the service name after the 'internal' keyword, so you could change /etc/services to read: Dare I suggest something as straightforward as bringing inetd, inetd.conf, /etc/services and the respective manpages into sync with each other and/or reality? It's not the right solution. They'll only get out of sync again. The correct solution is to stop pretending /etc/services means anything to inetd except as a way to map service names to port numbers. It doesn't, and never did. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: tcpdump(1) additions.
Bill Fumerola bi...@jade.chc-chimes.com writes: Unless there is strong feelings against it, I'd like to commit the smb patches (as seen on www.samba.org) and ipsec/ike patches (recently mailed to the tcpdump mailing list and b...@freebsd.org) to tcpdump(1). Will they be included in a future official release of tcpdump? Can we afford to wait until then, and simply merge in the next release when it comes? DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: DVD-ram
crypt0genic crypt0ge...@ecad.org writes: I have a Lacie DVD-RAM drive, it work great under windows, here is the DMESG i g et from it, I hope this is of some help. LaCie don't make drives, they just package them in ugly boxes with noisy fans. One of my cow-orkers (with whom I share an office) had an external LaCie disk hooked up to his Mac until I threatened to pour Coca Cola into the PSU (this was after I'd hinted several times that the handles on his G3 would serve very well for chucking it out the window) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: DVD-ram
crypt0genic crypt0ge...@ecad.org writes: * Dag-Erling Smorgrav (d...@flood.ping.uio.no) [990701 11:47]: LaCie don't make drives, they just package them in ugly boxes with noisy fans. Im not sure what model you are refering too, but the drive I have is in a stylish external box with a fan that doesnt make a whisper on noise, It also doesnt make any sound when reading/writeing. The unit is so sturdy I rekon I could through it at a brick wall without damaging it! Overall Im very pleased with this piece of hardware and when it is supported under freebsd it will be one of my most prised devices. : ) The box may look solid, but the drive inside is a standard OEM component (Matshita, IIRC) which would certainly not survive the impact, no matter how sturdy an enclosure it's in - unless the enclosure has internal shock mounts, which would frankly surprise the hell out of me given LaCie's generally low prices. You get what you pay for. And the fan may be nice and silent now, but how do you know that'll last? My cow-orker's unit was two months old when the fan started screaming like a butchered pig. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
IETF 45
[Bcc: to hackers, Cc: to ofug-chat] As you may be aware of, IETF 45 will be held in Oslo, Norway the week after next. If any of you are going, or know of FreeBSD people who are going, and are interested in getting together with norwegian FreeBSD users and developers in a social context, don't hesitate to contact the Oslo FreeBSD User Group (http://www.ofug.org/). DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
bpfilter - bpf patches [LONG]
[Bcc:ed to net, committers; please follow up on hackers] Attached are patches for renaming 'pseudo-device bpfilter' to 'peudo-device bpf', courtesy of glimpse(1) and ed(1). LINT and GENERIC build fine with these patches; I haven't tried to run a kernel built with them, though. Also, although I caught and corrected a few spacing nits caused by chopping off five letters, there may be some I didn't catch. If no-one objects, I'll commit this to -CURRENT in a few days. DES -- Dag-Erling Smorgrav - d...@yes.no Index: src/release/picobsd/router/conf/PICOBSD === RCS file: /home/ncvs/src/release/picobsd/router/conf/PICOBSD,v retrieving revision 1.14 diff -u -r1.14 PICOBSD --- PICOBSD 1999/05/24 17:27:30 1.14 +++ PICOBSD 1999/07/02 08:10:05 @@ -94,7 +94,7 @@ pseudo-device ether #pseudo-device tun 2 #pseudo-device vn -#pseudo-device bpfilter4 +#pseudo-device bpf 4 pseudo-device ppp 4 pseudo-device pty 16 #pseudo-device gzip# Exec gzipped a.out's Index: src/release/scripts/dokern.sh === RCS file: /home/ncvs/src/release/scripts/dokern.sh,v retrieving revision 1.14 diff -u -r1.14 dokern.sh --- dokern.sh 1999/06/09 09:08:22 1.14 +++ dokern.sh 1999/07/02 08:10:05 @@ -12,7 +12,7 @@ -e 's/GENERIC/BOOTMFS/g' # So dhclient will work (just on boot floppy). -echo pseudo-device bpfilter 4 +echo pseudo-device bpf 4 echo options NFS_NOSERVER echo options SCSI_NO_OP_STRINGS Index: src/share/man/man4/bpf.4 === RCS file: /home/ncvs/src/share/man/man4/bpf.4,v retrieving revision 1.16 diff -u -r1.16 bpf.4 --- bpf.4 1999/01/10 04:59:59 1.16 +++ bpf.4 1999/07/02 08:10:05 @@ -29,7 +29,7 @@ .Nm bpf .Nd Berkeley Packet Filter .Sh SYNOPSIS -.Cd pseudo-device bpfilter +.Cd pseudo-device bpf .Sh DESCRIPTION The Berkeley Packet Filter provides a raw interface to data link layers in a protocol Index: src/sys/alpha/tc/am7990.c === RCS file: /home/ncvs/src/sys/alpha/tc/am7990.c,v retrieving revision 1.3 diff -u -r1.3 am7990.c --- am7990.c1999/05/10 15:48:01 1.3 +++ am7990.c1999/07/02 08:08:50 @@ -78,7 +78,7 @@ */ #include opt_inet.h -#if NBPFILTER 0 +#if NBPF 0 #include net/bpf.h #include net/bpfdesc.h #endif @@ -229,7 +229,7 @@ if_attach(ifp); ether_ifattach(ifp); -#if NBPFILTER 0 +#if NBPF 0 bpfattach(ifp-if_bpf, ifp, DLT_EN10MB, sizeof(struct ether_header)); #endif @@ -318,7 +318,7 @@ struct letmd tmd; u_int8_t *myaddr; -#if NBPFILTER 0 +#if NBPF 0 if (ifp-if_flags IFF_PROMISC) init.init_mode = LE_MODE_NORMAL | LE_MODE_PROM; else @@ -565,7 +565,7 @@ /* We assume that the header fit entirely in one mbuf. */ eh = mtod(m, struct ether_header *); -#if NBPFILTER 0 +#if NBPF 0 /* * Check if there's a BPF listener on this interface. * If so, hand off the raw packet to BPF. @@ -923,7 +923,7 @@ if (m == 0) break; -#if NBPFILTER 0 +#if NBPF 0 /* * If BPF is listening on this interface, let it see the packet * before we commit it to the wire. Index: src/sys/alpha/tc/if_le_dec.c === RCS file: /home/ncvs/src/sys/alpha/tc/if_le_dec.c,v retrieving revision 1.1 diff -u -r1.1 if_le_dec.c --- if_le_dec.c 1998/08/20 08:27:10 1.1 +++ if_le_dec.c 1999/07/02 08:09:11 @@ -41,7 +41,7 @@ * @(#)if_le.c 8.2 (Berkeley) 11/16/93 */ -#include bpfilter.h +#include bpf.h #include sys/param.h #include sys/systm.h #include sys/kernel.h Index: src/sys/conf/files === RCS file: /home/ncvs/src/sys/conf/files,v retrieving revision 1.223 diff -u -r1.223 files --- files 1999/06/24 03:44:10 1.223 +++ files 1999/07/02 08:09:11 @@ -391,7 +391,7 @@ ntfs/ntfs_compr.c optional ntfs ntfs/ntfs_ihash.c optional ntfs net/bpf.c standard -net/bpf_filter.c optional bpfilter +net/bpf_filter.c optional bpf net/bridge.c optional bridge net/bsd_comp.c optional ppp_bsdcomp #net/hostcache.c standard Index: src/sys/contrib/dev/oltr/if_oltr.c === RCS file: /home/ncvs/src/sys/contrib/dev/oltr/if_oltr.c,v retrieving revision 1.5 diff -u -r1.5 if_oltr.c --- if_oltr.c 1999/05/09 17:07:24 1.5 +++ if_oltr.c 1999/07/02 08:09:11 @@ -37,7 +37,7 @@ #include pci.h #include oltr.h #include opt_inet.h -#include bpfilter.h +#include bpf.h #if (NOLTR + NPCI) 0 @@ -90,7 +90,7 @@ #include
netstat(1) / sockstat(1) field width adjustments
[Bcc:ed to net, please follow up on hackers] Attached are patches which widen the local/foreign address fields in netstat(1) (so as not to truncate the port number) and the protocol field in sockstat(1) (to accomodate 'divert'). The netstat patch has the unfortunate side effect of pushing the state field so far to the right that most states (except LISTEN) spill over. I consider that the lesser of two evils. I chopped two characters off the process name field to avoid a similar problem in sockstat. As usual, I welcome comments and suggestions, and will commit the patches to -CURRENT in a few days if no-one objects. The patches are by Ruslan Ermilov, with a few adjustment by yours truly. DES -- Dag-Erling Smorgrav - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: netstat(1) / sockstat(1) field width adjustments
Dag-Erling Smorgrav d...@yes.no writes:
Attached are patches [...]
...and here are the patches.
Noticed by: Peter Wemm pe...@overcee.netplex.com.au
DES
--
Dag-Erling Smorgrav - d...@yes.no
Index: src/usr.bin/netstat/inet.c
===
RCS file: /home/ncvs/src/usr.bin/netstat/inet.c,v
retrieving revision 1.31
diff -u -r1.31 inet.c
--- inet.c 1999/03/10 17:25:42 1.31
+++ inet.c 1999/07/03 09:41:51
@@ -163,9 +163,7 @@
putchar('\n');
if (Aflag)
printf(%-8.8s , Socket);
- printf(Aflag ?
- %-5.5s %-6.6s %-6.6s %-18.18s %-18.18s %s\n :
- %-5.5s %-6.6s %-6.6s %-22.22s %-22.22s %s\n,
+ printf(%-5.5s %-6.6s %-6.6s %-21.21s %-21.21s %s\n,
Proto, Recv-Q, Send-Q,
Local Address, Foreign Address, (state));
first = 0;
@@ -196,9 +194,9 @@
}
if (istcp) {
if (tp-t_state 0 || tp-t_state = TCP_NSTATES)
- printf( %d, tp-t_state);
+ printf(%d, tp-t_state);
else {
- printf( %s, tcpstates[tp-t_state]);
+ printf(%s, tcpstates[tp-t_state]);
#if defined(TF_NEEDSYN) defined(TF_NEEDFIN)
/* Show T/TCP `hidden state' */
if (tp-t_flags (TF_NEEDSYN|TF_NEEDFIN))
@@ -555,7 +553,6 @@
{
struct servent *sp = 0;
char line[80], *cp;
- int width;
sprintf(line, %.*s., (Aflag !numeric) ? 12 : 16, inetname(in));
cp = index(line, '\0');
@@ -565,8 +562,7 @@
sprintf(cp, %.15s, sp ? sp-s_name : *);
else
sprintf(cp, %d, ntohs((u_short)port));
- width = Aflag ? 18 : 22;
- printf( %-*.*s, width, width, line);
+ printf(%-21.21s , line);
}
/*
Index: src/usr.bin/sockstat/sockstat.1
===
RCS file: /home/ncvs/src/usr.bin/sockstat/sockstat.1,v
retrieving revision 1.1
diff -u -r1.1 sockstat.1
--- sockstat.1 1999/04/15 13:40:43 1.1
+++ sockstat.1 1999/07/03 09:41:51
@@ -39,7 +39,7 @@
.Nm
command lists open Internet sockets. The information listed for each
socket is:
-.Bl -tag -width FOREIGN_ADDRESS
+.Bl -tag -width FOREIGN ADDRESS
.It Li USER
The user who owns the socket.
.It Li COMMAND
@@ -49,7 +49,7 @@
.It Li FD
The file descriptor number of the socket.
.It Li PROTO
-The transport protocol (udp or tcp) associated with the socket.
+The transport protocol associated with the socket.
.It Li LOCAL ADDRESS
The address the local end of the socket is bound to (see
.Xr getsockname 2 ).
@@ -59,8 +59,8 @@
.El
.Sh SEE ALSO
.Xr fstat 1 ,
-.Xr inet 4 ,
-.Xr netstat 1 .
+.Xr netstat 1 ,
+.Xr inet 4 .
.Sh HISTORY
The
.Nm
Index: src/usr.bin/sockstat/sockstat.pl
===
RCS file: /home/ncvs/src/usr.bin/sockstat/sockstat.pl,v
retrieving revision 1.2
diff -u -r1.2 sockstat.pl
--- sockstat.pl 1999/05/01 11:31:19 1.2
+++ sockstat.pl 1999/07/03 09:48:24
@@ -33,18 +33,17 @@
my ($user, $cmd, $pid, $fd, $inet, $type, $proto, $sock, $laddr, $faddr);
print EOH;
-USER COMMAND PID FD PROTO LOCAL ADDRESSFOREIGN ADDRESS
+USER COMMANDPID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
EOH
format STDOUT =
-@ @ @ @ @@ @
-$user, $cmd, $pid, $fd, $proto,$laddr, $faddr
+@ @ @ @ @ @ @
+$user, $cmd,$pid, $fd, $proto,$laddr, $faddr
.
-open NETSTAT, netstat -Aan | or die 'netstat -Aan' failed: $!;
+open NETSTAT, netstat -Aan -finet | tail +3 | or die 'netstat' failed: $!;
while (NETSTAT) {
my ($sock, $proto, $recvq, $sendq, $laddr, $faddr, $state) = split;
-next unless ($proto =~ m/tcp|udp/);
($myaddr{$sock}, $hisaddr{$sock}) = ($laddr, $faddr);
}
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: bpfilter - bpf patches [LONG]
Doug d...@gorean.org writes: Forgive me if this is a stupid question, but are there any circumstances where naming the kernel include file bpf.h would conflict with /usr/include/net/bpf.h? I don't think so. The bpf.h created by config(8) resides in the compile directory and is only used there; the real bpf.h is in /sys/net/ (or /usr/include/net) and is only referred to as net/bpf.h. Besides, if there were any confusion, I wouldn't (shouldn't) have been able to build LINT and GENERIC with the patches. That said, thanks for asking - while looking into this matter I found another problem :) new patches will be available soon. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: bpfilter - bpf patches [LONG]
Dag-Erling Smorgrav d...@flood.ping.uio.no writes: That said, thanks for asking - while looking into this matter I found another problem :) new patches will be available soon. Nothing serious; a corrected patch is available on my freefall web page (http://www.freebsd.org/~des/software/) DES -- Dag-Erling Smorgrav - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: how to start to be a hacker?
Not to let this become a passage of right or anything. ITYM rite of passage. HTH, HAND! DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Repalcement for grep(1)
Jamie Howard howar...@wam.umd.edu writes:
I made the version in FreeBSD 4.0 my target except for -A num, -B num, -C,
-num, and -Z. These are not required by the Single Unix Specification or
POSIX and I felt they would bloat my code too significantly.
I find those quite useful, and I don't see how they'd bloat your code
a lot. You need a line @queue and a $toprint counter, as well as $lead
and $trail counters. $regexp is the expression to search for, and
$line is a scratch variable. Initialize by setting $lead to the -A
argument, $trail to the -B argument; if you encounter -C, set $lead
and $trail to 2; if you encounter -num, set $lead and $trail to
num. Now for the search algorithm in Perl:
$toprint = 0;
@queue = qw();
while ($line = INPUT) {
if ($toprint) {
print $line;
--$toprint;
} else {
shift @queue if (@queue $lead);
push @queue, $line;
}
next unless ($line ~ m/$regexp/o);
while (@queue) {
print shift @queue;
}
$toprint = $trail;
}
This should be trivial to translate to C. The only non-trivial part of
implementing this stuff is that you have to trick getopt() to make
-num work. You'll have to put a : at the start of your getopt()
string and examine every argument getopt() complains about.
Hope this helps... keep up the good work!
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Repalcement for grep(1)
Jamie Howard howar...@wam.umd.edu writes: All of the code is original except for binary.c. It is used with the -a option to prevent searching binary files. binary.c is extricated from less-332's binary checking code. I was just that lazy. Less's binary checking code is a tad too strict. It complains about files with my name at the top (e.g. /usr/include/fetch.h in FreeBSD 3.x and 4.x) in non-ISO8859 locales. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
Wes Peters w...@softweyr.com writes: # # Others? # 50.70 6.2 gellekum # Thomas Gellekum, Aachen, Germany 12.5877.35 koshy# Joseph Koshy, Bangalore, India 48.36 2.99 philippe # Phillipe Charnier, Cannes Ecluse, Fran ce The three marked Others were individuals who responded to didn't appear to have accounts on freefall. This looks pretty cool when used with xearth -markerfile, you can see that the sun never sets on the FreeBSD empire. ;^) gellekum == t...@freebsd.org koshy == jko...@freebsd.org philippe == charn...@freebsd.org So far, Eivind is the northernmost and Grog and the Adelaide crowd the southernmost. Put me in the same spot as Eivind (I actually live in Oslo, 15 miles to the north of Ski, but I work in Ski). If you can find the right coordinates for Oslo, put me there instead :) I think tegge also lives in Oslo now, but I'm not sure. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Jamie Howard howar...@wam.umd.edu writes: Due to the number of fixes I have received over the past few days, I decided to put together a new release of grep. It was either this or watch _Titanic_ on Cinemax. A clear-cut choice. I changed it so that even when called as grep or with -G, it treats the pattern as an extended regular expression. GNU grep behaves the same way. Hmm, well, never mind standards I guess. Archie Cobbs dropped the hint needed to solve the problems with -x. Right now, I wrap the pattern with ^( and )$. I know GNU grep does this, but is this correct? Yes. You can solve -w in a similar manner by using \ and \. Now, as it stands, I beleive this implementation is identical to GNU grep, *functionally* identical. Due to problems with the previous download site (it is down as I type this), I will place this file in two locations: ftp://dragon.ham.muohio.edu/pub/howardjp/grep-0.3.tar.gz ftp://ftp.wam.umd.edu/pub/howardjp/grep-0.3.tar.gz Mirror site: ftp://ftp.ofug.org/pub/grep/ DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Jamie Howard howar...@wam.umd.edu writes: Ahh, this is a good idea. I have not yet replaced GNU grep on my system with this so it has not yet occurred to me that there might be issues with that. I tried it; it works fine except for the lack of -w. Haven't tried 0.3 yet. A good test is to build lots of ports, since the ports framework uses grep a lot. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Jamie Howard howar...@wam.umd.edu writes:
I incorporated a huge patch from Dag-Erling Smorgrav [...]
Here's more :)
BTW, I assume you've read this:
URL:http://www.opengroup.org/onlinepubs/007908799/xcu/grep.html
I see you switched to using extended regexps by default, and made -E a
no-op; this breaks the ports collection, so I changed it back.
Sort your switch cases.
Don't use err() indiscriminately after a malloc() failure; malloc()
doesn't set errno.
Don't use calloc() needlessly.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
--- grep-0.3/grep.c Mon Jul 5 21:23:18 1999
+++ des/grep.c Wed Jul 7 20:53:46 1999
@@ -28,6 +28,7 @@
#include sys/types.h
#include sys/stat.h
+
#include err.h
#include regex.h
#include stdio.h
@@ -89,9 +90,6 @@
case 'G':
Gflag++;
break;
- case 'Z':
- Zflag++;
- break;
case 'L':
lflag = 0;
Lflag = qflag = 1;
@@ -100,6 +98,9 @@
fprintf(stderr, Jamie's grep version %u.%u\n, VER_MAJ, VER_MIN);
usage();
break;
+ case 'Z':
+ Zflag++;
+ break;
case 'a':
aflag = 1;
break;
@@ -115,11 +116,11 @@
case 'f':
if (stat(optarg, patternstat))
err(2, %s, optarg);
- if ((pattern = calloc(1, patternstat.st_size + 1)) == NULL)
- err(1, calloc);
+ pattern = grep_malloc(patternstat.st_size + 1);
if ((patternfile = fopen(optarg, r)) == NULL)
err(2, %s, optarg);
fread(pattern, patternstat.st_size, 1, patternfile);
+ pattern[patternstat.st_size] = 0;
break;
case 'h':
oflag = 0;
@@ -192,40 +193,37 @@
cflags |= REG_NOSPEC;
while (pattern != NULL) {
patterns++;
- if ((pat = realloc(pat, patterns * sizeof(regex_t))) == NULL)
- err(1, realloc);
+ pat = grep_realloc(pat, patterns * sizeof(regex_t));
if ((c = regcomp(pat[patterns - 1], tmp, cflags))) {
fprintf(stderr, %s\n, tmp);
- regerror(c, pat, (char *)re_error, RE_ERROR_BUF);
+ regerror(c, pat, re_error, RE_ERROR_BUF);
err(2, re_error);
}
tmp = strsep(pattern, \n);
}
} else {
- cflags |= REG_EXTENDED;
+ cflags |= Eflag ? REG_EXTENDED : REG_BASIC;
if (xflag) {
- if ((realpat = malloc(strlen(pattern) + sizeof(^() +
- sizeof()$) + 1)) == NULL)
- err(1, malloc);
+ realpat = grep_malloc(strlen(pattern) + sizeof(^()
+ + sizeof()$) + 1);
strcpy(realpat, ^();
strcat(realpat, pattern);
strcat(realpat, )$);
} else if (wflag) {
- if ((realpat = malloc(strlen(pattern) + sizeof([[::]]) +
-sizeof([[::]]) + 1)) == NULL)
- err(1, malloc);
+ realpat = grep_malloc(strlen(pattern) + sizeof([[::]])
+ + sizeof([[::]]) + 1);
strcpy(realpat, [[::]]);
strcat(realpat, pattern);
strcat(realpat, [[::]]);
- }
+ } else {
realpat = pattern;
- if((pat = malloc(sizeof(regex_t))) == NULL)
- err(1, malloc);
- if((c = regcomp(pat, realpat, cflags))) {
- regerror(c, pat, (char *)re_error, RE_ERROR_BUF);
+ }
+ pat = grep_malloc(sizeof(regex_t));
+ if ((c = regcomp(pat, realpat, cflags))) {
+ regerror(c, pat, re_error, RE_ERROR_BUF);
err(2, re_error);
}
- if(wflag)
+ if (xflag || wflag)
free(realpat);
patterns = 1;
}
@@ -233,9 +231,8 @@
if ((argc == 0 || argc == 1) !oflag)
hflag = 1;
if (argc == 0)
- exit(!procfile((char *)NULL));
-c = 0;
-for (i = 0; i argc; i++) {
+ exit(!procfile(NULL));
+for (c = i = 0; i argc; i++) {
c += procfile(argv[i]);
}
if (Fflag)
--- grep-0.3/grep.h Mon Jul 5 14:25:46 1999
+++ des/grep.h Wed Jul 7 20:28:28 1999
@@ -66,3 +66,5 @@
int procline(str_t ln);
int seekable(FILE *f);
void usage(void);
+void *grep_malloc(size_t size);
+void *grep_realloc(void *ptr, size_t size);
--- grep-0.3/util.c Mon Jul 5 17:50:56 1999
+++ des/util.c Wed Jul 7 20:55:57 1999
@@ -27,7 +27,9 @@
*/
#include sys/types.h
+
#include err.h
+#include errno.h
#include regex.h
#include stdio.h
#include stdlib.h
@@ -60,12 +62,11 @@
*/
gzf = gzdopen(STDIN_FILENO, rb);
fn = -;
- } else
- if (!(gzf = gzopen(fn, r))) {
- if (!sflag)
- warn(%s, fn);
- return 0;
- }
+ } else if ((gzf = gzopen(fn, r)) == NULL) {
+ if (!sflag
Re: Replacement for grep(1) (part 2)
[accidentally b0rked the cc: line; apologies to those who get this twice] Jason Thorpe thor...@nas.nasa.gov writes: On 07 Jul 1999 20:57:16 +0200 Dag-Erling Smorgrav d...@flood.ping.uio.no wrote: Don't use err() indiscriminately after a malloc() failure; malloc() doesn't set errno. This is a bug in malloc(3), is it not? According to the Single Unix Specification, yes. URL:http://www.opengroup.org/onlinepubs/007908799/xsh/malloc.html DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Dag-Erling Smorgrav d...@flood.ping.uio.no writes:
Jamie Howard howar...@wam.umd.edu writes:
I incorporated a huge patch from Dag-Erling Smorgrav [...]
Here's more :)
Following up on myself, I introduced a bug in the previous round of
patches; here's a corrected patch against 0.3.
(the bug was that grep would always bail out if no pattern was
specified after the options, even if one was provided with the -e or
-F option)
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
--- grep-0.3/grep.c Mon Jul 5 21:23:18 1999
+++ des/grep.c Wed Jul 7 21:13:29 1999
@@ -28,6 +28,7 @@
#include sys/types.h
#include sys/stat.h
+
#include err.h
#include regex.h
#include stdio.h
@@ -89,17 +90,18 @@
case 'G':
Gflag++;
break;
- case 'Z':
- Zflag++;
- break;
case 'L':
lflag = 0;
Lflag = qflag = 1;
break;
case 'V':
fprintf(stderr, Jamie's grep version %u.%u\n, VER_MAJ, VER_MIN);
+ fprintf(stderr, argv[0]);
usage();
break;
+ case 'Z':
+ Zflag++;
+ break;
case 'a':
aflag = 1;
break;
@@ -115,11 +117,11 @@
case 'f':
if (stat(optarg, patternstat))
err(2, %s, optarg);
- if ((pattern = calloc(1, patternstat.st_size + 1)) == NULL)
- err(1, calloc);
+ pattern = grep_malloc(patternstat.st_size + 1);
if ((patternfile = fopen(optarg, r)) == NULL)
err(2, %s, optarg);
fread(pattern, patternstat.st_size, 1, patternfile);
+ pattern[patternstat.st_size] = 0;
break;
case 'h':
oflag = 0;
@@ -162,7 +164,7 @@
argc -= optind;
argv += optind;
-if (argc == 0)
+if (argc == 0 !pattern)
usage();
if (!pattern) {
@@ -192,40 +194,37 @@
cflags |= REG_NOSPEC;
while (pattern != NULL) {
patterns++;
- if ((pat = realloc(pat, patterns * sizeof(regex_t))) == NULL)
- err(1, realloc);
+ pat = grep_realloc(pat, patterns * sizeof(regex_t));
if ((c = regcomp(pat[patterns - 1], tmp, cflags))) {
fprintf(stderr, %s\n, tmp);
- regerror(c, pat, (char *)re_error, RE_ERROR_BUF);
+ regerror(c, pat, re_error, RE_ERROR_BUF);
err(2, re_error);
}
tmp = strsep(pattern, \n);
}
} else {
- cflags |= REG_EXTENDED;
+ cflags |= Eflag ? REG_EXTENDED : REG_BASIC;
if (xflag) {
- if ((realpat = malloc(strlen(pattern) + sizeof(^() +
- sizeof()$) + 1)) == NULL)
- err(1, malloc);
+ realpat = grep_malloc(strlen(pattern) + sizeof(^()
+ + sizeof()$) + 1);
strcpy(realpat, ^();
strcat(realpat, pattern);
strcat(realpat, )$);
} else if (wflag) {
- if ((realpat = malloc(strlen(pattern) + sizeof([[::]]) +
-sizeof([[::]]) + 1)) == NULL)
- err(1, malloc);
+ realpat = grep_malloc(strlen(pattern) + sizeof([[::]])
+ + sizeof([[::]]) + 1);
strcpy(realpat, [[::]]);
strcat(realpat, pattern);
strcat(realpat, [[::]]);
- }
+ } else {
realpat = pattern;
- if((pat = malloc(sizeof(regex_t))) == NULL)
- err(1, malloc);
- if((c = regcomp(pat, realpat, cflags))) {
- regerror(c, pat, (char *)re_error, RE_ERROR_BUF);
+ }
+ pat = grep_malloc(sizeof(regex_t));
+ if ((c = regcomp(pat, realpat, cflags))) {
+ regerror(c, pat, re_error, RE_ERROR_BUF);
err(2, re_error);
}
- if(wflag)
+ if (xflag || wflag)
free(realpat);
patterns = 1;
}
@@ -233,9 +232,8 @@
if ((argc == 0 || argc == 1) !oflag)
hflag = 1;
if (argc == 0)
- exit(!procfile((char *)NULL));
-c = 0;
-for (i = 0; i argc; i++) {
+ exit(!procfile(NULL));
+for (c = i = 0; i argc; i++) {
c += procfile(argv[i]);
}
if (Fflag)
--- grep-0.3/grep.h Mon Jul 5 14:25:46 1999
+++ des/grep.h Wed Jul 7 20:28:28 1999
@@ -66,3 +66,5 @@
int procline(str_t ln);
int seekable(FILE *f);
void usage(void);
+void *grep_malloc(size_t size);
+void *grep_realloc(void *ptr, size_t size);
--- grep-0.3/util.c Mon Jul 5 17:50:56 1999
+++ des/util.c Wed Jul 7 20:55:57 1999
@@ -27,7 +27,9 @@
*/
#include sys/types.h
+
#include err.h
+#include errno.h
#include regex.h
#include stdio.h
#include stdlib.h
@@ -60,12 +62,11 @@
*/
gzf = gzdopen(STDIN_FILENO, rb);
fn = -;
- } else
- if (!(gzf = gzopen(fn, r))) {
- if (!sflag
Re: Repalcement for grep(1)
Jamie Howard howar...@wam.umd.edu writes: On Sun, 4 Jul 1999, Archie Cobbs wrote: There are two special cases- of bracket expressions: the bracket expressions `[[::]]' and `[[::]]' match the null string at the beginning and end of a word respectively. Perhaps this will help with -w? Yes, I received a patch from Simon Burge which implements this. It also beats using [^A-Za-z] and [A-Za-z$] as I was and GNU grep does. No, because there are scripts out there (e.g. ports/Mk/bsd.port.mk) which rely on this behaviour. I suggest you explore the magic of the nmatch and pmatch arguments to regexec() :) Specifically, the pattern matched a word if: ((pmatch[0].rm_so == 0 || !isalpha(line[pmatch[0].rm_so-1])) (pmatch[0].rm_eo == len || !isalpha(line[pmatch[0].rm_eo]))) This is off the top of my head, from reading the man page: you'll have to try it out to see if it works. You might want to replace isalpha with something less restrictive, such as isalnum(), or: #define isword(x) (isalnum(x) || (x) == '_') (judging from empirical observation, the latter corresponds to what GNU grep does) As for full-line matches (-x), simply check that (pmatch[0].rm_so == 0 pmatch[0].rm_eo == len) This should save you from playing games with back-references. (both code snippets assume that line points to a line of text from the input and that len is the length of that line minus the newline) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Jamie Howard howar...@wam.umd.edu writes: On 7 Jul 1999, Dag-Erling Smorgrav wrote: I see you switched to using extended regexps by default, and made -E a no-op; this breaks the ports collection, so I changed it back. The FreeBSD, NetBSD, and OpenBSD manpage for grep says this: Grep understands two different versions of regular expression syntax: ``basic'' and ``extended.'' In GNU grep, there is no difference in available functionality using either syntax. Is this inaccurate or am I reading it wrong? One or the other. Try it out for yourself. r...@flood /tmp# cat foo abcd efgh ijkl abcd (efgh) ijkl r...@flood /tmp# grep -V GNU grep version 2.0 usage: grep [-[AB] num] [-CEFGLVXHPRSZabchilnqsvwxy] [-e expr] [-f file] [files ...] r...@flood /tmp# grep '(efgh)' foo abcd (efgh) ijkl r...@flood /tmp# grep -E '(efgh)' foo abcd efgh ijkl abcd (efgh) ijkl Don't use err() indiscriminately after a malloc() failure; malloc() doesn't set errno. Shouldn't malloc be fixed? :) Should, but probably won't in the near future. Oh well. I guess you can just remove 'errno = ENOMEM' from grep_malloc() and grep_realloc() and blame phk if anyone complains :) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Repalcement for grep(1)
Jamie Howard howar...@wam.umd.edu writes: I am not the internationalization expert, but doesn't [^A-Za-z] and [A-Xa-z$] limit you to just English and other Roman languages? Won't [[::]] and [[::]] be languages independent, presuming regex supports it? They don't DTRT. They only match whitespace boundaries IIRC. Anyway, I already posted a solution which does not involve screwing around with the pattern. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Repalcement for grep(1)
BTW, the end-of-line handling is wrong; grep will fail to select a line where the pattern appears at the end and the line is not terminated by a newline. I'm working on a fix (and on implementing my solution for -w and -x). DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Assar Westerlund as...@sics.se writes: Dag-Erling Smorgrav d...@flood.ping.uio.no writes: + realpat = grep_malloc(strlen(pattern) + sizeof(^() + + sizeof()$) + 1); Why not just use asprintf? Doesn't matter, thsis code is gone in the latest version. You though the linux 'kernel of the day' was bad; now you have the FreeBSD 'grep of the minute' :) In this case it doesn't matter but in general this function is wrong. malloc(0) can return NULL. Agreed. And besides, I really don't think this is a grep function but actually is useful for programs that don't have any strategy for handling out of memory errors and might as well die (with a descriptive error message, of course). Let's call it emalloc and let's put in somewhere where it can be used. Too simple to warrant that, and other programs will likely want to handle the error differently. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Jon Ribbens j...@oaktree.co.uk writes: Daniel C. Sobral d...@newsguy.com wrote: OTOH, though, FreeBSD's malloc() is very unlikely to return an out of memory error. Why is that? Because FreeBSD overcommits memory. You can allocate (almost) as much memory as you want regardless of how much RAM / swap you have. You won't run into trouble unless you actually try to use too much of it. What happens if the process hits its resource limits? Malloc() fails with ENOMEM. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Determining the return address
Is there any (evidently non-portable) way of determining a function
instance's return address? I have an idea or two that involves the
return address and dladdr(). The code I currently use looks like this:
int
log_print(log_t *log, char *fmt, ...)
{
char date[32], str[MAX_LOG_LINE];
struct iovec iov[10];
Dl_info info;
size_t len;
va_list ap;
int n;
len = log_makedate(date, sizeof date);
iov[n=0].iov_base = date;
iov[n].iov_len = len;
if (dladdr(*(((void**)log)-1), info) == 0)
iov[++n].iov_base = (unknown);
else
iov[++n].iov_base = (char *)info.dli_sname;
iov[n].iov_len = strlen(iov[n].iov_base);
iov[++n].iov_base = : ;
iov[n].iov_len = 2;
va_start(ap, fmt);
len = lvformat(str, sizeof str, fmt, ap);
va_end(ap);
while (len 0 isspace(str[len-1]))
--len;
iov[++n].iov_base = str;
iov[n].iov_len = len;
iov[++n].iov_base = \n;
iov[n].iov_len = 1;
return writev(log-fd, iov, ++n);
}
Is it correct? (empirical evidence suggests it is) Is there any better
way to do it? Will it work on the Alpha?
BTW, is dladdr() signal-safe?
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Devloper
Assem Salama sal...@twcny.rr.com writes: I am interested in helping in the development in FreeBSD. I'm not a hotshot programmer but I know how to program. Could someone please send me the available projects that I can work on and some info about them? URL:http://www.freebsd.org/handbook/contrib.html DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Devloper
Daniel C. Sobral d...@newsguy.com writes: * a sysctl to make the system non-overcommit So I see common sense lost in the end. * SIGDANGER in low-memory situations Do we support more than 32 signals? ISTR AIX already does this. What signal numbers / names does AIX use for this? * Dividing processes into those that ought to be killed first and those that ought to be killed last in low-memory situations How does AIX solve that problem? * Per-user swap space limit Is that a realistic goal? What do we do about shared text, count it once for every user that uses it? DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Determining the return address
Alfred Perlstein bri...@rush.net writes: This looks like what you are doing is trying to grab the data on the stack before log which is the return address. Yes. It actually works :) I doubt this is at all portable and may fail because of optimizations and ABI, such as archs that store the return address in a register... I know - I don't expect it to be portable. gdb and glibc have some functions to assist in runtime backtraces, perhaps a look there may help? I found out about __builtin_return_address(0). BTW, is dladdr() signal-safe? not according to the sigaction man page. OK, is there any way I can find out that I am being called from a signal handler, other than using a global variable? I want my logging functions to be signal-safe - that's why I use writev(), and I've gone to great lengths to ensure that log_makedate() (which uses localtime_r() and strftime() to build a date string) and lvformat() (a printf() clone with some additional goodies) are signal-safe. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
Greg Lehey g...@lemis.com writes: mdoc.samples(7). Now tell me that that's not intuitive. It would seem mdoc.samples(7) does not teach by example :) d...@des ~% man -t mdoc.samples | lpr -Plex Usage: .Rv -std sections 2 and 3 only DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Determining the return address
Alfred Perlstein bri...@rush.net writes: On 18 Jul 1999, Dag-Erling Smorgrav wrote: Alfred Perlstein bri...@rush.net writes: I doubt this is at all portable and may fail because of optimizations and ABI, such as archs that store the return address in a register... I know - I don't expect it to be portable. *slap* :) It's #ifdef'ed so you can drop it on platforms where it doesn't work :) gdb and glibc have some functions to assist in runtime backtraces, perhaps a look there may help? I found out about __builtin_return_address(0). what is that? a function? available on freebsd? GCC builtin function. by setting an alternate signal stack i think you can check if you are in a signal using this. this may not be the best way but it seems like a viable solution. Hmm, I ended up using a global variable which I increment at the beginning of the signal handler, and decrement at the end. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Determining the return address
Wes Peters w...@softweyr.com writes: On the SPARC, FWIW, the return address is in %i7. What is difficult to determine (programmatically) is if the function is a normal or leaf function; different return sequences are used for each. It doesn't matter; all I need it for is to find the caller's name using dladdr(). DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Determining the return address
Alfred Perlstein bri...@rush.net writes: On 18 Jul 1999, Dag-Erling Smorgrav wrote: Hmm, I ended up using a global variable which I increment at the beginning of the signal handler, and decrement at the end. As long as you make sure the code won't have multiple access that would work. Signal handlers having multiple accesses? When did you last see that happen? DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Determining the return address
Alfred Perlstein bri...@rush.net writes: erm, can't you point multiple signal handler entries to the same routine? can't you also make it so that signals aren't defered or blocked while another handler is executing so you may actually re-enter the handler before it's complete. I use good ol' signal() rather than sigaction(), so no, signals can't interrupt one another's handlers. specifically how you say you increment it, then decrement it, if you have multiple handlers where one can interupt another you can have the counter get jumbled. Not if increment / decrement is atomic. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Overcommit and calloc()
Kelly Yancey kby...@alcnet.com writes:
I'm afraid my question got lost amongst the see of overcommit messages. :)
I was curious if calloc() was overcommitted also?
Here's our calloc() implementation:
void *
calloc(num, size)
size_t num;
register size_t size;
{
register void *p;
size *= num;
if ( (p = malloc(size)) )
bzero(p, size);
return(p);
}
so the answer is yes, it overcommits, but the bzero() may cause the
system to run out of swap.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD
Oscar Bonilla oboni...@fisicc-ufm.edu writes: the idea is to have an entry in the /etc/passwd enabling LDAP lookups. the Entry would be of the form ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com Horrible idea. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD
Oscar Bonilla oboni...@fisicc-ufm.edu writes: On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote: Oscar Bonilla oboni...@fisicc-ufm.edu writes: the idea is to have an entry in the /etc/passwd enabling LDAP lookups. the Entry would be of the form ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com Horrible idea. suggestions? /etc/auth.conf DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Overcommit and calloc()
Kelly Yancey kby...@alcnet.com writes: Ahh...but wouldn't the bzero() touch all of the memory just allocated functionally making it non-overcommit? No. If it were an non-overcomitting malloc, it would return NULL and set errno to ENOMEM, instead of dumping core. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Overcommit and calloc()
Kelly Yancey kby...@alcnet.com writes: I don't know how many programs make use of calloc() but would not a more efficient algorithm be to better integrate it with malloc() such that if there is a fragment on the heap which can be used, bzero() it and return that, otherwise, simply call sbrk() and return that (since it is already zero'ed). Currently, in the event that malloc() simply returns newly sbrk()'ed memory, we unnecessarily zero it again. I don't see the point. I've seen very few examples of justified calloc() use. For instance, I see a lot of people use calloc() instead of malloc() when allocating strings, just to make sure they'll be terminated after a strncpy(), instead of simply setting the last character to '\0' after the strncpy(). When I allocate memory, I usually intend to put something in it. There's always the odd struct sockaddr_in which I bzero() before filling it in, but they're usually on the stack. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Overcommit and calloc()
John-Mark Gurney gurne...@efn.org writes: Dag-Erling Smorgrav scribbled this message on Jul 20: When I allocate memory, I usually intend to put something in it. There's always the odd struct sockaddr_in which I bzero() before filling it in, but they're usually on the stack. and even then, I don't believe in filling sockaddr_in w/ bzero, I believe in using getsockaddr on it so that you actually get all the fields filled out properly... See? One less reason to use bzero() / calloc() :) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
BSDI binary compatibility
What kinds of BSDI binaries are we supposed to be able to run? I haven't had any luck getting *any* BSDI binaries to run on my (very recent) 4.0-CURRENT box. I have a handful of BSDI binaries, some of which are identified as: d...@des ~/yes/bsdi/shopsite% file wwwinstall.cgi wwwinstall.cgi: unknown pure executable d...@des ~/yes/bsdi/shopsite% ./wwwinstall.cgi zsh: bus error (core dumped) ./wwwinstall.cgi others (ls and cat from BSDI 4.0): d...@des ~/yes/bsdi/cmc% file ./ls ./ls: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked, stripped d...@des ~/yes/bsdi/cmc% ./ls ELF binary type not known. Use brandelf to brand it. zsh: abort ./ls and finally a few static ones Chris Costello was kind enough to build for me: d...@des ~/yes/bsdi/cmc/bsdi_static% file hello hello: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, not stripped d...@des ~/yes/bsdi/cmc/bsdi_static% ./hello ELF binary type not known. Use brandelf to brand it. zsh: abort ./hello DES -- Dag-Erling Smorgrav - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: amandad zombies (fwd)
Snob Art Genre b...@narcissus.net writes: I've been beating my head against a mysterious problem for some time now, and I'm hoping that you folks can help me out. When I run amanda, seven out of my 16 hosts don't respond. Of these, some are Solaris and some are FreeBSD 3.1-RELEASE, but it's the FreeBSD ones I'm concerned with at the moment. I'm using Amanda 2.4.1. (Note that the symptomology on the Solaris machines is different, which is why I'm posting this to -hackers.) This was fixed in revision 1.49 of src/usr.sbin/inetd.c (1999/05/11). DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
UDMA problems on ALI chipsets
Is anybody working on getting UltraDMA to work on ALI chipsets? I have a scratch box with that chipset and an UDMA disks and can test patches and perform minor debugging if anyone needs me to. ide_pci0: Acer Aladdin IV/V (M5229) Bus-master IDE controller irq 0 at device 15.0 on pci0 DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
IDE breakage
drive 0 ___disk wd1 at wdc0 drive 1 ___controller wdc1at isa? port IO_WD2 bio irq 15 flags 0xa0ffa0ff ___disk wd2 at wdc1 drive 0 ___disk wd3 at wdc1 drive 1 ___options ATAPI ___options ATAPI_STATIC ___device acd0 ___pseudo-devicevn 2 ___ ___# Networking ___options INET ___options IPFIREWALL ___options IPFIREWALL_VERBOSE ___options DUMMYNET ___options NMBCLUSTERS=8192 ___device fxp0 ___device xl0 ___pseudo-deviceether ___pseudo-deviceloop 2 ___pseudo-devicebpfilter 4 ___pseudo-devicepty 64 ___ ___# Console ___controller atkbdc0 at isa? port IO_KBD tty ___device atkbd0 at isa? tty irq 1 ___device vga0at isa? port ? conflicts ___device sc0 at isa? tty ___options MSGBUF_SIZE=40960 ___ ___ r...@xxx /# strings -n 3 /kernel.old | grep '^___' ___# ___# Kernel configuration for X servers. ___# ___ ___machine i386 ___cpu I586_CPU ___cpu I686_CPU ___identX ___maxusers 256 ___ ___# General options ___options COMPAT_43 ___options KTRACE ___options SYSVSHM ___options SYSVMSG ___options SYSVSEM ___options INCLUDE_CONFIG_FILE ___options USERCONFIG ___options VISUAL_USERCONFIG ___ ___config kernel root on wd0 ___ ___# Buses ___controller isa0 ___controller pnp0 ___controller pci0 ___ ___device npx0at isa? port IO_NPX irq 13 ___ ___# File system ___options FFS ___options FFS_ROOT ___options MFS ___options MFS_ROOT ___options PROCFS ___options SOFTUPDATES ___ ___controller fdc0at isa? port IO_FD1 bio irq 6 drq 2 ___disk fd0 at fdc0 drive 0 ___controller wdc0at isa? port IO_WD1 bio irq 14 flags 0xa0ffa0ff ___disk wd0 at wdc0 drive 0 ___disk wd1 at wdc0 drive 1 ___controller wdc1at isa? port IO_WD2 bio irq 15 flags 0xa0ffa0ff ___disk wd2 at wdc1 drive 0 ___disk wd3 at wdc1 drive 1 ___options ATAPI ___options ATAPI_STATIC ___device acd0 ___pseudo-devicevn 2 ___ ___# Networking ___options INET ___options IPFIREWALL ___options IPFIREWALL_VERBOSE ___options DUMMYNET ___options NMBCLUSTERS=8192 ___device fxp0 ___device xl0 ___pseudo-deviceether ___pseudo-deviceloop 2 ___pseudo-devicebpfilter 4 ___pseudo-devicepty 64 ___ ___# Console ___controller atkbdc0 at isa? port IO_KBD tty ___device atkbd0 at isa? tty irq 1 ___device vga0at isa? port ? conflicts ___device sc0 at isa? tty ___options MSGBUF_SIZE=40960 ___ ___ DES -- Dag-Erling Smorgrav - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: IDE breakage
Dag-Erling Smorgrav d...@yes.no writes: I'm experiencing serious problems with DMA (even normal DMA, not UDMA) on recent versions of -STABLE. Here's an excerpt from messages; kernel #3 is a recent -STABLE (yesterday's sources), while kernel #2 is 3.2-RELEASE. The config file for both is identical. A brand new kernel (from the same sources and config, but built in a clean build directory) produces the following: Jul 22 11:29:17 irc /kernel: Copyright (c) 1992-1999 FreeBSD Inc. Jul 22 11:29:17 irc /kernel: Copyright (c) 1982, 1986, 1989, 1991, 1993 Jul 22 11:29:17 irc /kernel: The Regents of the University of California. All rights reserved. Jul 22 11:29:17 irc /kernel: FreeBSD 3.2-STABLE #0: Thu Jul 22 10:54:31 CEST 1999 Jul 22 11:29:17 irc /kernel: r...@xxx.x.xx:/usr/src/sys/compile/X Jul 22 11:29:17 irc /kernel: Timecounter i8254 frequency 1193182 Hz Jul 22 11:29:17 irc /kernel: Timecounter TSC frequency 348204679 Hz Jul 22 11:29:17 irc /kernel: CPU: Pentium II/Xeon/Celeron (348.20-MHz 686-class CPU) Jul 22 11:29:17 irc /kernel: Origin = GenuineIntel Id = 0x652 Stepping = 2 Jul 22 11:29:17 irc /kernel: Features=0x183f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR Jul 22 11:29:17 irc /kernel: real memory = 134217728 (131072K bytes) Jul 22 11:29:17 irc /kernel: avail memory = 127774720 (124780K bytes) Jul 22 11:29:17 irc /kernel: Preloaded elf kernel kernel at 0xc023c000. Jul 22 11:29:17 irc /kernel: Probing for devices on PCI bus 0: Jul 22 11:29:17 irc /kernel: chip0: Intel 82443BX host to PCI bridge rev 0x02 on pci0.0.0 Jul 22 11:29:17 irc /kernel: chip1: Intel 82443BX host to AGP bridge rev 0x02 on pci0.1.0 Jul 22 11:29:17 irc /kernel: xl0: 3Com 3c905-TX Fast Etherlink XL rev 0x00 int a irq 11 on pci0.13.0 Jul 22 11:29:17 irc /kernel: xl0: Ethernet address: 00:60:08:e8:6b:1d Jul 22 11:29:17 irc /kernel: xl0: autoneg complete, link status good (full-duplex, 100Mbps) Jul 22 11:29:17 irc /kernel: chip2: Intel 82371AB PCI to ISA bridge rev 0x02 on pci0.20.0 Jul 22 11:29:17 irc /kernel: ide_pci0: Intel PIIX4 Bus-master IDE controller rev 0x01 on pci0.20.1 Jul 22 11:29:17 irc /kernel: chip3: Intel 82371AB Power management controller rev 0x02 on pci0.20.3 Jul 22 11:29:17 irc /kernel: Probing for devices on PCI bus 1: Jul 22 11:29:17 irc /kernel: vga0: ATI model 4742 graphics accelerator rev 0x5c int a irq 11 on pci1.0.0 Jul 22 11:29:17 irc /kernel: Probing for PnP devices: Jul 22 11:29:17 irc /kernel: Probing for devices on the ISA bus: Jul 22 11:29:17 irc /kernel: sc0 on isa Jul 22 11:29:17 irc /kernel: sc0: VGA color 16 virtual consoles, flags=0x0 Jul 22 11:29:17 irc /kernel: atkbdc0 at 0x60-0x6f on motherboard Jul 22 11:29:17 irc /kernel: atkbd0 irq 1 on isa Jul 22 11:29:17 irc /kernel: fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa Jul 22 11:29:17 irc /kernel: fdc0: FIFO enabled, 8 bytes threshold Jul 22 11:29:17 irc /kernel: fd0: 1.44MB 3.5in Jul 22 11:29:17 irc /kernel: wdc0 at 0x1f0-0x1f7 irq 14 flags 0xa0ffa0ff on isa Jul 22 11:29:17 irc /kernel: wdc0: unit 0 (wd0): Maxtor 90640D4, DMA, 32-bit, multi-block-16 Jul 22 11:29:17 irc /kernel: wd0: 6149MB (12594960 sectors), 13328 cyls, 15 heads, 63 S/T, 512 B/S Jul 22 11:29:17 irc /kernel: wdc1 at 0x170-0x177 irq 15 flags 0xa0ffa0ff on isa Jul 22 11:29:17 irc /kernel: wdc1: unit 0 (atapi): CD-ROM CDU611-Q/2.0c, removable, accel, dma, iordis Jul 22 11:29:17 irc /kernel: acd0: drive speed 1723KB/sec, 256KB cache Jul 22 11:29:17 irc /kernel: acd0: supported read types: CD-R, CD-RW, CD-DA Jul 22 11:29:17 irc /kernel: acd0: Audio: play, 16 volume levels Jul 22 11:29:17 irc /kernel: acd0: Mechanism: ejectable tray Jul 22 11:29:17 irc /kernel: acd0: Medium: no/blank disc inside, unlocked Jul 22 11:29:17 irc /kernel: npx0 on motherboard Jul 22 11:29:17 irc /kernel: npx0: INT 16 interface Jul 22 11:29:17 irc /kernel: vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa Jul 22 11:29:17 irc /kernel: IP packet filtering initialized, divert disabled, rule-based forwarding disabled, unlimited logging Jul 22 11:29:17 irc /kernel: DUMMYNET initialized (990504) Jul 22 11:29:17 irc /kernel: changing root device to wd0s1a Jul 22 11:29:17 irc /kernel: wd0: DMA failure, DMA status 5active Jul 22 11:29:17 irc last message repeated 17 times Jul 22 11:29:17 irc /kernel: wd0: DMA failure, DMA status 7error,active Jul 22 11:29:17 irc /kernel: Jul 22 11:29:17 irc /kernel: Jul 22 11:29:17 irc /kernel: Fatal trap 12: page fault while in kernel mode Jul 22 11:29:17 irc /kernel: fault virtual address = 0x44 Jul 22 11:29:17 irc /kernel: fault code= supervisor read, page not present Jul 22 11:29:17 irc /kernel: instruction pointer = 0x8:0xc01813ca Jul 22 11:29:17 irc /kernel: stack pointer = 0x10:0xc9599b84 Jul 22 11:29:17 irc /kernel: frame pointer = 0x10:0xc9599bf4 Jul 22 11:29:17 irc /kernel: code segment = base 0x0, limit 0xf, type 0x1b Jul 22 11:29:17 irc /kernel: = DPL 0, pres
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
Sheldon Hearn sheld...@uunet.co.za writes:
I know exactly why you see what you see when you do what you do. All I
can say is don't do that, because I can't think of a why to cater for
what you're doing in a sensible fashion.
I think you're jumping to conclusions. What I'd like to see is a
tcpdump log of the UDP scan ('tcpdump -i ed0 udp or icmp'). Yes, I
know it's going to be huge.
DES
--
Dag-Erling Smorgrav - d...@flood.ping.uio.no
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
Andre Albsmeier andre.albsme...@mchp.siemens.de writes: Comes in private email. It's about 130KB after which tcpdump crashed with: zsh: 5741 segmentation fault tcpdump -i fxp0 150 udp or icmp Weird. Very weird. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
Andre Albsmeier andre.albsme...@mchp.siemens.de writes: Just to overcome speculations :-) I just tested it on another machine with the same result. If have tested it now between all 3 machines in each direction. Same result. Weird. I'm unable to reproduce it; my test box responds to UDP queries but does not log them (though it logs TCP queries). I'll update to the latest inetd and try again. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Mentioning RFC numbers in /etc/services
Sheldon Hearn sheld...@uunet.co.za writes: I plan to mention in the comments for each service in /etc/services, the latest RFC describing the service. Good idea. I also plan to mention in the manpage for services(5) the e-mail address to which requests for How do I get the RFCs should be sent. Don't. Instead, put it in a separate rfc(7) man page which you refer to in the services(5) man page. While you're at it, search all the other man pages for the string RFC and add a reference to rfc(7) to every page that lists an RFC as reference (e.g. fetch(3)). d...@des ~/yes% current -l RFC | grep '\.[0-9]' src/contrib/amd/scripts/expn.1 src/contrib/bind/doc/man/dig.1 src/contrib/bind/doc/man/dnskeygen.1 src/contrib/bind/doc/man/getnetent.3 src/contrib/bind/doc/man/hostname.7 src/contrib/bind/doc/man/mailaddr.7 src/contrib/bind/doc/man/named-xfer.8 src/contrib/bind/doc/man/named.8 src/contrib/bind/doc/man/nslookup.8 src/contrib/bind/doc/man/resolver.3 src/contrib/bind/doc/misc/FAQ.1of2 src/contrib/bind/doc/misc/FAQ.2of2 src/contrib/egcs/libio/dbz/dbz.1 src/contrib/egcs/libio/dbz/dbz.3z src/contrib/ipfilter/ipsend/ipresend.1 src/contrib/ipfilter/ipsend/ipsend.5 src/contrib/ipfilter/man/ipftest.1 src/contrib/isc-dhcp/client/dhclient.conf.5 src/contrib/isc-dhcp/client/dhclient.leases.5 src/contrib/isc-dhcp/common/dhcp-options.5 src/contrib/libpam/doc/man/pam.8 src/contrib/libpam/doc/man/pam_authenticate.3 src/contrib/libpam/doc/man/pam_chauthtok.3 src/contrib/libpam/doc/man/pam_fail_delay.3 src/contrib/libpam/doc/man/pam_open_session.3 src/contrib/libpam/doc/man/pam_setcred.3 src/contrib/libpam/doc/man/pam_start.3 src/contrib/libpam/doc/man/pam_strerror.3 src/contrib/libpam/doc/specs/rfc86.0.txt src/contrib/opie/opie.4 src/contrib/opie/opieftpd.8 src/contrib/patch/patch.1 src/contrib/perl5/Changes5.004 src/contrib/sendmail/src/sendmail.8 src/contrib/tcp_wrappers/hosts_access.5 src/contrib/tcp_wrappers/hosts_options.5 src/contrib/tcp_wrappers/tcpd.8 src/contrib/tcpdump/tcpdump.1 src/crypto/telnet/telnetd/telnetd.8 src/gnu/usr.bin/rcs/co/co.1 src/lib/libc/net/getnetent.3 src/lib/libc/net/resolver.3 src/lib/libc/rpc/rpc.3 src/lib/libc/rpc/rpc_secure.3 src/lib/libc/sys/rfork.2 src/lib/libc/xdr/xdr.3 src/lib/libfetch/fetch.3 src/lib/libmd/mdX.3 src/lib/libradius/libradius.3 src/lib/libradius/radius.conf.5 src/lib/libz/zlib.3 src/libexec/bootpd/bootpd.8 src/libexec/bootpd/bootptab.5 src/libexec/bootpd/tools/bootpef/bootpef.8 src/libexec/bootpd/tools/bootptest/bootptest.8 src/libexec/fingerd/fingerd.8 src/libexec/ftpd/ftpd.8 src/libexec/telnetd/telnetd.8 src/libexec/tftpd/tftpd.8 src/sbin/i386/cxconfig/cxconfig.8 src/sbin/md5/md5.1 src/sbin/mount_nfs/mount_nfs.8 src/sbin/mountd/exports.5 src/sbin/mountd/mountd.8 src/sbin/nfsd/nfsd.8 src/sbin/routed/routed.8 src/sbin/routed/rtquery/rtquery.8 src/sbin/spppcontrol/spppcontrol.8 src/share/examples/mdoc/example.1 src/share/examples/mdoc/example.3 src/share/man/man4/ifmib.4 src/share/man/man4/ip.4 src/share/man/man4/sppp.4 src/share/man/man4/tcp.4 src/share/man/man4/ttcp.4 src/share/man/man5/rc.conf.5 src/share/man/man7/mailaddr.7 src/share/man/man9/MD5.9 src/usr.bin/fetch/fetch.1 src/usr.bin/finger/finger.1 src/usr.bin/ftp/ftp.1 src/usr.bin/showmount/showmount.8 src/usr.bin/whois/whois.1 src/usr.sbin/arp/arp.4 src/usr.sbin/atm/atmarpd/atmarpd.8 src/usr.sbin/atm/scspd/scspd.8 src/usr.sbin/inetd/inetd.8 src/usr.sbin/mrouted/mrouted.8 src/usr.sbin/ppp/ppp.8 src/usr.sbin/pppd/pppd.8 src/usr.sbin/rarpd/rarpd.8 src/usr.sbin/rndcontrol/random.4 src/usr.sbin/xntpd/doc/xntpd.8 src/usr.sbin/xntpd/doc/xntpdc.8 DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
TCP/IP hardening
Attached are patches which implement four new sysctl variables: * net.inet.icmp.dropredirect: if set to 1, ignore ICMP REDIRECT packets. * net.inet.icmp.logredirect: if set to 1, log all ICMP REDIRECT packets (before optionally dropping them). * net.inet.tcp.restrict_rst: if set to 1, do not emit TCP RST packets. Conditional on the TCP_RESTRICT_RST kernel option, which defaults to off. * net.inet.tcp.drop_synfin: if set to 1, drop TCP packets with both the SYN and FIN options set. Conditional on the TCP_DROP_SYNFIN kernel option, which defaults to off. The logredirect code uses inet_ntoa, which is a bad idea. I'm open to suggestions for a better solution. Also, these sysctl variables should be described in a man page somewhere, but I'm not sure which one. These patches compile, but are not fully tested. DES -- Dag-Erling Smorgrav - d...@yes.no Index: etc/defaults/rc.conf === RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.23 diff -u -r1.23 rc.conf --- rc.conf 1999/07/26 10:49:33 1.23 +++ rc.conf 1999/07/26 19:11:51 @@ -48,6 +48,11 @@ tcp_extensions=NO# Set to Yes to turn on RFC1323 extensions. log_in_vain=NO # Disallow bad connection logging (or YES). tcp_keepalive=YES# Kill dead TCP connections (or NO). +tcp_restrict_rst=NO # Set to YES to restrict emission of RST +tcp_drop_synfin=NO # Set to YES to drop TCP packets with SYN+FIN + # NOTE: this breaks rfc1644 extensions (T/TCP) +icmp_dropredirect=NO # Set to YES to ignore ICMP REDIRECT packets +icmp_logredirect=NO # Set to YES to log ICMP REDIRECT packets network_interfaces=auto # List of network interfaces (or auto). ifconfig_lo0=inet 127.0.0.1 # default loopback device configuration. #ifconfig_lo0_alias0=inet 127.0.0.254 netmask 0x # Sample alias entry. Index: etc/rc.network === RCS file: /home/ncvs/src/etc/rc.network,v retrieving revision 1.52 diff -u -r1.52 rc.network --- rc.network 1999/07/26 15:17:23 1.52 +++ rc.network 1999/07/26 19:11:51 @@ -197,6 +197,16 @@ echo -n ' broadcast ping responses=YES' sysctl -w net.inet.icmp.bmcastecho=1 /dev/null fi + +if [ X$icmp_dropredirect = XYES ]; then + echo -n ' ignore ICMP redirect=YES' + sysctl -w net.inet.icmp.dropredirect=1 /dev/null +fi + +if [ X$icmp_logredirect = XYES ]; then + echo -n ' log ICMP redirect=YES' + sysctl -w net.inet.icmp.logredirect=1 /dev/null +fi if [ X$gateway_enable = XYES ]; then echo -n ' IP gateway=YES' @@ -216,6 +226,16 @@ if [ X$tcp_keepalive = XYES ]; then echo -n ' TCP keepalive=YES' sysctl -w net.inet.tcp.always_keepalive=1 /dev/null +fi + +if [ X$tcp_restrict_rst = XYES ]; then + echo -n ' restrict TCP reset=YES' + sysctl -w net.inet.tcp.restrict_rst=1 /dev/null +fi + +if [ X$tcp_drop_synfin = XYES ]; then + echo -n ' drop SYN+FIN packets=YES' + sysctl -w net.inet.tcp.drop_synfin=1 /dev/null fi if [ X$ipxgateway_enable = XYES ]; then Index: sys/conf/options === RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.144 diff -u -r1.144 options --- options 1999/07/05 20:19:34 1.144 +++ options 1999/07/26 19:11:51 @@ -222,6 +222,8 @@ PPP_FILTER opt_ppp.h TCP_COMPAT_42 opt_compat.h TCPDEBUG +TCP_RESTRICT_RST opt_tcp_input.h +TCP_DROP_SYNFINopt_tcp_input.h IPFILTER opt_ipfilter.h IPFILTER_LOG opt_ipfilter.h SLIP_IFF_OPTS opt_slip.h Index: sys/i386/conf/LINT === RCS file: /home/ncvs/src/sys/i386/conf/LINT,v retrieving revision 1.620 diff -u -r1.620 LINT --- LINT1999/07/26 05:47:17 1.620 +++ LINT1999/07/26 19:11:51 @@ -465,9 +465,23 @@ optionsIPDIVERT#divert sockets optionsIPFILTER#kernel ipfilter support optionsIPFILTER_LOG#ipfilter logging -#options IPFILTER_LKM#kernel support for ip_fil.o LKM optionsIPSTEALTH #support for stealth forwarding +#options IPFILTER_LKM#kernel support for ip_fil.o LKM optionsTCPDEBUG + +# The following options add sysctl variables for controlling how certain +# TCP packets are handled. +# +# TCP_RESTRICT_RST adds support for blocking the emission of TCP RST packets. +# This is useful on systems which are exposed to SYN floods (e.g. IRC servers) +# or any system which one does not want to be easily portscannable. +# +# TCP_DROP_SYNFIN adds
Re: Proposal for new syscall to close files
Peter Jeremy jere...@gsmx07.alcatel.com.au writes: If it ever gets committed (I don't think it's particularly useful myself), That's 2 against, 1 (me) for. Three against. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Squid - a bug in src/sys/kern/uipc_socket.c
Jaye Mathisen mr...@internetcds.com writes: Maybe it could be made a sysctl knob... No, a socket option would be more appropriate. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
TCP/IP hardening, take two
I cleaned up the previously posted patches, tested them a little more, and added a sysctl knob for logging SYN+FIN packets (before optionally dropping them). A FreeBSD 4.0-CURRENT machine with these patches and no firewall looks like this to nmap (with tcp.drop_synfin and tcp.restrict_rst enabled): | Starting nmap V. 2.12 by Fyodor (fyo...@dhp.com, www.insecure.org/nmap/) | Interesting ports on destmp.follo.net (195.204.143.235): | (Not showing ports in state: filtered) | PortState Protocol Service | 22 opentcpssh | | TCP Sequence Prediction: Class=random positive increments | Difficulty=38742 (Worthy challenge) | No OS matches for host (see http://www.insecure.org/cgi-bin/nmap-submit.cgi). | TCP/IP fingerprint: | TSeq(Class=RI%gcd=2%SI=1429) | TSeq(Class=RI%gcd=1%SI=1026) | TSeq(Class=RI%gcd=1%SI=9756) | T1(Resp=Y%DF=Y%W=402E%ACK=S++%Flags=AS%Ops=M) | T2(Resp=N) | T3(Resp=N) | T4(Resp=N) | T5(Resp=N) | T6(Resp=N) | T7(Resp=N) | PU(Resp=Y%DF=N%TOS=0%IPLEN=38%RIPTL=148%RID=F%RIPCK=F%UCK=0%ULEN=134%DAT=E) | | | Nmap run completed -- 1 IP address (1 host up) scanned in 75 seconds Note: The TCP sequence prediction difficulty rating is meaningless, Successive nmap runs show ratings from approx. 5000 to approx. 4 for the same computer with the same software. DES -- Dag-Erling Smorgrav - d...@yes.no Index: etc/defaults/rc.conf === RCS file: /home/ncvs/src/etc/defaults/rc.conf,v retrieving revision 1.23 diff -u -r1.23 rc.conf --- rc.conf 1999/07/26 10:49:33 1.23 +++ rc.conf 1999/07/27 11:18:30 @@ -48,6 +48,12 @@ tcp_extensions=NO# Set to Yes to turn on RFC1323 extensions. log_in_vain=NO # Disallow bad connection logging (or YES). tcp_keepalive=YES# Kill dead TCP connections (or NO). +tcp_drop_synfin=NO # Set to YES to drop TCP packets with SYN+FIN + # NOTE: this breaks rfc1644 extensions (T/TCP) +tcp_log_synfin=NO# Set to YES to log TCP packets with SYN+FIN +tcp_restrict_rst=NO # Set to YES to restrict emission of RST +icmp_dropredirect=NO # Set to YES to ignore ICMP REDIRECT packets +icmp_logredirect=NO # Set to YES to log ICMP REDIRECT packets network_interfaces=auto # List of network interfaces (or auto). ifconfig_lo0=inet 127.0.0.1 # default loopback device configuration. #ifconfig_lo0_alias0=inet 127.0.0.254 netmask 0x # Sample alias entry. Index: etc/rc.network === RCS file: /home/ncvs/src/etc/rc.network,v retrieving revision 1.52 diff -u -r1.52 rc.network --- rc.network 1999/07/26 15:17:23 1.52 +++ rc.network 1999/07/27 11:18:30 @@ -197,6 +197,16 @@ echo -n ' broadcast ping responses=YES' sysctl -w net.inet.icmp.bmcastecho=1 /dev/null fi + +if [ X$icmp_dropredirect = XYES ]; then + echo -n ' ignore ICMP redirect=YES' + sysctl -w net.inet.icmp.dropredirect=1 /dev/null +fi + +if [ X$icmp_logredirect = XYES ]; then + echo -n ' log ICMP redirect=YES' + sysctl -w net.inet.icmp.logredirect=1 /dev/null +fi if [ X$gateway_enable = XYES ]; then echo -n ' IP gateway=YES' @@ -216,6 +226,21 @@ if [ X$tcp_keepalive = XYES ]; then echo -n ' TCP keepalive=YES' sysctl -w net.inet.tcp.always_keepalive=1 /dev/null +fi + +if [ X$tcp_drop_synfin = XYES ]; then + echo -n ' drop SYN+FIN packets=YES' + sysctl -w net.inet.tcp.drop_synfin=1 /dev/null +fi + +if [ X$tcp_log_synfin = XYES ]; then + echo -n ' log SYN+FIN packets=YES' + sysctl -w net.inet.tcp.log_synfin=1 /dev/null +fi + +if [ X$tcp_restrict_rst = XYES ]; then + echo -n ' restrict TCP reset=YES' + sysctl -w net.inet.tcp.restrict_rst=1 /dev/null fi if [ X$ipxgateway_enable = XYES ]; then Index: sys/conf/options === RCS file: /home/ncvs/src/sys/conf/options,v retrieving revision 1.144 diff -u -r1.144 options --- options 1999/07/05 20:19:34 1.144 +++ options 1999/07/27 11:18:30 @@ -207,6 +207,8 @@ INET opt_inet.h IPDIVERT DUMMYNET opt_ipdn.h +IPFILTER opt_ipfilter.h +IPFILTER_LOG opt_ipfilter.h IPFIREWALL opt_ipfw.h IPFIREWALL_VERBOSE opt_ipfw.h IPFIREWALL_VERBOSE_LIMIT opt_ipfw.h @@ -220,11 +222,11 @@ PPP_BSDCOMPopt_ppp.h PPP_DEFLATEopt_ppp.h PPP_FILTER opt_ppp.h +SLIP_IFF_OPTS opt_slip.h TCP_COMPAT_42 opt_compat.h TCPDEBUG -IPFILTER opt_ipfilter.h -IPFILTER_LOG opt_ipfilter.h -SLIP_IFF_OPTS opt_slip.h +TCP_DROP_SYNFIN
replacing grep(1)
Jamie Howard (howar...@wam.umd.edu), with a little help from yours truly, has written a BSD-licensed version of grep(1) which has all the functionality of our current (GPLed) implementation, plus a little more, in one seventh the source code and one fourth the binary code. What's more, the code is actually possible for mere mortals to read and understand. The source code is available for download from freefall: URL:http://www.freebsd.org/~des/software/grep-0.7.tar.gz I move that we replace GNU grep in our source tree with this implementation, once it's been reviewed by all concerned parties. DES -- Dag-Erling Smorgrav - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: replacing grep(1)
Sheldon Hearn sheld...@uunet.co.za writes: Version 0.3 broke port-building badly. Does version 0.7 make it through a build of a whole stack of ports? Yes. DES -- Dag-Erling Smorgrav - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: replacing grep(1)
Brian F. Feldman gr...@freebsd.org writes: That's true. I'd like to see the replacement grep do mmaping of the input files if it doesn't already, as that would speed it up. Shouldn't be too hard to implement, the way file operations are abstracted. Patches? :) DES -- Dag-Erling Smorgrav - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: replacing grep(1)
Sheldon Hearn sheld...@uunet.co.za writes: In this case, the implementation we'll be introducing will introduce a performance loss, not a gain. Can you document that? As far as stability goes, there's a loss involved _if_ passing the GNU grep regression tests is important. Do you mean that Jamie's implementation doesn't pass those regression tests? If they don't, we can fix it before importing it into the tree. DES -- Dag-Erling Smorgrav - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: replacing grep(1)
Tim Vanderhoek vand...@ecf.utoronto.ca writes: Have you run your systems with J-grep as a replacement for GNU grep for a while (making sure nothing breaks)? Yes. There seems to be at least one dependency on GNU grep in /ports/Mk/bsd.port.mk where the -F argument is used. -F is implemented. DES -- Dag-Erling Smorgrav - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Free BSDI CD!
Brian F. Feldman gr...@freebsd.org writes: My point was that it's not a very important thing to do to give out FreeBSD CDs like BSD/OS gives out trial versions of their wares. Yes, it is. Try doing an FTP install across a 28k8 or 33k6 modem some time. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Linear buffers in VESA screen modes
Andrew Gordon a...@arg1.demon.co.uk writes: The application for which I need this is to support capture from the bktr driver onto the screen (ie. so that you can watch TV without X). With the above hack and a small (100-line) program it works very nicely - far tidier than installing X just for this purpose on some embedded systems where I need this capability. Might one persuade you to release that 100-line program? :) DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: replacing grep(1)
Tim Vanderhoek vand...@ecf.utoronto.ca writes: I do. Still far too slow. I'll work on this tomorrow, since that seems the only way to convince people that mmap is not such a big win. :-( mmap() gives a fourfold speed increase. I call that a big win. I have a few other ideas which will make 0.11 even faster. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: replacing grep(1)
James Howard howar...@wam.umd.edu writes: DES tells me he has a new version (0.10) which mmap()s. It supposedly cuts the run time down significantly, I do not have the numbers in front of me. Unfortunetly he has not posted this version yet so I cannot download it and run it myself. It's in the usual place (ftp://ftp.ofug.org/pub/grep/). He also says that if mmap fails, he drops back to stdio. This should only happen in the NFS case, the 2G case, etc. Any case in which a) the file is too large to mmap, b) the file is not a regular file, or c) mmap() fails (e.g. NFS). DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: replacing grep(1)
John-Mark Gurney gurne...@efn.org writes: it was VERY simple to do... and attached is the patch... this uses the option REG_STARTEND to do what the copy was trying to do... all of the code to use REG_STARTEND was already there, it just needed to be enabled.. Funnily, I experience a near-doubling of running time with similar patches. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: replacing grep(1)
Dag-Erling Smorgrav d...@flood.ping.uio.no writes: John-Mark Gurney gurne...@efn.org writes: it was VERY simple to do... and attached is the patch... this uses the option REG_STARTEND to do what the copy was trying to do... all of the code to use REG_STARTEND was already there, it just needed to be enabled.. Funnily, I experience a near-doubling of running time with similar patches. To be precise, I experience a 30% decrease in system time and a 100% increase in user time when I use RE_STARTEND and eliminate the malloc() / memcpy() calls in procfile(). DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: No MAXUID ?
Sheldon Hearn sheld...@uunet.co.za writes: Another question I should have asked in my original mail is this: are there magical reasons why we should want pwd_mkdb to bleat for every encountered UID greater that 65535 ? How many times do I have to go through this? There is no artificial limitation in pwd_mkdb. pwd_mkdb warns against UIDs larger than 65535 because legacy software that uses unsigned short instead of uid_t will break with large UIDs. There were even a few such cases in our tree that I fixed less than a year ago IIRC. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: No MAXUID ?
Sheldon Hearn sheld...@uunet.co.za writes: Would you be happy with changing things so that only one warning is generated? Something like 9 max_uid 65535: others may exist? The current behaviour is quite annoying with large passwd files. :-) Sure, and maybe modify the warning to say something like legacy software may not support UIDs larger than 65535 DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
grep-0.11
ftp://ftp.ofug.org/pub/grep/grep-0.11.tar.gz More (gprof-assisted) speedups. DES -- Dag-Erling Smorgrav - d...@yes.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
