Радиус отключен.

Судя по его предыдущему посту, где он смог вызвать сбой Radius Listener, я бы сказал, что у Radius Listener есть проблемы… Быстрый просмотр его поста позволяет мне рискнуть и предположить, что MT не реализовал RFC полностью или даже не реализовал его вовсе. Однако это легко проверить. Попробую поиграть с этим на выходных и, возможно, отправлю MT подробный отчет об ошибке, чтобы они исправили это в следующей версии. Учитывая, что Radius Listener падает при получении невалидных запросов, у меня уже возникают тревоги по поводу переполнения буфера. Похоже, здесь задействованы в основном три проблемы: 1 - MT принимает невалидные запросы. Согласно RFC, при получении невалидного запроса необходимо возвращать код ошибки 404. MT, в RFC есть целый ряд кодов возврата ошибок, я не знаю, что происходит в коде, но пожалуйста, посмотрите на него. 2 - Я почти уверен, что когда DM не выполняется должным образом, это связано с двумя проблемами: 2.1 - MT получает невалидный DM (например, пакет DM, не содержащий всей необходимой информации), или 2.2 - MT не обрабатывает отключение / завершение работы интерфейса должным образом (сейчас я ставлю на обе эти проблемы). Нужно помнить, что MT должен найти интерфейс для отключения, основываясь на предоставленной вами информации! Если вы предоставите неверную информацию, он не отключит правильный интерфейс (если вообще отключит какой-либо). Если вы не предоставите достаточно информации, он не сможет найти интерфейс для отключения или, что еще хуже, отключит не тот интерфейс. Чем больше информации вы ему предоставите, тем больше шансов, что MT найдет интерфейс и отключит его должным образом. Я здесь никого не нападаю (по крайней мере, я надеюсь, что MT так не подумает), но если это можно сделать, исправить и признать стабильным (чего я в настоящее время не вижу), то это будет отличная функция. В настоящее время я крайне нехочу её использовать из-за таких проблем. RFC довольно скудный, эта «функция» относительно новая (дата публикации июль 2003 г.), и поддержки, а также информации о ней не так много, потому что она такая новая… Со временем все, должно быть, наладится. Если кто-то запускает это и хочет попробовать… Посмотрите мой предыдущий пост и попробуйте DM с правильно отформатированным запросом, предоставив как можно больше информации. Я бы сказал, постарайтесь включить все атрибуты в session-identification, которые MT поддерживает.

Окей, MT, видимо, нужно разбираться с этим. Однозначно есть ошибка в сервисе внутри MT. Оно не должно вылетать, а должно возвращать NACK (Не подтверждено) с ошибкой 404 (Неверный запрос). Похоже, MT просто закодировали части RFC, которые им нужны, и остальное проигнорировали. Теперь это можно считать багом, IMHO. Избавьте меня от пота в это ужасное лето, чтобы не сидеть и потеть в серверной, ковыряясь с Mikrotik и Radius. Просто на всякий случай, если MT не заметит этого на форуме, может, лучше написать в поддержку support@mt, хотя я уверен, что от MT скоро будет ответ здесь.

Просто небольшая проверка концепции: MT: requests: 0
 bad-requests: 0
         acks: 0
         naks: 0 Сейчас отправляю невалидный Disconnect (NAS-IP-Address указан неверно): Отправка Disconnect-Request с id 135 на 198.18.60.1:1700
       NAS-IP-Address = 198.18.60.2
       Framed-IP-Address = 00:00:00:00:00:00
rad_recv: Disconnect-NAK пакет от хоста 198.18.60.1:1700, id=135, length=45
       Error-Cause = NAS-Identification-Mismatch
       NAS-Identifier = "wsmd-core02"
       NAS-IP-Address = 198.18.60.1 MT Stats: requests: 0
 bad-requests: 1
         acks: 0
         naks: 0 Пока что все хорошо, хотя NACK должен был вырасти, так как запрос не был плохим, он просто был некорректным… По моему мнению, BAD = неверный синтаксис и тому подобное, но это дело вкуса, как говорится. Теперь отправляю тот же запрос, но с правильным NAS-IP-Address. Отправка Disconnect-Request с id 144 на 198.18.60.1:1700
       NAS-IP-Address = 198.18.60.1
       Framed-IP-Address = 00:00:00:00:00:00
Повторная отправка Disconnect-Request с id 144 на 198.18.60.1:1700
       NAS-IP-Address = 198.18.60.1
       Framed-IP-Address = 00:00:00:00:00:00
Повторная отправка Disconnect-Request с id 144 на 198.18.60.1:1700
       NAS-IP-Address = 198.18.60.1
       Framed-IP-Address = 00:00:00:00:00:00 Timeouts… MT Stats: requests: 0
 bad-requests: 1
         acks: 0
         naks: 0 Служба Radius listener умерла. Она больше не принимает никаких запросов, пока служба не будет отключена и снова включена.

BAD означает, что общий секрет (или сигнатура пакета) оказался неверным. Запрос на отключение (Disconnect-Request) не сработает с PPPoE и PPTP, потому что в текущих версиях есть проблема, которую исправят в следующем релизе.

Включи отладку, логи радиуса, там увидишь, что происходит. Если хочешь отправлять с другого адреса, добавь этот адрес как ещё один сервер радиуса (неважно, будешь ли ты его использовать).

Вам нужно отправить идентификатор NAS, один из: NAS-IP-Address, NAS-Identifier или NAS-IPv6-Address (который не поддерживается MT). Затем вам также нужно отправить идентификатор СЕССИИ, один (или несколько): User-Name, NAS-Port, Framed-IP-Address, Called-Station-Id, Calling-Station-Id, Acct-Session-Id, Acct-Multi-Session-Id (не поддерживается MT), NAS-Port-Type, NAS-Port-Id, Originating-Line-Info (не поддерживается MT), Framed-Interface-Id (не поддерживается MT), Framed-IPv6-Prefix (не поддерживается MT). Соберите эти данные, сформируйте запрос и отправьте его в MT. Типичный запрос на отключение PPPoE-соединения может выглядеть примерно так: NAS-IP-Address = this.is.the.ip.of.my.NAS
 User-Name = piet@somewhere.nice
 Acct-Session-Id = 81200000
 Calling-Station-Id = MAC:Address:Of:PPPOE:Client
 Framed-IP-Address = this.is.the.ip.of.the.user Это будет правильно отформатированное сообщение об отключении, включающее РАЗЛИЧНЫЕ проверки, чтобы MT отключал только одно единственное правильное соединение. Все эти значения получены из каждого обновления учёта, которое получает RADIUS-сервер, вся информация доступна RADIUS-серверу, вам нужно просто отправить правильные данные обратно. Давайте лучше убедимся, что мы получим правильную информацию на этом форуме.