TCP input processing bug
I think I've located a problem in TCP input processing...and it has been there for quite a while. It breaks half-open connection discovery for many cases since version 1.15 of netinet/tcp_input.c (committed by Garrett Wollman, which is why this is Cc'd to him), although that isn't where the (presumably) incorrect behavior was introduced. The half-open connection discovery problem can be reproduced easily, the conditions required are: - Machine A thinks it has an established connection with machine B - Machine B disagrees (it has crashed, the network has been down, maybe has been recently assigned the IP of another machine that disconnected unnicely etc., there are a lot of conditions that can cause this) - Machine B tries to connect to machine A using the same source port number as the half-open connection - Machine B selects a sequence number below the current window expected by machine A Machine B sends a SYN, but gets nothing as a reply (it should be getting an ACK), no matter how many times it tries. Machine A will keep the connection in an established state until it tries to send data (depending on the application, this may never happen) or is timed out by keepalives. This is particularly nasty if the boot procedure of machine B establishes a TCP connection to machine A - after a crash, it'll always try to use the same port number and never succeed. Basically, in the tcp_input function, just before ACK processing, when 'goto drop' is done if ACK isn't set, TF_ACKNOW might be set in tp-t_flags, but the ACK is never sent because tcp_output is never called. This can be fixed by checking for TF_ACKNOW in the drop: case and calling tcp_output if it is set. However, such a modification can change the behavior of a considerable number of cases so I think it needs careful verification. Anyone who knows the TCP code, please comment! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/sys/kern imgact_gzip.c
On Tue, 22 Jun 1999, Kris Kennaway wrote:
On Tue, 22 Jun 1999, Brian F. Feldman wrote:
Date: Tue, 22 Jun 1999 01:08:04 -0400 (EDT)
From: Brian F. Feldman [EMAIL PROTECTED]
To: Kris Kennaway [EMAIL PROTECTED]
Cc: Peter Wemm [EMAIL PROTECTED], Jean-Marc Zucconi [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: cvs commit: src/sys/kern imgact_gzip.c
On Tue, 22 Jun 1999, Kris Kennaway wrote:
On Tue, 22 Jun 1999, Peter Wemm wrote:
Ahh yes, I forgot that / was read-write for MFS boots. However:
#!/bin/sh
skip=18
if /usr/bin/tail +$skip $0 | gzip -cd /tmp/gztmp$$; then
chmod 700 /tmp/gztmp$$
prog="`echo $0 | sed 's|^.*/||'`"
if /bin/ln /tmp/gztmp$$ "/tmp/$prog" 2/dev/null; then
trap '/bin/rm -f /tmp/gztmp$$ "/tmp/$prog"; exit $res' 0
(/bin/sleep 5; /bin/rm -f /tmp/gztmp$$ "/tmp/$prog") 2/dev/null
/tmp/"$prog" ${1+"$@"}; res=$?
else
trap '/bin/rm -f /tmp/gztmp$$; exit $res' 0
(/bin/sleep 5; /bin/rm -f /tmp/gztmp$$) 2/dev/null
/tmp/gztmp$$ ${1+"$@"}; res=$?
fi
else
echo Cannot decompress $0; exit 1
fi; exit $res
This is the unpatched (insecure) version of gzexe (all the /tmp/gztmp$$'s),
but it's functionally the same.
Now, if tail, sh, gzip, chmod, ln, sleep, rm, etc are all in the gzexe'd
crunched linked binary, how is it supposed to decompress itself? "sh" itself
is part of the crunched binary, so what is going to decode sh when sh itself
is a shell script?
Yes, that seems to be a problem - gzexe depends on those executables. However
it shouldn't be too hard to recode this decompressor in C to perform the same
job without any external dependencies. The question is whether that would be
easier than fixing the kernel to handle gzipped ELF binaries transparently -
almost certainly it would be.
How's what I attached?
[Context left in for cross-post to hackers]
Hmm..I don't have a deflate on my system. This should be linked static as
well, otherwise you need the runtime linker + libraries, and that has a 69k
overhead (when stripped). Possibly this could be optimized further..I don't
know if this is small enough to be useful however.
It's a proof of concept, it didn't need to be static. I don't have a program
to do deflate either. What I know is that you said it would be hard, but
it was not very hard to make a framework to do what gzexe does in C.
Mike's suggestion of a gzipped MFS image is probably best for things like boot
floppies.
Kris
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
-
"Never criticize anybody until you have walked a mile in their shoes,
because by that time you will be a mile away and have their shoes."
-- Unknown
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/sys/kern imgact_gzip.c
On Wed, 23 Jun 1999, Kris Kennaway wrote: On Tue, 22 Jun 1999, Brian F. Feldman wrote: Hmm..I don't have a deflate on my system. This should be linked static as well, otherwise you need the runtime linker + libraries, and that has a 69k overhead (when stripped). Possibly this could be optimized further..I don't know if this is small enough to be useful however. It's a proof of concept, it didn't need to be static. I don't have a program to do deflate either. What I know is that you said it would be hard, but it was not very hard to make a framework to do what gzexe does in C. Actually: The question is whether that would be easier than fixing the kernel to handle gzipped ELF binaries transparently - almost certainly it would be. I said it would be easy(ier) :) FWIW, compiling libc.a and libz.a with -Os brings the overhead down to 67416 bytes per executable. Linked dynamically it's 4829 bytes (i.e. the other 62k is library code), so it doesn't look like there's much room for improvement. This sure seems like enough to replace a.out gzip support. Taking the compression/decompression routines out of the kernel would save memory and result in roughly the same amount of space being used. If we had a deflate program, this would work quite well =) Kris - "Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes." -- Unknown To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mysterious problem with 2.2.x binary on 3.1
Hi, I have a mysterious problem with running a 2.2.6 binary (dynamically linked) on a 3.1 box. The crazy thing is that it has worked flawlessly before. After doing a bit of development and compiling it again, I get segfaults when I try to run it on the 3.1 box. When I try it with an a.out gdb (ftp'ed from the 2.2.6 box) I get this: ./gdb web-ssql GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc... (gdb) r -v Starting program: /home/bowtie/web-ssql -v reading register eip (#8): Bad address. (gdb) (3.1) ldd web-ssql: ldd web-ssql web-ssql: -lcrypt.2 = /usr/lib/aout/libcrypt.so.2.0 (0x200a3000) -lm.2 = /usr/lib/aout/libm.so.2.0 (0x200b8000) -lc.3 = /usr/lib/aout/libc.so.3.1 (0x200d2000) (2.2.6) ldd web-ssql: web-ssql: -lcrypt.2 = /usr/lib/libcrypt.so.2.0 (0x200ab000) -lm.2 = /usr/lib/libm.so.2.0 (0x200ae000) -lc.3 = /usr/lib/libc.so.3.1 (0x200c8000) When I link the binary statically it works ok, but unfortunately I need it to be dynamically linked. Does anyone recognize this behaviour? And even better knows whats going on? Regards, Marc. Marc van Kempen BowTie Technology Email: [EMAIL PROTECTED]WWW Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Serial Console Wierdness
'cu' hangs up really easily. use 'kermit' (it's in ports) and the hangup problem will disappear. i tried to find an option to cu to modify its hangup behavior but to no avail. your second problem sounds like it could be terminal sizing -- have you tried this with a default 80x24 window, set and exported TERM properly, etc? i was not able to get my console to work properly past 38400 baud; i am not sure why. 38400 has been just fine speed-wise for me, though, so i'm not that upset. :) (also see http://www.arctic.org/~aaron/tips/freebsd-serial-console) aaron On Tue, 22 Jun 1999 13:31:33 EDT, "Bill G." writes: I got a serial console working on COM2, to which I have connected another FreeBSD box. I connect with 'cu' fine, but I'm running into a couple of problems which I haven't been able to find and answer for. o When I connect, when the machine is first turned on, I get disconnected twice during the boot up sequence (cu reports Got hangup signal) -- looks like when the sio1 device is probed, and also when getty runs. o 9600 was rather slow, so I changed it to 115200, which worked, however I had a few problems with terminal display -- any output that scrolls down past the bottom of the screen gets 'garbled'. (IE, I run clear; ls -l / -- the first 23 lines look ok then it gets messed up). Same results from console mode of my client machine and from an xterm. I thought that 115200 might be too fast, so I slowed it down to 38400, but same trouble. I'm not sure if this occured at 9600. Any thoughts / ideas / suggestions would be appreciated. Thanks, To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isasio.c)
On Tue, 22 Jun 1999, Hellmuth Michaelis wrote: From the keyboard of Nick Hibma: And as to the author: Writing docu while you are implementing something might work in a commercial environment where you want to be able to market something before it's sell-by date, but for hobbiests who basically spend the odd evening doing something, it is too much hassle. In case FreeBSD wants to enter commercial environments, we have to behave like behaving in commercial environments. I know that it is current behaviour, much easier and obviously a commonly accepted thing that code, subsystem and/or changes are not and need not to be documented, but this is not a reason in itself for not changing this. Also, i think that the argument Mike and others use: "don't complain for a lack of things, contribute!" - which i use and used all the time - is not valid for this issue: at least i can't contribute because i don't understand things (now someone could argue, that i'm wrong here ...). The last thing i want is a flamewar on this topic and i don't write this because i want to piss onto someones shoes. And i don't write about a man page for "ls" or "more" but a fundamental change in FreeBSD's inner architecture. Writing software in one's spare time is a case of triage. When I have a day or two to spend working on FreeBSD, I have to make a choice on what most needs doing and if that is a choice between technical writing or designing an algorithm to fix the current limitations of driver detach and KLD unload, I don't think the technical writing is going to win. People must also bear in mind that the most important target release for this software is 4.0 which isn't scheduled until next year. I am certain that the documentation situation will improve before that release. -- Doug Rabson Mail: [EMAIL PROTECTED] Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: CDROM drive doesn't probe if no CD present [Was:cannot mount cd indicates bad ide cd drive - replace?]
I'm lofting this up on -hackers to get the attention of the ATAPI CD driver programmer -- Soren, you still around? Take a look at this. On Tue, 22 Jun 1999, Woody Carey wrote: Ok, here is some more information: Here is the behavior when there is no cd in the drive at bootup [reboot, actually] ^M^[[Kmyname# mount /cdrom cd9660: Input/output error myname# dmesg [...] wdc0: unit 1 (atapi): ATAPI CDROM/V2.10, removable, accel, dma, iordy acd0: drive speed 0 - 4125KB/sec, 128KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked and here is the dmesg output and mount output with a cd in the drive at boot: myname# dmesg [...] wdc0: unit 1 (atapi): ATAPI CDROM/V2.10, removable, accel, dma, iordy acd0: drive speed 4125KB/sec, 128KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked myname# mount /cdrom There was some success message on the console after this mount indicating success. It did not appear in this script output, obviously. Bizarre. That may be a driver bug or your drive is getting into an inconsistent state if it doesn't boot with a CD present. What brand/model of CD drive is it? Doug White Internet: [EMAIL PROTECTED]| FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite| www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
* Mark Newton ([EMAIL PROTECTED]) [990622 17:38]: Hellmuth Michaelis wrote: And as to the author: Writing docu while you are implementing something might work in a commercial environment where you want to be able to market something before it's sell-by date, but for hobbiests who basically spend the odd evening doing something, it is too much hassle. In case FreeBSD wants to enter commercial environments, we have to behave like behaving in commercial environments. Ok, so let's follow Microsoft's industry-leading documentation standards. Blah, this argument is, pardon my french, utter bullshit. If one looks at, the now deceased, DEC Unix and it's programmer's manuals, ye see what Hellmuth tries to put down with his statement. In fact I have a couple of those pdf/ps files printed out and they make for TOP CLASS programmer's material. Needless to say I hope to reach this level of excellence with the PDP as well... It's all a matter of time and effort and unfortunately not many care to take the time to document, but rather hack on. (And somewhere that's very understandable.) -- Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl The *BSD Programmer's Documentation Project Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: We are back and will not accept no... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
* Mike Smith ([EMAIL PROTECTED]) [990622 17:38]: And they might, too. phk has frequently expressed a desire to either write documentation on existing systems, or at least help others do so. No offence meant, but we can see how much of this has actually materialised. Hence I started the PDP =P Still going strong... Documentation is written after the fact, by someone else. That's the worst kind of documentation. In fact, most UNIX documentation is written by the authors. After the fact, admittedly. In fact, most Unix documentation is never written, being my original point. Which sucks given all the crap the same people tend to spew then about Microsoft being very closed about their internals. No documentation is worse than just a sparse manpage. The latter at least makes it more understanding for all without doing too much UTSL. And given the aspirations the Project has with regard to commercial support I find the silent encouragement of just hack and not document disturbing to say the very least. As always, complaining about the _lack_ of something is the wrong approach for this project. Step up and fill the gap, or expose yourself to criticism for failing to do so. There has to be a way to make a verb from Brett Glass' name, but I'm sure you get the point. And I did/am doing that with the PDP, which at it current rate of support (that is just me ;) whill be finished somewhere when FreeBSD 6.5 will be released or so, but I am not complaining about that =) I am not fingerpointing here, not am I willing to. I just want to ask all developers to try and document at least the basic ideas somewhere in a manpage in order to make it easier for others (like me) who want to get the documentation on the road. Thanks, -- Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl The *BSD Programmer's Documentation Project Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: We are back and will not accept no... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
2.2.7 + NBUF + NMBCLUSTERS
Hoi folx, I have a 2.2.7 system that runs out of mbuf clusters. maxuser 64 I've raised options NMBCLUSTERS=6144 options NBUF=3072 and that made it for a while. However the system is running a chatserver and a webserver of a customer and now it hits me again. Are there any problems in raising it to options NMBCLUSTERS=16384 options NBUF=8192 Does this combination make sense at all? (in the LINT file NBUF was half the value of NMBCLUSTERS, so I kept this). Thanks \Maex -- SpaceNet GmbH | http://www.Space.Net/ | Yeah, yo mama dresses Research Development| mailto:[EMAIL PROTECTED] | you funny and you need Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0| a mouse to delete files D-80807 Muenchen | Fax: +49 (89) 32356-299 | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
On Tuesday, 22 June 1999 at 1:42:05 -0700, Mike Smith wrote:
And they might, too. phk has frequently expressed a desire to either
write documentation on existing systems, or at least help others do
so.
No offence meant, but we can see how much of this has actually
materialised.
None taken. But if it hasn't happened yet, it's not phk's fault. The
real problem is a general attitude: UTSL. Sure, a good hacker can get
by with the source, but good documentation makes for a smoother
project.
It has never happened that way (anywhere, on any project),
Of course it has. It's just uncommon in the FreeBSD environment. In
many large projects, you don't do any code until you have a clear
definition of what you're going to do.
It's uncommon in _most_ environments. Or perhaps tech writers exist
for some other purpose?
I don't know too many UNIX tech writers.
and it never will.
My father never had a computer, and his father never did, so I never
will have one. What an argument.
The circumstances aren't comparable.
Why not? In each case, you're resisting change.
Documentation is written after the fact, by someone else.
That's the worst kind of documentation. In fact, most UNIX
documentation is written by the authors. After the fact, admittedly.
In fact, most Unix documentation is never written, being my original
point.
That doesn't make it a desirable or unchangeable situation.
Hopefully the change of subject line and recipients will get some more
representative views on this subject.
Perhaps I should have been clearer; the sort of documentation that the
original set of plaintiffs were asking for is the mythical "describe
everything as it was, is and will be, and make it constantly
representative and up to date".
This clarifies your interpretation of the situation. In fact, I was
the "original plaintiff", and I wrote:
Nice to know there's a man page. But the real thing is that the
"right thing" to do needs to be documented somewhere. It would be
nice, for example, to have an overview of the design principles. Yes,
I know I'm asking for a lot here, but it would really help.
These are the same people that will complain about disparities
between any extant documentation and reality, as well as carp
incessantly about the lack of some form of documentation other than
what already exists ("why isn't there a permuted index?" "where's
the sanskrit translation?"
I think you're reading more into this than was stated.
"my cat can't read _this_!").
Put in a PR. cat should be able to read anything.
As always, complaining about the _lack_ of something is the wrong
approach for this project. Step up and fill the gap, or expose
yourself to criticism for failing to do so. There has to be a way
to make a verb from Brett Glass' name, but I'm sure you get the
point.
"To glass"?
Yes, I'm a firm believer in "if it's broke, fix it yourself". I'm
also not complaining about the current situation; it's probably too
late for that. But it would be really nice if we could cultivate this
concept of describing what you're doing while you're doing it.
Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
In message [EMAIL PROTECTED] Jeroen Ruigrok/Asmodai writes: : Granted, we can never think of reaching a commercial level on documentating : the internals/code which all the committers provide. I think that the documenation that Doug has written to date EXCEEDS so called commercial standards. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: inetd/tcpd...changing hosts.allow...plus a documentation issue
Sheldon Hearn scribbled this message on Jun 21: You can expect the internal wrapping fixes and the SIGHUP bugfix to be merged back to STABLE soon (within a week). I'm in no rush, and I'm glad I didn't rush, since David Malone has already uncovered a bug in the handling of maxchild, which I believe is worth fixing before the merge. :-) you should, because this is a problem in 3.2-R... and we see this on a box we reciently upgraded from 2.2.7 to 3.2-R and it exhibits this behavior, so, when will it be merged? and what files need to be updated? -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought. -- Ralph Waldo Emerson To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: SMP and Celerons...
On Sat, Jun 19, 1999 at 04:57:25PM -0600, Warner Losh wrote: By broke, I mean that they don't scale well due to cache effects. I think it may just be a size thing, but it might also be a cache coherency protocol ineffeciencies as well. The articles I've seen show that for typical workloads, people with two celerons were getting in the 1.5x range, while people with PIIs were getting 1.8x or so. Warnr Warner, Don't suppose you have a URL handy for those articles? I'm contemplating building a dual-Celery box so it's probably good to know this stuff. Although, with the Celerons over here selling for around half the price of an equivalent P-II they'd have to scale real bad to put me off the idea :-) Even if the performance sucks, I'll have an otherwise well-specced box that I can upgrade to P-II's as I can afford it. Cheers, Scott -- === Scott Mitchell | PGP Key ID | Eagles may soar, but weasels London, England | 0x54B171B9 | don't get sucked into jet engines s.mitch...@computer.org | 0xAA775B8B | -- Anon To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: SMP and Celerons...
In message 19990620193722.51...@goatsucker.org Scott Mitchell writes: : Don't suppose you have a URL handy for those articles? I'm contemplating : building a dual-Celery box so it's probably good to know this stuff. : Although, with the Celerons over here selling for around half the price of : an equivalent P-II they'd have to scale real bad to put me off the idea :-) : Even if the performance sucks, I'll have an otherwise well-specced box that : I can upgrade to P-II's as I can afford it. You might want to look at Ars Technica http://www.arstechnica.com/'s back issues, or HardOCP (http://www.hardocp.com). bxboards (http://www.bxboards.com/ pops up from tiem to time as well. Warner 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]
On Mon, 21 Jun 1999 12:10:47 MST, Doug wrote: In fact, the man page is correct, however the inetd code currently has an outdated version of the canonical name. Thus, at minimum the man page should be udpated to reflect this reality. A better solution would be to remove the hard coded values in the code, and fix the config file. It took me a bit of playing to find the problem, since the PR doesn't say if I use service name ``auth'' instead of ``inetd'', I get the following error message from inetd: internal service auth unknown That's the kind of thing I was looking for when I asked you (twice) to send a useful How-To-Repeat. It doesn't help that people who've run into the problem understand the vague description provided, because I haven't run into it. Now that I understand the problem, I'd like to put forward this proposal: The manual pages for services(5), inetd(8) and inetd.conf(5) are adequate if inetd accepts both canonical service names _and_ aliases. Therefore a healthy, backward-compatible change that is unlikely to accept existing users is to teach inetd to understand service name aliases. I'm not yet saying that this is possible, but I am saying that I'll look into it if it'd make you happy. Whatever your preference is, I'd suggest dropping freebsd-hackers from further discussion. Now that we all understand each other, it's probably more appropriate that the conversation continue on PR feedback only. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
On Mon, 21 Jun 1999 17:47:10 -0400, John Baldwin wrote: I suppose you could a field wrap/nowrap like the wait/nowait field.. but then you'd be butchering the sacred cow of the inetd.conf format... I don't see why people want to make inetd responsible for per-case exclusions from the default wrapping behaviour -- that's what hosts.allow was for. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
On Tuesday, 22 June 1999 at 1:23:24 -0700, Mike Smith wrote: Anyway, i don't think you are asking for too much - of what use is a shiny new design of a new subsystem in the very basic FreeBSD architecture if just some handful few people knew how it works and how to use it ? Gosh, that would make it just like every other shiny new subsystem. Folks, just cut the carping and write your own documentation. The architects can't, Of course they can. and won't write it for you. And they might, too. phk has frequently expressed a desire to either write documentation on existing systems, or at least help others do so. I'm in the process of writing technical docs for Vinum. The biggest problem is knowing what to write and how to describe it. It has never happened that way (anywhere, on any project), Of course it has. It's just uncommon in the FreeBSD environment. In many large projects, you don't do any code until you have a clear definition of what you're going to do. and it never will. My father never had a computer, and his father never did, so I never will have one. What an argument. Documentation is written after the fact, by someone else. That's the worst kind of documentation. In fact, most UNIX documentation is written by the authors. After the fact, admittedly. Hopefully the change of subject line and recipients will get some more representative views on this subject. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key 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)
And they might, too. phk has frequently expressed a desire to either write documentation on existing systems, or at least help others do so. No offence meant, but we can see how much of this has actually materialised. It has never happened that way (anywhere, on any project), Of course it has. It's just uncommon in the FreeBSD environment. In many large projects, you don't do any code until you have a clear definition of what you're going to do. It's uncommon in _most_ environments. Or perhaps tech writers exist for some other purpose? and it never will. My father never had a computer, and his father never did, so I never will have one. What an argument. The circumstances aren't comparable. Documentation is written after the fact, by someone else. That's the worst kind of documentation. In fact, most UNIX documentation is written by the authors. After the fact, admittedly. In fact, most Unix documentation is never written, being my original point. Hopefully the change of subject line and recipients will get some more representative views on this subject. Perhaps I should have been clearer; the sort of documentation that the original set of plaintiffs were asking for is the mythical describe everything as it was, is and will be, and make it constantly representative and up to date. These are the same people that will complain about disparities between any extant documentation and reality, as well as carp incessantly about the lack of some form of documentation other than what already exists (why isn't there a permuted index? where's the sanskrit translation? my cat can't read _this_!). As always, complaining about the _lack_ of something is the wrong approach for this project. Step up and fill the gap, or expose yourself to criticism for failing to do so. There has to be a way to make a verb from Brett Glass' name, but I'm sure you get the point. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com 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: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
In short: Where's the patch? And as to the author: Writing docu while you are implementing something might work in a commercial environment where you want to be able to market something before it's sell-by date, but for hobbiests who basically spend the odd evening doing something, it is too much hassle. Writing the manual after the fact or manuals written by someone else are far easier to get coherent and useful. Nick Perhaps I should have been clearer; the sort of documentation that the original set of plaintiffs were asking for is the mythical describe everything as it was, is and will be, and make it constantly representative and up to date. These are the same people that will complain about disparities between any extant documentation and reality, as well as carp incessantly about the lack of some form of documentation other than what already exists (why isn't there a permuted index? where's the sanskrit translation? my cat can't read _this_!). As always, complaining about the _lack_ of something is the wrong approach for this project. Step up and fill the gap, or expose yourself to criticism for failing to do so. There has to be a way to make a verb from Brett Glass' name, but I'm sure you get the point. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy 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)
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
Hellmuth Michaelis wrote: And as to the author: Writing docu while you are implementing something might work in a commercial environment where you want to be able to market something before it's sell-by date, but for hobbiests who basically spend the odd evening doing something, it is too much hassle. In case FreeBSD wants to enter commercial environments, we have to behave like behaving in commercial environments. Ok, so let's follow Microsoft's industry-leading documentation standards. - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223 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)
And as to the author: Writing docu while you are implementing something might work in a commercial environment where you want to be able to market something before it's sell-by date, but for hobbiests who basically spend the odd evening doing something, it is too much hassle. In case FreeBSD wants to enter commercial environments, we have to behave like behaving in commercial environments. Ok, so let's follow Microsoft's industry-leading documentation standards. Hm, it might be hard to find people using FreeBSD without any technical skills whatsoever. :) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
On 22-Jun-99 Sheldon Hearn wrote: On Mon, 21 Jun 1999 17:47:10 -0400, John Baldwin wrote: I suppose you could a field wrap/nowrap like the wait/nowait field.. but then you'd be butchering the sacred cow of the inetd.conf format... I don't see why people want to make inetd responsible for per-case exclusions from the default wrapping behaviour -- that's what hosts.allow was for. Because that only controls access, it does not actually turn wrapping off. Wrapping also logs as well as access control. If you use ftp -l -l, then the ftp daemon will produce the same log messages, thus there is no need to have them twice, except to eat up disk space. And if you are only using wrapping for logging purposes, then turning off wrapping on ftpd then cuts out the duplicate messages, allowing you to store more actual logs instead of wasting space on dup's. It's also more orthogonal to allow an on/off switch for each service. Ciao, Sheldon. --- John Baldwin jobal...@vt.edu -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc Power Users Use the Power to Serve! - http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
On Tue, 22 Jun 1999 07:04:29 -0400, John Baldwin wrote: Because that only controls access, it does not actually turn wrapping off. Let me be more specific; if you don't want ftpd wrapped, just add ftpd: ALL : ALLOW to your /etc/hosts.allow . A stock configuration won't log successful connections, so you won't see any logging at all. Asking for command-line switches and/or inetd.conf directives that allow per-case exclusions seems to me like asking for duplicate functionality that isn't required (or is that tautology? :-). Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
TCP input processing bug
I think I've located a problem in TCP input processing...and it has been there for quite a while. It breaks half-open connection discovery for many cases since version 1.15 of netinet/tcp_input.c (committed by Garrett Wollman, which is why this is Cc'd to him), although that isn't where the (presumably) incorrect behavior was introduced. The half-open connection discovery problem can be reproduced easily, the conditions required are: - Machine A thinks it has an established connection with machine B - Machine B disagrees (it has crashed, the network has been down, maybe has been recently assigned the IP of another machine that disconnected unnicely etc., there are a lot of conditions that can cause this) - Machine B tries to connect to machine A using the same source port number as the half-open connection - Machine B selects a sequence number below the current window expected by machine A Machine B sends a SYN, but gets nothing as a reply (it should be getting an ACK), no matter how many times it tries. Machine A will keep the connection in an established state until it tries to send data (depending on the application, this may never happen) or is timed out by keepalives. This is particularly nasty if the boot procedure of machine B establishes a TCP connection to machine A - after a crash, it'll always try to use the same port number and never succeed. Basically, in the tcp_input function, just before ACK processing, when 'goto drop' is done if ACK isn't set, TF_ACKNOW might be set in tp-t_flags, but the ACK is never sent because tcp_output is never called. This can be fixed by checking for TF_ACKNOW in the drop: case and calling tcp_output if it is set. However, such a modification can change the behavior of a considerable number of cases so I think it needs careful verification. Anyone who knows the TCP code, please comment! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/sys/kern imgact_gzip.c
On Tue, 22 Jun 1999, Brian F. Feldman wrote:
Date: Tue, 22 Jun 1999 01:08:04 -0400 (EDT)
From: Brian F. Feldman gr...@unixhelp.org
To: Kris Kennaway kkenn...@physics.adelaide.edu.au
Cc: Peter Wemm pe...@netplex.com.au, Jean-Marc Zucconi j...@freebsd.org,
h...@freebsd.org, cvs-committ...@freebsd.org, cvs-...@freebsd.org
Subject: Re: cvs commit: src/sys/kern imgact_gzip.c
On Tue, 22 Jun 1999, Kris Kennaway wrote:
On Tue, 22 Jun 1999, Peter Wemm wrote:
Ahh yes, I forgot that / was read-write for MFS boots. However:
#!/bin/sh
skip=18
if /usr/bin/tail +$skip $0 | gzip -cd /tmp/gztmp$$; then
chmod 700 /tmp/gztmp$$
prog=`echo $0 | sed 's|^.*/||'`
if /bin/ln /tmp/gztmp$$ /tmp/$prog 2/dev/null; then
trap '/bin/rm -f /tmp/gztmp$$ /tmp/$prog; exit $res' 0
(/bin/sleep 5; /bin/rm -f /tmp/gztmp$$ /tmp/$prog) 2/dev/null
/tmp/$prog ${1+$@}; res=$?
else
trap '/bin/rm -f /tmp/gztmp$$; exit $res' 0
(/bin/sleep 5; /bin/rm -f /tmp/gztmp$$) 2/dev/null
/tmp/gztmp$$ ${1+$@}; res=$?
fi
else
echo Cannot decompress $0; exit 1
fi; exit $res
This is the unpatched (insecure) version of gzexe (all the /tmp/gztmp$$'s),
but it's functionally the same.
Now, if tail, sh, gzip, chmod, ln, sleep, rm, etc are all in the gzexe'd
crunched linked binary, how is it supposed to decompress itself? sh
itself
is part of the crunched binary, so what is going to decode sh when sh
itself
is a shell script?
Yes, that seems to be a problem - gzexe depends on those executables.
However
it shouldn't be too hard to recode this decompressor in C to perform the
same
job without any external dependencies. The question is whether that would be
easier than fixing the kernel to handle gzipped ELF binaries transparently -
almost certainly it would be.
How's what I attached?
[Context left in for cross-post to hackers]
Hmm..I don't have a deflate on my system. This should be linked static as
well, otherwise you need the runtime linker + libraries, and that has a 69k
overhead (when stripped). Possibly this could be optimized further..I don't
know if this is small enough to be useful however.
Mike's suggestion of a gzipped MFS image is probably best for things like boot
floppies.
Kris
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
-
Never criticize anybody until you have walked a mile in their shoes,
because by that time you will be a mile away and have their shoes.
-- Unknown
#!/bin/sh
of=`basename $1`_z
cs=$of.c
cat $cs .
#include sys/types.h
#include sys/mman.h
#include sys/wait.h
#include sys/stat.h
#include zlib.h
#include err.h
#include unistd.h
#include stdio.h
$(deflate $1 | file2c 'u_char program[] = { ' ' };')
int
main(int argc, char **argv) {
int status;
u_long destLen = sizeof(program);
void *outputaddr;
char outputname[256];
int outputfd;
snprintf(outputname, sizeof(outputname), %s.XX, argv[0]);
if ((outputfd = mkstemp(outputname)) == -1)
err(1, mkstemp);
outputaddr = mmap(NULL, destLen, PROT_WRITE, MAP_SHARED, outputfd, 0);
if (outputaddr == MAP_FAILED)
err(1, mmap);
status = uncompress(outputaddr, destLen, program, sizeof(program));
switch (status) {
case Z_MEM_ERROR:
err(1, Z_MEM_ERROR);
case Z_BUF_ERROR:
err(1, Z_BUF_ERROR);
case Z_DATA_ERROR:
err(1, Z_DATA_ERROR);
default:
break;
}
msync(outputaddr, 0, MS_SYNC);
munmap(outputaddr, destLen);
ftruncate(outputfd, destLen);
fchmod(outputfd, 0755);
close(outputfd);
switch (fork()) {
case 0:
execv(outputname, argv);
case -1:
err(1, fork);
default:
wait(status);
}
unlink(outputname);
exit(status);
}
.
cc -lz -O -Wall $cs -o $of
rm $cs
Re: cvs commit: src/sys/kern imgact_gzip.c
On Tue, 22 Jun 1999, Kris Kennaway wrote:
On Tue, 22 Jun 1999, Brian F. Feldman wrote:
Date: Tue, 22 Jun 1999 01:08:04 -0400 (EDT)
From: Brian F. Feldman gr...@unixhelp.org
To: Kris Kennaway kkenn...@physics.adelaide.edu.au
Cc: Peter Wemm pe...@netplex.com.au, Jean-Marc Zucconi j...@freebsd.org,
h...@freebsd.org, cvs-committ...@freebsd.org, cvs-...@freebsd.org
Subject: Re: cvs commit: src/sys/kern imgact_gzip.c
On Tue, 22 Jun 1999, Kris Kennaway wrote:
On Tue, 22 Jun 1999, Peter Wemm wrote:
Ahh yes, I forgot that / was read-write for MFS boots. However:
#!/bin/sh
skip=18
if /usr/bin/tail +$skip $0 | gzip -cd /tmp/gztmp$$; then
chmod 700 /tmp/gztmp$$
prog=`echo $0 | sed 's|^.*/||'`
if /bin/ln /tmp/gztmp$$ /tmp/$prog 2/dev/null; then
trap '/bin/rm -f /tmp/gztmp$$ /tmp/$prog; exit $res' 0
(/bin/sleep 5; /bin/rm -f /tmp/gztmp$$ /tmp/$prog) 2/dev/null
/tmp/$prog ${1+$@}; res=$?
else
trap '/bin/rm -f /tmp/gztmp$$; exit $res' 0
(/bin/sleep 5; /bin/rm -f /tmp/gztmp$$) 2/dev/null
/tmp/gztmp$$ ${1+$@}; res=$?
fi
else
echo Cannot decompress $0; exit 1
fi; exit $res
This is the unpatched (insecure) version of gzexe (all the
/tmp/gztmp$$'s),
but it's functionally the same.
Now, if tail, sh, gzip, chmod, ln, sleep, rm, etc are all in the gzexe'd
crunched linked binary, how is it supposed to decompress itself? sh
itself
is part of the crunched binary, so what is going to decode sh when sh
itself
is a shell script?
Yes, that seems to be a problem - gzexe depends on those executables.
However
it shouldn't be too hard to recode this decompressor in C to perform the
same
job without any external dependencies. The question is whether that would
be
easier than fixing the kernel to handle gzipped ELF binaries
transparently -
almost certainly it would be.
How's what I attached?
[Context left in for cross-post to hackers]
Hmm..I don't have a deflate on my system. This should be linked static as
well, otherwise you need the runtime linker + libraries, and that has a 69k
overhead (when stripped). Possibly this could be optimized further..I don't
know if this is small enough to be useful however.
It's a proof of concept, it didn't need to be static. I don't have a program
to do deflate either. What I know is that you said it would be hard, but
it was not very hard to make a framework to do what gzexe does in C.
Mike's suggestion of a gzipped MFS image is probably best for things like boot
floppies.
Kris
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
-
Never criticize anybody until you have walked a mile in their shoes,
because by that time you will be a mile away and have their shoes.
-- Unknown
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/sys/kern imgact_gzip.c
On Tue, 22 Jun 1999, Brian F. Feldman wrote: Hmm..I don't have a deflate on my system. This should be linked static as well, otherwise you need the runtime linker + libraries, and that has a 69k overhead (when stripped). Possibly this could be optimized further..I don't know if this is small enough to be useful however. It's a proof of concept, it didn't need to be static. I don't have a program to do deflate either. What I know is that you said it would be hard, but it was not very hard to make a framework to do what gzexe does in C. Actually: The question is whether that would be easier than fixing the kernel to handle gzipped ELF binaries transparently - almost certainly it would be. I said it would be easy(ier) :) FWIW, compiling libc.a and libz.a with -Os brings the overhead down to 67416 bytes per executable. Linked dynamically it's 4829 bytes (i.e. the other 62k is library code), so it doesn't look like there's much room for improvement. Kris - Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes. -- Unknown To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
On Tue, 22 Jun 1999, Sheldon Hearn wrote: On Tue, 22 Jun 1999 07:04:29 -0400, John Baldwin wrote: Because that only controls access, it does not actually turn wrapping off. Let me be more specific; if you don't want ftpd wrapped, just add ftpd: ALL : ALLOW to your /etc/hosts.allow . A stock configuration won't log successful connections, so you won't see any logging at all. But if you can turn off wrapping, you can save a fork()/exec() per connection. -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
On Tue, 22 Jun 1999 14:53:28 GMT, Ben Rosengart wrote: But if you can turn off wrapping, you can save a fork()/exec() per connection. The only exec is an execv() at line 740 of inetd.c, which launches the program that will service a request. It's done irrespective of wrapping. So you can save a fork, not an exec. Forks are cheap. I'm not really opposed to having command-line options for per-case exclusions -- I'm just opposed to doing the work myself if it doesn't gain us anything significant. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
On Tue, 22 Jun 1999, Sheldon Hearn wrote: On Tue, 22 Jun 1999 14:53:28 GMT, Ben Rosengart wrote: But if you can turn off wrapping, you can save a fork()/exec() per connection. The only exec is an execv() at line 740 of inetd.c, which launches the program that will service a request. It's done irrespective of wrapping. So you can save a fork, not an exec. Forks are cheap. Oh, duh. I was still thinking in terms of tcpd, not libwrap. -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/sys/kern imgact_gzip.c
On Wed, 23 Jun 1999, Kris Kennaway wrote: On Tue, 22 Jun 1999, Brian F. Feldman wrote: Hmm..I don't have a deflate on my system. This should be linked static as well, otherwise you need the runtime linker + libraries, and that has a 69k overhead (when stripped). Possibly this could be optimized further..I don't know if this is small enough to be useful however. It's a proof of concept, it didn't need to be static. I don't have a program to do deflate either. What I know is that you said it would be hard, but it was not very hard to make a framework to do what gzexe does in C. Actually: The question is whether that would be easier than fixing the kernel to handle gzipped ELF binaries transparently - almost certainly it would be. I said it would be easy(ier) :) FWIW, compiling libc.a and libz.a with -Os brings the overhead down to 67416 bytes per executable. Linked dynamically it's 4829 bytes (i.e. the other 62k is library code), so it doesn't look like there's much room for improvement. This sure seems like enough to replace a.out gzip support. Taking the compression/decompression routines out of the kernel would save memory and result in roughly the same amount of space being used. If we had a deflate program, this would work quite well =) Kris - Never criticize anybody until you have walked a mile in their shoes, because by that time you will be a mile away and have their shoes. -- Unknown To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
mysterious problem with 2.2.x binary on 3.1
Hi, I have a mysterious problem with running a 2.2.6 binary (dynamically linked) on a 3.1 box. The crazy thing is that it has worked flawlessly before. After doing a bit of development and compiling it again, I get segfaults when I try to run it on the 3.1 box. When I try it with an a.out gdb (ftp'ed from the 2.2.6 box) I get this: ./gdb web-ssql GDB is free software and you are welcome to distribute copies of it under certain conditions; type show copying to see the conditions. There is absolutely no warranty for GDB; type show warranty for details. GDB 4.16 (i386-unknown-freebsd), Copyright 1996 Free Software Foundation, Inc... (gdb) r -v Starting program: /home/bowtie/web-ssql -v reading register eip (#8): Bad address. (gdb) (3.1) ldd web-ssql: ldd web-ssql web-ssql: -lcrypt.2 = /usr/lib/aout/libcrypt.so.2.0 (0x200a3000) -lm.2 = /usr/lib/aout/libm.so.2.0 (0x200b8000) -lc.3 = /usr/lib/aout/libc.so.3.1 (0x200d2000) (2.2.6) ldd web-ssql: web-ssql: -lcrypt.2 = /usr/lib/libcrypt.so.2.0 (0x200ab000) -lm.2 = /usr/lib/libm.so.2.0 (0x200ae000) -lc.3 = /usr/lib/libc.so.3.1 (0x200c8000) When I link the binary statically it works ok, but unfortunately I need it to be dynamically linked. Does anyone recognize this behaviour? And even better knows whats going on? Regards, Marc. Marc van Kempen BowTie Technology Email: m...@bowtie.nlWWW Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Serial Console Wierdness
I got a serial console working on COM2, to which I have connected another FreeBSD box. I connect with 'cu' fine, but I'm running into a couple of problems which I haven't been able to find and answer for. o When I connect, when the machine is first turned on, I get disconnected twice during the boot up sequence (cu reports Got hangup signal) -- looks like when the sio1 device is probed, and also when getty runs. o 9600 was rather slow, so I changed it to 115200, which worked, however I had a few problems with terminal display -- any output that scrolls down past the bottom of the screen gets 'garbled'. (IE, I run clear; ls -l / -- the first 23 lines look ok then it gets messed up). Same results from console mode of my client machine and from an xterm. I thought that 115200 might be too fast, so I slowed it down to 38400, but same trouble. I'm not sure if this occured at 9600. Any thoughts / ideas / suggestions would be appreciated. Thanks, Bill To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Serial Console Wierdness
'cu' hangs up really easily. use 'kermit' (it's in ports) and the hangup problem will disappear. i tried to find an option to cu to modify its hangup behavior but to no avail. your second problem sounds like it could be terminal sizing -- have you tried this with a default 80x24 window, set and exported TERM properly, etc? i was not able to get my console to work properly past 38400 baud; i am not sure why. 38400 has been just fine speed-wise for me, though, so i'm not that upset. :) (also see http://www.arctic.org/~aaron/tips/freebsd-serial-console) aaron On Tue, 22 Jun 1999 13:31:33 EDT, Bill G. writes: I got a serial console working on COM2, to which I have connected another FreeBSD box. I connect with 'cu' fine, but I'm running into a couple of problems which I haven't been able to find and answer for. o When I connect, when the machine is first turned on, I get disconnected twice during the boot up sequence (cu reports Got hangup signal) -- looks like when the sio1 device is probed, and also when getty runs. o 9600 was rather slow, so I changed it to 115200, which worked, however I had a few problems with terminal display -- any output that scrolls down past the bottom of the screen gets 'garbled'. (IE, I run clear; ls -l / -- the first 23 lines look ok then it gets messed up). Same results from console mode of my client machine and from an xterm. I thought that 115200 might be too fast, so I slowed it down to 38400, but same trouble. I'm not sure if this occured at 9600. Any thoughts / ideas / suggestions would be appreciated. Thanks, 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)
On Tue, 22 Jun 1999, Hellmuth Michaelis wrote: From the keyboard of Nick Hibma: And as to the author: Writing docu while you are implementing something might work in a commercial environment where you want to be able to market something before it's sell-by date, but for hobbiests who basically spend the odd evening doing something, it is too much hassle. In case FreeBSD wants to enter commercial environments, we have to behave like behaving in commercial environments. I know that it is current behaviour, much easier and obviously a commonly accepted thing that code, subsystem and/or changes are not and need not to be documented, but this is not a reason in itself for not changing this. Also, i think that the argument Mike and others use: don't complain for a lack of things, contribute! - which i use and used all the time - is not valid for this issue: at least i can't contribute because i don't understand things (now someone could argue, that i'm wrong here ...). The last thing i want is a flamewar on this topic and i don't write this because i want to piss onto someones shoes. And i don't write about a man page for ls or more but a fundamental change in FreeBSD's inner architecture. Writing software in one's spare time is a case of triage. When I have a day or two to spend working on FreeBSD, I have to make a choice on what most needs doing and if that is a choice between technical writing or designing an algorithm to fix the current limitations of driver detach and KLD unload, I don't think the technical writing is going to win. People must also bear in mind that the most important target release for this software is 4.0 which isn't scheduled until next year. I am certain that the documentation situation will improve before that release. -- Doug Rabson Mail: d...@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Serial Console Wierdness
Aaron, At 10:39 AM 6/22/99 -0700, you wrote: 'cu' hangs up really easily. use 'kermit' (it's in ports) and the hangup problem will disappear. i tried to find an option to cu to modify its hangup behavior but to no avail. Problem 1 solved! Thanks. Kermit works great! your second problem sounds like it could be terminal sizing -- have you tried this with a default 80x24 window, set and exported TERM properly, etc? Ack! I could have sworn it didn't work from text-mode cons25 before, but now it is. for some reason, I cannot get it to work from an xterm...I tried TERM=xterm xterm-color ...also I tried setting stty cols and rows no luck... i was not able to get my console to work properly past 38400 baud; i am not sure why. 38400 has been just fine speed-wise for me, though, so i'm not that upset. :) (also see http://www.arctic.org/~aaron/tips/freebsd-serial-console) Nice page! I was going to write one up, but yours looks good... Bill To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Serial Console Wierdness
On Tue, Jun 22, 1999 at 02:35:22PM -0400, Bill G wrote: Aaron, At 10:39 AM 6/22/99 -0700, you wrote: 'cu' hangs up really easily. use 'kermit' (it's in ports) and the hangup problem will disappear. i tried to find an option to cu to modify its hangup behavior but to no avail. Problem 1 solved! Thanks. Kermit works great! On one of my machines this problem does not disappear with kermit; I get Communications disconnect (Back at host). Regards --- Udo Schweigert || Voice : +49 89 636 42170 Siemens AG, Siemens CERT|| Fax: +49 89 636 48000 ZT IK 3 || email : udo.schweig...@mchp.siemens.de D-81730 Muenchen / Germany ||: u...@cert.siemens.de PGP fingerprint || 2A 53 F6 A6 30 59 64 02 6B C4 E0 73 B2 C9 6C E7 --- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: CDROM drive doesn't probe if no CD present [Was:cannot mount cd indicates bad ide cd drive - replace?]
I'm lofting this up on -hackers to get the attention of the ATAPI CD driver programmer -- Soren, you still around? Take a look at this. On Tue, 22 Jun 1999, Woody Carey wrote: Ok, here is some more information: Here is the behavior when there is no cd in the drive at bootup [reboot, actually] ^M^[[Kmyname# mount /cdrom cd9660: Input/output error myname# dmesg [...] wdc0: unit 1 (atapi): ATAPI CDROM/V2.10, removable, accel, dma, iordy acd0: drive speed 0 - 4125KB/sec, 128KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: no/blank disc inside, unlocked and here is the dmesg output and mount output with a cd in the drive at boot: myname# dmesg [...] wdc0: unit 1 (atapi): ATAPI CDROM/V2.10, removable, accel, dma, iordy acd0: drive speed 4125KB/sec, 128KB cache acd0: supported read types: CD-R, CD-RW, CD-DA acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray acd0: Medium: CD-ROM 120mm data disc loaded, unlocked myname# mount /cdrom There was some success message on the console after this mount indicating success. It did not appear in this script output, obviously. Bizarre. That may be a driver bug or your drive is getting into an inconsistent state if it doesn't boot with a CD present. What brand/model of CD drive is it? Doug White Internet: dwh...@resnet.uoregon.edu| FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite| www.freebsd.org 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)
* Doug Rabson (d...@nlsystems.com) [990622 20:48]: On Tue, 22 Jun 1999, Hellmuth Michaelis wrote: From the keyboard of Nick Hibma: And as to the author: Writing docu while you are implementing something might work in a commercial environment where you want to be able to market something before it's sell-by date, but for hobbiests who basically spend the odd evening doing something, it is too much hassle. In case FreeBSD wants to enter commercial environments, we have to behave like behaving in commercial environments. I know that it is current behaviour, much easier and obviously a commonly accepted thing that code, subsystem and/or changes are not and need not to be documented, but this is not a reason in itself for not changing this. Also, i think that the argument Mike and others use: don't complain for a lack of things, contribute! - which i use and used all the time - is not valid for this issue: at least i can't contribute because i don't understand things (now someone could argue, that i'm wrong here ...). Writing software in one's spare time is a case of triage. When I have a day or two to spend working on FreeBSD, I have to make a choice on what most needs doing and if that is a choice between technical writing or designing an algorithm to fix the current limitations of driver detach and KLD unload, I don't think the technical writing is going to win. I can perfectly understand that, and I like to fill that gap. The gap being the lack of documentation. Granted, we can never think of reaching a commercial level on documentating the internals/code which all the committers provide. To think that is either dreaming far into the future or just being foolish. However there is a certain amount of documentation that can be done, skeletal manpages, good sourcecode comments, and the likes that make filling in the abovementioned gap easier for those who (are willing and) have the time to do this. People must also bear in mind that the most important target release for this software is 4.0 which isn't scheduled until next year. I am certain that the documentation situation will improve before that release. It is already getting improved upon Doug. And as a sidenote, so is asking feedback for pr's what Sheldon is doing a lot and which I tend to assist him in. -- Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl The *BSD Programmer's Documentation Project Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: We are back and will not accept 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)
* Mark Newton (new...@internode.com.au) [990622 17:38]: Hellmuth Michaelis wrote: And as to the author: Writing docu while you are implementing something might work in a commercial environment where you want to be able to market something before it's sell-by date, but for hobbiests who basically spend the odd evening doing something, it is too much hassle. In case FreeBSD wants to enter commercial environments, we have to behave like behaving in commercial environments. Ok, so let's follow Microsoft's industry-leading documentation standards. Blah, this argument is, pardon my french, utter bullshit. If one looks at, the now deceased, DEC Unix and it's programmer's manuals, ye see what Hellmuth tries to put down with his statement. In fact I have a couple of those pdf/ps files printed out and they make for TOP CLASS programmer's material. Needless to say I hope to reach this level of excellence with the PDP as well... It's all a matter of time and effort and unfortunately not many care to take the time to document, but rather hack on. (And somewhere that's very understandable.) -- Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl The *BSD Programmer's Documentation Project Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: We are back and will not accept 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)
* Mike Smith (m...@smith.net.au) [990622 17:38]: And they might, too. phk has frequently expressed a desire to either write documentation on existing systems, or at least help others do so. No offence meant, but we can see how much of this has actually materialised. Hence I started the PDP =P Still going strong... Documentation is written after the fact, by someone else. That's the worst kind of documentation. In fact, most UNIX documentation is written by the authors. After the fact, admittedly. In fact, most Unix documentation is never written, being my original point. Which sucks given all the crap the same people tend to spew then about Microsoft being very closed about their internals. No documentation is worse than just a sparse manpage. The latter at least makes it more understanding for all without doing too much UTSL. And given the aspirations the Project has with regard to commercial support I find the silent encouragement of just hack and not document disturbing to say the very least. As always, complaining about the _lack_ of something is the wrong approach for this project. Step up and fill the gap, or expose yourself to criticism for failing to do so. There has to be a way to make a verb from Brett Glass' name, but I'm sure you get the point. And I did/am doing that with the PDP, which at it current rate of support (that is just me ;) whill be finished somewhere when FreeBSD 6.5 will be released or so, but I am not complaining about that =) I am not fingerpointing here, not am I willing to. I just want to ask all developers to try and document at least the basic ideas somewhere in a manpage in order to make it easier for others (like me) who want to get the documentation on the road. Thanks, -- Jeroen Ruigrok van der Wervenasmodai(at)wxs.nl The *BSD Programmer's Documentation Project Network/Security Specialist http://home.wxs.nl/~asmodai *BSD: We are back and will not accept no... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
2.2.7 + NBUF + NMBCLUSTERS
Hoi folx, I have a 2.2.7 system that runs out of mbuf clusters. maxuser 64 I've raised options NMBCLUSTERS=6144 options NBUF=3072 and that made it for a while. However the system is running a chatserver and a webserver of a customer and now it hits me again. Are there any problems in raising it to options NMBCLUSTERS=16384 options NBUF=8192 Does this combination make sense at all? (in the LINT file NBUF was half the value of NMBCLUSTERS, so I kept this). Thanks \Maex -- SpaceNet GmbH | http://www.Space.Net/ | Yeah, yo mama dresses Research Development| mailto:maex-...@space.net | you funny and you need Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0| a mouse to delete files D-80807 Muenchen | Fax: +49 (89) 32356-299 | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
3.x NFS patchset
There is a backported version of MAtt's NFS fixes at: ftp://ftp.whistle.com/pub/julian/nfs-3.diffs These include Andrew's fix to the fix results apreciated. If you've been having NFS server side problems on 3.x check these out.. julian To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Jeroen Ruigrok/Asmodai's project
Dear Jeroen Ruigrok/Asmodai: I received your email concerning your documentation project a week ago. I tried to respond a couple of times, but I could not reach your private email address. I have written a much longer email. Anyway, I am afraid that being a one year old newbie I could not help as much as you expect. I appreciate all the help I have received from you and others on this list. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
vi(1) is for whimps
vi(1) is for whimps http://www.geocities.com/SiliconValley/Lab/1986/viforwhimps.html --- I'd rather pay for my freedom than live in a bitmapped, pop-up-happy dungeon like NT. http://www.performancecomputing.com/features/9809of1.shtml Get free e-mail and a permanent address at http://www.netaddress.com/?N=1 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
On 22-Jun-99 Sheldon Hearn wrote: On Tue, 22 Jun 1999 07:04:29 -0400, John Baldwin wrote: Because that only controls access, it does not actually turn wrapping off. Let me be more specific; if you don't want ftpd wrapped, just add ftpd: ALL : ALLOW That still wraps, it just allows everyone in. to your /etc/hosts.allow . A stock configuration won't log successful connections, so you won't see any logging at all. But if I want to log *all* connections to service foo, but not bar, I could not use tcpd for foo and and bar by itself and achieve that, so you are removing some configurability. If very few people use this extra configurability and if it is a pain to add it in, then I guess it's no real big deal. Asking for command-line switches and/or inetd.conf directives that allow per-case exclusions seems to me like asking for duplicate functionality that isn't required (or is that tautology? :-). Actually, it's asking for functionality that exists with TCP wrappers, but not with the integrated inetd. Like I said, though, if no one but me is going to miss it, and it is non-trivial to implement, then don't bother. OTOH, if it is trivial to implement, then why remove functionality? Ciao, Sheldon. --- John Baldwin jobal...@vt.edu -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc Power Users Use the Power to Serve! - http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: vi(1) is for whimps
On Tue, Jun 22, 1999, Jesus Monroy wrote: vi(1) is for whimps http://www.geocities.com/SiliconValley/Lab/1986/viforwhimps.html Well, you should've posted that to -chat... Second, there are other things people use vi for. You can't add a sentence to a paragraph with cat as easily as you could with vi, such as: So as I headed to the bakery to get some new bread, I decided to stop at the newspaper stand and pick up the sunday paper. So as I headed to the bakery to get some new, delicious white bread, I decided to stop at the newspaper stand to pick up the Sunday edition of the Houston Chronicle. vi is for people who want to get things done the right way with a standard tool that is meant for editing files. If you want to be pedantic, you shouldn't use 'cat' at all for editing files! cat is meant to catenate two or more files to stdout. Try ed. (Although, if taken properly, the page is a good laugh) --- I'd rather pay for my freedom than live in a bitmapped, pop-up-happy dungeon like NT. http://www.performancecomputing.com/features/9809of1.shtml Get free e-mail and a permanent address at http://www.netaddress.com/?N=1 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- Chris Costelloch...@calldei.com I bet the human brain is a kludge. - Marvin Minsky 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)
On Tuesday, 22 June 1999 at 1:42:05 -0700, Mike Smith wrote: And they might, too. phk has frequently expressed a desire to either write documentation on existing systems, or at least help others do so. No offence meant, but we can see how much of this has actually materialised. None taken. But if it hasn't happened yet, it's not phk's fault. The real problem is a general attitude: UTSL. Sure, a good hacker can get by with the source, but good documentation makes for a smoother project. It has never happened that way (anywhere, on any project), Of course it has. It's just uncommon in the FreeBSD environment. In many large projects, you don't do any code until you have a clear definition of what you're going to do. It's uncommon in _most_ environments. Or perhaps tech writers exist for some other purpose? I don't know too many UNIX tech writers. and it never will. My father never had a computer, and his father never did, so I never will have one. What an argument. The circumstances aren't comparable. Why not? In each case, you're resisting change. Documentation is written after the fact, by someone else. That's the worst kind of documentation. In fact, most UNIX documentation is written by the authors. After the fact, admittedly. In fact, most Unix documentation is never written, being my original point. That doesn't make it a desirable or unchangeable situation. Hopefully the change of subject line and recipients will get some more representative views on this subject. Perhaps I should have been clearer; the sort of documentation that the original set of plaintiffs were asking for is the mythical describe everything as it was, is and will be, and make it constantly representative and up to date. This clarifies your interpretation of the situation. In fact, I was the original plaintiff, and I wrote: Nice to know there's a man page. But the real thing is that the right thing to do needs to be documented somewhere. It would be nice, for example, to have an overview of the design principles. Yes, I know I'm asking for a lot here, but it would really help. These are the same people that will complain about disparities between any extant documentation and reality, as well as carp incessantly about the lack of some form of documentation other than what already exists (why isn't there a permuted index? where's the sanskrit translation? I think you're reading more into this than was stated. my cat can't read _this_!). Put in a PR. cat should be able to read anything. As always, complaining about the _lack_ of something is the wrong approach for this project. Step up and fill the gap, or expose yourself to criticism for failing to do so. There has to be a way to make a verb from Brett Glass' name, but I'm sure you get the point. To glass? Yes, I'm a firm believer in if it's broke, fix it yourself. I'm also not complaining about the current situation; it's probably too late for that. But it would be really nice if we could cultivate this concept of describing what you're doing while you're doing it. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key 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)
On Tuesday, 22 June 1999 at 19:34:14 +0930, Mark Newton wrote: Hellmuth Michaelis wrote: And as to the author: Writing docu while you are implementing something might work in a commercial environment where you want to be able to market something before it's sell-by date, but for hobbiests who basically spend the odd evening doing something, it is too much hassle. In case FreeBSD wants to enter commercial environments, we have to behave like behaving in commercial environments. Ok, so let's follow Microsoft's industry-leading documentation standards. He said commercial, not toy. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key 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)
On Tuesday, 22 June 1999 at 19:19:47 +0100, Doug Rabson wrote: On Tue, 22 Jun 1999, Hellmuth Michaelis wrote: From the keyboard of Nick Hibma: And as to the author: Writing docu while you are implementing something might work in a commercial environment where you want to be able to market something before it's sell-by date, but for hobbiests who basically spend the odd evening doing something, it is too much hassle. In case FreeBSD wants to enter commercial environments, we have to behave like behaving in commercial environments. I know that it is current behaviour, much easier and obviously a commonly accepted thing that code, subsystem and/or changes are not and need not to be documented, but this is not a reason in itself for not changing this. Also, i think that the argument Mike and others use: don't complain for a lack of things, contribute! - which i use and used all the time - is not valid for this issue: at least i can't contribute because i don't understand things (now someone could argue, that i'm wrong here ...). The last thing i want is a flamewar on this topic and i don't write this because i want to piss onto someones shoes. And i don't write about a man page for ls or more but a fundamental change in FreeBSD's inner architecture. Writing software in one's spare time is a case of triage. When I have a day or two to spend working on FreeBSD, I have to make a choice on what most needs doing and if that is a choice between technical writing or designing an algorithm to fix the current limitations of driver detach and KLD unload, I don't think the technical writing is going to win. People must also bear in mind that the most important target release for this software is 4.0 which isn't scheduled until next year. I am certain that the documentation situation will improve before that release. Doug, before you get the wrong impression, I don't think anybody's criticizing you. My intention was to raise the awareness of the importance, not of low-level documentation, but of this is why we did it this way, and this is how to use it kind of documentation; much of it could be in mail messages, but it's stuff which only the authors can really explain. Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Serial Console Wierdness
Bill G. wrote: I got a serial console working on COM2, to which I have connected another FreeBSD box. I connect with 'cu' fine, but I'm running into a couple of problems which I haven't been able to find and answer for. o When I connect, when the machine is first turned on, I get disconnected twice during the boot up sequence (cu reports Got hangup signal) -- looks like when the sio1 device is probed, and also when getty runs. This happens when the serial chip gets reset, and the DCD line goes low for a moment. For most local serial connections, you really want to tie the DCD pin back to the DTR/DSR. If you use rj45 modular adapters, this is fairly easy. I find the following wiring to be rather convenient, as you have a single type of adapter, which can used for just about anything. If you use a crossed ethernet cable, you will get a null cable, otherwise it will be straight through. Signal DB25 DB9 RJ45Color ,--DCD 8 1 NC | TXD 2 3 1 Blue | RXD 3 2 3 Black +--DTR 20 4 NC | SG 7 5 7 Brown `--DSR 6 6 NC RTS 4 7 2 Orange CTS 5 8 6 Yellow Hope this is of some use.. Chris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Porting strategy - pine4 + SSL
I have made a preliminary patch (hack?) to add SSL to pine (it's like
clicking the 'server requires secure connection' box - POP or IMAP over
SSL).
The pine4 port is fairly involved. Adding my stuff is almost downright
trivial. It amounts to adding
BUILD_DEPENDS= ${PREFIX}/lib/libssl.a:${PORTSDIR}/security/SSLeay \
${PREFIX}/lib/libcrypto.a:${PORTSDIR}/security/SSLeay \
${PREFIX}/lib/libRSAglue.a:${PORTSDIR}/security/SSLeay \
${PREFIX}/lib/librsaref.a:${PORTSDIR}/security/rsaref
RESTRICTED= Contains cryptography - no export from US
DISTFILES+= pine4+ssl-1.0
MASTER_SITES+= ftp://ftp.kfu.com/pub/
(the pine4+ssl-1.0.tar.gz file isn't there yet. :-) )
and modifying the Makefile to add EXTRAAUTHENTICATORS=ssl to the end
of the build command.
How should I do this? Should I copy the pine4 port entirely?
Should I modify the existing pine4 adding conditional stuff to
handle ssl? Can someone suggest a hackish way to piggyback onto
the existing pine4 port with a new port consisting only of the
steps above, but preserving the steps of the original port?
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Porting strategy - pine4 + SSL
* From: Nick Sayer nsa...@quack.kfu.com
*
* I have made a preliminary patch (hack?) to add SSL to pine (it's like
* clicking the 'server requires secure connection' box - POP or IMAP over
* SSL).
*
* The pine4 port is fairly involved. Adding my stuff is almost downright
* trivial. It amounts to adding
*
*
* BUILD_DEPENDS= ${PREFIX}/lib/libssl.a:${PORTSDIR}/security/SSLeay \
* ${PREFIX}/lib/libcrypto.a:${PORTSDIR}/security/SSLeay \
* ${PREFIX}/lib/libRSAglue.a:${PORTSDIR}/security/SSLeay \
* ${PREFIX}/lib/librsaref.a:${PORTSDIR}/security/rsaref
*
* RESTRICTED= Contains cryptography - no export from US
*
* DISTFILES+= pine4+ssl-1.0
* MASTER_SITES+= ftp://ftp.kfu.com/pub/
*
* (the pine4+ssl-1.0.tar.gz file isn't there yet. :-) )
*
* and modifying the Makefile to add EXTRAAUTHENTICATORS=ssl to the end
* of the build command.
*
* How should I do this? Should I copy the pine4 port entirely?
* Should I modify the existing pine4 adding conditional stuff to
* handle ssl? Can someone suggest a hackish way to piggyback onto
* the existing pine4 port with a new port consisting only of the
* steps above, but preserving the steps of the original port?
(1) Change pine4/Makefile to define stuff like PKGNAME with ?= and
*_DEPENDS with +=
(2) Set MASTERDIR=${.CURDIR}/../pine4 and put the above plus
.include ${MASTERDIR}/Makefile in pine4-ssl/Makefile.
You may need to supply pkg/* files separately.
Satoshi
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)
In message 19990622214842.d15...@daemon.ninth-circle.org Jeroen Ruigrok/Asmodai writes: : Granted, we can never think of reaching a commercial level on documentating : the internals/code which all the committers provide. I think that the documenation that Doug has written to date EXCEEDS so called commercial standards. Warner 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)
In message 19990622214019.b15...@daemon.ninth-circle.org Jeroen Ruigrok/Asmodai writes: : No documentation is worse than just a sparse manpage. ls /usr/share/man/man9 | egrep newbus stuff bus_generic_attach.9.gz bus_generic_detach.9.gz bus_generic_map_intr.9.gz bus_generic_print_child.9.gz bus_generic_read_ivar.9.gz bus_generic_shutdown.9.gz bus_generic_write_ivar.9.gz devclass.9.gz devclass_add_driver.9.gz devclass_delete_driver.9.gz devclass_find.9.gz devclass_find_driver.9.gz devclass_get_device.9.gz devclass_get_devices.9.gz devclass_get_maxunit.9.gz devclass_get_name.9.gz devclass_get_softc.9.gz BUS_CONNECT_INTR.9.gz BUS_CREATE_INTR.9.gz BUS_PRINT_CHILD.9.gz BUS_READ_IVAR.9.gz BUS_WRITE_IVAR.9.gz DEVICE_ATTACH.9.gz DEVICE_DETACH.9.gz DEVICE_PROBE.9.gz DEVICE_SHUTDOWN.9.gz device.9.gz device_add_child.9.gz device_add_child_after.9.gz device_busy.9.gz device_delete_child.9.gz device_disable.9.gz device_enable.9.gz device_find_child.9.gz device_get_desc.9.gz device_get_devclass.9.gz device_get_driver.9.gz device_get_ivars.9.gz device_get_softc.9.gz device_get_state.9.gz device_get_unit.9.gz device_is_alive.9.gz device_is_enabled.9.gz device_probe_and_attach.9.gz device_set_desc.9.gz device_unbusy.9.gz driver.9.gz There may be more that I missed... Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
