Developer support list for Wireshark ()

Guy Harris | 1 Apr 2009 01:01

Re: Filtering

On Mar 31, 2009, at 3:53 PM, gogrady@... wrote:

> I think that answer my question. So it looks like my best bet is to  
> use the hidden field and just go with bad UI eh?

Your *best* bet might be to find a way of dissecting the packet that  
doesn't involve your DLL, given the problems you've been having trying  
to use it in Wireshark (probably because it was never designed for use  
in Wireshark, and so is a bad fit for Wireshark; square pegs fit into  
round holes only with a lot of hard pounding and perhaps some ugly  
noises and damage to peg, hole, or both).

Code such as

	time = (_GetMsgTime)();
	pi = proto_tree_add_text(icom_message_tree, tvb, 0, 0, "Time: %s",  
time);

is suboptimal UI even if you completely ignore filtering issues - you  
can't click on the "Time: %s" line and see what packet data  
corresponds to it, for example.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

headers

gogrady | 1 Apr 2009 01:22

Re: Filtering

The only way to dissect this protocol is through the dll, i cannot create it soley in the plugin as is the
design requirements. I'm working on functions that will show the bytes for the corresponding packet
section and currently have all but the last level of dissection level of the protocol.

Greg

Guy Harris wrote:
> On Mar 31, 2009, at 3:53 PM, gogrady@... wrote:
>
>> I think that answer my question. So it looks like my best bet is to  
>> use the hidden field and just go with bad UI eh?
>
> Your *best* bet might be to find a way of dissecting the packet that  
> doesn't involve your DLL, given the problems you've been having trying  
> to use it in Wireshark (probably because it was never designed for use  
> in Wireshark, and so is a bad fit for Wireshark; square pegs fit into  
> round holes only with a lot of hard pounding and perhaps some ugly  
> noises and damage to peg, hole, or both).
>
> Code such as
>
> 	time = (_GetMsgTime)();
> 	pi = proto_tree_add_text(icom_message_tree, tvb, 0, 0, "Time: %s",  
> time);
>
> is suboptimal UI even if you completely ignore filtering issues - you  
> can't click on the "Time: %s" line and see what packet data  
> corresponds to it, for example.

___________________________________________________________________________

(Continue reading)

headers

Guy Harris | 1 Apr 2009 01:25

Re: Filtering

On Mar 31, 2009, at 4:01 PM, Guy Harris wrote:

> Your *best* bet might be to find a way of dissecting the packet that
> doesn't involve your DLL, given the problems you've been having trying
> to use it in Wireshark (probably because it was never designed for use
> in Wireshark, and so is a bad fit for Wireshark; square pegs fit into
> round holes only with a lot of hard pounding and perhaps some ugly
> noises and damage to peg, hole, or both).

Now, in cases where the DLL returns something useful for Wireshark,  
rather than just a human-readable text string - i.e., where it returns  
the raw value from the packet - you could use proto_tree_add_uint() to  
add the value to the protocol tree; that would make it filterable, and  
Wireshark would display it for you.

If you're really ambitious, in cases such as

	time = (_GetMsgTime)();
	pi = proto_tree_add_text(icom_message_tree, tvb, 0, 0, "Time: %s",
time);

you could try parsing the string you get back from the DLL and convert  
it to a value that you could hand to a proto_tree_add routine.

If the DLL doesn't hand you the raw offset in the packet data for a  
field, or the raw length of the data for the field, you still wouldn't  
be able to pass the real offset and length fields to the  
proto_tree_add routines, so you still wouldn't be able to click on the  
field and see which particular bytes in the packet correspond to the

(Continue reading)

headers

Guy Harris | 1 Apr 2009 01:30

Re: Filtering

On Mar 31, 2009, at 4:22 PM, gogrady@... wrote:

> The only way to dissect this protocol is through the dll, i cannot  
> create it soley in the plugin as is the design requirements.

Can you tell whoever imposed those design requirements that perhaps  
they should impose *on the DLL* a design requirement that there be  
ways of getting, for each field, the *raw data* rather than some  
"helpful" human-readable interpretation of the field - and that it  
return the raw byte offset and length-in-bytes of a field, if it  
doesn't do so already -  if they're going to make use of the DLL a  
requirement for the design of the Wireshark dissector?

Otherwise, it's somewhat like imposing a design requirement on a house  
that the only form of hammers to be used when building the house are  
sledgehammers, even for hammering nails into walls.

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

headers

mirtaher | 1 Apr 2009 05:00

how to get Wireshark directory path ?

Hi,

I am writing a plug in to dissect MPICH packets and I need the absolute
path of the wireshark home directory so I can access a shell file on my
plug in folder.

I.e. <wiresharkfolder>/plugins/mpich/≤myshell file.>

Is there any environment variable or wireshark variable that store it, or
any other way I can get it ?

Appreciate any help.
Seyed.
_________________________________________

Seyed M. Mirtaheri
+1 (778) 883 3500
Department of Computer Science
University of British Columbia

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

headers

gogrady | 1 Apr 2009 05:28

Re: Filtering

hello,

well theres no way i can change how the lib dissects since it is used in many more programs than just
wireshark. i am creating a dll interface between wireshark plugin and the protocol lib, it returns the
human readable information because that is what is needed for the more important programs that my company
is developing. There are ways in my dll and lib to get the size of the raw data so that when i highlight in
wireshark it highlights the correct bytes in the raw data section, i have functions that i can pass to the
proto_tree_add_'s for length that do this, and i have a variable "offset" that keeps track of the current
placement in the raw data. The design is and must stay as the raw data is passed plugin -> interface -> lib and
then the human readable char * or int from lib -> interf
 ace -> plugin and must be done as so. Unless you have another idea for outputing these types to make
filterable, it seems to me that the only way is to use the hidden items along with the ad
 d_text.

Any other ideas? Hopefully you can understand that i would do it differently if i could, but unfortunately
this is not the most important project and is only used for troubleshooting the complex protocol in which
my company wants to use their already made lib,

Thank you for all the help, it has helped me better understand wireshark dissection,

Greg

Guy Harris wrote:
> On Mar 31, 2009, at 4:22 PM, gogrady@... wrote:
>
>> The only way to dissect this protocol is through the dll, i cannot  
>> create it soley in the plugin as is the design requirements.
>
> Can you tell whoever imposed those design requirements that perhaps  
> they should impose *on the DLL* a design requirement that there be

(Continue reading)

headers

Guy Harris | 1 Apr 2009 05:39

Re: Filtering


On Mar 31, 2009, at 8:28 PM, gogrady@... wrote:

> i am creating a dll interface between wireshark plugin and the  
> protocol lib, it returns the human readable information because that  
> is what is needed for the more important programs that my company is  
> developing.

That's *all* that's needed?  And they won't make changes to allow the  
DLL to be used conveniently in protocol analyzers as well?

> There are ways in my dll and lib to get the size of the raw data so  
> that when i highlight in wireshark it highlights the correct bytes  
> in the raw data section, i have functions that i can pass to the  
> proto_tree_add_'s for length that do this, and i have a variable  
> "offset" that keeps track of the current placement in the raw data.  
> The design is and must stay as the raw data is passed plugin ->  
> interface -> lib and then the human readable char * or int from lib - 
> > interface -> plugin and must be done as so. Unless you have  
> another idea for outputing these types to make filterable, it seems  
> to me that the only way is to use the hidden items along with the  
> add_text.

The idea that I've already mentioned is that:

	for the cases where the library returns an int, if the int value is  
the raw data for the field, use it in proto_tree_add_uint() or  
proto_tree_add_int();

	for the cases where the library human-readable string, parse the

(Continue reading)

headers

Maynard, Chris | 1 Apr 2009 16:29

Re: Filtering

I sort of hate to jump back in here because Guy really knows his stuff
and I think he's already given the best advice, but I thought I would
try to provide a more concrete example of what Guy is referring to with
the proto_tree_add_format_value_{something other than text} reference
...

Using the original "time" example, I think the following pseudo-code
should more-or-less do the job:

static int hf_icom_time = -1;

dissect_icom(...) {
    ...
    time = (_GetMsgTime)();
    pi = proto_tree_add_string_format_value(icom_message_tree,
hf_icom_time, tvb, 0, 0, time, "%s", time);
    ...
}

...

    { &hf_icom_time,
        { "Time", "icom.time", FT_STRINGZ, BASE_NONE,
        NULL, 0x00, "", HFILL }
    },
...

- Chris

> -----Original Message-----

(Continue reading)

headers

Gerhard Gappmeier | 1 Apr 2009 18:32

OPCUA Update

Hi all,

the most OPC UA Specifications are released meanwhile.
Also Part 6 which describes the protocol.
So it was overdue to update the wireshark opcua plugin.

Really a lot changed since the last update: transport, security and application layer, so this is a big update.

I attached the patch that will update the code.
It's only tested on Linux, but buildbot while verify the other platforms anyway.

I also attached a sample capture file for fuzzy testing.

What is really missing is a configuration option in Edit->preferences
where you can configure the port. Default is port 4840,
which is also the registered port for OPCUA.
But a lot of servers will run on other ports, so a configuration option would be nice.

Maybe somebody can help at this point, because I have no clue about the
wireshark GUI stuff.

--
mit freundlichen Grüßen / best regards

Gerhard Gappmeier
ascolab GmbH - automation systems communication laboratory
Tel.: +49 9131 691 123
Fax: +49 9131 691 128
Web: http://www.ascolab.com
GPG-Key: http://www.ascolab.com/gpg/gg.asc

Attachment (cppserver.cap): application/octet-stream, 52 KiB

Attachment (opcuaV1.patch): text/x-patch, 392 KiB

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

headers

buildbot | 1 Apr 2009 19:37

buildbot failure in Wireshark (development) on Ubuntu-7.10-x86-64

The Buildbot has detected a new failure of Ubuntu-7.10-x86-64 on Wireshark (development).
Full details are available at:
 http://buildbot.wireshark.org/trunk/builders/Ubuntu-7.10-x86-64/builds/843

Buildbot URL: http://buildbot.wireshark.org/trunk/

Buildslave for this Build: ubuntu-7.10-x86

Build Reason: 
Build Source Stamp: HEAD
Blamelist: etxrab,wmeier

BUILD FAILED: failed fuzz-menagerie

sincerely,
 -The Buildbot

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@...>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@...?subject=unsubscribe

Mon	Tue	Wed	Thu	Fri	Sat	Sun

		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30

198	May 2013
306	April 2013
286	March 2013
226	February 2013
157	January 2013
141	December 2012
145	November 2012
271	October 2012
231	September 2012
270	August 2012
259	July 2012
212	June 2012
271	May 2012
155	April 2012
188	March 2012
218	February 2012
267	January 2012
141	December 2011
189	November 2011
271	October 2011
297	September 2011
702	August 2011
519	July 2011
330	June 2011
367	May 2011
371	April 2011
293	March 2011
235	February 2011
278	January 2011
311	December 2010
369	November 2010
376	October 2010
313	September 2010
248	August 2010
254	July 2010
225	June 2010
341	May 2010
382	April 2010
357	March 2010
313	February 2010
382	January 2010
204	December 2009
287	November 2009
341	October 2009
350	September 2009
380	August 2009
463	July 2009
372	June 2009
393	May 2009
425	April 2009
397	March 2009
368	February 2009
192	January 2009
266	December 2008
288	November 2008
330	October 2008
218	September 2008
259	August 2008
348	July 2008
347	June 2008
280	May 2008
555	April 2008
342	March 2008
344	February 2008
350	January 2008
279	December 2007
513	November 2007
389	October 2007
325	September 2007
633	August 2007
431	July 2007
305	June 2007
433	May 2007
394	April 2007
675	March 2007
512	February 2007
736	January 2007
386	December 2006
523	November 2006
536	October 2006
578	September 2006
392	August 2006
322	July 2006
84	June 2006