Hi,
I've been experiencing problems with TCP connections. The symptoms are:
- I can't upload large (>5 KByte) files with ftp, the client reports
"stalled" at file position 19456; the server receives only the first
1024 Bytes of the file. Downloads work just fine.
- Sending mail (uucp-over-ip
On Dec 13, 2:42pm, "Richard A. Steenbergen" wrote:
} Subject: Re: Ratelimint Enhancement patch (Please Review One Last Time!)
} On Wed, 13 Dec 2000, Alfred Perlstein wrote:
} > Suppressing outgoing RST due to high rate of connections on an unopen
} > port (possible portscan): 202/200 pps
}
} It
Alfred Perlstein wrote:
>
> * Alfred Perlstein <[EMAIL PROTECTED]> [001213 14:20] wrote:
> > * Matt Dillon <[EMAIL PROTECTED]> [001213 13:07] wrote:
> > > :I believe that your changes have been sorely needed for many
> > > :years. While I would like to see regular mbufs given a callback
> > > :me
Hi,
You probably need to use tcpmssd from the ports (net/tcpmssd) or use the
recently added tcpmss option of PPP for you ADSL link.
Look in the archive of this list for TCP MSS and ADSL, and you will find all
the information you need.
You can also look at http://renaud.waldura.com/doc/freebsd-p
On Thu, 14 Dec 2000, Patrick Bihan-Faou wrote:
> Hi,
>
> You probably need to use tcpmssd from the ports (net/tcpmssd) or use the
> recently added tcpmss option of PPP for you ADSL link.
How long ago was this added to PPP?
Vince.
--
=
I think that it was added in the last 2 weeks. It is in the HEAD for sure.
It has not been commited in 4-STABLE yet.
Patrick.
> -Original Message-
> From: Vince Vielhaber [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 14, 2000 10:27 AM
> To: Patrick Bihan-Faou
> Cc: [EMAIL PROTECT
On Thu, 14 Dec 2000, Patrick Bihan-Faou wrote:
> I think that it was added in the last 2 weeks. It is in the HEAD for sure.
> It has not been commited in 4-STABLE yet.
Ok, that explains why I didn't see it in 4.2.
Thanks!
Vince.
--
==
I'm happy to announce this problem has finally found its final solution in
ppp version >= 11/28/2000: the new option "tcpmssfixup" (enabled by
default!) corrects the outgoing TCP MSS and solves the problem for good.
This functionality is strictly identical to what the tcpmssd port does, but
it's n
Tony Finch <[EMAIL PROTECTED]> wrote:
>
>Instead of the existing breadth-first search of the whole file table
>at the start of unp_gc, it should first clear the mark on each
>descriptor on the in-flight list, then do a depth-first search of all
>the descriptors reachable from the unix domain socke
Tony Finch <[EMAIL PROTECTED]> wrote:
>
>R. D. Lins: "Cyclic Reference Counting with Local Mark-Scan";
>Information Processing Letters 44(4):215-220, 1992; University of Kent
>at Canterbury Computing Laboratory Technical Report 75, July 1990.
http://citeseer.nj.nec.com/lins90cyclic.html
Tony.
--
> Ok, I'll see if that can happen. Basically since the reference
> never goes to zero on the socket, the buffers are never forced to
> be flushed/cleared and the mbuf will then never be free'd resulting
> it it leaking itself. Basically a socket hanging there with an
> mbuf referencing itself.
>
Terry Lambert <[EMAIL PROTECTED]> wrote:
>
>SVR4 and Solaris avoid the problem entirely by ensuring that
>each reference to a vnode pointer counts as an "open", and
>the vnode can not be discarded until a 1->0 reference count
>change (grep for VHOLD/VRELE/VREF in the Solaris headers).
FreeBSD doe
> >SVR4 and Solaris avoid the problem entirely by ensuring that
> >each reference to a vnode pointer counts as an "open", and
> >the vnode can not be discarded until a 1->0 reference count
> >change (grep for VHOLD/VRELE/VREF in the Solaris headers).
>
> FreeBSD does this too. It doesn't solve th
> >This still leaves the possibility of a circular reference being
> >passed while being passed until the process exits, but I don't
> >think you need to care about that.
>
> That's the whole point of this conversation!
I don't think you need to care about it. There are valid reasons
for doing
* Terry Lambert <[EMAIL PROTECTED]> [001214 15:45] wrote:
> > >This still leaves the possibility of a circular reference being
> > >passed while being passed until the process exits, but I don't
> > >think you need to care about that.
> >
> > That's the whole point of this conversation!
>
> I do
I think there is some confusion over ref counts here. I'm going
to try to be clear: You *cannot* use a 1->0 transition on a ref
count to cleanup self referential loops in socket message queues
from file descriptor passing. Because no 1->0 transition will
ever occur, even if
Matt Dillon <[EMAIL PROTECTED]> wrote:
>
>We are *not* going create a separate ref count field just to track
>socket queue references, because this breaks the file descriptor passing
>semantics...
There is an f_msgcount field already but isn't used for the sort of
half-baked hack at t
> I'm happy to announce this problem has finally found its final solution in
> ppp version >= 11/28/2000: the new option "tcpmssfixup" (enabled by
> default!) corrects the outgoing TCP MSS and solves the problem for good.
> This functionality is strictly identical to what the tcpmssd port does, bu
> > I'm happy to announce this problem has finally found its final solution
in
> > ppp version >= 11/28/2000: the new option "tcpmssfixup" (enabled by
> > default!) corrects the outgoing TCP MSS and solves the problem for good.
> > This functionality is strictly identical to what the tcpmssd port
I am interested in creating a pathological lab network with the
following forwarding rules:
- three networks (A,B,C)
- packets from A or C are forwarded to B
- packets from B are forward to both A and C
I was thinking of using BRIDGE+ipfw to create this by hacking
bridge.c so that all dsts are
Hi,
if you want to use bridging and you know the IPs of the hosts on
"networks" A, B, and C (which is what you need to use the 'deny'
rules) you do not need to hack bridge.c
On the other hand, your solution will not block ARPs and subnet-broadcast
packets, so i really think the best solution is
Hello Luigi --
Thank you for your response. Btw, I've been reading over the
bridge code ... many thanks for this valuable resource!
The problem with the "just let it be a router" approach is that I
want all traffic from B to go to A and C, not just that which is
actually intended for said net (
Ok, I've redone the messages in the ratelimiting patch. They are now as
follows:
Limiting icmp unreach response from 439 to 200 packets per second
Limiting closed port RST response from 283 to 200 packets per second
Limiting open port RST response from 18724 to 200 packets per second
Limiting i
Looks good to me, I'll commit this within the next 24 hours unless
someone complains with reason.
Thanks Mike.
On Thu, 14 Dec 2000, Mike Silbersack wrote:
>
> Ok, I've redone the messages in the ratelimiting patch. They are now as
> follows:
>
> Limiting icmp unreach response from 439
Hi!
""Matthew Emmerton"" <[EMAIL PROTECTED]> wrote in message
news:<002101c0663a$d0270b90$[EMAIL PROTECTED]>...
> > > I'm happy to announce this problem has finally found its final
solution
> > > in ppp version >= 11/28/2000: the new option "tcpmssfixup" (enabled by
> > > default!) corrects the
> Thank you for your response. Btw, I've been reading over the
> bridge code ... many thanks for this valuable resource!
>
> The problem with the "just let it be a router" approach is that I
> want all traffic from B to go to A and C, not just that which is
> actually intended for said net (yes
26 matches
Mail list logo
