Wireshark Dissector and the Future

Wireshark Dissector and the Future

[Kevin Cox]

-----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.

Cheers,
Kevin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlPnZAcACgkQwHWKOzTVLnTV/AD8D+ASjEYM4QEZY7LeP3hwFIaO
icK8icddehuxgqYL2qcA/jyHz8gKlQXu7uvjx/qHp0Crd3i8OohTyMbD2DkVMO/c
=Vzto
-----END PGP SIGNATURE-----

Re: Wireshark Dissector and the Future

[Gregory Farnum]

On Sun, Aug 10, 2014 at 5:22 AM, Kevin Cox <kevincox@kevincox.ca> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Wireshark Dissector and the Future

[Kevin Cox]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 21/08/14 12:15, Gregory Farnum wrote:
> On Sun, Aug 10, 2014 at 5:22 AM, Kevin Cox <kevincox@kevincox.ca> wrote:
>> 3. Run the network traffic of automated tests (such as teuthology)
>> through Wireshark and check the warnings/errors.
>
> 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.
I agree that #1 is probably not the long term solution.

For running test traffic through wireshark there are two options, one is
to capture the traffic, then analyse in a separate step, or we could
just analyse on the fly.  While just dumping the network traffic and
analysing later is easier to set up it is probably better to run the
analysis on the fly as the output will be a lot smaller (unless we want
to keep the packet capture for another reason).

Actually capturing the traffic is not too hard.  Either tcpdump or
tshark can be used to capture the packets.  Then tshark can be used to
analyse them.  Of course if tshark is doing the dumping it can analyse
on the fly.  The display filter '-Y' option  can be used to restrict the
output to "interesting" features.  Many are already filterable by the
dissector (for example '-Yceph.ver.tooold||ceph.ver.toonew' will detect
encoding versions not supported by the dissector) and more could be
added as desired.

I don't however, know anything about teuthology so I will need to look
into how to integrate that.

Cheers,
Kevin

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlP3ru0ACgkQwHWKOzTVLnROSQD/dttXUaZLBH5DKXcOnjod/B8M
xZhEWDgjImDJpe+JSwAA/0EJGe0NvK6HldoNblDs8Mg+EWKslIvd7Z49p32KJjbc
=HwX/
-----END PGP SIGNATURE-----


--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html