usb_c_lan_mac_to_windows_instruction_by_claude.md A developer used Claude Code to create a solution for connecting a Windows laptop to a MacBook via a USB-C cable as a LAN link, enabling IP-based communication for tools like TeamViewer. The solution involves running a TinyCore Linux VM in VirtualBox with a patched cdc_ncm driver to handle Apple's non-standard USB NCM device. The developer documented several pitfalls, including avoiding usbipd bind and xHCI controllers, and provided a step-by-step instruction set. Human text follows... Hi. In this gist I'd like to share a solution for connecting a Windows laptop to a Macbook into LAN via a 5$ usb-c cable you can ping from either to either, and, for example, connect from one to another in team viewer via LAN IP https://www.teamviewer.com/en/global/support/knowledge-base/teamviewer-remote/remote-control/use-teamviewer-remote-in-lan/ . This solution was produced by Claude Code https://code.claude.com/docs/en/terminal-guide after 2 days of trial and error. Supposedly, you should be able to make a prompt to Claude Code to use this file to set up the usb-c LAN connection and it will hopefully implement the solution much faster than it did for me. On the Macbook side I did not have to do much, just enabled Internet Sharing with Wi-Fi as source and ticked all other checkboxes for the destinations. I also ran a couple ip-related commands there, most important one being the sudo route add -net 192.168.2.0/24 -interface bridge100 , see the instruction below. On windows I think it was some rocket science stuff, the bot was installing linux on virtualbox, writing some driver patches, etc... Not sure how much did it leave in the end though, will need to read through that AI slop below. You can see the results of this instruction here: https://www.youtube.com/watch?v=VtNlKl0ABmE https://www.youtube.com/watch?v=VtNlKl0ABmE AI-generated text follows... Goal : Make a USB-C cable between a MacBook and a Windows laptop act as a LAN link, so both machines can reach each other by IP — for TeamViewer, games, file sharing, etc. Tested on : macOS Sequoia 15.7.2 + Windows 11, TinyCore Linux CorePure64 14.0 kernel 6.1.2-tinycore64 , VirtualBox 7.2.8. Why it's non-trivial : Apple's USB NCM device VID 05AC, PID 1905 is non-standard — it has no interrupt IN endpoint and no IAD descriptor. Windows' built-in NCM drivers UsbNcm.sys , UsbNcmUm.sys both fail with NTSTATUS 0xC0000483 . The only driver that works is Linux's cdc ncm , patched. The solution runs a tiny Linux VM TinyCore in VirtualBox that acts as a transparent router between the USB link and Windows. These are the footguns discovered over multiple days of debugging. Read before touching anything. 1. DO NOT use usbipd bind on the Apple NCM device. usbipd-win installs WinUSB as the driver and issues a USB SET CONFIGURATION reset. Apple's NCM device responds by entering a hard error state 0000:0002 Unknown USB Device Device Descriptor Request Failed . Recovery requires toggling Internet Sharing on the Mac. usbipd-win's VBoxUSBMon.sys also registers as a global USB filter at the kernel level and will break USB tethering for all other devices phones, etc. — see charging/tethering section below. 1b. DO NOT use Disable-PnpDevice on the Apple NCM device or its interfaces . Disable-PnpDevice issues a USB reset equivalent to usbipd's SET CONFIGURATION — the Apple NCM device enters the same hard error state and completely disappears from the Windows USB bus. Recovery requires a physical cable replug. When dealing with VBoxUSBMon stale state, only use: VM poweroff → net stop VBoxUSBMon /y → net start VBoxUSBMon → VM start. Never touch the PnP device directly. 2. DO NOT use xHCI USB controller in VirtualBox. xHCI causes VBoxSVC to fail silently: the device shows as Captured in list usbhost but is never attached to the VM. VBox.log fills with ConsoleWrap::detachUSBDevice errors every ~111 seconds. Use OHCI + EHCI only. 3. DO NOT plug the USB-C cable before the VM is running with modules loaded. If the cable is already plugged in when the VM starts, VBoxUSBMon may enter a bad state. Always start the VM first, wait for boot, then plug. 4. DO NOT enable proxy arp=1 on usb0. This causes the VM to answer ALL ARP requests on the USB link, including 169.254.x.x link-local addresses, producing a flood of gratuitous ARPs and ~50% packet drops. Set proxy arp=0 on usb0 and use an explicit pub ARP entry for 192.168.2.200 only. 5. DO NOT try to add en6 to bridge100 on macOS 15 Sequoia. en6 the Apple USB NCM interface has options=400