tcp close misfunction

[GoogleCodeExporter]

What steps will reproduce the problem?
1. x86/zrv
2. rlogin to host, usual work and "exit" on remote shell
3. Try to reconnect

What is the expected output? What do you see instead?
This log appear (10 is remote host, 16 is local embox)

IP 10.513 > 16.513: Flags [P.], seq 124:134, ack 46, win 114, options 
[nop,nop,TS val 6170337 ecr 933069], length 10
IP 10.513 > 16.513: Flags [F.], seq 134, ack 46, win 114, options [nop,nop,TS 
val 6170337 ecr 933069], length 0
<logout occurs>
IP 16.513 > 10.513: Flags [.], ack 134, win 16384, length 0
IP 16.513 > 10.513: Flags [.], ack 135, win 16384, length 0
IP 16.513 > 10.513: Flags [F.], seq 46, ack 135, win 16384, length 0
IP 10.513 > 16.513: Flags [R], seq 877817, win 0, length 0
<trying to reconnect>
IP 16.513 > 10.513: Flags [S], seq 100, win 16384, options [mss 16396,sackOK,TS 
val 933069 ecr 0,nop,wscale 7], length 0
IP 10.513 > 16.513: Flags [S.], seq 2859136088, ack 101, win 14480, options 
[mss 1460,sackOK,TS val 6220203 ecr 933069,nop,wscale 7], length 0
IP 16.513 > 10.513: Flags [R], seq 100, win 16384, length 0
IP 10.513 > 16.513: Flags [S.], seq 2859136088, ack 101, win 14480, options 
[mss 1460,sackOK,TS val 6220504 ecr 933069,nop,wscale 7], length 0
IP 16.513 > 10.513: Flags [R], seq 100, win 16384, length 0

Socket which send reset and connecting socket are not the same. Can guess, that 
no socket unhash occur. Also, double ack on FIN is confusing.

Please use labels and text to provide additional information.

Original issue reported on code.google.com by drakon.m...@gmail.com on 28 Mar 2013 at 4:03

[GoogleCodeExporter]

Issue 577 has been merged into this issue.

Original comment by ki.stfu on 28 Mar 2013 at 4:10

[GoogleCodeExporter]

it is revenge of embox socket))

Original comment by ki.stfu on 28 Mar 2013 at 4:38

[GoogleCodeExporter]

i can't reproduce your problem. i have this:

IP 10.513 > 16.513: Flags [F.], seq 220, ack 38, win 114, options [nop,nop,TS 
val 9236981 ecr 933069], length 0
IP 16.513 > 10.513: Flags [.], ack 221, win 16384, length 0
IP 16.513 > 10.513: Flags [F.], seq 38, ack 221, win 16384, length 0
IP 10.513 > 16.513: Flags [.], ack 39, win 114, options [nop,nop,TS val 9236983 
ecr 933069], length 0
IP 16.513 > 10.513: Flags [S], seq 100, win 16384, options [mss 16396,sackOK,TS 
val 933069 ecr 0,nop,wscale 7], length 0
IP 10.513 > 16.513: Flags [.], ack 39, win 114, options [nop,nop,TS val 9237897 
ecr 933069], length 0
IP 16.513 > 10.513: Flags [R], seq 100, win 16384, length 0
IP 16.513 > 10.513: Flags [S], seq 100, win 16384, options [mss 16396,sackOK,TS 
val 933069 ecr 0,nop,wscale 7], length 0
IP 10.513 > 16.513: Flags [.], ack 39, win 114, options [nop,nop,TS val 9238604 
ecr 933069], length 0
IP 16.513 > 10.513: Flags [R], seq 100, win 16384, length 0

this dump displays the normal behavior for tcp, so:
rlogin was fixed by r9315.

Original comment by ki.stfu on 28 Mar 2013 at 6:30

• Changed state: Started

[GoogleCodeExporter]

first ack for last P. packet and it was sent before receiving a F. packet, 
second ack for F. packet. i think all good.

Original comment by ki.stfu on 28 Mar 2013 at 6:40

[GoogleCodeExporter]

Alright, that double ack is ok, it was looking wierd. BUT everything cannot be 
ok as you (as embox)  send rst from port that requested connection (last line 
in tcp dump). This issue describes this bad behavior.

Original comment by drakon.m...@gmail.com on 28 Mar 2013 at 8:03

[GoogleCodeExporter]

yes, but i can't reproduce this. i suggest not to close this task to clarify 
the circumstances

Original comment by ki.stfu on 28 Mar 2013 at 8:10

[GoogleCodeExporter]

I made some changes in r9473, and I think it fix this problem. Please, try my 
solution on itself (don't forget revert r9315 in local repository before 
trying).

The problem was: we unlock a port on close(), but actually a TCP socket is not 
closed (it was in closing state), so we can open a new socket on the same port 
and we do that. Thus we had two socket with the same attributes, and all 
packets destined for the 2nd socket was handling by 1st socket (because 1st 
socket was created early than 2nd socket and in tcp_hash table it located 
before 2nd socket), which was in closing state.

Original comment by ki.stfu on 5 Apr 2013 at 7:31

• Added labels: Component-Logic
• Removed labels: Arch-x86

[GoogleCodeExporter]

I'm agree with reason of this behaviour, it was looking same way for me.

Although, dislike sport_alloced. as well all ip_port that caused such troubles.

Original comment by drakon.m...@gmail.com on 6 Apr 2013 at 7:39

[GoogleCodeExporter]

Yes, it's slippery place, but if we will careful in freeing ports we avoid such 
problems. May be ip_port api needs to be improved, including logic with 
sport_alloced varibale.I think about this.

Original comment by ki.stfu on 6 Apr 2013 at 11:25

• Changed state: Fixed