On Mon, Jul 18, 2011 at 5:08 PM, Mike Komer <[email protected]> wrote: > PROBLEM 1 > > tcpprep does not recognize a returning packet. This seems unique to UDP. > Perhaps it is not autmoatically assuming the dst is the server? > > # tcpdump -nn -tqr udp.cap > reading from file udp.cap, link-type EN10MB (Ethernet) > IP 192.168.1.101.3097 > 210.22.14.9.3076: UDP, length 25 > IP 210.22.14.9.3076 > 192.168.1.101.3097: UDP, length 108 > # tcpprep --auto=client --cachefile=input.cache --pcap=udp.cap > # tcpprep --print-info=input.cache > Packet 1 -> Secondary > Packet 2 -> Secondary > # tcpprep --auto=client --cachefile=input.cache --ratio=1.0 --pcap=udp.cap > # tcpprep --print-info=input.cache > Packet 1 -> Secondary > Packet 2 -> Secondary
Mind sending me that pcap so I can reproduce this issue? In the meantime, you could prolly use --port instead of --auto to split the traffic correctly. > > > PROBLEM 2 > > In this case, the 172.16.8.233 address is not rewritten. The same command > format works on other packet captures. srcipmap/dstipmap do not appear to > take multiple pairs. Plus it would require two writes to get src and dst. > For this problem, the order of the pairs does not matter. The 172.16.8.233 > address fails to rewrite. > > # tcpdump -nn -tqr tcp.cap > reading from file tcp.cap, link-type EN10MB (Ethernet) > IP 172.16.8.233.1152 > 172.16.8.58.1521: tcp 0 > IP 172.16.8.58.1521 > 172.16.8.233.1152: tcp 0 > IP 172.16.8.233.1152 > 172.16.8.58.1521: tcp 0 > IP 172.16.8.233.1152 > 172.16.8.58.1521: tcp 260 > IP 172.16.8.58.1521 > 172.16.8.233.1152: tcp 8 > ... > > # tcprewrite --skipbroadcast > --pnat=172.16.8.233/32:192.168.129.1/32,172.16.8.58/32:192.168.1.0/32 > --infile=tcp.cap --outfile=rewrite.cap > > # tcpdump -nn -tqr rewrite.cap > reading from file rewrite.cap, link-type EN10MB (Ethernet) > IP 172.16.8.233.1152 > 192.168.1.0.1521: tcp 0 > IP 192.168.1.0.1521 > 172.16.8.233.1152: tcp 0 > IP 172.16.8.233.1152 > 192.168.1.0.1521: tcp 0 > IP 172.16.8.233.1152 > 192.168.1.0.1521: tcp 260 > IP 192.168.1.0.1521 > 172.16.8.233.1152: tcp 8 > ... > > Nothing gets rewritten here. > > # tcpdump -nn -tqr udp2.cap; tcprewrite --skipbroadcast > --srcipmap=68.119.66.249/32:1.1.1.1/32,45.13.14.233/32:2.2.2.2/32 > --infile=udp2.cap --outfile=rewrite.cap ; tcpdump -nn -tqr rewrite.cap > reading from file udp2.cap, link-type EN10MB (Ethernet) > IP 68.119.66.249.15848 > 45.13.14.233.12324: UDP, length 25 > IP 68.119.66.249.15848 > 45.13.14.233.12324: UDP, length 25 > IP 45.13.14.233.12324 > 68.119.66.249.15848: UDP, length 533 > IP 45.13.14.233.12324 > 68.119.66.249.15848: UDP, length 533 > reading from file rewrite.cap, link-type EN10MB (Ethernet) > IP 68.119.66.249.15848 > 45.13.14.233.12324: UDP, length 25 > IP 68.119.66.249.15848 > 45.13.14.233.12324: UDP, length 25 > IP 45.13.14.233.12324 > 68.119.66.249.15848: UDP, length 533 > IP 45.13.14.233.12324 > 68.119.66.249.15848: UDP, length 533 > # tcpdump -nn -tqr udp2.cap; tcprewrite --skipbroadcast > --pnat=68.119.66.249/32:1.1.1.1/32,45.13.14.233/32:2.2.2.2/32 > --infile=udp2.cap --outfile=rewrite.cap ; tcpdump -nn -tqr rewrite.cap > reading from file udp2.cap, link-type EN10MB (Ethernet) > IP 68.119.66.249.15848 > 45.13.14.233.12324: UDP, length 25 > IP 68.119.66.249.15848 > 45.13.14.233.12324: UDP, length 25 > IP 45.13.14.233.12324 > 68.119.66.249.15848: UDP, length 533 > IP 45.13.14.233.12324 > 68.119.66.249.15848: UDP, length 533 > reading from file rewrite.cap, link-type EN10MB (Ethernet) > IP 68.119.66.249.15848 > 45.13.14.233.12324: UDP, length 25 > IP 68.119.66.249.15848 > 45.13.14.233.12324: UDP, length 25 > IP 45.13.14.233.12324 > 68.119.66.249.15848: UDP, length 533 > IP 45.13.14.233.12324 > 68.119.66.249.15848: UDP, length 533 Odd that it doesn't work with certain IP addresses, but is fine with others. Never noticed that before. Send me the pcap if you can? -- Aaron Turner http://synfin.net/ Twitter: @synfinatic http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin "carpe diem quam minimum credula postero" ------------------------------------------------------------------------------ Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ _______________________________________________ Tcpreplay-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tcpreplay-users Support Information: http://tcpreplay.synfin.net/trac/wiki/Support
