1

Ноутбук может пинговать и трассировать, но не просматривать Интернет. Я начну с того, что уже исключил:

  • Это совершенно новая установка Windows
  • Сеть работает нормально для других 5 устройств, как Wi-Fi, так и проводной
  • Telnet не подключается
  • Пингует доменное имя и IP-адрес работает нормально
  • Я могу просматривать ноутбук через компьютер в сети, но не наоборот
  • проверил, что нет никаких активных настроек прокси

Итак, у кого-нибудь есть идеи, что может быть причиной этого, кроме того, что я уже пробовал? Я уже поставил диагноз перечисленным выше материалам, поэтому рассказывать мне telnet будет непродуктивно. Сказать мне попробовать другой браузер или проверить на вирусы или отключить AV также не поможет, так как я исключил это. Я прошу прощения за свой тон, но я, кажется, получаю одни и те же несколько ответов каждый раз, когда задаю этот вопрос, и в этот момент мой вопрос должен исчезнуть.

|источник

3 ответа3

1

Попробуйте этот метод:

  • Нажмите Пуск -> В поле поиска введите cmd -> Затем "CMD" будет отображаться в поиске -> Теперь щелкните правой кнопкой мыши "CMD" ---> Выберите "Запуск от имени администратора".

  • Теперь введите эту команду и нажмите "Enter".

netsh int ip reset resetlog.txt

  • Перезагрузите компьютер

Удачи.

|источник
1

Размер пакета - еще одна возможная причина проблем с сетью.

У меня недавно была похожая проблема. ping работает, поэтому у меня есть интернет-соединение, но большинство TCP-соединений зависают и, наконец, время ожидания истекло. Оказывается, что моя беспроводная карта глючит или недостаточно активна и не обрабатывает большие пакеты должным образом. Одно из различий между ping и большинством TCP-соединений заключается в том, что ping по умолчанию использует небольшие пакеты. Чтобы проверить, доставляются ли большие пакеты нормально, используйте команду ping с разными размерами пакетов, используя опцию -l † (в Windows). Например, ping адрес 10.0.99.221 с 1000 байт в поле данных, введите:

ping -l 1000 10.0.99.221

В моем случае ping с 500 байтами приводит к потере 95% пакетов, в то время как ping с 56 байтами работает нормально.

Установка MTU (Maximum Transmission Unit) на меньшее значение может временно обойти проблему. Это отрицательно сказывается на производительности.

В моем случае установка MTU на 400 делает сеть временно работоспособной. Это довольно мало и не рекомендуется. Поскольку это проблема, связанная с аппаратным обеспечением, аппаратное обеспечение должно быть исправлено или заменено.
______________
† Это строчная буква L ; возможно это обозначает пакет l ength.

|источник
1

Пара идей:

  1. Linux live CD тест. Просто загрузитесь на live cd и попробуйте получить доступ к сети, используя это. Я делаю это, чтобы убедиться, что сетевой стек, используемый для вашего оборудования, неисправен.
  2. Попробуйте перейти к следующему прыжку с помощью браузера. Если вы находитесь в домашней сети, это обычно 192.168.1.1 но вы можете узнать с помощью ipconfig и посмотреть, какой у вас шлюз по умолчанию. Вы должны увидеть веб-интерфейс.
  3. Измените свой DNS-сервер на вашем компьютере на те, которые должны быть доступны в Интернете; в отличие от использования вашего следующего прыжка (192.168.1.1 или тому подобное). После внесения этого изменения попробуйте разрешить DNS (просто ping example.com).
  4. Запустите захват пакетов на вашем компьютере (или маршрутизаторе), чтобы увидеть, какие пакеты покидают ваш компьютер (если хотите, опубликуйте pcap или снимок экрана с этим).

Я рекомендую последний, потому что было любопытно, что ICMP работает на вашем маршрутизаторе, но не TCP или UDP. Однако разрешение хоста - это UDP. После дальнейшей проверки вашего старого вопроса я вижу, что ваш DNS-сервер - ваш следующий переход. Таким образом, изменение этого параметра должно помешать правильному разрешению DNS (убедитесь, что проблема не устранена).

Если это не работает в Linux, то мы можем окончательно определить проблему как аппаратную. Если вы хотите на этом шаге мы могли strace различные процессы , чтобы выяснить , в какой момент он терпит неудачу.

Однако, если он работает на Linux, но не на Windows, мы должны попытаться сделать больше работы. В этот момент вы можете попробовать использовать Windows strace (не существует, но ссылки ниже). Чтобы увидеть, какие процессы вызываются (а какие нет), когда вы запускаете ping vs telnet.

Казалось бы, проблема заключается в том, что при наличии пакета TCP или UDP, который должен покинуть сеть (получить доступ к Интернету), стек tcp/udp не передает их должным образом на третий уровень. Однако ICMP является протоколом третьего уровня, поэтому он будет обходить стек tcp/udp. Однако, если завершение шага 2, описанного выше, работает, это показывает, что доступ к внутренней сети, по-видимому, не вызывает этой проблемы, и завершение шага 3, приведенного выше, должно показать это путем инверсии (так как в нем должно перестать работать). Захват пакета подтвердит это. Чтобы попытаться исправить это из командной строки с повышенными правами:

netsh int ipv4 uninstall
netsh int ipv6 uninstall
netsh int tcp uninstall
netsh int ipv4 install
netsh int ipv6 install
netsh int tcp install
netsh winsock reset catalog

Я бы не рекомендовал запускать их только без исследования проблемы. Но это должно помочь.

Strace(esque) Ссылки: http://msdn.microsoft.com/en-us/library/windows/hardware/ff552060%28v=vs.85%29.aspx

http://www.intellectualheaven.com/default.asp?BH=projects&H=strace.htm

http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .