Hi,
I think 192..83 is rebooted at around frame #74. 192..83
sends an ABORT to 192..80 to terminate the association. In
frame #75, 192..80 tries to establish another association.
192..83 responds with an invalid ABORT (frame #76) like the
above.
192..80 retransmits the INIT in frame #77 after 3s. I guess
192..83 is still shutting down and so it responds with another
invalid ABORT (frame #78). This ABORT is ignored by 192..80
as expected.
192..80 continues the retransmission of INIT in frames #79 -
#82. So the SCTP stack indeed retransmits the INIT as
expected. How long did you wait for the event? Here is the
output I got from running your program.
Yes, 192.83 was rebooted around frame #74.
192.80 SCTP retransmits INIT from #79 to #82.
But it stops after that.
Why should it stop re-transmission? It did not send COM LOST either to
application.
I have re-ran tests and waited for long time (10 minutes).
But I did not see SCTP transmitting Init further.
I have modified the program to time out select after 60 seconds.
After 192.83 is rebooted app on 192.80 keeps getting select time but not COM
LOST.
Below is output of the program.
^^^^Wait for some time and make another connection attempt ^^^^
[ 29112006 10:43:01.834 ] Intitiating connection
[ 29112006 10:43:01.835 ] Connection attempt successful errno = 150
[ 29112006 10:43:01.835 ] Connection attempt successful returning value 1
[ 29112006 10:43:01.835 ] Going into select loop
[ 29112006 10:44:01.843 ] select time out
[ 29112006 10:45:01.853 ] select time out
[ 29112006 10:46:01.862 ] select time out
[ 29112006 10:47:01.871 ] select time out
[ 29112006 10:48:01.880 ] select time out
[ 29112006 10:49:01.889 ] select time out
[ 29112006 10:50:01.898 ] select time out
[ 29112006 10:51:01.907 ] select time out
[ 29112006 10:52:01.916 ] select time out
[ 29112006 10:53:01.925 ] select time out
[ 29112006 10:54:01.934 ] select time out
Regarding dtrace utility, is this command sufficient to check if SCTP is
transmitting Init:
dtrace -n BEGIN -n fbt:ip:sctp_init_mp:entry
Regards,
Dhananjay
_______________________________________________
networking-discuss mailing list
[email protected]
