freeradius 3

[Efendy]

Не надо апдейтить статические айпи, нахрена впустую ресурсы тратить (запись на диск). Попробуй select 1;

[fet4]

Не, пишет    -1 sql
No additional quires

и не работает

[Efendy]

Ну тогда просто убери AND type = 'dynamic' - пусть апдейтит и статические

[kosmich]

У тебя тоже ошибка "RADIUS: rad_send_request for user 'ррр_test' failed: No valid RADIUS responses received"? Чтоб мы не искали ошибку kosmich по твоим логам.

Нет такого не было все чисто.

Так у меня mpd а не аксель.

Стас какое мне решение применить ?
Проверю на мпд сегодня.

[Efendy]

Та суть не в pppoe-сервере, а в радиусе.  Попробуй убрать AND type = 'dynamic'

[sergey104]

изменил процедуру

Код:

DROP PROCEDURE IF EXISTS `radupdate`;
DELIMITER $$
CREATE PROCEDURE `radupdate`(IN login VARCHAR(64), IN ip VARCHAR(16), IN properties VARCHAR(255))
BEGIN
  DECLARE usr_id INT;
  DECLARE usr_ip VARCHAR(15) DEFAULT NULL;
  SELECT id INTO usr_id FROM users WHERE name=login LIMIT 1;
  SELECT get_ip(usr_id) INTO usr_ip;
  CALL set_auth(usr_ip, CONCAT('mod=pppoe;',REPLACE(properties,':','')));
  UPDATE users SET id=usr_id WHERE id=usr_id LIMIT 1;
END$$
DELIMITER ;

пока работает

[kosmich]

Процедура в сообщении выше, статика работает.

Та суть не в pppoe-сервере, а в радиусе.  Попробуй убрать AND type = 'dynamic'

Суть в том что только мпд матерился, на ответы от радиуса.

Эта строка есть только в процедуре для ДХЦП. Если ее убрать, выдает левый айпи, а в биллинге отображается "старый".

Код:

AND type = 'dynamic'

5-я страница, что только двое-трое столкнулись с этой проблемой на PPPoE статике ?

[fet4]

Да. В set_auth в конце есть UPDATE. Приводим его к виду.

Код:

    UPDATE ip_pool SET `release` = UNIX_TIMESTAMP() + 3600
        WHERE ip = INET_ATON(usr_ip) LIMIT 1;

И статика начинает работать.

radupdate менять не нужно, тем более если он у Вас свой. И это проблема не сервера доступа, а походу новая логика freeradius 3, которая не дает поднять сессию без должного ответа мускула.

[kosmich]

Да. В set_auth в конце есть UPDATE. Приводим его к виду.

Код:

    UPDATE ip_pool SET `release` = UNIX_TIMESTAMP() + 3600
        WHERE ip = INET_ATON(usr_ip) LIMIT 1;

И статика начинает работать.

radupdate менять не нужно, тем более если он у Вас свой. И это проблема не сервера доступа, а походу новая логика freeradius 3, которая не дает поднять сессию без должного ответа мускула.

Пока у нас все общее, процедуры из документации тоже.
Стас указал, где поменять, там и поменял. Указанная строка есть только в процедурах для PPPoE.
Не понял только, что можно с вариантом

Код:

SELECT 1;

его вместо предложенной строки UPDATE users SET id=user_id WHERE id=user_id LIMIT 1; можно использовать ?

Лучше пусть Стас внесет ясность, можно и нужно ли менять там, где ты предлагаешь, с точки зрения производительности, на достаточно высоких нагрузках, или какие еще варианты можно и нужно ли проверить ?

[Efendy]

• Эта проблема связана только с аккаунтингом, если он у тебя используется, то значит используется процедура  radupdate.
  
• Для третьего радиуса необходимо, чтобы эта процедура сказала радиусу, что она затронула несколько строк в базе
• Поскольку в этой процедуре последним вызывается set_auth, то инфа по затронутым строкам берется из последнего действия set_auth, а там идет изменение времени релиза ip, но только для динамики. Поэтому мы пришли к варианту, что ладно, пусть апдейтятся не только динамические - для статических нет смысла апдейдить, но зато просто радиус будет видеть, что есть какой-то результат по затронутым строкам
• Сперва я хотел предложить использовать SELECT 1 для сообщения о количестве строк - это легкая операция, но она не привела ни к чему хорошему - 3й радиус считает, что select должен вернуть имя sql. Вопрос "какого хера?" Просто так захотелось? Ладно. Вариант с SELECT отпал. Не юзаем его!
• UPDATE users SET id=user_id WHERE id=user_id LIMIT 1 я предложил использовать в самом конце radupdate поскольку не факт, что во всех radupdate, что тут встречались последним будет CALL set_auth, поэтому лучше точно быть уверенным, что radupdate вернет "затронутое количество строк". Последний sql бессмысленный, он говорит измени поле так, чтобы оно стало точно таким же как и было. Т.е. по факту ничего в базе не меняется (хотя вот щас подумал, что мускул тупой может и лочить в этот момент таблицу, я уже на воду дую, так что может стоит апдейтить совершенно левую таблицу)

[tom]

Так до чого в решті решт прийшли? Ставим UPDATE?

[kosmich]

Так до чого в решті решт прийшли? Ставим UPDATE?

Да. Проверил на стендах и в бою.

Код:

DROP PROCEDURE IF EXISTS `radupdate`;
DELIMITER $$
CREATE PROCEDURE `radupdate`(IN login VARCHAR(64), IN ip VARCHAR(16), IN properties VARCHAR(255))
BEGIN
  DECLARE usr_id INT;
  DECLARE usr_ip VARCHAR(15) DEFAULT NULL;
  SELECT id INTO usr_id FROM users WHERE name=login LIMIT 1;
  SELECT get_ip(usr_id) INTO usr_ip;
  CALL set_auth(usr_ip, CONCAT('mod=pppoe;',REPLACE(properties,':','')));
  UPDATE users SET id=usr_id WHERE id=usr_id LIMIT 1;
END$$
DELIMITER ;

h t t p://nodeny.com.ua/wiki/index.php/Freebsd_%2B_Freeradius3_%2B_Nodeny_Plus
Стас, может необходимо и в документации поправить ?

[Efendy]

h t t p://nodeny.com.ua/wiki/index.php/Freebsd_%2B_Freeradius3_%2B_Nodeny_Plus
Стас, может необходимо и в документации поправить ?

Уже забыл о чем мы тут спорили, нужно для пппое добавить строку UPDATE users SET id=usr_id WHERE id=usr_id LIMIT 1;? Добавил

[Cell]

Столкнулся с вот такой фигней на на этом долбаном фрирадиус3
Ума не приложу с чем это может быть связано. Вроде перекликается с последней темой но как-то не очень.
При всем при этом  нужно добавить, что сессия на сервере висит 17 суток и не отваливалась ни разу.
Скрин прилагается.

[Cell]

я в н+ отключение по команде stop не использую, честно говоря я забыл почему, возможно чтобы риконнекты не забивали таблицу авторизаций или не высасывали пул ip. Пусть авторизация пропадает по таймауту, 2 минуты таймаута - это разве много?

Я думаю, процедуру radstop нужно вернуть в коробку, а ее использовать, каждый решает сам.
Лично меня ТП замучили уже, ибо звонит абон с некой проблемой, оператор ему помогает и просит перезагрузить свое обоудование,
а в логах авторизаций либо нечего не поменялось, либо затерлись параметры последней сессии(ип, мак, нас, сервис-нейм и.т.п.)
и даже если будет засорятся бд реконнектами, будет локализирована проблема с оборудованием Прова либо Абона.

Короче не знаю где лучше разместить это дело. Процедура radstop для pppoe со статическим пулом адресов. Удаляет авторизациию, заносит данные о закончившейся сессии в таблицу логов авторизаций. Мне, как и 90% админов этого будет достаточно чтобы не сводить с ума ТП.

Код:

DROP PROCEDURE IF EXISTS `radstop`;
DELIMITER $$
CREATE PROCEDURE `radstop`(IN login VARCHAR(64))
BEGIN
  DECLARE usr_id INT;
  DECLARE ipt INT;
  DECLARE st INT;
  DECLARE prop TEXT;
  SELECT id INTO usr_id FROM users WHERE name=login LIMIT 1;
  SELECT ipn,start,properties INTO ipt,st,prop FROM v_ips WHERE ip=get_ip(usr_id) LIMIT 1;
  INSERT into auth_log (id,uid,ip,start,end,properties) VALUES (NULL,usr_id,ipt,st,unix_timestamp(),prop);
  DELETE FROM auth_now WHERE ip = get_ip(usr_id) LIMIT 1;
END$$
DELIMITER ;

Что же касается поста выше - то причина понятна и проста: freeradius3 - синоним слова ГОВНО. На пока отказываюсь от него в пользу старой версии. (собираю из исходников)