I read an interesting article about coding for the AR Drone 2.0 from Parrot. In this code they us nodeJS to talk to the drone. Therefore the code starts out with creating a Stream to /dev/ttyO0
I am starting out to learn more about the background of linux functionalities and would like to know:
How do you initially find out that the dev/ttyO0 is being used, for example on the drone which runs on linux. It is kind of reverse engineering I think, but what tools or commands are being used therefore?
When I want to reverse engineer a system like the drone, and find out which commands are being sent, is there something like a "sniffer" to find out what commands are being sent?
I know this is not a short and easy answer, but I would be happy to learn more about that or find out, where to learn about that. But initially the question about finding the right device would be very interesting.
Thank you
I don't know the answer to the first part of your question, but I can address the second part.
Yes, the AR.Drone uses TCP and UDP for all communications between the drone and the controller app, including commands, telemetry and video. You can use a standard network sniffer, like tcpdump or Wireshark. When you connect to the drone, its default IP address is 192.168.1.1. Configure the sniffer to capture all traffic to and from that address. Here are some highlights of what you can see:
Command/"AT" comms, UDP on port 5556: This port is used to send commands to the drone. Commands are in ASCII, and look like AT*..., for example AT*REF=7,256 or AT*PCMD=7,1,-1110651699,0,0,1050253722. Section 6 of the AR.Drone Developer Guide describes most (but not all) of the commands.
Navdata, UDP on port 5554: This is binary encoded data sent from the drone containing sensor data and information about the state of the drone. It includes things like air pressure, altitude estimate, position estimate, flying mode, and GPS (if your drone is equipped with one). Since you mentioned Javascript, the file parseNavdata.js in the node-ar-drone library contains code to parse navdata.
Video, TCP on port 5555: This is realtime video from the drone in an almost-but-not-quite H264 format known as PaVE. The format is documented in section 7.3 of the Developer Guide, and most libraries for talking to AR.Drones can parse the format.
Another thing you may notice:
FTP: The official controller app uses standard FTP to send an ephemeris file to the drone that contains info that helps GPS get a faster lock.
Related
I want to create on my Linux desktop a small server listening to requests using Bluetooth. Clients (such as mobile phones or tablets) will connect to this server and exchange data back and forth.
It should be straightforward, but I'm unable to find an up-to-date tutorial for Bluez's new DBUS-based API, and Bluez documentation is basically just a huge data dump.
Any suggestions on how I should proceed? (The language used does not really matter, since there are DBUS bindings for all major languages.)
These are some useful links to get started, it's not much but it's a start.
Textual (and up-to-date) description of the DBus interfaces exposed by bluez5 : https://git.kernel.org/cgit/bluetooth/bluez.git/tree/doc
You can find example for gatt client/server in the prevous cgit at the following path : /tree/src/shared/
An overview of Bluez and it's dbus interfaces (conference given at the 2016 Open IoT Summit) : https://www.youtube.com/watch?v=tclS9arLFzk
If you need example for your dbus bindings, I suggest looking at their test files
As you said yourself, there are dbus bindings in many languages however the language does matter. For example, some old low-level C API are not advised (see for yourself the advices in the dbus tutorial on freedesktop.org)
I suggest the following steps to start (especially for LE) :
Read the adapter-api.txt (first link) description and try to build a proxy to interact the org.bluez.Adapter1 interface (when trying to build the proxy: name would be 'org.bluez' and object path '/org/bluez/hci0' as describded in adapter-api.txt). Call StartDiscovery and StopDiscovery
Once scanning is done, print your proxy introspection to find the devices discovered (you should see MAC addresses preceded by "dev_")
Build proxies to interact with the device (read the device-api.txt file description to find out what you need)
For LE, if you want to access the Services of a Device. Introspect your device proxy and you will find it'serices. Repeat the process to reach Characteristics and Descriptors.
While working on voip apps, I usually end up picking up one phone, talking to it, picking up the other phone and check if I hear myself. This even gets trickier if I'm doing apps with three way calling.
Using a softphone doesn't help.
Ideally, I want to be able to run multiple instances of some command line based sip ua wherein i can dial a number. Once the ua has dialed and the other party ha picked up, both agents exchange audio. But instead of having to hear some audio, the apps instead display some text which identifies the other end. Possibly some frequency pattern that can be converted to text. Then this text is displayed on the app.
Can something like this be done? I'm creating apps against freeswitch. Ideas how to debug voip apps are also welcome in the comments.
yes, absolutely. The easiest would be to have a separate FreeSWITCH server that is used for placing the test calls and sending/receiving your test signals.
tone_stream will generate the tones at frequencies that you need: https://freeswitch.org/confluence/display/FREESWITCH/Tone_stream
tone_detect can detect the frequencies and execute actions, or even better, generate events that you can catch over an ESL socket: https://freeswitch.org/confluence/display/FREESWITCH/mod_dptools%3A+tone_detect
The best way to generate such calls is to use a dialer script which communicates to FreeSWITCH via Event Socket. Here you can see some (working) examples that I made with Perl:
https://github.com/voxserv/rring/blob/master/lib/Rring/Caller/FreeSWITCH.pm -- this is a part of a test suite tat I build for testing a provider's SIP infrastructure. As you can see, it connects to FreeSWITCH, starts event listener, and then originates the call and also expects an inbound call. It then sends and analyzes DTMF.
https://github.com/voxserv/freeswitch-helper-scripts/tree/master/esl -- these are special-purpose dialers, you can also use them as examples.
https://github.com/voxserv/freeswitch-perf-dialer -- this one generates a series of calls, like SIPp does.
Another technique is to play a sample audio file and record the audio being received on the other end[call recording] and then comparing the two. This system works on setup where systems are located at various places and you are testing end to end quality.
There are lot of Audio Comparison tools [like PESQ] should help you not just detect the presence of Audio but also give stats about the degradation of various parameters in the audio stream.
This can be extended to do test analysis of FS patches as and when they are released and also for other hooks or quality standards you want to enforce.
I'm trying to reverse the protocol used by an early nineties logic analyzer an its PC software.
The device is connected via RS-232 (propietary wiring) and communicates with a DOS program, successfully running on DOSBOX.
I'm able to control the device with the original software but it would be useful to autimathe the downloading of data from the analyzer using a custom program but to do so I need to know what is going on the serial port.
Ineed to know what mode is the serial port set, while I know for sure the datarate is either 1200 or 9600 bps (configurable on the device) I don't know the flow control (I guess it is RTS/CTS).
I also need to tap into the conversation between the prgram and the device without disturbing their communication.
Reading the serial port with another program (cutecom/minicom) prevents the emulator from receiving the data from the hardware.
So, summing up, what I need to know is:
What configuration is set on /dev/ttyS0 (via IOCTL calls, i think)
What goes on between program and device.
I was thinking in programming a library which acts as a proxy for the standard c library (via LD_PRELOAD) but there must be an easier way to do this.
You can use slsnif (Serial Line SNIFfer).
http://linux.die.net/man/1/slsnif
Here's a link to the sourceforge project so you can download it. I don't believe it comes with any modern distributions but I could be wrong so check your distro's software repository first.
http://sourceforge.net/projects/slsnif/
I use ttyrpld for tty sniffing. I ported it to PPC and run it on 2.6.32. It logs all of the tty traffic on the board to files, one per tty. Works well.
I'm looking to write my own multiplayer game server (most likely in nodejs) and I was wondering what protocol I should be using to transfer data? Are Datagrams the norm to send information (i realize they don't confirm delivery like HTTP, that can written on top of the protocol)? Any suggestions of performant proven systems would be a real help.
I guess I'm looking for successful techniques in handling the data transfer quickly and effectively (maintaining state on the server and scaling are a separate issue that I have a solid understanding of).
I'm looking to initially support desktop/mobile games (MacOS, iOS, and Android).
For all your protocol needs take a look at socketIO.
Basically your best solution is to rely on websockets which are TCP sockets. socketIO is just a nice cross-browser compliant abstraction.
Either you use standard long pulling techniques or html5 websockets. There is no access to UDP for browser <-> server.
There is a technology that is called RTMFP that Adobe introduced in the latest version of Flash (Flash 10). It allows you to do P2P connection and transfer data directly from a client to an other client without passing by the server. On top of that, it's using UDP to transfer data. I believe that this was originally designed to do video and audio streaming, but you can use it to pass data around.
However the main downside on this technology is the mobile since most of them don't support Flash. In this case you can use Socket.IO and use the server as a router of information as a fallback.
If you want to build your application in Javascript, you can still use it by bridging the functionnality to Javascript. If you want to take a look at a simple version of a bridge, you can take a look at this github project (I am the author).
As a C++ developer of Massive Multiplayer games for 10 years, I can tell you that most of your more advanced games, such as ones in which I was involved (Legends Of Kesmai, Magic: The Gathering Online, Airwarrior II, AVP, NTN Triva) to name a few, TCP is used for most communication simply because you need an ACK / NACK to be sure the data was received from the client. That is not to say UDP doesn't have it's place. In Legends we wrote the the protocol code to use UDP for out of bandwidth delivery of data which wasn't imperative that it be received in proper packet order and complete. Use UDP when you want to do things like update graphic files in the background while the user is playing, etc. This type of delivery is often used for such purposes and allows your TCP packets to arrive as required by your server.
I have an application where I have about 10,000 pieces of monitoring equipment across the US that periodically dials into a bank of 32 phone lines. I have two receivers of 16 lines each that answer the call and temporarily stores a small alpha string. I then have a computer that polls the receivers and parses the string and copies it to a database.
I am looking to replace the phone lines and the receivers with a voip solution and rewrite the software to parse the data string.
Any ideas on where to get started?
Tom's suggestion about Asterisk is a good one for the overall system.
However you will still need to decode the data sent from your remote equipment from an audio signal to a data signal. That task is what the "dem" part of Modem stands for (Modulate/Demodulate). Either you do this with a canned hardware/software package (as you are currently doing with a commercial modem) or you have to emulate the modem in software yourself which will be extremely tricky to code at the very least if you attempt it yourself (heaps of standards that you have to comply with for a general modem solution, plus the solution needs to work in real time)
For the software approach could start with this page Linmodems.org (just a something I saw on google prompted by your question). Alternatively do lots of searches on google for software modems. Getting someone else's code is the best approach for this sort of code :)
Whatever you end up doing I suspect it will be rather custom.
A good place to start is probably Asterisk PBX.
I take it you don't want to replace the modems at the client sites (the easiest thing on the server side would be each clients had its own IP software stack, and used its modem to call an ISP and establish an internet connection, and then talk to your server using TCP or UDP or HTTP or whatever).
Assuming that you don't have IP capability on the client sites, Googling suggests that the relevent technology is called "Modem over IP" or "MoIP" (which Wikipedia seems to be confusing with "Mobile over IP").
VoIP consists of SIP for signalling (e.g. for call set-up and call tear-down) plus some codecs (e.g. H.323) for traffic (encoded voice) while the call is established.
I'm guessing that MoIP can keep the SIP signalling, but needs to use some different codecs.
V.150 Modem over IP White Paper looks like an introduction to the technologies. I don't know what vendors there are.
I presume you are looking to find a way to do this without mofidying the modem hardware at your remote sites. If this is the case you will have to find or write signal processing software to demodulate the encoded signal from the modem. Fortunately, signal encodings on a modem are designed to be easy to do this with.
Maybe somebody makes software modem libaries that do this sort of thing. The other parts of the problem will be emulating the handshaking on the modem so it plays nicely with the remote sites.
If you can modify the software (really just the number to dial, but it would have to include the data you want to transfer) at the 10000 sites (not likely!), you could in theory use DTMF in the "dial" string to key the data over into Asterisk. Ok, more than a bit hackey, but it would avoid having to have a software modem. Note: you'd want a checksum!! (and maybe send it multiple times) And a way to tell the caller if it was received correctly. Like I said, hackey but cute.