Ostatnio miałem problem z połączeniem internetowym na moim MacBooku Pro na początku 2011 roku z systemem OS X 10.8.3: od czasu do czasu połączenie „zawiesza się” na około 5 sekund, a następnie wraca.
Dzieje się tak zarówno przez Wi-Fi, jak i przez kabel Ethernet , i dzieje się to tylko z moim komputerem, gdy jest uruchomiony system OS X (nie stanie się to, gdy system Windows 7 zostanie uruchomiony na tym samym komputerze lub na innym komputerze / urządzeniu). Wywołuje połączenia Skype co 2 minuty, więc jest to bardzo frustrujące.
Pinging Google.com wygląda tak podczas uruchamiania OS X (istnieją setki pakietów, które zwracają w czasie krótszym niż 100 ms (z kilkoma w zakresie 130), a następnie odpadają na kilka sekund) :
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
Uwaga: adres MAC Wi-Fi mojego urządzenia to 68: a8: 6d: 29: cf: 8a (statyczny IP 192.168.1.250), a jego adres Ethernet to 3c: 07: 54: 5a: e0: 44 (statyczny IP 192.168.1.251) . Adres IP routera to 192.168.1.1, a jego adres WAN to 85.61.155.224.
Na następnym zrzucie ekranu widać podczas rozmowy Skype:
ping 192.168.1.1
w lewym górnym rogu.ping 85.61.155.224
w lewym dolnym rogu.ping google.com
w prawym dolnym rogu.arp -an
iarp -ad
polecenia wykonywane.
Kiedy wykonałem arp -ad
polecenie w momencie, gdy połączenie zostało utracone, na liście nie było żadnych adresów. Wyglądało to tak:
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$
Nie mam wystarczającej wiedzy, aby postępować zgodnie z instrukcjami Mike'a, jak uzyskać i skompilować źródło mtr
polecenia.
Tak wygląda sytuacja, gdy jest gorzej:
Bieganie netstat -s
daje:
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
Bieganie netstat -I en1
daje:
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 - -
Bieganie ifconfig -a
daje:
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
Co myślę:
- To nie jest problem z Wi-Fi, ponieważ zdarza się to również przez kabel.
- To nie jest problem z routerem / usługodawcą internetowym, ponieważ inne urządzenia i maszyny nie mają problemu.
- To nie jest problem z komputerem, ponieważ zdarza się to tylko podczas działania systemu OS X.
- Dlatego musi to być problem z OS X.
Co próbowałem:
- Uruchom ponownie, zamknij.
- Włącz i wyłącz AirPort, różne kable Ethernet.
- Uprawnienia do naprawy.
- Zresetuj PRAM.
- Wyczyść wszystkie pamięci podręczne systemu i użytkownika za pomocą Onyx.
Dziwna uwaga: z jakiegoś dziwnego powodu problem wydaje się nasilać, gdy odbywa się rozmowa na skype.
Byłbym wdzięczny za pomysły na rozwiązanie tego problemu.
Odpowiedzi:
Kiedy przekroczą limit czasu połączenia, czy możesz to zrobić
arp -an
w Terminal.app i sprawdzić, czy nadal masz wszystkie adresy MAC w tabeli ARP? as in - adres MAC routera lub host, który próbujesz pingować?Jeśli to zrobisz (i masz czas, zanim znów zacznie działać), czy możesz opróżnić tablicę arp (
sudo arp -ad
), a następnie sprawdzić, czy adres MAC routera ponownie pojawia się w tabeli ARP?Spróbuj także uruchomić polecenie ping do adresu IP routera w jednej sesji terminalu, a może ping do adresu WAN routera w innym, podczas korzystania ze Skype. Sprawdź, czy wszystkie przekroczą limit czasu, czy tylko jeden z nich.
mtr
Kolejnym narzędziem, które uważam za przydatne , może być konieczne uzyskanie źródła i samodzielne skompilowanie go lub użycie fink / macports lub innego menedżera pakietów. Gdy go zdobędziesz, po prostu uruchom go w miejscu docelowym w Internecie, a pokaże Ci, który chmiel przestaje odpowiadać.Jak zainstalować oprogramowanie ze źródeł (takich jak mtr) Wymaga zainstalowania Xcode :
gzip -dc filename.tar.gz | tar -xvf -
, który zwykle utworzy nowy katalog w bieżącym katalogu i umieści tam zawartość archiwum)./configure --prefix=/usr/local
(uwaga: lubię instalować oprogramowanie ze źródła do,/usr/local
aby trzymać go z dala od plików binarnych zainstalowanych jako część systemu;--prefix=/usr/local
wystarczy opcja konfiguracji)make
sudo make install
źródło
mtr
jest doskonałym narzędziem. Niestety problem tutaj jest znacznie mniejszy. Problem wydaje się występować między MacOS X a 192.168.1.1. Nie musisz polować w stronę horyzontu Internetu ☺.Czy możesz najpierw sprawdzić, czy naprawdę używasz interfejsu sieciowego, powinieneś:
Czy możesz spojrzeć na wynik następujących poleceń (jeśli en0 to nazwa interfejsu sieciowego karty Ethernet):
Aby pomóc w zlokalizowaniu problemu, możesz utworzyć konkretną lokalizację z aktywowaną kartą Ethernet i jeśli to możliwe, używając tylko IPv4 lub IPv6, ale nie jednocześnie:
Czy możesz uruchomić następujący fragment potencjalnych błędów sprzętowych lub sterowników:
(nie bój się, możesz znaleźć wiele informacji o kanałach Wi-Fi).
Następujący komunikat wyświetlany przez twoją sieć:
oznacza, że faktycznie jesteś celem głupiego zalewania synem TCP (co jest atakiem typu DOS).
Kiedy twój:
dławiki przez 6s, czy możesz uruchomić:
źródło
ping 192.168.1.1
(które nie wykona żadnego żądania DNS).Automatic
konfiguracją.ifconfig -a
?Automatic
lokalizacji w Preferencjach sieciowych, utworzyłem nową lokalizację dla domu i pracy i wygląda na to, że zatrzymało limity czasu blokowania.Mam ten problem od dłuższego czasu (począwszy od aktualizacji do Mavericks) i po miesiącach badań myślę, że w końcu znalazłem rozwiązanie.
Przede wszystkim na forach Apple jest sporo osób z tym samym problemem:
Jest to znany problem i naprawdę nie wiem, dlaczego Apple nie zapewnił jeszcze rozwiązania tego problemu. W wymienionych wyżej wątkach jest wiele sugestii, aby to naprawić, ale większość z nich nie działała. Niektóre tymczasowo naprawiają problem:
sudo rm -rf /Library/Preferences/SystemConfiguration
Po tych działaniach połączenie sieciowe czuje się znacznie lepiej i nie odczuwam spadków przez kilka godzin, a czasem nawet dni. Ale problemy zawsze wracają.
To pytanie i wskazówki, że problem może być związany z ARP, skłoniły mnie do rozpoczęcia dalszych badań i znalazłem tę stronę , która szczegółowo opisuje błąd, a także zawiera łatkę, którą cytuję tutaj:
Zapoznaj się z podanym linkiem, aby uzyskać szczegółowe wyjaśnienie poprawki, która ma zostać uwzględniona w przyszłej aktualizacji systemu operacyjnego Yosemite firmy Apple. Wyłącza żądania ARP emisji pojedynczej, co powoduje zamieszanie z niektórymi urządzeniami sieciowymi, takimi jak domowy router.
Po zastosowaniu poprawki i ponownym uruchomieniu należy sprawdzić, czy
zwraca
net.link.ether.inet.arp_unicast_lim: 0
. Jeśli liczba nie jest równa zero, poprawka nie została poprawnie zastosowana.Potem znalazłem inny wątek w społecznościach Apple, który zawiera to samo rozwiązanie: Mavericks i Failed ARP powodujący spadek sieci! Po tym, jak wiesz, na czym polega problem, znalezienie odpowiedniego rozwiązania jest o wiele łatwiejsze.
źródło
Po pierwsze, widzę dropbox działający na pasku menu; czy już to wyłączyłeś?
Po drugie, spróbuj usunąć wszelkie inne elementy uruchamiania / logowania. Zaglądać:
Zaloguj Się:
Uruchomienie:
źródło
Jest tu wiele informacji na temat rozwiązywania problemów i diagnostyki, ale czasem podczas rozwiązywania problemów fajnie jest wrócić do podstaw i zakwestionować pewne założenia.
Jak wspomniałem w komentarzu, wygląda to bardzo podobnie do routera QOS, ponieważ Twój komputer tymczasowo przekroczył pewien limit przepustowości lub prędkości pakietów.
Co się stanie, jeśli wykonujesz różne wzorce, natężenia i wielkość ruchu sieciowego w systemie OS X w przeciwieństwie do systemu Windows, a to jest prawdziwa przyczyna, a nie sterowniki sprzętowe lub oprogramowanie?
Spodziewałbym się, że uruchomienie OS X jest skorelowane z twoimi obserwacjami, ale co, jeśli nie jest to przyczyną tymczasowych przerw w sieci.
Czy próbowałeś dowiedzieć się, co się stanie, jeśli dostawca filtrów sieci wprowadzi jakieś filtry QOS i zmiany routingu? Czy rozważałeś tunelowanie całego ruchu do innego komputera (ssh lub VPN), aby wykluczyć trywialne filtry. (Jeśli dostawca dokonuje głębokiej kontroli pakietów lub ograniczenia docelowego i rzeczywistego ograniczenia - możesz nie być w stanie uniknąć tych krótkich limitów czasu.)
Mam nadzieję, że znajdziesz odpowiedź, patrząc na szczegóły sieci (i wszyscy nauczymy się czegoś z eksploracji tych opcji) - ale upewnij się, że bierzesz również pod uwagę, że twoje narzędzia pomiarowe i dodatkowy ruch do ping / poke na rzeczy mogą wpływać na liczbę odwiedzin i zwiększać prawdopodobieństwo, że Skype spadnie za Ciebie. Routery, które skonfigurowałem, są zaprogramowane do opuszczania ruchu ICMP przed wszystkimi innymi ruchami, ponieważ gdy przepustowość staje się mała - wolałbym, aby ping się nie powiódł i inne pakiety przeszły. Twój dostawca usług internetowych i dostawca sieci mógł skonfigurować to samo.
źródło
Oprócz wszystkich tych elementów możesz chcieć upewnić się, że funkcja automatycznego wykrywania proxy nie jest włączona (podobnie jak automatyczna konfiguracja serwera proxy). To zwykle powoduje więcej problemów i nie jest często potrzebne.
źródło
Wszystkie te informacje diagnostyczne zawarte w tym pytaniu znacznie zawęziły możliwości.
Na początek twoje pingi do 192.168.1.1 znacznie izolują problem od twojego routera, komputera lub sieci LAN. To nie jest problem z DNS ani twoim dostawcą usług internetowych.
Najbardziej niepokoją mnie wyniki twoich testów ping do 192.168.1.1. Czy zrobiłeś coś dziwnego, ustawiając je?
Na przykład, masz udane pingi o numerach sekwencji ICMP 24267, 24268 i 24269, następnie 3 limity czasu, a następnie sukces ponownie z ICMP 24273. Więc liczba sukcesów wydaje się odpowiednia. Liczby limitów czasu są jednak zupełnie inne. Spodziewałbym się zobaczyć przekroczenia limitu czasu żądań z ICMP 24270, 24271 i 24272, ale zamiast tego limity czasu zgłaszają ICMP 89806, 89807 i 89808. Nigdy wcześniej tego nie widziałem, więc dla mnie sugeruje to, że masz zepsuty stos sieciowy na tym komputer. Być może o jeden za dużo rozszerzeń. Czy jest szansa, że masz zainstalowany Netgear Genie? A może oprogramowanie VPN?
W każdym razie powiedziałbym, że nadszedł czas, aby wyłączyć „ulepszenia”, aby sprawdzić, czy możesz znaleźć winowajcę zainstalowanego na komputerze.
Edytować
OK, zagadka rozwiązana. Numer kolejny ICMP jest polem 16-bitowym. Traktowane jako liczba całkowita bez znaku, co oznacza, że ma maksymalną wartość 65 535, a następnie zawija się do zera. Więc jeśli lokalny program ping utrzymuje 32-bitowy licznik liczb całkowitych (co prawdopodobnie domyślnie by zrobił), mógłby zgłosić 32-bitową liczbę całkowitą dla brakujących pakietów. Jednak podczas czytania odpowiedzi odpowiedź musi koniecznie zawierać tylko ostatnie 16 bitów licznika. Zatem odpowiedzią na numer sekwencji 89805 będzie 89505 i 0xFFFF, czyli 24269.
źródło
Wiem, że to stary temat.
Ale dziękuję wszystkim za to rozwiązywanie problemów. Wszystkie te kroki pomogły mi rozwiązać problem polegający na tym, że mogłem pingować hosty, ale nie mogłem się z nimi połączyć przez telnet.
Rozwiązanie było raczej proste (potem) usunęło wszystkie niepotrzebne rzeczy stąd (jak wspomniano zac)
Zaloguj Się:
~ / Library / LaunchAgents / ~ / Library / LaunchDaemons / Preferencje systemowe> Użytkownicy i grupy> Elementy logowania
Uruchomienie:
/ Library / LaunchAgents / / Library / LaunchDaemons / / Library / StartupItems / /Library/Preferences/com.apple.loginitems.plist (rzadko istnieje)
Jeszcze raz dziękuję wszystkim
źródło
Ciekawy problem, biorąc pod uwagę, że nadal występuje w sieci Ethernet. Miałem podobny problem, ale problemem były zakłócenia Wi-Fi z innych sieci. Przejście na pasmo 5 GHz rozwiązało mój problem, który wydaje się, że warto spróbować.
źródło
Wszelkie wskazówki z /var/log/system.log?
jak wygląda netstat -s?
Moje przeczucie mówi usunięcie / Biblioteka / Preferencje / Konfiguracja systemu i ręczne dodanie interfejsów sieciowych.
Wygląda na to, że próbowałeś już wielu rzeczy.
źródło
Wyglądasz podobnie do tego?
https://discussions.apple.com/thread/5483424?tstart=0
Właśnie opublikowałem to dla Mavericks. Myśli?
źródło
Wskazówki dla systemu Mac OSX http://hints.macworld.com/article.php?story=20080605143917233 na temat porzuconych połączeń, ponieważ wyszukiwania DNS nie powiodły się w oczekiwaniu na identyfikację routera przez DCHP.
Najprawdopodobniej jest to ustawienie DNS i / lub przyspieszenie w ustawieniach modemu, a ominięcie tego DNS powinno pomóc rozwiązać problem.
źródło
Pachnie to tak, jakby inne urządzenie w sieci próbowało użyć tego samego adresu IP co Ty lub masz problemy z DHCP.
Czy widzisz, czy nadal możesz go odtworzyć po przypisaniu sobie statycznego adresu IP?
Idź do Preferencji sieciowych, wybierz interfejs Ethernet, zaawansowane, TCP / IP
Zmień menu rozwijane „Konfiguruj IPv4” na „Ręcznie”
Adres IPv4: 192.168.1.150 (coś wyjątkowego, nie to, co wcześniej przypisał ci DHCP) Maska podsieci: 255.255.255.0 Router: 192.168.1.1
Zapisać
Następnie spróbuj ponownie odtworzyć problem. Podczas wykonywania tego testu upewnij się, że Wi-Fi jest wyłączone, więc używany jest tylko Ethernet. Pomoże to go zawęzić.
Jeśli nadal masz problem, pobierz Wireshark ( http://www.wireshark.org/ ), rozpocznij przechwytywanie, odtwórz problem, zapisz zrzut i pozwól nam rzucić okiem.
Jakiego routera / punktu dostępu używasz?
źródło
Dwie rzeczy do sprawdzenia, które są powiązane z tym, że jest to spowodowane zwiększonym ruchem LAN z powodu nowych współlokatorów.
źródło
Cześć chłopaki, miałem dokładnie ten sam problem, ale właśnie odłączyłem słuchawki, których używałem i rozmawiam z moim przyjacielem przez pierwsze 10 minut i nadal nie spadło, kiedy spadło po 20 sekundach.
Przewód słuchawek został podarty, co mogło być przyczyną problemu, ale niewiele wiem o adresie IP i pingach, a to chyba mi pomogło. Jeśli spróbujesz i to nie zadziała, nie obwiniaj mnie, bo to naprawiło mój problem.
źródło
wiem, że to stary wątek, ale zrobienie tego rozwiązało problem, który miałem. Mój internet czasami się rozłączał, a pingi ciągle spadały. To, co naprawiłoby mój problem, to wyłączenie Wi-Fi lub Ethernetu (z którego kiedykolwiek korzystałem), a następnie ponowne włączenie. Oczywiście rozwiązałoby to tylko tymczasowo problem. To było dziwne, ponieważ ilekroć mój Mac Pro 4,1 miał ten problem, mój laptop Mac również tracił pingi. To prawie tak, jakby mój Mac Pro zniszczył moją sieć.
Próbowałem tak wielu rzeczy! zastępując modem, router, zwany isp, kupił USB na Ethernet. nic z tych rzeczy nie działało, dopóki tego nie spróbowałem!
Zrobiłem to, co wspomniano powyżej i ostatecznie rozwiązało problem !!
źródło
Miałem podobny problem iw moim przypadku wydaje się, że jest spowodowany przez Tunnelblick, nawet gdy VPN nie był podłączony. Odinstalowałem go (za pomocą deinstalatora, nie tylko przeciągnij do Kosza) i problem zniknął.
źródło