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

47 /* функция p_output() вычисляет и сохраняет контрольную сумму IP */

48 ip->ip_v = IPVERSION;

49 ip->ip_hl = sizeof(struct ip) >> 2;

50 ip->ip_tos = 0;

51 #if defined(linux) || defined(__OpenBSD__)

52 ip->ip_len = htons(userlen); /* сетевой порядок байтов */

53 #else

54 ip->ip_len = userlen; /* порядок байтов узла */

55 #endif

56 ip->ip_id = 0; /* это пусть устанавливает уровень IP */

57 ip->ip_off = 0; /* смещение флагов, флаги MF и DF */

58 ip->ip_ttl = TTL_OUT;

59 Sendto(rawfd, buf, userlen, 0, dest, destlen);

60 }

24-26 Указатель ipуказывает на начало заголовка IP (структуру ip), а указатель uiуказывает на то же место, но структура udpiphdrявляется объединением заголовков IP и UDP.

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

28-31 Переменная ui_len— это длина дейтаграммы UDP: количество байтов пользовательских данных плюс размер заголовка UDP (8 байт). Переменная userlen(количество байтов пользовательских данных, которые следуют за заголовком UDP) увеличивается на 28 (20 байт на заголовок IP и 8 байт на заголовок UDP), для того чтобы соответствовать настоящему размеру дейтаграммы IP.

32-45При вычислении контрольной суммы UDP учитывается не только заголовок и данные UDP, но и поля заголовка IP. Эти дополнительные поля заголовка IP образуют то, что называется псевдозаголовком ( pseudoheader ). Включение псевдозаголовка обеспечивает дополнительную проверку на то, что если значение контрольной суммы верно, то дейтаграмма была доставлена на правильный узел и с правильным кодом протокола. В указанных строках располагаются операторы инициализации полей в IP-заголовке, формирующих псевдозаголовок. Данный фрагмент кода несколько запутан, но его объяснение приводится в разделе 23.6 [128]. Конечным результатом является запись контрольной суммы UDP в поле ui_sum, если не установлен флаг zerosum(что соответствует наличию аргумента командной строки -0).

Если при вычислении контрольной суммы получается 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.