@UBNT-BruceG

Это баг. Я жду его исправления уже около 6 месяцев.  
Баг №1: UAP не реагирует на атрибут Idle-Timeout. Он должен завершать сессию пользователя и отправлять пакет Session Stop на RADIUS-сервер с параметром Acct-Terminate-Cause, установленным в Idle-Timeout. Сейчас этого не происходит, и у нас остаются подвешенные сессии, что вызывает кучу проблем и раздражения. Конечно, он также должен разъединять молчащий клиент.  
Посмотрите сюда:  
http://freeradius.org/rfc/rfc2866.html#Acct-Terminate-Cause  
http://freeradius.org/rfc/rfc2865.html#Idle-Timeout  

P.S. Чтобы увидеть проблему в действии, не обязательно иметь ноутбук с аппаратной кнопкой включения/выключения Wi-Fi. Иногда, когда я отключаю Wi-Fi на iPhone 6 SE, не вижу пакета Accounting Stop от UAP. Но скорее всего, это проблема именно iPhone. Другие устройства я не проверял. В любом случае, UAP всё равно должен завершать бездействующие сессии. Интересно, что случится, если пользователь сначала залогинится, а потом выйдет из зоны Wi-Fi — вот вам задачка.

Баг №2: Когда установлено Session-Timeout, UAP завершает только первую сессию, а вторая длится вечно.

Спасибо за помощь.

С конфигурацией моего RADIUS-сервера всё в порядке. Проблема в прошивке UAP. Её нужно исправить, и я уже довольно долго жду, когда это сделают.

1) Мой вопрос был не про мою собственную конфигурацию. Я спрашивал, почему вообще нужно что-то редактировать? Разве UAP не должен получать информацию о пользователе с RADIUS-сервера и вести учёт соответственно? То есть, зачем мне что-то менять на самом RADIUS-сервере? UAP же спрашивает, что делать с пользователем, а RADIUS-сервер отвечает, читая данные из базы, правильно? После этого UAP должен выполнять то, что ему сказал RADIUS-сервер. Если он этого не делает, значит, с самим UAP что-то не так. Для справки: RADIUS-сервер только сообщает, он ничего не контролирует. Контроль — это дело UAP, а сейчас он свою работу не выполняет.

3) Пожалуйста, протестируйте это с атрибутом Idle-Timeout. Это очень просто. Возьмите один из ноутбуков, на котором можно отключить Wi-Fi кнопкой на корпусе. Установите для пользователя Idle-Timeout на 120 секунд. Запустите tcpdump на сервере. Подключитесь к Wi-Fi с ноутбука. Наблюдайте обмен пакетами между RADIUS-сервером и UAP. Затем отключите Wi-Fi, сдвинув кнопку на корпусе в положение «выключено». Подождите 130 секунд. И потом скажите, видите ли вы какие-либо пакеты с остановкой учёта (accounting stop packets). Удачи!

Большое спасибо за ответ. Однако это вызывает у меня ещё несколько вопросов:  
1) Почему UAP требует, чтобы я внес это изменение в файле политики FreeRADIUS? У меня уже есть этот атрибут в таблице radreply, и я знаю, что FreeRADIUS его читает и отправляет на UAP. Разве UAP не должен получать информацию с RADIUS-сервера и действовать согласно ей?  
2) Почему выставлять Session-Timeout на 60 секунд? Это значит, что будет инициироваться повторная аутентификация каждую минуту!  
3) Настоящая проблема не в Session-Timeout. Настоящая проблема в том, что UAP не учитывает атрибут Idle-Timeout. Он должен завершать сессию пользователя после X последовательных секунд простоя. Есть ли у вас решение для этого?  
Прости, друг, но в плане RADIUS-учёта UAP проваливается просто полностью.

На самом деле проблема с Session-Timeout немного в другом. UAP завершает первую сессию, но не вторую; то есть вторая сессия может длиться бесконечно. Но это довольно мелкая проблема. Сам атрибут Session-Timeout не особо полезен. Его даже можно считать раздражающим, потому что всё, что он делает — заставляет пользователя переподтверждаться каждые Х секунд. На самом деле вам нужен атрибут «Idle-Timeout». Он говорит UAP завершать сессии после Х секунд бездействия подряд. И вот тут начинаются настоящие проблемы. UAP просто не соблюдает атрибут Idle-Timeout! Но и это ещё не всё! UAP ужасно ведёт учёт RADIUS. Иногда неверно считает трафик на загрузку и выгрузку, а иногда отправляет искажённые и неполные пакеты окончания учёта. Я уже связался с командой разработчиков прошивки и пытаюсь решить эти проблемы. Надеюсь, скоро услышим от них новости.

Проверено на последней версии 4.4.11 (Controller) и UAP версии 3.7.37. Таймаут сессии по-прежнему не работает. Пожалуйста, Ubiquiti, дайте хоть какой-то ответ, будет ли эта функция реализована. Она нам нужна, и если нет — придётся искать другие устройства.