|
Hi,
How to get a attachment file from captured email.
Thanks,
Sridhar
-------Original Message-------
Date: 02/23/06 06:05:46
Subject: Ethereal-dev Digest, Vol 34, Issue 36
Send Ethereal-dev mailing list submissions to
To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ethereal-dev digest..."
Today's Topics:
1. RE: Fallen at the first hurdle :( (Guy Harris)
2. [bug][patch] packet-x11.c, file.c and addr_resolv.c (didier)
3. buildbot failure in Solaris-8-SPARC
4. Re: Fallen at the first hurdle :( (Ulf Lamping)
5. Patch for VoipCalls (Alejandro Vaquero)
6. RE: Fallen at the first hurdle :( (Maynard, Chris)
7. SV: [Ethereal-dev] Re: Re: Using USER DLT for RNSAP (over
SCCP) (Anders Broman)
8. Re: The FAQ is pretty much outdated in lot's of places, could
someone remove things no longer interesting? (Guy Harris)
9. Re: Fallen at the first hurdle :( (Ulf Lamping)
----------------------------------------------------------------------
Message: 1
Date: Wed, 22 Feb 2006 16:34:43 -0800 (PST)
Subject: RE: [Ethereal-dev] Fallen at the first hurdle :(
Message-ID:
Content-Type: text/plain;charset=iso-8859-1
Guy Harris wrote:
> The Win32: Recommended Tools section of the Developer's Guide needs to be
> changed to say that you need Cygwin *even for Win32 native builds*, as
> bash is required and you only get it with Cygwin.
It should also list "rm" as a necessary tool, unless we can use "del" in
the Makefiles.
------------------------------
Message: 2
Date: Thu, 23 Feb 2006 01:32:47 +0000
Subject: [Ethereal-dev] [bug][patch] packet-x11.c, file.c and
addr_resolv.c
Content-Type: text/plain; charset="us-ascii"
Hi
3 bugs
packet-x11
copy and past overlooked? test with 8 but substract to 4.
file.c
time reference menu callback doesn't set cf->filter, it dumps a core if
you have a file big enough in find next/ find prev.
addr_resolv.c
leak memory, break list chain when snooping address.
Didier
PS:
No comment on my previous patch ? Here for a file with a lot of
reassembling it leaks 6 MBytes per filtering.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ethereal.patch.gz
Type: application/x-tar
Size: 1249 bytes
Desc: not available
Url : /pipermail/attachments/20060223/7a805fdf/ethereal.patch.tar
------------------------------
Message: 3
Date: Wed, 22 Feb 2006 19:46:46 -0600
Subject: [Ethereal-dev] buildbot failure in Solaris-8-SPARC
The Buildbot has detected a new failure of Solaris-8-SPARC.
Build Reason: changes
Build Source Stamp: 1992
Blamelist: lego
BUILD FAILED: failed distcheck
sincerely,
-The Buildbot
------------------------------
Message: 4
Date: Thu, 23 Feb 2006 03:04:54 +0100
Subject: Re: [Ethereal-dev] Fallen at the first hurdle :(
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Guy Harris wrote:
> Dave Ramsey wrote:
>
>> I have re-read the tools section very carefully, and Cygwin is only
>> mentioned as an alternative to Native Win32 ... I can't see where Cygwin
>> is
>> specified as a mandatory tool to build under Native Win32 environment,
>> although it IS late and I'm tired :)
>>
>
> The Win32: Recommended Tools section of the Developer's Guide needs to be
> changed to say that you need Cygwin *even for Win32 native builds*, as
> bash is required and you only get it with Cygwin.
>
Will this story ever end?
When I was writing the first version of the doc, I was only mentioning
the cygwin part.
Then some people were whining that they use the native Win32 tools and
it's much faster to work with and so on.
I added the native version descriptions.
The next time another one was whining: "I tried the native builds and it
didn't worked"
So I added a *bold note* "*Unless you know exactly what you are doing,
you should strictly following the recommendations!"*
But it seems to be common sense to ignore this note?!?
I know how this will continue:
I'm writing "bash is required from cygwin so you need to get cygwin".
So the next one will come and say: "but I'm using bash from the Gnuwin
project and it's just working fine".
And so the story will continue until doomsday ...
It seems to be common sense to read a small part of the doc and then
say: "but that doesn't work".
So actually I'm deeply tired to write that stuff so each and every lazy
person in the world is getting the point without actually reading the
guide at all.
I think I'm not going to continue working on the developer's guide, may
someone else continue this cumbersome and depressing work ...
Regards, ULFL
P.S: It also seems to be common sense to criticize the documentation
without doing anything to improve it. Documentation seems to be a "job
done by someone else". I''m going to follow this trail by the things I'm
going to do in the future. Let someone else do the user documentation ...
------------------------------
Message: 5
Date: Wed, 22 Feb 2006 21:48:16 -0700
Subject: [Ethereal-dev] Patch for VoipCalls
Content-Type: text/plain; charset="iso-8859-1"
Hi All,
find attached a patch for the VoipCalls to fix a couple of issues:
- a problem with the RTP Events (RFC2833) not been handle correctly
- Display the RTP stream in time order when the setup frame is after the
RTP stream.
- fix a init issue that caused the H245 packet to not been displayed
correctly.
Regards
Alejandro
-------------- next part --------------
Index: asn1/h245/packet-h245-template.c
===================================================================
--- asn1/h245/packet-h245-template.c (revision 17375)
+++ asn1/h245/packet-h245-template.c (working copy)
@@ -72,7 +72,7 @@
static dissector_handle_t h263_handle = NULL;
static dissector_handle_t amr_handle = NULL;
-static void reset_h245_packet_info(h245_packet_info *pi);
+static void init_h245_packet_info(h245_packet_info *pi);
static int hf_h245_pdu_type = -1;
static int hf_h245Manufacturer = -1;
static int h245_tap = -1;
@@ -316,6 +316,7 @@
while ( tvb_length_remaining( tvb, offset>>3 )>0 ){
CLEANUP_PUSH(reset_h245_pi, NULL);
h245_pi=ep_alloc(sizeof(h245_packet_info));
+ init_h245_packet_info(h245_pi);
offset = dissect_h245_MultimediaSystemControlMessage(tvb, offset, pinfo ,tr, hf_h245_pdu_type);
tap_queue_packet(h245dg_tap, pinfo, h245_pi);
offset = (offset+0x07) & 0xfffffff8;
@@ -420,7 +421,7 @@
h223_lc_init();
}
-static void reset_h245_packet_info(h245_packet_info *pi)
+static void init_h245_packet_info(h245_packet_info *pi)
{
if(pi == NULL) {
return;
Index: asn1/h245/h245.cnf
===================================================================
--- asn1/h245/h245.cnf (revision 17375)
+++ asn1/h245/h245.cnf (working copy)
@@ -279,7 +279,7 @@
else
g_snprintf(h245_pi->frame_label, 50, "%%s ", val_to_str(value, h245_RequestMessage_short_vals, "UKN"));
- g_snprintf(h245_pi->comment, 50, "%%s %%s ", h245_pi->comment, val_to_str(value, h245_RequestMessage_vals, "<unknown>"));
+ g_strlcat(h245_pi->comment, val_to_str(value, h245_RequestMessage_vals, "<unknown>"), 50);
/* if it is OLC or RM*/
if ((codec_type != NULL) && (( value == 3) || ( value == 8)))
@@ -307,7 +307,8 @@
/* Add to packet info */
g_snprintf(h245_pi->frame_label, 50, "%%s %%s ", h245_pi->frame_label, val_to_str(value, h245_ResponseMessage_short_vals, "UKN"));
- g_snprintf(h245_pi->comment, 50, "%%s %%s ", h245_pi->comment, val_to_str(value, h245_ResponseMessage_vals, "<unknown>"));
+ g_strlcat(h245_pi->comment, val_to_str(value, h245_ResponseMessage_vals, "<unknown>"), 50);
+
#.END
#----------------------------------------------------------------------------------------
#.FN_BODY IndicationMessage VAL_PTR = &value
@@ -330,7 +331,8 @@
col_set_fence(pinfo->cinfo,COL_INFO);
/* Add to packet info */
g_snprintf(h245_pi->frame_label, 50, "%%s %%s ", h245_pi->frame_label, val_to_str(value, h245_IndicationMessage_short_vals, "UKN"));
- g_snprintf(h245_pi->comment, 50, "%%s %%s ", h245_pi->comment, val_to_str(value, h245_IndicationMessage_vals, "<unknown>"));
+ g_strlcat(h245_pi->comment, val_to_str(value, h245_IndicationMessage_vals, "<unknown>"), 50);
+
#.END
#----------------------------------------------------------------------------------------
#.FN_BODY CommandMessage VAL_PTR = &value
@@ -353,7 +355,7 @@
col_set_fence(pinfo->cinfo,COL_INFO);
/* Add to packet info */
g_snprintf(h245_pi->frame_label, 50, "%%s %%s ", h245_pi->frame_label, val_to_str(value, h245_CommandMessage_short_vals, "UKN"));
- g_snprintf(h245_pi->comment, 50, "%%s %%s ", h245_pi->comment, val_to_str(value, h245_CommandMessage_vals, "<unknown>"));
+ g_strlcat(h245_pi->comment, val_to_str(value, h245_CommandMessage_vals, "<unknown>"), 50);
#.END
#----------------------------------------------------------------------------------------
Index: gtk/graph_analysis.c
===================================================================
--- gtk/graph_analysis.c (revision 17375)
+++ gtk/graph_analysis.c (working copy)
@@ -975,8 +975,6 @@
#else
pango_layout_set_text(big_layout, label_string, -1);
pango_layout_get_pixel_size(big_layout, &label_width, &label_height);
-
- label_width = label_height = 0;
#endif
if (start_arrow<end_arrow){
arrow_width = end_arrow-start_arrow;
Index: gtk/voip_calls.c
===================================================================
--- gtk/voip_calls.c (revision 17375)
+++ gtk/voip_calls.c (working copy)
@@ -376,37 +376,27 @@
/* ***************************TAP for RTP Events*****************************/
/****************************************************************************/
+static guint32 rtp_evt_frame_num = 0;
+static guint8 rtp_evt = 0;
+static gboolean rtp_evt_end = FALSE;
+/*static guint32 rtp_evt_setup_frame_num = 0;*/
+
/****************************************************************************/
/* whenever a rtp event packet is seen by the tap listener */
static int
rtp_event_packet(void *ptr _U_, packet_info *pinfo _U_, epan_dissect_t *edt _U_, const void *rtp_event_info)
{
const struct _rtp_event_info *pi = rtp_event_info;
- voip_rtp_tapinfo_t *tapinfo = &the_tapinfo_rtp_struct;
- voip_rtp_stream_info_t *tmp_listinfo;
- voip_rtp_stream_info_t *strinfo = NULL;
- GList* list;
/* do not consider RTP events packets without a setup frame */
if (pi->info_setup_frame_num == 0){
return 0;
}
- /* check wether we already have a RTP stream with this setup frame in the list */
- list = g_list_first(tapinfo->list);
- while (list)
- {
- tmp_listinfo=list->data;
- if ( (tmp_listinfo->setup_frame_number == pi->info_setup_frame_num)
- && (tmp_listinfo->end_stream == FALSE) && (tmp_listinfo->rtp_event == -1)){
- strinfo = (voip_rtp_stream_info_t*)(list->data);
- strinfo->rtp_event = pi->info_rtp_evt;
- break;
- }
- list = g_list_next (list);
- }
+ rtp_evt_frame_num = pinfo->fd->num;
+ rtp_evt = pi->info_rtp_evt;
+ rtp_evt_end = pi->info_end;
-
return 0;
}
@@ -500,9 +490,9 @@
&& (tmp_listinfo->ssrc == pi->info_sync_src) && (tmp_listinfo->end_stream == FALSE)){
/* if the payload type has changed, we mark the stream as finished to create a new one
this is to show multiple payload changes in the Graph for example for DTMF RFC2833 */
- if ( tmp_listinfo->pt != pi->info_payload_type )
+ if ( tmp_listinfo->pt != pi->info_payload_type ) {
tmp_listinfo->end_stream = TRUE;
- else {
+ } else {
strinfo = (voip_rtp_stream_info_t*)(list->data);
break;
}
@@ -510,6 +500,11 @@
list = g_list_next (list);
}
+ /* if this is a duplicated RTP Event End, just return */
+ if ((rtp_evt_frame_num == pinfo->fd->num) && !strinfo && (rtp_evt_end == TRUE)) {
+ return 0;
+ }
+
/* not in the list? then create a new entry */
if (strinfo==NULL){
strinfo = g_malloc(sizeof(voip_rtp_stream_info_t));
@@ -543,6 +538,14 @@
strinfo->npackets++;
strinfo->stop_rel_sec = pinfo->fd->rel_ts.secs;
strinfo->stop_rel_usec = pinfo->fd->rel_ts.nsecs/1000;
+
+ /* process RTP Event */
+ if (rtp_evt_frame_num == pinfo->fd->num) {
+ strinfo->rtp_event = rtp_evt;
+ if (rtp_evt_end == TRUE) {
+ strinfo->end_stream = TRUE;
+ }
+ }
}
the_tapinfo_struct.redraw = TRUE;
@@ -572,13 +575,15 @@
/* using the setup frame number of the RTP stream, we get the call number that it belongs */
voip_calls_graph_list = g_list_first(the_tapinfo_struct.graph_analysis->list);
- item = 0;
while (voip_calls_graph_list)
{
gai = voip_calls_graph_list->data;
conv_num = gai->conv_num;
/* if we get the setup frame number, then get the time position to graph the RTP arrow */
if (rtp_listinfo->setup_frame_number == gai->frame_num){
+ /* look again from the begining because there are cases where the Setup frame is after the RTP */
+ voip_calls_graph_list = g_list_first(the_tapinfo_struct.graph_analysis->list);
+ item = 0;
while(voip_calls_graph_list){
gai = voip_calls_graph_list->data;
/* if RTP was already in the Graph, just update the comment information */
@@ -613,7 +618,6 @@
break;
}
voip_calls_graph_list = g_list_next(voip_calls_graph_list);
- item++;
}
rtp_streams_list = g_list_next(rtp_streams_list);
}
Index: epan/dissectors/packet-h245.c
===================================================================
--- epan/dissectors/packet-h245.c (revision 17375)
+++ epan/dissectors/packet-h245.c (working copy)
@@ -1,6 +1,6 @@
/* Do not modify this file. */
/* It is created automatically by the ASN.1 to Ethereal dissector compiler */
-/* .\packet-h245.c */
+/* ./packet-h245.c */
/* ../../tools/asn2eth.py -X -e -p h245 -c h245.cnf -s packet-h245-template h245.asn */
/* Input file: packet-h245-template.c */
@@ -80,7 +80,7 @@
static dissector_handle_t h263_handle = NULL;
static dissector_handle_t amr_handle = NULL;
-static void reset_h245_packet_info(h245_packet_info *pi);
+static void init_h245_packet_info(h245_packet_info *pi);
static int hf_h245_pdu_type = -1;
static int hf_h245Manufacturer = -1;
static int h245_tap = -1;
@@ -2283,7 +2283,7 @@
static int
dissect_h245_H221NonStandardID(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 682 "h245.cnf"
+#line 684 "h245.cnf"
t35CountryCode = 0;
t35Extension = 0;
manufacturerCode = 0;
@@ -2291,7 +2291,7 @@
offset = dissect_per_sequence(tvb, offset, pinfo, tree, hf_index,
ett_h245_H221NonStandardID, H221NonStandardID_sequence);
-#line 686 "h245.cnf"
+#line 688 "h245.cnf"
h221NonStandard = ((t35CountryCode * 256) + t35Extension) * 65536 + manufacturerCode;
proto_tree_add_uint(tree, hf_h245Manufacturer, tvb, (offset>>3)-4, 4, h221NonStandard);
@@ -2316,7 +2316,7 @@
static int
dissect_h245_NonStandardIdentifier(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 663 "h245.cnf"
+#line 665 "h245.cnf"
guint32 value;
nsiOID = "";
@@ -2351,7 +2351,7 @@
static int
dissect_h245_T_data(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 697 "h245.cnf"
+#line 699 "h245.cnf"
tvbuff_t *next_tvb = NULL;
offset = dissect_per_octet_string(tvb, offset, pinfo, tree, hf_index,
@@ -2377,7 +2377,7 @@
static int
dissect_h245_NonStandardParameter(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 695 "h245.cnf"
+#line 697 "h245.cnf"
nsp_handle = NULL;
offset = dissect_per_sequence(tvb, offset, pinfo, tree, hf_index,
@@ -2507,7 +2507,7 @@
offset = dissect_per_sequence(tvb, offset, pinfo, tree, hf_index,
ett_h245_MasterSlaveDetermination, MasterSlaveDetermination_sequence);
-#line 446 "h245.cnf"
+#line 448 "h245.cnf"
h245_pi->msg_type = H245_MastSlvDet;
@@ -5292,7 +5292,7 @@
dissect_h245_T_standard(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
offset = dissect_per_object_identifier_str(tvb, offset, pinfo, tree, hf_index, &standard_oid_str);
-#line 485 "h245.cnf"
+#line 487 "h245.cnf"
if(!h245_lc_dissector && strcmp(standard_oid_str,"0.0.8.245.1.1.1") == 0)
h245_lc_dissector = amr_handle;
@@ -5648,7 +5648,7 @@
static int
dissect_h245_Application(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 379 "h245.cnf"
+#line 381 "h245.cnf"
guint32 value;
offset = dissect_per_choice(tvb, offset, pinfo, tree, hf_index,
@@ -7542,7 +7542,7 @@
static int
dissect_h245_VideoCapability(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 370 "h245.cnf"
+#line 372 "h245.cnf"
guint32 value;
offset = dissect_per_choice(tvb, offset, pinfo, tree, hf_index,
@@ -7927,7 +7927,7 @@
static int
dissect_h245_AudioCapability(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 361 "h245.cnf"
+#line 363 "h245.cnf"
guint32 value;
offset = dissect_per_choice(tvb, offset, pinfo, tree, hf_index,
@@ -8571,7 +8571,7 @@
offset = dissect_per_sequence(tvb, offset, pinfo, tree, hf_index,
ett_h245_TerminalCapabilitySet, TerminalCapabilitySet_sequence);
-#line 461 "h245.cnf"
+#line 463 "h245.cnf"
h245_pi->msg_type = H245_TermCapSet;
@@ -9879,7 +9879,7 @@
static int
dissect_h245_Ipv4_network(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 497 "h245.cnf"
+#line 499 "h245.cnf"
tvbuff_t *value_tvb;
@@ -9904,7 +9904,7 @@
static int
dissect_h245_TsapIdentifier(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 510 "h245.cnf"
+#line 512 "h245.cnf"
guint32 tsapIdentifier;
offset = dissect_per_constrained_integer(tvb, offset, pinfo, tree, hf_index,
@@ -10223,14 +10223,14 @@
static int
dissect_h245_T_mediaChannel(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 528 "h245.cnf"
+#line 530 "h245.cnf"
media_channel = TRUE;
offset = dissect_h245_TransportAddress(tvb, offset, pinfo, tree, hf_index);
-#line 558 "h245.cnf"
+#line 560 "h245.cnf"
media_channel = FALSE;
@@ -10245,14 +10245,14 @@
static int
dissect_h245_T_mediaControlChannel(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 540 "h245.cnf"
+#line 542 "h245.cnf"
media_control_channel = TRUE;
offset = dissect_h245_TransportAddress(tvb, offset, pinfo, tree, hf_index);
-#line 564 "h245.cnf"
+#line 566 "h245.cnf"
media_control_channel = FALSE;
@@ -10495,7 +10495,7 @@
static int
dissect_h245_OLC_rev_multiplexParameters(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 614 "h245.cnf"
+#line 616 "h245.cnf"
media_channel = FALSE;
@@ -10506,7 +10506,7 @@
ett_h245_OLC_rev_multiplexParameters, OLC_rev_multiplexParameters_choice,
NULL);
-#line 622 "h245.cnf"
+#line 624 "h245.cnf"
if (!pinfo->fd->flags.visited) {
if (codec_type && (strcmp(codec_type, "t38fax")==0)) {
@@ -10815,7 +10815,7 @@
}
-#line 472 "h245.cnf"
+#line 474 "h245.cnf"
if (h245_pi != NULL) h245_pi->msg_type = H245_OpenLogChn;
@@ -10890,7 +10890,7 @@
offset = dissect_per_sequence(tvb, offset, pinfo, tree, hf_index,
ett_h245_CloseLogicalChannel, CloseLogicalChannel_sequence);
-#line 426 "h245.cnf"
+#line 428 "h245.cnf"
h245_pi->msg_type = H245_CloseLogChn;
@@ -11461,7 +11461,7 @@
static int
dissect_h245_VideoMode(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 395 "h245.cnf"
+#line 397 "h245.cnf"
guint32 value;
offset = dissect_per_choice(tvb, offset, pinfo, tree, hf_index,
@@ -11824,7 +11824,7 @@
static int
dissect_h245_AudioMode(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 387 "h245.cnf"
+#line 389 "h245.cnf"
guint32 value;
offset = dissect_per_choice(tvb, offset, pinfo, tree, hf_index,
@@ -11895,7 +11895,7 @@
static int
dissect_h245_DataModeApplication(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 403 "h245.cnf"
+#line 405 "h245.cnf"
guint32 value;
offset = dissect_per_choice(tvb, offset, pinfo, tree, hf_index,
@@ -12989,7 +12989,7 @@
static int
dissect_h245_T_subMessageIdentifer(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 490 "h245.cnf"
+#line 492 "h245.cnf"
guint32 subMessageIdentifer;
@@ -13107,7 +13107,7 @@
else
g_snprintf(h245_pi->frame_label, 50, "%s ", val_to_str(value, h245_RequestMessage_short_vals, "UKN"));
- g_snprintf(h245_pi->comment, 50, "%s %s ", h245_pi->comment, val_to_str(value, h245_RequestMessage_vals, "<unknown>"));
+ g_strlcat(h245_pi->comment, val_to_str(value, h245_RequestMessage_vals, "<unknown>"), 50);
/* if it is OLC or RM*/
if ((codec_type != NULL) && (( value == 3) || ( value == 8)))
@@ -13156,7 +13156,7 @@
offset = dissect_per_sequence(tvb, offset, pinfo, tree, hf_index,
ett_h245_MasterSlaveDeterminationAck, MasterSlaveDeterminationAck_sequence);
-#line 411 "h245.cnf"
+#line 413 "h245.cnf"
h245_pi->msg_type = H245_MastSlvDetAck;
@@ -13200,7 +13200,7 @@
offset = dissect_per_sequence(tvb, offset, pinfo, tree, hf_index,
ett_h245_MasterSlaveDeterminationReject, MasterSlaveDeterminationReject_sequence);
-#line 416 "h245.cnf"
+#line 418 "h245.cnf"
h245_pi->msg_type = H245_MastSlvDetRjc;
@@ -13221,7 +13221,7 @@
offset = dissect_per_sequence(tvb, offset, pinfo, tree, hf_index,
ett_h245_TerminalCapabilitySetAck, TerminalCapabilitySetAck_sequence);
-#line 441 "h245.cnf"
+#line 443 "h245.cnf"
h245_pi->msg_type = H245_TermCapSetAck;
@@ -13297,7 +13297,7 @@
offset = dissect_per_sequence(tvb, offset, pinfo, tree, hf_index,
ett_h245_TerminalCapabilitySetReject, TerminalCapabilitySetReject_sequence);
-#line 451 "h245.cnf"
+#line 453 "h245.cnf"
h245_pi->msg_type = H245_TermCapSetRjc;
@@ -13371,14 +13371,14 @@
static int
dissect_h245_Ack_mediaChannel(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 522 "h245.cnf"
+#line 524 "h245.cnf"
media_channel = TRUE;
offset = dissect_h245_TransportAddress(tvb, offset, pinfo, tree, hf_index);
-#line 546 "h245.cnf"
+#line 548 "h245.cnf"
media_channel = FALSE;
@@ -13393,14 +13393,14 @@
static int
dissect_h245_Ack_mediaControlChannel(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 534 "h245.cnf"
+#line 536 "h245.cnf"
media_control_channel = TRUE;
offset = dissect_h245_TransportAddress(tvb, offset, pinfo, tree, hf_index);
-#line 552 "h245.cnf"
+#line 554 "h245.cnf"
media_control_channel = FALSE;
@@ -13447,7 +13447,7 @@
static int
dissect_h245_T_forwardMultiplexAckParameters(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 570 "h245.cnf"
+#line 572 "h245.cnf"
media_channel = FALSE;
@@ -13458,7 +13458,7 @@
ett_h245_T_forwardMultiplexAckParameters, T_forwardMultiplexAckParameters_choice,
NULL);
-#line 578 "h245.cnf"
+#line 580 "h245.cnf"
if (!pinfo->fd->flags.visited) {
if (codec_type && strcmp(codec_type, "t38fax")==0) {
@@ -13543,7 +13543,7 @@
pinfo->p2p_dir = p2p_dir;
-#line 478 "h245.cnf"
+#line 480 "h245.cnf"
h245_pi->msg_type = H245_OpenLogChnAck;
@@ -13614,7 +13614,7 @@
offset = dissect_per_sequence(tvb, offset, pinfo, tree, hf_index,
ett_h245_OpenLogicalChannelReject, OpenLogicalChannelReject_sequence);
-#line 421 "h245.cnf"
+#line 423 "h245.cnf"
h245_pi->msg_type = H245_OpenLogChnRjc;
@@ -13635,7 +13635,7 @@
offset = dissect_per_sequence(tvb, offset, pinfo, tree, hf_index,
ett_h245_CloseLogicalChannelAck, CloseLogicalChannelAck_sequence);
-#line 431 "h245.cnf"
+#line 433 "h245.cnf"
h245_pi->msg_type = H245_CloseLogChnAck;
@@ -14963,9 +14963,10 @@
/* Add to packet info */
g_snprintf(h245_pi->frame_label, 50, "%s %s ", h245_pi->frame_label, val_to_str(value, h245_ResponseMessage_short_vals, "UKN"));
- g_snprintf(h245_pi->comment, 50, "%s %s ", h245_pi->comment, val_to_str(value, h245_ResponseMessage_vals, "<unknown>"));
+ g_strlcat(h245_pi->comment, val_to_str(value, h245_ResponseMessage_vals, "<unknown>"), 50);
+
return offset;
}
static int dissect_response(tvbuff_t *tvb, int offset, packet_info *pinfo, proto_tree *tree) {
@@ -16144,7 +16145,7 @@
static int
dissect_h245_CommandMessage(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 337 "h245.cnf"
+#line 339 "h245.cnf"
guint32 value;
offset = dissect_per_choice(tvb, offset, pinfo, tree, hf_index,
@@ -16167,7 +16168,7 @@
col_set_fence(pinfo->cinfo,COL_INFO);
/* Add to packet info */
g_snprintf(h245_pi->frame_label, 50, "%s %s ", h245_pi->frame_label, val_to_str(value, h245_CommandMessage_short_vals, "UKN"));
- g_snprintf(h245_pi->comment, 50, "%s %s ", h245_pi->comment, val_to_str(value, h245_CommandMessage_vals, "<unknown>"));
+ g_strlcat(h245_pi->comment, val_to_str(value, h245_CommandMessage_vals, "<unknown>"), 50);
@@ -16214,7 +16215,7 @@
offset = dissect_per_sequence(tvb, offset, pinfo, tree, hf_index,
ett_h245_MasterSlaveDeterminationRelease, MasterSlaveDeterminationRelease_sequence);
-#line 456 "h245.cnf"
+#line 458 "h245.cnf"
h245_pi->msg_type = H245_MastSlvDetRls;
@@ -16234,7 +16235,7 @@
offset = dissect_per_sequence(tvb, offset, pinfo, tree, hf_index,
ett_h245_TerminalCapabilitySetRelease, TerminalCapabilitySetRelease_sequence);
-#line 466 "h245.cnf"
+#line 468 "h245.cnf"
h245_pi->msg_type = H245_TermCapSetRls;
@@ -16255,7 +16256,7 @@
offset = dissect_per_sequence(tvb, offset, pinfo, tree, hf_index,
ett_h245_OpenLogicalChannelConfirm, OpenLogicalChannelConfirm_sequence);
-#line 436 "h245.cnf"
+#line 438 "h245.cnf"
h245_pi->msg_type = H245_OpenLogChnCnf;
@@ -17352,7 +17353,7 @@
static int
dissect_h245_IndicationMessage(tvbuff_t *tvb, int offset, packet_info *pinfo _U_, proto_tree *tree, int hf_index) {
-#line 314 "h245.cnf"
+#line 315 "h245.cnf"
guint32 value;
offset = dissect_per_choice(tvb, offset, pinfo, tree, hf_index,
@@ -17375,9 +17376,10 @@
col_set_fence(pinfo->cinfo,COL_INFO);
/* Add to packet info */
g_snprintf(h245_pi->frame_label, 50, "%s %s ", h245_pi->frame_label, val_to_str(value, h245_IndicationMessage_short_vals, "UKN"));
- g_snprintf(h245_pi->comment, 50, "%s %s ", h245_pi->comment, val_to_str(value, h245_IndicationMessage_vals, "<unknown>"));
+ g_strlcat(h245_pi->comment, val_to_str(value, h245_IndicationMessage_vals, "<unknown>"), 50);
+
return offset;
}
static int dissect_indication(tvbuff_t *tvb, int offset, packet_info *pinfo, proto_tree *tree) {
@@ -17475,6 +17477,7 @@
while ( tvb_length_remaining( tvb, offset>>3 )>0 ){
CLEANUP_PUSH(reset_h245_pi, NULL);
h245_pi=ep_alloc(sizeof(h245_packet_info));
+ init_h245_packet_info(h245_pi);
offset = dissect_h245_MultimediaSystemControlMessage(tvb, offset, pinfo ,tr, hf_h245_pdu_type);
tap_queue_packet(h245dg_tap, pinfo, h245_pi);
offset = (offset+0x07) & 0xfffffff8;
@@ -22906,7 +22909,7 @@
"Rtp/expirationTime", HFILL }},
/*--- End of included file: packet-h245-hfarr.c ---*/
-#line 350 "packet-h245-template.c"
+#line 351 "packet-h245-template.c"
};
/* List of subtrees */
@@ -23389,7 +23392,7 @@
&ett_h245_MobileMultilinkReconfigurationIndication,
/*--- End of included file: packet-h245-ettarr.c ---*/
-#line 356 "packet-h245-template.c"
+#line 357 "packet-h245-template.c"
};
module_t *h245_module;
@@ -23457,7 +23460,7 @@
h223_lc_init();
}
-static void reset_h245_packet_info(h245_packet_info *pi)
+static void init_h245_packet_info(h245_packet_info *pi)
{
if(pi == NULL) {
return;
Index: epan/dissectors/packet-rtp-events.c
===================================================================
--- epan/dissectors/packet-rtp-events.c (revision 17375)
+++ epan/dissectors/packet-rtp-events.c (working copy)
@@ -115,27 +115,33 @@
val_to_str( rtp_evt, rtp_event_type_values, "Unknown (%u)" ));
}
- if ( tree )
- {
- ti = proto_tree_add_item( tree, proto_rtp_events, tvb, offset, -1, FALSE );
- rtp_events_tree = proto_item_add_subtree( ti, ett_rtp_events );
+ ti = proto_tree_add_item( tree, proto_rtp_events, tvb, offset, -1, FALSE );
+ rtp_events_tree = proto_item_add_subtree( ti, ett_rtp_events );
- proto_tree_add_uint ( rtp_events_tree, hf_rtp_events_event, tvb, offset, 1, rtp_evt);
+ proto_tree_add_uint ( rtp_events_tree, hf_rtp_events_event, tvb, offset, 1, rtp_evt);
- octet = tvb_get_guint8(tvb, offset +1 );
- proto_tree_add_boolean (rtp_events_tree, hf_rtp_events_end, tvb, offset+1, 1, octet);
- proto_tree_add_boolean (rtp_events_tree, hf_rtp_events_reserved, tvb, offset+1, 1, octet);
- proto_tree_add_uint ( rtp_events_tree, hf_rtp_events_volume, tvb, offset+1, 1, octet);
+ octet = tvb_get_guint8(tvb, offset +1 );
+ proto_tree_add_boolean (rtp_events_tree, hf_rtp_events_end, tvb, offset+1, 1, octet);
+ proto_tree_add_boolean (rtp_events_tree, hf_rtp_events_reserved, tvb, offset+1, 1, octet);
+ proto_tree_add_uint ( rtp_events_tree, hf_rtp_events_volume, tvb, offset+1, 1, octet);
- proto_tree_add_item ( rtp_events_tree, hf_rtp_events_duration, tvb, offset+2, 2, FALSE);
+ proto_tree_add_item ( rtp_events_tree, hf_rtp_events_duration, tvb, offset+2, 2, FALSE);
- /* Make end-of-event packets obvious in the info column */
- if ((octet & 0x80) && check_col(pinfo->cinfo, COL_INFO))
- {
- col_append_str(pinfo->cinfo, COL_INFO, " (end)");
- }
+ /* set the end info for the tap */
+ if (octet & 0x80)
+ {
+ rtp_event_info.info_end = TRUE;
+ } else
+ {
+ rtp_event_info.info_end = FALSE;
+ }
- }
+ /* Make end-of-event packets obvious in the info column */
+ if ((octet & 0x80) && check_col(pinfo->cinfo, COL_INFO))
+ {
+ col_append_str(pinfo->cinfo, COL_INFO, " (end)");
+ }
+
tap_queue_packet(rtp_event_tap, pinfo, &rtp_event_info);
}
Index: epan/dissectors/packet-rtp-events.h
===================================================================
--- epan/dissectors/packet-rtp-events.h (revision 17375)
+++ epan/dissectors/packet-rtp-events.h (working copy)
@@ -255,5 +255,6 @@
struct _rtp_event_info {
guint8 info_rtp_evt;
guint32 info_setup_frame_num; /* the frame num of the packet that set this RTP connection */
+ gboolean info_end;
};
------------------------------
Message: 6
Date: Thu, 23 Feb 2006 00:44:52 -0500
Subject: RE: [Ethereal-dev] Fallen at the first hurdle :(
Message-ID:
Content-Type: text/plain; charset="us-ascii"
Ulf,
I'd like to start out by first saying that many people know how hard
you've worked not only on the documentation, but on everything else as
well, and although the documentation may seem like a thankless job, it
is certainly appreciated and I'm sure your efforts have helped many more
people than you'll probably ever know.
That said, I'm not quite sure why you seemed to have been so taken aback
by the recent posts that started with Dave Ramsey's inquiry. He seems
like someone who is fairly new to Ethereal and obviously does not have
your level of expertise. I read the chain and did not observe any
whining but rather a simple call for help from the developers in which
he seemed to even be joking at a bit at his own inability to get
started.
And I took Guy's comments as intended to be constructive feedback in
order to try to improve the documentation, not to dictate to you what it
must say. It's my personal feeling that if folks new to Ethereal are
still having trouble getting started, then even though there may be
multiple ways of doing something, new folks are basically looking for a
cook book of exact steps to follow because they just want to get going
quickly in order to solve their own problem and not necessarily to learn
all the ins-and-outs of Ethereal development ... at least not right
away. The easier it is for new people to get started, hopefully the
more productive they'll be and the more interested they'll be in
Ethereal, which will hopefully lead to more of them contributing to its
development in the long run.
On behalf of the many people who have benefited from your work, I hope
that you are only venting some frustrations, that you will not abandon
work on the user's guide and that you will continue to be open to user's
& developer's feedback regarding the documentation, much like a
dissector author might receive comments on ways to improve a particular
protocol dissector. In some sense, it is easier to write Ethereal
dissectors than good documentation because for the dissector,
essentially it works or it doesn't, but the documentation is not
measured by the same criteria.
I'd like to conclude with this: Since August 2003 (which probably makes
me a newbie to most), I have developed over 15 proprietary dissectors
for my company and I maintain them all, some of them quite complex
(unfortunately). When a new Ethereal update is released, I update our
customized version to keep pace. I maintain our own documentation and
our own internal Ethereal group so I can easily disseminate information
to people within the company who are using it, and so they can provide
feedback, report bugs, etc. Many times I have asked for help, but in
the 2.5 years I've been involved, thus far nobody has been able or
willing. I wish others would assist me because I know that some of the
dissectors are lacking, other protocols are yet to be written, and in
some cases I simply can't gather even the test captures I need in order
to fully test the dissectors. Even within my own company it is hard to
get any help or constructive feedback. But regardless, I know that what
I do serves a useful purpose and I enjoy doing it because the work I've
done has helped people and I know it will continue to do so. There are
no rewards for my work; it's not even a funded project. I work on it
mostly in my "spare" time, but I guess the personal satisfaction is why
I do it. I hope it's why you do it as well.
Best regards,
Chris Maynard,
P.S. I know you hate the following disclaimer, but I have no control
over it being added to the outgoing e-mail. For the record, I hate it
too.
-----------------------------------------
This email may contain confidential and privileged material for the
sole use of the intended recipient(s). Any review, use, retention,
distribution or disclosure by others is strictly prohibited. If you
are not the intended recipient (or authorized to receive for the
recipient), please contact the sender by reply email and delete all
copies of this message. Also, email is susceptible to data
corruption, interception, tampering, unauthorized amendment and
viruses. We only send and receive emails on the basis that we are
not liable for any such corruption, interception, tampering,
amendment or viruses or any consequence thereof.
------------------------------
Message: 7
Date: Thu, 23 Feb 2006 07:40:35 +0100
Subject: SV: [Ethereal-dev] Re: Re: Using USER DLT for RNSAP (over
SCCP)
Message-ID: <001301c63844$0ddee1c0$6800a8c0@ditt7huk3o9fm5>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I have done the SCCP reassembly and added the ssn to RNSAP
At least in the first file there is a decoding/encoding error :(
I haven't looked at the new file yet.
Brg
Anders
-----Ursprungligt meddelande-----
Skickat: den 23 februari 2006 00:08
Till: Ethereal development
Dmne: Re: [Ethereal-dev] Re: Re: Using USER DLT for RNSAP (over SCCP)
> > RNSAP does not yet register to SCCP.
> How do you identify RANAP today?
Either because it uses a well known SSN (0x8e) or heuristically by
means of the lenght being right and the opcode (the heuristics fail
sometimes to get ranap packets and sometimes they might interpret as
ranap things that aren't realy ranap, that's heuristic isn't it :-).
> Why can I not force Ethereal to decode RNSAP _unconditionally_ on top of
> SCCP (I thought this is the purpose of these USER DLT, but how?)
Because sccp does not know (yet) even that RNSAP exists . In order to
do so the RNSAP dissector has to register to use an SCCP SSN (don't
worry I'll add it soon).
Even at that point not everything is solved, A problem is that the SSN
appears only in the setup packets of the SCCP "call" so unless your
capture contains these two messages SCCP will try to guess If the
payload is unknown. Theres no heuristics for RNSAP (I don't even know
if some reliable method to guess RNSAP exists, so it's not possible
for me to write it).
User DLT was born with no purpose other than helping me write the K12
rf5 file import. Even if the k12 code did not needed it once finished,
It turned out handy, so I packet it and left it there.
What it does is it takes a USER_DLT (unassigned PCAP encasulation
type) and maps it to an arbitrary protocol optionaly removing some
bytes before and some after. If you have a file that uses one of this
encapsulation types (usually a node's log passed through text2pcap) it
allows you to decode the payloadof the frames.
>
> I see 3 possibilities:
>
> Solution 1
> Both RANAP and RNSAP subscribe to SCCP. The user shall have the chance to
> decide which of the two is chosen on top of SCCP. This then would decode
the
> correctly chosen frames error free and the wrongly chosen frames (most
> likely) with errors. This works fine for every frame (also if no CR/CC is
> present).
Very Ugly.
> Solution 2
> Both RANAP and RNSAP subscribe to SCCP. The decision whether to load the
one
> or the other shall be based on the SSN from the CR message and all
> subsequent CC, DT1, RLSD, RLC within the same <SLR,DLR> shall be treated
> alike.
This one is neat and feasable.
> The problem just remains: What if the SSN is the same (for both RANAP and
> RNSAP). Is that possible? I think so. But then we still have solution 1.
While over a certain association (DPC-OPC) there should be no more
than one SSN per application. There could be someone tat uses the same
ssn for different applications,
However good practice is to use different SSNs for different
Applications even over different associations.
If you find something like that in the field make sure the System
Engineer is transfered to marketing before he causes more damage!!!
:-)
Solution 1 is ugly!
A Protocol preference in RNSAP for telling which SSN to use is a must!
So we go with 2.
As per the heuristics do you have an Idea on how we can guess if
something is RNSAP and not something else?
> Solution 3
> Make a protocol discriminator based on the <opc,dpc> from the SCCP Routing
> Label, but this might be a configuration nightmare. This is by the way
> exactly what the Network Elements are doing (i.e. the MGW)
I think the MGW is at most an STP for RNSAP messages, AFAIK in most
cases the IuR is cross-connected via ATM and as such completely
transparent to the MGw which works only as an ATM switch.
> In my attachment there is 1 IuCS transaction and 1 Iur transaction.
> For IuCS RANAP is used when SSN=142 (frame 1)
> For Iur RNSAP is used when SSN=143 (frame 12)
> If you are interested in Solution 3:
> PCs starting with 3 are RNCs,
> 2107 is the MGC
MGC in regard of the MGw only, MSC for the RNCs I guess.
>
> Any finally: The RNSAP messages are segmented over several DT1 frames
> (frames 16,17,18,19)
Thanks I'll take a look at this.
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
_______________________________________________
Ethereal-dev mailing list
------------------------------
Message: 8
Date: Wed, 22 Feb 2006 23:06:15 -0800
Subject: Re: [Ethereal-dev] The FAQ is pretty much outdated in lot's
of places, could someone remove things no longer interesting?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Ulf Lamping wrote:
> Answering "ancient" questions (about versions more than a year ago)
> which doesn't really appear frequently right now should be simply
> removed IMHO (these are not frequently asked).
Any objections to removing that?
> Some things shouldn't be answered in the FAQ, but should point to other
> places:
>
> "Q1.5 What protocols are currently supported?" Shouldn't list the
> protocols but simply point to the (T)Ethereal output to keep things
> small (this list is more than about half of the entire FAQ page!!!).
> Same applies to the file formats Q1.8. If we don't have a automatically
> generated list of file formats in Ethereal, we might want to add it.
Any objections to removing those?
If no objections, I'll remove them.
------------------------------
Message: 9
Date: Thu, 23 Feb 2006 12:30:37 +0100
Subject: Re: [Ethereal-dev] Fallen at the first hurdle :(
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Maynard, Chris wrote:
> Ulf,
> I'd like to start out by first saying that many people know how hard
> you've worked not only on the documentation, but on everything else as
> well, and although the documentation may seem like a thankless job, it
> is certainly appreciated and I'm sure your efforts have helped many more
> people than you'll probably ever know.
>
It's good to hear that from time to time.
> That said, I'm not quite sure why you seemed to have been so taken aback
> by the recent posts that started with Dave Ramsey's inquiry. He seems
> like someone who is fairly new to Ethereal and obviously does not have
> your level of expertise. I read the chain and did not observe any
> whining but rather a simple call for help from the developers in which
> he seemed to even be joking at a bit at his own inability to get
> started.
>
Actually, Dave said in his mail that he had a look at the devguide, and
then couldn't find the start of the Tools section ?!?
The whining was done in some Mail quite a while ago, and of course it
wasn't actually whining.
> And I took Guy's comments as intended to be constructive feedback in
> order to try to improve the documentation, not to dictate to you what it
> must say.
This wasn't meant to criticize Guy, as he's one of the few people keep
the project going, and helped me several times solving problems.
However, there seems to be a lot of constructive feedback but a lot less
work actually being done.
In parts it sometimes really reminds me of Monty Pythons "Life of Brian" ...
> It's my personal feeling that if folks new to Ethereal are
> still having trouble getting started, then even though there may be
> multiple ways of doing something, new folks are basically looking for a
> cook book of exact steps to follow because they just want to get going
> quickly in order to solve their own problem and not necessarily to learn
> all the ins-and-outs of Ethereal development ... at least not right
> away. The easier it is for new people to get started, hopefully the
> more productive they'll be and the more interested they'll be in
> Ethereal, which will hopefully lead to more of them contributing to its
> development in the long run.
>
Yes, I've noticed that in many other open source projects: "You can use
A, B, or C and when you're very experienced you can even use D".
But no one is giving you a simple way to get a first time running system.
However, I did exactly that by trying to give that advise in the "Win32:
Recommended Tools" section.
That's the catch 22 I tried to explain in my mail. I agree with you to
make things at simple as possible for beginners.
But when you do it that way, some experienced user will tell you: "But
that's not the way it really is, I'm doing..."
So you change it respectively and the next one comes having problems to
understand as there's so much text to read ...
It that actually *can* be quite frustrating ...
> On behalf of the many people who have benefited from your work, I hope
> that you are only venting some frustrations, that you will not abandon
> work on the user's guide and that you will continue to be open to user's
> & developer's feedback regarding the documentation, much like a
> dissector author might receive comments on ways to improve a particular
> protocol dissector. In some sense, it is easier to write Ethereal
> dissectors than good documentation because for the dissector,
> essentially it works or it doesn't, but the documentation is not
> measured by the same criteria.
>
I actually don't know for now. Even after sleeping a night over it, it
still don't seem to be a task that I like to continue.
> I'd like to conclude with this: Since August 2003 (which probably makes
> me a newbie to most), I have developed over 15 proprietary dissectors
> for my company and I maintain them all, some of them quite complex
> (unfortunately). When a new Ethereal update is released, I update our
> customized version to keep pace. I maintain our own documentation and
> our own internal Ethereal group so I can easily disseminate information
> to people within the company who are using it, and so they can provide
> feedback, report bugs, etc. Many times I have asked for help, but in
> the 2.5 years I've been involved, thus far nobody has been able or
> willing. I wish others would assist me because I know that some of the
> dissectors are lacking, other protocols are yet to be written, and in
> some cases I simply can't gather even the test captures I need in order
> to fully test the dissectors. Even within my own company it is hard to
> get any help or constructive feedback. But regardless, I know that what
> I do serves a useful purpose and I enjoy doing it because the work I've
> done has helped people and I know it will continue to do so. There are
> no rewards for my work; it's not even a funded project. I work on it
> mostly in my "spare" time, but I guess the personal satisfaction is why
> I do it. I hope it's why you do it as well.
>
Hmmm, sounds much like the position I'm in, however within my company I
do get at least some constructive feedback,
so my position might be slightly better :-)
However, the personal satisfaction is fading over the last months ...
I know that most of the time you'll only hear the negative side, as
people complain about things they don't like,
and often say nothing about the things they like or which are going well.
So I get your mail as a constructive feedback in the positive sense :-)
> P.S. I know you hate the following disclaimer, but I have no control
> over it being added to the outgoing e-mail. For the record, I hate it
> too.
>
Agreed ;-)
Regards, ULFL
------------------------------
Message: 10
Date: Thu, 23 Feb 2006 14:58:56 +0100 (CET)
Subject: Re: [Ethereal-dev] IPsec dissector to decrypt ESP Payload
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I am not really sure about what you said but here is my answer ;-).
First of all I have added some field in the ESP Preferences to describe
the SAs, the Keys, the Encryption algorithms and the Authentication
algorithms (perhaps for future use for checking authentication... Whatever
if you use the NULL authentication the alignment is different so you have
to precise it).
I understood that you are talking about decryption of ESP in tunnel mode.
Here is one of the more complexe tology I tried (if you have encapsulated
ESP in encapsulated ESP in ... it should work the same).
It is in v4 and I joigned the dump file with the preference file you have
to put in ~/.ethereal
N1 R1 N2
[192.168.0.3] -------[192.168.0.2][10.0.0.1]--------[10.0.0.2]
default route for 192.168.0.3 is 192.168.0.2
There is not default route on 10.0.0.2.
it means that I will received destination unreachable ... Great ;-)
In this case I have the following policies:
########## For 192.168.0.2 (R1)
spdadd 192.168.0.3 10.0.0.2 any -P out ipsec
esp/tunnel/10.0.0.1-10.0.0.2/use;
add 10.0.0.1 10.0.0.2 esp 10
-m tunnel
-E aes-cbc "aescbcencryption"
-A hmac-sha1 "hmacsha1authenticati";
########## For 192.168.0.3 (N1)
spdadd 192.168.0.3 10.0.0.2 any -P out ipsec esp/transport//require;
add 192.168.0.3 10.0.0.2 esp 15
-E des-cbc "descbte"
-A hmac-sha1 "hmacsha1authenticati";
It means that packets coming from N1 to 10.0.0.3 will be encrypted with
des-cbc and tunneled with ESP encryption aes-cbc to N2.
If I have a look into R1, I have these two SAs to decrypt the entire packet.
I will have something like
[IP1][ESP1][ENCRYPTION1]
with [ENCRYPTION1]=[IP2][ESP2][ENCRYPTION2]
and [ENCRYPTION2]=ICMP
IP1 is ip layer from R1 to N2
ENCRYPTION2 is aes-cbc
IP2 is ip layer from N1 to 10.0.0.3
ENCRYPTION2 is des-cbc
thus you have enough information to describe the whole packet.
if you use the preference File in attachment it will do this.
You only have two SAs :
SA #1: IPV4|10.0.0.1|10.0.0.2|*
Encrypt 1 : AES-CBC
Auth 1 : HMAC-SHA1
Encrypt Key 1 : aescbcencryption
SA #2: IPV4|192.168.0.3|10.0.0.2|*
Encrypt 2 : DES-CBC
Auth 2 : HMAC-SHA1
Encrypt Key 2 : descbcte
And as a consequence the Destination Unreachable will also be decrypted,
because SAs are the same.
I hope it was the question,
Best regards,
---
Frederic
> On Wed, Feb 22, 2006 at 05:03:38PM +0100, Frederic Roudaut wrote:
>>
>> Because I received no comment about my dissector, I ask again ;-).
>> Is there any need for my update ? Does anyone plan to use it ?
>
> I quickly browsed through the readme and was not sure where the
> dissector would get the PSK or the private key for the SA from. It
> would be very useful to be able to look 'inside' an IPsec tunnel
> so if there is a mechanism to select a PSK / private key and then
> be able to decrypt the IPSEC traffic I do think I will use it
> some times.
>
> I do believe it's necessary to capture from the setup of the
> SA's to be able to do so, which might limit it's usefullness
> in the real world (unless you're able to restart the tunnel
> of course).
>
> Still, I personally would definately like this functionality
> to be available in the official releases :)
>
>
> Cheers, Sake
>
> _______________________________________________
> Ethereal-dev mailing list
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: capture_v4_ipsec2.pcap
Type: application/octet-stream
Size: 157639 bytes
Desc: not available
Url : /pipermail/attachments/20060223/7f78a3a8/capture_v4_ipsec2.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: preferences
Type: application/octet-stream
Size: 87640 bytes
Desc: not available
Url : /pipermail/attachments/20060223/7f78a3a8/preferences.obj
------------------------------
_______________________________________________
Ethereal-dev mailing list
End of Ethereal-dev Digest, Vol 34, Issue 36
******************************************** | 
