I recently updated my IDE to Monodevelop 6 using Flatpak, on Ubuntu 16.04 LTS, from an older version 5.
I have an application that interacts with serial ports which is basically a USB/RS232 adapter connecting a device to my computer.
I have no issue accessing USB port (/dev/ttyUSB0) when I debug the application in Monodevelop5. However, the device directory (/dev/) that I have access to, using Monodevelop6 is completely different than the one I have access to in Linux, and there is no ttyUSB0 in that folder.
I believe this is because Flatpak runs the application in sandbox. So, if that is the reason, how can I access to a serial port then?
Thanks.
Most likely that's because Flatpak is blocking access to the serial device.
Unfortunately at the moment I don't think there is a way to give access specifically to the serial devices, so you'd need to give access to all:
$ flatpak run --device=all com.xamarin.MonoDevelop
What this does is essentially mount the host's /dev inside the sandbox, so the app has full access to it.
It's a pretty big hole in the sandbox, but sometimes it's needed until all the permission handling stuff gets implemented.
Related
I am a developer of ROS projects. Recently I am trying using ROS(melodic) on WSL2(Windows Subsystem for Linux), and all things works just great. But I got some trouble when I want to use another PC which also in the same local area network(LAN) to communicate with. Before setting the environment variables like "ROS_MASTER_URI, ROS_IP", I know that since WSL 2 work on Hyper-V so the IP show on WSL2 is not the one in the real LAN. I have to do some command like below in order to make everyone in LAN communicate with the specific host:PORT on WSL2.
netsh interface portproxy delete v4tov4 listenport=$port listenaddress=$addr
But here comes a new question:
The nodes which use TCPROS to communicate with each other have a random PORT every time I launch the file.
How can I handle this kind of problem?
Or is there any information on the internet that I can have a look?
Thank you.
The root problem is described in WSL issue #4150. To quote from that thread,
WSL 2 seems to NAT it's virtual network, instead of making it bridged
to the host NIC.
Option 1 - Port forwarding script on login
Note: From #kraego's comment (and the edited question, which I'm just seeing based on the comment), this is probably not a good option for ROS, since the port numbers are randomly assigned. This makes port forwarding something that would have to be dynamically done.
There are a number of workarounds described in that issue, for which you've already figured out the first part (the port forwarding). The primary technique seems to be to create a PowerShell script to detect the IP address and create the port forwarding rules that runs upon Windows login. This particular comment near the top of the thread seems to be the canonical go-to answer, although many people have posted their tweaks or alternatives throughout the very long thread.
One downside - I believe the script that is mentioned there needs to be run at logon since the WSL subsystem seems to only want to run when a user is logged in. I've found that attempting to run a WSL service or instance through Windows OpenSSH results in that instance/service shutting down soon after the SSH session is closed, unless the user is already logged into Windows with a WSL instance opened.
Option 2 - WSL1
I would also propose that, assuming it fits your workflow and if the ROS works on it (it may not, given the device access you need, but not sure), you can simply use WSL1 instead of WSL2 to avoid this. You can try this out by:
Backing up your existing distro (from PowerShell or cmd, use wsl --export <DistroName> <FileName>
Import the backup into a new WSL1 instance with wsl --import <NewDistroName> <InstallLocation> <FileNameOfBackup> --version 1
It's possible to simply change versions in place, but I tend to like to have a backup anyway before doing it, and as long as you are backing up, you may as well leave the original in place.
Qt Quick WebGL Streaming is a technology by which any Qt Quick ("QML") application can display its user interface to a user connecting via a web browser. All you have to do is to start the application like this on the host:
./my-qml-program -platform webgl:port=8080
This works, but is limited by design so that only one user can be connected at the same time and see the user interface. As the reason for this, they quote problems with user input, with querying the GPU, and with security (source).
Initially, the Qt developers wanted to support multiple users in WebGL streaming by serving multiple windows from one process:
How will concurrency be supported? Like does each connection get it's own QGuiApplication, or is there only one? […] You create a single QGuiApplication and different windows. There is a signal to notify when new clients connect to the HTTP server. When the signal is emitted, you create a different QWindow. The windows are independent (source)
Now however, the developers want to support multiple users in WebGL streaming by launching one process per user.
We are working in decoupling the HTTP Server from the plugin
A dedicated HTTP Server application will be provided
Instead of running all the users in the same process a new process will be spawned per user
The new process will handle the web socket
(source)
"Decoupling the HTTP Server from the plugin" would mean replacing it with QHttpServer:
I have planned some use-cases for this [QHttpServer] module: Change the current embedded web server (and WebSockets) in the WebGL plugin to make it easy to create your own custom solutions based on the plugin. (source)
So far, no solution has been implemented. What is the simplest way to implement support for multiple users in Qt WebGL streaming myself, without waiting for Qt to implement this?
Here is a solution that uses the load balancer Pen to make a Qt application accessible via WebGL streaming to multiple users at the same time. It forwards an incoming connection to one of multiple Qt processes running on the same host, each of which running its own embedded web server. This kind of forwarding is exactly the job of a load balancer, just that it usually distributes connections to multiple hosts.
Caveat: In my tests, WebGL streaming in Qt 5.12.3 is fast enough for real use only in the local network, not over Internet. So you can't use it to "convert a Qt application into a web application on the cheap".
Instructions
These instructions apply to Ubuntu 19.10, 20.04 and other Debian based distributions.
Install the Qt application on your web host.
Install the Qt WebGL platform plugin on your web host. It is not contained in the Ubuntu 19.10 distribution, for example. In such a case, you'd have to compile and install it yourself. Under Ubuntu Linux, the result should be the following file:
/usr/lib/x86_64-linux-gnu/qt5/plugins/platforms/libqwebgl.so
Start multiple processes of the Qt application. Each should serve one port with Qt WebGL streaming. Here we start three processes, but you can start as many as fit into your memory.
nohup myapplication -platform webgl:port=8080 &
nohup myapplication -platform webgl:port=8081 &
nohup myapplication -platform webgl:port=8082 &
Install the load balancer Pen.
sudo apt install pen
Start the load balancer. Note that with pen 80 … it is started so that the users only have to enter a simple URl such as http://example.com/ into their web browser to visit the application. If port 80 is already in use, you can choose any other port (say, 9090), start the load balancer with pen 9090 … and then let users visit a URL like http://example.com:9090/. Also note the :1:1 suffix for each server process listed, telling pen to only connect at most one client to one process.
pen 80 localhost:8080:1:1 localhost:8081:1:1 localhost:8082:1:1
Test the setup. To test, visit the associated URL http://example.com/ from multiple devices. You shoud be served one process of the application on each device. It is not possible to see two processes in two parallel browser tabs on the same device – pen would then try to connect the second such tab to the same Qt process as the first tab because the request comes from the same IP address. As a result, you'd see a spinning wheel in the second tab, because Qt processes only allow one connection each for WebGL streaming.
Improvements
This solution could be further improved by starting the Qt processes only on demand, once a client connects. This should be possible with systemd socket activation.
Is there a better tool than WireShark to sniff out where given application is trying to connect and at which port. (So that I could easily overwrite it with my HOSTS file). Being able to log packet data is helpful too.
Ultimately I would prefer an application that I could just throw a running process at and start logging the network activities of the given app
Of course the application and sniffer will be running on the same PC. Preferably I would love a Windows sniffer. Since running that app on Linux will be .... difficult.
Answering myself: http://www.sysprobs.com/monitor-network-traffic-windows-7-microsoft-network-monitor-34
This article helped me big time. The tool in there is really great.
Have you tried socket sniff?
It should let you monitor specific applications:
socket sniff
I am building a app that has a javascript layer on top that uses QtWebkit to occasionally access web pages; however if I start my app up without a wireless connection and then set up a connection (using ifup then a device connect then dhcpcd to get the gateway set up) the Javascript continues to be oblivious to the gateway to the wider world.
QNetworkConfigurationManager in my QtApp reports the connection is up OK after I updateConfigurations() and the IP and netmask are reported OK as well.
wget from the command prompt happily obtains whatever webpage I ask it to get.
But if I create an instance of QNetworkAccessManager then
manager->get(QNetworkRequest(QUrl("http://www.google.com/index.html"))); replies that it cannot reach the page.
Do I need to poke an update the QtWebKit somehow for the JS layer to update it's configuration as well?
The problem has been found; the implementation of Qt for embedded we have has an error in it for our implementation of uclibc. This has been patched by the (deleted for security reasons) company that supplied us with the libraries for our embedded solution.
I'm wondering if there is a way to create an asp.net webpage that will connect a visitors USB device to an application on the windows bases server? This way we avoid having to install a software on the visitors computer to control a USB device update that they purchase form us.
All they have to do is visit our update page, plug their deivce to the USB, and have our site update the usb hardware.
Possible? or am I dreaming? :)
i found software like: USB over IP, and few others. But not show ure its possible to create a C# or vb.net based ASP.net page to control the visitors USB device.
Please advise.
In general, Web pages and scripts that run in browsers are limited in what local system resources they can access. Direct access to hardware like USB devices has obvious security implications.
The only way I can think of to do this might be an ActiveX control (IE only, I think) or some other kind of browser plugin.
One possibility is building a webserver into the USB device. Give the device internet access, and get it to download its own firmware in a process controlled through the webpage that the usb device serves.
Note that I have no idea if this is actually possible, just thought I'd throw in this different way of looking at the problem.
It is possible to create an ActiveX/.NETcontrol/Java Applet that will do it.
Granting the rights to this thing to access local devices will require certain security setup which can be automated, but in any case will require some user consent/interaction
I see here 2 ways:
ActiveX control
The problem is that the user should first download and install the
ActiveX from an Internet web server or from a local file
USB Device driver + DHCP Server + Web server embedded in the
device
Your USB device, once plugged, should present itself as a "Virtual
Ethernet Interface" in order for Windows to add the driver to the
list of the Internet Connections.
The Device should have also a DHCP server in order to give Windows
an IP address. Beware of the fact
The USB Device should also have an HTTP server.
At the end of this process, Windows will have 2 IP addresses.
Now you have to figure out how to have IE point to the index.html
file of the device.
Buy/Find a commercial software
You are not the first guy on this planet that has similar
requirements.
The only way I can possibly imagine doing this is through JAVA
EDIT: Looks like there might be an ActiveX way to do this as well, though ActiveX is Internet Explorer only, which limits it's usability.