COM Port Access in WSL

[nosajthenitram]

In an attempt to use the com ports from WSL, I encountered the following:

public@systemhost:/dev$ ls ttyS4 -l crw-r----- 1 root root 4, 68 Apr 14 21:23 ttyS4

public@systemhost:/dev$ cu /dev/ttyS4 cu: /dev/ttyS4: System not found

public@systemhost:/dev$ sudo cu /dev/ttyS4 cu: /dev/ttyS4: System not found

This is a USB to serial adapter. I've tried to open each of the ports present on my system, but no such luck.

[MikeGitb]

There is a feature request for that somewhere on uservoice, but sadly, accessing the windows USB/com ports is afaik not yet possible.

[dhalbert]

Serial port access has been added in Insider build 16176. See https://blogs.msdn.microsoft.com/wsl/2017/04/14/serial-support-on-the-windows-subsystem-for-linux/

Note that screen and minicom don't work yet. I'm trying to get cu to work, but haven't gotten the permissions right yet.

[MikeGitb]

@dhalbert: Thanks for the heads up. Just to make sure I read this right: this is not part of CU right?

[nosajthenitram]

Using 16176 and it is supposed to work. It's not part of cu, it's part of the WSL, exposing serial ports as device nodes. There's a couple of missing IOCTLS that prevent minicom from working, but cu should.

[dhalbert]

I tried using cu and had to chmod 666 /dev/ttySxx (where xx is the COM port I wanted) and also run cu as root to avoid permission problems. Then it seemed to open the port but I couldn't get any input or output. I'm not sure if this is a problem with my use of cu or something else. I was talking to a serial-to-USB device that works fine with Putty or Tera Term.

[stehufntdev]

Thanks for trying out the serial support. Can you please try the follow:

1.) Please double check that your COM port shows up in the registry under HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM

2.) The ttyS number matches the COM port number (e.g. ttyS1->COM1, ttyS2->COM2, ...)

3.) No other process has the COM port open (Windows only allows a single open).

4.) Try running with an elevated command prompt and as root

[nosajthenitram]

Can confirm that no other process is opening any of my COM ports.

In an elevated bash (run as admin):

sudo cu /dev/ttyS4
cu: /dev/ttyS4: System not found

Am I missing something?

[dhalbert]

You have to specify the tty as the -l or --line option:
sudo cu -l /dev/ttyS4

[nosajthenitram]

Appreciate the feedback, I've never used cu before.

sudo cu -l /dev/ttyS4
cu: open (/dev/ttyS4): Permission denied
cu: /dev/ttyS4: Line in use

Same stands for all of my COM ports; in the elevated bash, using sudo.

[dhalbert]

sudo chmod 666 /dev/ttyS4
sudo cu -l /dev/ttyS4

That should get rid of the permission error.

[stehufntdev]

@dhalbert, were you able to resolve the issues that you were hitting? If not, can you give me a quick rundown of your setup? I have some serial hardware and if it matches I can try to repro.

Locally I used cu to connect to a RaspPi, cu -l /dev/ttyS2 -s 9600. I may have also set the serial configuration with sty -F /dev/ttyS2 raw -echo -echoe -echok -echoctl -echoke -iexten -onlcr cs8 crtscts since some of the Windows serial ports had non-conventional initial settings. I'll give it a try tomorrow and report back.

[nosajthenitram]

Thanks, @dhalbert - your suggestion worked, sorta. I'm able to connect to the 'line' now, but still not seeing any of the serial traffic. Probably related to what @stehufntdev mentioned about line settings, which I've tried his but to no avail... need to read up on this a bit more and make sure I have the settings correct.

[dhalbert]

@nosajthenitram: Yes, that's the problem I see.
@stehufntdev:

I am trying to connect to an Adafruit M0 Feather board which is running CircuitPython (variant of MicroPython), talking to the REPL. I did this:

$ sudo chmod 666 /dev/ttyS4
$ cu -l /dev/ttyS4
Connected.

At that point cu just appears to hang. I try typing ~. and then return to close the connection and nothing happens. I have to kill the process from another bash. When I do kill the process, the ~. shows up as input to bash, so it appears it was never read.

I can ask cu to turn on debugging, and I get a little info.

$ cu -l /dev/ttyS4 --debug all
cu: fconn_open: Opening port /dev/ttyS4 (default speed)
cu: fsserial_open: Baud rate is 9600
cu: fconn_set: Changing setting to 0, 0, 2
Connected.

I can connect to the same COM4 port with Tera Term or putty without difficulty, also at 9600 baud (that probably doesn't matter since it's USB to serial). I tried your stty flags but the problem remained. I also tried both USB2 and USB3 ports. Thanks for your help.

[stehufntdev]

Thanks @dhalbert, appreciate the extra details! I was able to cu fine with a raspberry pi over a usb to serial connector which is the closest thing I have, and wanted to share out the notes. On my machine, the raspberry pi is connected on COM5. Running as a Windows administrator should only be needed if your COM port is only accessible by a Windows administrator.

1.) sudo chmod 666 /dev/ttyS5 - This is required since cu changes it's uid which drops capabilities even when running as root. Not all serial programs have the same behavior.
2.) stty -F /dev/ttyS5 -a . Optionally check your current serial settings before updating.
3.) Set your serial settings, depending on your application this usually will be raw or sane. Either one seems to work fine with cu:
3.a) stty -F /dev/ttyS5 sane 9600
3.b) stty -F /dev/ttyS5 raw 9600 -echo -echoe -echok -echoctl -echoke -iexten -onlcr cs8 crtscts
4.) cu -l /dev/ttyS5 -s 9600
5.) Hit enter to refresh the cu console

Here's the output:

stehufntdev@stehuf-test-6:/mnt/c/Users/stehuf$ sudo chmod 666 /dev/ttyS5
[sudo] password for stehufntdev:
stehufntdev@stehuf-test-6:/mnt/c/Users/stehuf$ stty -F /dev/ttyS5 -a
speed 1200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ; eol = ; eol2 = ; swtch = ;
start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs7 hupcl -cstopb cread clocal crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl -ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc
stehufntdev@stehuf-test-6:/mnt/c/Users/stehuf$ stty -F /dev/ttyS5 sane 9600
stehufntdev@stehuf-test-6:/mnt/c/Users/stehuf$ cu -l /dev/ttyS5 -s 9600
Connected.

Raspbian GNU/Linux 8 raspberrypi ttyAMA0

raspberrypi login: pi
Password:
Last login: Sat Dec 17 01:41:41 UTC 2016 on ttyAMA0
Linux raspberrypi 4.4.34-v7+ #930 SMP Wed Nov 23 15:20:41 GMT 2016 armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

SSH is enabled and the default password for the 'pi' user has not been changed.
This is a security risk - please login as the 'pi' user and type 'passwd' to set a new password.

pi@raspberrypi:~$

[nosajthenitram]

Not sure which of the above stty settings did it, but something pushed it to work. :)

public@systemhost:/dev$ sudo cu -l /dev/ttyS4 -s 9600
[sudo] password for public:
Connected.

Raspbian GNU/Linux

Thanks for the support in getting this going.

[stehufntdev]

Great to hear, thanks for the confirmation! Not sure why some serial devices initialize with non-conventional configurations. For the most part, WSL reports back the current configuration since there isn't really a canonical serial device configuration with the proliferation of serial devices. I'll see if we can update the blog with some of the commands above since it will probably be a common question.

@dhalbert, did the steps above resolve the issue you were seeing?

[dhalbert]

@stehufntdev I tried both the sane and raw settings you gave above. I still see neither input nor output. I wrote a small program on the board in question to print continuously to its serial port. But I also don't seem to be able to get output by doing just cat /dev/ttyS4. And in CMD, doing type COM4 just returns immediately. I also tried some PowerShell reading from COM4 as described here: https://blogs.msdn.microsoft.com/powershell/2006/08/31/writing-and-reading-info-from-serial-ports/, and that didn't work either: it just hung on the ReadLine(). So if I can't get I/O from basic Windows functions, that seems odd. It still works fine in Tera Term and Putty.

The device as shown in Device Manager is just "USB Serial Device (COM4)". The driver is WINDOWS\system32\DRIVERS\usbser.sys, version 10.0.16176.1000. The device installed with no errors, using usbser.inf to install. The Feather M0 board I'm using has native USB support on its Atmel SAMD21 processor.

[stehufntdev]

@dhalbert, thanks for the update and trying out the different scenarios! It's really strange that you can't read from the serial port with powershell, and I haven't come across a device with that behavior. I'll ask around to see if I can get something similar from our hardware lab.

One thing that might be good to check is to see if Tera Term or Putty are setting different serial port settings which cause the device to function. Can you please try the following to see if you can use powershell\WSL with the settings populated by Tera Term or Putty:

1.) Load up Tera Term or Putty so the serial device is functional
2.) Forcibly terminate Tera Term or Putty so the serial device settings are not reset
3.) Load up powershell or WSL and connect to the device without modifying the serial device settings.

[dhalbert]

@stehufntdev: I'll ask around to see if I can get something similar from our hardware lab.

Try anything you can load CircuitPython on MicroPython on. An Arduino Zero might be more readily available. I haven't tried a BBC micro:bit but that might exhibit the same behavior when loaded with MicroPython if it has a REPL. These MS guys might be able to help: https://makecode.com/blog/one-chip-to-flash-them-all, https://github.com/Microsoft/uf2.

I will test as you suggested and maybe try writing some simple test programs as well.

[dhalbert]

@stehufntdev - No luck on killing Tera Term and then using its settings (which are not unusual: 9600 baud, 8N1, no flow control).

Also tried various things from WSL using Python. I set up a program on the board to continuously output some text with numbers separated by \r\n, and then tried to read the characters from Python:

>>> t = open('/dev/ttyS3', "rb")
>>> t.read(10)

[hangs]
I also tried the lower-level os.open() interface with Python, which uses file descriptors directly. Same issue. I booted up native Ubuntu on the same computer and had no trouble getting the same Python code above to read output from the board. The stty settings on Ubuntu were stock, and I also tried raw successfully.

I have a feeling this is due to something about WSL's interactions with the stock usbser.sys driver, as opposed to stty settings. If you were talking to the RPi with a USB-to-serial cable, that adapter is probably using an FTDI or similar chip with a proprietary driver, not the older MS usbser.sys driver.

[stehufntdev]

@dhalbert, thanks for all of your persistence here really appreciate the help!

I borrowed a Arduino Mega 2560 which uses usbser.sys as well, and was able to go through the steps above for cu and write basic commands like volt and port and read the results back just fine. For comparison testing I used putty to make sure the behavior matched. Is there anything in this setup I can change to be closer to your repro?

Since both powershell and WSL don't work on your device with reasonable configuration settings, I'm starting to wonder if your device doesn't report read available correctly. If you have time to further debug, could you try out the MSDN sample code just below the "...one oversight covered later in this section" line? That block of code waits for read available and then reads the data which is what is done in WSL. Based on your results we can rule out a read available issue with the device.

Today I'll see if I can get ahold of a Adafruit M0 Feather board. If you can share out any details on your setup that might be relevant that would be helpful since I haven't worked with these devices previously :).

[dhalbert]

@stehufntdev - Thanks for looking at this. The Mega uses an Atmel 328 microcontroller, which does not have native USB support, so the board provides USB connectivity with another small microcontroller that just manages the USB port, so it may be acting somewhat differently. The M0 boards uses an Atmel 32u4-based-board which has native USB support.

I will try the MSDN code, though I have to get VS installed on the Insider machine. If you have a precompiled test for the read-available issue, I could use that, but don't spend a lot of time on building it.

To test with a Feather M0:

1. Download https://github.com/adafruit/circuitpython/releases/download/0.9.5/adafruit-circuitpython-feather_m0_basic-0.9.5.bin from https://github.com/adafruit/circuitpython/releases.
2. Download and unpack https://github.com/shumatech/BOSSA/releases/download/1.7.0/bossac-1.7.0-mingw32.tar.gz from https://github.com/shumatech/BOSSA/releases.
3. Connect the M0 to a USB port and double-click its reset button to activate the bootloader. Its LED should start pulsing slowly (fading in and out). In CMD, run
   bossac.exe -evwR adafruit-circuitpython-feather_m0_basic-0.9.5.bin
   It should scan the COM ports and find the right one. If you need to specify the COM port, do
   bossac.exe -evwRp COMx adafruit-circuitpython-feather_m0_basic-0.9.5.bin
4. Now CircuitPython should be on the board. (You may need to press the reset button once again, but I think not.) The board will come up and will report a composite USB device that is a CDC serial device, an MSC device (CIRCUITPY will mount on D:\ or whatever), and mouse and keyboard HID devices.
5. Connect with, say, Putty, and hit return. You should be in the Python REPL. You can type ctrl-D to have it restart. Try it out. Then close Putty and try it using cu in WSL, which shouldn't work.
6. If you want to get continuous output from the board, go back to Putty and write a small program in the REPL like:

i=0
while True do:
    i += 1
    print(i)

So now the board will print numbers continuously and you can test reading in WSL or in Windows proper.

There is an outdated tutorial here, but the above should duplicate what I'm doing.

[stehufntdev]

@dhalbert, thanks again! All of my serial test code was kernel mode so we couldn't reuse it here. Let me know if getting the sample setup proves to be painful and I can share out the code and a binary :).

Thanks for the details, I have a lead on a Feather M0 but waiting to hear back.

[dhalbert]

@stehufntdev - I hacked up a test program to read chars from the Feather M0 running the Python print loop shown above. I included the problematic character reading loop as described in the MSDN sample code you referenced.

Here's the program (as .txt due to GitHub upload restrictions). I started with someone else's sample serial reading code, no points for style. I removed some COMMTIMEOUT setting code which seemed unnecessary: it did not change the result:
serial_read.cpp.txt

I'm not quite sure what I'm testing here, but I hope this helps. I originally tested this on vanilla Creators Update (while waiting for VS to install on my wimpy Insider Build machine) and then 16179.

When run, the programs reads and prints about 50-100 lines of increasing numbers, and then hangs. When it starts, it reads some old output that seem to have been previously buffered and then skips ahead to the latest set of consecutive numbers:

Port COM4 Opened
 5461192
5461193
[...]
5461201
56641910
6641911
6641912
[...]
6642002
6642003
6642 [hangs here]

[stehufntdev]

@dhalbert, thanks for sharing out the results. Based on the above the device reported back read available but it's concerning that it hung. Going through your sample code I realized we wanted to try out the block without the caveat :(, sorry for the oversight there. If it's not too much trouble could you re-run with the code in the block just below in the sample that has a do while loop on the read? I'm hoping to rule out the hang is a result of read available.

Also, thanks for your tip on the https://github.com/Microsoft/uf2 project. I spoke with that team and was able to borrow a Feather M0 to setup a local repro. I should be able to start debugging today and will report back.

[dhalbert]

@stehufntdev - With the do-while loop added, the sample program works just fine. It continuously reads my continuously-printing python loop above.
serial_read2.cpp.txt

Glad you got in contact with the uf2 people. Their bootloader is very nice.

Version 0.9.6 of CircuitPython is now released. I just tested it with cu as well: same problem. Knowing what was fixed, I did not expect a change.

[stehufntdev]

Thanks @dhalbert, appreciate all your help here. I was able to reproduce the hang with the device and tried a few different scenarios. Here's one that was particularly concerning:

1.) Reboot machine
2.) Run serial_read2.exe
3.) serial_read2.exe doesn't show any output

However, if I then connect with putty, putty shows the output. If I then close putty and rerun serial_read2.exe it shows the output just fine. Can you confirm if you are seeing the same behavior?

Based on the above, the serial device doesn't output with standard settings and putty is setting something that makes it work. Not sure I would go as far to say that the device is buggy since it does work with putty and I'll do some more digging to see if I can narrow down the setting.

[MikeGitb]

as I think my previous comment two weeks ago was missunderstood: Accessing com ports is not possible in the Creators Update but only in a later Insider Preview. Right?

[stehufntdev]

@MikeGitb, yes serial port support is only in the latest insider preview (post Creator's update).

[dhalbert]

@stehufntdev - I duplicated your results. Note that you don't have to reboot: pulling the USB plug and then replacing it (and waiting until the CIRCUITPY drive shows up) will reset the port.

I looked at the putty source code to see what it was setting, and I've found the change that will make serial_read2.exe work! You have to set .fDtrControl to DTR_CONTROL_ENABLE. It must be that value and no other. Here's the putty source code, and the line in question: https://github.com/Yasushi/putty/blob/master/windows/winser.c#L109

Add the .fDtrControl setting to serial_read2.cpp:

	dcbSerialParams.BaudRate = CBR_9600;
	dcbSerialParams.ByteSize = 8;
	dcbSerialParams.StopBits = ONESTOPBIT;
	dcbSerialParams.Parity = NOPARITY;
	dcbSerialParams.fDtrControl = DTR_CONTROL_ENABLE;   // NEW - Makes it work
	//dcbSerialParams.fDtrControl = DTR_CONTROL_HANDSHAKE;  // Does not work.
	//dcbSerialParams.fDtrControl = DTR_CONTROL_DISABLE;  // Does not work.

So the serial code on the M0 is expecting that the host will assert DTR (Data Terminal Ready), and does not transmit until DTR is enabled.

stty used to list an option cdtrdsr to toggle DTR support. However, it's not in the current one shipped with Ubuntu. stty was changed not to include unsupported options in 2014. I think this is because stty uses tcsetattr() to change serial device modes. To toggle DTR, it looks like you need to use ioctl() with TIOCIM_DTR.

So maybe this all has to do with the ioctl() stuff you haven't implemented yet. It may be that DTR is asserted by default on Linux systems when a serial port is opened, so this problem doesn't show up there.

EDIT: I found out about the MODE command in CMD, which conveniently describes the properties of a COM port and lets you change them easily.

[MikeGitb]

@stehufntdev: Thanks for the clarification (disappointing as it is)

[benhillis]

@MikeGitb - worry not! Windows is targeting a release twice a year so users on stable builds won't have to wait long.

[stehufntdev]

Thanks @dhalbert, I narrowed it down to the DTR bit as well and also discovered the mode command :). Here's a basic repro using your test:

hang:
mode com3 dtr=off data=8 parity=n
serial_read2_settings.exe

no hang:
mode com3 dtr=on data=8 parity=n
serial_read2_settings.exe

As you suspected DTR is part of the ioctl support and isn't included in termios. I started working on the fix and will report back when it is finished. Thanks again for brining this to our attention!

[dhalbert]

@stehufntdev, great!

Are you going to try to emulate how serial ports come up on Linux? Or is that not really worth it? It does appear that they start with DTR (and maybe other things) asserted. Maybe one way to do that would be that the first time /dev/ttySx is opened, you would set DTR, etc. as it would be on Linux.

As we saw usbser.sys does not do this. I tried a couple of other proprietary Windows drivers: the FTDI driver used for a USB-to-serial cable (e.g. for RPi) does turn on RTS. The driver supplied by Silicon Labs for their CP2104 USB-to-serial chip (used for example here) does not.

[stehufntdev]

@dhalbert, to err on the safe side we need to rely on the Windows serial driver to set the correct defaults when the serial port is opened. I thought about adding initialization code in our layer, but there are so many different serial configurations that any defaults we picked would be the wrong ones.

It looks like some versions of stty support configuring DTR, but I'm not seeing that option in the version included with Xenial. If this ends up causing a lot of issues we can take another look at a default configuration but I think those changes should really be in the serial driver.

[stehufntdev]

@dhalbert, I'm hitting another strange issue with the device. If I update your sample code to not call SetCommState, the device hangs even if I set everything up through mode before hand. I would have expected the device to work just fine in this scenario.

Might be worthwhile to contact the company or search around to see if anyone else is having issues when reading from the device in code. I think supporting this in WSL might be tricky since the device seems to be very sensitive to the settings.

[dhalbert]

@stehufntdev: Could you give the the MODE settings output before you run serial_read2 without SetCommState() and get the hang? I will check it out. Can you still read from the device via Putty or Tera Term? I suspect it might be yet another setting.

The serial code used is the standard library supplied by Atmel for the microcontroller, incorporated into CircuitPython. It's all open-source and I'm helping on a volunteer basis to debug all this, so I'll look deeper.

[stehufntdev]

@dhalbert, yes I can still read fine from the device via putty. To follow-up on the experiment above, I updated your sample code to call SetCommState without changing the values from GetCommState (i.e. set to the current). After this, the device worked fine so the board seems to have some requirement that after opening the state has to be set.

[stehufntdev]

@dhalbert, I was able to narrow down the device hang some more. SetCommState calls EscapeCommFunction to set\clear RTS and DTR so the line matches the value passed to SetCommState. When the feather M0 is opened, the DTR line is clear and needs to be set to transfer data. To double check I updated the same code to call EscapeCommFunction with SETDTR instead of SetCommstate and it worked fine. SetCommState has a comment that this is required for Win95 compatibility :), but I don't know the history of that code.

If you can update the serial code on the devices, my recommendation would be to have the device come up with the correct serial settings for transfer. Also, DTR doesn't seem to have first class support everywhere (e.g. Linux) but I imagine switching over to another mechanism may be costly.

Going through the serial layer in WSL, I think we can support this device but it will likely be easier to configure from Windows first since the Linux tty tools I found don't have support for DTR. Here's a quick summary of the changes I will make:

1.) Match SetCommState's behavior of updating the RTS and DTR line to match the configuration.
2.) Add support for ioctls to configure DTR and other settings

With some quick testing I was able to open the device with cu once it was configured.

[dhalbert]

@stehufntdev, thanks for the update. I looked at the source code for this device and also did some other research. In general, the libraries for these kinds of devices (not just Atmel) use DTR and/or RTS to determine whether they should send output. If DTR is not asserted, they assume they are not connected. Changing this might break a bunch of assumptions, so I'm leery of that.

On Linux, DTR appears to always be asserted when a USB CDC device is connected, at least for the generic CDC driver. On Windows, usbser.sys, the generic driver, does not assert DTR automatically. So whatever program uses the port needs to do the right thing for the device. So Putty, etc. all set DTR and things are fine.

The best thing may be for me just to have a little utility to do the ioctl() to set DTR. Terminal programs do not necessarily do this: I looked at the source for minicom and screen and they don't appear to control DTR (though minicom will report its value!). And since cu is an antique program meant for modems and real serial ports, it never really had to deal with this, it seems.

One thing I stumbled on about using EscapeCommFunction() to set DTR and RTS: In the past, and maybe currently, usbser.sys does not let you assert RTS before asserting DTR. So you have to call it twice. I saw this mentioned several places. It is described most clearly here: http://dangerousprototypes.com/forum/viewtopic.php?f=29&t=2435:

there is a bug in the windows CDC driver in that it does not pass on the value of the RTS signal until DTS [sic, DTR] is also updated.

I don't know if this is really a bug or is by design, but you might need to watch out for this. Also mentioned here and here.

[stehufntdev]

@dhalbert, thanks all sounds reasonable to me.

I tested with a few more serial devices and submitted the changes described above. This should work on a future insider build and the test program could use mode from cmd.exe or from WSL you can use the TIOCMSET\TIOCMBIS ioctls with TIOCM_DTR. Once the changes are out I'll update the blog post with the devices and some more examples.

[123swk123]

I am getting

fcntl.ioctl(self.fd, TIOCMBIS, TIOCM_DTR_str)
OSError: [Errno 25] Inappropriate ioctl for device

I guess this is already been taken care for future release, if not then we need to make DTR control work not sure RTS works or not

[stehufntdev]

The fix hasn't made it out to insider builds yet, but I will update the tag on the thread when it does and the blog post to include the supported ioctls.

[Raphdeumax]

Hi Everyone,
Have you find a solution to connect a dongle USB in the WSL ?
I would like to connect a dongle USB Wifi on a Kali distribution.
Thank's ;-)

[sunilmut]

@Raphdeumax - If your USB WiFi device is getting enumerated by Windows, conceptually it should work within bash. Is the WiFi device not showing up in ip addr show or ifconfig? Also, this looks dupe of #1077. Might be better to post there.

[Raphdeumax]

HI @sunilmut and thanks for your response.
I'm trying to connect a wifi dongle on a Kali but the interface "wlan0" does not appear in "wifite" or "ifconfig". Do you think it is possible to install a driver to interpret the Wifi dongle ?

[sunilmut]

@Raphdeumax - Is the interface showing up on Windows, in ipconfig /all? Also, which version of Windows are you using (please share the output of the ver command from CMD)?

[TimV81]

@stehufntdev & @dhalbert - I have been following this issue since I tried to work with my microPython device earlier this year through my WSL setup and stumbled upon this issue. I previously got to the "Connected" message after launching cu, but no in- or output was displayed.

I just installed the FCU. After uninstalling the previous "Bash on Ubuntu on Windows" system, and installing Ubuntu WSL through the Windows Store I can confirm this issue has been resolved and in- as well as output to the usb serial device works perfectly! Well done!

[therealkenc]

Thanks @TimV81. Closing this out. 16176 and FCU.