On Wed, May 16, 2018 at 07:17:07PM +0200, Andreas Fink wrote: > > > > On 16 May 2018, at 18:29, Marcelo Ricardo Leitner <marcelo.leitner@xxxxxxxxx> wrote: > > > > Hi, > > > > On Wed, May 16, 2018 at 02:02:46PM +0200, Andreas Fink wrote: > >> Under FreeBSD and MacOS, the sctp_connectx returns without an error > >> (as its a non blocking socket) and my subsequent code then calls > >> poll to wait for events or data to be delivered with a follow up > >> call to sctp_recvmsg to process that data and/or events > >> I would expect a SCTP UP message to appear after the other side > >> has done the same after the SCTP handshake completes. > >> > >> Under Linux however sctp_connectx does immediately return with > >> connection refused and we are stuck. > > > > Right. This (the returning) is because on Linux the connect operation > > always blocks, even if the socket is configured to not do so. It's a > > known issue, we're working on it. Xin Long has some patches already > > and hopefully we can post them soon. > > > > On the simultaenous open, when you connect to Cisco ITP or the others, > > doesn't it send an Abort right after the INIT request reaches it? If > > they don't, I find it odd. > > actually I played around with my test programm and figured I had the > block/no block logic inverted by mistake. Right now I have > sctp_connectx returning error 115 (EINPROGRESS) in errno which is > not 0 as on MacOS X or FreeBSD but at least it can be handled > properly. Ah right. The issue I mentioned happens only with connect calls from within the kernel itself. My bad. Ok. EINPROGRESS is expected. > The second problem I spotted was that poll was returning data and a > error at the same time. pollfds[0].revents == 9 is what I saw. > Because my code bails out if it sees bit 8 set (POLLERR), it never > got to the point to actually read and process the data. And because > errno was actually set to 0, my code was thinking its time to > immediately read again, creating a busy loop. poll returns > instantly, not after timeout. > I'm just changing that. I however find it odd that poll can return > an error flag ,errno being 0 and data. Somehow this doesn't make > much sense to me. But it could be related to the fact that > EINPROGRESS was set before maybe? EINPROGRESS is described in connect() man page. If the socket faced some issue after returning it, you need to fetch the error code using getsockopt(fd, SOL_SOCKET, SO_ERROR, ...) instead and not errno. errno itself is more to the syscall you just called, poll in the case, and poll worked. > > > >> I have not figured out how this can be achieved reliably. constantly > >> calling sctp_connectx can not be the solution as it would create a > >> busy loop and probably a packet storm. > > > > Maybe by using some iptables rule to drop Abort chunks, using a socket > > filter (SO_ATTACH_FILTER) to do it (I never did it, btw, just sharing > > ideas). > > > > Uh that would be a quite ugly hack :) Agreed :) > The ABORT's seem however to be no longer be the issue once the socket is in non blocking. Interesting. So then you just ignore the error the socket reports (SO_ERROR above)? Marcelo -- 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
