tun not ready should not be a critical error

[F5OEO]

Launching dvb-gse creates a tun interface. If this interface is not up, and dvb-gse receive some bbframe, it exits with

Error: failed to send PDU to TUN device
Caused by:
    Input/output error (os error 5
```)
Usually, an external script makes the interface up, but if some bbframe arrives in the meantime, dvb-gse breaks.

[daniestevez]

I see several possible solutions to this problem:

1. We could encourage users to create and bring the tun interface up before running dvg-gse, by running something like

   sudo ip tuntap add mode tun name tun0
   sudo ip link set dev tun0 up

   This approach already works, but if the user doesn't create the tun device beforehand, then dvb-gse will create, so the potential problem you mention appears. If the tun device has been created beforehand, then dvb-gse just uses it, without creating a new one. I think this is simply what happens with the ioctl() done to /dev/net/tun (see here), so it's not something that dvb-gse can control.

2. dvb-gse could try to bring the interface up before sending packets to it. I don't know how to bring an interface up in Rust or C code, but I guess it's not too difficult. Portability is not a concern, since using tun devices already restricts this part of the software to Linux only. Perhaps what I dislike about this solution is that we would be bringing up the tun device but not assigning an IP to it, which may or may not make sense.

3. When we fail to send a packet to the TUN device, we could log an error and continue instead of terminating the program. This is a simple solution, but it has the drawback that it doesn't discriminate between this problem and other errors that could happen during normal execution and that would be worthy of terminating the program. The error we get here is an input/output error returned by the write() system call to the file descriptor associated to the TUN device, so I don't think there's much we can do to tell if the problem is that the interface is down or something else (other than actually going and checking if the interface is up or down).

Which solution makes most sense to you? Can you think of another solution or some variation of these?

[daniestevez]

I have decided not to make the TUN errors critical, because I've seen a case in which a corrupted BBFRAME was received, which caused garbage GSE packets to be obtained and written into the TUN. Since these were badly formatted, the kernel returned an error. Given that this situation is unlikely but possible, it is better to continue running if there are TUN write errors. An error is logged.

Closing this issue as done.