lalex

добро. жду в аське.

как исправить ошибки "recv data answer error!", "recv login answer error!", "incorrect login" и "bad comand" при пополнении счета абонента через конфигуратор? в следствии пополнение не происходит и конфигуратор отваливается от сервера. при нажатии кнопки "обновить" всё реконектится и может работать нормально. в версии 2.407р1 такой ошибки не встречалось, она появилась в 2.408-rc2, тогда пришлось возвращаться на 2.407р1. неужели опять прийдется возвращаться?

всё решено. спасибо за помощь.

можно в принципе и так сказать. был бы рад любой конкретной помощи.

если нет любимого языка программирования? кусок примера можно привести?

требуемая задача: импортировать 300-400 пользователей, например из CSV-файла. в файле по колонкам будут разбиты: ФИО, группа, адресс, IP, логин, пароль, тариф (порядок можно изменить). кто что-то может подсказать по этому поводу?

404 по ссылке с первой страницы, можно автора попросить перезалить? могу дать возможность выложить на длительное хранение.

ух-ты.. думается после НГ поставлю... как доем все салаты с "шубой" с наступающим всех.

есть такое дело. генерирую до тех пор, пока не будет этих символов

и тем не менее он встречается. редко, но встречается. происходит как правило в том случае, когда один логин используется на 2х и более компьютерах. пользователь вытягивает кабель (авторизатор не отключая), переключает его в другой компьютер и подключиться уже не может. СТГ отвечает, что логин уже используется. сессия пользовательская не отваливается от сервака ни через минуту, ни через 12 часов. эта ситуация подтверждена на 2х серверах.

в последнее время обратил внимание на периодически вылезающий баг (2.407). пользователь не дисконектится автоматом и сессия его висит. при подключении пользователя заново сервер соответственно отвечает, что "такой логин уже используется". за последние сутки было 2 таких случая. раньше тоже периодически такой баг вылезал, но не придавал ему особого внимания.

действительно ли этот StatWritePeriod параметр отвечает за периодичность записи в файл stat? и как будет вести себя СТГ при 500 пользователях постоянно записывая эту информацию?

возникла мысль find-ом лазить в файл stat пользователя (БД - файловая). при достижении величины больше тарифного плана, то отключать пользователя. но как поступать, когда несколько тарифных планов с разной "абонплатой/объём трафика"? ЗЫ: я так понимаю ни у кого такой задачи не стояло. т.е. все (или большинство) просто продают трафик помегабайтно. у нас просто схема предоплаты 1го числа за определенный объём, а сверх лимита очень быстро деньги убегают.

Делал ли кто либо такую связку, реализовывал ли такую возможность при таковой ситуации? Т.е. - проплатил пользователь 300 грн, при тарифном плане 50 грн/мес, абонплата снялась согласно тарифному плану, остаток на счету 250 грн и при достижении своего порога (например 5 Гб) интернет отключался. ЗЫ: не очень удобно выходит, когда после достижения порога интернет считается по иному (помегабайтному) тарифу.

подтверждаю. в 406 этот баг присутствует (последний билд пока не ставил). каким образом происходит и по какой причине - неясно. бывает рандомно на разных логинах.. с периодичностью 1-2 недели. помогает только перезапуск СТГ.

начну с малого: - сегодня при переходе на новый месяц не у всех пользователей снялась абонплата и обнулился трафик. проблема имела место где-то у 1/3 пользователей (всего около 400 зарегистрированных). странно, но до этого стоял RС1 и с момента её выхода таких проблем никогда не наблюдал. раньше в конце месяца (30-31 числа) я регулярно перезапускал СТГ принудительно во избежания разного рода ошибок и пере этим делал бекап юзеров. сейчас этого не сделал - так-же в конфигураторе никак не может отработать сортировка по IP, если выбрать всех онлайн пользователей в фильтре. - при нажатии обно

что-то я не очень понял смысла написанного.

Требуется запретить выдачу динамического адреса для списка mac-адресов в локальной сети вида 192.168.1.0/24 правила вида: iptables -I INPUT -i eth0 -p udp --sport 68 --dport 67 -m mac --mac-source $MAC -j DROP или iptables -I INPUT -m mac --mac-source $MAC -j DROP не приводят к нужному результату, адреса по прежнему выдаются, а счётчик в iptables, говорящий о том, что правило сработало, исправно растёт. как решить вопрос?

возьми версию посвежее. эту например.

по адресу пишу или нет, но в последней версии конфигуратора (1.90.9) не работает (или работает по иной логике) скорее всего фильтр. по крайней мере если в фильтре вписать IP-адрес подключенного пользователя, то он его не отобразит. отображает лишь пользователя у которого стоит флаг "всегда онлайн" и вписан адрес вручную или конфигуратор не в состоянии выбрать из текущих подключенных пользователей нужного по IP-адресу, а выбирает только тех у кого вписан адрес? а если адреса раздаются по dhcp? как тогда быть?

а сюда можно их предоставить? для сравнения... может отыщутся общие "глючные" нюансы.

так дело в том, что все правила добавляющиеся в скрипте конекта, убираются в скрипте дисконекта и добавляется форвардное правило блокирующее адрес, с которого был инициирован дисконект.

Имею CentOS 5.2 и СТГ 2.4. юзеры ходят в интернет через транспарент прокси, натится несколько портов. несколько человек (5-6 где-то) умудряется качать при выключенном авторизаторе. т.е. стартуют закачку при включенном авторизаторе и, выключаясь, продолжают качать дальше. Самостоятельно воссоздать картину не смог, т.к. авторизатор чётко отрабатывает и меня дисконектит. при наблюдении за качающим юзером я смотрел и видел что скрипт дисконекта отрабатывает и в фаерволе появляются строки iptables -I FORWARD -i $eth_local -s $ip -j DROP iptables -I FORWARD -o $eth_local -d $ip -j DROP соответст

это в какой версии наблюдалось? и на какой конфигурации ПС?

этот ответ я нашел и в официальной справке. если параметр выставить - 2 или 10? на что он повлияет? каким образом выяснить в каких случаях нужно менять этот параметр и что означает "тормознутый скрипт"?