I'm following the sample application of a Webserver, handling incoming requests through TCP with a Port.
Sample application with code: https://incredibits.io/project/windows-10-iot-internet-of-things-tips/windows-10-iot-raspberry-pi-web-server
When debugging the UWP application on my Windows 10 machine, and try to access the the local IP (192.168.x.x <- Ofcourse I've entered my actual local IP) I get what I'm supposed to. The application get's an incoming request and returns some data back to me (The client) on another computer of mine.
The issues I'm facing is when I deploy this to my Raspberry Pi 3 running Windows 10 IoT Core (The newest from Insider), I can't access the application from my client computer at all. Is this a thing with the Pi's firewall or something else preventing this?
I CAN access the IoT Core's Web interface on port 8080, but I cannot access my application running on port 80. (I've tried switching the port to another one aswell, works locally on my Windows 10 but not on the Pi)
Does anyone know a solution, or have faced a similar issue?
Note:
I've also tried examples like (https://ms-iot.github.io/content/en-US/win10/samples/BlinkyWebServer.htm) which again, works on my Windows 10 pc, and can be accessed by my other PC if their on the same network, but not on my Pi)
I found the solution to my problem.
The port I was using, wasn't opened up in the Raspberry Pi's Firewall. I couldn't find how to add a rule to the Firewall but after some help on Freenode C# Chat forum, I found the following snippet:
First I log into the Pi through PowerShell
Enter-PsSession -ComputerName MyRaspberryPi-Credential MyRaspberryPi\Administrator
Then I manually add the Firewall opening of the port I'm using. In this case port 8080.
netsh advfirewall firewall add rule name="Raspberry Pi Webserver" dir=in action=allow protocol=TCP localport=8080
After that, everything worked as expected. I could access the port on my Raspberry Pi! All good!
Thanks to #canton7 and #taylor-kidd in the comments, for coming with suggestions that in the end helped me!
EDIT 12th of April:
It seems like this issue with the Firewall not being opened, was actually a known issue by Microsoft already. They write that in their Relase notes for the Insider Preview version 14295 (Which I am using) here http://ms-iot.github.io/content/en-US/win10/ReleaseNotesInsiderPreview.htm
I'm currently working on Universal Windows Application(Windows 10) which will communicate with another hardware via virtual COM PORT.
I have tried to use Windows.Devices.SerialCommunication.Serial Port API to communicate. I haven't got any problems on listing available COM ports and opening specified port. Problems occurs on write/read commands on given COM port. I can't receive any answer from mine hardware (received timeouts instead). While using commandline (echo XX > COM4) there wasn't any problems - I received answer on second commandline(type COM4) nearly immediately.
Changing read/write timeout have not solve issue. I'm also sure that Baud Rate and others serial port parameters are ok.
Any ideas why I always get timeouts?
Found the cause of this problem: I have not add new line signs at end of command. In windows cmd this had to be added automatically.
I am trying to read data from a serial device. It has an LED that turns on when I connect it to an actual serial port (on an old XP machine).
On my target machine however, I need to use a USB-serial adapter, and the LED does not turn on when connecting it.
It does turn on when I open the serial port with Putty or Hyperterminal though.
Now I have been trying to read it in my .Net project, and in order to do that, i run the example code from the MSDN documentation here :
https://msdn.microsoft.com/en-us/library/system.io.ports.serialport.readline%28v=vs.110%29.aspx
when I do, nothing gets read from the port, and the LED does not even turn on. I would expect it to turn on whenever I hit the
_serialPort.Open();
but it does not.
Is there a specific step, or configuration, or workaound, to ensure the serial port receives power when using USB adapters?
My serial device is a GlobalCaché GC-IRE.
The USB adapters I have been testing: 3 different ones, two no-names and one TrendNet TU-S9.
We have a server application (developed using .Net 1.1, C#) which listen the port 8086 and the client application, before starting will handshake with this server using remoting.
The application is working fine in almost all environments - Windows 2000/2003/2008/XP/Vista.
Now we are facing an issue with Windows 7.
When we are staring the server, it’s opening the port and will be listening to clients, but when try to send a request from a client who is running in other OS, it gives a message that server is not running.
We disabled the proxy, gave the exceptions for proxy but all went in vain. On further analysis we found that the system is having multiple connectivity (LAN, Bluetooth &WIFI).
When we checked the TCP port using netstat –a it showed the Local Address as 0.0.0.0:8086. So we disabled/removed the Bluetooth & WiFi option and tried again then also netstat is showing LocalAddress 0.0.0.0:8086.
How to go ahead in this situation?
Thanks in advance.
Do a network capture using Microsoft Network Monitor or Wireshark to better understand the underlying TCP/IP packets. That can show what's up easily.
In my C# 2008 application, I use the SerialPort.GetPortNames() function to retrieve the list of currently available ports. What I have noticed is, when ever I plug in a USB device, it's port number i s shown in the list on my Application and when I unplug it and refresh the list, the port number is no longer there.
One phase of the application involves reading/writing data from/to the device continuously. Now, my expectation is, If I unplug the device during the operation and get the current Port list using SerialPort.GetPortNames(), the Port Name will not be there and I can use that to make the decision that the device has been unplugged.
To my surprise, the Port name is still found despite having it removed
Why is the program behaving like this? The port name isn't listed when in no-communication mode. Does it have something to do with the device being removed when it's communicating?
You have to be talking about SerialPort.GetPortNames(), "GetPortList" doesn't make sense. The function iterates values in the registry, written there by your USB emulator device driver. You can have a look-see with Regedit.exe, navigate to HKLM\Hardware\DeviceMap\SerialComm. Unplug it, press F5, if the COM port is still there then SerialPort doesn't know any better than the port still being present.
There is no prescribed behavior as to how a serial port device driver should behave when the port suddenly vanishes. Serial ports are very primitive, they date back to an era where "bug" meant a moth gumming up the teletype. There is no hardware support at all for Plug and Play, removing a port with the power turned on is equivalent to unplugging the disk drive while Windows is swapping to the paging file.
Most device drivers return an error code, it generates an uncatchable exception that crashes your program. The subject of this feedback article. Apparently your device driver doesn't do that, which ought to be preferable over bombing your program. Encouraging btw, most USB emulator device drivers are utter junk.
The ultimate workaround is simple: put a little tag on the plug "don't disconnect while in use!" It's kinda of a problem with USB, most people look at it and go "hmm, what can I do with it?". And arrive at the only answer and unplug it. After a couple of kabooms, they'll learn to not do that anymore.
I'm assuming you mean System.IO.Ports.SerialPort.GetPortNames(), because i could not find a GetPortList() function anywhere. MSDN says: "If the registry contains stale or otherwise incorrect data then the GetPortNames method will return incorrect data", so that's probably where the problem lies. I guess Windows doesn't update the registry if the port is still being 'used', just like you can't delete a file when a program has a handle on it.
If you want to test if the device is removed, you can do so with a Window API call (http://www.pinvoke.net/default.aspx/user32/RegisterDeviceNotification.html). Hope that helps!
It is correct that GetPortNames() reads the ports from the Registry key
HKLM\Hardware\DeviceMap\SerialComm
This is automagically updated by Windows every time a port is opened or closed.
But nevertheless it has happened to me that there is a non-existent Port listed in the Registry, and also returned from GetPortNames(). When I try to open this port I get "The Port XYZ does not exist".
What is that ???
I now found out the reason:
This happens always after using PortMon from www.sysinternals.com.
This tool is buggy and lets the dead port hanging around in the Registry if the port is closed while it is monitored.
In this case the only remedy is to reboot the computer.
As others have mentioned, it's very driver-specific. There does not appear to be a way to check with the .Net API whether a port returned by GetPortNames() actually exists and is valid.
As for why the ports behave like this, I have found that some USB-to-serial drivers cause the application to crash when the port is unplugged suddenly.
Other drivers, often those that do not crash, will keep the port in the list until your application closes it, then it disappears. Trying to read from or write to the stale port will (usually) cause timeouts or errors. Presumably, in order not to crash the application, the driver needs to keep the stale port around while it is still open in the application.
If you plug in the port again, some drivers are even be able to reconnect it to your application, others will not recognize the port until your application closes the stale port. This reconnecting behaviour can be somewhat dangerous if the port disappeared because the device rebooted, because then it will suddenly be in a different state than your application expects without an obvious indication that it has reset. At least if you get errors from the port you know that something happened.
I've also found that if I forget to close the port, it won't disappear from the list until the garbage collector gets around to disposing the SerialPort object.