Jtdylktuy

• 
  

  Problem:

  
  
  
  
  
  • Network configuration results in 10 minute operating system load time.
  
  
  
  


• 
  

  Setup

  
  
  
  
  
  • Two Windows 10 systems, latest updates
  
  
  • connected directly with ethernet cable (non-crossover)
  
  
  • Static IPs on both
  
  
  • Windows Kernel Network Debugging is enabled
    
  
  
  • Windows Firewall is disabled on target
  
  
  • Host machine has two network interfaces
  
  
  
  


• 
  

  Questions:

  
  
  
  
  
  • How does crossover connections affect broadcast packets?
  
  
  • Could the network switch store-and-forward table be responsible?
  
  
  
  


• 
  

  Observations:

  
  
  
  
  
  • the 10 minute boot time hang is at spinning windows boot splash
  
  
  • I assume the KDNET filter is having a hard time...
  
  
  • When I connect both PCs to a network switch, problem solved
  
  
  • when I disable network debug, problem solved
  
  
  • 
    Connected to target 169.254.78.132 on port 50008 on local IP 192.168.128.1 prints in WinDbg on connection, with network switch or crossover cable
  
  
  • 
    Connected to target 172.29.2.197 on port 50008 on local IP 172.29.13.140 is when DHCP is enabled on target, connecting through primary network interface.
  
  
  • Leaving WinDbg closed (no kernel debug session open), still slow
  
  
  • List of IP addresses of target as per netadapter
  
  
  
  

IP ADDRESSES



unicast            ffffd206bfefb040 - 192.168.128.100

multicast          ffffd206bfef2040 - 224.0.0.1

multicast          ffffd206ccdd1040 - 224.0.0.251

multicast          ffffd206ccddb040 - 224.0.0.252

multicast          ffffd206cd375040 - 239.255.255.250

broadcast          ffffd206bfef8040 - 255.255.255.255

broadcast          ffffd206ccda9040 - 192.168.128.255

TL;Dr: Use bcdedit /set {dbgsettings} dhcp No or nodhcp flag.

bcdedit /dbgsettings NET HOSTIP:ip PORT:port [KEY:key] [nodhcp] [newkey] [/start startpolicy] [/noumex]

WinDBG using Windows 10 (RS5 / 17763.1) kernel network debugging requires DHCP by default to function optimally.

Recall, that KDNET kernel module operates on a lower level than Windows OS. The "Microsoft Kernel Debug Network Adapter" connection's IP address settings are NOT used, nor the hidden real (Intel/Realtek/Broadcom) adapter, that had its IP address as well.

For example, setting IPV4 address to 192.168.128.1 in Network Connections control panel, the debugger (while connected to switch) reports this:

Connected to target 172.29.1.132 on port 50008 on local IP 172.29.13.140.

this correlates to my previous observation that when crossover cable was used:

Connected to target 169.254.78.132 on port 50008 on local IP 192.168.128.1

So a crossover cable with no DHCP server results in KDNET stalling for 10 minutes on DHCP before finally falling back to link-local address.

Confirmed by https://community.osr.com/discussion/290941/network-debugging-took-pcs-off-the-dhcp-network-windbg-can-no-longer-connect

The kernel debugger (meaning the part embedded in the target
computer's kernel) is able to connect a windbg on a machine with a
static IP, but it has never supported assigning a static IP to itself.
You either use DHCP, or you get a fallback address in the 169.254.x.x
range. That range is not routable, so the two computers have to be
directly connected.

Note that the IP address assigned to the network adapter by the
operating system is irrelevant. The kernel debugger has its own
independent driver stack.

Also, communication is done via UDP packets, not TCP... so it doesn't need an IP address really. Here is the Wireshark packet capture showing the DHCP requests using crossover cable:

Looking closer at the output of bcdedit and bcdedit /dbgsettings I see windows automatically used the DHCP flag, despite me never adding it. I see they also added a "nodhcp" option, although its hard to find in the documentation

debug                   Yes

----- dbgsettings -----

busparams               3.0.0

key                     1.2.3.4

debugtype               NET

hostip                  192.168.128.1

port                    50008

dhcp                    Yes

Adding DHCP:no to my network debug setup batch script solved the problem!

@echo off



rem get bus device function from Device Manager of network adapter

set bdf=3.0.0



rem port used in WinDbg

set port=50008



rem set your workstation machine to the following IP on a secondary adapter

set ip=192.168.128.1



rem enable network debug using the ip address of the dev system

bcdedit /debug on

bcdedit /create {dbgsettings} > NUL 2>&1

bcdedit /dbgsettings NET HOSTIP:%ip% PORT:%port% KEY:1.2.3.4

bcdedit /set {dbgsettings} busparams %bdf%

bcdedit /set {dbgsettings} dhcp No



rem rebuilt BCDs don't contain these sections / inheritance, and prevents Microsoft Kernel Debug Network Adapter from appearing

bcdedit /set {current} inherit {globalsettings}

bcdedit /create {globalsettings} > NUL 2>&1

bcdedit /set {globalsettings} inherit {dbgsettings}



pause

There is also the Firewall issue caused by static networks with no DNS being marked "public", I have this powershell snippet to fix it, but its required on Startup.... I just disabled the Firewall for this target machine to mitigate the issue instead.

# Name             : Unidentified network

# InterfaceAlias   : nameOfYourNetworkAdapter

# InterfaceIndex   : 6

# NetworkCategory  : Public

# IPv4Connectivity : NoTraffic

# IPv6Connectivity : NoTraffic



# converts the "Public" network to "Private" so file sharing and such works with Windows firewall

# this is good for local connections that do not need gateway / dns



get-netconnectionprofile -InterfaceAlias *

set-netconnectionprofile -InterfaceAlias nameOfYourNetworkAdapter -NetworkCategory Private

get-netconnectionprofile -InterfaceAlias *



# note, I don't believe this persists between reboots... so add to startup menu if needed

# it makes it easier to rename your nework adapter to 'debug' or something without spaces