Date: Mon, 10 Apr 2006 04:38:50 -0700 From: Julian Elischer <julian@elischer.org> To: Andrea Campi <andrea+freebsd_net@webcom.it> Cc: freebsd-net@freebsd.org Subject: Re: TCP Daytona in userland Message-ID: <443A43CA.1030508@elischer.org> In-Reply-To: <20060409223246.GA1747@webcom.it> References: <20060409223246.GA1747@webcom.it>
next in thread | previous in thread | raw e-mail | index | archive | help
Andrea Campi wrote: >Hi all, > >I have started working on a "TCP Daytona" implementation [1]. I'm >quite familiar with TCP/IP in theory, and sort of familiar with the >BSD implementation ideas, but looking into tcp_input and tcp_output is >always a mistic experience ;-) I tried to understand how I could >generate multiple (either duplicate or better partial ACKs), but I >guess tcp_output is really not meant to do such a thing. Does anyone >have an idea of how hard would it be to generate more than one ACK for >an input packet, and could you give me some suggestion? > >So to get my feet wet, I've decided to start from a simple userland >implementation using BPF. Currently I'm using a test program that does >an HTTP transfer and, from a parallel thread, I monitor the >conversation and send additional ACKs for each genuine ACK I see. This >doesn't seem to have any (positive or negative) effect if I send 1 or >2 duplicate ACKs, but slows the connection down if I send 3 or more >additional ACKs. I didn't have much time to investigate this yet. > >Sadly, this wouldn't work if I wanted to send partial ACKs instead. >What would be nice is to be able to stop the genuine ACK from being >sent and inject partial ACKs instead. Do we have any mechanism that >would allow me to do this? Maybe I should be using divert(4) instead? > > use netgraph with the ng_ether and the ng_etf filter to separate out IP packets and send them to you? if you use divert then re-injecting packets will put them out through ip_output which is probably not what you want. >Lastly, if anybody already worked on this: do you have any additional >suggestion? In particular regarding the testing methodology: since a >few years have passed, I'm not quite sure whether different OSs have >implemented any countermeasure. I'm mainly testing against a FreeBSD >box I control, and I don't think we have any defence against this yet. > >Bye, > Andrea > >1. as per the Savage et al. paper: >http://www-cse.ucsd.edu/~savage/papers/CCR99.pdf >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?443A43CA.1030508>