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.


Příspěvky - mikesznovu

Stran: 1 ... 5 6 [7] 8 9 ... 29
91
Hardware / Re: Zamrzne asi z jiné příčiny, sleep nebyl
« kdy: 06. 02. 2023, 14:40:41 »
Tak teď tomu fakt nerozumím. Nechal jsem ho běžet.  Zapnu monitor(ve vypnutém stavu  USB hub monitoru jako kdyby neexistoval), vidím hýbat se spořič. ťuknu na klávesu nebo stisknu myš aby se spořič  spakoval a obraz zmizí ->černá obrazovka (Nemusí nutně znamenat že příčinou bylo ťuknutí na tu klávesu, mohlo to klidně být samotné zapnutí monitoru)
... Nereaguje na pingpakety (umím si ručně vstříknout záznam  do ip neigh ip lladr dev xxx  nebo L2 broadcast), síťovka jen svítí oranžově, neblikne když přichází pakety. Nereaguje ani na krátký stisk vypínacího čudlu...


Ubuntu MATE tam je nějaké LTS, tuším 18 nebo 21.



do spánku jsem ho nedával, jen jsem vypnul switch(abych nešoupával konektory :D ) a monitor. Jediné co v něm bylo zapojené je barrel napájecí konektor, HDMI,eth kabel do vypnutého switche a USB kabel do USB hubu v monitoru (downstream: myš a klávesnice)

Snad asi jediné co zbývá je UART...

92
Sítě / Může switch nebo router spojovat fragmenty TCP?
« kdy: 06. 02. 2023, 00:37:35 »
TLDR: to sítě vstupují IP  pakety o délce 576, ale na počítač jdou o délce 576,1110,1624,2148 a 2672. matematicky to sedí, stačí odečíst 20, odečíst 32 a vydělit 524.

Všiml jsem si zvláštní věci, jde o normální DASH video přes HTTPS přes port 443-TCP přes IPv4, z české televize, které občas dělá problémy (někdy se přehrávání   webu zadrhne- pozoruji, že to je skoro vždy když  příchozí IP pakety o délce výhradně 576b chodí až do stroje, ale o tom to dnes nebude  ). přehrávalo se to teď ne na webu, ale v přehrávači videí, a všiml jsem si ,že conntrack na bráně ukazoval  350 řádků spojení k romuto serveru, ale nethogs, že aktivních jich bylo tak 10 (mezi 10 a 180 kB/s).
Síť: (wifi)brána(ethernet) ---  (ethernet)Wifi-AP(br0:wifi+eth) --- switch --- počítače

brána je RPi, wifi-ap je tzv. wifirouterkombo, už několik let staré, ale relativně vyšší střední třída s Gigabit porty, DSLWAN(deaktivovaným) a switch je  takový nejlevnější gigový 4portový .

Příchozí rámce  do brány mají délku 590b (14+20+32+ 524)b, bez těch 14 to je těch 576.
Poznámka TCP má hlavičku 32 b oproti normální 20 (ecn,ecr+padding).
Odchozí rámce z brány taky.
Příchozí rámce do počítače jsou modifikované, je to spektrum paketů o asi 5 vellikostech a nejpodivnější na tom je, že má i velikost přesahující 1500b.

Trochu ve stínu zustal wifi ap router, vše je zapojeno v LAN portech. Má sice programy ip, jádro 2.6 z roku 2016(?nesoulad), ale prihlašuju se na něj přes telnet. Nemá binárku conntrack, ale  shell sh a  příkaz cat /proc/net/nf_conntrack
 hlásí jen spojení na telnetu, takže se dá předpokládat že jenom bridguje. kromě toho iptables -L {nat,mangle,filter,raw} nic moc, mangle prázdný, raw neexistuje, nat prázdný . filter má nulové čítače kromě inputu. a input  má jen 24 MB dat na -i bridge -j ACCEPT a to asi taky nic není, takže asi jenom fakt bridguje ....

SWITCH:
Předpokládám, že stále platí, že switch maximálně ví, že podle ethertype to jsou IP pakety ale dál s nimi nic nedělá, o IP vrstvu, natož TCP se nestará . Je to hloupý switch bez managementu.

WIRESHARK:
Snad ani wireshark nedělá žádnou magii v prezentaci paketů. Nikde nemám nic jako  záložky Packet / reassembled frame,  ani. IP pakety nejsou fragmentované


Pakety jsem sniffoval přes wireshark, ale sekvenčně pokaždé na jiném konci. (Ideální by bylo souběžně na rozhraní any na všech prvcích.... :) a zkorelovat je, ale nejsem CSIRT )
Kromě toho je tam nějak modifikované WIN size u na vstupuju bylo něco kolem 500-650 ale u těch modifikovnaných na stanici je10880 .

Proč k některým zdrojům dojde v původní podobě  (jen 576)?
Druhá zvláštnost je MTU.... jakko kdyby neexistovalo., koncová stanice, brána mají v ip address uvedené MTU 1500, router taky(u bridge,eth i wifi)
na jakém prvku dochází k té změně?
Není to třeba tcp offloading, který právě tcpdump nemá šanci zachytit?

Někd nějaké nápady, jak zjistit, co a kde se děje?

93
Hardware / Re:Může uspání jader CPU způsobit problém?
« kdy: 05. 02. 2023, 21:14:07 »
Odhaluju příčinu zamrznutí  (od uspání uběhlo 12 hodin) a  napadlo mě co když ty cpu  offline je recept na takovýhle neprobuzení.
Stalo se mi totiž že uspaný SBC se neprobral, bohužel nezjistim proč a v jakym byl stavu. Probudit nešel, monitor hlásil no signal, ale síťovka blikla při paketu.
Mám podezření že k probuzení došlo ale z nějakého důvodu zatuhl těsně po probuzení .
Pokud by došlo k selhání (výpadku) napájení,, nalezl bych ho spuštěný, reagoval by na ping.

Takhle jsem ho nalezl v stavu, , JAKO když ho vypnu(softwarově nebo podržením čudlu)
Ale zároveň je možné, že byl spuštěný, jelikož připojená wifikarta blikala., taky byl pasivní chladič míírně teplý(ale stav běhu bych podle toho určil s hodně níkzou jistotou)

v journalctl --file jsem vyšťoural že uspaný byl  OK (i když je místo, kde se mohou vci po**rat když kernel  usne, ještě může dělat něco firmware)
Kód: [Vybrat]
find /var/log/journal -type  f   -exec bash -c 'echo  $(journalctl  --file  {} |wc -l)   {} ;' ";"

PM: suspend entry(deep)
ale už jsem nenašel nic potom (pm suspend exit)
 


Takže nevím... vím,že jsem předtim asi4/8 dal offline.

ale:
Tak já jsem to zkoušel (asi 4x, ruzne kombinace) a pokaždé se probral.... takže tím to nebude

A nebo je možné, že byl v nějakém metastavu to se taky vzácně může stát ()

94
Software / Re:Firefox nefunguje po aktualizaci rozšíření
« kdy: 05. 02. 2023, 19:51:22 »
Pokud nevyhovuje firefox, můžete používat operu, nebo chrome.
chromý na androidu neumí ANI rozšíření !!! Když už tak Bromite nebo iodine nebo co já vím s kolika chemickými prvky se dá serfovat na na androidu
Firefox právě vyhovuje možností nastavení, ale vázne stabilita a pak takovéhle průsery


Každopádně díky f

95
Vývoj / Re:Náhrada \K v regexp za assertion (.(?<!^www\.))+$
« kdy: 05. 02. 2023, 19:37:33 »
díky za snahu, ale asi jste to netestovali, neboť to označí celé řádky. To co obarvují ty online nástroje hodně barvičkama ve skutečnosti jsou matching groups asi jste si mysleli, že když to vyznačí jednotlivé skupiny je vyhráno... což by stačilo v případě dalšího zpracování preg_match ... $match[2] (0...celý, jednička případné www., dvojka to co hledám),,, jenže právě to jsem na začátku upozorǚnoval že to má být čistě  vyznačený řetězec shody

TLDR správně je (.(?<!^www\.))+$, ale mám  mírný pocit, že je to z hlediska výkonnosti neefektivní
(a krásné na tom je, že pouhá přítomnost toho znaku stříška ^ ovlivňuje jestli to funguje jen na počáteční www., nebo na poslední www. (což ale není uplně košér, cokoli.www.tamto by mělo pobrat celé, ale www.www.tamto  jsou zapeklité testovací řetězce ,ale lookbehind (?<!(www.)+) je zakázané)

Zkusil jsem  1.
(www\.)?(\S+(\.\S+)?)
i označí od začátku tedy i s www : (

2:
Tak  radu FKoudelky jsem zkusil, nevím-jaký výraz jsem převedl na cat testfile.txt  | grep --color -Pi '^(?:www\.)?(.+?)$' a už od pohledu se mi zdá, že to bode blbost, jelikož  začíná ^, že matchne uplně celý řádek od začátku včetně www a taky že jo, . Zkusil jsem ubrat počáteční ^  a nic. A tuším,



https://regex101.com/r/TejAZp/1

PS: díky i za všimnutí "www." s tečkou, nechtěl jsem to komplikovat

Dopracoval jsem se teď k tomuhle výrazu : ((?<!^www\.).)+$, ale máte tušení proč do shody nezapočte i první znak  za www.?

www.fo.lk
hsa.dk
www.www.doublew

Dá se to řešit i pomocí .(?<!^www\.).)+$, což ale vyřadí uplně z shody www.a, www.b ... je to takové nesystémový hack i když use case pro www.z je nesmysl

Tohle je již správné : (.(?<!^www\.))+$ ( přesun tečky v první závorce na začátek assertion



www.fo.lk
hsa.dk
www.www.doublew
www.o
h
www.kdwk.www.jkjlk.www.kldssaskld
www.www.kdwk.www.jkjlk.www.kldssaskld
www.www.sad.www.sad.www.kdwkjkjlk.www.kldssaskld
www.www.www.sad.www.sad.www.kdwkjkjlk.www.kldssaskld
sad.www.sad.www.kdwkjkjlk.www.kldssaskld

96
Hardware / Může uspání jader CPU způsobit problém?
« kdy: 05. 02. 2023, 18:52:57 »
Máte někdo zkušenost, že by příkaz vypnutí  jednoho nebo několika CPU v linuxu
   přes

Kód: [Vybrat]
echo 0 | sudo tee /sys/devices/system/cpu/cpu#/online

mohl po uspání do RAM a následném probuzení způsobit problém že se se něco pokazí? myslím tím třeba zatuhnutí  při uspání, při probuzení, samo-reset, nebo že se prostě zasekne a vypne (při sleep nebo probuzení)

97
Sítě / Re:v jednom směru jde ipv6 ping jen s suffixem %wlan0
« kdy: 05. 02. 2023, 00:06:22 »
Jenom pro uvedení na pravou míru:
Jako rozumím, u link local adres vse [urléhttps://stackoverflow.com/questions/45795554/avoid-specifying-interface-when-using-ipv6-address]prý má rozhraní uvádět když [/url]to píšou (ale na druhou stranou mám o tom trochu pochybnosti)
Ale je mi divné, proč to jednou jde bez(vyjímka potvrzující stackoverflow) a jednou nejde bez. čím to tedy je? Souvisí to  s tím ,že v jednom případě ipv6 adresa vychází z mac a v dhuhém nevychází?

98
Sítě / V jednom směru jde IPv6 ping jen s %wlan0
« kdy: 04. 02. 2023, 23:54:24 »
Vše podstatné jsem se sznažil vměstnat do názvu. Mám 2 počítače spojené switchem (technicky jeden přes ethernet, druhý přes wifi, ale je "wifi router" to bridguje ), oba link local adresy. Z žádného rozhraní neodejdou žádné pakety

Problém je ,ten, že ping na ipv6 adresu u z druhého na první jde jen  uvedení -I wlan0 nebo %wlan0 za adresou? (I když  chvíli dřív jsem měl pocit, že -I wlan0 taky nefunfovalo)
Proč?
(Chápal bych to třeba obráceně, z  počítače, který má těch rozhraní hafo a ne z tohoto který má jedno)

Situace je symetrická až na  trošku jiný tvar ip adres. a počet rozhraní každého pc., a způsobu "setupu" a taky že v výpisu ip se ukazuje noprefixroute(nevím co to znamená a jestli to něčemu vadí) a u druhého ne
tady jsou výpisy, slovní popis jsem dal do citace(je to ukecané)

Kód: [Vybrat]
#druhý:
#druhá půlka ipv6 je skoro mac adresa#
ip -6 a show wlan0 ## druhý
4: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet6 fe80::8737:b5ee:87f4:9caa/64 scope link !!!! noprefixroute !!!!
       valid_lft forever preferred_lft forever
ip neigh
fe80::bbbb:bbff:fe5d:3333 dev wlan0 lladdr b9:bb:bb:5d:33:33 DELAY

## první
#mac adresa a ipv6 nemají nic sp lečného
ip -6 a show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 fe80::baaa:aaff:fe5d:3333/64 scope link
       valid_lft forever preferred_lft forever
ip neigh
fe80::8737:b5ee:87f4:9caa dev eth0 lladdr 00:1f:cf:51:a4:30 DELAY

Ping:
Kód: [Vybrat]
první na druhý, není potřeba %wlan0 ani -Iwlan0
ping fe80::8737:b5ee:87f4:9caa
PING fe80::8737:b5ee:87f4:9caa(fe80::8737:b5ee:87f4:9caa) 56 data bytes
64 bytes from fe80::8737:b5ee:87f4:9caa%eth0: icmp_seq=1 ttl=64 time=2.02 ms
64 bytes from fe80::8737:b5ee:87f4:9caa%eth0: icmp_seq=2 ttl=64 time=2.02 ms
64 bytes from fe80::8737:b5ee:87f4:9caa%eth0: icmp_seq=3 ttl=64 time=2.10 ms

druhý-první
ping  fe80::babb:bbff:fe5d:3333
PING fe80::babb:Bbff:fe5d:3333(fe80::bbbb:bbff:fe5d:3333) 56 data bytes
^C
--- fe80::babb:bbff:fe5d:3333 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1022ms

ping  fe80::bbbb:bbff:fe5d:3333 -I wlan0
ping: Warning: source address might be selected on device other than: wlan0
PING fe80::bbbb:bbff:fe5d:3333(fe80::ba27:bbff:fe5d:3333) from :: wlan0: 56 data bytes
64 bytes from fe80::bbbb:bbff:fe5d:3333%wlan0: icmp_seq=1 ttl=64 time=10.2 ms
64 bytes from fe80::bbbb:bbff:fe5d:3333%wlan0: icmp_seq=2 ttl=64 time=2.56 ms
64 bytes from fe80::bbbb:bbff:fe5d:3333%wlan0: icmp_seq=3 ttl=64 time=8.17 ms
^C
--- fe80::bbbb:bbff:fe5d:3333 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms

ping  fe80::bbbb:bbff:fe5d:3333%wlan0
PING fe80::bbbb:bbff:fe5d:3333%wlan0(bbbb:bbff:fe5d:3333 %wlan0) 56 data bytes
64 bytes from fe80::bbbb:bbff:fe5d:3333 %wlan0: icmp_seq=1 ttl=64 time=9.07 ms
64 bytes from fe80::bbbb:bbff:fe5d:3333 %wlan0: icmp_seq=2 ttl=64 time=7.44 ms

první (ten kabelem připojený) má debian a původě provozuju bez ipv6, headless, tudíž tam jsou ty síťové daemony povypínané, ale grafický seat tam stejně běží,  síť je konfigurovaná ručně (původně bez ipv6), až navíc jsem přidal ipv6 adresu eth0 rozhraní pouze tím, že jsem povolil sys sysctl net.ipv6.conf.eth0.disable_ipv6  a tím na eth0 mu přibyla fe80:: adresa.  forwarding je disabled. . Má přiřazenou ip fe80::MmAA:CCFF:FEMM:AACC (v podstatě vnořená mac adresa až na nějaký xor) . má wireguardy(žádné fe80::) s ipv6, wifi, eth0, lo,. ipv6 je na wg,lo, a teď nově i na eth0
druhý (ten připojený přes wifi) má  Ubuntu "jammy" a  připojen je klasicky přes nework manager v liště ,, s výchozím nastavením, prostě nalezena wifi : ipv6 settings automaticky., má jediné aktivní rozhraní wifi+lo

99
Vývoj / Náhrada \K v regexp za assertion
« kdy: 04. 02. 2023, 16:44:42 »
Mám výraz '^(www)?\K.+?$' (bez uvozovek) volaný  grep-em s parametry -P a především -o (to je důležité, jelikož matchuje jakýkoli řádek, ale výstup je bez toho "pocatek")

Jde nějak ho převést do tvaru aniž by tam bylo \ K  a aniž bych www bylo ve výrazu dvakrát?? Zkoušel jsem
'(?:(www|^)).+?$'
'(?:(www)?).+$'
(?<=www)
(?<=www|^).+$'
a další (i positive lookahead)

nevíc se tomu blíží  sloučení  '^(?!www).+?$'  a (?<=www).+?$'

Ale nikdy se mi nepodařilo přijít na kloub tomu

prostě aby to z řádků
Kód: [Vybrat]
www.neco
wtf.tamto
www.www.hento
vyplivlo (všechny ) řádky, ale s tím oříznutým www, tudíž :
Kód: [Vybrat]
.neco
wtf.tamto
.www.hnto
 

to oříznutí je právě díky -o

Samozřejmě, jde to přes sed a nebo přes ten zmíněný \K v grepu... ale jak to udělám přes grep? Zcela jistě se tam využije něco z non-captring groups, operátor ^, ungreddy modifikátor .+?, lookbehind , lookafter


EDIT: pardon, non capturing groups je nesmysl ... ty by měly smysl v match_data strukurách (třeba výsledek pregmatch vphp) a tady je to plain grep co rovnou háže výstup

100
Software / Firefox nefunguje po aktualizaci rozšíření
« kdy: 01. 02. 2023, 12:52:04 »
Firefox pro android mi udělal průser.  Aniž bych se o tom dozvěděl, natož nebo to někde nastavil nebo odsouhlasil, mi aktualizoval rozšíření.

Potom jsem si ničeho nevšiml, až posleze jsemch chtěl s nim interagovat (otevřít jeho control panel ) - Ukázala se prázdná obrazovka. Hell, F/... jsem si říkal, restartuju prohlížeč, to samé. Tak jdu do Menu - Addons, zapnu, vypnu. Dole vitím "toast" oznámení Extension was successfully enabled

Jenže když dám zpět tak vidím, že extension se ale actually disabled. FIREFOX dokonce lhal! (dokonce se animoval ten přepínač vyp/zap)

Tušíž se nedostanu ani do  "nastavení" addonu.


Proč do háje firefox dělá takovéhle průsery, proč aktualizuje addon, který pak nefunguje ????

Je nějaký způsob, jak vrátit starou verzi rozšíření, která fungovala, než Firefox se dotoho vmontoval.
Opravdu nemám v programu hlídat, kdy firefox něco, podělá, dělat zálohy nastavení a aktualizovat , vracet zálohované nastavení....
Právě že jde nepostradatelný addon, bez kterého je browsování webu nepředstavitelné

Nebo je nějaký způsob, jak a v jaké cestě souborového systému androidu(mám root) najít data rozšíření?

101
/dev/null / dobrý tip na urychlení práce s sort & uniq
« kdy: 30. 01. 2023, 23:56:50 »
když si zadefinujete příkazem alias seradvyskyty ="sort | uniq -c |sort -n",
tak je to dost dobrý trik, který ušetří bouchání do klávesnice  (hlavně náročný znak |) při počítání výskytů stejných řádků...
Asi neexistuje žádný parametr sort ani uniq, který by to samé dělal, že (klidně i bez posledního sort-n)? (v man uniq stejně se píše něco na způsob: NOTE: uniq does not sort, so  you may want use sort before or  sort -u... )

102
Sítě / Výlučnost CNAME a MX: v jakém směru?
« kdy: 19. 01. 2023, 21:11:39 »
Chci se zeptat, pry je zakazane nejaka kombinace mx zaznamu a cname.
Jak totedy je?

Pouziju priklad (posilani posty domene a.b.c).
Skladacka ma dva dily: prvni dil v poradi je hodnota pro samotnou mailovou domenu ( tedy jestli a.b.c ma zaznam cname(i vicekrat zretezene) a nebo mx) a druha jestli hodnota MX ma hodnotu A nebo CNAME(i vicekrat zretezene).
Neni to tak ze by platilo vse najednou, chci v tom najit ty problemove pasaze
domena a.b.c ma nastaveno cname na c.d.e
c.d.e ma MX: m.n.o
M.n.o ma cname q.w.z
q.w.z ma A:1.2.3.4
q.w.z ma MX x.x.x + x.x.x ma A:2.3.4.5



A hlavne, muze se cname retezit? (V obou mistech ;?
1: a.b.c (domena) : cname x.y.z : x.y.z uz nusi byt a nutne?

2: m.n.o (mailserver) cname q.w.z . q.w.z uz musi nutne byt uz A?


Tedy  rekapitulace: v jakych mistech (1.domena a 2.mailserver) muze byt vmestnano cname? A zadruhe kolikrat se muze cname retezit na prisl.miste?


Dal:
2 muze byt hodnotamx ip adresa?
3 muze byt u domeny x.y.z 3.radu mx identicka hodnota x.y.z

103
Sítě / Re:Přesměrování portu ve firewallu MikroTik
« kdy: 07. 01. 2023, 20:11:31 »
445
Není chyba hned tady? koukám že to je pasé

104
Software / Náhodné pořadí grep stdout +stderr
« kdy: 07. 01. 2023, 20:09:33 »
je nějaký důvod proč třeba conntrack -L | grep tcp vrací mezi mrakem řádků obsahujících tcp (v mém případě 50)  řádek "flow entries have been shown" v náhodném pořadí pokaždé ?

conntrack -L 2&>1 | grep tcp dává paradoxně výsledek někde uprostřed, ale konzistentně vůči samotnému výstupu stdout.

zaprvé, je tohle nějaká zvláštnost shellu, terminálu   nebo ?i? programu conntrack (který to třeba vypisuje ve vláknech) a nebo dokonce grepu?

105
Vývoj / Re:HMAC, SHA1 (C++/AVX2 VS2022)
« kdy: 07. 01. 2023, 20:02:54 »
[
Takto jsem posledne vyresil sifrovani ve fotakovem RAWu,
co proboha šifruje foťák? (když nepočítám wpa nebo připojení k internetu)? Nebo je to  nějaký foťák s funkcí content authenticity? (nějaká featura za kterou stojí adobe, že fotky budou podepsané jak vylezou z foťáku a má to dokazovat, že s nimi nrbylo manipulováno)

Stran: 1 ... 5 6 [7] 8 9 ... 29