Реализация ioctl, как правило, использует команду switch, основанную на номере команды. Но что должно быть в варианте default, когда номер команды не совпадает с допустимыми операциями? Вопрос спорный. Некоторые функции ядра возвращают - EINVAL («Invalid argument», «Недопустимый аргумент»), что имеет смысл, поскольку этот командный аргумент действительно не является допустимым. Стандарт POSIX, однако, утверждает, что если была выдана неуместная команда ioctl, должно быть возвращено - ENOTTY. Данный код ошибки интерпретируется библиотекой Си как «несоответствующая команда ioctl для устройства», которая является обычно именно тем, что должен услышать программист. Хотя по-прежнему в ответ на недействительную команду ioctl очень распространено возвращение - EINVAL [6].



2. Разработка механизма отправки сообщений активности

Данный механизм разрабатывался на предприятие ELTEX для сервисных маршрутизаторов ESR100/200/1000/1200. Для начала я разобрался с подсистемой ядра таймеры. Была написана функция коллбек для вызова ее по истечению заданного времени static void gre_keepalive_timer_callback (unsigned long data).

Данная функция отвечает за сборку пакета и его постановку в очередь на отправку. Так же функция следит за тем что были ли получены ответы от другой стороны туннеля. Таймер инициализируется в функции static int ipgre_tunnel_init (struct net_device *dev).

и если переменная timeout больше 0, то будет произведена инициализация таймера следующими вызовами функции представленными в листинге 4.1.

Листинг 4.1 - инициализация таймера на языке Си

if (tunnel->parms.param_gre_keepalive.timeout) {

setup_timer (&tunnel->timer_gre.timer, gre_keepalive_timer_callback,

(unsigned long) tunnel);

tunnel->timer_gre.timer.expires = jiffies +

msecs_to_jiffies (tunnel->parms.param_gre_keepalive.timeout);

add_timer (&tunnel->timer_gre.timer);

tunnel->timer_gre.timestamp = jiffies;

}

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

Далее устанавливается первый таймаут после которого будет вызвана коллбек функция. Далее вызов add_timer добавляет таймер в очередь таймеров. И последняя команда требуется для того что бы запомни когда был отправлен последний пакет. Изменение таймера происходит при получение вызова IOCTL с командой SIOCCHGTUNNEL и если переменная timeout больше 0 и не равна предыдущему значению таймаута, то вызывалась функции удаления таймера и заново происходит его инициализация представлены в листинге 4.2:

Листинг 4.2 - изменение таймаута таймера на языке Си

del_timer_sync (&tunnel->timer_gre.timer);

setup_timer (&tunnel->timer_gre.timer, gre_keepalive_timer_callback, (unsigned long) tunnel);

tunnel->timer_gre.timer.expires = jiffies +

msecs_to_jiffies (p.param_gre_keepalive.timeout);

add_timer (&tunnel->timer_gre.timer);

tunnel->timer_gre.timestamp = jiffies;

Вызов del_timer_sync нужен для того что бы не возникли исключения в ситуации когда функция реакиции выполняется на одном процессоре, а удаление на другом. Далее все повторяется как при инициализации. Для взаимодействия между пользовательским пространства и пространством ядра была написана структура в файле uapi/linux/if_tunnel.h, показанная в листинге 4.3.

struct gre_keepalive {

int timeout;

int retries;

};

Листинг 4.3 - Пример полей являющихся общими для пользователь и пространства ядра на языке Си

Данная структура встроена в структуру приведенной на листинге 4.4.

Листинг 4.4 - структура конфигурирования туннеля на языке Си

struct ip_tunnel_parm {

char name[IFNAMSIZ];

int link;

__be16 i_flags;

__be16 o_flags;

__be32 i_key;

__be32 o_key;

struct iphdr iph;

struct gre_keepalive param_gre_keepalive;

};

Данная структура является уникальной для нескольких видов туннелей, через данную структуру происходит конфигурирование туннеля посредствам вызова IOCTL.

Конфигурирование происходит по средствам утилиты iproute2, она получает строку конфигурирования, и отправляет переменные по средствам IOCTL, для модуля ядра.

Теперь рассмотрим сборку пакета для отправки другой стороне туннеля. Для отправки нужно выделить память и заполнить структуру sk_buff, для работы механизма нужно положить внутрь пакета заголовки IP и GRE. В IP заголовке должны быть заполнены поля saddr и daddr таким образом, чтобы при декапсуляции обработки пакета должен быть от маршрутизирован обратно источнику. В заголовке GRE поле protocol должно быть равно 0, тем самым при получение данного пакета с типом 0 будет понятно что этот пакет для механизма keepalive.

Пакет начинает собираться в функции представленной в листинге 4.5.

Листинг 4.5 - сборка и разметка полей структуры sk_buff на языке Си

static void send_gre_packet (__be32 saddr, __be32 daddr,

struct tnl_ptk_info *tpi, struct net_device *dev)

{

struct iphdr *iph;

struct gre_base_hdr *greh;

struct sk_buff *skb;

int gre_len;

int hlen = LL_RESERVED_SPACE(dev);

int tlen = dev->needed_tailroom;

gre_len = ip_gre_calc_hlen (tpi->flags);

skb = alloc_skb (2 * (sizeof (struct iphdr) + gre_len) + hlen + tlen, GFP_ATOMIC);

if (skb == NULL)

return;

skb_reserve (skb, hlen);

skb_reset_network_header(skb);

skb->dev = dev;

skb->protocol = htons (ETH_P_IP);

ph = (struct iphdr *) skb_put (skb, sizeof (struct iphdr));

greh = (struct gre_base_hdr *) skb_put (skb, gre_len);

build_gre_header (greh, tpi, 0, gre_len);

build_ip_header (iph, daddr, saddr);

iph->tot_len = (sizeof (struct iphdr) + gre_len);

iph->check = ip_fast_csum((char *) iph, iph->ihl);

ipgre_xmit (skb, skb->dev);

}

Переменные hlen и tlen нужны для корректного выделения памяти, так же нужно подсчитать длину GRE заголовка, т.к. он переменной длины. Подсчет длинны происходит в функции:

Каждое дополнительное поле в заголовке GRE увеличивает его длину на 4 байта.

Далее функция alloc_skb выделяет память для структуры, плюс для 4 заголовков для работы механизма. Функция skb_reserve резервирует область памяти для дальнейшей обработки пакета ядром. Функция skb_reset_network_header размечает начало внешнего IP заголовка, это нужно для того что ядро само заполнит внешний заголовок пакета. Далее указывается структура указывающая на интерфейс с которого будет отправлен пакет skb->dev = dev, затем указывается тип пакета skb->protocol = htons (ETH_P_IP). По средствам функции skb_put происходит разметка для внутренних заголовков. GRE заголовок заполняется в функции build_gre_header приведенной в листинге 4.6.

Листинг 4.6 - Вычисление длинны GRE заголовка и сборка GRE заголовка на языке Си

static int ip_gre_calc_hlen (__be16 o_flags)

{

int addend = 4;

if (o_flags&TUNNEL_CSUM)

addend += 4;

if (o_flags&TUNNEL_KEY)

addend += 4;

if (o_flags&TUNNEL_SEQ)

addend += 4;

return addend;

}

static void build_gre_header (struct gre_base_hdr *greh,

struct tnl_ptk_info *tpi, __be16 proto,

int gre_len)

{

greh->flags = tnl_flags_to_gre_flags (tpi->flags);

greh->protocol = proto;

if (tpi->flags&(TUNNEL_KEY|TUNNEL_CSUM|TUNNEL_SEQ)) {

__be32 *ptr = (__be32 *) (((u8 *) greh) + gre_len - 4);

if (tpi->flags&TUNNEL_SEQ) {

*ptr = tpi->seq;

ptr -;

}

if (tpi->flags&TUNNEL_KEY) {

*ptr = tpi->key;

ptr -;

}

if (tpi->flags&TUNNEL_CSUM) {

*(__sum16 *) ptr = 0;

*(__sum16 *) ptr = ip_compute_csum((unsigned char *) greh, gre_len);

}

}

}

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

IP заголовок собирается в функции build_ip_header представленной в листинге 4.7.

Листинг 4.7 - сборка IP заголовка на языке Си

static void build_ip_header (struct iphdr *iph, __be32 saddr, __be32 daddr)

{

iph->ihl = 5;

iph->version = 4;

iph->tos = 0;

iph->id = 100;

iph->frag_off = 0;

iph->ttl = 255;

iph->protocol = IPPROTO_GRE;

iph->check = 0;

iph->saddr = saddr;

iph->daddr = daddr;

}

Здесь происходит инициализация полей и установка ip адресов для того что бы пакет мог вернутся обратно.

После того как заголовки сформированы что бы поставить пакет в очередь нужно вызвать вызов skb_queue_xmit, но в данном случае использовать данный вызов не возможно, т.к. после смены состояния интерфейса на не активное, нужно продолжать отправлять пакеты, но данный вызов следит что бы интерфейс был активен. Что бы отправить пакет используется вызов ipgre_xmit. После того как пакет поставлен в очередь на отправку, происходит проверка на то что сколько уже было отправлено пакетов после того как пришел последний ответ. Если отправлено пакетов больше чем значение переменной retries, то будет произведена смена состояния интерфейса. И изменение параметра таймаут для следующего вызова колбек функции.

Так же пришлось изменить модуль ядра gre.c. В нем при получение пакета происходит его обработка и для дальнейшей обработки требовалось минимум 12 байт информации, но при работе механизма минимальный объем пакета может быть 4 байта - это размер GRE заголовка без дополнительных полей. Поэтому была внесена правка листинг 4.8.

Листинг 4.8 - проверка объема данных в пакете на языке Си

if (! pskb_may_pull (skb, 4))

goto drop;

Данный вызов сравнивает объем данных в пакете и объемом указанным параметром в функцию.

В модуль if_tunnel.c были внесены правки, связанные с конфигурирование модуля ip_gre.c так как с начало IOCTL вызов обрабатывается этим модулем, а потом уже вызывается функция для конфигурирования нужного туннеля, для того что бы можно было настроить механизм keepalive были добавлены строки листинг 4.9.

Листинг 4.9 - прием переменных конфигурирования на языке Си

t->parms.param_gre_keepalive.timeout = p->param_gre_keepalive.timeout;

t->parms.param_gre_keepalive.retries = p->param_gre_keepalive.retries;

здесь происходит обработка данных пришедших из пользовательского пространства.

Теперь рассмотрим как происходит конфигурирование в командной строке CLI. Командная оболочка основана на clish, для конфигурирования устройства в проекте ESR используется наследование, но большая часть проекта написана на Си, а в этом языке как всем известно нету рефликсии, да в нашем проекте она реализована!!! Рефлексия позволяет описать объект конфиги формально и использовать для сериализации, десериализации, работы с конфигой через IPC методы реализованные в едином стиле и не писать массу кода для каждой новой опции в конфигурации. За экономию приходится платить, это и не слишком прозрачный код и ограничения, накладываемые теми самыми методами. Так как они одни для всех, то нагородить чего-то особенного не получится, приходится довольствоваться встроенными сущностями. Для реализации единых методов был введен базовый тип: ESRobject_t, т.е. все объекты конфигураций наследуются от него. Описание объекта конфигурации, ESRobject_fields_MUST_BE_FIRST это макрос, скрывающий под собой объявление обязательных полей, именно их состав и порядок обеспечивает единообразный интерфейс и подобие механизма наследования от ESRobject_t.

Он выглядит так листинг 4.10.

Листинг 4.10 - Пример макроса объявления структуры на языке Си

#define ESRobject_fields_MUST_BE_FIRST \

ESRobject_type_t type ESR_OBJECT_PACKED; \

ESRbool_t is_active;

Таким образом у базового класса и каждого наследника есть два обязательных поля:

· is_active - признак активности объекта.

· type - глобальный тип объекта, любой объект, описываемый рефлексией должен иметь свой уникальный тип. Для каждого объекта должен быть описан enum с перечислением атрибутов и вложенных объектов, были добавлены переменные для активации, задания таймаута и количества повторов листинг 4.11.

Листинг 4.11 - Пример полей в рефликсии для конфигурирования механизма на языке Си

ESRconfig_tunnels_gre_ATTR_keepalive_timeout,

ESRconfig_tunnels_gre_ATTR_keepalive_retries,

ESRconfig_tunnels_gre_ATTR_keepalive_enable,

ESRconfig_tunnels_gre_ATTR_LAST = ESRconfig_tunnels_gre_ATTR_keepalive_enable,

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

Листинг 4.12 - Пример инициализации структур на языке Си

static void tunnels_gre_ref_init(void)

{

ESRconfig_reflection_init (ref, tunnels_gre, MAP);

ESRconfig_reflection_FOREACH_ATTR (tunnels_gre)

{

ESRobject_reflection_attribute_t * attr = &ref.attr [attr_idx];

ESRobject_reflection_SWITCH_BY_ATTR_ID(ref)

{

…

CASE_WITH_CHECK (keepalive_timeout, keepalive-timeout, INTEGER);

CASE_WITH_CHECK (keepalive_retries, keepalive-retries, INTEGER);

CASE (keepalive_enable, keepalive-enable, BOOL);

…

}

}

}

Т.е рефлексия - это своего рода разметка объекта, тип поля, его имя, смещение относительно начала объекта, размер и метод верификации для операций IPC (ATTR_SET и тд).

Вызов макроса ESRconfig_reflection_init происходит со следующими параметрами:

· NONE сигнализирует о том, что наш объект не является каким-либо контейнером, т.е. не содержит никаких подобъектов (возможны MAP, LIST, ARRAY, NONE).

· interfaces_vti это часть имени нашего объекта, используется в макросе.

· ref это экземпляр рефлексии для нашего объекта.

· Макросы CASE и CASE_WITH_CHECK отвечают за разметку типа переменной, второй макрос объявляет дополнительную проверку корректности введенного значения.

Листинг 4.13 - Пример заголовков функции проверки введенных переменных на языке Си

int ESRconfig_check_tunnels_gre_keepalive_timeout (

ESRobject_root_t * root,

const ESRobject_t * o,

uint8_t * ptr,

size_t size,

ESRobject_error_description_t * err)

int ESRconfig_check_tunnels_gre_keepalive_retries (

ESRobject_root_t * root,

const ESRobject_t * o,

uint8_t * ptr,

size_t size,

ESRobject_error_description_t * err)

Данные функции представленные в листинге 4.13 отвечают за проверку корректности указания значения.

При работе с данными структурами удобно использовать определенные макросы, например макрос который отвечает за проход по всем активным интерфейсам: ESRconfig_reflection_FOREACH_OBJ (obj_idx, tunnels_gre)

Так же при инициализации нужно указать определенные дефолтные значения:

cfg->keepalive_timeout = ESRconfig_tunnels_gre_keepalive_timeout_DEFAULT;

cfg->keepalive_retries = ESRconfig_tunnels_gre_keepalive_retries_DEFAULT;

cfg->keepalive_enable = ESRbool_false;

в данном случае устанавливается значение по умолчанию для значения timeout равное 10, retries равно 5, и переменная enable устанавливается не активным, т.к. данный механизм по умолчанию должен быть выключен.

Далее перед тем как будет произведено конфигурирование модуля ядра, нужно передать параметры утилите iproute2. Так же из-за того, что на интерфейсе может быть сконфигурирован VRF (virtual routing forwarding), есть несколько методов для запуска данного механизма, так как механизм должен быть активен в нужном пространстве. Для этого обрабатывается условие if (strlen (tunnel_gre->vrf_instance) > 0) и если VRF настроен то нужно выполнить do_cmd ip netns exec % s ip tunnel % s % s_%d mode gre local % s remote % s ttl % s tos % s keepalive % d % d здесь передаеются в строке параметров переменные для конфигурирования интерфейса, если VRF не задан do_cmd ip tunnel % s % s_%d mode gre local % s remote % s ttl % s tos % s keepalive % d % d то команда немного упрощается. Для того что бы отключить данный механизм нужно параметры keepalive указать равные 0 0. Оболочка CLI основывается на древовидной структуре описанной в файлах типа XML. Дя того что бы пользователь мог увидеть настройки при конфигурирование интерфейса нужно создать в XML файле несколько объявлений в листинге 4.14.

Листинг 4.14 - Пример XML файла

<COMMAND name= «keepalive»

permissions= «10»

help= «Configure parameters of keepalive»/>

<COMMAND name= «keepalive timeout»

permissions= «10»

help= «Set period keepalive»>

<PARAM name= «TIMEOUT»

help= «Set keepalive period in seconds»

ptype= «TYPE_INT_1_32767»/>

<ACTION builtin= «klish_reflection_handler»>«${IPC_PATH_BASE}|#|ATTR_SET|keepalive-timeout|${TIMEOUT}«</ACTION>

</COMMAND>

<COMMAND name= «keepalive retries»

permissions= «10»

help= «Set the number of retries»>

<PARAM name= «RETRIES»

help= «Retry count»

ptype= «TYPE_INT_1_255»/>

<ACTION builtin= «klish_reflection_handler»>«${IPC_PATH_BASE}|#|ATTR_SET|keepalive-retries|${RETRIES}«</ACTION>

</COMMAND>

<COMMAND name= «keepalive enable»

permissions= «10»

help= «Enable keepalive»>

<ACTION builtin= «klish_reflection_handler»> «${IPC_PATH_BASE}|#|ATTR_SET|keepalive-enable|true»</ACTION>

</COMMAND>

Здесь происходит добавление команд для оболочки CLI, директивами COMMAND объявляется команда, PARAM задаются параметры для команды, действие ACTION позволяет вызвать какую-либо функцию для дальнейшей обработки переменных. В консоли CLI конфигурирование происходит следующим образом рисунок 4.1. С начало надо зайти в режим конфигурирования вводом команды config, далее нужно перейти в режим конфигурирования туннеля GRE, выполнением команды tun gre <номер туннеля>, далее командами keepalive enable активируется механизм отправки сообщений активности, keepalive timeout задает время периода отправки сообщений, и keepalive retries используется для того, чтобы можно было задать количество повторов отправки сообщений по истечению, которых будет произведено смена состояния интерфейса.

Пример командной строки CLI

После применения данных настроек надо выполнить команды commit и confirm, после выполнения данных команд, при помощи программы wireshark видно то пакеты отправляются с определенным периодом рисунок.



Трафик в программе wireshark

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

Пример сообщения в консоли CLI

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



Заключение

В ходе разработки данного механизма были изучены подсистемы ядра linux, сетевая для сборки пакет, времени для задания таймаута, изучено конфигурирование модуля ядра по средствам IOCTL, написан небольшой патч для утилиты iproute2, была добавлена возможность конфигурирования из командной строки CLI. Данный механизм позволил улучшить работу с GRE туннелем, т.к. после того как происходит потеря соединения то по истечению заданного количества повторов происходит смена состояния интерфейса, тем самым вызывая удаление маршрута для GRE туннеля. После удаления маршрута пакеты сетевого трафика будут либо отбрасываться на входе в туннель и будет отправляться сообщение о недоступности соединения, либо если в системе прописаны альтернативные маршруты, то пакет пойдет через них. В данной работе можно доработать возможность работы данного механизма когда сконфигурирован подсчет пакетов т.е. в заголовке GRE добавляется дополнительное поле SEQ, но в маршрутизаторах ELTEX ESR100/200/1000/1200, данная возможность конфигурирования не поддерживается, по этому в данной работе не было реализовано данная функция.



Библиография

1 Лав Р. Linux. Системное программирование - 2-е изд. - Санкт-Петербург: Питер, 2014. - 448. с.

2 Оливер В.Г. Компьютерные сети. Принципы, технологии, протоколы - СПб.: ПИТЕР, 2002. - 668с

3 Цилюрик О.И. Модули ядра Linux. Внутренние механизмы ядра. Таймеры ядра. URL: http://rus-linux.net/MyLDP/BOOKS/Moduli-yadra-Linux/06/kern-mod-06-14.html. (дата обращения 7.06.2016)

4 API ядра Linux, Часть 3: Таймеры и списки в ядре 2.6. URL: http://rus-linux.net/nlib.php? name=/MyLDP/kernel/api/kernelapi3.html. (дата обращения 7.06.2016)

5 Анатомия сетевого стека в Linux. URL: https://www.ibm.com/developerworks/ru/library/l-linux-networking-stack/. (дата обращения 7.06.2016)

6 Цилюрик О.И. Модули ядра Linux. Внешние интерфейсы модуля. Сеть. URL: http://rus-linux.net/MyLDP/BOOKS/Moduli-yadra-Linux/05/kern-mod-05-11.html. (дата обращения 7.06.2016)

7 Сетевые драйверы. URL: http://dmilvdv.narod.ru/Translate/LDD3/ldd_how_snull_designed.html. (дата обращения 7.06.2016)

8 IOCTL. URL: http://dmilvdv.narod.ru/Translate/LDD3/ldd_ioctl.html. (дата обращения 7.06.2016)

9 Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman. Linux Device Drivers, Third Edition. - USA, 2005. - С. 497-545

Размещено на Allbest.ru

...