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 - Ħαℓ₸℮ℵ ␏⫢ ⦚

Stran: 1 2 [3] 4 5 ... 11
31
Sítě / Re:Podivné DHCP dotazy
« kdy: 15. 07. 2022, 16:47:38 »
Myslíš to nějak vyčítavě? Připojoval jsem asi v tu dobu NAS, který ale svou MAC má a taky nějaký mini PC board(kterýmu ale divně šla síť, se zapojeným kabelem eth0 bylo po startu down, sice ipv6 mělo a aleipv4 ne, ale taky si myslím že mac addr má stabilní.)
Vím a nevím, Ten seznam čítá asi 20 položek, žádný opatření (mac whitelist) extra monitoring nedělám nebo DHCP snooping(jestli se tím myslí, implicitní blokace ip pokud neprojde přes dhcp server)... Samozřejmě prolítnout journalctl |grep DHCP.+ mohu a taky jsem z toho čerpal. Pokud by se mi  něco ale připojovalo staticky, tak se to nikde neobjeví (kromě arp, kde se to objevilo a byl to impuls k dotazu )

Ale to podezření nedává smysl, jaké zařízení by dělalo jenom dhcp discover  a nic (dhcp-related) dál? Po Offer už tam nic není

Jo, podíval jsem se i  do logu ACCESSPOINTU (jelikož to je nějaká consumer krabička v roli switche+bridge ; brána&dhcp běží na linuxu najiném mikropočítači), ale nic nevyčetl, wifi záložka má jen a současné associace wlan mac adres (bez vazby na ip) a general log hlásí jen nějaké discovery ADSL(to nepoužívám)


Citace
Vtipné je, že 192.168.1/24 je skutečný rozsah sítě.
Jo a na závěr se musím opravit, v úvodním postu jsem se dopustil mea-culpa. Tak je logické, že   192.168.1/24  je správný rozsah sítě (přesněji IP z rozsahu), který dnsmasq nabízí...


Napadá mě třeba ip link flush addr, ale takový příkaz neexistuje

32
Sítě / Podivné DHCP dotazy
« kdy: 15. 07. 2022, 11:37:59 »
Nazdarek, v logu jsem zaznamenal neočekávané DHCP komunikaci. Co by to mohlo být? Tipuji že MAC adres jsou náhodné (alá android randomizace). A taky je mi divné, že sekvence DHCP končí vždy OFFER (nenásleduje Request&Ack)

adresy MAC mám v souboru dané direktivou dhcp-hostsfile=/...conf pro přehlednost, a toto jsou neznámé.

Poznáte (spíš podle charakteristiky), co by to mohlo být nebo jaký OS /stack se takhle chová? Třeba nějaká feature na detekci konektivity nějakého zařízení? Vtipné je, že 129.168.1/24 je skutečný rozsah sítě.

Víc jsem nedohledal v logzích.

Kód: [Vybrat]
23:50:17  dnsmasq-dhcp[569]: DHCPDISCOVER(eth0) 03:d7:75:fd:53:35
23:50:17  dnsmasq-dhcp[569]: DHCPOFFER(eth0) 192.168.1.113 03:d7:75:fd:53:35
23:50:20  dnsmasq-dhcp[569]: DHCPDISCOVER(eth0) 4a:72:e0:b9:91:1b
23:50:20  dnsmasq-dhcp[569]: DHCPOFFER(eth0) 192.168.1.87 4a:72:e0:b9:91:1b

00:13:19  dnsmasq-dhcp[569]: DHCPDISCOVER(eth0) d2:cb:bc:20:9c:03
00:13:19  dnsmasq-dhcp[569]: DHCPOFFER(eth0) 192.168.1.81 d2:cb:bc:20:9c:03
00:13:22  dnsmasq-dhcp[569]: DHCPDISCOVER(eth0) ad:15:86:9b:20:fc
00:13:22  dnsmasq-dhcp[569]: DHCPOFFER(eth0) 192.168.1.65 ad:15:86:9b:20:fc
00:13:25  dnsmasq-dhcp[569]: DHCPDISCOVER(eth0) 2b:f5:0f:66:45:75
00:13:25  dnsmasq-dhcp[569]: DHCPOFFER(eth0) 192.168.1.12 2b:f5:0f:66:45:75
00:13:28  dnsmasq-dhcp[569]: DHCPDISCOVER(eth0) ca:46:15:53:28:54
00:13:28  dnsmasq-dhcp[569]: DHCPOFFER(eth0) 192.168.1.96 ca:46:15:53:28:54

33
Tak jsem zjistil něco zajímavého. Když je "ProPhotoMode" režim a manuální "ostření",  nastavím Infinity (to jsem psal, že při ručním režimu ostření se na nekonečno nedá dostat),  jsou tedy věci v dálce ne uplně ostré ,tak po ťuknutí(otřesem) do smartphonu najednou spraví a je to ostré .

Dá se to opakovat, když zase na "tachometre" zaostření nastavím něco blíž, zase k nekonečnu, nezaostřené, poklepu/drcnu a je zaostřeno.


Přitom, záhada, v Auto focus to na nekončeno ostří dobře.

Tipl bych nějaká pružinka blbne, nebo tam zeseklý nějaká nečistoty,  (a tam bych neřekl že bude servomotor s ozubeným kolem, ale přitahování jen nějakým elektromagnetem nebo vychylování permanentního magnetu). Je možné, že pozice nekonečno je, když nepůsobí žádná síla a něco tedy brání se dostat čočce do "volného bloku"
 Ani poslední krok před nekonečnem V MF neostří správně . (U spousty mobilů se dá pozorovat, že na krajních polohách rozsahu se to chová divně/nespojitě)

34
stačí v klidu otevřít dev tools, dát f5, napíše to, že příspěvek už existuje, ale v network kartě mám samotný POST a textu příspěvku.

Máš pravdu, Zkusil jsem tentokrát způsob Reload, napsalo mi to hlášku "Nastala chyba, neodeslali jste příspěvek dvakrát" ? Hláška, která mi naprosto nic užitečného nepoví.  Tak jsem dal Reload, a zkusil tlačítko zpět  a formulář se objevil s rozepsaným textem. Ani k tomu nebyla potřeba konzole a "záloha" v Network-Payload

Je to opravdu nějaký kanadský žertík,jelikož ,když člověk po tom "marném odeslání" nedá reload, ale zkusí Zpět, tak se formulář neobjeví a text je ztracen.



35
Software / pidof vrací neúplný počet výsledků
« kdy: 13. 07. 2022, 13:29:13 »
proč když v linuxu (debian, 5.10) zadám (opakovaně za sebou) pidof wget, tak mi to vrátí neúplný počet výsledků?

Kód: [Vybrat]
0 6 9 9 9 0 11 12 12 12 0 12 12 12 12 12 12 12 12 12 12 11 11 5 1 0 0 4 8 12 12 9 0
(výstup jsem předžvýkal originál pidů uplně dole)

Bude to trošku delší post s výstupy utilit, snad se vtom odhalí zakopaný pes

Nějak na to musí mít vliv fronta zápisu na disk a čekání procesů, které se vytratí, když zthrottluji rychlost stahování a když ji navrátím, po nějaké době se nastolí čekání.... Avšak bcmstat hlásí konstantně 4-5 MB/s. Mimochodem, proč iftop hlásí polovinu? (99% trafficu se neforwarduje)

v htopu stále jsou, některé mají stav D(isk sleep), S(leep)
Jde o stahování na RPI 3 a z nějakého důvodu
Mimochodem flashka má seq. zápis 110MB/s, čtení 210 MB/s.  benchmark lehce: sekvenční zápis přes DD na sda i přímo
 do mountpointu (přes exfat) dává 33MB/s

iostat hlásí write size 64kB blocksize. exfat driver je tam rychlý(kernelový)

htop:
wgety v htop dávají po 2%(10x http) a po 8%(2x https)
htop  K H:
15% kworker/0:2-events
40% kworker/us:5-brcm_wg/mmc - patrně wifina-, když přes ni jde 40 Mbps (15000 irq/s)- viz dole

Děje se tam něco nepěkného.... ohledně přerušení/ fronty disku/


Swap není, využití ram 280/900



bcmstat
Kód: [Vybrat]
Time         ARM    Core    H264 Core Temp (Max)  IRQ/s      RX B/s      TX B/s   cpu0   cpu1   cpu2   cpu3
12:54:37  600Mhz  250Mhz  250Mhz 45.62C (47.24C)  4,585     175,964       5,911 100.00 100.00 100.00 100.00
12:54:39  600Mhz  250Mhz  250Mhz 45.62C (47.24C)  8,468   2,516,984     164,778 100.00 100.00 100.00 100.00
12:54:41  600Mhz  250Mhz  250Mhz 45.62C (47.24C) 15,418   3,468,569     151,227 100.00 100.00 100.00 100.00
12:54:43  600Mhz  250Mhz  250Mhz 45.62C (47.24C) 13,627   3,924,711     118,448 100.00 100.00 100.00 100.00
12:54:45  600Mhz  250Mhz  250Mhz 45.62C (47.24C)  8,493   3,543,318      66,350  64.19  70.97 100.00 100.00
12:54:47  600Mhz  250Mhz  250Mhz 45.62C (47.24C) 17,527   3,718,094      60,898  81.63 100.00 100.00 100.00
12:54:49  600Mhz  250Mhz  250Mhz 45.62C (47.24C)  8,330   3,384,918     140,940  95.66 100.00 100.00 100.00
12:54:51  600Mhz  250Mhz  250Mhz 46.16C (47.24C)  7,952   3,846,413      34,260 100.00 100.00 100.00 100.00
12:54:53  600Mhz  250Mhz  250Mhz 46.16C (47.24C)  7,676   3,355,452      66,200 100.00 100.00 100.00 100.00
12:54:55 1200Mhz  400Mhz  300Mhz 46.16C (47.24C) 11,820   5,020,296      37,388 100.00 100.00 100.00 100.00
12:54:57  600Mhz  250Mhz  250Mhz 45.08C (47.24C)  2,434     658,430       1,419  60.28 100.00 100.00 100.00
12:54:59 1200Mhz  400Mhz  300Mhz 45.62C (47.24C)    778      19,182         595   1.58  51.52 100.00 100.00
12:55:01  600Mhz  250Mhz  250Mhz 45.08C (47.24C)  1,868       4,794         162  87.42  46.31 100.00 100.00
12:55:03  600Mhz  250Mhz  250Mhz 45.08C (47.24C)  3,520     140,598       4,432 100.00 100.00 100.00 100.00
12:55:05  600Mhz  250Mhz  250Mhz 45.08C (47.24C)  6,674   1,889,065     110,850 100.00 100.00 100.00 100.00

iostat (v době ,kdy je "zahlceno")

Kód: [Vybrat]
     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,12    0,03     14,5k      0,7k     0,07     0,04  35,6%  58,3%   14,19  158,11   0,01   119,4k    21,7k   8,00   0,1% mmcblk0
    0,02    0,75      2,1k     55,7k     0,00     0,07  11,8%   8,5%   24,36   27,90   0,02    91,6k    74,7k  14,78   1,1% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00    2,00      0,0k    128,0k     0,00     0,00   0,0%   0,0%    0,00 1031,17   2,06     0,0k    64,0k 486,67  97,3% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00   71,33      0,0k      4,5M     0,00     2,33   0,0%   3,2%    0,00   36,32   2,59     0,0k    65,0k  18,18 129,7% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33  110,67      0,2k      6,9M     0,00     0,00   0,0%   0,0%   34,00   17,81   1,98     0,5k    63,9k   8,98  99,7% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33   62,00      0,2k      3,9M     0,00     7,00   0,0%  10,1%   26,00   25,06   1,56     0,5k    63,9k  12,73  79,3% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00   13,33      0,0k    834,7k     0,00     0,00   0,0%   0,0%    0,00  161,95   2,16     0,0k    62,6k  81,25 108,3% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33   22,33      0,2k      1,4M     0,00     2,33   0,0%   9,5%    5,00   82,75   1,85     0,5k    62,9k  40,88  92,7% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00   19,67      0,0k      1,3M     0,00     0,00   0,0%   0,0%    0,00  106,81   2,10     0,0k    65,6k  53,73 105,7% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00    2,67      0,0k    170,7k     0,00     0,00   0,0%   0,0%    0,00  624,38   1,66     0,0k    64,0k 358,75  95,7% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00    1,33      0,0k     85,3k     0,00     0,00   0,0%   0,0%    0,00  725,75   0,97     0,0k    64,0k 537,50  71,7% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33   40,33      0,2k      2,5M     0,00     4,67   0,0%  10,4%    8,00   72,62   2,93     0,5k    62,7k  36,15 147,0% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00   77,33      0,0k      4,8M     0,00     4,00   0,0%   4,9%    0,00   21,55   1,67     0,0k    63,0k  12,93 100,0% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00   36,33      0,0k      2,3M     0,00     2,33   0,0%   6,0%    0,00   43,27   1,57     0,0k    64,3k  21,74  79,0% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33   91,67      0,2k      5,8M     0,00     4,67   0,0%   4,8%   37,00   26,20   2,41     0,5k    64,3k  13,19 121,3% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33   50,67      0,2k      3,1M     0,00     4,67   0,0%   8,4%   31,00   38,80   1,98     0,5k    63,0k  19,41  99,0% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00    1,33      0,0k     85,3k     0,00     0,00   0,0%   0,0%    0,00  930,25   1,24     0,0k    64,0k 572,50  76,3% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00    0,67      0,0k     42,7k     0,00     0,00   0,0%   0,0%    0,00 1439,00   0,96     0,0k    64,0k 720,00  48,0% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33    0,67      0,2k     41,3k     0,00     2,33   0,0%  77,8%    3,00 1638,00   1,09     0,5k    62,0k 1090,00 109,0% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00    0,33      0,0k      2,7k     0,00     0,00   0,0%   0,0%    0,00 3104,00   1,03     0,0k     8,0k 3100,00 103,3% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00    0,67      0,0k     42,7k     0,00    31,33   0,0%  97,9%    0,00 4386,50   2,92     0,0k    64,0k 1420,00  94,7% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33  162,00      0,2k     10,1M     0,00     0,00   0,0%   0,0%   16,00   20,70   3,36     0,5k    63,9k  10,41 169,0% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,00   50,00      0,0k      3,1M     0,00     4,67   0,0%   8,5%    0,00   39,85   1,99     0,0k    63,5k  20,07 100,3% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33   90,67      0,2k      5,6M     0,00     8,33   0,0%   8,4%   35,00   17,15   1,57     0,5k    62,8k   8,68  79,0% sda

     r/s     w/s     rkB/s     wkB/s   rrqm/s   wrqm/s  %rrqm  %wrqm r_await w_await aqu-sz rareq-sz wareq-sz  svctm  %util Device
    0,00    0,00      0,0k      0,0k     0,00     0,00   0,0%   0,0%    0,00    0,00   0,00     0,0k     0,0k   0,00   0,0% mmcblk0
    0,33   12,00      0,2k    766,7k     0,00     0,00   0,0%   0,0%   23,00  177,75   2,14     0,5k    63,9k  87,03 107,3% sda



watch -d -n4 "cat /proc/interrupts" (ručně jsem vybral řádky které mají víc než 100/sec zhruba
Kód: [Vybrat]
75:   12310667          0          0          0  ARMCTRL-level  50 Edge      DMA IRQ
 75:   12315233          0          0          0  ARMCTRL-level  50 Edge      DMA IRQ

 89:   89839051          0          0          0  ARMCTRL-level  64 Edge      dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1
 89:   89842337          0          0          0  ARMCTRL-level  64 Edge      dwc_otg, dwc_otg_pcd, dwc_otg_hcd:usb1

105:   14910325          0          0          0  ARMCTRL-level  80 Edge      vc4 firmware kms
105:   14910569          0          0          0  ARMCTRL-level  80 Edge      vc4 firmware kms

119:  124949997          0          0          0  ARMCTRL-level  94 Edge      mmc1
119:  124972375          0          0          0  ARMCTRL-level  94 Edge      mmc1


free
Kód: [Vybrat]
free -m
              total        used        free      shared  buff/cache   available
Mem:            871         262          75          74         533         471
Swap:             0           0           0

PIDY: originál před zkrácením while read e; do echo $e | wc -w;  done <textovy_vystup_pidy| tr "\n" " "
Kód: [Vybrat]
24449 23863 23778 23774 23726 23464
24449 23863 23788 23778 23774 23726 23491 23464 23195
24449 23868 23863 23788 23778 23774 23726 23464 23195
24449 23868 23863 23788 23778 23774 23726 23464 23195

24449 23868 23863 23788 23785 23778 23774 23733 23726 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195

24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23726 23491 23464 23195
23863 23733 23726 23491 23464
23788


23788 23491 23464 23195
23863 23788 23785 23778 23774 23733 23491 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23868 23863 23788 23785 23778 23774 23733 23726 23491 23464 23195
24449 23863 23788 23785 23778 23774 23726 23464 23195

36
Bazar / Re:Prodám Corning Thunderbolt 3 optický kabel, 50m
« kdy: 12. 07. 2022, 17:23:57 »
Vyzkouším, měl jsem pocit že  nešlo Zpět◀️ ani Reload🔁. Možná hraje roli browser a přístup k redirectu po odeslání

37
Server / spojení se na hostovaný discord server
« kdy: 12. 07. 2022, 17:20:33 »
Pokud discord umí být selfhosted
, jak se jako klient připojím k někomu na server(když znám jen https://discord.com/invite/Abc123f - jak z toho extrahuji ip adresu/nebo mi.ji fotyčný musí sám poslat)? Lze to s identitou z zaregistrované na discord.com nebo si tam vytviřim novou identitu?

A nebo jsem to špatně pochopil a původní discord neumí být takhle decentralizovaný( první věc self hosted a druhá věc jak se tam připojit decentralizovaně)



Btw a ten fosscord je ( plně)oboustranně zaměnitelný s discord?

38
Bazar / Re:Prodám Corning Thunderbolt 3 optický kabel, 50m
« kdy: 12. 07. 2022, 14:01:15 »
Není to náhodou po Kovym?  Podle nějakého videa za série http://zařizujeme studio je to asi jediný člověk co si pořídil thundebrolt 3 kabel na propojení nějakého high end NASu,, bylo to minimálně 10m...

Už se mi nechce hledat co to bylo za video z těch 6, ale původně to zapojili USB-C portu a divili se proč to je tak "pomalý"


BTW: spadl mi kamen ze srdce, čirou náhodou jsem měl otevřený Preserve Log v Network Tabu v Dev Tools a zrovna udeřila pět let reportovaná chyba při odesílání příspěvku Litujeme přistup byl odepřen

39
Hardware / Re:Menší telefon
« kdy: 12. 07. 2022, 13:42:41 »
Soucítím. Mám možnost porovnat 16:10 a pak obdélník 2.1666 (alias devět ™ ku dvaceet celých pět desetin ™) a ten sráč se nevejde do kapsy, pouzder....
Fajn to druhé je, když má člověk často klávesnici, jinak to nedává smysl. A nejhorší, že některé přehrávače videa (asi ceskatelevize,stream, mall) jsou tak fajnově optimalizované v obou orientacích, že při původním zobrazení na výšku logicky limitem šířka displeje(1080) a při překlopení na výšku člověk očekává, že se se 16:9 obraz letterboxuje s pruhy na kratší straně displeje, jenže stavový řádek, tlačítka z toho udělají titěrný čtvereček oprostřed displeje.

40
Tak se mi stává, že alza.cz vyhodnotí jako bota a ukáže dialog

41
Odkladiště / Re:redmi note 3 a co dalej ?
« kdy: 12. 07. 2022, 13:30:29 »
Hehehe mi cloud a xiaomi úpravy androidu to je drbna jak stará blažková. Asi 20 domén to kontaktuje, prý to bonzuje i čísla jednou za čas...

Po naflashování AOSP samozřejmě vyčištěno..
Nevýhoda je asi že je to postarší, podle katalogu tam půjde dát Lineageos 14(Android 7). podle aktivity  n fórutomuhle odzvonilo v roce 2016... zařízení přitom je uvedené v roce 2016... divné. ale už i v té době byly povedené telefony (to se ještě nehajpovaly čočky, notche a další sereptičky na parádu)

42
Když si zobrazím nějaký plynulý přechod barev (bílá,černá, červená, zelená, modrá atd, nejmarkantněji bílá–černá)
, tak je mi divné, při jaké kombinaci mi se to ukazuje krásně plynule a kdy to dělá celkem nepěkné skoky.

Na Macbooku na interním LCD nádhera. Na jiném externím monitoru (2013) taky pěkné (nejlepší je nechat defaultní prostor, kontrast, křivky, gammu , pak se to horší)

Na testovaném LCD (2018) , z výroby kalibrovaném, dle recenzí DeltaE <1.9. začne přihořívat Když je to na jiném PC než Macbooku, tak je to tam taky hezké, bez pruhů. Ale jakmile připojím macbook na tento monitor, po celé siločáře přechodu se ukážou skoky . Čím to je ? Taky jsem hned zkoušel to hasit různým defaultním nastavením monitoru(gamma, režim, kontrast, HDMI,MiniDisplayPort) a nic.

Paradoxní je, že OS X sám o sobě nabídne asi 3 různé barevné profily ("po filtru" ✅  Pro tento monitor), ani jeden z nich to nespravil. Zkoušel jsem neškálované zobrazení, nativní i škálované (nativní,ale  větší písma,ikony atd).

Nevíte, kde by mohl být problém, když jiné počítače (pravda, zkoušeny windowsy pokaždé) s tím nemají problém?

43
Desktop / jak řešíte zvuk v případě více monitorů
« kdy: 01. 07. 2022, 12:24:08 »
Mám takovou otázku na pokec, pokud nepoužíváte  sluchátka nebo externí reprobedny(pak je to bezpředmětné), jak řešíte setup zvuku v případě více externích monitorů ? (Z různých důvodů, pohodlnost, nevhodnost do prostoru, akceptace zvukové kvality )

Jde mi spíš o  prostorové uspořádání a workflow, jestli nějaký monitor máte jako hlavní a druhý postranní, nebo máte 2 rovnocenné vedle sebe, tak ze kterého jde zvuk, pokud ne z obou(pokud to nějak jde udělat).

A taky, o jakou náplň činnosti jde. Třeba u grafika, který maximálně slyší zvuky Windows (Eject,Chyba,Dialog,...)  to asi nehraje roli

44
čistě pro zajímovat jsem zkusil iperf3 -s -D; iperf3 -c 127.0.0.1 a překvapilo mě (v jednotkách Gbps : přístroj)
Kód: [Vybrat]
23: VPS (frekvence jádra  nevím)
 4: RPI3B (má 1.2 Ghz po čtyřech)
 2: 2jádro i5 v starém notebooku @800MHz
 6: stejné, ale v2.6GHz
----
 toto by mě zajímalo
 ?: Macbook M1, M2
 ?: Ryzen 5700

No a nadpis vlákna je poněkud nadsazený, ale přesto, co pravdy je na takovémhle benchmarku? Co se z něj dá hrubě vyčíst, co je úzké hrdlo takového benchmarku? a co naopak takový test "netestuje"

A když konkrétně dodám, že třeba takový test nevytíží CPU na 100% ( a i tak je vše z toho kernel load). Samozřejmě roli bude hrát OS, i konkrétní tuning net.ipv4.xxx v případě linuxu, různý scheduling tcp



Tohle škrtám, to jsou moc věštecké počty: Tak například že Raspberry při 5 wattech(neměřeno, jenom odhad na základě  kolik tak bere podle zátěže CPU: zatěžuje to jádro a půl ze čtyř) se vyrovná postaršímu i5 2jádru v při 1.8GHz  na 7W... Ale přepočet na watty do toho  vnáší další závislost na procesu....

45
Server / Jak funguje na webhostinzích firewall a ochrany
« kdy: 29. 06. 2022, 10:08:51 »
Dejme tomu, že mám veřejnou IP a na ní hostuju různé druhy serverů, www hosting, smtp atd... Každý se asi setká s tím, že mu tam chodí různé automaty, boti(search engine), pak tam zkouší různé URL typu GET /rom0?cmd=%2Eshell/rm%20-rf  atd... Nebo na IMAP se zkouší některé adresy přihlašovat 100krát denně atd atd
kdo to loguje, tak má přehled, případně používá přehled přímo v daných Dashboardech, vidí tam frekventované adresy....

Já bych je dal do iptables -j DROP ( v lepším případě  s --comment, --match-set, -j LOG+DROP , případně -m recent, --connlimit ,--limit)

Takhle ten seznam pak ale bobtná, pak je taky problém, že ne každá malicous IP(případně rovnou rozsahy), která se dostane na seznam třeba podle zablokování  nevalidní SMTP komunikace, není "hacker", ale třeba napadený počítač uživatele, kterému by nemělo být bráněno dostat se na
 www (http 80 a 443). Tím spíš, ,dyž za jednou natovanou adresou může být víc uživatelů

A ještě pozorování, z deseti adres třeba 7 jich otravuje jen 2 dny a pak dá pokoj, 3 třeba zkouší nonstop 10 požadavků za zen a nebo pak je skupina, kde někdo zkouší 100 rq/s (ale   třeba po hodině by to ustalo). Další aspekt je, že někde je to vyloženě jedna IP a jinde jsou v shluku v nějaké rozsahu (většinou /24, ale mám 2 případy nějakého nizozemského providera /16)


To je popis jak to dělat po domácku.. Má otázka jak tohle řešit lépenež sadou iptables

A druhá otázka je ,jak tohle řeší webhostingové služby (multihosting s virtualhosty tedy s víc doménama a taky víc IP než jednou ať už víc IP na jednom stroji nebo  více stroji, prostě M:N a nebo rovnou s load balancerem)... V téhle oblasti je i druhá strana mince dostupnost, protože  se může stát, že vložením adresy do REJECTu  která lezla po SMTP se zablokuje WWW pro ni(nebo rozsah) pro nevinné uživatele, kteří mají tu smůlu že jsou v rozsahu útočníka/ za NATem,kde je útočník a nebo jen mají napadený počítač...

Nezdá se mi, že by ručně admin sledoval countery iptables nebo dashboard serveru a během šichty operoval s iptables -D INPUT / -I INPUT

Jak reálně na web  hostinízích funguje ochrana proti malicious aktérům, IP adresám  z blocklistů ?

Nezajímá mě tolik konkrétní produkt, ale spíš přístup a koncept a přístup.

Třetí aspekt je časové ohraničení blokování. Protože se na problematický traffic přijde, provider upozorní zákazníka(zafiltruje porty), uživatel "udělá reinstall widlí když má pomalý internet" a prostě nedá se dát -DROP na furt

Stran: 1 2 [3] 4 5 ... 11