mlvpn_tuntap_read blocking/non-blocking

[markfoodyburton]

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?????

[zehome]

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

[markfoodyburton]

I was beginning to think I had gone mad ! Thanks Laurent, I'll work on cleaning all my patches up and send them.

[zehome]

I'm going to address that