On Mon, 20 Jun 2016, Jeff Layton wrote: > On Mon, 2016-06-20 at 12:21 +0000, Sage Weil wrote: > > On Mon, 20 Jun 2016, Jeff Layton 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. > > > > > > Given the way the protocol works, the only way I can see to reliably > > > determine client and server is to read enough bytes to get to the > > > client's address when the server sends it, and see whether it matches > > > the receiver's address/port. > > > > I'm not sure I follow. The client is the one initiating the connection > > and the server is the one accepting. Does wireshark not let you tell > > that? > > > > I don't think so, at least not that I can tell. I'll double-check > though. > > > The addrs are exchanged so that each end can learn what their > > effective address is, but this is a bit of a hack and not really > > ideal--hoping to reduce our reliance on this (or drop it entirely) > > with msgr2. > > > > Good. > > If we do need something along those lines, it would be best to make > each peer send the same thing. Right now, the server sends its address > and then the address of the client, but the client only sends its own > address. > > An impartial observer that doesn't see the socket connection has no way > to know which end is going to send what. If we had the client and > server both send both addresses (or neither) then that makes things > _much_ simpler for the dissector. Let's maybe change teh msgr2 banner to be 'ceph accept %llx %llx' and 'ceph connect %llx %llx' or similar so that we don't have this problem there? sage > > > Is there a simpler way to do this that I'm missing? > > > > > > Also, it looks like this shouldn't be a problem for the msgr2 protocol > > > since the initial exchange doesn't involve sending addresses. Is that > > > the case? > > > > It's true that it doesn't include the addr exchange. It doesn't have any > > other explicit indication in the data flow that tells you who is the > > client vs server, though, either... > > If we can avoid sending addresses at all in the initial negotiation, > then I think that takes care of the problem. > > -- > Jeff Layton <jlayton@xxxxxxxxxx> > >
