☰

Verhindern Sie, dass ein Programm (vmet-natd) Ereignisse erhält, die darauf hinweisen, dass das Netzwerk in Linux seinen Status geändert hat.

tag-icon • tag-icon linux networking dhcp vmware-workstation
Verhindern Sie, dass ein Programm (vmet-natd) Ereignisse erhält, die darauf hinweisen, dass das Netzwerk in Linux seinen Status geändert hat.

Unser WLAN-Zugangspunkt ist mit einer sehr aggressiven DHCP-Lease-Zeit von 10 Minuten konfiguriert. An sich ist das kein Problem, da die IP-Adresse bei Erneuerung der Lease gleich bleibt. Aber ich verwende VMware Workstation und ein so kurzes Intervall führt zu häufigen Netzwerkausfällen innerhalb der virtuellen Maschinen. Das Grundproblem liegt im vmet-natd-Daemon. Er erkennt, dass es IRGENDEINEN Netzwerk-Vorfall gab und geht davon aus, dass es sich um eine erneute Verbindung handelte. Die Folge ist, dass der virtuelle Netzwerkadapter in der VM eine „physische“ Netzwerktrennung und dann eine sofortige Wiederherstellung erfährt. Und alle meine TCP-Sitzungen werden in der VM beendet.

Derzeit verwende ich VMware Workstation 15.1.0 auf einem Xubuntu 18.04-Host.

Dies sind die Ereignisse aus dem Syslog, wenn dies auftritt.

Jun 25 15:23:18 laptop wpa_supplicant[1039]: wlp2s0: WPA: Group rekeying completed with 6c:3b:6b:XX:XX:XX [GTK=CCMP]
Jun 25 15:26:06 laptop dhclient[6554]: DHCPREQUEST of 192.168.XXX.XXX on wlp2s0 to 192.168.XXX.XXX port 67 (xid=0x6f72XXXX)
Jun 25 15:26:06 laptop dhclient[6554]: DHCPACK of 192.168.XX.XX from 192.168.XX.XX
Jun 25 15:26:06 laptop NetworkManager[1038]: <info>  [1561465566.1687] dhcp4 (wlp2s0):   address 192.168.XX.XX
Jun 25 15:26:06 laptop NetworkManager[1038]: <info>  [1561465566.1687] dhcp4 (wlp2s0):   plen 24 (255.255.255.0)
Jun 25 15:26:06 laptop NetworkManager[1038]: <info>  [1561465566.1687] dhcp4 (wlp2s0):   gateway 192.168.XX.XX
Jun 25 15:26:06 laptop vmnet-natd: RTM_NEWADDR: index:4, addr:192.168.XXX.XXX
Jun 25 15:26:06 laptop NetworkManager[1038]: <info>  [1561465566.1688] dhcp4 (wlp2s0):   lease time 600
Jun 25 15:26:06 laptop NetworkManager[1038]: <info>  [1561465566.1688] dhcp4 (wlp2s0):   nameserver '192.168.XXX.XXX'
Jun 25 15:26:06 laptop NetworkManager[1038]: <info>  [1561465566.1688] dhcp4 (wlp2s0):   nameserver 'XXX.XXX.XXX.XXX'
Jun 25 15:26:06 laptop NetworkManager[1038]: <info>  [1561465566.1688] dhcp4 (wlp2s0):   nameserver 'XXX.XXX.XXX.XXX'
Jun 25 15:26:06 laptop NetworkManager[1038]: <info>  [1561465566.1688] dhcp4 (wlp2s0): state changed bound -> bound
Jun 25 15:26:06 laptop dbus-daemon[1020]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.11' (uid=0 pid=1038 comm="/usr/sbin/NetworkManager --no-daemon " label="unconfined")
Jun 25 15:26:06 laptop systemd[1]: Starting Network Manager Script Dispatcher Service...
Jun 25 15:26:06 laptop dhclient[6554]: bound to 192.168.XXX.XXX -- renewal in 267 seconds.
Jun 25 15:26:06 laptop dbus-daemon[1020]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Jun 25 15:26:06 laptop systemd[1]: Started Network Manager Script Dispatcher Service.
Jun 25 15:26:06 laptop nm-dispatcher: req:1 'dhcp4-change' [wlp2s0]: new request (1 scripts)
Jun 25 15:26:06 laptop nm-dispatcher: req:1 'dhcp4-change' [wlp2s0]: start running ordered scripts...
Jun 25 15:26:06 laptop kernel: [10747.491441] userif-2: sent link down event.
Jun 25 15:26:06 laptop kernel: [10747.491445] userif-2: sent link up event.

Da ist einThread in den VMware-Forendarüber ohne Lösung.

Wie verhindere ich das? Mein Google-Fu war nicht gut genug, um die Lösung zu finden.

Es gibt möglicherweise mehrere Möglichkeiten, dieses Problem zu beheben.

  1. Korrigieren Sie vmnet-natd, um eine spezielle Behandlung für solche Ereignisse durchzuführen. (VMware-Support ist nicht hilfreich).
  2. Konfigurieren Sie vmnet-natd so, dass Netzwerk-Ereignisse vollständig ignoriert werden, aber es scheint keine solche Option zu geben.
  3. Generieren Sie keine Netzwerkänderungsereignisse, wenn sich durch Patchen/Konfigurieren des Kernel-/Userspace-Linux-Netzwerkstapels nichts an der Neucodierung der Wi-Fi-Zuordnung oder der Verlängerung des DHCP-Lease geändert hat.
  4. Patchen/konfigurieren Sie den Kernel-/Userspace-Linux-Netzwerkstapel, um keine Netzwerkereignisse (oder eine Teilmenge davon) an vmnet-natd zu senden.

Kann mir jemand den Weg des geringsten Widerstands zeigen, um dieses Ärgernis zu lösen?

Aktualisierung 1:Der Netzwerkadapter in der VM ist im NAT-Modus konfiguriert. Ich kann ihn nicht in einem anderen Modus ausführen, da ich keine meiner VMs direkt dem Büronetzwerk aussetzen kann. Der DHCP-Server für den Host ist der Zugriffspunkt selbst und bleibt immer derselbe. Das Netzwerk wird mit Network Manager verwaltet.

Antwort1

Der Artikel Beheben von Problemen mit VMWare Player unter Linux bei Verwendung von DHCP-Adressen beschreibt das Problem und bietet eine Lösung an.

Dieses mit VMwarePlayer v8+ eingeführte Problem wird wie folgt beschrieben:

Bei jeder Erneuerung der DHCP-Adresse eines beliebigen Netzwerkadapters des Hostcomputers kommt es bei allen virtuellen Maschinen zu einer Netzwerktrennung und -verbindung, wodurch das Netzwerk bei jeder Erneuerung etwa 20 Sekunden lang unbrauchbar wird.

Dies ist besonders zerstörerisch für Netzwerke mit einer kurzen DHCP-Lease-Dauer wie Ihrem, wo etwa alle 5 Minuten alle VMs für kurze Zeit ihre Netzwerkverbindung verlieren würden.

Dieses Verhalten ist deutlich zu sehen in /var/log/messages:

Jun 25 15:26:06 laptop kernel: [10747.491441] userif-2: sent link down event.
Jun 25 15:26:06 laptop kernel: [10747.491445] userif-2: sent link up event.

Der Autor des Artikels hat die Zeichenfolge userif-3in der Datei gefunden userif.c, die im Code-Tar der Datei enthalten ist, /usr/lib/vmware/modules/source/vmnet-only.tar die in jeder VMWarePlayer-Installation enthalten ist.

Der Code, den er fand, sah folgendermaßen aus:

965 int
966 VNetUserIfSetUplinkState(VNetPort *port, uint8 linkUp)
967 {
...
1010    LOG(0, (KERN_NOTICE "userif-%d: sent link %s event.\n",
1011         userIf->port.id, linkUp ? "up" : "down"));
1012 
1013    return retval;
1014 }

Anschließend erstellte er eine Patch-Datei und wendete den Code wie folgt an:

cd /tmp
tar xf /usr/lib/vmware/modules/source/vmnet.tar
patch -p0 < vmware-vmnet-only.patch
tar cf vmnet.tar vmnet-only
cp /tmp/vmnet.tar /usr/lib/vmware/modules/source/vmnet.tar
/usr/bin/vmware-modconfig --console --install-all
systemctl restart vmware    ## or 'service vmware restart'

Ich liste seinen Patch unten auf:

-- vmnet-only/userif.c  2017-12-21 17:02:28.555820933 +0100
+++ vmnet-only.jjk/userif.c 2017-12-15 13:22:13.257724953 +0100
@@ -973,6 +973,9 @@
    userIf = (VNetUserIF *)port->jack.private;
    hubJack = port->jack.peer;

+   /* never send link down events */
+   if (!linkUp) return 0;
+
    if (port->jack.state == FALSE || hubJack == NULL) {
       return -EINVAL;
    }

verwandte Informationen