Уильям Стивенс - UNIX - разработка сетевых приложений

Если при вычислении контрольной суммы получается 0, вместо него записывается значение 0xffff. В обратном коде эти числа совпадают, но протокол UDP устанавливает контрольную сумму в нуль, чтобы обозначить, что она вовсе не была вычислена. Обратите внимание, что в листинге 28.10 мы не проверяем, равно ли значение контрольной суммы нулю: дело в том, что в случае ICMPv4 нулевое значение контрольной суммы не означает ее отсутствия.

Следует отметить, что в Solaris 2.x, где xether_type) != ETHERTYPE_IP)

21 err_quit("Ethernet type not IP", ntohs(eptr->ether_type));

22 return (udp_check(ptr + 14, len — 14));

23 case DLT_SLIP: /* заголовок SLIP = 24 байта */

24 return (udp_check(ptr + 24, len — 24));

25 case DLT_PPP: /* заголовок PPP = 24 байта */

26 return (udp_check(ptr + 24, len — 24));

27 default:

28 err_quit("unsupported datalink (%d)", datalink);

29 }

30 }

31 }

14-29 Наша функция next_pcap(см. листинг 29.12) возвращает следующий пакет из устройства захвата пакетов. Поскольку заголовки канального уровня различаются в зависимости от фактического типа устройства, мы применяем ветвление в зависимости от значения, возвращаемого функцией pcap_datalink.

Сдвиги на 4, 14 и 24 байта объясняются на рис. 31.9 [128]. Сдвиг, равный 24 байтам, показанный для заголовков SLIP и PPP, применяется в BSD/OS 2.1.

Несмотря на то, что в названии DLT_EN10MB фигурирует обозначение «10МВ», этот тип канального уровня используется для сетей Ethernet, в которых скорость передачи данных равна 100 Мбит/с.

Наша функция udp_check(см. листинг 29.13) исследует пакет и проверяет поля в заголовках IP и UDP.

В листинге 29.12 показана функция next_pcap, возвращающая следующий пакет из устройства захвата пакетов.

Листинг 29.12. Функция next_pcap: возвращает следующий пакет

//udpcksum/pcap.c

38 char*

39 next_pcap(int *len)

40 {

41 char *ptr;

42 struct pcap_pkthdr hdr;

43 /* продолжаем следить, пока пакет не будет готов */

44 while ((ptr = (char*)pcap_next(pd, &hdr)) == NULL);

45 *len = hdr.caplen; /* длина захваченного пакета */

46 return (ptr);

47 }

43-44 Мы вызываем библиотечную функцию pcap_next, возвращающую следующий пакет. Указатель на пакет является возвращаемым значением данной функции, а второй аргумент указывает на структуру pcap_pkthdr, которая тоже возвращается заполненной:

struct pcap_pkthdr {

struct timeval ts; /* временная метка */

bpf_u_int32 caplen; /* длина захваченного фрагмента */

bpf_u_int32 len; /* полная длина пакета, находящегося в канале */

};

Временная отметка относится к тому моменту, когда пакет был считан устройством захвата пакетов, в противоположность моменту фактической передачи пакета процессу, которая может произойти чуть позже. Переменная caplenсодержит длину захваченных данных (вспомним, что в листинге 29.2 нашей переменной shaplenбыло присвоено значение 200 и она являлась вторым аргументом функции pcap_open_liveв листинге 29.5). Назначение устройства захвата пакетов состоит в захвате заголовков, а не всего содержимого каждого пакета. Переменная len — это полная длина пакета, находящегося в канале. Значение caplenбудет всегда меньше или равно значению len.

45-46 Перехваченная часть пакета возвращается через указатель (аргумент функции), и возвращаемым значением функции является указатель на пакет. Следует помнить, что указатель на пакет указывает фактически на заголовок канального уровня, который представляет собой 14-байтовый заголовок Ethernet в случае кадра Ethernet или 4-байтовый псевдоканальный (pseudo-link) заголовок в случае закольцовки на себя.

Если мы посмотрим на библиотечную реализацию функции pcap_next, мы увидим, что между различными функциями существует некоторое «разделение труда», схематически изображенное на рис. 29.5. Наше приложение вызывает функции pcap_, среди которых есть как зависящие, так и не зависящие от устройства захвата пакетов. Например, мы показываем, что реализация BPF вызывает функцию read, в то время как реализация DLPI вызывает функцию getmsg, а реализация Linux вызывает recvfrom.