Closed markfoodyburton closed 7 years ago
yes absolutely I have the same problem. Sometimes select() / poll() will tell the user process that something is ready when it's not.
Under Linux, select() may report a socket file descriptor as "ready for
reading", while nevertheless a subsequent read blocks. This could for
example happen when data has arrived but upon examination has wrong
checksum and is discarded. There may be other circumstances in which a
file descriptor is spuriously reported as ready. Thus it may be safer
to use O_NONBLOCK on sockets that should not block.
This is a mistake, I should have noted all socket as non blocking
I was beginning to think I had gone mad ! Thanks Laurent, I'll work on cleaning all my patches up and send them.
I'm going to address that
The file descriptor for the tuntap is currently set up to be blocking. Indeed, mlvpn_tuntap_read is currently set up to simply do a blocking read on it. This would seem to be perfectly reasonably, since lib_ev will only call the read if/when it would not block.
However, If I allow that, then sometimes (sometimes after days), one, or other, or both my tunnels 'freeze'. It SEEMS that setting the file descriptor to be non-blocking (as recommended by lib_ev), and checking the return status of the read in mlvpn_tuntap_read solves this problem for me.
I'll provide a patch, but before doing so, has anybody else seen anything similar, or have any good explanation as to why this should be needed?????