Alexey Gakalo писал(а):
Мы проверим вашу ситуацию. По результатам отпишемся в форуме.
Отсутствовал некоторое время, ответов не последовало. Печально.
Bigarov Ruslan писал(а):
Как я уже писал, если проблема на стороне нашего устройства, то мы исправим это.
Alexey Gakalo писал(а):
И наконец, в четвертых.По механизму техподдержки.
Хотелось бы еще раз для вас осветить механизм исправления недочетов.
Для того что бы разрабочики продукта могли исправить что то не понравившееся вам в прошивке,инженерам техподдержки необходимо детально изучить вашу ситацию и описать проблему происходящую с устройством , описать все внешние условия, при которых эта проблема проявляется.
То есть смоделировать ситуацию на стенде (с помощью точно такого устройства с той же прошикой).
Если такая проблема повторяется в 100% случаев,то запрос на исправление проблемы отсылается разрабочкам устройства.
Если же проблема "плавающая",т.е не повторяется на стенде,то исправления не будет ( потому что непонятно, что исправлять или вообще надо исправлять (когда проблема не в устрйостве)).
Именно так происходит в данном случае.Пока мы не можем смоделировать вашу ситуацию.Но работы в этом направлении ведутся.
Цитата:
Похоже таки время идет, а длинк не меняется. Кому повезло, все работает и полностью удовлетворяет, радуйтесь, если не повезло и что-то не работает, бороться бесполезно, проще найти продукт который работает от другого производителя. Это будет быстрее и нервы останутся целее.
Мы готовы к сотрудничеству,и признаем свои ошибки, если они есть.
А вы готовы?Если готовы, давайте следовать правилам форума и писать подробно :что как и где, c приведением необходимой технической информации.
А эмоции оставьте для других болталок.
Вернёмся к моей проблеме. Я опишу подробно её саму и как она проявляется и повторяется "в 100% случаев", т.е. является абсолютно не "плавающей".
Метод PPPoE имеет два чётких этапа работы: этап открытия PPP сессии и соответственно этап самого сеанса.
На этапе открытия происходит обмен 4-мя пакетами. Это PADI, PADO, PADR, PADS. Клиент, желающий открыть сессию отсылает широковещательный пакет инициации PADI. Получившие его PPP серверы высылают обратно пакет с предложением PADO. Этих предложений в общем случае может быть и несколько. Клиент выбирает один из серверов на своё усмотрение и направляет ему запрос PADR. В результате должен поступить пакет PADS с подтверждением и указанием номера сессии. Далее обмен данных идёт в рамках открытой сессии. Допустим по каким-либо причинам (PPPoE сервер провайдера просто не справляется с нагрузкой или в силу других обстоятельств) ответа так и не поступило.
Видно на этом этапе и возникает ошибка, описываемая на форуме не только одним мной. Дело в том, что как я выяснил из своих наблюдений, после некоторого числа неудачных PADI запросов сервер просто перестаёт отвечать "атакующему" на некоторое время. Проблема казалось бы найдена - перегруз, НО почему же в этих же условиях абсолютно работоспособными оказываются (как я уже писал) и другие модемы и клиент Windows? А это потому, что они дойдя до PADS и не получив его ответ, перепосылают именно PADR (как собственно и предписывает RFC 2516), а D-Link молчит или начинает запрос с самого сначала, т.е. с PADI. И в результате скоро оказывается "заблокированным" и в таком состоянии он всё шлёт запросы. У меня он подключается в лучшем случае часика через 2. А такое действие его работы противоречит RFC 2516 (я уже приводил этот отрывок выше):
Цитата:
8. Other Considerations
When a host does not receive a PADO packet within a specified amount of time, it SHOULD resend it's PADI packet and double the waiting period. This is repeated as many times as desired. If the Host is waiting to receive a PADS packet, a similar timeout mechanism SHOULD be used, with the Host re-sending the PADR. After a specified number of retries, the Host SHOULD then resend a PADI packet.
Кажется так:
8. Другие Соображения
Когда хост не получает пакет PADO в пределах определенного времени, он ДОЛЖЕН передать повторно пакет PADI и удвоить период ожидания. Это повторяется так много раз как захочет. Если хост ожидает получения пакета PADS, аналогичный механизм тайм-аута ДОЛЖЕН быть использован, с перепосылкой PADR. После определенного количества повторных попыток, хост ДОЛЖЕН затем передать повторно пакет PADI.
По поводу моделирования такой ситуации. Я делал следующим образом:
1. захватывал пакеты процесса подключения к серверу;
2. отключал dsl line;
3. в ответ на PADI отсылал PADO с учётом соответствия TAG Host-Uniq и наблюдал за происходящим.
4. повторял п.3.
P.S. Если бы вы знали как меня это бесит. 15 месяцев одно и то же.
А с ВолгаТелекомом вообще разговаривать бесполезно.
Вход
Регистрация
FAQ
Поиск
