Fox Mulder

Myslím, že byste měli překontrolovat pro jistotu všechna vestavěná pravidla, jelikož jsou tam odlišné směry nejen i pro ty dvě další pravidla, které také vidíte na screenu v předchozím příspěvku, ale je špatně i např. "Povolit synchronizaci času (NTP)". Zde je také komunikace povolena jen dovnitř, a tudíž synchronizace nefunguje.

V případě, že by někdo měl stejný problém, zde je rozřešení problému. Potíž je v tom, že ve vestavěném pravidlu firewallu, které povoluje získávání IP adresy, je v nové verzi 16.2.11.0 povolena komunikace pouze dovnitř (viz zaslaný screenshot). Notebook ale pro získání IP chce komunikovat ven (viz další screenshot), což mu právě toto nastavení pravidla znemožňuje. Ve starší verzi 16.1.14.0 je toto pravidlo odlišné - je tam povolena komunikace oběma směry, tedy ven i dovnitř (viz třetí screenshot). Proto ve starší verzi než došlo k aktualizaci, získávání IP adresy z DHCP fungovalo bez problémů. Toto se projevuje jen ve firewallu nastaveném na administrátorský režim (jako to mám já), v automatickém režimu, který je výchozí a povoluje vše odchozí, se to samozřejmě neprojeví. Netuším, zda jde o záměr programátorů nebo chybu...

Ano, jen bezdátově do Wi-Fi sítě. Je to moje domácí síť, ale jako veřejnou (nedůvěryhodnou) ji mám označenou záměrně kvůli přísnějším vestavěným pravidlům firewallu. Nicméně před aktualizací 16.2.11.0 fungovalo přiřazování parametrů sítě z DHCP bezchybně i při veřejně označené síti. I tak jsem ji ale zkusil označit jako důvěryhodnou dle vašeho obrázku, ale bohužel ani toto nijak nepomohlo - získávání parametrů sítě je stále blokováno.

Zasílám logy z ESET Log Collector při zapnutém rozšířeném protokolování. Bohužel dalším krokem nemůžu pokračovat, jelikož netuším, která je ta příslušná komunikace, kterou bych měl odblokovat pro komunikaci s DHCP - je jich tam vetší množství, obzvlášť po zapnutí/restartu počítače. Která by měla být ta správná? Můžete mi sdělit, jak by tyto detaily pravidla pro komunikaci s DHCP měly vypadat? Žádnou komunikaci IP adresy kterou má můj router (v něm běží DHCP), s počítačem či opačným směrem tam blokovanou nevidím. Co přesně bych tam měl hledat? Díky. eis_logs (NTB Asus P50IJ - rozšířené protokolování).zip

Doplňuji další poznatek z testování této situace: Provedl jsem odinstalaci EIS pomocí ESET Uninstalleru a čistou instalaci verzí 16.2.11.0, ale bohužel ani toto nijak nepomohlo k vyřešení problému. Zjistil jsem, že po nainstalování EIS 16.2.11.0 se může notebook restartovat a parametry sítě od DHCP dostává, ale jakmile se notebook vypne, při následném zapnutí už od DHCP nic nedostane. ESET to bohužel blokuje.

eis_logs (NTB Asus P50IJ).zip

Ještě přidávám logy z ESET Log Collector. Možná Marcos by z nich něco vyčetl... Díky za případné reakce. eis_logs.zip

Dobrý den, můj notebook (Win 11 x64) po zaktualizování na programovou aktualizaci 16.2.11.0 přestal dostávat IP adresu od DHCP serveru v routeru (TP-Link). Vždy dostane pouze DNS servery, ale IP adresu nikoli. Zůstane mu tedy ta začínající 169.x.x.x, a tedy nefunguje připojení k internetu. Před touto aktualizací bylo vše v pořádku. Poznatek je takový, že pokud notebooku IP adresu zadám ručně, připojí se a vše funguje. Chci ale, aby ji dostával od DHCP a to teď bohužel není možné. Taktéž pokud deaktivuji ESET firewall, notebook ihned dostane IP adresu od DHCP. Je tedy zřejmé, že to má souvislost s ESETem a poslední programovou aktualizací. Má někdo podobné potíže? Klidně bych se vsadil, že instalace starší verze 16.1.14.0 by problém vyřešila. Jen doufám, že nedojde k automatické aktualizaci na ostatních PC na poslední verzi ESETu... Díky.

Dobrý den Peter, postup, který doporučujete, jsem již udělal i spolu s odesláním logů z aplikace EMS (případ #HVW-715-41513, #IOX-424-76255), ale kolegové z technické podpory, z logů nic, co by vysvětlilo takové chování, nezjistili. Nerozumím, proč k takovému chování nedocházelo se starší verzí 6.3.66.0, a jakmile jsem nainstaloval verzi 7.x.x.x, tak hned se to takto začalo chovat. Z mého pohledu to vypadá, jako kdyby byla potíž ve verzi EMS 7.x.x.x. Kolegové z technické podpory ale tvrdí, že v aplikaci EMS chyba není. Jak ale tedy vysvětlit skutečnost, že u starší verze bylo vše v pořádku? U jiných aplikací k odebírání práv nedochází, jen u EMS a to ještě pouze oprávnění přístupu ke všem souborům (jiná oprávnění EMS zůstanou zachována). Hezký den.

Vidím, že bohužel ani moudrý Marcos netuší, kde by mohla být potíž. Mohl by mi napsat, kde stáhnout z oficiálního zdroje od ESETu, starší verzi 6.3.66.0, se kterou zmíněný problém nebyl? Nainstaloval bych ji lokálně, když na Google Play již není k dispozici. Díky.

Dobrý den, nainstaloval jsem si na mobil (Nokia 4.2) nový ESET Mobile Security (EMS) verze 7.x.x a zjistil jsem tento problém s oprávněním. Aplikace EMS si po instalaci vyžádá oprávnění přístupu ke všem souborům, které ji povolím a vše pracuje správně. Problém nastane po restartu telefonu, kdy aplikace EMS po spuštění hlásí, že Antivirus nepracuje správně a znovu se dožaduje povolení oprávnění ke všem souborům. Když nahlédnu v nastavení telefonu, jaké oprávnění má EMS, je tam, že přístup má pouze k médiím, nikoli ke všem souborům. Povolím tedy přístup ke všem souborům a vše je v pořádku. Po restartu telefonu se opakuje již výše popsané, že má EMS přístup jen k médiím. Vyzkoušena i reinstalace EMS. Vyzkoušel jsem aplikaci EMS povolit oprávnění k přístupu k poloze (kvůli detekci zařízení v síti) a toto oprávnění zůstane správně zachované i po restartu telefonu. (Používám jen skenování souborů, nikoli všechny funkce aplikace EMS, tudíž ostatní funkce mají oprávnění běžně nepovolené). U předchozí verze 6.3.66.0 k tomuto nikdy nedošlo. Změnu verze jsem provedl odinstalací verze 6.3.66.0, restart telefonu a novou instalaci verze 7.x.x z Google Play. Nerozumím tomu, proč u starší verze k tomu nedocházelo, a ihned po instalaci nové ano. Bohužel již není možné nainstalovat zpět starší verzi 6.3.66.0, jelikož na Google Play již není k dispozici. Není tedy ani možné vyzkoušet, zda by ke stejnému problému docházelo teď se starší verzí, a vyloučit tak problém v samotném Androidu. V telefonu je systém Android 11 s posledními aktualizacemi systému a pouze integrované aplikace Googlem. Děkuji.

1) Myslím tím ten modul, který upravíte, pokud je třeba nějak pozměnit testování registru. V minulosti test registru byl upraven, aby nebyly testovány odkazy na neexistující položky (zaznělo zde na fóru v angličtině). Právě ten modul mě zajímá. Vidím totiž, že při Smart kontrole, už není testován registr na jednom z PC, přestože příslušný checkbox je zatržen, ale na druhém PC je stále testován. Na těch PC je ale právě rozdílná (mimo jiné) verze modulu "Modul léčení" - 1213 a 1214. Nebylo od verze 1214 upraveno testování registru, aby se testoval pouze při hloubkové kontrole? 2) Nikoli, na obou PC jsou zapnuté standardní aktualizace, přesto jsou čtyři moduly v odlišných verzích. Děkuji.

Dobrý den, mohl by mi Marcos sdělit, jaký modul v programu ESET, reprezentuje testování registru? Nejde o modul s názvem "Modul léčení"? Dále by mě zajímalo, proč např. na dvou počítačích, kde ESET hlásí, že je aktuální a nestahuje žádnou aktualizaci, jsou přesto některé moduly v rozdílných verzích? Např. Modul antivirového a antispywarového skeneru, Modul léčení, Modul LiveGrid komunikace a Modul kontroly skriptů...? Taková situace je v pořádku? Děkuji.

Dobrý den, po zaktualizování programu EIS na verzi 13.2.15.0 jsem si všiml dvou problémů v programu. Ten první je zcela jistě chyba, u druhého nevím, zda to není záměr programátorů a tedy to může být správně. První problém: Nastavení - Síťová ochrana - Průvodce řešením problémů V některých případech, pokud kliknu na Detaily, v zobrazeném okně není zobrazen řádek (druhý modrý) s textem celý, řekl bych, že zde asi chybí vodorovný posuvník. Dále jsou tlačítka Odblokovat a Zavřít posunuta moc doprava a tlačítko Zavřít téměř není vidět (v některých případech není tlačítko Zavřít vůbec vidět a Odblokovat je o kousek "useknuté"). Mnohem více řekne screenshot, který zasílám v příloze. Rovnou zmíním, že reinstalace EIS, kterou zkoušel známý, nic neřeší, proto se domníváme, že jde asi o chybu v kódu ESETu. Druhý problém (?): Nástroje - Další nástroje - Plánovač Zde jde možná o záměr, ale v předchozí verzi EIS se takto aktualizace v plánovači nechovala. Stejné popisuje uživatel na ESET fóru (nebudu to tedy popisovat znova) zde https://forum.eset.com/topic/24869-eset-internet-security-132150/ ,ale nikdo přímo z ESETu mu tam neodpověděl, zda jde o chybu nebo je to v pořádku. Děkuji.

Ahoj, Již delší dobu pozoruji na NTB problém s výpadky internetu. Vše co souvisí se síťovým připojením jsem zkontroloval a vše se zdá být v pořádku. Proto mě napadlo, jestli to třeba nesouvisí s programem EIS (chybou v některém modulu?), jelikož provádí kontrolu provozu sítě. Problém se projevuje naprosto náhodným výpadkem přístupu k internetu po náhodných dobách, vždy cca na 2-3 minuty, poté se spojení obnoví a vše zase funguje. Níže popisuji poznatky: *** V době výpadku je vždy na liště u hodin "zeměkoule se zákazovou značkou", když na ni najedu myší je zde informace s názvem Wi-Fi sítě, ke které jsem připojen a "připojení k internetu není k dispozici". *** V době výpadku v nastavení Windows v sekci "Síť a internet" a "Zobrazit vaše vlastnosti sítě" má NTB stále přidělenou IP adresu a servery DNS z DHCP, ale není tam vidět doba zápůjčky IP adresy a rychlost spojení (což v době funkčního připojení je) a je tam také informace "Připojeno k neznámá síť". Po samovolném obnovení připojení (po zmíněných cca 2-3 minutách) se tam veškeré informace zase zobrazí i s informací "Připojeno". *** Po samovolném obnovení připojení NTB nežádá server DHCP o přidělení IP adresy, tedy adresu neztrácí. *** V době výpadku jsou normálně vidět moje i ostatní Wi-Fi sítě v okolí, tedy Wi-Fi modul v NTB bude pravděpodobně fungovat správně. *** V době výpadku se nedá připojit k jiným zařízením v síti, tedy u poskytovatele problém nepředpokládám. *** Na stoním PC, který je ke stejnému routeru připojen, ale kabelem, se výpadky neprojevují. *** Velmi zvláštní je to, že poprvé se výpadky objevily letos v březnu hned po změně času na letní. V souvislosti s jinou věcí jsem z programu EIS v nastavení u firewallu ze "Známé sítě" odstranil moji Wi-Fi síť a nastavení uložil. Program ESET si ji zase hned načetl znova zpět. Poté jsem ještě provedl restart NTB. Od té doby výpadky zmizely, ale jen do doby, než se letos v říjnu zase posunul čas na zimní. Po změně času se zase hned výpadky objevily. Zvláštní... *** Dříve jsem měl jiný router (Ubiquiti) a jiný přístupový bod (Edimax), s těmito zařízeními se nikdy žádné výpadky neobjevovaly. Možná nějaká nekompatibilita mezi novými zařízeními (Tp-Link a Asus) a programem EIS, která by se ale projevovala po změně času??? Opravdu zvláštní... ---------------- - Hlavní drátový router TP-Link TL-R600VPN, který přiděluje IP adresy a další parametry sítě. - Wi-Fi router Asus RT-AC1200G+ (běží v módu pouze jako přístupový bod), ke kterému se připojuje zmíněný NTB. - Na obou routerech správný čas i datum, taktéž i v NTB. - V NTB ovladač Wi-Fi aktuální. - Firmware obou routerů aktuální. - Vzhledem k tomu, že se problém vždy objevil po změně času zimní/letní a opačně, nepředpokládám tedy nějakou HW vadu nějakého ze zmíněných zařízení. V případě závady by se problém poprvé asi neobjevil vždy po změně času. - EIS 13.0.24.0 (potíž ale existovala i při starších programových verzích EIS). - Moduly ESET aktuální k dnešnímu dni. - Windows 10 1909, aktuální k dnešnímu dni. -------------- Netvrdím, že je zcela jistě potíž v ESETu, ale vzhledem k tomu, že v síti a zařízeních se zdá být vše OK, mohl by to ESET možná způsobovat, vzhledem k tomu, že skenuje a kontroluje síťový provoz. Dle dostupných informací, v dávné minulosti v ESETu verze 4 byl údajně nějaký problém s odpojováním sítě ESETem. Možná nějaká podobná chyba...? Díky za případný předběžný názor nebo na navedení, kde by mohla být potíž.