Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Введение

туннель инкапсуляция linux ядро

Бакалаврская работа была выполнена на предприятие ELTEX, для сервисных маршрутизаторов ESR100/200/1000/1200. Целью бакалаврской работы является изучение и разработка «Механизма отправки сообщений активности» для GRE туннеля. В данной работе будет рассмотрен GRE (Generic Routing Encapsulation - общая инкапсуляция маршрутов) туннель. GRE - это протокол туннелирования сетевых пакетов, разработанный компанией Cisco Systems. Его основное назначение - инкапсуляция пакетов сетевого уровня сетевой модели OSI в IP пакеты. Сообщения поддержки активности (Keepalive) отправляются сетевым устройством по физическому или виртуальному каналу связи для информирования другого сетевого устройства о том, что канал связи между ними сохраняет работоспособность. Данная работа актуальна потому, что туннель GRE не может определить состояние туннеля с другой стороны. Поэтому возникает проблема, связанная с тем что если с одной стороны туннель активен, а с другой нет, то пакеты, проходящие через туннель GRE, будут попадать в так называемые «черные дыры», т.е. будут уничтожатся. Пакеты будут уничтожатся потому что, если туннель не активен, то на маршрутизаторе не будет нужного маршрута, вследствие чего пакеты будут отброшены. Механизм отправки сообщений активности (keepalive), позволяет избежать данной проблемы, но только на той стороне где данный механизм активен, т.к. данный механизм опирается на инкапсуляцию пакетов, поэтому данный механизм может работать и с туннелем который не поддерживает его. Как только соединение между сторонами туннеля будет утеряна, после выполнения определенных условий задаваемых при конфигурирование, будет произведена смена состояния, в следствие чего будут удалены маршруты, и пакеты не смогут попасть в туннель.

В данном дипломном проекте требуется разработать «Механизма отправки сообщений активности» для GRE туннеля. Требуется понять на каком уровне модели OSI работает данная подсистема, так же изучить работу с формированием skb пакетов, изучить принципы работы keepalive для GRE туннеля, так же нужно изучить подсистему времени для использования таймера. Данный механизм разрабатывается для сервисных маршрутизаторов ELTEX ESR100/200/1000/1200. Для реализации данной задачи нужно изучить принципы конфигурирования GRE туннеля для того что бы можно было задать время таймаута и количество повторов, по истечению. Так же была модифицирована утилита iproute2. Через данную утилиту производится конфигурирование механизма посредствам IOCTL вызовам.



1. Описание

1.1 IP-туннель

IP-туннель - Сетевой Интернет-протокол (IP), соединение между двумя сетями. При передачи он использует различные протоколы сети посредствам инкапсуляцию. IP-туннель часто применяется при создании двух перекрывающихся IP-сети, которые не имеют прямой пути друг к другу, с основанием через промежуточное транспортное соединение протокола маршрутизации. В объединение с протоколом IPsec виртуальной частной сети между двумя или более частными сетями через публичную соединение может быть создана, например, по средствам Интернет.

На концах между сетью источника и транзитной сети, а также сети транзита и назначения сети, применяются шлюзы, которые назначают концы туннеля через IP-транзитной сети. Таким образом, концы IP-туннеля являются связанными с IP-маршрутизаторами, которые создают стандартный IP-маршрут между сетью исходящего устройства и сетью конечного интерфейса. В пакетах, поступивших в эти конечные точки происходит декапсуляция, удаление их транзитного заголовка кадра и, таким образом, превращается в начальный формат IP и входит в IP-стека конечную точку туннеля. Кроме того, инкапсуляция любого другого сетевого протокола, который используется для транспортировки, например, протокол IPsec или протокол безопасности транспортного уровня, не удаляется.

Туннелирование (от английского Tunneling. - «прокладка туннеля») в компьютерных сетях. - Процесс, в котором создается безопасное логическое соединение между двумя конечными точками посредствам инкапсуляции различных протоколов туннелирования обеспечивает собой способ сборки сети, в которой сетевой протокол инкапсулируется в другой. от обычных сетевых многоуровневый моделей (например, OSI или TCP / IP) туннелирования, отличающийся тем, что инкапсулированный протокол имеет тот же или более низкий уровень, чем используется в качестве туннеля.

Туннелирование дело в том, чтобы запаковать передающую часть данных, вместе с полями обслуживания, в новом пакете, чтобы обеспечить конфиденциальность и целостность передаваемой части, в том числе служебных полей. Туннелирование может использоваться на сетевом и прикладном уровнях. Комбинация туннелирования и шифрования позволяет для создания закрытых виртуальных частных сетей (VPN). Туннель обычно используется для объединения транспортных протоколов или для создания защищенного соединения между сетевыми узлами.

В процессе инкапсуляции (туннелирования) принимают следующие типы участия протоколов:

· транспортирующий протокол;

· несущий протокол;

· протокол инкапсуляции.

Протокол передающей сети служит несущим, а протокол объединяемых сетей - транспортируемым. Пакеты, передаваемого протокола размещены в пакете данных протокола для передачи, применяя протокол инкапсуляции. Пакеты - «пассажиры» не обрабатываются при передаче в граничной сети в любом случае. Инкапсуляция выполняется конечным устройство (маршрутизатор или коммутатор), который находится на концах между сетями исходящего и конечного интерфейса. Получение пакетов транспортируемого протокола из передающих пакетов выполняет второе конечное устройство, расположенное на границе между транзитной сетью и сетью назначения. Пограничное устройства указывают в несущих пакетах свои адреса, а не адреса узлов сети назначения.



1.2 Туннели GRE

Функционирование туннеля GRE не зависит от состояния туннеля. Поэтому каждый конечный интерфейс туннелей не знает о состоянии или наличии другого удаленного конечного интерфейса туннеля. Поэтому, локальный маршрутизатор граничной точки туннеля не может изменить состояние интерфейса GRE туннеля, если другой конечный интерфейс туннеля недоступен. Возможность изменить состояние интерфейса на отключенный, когда вторая сторона соединения недоступна, применяется для удаления маршрутов (т.е. статических маршрутов) в таблице маршрутизации, которую использует интерфейс исходящего соединения. К примеру, если интерфейс отключен или нет соединения, тогда все статические маршруты, которые привязаны к интерфейсу, удаляются из таблицы маршрутизации. Данная возможность позволяет использовать альтернативный маршрут или альтернативный интерфейс при назначении альтернативного (динамического) маршрута или при помощью маршрутизации на основе политик (PBR). Поэтому, интерфейс туннеля GRE сменит состояние на активное сразу после установки или восстановления соединения и будет активным пока будет существовать действительный адрес источника туннеля или интерфейс активен. IP-адрес назначения туннеля также должны быть доступным для маршрутизации. Иначе, даже если вы настроили адрес другого конца туннеля, туннель будет не доступен. Поэтому статический маршрут PBR основанный на политиках или передача пакетов через интерфейс GRE туннеля активен, даже если туннельные пакеты GRE не доходят до другой стороны туннеля. До внедрения механизма отправки сообщений активности GRE, GRE туннель менял состояние на не активный по нескольким причинам:

· На исходящем интерфейсе нет маршрута, который соответствует адресу назначения туннеля.

· Отключался интерфейс, к которому прикреплен туннеля.

· Маршрут по адресу назначения туннеля проходит через этот туннель.

Эти три правила (без маршрута, и отключение интерфейса рассогласование туннеля маршрута назначения) являются глобальными проблемами маршрутизатора на концах туннеля, и проблема промежуточной производительности сети не ограничены. В частности, правила не могут объяснить случай, когда пакеты отправляются, через туннель GRE, но теряются до прибытия к конечному интерфейсу туннеля. С этим связано, что пакеты, проходящие через данный туннель GRE попадают в «черную дыру», при настроенных альтернативных маршрутов с помощью PBR, или статический маршрут через другой интерфейс потенциально доступен. Сообщения Keepalive GRE туннеля применяются, чтобы решить проблему так же, как сообщения используются на физических интерфейсах. Программное обеспечение компании серии ELTEX сервисные маршрутизаторы ERS100/200/1000/1200 вы можете установить конфигурацию сообщений поддержки активности в нужном интерфейсе туннеля GRE «точка-точка». Это изменение, в свою очередь, позволяет динамически отключать интерфейс, если не возвращаются сообщений активности в течение некоторого периода времени.

1.3 Сообщения поддержки активности туннеля с общей инкапсуляцией маршрутов (GRE)

Механизм отправки сообщений поддержки активности туннеля GRE дает возможность одному из интерфейсов отправлять пакеты для поддержки активности другому маршрутизатору и получать ответы от него, даже если другой маршрутизатор не поддерживает механизм GRE keepalive. Поэтому GRE является механизмом туннелирования для IP-пакетов туннелирования внутри IP-протокола, IP-пакет GRE туннеля может быть создан внутри другого туннеля пакета IP-GRE. Для сообщений поддержки активности GRE, отправитель заранее вкладыввает в созданный пакет, пакет ответа в пределах первоначального пакета-сообщения с запросом о поддержке активности, другой стороне необходимо произвести только стандартную декаплуляцию GRE внешнего заголовка IP-GRE, а затем передать внутренний пакет IP-GRE. В частности, механизм отправки сообщений активности туннеля, идут не через туннель, и через физический интерфейс. Это означает, что функция туннелирования выходного интерфейса, например, защита туннеля, качество обслуживания (QoS) и так далее, не влияют на сообщения поддержки активности GRE туннеля. Если есть входящий ACL трафика в интерфейсе туннеля GRE, пакеты поддержки активности туннеля GRE (список доступа разрешение на хост GRE) должно быть разрешено. Другой атрибут сообщений активности GRE туннель - независимые счетчики сообщений поддержки активности. Проблема конфигурации сообщений активности на одной стороне туннеля является то, что только один маршрутизатор, на котором установлен механизм поддержки активности туннеля, помечает интерфейс туннеля не активным, если истекло время ожидания сообщений активности. Интерфейс GRE туннеля на другой стороне, где нет поддержки активности туннеля, остается активным, даже если другая сторона туннеля отключена. Туннель может стать черной дырой для пакетов, направленных в сторону туннеля, который не имеет настроенного механизма отправки сообщений активности. В большой сети туннелей GRE с топологией «звезда» следует выполнить только настройку конфигурации сообщений поддержки активности на стороне оконечных устройств, но не стороне концентратора. В большинстве случаев для оконечных устройств более важна возможность определять недостижимость концентратора и переключаться на резервный путь (например, для резервирования соединений).



1.4 Принципы работы сообщений поддержки активности туннеля

Туннель GRE - это находящийся на маршрутизаторе виртуальный интерфейс, который поддерживает механизм для инкапсулирования пакетов, передаваемых внутри транспортного протокола (passenger packet). Этот механизм предоставляет набор служб, с помощью которых можно создать схему инкапсуляции «точка-точка». Далее показаны концепции IP-туннелирования, где GRE - протокол инкапсуляции, а IP - транспортный протокол. Протокол передачи может является IP-протоколом (однако он может быть другим протоколом, например Decnet, IPX или Appletalk).

Структура изображенного туннельного пакета:

· IP является транспортным протоколом.

· GRE является протоколом инкапсуляции.

· IP является протоколом переноса.

Для наиболее полного понимания работы механизма отправки сообщений поддержки активности GRE, далее рассмотрим пример топологии с туннелем и конфигурации изображенной на рисунке 3.2. Физические интерфейсы маршрутизаторов Router A и Router B обозначены как S1 и S2, туннельные интерфейсы обозначены Tu0. Имеется магистральная IP-сеть между двумя конечными маршрутизаторами туннеля GRE. Это пример пакета поддержки активности, который отправлен из маршрутизатора Router A и назначен маршрутизатору Router B. Ответ на сообщение поддержки активности, который маршрутизатор Router B возвращает маршрутизатору Router A, уже находится во внутреннем IP-заголовке. Маршрутизатор Router B просто декапсулирует пакеты поддержки активности и отправляет их обратно на физический интерфейс (S2). Тот, в свою очередь, обрабатывает пакеты поддержки активности GRE подобно любым другим IP-пакетам данных GRE.



Топология сети

Структура пакета GRE keepalive

Ниже показаны выходные данные команд, используемых для конфигурации сообщений поддержки активности в туннелях GRE.

ESR1000# config

ESR1000 (config)# tunnel gre 1

ESR1000 (config-gre)# keepalive timeout 10

ESR1000 (config-gre)# keepalive retries 5

ESR1000 (config-gre)# keepalive enable

Синтаксис данной команды keepalive timeout 1-32767 секунд, по умолчания 10 секунд. Синтаксис данной команды keepalive retries 1-255 повторов, по умолчанию 5 повторов. Синтаксис данной команды keepalive enable активация данной механизма, по умолчанию выключен.

Если сообщения поддержки активности на конечной точке туннеля маршрутизатора Router A включены, маршрутизатор с интервалом заданным keepalive timeout создает внутренний IP-заголовок и заголовок GRE с нулевым типом протокола (PT) рисунок 3.3. Далее он передает этот пакет туннельному интерфейсу, после чего происходит инкапсуляция пакета с внешним IP-заголовком и заголовком GRE с PT, равным IP. Маршрутизатор Router A изменяет значение счетчика путем увеличения значения при приеме сообщений поддержки активности туннеля на единицу. Предположим, что способ для достижения другой стороны туннеля существует, а туннельный протокол по каким-то причинам не отключен, то пакет поступает на маршрутизатор Router B. Затем он сопоставляется с туннелем 0, декапсулируется и направляется по IP-адресу назначения, который является IP-адресом источника туннеля на маршрутизаторе Router A. Когда пакет поступает на маршрутизатор Router A, он декапсулируется, и проверка PT дает в результате 0. Это означает, что данный пакет является пакетом поддержки активности. Происходит сброс значения счетчика сообщений проверки активности на 0 и пакет отбрасывается. В случае если маршрутизатор Router B недоступен, маршрутизатор Router A продолжает создавать и отправлять пакеты поддержки активности, а также обычный трафик. Если сообщение поддержки активности не возвращается, линейный протокол туннеля остается включенным до тех пор, пока значение счетчика сообщений поддержки активности меньше, чем число периода. Если данное условие не соблюдено, то в следующий раз при попытке маршрутизатора Router A отправить пакет поддержки активности маршрутизатору Router B, линейный протокол отключается. Во включенном или выключенном состоянии туннель не передает и не обрабатывает какой-либо трафик данных. Однако он продолжает отправлять пакеты поддержки активности. При получении ответов сообщений поддержки активности, означающих доступность конечной точки туннеля, счетчик сообщений поддержки активности сбрасывается на 0, а линейный протокол в туннеле активируется.



1.5 Сетевая подсистема ядра Linux

Сетевая модель

Сетевая модель - это модель взаимодействия сетевых протоколов. А протоколы в свою очередь, это стандарты, которые определяют каким образом, будут обмениваться данными различные программы.

Эталонная сетевая модель OSI расшифровывается как Open System Interconnection. На русском языке это звучит следующим образом: Сетевая модель взаимодействия открытых систем (эталонная модель). Данную модель можно назвать стандартом. Поэтому этой модели придерживаются производители сетевых устройств, когда разрабатывают новые продукты.

Сетевая модель OSI состоит из 7 уровней, причем принято начинать отсчёт с нижнего.

Перечислим их:

· Прикладной уровень (application layer)

· Представительский уровень или уровень представления (presentation layer)

· Сеансовый уровень (session layer)

· Транспортный уровень (transport layer)

· Сетевой уровень (network layer)

· Канальный уровень (data link layer)

· Физический уровень (physical layer)



Модель OSI

Прикладной уровень

Прикладной уровень (уровень приложений; англ. application layer) - верхний уровень модели, позволяет обеспечить взаимодействие пользовательских приложений с сетью:

· позволяет приложениям использовать сетевые службы:

· позволяет организовать удалённый доступ к файлам и базам данных, пересылкам электронной почты;

· отвечает за передачу служебной информации;

· предоставляет приложениям информацию об ошибках;

· формирует запросы к уровню представления.

Протоколы прикладного уровня: RDP, HTTP, SMTP, SNMP, POP3, FTP, XMPP, OSCAR, Modbus, SIP, TELNET и другие.

Уровень представления

Представительский уровень (уровень представления; англ. presentation layer) обеспечивает преобразование протоколов и кодирование / декодирование данных. приложение запрашивает, полученные от прикладного уровня, ну уровне представления преобразуется в формат для передачи по сети и полученные из сетевого приложения данные преобразуется в формат. На этом уровне могут быть процессы сжатия / восстановления и шифрования / дешифрования, а также перенаправление запросов на другой сетевой ресурс, если они не могут быть обработаны на месте.

Уровень представления обычно представляет собой промежуточное преобразование протокола для информации из соседних уровней. Это позволяет устанавливать связь между приложениями на различных компьютерных системах прозрачно для приложений должным образом. Уровень представления обеспечивает форматирование и преобразование кода. Формат кода, используемого для обеспечения потока информации для обработки приложений, которые будут иметь смысл для него. При необходимости, этот слой может выполнять передачу данных из одного формата в другой.

Уровень представления приходится иметь дело не только с форматом и представления данных, он также участвует в структурах данных, которые используются программами. Таким образом, уровень 6 обеспечивает организацию данных при их доставке.

Протоколы уровня представления: AFP - Apple Filing Protocol, ICA - Independent Computing Architecture, LPP - Lightweight Presentation Protocol, NCP - NetWare Core Protocol, NDR - Network Data Representation, XDR - eXternal Data Representation, X.25 PAD - Packet Assembler/Disassembler Protocol.

Сеансовый уровень

Сеансовый уровень (англ. session layer) модели обеспечивает поддержание сеанса связи, позволяя приложениям взаимодействовать между собой длительное время. Уровень управляет созданием / завершением сеанса, обменом информацией, синхронизацией задач, определением права на передачу данных и поддержанием сеанса в периоды неактивности приложений.

Транспортный уровень

Транспортный уровень (англ. transport layer) модели предназначен для обеспечения надёжности передачи данных от отправителя к получателю. При этом уровень надёжности может изменятся в широких пределах. Существует множество классов протоколов транспортного уровня, начиная от протоколов, предоставляющих только основные транспортные функции (например, функции передачи данных без подтверждения приема), и заканчивая протоколами, которые гарантируют доставку в пункт назначения нескольких пакетов данных в надлежащей последовательности, мультиплексируют несколько потоков данных, обеспечивают механизм управления потоками данных и гарантируют достоверность принятых данных. Например, UDP ограничивается контролем целостности данных в рамках одной датаграммы, и не исключает возможности потери пакета целиком, или дублирования пакетов, нарушение порядка получения пакетов данных; TCP обеспечивает надёжную непрерывную передачу данных, исключающую потерю данных или нарушение порядка их поступления или дублирования, может перераспределять данные, разбивая большие порции данных на фрагменты и наоборот склеивая фрагменты в один пакет.

Сетевой уровень

Сетевой уровень (англ. network layer) модели предназначен для определения пути передачи данных. Отвечает за трансляцию логических адресов и имён в физические, определение кратчайших маршрутов, коммутацию и маршрутизацию, отслеживание неполадок и «заторов» в сети.

Протоколы сетевого уровня маршрутизируют данные от источника к получателю. Работающие на этом уровне устройства (маршрутизаторы) условно называют устройствами третьего уровня (по номеру уровня в модели OSI).

Канальный уровень

Канальный уровень (англ. data link layer) предназначен для обеспечения взаимодействия сетей на физическом уровне и контроля за ошибками, которые могут возникнуть. Полученные с физического уровня данные, представленные в битах, он упаковывает в кадры, проверяет их на целостность и, если нужно, исправляет ошибки (формирует повторный запрос поврежденного кадра) и отправляет на сетевой уровень. Канальный уровень может взаимодействовать с одним или несколькими физическими уровнями, контролируя и управляя этим взаимодействием.

Спецификация IEEE 802 разделяет этот уровень на два подуровня: MAC (англ. media access control) регулирует доступ к разделяемой физической среде, LLC (англ. logical link control) обеспечивает обслуживание сетевого уровня.

На этом уровне работают коммутаторы, мосты и другие устройства. Эти устройства используют адресацию второго уровня (по номеру уровня в модели OSI).

В программировании этот уровень представляет драйвер сетевой платы, в операционных системах имеется программный интерфейс взаимодействия канального и сетевого уровней между собой. Это не новый уровень, а просто реализация модели для конкретной ОС. Примеры таких интерфейсов: ODI, NDIS, UDI.

Физический уровень

Физический уровень (англ. physical layer) - нижний уровень модели, который определяет метод передачи данных, представленных в двоичном виде, от одного устройства (компьютера) к другому. Составлением таких методов занимаются разные организации, в том числе: Институт инженеров по электротехнике и электронике, Альянс электронной промышленности, Европейский институт телекоммуникационных стандартов и другие. Осуществляют передачу электрических или оптических сигналов в кабель или в радиоэфир и, соответственно, их приём и преобразование в биты данных в соответствии с методами кодирования цифровых сигналов.

На этом уровне также работают концентраторы, повторители сигнала и медиаконвертеры.

Функции физического уровня реализуются на всех устройствах, подключенных к сети. Со стороны компьютера функции физического уровня выполняются сетевым адаптером или последовательным портом. К физическому уровню относятся физические, электрические и механические интерфейсы между двумя системами. Физический уровень определяет такие виды сред передачи данных как оптоволокно, витая пара, коаксиальный кабель, спутниковый канал передач данных и т.п. Стандартными типами сетевых интерфейсов, относящимися к физическому уровню, являются: V.35, RS-232, RS-485, RJ-11, RJ-45, разъемы AUI и BNC.

1.6 Сетевая подсистема ядра

Сетевая подсистема ядра является более разветвлённее интерфейсов устройств Linux. Но, несмотря на обилие возможностей (например, если судить по числу обслуживающих сетевых утилит: ifconfig, ip, netstat, route… и до нескольких десятков иных) - сетевая подсистема Linux, с позиции разработчика ядра, логичнее и прозрачнее, чем, например, тот же интерфейс устройств. Сетевая подсистема Linux ориентирована в большей степени на обслуживание протоколов Ethernet на канальном уровне и TCP/IP на транспортном уровне, но эта модель расширяется с равным успехом и на другие типы протоколов, таким образом покрывая весь спектр возможностей. Сеть TCP/IP, как известно, весьма условно вписывается в 7-уровневую модель OSI взаимодействия открытых систем (она и разработана раньше модели OSI, и, естественно, они не соответствуют друг другу). В Linux сложилась такая терминология разделения на подуровни, что:

· всё, что относится к поддержке оборудования и канальному уровню - описывается как сетевые интерфейсы;

· протоколы сетевого уровня OSI (IP/IPv4/IPv6, IPX, ICMP, RIP, OSPF, ARP,…) - как сетевой уровень стека протоколов (или L2);

· всё, что выше (UDP, TCP, SCTP…) - как протоколы транспортного уровня (или L3);

· всё же то, что относится к выше лежащим уровням (сеансовый, представительский, прикладной) модели OSI (например: SSH, SIP, RTP,…) - никаким образом не проявляется в ядре, и относится уже только к области клиентских и серверных утилит пространства пользователя.

Сетевая реализация построена так, чтобы не зависеть от конкретики протоколов. Основной структурой данных описывающей сетевой интерфейс (устройство) является struct net_device, к ней мы вернёмся позже, описывая устройство [3].

А вот основной структурой обмениваемых данных (между сетевыми уровнями), на движении которой построена работа всех сетевых уровней - есть буферы сокетов (определения в <linux/skbuff.h>). Буфер сокетов состоит их двух частей: данные управления struct sk_buff, и данные пакета (указываемые в struct sk_buff указателями head и data). Буферы сокетов всегда увязываются в очереди (struct sk_queue_head) посредством своих двух первых полей next и prev. В листинге 3.1 предоставлены некоторые поля структуры.

Листинг 3.1 - Пример структуры sk_buf на языке Си

typedef unsigned char *sk_buff_data_t;

struct sk_buff {

struct sk_buff *next; /* These two members must be first. */

struct sk_buff *prev;

…

sk_buff_data_t transport_header;

sk_buff_data_t network_header;

sk_buff_data_t mac_header;

…

unsigned char *head,

*data;

…

};

Структура вложенности заголовков в точности соответствует структуре инкапсуляции сетевых протоколов внутри друг друга, это позволяет обрабатывающему слою получить доступ до информации, относящейся только к данному слою.

Пример структуры sk_buff

Как можно заметить, несколько структур sk_buff для данного соединения могут быть связаны вместе рисунок 3.4. Каждая из них идентифицирует структуру устройства (net_device), которому пакет посылается или от которого получен. Так как каждый пакет представлен в sk_buff, заголовки пакетов удобно определены набором указателей (th, iph и mac для Управления доступом к среде (заголовок Media Access Control или MAC). Поскольку структуры sk_buff являются центральными в организации данных сокета, для управления ими был создан ряд функций поддержки. Существуют функции для создания, разрушения, клонирования и управления очередностью sk_buff.

Буферы сокетов разработаны таким образом, чтобы связываться друг с другом для данного сокета и включать большой объем информации, в том числе ссылки на заголовки протоколов, временные метки (когда пакет был отправлен или получен) и соответствующее устройство.

1.7 Сетевые интерфейсы

Роль сетевого интерфейса в системе аналогична таковой для смонтированного блочного устройства. Блочное устройство регистрирует в ядре свои диски и методы и затем «передаёт» и «получает» блоки по запросу, означающему вызов его функции request. Аналогичным образом сетевой интерфейс должен зарегистрировать себя в определённых структурах данных ядра, чтобы быть вызванным, когда происходит обмен пакетами с внешним миром[5].

Есть несколько важных различий между смонтированными дисками и интерфейсами доставки пакеты. Начнём с того, что диск существует в виде специального файла в каталоге /dev, в то время как сетевой интерфейс не имеет такой точки входа. Нормальные операции с файлами (чтение, запись и так далее) не имеют смысла применительно к сетевым интерфейсам, так что невозможно применять к ним подход Unix «всё есть файл». Таким образом, сетевые интерфейсы существуют в их собственном пространстве имён и экспортируют другой набор операций.

Хотя вы можете возразить, что при использовании сокетов приложения используют системные вызовы read и write, эти вызовы на программное обеспечение объекта, который отличается от интерфейса. На одном физическом интерфейсе может быть мультиплексировано несколько сотен сокетов[4].

Но самое важное различие между ними в том, что блочные драйверы работают только отвечая на запросы из ядра, тогда как сетевые драйверы получают пакеты асинхронно извне. Таким образом, если блочный драйвер запрашивается, чтобы послать буфер в ядро, сетевое устройство просит поместить входящие пакеты в ядро. Интерфейс ядра для сетевых драйверов разработан для этого другого режима управления.

Сетевые драйверы также должны быть готовы поддержать ряд административных задач, таких как настройка адресов, изменение параметров передачи и поддержание статистики трафика и ошибок. API для сетевых драйверов отражает эту необходимость и, таким образом, выглядит несколько отличающимся от интерфейсов, которые мы видели до сих пор.

Сетевая подсистема ядра Linux разработана так, чтобы быть полностью независимой от протокола. Это относится как к сетевым протоколам (Интернет-протокол [IP] по сравнению с IPX и другими протоколами) и аппаратным протоколам (Ethernet по сравнению с Token Ring и другими). Взаимодействие между сетевым драйвером и ядром имеет дело должным образом с одним сетевым пакетом за раз; это позволяет проблемам протокола быть аккуратно скрытыми от драйвера и физической передаче быть скрытой от протокола[7].

1.8 Подсистема таймеров ядра linux

Природа времени (в Linux)

В ядре Linux время измеряется с помощью глобальной переменной с именем jiffies, которая определяет количество временных тиков (тактов), прошедших после загрузки системы. Способ, каким подсчитываются тики, зависит на самом низком уровне от конкретной аппаратной платформы, на которой вы работаете, однако, обычно увеличение значения происходит с помощью прерываний. Частота тиков (младший значащий бит в jiffies) конфигурируема, но в последнем ядре 2.6 для архитектуры x86 продолжительность тика равна 4 мсек (250Hz). Глобальная переменная jiffies используется в ядре для различных целей, одной из которых является хранение абсолютного текущего времени, которое нужно для вычисления значения тайм-аута для таймера (позже вы увидите примеры этого) [1].

В последних ядрах 2.6 имеются несколько различных схем, используемых для таймеров. Самой простой и наименее точной из всех схем таймеров (хотя и пригодной в большинстве случаев) является интерфейс API для таймеров (timer API). Этот API позволяет создавать таймеры, которые используют переменную jiffies (с минимальным тайм-аутом в 4 мсек). Также имеется API для таймеров высокого разрешения, который позволяет создавать таймеры, время в которых определяется в наносекундах. В зависимости от вашего процессора и скорости, с которой он работает, ваши возможности могут варьироваться, но API позволяет планировать тайм-ауты с интервалом меньшим, чем продолжительность тиков jiffies.

Стандартные таймеры

Стандартный API таймеров является частью ядра Linux в течение довольно продолжительного времени (начиная с самых ранних версий ядра Linux). Хотя этот интерфейс предлагает меньшую точность, чем таймеры высокого разрешения, он идеально подходит для определения тайм-аута в традиционных драйверах и компенсирует ошибки, возникающие при работе с физическими устройствами. Во многих случаях эти тайм-ауты никогда не возникают, а лишь устанавливаются, а затем отменяются [1].

Простые таймеры ядра реализованы с использованием алгоритма timer wheel («кольцо таймеров»). Идея впервые была предложена в 1997 году Финном Арне Генгстедом (Finn Arne Gangstad). В нем игнорируется проблема управления большим количеством таймеров, но для типичного случая - управление разумным количеством таймеров - он подходит. (Первоначально реализация таймеров представляла собой двусвязный список, упорядоченный в порядке истечения срока действия таймеров. Хотя этот подход концептуально прост, но он не масштабируем.) В алгоритме timer wheel используется набор слотов, где каждый слот представляет собой некоторый отсчет времени, по достижении которого в будущем истекает время таймера. Слоты определяются в соответствие с логарифмической шкалой времени, причем для этого используется пять слотов. С помощью переменной jiffies определяется количество групп, которые представляют собой время достижения срабатывания таймера в будущем (где каждая группа представляет собой список таймеров). Добавление таймера осуществляется с помощью операций со списками, сложность которых равна O (1) для случая, когда количество таймеров, время которых истекает, равно O (N). Истечение времен таймеров происходит в виде каскадных операций, когда при уменьшении срока действия таймеров они изымаются из слотов с высокой гранулярностью и переносятся в слоты с низкой гранулярностью. Теперь давайте посмотрим, как API используется для реализации этих таймеров.

1.9 Таймеры ядра

Понятие таймера существенно шире и сложнее в реализации, чем просто выжидание некоторого интервала времени. Таймер (экземпляров которых может одновременно существовать достаточно много) должен асинхронно возбудить некоторое предписанное ему действие в указанный момент времени в будущем.

Ядро предоставляет драйверам API таймера: ряд функций для декларации, регистрации и удаления таймеров ядра в листинге 3.2.

Листинг 3.2 - Пример структуры timer_list на языке Си

#include <linux/timer.h>

struct timer_list {

struct list_head entry;

unsigned long expires;

void (*function) (unsigned long);

unsigned long data;

…

};

API ядра для работы с таймером:

· void init_timer (struct timer_list *timer);

· struct timer_list TIMER_INITIALIZER (_function, _expires, _data);

· void add_timer (struct timer_list *timer);

· void mod_timer (struct timer_list *timer, unsigned long expires);

· int del_timer (struct timer_list *timer);

· expires - значение jiffies, наступления которого таймер ожидает для срабатывания (абсолютное время);

· при срабатывании функция function() вызывается с data в качестве аргумента;

· чаще всего data - это преобразованный указатель на структуру;

Функция таймера в ядре выполняется в контексте прерывания (Не в контексте процесса! А конкретнее: в контексте обработчика прерывания системного таймера.), что накладывает на неё дополнительные ограничения:

Не разрешён доступ к пользовательскому пространству. Из-за отсутствия контекста процесса, нет пути к пользовательскому пространству, связанному с любым определённым процессом.

Указатель current не имеет смысла и не может быть использован, так как соответствующий код не имеет связи с процессом, который был прерван.

Не может быть выполнен переход в блокированное состояние и переключение контекста. Код в контексте прерывания не может вызвать schedule() или какую-то из формwait_event(), и не может вызвать любые другие функции, которые могли бы перевести его в пассивное состояние, семафоры и подобные примитивы синхронизации также не должны быть использованы, поскольку они могут переключать выполнение в пассивное состояние.

Код ядра может понять, работает ли он в контексте прерывания, используя макрос: in_interrupt().

Таймеры высокого разрешения

Таймеры высокого разрешения появляются с ядра 2.6.16, структуры представления времени для них определяются в файлах <linux/ktime.h>. Поддержка осуществляется только в тех архитектурах, где есть поддержка аппаратных таймеров высокого разрешения. Определяется новый временной тип данных ktime_t - временной интервал в наносекундном выражении, представление его сильно разнится от архитектуры. Здесь же определяются множество функций установки значений и преобразований представления времени (многие из них определены как макросы, но здесь записаны как прототипы) [2]:

· ktime_t ktime_set (const long secs, const unsigned long nsecs);

· ktime_t timeval_to_ktime (struct timeval tv);

· struct timeval ktime_to_timeval (ktime_t kt);

· ktime_t timespec_to_ktime (struct timespec ts);

· struct timespec ktime_to_timespec (ktime_t kt);

Сами операции с таймерами высокого разрешения определяются в <linux/hrtimer.h>, это уже очень напоминает модель таймеров реального времени, вводимую для пространства пользователя стандартом POSIX:

Листинг 3.3 - Пример структуры hrtimer на языке Си

struct hrtimer {

…

ktime_t _expires;

enum hrtimer_restart (*function) (struct hrtimer *);

…

}

Единственным определяемым пользователем полем этой структуры является функция реакции function, здесь обращает на себя внимание прототип этой функции, пример в листинге 3.4:

Листинг 3.4 - Пример структуры hrtimer_restart и функций на языке Си

enum hrtimer_restart {

HRTIMER_NORESTART,

HRTIMER_RESTART,

};

void hrtimer_init (struct hrtimer *timer, clockid_t which_clock, enum hrtimer_mode mode);

int hrtimer_start (struct hrtimer *timer, ktime_t tim, const enum hrtimer_mode mode);

extern int hrtimer_cancel (struct hrtimer *timer);

…

enum hrtimer_mode {

HRTIMER_MODE_ABS = 0x0, /* Time value is absolute */

HRTIMER_MODE_REL = 0x1, /* Time value is relative to now */

…

};

Параметр which_clock типа clockid_t, это вещь из области стандартов POSIX, то, что называется стандартом временной базис (тип задатчика времени): какую шкалу времени использовать, из общего числа определённых в <linux/time.h> (часть из них из POSIX, а другие расширяют число определений) пример в листинге 3.5.

Листинг 3.5 - Пример шкал времени

#define CLOCK_REALTIME 0

#define CLOCK_MONOTONIC 1

#define CLOCK_PROCESS_CPUTIME_ID 2

#define CLOCK_THREAD_CPUTIME_ID 3

#define CLOCK_MONOTONIC_RAW 4

#define CLOCK_REALTIME_COARSE 5

#define CLOCK_MONOTONIC_COARSE 6

Относительно временных базисов в Linux известно следующее:

· CLOCK_REALTIME - системные часы, со всеми их плюсами и минусами. Могут быть переведены вперёд или назад, в этой шкале могут попадаться «вставные секунды», предназначенные для корректировки неточностей представления периода системного тика. Это наиболее используемая в таймерах шкала времени.

· CLOCK_MONOTONIC - подобно CLOCK_REALTIME, но отличается тем, что, представляет собой постоянно увеличивающийся счётчик, в связи с чем, естественно, не могут быть изменены при переводе времени. Обычно это счётчик от загрузки системы.

· CLOCK_PROCESS_CPUTIME_ID - возвращает время затрачиваемое процессором относительно пользовательского процесса, время затраченное процессором на работу только с данным приложением в независимости от других задач системы. Естественно, что это базис для пользовательского адресного пространства.

· CLOCK_THREAD_CPUTIME_ID - похоже на CLOCK_PROCESS_CPUTIME_ID, но только отсчитывается время, затрачиваемое на один текущий поток.

· CLOCK_MONOTONIC_RAW - то же что и CLOCK_MONOTONIC, но в отличии от первого не подвержен изменению через сетевой протокол точного времени NTP.

Последние два базиса CLOCK_REALTIME_COARSE и CLOCK_MONOTONIC_COARSE добавлены недавно (2009 год), авторами утверждается, что они могут обеспечить гранулярность шкалы мельче, чем предыдущие базисы. Работу с различными базисами времени обеспечивают в пространстве пользователя малоизвестные API вида clock_*() (clock_gettext(), clock_nanosleep(), clock_settime(),…) [1].

1.10 Системный вызов ioctl

Большинству драйверов в дополнение к возможности чтения и записи устройства необходима возможность управления аппаратурой разными способами через драйвер устройства. Большинство устройств может выполнять операции за рамками простой передачи данных; пользовательское пространство часто должно иметь возможность запросить, например, блокировку устройством своих шторок, извлечение носителя информации, сообщить об ошибке информации, изменение скорости передачи, либо самоликвидацию. Эти операции обычно поддерживаются через метод ioctl (команда управления вводом-выводом), который реализует системный вызов с тем же названием.

В пользовательском пространстве системный вызов ioctl имеет следующий прототип int ioctl (int fd, unsigned long cmd,…);

Прототип выделяется в списке системных вызовов Unix из-за точек, которые обычно отмечают функцию с переменным числом аргументов. Однако, в реальной системе системный вызов в действительности не может иметь переменное количество аргументов. Системные вызовы должны иметь чётко определённые прототипы, потому что пользовательские программы могут получать к ним доступ только через аппаратные «ворота». Таким образом, точки в прототипе представляют не переменное количество аргументов, а один дополнительный аргумент, традиционно определяемый как char *argp. Точки просто не допускают проверку типа во время компиляции. Фактический характер третьего аргумента зависит от используемой команды управления (второй аргумент). Некоторые команды не требуют никаких аргументов, некоторым требуется целые значения, а некоторые используют указатель на другие данные. Использование указателя является способом передачи в вызов ioctl произвольных данных; устройство затем сможет обменяться любым количеством данных с пользовательским пространством [6].

Неструктурированный характер вызова ioctl вызвал его падение в немилость среди разработчиков ядра. Каждая команда ioctl является, по сути, отдельным, обычно недокументированным системным вызовом, и нет никакой возможности для проверки этих вызовов каким-либо всеобъемлющим образом. Кроме того, трудно сделать, чтобы неструктурированные аргументы ioctl работали одинаково на всех системах; учитывая, например, 64-х разрядные системы с пользовательским процессом, запущенном в 32-х разрядном режиме. В результате, существует сильное давление, чтобы осуществлять разные операции контроля только какими-либо другими способами. Возможные альтернативы включают вложения команд в поток данных (мы обсудим этот подход далее в этой главе) или использование виртуальных файловых систем, или sysfs, или специфичные драйверные файловые системы. (Мы будем рассматривать sysfs в Главе 14.) Тем не менее, остается фактом, что ioctl часто является самым простым и наиболее прямым выбором для относящихся к устройству операций. Метод драйвера ioctl имеет прототип, который несколько отличается от версии пользовательского пространства: int (*ioctl) (struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg);

Указатели inode и filp являются значениями, соответствующими файловому дескриптору fd, передаваемого приложением, и являются теми же параметрами, передаваемыми в метод open. Аргумент cmd передаётся от пользователя без изменения, а необязательный аргумент arg передаётся в виде unsigned long, независимо от того, был ли он задан пользователем как целое или указатель. Если вызывающая программа не передаёт третий аргумент, значение arg, полученное операцией драйвера, не определено. Из-за отключённой проверки типа дополнительного аргумента компилятор не сможет предупредить вас, если в ioctl передаётся неправильный аргумент, и любая связанная с этим ошибка будет труднообнаруживаемой.

Как можно было себе представить, большинство реализаций ioctl содержат большой переключатель, который выбирает правильное поведение в зависимости от аргумента cmd. Разные команды имеют различные числовые значения, которые для упрощения кодирования обычно задаются символическими именами. Символическое имя присваивается через определение препроцессора. Заказные драйверы обычно объявляют такие символы в своих заголовочных файлах. Чтобы иметь доступ к этим символам, пользовательские программы должны, конечно, подключить этот заголовочный файл.

Выбор команд ioctl

Прежде чем писать код для ioctl, необходимо выбрать цифры, которые соответствуют командам. Инстинктивно многие программисты выбирают небольшие числа, начиная с 0 или 1 и далее увеличивая значения. Есть, однако, веские причины не делать это таким образом. Номера команд ioctl должны быть уникальными в системе в целях предотвращения ошибок, вызванных правильной командой для неправильного устройства. Такое несоответствие не является маловероятным и программа могла бы обмануть сама себя, пытаясь изменить скорость передачи данных входного потока, не связанного с последовательным портом, такого, как FIFO или аудио устройства. Если каждый номер ioctl является уникальным, программа получает ошибку EINVAL раньше, чем успевает сделать что-то непреднамеренное.

Чтобы помочь программистам создавать уникальные коды команд ioctl, эти коды были разделены на несколько битовых полей. Первые версии Linux использовали 16-ти разрядные числа: верхние восемь «магических» чисел связывались с устройством, а нижние восемь были последовательными номерами, уникальными для данного устройства. Это произошло потому, что Линус был «невежественен» (его собственные слова); лучшее разделение битовых полей было придумано лишь позднее. К сожалению, довольно много драйверов всё ещё используют старое соглашение. Они вынуждены: изменение кодов команд нарушило бы работу многих бинарных программ и это не то, что разработчики ядра готовы сделать.

Для выбора номеров ioctl для вашего драйвера в соответствии с соглашением ядра Linux вы должны сначала проверить include/asm/ioctl.h и Documentation/ioctl-number.txt. Этот заголовок определяет битовые поля для использования: тип (системный номер), порядковый номер, направление передачи и размер аргумента. Файл ioctl-number.txt перечисляет системные номера, используемые в ядре (* Однако, поддержка этого файла была несколько ограниченной в последнее время.), поэтому вы сможете выбрать свой собственный номер в системе и избежать дублирования. В этом текстовом файле также перечислены причины, по которым должно быть использовано данное соглашение.

Утверждённый способ определения номеров команд ioctl использует четыре битовых области, которые имеют следующие значения. Новые символы, введённые в этом списке, определяются в <linux/ioctl.h>.

· Type Системный номер. Просто выберите одно число (после консультации с ioctl-number.txt) и используйте его в драйвере. Это поле шириной восемь бит (_IOC_TYPEBITS).

· Number Порядковый (последовательный) номер. Это поле шириной восемь бит (_IOC_NRBITS).

· Direction Направление передачи данных, если данная команда предполагает передачу данных. Возможными значениями являются _IOC_NONE (без передачи данных), _IOC_READ, _IOC_WRITE и _IOC_READ | _IOC_WRITE (данные передаются в обоих направлениях). Передача данных с точки зрения приложения; _IOC_READ означает чтение из устройства, так что драйвер должен писать в пространство пользователя. Обратите внимание, что поле является битовой маской, _IOC_READ и _IOC_WRITE могут быть извлечены при помощи логической операции.

· Size Размер предполагаемых пользовательских данных. Ширина этого поля зависит от архитектуры, но, как правило, 13 или 14 бит. Вы можете найти это значение для вашей конкретной архитектуры в макросе _IOC_SIZEBITS. Не обязательно использовать поле size - ядро не проверяет его - но это хорошая идея. Правильное использование этого поля может помочь обнаружить ошибки программирования в пользовательском пространстве и позволит реализовать обратную совместимость, если вам когда-нибудь понадобится изменить размер соответствующего элемента данных. Однако, если вам требуются более крупные структуры данных, вы можете просто проигнорировать поле size. Как используется это поле, мы рассмотрим в ближайшее время.

Заголовочный файл <asm/ioctl.h>, который подключается <linux/ioctl.h>, определяет макрос, который поможет задать номера команд следующим образом: _IO (type, nr) (для команды, которая не имеет аргумента), _IOR (type, nr, datatype) (для чтения данных из драйвера), _IOW (type, nr, datatype) (для записи данных) и _IOWR (type, nr, datatype) (для двунаправленной передачи). Поля type и fields, передаваемые в качестве аргументов, и поле size получаются применением sizeof к аргументу datatype.

Заголовок определяет также макросы, которые могут быть использованы в вашем драйвере для декодирования номеров: _IOC_DIR(nr), _IOC_TYPE(nr), _IOC_TYPE(nr), _IOC_NR(nr) и _IOC_SIZE(nr). Мы не будем углубляться более подробно в эти макросы, так как заголовочный файл ясен, а ниже в этом разделе показан код примера.

Вот как определяются некоторые команды ioctl. В частности, эти команды устанавливают и получают настраиваемые параметры драйвера пример команд в листинге 3.6.

Листинг 3.6 - Пример команд и параметров драйвера

/* Используем 'k' как системный номер */

#define SCULL_IOC_MAGIC 'k'

/* Пожалуйста, используйте в вашем коде другое 8-ми битовое число */

#define SCULL_IOCRESET _IO (SCULL_IOC_MAGIC, 0)

/*

* S означает «Set» («Установить») через ptr,

* T означает «Tell» («Сообщить») прямо с помощью значения аргумента

* G означает «Get» («Получить»): ответ устанавливается через указатель

* Q означает «Query» («Запрос»): ответом является возвращаемое значение

* X означает «eXchange» («Обменять»): переключать G и S автоматически

* H означает «sHift» («Переключить»): переключать T и Q автоматически

*/

#define SCULL_IOCSQUANTUM _IOW (SCULL_IOC_MAGIC, 1, int)

#define SCULL_IOCSQSET _IOW (SCULL_IOC_MAGIC, 2, int)

#define SCULL_IOCTQUANTUM _IO (SCULL_IOC_MAGIC, 3)

#define SCULL_IOCTQSET _IO (SCULL_IOC_MAGIC, 4)

#define SCULL_IOCGQUANTUM _IOR (SCULL_IOC_MAGIC, 5, int)

#define SCULL_IOCGQSET _IOR (SCULL_IOC_MAGIC, 6, int)

#define SCULL_IOCQQUANTUM _IO (SCULL_IOC_MAGIC, 7)

#define SCULL_IOCQQSET _IO (SCULL_IOC_MAGIC, 8)

#define SCULL_IOCXQUANTUM _IOWR (SCULL_IOC_MAGIC, 9, int)

#define SCULL_IOCXQSET _IOWR (SCULL_IOC_MAGIC, 10, int)

#define SCULL_IOCHQUANTUM _IO (SCULL_IOC_MAGIC, 11)

#define SCULL_IOCHQSET _IO (SCULL_IOC_MAGIC, 12)

#define SCULL_IOC_MAXNR 14

Точный порядковый номер команды не имеет определённого значения. Он используется только, чтобы отличить команды друг от друга. На самом деле, вы можете даже использовать тот же порядковый номер для команды чтения и записи, поскольку фактический номер ioctl отличается в битах «направления», но нет никакой причины, почему бы вы не захотели сделать это. Мы решили не использовать порядковые номера команд нигде, кроме декларации, поэтому мы не назначили им символические значения. Вот почему в данном ранее определении появляются явные номера. Приведённый пример показывает один из способов использования номеров команд, но вы вольны делать это по-другому [6].

За исключением небольшого числа предопределённых команд значение аргумента cmd в ioctl в настоящее время не используется ядром и весьма маловероятно, что это будет в будущем. Таким образом, можно, если вы почувствовали себя ленивым, избегать сложных показанных ранее деклараций и явно декларировать набор скалярных чисел. С другой стороны, если бы вы сделали это, вы бы вряд ли выиграли от использования битовых полей и вы бы столкнулись с трудностями, если бы когда-то представили свой код для включения в основное ядро. Заголовок <linux/kd.h> является примером этого старомодного подхода, использующего для определения команд ioctl 16-ти разрядные скалярные значения. Этот исходный файл полагался на скалярные значения, потому что он использовал конвенцию того времени, а не из-за лени. Изменение его сейчас вызвало бы неуместную несовместимость.

...