https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263534
Michael changed:
What|Removed |Added
Resolution|--- |FIXED
Status|Open
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263534
Graham Perrin changed:
What|Removed |Added
Assignee|b...@freebsd.org|n...@freebsd.org
--
You are recei
does to
>> start any individual test is, it disables its own interface,
>> and at the beginning of the new test, it suddenly "up"s its
>> interface and sends test packet right after that.
>> This is where we have problem, and we don't receive this
>> f
> > It sounds to me like the problem is with your test setup. If
> > your test requires no packet drops, then it implicitly
> > assumes having established link and sending the packets
> > right after the interface
>
> Unfortunately we can't change test setup. S
t sounds to me like the problem is with your test setup. If
> your test requires no packet drops, then it implicitly
> assumes having established link and sending the packets
> right after the interface
Unfortunately we can't change test setup. Spirent Test-Center device runs the
te
dual test is, it disables its own
> > interface, and at the beginning of the new test, it suddenly "up"s its
> > interface and sends test packet right after that without any delay.
>
You may want to go over spirent box settings and look for something along
the lines of &q
erface, and at the beginning of the new test, it suddenly "up"s its
> interface and sends test packet right after that without any delay. This is
> where we have problem, and we don't receive this first packets most of the
> time (result is vary, in 100 tests, we lose about 60~
idual test is, it disables its own interface, and at the
beginning of the new test, it suddenly "up"s its interface and sends test
packet right after that without any delay. This is where we have problem, and
we don't receive this first packets most of the time (result is vary, in
ns the "old" value of SND.NXT
> (I believe). SND.MAX can always be used to distinguish new data tx from
> retx - useful for things like RTTM, some ECN updates, etc.
I think above cluase means that TCP can't distinguish. And TCP assume
pkt 2,3,4,5,6 is lost& retransmit.(am I right?)
the packet
> filter after the apropriate rule has been identified as long as
> necessary to reach the right bandwidth ratio...
> 3. Right now I did it with ipfw... Seems to work... Although it
> looks like up to 20 packets are waiting for the right bandwidth...
> Maybe the server even r
sender of a stream to slow down?
In case of TCP I could think of a quite easy way to do so:
1. ipfw does it...
2. I would just delay the processing of the packet by the packet
filter after the apropriate rule has been identified as long as
necessary to reach the right bandwidth ratio...
3. Right now
Arne,
On Monday 03 October 2005 21:17, Arne W�rner wrote:
> Since my server cannot process gracefully a 20Mb/s stream on one
> NIC, while ntpd (or ping) runs on the other NIC (round trip times
> increase from about 60msec to 300msec), I tried to limit the
> sporadic big data stream to not more tha
Hiho!
I use pf.
Since my server cannot process gracefully a 20Mb/s stream on one
NIC, while ntpd (or ping) runs on the other NIC (round trip times
increase from about 60msec to 300msec), I tried to limit the
sporadic big data stream to not more than 9Mb/s.
When I look at "pfctl -s queue -vv" it
Synopsis: rn_walktree_from not halting at the right node
Responsible-Changed-From-To: freebsd-net->andre
Responsible-Changed-By: andre
Responsible-Changed-When: Thu Aug 26 21:40:24 GMT 2004
Responsible-Changed-Why:
Take over.
http://www.freebsd.org/cgi/query-pr.cgi?pr=38
Synopsis: rn_walktree_from not halting at the right node
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: arved
Responsible-Changed-When: Thu Aug 26 20:23:36 GMT 2004
Responsible-Changed-Why:
Over to freebsd-net for review.
http://www.freebsd.org/cgi/query-pr.
Hi Doug,
Your analysis is correct (kern/46961), I am slowly working on the
fix but no ETA. It seems NetBSD recently has fixed a similar issue,
haven't checked this fact yet, just saw a promising commit log in
if_ethersubr.c.
--
Maxim Konovalov, [EMAIL PROTECTED], [EMAIL PROTECTED]
_
her_dhost,
| > IFP2AC(ifp)->ac_enaddr, ETHER_ADDR_LEN) != 0
| > && (ifp->if_flags & IFF_PPROMISC) == 0) {
| > /*
| > * Let VLAN packets go to the SW VLAN node needed for
| >
mp; ntohs(eh->ether_type) == ETHERTYPE_VLAN )) {
m_freem(m);
return;
}
}
}
That makes it work. I rather doubt this is the right solution.
Suggestions greatly appreciated. This issu
I have the Border router set up and working it seems, and the client/host on the same
network and ping it - but it knows
itself as the interface only ? (fe80+MAC)
How do I convince the client that it is actually 2002:cb01:6006::2
I can't discover how to put a 2002 address onto the rl0 interface.
From: "Merlin" <[EMAIL PROTECTED]>
> If I understand it correctly, all I need to do on a network host is set
> ipv6_enable="YES"
>
> and the rest is done automagically.
Correct.
> net.inet6.forwarding=0
> net.inet6.accept_rtadv=1
> rtsol
>
> are all set automatically from the rc.network6 sta
If I understand it correctly, all I need to do on a network host is set
ipv6_enable="YES"
and the rest is done automagically.
net.inet6.forwarding=0
net.inet6.accept_rtadv=1
rtsol
are all set automatically from the rc.network6 startup ?
Do I have to have this set? or is it all done for the ho
I'm trying to get the options in rc.conf right for the stf0 interface for
IPv6/6to4 stuff
I'm hoping that someone out there is somewhat more expert in this than I.
It all works I might say. ping6 and all that - but I'm sure it's not set up
right?
I have two servers with
> From: "leal" <[EMAIL PROTECTED]>
> Date: Fri, 20 Apr 2001 16:47:51 -0300
> Sender: [EMAIL PROTECTED]
>
> I believe that this question is pertinent in this forum. I have some
> wireless-lan's interconected with my principal lan that have internet
> access. Without visible answers, all my wireles
I believe that this question is pertinent in this forum. I have some
wireless-lan's interconected with my principal lan that have internet
access. Without visible answers, all my wireless-lan is with the traffic
terrible!!! lost more lost. 50%, 75% of losses, this started more or less
two days. i
On Fri, Mar 09, 2001 at 02:56:21PM +0900, [EMAIL PROTECTED] wrote:
>
> >From the server's point of view:
> >
> >+ TCP/IP handshake from client, allocate protocol control blocks
> >+ receive data from client
> >+ client resets connection, pcb is destroyed
> >
> >Exactly why the client
>From the server's point of view:
>
>+ TCP/IP handshake from client, allocate protocol control blocks
>+ receive data from client
>+ client resets connection, pcb is destroyed
>
>Exactly why the client resets the connection isn't my concern at
>the moment. Some stacks may place a t
, a connect(), write(), close() call
> > should work. However, the code that was added was to handle the
> > abnormal cases from the server's point of view.
>
> Just make sure your patch is ok with the unix file descriptor
> passing garbage collection code, it seems to rel
The graceful-close debate is a very old one, going back more than
twenty years. X.25 and ISO-TP have non-graceful close - the close
can pass data in the network and cause it to be lost. TCP is
defined as graceful-close. In SVR4 TLI there are two types of
stream "sockets" with graceful or ugly c
write() close(), there is no forced
> > connection termination involved at all.
>
> Under normal circumstances, a connect(), write(), close() call
> should work. However, the code that was added was to handle the
> abnormal cases from the server's point of view.
Just make sure yo
On Thu, Mar 08, 2001 at 01:00:48PM -0500, Wietse Venema wrote:
> Jonathan Lemon:
> > On Thu, Mar 08, 2001 at 10:38:17AM -0500, Wietse Venema wrote:
> > > If the result of connect() write() close() depends on whether
> > > accept() happens after or before close(), then the behavior is
> > > broken.
Jonathan Graehl:
> > > Data CAN be lost if the TCP connection is RST. It has nothing to
> > > do with the ordering of accept() with respect to close().
> >
> > Please educate me: how would RST come into this discussion at all?
> > The client does connect() write() close(), there is no forced
> >
I would like to preempt corrections to the effect that it is currently
impossible for accept to return both an error code and a socket to read the data
from. It sounds like there may be a bug in the behavior of accept w.r.t Unix
Domain sockets. For TCP, if the client sends data, then closes with
> > Data CAN be lost if the TCP connection is RST. It has nothing to
> > do with the ordering of accept() with respect to close().
>
> Please educate me: how would RST come into this discussion at all?
> The client does connect() write() close(), there is no forced
> connection termination involv
Jonathan Lemon:
> On Thu, Mar 08, 2001 at 10:38:17AM -0500, Wietse Venema wrote:
> > If the result of connect() write() close() depends on whether
> > accept() happens after or before close(), then the behavior is
> > broken. The client has received a successful return from write()
> > and close()
On Thu, Mar 08, 2001 at 10:38:17AM -0500, Wietse Venema wrote:
> If the result of connect() write() close() depends on whether
> accept() happens after or before close(), then the behavior is
> broken. The client has received a successful return from write()
> and close(). The system is not suppos
If the result of connect() write() close() depends on whether
accept() happens after or before close(), then the behavior is
broken. The client has received a successful return from write()
and close(). The system is not supposed to lose the data, period.
This race condition did not exist with UN
On Thu, Mar 08, 2001 at 12:52:31PM +0900, [EMAIL PROTECTED] wrote:
>
> >Several parts of Postfix do: connect() write() close(), where the
> >close() may happen before the server has accept()ed the connection.
> >Due to an incompatible change in FreeBSD 4.2-STABLE, this causes
> >accept() after cl
>Several parts of Postfix do: connect() write() close(), where the
>close() may happen before the server has accept()ed the connection.
>Due to an incompatible change in FreeBSD 4.2-STABLE, this causes
>accept() after close() to fail. The already written data is lost.
>This is a bad incompatible
Several parts of Postfix do: connect() write() close(), where the
close() may happen before the server has accept()ed the connection.
Due to an incompatible change in FreeBSD 4.2-STABLE, this causes
accept() after close() to fail. The already written data is lost.
This is a bad incompatible chan
In article [EMAIL PROTECTED]> you write:
>In article
><[EMAIL PROTECTED]> Robert
>Watson wrote:
>
>>It seems that the ECONNABORTED is the "standard" way to address this
>>scenario; it might be an interesting exercise for someone to look at the
>>common application suites and see how they respond t
In article
<[EMAIL PROTECTED]> Robert
Watson wrote:
>It seems that the ECONNABORTED is the "standard" way to address this
>scenario; it might be an interesting exercise for someone to look at the
>common application suites and see how they respond to various failure
>modes in accept(). It certai
gt; thought it was going to give you turned out not to be there at the
> last moment. This was a killer for applications which expected
> return from select() to be a reliable indicator of connections
> waiting.
>
> I think the proposed fix is the best one we can get right now.
> R
d out not to be there at the
last moment. This was a killer for applications which expected
return from select() to be a reliable indicator of connections
waiting.
I think the proposed fix is the best one we can get right now.
Restructuring the TCP code to handle this case doesn't make a whol
) will fail
>> so almost every application will go to error case (if you don't have
>> error check in userland appication, that's problem in application).
>Why does SUSv2 suggest this when so many applications would break?
>And they work fine doing the old beha
On Mon, Feb 12, 2001 at 06:34:29PM -0800, Archie Cobbs wrote:
> Jonathan Lemon writes:
> > It seems to me that the odds of an application being able to correctly
> > handle an error return from accept() are far greater than the odds that
> > the code correctly checks 'len' upon return from accept
Jonathan Lemon writes:
> It seems to me that the odds of an application being able to correctly
> handle an error return from accept() are far greater than the odds that
> the code correctly checks 'len' upon return from accept. This, combined
> with the standard, seems to be rationale enough to
[EMAIL PROTECTED] writes:
> >And what do you mean by ``most apps already do the wrong thing now''?
>
> for background (like when this happens) see previous articles
> on this thread.
>
> current behavior: return 0-length sockaddr.
Yeah, that is totally broken.
Hmm.. how long
> struct sockaddr_in sin;
>
> len = sizeof(sin);
> fd = accept(s, (struct sockaddr *)&sin, &len);
> if (fd == -1)
> err(1, "accept");
> printf("peer address: %s\n", inet_ntoa(sin.sin_addr));
>
>The bug with this code is that it blindly uses ``sin'' after
On Mon, Feb 12, 2001 at 04:51:48PM -0800, Archie Cobbs wrote:
> Jonathan Lemon writes:
> > > > Did you guys agree on a commit-worthy fix yet?
> > >
> > > I wasn't party to the issue that generated this thread in the first
> > > place, but.. I think the concensus is that if accept(2) returns
> >
>> No, as this is the current behavior. The change will be for accept
>> to return an error, on the basis that 1) most apps already do the
>> wrong thing now anyway, and 2) it brings us closer to a 'standard',
>> e.g.: what other systems are doing as well.
>
>I don't understand then.
>
>What is
Jonathan Lemon writes:
> > > Did you guys agree on a commit-worthy fix yet?
> >
> > I wasn't party to the issue that generated this thread in the first
> > place, but.. I think the concensus is that if accept(2) returns
> > an error then this will break some applications, so instead it
> > shoul
On Mon, Feb 12, 2001 at 09:56:26AM -0800, Archie Cobbs wrote:
> Kris Kennaway writes:
> > Did you guys agree on a commit-worthy fix yet?
>
> I wasn't party to the issue that generated this thread in the first
> place, but.. I think the concensus is that if accept(2) returns
> an error then this
Kris Kennaway writes:
> Did you guys agree on a commit-worthy fix yet?
I wasn't party to the issue that generated this thread in the first
place, but.. I think the concensus is that if accept(2) returns
an error then this will break some applications, so instead it
should return a socket which w
Did you guys agree on a commit-worthy fix yet?
Kris
PGP signature
; and reopen it. Sendmail is robust enough not to "break" but this
> shows that if it gets an accept(2) error it assumes the problem is
> with the *listening* socket, not the new socket.
Yes, I looked at sendmail, ftpd, sshd, telnetd, inetd, and apache.
Only apache does the right thi
Jonathan Lemon writes:
> >> Jayanth did make one point that an application could assume that
> >> the error return from accept was in regards to the listening socket
> >> instead of the new socket, so that may be a concern.
> >
> >Yes I have always assumed this to be true. If the connection is
>
Robert Watson writes:
> > Jonathan Lemon writes:
> > > Jayanth did make one point that an application could assume that
> > > the error return from accept was in regards to the listening socket
> > > instead of the new socket, so that may be a concern.
> >
> > Yes I have always assumed this to b
In article
[EMAIL PROTECTED]>
you write:
>
>On Wed, 7 Feb 2001, Archie Cobbs wrote:
>
>> Jonathan Lemon writes:
>> > Jayanth did make one point that an application could assume that
>> > the error return from accept was in regards to the listening socket
>> > instead of the new socket, so that
In article [EMAIL PROTECTED]> you write:
>Jonathan Lemon writes:
>> Jayanth did make one point that an application could assume that
>> the error return from accept was in regards to the listening socket
>> instead of the new socket, so that may be a concern.
>
>Yes I have always assumed this to
On Wed, 7 Feb 2001, Archie Cobbs wrote:
> Jonathan Lemon writes:
> > Jayanth did make one point that an application could assume that
> > the error return from accept was in regards to the listening socket
> > instead of the new socket, so that may be a concern.
>
> Yes I have always assumed t
>> Jayanth did make one point that an application could assume that
>> the error return from accept was in regards to the listening socket
>> instead of the new socket, so that may be a concern.
>Yes I have always assumed this to be true. If the connection is
>already broken before I get it, why
Jonathan Lemon writes:
> Jayanth did make one point that an application could assume that
> the error return from accept was in regards to the listening socket
> instead of the new socket, so that may be a concern.
Yes I have always assumed this to be true. If the connection is
already broken be
> i believe you will want to merge this.
> scenario:
> - you are listening to tcp port
> - someone comes in, handshake (SYN, SYNACK, ACK)
> - someone sends RST
> - your server issues accept(2)
> previous behavior: accept(2) returns successful result with
>Looks good to me (although the patch is mixed in with a bunch
>of other crud). I've tested it out locally and will commit it
>unless there are any objections.
it is because of cvs issue. the important portion is below.
itojun
@@ -320,11 +359,8 @@ soaccept(so, nam)
so->so_s
>>>Looks good to me (although the patch is mixed in with a bunch
>>>of other crud). I've tested it out locally and will commit it
>>>unless there are any objections.
>> it is because of cvs issue. the important portion is below.
> oops, need some change in uipc_syscalls.c side... hol
Current updated patch for comments is below.
Jayanth did make one point that an application could assume that
the error return from accept was in regards to the listening socket
instead of the new socket, so that may be a concern.
--
Jonathan
Index: uipc_socket.c
==
>>Looks good to me (although the patch is mixed in with a bunch
>>of other crud). I've tested it out locally and will commit it
>>unless there are any objections.
> it is because of cvs issue. the important portion is below.
oops, need some change in uipc_syscalls.c side... hold
>>Looks good to me (although the patch is mixed in with a bunch
>>of other crud). I've tested it out locally and will commit it
>>unless there are any objections.
>
> it is because of cvs issue. the important portion is below.
Looks good to me as well.
-DG
David Greenman
Co-founder,
In article [EMAIL PROTECTED]> you write:
>-=-=-=-=-=-
>
>Can anyone comment on this patch?
>
>http://www.kame.net/dev/cvsweb.cgi/kame/freebsd4/sys/kern/uipc_socket.c
Looks good to me (although the patch is mixed in with a bunch
of other crud). I've tested it out locally and will commit it
unless
Won't comment on the implementation as I have't had a chance to review it
yet, but the description sounds right, and compatible with
http://www.opengroup.org/orc/DOCS/XNS/text/accept.htm
http://www.fifi.org/cgi-bin/man2html/usr/share/man/man2/accept.2.gz
There are some interestin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
< said:
> Can anyone comment on this patch?
> http://www.kame.net/dev/cvsweb.cgi/kame/freebsd4/sys/kern/uipc_socket.c
I don't necessarily agree that the previous behavior was wrong, but
I'm willing to bet that a lot of programs don't bother to chec
right after handshake
X-Template-Reply-To: [EMAIL PROTECTED]
X-Template-Return-Receipt-To: [EMAIL PROTECTED]
X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2
From: [EMAIL PROTECTED]
Date: Wed, 07 Feb 2001 21:39:49 +0900
X-UIDL: aff7d2fbee72775e2137abcde0bef0d0
i believe you
72 matches
Mail list logo
