Okresowe utraty pakietów w sieci domowej — jak je znaleźć i naprawić

Zanim zaczniesz

Natychmiast wykonaj kontrolowany test ping z komputera Linux i zapisz wyniki — to najprostszy dowód na okresową utratę pakietów. Jeśli chcesz od razu przejść do działania, otwórz terminal i wykonaj krok 1 opisany poniżej.

Jak krok po kroku zlokalizować utratę pakietów

1. Podstawowy test ping (potwierdzenie i skala problemu)
   • Uruchom dłuższy test do bramy domowej i do hosta zewnętrznego (np. 8.8.8.8). Zapisz wyniki.
   • Komendy:

     ping -c 200 192.168.1.1
     ping -c 200 8.8.8.8

   • Co czytać: procent strat (% packet loss), średni czas (rtt), odchylenie. Utrata do bramy wskazuje problem lokalny (kabel, AP, switch). Utrata tylko do 8.8.8.8 wskazuje na sieć ISP lub modem.
2. MTR — jednoczesne traceroute i ping (lokalizacja miejsca strat)
   • Uruchom mtr z uprawnieniami root, pozwoli wykryć, na którym hopie pojawiają się straty i czy są okresowe.
   • Komenda:

     sudo mtr --report --report-cycles 300 8.8.8.8

   • Interpretacja: jeśli straty zaczynają się na pierwszym hopie (twoja brama), problem jest lokalny. Jeśli pojawiają się na hopach poza twoją siecią, zanotuj IP/AS i czas występowania — to przydatne przy kontakcie z ISP.
3. Traceroute TCP/UDP — omijanie ograniczeń ICMP
   • Niektóre routery/ISP ignorują ICMP. Użyj traceroute z TCP (port 80/443) lub narzędzia tcptraceroute.
   • Przykład:

     sudo traceroute -T -p 443 8.8.8.8
     sudo apt install tcptraceroute && sudo tcptraceroute 8.8.8.8 443

   • Porównaj ścieżki ICMP i TCP: różnice mogą ujawnić filtrowanie lub rate‑limit na ICMP.
4. Tcpdump — zbieranie pakietów podczas incydentu (głębsza analiza)
   • Zapis ruchu na interfejsie, aby zobaczyć retransmisje TCP, ICMP timeouts, ARP flaps.
   • Przykład zapisu 60s ruchu do pliku pcap:

     sudo tcpdump -i eth0 -w /tmp/capture.pcap -G 60 -W 1

   • Analiza: otwórz plik w Wireshark lub użyj tshark do statystyk:

     tshark -r /tmp/capture.pcap -q -z io,stat,0,COUNT

   • Szukaj: duża liczba retransmisji TCP, pakiety RST, ICMP unreachable, ARP probes. To wskaże typ problemu (warstwy 2, 3 lub wyższe).

Sprawdzenia sprzętowe i fizyczne (wyeliminuj najczęstsze przyczyny)

1. Okablowanie i konektory
   • Wymień kabel Ethernet na znany dobry patch cord (najlepiej krótkie CAT6). Testuj po kolei: komputer → kabel → switch → modem.
   • Sprawdź widoczne uszkodzenia, gięcia, zabrudzenia. Zwróć uwagę na luźne złącza RJ45 i oksydację.
   • Jeśli używasz kabla dłuższego niż 20–30 m lub instalacji z ekranowaniem, sprawdź zakończenia i ciągłość przy użyciu testera kabli lub multimetru; przynajmniej wymień na krótszy do testów.
2. Porty, przełączniki i zasilanie
   • Przełącz porty: podłącz kabel do innego portu switcha i sprawdź czy problem znika.
   • Wyłącz i włącz zasilanie switcha/modemu. Sprawdź temperaturę urządzeń (przegrzanie powoduje okresowe błędy). Jeśli urządzenie ma diody diagnostyczne, porównaj ich stan z dokumentacją.
   • Jeśli masz zapasowy switch lub router, podmień go na krótki test.
3. Wi‑Fi: zakłócenia i przeciążenie kanału
   • Jeśli problem dotyczy Wi‑Fi, użyj narzędzia do skanowania kanałów (np. wavemon, iwlist) i przełącz kanał na mniej zatłoczony.

     sudo iwlist wlan0 scan | egrep "Channel|ESSID"

   • Wyłącz tryb automatycznego wyboru kanału na routerze i wybierz kanał ręcznie (zwłaszcza na 2.4 GHz). Przetestuj 5 GHz, jeśli urządzenia go obsługują.
   • Upewnij się, że AP nie działa w trybie mieszanym (b/g/n) jeśli masz tylko n/ac — wymuszenie n/AC może poprawić stabilność.

Testy długoterminowe i partycjonowanie ruchu

Celem jest udowodnienie okresowości i korelacji z ruchem lub sprzętem.

1. Harmonogram testów
   • Uruchom długotrwałe mtr/ping na kilka godzin w godzinach, gdy występuje problem (np. 8–12 godzin). Zapisz pliki wyników.
   • Przykład skryptu prostego testu ping co 1 sekundę przez 8 godzin:

     ping -i 1 -c 28800 8.8.8.8 > /var/log/ping-8.8.8.8.log

2. Sekcjonowanie sieci (izolacja źródła ruchu)
   • Odłącz wszystkie urządzenia poza testowym komputerem. Jeśli problem znika, podejrzany jest inny endpoint powodujący bursty traffic lub konflikt IP.
   • Podłącz kolejno urządzenia (smart TV, telefony, IoT) i obserwuj gdy pojawi się ponownie — to wskaże winowajcę.
3. Test z bezpośrednim połączeniem do modemu ISP
   • Jeśli masz modem i router osobno: podłącz testowy komputer bezpośrednio do modemu ISP (omijając router/switch). Powtórz ping/mtr. Jeżeli straty pojawiają się nadal, prawdopodobnie problem po stronie ISP lub modemu.
   • Uwaga: podczas podłączania bezpośrednio do modemu możesz stracić dostęp do lokalnych usług; upewnij się, że masz potrzebne dane do przywrócenia konfiguracji.

Jak sprawdzić, czy zadziałało

Po każdej zmianie powtórz skrócony test: 5‑minutowy ping i 5‑minutowe mtr. Porównaj logi przed i po. O sukcesie świadczy spadek packet loss do 0–0.5% i stabilne RTT bez skoków (>100 ms nagle) w okresie testowym.

Kiedy przerwać i skontaktować się ze wsparciem

• Jeżeli po podłączeniu bezpośrednio do modemu nadal występują straty — dokumentuj wyniki (mtr, tcpdump, timestampy) i otwórz zgłoszenie u ISP z załączonymi plikami.
• Jeżeli mtr wskazuje na niestabilność na granicy twojego AS (adresy routerów ISP) — zapisz hopy, ASN i czasy incydentów. To przyspiesza eskalację do działu sieciowego ISP.
• Jeżeli sprzęt sieciowy (modem/router/switch) wykazuje błędy sprzętowe, diody sygnalizują awarie lub urządzenie resetuje się — przygotuj model, numer seryjny i logi systemowe przed kontaktem z producentem lub dostawcą usługi.

Praktyczne blokery i uwagi końcowe

• Upewnij się, że testujesz z uprawnieniami root tam, gdzie to wymagane (mtr, tcpdump). Brak uprawnień zmienia zachowanie narzędzi.
• ICMP może być rate‑limitowane przez routery lub ISP — nigdy nie polegaj wyłącznie na ping; potwierdź TCP/UDP traceroute i tcpdump.
• Jeśli używasz VPN, wyłącz go podczas testów — tunel zmienia trasę i maskuje lokalne problemy.
• Dokumentuj dokładne czasy wystąpienia strat (czas systemowy + strefa) — to kluczowe dane dla ISP.