Модуль ядра Linux. Виртуальный сетевой интерфейс.
Добавлено: 21 янв 2013, 14:10
Добрый день!
В настоящий момент я занимаюсь задачей по шифрованию трафика на уровне ядра и мне очень помогли статьи Олега Ивановича Цилюрика по разработке модулей ядра, спасибо! Так же помогли статьи Олега с сайта IBM developerWorks.
Для изучения я использовал исходный код модулей из архива network.tgz, взятого от сюда.
Но у меня все еще остается несколько вопросов.
Для начала более общие:
1) Цель моей задачи - изменить содержимое IP пакета на отправляющей стороне, отправить его в сеть (при этом проследить чтобы исходный пакет не ушел в сеть), а на принимающей стороне получить пакет, произвести над ним обратное преобразование и протолкнуть дальше по стеку TCP/IP. Изучив материал, я нашел решение - использовать системный вызов dev_add_pack(). Павильно ли мое решение? Какие могут возникнуть проблемы? Может есть альтернативные решения?
2) Каким образом пакет проходит по стеку TCP/IP если я регистрирую новый обработчик протокола 3-го уровня вызовом dev_add_pack()? Пакет сначала пройдет через мой обработчик, а затем пойдет в стандартный обработчик ip?
3) Мой обработчик будет вызываться при прохождении пакета по стеку TCP/IP как вверх, так и вниз? Я могу как то различать, пришел ли пакет из сети (входящий) или он создан на локальной машине (исходящий)?
4) Что повлечет за собой изменение длины пакета IP в буфере сокета sk_buff на этом уровне?
А теперь вопросы по конкретному модулю из статьи Разработка модулей ядра Linux: Часть 35. Дополнительные аспекты использования модулей ядра для создания сетевых интерфейсов:
3) Я исследовал упрощенную и полную версию данного виртуального интерфейса и заметил что упрощенный интерфейс(virtl.ko) работает как фильтр, т.е. он не различает какие пакеты для родительского интерфейса являются входящими, а какие исходящими, я правильно понимаю?
4) В полном виртуальном интерфейсе(virt.ko) каким образом пакеты проходят через стек TCP/IP? С помощью данного модуля ядра мы добавляем свои обработчики протоколов 3-го уровня, но после того как мы получили пакет и функция start_xmit() обработала его, куда он дальше попадает?
5) При исследовании данного модуля на принимающей сообщения машине я заметил утечку памяти. Если я отправляю 100мб, то на приемной стороне с запущенным модулем забьется ровно 100мб оперативки. Без этого модуля все нормально. После выгрузки модуля память не освобождается. Такое ощущения что буферы сокетов где то клонируются и не освобождаются.
Буду рад любым советам. Спасибо!
В настоящий момент я занимаюсь задачей по шифрованию трафика на уровне ядра и мне очень помогли статьи Олега Ивановича Цилюрика по разработке модулей ядра, спасибо! Так же помогли статьи Олега с сайта IBM developerWorks.
Для изучения я использовал исходный код модулей из архива network.tgz, взятого от сюда.
Но у меня все еще остается несколько вопросов.
Для начала более общие:
1) Цель моей задачи - изменить содержимое IP пакета на отправляющей стороне, отправить его в сеть (при этом проследить чтобы исходный пакет не ушел в сеть), а на принимающей стороне получить пакет, произвести над ним обратное преобразование и протолкнуть дальше по стеку TCP/IP. Изучив материал, я нашел решение - использовать системный вызов dev_add_pack(). Павильно ли мое решение? Какие могут возникнуть проблемы? Может есть альтернативные решения?
2) Каким образом пакет проходит по стеку TCP/IP если я регистрирую новый обработчик протокола 3-го уровня вызовом dev_add_pack()? Пакет сначала пройдет через мой обработчик, а затем пойдет в стандартный обработчик ip?
3) Мой обработчик будет вызываться при прохождении пакета по стеку TCP/IP как вверх, так и вниз? Я могу как то различать, пришел ли пакет из сети (входящий) или он создан на локальной машине (исходящий)?
4) Что повлечет за собой изменение длины пакета IP в буфере сокета sk_buff на этом уровне?
А теперь вопросы по конкретному модулю из статьи Разработка модулей ядра Linux: Часть 35. Дополнительные аспекты использования модулей ядра для создания сетевых интерфейсов:
3) Я исследовал упрощенную и полную версию данного виртуального интерфейса и заметил что упрощенный интерфейс(virtl.ko) работает как фильтр, т.е. он не различает какие пакеты для родительского интерфейса являются входящими, а какие исходящими, я правильно понимаю?
4) В полном виртуальном интерфейсе(virt.ko) каким образом пакеты проходят через стек TCP/IP? С помощью данного модуля ядра мы добавляем свои обработчики протоколов 3-го уровня, но после того как мы получили пакет и функция start_xmit() обработала его, куда он дальше попадает?
5) При исследовании данного модуля на принимающей сообщения машине я заметил утечку памяти. Если я отправляю 100мб, то на приемной стороне с запущенным модулем забьется ровно 100мб оперативки. Без этого модуля все нормально. После выгрузки модуля память не освобождается. Такое ощущения что буферы сокетов где то клонируются и не освобождаются.
Буду рад любым советам. Спасибо!