RomanCh

Вероятно вы про наличие атрибута указывающего тип ответа (OFFER/ACK/NAK) - если да, то его слать не надо. dhcpd сам решает исходя из ситуации какой тип пакета отправить. Обусловленно это как минимум кэшированием - если оно включено то на RADIUS сервер отсылается только один запрос. А вообще, исходя из протокола DHCP - ответы сервера должны содержать одинаковый набор конфигурационных данных в OFFER & ACK. Хотя для преобразования их в DHCP из RADIUS это не принципиально. Главное что бы совпадали обязательные атрибуты (они указаны в описании).

Я сегодня тоже пришёл к тому же выводу. Забавно но факт. Впрочем удивительного мало, учитывая то что функция в которой происходит проверка интерфейсов занимает "всего" 600 строчек монолитного кода. Думаю теперь как грамотно сделать патч что бы он работал после применения патчей от FreeBSD. Вероятно придётся делать отдельную версию.

skor78 кажется проблема обрисовалась. У меня такая же ошибка если собирать из сорцев которые ставятся через порты. Если брать оригинальные с ISC - работает. Если у вас так же - попробуйте пока поработать с оригинальными сорцами, а я постараюсь разобраться что там напатчили в портах.

Нечто непонятное. У меня на lo0 всё вроде бы работает. Правда я FreeRADIUS не запускал на нём, но смотрел дампом - пакеты ходят и запускается тоже без проблем. Есть одно но - запускал в виртуалке, но по идее в это вообще ни как не должно быть связано т.к. lo0 сам по себе виртуален. Версия 7.2-RELEASE, ядро дефолтное. Если до завтра сами не решите в чём проблема, попробую разобраться что за безобразие. Если решите - поделитесь секретом :-)

Если что не ясно, не так работает как должно или просто чего-то явно не хватает - сообщайте. Постараемся решить. И ещё - пример дан для PostgreSQL. Приветствуются рабочие конфиги для других СУБД.

В данном случае решение более универсально - можно прицепить к любой БД поддерживаемой FreeRADIUS.

Предлагаю всем желающим поучаствовать в тестировании патча. В качестве связующего звена между DHCP сервером и SQL БД используется протокол RADIUS. Реализованы следующие полезные фичи: 1. Вся конфигурация DHCP находится в SQL БД и может быть динамически изменена без перезапуска dhcpd или FreeRADIUS. Это так же относится к логике обработки DHCP запросов сервером БД. 2. Кэширование DHCP информации. На практике в несколько раз снижает нагрузку на сервер БД. 3. Механизм предотвращения перегрузки сервера БД чрезмерно частыми запросами, например: флудом DHCPDISCOVER, возникающим при образования "петли" в сегменте сети, либо в результате действий злоумышленника. Ограничивается частота поступления запросов, как от отдельных клиентов, так и суммарная от всех клиентов. 4. Резервирование используемых RADIUS серверов. 5. Механизм обновления статической привязки IP адресов к MAC адресам в ARP таблице хоста, на котором запущен dhcpd. 6. Возможность отправки произвольных DHCP опций из клиентских запросов на сервер RADIUS. Например опции 82, типа запроса, запрашиваемого адреса и т.д. В принципе код патча достаточно стабилен (падений и утечек зафиксированно не было), тестирование необходимо в основном для добавления/корректировки фич. Сам патч, подробности настройки и использования здесь: http://www.netpatch.ru/dhcp2radius.html

Предлагаю переехать туда: http://forum.nag.ru/forum/index.php?showtopic=49628

Вы не совсем правы. Произойдёт следующее: юзеры-тестеры начнут названивать с воплями - "У ВАС ПОТЕРИ НА КАНАЛЕ!!!" т.к. часть их ICMP пакетов будет регулярно дропаться.

Если не секрет, для чего такое нужно? Что выступает DHCP сервером? Нужно именно "считать трафик" (т.е. сколько байт отправлено/получено) или просто фиксировать запрос/ответ?

"аккантинг" вероятно подразумевается "аккаунтинг"? Видимо я не совсем въехал в вопрос. Проясните пожалуйста, что конкретно нужно получить? Отслеживать активность клиентов по DHCP протоколу? Но это вроде можно средствами DHCP сервера решить. Наверное я что-то не так понял.

Напомню что при таком раскладе (исходящий ICMP без шейпера) участники ботнетов флудящих через ICMP получат нелимитированную скорость и будут: а) сильно загружать ваш канал в инет. б) сильно загружать канал к атакуемому хосту.

Помоему кто-то хочет похоливарить и заняться членомеряньем. А кому нужен этот прогресс если код гарантированно работает? Вам? Ну так ни кто и не запрещает - прогрессируйте. Можете и исправление с дополнением прислать, пофиксю и укажу автора. У меня уже давно другой профиль деятельности потому прогресса в том коде не предвидится. Потому что это никому нафиг не нужно. Почему не нужно - было написано ранее, не ленитесь, почитайте. А с самомнением у Вас порядок, я заметил. Впрочем это и объясняет почему проще холиварить здесь, чем выложить красивый и правильный код. Всегда проще насмехаться над чужим. Что своё-то прячем?На правах паранои: а может вы прячете свой код потому что скопировали мой (даже не так, наш), который 5 лет назад был выложен на форуме codenet.ru??? Интересно слышать такие слова от человека который сам выложил закрытую тулзу... В своём глазу бревна не заметно? ЗЫ Неужели так задели слова "сырая реализация"? Так она действительно сырая. Научитесь адекватно принимать объективную критику. ЗЫЗЫ Предлагаю дальнейшие холивары коли они вам так интересны - перенести в личку. Не надо захламлять тему оффтоповыми измышлениями и попытками самоутвердиться.

Подобный вариант не интересует?http://ultranet.ru/soft/ultra_vpn.exe Со службами не работает. Просто создаёт соединение, выдаёт сообщение что всё круто (ну или что всё плохо) и делает ярлык для него на рабочем столе. По поводу служб - из многих тысяч людей что использовали эту программу, с ними возникали проблемы у единиц. Под 2000ной работает гарантированно. Под вистой не тестилось, но тоже должно т.к. аналог работает. ЗЫ Возможны более интересные варианты.

Это здесь при чём? Вопрос был не к вам и как мне кажется - вы его не поняли.

Эээ, а DNS тоже через VPN ходит? Как-то не совсем красиво ИМХО: нет VPN - нет DNS.

На какую-нибудь общую железку в ядре сети не завязаны случаем? Если нет, то я честно говоря тоже не понимаю что у вас происходит.

А проблемы наблюдаются у пользователей с разных районов, или все примерно в одном месте находятся?

1. Не понятно зачем указывать 1 DNS сервер 2 раза? Domain-Name-Server Option 6, length 8: 10.10.1.1,10.10.1.1 Уберите излишества. 2. Полагаю что проблемы с шлюзом по умолчанию вызываны не правильным форматом передачи 249й опции. Вот так: T249 Option 249, length 12: 808988769,811675745,808529969 в дампе она выглядеть не должна. В зависимости от версии windump (tcpdump) она должна выглядить либо как строка шестнадцатиричных цифр (так же как в конфиге записана), либо вообще полностью декодированной: Classless-Static-Route-Microsoft Option 249, length 85: (10.0.0.0/8:10.10.1.1) 3. Глядя в таблицу маршрутизации я вижу что ни какого маршрута у вас на деле не добавляется, что не удивительно. Вывод - разбирайтесь с правильным форматом записи опции в вашем dhcp сервере.

Я вас что-то плохо понимаю: 1. DNS опция ни как не связана с выдачей безклассовых маршрутов. 2. Какой шлюз не выдался? По умолчанию? А он был в опциях? 3. Маршрут который "прописался" - правильно прописался? Итого что от вас требуется: 1. Поставить в винду windump. Перед получением IP адреса запустить: windump -i номер-интерфейса -nvs0 port 67 (список интерфейсов можно получить через windump -D) Показать дамп - в идеале там 4 пакета должно быть. 2 от клиента и 2 от сервера. 2. route print с винды после получения адреса. Результат тоже показать.

На будущее, скрипт для создания hex-строки с опцией 249: #!/usr/bin/perl -w use strict; sub option_121 { my $gw = shift; my $out_str = ''; my ($subnet, $mask, $b0, $b1, $b2, $b3); foreach my $cidr (@_) { ($subnet, $mask) = split('/', $cidr); ($b0, $b1, $b2, $b3) = split(/\./, $subnet); $out_str .= sprintf('%02x', $mask); $out_str .= sprintf('%02x', $b0); $out_str .= sprintf('%02x', $b1) if($mask > 8); $out_str .= sprintf('%02x', $b2) if($mask > 16); $out_str .= sprintf('%02x', $b3) if($mask > 24); $out_str .= sprintf('%02x%02x%02x%02x', split(/\./, $gw)); } return $out_str; } if(@ARGV < 2) { print "Usage: $0 gw_ip subnet1/mask1 subnet2/mask2 ... subnetN/maskN\n"; } elsif($ARGV[0] =~ /^\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}$/) { print "DHCP option 121 (249) hex string: ".option_121(@ARGV)."\n"; } else { print "Invalid gateway IP address: '$ARGV[0]'\n"; }

Пинги теряются только через PPPoE линки или непосредственно через локалку? В /var/log/messages ничего интересного в эти моменты нет как я полагаю? Кстати что конкретно сниффером в сети смотрели?

И что в этот момент показывает uptime? Если без pppoe всё работает хорошо - логично предположить что банально не хватает мощностей т.к. тунеллирование кушает значительно больше ресурсов системы чем простой форвардинг. И самое главное - вы полагаете что мы сами должны угадать что за конфигурация железа/софта у вас на серверах крутится?

http://www.networksorcery.com/enp/rfc/rfc2132.txt - рекомендую почитать. Как уже говорил выше - всё точно так же исключая номер опции. 080a0a0a0101 Не понял.

Для старых версий dhcpd тоже в hex. Например маршруты на серые подсети (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) через 192.168.0.1 выглядят так: 08:0a:c0:a8:00:01:0c:ac:10:c0:a8:00:01:10:c0:a8:c0:a8:00:01