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