[Dario Lombardo <dario.lombardo.ml@xxxxxxxxx>]

I've run it on the original 10G file (70M packets). It can't process all of them. At around 30M packets memory consumption is about 3.7G.

It's a good improvement anyway!

Thanks

Dario.

On Fri, Aug 30, 2013 at 3:35 AM, Evan Huus <eapache@xxxxxxxxx> wrote:

On Thu, Aug 29, 2013 at 11:07 AM, Dario Lombardo <dario.lombardo.ml@xxxxxxxxx> wrote:

On Thu, Aug 29, 2013 at 4:35 PM, Evan Huus <eapache@xxxxxxxxx> wrote:

Basically, but it's also more. If your capture contains a DNS packet resolving a name in a certain way, and the system name resolver gives a different answer, we prefer the DNS packet in the capture (since presumably the capture was on some local network where that name resolves differently). For this reason we can't just drop old cache entries unless name resolution is disabled completely.

That's really interesting. This means that if a DNS packet with a fake resolution is got, it can pollute the "cache". 

I've triggered this behaviour in the attached pcap file. It appears that I'm pinging google (in my svn wireshark), while actually I'm pinging a private addres :).

I have checked in an option for this in revision 51584 which should also solve your memory problem (or most of them). If you run that revision of tshark with the flag: -o dns.use_for_addr_resolution:FALSE then you should see substantially lower memory usage, (and your crafted capture won't resolve the internal address as google either). I left it enabled by default, since that was the existing behaviour, but I don't have a strong opinion one way or the other.

Cheers,
Evan

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe