https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-1434 Lustre <p>There was work previously done to create two plugins for Wireshark to decode LNet and Lustre headers. That work is started in lustre/contrib as the files packet-lnet.c and packet-lustre.c.</p> <p>Attempting to build these plugins revealed that Wireshark's API for dissectors has changed such they no longer build/run. Also, the Lustre plugin had a few syntax errors so I am not sure if it ever worked.</p> <p>This feature request is to do the following upgrades to Wireshark support:</p> <p>1- Get both plugins building under the latest 1.4.x version of Wireshark (will be backwards compatible with 1.2.x).<br/> 2- Move them to a wireshark subdirectory of lustre/contrib to isolate them better<br/> 3- Create a Makefile to build and install the plugins (one does not exist today).<br/> 4- If possible, automate the building of the plugins if the build system has the Wireshark source package installed.</p> <p>A Wiki page should also be created to provide instruction on how to use Wireshark to look at LNet and Lustre packets.</p> LU-1434

Update Wireshark support for LNet and Lustre

New Feature Minor Resolved Fixed Doug Oucharek Doug Oucharek LNet tools, Wed, 23 May 2012 17:53:15 +0000 Tue, 19 Jun 2018 02:30:45 +0000 Fri, 15 Mar 2013 14:16:47 +0000 Lustre 2.4.0 Lustre 2.4.0 0 7 <p>Doug, what is the current stat of this code? It would probably be useful to submit these patches to Gerrit for inspection and landing.</p> <p>Ideally we would hook the files into the Lustre build system and generate (possibly a separate RPM) binaries for Wireshark plugins for the kernels we support. This would probably need the build nodes to install the "wireshark devel" packages, and have a configure check to detect whether the headers/libraries are installed.</p> <p>Here is the current state of Wireshark support:</p> <ul class="alternate" type="square"> <li>All changes I have made to date are on a Git branch on my system ready to be pushed into Gerrit. I was holding off until we are past 2.3 being the master. We are beyond that point so I should be pushing soon.</li> <li>I have done a Makefile for manual building so people can build it for themselves when they want.</li> <li>There is a README in the directory explaining how to build and install the new Wireshark plugins.</li> </ul> <p>There are, however, some problems:</p> <p>1- The decoding for Lustre is HUGE. The one file is over 12K lines of code. The file for LNet decoding is just over 1K lines. This is going to be a very long and painful code inspection.<br/> 2- I updated all code for our coding guidelines so it passes our Git hooks. As such, Gerrit will flag all lines as changed. That means about 13.5K lines will go into Gerrit in one patch.<br/> 3- I've been able to verify the LNet decoding, but the Lustre decoding does have some errors. I'm sure it is over 80% correct, but there is a need for making corrections. I don't have the background to do this (nor is there a protocol map I can rely on for this). I need the help of the Lustre experts to verify the Lustre decoding and make the necessary changes.</p> <p>So, what I'd like to do is this:</p> <p>1- Submit what I have so far to Gerrit to start the review/correction process.<br/> 2- Have some of the experts at the Lustre protocol install the patch, build Wireshark support, and do captures to verify that the decoding is correct. When errors are found, send corrections to me and I'll accumulate them into a new updated patch.<br/> 3- When the decoding is correct and happy, do a final patch to automate the build process tying this into our build system.</p> <p>Thoughts?</p> <p>Do we really need to convert every line of code to the new format? In other words, is every line modified just to convert it to proper coding style, or is in needed due to changes in wireshark? Changing every line in the file in one patch will make it messy to inspect.</p> <p>Is it possible to land the LNet decoding first, then do the Lustre decoding in a separate patch to reduce the patch size? This would also allow landing the working LNet code first while the Lustre code is being fixed.</p> <p>As to the Lustre decoding, the RQF structures should describe all of the RPC formats in use today. I agree that getting all of the structures decoded would be great, but given that the current code is completely broken I wonder if 80% decoding is better than zero, and we can work on fixing this incrementally?</p> <p>I've created a new patch with only the changes needed to build and run the wireshark LNet and Lustre decoders under wireshark-1.6.8. </p> <p>This is under change: <a href="http://review.whamcloud.com/4393" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4393</a></p> <p>There are known issues with the Lustre decoding which will need to be ironed out over time. Future improvements/fixes will be done under new patches.</p> <p>Update to Makefile to compile code in the directory and install depending on user id:<br/> <a href="http://review.whamcloud.com/4851" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4851</a></p> <p>Updates to lustre parsing code that I needed to decode lustre packets while investigating <a href="https://jira.whamcloud.com/browse/LU-2277" title="Text file busy" class="issue-link" data-issue-key="LU-2277"><del>LU-2277</del></a>:<br/> <a href="http://review.whamcloud.com/4852" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/4852</a></p> <p>Further lustre parsing enhancements<br/> <a href="http://review.whamcloud.com/5155" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/5155</a></p> <p><a href="http://review.whamcloud.com/#change,5520" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#change,5520</a></p> Related LUDOC-91 LU-2632 LU-1915 Development Rank 1|hzvnjb: Rank (Obsolete) 7627