Имя пользователя:
Пароль:
 | Правила  

Компьютерный форум OSzone.net » Клиентские ОС Microsoft » Microsoft Windows 7 » Интернет - Помогите решить проблему долгой авторизации интернет соединения по протоколу PPPoe!

Ответить
Настройки темы
Интернет - Помогите решить проблему долгой авторизации интернет соединения по протоколу PPPoe!

Новый участник


Сообщения: 32
Благодарности: 0

Профиль | Отправить PM | Цитировать


Изменения
Автор: deepdive
Дата: 29-10-2009
Очень хочу перейти на windows 7, но из-за этой проблемы не лежит душа. Когда-то здесь этот вопрос обсуждался другим пользователем и насколько я понял, вопрос не решился. Соединение длится около 20 секунд, у знакомых моментально. Пробовал разные команды типа netsh и т.д. Может быть проблема в сетевом адаптере. Какие у кого есть варианты?

Отправлено: 00:01, 29-10-2009

 

Новый участник


Сообщения: 32
Благодарности: 0

Профиль | Отправить PM | Цитировать


Цитата Valeant:
Так же определите метод и протоколы проверки пароля PAP, CHAP галки в свойстве соединения. »
Это я уже проверял не один раз, галки стоят, пробовал разные варианты.

Мне кажется, что задержка идет из-за какой-то службы безопасности при проверке имени и пароля.

Отправлено: 14:16, 29-10-2009 | #11



Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.

Если же вы забыли свой пароль на форуме, то воспользуйтесь данной ссылкой для восстановления пароля.


Аватара для freese

Ветеран


Contributor


Сообщения: 6683
Благодарности: 1296

Профиль | Отправить PM | Цитировать


Цитата Valeant:
иногда подмешивается определение IPv6 »
кстати ipv6 выключен? бывали случаи что он мешает

Отправлено: 15:32, 29-10-2009 | #12


Новый участник


Сообщения: 32
Благодарности: 0

Профиль | Отправить PM | Цитировать


http://pic.ipicture.ru/uploads/091029/STPsZKM99X.jpg


Задержка на 7 фрейме, кто-то знает что именно?

Это 6 фрейм


Последний раз редактировалось deepdive, 29-10-2009 в 15:57.


Отправлено: 15:45, 29-10-2009 | #13


Новый участник


Сообщения: 32
Благодарности: 0

Профиль | Отправить PM | Цитировать


Здесь седьмой




Отправлено: 16:02, 29-10-2009 | #14


Ветеран


Сообщения: 1958
Благодарности: 306

Профиль | Отправить PM | Цитировать


deepdive,
У меня вопрос сразу же, я непонял это шутка
DestAddress - RECV и SrcAddres - RECV
или
DestAddress - SEND и SrcAddres - SEND
По MAC это кто?
Или у вас столбы по другому
Frame-Time-Process Name-Conv ID-Source-Destination-Protocol-Description
Пр.кн.мыши на строке с наименованием столбцов.


Цитата:
Протокол LCP состоит из форматированных пакетов, которые позволяют двум сторонам обмениваться информацией для определения параметров соединения.
Поле Идентификатор имеет длину в один октет и используется для уникальной идентификации пакета LCP. Таким образом, передатчик может однозначно определить, на какой именно запрос он посылает ответ.

Пакет LCP типа Configure-Request используется для установления РРР-соединения между двумя устройствами. Параметры конфигурации, которые клиент хочет согласовать с удаленным хостом, находятся в поле данных пакета. Все параметры, для которых клиент запрашивает значения, отличные от значений по умолчанию, должны включаться в этот пакет. Все параметры, значения которых не отличаются от значений по умолчанию, в пакет LCP типа Configure-Request не включаются.

Пакет LCP типа Configure-Ack посылается хостом РРР, если он согласен со значениями всех параметров, заявленных в пакете Configure-Request. Значения всех параметров в этом пакете должны полностью соответствовать параметрам, заявленным в пакете Configure-Request. Если имеется расхождение хотя бы в одном из параметров, то сервер РРР не выдает пакет Configure-Ack.

Пакет LCP типа Configure-Nak используется для сигнализации о том, что по крайней мере один из параметров, заявленных в пакете Configure-Request, не принят сервером РРР. При этом сервер должен указать, какой именно параметр не принят, и предложить альтернативное значение этого параметра в поле Опции этого пакета.

Пакет LCP типа Configure-Reject применяется с целью уведомления клиента о том, что параметры, указанные в пакете Configure-Request, либо не опознаны (являются ошибочными), либо не приняты сервером РРР. Когда клиент получает пакет типа Configure-Reject, то он должен сделать вывод о том, что ни один из предложенных им параметров недоступен для согласования с сервером РРР.

Пакет LCP типа Terminate-Request используется клиентом для завершения текущего сеанса РРР. Поле данных в таком пакете может состоять из нулевых байт или заполняться данными, которые не имеют значения. Хост РРР должен обнаруживать пакеты такого типа и реагировать на них соответствующим образом в течение всего сеанса РРР.

Пакет LCP типа Terminate-Ack используется сервером РРР для уведомления клиента о том, что его запрос на завершение сеанса РРР получен. Поле данных этого пакета может заполняться нулевыми байтами или другой бессмысленной информацией. Когда сервер РРР принимает пакет типа Terminate-Request, он должен ответить на него пакетом типа Terminate-Ack и инициировать завершение соединения.

Пакет LCP типа Code-Request используется в том случае, когда сервер РРР получает от клиента пакет РРР с искаженным значением в поле Код. Это говорит о том, что версия РРР у клиента не совпадает с версией РРР на сервере или же у клиента неправильно установлена поддержка РРР. После того как сервер послал пакет такого типа, он немедленно разрывает РРР-соединение.

Пакет LCP типа Protocol-Request применяется, если сервер РРР получает пакет РРР либо с искаженным значением в поле Протокол, либо с протоколом, который им не поддерживается. При этом в поле данных пакета этого типа включается копия отвергнутого пакета. Получение такого пакета клиентом свидетельствует о том, что указанный протокол не поддерживается сервером, о чем он сообщает пользователю.

Пакет LCP типа Echo-Request применяется для реализации метода обратной связи в РРР-соединении. Получив пакет Echo-Request, устройство РРР должно выдать в ответ на него пакет Echo-Reply. Довольно часто эта процедура используется для того, чтобы предотвратить преждевременное завершение соединения из-за отсутствия активности. Она может использоваться также в диагностических целях. Во время переговоров о параметрах соединения может быть определен параметр Magic-Number, который затем можно использовать в данном пакете для идентификации соединения.

Как уже отмечалось, пакет LCP типа Echo-Reply используется в ответ на пакет Echo-Request. Если для соединения был определен параметр Magic-Number, то он должен включаться в этот пакет.

Пакет LCP типа Discard-Request применяется для тестирования соединения. Приемное устройство должно немедленно отбросить пакет Discard-Request. Никакого ответа на этот пакет приемное устройство посылать не должно. Пакет типа Discard-Request также должен содержать параметр Magic-Number, который был определен на стадии установления соединения.

Для полного понимания http://www.intuit.ru/department/inte...dmail/8/3.html

Последний раз редактировалось Valeant, 29-10-2009 в 18:44.

Это сообщение посчитали полезным следующие участники:

Отправлено: 18:27, 29-10-2009 | #15


Новый участник


Сообщения: 32
Благодарности: 0

Профиль | Отправить PM | Цитировать


Цитата Valeant:
У меня вопрос сразу же, я непонял это шутка
DestAddress - RECV и SrcAddres - RECV
или
DestAddress - SEND и SrcAddres - SEND
По MAC это кто?
Или у вас столбы по другому
Frame-Time-Process Name-Conv ID-Source-Destination-Protocol-Description
Пр.кн.мыши на строке с наименованием столбцов. »
Я не понял что ты имеешь ввиду?

Отправлено: 18:56, 29-10-2009 | #16


Ветеран


Сообщения: 1958
Благодарности: 306

Профиль | Отправить PM | Цитировать


deepdive,
Я всегда считал, что обмен должен идти между сервером и клиентом так как это PPP точка - точка.
У меня подозрения что RECV -> RECV (SEND -> SEND)сам на себя

Должно быть наверное так
...
62 - 4.007229 - {PPPoE:29} - [MAC клиента] - [MAC сервера] - LCP:Configure-Request, ID = 0
63 - 4.026230 - {PPPoE:29} - [MAC сервера] - [MAC клиента] - LCP:Configure-Request, ID = 1
64 - 4.026230 - {PPPoE:29} - [MAC сервера] - [МАС клиента] - LCP:Configure-Reject, ID = 0
65 - 4.026230 - {PPPoE:29} - [MAC клиента] - [МАС сервера] - LCP:Configure-Ack, ID = 1
66 - 4.026230 - {PPPoE:29} - [MAC клиента] - [МАС сервера] - LCP:Configure-Request, ID = 1
67 - 4.044231 - {PPPoE:29} - [MAC сервера] - [МАС клиента] - LCP:Configure-Ack, ID = 1
68 - 4.044231 - {PPPoE:29} - [MAC клиента] - [МАС сервера] - LCP:Identification, ID = 2
69 - 4.044231 - {PPPoE:29} - [MAC клиента] - [МАС сервера] - LCP:Identification, ID = 3
70 - 4.044231 - {PPPoE:29} - [MAC клиента] - [МАС сервера] - LCP:Identification, ID = 4
71 - 4.045231 - {PPPoE:29} - [MAC сервера] - [МАС клиента] - CHAP:Challenge, ID = 1
72 - 4.046231 - {PPPoE:29} - [MAC клиента] - [МАС сервера] - CHAP:Response, ID = 1
73 - 4.094234 - {PPPoE:29} - [MAC сервера] - [МАС клиента] - CHAP:Success, ID = 1
74 - 4.095234 - {PPPoE:29} - [MAC сервера] - [МАС клиента] - IPCP:Code = Configure-Request
75 - 4.095234 - {PPPoE:29} - [MAC клиента] - [МАС сервера] - CCP:Configure-Request,Identifier=5
76 - 4.095234 - {PPPoE:29} - [MAC клиента] - [МАС сервера] - IPCP:Code = Configure-Request
77 - 4.095234 - {PPPoE:29} - [MAC клиента] - [МАС сервера] - IPCP:Code = Configure-Ack
78 - 4.112235 - {PPPoE:29} - [MAC сервера] - [МАС клиента] - LCP:Protocol-Reject, ID = 2
79 - 4.113235 - {PPPoE:29} - [MAC сервера] - [МАС клиента] - IPCP:Code = Configure-Reject
...

Вид подключения какой, что к сетевой подключено или сразу лок.сеть?

Отправлено: 19:34, 29-10-2009 | #17


Новый участник


Сообщения: 32
Благодарности: 0

Профиль | Отправить PM | Цитировать


Сети нету! Стоит сетевая карта Realtek 8168 через которую работает модем. Но данных сетевой карты в этой статистике нет.
Я использовал microsoft network monitor 3. А как я могу посмотреть эти данные другим способом?

Цитата Valeant:
Вид подключения какой »
PPPoE

Может дело в сетевой карте.

Отправлено: 19:40, 29-10-2009 | #18


Новый участник


Сообщения: 32
Благодарности: 0

Профиль | Отправить PM | Цитировать


Этот вариант из под windows XP, где все отлично работает.





http://pic.ipicture.ru/uploads/091029/64RyvFjtAV.jpg

Отправлено: 20:30, 29-10-2009 | #19


Ветеран


Сообщения: 1958
Благодарности: 306

Профиль | Отправить PM | Цитировать


deepdive,
Все правильно, алгоритм он везде одинаковый, при анализе вас должно интересовать только My Traffic.
В нем все что приходит/у ходит на вашу/с вашей сетевой карты в сеть.
По пакетам вы правильно определили время на котором заминка аж 20сек.

только последняя 3.3.1641.0 (http://www.microsoft.com/downloads/d...6-3088333d062f) и Microsoft Network Monitor Parsers 3.4.1972 (http://www.codeplex.com/NMParsers)

Отправлено: 20:36, 29-10-2009 | #20



Компьютерный форум OSzone.net » Клиентские ОС Microsoft » Microsoft Windows 7 » Интернет - Помогите решить проблему долгой авторизации интернет соединения по протоколу PPPoe!

Участник сейчас на форуме Участник сейчас на форуме Участник вне форума Участник вне форума Автор темы Автор темы Шапка темы Сообщение прикреплено

Похожие темы
Название темы Автор Информация о форуме Ответов Последнее сообщение
BSOD - помогите решить проблему... Necessary Хочу все знать 3 28-07-2008 14:47
Помогите решить проблему shron Сетевые технологии 2 05-08-2007 02:11
Помогите решить проблему. vint29 Материнские платы и память 14 22-01-2007 19:07




 
Переход