msolters
node-webkit freez
When i try to connect to wifi, it does connect, but also freeze aplication.
I've created an NW.js app using the wifi-control-node module. You can test it in your version of Linux to see if it works. I've verified it works with NW.js v0.12.3 on Windows 7.
- https://github.com/TheJaredWilcurt/UGUI-Wifi
Part of the WiFi connection sequence involves waiting until the connection is complete. There are a couple edge cases I can think of where this can result in an infinite loop as written! Depending on your implementation, that could very easily introduce a dead stop.
This project is not my first priority but I can look into adding a parameter that could attempt to implement a timeout to break those loops next week.
The only way I can really get to the bottom of this is if you can post the log output up until the point that it freezes. Maybe you could try running the node app and dump its output to a file like node yourapp.js > log.txt and paste it here? Make sure that you initialize the module in debug mode so we can capture all the state changes:
WiFiControl.init({
debug: true
});
I have the same issue on my windows 10 machine using electron 0.36.4 (Node 5.1.1). Discovering networks works just fine but connecting to one does change the connection and freezes electron completely. There even remains a process after killing the application.
My debug output for scanning for networks:
node_modules\wifi-control\lib\wifi-control.js:68 WiFiControl: Debug mode set to: true
node_modules\wifi-control\lib\wifi-control.js:68 WiFiControl: Determining system wireless interface...
node_modules\wifi-control\lib\wifi-control.js:68 WiFiControl: Host machine is Windows.
node_modules\wifi-control\lib\wifi-control.js:68 WiFiControl: Executing: echo wlan
node_modules\wifi-control\lib\wifi-control.js:68 WiFiControl: Automatically located wireless interface wlan.
node_modules\wifi-control\lib\wifi-control.js:68 WiFiControl: Scanning for nearby WiFi Access Points...
node_modules\wifi-control\lib\wifi-control.js:68 WiFiControl: Nearby WiFi APs successfully scanned (16 found).
index.js:15 Objectmsg: "Nearby WiFi APs successfully scanned (16 found)."networks: Array[16]0: Objectsignal_level: -59.5ssid: "myssid"__proto__: Object1: [...]__proto__: Objectlength: 16__proto__: Array[0]success: true__proto__: Object
And connecting to an open network using the javascript console:
var _ap = {
ssid: "myssid"
};
var results = WiFiControl.connectToAP(_ap);
node_modules\wifi-control\lib\wifi-control.js:68 WiFiControl: Generating win32 wireless profile...
node_modules\wifi-control\lib\wifi-control.js:68 WiFiControl: Executing: netsh wlan add profile filename="myssid.xml"
node_modules\wifi-control\lib\wifi-control.js:68 WiFiControl: Success!
node_modules\wifi-control\lib\wifi-control.js:68 WiFiControl: Executing: netsh wlan connect ssid="myssid" name="myssid"
node_modules\wifi-control\lib\wifi-control.js:68 WiFiControl: Success!
node_modules\wifi-control\lib\wifi-control.js:68 WiFiControl: Removing temporary WiFi config file...
node_modules\wifi-control\lib\wifi-control.js:68 WiFiControl: Waiting for connection attempt to settle...
@cemrich I very much think your problem stems from the problem as @Kilgaloon . Basically, the loop which checks the system's network state either (a) finds out the system is connected, but the loop livelocks or (b) the loop never gets a response regarding the system's network state. It could be both.
I intend to rewrite this module to avoid A regardless, by implementing async looping with a configurable time out.
But to understand why the loop never stops, can you tell me what the output of the following program is:
WiFiControl.init({
debug: true
});
console.log( WiFiControl.getIfaceState() );
By analyzing the response from Windows 10 of the .getIfaceState() method, we may get an insight into why that response isn't sufficient to break the network state loop.
Thank you for your quick response. The output is
Object {success: true, msg: "Successfully acquired state of network interface wlan.", ssid: "myssid", connection: undefined, power: true}
Yup, that connection: undefined is the root of the issue (in your case). I'm thinking through a solution that should hopefully be more immune to exceptions like this or others we haven't seen yet.
@cemrich I recently released a version 2.0.0 of this package. I've replaced all of the offending loops with a better timeout system. Would be interested to know if it helps you in any way with this problem.
Yes, the bug is gone with the latest release. Thank you!
Windows now does connect fine to my (open) network. However, wifi-control does not recognize this fact:
var results = WiFiControl.connectToAP(_ap, function (err, response) { console.log(err, response); });
node_modules\wifi-control\lib\wifi-control.js:36 WiFiControl: Generating win32 wireless profile...
node_modules\wifi-control\lib\wifi-control.js:36 WiFiControl: Executing: netsh wlan add profile filename="myssid.xml"
node_modules\wifi-control\lib\wifi-control.js:36 WiFiControl: Success!
node_modules\wifi-control\lib\wifi-control.js:36 WiFiControl: Executing: netsh wlan connect ssid="myssid" name="myssid"
node_modules\wifi-control\lib\wifi-control.js:36 WiFiControl: Success!
node_modules\wifi-control\lib\wifi-control.js:36 WiFiControl: Removing temporary WiFi config file...
node_modules\wifi-control\lib\wifi-control.js:36 WiFiControl: WiFi connection request to "myssid" has been processed.
undefined
VM130:2 Connection confirmation timed out. (5000ms) Object {success: false, msg: "Error: Could not connect to myssid"}
But this seems to be another bug.
Yeah, note that undefined you're getting is because in v2.0 WiFiControl.connectToAP( _ap, cb ) method no longer returns anything directly. It will always return undefined. All result parsing should happen inside your cb().
Then, secondly, I bet the problem is the same as in https://github.com/msolters/wifi-control-node/issues/9#issuecomment-174051540.
Do you think you could post the results from your command prompt on the computer exhibiting that behaviour when you run the following command?
netsh wlan show interface
You may have to execute that with administrative privileges. It will show us exactly what WiFiControl is attempting (and failing) to parse in your case.
Yeah, note that undefined you're getting is because in v2.0 WiFiControl.connectToAP( _ap, cb ) method no longer returns anything directly. It will always return undefined. All result parsing should happen inside your cb().
I know, but the callback function is called with an error object as if the network has not been found.
Do you think you could post the results from your command prompt on the computer exhibiting that behaviour when you run the following command?
Es ist 1 Schnittstelle auf dem System vorhanden:
Name : Wi-Fi
Beschreibung : Intel(R) Dual Band Wireless-AC 7265
GUID : e8f8a21f-50ff-42b7-af4a-xxxxxxxxxxxx
Physische Adresse : XX:XX:XX:XX:XX:XX
Status : Verbunden
SSID : myssid
BSSID : XX:XX:XX:XX:XX:XX
Netzwerktyp : Infrastruktur
Funktyp : 802.11n
Authentifizierung : WPA2-Personal
Verschlüsselung : CCMP
Verbindungsmodus : Automat. Verbindung
Kanal : 6
Empfangsrate (MBit/s) : 144.4
Übertragungsrate (MBit/s) : 144.4
Signal : 99%
Profil : myssid
Status des gehosteten Netzwerks : Nicht verfügbar
Sorry, it's all German - i cannot convince windows to switch languages, but I can translate if needed. I think the error might hide in the last line: Status of the hosted network: Not available.
This answers everything.
The output above is parsed by the package to determine network state, but it parses by matching keywords. These will obviously not work when the keywords are English but the output is in German!
That's what causes the error. I will need to think about this. I need to find a way to force output in a known language (as in, I know in advance what language it will be) or else find a different mechanism of parsing (e.g. counting lines).
BTW this line proves that you are connected: Status : Verbunden.
English output would read State: Connected