From af3e2dbdc619c466f238348ca0105da4e0ff48a0 Mon Sep 17 00:00:00 2001 From: Gerald Combs Date: Sun, 31 Aug 2014 18:40:56 -0700 Subject: WSUG: Convert ``Advanced Topics'' to AsciiDoc. Leave most of the content intact for now. Change-Id: Ie91fda8a3fe6ea2eb4c47acf7c41d7e6979235b0 Reviewed-on: https://code.wireshark.org/review/3938 Petri-Dish: Gerald Combs Tested-by: Petri Dish Buildbot Reviewed-by: Gerald Combs --- docbook/wsug_src/WSUG_chapter_advanced.asciidoc | 786 ++++++++++++++++++ docbook/wsug_src/WSUG_chapter_advanced.xml | 1012 ----------------------- 2 files changed, 786 insertions(+), 1012 deletions(-) create mode 100644 docbook/wsug_src/WSUG_chapter_advanced.asciidoc delete mode 100644 docbook/wsug_src/WSUG_chapter_advanced.xml (limited to 'docbook/wsug_src') diff --git a/docbook/wsug_src/WSUG_chapter_advanced.asciidoc b/docbook/wsug_src/WSUG_chapter_advanced.asciidoc new file mode 100644 index 0000000000..488d655bf3 --- /dev/null +++ b/docbook/wsug_src/WSUG_chapter_advanced.asciidoc @@ -0,0 +1,786 @@ +++++++++++++++++++++++++++++++++++++++ + +++++++++++++++++++++++++++++++++++++++ + +[[ChapterAdvanced]] + +== Advanced Topics + +[[ChAdvIntroduction]] + +=== Introduction + +This chapter some of Wireshark's advanced features. + +[[ChAdvFollowTCPSection]] + +=== Following TCP streams + +If you are working with TCP based protocols it can be very helpful to see the +data from a TCP stream in the way that the application layer sees it. Perhaps +you are looking for passwords in a Telnet stream, or you are trying to make +sense of a data stream. Maybe you just need a display filter to show only the +packets of that TCP stream. If so, Wireshark's ability to follow a TCP stream +will be useful to you. + +Simply select a TCP packet in the packet list of the stream/connection you are +interested in and then select the Follow TCP Stream menu item from the Wireshark +Tools menu (or use the context menu in the packet list). Wireshark will set an +appropriate display filter and pop up a dialog box with all the data from the +TCP stream laid out in order, as shown in <>. + +[NOTE] +==== +Opening the ``Follow TCP Stream'' installs a display filter to +select all the packets in the TCP stream you have selected. +==== + +==== The ``Follow TCP Stream'' dialog box + +[[ChAdvFollowStream]] + +.The ``Follow TCP Stream'' dialog box +image::wsug_graphics/ws-follow-stream.png[] + +The stream content is displayed in the same sequence as it appeared on the +network. Traffic from A to B is marked in red, while traffic from B to A is +marked in blue. If you like, you can change these colors in the +``Colors'' page if the ``Preferences'' dialog. + +Non-printable characters will be replaced by dots. + +// XXX - What about line wrapping (maximum line length) and CRNL conversions? + +The stream content won't be updated while doing a live capture. To get the +latest content you'll have to reopen the dialog. + +You can choose from the following actions: + +. __Save As__: Save the stream data in the currently selected format. + +. __Print__: Print the stream data in the currently selected format. + +. __Direction__: Choose the stream direction to be displayed (``Entire + conversation'', ``data from A to B only'' or ``data from B to A only''). + +. __Filter out this stream__: Apply a display filter removing the current TCP + stream data from the display. + +. __Close__: Close this dialog box, leaving the current display filter in + effect. + +You can choose to view the data in one of the following formats: + +. __ASCII__: In this view you see the data from each direction in ASCII. + Obviously best for ASCII based protocols, e.g. HTTP. + +. __EBCDIC__: For the big-iron freaks out there. + +. __HEX Dump__: This allows you to see all the data. This will require a lot of + screen space and is best used with binary protocols. + +. __C Arrays__: This allows you to import the stream data into your own C + program. + +. __Raw__: This allows you to load the unaltered stream data into a different + program for further examination. The display will look the same as the ASCII + setting, but ``Save As'' will result in a binary file. + +[[ChAdvExpert]] + +=== Expert Information + +The expert infos is a kind of log of the anomalies found by Wireshark in a +capture file. + +The general idea behind the following ``Expert Info'' is to have a better +display of ``uncommon'' or just notable network behaviour. This way, both novice +and expert users will hopefully find probable network problems a lot faster, +compared to scanning the packet list ``manually'' . + +[WARNING] +.Expert infos are only a hint +==== +Take expert infos as a hint what's worth looking at, but not more. For example, +the absence of expert infos doesn't necessarily mean everything is OK. +==== + +The amount of expert infos largely depends on the protocol being used. While +some common protocols like TCP/IP will show detailed expert infos, most other +protocols currently won't show any expert infos at all. + +The following will first describe the components of a single expert info, then +the User Interface. + +[[ChAdvExpertInfoEntries]] + +==== Expert Info Entries + +Each expert info will contain the following things which will be described in +detail below. + +[[ChAdvTabExpertInfoEntries]] + +.Some example expert infos +[options="header"] +|=============== +|Packet #|Severity|Group|Protocol|Summary +|1|Note|Sequence|TCP|Duplicate ACK (#1) +|2|Chat|Sequence|TCP|Connection reset (RST) +|8|Note|Sequence|TCP|Keep-Alive +|9|Warn|Sequence|TCP|Fast retransmission (suspected) +|=============== + +[[ChAdvExpertSeverity]] + +===== Severity + +Every expert info has a specific severity level. The following severity levels +are used, in parentheses are the colors in which the items will be marked in the +GUI: + +* __Chat (grey)__: information about usual workflow, e.g. a TCP packet with the + SYN flag set + +* __Note (cyan)__: notable things, e.g. an application returned an ``usual'' + error code like HTTP 404 + +* __Warn (yellow)__: warning, e.g. application returned an ``unusual'' error + code like a connection problem + +* __Error (red)__: serious problem, e.g. [Malformed Packet] + +[[ChAdvExpertGroup]] + +===== Group + +There are some common groups of expert infos. The following are currently implemented: + +* __Checksum__: a checksum was invalid + +* __Sequence__: protocol sequence suspicious, e.g. sequence wasn't continuous or + a retransmission was detected or ... + +* __Response Code__: problem with application response code, e.g. HTTP 404 page + not found + +* __Request Code__: an application request (e.g. File Handle == x), usually Chat + level + +* __Undecoded__: dissector incomplete or data can't be decoded for other reasons + +* __Reassemble__: problems while reassembling, e.g. not all fragments were + available or an exception happened while reassembling + +* __Protocol__: violation of protocol specs (e.g. invalid field values or + illegal lengths), dissection of this packet is probably continued + +* __Malformed__: malformed packet or dissector has a bug, dissection of this + packet aborted + +* __Debug__: debugging (should not occur in release versions) + +It's possible that more groups will be added in the future. + +[[ChAdvExpertProtocol]] + +===== Protocol + +The protocol in which the expert info was caused. + +[[ChAdvExpertSummary]] + +===== Summary + +Each expert info will also have a short additional text with some further explanation. + +[[ChAdvExpertDialog]] + +==== ``Expert Info'' dialog + +You can open the expert info dialog by selecting menu:Analyze[Expert Info]. + +// XXX - add explanation of the dialogs context menu. + +.The ``Expert Info'' dialog box +image::wsug_graphics/ws-expert-infos.png[] + +[[ChAdvExpertDialogTabs]] + +===== Errors / Warnings / Notes / Chats tabs + +An easy and quick way to find the most interesting infos (rather than using the +Details tab), is to have a look at the separate tabs for each severity level. As +the tab label also contains the number of existing entries, it's easy to find +the tab with the most important entries. + +There are usually a lot of identical expert infos only differing in the packet +number. These identical infos will be combined into a single line - with a count +column showing how often they appeared in the capture file. Clicking on the plus +sign shows the individual packet numbers in a tree view. + +[[ChAdvExpertDialogDetails]] + +===== Details tab + +The Details tab provides the expert infos in a ``log like'' view, each entry on +its own line (much like the packet list). As the amount of expert infos for a +capture file can easily become very large, getting an idea of the interesting +infos with this view can take quite a while. The advantage of this tab is to +have all entries in the sequence as they appeared, this is sometimes a help to +pinpoint problems. + +[[ChAdvExpertColorizedTree]] + +==== ``Colorized'' Protocol Details Tree + +.The ``Colorized'' protocol details tree +image::wsug_graphics/ws-expert-colored-tree.png[] + +The protocol field causing an expert info is colorized, e.g. uses a cyan +background for a note severity level. This color is propagated to the toplevel +protocol item in the tree, so it's easy to find the field that caused the expert +info. + +For the example screenshot above, the IP ``Time to live'' value is very low +(only 1), so the corresponding protocol field is marked with a cyan background. +To easier find that item in the packet tree, the IP protocol toplevel item is +marked cyan as well. + +[[ChAdvExpertColumn]] + +==== ``Expert'' Packet List Column (optional) + +.The ``Expert'' packet list column +image::wsug_graphics/ws-expert-column.png[] + +An optional ``Expert Info Severity'' packet list column is available that +displays the most significant severity of a packet or stays empty if everything +seems OK. This column is not displayed by default but can be easily added using +the Preferences Columns page described in <>. + +[[ChAdvTimestamps]] + +=== Time Stamps + +Time stamps, their precisions and all that can be quite confusing. This section +will provide you with information about what's going on while Wireshark +processes time stamps. + +While packets are captured, each packet is time stamped as it comes in. These +time stamps will be saved to the capture file, so they also will be available +for (later) analysis. + +So where do these time stamps come from? While capturing, Wireshark gets the +time stamps from the libpcap (WinPcap) library, which in turn gets them from the +operating system kernel. If the capture data is loaded from a capture file, +Wireshark obviously gets the data from that file. + +==== Wireshark internals + +The internal format that Wireshark uses to keep a packet time stamp consists of +the date (in days since 1.1.1970) and the time of day (in nanoseconds since +midnight). You can adjust the way Wireshark displays the time stamp data in the +packet list, see the ``Time Display Format'' item in the +<> for details. + +While reading or writing capture files, Wireshark converts the time stamp data +between the capture file format and the internal format as required. + +While capturing, Wireshark uses the libpcap (WinPcap) capture library which +supports microsecond resolution. Unless you are working with specialized +capturing hardware, this resolution should be adequate. + +==== Capture file formats + +Every capture file format that Wireshark knows supports time stamps. The time +stamp precision supported by a specific capture file format differs widely and +varies from one second ``0'' to one nanosecond ``0.123456789''. Most file +formats store the time stamps with a fixed precision (e.g. microseconds), while +some file formats are even capable of storing the time stamp precision itself +(whatever the benefit may be). + +The common libpcap capture file format that is used by Wireshark (and a lot of +other tools) supports a fixed microsecond resolution ``0.123456'' only. + +Writing data into a capture file format that doesn't provide the capability to +store the actual precision will lead to loss of information. For example, if you +load a capture file with nanosecond resolution and store the capture data in a +libpcap file (with microsecond resolution) Wireshark obviously must reduce the +precision from nanosecond to microsecond. + +==== Accuracy + +People often ask ``Which time stamp accuracy is provided by Wireshark?''. Well, +Wireshark doesn't create any time stamps itself but simply gets them from +``somewhere else'' and displays them. So accuracy will depend on the capture +system (operating system, performance, etc) that you use. Because of this, the +above question is difficult to answer in a general way. + +[NOTE] +==== +USB connected network adapters often provide a very bad time stamp accuracy. The +incoming packets have to take ``a long and winding road'' to travel through the +USB cable until they actually reach the kernel. As the incoming packets are time +stamped when they are processed by the kernel, this time stamping mechanism +becomes very inaccurate. + +Don't use USB connected NICs when you need precise time stamp +accuracy. +==== + +// (XXX - are there any such NIC's that generate time stamps on the USB +// hardware?) + +[[ChAdvTimezones]] + +=== Time Zones + +If you travel across the planet, time zones can be confusing. If you get a +capture file from somewhere around the world time zones can even be a lot more +confusing ;-) + +First of all, there are two reasons why you may not need to think about time +zones at all: + +* You are only interested in the time differences between the packet time stamps + and don't need to know the exact date and time of the captured packets (which + is often the case). + +* You don't get capture files from different time zones than your own, so there + are simply no time zone problems. For example, everyone in your team is + working in the same time zone as yourself. + +.What are time zones? +**** +People expect that the time reflects the sunset. Dawn should be in the morning +maybe around 06:00 and dusk in the evening maybe at 20:00. These times will +obviously vary depending on the season. It would be very confusing if everyone +on earth would use the same global time as this would correspond to the sunset +only at a small part of the world. + +For that reason, the earth is split into several different time zones, each zone +with a local time that corresponds to the local sunset. + +The time zone's base time is UTC (Coordinated Universal Time) or Zulu Time +(military and aviation). The older term GMT (Greenwich Mean Time) shouldn't be +used as it is slightly incorrect (up to 0.9 seconds difference to UTC). The UTC +base time equals to 0 (based at Greenwich, England) and all time zones have an +offset to UTC between -12 to +14 hours! + +For example: If you live in Berlin you are in a time zone one hour earlier than +UTC, so you are in time zone ``+1'' (time difference in hours compared to UTC). +If it's 3 o'clock in Berlin it's 2 o'clock in UTC ``at the same moment''. + +Be aware that at a few places on earth don't use time zones with even hour +offsets (e.g. New Delhi uses UTC+05:30)! + +Further information can be found at: +link:wikipedia-web-site:[]Time_zone[wikipedia-web-site:[]Time_zone] and +link:wikipedia-web-site:[]Coordinated_Universal_Time[wikipedia-web-site:[]Coordinated_Universal_Time]. +**** + + + +.What is daylight saving time (DST)? +**** +Daylight Saving Time (DST), also known as Summer Time is intended to ``save'' +some daylight during the summer months. To do this, a lot of countries (but not +all!) add a DST hour to the already existing UTC offset. So you may need to take +another hour (or in very rare cases even two hours!) difference into your ``time +zone calculations''. + +Unfortunately, the date at which DST actually takes effect is different +throughout the world. You may also note, that the northern and southern +hemispheres have opposite DST's (e.g. while it's summer in Europe it's winter in +Australia). + +Keep in mind: UTC remains the same all year around, regardless of DST! + +Further information can be found at +link:wikipedia-web-site:[]Daylight_saving[wikipedia-web-site:[]Daylight_saving]. +**** + +Further time zone and DST information can be found at +link:greenwichmeantime-web-site:[][greenwichmeantime-web-site:[]] and +link:timeanddate-web-site:[][timeanddate-web-site:[]]. + +==== Set your computer's time correctly! + +If you work with people around the world it's very helpful to set your +computer's time and time zone right. + +You should set your computers time and time zone in the correct sequence: + +. Set your time zone to your current location + +. Set your computer's clock to the local time + +This way you will tell your computer both the local time and also the time +offset to UTC. Many organizations simply set the time zone on their servers and +networking gear to UTC in order to make coordination and troubleshooting easier. + +[TIP] +==== +If you travel around the world, it's an often made mistake to adjust the hours +of your computer clock to the local time. Don't adjust the hours but your time +zone setting instead! For your computer, the time is essentially the same as +before, you are simply in a different time zone with a different local time. +==== + +You can use the Network Time Protocol (NTP) to automatically adjust your +computer to the correct time, by synchronizing it to Internet NTP clock servers. +NTP clients are available for all operating systems that Wireshark supports (and +for a lot more), for examples see: +link:ntp-web-site:[][ntp-web-site:[]]. + + +==== Wireshark and Time Zones + +So what's the relationship between Wireshark and time zones anyway? + +Wireshark's native capture file format (libpcap format), and some other capture +file formats, such as the Windows Sniffer, EtherPeek, AiroPeek, and Sun snoop +formats, save the arrival time of packets as UTC values. UN*X systems, and +``Windows NT based'' systems represent time internally as UTC. When Wireshark is +capturing, no conversion is necessary. However, if the system time zone is not +set correctly, the system's UTC time might not be correctly set even if the +system clock appears to display correct local time. When capturing, WinPcap has +to convert the time to UTC before supplying it to Wireshark. If the system's +time zone is not set correctly, that conversion will not be done correctly. + +Other capture file formats, such as the Microsoft Network Monitor, DOS-based +Sniffer, and Network Instruments Observer formats, save the arrival time of +packets as local time values. + +Internally to Wireshark, time stamps are represented in UTC. This means that +when reading capture files that save the arrival time of packets as local time +values, Wireshark must convert those local time values to UTC values. + +Wireshark in turn will display the time stamps always in local time. The +displaying computer will convert them from UTC to local time and displays this +(local) time. For capture files saving the arrival time of packets as UTC +values, this means that the arrival time will be displayed as the local time in +your time zone, which might not be the same as the arrival time in the time zone +in which the packet was captured. For capture files saving the arrival time of +packets as local time values, the conversion to UTC will be done using your time +zone's offset from UTC and DST rules, which means the conversion will not be +done correctly; the conversion back to local time for display might undo this +correctly, in which case the arrival time will be displayed as the arrival time +in which the packet was captured. + +[[ChAdvTabTimezones]] + +.Time zone examples for UTC arrival times (without DST) +[options="header"] +|=============== +||Los Angeles|New York|Madrid|London|Berlin|Tokyo +|_Capture File (UTC)_|10:00|10:00|10:00|10:00|10:00|10:00 +|_Local Offset to UTC_|-8|-5|-1|0|+1|+9 +|_Displayed Time (Local Time)_|02:00|05:00|09:00|10:00|11:00|19:00 +|=============== + +For example let's assume that someone in Los Angeles captured a packet with +Wireshark at exactly 2 o'clock local time and sends you this capture file. The +capture file's time stamp will be represented in UTC as 10 o'clock. You are +located in Berlin and will see 11 o'clock on your Wireshark display. + +Now you have a phone call, video conference or Internet meeting with that one to +talk about that capture file. As you are both looking at the displayed time on +your local computers, the one in Los Angeles still sees 2 o'clock but you in +Berlin will see 11 o'clock. The time displays are different as both Wireshark +displays will show the (different) local times at the same point in time. + +__Conclusion__: You may not bother about the date/time of the time stamp you +currently look at unless you must make sure that the date/time is as expected. +So, if you get a capture file from a different time zone and/or DST, you'll have +to find out the time zone/DST difference between the two local times and +``mentally adjust'' the time stamps accordingly. In any case, make sure that +every computer in question has the correct time and time zone setting. + +[[ChAdvReassemblySection]] + + +=== Packet Reassembly + +==== What is it? + +Network protocols often need to transport large chunks of data which are +complete in themselves, e.g. when transferring a file. The underlying protocol +might not be able to handle that chunk size (e.g. limitation of the network +packet size), or is stream-based like TCP, which doesn't know data chunks at +all. + +In that case the network protocol has to handle the chunk boundaries itself and +(if required) spread the data over multiple packets. It obviously also needs a +mechanism to determine the chunk boundaries on the receiving side. + +Wireshark calls this mechanism reassembly, although a specific protocol +specification might use a different term for this (e.g. desegmentation, +defragmentation, etc). + +==== How Wireshark handles it + +For some of the network protocols Wireshark knows of, a mechanism is implemented +to find, decode and display these chunks of data. Wireshark will try to find the +corresponding packets of this chunk, and will show the combined data as +additional pages in the ``Packet Bytes'' pane (for information about this pane. +See <>). + +[[ChAdvWiresharkBytesPaneTabs]] + +.The ``Packet Bytes'' pane with a reassembled tab +image::wsug_graphics/ws-bytes-pane-tabs.png[] + +Reassembly might take place at several protocol layers, so it's possible that +multiple tabs in the ``Packet Bytes'' pane appear. + +[NOTE] +==== +You will find the reassembled data in the last packet of the chunk. +==== + +For example, in a _HTTP_ GET response, the requested data (e.g. an HTML page) is +returned. Wireshark will show the hex dump of the data in a new tab +``Uncompressed entity body'' in the ``Packet Bytes'' pane. + +Reassembly is enabled in the preferences by default but can be disabled in the +preferences for the protocol in question. Enabling or disabling reassembly +settings for a protocol typically requires two things: + +. The lower level protocol (e.g., TCP) must support reassembly. Often this + reassembly can be enabled or disabled via the protocol preferences. + +. The higher level protocol (e.g., HTTP) must use the reassembly mechanism to + reassemble fragmented protocol data. This too can often be enabled or disabled + via the protocol preferences. + +The tooltip of the higher level protocol setting will notify you if and which +lower level protocol setting also has to be considered. + +[[ChAdvNameResolutionSection]] + +=== Name Resolution + +Name resolution tries to convert some of the numerical address values into a +human readable format. There are two possible ways to do these conversions, +depending on the resolution to be done: calling system/network services (like +the gethostname() function) and/or resolve from Wireshark specific configuration +files. For details about the configuration files Wireshark uses for name +resolution and alike, see <>. + +The name resolution feature can be enabled individually for the protocol layers +listed in the following sections. + +==== Name Resolution drawbacks + +Name resolution can be invaluable while working with Wireshark and may even save +you hours of work. Unfortunately, it also has its drawbacks. + +* _Name resolution will often fail._ The name to be resolved might simply be + unknown by the name servers asked, or the servers are just not available and + the name is also not found in Wireshark's configuration files. + +* _The resolved names are not stored in the capture file or somewhere else._ So + the resolved names might not be available if you open the capture file later + or on a different machine. Each time you open a capture file it may look + ``slightly different'' simply because you can't connect to the name server + (which you could connect to before). + +* _DNS may add additional packets to your capture file._ You may see packets + to/from your machine in your capture file, which are caused by name resolution + network services of the machine Wireshark captures from. ++ +// XXX Are there any other such packets than DNS ones? + +* _Resolved DNS names are cached by Wireshark._ This is required for acceptable + performance. However, if the name resolution information should change while + Wireshark is running, Wireshark won't notice a change in the name resolution + information once it gets cached. If this information changes while Wireshark + is running, e.g. a new DHCP lease takes effect, Wireshark won't notice it. + +// XXX Is this true for all or only for DNS info? + +Name resolution in the packet list is done while the list is filled. If a name +can be resolved after a packet is added to the list, its former entry won't be +changed. As the name resolution results are cached, you can use +menu:View[Reload] to rebuild the packet list with the correctly resolved names. +However, this isn't possible while a capture is in progress. + +==== Ethernet name resolution (MAC layer) + +Try to resolve an Ethernet MAC address (e.g. 00:09:5b:01:02:03) to something +more ``human readable''. + +__ARP name resolution (system service)__: Wireshark will ask the operating +system to convert an Ethernet address to the corresponding IP address (e.g. +00:09:5b:01:02:03 → 192.168.0.1). + +__Ethernet codes (ethers file)__: If the ARP name resolution failed, Wireshark +tries to convert the Ethernet address to a known device name, which has been +assigned by the user using an _ethers_ file (e.g. 00:09:5b:01:02:03 → +homerouter). + +__Ethernet manufacturer codes (manuf file)__: If neither ARP or ethers returns a +result, Wireshark tries to convert the first 3 bytes of an ethernet address to +an abbreviated manufacturer name, which has been assigned by the IEEE (e.g. +00:09:5b:01:02:03 → Netgear_01:02:03). + +==== IP name resolution (network layer) + +Try to resolve an IP address (e.g. 216.239.37.99) to something more ``human +readable''. + +__DNS/concurrent DNS name resolution (system/library service)__: Wireshark will +ask the operating system (or the concurrent DNS library), to convert an IP +address to the hostname associated with it (e.g. 216.239.37.99 -> +www.1.google.com). The DNS service is using synchronous calls to the DNS server. +So Wireshark will stop responding until a response to a DNS request is returned. +If possible, you might consider using the concurrent DNS library (which won't +wait for a name server response). + +[WARNING] +==== +Enabling network name resolution when your name server is unavailable may +significantly slow down Wireshark while it waits for all of the name server +requests to time out. Always use concurrent DNS resolution. +==== + +__DNS vs. concurrent DNS__: here's a short comparison: Both mechanisms are used +to convert an IP address to some human readable (domain) name. The usual DNS +call gethostname() will try to convert the address to a name. To do this, it +will first ask the systems hosts file (e.g. __/etc/hosts__) if it finds a +matching entry. If that fails, it will ask the configured DNS server(s) about +the name. + +So the real difference between DNS and concurrent DNS comes when the system has +to wait for the DNS server about a name resolution. The system call +gethostname() will wait until a name is resolved or an error occurs. If the DNS +server is unavailable, this might take quite a while (several seconds). + +The concurrent DNS service works a bit differently. It will also ask the DNS +server, but it won't wait for the answer. It will just return to Wireshark in a +very short amount of time. The actual (and the following) address fields won't +show the resolved name until the DNS server returns an answer. As mentioned +above, the values get cached, so you can use menu:View[Reload] to ``update'' these +fields to show the resolved values. + +__hosts name resolution (hosts file)__: If DNS name resolution failed, Wireshark +will try to convert an IP address to the hostname associated with it, using a +hosts file provided by the user (e.g. 216.239.37.99 -> www.google.com). + +==== TCP/UDP port name resolution (transport layer) + +Try to resolve a TCP/UDP port (e.g. 80) to something more ``human readable''. + +__TCP/UDP port conversion (system service)__: Wireshark will ask the operating +system to convert a TCP or UDP port to its well known name (e.g. 80 -> http). + +// XXX - mention the role of the /etc/services file (but don't forget the files and folders section)! + +[[ChAdvChecksums]] + +=== Checksums + +Several network protocols use checksums to ensure data integrity. Applying +checksums as described here is also known as _redundancy checking_. + + +.What are checksums for? +**** +Checksums are used to ensure the integrity of data portions for data +transmission or storage. A checksum is basically a calculated summary of such a +data portion. + +Network data transmissions often produce errors, such as toggled, missing or +duplicated bits. As a result, the data received might not be identical to the +data transmitted, which is obviously a bad thing. + +Because of these transmission errors, network protocols very often use checksums +to detect such errors. The transmitter will calculate a checksum of the data and +transmits the data together with the checksum. The receiver will calculate the +checksum of the received data with the same algorithm as the transmitter. If the +received and calculated checksums don't match a transmission error has occurred. + +Some checksum algorithms are able to recover (simple) errors by calculating +where the expected error must be and repairing it. + +If there are errors that cannot be recovered, the receiving side throws away the +packet. Depending on the network protocol, this data loss is simply ignored or +the sending side needs to detect this loss somehow and retransmits the required +packet(s). + +Using a checksum drastically reduces the number of undetected transmission +errors. However, the usual checksum algorithms cannot guarantee an error +detection of 100%, so a very small number of transmission errors may remain +undetected. + +There are several different kinds of checksum algorithms; an example of an often +used checksum algorithm is CRC32. The checksum algorithm actually chosen for a +specific network protocol will depend on the expected error rate of the network +medium, the importance of error detection, the processor load to perform the +calculation, the performance needed and many other things. + +Further information about checksums can be found at: +link:wikipedia-web-site:[]Checksum[wikipedia-web-site:[]Checksum]. +**** + +==== Wireshark checksum validation + +Wireshark will validate the checksums of many protocols, e.g. IP, TCP, UDP, etc. + +It will do the same calculation as a ``normal receiver'' would do, and shows the +checksum fields in the packet details with a comment, e.g. [correct] or +[invalid, must be 0x12345678]. + +Checksum validation can be switched off for various protocols in the Wireshark +protocol preferences, e.g. to (very slightly) increase performance. + +If the checksum validation is enabled and it detected an invalid checksum, +features like packet reassembly won't be processed. This is avoided as +incorrect connection data could ``confuse'' the internal database. + +==== Checksum offloading + +The checksum calculation might be done by the network driver, protocol driver or +even in hardware. + +For example: The Ethernet transmitting hardware calculates the Ethernet CRC32 +checksum and the receiving hardware validates this checksum. If the received +checksum is wrong Wireshark won't even see the packet, as the Ethernet hardware +internally throws away the packet. + +Higher level checksums are ``traditionally'' calculated by the protocol +implementation and the completed packet is then handed over to the hardware. + +Recent network hardware can perform advanced features such as IP checksum +calculation, also known as checksum offloading. The network driver won't +calculate the checksum itself but will simply hand over an empty (zero or +garbage filled) checksum field to the hardware. + + +[NOTE] +==== +Checksum offloading often causes confusion as the network packets to be +transmitted are handed over to Wireshark before the checksums are actually +calculated. Wireshark gets these ``empty'' checksums and displays them as +invalid, even though the packets will contain valid checksums when they leave +the network hardware later. +==== + + +Checksum offloading can be confusing and having a lot of [invalid] messages on +the screen can be quite annoying. As mentioned above, invalid checksums may lead +to unreassembled packets, making the analysis of the packet data much harder. + +You can do two things to avoid this checksum offloading problem: + +* Turn off the checksum offloading in the network driver, if this option is available. + +* Turn off checksum validation of the specific protocol in the Wireshark preferences. + Recent releases of Wireshark disable checksum validation by default due to the + prevalance of offloading in modern hardware and operating systems. + +++++++++++++++++++++++++++++++++++++++ + +++++++++++++++++++++++++++++++++++++++ \ No newline at end of file diff --git a/docbook/wsug_src/WSUG_chapter_advanced.xml b/docbook/wsug_src/WSUG_chapter_advanced.xml deleted file mode 100644 index c6d077ea83..0000000000 --- a/docbook/wsug_src/WSUG_chapter_advanced.xml +++ /dev/null @@ -1,1012 +0,0 @@ - - - Advanced Topics -
- Introduction - In this chapter some of the advanced features of - Wireshark will be described. -
-
- Following TCP streams - If you are working with TCP based protocols it can be - very helpful to see the data from a TCP stream in the way that - the application layer sees it. Perhaps you are looking for - passwords in a Telnet stream, or you are trying to make sense - of a data stream. Maybe you just need a display filter to show - only the packets of that TCP stream. If so, Wireshark's ability - to follow a TCP stream will be useful to you. - Simply select a TCP packet in the packet list of the - stream/connection you are interested in and then select the - Follow TCP Stream menu item from the Wireshark Tools menu (or - use the context menu in the packet list). Wireshark will set an - appropriate display filter and pop up a dialog box with all the - data from the TCP stream laid out in order, as shown in - . - - Note! - It is worthwhile noting that Follow TCP Stream installs - a display filter to select all the packets in the TCP stream - you have selected. - -
- The "Follow TCP Stream" dialog box -
- The "Follow TCP Stream" dialog box - -
- The stream content is displayed in the same sequence as - it appeared on the network. Traffic from A to B is marked in - red, while traffic from B to A is marked in blue. If you - like, you can change these colors in the Edit/Preferences - "Colors" page. - Non-printable characters will be replaced by dots. XXX - - What about line wrapping (maximum line length) and CRNL - conversions? - The stream content won't be updated while doing a live - capture. To get the latest content you'll have to reopen the - dialog. - You can choose from the following actions: - - - - Save As: Save the stream data in the - currently selected format. - - - - Print: Print the stream data in the - currently selected format. - - - - Direction: Choose the stream direction - to be displayed ("Entire conversation", "data from A to B - only" or "data from B to A only"). - - - - Filter out this stream: Apply a display - filter removing the current TCP stream data from the - display. - - - - Close: Close this dialog box, leaving - the current display filter in effect. - - - You can choose to view the data in one of the following - formats: - - - - ASCII: In this view you see the data - from each direction in ASCII. Obviously best for ASCII - based protocols, e.g. HTTP. - - - - EBCDIC: For the big-iron freaks out - there. - - - - HEX Dump: This allows you to see all - the data. This will require a lot of screen space and is - best used with binary protocols. - - - - C Arrays: This allows you to import - the stream data into your own C program. - - - - Raw: This allows you to load the - unaltered stream data into a different program for - further examination. The display will look the same as - the ASCII setting, but "Save As" will result in a binary - file. - - -
-
-
- Expert Infos - The expert infos is a kind of log of the anomalies found - by Wireshark in a capture file. - The general idea behind the following "Expert Info" is to - have a better display of "uncommon" or just notable network - behaviour. This way, both novice and expert users will - hopefully find probable network problems a lot faster, compared - to scanning the packet list "manually" . - - Expert infos are only a hint! - Take expert infos as a hint what's worth looking at, - but not more. For example: The absence of expert infos - doesn't necessarily mean everything is ok! - - - The amount of expert infos largely depends on the - protocol being used! - While some common protocols like TCP/IP will show - detailed expert infos, most other protocols currently won't - show any expert infos at all. - - The following will first describe the components of a - single expert info, then the User Interface. -
- Expert Info Entries - Each expert info will contain the following things - which will be described in detail below: - - Some example expert infos - - - - Packet # - Severity - Group - Protocol - Summary - - - - - 1 - Note - Sequence - TCP - Duplicate ACK (#1) - - - 2 - Chat - Sequence - TCP - Connection reset (RST) - - - 8 - Note - Sequence - TCP - Keep-Alive - - - 9 - Warn - Sequence - TCP - Fast retransmission (suspected) - - - -
-
- Severity - Every expert info has a specific severity level. The - following severity levels are used, in parentheses are the - colors in which the items will be marked in the GUI: - - - - Chat (grey): information about usual - workflow, e.g. a TCP packet with the SYN flag - set - - - - Note (cyan): notable things, e.g. an - application returned an "usual" error code like HTTP - 404 - - - - Warn (yellow): warning, e.g. - application returned an "unusual" error code like a - connection problem - - - - Error (red): serious problem, e.g. - [Malformed Packet] - - -
-
- Group - There are some common groups of expert infos. The - following are currently implemented: - - - - Checksum: a checksum was - invalid - - - - Sequence: protocol sequence - suspicious, e.g. sequence wasn't continuous or a - retransmission was detected or ... - - - - Response Code: problem with - application response code, e.g. HTTP 404 page not - found - - - - Request Code: an application request - (e.g. File Handle == x), usually Chat level - - - - Undecoded: dissector incomplete or - data can't be decoded for other reasons - - - - Reassemble: problems while - reassembling, e.g. not all fragments were available or - an exception happened while reassembling - - - - Protocol: violation of protocol specs - (e.g. invalid field values or illegal lengths), - dissection of this packet is probably continued - - - - Malformed: malformed packet or - dissector has a bug, dissection of this packet - aborted - - - - Debug: debugging (should not occur in - release versions) - - It's possible that more such group values - will be added in the future ... -
-
- Protocol - The protocol in which the expert info was - caused. -
-
- Summary - Each expert info will also have a short additional - text with some further explanation. -
-
-
- "Expert Info" dialog - From the main menu you can open the expert info dialog, - using: "Analyze/Expert Info" - XXX - add explanation of the dialogs context - menu. - -
- Errors / Warnings / Notes / Chats tabs - An easy and quick way to find the most interesting - infos (rather than using the Details tab), is to have a look at the - separate tabs for each severity level. As the tab label - also contains the number of existing entries, it's easy to - find the tab with the most important entries. - There are usually a lot of identical expert infos - only differing in the packet number. These identical infos - will be combined into a single line - with a count column - showing how often they appeared in the capture file. Clicking on - the plus sign shows the individual packet numbers in a tree - view. -
-
- Details tab - The Details tab provides the expert infos in a "log - like" view, each entry on its own line (much like the - packet list). As the amount of expert infos for a capture - file can easily become very large, getting an idea of the - interesting infos with this view can take quite a while. - The advantage of this tab is to have all entries in the - sequence as they appeared, this is sometimes a help to - pinpoint problems. -
-
-
- "Colorized" Protocol Details Tree - - The protocol field causing an expert info is colorized, - e.g. uses a cyan background for a note severity level. This - color is propagated to the toplevel protocol item in the - tree, so it's easy to find the field that caused the expert - info. - For the example screenshot above, the IP "Time to live" - value is very low (only 1), so the corresponding protocol - field is marked with a cyan background. To easier find that - item in the packet tree, the IP protocol toplevel item is - marked cyan as well. -
-
- "Expert" Packet List Column (optional) - - An optional "Expert Info Severity" packet list column - is available (since SVN 22387 → 0.99.7), that displays - the most significant severity of a packet, or stays empty if - everything seems ok. This column is not displayed by default, - but can be easily added using the Preferences Columns page - described in - . -
-
-
- Time Stamps - Time stamps, their precisions and all that can be quite - confusing. This section will provide you with information about - what's going on while Wireshark processes time stamps. - While packets are captured, each packet is time stamped - as it comes in. These time stamps will be saved to the capture - file, so they also will be available for (later) - analysis. - So where do these time stamps come from? While capturing, - Wireshark gets the time stamps from the libpcap (WinPcap) - library, which in turn gets them from the operating system - kernel. If the capture data is loaded from a capture file, - Wireshark obviously gets the data from that file. -
- Wireshark internals - The internal format that Wireshark uses to keep a - packet time stamp consists of the date (in days since - 1.1.1970) and the time of day (in nanoseconds since - midnight). You can adjust the way Wireshark displays the time - stamp data in the packet list, see the "Time Display Format" - item in the - for details. - While reading or writing capture files, Wireshark - converts the time stamp data between the capture file format - and the internal format as required. - While capturing, Wireshark uses the libpcap (WinPcap) - capture library which supports microsecond resolution. Unless - you are working with specialized capturing hardware, this - resolution should be adequate. -
-
- Capture file formats - Every capture file format that Wireshark knows supports - time stamps. The time stamp precision supported by a specific - capture file format differs widely and varies from one second - "0" to one nanosecond "0.123456789". Most file formats store - the time stamps with a fixed precision (e.g. microseconds), - while some file formats are even capable of storing the time - stamp precision itself (whatever the benefit may be). - The common libpcap capture file format that is used by - Wireshark (and a lot of other tools) supports a fixed - microsecond resolution "0.123456" only. - - Note! - Writing data into a capture file format that doesn't - provide the capability to store the actual precision will - lead to loss of information. Example: If you load a capture - file with nanosecond resolution and store the capture data - to a libpcap file (with microsecond resolution) Wireshark - obviously must reduce the precision from nanosecond to - microsecond. - -
-
- Accuracy - It's often asked: "Which time stamp accuracy is - provided by Wireshark?". Well, Wireshark doesn't create any - time stamps itself but simply gets them from "somewhere else" - and displays them. So accuracy will depend on the capture - system (operating system, performance, ...) that you use. - Because of this, the above question is difficult to answer in - a general way. - - Note! - USB connected network adapters often provide a very - bad time stamp accuracy. The incoming packets have to take - "a long and winding road" to travel through the USB cable - until they actually reach the kernel. As the incoming - packets are time stamped when they are processed by the - kernel, this time stamping mechanism becomes very - inaccurate. - Conclusion: don't use USB connected NIC's when you - need precise time stamp accuracy! (XXX - are there any such - NIC's that generate time stamps on the USB hardware?) - -
-
-
- Time Zones - If you travel across the planet, time zones can be - confusing. If you get a capture file from somewhere around the - world time zones can even be a lot more confusing ;-) - First of all, there are two reasons why you may not need - to think about time zones at all: - - - You are only interested in the time differences - between the packet time stamps and don't need to know the - exact date and time of the captured packets (which is often - the case). - - - You don't get capture files from different time zones - than your own, so there are simply no time zone problems. - For example: everyone in your team is working in the same - time zone as yourself. - - - - What are time zones? - People expect that the time reflects the sunset. Dawn - should be in the morning maybe around 06:00 and dusk in the - evening maybe at 20:00. These times will obviously vary - depending on the season. It would be very confusing if - everyone on earth would use the same global time as this - would correspond to the sunset only at a small part of the - world. - For that reason, the earth is split into several - different time zones, each zone with a local time that - corresponds to the local sunset. - The time zone's base time is UTC (Coordinated Universal - Time) or Zulu Time (military and aviation). The older term - GMT (Greenwich Mean Time) shouldn't be used as it is slightly - incorrect (up to 0.9 seconds difference to UTC). The UTC base - time equals to 0 (based at Greenwich, England) and all time - zones have an offset to UTC between -12 to +14 hours! - For example: If you live in Berlin you are in a time - zone one hour earlier than UTC, so you are in time zone "+1" - (time difference in hours compared to UTC). If it's 3 o'clock - in Berlin it's 2 o'clock in UTC "at the same moment". - Be aware that at a few places on earth don't use time - zones with even hour offsets (e.g. New Delhi uses - UTC+05:30)! - Further information can be found at: - - &WikipediaTimezone; and - - &WikipediaUTC;. - - - What is daylight saving time (DST)? - Daylight Saving Time (DST), also known as Summer Time, - is intended to "save" some daylight during the summer months. - To do this, a lot of countries (but not all!) add a DST hour - to the already existing UTC offset. So you may need to take - another hour (or in very rare cases even two hours!) - difference into your "time zone calculations". - Unfortunately, the date at which DST actually takes - effect is different throughout the world. You may also note, - that the northern and southern hemispheres have opposite - DST's (e.g. while it's summer in Europe it's winter in - Australia). - Keep in mind: UTC remains the same all year around, - regardless of DST! - Further information can be found at: - - &WikipediaDaylightSaving;. - - Further time zone and DST information can be found at: - - &TimezoneGMTSite; and - - &TimezoneWorldClockSite;. -
- Set your computer's time correctly! - If you work with people around the world, it's very - helpful to set your computer's time and time zone - right. - You should set your computers time and time zone in the - correct sequence: - - - Set your time zone to your current location - - - Set your computer's clock to the local time - - This way you will tell your computer both the - local time and also the time offset to UTC. - - Tip! - If you travel around the world, it's an often made - mistake to adjust the hours of your computer clock to the - local time. Don't adjust the hours but your time zone - setting instead! For your computer, the time is essentially - the same as before, you are simply in a different time zone - with a different local time! - - - Tip! - You can use the Network Time Protocol (NTP) to - automatically adjust your computer to the correct time, by - synchronizing it to Internet NTP clock servers. NTP clients - are available for all operating systems that Wireshark - supports (and for a lot more), for examples see: - &NTPSite;. - -
-
- Wireshark and Time Zones - So what's the relationship between Wireshark and time - zones anyway? - Wireshark's native capture file format (libpcap - format), and some other capture file formats, such as the - Windows Sniffer, EtherPeek, AiroPeek, and Sun snoop formats, - save the arrival time of packets as UTC values. UN*X systems, - and "Windows NT based" systems represent - time internally as UTC. When Wireshark is capturing, no - conversion is necessary. However, if the system time zone is - not set correctly, the system's UTC time might not be - correctly set even if the system clock appears to display - correct local time. "Windows 9x based" systems (Windows 95, - Windows 98, Windows Me) represent time internally as local - time. When capturing, WinPcap has to convert the time to UTC - before supplying it to Wireshark. If the system's time zone - is not set correctly, that conversion will not be done - correctly. - Other capture file formats, such as the Microsoft - Network Monitor, DOS-based Sniffer, and Network Instruments - Observer formats, save the arrival time of packets as local - time values. - Internally to Wireshark, time stamps are represented in - UTC; this means that, when reading capture files that save - the arrival time of packets as local time values, Wireshark - must convert those local time values to UTC values. - Wireshark in turn will display the time stamps always - in local time. The displaying computer will convert them from - UTC to local time and displays this (local) time. For capture - files saving the arrival time of packets as UTC values, this - means that the arrival time will be displayed as the local - time in your time zone, which might not be the same as the - arrival time in the time zone in which the packet was - captured. For capture files saving the arrival time of - packets as local time values, the conversion to UTC will be - done using your time zone's offset from UTC and DST rules, - which means the conversion will not be done correctly; the - conversion back to local time for display might undo this - correctly, in which case the arrival time will be displayed - as the arrival time in which the packet was captured. - - - Time zone examples for UTC arrival times (without - DST) - - - - - - Los Angeles - New York - Madrid - London - Berlin - Tokyo - - - - - - Capture File (UTC) - - 10:00 - 10:00 - 10:00 - 10:00 - 10:00 - 10:00 - - - - Local Offset to UTC - - -8 - -5 - -1 - 0 - +1 - +9 - - - - Displayed Time (Local Time) - - 02:00 - 05:00 - 09:00 - 10:00 - 11:00 - 19:00 - - - -
- - An example: Let's assume that someone in Los Angeles - captured a packet with Wireshark at exactly 2 o'clock local - time and sends you this capture file. The capture file's time - stamp will be represented in UTC as 10 o'clock. You are - located in Berlin and will see 11 o'clock on your Wireshark - display. - Now you have a phone call, video conference or Internet - meeting with that one to talk about that capture file. As you - are both looking at the displayed time on your local - computers, the one in Los Angeles still sees 2 o'clock but - you in Berlin will see 11 o'clock. The time displays are - different as both Wireshark displays will show the - (different) local times at the same point in time. - - Conclusion: You may not bother about the - date/time of the time stamp you currently look at, unless you - must make sure that the date/time is as expected. So, if you - get a capture file from a different time zone and/or DST, - you'll have to find out the time zone/DST difference between - the two local times and "mentally adjust" the time stamps - accordingly. In any case, make sure that every computer in - question has the correct time and time zone setting. -
-
-
- Packet Reassembling -
- What is it? - Network protocols often need to transport large chunks - of data, which are complete in themselves, e.g. when transferring - a file. The underlying protocol might not be able to handle - that chunk size (e.g. limitation of the network packet size), - or is stream-based like TCP, which doesn't know data chunks - at all. - In that case the network protocol has to handle the - chunk boundaries itself and (if required) spread the data - over multiple packets. It obviously also needs a mechanism to - determine the chunk boundaries on the receiving side. - - Tip! - Wireshark calls this mechanism reassembling, although - a specific protocol specification might use a different - term for this (e.g. desegmentation, defragmentation, - ...). - -
-
- How Wireshark handles it - For some of the network protocols Wireshark knows of, a - mechanism is implemented to find, decode and display these - chunks of data. Wireshark will try to find the corresponding - packets of this chunk, and will show the combined data as - additional pages in the "Packet Bytes" pane (for information - about this pane, see - ). - -
- The "Packet Bytes" pane with a reassembled - tab - -
- - - Note! - Reassembling might take place at several protocol - layers, so it's possible that multiple tabs in the "Packet - Bytes" pane appear. - - - Note! - You will find the reassembled data in the last packet - of the chunk. - - An example: In a - HTTP GET response, the requested data (e.g. - an HTML page) is returned. Wireshark will show the hex dump of - the data in a new tab "Uncompressed entity body" in the - "Packet Bytes" pane. - Reassembling is enabled in the preferences by default. - The defaults were changed from disabled to enabled in - September 2005. If you created your preference settings - before this date, you might look if reassembling is actually - enabled, as it can be extremely helpful while analyzing - network packets. - The enabling or disabling of the reassemble settings of - a protocol typically requires two things: - - - the lower level protocol (e.g., TCP) must support - reassembly. Often this reassembly can be enabled or - disabled via the protocol preferences. - - - the higher level protocol (e.g., HTTP) must use the - reassembly mechanism to reassemble fragmented protocol - data. This too can often be enabled or disabled via the - protocol preferences. - - - The tooltip of the higher level protocol setting will - notify you if and which lower level protocol setting also has to - be considered. -
-
-
- Name Resolution - Name resolution tries to convert some of the numerical - address values into a human readable format. There are two - possible ways to do these conversions, depending on the - resolution to be done: calling system/network services (like - the gethostname() function) and/or resolve - from Wireshark specific configuration files. For details about the - configuration files Wireshark uses for name resolution and - alike, see . - The name resolution feature can be enabled individually - for the protocol layers listed in the following sections. -
- Name Resolution drawbacks - Name resolution can be invaluable while working with - Wireshark and may even save you hours of work. Unfortunately, - it also has its drawbacks. - - - - Name resolution will often fail. The - name to be resolved might simply be unknown by the name - servers asked, or the servers are just not available and - the name is also not found in Wireshark's configuration - files. - - - - The resolved names are not stored in the capture - file or somewhere else. So the resolved names - might not be available if you open the capture file later - or on a different machine. Each time you open a capture - file it may look "slightly different", simply - because you can't connect to the name server (which you - could connect to before). - - - - DNS may add additional packets to your capture - file. You may see packets to/from your machine - in your capture file, which are caused by name resolution - network services of the machine Wireshark captures from. - XXX - are there any other such packets than DNS - ones? - - - - Resolved DNS names are cached by - Wireshark. This is required for acceptable - performance. However, if the name resolution information - should change while Wireshark is running, Wireshark won't - notice a change in the name resolution information once - it gets cached. If this information changes while - Wireshark is running, e.g. a new DHCP lease takes effect, - Wireshark won't notice it. XXX - is this true for all or - only for DNS info? - - - - Tip! - The name resolution in the packet list is done while - the list is filled. If a name could be resolved after a - packet was added to the list, that former entry won't be - changed. As the name resolution results are cached, you can - use "View/Reload" to rebuild the packet list, this time - with the correctly resolved names. However, this isn't - possible while a capture is in progress. - -
-
- Ethernet name resolution (MAC layer) - Try to resolve an Ethernet MAC address (e.g. - 00:09:5b:01:02:03) to something more "human readable". - - ARP name resolution (system - service): Wireshark will ask the operating system to - convert an Ethernet address to the corresponding IP address - (e.g. 00:09:5b:01:02:03 → 192.168.0.1). - - Ethernet codes (ethers file): If the ARP - name resolution failed, Wireshark tries to convert the - Ethernet address to a known device name, which has been - assigned by the user using an ethers - file (e.g. 00:09:5b:01:02:03 → homerouter). - - Ethernet manufacturer codes (manuf file): If - neither ARP or ethers returns a result, Wireshark tries - to convert the first 3 bytes of an ethernet address to an - abbreviated manufacturer name, which has been assigned by the - IEEE (e.g. 00:09:5b:01:02:03 → Netgear_01:02:03). -
-
- IP name resolution (network layer) - Try to resolve an IP address (e.g. 216.239.37.99) to - something more "human readable". - - DNS/concurrent DNS name resolution (system/library - service): Wireshark will ask the operating system - (or the concurrent DNS library), to convert an IP address to - the hostname associated with it (e.g. 216.239.37.99 → - www.1.google.com). The DNS service is using synchronous calls - to the DNS server. So Wireshark will stop responding until a - response to a DNS request is returned. If possible, you might - consider using the concurrent DNS library (which won't wait - for a name server response). - - Warning! - Enabling network name resolution when your name - server is unavailable may significantly slow down Wireshark - while it waits for all of the name server requests to time - out. Use concurrent DNS in that case. - - - DNS vs. concurrent DNS: here's a short - comparison: - Both mechanisms are used to convert an IP address to some - human readable (domain) name. The usual DNS call - gethostname() will try to convert the - address to a name. To do this, it will first ask the systems - hosts file (e.g. /etc/hosts) if it finds - a matching entry. If that fails, it will ask the configured - DNS server(s) about the name. - So the real difference between DNS and concurrent DNS - comes when the system has to wait for the DNS server about a - name resolution. The system call gethostname() - will wait until a name is resolved or an error - occurs. If the DNS server is unavailable, this might take - quite a while (several seconds). - The concurrent DNS service works a bit differently. It - will also ask the DNS server, but it won't wait for the - answer. It will just return to Wireshark in a very short - amount of time. The actual (and the following) address fields - won't show the resolved name until the DNS server returns an - answer. As mentioned above, the values get cached, so you can - use View/Reload to "update" these fields to show the resolved - values. - - hosts name resolution (hosts file): If DNS - name resolution failed, Wireshark will try to convert an IP - address to the hostname associated with it, using a hosts - file provided by the user (e.g. 216.239.37.99 → - www.google.com). -
-
- IPX name resolution (network layer) - - ipxnet name resolution (ipxnets file): XXX - - add ipxnets name resolution explanation. -
-
- TCP/UDP port name resolution (transport layer) - Try to resolve a TCP/UDP port (e.g. 80) to something - more "human readable". - - TCP/UDP port conversion (system service): - Wireshark will ask the operating system to convert a TCP or - UDP port to its well known name (e.g. 80 → http). - XXX - mention the role of the /etc/services file (but - don't forget the files and folders section)! -
-
-
- Checksums - Several network protocols use checksums to ensure data - integrity. - - Tip! - Applying checksums as described here is also known as - redundancy checking. - - - What are checksums for? - Checksums are used to ensure the integrity of data - portions for data transmission or storage. A checksum is - basically a calculated summary of such a data portion. - Network data transmissions often produce errors, such - as toggled, missing or duplicated bits. As a result, the data - received might not be identical to the data transmitted, - which is obviously a bad thing. - Because of these transmission errors, network protocols - very often use checksums to detect such errors. The - transmitter will calculate a checksum of the data and - transmits the data together with the checksum. The receiver - will calculate the checksum of the received data with the - same algorithm as the transmitter. If the received and - calculated checksums don't match a transmission error has - occurred. - Some checksum algorithms are able to recover (simple) - errors by calculating where the expected error must be and - repairing it. - If there are errors that cannot be recovered, the - receiving side throws away the packet. Depending on the - network protocol, this data loss is simply ignored or the - sending side needs to detect this loss somehow and - retransmits the required packet(s). - Using a checksum drastically reduces the number of - undetected transmission errors. However, the usual checksum - algorithms cannot guarantee an error detection of 100%, so a - very small number of transmission errors may remain - undetected. - There are several different kinds of checksum - algorithms; an example of an often used checksum algorithm is - CRC32. The checksum algorithm actually chosen for a specific - network protocol will depend on the expected error rate of - the network medium, the importance of error detection, the - processor load to perform the calculation, the performance - needed and many other things. - Further information about checksums can be found at: - . - -
- Wireshark checksum validation - Wireshark will validate the checksums of several - protocols, e.g.: IP, TCP, UDP, ... - It will do the same calculation as a "normal receiver" - would do, and shows the checksum fields in the packet details - with a comment, e.g.: [correct], [invalid, must be - 0x12345678] or alike. - Checksum validation can be switched off for various - protocols in the Wireshark protocol preferences, e.g. to - (very slightly) increase performance. - If the checksum validation is enabled and it detected - an invalid checksum, features like packet reassembling won't - be processed. This is avoided as incorrect connection data - could "confuse" the internal database. -
-
- Checksum offloading - The checksum calculation might be done by the network - driver, protocol driver or even in hardware. - For example: The Ethernet transmitting hardware - calculates the Ethernet CRC32 checksum and the receiving - hardware validates this checksum. If the received checksum is - wrong Wireshark won't even see the packet, as the Ethernet - hardware internally throws away the packet. - Higher level checksums are "traditionally" calculated - by the protocol implementation and the completed packet is - then handed over to the hardware. - Recent network hardware can perform advanced features - such as IP checksum calculation, also known as checksum - offloading. The network driver won't calculate the checksum - itself but will simply hand over an empty (zero or garbage filled) - checksum field to the hardware. - - Note! - Checksum offloading often causes confusion as the - network packets to be transmitted are handed over to - Wireshark before the checksums are actually calculated. - Wireshark gets these "empty" checksums and displays them as - invalid, even though the packets will contain valid - checksums when they leave the network hardware - later. - - Checksum offloading can be confusing and having a lot - of [invalid] messages on the screen can be quite annoying. As - mentioned above, invalid checksums may lead to unreassembled - packets, making the analysis of the packet data much - harder. - You can do two things to avoid this checksum offloading - problem: - - - Turn off the checksum offloading in the network - driver, if this option is available. - - - Turn off checksum validation of the specific - protocol in the Wireshark preferences. - - -
-
- - -- cgit v1.2.3