Archive for the ‘Packet Capture’ category

  1. TCP Analysis and the Five-Tuple

    The TCP expert of Wireshark is doing a pretty good job at pinpointing problems, helping analysts to find the packets where things go wrong. Unfortunately, there are some things that can throw the expert off pretty badly, which can fool inexperienced analysts in believing that there are big problems on the network. I did a […]
  2. Advanced display filtering

    Wireshark has a lot of display filters, and the filtering engine is really powerful. You can filter on almost anything in a packet, and ever since the filter box started suggesting possible filter expressions it got really easy to find the one you wanted.
  3. Working with multi-point captures

    Every now and then most analysts run into a troubleshooting situations where they need to capture the same packets at different locations in the network. Some reasons for such multi-point captures include having to determine if packets get delayed at some point in the network (this would be one of the few cases where “it […]
  4. Determining network protocols

    If you spent enough time using Wireshark or any other network analysis tool, you’ll sooner or later be able to even read bare hex dumps of packets, at least partially (it’s a little bit like Neo seeing the Matrix). So maybe you run across a text dump of a packet like this one: 0000  00 […]
  5. Diagnosing intermittent “network” problems

    There’s that one thing that customers usually ask, and that question is if I would be able to help diagnosing a problem on the network. My answer has two parts: If we can capture the problem situation in packets, I will find it When I find it, I’ll tell you if it’s a network problem […]
  6. Determining frame forwarding latency

    In some situations the question arises how much a frame was delayed by a device it has to pass through, e.g. firewalls, loadbalancers and sometimes even routers and switches. Usually, novice network analysts think that for that you need to synchronize the clocks of the capture PCs down to microseconds or even better, but that […]
  7. How millisecond delays may kill database performance

    Mike, an old buddy of mine is one of the best database application development consultants I have ever met. We worked together for the same company for a couple of years before I got into network analysis and he started his own company. A couple of months ago I found out that there was going […]
  8. The trouble with multiple capture interfaces

    The PCAPng file format Starting with Wireshark 1.8, the old PCAP format was replaced by PCAPng as the new default file format for packet captures. I have to admit that I may be one of the people to blame for this – at the end of Sharkfest 2011 we had a panel discussion with Gerald […]
  9. TCP Expert Updates in Wireshark 1.12

    Wireshark 1.12 has just arrived, and of course the first thing to do is to download and install the new version. The second thing to do should be to read the release notes.Nobody seems to do it, but everybody should. Okay, before I get to the TCP expert thing, let’s see why release notes are […]
  10. Determining TCP Initial Round Trip Time

    I was sitting in the back in Landis TCP Reassembly talk at Sharkfest 2014 (working on my slides for my next talk) when at the end one of the attendees approached me and asked me to explain determining TCP initial RTT to him again. I asked him for a piece of paper and a pen, […]