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
