>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
Euuh, scratch that. I don't see anything committed to HEAD yet, at
all. No use in MFCing something that hasn't yet been committed. :-)
Bosko
I wrote:
> 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.
>
> J
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.135&r2=1.136
>
> >> > will correct it. thanks for reporting.
>
>
>http://www.kame.net/dev/cvsweb.cgi/kame/kame/sys/netinet6/nd6.c.diff?r1=1.135&r2=1.136
>
> itojun
>
Any chance of this finding its way into -current and -stable (preferably
before the release)?
John
--
John Hay -- [EMAIL PROTECTED]
To
>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
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:
> > > > > I
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
* 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 connect() write() close() depends on whether
> > > > accept(
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
Hi,
Has the topic of Strong/Weak ES model been discussed here?
Please give me a pointer if the topic has been debated.
I was wondering if there's a sysctl switch (like
net.inet.ip.strongendsystem mentioned in NetBSD list)
implemented in FreeBSD.
yu
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
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 th
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: at
device 13.0 on pci0fxp0: could not map memory
Anyone knows how to get this card to
work?
Really Thanks,
Rafael Toni
Title: RE: MS Shares through IPFW
Hi Patrick,
Another issue here is the workgroup of the NT/Win PCs. You will have to set all PCs in the same workgroup named such as MYWORKGROUP, plus do you use authentication at all? Is your NT network in a peer-to-peer or domain schema? I hope this help.
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 0
Hi all!
I need to allow some M$ clients to access M$ shares on an NT server, the
clients and server being on opposite sides of a FreeBSD ipfw firewall. The
firewall is running fine (has been for 6 months) but I cannot get this D**N
Netbios stuff going.
In my desperation I have gone as far as ad
21 matches
Mail list logo
