Cокеты в Linux

А причём тут сокеты?

raw sockets видимо

Я хотел ТСа в код netfilter ткнуть вобщем-то :)

>raw sockets видимо

а причем тут роу сокеты?

Стоит задача написать маршрутизатор пакетов из одной сети в другую.

а разве таблица маршрутизации не на уровне ядра работает?

ТС, поясни, что именно ты хочешь... написать управлялку таблицей маршрутизации или все-таки саму маршрутизацию?

TC пытается осмыслить тему дипломной работы, тут можно посоветовать выбрать другую тему если можно, а то эта скучная.

а разве таблица маршрутизации не на уровне ядра работает?

А какая разница, где ей работать?

а пакетики на каком уровне разбрасываться будут, тоже без разницы?

а пакетики на каком уровне разбрасываться будут, тоже без разницы?

Абсолютно. Ну в юзерспейсе помедленнее будет из-за переключений контекста.

ты вполне можешь делать IP маршрутизацию в us. Просто будет больше копирования памяти и не сможешь так красиво оптимизировать код.

Боюсь что в удаленном сообщении был первый правильный вопрос. В смысле что бы тему точно огласил. Очень вероятно что автор треда немного ошибся.

Мне требуется написать некое подобие биллинг системы, но только в простейшем ее виде. Поскольку сетевым программированием я только начал заниматься, то вопросы есть: - как организовать прием и пере направление пакетов? (сокеты raw????) - как понять кому пришел пакет от «сервера»

Насколько я помню - маршрутизация пакетов происходит на уровне ядра. Можно как-то контролировать этот процесс? Или нужно самому писать софт. Также мне нужно сделать мониторинг сетевого траффика.

Тема звучит так: «конроль и мониторинг сетевых ресурсов».

>Поскольку сетевым программированием я только начал заниматься,

Смелый выбор темы диплома.

как организовать прием и пере направление пакетов?

Что значит «пере направление»? NAT что-ли?

Контролировать маршрутизацию... Есть маршруты, есть кеш маршрутов. Маршруты можно добалять/удялять, но это, наверное, управление маршрутизацией, а не контроль.

Вобще, что то у вас странное. Известные мне биллинговые системы собирают информацию о трафике и изменяют настройки (маршруты, NAT )при подключении/отключении/привышении порога. То есть они занимаются мониторингом сетевого трафика, информацию о трафике разные реализации получают по разному (raw socket, iptables ULOG или QUEUE, NetFilter).

>Смелый выбор темы диплома. К сожалению этот выбор был безальтернативным, тобиш добровольно/принудительно. Препод сам ничего не знает, а вот захотелось ему.

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

То есть я понимаю, что нужно посредством system() просто выполнять команды iptables?

какого еще system()? пхпшник что ли?

> какого еще system()?
Наверное, такого, какой описывается в man 3 system.

пхпшник что ли?

А причем тут пхп?

боюсь он морду своего биллинга на нем собрался делать

Ребята, как считать статистику по принято/передано с iptables программой на С/С++ ? А то никак найти не могу, может у iptables есть какие-то API?

значения в iptables сбрасываются периодически

я бы юзал наверное какой то vpn + radius, базу хранил в мускуле

морду к этому на питоне или взять любую готовую. зачем тут c/c++ ?

>у iptables есть какие-то API?

гугли по libnetfilter - там их несколько...(conntrack, queue, log)

>значения в iptables сбрасываются периодически

если написать приложение и подвязать его к iptables через -j QUEUE или -j ULOG, то все будет ок.

Кстати вопрос знающим, -j QUEUE - такое же тормозное Г как и -j ULOG?

Я не особо специалист по QUEUE, но тормознутости ULOG не замечал. В чём она проявляется? А так они разные, ЕМНИП, то в QUEUE входит очередь до 1000 пакетов в user-space. И если программа не пропускает через себя пакеты, то они дальше не идут. То есть по сути это фильтр. А в ULOG идёт копия пакета, и будет ли она обработана в user-space это не важно, сам пакет пойдёт дальше.

>тормознутости ULOG не замечал

Прогони пару 1Gbit/sec трафика через ULOGD на P4 и удивись.

P.S. С NETFLOW ессно таких проблем нет ;). Но мы его здесь и не рассматриваем...

в ULOG идёт копия пакета, и будет ли она обработана в user-space это не важно, сам пакет пойдёт дальше

Понятно. Разные принципы. Спасибо за пояснение.

То есть вы пытались использовать ulogd? Так бы сразу и писали. И при чём тут "-j ULOG"? Да, толсто :)

Когда мне надо было, я сразу выкинул ulogd и сам писал читалку того, что шлёт ядро (два потока, приоритет реального времени на поток чтения из ULOG-сокета). Написание, тестирование, изучение ядра заняло примерно 1,5 месяца, так что ТС не позавидуешь, если, конечно, ему нужна реально работающая система :)

P.S. Какой Netflow? ipt_NETFLOW или через pcap (softflowd, fprobe)?

>Какой Netflow?

сначала б-гомерзкий ndsad, потом ipt_NETFLOW

То есть вы пытались использовать ulogd? Так бы сразу и писали. И при чём тут "-j ULOG"?

При том что это один из вариантов как подружить сраные ndsad и UTM5(вот в жисть бы такой говно-биллинг бы не купил).

Сейчас все крутится на ipt_NETFLOW - проблем нет.