In some mail from Alan Cox, sie said: > > > Now you may be wondering why does a write to the socket returned by > > accept() generates a SIGPIPE. This bring us to the second issue. It seems > > that at least under Linux 2.0.X accept will return a socket in the > > received queue if it is not in the SYN_SENT or SYN_RECV state, even when > > it has not gone through the ESTABLISHED state. > > > > By doing a stealth scan on the port the socket goes from the SYN_RECV > > state to the CLOSED state. When you try to read from such a socket you > > get a SIGPIPE. The sematics of Linux's accept seems to be non-standard. I > > wonder what else breaks by not handling SIGPIPE. > > On that issue you are a little astray. Linux merely made the window for > the inetd problem a bit larger. You can hit a box betwen the accept > returning towards user space and the write() with a seperate RST frame > regardless of what accept returns. If generic BSD has this missing > SIGPIPE I venture to say that if you can hit the precise boundary needed > you can bring down inetd there too. I don't see that being a problem for the BSD inetd as it fork()s before the write and the process which receives the SIGPIPE is a child of inetd, not the master (so to speak). I would have thought the linux one would behave the same. Darren
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:34:04 PDT