Martin Wilck | 10 Feb 10:22
Gravatar

SSL decryption breaks after retransmission

Hello,

I just stumbled upon the known problem "SSL decryption breaks after
retransmission"
(http://www.wireshark.org/lists/wireshark-dev/200805/msg00067.html) with
wireshark 1.6.5.

I wonder if a patch for this issue is available? Is anybody working on this?

Martin

--

-- 
Dr. Martin Wilck
PRIMERGY System Software Engineer
x86 Server Engineering

FUJITSU
Fujitsu Technology Solutions GmbH
Heinz-Nixdorf-Ring 1
33106 Paderborn, Germany
Phone:			++49 5251 525 2796
Fax:			++49 5251 525 2820
Email:			martin.wilck@...
Internet:		http://ts.fujitsu.com
Company Details:	http://ts.fujitsu.com/imprint
___________________________________________________________________________
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
(Continue reading)

Sean Bright | 10 Feb 00:20
Picon
Gravatar

Logical error in r37159

In r37159, the following change was made to ui/gtk/rtp_player.c:

<at> <at> -1654,9 +1636,7 <at> <at> GtkWidget *dialog; /* we should never be here if we are in PLAY and !PAUSE */ - if(!rtp_channels->stop && !rtp_channels->pause){ - exit(10); - } + g_assert(!rtp_channels->stop && !rtp_channels->pause); The logic, however, was not negated properly. The correct assertion should be: g_assert(rtp_channels->stop || rtp_channels->pause); With the current code, the RTP player causes a crash for me when pressing the 'Play' button. Thanks, Sean Bright
___________________________________________________________________________
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
Lanell Allen | 9 Feb 16:20
Picon
Gravatar

1.7.1 bug? tcp.flags == 0x8c2

[SYN, ECN, CWR]

The "tcp.flags == 0x8c2" filter crashes on v. 1.7. Stays "pink" with the error message "invalid filter" / "too big", etc.
Works fine on 1.6.1 and 1.6.4

Lanell Allen, WCNA
___________________________________________________________________________
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
Anders Broman | 8 Feb 17:05
Picon
Favicon

Adding name resolution blocks in Wireshark

Hi,
Getting WS to add a Name resolution block seems to be a simple patch
Index: file.c
===================================================================
--- file.c      (revision 1249)
+++ file.c      (working copy)
<at> <at> -3786,6 +3786,9 <at> <at>
       goto fail;
     }
 
+       /* Add address resolution */
+       wtap_dump_set_addrinfo_list(pdh, get_addrinfo_list());
+
 
Should it be safeguarded with a preference? Any other pitfalls?
 
Regards
Anders
 
___________________________________________________________________________
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
Roland Knall | 8 Feb 15:20
Picon

Updating fuzz-menagerie?

Hi

Short question, two actually. First, there are some entries in the
fuzz-menagerie, which do not work, as they are patches. Shouldn't they
be removed from the test all together? And my second question, I have
added some example capture files to
http://wiki.wireshark.org/SampleCaptures#openSAFETY , and I was
wondering, if I need to do anything else to add them to the normal
fuzz-menagerie

regards,
Roland
___________________________________________________________________________
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

Picon
Favicon
Gravatar

Filtering Question

What's the difference between ip.src and ip.src_host (and ip.dst and ip.dst_host and ip.addr vs ip.host)?

http://www.wireshark.org/docs/dfref/i/ip.html lists one as a type "Character" and another as type "IPv4 address"
 

ip.dst IPv4 address Destination 1.0.0 to 1.6.5
ip.dst_host Character string Destination Host 1.0.0 to 1.6.5

They return the same results, so what exactly does the "type" do?

 Thanks,
Jonathan S. Weissman
___________________________________________________________________________
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
Anders Broman | 7 Feb 15:33
Picon
Favicon

Defining a DLT which could be used to dissect any protocol.

Hi,
How about defining a DLT with a TLV based header which could be used to carry any protocol - a tag would contain the name of the protocol to be called the name would of course have to correspond
To the name the dissector has registered in Wireshark - yes this is a weakness an alternative would be to give every protocol a number but that means keeping a registry list.
Tags could be defined to carry any extra info needed.
 
Something like this
Header
Header length
Header version
-------------------
Tag
Length
value
--------
:
--------
Tag = Data
Length
Data
 
Example tags
Tag = 1  Protocol name, the name used by the Wireshark dissector to be called with the protocol data. ( ex "sip" ).
Tag = 2  SRC Address( Octet 1 = Address family), ( ex IP4 address, IP6 Address, OPC, DPC ....)
                                   2-n Address data
Tag = 2  DST Address
:
Tag X  Vendor specific ( vendor Id, vendor tag  + data)
Tag = 254 Data
Tag = 255 Reserved for extension
 
This is just to test the wathers before geting to far into defining the tags.
Comments?
 
Regards
Anders
 
___________________________________________________________________________
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
Sylvain Munaut | 7 Feb 08:06
Picon

[RFC] bug 6797 : proto: Add proto_tree_add_split_{uint, int} helpers for non contiguous int fields

Hi,

Anders Broman suggested I post here to get more feedback.

----
This adds a helper in proto.c to display fields where you have to go grab bits
at several places (within a 32 bits word) to make the value.

This doesn't recover the value of the field itself, it just takes care of the
formating and displaying of 'bit fields' in the common format to display such
things.

(thing like  ....110...1100...1 = 0xd9)

This will be used in the GMR-1 RR dissector among others where some fields have
been split into small values (i.e. MSB at one place, LSB at another).

If you don't think this belongs in proto and should be somewhere else, I can
prefix it with gmr1_ and place it in gmr1_common.c (it does need to be exported
in the global namespace tough because it's used in several gmr1 files).
----

And the feedback already in the bug tracker:

> We would need a write up of the function in README.developer as well.

Ok, will do.

> You should probably post to the developers list to get more feedback.

Done :)

> Would it be feasible to have proto_tree_add_split_item() instead/as well
> and have all the magic done internally?

There is two issues there:
 - First the caller code can often decode the real value much more
easily than having to reconstruct it bit by bit.
 - Some time to get the value you have to take the bits in a weird
"order". Like if you get something like

...3210...7654  (dots are unused bits, numbers are bit position).

The caller knows he can just do (val & 0xf) << 4 | ((val & 0xf00) >> 8)
But passing the info on which bit to take when is not trivial.

Here I'm aiming to provide visual feedback about which bits where used
rather than how they were used.

> Would it be better to go for 64bits?

I used 32 bits because all the display "magic" is done by a
pre-existing helper decode_bitfield_value and it only handles 32 bits.

> Come to think of it would proto_tree_add_split_bits_item(tvb,tree,
start_bit_offset,num_of_bits,num_skip_bits,num_of_remaining_bits,encoding) make more sense?

See above: Sometimes the bits don't have to be taken "in order" ...

Cheers,

    Sylvain
From 656fbda551f07b8d5bd1c4af412f257692628e9c Mon Sep 17 00:00:00 2001
From: Sylvain Munaut <tnt <at> 246tNt.com>
Date: Sun, 18 Dec 2011 13:22:10 +0100
Subject: [PATCH] proto: Add proto_tree_add_split_{uint,int} helpers for non contiguous int fields

Signed-off-by: Sylvain Munaut <tnt <at> 246tNt.com>
---
 epan/proto.c |   94 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 epan/proto.h |   32 ++++++++++++++++++++
 2 files changed, 126 insertions(+), 0 deletions(-)

diff --git a/epan/proto.c b/epan/proto.c
index 7c3a214..01b2162 100644
--- a/epan/proto.c
+++ b/epan/proto.c
@@ -2932,6 +2932,53 @@ proto_tree_add_uint(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
 	return pi;
 }

+proto_item*
+proto_tree_add_split_uint(proto_tree *tree, const int hf_index,
+                          tvbuff_t *tvb, const gint start, const gint len,
+                          guint32 true_value, guint32 mask, const guint enc)
+{
+	char *bf_str, *lbl_str;
+	proto_item* pi;
+	guint32 v;
+
+	if (!tree)
+		return NULL;
+
+	bf_str = ep_alloc(64);
+	lbl_str = ep_alloc(ITEM_LABEL_LENGTH+1);
+
+	switch (len) {
+	case 1:
+		v = tvb_get_guint8(tvb, start);
+		break;
+
+	case 2:
+		v = (enc == ENC_BIG_ENDIAN) ?
+			tvb_get_ntohs(tvb, start) :
+			tvb_get_letohs(tvb, start);
+		break;
+
+	case 4:
+		v = (enc == ENC_BIG_ENDIAN) ?
+			tvb_get_ntohl(tvb, start) :
+			tvb_get_letohl(tvb, start);
+		break;
+
+	default:
+			DISSECTOR_ASSERT_NOT_REACHED();
+	}
+
+	decode_bitfield_value(bf_str, v, mask, len<<3);
+
+	pi = proto_tree_add_uint(tree, hf_index, tvb, start, len, true_value);
+
+	proto_item_fill_label(PITEM_FINFO(pi), lbl_str);
+
+	proto_item_set_text(pi, "%s%s", bf_str, lbl_str);
+
+	return pi;
+}
+
 proto_item *
 proto_tree_add_uint_format_value(proto_tree *tree, int hfindex, tvbuff_t *tvb,
 				 gint start, gint length, guint32 value,
@@ -3098,6 +3145,53 @@ proto_tree_add_int(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
 	return pi;
 }

+proto_item*
+proto_tree_add_split_int(proto_tree *tree, const int hf_index,
+                         tvbuff_t *tvb, const gint start, const gint len,
+                         gint32 true_value, guint32 mask, const guint enc)
+{
+	char *bf_str, *lbl_str;
+	proto_item* pi;
+	guint32 v;
+
+	if (!tree)
+		return NULL;
+
+	bf_str = ep_alloc(64);
+	lbl_str = ep_alloc(ITEM_LABEL_LENGTH+1);
+
+	switch (len) {
+	case 1:
+		v = tvb_get_guint8(tvb, start);
+		break;
+
+	case 2:
+		v = (enc == ENC_BIG_ENDIAN) ?
+			tvb_get_ntohs(tvb, start) :
+			tvb_get_letohs(tvb, start);
+		break;
+
+	case 4:
+		v = (enc == ENC_BIG_ENDIAN) ?
+			tvb_get_ntohl(tvb, start) :
+			tvb_get_letohl(tvb, start);
+		break;
+
+	default:
+			DISSECTOR_ASSERT_NOT_REACHED();
+	}
+
+	decode_bitfield_value(bf_str, v, mask, len<<3);
+
+	pi = proto_tree_add_int(tree, hf_index, tvb, start, len, true_value);
+
+	proto_item_fill_label(PITEM_FINFO(pi), lbl_str);
+
+	proto_item_set_text(pi, "%s%s", bf_str, lbl_str);
+
+	return pi;
+}
+
 proto_item *
 proto_tree_add_int_format_value(proto_tree *tree, int hfindex, tvbuff_t *tvb,
 				gint start, gint length, gint32 value,
diff --git a/epan/proto.h b/epan/proto.h
index 6859d48..0051211 100644
--- a/epan/proto.h
+++ b/epan/proto.h
@@ -1320,6 +1320,22 @@ extern proto_item *
 proto_tree_add_uint(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
 	gint length, guint32 value);

+/** Add one FT_UINT8, FT_UINT16, FT_UINT24 or FT_UINT32 to a proto_tree
+ *  when it's contructed from non contiguous bits
+ @param tree the tree to append this item to
+ @param hfindex field index
+ @param tvb the tv buffer of the current data
+ @param start start of data in tvb
+ @param length length of data in tvb
+ @param true_value data to display and set
+ @param mask mask of bits belonging to the value (used to generate string)
+ @param enc encoding endianness
+ @return the newly created item */
+extern proto_item*
+proto_tree_add_split_uint(proto_tree *tree, const int hf_index,
+	tvbuff_t *tvb, const gint start, const gint len,
+	guint32 true_value, guint32 mask, const guint enc);
+
 /** Add a formatted FT_UINT8, FT_UINT16, FT_UINT24 or FT_UINT32 to a proto_tree,
     with the format generating the string for the value and with the field
     name being included automatically.
@@ -1409,6 +1425,22 @@ extern proto_item *
 proto_tree_add_int(proto_tree *tree, int hfindex, tvbuff_t *tvb, gint start,
 	gint length, gint32 value);

+/** Add one FT_INT8, FT_INT16, FT_INT24 or FT_INT32 to a proto_tree
+ *  when it's contructed from non contiguous bits
+ @param tree the tree to append this item to
+ @param hfindex field index
+ @param tvb the tv buffer of the current data
+ @param start start of data in tvb
+ @param length length of data in tvb
+ @param true_value data to display and set
+ @param mask mask of bits belonging to the value (used to generate string)
+ @param enc encoding endianness
+ @return the newly created item */
+extern proto_item*
+proto_tree_add_split_int(proto_tree *tree, const int hf_index,
+	tvbuff_t *tvb, const gint start, const gint len,
+	gint32 true_value, guint32 mask, const guint enc);
+
 /** Add a formatted FT_INT8, FT_INT16, FT_INT24 or FT_INT32 to a proto_tree,
     with the format generating the string for the value and with the field
     name being included automatically.
--

-- 
1.7.3.4

___________________________________________________________________________
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
Tyson Key | 6 Feb 22:45
Picon
Gravatar

User-Customisable Payload Dissection

Hi,

Now that the GSM SIM/ISO 7816 protocol dissector has been integrated,
it might be useful to provide a "Payload Protocol" option for the CCID
dissector - so that users can switch appropriately between treating
payloads as either plain data, or as GSM SIM/ISO 7816 packets.

With that in mind, please can someone provide some pointers as to how
I'd go about implementing such a feature? I've seen some of the
preferences-related notes in the ReadMe files; and the thread on the
"Decode As..." dialogue - but I'm unsure if there's a generic approach
to dealing with that sort of thing in dissectors.

Thanks,

Tyson.

--

-- 
                                          Fight Internet Censorship!
http://www.eff.org
http://vmlemon.wordpress.com | Twitter/FriendFeed/Skype: vmlemon |
00447934365844
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev <at> wireshark.org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request <at> wireshark.org?subject=unsubscribe
Mike Morrin | 5 Feb 23:03
Picon
Gravatar

CSN.1 [Re: Remaining Wireshak stuff during FOSDEM]

Sylvain Munaut wrote: 
> - CSN1 decoding is manually coded right now - and wrong in some places.
>  Automatic creation like ASN.1 possible but rather hard problem.

Something pretty important to me is that the code can be modified to "look" nice.

For eg. when you look at the TETRA dissectors that uses ASN.1 autogenerated stuff the field values are presented but the names are obscure and most of the time you have no idea what they mean unless you have the spec opened at the right page beside you.

While on the other hand when you look at the output of the manually crafted CSN1 (well, it uses a CSN1 helpers of course) code of GMR1, each value is nicely presented, with field meaning from the specs if appropriate and the value properly decoded (like if an integer represents a frequency in 0.5 Hz increment, it will display that).

So IMHO the approach currently used right now (a csn1 generic framework + description of the structures in specific files) is not bad, it just misses something to "pre generate" all the boilerplate stuff from a .csn1 file.

Note that there are currently two forms of csn.1 dissection in wireshark.  
*  The handcrafted, in-line dissection stuff, such as packet-gsm_a_rr.c 
*  The table driven, engine-dissected stuff using packet-csn1.c as a dissection engine, such as packet-gsm_rlcmac.c.  

I  recently gave  the csn.1 dissection in packet-gsm_a_rr.c a significant facelift, and although the source code is a bit fiddly, I does format the dissection in a highly readable manner.

I am currently embarked on some significant enhancements to packet-gsm_rlcmac.c, including dissection of RLC data headers and improvements to readability of the dissection.  
With practice the table driven dissectors are quicker to write, but they can be rather obscure on first acquaintance, especially for nested structures and loops.

Anyway my main point is that csn.1 is generally an evolutionary dead-end, and other than minor extensions in the 2 GSM protocols that use it, it is unlikely to be used in new protocols (for commercial and IPR reasons), so I would not recommend people to lose too much sleep trying to auto-generate csn.1 dissectors.
___________________________________________________________________________
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
Sylvain Munaut | 5 Feb 21:10
Picon

filters name : gmr1_xxx vs gmr1.xxx

Hi,

I'm about to submit GMR-1 dissectors and when running them through the
checkfiltername script, it warns me about the name I chose.

Since GMR-1 has different channel types with completely different
messages (and messages encoding), there is several packet-xxx:

packet-gmr1_dtap.c
packet-gmr1_rr.c
packet-gmr1_common.c
packet-gmr1_bcch.c

So far I had named the filters in the field definition like
gmr1.bcch.xxx  or gmr1.rr.xxx ...

Is that acceptable or should I really stick to starting the filters by
what's after the 'packet-' filename ?

Cheers,

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


Gmane