I am currently working on a robotics simulation environment.
Robots, that can interact with he virtual wold can be controlled/monitored via a network connection.
For the whole network communication (and of course other things e.g. Threads) we use the ACE library.
The problem I have now is that it seems to me that the asynchronous UDP part is broken.
When running the test program "test_udp_proactor -h localhost -p 55555" that comes with ACE I will always get the errorcode 89 (Destination address required).
So far this is what I tried, but nothing helped:
recompiling newer/different versions of ACE
modifying the code of test_udp_proactor, recreating a similar program
changing the environment (different PC with 32bit CPU and Ubuntu 9.10)
When using synchronous methods everything works just fine, so there is no error with the network hardware/software.
I searched google and this site for hours/days now and it seems that nobody else has this problem! At least I can't find it.
I am really frustrated now, because as far as I understand it, ACE is really mature and reliable. Though some people are very fond of the design of it.
It is used in the aerospace community, where reliability and Real-Time aspects are a must!
I can't believe ACE doesn't support asynch. UDP communication and/or nobody else found that out.
Can somebody run a simple test for me with test_udp_proactor to verify this behavior?
We have to use a real-time capable system, so windows is not an option...
Any other hints and/or tips, preferably from the ACE-gurus ? :-)
Thank you very much
Try looking at the problem at a system call level. Use strace to see what system calls and values are being sent to the kernel and what error codes those system calls are returning.
You may find your problem quickly.
Related
I'm posing a question here directly in relation to this issue on github for node-serialport. In a nutshell something that used to work fine in v4.x of the library no longer works in v6.x of the library. I think it must have something to do with how the library is opening the COM port (options or something), and I suspect its artificially limiting the power delivered over USB in the current version of the library.
I wrote the simplest scripts that I could to reproduce the problem (scripts posted in the issue) using:
NodeJS and v4.x of the library [works]
NodeJS and v6.x of the library [fails]
Python and PySerial equivalent [works]
Following through on a recommendation by the repository maintainer, I researched and found a utility for windows called drstrace that allowed me to capture logs of the execution of each of these scripts executing for a period of time (these logs are posted as attachments in the referenced issue).
Now I'm stuck, as I don't know how to make heads or tails of the drstrace logs, though I feel confident that the difference is probably evident in comparing the three files. I just don't know enough about how to read the drstrace logs and windows drivers and system calls to break through.
I realized posting this question here is something of an act of desperation, but I figure it's worth a shot. Hopefully it is clear that I've not lacked in effort pursuing this on my own, I'm just over my head at this point, and could use help getting further. Any guidance would be appreciated. Most awesome would be someone who is versed in this level of diagnostics giving it a look and reading the tea leaves. It would be great to contribute back to such an important open source library.
Update 2017 Nov 10
I reached out to FTDI support asking:
I use the FT231X in many of my products. I need some help with
understanding how the Windows FTDI driver manages power. More to the
point, I'm hoping you can help me understand how to direct the driver
to allow the full 500mA allowed by USB to be delivered to my product
by a Windows computer.
The reply was:
Just use our FT_Prog utility to set the max VBUS current to 500
mA:
This drive current becomes available after the FT231X enumerates.
I haven't tried this advice yet, but I wanted to share it with anyone reading this. The fact remains that node-serialport 6.0.4 behavior differs from both node-serialport 4.0.7 behavior and pyserial behavior.
Here is an alternative theory you could look into:
Windows interacting with V6.x might be interacting with the flow control settings differently, which might be causing your device to respond with an unexpected state causing your test to fail.
I Read a bit more about windows drivers and how they manage that i only found out that its related to the hardware manufacturer i think its not a fail from serialport it self since its really using the drivers it self it adds no extras on that level.
i am Contributor of SerialPort and can tell you that it offers only bindings for the Operating System to node that means it don't does any actions it offers you only a API read the following from microsoft they say you should ask your hardware vendor
Power Management in Serial Port Drivers (Windows CE 5.0)
Windows CE 5.0
Send Feedback
The minimum power management that a serial port driver can provide is to put the serial port hardware into its lowest power consumption state with the HWPowerOff function, and to turn the serial port hardware fully back on with the HWPowerOn function. Both of these functions are implemented in the lower layer. Beyond this minimal processing, a serial port driver can conserve power more effectively by keeping the port powered down unless an application has opened the serial port. If there is no need for the driver to detect docking events for removable serial port devices, the driver can go one step further and remove power from the serial port's universal asynchronous receiver-transmitter (UART) chip, if no applications are using the port.
Most serial port hardware can support reading the port's input lines even without supplying power to the serial line driver. Consult the documentation for your serial port hardware to determine what parts of the serial port circuitry can be selectively powered on and off, and what parts must be powered for various conditions of use.
Source:
https://msdn.microsoft.com/en-us/library/aa447559.aspx
about changes from serialport v4 => 6
new Stream Interface
but nothing changed with the core opening method of the port.
also nothing changed in the bindings which open the port
node serialport is a collection of bindings written in c++
I have an application which I need to port on Linux. I was thinking to use Free Pascal the problem is the application uses Windows API's to perform tasks such as serial port communication etc... Is there a msdn for linux users or a book covering how linux works internaly if there are apis.
I am very confused.
Well, it's sad to say but if your code in very Windows-dependend (not VCL depended!) then probably it'll be faster to write the application from the begining rather then porting it.
But if it's only serial port matter then give a try to multiplatform SynaSer library, find it here: http://synapse.ararat.cz.
hope this help :)
Robert Love has a book on Linux Systems Programming - that will cover this area and Love's books are generally good, so it is worth looking at.
It's not entirely clear from your question, but if your concern is that there are specific calls to hardware controlling functions in your Windows application that make it difficult to port I would suggest that is a misplaced fear. Both Windows and Linux operate on the principle that the application level programmer should be kept away from the hardware and that all that should be handled by the operating system kernel and only be accessible to applications via system calls. As the kernels of different operating systems face similar demands from users/applications, they tend to have system calls that do the same sorts of things. It is necessary to match the system calls to one another but I can see no reason why that should be impossible.
What may be more troublesome is that your Windows application may rely heavily on the Windows executive's windowing code/API. Again finding analogues for your code is not impossible but is likely to be a bit more complex e.g. in Linux this stuff is generally not handled in the kernel at all (unlike Windows).
But then again, your code may be written against a portable toolkit/library like Qt which would make things a lot easier.
Good luck in any case.
If the program contains GUI code you must use linux libraries like GTK/XLIB in order to create windows, forms, buttons, etc...
Windows specific functions (like EnterCriticalSection, WaitForSingleObject or _beginthreadex) must be replaced with equivalent linux api functions (a nice tutorial can be found here:
"www.ibm.com/developerworks/systems/library/es-MigratingWin32toLinux.html") or you can use libraries such as w2lpl or wine
A useful library for this kind of problems i've found at http://www.adontec.com/windows-to-linux-port-library.htm
I've had great experiences just using WINE. (https://www.winehq.org/)
You don't really port your app at all. You just make sure it doesnt violate some of the basc constraints of WINE and just run it as is. WINE (though is says it is not) is an emulator of the windows API's and will just do the translation for you. It's pretty complete in its coverage of the API's.
i am newbie to Linux platform, i am working on java technology.
what i have to do is : Having a program that running on mobile devices,that sends some data to my Linux machine, now i have to create a program in java that
listen to a particular port.
access data comes on that port(which is sending by mobile device)
save that data to the database.
response back to the mobile device.
i.e. i would make my Linux system as server that can listen from many clients(mobile devices), but not getting how to configure this environment... :(
i used cent OS 5.4 and
installed jdk1.6.0_24
any help would be appreciated.....
thanx in advance!
khushi
One of Java's greatest strengths is that you can pretty much ignore the host operating system as long as you stick to core Java features. In the case you're describing, you should be able to accomplish everything by simply using the standard Java networking APIs and either the JDBC to access an existing, external database or you could choose any number of embedded Java databases such as Derby. For your stated use case, that you'll be running the application on Linux is pretty much irrelevant (which should be good news... you don't need to learn a whole operating system in addition to writing your app ;-).
Here's a nice client/server tutorial, in that it is broken into steps, and adds each new concept in another step.
Here's another client/server tutorial with much more detail.
I would write it to accept one connection at a time. Once that works, I would study the new(ish) java.lang.concurrent classes, in particular the ExecutorService, as a way of managing the worker bee handling each connection. Then change your program to handle multiple connections using those classes. Breaking it up in two steps like that will be a lot easier.
Is it possible to create GUI firewall that works as Windows and Mac counterparts? Per program basis. Popup notification window when specific program want to send\recv data from network.
If no, than why? What Linux kernel lacks to allow existence of such programs?
If yes, than why there aren't such program?
P.S. This is programming question, not user one.
Yes it's possible. You will need to setup firewall rules to route traffic through an userspace daemon, it'll involve quite a bit of work.
N/A
Because they're pretty pointless - if the user understands which programs he should block from net access he could just as well use one of multiple existing friendly netfilter/iptables frontends to configure this.
It is possible, there are no restrictions and at least one such application exists.
I would like to clarify a couple of points though.
If I understood this article correct, the firewalls mentioned here so far and iptables this question is tagged under are packet filters and accept and drop packets depending more on IP addresses and ports they come from/sent to.
What you describe looks more like mandatory access control to me. There are several utilities for that purpose in Linux - selinux, apparmor, tomoyo.
If I had to implement a graphical utility you describe, I would pick, for example, AppArmor, which supports whitelists, and, to some extent, dynamic profiling, and tried to make a GUI for it.
OpenSUSE's YaST features graphical interface for apparmor setup and 'learning' , but it is specific to the distribution.
So Linux users and administrators have several ways to control network (and files) access on per-application basis.
Why the graphical frontends for MAC are so few is another question. Probably it's because Linux desktop users tend to trust software they install from repositories and have less reasons to control them this way (if an application is freely distributed, it has less reasons to call home and packages are normally reviewed before they get to repositories) while administrators and power users are fine with command line.
As desktop Linux gets more popular and people install more software from AUR or PPA or even from gnome-look.org where packages and scripts are not reviewed that accurately (if at all) a demand for such type of software (user-friendly, simple to configure MAC) might grow.
To answer your 3rd point.
There is such a program which provides zenity popups, it is called Leopard Flower:
http://sourceforge.net/projects/leopardflower
Yes. Everything is possible
-
There are real antiviruses for linux, so there could be firewalls with GUI also. But as a linux user I can say that such firewall is not needed.
I reached that Question as i am currently trying to migrate from a Mac to Linux. There are a lot of applications I run on my Mac and on my Linux PC. Some of them I trust fully. But others I am not fully trusting. If they are installed from a source that checks them or not, do i have to trust them because someone else did? No, I am old enough to choose myself.
In times where privacy is getting more and more complicate to achieve, and Distributions exist that show that we should not trust everyone, I like to be in control of what my applications do. This control might not end at the connection to the network/Internet but it is what this question (and mine is about.
I have used LittleSnitch for MacOSX in the past years and I was surprised how often an application likes to access the internet without me even noticing. To check for updates, to call home, ...
Now where i would like to switch to Linux, I tried to find the same thing as I want to be in control of what leaves my PC.
During my research I found a lot of questions about that topic. This one, in my opinion, best describes what it is about. The question for me is the same. I want to know when an application tries to send or receive information over the network/internet.
Solutions like SELinux and AppAmor might be able to allow or deny such connections. Configuring them means a lot of manual configuration and does not inform when a new application tries to connect somewhere. You have to know which application you want to deny access to the network.
The existence of Douane (How to control internet access for each program? and DouaneApp.com) show that there is a need for an easy solution. There is even a Distribution which seems to have such a feature included. But i am not sure what Subgraph OS (subgraph.com) is using, but they state something like this on there website. It reads exactly like the initial question: "The Subgraph OS application firewall allows a user to control which applications can initiate outgoing connections. When an unknown application attempts to make an outgoing connection, the user will be prompted to allow or deny the connection on a temporary or permanent basis. This helps prevent malicious applications from phoning home."
As it seems to me, there are only two options at the moment. One is to Compiling Douane manually mysqlf or two, switch distribution to Subgraph OS. As one of the answers state, everything is possible - So i am surprised there is no other solution. Or is there?
A linux machine freezes few hours after booting and running software (including custom drivers). I'm looking a method to debug such problem. Recently, there has been significant progress in Linux Kernel debugging techniques, hasn't it?
I kindly ask to share some experience on the topic.
If you can reproduce the problem inside a VM, there is indeed a fairly new (AFAIK) technique which might be useful: debugging the virtual machine from the host machine it runs on.
See for example this:
Debugging Linux Kernel in VMWare with Windows host
VMware Workstation 7 also enables a powerful technique that lets you record system execution deterministically and then replay it as desired, even backwards. So as soon as the system crashes you can go backwards and see what was happening then (and even try changing something and see if it still crashes). IIRC I read somewhere you can't do this and debug the kernel using VMware/gdb at the same time.
Obviously, you need a VMM for this. I don't know what VMM's other than VMware's VMM family support this, and I don't know if any free VMware versions support this. Likely not; one can't really expect a commercial company to give away everything for free. The trial version is 30 days.
If your custom drivers are for hardware inside the machine, then I suppose this probably won't work.
SystemTap seems to be to Linux what Dtrace is to Solaris .. however I find it rather hostile to use. Still, you may want to give it a try. NB: compile the kernel with debug info and spend some time with the kernel instrumentation hooks.
This is why so many are still using printk() after empirically narrowing a bug down to a specific module.
I'm not recommending it, just pointing out that it exists. I may not be smart enough to appreciate some underlying beauty .. I just write drivers for odd devices.
There are many and varied techniques depending on the sort of problems you want to debug. In your case the first question is "is the system really frozen?". You can enable the magic sysrq key and examine the system state at freeze and go from there.
Probably the most directly powerful method is to enable the kernel debugger and connect to it via a serial cable.
One option is to use Kprobes. A quick search on google will show you all the information you need. It isn't particularly hard to use. Kprobes was created by IBM I believe as a solution for kernel debugging. It is essentially a elaborate form of printk() however it allows you to handle any "breakpoints" you insert using handlers. It may be what you are looking for. All you need to do is write and 'insmod' a module into the kernel which will handle any "breakpoints" hit that you specify in the module.
Hope that can be a useful option...
How I debug this kind of bug, was to run my OS inside the VirtualBox, and compile the kernel with kgdb builtin. Then I setup a serial console on the VirtualBox so that I can gdb to the kernel inside the VirtualBox's OS via the serial console. Anytime the OS hang, just like magic sysrq key, I can enter ctrl-c on the gdb to stop and understand the kernel at that point in time.
Normally kernel stack tracing is just too difficult to pinpoint the culprit process, so the best way I think is still generic "top" command, just looking at the application logs to see what are the cause of hanging - this will need a reboot to see the log of course.