Running mgetty on a bunch of modems on various machines, I will
occasionally run across one that looks like:
rimmer:/usr4/mike$ ps alx|grep cuaR11
0 1371 1 0 4 0 9168 ttywai IE??0:00.02
/usr/local/sbin/mgetty cuaR11
...with "ttywai" as the WCHAN and "E" in the STAT
On Sat, Nov 18, 2000 at 03:54:46PM +0100, Jesper Skriver wrote:
On Fri, Nov 17, 2000 at 02:29:04PM -0800, Alfred Perlstein wrote:
* Jesper Skriver [EMAIL PROTECTED] [001117 12:11] wrote:
[snip]
This timeout could be avoided if the sending mail server reacted to the
'ICMP
On Sat, Nov 18, 2000 at 06:36:32PM +0100, Jesper Skriver wrote:
I'll see if I can get code together which will do this.
I've now got this working (diff attached), it was actually quite
simple when I got a grip on what was going on in sys/netinet/, I'm
gratefull for comments.
Now I need to get
This patch seems like it will do the wrong thing for ICMP messages that
are associated with non-TCP packets. It looks like ICMP unreachable
messages for UDP packets will never get delivered to UDP sockets.
louie
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe
On Sun, Nov 19, 2000 at 04:03:04PM -0500, Louis A. Mamakos wrote:
This patch seems like it will do the wrong thing for ICMP messages that
are associated with non-TCP packets. It looks like ICMP unreachable
messages for UDP packets will never get delivered to UDP sockets.
Yep - I've come
On Sun, Nov 19, 2000 at 10:04:51PM +0100, Jesper Skriver wrote:
On Sun, Nov 19, 2000 at 04:03:04PM -0500, Louis A. Mamakos wrote:
This patch seems like it will do the wrong thing for ICMP messages that
are associated with non-TCP packets. It looks like ICMP unreachable
messages for
On Wed, Nov 15, 2000 at 07:01:35PM +0200, Peter Pentchev wrote:
On Wed, Nov 15, 2000 at 08:47:22AM -0800, Alfred Perlstein wrote:
* Peter Pentchev [EMAIL PROTECTED] [001115 06:19] wrote:
All right, feel free to flame me a LOT for what follows :)
No need for that. (yet) :-)
On Wed, 15 Nov 2000, Mike Smith wrote:
I have been having a great time :-) debugging a device driver,
and have run into a really fun way to panic. With one type
of traffic, [something] happens and the kernel drops into
DDB, just the way I want.
[snip panic info]
This is pretty
It would seem more appropriate, somehow, to push the response to the
ICMP message up into the protocols where they can take the appropriate
action. Of course, the problem is that the PRC_* abstracted codes may
not be rich enough to express all the semantics you'd wish to convey.
So one goal
On Sun, 19 Nov 2000, Jesper Skriver wrote:
A coworker of mine got into "rfc mode" and found the below, as we both
read it, it says that we MUST treat a ICMP unreachable like a TCP RST.
##
... A transport protocol
that has
As mentioned in pr bin/22965, I stumbled across a bug
in libc/gen/getcap.c when compiling it under other
platforms. The basic problem is some code which does:
(void)fclose(pfp);
if (ferror(pfp)) {
...do stuff...
}
I find it surprising that the above
On Sat, 18 Nov 2000, Maxime Henrion wrote:
Hi,
I was wondering if it was reasonnable to implement the select() and poll()
system calls as kqueue()/kevent() wrappers. This would make any application
using these system calls benefit from the performance improvements of the new
kernel
Hi All:)
I'm testing a honking reverse resolver system for use in resolving web
logs. It's an Abit KT7 system with 1.1 GHz processor and 768 MB of ECC
ram running 4.1-stable as of about a month ago.
I'm looking up the IP addresses with up to 1500 or so processes each
taking a list of addresses
* David Miller [EMAIL PROTECTED] [001119 20:30] wrote:
Hi All:)
I'm testing a honking reverse resolver system for use in resolving web
logs. It's an Abit KT7 system with 1.1 GHz processor and 768 MB of ECC
ram running 4.1-stable as of about a month ago.
I'm looking up the IP addresses
On Fri, 17 Nov 2000, Alfred Perlstein wrote:
This timeout could be avoided if the sending mail server reacted to the
'ICMP administratively prohibited' they got from our router.
$ telnet nemo.dyndns.dk 25
Trying 193.89.247.125...
telnet: Unable to connect to remote host: No route to
On Sun, Nov 19, 2000 at 11:45:50PM -0500, David Miller wrote:
I've had the suggestion to up maxusers to 512. I'm a little leery of
this, having heard of problems 128 on this list for seemingly years. Is
there a better way to size the network buffers and anything else which
needs to be
I need to do MX lookups in a threaded program, does anyone know if
the res_ functions are thread safe, or if there's an alternative
I can use that is?
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe:
17 matches
Mail list logo
