DNS lookups not showing up #423

fklassen · 2017-10-20T23:38:44Z

For now, just dumping the conversation from the mailing list ....

Ah, didn't realize there were two more commands... just saw the
tcpprep and my brain turned off.

The problem right now for me is that:

tcpprep --auto=client --cachefile=query.cache --pcap=queries-ipv4-new.pcap

is generating an invalid cache file:

$ tcpprep -S query.cache

Fatal Error: Cache data length (256 bytes) doesn't match cache header
(25000 bytes). looks like a bug in 4.2.6.

Anyways, that's not your problem though.

Your problem is you're mapping the traffic from port 53 to 50068 and
now tcpdump doesn't think it is DNS traffic and doesn't decode it.
The data is still there though if you use the -A flag:

$ tcpdump -c 1 -r queries-ipv4-READY.pcap -A
reading from file queries-ipv4-READY.pcap, link-type EN10MB (Ethernet)
07:11:14.228108 IP localhost.50471 > localhost.50068: UDP, length 36
E..@....@.|..........'...,.s.............robotmatchunit.com.....

--
Aaron Turner
https://synfin.net/ Twitter: @synfinatic
My father once told me that respect for the truth comes close to being
the basis for all morality. "Something cannot emerge from nothing,"
he said. This is profound thinking if you understand how unstable
"the truth" can be. -- Frank Herbert, Dune

On Fri, Oct 20, 2017 at 3:53 PM, Felipe Agnelli Barbosa
[email protected] wrote:
Aaron, the problem occour after, in the next command of the my previous
email.

On Oct 20, 2017 8:01 PM, "Aaron Turner" [email protected] wrote:

Works for me on 4.2.6:

$ tcprewrite --dlt=enet --enet-smac=09:09:09:09:09:09
--enet-dmac=01:02:03:04:05:06 -i ~/Downloads/queries-ipv4.pcap -o
test.pcap

$ tcpdump -r test.pcap -c1 -v
reading from file test.pcap, link-type EN10MB (Ethernet)
07:11:14.228108 IP (tos 0x0, ttl 64, id 1, offset 0, flags [none],
proto UDP (17), length 64)
localhost.50471 > localhost.domain: 0 NS? robotmatchunit.com. (36)

$ tcprewrite -V
tcprewrite version: 4.2.6 (build git:v4.2.6)
Copyright 2013-2017 by Fred Klassen -
AppNeta
Copyright 2000-2012 by Aaron Turner
The entire Tcpreplay Suite is licensed under the GPLv3
Cache file supported: 04
Compiled against libdnet: 1.12
Compiled against libpcap: libpcap version 1.8.1 -- Apple version 67.60.1
64 bit packet counters: enabled
Verbose printing via tcpdump: enabled
Fragroute engine: enabled

--
Aaron Turner
https://synfin.net/ Twitter: @synfinatic
My father once told me that respect for the truth comes close to being
the basis for all morality. "Something cannot emerge from nothing,"
he said. This is profound thinking if you understand how unstable
"the truth" can be. -- Frank Herbert, Dune

On Thu, Oct 19, 2017 at 6:10 AM, Felipe Agnelli Barbosa
[email protected] wrote:
Hi Aaron,

Follow the commands and the comments:

tcprewrite --dlt=enet --enet-dmac="MAC" --enet-smac="MAC" -i
queries-ipv4.pcap[0] -o queries-ipv4-new.pcap

The pcap file queries-ipv4-new.pcap originated contains the dns queries.

tcpprep --auto=client --cachefile=query.cache
--pcap=queries-ipv4-new.pcap
tcprewrite -C --portmap=53:50068 --endpoints=192.168.0.3:10.153.0.17
--cachefile=query.cache -i queries-ipv4-new.pcap -o
queries-ipv4-READY.pcap

Here, with the pcap file queries-ipv4-READY.pcap, the problem that I
mentioned happens.

[0]

https://www.dropbox.com/sh/qhulhpfr2fcvghj/AACv81C0s7OecBuF1l8x806Aa?dl=0

Regards,

[]s
Felipe

2017-10-19 0:44 GMT-02:00 Aaron Turner [email protected]:

Smells like a bug, but could be an issue where your pcap file
incorrectly states the packet length. If you could share the pcap
file (dropbox/etc link preferred) and the tcprewrite command you ran
that would be useful.

Aaron Turner
https://synfin.net/ Twitter: @synfinatic
My father once told me that respect for the truth comes close to being
the basis for all morality. "Something cannot emerge from nothing,"
he said. This is profound thinking if you understand how unstable
"the truth" can be. -- Frank Herbert, Dune

On Wed, Oct 18, 2017 at 8:17 AM, Felipe Agnelli Barbosa
[email protected] wrote:
Hi guys,

I have working with tcpreplay suite and I find something interesting
that I
can't explain until now.

My environment is made of one pcap file that I use tcprewrite to
replace
source/destiny IP, MAC and the pcap file originated does not contain
the
dns
query, like:

Before tcprewrite modification:

13:00:00.000181 IP 192.168.0.3.18418 > 10.153.0.17.53: 42386 [1au] A?
www.example.com. (47)

After:

13:00:00.000181 IP 192.168.0.3.18418 > 10.153.0.17.50073: UDP, length
47

I got to see this with tcpdump.

Has anyone ever experienced this?

Bellow some more informations.

lsb_release -a

No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.3 LTS
Release: 16.04
Codename: xenial

tcpreplay -V

tcpreplay version: 4.2.5 (build git:v4.2.5)
Copyright 2013-2017 by Fred Klassen -
AppNeta
Copyright 2000-2012 by Aaron Turner
The entire Tcpreplay Suite is licensed under the GPLv3
Cache file supported: 04
Not compiled with libdnet.
Compiled against libpcap: 1.7.4
64 bit packet counters: enabled
Verbose printing via tcpdump: enabled
Packet editing: disabled
Fragroute engine: disabled
Injection method: PF_PACKET send()
Not compiled with netmap

tcpdump --v

tcpdump version 4.9.0
libpcap version 1.7.4
OpenSSL 1.0.2g 1 Mar 2016

Regards,
Felipe