Customer Reviews

Practical Packet Analysis: Using Wireshark to Solve Real-World Network Problems

5 star:		(5)
4 star:		(3)
3 star:		(3)
2 star:		(2)
1 star:		(0)

 

 

To use "American Idol" lingo, you've already read reviews by Randy Jackson and Paula Abdul. It's time for the truth from Simon Cowell -- Practical Packet Analysis (PPA) is a disaster. I am not biased against books for beginners; see my five star review of Computer Networking by Jeanna Matthews. I am not biased against author Chris Sanders; he seems like a nice guy who is trying to write a helpful book. I am not a misguided newbie; I've written three books involving traffic analysis. I did not skim the book; I read all of it on a flight from San Jose to Washington Dulles. I do not dislike publisher No Starch; I just wrote a five star review for Designing BSD Rootkits by Joseph Kong.

PPA is written for beginners, or at least it should be intended for beginners givens its subject matter. It appears the author is also a beginner, or worse, someone who has not learned fundamental networking concepts. This situation results in a book that will mislead readers who are not equipped to recognize the numerous technical and conceptual problems in the text. This review will highlight several to make my point. These are not all of the problems in the book.

p 21: This is painfully wrong on multiple levels: "When one computer needs to send data to another, it sends an ARP request to the switch it is connected to. The switch then sends an ARP broadcast packet to all of the computers connected to it... The switch now has a route established to that destination computer... This newly obtained information is stored in the switch's ARP cache so that the switch does not have to send a new ARP broadcast every time it needs to send data to a computer." This misconception is aggravated on p 62 in the discussion of ARP.

p 65, Figure 6-5: The TCP three way handshake is not SYN - ACK - SYN.

p 78, Figure 7-3: The TCP three way handshake is not SYN - ACK - ACK.

p 79: Packet 5 is not "the packet that was lost and is now being retransmitted." Packet 2 is.

p 80: There is no "ICMP type 0, code 1 packet."

p 85: This boggles the mind: "Immediately after that ARP packet, we see a bunch of NetBIOS traffic... If that other IP address wasn't a sign that something is wrong, then all of this NetBIOS traffic definitely is. NetBIOS is an older protocol that is typically only used as a backup when TCP/IP isn't working. The appearance of NetBIOS traffic here means that since Beth's computer was unable to successfully connect to the Internet with TCP/IP, it reverted back to NetBIOS as an alternate means of communication -- but that also failed. (Anytime you see NetBIOS on your network, it is often a good sign that something is not quite right.)"

p 85: This "troubleshooting" example highlights the different default gateways for Barry and Beth as being the "biggest anomaly" causing Beth's computer to not work. The author ignores the fact that Barry and Beth have computers with the same MAC addresses.

p 89: Traces recorded at a client and server are compared. The author says "The two capture files look amazingly similar; in fact, the only difference between the two files is that the source and destination addresses on the SYN packets have been switched around." Good grief.

p 106: Another "troubleshooting" scenario wonders if a "slow network" problem is related to the fact that tracerouting out from a host fails to produce a response from the router. However, the traceroute continues past the router, so connectivity exists (missed by the author). He says "we know our problem lies with our network's internal router because we were never able to receive an ICMP response from it. Routers are very complicated devices, so we aren't going to delve into the semantics of exactly what is wrong with the router."

pp 107-8: Yet another "troubleshooting" issue wonders why seemingly "double packets" are seen while sniffing on a host. The author wonders if "misconfigured port mirroring" could be the problem, ignoring his statement that the trace was collected on the host in question. He doesn't notice that each "double packet" has a unique MAC address pairing, i.e., packet 1 involves 00:d0:59:aa:af:80 > 00:01:96:3c:3f:54 and packet 2 involves 00:01:96:3c:3f:a8 > 00:20:78:e1:5a:80. Assuming 00:d0:59:aa:af:80 is the only MAC address for the troubled host, there is no way this machine could see traffic "bouncing back" -- the destination MAC address for the dupe packet is 00:20:78:e1:5a:80.

p 110: Another "troubleshooting" example fails to recognize that packets 1-18 and 29 are part of one unique TCP session, and 19-28 are an entirely different session. Packet 29's RST ACK is not an "acknowledgement" of the RST in packet 28; besides not being an actual protocol mechanism, those packets are from different sessions anyway!

p 112: "More ominously, most of the traffic is being sent with the TCP PSH flag on, which forces a receiving computer to skip its buffer and push that traffic straight through, ahead of any other traffic. That is almost always a bad sign." It's a bad sign when you don't know what you're talking about, apparently.

p 129: "Display filters make it easy to search for traffic such as DCEPRC (sic), NetBIOS, or ICMP, which should not be seen under normal circumstances." I guess Windows networks never use at least DCERPC regularly?

This book should not have been published. The author should sit down with Interconnections, 2nd Ed by Radia Perlman, Troubleshooting Campus Networks by Priscilla Oppenheimer/Joseph Bardwell, and The Internet and its Protocols by Adrian Farrel, and learn how networks operate. Then he should have Gerald Combs REALLY provide a technical edit of PPA, since it's clear Mr Combs probably skimmed this book without catching the issues noted above.

The only positives I can say for PPA is that, like other No Starch books, it's form factor and readability is excellent. The diagrams are clear (albeit often misunderstood) and the obvious typos are few. As far as learning anything, the mention of "Expert Infos" on p 100 was nice.

The conversational style of the book and the basic idea are very sound. Some of the information is well presented. So we'll start with 5 stars and see where we end up.

There are some typos and errors in the book (the Syn-Ack-Ack mentioned in two reviews is simply a typo in the diagram, the text on the same page correctly has it as Syn-Syn/Ack-Ack). Unfortunately, there are more serious errors than this, so there goes one star.

This is clearly a beginner's book, so some basic configuration explanations are needed to get Wireshark (and Cain and Able) set up properly. When the novice is presented with multiple network interfaces they can capture from, how do they decide which is the one to use? The author provides no help here, so the novice can do nothing but try each one in turn and see which one works. In my case, since I was using a notebook with a wireless connection, none of them worked in either program. Turning off promiscuous mode in Wireshark did the trick, but the author should have explained the need for that in the text. This book is about using these tools, so not explaining the basics is worth a star.

I downloaded the sample traces. The first one I tried: wrongdissector.dmp wasn't in the archive. An oversight perhaps? Let's try the next one in the text: suspectemployeechat.dmp. The content of this trace doesn't match the text all: the two individuals are chatting on a similar topic, perhaps, the contents of their conversation is complete different. There is no way to reconcile it with the text. Now we've moved from oversight to rubbish. Say goodbye to another star.

Final score: two stars out of five. If the publisher and/or their agents reads these reviews (they appear to have written some of them), please issue an errata and fix the download.

I bought also "Computer Networks: Internet Protocols in Action
by Jeanna Matthews". Both as reference books. See also my review on that.

Let's start by saying it's very annoying if you have to read other material or have some doubt about your own knowledge concerning specific topics and then afterwards it proved to be your understanding and assumptions WHERE RIGHT and the book presented something wrong like the three way TCP way handshake is not SYN - ACK - SYN, Richard Bejtlich mentioned. These are crucial aspects of protocol understanding, the main reason you would buy a book like this. Nevertheless some faults can be made and maybe in the next version of the book this is reviewed and solved.

Rob Faber [CISSP, CEH, MCSE]
Security Consultant
The Netherlands

I was looking for a book simple enough for me to follow regarding Wireshark.
After reading, I at least feel confidant enough that I can read a pcap file and make sense out of it.
If your a newbie to packet captures like I was, you will find this book very helpful.

While this book will give you a passable introduction to the technical aspects of packet analysis and WireShark, the goal is to introduce the reader to some practical uses of WireShark. It answers questions that the accidental, occasional or beginning user asks themselves. I do not fault the author for a few inaccuracies as almost every technical/boring tome has them if you stay awake long enough to come across them. Since this book is so short, it made an easy target for the trained professional reviewer to rip it to shreds. Oh well.

If you want serious, practical training in the use of WireShark, find out about the consummate expert in teaching this subject. Her name is Laura Chappell. Search the web for more info. She goes light years beyond any publication in print with on demand and live video seminars and training for the serious student. Chappell has numerous titles (10 or more) specific to this subject listed on Amazon.com.

As there aren't too many books out there on use of wireshark I found this book to be quite useful for people wanting to get their hands onto trying. I was looking for some books that would be good as a learning tool that I can throw to new members on my team and this book was roundly accepted, particularily the real world examples. By no means should this book be the only one on your shelf as there are many concepts that need to be delved into to really get a firm understanding. The book begins with a basic intro to general router concepts and hardware, it then goes into the functions of Wireshark. I found that this information could of been found on the Wireshark userguide or help file. It was basically a re-hash here so that space could of been better used providing more info about routers in general instead as a lot of the real world problems come from misconfigured routers or machines.

Overall after reading the book the reader should get a fair understanding of TCP/IP concepts and communication on a network and is a good jump off point onto more advanced books.

This book would be great for a beginner or computer tech that is becoming a network tech. This book gets the idea of Wireshark and its possible uses across very well and is an easy two-day read. Some stuff left out but not bad considering that the book is under 170 pages. This book will introduce you to Wireshark, and inspire you to dig deeper to read more about packet analysis and TCP/IP.

Lately I have been reading reviews after I buy books just to see how they stack up, and this is no exception. I bought the book after checking it out at the book store and saw that there was good stuff in it. If you use Wireshark, or if you are learning it, you should have this book on your shelf period.
Chris Sanders not only does a great job of introducing you to the mindset of packet analysis, he shows a side of it that most of the people I interact with don't consider...the day to day administrator's needs for a way to diagnose network problems.

If you live the world of network monitoring and information security then this books works for you as well. The concepts are what is important and they are presented very well.

As to those who say there are too many things like the mis-representation of the three-way handshake I say Thanks for pointing it out to the novice among us. For the novice, now you know, so...buy the book anyway. If I put a technical book back every time I saw a mistake that the proofer missed, I'd have empty shelves.

Thanks Chris for taking a tough subject and making it much easier to digest.

The reading of this book took me about two weeks and it was fun. There are some mistakes, but overall the book is very good. The examples are very useful and the explanations are clear and simple. After finishing this book (I took it from a friend) I ordered the 2nd edition and I am not disappointed.

I am the kind of person who gets almost all of his information from books. This is because when I communicate, or attempt to communicate, to human beings, I get easily alientated by the weaknesses in their language. What are these weaknesses? How about poor syntax, pomp, condescension and infalted sense of self-worth, to name a few?

But I got this book primarily to explore wireless. I am interested in wireless sniffing and have been experimenting heaviy with Linux and the Aircrack-ng suite for the past several months.

I did enjoy the exposition of the author of the OSI model in the beginning of the book. He does write clearly although he doesn't really provide many examples. I learn best thru the inductive method and so I really depend on examples with which to experiment. So I jumped ahead to the wireless chapter, which wasn't a great disappointment. It did explain the inner workings of Wireshark and the 802.11 header to me in relatively concise terms. Also, how to apply filters. But the true meaning of the packets and how to arrange them to give insights into the network structure, were not there. And that was the primarily reason I got the book.

So, all in all, about average. Best for a beginner who is just starting out with Linux.