aboutsummaryrefslogtreecommitdiffstats
path: root/epan/dissectors/packet-rpcrdma.c
AgeCommit message (Collapse)AuthorFilesLines
2022-03-22rpcrdma: fix build issue [-Wmaybe-uninitialized]Joakim Karlsson1-1/+1
2022-03-18RPCoRDMA: do not reassemble if there is only one fragmentJorge Mora1-14/+14
Only reassemble if reply chunk size is non-zero to avoid reassembly of a single fragment. The RPC-over-RDMA reply has no data when the reply chunk size is non-zero but it needs to reassemble all fragments (more_frags = FALSE) in this frame. On the other hand when the reply chunk size is zero, the whole message is given in this frame therefore there is no need to reassemble.
2022-03-16RPCoRDMA: add padding on iWarp read and write chunksJorge Mora1-0/+31
Add padding bytes as a separate fragment when last fragment's data is not on a four-byte boundary. The MPA layer removes the padding bytes from all iWarp Reads and Writes. The iWarp Send messages are padded correctly. Fixes #17963.
2022-03-16RPCoRDMA: add iWarp read chunk reassemblyJorge Mora1-0/+58
Add binary tree, request_list, to add rdmap_request_t struct using the sink steering tag of a tagged message as the key. The request info is used to map the read response STag to the segment STag and to map the read response offset to the segment offset. Since the read chunk message is reassembled in the last read response, go through all segments to calculate read chunk size and the received bytes on the last read fragment. If all read chunk fragments has been added to the reassembly table then complete the reassembly and return the reassembled buffer. Related to #17963.
2022-03-16RPCoRDMA: add iWarp reply chunk reassemblyJorge Mora1-14/+12
Make sure to process RDMA_NOMSG not only for Infiniband but for iWarp as well. Related to #17963.
2022-03-16RPCoRDMA: add iWarp write chunk reassemblyJorge Mora1-10/+51
Add function add_iwarp_fragment() to add an iWarp fragment to the reassembly table and return the reassembled data if all fragments have been added. Make sure to process RDMA_MSG not only for Infiniband but for iWarp as well. Related to #17963.
2022-03-16RPCoRDMA: add iWarp send reassemblyJorge Mora1-29/+61
Add global variable gp_rdmap_info to point to the data parameter given by parent dissector IWARP_DDP_RDMAP. Add binary tree, msn_list, to add send_info_t struct using the message sequence number of an untagged message as the key. Modify function add_send_fragment() to include iWarp segments. Message numbers are given by the untagged message offset, thus the msgno of send_info_t is not used and it is set to 0. Since message offsets are not consecutive for iWarp, verify there are no missing fragments by checking the number of bytes added to the reassembly table. Also, remove function rpcrdma_initialize() Related to #17963.
2022-03-16RPCoRDMA: correctly cache Infiniband send fragmentsJorge Mora1-62/+51
On the second pass, make sure to get the correct reassembly info from the packet proto cache. This avoids having add_fragment() being called again in the second pass since the message id will be different. Also, do all of the work on add_send_fragment() and get it ready for iWarp send reassembly. Related to #17963.
2022-03-16RPCoRDMA: correctly reassemble chunks when handle is reusedJorge Mora1-199/+248
Include the virtual address or offset when searching for the correct segment. Add the segment info struct to a binary tree instead of a list to speed up searching for the correct segment when dealing with large packet traces. Add binary tree, pns_list, to avoid searching for the segment and then looking through all requests for the correct request info for the fragment. This way, the search is done using the PSN of the read/write fragment to find the correct request info on a single tree search. Add another binary tree, msgid_list, to search for all segments belonging to the same reassembly message id when calculating if reassembly is really done. Make sure all read/write reassembly is done on the first pass only. On the second pass, get the correct reassembly info from the packet proto cache. This is accomplished in part by removing get_msg_num function and instead adding add_ib_fragment function. This function, just calls get_reassembled_data() on the second pass to make sure all fragments are labeled correctly with "Reassembled in" message. On the first pass, add the fragment using either the segment info for a write only fragment or the request info for any other read/write fragments. This avoids having to add a request for the write only case since all the information needed is already in the segment info. The message number is now easily calculated by making it relative to request or segment info. Cache the value returned by get_rdma_list_size() since the segment info, more specifically rbytes, is not available on the second pass. Most of these changes not only deal with the issue to correctly reassemble chunks when the handle is being reused but it also prepares common code to add iWarp reassembly. Fixes #17961. Fixes #17962. Related to #17963.
2021-07-13prefs_register_protocol_obsolete protocols with only obsolete prefsChuck Craft1-1/+1
Related to #17465 and !3526
2021-05-13RPCoRDMA: fix read chunk reassembly if reply chunk is presentJorge Mora1-1/+3
Use correct segment type given by the reassembly message id when dealing with multiple chunks in the same frame. When an NFS WRITE is sent with a read chunk having multiple segments and it also includes a reply chunk, using the wrong segment type could lead to reassemble the message prematurely on the last read response for the first read chunk segment. The message should be reassembled in the last read response for the last segment.
2020-12-03RPCoRDMA: fix reassembly for Position-Zero Read ChunkJorge Mora1-1/+15
A Long Call or Position-Zero Read Chunk (PZRC) MUST include appropriate XDR roundup padding to maintain proper XDR alignment of their contents. For a PZRC, padding has already been added to the payload stream thus all padding added by the InfiniBand layer must be removed before adding the fragment to the reassembly table. See: https://tools.ietf.org/html/rfc8166#section-3.5 (Section 3.5.3) Closes #17054
2020-11-23RPCoRDMA: fix RPC-over-RDMA message type infoJorge Mora1-4/+5
Get value of message type from the buffer before displaying it in the info column of the packet list pane. Also, make sure there is enough bytes in the buffer to get the RPCoRDMA header.
2020-06-01Fix some cppcheck issues:Martin Mathieson1-2/+1
- Some redundant assignments or tests. - Some declarations were changed to match definitions in terms of including _U_ for the same parameters - Some parenthesis added/changed to made precedence more obvious epan/color_filters.c:533: style: Variable 'name' is reassigned a value before the old one has been used. epan/color_filters.c:534: style: Variable 'filter_exp' is reassigned a value before the old one has been used. asn1/tcap/packet-tcap-template.c:2199: warning: Function 'dissect_tcap_ITU_ComponentPDU' argument order different: declaration '_U_, tvb, offset, _U_, tree, _U_' definition '_U_, tvb, offset, actx, tree, _U_' epan/dissectors/packet-aim.c:2546: warning: Function 'dissect_aim_tlv_value_icq' argument order different: declaration 'ti, subtype, tvb, _U_' definition 'ti, _U_, tvb, pinfo' epan/dissectors/packet-arp.c:1133: style: Clarify calculation precedence for '&' and '?'. epan/dissectors/packet-arp.c:1143: style: Clarify calculation precedence for '&' and '?'. epan/dissectors/packet-arp.c:1158: style: Clarify calculation precedence for '&' and '?'. epan/dissectors/packet-arp.c:1168: style: Clarify calculation precedence for '&' and '?'. epan/dissectors/packet-gtpv2.c:5997: warning: Function 'dissect_gtpv2_mbms_service_area' argument order different: declaration 'tvb, _U_, tree, _U_, _U_, _U_, _U_, _U_' definition 'tvb, _U_, tree, item, _U_, _U_, _U_, _U_' epan/dissectors/packet-gtpv2.c:6291: warning: Function 'dissect_gtpv2_mbms_time_to_data_xfer' argument order different: declaration 'tvb, _U_, tree, _U_, _U_, _U_, _U_, _U_' definition 'tvb, _U_, tree, item, _U_, _U_, _U_, _U_' epan/dissectors/packet-gtpv2.c:6369: warning: Function 'dissect_gtpv2_epc_timer' argument order different: declaration 'tvb, _U_, tree, _U_, _U_, _U_, _U_, _U_' definition 'tvb, _U_, tree, item, _U_, message_type, _U_, _U_' epan/dissectors/packet-knxip.c:2939: style: Condition 'mac_error' is always false (just added comment) epan/dissectors/packet-mac-lte.c:4386: style: Clarify calculation precedence for '&' and '?'. epan/dissectors/packet-nas_5gs.c:1828: style: Variable 'nas5gs_data->payload_container_type' is reassigned a value before the old one has been used. (noted confusing recursion) epan/dissectors/packet-rpcrdma.c:587: warning: Identical condition 'offset>max_offset', second condition is always false epan/dissectors/packet-rsl.c:2098: style: Assignment of function parameter has no effect outside the function. Change-Id: Ib5c9a04cfb6e6233972bc041434601c8ef09c969 Reviewed-on: https://code.wireshark.org/review/37343 Petri-Dish: Martin Mathieson <martin.r.mathieson@googlemail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Martin Mathieson <martin.r.mathieson@googlemail.com>
2020-05-07Replace instances of wmem_alloc with wmem_newMoshe Kaplan1-5/+5
This commit replaces instances of (myobj *)wmem_alloc(wmem_file_scope(), sizeof(myobj)) and replaces them with: wmem_new(wmem_file_scope(), myobj) to improve the readability of Wireshark's code. The replacement locations were identified with grep and replaced with the Python script below. grep command: egrep "wmem_alloc0?\(wmem_file_scope\(\), sizeof\([a-z_]+\)\)" . -R -l python script: import re import sys import fileinput pattern = r'\(([^\s]+) ?\*\) ?wmem_alloc(0?)\((wmem_[a-z]+_scope\(\)), sizeof\(\1\)\)' replacewith = r'wmem_new\2(\3, \1)' fname = sys.argv[1] for line in fileinput.input(fname, inplace=1, mode='rb'): output = re.sub(pattern, replacewith, line) sys.stdout.write(output) Change-Id: Ieac246c104bf01e32cbc6e11e53e81c7f639d870 Reviewed-on: https://code.wireshark.org/review/37158 Petri-Dish: Pascal Quantin <pascal@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Pascal Quantin <pascal@wireshark.org>
2020-01-11Compilation fixes when CMAKE_BUILD_TYPE = MinSizeRel (-Os flag).Roman Koshelev1-3/+5
Compiler - gcc 8.3.0 These are mostly errors 'may be used uninitialized in this function' Change-Id: I6a8f7172c99024fd449570937b030e37c0ea5c3d Reviewed-on: https://code.wireshark.org/review/35746 Reviewed-by: Pascal Quantin <pascal@wireshark.org>
2019-12-09RPC-over-RDMA: add reassembly of SEND first, middle and lastJorge Mora1-3/+86
Linux uses SEND first, middle and last for small NFS reads instead of using the write chunk list. Reassembly is done using the PSN (packet sequence number) to order the segments in case one or more segments are sent out of order. Reassembly uses a single message id per each direction of a given conversation so it is tied to the destination queue pair. Also, the PSN given in the SEND First packet is used as a base so fragment numbers are relative and start at zero. Furthermore, a previous incomplete reassembly is thrown away in the SEND First packet so any fragments previously added to the reassembly table are not included in the current reassembled message. Bug: 16225 Change-Id: I8de6a3123676e348d8e893f0f67d4b3ba38db27f Reviewed-on: https://code.wireshark.org/review/35224 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2019-07-26HTTPS (almost) everywhere.Guy Harris1-1/+1
Change all wireshark.org URLs to use https. Fix some broken links while we're at it. Change-Id: I161bf8eeca43b8027605acea666032da86f5ea1c Reviewed-on: https://code.wireshark.org/review/34089 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2018-12-27Try to squeeze some bytes out of the frame_data structure.Guy Harris1-8/+8
Make the time stamp precision a 4-bit bitfield, so, when combined with the other bitfields, we have 32 bits. That means we put the flags at the same structure level as the time stamp precision, so they can be combined; that gets rid of an extra "flags." for references to the flags. Put the two pointers next to each other, and after a multiple of 8 bytes worth of other fields, so that there's no padding before or between them. It's still not down to 64 bytes, which is the next lower power of 2, so there's more work to do. Change-Id: I6f3e9d9f6f48137bbee8f100c152d2c42adb8fbe Reviewed-on: https://code.wireshark.org/review/31213 Petri-Dish: Guy Harris <guy@alum.mit.edu> Tested-by: Petri Dish Buildbot Reviewed-by: Guy Harris <guy@alum.mit.edu>
2018-05-29RPC-over-RDMA: fix infinite loopPeter Wu1-3/+3
When there are two segments, but zero requests, "i=1" will be reset to "i=0" and an infinite loop occurs. Change-Id: I32cb387ce0724936bcb5d5832b1c90d2bc585998 Fixes: v2.5.2rc0-100-g8f0f691312 ("RPC-over-RDMA: add reassembly for reply, read and write chunks") Link: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=7138 Reviewed-on: https://code.wireshark.org/review/27891 Reviewed-by: Jaap Keuter <jaap.keuter@xs4all.nl> Petri-Dish: Jaap Keuter <jaap.keuter@xs4all.nl> Tested-by: Petri Dish Buildbot Reviewed-by: Peter Wu <peter@lekensteyn.nl>
2018-04-05rpcrdma: add check to prevent null dereference (found by clang).Dario Lombardo1-1/+1
Change-Id: Iff3e3a348d40e42569135179953a957f9012fd3f Reviewed-on: https://code.wireshark.org/review/26730 Petri-Dish: Dario Lombardo <lomato@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
2018-03-26rpcrdma: make sure that heuristic checks don't throw an exceptionMartin Kaiser1-3/+7
We should not be throwing an exception while checking if the packet really contains our protocol. Add a length check to make sure that the initial tvb_get_ntohl() call will not fail. Read the message type after the heuristic check. Change-Id: I397732dbec20bcd0ab5356e8c3500fd0cb6e1434 Reviewed-on: https://code.wireshark.org/review/26634 Reviewed-by: Martin Kaiser <wireshark@kaiser.cx> Petri-Dish: Martin Kaiser <wireshark@kaiser.cx> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-03-25RPCRDMA: Fix 'might be clobbered' warningUli Heilmeier1-1/+1
Fix "might be clobbered by 'longjmp' or 'vfork' warning Change-Id: I3c7433568c452782316e37efd9697effdf0ebe0f Reviewed-on: https://code.wireshark.org/review/26632 Petri-Dish: Martin Kaiser <wireshark@kaiser.cx> Tested-by: Petri Dish Buildbot Reviewed-by: Martin Kaiser <wireshark@kaiser.cx>
2018-03-24RPC-over-RDMA: add explicit fall through comments to please gcc 7.2.0Pascal Quantin1-0/+4
Change-Id: Ied55b2283da36dabd21768660f6824492cd569a1 Reviewed-on: https://code.wireshark.org/review/26624 Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com>
2018-03-24RPC-over-RDMA: add reassembly for reply, read and write chunksJorge Mora1-29/+1019
The RDMA reply chunk is used for a large RPC reply which does not fit into a single SEND operation and does not have a single large opaque, e.g., NFS READDIR. The RPC call packet is used only to set up the RDMA reply chunk. The whole RPC reply is transferred via RDMA writes. Fragments are added on any RDMA write packet, RDMA_WRITE_ONLY, RDMA_WRITE_FIRST, etc., and the reassembly is done on the reply message. The RPC reply packet has no data (RDMA_NOMSG) but fragments are reassembled and the whole RPC reply is dissected. The RDMA read chunk list is used for a large RPC call which has at least one large opaque, e.g., NFS WRITE. The RPC call packet is used only to set up the RDMA read chunk list. It also has the reduced message data which includes the first fragment (XDR data up to and including the opaque length), but it could also have fragments between each read chunk and the last fragment after the last read chunk data. The reduced message is then broken down into fragments and inserted into the reassembly table. Since the RDMA read chunk list is set up in the RPC call then do not dissect the upper layer in this case and just label rest of packet as "Data" since the reassembly will be done on the last read response. The protocol gives the XDR position where each chunk must be inserted into the XDR stream thus as long as the maximum I/O size is known it is possible to know exactly where to insert these fragments. This maximum I/O size is set on the first READ_RESPONSE_FIRST or READ_RESPONSE_MIDDLE but in case where any of these packets have not been seen then a value of 100 is used (real value should be at least 1024) but in this case the message numbers are not consecutive between chunks but since the total size of all chunks is verified to make sure there is a complete message to reassemble then all fragments should be in the correct order. Fragments are added on any RDMA read packet: RDMA_READ_RESPONSE_ONLY, RDMA_READ_RESPONSE_FIRST, etc., and the reassembly is done on the last read response. Since there could be multiple chunks and each chunk could have multiple segments then the total size must be checked to complete the reassembly because in this case there will be multiple READ_RESPONSE_LAST. The RDMA write chunk list is used for a large RPC reply which has at least one large opaque, e.g., NFS READ. The RPC call packet is used only to set up the RDMA write chunk list. The opaque data is then transferred via RDMA writes and then the RPC reply packet is sent from the server. The RPC reply packet has the reduced message data which includes the first fragment (XDR data up to and including the opaque length), but it could also have fragments between each write chunk and the last fragment after the last write chunk data. The reduced message is then broken down into fragments and inserted into the reassembly table. Since the RPC reply is sent after all the RDMA writes then the fragments from these writes must be inserted in the correct order: the first RDMA write fragment is inserted with message number 1, since the first fragment (message number 0) will come from the very last packet (the RPC reply with RDMA_MSG). Also, the last packet could have fragments which must be inserted in between chunk data, therefore message numbers from one chunk to another are not consecutive. In contrast with the RDMA read chunk list, the protocol does not allow an XDR position in the RDMA write chunks, since the RPC client knows exactly where to insert the chunk's data because of the virtual address of the DDP (direct data placement) item. There is no way to map a virtual address with an XDR position, thus in order to reassemble the XDR stream a two pass approach is used. In the first pass (visited = 0), all RDMA writes are inserted as fragments leaving a gap in between each chunk. Then the dissector for the upper layer is called with a flag letting the dissector know that it is dealing with a reduced message so all DDP enabled operations handle the opaque data as having only the size of the opaque but not the data and reporting back the offset from the end of the message. Once the upper layer dissector returns, this layer now has a list of DDP eligible item's offsets which are then translated into XDR offsets and then the RPC reply packet is broken into fragments and inserted in the right places as in the case for the RDMA read chunk list. On the second pass (visited = 1), all fragments have already been inserted into the reassembly table so it just needs to reassembled the whole message and then call the upper layer dissector. RFC 8267 specifies the upper layer bindings to RPC-over-RDMA version 1 for NFS. Since RPC-over-RDMA version 1 specifies the XDR position for the read chunks then only the write chunk DDP eligible items are handled in the upper layer, in this case the NFS layer. These are the only procedures or operations eligible for write chunks: * The opaque data result in the NFS READ procedure or operation * The pathname or linkdata result in the NFS READLINK procedure or operation Two functions are defined to signal and report back the DDP eligible item's offset to be used by the upper layers. Function rpcrdma_is_reduced() is used to signal the upper layer that it is dealing with a reduced data message and thus should ignore DDP eligible item's opaque processing and just report back the offset where the opaque data should be. This reporting is done using the second function rpcrdma_insert_offset(). Reassembly is done for InfiniBand only. Reassemble fragments using the packet sequence number (PSN) of each RDMA I/O fragment to make sure the message is reassembled correctly when fragments are sent out of order. Also a unique message id is used for each message so fragments are reassembled correctly when fragments of different messages are sent in parallel. The reassembled message could be composed of multiple chunks and each chunk in turn could be composed of multiple segments in which each segment could be composed of multiple requests and of course each request is composed of one or more fragments. Thus in order to have all fragments for each segment belonging to the same message, a list of segments is created and all segments belonging to the same message are initialized with the same message id. These segments are initialized and added to the list on the call side on RDMA_MSG by calling process_rdma_lists. Bug: 13260 Change-Id: Icf57d7c46c3ba1de5d019265eb151a81d6019dfd Reviewed-on: https://code.wireshark.org/review/24613 Petri-Dish: Anders Broman <a.broman58@gmail.com> Tested-by: Petri Dish Buildbot Reviewed-by: Anders Broman <a.broman58@gmail.com>
2018-02-21RPCoRDMA: Set an upper bound for our chunk size.Gerald Combs1-3/+8
Make sure our write chunk size doesn't exceed our tvbuff. Adjust a few length checks. Bug: 14449 Change-Id: If9dd8a6094830c5b47adfff0acb3ff726168e801 Reviewed-on: https://code.wireshark.org/review/25943 Reviewed-by: Gerald Combs <gerald@wireshark.org> Petri-Dish: Gerald Combs <gerald@wireshark.org> Tested-by: Petri Dish Buildbot Reviewed-by: Michael Mann <mmann78@netscape.net>
2018-02-12dissectors: use SPDX identifiers.Dario Lombardo1-13/+1
Change-Id: I92c94448e6641716d03158a5f332c8b53709423a Reviewed-on: https://code.wireshark.org/review/25756 Petri-Dish: Dario Lombardo <lomato@gmail.com> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2017-10-06RPC-over-RDMA: fix write list chunk countJorge Mora1-0/+1
Add the chunk_size to the offset to get the correct write list count, this issue was introduced by the fix for Bug: 13558 Change-Id: I306a9c0c9d601f7bdf4cc0e49eacd5466a6adb89 Reviewed-on: https://code.wireshark.org/review/23851 Petri-Dish: Michael Mann <mmann78@netscape.net> Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org> Reviewed-by: Michael Mann <mmann78@netscape.net>
2017-04-06RPC-over-RDMA: protect against a variable overflowPascal Quantin1-5/+9
Bug: 13558 Change-Id: I0cb379df1a6c40a3c4a84f18c631d9239550c3ab Reviewed-on: https://code.wireshark.org/review/20941 Reviewed-by: Pascal Quantin <pascal.quantin@gmail.com> Petri-Dish: Pascal Quantin <pascal.quantin@gmail.com> Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2016-12-21packet-rpcrdma: Fix Reply chunk selection sizeChuck Lever1-1/+1
When a Reply chunk is not present, selecting the "Reply chunk" in the protocol tree should also select the four bytes of zeroes in the header. This should work the same way as for the Read list and Write list. Change-Id: I0a9b7f927cad21e39189cfc1f2b619537ba26a30 Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-on: https://code.wireshark.org/review/19376 Reviewed-by: Michael Mann <mmann78@netscape.net>
2016-12-20Improve Infiniband heuristic subdissection.Michael Mann1-18/+9
Add preference in Infiniband dissector to distinguish between heuristic and non-heuristic dissection (that uses Decode As). Remove all of the preferences in the Infiniband subdissectors that tried to put in "manual" heuristics and direct users to just use Decode As. Most subdissectors still kept some basic heuristics in their heuristic functions, but now also register with the Infiniband dissector table for "manually" forcing dissection with Decode As. Ping-Bug: 13259 Change-Id: I20d56eee38887664b439e52ec5f5b8f962c45ef1 Reviewed-on: https://code.wireshark.org/review/19362 Petri-Dish: Michael Mann <mmann78@netscape.net> Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org> Reviewed-by: Michael Mann <mmann78@netscape.net>
2016-12-08packet-rpcrdma: Select correct size of transport headerChuck Lever1-0/+4
Nit: Make it easier to see the transition between the end of the RPC-over-RDMA transport header and the start of the RPC header. Calculate the selection size of the RPC-over-RDMA header properly, including the size of the chunk lists. Change-Id: I84bc7d970a95e8f50a21a45ded386322711b6512 Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-on: https://code.wireshark.org/review/19034 Reviewed-by: Michael Mann <mmann78@netscape.net> Petri-Dish: Michael Mann <mmann78@netscape.net> Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2016-12-07packet-rpcrdma: Fix selection size in chunk list dissectorsChuck Lever1-13/+11
Use proto_item_set_len instead of walking the packet ahead of time trying to compute the size. Change-Id: I5eb3da1fef45895853cb5b6b198d0310394e4176 Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-on: https://code.wireshark.org/review/19120 Reviewed-by: Michael Mann <mmann78@netscape.net> Petri-Dish: Michael Mann <mmann78@netscape.net> Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org> Reviewed-by: Anders Broman <a.broman58@gmail.com>
2016-12-07packet-rpcrdma: Prepare dissector for RPC-over-RDMA on iWARP or RoCEChuck Lever1-152/+69
Remove the Infiniband-centric QP filtering. This filtering attempted to create conversations to allow the heuristic dissector to be bypassed once it was established that a QP was carrying RPC-over-RDMA traffic. However, it was preventing proper identification of RPC-over-RDMA traffic when a CM connection establishment exchange doesn't appear in the capture (which is frequently the case for captures of NFS traffic). Also, without this conversation logic, loading a capture file appears to be significantly faster, at least for capture files I have on hand. Later, some form of conversation management will be needed in order to associate RPC-over-RDMA transport headers with RDMA Read and Write operations that go along with them. But it will need to be agnostic about the underlying link layer. Bug: 13199 Bug: 13202 Change-Id: Ie6b7a4c65979dac036306f7367ce18836713ab4d Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-on: https://code.wireshark.org/review/19032 Petri-Dish: Michael Mann <mmann78@netscape.net> Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org> Reviewed-by: Michael Mann <mmann78@netscape.net>
2016-12-06packet-rpcrdma: Add filter variable for Write chunk segment countChuck Lever1-0/+8
Allow the Write segment count field to be selected and filtered on. In many Write chunks there is just one segment. However in some special cases there can be multiple segments in a Write or Reply chunk. Change-Id: Ic4a4104e3a44bf4f2c96e4e5353a10e7547350c9 Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-on: https://code.wireshark.org/review/19102 Petri-Dish: Michael Mann <mmann78@netscape.net> Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org> Reviewed-by: Michael Mann <mmann78@netscape.net>
2016-12-06packet-rpcrdma: Clean up Reply chunk dissectionChuck Lever1-35/+29
Display the Reply chunk as a tree, using the same code that the Write list dissector now uses. Fix up the selection size of the Reply chunk. Bug: 13197 Change-Id: Ie861b7721b2c2dd9a5839986488ee22f39f81d1e Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-on: https://code.wireshark.org/review/19101 Petri-Dish: Michael Mann <mmann78@netscape.net> Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org> Reviewed-by: Michael Mann <mmann78@netscape.net>
2016-12-06packet-rpcrdma: Fix Write list dissectionChuck Lever1-10/+109
The current mechanism of dissecting RPC-over-RDMA chunk lists is not working. It treats the Write list as a list of RDMA segments (it's a list of counted arrays). Bug: 13197 Change-Id: I6f8e788d66eefd17d6c1995e238a9ff9fa1e81f2 Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-on: https://code.wireshark.org/review/19100 Reviewed-by: Michael Mann <mmann78@netscape.net>
2016-12-06packet-rpcrdma: Fix Read list dissectionChuck Lever1-1/+77
The current mechanism of dissecting RPC-over-RDMA chunk lists is not working. It treats the Read list as a counted array (it's a list). Part of this confusion arises because RFC 5666 uses the term "chunk" to mean "chunk", "read segment", and "rdma segment". Re-organize the dissector logic to make this distinction properly. Bug: 13197 Change-Id: Iad517804dbcf8b30de795af03af7a71a6f231231 Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-on: https://code.wireshark.org/review/19099 Reviewed-by: Michael Mann <mmann78@netscape.net>
2016-12-05packet-rpcrdma: Display length fields in decimalChuck Lever1-2/+2
Change-Id: I3a3a51de76286800992b1445c332c50059112c54 Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-on: https://code.wireshark.org/review/19098 Reviewed-by: Michael Mann <mmann78@netscape.net>
2016-12-05packet-rpcrdma: Remove if (tree) preventing dissectors being called.Chuck Lever1-58/+55
When tshark displays each frame in default mode (without -V): - NFS on TCP is dissected and displayed - NFS on RPC/RDMA is displayed as only an RPC/RDMA frame NFS on RPC/RDMA should be dissected and displayed just like NFS on TCP. Make passing along the RPC payload to the RPC dissector unconditional. Bug: 13198 Change-Id: Ia86f3abcfcbc65a860d4ff7bac19a5f3af44a0b0 Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-on: https://code.wireshark.org/review/19027 Reviewed-by: Michael Mann <mmann78@netscape.net>
2016-12-02packet-rpcrdma: Fix protocol frame pre-detectionChuck Lever1-37/+90
The current mechanism of detecting RPC-over-RDMA is broken because it treats the Read list as a counted array (it's a list); and treats the Write list and Reply chunk identically (one is a list, one is always a single chunk). While we're here, refactor pre-detection helper functions so they can be used during frame dissection as well. Bug: 13196 Change-Id: I76e210c8d2a9464fed00e7199072d37f4ebbebf2 Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-on: https://code.wireshark.org/review/19025 Petri-Dish: Michael Mann <mmann78@netscape.net> Reviewed-by: Michael Mann <mmann78@netscape.net>
2016-12-02packet-rpcrdma: Display length and version fields in decimalChuck Lever1-8/+8
Display length fields in decimal, just as they are displayed by the RDMA RETH dissector. Display version fields in decimal, just as they are displayed by the RPC dissector. RDMA offset fields are left in hexadecimal since they are essentially addresses, and at least the Linux RPC-over-RDMA implementation has debugging messages that display these as hexadecimal values. Change-Id: I7206970675ca0ca486b3a2837b6dbb1c4d764091 Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-on: https://code.wireshark.org/review/19028 Reviewed-by: Michael Mann <mmann78@netscape.net>
2016-12-02packet-rpcrdma: Dissector should exit when frame is not RPC-over-RDMAChuck Lever1-1/+1
On an RDMA transport, RPC protocol never appears in a frame by itself. If RPC-over-RDMA is not present, then RPC is by definition not present as an InfiniBand data payload. Bug: 13195 Change-Id: Icaea9d4936477af32adc73140c67539e977a7a9a Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Reviewed-on: https://code.wireshark.org/review/19024 Reviewed-by: Michael Mann <mmann78@netscape.net>
2016-10-28rpcrdma: fix fix spelling typo found by lintianAlexis La Goutte1-1/+1
Change-Id: If057ecf07b6707a5b72b8a29ccf6388b16f4826a Reviewed-on: https://code.wireshark.org/review/18520 Reviewed-by: Anders Broman <a.broman58@gmail.com>
2016-03-20Create call_data_dissector() to call data dissector.Michael Mann1-3/+1
This saves many dissectors the need to find the data dissector and store a handle to it. There were also some that were finding it, but not using it. For others this was the only reason for their handoff function, so it could be eliminated. Change-Id: I5d3f951ee1daa3d30c060d21bd12bbc881a8027b Reviewed-on: https://code.wireshark.org/review/14530 Petri-Dish: Michael Mann <mmann78@netscape.net> Reviewed-by: Michael Mann <mmann78@netscape.net>
2016-03-20Manually add protocol dependencies derived from find_dissector.Michael Mann1-2/+2
Started by grepping call_dissector_with_data, call_dissector_only and call_dissector and traced the handles passed into them to a find_dissector within the dissector. Then replaced find_dissector with find_dissector_add_dependency and added the protocol id from the dissector. "data" dissector was not considered to be a dependency. Change-Id: I15d0d77301306587ef8e7af5876e74231816890d Reviewed-on: https://code.wireshark.org/review/14509 Petri-Dish: Michael Mann <mmann78@netscape.net> Reviewed-by: Michael Mann <mmann78@netscape.net>
2016-02-22Resolve hf_ field name conflicts with protocol strings.Michael Mann1-7/+1
Change-Id: Ie719e2f14c6eaf536035ab30dcb40e91c431c6e4 Reviewed-on: https://code.wireshark.org/review/14061 Petri-Dish: Michael Mann <mmann78@netscape.net> Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com> Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org> Reviewed-by: Michael Mann <mmann78@netscape.net>
2016-01-24Add the packet number to the packet_info structure, and use it.Guy Harris1-2/+2
That removes most of the uses of the frame number field in the frame_data structure. Change-Id: Ie22e4533e87f8360d7c0a61ca6ffb796cc233f22 Reviewed-on: https://code.wireshark.org/review/13509 Reviewed-by: Guy Harris <guy@alum.mit.edu>
2015-12-09new_create_dissector_handle -> create_dissector_handle for dissector directory.Michael Mann1-1/+1
Some of the ASN.1 dissectors still generate a new_create_dissector_handle from the tool itself, so leave those for now. Change-Id: Ic6e5803b1444d7ac24070949f5fd557909a5641f Reviewed-on: https://code.wireshark.org/review/12484 Petri-Dish: Anders Broman <a.broman58@gmail.com> Reviewed-by: Michael Mann <mmann78@netscape.net>
2015-10-22Use address functions instead of ADDRESS macros in asn1 and epanGerald Combs1-6/+6
Replace CMP_ADDRESS, COPY_ADDRESS, et al with their lower-case equivalents in the asn1 and epan directories. Change-Id: I4043b0931d4353d60cffbd829e30269eb8d08cf4 Reviewed-on: https://code.wireshark.org/review/11200 Petri-Dish: Michal Labedzki <michal.labedzki@tieto.com> Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com> Tested-by: Petri Dish Buildbot <buildbot-no-reply@wireshark.org> Reviewed-by: Michael Mann <mmann78@netscape.net>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-25 07:52:34 +0000