Příspěvky

61

Software / Je možné získat text dříve vypsaný do reálné konzole

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

Na linuxu jsem přžihlášen do konzolí na Ctrl Alt FN (doufám, že se nazývá virtuální, a je to konzole nebo terminál?). Na jedné z nich se mi vypsal zajímavý text. Chtěl bych ho uložit jiným způsobem než ofocením obrazovky nebo děláním prinstrceenu (jde to vůbec?). Chápu, že to není emulátor terminálu, kde si mohu dělat co chci.

Samozřejmě jsem s tím dopředu nepočítal, takže bych ten text chtěl získat zpětně, po té, co už je vypsaný.
- Pokud to jde, je možné vypsat který už je "nad obrazovkou" (ten záznamy byl delší, takž odscrolloval).


o /sys/class/tty vím. O /dev/ttyN také (mohu z ní číst přes cat)

62

Server / Re:Double SSH tunelling

« kdy: 21. 04. 2020, 16:56:37 »

VýživNapěchovaný článek o využití nc:
https://miloserdov.org/?p=2826
v dolní polovině se píše o příkladu s SQL (keyword 3306

63

Hardware / Re:Jednoduchá "krabička" pre videohovor

« kdy: 21. 04. 2020, 16:51:54 »

sim karta - předplacená T-mobile za 500Kč 1GB měsíčně
- levný bazarový 4G tablet
-

Co vás k tomuto masochismu vedlo? To jste nenašel nic levnějšího? Nebo je datový průtok >1GB? dají se najít 1GB za 150Kč měsíčně

64

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...

65

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)

66

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

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

OK, isatty.

67

/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..?

68

/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í.

69

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;
}


70

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.)

71

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

72

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 ?

73

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

74

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)?

75

/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í