Temat: TP-Link WDR-4300 v1 - Znikające połączenie
Witam,
Nie dawno się rozwiązał jeden problem z tym router i mamy kolejny, a 3 miesiące był spokój.
Na routerze nie ma połączenia z Internetem, tzn jest, ale mam dużo packet lostów (70-90%)
OpenWrt 19.07-SNAPSHOT r11225-14903d9d8c / LuCI openwrt-19.07 branch git-20.287.57033-3d52019
WAN: DHCPv4 192.168.1.1
BR-LAN: 192.168.100.3
Klient OpenVPN - TAPkiedy z poziomu putty puszcze ping na serwer googla lub obojętnie jakikolwiek. To wynik wygląda tak:
PING google.com (172.217.16.142): 56 data bytes
64 bytes from 172.217.16.142: seq=3 ttl=112 time=20.242 ms
64 bytes from 172.217.16.142: seq=4 ttl=112 time=20.941 ms
64 bytes from 172.217.16.142: seq=5 ttl=112 time=20.792 ms
64 bytes from 172.217.16.142: seq=6 ttl=112 time=20.580 ms
tutaj mamy pusto
64 bytes from 172.217.16.142: seq=48 ttl=112 time=150.027 ms
64 bytes from 172.217.16.142: seq=49 ttl=112 time=20.801 ms
64 bytes from 172.217.16.142: seq=50 ttl=112 time=20.598 ms
64 bytes from 172.217.16.142: seq=51 ttl=112 time=20.467 ms
64 bytes from 172.217.16.142: seq=52 ttl=112 time=20.278 ms
64 bytes from 172.217.16.142: seq=53 ttl=112 time=21.022 ms
64 bytes from 172.217.16.142: seq=54 ttl=112 time=21.131 ms
64 bytes from 172.217.16.142: seq=55 ttl=112 time=20.582 ms
64 bytes from 172.217.16.142: seq=56 ttl=112 time=20.349 ms
64 bytes from 172.217.16.142: seq=93 ttl=112 time=894.364 ms
64 bytes from 172.217.16.142: seq=94 ttl=112 time=20.920 ms
64 bytes from 172.217.16.142: seq=95 ttl=112 time=20.715 ms
64 bytes from 172.217.16.142: seq=96 ttl=112 time=20.461 ms
znowu pusto...
64 bytes from 172.217.16.142: seq=771 ttl=112 time=20.862 ms
64 bytes from 172.217.16.142: seq=772 ttl=112 time=20.731 ms
64 bytes from 172.217.16.142: seq=773 ttl=112 time=20.413 ms
64 bytes from 172.217.16.142: seq=774 ttl=112 time=20.633 ms
64 bytes from 172.217.16.142: seq=787 ttl=112 time=2732.725 ms
64 bytes from 172.217.16.142: seq=788 ttl=112 time=1732.674 ms
64 bytes from 172.217.16.142: seq=789 ttl=112 time=732.535 ms
64 bytes from 172.217.16.142: seq=790 ttl=112 time=20.576 ms
64 bytes from 172.217.16.142: seq=791 ttl=112 time=20.385 ms
64 bytes from 172.217.16.142: seq=792 ttl=112 time=21.066 ms
i podsumowowanie...
--- google.com ping statistics ---
1000 packets transmitted, 295 packets received, 70% packet loss
round-trip min/avg/max = 20.125/171.511/2932.705 msJak wiadomo wiąże się to z tym, że brak możliwości dogrywania pakietów czy aktualizacji. Skrypty które działają w oparciu o ping itp. wywalają błędy.
Teraz ciekawostka. Po stronie LAN brak takich objawów. Klienci sieci mogą oglądać VOD, grać online etc.
Kolejna ciekawostka...
Po puszczeniu pingu z innej maszyny w sieci VPN ( z innej lokalizacji po tap0) w tym przypadku serwer VPN 192.168.100.1
podsumowanie wygląda tak:
--- 192.168.100.3 ping statistics ---
1000 packets transmitted, 1000 received, 0% packet loss,
rtt min/avg/max/mdev = 51.881/165.430/719.980/89.569 mscat /etc/config/network
config interface 'loopback'
<------>option ifname 'lo'
<------>option proto 'static'
<------>option ipaddr '127.0.0.1'
<------>option netmask '255.0.0.0'
config globals 'globals'
<------>option ula_prefix 'fdb6:a390:87b1::/48'
config interface 'lan'
<------>option type 'bridge'
<------>option proto 'static'
<------>option netmask '255.255.255.0'
<------>option ip6assign '60'
<------>option ipaddr '192.168.100.3'
<------>option ifname 'eth0.1 tap0'
<------>option gateway '192.168.1.1'
<------>list dns '8.8.8.8'
<------>list dns '8.8.4.4'
<------>list dns '192.168.100.1'
config interface 'wan'
<------>option proto 'dhcp'
<------>option ifname 'eth0.2'
config device 'wan_eth0_2_dev'
<------>option name 'eth0.2'
<------>option macaddr '10:fe:ed:e6:31:c3'
config interface 'wan6'
<------>option ifname 'eth0.2'
<------>option proto 'dhcpv6'
<------>option reqaddress 'try'
<------>option reqprefix 'auto'
config switch
<------>option name 'switch0'
<------>option reset '1'
<------>option enable_vlan '1'
config switch_vlan
<------>option device 'switch0'
<------>option vlan '1'
<------>option ports '2 3 4 5 0t'
config switch_vlan
<------>option device 'switch0'
<------>option vlan '2'
<------>option ports '1 0t'Problem się zaczął pojawiać w momencie kilkukrotnego wyłączenia prądu przez operatora. W tym czasie stwierdziłem, że zmienie miejsce położenia modemu od INEA + ONT oraz TP-Linka.
przewody Cat5e raczej nie powinny robić problemu, bo wszystko co po stronie LAN za NAT nie ma problemu ze stabilnością. No może są lekkie czkawki.. skoki do 100ms ale nie takie ilości gubionych pakietów po WAN i tylko z routera.