Hi Prosiac, 1. Your dhcp.pcap has traffic from both the client and server. There is nothing wrong with that, but depending on how you use tcpreplay this may cause problems. Basically, if you are trying to replay traffic to a server, then you don't want to replay the server traffic too.
2. The easiest way to remove traffic from the server is to use tcpdump. Looking at your pcap something like: tcpdump -s0 -r dhcp.pcap -w dhcp-client.pcap ip src 0.0.0.0 3. Since the packets from the client to the server are broadcast packets, the destination MAC should be FF:FF:FF:FF:FF:FF. The source MAC should be that of your network card you're sending the traffic from via tcpreplay. 4. Earlier, you asked what "port" tcpreplay uses when sending the traffic. The answer is: whatever port is in the packets in the pcap file. You should open the pcap in Wireshark and look to see what the source port is or in the RFC which describes the DHCP protocol. Hope that helps. On Fri, Dec 16, 2011 at 8:20 AM, Prosiac Akin <cramped_ga...@yahoo.com> wrote: > I tried to do some steps and the results are shown in the file attached. > Hope you will understand and give me some advice. > > and to your comments > Seconde remark : as you are sending only these 4 packets: you need to know > that when the remote machin (server) gets the first packet (1) the servers > answers back in broadcast as the Destination adress is 255.255.255.255 > > ( I didn't understand what you mean) > > 3rd remark: as you are sending in only one way Client-> server : Then The 4 > above packets are sent in one direction !! Although it is in reality a > negociation between Client and server (so here may be you should use the > cache file!!!! to separate the 2 directions). > > (How to do this??) > > > > Any idea from that will be appreciated > > > > > ________________________________ > From: Ali Gouta <ali.go...@gmail.com> > To: Main forum for tcpreplay <tcpreplay-users@lists.sourceforge.net> > Sent: Friday, December 16, 2011 3:07 PM > > Subject: Re: [Tcpreplay-users] sending pcap files from one computer to > another using tcpreplay > > I think I understand what you are doing... well Here May be I can give you > some advices but not the solution as I never used L7 filter. > At first I opened up your pcap file: All what it contains is the dhcp > transaction: > > 1 0.000000 0.0.0.0 -> 255.255.255.255 DHCP DHCP Discover - > Transaction ID 0x3d1d > 2 0.000295 192.168.0.1 -> 192.168.0.10 DHCP DHCP Offer - Transaction > ID 0x3d1d > 3 0.070031 0.0.0.0 -> 255.255.255.255 DHCP DHCP Request - > Transaction ID 0x3d1e > 4 0.070345 192.168.0.1 -> 192.168.0.10 DHCP DHCP ACK - Transaction > ID 0x3d1e > > One advice is start to analyse other pcap files (you can generate one on > your own just make wireshark working while opening up some web > sites/videos..) And then replay the pcap file and see if L7 works or not. > > Seconde remark : as you are sending only these 4 packets: you need to know > that when the remote machin (server) gets the first packet (1) the servers > answers back in broadcast as the Destination adress is 255.255.255.255 > > 3rd remark: as you are sending in only one way Client-> server : Then The 4 > above packets are sent in one direction !! Although it is in reality a > negociation between Client and server (so here may be you should use the > cache file!!!! to separate the 2 directions). > > At last it seems you are dealing with iptables and that L7 filter is just a > module (extention). So in other words it might be that L7 filter doesn't fit > well with things you are doing (especially when using tcpreplay): Try to > have a look here : http://l7-filter.sourceforge.net/PacketFlow.png. > This may tell you something !! May be Aaroun may answer you cuz I really > don't have the correct answer ;) > > Good luck. > > > On Fri, Dec 16, 2011 at 2:03 PM, Prosiac Akin <cramped_ga...@yahoo.com> > wrote: > > i was trying to detect protocols of the traffic from L7 filter. for that i > need to create the real traffic for all the protocols listed on > http://l7-filter.sourceforge.net/protocols. > > Since, i couldn't create the real traffic flow for protocol detection with > the help of L7 filter. I decided to opt the pcap files of such protocols. > Therefore, i thought of replaying that pcap file on the network and inject > it back to the L7 filter for its protocol detection (as i assumed that the > protocols information are already stored in the pcap files). > > In real scenario, now to check whether the traffic according to its > respective protocols is matched or not. I have to issue this command > > :~$ sudo iptables -t mangle -A PREROUTING -p udp --sport 53 -j NFQUEUE > --queue-num 0 > > and checked with another command whether it is being listed or not > > :~$ sudo iptables -t mangle -L (To list the filter rules on mangle table) > Chain PREROUTING (policy ACCEPT) > target prot opt source destination > NFQUEUE udp -- anywhere anywhere udp spt:domain > NFQUEUE num 0 > > here, the L7 filter is listening to the source port of 53 which dns uses. > > And when i issue another command > :~$ nslookup google.com > Server: 192.168.234.2 > Address: 192.168.234.2#53 > > it generates the dns packets (which is seen through wireshark), and the L7 > filter will check all the .pat files which is listed on its > /etc/l7.conf, where dns is given some value (for example: dns 7 ) . When its > gets the information that is required to match the flow of packets as dns, > then its says "matched and with the mark 0x00007" which is the same value as > provided for dns in l7.conf file. Hence, i can be sure that the packets are > being matched with the corresponding protocols. > > The same command > sudo iptables -t mangle -A PREROUTING -p udp --sport 53 -j NFQUEUE > --queue-num 0 > > can be used to listen to the ports in the computer where L7 filter is > running with the simple change > sudo iptables -t mangle -A PREROUTING -i eth0 -p tcp --dport 1024: -j > NFQUEUE --queue-num 0 > (To detect all the protocol which use ports above 1024 to 65000 on the host > running l7 filter) > > > So, with this idea, i thought that with tcpreplay (as it replayed the pcap > files), if i am able to inject traffic to L7 filter, the same protocols > (like in the real case) would be detected. And for that, i first thought of > sending only the packets from one computer to another. On this case, yes the > below command worked. > > > sudo tcprewrite --enet-dmac=00:19:D1:07:0F:73 --enet-smac=00-24-8C-0B-CA-A2 > --infile=dhcp.pcap --outfile=output.pcap > and > sudo tcpreplay --intf1=eth0 "output.pcap" > > and now i am thinking to inject this "output.pcap" file to the L7 filter. > once i send packets through tcpreplay from computer having mac > 00-24-8C-0B-CA-A2, the packets are being displayed as it was, through > wireshark on the destination computer. And now i let my L7 filter run, > however, at this point it is not detecting its packets that the original > hosted pcap file was of DHCP. > > Therefore, i asked you that question, as in both commands, it is neither > telling me the information about source port or destination port. So at this > stage L7 filter will not understand from where and what types of packets are > coming. As mentioned above, it (L7) listens to port above 1024 from its own > platform and if we are listening to server incoming packets we have to > specify the source port. > > And to your saying > "the capture contains ports associated to trafic that was captured WHILE > generating the initial pcap file." I looked at my dhcp.pcap file which is > attached herewith my email. It is using port sport 68 and dport 67. > So at this stage, how can i play with tcpreplay so that L7 filter will > understand the packets and start its detection saying "OK, now it is DHCP > packets and let me mark it as DHCP with the number provided in /etc/l7.conf > )?? > > > I hope now you understand what am i trying to do and where am i having > confusion. > > > > > > > > > > > > > ________________________________ > From: Ali Gouta <ali.go...@gmail.com> > To: Main forum for tcpreplay <tcpreplay-users@lists.sourceforge.net> > Sent: Friday, December 16, 2011 12:45 PM > > Subject: Re: [Tcpreplay-users] sending pcap files from one computer to > another using tcpreplay > > I don't think that tcpreplay operates on the 4th layer means that it won't > be possible to change origin ports!!! > the capture contains ports associated to trafic that was captured WHILE > generating the initial pcap file. > So saying on which ports tcpreplay listens/responds have no sens cause it > depends on ports used when generating the pcap file. > > I don't know exactly what you are looking for, but what would be the purpose > of changing ports ??? thus if you will change ports then Wireshark will give > wrong results on the server side. As for identifying an http application => > we need port 80. If you will change it to other port you may blows up > everything... and http won't be identified. > > On Fri, Dec 16, 2011 at 12:28 PM, Prosiac Akin <cramped_ga...@yahoo.com> > wrote: > > Hello there, > > sudo tcprewrite --enet-dmac=00:19:D1:07:0F:73 --enet-smac=00-24-8C-0B-CA-A2 > --infile=dhcp.pcap --outfile=output.pcap > and > sudo tcpreplay --intf1=eth0 "output.pcap" > > from normal pc (without virtualization). The packets are seen on the > wireshark on the destination computer with mac 00:19:D1:07:0F:73. I am > working on why from virtualization pc, it is not working. > > If i am not wrong, my understanding of above command is > For ex: "output.pcap" file is being replayed by the computer with mac > 00-24-8C-0B-CA-A2 with interface eth0 and is destined to the computer having > mac 00:19:D1:07:0F:73. > > Now, my question is. > 1. Can you please tell me on which particular port does tcpreplay > listens/responds while communicating b/w 2 computers?? > 2. Is it possible to define port mannually while issuing the commands when > the packets are replayed to desired computer ??? > > like dns uses port 53. The client requests from a random port above 1023 to > server port 53. The servers response from port 53 to the originating port > the client was questioning on. So is there any mechanism to define ports > mannually ???? > > ________________________________ > From: Aaron Turner <synfina...@gmail.com> > To: Main forum for tcpreplay <tcpreplay-users@lists.sourceforge.net> > Sent: Thursday, December 15, 2011 11:06 PM > > Subject: Re: [Tcpreplay-users] sending pcap files from one computer to > another using tcpreplay > > Could be... I dunno. VMWare has to do some tricks for the networking > to work, and it's quite possible that it's not compatible with > tcpreplay. It may also depend on if you're using NAT, Routed or > Transparent on the virtual host. Your best chance of getting things > working would be transparent since NAT/Routed would place you on > different L2 broadcast networks which would definitely break things. > > On Thu, Dec 15, 2011 at 1:43 PM, Ali Gouta <ali.go...@gmail.com> wrote: >> I think it is because there is no way where to send the in coming packet: >> in >> other words you need to fullfill the routing table on the server side. If >> you have 2 Nic cards on the server side (1 connected to eth0 of the >> client) >> and the other is free. Try to add a route in the routing table to the free >> interface (mean the other interface not the one connected to eth0) At That >> moment the packet might be seen ... Try and tell us. >> If you have only one card on the server side try to add a route which says >> all incoming packet from ethX (of the server related to eth0) will be sent >> back to eth0. And see what it gives. >> >> the command to add a route is: route xxxxxx (look for it) >> >> Good luck >> >> >> On Thu, Dec 15, 2011 at 10:00 PM, Prosiac Akin <cramped_ga...@yahoo.com> >> wrote: >>> >>> Hello there, >>> >>> the output of the command >>> sudo tcprewrite --enet-dmac=00:19:D1:07:0F:73 >>> --enet-smac=00-24-8C-0B-CA-A2 --infile=dhcp.pcap --outfile=output.pcap >>> >>> and >>> >>> sudo tcpreplay --intf1=eth0 "output.pcap" >>> >>> Output >>> ---------- >>> sending out eth0 >>> processing file: output.pcap >>> Actual: 4 packets (1312 bytes) sent in 0.07 seconds >>> Rated: 18742.9 bps, 0.14 Mbps, 57.14 pps >>> Statistics for network device: eth0 >>> Attempted packets: 4 >>> Successful packets: 4 >>> Failed packets: 0 >>> Retried packets (ENOBUFS): 0 >>> Retried packets (EAGAIN): 0 >>> >>> And on the destination PC with mac 00:19:D1:07:0F:73, i was not able to >>> see the 4 packets of DHCP through wireshark >>> >>> ________________________________ >>> From: Aaron Turner <synfina...@gmail.com> >>> To: Main forum for tcpreplay <tcpreplay-users@lists.sourceforge.net> >>> Sent: Thursday, December 15, 2011 9:39 PM >>> >>> Subject: Re: [Tcpreplay-users] sending pcap files from one computer to >>> another using tcpreplay >>> >>> On Thu, Dec 15, 2011 at 11:08 AM, Prosiac Akin <cramped_ga...@yahoo.com> >>> wrote: >>> > i followed your instructions with the commands mentioned below >>> > tcprewrite --enet-dmac=00:55:22:AF:C6:37 --enet-smac=00:44:66:FC:29:AF >>> > --infile=input.pcap --outfile=output.pcap >>> > >>> > tcpreplay --intf1=eth0 "output.pcap" >>> > >>> > no error was seeen with this command, however, i cannot see the packets >>> > through wireshark. >>> >>> What is the report at the end of the tcpreplay command? How many >>> packets were sent? >>> >>> > Is it because i am doing this all in Vmware platform??? ( I am using >>> > the >>> > virtual mac address for smac taken from ubuntu installed in vmware). If >>> > yes, >>> > what could be its possible solution??? >>> >>> Honestly, I don't use VMWware so I don't know, but it's quite possible. >>> >>> > (I was wondering about its usage. can you please clarify me what this >>> > command is actually doing. Why do we need that --outfile??? Even if we >>> > give >>> > the same pcap name as input.pcap, the command works fine. So i am >>> > really >>> > confused) >>> >>> --outfile is for specifying the new, modified pcap file name. If you >>> don't specify --outfile and tcprewrite doesn't complain that it's a >>> required option, then that's a bug and you likely have an old version >>> of tcprewrite (I don't believe the current version has this bug). You >>> really shouldn't use the same value as infile as bad things will >>> likely happen (you'll probably truncate the pcap so it has no packets) >>> which may explain why wireshark didn't see any. >>> >>> -- >>> 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" >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> 10 Tips for Better Server Consolidation >>> Server virtualization is being driven by many needs. >>> But none more important than the need to reduce IT complexity >>> while improving strategic productivity. Learn More! >>> http://www.accelacomm.com/jaw/sdnl/114/51507609/ >>> _______________________________________________ >>> 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 >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> 10 Tips for Better Server Consolidation >>> Server virtualization is being driven by many needs. >>> But none more important than the need to reduce IT complexity >>> while improving strategic productivity. Learn More! >>> http://www.accelacomm.com/jaw/sdnl/114/51507609/ >>> _______________________________________________ >>> 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 >> >> >> >> >> ------------------------------------------------------------------------------ >> 10 Tips for Better Server Consolidation >> Server virtualization is being driven by many needs. >> But none more important than the need to reduce IT complexity >> while improving strategic productivity. Learn More! >> http://www.accelacomm.com/jaw/sdnl/114/51507609/ >> _______________________________________________ >> 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 > > > > -- > 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" > > ------------------------------------------------------------------------------ > 10 Tips for Better Server Consolidation > Server virtualization is being driven by many needs. > But none more important than the need to reduce IT complexity > while improving strategic productivity. Learn More! > http://www.accelacomm.com/jaw/sdnl/114/51507609/ > _______________________________________________ > 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 > > > > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > _______________________________________________ > 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 > > > > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > _______________________________________________ > 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 > > > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > _______________________________________________ > 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 > > > > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > _______________________________________________ > 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 > > > ------------------------------------------------------------------------------ > Learn Windows Azure Live! Tuesday, Dec 13, 2011 > Microsoft is holding a special Learn Windows Azure training event for > developers. It will provide a great way to learn Windows Azure and what it > provides. You can attend the event by watching it streamed LIVE online. > Learn more at http://p.sf.net/sfu/ms-windowsazure > _______________________________________________ > 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 -- 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" ------------------------------------------------------------------------------ Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure _______________________________________________ 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
