Re: [Wireshark-dev] JSONshark -- Was: Applying for GSOC

Hello I think we have to build an api layer for converting data from libwireshark(dissection core) to JSON which would then be interpreted by JavaScript browser to display results Am i getting the idea right? Regards Sumit On Fri, Apr 12, 2013 at 5:33 AM, Jakub Zawadzki wrote: > On Wed, Apr 1

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.

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 ___

[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 defaul

[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 rela

Re: [Wireshark-dev] Filebacked-tvbuffs : GSoC'13

On Apr 18, 2013, at 11:42 AM, Anders Broman 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. _

Re: [Wireshark-dev] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]

On Apr 18, 2013, at 1:40 PM, Evan Huus 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 regen

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.

Re: [Wireshark-dev] Enhanced PCAP-NG dissection

On Apr 18, 2013, at 1:01 PM, Brandon Carpenter 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

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 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

Re: [Wireshark-dev] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]

On Thu, Apr 18, 2013 at 4:59 PM, Anders Broman wrote: > Evan Huus skrev 2013-04-18 22:40: > >> On Thu, Apr 18, 2013 at 3:56 PM, Jeff Morriss >> 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 da

Re: [Wireshark-dev] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]

On Thu, Apr 18, 2013 at 4:53 PM, Jeff Morriss wrote: > On 04/18/13 16:40, Evan Huus wrote: >> >> On Thu, Apr 18, 2013 at 3:56 PM, Jeff Morriss >> wrote: >>> >>> On 04/18/13 15:14, Evan Huus wrote: This is a tangential issue that has always confused me. Why do we malloc+me

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 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 ef

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 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

Re: [Wireshark-dev] Copying TVBs for Reassembly [Was: Filebacked-tvbuffs : GSoC'13]

On Thu, Apr 18, 2013 at 3:56 PM, Jeff Morriss 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

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 wrote: > This is a tangential issue that has always confused me. > > Why do we malloc+memcpy data for reassembly when we already hav

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 edit

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

Re: [Wireshark-dev] Need help for getting started

Hi Jeff, Thanks, I explored the both the suggested list, I found list[1] 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 o

[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 woul

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-pa

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 p

Re: [Wireshark-dev] Filebacked-tvbuffs : GSoC'13

On Thu, Apr 18, 2013 at 9:25 PM, Jeff Morriss wrote: > 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 situation

Re: [Wireshark-dev] Filebacked-tvbuffs : GSoC'13

On Apr 18, 2013, at 10:28 AM, Evan Huus 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

Re: [Wireshark-dev] Filebacked-tvbuffs : GSoC'13

On Thu, Apr 18, 2013 at 1:11 PM, Guy Harris wrote: > > On Apr 18, 2013, at 9:28 AM, Evan Huus 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 y

Re: [Wireshark-dev] Filebacked-tvbuffs : GSoC'13

On Apr 18, 2013, at 9:28 AM, Evan Huus 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

Re: [Wireshark-dev] [GSoC] Packet Editor and Viewer

On Apr 15, 2013, at 1:57 PM, Edwin Abraham 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 p

Re: [Wireshark-dev] [GSoC] Packet Editor and Viewer

On Apr 18, 2013, at 1:38 AM, Edwin Abraham 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

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 wrote: > vineeth vijay skrev 2013-04-18 18:11: > > Hi Anders, > > Do you mean abi

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) gi

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. Regard

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

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 unde

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 wrote: > Hi, > > I think these topi

Re: [Wireshark-dev] GSOC ideas: protocol buffers dissector andFileshark

Dnia 18 kwietnia 2013 17:56 Guy Harris 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 F

Re: [Wireshark-dev] GSOC ideas: protocol buffers dissector and Fileshark

On Apr 18, 2013, at 8:34 AM, okordy 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 pro

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 wher

[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 diss

[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 Arbitr

[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 b

[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

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 diggin

Re: [Wireshark-dev] needed wireshark-dev tool

On Apr 16, 2013, at 8:35 PM, 王贤刚 wrote: > see subject. What's a "wireshark-dev tool"? ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.or