filesync
filesync copied to clipboard
opeolluwa
Create Wifi Hotspot on windows Operation system
The problem: Windows operating system does not allow the creation of a Wifi Hotspot unless the device is connected to a Wifi.
The Task: Implement a function to create a wifi hotspot on the Windows Operating system. See this project built in the C programming language wich attempts to achieve this feature
Hi @opeolluwa I found a project that focuses on implementing Wi-Fi and it seems that the hotspot feature has already been implemented. Would it be possible for me to utilize this crate to resolve the current issue?
@zoo868e you could try it out in a test environment, if it all work fine, then we can implement the feature for each OS.
I noticed that the mentioned project contains numerous unimplemented!() statements. As a result, I have decided not to utilize it. Instead, I will make an effort to implement the functionality using Windows system calls, as outlined in this project.
We'll done @zoo868e ❤️, I love your persistence and determination.
I once checked out the project but I couldn't get it to compile, plus I'm not very good at C programming.
It would be a great feat if you could get it work, we'll use a Rust FFI to call the C code.
Please let me know if anything come up.
Regards this, I'm exploring netsh for Windows Operating system and nmcli for Linux, I've been able to got farther with the Linux implementation and I think there might be a break through
These are cli tools to interact with the OS network manager. See the progress here.
Sounds great! I encountered a lot of difficulties when using the Windows crate, so interacting with the CLI tools seems like a wise choice.
The implementation as it is, especially for Mac and Windows is largely a higher level implementation of the approach, I need to track down the details.
My attention is on the Linux, hopefully, fixing it would pave way for other things
Hi @opeolluwa, I have implemented the functions (#205) for starting and stopping the hotspot on Windows. Please review them.
Hi @zoo868e thank you for working on this, I'm mostly busy these writing exams at school, I'd take a look at it the first chance I get but it might take some time ❤️
Thank you! Did you try out the functions on a Windows Operating system to check for their working status
Okays... Same as mine, I'd merge the PR and build the application in debug mode. I'd keep you in sync
Just came across this issue, while catching up on Week in Rust/Call for Participation. A bit late, but hopefully not too late...
I haven't had time yet to delve into the WiFi API(s) offered by the operating system. Though, the implementation suggested by @zoo868e has a number of issues. Not to dismiss their effort, but this doesn't appear to be a tractable solution. In no particular order, here are a few shortcomings:
- Creating a process on Windows is a relatively expensive operation.
- Launching a process by name (rather than a fully qualified path name) instantly opens you up to MITM attacks.
- The netsh.exe binary might not exist on any given system, or access could be subject to a group policy, or anti-malware service rules.
- Dropping down to a CLI means giving up on structured information:
- The only reliable binary classifier here is whether launching the child process succeeded or not.
- If it did succeed, the only data available is a 1-dimensional stream of bytes, with no clear-cut meaning.
- Checks like
.contains("Hosted network supported : Yes")will produce false negatives in case the application decides to update its output format (e.g. by adding Virtual Terminal Sequences). - The check will straight up fail in case the application is localized, while running under a locale other than en_US.
Some of these can be addressed, with ad-hoc implementations, yet one of the important ones (namely, propagation of rich error information) cannot.
If you're interested, I'll have a look at wekillpeople's (um, yeah, whatever...) hotspot-windows implementation, and see if it's feasible to transliterate that into a Rust module/crate.
@opeolluwa I've looked into it a bit, but haven't made any substantial progress yet. The weekend is going to be busy, too, but I think I'll have something to show by Monday evening.
hey guys @tim-weis @zoo868e see this crate, https://crates.io/crates/wifidirect-legacy-ap
hey guys @tim-weis @zoo868e see this crate, https://crates.io/crates/wifidirect-legacy-ap
That's very helpful indeed, thanks a lot for that. Not so much the crate itself, but the link to the Wi-Fi Direct Legacy Connection C++ WRL Demo uncovered a fair amount of information new to me.
Just leaving a few notes, as my memory is best known for being short-lived:
New to me, Wi-Fi is a bit of a mess. If I understand, there used to be a time where the protocol had no provision for creating peer-to-peer connections over Wi-Fi radios, and systems left and right invented their own schemes. This changed with the introduction of Wi-Fi Direct, formalizing this use case, and allowing vendors to provide APIs for it.
That was insightful in so far as I was previously struggling to make sense out of the multitude of APIs offered by Windows, that all seemingly provide the same functionality. The Wi-Fi Direct sample calls out that the WlanHostedNetwork API were deprecated (though I couldn't find any evidence for that from the documentation). Nonetheless, it appears as though the Windows.Devices.WiFiDirect.dll Windows Runtime Component is the current API to use (wrapping the flat, C-style Wi-Fi Direct API behind a more convenient interface).
The WiFiDirect Legacy AP (for Windows) crate interfaces with the Windows Runtime API, so using that as-is, or as a starting point would make sense. Regardless, there are a few rough spots in its implementation to consider:
- The whole MPSC-dance: It is employed to ultimately wrap an asynchronous API behind a synchronous, blocking interface. It may be worth evaluating whether exposing an
asyncinterface is feasible. The unfortunate reality, however, is, that Rust'sasync/.await()model is very outside-in (i.e. application driven) rather than inside-out (OS driven). This design makes it challenging to map onto a kernel architecture that sports native async support (such as Windows'). - Communication across the MPSC channels is rather limited. Only
Strings andbools are exchanged, leaving a lot of useful error diagnostics behind. - Lots of
unwrap()s andexpect()s. Some of them are justified, but others are really just a corollary of the unstructured exchange of information between the MPSC channels. Withpanic = "abort"being the only safe panic handling strategy, this isn't entirely desirable.
All that said, I haven't yet verified whether either of the implementations actually work. I'm still a bit terrified about the idea of breaking this laptop's sole connection to the outside world. Though, at least, I believe the Wi-Fi chip in this device supports Wi-Fi Direct.
I'll see what I can do to move this forward.
Hi @tim-weis that was quite a mouthful, thank you so much for digging so deep. I'd look this up on my end and see what I can come up with.
like you said, you might need to take your time on trying things out.
