Ahoj,
mám problém při stahování větších objemů dat naráz. Projevuje se u mě následovně:
- stahuji velký soubor (stovky MB, např. instalační image Ubuntu) - stahování jede plnou rychlostí, co umožňuje poskytovatel internetu, po stažení cca 100 až 200MB (liší se, pokaždé jinak) naráz rychlost stahování spadne na 0 a už se nerozeběhne. Když stahování začnu znovu, tak zase běží plnou rychlostí, ale problém se opakuje.
- Sleduji videa - v nějakém momentu (vyskytuje se nepravidelně) se sekne a trvá jednotky až desítky sekund, než se znovu rozjede. Někdy se nerozjede, pak je nutné obnovit stránku, poté video znovu v pohodě jede.
Co by mohlo být důležité:
- Turris 1.1
- WAN - PPPoE (s předešlým poskytovatelem byla běžné připojení bez PPPoE a problém nebyl, nebo jsem si ho nevšiml)
- problém je v Turrisu - při připojení počítače přímo k poskytovateli problém není
- připadá mi to jako nějaký typ kvóty, timeoutu nebo pravidla firewallu, ale netuším, kam se podívat. Neuvědomuji si, že bych něco takového nastavoval, Turris jsem nechával ve výchozím nastavení.
Předem díky za tipy
Zdravím,
dost by pomohl “Systémový log” a nejlépe okolo času výpadku, možná tam bude něco zaznamenané.
2 Likes
Tuším, že problém nebude ve velkém souboru, ale v nějaké pravidelné činnosti na pozadí.
Zkus se v logu zaměřit na přesný čas přerušní spojení a jiné akce v daném čase a na časovou pravidelnost výpadků.
Navrhuji zkusit stahovat “dlouhé” soubory (ideálně ten samý) na několika klientech současně a zjisit, zda-li se spojení přetrhne na všech nebo jen na jednom, na wifi nebo jen na drátě atd.
Nechci tu uvádět nepravdy, ale pokud si dobře pamatuji, tak mě spojení pravidelně trhal ucollect - a to i na vnitřní síti. Např TV pravidelně po čase hlásila, že nemá spojení. Aby si ověřila, že je na internetu, posílala několik DNS dotazů ve vteřině na .root-servers.net a při timeoutu (ucollect zrovna zpracovával/odesílal) hlásila chybu.
Zkus tedy také zastavit všechny služby, které jsou “navíc” a zjisit, jestli problém přetrvává.
Díky za tipy, níže přikládám výtažek ze syslogu. Abych to shrnul:
- může za to pppd, které spadne s hláškou CCP terminated by peer (Encryption got out of sync)
- žádnou zjevnou příčinu tohoto stavu nevidím - sekundy, i desítky sekund předtím se v syslogu nic neděje (ještě před započetím stahování velkého souboru)
Co na to znalci přes pppd?
příklad: čas přerušení downloadu: 23:51:33
2019-04-07 23:51:24 notice unbound[]: [6088:0] notice: sendto failed: Permission denied
2019-04-07 23:51:24 notice unbound[]: [6088:0] notice: remote address is 2600:9000:5304:a000::1 port 53
2019-04-07 23:51:33 info pppd[17125]: CCP terminated by peer (Encryption got out of sync)
2019-04-07 23:51:33 err pppd[17125]: MPPE disabled
2019-04-07 23:51:33 info pppd[17125]: Connect time 4.7 minutes.
2019-04-07 23:51:33 info pppd[17125]: Sent 3288200 bytes, received 83391337 bytes.
2019-04-07 23:51:33 notice netifd[]: Network device ‘pppoe-wan’ link is down
2019-04-07 23:51:33 notice netifd[]: Network alias ‘pppoe-wan’ link is down
2019-04-07 23:51:33 notice netifd[]: Interface ‘wan6’ has link connectivity loss
2019-04-07 23:51:33 notice netifd[]: Interface ‘wan_6’ has link connectivity loss
2019-04-07 23:51:33 err ucollect[19011]: Error reading packets from PCAP on pppoe-wan (The interface went down)
2019-04-07 23:51:33 err ucollect[774]: Last message ‘Error reading packet’ repeated 1 times, suppressed by syslog-ng on turris
2019-04-07 23:51:33 warning ucollect[19011]: epoll_wait on 4 interrupted, retry
2019-04-07 23:51:33 info ucollect[19011]: Reconfiguring
2019-04-07 23:51:33 info ucollect[19011]: Loading plugin library libpluglib_ucollect_diffstore_1.2.so
2019-04-07 23:51:33 info ucollect[774]: Last message ‘Loading plugin libra’ repeated 1 times, suppressed by syslog-ng on turris
2019-04-07 23:51:33 info ucollect[19011]: Sending login credentials disabled
2019-04-07 23:51:33 info ucollect[774]: Last message ‘Sending login creden’ repeated 5 times, suppressed by syslog-ng on turris
2019-04-07 23:51:33 info ucollect[19011]: Unloading plugin library
2019-04-07 23:51:33 info ucollect[774]: Last message ‘Unloading plugin lib’ repeated 1 times, suppressed by syslog-ng on turris
2019-04-07 23:51:33 err odhcp6c[17183]: Failed to send RS (Permission denied)
2019-04-07 23:51:33 err odhcp6c[17172]: Failed to send RS (Permission denied)
2019-04-07 23:51:33 notice pppd[17125]: Compression disabled by peer.
2019-04-07 23:51:33 notice pppd[17125]: Connection terminated.
2019-04-07 23:51:33 notice netifd[]: Interface ‘wan6’ is disabled
2019-04-07 23:51:33 notice netifd[]: Interface ‘wan_6’ is disabled
2019-04-07 23:51:33 info pppd[17125]: Sent PADT
2019-04-07 23:51:33 notice netifd[]: Interface ‘wan’ has lost the connection
2019-04-07 23:51:33 info pppd[17125]: Exit.
2019-04-07 23:51:33 notice netifd[]: Interface ‘wan’ is now down
2019-04-07 23:51:33 notice netifd[]: Interface ‘wan’ is disabled
2019-04-07 23:51:33 notice netifd[]: Interface ‘wan’ is enabled
2019-04-07 23:51:33 notice netifd[]: Interface ‘wan’ is setting up now
2019-04-07 23:51:33 notice root[]: stopping ntpclient
2019-04-07 23:51:33 err odhcp6c[17172]: Failed to send DHCPV6 message to ff02::1:2 (Permission denied)
2019-04-07 23:51:34 err odhcp6c[17183]: Failed to send DHCPV6 message to ff02::1:2 (Permission denied)
2019-04-07 23:51:35 notice netifd[]: Network device ‘eth2’ link is down
2019-04-07 23:51:35 notice netifd[]: Interface ‘wan’ has link connectivity loss
2019-04-07 23:51:36 info kernel[]: [4865986.798551] fsl-gianfar ffe26000.ethernet eth2: Link is Up - 100Mbps/Full - flow control rx/tx
2019-04-07 23:51:36 notice netifd[]: Network device ‘eth2’ link is up
2019-04-07 23:51:36 notice netifd[]: Interface ‘wan’ has link connectivity
2019-04-07 23:51:36 notice netifd[]: Interface ‘wan’ is setting up now
…
… asi milion zpráv uboundu[]
…
2019-04-07 23:51:46 info pppd[19869]: Plugin rp-pppoe.so loaded.
2019-04-07 23:51:46 info pppd[19869]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7
2019-04-07 23:51:46 notice pppd[19869]: pppd 2.4.7 started by root, uid 0
2019-04-07 23:51:46 err pppd[19869]: Interface eth2 has MTU of 1492 – should be at least 1500.
2019-04-07 23:51:46 err pppd[19869]: This may cause serious connection problems.
2019-04-07 23:51:46 info pppd[19869]: PPP session is 1372
2019-04-07 23:51:46 warning pppd[19869]: Connected to 4c:5e:0c:6b:7c:b3 via interface eth2
2019-04-07 23:51:46 info kernel[]: [4865996.863451] pppoe-wan: renamed from ppp0
2019-04-07 23:51:46 info pppd[19869]: Using interface pppoe-wan
2019-04-07 23:51:46 notice pppd[19869]: Connect: pppoe-wan <–> eth2
2019-04-07 23:51:46 notice pppd[19869]: CHAP authentication succeeded
2019-04-07 23:51:46 notice pppd[19869]: peer from calling number 4C:5E:0C:6B:7C:B3 authorized
2019-04-07 23:51:46 notice pppd[19869]: local IP address 178.17.13.81
2019-04-07 23:51:46 notice pppd[19869]: remote IP address 10.10.0.1
2019-04-07 23:51:46 notice pppd[19869]: primary DNS address 178.17.0.11
2019-04-07 23:51:46 notice pppd[19869]: secondary DNS address 178.17.0.12
2019-04-07 23:51:46 notice pppd[19869]: MPPE 128-bit stateless compression enabled
2019-04-07 23:51:46 notice netifd[]: Network device ‘pppoe-wan’ link is up
2019-04-07 23:51:46 notice netifd[]: Interface ‘wan6’ is enabled
2019-04-07 23:51:46 notice netifd[]: Interface ‘wan_6’ is enabled
2019-04-07 23:51:46 notice netifd[]: Network alias ‘pppoe-wan’ link is up
2019-04-07 23:51:46 notice netifd[]: Interface ‘wan6’ has link connectivity
2019-04-07 23:51:46 notice netifd[]: Interface ‘wan6’ is setting up now
2019-04-07 23:51:46 notice netifd[]: Interface ‘wan_6’ has link connectivity
2019-04-07 23:51:46 notice netifd[]: Interface ‘wan_6’ is setting up now
2019-04-07 23:51:46 notice netifd[]: Interface ‘wan’ is now up
2019-04-07 23:51:46 err odhcp6c[19905]: Failed to send RS (Permission denied)
2019-04-07 23:51:46 err odhcp6c[19912]: Failed to send RS (Permission denied)
2019-04-07 23:51:46 notice firewall[]: Reloading firewall due to ifup of wan (pppoe-wan)
2019-04-07 23:51:46 info turris-firewall-rules[]: (v63) IPv4 WAN interface used - ‘pppoe-wan’
2019-04-07 23:51:46 info turris-firewall-rules[]: (v63) IPv6 WAN interface used - ‘lo’
Začal bych asi deaktivací IPv6 na ppp spoji + a zakázal WAN6 rozhraní (nespárovaný protokol).
CCP (Compression Control Protocol) negotiation - defakto došlo k resynchronizaci spoje a spoj se rozpadl a vzdálený stroj Vás odpojil. To mi také dělalo u ADSL modemu a to dost často, až jsem od ADSL odešel…
Můžete zkusit donutit spoj, aby nepoužíval CCP: editujte přes ssh soubor /etc/ppp/options a přidejte řádek:
noccp
a zkuste to.
Děkuji za tipy. Sice pomalu, nicméně postupuji, a dávám vědět výsledky:
-
spoj si nechal vnutit nepoužívání CCP, a spojení se už nepřerušuje, takže dobrý 
podle doporučení jsem do /etc/ppp/options přidal řádek
noccp
a restartoval rozhraní WAN
-
deaktivace IPv6 na WAN rozhraní potlačila ty mraky warování uboundu v logu, nicméně mi to nešlo udělat podle obrázku v nápovědě, protože moje záložka “Pokročilé nastavení” vypadá trochu jinak. Takže jsem to vyřešil následovně v duchu rady na https://www.turris.cz/forum/topic_show.pl%3Fpid=10405.html s drobnými změnami:
přes ssh jsem v souboru /etc/config/resolver v sekci
config resolver 'common'
změnil řádek
option net_ipv6 '0'
a restartoval pomocí příkazu
/etc/init.d/resolver restart
