Hi list!
It turns out that packet-ssh.c loops forever if the first packets
are short frames (the announced TCP payload is bigger than the real
captured payload, for example because one forgot to -s 65535 with
tcpdump :).
Attached patch replaces the tvb_reported_length_remaining calls with
tvb_ensure_length_remaining calls, and fixes the problem here.
As a side note, I'm not sure packet-ssh.c takes all cases in account,
for example my first workaround was to add an else block at line 329,
now it seems this isn't needed anymore but I did not check all possible
cases.
--
Loïc Minier <lool@xxxxxxxx>
Index: packet-ssh.c
===================================================================
RCS file: /cvsroot/ethereal/packet-ssh.c,v
retrieving revision 1.7
diff -u -r1.7 packet-ssh.c
--- packet-ssh.c 17 Apr 2003 07:39:18 -0000 1.7
+++ packet-ssh.c 18 Dec 2003 19:01:17 -0000
@@ -295,7 +295,7 @@
return;
}
- while((remain_length = tvb_reported_length_remaining(tvb,offset))> 0 ) {
+ while((remain_length = tvb_ensure_length_remaining(tvb,offset))> 0 ) {
need_desegmentation = FALSE;
last_offset = offset;
this_number = this_data->counter+number;
@@ -573,7 +573,7 @@
/* MAC , if there is still bytes, treat it as 16bytes MAC*/
if(msg_code == SSH2_MSG_KEX_DH_GEX_REPLY) {
- len = tvb_reported_length_remaining(tvb,offset);
+ len = tvb_ensure_length_remaining(tvb,offset);
if(len == 16) {
if(tree) {
proto_tree_add_item(key_ex_tree, hf_ssh_mac_string,
@@ -591,7 +591,7 @@
{
gint len;
- len = tvb_reported_length_remaining(tvb,offset);
+ len = tvb_ensure_length_remaining(tvb,offset);
if (check_col(pinfo->cinfo, COL_INFO)) {
col_add_fstr(pinfo->cinfo, COL_INFO, "Encrypted %s packet len=%d",
is_response?"response":"request",len);
