Archive for the ‘Packet Capture’ category

  1. Sharkfest 2013 Recap

    Yesterday I returned from the annual Wireshark conference, Sharkfest 2013, and once again it has been a great conference. I had four talks (well, actually I had three, but one was scheduled to run twice and it looks like I never do a talk the same way), and one of them I did together with […]
  2. Spurious Retransmissions

    Update: since Wireshark version 1.12 is out, lots of people look for the meaning of “tcp spurious retransmission” info message, so I changed the post a little to make it easier to find what you’re looking for. Today, while doing a lot of testing of my trace handling code as well as in preparation for […]
  3. Name Resolution Denial of Service

    Today I was using a combination of dumpcap and Wireshark to run a network forensics investigation against a server that may have been compromised. A couple of malicious files had been reported by the virus scanner, so I had to take a closer look at what it was doing in the network. Actually, dumpcap was […]
  4. The notorious Wireshark “Out of Memory” problem

    It is one of the most common question on the Wireshark Q&A site: “I have xyz gigabyte of memory, but still Wireshark crashes when I try to capture data”, with xyz being a more or less impressive (or even ridiculous) amount of memory. This is how a typical crash looks like (your mileage may vary):
  5. Wireshark GeoIP resolution setup

    One of the many features Wireshark provides is the name resolution for various protocol layers, and I have to admit that – at least for me – some of them are really helpful while others (well, one of them, to be more specific) annoy the hell out of me. I really like MAC layer resolution, […]
  6. Capturing damaged frames

    One of the questions that I often got in my network analysis classes was how to capture damaged frames. It is an obvious thing to ask, since frames with bad checksums will most certainly have to be retransmitted or are at least a nice indicator that something went wrong while transporting the frame.
  7. The packet analysts “self check”

    One thing all members of our packet analysis team do every once in a while is to check what their own laptop/PC is doing on the network – meaning, that we just close all programs and run Wireshark to see what packets are still going in and out. If we’re in paranoid mode for some […]
  8. Learning something new every day…

    Today, a question was posted on ask.wireshark.org, about Wireshark becoming more than just a packet analyzer since it could already read MP3, JPG and other file formats.
  9. Capturing packets of VMware machines, part 2

    In the first post I described how to capture packets in VMware vSphere environments when dealing with standard vSwitches. While that works fine, some larger installations have an even better way of doing network captures of virtual machine traffic, provided by the so-called Distributed vSwitches. Unfortunately, those special vSwitches require a Enterprise Plus license, so […]
  10. Capturing packets of VMware machines, part 1

    I have always been the guy in our network analysis team responsible for the actual capture of network packets. I bought all the recording hardware we used, acquired network TAPs of all sorts and speeds, and did most of the planning of where to put which engine.