Tcpdump - Линукс команда - Unix команда

ИМЕ

tcpdump - дъмп трафик в мрежа

Кратък обзор

tcpdump [ -deflnNOpqRStuvxX ] [ -c броя ]

[ -Ф файл ] [ -F файл ]

[ -i интерфейс ] [ -m модул ] [ -r файл ]

[ -s snaplen ] [ -T тип ] [ -U потребител ] [ -w файл ]

[ -А алго: тайно ] [ израз ]

ОПИСАНИЕ

Tcpdump отпечатва заглавията на пакети на мрежов интерфейс, които съответстват на булевия израз . Той може да се изпълнява и с флаг -w , който го кара да запази пакетните данни във файл за по-късен анализ и / или с флага -r , което го кара да чете от запазен пакетен файл, вместо да чете пакети от мрежов интерфейс. Във всички случаи само пакетите, които съответстват на израз, ще бъдат обработени от tcpdump .

Tcpdump ще продължи да улавя пакети, докато не бъде прекъснат от сигнал SIGINT (генериран например чрез натискане на вашия прекъсващ знак, обикновено C-контрол) или SIGTERM сигнал (обикновено генериран с kill (1) команда); ако се изпълнява с флаг -c , той ще запише пакети, докато не бъде прекъснат от сигнал SIGINT или SIGTERM или определен брой пакети са обработени.

Когато tcpdump завърши улавянето на пакети, той ще отчита броя на:

пакетите "получени от филтъра" (значението на това зависи от операционната система, на която се изпълнява tcpdump и евентуално от начина, по който е била конфигурирана операционната система - ако е посочен филтър на командния ред, на някои OSes брои пакети, независимо от това дали са съвпадани с филтърния израз, а на други OS се броят само пакети, които са съвпадали с филтърния израз и са били обработени от tcpdump );

пакетите `` dropped by kernel '' (това е броят на пакетите, които бяха премахнати поради липса на буферно пространство от механизма за улавяне на пакети в операционната система, на която работи tcpdump , ако операционната система докладва тази информация на приложения; ако не, тя ще бъде отчетена като 0).

На платформи, които поддържат сигнала SIGINFO, като повечето BSD, той ще отчита тези бройки, когато получи сигнал SIGINFO (генериран например чрез въвеждане на символа "status", обикновено контрола-T) и ще продължи да записва пакети ,

Четенето на пакети от мрежов интерфейс може да изисква специални привилегии:

Под SunOS 3.x или 4.x с NIT или BPF:

Трябва да имате достъп за четене до / dev / nit или / dev / bpf * .

Под Solaris с DLPI:

Трябва да имате достъп за четене / запис на мрежовото псевдо устройство, например / dev / le . Поне някои версии на Solaris обаче не са достатъчни, за да позволят на tcpdump да се улови в непрофесионален режим; на тези версии на Solaris, трябва да сте корен, или tcpdump трябва да бъде инсталиран setuid да корен, за да се улови в незначителен режим. Имайте предвид, че при много (може би всички) интерфейси, ако не заснемате в непрофесионален режим, няма да виждате изходящи пакети, така че улавянето, което не е извършено в непрофесионален режим, може да не е много полезно.

Под HP-UX с DLPI:

Трябва да сте root или tcpdump трябва да бъде инсталиран на root.

Под IRIX със snoop:

Трябва да сте root или tcpdump трябва да бъде инсталиран на root.

Под Linux:

Трябва да сте root или tcpdump трябва да бъде инсталиран на root.

Под Ултрикс и цифров UNIX / Tru64 UNIX:

Всеки потребител може да улови мрежовия трафик с tcpdump . Въпреки това, нито един потребител (дори и суперпотребителят) не може да заснеме в непрофесионален режим на интерфейс, освен ако суперпотребителят не е разрешил операцията на незначителен режим на този интерфейс, използвайки pfconfig (8), и никой потребител (дори не суперпотребителят ) може да заснема трафик с единичен трафик, получен от или изпратен от машината на интерфейс, освен ако суперпотребителят не е разрешил операция за копиране на всички режими на този интерфейс, използвайки pfconfig , така че полезното заснемане на пакети на интерфейс вероятно изисква или непроизводен режим, - в този интерфейс да бъде активирана операция в цял режим или и двата режима на работа.

Под BSD:

Трябва да имате достъп за четене / dev / bpf * .

Четенето на запазен пакет файл не изисква специални привилегии.

НАСТРОИКИ

-а

Опитът да се превърнат адресите на мрежата и излъчването в имена.

-° С

Излез след получаването на броя пакети.

-° С

Преди да напишете суров пакет на файла за запис, проверете дали файлът понастоящем е по-голям от file_size и ако е така, затворете текущия файл за запаметяване и отворете нов. Savefiles след първия файл за запис ще има името, посочено с флага -w , с номер след него, започвайки от 2 и продължавайки нагоре. Размерите на file_size са милиони байтове (1,000,000 байта, а не 1,048,576 байта).

-д

Разтоварвайте компилирания пакет съвпадащ код в човешка четима форма със стандартен изход и спиране.

-DD

Кодът за съвпадение на пакета за пакети като фрагмент от програмата C.

-DDD

Код за съвпадение на пакета за десетични знаци като десетични номера (предхождани от брой).

-Д

Отпечатайте заглавката на нивото на връзката на всяка изпускателна линия.

-Е

Използвайте алго: тайна за декриптиране на IPsec ESP пакети. Алгоритмите могат да бъдат des-cbc , 3des-cbc , blowfish-cbc , rc3-cbc , cast128-cbc или никой . Стандартният стандарт е des-cbc . Възможността за декриптиране на пакети е налице само ако tcpdump е компилиран с активирана криптография. тайната на текста ASCI за тайния ключ ESP. В този момент не можем да вземем произволна двоична стойност. Опцията приема RFC2406 ESP, а не RFC1827 ESP. Опцията е само за целите на отстраняване на грешки, а използването на тази опция с истински "таен" ключ е обезкуражено. С представянето на тайния ключ на IPsec на командния ред вие го правите видим за другите, чрез ps (1) и други случаи.

-f

Печат на "чужди" интернет адреси цифрово, а не символично (тази опция е предназначена да преодолее сериозни мозъчни увреждания в сървъра на Sun на сървъра --- обикновено той виси завинаги да превежда не-локални интернет номера).

-F

Използвайте файла като вход за израза на филтъра. Допълнителен израз, даден в командния ред, се игнорира.

-i

Слушайте интерфейса . Ако не е определено, tcpdump търси в системния интерфейс за най-ниско номериран, конфигуриран интерфейс (с изключение на loopback). Връзките се нарушават, като изберете най-ранния мач.

На Linux системите с 2.2 или по-нови ядра може да се използва интерфейсен аргумент от "any", който може да се използва за заснемане на пакети от всички интерфейси. Имайте предвид, че заснеманията на `` всяко '' устройство няма да се извършват в непрофесионален режим.

-l

Направете buffered stdout линия. Полезно, ако искате да видите данните, докато ги заснемате. Например,
`` tcpdump -l | tee dat "или" tcpdump -l> dat & tail -f dat ".

-м

Заредете дефинициите на модула на SMI MIB от файлов модул . Тази опция може да се използва няколко пъти, за да се заредят няколко MIB модула в tcpdump .

-н

Не конвертирайте адресите на хостове до имена. Това може да се използва, за да се избегнат търсенията в DNS.

-NN

Не конвертирайте номера на протоколи и портове и т.н.

-N

Не отпечатвайте квалификация на име на хост на домейн. Например, ако дадете този флаг, то tcpdump ще отпечата "nic" вместо "nic.ddn.mil".

-О

Не пускайте оптимизатора на кодовете за съвпадение на пакети. Това е полезно само ако подозирате, че има грешка в оптимизатора.

-p

Не поставяйте интерфейса в непрофесионален режим. Имайте предвид, че интерфейсът може да е в незначителен режим по някаква друга причина; следователно, "-p" не може да се използва като съкращение за "ether host" {local-hw-addr} или етерно излъчване ".

-q

Бърз (тих?) Изход. Отпечатвайте по-малко информация от протокола, така че изходните линии да са по-къси

-R

Да приемем, че пакетите ESP / AH се основават на стари спецификации (RFC1825 до RFC1829). Ако е посочено, tcpdump няма да отпечата поле за преиграване. Тъй като в спецификацията ESP / AH няма протоколно версийно поле, tcpdump не може да изведе версията на протокола ESP / AH.

-r

Прочетете пакетите от файла (който е създаден с опцията -w). Стандартният вход се използва, ако файлът е `` - ''.

-С

Печатайте абсолютни, а не относителни, номера на TCP поредици.

-с

Snarf запълва байтове на данни от всеки пакет, а не по подразбиране от 68 (с NIT на SunOS, минималният всъщност е 96). 68 байта е подходящ за IP, ICMP, TCP и UDP, но може да съкрати информацията от протокола от пакетите с име сървър и NFS (виж по-долу). Пакети, съкратени поради ограничена снимка, се показват на изхода с `` [ proto ] ", където прото е името на нивото на протокола, на което е настъпило съкращаването. Имайте предвид, че като се вземат по-големи снимки, двете увеличават времето, необходимо за обработка на пакетите и ефективно намаляват количеството буфериране на пакети. Това може да доведе до загуба на пакетите. Трябва да ограничите snaplen до най-малкия брой, който ще улови протокола информация, която ви интересува. Настройка snaplen на 0 означава, използвайте необходимата дължина, за да улови цели пакети.

-T

Force пакети, избрани по " израз ", за да бъдат интерпретирани определения тип . Понастоящем известни типове са cnfp (протокол Cisco NetFlow), rpc (протокол за приложения в реално време), rtcp (контролен протокол за приложения в реално време), snmp (Simple Network Management Protocol), vat ) и wb (разпределени White Board).

-T

Не печатайте клеймо за дата на всеки депо за линия.

-tt

Отпечатайте неформатиран времеви маркер на всяка изпускателна линия.

-U

Отпада привилегиите на root и променя потребителския идентификатор до потребителския и груповия идентификатор към основната група потребители .

Забележка! Red Hat Linux автоматично пуска привилегиите на потребителя `` pcap '', ако не е посочено друго.

-ttt

Отпечатайте делта (в микро секунди) между текущата и предишната линия на всяка линия за депониране.

-tttt

Отпечатайте времева марка във формат по подразбиране, продължена по дата, на всяка изпускателна линия.

-u

Отпечатване на некодираните дръжки за NFS.

-V

(Малко повече) подробен изход. Например, времето за живеене, идентификацията, общата дължина и опциите в IP пакета се отпечатват. Също така дава възможност за допълнителни проверки на целостта на пакета, като например проверка на контролната сума на IP и ICMP хедъра.

-vv

Дори по-подробен изход. Например, допълнителни полета се отпечатват от пакети от отговори NFS, а пакетите SMB се декодират напълно.

-vvv

Дори по-подробен изход. Например опциите telnet SB ... SE се отпечатват изцяло. С опциите -X telnet се отпечатват и шестоъгълници.

-w

Напишете необработените пакети, които да се архивират, вместо да се анализират и отпечатват. Те могат да бъдат отпечатани по-късно с опцията -r. Стандартният изход се използва, ако файлът е `` - ''.

-х

Отпечатвайте всеки пакет (минус заглавката му на ниво връзка) в шестнадесетичен. Колкото по-малък от целия пакет или от щрихованите байтове ще бъде отпечатан. Забележете, че това е целият пакет на линк слой, така че за слоевете на връзките, които подложката (напр. Ethernet), запълващите байтове също ще бъдат отпечатани, когато пакетът с по-висок слой е по-къс от желаното подложка.

-Х

Когато печатате шестнадесетичен, отпечатайте и Ascii. Така, ако -x също е зададено, пакетът е отпечатан в hex / ascii. Това е много удобно за анализ на нови протоколи. Дори ако -x не е зададено, някои части на някои пакети могат да бъдат отпечатани в hex / ascii.

изразяване

избира кои пакети ще бъдат изхвърлени. Ако не е даден израз , всички пакети в мрежата ще бъдат изхвърлени. В противен случай ще бъдат изхвърлени само пакети, чийто израз е "true".

Изразът се състои от едно или повече примитиви. Примитивите обикновено се състоят от идентификационен номер (име или номер), предхождан от един или повече квалификации. Има три различни вида квалификации:

Тип

квалификаторите казват какъв вид се отнася до името или номера на идент. Възможните типове са хост , мрежа и порт . Например "host foo", "net 128.3", "port 20". Ако няма квалификационен тип, приема се хост .

реж

квалификаторите определят конкретна посока на прехвърляне към и / или от id . Възможните посоки са src , dst , src или dst и src и dst . Например "src foo", "dst net 128.3", "src" или "dst port ftp-data". Ако няма квалификатор на дир, предполага се src или dst . За "нула" слоеве на връзки (т.е. протоколи от точка до точка, като например приплъзване), входящите и изходящите квалификатори могат да се използват за определяне на желаната посока.

прото

квалификаторите ограничават мача до определен протокол. Възможните протоси са: ether , fddi , tr , ip , ip6 , arp , rarp , decnet , tcp и udp . Например "ether src foo", "arp net 128.3", "tcp port 21". Ако няма Pro квалификатор, се приемат всички протоколи съответстващи на типа. Например "src foo" означава "(ip или arp или rarp) src foo" (с изключение на последния не е юридически синтаксис), "net bar" означава "(ip или arp или rarp) net bar" `(tcp или udp) порт 53 '.

[fddi] всъщност е псевдоним на "етер"; параметрите на FDDI съдържат адреси на източника и дестинация като Ethernet и често съдържат типове пакети, подобни на Ethernet, за да можете да филтрирате тези FDDI полета точно както при аналоговите полета Ethernet. Функциите на FDDI съдържат и други полета, но не можете да ги посочите изрично в израз на филтъра.

По същия начин, "tr" е псевдоним за "етер"; изявленията на предишния параграф относно заглавките на FDDI се отнасят и за заглавията на Token Ring.]

В допълнение към гореизброените има някои специални "примитивни" ключови думи, които не следват модела: шлюз , излъчване , по-малко , по-големи и аритметични изрази. Всичко това е описано по-долу.

По-сложните филтърни изрази се създават, като се използват думите и или не се комбинират примитиви. Например, "host foo, а не port port ftp, а не port port ftp-data". За да запазите въвеждането, същите списъци с квалификации могат да бъдат пропуснати. Например `tcp dst port ftp или ftp-data или домейн 'е точно същото като` tcp dst port ftp или tcp dst port ftp-data или tcp dst port domain'.

Допустимите примитиви са:

dst домакин домакин

Вярно е, ако IPv4 / v6 целевото поле на пакета е хост , което може да бъде адрес или име.

src хост хост

Вярно е, ако IPv4 / v6 изходното поле на пакета е хост .

домакин домакин

Вярно е, че или източникът или местоназначението на пакета IPv4 / v6 е хост . Всеки от горните изрази на хост може да бъде предварително с ключови думи, ip , arp , rarp или ip6, както в:

ip host хост

което е еквивалентно на:

етер proto \ ip и гостоприемник

Ако хост е име с няколко IP адреса, всеки адрес ще бъде проверен за съвпадение.

етер

Вярно е, ако адресът на дестинация на Ethernet е ehost . Ehost може да бъде или име от / etc / ethers, или число (вижте етери (3N) за цифров формат).

ether src ehost

Вярно е, ако адресът на източника на етернет е ehost .

ether ehost host

Вярно е, че или източникът или целевият адрес на Ethernet е ehost .

портал за хост

Вярно, ако пакетът използва хоста като шлюз. Т.е., източникът или целевият адрес на Ethernet е хост, но нито IP източникът, нито дестинацията за IP са хост . Хостът трябва да бъде име и трябва да бъде намерен както от механизмите за разрешаване на адреса на хост-име на IP адрес (име на хост, DNS, NIS и т.н.), така и от резолюцията на адреса на хост-име-към- механизъм (/ etc / ethers и т.н.). (Еквивалентен израз е

ehost host ehost и не гостоприемник

който може да се използва с имена или номера за хост / ehost .) Този синтаксис в момента не работи в конфигурация с активиран IPv6.

dst net net

Вярно, ако IPv4 / v6 целевият адрес на пакета има мрежов номер на мрежата . Net може да е име от / etc / мрежи или мрежов номер (за подробности вижте мрежи (4) ).

src нетна мрежа

Вярно, ако IPv4 / v6 източникът на адреса на пакета има мрежов номер на мрежата .

нетна мрежа

Вярно е, че ако източникът на IPv4 / v6 или целевият адрес на пакета имат мрежов номер на мрежата .

net net mask net mask

Вярно е, ако IP адресът съвпада с мрежата с конкретната мрежова маска . Може да има квалификация със src или dst . Обърнете внимание, че този синтаксис не е валиден за мрежата IPv6.

нетно нетно / лино

Вярно е, ако IPv4 / v6 адресът съвпада с мрежата с мрежовата маска, която е широка. Може да има квалификация със src или dst .

dst порт пристанище

Вярно е, ако пакетът е ip / tcp, ip / udp, ip6 / tcp или ip6 / udp и има стойност на пристанището на пристанището . Портът може да бъде число или име, използвано в / etc / services (вижте tcp (4P) и udp (4P)). Ако се използва име, се проверява както номерът на порта, така и протоколът. Ако се използва число или двусмислено име, се проверява само номерът на порта (напр. Dst port 513 ще отпечатва трафика tcp / login и трафика udp / кой, а пристанищният домейн ще отпечатва трафик tcp / domain и udp / domain).

src порт порт

Вярно, ако пакетът има стойност на пристанище на порт .

порт пристанище

Вярно, ако източникът или целевият порт на пакета е порт . Всеки от горните портови изрази може да бъде пренасочен с ключови думи, tcp или udp , както в:

tcp src порт порт

който съвпада само с tcp пакети, чийто източник е порт .

по-малка дължина

Вярно е, ако пакетът има дължина, по-малка или равна на дължината . Това е еквивалентно на:

len <= дължина .

голяма дължина

Вярно е, ако пакетът има дължина, по-голяма или равна на дължината . Това е еквивалентно на:

len> = дължина .

ip прото протокол

Вярно е, ако пакетът е IP пакет (вж. Ip (4P)) на протокол тип протокол . Протоколът може да бъде число или едно от имената icmp , icmp6 , igmp , igrp , pim , ah , esp , vrrp , udp или tcp . Имайте предвид, че идентификаторите tcp , udp и icmp също са ключови думи и трябва да бъдат избягнати чрез обратна наклонена черта (\), която е \\ в C-shell. Обърнете внимание, че този примитив не преследва веригата на заглавния протокол.

прото протокол ip6

Вярно е, ако пакетът е IPv6 пакет протокол тип протокол . Обърнете внимание, че този примитив не преследва веригата на заглавния протокол.

протокол ip6 протокол

Вярно е, ако пакетът е IPv6 пакет и съдържа заглавка на протокола с типов протокол в неговата верига с протоколни заглавия. Например,

ip6 протохина 6

съответства на всеки пакет от IPv6 с TCP протокол в заглавната верига на протокола. Пакетът може да съдържа например заглавка за удостоверяване, заглавен маршрутизатор или заглавка на опция "хоп по хоп", между заглавката на IPv6 и заглавката на TCP. Кодът на BPF, излъчван от този примитив, е сложен и не може да бъде оптимизиран от BPF оптимизатора в tcpdump , така че това може да е малко бавно.

ip протокола протокол

Еквивалентен на протокола на протокола ip6 , но това е за IPv4.

етер излъчване

Вярно е, ако пакетът е пакет за етернет излъчване. Ключовата дума " етер" е по избор.

ip излъчване

Вярно е, ако пакетът е IP излъчван пакет. Тя проверява както конвенциите за излъчване на всички нули, така и всички тях и търси местната маска на подмрежата.

етерна мултикаст

Вярно е, ако пакетът е пакет за множествено предаване на Ethernet. Ключовата дума " етер" е по избор. Това е съкращение за " етер [0] & 1! = 0 ".

ip multicast

Вярно, ако пакетът е IP пакет за множествено предаване.

ip6 multicast

Вярно е, ако пакетът е пакет за множествено предаване за IPv6.

протокол на етер прото

Вярно, ако пакетът е от протокол за етерния тип. Протоколът може да бъде число или едно от имената ip , ip6 , arp , rarp , atalk , aarp , decnet , sca , lat , mopdl , moprc , iso , stp , ipx или netbeui . Забележете, че тези идентификатори са и ключови думи и трябва да избягате чрез наклонена черта (\).

[В случая на FDDI (напр. ` Fddi protocol arp ') и Token Ring ( напр.` Tr protocol arp '), за повечето от тези протоколи идентификацията на протокола идва от заглавката 802.2 Logical Link Control (LLC) обикновено е наслоен върху заглавката на FDDI или Token Ring.

При филтриране на повечето идентификатори на протоколи на FDDI или Token Ring, tcpdump проверява само полето ID на протокол на LLC заглавие в така наречения SNAP формат с ОИУ от 0x000000 за капсулиран Ethernet; тя не проверява дали пакетът е в SNAP формат с OUI от 0x000000.

Изключенията са iso , за които той проверява полетата DSAP (Point Service Access Point) и SSAP (Source Service Access Point) на LLC header, stp и netbeui , където проверява DSAP на LLC заглавката и atalk , където проверява за SNAP формат пакет с OUI от 0x080007 и Appletalk тип.

В случая на Ethernet, tcpdump проверява полето Ethernet тип за повечето от тези протоколи; изключенията са iso , sap и netbeui , за които тя проверява за рамка 802.3 и след това проверява LLC заглавието, както прави за FDDI и Token Ring, atalk , където проверява и двата вида Appletalk в Ethernet рамка и за SNAP-формат, както при FDDI и Token Ring, където проверява за протокола ART на Appletalk или в Ethernet кадър, или 802.2 SNAP рамка с OUI от 0x000000 и ipx , където проверява за IPX etype в Ethernet рамка, IPX DSAP в заглавната част на LLC, 802.3 без калибриране на LLC заглавието на IPX и IPX етикет в SNAP рамка.]

decnet src хост

Вярно е, ако източникът на адрес на DECNET е хост , който може да е адрес на формуляра "10.123" или име на хост DECNET. [Поддръжката на името на хост DECNET е достъпна само за системите Ultrix, които са конфигурирани да изпълняват DECNET.]

decnet dst хост

Вярно е, ако адресът на DECNET е домакин .

decnet хост домакин

Вярно е, че ако източникът или целевият адрес на DECNET са хост .

ip , ip6 , arp , rarp , atalk , aarp , decnet , iso , stp , ipx , netbeui

Съкращения за:

етер прото p

където р е един от горните протоколи.

lat , moprc , mopdl

Съкращения за:

етер прото p

където р е един от горните протоколи. Имайте предвид, че tcpdump понастоящем не знае как да анализира тези протоколи.

vlan [vlan_id]

Вярно, ако пакетът е пакет VLAN на IEEE 802.1Q. Ако е зададено [vlan_id] , само вярно е, че пакетът има посочения vlan_id . Обърнете внимание, че първата дума vlan, която се среща в израза, променя декодиращите отмествания за останалата част от израза при предположението, че пакетът е VLAN пакет.

tcp , udp , icmp

Съкращения за:

ip proto p или ip6 proto p

където р е един от горните протоколи.

прото протокол

Вярно е, ако пакетът е OSI пакет протокол тип протокол . Протоколът може да бъде число или едно от имената clnp , esis или isis .

clnp , esis , isis

Съкращения за:

iso proto p

където р е един от горните протоколи. Обърнете внимание, че tcpdump прави непълна задача да анализира тези протоколи.

expr relop expr

Вярно е, ако отношението се задържи, където relop е един от>, <,> =, <=, =, = = и expr е аритметичен израз, съставен от цялостни константи (изразени в стандарт C синтаксис), нормалните двоични оператори [ , -, *, /, &, |], оператор за дължина и специални аксесоари за пакети данни. За достъп до данните в пакета използвайте следния синтаксис:

proto [ expr : размер ]

Прото е един от етер, fddi, tr, ppp, приплъзване, link, ip, arp, rarp, tcp, udp, icmp или ip6 и показва протоколния слой за индексната операция. ( етер, fddi, tr, ppp, приплъзване и връзка всички се отнасят до слоя на връзката.) Забележете, че типовете tcp, udp и други протоколи от горния слой се прилагат само за IPv4, а не за IPv6 (това ще бъде фиксирано в бъдеще). Байтовото отместване, съотнесено към посочения протоколен слой, е дадено чрез expr . Размерът е незадължителен и показва броя на байтовете в областта, представляваща интерес; тя може да бъде една, две или четири и да е по подразбиране. Операторът за дължина, означен с ключовата дума len , дава дължината на пакета.

Например " ether [0] & 1! = 0 " улавя всички трафик за множествено предаване. Изразът " ip [0] & 0xf! = 5 " улавя всички IP пакети с опции. Изразът " ip [6: 2] & 0x1fff = 0 " улавя само неграматизирани дейтаграми и нула на фрагментирани дейтаграми. Тази проверка се прилага имплицитно към операциите на tcp и udp index. Например tcp [0] винаги означава първия байт на TCP заглавката и никога не означава първия байт на вмъкващия се фрагмент.

Някои отклонения и стойности на полета могат да бъдат изразени като имена, а не като цифрови стойности. Предлагат се следните компенсации на полетата на заглавната част на протокола: icmptype (поле ICMP тип), icmpcode (ICMP кодово поле) и tcpflags (полето TCP flags).

Следните стойности на ICMP тип поле са налични: icmp-echoreply , icmp-unreach , icmp-sourcequench , icmp-redirect , icmp-echo , icmp-routeradvert , icmp-routersolicit , icmp-timxceed , icmp-paramprob , icmp-tstamp , icmp -tstampreply , icmp-ireq , icmp-ireqreply , icmp-maskreq , icmp-maskreply .

Предлагат се следните стойности на TCP флагове: tcp-fin , tcp-syn , tcp-rst , tcp-push , tcp-push , tcp-ack , tcp-urg .

Примитивите могат да се комбинират чрез:

Заглавена група от примитиви и оператори (скобите са специални за Shell и трябва да бъдат избегнати).

Отрицание (" ! " Или " не ").

Съответствие (" && " или " и ").

Алтернатива (` || 'или` или ').

Отрицанието има първостепенно значение. Редуването и конкатенацията имат равнопоставено предимство и се свързват от ляво на дясно. Забележете, че изрично и символи, а не juxtaposition, сега са необходими за свързване.

Ако даден идентификатор е даден без ключова дума, се приема последната ключова дума. Например,

не домакин и асо

е кратко за

не хост срещу и домакин асо

с което не бива да се бърка

не (хост срещу или асо)

Експресивните аргументи могат да бъдат предадени на tcpdump като един аргумент или като няколко аргумента, което от двете е по-удобно. Обикновено, ако изразът съдържа Shell metacharacters, е по-лесно да го предаде като единствен, цитиран аргумент. Няколко аргумента са свързани с интервали, преди да бъдат анализирани.

ПРИМЕРИ

За да отпечатате всички пакети, пристигащи или заминаващи от залез слънце :

tcpdump домакин залез слънце

За да отпечатвате трафик между хелиос и горещ или асо :

tcpdump host helios и \ (горещо или асо \)

За да отпечатате всички IP пакети между асо и всеки хост, с изключение на helios :

tcpdump ip хоста асо и не helios

За да отпечатате целия трафик между местни хостове и хостове в Бъркли:

tcpdump net ucb-етер

За да отпечатате целия трафик на ftp чрез спусък на интернет портала: (имайте предвид, че изразът е цитиран, за да се предотврати неправилното интерпретиране на скобите):

tcpdump "шуп на шлюза и (порт ftp или ftp-данни)"

За да отпечатате трафик, който не е генериран от или предназначен за локални хостове (ако сте влезли в друга мрежа, тези неща никога не трябва да го правят в локалната ви мрежа).

tcpdump ip и нето локална мрежа

За да отпечатате началните и крайните пакети (SYN и FIN пакетите) на всеки TCP разговор, който включва не-местен хост.

tcpdump 'tcp [tcpflags] & (tcp-syn | tcp-fin)! = 0 и не src и dst net localnet '

За да отпечатате IP пакети по-дълги от 576 байта, изпратени чрез шупване на шлюза:

tcpdump 'шуп и ip [2: 2]> 576'

За да отпечатате IP излъчвания или пакети за множествено предаване, които не са изпратени чрез Ethernet излъчване или множествено предаване:

tcpdump 'етер [0] & 1 = 0 и ip [16]> = 224'

За да отпечатате всички ICMP пакети, които не са ехо-заявки / отговори (т.е. не ping пакети):

tcpdump 'icmp [icmptype]! = icmp-ехо и icmp [icmptype]! = icmp-echoreply'

ИЗХОДЕН ФОРМАТ

Изходът на tcpdump зависи от протокола. По-долу е дадено кратко описание и примери за повечето формати.

Линкове за нивото на връзката

Ако е дадена опцията "-e", заглавката на нивото на връзката се отпечатва. На ethernets се отпечатват адресите на източника и дестинацията, протоколът и дължината на пакета.

На FDDI мрежи опцията "-e" причинява tcpdump да отпечата полето "control frame", адреса на източника и дестинацията и дължината на пакета. (Например тези, съдържащи IP дейтаграми) са пакети "async" с приоритетна стойност между 0 и 7, например " async4 ". се приема, че пакетите съдържат пакет за контрол на локалната връзка (LLC) 802.2, LLC заглавката се отпечатва, ако не е дейтаграма ISO или така нареченият SNAP пакет.

В мрежите на Token Ring опцията "-e" причинява tcpdump да отпечата полетата "control access" и "frame control", адресите на източника и дестинацията и дължината на пакета. Както и при FDDI мрежите, се приема, че пакетите съдържат LLC пакет. Независимо от това дали опцията "-e" е зададена или не, информацията за маршрутизиране на източника се отпечатва за пакети с източник на маршрутизация.

(NB: Следващото описание предполага познаване на SLIP компресионния алгоритъм, описан в RFC-1144.)

В SLIP връзките се отпечатват индикатори за посока ("I" за входящи, "O" за изходящи), тип пакети и информация за компресията. Типът пакети се отпечатва първо. Трите вида са ip , utcp и ctcp . Не се отпечатва допълнителна информация за връзка за IP пакети. За TCP пакетите идентификаторът на връзката се отпечатва по типа. Ако пакетът е компресиран, неговият кодиран хедър се отпечатва. Специалните случаи се отпечатват като * S + n и * SA + n , където n е сумата, с която се е променил последователният номер (или последователният номер и ack). Ако не е специален случай, се отпечатват нула или повече промени. Промяната се означава с U (спешно показалец), W (прозорец), A (ack), S (последователен номер) и I (пакет ID), последвани от делта (+ n или -n) (= N). Накрая се отпечатва количеството данни в пакета и дължината на компресираната заглавка.

Например, следващият ред показва изходящ компресиран TCP пакет с имплицитен идентификатор на връзката; ака се промени с 6, последователният номер с 49 и идентификационния номер на пакета с 6; има 3 байта данни и 6 байта на компресиран хедър:

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

ARP / RARP пакети

Arp / rarp изхода показва типа искане и неговите аргументи. Форматът е предназначен да бъде самообяснителен. Ето кратка извадка, взета от началото на "rlogin" от хоста rtsg до хоста csam :

arp, който има CSAM, каже rtsg arp reply csam е в CSAM

Първият ред казва, че rtsg е изпратил arp пакет с искане за Ethernet адреса на интернет хоста csam. Csam отговаря с своя Ethernet адрес (в този пример Ethernet адресите са с капачки и интернет адреси с малки букви).

Това би изглеждало по-малко излишно, ако бяхме направили tcpdump -n :

arp кой има 128.3.254.6 кажа 128.3.254.68 arp отговор 128.3.254.6 е на 02: 07: 01: 00: 01: c4

Ако бяхме направили tcpdump -e , фактът, че първият пакет се излъчва и вторият е точка до точка, ще бъде видим:

RTSG Broadcast 0806 64: arp, който има csam кажа rtsg CSAM RTSG 0806 64: arp отговор csam е в CSAM

За първия пакет се казва, че източникът на адрес на Ethernet е RTSG, дестинацията е адресът на излъчване на Ethernet, полето за тип съдържа хекс 0806 (тип ETHER_ARP) и общата дължина е 64 байта.

TCP пакети

(Забележка: Следващото описание предполага запознаване с TCP протокола, описан в RFC-793. Ако не сте запознати с протокола, нито това описание, нито tcpdump ще ви бъдат много полезни.)

Общият формат на протокола tcp е:

src> dst: Flags data-seqno ack window спешни опции

Src и dst са източниците и целевите IP адреси и пристанища. Флаговете са комбинация от S (SYN), F (FIN), P (PUSH) или R (RST) или единична "." (без флагове). Data-seqno описва частта от пространството на секвенцията, обхваната от данните в този пакет (виж примера по-долу). Ack е последователен номер на следващите данни, очаква се другата посока на тази връзка. Прозорецът е броят на байтовете на буферното пространство за получаване, които са на разположение в другата посока на тази връзка. Urg показва, че в пакета има "спешни" данни. Опциите са опции tcp, затворени в ъглови скоби (напр. ).

Src, dst и флагове винаги присъстват. Другите полета зависят от съдържанието на заглавката на протокола tcp на пакета и се извеждат само ако е подходящо.

Тук е началната част на rlogin от хоста rtsg до host csam .

rtsg.1023> csam.login: S 768512: 768512 (0) спечели 4096 csam.login> rtsg.1023: S 947648: 947648 (0) ack 768513 спечели 4096 rtsg.1023> csam. Влизам: . ак 1 победа 4096 rtsg.1023> csam.login: P 1: 2 (1) ack 1 win 4096 csam.login> rtsg.1023:. Актив 2: 4096 rtsg.1023> csam.login: P 2:21 (19) ack 1 win 4096 csam.login> rtsg.1023: P 1: 2 (1) ack 21 win 4077 csam.login> rtsg.1023: P 2: 3 (1) ack 21 спечели 4077 urg 1 csam.login> rtsg.1023: P 3: 4 (1) ack 21 спечели 4077 urg 1

Първият ред казва, че tcp порт 1023 на rtsg е изпратил пакет за влизане в пристанището на csam. S показва, че е зададено флагът SYN . Номерът на последователността на пакетите е 768512 и не съдържа данни. (Нотацията е "първа: последна (nbytes)", което означава "номерата на последователностите първо , но не и последната, която е nbytes байтове на потребителските данни".) има опция с максимум сегмент, изискваща mss от 1024 байта.

Csam отговаря с подобен пакет, с изключение на това, че включва захранващо устройство за SYN на rtsg. Rtsg след това acks csam SYN. В "." означава, че не са зададени флагове. Пакетът не съдържа данни, така че няма номер на последователност от данни. Обърнете внимание, че номерът на последователността ack е малко цяло число (1). Първият път, когато tcpdump вижда tcp `conversation ', той отпечатва последователността от пакета. При следващите пакети на разговора се отпечатва разликата между последователния номер на текущия пакет и този начален номер на последователност. Това означава, че номерата на последователностите след първото могат да бъдат интерпретирани като относителни байтове в потока от данни на разговора (с първия байт за данни, всяка посока е "1"). "-S" ще замени тази функция, причинявайки изходните номера на поредицата.

На шестата линия rtsg изпраща csam 19 байта данни (байтове 2 до 20 в rtsg -> csam страна на разговора). Флагът PUSH е зададен в пакета. На седмата линия csam казва, че получените данни са изпратени от rtsg до, но не включват байт 21. Повечето от тези данни очевидно се намират в буферния буфер, тъй като прозорецът за получаване на csam е получил 19 байта по-малък. Csam също изпраща един байт данни към rtsg в този пакет. На 8-ия и 9-тия ред csam изпраща два байта спешни, избрани данни към rtsg.

Ако снимката беше достатъчно малка, че tcpdump не улови пълния TCP хедър, той интерпретира колкото се може повече от заглавката, а след това съобщава `` [[| tcp ] ", за да покаже, че остатъкът не може да бъде интерпретиран. Ако заглавката съдържа фалшива опция (една с дължина, която е или твърде малка, или извън края на заглавката), tcpdump я отчита като `` [ bad opt ] '' и не интерпретира други опции (тъй като е невъзможно да се каже където започват). Ако дължината на заглавката показва, че опциите са налице, но дължината на IP дейтаграмата не е достатъчно голяма, за да могат действително да бъдат налице, tcpdump я съобщава като `` [ bad hdr length ] ''.

Записване на TCP пакети със специални комбинации от флагове (SYN-ACK, URG-ACK и т.н.)

Има 8 бита в секцията контролни битове на TCP заглавката:

CWR | ИКЕ | URG | ACK | PSH | RST | SYN | FIN

Да приемем, че искаме да гледаме пакети, използвани за създаване на TCP връзка. Припомнете, че TCP използва 3-лентов протокол за ръкостискане, когато инициализира нова връзка; последователността на връзката по отношение на TCP контролните битове е

1) повикващият изпраща SYN

2) Получателят отговаря със SYN, ACK

3) повикващият изпраща ACK

Сега се интересуваме от улавяне на пакети, които имат само бит SYN (стъпка 1). Обърнете внимание, че не искаме пакети от стъпка 2 (SYN-ACK), просто обикновен първоначален SYN. Това, от което се нуждаем, е правилният израз на филтъра за tcpdump .

Припомнете структурата на TCP заглавка без опции:

0 15 31 ----------------------------------------------- ------------------ | източник на пристанище | крайно пристанище | -------------------------------------------------- --------------- | пореден номер | -------------------------------------------------- --------------- | номер на потвърждение | -------------------------------------------------- --------------- | HL | rsvd | C | E | U | A | P | R | S | F | размера на прозореца | -------------------------------------------------- --------------- | Контролна сума на TCP | спешно указание | -------------------------------------------------- ---------------

TCP заглавката обикновено съдържа 20 октета данни, освен ако не са налице опции. Първият ред на графата съдържа октети 0-3, втората линия показва октети 4 - 7 и т.н.

Започвайки да броим с 0, съответните битове за TCP контрол се съдържат в октет 13:

0 7 | 15 | 23 | 31 ---------------- | --------------- | --------------- | ---------------- | HL | rsvd | C | E | U | A | P | R | S | F | размера на прозореца | ---------------- | --------------- | --------------- | - --------------- | | 13 октет | | |

Нека да разгледаме по-отблизо октета не. 13:

| | | --------------- | | С | Д | U | А | P | R | S | F | | --------------- | 7 5 3 0 |

Това са битовете на TCP контрола, които ни интересуват. Преброихме битовете в този октет от 0 до 7 от дясно на ляво, така че PSH битът е битов номер 3, докато bit URG е номер 5.

Спомнете си, че искаме да уловим пакети само със SYN набор. Да видим какво се случва с октет 13, ако пристигне TCP дейтаграма с бита SYN, зададен в заглавката му:

| С | Д | U | А | P | R | S | F | | --------------- | | 0 0 0 0 0 0 1 0 |. | | --------------- | | 7 6 5 4 3 2 1 0 |

Ако разгледаме секцията с контролните битове, ще видим, че е зададен само бит номер 1 (SYN).

Ако се приеме, че октет номер 13 е 8-битово неподписан цяло число в мрежов байт, двоичната стойност на този октет е

00000010

и нейното десетично представяне е

7 6 5 4 3 2 1 0 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 = 2

Вече сме готови, защото сега знаем, че ако е зададено само SYN, стойността на 13-ия октет в TCP заглавката, когато се интерпретира като 8-битово неподписан цяло число в мрежов байт, трябва да бъде точно 2.

Тази връзка може да бъде изразена като

tcp [13] == 2

Можем да използваме този израз като филтър за tcpdump, за да гледаме пакети, които имат само SYN:

tcpdump -i xl0 tcp [13] == 2

Изразът казва "нека 13-тата октета на TCP дейтаграмата да има десетична стойност 2", което е точно това, което искаме.

Сега нека приемем, че трябва да уловим SYN пакети, но не ни е интересно дали ACK или всеки друг TCP контролен бит е зададен едновременно. Да видим какво става с октет 13, когато пристигне TCP дейтаграма със SYN-ACK набор:

| С | Д | U | А | P | R | S | F | | --------------- | | 0 0 0 1 0 0 1 0 | | --------------- | | 7 6 5 4 3 2 1 0 |

Сега битове 1 и 4 са зададени в 13-ия октет. Двоичната стойност на октет 13 е

00010010

което се превежда до десетичната

7 6 5 4 3 2 1 0 0 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 + 0 * 2 + 1 * 2 + 0 * 2 = 18

Сега не можем просто да използваме 'tcp [13] == 18' в изгледа на филтъра tcpdump , защото това би избрало само тези пакети, които са настроени SYN-ACK, но не и тези, които имат само SYN набор. Не забравяйте, че не ни е интересно дали ACK или който и да е друг контролен бит е зададен толкова дълго, колкото е зададено SYN.

За да постигнем нашата цел, трябва да логически И бинарна стойност на октет 13 с някаква друга стойност, за да запазим SYN бита. Знаем, че искаме SYN да бъде зададен във всеки случай, така че логично ще бъде стойността в 13-ия октет с двоичната стойност на SYN:

00010010 SYN-ACK 00000010 SYN И 00000010 (искаме SYN) И 00000010 (искаме SYN) -------- -------- = 00000010 = 00000010

Виждаме, че тази операция AND дава същия резултат, независимо дали е зададен ACK или друг бит за TCP контрол. Десетичното представяне на стойността AND, както и резултатът от тази операция, е 2 (двоично 00000010), така че знаем, че за пакети със SYN настройка трябва да се спази следната връзка:

((стойност на октет 13) И (2)) == (2)

Това ни насочва към израз на филтъра tcpdump

tcpdump -i xl0 'tcp [13] & 2 == 2'

Обърнете внимание, че в израза трябва да използвате единични кавички или обратно наклонена черта, за да скриете специалния знак AND ('&') от обвивката.

UDP пакети

UDP форматът е илюстриран с този RWho пакет:

които предадоха: udp 84

Това казва, че пристанището, което на приемащия актинид е изпратило udg дейтаграма на порт, който на излъчване на хост, интернет излъчване адрес. Пакетът съдържаше 84 байта потребителски данни.

Някои UDP услуги се разпознават (от номера на източника или целевия порт) и се отпечатва информацията от протокола от по-високо ниво. По-специално, заявките за услуга за име на домейн (RFC-1034/1035) и Sun RPC повиквания (RFC-1050) към NFS.

Заявки за сървъра за имена на UDP

(Забележка: Следващото описание предполага запознаване с протокола за домейна, описан в RFC-1035. Ако не сте запознати с протокола, следното описание ще бъде написано на гръцки език.)

Заявките за сървъра за имена са форматирани като

src> dst: id op? флагове qtype qclass име (len) h2opolo.1538> helios.domain: 3+ A? ucbvax.berkeley.edu. (37)

Хост h2opolo поиска от домейн сървъра на helios адрес за запис (qtype = A), свързан с името ucbvax.berkeley.edu. Идентификационният номер на заявката е "3". Бутонът "+" показва, че желаният флаг е бил зададен. Дължината на заявката беше 37 байта, без да се включват заглавията на протокола UDP и IP протокола. Операцията на заявката беше нормална, Query , така че op полето беше пропуснато. Ако операторът беше нещо друго, щеше да бъде отпечатан между "3" и "+". По същия начин, qclass е нормалната, C_IN и е пропуснат. Всякакви други класове биха били отпечатани непосредствено след "А".

Няколко аномалии са проверени и могат да доведат до допълнителни полета, включени в квадратни скоби: Ако заявката съдържа отговор, записът на органите или допълнителните записи, ancount , nscount или arcount се отпечатват като "[ n a]", "[ n n ] или "[ n au]", където n е подходящият брой. Ако някой от битовете за отговор е настроен (AA, RA или rcode), или някой от битовете "must be zero" се задава в байтове 2 и 3, се отпечатва "[b2 & 3 = x ]", където x е хексан заглавни байтове две и три.

Отговори на сървъра за имена на UDP

Отговорите на име на сървъра са форматирани като

src> dst: id op rcode флагове a / n / au тип данни от класа (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 с 3 записа за отговор, 3 записи на сървъра за имена и 7 допълнителни записа. Първият запис за отговори е тип А (адрес), а данните му са интернет адрес 128.32.137.3. Общият размер на отговора беше 273 байта, с изключение на UDP и IP заглавията. Оп (Query) и кода на отговор (NoError) бяха пропуснати, както и класа (C_IN) на запис А.

Във втория пример, helios отговаря на заявка 2 с код за отговор на несъществуващ домейн (NXDomain) без отговори, един сървър на имена и никакви записи на авторите. Символът `* 'показва, че е зададен отговорният отговор . Тъй като нямаше отговори, не бяха отпечатани никакви типове, класове или данни.

Други знаци на флага, които може да се появят, са `- '(налична рекурсия, RA, не е зададено) и` |' (прекъснато съобщение, TC, комплект). Ако секцията "въпрос" не съдържа точно един запис, се отпечатва "[ n q]".

Имайте предвид, че заявките и отговорите на сървъра за имена са склонни да бъдат големи, а стандартният шпаплен от 68 байта може да не улови достатъчно пакета за отпечатване. Използвайте флага -s, за да увеличите скоростта, ако трябва сериозно да проучите трафика на сървъра за имена. " 128 " работи добре за мен.

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

tcpdump вече включва доста широко SMB / CIFS / NBT декодиране за данни за UDP / 137, UDP / 138 и TCP / 139. Някои примитивни декодиране на IPX и NetBEUI SMB данни също е направено.

По подразбиране се прави сравнително минимално декодиране, като се прави много по-подробно декодиране, ако се използва -v. Бъдете предупредени, че с един-единствен SMB пакет може да поеме страница или повече, така че използвайте само -v, ако наистина искате всички глупави детайли.

Ако декодирате SMB сесии, съдържащи стрийми за Unicode, може да поискате да зададете променливата за обкръжение USE_UNICODE на 1. Заявка за автоматично откриване на символи за Unicode.

За информация относно SMB пакетни формати и какво означават всички полета, вижте www.cifs.org или директорията pub / samba / specs / на вашия любим сайт mirba.org samba.org. Малките пластири са написани от Andrew Tridgell (tridge@samba.org).

Заявки и отговори от NFS

Заявките и отговорите на Sun NFS (мрежова файлова система) се отпечатват като:

src.xid> dst.nfs: len op args src.nfs> dst.xid: отговор stat len ​​op резултати sushi.6709> wrl.nfs: 112 readlink fh 21,24 / 10,73165 wrl.nfs> sushi.6709: отговори добре 40 readlink "../var" sushi.201b> wrl.nfs: 144 търсене fh 9,74 / 4096.6878 "xcolors" wrl.nfs> sushi.201b: reply ok 128 lookup fh 9,74 / 4134.3150

На първия ред домакин суши изпраща транзакция с id 6709 до wrl (забележете, че номерът, следващ хоста src, е идентификатор на транзакцията, а не портът на източника). Искането беше 112 байта, с изключение на заглавията на UDP и IP адресите. Операцията беше readlink (чете символна връзка) на дръжката на файла ( fh ) 21,24 / 10,731657119. (Ако някой има късмет, както в този случай, дръжката на файла може да се интерпретира като основна, малка двойка номера на устройство, последвана от номерът на инода и номера на генерирането.) Wrl отговаря "ok" със съдържанието на връзката.

На третия ред суши поиска wrl да търси името " xcolors " в директория 9,74 / 4096,6878. Обърнете внимание, че отпечатаните данни зависят от типа операция. Форматът е предназначен да бъде самостоятелен, ако се чете във връзка с NFS протокол spec.

Ако е дадено знакът -v (подробно), се отпечатва допълнителна информация. Например:

sushi.1372a> wrl.nfs: 148 прочетено fh 21,11 / 12,195 8192 байта @ 24576 wrl.nfs> sushi.1372a: отговор ok 1472 прочетете REG 100664 id 417/0 sz 29388

(-V също така отпечатва IP адресите на TTL, ID, дължина и фрагментация, които са били пропуснати от този пример). На първия ред суши поиска wrl да прочете 8192 байта от файла 21,11 / 12,195 при отместване на байтовете 24576. Wrl отговаря "ok"; пакетът, показан на втория ред, е първият фрагмент от отговора и оттам има едва 1472 байта (останалите байтове ще последват в следващите фрагменти, но тези фрагменти нямат NFS или дори UDP заглавки и затова не могат да бъдат отпечатани, в зависимост от използвания израз на филтъра). Тъй като знакът -v е даден, някои от файловите атрибути (които се връщат в допълнение към файловите данни) се отпечатват: типа на файла (`` REG '', за обикновения файл), файловия режим (в осмичен) uid и gid и размера на файла.

Ако знакът -v е даден повече от веднъж, се отпечатват още повече подробности.

Обърнете внимание, че заявките за NFS са много големи и голяма част от детайлите няма да бъдат отпечатани, освен ако не е увеличено. Опитайте да използвате " -s 192 ", за да гледате трафик на NFS.

Пакетите с отговори NFS не посочват изрично операцията RPC. Вместо това tcpdump следи за "скорошни" заявки и ги сравнява с отговорите, използвайки идентификационния номер на транзакцията. Ако отговорът не следва отблизо съответната заявка, тя може да не е паралелна.

AFS искания и отговори

Transarc AFS (Andrew File System) заявките и отговорите се отпечатват като:

src.sport> dst.dport: rx пакет тип src.sport> dst.dport: rx услуга тип пакет повикване call-name args src.sport> dst.dport: rx услуга тип пакета отговор call-name args elvis. 7001> pike.afsfs: rx данни fs повикване преименувайте стария fid 536876964/1/1 ".newsrc.new" new fid 536876964/1/1 ".newsrc" pike.afsfs> elvis.7001: rx data fs replies rename

На първия ред домакин елвис изпраща RX пакет за щука. Това е RX пакет данни към услугата fs (fileserver) и е стартирането на RPC повикване. Повикването на RPC беше преименуване, със стария идентификационен номер на файла на 536876964/1/1 и старото име на файла `.newsrc.new ', както и новия идент. № на файла 536876964/1/1 и новото име на файла`. newsrc ". Хостът щука отговаря с RPC отговор на повикването с преименуване (което е било успешно, защото е пакет данни, а не пакет за прекратяване).

По принцип всички RPC RPC на AFS се декодират поне чрез RPC име на повикване. Повечето RPC RPC имат поне някои от аргументите декодирани (обикновено само "интересните" аргументи, за някои дефиниции на интересни).

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

Ако знакът -v (подробно) е даден два пъти, се отпечатват пакетите за потвърждение и допълнителната информация за заглавката, като идентификационния номер на повикването за RX, номера на повикването, серийния номер, серийния номер и RX пакетните знамена.

Ако знакът -v е даден два пъти, се отпечатва допълнителна информация, като идентификационния номер на повикването RX, серийния номер и знамето за RX пакетите. Информацията за преговорите за MTU също се отпечатва от RX ack пакети.

Ако знакът -v е даден три пъти, индексът за сигурност и идентификационният номер на услугата се отпечатват.

Кодовете за грешки са отпечатани за прекратяване на пакетите, с изключение на пакетите с Ubik маяци (защото прекратяването на пакетите се използва за означаване на глас "yes" за протокола Ubik).

Обърнете внимание, че заявките за AFS са много големи и много от аргументите няма да бъдат отпечатани, освен ако не се увеличи snaplen . Опитайте се да използвате ` -s 256 ', за да гледате трафика AFS.

AFS пакетите за отговор не посочват изрично операцията RPC. Вместо това tcpdump следи за "последните" заявки и ги сравнява с отговорите, като използва номера на повикването и идентификационния номер на услугата. Ако отговорът не следва отблизо съответната заявка, тя може да не е паралелна.

KIP Appletalk (DDP в UDP)

Пакетите Appletalk DDP, капсулирани в дейтаграми на UDP, се дезапакетират и изхвърлят като DDP пакети (т.е. цялата информация за заглавната част на UDP се изхвърля). Файлът /etc/atalk.names се използва за преобразуване на числата на appletalk и на номерата на възлите към имена. Линиите в този файл имат формата

номер на име 1.254 етер 16.1 icsd-net 1.254.110 асо

Първите две линии дават имената на мрежите на appletalk. Третият ред дава името на конкретен хост (хост се различава от мрежата от 3-тата октета в числото - нетният номер трябва да има два октета, а номерът на хоста трябва да има три октета.) Номерът и името трябва да бъдат разделени по бели полета (празни места или раздели). Файлът /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 не съществува или не съдържа запис за някои appletalk хост / нет номер, адресите се отпечатват в цифров вид.) В първия пример NBP (DDP порт 2) на мрежата 144.1 възел 209 изпраща към всичко, което слуша на порт 220 на мрежовия мрежов възел 112. Вторият ред е същият, освен ако не е известно пълното име на изходния възел ("офис"). Третият ред е изпращане от порт 235 на нетен jssmag възел 149, за да се излъчва на логическия порт на icsd-net (забележете, че адресът за излъчване (255) е означен с нетно име без хост номер - поради тази причина е добра идея за да запазите имената на възлите и мрежовите имена различни в /etc/atalk.names).

NBP (протокол за свързване на име) и пакетите 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> -net.112.220: nbp-отговор 190: "techpit: LaserWriter @ *" 186

Първият ред е заявка за търсене на име за лазерни писма, изпратена от net icsd хост 112 и излъчена в мрежата jssmag. Идентификационният номер nbp за търсенето е 190. Вторият ред показва отговор за тази заявка (имайте предвид, че той има същия идентификатор) от хост jssmag.209, заявявайки, че разполага с лазерен ресурс, наречен "RM1140", регистриран на порт 250. Третият line е друг отговор на същото искане, казвайки, че хостът на techpit има лазерни "techpit" регистриран на пристанище 186.

ATP пакетно форматиране е демонстрирано чрез следния пример:

jssmag.209.165: atp-resp 12266: 0 (512) 0xae040000 helios.132> jssmag.209.165: atp-re 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 инициира транзакция id 12266 с хост helios, като поиска до 8 пакета (`<0-7> '). Шестмесечното число в края на реда е стойността на полето "userdata" в заявката.

Helios отговаря с 8 512 байта пакета. "Дискът" след идентификационния номер на транзакцията дава номера на последователността на пакета в транзакцията, а номерът в паренса е количеството данни в пакета, с изключение на ATP заглавката. "*" На пакет 7 показва, че е зададен битът на EOM.

След това Jssmag.209 изисква пакети 3 & 5 да бъдат препредадени. Хелиос ги препраща, след което jssmag.209 освобождава транзакцията. Накрая jssmag.209 инициира следващата заявка. "*" На заявката показва, че XO ("точно веднъж") не е зададен.

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

Раздробените интернет дейтаграми се отпечатват като

(име на фрагмент : размер @ отместване +) ( идентификатор на фрагмента : размер @ отместване )

(Първата форма показва, че има повече фрагменти. Вторият показва, че това е последният фрагмент.)

Id е идентификационният номер на фрагмента. Размерът е размерът на фрагмента (в байтове), с изключение на IP заглавката. Офсетов е отместването на този фрагмент (в байтове) в оригиналната дейтаграма.

Информацията за фрагмента се извежда за всеки фрагмент. Първият фрагмент съдържа заглавката на протокола от по-високо ниво и информацията за frag се отпечатва след информацията за протокола. Фрагментите след първото не съдържат заглавие на протокола от по-високо ниво и информацията за frag се отпечатва след адресите на източника и дестинацията. Например, тук е част от ftp от arizona.edu до lbl-rtsg.arpa по CSNET връзка, която не изглежда да обработва 576 байта дейтаграми:

arizona.ftp-данни> rtsg.1170:. 1024: 1332 (308) ack 1 победа 4096 (фрагмент 595а: 328 ° 0 +) arizona> rtsg: (frag 595a: 204 @ 328) rtsg.1170> arizona.ftp данни:. Акк 1536 спечели 2560

Тук има няколко неща, които трябва да обърнете внимание: Първо, адресите във втория ред не включват номера на портове. Това е така, защото информацията за протокола TCP е всичко в първия фрагмент и нямаме представа какъв е портът или номерата на последователностите при отпечатването на по-късните фрагменти. На второ място, информацията за последователността tcp в първия ред се отпечатва така, сякаш имаше 308 байта потребителски данни, когато в действителност има 512 байта (308 в първия фрагмент и 204 във втория). Ако търсите дупки в пространството за последователност или се опитвате да съвпадате с акаунти с пакети, това може да ви заблуди.

Пакет с IP , който не фрагментира флага, е отбелязан с последващо (DF) .

Показване на времето

По подразбиране всички изходни линии се предхождат от таймер. Клеймото е текущото време във формата

чч: мм: ss.frac

и е толкова точен, колкото и часовника на ядрото. Кратката дата отразява времето, когато ядрото за първи път видя пакета. Не се правят опити да се отчете времето между интерфейса на Ethernet, който е премахнал пакета от проводника и когато ядрото е обслужвало прекъсването на новия пакет.

ВИЖТЕ СЪЩО

трафик (1С), нит (4P), bpf (4), pcap (3)

Важно: Използвайте командата човек ( % man ), за да видите как се използва команда на вашия компютър.