Příspěvky

76

Sítě / Re:Nadstavba ping - určení směru neprostupnosti

« kdy: 19. 04. 2020, 23:27:12 »

Nemyslím případ kdy je packet loss 100%,...
On to reply  může poslat a přijde, ale ne vždy.  Prostě síť má nějakou ztrátovost a jednou za čas odpověď na aktuální paket  určitě dorazí. Musela by tam být nějaká výměna informací v tom smyslu, že by to reply i obsahovala nějakou historii, která čísla requestů (ne)přišly )a případně (volitelně čas od času by v echo bylo něco jako potvrzení, že se reply s reporty vrátila, aby si cíl mohl vypláchnout buffer reportů).  Přece máme TCP...

77

Sítě / Nadstavba ping - určení směru neprostupnosti

« kdy: 19. 04. 2020, 15:10:31 »

Pokus se nepletu, ping zkoumá zda prostě dorazila odpověď na každý ICMP paket zvlášť. Ale pokud REPLY nedorazí, nedá se z toho zjistit, zda k cíli vůbec REQUEST se dostal. Neexistuje nějaká "nadstavba" ping (nebo uplně jiný nástroj), která by tohle řešila? Aby z toho šlo kromě dvou stavů  Odpověděl/Loss Rozlišit i třetí případ -podmnožinu Loss, <kdy nedorazil ani Požadavek >a kdy <nedorazila jenom Reply>.

Asi to nebude pochopitelně na bázi ICMP (ledaže by se to nějak zapouzřilo do textu paketu a číslo sekvence)

78

Software / Re:Proč není výstup příkazů přes watch barevný?

« kdy: 18. 04. 2020, 11:09:52 »

OK, isatty.

79

/dev/null / Re:Podrobnosti o útocích na české nemocnice

« kdy: 18. 04. 2020, 11:04:54 »

Zajímavá teorie, ale stejně tak může být pomsta za digitální daň (nejsem zaujatý, ale prostě mě to napadlo). Naopak je vyloučen čínský vítr, tam teď je  sonda zaražená hodně hluboko.
Ví se co to bylo za nemocnice, například nemocnice v okolí Petra novotného, řeporyjí atd..?

80

/dev/null / Re:Podrobnosti o útocích na české nemocnice

« kdy: 18. 04. 2020, 09:45:50 »

Aha,on byla nějaká nehoda? Já jen ve zprávách četl, že ŇEKŇÚB varuje před nějakými útoky. Tak mi bylo divné proč ti čučkaři straší nebo jestli něco tuší a nebo i ví.

81

Software / Re:Chromium na YouTube přehrává VP9 i přes doplněk h264-ify

« kdy: 18. 04. 2020, 08:50:22 »

Tak jsem zjistil, že jsem měl blokované cookies na youtube a po povolení problém zmizel. Vážně by mě ale zajímalo, jakou to s tím má spojitost...
https://greasyfork.org/en/scripts/8128-youtube-h-264/code
Kod prakticky jen prepisuje funkci  vracejici podporu podpory kodeku, že při argumentu vp9/webM/vp8 vrátí nic, jinak výsledek původní funkce

Kód: [Vybrat]

origFn=prepisovany.fn
prepisovany.fn=(type)=>{
  if(type=="wp9") return '';
  return origFn.fn;
}

82

Software / Re:youtube:Chromium přehrává VP9 ačkoli h264-ify

« kdy: 17. 04. 2020, 22:36:56 »

Samozřejmě že ty mraky vidí co jsem teď přehrál, minimálně 50% má h264 a každé hrálo v VP9.

Zajímalo by mě co se děje na pozadí, jestli h264ify selhal ?

Samozřejmě když otevřu file:///~ukazka.AVC.mp4, tak to browser přehraje (a je mi jedno zda s akcelerací nebo ne.)

83

Software / Proč není výstup příkazů přes watch barevný?

« kdy: 17. 04. 2020, 22:29:02 »

Pokud pustím příkaz iostat , automaticky ho mám v barvách. Pokud si chci pustit přes watch (šikovná  věc na periodické sledování výstupu příkazu), proč musí explicitně  být zadaná proměnná  pro zapnutí barev  (před či po)? (Týká se i příkazu ls, běžně vypisuje barevně, ale přes watch to musí být watch -c ls --color)

Kód: [Vybrat]

watch -c S_COLORS=always iostat 
S_COLORS=always watch -c  iostat 

Podle mě je tam nějaká zvláštní magie jako zjišťování parametrů terminálu (takové ty věci jako že výstup utility htop se přizpůsobí oknu). Napadla mě ještě jiná příčina a sice výchozí proměnné prostředí, které se nepředávají do subshellu.... Co z toho to je?


PS: co znamená "double buffered" IO příkazů (údajně watch, může způsobovat "blikání" ale věřím že to nemá níc společného s VSYNC a double bufferingem u grafických karet

84

Software / Chromium na YouTube přehrává VP9 i přes doplněk h264-ify

« kdy: 17. 04. 2020, 21:19:11 »

Dobrý den, mám Chromium 78 a pravděpodobně po smazání /usr/lib/chromium-browser/libpepflashplayer.so  mi youtube videa videa chodí v VP9 (itag 243, vp09). Doplněk h264ify už  aleakchihdccplidncghkekgioiakgal mám dávno. Flash v prohlížeči nehci. Zároveň to chci přehrávat přes h264, protože je méně náročný (především v situaci kdynemám hw dekodér).

Kde je problém, proč to nehraje ?

85

Sítě / Re:Dotazy k wifi (různé "MAC" adresy) , beacon,probe na všech kanálech?

« kdy: 15. 04. 2020, 23:07:13 »

kde/jak vstupuje ramec do zpracovani

to by mě právě zajímalo.  Mám prostě pocit, že pokud běžnou "Ethernetovou" komunikaci, tak to využívá  navíc i tu druhou adresu :24, ale pokud jde o servisní (probe,response, autentizace),pak pouze první :20..

ze chodi spravene management ARP paketu.

Co by se mělo na ARP paketech managovat? Tím ARP jsem to zabil. Obrat jsem jen použil,abych získal MAC adresu protistrany(routeru). Stejný výsledek bych(jsem nyní)  získal sniffováním na wlan0 (a v běžném, ne monitor modu)

Klienti asociovani k AP pokud se nepletu vzdy komunikuji skrze toto AP, nikoliv naprimo - proto je tam ta druha(treti) MAC adresa.

Ano, klient  STA s klientem STA vždy přes AP. Jenže tady jsem komunikoval já (STA)s bránou (routerem, AP). (oběma směry).
Možná to nějak souvisí s poli To DS a From DS. Ale nevím důvod proč Router používá druhou adresu *, jako kdyby simuloval WDS (až na to, že nedistribuuje bezdrátovému repeateru ale internímu switchi dokonce v té samé krabičce)
(Ne uplně jim rozumím). Co vlastně zkratka DS znamená?Distribution system? Jako vím, že 0,0 je přímá komunikace. Pak by to dávalo smysl, že i když komunikace mezi AP a STA je svým způsobem přímá (chápáno na úrovni IP), ale Hodnoty jsou 0,1 nebo 1,0.


* FIlozoficky, která adresa je správná (první) a která ta "druhá navíc"?
 :20 :BSS ID, Transmiter ze směru od AP/Receiver při směru k AP) ... i tedy se to dá nazvat adresa na WLAN vrstvě (identifikátor BSSID)
 :24 :Source ze směru od AP/Destination při směru k AP),  MAC routeru na linkové vrstvě bez monitor modu ,, pravděpodobně shodou okolností ( ) MAC routeru při připojení kabelem,  ...tedy i se dá nazvat adresa na linkové vrstvě Ethernet (pokud monitor mode vynecháme, tak vidíme jen tuto)

==> A proč by nemohly být identické obě?
(na 5GHz) si myslím, že to tak je (jediná doměnka, že admin rozhraní hlásí wlan 5GHz mac:24), ale nemohu otestovat

86

Sítě / Dotazy k wifi (různé "MAC" adresy) , beacon,probe na všech kanálech?

« kdy: 15. 04. 2020, 19:20:33 »

Měl bych dotaz k wifi... Mám accesspoint a všiml jsem si  ('jiným strojem  s kartou monitor modu) jednak při zobrazení stavu ale i při probíhající komunikaci  v odlišnosti MAC Adres a  hodnot fyzických adres 802.11 protokolu  . Vím, že Ethernetovým adresám nemusí odpovídat na 100%, například u ad hoc jsou částečně náhodné. Dotaz je , proč Accesspoint v komunikaci (při příjmu i posílání) vystupuje  v jednom paketu (tedy ne v čase) dvěma bezdrátovými adresami (neboli fyzickými adresami, ale ne uplně přesně mac adresami)". Vím, že Wifi 802.11 to tak má specifikované, že pakety mají 3 adresy (v případě to DS+ from DS 1 i čtyry). Ale proč v jednoduché situaci, když komunikuje klient přímo s AP (bránou) bez prostředníka (WDS,extender).





arp příkaz vrací MAC adresu pro bránu , ke které jsem připojený přes wifi ...:77::24
administrační rozhraní routeru zobrazuje  Jako mac adresu pro 2.4Ghz wifinu ...:77::20
administrační rozhraní routeru jako mac adresu pro 5GHz: ...:77::24 (ale tu nikdo nevyužívá a nikdo k není připojen)
administrační rozhraní routeru zobrazuje LAN MAC Addr : ...:77::24
mac adresa routru na  při připojení kabelem na GbEth je ...:77::24
datové Wifi pakety od AP k station mají Transmitter Address(= BSS ID) ...:77::20, ale source address ...:77::24
datové wifi pakety od station k AP  mají  Receiver address (= BSS ID) ...:77::20, ale Destination ...:77::24
Probe response k STA má BSS ID pole shodné s Source (= Transmitter) ...:77::20 (tzn že ...:77::20 je tam 2x)
jen pro informaci, hodnoty v závorce(=) znamená že jde o jednu stále strejné místo v paketu i když wireshark pro něj má více polí (ale záleží na situaci, takže Bss ID  někdy je Transmitter a někdy receiver)
vyslané Beacony a přijaté ACK pakety mají ...:77::20
Broadcastové pakety s Wifi adresou spanning tree mají  obě adresy ...:77::20
Neexistují pakety, které by se obešly bez ...:77::20 adresy., naopak pakety bez ...:77::24 existují (výše např, beacon, ack, broadcast )
žádné extendéry, repeatery, zesilovače a podobné haraburdí nepoužívám


Z jakého důvodu tedy se používají 2 různé fyzické adresy lišící se jen rozdílem 4? Teď
Klíčová je podle mě vztah LAN adresa ...:77::24, proč ale "WLAN MAC"(spíš správněji bezdrátová adresa) je pro 2.4Ghz ...:77::20 a pro 5Ghz ...:77::24 . Dělá to rozdíl nesrovnalost mezi 2.4Ghz (jiná WLAN MAC) a 5GHz (obě stejné)



Druhý dotaz je k frekvenčnímu obsazení: datová komunikace probíhá na jednom kanále. (z pozorování, asi tam dynamické střídání kanálu nebude). Ale když při v běžícím wiresharku na odposlechové kartě dám   sudo iwconfig wlan1   channel N, tak beacony vidím od všech sítí stejně , nezávisle na kanále. Opravdu to tak je? Nemůže to být bug v toolkitu/driveru, že karta špatně reportuje nastavený kanál (a nebo trvá dobu než se přepne ale už to hlásí jiné číslo naopak)? Nebo mi nějaký program mění kanály (network manager jsem nevypl, jen  'if down, iw set mode monitor, ip link up')

S tím souvisí, jak probíhá scanování mac sítí (prostě to, když si na telefonu dám výběr sítě.) Projíždí to všechny (kanály)?

87

/dev/null / Poštovní server - nutné něco kolem DNS(MX) řešit u ISP

« kdy: 13. 04. 2020, 15:31:27 »

Zdravíčko, pokud bych chtěl mít  "mail" (pravděpodobně mailserver, nevím co dalšího ještě je, různé relay, remailer...) na svém PC připojený přes daného USP, je potřeba nějak řešit DNS a MX záznamy nebo se to obejde i bez toho?


Lze vůbec používat e-mailové služby bez systému doménových jmen (že příjemce uvidí blahlo@1.2.88.22)? A nebo to jde nějak na polovičatě (že provider asi nedovolí měnit DNS) ,ale že bych si DNS rozjel sám. MJ. bude to mít nějaký efekt?


A jako dodatek, nebude problém s doručitelností? Existuje spousta technologií DKIM,DMARC,SPF, certifikáty atd...

PS: Teď nemyslím využívat ty mailservery ,jak uvádí každý provider (smtp.o2.cz, smtp.wifinar.cz), i když to s dotazem takdy souvisí

V e-mailu nemám hluboké znalosti, hlavně co se týče  těch ověřovacích technologií

88

Sítě / Re:traceroute - jak vlastně funguje, proč pomalé

« kdy: 13. 04. 2020, 14:37:36 »

Tak princip už jsem se dozvěděl. Routery po cest (uzly) spolu nijak nekooperují, vše jde ode mně. Pomocí -d jsem měl vyplé DNS vyzvídání.

Dál jsem se dozvěděl, že některé uzly neodpovídají, protože prostě mají  ICMP vyplé (ale může být i UDP/TCP tracert na unixu) a hlavně z důvodu obavy o prozrazení topologie.infrastruktury. Mohou i některé sítě či routery s TTL  manipulovat jinak než dekremenatcí (to zní jak defekací) že nějak budou švindlovat? Například na základě cíle/zdroje/zátěže nebo jiné situace? Děje se to? Z jakých důvodů?

Některé směrovače zobrazují chybovou zprávu „timeout“, protože je pravděpodobné, že budou mít na svých počítačích omezený dohled, protože je součástí vnitřní sítě operátora.

To jsem se dočetl na nějakém špatně přelozeném webu.
To je něco jiného, než to předtím? Jestli tomu kvazipřekladu rozumím, tak tím myslí, že v síti nějaké organizace (operátora,datacentra atd)  jsou  pro okolní svět "routery uvnitř schované", tzn. že nejenže neodpovídají na pingECHO, ale ani nesnižují TTL kolikrát by odpovídalo reálnému počtu  routerů tam (ale třeba jen 2x). To se také děje? (Z důvodu výše - vyzrazení nebo optimalizace)

89

Sítě / traceroute - jak vlastně funguje, proč pomalé

« kdy: 13. 04. 2020, 10:54:21 »

Když zadám traceroute, občas se hodně načekám. Hlavně se to třeba na 10 s zasekne někde (samozřejmě k cíli se normálně připojím). To se děje proč (jiný důvod než neodpovídání na ping)? Ono to není extrarychlé (například po půl sekundě) i na řádcích u kterých to ukazuje 30ms. Za další, ty hodnoty jsou ekvivalent pingu  a jsou vždy inkrementální(součet předchozích) a nebo jen pro daný hop ?

Jak vlastně funguje tracert? je to ICMP? Jak se můj PC dozví IP adresy meziuzlů? Pokud bych si pustil wireshark, to co uvidím, je vše (veškeré kroky vycházejí z mého PC) a nebo součástí "Trasování" je i komunikace mezi ostatními uzly (že třetí hop v cestě sám  až dostane impuls, sám začne komunikovat s pátým, čvtrým, posledním(cíl) nebo mnou)?

90

/dev/null / Proč jsou tyto blogy tak nenažrané? 500MB

« kdy: 13. 04. 2020, 10:23:00 »

proč blogy uplně zahltí prohlížeč chrome? Vezmou si 500 MB RAM. NA 3 sekundy zamrzne prohlížeč.Je to podle mě taková wordpressová zplácanina. ale podle mě tam jsou nějak blbě optimalizované obrázky či cool pluginy na skrollování, instagram nebo tak.  I přesto že blokátorem zablokované stránky 3.stran (zde i youtube) ale ne první stránky. Po zablokování všech skriptů už je web "responzivní" (nežere prostředky ), ale nedá se číst (rozbitý layout)

Kód: [Vybrat]

seznam  skriptů  co se snaží načíst(po zablokování všech skritpů, to znamená, že kdybych je neblokoval, kaskádově by se načetlo víc ještě)
wp-content/:
plugins/akismet/_inc/form.js
/plugins/instagram-feed/js/sb-instagram.min.js
/plugins/themify-portfolio-post/themes/stack/js/scripts.js
/themes/themify-shoppe/js/jquery.smartresize.min.js
/themes/themify-shoppe/js/themify.script.min.js
/themes/themify-shoppe/themify/js/main.min.js
/themes/themify-shoppe/themify/js/themify.sidemenu.min.js

wp-includes/js:
comment-reply.min.js
js/imagesloaded.min.js
js/jquery/jquery-migrate.min.js
js/jquery/jquery.js
js/jquery/jquery.masonry.min.js
js/masonry.min.js
js/wp-embed.min.js

weefworld.eu
flabgee.cz