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:
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
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
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
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
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
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
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
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.
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:
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
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)
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.
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)
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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,
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
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
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
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
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
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
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
-
42 matches
Mail list logo
