J'ai récemment eu ce problème avec ma connexion Internet sur mon MacBook Pro Début 2011 fonctionnant sous OS X 10.8.3: de temps en temps, la connexion "se fige" pendant environ 5 secondes, puis revient.
Cela se produit à la fois via un câble Wi-Fi ou Ethernet , et cela ne se produit que sur mon ordinateur sous OS X (cela ne se produira pas si Windows 7 est exécuté sur le même ordinateur ou sur un autre ordinateur / périphérique). Skype laisse tomber les appels toutes les 2 minutes environ, donc c'est très frustrant.
La commande Google Google ressemble à ceci lorsque vous utilisez OS X (des centaines de paquets sont renvoyés en moins de 100 ms (quelques-uns dans la plage des 130), puis une chute de plusieurs secondes) :
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
Remarque: le MAC Wi-Fi de ma machine est 68: a8: 6d: 29: cf: 8a (IP statique 192.168.1.250) et son adresse Ethernet est 3c: 07: 54: 5a: e0: 44 (IP statique 192.168.1.251). . L'IP LAN du routeur est 192.168.1.1 et son IP WAN est 85.61.155.224.
Dans la capture d'écran suivante, vous pouvez voir, lors d'un appel Skype:
ping 192.168.1.1
en haut à gauche.ping 85.61.155.224
en bas à gauche.ping google.com
en bas à droite.- les commandes
arp -an
etarp -ad
exécutées.
Lorsque j'ai exécuté la arp -ad
commande à un moment où la connexion était perdue, la liste ne contenait aucune adresse. Cela ressemblait à ceci:
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$
Je ne connais pas suffisamment les instructions de Mike pour obtenir et compiler la source de la mtr
commande.
Voici à quoi les choses ressemblent quand c'est pire:
Courir netstat -s
donne:
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
Courir netstat -I en1
donne:
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 - -
Courir ifconfig -a
donne:
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
Ce que je pense:
- Ce n'est pas un problème de Wi-Fi, car cela se produit également par câble.
- Ce n'est pas un problème de routeur / FAI car les autres appareils et machines n'ont pas de problème.
- Ce n'est pas un problème d'ordinateur car cela ne se produit que sous OS X.
- Ce doit donc être un problème d’OS X.
Ce que j'ai essayé:
- Redémarrer, arrêter.
- Activer et désactiver AirPort, différents câbles Ethernet.
- Autorisations de réparation.
- Réinitialiser le PRAM.
- Effacez tous les caches système et utilisateur avec Onyx.
Note étrange: pour une raison étrange, le problème semble s'aggraver lorsqu'un appel sur Skype a lieu.
J'apprécierais aimablement les idées sur la façon d'aborder cette question.
Réponses:
Lorsque le délai de connexion de vos connexions commence à expirer, pouvez-vous le faire
arp -an
dans Terminal.app et voir si vous avez toujours toutes les adresses MAC dans la table ARP? as in - l'adresse MAC de votre routeur ou l'hôte que vous essayez d'envoyer par ping?Si vous le faites (et vous avez le temps de recommencer à fonctionner), pouvez-vous vider la table arp (
sudo arp -ad
) et voir ensuite si l'adresse MAC de votre routeur apparaît à nouveau dans la table ARP?Essayez également d’exécuter un ping sur l’adresse IP du réseau local de votre routeur dans une session Terminal et, éventuellement, sur l’adresse IP WAN de votre routeur pendant une autre session lorsque vous êtes sur Skype. Voir si tous commencent à chronométrer ou juste l'un d'entre eux. Un autre outil que je trouve utile est
mtr
- vous devrez peut-être obtenir le code source et le compiler vous-même ou utiliser fink / macports ou un autre gestionnaire de paquets. Lorsque vous l'obtenez, exécutez-le simplement vers une destination quelque part sur Internet et il vous indiquera quel saut cesse de répondre.Comment installer un logiciel à partir de sources (telles que mtr) Nécessite l'installation de Xcode :
gzip -dc filename.tar.gz | tar -xvf -
, qui créera généralement un nouveau répertoire dans le répertoire actuel et y placera le contenu de l'archive)./configure --prefix=/usr/local
-vous (notez bien que j'aime bien installer le logiciel à partir de la source/usr/local
pour le garder loin des binaires installés dans le système; l'--prefix=/usr/local
option de configuration le fera exactement)make
sudo make install
la source
mtr
est un excellent outil. Malheureusement ici le problème est beaucoup moins loin. Le problème semble se situer entre MacOS X et 192.168.1.1. Pas besoin de chasser vers l'horizon de l'Internet.Pourriez-vous d'abord vérifier que vous utilisez vraiment l'interface réseau, vous devriez:
Pourriez-vous regarder le résultat des commandes suivantes (si en0 est le nom d'interface réseau de votre carte Ethernet):
Pour vous aider à localiser le problème, pourriez-vous créer un emplacement spécifique en activant uniquement votre carte Ethernet et, si possible, en utilisant uniquement IPv4 ou IPv6, mais pas les deux:
Pourriez-vous exécuter l'extrait suivant d'erreurs potentielles de matériel ou de pilote:
(N'ayez pas peur, vous trouverez peut-être de nombreuses informations sur les canaux Wi-Fi).
Le message suivant affiché par votre netstat:
signifie que vous êtes en réalité la cible d'une stupide TCP inondation (qui est une attaque par déni de service (DOS)).
Quand ton:
chokes for 6s, pourriez-vous courir:
la source
ping 192.168.1.1
(qui ne fera aucune requête DNS).Automatic
configuration.ifconfig -a
?Automatic
emplacement dans les Préférences réseau, créé un nouvel emplacement pour Home et Work et cela semble avoir stoppé les délais de blocage.Je rencontre ce problème depuis longtemps (après une mise à niveau de Mavericks) et, après des mois de recherche, je pense avoir enfin trouvé une solution.
Tout d’abord, un grand nombre de personnes ont le même problème dans les forums Apple:
Il s’agit donc d’un problème connu et je ne sais vraiment pas pourquoi Apple n’a pas encore fourni de solution à ce problème. Dans les discussions énumérées ci-dessus, il existe de nombreuses suggestions pour résoudre ce problème, mais la plupart d'entre elles n'ont pas fonctionné. Certains résolvent le problème temporairement:
sudo rm -rf /Library/Preferences/SystemConfiguration
Après ces mesures, la connexion réseau se sent beaucoup mieux et je n’éprouve aucune chute pendant plusieurs heures, voire quelques jours. Mais les problèmes reviennent toujours.
Cette question et les allusions selon lesquelles le problème pourrait être lié à ARP m'ont amené à poursuivre mes recherches. J'ai trouvé cette page , qui décrit le bogue en détail et contient également un correctif, que je cite ici:
Veuillez vous reporter au lien fourni pour une explication détaillée du correctif, qui est censé être inclus dans une future mise à jour du système d'exploitation pour Yosemite par Apple. Il désactive les demandes ARP en monodiffusion, ce qui entraîne une confusion avec certains équipements réseau tels que votre routeur domestique.
Après avoir appliqué le correctif et redémarré, il convient de vérifier si
retourne
net.link.ether.inet.arp_unicast_lim: 0
. Si le nombre n'est pas égal à zéro, le correctif n'a pas été appliqué correctement.Par la suite, j'ai trouvé un autre fil au sein des communautés Apple qui contient la même solution: Mavericks et Failed ARP provoquant des interruptions de réseau! Eh bien, une fois que vous savez quel est le problème, il est beaucoup plus facile de trouver la bonne solution.
la source
Tout d'abord, je vois dropbox en cours d'exécution dans votre barre de menus. avez-vous désactivé cela, encore?
Deuxièmement, essayez de supprimer tout autre élément de démarrage / connexion. Regarder dans:
S'identifier:
Commencez:
la source
Il contient beaucoup d'informations sur le dépannage et le diagnostic, mais il est parfois amusant de revenir à la base et de remettre en question certaines hypothèses lors du dépannage.
Comme je l'ai mentionné dans un commentaire, cela ressemble beaucoup à un routeur QOS démarrant du fait que votre ordinateur dépasse temporairement une limite de bande passante ou de débit de paquets.
Que se passe-t-il si vous utilisez différents modèles, volumes et quantités de trafic réseau sous OS X par opposition à Windows et que c'est la cause réelle, pas les pilotes matériels ou les logiciels?
J'imagine que l'exécution d'OS X est corrélée à vos observations, mais que faire si ce n'est pas la cause des pauses temporaires du réseau.
Avez-vous essayé de rechercher si des filtres de qualité de service et des modifications de routage étaient implémentés par votre fournisseur de réseau? Avez-vous envisagé de transférer tout le trafic sur un autre ordinateur (ssh ou VPN) afin d'éliminer les filtres triviaux? (Si le fournisseur procède à une inspection approfondie des paquets ou à une destination et à une limitation du débit réel, vous ne pourrez peut-être pas échapper à ces brefs délais.)
J'espère que vous pourrez trouver une réponse en consultant les détails du réseau (et nous allons tous apprendre quelque chose en explorant ces options) - mais assurez-vous également de considérer que vos outils de mesure et le trafic supplémentaire généré par les commandes ping / poke pourraient vous aider. affecter le trafic et rendre plus probable la chute de Skype pour vous. Les routeurs que j'ai configurés sont programmés pour abandonner le trafic ICMP avant tout autre trafic, car lorsque la capacité est réduite - je préférerais que le ping échoue et que les autres paquets passent. Votre FAI et votre fournisseur de réseau ont peut-être configuré la même chose.
la source
En plus de tout ce qui est présenté ici, vous voudrez peut-être vous assurer que la détection automatique du proxy n'est pas activée (ainsi que la configuration automatique du proxy). Cela a tendance à causer plus de problèmes qu'autrement et ce n'est souvent pas nécessaire.
la source
Avec toutes les informations de diagnostic de cette question, vous avez considérablement réduit les possibilités.
Pour commencer, vos pings vers 192.168.1.1 isolent considérablement le problème pour votre routeur, votre ordinateur ou votre réseau local. Ce n'est pas un problème avec DNS ou votre fournisseur de services Internet.
Je suis le plus perturbé par les résultats de vos tests de ping à 192.168.1.1. Avez-vous fait quelque chose de bizarre en les installant?
Par exemple, vous avez des pings réussis avec les numéros de séquence ICMP de 24267, 24268 et 24269, puis 3 expirations, puis le succès à nouveau avec ICMP 24273. Le nombre de succès semble donc correct. Cependant, le nombre de délais d'attente est complètement différent. Je m'attendrais à voir les délais d'attente des demandes ICMP 24270, 24271 et 24272, mais plutôt les rapports ICMP 89806, 89807 et 89808. ordinateur. Peut-être une trop nombreuses extensions. Netgear Genie est-il déjà installé? Ou peut-être un logiciel VPN?
Dans tous les cas, je dirais qu'il est temps de désactiver les "améliorations" pour voir si vous pouvez trouver un coupable installé sur votre ordinateur.
modifier
OK, le mystère résolu. Le numéro de séquence ICMP est un champ de 16 bits. Traité comme un entier non signé, cela signifie qu’il a une valeur maximale de 65 535 et qu’il est ensuite renvoyé à zéro. Ainsi, si le programme ping local maintient un compteur d'entiers de 32 bits (ce qui serait probablement le cas par défaut), il pourrait signaler un nombre entier de 32 bits pour les paquets manquants. Toutefois, lors de la lecture des réponses, celle-ci ne contiendra nécessairement que les 16 derniers bits du compteur. Donc, la réponse au numéro de séquence 89805 sera 89505 & 0xFFFF, soit 24269.
la source
Je sais que c'est un vieux sujet.
Mais merci à tous pour ce dépannage. Toutes les étapes m'ont aidé à résoudre un problème où je pouvais envoyer une requête ping à des hôtes, mais pas me connecter via telnet.
La solution était plutôt simple (après), supprimait toutes les choses inutiles d'ici (comme mentionné par zac)
S'identifier:
~ / Bibliothèque / LaunchAgents / ~ / Library / LaunchDaemons / Préférences Système> Utilisateurs et groupes> Éléments de connexion
Commencez:
/ Library / LaunchAgents / / Library / LaunchDaemons / / Library / StartupItems / /Library/Preferences/com.apple.loginitems.plist (existe rarement)
Encore une fois, merci à tous
la source
Curieux problème compte tenu qu'il persiste d'Ethernet. J'avais un problème similaire, mais le problème était l'interférence WiFi d'autres réseaux. Le passage à une bande de 5 GHz a résolu mon problème, ce qui vaut la peine d'essayer.
la source
Des astuces dans /var/log/system.log?
à quoi ressemble netstat -s?
Mon intuition dit supprimer / Bibliothèque / Préférences / Configuration système et rajouter les interfaces réseau manuellement.
Il semble que vous ayez déjà essayé beaucoup de choses.
la source
Ressembler à cela?
https://discussions.apple.com/thread/5483424?tstart=0
Je viens de poster ceci pour Mavericks. Pensées?
la source
Conseils Mac OSX http://hints.macworld.com/article.php?story=20080605143917233 sur les connexions interrompues car les recherches DNS échouent en attendant l'identification DCHP d'un routeur.
Il est fort probable que le DNS et / ou un paramètre d’accélération défini dans les paramètres de votre modem et le contournement de ce DNS devrait vous aider à résoudre votre problème.
la source
Cela sent comme si un autre appareil de votre réseau essayait d'utiliser la même adresse IP que vous, ou des problèmes avec DHCP.
Pouvez-vous voir si vous pouvez toujours le reproduire après vous être attribué une adresse IP statique?
Aller aux Préférences Réseau, choisissez votre interface Ethernet, avancée, TCP / IP
Changez le menu déroulant "Configurer IPv4" en "Manuellement"
Adresse IPv4: 192.168.1.150 (quelque chose d'unique, pas ce que DHCP vous avait assigné auparavant) Masque de sous-réseau: 255.255.255.0 Routeur: 192.168.1.1
sauver
Ensuite, essayez de reproduire le problème à nouveau. Lorsque vous effectuez ce test, assurez-vous que votre réseau Wi-Fi est désactivé afin que seul votre réseau Ethernet soit utilisé. Cela aidera à le réduire.
Si le problème persiste, vous devez télécharger Wireshark ( http://www.wireshark.org/ ), démarrer une capture, reproduire le problème, enregistrer le dump et laisser-nous jeter un coup d'œil.
En outre, quel routeur / AP utilisez-vous?
la source
Deux choses à vérifier sont en corrélation avec l’augmentation du trafic LAN due aux nouveaux colocataires.
la source
Hé les gars, j'avais exactement le même problème, mais je viens de débrancher le casque que j'utilisais et je parle avec mon ami depuis maintenant 10 minutes et il n'a toujours pas chuté, mais avant, il était tombé à 20 secondes.
Le cordon de mon casque a été déchiré, ce qui a peut-être causé le problème, mais je ne connais pas grand chose à propos de l'adresse IP et du contenu des commandes ping, et cela a semblé m'aider. Si vous essayez et cela ne fonctionne pas ne me blâmez pas, car cela a résolu mon problème.
la source
Je sais que c'est un vieux fil, mais cela a résolu le problème que j'avais. Mon internet se déconnecte parfois et le ping tombe tout le temps. Ce qui réglerait mon problème, c’est d’éteindre la connexion Wi-Fi ou Ethernet, puis de le réactiver. Bien sûr, cela ne résoudrait que temporairement le problème. C'était bizarre, car chaque fois que mon mac pro 4,1 aurait ce problème, mon ordinateur portable mac perdait également des pings. C'était presque comme si mon Mac Pro allait faire tomber mon réseau.
J'ai essayé beaucoup de choses! remplacer le modem, routeur, appelé ISP, acheté USB à Ethernet. aucune de ces choses n'a fonctionné, jusqu'à ce que j'essaye ça!
J'ai fait ce qui est mentionné ci-dessus et le problème a finalement été résolu!
la source
J'ai eu un problème similaire et dans mon cas, il semble être causé par Tunnelblick, même lorsque le VPN n'était pas connecté. Je l'ai désinstallé (avec le programme de désinstallation, pas simplement glisser à la corbeille) et le problème est parti.
la source