Интригующая проблема с подключением в OS X

Недавно у меня возникла эта проблема с подключением к Интернету на моем 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-адрес маршрутизатора в локальной сети — 192.168.1.1, а его IP-адрес в глобальной сети — 85.61.155.224.

На следующем снимке экрана во время звонка по скайпу видно:

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

Странное примечание: по какой-то странной причине проблема усугубляется, когда происходит звонок по скайпу.

Я был бы признателен за идеи о том, как подойти к этому вопросу.

Я тоже это испытываю! Это ооочень раздражает. Не уверен, что это началось с 10.8.3. Мой Mac получил степень MBA в середине 2012 года. Однако зависание сети может длиться до 15 секунд.
Пожалуйста, проверьте, настроен ли ваш Skype: Порт входящего подключения: 12794
Мой скайп настроен на порт 15973
Я добавил инструкцию по установке MTR в ответ Майка.
Я понял, что, по крайней мере, один раз WAN IP маршрутизатора изменился после массовой потери соединения. Что удивительно, так это то, что у других устройств нет абсолютно никаких проблем!
Хорошо, тогда - еще несколько вопросов. У вас есть отдельный роутер и точка доступа, или они все интегрированы? Если они отдельные - у вас есть коммутатор между Роутером и Точкой Доступа? Кроме того, если вы подключены через Ethernet, вы подключаетесь к тому же коммутатору (обратите внимание — я все еще имею в виду отдельное устройство)
Моя установка довольно проста: всего один роутер (livebox 2). Я пробовал разные конфигурации Wi-Fi и все порты Ethernet, но безуспешно. Это началось около 2 недель назад, и я совершенно не знаю, что могло спровоцировать это. Некоторые дни хуже других, это происходит в разное время... Не могу найти закономерности.
Какая у вас конфигурация DHCP? Возможно ли, что у вас есть статически назначенный IP-адрес, конфликтующий либо с другим статическим адресом, либо с адресом, предоставленным DHCP?
DHCP-сервер включен, но, пытаясь решить проблему, я установил статические IP-адреса для себя и других компьютеров в сети.
Когда это происходит, можете ли вы по-прежнему пинговать какие-либо другие устройства в той же локальной сети? Я не думаю, что проблема связана с DHCP или чем-то еще на уровне 3. Я думаю, что проблема связана с уровнем 2 - по какой-то причине ваш маршрутизатор / точка доступа перестает отвечать на трафик уровня 2 с вашего Mac. Хотя я понимаю, что у вас нет таких проблем с другими устройствами, для меня это указывает на проблему с вашим livebox 2. Возникают ли у вас подобные проблемы, когда ваш Mac подключен к другому Wi-Fi или другому соединению Ethernet? (например, на работе, у друга и т. д.)?
Вы используете тот же IP-адрес для Windows 7? Если нет, попробуйте. Ваш netstat показывает очень большое количество неудачных попыток подключения. Есть идеи, почему? На данный момент, я думаю, вам нужно настроить захват пакетов, чтобы увидеть, что происходит в сети, когда происходят тайм-ауты. Инструкции см. на support.apple.com/kb/HT3994 или попробуйте использовать deliciouscocoabytes.com/cpa . В частности, я хочу посмотреть, отправляет ли компьютер во время сбоя ping-запросы на маршрутизатор и есть ли ответы на ping-запросы по проводу, которые отправляются на другой MAC-адрес Ethernet.
→ Мигель: отличное решение проблем с сетью ☺ ! Очевидно, что внутреннего пинга к вашему маршрутизатору (192.168.1.1) достаточно, чтобы показать, что проблема находится между MacOS X и вашим маршрутизатором. Вы используете Automaticместоположение?
→ gentmatt & Miguel: не могли бы вы попробовать перейти на MacOS X 10.8.2 и проверить с помощью локального пинга, есть ли у вас такая же дыра в 6 с (или больше)?
Даниэль Асуэлос: Я удалил все свои местоположения и настроил новое местоположение, которое я назвал «ДОМ» только с Ethernet и аэропортом. Я установил статический IP-адрес на своем маршрутизаторе для Ethernet и еще один для аэропорта, и я ввел все вручную в конфигурацию сети.
Old Pro: Я попробую то, что вы предлагаете, и опубликую результаты как можно скорее. Спасибо!
@mike: эта проблема возникает только в этой сети ... Вчера я вышел и проверил общедоступные сети и обнаружил, что у меня нет этой проблемы. Это указывает на какую-то плохую связь между OS X и моим маршрутизатором.
→ Мигель: не используйте 2 разных интерфейса в MacOS X для анализа сетевой проблемы: исследуйте по одному. Начните с Ethernet. Ваша проблема выглядит типичной для Automaticконфигурации проклятой сети.
Всем: Большое спасибо за ваши ответы, особенно МАЙКУ, OLD PRO и DANIEL AZUELOS. Поскольку время награды истекло, а проблема все еще не устранена, я бросил кости между вами тремя, и DANIEL AZUELOS получит +50... НО я сразу же открою другую награду, поэтому, пожалуйста, потерпите меня.
Это признак сбоя маршрутизации в нисходящем направлении. В частности, я предполагаю, что либо таблица маршрутизации изменяется, либо фильтр QOS решает поставить ваши пакеты в очередь и доставить другие пакеты с более высоким приоритетом предпочтительно в течение определенного периода времени. У вас есть отличная помощь здесь, но я бы провел немного времени с вашим сетевым провайдером, чтобы понять, когда и как они будут ограничивать ваше соединение. Вы можете проверить это косвенно, сильно сократив другой трафик или направив этот трафик через VPN в центр обработки данных в другом месте, чтобы избежать элементарных триггеров QOS.
Мигель: тот факт, что вы, кажется, не пострадали от этого в любой другой сети, мне кажется, указывает на то, что проблема действительно между вашим маршрутизатором и Mac. Я не согласен с другими, что проблема с вашим провайдером. Когда возникает ваша проблема, вы не видите MAC-адрес вашего маршрутизатора в таблице ARP. Это более низкий уровень, чем DHCP, маршрутизация и т. д., поскольку для их работы требуется подключение уровня 2. У вас не работает подключение уровня 2, когда проблема проявляется. (подлежит уточнению)
(Часть 2): Единственная другая вещь, которую я бы проверил (если ваш маршрутизатор позволяет), — это войти в маршрутизатор с другого устройства и посмотреть, можете ли вы очистить, а затем увидеть MAC-адрес вашего Mac на маршрутизаторе, пока возникает проблема. (так похоже на то, что вы сделали на своем MBP). Это покажет, есть ли одностороннее подключение или нет подключения. У меня были похожие проблемы с точкой доступа Linksys — она переставала пересылать кадры Ethernet (что влияет на уровень 2), и в результате ВСЕ переставало работать. Мне удалось обойти проблему, переключив точку доступа на диапазон 5 ГГц.
@mike Понятно ... это определенно проблема между Mac и маршрутизатором. Я могу попытаться проверить MAC-адрес моего Mac с другого устройства во время разрыва соединения... но есть ли другой способ? Я должен попросить своих соседей по комнате сотрудничать для этого, и ни у кого из нас нет много свободного времени.
@mike Как ты думаешь, маленький снитч может быть возможной причиной? Я использую его в течение многих лет, и до сих пор такого не случалось... но, может быть, моя локальная сеть теперь более загружена, когда сюда переехали еще 2 человека... Что вы думаете?
Мигель — не уверен насчет Little Snitch — никогда им не пользовался. Я так не думаю, поскольку кажется, что проблема связана с уровнем 2. Обычно, когда приложения делают что-то по сети, они используют предоставляемый системой стек TCP/IP (либо с помощью системных вызовов, либо с помощью одной из многих платформ). Есть исключения, хорошими примерами являются брандмауэры и снифферы. Я все еще думаю, что если Little Snitch обходит системный стек TCP/IP, он делает это на уровне 3. Проверка того, виден ли Mac-адрес вашего MBP на другом устройстве (другом ПК или MAC), является хорошей идеей (подлежит уточнению)
(Часть 2) ... просто убедитесь, что вы пытаетесь запустить ping как для маршрутизатора, так и для другого устройства одновременно. Тот факт, что вы, кажется, не сталкиваетесь с такой же проблемой в другой сети, подтверждает, что проблема локальна для вашей настройки. Вы упомянули, что ваша локальная сеть стала более загруженной после переезда двух других людей. Значит ли это, что раньше таких проблем не было, или вы не сталкивались с ними так часто, но они все еще были? Это может означать, что интерфейс вашего маршрутизатора несколько перегружен. Какая марка и модель маршрутизатора?
Еще одна вещь, которую я хотел бы добавить, это попробовать запустить wireshark — это очень хороший (возможно, лучший?) и бесплатный анализатор пакетов. Вы можете запустить его на своем компьютере и посмотреть, отправляет ли он какие-либо кадры и пакеты через свой сетевой интерфейс, пока возникает проблема (например, вы ищете запросы ARP после того, как вы сбросили кеш arp), и если вы получение каких-либо ответов. Если ваша проблема вызвана, скажем, поврежденными фреймами, вы это увидите. Вам также понадобится XQuartz, если вам нужен графический интерфейс (который того стоит).
@mike, что вы думаете о том факте, что тайм-ауты ping сообщают о порядковых номерах ICMP из другой последовательности, чем об успехах ping? apple.stackexchange.com/a/91069/21703
→ mike: Wiresharkотличный инструмент, но предназначенный только для гуру, свободно владеющих опциями arp, ifconfig, netstatи ping☺.
Это происходит, когда вы полностью находитесь в другой сети, например, в школе или на работе? Если вы загружаете свой MacBook Pro в режим восстановления (загрузка, нажимая cmd + R), происходит ли это там через Safari и / или терминал? Если ответ на любой из этих вопросов отрицательный, я бы сделал резервную копию системы и переустановил ОС.
→ Мигель: ваша проблема проанализирована, исправлена? Вам все еще нужна помощь? Какой лучший ответ?
@danielAzuelos Проблема не решена. Я отказался от звонков по скайпу в определенные часы.
@danielAzuelos Нет лучшего ответа, но ответы, получившие награды, — это те, которые, по моему мнению, были ближе всего к решению.
→ Мигель: еще раз прочитав ваше первоначальное описание проблемы, я убежден, что это типично для Automaticконфигурации местоположения MacOS X. Это ключевое отличие от Windows.
Для меня странно то, что у меня такая же проблема, но я использую эксклюзивную ОС Microsoft на своем MacBook Pro 15 дюймов 2008 года. Я получаю замедление трафика как в Wi-Fi, так и в Ethernet. Есть ли решение? Это связано с оборудованием? Спасибо

Ответы (17)

Когда время ваших подключений истекает, можете ли вы сделать это arp -anв Terminal.app и посмотреть, есть ли у вас все MAC-адреса в таблице ARP? например, MAC-адрес вашего маршрутизатора или хост, который вы пытаетесь пропинговать?

Если вы это сделаете (и у вас есть время, прежде чем он снова начнет работать), можете ли вы очистить таблицу arp ( sudo arp -ad), а затем посмотреть, появляется ли снова MAC-адрес вашего маршрутизатора в таблице ARP?

Кроме того, попробуйте пропинговать IP-адрес вашего маршрутизатора в локальной сети в одном сеансе терминала и, возможно, пропинговать IP-адрес вашего маршрутизатора в глобальной сети в другом, пока вы находитесь в Skype. Посмотрите, все ли из них начинают тайм-аут или только один из них. Еще один инструмент, который я считаю полезным, mtr- вам может понадобиться получить исходный код и скомпилировать его самостоятельно или использовать fink/macports или другой менеджер пакетов. Когда вы его получите, просто запустите его где-нибудь в Интернете, и он покажет вам, какой переход перестает отвечать.

Как установить программное обеспечение из источников (например, mtr) Требуется установить Xcode :

  • скачать исходный архив (обычно .tar.gz или .tar.bz2)
  • распакуйте загруженный файл (например, в Terminal.app run gzip -dc filename.tar.gz | tar -xvf -, который обычно создает новый каталог в текущем каталоге и помещает туда содержимое архива)
  • перейдите к полученной папке в терминале
  • запустите ./configure --prefix=/usr/local(обратите внимание, я предпочитаю устанавливать программное обеспечение из исходного кода /usr/local, чтобы оно не устанавливалось в бинарные файлы, установленные как часть системы; --prefix=/usr/localопция настройки сделает именно это)
  • бегmake
  • бегsudo make install
  • сделано!
Сделал это, скоро отредактирую вопрос с результатами.
Когда я делаю «arp -an» после удаления таблицы, маршрутизатор не отображается до тех пор, пока соединение не будет восстановлено.
→ Майк: mtrотличный инструмент. К сожалению, здесь проблема гораздо менее далека. Проблема, кажется, стоит между MacOS X и 192.168.1.1. Не нужно гнаться за горизонтом интернета ☺.
Эта команда действительно помогла мне.

Не могли бы вы сначала проверить, что вы действительно используете сетевой интерфейс, который вы должны:

ifconfig -a

Не могли бы вы взглянуть на вывод следующих команд (если en0 — это имя сетевого интерфейса вашей Ethernet-карты):

netstat -I en0

Чтобы помочь найти проблему, не могли бы вы создать конкретное местоположение только с активированной картой Ethernet и, если возможно, только с IPv4 или IPv6, но не с обоими:Местоположение с включенным только Ethernet

Не могли бы вы запустить следующий фрагмент потенциальных ошибок оборудования или драйверов:

grep ' en[012]' /var/log/kernel.log

(не пугайтесь, вы можете найти много информации о каналах Wi-Fi).

Следующее сообщение, выставленное вашим netstat:

44620 embryonic connections dropped

означает, что вы на самом деле являетесь целью глупого синхропотока tcp (который представляет собой атаку типа «отказ в обслуживании» (DOS)).

Когда ваш:

ping 192.168.1.1

дроссели на 6 секунд, не могли бы вы запустить:

netstat -m
Когда 192.168.1.1 забивается, netstat -m не показывает ничего необычного. Кстати, grep не может найти '/var/log/kernel.log'. Я редактирую вопрос с результатами «netstat -I en1» (сейчас я использую en1, который является моим аэропортом, en0 неактивен). В чем может быть причина DOS-атаки?
→ Мигель: чтобы упростить анализ вашей проблемы, создайте новую сетевую конф. с включенным только интерфейсом Ethernet. Затем держитесь в окне a ping 192.168.1.1(которое не будет выполнять никаких DNS-запросов).
→ Мигель: возможно, вы невольно стали автором своей DOS-атаки ☹, но это еще предстоит подтвердить. Я подозреваю, что сетевая петля вызвана Automaticконфигурацией.
→ Мигель: не могли бы вы предоставить нам ifconfig -a?
Я отредактирую вопрос сейчас с результатами.
Я создал новую сетевую конфигурацию только с ethernet и буду пинговать «192.168.1.1» в течение следующих 24 часов, чтобы посмотреть, что произойдет.
→ Мигель: не могли бы вы предоставить нам ifconfig -aконфигурацию только для Ethernet? Если вам посчастливилось решить проблему в Ethernet, то гораздо проще сосредоточиться на этой более простой форме проблемы (Ethernet — это 1 измерение, а Wireless — 3 ☺).
Это решило мою проблему, я переместил Automaticместоположение в сетевых настройках, создал новое местоположение для дома и работы, и это, похоже, остановило тайм-ауты блокировки.

У меня была эта проблема уже давно (начиная с обновления до Mavericks), и после нескольких месяцев исследований я думаю, что наконец нашел решение.

Во-первых, на форумах Apple довольно много людей с точно такой же проблемой:

Итак, это известная проблема, и я действительно не знаю, почему Apple до сих пор не предоставила для нее исправления. В темах, перечисленных выше, есть много предложений по исправлению этого, но большинство из них не сработало. Некоторые решают проблему временно:

  • Отключите и снова подключите сеть
  • Старый друг: перезагрузка
  • Удалите папку, содержащую конфигурацию сети:sudo rm -rf /Library/Preferences/SystemConfiguration

После этих мер сетевое соединение чувствует себя намного лучше, и я не испытываю обрывов в течение нескольких часов, а иногда и дней. Но проблемы всегда возвращаются.

Этот вопрос и намеки на то, что проблема может быть связана с ARP, побудили меня начать дальнейшие исследования, и я нашел эту страницу , на которой подробно описана ошибка, а также содержится патч, который я привожу здесь:

sudo su
touch /etc/sysctl.conf
echo net.link.ether.inet.arp_unicast_lim=0 >> /etc/sysctl.conf
chown root:wheel /etc/sysctl.conf
chmod 0644 /etc/sysctl.conf

Пожалуйста, обратитесь к предоставленной ссылке для подробного объяснения исправления, которое должно быть включено в будущее обновление ОС для Yosemite от Apple. Он отключает одноадресные запросы ARP, которые вызывают путаницу с некоторым сетевым оборудованием, таким как ваш домашний маршрутизатор.

После применения исправления и перезагрузки следует проверить,

sudo sysctl -a | grep net.link.ether.inet.arp_unicast_lim

возвращается net.link.ether.inet.arp_unicast_lim: 0. Если число не равно нулю, исправление было применено неправильно.

Впоследствии я нашел еще одну ветку в сообществах Apple, которая содержит то же решение: Mavericks и Failed ARP, вызывающие обрывы сети! Что ж, после того, как вы узнаете, в чем проблема, найти правильное решение намного проще.

Во-первых, я вижу дропбокс в строке меню; ты еще не отключил это?

Во-вторых, попробуйте удалить любые другие элементы запуска/логина. Заглянуть:

Авторизоваться:

  1. ~/Библиотека/LaunchAgents/
  2. ~/Библиотека/LaunchDaemons/
  3. Системные настройки > Пользователи и группы > Элементы входа

Запускать:

  1. /Библиотека/LaunchAgents/
  2. /Библиотека/LaunchDaemons/
  3. /Библиотека/Элементы автозагрузки/
  4. /Library/Preferences/com.apple.loginitems.plist (существует редко)
Я не пытался отключить Dropbox, поможет ли это? А также, не могли бы вы объяснить причину удаления этих предметов? Спасибо!
Вы хотите определить, связана ли проблема с OS X или частью программного обеспечения, которое было добавлено после первоначальной установки. Такие вещи, как Dropbox, который устанавливает сетевые подключения, как только загружается учетная запись пользователя, или антивирусное программное обеспечение, которое обычно работает во всех учетных записях пользователей, могут резервировать порт или иным образом способствовать возникновению проблемы.
Хорошо, я сделаю это и опубликую здесь результаты завтра.
→ Мигель: Dropbox не может быть вашей проблемой. Dropbox просто выполняет 443/tcp, как и любой другой веб-браузер. Но в случае, если вы хотите выполнить анализ сети (Wireshark или tcpdump), остановка Dropbox удалит вам кучу TCP-трафика. Следовательно, это поможет вам «увидеть» любое неправильное поведение.
Это несколько хороших догадок по устранению неполадок, но если бы вы объяснили, как и почему, по вашему мнению, эти элементы повлияют на непрерывность сети, ответ был бы более полезен для ОП, но также научил бы людей в подобных ситуациях тому, почему вы предложили это как в отличие от чего-то, чтобы исключить.
@ Мигель, еще несколько догадок. 1. Обращались ли вы к своему интернет-провайдеру, чтобы узнать, могут ли они проверить качество линии? 2. как насчет настройки тестовой учетной записи пользователя, чтобы увидеть, изменится ли проблема. Третье предложение — проверить вашу систему — такие вещи, как проверка разрешений — диагностика машины. 4. не могли бы вы заменить компоненты - запустите свой компьютер у друга - одолжите роутер у друга - да, и удалите все остальное сетевое оборудование из вашей системы.
@DavidDelMonte, компьютер отлично работает в других местах. Я попробую настроить новую учетную запись пользователя. Мой интернет-провайдер говорит мне, что все в порядке, и на других машинах в моей сети нет проблем. Починил разрешения и все отлично, но не могу поменять местами компоненты.

Здесь содержится много информации об устранении неполадок и диагностике, но иногда при устранении неполадок интересно вернуться к основам и подвергнуть сомнению некоторые предположения.

Как я упоминал в комментарии, это очень похоже на то, что маршрутизатор QOS срабатывает из-за того, что ваша машина временно превышает ограничение пропускной способности или скорости передачи пакетов.

Что, если вы выполняете разные шаблоны, объемы и объемы сетевого трафика в OS X, а не в Windows, и это настоящая причина, а не драйверы оборудования или программное обеспечение?

Я ожидаю, что запуск OS X коррелирует с вашими наблюдениями, но что, если это не причина временных пауз в сети.

Вы пробовали исследовать, что если какие-либо фильтры QOS и изменения маршрутизации реализованы вашим сетевым провайдером? Рассматривали ли вы туннелирование всего трафика на другой компьютер (ssh или VPN), чтобы исключить тривиальные фильтры. (Если провайдер проводит глубокую проверку пакетов или ограничивает пункт назначения и истинную скорость, возможно, вы не сможете избежать этих коротких тайм-аутов.)

Я надеюсь, что есть ответ, который вы сможете найти, изучив детали сети (и мы все узнаем что-то, изучив эти параметры), но убедитесь, что вы также учитываете, что ваши инструменты измерения и добавленный трафик для ping/poke на вещи могут влияют на подсчет трафика и повышают вероятность того, что Skype упадет для вас. Маршрутизаторы, которые я настроил, запрограммированы на отбрасывание трафика ICMP перед всем остальным трафиком, поскольку, когда пропускная способность становится ограниченной, я бы предпочел, чтобы пинг не прошел, и другие пакеты прошли. Ваш интернет-провайдер и сетевой провайдер могли настроить все аналогично.

Понятно... но в моей сетевой активности за последние 5 лет ничего не изменилось. Эта проблема началась около месяца назад, и я не могу найти никаких корреляций, за исключением того, что это было около месяца назад, когда въехали 2 коллеги. Но я провел тесты ping на их машинах, и они не испытывают этой проблемы. Мне ничего не известно о каких-либо QOS-фильтрах, но я постараюсь выяснить.
Skype принимает звонки почти круглосуточно и без выходных на моем компьютере... Сегодня я отключу все пинги и т. д., чтобы посмотреть, не изменится ли что-то в следующий раз, когда соединение прервется (потому что я все еще могу сказать, если оно прервется, слушая звук). получаю от скайп звонка)

В дополнение ко всему вышеперечисленному, вы можете убедиться, что автоматическое обнаружение прокси-сервера не включено (а также автоматическая настройка прокси-сервера). Это, как правило, вызывает больше проблем, чем нет, и часто в этом нет необходимости.

Системные настройки

Спасибо за совет, они уже были выключены :(

Со всей большой диагностической информацией в этом вопросе вы значительно сузили возможности.

Начнем с того, что ваш эхо-запрос на 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.

Привет. Я не делал ничего странного... это просто "sudo ping 192.168.1.1"... Я понимаю, что вы говорите о порядковых номерах ICMP... Я понятия не имею, почему это может быть... пинг шел слишком долго? (работает уже несколько дней)... Понятия не имею. Кроме того, моя сетевая конфигурация очень проста, и я использую одну и ту же конфигурацию в течение многих лет без каких-либо проблем.
Программное обеспечение, которое всегда работает в фоновом режиме и может иметь какое-то отношение к этому: Little Snitch, Dropbox, Skype и все такое для OS X... но ничего нового, и проблема началась около месяца назад. Одна вещь, которую я подозреваю, это то, что это было около месяца назад, когда въехали 2 новых соседа по комнате. Я провел пинг-тесты на их компьютерах, и у них нет этой проблемы.
@Miguel, определенно удалите Little Snitch, поскольку это именно то программное обеспечение, которое может создавать эту проблему. Если у вас нет сложной конфигурации, я бы посоветовал полностью удалить ее и даже очистить корзину, чтобы убедиться, что она исчезла, перезагрузиться и посмотреть, решит ли это проблему.
Хорошо, я полностью удалю его и посмотрю, что произойдет (но я использую его уже много лет без проблем).
Забавно... 24269 в двоичной форме равно 0000 0101 1110 1100 1101. 89806 в двоичной форме равно 0001 0101 1110 1100 1110. Однако, если мы возьмем 24269 и просто поменяем местами бит 16, мы получим 0001 0101 1110 1100 1101 = 89805. выглядит как целое число со знаком и без знака, так что это чисто числовое представление. Возможно, устройство, которое пингует Мигель, использует целое число без знака вместо знакового (или наоборот)...

Я знаю, что это старая тема.

Но спасибо всем за это устранение неполадок. Все шаги помогли мне устранить проблему, из-за которой я мог пинговать хосты, но не мог подключиться к ним через telnet.

Решение было довольно простым (впоследствии) удалил все лишнее отсюда (как упоминал Зак)

Авторизоваться:

~/Library/LaunchAgents/ ~/Library/LaunchDaemons/ Системные настройки > Пользователи и группы > Элементы входа

Запускать:

/Library/LaunchAgents/ /Library/LaunchDaemons/ /Library/StartupItems/ /Library/Preferences/com.apple.loginitems.plist (существует редко)

Еще раз всем спасибо

Любопытная проблема, учитывая, что она сохраняется в сети Ethernet. У меня была аналогичная проблема, но я обнаружил, что проблема связана с помехами WiFi от других сетей. Переключение на диапазон 5 ГГц решило мою проблему, и, думаю, стоит попробовать.

Прежде чем менять сетевой канал, потому что вы считаете, что у вас есть проблема с помехами, просто четко диагностируйте ее. Это довольно просто: используйте istumbler.net . Вы посмотрите правде прямо в глаза ☺.

Какие-нибудь подсказки из /var/log/system.log?

как выглядит netstat -s?

Моя догадка говорит, что нужно удалить /Library/Preferences/SystemConfiguration и вручную добавить сетевые интерфейсы.

Хотя, похоже, вы уже многое перепробовали.

Привет, Мигель, добавляю больше вуду после просмотра ваших снимков экрана. не могли бы вы попробовать эти три вещи: 1: отключить Bluetooth, 2: проверить сетевые интерфейсы 1 на 1? 3: просто чтобы подтвердить, вы используете стандартные сетевые драйверы, верно?
Журнал system.log огромен... Я искал конкретные слова, но ничего подходящего не нашел :(
Я отредактирую вопрос, добавив данные, которые мне дал netstat -s.
Я уже удалил всю конфигурацию сети. и добавил все обратно вручную, но безуспешно. Bluetooth всегда был выключен. Я использую стандартные сетевые драйверы. Все сетевые интерфейсы дают абсолютно одинаковые результаты: то и дело моментальная потеря связи :(
Меня беспокоят ошибки пакетов icmp и ip. отдельно установите свежую копию OSX и загрузитесь с нее через USB. Это изолирует вашу установку OSX. если свежая копия остается с ошибками, значит, у нас аппаратная ошибка - кто знает, может быть, ее вызовут только драйверы OSX. Покажите, что проблема появляется при новой установке, и Apple должна исправить ее для вас.
Я сделаю это, если у меня будет свободное время, у меня много работы, которую нужно сделать :\

Похоже на это?

https://discussions.apple.com/thread/5483424?tstart=0

Я только что разместил это для Mavericks. Мысли?

Хотя эта ссылка может ответить на вопрос, лучше включить сюда основные части ответа и предоставить ссылку для справки. Ответы, содержащие только ссылку, могут стать недействительными, если связанная страница изменится.
Я постараюсь взглянуть на решение по ссылке, чтобы увидеть, поможет ли оно мне. Опубликую обратно.

Подсказки Mac OSX http://hints.macworld.com/article.php?story=20080605143917233 о разорванных соединениях из-за сбоя поиска DNS в ожидании DCHP-идентификации маршрутизатора.

try configuring your Mac to use the OpenDNS (OpenDNS.ORG) servers 
instead of your ISPs DNS servers.

Скорее всего, DNS и/или настройка ускорения в настройках вашего модема и обход этого DNS должны помочь решить вашу проблему.

Это не вызвало бы эту проблему. ping выполняет поиск DNS один раз (в данном случае google.com -> 173.194.34.196), а затем использует IP-адрес.
Сделаю это и отчитаюсь.
→ Blip: это не проблема, связанная с DNS. Пинг к маршрутизатору с IP-адресом не создает никаких пакетов udp, просто глупое эхо icmp.

Это похоже на то, что другое устройство в вашей сети пытается использовать тот же 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/ ), начать захват, воспроизвести проблему, сохранить дамп и дать нам взглянуть.

Кроме того, какой маршрутизатор / точка доступа вы используете?

Две вещи, которые нужно проверить, коррелируют с тем, что это вызвано увеличением трафика локальной сети из-за новых соседей по комнате.

  1. Есть ли на роутере настройки QoS (Quality of Service), и если да, то как? Трафик Skype будет иметь приоритет, и если глобальная сеть станет перегруженной, маршрутизатор может отреагировать, временно отключив соединения с более низким приоритетом.
  2. ЦП маршрутизатора просто перегружается? Когда я перешел с DSL 1 Гбит/с на кабельную сеть 5 Гбит/с, я обнаружил, что мой маршрутизатор просто не справляется с возросшим трафиком, и мне пришлось купить новый. Изучите производительность вашего маршрутизатора и посмотрите, может ли это быть проблемой. Подробные обзоры производительности большинства маршрутизаторов доступны в Интернете; проверьте и посмотрите, как оценивается ваш маршрутизатор по сравнению с пропускной способностью вашего интернет-сервиса.

Привет, ребята, у меня была точно такая же проблема, но я просто отключил наушники, которые использовал, и я разговаривал со своим другом в течение первых 10 минут, и он до сих пор не упал, когда раньше он упал на 20 секунд.

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

Решение было довольно простым (впоследствии) удалил все лишнее отсюда (как упоминал Зак)

Авторизоваться:

~/Library/LaunchAgents/ ~/Library/LaunchDaemons/ Системные настройки > Пользователи и группы > Элементы входа

Запускать:

/Library/LaunchAgents/ /Library/LaunchDaemons/ /Library/StartupItems/ >/Library/Preferences/com.apple.loginitems.plist (существует редко)

Я знаю, что это старый поток, но это решило проблему, с которой я столкнулся. Мой интернет иногда отключался, и пинг постоянно падал. Что могло бы решить мою проблему, так это отключить Wi-Fi или Ethernet (что я когда-либо использовал), а затем снова включить его. Конечно, это лишь временно решит проблему. Это было странно, потому что всякий раз, когда у моего Mac Pro 4,1 возникала эта проблема, мой ноутбук Mac также терял пинг. Это было похоже на то, что мой Mac Pro отключит мою сеть.

Я столько всего перепробовал! заменил модем, роутер, позвонил провайдеру, купил usb для ethernet. ни одна из этих вещей не работала, пока я не попробовал это!

Я сделал то, что упоминалось выше, и это, наконец, решило проблему!

У меня была аналогичная проблема, и в моем случае она, похоже, была вызвана Tunnelblick, даже когда VPN не был подключен. Я удалил его (с помощью деинсталлятора, а не просто перетащил в корзину), и проблема исчезла.

Интригующая проблема с подключением в OS X
СпросиСетьПолитика конфиденциальности1y, 0v