On Mon, 1 Jun 2015, J. Bruce Fields wrote: > On Wed, May 27, 2015 at 02:03:56PM -0400, Benjamin Coddington wrote: > > On Wed, 27 May 2015, Benjamin Coddington wrote: > > > > > What follows is a small tool I think may be convenient to test and reproduce > > > certain types of bugs that are difficult to create from above the > > > filesystem, but are clearly problematic and have well-defined network > > > triggers. Anna's recent BAD_STATEID on WRITES with delegation is a good > > > > *Olga > > > > Apologies. > > > > Ben > > > > > example of that. This tool uses netfilters NFQUEUE target to allow a linux > > > host to modify the NFS network traffic between existing clients and servers. > > > In that sense, it is very similar to nfs-proxy, however I find it to be much > > > more convenient to use, as it can be quickly inserted and removed from an > > > existing network conection. > > By the way, I only recently noticed there's a branch of Fred's old pynfs > repo with the proxy-nfs code. I've just merged that branch into my > tree. (Let me know if anyone uses that.) > > Do you want me to take these patches to? Do you think you're going to > continue using this? I'm actually not sure yet if this is more or less useful than the nfs-proxy.. In using it the past week, I found it to be convenient for quickly inserting and removing behaviors, and then modifiying those behaviors and quickly inserting/removing them again. I think doing that with the nfs-proxy would be more disruptive to the client, potentially. It does suffer from a scrambling of TCP sequencing if payload sizes are modified - the nfs-proxy doesn't have this problem. That causes the transport to want to reconnect.. so when using it you have to keep TCP in mind. I think I'll continue to use what I have and do a bit of refinement and post back again in a bit. Ben -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
