In brief,
No.
Too brief?
No. tcpreplay never reads any traffic. It'll replay the SYN. the server
will see the SYN, and generate a new SYN-ACK, which tcpreplay won't do
anything about because it never reads any traffic. It'll go ahead to
blindly replay the original ACK, but the server will ignore it and reply
with an RST, because a valid ACK must use a sequence number from the real
SYN-ACK, which it never saw. The TCP three-way handshake was originally
designed to prevent accidentally wandering echoes of packets from being
accepted, but it effectively guarantees that tcpreplay cannot establish a
connection, by design.
On Apr 4, 2012 6:34 AM, "Senthil Kumar S" <senthilkuma...@sasken.com>
wrote:
> Give me a quick reply please..****
>
> ** **
>
> If I add proper routes in the DUT, then the communication between Client
> and Server will be real ??****
>
> ** **
>
> Does it mean, tcpreplay will start traffic in this order SYN, SYN-ACK, ACK
> ??. what if any packet gets missed (ex: SYN-ACK) ??****
>
> ** **
>
> *Regards,
> **S. Senthil kumar*****
>
> ****
>
> * *
>
> ** **
>
> *From:* Ali Gouta [mailto:ali.go...@gmail.com]
> *Sent:* Wednesday, April 04, 2012 12:51 PM
> *To:* Main forum for tcpreplay
> *Subject:* Re: [Tcpreplay-users] tcpreplay Client Server communication****
>
> ** **
>
> Did you add new entries in the routing table of the DUT ?****
>
> command to be prompt: route **********
>
> on advice: try using tshark instead wireshark.****
>
> good luck.****
>
> ** **
>
> On Wed, Apr 4, 2012 at 7:51 AM, Senthil Kumar S <senthilkuma...@sasken.com>
> wrote:****
>
> Let me explain how the setup looks like with some more details,****
>
> ****
>
> TCPReplay PC DUT****
>
> ****
>
> eth0: 10.2.12.156 DUT-eth0: 10.2.12.152****
>
> MAC: 44:37:e6:0f:e1:54 DUT-MAC: 00:16:76:c1:32:DA****
>
> ****
>
> eth1:192.168.0.100 DUT-eth1: 192.168.0.101****
>
> MAC: 00:1c:f0:94:a4:3f DUT-MAC: 00:e0:1c:3c:2f:a6****
>
> ****
>
> My application runs on the DUT. The pcap files have Server-Client traffic
> with ip addresses, 10.2.12.152 & 192.168.0.101, accordingly the MAC
> addresses.****
>
> ****
>
> This pcap file was pumped from the "TCPReplay PC". Isn't that correct ??
> if not, what change I have to do??****
>
> ****
>
> Pls help me.****
>
> ****
>
> *Regards,
> **S. Senthil kumar*****
>
> ****
>
> * *****
>
> ****
>
> *From:* Senthil Kumar S
> *Sent:* Wednesday, April 04, 2012 9:49 AM****
>
>
> *To:* Main forum for tcpreplay****
>
> *Subject:* RE: [Tcpreplay-users] tcpreplay Client Server communication****
>
> ****
>
> I changed the MAC address to match the MACs of the DUT. Two instances of
> wireshark were used. One listens to eth0 and another listens to eth1.****
>
> ****
>
> *Regards,
> **S. Senthil kumar*****
>
> ****
>
> * *****
>
> ****
>
> *From:* Panos Kampanakis [mailto:pan...@gmail.com]
> *Sent:* Wednesday, April 04, 2012 8:51 AM
> *To:* Main forum for tcpreplay
> *Subject:* Re: [Tcpreplay-users] tcpreplay Client Server communication****
>
> ****
>
> What is the destination MAC? Could it be that Wireshark is listening
> in promiscuous mode but the dest mac is not the DUT NIC's MAC so the NIC
> and thus the application don't see the packets?****
>
> ****
>
> ****
>
> ****
>
> On Tue, Apr 3, 2012 at 3:19 AM, Senthil Kumar S <senthilkuma...@sasken.com>
> wrote:****
>
> Hi All,****
>
> ****
>
> I am using tcpreplay- version 3.4.4.****
>
> ****
>
> The usage is like Client - Server packets go in one interface(eth0),
> Server - Client traffic goes in another interface(eth2).****
>
> ****
>
> DUT is another PC having two interfaces. Packets sent using tcpreplay are
> received in the DUT (wireshark displays all the packets), but my
> application running in the DUT does not receive or see any packets.****
>
> ****
>
> Why is this behavior ??.****
>
> What I should do, so that my application under test can see the packets ??
> ****
>
> ****
>
> Any help is appreciated.****
>
> ****
>
> *Regards,
> **S. Senthil kumar*****
>
> ****
>
> * *****
>
> ****
>
> ****
> ------------------------------
>
> SASKEN BUSINESS DISCLAIMER: This message may contain confidential,
> proprietary or legally privileged information. In case you are not the
> original intended Recipient of the message, you must not, directly or
> indirectly, use, disclose, distribute, print, or copy any part of this
> message and you are requested to delete it and inform the sender. Any views
> expressed in this message are those of the individual sender unless
> otherwise stated. Nothing contained in this message shall be construed as
> an offer or acceptance of any offer by Sasken Communication Technologies
> Limited ("Sasken") unless sent with that express intent and with due
> authority of Sasken. Sasken has taken enough precautions to prevent the
> spread of viruses. However the company accepts no liability for any damage
> caused by any virus transmitted by this email.
> Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html****
>
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> 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****
>
> ****
>
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> 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****
>
> ** **
>
>
> ------------------------------------------------------------------------------
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> _______________________________________________
> 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
>
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
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
