I'm using Wireshark to sniff the network and detect the VoIP calls. Detected VoIP calls can be seen from GUI (Telephony->VoIP Calls).
Now I want to get this list from command line. I searched through wireshark documents, but couldn't find a command to do that.
I'm using the commands like
tshark -r myFile -R "sip.CSeq.method eq INVITE"
from this topic :
Filtering VoIP calls with tshark
Is there a command to show that voip call list from command line, or do i have to parse the outputs and create my own list? Do you suggest any other tool to do that?
Any help would be greatly appreciated.
I don't know of any way to coax tshark to give you what the Wireshark GUI does. You can do this by post-processing the output from tshark, but it will be a fair amount of work. One approach would be to:
Have tshark to display the full details of the SIP packets (e.g., with -v)
Pipe this to a process that will extract info from each packet. This process will need to detect packet boundaries, since the input will have multiple lines per packet.
This process will need to store selected info from these packets (such as From, To, Start Time, etc.) and correlate this info across packets based on dialog identifiers.
The process will need to understand the SIP protocol well enough to determine when calls are confirmed, terminated, etc.
This is certainly doable, but I wanted you to know what you are getting into.
An alternative to a separate process (that I have no experience with) is to write a Wireshark script in Lua, and invoke that via tshark -Xlua_script:my_script.lua (using a version of tshark compiled with Lua support). An example to help you get started can be found here under the example "Dump VoIP calls into separate files" (or similarly here on Google Code). The advantages are:
You automatically have access to the parsed SIP message.
It is easy to tell where the packet begins and ends.
Everything runs in a single process.
For me, the downside is that I would have to learn a new language (not the worst thing in the world).
EDIT: Looks like the SIP dissector in wireshark/tshark can help quite a bit if you use the Lua script approach; for instance, you can inspect sip.response-request on a SIP response to find the packet number of matching request.
Related
I want to write a Forth program for my Raspberry Pi. This program shall read some sensor data from an existing file and send it to a website where the data gets stored.
Searching the web there was plenty of documentation about how easy and fast Forth is and how to calculate Fibonacci numbers. But how can I request a URL? How can I send data to a website and process the result?
If there's no socket support: is it possible to start an external program like curl/wget to do the request?
It is not obvious from the question what the Forth implementation is used.
For example, Gforth (that is available on Raspberry Pi)
has some support of the sockets and also it allows to start an external program using system word. See my answer on the similar question: How do I read raw code from a website in Gforth?
Example of creating curl child process in Gforth:
S" curl https://example.com/" system
In any case,
it seems that the most promising approach for the given problem is to develop a binding to libcurl (if it doesn't exist yet for the used Forth implementation).
I have a device (made in china) that works great but with a very annoying flaw. It's a massage device that will only work if it is connected to the internet at startup. Once it starts, it would work without the internet until it is turned off. So in short, if the internet is down, it will never work or it is impossible to bring this device on an area with no connection.
What I'm planning to do is emulate its server/client communication at start-up by using an old-PC that would run the server emulator software and some DNS re-routing and a WiFi router (using the PC as WAN).
I'll connect the device on the router, and its communication with the Chinese Server is emulated by the PC.
Can anyone give me an idea where to start, tools needed etc? I'm a programmer but new to packet emulation/replay. I've sniffed packets that the device does and its always consistent on every start/restart of the device. Here's the wireshark capture (IMG):
WireShark Packet Capture
You have two tasks, IMHO neither of them requires special tools:
Redirect requests to local address
You need to setup local DNS server and configure it to provide local IP address on hengdetech lookup. I didn't dive into this part, but google has plenty of forums discussing necessary config for different DNS servers.
Device most likely gets DNS server address from DHCP server. So you need to point device to local DNS instead of default one by configure DHCP server (which is run on your router, I suppose).
Once your DHCP configures local DNS and local DNS redirects hedgdete to local IP address, you are free to go to the second part which is
Emulate server behavior
Server must wait for some initial data from client before sending some data back. Such logic doesn't fit well into common "replay packets" tool capabilities, but it's quite easy to implement dumb TCP server with desired functionality on whatever language you like. Open socket, wait for data, send data, not a big deal, isn't it? So I wouldn't bother searching for the right tool, but would creat new instead.
If you need quick proof of concept, that you understand data flow right, before start coding, you may try netcat utility on Unix system for quick server emulation. I did the following once: extracted exchanged payload data from traces and saved as binaries (e.g. file1.bin is sent by server after the first request, file2.bin is sent after the second etc), then used something like this: cat - file1.bin - file2.bin | nc -l -p <local_port> -n. Using cat without dashes results into nc sending all files content to client, once it connects. Dash means "use data from console input rather than file" and they are used only as flow control. cat hangs on the first dash waiting for user input, so pressing ctrl+d proceeds to next file content and sends file1.bin, then hangs on the second dash. So you wait for the first request, press ctrl+d to send file1.bin content, then wait for the second request, press ctrl+d to send file2.bin content and so on.
EDIT
You generally got the idea of extracting data from wireshark traces right, but I want to clarify some subtlenesses.
When you said "saved binaries", did you mean to save individually captured packets as binaries so that netcat could send them to clients as a reply one by one (with the help of dash) ? If so, how do I save captured packets as binaries? Can I just extract them from the wireshark capture files, paste it on a new file and save as binary?
Only payload part of the packet needs to be saved, not the whole packet. TCP header, IP header and so on shouldn't be extracted, only tcp data section should be saved. Check second part of this answer for howto. I suppose, TCP data in your case consists of binary data rather than plain text, so you need to copy it as "raw binary" and use some binary editor allowing to paste "raw binary" into file such as frhed. So yes, you create new file and paste data copied from wireshark into it, so file consists of exactly the same bytes as packet payload.
Another thing to mention, TCP is a stream protocol, one packet doesn't always mean one response message. If you see several TCP packets of maximum size (aka MTU, which is usually 1.5 Kbytes) without PSH flag followed by packet of lesser size with PSH flag, they all contain parts of the single response message, so their payloads should be combined into one "fileX.bin".
Is there a conventional way to write a program such that commands can be issued to the program from the command line without a repl? For example, how you can send commands to a running nginx server using sudo /etc/init.d/nginx restart (or any other valid command besides restart)
One idea I had was having the long-running program create and monitor a unix socket that other programs can write to to send it commands. Another was to create a local server with a REST interface that can be sent commands that way, though that seems a bit gross.
What's the right way to do this?
Both ways are ok, and you could even consider using some RPC machinery, such as making your application serve JSONRPC on some unix(7) socket. Or use a fifo(7). Or use D-Bus.
A common habit on Unix is to have applications reload their configuration files on e.g. SIGHUP signal, and save some persistent state (before terminating) on SIGTERM. Read signal(7) (notice that only async-signal-safe routines can be called fro signal handlers; a good way is to only set some volatile sig_atomic_t variable inside the handler and test it outside). See also POSIX signal.h documentation.
You might make your application become a specialized HTTP server (e.g. using some HTTP server library like libonion) and give it some Web interface (or REST, or SOAP ...); the user (or sysadmin) will then use his browser to interact with your application.
You could make your server systemd compatible. (I don't know exactly what that requires, it is perhaps D-bus related).
You could embed some command interpreter (like Guile and Lua) in your app and have some limited kind of REPL loop running on some IPC like a socket or a fifo. Beware of nasty code injection.
I had a similar issue where I have a plethora of services running on any number of machines and each is in need of communicating with several others.
My main problem was not so much the communication between the services. That can be done with a simple message sent over a connection (as Basile mentioned, it can be TCP, UDP, Unix sockets, FIFOs...). However, when you have over 20 services, many of which need to communicate with several other services, you start having a headache on how to get all the connections right (I have such a system, although it has a relatively limited number of services, like just 10 and that's already very complicated).
So I created a process (yet another service) called Communicator. All services connect to the Communicator service and when they need to send a message, they include the name of the service they want to reach. The Communicator service is in charge of sending the message to the right place—i.e. it could be to another Communicator service running on a different computer. Communicator has a graph of all the services available on your network and knows how to send messages to them without your service having to know anything about all of that. Computing a graph can be really complex.
For the purpose, I created the eventdispatcher project. It is in C++, which may not be what you're interested in, although you could use it in other languages that interface with C/C++. The structure of the messages are "proprietary" (specific to the Communicator), but you can create any message you want. A message includes a name and parameters (param-name=value). The first version has a simple one line text communication system. The newer version accepts JSON as well (still must be one line of text per message).
The system supports TCP, UDP, Unix sockets, FIFO, and between threads, you can have thread safe fifos. It also understand signals (like SIGHUP, SIGTERM, etc.) It has a specific connection to listen for the death of a thread. It supports encryption over TCP via OpenSSL. The messages can automatically be dispatched (hence the current name of the library). Connections are assigned a timer. And there are CUI and GUI (Qt) extensions as well.
The one main point here is that all your connections can be polled (see poll()) and thus you can implement a system that reacts to events instead of a system which sleeps and checks for events, sleeps and check, etc. or worth, you have a single blocking connection and everything has to happen on that one connection or your service gets stuck. This is one reason Unix has been using signals since early version of Unix did not have select() nor poll().
For Linux, select() works for both sockets and console input. But on windows, it only works for sockets.
This is problematic because I am looking to write a client in perl console where I can connect to a server, print and parse messages, and be informed when the user inputs commands into the console. Something like a chatroom, when I can both print messages to the console and read user input to send messages.
Is there any alternative to do this on Windows? Or am I forced to use Window Applications instead of the console?
Unfortunately not. In fact, this is one of the core problems facing porting asynchronous software onto Windows.
About the closest thing you could get is WaitForMultipleObjectsEx, which has all sorts of interesting and well-known issues with it (such as its 64 handle limit, and how it copes with than one handle being ready at once). But if you want to multiple console and network socket IO, it's about the only option on Windows.
I want to capture and save the data that's being sent to a certain process through internet .
Are there any tools for the job?
If not, does listening to the same port as the process that I'm trying to get data from, will get me the data?
Any help appreciated !
You can try Wireshark: http://www.wireshark.org/
Or RawCap: http://www.netresec.com/?page=RawCap
I don't know what is the data format you are trying to capture. I used these two tools to capture xml data from web service.
On Windows, use Winsock Packet Editor (WPE). You will be able to hook a process' all Winsock-related functions and capture (and even modify/block) any TCP/IP, UDP packets that the application receives or sends. For all other operating systems, you will have to either:
write your own tool that hooks various socket functions (e.g. send, recv, etc.)
or just use Wireshark which will capture all Layer-3 packets that goes through your network card. You will have to use your own knowledge of the application that you're trying to monitor in order to filter the packets that are specific to the application.
Are there any tools for the job?
Wireshark. But what have you tried?
If not, does listening to the same port as the process that i'm trying to get data from, will get me the data?
Not if you don't forward the traffic to the real destination, otherwise the other party will be waiting forever on a response, or simply timeout and close the connection. You should create something like a proxy.
Wireshark is easier.