That is the easiest solution for me... Thanks.
Hi
It's me replying myself.
Yes, this is the behaviour of an kernel implementation. The problem lies in the fact that we the have an SCTP implementation
The problem lied in the fact that I wasn't calling "listen(fd, 1)" before trying to listen in the socket.
On the other hand, as you could have seen in the trace I sent, after SCTP1 sents an INIT, SCTP2 replies with an INIT ACK, instead of an ABORT (as it is prescribed in section 3.1 of Sockets API Extensions for SCTP )
I believe that it is a BUG. I tested with linux kernel sctp and that implementation does reply with an ABORT message if the user forgets to call 'listedn(fd, 1)'
Best Regards
Javier Acuña
________________________________________________________________
Mensaje enviado desde el Servicio Webmail del Dominio sixbell.cl
_____________________________
La informacion contenida en esta transmision es confidencial, y no puede ser usada por otras personas que su(s) destinatario(s). El uso no autorizado de la informacion contenida en esta transmision puede ser sancionado. Si ha recibido esta transmision por error, por favor destruyala y notifique al remitente telefonicamente, con cobro revertido o via e-mail.
The information contained in this transmission is privileged, and may not be used by any person other than its addressee(s). Unauthorized use of the information contained in this transmission may be punished by law. If received in error, please destroy and notify the sender by calling collect or by e-mail.
_____________________________
_______________________________________________
discussion mailing list
discussion AT sctp.de
http://www.sctp.de/mailman/listinfo/discussion
Archive powered by MHonArc 2.6.19+.