[Ethereal-dev] Core dump in current gsm-sms-ud dissector
Biot Olivier
Current "gsm-sms-ud" dissector causes a crash on a reference capture I =
have
(funny it didn't crash yesterday when I committed a SMPP patch). I =
think the
gsm-sms-ud protocol registration is the cause (handle =3D 0x0). As I =
don't
have the time right now, could someone else have a look?
Regards,
Olivier
GNU gdb 2003-09-20-cvs (cygwin-special)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and =
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for =
details.
This GDB was configured as "i686-pc-cygwin"...
(gdb) r
Starting program:
/home/Administrator/Ethereal/cvs/ethereal-pcre/ethereal.exe -r
/home/be322008/Desktop/Snoops/BigCap.snoop
Program received signal SIGSEGV, Segmentation fault.
0x00a8e5af in call_dissector_work (handle=3D0x0, tvb=3D0x10defe60,=20
pinfo=3D0x10e05c18, tree=3D0x10425b48) at packet.c:403
403 if (handle->protocol !=3D NULL &&
(gdb) bt full
#0 0x00a8e5af in call_dissector_work (handle=3D0x0, tvb=3D0x10defe60,=20
pinfo=3D0x10e05c18, tree=3D0x10425b48) at packet.c:403
saved_proto =3D 0x610e2707
"\213M\b)Y\b\001\031\211=FB\001]=F0)=DF\213U\f\213B\b)=D8\205=C0\211B\b\=
017\204g=FF=FF=FF\21
3U\b\205=FF\017=B7B\fu\234=EB\212\213\032\213B\020)=C3\211\004$\215\f\03=
7\211M=E4\211L
$\004=E8=D1)=F7=FF\205=C0\017\204=3D=FF=FF=FF\213U\b\213M=E4\211B\020\00=
1=D8\211=FB\211\002\211J\024
\211z\b=E9x=FF=FF=FF\213U\b\213\002;B\020v\0049=DFwS\213U\b\213Z\0249=DF=
r'\211\\$\b\213M
=F0\211L$\004\213B =
\211\004$=FFR(\205=C0\211=C3\017\217j=FF=FF=FF=E9=E8=FE=FF=FF\215t&"
saved_can_desegment =3D 50824
ret =3D 10357596
save_writable =3D 2284280
save_dl_src =3D {type =3D 283049568, len =3D 0,=20
data =3D 0x15934d4 =
"\211X\004\211=F0\215e=F8[^]=C3\211=D8=EB=F5U\211=E5=E8=C8\006"}
save_dl_dst =3D {type =3D 269763144, len =3D 4096,=20
data =3D 0x9e0aea "[Illegal %s]"}
save_net_src =3D {type =3D 282274976, len =3D 6,=20
data =3D 0x21 <Address 0x21 out of bounds>}
save_net_dst =3D {type =3D 128, len =3D 189, data =3D 0x10defe60 ""}
save_src =3D {type =3D AT_NONE, len =3D 1,=20
data =3D 0x9e08fd "Frame: %u, payload: %u-%u"}
save_dst =3D {type =3D 272766776, len =3D 4349, data =3D 0x10defe60 =
""}
saved_proto =3D 0x610e2707
"\213M\b)Y\b\001\031\211=FB\001]=F0)=DF\213U\f\213B\b)=D8\205=C0\211B\b\=
017\204g=FF=FF=FF\21
3U\b\205=FF\017=B7B\fu\234=EB\212\213\032\213B\020)=C3\211\004$\215\f\03=
7\211M=E4\211L
$\004=E8=D1)=F7=FF\205=C0\017\204=3D=FF=FF=FF\213U\b\213M=E4\211B\020\00=
1=D8\211=FB\211\002\211J\024
\211z\b=E9x=FF=FF=FF\213U\b\213\002;B\020v\0049=DFwS\213U\b\213Z\0249=DF=
r'\211\\$\b\213M
=F0\211L$\004\213B =
\211\004$=FFR(\205=C0\211=C3\017\217j=FF=FF=FF=E9=E8=FE=FF=FF\215t&"
saved_can_desegment =3D 50824
ret =3D 10357596
save_writable =3D 2284280
save_dl_src =3D {type =3D 283049568, len =3D 0,=20
data =3D 0x15934d4 =
"\211X\004\211=F0\215e=F8[^]=C3\211=D8=EB=F5U\211=E5=E8=C8\006"}
save_dl_dst =3D {type =3D 269763144, len =3D 4096,=20
data =3D 0x9e0aea "[Illegal %s]"}
save_net_src =3D {type =3D 282274976, len =3D 6,=20
data =3D 0x21 <Address 0x21 out of bounds>}
save_net_dst =3D {type =3D 128, len =3D 189, data =3D 0x10defe60 ""}
save_src =3D {type =3D AT_NONE, len =3D 1,=20
data =3D 0x9e08fd "Frame: %u, payload: %u-%u"}
save_dst =3D {type =3D 272766776, len =3D 4349, data =3D 0x10defe60 =
""}
#1 0x00a903bf in call_dissector (handle=3D0x0, tvb=3D0x10defe60,=20
pinfo=3D0x10e05c18, tree=3D0x10425b48) at packet.c:1596
handle =3D 0x0
tvb =3D (tvbuff_t *) 0x10defe60
pinfo =3D (packet_info *) 0x10e05c18
tree =3D (proto_tree *) 0x10425b48
ret =3D 0
#2 0x0061e536 in parse_gsm_sms_ud_message (sm_tree=3D0x10ce51f0,=20
tvb=3D0x10defe2c, pinfo=3D0x10e05c18, top_tree=3D0x10425b48)
at packet-gsm_sms_ud.c:385
sm_tvb =3D (tvbuff_t *) 0x10defe60
subtree =3D (proto_item *) 0x10427750
tree =3D (proto_item *) 0x104279a8
udh_len =3D 11 '\v'
udh =3D 96 '`'
len =3D 3 '\003'
sm_len =3D 63
sm_data_len =3D 283049568
i =3D 283139096
is_fragmented =3D 1
fd_sm =3D (fragment_data *) 0x0
sm_id =3D 0
frags =3D 2
frag =3D 2
save_fragmented =3D 0
try_gsm_sms_ud_reassemble =3D 1
reassembled =3D 1
reassembled_in =3D 12789
p_src =3D 49154
p_dst =3D 49999
ports_available =3D 1
#3 0x0061ebc8 in dissect_gsm_sms_ud (tvb=3D0x10defe2c, =
pinfo=3D0x10e05c18,=20
tree=3D0x10425b48) at packet-gsm_sms_ud.c:423
tvb =3D (tvbuff_t *) 0x10425b48
pinfo =3D (packet_info *) 0x0
tree =3D (proto_tree *) 0x10defe60
ti =3D (proto_item *) 0x0
subtree =3D (proto_tree *) 0x0
#4 0x00a8e571 in call_dissector_through_handle (handle=3D0x10088638,=20
tvb=3D0x10defe2c, pinfo=3D0x10e05c18, tree=3D0x10425b48) at =
packet.c:363
handle =3D 0x10defe60
tvb =3D (tvbuff_t *) 0x10defe2c
pinfo =3D (packet_info *) 0x10425b48
saved_proto =3D 0x61f292 "GSM SMS UD"
ret =3D 0
#5 0x00a8e8f0 in call_dissector_work (handle=3D0x10088638, =
tvb=3D0x10defe2c,=20
pinfo=3D0x10e05c18, tree=3D0x10425b48) at packet.c:513
saved_proto =3D 0x90c9a4 "SMPP"
saved_can_desegment =3D 1
ret =3D 283049540
save_writable =3D 0
save_dl_src =3D {type =3D 283049464, len =3D 283049516,=20
data =3D 0x22ca98 "=C8=CA\""}
save_dl_dst =3D {type =3D AT_NONE, len =3D 283049516,=20
data =3D 0x10defe2c "\001"}
save_net_src =3D {type =3D 2280008, len =3D 22623468,=20
data =3D 0x22ca68 "\230=CA\""}
save_net_dst =3D {type =3D 283049464, len =3D 74, data =3D 0x22ca68
"\230=CA\""}
save_src =3D {type =3D 283049544, len =3D 2280036,=20
data =3D 0x1 <Address 0x1 out of bounds>}
save_dst =3D {type =3D 283049464, len =3D 39,=20
data =3D 0x4a <Address 0x4a out of bounds>}
saved_proto =3D 0x90c9a4 "SMPP"
saved_can_desegment =3D 1
ret =3D 283049540
save_writable =3D 0
save_dl_src =3D {type =3D 283049464, len =3D 283049516,=20
data =3D 0x22ca98 "=C8=CA\""}
save_dl_dst =3D {type =3D AT_NONE, len =3D 283049516,=20
data =3D 0x10defe2c "\001"}
save_net_src =3D {type =3D 2280008, len =3D 22623468,=20
data =3D 0x22ca68 "\230=CA\""}
save_net_dst =3D {type =3D 283049464, len =3D 74, data =3D 0x22ca68
"\230=CA\""}
save_src =3D {type =3D 283049544, len =3D 2280036,=20
data =3D 0x1 <Address 0x1 out of bounds>}
save_dst =3D {type =3D 283049464, len =3D 39,=20
data =3D 0x4a <Address 0x4a out of bounds>}
#6 0x00a903bf in call_dissector (handle=3D0x10088638, =
tvb=3D0x10defe2c,=20
pinfo=3D0x10e05c18, tree=3D0x10425b48) at packet.c:1596
handle =3D 0x0
tvb =3D (tvbuff_t *) 0x10defe2c
pinfo =3D (packet_info *) 0x10e05c18
tree =3D (proto_tree *) 0x10425b48
ret =3D 0
#7 0x0090b987 in submit_sm (tree=3D0x10ce50a0, tvb=3D0x10defdf8,=20
pinfo=3D0x10e05c18, top_tree=3D0x10425b48) at packet-smpp.c:1404
tvb =3D (tvbuff_t *) 0x10e05c18
top_tree =3D (proto_tree *) 0x0
tvb_msg =3D (tvbuff_t *) 0x0
offset =3D 39
flag =3D 0 '\0'
udhi =3D 64 '@'
length =3D 74 'J'
src_str =3D 0x10e1f610 "32477200179"
dst_str =3D 0x10e1f630 "32476471861"
save_src =3D {type =3D AT_IPv4, len =3D 4, data =3D 0x10e1f650 =
"=AC\020\v}"}
save_dst =3D {type =3D AT_IPv4, len =3D 4, data =3D 0x10e1f660
"=AC\021\003\006"}
#8 0x0090cccc in dissect_smpp_pdu (tvb=3D0x10defd90, =
pinfo=3D0x10e05c18,=20
tree=3D0x10425b48) at packet-smpp.c:1918
tmp_tvb =3D (tvbuff_t *) 0x0
pdu_tvb =3D (tvbuff_t *) 0x10defe2c
tvb =3D (tvbuff_t *) 0x10defe2c
command_length =3D 129
command_id =3D 4
command_status =3D 0
sequence_number =3D 2
command_str =3D (gchar *) 0x9071b2 "Submit_sm"
command_status_str =3D (gchar *) 0x0
ti =3D (proto_item *) 0x10ce50a0
smpp_tree =3D (proto_tree *) 0x10ce50a0
#9 0x0094810a in tcp_dissect_pdus (tvb=3D0x10defcf4, =
pinfo=3D0x10e05c18,=20
tree=3D0x10425b48, proto_desegment=3D0, fixed_len=3D16,=20
get_pdu_len=3D0x90c830 <get_smpp_pdu_len>,=20
dissect_pdu=3D0x90c9d0 <dissect_smpp_pdu>) at packet-tcp.c:1989
except_sn =3D {except_down =3D 0x22ceb0, except_type =3D =
XCEPT_CATCHER,=20
except_info =3D {except_catcher =3D 0x22cbb0, except_cleanup =3D =
0x22cbb0}}
except_ch =3D {except_id =3D 0x947f48, except_size =3D 1, except_obj =
=3D {
except_id =3D {except_group =3D 4, except_code =3D 283049204},=20
except_message =3D 0x10defcf4 "\001", except_dyndata =3D 0x0}, =
except_jmp =3D
{
2280392, 129, 2280608, 2280608, 0, 0, 2280664, 2280336, 9732201,
3670051,=20
2293760, 129, 2280504, 11119404, 272135670, 129, 32, 2280484, =
2280488,
0,=20
-1, 2280492, 539151408, 0, 0, 269553448, 269543640, 2280685, =
2280552,=20
9103820, 283049204, 0, -1, 283049204, 2280672, 2280620, 2280584,
11112344,=20
283049204, 8, 4, 2280620, 2280624, 2280672, 2280664, 283049204,
269543736,=20
2, 2280632, 11116599, 283049204, 8}}
exc =3D (except_t *) 0x1
catch_spec =3D {{except_group =3D 1, except_code =3D 0}}
offset =3D 0
offset_before =3D 0
length_remaining =3D 129
plen =3D 129
length =3D 0
next_tvb =3D (tvbuff_t *) 0x10defd90
#10 0x0090c91f in dissect_smpp (tvb=3D0x10defcf4, pinfo=3D0x10e05c18,=20
tree=3D0x10425b48) at packet-smpp.c:1681
tvb =3D (tvbuff_t *) 0x10defcf4
offset =3D 269543736
#11 0x0090c81f in dissect_smpp_heur (tvb=3D0x10defcf4, =
pinfo=3D0x10e05c18,=20
tree=3D0x10425b48) at packet-smpp.c:1656
tvb =3D (tvbuff_t *) 0x10defcf4
pinfo =3D (packet_info *) 0x0
tree =3D (proto_tree *) 0x0
command_id =3D 0
command_status =3D 0
command_length =3D 0
#12 0x00a8fd96 in dissector_try_heuristic (sub_dissectors=3D0x100f1250, =
tvb=3D0x10defcf4, pinfo=3D0x10e05c18, tree=3D0x10425b48) at =
packet.c:1449
status =3D 0
saved_proto =3D 0x947827 "TCP"
entry =3D (GSList *) 0x1010e938
dtbl_entry =3D (heur_dtbl_entry_t *) 0x10defcf4
saved_can_desegment =3D 2
status =3D 0
saved_proto =3D 0x947827 "TCP"
#13 0x00948b50 in decode_tcp_ports (tvb=3D0x10defcc0, offset=3D20,=20
pinfo=3D0x10e05c18, tree=3D0x10425b48, src_port=3D55405, =
dst_port=3D8100)
at packet-tcp.c:2308
tvb =3D (tvbuff_t *) 0x0
offset =3D 0
pinfo =3D (packet_info *) 0x10e05c18
dst_port =3D 55405
next_tvb =3D (tvbuff_t *) 0x10defcf4
low_port =3D 0
high_port =3D 55405
#14 0x00948cde in process_tcp_payload (tvb=3D0x10defcc0, offset=3D20,=20
pinfo=3D0x10e05c18, tree=3D0x10425b48, tcp_tree=3D0x104259f8, =
src_port=3D55405,=20
dst_port=3D8100, nxtseq=3D0, is_tcp_segment=3D0) at =
packet-tcp.c:2333
except_sn =3D {except_down =3D 0x22d630, except_type =3D =
XCEPT_CATCHER,=20
except_info =3D {except_catcher =3D 0x22cdc0, except_cleanup =3D =
0x22cdc0}}
except_ch =3D {except_id =3D 0x948c28, except_size =3D 1, except_obj =
=3D {
except_id =3D {except_group =3D 1907106356, except_code =3D 0},=20
except_message =3D 0x103f8400 "t1=B3", except_dyndata =3D 0x0}, =
except_jmp =3D {
2280920, 2281424, 2281136, 2281136, 0, 283139096, 2281176, 2280864, =
9735279, 3670051, 2293760, 12537496, 2281112, 1628311491, 2290256,=20
2280992, 9732433, 2281188, 269763222, 14451, 4017, 283049152, =
272169624,
283049152, 2281080, 11089326, 272169656, 0, 1, 1627983033, 2281104, =
0,=20
2281096, 11158956, 272168256, 9, 2281112, 11158956, 281926832,
283140328,=20
2281144, 1627738564, 272168224, 283049152, 2281160, 11089326, =
272168256,
269763144, 1628240464, 4033, 4096, 12537496}}
exc =3D (except_t *) 0x0
catch_spec =3D {{except_group =3D 1, except_code =3D 0}}
#15 0x00947f12 in desegment_tcp (tvb=3D0x10e05c18, pinfo=3D0x10425b48,=20
offset=3D272783864, seq=3D55405, nxtseq=3D8100, sport=3D0, =
dport=3D0, tree=3D0x15a6,
tcp_tree=3D0x10defcc0) at packet-tcp.c:1559
pinfo =3D (packet_info *) 0x10e05c18
tcpinfo =3D (struct tcpinfo *) 0x0
ipfd_head =3D (fragment_data *) 0xbf4e98
old_tsk =3D {src =3D 0x22cf38, dst =3D 0x0, seq =3D 2283056, sport =3D =
1,=20
dport =3D 0, start_seq =3D 2280896, tot_len =3D 2281176, first_frame =
=3D 22525788}
tsk =3D (tcp_segment_key *) 0x0
must_desegment =3D 4096
called_dissector =3D 4033
deseg_offset =3D 1628240464
deseg_seq =3D 269763144
nbytes =3D 0
#16 0x00000014 in ?? ()
No symbol table info available.
#17 0x10e05c18 in ?? ()
No symbol table info available.
#18 0x10425b48 in ?? ()
No symbol table info available.
#19 0x104259f8 in ?? ()
No symbol table info available.
#20 0x0000d86d in ?? ()
No symbol table info available.
#21 0x00001fa4 in ?? ()
No symbol table info available.
(gdb) print *(pinfo->fd)
$1 =3D {next =3D 0x0, prev =3D 0x10ddd938, pfd =3D 0x0, num =3D 12789, =
pkt_len =3D 183,=20
cap_len =3D 183, cul_bytes =3D 5659137, rel_secs =3D 12263991, =
rel_usecs =3D
304677,=20
abs_secs =3D 1050582763, abs_usecs =3D 887462, del_secs =3D 0, =
del_usecs =3D 906,=20
file_off =3D 5982796, lnk_t =3D 1, flags =3D {passed_dfilter =3D 0, =
encoding =3D 0,=20
visited =3D 0, marked =3D 0, ref_time =3D 0}, color_filter =3D 0x0}
(gdb) q
_______________________________________________
Ethereal-dev mailing list
Ethere...@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev
Chris Wilson
Hi Olivier,
> Current "gsm-sms-ud" dissector causes a crash on a reference capture I
> have(funny it didn't crash yesterday when I committed a SMPP patch). I
> think the gsm-sms-ud protocol registration is the cause (handle = 0x0).
> As I don't have the time right now, could someone else have a look?
This is my fault, missed a bit whilst pulling GSM SMS UD from the SMPP code. You'll only see that problem if you have the option to pass all UDH with a port onto the WSP dissector (aside: shouldn't that option be in the WSP dissector?)
Fix is:
RCS file: /cvsroot/ethereal/packet-gsm_sms_ud.c,v
retrieving revision 1.3
diff -r1.3 packet-gsm_sms_ud.c
613a627,629
>
> wsp_handle = find_dissector("wsp-cl");
> g_assert (wsp_handle);
Cheers,
Chris
--
Chris Wilson <ch...@mxtelecom.com>
http://www.mxtelecom.com
Olivier Biot
| Hi Olivier,
|
| > Current "gsm-sms-ud" dissector causes a crash on a reference
capture I
| > have(funny it didn't crash yesterday when I committed a SMPP
patch). I
| > think the gsm-sms-ud protocol registration is the cause (handle =
0x0).
| > As I don't have the time right now, could someone else have a
look?
|
| This is my fault, missed a bit whilst pulling GSM SMS UD from the
| SMPP code. You'll only see that problem if you have the option to
| pass all UDH with a port onto the WSP dissector
Correct.
| (aside: shouldn't that option be in the WSP dissector?)
That option relates to GSM SMS User Data containing a
Ports IE with 16-bit ports. The WSP dissector does not
know about an UDH.
| Fix is:
|
| RCS file: /cvsroot/ethereal/packet-gsm_sms_ud.c,v
| retrieving revision 1.3
| diff -r1.3 packet-gsm_sms_ud.c
| 613a627,629
| >
| > wsp_handle = find_dissector("wsp-cl");
| > g_assert (wsp_handle);
Checked in, along with the removal of the email address as suggested
by today's postings.
Regards,
Olivier
Chris Wilson
--Multipart_Tue__27_Jan_2004_19:10:59_+0000_11d0f0c0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hi Olivier,
On Tue, 27 Jan 2004 18:17:58 +0100
"Olivier Biot" <ethe...@tiscali.be> wrote:
> | Fix is:
> |
> | RCS file: /cvsroot/ethereal/packet-gsm_sms_ud.c,v
> | retrieving revision 1.3
> | diff -r1.3 packet-gsm_sms_ud.c
> | 613a627,629
> | >
> | > wsp_handle = find_dissector("wsp-cl");
> | > g_assert (wsp_handle);
>
> Checked in, along with the removal of the email address as suggested
> by today's postings.
Thanks. Latest mini-patch attached...
It adds the option to prevent GSM SMS UD dissector allowing subdissectors to change the columns in the GUI. Reason for this, if I have a single TCP packet containing 4 Submit_sm's they'll be displayed as:
PROTOCOL INFO
SMPP SMPP Submit_sm, Submit_sm, Submit_sm, Submit_sm
However if the second Submit_sm is a WAP PUSH then the packet will show as:
PROTOCOL INFO
WSP WSP Push (WBXML 1.2, Public ID: "-//WAPFORUM//DTD SI...
And we'll lose the information in the INFO column about the other Submit_sm PDU's in the TCP packet.
Cheers,
Chris
--
Chris Wilson <ch...@mxtelecom.com>
http://www.mxtelecom.com
--Multipart_Tue__27_Jan_2004_19:10:59_+0000_11d0f0c0
Content-Type: application/octet-stream;
name="gsm_sms_ud-col-patch.diff"
Content-Disposition: attachment;
filename="gsm_sms_ud-col-patch.diff"
Content-Transfer-Encoding: base64
SW5kZXg6IHBhY2tldC1nc21fc21zX3VkLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2N2c3Jvb3Qv
ZXRoZXJlYWwvcGFja2V0LWdzbV9zbXNfdWQuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS40CmRp
ZmYgLXIxLjQgcGFja2V0LWdzbV9zbXNfdWQuYwoxMzhhMTM5LDE0MAo+IC8qIFByZXZlbnQgc3Vi
ZGlzc2VjdG9ycyBjaGFuZ2luZyBjb2x1bW4gZGF0YSAqLwo+IHN0YXRpYyBnYm9vbGVhbiBwcmV2
ZW50X3N1YmRpc3NlY3RvcnNfY2hhbmdpbmdfY29sdW1ucyA9IEZBTFNFOwoyMTUsMjE3ZDIxNgo8
ICNpZmRlZiBERUJVRwo8IHByaW50ZigidWRobGVuICVkXG4iLCB1ZGhfbGVuKTsKPCAjZW5kaWYK
MjI4ZDIyNgo8IAkJCQkJaXNfZnJhZ21lbnRlZCA9IFRSVUU7CjIzMWEyMzAsMjMxCj4gCQkJCQlp
ZihmcmFncz4xKQo+IAkJCQkJCWlzX2ZyYWdtZW50ZWQgPSBUUlVFOwoyNTNkMjUyCjwgCQkJCQlp
c19mcmFnbWVudGVkID0gVFJVRTsKMjU2YTI1NiwyNTcKPiAJCQkJCWlmKGZyYWdzPjEpCj4gCQkJ
CQkJaXNfZnJhZ21lbnRlZCA9IFRSVUU7CjM4NmEzODgsMzkzCj4gCQkJCWdib29sZWFuIGFsbG93
X3dyaXRlID0gRkFMU0U7Cj4gCQkJCWlmICggcHJldmVudF9zdWJkaXNzZWN0b3JzX2NoYW5naW5n
X2NvbHVtbnMgJiYgY29sX2dldF93cml0YWJsZShwaW5mby0+Y2luZm8pICkgewo+IAkJCQkJYWxs
b3dfd3JpdGUgPSBUUlVFOwo+IAkJCQkJY29sX3NldF93cml0YWJsZShwaW5mby0+Y2luZm8sIEZB
TFNFKTsKPiAJCQkJfQkJCQkKPiAKNDAwYTQwOCw0MTAKPiAJCQkJCj4gCQkJCWlmKCBhbGxvd193
cml0ZSApCj4gCQkJCQljb2xfc2V0X3dyaXRhYmxlKHBpbmZvLT5jaW5mbywgVFJVRSk7CjYwM2E2
MTQsNjE4Cj4gICAgIHByZWZzX3JlZ2lzdGVyX2Jvb2xfcHJlZmVyZW5jZSAoZ3NtX3Ntc191ZF9t
b2R1bGUsICJwcmV2ZW50X2Rpc3NlY3RvcnNfY2hnX2NvbHMiLAo+ICAgICAJICAgICJQcmV2ZW50
IHN1Yi1kaXNzZWN0b3JzIGZyb20gY2hhbmdpbmcgY29sdW1uIGRhdGEiLAo+IAkgICAgIlByZXZl
bnQgc3ViLWRpc3NlY3RvcnMgZnJvbSByZXBsYWNpbmcgY29sdW1uIGRhdGEgd2l0aCB0aGVpciAi
Cj4gCSAgICAib3duLiBFZy4gUHJldmVudCBXU1AgZGlzc2VjdG9yIG92ZXJ3cml0aW5nIFNNUFAg
aW5mb3JtYXRpb24uIiwKPiAJICAgICZwcmV2ZW50X3N1YmRpc3NlY3RvcnNfY2hhbmdpbmdfY29s
dW1ucyk7CjYxNmE2MzIKPiAJCQkK
--Multipart_Tue__27_Jan_2004_19:10:59_+0000_11d0f0c0
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Ethereal-dev mailing list
Ethere...@ethereal.com
http://www.ethereal.com/mailman/listinfo/ethereal-dev
--Multipart_Tue__27_Jan_2004_19:10:59_+0000_11d0f0c0--
Olivier Biot
Could you generate an *unified* diff (diff -u) against the current CVS
version?
Your patch somehow gets mangled.
Regards,
Olivier
----- Original Message -----
From: "Chris Wilson"
|
| Hi Olivier,
|
| On Tue, 27 Jan 2004 18:17:58 +0100 "Olivier Biot" wrote:
|
| > | Fix is:
| > |
| > | RCS file: /cvsroot/ethereal/packet-gsm_sms_ud.c,v
| > | retrieving revision 1.3
| > | diff -r1.3 packet-gsm_sms_ud.c
| > | 613a627,629
| > | >
| > | > wsp_handle = find_dissector("wsp-cl");
| > | > g_assert (wsp_handle);
| >
| > Checked in, along with the removal of the email address as
suggested
| > by today's postings.
|
| Thanks. Latest mini-patch attached...
|
| It adds the option to prevent GSM SMS UD dissector allowing
subdissectors to change the columns in the GUI. Reason for this, if I
have a single TCP packet containing 4 Submit_sm's they'll be displayed
as:
|
| PROTOCOL INFO
| SMPP SMPP Submit_sm, Submit_sm, Submit_sm, Submit_sm
|
| However if the second Submit_sm is a WAP PUSH then the packet will
show as:
|
| PROTOCOL INFO
| WSP WSP Push (WBXML 1.2, Public ID: "-//WAPFORUM//DTD SI...
|
| And we'll lose the information in the INFO column about the other
Submit_sm PDU's in the TCP packet.
Olivier Biot
From: "Chris Wilson"
| Hi,
|
| On Tue, 27 Jan 2004 22:47:09 +0100 "Olivier Biot" wrote:
|
| > Could you generate an *unified* diff (diff -u) against the current
CVS
| > version?
| > Your patch somehow gets mangled.
|
| Apologies.... see attached.
Checked in, but I renamed allow_write to disallow_write.
There is however a bug somewhere in the reassembly code as when
disallowing subdissectors to set the columns I get an "[Illegal Short
Message fragments] (Short Message Reassembled)" entry in the summary
column in a *forged* capture where I accidentally merged three
identical SMPP captures with mergecap; the error is visible only on
the 1st reassembled packet's summary line. Looking in the Short
Message fragments subtree, I see that the reassembly code reports
conflicting overlapping data, however the tvb_subsets do not overlap
(but one gets replicated twice because of the accidental
triple-merger).
Regards,
Olivier
Guy Harris
> There is however a bug somewhere in the reassembly code as when
> disallowing subdissectors to set the columns I get an "[Illegal Short
> Message fragments] (Short Message Reassembled)" entry in the summary
> column in a *forged* capture where I accidentally merged three
> identical SMPP captures with mergecap; the error is visible only on
> the 1st reassembled packet's summary line. Looking in the Short
> Message fragments subtree, I see that the reassembly code reports
> conflicting overlapping data, however the tvb_subsets do not overlap
> (but one gets replicated twice because of the accidental
> triple-merger).
Can you send that forged capture?
Guy Harris
> There is however a bug somewhere in the reassembly code as when
> disallowing subdissectors to set the columns I get an "[Illegal Short
> Message fragments] (Short Message Reassembled)" entry in the summary
> column in a *forged* capture where I accidentally merged three
> identical SMPP captures with mergecap; the error is visible only on
> the 1st reassembled packet's summary line. Looking in the Short
> Message fragments subtree, I see that the reassembly code reports
> conflicting overlapping data,
Not in the capture you sent me - it reports overlaps, but not
conflicting overlaps.
> however the tvb_subsets do not overlap
Yes, they do - in the capture you sent me, there are 3 copies of each of
the packets, and the 3 copies of the first fragment overlap.
> (but one gets replicated twice because of the accidental
> triple-merger).
It can't tell that they were replicated as a result of that.
The second and third instances of the second fragment are treated as new
fragments - the first instance completes the reassembly, and the data
structure for the in-progress reassembly is replaced by a data structure
for a completed reassembly.
Part of the problem is that the reassembly code, if it reports fragment
errors, sets the column string, rather than appending to it. Perhaps it
should append to the string, instead.
(BTW, should the "col_append_*str" routines take a "char *" argument
that, if not null, is appended to the string before appending the new
text if the string is not empty, so that you can put in a space, or ";",
or "; ", or... to separate the new item from any existing items without
that item showing up at the beginning of the column? The same might
apply to "proto_item_append_text()", and possibly even
"proto_item_append_string()".)