Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: darebacik 22. 12. 2023, 09:53:58
-
Od ISP (najvacsi na slovensku) mame GPON. Dostali sme od nich tento modem Sagemcom 5670. Zo zaciatku to blblo a internet vypadaval (vysoky packet lost). Potom nam niekto poradil nech ideme cez bridge mod s vlastnym zariadenim. Kupil sa TP-Link Archer C6 v3 a asi mesiac to islov pohode. Teraz zacali problemy. Spravil som si z internetu ping test (uptime kuma) na IP adresu a vidim, ze je tam obrovska strata paketov (cca 40%).
ISP tvrdi, ze ma vsetko v poriadku.
Ako by som mohol zistit ci je problem v nasom TP-Linku. Je tam FW od vyroby. Vela sa v tp-linku nenastavovalo, akurat PPPoE, Wifi guest, DHCP a vzdialena sprava (port nestandardny).
TP-Link bol kupovany pred mesiacom. Nedokazem potvrdit, ze nie je v poriadku, ale preco by nemal byt v poriadku ?
-
Jelikož to už vypadávalo i před TP-Linkem, tak u něho bych chybu nehledal (osobně bych ale model C6 nebral a šel radši do Archer AX20). Každopádně není problém ten TP-Link vyřadit a vyzkoušet přímo v PC nebo si někde půjčit jiný router.
-
Problem je vsak v tom, ze ja tam nie som osobne a ono to vacsinou funguje. Napr. dnes to ide bez problemov (vcera to cely den neslo). Ludia co tam su, tak to vedia len vypnut a zapnut (myslim napajanie).
Problem sa vacsinou musi riesit, ked to nefunguje, ale teraz je to OK (zabudol som napisat, ze problem nie je trvaly, ale obcas vidim vysoky packet lost).
Mozno by bolo vhodnejsie z bridgu prejst znova na route a nechat tieto problemy riesit ISP.
-
Pokud je k dispozici nějaký záložní router, zkusit tam dát ten a sledovat, jestli se situace zlepší. Ale pokud to blblo už před tím, tipoval bych to na modem nebo ještě někde za ním u ISP.
-
To je tak zralé... posadit si tam počítač s LTE konektivitou a TeamViewerem (nebo nějakou VPN), abyste se dostal na management krabiček v LAN ve chvíli, kdy má PON 40% ztrátovost. Pochybuji, že je to lokálními krabičkami - snad leda Wifi bych podezíral. Naučit koncové uživatele, aby pokud je problém, zkusili se píchnout do routeru kabelem.
Při pingu zvenčí na venkovní adresu ("whatismyip.com"?) je otázkou, kdo Vám na ten ping odpovídá: zda CPE router, nebo spíš CGNAT gateway operátora. Jinak odpověď na ping není garantovaná a je to první věc, na kterou se CPU síťového prvku vykašle, když má vysokou zátěž. V dávných dobách na to tradičně kašlaly páteřní boxy u ISP. Přitom ztrátovost pro reálný provoz mohla být nulová.
Hmm. Dát do vnitřní sítě box, který bude pingat lokální router a první hop na straně operátora (access router). Se záznamem na hdd. Po nějaké době (den, týden?) záznam zpracovat do grafu a kontaktovat operátora. Ještě tak kdybyste dokázal stáhnout nějaké countery ze svého routeru, třeba přes SNMP (zátěž CPU, počítadla paketů). Otázkou je, zda to Váš router umí - našel jsem tutorial (https://techexpert.tips/tp-link/tp-link-archer-c20-ac750-enable-snmp/) pro jakéhosi příbuzného.
-
Od ISP (najvacsi na slovensku) mame GPON. Dostali sme od nich tento modem Sagemcom 5670. Zo zaciatku to blblo a internet vypadaval (vysoky packet lost). Potom nam niekto poradil nech ideme cez bridge mod s vlastnym zariadenim. Kupil sa TP-Link Archer C6 v3 a asi mesiac to islov pohode. Teraz zacali problemy. Spravil som si z internetu ping test (uptime kuma) na IP adresu a vidim, ze je tam obrovska strata paketov (cca 40%).
ISP tvrdi, ze ma vsetko v poriadku.
Ako by som mohol zistit ci je problem v nasom TP-Linku. Je tam FW od vyroby. Vela sa v tp-linku nenastavovalo, akurat PPPoE, Wifi guest, DHCP a vzdialena sprava (port nestandardny).
TP-Link bol kupovany pred mesiacom. Nedokazem potvrdit, ze nie je v poriadku, ale preco by nemal byt v poriadku ?
To zarizeni na kterem mate (vysoky packet lost) je pripojene do Vasi domaci site pomoci WiFi a nebo kabelu? ;)
A nebo ten (vysoky packet lost) je primo ze zarizeni TP-Link Archer C6 v3 ktere je pripojene k Sagemcom 5670 pomoci eth kabelu?
-
Na GPone môže byť vysoký útlm, vysoká osrazivosť v konektore, alebo v ktoromkoľvek splitri potrase.
S tým ty nič neurobíš, ak nemáš doma OTDR s ktorým môžeš merať zaživa....
Ináč C6 mali nedávno aktívne zneužívanú zraniteľnosť.
Treba upgradovať.
-
Velmi dakujem za konstruktivne reakcie.
Vec sa ma takto:
Sagemcom je zariadenie od ISP a je v bridge mode. Bridge oni nastavuju na porte LAN1. Odtial je LAN patch kabel smerujuci na Archer C6 do portu WAN. V Archeri vytacam PPPoE cize tam aj dostaneme pevnu verejnu IPv4 adresu.
Ja pingam tuto IP adresu z vonka. Je to sice v ramci toho iste ISP, ale cez 5 okresov a 100 km (myslim, ze BRAS mame stejny).
Ja musim vylucit, ze nas Archer je vadny, pretoze ISP bude vzdy tvrdit, ze oni maju vsetko v poriadku. Vcera ked to blblo, tak som spravil 2 hodinovy ping a vysledkom bolo
--- xx.xx.136.202 ping statistics ---
7200 packets transmitted, 4328 received, 39.8889% packet loss, time 7273858ms
rtt min/avg/max/mdev = 16.860/18.955/56.790/3.871 ms
Najschodnejsie riesenie je kupit dalsi router a skusit to tam, je to sice investicia navyse a mozno zbytocna. Prip. este by som mohol skusit dat na Archer C6 openwrt (dokonca by mediatek v routery mal vediet aj hw nat) a skusit to tam.
-
Tak napr. dnes to znava zacalo robit (vid prilozeny obrazok z uptime kuma). Ja som vzdialene rebootol Archer C6 pred 12:00 (to je ta cervena ciara).
Tie zlte stlpceky predstavuju packet lost cca 40%
Z toho sa moze zdat, ze problemom moze byt skutocne ten archer (kedze po reboote OK).
-
Taková kacířská myšlenka - nemůže být nakopnut etherent port (až už v Sagemu nebo TP-Linku). Zkrátka začne blbnout signalizace a padá t třeba 10/100/1000, half/full duplex, .... Se podívej před rebootem do logu, zda se dá k tomu někde dostat. Reboot ti udělá často i reset ethernet iface a po resetu se to na chvíli vzpamatuje...
Pokud je tam v místě někdo s minimem inteligence, tak při dalším ublbnutí instruuj, ať na chvíli vytáhne Ethernet kabel na pár sekund mezi těmi krabičkami, zda to náhodou také nenapraví situaci.
-
Ještě mě napadá, že takhle nějak může vypadat kolize adres. Na infrastruktuře providera by to samozřejmě bylo překvápko.
A pokud "pomůže restart", tak mě ještě napadá, zda by se dal navodit restart PPPoE relace, bez restartu fyzického linku...
-
Taková kacířská myšlenka - nemůže být nakopnut etherent port (až už v Sagemu nebo TP-Linku). Zkrátka začne blbnout signalizace a padá t třeba 10/100/1000, half/full duplex, .... Se podívej před rebootem do logu, zda se dá k tomu někde dostat. Reboot ti udělá často i reset ethernet iface a po resetu se to na chvíli vzpamatuje...
Pokud je tam v místě někdo s minimem inteligence, tak při dalším ublbnutí instruuj, ať na chvíli vytáhne Ethernet kabel na pár sekund mezi těmi krabičkami, zda to náhodou také nenapraví situaci.
Archer C6 ma syslog a log je mozne ulozit. Avsak ked ho ulozim, tak tam toho je prapodivne malo, takze ho sem mozem kopnut. A aj tie datumi su nejake divne (z dnes a potom z pred vyse mesiaca kusok).
####################################################################
# Archer C6 System Log
# Time = 2023-12-23 22:44:04
# H-Ver = 3.20 ; S-Ver = 1.0.14 Build 20211118 rel.43110
# LAN: I = 192.168.105.10 ; M = 255.255.255.0 ; MAC = 9C:53:22:B7:3A:EB
# WAN: W = pppoe ; I = xx.xx.136.202 ; M = 255.255.255.255 ; MAC = 9C:53:22:B7:3A:EC
# G = 213.81.232.205 ; D1 = 213.81.170.154 ; D2 = 213.81.153.154
# Clients connected: 10 ; WI-FI : 6
####################################################################
2023-12-23 22:38:30 time-settings[26391]: <6> 279508 Service restart
2023-12-23 22:38:29 time-settings[26336]: <6> 279508 Service restart
2023-12-23 22:38:25 time-settings[26024]: <6> 279508 Service restart
2023-12-23 21:35:43 remote-management[23586]: <6> 282055 remote client ip xx.xx.92.19 log in.
2023-12-23 10:58:41 led-controller[764]: <6> 288051 Start to run WAN1_ON
2023-12-23 10:58:41 led-controller[764]: <6> 288051 Start to run WAN0_OFF
2023-12-23 10:58:41 led-controller[764]: <6> 288051 Start to run LAN_ON
2023-12-23 10:58:41 remote-management[10003]: <6> 282055 remote client ip xx.xx.92.19 log in.
2023-12-23 10:58:12 led-controller[764]: <6> 288051 Start to run WAN1_ON
2023-12-23 10:58:12 led-controller[764]: <6> 288051 Start to run WAN0_OFF
2023-12-23 10:58:12 led-controller[764]: <6> 288051 Start to run LAN_ON
2023-12-23 10:58:07 nat[7772]: <6> 211021 IPSEC ALG enabled
2023-12-23 10:58:07 nat[7772]: <6> 211021 L2TP ALG enabled
2023-12-23 10:58:07 nat[7772]: <6> 211021 PPTP ALG enabled
2023-12-23 10:58:07 nat[7772]: <6> 211021 SIP ALG enabled
2023-12-23 10:58:07 nat[7772]: <6> 211021 RTSP ALG enabled
2023-12-23 10:58:06 nat[7772]: <6> 211021 H323 ALG enabled
2023-12-23 10:58:06 nat[7772]: <6> 211021 TFTP ALG enabled
2023-12-23 10:58:06 nat[7772]: <6> 211021 FTP ALG enabled
2023-12-23 10:58:06 upnp[9302]: <6> 217504 Service start
2023-12-23 10:58:06 upnp[9302]: <6> 217505 Service stop
2023-12-23 10:58:04 nat[7772]: <5> 211054 Virtual server created succeeded[ex-port:5901 ip:192.168.105.1 in-port:5901 protocol:all]
2023-12-23 10:58:04 nat[7772]: <5> 211054 Virtual server created succeeded[ex-port:5432 ip:192.168.105.1 in-port:5432 protocol:all]
2023-12-23 10:58:03 nat[7772]: <5> 211054 Virtual server created succeeded[ex-port:10022 ip:192.168.105.1 in-port:10022 protocol:all]
2023-12-23 10:58:01 remote-management[8189]: <6> 282504 Service start
2023-12-23 10:58:01 remote-management[8189]: <6> 282505 Service stop
2021-11-18 00:01:10 nat[7772]: <6> 211501 Initialization succeeded
2021-11-18 00:01:09 nat[7772]: <6> 211501 Initialization succeeded
2021-11-18 00:01:06 ppp[6758]: <6> 261091 ppp receive IPCP ACK
2021-11-18 00:01:06 ppp[6758]: <6> 261090 ppp send IPCP Req options(addr=xx.xx.136.202;dns1=213.81.170.154;dns2=213.81.153.154;)
2021-11-18 00:01:06 ppp[6758]: <6> 261093 ppp receive IPCP NAK options(addr=xx.xx.136.202;dns1=213.81.170.154;dns2=213.81.153.154;)
2021-11-18 00:01:06 ppp[6758]: <6> 261090 ppp send IPCP Req options(addr=0.0.0.0;dns1=0.0.0.0;dns2=0.0.0.0;)
2021-11-18 00:01:06 ppp[6758]: <6> 261075 ppp receive PAP AuthAck Login ok
2021-11-18 00:01:06 ppp[6758]: <6> 261074 ppp send PAP AuthReq user=(gredajoz28@dslfirma)
2021-11-18 00:01:06 ppp[6758]: <6> 261060 ppp send LCP ACK
2021-11-18 00:01:06 ppp[6758]: <6> 261058 ppp receive LCP Request options(mru=1492;authtype=PPP_PAP;magic=0x2adc8cec;)
2021-11-18 00:01:04 ppp[6758]: <6> 261064 ppp receive LCP ACK
2021-11-18 00:01:04 ppp[6758]: <6> 261061 ppp send LCP Request options(mru=1480;magic=0xb04ddcd2;)
2021-11-18 00:01:04 ppp[6758]: <6> 261025 pppoe receive PADS sess-id(2432)
2021-11-18 00:01:04 ppp[6758]: <6> 261024 pppoe send PADR Host-Uniq(1a66)
2021-11-18 00:01:04 ppp[6758]: <6> 261022 pppoe receive PADO form AC-MAC(20:e0:9c:3e:98:01)
2021-11-18 00:01:04 ppp[6758]: <6> 261023 pppoe receive PADO AC-Name(po-maue-bras-1)
2021-11-18 00:01:04 ppp[6758]: <6> 261021 pppoe send PADI Host-Uniq(1a66)
2021-11-18 00:01:04 ppp[6758]: <6> 261026 pppoe send PADT due to(resending PADI)
2021-11-18 00:01:03 remote-management[7095]: <6> 282504 Service start
2021-11-18 00:01:03 remote-management[7095]: <6> 282505 Service stop
2021-11-18 00:01:01 nat[6712]: <6> 211501 Initialization succeeded
2021-11-18 00:01:00 nat[6712]: <6> 211501 Initialization succeeded
2021-11-18 00:00:59 ppp[6758]: <6> 261021 pppoe send PADI Host-Uniq(1a66)
2021-11-18 00:00:59 ppp[6758]: <6> 261026 pppoe send PADT due to(resending PADI)
2021-11-18 00:00:57 led-controller[764]: <6> 288051 Start to run WAN1_OFF
2021-11-18 00:00:57 led-controller[764]: <6> 288051 Start to run WAN0_ON
2021-11-18 00:00:57 led-controller[764]: <6> 288051 Start to run LAN_ON
2021-11-18 00:00:55 led-controller[764]: <6> 288051 Start to run WAN1_OFF
2021-11-18 00:00:55 led-controller[764]: <6> 288051 Start to run WAN0_OFF
2021-11-18 00:00:55 led-controller[764]: <6> 288051 Start to run LAN_ON
2021-11-18 00:00:55 led-controller[764]: <6> 288051 Start to run STATUS_ON
2021-11-18 00:00:53 qos[6446]: <6> 259504 Service start
2021-11-18 00:00:53 qos[6446]: <6> 259503 Function disabled
2021-11-18 00:00:52 led-controller[764]: <6> 288051 Start to run GENERAL
2021-11-18 00:00:48 traffic-stats[5969]: <6> 269504 Service start
2021-11-18 00:00:45 factory-reset[5719]: <6> 284504 Service start
2021-11-18 00:00:44 parental-control[5572]: <6> 229504 Service start
2021-11-18 00:00:44 parental-control[5572]: <6> 229502 Function enabled
2021-11-18 00:00:43 remote-management[5454]: <6> 282504 Service start
2021-11-18 00:00:43 access-control[5426]: <6> 239504 Service start
2021-11-18 00:00:43 access-control[5426]: <6> 239503 Function disabled
2021-11-18 00:00:41 nat[4617]: <7> 211001 Flush conntrack
2021-11-18 00:00:41 nat[4617]: <6> 211502 Function enabled
2021-11-18 00:00:41 nat[4617]: <5> 211051 Create NAT chain succeeded
2021-11-18 00:00:40 nat[4617]: <6> 211501 Initialization succeeded
2021-11-18 00:00:39 nat[4617]: <6> 211501 Initialization succeeded
2021-11-18 00:00:37 basic-security[4002]: <6> 219504 Service start
2021-11-18 00:00:37 basic-security[4002]: <5> 219606 Flush conntrack table succeeded
2021-11-18 00:00:35 firewall[1439]: <6> 209504 Service start
2021-11-18 00:00:34 imb[3873]: <6> 218507 Daemon connection succeeded
2021-11-18 00:00:34 imb[3873]: <6> 218012 ARP Binding disabled
2021-11-18 00:00:34 imb[3873]: <6> 218506 Config interface initialization succeeded
2021-11-18 00:00:34 imb[3873]: <6> 218501 Initialization succeeded
2021-11-18 00:00:34 upnp[3658]: <6> 217504 Service start
2021-11-18 00:00:33 upnp[3658]: <6> 217505 Service stop
2021-11-18 00:00:32 led-controller[764]: <6> 288051 Start to run WIFI5G_ON
2021-11-18 00:00:32 led-controller[764]: <6> 288051 Start to run WIFI2G_ON
2021-11-18 00:00:21 ppp[1494]: <6> 261021 pppoe send PADI Host-Uniq(5d6)
2021-11-18 00:00:21 ppp[1494]: <6> 261026 pppoe send PADT due to(resending PADI)
2021-11-18 00:00:21 remote-management[1658]: <6> 282504 Service start
2021-11-18 00:00:20 remote-management[1658]: <6> 282505 Service stop
2021-11-18 00:00:11 ppp[1494]: <6> 261021 pppoe send PADI Host-Uniq(5d6)
2021-11-18 00:00:11 ppp[1494]: <6> 261026 pppoe send PADT due to(resending PADI)
2021-11-18 00:00:06 ppp[1494]: <6> 261021 pppoe send PADI Host-Uniq(5d6)
2021-11-18 00:00:06 ppp[1494]: <6> 261026 pppoe send PADT due to(resending PADI)
2021-11-18 00:00:00 led-controller[764]: <6> 288051 Start to run STATUS_SAN
2021-11-18 00:00:00 time-settings[797]: <6> 279504 Service start
1970-01-01 00:00:15 led-controller[764]: <6> 288504 Service start
Ano, myslim, ze ty ludia co tam su, tak by dokazali v pripade problemov reinsert patch kabelu medzi sagemcomom a archerom (avsak, niekto by im musel ukazat, ze ak to vytahuje z portu, tak musi podvihnut ten cuplik na RJ45 konektore) :)
Ale najskor to pojde az po sviatkoch.
Inak zakaznik sa do Sagemcomu v bridge mode nijak nedostane, takze tam nemozem nic.
Ještě mě napadá, že takhle nějak může vypadat kolize adres. Na infrastruktuře providera by to samozřejmě bylo překvápko.
A pokud "pomůže restart", tak mě ještě napadá, zda by se dal navodit restart PPPoE relace, bez restartu fyzického linku...
Restart PPPoE sa navodit da, ale musel by som byt v LAN sieti (pretoze je tam button connect a disconnect (skoda, ze tam nie je reconnect)). Ak by som dal disconnect, tak by som sa odrezal.
A este jedna vec. Vzdy (zrejme po reboote) naskoci cas UTC 0. Ja to vzdy zmenim na UTC +1 a ulozim (vid najnovsie riadky v logu).
-
Pri vypadkoch v logu je teraz vidiet napr. aj toto
2023-12-24 09:53:05 led-controller[764]: <6> 288051 Start to run WAN1_ON
2023-12-24 09:53:05 led-controller[764]: <6> 288051 Start to run WAN0_OFF
2023-12-24 09:53:05 led-controller[764]: <6> 288051 Start to run LAN_ON
2023-12-24 09:52:50 led-controller[764]: <6> 288051 Start to run WAN1_OFF
2023-12-24 09:52:50 led-controller[764]: <6> 288051 Start to run WAN0_ON
2023-12-24 09:52:50 led-controller[764]: <6> 288051 Start to run LAN_ON
2023-12-24 09:37:48 led-controller[764]: <6> 288051 Start to run WAN1_ON
2023-12-24 09:37:48 led-controller[764]: <6> 288051 Start to run WAN0_OFF
2023-12-24 09:37:48 led-controller[764]: <6> 288051 Start to run LAN_ON
2023-12-24 09:37:33 led-controller[764]: <6> 288051 Start to run WAN1_OFF
2023-12-24 09:37:33 led-controller[764]: <6> 288051 Start to run WAN0_ON
2023-12-24 09:37:33 led-controller[764]: <6> 288051 Start to run LAN_ON
2023-12-24 09:23:01 led-controller[764]: <6> 288051 Start to run WAN1_ON
2023-12-24 09:23:01 led-controller[764]: <6> 288051 Start to run WAN0_OFF
2023-12-24 09:23:01 led-controller[764]: <6> 288051 Start to run LAN_ON
2023-12-24 09:22:46 led-controller[764]: <6> 288051 Start to run WAN1_OFF
2023-12-24 09:22:46 led-controller[764]: <6> 288051 Start to run WAN0_ON
2023-12-24 09:22:46 led-controller[764]: <6> 288051 Start to run LAN_ON
2023-12-24 09:19:01 led-controller[764]: <6> 288051 Start to run WAN1_ON
2023-12-24 09:19:01 led-controller[764]: <6> 288051 Start to run WAN0_OFF
2023-12-24 09:19:01 led-controller[764]: <6> 288051 Start to run LAN_ON
2023-12-24 09:18:46 led-controller[764]: <6> 288051 Start to run WAN1_OFF
-
V každém kole je vypsán status LAN (vždy ON), WAN1 a WAN0. Zdá se, že WAN1 a WAN0 se střídají (v ON/OFF).
Co jsou zač WAN1 a WAN0 ? Vy máte dva uplinky?
-
Samozrejme uplink je len jeden, ale netusim, ci je pod nazvom WAN0, alebo WAN1.
Momentalne je v zariadeni FW
1.0.14 Build 20211118 rel.43110(4555)a k dispozicii je
1.0.16 Build 20230828 rel.44667Teoreticky by som mohol spravit uprade, len netusim ci to mozem spravit na dialku, lebo ak sa odrezem, tak je amen :D
-
Uff, log pozpátku, jsem si musel stoupnout na hlavu, až z člověka padá salát....
Ten router nemá šváb na reálný čas, tak začíná po resetu/zapnutí asi vždy v tom 18.11.2021 a až chytne internet a čas z něj, tak poskočí na současnou realitu.
To WAN0/WAN1 a dle procesu led-controller, tak to je cvičení s LEDkama. Rotuer má WAN LEDku dvoubarevnou - oranžová=link je up, ale není internet, zelená=jede internet. Takže to cvičení při výpadlu WAN0 off/WAN1 on a zpět bude značit, že nedošlo asi k výpadku ethernet portu (to by asi bylo WAN0 off+WAN1 off), ale rotuer dospěl k tomu, že nemá internet a přechází mezi zelenou a oranžovou...
Je otázka, jak bere výpadek internetu, zda si to nějak testuje nebo v tomto případě pár PPPoE sešny. Fakt v tom logu není nic víc? V zobrazení exportu logu se dá zvolit type=ALL, level=ALL. Zda ke cvičení s LEDkama není i něco o PPP vrstvě. Nebo neukazuje někde stav spojneí PPPoE, jak je dlouho navázané? Zda ne dojde k restartu PPPoE při tom výpadku...
Dle toho a dle poznámky, že to blbo i když Sagem ukončoval PPPoE u sebe, tak se mi problém jeví od Sagemu dál do sítě ISP.
-
Pri dalsich kratkodobych vypadkoch sa prihlasim a stiahnem cely log
-
Rano cca o 10:00 som urobil remote reboot a celkom OK to fungovalo az do nejakej 18:00 (vid graf). Davam tu cely log (ALL - ALL).
Vobec neviem, kedy sa k zariadeniu dostanem fyzicky, ale budem ho musiet vymenit za ine. Ak bude vypadavat aj nadalej, tak kontaktujem ISP, nech si riesi svoj sagemcom.
-
Dle toho to vypadá, že PPPoE nepadlo, jen nejede net. Což si asi router testuje, že si pingá asi ten svůj cloud management nebo něco takového.
Hele, v logu je IP brány a přidělené DNS servery (to je to G = 213.81.233.163 ; D1 = 213.81.170.154 ; D2 = 213.81.153.154).
Zkus, zda ta brána 213.81.233.163 odpovídá na ping z počítače v té LAN, z Internetu neodpovídá. Podobně testni ty DNS servery, D1 odpovídá z vnějšku, G a D2 ne. Zkusil bych si pustit z LAN něco, co bude pinkat na tu bránu/DNS, zda to při výpadku vypadne také. Pokud by ti ping na adresu brány šel a při výpadku internetu tenhle ping nevypadne, tak je problém někde dál u ISP, než je linka k tobě (ale to by asi blbo i jiným a řvali by).
-
Dik, ale neviem, kedy sa tam dostanem.
Vzdy ak zistim problemy a na dialku rebootnem tp-link, tak ono to zas funguje nejakych 5-10hodin OK.
Modem od ISP co je v mode bridge, tak ten sa nerebootuje vobec (lebo na ten nemam dosah).
Cisto teoreticky, ked po reboote tp-linku to par hodin funguje, tak prisudzujem vadu tp-linku (ale ci sa jedna o HW, alebo SW, tak to uz netusim).
-
Po rebootu TP-linku se resetuje taky fyzický port na terminátoru a PPPoE relace, takže jsou i další věci, které se restartem CPE routeru mohou "vrátit znovu na start".