Tyler K McGeorge wrote:
After I set up my BIND name daemon, I started getting the following message:
Jan 31 16:12:45 palisorrpc.statd: invalid hostname to sm_stat: (then a
whole bunch of gibberish, I would transcribe it, but it uses strange
characters that aren't available in
After I set up my BIND name daemon, I started
getting the following message:
Jan 31 16:12:45 palisor
rpc.statd: invalid hostname to sm_stat: (then a whole bunch of gibberish, I
would transcribe it, but it uses strange characters that aren't available in
Windows.)
I assume this means that
Luigi Rizzo wrote:
Hi,
I sent these files in private. But I remembered that I have another
unusual config in this machine: is is multiprocessed, and has 10 SCSI disks
and lots of SYSV shared memory.
i think SMP might have something to do with it. Yusuf, are you also
using an
Hi,
I don't want to bring flame war, but the following Linus' words may be
right:
-
The fact I dislike about the HP-UX implementation is that it is so obviously stupid.
And I have to say that I absolutely despise the BSD people. They did sendfile()
after both Linux and HP-UX had done it,
On Thu, Feb 01, 2001 at 01:31:39PM +0800, bsddiy wrote:
I don't want to bring flame war, but the following Linus' words may
be right:
Did you have a point to make here? If so, I missed it.
Kris
PGP signature
Tyler K McGeorge ([EMAIL PROTECTED]) wrote:
After I set up my BIND name daemon, I started getting the following message:
Jan 31 16:12:45 palisorrpc.statd: invalid hostname to sm_stat: (then a whole
bunch of gibberish, I would transcribe it, but it uses strange characters that aren't
CC: -stable, this seens not to be a -net related problem.
Yusuf Goolamabbas wrote:
Hi,
I sent these files in private. But I remembered that I have another
unusual config in this machine: is is multiprocessed, and has 10 SCSI disks
and lots of SYSV shared memory.
i think
No, but the problem is that there was no increase (actually, no
record at all) under ipsec: IPComp. The number on the sending
side seemed right. The increase matched the ones I saw from
tcpdump. It looked like the IPComp packets either weren't
logged or were
On Thu, 1 Feb 2001 [EMAIL PROTECTED] wrote:
Hi
Thanks for the replies.
Sorry, I forgot to say that I was using to the tunnel to connect to the
remote site with interface address of 132.146.113.1 and I am not using the
tunnels to send the packets to the local address, 132.146.115.164. I
Nick
Thanks for taking the time to reply to query. Here is more information that
may help you.
Having created the tunnel, I create a route to a node that I know is on the
other side of the tunnel. When I try to ping this site, or even the tunnel
end, I get a 'sendto: Network is down' reply
Hello Freebsd-net,
The following code has a problem with it. After 16000 or so connections
the my tcp connections run out of buffer space, which does not allow me to
make any new TCP connections and the system locks up. an netstat -an
revieles that there are about 100 sockets in TIME_WAIT
On Thu, 1 Feb 2001, David Greenman wrote:
I don't want to bring flame war, but the following Linus' words may be
right:
The FreeBSD API is the way it is after a collaboration with the Apache
folks. The sendfile() implementation in FreeBSD works just fine and I think
it has one of the
unsubscribe
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
On Thu, 1 Feb 2001 18:00:10 +, Tony Finch [EMAIL PROTECTED] said:
For this reason turning off TCP_CORK pushes out queued data, but
this isn't the case for TCP_NOPUSH.
This is a long-standing bug. You are welcome to fix it.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
On Thu, 1 Feb 2001 14:28:07 -0500 (EST), "Richard A. Steenbergen" [EMAIL PROTECTED]
said:
Then shortly thereafter, with the sockbuf only slightly drained, new
write events will come up in whatever polling method you're using,
and you get to fire off another 1000 syscalls just to add an
I don't want to bring flame war, but the following Linus' words may be
right:
The FreeBSD API is the way it is after a collaboration with the Apache
folks. The sendfile() implementation in FreeBSD works just fine and I think
it has one of the most complete API's of any of them out there.
[Bcc to net and ipfw as relevant there -- if you want a reply to
go to the lists you need to add them explicitly.]
Hi,
as some of you have noticed, i am trying to fix some long-standing
problems that we have had with bridging and dummynet, so I'd like
to comment on what I am doing and how.
* i
[EMAIL PROTECTED] wrote:
Hello!
We have a single firewall machine and a _separate_ machine running
squid proxy (both servers are on the same network wire).
How do I catch all of the outgoing http requests and send them through
squid?
I tried
ipfw add fwd squid,3128 tcp
* Matthew Luckie [EMAIL PROTECTED] [010201 13:13] wrote:
Hi there
I am willing to do some work to enable the kernel to do this, if it
currently cannot, if a committer is interested in adding this feature to
the kernel. However, I guess that this type of enhancement might not be
wanted.
I sent these files in private. But I remembered that I have another
unusual config in this machine: is is multiprocessed, and has 10 SCSI disks
and lots of SYSV shared memory.
i think SMP might have something to do with it. Yusuf, are you also
using an SMP box ?
Luigi Rizzo wrote:
I tried only removing DUMMYNET from config, and the bug continues. Should
I try the changes below?
no-they only affect dummynet. But this seems to suggest that
the problem is unrelated to my changes...
cheers
luigi
Hi,
I found the
Garrett Wollman [EMAIL PROTECTED] wrote:
Tony Finch [EMAIL PROTECTED] wrote:
For this reason turning off TCP_CORK pushes out queued data, but
this isn't the case for TCP_NOPUSH.
This is a long-standing bug. You are welcome to fix it.
I've been looking at this and it seems to me to be simply
On 1 Feb, Julian Elischer wrote:
= We have a single firewall machine and a _separate_ machine running
= squid proxy (both servers are on the same network wire).
=
= How do I catch all of the outgoing http requests and send them
= through squid?
=
= I tried
=
= ipfw add
Hi,
It turned out that the problem is in netinet/in_proto.c.
(It might have been fixed in -stable long ago, but not
in 4.2 release. :-)
yushun.
--- /usr/src/sys/netinet/in_proto.c Thu Feb 1 14:56:45 2001
+++ /usr/src/sys/netinet/in_proto.c.ORIGThu
Hi,
Another (sort of) related question: I've got the bandwidth
measurements for different algorthms using netperf. I was
really surprised that IPComp did so bad. Any ideas?
TCP UDP(Mbps) Ping(ms)Key(bits)
- Original Message -
From: "Tony Finch" [EMAIL PROTECTED]
To: "Kris Kennaway" [EMAIL PROTECTED]
Cc: "bsddiy" [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Friday, February 02, 2001 2:00 AM
Subject: Re: sendfile()
Kris Kennaway [EMAIL PROTECTED] wrote:
Linus's argument against
Another (sort of) related question: I've got the bandwidth
measurements for different algorthms using netperf. I was
really surprised that IPComp did so bad. Any ideas?
thanks for measurements, it's good to see.
i guess couple of reasons here.
-
thanks for tracking this problem -- it also explains
why i did not see it in my environment, as i have a mostly 4.2-R
system with new code in net/ and netinet/
cheers
luigi
Hi,
I found the problem!
I started searching for the point where ipfw writes to the msgbuf,
28 matches
Mail list logo
