On Sun, Aug 10, 2014 at 5:22 AM, Kevin Cox <kevincox@xxxxxxxxxxx> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Hello, > > This summer as a GSOC project I have implemented a Wireshark dissector > for Ceph. It has been committed to Wireshark master and will be > available in the next release. > > I have been talking with Sage and we have been identifying a couple of > next steps that need to be discussed about how the dissector will be > kept up to date and related issues. > > Firstly there is the issue of the two existing dissectors sitting in the > Ceph tree. Neither compile with a modern Wireshark and the new one is > far more complete. The current plan is simply to delete them unless > anyone has objections or a better idea. > > Secondly there is the issue of keeping the dissector up to date. The > way it is written it should be fairly resilient to new messages and > encodings but of course to be the most useful it would understand the > latest version of the protocol. > > There is documentation coming to both the Ceph tree and the top of the > Wireshark dissector (both mostly written but uncommitted) describing how > to update the dissector. However we were wondering how updating the > dissector could become part of the regular workflow when updating Ceph. > I have a couple of ideas myself but wanted to pitch it to the community > to see what we could come up with in addition to my thoughts which are > below. > > 1. Make if part of the review process. "Hey, I noticed you updated the > encoding of 'x' could you update the wireshark dissector as well." > > 2. Create a "static analysis" tool to check for current encoding > versions and warn if they are newer then what is supported by the > dissector. > > 3. Run the network traffic of automated tests (such as teuthology) > through Wireshark and check the warnings/errors. > > I think number 3 is particularly interesting because it can catch more > then encoding mismatches and possibly other errors in the traffic. > However it needs much more integration and requires that the new > encodings are properly tested (although they should be anyway). > > I would appreciate ideas and feedback about how this can/should be > handled and integrated into the pipeline. A little late now (I've been on vacation) but I just want to register a vote against option #1 — nobody is going to consistently remember that. :) I suspect option #3 is the most practical and most likely to keep it up to date; I don't know exactly how would be best to dump the network traffic but I think that it should be fairly simple to dump any gathered data into wireshark as part of a short teuthology test that's in all the suites. -Greg Software Engineer #42 @ http://inktank.com | http://ceph.com -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
