Re: [Wireshark-dev] The cost of memory allocation
2016-09-21 12:14 GMT+03:00 Paul Offord <paul.off...@advance7.com>: > Thanks Graham – that’s a great point and I’ll take a look this evening > with a Release build. > Paul, if you are familiar with Linux, I may recommend you to use callgrind tool from the valgrind toolset for this purpose. Its reports can be viewed with KCachegrind and they are very informative. The only disadvantage is that is slows down execution by the factor of 8-10 since it virtualizes execution of all process'es instructions to estimate accurate number of machine cycles needed for execution and to build a good callgraph. The advantage is that report is not a statistic based on many snapshots of process state but is an accurate estimation of virtually any single function call with a perfect estimation of time taken by the function body and of time taken by all its callees. Also you can use it on a release build without any modification. -- With best regards Max Dmitrichenko ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Sequence aware dissector of TCP payload
Hi everybody! Sometime ago I wrote a dissector of TCP-based protocol, and I faced with the problem of TCP out-of-order frames. E.g.: 1) Duplicated packet 2) Out-of-order packet later followed by TCP retransmission 3) Simple reordering and so on. Most protocols seems to be tolerant to this. But if you protocol is encrypted or compressed, such event poisons the state of decoder or decompressor and most of times it is unrecoverable. Does wireshark have anything to handle this? If not is there any demand for such functionality from dissectors' authors? -- With best regards Max Dmitrichenko ___ Sent via:Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] SSL decryption breaks after retransmission
2012/2/10 Martin Wilck martin.wi...@ts.fujitsu.com Hello, I just stumbled upon the known problem SSL decryption breaks after retransmission (http://www.wireshark.org/lists/wireshark-dev/200805/msg00067.html) with wireshark 1.6.5. I wonder if a patch for this issue is available? Is anybody working on this? I have made a patch and put it into the bug tracker about half a year ago. Now I think it could be implemented better than it is, but I have not discussed it with core developers and I've made it in a way to not break anything existing. It is done in the TCP desegment layer but needs some assistance from upper layer. -- Max ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] SSL decryption breaks after retransmission
2012/2/10 Martin Wilck martin.wi...@ts.fujitsu.com On 02/10/2012 12:13 PM, Max Dmitrichenko wrote: I have made a patch and put it into the bug tracker about half a year ago. Thanks - I assume you're talking about https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5971 ? Yep! -- Max ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] SSL decryption breaks after retransmission
2012/2/10 Martin Wilck martin.wi...@ts.fujitsu.com On 02/10/2012 01:09 PM, Max Dmitrichenko wrote: Thanks - I assume you're talking about https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5971 ? Yep! I built wireshark with this patch applied, but it didn't solve my problem. I still need to tell wireshark manually to ignore the retransmitted packets in order to get proper SSL decryption of the follow-up SSL stream. It will not work out of the box. A higher level dissector has to assist this and needs a patch. Actually the problem is that TCP is not a datagram but stream protocol. A subdissector for any protocol over TCP should not ignore this fact. In general, there are following cases. 0) Any TCP based dissector should be prepared to receive a TVB containing more than one logical PDU. 1) tvb contains a full logical PDU. Nothing to be done. 2) tvb contains the first part of logical PDU. Desegmentation needed. Currently TCP-desegmentor skips retransmissions of later parts. 3) tvb contains the second (or later) part of logical PDU or the first retransmitted part. Currently this is not handled. My patch is about to solve 3). You should patch the dissector to detect this situation and request the TCP-desegmentor to do the rest job. I guess this could be solved in out of the box way. But this will break the behavior of existing dissectors - they will not receive and dissect retransmissions which could be of someone's interest. -- Max ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Custom dissector creation
2011/12/6 Andriy Beregovenko j...@jet.kiev.ua: I'm truing to create custom dissector. Data in protocol is crypted with rc4, so I use internal implementation of RC4 encription and it works fine. Of course I read [0] before writing code :) But I got strange behaivor with result displaing. At time of dump loading and dissector processing data, all data structures is filled correct(I check this using many printf :]). Wireshark can dissect every single packet a lot of times. The first time it dissects it while dump loading. Then every time you select the packet for the inspection. But you must be sure to decrypt all the packets only once - during the first pass. Keep in mind also that TCP packets can be reordered but you should decrypt the packets only in their proper order. You have to write some kind of stateful dissector with the state assosiated to every packet in the stream. It is rather hard job for the first dissector. Take a look into SSL of SSH dissectors to get the idea. At the time I was writing my own dissector the task of reordering TCP packets was unsolved in a generic case. I wrote the patch for the tcp assembler and commited it to the bug tracker. It requires some help from your (upperlevel) dissector to work but it solved the problem for me. -- Max ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Decompress Data
2011/10/7 Marcel Haas inf...@fh-worms.de: And i have the next problem. Damn wireshark kick my ass :) I have some packets witch are compress witz zlib. I want to uncompress them. I read the dev-guid about transformed data but i dont have a clue. I were testing some stuff but with no good result. Can someone help me with that ? It is simple. 1) You have to know the size of decompressed data, e.g. in buffer_size variable. 2) Alloc the buffer of needed size for it using e.g. se_alloc, e.g. you have pointer to alloced buffer called buffer_ptr. 3) Decompress you data into that buffer. 4) call child_tvb = tvb_new_child_real_data(current_tvb, buffer_ptr, buffer_size, buffer_size); 5) call add_new_data_source(pinfo, child_tvb, Decompressed Data); 6*) Optionally you can dissect child_tvb as any usual TVB. In the GUI you'll get the decompressed data into another tab called Decompressed Data or any other name you provide in step 5. -- Max ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [PATCH] RFC: Handling and reassembling TCP Out-Of-Order packets
2011/6/8 Fernandez, Rafael rafael.fernan...@citadelgroup.com: Which release may I apply this patch to? It was done for the trunk revision 37461. Try to apply it to the HEAD and if it fails, I'll renovate it. If you need, I can also try to modify some existing dissector to make use the introduced feature. Or we can discuss here how to implement this feature so any existing dissector will benefit from it but I'm not sure that this doesn't break anything. -- Max ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] [PATCH] RFC: Handling and reassembling TCP Out-Of-Order packets
Hi! I've just submitted a patch [1] to the bugzilla and wish to discuss it here. The patch was born after the discussion [2] happened about a month ago. There we came to the conclusion that everything works fine until application level PDU is fragmented and the first fragment is lost and retransmitted later. This situation is extremely painful for the protocols which use encryption, because it breaks everything. I tried to implement it without changing the current behavior for dissectors which are unaware of this feature. I guess such a core change won't go to the upcoming 1.6.0, but I would be happy to see it in the 1.7.0 or may be in 1.6.1 - you decide. [1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5971 [2] http://www.wireshark.org/lists/wireshark-dev/201105/msg00039.html -- Max ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Saving 802.11 WPA/WPA2 decrypted packets
Hi Sreenivasulu, 2011/5/11 Sreenivasulu Yellamaraju sreenivasulu.yellamar...@csr.com: If you confirm, I can think of buying it as it seems to be not a freeware. aircrack-ng toolset is actually open source. Look here: http://www.aircrack-ng.org/ But if you want to use it under Windows you need a proper hardware. Cacetech AirPCap adapters are the only currently supported and cost $200-600 per unit depending on features. Under Linux you can use almost any WiFi adapter which is supported by Linux for the frame capture. Maybe you will need an appropriate patch which can be found on the Internet. -- Max ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] TCP dissect issue when app-level message spans multiple TCP packets
2011/5/6 Jeff Morriss jeff.morriss...@gmail.com: Oh, those out-of-order packets are quite possibly the problem: see the recent discussion here on Handling TCP packets reordering. Would love to fix this problem somehow, but I'm lack of knowledge of wireshark's core :( -- Max ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Handling TCP packets reordering
Hi! I'm continue to write dissector for an encrypted protocol. Everything works fine until I receive an out-of-order TCP segment, i.e. previous was lost. Since I'm trying to decrypt it, I fail with it and break the whole decryption context. Is there any way to: 1) Detect that this packet is out of order in given conversation? 2) Ask the TCP dissector to feed this packet later again when all previous segments will be retransmitted? And as far as I understand, there can be a situation when packet is duplicated. This should be handled too. How? -- Max ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Handling TCP packets reordering
2011/5/5 Jeff Morriss jeff.morriss...@gmail.com: Sake Blok wrote: On 4 mei 2011, at 22:11, Jeff Morriss wrote: I would think desegment_tcp() should be able to handle this by not calling your dissector for an out-of-order segment: it should be able to only call your dissector once it has a completely reassembled (desegmented) PDU. Looking through the code, it's not immediately obvious to me what the problem is. One case that can cause a problem is when the first segment of a PDU is received out-of-order. Or did your recent work also handle this exception, Jeff? Yep, that's the case rev 36304 fixed. Sake and Jeff, thank you for your replies. Indeed the problem is when the first segment of multisegment PDU is received out-of-order, i.e. later than the second segment, for example. Provided that protocol is encrypted (including framing headers), I'm not able to deduct anything at the beginning of dissection. I try to decrypt this fragment, but decryption fails and more over the decryption context is spoiled after this try - all later packets are decrypted into the junk. If the first segment of PDU is received in order then all other segments seems to be assembled correctly despite of their order - I have observed such situations. Let's get back to your statement, Jeff. Suppose, we have PDU of 3 fragments which come in this order: 2, 1, 2 (dup), 3. What should I write in the dissector to handle this correctly? Or may be you can point me to the code of any existing dissector which handles this? -- Max ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Handling TCP packets reordering
2011/5/5 Jeff Morriss jeff.morriss...@gmail.com: I did stumble across a (apparently unrelated) problem in that it will fail if you see a gap while the subdissector is returning DESEGMENT_ONE_MORE_SEGMENT (as HTTP does until it gets all the headers): in that case TCP has to assume that the current message is not part of the existing multisegment_pdu--which unfortunately breaks things. Not sure what can be done about that... Such situation can be detected inside the dissector if we know position in the stream and have the tcpinfo-seq for the packet. The application protocol dissector can use this knowledge to signal down to the TCP dissector. Can we make TCP dissector to delay such marked packet and resubmit it (possibly reassembled with other fragments) to the subdissector again? -- Max ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] [PATCH] Re: Freeing memory of se_alloc'ated object
2011/5/3 ronnie sahlberg ronniesahlb...@gmail.com:
I think registering a destructor for an allocated is very useful, but
it would be very uncommon.
Most allocations never need a destructur, so it shouldnt be made
mandatory in the allocation functions.
As it is implemented now, it's not mandatory - just a branch of already
existing functions.
So instead of creating a new API for allocations with a destructor I
would suggest adding a new _add_destructor call instead.
That way you can add destructors to existing objects after they are
allocated, post allocation time.
Ok. I see you, guys, like the idea of dynamic feature management :)
Both ways have right to exist, but this one is more error prone.
Copy-pasting the code can add two destructors call to the same object.
something like :
object = se_alloc(...);
se_set_emem_destructor(object, void (*your_callback)(void
*object), void *private_data);
Then this can just add the destructor to a linked list of
struct se_destructors {
struct se_destructors *next;
void *object;
void *private_data;
void (*callback)(void *object, void *private_data);
};
Well, it was the first idea that came up when I started to implement this.
But when I looked into emem's code, I found the other way to implement
this. Generally I have no objections but one - read below.
I threw a private_data pointer in there too.
Once you have callbacks you almost always enbd up wanting to pass data
like this to it too.
While it is very common to use such private_data pointers, when talking
about callbacks, it is generally a bad design practice if the object being
destructed needs some external context.
While you've made a statement that destructor's will be rarely used among
all the Wireshark code, the feature of private_data will be rarely used among
destructors' code ;)
Anyway, the feature introduced in my patch can be reimplemented. But
may I ask the dumb question? Who decides here what is going to the trunk
and what it should like?
I'm ready to (re-)implement any design of this feature but need some
concentrated piece of absolute wisdom from local Guru :)
--
Max
___
Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
