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.


Témata - mikesznovu

Stran: 1 [2] 3 4 ... 9
16
/dev/null / Různý EHLO string
« kdy: 06. 02. 2023, 15:04:10 »
Mimochodem, když odesílám e-mail přes STARTLS, Tak po tomto příkazu (EHLO,STARTTLS,EHLO,MAIL FROM) zase se začíná od EHLO.  Jaká je praxe při kontrole EHLO, pokud se použije pokaždý jiný EHLO string (ano, nedává to smysl...), kontrolují se obě nebo jen tam první nebo ta po STARTTLS nebo stačí když vyhoví jedna?

Mě šlo poslat mail na  příchozí SMTP server  i když nemám RDNS záznam. ani dokonce když EHLO neodovídá mé doméně. A došel

 The IP address sending this 550-5.7.25 message does not have a PTR record setup, or
the corresponding
 forward DNS entry does not point to the sending IP.
As a policy,  Gmail does not accept messages from IPs with missing PTR records.





Dávání jednořádkového dlouhého textu do CODE není uplně friendly.

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

18
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í)

19
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

20
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

21
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í?

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

23
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

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

25
/dev/null / dvtv.cz
« kdy: 26. 12. 2022, 19:45:56 »
Dá se to po**ělat ještě víc??
"Zpět
Something went wrong :("

k čemu je nutné nějak tiv.io na dvtv.cz???

26
/dev/null / Je nějaký vztah mezi těmito doménami?
« kdy: 15. 12. 2022, 21:01:33 »
api-respekt-prod.eu.contember.cloud a cntmbr.com a co je to zač?

27
Sítě / Lze zjistit DKIM selektor jen podle domény?
« kdy: 09. 12. 2022, 15:13:25 »
Narazil jsem na službu https://dmarc.nu/en, kde mě zaujala jedna věc. po zadání pěti domén (tedy třeba alza.cz) jsem nabyl dojmu, že nevrací správné výsledky. False negatives 

vrátí tyto výsledky (zajímá mě jen 3. boxík DKIM):
alza.cz vrací v pořádku ; selector found: 1 záznam : Office365
kostel.cz vrací v pořádku ; selector found 2 záznamy : Mailjet : mailjet._domainkey Google : google._domainkey
... jiná  ... ; ... 2: mandrill
palermo.it ; fujfuj ; found zero . –– Přesto tato doména selektor má
nebo jakákoli jiná doména o které víte že má DKIM ale kontrola pro něj hlásí not found

... v kontrastu: google.com  nebo jiné spol. používá dynamické selektory typu dkim-2022-10
Mě zajímá jak dochází k těmto selektorům? To jsou nějaká dobře známá jména? Pokud ano, je to nějaký důsledek "nařízení", že si oni diktují hodnotu DKIM selektoru?

Případně si to nějak domýšlí* z TXT záznamu SPF  obsahujících include; nebo různýcch TXT typu site-verification? Toto domýšlení ale nemůže být dokonalé a taky očividně nenajde správný DKIM který zde není uveden

 

A nebo mě uplně převezli a mají to nějak fikaně? nechají si (jak ???) poslat mail z této domény, z nějž na to přijdou?

28
Vývoj / Neomezená rekurze při foreach C#
« kdy: 06. 12. 2022, 23:38:37 »
Dojde zde k "neomezené rekurzi" ? Je tento (1,2) kod optimální? Samozřejmě strom je konečný, ale  volá se yieldnode/applynode. Nejde mi o rekurzi stromu a pricipu algoritmu (což jsou) ale o kód, jestli roste stack frame s hloubkou stromu

Případně pokud ano , dokáže se s tim kompilator poprat ((tail)optimalizace, dekompozice na "goto")?

Kód: [Vybrat]
1

public IEnumerator<T> GetEnumerator()
{
    foreach (var item in YieldNode(_root))
        yield return item;
}

private IEnumerable<T> YieldNode(Node<T> node)
{
    if (node == null)
        yield break;

    foreach (var item in YieldNode(node.Left))
        yield return item;

    yield return node.Item;

    foreach (var item in YieldNode(node.Right))
        yield return item;
}

2:

public void ForEach(Action<T> action)
{
    ApplyToNode(_root, action);
}

private void ApplyToNode(Node<T> node, Action<T> action)
{
    if (node == null)
        return;

    ApplyToNode(node.Left, action);
    action(node.Item);
   

29
Vývoj / Srovnání algoritmů na prvočísla
« kdy: 04. 12. 2022, 23:01:27 »
Který z algoritmů bude asymptoticky lepší v čase? Hlavní cyklus klasicky počítá od dvojky a inkrementuje i. (Případně od trojky a inkrementuje po 2, to je fuk)
-ten, který daného kandidáta zkouší dělit všemi čísly až po číslo samotné i (to je pro ukázku zde jenom)
ten, který daného kandidáta zkouší dělit všemi čísly až po FLOOR(SQRT(i))
-ten, který daného kandidáta zkouší dělit jen prvočísly až po číslo samotné i, přičemž si prvočísla ukládá to pomocné tabulky
-Erasthenovo síto

Druhá větev-
je lepší (opět rychlejší) v druhém vnoření cyklu při porovnání odmocniny si odmocninu nejdřív spočítat (sqrt(i)) a nebo testovat  j<=i*i
-samozřejmě taky vím, že taky dost výkonu ubere, když odmocnina není převedená z float na int

30
O serveru Root.cz / Přidání názoru trvá 10 sekund
« kdy: 29. 11. 2022, 17:32:23 »
Přidání názoru pod článek/zprávičku trvá 10.55sec (Waitng (TTFB)). Není to nějak moc pomalé? Obzvlášť vkontrastu, když editace trvá stovky ms.

Stran: 1 [2] 3 4 ... 9