Ocena wątku:
  • 0 głosów - średnia: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Testowanie łącza speedtest rozłącza internet przy aktywnym VPN
#1
0
Czołem. Przychodzę z problemem z którym nie potrafię sobie poradzić. Więc po kolei.

Internet światłowodowy od lokalnego usługodawcy 600 / 60

W domu łączę się głównie na dwa komputery podpięte pod ruter kablami. Na ogół nie korzystam z Wi Fi. Komputery to:

Mój komputer - Dell E5430 Linux Mint - Vera

Komputer żony - Dell E5430 Linux Mint - Vera

1. Żauważyłem kilka dni temu, że na moim komputerze podczas testowania połączenia na popularnych stronach typu speedtest.net, speedtest.pl, fast.com i innych tego typu stronach występuje problem rozłączania internetu podczas wykonywania testu lub chwilę po wykonaniu testu. Na ogół wywala neta podczas testowania. Kiedy to następuje, to nie ma internetu także na drugim komputerze. Stan diód na ruterze i punkcie dostępowym jest prawidłowy, Nie wskazują na utratę połączenia z usługą. Po kilku minutach internet wraca i można na obu komputerach z niego korzystać.

2. Korzystam z Nord VPN. Opisywany problem występuje wyłącznie podczas aktywnego połączenia z serwerem VPN. Wygląda to tak. Łączę się z VPN, po nawiązaniu połączenia wchodzę na speedtest.net klikam przetestuj prędkość i po kilku chwilach wywala neta. Kiedy to robię bez aktywnego VPNa to test przebiega bez zarzutu. Kiedy to samo zrobię na drugim kompie tj. na kompie żony połącze się z VPN i puszczę test prędkości, to internetu nie wywala.

3. Ustaliłem, że problem dotyczy wyłącznie mojego komputera, raczej strony sprzętowej, ustawień karty sieciowej czy czegoś podobnego. Dysponuje także oddzielnym adapterem USB - Ethernet, nawet kiedy wepnę ten adapter do mojego kompa i puszczę test na aktywnym VPN także neta wywala, kiedy adapter włożę do drugiego kompa - żony wszystko jest ok.

4. Poszedłem krok dalej i uruchomiłem wersję live linuxa minta. Jedynymi zmianami jakie wprowadziłem to instalacja pliku realse 1.0.0 ze strony usługodawcy VPN tak, żeby móc się połączyć i także na wersji live występuje problem, wywala neta podczas testowania łącza.

5. Ustaliłem, że problem dotyczy wyłącznie testów łącza, niezależnie od tego na jakiej stronie testuje łącze. Ustaliłem też, że kiedy połączę się z VPN przez protokół TCP problem znika, ale jak wiadomo spadają prędkości.


Przeczesując internet znalazłem przypadek osoby, u której działo się podobnie. Jednak on miał problem przy windowsie
Poniżej link:

https://forum.pasja-informatyki.pl/37135...rnet-innym

Nie zauważyłem jednak by inne czynności jak pobieranie dużych plików albo wysyłanie dużych plików powodowało problem. Problem też nie występuje na Wi Fi Poprzez Wi Fi mogę testować połączenie na swoim kompie bez obawy rozłączenia neta.

Gdzie leży problem ? Jakieś pomysły ? Może ustawienia karty sieciowej ? Z góry dzięki za pomoc

Dodano po pewnym czasie:
To co jest warte dodania, a czego nie umieściłem w poprzednim poście.

W obu komputerach zostały wymienione kable LAN łączace komputery z ruterem, wymieniony został także kabelek światłowodowy idący od gniazda do punktu dostępowego. Także kabel LAN idący od punktu dostępowego ze światłowodem do rutera. Słowem przewody są ok.

Wykorzystałem fakt, że posiadam dwa identyczne modele laptopów. Właściwie różnią się chyba tylko procesorem, marką dysku, ramem i kartą WLAN. No i dziś robiłem przekładankę

Na pierwszy ogień poszła pamięć RAM. Z komputera żony na którym wszystko działa ok, wyciągnąłem RAM i włozyłem do swojego kompa uprzednio w swoim wyjmując te co miałem, nie dodawałem kości. Puściłem test i okazało się, że problem nadal występuje. Powróciłem do poprzedniej konfiguracji.

Na obu kompach są linuxy mint o czym było powyżej. Wykręciłem dysk twardy z kompa żony i włożyłem w swojego laptopa. Mój natomiast włozyłem w jej laptopa. Okazało się, że na moim kompie z jej dyskiem kiedy puściłem speedtest, problem nadal występuje. Natomiast na jej komputerze z moim dyskiem, problem po puszczeniu testu nie występował. Powróciłem do pierwotnej konfiguracji.

Odczepiłem przewody i wyciągnąłem ze swojego laptopa kartę WLAN. Puśćiłem speed test i problem natal występuje.

Nawet dzisiaj zrobiłem update biosu, a właściwie jego nadpisanie i ciągle to samo.

To jak z archiwum X Smile

Wygląda na to, że problem jest czysto sprzętowy. Może chipset ? Macie jakieś pomysły ?

Dodano po pewnym czasie:
I tak sobie dumałem leżąc na kanapie i wydumuałem.

Mówię, nie przemieniałem jeszcze procesora, no ale co ma procesor do rozłączania sieci przy próbie testowania na speedtest. W końcu stwierdziłem, że moim przypadku ma, ponieważ problem objawiał się przy testowaniu prędkości podczas aktywnego VPNa czyli podczas szyfrowanego połączenia, a jak założyłem w tym szyfrowaniu być może udział bierze właśnie procesor.

Wstałem więc z kanapy i raz jeszcze rozkręciłem laptopy. Wydostałem procesory z obu laptopów i ten procesor, od żony bardzo zbliżony parametrami włożyłem do swojego laptopa, a swój procesor do jej laptopa. Uruchomiłem swój komputer, połączyłem się z VPN i puściłem test. Okazało się, że problem znikł !

Dla potwierdzenia słuszności tezy, uruchomiłem kompa żony z tym moim procesorem i okazało się, że u niej pojawił się problem, wywaliło neta.

Rozwiązaniem okazał się uszkodzony procesor, który tak na ogół nie dawał żadnych oznak uszkodzenia, poza tym co opisałem w wątku. Czeka mnie zakup procka do kompa, ale do 100 zł za używkę dam radę się wyrobić.

Problem rozwiązany, przyczyna znana.
Odpowiedz
#2
0
A to nie jest po prostu wina braku jakichś sterowników. Skoro masz różne procesory, to może zobacz, czy ktoś nie miał podobnego problemu z tym problematycznym - może się okazać, że wymagana jest np. inna wersja kernela lub jakiś inne dodatkowe rzeczy - unikniesz wtedy zbędnego wydatku.
Kernel: 6.2.0-32-generic x86_64 Desktop: Xfce 4.18.1 Distro: Debian GNU/Linux 12 (bookworm)
Odpowiedz
#3
0
(18-04-2023, 23:04)MichałM napisał(a): A to nie jest po prostu wina braku jakichś sterowników. Skoro masz różne procesory, to może zobacz, czy ktoś nie miał podobnego problemu z tym problematycznym - może się okazać, że wymagana jest np. inna wersja kernela lub jakiś inne dodatkowe rzeczy - unikniesz wtedy zbędnego wydatku.

Właściwie to kernele testowałem różne. Sterowników pod problematyczny i7-3520M dla linuxa nie widzę w sieci. Pakiet intel-microcode jest zainstalowany, zrobiłem jego reinstalkę. Bez większych zmian.

Akurat ten procesor miał prawo wyciągnąć kopyta. Przez jakieś może dwa lata mocno go eksploatowałem. Liczyłem jakiś czas temu dla projektów BOINC : Seti@home i tym podobne. Laptop z tym procesorem działał 24/h całymi tygodniami pod 100% obciążeniem. Jedyne co mnie zaskakuje, to do tej pory wychodziłem z założenia, że z procesorami jest tak, że albo są sprawne, albo niesprawne, a ich wadliwe działanie jest widoczne na pierwszy rzut oka i łatwe w zdiagnozowaniu. Tu akurat procek działa, nie wyskakują jakieś artefakty, zwieszenia systemu itp. A mimo to...

Przy prędkościach internetu 300 / 30 jakie miałem do niedawna, przy aktywnym VPN nie powodował problemu, jeszcze wyrabiał. Problem się zrobił parę dni temu, kiedy operator zwiększył prędkość internetu na 600 / 60.

Dodano po pewnym czasie:
No i przyszedł nowo zakupiony procesor I7-3520M. Po wrzuceniu go do laptopa dzieje się tak samo. Wywala neta. Czyli wychodzi na to, że jest to kwestia sterowników ewentualnie niedopracowań jądra lub wina leży po stronie usługodawcy VPN. Nie wiem co jeszcze mogę zrobić by to usprawnić. Odwiedziłem też stronę intela, ale tam żadnych sterowników pod linuxa dla tego procesora nie widzę.
Odpowiedz
#4
0
Nie mogłem znaleźć adresu e-mail do obsługi technicznej Della, więc napisałem posta na ich forum technicznym. Może ktoś wskaże gdzie leży problem.
Odpowiedz
#5
0
A próbowałeś tego nowego procka uruchomić w laptopie żony?
Jaki CPU ma żona?
Odpowiedz
#6
0
Tego nowo zakupionego i7 nie wkładałem do laptopa żony, wylądował od razu u mnie w lapku. Podejrzewam, że tutaj problem by pozostał ten sam. Dziś już nie mam czasu ale w tym tygodniu się może tym zajmę i przerzucę.

Żona obecnie ma ten procek który u mnie początkowo stwarzał problem, a wcześniej był tam i3-3120M o ile mnie pamięć nie myli i on nie powodował problemu, zarówno u niej w lapku jak i u mnie. Obecnie i3 wylądował w szafce a w obu lapkach jest i7 i w obu ten sam problem.
Odpowiedz
#7
0
To pozostaje zdiagnozować co się konkretnie "wywala":
- fizyczny link
- łącze do vpn
- łącze do Internetu
- coś innego

Po wywołaniu problemu przydadzą się wyniki poleceń:
Kod:
ip link
Kod:
ethtool nazwa_karty
Kod:
ping -c 4 8.8.8.8
Odpowiedz
#8
0
(26-04-2023, 17:51)dedito napisał(a): To pozostaje zdiagnozować co się konkretnie "wywala":
- fizyczny link
- łącze do vpn
- łącze do Internetu
- coś innego

Po wywołaniu problemu przydadzą się wyniki poleceń:
Kod:
ip link
Kod:
ethtool nazwa_karty
Kod:
ping -c 4 8.8.8.8


Po wywołaniu powyższych komend dostaję coś takiego

Kod:
michal@michal:~$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp12s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether f0:1f:af:28:30:38 brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 4c:80:93:01:d9:a7 brd ff:ff:ff:ff:ff:ff
4: nordlynx: <POINTOPOINT,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none

michal@michal:~$ ethtool enp12s0
Settings for enp12s0:
    Supported ports: [ TP ]
    Supported link modes:   10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Half 1000baseT/Full
    Supported pause frame use: No
    Supports auto-negotiation: Yes
    Supported FEC modes: Not reported
    Advertised link modes:  10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Half 1000baseT/Full
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Advertised FEC modes: Not reported
    Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                         100baseT/Half 100baseT/Full
                                         1000baseT/Half 1000baseT/Full
    Link partner advertised pause frame use: No
    Link partner advertised auto-negotiation: Yes
    Link partner advertised FEC modes: Not reported
    Speed: 1000Mb/s
    Duplex: Full
    Auto-negotiation: on
    Port: Twisted Pair
    PHYAD: 1
    Transceiver: internal
    MDI-X: off
netlink error: Operation not permitted
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
    Link detected: yes

michal@michal:~$ ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=54.1 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=53.9 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=53.7 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=54.2 ms

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 53.680/53.976/54.152/0.190 ms


Po zaistnieniu problemu

Kod:
michal@michal:~$ ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3071ms
Odpowiedz
#9
0
Potrzebuje wszystkie po zaistnieniu problemu, a widzę tylko wynik pinga.
Przy okazji wrzuć też wynik ip address show
Odpowiedz
#10
0
(27-04-2023, 09:02)dedito napisał(a): Potrzebuje wszystkie po zaistnieniu problemu, a widzę tylko wynik pinga.
Przy okazji wrzuć też wynik ip address show

Nie wiem czy pisząc, że potrzebujesz wszystko potrzebujesz też wyniku dla wszystkich kart ? Z tego co ustaliłem port ethernet w lapku jest na enp12s0 więc komendę ethtool wpisałem z tą nazwą karty.

Po zaistnieniu problemu

Kod:
michal@michal:~$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp12s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether f0:1f:af:28:30:38 brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 4c:80:93:01:d9:a7 brd ff:ff:ff:ff:ff:ff
4: nordlynx: <POINTOPOINT,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none
michal@michal:~$ ethtool enp12s0
Settings for enp12s0:
    Supported ports: [ TP ]
    Supported link modes:   10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Half 1000baseT/Full
    Supported pause frame use: No
    Supports auto-negotiation: Yes
    Supported FEC modes: Not reported
    Advertised link modes:  10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Half 1000baseT/Full
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Advertised FEC modes: Not reported
    Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                         100baseT/Half 100baseT/Full
                                         1000baseT/Half 1000baseT/Full
    Link partner advertised pause frame use: No
    Link partner advertised auto-negotiation: Yes
    Link partner advertised FEC modes: Not reported
    Speed: 1000Mb/s
    Duplex: Full
    Auto-negotiation: on
    Port: Twisted Pair
    PHYAD: 1
    Transceiver: internal
    MDI-X: off
netlink error: Operation not permitted
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
    Link detected: yes
michal@michal:~$ ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3056ms

michal@michal:~$ ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp12s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether f0:1f:af:28:30:38 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.137/24 brd 192.168.1.255 scope global dynamic noprefixroute enp12s0
       valid_lft 32922sec preferred_lft 32922sec
3: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 4c:80:93:01:d9:a7 brd ff:ff:ff:ff:ff:ff
4: nordlynx: <POINTOPOINT,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.5.0.2/32 scope global nordlynx
       valid_lft forever preferred_lft forever


Tak przy okazji na forum Dell’a otrzymałem taką oto informację od jednego z użytkowników:

"That makes it even more likely there's a conflict between the inevitable lag in the network when using the VPN and the test software.  This has absolutely nothing to do with firmware, which doesn't have any role in what you're seeing.

It may be there's a fault in the loop in the test software that's showing up with the faster CPU."

Dodano po pewnym czasie:
Ja bym jeszcze rozpatrzał, czy czasem ruter podczas wykonywania testu nie jest zalewany nadmierną ilością połączeń i czy w takim przypadku nie załącza się jakaś automatyczna blokada odseparowująca wszystkie podłączone urządzenia ? Przy okazji swojego pierwszego postu wrzuciłem link do przypadku osoby u której działo się podobnie

Dodano po pewnym czasie:
(27-04-2023, 11:37)kruger84 napisał(a):
(27-04-2023, 09:02)dedito napisał(a): Potrzebuje wszystkie po zaistnieniu problemu, a widzę tylko wynik pinga.
Przy okazji wrzuć też wynik ip address show

Nie wiem czy pisząc, że potrzebujesz wszystko potrzebujesz też wyniku dla wszystkich kart ? Z tego co ustaliłem port ethernet w lapku jest na enp12s0 więc komendę ethtool wpisałem z tą nazwą karty.

Po zaistnieniu problemu

Kod:
michal@michal:~$ ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp12s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether f0:1f:af:28:30:38 brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 4c:80:93:01:d9:a7 brd ff:ff:ff:ff:ff:ff
4: nordlynx: <POINTOPOINT,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/none
michal@michal:~$ ethtool enp12s0
Settings for enp12s0:
    Supported ports: [ TP ]
    Supported link modes:   10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Half 1000baseT/Full
    Supported pause frame use: No
    Supports auto-negotiation: Yes
    Supported FEC modes: Not reported
    Advertised link modes:  10baseT/Half 10baseT/Full
                            100baseT/Half 100baseT/Full
                            1000baseT/Half 1000baseT/Full
    Advertised pause frame use: No
    Advertised auto-negotiation: Yes
    Advertised FEC modes: Not reported
    Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                         100baseT/Half 100baseT/Full
                                         1000baseT/Half 1000baseT/Full
    Link partner advertised pause frame use: No
    Link partner advertised auto-negotiation: Yes
    Link partner advertised FEC modes: Not reported
    Speed: 1000Mb/s
    Duplex: Full
    Auto-negotiation: on
    Port: Twisted Pair
    PHYAD: 1
    Transceiver: internal
    MDI-X: off
netlink error: Operation not permitted
        Current message level: 0x000000ff (255)
                               drv probe link timer ifdown ifup rx_err tx_err
    Link detected: yes
michal@michal:~$ ping -c 4 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3056ms

michal@michal:~$ ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp12s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether f0:1f:af:28:30:38 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.137/24 brd 192.168.1.255 scope global dynamic noprefixroute enp12s0
       valid_lft 32922sec preferred_lft 32922sec
3: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 4c:80:93:01:d9:a7 brd ff:ff:ff:ff:ff:ff
4: nordlynx: <POINTOPOINT,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.5.0.2/32 scope global nordlynx
       valid_lft forever preferred_lft forever


Tak przy okazji na forum Dell’a otrzymałem taką oto informację od jednego z użytkowników:

"That makes it even more likely there's a conflict between the inevitable lag in the network when using the VPN and the test software.  This has absolutely nothing to do with firmware, which doesn't have any role in what you're seeing.

It may be there's a fault in the loop in the test software that's showing up with the faster CPU."

Dodano po pewnym czasie:
Ja bym jeszcze rozpatrzał, czy czasem ruter podczas wykonywania testu nie jest zalewany nadmierną ilością połączeń i czy w takim przypadku nie załącza się jakaś automatyczna blokada odseparowująca wszystkie podłączone urządzenia ? Przy okazji swojego pierwszego postu wrzuciłem link do przypadku osoby u której działo się podobnie


Zobrazuję jeszcze jedno. Po wykonaniu komendy
Kod:
mtr google.com

Widać, że gubione są pakiety po stronie usługodawcy internetu VPN. Załączam screen

[Obrazek: 15f0925794252297.png]

Dodano po pewnym czasie:
Odpowiedz


Skocz do:




Użytkownicy przeglądający ten wątek: 3 gości