Николай Малых

Описание программы tcpdump подготовленное на основе информации из руководства man. Программа tcpdump работает на всех платформах UNIX, а сейчас существует и аналог этой программы для платформ Windows -Windump.

http://www.tcpdump.org

Программа tcpdump, включаемая в большинство дистрибутивов UNIX, выводит заголовки пакетов для сетевого интерфейса в соответствии с заданным логическим выражением. Программа также допускает использование с флагом -w для записи пакетов в файл, которым может впоследствии использоваться для анализа. Возможен и просмотр заголовков из таких файлов с помощью флага -r. Во всех случаях tcpdump имеет дело только с пакетами, соответствующими заданному логическому выражению (фильтру).

Формат вывода

Формат вывода программы tcpdump зависит от протокола. Ниже приведены краткие описания и примеры для большинства используемых форматов вывода.

Заголовки канального уровня

При использовании опции -e выводится содержимое заголовков канального уровня. Для сетей Ethernet информация из заголовков включает адреса отправителя и получателя, протокол и размер кадра.

Для сетей FDDI опция -e обеспечивает вывод поля управления (frame control), адресов отправителя и получателя, а также размера кадра. Значение поля управления определяет интерпретацию остальной части кадра. Нормальные кадры (например, содержащие дейтаграммы IP) являются “асинхронными” с уровнем приоритета от 0 до 7 (например async4). Предполагается, что такие кадры содержат пакеты 802.2 LLC. Заголовок LLC выводится в тех случаях, когда пакет не является дейтаграммой ISO или так называемым SNAP-пакетом.

В сетях Token Ring опция -e обеспечивает вывод полей контроля доступа (access control) и управления кадром (frame control), адресов отправителя и получателя, а также размера кадра. Как и для сетей FDDI предполагается, что кадры содержат пакеты LLC. Независимо от наличия опции -e выводится информация о заданном отправителем маршруте (source routing), если пакет содержит такую информацию.

При использовании в сетях 802.11 опция -e выводит значения полей управления (frame control), все адреса из заголовка 802.11, а также размер кадра. Предполагается, что кадры содержат пакеты LLC.

Для каналов SLIP информация канального уровня включает индикатор направления (I для входящего трафика, O – для исходящего), тип пакета и сведения о компрессии¹. Поле типа пакета выводится первым и может принимать значение ip, utcp или ctcp. Остальные сведения относятся к пакету IP. Для пакетов TCP вслед за типом выводится идентификатор соединения. Если для пакета используется компрессия, сжатый заголовок декодируется перед выводом. Для специальных случаев² выводятся значения *S+n и *SA+n (где n – числовое значение), которые указывают величину изменения порядкового номера для пакета и подтверждения, соответственно. Для остальных пакетов могут выводиться индикаторы изменений U (указатель важности - urgent pointer), W (окно - window), A (подтверждение - ack), S (порядковый номер - sequence number) и I (идентификатор пакета - packet ID), сопровождаемые величиной изменения (+n или -n) или указателем на новое значение параметра (=n). Далее выводится информация о количестве данных в пакете и размер сжатого заголовка.

Например строка вывода

O ctcp * A+6 S+49 I+6 3 (6)

относится к исходящему сжатому пакету TCP с неявным идентификатором соединения. Порядковый номер подтверждения увеличился на 6, порядковый номер пакета – на 49, идентификатор пакета – на 6. Пакет содержит 3 байта данных и 6-байтовый сжатый заголовок.

Пакеты ARP/RARP

Информация, выводимая для пакетов arp/rarp, включает тип запроса и его аргументы. Выводимой информации вполне достаточно для понимания происходящих процессов. Ниже показан пример вывода для случая, когда хост rtsg открывает сессию rlogin с хостом csam:

arp who-has csam tell rtsg

arp reply csam is-at CSAM

Первая строка показывает запрос arp от хоста rtsg для получения адресов (MAC и IP) хоста csam. В ответ на это csam возвращает свои адреса (в нашем примере IP-адрес обозначен как csam, а MAC-адрес – как CSAM). Если ввести команду с опцией -n, результат будет выглядеть как

arp who-has 128.3.254.6 tell 128.3.254.68

arp reply 128.3.254.6 is-at 02:07:01:00:01:c4

Если же воспользоваться опцией -e, можно увидеть, что первый пакет является широковещательным (MAC-адрес отправителя показан как RSTG), поле типа содержит значение 0806 (ETHER_ARP), а размер пакета составляет 64 байта:

RTSG Broadcast 0806 64: arp who-has csam tell rtsg

CSAM RTSG 0806 64: arp reply csam is-at CSAM

Пакеты TCP

Для понимания приведенной здесь информации вы должны быть знакомы с протоколом TCP. Если протокол известен вам недостаточно хорошо, обратитесь к документу RFC 793³.

Формат вывода для протокола TCP в общем случае имеет вид:

src > dst: flags data-seqno ack window urg options

Поля src и dst содержат IP-адреса и номера портов для отправителя и получателя. Поле flags содержит комбинацию символов S (SYN), F (FIN), P (PUSH), R (RST), W (ECN CWR) и E (ECN-Echo) в соответствии с установленными для пакета флагами или один символ “.” (нет флагов). Поле data-seqno описывает занятую данным пакетом часть пространства порядковых номеров. Поле ack содержит порядковый номер, ожидаемый для следующей порции данных, передаваемой через это соединение в обратном направлении. Поле window показывает число байтов в приемном буфере, доступных для обратного направления в этом соединении. Поле urg показывает состояние флага важности (urgent) для данных из этого пакета. Поле options содержит опции TCP, заключенные в угловые скобки.

Поля src, dst и flags присутствуют во всех случаях, а вывод остальных полей зависит от информации в заголовке пакета TCP.

Ниже показан набор пакетов, передаваемых при организации хостом rtsg сессии rlogin с хостом csam.

1. rtsg.1023 > csam.login: S 768512:768512(0) win 4096

2. csam.login > rtsg.1023: S 947648:947648(0) ack 768513 win 4096

3. rtsg.1023 > csam.login: . ack 1 win 4096

4. rtsg.1023 > csam.login: P 1:2(1) ack 1 win 4096

5. csam.login > rtsg.1023: . ack 2 win 4096

6. rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096

7. csam.login > rtsg.1023: P 1:2(1) ack 21 win 4077

8. csam.login > rtsg.1023: P 2:3(1) ack 21 win 4077 urg 1

9. csam.login > rtsg.1023: P 3:4(1) ack 21 win 4077 urg 1

Первая строка показывает, что порт TCP с номером 1023 хоста rtsg отправил пакет в порт login хоста csam. Символ S говорит о наличии в пакете флага SYN. Порядковый номер пакета равен 768512 и данных в пакете не содержится⁴. Пакет не содержит в себе подтверждения, доступный размер приемного окна составляет 4096 байтов, а запрошенное значение MSS составляет 1024 байта.

Сайт csam отправляет в ответ подобный полученному пакет, включающий подтверждение для полученного от rtsg пакета SYN. После этого rtsg подтверждает хосту csam получение от него пакета SYN. Точка (.) в поле флагов говорит о том, что пакет не содержит ни одного флага. Данных в пакете не содержится, поэтому в строке вывода отсутствуют значения порядковых номеров. Отметим, что для подтверждения в строке 3 указан порядковый номер 1. Когда программа tcpdump видит первый пакет в данном соединении, она выводит порядковый номер из этого пакета. Для последующих пакетов данного соединения выводятся значения разницы между порядковым номером для текущего пакета и начальным порядковым номером. Это значит, что для всех пакетов, кроме первого, порядковые номера указываются относительно начала потока данных для соединения и первый байт данных имеет номер 1. Опция -S (стр. 320) отключает относительную нумерацию и обеспечивает вывод порядковых номеров в соответствии со значениями в пакетах.

В строке 6 показан пакет, который rtsg отправляет хосту csam с 19 байтами данных (байты со 2 по 20). Пакет передается с флагом PUSH. Строка 7 содержит отправленное хостом csam подтверждение приема данных от хоста rtsg вплоть до байта с номером 21 (но не включая этот байт). Большая часть этих данных сохраняется в приемном буфере, поскольку csam показывает уменьшение приемного окна на 19 байтов. В этом пакете csam также передает хосту rtsg 1 байт данных. В строках 8 и 9 показана передача хостом csam двух важных (urg) байтов данных, отправленных с использованием флага выталкивания PUSH.

Если используется достаточно малый кадр захвата (см описание опции -s на стр. 320), tcpdump может не получить заголовок TCP полностью. В таких случаях интерпретируется полученная часть заголовка, а в строке вывода помещается маркер [|tcp], показывающий невозможность полной интерпретации. Если заголовок содержит некорректную опцию⁵, строка вывода будет содержать маркер [bad opt] и последующие опции не будут интерпретироваться, поскольку невозможно корректно определить начало следующей опции. Если поле размера заголовка указывает на присутствие опций, но размер пакета IP недостаточно велик для включения всех опций в пакет, tcpdump будет помещать в строке вывода маркер [bad hdr length].

Сбор пакетов TCP с заданными комбинациями флагов (SYN-ACK, URG-ACK и т. п.)

Поле флагов заголовка TCP содержит 8 полей:

CWR | ECE | URG | ACK | PSH | RST | SYN | FIN

Предположим, нам нужно собрать пакеты, используемые для организации нового соединения TCP. Напомним, что протокол TCP использует 3-этапную процедуру организации новых соединений:

1. Инициатор соединения передает пакет с установленным флагом SYN.

2. Получатель этого пакета передает отклик с флагами SYN и ACK.

3. Инициатор передает в ответ пакет с флагом ACK.

Давайте создадим фильтр, который будет собирать пакеты, в которых установлен только флаг SYN (этап 1). Отметим, что пакеты этапа 2 (SYN-ACK) нас не будут интересовать, поскольку они являются просто откликами на стартовый запрос SYN. Прежде, чем строить выражение для фильтра, вспомним структуру заголовка TCP без опций:

Таблица 67 Структура заголовка TCP

Заголовок TCP состоит из 20 октетов, если не используются необязательные поля опций. Первая строка таблицы 67 соответствует октетам 0 - 3, вторая – октетам 4 - 7 и т. д. Поле битов управления (флагов) TCP содержится в октете 13. Пронумеруем биты флагов справа налево (в соответствии с ростом значимости битов

Таблица 68 Биты флагов TCP

Таким образом, значение октета флагов при наличии в нем только флага SYN будет составлять

0*128 + 0*64 + 0*32 + 0*16 + 0*8 + 0*4 + 1*2 + 0*1 = 2

и для выделения пакетов с флагом SYN можно воспользоваться выражением

tcp[13] == 2

Указав интересующий интерфейс, мы можем собрать пакеты с помощью команды:

tcpdump -i <интерфейс> tcp[13] == 2

Эту команду можно перевести на человеческий язык словами: “Собрать с указанного интерфейса пакеты TCP, имеющие в тринадцатом октете заголовка значение 2".

Далее предположим, что нам нужно собрать пакеты с флагом SYN независимо от состояния флага ACK и иных флагов. Посмотрим, какое значение будет иметь октет флагов для пакетов SYN-ACK:

|C|E|U|A|P|R|S|F|

|0 0 0 1 0 0 1 0|

В десятичном формате значение 00010010 будет равно 18

0*128 + 0*64 + 0*32 + 1*16 + 0*8 + 0*4 + 1*2 + 0*1 = 2

Однако, мы не можем использовать выражение

tcp[13] == 18

поскольку ему будут соответствовать только пакеты с установленными флагами SYN и ACK, но не будут соответствовать пакеты, имеющие только флаг SYN, который интересует нас в первую очередь.

Для сбора пакетов SYN независимо от значения флага ACK нам следует использовать маску 00000010 (десятичное значение 2). Таким образом, мы можем ввести выражение:

tcpdump -i <интерфейс> 'tcp[13] & 2 == 2'

которое позволит нам собирать пакеты с установленным флагом SYN независимо от присутствия других флагов.

Пакеты UDP

Формат вывода пакетов UDP можно проиллюстрировать на примере пакета rwho:

actinide.who > broadcast.who: udp 84

Приведенная строка говорит о том, что порт who хоста actinide передал дейтаграмму UDP в порт who с использованием широковещательного адреса IP. Пакет содержит 84 байта пользовательских данных.

Для некоторых служб, работающих по протоколу UDP распознаются протоколы вышележащего уровня (на основе номера порта) и для этих протоколов выводится соответствующая информация. В частности, программа tcpdump выводит дополнительные сведения для пакетов DNS⁶ и вызовов NFS с помощью Sun RPC⁷.

Запросы UDP к серверам DNS

Формат вывода для запросов DNS имеет вид

src > dst: id op? flags qtype qclass name (len)

Например

h2opolo.1538 > helios.domain: 3+ A? ucbvax.berkeley.edu. (37)

говорит, что хост h2opolo запрашивает у сервера имен helios адресную запись (qtype=A) для имени ucbvax.berkeley.edu. Идентификатор запроса имеет значение 3. Знак + показывает наличие флага recursion desired⁸. Размер пакета составляет 37 байтов без учета заголовков UDP и IP. Поскольку пакет содержит нормальный запрос, поле op опущено. Если бы это поле содержало что-то иное, соответствующий код был бы выведен между 3 и +. Поле qclass также содержит стандартное значение C_IN, которое опущено при выводе. Любое другое значение qclass было бы выведено вслед за символом A.

При анализе пакета проверяется наличие в нем аномалий и в результате такой проверки строка вывода может содержать дополнительные поля, заключенные в квадратные скобки. Если запрос содержит секции answer (ответ), authority records (запись о полномочиях) или additional records (дополнительные записи), значения ancount, nscount или arcount выводятся как [na], [nn] или [nau], где n показывает значение соответствующего счетчика. Если установлены какие-либо биты отклика (AA, RA или rcode) или в байтах 2 и 3 установлены любые биты must be zero (должно быть нулем, выводится поле [b2&3=x], где x – шестнадцатеричное значение байтов 2 и 3 из заголовка.

UDP-отклики от серверов DNS

Для вывода откликов сервера имен используется формат

src > dst: id op rcode flags a/n/au type class data (len)

Например,

helios.domain > h2opolo.1538: 3 3/3/7 A 128.32.137.3 (273)

helios.domain > h2opolo.1537: 2 NXDomain* 0/1/0 (97)

Первая строка показывает, что сервер helios отвечает на запрос с id=3 от хоста h2opolo сообщениям с тремя записями answer, 3 записями NS и 7 дополнительными записями. Первая запись answer имеет тип A (address - адрес) и содержит IP-адрес указанного в запросе хоста (128.32.137.3). Общий размер отклика составляет 273 байта без учета заголовков UDP и IP. Поля op (Query) и код отклика (NoError) были опущены при выводе.

Во второй строке helios отвечает на запрос 2 с кодом NXDomain (несуществующий домен) без записей answer, с одной записью NS и без записей authority. Символ * показывает, установленный бит authoritative answer. Ввиду отсутствия записей answer не выводится никакой информации о типе, классе и данных.

В строке вывода могут также появляться индикаторы флагов RA (рекурсия доступна) “-” и TC (усеченное сообщение) “|”. Если секция question (вопрос) не содержит в точности одну запись, выводится поле [nq].

Отметим, что запросы и отклики DNS могут быть достаточно велики и принятое по умолчанию значение кадра захвата (68 байтов) может не обеспечить достаточное количество данных из пакета. Для просмотра трафика DNS целесообразно увеличить размер кадра захвата вдвое с помощью опции -s 128.

Декодирование SMB/CIFS

Программа tcpdump поддерживает функции декодирования пакетов SMB/CIFS/NBT, использующих порты UDP/137, UDP/138 и TCP/139. Поддерживаются также некоторые примитивы декодирования данных IPX и NetBEUI SMB.

По умолчанию декодирование происходит с минимальным выводом информации, а для увеличения информативности служит опция -v. Отметим, что при использовании опции -v один пакет SMB может занимать больше экранной страницы, поэтому используйте данную опцию только при необходимости, чтобы не утонуть в море выводимых на экран данных.

При декодировании сеансов SMB, содержащих текстовые строки Unicode может потребоваться установка переменной окружения USE_UNICODE =1.

Информацию о формате пакетов SMB вы сможете найти на сайте http://www.samba.org/ или одном из его зеркал.

Запросы и отклики NFS

Запросы и отклики Sun NFS⁹ имеют вид:

src.xid > dst.nfs: len op args

src.nfs > dst.xid: reply stat len op results

Ниже показан пример вывода информации для пакетов NFS

sushi.6709 > wrl.nfs: 112 readlink fh 21,24/10.73165

wrl.nfs > sushi.6709: reply ok 40 readlink "../var"

sushi.201b > wrl.nfs: 144 lookup fh 9,74/4096.6878 "xcolors"

wrl.nfs > sushi.201b: reply ok 128 lookup fh 9,74/4134.3150

Первая строка показывает, что хост sushi передает транзакцию с идентификатором 6709¹⁰ хосту wrl. Размер запроса составляет 112 байтов без учета заголовков UDP и IP. Запрашиваемая операция readlink¹¹ для файла с идентификатором (handle) fh 21,24/10.731657119 была успешно выполнена и хост wrl возвращает результат ok с содержимым символьной ссылки.

В третьей строке sushi запрашивает у хоста wrl поиск файла xcolors в каталоге 9,74/4096.6878.

При использовании опции -v вывод становится более информативным¹²:

sushi.1372a > wrl.nfs: 148 read fh 21,11/12.195 8192 bytes @ 24576

wrl.nfs > sushi.1372a: reply ok 1472 read REG 100664 ids 417/0 sz 29388

В первой строке показан запрос sushi к хосту wrl на чтение 8192 байтов из файла 21,11/12.195, начиная со смещения 24576. Хост wrl возвращает результат ok; показанный во второй строке пакет является первым фрагментом отклика, содержащим 1472 байта прочитанных данных. Последующие фрагменты не имеют заголовков NFS и UDP, поэтому информация об этих пакетов может не появиться на экране, если вы задали в команде тот или иной фильтр. Благодаря использованию опции -v выводится также некоторые атрибуты прочитанного файла (тип REG – обычный файл, восьмеричное представление прав доступа, идентификаторы владельца и группы, а также размер файла).

При использовании опции -vv объем выводимой информации может дополнительно возрасти.

Отметим, что запросы NFS могут быть достаточно большими и при использовании опции -v выводимая информация может занять несколько экранных страниц. В некоторых случаях будет полезно уменьшить размер кадра захвата с помощью опции -s (например, -s 192).

Отклики NFS не идентифицируют явно операции RPC. Программа tcpdump сохраняет информацию о последних запросах и при выводе откликов указывает соответствующие идентификаторы транзакций.

Запросы и отклики AFS

Вывод информации для запросов и откликов AFS¹³ имеет вид:

src.sport > dst.dport: rx packet-type

src.sport > dst.dport: rx packet-type service call call-name args

src.sport > dst.dport: rx packet-type service reply call-name args

Ниже показан пример вывода информации для пакетов AFS

elvis.7001 > pike.afsfs:

rx data fs call rename old fid 536876964/1/1 ".newsrc.new"

new fid 536876964/1/1 ".newsrc"

pike.afsfs > elvis.7001: rx data fs reply rename

в первой строке хост elvis передает пакет RX хосту pike. Этот пакет адресован файловому серверу (fs) и начинает вызов удаленной процедуры (RPC). Вызов RPC содержит команду rename (переименовать) с идентификатором старого каталога 536876964/1/1 и именем .newsrc.new, а также новым идентификатором 536876964/1/1 и именем .newsrc. Хост pike возвращает отклик RPC с информацией об успешном изменении имени файла.

В общем случаем все пакеты AFS RPC декодируются по крайней мере как имена процедур RPC. Во многих случаях также декодируется один или несколько передаваемых процедуре аргументов.

Формат вывода должен быть достаточно понятен для тех, кто знаком с AFS и RX.

При использовании опции -v обеспечивается вывод дополнительной информации Идентификаторы вызовов RX, номера вызовов, порядковые номера, флаги пакетов RX). Опция -vv дополнительно увеличивает объем выводимой информации (в частности, сведений о согласовании MTU для пакетов RX ack), а опция -vvv обеспечивает также вывод параметров безопасности и идентификаторов сервиса.

Для пакетов abort выводятся коды ошибок (за исключением пакетов Ubik, поскольку эти пакеты используются для обозначения пакетов yes vote протокола Ubik).

Отметим, что запросы AFS могут быть достаточно велики, поэтому использование флага -v иной раз будет приводить к выводу для пакета многостраничной информации. Вы можете задать размер кадра захвата с помощью опции -s для обеспечения более читаемых результатов (например, -s 256).

Отклики AFS явно не идентифицируют операции RPC, поэтому tcpdump отслеживает последние запросы и помечает отклики идентификаторами соответствующих запросов.

KIP AppleTalk (DDP in UDP)

Пакеты AppleTalk DDP, инкапсулированные в дейтаграммы UDP, извлекаются из дейтаграмм и отображаются как пакеты DDP (т. е., все заголовки UDP отбрасываются). Для преобразования имен сетей и хостов AppleTalk используется файл /etc/atalk.names, строки которого имеют форму адрес (номер) - имя

1.254 ether

16.1 icsd-net

1.254.110 ace

В приведенном примере первые две строки содержат имена сетей AppleTalk, а третья строка – имя хоста¹⁴. Для разделения номера и имени в файле могут использоваться пробелы или символы табуляции. Файл /etc/atalk.names может содержать пустые строки и строки комментариев, начинающиеся с символа #.

Адреса AppleTalk выводятся в формате

net.host.port

Например,

144.1.209.2 > icsd-net.112.220

office.2 > icsd-net.112.220

jssmag.149.235 > icsd-net.2

Если файл /etc/atalk.names не содержит записи для той или иной сети или хоста, соответствующее поле выводится в цифровом формате. В первой строке показан пакет NBP (DDP порт 2) отправленный узлом 209 сети 144.1 в порт 220 узла 112 сети icsd-net. Вторая строка отличается от первой только тем, что указано также символьное имя отправителя (office). В третьей строке показан пакет, отправленный из порта 235 хостом 149 сети jssmag всем хостам¹⁵ сети icsd-net, прослушивающим порт NBP

Пакеты протоколов NBP (name binding protocol) и ATP (AppleTalk transaction protocol) выводятся с интерпретацией их содержимого. Для остальных протоколов просто выводится дамп имени протокола или его номера, если имя неизвестно, и размер пакета.

Пакеты NBP выводятся в формате, подобном приведенному ниже:

icsd-net.112.220 > jssmag.2: nbp-lkup 190: "=:LaserWriter@*"

jssmag.209.2 > icsd-net.112.220: nbp-reply 190: "RM1140:LaserWriter@*" 250

techpit.2 > icsd-net.112.220: nbp-reply 190: "techpit:LaserWriter@*" 186

Первая строка показывает запрос на преобразование имени для принтеров LaserWriter, переданный хостом 112 сети icsd по широковещательному адресу сети jssmag. Идентификатор запроса nbp имеет значение 190. Вторая строка содержит отклик на этот запрос от хоста jssmag.209, сообщающего о наличии ресурса LaserWriter с именем RM1140, зарегистрированного на порту 250. В третьей строке показан другой отклик на тот же запрос, говорящий, что хост techpit имеет ресурс LaserWriter с именем techpit, зарегистрированный на порту 186.

Пример формата вывода пакетов ATP показан ниже:

jssmag.209.165 > helios.132: atp-req 12266<0-7> 0xae030001

helios.132 > jssmag.209.165: atp-resp 12266:0 (512) 0xae040000

helios.132 > jssmag.209.165: atp-resp 12266:1 (512) 0xae040000

helios.132 > jssmag.209.165: atp-resp 12266:2 (512) 0xae040000

helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000

helios.132 > jssmag.209.165: atp-resp 12266:4 (512) 0xae040000

helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000

helios.132 > jssmag.209.165: atp-resp 12266:6 (512) 0xae040000

helios.132 > jssmag.209.165: atp-resp*12266:7 (512) 0xae040000

jssmag.209.165 > helios.132: atp-req 12266<3,5> 0xae030001

helios.132 > jssmag.209.165: atp-resp 12266:3 (512) 0xae040000

helios.132 > jssmag.209.165: atp-resp 12266:5 (512) 0xae040000

jssmag.209.165 > helios.132: atp-rel 12266<0-7> 0xae030001

jssmag.209.133 > helios.132: atp-req* 12267<0-7> 0xae030002

хост jssmag.209 инициирует транзакцию 12266 с хостом helios, запрашивая до 8 пакетов (<0-7>). Шестнадцатеричное число в конце строки содержит значение поля userdata из запроса.

Хост helios отвечает на полученный запрос 8 пакетами по 512 байтов. Число после номера транзакции указывает порядковый номер пакета для данной транзакции, а число в скобках – размер данных в пакете без учета заголовка ATP. Символ * для пакета 7 показывает наличие флага EOM.

Хост jssmag.209 после получения пакетов запрашивает повторную передачу пакетов 3 и 5 и helios повторяет эти пакеты, после чего jssmag.209 завершает транзакцию. В последней строке показан новый запрос хоста jssmag.209. Символ * показывает, что флаг XO (exactly once) для пакета не установлен.

Фрагментация IP

Фрагментированные дейтаграммы IP выводятся в формате:

(frag id:size@offset+)

(frag id:size@offset)

Знак + в первой строке показывает наличие дополнительных фрагментов.

Поле id показывает идентификатор фрагмента, size – его размер в байтах без учета заголовка IP, а offset – смещение (в байтах) фрагмента в исходной дейтаграмме.

Информация выводится для каждого фрагмента. Первый фрагмент выводится с заголовком протокола вышележащего уровня и сведениями о фрагментации. Все последующие фрагменты не включают заголовка протокола вышележащего уровня и сведения о фрагменте выводятся сразу после адресов отправителя и получателя. Ниже приведен пример пакетов связанных с передачей файла по протоколу FTP с сайта arizona.edu на хост rtsg через сеть CSNET, которая не поддерживает передачу дейтаграмм размером 576 байтов.

arizona.ftp-data > rtsg.1170: . 1024:1332(308) ack 1 win 4096 (frag 595a:328@0+)

arizona > rtsg: (frag 595a:204@328)

rtsg.1170 > arizona.ftp-data: . ack 1536 win 2560

Отметим, что адреса во второй строке приведены без номеров портов, поскольку фрагменты (за исключением первого) не содержат заголовков TCP, что не позволяет получить сведений о номера портов и порядковых номерах TCP. Порядковые номера в первой строке показывают наличие в пакет 308 байтов пользовательских данных, хотя фактически в дейтаграмме содержится 512 байтов (308 байтов в первом фрагменте и 204 – во втором).

Пакеты с флагом запрета фрагментирования (don't fragment) помечаются символами DF.

Временные метки

По умолчанию каждая строка вывода включает временную метку, содержащую время захвата кадра в формате:

hh:mm:ss.frac

Точность отображения времени зависит от точности системного таймера. Временная метка фиксирует момент, когда кадр становится доступным ядру системы. Время между получением кадра из среды передачи и его доставкой ядру не принимается во внимание.