Networking between VM with lldb debugging

lundman · ‎10-02-2022

Hosts involved:

Win - WIn10 machine running VMware 16.1.0 and the two VMs

VM1 - Catalina serving as lldb host

VM2 - Catalina caused to panic, waiting for lldb

M1 - laptop I work with

The 2 HW machines and 2 VMs (bridge) are on the same LAN network, getting IPs from gateway (edgemax).

Networking between VM1 and VM2 is fine, I can ssh, scp, ping, and all the usual things.

But when I panic VM2, and it waits for lldb (gdb protocol) it will just timeout. lldb uses UDP, and maybe broadcast is involved.

If I run lldb on M1, it can connect to VM2 just fine. It is just VM1 and VM2 that seems unable to talk. If I use "nc -u" and "tcpdump" direct UDP also work between VM1 and VM2 (pre-panic).

All networking is otherwise normal, /24 on all hosts, arp is fine (tried permanent arp entry, but not the issue). Tried without Windows firewall (just in case, but all work with M1).

Any ideas why I can't debug between two VMs?

RDPetruska · ‎10-03-2022

Since you state that you have an M1 Mac host, I assume you are actually running the VMware Fusion Tech Preview?

lundman · ‎10-03-2022

Nah, the Windows 10 box running VMware Workstation (Pro or Player) 16.1.0 has both VMs, and they can not lldb between them, even though the network is fine.

I mention the M1, as it can lldb to the VM2 - as a demonstration that it is not a firewall, general IP configuration or similar at all. I suspect I can copy the VM2 over to M1 and it will work. It appears to be something about the two VMs being next to each other.

I also added a secondary nic to both VMs, assigned vmnet6 (random pick), configured manual IPs 1.1.1.1 and 1.1.1.2 on /24, ping, ssh working, changed kdp_match_name=en2 (a kernel debugger variable to use the nic for vmnet6) and it still can not communicate.

I don't see anything special in their UDP reply code either:

https://github.com/apple-opensource/xnu/blob/eb45a4f3d6bc33c958fcbf4ea7388da13ae63a2e/osfmk/kdp/kdp_...

it is most perplexing.

RDPetruska · ‎10-04-2022

Ahh, then that means you have illegally hacked Workstation to run Apple virtual machines. It is a violation of Apple's licensing to run their OS on non-Apple hardware. We cannot help you here, as VMware could get into legal trouble. Locking this thread.