Got updates/suggestions? Email us at updates@wiresharkbook.com.

• p. 12 - TYPO: Figure 4 - Notice that the destination MAC address of the packet before it enters the switch should be MAC D. Remember that switches do not alter the MAC address information as they forward packets. [changed in 1.0d]
• p. 47 - TRACE NAME: The trace file download-bad.pcap is named http-download-bad.pcap in the download section of this website.
• p. 81 - CLARIFICATION: On this page, we discuss Portable Wireshark. Jim A. pointed out that some clarification is required here. You must still install WinPcap to capture traffic on that host so Portable Wireshark does not leave the host untouched. Jim A. mentioned TCPDUMP for Windows available at www.microolap.com as one solution if you want to capture without installing anything on the local host. Thanks Jim A.!
• p. 87 - IDEA SUBMITTED: Jim A. also had a suggestion regarding "Set up Port Spanning/Port Mirroring on a Switch" on page 87. Jim A. writes "Sometimes we don't have access to the production switches. Mention that we can bring our own inexpensive switch that is capable of doing port mirroring and insert it between the client computer and the wall jack or on-site production switch. This is the replacement for "hubbing out" but without some of the disadvantages of using a hub instead of a switch--"switching out." A Netgear GS108T managed switch, for example, is currently available for just over $100, and is easily carried around."
• p. 118 - REWORDING: Under "Use Operators to Combine Capture Filters" on page 118, I reworded this sentence: "The capture filter host 192.168.1.103 and tcp dst 53 will capture all traffic sent to port 53 sent to or from 192.168.1.103. If 192.168.1.103 is a client on the network, this filter would display DNS queries sent to port 53." [changed in 1.0e]
• p 188 - EXTRA INFORMATION ON PROTOCOL HIERARCHY: Jim A. again came through with a great addition - take a look at Figure 110 on page 188. Jim said I need to explain why the numbers don't add up to 100%. Ok... let's open POP-NORMAL.PCAP together here (you can get that trace file in the Download section of this site). This trace file only contains POP email connection traffic. Select Statistics | Protocol Hierarchy. Notice that under TCP we don't see 100% of the packets - we see 67.57% of the packets as POP and 94.94% bytes as POP. Where is the other traffic under TCP? Right click on POP in that window and Apply as Filter | Selected. Wireshark put in a "pop" display filter for you - notice however that there are packets that did not match this filter. Now use a display filter of "!pop". What's left over? Aha! Skip over to page 448 for a Tip about this behavior. Notice that the connection set up, tear down and ACKs are not counted under POP - they are part of the TCP protocol overhead. Click the Help button in the Protocol Hierarchy window for more details.
• p. 225 - TYPO: In the chart showing the results of the ip.addr != 10.2.4.1, the last entry and column should be "Yes" as there is a match on that line. [changed in 1.0e]
• p. 321 - EXTRA INFORMATION ON GRATUITOUS ARPS: Jim A. again had a suggestion to check out wiki.wireshark.org/gratuitous_arp to learn about other purposes of gratuitous ARPs on the network. (Still - the most common use is as a duplicate IP detection mechanism.)
• p. 375 - RESTATED: Under "When TCP-Based Services are Refused" on page 375, I changed the first sentence to read "If the target server did not have a process listening on port 21, it would respond to the SYN packet with a TCP Reset." [changed in 1.0e]
• p. 383 - TYPO: Jim A. caught an important one on page 383 - "Rather than sending a single ACK for every TCP segment received, TCP implementations using delayed ACKs won’t send ACKs when either of the following conditions is met:" The word "won't" should be removed to read "Rather than sending a single ACK for every TCP segment received, TCP implementations using delayed ACKs send ACKs when either of the following conditions is met:" - scratch out that word in your book. [changed in 1.0e]
• p. 559 - TYPO: On the voip-extension.pcap trace file description, the second sentence should read "Colorize the RTP conversation starting with packet 4 with Color 2." (the packet number 4 was missing). Thanks Ross!
• p. 582 - TYPO: Third paragraph under "Watch for Small Payload Sizes" the text should state "An example of this would be when two distant TCP hosts complete the handshake process indicating the MSS value of 1,460 bytes." (Not MTU.) [changed in 1.0e]
• p. 694 - TYPO: Under the "Mergecap Examples" heading, the sentence should state "to launch Mergecap" (not Wireshark). Same issue on page 699 under Dumpcap.
• HINT ON TRACE FILE: The trace file smtp-prob.pcap has some distracting traffic in it as a user shows they can ping and FTP to a target. What happens when they try to reach the SMTP server at 10.2.23.11 though? (Funny - if MAC name resolution is enabled you will see an interesting OUI value in this trace file.)