Hi Aaron, Thanks for getting back with me. I have a couple more questions and I appreciate your time; I agree that the general solution is very complicated.
> Correct. tcpreplay can not do this. The issue is more then timing, > it's dealing with changing TCP initial sequence numbers, source ports > and stuff like that. Understood. >> - Is there any interest/possibility of baking this feature into a >> version of the tcpreplay tools? > > Interest? Sure. Chances of it actually happening? Close to zero. > The effort required to make this sort of thing happen is beyond what I > have time to do on my own in my free time. In the past, the people > who are interested in helping quickly throw up their hands in > frustration once they wrap their head around all the corner cases to > get a 50/50 chance of this sort of thing working for a given pcap. > Things get a lot easier if you're taking a pcap of a given > client/server and replaying it to the same client or server, but once > you change the target things get messy really fast. Okay, I'd like to get a better idea of how the problem could be scoped to reduce the overall complexity. What if we assumed the following: 1) We're not interested in replaying client traffic to a server -- just server traffic to a client. 2) Assume we know the exact version / patch level / configuration of the original browser that generated the PCAP. And, assume we have a copy of that identical browser that we use to replay the server traffic to. Meaning, we don't care about interop with any other browser or application -- just the original target application. 3) Based on #2, we also assume that the browser is *deterministic*. Meaning, given the same server traffic, over and over again, the browser's request pattern and timing is identical and unchanging. Yes, I know this is a very naive approach (considering there may be many factors that change a browser's behavior). However, assume we have a way to get the browser back into an identical state *right before the original PCAP was generated* -- which makes it ideal for replaying the same identical server traffic. I can go into more detail about how we could accomplish this, if you'd like an additional explanation. 4) Assume all application data inside the PCAP causes the browser/OS to behave in a deterministic fashion. For example, we assume the PCAP doesn't contain Javascript that causes the browser to act differently, based on a randomized value, etc. 5) What if we don't care about getting/matching identical, originating source ports / TCP initial sequence numbers from the browser -- basically we could ignore most data at or below the TCP and IP layers of the packets. What really matters is replaying the same, identical traffic at the *application layer*. Also, assume for a second that you don't need to rewrite any data in the application layer (because of assumptions #2 and #3). 6) Assume that the browser can't simultaneously request multiple resources to multiple servers at the same exact time. Yes, I know in complex situations, this doesn't work, but let's assume we're dealing with fairly simple content, at this point. > Nothing that I'm aware of. Depending on how complex your HTTP stream > is, you can fake it pretty easy though. Take your pcap, load it in > Wireshark, extract the server to client flow and save it off in a new > file. Then use netcat to serve up that file data to any client which > connects on port 80. This will work for simple cases, but more > complex situations will have a bunch of issues. Okay, now we're getting somewhere. Let's take your initial netcat approach and expand it, factoring the assumptions I mentioned earlier. For example, let's assume a PCAP contained the following data: Time 0: DNS lookup to www.google.com (and all response data) Time 10: HTTP request to http://www.google.com/ (and all response data to render this HTML content) Time 20: HTTP request to http://www.google.com/favicon.ico (and all response data ICO content) Time 30: DNS lookup to www.yahoo.com (and all response data) Time 40: HTTP request to http://www.yahoo.com/ (and all response data to render this HTML content) Time 50: HTTP request to http://www.yahoo.com/favicon.ico (and all response data ICO content) So, at a very simple level, the logic needed to replay this back to the same browser would be: - Assume the "replay logic code" is running on a server that can is already configured to automatically intercept any and all traffic from the browser - Identify all *destination* TCP and *destination* UDP ports in the PCAP corresponding to the initial connection requests made by the browser to each server - For each source TCP/UDP port, create a "sequence array", where each entry in the array maps to the *content* that should be sent back to the browser *in that order*. To be clear, we don't care about absolute timestamps of content -- only that we return content in relative order, based upon how many times the browser has requested content via the matching destination TCP/UDP port. Example: udp_destination_port_53 = [ "Response content for www.google.com", "Response content for www.yahoo.com"] tcp_destination_port_80 = [ "Response content for http://www.google.com/";, "Response content for http://www.google.com/favicon.ico";, "Response content for http://www.yahoo.com/";, "Response content for http://www.yahoo.com/favicon.ico"; ] Then, for each initial connection, identify the destination port the browser is trying to contact and literally feed it the next element in the built array. Once all we reach the end of all the elements in all the arrays, we assume the browser has finished rendering all the content. So, my questions are: 1) Based on the simple solution I've described, are there any other factors my original assumptions did not take into account? In other words, could it work, given the original assumptions? 2) Could any of the tcpreplay code be used to accomplish a fraction of this goal? (Such as identifying and extracting the application layer content for each request to build the corresponding array entries?) Thanks again for your time, -- Darien ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Tcpreplay-users mailing list Tcpreplay-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tcpreplay-users Support Information: http://tcpreplay.synfin.net/trac/wiki/Support
