Wireshark · Wireshark-dev: Re: [Wireshark-dev] string manipulation

["Anders Broman" <a.broman@xxxxxxxxx>]

Hi,
Your protocol gets handed a tvb with the protocol pdu
Imagine a buffer like this:

Offset
0000 00 01 02 03 04 06 07  61 62 63 64 65 66 67 68 ........  abcdefgh

If you want to put 06 into the protocol tree you should do:
Offset = 5;
proto_tree_add_item(tree, hf_foo, tvb, offset, 1, FALSE);

:
	{ &hf_proto_foo,
		{ "Text in proto tree","proto.foo",
		FT_UINT8,BASE_DEC, NULL, 0x0,
		NULL, HFILL }
	},
If the value 6 has a special meaning use a value_string and do:
	{ &hf_proto_foo,
		{ "Text in proto tree","proto.foo",
		FT_UINT8,BASE_DEC, VALS(proto_foo_vals), 0x0,
		NULL, HFILL }
	},
If you want to put the string abcdefgh into the protocol tree you need to
do:
Offset = 7
proto_tree_add_item(tree, hf_foo, tvb, offset, 8, FALSE);

:
	{ &hf_proto_foo2,
		{ " Text in proto tree ",	" proto.foo2",
		FT_STRING, BASE_NONE, 0, 0,
		NULL, HFILL }
	},
Regards
Anders

-----Ursprungligt meddelande-----
Från: wireshark-dev-bounces@xxxxxxxxxxxxx
[mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] För Brian Oleksa
Skickat: den 25 januari 2010 22:11
Till: Developer support list for Wireshark
Ämne: [Wireshark-dev] string manipulation

Guy

This past e-mail was very helpful. I have made some big leaps fixing 
some of my code to adhere to the coding standards.

But I do have some more questions:    I am on too strings now.

This is what I am currently doing:

PS. I am still working on fixing the ptr stuff....but wanted to start 
small and work one problem at a time.

                    char flowname[9];
                    strncpy(flowname, ptr, 8);
                    flowname[8] = '\0';
                    ptr += 8;
                    proto_tree_add_uint_format(helen_sub_tree, 
hf_helen_length, tvb, offset, 8, 0,
                            "Flowname: %s", flowname);
                    offset += 8;

In the developers README file... it tells you NOT to use strcpy...but 
instead use g_snprintf().

I am having a hard time interpreting this into what I already have. Any 
help (or examples using g_snprintf) is greatly appreciated.

Thanks,
Brian





Guy Harris wrote:
> On Jan 21, 2010, at 11:59 AM, Brian Oleksa wrote:
>
>   
>> But how I start the initial counting process is I do the following:
>>
>> guint8 * ptr = (guint8*) tvb->real_data;
>>     
>
> Don't do that.
>
> First of all, that isn't guaranteed to work for all tvbuffs; we currently
aren't using composite tvbuffs (and there are apparently some bugs in them),
but, if we do, there is no guarantee that the "real_data" field of a tvbuff
will always be valid.
>
> Second of all, you should not just extract fields from the packet data
yourself:
>
> 	doing so means that no bounds checking is done, so you might run
past the end of the packet data (do *NOT* assume either that all packets for
your protocol will be valid or that the capture wasn't cut short by setting
the snapshot length when capturing);
>
> 	doing so means that if a field isn't aligned on an appropriate
boundary in memory, attempting to fetch the data could fail (SPARC
processors, for example, do not support unaligned accesses, and we *do*
support Wireshark on SPARC);
>
> 	doing so means means that you have to do the byte swapping yourself.
>
> Instead, use the tvb_get_ routines to fetch fields individually, using the
offset variable.
>
> Speaking of byte swapping, this:
>
>
https://www.darkcornersoftware.com/confluence/display/open/Packet+Structure
>
> says "All values are in network byte order", so if you're running on a
machine with the most popular family of desktop and notebook processors -
i.e., an x86 or x86-64 processor - you *would* have to byte-swap values if
you fetch them yourself.  That also means that the tvb_get_ntoh routines
should be used to fetch numerical field values.
>
>   
>> Actually..... maybe you can see your answer better in the code. I have
attached the packet-helen.c file.
>>     
>
> Please don't use hf_helen_length for anything other than an actual length
field.  Each field in the packet should have its *own* hf_ value.
>
> Once you've started using the tvb_get_ routines, and the offset variable,
to process the fields, and have given each field its own hf_ value, then:
>
> The hf_ item for the time stamp should be something like
>
> 	{ &hf_helen_time,
> 	    { "Time", "helen.time", FT_ABSOLUTE_TIME, BASE_NONE, NULL, 0x0,
"Time", HFILL}},
>
> If you want to display the times as UTC, then the way you'd do this
depends on the version of Wireshark you're using.
>
> Wireshark 1.0.x or 1.2.x:
>
> You would add that field to the packet by doing something such as
>
> 	nstime_t t;
> 	guint64 msecs_since_the_epoch;
> 	struct tm *tmp;
> 	static const char *mon_names[12] = {
> 		"Jan",
> 		"Feb",
> 		"Mar",
> 		"Apr",
> 		"May",
> 		"Jun",
> 		"Jul",
> 		"Aug",
> 		"Sep",
> 		"Oct",
> 		"Nov",
> 		"Dec"
> 	};
>
> 	msecs_since_the_epoch = tvb_get_ntoh64(tvb, offset);
> 	t.secs = msecs_since_the_epoch/1000;
> 	t.nsecs = (msecs_since_the_epoch%1000)*1000000;	/* milliseconds to
nanoseconds */
> 	tmp = gmtime(&t.secs);
> 	proto_tree_add_time_format_value(helen_sub_tree, hf_helen_time, tvb,
offset, 8, &t,
> 	    "%s %2d, %d %02d:%02d:%02d.%09ld UTC",
> 	    mon_names[tmp->tm_mon],
> 	    tmp->tm_mday,
> 	    tmp->tm_year + 1900,
> 	    tmp->tm_hour,
> 	    tmp->tm_min,
> 	    tmp->tm_sec,
> 	    (long)t.nsecs);
>
> Current top-of-tree Wireshark:
>
> You would have the hf_ item be something like
>
> 	{ &hf_helen_time,
> 	    { "Time", "helen.time", FT_ABSOLUTE_TIME, ABSOLUTE_TIME_UTC,
NULL, 0x0, "Time", HFILL}},
>
> and do something like
>
> 	nstime_t t;
> 	guint64 msecs_since_the_epoch;
>
> 	msecs_since_the_epoch = tvb_get_ntoh64(tvb, offset);
> 	t.secs = msecs_since_the_epoch/1000;
> 	t.nsecs = (msecs_since_the_epoch%1000)*1000000;	/* milliseconds to
nanoseconds */
> 	proto_tree_add_time(helen_sub_tree, hf_helen_time, tvb, offset, 8,
&t);
>
> If you want to display the time as local time (in the time zone of the
machine running Wireshark), that's a bit easier.
>
___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>   
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe