wifi-control-node
wifi-control-node copied to clipboard
Win32 - fix netsh command
These old netsh command doesn't work. It can work only if your network interface name was "wlan". I don't know how to compile those file. But I change it in .coffee. Not in .js like in my work.
Hmm, well I'm not sure why this should be necessary. Currently, @WiFiControlSettings.iface
is set to wlan
when you use "autoFindInterface": https://github.com/msolters/wifi-control-node/blob/master/src/win32.coffee#L93
Have you verified the output of autoFindInterface
to see if it is correctly echoing the expected value of wlan
?
I didn't user autoFindInterface since I have more than 1 wireless adapters installed and I have to control many of them at a time. Here was my code that have a problem with the original code.
function initGoPro() {
var settings = {
iface: 'Wi-Fi',
connectionTimeout: 1000 // in ms
};
var settings2 = {
iface: 'Wi-Fi 3',
connectionTimeout: 1000 // in ms
};
var _ap = {
ssid: "ssid1",
password: "testing1"
};
var _ap2 = {
ssid: "ssid2",
password: "testing2"
};
WiFiControl.init( settings );
var results = WiFiControl.connectToAP( _ap, function(err, response) {
console.log(response);
});
WiFiControl2.init( settings2 );
var results = WiFiControl2.connectToAP( _ap2, function(err, response) {
console.log(response);
});
}
Ah, ok.
Windows support is probably the weakest of the 3 OS in this package because I rarely use it myself.
The issue here is you are supplying in this example something like Wi-Fi 3
as the interface name. This means that later when the package composes commands to get e.g. the interface's state, it will be inserting the literal Wi-Fi 3
into a string like netsh Wi-Fi 3 show interface
.
You can see how those spaces can break the command. Assuming Wi-Fi 3
is a valid interface name in your system, perhaps this is an issue that can be fixed by simply providing quotes in the command strings, around the interface name.
~~Regardless, what I do know is that the changes you have here will not help. We are already assuming iface
is wlan, and in the code you provided, your values are overriding this assumption. The changes you have proposed here are, as far as I can tell, literally equivalent to simply passing iface: "wlan"
in your settings. I don't think that fixes anything.~~
Ok, I'm sorry -- I misread your changes re: wlan
literal. I forgot that, in Windows, it treats wlan
keyword as a way to filter down netsh
to only your wireless interfaces. I see now that your changes should in fact accomplish the goal of specifying the interface
value when dealing with netsh
, and you've wrapped them in quotes! Nice!
I will test this on a Win32 machine when I can!
~~There's some things we can try to fix this, but they should happen in a separate PR. If it's OK with you, I think we should close this PR, open a new issue referring to this PR, and then create a new PR that addresses the root cause which appears to be the proper handling of compound interface names that may or may not contain spaces. Then we can test that solution.~~
the command of netsh wasn't netsh {interfacename} ....
it was netsh wlan .... interface="{interfacename}"
. the second parameter have to be 'wlan' and can't be anything else. So this wasn't have a thing to do with these space break.
C:\Users\hisof>netsh "Wi-Fi 3" show networks
The following command was not found: "Wi-Fi 3" show networks.
C:\Users\hisof>netsh wlan show networks interface="Wi-Fi 3"
Interface name : Wi-Fi 3
There are 11 networks currently visible.
SSID 1 : ----
Network type : Infrastructure
Authentication : WPA2-Personal
Encryption : CCMP
SSID 2 : --------
Network type : Infrastructure
Authentication : WPA2-Personal
Encryption : CCMP
Yes, see above; I realized my mistake shortly before you replied! I understand now what you've accomplished -- but I need to verify it on the next win32 system I can find.