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-----
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Gregory Farnum]

Post by Kevin Cox
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hello,
This summer as a GSOC project I have implemented a Wireshark dissecto=

r

Post by Kevin Cox
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 o=

f

Post by Kevin Cox
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

Post by Kevin Cox
Ceph tree. Neither compile with a modern Wireshark and the new one i=

s

Post by Kevin Cox
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 th=

e

Post by Kevin Cox
Wireshark dissector (both mostly written but uncommitted) describing =

how

Post by Kevin Cox
to update the dissector. However we were wondering how updating the
dissector could become part of the regular workflow when updating Cep=

h.

Post by Kevin Cox
I have a couple of ideas myself but wanted to pitch it to the commun=

ity

Post by Kevin Cox
to see what we could come up with in addition to my thoughts which ar=

e

Post by Kevin Cox
below.
1. Make if part of the review process. "Hey, I noticed you updated th=

e

Post by Kevin Cox
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 mor=

e

Post by Kevin Cox
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 =E2=80=94 nobody is going to consistently reme=
mber
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" i=
n
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Kevin Cox]

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

Post by Gregory Farnum

Post by Kevin Cox
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 =E2=80=94 nobody is going to consistently re=

member

Post by Gregory Farnum
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 th=

e

Post by Gregory Farnum
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.

=46or 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 th=
e
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
=3DHwX/
-----END PGP SIGNATURE-----


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