|
VPN соединение падает спустя некоторое время в Win7
VPN я использую для выхода в интернет. После подключения спустя минут 10 впн падает. Нужны координальные решения, все стандартные настройки я проверял и перепроверял, настраивал всё что можно. Единственное чего добился, увеличил время соединения до 10 мин.
Провайдер виновен быть не может. В XP всё отлично пашет. |
Дрова для сетевухи какие стоят?У меня падения прекратились только после того,как с Microsoft Update поставил.
|
Liseratum,
Обратил внимание у многих на в свойствах сетевой есть параметр RSS именно в сетевой а не ОС, отключение его решает проблему. Но в любом случае как было сказано с драйвера надо начать. |
Дрова стоят виндовые. Сетевуха встроеная
|
Liseratum, модель материнской платы, пожалуйста.
|
Поставил сетевуху Realtek, такая же проблемма.
|
Liseratum,
От перемены сетевых плат может не чего не изменится. Цитата:
Какие стандартные настройки вы пробовали? |
Цитата:
|
GAVVV,
На nForce втречал. |
Valeant,
Да спасибо - Ваш пост мне и помог! |
RSS - как это может называться на сетевой карте Realtek??
|
Цитата:
У меня вот так, на nForce, в свойствах написано! |
intersk,
к Realtek это не относилось, на данных платах не было замечено. А так в файле *.inf для данной сетевой карты например Цитата:
|
у меня постоянные обрывы интернета, карта Realtek, Windows 7 (на Vista тоже).
Привязка у провайдера по MAC сетевой карты. Включал-отключал файерволы и антивирус, менял драйвера - не помогает. IPv6 отключил. Галка с сетевой снята об отключении экономии энергии. Экспериментировал с настойками сетевой карты Простите за такое большое сообщение, но уж очень надоели эти обрывы каждый минут 10-15 (когда не осуществляешь активный серфинг). Может что-то ещё можно сделать. Пытался разобраться, один специалист с ником БЭЛИН вот как прокомментировал: ЧАСТЬ 1 1.В данной сети куда вы подключены судя по IP - 169.254.х.х ну просто кишит, т.е. не кто настройку не делал, а положились чисто на автоматическую - лучше присвоить всем определенные адреса из сетки 172. 2.1 VPN - PPTP Если вы соединились по VPN, потом нажали старт в Microsoft Network Monitor 3 и не чего не трогали минут 5, то у вас должны были быть пакеты в My Traffic (обязательно) под полученным вами IP от сервера VPN, что-то типа My traffic + - Unknown + --- IPv4 (например 84.242... IP вашего сервера VPN) ... Через равные промежутки времени должны быть от сервера VPN пакеты LCP Echo-Request на ваш полученный IP, и ответы от вас LCP Echo-Reply. Так же должен пробегать пакет GRE он для VPN обязателен, и еще один вид пакетов между вашей сетевой и сервером VPN - PPTP Control Message - Echo Request и естественно ответ PPTP Control Message - Echo Reply. 2.2 PPPoE Аналогично и при данном соединении My traffic + - Unknown + --- PPPoE (например ваш MAC - MAC сервера) ... Через равные промежутки времени должны быть LCP Echo-Request и ответы от вас LCP Echo-Reply. 3.Cудя по route print после разрыва то у вас был ip например 84.242.... в Microsoft Network Monitor ищем это упоминание, в мусоре я так называю все что лежит в Other Traffic находим пакеты 3.1 Адрес ns.natm.ru - 213.148.160.1 {DNS:14, UDP:13, IPv4:12, PPPoE:5} 84.242.253.135 - ns.natm.ru - DNS:QueryId {DNS:14, UDP:13, IPv4:12, PPPoE:5} ns.natm.ru - 84.242.253.135 - DNS:QueryId, Response - Name Error (перевод не нужен понятно, чо проблема с DNS - Name Error) ... {DNS:20, UDP:19, IPv4:12, PPPoE:5} 84.242.253.135 - ns.natm.ru - DNS:QueryId, Query for 65.141.254.169.in-addr.arpa of type PTR on class Internet (получили IP, но запрос по DNS передаем на 169.254.141.65 не туда) {DNS:22, UDP:21, IPv4:12, PPPoE:5} 84.242.253.135 - ns.natm.ru - DNS:QueryId, Query for 255.255.254.169.in-addr.arpa of type PTR on class Internet {DNS:24, UDP:23, IPv4:12, PPPoE:5} 84.242.253.135 - ns.natm.ru - DNS:QueryId, Query for 1.160.148.213.in-addr.arpa of type PTR on class Internet {DNS:26, UDP:25, IPv4:12, PPPoE:5} 84.242.253.135 - ns.natm.ru - DNS:QueryId, Query for 252.0.0.224.in-addr.arpa of type PTR on class Internet {DNS:22, UDP:21, IPv4:12, PPPoE:5} ns.natm.ru - 84.242.253.135 - DNS:QueryId, Response - Name Error {DNS:24, UDP:23, IPv4:12, PPPoE:5} ns.natm.ru - 84.242.253.135 - DNS:QueryId, Response - Success, Array[213.148.160.1,213.148.161.1] {DNS:26, UDP:25, IPv4:12, PPPoE:5} ns.natm.ru - 84.242.253.135 - DNS:QueryId, Response - Name Error (похоже на истину 213.148.160.1, но проблема) 3.2 Так же в мусоре есть ваш мак 00-16-D3-8B-68-6B, mak 00-19-B9-F7-3D-E5 - ns.natm.ru {PPPoE:5} [Dell Inc. F73DE5 [00-19-B9-F7-3D-E5]] [Wistron Corporation 8B686B [00-16-D3-8B-68-6B]] LCP:Echo-Request {PPPoE:5} [Wistron Corporation 8B686B [00-16-D3-8B-68-6B]] [Dell Inc. F73DE5 [00-19-B9-F7-3D-E5]] LCP:Echo-Reply ... {DNS:34, UDP:33, IPv4:12, PPPoE:5} 84.242.253.135 - ns.natm.ru - DNS:QueryId, Query for 226.81.254.169.in-addr.arpa of type PTR on class Internet {DNS:34, UDP:33, IPv4:12, PPPoE:5} ns.natm.ru - 84.242.253.135 - DNS:QueryId, Response - Name Error ... Потом вот это 00-15-E9-44-92-52 - D-Link {PPPoE:5} [D-Link Corporation 449252 [00-15-E9-44-92-52]] [*BROADCAST [FF-FF-FF-FF-FF-FF]] - PPPoE:Active Discovery Initiation (PADI) svchost.exe {DHCP:43, UDP:8, IPv4:7} 0.0.0.0 255.255.255.255 DHCP:Request, MsgType = DISCOVER ... {DNS:56, UDP:55, IPv4:12, PPPoE:5} 84.242.253.135 - ns.natm.ru - DNS:QueryId, Query for www.msftncsi.com of type Host Addr on class Internet {DNS:56, UDP:55, IPv4:12, PPPoE:5} ns.natm.ru - 84.242.253.135 - DNS:QueryId, Response - Success, 213.199.181.90, 65.55.117.2 ... (тут все уже правильно) ... {DNS:76, UDP:75, IPv4:12, PPPoE:5} 84.242.253.135 - ns.natm.ru - DNS:QueryId, Query for 19.203.254.169.in-addr.arpa of type PTR on class Internet {DNS:76, UDP:75, IPv4:12, PPPoE:5} ns.natm.ru - 84.242.253.135 -DNS:QueryId, Response - Name Error (опять делаете запрос не туда) ... 169.254.22.171 - MICROSOF-005981 ARP:Request, 169.254.22.171 asks for 169.254.203.19 MICROSOF-005981 - 169.254.22.171 ARP:Response, 169.254.203.19 at 00-E0-4C-41-A0-2D С этого момента ваша система уже не работает с пакета 287. В ProcMonitor так же присутствует где FSC ваш ПК UDP Send - FSC:63397 -> ns.natm.ru:domain UDP Receive - FSC:64929 -> ns.natm.ru:domain и вот это UDP Send - FSC:bootpc -> 255.255.255.255:bootps ... UDP Send - FSC:bootpc -> 255.255.255.255:bootps (BOOTP (Bootstrap Protocol) так же как и RARP обеспечивает определение IP адреса по MAC адресу (например, при загрузке устройства, не имеющего возможности хранить свой собственный IP адрес http://www.bog.pp.ru/work/bootp.html) Из сего вывода я делаю предположение, что у вас есть небольшая локальная сеть, все ПК с DHCP, как такого сервера DHCP у вас нет, работа с интернет обеспечивается через D-LINK модем через который получают доступ (так как есть еще одно PPPoE только не с вашим мак) проблемы с настройками на вашем ПК и на модеме DLink. ЧАСТЬ 2 Еще раз смотрел ваш capture buffer наткнулся как и раньше вот на что 147 {TCP:58, IPv4:57, PPPoE:5} ncsi.glbdns.microsoft.com 84.242.253.135 TCP TCP:Flags=...A...F, SrcPort=HTTP(80), DstPort=49158, PayloadLen=0, Seq=400799557, Ack=3459151699 148 {TCP:58, IPv4:57, PPPoE:5} 84.242.253.135 ncsi.glbdns.microsoft.com TCP TCP:Flags=...A...., SrcPort=49158, DstPort=HTTP(80), PayloadLen=0, Seq=3459151699, Ack=400799558 149 {TCP:58, IPv4:57, PPPoE:5} 84.242.253.135 ncsi.glbdns.microsoft.com TCP TCP:Flags=...A...F, SrcPort=49158, DstPort=HTTP(80), PayloadLen=0, Seq=3459151699, Ack=400799558 150 {TCP:58, IPv4:57, PPPoE:5} 84.242.253.135 ncsi.glbdns.microsoft.com TCP TCP:Flags=...A.R.., SrcPort=49158, DstPort=HTTP(80), PayloadLen=0, Seq=3459151700, Ack=400799558 151 {TCP:60, IPv4:57, PPPoE:5} ncsi.glbdns.microsoft.com 84.242.253.135 TCP TCP:Flags=...A...., SrcPort=HTTP(80), DstPort=49158, PayloadLen=0, Seq=400799558, Ack=3459151700 152 {TCP:60, IPv4:57, PPPoE:5} 84.242.253.135 ncsi.glbdns.microsoft.com TCP TCP:Flags=.....R.., SrcPort=49158, DstPort=HTTP(80), PayloadLen=0, Seq=3459151700, Ack=3459151700 Описание заголовка и битов http://network.distudy.ru/set_j0/set_j0d.html Должно быть именно в данном случае, и в точно такой же ситуации при доступе к серверу, это конечно частный случай сравнения {TCP:43, IPv4:116, PPPoE:69} ncsi.glbdns.microsoft.com х.х.х.х TCP TCP:Flags=...A...F, SrcPort=HTTP(80), DstPort=51222, PayloadLen=0, Seq=1067319067, Ack=463019270, Win=4417 (scale factor 0x0) = 4417 {TCP:43, IPv4:116, PPPoE:69} х.х.х.х ncsi.glbdns.microsoft.com TCP TCP:Flags=...A...F, SrcPort=51222, DstPort=HTTP(80), PayloadLen=0, Seq=463019270, Ack=1067319067, Win=4085 (scale factor 0x4) = 65360 {TCP:43, IPv4:116, PPPoE:69} х.х.х.х ncsi.glbdns.microsoft.com TCP TCP:Flags=...A...., SrcPort=51222, DstPort=HTTP(80), PayloadLen=0, Seq=463019271, Ack=1067319068, Win=4085 (scale factor 0x4) = 65360 {TCP:45, IPv4:116, PPPoE:69} ncsi.glbdns.microsoft.com x.x.x.x TCP TCP:Flags=...A...F, SrcPort=HTTP(80), DstPort=51222, PayloadLen=0, Seq=1067319067, Ack=463019271, Win=4417 Дает Reset ваш ПК у меня подозрение на формирование пакетов на вашей стороне так как два пакета одинаковые, только есть разница в битах. В вашем случае с capture.cap я зацепился только вот за что определение доступа к интернету и значек в трее 148 PPPoE от вас - ncsi.glbdns.microsoft.com - TCP:Flags=...A.... 149 PPPoE от вас - ncsi.glbdns.microsoft.com - ТCP:Flags=...A...F механизм конца передачи, данных нет 150 PPPoE от вас - ncsi.glbdns.microsoft.com - TCP:Flags=...A.R.. вы информируете адресат о Цитата: Флаг RST - reset используется для сброса состояния соединения, которое из-за сбоя хоста или по другой причине попало в тупиковую ситуацию. Кроме того, он используется для отказа от неверного сегмента или от попытки создать соединение. Если вы получили сегмент с установленным битом RST, это означает наличие какой-то проблемы. 151 PPPoE - ncsi.glbdns.microsoft.com к вам - TCP:Flags=...A.... подтверждает получение предыдущего пакета 152 PPPoE от вас - ncsi.glbdns.microsoft.com - TCP:Flags=.....R.. конец 155 PPPoE от вас - ns.natm.ru (провайдер ваш) DNS Query for 90.181.199.213.in-addr.arpa of type PTR on class Internet запрос на преобразование DNS - ncsi.glbdns.microsoft.com 156 PPPoE ns.natm.ru к вам DNS Response - Name Error ответ вам Error 157 169.254.22.171 - 224.0.0.252 - LLMNR Query for 90.181.199.213.in-addr.arpa of type PTR on class Internet Другим способом от вас но уже просто по сети, а не по PPPoE ... 166 PPPoE от [00-19-B9-хх-хх-хх] к вам [00-16-D3-хх-хх-хх] LCP LCP:Echo-Request 167 PPPoE от вас [00-16-D3-хх-хх-хх] к [00-19-B9-хх-хх-хх]] LCP LCP:Echo-Reply Ты тут, я тут ... 172 DHCP от вас широковещательный пакет в сеть на поиск сервера DHCP 0.0.0.0 - 255.255.255.255 - DHCP:Request, MsgType = DISCOVER ... И далее просто повторение PPPoE от [00-19-B9-хх-хх-хх] к вам [00-16-D3-хх-хх-хх] LCP LCP:Echo-Request PPPoE от вас [00-16-D3-хх-хх-хх] к [00-19-B9-хх-хх-хх]] LCP LCP:Echo-Reply ... DHCP от вас широковещательный пакет в сеть на поиск сервера DHCP 0.0.0.0 - 255.255.255.255 - DHCP:Request, MsgType = DISCOVER ЧАСТЬ 3 Еще раз при просмотре capture.cap от 15.10.09 вот что мне интересно, если у вас mac 00-16-D3-8B-68-6B и ваше PPPoE создается с сервером MAC 00-19-B9-хх-хх-хх, он же является для вас и DNS, то очень странно вот что, зачем этому серверу выполнять команду, которую выполняют только клиенты PPPoE 823 - {PPPoE:5} [Dell Inc. [00-19-B9-хх-хх-хх]] [Wistron Corporation [00-16-D3-8B-68-6B]] LCP:Echo-Request, ID = 46 824 - {PPPoE:5} [Wistron Corporation [00-16-D3-8B-68-6B]] [Dell Inc. [00-19-B9-F7-3D-E5]] LCP:Echo-Reply, ID = 46 ... 844 - {PPPoE:5} [Dell Inc. [00-19-B9-хх-хх-хх]] [*BROADCAST [FF-FF-FF-FF-FF-FF]] PPPoE:Active Discovery Initiation (PADI) 846 - {PPPoE:5} [Dell Inc. [00-19-B9-хх-хх-хх]] [Wistron Corporation [00-16-D3-8B-68-6B]] LCP:Terminate-Request, ID = 2 847 - {PPPoE:5} [Wistron Corporation [00-16-D3-8B-68-6B]] [Dell Inc. [00-19-B9-хх-хх-хх]] LCP:Terminate-Ack, ID = 2 848 - {PPPoE:5} [Dell Inc. [00-19-B9-хх-хх-хх]] [Wistron Corporation [00-16-D3-8B-68-6B]] PPPoE:Active Discovery Terminate (PADT) 849 - {PPPoE:5} [Wistron Corporation [00-16-D3-8B-68-6B]] [Dell Inc. [00-19-B9-F7-3D-E5]] PPPoE:Active Discovery Terminate (PADT) 850 - {PPPoE:5} [Dell Inc.[00-19-B9-F7-3D-E5]] [Wistron Corporation [00-16-D3-8B-68-6B]] PPPoE:Active Discovery Terminate (PADT) При первом осмотре NMM 3 имею опять эти же ошибки в формировании пакетов 1. capture-1 9 - {TCP:3, IPv4:2, PPPoE:1} - от ВАС - ncsi.glbdns.microsoft.com - TCP:Flags=...A...., SrcPort=49161, DstPort=HTTP(80), PayloadLen=0, Seq=1290625607, Ack=4061555525 10 - {TCP:3, IPv4:2, PPPoE:1} - от ВАС - ncsi.glbdns.microsoft.com - TCP:Flags=...A...F, SrcPort=49161, DstPort=HTTP(80), PayloadLen=0, Seq=1290625607, Ack=4061555525 11 - {TCP:3, IPv4:2, PPPoE:1} - от ВАС - ncsi.glbdns.microsoft.com - TCP:Flags=...A.R.., SrcPort=49161, DstPort=HTTP(80), PayloadLen=0, Seq=1290625608, Ack=4061555525 bit сброса RESET инициатор ваш ПК, два одинаковых пакета с разными флагами, хотя Seq и Ack должны быть на 1 больше 12 - {TCP:5, IPv4:2, PPPoE:1} - ncsi.glbdns.microsoft.com - для ВАС - ТCP:Flags=...A...., SrcPort=HTTP(80), DstPort=49161, PayloadLen=0, Seq=4061555525, Ack=1290625608 13 - {TCP:5, IPv4:2, PPPoE:1} - от ВАС - ncsi.glbdns.microsoft.com - TCP:Flags=.....R.., SrcPort=49161, DstPort=HTTP(80), PayloadLen=0, Seq=1290625608, Ack=1290625608 Предполагаю нарушена последовательность Seq и Ack - в нормальном режиме это просто кончается Fin. Как я писал в посте выше опять же не понятка в том что 490 - {PPPoE:1} - [Dell Inc. [00-19-B9-хх-хх-хх]] [Wistron Corporation [00-16-D3-хх-хх-хх]] - LCP:Echo-Request, ID = 26, Length = 8 491 - {PPPoE:1} - [Wistron Corporation [00-16-D3-хх-хх-хх]] [Dell Inc. [00-19-B9-хх-хх-хх]] - LCP:Echo-Reply, ID = 26, Length = 8 495 - {PPPoE:1} - [Dell Inc. [00-19-B9-хх-хх-хх]] [*BROADCAST [FF-FF-FF-FF-FF-FF]] - PPPoE:Active Discovery Initiation (PADI) вот что мне интересно тут у вас опять, если у вас mac [Wistron Corporation] 00-16-D3-8B-68-6B и ваше PPPoE создается с сервером MAC [Dell Inc.]00-19-B9-хх-хх-хх, он же является для вас и DNS, то очень странно вот что, зачем этому серверу выполнять команду, которую выполняют только клиенты PPPoE для поиска сервера PPPoE предположение произошел разрыв у [Dell Inc.]00-19-B9-хх-хх-хх и он сам ищет вышестоящий сервер. Далее все как по науки рвется ваше соединение, инициатор [Dell Inc. [00-19-B9-хх-хх-хх] 573 - {PPPoE:5} [Dell Inc. [00-19-B9-хх-хх-хх]] [Wistron Corporation [00-16-D3-8B-68-6B]] LCP:Terminate-Request, ID = 2 574 - {PPPoE:5} [Wistron Corporation [00-16-D3-8B-68-6B]] [Dell Inc. [00-19-B9-хх-хх-хх]] LCP:Terminate-Ack, ID = 2 575 - {PPPoE:5} [Dell Inc. [00-19-B9-хх-хх-хх]] [Wistron Corporation [00-16-D3-8B-68-6B]] PPPoE:Active Discovery Terminate (PADT) 576 - {PPPoE:5} [Wistron Corporation [00-16-D3-8B-68-6B]] [Dell Inc. [00-19-B9-хх-хх-хх]] PPPoE:Active Discovery Terminate (PADT) 577 - {PPPoE:5} [Dell Inc.[00-19-B9-хх-хх-хх]] [Wistron Corporation [00-16-D3-8B-68-6B]] PPPoE:Active Discovery Terminate (PADT) 2. Так же не понял зачем ПК имеющему IP делать запрос на DHCP 653 - {DHCP:51, UDP:50, IPv4:49, PPPoE:1} - от ВАС(84.242.x.x) - 255.255.255.255 - DHCP:Request, MsgType = INFORM, TransactionID = 0x9FC4C756 |
intersk,
Конечно для полного понимания необходимо по чаше смотреть в данные программы такие как Microsoft Network Monitor 3 и возможно сохранить от нее лог при нормальной работе, тогда будет понятно что и где не так. Посмотреть как она работает просто не прикасаясь не к чему, даже можно лог записать. В вашей ситуации "нельзя" сказать нажмите здесь галку и все за работает вряд ли кто скажет. Конечно описывать проблему тяжело, тем более что можно было сослаться на http://www.thevista.ru/forums.php?m=posts&q=15394&d=30 Подтвержу, что считаю проблем при DHCP хватает т.е. динамический IP, да еще и сам факт, что если в сети по какой либо причине сервер DHCP не ответит, то ваш ПК присвоит себе адрес сам из сетки 169.254.х.х Далее у вас VPN соединения то можно было хотябы посмотреть на данном сайте одну страницу про описания данного механизма соединения ... PPPoE:Active Discovery Terminate (PADT) PPPoE:Active Discovery Terminate (PADT) PPPoE:Active Discovery Terminate (PADT) ... Далее Цитата:
1.Точная версия драйвера ваше сетевой и ее марка, настройка драйвера сетевой 2.netsh interface tcp show global 3. ПО - антивирус (firewall) 4. как подключены |
А можете по подробней описать где этот RSS находится, в свойствах моей сетевухи такого нету, не в Realtek ne v nForce. Может в реестре можно поменять где нить.
|
Liseratum,
Значит это к вам не относится. |
Нашел решение проблемы.
1) если ВКЛЮЧЕН встроенный брэндмауэр (фаервол) его необходимо отключить, и возможно проблема исчезнет. Перед тем как полностью отключить службу необходимо отключить привязки службы к сетевым соединениям (сняв галочки напротив ВСЕХ сетевых соединений). тут: Пуск > Настройка > Панель управления > Брендмауэр Windows. В разделе дополнительных параметров. Брандмауэр это встроенная служба Vista находиться тут: Пуск > Настройка > Панель управления > Администрирование > Службы > Брэндмауэр Windows (пункт из списка). Отключить, установить тип запуска "Отключено", + установить последние обновления системы Vista или Seven; 2) Если встроенный брэндмауэр отключен правильно (как показано выше) и проблема не исчезла. Необходимо отключить антивирус, обладающий функциями брэндмаура (фаервола) и посмотреть на результат. Или другой фаервол, например данная проблема была замечена с фаерволом AtGuard. 3) Возможно у вас такой случай: Когда на платформе nForce от nVidia встречаются Windows 7 - проблема в настройках драйвера сетевой карты, точнее во включенной опции: Receive Side Scaling (RSS). Поскольку Receive Side Scaling штука весьма полезная, она распределяет нагрузку TCP/IP (TOE) между ядрами процессора, что обеспечивает меньшую загрузку процессора в целом, то её отключение не является панацеей. Но, как временная мера пока не выпустят патч или новые драйвера, подойдёт. Если отсутствует вкладка «Дополнительно», то можно отключать RSS через командную строку: netsh interface tcp set global rss=disabled После чего перезагружаемся, и проверяем статус: 4) На компьютере установлена Windows XP и после установления VPN соединения буквально через 20-40 секунд оно "отваливается". Если у вас появляется в разделе панели управления "Сетевые подключения" сетевое подключение под названием "а-connect" или "z-connect" => У вас на компьютере вирус! поставьте свежий антивирус и почистите систему. При попытке удалить это соединение оно появляется снова после очередного "обрыва" vnp . Проблема не зависит от верcии Windows. 5) Отключить механизм определения "мертвых шлюзов". Ищем в реестре параметр EnableDeadGWDetect и присваеваем ему 0 (нулевое значение). В Windows этот параметр находится в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 6) Отключить в свойствах сетевого соединения протокол интернета версии 6 (TCP/IPv6). Лучше оставить отметки только на компонентах "Планировщик пакетов QoS" и "Протокол Интернета версии 4 (TCP/IPv4)". |
У меня у друга щас наоборот проблема решилась, у него Виндовс 7 Максимальная, Ноутбук HP Сетевуха Реалтек, Убрал как вы написали сначала RSS этот Боковое маштабирование или как там его ,всё равно каждые секунд 10-20 рвалось, причём при повторном звонке ошибку выдавал 619 номер...
Я залез в Бредмауэр Виндовс хотел его отключить,а он уже БЫЛ отключенный, я поставил наоборот его включить, и всё заработало,по крайней мере уже как 30-ть минут прошло, ещё ни одного обрыва не было...!!! |
Цитата:
попробую ваши советы... |
Liseratum, спасибо!!! за два часа работы в интернете оборвалось единожды. Причем перед этим Opera подвисла , а потом обрыв. Посмотрим дальше.....
на следующий день - БЕЗ ВЫЛЕТОВ!!! Вот только ещё что - установил OutposteFirewall - так он постоянно блокирует какие то пакеты UPD на один и тот же адрес 10.10...... Может этот пакет и разрывал соединение, а теперь он блокируется... Будем дальше тестить. Обрывов нет и после переустанови системы без каких-либо манипуляций. Думаю дело всё в каких-то исходящих соединениях, которые теперь блокируются файерволом. |
868-я ошибка
Добрый день!!!Поставил себе 7-ку и тут же начались проблемы с VPN вылетает инет. ПрТак и не смог разобраться из-за чего это происходит. Проблема решалась сама по себе через некоторое время (иногда 10 мин, иногда 4 часа) после чего все опять начинало работать или приходилось пользоваться перезагрузкой. Пробывал винду переставлять и все заново перенастраивать ничего не помогало.Постоянно выдает ошибку 868.В абонентской службе провайдера сказали ,что дело в 7-ке и косяками DNS . Често сказать не понял.Может кто-нить подскажет?
|
|
Morpheus,не особо красноречивый ответ у Мелкософта
|
boalni, а попробовали вбить эти адреса?
Склеил темы. Читайте выше. |
Ничего выше сказанное не помогло, возможно у меня другая проблема, но... может кто сталкивался???
Есть сервер, все равно какой 2003 или 2008. К нему через pptp подключается vpn с XP. Тунель отлично работает. И не важно есть обмен по этому тунелю или нет. Но проблемы начались после того как вместо XP поставил Семерку. VPN висит, и если запросы идут с клиенткой машины, например по шаровым дисками или радмином, то с сервера аналогично тоже запросы и пинги проходят. Но стоит чтобы с клиентской машины пошла тишина и эта тишина длится ровно 1 минуту, как с сервера уже никак не достучаться ничем на семерку, ни пинги ни радмином. Дальше интереснее. Если запустить пингования сервера с клиентской семерки постоянно, то проблема решается. Но хотелось бы выяснить и решить эту проблему, ведь в XP все в порядке. Параметр RSS а также галочка в настройках сетевухи семерки возможность отключения адаптера при простое тоже отключено. |
Остановил брандмауэр как службу и поставил параметр отключено.
Теперь не вылетает. |
| Время: 16:17. |
Время: 16:17.
© OSzone.net 2001-