Les deux copies d’écran que tu as publié confirme mon opinion d’un bug du logiciel.

• En effet, le premier écran confirme bien que le média « ethernet local area connection » est bien déconnecté, du coup il n’y a pas de route passant par cet interface autre que la route vers 127.0.0.1 via 127.0.0.1 et 127/24 via 127.0.0.1. En clair, même dans cet état déconnecté toutes les destinations commençant par 127 sont atteignable par l’interface loopback, ce qui est normal depuis que IP et TCP existent (vers 1980).

Donc le traffic émis par ton dongle vers le port udp 10110 devrait être émis et reçu, ce qui ne semble pas le cas.

• A l’inverse lorsque ethernet est branché, le média ethernet apparait connecté (2ème écran) avec l’adresse IP 169.254.71.228 (déterminé automatiquement en l’absence d’un serveur dhcp local) et des routes montent vers 169.254.255.255 (aka 169.254/16), ce qui est tout à fait normal ... et devrait être sans incidence sur le fonctionnement du dongle ou son logiciel puisque lui ne trafique que vers 127.255.255.255 (loopback)

C’est donc bien un bug du logiciel, où alors la suite logiciel (driver) tcp/ip à changé récemment sans que je m’en aperçoive, pourquoi pas mais ...

Il peut t’amuser de savoir qui est à l’écoute des ports et en particulier du port 10110 en udp.

• La commande « netstat -ona » permet ça, la dernière colonne indique un n° de process à l’écoute du port précisé dans les premières colonnes. Très utile aussi pour repérer les anomalies par ex. Dans ce cas précis ça devrait être le process opencpn