November 2014 - kernel-russian@kernelnewbies.org

Fwd: [Network] Простой ICMP запрос
by Ivan Riabtsov Nov. 22, 2014

Nov. 22, 2014

22.11.14, Alex Naumov<alexander_naumov(a)opensuse.org> написал(а): > 2014-11-21 22:16 GMT+01:00 Ivan Riabtsov <ivriabtsov(a)gmail.com>: > >> думаю, что сеть можно считать рабочей, если вернулось не меньше 3-х из >> 4-х пакетов, > > > Да, 75% конечно надежней, чем 50%, но если мы получили хотя бы... даже один > ответ, значит хост работает и отвечат. По количеству отстальных ответов > можно судить о качестве соединения. ну в общем в обычном unix так пинг и работает, он посылает 1 пакет и по 1-му ответу судит, жив хост или нет > > >> еще я бы проверил контрольную сумму принятого пакета, без >> нее как-то не кошерно > > > Да, она добавляется, но не проверяется при получении. > Значит ли это, что, если я ping'ую два хоста, то ответы могут просто > перемешаться? по идее при посылке пинга надо генерировать id пакета и номер последовательнности, можно хранить у себя соответствие id пакета и ip адреса, соответственно после получения пакета проверять, совпадает ли id пакета и ip адрес, с которого был получен ответ, для этого надо распарсить ip header полученного пакета > > >> еще я не очень понял, recvfrom не блокируется в >> ожидании ответа? > > > Я просто добавил пока секундную задержку :) > Кстати, не подвесит ли блокировка процесс, при отсутствии ответов? можно сделать вызов блокирующим, но запускать как отдельный поток, тогда, если вызывающая процедура "заснет" например на 4 секунды, то по прошествии этих 4-х секунд она может принудительно ззавершить поток. > > >> получается, что как минимум первый вызов recvfrom >> всегда пройдет в холостую, > > > Да, сам не знаю как так получилось - конечно же recvfrom() и sendto() надо > поменять местами. угу :) > > > >> я бы возможно попробовал отдельный сделать >> поток для посылки пингов и отдельный поток для приема пакетов, возврат >> из потока я не очень понимаю, как делать, так что сделал бы внешнюю >> переменную, в которой бы записывалось кол-во принятых пакетов, при >> этом вызов recvfrom сделал бы блокирующимся, но я не знаю как это >> делать, по идее он по умолчанию такой, иначе придется делать холостой >> цикл, который будет отъедать процессорное время. >> >> Будет интересно посмотреть на код, но на сколько оправданно > распараллеливание потока (т.е. усложнение кода) в данном случае? в принципе не опревдано, но ради нтереса можно запилить :) >

1 0

Re: [Network] Простой ICMP запрос
by Ivan Riabtsov Nov. 22, 2014

Nov. 22, 2014

22.11.14, Ivan Riabtsov<ivriabtsov(a)gmail.com> написал(а): > 22.11.14, Alex Naumov<alexander_naumov(a)opensuse.org> написал(а): >> 2014-11-21 22:16 GMT+01:00 Ivan Riabtsov <ivriabtsov(a)gmail.com>: >> >>> думаю, что сеть можно считать рабочей, если вернулось не меньше 3-х из >>> 4-х пакетов, >> >> >> Да, 75% конечно надежней, чем 50%, но если мы получили хотя бы... даже >> один >> ответ, значит хост работает и отвечат. По количеству отстальных ответов >> можно судить о качестве соединения. > > ну в общем в обычном unix так пинг и работает, он посылает 1 пакет и > по 1-му ответу судит, жив хост или нет > >> >> >>> еще я бы проверил контрольную сумму принятого пакета, без >>> нее как-то не кошерно >> >> >> Да, она добавляется, но не проверяется при получении. >> Значит ли это, что, если я ping'ую два хоста, то ответы могут просто >> перемешаться? > > по идее при посылке пинга надо генерировать id пакета и номер > последовательнности, можно хранить у себя соответствие id пакета и ip > адреса, соответственно после получения пакета проверять, совпадает ли > id пакета и ip адрес, с которого был получен ответ, для этого надо > распарсить ip header полученного пакета > >> >> >>> еще я не очень понял, recvfrom не блокируется в >>> ожидании ответа? >> >> >> Я просто добавил пока секундную задержку :) >> Кстати, не подвесит ли блокировка процесс, при отсутствии ответов? > > можно сделать вызов блокирующим, но запускать как отдельный поток, > тогда, если вызывающая процедура "заснет" например на 4 секунды, то по > прошествии этих 4-х секунд она может принудительно ззавершить поток. в смысле отдельный поток не для посылки и приема, а просто для целой процедуры ping, то есть в этом потоке будет и посылка и прием пакетов, думаю, это будет оптимальный вариант. > >> >> >>> получается, что как минимум первый вызов recvfrom >>> всегда пройдет в холостую, >> >> >> Да, сам не знаю как так получилось - конечно же recvfrom() и sendto() >> надо >> поменять местами. > > угу :) > >> >> >> >>> я бы возможно попробовал отдельный сделать >>> поток для посылки пингов и отдельный поток для приема пакетов, возврат >>> из потока я не очень понимаю, как делать, так что сделал бы внешнюю >>> переменную, в которой бы записывалось кол-во принятых пакетов, при >>> этом вызов recvfrom сделал бы блокирующимся, но я не знаю как это >>> делать, по идее он по умолчанию такой, иначе придется делать холостой >>> цикл, который будет отъедать процессорное время. >>> >>> Будет интересно посмотреть на код, но на сколько оправданно >> распараллеливание потока (т.е. усложнение кода) в данном случае? > > в принципе не опревдано, но ради нтереса можно запилить :) > >> >

1 0

[Network] Простой ICMP запрос
by Alex Naumov Nov. 22, 2014

Nov. 22, 2014

Всем привет. Начнем потихоньку? Вот [1] пример функции, которая отправляет 4 ICMP запроса (raw-сокет). В качестве аргумента передаем ей строку с IP адресом. Если получено больше одного ответа, то функция возвращает положительный ответ. Предпологается, что функция используется по аналогии с ping(8). Кто что думает об этом коде? Что можно улучшить? Мне вот интересно, сколько по-вашему стоит получить ответов, чтобы быть уверенным, что сеть работет без проблем и задержка с ответами не слишком большая? Кто-нибудь может ясно объяснить, почему для корректной работы он требует права root? Alex [1] http://goo.gl/2eAH4C

3 5

Re: [Network] Простой ICMP запрос
by Alex Naumov Nov. 21, 2014

Nov. 21, 2014

2014-11-21 22:20 GMT+01:00 Naydin Andrey <naydinav(a)gmail.com>: > Привет Alex. Может имеет смысл создать репозиторий на github или еще где. > Что б можно было сразу примеры-задачки сливать, собирать, вносить правки. Я > это предлагаю в контексте > > Кто что думает об этом коде? Что можно улучшить? > > Что б можно было создавать бранчи с решениям, которые по мнению > конкретного взятого разработчика улучшают код. И затем обсуждать. > И всегда можно будет в переписке ссылаться на нужный коммит/ветку. > Это только предложение. А не условие. > Привет. Это отличная идея! Я сам хотел предложить. Кто возьмется? Создайте кто-нибудь, кому не лень, мы скопируем. > > Анализируя пристегнутый код письму могу только пока предложить вариант > ответа к следующему вопросу > > Кто-нибудь может ясно объяснить, почему для корректной работы он требует > права root? > > Тут я немного схитрил, что б получить ответ. > Рута запрашивает на > sd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); > > А стандартный системный ping - нет. Поэтому не долго думая, слил исходники > пакета busybox (очень советую скачать всем, кто хочет в полной мере на > примере изучать разработку системного ПО) и начал сравнивать нашей > реализации Ping с тем что представлено в нем. > > Сокет создается там примерно так же. Но идет проверка, что если сокет не > создался, то идет проверка на права доступа со следующей припиской. > ** We don't have root privileges. Try SOCK_DGRAM instead.* > * * Linux needs net.ipv4.ping_group_range for this to work.* > * * MacOSX allows ICMP_ECHO, ICMP_TSTAMP or ICMP_MASKREQ* > * */* > Гугл по запросу > > > *ping_group_range Выдал такой результат. * > > Socket(2) is restricted to the group range specified in > "/proc/sys/net/ipv4/ping_group_range" (or the owner of CAP_NET_RAW). It > is "1 0" by default, meaning that nobody except root may create ping > sockets. Setting it to "100 100" would gain permissions to the single > group, "0 65535" would enable it for the world. > > Интересно. Я пока глубоко в этот вопрос не погружался. Думал, что это требуют все raw-сокеты. Но с чем связанно требование к правам root?

1 0

Re: [Network] Простой ICMP запрос
by Андрей Найдин Nov. 21, 2014

Nov. 21, 2014

возвращаясь к цитате. >> Socket(2) is restricted to the group range specified in >> "/proc/sys/net/ipv4/ping_group_range" (or the owner of CAP_NET_RAW). It >> is "1 0" by default, meaning that nobody except root may create ping >> sockets. Setting it to "100 100" would gain permissions to the single >> group, "0 65535" would enable it for the world. >> попробовал у себя сделать следующий финт ушами по подмене значений в /proc/sys/net/ipv4/ping_group_range выставил значения "0 65535" - ничего не поменялось, все так же требует права рута наш пример. Перезагрузил систему - значения сбросились. Более детально решил не капать. Для себя решил, что без прав суперпользователя пинг не получится реализовать. Я думаю, что разработчики просто сделали требование на права суперпользователя для raw-сокетов, так как их применение потенциально опасно. Напихать в пакет можно что угодно. На сколько я помню забиндить диапазон портов <1024 сокетом так же требует прав суперпользователя. Так же логично, что б стандартные порты сервисов (www, ssh, ftp) нельзя было слегонца забиндить и выдать себя клиентам за веб-сервер. 22 ноября 2014 г., 0:44 пользователь Ivan Riabtsov <ivriabtsov(a)gmail.com> написал: > обеими руками за идею с git, хотя не очень умею с ним работать. > > 22.11.14, Ivan Riabtsov<ivriabtsov(a)gmail.com> написал(а): > > ну вообще привелегии root нужны, просто обычно /bin/ping с битом Suid: > > $ cd /bin > > ivr@debian:/bin > > $ ll | grep ping > > -rwsr-sr-x 1 root root 36K Apr 12 2011 ping > > -rwsr-xr-x 1 root root 37K Apr 12 2011 ping6 > > > > > > 22.11.14, Naydin Andrey<naydinav(a)gmail.com> написал(а): > >> > >> Привет Alex. Может имеет смысл создать репозиторий на github или еще > >> где. Что б можно было сразу примеры-задачки сливать, собирать, вносить > >> правки. Я это предлагаю в контексте > >>> Кто что думает об этом коде? Что можно улучшить? > >> Что б можно было создавать бранчи с решениям, которые по мнению > >> конкретного взятого разработчика улучшают код. И затем обсуждать. > >> И всегда можно будет в переписке ссылаться на нужный коммит/ветку. > >> Это только предложение. А не условие. > >> > >> Анализируя пристегнутый код письму могу только пока предложить вариант > >> ответа к следующему вопросу > >>> Кто-нибудь может ясно объяснить, почему для корректной работы он > >>> требует права root? > >> Тут я немного схитрил, что б получить ответ. > >> Рута запрашивает на > >> sd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP); > >> > >> А стандартный системный ping - нет. Поэтому не долго думая, слил > >> исходники пакета busybox (очень советую скачать всем, кто хочет в полной > >> мере на примере изучать разработку системного ПО) и начал сравнивать > >> нашей реализации Ping с тем что представлено в нем. > >> > >> Сокет создается там примерно так же. Но идет проверка, что если сокет не > >> создался, то идет проверка на права доступа со следующей припиской. > >> /* We don't have root privileges. Try SOCK_DGRAM instead.// > >> // * Linux needs net.ipv4.ping_group_range for this to work.// > >> // * MacOSX allows ICMP_ECHO, ICMP_TSTAMP or ICMP_MASKREQ// > >> // */// > >> /Гугл по запросу /ping_group_range > >> > >> Выдал такой результат. > >> / > >> > >> Socket(2) is restricted to the group range specified in > >> "/proc/sys/net/ipv4/ping_group_range" (or the owner of CAP_NET_RAW). It > >> is "1 0" by default, meaning that nobody except root may create ping > >> sockets. Setting it to "100 100" would gain permissions to the single > >> group, "0 65535" would enable it for the world. > >> > >> > >> > >> > >> > >> > > > _______________________________________________ > Kernel-russian mailing list > Kernel-russian(a)kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernel-russian >

1 0

Стивенс "UNIX: разработка сетевых приложений" - упражнения и примеры из книги
by Alex Naumov Nov. 20, 2014

Nov. 20, 2014

Всем привет. Да, этот ML о Linux kernel, тем не менее, так как трафик рассылки очень низкий, я думаю, мы можем немного расширить тематику. Думаю, тут найдутся те, кто просто увлекается системным или сетевым программированием. Естественно на C. Вы наверняка знаете о книге Стивенса "UNIX: разработка сетевых приложений". Мой вопрос... или даже не вопрос, а предложение, прорешать задачки из этой книги. Там есть, если не ошибаюсь, и задачи и просто примеры, которые в современных дистрибутивах уже не работают. Есть тут те, кому интересно пройтись по книге и исправить примеры и запрограммировать задачки? Если есть единомышленники или просто те, кому это интересно, пишите сюда. Будем обсуждать идеи или просто решения той или иной из задач. Естественно никто не мешает задачи менять, усложнять и т.д. Мне было бы интересно посмотреть другие решения, обсудить их и конечно же сравнить со своими. Было бы интересно почитать о критике своего кода. Короче говоря, приглашаю всех С-программистов весело провести время :) С уважением, Alex

3 3

Докуменация о /proc: остается актуальной как минимум последние 5 лет
by Alex Naumov Nov. 19, 2014

Nov. 19, 2014

Всем привет. Как известно, официальная документация для /proc находится тут[1], но там примеры и дата последнего обновления аж 2009 года. Хотя если посмотреть дату самого файла, то выходит, что файл достаточно новый - 2014 года. /proc совсем не поменялся за последние 5 лет? Или более актуальную информацию перенесли в другое место? 0.1 Introduction/Credits ------------------------ This documentation is part of a soon (or so we hope) to be released book on the SuSE Linux distribution. As there is no complete documentation for the /proc file system and we've used many freely available sources to write these chapters, it seems only fair to give the work back to the Linux community. This work is based on the 2.2.* kernel version and the upcoming 2.4.*. С уважением, Alex [1] https://www.kernel.org/doc/Documentation/filesystems/proc.txt

2 2

"Understanding and using C pointers" by Richard M. Reese
by Alex Naumov Nov. 19, 2014

Nov. 19, 2014

Всем привет. Может кто-то в курсе: есть ли перевод этой книги на русский или возможно частичный любительский перевод? Книга очень классная, читаю ее сейчас, но хотелось бы познакомиться и с переводом, если таковой имеется. С уважением, Alex

1 0