ปัญหาการเชื่อมต่อที่น่าสนใจใน OS X

33

ฉันเพิ่งได้รับปัญหานี้กับการเชื่อมต่ออินเทอร์เน็ตของฉันใน MacBook Pro ของฉันต้นปี 2011 ที่ใช้ OS X 10.8.3: การเชื่อมต่อ "ค้าง" เป็นครั้งคราวประมาณ 5 วินาทีแล้วกลับมา

มันเกิดขึ้นทั้งผ่าน Wi-Fi หรือสาย Ethernetและจะเกิดขึ้นกับเครื่องของฉันเมื่อใช้งาน OS X เท่านั้น (จะไม่เกิดขึ้นเมื่อใช้งาน Windows 7 บนเครื่องเดียวกันหรือบนเครื่อง / อุปกรณ์อื่น ๆ ) มันทำให้การโทรของ Skype ลดลงทุกๆ 2 นาทีดังนั้นมันจึงน่าผิดหวังมาก

การส่ง Ping ไปที่ 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) และที่อยู่อีเทอร์เน็ตคือ 3c: 07: 54: 5a: e0: 44 (IP คงที่ 192.168.1.251) . LAN 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 เพราะมันเกิดขึ้นผ่านสายเคเบิลด้วย
  • ไม่ใช่ปัญหาเราเตอร์ / ISP เพราะอุปกรณ์และเครื่องอื่น ๆ ไม่มีปัญหา
  • ไม่ใช่ปัญหาของเครื่องเนื่องจากจะเกิดขึ้นเฉพาะเมื่อใช้งาน OS X
  • ดังนั้นจึงต้องเป็นปัญหาของ OS X

สิ่งที่ฉันพยายาม:

  • รีสตาร์ทปิดเครื่อง
  • เปิดและปิด AirPort สายอีเธอร์เน็ตที่แตกต่างกัน
  • ซ่อมแซมสิทธิ์
  • รีเซ็ต PRAM
  • ล้างแคชของระบบและผู้ใช้ทั้งหมดด้วย Onyx

หมายเหตุแปลก ๆ : ด้วยเหตุผลแปลก ๆ บางอย่างปัญหาดูเหมือนจะเลวร้ายลงเมื่อมีการโทร skype เกิดขึ้น

ฉันขอขอบคุณแนวคิดในการแก้ไขปัญหานี้

macos  mountain-lion  airport  internet  ethernet 
— ไมค์ดี
แหล่งที่มา
1
ฉันพบสิ่งนี้เช่นกัน! มันน่ารำคาญมาก ไม่แน่ใจว่าสิ่งนี้จ้องมองด้วย 10.8.3 My Mac เป็น MBA Mid 2012 แต่เครือข่ายค้างสามารถนานถึง 15 วินาที
— gentmatt
2
โปรดตรวจสอบว่า Skype ของคุณถูกตั้งค่าเป็น: พอร์ตการเชื่อมต่อขาเข้า: 12794
— Ruskes
1
ฉันเพิ่มคำแนะนำในการติดตั้งสำหรับ MTR ตามคำตอบของไมค์
— Alexander
2
ตกลงแล้ว - คำถามอีกสองสามข้อ คุณมีเราเตอร์แยกต่างหากและจุดเชื่อมต่อหรือรวมทั้งหมดหรือไม่ หากแยกกันคุณมีสวิตช์ระหว่างเราเตอร์และจุดเข้าใช้งานหรือไม่ นอกจากนี้ - ถ้าคุณเชื่อมต่อกับอีเธอร์เน็ต - คุณเชื่อมต่อกับสวิตช์ตัวเดียวกัน (โปรดทราบ - ฉันยังหมายถึงอุปกรณ์แยกต่างหาก)
— ไมค์
2
มิเกล: ความจริงที่ว่าคุณไม่ได้รับผลกระทบจากสิ่งนี้ในเครือข่ายอื่น ๆ ของฉันดูเหมือนว่าจะระบุว่าปัญหาระหว่างเราเตอร์และ Mac ของคุณ ฉันไม่เห็นด้วยกับคนอื่น ๆ ว่ามีปัญหากับ ISP ของคุณ เมื่อปัญหาของคุณเกิดขึ้นคุณจะไม่เห็นที่อยู่ MAC ของเราเตอร์ของคุณในตาราง ARP ของคุณ นี่คือเลเยอร์ที่ต่ำกว่า DHCP การกำหนดเส้นทางและอื่น ๆ เนื่องจากสิ่งเหล่านี้ทั้งหมดต้องการการเชื่อมต่อของเลเยอร์ 2 ในการทำงาน คุณไม่มีการเชื่อมต่อของเลเยอร์ 2 ที่ใช้งานได้เมื่อเกิดปัญหาขึ้น (TBC)
— ไมค์

คำตอบ:

13

เมื่อการเชื่อมต่อของคุณเริ่มหมดเวลาคุณสามารถทำarp -anใน Terminal.app และดูว่าคุณยังมีที่อยู่ MAC ทั้งหมดในตาราง ARP หรือไม่ เช่นเดียวกับที่อยู่ MAC ของเราเตอร์ของคุณหรือโฮสต์ที่คุณพยายาม ping

หากคุณ (และคุณมีเวลาก่อนที่มันจะเริ่มทำงานอีกครั้ง) คุณสามารถล้างตาราง arp ( sudo arp -ad) แล้วดูว่าที่อยู่ MAC ของเราเตอร์ของคุณปรากฏในตาราง ARP อีกครั้งหรือไม่

ลองใช้ ping ไปยังที่อยู่ LAN ของเราเตอร์ของคุณในเซสชันหนึ่งของเทอร์มินัลและอาจ ping ไปยังที่อยู่ IP ของ WAN ของเราเตอร์ของคุณในขณะที่คุณกำลังใช้ 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
  • ทำ!
— ไมค์
แหล่งที่มา
ทำอย่างนี้ในไม่ช้าจะแก้ไขคำถามด้วยผลลัพธ์
— Mike D.
เมื่อฉันทำ 'arp -an' หลังจากลบตารางแล้วจะไม่แสดงเราเตอร์จนกว่าการเชื่อมต่อจะเปิดขึ้น
— Mike D.
1
→ไมค์: mtrเป็นเครื่องมือที่ยอดเยี่ยม โชคไม่ดีที่นี่ปัญหาอยู่ไกลน้อยกว่ามาก ดูเหมือนว่าปัญหาจะอยู่ระหว่าง MacOS X และ 192.168.1.1 ไม่จำเป็นต้องตามล่าไปยังขอบฟ้าของอินเทอร์เน็ต☺
— แดน
คำสั่งนี้ช่วยฉันได้จริงๆ
— Jadda
6

คุณสามารถตรวจสอบก่อนว่าคุณใช้อินเทอร์เฟซเครือข่ายจริง ๆ คุณควร:

ifconfig -a

คุณช่วยดูผลลัพธ์ของคำสั่งต่อไปนี้ (ถ้า en0 เป็นชื่ออินเตอร์เฟสเครือข่ายของการ์ด Ethernet ของคุณ):

netstat -I en0

เพื่อช่วยในการค้นหาปัญหาคุณสามารถสร้างสถานที่เฉพาะได้โดยเปิดใช้งานการ์ดอีเทอร์เน็ตของคุณและหากเป็นไปได้ให้ใช้เฉพาะ IPv4 หรือ IPv6 แต่ไม่ใช่ทั้งสองอย่าง: ตำแหน่งที่เปิดเพียงอีเธอร์เน็ต

คุณสามารถเรียกใช้ข้อแตกต่างของฮาร์ดแวร์หรือไดรเวอร์ที่มีข้อผิดพลาดต่อไปนี้:

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

(อย่าตกใจคุณอาจพบข้อมูลช่องสัญญาณ Wi-Fi จำนวนมาก)

ข้อความต่อไปนี้แสดงโดย netstat ของคุณ:

44620 embryonic connections dropped

หมายความว่าคุณเป็นเป้าหมายของการโจมตีด้วย tcp syn ที่โง่เขลา (ซึ่งเป็นการโจมตีแบบปฏิเสธการให้บริการ (DOS))

เมื่อคุณ:

ping 192.168.1.1

ฉายาสำหรับ 6s คุณสามารถเรียกใช้:

netstat -m
— แดน
แหล่งที่มา
เมื่อ 192.168.1.1 chokes 'netstat -m' ไม่แสดงอะไรผิดปกติ อย่างไรก็ตาม, grep ไม่สามารถหา '/var/log/kernel.log' ได้ ฉันแก้ไขคำถามด้วยผลลัพธ์ของ 'netstat -I en1' (ฉันกำลังใช้ en1 ในขณะนี้ซึ่งเป็นสนามบินของฉัน en0 ไม่ทำงาน) สาเหตุของการโจมตีของ DOS คืออะไร
— Mike D.
2
→ Miguel: ทำการวิเคราะห์ปัญหาของคุณให้ง่ายขึ้นสร้างเครือข่ายใหม่ เพียงแค่เปิดอินเตอร์เฟสอีเธอร์เน็ต จากนั้นให้อยู่ในหน้าต่าง a ping 192.168.1.1(ซึ่งจะไม่ทำการร้องขอ DNS ใด ๆ )
— แดน
→มิเกล: คุณอาจเป็นผู้แต่งการโจมตี DOS ของคุณอย่างไม่เต็มใจ แต่ก็ยังยืนยันได้ ฉันสงสัยว่าเครือข่ายลูปเกิดจากการAutomaticกำหนดค่า
— แดน
1
→มิเกล: คุณให้อะไรเราifconfig -aบ้าง
— แดน
1
วิธีนี้แก้ไขปัญหาของฉันฉันย้ายออกจากAutomaticตำแหน่งในการตั้งค่าเครือข่ายสร้างตำแหน่งใหม่สำหรับบ้านและที่ทำงานและดูเหมือนว่าจะหยุดการหมดเวลาบล็อก
— Alex Lynham
4

ฉันมีปัญหานี้มาเป็นเวลานานแล้ว (เริ่มหลังจากอัพเกรดเป็น 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 แบบ unicast ซึ่งทำให้เกิดความสับสนกับอุปกรณ์เครือข่ายบางอย่างเช่นเราเตอร์ที่บ้านของคุณ

หลังจากใช้การแก้ไขและการรีบูตควรตรวจสอบว่า

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

net.link.ether.inet.arp_unicast_lim: 0ผลตอบแทน หากตัวเลขไม่เท่ากับศูนย์แสดงว่าการแก้ไขไม่ได้ใช้อย่างถูกต้อง

หลังจากนั้นฉันได้พบเธรดอื่นในชุมชน Apple ที่มีโซลูชันเดียวกัน: Mavericks และ Failed ARP ทำให้เครือข่ายลดลง! หลังจากคุณรู้ว่าปัญหาคืออะไรการหาทางออกที่ถูกต้องนั้นง่ายกว่ามาก

— pederpansen
แหล่งที่มา
3

ก่อนอื่นฉันเห็น dropbox ทำงานในแถบเมนูของคุณ คุณปิดใช้งานแล้วหรือยัง

ประการที่สองลองลบรายการเริ่มต้น / เข้าสู่ระบบอื่น ๆ ดูใน:

เข้าสู่ระบบ:

  1. ~ / Library / LaunchAgents /
  2. ~ / Library / LaunchDaemons /
  3. ค่ากำหนดของระบบ> ผู้ใช้ & กลุ่ม> รายการเข้าสู่ระบบ

เริ่มต้น:

  1. / Library / LaunchAgents /
  2. / Library / LaunchDaemons /
  3. / Library / StartupItems /
  4. /Library/Preferences/com.apple.loginitems.plist (ไม่ค่อยมีอยู่)
— Zac
แหล่งที่มา
ฉันไม่ได้ลองปิดการใช้งาน Dropbox มันจะมีประโยชน์ไหม? และคุณสามารถอธิบายเหตุผลในการลบรายการเหล่านั้นได้หรือไม่ ขอบคุณ!
— Mike D.
1
คุณต้องการแยกหากปัญหาเกิดขึ้นกับ OS X หรือซอฟต์แวร์ที่เพิ่มหลังจากการติดตั้งครั้งแรก สิ่งต่าง ๆ เช่นดรอปบ็อกซ์ที่ทำการเชื่อมต่อเครือข่ายทันทีที่บัญชีผู้ใช้โหลดหรือซอฟต์แวร์ป้องกันไวรัสที่โดยปกติแล้วจะทำงานในบัญชีผู้ใช้ทั้งหมดอาจกำลังสำรองพอร์ตหรือสนับสนุนปัญหา
— zac
ตกลงฉันจะทำสิ่งนี้และจะโพสต์ผลลัพธ์ที่นี่ในวันพรุ่งนี้
— Mike D.
→มิเกล: Dropbox ไม่ใช่ปัญหาของคุณ Dropbox กำลังทำ 443 / tcp เหมือนกับการท่องเว็บอื่น ๆ แต่ในกรณีที่คุณต้องการทำการดมกลิ่นเครือข่าย (Wireshark หรือ tcpdump) การหยุด Dropbox จะลบทราฟฟิก TCP จำนวนมาก ดังนั้นสิ่งนี้จะช่วยให้คุณ "เห็น" การกระทำที่ไม่เหมาะสมใด ๆ
— แดน
1
@Miguel คาดเดาอีกมาก 1. คุณได้ติดต่อ ISP ของคุณเพื่อดูว่าพวกเขาสามารถตรวจสอบคุณภาพของสายได้หรือไม่? 2. วิธีการเกี่ยวกับการตั้งค่าบัญชีผู้ใช้ทดสอบเพื่อดูว่าปัญหาเกิดขึ้นหรือไม่ ข้อเสนอแนะที่สามคือการตรวจสอบระบบของคุณ - เช่นการตรวจสอบสิทธิ์ - การวินิจฉัยเครื่อง 4. คุณสามารถสลับส่วนประกอบออกมาได้หรือไม่ - รันคอมพิวเตอร์ของคุณที่ตำแหน่งเพื่อน - ยืมเราเตอร์เพื่อนของคุณ - โอ้แล้วเอาอุปกรณ์เครือข่ายอื่น ๆ ออกจากระบบของคุณ
— David DelMonte
2

มีข้อมูลมากมายที่นี่เกี่ยวกับการแก้ไขปัญหาและการสิ้นสุดการวินิจฉัย แต่บางครั้งเมื่อการแก้ไขปัญหามันสนุกที่จะกลับไปสู่พื้นฐานและตั้งคำถามบางอย่าง

ดังที่ฉันได้กล่าวถึงในความคิดเห็นนี้ดูเหมือนว่าเราเตอร์ QOS เตะในเนื่องจากเครื่องของคุณเกินแบนด์วิดท์หรืออัตราการส่งแพ็คเก็ตชั่วคราว

ถ้าคุณทำรูปแบบปริมาณและปริมาณของการรับส่งข้อมูลเครือข่ายที่แตกต่างกันในขณะที่บน OS X ไม่ใช่ Windows และนั่นเป็นสาเหตุที่แท้จริงไม่ใช่ไดรเวอร์ฮาร์ดแวร์หรือซอฟต์แวร์

ฉันคาดหวังว่าการใช้งาน OS X นั้นมีความสัมพันธ์กับข้อสังเกตของคุณ แต่ถ้าหากไม่ใช่สาเหตุของเครือข่ายชั่วคราวจะหยุดชั่วคราว

คุณได้ลองทำการวิจัยแล้วถ้าตัวกรอง QOS และการเปลี่ยนเส้นทางถูกใช้งานโดยผู้ให้บริการเครือข่ายของคุณ? คุณได้พิจารณาช่องทางการรับส่งข้อมูลทั้งหมดไปยังคอมพิวเตอร์เครื่องอื่น (ssh หรือ VPN) เพื่อให้คุณสามารถแยกแยะตัวกรองเล็กน้อยได้หรือไม่ (หากผู้ให้บริการทำการตรวจสอบแพ็คเก็ตลึกหรือปลายทางและการ จำกัด อัตราที่แท้จริง - คุณอาจไม่สามารถหลีกเลี่ยงการหมดเวลาสั้น ๆ เหล่านี้ได้)

ฉันหวังว่าจะมีคำตอบที่คุณสามารถหาได้โดยดูที่รายละเอียดของเครือข่าย (และเราทุกคนจะเรียนรู้อะไรบางอย่างจากการสำรวจตัวเลือกเหล่านั้น) - แต่ต้องแน่ใจว่าคุณพิจารณาเครื่องมือในการวัดของคุณและเพิ่มปริมาณการใช้ ส่งผลต่อจำนวนการเข้าชมและทำให้ Skype มีแนวโน้มที่จะลดลงสำหรับคุณ เราเตอร์ที่ฉันตั้งค่านั้นถูกตั้งโปรแกรมให้ปล่อยการรับส่งข้อมูล ICMP ก่อนการรับส่งข้อมูลอื่นทั้งหมดตั้งแต่เมื่อความจุแน่น - ฉันต้องการ ping ล้มเหลวและแพ็กเก็ตอื่น ๆ ISP และผู้ให้บริการเครือข่ายของคุณอาจตั้งค่าในทำนองเดียวกัน

— bmike
แหล่งที่มา
ฉันเห็น ... แต่ไม่มีอะไรเปลี่ยนแปลงในกิจกรรมเครือข่ายใน 5 ปีที่ผ่านมา ปัญหานี้เริ่มต้นเมื่อประมาณหนึ่งเดือนที่แล้วและฉันไม่สามารถพบความสัมพันธ์ใด ๆ ยกเว้นว่ามันเป็นประมาณหนึ่งเดือนที่ผ่านมาเมื่อเพื่อนร่วมงาน 2 คนย้ายเข้ามา แต่ฉันวิ่งทดสอบ ping บนเครื่องของพวกเขาและพวกเขาไม่พบปัญหานี้ ฉันไม่ทราบถึงตัวกรอง QOS ใด ๆ แต่ฉันจะพยายามค้นหา
— Mike D.
Skype กำลังโฮสต์สายเกือบ 24/7 บนเครื่องของฉัน ... ฉันจะปิดการปิงทั้งหมดและอื่น ๆ ในวันนี้เพื่อดูว่ามีอะไรเปลี่ยนแปลงในครั้งต่อไปที่การเชื่อมต่อขาดหายไปหรือไม่ (เพราะฉันยังคงสามารถบอกได้ว่า ฉันได้รับจากการโทร Skype)
— Mike D.
2

นอกเหนือจากทุกสิ่งที่นี่คุณอาจต้องการตรวจสอบว่า Auto Proxy Discovery ไม่ได้เปิดอยู่ (รวมถึงการกำหนดค่าพร็อกซีอัตโนมัติ) ที่มีแนวโน้มที่จะทำให้เกิดปัญหามากกว่าไม่และบ่อยครั้งที่มันไม่จำเป็น

ค่ากำหนดของระบบ

— Martin Marconcini
แหล่งที่มา
ขอบคุณสำหรับคำแนะนำพวกเขาถูกปิดแล้ว :(
— Mike D.
2

ด้วยข้อมูลการวินิจฉัยที่ยอดเยี่ยมทั้งหมดในคำถามนี้คุณได้จำกัดความเป็นไปได้อย่างมาก

เริ่มต้นด้วยการส่ง Ping ไปที่ 192.168.1.1 เพื่อแยกปัญหาอย่างมากไปยังเราเตอร์คอมพิวเตอร์หรือ LAN นี่ไม่ใช่ปัญหากับ DNS หรือ ISP ของคุณ

ฉันถูกรบกวนมากที่สุดจากผลการทดสอบ ping ของคุณที่ 192.168.1.1 คุณทำอะไรแปลก ๆ ในการตั้งค่าหรือไม่?

ตัวอย่างเช่นคุณประสบความสำเร็จในการส่ง Ping กับหมายเลขลำดับ 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 ... ฉันไม่รู้ว่าทำไมอาจเป็น ... ping ยาวเกินไปหรือไม่ (มันใช้งานมาหลายวันแล้ว) ... ไม่มีความคิด นอกจากนี้การกำหนดค่าเครือข่ายของฉันก็เรียบง่ายและฉันใช้การตั้งค่าเดียวกันมาหลายปีโดยไม่มีปัญหา
— Mike D.
1
ซอฟต์แวร์ที่ทำงานในพื้นหลังอยู่ตลอดเวลาและอาจมีบางสิ่งที่เกี่ยวข้องกับสิ่งนี้: Little Snitch, Dropbox, Skype, และ OS X ทั้งหมด ... แต่ไม่มีอะไรใหม่และปัญหาเริ่มต้นเมื่อประมาณหนึ่งเดือนที่แล้ว สิ่งหนึ่งที่ฉันสงสัยคือประมาณหนึ่งเดือนที่ผ่านมาเมื่อเพื่อนร่วมห้องใหม่ 2 คนย้ายเข้ามาฉันรันการทดสอบ ping ในคอมพิวเตอร์ของพวกเขาและพวกเขาไม่พบปัญหานี้
— Mike D.
@Miguel ลบ Little Snitch ออกอย่างแน่นอนเนื่องจากเป็นซอฟต์แวร์ที่สามารถสร้างปัญหานี้ได้ หากคุณไม่ได้มีการกำหนดค่าที่ซับซ้อนฉันจะบอกว่าถอนการติดตั้งอย่างสมบูรณ์และยังล้างถังขยะเพื่อให้แน่ใจว่ามันหายไปและรีบูตและดูว่าการแก้ไขปัญหา
— โปรเก่า
ตกลงฉันจะถอนการติดตั้งอย่างสมบูรณ์และดูว่าเกิดอะไรขึ้น (แต่ฉันใช้มันมาหลายปีแล้วโดยไม่มีปัญหา)
— Mike D.
ตลก ... 24269 ในเลขฐานสองคือ 0000 0101 1110 1100 1101 89806 ในรูปแบบเลขฐานสองคือ 0001 0101 1110 1100 1110 อย่างไรก็ตามถ้าเราใช้ 24269 และเปลี่ยน bit 16 เราได้รับ 0001 0101 1110 1100 1101 = 89805 ดูเหมือนว่าเป็นจำนวนเต็มเมื่อเทียบกับที่ไม่ได้ลงชื่อดังนั้นการนำเสนอตัวเลขอย่างหมดจด มันอาจจะเป็นว่าอุปกรณ์ที่มิเกลกระตุกใช้จำนวนเต็มไม่ได้ลงนามแทนการลงนาม (หรือรอบทางอื่น) ...
— ไมค์
2

ฉันรู้ว่านี่เป็นหัวข้อเก่า

แต่ขอบคุณทุกคนสำหรับการแก้ไขปัญหานี้ ขั้นตอนทั้งหมดช่วยฉันแก้ไขปัญหาที่ฉันสามารถ ping ไพร่พล แต่ไม่เชื่อมต่อกับพวกเขาผ่าน telnet

การแก้ปัญหาค่อนข้างง่าย (หลังจากนั้น) นำสิ่งที่ไม่จำเป็นออกจากที่นี่ (ตามที่กล่าวถึง zac)

เข้าสู่ระบบ:

~ / Library / LaunchAgents / ~ / Library / LaunchDaemons / การตั้งค่าระบบ> ผู้ใช้และกลุ่ม> รายการเข้าสู่ระบบ

เริ่มต้น:

/ Library / LaunchAgents / / Library / LaunchDaemons / / Library / StartupItems / /Library/Preferences/com.apple.loginitems.plist (ไม่ค่อยมีอยู่)

ขอขอบคุณอีกครั้ง

— JustM
แหล่งที่มา
1

ปัญหาที่น่าสงสัยพิจารณาว่ามันยังคงอยู่ของอีเธอร์เน็ต ฉันมีปัญหาที่คล้ายกัน แต่พบว่าสัญญาณรบกวน WiFi จากเครือข่ายอื่นเป็นปัญหา การเปลี่ยนมาใช้ย่านความถี่ 5GHz ช่วยแก้ไขปัญหาของฉันซึ่งก็ถือว่าคุ้มค่ากับการยิง

— อเล็กซานเด
แหล่งที่มา
ก่อนที่จะเปลี่ยนแชนเนลเครือข่ายเพราะคุณคิดว่าคุณมีปัญหาสัญญาณรบกวน นี่คือสวยง่ายใช้งาน: ใช้istumbler.net คุณจะมองความจริงตรงเข้าไปในดวงตา☺
— แดน
1

คำแนะนำใด ๆ จาก /var/log/system.log?

netstat -s มีลักษณะอย่างไร

ลางสังหรณ์ของฉันบอกว่าลบ / Library / Preferences / SystemConfiguration และเพิ่มอินเทอร์เฟซเครือข่ายกลับด้วยตนเอง

ดูเหมือนว่าคุณจะลองหลายอย่างแล้ว

— epoon
แหล่งที่มา
สวัสดีมิเกลเพิ่ม voodoo มากขึ้นหลังจากเห็นภาพหน้าจอของคุณ คุณลองสามสิ่งนี้ได้ไหม: 1: ปิดการใช้งานบลูทู ธ , 2: ทดสอบการเชื่อมต่อเครือข่าย 1 โดย 1 3: เพียงเพื่อยืนยันว่าคุณใช้ไดรเวอร์เครือข่ายหุ้นใช่มั้ย
— epoon
system.log มีขนาดใหญ่มาก ... ฉันค้นหาคำเฉพาะ แต่ไม่พบสิ่งที่เกี่ยวข้อง :(
— Mike D.
ฉันจะแก้ไขคำถามที่เพิ่มข้อมูลที่ netstat -s มอบให้ฉัน
— Mike D.
ฉันลบการกำหนดค่าเครือข่ายทั้งหมดแล้ว และเพิ่มทุกอย่างกลับด้วยตนเอง แต่ไม่มีโชค บลูทู ธ ถูกปิดอยู่เสมอ ฉันใช้ไดรเวอร์เครือข่ายหุ้น อินเทอร์เฟซเครือข่ายทั้งหมดให้ผลลัพธ์ที่เหมือนกันทั้งหมด: การสูญเสียการเชื่อมต่อชั่วขณะชั่วขณะแล้ว :(
— Mike D.
1
ข้อผิดพลาดของแพ็กเก็ต icmp และ ip นั้นเป็นปัญหากับฉัน แยกต่างหากติดตั้งสำเนาใหม่ของ OSX และบู๊ตผ่าน USB นี่จะแยกการติดตั้ง OSX ของคุณ หากสำเนาใหม่ยังคงเป็นบั๊กอยู่เรามีข้อผิดพลาดด้านฮาร์ดแวร์ - ใครจะรู้อาจเป็นเพียงไดรเวอร์ OSX เท่านั้นที่จะทริกเกอร์ได้ แสดงว่าปัญหานั้นปรากฏขึ้นในการติดตั้งใหม่และ Apple ควรแก้ไขให้คุณ
— ตอนที่
1

มีลักษณะเช่นนี้หรือไม่

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

ฉันเพิ่งโพสต์สิ่งนี้สำหรับ Mavericks คิด?

— Meh
แหล่งที่มา
1
แม้ว่าลิงก์นี้อาจตอบคำถามได้ดีกว่าหากรวมส่วนสำคัญของคำตอบไว้ที่นี่และให้ลิงก์สำหรับการอ้างอิง คำตอบสำหรับลิงค์เท่านั้นอาจไม่ถูกต้องหากหน้าเว็บที่เชื่อมโยงมีการเปลี่ยนแปลง
— grg
ฉันจะลองดูวิธีแก้ปัญหาในลิงค์เพื่อดูว่ามันช่วยฉันด้วยหรือไม่ จะโพสต์กลับ
— Mike D.
0

Mac OSX Hints 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 นั้นจะช่วยแก้ไขปัญหาของคุณได้

— BlipBertMon
แหล่งที่มา
5
นั่นจะไม่ทำให้เกิดปัญหานี้ ping ทำการค้นหา DNS หนึ่งครั้ง (google.com -> 173.194.34.196 ในกรณีนี้) จากนั้นใช้ที่อยู่ IP ตั้งแต่นั้นมา
— Gordon Davisson
จะทำสิ่งนี้และรายงานกลับ
— Mike D.
1
→ Blip: นี่ไม่ใช่ปัญหาที่เกี่ยวข้องกับ DNS การ ping ไปยังเราเตอร์ที่มีที่อยู่ IP ไม่ได้สร้าง udp paquet ใด ๆ เพียงแค่สะท้อน icmp โง่ ๆ
— แดน
0

กลิ่นนี้เหมือนอุปกรณ์อื่นในเครือข่ายของคุณกำลังพยายามใช้ IP เดียวกันกับคุณหรือมีปัญหากับ DHCP

คุณเห็นหรือไม่ว่าคุณยังคงสามารถทำซ้ำได้หลังจากกำหนด IP แบบคงที่ให้กับตัวเอง

ไปที่การตั้งค่าเครือข่ายเลือกอินเตอร์เฟสอีเธอร์เน็ตขั้นสูง TCP / IP

เปลี่ยนรายการแบบเลื่อนลง "กำหนดค่า IPv4" เป็น "ด้วยตนเอง"

ที่อยู่ IPv4: 192.168.1.150 (สิ่งที่ไม่เหมือนใครไม่ใช่สิ่งที่ DHCP มอบหมายให้คุณก่อน) Subnet Mask: 255.255.255.0 เราเตอร์: 192.168.1.1

บันทึก

จากนั้นลองสร้างปัญหาอีกครั้ง เมื่อทำการทดสอบนี้ตรวจสอบให้แน่ใจว่า Wi-Fi ของคุณปิดอยู่ดังนั้นจึงมีเพียงอีเธอร์เน็ตที่ใช้งานอยู่ สิ่งนี้จะช่วยให้แคบลง

หากคุณยังมีปัญหาอยู่คุณควรดาวน์โหลด Wireshark ( http://www.wireshark.org/ ) เริ่มการจับภาพสร้างปัญหาขึ้นมาใหม่บันทึกการถ่ายโอนข้อมูลและให้เราดู

นอกจากนี้คุณใช้เราเตอร์ / AP อะไร?

— skrewler
แหล่งที่มา
0

ตรวจสอบสองสิ่งที่สัมพันธ์กับสิ่งนี้ที่เกิดจากการเพิ่มปริมาณการใช้ LAN เนื่องจากเพื่อนร่วมห้องใหม่

  1. มีการตั้งค่า QoS (Quality of Service) บนเราเตอร์หรือไม่และหากเป็นเช่นนั้นจะมีการตั้งค่าอย่างไร ปริมาณการใช้ Skype จะถูกจัดลำดับความสำคัญและหาก WAN กำลังอิ่มตัวเราเตอร์อาจตอบสนองโดยการปิดการเชื่อมต่อที่มีลำดับความสำคัญต่ำกว่าชั่วคราว
  2. ซีพียูเราท์เตอร์เพิ่งโอเวอร์โหลดหรือไม่? เมื่อฉันอัพเกรดจากบริการเคเบิล 1 Gbs DSL เป็น 5 Gbs ฉันพบว่าเราเตอร์ของฉันไม่สามารถรับปริมาณการใช้งานที่เพิ่มขึ้นและต้องซื้อใหม่ ตรวจสอบประสิทธิภาพของเราเตอร์ของคุณและดูว่านี่อาจเป็นปัญหาหรือไม่ เราเตอร์ส่วนใหญ่มีรีวิวแบบละเอียดที่มีอยู่ในอินเทอร์เน็ต ตรวจสอบและดูว่าเราเตอร์ของคุณได้รับการจัดอันดับอย่างไรเมื่อเทียบกับความสามารถในการให้บริการอินเทอร์เน็ตของคุณ
— โปรเก่า
แหล่งที่มา
0

เฮ้พวกฉันกำลังมีปัญหาที่แน่นอนเหมือนกัน แต่ฉันเพิ่งถอดปลั๊กหูฟังที่ฉันใช้และฉันได้พูดคุยกับเพื่อนใน 10 นาทีแรกตอนนี้และมันก็ยังไม่ลดลงเมื่อก่อนที่มันจะลดลงใน 20 วินาที

สายหูฟังของฉันถูกฉีกดังนั้นมันอาจเป็นสาเหตุของปัญหา แต่ฉันไม่รู้อะไรมากมายเกี่ยวกับที่อยู่ IP และสิ่ง ping และสิ่งนี้ดูเหมือนจะช่วยฉันออก ถ้าคุณลองและมันไม่ทำงานไม่โทษฉันเพราะมันแก้ไขปัญหาของฉัน

— Wonderman
แหล่งที่มา
0

การแก้ปัญหาค่อนข้างง่าย (หลังจากนั้น) นำสิ่งที่ไม่จำเป็นออกจากที่นี่ (ตามที่กล่าวถึง zac)

เข้าสู่ระบบ:

~ / Library / LaunchAgents / ~ / Library / LaunchDaemons / การตั้งค่าระบบ> ผู้ใช้และกลุ่ม> รายการเข้าสู่ระบบ

เริ่มต้น:

/ Library / LaunchAgents / / Library / LaunchDaemons / / Library / StartupItems /> /Library/Preferences/com.apple.loginitems.plist (ไม่ค่อยมีอยู่)

ฉันรู้ว่านี่เป็นด้ายเก่า แต่การทำเช่นนี้แก้ไขปัญหาที่ฉันมี บางครั้งอินเทอร์เน็ตของฉันจะตัดการเชื่อมต่อและ ping จะลดลงตลอดเวลา สิ่งที่จะแก้ไขปัญหาของฉันได้คือปิด Wi-Fi หรืออีเธอร์เน็ต (ซึ่งฉันเคยใช้) แล้วเปิดใช้งานอีกครั้ง แน่นอนว่านี่เป็นการแก้ไขปัญหาชั่วคราวเท่านั้น มันแปลกเพราะเมื่อใดก็ตามที่ mac pro 4,1 ของฉันมีปัญหานี้แล็ปท็อป mac ของฉันก็จะสูญเสียการส่ง Ping เช่นกัน มันเกือบจะเหมือนกับที่ Mac Pro ของฉันจะทำให้เครือข่ายของฉันแย่ลง

ฉันลองหลายสิ่งหลายอย่าง! เปลี่ยนโมเด็มเราเตอร์ที่เรียกว่า isp ซื้อ usb ไปยังอีเธอร์เน็ต สิ่งเหล่านั้นไม่ทำงานจนกว่าฉันจะลองสิ่งนี้!

ฉันทำสิ่งที่กล่าวมาข้างต้นและในที่สุดก็แก้ไขปัญหาได้ !!

— เดวิด
แหล่งที่มา
0

ฉันมีปัญหาที่คล้ายกันและในกรณีของฉันดูเหมือนจะเกิดจาก Tunnelblick แม้ว่าจะไม่ได้เชื่อมต่อ VPN ฉันถอนการติดตั้ง (ด้วยตัวถอนการติดตั้งไม่ใช่แค่ลากไปที่ถังขยะ) และปัญหาก็หายไป

— csanchez
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.