In this document I want to review a book my Chris Sanders, “Practical Packet Analysis”, published by “No Starch Press”. It took me about a week to read the whole book, and actually more time to revise what I have learnt and to write a review.
Chris Sanders: Practical Packet Analysis
So, what made me want to write about a book on packet analysis, and what is packet analysis in the first place? Well, speaking non-strictly, packets are the words of the Internet. Small-ish digestible pieces of information that computers exchange among themselves. Digestible here is a very good metaphor.
Suppose you are having a dinner, and together with your main food, you also have a glass of soda. Well, soda water is liquid, and can be consumed, in theory, continuously. However, it is hard to drink something continuously for a long time. People tend to swallow even liquid products gulp by gulp – that is, in portions.
Computers in this respect are surprisingly not different to humans. Even when communication appears to be continuous, (such as with the TCP/IP protocol), in reality it goes in small portions called “packets”.
Why would we need to analyse those packets at all? When, when communication goes well, and not problems are perceived, packet analysis is only needed by the networking professionals, for their professional purposes. However, when thing go South, even people who are non-experts, but simply want to debug their Internet connection, might need to try and see what is actually going in and out of their network card – packets.
Another case when packet analysis may be of value is when one is writing a distributed application (which I have been doing at my job), and needs to check whether network load is distributed evenly, or at least rationally over the network.
I ended up reading Chris Sanders’ book after skimming through a few similar ones in a library, and I have to say, there were quite a few alternatives. In fact, taught by my previous bitter experience, I had suspected that I would have to read more than one book on the topic. However, jumping ahead, I have to say that that is what really happened, but also that Practical Packet Analysis (PPA) turned out to be good enough of a book so that I didn’t have to read those additional books in their entirety; I only needed to consume a few chapters filling in the lacunae.
One more thing that I used as a heuristic when choosing PPA is that it is published by “No Starch Press”. I do not know how this is happening, but No Starch guys seem to always be able to publish really good handbooks on technologies, even if for sometimes very exotic technologies. (The only recent book on GNU Autotools is published by them!)
So, Practical Packet Analysis turned out to be a handy, simple, and, indeed, practical book. It does very little about explaining TCP/IP itself, offloading this duty to other books, for example, to “TCP/IP Illustrated” and “Internetworking with TCP/IP”.
What it does, however, it covers practical cases that a systems administrator debugging his system might be interested in: slow network, address conflicts, packet loss, name resolution failures, traffic hijacking by adversaries.
It does it by gradually, bit by bit, unfolding the GUI of the Wireshark packet capture tool. As Wireshark’s interface is quite naturally adapted for debugging certain kinds of network failures, going over it, screen after screen, allows to, at the same time, explain Wireshark’s usage, and comment on which issues led to the appearance of those screens, and how to resolve them.
For the cases when Wireshark does not have a suitable GUI page, it is possible to do simple packet capture, and to hand over the analysis of those packet dumps to some other tool.
Unfortunately, PPA does not talk much about analysing packets with a script. It does mention, thought that Wireshark has a plugin framework, and supports applying packet analysing scripts (which can be written in different languages) to packet streams being captured.
It also covers in the console usage of tshark (TUI Wireshark). I even ended up using it for some of my tasks, because some machines do not have a GUI. In addition to tshark, the same chapter also discusses tcpdump, the only other tool in the book.
Topics not covered
I was a bit disappointed by the fact that the book actually is saying almost nothing about reverse-engineering protocols. Its basic assumption is that whatever is going within a network either has been already defined in the Wireshark library, or has a description, say, in asn1, which can be converted to a Wireshark packet dissector with a little work.
However, the library that does network communication in my case, and which I need to debug, is not transparent, its protocol is not known, so there is no ready to use packet dissector. The book, however, does refer to the Wireshark’s official manual, which, seemingly, is quite decent and even exists in two volumes, one for the GUI, and one for writing dissectors, so the direction to head on after the end of the book becomes clear.
It also does not cover Wireshark’s GUI entirely, some features, were left as an exercise to reader. I do hope that they will be easy enough to grasp by oneself.
General impression and conclusion
I am a little disappointed that it does not mention mausezahn, the tool used by Linux kernel developers for testing network, and does not teach how to write a packet dissector, for example, for some very simple protocol.
I would recommend it as a homework for beginner network programmers, and network administrators.
Feedback and donate
I also have: