On Sat, Mar 07, 2015 at 08:44:24PM +0100, ext Danny Smit wrote: > I changed my code to reflect this, but it doesn't really make a > difference. For what its worth, I already tried something similar with > an higher level API to wait for socket notification, which led to the > same results. > > Whats interesting is that the poll() call returns immediately (within > milliseconds) regardless of the timeout value. It does set "revents" > on the struct in [sfd], of which the very first occurrence of this > call sets revents to 73 (0x49), but all subsequent calls to poll > within the loop shown above sets revents to 65 (0x48). So POLLERR (0x08) is reported in all cases. Perhaps this is the indication of ABORT you're looking for? > But every call to sctp_recvmsg() still returns with an error and sets > errno to 107 (ENOTCONN). Therefore sctp_recvmsg somehow still seems > unable to read the events. I'm out of ideas :( Time to involve real experts I guess. -- What doesn't kill you makes you stronger. -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
