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

Нещодавно у мене виникло це питання з підключенням до Інтернету на моєму MacBook Pro Early 2011 під керуванням OS X 10.8.3: час від часу з'єднання «зависає» приблизно на 5 секунд, а потім повертається назад.

Це відбувається як через Wi-Fi, так і через кабель Ethernet , і це відбувається лише з моєю машиною, коли він працює під керуванням OS X (це не відбудеться під час роботи Windows 7 на тій же машині або на будь-якій іншій машині / пристрої). Це робить дзвінки через скайп кожні 2 хвилини або близько того, тому це дуже засмучує.

Pinging 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

Примітка: Wi-Fi MAC моєї машини становить 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, а WAN IP - 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, оскільки це відбувається і через кабель.
• Це не проблема маршрутизатора / провайдера, оскільки інші пристрої та машини не мають проблем.
• Це не проблема з машиною, оскільки це відбувається лише під час роботи ОС X.
• Тому це повинно бути проблемою OS X.

Що я спробував:

• Перезапуск, вимкнення.
• Вмикайте та вимикайте AirPort, різні кабелі Ethernet.
• Ремонт дозволів.
• Скиньте ПРАМ.
• Очистіть усі кеші системи та користувачів за допомогою Onyx.

Дивна примітка: З якоїсь дивної причини проблема, здається, загострюється, коли відбувається дзвінок по скайпу.

Я дуже вдячний ідеям, як підійти до цього питання.

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

Якщо у вас є (і у вас є час, перш ніж він почне працювати знову), можете ви промити таблицю arp ( sudo arp -ad), а потім побачити, чи MAC-адреса вашого маршрутизатора знову відображається в таблиці ARP?

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

Як встановити програмне забезпечення з джерел (наприклад, mtr) Потрібно встановити Xcode :

• завантажте вихідний архів (зазвичай .tar.gz або .tar.bz2)
• розпакуйте завантажений файл (наприклад, у запуску Terminal.app gzip -dc filename.tar.gz | tar -xvf -, який, як правило, створить нову директорію у поточному каталозі та помістіть вміст архіву туди)
• перейдіть до отриманої папки в терміналі
• запустити ./configure --prefix=/usr/local(будь ласка, зверніть увагу, мені подобається встановлювати програмне забезпечення з джерела, /usr/localщоб не подати його до бінарних файлів, встановлених як частина системи; --prefix=/usr/localможливість налаштування буде робити саме це)
• бігати make
• бігати sudo make install
• зроблено!

Ви можете спочатку перевірити, чи справді ви використовуєте мережевий інтерфейс, який вам слід:

ifconfig -a

Чи можете ви подивитись на висновки наступних команд (якщо en0 - це мережевий інтерфейс вашої картки Ethernet):

netstat -I en0

Щоб допомогти знайти проблему, ви можете зробити конкретне місце з активованою лише вашою Ethernet-карткою, і, якщо можливо, використовуючи лише IPv4 або IPv6, але не обидва:

Чи можете ви запустити наступний витяг потенційних апаратних чи драйверних помилок:

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

(не лякайтеся, ви можете знайти багато інформації про канали Wi-Fi).

Наступне повідомлення, виставлене вашим netstat:

44620 embryonic connections dropped

означає, що ви насправді є ціллю дурного затоплення синхросигналу tcp (що є атакою відмови в обслуговуванні (DOS)).

Коли:

ping 192.168.1.1

дроселі на 6s, чи можете ви запустити:

netstat -m

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

Перш за все, на форумах Apple є досить багато людей з такою самою проблемою:

• Чому в OS X Mavericks Інтернет настільки повільний?
• Випуск мережі Mavericks

Тож це відома проблема, і я справді не знаю, чому 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. Якщо число не дорівнює нулю, виправлення було застосовано неправильно.

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

По-перше, я бачу папку, що працює у вашому рядку меню; Ви все ж відключили це?

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

Вхід:

1. ~ / Бібліотека / LaunchAgents /
2. ~ / Бібліотека / LaunchDaemons /
3. Налаштування системи> Користувачі та групи> Елементи входу

Стартап:

1. / Бібліотека / LaunchAgents /
2. / Бібліотека / LaunchDaemons /
3. / Бібліотека / StartupItems /
4. /Library/Preferences/com.apple.loginitems.plist (рідко існує)

Тут є велика кількість інформації щодо усунення несправностей та діагностичного завершення речей, але іноді при усуненні неполадок цікаво повернутися до основ і поставити під сумнів деякі припущення.

Як я вже згадував у коментарі, це дуже схоже на запуск маршрутизатора QOS через те, що ваша машина тимчасово перевищує деяку пропускну здатність або обмеження частоти пакетів.

Що робити, якщо ви працюєте з різними моделями, обсягами та обсягами мережевого трафіку під час роботи з ОС X на відміну від Windows, і це справжня причина, а не драйвери обладнання або програмне забезпечення?

Я б очікував, що запуск ОС X корелює з вашими спостереженнями, але що робити, якщо це не є причиною тимчасових мережних пауз.

Ви спробували дослідити, що робити, якщо які-небудь фільтри QOS та зміни маршрутизації реалізуються постачальником мережі? Чи розглядали ви тунелювання всього трафіку на інший комп'ютер (ssh або VPN), щоб ви могли виключити тривіальні фільтри. (Якщо постачальник проводить глибоку перевірку пакетів, або призначення, і обмеження справжньої швидкості - ви, можливо, не зможете уникнути цих коротких тайм-аутів.)

Я сподіваюся, що ви знайдете відповідь, переглянувши деталі мережі (і ми все дізнаємось щось, вивчивши ці варіанти) - але будьте впевнені, ви також врахуєте, що ваші інструменти вимірювання та додали трафік до ping / poke на речі впливати на кількість трафіку і зробити його більш імовірним, що скайп для вас зменшиться. Налаштовані мною маршрутизатори запрограмовані знижувати трафік ICMP перед тим, як весь інший трафік, оскільки коли потужність стає недостатньою, я вважаю за краще провалитись, і інші пакети пройдуть. Ваш Інтернет-провайдер і постачальник послуг могли налаштувати подібне.

На додаток до всіх матеріалів тут, ви можете переконатися, що функція автоматичного виявлення проксі не ввімкнена (як і автоматична конфігурація проксі). Це, як правило, викликає більше проблем, ніж ні, і часто не потрібно.

Маючи всю чудову діагностичну інформацію в цьому питанні, ви значно звузили можливості.

Для початку ваші пінгви до 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.

Рішення було досить простим (згодом) видалило звідси всі непотрібні речі (як зак згадано)

Вхід:

~ / Бібліотека / LaunchAgents / ~ / Бібліотека / LaunchDaemons / Налаштування системи> Користувачі та групи> Елементи входу

Стартап:

/ Бібліотека / LaunchAgents / / Бібліотека / LaunchDaemons / / Бібліотека / StartupItems / /Library/Preferences/com.apple.loginitems.plist (рідко існує)

Ще раз дякую всім

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

Будь-які підказки з /var/log/system.log?

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

У моїй думці сказано видалити / Бібліотека / Налаштування / SystemConfiguration та додати назад мережеві інтерфейси вручну.

Схоже, ви вже пробували багато речей.

Схожий на це?

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 повинен допомогти вирішити вашу проблему.

Це пахне тим, що інший пристрій у вашій мережі намагається використовувати той самий 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 ви використовуєте?

Дві речі, щоб перевірити, що співвідноситься з цим, викликано збільшенням трафіку локальної мережі через нових сусідів по кімнаті.

1. Чи є на маршрутизаторі налаштування QoS (Якість обслуговування), і якщо так, то як вони встановлюються? Трафік через Skype був би пріоритетним, і якщо WAN перенасичується, маршрутизатор може відповісти тимчасовим відключенням з'єднань нижчого пріоритету.
2. Це процесор маршрутизатора просто перевантажений? Коли я модернізував з 1 Гбіт DSL до 5 Гб кабельного сервісу, я виявив, що мій маршрутизатор просто не може йти в ногу зі збільшенням трафіку і мусив купувати новий. Дослідіть продуктивність маршрутизатора і перевірте, чи це може бути проблемою. Більшість маршрутизаторів мають детальні огляди продуктивності, доступні в Інтернеті; перевірте і подивіться, як оцінюється ваш маршрутизатор порівняно з вашими можливостями Інтернет-сервісу.

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

Шнур моїх навушників був зірваний, тому це, можливо, спричинило проблеми, але я не знаю багато нічого про ip-адресу та речі для пінгу, і це, здавалося, допомогло мені. Якщо ви спробуєте, і це не працює, не звинувачуйте мене, бо це виправило мою проблему.

Рішення було досить простим (згодом) видалило звідси всі непотрібні речі (як зак згадано)

Вхід:

~ / Бібліотека / LaunchAgents / ~ / Бібліотека / LaunchDaemons / Налаштування системи> Користувачі та групи> Елементи входу

Стартап:

/ Бібліотека / LaunchAgents / / Бібліотека / LaunchDaemons / / Бібліотека / StartupItems /> /Library/Preferences/com.apple.loginitems.plist (рідко існує)

Я знаю, що це стара тема, але це вирішило проблему, яку я мав. Мій Інтернет час від часу відключається, а пінг весь час падає. Що могло б вирішити мою проблему - це вимкнути wi-fi чи Ethernet (якими я колись користувався), а потім повторно увімкнути його. Звичайно, це лише тимчасово усуне проблему. Це було дивно, бо коли б у мого mac pro 4,1 виникло це питання, мій ноутбук Mac також втрачав пінг. Це було майже так, як мій Mac Pro звів мою мережу.

Я спробував так багато речей! замінивши модем, роутер, званий isp, купив usb на Ethernet. жодна з цих речей не працювала, поки я не спробував цього!

Я зробив те, що було сказано вище, і це, нарешті, вирішило проблему !!

У мене була подібна проблема, і в моєму випадку, здається, це викликано Tunnelblick, навіть коли VPN не був підключений. Я його видалив (із видаленням, а не просто перетягніть у кошик), і проблема пішла.