I have a ton of wireshark traces containing varying amount of ISCSI packets. I need to parse out the command being sent by the initiator (in bytes) and write it to a file for each packet. I was originally going to do this manually, as it is easily viewable inside the wireshark application (see SS below), but some of these traces are huge (1-2 Gb), and it would take forever to do by hand.
I've been looking into tshark and rawshark documentation, but I'm not sure either is able to get me what I need. A friend suggested using libpcap to parse the traces myself, but from what I can tell I'd need to find some way to identify the bytes I need to pull out of each packet. Ideally I'd like to use something that recognizes it for me (ie wireshark's ISCSI dissector).
Can anyone point me in the right direction? I need some way to parse out these commands from each ISCSI packet without looking through the raw packet data and trying to identify which bytes I need. As a note - It's not always the last 16 bytes in the packet as shown above, so I can't just go through and take the last 16 bytes.
If you export the packets to PDML/XML (File->Export...->File->Save As Type PDML) you will get a nice XML file with all the protocol fields. You may be able to use this for your requirements, or use it as an index to locate the raw bytes in each packet.
Related
I have a custom wireshark dissector, but it takes a very long time to load/dissect large captures.
Is it possible to only dissect packets when they are displayed/on scroll?
No, it's not. The Wireshark core has no idea whether a given dissector constructs, for some or all packets, state needed for dissecting later packets, so it has to dissect every packet when it reads the file in.
I’m here again with a new question; this time about PLC.
I start by saying I’m new of PLC and I’ve never saw one of them until a couple of month ago.
I’m asked to write a program that read, from Delphi, some data from a PLC Siemens S7-300 in order to archive them in a SQL Server database. I’m using the “libnodave” library.
The program is quite simple. I must verify a bit and when it is on I have to read the data from the PLC and set off the bit. With the library I’ve told about I can read and write without problems, but the data I have to read are stored in a group of byte (about 60 bytes), so I’ve to read some bytes, skip some others and read others bytes. Moreover the bit I must test is in the end of this group of bytes.
So I read the entire group of bytes I put the data red in a group of variables and then I test the bit and, if it is on, I store the data into the database.
In order to skip the byte I don’t have to read I use this kind of statements:
for i := 1 to 14 do
daveGetU8(dc);
for i := 1 to 6 do
daveGetU16(dc);
My questions are these:
There is a better way to read the data skipping the ones I don’t have
to read?
Is it convenient to read the entire group of bytes and after
test the bit or is better to make two reading separated?
I say this because I’ve found in internet that the read operations requires some time, so is better to make the minimum numbers of reading possible.
Eros
Communicating with a PLC involves some overhead.
You send a request and after some time you receive an answer.
Often the communication is through a serial line with limited bandwidth.
The timing then involves:
Time to send the request
Time for the PLC to respond
Time to transfer the response
It is difficult to give a definite answer to your questions, since we don't know how critical the timing is.
Anyway, polling the flag byte only seems like reasonable way to go.
When the flag is set, read the entire block in one command and then clear the flag.
Reading the data in small parts to avoid the gaps, is probably more time consuming than reading the entire block at once.
You can make the maths yourself since you know the specifications.
Example:
Lets say the baud rate is 9600 baud. This means roughly 1 byte per millisecond transfer time. The command to read is about 10 bytes long and the block answer about 70 bytes (assuming the protocol is binary). The PLC delay time about 50 ms. This adds to 130 ms, while reading the flag only adds to about 70 ms.
Only you can say if the additional polling time of 70 ms is acceptable.
Edit: In a comment it is stated that the communication is via ethernet on a 100+ MBit/s line. In that case, I suggest to read all data in one command and process it in the PC. Timing is of little concern with such bandwidth.
I am using a wireshark. I sniffed packets with FCS using wireshark and saved into pcap file in HardDisk. At the running time it can know FCS is included or not. But my doubt is, when I open a saved pcap file using wireshark how it is knowing whether the saved file is captured with FCS or not?
How wireshark is differentiating files with FCS?
Is there any variable in pcap file to know this?
when I open a saved pcap file using wireshark how it is knowing whether the saved file is captured with FCS or not?
It doesn't know. It guesses, based on:
how long the actual packet being sent over Ethernet is (for example, IPv4 packets have a "total length" field);
how long the Ethernet packet is (it may be longer than needed for the actual packet, as Ethernet packets must be at least 64 octets long, including the Ethernet header, the Ethernet payload, and the FCS).
If the Ethernet packet looks as if it's 4 octets longer than it would be without the FCS, Wireshark assumes those 4 octets are the FCS.
How wireshark is differentiating files with FCS?
Some file formats always include the FCS, some file formats never include the FCS, and some file formats, such as pcap, might or might not include the FCS. The code that handles different capture file formats indicates that to the code in Wireshark that actually read the files.
Is there any variable in pcap file to know this?
Unfortunately, no, there isn't, which is why Wireshark has to guess.
In case of 802.11 there exists a Management packets, we can't know the exact length of Packets because there exists Information elements which are of variable length. In that case how Wireshark guess the FCS?
It doesn't.
For 802.11, just as for Ethernet, some file formats always include the FCS, some file formats never include the FCS, and some file formats, such as pcap, might or might not include the FCS. The code that handles different capture file formats indicates that to the code in Wireshark that actually read the files.
For file formats that might or might not include the FCS:
if the packets don't have a radiotap metadata header before the 802.11 header, Wireshark checks a preference that the user has to set (you can't indicate it in the file);
if the packets do have a radiotap header, and it includes a Flags field, Wireshark checks the "frame includes FCS" flag in that field.
I want to store large number of packets in a pcap file (say around 200000) and then send it using tcpreplay . The problem is the loop option in tcpreplay sends at a very low speed .
Now I am capturing packets using wireshark but wireshark does not respond after sending a lot of packets . How can i increase the length of the pcap file by multiplying the number of packets already stored in it ? How can I achieve good throughput using tcpreplay?
If you'd like to multiple a single pcap, consider the mergecap command, shipped with wireshark.
Regarding the packet pumping speed of tcpreplay take a look at its FAQs, and in particular consider the -T option to pick a timer mechanism that works well. I've found rdtsc to work very well. Also consider using a short trace that fits into memory, and iterating playback of that, to avoid disk I/O. For this, consider the -K option.
On one end, you have TCP, which guarantees that packets arrive and that they arrive in order. It's also designed for the commodity Internet, with congestion control algorithms that "play nice" in traffic. On the other end of the spectrum, you have UDP, which doesn't guarantee arrival time and order of packets, and it allows you to send large data to a receiver. Somewhere in the middle, you have reliable UDP-based programs, such as UDT, that offer customized congestion control algorithms and reliability, but with greater speed and flexibility.
However, what I'm looking for is the capability to send large chunks of data over UDP (greater than the 64k datagram size of UDP), but without a concern for reliability of each individual datagram. The idea is that the large data is broken down into datagrams of a specified size (<= 64,000 bytes), probably with some header data stuck on the front and sent over the network. On the receiving side, these datagrams are read in and stored. If a datagram doesn't arrive, all of the datagrams associated with that transfer are simply thrown out by the client.
Most of the "reliable UDP" implementations try to maintain reliability of each datagram, but I'm only interested in the whole, and if I don't get the whole, it doesn't matter - throw it all away and wait for the next. I'd have to dig deeper, but it might be possible with custom congestion control algorithms in UDT. However, are there any protocols with this approach?
You could try ENet, whilst not specifically aimed at what you're trying to do it does have the concept of 'fragmented data blocks' whereby you send data larger than its MTU and it sends as a sequence of datagrams of its MTU with header details that relate one part of the sequence to the rest. The version I'm using only supports 'reliable' fragments (that is the ENet reliability layer will kick in to resend missing fragments) but I seem to remember seeing discussion on the mailing list about unreliable fragments which would likely to exactly what you want; i.e. deliver the whole payload if it all arrives and throw away the bits if it doesn't.
See http://enet.bespin.org/
Alternatively take a look at the answers to this question: What do you use when you need reliable UDP?