Re: determining client and server on a connection

[Jeff Layton <jlayton@redhat.com>]

On Tue, 2016-06-21 at 00:26 +0800, Haomai Wang wrote:
> 
> 
> On Mon, Jun 20, 2016 at 7:21 PM, Jeff Layton <jlayton@redhat.com> wrote:
> > Hi! I'm just getting started working with ceph, and decided to tackle
> > fixing up the wireshark dissector which isn't working properly when you
> > use the kernel's fs client.
> > 
> > This page says that the server always sends its banner first:
> > 
> >     http://docs.ceph.com/docs/master/dev/network-protocol/?highlight=protocol
> > 
> > ...but that's not true with the Linux kernel client. The client and
> > server send their banners and addresses concurrently, and the client
> > often gets there first. The wireshark dissector relies on the server
> > sending its banner first however, so it quickly mixes the two up and
> > things go south from there.
> Hmm, actually I also modify this behavior in async msgr(https://github.com/ceph/ceph/pull/9802 last commit).
> Because I found there is no real logic difference in ordering. 
>  


Yeah, sending them concurrently does seem like the right thing to do.
There's no reason to serialize them at all, AFAICT. The first draft of
the patch is here:

    https://code.wireshark.org/review/#/c/16043/1

It seems to work for me when sniffing both the kernel and FUSE mounts
now.

The patch is not terribly pretty, but I think we'll have more work to
do in the dissector once msgr2 starts getting closer to being
finalized.

-- 
Jeff Layton <jlayton@redhat.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