☰

Impedir que um programa (vmet-natd) receba eventos de que a rede mudou de estado no Linux

tag-icon • tag-icon linux networking dhcp vmware-workstation
Impedir que um programa (vmet-natd) receba eventos de que a rede mudou de estado no Linux

Nosso ponto de acesso Wi-Fi está configurado com um tempo de concessão de DHCP muito agressivo de 10 minutos. Não é um problema em si, pois o endereço IP permanece o mesmo quando o aluguel é renovado. Mas eu executo o VMware Workstation e um intervalo tão curto leva a quedas frequentes de rede dentro das máquinas virtuais. A raiz do problema está no daemon vmet-natd. Ele detecta que houve ALGUM evento de rede e assume que foi uma reconexão. A consequência é que o adaptador de rede virtual na VM obtém uma desconexão "física" da rede e, em seguida, uma reconexão imediata. E todas as minhas sessões TCP são descartadas na VM.

Atualmente estou executando o VMware Workstation 15.1.0 em um host Xubuntu 18.04.

Estes são os eventos do syslog quando isso ocorre.

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.

Existe umtópico em fóruns vmwaresobre isso sem solução.

Como posso evitar isso? Meu google-fu não foi bom o suficiente para encontrar a solução.

Pode haver várias maneiras de corrigir isso.

  1. Corrija vmnet-natd para fazer tratamento especial para tais eventos. (O suporte VMware não é útil).
  2. Configure o vmnet-natd para ignorar completamente os eventos de rede, mas parece não haver tal opção.
  3. Não gere eventos de alteração de rede se nada mudou na rechaveamento da associação Wi-Fi ou na extensão de concessão de DHCP, corrigindo/configurando a pilha de rede linux do kernel/espaço do usuário.
  4. Patch/configure a pilha de rede linux do kernel/userspace para não enviar eventos de rede (ou algum subconjunto deles) para vmnet-natd.

Alguém pode me indicar o caminho de menor resistência para resolver esse incômodo?

Atualização 1:O adaptador de rede na VM está configurado no modo NAT. Não consigo executá-lo em nenhum outro modo, pois não consigo expor nenhuma das minhas VMs diretamente na rede do escritório. O servidor DHCP para host é o próprio ponto de acesso e permanece o mesmo o tempo todo. A rede é gerenciada com o Network Manager.

Responder1

O artigo Corrigindo o VMWare Player no Linux ao usar endereços DHCP descreve o problema e oferece uma solução.

Este problema, introduzido com VMwarePlayer v8+, é descrito como:

Cada vez que o endereço DHCP de qualquer um dos adaptadores de rede da máquina host é renovado, todas as máquinas virtuais recebem uma desconexão e conexão da rede, tornando a rede inutilizável por aproximadamente 20 segundos a cada renovação.

Isto é particularmente destrutivo para redes com um tempo de concessão de DHCP curto como o seu, onde aproximadamente a cada 5 minutos todas as VMs perderiam a conectividade de rede por um curto período.

Esse comportamento pode ser visto claramente em seu /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.

O autor do artigo encontrou a string userif-3no arquivo userif.c, incluída no código-tar do arquivo /usr/lib/vmware/modules/source/vmnet-only.tar que acompanha cada instalação do VMWarePlayer.

O código que ele encontrou ficou assim:

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 }

Ele então criou um arquivo patch e aplicou o código da seguinte forma:

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'

Eu listo seu patch abaixo:

-- 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;
    }

informação relacionada