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

30 printf(" type = %d, code = %d\n", icmp6->icmp6_type, icmp6->icmp6_code);

Вторая часть функции readable_v6приведена в листинге 28.32. Код аналогичен приведенному в листинге 28.30: мы проверяем тип ICMP-ошибки, убеждаемся, что дейтаграмма, вызвавшая ошибку, является UDP-дейтаграммой, а затем строим структуру icmpd_err, которую отсылаем клиенту.

Листинг 28.32. Обработка полученной дейтаграммы ICMPv6, вторая часть

//icmpd/readable_v6.c

31 if (icmp6->icmp6_type == ICMP6_DST_UNREACH ||

32 icmp6->icmp6_type == ICMP6_PACKET_TOO_BIG ||

33 icmp6->icmp6_type == ICMP6_TIME_EXCEEDED) {

34 if (icmp6len

35 err_quit("icmp6len (%d)

36 hip6 = (struct ip6_hdr*)(buf + 8);

37 hlen2 = sizeof(struct ip6_hdr);

38 printf("\tsrcip = %s, dstip = %s, next hdr = %d\n",

39 Inet_ntop(AF_INET6, &hip6->ip6_src, srcstr, sizeof(srcstr)),

40 Inet_ntop(AF_INET6, &hip6->ip6_dst, dststr, sizeof(dststr)),

41 hip6->ip6_nxt);

42 if (hip6->ip6_nxt == IPPROTO_UDP) {

43 udp = (struct udphdr*)(buf + 8 + hlen2);

44 sport = udp->uh_sport;

45 /* поиск доменного сокета клиента, отправка заголовков */

46 for (i = 0; i = 0 &&

48 client[i].family == AF_INET6 &&

49 client[i].lport == sport) {

50 bzero(&dest, sizeof(dest));

51 dest.sin6_family = AF_INET6;

52 #ifdef HAVE_SOCKADDR_SA_LEN

53 dest.sin6_len = sizeof(dest);

54 #endif

55 memcpy(&dest.sin6_addr, &hip6->ip6_dst,

56 sizeof(struct in6_addr));

57 dest.sin6_port = udp->uh_dport;

58 icmpd_err.icmpd_type = icmp6->icmp6_type;

59 icmpd_err.icmpd_code = icmp6->icmp6_code;

60 icmpd_err.icmpd_len = sizeof(struct sockaddr_in6);

61 memcpy(&icmpd_err.icmpd_dest, &dest, sizeof(dest));

62 /* преобразование типа и кода ICMPv6 к значению errno */

63 icmpd_err.icmpd_errno = EHOSTUNREACH; /* по умолчанию */

64 if (icmp6->icmp6_type == ICMP6_DST_UNREACH &&

65 icmp6->icmp6_code ICMP6_DST_UNREACH_NOPORT)

66 icmpd_err.icmpd_errno = ECONNREFUSED;

67 if (icmp6->icmp6_type == ICMP6_PACKET_TOO_BIG)

68 icmpd_err.icmpd_errno = EMSGSIZE;

69 Write(client[i].connfd, &icmpd_err, sizeof(icmpd_err));

70 }

71 }

72 }

73 }

74 return(--nready);

75 #endif

76 }

Символьные сокеты обеспечивают три возможности:

1. Чтение и запись пакетов ICMPv4, IGMPv4 и ICMPv6.

2. Чтение и запись IP-дейтаграммы с полем протокола, которое не обрабатывается ядром.

3. Формирование своих собственных заголовков IPv4, обычно используемых в диагностических целях (или, к сожалению, хакерами).

Два традиционных диагностических средства — программы pingи traceroute— используют символьные сокеты. Мы разработали наши собственные версии этих программ, поддерживающие обе версии протокола — и IPv4, и IPv6. Также нами разработан наш собственный демон icmpd, который обеспечивает доступ к сообщениям об ошибках ICMP через сокет UDP. Данный пример также иллюстрирует передачу дескриптора через доменный сокет Unix между неродственными клиентом и сервером.

1. В этой главе говорилось, что почти все поля заголовка IPv6 и все дополнительные заголовки доступны приложению через параметры сокета или вспомогательные данные. Какая информация из дейтаграммы IPv6 не доступна приложению?

2. Что произойдет в листинге 28.30, если по какой-либо причине клиент перестанет производить считывание из своего доменного сокета Unix и демон icmpdнакопит множество сообщений для данного клиента? В чем заключается простейшее решение этой проблемы?

3. Если задать нашей программе pingадрес широковещательной передачи, направленный в подсеть, она будет работать. То есть широковещательный эхо- запрос ICMP посылается как широковещательный запрос канального уровня, даже если мы не установим параметр сокета SO_BROADCAST. Почему?

4. Что произойдет с программой ping, если мы запустим ее на узле с несколькими интерфейсами, а в качестве аргумента имени узла возьмем групповой адрес 224.0.0.1?

В настоящее время большинство операционных систем позволяют приложению получать доступ к канальному уровню. Это подразумевает следующие возможности:

1. Отслеживание пакетов, принимаемых на канальном уровне, что, в свою очередь, позволяет запускать такие программы, как tcpdump, на обычных компьютерных системах (а не только на специальных аппаратных устройствах для отслеживания пакетов). Если добавить к этому способность сетевого интерфейса работать в смешанном режиме ( promiscuous mode ), приложение сможет отслеживать все пакеты, проходящие по локальному кабелю, а не только предназначенные для того узла, на котором работает эта программа.

Эта возможность не так полезна в коммутируемых сетях, которые получили широкое распространение в последнее время. Дело в том, что коммутатор пропускает трафик на конкретный порт только в том случае, если этот трафик адресован конкретному устройству или устройствам, подключенным к этому порту, каким бы трафик ни был: направленным, широковещательным или многоадресным. Для того чтобы получать трафик, передаваемый через другие порты коммутатора, нужно сначала переключить свой порт коммутатора в режим контроля (monitor mode или port mirroring). Заметьте, что многие устройства, которые обычно не считают коммутаторами, на самом деле являются таковыми. Например, двухскоростной концентратор 10/100 обычно является двухпортовым коммутатором: один порт для сетей, работающих на 100 Мбит/с, другой — для сетей на 10 Мбит/с.

2. Возможность запуска определенных программ как обычных приложений, а не как частей ядра. Скажем, большинство версий Unix сервера RARP — это обычные приложения, которые считывают запросы RARP с канального уровня (запросы RARP не являются дейтаграммами IP), а затем передают ответы также на канальный уровень.

Три наиболее распространенных средства получения доступа к канальному уровню в Unix — это пакетный фильтр BSD (BPF, BSD Packet Filter), DLPI в SVR4 (Datalink Provider Interface — интерфейс поставщика канального уровня) и интерфейс пакетных сокетов Linux ( SOCK_PACKET). Мы приводим в этой главе обзор перечисленных средств, а затем описываем libcap— открытую для свободного доступа библиотеку, содержащую функции для захвата пакетов. Эта библиотека работает со всеми тремя перечисленными средствами, и использование библиотеки позволяет сделать наши программы не зависящими от фактического способа обеспечения доступа к канальному уровню, применяемому в данной операционной системе. Мы описываем эту библиотеку, разрабатывая программу, которая посылает запросы серверу имен DNS (мы составляем свои собственные дейтаграммы UDP и записываем их в символьный сокет) и считывает ответ при помощи libcap, чтобы определить, добавляет ли сервер имен контрольную сумму в дейтаграммы UDP.

4.4BSD и многие другие Беркли-реализации поддерживают BPF — пакетный фильтр BSD (BSD Packet Filter). Реализация BPF описана в главе 31 [128]. История BPF, описание псевдопроцессора BPF и сравнение с пакетным фильтром SunOs 4.1.x NIT приведены в [72].