On Thu, Mar 08, 2001 at 11:47:45AM +0200, Patrick O'Reilly wrote:
In my desperation I have gone as far as adding these two very loose rules,
which are the very first rules in the ipfw chain:
/sbin/ipfw -q add 9 allow log ip from 10.5.5.0/24 to 10.3.3.240
/sbin/ipfw -q add 9
I'm having some problems on configuring my just
purchased Intel PRO/100+ PCI (reported by Intel as being P#:
689661-004).
When booting, FreeBSD 4.2 reports:
fxp0: Intel Pro 10/100B/100+ Ethernet at
device 13.0 on pci0fxp0: could not map memory
Anyone knows how to get this card to
work?
FIXED !!!
Thanks to you all (Bill, Blair and Johnny) for your help.
It turns out the problem was not at the transport level at all (seriously
red face now!)
The login and password was the issue - Since the clients and server are not
on the same windows NT domain, the NT server was validating
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
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 supposed
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(). The
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 involved at
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
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
connection
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. The client
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
On Thu, Mar 08, 2001 at 02:30:23PM -0800, Alfred Perlstein wrote:
* Jonathan Lemon [EMAIL PROTECTED] [010308 14:19] wrote:
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
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 timeout
will correct it. thanks for reporting.
http://www.kame.net/dev/cvsweb.cgi/kame/kame/sys/netinet6/nd6.c.diff?r1=1.135r2=1.136
itojun
Any chance of this finding its way into -current and -stable (preferably
before the release)?
John
--
John Hay -- [EMAIL PROTECTED]
To
I'll do it right now if itojun doesn't mind (to save him a task :-) )
and get authorization from Jordan to commit.
Thanks,
Bosko.
John Hay wrote:
will correct it. thanks for reporting.
http://www.kame.net/dev/cvsweb.cgi/kame/kame/sys/netinet6/nd6.c.diff?r
1=1.135r2=1.136
itojun
I'll do it right now if itojun doesn't mind (to save him a task :-) )
and get authorization from Jordan to commit.
please go ahead, i can review the diff if you want me to.
itojun
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
16 matches
Mail list logo
