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 the upcoming Sharkfest 2013, I got a trace sample from Landi that he wanted me to take a look at because he wondered about some SSL decoding stuff. So I did, and while we were talking about what the SSL dissector was doing I saw a new TCP expert message I had never seen before: “TCP Spurious Retransmission”.

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 already running for a couple of days in front of the firewall using a capture filter set to the server IP, recording everything that the server sent or received to and from the internet. So basically I wanted to separate good from bad traffic, if any, and see what was transferred.

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, and often I enable network layer name resolution, but I really do not like protocol name resolution. Oh, and then there is GeoIP resolution, which is really helpful in some cases as well, but it takes a little time to set it up.

Update: There’s a newer article for GeoIP setup in Wireshark 2.x here.

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 reason, we even grab a network TAP and an additional “known good” PC to capture the packets, just to make sure that no malware is hiding packets from us. Sometimes we also let some program run to see what it does while the user doesn’t do anything. And as my buddy and “trace connoisseur” Eddi (also, one of the most paranoid IT people I know ;)) always says: “You need to be able to explain each and every packet that goes in and out of your PC.”

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 all installations that run on Enterprise or less do not get these and have to stick with standard vSwitches.

Firewall trouble

A few days ago my connection(s) to the computing center suddenly degraded, meaning that I suddenly could not contact some of my servers anymore or only after waiting for sometimes minutes, while others worked fine. I checked the Icinga monitoring system and saw that everything was fine, except the firewall, which seemed to have a lot more latency than usual when forwarding packets. Then, my provider sent me and email that his own monitoring system was seeing problems with my firewall, too, and shortly after that a SMS arrived telling me that it seemed to have gone belly up. Uh oh.