Network debugging, took PCs off the DHCP network, WinDbg can no longer connect

Tim, the test machine is on 192.168.203.10, the same subnet as the host.

matt_sykes wrote:

Tim, the test machine is on 192.168.203.10, the same subnet as the host.

Um, no, it’s not.  The test machine is 169.254.181.179, which is on a
different subnet.  Your message said so.

You’re not grasping what I’ve been trying to say here.  It doesn’t
matter one teensy little bit what IP address you assign to the target
interface after the OS has booted.  It’s totally irrelevant to the
kernel debugger connection.  The kernel debugger runs a completely
separate network stack.  It will assign its own IP address to that
interface, and it can do so in one of two ways: it can pull from DHCP,
or it can pick a random address from the APIPA range, which is
169.254.xxx.xxx.  That’s the extent of your choices.  You cannot force a
static IP of your own choosing.  It’s impossible.

Remember, at the time the kernel debugger starts, the kernel doesn’t
even KNOW what IP address was assigned.  That all comes later.

Tim, you can specify a static IP address, you use ‘nodhcp’ in /dbgsettings. The problem is, as I stated above, that this is NOT documented by Microsoft in either of the links I got fro a google search on setting this up.

matt_sykes wrote:

Tim, you can specify a static IP address, you use ‘nodhcp’ in /dbgsettings. The problem is, as I stated above, that this is NOT documented by Microsoft in either of the links I got fro a google search on setting this up.

Yes, you can specify “nodhcp”, and that does trigger a static IP
address, but you don’t get to specify what IP address to use. The
kernel will choose one at random from the APIPA range, 169.254.xxx.xxx,
which is exactly what showed up in your message. Remember, the HOSTIP
parameter specifies the IP address of the other computer – the one
running windbg.

Tim, the relevant take home from this thread is that Windbg in it’s latest incarnation has problems connecting to a target on a static network, unless you specify nodhcp, which isnt documented by Microsoft.

Whatever windbg does internally isnt of interest to me. What I am interested in is getting it working so I can get on and do my job, and this is how to get it to work, and if anyone else has this problem, this post just might help them too.

matt_sykes wrote:

Tim, the relevant take home from this thread is that Windbg in it’s latest incarnation has problems connecting to a target on a static network, unless you specify nodhcp, which isnt documented by Microsoft.

I must respectfully disagree.  The “nodhcp” option certainly is documented:

https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/bcdedit--dbgsettings

Whatever windbg does internally isnt of interest to me. What I am interested in is getting it working so I can get on and do my job, and this is how to get it to work, and if anyone else has this problem, this post just might help them too.

I have told you several times how to get it to work.  Give your debug
host an IP address in the APIPA range.  Then, both machines will be in
the same subnet, and everything will work just fine. For kernel
debugging without DHCP, you are not allowed to choose your own subnet. 
The problem is just that simple.

Tim, take a look at the three links I gave you earlier, these were the first hits I got off google. It isnt documented there. OK, so yo found one place it is. SO did I (but not on a MSFT site). But this isnt good enough, it should be documented everywhere /dbgsettings net is. Particularly as the latest windbg has problems connecting over a static network.

I have told you several times how to get it to work

And I just told you, I think it is twice now, how to get it to work. Use nodhcp.

Give your debug host an IP address in the APIPA range

So change my entire network because of a bug in the latest windbg?

For kernel debugging without DHCP, you are not allowed to choose your own subnet

Yes you can, just specify nodhcp.

On Jan 23, 2019, at 2:38 AM, matt_sykes wrote:
>
>> Give your debug host an IP address in the APIPA range
>
> So change my entire network because of a bug in the latest windbg?

No. Change the IP address and net mask on your host machine. When you’re through debugging, change it back. That’s one “netsh” command that you can plop in a batch file.

>> For kernel debugging without DHCP, you are not allowed to choose your own subnet
>
> Yes you can, just specify nodhcp.

And then what? How do you specify the target’s IP address?

Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

And then what? How do you specify the target’s IP address?

Statically Tim

Statically Tim

Are you intentionally trying to be dense here? Are you specifically trying to jerk around someone who is actually trying to help you? Look, here are some facts.

  • bcdedit has two addressing options: DHCP (by default), or /nodhcp
  • If you specify /nodhcp, the test machine’s adapter is assigned a static address in the 169.254 subnet
  • There is no parameter to bcdedit that lets you specify an IP address for the target
  • The kernel debugger doesn’t know what IP address might be assigned to the interface after boot has completed

Given those facts, one is led to the inescapable conclusion that there is not now, nor has there ever been, a mechanism to assign a specific static IP address to the kernel debugger’s network interface. Therefore, what you are saying is nonsense. If you have a recipe that contradicts this, I’d welcome you to share it, as I have been asking you to do for the last two weeks.

Tim, it works. Dont you get it? The solution to the problem was nodhcp. It works now. Put the to machines on a static network, set the /dbgsettings up, and reboot. windbg connects. OK? Do you get that?

Do you get that?

I don’t get it Mr. Sykes.

Perhaps you can explain to us the exact steps you’ve used to assign a static IP address, other than one in the 169.254 subnet, to the test machine. You’ve said “statically”… but this doesn’t tell us WHERE to set this statically. I know how to set it on the HOST machine… in Network Properties. But on the TEST machine? If we are all being incredibly stupid, feel free to paste a screen shot of where we make this change.

I’m taking on face-value that you have found the heretofore unknown incantation to make this work. I’m hoping you will take the time to kindly share this incantation with us. Like Mr. Roberts, I’m under the impression that using /nodhcp gets you a target with a static IP in the 169.254 range and would like to know how to change that.

Thanks,

Peter

Why so patronising Peter? Really

Surely you know how to assign a static network address to a PC (I used 192.168.137 subnet as the host had been set up to do internet sharing) , so do that, then enable debugging on the target, set the host address, port, and specify nodhcp.

Get the key, put that in windbg on the host, and restart the target.

Windbg connects and you can debug.

Why so patronising Peter? Really

For somebody who of gets a lot of questions answered here, I find your manner surprisingly aggressive.

Please, Mr. Sykes: For the benefit of everyone, dial it down a level. And bear in mind that when posting here you’re a guest in my house. I don’t invite guests home to have my other guests insulted, be insulted myself, or to have my motives impugned.

Peter

It wasnt me who called someone dense Peter.

No, Mr Sykes… but Mr, Roberts has answered questions for quite literally hundreds of people here. His uniform willingness to help, coupled with his exceptional patience, are the stuff of legend. This has earned him the undisputed right to receive respect and deference from every member of this community. And this level of respect is due him regardless of whether Mr, Roberts might display a rare level of frustration in one of his numerous replies.

When you speak disrespectfully to Mr. Roberts, regardless of the provocation, it is not acceptable to me. When you couple this with a snarky reply to me… well, that earns you a bit of a rebuke.

I’m not sure why I need to explain this to you Mr. Sykes. You’ve been here for about five years. Surely you know the rules by now.

Regardless, I’ve taken ten minutes from my Saturday morning to explain this to you, as opposed to going with the faster and simpler alternative of putting you on moderation (which takes 3 mouse clicks), which was my first inclination.

Any reply to this post from you, other than perhaps “Thank you Peter, you are both wise and good looking”, would be Ill-advised. If you want to continue the vain attempt to justify your actions, or you wish to try my patience further in any other way, I ask you to please do so with a direct email. My direct email is visible in my profile.

Peter

Thank you for the information @Tim_Roberts , I forgot that KDNET maintains its own IP address stack!

@Tim_Roberts said:

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.

I wrote a SuperUser post based on extreme slowness to boot with static network. KDNET takes ~10minutes to fall back on link-local address when DHCP server is unavailable. I discovered the DHCP:yes flag was set by default, clearing that flag (on RS5 17763.1) allowed network debug to work as intended.

https://superuser.com/questions/1404669/crossover-computer-connection-vs-network-switch-broadcast-packet-differences

Actually makes it easier, because toggling the IP address of the target machine in Windows is sufficient to block internet access (NDA project), without needing a direct network cross-over connection. WinDbg settings can remain on DHCP

I would recommend amending the Network debug articles to include the nodhcp documentation from https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/bcdedit--dbgsettings as that was definitely missed by me as well.

I would recommend amending the Network debug articles to include the nodhcp

That is an excellent idea.

Are you aware that the docs are on github… and you can do the edits yourself? Seriously. Go to that page, and you’ll see an “edit” link at the top. Go for it! The doc folks are very pleasant to deal with and appreciative of contributions.

Peter

Actually Peter I have been here since the dawn of time, been writing windows drivers since the days of NT4. (remember the old discussion forum we used before you created these ones on osr? WHat was it, google groups or some such, I forget)

But anyway, I see someone else has agreed with me, that nodhcp is not clearly documented, and nice to see you agree Peter. Now perhaps we can put whatever misunderstanding everyone suffered in this thread behind us and move on.

Actually Peter I have been here since the dawn of time

Then you should really know the rules, Mr. Sykes, know that Mr. Roberts is worthy of your respect, and act likewise.

What was it, google groups or some such, I forget

It was way before there was a Google, Mr. Sykes. Those original forums, back in the 1993 and 1994, were on CompuServe. We’ve been answering questions about how to write Windows (NT) drivers for a long, long, time here at OSR…

Oh, these were the days…

Peter
(thread closed)