Структура мережевої підсистеми Linux. Створення мережевого інтерфейсу. Передача пакетів та аналіз поведінки інтерфейсу. Протокол транспортного рівня. Використання модулів ядра. Вплив маршрутизації на процес розробки і налагодження мережевих модулів.
При низкой оригинальности работы "Розробка мережевого системного програмного забезпечення на базі ядра ОС Linux", Вы можете повысить уникальность этой работы до 80-100%
1. Ознайомлення з Мережевою підсистемоюПЕРЕЛІК ВИКОРИСТАНОЇ ЛІТЕРАТУРИОднак вивчення питань взаємодії з мережевими пристроями та протоколами з коду модулів ядра було вирішено включити в огляд драйверів пристроїв саме через функціонал близькості предметів. Цікавість розробника модулів ядра до мережевої підсистеми може бути звязана з тим, що саме через постійне розширення спектра протоколів і комунікаційних пристроїв, задачі по розробці драйверів для специфічних комунікаційних пристроїв зявляються більш частіше, чим для любих інших видів пристроїв. Основною структурою даних, яка описує мережевий інтерфейс (пристрій), є struct net_device, а основною структурою, за допомогою якої відбувається обмін даними між мережевими рівнями і на основі якої побудована робота всієї мережевої підсистеми є буфер сокета - struct sk_buff (файл ).Але, незважаючи на велику кількість можливостей (наприклад, якщо судити за кількістю обслуговуючих мережевих утиліт: ifconfig, ip, netstat і тд), мережева підсистема Linux, з позиції розробника ядра, виглядає логічнішою і прозорішою, ніж, наприклад, ті ж інтерфейси для роботи з пристроями. Ця підсистема в основному орієнтована на обслуговування Ethernet-протоколів на канальному рівні і TPC/IP на транспортному рівні, але також розширюється і на інші типи протоколів, таким чином, покриваючи весь спектр можливостей. На даний момент мережева підсистема Linux забезпечує підтримку найширшого спектра протоколів і пристроїв: · дротове зєднання Ethernet (LAN); · бездротові модеми (WAN), що відносяться до різноманітних протоколів, мережам і модифікаціям: GSM, GPRS, EDGE, CDMA, EV-DO (EVDO), WIMAX, LTE. Мережева модель TCP/IP, як відомо, дуже умовно узгоджується (або зовсім не узгоджується ) з 7-ми рівневою OSI-моделлю взаємодії відкритих систем.На відміну від решти системних пристроїв, яким відповідають імена в каталозі /dev, мережеві пристрої створюють мережеві інтерфейси, які не відображаються як іменовані пристрої, але мають свій набір конфігураційних параметрів (MAC адресу, IP адреса, маска мережі і т.д). Інтерфейси можуть бути фізичними (відображаючи реальні апаратні мережеві пристрої, наприклад, eth0 - адаптер Ethernet) або логічними (що відображають деякі модельовані поняття, наприклад tap0 - тунельний інтерфейс). Одному реальному апаратному мережевому пристрою може відповідати одночасно кілька різних мережевих інтерфейсів. При розробці модулів ядра, що підтримують мережеві пристрої, постійно потрібно спостерігати за станом і керувати різними мережевими інтерфейсами. Тут показані два мережевих інтерфейси: фізична бездротова мережа Wi-Fi (wlan0) і віртуальний інтерфейс (віртуальна приватна мережа, VPN), створений програмними засобами (CISCOSYSTEMVPNCLIENT) від Cisco System (cipsec0), - працюють через один і той же фізичний канал (що підтверджує сказане вище про можливість декількох мережевих інтерфейсів над одним каналом).Буфер сокета складається з двох частин: · керуючі дані, що знаходяться в структурі struct sk_buff; · дані пакета (вказуються в struct sk_buff покажчиками head і data). Буфери сокетів упорядковуються у вигляді черги (struct sk_queue_head) за допомогою своїх двох перших полів next та prev. Фрагмент структури sk_buff typedef unsigned char *sk_buff_data_t; Примірники даних типу struct sk_buff: · створюються при надходженні чергового мережевого пакету з зовнішнього фізичного середовища (потрібно враховувати можливість сегментації пакетів).Імя мережевого інтерфейсу завершується числовим суфіксом - порядковим номером даного інтерфейсу і є унікальним в системі, відповідаючи імені в каталозі /dev для потокових пристроїв. Мережевий інтерфейс повязує воєдино безліч параметрів канального рівня (наприклад, апаратний MAC-адресу) з параметрами більш високих рівнів (наприклад, IP адрес). #include static struct net_device *dev; static int my_open( struct net_device *dev ) {printk( KERN_INFO "Hit: my_open(%s)
", dev->name );Як зазначалось вище, основу опису мережевого інтерфейсу становить структура struct net_device, описана у файлі . Ця структура, містить не тільки опис апаратних засобів, але і конфігураційні параметри мережевого інтерфейсу по відношенню до вище лежачим протоколам. Фрагмент структури net_device struct net_device {char name[ IFNAMSIZ ] ; Докладний розбір полів структури struct net_device або їх можливих значень не має сенсу, так як ця структура може радикально змінюватися між під версіями ядра; та її аналіз повинен проводитися «за місцем» на основі вивчення названих вище заголовних файлів. Нижче наведено фрагмент даної функції, визначеної в ядрі 3.09, але немає жодних гарантій, що в іншій версії ядра не зявиться жодних змін. static inline void *netdev_priv(const struct net_device*dev)У рамках цього підходу кожний отриманий мережевий пакет продовжує апаратне переривання по IRQ-лінії адаптера, що служить сигналом на прийом чергового мережевого пакет
План
4. Зміст розрахунково-пояснювальної записки (перелік питань, які підлягають розробці)
1.1 Структура мережевої підсистеми Linux;
1.2 Використовувані інструменти;
1.3 Структура sk_buff;
1.4 Створення мережевого інтерфейсу;
1.5 Структура net_device;
2.1 Традиційний підхід для реалізації мережевих інтерфейсів;
2.2 Високошвидкісні інтерфейси;
2.3 Передача пакетів;
2.4 Віртуальний мережевий інтерфейс;
2.5 Аналіз поведінки інтерфейсу;
2.6 Протокол мережевого рівня;
2.7 Протокол транспортного рівня;
3.1 Протокольні фільтри;
3.2 Вплив маршрутизації на процес розробки і налагодження мережевих модулів;
3.3 Допоміжні API ядра;
3.4 Операції з файлами;
3.5 Запуск нових процесів.
5. Перелік графічного (ілюстративного) матеріалу, якщо передбачено
6. Дата видачі завдання 5.03.2013 р.
КАЛЕНДАРНИЙ ПЛАН
№ п/пНазва етапів курсової роботиТермін виконання етапів роботиПримітка
1Отримання завдання на КР1.03.2013 - 5.03.213
2Ознайомлення з вихідними даними6.03.2013 - 8.03.2013
