CyberPsychotic wrote:
> yep. Checked this. On BSD machines sock_a gets some random value, while on
> Linux it's always zero. This was the cause why it was stuck in accept. By
> the way, is there way in gdb to check what filedescriptors are opened in
> some process, so I could investigate such behaviour in future?
I dunno about gdb, but you can use `ls -l /proc/<pid>/fd' to see which
descriptors a process has open. The format is [dddd]:xxxxx where dddd
is the device (major and minor numbers, in hex), and dddd is the inode
number, in decimal. Sockets are shown with a device of 0000.
> > > Looks like I broke the connection, and kernel still waits for last_ack
> > > from remote. Is there way to flush such things?
> >
> > The kernel should keep resending the FIN until the other end
> > acknowledges it.
>
> within certain timeout, right?
I think so.
For the FIN_WAIT_2 state, the RFCs don't specify a timeout. This
allows for an interesting denial-of-service attack, which all Win32
systems employ (some people might suggest that this is deliberate).
However, most recent Unices (including Linux) implement a timeout.
> > There isn't any mechanism to forcibly change a
> > socket's state (although I guess you could use spak to send a fake
> > ACK).
>
> yep.probably it would work, but is it the only way to fix it? and.. I will
> need SYN/ACK numbers here, is there a way to get (within a C code) these
> pack. numbers which kernel expect? (probably it could be possible for
> setuids by examining certain areas of memory, since kernel saves these
> numbers somewhere anyway, but is the a "proper" way?)
I suspect that you would need to monitor the outbound FIN segments to
get the necessary information.
--
Glynn Clements <[EMAIL PROTECTED]>
