Příspěvky

286

Odkladiště / Re:Mobil Xiaomi MI 9T Pro mě odposlouchává?

« kdy: 22. 10. 2021, 15:01:07 »

uff, ještě že jsem googLLOVSKOU variantu  a xiaOMUNISTICKOU variantu androidu přemáznul LineageOS. Podobné téma tu kdysi bylo (nejsem si jistý, jestli v tom ale hrál roli telefon)...

Ono je to těžké, když lidé mají aktivní oba kanály:
1.(UP)první na šmírování a  reportování (nahrávání, asistent, keyloggery na zlepšování klávesnice)
2.(DOWN) na  injektáž cílenými "informacemi" stahování reklam a "navrhovaného" obsahu.
3.(sidechannel) Bohužel člověk neovlivní- jak zde někdo psal, "návštěva se připojí na stejnou wifi" nebo vás někdo označí.

K automatické regeneraci APN:
Nevím jak s APN na androidu, ale v "starší telefonech" se také stávalo, že dříve smazaný APN se znovu přidal. Bylo to ale z důvodu že byla vyndaná SIM a potom vložená. Telefon tedy při změně SIM natáhl na ní uložené APN. Pomohlo APN nemazat, ale změnit mu název.(Tajemství je v tom , jaký název. Musí se změnit samotná hodnota APN na nesmyslnou. Ale asi musí zůstat "pojmenování profilu APN" - kdyby se totiž přejmenovalo toto, tak se to vyhodnotí, jako jiný profil)
Je možné, že na androidu v jednom z desítek partition typu vendor/oem jsou uložené hodnoty operátorů celé evropy.

287

Server / Re:Vadný NAS Synology

« kdy: 20. 10. 2021, 23:46:15 »

kondenzátor těsně u čtvercové cívky v měniči měl obrovský vnitřní odpor a byl tam už jen pro parádu.

Zmiňoval jsi hodněkrát zkratku DC, tak jen dodám, v režimu DC obrovský odpor není na parádu, ale fyziologický stav .

Tedy pokud jsi nemyslel skutečný vnitřní odpor, který je je zamaskovaný podstatou kondenzátoru v režimu DC se tak jeví a lze ho odhalit jen v AC režimu. (možná poněkud opisem vysvětleno)

288

Server / Obdoba SERVFAIL/NXDOMAIN u virtualhosta

« kdy: 20. 10. 2021, 23:35:06 »

Existuje nějaký koncept  podobný úrovni DNS (NXDOMAIN,SERVFAIL) ale pro oblast, kdy na jednom stroji běží více domén? Uvažuje se stroj, na kterém běží domény na http, některé na https a některé na obou.

Zkusím to vysvětlit: DNS prozradí ip pro danou doménu., ale neřekne jesli běží na http nebo https.


Nelze to zajistit tím, že by TCP nereagovalo nebo RSTovalo, protože aplikační vrstva je až za nim.

Zajímá mě technické řešení , ale i de-facto používané.

Například pro TLS: Něco  co řekne že daný virtual host neexistuje a nepokračuje se dál do HTTP.
A pro HTTP i pro HTTPS(myšleno HTTP po TLS , že by pžedchozí bod nebyl nebo selhal) : Existuje nějaký
stavový kód něco jako No such server?

289

Software / skytube: přiškrcené video 0.1MB/s

« kdy: 16. 10. 2021, 19:23:00 »

Pozoruju. Že při prohlížení videí aplikací Skytube mi to je sosá 100kB/s. Takže se sekají každou chvili. Zkoušel jsem měnit rozlišení(kostrbatě v preferences-playback quality max.res)
Nevíte čím to? Dřív , před pulrokem neblblo žádné videi, před měsícem třeba každé páté (občas pomohlo video pustit znova). Taky dlouho trvá než začne hrát. Teď každé.

V browseru to jede neomezenou rychlostí.

290

Hardware / Re:Ochrana proti zkratu 12V/2A

« kdy: 16. 10. 2021, 19:16:59 »

tak vypne při 4 In.

Co je to za tu jednotku In? Půvidnějsem   myslel že je to logaritmus, ale pismenko je i.
 Tipuji Nějaký proud I s označením n, něco jako normální proud.

291

Windows a jiné systémy / Android: zakázání (části) dotykové obrazovky

« kdy: 29. 09. 2021, 14:26:18 »

Nazdar, je možné nějak na androidu zakázat určitou podoblast dotykové plochy (aby nebyly vyhodnocovány dotyky)? Neustále mi na dolní části disleje se generují falešné dotyky.
Případně jak to persistovat, existuje taky něco jako rc.local/autorun.inf??

A taky, určitě vstup prsty jde přes několik vrstev, od firmwaru na mikročipu dotykové vrstvy po low level driver, který to pak "filtruje, kalibruje", až po očištěný vstup pro gesta androidu, který je následně předává aplikacím.

Já bych to potřeboval právě (!asi!) na té nižší úrovni, aby to dokázalo detekovat i  dotyky na zbytku displeje. Možná by se podařilo díky filtrování na nízké úrovni, že by možná zůstala funkčnost i poblíž spodku obrazovky. Než když to bude filtrované na vyšší úrovni, že se tam žádný touch event nedostane vůbec.


O obraz mi prozatím nejde. Přesto jsem si pomocí

Kód: [Vybrat]

adb shell wm size 1080x1600

zůžil "už tak nudlovitý displej" a trochu odsunul problémovou stranu displeje. Není to ideální, protože to centruje na střed, takže mi zbytečně ubylo i místo nahoře, mohlo by to být 1080x1760 kdyby to bylo zarovnané na hořejšek.

To trošičku pomohlo, ale ne kompletně

292

Sítě / Re:dhcpd troubleshooting hlášek

« kdy: 29. 09. 2021, 14:16:03 »

Jenom pro informaci, ta chybová hláška dhcpcd restartu byla

Kód: [Vybrat]

 dhcpcd[1108]  main: control_open: Connection refused.
dhcpcd[395]: wlan0: DHCP lease expired

toto nejspíš důsledek (oba dva řádky těsně po sobě)
 dhcpcd-run-hooks[471]: wlan0: failed to start wpa_supplicant
dhcpcd-run-hooks[472]: wlan0: Successfully initialized wpa_supplicant



taky systemd- (což ale asi není směrodatné)
systemd[1]: dhcpcd.service: Main process exited, code=killed, status=11/SEGV
 systemd[1]: dhcpcd.service: Failed with result 'signal'.

293

Sítě / Re: dhcp<c>d restart fixuje mac...

« kdy: 29. 09. 2021, 13:03:41 »

Tak se omlouvám, přišel jsem, proč mi nejde ten ohejbák na dhcpcd. Měl jsem omylem zapsané systemctl start/stop/restart dhcpd místo dhcpcd

To takže narovnané to je, ale příčina zůstala, že bez restartu služby to  v 50% zaregistruje správně změněnou MAC a jindy tam visí stará

294

Sítě / Re:DHCP klient použije starou MAC po změně ip link set addr - DHCP neklapne

« kdy: 29. 09. 2021, 12:48:22 »

Možná jsem odhalil potenciální problémový článek - dhcpcd (ale ne co konkrétně tam blbne). Projistotu ještě upřesním že je problém v připojování do vnější sítě, tedy dhcp klienta. Vnitřní síť tady vůbec neřeším

No předpokládal jsem, že když je změna mac obalená příkazy set down  <> ; set up ; ,že není aktivní. A tahle změna je na začátku skriptu. wpa supplicant je na konci.

-Zkoušel jsem tam dávat i prodlevy sleep.
-Taky jsem zkoušel systemctl restart dhcpd po změně. Problém nezmizel,
-zkoušel jsem i  uplně na začátek dát stop dhcdp a po změně start dhcpcd.
- I přesunout start dhcpcd po wpa_supplicantu

V běžícím systému (tedy ne spuštění  routeru), když se v tom hrabu:

Divné je že příkaz dhcpd restart  skončí *někdy* chybou  (musel bych najít, něco jako lease expired)

Někdy pomůže druhé volání systemctl dhcpd restart, nebo stop  & start.
Pak už wpa_supplicant dává správné pole.

Je to dost záhadné, dějou se ty věci náhodně. Ještě zkusím rfkill block & unblock;

295

Sítě / DHCP klient použije starou MAC po změně ip link set addr - DHCP neklapne

« kdy: 28. 09. 2021, 22:18:12 »

Poradíte mi debuggovat jeden podivný problém ohledně  MAC adresy a DHCP handshake??  Je to docela zapeklité, protože se to děje NÁHODNĚ (50% : funkční, 50% nefunkční)

Používám RPI jako router a mám na něm změněnou MAC adresu. Veškerá konfigurace je v skriptu, který je primitivně "spuštěn" sudo /home/me/startuj.sh v /etc/rc.local . (Samozřejmě moduly jako dnsmasq,stubby,  mají svoje konfiguráky , ale třeba i takový wpa_supplicant jde spustit onelinerem s argumentem -c <(wpa_passhrase ssid heslo) -i w1 )

První řádek skriptu je ip link set down w1; ip link set w1 address  XX-YY-----XX; ip link set up ew1h1, pak tam je sysctl, iptables -A, dnsmasq &,  stubby &, suplicant &   (s těmi & přeháním, většina toho má nějaký parametr aby to běželo jako daemon)



PROBLÉM:  V 50% případech   po spuštění WPA_SUPPLICANTU  odchozí komunikace DHCP obsahuje FIELD Client-Ethernet-Address což je políčko  v "aplikační" vrstvě DHCP starou MAC (před změnou pomocí ip link set addr).

A to dokonce i po manuální kill wpa_supplicant a dalším spuštění wpa_supplicant & tcpdum -enti w1 -vvv

Samozřejmě MAC adresa paketů je vždy správná (to je ale adresa na linkové vrstvě), kvůli této neshodě mi DHCP SERVER NEODPOVÍ
 
Kde se bere ale ta náhodnost, že někdy se stihne někde kdesi schovaná proměnná obsahující MAC adresu, která se vstříkne do Client-Address a jindy tam zůstane viset stará (a je následně nekonzistence, že ip a už hlásí novou)?

Vařím z vody, ale soudím, že to nebude něco "systémového", protože MAC adresa paketů vždycky sedí správně, ale problém je ta hodnota uvnitř dhcp paketu a to musí obsluhovat  nějaká služba DHCP.

Otázka 2: jak ručně vynutit, aby client-eth-addr byla aktuální, rovná mac adrese?

Otázka 3: je vůbec možné pole Client-eth-addr vypustit ? Nebo to je principiální nutnost, protože MAC adresu by mohl změnit router, když bude po cestě v  rozlehlejší síti, ? A i tak, jde vypustit , čímž by se implikovalo, že se má použít mac adresa z paketu? (ale asi je to nebezpečné řešení)

Rozumím, by to bylo nejlepší mít nakonfigurované v deseti souborech ve stylu systemd, na ideálně vlastní unity, ale tohle byl prostě takové nejjednodušší zprovoznění (v podstatě ne deklarativně, ale konstruktivně-procedurálně: přijdu k počítači kde nic neběží a rozběhám router přímočaře na zelené louce, že do něj zadám příkazy. Ta samá posloupnost příkazů pak je obsahem toho startovacího skriptu ).

296

Odkladiště / Re:Unášení DNS provozu a hazard

« kdy: 28. 09. 2021, 21:44:27 »

Ty ještě nepoužíváš zabezpečené DNS (na portu 853 nebo 443)?? Na routeru se k tomu hodí stubby například.
Jestli tomu popisu dobře rozumím, tak dělají transparentní redirect na úrovni IP, (alias dns hijacking).

>>atlantis
To není tak jednoduché, jak by se zdálo, když si nastavím dns 8.8.8.8, očekávat, že na dotaz na hledanou doménu přijde taky od 8.8.8.8, Může přijít od 81.24.11, což může být jiný pc v infrastruktuře googlu, prostě "backend", narozdíl od frontentu, kam posílají dotazy klienti.

Stejně tak  provider DalskabatyWifinar může provozovat DNS na počítači 1.2.3.4 (dns.ispik.cz), ale jeho požadavek vyjde ven z 81.24.89.21 serverovnanakopci.ispik.cz  ale i klidně z cloudflare, pokud si nastaví, že jako poskytovatele upstream dns využije třetí službu


HINT: lépe než z IP adres se to pozná podle reverzních DNS jmen. (například front: odvr.nic , ptá se něco jako odvr-2.r.nic.cz )

Takže shoda tam bude aspoň nějaká, že bude vidět že to patří k sobě.

 DNS není monolit, skládá se z 3 částí minimálně - upstream resolver (pokud není použitý rekurzivní), lokální server a klientský resolver... Taky záleží kde jsi měnil nastavení, obvykle jsi na nějaká router připojen a ten ti může vnutit svůj lokální server a nebo ti může "přenechat" to co je v něm nastaveno, např 8.8.8.8 posílá pak v dhcp.

A otázka, máš standartní konfiguraci, jsi napojen přes router?

297

/dev/null / Příklad

« kdy: 24. 09. 2021, 00:30:22 »

zvláštní:"dotažení CSS" bez reloadu
Příklad stránky kde se to děje:
https://supreme.justia.com/cases/federal/us/354/118/
(doména justatic.com na které jsou styly, tedy první načtení s touto doménou nepovolenou - ať uuž přes 3rd party nebo začervernalou touto konkrétně)



Celkem mě fascinoval jeden jev na některých webových stránkách, Chtěl bych vysvětlit, jak to fungujuje, jestli je to nakodované na webu nebo je to věc browseru.

Jde o to, že na některých stránkách pozoruji, že ve jsou schopné "načíst" CSS,poté, co se to při prvním pokusu"první návštěvě nepovedlo z tohoto důvodu:
1. mají styly nebo obrázky na externí doméně  a ta je zablokovaná uBlock origin..
2. (nezkoušeno) nastavit v developer tools - Network - typ sítě 2G (jinak to člověk nestihne vnímat ) a vytáhnout "kabel" nebo dát  checkbox Offline

Upozornění
Možná to silně bude záležet na prohlížeči a zadruhé, bude možná mít vliv cache (takže asi nepujde postup že si otevřu stránku, tam zakážu domény cdn nebo 3rd, reloadnu a pak zase povolím
)
-je nanejvýš vhodné mít otevřenou konzoli a v tabu network zaznamenávat requesty  pro názornost.

 Každopádně je divné, že se to děje i v tom případě uBLock origin, kdy nijak se nemění stav online/offline, pouze brání načítání z nějakých domén (Setting-Advanced  User - a dynamické filtrování blokovat domény3rd party)

Konkrétní příklad
weby na google blog(spot) - nemusí nutně běžet doméně google blogspot - konkrétně fffilm.name - Prvně, když se stránka načte a je blokováno:
blogblog.com
blogger.com
bp.blogspot.com
tak se stránka nenačte hezky (bez obrázků nebo s divným vzhledem- chybějící CSS)
Pak následuje fáze 2
buď připojím kabel nebo odškrtnu Offline v konzoli nebo v ubLocku povolím domény.


A SAMO SE TO NAČTE. Bez  reloadu.

(fffilm.name je vybráno pouze jako příklad)


Společný jmenovatel: načte se to bez nutnosti reloadu, prakticky hned po "odblokování"


čím to je? Nějaký timeout, kdy browser zkouší načíst  aktivně resource po nějakou dobu než to vzdá nebo něco jako mutation observer nebo něco jako html5 featura Stav-dokumentu oflline resp. odpovídající listener na změnu stavu (nevim  zda se to zrovna nejmenuje onOnline)

Vážně by mě to zajímalo, jak tahla magická věc funguje.

298

Software / Re:GUI pro slučování podobných textových souborů

« kdy: 23. 09. 2021, 18:02:46 »

Mám podobný provlém , akorát že těch souborů je 7. Mají 400 až 3000 řádků, někde záznam je tvořen 2 řádky ( komentář).


Soubory jsou jako vzasadě jako append , pokud se ručně nemění(což ale se děje kvuli drobnym upravam). Vetsinou jsou vzaté z nějakého předchozího  a tudiž některé nohou mít společnou historii . ale byly zkopirovany na ruzna zarizeni v ruzny cas a vyvijely se vlastnim zivoten (append a obcasne editace, korekkce) a je běžné že do stejná věc se mohla do  dostat do vice souboru (mozna v s.nejakou odchylkou)


Zaznam je vzdy dvojice radku, kdy prvni je comment a druhy samotny record. Ovsem pri vlozebi "stejneho zaznamu" se muze cast komentu mirne lisit. Dokonce se muze mirne lisit i samotny record .


Mohou tam být ručni odchylky ( odmazaný řadek veprostřed, zakomentovany ci upraveny)

Tool by byměl nějak schopn být umět znát syntaxi a "normalizovat řádky" (např. "/*" u jednoho ne ano , nebo část za nějakym znakem co se vyskytuje jen jednou)


Cílem je všechny soubory agregovat do jednoho.

299

Windows a jiné systémy / Android USB tethering <->Wifi bez překladu adres

« kdy: 20. 09. 2021, 17:14:46 »

Je nějak možné na androidu zprovoznit USB Tethering (že je připojen k  WLAN, tam problém není)  aby nepoužíval  překlad adres na na rozhraní rndis0 a nebo dokonce aby běžel místo síťové vrstvy na linkové (tím pádem by ani překlad adres nepřicházel v úvahu)?

V windows  se pak po připojení mobilu USB kabelem v Síťových adaptérech vytvoří nový "Remote NDIS  Internet sharing  Device" s rychlostí   429,50 Mb/s a vlastním DNS,DHCP, makou, subnetem ip a bránou.

300

/dev/null / zvláštní:"dotažení CSS" bez reloadu

« kdy: 18. 09. 2021, 16:38:17 »

Celkem mě fascinoval jeden jev na některých webových stránkách, Chtěl bych vysvětlit, jak to fungujuje, jestli je to nakodované na webu nebo je to věc browseru.

Jde o to, že na některých stránkách pozoruji, že ve jsou schopné "načíst" CSS,poté, co se to při prvním pokusu"první návštěvě nepovedlo z tohoto důvodu:
1. mají styly nebo obrázky na externí doméně  a ta je zablokovaná uBlock origin..
2. (nezkoušeno) nastavit v developer tools - Network - typ sítě 2G (jinak to člověk nestihne vnímat ) a vytáhnout "kabel" nebo dát  checkbox Offline

Upozornění
Možná to silně bude záležet na prohlížeči a zadruhé, bude možná mít vliv cache (takže asi nepujde postup že si otevřu stránku, tam zakážu domény cdn nebo 3rd, reloadnu a pak zase povolím
)
-je nanejvýš vhodné mít otevřenou konzoli a v tabu network zaznamenávat requesty  pro názornost.

 Každopádně je divné, že se to děje i v tom případě uBLock origin, kdy nijak se nemění stav online/offline, pouze brání načítání z nějakých domén (Setting-Advanced  User - a dynamické filtrování blokovat domény3rd party)

Konkrétní příklad
weby na google blog(spot) - nemusí nutně běžet doméně google blogspot - konkrétně fffilm.name - Prvně, když se stránka načte a je blokováno:
blogblog.com
blogger.com
bp.blogspot.com
tak se stránka nenačte hezky (bez obrázků nebo s divným vzhledem- chybějící CSS)
Pak následuje fáze 2
buď připojím kabel nebo odškrtnu Offline v konzoli nebo v ubLocku povolím domény.


A SAMO SE TO NAČTE. Bez  reloadu.

(fffilm.name je vybráno pouze jako příklad)


Společný jmenovatel: načte se to bez nutnosti reloadu, prakticky hned po "odblokování"


čím to je? Nějaký timeout, kdy browser zkouší načíst  aktivně resource po nějakou dobu než to vzdá nebo něco jako mutation observer nebo něco jako html5 featura Stav-dokumentu oflline resp. odpovídající listener na změnu stavu (nevim  zda se to zrovna nejmenuje onOnline)

Vážně by mě to zajímalo, jak tahla magická věc funguje.