У меня недавно была эта проблема с моим интернет-соединением на моем MacBook Pro начале 2011 года под управлением OS X 10.8.3: время от времени соединение «зависает» примерно на 5 секунд, а затем возвращается.
Это происходит как по Wi-Fi, так и по кабелю Ethernet , и это происходит только с моей машиной, когда она работает под управлением OS X (это не произойдет, если Windows 7 работает на той же машине или на любом другом компьютере / устройстве). Это делает Skype сбрасывать звонки каждые 2 минуты или около того, так что это очень расстраивает.
Пинг Google.com выглядит следующим образом при запуске OS X (сотни пакетов возвращаются менее чем за 100 мс (с несколькими в диапазоне 130), затем выпадают на несколько секунд) :
64 bytes from 173.194.34.196: icmp_seq=694 ttl=48 time=71.463 ms
64 bytes from 173.194.34.196: icmp_seq=695 ttl=48 time=68.362 ms
64 bytes from 173.194.34.196: icmp_seq=696 ttl=48 time=69.056 ms
64 bytes from 173.194.34.196: icmp_seq=697 ttl=48 time=92.563 ms
64 bytes from 173.194.34.196: icmp_seq=698 ttl=48 time=130.814 ms
64 bytes from 173.194.34.196: icmp_seq=699 ttl=48 time=71.054 ms
64 bytes from 173.194.34.196: icmp_seq=700 ttl=48 time=73.588 ms
64 bytes from 173.194.34.196: icmp_seq=701 ttl=48 time=71.185 ms
64 bytes from 173.194.34.196: icmp_seq=702 ttl=48 time=72.161 ms
64 bytes from 173.194.34.196: icmp_seq=703 ttl=48 time=69.163 ms
64 bytes from 173.194.34.196: icmp_seq=704 ttl=48 time=73.425 ms
64 bytes from 173.194.34.196: icmp_seq=705 ttl=48 time=141.980 ms
64 bytes from 173.194.34.196: icmp_seq=706 ttl=48 time=226.818 ms
64 bytes from 173.194.34.196: icmp_seq=707 ttl=48 time=210.087 ms
Request timeout for icmp_seq 708
Request timeout for icmp_seq 709
Request timeout for icmp_seq 710
Request timeout for icmp_seq 711
Request timeout for icmp_seq 712
64 bytes from 173.194.34.196: icmp_seq=713 ttl=48 time=73.582 ms
64 bytes from 173.194.34.196: icmp_seq=714 ttl=48 time=70.994 ms
64 bytes from 173.194.34.196: icmp_seq=715 ttl=48 time=72.502 ms
64 bytes from 173.194.34.196: icmp_seq=716 ttl=48 time=70.467 ms
64 bytes from 173.194.34.196: icmp_seq=717 ttl=48 time=68.470 ms
64 bytes from 173.194.34.196: icmp_seq=718 ttl=48 time=70.767 ms
64 bytes from 173.194.34.196: icmp_seq=719 ttl=48 time=69.078 ms
Примечание. MAC-адрес Wi-Fi на моей машине равен 68: a8: 6d: 29: cf: 8a (статический IP-адрес 192.168.1.250), а его адрес Ethernet равен 3c: 07: 54: 5a: e0: 44 (статический IP-адрес 192.168.1.251). , IP-адрес маршрутизатора LAN 192.168.1.1, а IP-адрес WAN 85.61.155.224.
На следующем скриншоте во время разговора по Skype видно:
ping 192.168.1.1
в левом верхнем углу.ping 85.61.155.224
в левом нижнем углу.ping google.com
в правом нижнем углу.arp -an
иarp -ad
команды выполняются.
Когда я выполнил arp -ad
команду в тот момент, когда соединение было потеряно, в списке не было адресов. Это выглядело так:
Miguels-MacBook-Pro:~ Ai$ sudo arp -ad
192.168.1.1 (192.168.1.1) deleted
192.168.1.4 (192.168.1.4) deleted
192.168.1.255 (192.168.1.255) deleted
Miguels-MacBook-Pro:~ Ai$ arp -an
Miguels-MacBook-Pro:~ Ai$
У меня нет достаточных знаний, чтобы следовать инструкциям Майка о том, как получить и скомпилировать источник mtr
команды.
Вот как все выглядит, когда это хуже:
Бег netstat -s
дает:
Miguels-MacBook-Pro:mtr-0.84 Ai$ NETSTAT -s
tcp:
18246745 packets sent
1119644 data packets (502840461 bytes)
43704 data packets (23125605 bytes) retransmitted
1 resend initiated by MTU discovery
11219994 ack-only packets (80633 delayed)
0 URG only packets
10 window probe packets
5446529 window update packets
419140 control packets
0 data packets sent after flow control
25777361 packets received
1284807 acks (for 502390806 bytes)
222223 duplicate acks
2 acks for unsent data
21993647 packets (3385435972 bytes) received in-sequence
85441 completely duplicate packets (85927570 bytes)
189 old duplicate packets
6141 packets with some dup. data (1633845 bytes duped)
2225930 out-of-order packets (3047304289 bytes)
2 packets (0 bytes) of data after window
0 window probes
7324 window update packets
63837 packets received after close
56 bad resets
9 discarded for bad checksums
0 discarded for bad header offset fields
0 discarded because packet too short
200907 connection requests
118631 connection accepts
110736 bad connection attempts
1273 listen queue overflows
220132 connections established (including accepts)
335687 connections closed (including 10893 drops)
4086 connections updated cached RTT on close
4086 connections updated cached RTT variance on close
1485 connections updated cached ssthresh on close
44620 embryonic connections dropped
1178835 segments updated rtt (of 1308648 attempts)
76481 retransmit timeouts
189 connections dropped by rexmit timeout
0 connections dropped after retransmitting FIN
17 persist timeouts
0 connections dropped by persist timeout
2015 keepalive timeouts
1 keepalive probe sent
1409 connections dropped by keepalive
127007 correct ACK header predictions
21519356 correct data packet header predictions
5021 SACK recovery episodes
5638 segment rexmits in SACK recovery episodes
6044752 byte rexmits in SACK recovery episodes
33658 SACK options (SACK blocks) received
2125185 SACK options (SACK blocks) sent
0 SACK scoreboard overflow
udp:
28584263 datagrams received
0 with incomplete header
0 with bad data length field
84 with bad checksum
4216 dropped due to no socket
239052 broadcast/multicast datagrams dropped due to no socket
729188 dropped due to full socket buffers
0 not for hashed pcb
27611723 delivered
28323341 datagrams output
ip:
61548853 total packets received
4 bad header checksums
0 with size smaller than minimum
0 with data size < data length
0 with ip length > max ip packet size
0 with header length < data size
0 with data length < header length
0 with bad options
0 with incorrect version number
103276 fragments received
0 fragments dropped (dup or out of space)
0 fragments dropped after timeout
51420 packets reassembled ok
61383903 packets for this host
32 packets for unknown/unsupported protocol
0 packets forwarded (0 packets fast forwarded)
105 packets not forwardable
112953 packets received for unknown multicast group
0 redirects sent
53953058 packets sent from this host
155 packets sent with fabricated ip header
0 output packets dropped due to no bufs, etc.
3748 output packets discarded due to no route
0 output datagrams fragmented
0 fragments created
0 datagrams that can't be fragmented
0 tunneling packets that can't find gif
3 datagrams with bad address in header
0 packets dropped due to no bufs for control data
icmp:
4216 calls to icmp_error
0 errors not generated 'cuz old message was icmp
Output histogram:
echo reply: 202
destination unreachable: 4216
0 messages with bad code fields
0 messages < minimum length
168 bad checksums
0 messages with bad length
0 multicast echo requests ignored
0 multicast timestamp requests ignored
Input histogram:
echo reply: 7013069
destination unreachable: 14133
echo: 202
time exceeded: 289
202 message responses generated
ICMP address mask responses are disabled
igmp:
0 messages received
0 messages received with too few bytes
0 messages received with wrong TTL
0 messages received with bad checksum
0 V1/V2 membership queries received
0 V3 membership queries received
0 membership queries received with invalid field(s)
0 general queries received
0 group queries received
0 group-source queries received
0 group-source queries dropped
0 membership reports received
0 membership reports received with invalid field(s)
0 membership reports received for groups to which we belong
0 V3 reports received without Router Alert
16 membership reports sent
ipsec:
0 inbound packets processed successfully
0 inbound packets violated process security policy
0 inbound packets with no SA available
0 invalid inbound packets
0 inbound packets failed due to insufficient memory
0 inbound packets failed getting SPI
0 inbound packets failed on AH replay check
0 inbound packets failed on ESP replay check
0 inbound packets considered authentic
0 inbound packets failed on authentication
0 outbound packets processed successfully
0 outbound packets violated process security policy
0 outbound packets with no SA available
0 invalid outbound packets
0 outbound packets failed due to insufficient memory
0 outbound packets with no route
ip6:
151513 total packets received
0 with size smaller than minimum
0 with data size < data length
0 with bad options
0 with incorrect version number
0 fragments received
0 fragments dropped (dup or out of space)
0 fragments dropped after timeout
0 fragments that exceeded limit
0 packets reassembled ok
5555 packets for this host
0 packets forwarded
145711 packets not forwardable
0 redirects sent
2608 packets sent from this host
0 packets sent with fabricated ip header
0 output packets dropped due to no bufs, etc.
4578 output packets discarded due to no route
23 output datagrams fragmented
46 fragments created
0 datagrams that can't be fragmented
0 packets that violated scope rules
145711 multicast packets which we don't join
Input histogram:
hop by hop: 2327
TCP: 244
UDP: 142524
ICMP6: 6416
Mbuf statistics:
244 one mbuf
two or more mbuf:
lo0= 2215
149054 one ext mbuf
0 two or more ext mbuf
0 packets whose headers are not continuous
0 tunneling packets that can't find gif
0 packets discarded due to too may headers
0 failures of source address selection
0 forward cache hit
0 forward cache miss
0 packets dropped due to no bufs for control data
icmp6:
0 calls to icmp_error
0 errors not generated because old message was icmp error or so
0 errors not generated because rate limitation
Output histogram:
router solicitation: 50
neighbor solicitation: 19
neighbor advertisement: 19
MLDv2 listener report: 59
0 messages with bad code fields
0 messages < minimum length
0 bad checksums
0 messages with bad length
Input histogram:
neighbor advertisement: 245
Histogram of error messages to be generated:
0 no route
0 administratively prohibited
0 beyond scope
0 address unreachable
0 port unreachable
0 packet too big
0 time exceed transit
0 time exceed reassembly
0 erroneous header field
0 unrecognized next header
0 unrecognized option
0 redirect
0 unknown
0 message responses generated
0 messages with too many ND options
0 messages with bad ND options
0 bad neighbor solicitation messages
0 bad neighbor advertisement messages
0 bad router solicitation messages
0 bad router advertisement messages
0 bad redirect messages
0 path MTU changes
ipsec6:
0 inbound packets processed successfully
0 inbound packets violated process security policy
0 inbound packets with no SA available
0 invalid inbound packets
0 inbound packets failed due to insufficient memory
0 inbound packets failed getting SPI
0 inbound packets failed on AH replay check
0 inbound packets failed on ESP replay check
0 inbound packets considered authentic
0 inbound packets failed on authentication
0 outbound packets processed successfully
0 outbound packets violated process security policy
0 outbound packets with no SA available
0 invalid outbound packets
0 outbound packets failed due to insufficient memory
0 outbound packets with no route
rip6:
0 messages received
0 checksum calcurations on inbound
0 messages with bad checksum
0 messages dropped due to no socket
0 multicast messages dropped due to no socket
0 messages dropped due to full socket buffers
0 delivered
0 datagrams output
pfkey:
0 requests sent to userland
0 bytes sent to userland
0 messages with invalid length field
0 messages with invalid version field
0 messages with invalid message type field
0 messages too short
0 messages with memory allocation failure
0 messages with duplicate extension
0 messages with invalid extension type
0 messages with invalid sa type
0 messages with invalid address extension
0 requests sent from userland
0 bytes sent from userland
0 messages toward single socket
0 messages toward all sockets
0 messages toward registered sockets
0 messages with memory allocation failure
Бег netstat -I en1
дает:
Miguels-MacBook-Pro-2:mtr-0.84 Ai$ netstat -I en1
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
en1 1500 <Link#5> 68:a8:6d:29:cf:8a 72539835 0 63847581 0 0
en1 1500 fe80::6aa8: fe80:5::6aa8:6dff 72539835 - 63847581 - -
en1 1500 192.168.1 192.168.1.250 72539835 - 63847581 - -
Бег ifconfig -a
дает:
Miguels-MacBook-Pro-2:mtr-0.84 Ai$ ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=3<RXCSUM,TXCSUM>
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=2b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4>
ether 3c:07:54:5a:e0:44
media: autoselect (none)
status: inactive
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 68:a8:6d:29:cf:8a
inet6 fe80::6aa8:6dff:fe29:cf8a%en1 prefixlen 64 scopeid 0x5
inet 192.168.1.250 netmask 0xffffff00 broadcast 192.168.1.255
media: autoselect
status: active
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
ether 0a:a8:6d:29:cf:8a
media: autoselect
status: inactive
fw0: flags=8822<BROADCAST,SMART,SIMPLEX,MULTICAST> mtu 4078
lladdr a4:b1:97:ff:fe:ec:f0:80
media: autoselect <full-duplex>
status: inactive
Что я думаю:
- Это не проблема Wi-Fi, потому что это происходит и по кабелю.
- Это не проблема маршрутизатора / интернет-провайдера, потому что другие устройства и машины не имеют проблем.
- Это не проблема компьютера, потому что это происходит только при работе OS X.
- Следовательно, это должно быть проблемой OS X.
Что я пробовал:
- Перезагрузка, выключение.
- Включите и выключите AirPort, различные кабели Ethernet.
- Ремонт разрешений.
- Сбросьте ПРАМ.
- Очистите все системные и пользовательские кэши с помощью Onyx.
Странное замечание: по какой-то странной причине проблема, кажется, ухудшается, когда происходит звонок по скайпу.
Буду признателен за идеи о том, как подойти к этому вопросу.
Ответы:
Когда время ваших соединений истекает, вы можете сделать это
arp -an
в Terminal.app и посмотреть, все ли у вас все MAC-адреса в таблице ARP? как в - MAC-адрес вашего маршрутизатора, или хост, который вы пытаетесь пропинговать?Если вы это сделаете (и у вас есть время до того, как он снова начнет работать), можете ли вы очистить таблицу arp (
sudo arp -ad
), а затем посмотреть, появляется ли MAC-адрес вашего маршрутизатора снова в таблице ARP?Кроме того, попробуйте выполнить проверку связи с IP-адресом локальной сети маршрутизатора в одном сеансе терминала и, возможно, проверить связь с IP-адресом глобальной сети маршрутизатора в другом сеансе Skype. Посмотрите, начнут ли они все время или только один из них. Еще один инструмент, который я считаю полезным
mtr
- вам может понадобиться получить исходный код и скомпилировать его самостоятельно или использовать fink / macports или другой менеджер пакетов. Когда вы получите его, просто запустите его в пункт назначения где-то в Интернете, и он покажет вам, какой прыжок перестает отвечать.Как установить программное обеспечение из источников (таких как mtr) Требуется установить Xcode :
gzip -dc filename.tar.gz | tar -xvf -
, который обычно создает новый каталог в текущем каталоге и помещает туда содержимое архива)./configure --prefix=/usr/local
(пожалуйста, обратите внимание, мне нравится устанавливать программное обеспечение из исходных кодов,/usr/local
чтобы держать его подальше от двоичных файлов, установленных как часть системы;--prefix=/usr/local
опция настройки сделает именно это)make
sudo make install
источник
mtr
это отличный инструмент. К сожалению, здесь проблема гораздо меньше. Проблема, кажется, стоит между MacOS X и 192.168.1.1. Не надо охотиться за горизонтом Интернета ☺.Не могли бы вы сначала проверить, действительно ли вы используете сетевой интерфейс, вы должны:
Не могли бы вы посмотреть вывод следующих команд (если en0 - это имя сетевого интерфейса вашей карты Ethernet):
Чтобы помочь определить причину проблемы, вы можете создать определенное местоположение, используя только активированную карту Ethernet и, если возможно, только IPv4 или IPv6, но не оба одновременно:
Не могли бы вы выполнить следующую выдержку из возможных ошибок оборудования или драйверов:
(не пугайтесь, вы можете найти много информации о каналах Wi-Fi).
Следующее сообщение выставлено вашим netstat:
означает, что вы на самом деле являетесь целью глупого tcp syn-flooding (который является атакой отказа в обслуживании (DOS)).
Когда ваш:
дроссели на 6с, не могли бы вы запустить:
источник
ping 192.168.1.1
(которое не будет выполнять никаких запросов DNS).Automatic
конфигурацией.ifconfig -a
?Automatic
Местоположения в сетевых настройках», создал новое местоположение для «Дома и работы», и это, по-видимому, остановило тайм-ауты блоков.У меня была эта проблема в течение долгого времени (начиная с обновления до Mavericks), и после месяцев исследований, я думаю, я наконец нашел решение.
Прежде всего, на форумах Apple довольно много людей с такой же проблемой:
Так что это известная проблема, и я действительно не знаю, почему Apple еще не предоставила решение этой проблемы. В темах, перечисленных выше, есть много предложений, чтобы исправить это, но большинство из них не сработало. Некоторые временно решают проблему:
sudo rm -rf /Library/Preferences/SystemConfiguration
После этих мер сетевое соединение чувствует себя намного лучше, и я не испытываю падений в течение нескольких часов, а иногда даже дней. Но проблемы всегда возвращаются.
Этот вопрос и намеки на то, что проблема может быть связана с ARP, заставили меня начать дальнейшие исследования, и я нашел эту страницу , которая подробно описывает ошибку, а также содержит патч, который я привожу здесь:
Пожалуйста, обратитесь к предоставленной ссылке для подробного объяснения исправления, которое должно быть включено в будущее обновление ОС для Yosemite от Apple. Он отключает одноадресные ARP-запросы, что приводит к путанице с некоторым сетевым оборудованием, таким как домашний маршрутизатор.
После применения исправления и перезагрузки следует проверить,
возвращается
net.link.ether.inet.arp_unicast_lim: 0
. Если число не равно нулю, исправление было применено неправильно.После этого я обнаружил еще одну ветку в сообществах Apple, в которой содержится то же решение: Mavericks и Failed ARP, вызывающие обрывы сети! Что ж, после того, как вы узнаете, в чем проблема, найти правильное решение будет намного проще.
источник
Во-первых, я вижу, что Dropbox работает в вашей строке меню; Вы уже отключили это?
Во-вторых, попробуйте удалить любые другие элементы запуска / входа. Заглянуть:
Авторизоваться:
Запускать:
источник
Здесь содержится много информации о поиске и устранении неисправностей и диагностике, но иногда при устранении неисправностей интересно вернуться к основам и подвергнуть сомнению некоторые предположения.
Как я упоминал в комментарии, это выглядит очень похоже на включенный маршрутизатор QOS из-за того, что ваша машина временно превысила некоторую пропускную способность или ограничение скорости передачи пакетов.
Что делать, если вы работаете в OS X с разными шаблонами, объемами и объемами сетевого трафика, в отличие от Windows, и это настоящая причина, а не драйверы оборудования или программное обеспечение?
Я ожидаю, что запуск OS X коррелирует с вашими наблюдениями, но что, если это не является причиной временных сетевых пауз.
Вы пытались исследовать, что, если какие-либо фильтры QOS и изменения маршрутизации осуществлены вашим сетевым поставщиком? Рассматривали ли вы туннелирование всего трафика на другой компьютер (ssh или VPN), чтобы исключить тривиальные фильтры. (Если провайдер проводит глубокую проверку пакетов или назначение и ограничение истинной скорости - вы не сможете избежать этих коротких тайм-аутов.)
Я надеюсь, что есть ответ, который вы можете найти, взглянув на детали сети (и мы все узнаем что-то из изучения этих опций), но убедитесь, что вы также учитываете, что ваши инструменты измерения и добавленный трафик к ping / poke в вещах могут повлиять на количество трафика и сделать его более вероятным, Skype отключится для вас. Маршрутизаторы, которые я настроил, запрограммированы для отбрасывания ICMP-трафика перед всем остальным трафиком, так как, когда емкость ограничена - я бы предпочел сбой проверки связи и прохождение других пакетов. Ваш Интернет-провайдер и поставщик сети, возможно, настроили все аналогично.
источник
В дополнение ко всему этому вы можете убедиться, что Auto Proxy Discovery не включен (а также автоматическая настройка прокси). Это имеет тенденцию вызывать больше проблем, чем нет, и часто это не нужно.
источник
Со всей большой диагностической информацией в этом вопросе вы значительно сузили возможности.
Начнем с того, что ваш пинг до 192.168.1.1 сильно изолирует проблему либо для вашего маршрутизатора, компьютера или локальной сети. Это не проблема с DNS или вашим провайдером.
Меня больше всего беспокоят результаты ваших пинг-тестов до 192.168.1.1. Вы сделали что-то странное в их настройке?
Например, у вас есть успешные эхо-запросы с порядковыми номерами ICMP 24267, 24268 и 24269, затем 3 тайм-аута, а затем повторный успех с ICMP 24273. Таким образом, числа успехов кажутся правильными. Однако числа тайм-аутов совершенно разные. Я ожидал бы увидеть тайм-ауты запросов от ICMP 24270, 24271 и 24272, но вместо этого тайм-ауты сообщают ICMP 89806, 89807 и 89808. Я никогда не видел этого раньше, и поэтому мне кажется, что у вас есть сломанный сетевой стек на этом компьютер. Возможно, слишком много расширений. Есть ли шанс, что у вас установлен Netgear Genie? Или, может быть, программное обеспечение VPN?
В любом случае, я бы сказал, что пришло время отключить «улучшения», чтобы посмотреть, сможете ли вы найти виновного на компьютере.
редактировать
ОК, тайна раскрыта Порядковый номер ICMP является 16-битным полем. Рассматривается как целое число без знака, это означает, что оно имеет максимальное значение 65 535 и затем обнуляется. Таким образом, если локальная программа ping поддерживает 32-разрядный целочисленный счетчик (что, вероятно, будет по умолчанию), она может сообщить 32-разрядное целое число для отсутствующих пакетов. Однако при чтении ответов в ответе обязательно должны быть только последние 16 бит счетчика. Таким образом, ответ на порядковый номер 89805 будет 89505 & 0xFFFF, что составляет 24269.
источник
Я знаю, что это старая тема.
Но спасибо всем за устранение неисправностей. Все шаги помогли мне решить проблему, когда я мог пинговать хосты, но не подключался к ним через telnet.
Решение было довольно простым (впоследствии) убрал все ненужные вещи отсюда (как упоминал zac)
Авторизоваться:
~ / Библиотека / LaunchAgents / ~ / Библиотека / LaunchDaemons / Системные настройки> Пользователи и группы> Элементы входа
Запускать:
/ Library / LaunchAgents / / Library / LaunchDaemons / / Library / StartupItems / /Library/Preferences/com.apple.loginitems.plist (редко существует)
Еще раз спасибо всем
источник
Любопытная проблема, учитывая, что она сохраняется в Ethernet. У меня была похожая проблема, но я обнаружил, что проблема связана с помехами WiFi от других сетей. Переключение на полосу 5 ГГц исправило мою проблему, которая стоит того.
источник
Любые подсказки из /var/log/system.log?
как выглядит netstat -s?
Моя догадка говорит удалить / Library / Preferences / SystemConfiguration и добавить обратно сетевые интерфейсы вручную.
Похоже, вы уже многое попробовали.
источник
Выглядит похоже на это?
https://discussions.apple.com/thread/5483424?tstart=0
Я только что опубликовал это для Mavericks. Мысли?
источник
Mac OSX Советы http://hints.macworld.com/article.php?story=20080605143917233 о сброшенных соединениях, поскольку поиск DNS не выполняется в ожидании идентификации DCHP маршрутизатора.
Скорее всего, DNS и / или настройка ускорения в настройках модема и обход этого DNS помогут решить вашу проблему.
источник
Это пахнет, как будто другое устройство в вашей сети пытается использовать тот же IP, что и вы, или какие-то проблемы с DHCP.
Не могли бы вы посмотреть, сможете ли вы воспроизвести его после назначения статического IP-адреса?
Перейдите в «Настройки сети», выберите интерфейс Ethernet, расширенный, TCP / IP
Измените выпадающий список «Настроить IPv4» на «Вручную»
IPv4-адрес: 192.168.1.150 (что-то уникальное, не то, что DHCP назначил вам раньше) Маска подсети: 255.255.255.0 Маршрутизатор: 192.168.1.1
Сохранить
Затем попробуйте воспроизвести проблему еще раз. При выполнении этого теста убедитесь, что ваш Wi-Fi выключен, поэтому используется только ваш Ethernet. Это поможет сузить его.
Если проблема не устранена, загрузите Wireshark ( http://www.wireshark.org/ ), чтобы начать захват, воспроизвести проблему, сохранить дамп и позвольте нам взглянуть.
Кроме того, какой маршрутизатор / AP вы используете?
источник
Необходимо проверить две вещи, которые связаны с увеличением трафика локальной сети из-за появления новых соседей по комнате.
источник
Эй, ребята, у меня была точно такая же проблема, но я просто отключил наушники, которые использовал, и я разговаривал с моим другом в течение первых 10 минут, и он до сих пор не упал, когда до того, как он упал на 20 секунд.
Шнур моих наушников был разорван, поэтому это могло быть причиной проблемы, но я ничего не знаю о IP-адресе и пинге, и это, похоже, помогло мне. Если вы пытаетесь, и это не работает, не вините меня, потому что это решило мою проблему.
источник
я знаю, что это старая тема, но это помогло решить проблему, которая у меня была. Мой интернет иногда отключался, и пинг постоянно падал. Что бы решить мою проблему, отключив Wi-Fi или Ethernet (который я когда-либо использовал), а затем снова включите его. Конечно, это только временно решит проблему. Это было странно, потому что всякий раз, когда мой Mac Pro 4,1 имел эту проблему, мой ноутбук Mac также терял пинг. Это было почти так, как будто мой Mac Pro сломал бы мою сеть.
Я перепробовал так много вещей! заменяя модем, роутер, называется isp, купил usb для ethernet. ни одна из этих вещей не работала, пока я не попробовал это!
Я сделал то, что упомянуто выше, и это наконец решило проблему !!
источник
У меня была похожая проблема, и в моем случае она вызвана Tunnelblick, даже если VPN не был подключен. Я удалил его (с помощью деинсталлятора, а не просто перетащить в корзину), и проблема ушла.
источник