madf

Они с Max куда-то пропали давно. С 2009-го, кажется, не слышно.

Сейчас уже и при аварийном останове файлы скорее всего не потеряются. тогда я вылечил это переходом на store mysql а вообще уже давно вылечил все в корне сменив биллинг ) И что сейчас, если не секрет?

И как затерся: сам файл остался но пуст или файла нет совсем?

Версия? Сейчас уже и при аварийном останове файлы скорее всего не потеряются.

Может ему жена не уделяет внимания в связи с соцсетями, вот и просит. А то против жаны не попреш Значит как муж он не состоялся.

Да фигня все это. При желании любую блокировку можно обойти. Не провайдера это дело, социальные сети блокировать. Воспитывать правильно надо. Если родитель просит такое, значит как родитель он потерпел крах.

100 в онлайне - это совсем не большая база. 3000 в онлайне - большая, а 100 - тут даже mod_store_mysql может работать. Под "контролируемыми условиями" я понимаю дополнительное отладочное журналирование. По этому сразу спрашиваю об обновлении до 2.408 + мои патчи и о предполагаемом времени ожидания появления глюка. Без этого, к сожалению, поиск и исправление проблемы может затянуться на непрогнозируемый срок.

Если нужно будет воспроизвести проблему в контролируемых условиях - сколько придется ждать в среднем? День? Неделю? Месяц?

Проблема воспроизводится регулярно?

Нет, это просто какое-то целое число, уникальное для каждого пользователя.

Тогда он не получит и ALIVE_ACK и отключит юзера по тайм-ауту.

Нет. Это работает не так. Отключение авторизатора, в отличии от процесса авторизации очень простое: 1. Клиент шлет DISCONN_SYN. 2. Сервер переходит в фазу 4 и шлет DISCONN_SYN_ACK. 3. Клиент отвечает DISCONN_ACK. 4. Сервер снимает авторизацию и шлет FIN. Если п.3 не происходит - сервер возвращается в фазу 3, т.е. "авторизован". Аналогично работает и клиент. Это все гуд, но что конкретно мона сделать? может таймауты увеличить между этими событиями? или еще че? К вашей проблеме это не относится. Я просто пытаюсь тут доказать что предположения SpiderX и Романа о причинах проблемы

Нет. Это работает не так. Отключение авторизатора, в отличии от процесса авторизации очень простое: 1. Клиент шлет DISCONN_SYN. 2. Сервер переходит в фазу 4 и шлет DISCONN_SYN_ACK. 3. Клиент отвечает DISCONN_ACK. 4. Сервер снимает авторизацию и шлет FIN. Если п.3 не происходит - сервер возвращается в фазу 3, т.е. "авторизован". Аналогично работает и клиент.

У юзеров в базе IP прописаны? Или у всех "*"? Т.е. я не вижу ничего плохого: авторизнулся юзер через авторизатор, сработал OnConnect, адрес попал в файрвол. Авторизнулся он-же через VPN - т.к. уже авторизован то OnConnect второй раз работать не будет. Отключится авторизатор - будет продолжать работать через VPN. Отключится VPN - будет продолжать работать через авторизатор. Но как только закончатся деньги, не важно уже как был авторизован и сколько раз, - сработает OnDisconnect и юзер работать перестанет. В чем проблема? Единственную проблему вижу если адреса назначаются автоматом - тогда во

Все равно непонятно. Как у вас файрвол работает? Ну тогда надо говорить не об авторизации а о состоянии: подключен или нет. Это разные вещи.

Не понял про айпишник и почему это кому-то выносит мозг. GetConnected, к стати, это не проверка на авторизацию. Когда юзер онлайн GetConnected возвращает 1 иначе 0. Так что с задачей он справляется. Юзер может быть авторизованным но не онлайн. GetConnected вернет 0. Хотя юзер авторизован. Почему так?

В скрипте только ipfw table X add $IP и ifw table X del $ip. Там не может быть проблема Да ладно! А код возврата ipfw проверяется?

Не понял про айпишник и почему это кому-то выносит мозг. GetConnected, к стати, это не проверка на авторизацию.

Не вижу здесь проблемы. СИстема как раз так построена что можно авторизоваться одновременно из разных мест. Не-ве-рю! тогда как обьяснить следующее клиент подключился , его IP был добавлен в таблицу файрвола клиент отключился , но из таблицы не удалился. в старгайзере он офлайн, не залип ничего подобного , может снова подключится и отключится и после этого интернет отрубится , т.е. удалится из таблицы. Случается крайне редко, но случается Проблема в скриптах.

Можно более подробно?

Не-ве-рю!

Потому, что проблема 100% повторяема из месяца в месяц 28 числа, после ротации IP адресов в сам знаешь какой сети А какое отношение к этому имеют одновременные дисконнекты? Если бы проблема была в этом - она проявлялась бы чаще, особенно на участках сети с потерями и "семафорами" у абонов. А в сам знаешь какой сети проблема проявляется только при смене IP, при которой дисконнект... Ммм... Достаточно побочное явление. Да и вообще, имеет место только для InetAccess. А с AO проблема сходного характера. Так что скорее всего проблема где-то глубже.

Я про вланы и интерфейсы писал чтобы показать кривость решения. Ваш вопрос я помню. Как на счет обновления до 2.408? Крайней вероятно. С какого перепугу?

Сама возможность привязать sgauth к локальному адресу мне не кажется чем-то "кривым" - это очень правильная и логичная функциональность, особенно с учетом того что привязка к локальному порту уже и так есть. Кривым я считаю путь к решению проблемы - вся эта чехарда с поднятием интерфейсов, пробросом вланов, перекидыванием IP для пользователя туда и обратно - это кривость. Бороться с проблемой можно и нужно, но у меня пока нет решения.

как то криво так поступать а если завис не один пользователь ? подтверждаю глюк 408 версии .. тоже наблюдается .. даже с файловой базой данных, слоник не причем Это ж workaround, он обычно кривой. Я бы очень удивился если бы тут была замешана БД.