[intersk]

RSS - как это может называться на сетевой карте Realtek??

[GAVVV]

RSS - как это может называться на сетевой карте Realtek?? »

"Функция маштабирования размера приема, или RSS ..."

У меня вот так, на nForce, в свойствах написано!

[Valeant]

intersk,
к Realtek это не относилось, на данных платах не было замечено.
А так в файле *.inf для данной сетевой карты например

; Realtek PCIe FE Family Controller ; Realtek PCI GBE Family Controller ; Realtek PCIe GBE Family Controller ... Battery = "Вкл, батарея" AcBattery = "Вкл, батарея или пер. ток" JumboFrame = "Большой кадр" 2KBMTU = "2KБ MTU" 3KBMTU = "3KБ MTU" 4KBMTU = "4KБ MTU" 5KBMTU = "5KБ MTU" 6KBMTU = "6KБ MTU" 7KBMTU = "7KБ MTU" 8KBMTU = "8KБ MTU" 9KBMTU = "9KБ MTU" S5WakeOnLan = "Включение по локальной сети после отключения" AutoLinkDownPcieMacOff = "Автоотключение PCIe (энергосбережение)" RSS = "Получение бокового масштабирования" AutoCrossoverDet = "Автоопределение кросс-кабеля" PriorityEnabled = "Приоритет вкл" VLANEnabled = "VLAN вкл" 10MbFirst = "Сначала 10 Mбит/с" 100MbFirst = "Сначала 100 Mбит/с" ... и в английской ... 9KBMTU = "9KB MTU" S5WakeOnLan = "Shutdown Wake-On-Lan" AutoLinkDownPcieMacOff = "Auto Disable PCIe (PowerSaving)" RSS = "Receive Side Scaling" AutoCrossoverDet = "Auto Crossover Detection" PriorityEnabled = "Priority Enabled" ...

[intersk]

у меня постоянные обрывы интернета, карта 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

[Valeant]

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)
...

Далее

Дает Reset ваш ПК у меня подозрение на формирование пакетов на вашей стороне так как два пакета одинаковые, только есть разница в битах. ... 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, это означает наличие какой-то проблемы.

Для того что ее решать, нужно с чего-то начать. Если считать что ОС одна и та же, то ее можно исключить, остаются драйвера, настройки сети и сетевое железо, и ПО которое поставил клиент.

1.Точная версия драйвера ваше сетевой и ее марка, настройка драйвера сетевой
2.netsh interface tcp show global
3. ПО - антивирус (firewall)
4. как подключены

[Liseratum]

А можете по подробней описать где этот RSS находится, в свойствах моей сетевухи такого нету, не в Realtek ne v nForce. Может в реестре можно поменять где нить.

[Valeant]

Liseratum,
Значит это к вам не относится.

[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)".

[alb20]

У меня у друга щас наоборот проблема решилась, у него Виндовс 7 Максимальная, Ноутбук HP Сетевуха Реалтек, Убрал как вы написали сначала RSS этот Боковое маштабирование или как там его ,всё равно каждые секунд 10-20 рвалось, причём при повторном звонке ошибку выдавал 619 номер...
Я залез в Бредмауэр Виндовс хотел его отключить,а он уже БЫЛ отключенный, я поставил наоборот его включить, и всё заработало,по крайней мере уже как 30-ть минут прошло, ещё ни одного обрыва не было...!!!

[intersk]

Проблема не зависит от верcии Windows. »

точно!
попробую ваши советы...