524Т, но ситуация такая же.....
прокомментируйте плз:
524Т посылает валидные логин/пароль, но сессия не устанавливается по причине отрицательного баланса. Спустя n-е число часов баланс в норме, но 524 уже не предпринимает попыток передать логин/пароль.

И присоединясь к автору темы - предложите мне вариант действий в такой ситуации, когда количество линков - за сотню, а площадь охвата 25тыс кв.км.?

Аналогичный вопрос решал я за неделю до вас
viewtopic.php?t=37918
Тоже менял прошивки по совету Длинковцев, потом получил ответ что это не бага а фича и что исправляться она не будет
viewtopic.php?t=38190
То что модемы галимые и предназначены для моно юзеров стоять на столе рядом с компом, что бы не далеко ходить если нужно передернуть, это факт. Моно юзеров устраивает цена и необходимость передергивать модем регулярно (пару раз в неделю), часто они вобще выключают его вместо с компом. Вобщем, для тех кому нужна надежная автономная работа не требующая вмешательства, эта модель точно не подходит.
Смотрел я 500Т с прошивкой V1. В ней есть регулировка количества попыток конекта и интервал в интерфейсе настройки PPPoE, и помоему модем выполняет эти настройки. Можете перепроверить. Но помоему там есть другие баги, я точно не исследовал каике именно, но работа модема мне не понравилась, я его пока отложил.

Тут на форуме я неоднократно спрашивал, что выбрать для млучая если нежна надежность ? Представители длинк мне не ответили. Видать не знают таких моделей.

Я начал сам читать всякие форумы и эксперементировать, что есть под рукой. В 2500U этой "фичи" нет, не факт что ее не сделают в следующих версиях, при таких явных защищениях правильности метода. Но там есть другие баги. Отваливается DNS форвардинг. Еще одна проблема может быть решится включением Keep Alive, но на понимание этого нужно время.
на форуме
http://www.kharkiv.ukrtelecom.ua/ua/for ... um.php?f=9
обсуждаюется работа модемов, в том числе и надежность. Можете почитать. Я думаю что и на других форумах тема надежности не забыта.

вот специально достал коробку
"For Home and Business"
ни в коей мере не End User даже не SOHO.

Это называется обман покупателя.
Говорится что хорошее устройство, много может, а когда выясняется что половина не работает и то что работает имеет каличную логику, говорится, что вы хотели от модема на $30 ? Это же для энд юзера. И как будто подразумевается что ЭкдЮзер не может быть организаций из 100 человек, и так же подразумевается что эндюзеру не ломает передергивать питание модему регулярно для возобновления работоспособности.
Странно что Длинк не избавляется от этих недостатков с течением времени. Да, дураков (в смысле не обладающих достаточной информацией) много, и организации одной покупки (как голимые магазины объманывающие покупателей в свойствах товара так и производители) пока процветают.

Давайте вместе разберемся в создавшейся ситуации.
К примеру, мы имеем следующую схему:
модем<--->терминирующее устройство (PPPoE сервер)<--->аутентификатор

Допустим, аутентификатор находится в нерабочем состоянии.
Когда от модема приходит запрос на аутентификацию, но никаких подтверждений об успехе или провале аутентификации не возвращается, модем просто до бесконечности будет ждать ответа от аутентификатора. В такой схеме, терминирующее устройство обязано ответить модему следующим образом: Authentication Fail (так как аутентификатор недоступен и для терминирующего устройства). После этого должна снова начаться Discovery stage, чего собственно не происходит и модем продолжает ждать ответа.
Это связано с тем, что (скорее всего) на стороне провайдера выставлен очень большой тайм-аут на подтверждение Authenticate запроса. Когда этот таймаут истечет, после "поднятия" аутентификатора будет дан ответ модему об успехе либо провале аутентификации.

По поводу возможности задания временного интервала и разрыва сессии со стороны модема я запрошу HQ. Следите за темой.

_________________
С уважением, Давыдов Денис.

да все происходит
Jan 1 12:01:30> pppd 2.4.3 started by root, uid 0
Jan 1 12:01:30> Connect: ppp0 {--} nas0
Jan 1 12:02:00> No response to PAP authenticate-requests
Jan 1 12:02:00> Connection terminated.
Jan 1 12:02:01> pppd 2.4.3 started by root, uid 0
Jan 1 12:02:01> Connect: ppp0 {--} nas0
Jan 1 12:02:31> No response to PAP authenticate-requests
Jan 1 12:02:31> Connection terminated.

Но ровно 5 раз. что совсем не логично.
Вот если-б было password error - ту спорно - нужно ли продолжать автоматические попытки.

кстати - возвращаясь к подсчету траффику на порту DSLAM и 5 попыток чтоб траффик не накапал? вот ради интереса - а какой провайдер считает траффик не проводя авторизацию?
это вообще ненормальная ситуация. авторизация не прошла, абонент не установлен. о какой тарификации может идти речь?
я лично работаю более чем с 30 провайдерами в разных города, предоставляющими доступ по aDSL. У всех тарификация траффика идет в пределах поднятой ppp сесии. Причем у большинства провайдеров логин/пароль могут быть использованы вообще на любом порту подключенном к сети провайдера.

У меня другая ситуация. Повторюсь кратко. Если быстро дернуть питание, модем начинает попытки авторизароваться пока предидущая сессия у провайдера еще не отвалилась. Да, выдатеся
Jan 1 12:00:42> pppd 2.4.3 started by root, uid 0
Jan 1 12:00:42> Connect: ppp0 {--} nas0
Jan 1 12:00:44> PAP authentication failed
Jan 1 12:00:44> Connection terminated.
(по идее естественно отвечать failed если конекшен с таким логином активен) но это продолжается всего одну минуту включая время перезагрузки, и за это время модем умудряется исчерпать все (5) попытки авторизации. Да будь попыток хоть 10 или интервал секунд 30, все бы было нормально, а так страдает вся страна с провайдером Укртелеком.
Я думаю у многих есть подобная проблема, просто на это не напарывались, чаще встречается другие проблемы. Я случано напоролся, перегрузил модем, увидел что он не сконектился, перегрузил еще раз, и все заработало, следующий перегруз, аналогично со 2-го раза, посмотрел в лог что происходит, и офигел.
Опять таки, Укртелекому предлогалось вообще не отвечать в этом случае (чего быстро реализовать не могут) на запрос авторизации, но и в этом случае модем ограничивается всего 5-ю попытками. Может быть для случая случайной перезагрузки это бы помогло, времени на "No response to PAP authenticate-requests" уходит больше и 5 попыток бы хватило, но есть другие случаи.
Вот когда не поднялся 2500 возможно из за не включенного Keep Alive, 500Т упал бы, исчервал свои 5 попыток (там как раз был не ответ авторизации) и то же бы настал ступор.
Я тоже задавал вопрос, кому считается трафик до авторизации PPPoE, или к кому будет производится авторизация PPPoE если провайдер считает трафик без авторизации ? Или есть такие провайдеры которые считают клиенту и берут деньги за не TCP/IP (Ethernet или ATM) трафик на порту без авторизации но тем не менее требуют авторизации по PPPoE ? Огласите весь список пожалуйста !

To All

Я сделаю запрос в HQ по поводу попыток аутентификации и введения в настройку модема настраиваемого временного интервала, по истечение которого модем сам будет drop'ать "безответную" сессию.

По поводу списка провайдеров:
Я не буду приводить этот список из политических соображений, но подсчет трафика путем снятия статистики со счетчиков интерфейсов DSLAM по SNMP действительно практикуется. PPPoE используется только для того, чтобы открыть абоненту доступ в Интернет.

_________________
С уважением, Давыдов Денис.

Да сделайте хоть что-нибудь, а лучше просто верни стандартную настройку в количество попыток и интервал между ними, как в первой версии.
А что, действительно провайдер может насчитать трафик при том что абонент в интернет вообще не выходил ? И вообще, трафик Ethernet или ATM (не знаю что там железяка считает, не TCP/IP точно) значительно превышает трафик TCP/IP. Получается клиентов дурят.
У нас провайдеры считают как правило TCP/IP тафик по нескольким направлениям по разной цене, домашний/локальный, городской, внутри страны и забугорный. Считать абоненту весь Ethernet бродкаст который может погнать его сетевуха через модем, это конечно очень оригинально.
А сколько байт пробегает при попытке авторизации ? С теперяшними ценами на трафик, если попытки делать не как из пулимета а с приличным интервалом, хотя бы секунд 10, я думаю стоимость этого трафика будет никак не заметна, и сравнима с другим паразитным трафиком выплевываемом сетевухой.
Помоему проблема трафика надумана. Вот то что модем делает попытки без интервала (см.приводимые мной и другими логи), что может приводить к перегрузке систем авторизации провайдеров, не смотря на <lcp_echo_failure>10</lcp_echo_failure><lcp_echo_interval>60</lcp_echo_interval>, это таки да, не правильо и надо исправлять а не говорить что это исправляться не будет, и что это фича. Интервал 60сек это наверное всетаки много (или там милисекунды выставлены ?), вот секунд 10-30 было бы в самый раз.
А еще, есть всякие алгоритмы динамического изменения интервала, чем долше не можем сконектится тем больше интервал, сначала он 5 сек (не 0 как у вас), через час - минута, а через 5 часов - минут 5, это вообще никого не напряжет, и настройки делать не надо и сконектится всегда сможем, хоть через пол года, проверяя востановление раз в час.
Но вставание модема в ступор, это _крайне_ не првильно !!! Какому глупому Китайцу пришло такое в голову ! А тем более всего 5 попыток без интервала. Я думаю что это просто ошибка, которую вы непонятно почему обозвали фичей и защищаете. Приходится много тратить времени что бы развеять ваши заблуждения. А оно у нас денег стоит. В результате происходит повышение качества ваших изделий за наш счет. А это уже не правильно. Мы платим деньги за изделия да еще и тратим деньги на повышение их качества. Я понимаю если бы по нашему сигналу вы нашли и устранили проблему, так вы еще и сопротивляетесь, отправляете нас по ложному пути и т.п. методами увеличиваете наши затраты. Ужаз.

Денис, 20 дней уже прошло. а мы всё ждем...

Над этим работают в HQ.
Точную дату выхода прошивки я назвать не могу, так как для меня эта информация пока недоступна. Я ожидаю прошивку также как и Вы.
Как только будут новости по этому поводу - я обязательно сообщу.

_________________
С уважением, Давыдов Денис.

и продолжаем ждать...