Features
- Cover Type: Paperback with 192 pages
- Published by: No Starch Press May 23, 2007
- Written in: English
- ISBN 10 Number: 1593271492
- ISBN 13 Number: 978-1593271497
-
Book Dimensions:
9.1 x 6.9 x 0.7 inches
- Weighs: 12.6 ounces
Product Description
It's easy enough to install Wireshark and begin capturing packets off the wire--or from the air. But how do you interpret those packets once you've captured them? And how can those packets help you to better understand what's going on under the hood of your network?
Practical Packet Analysis shows how to use Wireshark to capture and then analyze packets as you take an indepth look at real-world packet analysis and network troubleshooting. The way the pros do it.
Wireshark (derived from the Ethereal project), has become the world's most popular network sniffing application. But while Wireshark comes with documentation, there's not a whole lot of information to show you how to use it in real-world scenarios.
Practical Packet Analysis shows you how to:
- Use packet analysis to tackle common network problems, such as loss of connectivity, slow networks, malware infections, and more
- Build customized capture and display filters
- Tap into live network communication
- Graph traffic patterns to visualize the data flowing across your network
- Use advanced Wireshark features to understand confusing packets
- Build statistics and reports to help you better explain technical network information to non-technical users
Because net-centric computing requires a deep understanding of network communication at the packet level,
Practical Packet Analysis is a must have for any network technician, administrator, or engineer troubleshooting network problems of any kind.
About The Author
Chris Sanders is currently the network administrator for a public school district in Kentucky. A
Microsoft Certified Professional and Certified Wireless Network Administrator, he writes for WindowsNetwork.com, WindowsDevCenter.com, and maintains a blog at chrissanders.org. He is the author of Saving Money and Time with Virtual Server (O'Reilly Short Cut).
Reader ReviewsTo 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
Search for books at
