I am reading docs for VLC Command line programming. there I saw
YUV video output
--yuv-file=<string> device, fifo or filename
device, fifo or filename to write yuv frames too.
What does device and fifo mean? how to specify them?
A FIFO pipe is a "first in first out" pipe handled by the file system. It is also called a named pipe
Essentially, the file system as a record on it that points to a section of RAM that is used to transfer data through between different processes as if it was an actual disk file it was reading and writing from. Of course, there are different behaviours between normal files and pipes, but that's the general idea.
The FIFO, or "first in, first out" is a queue term, which means the first data written to the pipe is the first data read out.
Now, device is a 'device' in your machine that can be specified to write data to or read data from. This can be something like a network device or a capture/display device (such as VIVO video cards). On *nix systems, a device is something you will find in /dev such as /dev/dvd for a DVD device.
It's a named pipe.
Try man mkfifo
Related
I'm trying to build a solution where dumpcap saves to text file in the format:
timestamp_as_detailed_as_possible, HEX-raw-packet
My goal is to have this continuously streaming each single data packet to the file, separated by newline.
2 questions?:
Is it possible for dumpcap to take care of fragmented packets, so I'm guaranteed each line contains 1 single full packet?
Is it OK to have another thread afterwards running and reading lines from the same file, do something with the data and then delete the line when processed - without this interfering with dumpcap?
Is it OK to have another thread afterwards running and reading lines from the same file, do something with the data and then delete the line when processed - without this interfering with dumpcap?
No. But this is the wrong approach. A pipe is actually what you should use here, i.e. dumpcap writing to a pipe and the analyzing process reading from it, i.e.
dumpcap -w - | analyzer
Is it possible for dumpcap to take care of fragmented packets, so I'm guaranteed each line contains 1 single full packet?
No, and it is also unclear here what exactly you expect. Usually there is no fragmentation done at the IP level and all since TCP tries to adjust the packet size to not be larger than the MTU anyway. And TCP should be treated as a byte stream only, i.e. don't expect anything you send to end up in a single packet or that multiple send will actually result in multiple packets.
I'm trying to build a solution where dumpcap saves to text file
Dumpcap doesn't save to text files, it saves to binary pcap or pcapng files.
You might want to consider using tcpdump instead, although you'd have to pipe it to a separate program/script to massage its output into the format you want.
Does read() system call causes the kernel device driver code to be executed?
I mean, when I want to read files from disk or from any driver, I use read() system call. Is that system call must use driver code to complete this task?
Thanks.
Yes, the read() uses standard file descriptors to read files from fixed offsets in files and of fixed bytes. The standard file descriptors are not files on the disc, but rather associated with a different device, the terminal device. Hence the drivers must be in use for the files to be accessed.
See man read for its usage and C prototype.
For more info about file handling use this link, particularly the "Reviewing Open Files" section for your particular query.
I am interested in opening a capture file in wireshark and then exporting the data in "C arrays" format [Wireshark provides that option in its GUI. One can do it by following "File->Export->as C arrays file" from the main menu.My question is how can I do this in perl? Can someone help me with a script for this?
I Would like to parse each and every packet of the wireshark capture. So I thought, I will first convert each packet to an array and then parse it. Do you have any suggestions on this? My capture consists of all IEEE 802.11 frames.
If you want to do all the parsing yourself, i.e. look at the raw packet data, I would suggest writing your own program using libpcap to read pcap-format capture files (on UN*X, libpcap 1.1.0 and later can also read pcap-ng-format capture files, which is what Wireshark 1.8.0 and later write by default). No need to write stuff out as C arrays.
I read some unix manual (http://pubs.opengroup.org/onlinepubs/009695399/functions/posix_spawn.html), and there was a mention about execution.
The new process image shall be constructed from a regular executable
file called the new process image file.
The expression process image caught my eyes.
I have been thought executable file is just a kind of sequence of command. Just as the word program means. But actually, I don't know the concept and structure of the executable file. And I felt executable file could be looks like an execution state image from the mention.
Could you explain me something about this? About the concept and structure of regular executable files in nowadays. In any OS.
Usually the executable file does not contain only instructions but also global data, readonly data and many more. I suggest you briefly look e.g. on the ELF format widely used in UNIX-like operating systems or PE format used in Windows.
The OS may also need for example to replace some addresses of functions (jump targets) with the real addresses of these functions in the memory, although this technique is probably not used anymore in common OSes. Anyway, there can be more work to do than just copy the file into memory and start executing from the first byte.
Does
pcap_t *pcap_open_offline(const char *fname, char *errbuf)
from libpcap read the whole pcap file into memory? If not so, I have to use tcpslice or similar tools to split pcap file up?
Thanks.
A strange way of wording your question, but I'll try and answer what I can.
pcap_open_offline() takes a .dump file (or similarly named output from tcpdump, tcpslice, or libpcap's pcap_dump_open() + pcap_dump() functions) as an input.
This file is exactly the same in format and function as a live trace of a network device, IE, you can use this pcap_t object in pcap_next, pcap_loop, etc.
Altering a dump file in any way (IE, stripping information or parsing out only what you want with tcpslice or wireshark) will render it unreadable by pcap_open_offline(), as it will not be formatted in the manner of a live packet trace.
However, it does not load the entire file at any one time into memory. It streams the file, as you would stream packets from a live trace.
To summarize: pcap_open_live() opens an unaltered tcpdump/tcpslice dump and reads it like a live stream. It does not load the entire file into its memory, as dumps can get quite large! Instead it just goes through the file only loading one packet's worth of the file at a time.