Sự cố kết nối hấp dẫn trên OS X


33

Gần đây tôi đã gặp sự cố này với kết nối internet của mình trên MacBook Pro đầu năm 2011 chạy OS X 10.8.3: thỉnh thoảng kết nối "đóng băng" trong khoảng 5 giây và sau đó quay lại.

Nó xảy ra cả qua Wi-Fi hoặc qua cáp Ethernetnó chỉ xảy ra với máy của tôi khi chạy OS X (điều này sẽ không xảy ra khi chạy Windows 7 trên cùng một máy hoặc trên bất kỳ máy / thiết bị nào khác). Nó làm cho Skype thả cuộc gọi cứ sau 2 phút hoặc lâu hơn, vì vậy nó rất bực bội.

Ping Google.com trông như thế này khi chạy OS X (có hàng trăm gói trở lại trong vòng chưa đến 100ms (với một vài trong phạm vi 130), sau đó giảm xuống trong vài giây) :

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

Lưu ý: MAC Wi-Fi của máy tôi là 68: a8: 6d: 29: cf: 8a (IP tĩnh 192.168.1.250) và địa chỉ Ethernet của nó là 3c: 07: 54: 5a: e0: 44 (IP tĩnh 192.168.1.251) . LAN IP của bộ định tuyến là 192.168.1.1 và IP IP của nó là 85.61.155.224.

Trong ảnh chụp màn hình tiếp theo, người ta có thể thấy, trong một cuộc gọi Skype:

  • ping 192.168.1.1 ở phía trên bên trái.
  • ping 85.61.155.224 ở phía dưới bên trái.
  • ping google.com ở phía dưới bên phải.
  • các lệnh arp -anvà được arp -adthực thi.

Khi tôi thực thi arp -adlệnh tại thời điểm mất kết nối, danh sách không hiển thị bất kỳ địa chỉ nào. Nó trông như thế này:

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$

Tôi không có đủ kiến ​​thức để làm theo hướng dẫn của mike về cách lấy và biên dịch nguồn mtrlệnh.

ảnh chụp màn hình của các hoạt động

Đây là cách mọi thứ nhìn khi nó tồi tệ hơn:

ảnh chụp màn hình tình huống xấu nhất

Chạy netstat -scho:

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

Chạy netstat -I en1cho:

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

Chạy ifconfig -acho:

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

Những gì tôi nghĩ:

  • Đây không phải là vấn đề Wi-Fi vì nó cũng xảy ra qua cáp.
  • Đây không phải là vấn đề về bộ định tuyến / ISP vì các thiết bị và máy khác không có vấn đề gì.
  • Đây không phải là sự cố máy vì nó chỉ xảy ra khi chạy OS X.
  • Do đó, nó phải là một vấn đề OS X.

Những gì tôi đã cố gắng:

  • Khởi động lại, tắt máy.
  • Bật và tắt AirPort, các loại cáp Ethernet khác nhau.
  • Quyền sửa chữa.
  • Đặt lại PRAM.
  • Xóa tất cả bộ nhớ cache của hệ thống và người dùng bằng Onyx.

Lưu ý kỳ lạ: Vì một số lý do kỳ lạ, vấn đề dường như trở nên tồi tệ hơn khi một cuộc gọi skype đang diễn ra.

Tôi rất vui lòng đánh giá cao ý tưởng về cách tiếp cận vấn đề này.


1
Tôi cũng trải nghiệm điều này! Thật là khó chịu. Không chắc chắn nếu điều này nhìn chằm chằm với 10.8.3. Mac của tôi là MBA giữa năm 2012. Tuy nhiên, việc đóng băng mạng có thể kéo dài 15 giây.
gentmatt

2
Vui lòng kiểm tra xem Skype của bạn có được đặt thành: Cổng kết nối đến: 12794
Ruskes

1
Tôi đã thêm hướng dẫn cài đặt cho MTR trên câu trả lời của mike
Alexander - Tái lập Monica

2
Được rồi - một vài câu hỏi nữa. Bạn có một bộ định tuyến riêng và một điểm truy cập, hoặc tất cả chúng đều được tích hợp? Nếu chúng là riêng biệt - bạn có chuyển đổi giữa Bộ định tuyến và Điểm truy cập không? Ngoài ra - nếu bạn đã kết nối với Ethernet - để bạn kết nối đến cùng một switch (xin lưu ý - Tôi vẫn có nghĩa là một thiết bị riêng biệt)
mike

2
Miguel: thực tế bạn dường như không bị ảnh hưởng bởi điều này trên bất kỳ mạng nào khác đối với tôi dường như cho thấy vấn đề thực sự nằm giữa bộ định tuyến của bạn và máy Mac. Tôi không đồng ý với những người khác rằng vấn đề là do ISP của bạn. Khi sự cố của bạn xảy ra, bạn không thấy địa chỉ MAC của bộ định tuyến trong bảng ARP của mình. Đây là lớp thấp hơn DHCP, định tuyến, v.v. vì tất cả đều yêu cầu kết nối Lớp 2 để hoạt động. Bạn không có kết nối Lớp 2 hoạt động khi sự cố xuất hiện. (TBC)
mike

Câu trả lời:


13

Khi các kết nối của bạn bắt đầu hết thời gian, bạn có thể thực hiện arp -antrong Terminal.app và xem liệu bạn có còn tất cả địa chỉ MAC trong bảng ARP không? như trong - địa chỉ MAC của bộ định tuyến của bạn hoặc máy chủ bạn đang cố gắng ping?

Nếu bạn làm (và bạn có thời gian trước khi nó bắt đầu hoạt động trở lại), bạn có thể xóa bảng arp ( sudo arp -ad) và sau đó xem liệu địa chỉ MAC của bộ định tuyến của bạn có hiển thị lại trong bảng ARP không?

Ngoài ra, hãy thử chạy ping đến địa chỉ IP LAN của bộ định tuyến của bạn trong một phiên Terminal và có thể ping đến địa chỉ IP WAN của bộ định tuyến của bạn trong một địa chỉ khác trong khi bạn đang sử dụng Skype. Xem nếu tất cả trong số họ bắt đầu thời gian ra hoặc chỉ một trong số họ. Một công cụ nữa mà tôi thấy hữu ích là mtr- bạn có thể cần lấy nguồn và tự biên dịch nó hoặc sử dụng fink / macports hoặc trình quản lý gói khác. Khi bạn nhận được nó, chỉ cần chạy nó đến một nơi nào đó trên Internet và nó sẽ cho bạn thấy hop nào dừng đáp ứng.

Cách cài đặt phần mềm từ các nguồn (chẳng hạn như mtr) Yêu cầu cài đặt Xcode :

  • tải xuống kho lưu trữ nguồn (thường là .tar.gz hoặc .tar.bz2)
  • giải nén tệp đã tải xuống (ví dụ: trong Terminal.app chạy gzip -dc filename.tar.gz | tar -xvf -, thông thường sẽ tạo một thư mục mới trong thư mục hiện tại và đặt nội dung của kho lưu trữ vào đó)
  • điều hướng đến thư mục thu được trong thiết bị đầu cuối
  • chạy ./configure --prefix=/usr/local(xin lưu ý, tôi muốn cài đặt phần mềm từ nguồn vào /usr/localđể tránh phần mềm nhị phân được cài đặt như một phần của hệ thống; --prefix=/usr/localtùy chọn cấu hình sẽ làm việc đó)
  • chạy make
  • chạy sudo make install
  • làm xong!

Đã làm điều này, sẽ sớm chỉnh sửa câu hỏi với kết quả.
Mike D.

Khi tôi thực hiện 'arp -an' sau khi xóa bảng, nó không liệt kê bộ định tuyến cho đến khi kết nối được bật lại.
Mike D.

1
→ mike: mtrlà một công cụ tuyệt vời. Không may ở đây vấn đề là ít hơn nhiều. Vấn đề dường như đứng giữa MacOS X và 192.168.1.1. Không cần phải tìm về phía chân trời của Internet.
dan

Lệnh này thực sự đã giúp tôi.
Jadda

6

Trước tiên bạn có thể kiểm tra xem bạn có thực sự sử dụng giao diện mạng không:

ifconfig -a

Bạn có thể xem đầu ra của các lệnh sau (nếu en0 là tên giao diện mạng của thẻ Ethernet của bạn):

netstat -I en0

Để giúp xác định sự cố, bạn có thể tạo một Vị trí cụ thể chỉ bằng thẻ Ethernet được kích hoạt và nếu có thể chỉ sử dụng IPv4 hoặc IPv6 chứ không phải cả hai: Vị trí chỉ bật Ethernet

Bạn có thể chạy trích xuất sau đây về lỗi phần cứng hoặc trình điều khiển tiềm năng:

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

(đừng sợ hãi, bạn có thể tìm thấy nhiều thông tin về các kênh Wi-Fi).

Thông báo sau đây được thể hiện bởi netstat của bạn:

44620 embryonic connections dropped

có nghĩa là bạn thực sự là mục tiêu của một cuộc tấn công đồng bộ tcp ngớ ngẩn (đó là một cuộc tấn công từ chối dịch vụ (DOS)).

Khi bạn:

ping 192.168.1.1

cuộn cảm cho 6s, bạn có thể chạy:

netstat -m

Khi 192.168.1.1 cuộn cảm 'netstat -m' không hiển thị bất cứ điều gì khác thường. Nhân tiện, grep dường như không thể tìm thấy '/var/log/kernel.log'. Tôi đang chỉnh sửa câu hỏi với kết quả của 'netstat -I en1' (Tôi đang sử dụng en1 ngay bây giờ, đó là Sân bay của tôi, en0 không hoạt động). Điều gì có thể là lý do cho cuộc tấn công DOS?
Mike D.

2
→ Miguel: để đơn giản hóa việc phân tích vấn đề của bạn, hãy tạo một mạng mới. chỉ với giao diện Ethernet trên. Sau đó giữ trong một cửa sổ a ping 192.168.1.1(sẽ không thực hiện bất kỳ yêu cầu DNS nào).
dan

→ Miguel: bạn có thể bất đắc dĩ là tác giả của cuộc tấn công DOS của bạn, nhưng điều này vẫn được xác nhận. Tôi nghi ngờ một vòng lặp mạng gây ra bởi một Automaticcấu hình.
dan

1
→ Miguel: bạn có thể cung cấp cho chúng tôi ifconfig -akhông?
dan

1
Điều này đã giải quyết được vấn đề của tôi, tôi chuyển khỏi AutomaticVị trí trong Tùy chọn mạng, tạo một vị trí mới cho Gia đình và Công việc và dường như đã dừng thời gian chờ chặn.
Alex Lynham

4

Tôi đã gặp vấn đề này từ lâu rồi (bắt đầu sau khi nâng cấp lên Mavericks) và, sau nhiều tháng nghiên cứu, tôi nghĩ rằng cuối cùng tôi đã tìm ra cách khắc phục.

Trước hết, có khá nhiều người có cùng một vấn đề trong các diễn đàn của Apple:

Vì vậy, đây là một vấn đề đã biết và tôi thực sự không biết tại sao Apple vẫn chưa cung cấp bản sửa lỗi cho vấn đề này. Trong các chủ đề được liệt kê ở trên, có nhiều đề xuất để khắc phục điều này, nhưng hầu hết những đề xuất đó không hoạt động. Một số khắc phục sự cố tạm thời:

  • Ngắt kết nối và kết nối lại mạng
  • Người bạn cũ: khởi động lại
  • Xóa thư mục chứa cấu hình mạng: sudo rm -rf /Library/Preferences/SystemConfiguration

Sau các biện pháp này, kết nối mạng cảm thấy tốt hơn nhiều và tôi không gặp phải tình trạng giảm trong vài giờ hoặc đôi khi thậm chí vài ngày. Nhưng những vấn đề luôn quay trở lại.

Câu hỏi này và gợi ý rằng vấn đề có thể liên quan đến ARP đã đưa tôi bắt đầu nghiên cứu sâu hơn và tôi đã tìm thấy trang này , trong đó mô tả chi tiết về lỗi và cũng có một bản vá, tôi trích dẫn ở đây:

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

Vui lòng tham khảo liên kết được cung cấp để được giải thích sâu hơn về bản sửa lỗi, được cho là sẽ được đưa vào bản cập nhật hệ điều hành trong tương lai cho Yosemite của Apple. Nó vô hiệu hóa các yêu cầu ARP unicast, gây nhầm lẫn với một số thiết bị mạng như bộ định tuyến gia đình của bạn.

Sau khi áp dụng sửa chữa và khởi động lại, cần kiểm tra nếu

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

trả lại net.link.ether.inet.arp_unicast_lim: 0. Nếu số không bằng 0, sửa chữa không được áp dụng chính xác.

Sau đó, tôi tìm thấy một chủ đề khác tại các cộng đồng apple có cùng một giải pháp: Mavericks và ARP thất bại khiến mạng bị rớt! Chà, sau khi bạn biết vấn đề là gì, việc tìm ra giải pháp chính xác dễ dàng hơn rất nhiều.


3

Đầu tiên, tôi thấy dropbox chạy trong thanh menu của bạn; bạn đã vô hiệu hóa điều đó chưa?

Thứ hai, hãy thử loại bỏ bất kỳ mục khởi động / đăng nhập khác. Nhìn vào:

Đăng nhập:

  1. ~ / Thư viện / LaunchAgents /
  2. ~ / Thư viện / LaunchDaemons /
  3. Tùy chọn hệ thống> Người dùng & Nhóm> Mục đăng nhập

Khởi nghiệp:

  1. / Thư viện / LaunchAgents /
  2. / Thư viện / LaunchDaemons /
  3. / Thư viện / StartupItems /
  4. / L Library / Repferences / com.apple.loginitems.plist (hiếm khi tồn tại)

Tôi đã không cố gắng vô hiệu hóa Dropbox, điều đó có hữu ích không? Và ngoài ra, bạn có thể giải thích lý do để loại bỏ những mặt hàng? Cảm ơn!
Mike D.

1
Bạn muốn tách biệt nếu sự cố xảy ra với OS X hoặc một phần mềm được thêm vào sau lần cài đặt ban đầu. Những thứ như dropbox tạo kết nối mạng ngay khi tài khoản người dùng tải hoặc phần mềm chống vi-rút thường chạy trong tất cả các tài khoản người dùng có thể đang đặt cổng hoặc góp phần gây ra sự cố.
zac

Ok, tôi sẽ làm điều này và sẽ đăng ở đây kết quả vào ngày mai.
Mike D.

→ Miguel: Dropbox không thể là vấn đề của bạn. Dropbox chỉ đơn giản là làm 443 / tcp như mọi trình duyệt web khác. Nhưng trong trường hợp bạn muốn thực hiện việc đánh hơi mạng (Wireshark hoặc tcpdump), việc dừng Dropbox sẽ loại bỏ cho bạn một loạt lưu lượng truy cập tcp. Do đó, điều này sẽ giúp bạn "nhìn thấy" bất kỳ hành vi sai trái nào.
dan

1
@Miguel, một số dự đoán nữa. 1. bạn đã liên hệ với ISP của bạn để xem họ có thể kiểm tra chất lượng đường dây không? 2. cách thiết lập tài khoản người dùng thử để xem sự cố có di chuyển không. Một gợi ý thứ ba là kiểm tra hệ thống của bạn - những thứ như kiểm tra quyền - chẩn đoán máy. 4. bạn có thể trao đổi các thành phần - chạy máy tính của bạn tại địa điểm của một người bạn - mượn bộ định tuyến bạn bè của bạn - ồ, và loại bỏ tất cả các thiết bị mạng khác khỏi hệ thống của bạn.
David DelMonte

2

Có rất nhiều thông tin ở đây về kết thúc xử lý sự cố và chẩn đoán, nhưng đôi khi khi xử lý sự cố, thật vui khi quay lại những điều cơ bản và đặt câu hỏi về một số giả định.

Như tôi đã đề cập trong một bình luận, nó trông rất giống bộ định tuyến QOS đang hoạt động do máy của bạn tạm thời vượt quá một số băng thông hoặc tốc độ gói.

Điều gì xảy ra nếu bạn đang thực hiện các kiểu, khối lượng và lưu lượng mạng khác nhau trong khi trên OS X trái ngược với Windows và đó là nguyên nhân thực sự, không phải trình điều khiển phần cứng hoặc phần mềm?

Tôi hy vọng việc chạy OS X có tương quan với các quan sát của bạn, nhưng nếu đó không phải là nguyên nhân của việc tạm dừng mạng tạm thời.

Bạn đã thử nghiên cứu xem có bất kỳ bộ lọc QOS và thay đổi định tuyến nào được nhà cung cấp mạng của bạn triển khai không? Bạn đã xem xét đường hầm tất cả lưu lượng truy cập đến một máy tính khác (ssh hoặc VPN) để bạn có thể loại trừ các bộ lọc tầm thường. (Nếu nhà cung cấp đang thực hiện kiểm tra gói sâu, hoặc giới hạn đích và tốc độ thực - bạn có thể không thoát được những khoảng thời gian ngắn này.)

Tôi hy vọng có câu trả lời bạn có thể tìm thấy bằng cách xem chi tiết về mạng (và tất cả chúng ta sẽ học được điều gì đó từ việc khám phá các tùy chọn đó) - nhưng hãy chắc chắn rằng bạn cũng xem xét rằng các công cụ đo lường của mình và thêm lưu lượng truy cập vào ping / poke vào mọi thứ có thể đang ảnh hưởng đến số lượng lưu lượng truy cập và làm cho nhiều khả năng Skype sẽ giảm cho bạn. Các bộ định tuyến tôi thiết lập được lập trình để giảm lưu lượng ICMP trước tất cả các lưu lượng khác kể từ khi dung lượng bị hạn chế - Tôi muốn thay thế ping và các gói khác vượt qua. ISP và nhà cung cấp mạng của bạn có thể đã thiết lập mọi thứ tương tự.


Tôi thấy ... nhưng không có gì thay đổi trong hoạt động mạng của tôi trong 5 năm qua. Vấn đề này bắt đầu khoảng một tháng trước và tôi không thể tìm thấy bất kỳ mối tương quan nào ngoại trừ đó là khoảng một tháng trước khi 2 đồng nghiệp chuyển đến. Nhưng tôi đã chạy thử nghiệm ping trên máy của họ và họ không gặp phải vấn đề này. Tôi không biết về bất kỳ bộ lọc QOS nào nhưng tôi sẽ cố gắng tìm hiểu.
Mike D.

Skype đang lưu trữ một cuộc gọi gần như 24/7 trên máy của tôi ... Tôi sẽ tắt tất cả các lệnh ping, v.v. hôm nay để xem có gì thay đổi vào lần tiếp theo khi kết nối bị giảm hay không (vì tôi vẫn có thể biết liệu nó có bị rớt hay không bằng cách nghe âm thanh Tôi nhận được từ cuộc gọi Skype)
Mike D.

2

Ngoài tất cả nội dung ở đây, bạn có thể muốn đảm bảo Auto Proxy Discovery không được bật (cũng như Cấu hình proxy tự động). Điều đó có xu hướng gây ra nhiều vấn đề hơn không và nó thường không cần thiết.

Tùy chọn hệ thống


Cảm ơn vì lời khuyên, họ đã tắt rồi :(
Mike D.

2

Với tất cả các thông tin chẩn đoán tuyệt vời trong câu hỏi này, bạn đã thu hẹp rất nhiều khả năng.

Để bắt đầu, ping của bạn tới 192.168.1.1 cách ly rất nhiều vấn đề với bộ định tuyến, máy tính hoặc mạng LAN của bạn. Đây không phải là vấn đề với DNS hoặc ISP của bạn.

Tôi băn khoăn nhất với kết quả kiểm tra ping của bạn tới 192.168.1.1. Bạn đã làm một cái gì đó kỳ lạ trong việc thiết lập chúng?

Ví dụ: bạn đã ping thành công với số thứ tự ICMP là 24267, 24268 và 24269, sau đó 3 lần hết giờ, sau đó thành công trở lại với ICMP 24273. Vì vậy, số lượng thành công có vẻ đúng. Tuy nhiên, số lượng thời gian chờ là hoàn toàn khác nhau. Tôi hy vọng sẽ thấy thời gian chờ yêu cầu từ ICMP 24270, 24271 và 24272 nhưng thay vào đó là báo cáo hết thời gian chờ ICMP 89806, 89807 và 89808. Tôi chưa bao giờ thấy điều đó trước đây và vì vậy tôi cho rằng bạn có một ngăn xếp mạng bị hỏng trên đó máy vi tính. Có lẽ một quá nhiều phần mở rộng. Bất kỳ cơ hội nào bạn đã cài đặt Netgear Genie? Hoặc có thể là phần mềm VPN?

Trong mọi trường hợp, tôi muốn nói rằng đã đến lúc bắt đầu vô hiệu hóa "cải tiến" để xem liệu bạn có thể tìm ra thủ phạm được cài đặt trên máy tính hay không.

Chỉnh sửa

OK, bí ẩn đã được giải quyết. Số thứ tự ICMP là một trường 16 bit. Được coi là một số nguyên không dấu, điều đó có nghĩa là nó có giá trị tối đa là 65.535 và sau đó kết thúc bằng không. Vì vậy, nếu chương trình ping cục bộ đang duy trì bộ đếm số nguyên 32 bit (có thể theo mặc định), nó có thể báo cáo số nguyên 32 bit cho các gói bị thiếu. Tuy nhiên, khi đọc trả lời, trả lời nhất thiết sẽ chỉ có 16 bit cuối cùng của bộ đếm. Vì vậy, câu trả lời cho số thứ tự 89805 sẽ là 89505 & 0xFFFF là 24269.


Chào. Tôi không làm điều gì kỳ lạ ... đó chỉ là một 'sudo ping 192.168.1.1' ... Tôi thấy những gì bạn đang nói về số thứ tự ICMP ... Tôi không biết tại sao đó có thể là ... có thể là ... ping đã chạy quá lâu? (nó đã chạy trong nhiều ngày) ... Không có ý tưởng. Ngoài ra, cấu hình mạng của tôi rất đơn giản và tôi đã sử dụng cùng một cấu hình trong nhiều năm mà không gặp vấn đề gì.
Mike D.

1
Phần mềm luôn chạy nền và có thể có liên quan đến vấn đề này: Little Snitch, Dropbox, Skype và tất cả các công cụ OS X ... nhưng không có gì mới và vấn đề bắt đầu khoảng một tháng trước. Một điều mà tôi nghi ngờ là khoảng một tháng trước, khi có hai người bạn cùng phòng mới chuyển đến. Tôi đã chạy thử nghiệm ping trong máy tính của họ và họ không gặp phải vấn đề này.
Mike D.

@Miguel, chắc chắn loại bỏ Little Snitch vì đó chính xác là loại phần mềm có thể tạo ra vấn đề này. Nếu bạn chưa có cấu hình phức tạp, tôi sẽ nói gỡ cài đặt hoàn toàn và thậm chí dọn sạch thùng rác để đảm bảo rằng nó đã biến mất và khởi động lại và xem liệu điều đó có khắc phục được sự cố không.
Old Pro

Ok, tôi sẽ hoàn toàn gỡ cài đặt nó và xem điều gì xảy ra (nhưng tôi đã sử dụng nó trong nhiều năm mà không có vấn đề gì).
Mike D.

Hài hước ... 24269 trong nhị phân là 0000 0101 1110 1100 1101. 89806 ở dạng nhị phân là 0001 0101 1110 1100 1110. Tuy nhiên, nếu chúng tôi lấy 24269 và chỉ cần trao đổi bit 16, chúng tôi nhận được 0001 0101 1110 1100 1101 = 89805. Với tôi trông giống như số nguyên được ký so với không dấu, vì vậy trình bày số hoàn toàn của nó. Có thể là thiết bị Miguel đang ping sử dụng số nguyên không dấu thay vì ký (hoặc ngược lại) ...
mike

2

Tôi biết đây là một chủ đề cũ.

Nhưng cảm ơn mọi người vì sự cố này. Tất cả các bước đã giúp tôi khắc phục sự cố trong đó tôi có thể ping máy chủ nhưng không kết nối với chúng qua telnet.

Giải pháp khá đơn giản (sau đó) đã loại bỏ tất cả những thứ không cần thiết từ đây (như zac đã đề cập)

Đăng nhập:

~ / Library / LaunchAgents / ~ / Library / LaunchDaemons / System Preferences> Users & Groups> Đăng nhập các mục

Khởi nghiệp:

/ Library / LaunchAgents / / Library / LaunchDaemons / / Library / StartupItems / / Library /Pferencesferences / com.apple.loginitems.plist (hiếm khi tồn tại)

Một lần nữa, cảm ơn tất cả


1

Vấn đề tò mò khi xem xét nó vẫn tồn tại của ethernet. Tôi gặp vấn đề tương tự nhưng thấy nhiễu WiFi từ các mạng khác là vấn đề. Việc chuyển sang băng tần 5GHz đã khắc phục vấn đề của tôi, đó là điều đáng để đoán.


Trước khi thay đổi kênh mạng vì bạn nghĩ rằng bạn có vấn đề về nhiễu, chỉ cần chẩn đoán nó là thư ký. Điều này khá dễ dàng: sử dụng istumbler.net . Bạn sẽ nhìn thẳng vào sự thật trong mắt.
dan

1

Có gợi ý nào từ /var/log/system.log không?

Netstat -s trông như thế nào?

Linh cảm của tôi nói xóa / Thư viện / Tùy chọn / SystemConfiguration và thêm lại các giao diện mạng theo cách thủ công.

Có vẻ như bạn đã thử nhiều thứ rồi.


Xin chào Miguel, thêm nhiều voodoo sau khi xem ảnh chụp màn hình của bạn. bạn có thể thử ba điều sau: 1: tắt bluetooth, 2: kiểm tra giao diện mạng 1 không? 3: chỉ để xác nhận, bạn đang sử dụng trình điều khiển mạng chứng khoán, phải không?
epoon

System.log rất lớn ... Tôi đã tìm kiếm các từ cụ thể nhưng không thể tìm thấy bất cứ điều gì có liên quan :(
Mike D.

Tôi sẽ chỉnh sửa câu hỏi thêm dữ liệu mà netstat -s đưa cho tôi.
Mike D.

Tôi đã xóa tất cả các cấu hình mạng. và thêm lại mọi thứ bằng tay nhưng không có may mắn. Bluetooth luôn bị tắt. Tôi đang sử dụng trình điều khiển mạng chứng khoán. Tất cả các giao diện mạng đều cho kết quả chính xác như nhau: mất kết nối tạm thời mọi lúc và sau đó :(
Mike D.

1
icmp và ip gói lỗi liên quan đến tôi. riêng biệt, cài đặt một bản sao OSX mới và khởi động từ nó qua USB. Điều này sẽ cô lập cài đặt OSX của bạn. nếu một bản sao mới vẫn có lỗi, thì chúng ta sẽ gặp lỗi phần cứng - ai biết được, có thể chỉ có trình điều khiển OSX sẽ kích hoạt nó. Cho thấy vấn đề xuất hiện trong bản cài đặt mới và apple sẽ khắc phục nó cho bạn
epoon

1

Nhìn tương tự như thế này?

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

Tôi chỉ đăng cái này cho Mavericks. Suy nghĩ?


1
Mặc dù liên kết này có thể trả lời câu hỏi, tốt hơn là bao gồm các phần thiết yếu của câu trả lời ở đây và cung cấp liên kết để tham khảo. Câu trả lời chỉ liên kết có thể trở nên không hợp lệ nếu trang được liên kết thay đổi.
grg

Tôi sẽ cố gắng xem xét giải pháp trong liên kết để xem nó có giúp tôi không. Sẽ gửi lại.
Mike D.

0

Gợi ý về Mac OSX http://hints.macworld.com/article.php?story=20080605143917233 về các kết nối bị rớt vì tra cứu DNS không nhận dạng DCHP của bộ định tuyến đang chờ xử lý ..

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

Rất có thể DNS và / hoặc cài đặt tăng tốc trong cài đặt modem của bạn và bỏ qua DNS đó sẽ giúp giải quyết vấn đề của bạn.


5
Điều đó sẽ không gây ra vấn đề này. ping thực hiện tra cứu DNS một lần (google.com -> 173.194.34.196 trong trường hợp này), sau đó sử dụng địa chỉ IP từ đó trở đi.
Gordon Davisson

Sẽ làm điều này và báo cáo lại.
Mike D.

1
→ Blip: đây không phải là vấn đề liên quan đến DNS. Việc ping về phía bộ định tuyến với địa chỉ IP không tạo ra bất kỳ udp paquet nào, chỉ là tiếng vang icmp ngớ ngẩn.
dan

0

Điều này có mùi giống như một thiết bị khác trên mạng của bạn đang cố gắng sử dụng cùng một IP như bạn hoặc gặp một số rắc rối với DHCP.

Bạn có thể thấy nếu bạn vẫn có thể sao chép nó sau khi tự gán cho mình một IP tĩnh không?

Tùy chọn mạng Goto, chọn giao diện Ethernet, nâng cao, TCP / IP

Thay đổi danh sách thả xuống "Định cấu hình IPv4" thành "Thủ công"

Địa chỉ IPv4: 192.168.1.150 (một cái gì đó độc đáo, không phải là thứ DHCP đã gán cho bạn trước đó) Mặt nạ mạng con: 255.255.255.0 Bộ định tuyến: 192.168.1.1

Tiết kiệm

Sau đó cố gắng tái tạo vấn đề một lần nữa. Khi thực hiện kiểm tra này, hãy đảm bảo Wi-Fi của bạn tắt để chỉ Ethernet của bạn được sử dụng. Điều này sẽ giúp thu hẹp nó xuống.


Nếu bạn vẫn gặp sự cố, bạn nên tải xuống Wireshark ( http://www.wireshark.org/ ) để bắt đầu chụp, tái tạo vấn đề, lưu kết xuất và để chúng tôi xem xét.

Ngoài ra, bạn đang sử dụng Router / AP nào?


0

Hai điều cần kiểm tra có liên quan đến vấn đề này do tăng lưu lượng mạng LAN do bạn cùng phòng mới.

  1. Có các cài đặt QoS (Chất lượng dịch vụ) trên bộ định tuyến không và nếu có, chúng được đặt như thế nào? Lưu lượng truy cập Skype sẽ được ưu tiên và nếu mạng LAN bị bão hòa, bộ định tuyến có thể đáp ứng bằng cách tạm thời tắt các kết nối ưu tiên thấp hơn.
  2. Là CPU bộ định tuyến đơn giản là bị quá tải? Khi tôi nâng cấp từ 1 Gbs DSL lên dịch vụ cáp 5 Gbs, tôi thấy rằng bộ định tuyến của tôi đơn giản là không thể theo kịp lưu lượng truy cập tăng lên và phải mua một cái mới. Điều tra hiệu suất của bộ định tuyến của bạn và xem nếu điều này có thể là một vấn đề. Hầu hết các bộ định tuyến có đánh giá hiệu suất chi tiết có sẵn trên internet; kiểm tra và xem bộ định tuyến của bạn được đánh giá như thế nào so với dung lượng dịch vụ internet của bạn.

0

Chào các bạn, tôi cũng gặp vấn đề chính xác như vậy, nhưng tôi chỉ rút tai nghe tôi đang sử dụng và tôi đã nói chuyện với bạn tôi trong 10 phút đầu và bây giờ nó vẫn không rơi, khi trước khi nó rớt xuống sau 20 giây.

Dây tai nghe của tôi bị rách nên có thể đã gây ra sự cố, nhưng tôi không biết gì nhiều về địa chỉ IP và công cụ ping, và điều này dường như giúp tôi giải quyết. Nếu bạn cố gắng và nó không hoạt động, đừng đổ lỗi cho tôi, vì nó đã khắc phục vấn đề của tôi.


0

Giải pháp khá đơn giản (sau đó) đã loại bỏ tất cả những thứ không cần thiết từ đây (như zac đã đề cập)

Đăng nhập:

~ / Library / LaunchAgents / ~ / Library / LaunchDaemons / System Preferences> Users & Groups> Đăng nhập các mục

Khởi nghiệp:

/ Library / LaunchAgents / / Library / LaunchDaemons / / Library / StartupItems /> / Library /Pferencesferences / com.apple.loginitems.plist (hiếm khi tồn tại)

Tôi biết đây là một chủ đề cũ, nhưng làm điều này đã khắc phục vấn đề tôi gặp phải. Internet của tôi đôi khi sẽ ngắt kết nối và ping sẽ giảm mọi lúc. Điều gì sẽ khắc phục vấn đề của tôi là tắt wi-fi hoặc ethernet (mà tôi đã từng sử dụng), sau đó kích hoạt lại nó. Tất nhiên điều này sẽ chỉ tạm thời khắc phục vấn đề. Thật là kỳ lạ bởi vì bất cứ khi nào máy mac pro 4,1 của tôi gặp sự cố này, máy tính xách tay mac của tôi cũng sẽ bị mất ping. Nó gần giống như Mac Pro của tôi sẽ làm sập mạng của tôi.

Tôi đã thử rất nhiều thứ! thay thế modem, bộ định tuyến, được gọi là isp, mua usb thành ethernet. Không ai trong số những điều đó làm việc, cho đến khi tôi đã thử điều này!

Tôi đã làm những gì được đề cập ở trên và cuối cùng nó đã khắc phục vấn đề !!


0

Tôi đã gặp một vấn đề tương tự và trong trường hợp của tôi, nó dường như là do Tunnelblick gây ra, ngay cả khi VPN không được kết nối. Tôi đã gỡ cài đặt nó (với trình gỡ cài đặt, không chỉ kéo đến Thùng rác) và vấn đề đã biến mất.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.