Re: [Wireshark-dev] needed wireshark-dev tool
On Apr 16, 2013, at 8:35 PM, 王贤刚 kendy1...@163.com wrote: see subject. What's a wireshark-dev tool? ___ 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] [GSoC] Packet Editor and Viewer
I want to start working on the LUA interpreter to achieve minimum to no reboot required to execute LUA scripts added while Wireshark is running. I have started to make a list of areas the LUA interpreter is being blocked. I wanted to know if there is anything specific I should look for while digging into the LUA interpreter. I also want to develop a better understanding of how the wslua machine is loaded while wireshark is booted. As for the Packet Editor I will start working on the Edit toolbar functionalities that need to be added to the Packet Editor. I will start by enlisting the editcap funtions and translating them to GUI based approach and start working on the UI with edit functions. This is the proposed UI design for the Packet Editor. Please let me know your thoughts https://docs.google.com/file/d/0BzQfAxVhGpq9S2RKWGxudExnQjQ/edit?usp=sharing On Tue, Apr 16, 2013 at 2:30 AM, Edwin Abraham edwin.abraha...@gmail.comwrote: Sorry for the mess in the previous mail. Here is the link to the GUI jpeg packet-editor-UI.jpghttps://docs.google.com/file/d/0BzQfAxVhGpq9S2RKWGxudExnQjQ/edit?ups=drive_web On Tue, Apr 16, 2013 at 2:27 AM, Edwin Abraham edwin.abraha...@gmail.comwrote: I agree on the confusion. The initial thought when I saw the project details on the Wireshark GSoC page was that a platform to design dissectors based on existing data. Then I extrapolated from that Idea to the Packet Editor. About the LUA code to run without restarting. We need to call init.lua again to re-load the scripts. But that may interfere with the existing lua based wireshark components. If we kill all captures and freeze the gui into a refresh, during the re-loading of the scripts, that should help. I am not quite sure of this. It may be better to reload the wslua machine itself. My thought about the Packet Editor environment was to have a UI that can be used for multiple functions. Packet editing, Creating Filter/Dissectors, Tools making listener. The main function would be to extend the editcap capabilities to the GUI. After filtering out and selecting the required packets, they are opened in the Packet Editor UI. The packets can be a capture file or a capturing device but the filter has to narrow down the packet editing. The UI will have three sets of toolbar and options (editcap,dissector,listener) to manipulate the packet. There will also exist a viewing tools to change how the selection of packets are percieved. Like data can be represented as HEX/BIN/ASCII with help of toggle switches. Then an edit tracker that highlights the edits to the packet can be enabled with a full range of customizable colours for each type of edit. The view will also have single packet view and multiple view. Each of the single packet will have ability to switch the selected data between HEX/BIN/ASCII/DEC. Whereas the Multiple Packet View will have a default data representation of HEX so that the view is compact. The Packet Editor part of the UI can have UI buttons for each of the editcap functionalities like changing the timestamp, simple shifts to the data, etc. Once the settings is applied for one packet it can be applied to all the remaining packets in the packet editor UI. With simple highlighting each of the changes can be seen so that when an edit is applied for the entire selection of packets the progress can be seen. When saving if we give option to store extra info about how the edit history looks like. While using Packet Editor the Dissector/Listener toolbar should be disabled when using the editcap based toolkit. This will avoid unnecessary bugs. The Dissector/Listener will use the LUA interpreter to create custom dissectors and listeners. The GUI will give more accessible methods to select and create the protocol-fields and specify the details of each of them. As the success of the simple Dissectors are tested we can even give the filters access to use the UI to make the filters and save them. Listener functionalities I will need to look a little more into them. Below is a rough idea of how the UI can look like. The difference between single view and multi-view is that it will have the grid-structure with collapsible protocol headers in a column view. Each data element can be given a option to be viewed as a different data type than the rest in a pop-up and then resize the grid to accommodate the change. Since the custom dissectors will take time to implement the dissector. It will be better to include a temp mode where the dissector can be applied to the packet in the gui not in the packet before actually creating the dissector. Though I am saying editcap when referring to the editor. I mean to use the functionalities. And then link the editcap to the gui later on. On Sun, Apr 14, 2013 at 10:15 PM, Guy Harris g...@alum.mit.edu wrote: On Apr 14, 2013, at 12:45 AM, Edwin Abraham edwin.abraha...@gmail.com wrote: Last Summer as a part of
[Wireshark-dev] Export higer level PDUs, Unbundled PDUs decrypted PDUs etc
Hi, I think these topics in various forms has been cropping up lately, would it be possible/useful to have a generic feature to Export to a new file From a dissector using a tap writing a to a generic DLT with a pseudo header containing pseudo data such as extracts from lover layers like IP port or whatever can be useful and an Indication what the next level protocol is. As an example if I have decrypted and reassembled SIP traffic it could be useful to be able to export that to a new file Just containing the SIP traffic and the IP port combination used. The header would then Indicate the protocol as SIP and the meta data would be of type TLV and added to as Needs arises. Just a rough idea... Regards Anders ___ 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] Need help for getting started
Hi all, I am new to open source projects. I would like to contribute to wireshark. I have setup my development environment for wireshark on my machine. Please suggest me some initial bugs so that I get introduced with the codebase. Please suggest areas where I can contribute. I will be happy to be part of wireshark-dev team. Thanks and Regards Subhash Kumar Singh IRC - subh ___ 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] Arbitrary capture sources
HI, I am studying at Department of Computer Science and engineering, University of Moratuwa, Sri Lanka. I am interested in network and system work. I am using wire shark frequently for my ccna studies. Also I am good with c programming. I read your idea page for GSOC and i was interested in Arbitrary capture sources project as it will be important for many. I am not very good with python or ruby but i am sure i can master it quickly. I am confident with little guidance and smart work i can complete this and contribute to wireshark community. i went through the dumpcap code and i feel that i can play with it. I get the idea but the work flow is n't very clear to me. it will be a great help if you can point me to the correct track. Can you please clear me these details 1. do i need to rewrite dumpcap or create a new lib 2. To have external sources we need to have a API do you have a API like that 3. insight on Control message 4. any assistance on how to start thank you in advance -- Regards, Indula ___ 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] GSOC ideas: protocol buffers dissector and Fileshark
Hello, I'm a Polish student and I want to implement something useful for Wireshark during Google Summer of Code. One of the ideas is already listed on your ideas page, the other is not (but, I have no idea, why it's not already implemented). First idea: implement Google's Protocol Buffers dissector. There are some protobuf dissectors floating around, but they are usually lacking most of features that common developer would need: - being shipped with Wireshark (it's easy, but it also needs the code to be license, code style etc compliant) - make it possible and easy to call it from other dissectors - I think most of Protocol Buffers usage (most protocols that use it) is encapsulated in other packets, with headers containing packet type and so on - easy way to provide packet structure; optionally, in various formats (generated C or plain text protobuf message structures) - other dissectors also have to easily provide Message structures to protobuf dissector - good handling of unknown fields - a way to provide info beyond protobuf Message struct, like bitfields descriptions, or a possibility to call another dissector for raw bytes embedded within protobuf message Second idea: Fileshark I've been thinking of such project a long before GSoC was announced. I really miss such tool and I really would like to see it. So, I would be glad do it by myself during summer. I think, the main concern with this project is to use as much common code as possible and maintain UI consistency with Wireshark. I think it would be reasonable to make it possible to use the same dissectors as for Wireshark Please, rate those ideas and my chances of being accepted for GSoC with these two. Thanks, okordy ___ 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] Need help for getting started
On 04/18/13 06:24, Subh. Singh wrote: Hi all, I am new to open source projects. I would like to contribute to wireshark. I have setup my development environment for wireshark on my machine. Please suggest me some initial bugs so that I get introduced with the codebase. Please suggest areas where I can contribute. I will be happy to be part of wireshark-dev team. Probably the best place to look for work would be to go through the open bug reports (there are plenty!), find something which interests you and/or is in your area of knowledge, and start working. The WishList[1] and the GSoC[2] lists are other places but those are more project-sized efforts. [1] http://wiki.wireshark.org/WishList [2] http://wiki.wireshark.org/GSoC2013 ___ 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] GSOC ideas: protocol buffers dissector and Fileshark
On Apr 18, 2013, at 8:34 AM, okordy oko...@o2.pl wrote: Second idea: Fileshark I've been thinking of such project a long before GSoC was announced. I really miss such tool and I really would like to see it. So, I would be glad do it by myself during summer. I think, the main concern with this project is to use as much common code as possible and maintain UI consistency with Wireshark. ...except in those places where the UI *should* be different. For example, when showing a JPEG, Wireshark doesn't have multiple items in the packet list pane, because the JPEG is in, for example, a single HTTP message. However, in Fileshark, the dissector might want to have separate items in the list pane for different parts of the JPEG file. I think it would be reasonable to make it possible to use the same dissectors as for Wireshark Yes, that's a lot of the point of Fileshark. ___ 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] GSOC ideas: protocol buffers dissector andFileshark
Dnia 18 kwietnia 2013 17:56 Guy Harris g...@alum.mit.edu napisał(a): ...except in those places where the UI *should* be different. For example, when showing a JPEG, Wireshark doesn't have multiple items in the packet list pane, because the JPEG is in, for example, a single HTTP message. However, in Fileshark, the dissector might want to have separate items in the list pane for different parts of the JPEG file. Of course, yes. But some components doesn't need to be reimplemented (for example, hex browser). I think it would be reasonable to make it possible to use the same dissectors as for Wireshark Yes, that's a lot of the point of Fileshark. I just wanted to emphasize this. ___ 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] Export higer level PDUs, Unbundled PDUs decrypted PDUs etc
Hi Anders, Do you mean ability to export only the payload protocol from tunneled/encapsulated captures like GTP-U etc? If yes, +1 :) Have been looking for such functionality for some time. Regards, Vineeth On Thu, Apr 18, 2013 at 2:23 PM, Anders Broman anders.bro...@ericsson.comwrote: Hi, I think these topics in various forms has been cropping up lately, would it be possible/useful to have a generic feature to “Export” to a new file* *** From a dissector using a tap writing a to a generic DLT with a pseudo header containing pseudo data such as extracts from lover layers like IP port or whatever can be useful and an Indication what the next level protocol is. As an example if I have decrypted and reassembled SIP traffic it could be useful to be able to export that to a new file Just containing the SIP traffic and the IP port combination used. The header would then Indicate the protocol as SIP and the meta data would be of type TLV and added to as Needs arises. Just a rough idea… ** ** Regards Anders ___ 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 ___ 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] Filebacked-tvbuffs : GSoC'13
On 04/15/13 10:01, Ambarisha B wrote: Hi dev, I am a final year engineering student pursuing my bachelors in Computer Science. I was going through the GSoC'13 ideas page and found Filebacked-tvbuffs interesting, so I looked it up. Here's a (probably not so) short summary of what I did and understood. I'm only a novice, so if I've got something wrong, please, enlighten me. I went through the (interesting) archived conversation linked on the ideas page. I've realized most of the discussion was about how to deal with large captures, so that users don't have to break up the captures. Swapping or if needed mmaped files would help. But since the goal of this project is to cut down the memory usage, I guess we're looking at non-mmaped files. The project description says that data in packet-bytes view and packet-details view is duplicate of that on the disk. I tried to look this up in the code. So, originally the data is in a capture_file and wtap_*() gets the data out of that and it is finally handed to dissect_packet() which actually makes the tvbuff out of it and passes to the sub-dissectors(dissect_frame etc). Yes. But the stuff in the packet-details view isn't what I consider to be the problem (normally): that stuff is only kept in memory as long as it's on your screen. The real problem (which I thought file-backed-tvbuffs might solve) would be when dissectors have to make copies of tvbuffs in order to do, for example, reassembly. Those copies are malloc()'d and it is believed that, in some situations, they account for a lot of Wireshark's memory usage. (A good side project would be to add some tracking to Wireshark's memory allocations so we could be sure how much of a problem this is. For example, a while ago someone pointed out that actually a huge amount of memory goes to storing frame_data's.) Anyway, if reassembly could be done using composite + file-backed tvbuffs then a lot of that alloc'd memory could go away. I think I now have an idea of how I would back up tvbuff by a hard disk. We add another type of tvbuff which is backed up by a file, the same way TVBUFF_SUBSET is backed by another tvbuff. Next we think about how to back it by a file?. Ofcourse, we can implement a neat cache in the tvb layer itself, tuned for our accesses. But I have a couple of thoughts on this. Do tell me, if I am missing something here. If we are accessing all the data in the tvbuff in one shot, there wouldn't be much use of a cache. Infact, it'll add housekeeping overhead. On the other hand, if we're making small repeated accesses to the data, a no-cache implementation would be pitifully slow. For this I need to look at usage of tvbuffs in those two views more closely. Also, now that there's this abstraction, the interface for accessing filebacked-tvbuff has to be a little different than normal tvbuffs (because the data access might require some housekeeping as opposed to the direct access of tvb-real_data+offset). I suspect there would have to be *some* amount of caching: for example we really wouldn't want to go off and read one byte off of the disk each time someone calls tvb_get_guint8(). I would expect that normally a tvbuff will have a lot of accesses in a very short period of time, then no accesses for quite a while, then another burst of accesses (corresponding to the frame or PDU in question being dissected when the file is read and then not accessed again until the user clicks or scrolls past the frame in question). I thought I should talk to you guys first, because I could be going on a wild-goose-chase with this. If there's something you want me to take a look at or study, please do let me know. Also, if you can point me to a little bug, so that I can get my hands dirty, that'll be great. I doubt there's much in the way of a bug to look at; I think to get your hands dirty you'd have to start digging into how, for example, the tvbuffs and reassembly work and see if it can be put together. ___ 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] Filebacked-tvbuffs : GSoC'13
Jeff Morriss skrev 2013-04-18 17:55: On 04/15/13 10:01, Ambarisha B wrote: Hi dev, I am a final year engineering student pursuing my bachelors in Computer Science. I was going through the GSoC'13 ideas page and found Filebacked-tvbuffs interesting, so I looked it up. Here's a (probably not so) short summary of what I did and understood. I'm only a novice, so if I've got something wrong, please, enlighten me. I went through the (interesting) archived conversation linked on the ideas page. I've realized most of the discussion was about how to deal with large captures, so that users don't have to break up the captures. Swapping or if needed mmaped files would help. But since the goal of this project is to cut down the memory usage, I guess we're looking at non-mmaped files. The project description says that data in packet-bytes view and packet-details view is duplicate of that on the disk. I tried to look this up in the code. So, originally the data is in a capture_file and wtap_*() gets the data out of that and it is finally handed to dissect_packet() which actually makes the tvbuff out of it and passes to the sub-dissectors(dissect_frame etc). Yes. But the stuff in the packet-details view isn't what I consider to be the problem (normally): that stuff is only kept in memory as long as it's on your screen. The real problem (which I thought file-backed-tvbuffs might solve) would be when dissectors have to make copies of tvbuffs in order to do, for example, reassembly. Those copies are malloc()'d and it is believed that, in some situations, they account for a lot of Wireshark's memory usage. Yes file backed tvbs might not have been such a great idea as Jeff points out the problem to be solved is probably the reassembled packets memory usage one also has to make sure that the tradeoff in speed isn't a problem (if any). Writing a new file on Wiresharks first pass with the reassembled data attached which will be read for any subsequent access might be the answer. (A good side project would be to add some tracking to Wireshark's memory allocations so we could be sure how much of a problem this is. For example, a while ago someone pointed out that actually a huge amount of memory goes to storing frame_data's.) I thought about this too, would it be possible to invent a hash table registry function which then could be used to enquire the hash table sizes and display it in the GUI? Anyway, if reassembly could be done using composite + file-backed tvbuffs then a lot of that alloc'd memory could go away. I think I now have an idea of how I would back up tvbuff by a hard disk. We add another type of tvbuff which is backed up by a file, the same way TVBUFF_SUBSET is backed by another tvbuff. Next we think about how to back it by a file?. Ofcourse, we can implement a neat cache in the tvb layer itself, tuned for our accesses. But I have a couple of thoughts on this. Do tell me, if I am missing something here. If we are accessing all the data in the tvbuff in one shot, there wouldn't be much use of a cache. Infact, it'll add housekeeping overhead. On the other hand, if we're making small repeated accesses to the data, a no-cache implementation would be pitifully slow. For this I need to look at usage of tvbuffs in those two views more closely. Also, now that there's this abstraction, the interface for accessing filebacked-tvbuff has to be a little different than normal tvbuffs (because the data access might require some housekeeping as opposed to the direct access of tvb-real_data+offset). I suspect there would have to be *some* amount of caching: for example we really wouldn't want to go off and read one byte off of the disk each time someone calls tvb_get_guint8(). I would expect that normally a tvbuff will have a lot of accesses in a very short period of time, then no accesses for quite a while, then another burst of accesses (corresponding to the frame or PDU in question being dissected when the file is read and then not accessed again until the user clicks or scrolls past the frame in question). I thought I should talk to you guys first, because I could be going on a wild-goose-chase with this. If there's something you want me to take a look at or study, please do let me know. Also, if you can point me to a little bug, so that I can get my hands dirty, that'll be great. I doubt there's much in the way of a bug to look at; I think to get your hands dirty you'd have to start digging into how, for example, the tvbuffs and reassembly work and see if it can be put together. ___ 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] Export higer level PDUs, Unbundled PDUs decrypted PDUs etc
vineeth vijay skrev 2013-04-18 18:11: Hi Anders, Do you mean ability to export only the payload protocol from tunneled/encapsulated captures like GTP-U etc? If yes, +1 :) Yes that could be one use case. Probably every protocol using the function would have to have code supporting it. Regards Anders Have been looking for such functionality for some time. Regards, Vineeth On Thu, Apr 18, 2013 at 2:23 PM, Anders Broman anders.bro...@ericsson.com mailto:anders.bro...@ericsson.com wrote: Hi, I think these topics in various forms has been cropping up lately, would it be possible/useful to have a generic feature to Export to a new file From a dissector using a tap writing a to a generic DLT with a pseudo header containing pseudo data such as extracts from lover layers like IP port or whatever can be useful and an Indication what the next level protocol is. As an example if I have decrypted and reassembled SIP traffic it could be useful to be able to export that to a new file Just containing the SIP traffic and the IP port combination used. The header would then Indicate the protocol as SIP and the meta data would be of type TLV and added to as Needs arises. Just a rough idea... Regards Anders ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org mailto: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 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ 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 ___ 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] Filebacked-tvbuffs : GSoC'13
A few misc notes on this topic in no particular order: - Once everything is converted to wmem (after 1.10 branches) it would be trivial to write a backend allocator that collected statistics on memory usage. - Has anybody ever tried to see if Massif (http://valgrind.org/info/tools.html#massif) gives any interesting data on memory usage? That's what it's for. - Our reassembly code is a bit of a mess anyways, as Guy's recent commit indicates. It could use a general cleanup and simplification just on general principle. Cheers, Evan On Thu, Apr 18, 2013 at 12:13 PM, Anders Broman a.bro...@bredband.net wrote: Jeff Morriss skrev 2013-04-18 17:55: On 04/15/13 10:01, Ambarisha B wrote: Hi dev, I am a final year engineering student pursuing my bachelors in Computer Science. I was going through the GSoC'13 ideas page and found Filebacked-tvbuffs interesting, so I looked it up. Here's a (probably not so) short summary of what I did and understood. I'm only a novice, so if I've got something wrong, please, enlighten me. I went through the (interesting) archived conversation linked on the ideas page. I've realized most of the discussion was about how to deal with large captures, so that users don't have to break up the captures. Swapping or if needed mmaped files would help. But since the goal of this project is to cut down the memory usage, I guess we're looking at non-mmaped files. The project description says that data in packet-bytes view and packet-details view is duplicate of that on the disk. I tried to look this up in the code. So, originally the data is in a capture_file and wtap_*() gets the data out of that and it is finally handed to dissect_packet() which actually makes the tvbuff out of it and passes to the sub-dissectors(dissect_frame etc). Yes. But the stuff in the packet-details view isn't what I consider to be the problem (normally): that stuff is only kept in memory as long as it's on your screen. The real problem (which I thought file-backed-tvbuffs might solve) would be when dissectors have to make copies of tvbuffs in order to do, for example, reassembly. Those copies are malloc()'d and it is believed that, in some situations, they account for a lot of Wireshark's memory usage. Yes file backed tvbs might not have been such a great idea as Jeff points out the problem to be solved is probably the reassembled packets memory usage one also has to make sure that the tradeoff in speed isn't a problem (if any). Writing a new file on Wiresharks first pass with the reassembled data attached which will be read for any subsequent access might be the answer. (A good side project would be to add some tracking to Wireshark's memory allocations so we could be sure how much of a problem this is. For example, a while ago someone pointed out that actually a huge amount of memory goes to storing frame_data's.) I thought about this too, would it be possible to invent a hash table registry function which then could be used to enquire the hash table sizes and display it in the GUI? Anyway, if reassembly could be done using composite + file-backed tvbuffs then a lot of that alloc'd memory could go away. I think I now have an idea of how I would back up tvbuff by a hard disk. We add another type of tvbuff which is backed up by a file, the same way TVBUFF_SUBSET is backed by another tvbuff. Next we think about how to back it by a file?. Ofcourse, we can implement a neat cache in the tvb layer itself, tuned for our accesses. But I have a couple of thoughts on this. Do tell me, if I am missing something here. If we are accessing all the data in the tvbuff in one shot, there wouldn't be much use of a cache. Infact, it'll add housekeeping overhead. On the other hand, if we're making small repeated accesses to the data, a no-cache implementation would be pitifully slow. For this I need to look at usage of tvbuffs in those two views more closely. Also, now that there's this abstraction, the interface for accessing filebacked-tvbuff has to be a little different than normal tvbuffs (because the data access might require some housekeeping as opposed to the direct access of tvb-real_data+offset). I suspect there would have to be *some* amount of caching: for example we really wouldn't want to go off and read one byte off of the disk each time someone calls tvb_get_guint8(). I would expect that normally a tvbuff will have a lot of accesses in a very short period of time, then no accesses for quite a while, then another burst of accesses (corresponding to the frame or PDU in question being dissected when the file is read and then not accessed again until the user clicks or scrolls past the frame in question). I thought I should talk to you guys first, because I could be going on a wild-goose-chase with this. If there's something you want me to take a look at or study, please do let me know. Also, if you can point me to a little bug, so
Re: [Wireshark-dev] Export higer level PDUs, Unbundled PDUs decrypted PDUs etc
Yes, and this function would take arguments of original frame, offset where the interesting payload starts and length of this payload. Correct?? Regards, Vineeth On Thu, Apr 18, 2013 at 9:52 PM, Anders Broman a.bro...@bredband.netwrote: vineeth vijay skrev 2013-04-18 18:11: Hi Anders, Do you mean ability to export only the payload protocol from tunneled/encapsulated captures like GTP-U etc? If yes, +1 :) Yes that could be one use case. Probably every protocol using the function would have to have code supporting it. Regards Anders Have been looking for such functionality for some time. Regards, Vineeth On Thu, Apr 18, 2013 at 2:23 PM, Anders Broman anders.bro...@ericsson.com wrote: Hi, I think these topics in various forms has been cropping up lately, would it be possible/useful to have a generic feature to “Export” to a new file From a dissector using a tap writing a to a generic DLT with a pseudo header containing pseudo data such as extracts from lover layers like IP port or whatever can be useful and an Indication what the next level protocol is. As an example if I have decrypted and reassembled SIP traffic it could be useful to be able to export that to a new file Just containing the SIP traffic and the IP port combination used. The header would then Indicate the protocol as SIP and the meta data would be of type TLV and added to as Needs arises. Just a rough idea… Regards Anders ___ 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 ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org 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-requ...@wireshark.org?subject=unsubscribe ___ 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 ___ 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] [GSoC] Packet Editor and Viewer
On Apr 18, 2013, at 1:38 AM, Edwin Abraham edwin.abraha...@gmail.com wrote: As for the Packet Editor I will start working on the Edit toolbar functionalities that need to be added to the Packet Editor. I will start by enlisting the editcap funtions ...none of which involve editing particular fields in the packet; the *only* editcap function that modifies packet data at all is the overwrite randomly-chosen bytes with random values function, which is used for fuzz-testing. Editcap is (by design and intent) not linked with libwireshark, so it doesn't and can't even know what packet fields are. I.e., don't get confused by the edit in editcap; it doesn't do the kind of editing that the current Packet Editor code does. Some of the editing it does might *also* be useful, but that would involve editing the packet list pane, removing packets, not editing a *particular* packet. ___ 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] [GSoC] Packet Editor and Viewer
On Apr 15, 2013, at 1:57 PM, Edwin Abraham edwin.abraha...@gmail.com wrote: I agree on the confusion. The initial thought when I saw the project details on the Wireshark GSoC page was that a platform to design dissectors based on existing data. That's an interesting idea, but that's not any of the current GSoC proposals. Perhaps it should be. My thought about the Packet Editor environment was to have a UI that can be used for multiple functions. Packet editing, Creating Filter/Dissectors, Tools making listener. The main function would be to extend the editcap capabilities to the GUI. ...which means deleting entire packets (-A and -B; -d, -D, and -w; and the packet range arguments and -r), tweaking time stamps (-S and -t), removing data from all or specified packets (-C and -s). The randomly-trash-data-in-the-packet function is there for fuzz-testing, and probably doesn't need to be in Wireshark. The other functions are for splitting capture files up; that would probably be done in a function under the File menu in an Export function; it's not an interactive editing function. The only editcap functions that involve editing packet data are the ones that chop data from the beginning or end of the packet; there's nothing that resembles the current (not configured in by default) packet editor UI. After filtering out and selecting the required packets, they are opened in the Packet Editor UI. The packets can be a capture file or a capturing device A capturing device is, in effect, a capture file; if you're doing, or have done, a live capture, Wireshark has a capture file open that contains the captured packets. but the filter has to narrow down the packet editing. The UI will have three sets of toolbar and options (editcap,dissector,listener) to manipulate the packet. There will also exist a viewing tools to change how the selection of packets are percieved. Like data can be represented as HEX/BIN/ASCII with help of toggle switches. To which data are you referring? A particular field? Below is a rough idea of how the UI can look like. Static views of a UI don't always indicate very much. Could you describe a typical task that would be done with the UI, by walking through the operations that would be done with the UI elements? ___ 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] Filebacked-tvbuffs : GSoC'13
On Apr 18, 2013, at 9:28 AM, Evan Huus eapa...@gmail.com wrote: - Our reassembly code is a bit of a mess anyways, as Guy's recent commit indicates. ...and that commit doesn't include another thing I started working on (but haven't done much on yet): The reassembled hash table looks up by endpoints and an ID, but there's no guarantee that there won't be *more than one* instance of that ID in a given flow between the two endpoints in question, so that lookup needs to take into account the frame number as well. (A bunch of the stuff I've been doing to the reassembly code was to fix issues that showed up when doing some regression testing of some changes to other code; there's a DTLS file that's especially good at finding all the funny stuff in reassembly code, in part because *every fragment* has a reassembled length, and hilarity ensues if they don't have the same values.) ___ 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] Filebacked-tvbuffs : GSoC'13
On Thu, Apr 18, 2013 at 1:11 PM, Guy Harris g...@alum.mit.edu wrote: On Apr 18, 2013, at 9:28 AM, Evan Huus eapa...@gmail.com wrote: - Our reassembly code is a bit of a mess anyways, as Guy's recent commit indicates. ...and that commit doesn't include another thing I started working on (but haven't done much on yet): The reassembled hash table looks up by endpoints and an ID, but there's no guarantee that there won't be *more than one* instance of that ID in a given flow between the two endpoints in question, so that lookup needs to take into account the frame number as well. That hadn't even occurred to me; I was thinking more of the fact that we don't have a separate 'head' structure for reassembly chains and just assume certain fields are set/unset based on whether the structure is first in the list or not. (A bunch of the stuff I've been doing to the reassembly code was to fix issues that showed up when doing some regression testing of some changes to other code; there's a DTLS file that's especially good at finding all the funny stuff in reassembly code, in part because *every fragment* has a reassembled length, and hilarity ensues if they don't have the same values.) Sounds like fun :P Honestly a total from-scratch rewrite is starting to look appealing from a code-cleanliness perspective, though it would probably still be an inefficient use of time from an engineering standpoint. Evan ___ 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] Filebacked-tvbuffs : GSoC'13
On Apr 18, 2013, at 10:28 AM, Evan Huus eapa...@gmail.com wrote: That hadn't even occurred to me; I was thinking more of the fact that we don't have a separate 'head' structure for reassembly chains and just assume certain fields are set/unset based on whether the structure is first in the list or not. I noticed that as well; that's also on my TODO list to fix. ___ 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] Filebacked-tvbuffs : GSoC'13
On Thu, Apr 18, 2013 at 9:25 PM, Jeff Morriss jeff.morriss...@gmail.comwrote: The real problem (which I thought file-backed-tvbuffs might solve) would be when dissectors have to make copies of tvbuffs in order to do, for example, reassembly. Those copies are malloc()'d and it is believed that, in some situations, they account for a lot of Wireshark's memory usage. Yeah, you did suggest the idea in that context first. Guy also mentioned a couple of times that the reassembly is retained in wireshark's address space. I just used the views as a lead to get into the code first time. I doubt there's much in the way of a bug to look at; I think to get your hands dirty you'd have to start digging into how, for example, the tvbuffs and reassembly work and see if it can be put together. Indeed, I was going through the reassembly code only today. I'll also see if I can get a profile from massif as Evan suggested. Cheers Ambarish ___ 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] Export higer level PDUs, Unbundled PDUs decrypted PDUs etc
vineeth vijay skrev 2013-04-18 18:34: Yes, and this function would take arguments of original frame, offset where the interesting payload starts and length of this payload. Correct?? Regards, Vineeth Or the tvb used by the dissector e.g the reassembled one + a buffer with meta data TLV:s possibly + DLT to use. Just brainstorming at this stage :-) On Thu, Apr 18, 2013 at 9:52 PM, Anders Broman a.bro...@bredband.net mailto:a.bro...@bredband.net wrote: vineeth vijay skrev 2013-04-18 18:11: Hi Anders, Do you mean ability to export only the payload protocol from tunneled/encapsulated captures like GTP-U etc? If yes, +1 :) Yes that could be one use case. Probably every protocol using the function would have to have code supporting it. Regards Anders Have been looking for such functionality for some time. Regards, Vineeth On Thu, Apr 18, 2013 at 2:23 PM, Anders Broman anders.bro...@ericsson.com mailto:anders.bro...@ericsson.com wrote: Hi, I think these topics in various forms has been cropping up lately, would it be possible/useful to have a generic feature to Export to a new file From a dissector using a tap writing a to a generic DLT with a pseudo header containing pseudo data such as extracts from lover layers like IP port or whatever can be useful and an Indication what the next level protocol is. As an example if I have decrypted and reassembled SIP traffic it could be useful to be able to export that to a new file Just containing the SIP traffic and the IP port combination used. The header would then Indicate the protocol as SIP and the meta data would be of type TLV and added to as Needs arises. Just a rough idea... Regards Anders ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org mailto: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 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing listwireshark-dev@wireshark.org mailto: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 ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org mailto: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 mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ 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 ___ 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] Filebacked-tvbuffs : GSoC'13
Evan Huus skrev 2013-04-18 18:28: Just throwing in some more stuff :-) - It would be nice to have a reference trace to test performance against, memory usage and execution time. - As a start of performance testing one could remove the reassembled data from it's hash table and store it in per-packet-data for faster access this date could perhaps be in a file later. This might require redesigning the per-packet-data functionality to keep track of the level in the packet protocol stack as say IP might occur more than once in a packet. The protocols in frame string functionality might be redesigned for this purpose. Currently it is only built if there is a tree I think. Regards Anders A few misc notes on this topic in no particular order: - Once everything is converted to wmem (after 1.10 branches) it would be trivial to write a backend allocator that collected statistics on memory usage. - Has anybody ever tried to see if Massif (http://valgrind.org/info/tools.html#massif) gives any interesting data on memory usage? That's what it's for. - Our reassembly code is a bit of a mess anyways, as Guy's recent commit indicates. It could use a general cleanup and simplification just on general principle. Cheers, Evan On Thu, Apr 18, 2013 at 12:13 PM, Anders Broman a.bro...@bredband.net wrote: Jeff Morriss skrev 2013-04-18 17:55: On 04/15/13 10:01, Ambarisha B wrote: Hi dev, I am a final year engineering student pursuing my bachelors in Computer Science. I was going through the GSoC'13 ideas page and found Filebacked-tvbuffs interesting, so I looked it up. Here's a (probably not so) short summary of what I did and understood. I'm only a novice, so if I've got something wrong, please, enlighten me. I went through the (interesting) archived conversation linked on the ideas page. I've realized most of the discussion was about how to deal with large captures, so that users don't have to break up the captures. Swapping or if needed mmaped files would help. But since the goal of this project is to cut down the memory usage, I guess we're looking at non-mmaped files. The project description says that data in packet-bytes view and packet-details view is duplicate of that on the disk. I tried to look this up in the code. So, originally the data is in a capture_file and wtap_*() gets the data out of that and it is finally handed to dissect_packet() which actually makes the tvbuff out of it and passes to the sub-dissectors(dissect_frame etc). Yes. But the stuff in the packet-details view isn't what I consider to be the problem (normally): that stuff is only kept in memory as long as it's on your screen. The real problem (which I thought file-backed-tvbuffs might solve) would be when dissectors have to make copies of tvbuffs in order to do, for example, reassembly. Those copies are malloc()'d and it is believed that, in some situations, they account for a lot of Wireshark's memory usage. Yes file backed tvbs might not have been such a great idea as Jeff points out the problem to be solved is probably the reassembled packets memory usage one also has to make sure that the tradeoff in speed isn't a problem (if any). Writing a new file on Wiresharks first pass with the reassembled data attached which will be read for any subsequent access might be the answer. (A good side project would be to add some tracking to Wireshark's memory allocations so we could be sure how much of a problem this is. For example, a while ago someone pointed out that actually a huge amount of memory goes to storing frame_data's.) I thought about this too, would it be possible to invent a hash table registry function which then could be used to enquire the hash table sizes and display it in the GUI? Anyway, if reassembly could be done using composite + file-backed tvbuffs then a lot of that alloc'd memory could go away. I think I now have an idea of how I would back up tvbuff by a hard disk. We add another type of tvbuff which is backed up by a file, the same way TVBUFF_SUBSET is backed by another tvbuff. Next we think about how to back it by a file?. Ofcourse, we can implement a neat cache in the tvb layer itself, tuned for our accesses. But I have a couple of thoughts on this. Do tell me, if I am missing something here. If we are accessing all the data in the tvbuff in one shot, there wouldn't be much use of a cache. Infact, it'll add housekeeping overhead. On the other hand, if we're making small repeated accesses to the data, a no-cache implementation would be pitifully slow. For this I need to look at usage of tvbuffs in those two views more closely. Also, now that there's this abstraction, the interface for accessing filebacked-tvbuff has to be a little different than normal tvbuffs (because the data access might require some housekeeping as opposed to the direct access of tvb-real_data+offset). I suspect there would have to be *some* amount of caching: for example we really wouldn't want to go off and read
[Wireshark-dev] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]
This is a tangential issue that has always confused me. Why do we malloc+memcpy data for reassembly when we already have 'virtual' composite TVBs? Wouldn't it be more efficient (in time and memory) to create a composite TVB for each reassembly and then build the reassembled packet in it? You would never have to copy or allocate any actual packet data... Or am I misunderstanding how composite TVBs actually work? Thanks, Evan P.S. Clearly some protocols where the payload is XORed or hashed wouldn't be able to do this, but most protocols doing reassembly just carry the raw payload bytes. ___ 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] Need help for getting started
Hi Jeff, Thanks, I explored the both the suggested list, I found list[1]http://wiki.wireshark.org/WishList is useful for me as I am not doing GSoC. Jeff, do you have any bugs for beginner, so that I can start working. I found bug 8454 https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8454 over bug database, do you think this bug is good to start working as beginner. Thanks and Regards Subhash Kumar Singh IRC - subh On Thu, Apr 18, 2013 at 9:13 PM, Jeff Morriss jeff.morriss...@gmail.comwrote: On 04/18/13 06:24, Subh. Singh wrote: Hi all, I am new to open source projects. I would like to contribute to wireshark. I have setup my development environment for wireshark on my machine. Please suggest me some initial bugs so that I get introduced with the codebase. Please suggest areas where I can contribute. I will be happy to be part of wireshark-dev team. Probably the best place to look for work would be to go through the open bug reports (there are plenty!), find something which interests you and/or is in your area of knowledge, and start working. The WishList[1] and the GSoC[2] lists are other places but those are more project-sized efforts. [1] http://wiki.wireshark.org/**WishListhttp://wiki.wireshark.org/WishList [2] http://wiki.wireshark.org/**GSoC2013http://wiki.wireshark.org/GSoC2013 __**__** ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives: http://www.wireshark.org/**lists/wireshark-devhttp://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/**options/wireshark-devhttps://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request@**wireshark.orgwireshark-dev-requ...@wireshark.org ?subject=**unsubscribe ___ 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] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]
On 04/18/13 15:14, Evan Huus wrote: This is a tangential issue that has always confused me. Why do we malloc+memcpy data for reassembly when we already have 'virtual' composite TVBs? Wouldn't it be more efficient (in time and memory) to create a composite TVB for each reassembly and then build the reassembled packet in it? You would never have to copy or allocate any actual packet data... There are a couple of problems with doing that (that I recall): 1) Composite TVBs don't actually work (or didn't work until very recently?). 2) The data behind a TVB goes away as soon as we're done dissecting (and displaying) the packet. That is, the TVB data is overwritten (IIRC) when the next packet is read. I suppose there was never any real reason to try to make reassembly work with composite TVBs: if they're just more malloc()'d memory then why mess with it rather than allocate our own copy of the data? (Well, OK, it would save a data copy, but...) ___ 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] Enhanced PCAP-NG dissection
On 04/17/2013 4:22 PM, Guy Harris wrote: I'm not talking about saving/exporting from Wireshark (or -r and -w from I'm talking about using *editcap*, which includes no dissectors and should not include any dissectors, to do that form of transformation. Yes, sorry. I was unfamiliar with editcap (and just educated myself). I now see the problem. And I was wrong in my response anyway. My change passes the whole PCAP-NG block as if it were the packet data which is something that would cause conversions with editcap to fail miserably. And I agree with everything else you said, too (well, mostly anyway). So what if we allow wiretap readers the ability to pass on a list of buffers, each with a type. Then dissectors and writers can look through the list and use only what it is able and ignore items it doesn't understand or does not want to process. So pcapng_read() could return something like the following (using Pythonic syntax for lists and tuples): 1. [(PCAPNG_BLOCK, (SHB, header data))] 2. [(PCAPNG_BLOCK, (IDB, interface data))] 3. [(PCAPNG_BLOCK, (NRB, name options)), (NAME, (ip address, names, ...))] 4. [(PCAPNG_BLOCK, (EPB, packet options)), (FRAME, (wtap_pkthdr, packet data))] 5. [(PCAPNG_BLOCK, (EPB, packet options)), (FRAME, (wtap_pkthdr, packet data))] 6. [(PCAPNG_BLOCK, (IDB, interface data))] 7. [(PCAPNG_BLOCK, (EPB, packet options)), (FRAME, (wtap_pkthdr, packet data))] ... In libwireshark, the dissector would store comments from the first item, a section header block, but would not display it in the packet list. Item 2, an interface descriptor block, might append the interface data to a separate interface list and also not add anything to the packet list. Item 3, a name resolution block, would provide the name resolution, which could be added to the names list while also ignoring the packet list. With item 4, there is finally data to append to the packet list with the addition of metadata, in the form of PCAP-NG options, which can also be displayed. An expert dissector could be enabled to also show the PCAP-NG blocks in the packet listing, along with detailed dissection (a great tool for learning PCAP-NG or for exploring new block types and options). When the data is transformed to another format, as with editcap, unknown items can be ignored. I think my head is about to explode now. Time for lunch. Brandon ___ 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] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]
I dont think composite tvbs actually work. or at least they didnt work when we originally wrote the reassembly code. On Thu, Apr 18, 2013 at 12:14 PM, Evan Huus eapa...@gmail.com wrote: This is a tangential issue that has always confused me. Why do we malloc+memcpy data for reassembly when we already have 'virtual' composite TVBs? Wouldn't it be more efficient (in time and memory) to create a composite TVB for each reassembly and then build the reassembled packet in it? You would never have to copy or allocate any actual packet data... Or am I misunderstanding how composite TVBs actually work? Thanks, Evan P.S. Clearly some protocols where the payload is XORed or hashed wouldn't be able to do this, but most protocols doing reassembly just carry the raw payload bytes. ___ 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 ___ 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] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]
On Thu, Apr 18, 2013 at 3:56 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: On 04/18/13 15:14, Evan Huus wrote: This is a tangential issue that has always confused me. Why do we malloc+memcpy data for reassembly when we already have 'virtual' composite TVBs? Wouldn't it be more efficient (in time and memory) to create a composite TVB for each reassembly and then build the reassembled packet in it? You would never have to copy or allocate any actual packet data... There are a couple of problems with doing that (that I recall): 1) Composite TVBs don't actually work (or didn't work until very recently?). 2) The data behind a TVB goes away as soon as we're done dissecting (and displaying) the packet. That is, the TVB data is overwritten (IIRC) when the next packet is read. I suppose there was never any real reason to try to make reassembly work with composite TVBs: if they're just more malloc()'d memory then why mess with it rather than allocate our own copy of the data? (Well, OK, it would save a data copy, but...) OK, so then the optimal case would be a tvb implementation that stored only frame_data pointers, offsets and lengths... similar but not identical to the current composite implementation. The reassembly code could then add meta-data to this when reassembling, and the tvb could lazily refetch the underlying tvbs using the existing wiretap interface? If we add some sort of caching mechanism so that repeated accesses didn't keep forcing reads of the original file then I expect this would be very fast: - adding fragments to reassembly would be near-instantaneous (just a few pointer updates) - reassembled tvbs would take minimal memory except when accessed (using tvb_get_* or proto_tree_add_*) - accessing a reassembled tvb would just be an offset calculation and then a wtap read to bring into memory the underlying real packet(s) containing the data being requested (assuming they aren't already cached) Thoughts? ___ 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] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]
On 04/18/13 16:40, Evan Huus wrote: On Thu, Apr 18, 2013 at 3:56 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: On 04/18/13 15:14, Evan Huus wrote: This is a tangential issue that has always confused me. Why do we malloc+memcpy data for reassembly when we already have 'virtual' composite TVBs? Wouldn't it be more efficient (in time and memory) to create a composite TVB for each reassembly and then build the reassembled packet in it? You would never have to copy or allocate any actual packet data... There are a couple of problems with doing that (that I recall): 1) Composite TVBs don't actually work (or didn't work until very recently?). 2) The data behind a TVB goes away as soon as we're done dissecting (and displaying) the packet. That is, the TVB data is overwritten (IIRC) when the next packet is read. I suppose there was never any real reason to try to make reassembly work with composite TVBs: if they're just more malloc()'d memory then why mess with it rather than allocate our own copy of the data? (Well, OK, it would save a data copy, but...) OK, so then the optimal case would be a tvb implementation that stored only frame_data pointers, offsets and lengths... similar but not identical to the current composite implementation. The reassembly code could then add meta-data to this when reassembling, and the tvb could lazily refetch the underlying tvbs using the existing wiretap interface? If we add some sort of caching mechanism so that repeated accesses didn't keep forcing reads of the original file then I expect this would be very fast: - adding fragments to reassembly would be near-instantaneous (just a few pointer updates) - reassembled tvbs would take minimal memory except when accessed (using tvb_get_* or proto_tree_add_*) - accessing a reassembled tvb would just be an offset calculation and then a wtap read to bring into memory the underlying real packet(s) containing the data being requested (assuming they aren't already cached) Thoughts? Yep, that sounds about what I was thinking of for file-backed (+composite) TVBs. :-) Basically reassembly would only have to deal with composite TVBs (for the reassembled data). The TVB layer, using file backing for the real data, would deal with keeping (and not keeping) the data in memory when it is needed (caching). Hmmm, the way you mentioned wiretap makes me think/realize that the TVBs should not actually store the real offset (since we'd want that stuff abstracted away by wiretap so the tvbuff code wouldn't have to deal with ugliness like compressed files and so forth). That might make it a bit harder... Unless we backed the TVBs with temporary files (seems wasteful and a pain to clean up after). ___ 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] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]
Evan Huus skrev 2013-04-18 22:40: On Thu, Apr 18, 2013 at 3:56 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: On 04/18/13 15:14, Evan Huus wrote: This is a tangential issue that has always confused me. Why do we malloc+memcpy data for reassembly when we already have 'virtual' composite TVBs? Wouldn't it be more efficient (in time and memory) to create a composite TVB for each reassembly and then build the reassembled packet in it? You would never have to copy or allocate any actual packet data... There are a couple of problems with doing that (that I recall): 1) Composite TVBs don't actually work (or didn't work until very recently?). 2) The data behind a TVB goes away as soon as we're done dissecting (and displaying) the packet. That is, the TVB data is overwritten (IIRC) when the next packet is read. I suppose there was never any real reason to try to make reassembly work with composite TVBs: if they're just more malloc()'d memory then why mess with it rather than allocate our own copy of the data? (Well, OK, it would save a data copy, but...) OK, so then the optimal case would be a tvb implementation that stored only frame_data pointers, offsets and lengths... similar but not identical to the current composite implementation. The reassembly code could then add meta-data to this when reassembling, and the tvb could lazily refetch the underlying tvbs using the existing wiretap interface? If we add some sort of caching mechanism so that repeated accesses didn't keep forcing reads of the original file then I expect this would be very fast: - adding fragments to reassembly would be near-instantaneous (just a few pointer updates) - reassembled tvbs would take minimal memory except when accessed (using tvb_get_* or proto_tree_add_*) - accessing a reassembled tvb would just be an offset calculation and then a wtap read to bring into memory the underlying real packet(s) containing the data being requested (assuming they aren't already cached) Thoughts? If on top of that small enough files could be mmaped it'd be even faster. ___ 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 ___ 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] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]
On Thu, Apr 18, 2013 at 4:53 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: On 04/18/13 16:40, Evan Huus wrote: On Thu, Apr 18, 2013 at 3:56 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: On 04/18/13 15:14, Evan Huus wrote: This is a tangential issue that has always confused me. Why do we malloc+memcpy data for reassembly when we already have 'virtual' composite TVBs? Wouldn't it be more efficient (in time and memory) to create a composite TVB for each reassembly and then build the reassembled packet in it? You would never have to copy or allocate any actual packet data... There are a couple of problems with doing that (that I recall): 1) Composite TVBs don't actually work (or didn't work until very recently?). 2) The data behind a TVB goes away as soon as we're done dissecting (and displaying) the packet. That is, the TVB data is overwritten (IIRC) when the next packet is read. I suppose there was never any real reason to try to make reassembly work with composite TVBs: if they're just more malloc()'d memory then why mess with it rather than allocate our own copy of the data? (Well, OK, it would save a data copy, but...) OK, so then the optimal case would be a tvb implementation that stored only frame_data pointers, offsets and lengths... similar but not identical to the current composite implementation. The reassembly code could then add meta-data to this when reassembling, and the tvb could lazily refetch the underlying tvbs using the existing wiretap interface? If we add some sort of caching mechanism so that repeated accesses didn't keep forcing reads of the original file then I expect this would be very fast: - adding fragments to reassembly would be near-instantaneous (just a few pointer updates) - reassembled tvbs would take minimal memory except when accessed (using tvb_get_* or proto_tree_add_*) - accessing a reassembled tvb would just be an offset calculation and then a wtap read to bring into memory the underlying real packet(s) containing the data being requested (assuming they aren't already cached) Thoughts? Yep, that sounds about what I was thinking of for file-backed (+composite) TVBs. :-) Oh, OK, I misunderstood that then. Basically reassembly would only have to deal with composite TVBs (for the reassembled data). The TVB layer, using file backing for the real data, would deal with keeping (and not keeping) the data in memory when it is needed (caching). Yes. Hmmm, the way you mentioned wiretap makes me think/realize that the TVBs should not actually store the real offset (since we'd want that stuff abstracted away by wiretap so the tvbuff code wouldn't have to deal with ugliness like compressed files and so forth). That might make it a bit harder... Unless we backed the TVBs with temporary files (seems wasteful and a pain to clean up after). Not sure I follow this, as I'm not sure what you mean by 'real offset'. TVBs don't currently store any offset into the file itself. And the virtual ones I described wouldn't have to, that information is already in frame_data-file_off. ___ 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] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]
On Thu, Apr 18, 2013 at 4:59 PM, Anders Broman a.bro...@bredband.net wrote: Evan Huus skrev 2013-04-18 22:40: On Thu, Apr 18, 2013 at 3:56 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: On 04/18/13 15:14, Evan Huus wrote: This is a tangential issue that has always confused me. Why do we malloc+memcpy data for reassembly when we already have 'virtual' composite TVBs? Wouldn't it be more efficient (in time and memory) to create a composite TVB for each reassembly and then build the reassembled packet in it? You would never have to copy or allocate any actual packet data... There are a couple of problems with doing that (that I recall): 1) Composite TVBs don't actually work (or didn't work until very recently?). 2) The data behind a TVB goes away as soon as we're done dissecting (and displaying) the packet. That is, the TVB data is overwritten (IIRC) when the next packet is read. I suppose there was never any real reason to try to make reassembly work with composite TVBs: if they're just more malloc()'d memory then why mess with it rather than allocate our own copy of the data? (Well, OK, it would save a data copy, but...) OK, so then the optimal case would be a tvb implementation that stored only frame_data pointers, offsets and lengths... similar but not identical to the current composite implementation. The reassembly code could then add meta-data to this when reassembling, and the tvb could lazily refetch the underlying tvbs using the existing wiretap interface? If we add some sort of caching mechanism so that repeated accesses didn't keep forcing reads of the original file then I expect this would be very fast: - adding fragments to reassembly would be near-instantaneous (just a few pointer updates) - reassembled tvbs would take minimal memory except when accessed (using tvb_get_* or proto_tree_add_*) - accessing a reassembled tvb would just be an offset calculation and then a wtap read to bring into memory the underlying real packet(s) containing the data being requested (assuming they aren't already cached) Thoughts? If on top of that small enough files could be mmaped it'd be even faster. Yes although I think this could be done entirely separately in wiretap without touching the reassembly or tvbuff code? It would need a wiretap API change since right now we pass in a buffer to fill and the new code would need to return a buffer pointer instead, but other than that I think it would be fairly unintrusive. ___ 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] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]
On 04/18/13 17:13, Evan Huus wrote: On Thu, Apr 18, 2013 at 4:53 PM, Jeff Morriss jeff.morriss...@gmail.com wrote: Hmmm, the way you mentioned wiretap makes me think/realize that the TVBs should not actually store the real offset (since we'd want that stuff abstracted away by wiretap so the tvbuff code wouldn't have to deal with ugliness like compressed files and so forth). That might make it a bit harder... Unless we backed the TVBs with temporary files (seems wasteful and a pain to clean up after). Not sure I follow this, as I'm not sure what you mean by 'real offset'. TVBs don't currently store any offset into the file itself. And the virtual ones I described wouldn't have to, that information is already in frame_data-file_off. My original (not fully thought through) thought was probably something like: file-backed TVBs would basically have a new type (TVBUFF_FILEBACKED or something) and contain: - a pointer which can hold (malloc'd) memory for the contents of the TVB (for caching) - a file pointer (probably a bad idea) - a file offset If instead the TVB points to the frame_data which has the offset (I didn't realize it did) then there's no need for the tvbuff to have it too. ___ 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] Enhanced PCAP-NG dissection
On Apr 18, 2013, at 1:01 PM, Brandon Carpenter hashs...@pnnl.gov wrote: On 04/17/2013 4:22 PM, Guy Harris wrote: I'm not talking about saving/exporting from Wireshark (or -r and -w from I'm talking about using *editcap*, which includes no dissectors and should not include any dissectors, to do that form of transformation. Yes, sorry. I was unfamiliar with editcap (and just educated myself). I now see the problem. And I was wrong in my response anyway. My change passes the whole PCAP-NG block as if it were the packet data which is something that would cause conversions with editcap to fail miserably. And I agree with everything else you said, too (well, mostly anyway). So what if we allow wiretap readers the ability to pass on a list of buffers, each with a type. Then dissectors and writers can look through the list and use only what it is able and ignore items it doesn't understand or does not want to process. So pcapng_read() could return something like the following (using Pythonic syntax for lists and tuples): 1. [(PCAPNG_BLOCK, (SHB, header data))] 2. [(PCAPNG_BLOCK, (IDB, interface data))] 3. [(PCAPNG_BLOCK, (NRB, name options)), (NAME, (ip address, names, ...))] 4. [(PCAPNG_BLOCK, (EPB, packet options)), (FRAME, (wtap_pkthdr, packet data))] 5. [(PCAPNG_BLOCK, (EPB, packet options)), (FRAME, (wtap_pkthdr, packet data))] 6. [(PCAPNG_BLOCK, (IDB, interface data))] 7. [(PCAPNG_BLOCK, (EPB, packet options)), (FRAME, (wtap_pkthdr, packet data))] I'm assuming the tokens with characters from [A-Z_] are atoms used as tags. My idea was that what would be returned from wtap_read() would be: (block type, information) where the block types were assigned by Wiretap, e.g. section header (which would be a file header for file formats not supporting multiple sections), interface list (only 1 interface per list with pcap-ng, possibly multiple interfaces for NetMon), name resolution information, packet, etc. One block type is file-type-specific, which is the escape hatch for all blocks that don't fit into the libwiretap abstraction; the abstraction can be extended over time, but so can the set of block types in capture file formats that support multiple block types, so the abstraction always runs the risk of running behind, and some block types might be *so* specific to a particular file format that there's no point in extending the abstraction to include them. (The point of the abstraction is to cover items that are supported in more than one capture file type, so that non-file-type-specific blocks can be used when writing out a file in a different format, and so that code running atop libwiretap need only, for example, handle packets, not pcap packets and pcap-ng PBs and pcap-ng EPBs and pcap-ng SPBs and NetMon packets and DOS Sniffer packets and) The information would be block-type specific. For non-file-type-specific blocks, it would be something such as: some fixed information that must be present for all blocks of that type; a collection of optional information, with each such item tagged, with one tag being file-type-specific - the data for items with that tag starts with whatever tag the file format uses, e.g. the option code for pcap-ng. For example, a packet block would have as required items the packet length and the packet data, and everything else, including relative or absolute time stamps, captured length, and comments, as optional data. For file-type-specific blocks, they would include whatever identifier tag is used in the particular capture file format, e.g. the block type code if it's a pcap-ng file, followed by the length of the raw contents of the block, followed by the raw contents of the block (with some wrapper information removed, e.g. for pcap-ng it wouldn't include the block total length fields; that's implied by the length of the raw contents of the block, i.e. add 12 for the two length fields and the type field to the length of the raw contents). In libwireshark, the dissector would store comments from the first item, a section header block, but would not display it in the packet list. BTW, I may have changed my mind about displaying SHBs in the block list (former packet list); if you've concatenated multiple captures, it might be useful to know when a new capture begins (complete with showing the comments for the section, if any). It could conceivably, for other file formats, show whatever summary information is in the file header. Item 2, an interface descriptor block, might append the interface data to a separate interface list and also not add anything to the packet list. Those might also be useful to show in the packet list, especially if additional interfaces show up in the middle of a capture. Item 3, a name resolution block, would provide the name resolution, which could be added to the names list while also ignoring the
Re: [Wireshark-dev] [GSoC] Packet Editor and Viewer
Thanks for clearing that up about editcap. Maybe the interactiveness for the editcap CLI can be taken from this UI. Okay lets say that there are a group packets that exist in a huge capture file. And the data needs to be retrieved, stored and interpreted. So the capture is opened in Packet Editor. The filter option in the UI can help pull the packets to be defined (either the filter can be defined by the default filter or by a packet editor based filter UI ). Once the filtered packets are pulled, the UI gets populated with the grid of data that is all collapsed till the last payload which will be displayed in the requested data format (HEX/BIN/DEC/ASCII) . And the fields used to filter the packets will be highlighted. https://docs.google.com/file/d/0BzQfAxVhGpq9SXBPRnlUZ0djWHM/edit?usp=sharing After clicking on a single packet the UI is opened with the all the fields till data payload. Now edit options will be available. Now the data field is alone opened alone and is displayed withe edit options available on the top of the data grid. The data grid can be edited then and there it self just like a text editor. Bit sometimes you need to have a operation conducted on that.This UI will help select the data and name the data selection. Multiple data can be marked and used for manipulation. https://docs.google.com/file/d/0BzQfAxVhGpq9V3hnajlVUTU1aUE/edit?usp=sharing . This data can be manipulated in the required manner by defining a simple flowchart UI, (essentially a program the user define). Now the flow-chart UI is opened with fixed set of functions to define the action for the named selection. The flow-chart will have exits to account for batch edits. So once the action is defined in the flow-chart it can be ported for all the packets in the UI. The selections can be made for each field and named accordingly so that it can be properly referred to all the packets. The Flow-chart UI can have options to access to write files. https://docs.google.com/drawings/d/1WI31j15hul9YiNDab6yl6Sj4kqjOOT3_f7hlMl5wRb8/edit?usp=sharing This entire process will also include saving to packets and saving the capture. If live capture then setup listener to apply the change dynamically. Simple edits to the data like shifts, time change or edit functions based on editcap can be done without calling the FlowChart UI. But that will give a graphical programming experience to the user. Now addressing manipulating capture files. We can pull the a 2-D grid of multiple packet editing views to represent multiple capture files. Then the operations can be applied by zooming into each view separately. This will give more concise control over the Merge, Split and Export options. To clear up the idea I suggest a active chat so that you can suggest the issues with my explanations. The google drive Drawing mode can act as simple whiteboard as it supports active changes. On Thu, Apr 18, 2013 at 10:30 PM, Guy Harris g...@alum.mit.edu wrote: On Apr 15, 2013, at 1:57 PM, Edwin Abraham edwin.abraha...@gmail.com wrote: I agree on the confusion. The initial thought when I saw the project details on the Wireshark GSoC page was that a platform to design dissectors based on existing data. That's an interesting idea, but that's not any of the current GSoC proposals. Perhaps it should be. My thought about the Packet Editor environment was to have a UI that can be used for multiple functions. Packet editing, Creating Filter/Dissectors, Tools making listener. The main function would be to extend the editcap capabilities to the GUI. ...which means deleting entire packets (-A and -B; -d, -D, and -w; and the packet range arguments and -r), tweaking time stamps (-S and -t), removing data from all or specified packets (-C and -s). The randomly-trash-data-in-the-packet function is there for fuzz-testing, and probably doesn't need to be in Wireshark. The other functions are for splitting capture files up; that would probably be done in a function under the File menu in an Export function; it's not an interactive editing function. The only editcap functions that involve editing packet data are the ones that chop data from the beginning or end of the packet; there's nothing that resembles the current (not configured in by default) packet editor UI. After filtering out and selecting the required packets, they are opened in the Packet Editor UI. The packets can be a capture file or a capturing device A capturing device is, in effect, a capture file; if you're doing, or have done, a live capture, Wireshark has a capture file open that contains the captured packets. but the filter has to narrow down the packet editing. The UI will have three sets of toolbar and options (editcap,dissector,listener) to manipulate the packet. There will also exist a viewing tools to change how the selection of packets are percieved. Like data can be represented as HEX/BIN/ASCII with help of toggle switches. To which data are
Re: [Wireshark-dev] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]
On Apr 18, 2013, at 1:40 PM, Evan Huus eapa...@gmail.com wrote: The reassembly code could then add meta-data to this when reassembling, and the tvb could lazily refetch the underlying tvbs using the existing wiretap interface? Lazily *regenerate* the underlying tvbs. The bottom-level tvbs would be regenerated by reading packet data from the file. However, there might be intermediate-level tvbs that do *not* contain data directly fetched from a file; instead, the data might have been decompressed, or decrypted, or de-encoded from base-64, or otherwise processed. Consider a packet reassembled from 3 lower-leel chunks, the first of which came from a base-64 decoding of still lower-level data reassembled from 5 even lower-level decrypted packets ___ 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] Filebacked-tvbuffs : GSoC'13
On Apr 18, 2013, at 11:42 AM, Anders Broman a.bro...@bredband.net wrote: This might require redesigning the per-packet-data functionality to keep track of the level in the packet protocol stack as say IP might occur more than once in a packet. There might *already* be reasons for doing that. ___ 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] [GSoC 2013] Improved Fuzzing
Hi, I am Rohit, Ph.D. candidate in CS at University Of Georgia. My Research interests lie at the intersection of Distributed Systems and Networking. I am interested in 'improved fuzzing' project. I have basic idea of random fuzzing and symbolic execution. I have couple of couple of questions related to project. Could you please let me know if I can discuss the project? Regards, Rohit. ___ 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] 1.10 branch + release schedule
Hi, I'd like to create the 1.10 branch next Monday (April 22) followed by 1.10rc1 a day or two later. I'm planning on the following: In trunk-1.10: Demote Qt in configure.ac and wireshark.nsi. Anyone wishing to work with Qt should do so from the trunk. In trunk: Promote Qt. Enable it by default in configure.ac and wireshark.nsi. Drop the OS X PPC package. Few people download it and I usually spend a lot of time during the release process waiting for the PPC builder. Possibly drop the U3 package. I'm on the fence about this since a fair number of people still download U3 packages each month. However, the technology reached end of life in 2009 and we should probably start pointing them to the PortableApps package. Note that we would still be committed to supporting OS X PPC and U3 users until Wireshark 1.10 reaches end of life in 2015. ___ 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] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]
I dont think composite tvbs actually work. or at least they didnt work when we originally wrote the reassembly code. They have been fixed last year. They are working for me in 1.8.x code. -- --- Dirk Jagdmann http://cubic.org/~doj - http://llg.cubic.org ___ 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] 1.10 branch + release schedule
Note that we would still be committed to supporting OS X PPC and U3 users until Wireshark 1.10 reaches end of life in 2015. I suggest remove OsX PPC and U3 even for the 1.10 release. Your changes for GTK/QT sound reasonable. -- --- Dirk Jagdmann http://cubic.org/~doj - http://llg.cubic.org ___ 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
