Wireshark-bugs: [Wireshark-bugs] [Bug 10644] New: Invalid Packet Length from LRH! [Malformed Pac
Date: Wed, 29 Oct 2014 21:43:28 +0000
Bug ID 10644
Summary Invalid Packet Length from LRH! [Malformed Packet] for short RDMA Write on RoCE
Product Wireshark
Version 1.8.10
Hardware x86-64
OS All
Status UNCONFIRMED
Severity Normal
Priority Low
Component Dissection engine (libwireshark)
Assignee bugzilla-admin@wireshark.org
Reporter fowlerja@us.ibm.com

Build Information:
Version 1.8.10 (SVN Rev Unknown from unknown)

Copyright 1998-2013 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GTK+ 2.20.1, with Cairo 1.8.8, with Pango 1.28.1, with
GLib 2.26.1, with libpcap, with libz 1.2.3, without POSIX capabilities, without
SMI, without c-ares, without ADNS, without Lua, without Python, with GnuTLS
2.8.5, with Gcrypt 1.4.5, with MIT Kerberos, without GeoIP, without PortAudio,
with AirPcap.

Running on Linux 2.6.32-431.30.1.el6.x86_64, with locale en_US.utf8, with
libpcap version 1.4.0, with libz 1.2.3, GnuTLS 2.8.5, Gcrypt 1.4.5, without
AirPcap.

Built using gcc 4.4.7 20120313 (Red Hat 4.4.7-4).

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.
--
Analyzing data for a RoCE connection,  I get the following:

Invalid Packet Length from LRH! [Malformed Packet]

when encountering a 'RDMA Write Only' packet, which is short in length (Payload
data after the RDMA Tranport Header is less than 40 bytes).   

The message is mis-leading, as there is no LRH for RoCE.  

For RoCE, packet-infiniband.c,  dissect_infiniband_common() is called with
'starts_with_grh' set.  Caused packetLength to be intialized to the Packet
Length from the GRH,  lnh_val is set to IBA_GLOBAL, and then a goto skip_lrh.

skip_lrh, we switch on lnh_val, going to case IBA_GLOBAL.  IBA_GLOBAL processes
the GRH, and then shaves 40 bytes off packetLength, for the GRH.  This is the
problem, and the Packet Length contained in the GRH does not include the length
of the GRH, so later down the line packetLength goes negative.  

I have resolved the problem by shaving the 40 bytes if 'starts_with_grh' is not
set:

1762,1763c1762,1764
<             packetLength -= 40; /* Shave 40 bytes for GRH */
< 
---
> 	    if (!starts_with_grh) {
>             	packetLength -= 40; /* Shave 40 bytes for GRH */
> 	    }


I checked the lastest level of the source, and it appears the problem still
exists there as well.  

Regards.


You are receiving this mail because:
  • You are watching all bug changes.