1
Software / Ovladač USB-C UVC video webkamery pro Android
« kdy: 27. 11. 2023, 12:27:22 »
Shánám program pro android, který zpřístupní připojenou webkameru vysílající obraz přes USB device class UVC.
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
2
Hardware / Jaký 3,5mm kabel pro mikrofon
« kdy: 27. 11. 2023, 12:24:12 »
zdravim zvukaře, možná půjde o banální věc, ale chtěl bych se ujistit, jaký koupit kabel pro přenos nahrávání mono zvuku z lineout výstupu . Fyzická podmínka je 3,5mm jack samec na obou koncích.
Současný TRS (2 černé nevodivé proužky) mi funguje pouze na vstupu zrcadlovky a navíc ukazuje ještě jeden kanál (nevím jestli je to chyba nebo záměr, jen je to možná detail)
Nefunguje to po připojení do androidu, dokonce si krám myslí, že jde o sluchátka, ani v Nokia telefonu. Co bohužel jsem nevyzkoušel je 3,5mm vstup na počítačích.
Má to být TS (dlouhý SLEEVE, kraťoučký ŤIP - jeden nevodivý proužek) , nebo TRRS (3 oddělující proužky) ? Jde o ten konec připojující se do PC/kamery/eventualně smartphonu. Vše 3,5mm jack samice. Chtěl bych právě tuto univerzálnost, abych mohl nahrávat do těchto 3 zařízení.
Nebo to řešit nějakým "Y" adaptérem ( kombo jack samec , 2 zdířky pro mikrofon a sluchátka, nemyslím "rozdvojku"). ? By šlo? Na tom by mi vadilo, že takový "balvan" bude třeba překážet.
Současný TRS (2 černé nevodivé proužky) mi funguje pouze na vstupu zrcadlovky a navíc ukazuje ještě jeden kanál (nevím jestli je to chyba nebo záměr, jen je to možná detail)
Nefunguje to po připojení do androidu, dokonce si krám myslí, že jde o sluchátka, ani v Nokia telefonu. Co bohužel jsem nevyzkoušel je 3,5mm vstup na počítačích.
Má to být TS (dlouhý SLEEVE, kraťoučký ŤIP - jeden nevodivý proužek) , nebo TRRS (3 oddělující proužky) ? Jde o ten konec připojující se do PC/kamery/eventualně smartphonu. Vše 3,5mm jack samice. Chtěl bych právě tuto univerzálnost, abych mohl nahrávat do těchto 3 zařízení.
Nebo to řešit nějakým "Y" adaptérem ( kombo jack samec , 2 zdířky pro mikrofon a sluchátka, nemyslím "rozdvojku"). ? By šlo? Na tom by mi vadilo, že takový "balvan" bude třeba překážet.
3
Windows a jiné systémy / Klávesnice mi vyměnila WASD a šipky
« kdy: 26. 11. 2023, 22:54:01 »
Nevím co se mi stalo s klávesnici. Najednou mám prohozené šipky a klávesy wasd. Napříč okny. OS Win 10. Jak je tohle možné?
4
Sítě / USB síťovka na routeru ASUS DSL-N16U
« kdy: 22. 11. 2023, 18:59:45 »
Ahojte, na ADSL routeru ASUS N-16U potřebuji zprovoznit jednu věc. Do USB portu jsem píchl gigabitovou síťovku a chci, aby rozhraní (wifi) spojil, víceméně netrvám na tom aby je bridgoval nebo mezi nimi routoval. Neptejte se proč, ale potřebuji další rozhraní, jiné než integrované porty.
Systém ji našel, v admin rozhraní na hlavní stránce "Network map" ji vidí v Connected USB Devices. Správně napsáno Realek USB LAN 10/100/1000.
Jenže ouha, když přejdu do nastavení vyberu WAN - Dual WAN - Primary WAN přepnu z ADSL na USB WAN,
mě vomejou.
Vidím tam tyhle nesmysly: (obrázek, jiný než v spanělštině jsem nenašel, ale snad je to pochopitelné)
On si router myslí, že jde o USB modem
! ! Přitom jde o Ethernetový adaptér. kde se žádné číslo ne bo APN nenastavuje. Nikde tam nevidím (třeba v dlouhatanském seznamu type Huawei, Siera, Ericson tam bude Ethernet Manual nebo v Connection type:2G/3G/4G bude i Ethernet jsem doufal) možnost něc jako plain old Ethernet.
Nechápu to i z logiky věci, když už to umí použít USB modem(kde je nějaká mezivrstva AT příkazů), tak očekávám, že to bude umět i takovou trivialitu, když to USB zařízení je 802.3 Ethernet
Systém ji našel, v admin rozhraní na hlavní stránce "Network map" ji vidí v Connected USB Devices. Správně napsáno Realek USB LAN 10/100/1000.
Jenže ouha, když přejdu do nastavení vyberu WAN - Dual WAN - Primary WAN přepnu z ADSL na USB WAN,
mě vomejou.
Vidím tam tyhle nesmysly: (obrázek, jiný než v spanělštině jsem nenašel, ale snad je to pochopitelné)
On si router myslí, že jde o USB modem
! ! Přitom jde o Ethernetový adaptér. kde se žádné číslo ne bo APN nenastavuje. Nikde tam nevidím (třeba v dlouhatanském seznamu type Huawei, Siera, Ericson tam bude Ethernet Manual nebo v Connection type:2G/3G/4G bude i Ethernet jsem doufal) možnost něc jako plain old Ethernet.Nechápu to i z logiky věci, když už to umí použít USB modem(kde je nějaká mezivrstva AT příkazů), tak očekávám, že to bude umět i takovou trivialitu, když to USB zařízení je 802.3 Ethernet
5
Sítě / Co je s routerem?
« kdy: 11. 11. 2023, 16:30:34 »
Začal se mi podivně chovat "router" (v uvozovkách, protože neplní funkci routeru) . Přes půl roku jsem do něj nelezl, nic neměnil, Předtím fungoval k spokojenosti. Zjednodušeně vše co se týká bezdrátu je divné, drátová zařízení a připojení jsou OK
Způsob použití výhradně jen jako Wifi AP + 4*Lan v bridge, . WAN nevyužito, defacto na něm očekávám jen L2 komunikaci a L2 bridging. Abych měl kam připojit bezdrátová zařízení
nyní:
- bezdrátová zařízení nedostanou IP, tudíž se nedostanou ani na LAN. Defacto všem bezdrátovým zařízením "nejde internet" (a ani LAN)
- skutečný faktickýrouter , tedy DNS,DHCP, gateway v síti vidí příchozí požadavky DHCP
- vypadá to, že wifi "link" je sestavená, asociováno
- bezdrátová zařízení nedostávají (nevidí)ARP odpovědi
- nepomůže statická IP na bezdr. zařízeních, protože i tak se ptají pořád ptají na IP brány nebo ostatních zařízení
- po restartu routeru je tak 20% šance , že bude vše fungovat, ale cca tak na 3 minuty, pak telefony zdtratí spojení
-jediné, kam se dá dostat je na IP toho routeru z bezdrátových zařízení
-zařízená přes kabelový Ethernet spolu normálně komunikují mezi sebou i do internetu
-kabelová zařízení fungují a dostanou IP od toho faktického DHCP i když jsou nově připojena.
Předem se omlouvám, že nejde o kompletní nebo exaktní popis. Opakuji, jde o ten "router" v roli Wifi AP + ethernetové switche. Ten je kabelem připojen k skutečnému routeru (to,co se od routeru čeká+dns+dhcp)
zkoušel jsem gigabitový kabel od routeru znovu zapojit, natočit antény
Nevíte co s ním je? Mám pocit, že se nějak rozhasilo bridgování u wifi-části a nebo umírá Wifi-část(pak ale bych očekával i problémy při komunikaci na HTTP rozhraní té krabičky, ale to paradoxně funguje)
Způsob použití výhradně jen jako Wifi AP + 4*Lan v bridge, . WAN nevyužito, defacto na něm očekávám jen L2 komunikaci a L2 bridging. Abych měl kam připojit bezdrátová zařízení
nyní:
- bezdrátová zařízení nedostanou IP, tudíž se nedostanou ani na LAN. Defacto všem bezdrátovým zařízením "nejde internet" (a ani LAN)
- skutečný faktický
- vypadá to, že wifi "link" je sestavená, asociováno
- bezdrátová zařízení nedostávají (nevidí)ARP odpovědi
- nepomůže statická IP na bezdr. zařízeních, protože i tak se ptají pořád ptají na IP brány nebo ostatních zařízení
- po restartu routeru je tak 20% šance , že bude vše fungovat, ale cca tak na 3 minuty, pak telefony zdtratí spojení
-jediné, kam se dá dostat je na IP toho routeru z bezdrátových zařízení
-zařízená přes kabelový Ethernet spolu normálně komunikují mezi sebou i do internetu
-kabelová zařízení fungují a dostanou IP od toho faktického DHCP i když jsou nově připojena.
Předem se omlouvám, že nejde o kompletní nebo exaktní popis. Opakuji, jde o ten "router" v roli Wifi AP + ethernetové switche. Ten je kabelem připojen k skutečnému routeru (to,co se od routeru čeká+dns+dhcp)
zkoušel jsem gigabitový kabel od routeru znovu zapojit, natočit antény
Nevíte co s ním je? Mám pocit, že se nějak rozhasilo bridgování u wifi-části a nebo umírá Wifi-část(pak ale bych očekával i problémy při komunikaci na HTTP rozhraní té krabičky, ale to paradoxně funguje)
6
/dev/null / Proč jdou webové stránky čímdáltímvíc dozadeke?
« kdy: 30. 10. 2023, 00:28:01 »
Jaké je vysvětlení, že s webovými stránkami to jde čím víc dál z kopce, i když to vypadá, že před 5 lety to už bylo na dně a a ony dokážou překvapit i dnes?
Příklad: idnes.cz:
-1. počáteční stav: stránka fungovala v pohodě, stačilo mít zablokované nežádoucí domény (třeba narouteru)
0. Bylo potřeba v adblocku se i podívat na samotnou doménu navštíveného webu, kde se vyskytovaly škodná URL
kdysi to začmodrchali tak, že stránka po reloadu vypadala jak HTML 2.0 bez podvolení se komunikace na rekamní URL a stahovala desítky podivných scriptů s kryptickými URL.
1. došlo články na podobné články byly znásilněny onclick na 1gr.cz/log - šlo vyřešit +js(add element listenter defuser, onmousedown)
2. znásilnění URL bylo permanentní a tak bylo nutné url extrahovat z atributu (právem dříve zablokované URL 1gr.log$document),
3.
nyní je výsledkem dvojitý znásilnění URL: (před kterým samozřejmě ublock origin nastaví mříž a ukáže varovný prst nehledě na doménu )
https://1gr.cz/log/score.aspx?pa*ld&url=https%3A%2F%2Fapi.cxense.com%2Fpublic%2Fwidget%2Fclick%2Fa3YKnerozšifrovatelá_směsicejakobase64 *
&id=23010bla_neco...
Neodvažoval jsem se to otevřít v proxy (kde jistě tahle doména není blokovaná
) a asi by mě to přesměrovalo po všech čertech cj.com nebo dotomi.com na konečnou stránku s článkem, která ve výsledku se od původní liší jen v (kromě nesměrodatného slugu) v id článku
A přitom jde o LINK na vedlejší článek.
A přitom částečný link na článek (alias čtenáři zahraj si na detektiva) se nachází v id GET parametru - stačí zadat idnes.cz/rubriky1/rubrika2/nahodnysledslugů.23010bla_neco a otevře se správný
uBlock Origin zabránil následující stránce v načtení:
bez parametrů = https://1gr.cz/log/score.aspx
page = xxx
box = podclankem1-retardee
place = 2
type = Bulvárníkecy
id = A231014_120159_jpz-laska-poradna-vestci-fabulace
url = https://api.cxense.com/blablalbal
tak mám řečnickou otázku? Opravdu limity neexistují a lze klesat až do nekonečna a stránky budou komunikovat šifrovaným websocketem s využitím cookies, localstorage a renderovat on the fly svg místo textu? A pro jistotu přečíst bez pocitu že mi někdou šťourá sondu do větráku počítače už nepůjde?
Nebo to webmaster v okamžiku 0 musel spadnout na hlavu, v okamžiku 1 se s ním rozešla holka, v okamžiku 2, je po 10 letech hulení trávy, v okamžiku 3 je po roce členství s straně SPD nebo výcviku talibanu, že tohle někdo dopustí, že link na vedlejší článek (de facto relative URL) se generuje přes nějakou 3. doménu s odkazem na čvtrou doménu???
Nebo se bude hypertext konzumovat tak, že se nadpis článku označí myší a zadá se do vyhledávače, který má snad zaindexováno a vyflusne požadovanou url, pro kterou ani nebylo předtím ani nutné zvednout malíček levého tlačítka myši z postele vstát? A to ani se nerozhoňuji, že takové URL má 850 znaků !!!)
* samozřejmě zkoušeny substringy(začátek, střed,konec) toho asi 700 jako-base64-hatmatilky i s umazáním 1,2,3,žádného počátečního znaků ,což je vlastnost base64, že je "modulo 4" na znaky co se týče správnosti vdekódování.
Příklad: idnes.cz:
-1. počáteční stav: stránka fungovala v pohodě, stačilo mít zablokované nežádoucí domény (třeba narouteru)
0. Bylo potřeba v adblocku se i podívat na samotnou doménu navštíveného webu, kde se vyskytovaly škodná URL
kdysi to začmodrchali tak, že stránka po reloadu vypadala jak HTML 2.0 bez podvolení se komunikace na rekamní URL a stahovala desítky podivných scriptů s kryptickými URL.
1. došlo články na podobné články byly znásilněny onclick na 1gr.cz/log - šlo vyřešit +js(add element listenter defuser, onmousedown)
2. znásilnění URL bylo permanentní a tak bylo nutné url extrahovat z atributu (právem dříve zablokované URL 1gr.log$document),
3.
nyní je výsledkem dvojitý znásilnění URL: (před kterým samozřejmě ublock origin nastaví mříž a ukáže varovný prst nehledě na doménu )
https://1gr.cz/log/score.aspx?pa*ld&url=https%3A%2F%2Fapi.cxense.com%2Fpublic%2Fwidget%2Fclick%2Fa3YKnerozšifrovatelá_směsicejakobase64 *
&id=23010bla_neco...
Neodvažoval jsem se to otevřít v proxy (kde jistě tahle doména není blokovaná
) a asi by mě to přesměrovalo po všech čertech cj.com nebo dotomi.com na konečnou stránku s článkem, která ve výsledku se od původní liší jen v (kromě nesměrodatného slugu) v id článkuA přitom jde o LINK na vedlejší článek.
A přitom
částečný link na článek (alias čtenáři zahraj si na detektiva) se nachází v id GET parametru - stačí zadat idnes.cz/rubriky1/rubrika2/nahodnysledslugů.23010bla_neco a otevře se správnýuBlock Origin zabránil následující stránce v načtení:
bez parametrů = https://1gr.cz/log/score.aspx
page = xxx
box = podclankem1-retardee
place = 2
type = Bulvárníkecy
id = A231014_120159_jpz-laska-poradna-vestci-fabulace
url = https://api.cxense.com/blablalbal
tak mám řečnickou otázku? Opravdu limity neexistují a lze klesat až do nekonečna a stránky budou komunikovat šifrovaným websocketem s využitím cookies, localstorage a renderovat on the fly svg místo textu? A pro jistotu přečíst bez pocitu že mi někdou šťourá sondu do větráku počítače už nepůjde?
Nebo to webmaster v okamžiku 0 musel spadnout na hlavu, v okamžiku 1 se s ním rozešla holka, v okamžiku 2, je po 10 letech hulení trávy, v okamžiku 3 je po roce členství s straně SPD nebo výcviku talibanu, že tohle někdo dopustí, že link na vedlejší článek (de facto relative URL) se generuje přes nějakou 3. doménu s odkazem na čvtrou doménu???
Nebo se bude hypertext konzumovat tak, že se nadpis článku označí myší a zadá se do vyhledávače, který má snad zaindexováno a vyflusne požadovanou url, pro kterou ani nebylo předtím ani nutné zvednout malíček levého tlačítka myši z postele vstát? A to ani se nerozhoňuji, že takové URL má 850 znaků !!!)
* samozřejmě zkoušeny substringy(začátek, střed,konec) toho asi 700 jako-base64-hatmatilky i s umazáním 1,2,3,žádného počátečního znaků ,což je vlastnost base64, že je "modulo 4" na znaky co se týče správnosti vdekódování.
7
/dev/null / Co dělají tyto domény
« kdy: 14. 10. 2023, 19:37:42 »
pubimgs.com
suspectmark.com
succeedscene.com
Neptal bych se kdyby na root cestě ("/") URL něco bylo. Komu slouží
suspectmark.com
succeedscene.com
Neptal bych se kdyby na root cestě ("/") URL něco bylo. Komu slouží
8
Sítě / Ping na NAT
« kdy: 12. 09. 2023, 22:35:10 »
je filozoficky správné, aby šel (cizími lidmi odkudkoli z internetu) "pingnout NAT" ? Nebo jinak vyjádřno "pingnout veřejná adresa někoho skupiny zákazníků jsoucí za daným natem "
Tedy, jestli provider si má nastavit, aby odpovídal jeho edge NAT na pingy z internetu.
(jasně, teoreticky na tom "natu"-jícím pc může běžet ještě SMTP, www server, pokud třeba daný ispíček poskytuje i sdílený hosting, tak teoreticky může Zároveň provozovat NAT pro zákazníky a server najednou a pak by dávalo mít smysl, aby šel pingnout... víte o někom, kdo takhle používá tento double hazard?)
Teoreticky to může obojí provozovat pod jednou IP, když se nebude obtěžovat tedy pro jeden svůj router-pc-server mít odlišné IP pro serverovou a natující část
Tedy, jestli provider si má nastavit, aby odpovídal jeho edge NAT na pingy z internetu.
(jasně, teoreticky na tom "natu"-jícím pc může běžet ještě SMTP, www server, pokud třeba daný ispíček poskytuje i sdílený hosting, tak teoreticky může Zároveň provozovat NAT pro zákazníky a server najednou a pak by dávalo mít smysl, aby šel pingnout... víte o někom, kdo takhle používá tento double hazard?)
Teoreticky to může obojí provozovat pod jednou IP, když se nebude obtěžovat tedy pro jeden svůj router-pc-server mít odlišné IP pro serverovou a natující část
9
/dev/null / AntiCaptcha.NET
« kdy: 06. 09. 2023, 14:06:58 »
Dává smysl mít blacklist katelog podle toho, kdo bojkotuje captcha? (Tzn že v prohlížeči si NEnačítá stránky s captchou)? Vymyslel někdo toto při smyslech? Blokuje ty hnusny javascripty a je po zásluze potrestán.
Existuje nějaká funkční než: AntiCaptcha.NET IPv4 dnsbl.anticaptcha.net ??
Price: 10 BTC
Contact: domain@anticaptcha.net
Existuje nějaká funkční než: AntiCaptcha.NET IPv4 dnsbl.anticaptcha.net ??
Price: 10 BTC
Contact: domain@anticaptcha.net
10
Server / Smysl atributu „darn“ v DKIM
« kdy: 06. 09. 2023, 11:22:01 »
Co značí atribut darn= v DKIM podpisu přichozi zprávy? Prvně viděno 30.8. Je to u mailů odeslaných hostovaných na google a i přímo z @gmail.com
Hodnota je doména příjemce. V případě že mail prvořadě nejde mě, ale někam, kde je mi následně je přeposlán (SRS), je tam samozřejmě doména toho prvního cíle
V rfc 6376 jsem to překvapivě nenašel
Hodnota je doména příjemce. V případě že mail prvořadě nejde mě, ale někam, kde je mi následně je přeposlán (SRS), je tam samozřejmě doména toho prvního cíle
Kód: [Vybrat]
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com;
s=20221208;
t=1693550839;
x=1694155379;
darn=prvotniprijemcemaillistnebomojedomena.czV rfc 6376 jsem to překvapivě nenašel
11
Hardware / Lze z USB-C grabovat? (HDMI Alt Mode)
« kdy: 29. 08. 2023, 12:34:06 »
Dotaz míří k straně počítače či notebooku. Je možné použít USB-C jakožto port, do kterého budou proudit videodata? Na druhé straně by byl HDMI zdroj, na který by se dala redukce HDMI–USB-C. A Jelikož USB-C je full-duplexní port, z logiky věci musí umět i přijímat data. Tím by odpadl problém v následujícím odstavce, že HDMI porty mají obvody dělané na jednosměrný* přenos.
Je pak možné tato data zpracovat? Je to nějak možné? Co by k tomu bylo potřeba? Hádám, že asi víc věcí, nevím jestli na úrovni HW, ale na úrovni driveru asi ano, něco jako dynamické vytvoření pseudo USB zařízení odpovídající vstupnímu zařízení.
Pokud to nejde proč? Co tomu brání
(Doplním: vím, že nejde běžný HDMI výstup na počítači použít jako vstup pro obraz. Ale zajímavější je důvod: že je to prý kvůli TMDS způsobu přenášení, tedy, že elektronické obvody jsou dělané pro výstup signálu a ne pro vstup. (*=S vyjímkou nějakého CEC/Ethernet))
A poddotaz, má Alt Mode A HDMI Alt mode stejné elektrické vlastnosti (hrana, frekvence, kódování, bit stuffing, napětí) jako USB Superspeed Transport a nebo své?
Je pak možné tato data zpracovat? Je to nějak možné? Co by k tomu bylo potřeba? Hádám, že asi víc věcí, nevím jestli na úrovni HW, ale na úrovni driveru asi ano, něco jako dynamické vytvoření pseudo USB zařízení odpovídající vstupnímu zařízení.
Pokud to nejde proč? Co tomu brání
(Doplním: vím, že nejde běžný HDMI výstup na počítači použít jako vstup pro obraz. Ale zajímavější je důvod: že je to prý kvůli TMDS způsobu přenášení, tedy, že elektronické obvody jsou dělané pro výstup signálu a ne pro vstup. (*=S vyjímkou nějakého CEC/Ethernet))
A poddotaz, má Alt Mode A HDMI Alt mode stejné elektrické vlastnosti (hrana, frekvence, kódování, bit stuffing, napětí) jako USB Superspeed Transport a nebo své?
12
Windows a jiné systémy / Nefunkční horizontální posun textu v androidu
« kdy: 18. 07. 2023, 10:24:42 »
Na androidu 11(AOSP) mě štve jedna věc (když nemám poruce BT kbd, což je 90% situací). V (jednořádkovém)adresním řádku prohlížeče, když mám dlouhé url, často potřebuji scrollnout na začátek/konec. Mometální hack je : vybrat vše a použít šipičky (> a <) v řádku softwarových tlačítek (což je funkce , která je défaultně vypnutá a mají ji jen smarthony bez HW spodních tlačítek a dostatečnou fyzickou šířkou LCD. To ale je jedna možnost / způsob Například druhý telefon (s AOSP 10 a SW klávesnicí ) to nemá...
Dál existuje (na můj vkus)pomalý posun: klikne se na nějaký znak a pod ním se objeví "kapička" (ne lásky) a může se táhnout s ní ke straném, ale není to tak rychlé(trvá to třeba 30s u dlouhých URL). Občas se musí "podráždit", že se v průběhu scrollování u levé/pravé strany displeje jako by s ní bleskově zašmrdlá vlevo a vpravo (jako kdyby se to po nějaké době scrollování zadrhlo a třelo to a bylo potřeba vypustit další kapičku oleje, aby zase jelo jak na začátku), ale pak si u takovéhleho způsobu ovládání připadá člověk jak debil u dotykáče.
Jenže taky potřebuju kromě začátek/konec rychlý posun. A tady je paradox na tom druhém telefonu(^) existuje i způsob, kde žádná kapička není,, ale jde rychle a a efektivné posouvat svajpováním . Má to 2 odlišnosti: scrollování je v opačném směru (text se posouvá ve směru pohybu) a připomíná to spíš scrollbar na windows a je to "proporcionální" v tom smyslu, že pravá část=začátek textu, levá část=konec, prostředek inputu=prostředek textu. Jako myšový scrollbar na Windows Me.
Proč taková funkce (nebo další způsob scrollu dlouhých jednořádkových textů)není v vyšší verzi AOSP !?
A jak ji tam přidám. A jak se jmenuje v terminologii AOSP zdrojáku(jsou tam různé kryptické termíny jako SurfaceFinger, toast, activity,verity)
Dál existuje (na můj vkus)pomalý posun: klikne se na nějaký znak a pod ním se objeví "kapička" (ne lásky) a může se táhnout s ní ke straném, ale není to tak rychlé(trvá to třeba 30s u dlouhých URL). Občas se musí "podráždit", že se v průběhu scrollování u levé/pravé strany displeje jako by s ní bleskově zašmrdlá vlevo a vpravo (jako kdyby se to po nějaké době scrollování zadrhlo a třelo to a bylo potřeba vypustit další kapičku oleje, aby zase jelo jak na začátku), ale pak si u takovéhleho způsobu ovládání připadá člověk jak debil u dotykáče.
Jenže taky potřebuju kromě začátek/konec rychlý posun. A tady je paradox na tom druhém telefonu(^) existuje i způsob, kde žádná kapička není,, ale jde rychle a a efektivné posouvat svajpováním . Má to 2 odlišnosti: scrollování je v opačném směru (text se posouvá ve směru pohybu) a připomíná to spíš scrollbar na windows a je to "proporcionální" v tom smyslu, že pravá část=začátek textu, levá část=konec, prostředek inputu=prostředek textu. Jako myšový scrollbar na Windows Me.
Proč taková funkce (nebo další způsob scrollu dlouhých jednořádkových textů)není v vyšší verzi AOSP !?
A jak ji tam přidám. A jak se jmenuje v terminologii AOSP zdrojáku(jsou tam různé kryptické termíny jako SurfaceFinger, toast, activity,verity)
13
Odkladiště / Jak je těžké (najít) EHLO hostname pro útočníka
« kdy: 18. 07. 2023, 10:09:48 »
Dejme tomu, že někdo má (odesílací)SMTP server za NATem (s zelenou na portu25), kde je víc uživatelů. A útočník bude chtít odeslat falešný mail jménem/adresou toho, kdo má regulerní SMTP server tam, tudíž SPF projde. Jedna z "ochran" (o tom prosím nediskutovat,je to v uvozovkách) ostatních příchozích SMTP serverů je, že samozřejmě kontrolují EHLO nazevodesilatele.com, jestli se resolvuje na danou IP odesilatele (v tomto případě IP sdílenou více uživateli, z nichž jeden je regulerní vlastník mailové domény/odesilatel a druhý útočník) . Tím pádem odesilatel má i logicky pro příchozí poštu jiný MX smtp server. A vlastně není jak zjistit z jaké konkrétní domény (smí) odesíla(t) maily. (z IP ano, přece SPF)
Může útočník nějak zjistit/uhádnout, jakým FQDN se regulerní odesílatel hlásí při odesílání pošty?
Moje doměnka je, že není takový způsob. (ledaže by si útočník nechal poslat poštu, ale to vylučuji, nebo by od někoho jiného získal hlavičky mailu) S vyjímkou různých služeb "DNS inteligence", "Passive DNS" - které "shromažďují (i historická" DNS data, jde o veřejné listy, kam útočník může nahlídnout a může zkoušet resolvovat až se/možná trefí/. Jak v praxi tohle je průchozí cesta nebo jde jen o teoretickou možnost?
(za předpokladu, že ví jakou doménu chce fejknout a taky že regulerni odesilatel nemá triviálně uhádnuté FQDN jako {smpt-out,mail,posta,mail}.domena.cz). odesílajícho serveru zdůrazňuji. MX je jiný.
Útočník nemá přístup k infrastruktuře ISP, nemůže odposlouchávat na portu. PTR záznam IP adresy taky nic neřeší, protože ta je třeba 82-2-2-4.cust.....provi...cz
Neřeším, že další ochrany pravděpodobně (ale třeba taky ne) takového útočníka nejspíš utnou.
Může útočník nějak zjistit/uhádnout, jakým FQDN se regulerní odesílatel hlásí při odesílání pošty?
Moje doměnka je, že není takový způsob. (ledaže by si útočník nechal poslat poštu, ale to vylučuji, nebo by od někoho jiného získal hlavičky mailu) S vyjímkou různých služeb "DNS inteligence", "Passive DNS" - které "shromažďují (i historická" DNS data, jde o veřejné listy, kam útočník může nahlídnout a může zkoušet resolvovat až se/možná trefí/. Jak v praxi tohle je průchozí cesta nebo jde jen o teoretickou možnost?
(za předpokladu, že ví jakou doménu chce fejknout a taky že regulerni odesilatel nemá triviálně uhádnuté FQDN jako {smpt-out,mail,posta,mail}.domena.cz). odesílajícho serveru zdůrazňuji. MX je jiný.
Útočník nemá přístup k infrastruktuře ISP, nemůže odposlouchávat na portu. PTR záznam IP adresy taky nic neřeší, protože ta je třeba 82-2-2-4.cust.....provi...cz
Neřeším, že další ochrany pravděpodobně (ale třeba taky ne) takového útočníka nejspíš utnou.
14
Windows a jiné systémy / Mobilní Firefox neukazuje obraz na iVysilání
« kdy: 15. 06. 2023, 14:43:44 »
Zdravím, asi před cca 2 týdny mi přestal jít obraz na ivysílání/ceskatelevize.cz v prohlížeči Fennec pro Android. Ukáže se jenom černá plocha, zvuk jde. Nejde to tedy ani ani nijak na stránce ovládat, musí být štěstí, že stránka iniciuje přehrávání(třeba při kliknutí na "Část pořadu") NEukáže se ani nějaká animace, že se něco načítá, prostě jako kdyby element VIDEO měl height 0
Další VELMI důležité poznámky:
-Nejde to ani na druhém telefonu se stejným browserem.
-V mobilním chrome to jde.
-Nepomohly a/b test parametrů: běžný/anonymní režim, nastavení Autoplay(Allow/Block), Checkbox "Zobrazení pro desktopové prohlížeče"
-Nepomohlo ani vyřazen všech doplňků .
Browser ani android jsem neupdatoval, tudíž na mém zařízení se nic nezměnilo
-Předtím to šlo v pohodě.
-Zkusil jsem v browseru "smazat cache a cookie"
-Zkusil jsem měnit user agenta.(je potřeba být trpělivý až se to projevý)
- V stahovacím menu androidu vidím "aktivní přehrávání", mohu dát (un)pause
-Naprostov klíčová věc: živé vysílání jde i s obrazem. Stejně tak jdou videa na článcích zpravodajství české televize: pohledem jde o stejný přehrávač. Tak proč kurňa u pořadů ne.
Podle mě dost důležité memento je, že zvuk jde. Pokud vím, jednotlivé streamy mají prikládaný zvuk+video. Ano to nevidím na síťovou chybu.
Provedla česká televize za poslední měsíc překodování (nebo dřív ateď překlopila) do AV1 třeba?
Průser je, že nelze ani seeknout, video by se dalo oželet , je přeci válka, tak se uskrovním, Mohu to je v chrome, ale tenhle browser tam mám z nouze, které v mobilním FF nejdou (sem tam problém s viewportem, ovládáním prvků, polofunkční videokonference asi 8 druhů problémů, náhodné pády, chybějící ovládací prvky na pár webech "mimo obrazovku"), jinak je můj primární browser
Bohužel na mobilnim firefoxu nemám žádné diagnostickén nástroje. Z logcat jsem taky nic nevyčetl.(Jednak je to chrlí přehl šel dat při stisku klávesy na BT(nedělám si srandu, nějaké IND_WAKE), klávesnici, přepnutí oken,sjetí lišty...)) za druhé mi nic ani nepadlo do oka,
Pokud najdu nějakou chybu v logcat, dám vědět.
Další VELMI důležité poznámky:
-Nejde to ani na druhém telefonu se stejným browserem.
-V mobilním chrome to jde.
-Nepomohly a/b test parametrů: běžný/anonymní režim, nastavení Autoplay(Allow/Block), Checkbox "Zobrazení pro desktopové prohlížeče"
-Nepomohlo ani vyřazen všech doplňků .
Browser ani android jsem neupdatoval, tudíž na mém zařízení se nic nezměnilo
-Předtím to šlo v pohodě.
-Zkusil jsem v browseru "smazat cache a cookie"
-Zkusil jsem měnit user agenta.(je potřeba být trpělivý až se to projevý)
- V stahovacím menu androidu vidím "aktivní přehrávání", mohu dát (un)pause
-Naprostov klíčová věc: živé vysílání jde i s obrazem. Stejně tak jdou videa na článcích zpravodajství české televize: pohledem jde o stejný přehrávač. Tak proč kurňa u pořadů ne.
Podle mě dost důležité memento je, že zvuk jde. Pokud vím, jednotlivé streamy mají prikládaný zvuk+video. Ano to nevidím na síťovou chybu.
Provedla česká televize za poslední měsíc překodování (nebo dřív ateď překlopila) do AV1 třeba?
Průser je, že nelze ani seeknout, video by se dalo oželet , je přeci válka, tak se uskrovním, Mohu to je v chrome, ale tenhle browser tam mám z nouze, které v mobilním FF nejdou (sem tam problém s viewportem, ovládáním prvků, polofunkční videokonference asi 8 druhů problémů, náhodné pády, chybějící ovládací prvky na pár webech "mimo obrazovku"), jinak je můj primární browser
Bohužel na mobilnim firefoxu nemám žádné diagnostickén nástroje. Z logcat jsem taky nic nevyčetl.(Jednak je to chrlí přehl šel dat při stisku klávesy na BT(nedělám si srandu, nějaké IND_WAKE), klávesnici, přepnutí oken,sjetí lišty...)) za druhé mi nic ani nepadlo do oka,
Pokud najdu nějakou chybu v logcat, dám vědět.
15
Sítě / Dva řádky v conntracku pro jeden flow
« kdy: 14. 06. 2023, 21:04:24 »
Mám VPN na VPS tvořící mi spojení do domácí sítě a některé porty mám forwardované. Use case je například, připojit se na nějaký monitoring , například https://VPS_IP:66443. ( takže DNAT je i DPAT 66443 -> 443 ; oh wait maximum čísla portu je 65535 ale už se mi to nechce přepisovat 
)
A samozřejmě mohu se připojit i když se nacházím v domácí síti, jelikož se připojuji na veřejnou IP adresu, tak provoz jde na adresu vps, a tunelem zpět, kde to router forwardne na určené zařízení. (Takhle mi to nevadí, vedle toho samozřejmě ještě mám bookmark https://TARGET:443 - zjednodušeně)
Mě zajímá, jestli je v pořádku, že v conntrack -L se vynoří dva záznamy. Logicky se nabízí je spojit si je podle společného prvku, což je port.
1. otázka je ,zda conntrack sám ví, že tyto 2 nějak patří spolu
2. existuje nějaká nadstavba conntracku, která "na tohle přijde" a umí seskupit tyto záznamy?
A nebo principiálně tam 2 záznamy musí být ? Prostě že to spojení tam automaticky není? Ani podle stejného čísla portu 52590 se to nedá ztotožnit? (Ano, vím pro soketový pár číslo portu není jednoznačný identifikátor)
zde je výpis conntrack -L | grep 52590 (což je číslo společné portu ) z mašiny, která je brána do internetu. (každý řádek jsem jenom rozdělil na 3 kvůli přehlednosti.)
)
tcp 6 427773 ESTABLISHED
#záznam pro odchozí spojení,
#zároveň přeložené z LAN do WAN
#SNAT(MASQ --to WAN_IP)
src=192.168.1.ZDROJ dst=VPS_IP sport=39149 dport=443
src=VPS_IP dst=WAN_IP sport=443 dport=52590 [ASSURED] mark=0 use=1
tcp 6 427773 ESTABLISHED #
#záznam pro příchozí spojení z tunelu
#není překládáno, správný routing je přes mark
src=EXT_IP dst=192.168.2.TARGET sport=52590 dport=66443
src=192.168.2.TARGET dst=EXT_IP sport=66443 dport=52590 [ASSURED] mark=9911 use=1
význam proměnných:
WAN_IP... je adresa routeru na rozhraní do internetu, která je následně ještě jednou (kdoví jestli jen)přeložena na EXT_IP( což je "internetová adresa zdroje" v terminologii neboveřejná adresa, která ale není veřejná,jinak bych nepotřeboval tunel)
VPS_IP ...veřejná VPS (druhý konec tunelu)
192.168. adresy zařízení ve vnitřní síti (je jich víc)
)A samozřejmě mohu se připojit i když se nacházím v domácí síti, jelikož se připojuji na veřejnou IP adresu, tak provoz jde na adresu vps, a tunelem zpět, kde to router forwardne na určené zařízení. (Takhle mi to nevadí, vedle toho samozřejmě ještě mám bookmark https://TARGET:443 - zjednodušeně)
Mě zajímá, jestli je v pořádku, že v conntrack -L se vynoří dva záznamy. Logicky se nabízí je spojit si je podle společného prvku, což je port.
1. otázka je ,zda conntrack sám ví, že tyto 2 nějak patří spolu
2. existuje nějaká nadstavba conntracku, která "na tohle přijde" a umí seskupit tyto záznamy?
A nebo principiálně tam 2 záznamy musí být ? Prostě že to spojení tam automaticky není? Ani podle stejného čísla portu 52590 se to nedá ztotožnit? (Ano, vím pro soketový pár číslo portu není jednoznačný identifikátor)
zde je výpis conntrack -L | grep 52590 (což je číslo společné portu ) z mašiny, která je brána do internetu. (každý řádek jsem jenom rozdělil na 3 kvůli přehlednosti.)
)
tcp 6 427773 ESTABLISHED
#záznam pro odchozí spojení,
#zároveň přeložené z LAN do WAN
#SNAT(MASQ --to WAN_IP)
src=192.168.1.ZDROJ dst=VPS_IP sport=39149 dport=443
src=VPS_IP dst=WAN_IP sport=443 dport=52590 [ASSURED] mark=0 use=1
tcp 6 427773 ESTABLISHED #
#záznam pro příchozí spojení z tunelu
#není překládáno, správný routing je přes mark
src=EXT_IP dst=192.168.2.TARGET sport=52590 dport=66443
src=192.168.2.TARGET dst=EXT_IP sport=66443 dport=52590 [ASSURED] mark=9911 use=1
význam proměnných:
WAN_IP... je adresa routeru na rozhraní do internetu, která je následně ještě jednou (kdoví jestli jen)přeložena na EXT_IP( což je "internetová adresa zdroje" v terminologii nebo
VPS_IP ...veřejná VPS (druhý konec tunelu)
192.168. adresy zařízení ve vnitřní síti (je jich víc)
