On Tuesday, 21 July 2015 at 11:08:00 UTC, Rikki Cattermole wrote:
On 21/07/2015 10:36 p.m., Baz wrote:
[...]
I'll summarize what my friend is saying.
netsh is potentially going away. Don't use it if you can.
Since you are using a localized system it, it may be causing
issues for the interface name.
Internally to Windows, it does not use the interface names. It
uses id's.
Oh and most importantly use Windows API not netsh.
You should instead be using ConvertInterfaceAliasToLuid[0] to
get the UID.
There does not appear to be a c-function to disable/enable an
interface. Supposedly[1] could be used to enable/disable the
card which provides it. Although I would recommend against it.
Lastly, this is half good news and half bad news. We have found
a way[2] through WMI/COM to enable/disable them. Although I've
never gone the path of COM let alone WMI which could be a
rather mess to deal with in D. May be easier to use PowerShell
for this.
Either way, my current theory revolves around Windows kernel +
subsystems not liking it toggling so frequently. Friend is a
little more conservative on it.
[0]
https://msdn.microsoft.com/en-us/library/windows/desktop/aa365821(v=vs.85).aspx
[1]
https://msdn.microsoft.com/en-us/library/windows/hardware/ff552169(v=vs.85).aspx
[2]
https://msdn.microsoft.com/en-us/library/hh968170(v=vs.85).aspx
That's an excellent expertise. However, I'd like to put the
emphasis on the fact that it looks like a deterministic way to
crash windows, even if to run the script, admin rights are
necessary.
Now there is also other questions in background: DHCP server,
network interface driver even if nowadays they are all in 'user
mode', (versus kernel mode).
