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

Stran: [1] 2 3 ... 5
1
Vývoj / Skrytí NOSCRIPT ublockem možné?
« kdy: 09. 02. 2024, 19:09:49 »
Řeším takovou napříjemnost v HTML kódu a zkouším takovou uplně crazy věc.
Dá se pravidlem ublock skrýt tag NOSCRIPT (tady  jeho vnitřek!)? Sice picker ukazuje že je to validní syntaxe, ale náhled nic (zkouším i uložit+Reload, protože občas Náhled se neprojeví v určitých situacích jako +js(), has() nebo style() )

Nadále obsah noscriptu zůstává zobrazen. Nečekal jsem, že tohle zabere, ale nevíte proč?

Zkouším to i když v ublocku dám  Ano i Ne volbě Zakázat javascript na stránce(prostřednictvím ublocku, protože když to dám prostř. site permission, tak nejde picker, nicméně prý obě volby by měly dělat to samé)

2
Server / ESMTP redukuje velikost, SMTP ne?
« kdy: 21. 01. 2024, 22:56:10 »
Zde ke konci je srovnávací tabulka E- a SMTP

Zarazilo mě "reduces message size"

Co jecto zač za featuru?

3
Server / Nastavení druhé instance Dnsmasq
« kdy: 18. 01. 2024, 17:11:16 »
Jde nějak nastasvit druhá instance DNSmasq  (pro nově přidané rozhraní ) nastavit ,tak aby v ní DNS vůbec neběžel (našel jsem jen opačnou volbu, aby neběžel DHCP) a aby v DHCP  Reply jen odkazoval na jiný nějaký DNS Server?

zkoumal jsem direktivy listen, dhcp-range, domain, server a nepřišel na to.



Tedy že na konfiguraci prvního dnsmsq nešáhnu. Ten obsluhuje jiné rozhraní. Na nově přidané rozhraní chci vlastní instanci dnsmasq. DNS tam nemá běžet a jen předá informaci, které DNS použít přes DHCP.

Momentálně to řeším tak, že tato instance dnsmasq má jako server nastaven server=127.0.0.1 a vypnutím stop-dns-rebind a log-queries

4
Je v protokolu SMTP první tok od serveru přípustný, aby obsahoval dva a víc řádků "220" ? Tedy 220-něco a 220. Tedy vůbec první tok v SMTP komunikaci. Ještě před tím než klient něco(HELO nebo EHLO, to server nemůže vědět) odešle. To se mi zdá trochu divné pro tuto fázi.. A případně liší se odpověď pro standard ESMTP a SMTP?

5
Sítě / Kontaktuje WireGuard peera vždy?
« kdy: 29. 08. 2023, 21:38:59 »
Měl bych takový dotaz k fungování wireguardu  v situacích, kdy druhý peer je nedostupný.  Mám modelový příklad: na VPS běží Wireguard a přes PREROUTING mám naforwardován vybraný port na koncové zařízení.


Pokud dojde k výpadku připojení koncového připojení, bude se ho VPS snažit kontaktovat  pokaždé, když přijde paket který má být forwardovaný? Nebo jsou tam nějaké timeouty (třeba vycházející z conntrack)?

Tím spíš, když koncové zařízení je za NATema výpadek trvá déle než  2 minuty. pak by vysílal VPS UDP do "černé dírky", jelikož NAT ISP už rozetnul spojení.


Zatímco v druhé situaci, kdy místo UDP je využit  (z koncového zařízení) ssh -w 1:2 prostě  root@vps.com "ip addr add x y peer z;ip link set tun2 up; ip r add x via y;", s vhodně zvolenými parametry Clieant/ServerAliveInterval/TCPKeepAlive prostě  ssh tunel zkolabuje jako magnetické pole po vypnutí proudu.

Vite o něčem. co by podobného chování docílilo u wireguardu (konfigurace, určo tam je nějaký keepalive, ale to je jen interval přeposílání "handshaku"), aspoň co by dalo interface do down. ???

6
Sítě / Tcpdump nezachytí některé pakety
« kdy: 09. 08. 2023, 14:50:27 »
Když zachytávám přes su(do) tcpdump se stejným filtrem pakety, tak na androidu mi jich zachytí méně (za stejné období 24 oproti 87)
Proč tomu tak je?

Konkrétně jde o UDP pakety na výpisu  s označením nat-isakmp-keepalive : na druhém výpisu z telefonu, chybí. Mělo by jít o IPSec tunel.

Nemůže  právě odtud IPSec # Implementations vítr vát ?  Zde se píše o dvou implementacích stacku. Může nějak to mluvit i následně do toho, co tcpdump/uvidí/zachytí?

Jaké je vysvětlení, že ty pakety tam prostě nejsou? (Pro potvrzení, na routeru jsem capturoval taky i vnější rozhraní a pakety tam viděl, tedy stejný výsledek jako na vnitřením rozhraní)

Jde jen o útržek z logu, nechtěl jsem postovat všech 87 řádků


Kód: [Vybrat]
su -c " tcpdump -ni wlan0  'port 4500 || port 500|| net 62.0.0.0/8 '" -t
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes

IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]

IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  child_sa[I]   
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  child_sa[R]   
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]
^C
24 packets captured
24 packets received by filter
0 packets dropped by kernel
Na routeru:
Kód: [Vybrat]
sudo tcpdump  -ti eth0 "port 4500 || net
62.0.0.0/8 || port 500" -n
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp:
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp:
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp:
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp:
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp:
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp:
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive

87 packets captured
87 received
0 dropped



Verze na androidu(kde je méně paketů) je :
Kód: [Vybrat]
su -c tcpdump --version                                                             tcpdump version 4.9.2                                                                   libpcap version 1.9.0-PRE-GIT (with TPACKET_V3)                                         BoringSSL


Na routeru:
tcpdump --version
tcpdump version 4.9.3
libpcap version 1.8.1
OpenSSL 1.1.1d  10 Sep 2019

7
Lze v windows firewallu určit takové firewallové pravidlo(nebo dvě), které  danému procesu  (Tab "Programy a služby"=cesta k exe) zablokuje (Tab: Obecné: akce=Blokovat) konektivitu  všem adresám(Tab:Obor=  přepínač libovolná adresa) kromě pár vybraných IP? (políčko vzdálená adresa)

Zkoušel jsem udělat druhé pravidlo pro stejný proces, ale s Tab:Obecné=Povolit a Tab:Obor:přepínač =vybrané adresy:a do seznamu je vepsat)

jenže je dále blokovano?

Jak to řešit? problém lze řešit jen aplikačním FW na tomto PC. Má windows firewall v sadě pravidel nějaké pořadí?

PS: hledal jsem i na stackoverflow, jenže tam radí odpověď na jiný problém. Radí zmenit politiku firewallu a následně povolit pár IP adres. To by uplně rozhasilo politiku firewallu na tomto pc. tu chci nechat. Já jen chci řešit sadu pravidel pro jeden program.

Snad mě nečeká  řešení pouze jednoho pravidla Blokovat a v obor se pokusit čarova s maskami typu 0.0.0.0/1,128.0.0.0/2,192.0.0.0/2..... 194.0.0..... to bych na to zaprvý musel mít nějaký generátor a naklikat by trvalo 15 minut

Přitom by stačilo jediné, aby (v rámci 1 jednoho pravidla)do Obor šlo přidat něco jako vyjímka nebo zápis s prefixem + a -, takže například bych danému programu zablokoval 180.2.1.0/24 a v zápětí vyjmout 180.2.1.16/28

Jenže když dám 2 pravidla, tak pravidlo povolit ho nepřepíše. P

zde je obrázek té hrůzy:

8
Server / Význam reason→comment:arc=fail v DMARC
« kdy: 09. 08. 2023, 10:44:23 »
Zdravicko,narazil jsem v DMARC reportu posílaném mě v uzlu ROW na neznámý atribut REASON (vyznačen v prostředním bloku). Co to prosím znamená? jde o normálně poslanou novou zprávu
, žádné FWD , ani bounce ani přeposílku ani SRS ani čachry. Tedy na mé straně aspoň.


Vypadá to, že to dělá jen pro jeden konkrétním SMTP MX server .kam posílám poštu. (Samozřejmě že dmarc-odesílající server není totožný s příslušným SMTP. Nutně. )

Nějaké ARC je pro mě spanělská vesnice, tak prosím o nějaké stručné shrnutí a vůbec, jak tyto řádky chápat, co znamenají a co si z toho odnest

Kód: [Vybrat]

<policy_published>
        <domain>xy.cz</domain>
        <adkim>r</adkim>
        <aspf>r</aspf>
        <p>quarantine</p>
        <sp>quarantine</sp>
        <pct>100</pct>
    </policy_published>

<record>  <row>
            <source_ip>254.0.68.2?9</source_ip>
            <count>1</count>
            <policy_evaluated>
                <disposition>none</disposition>
                <dkim>fail</dkim>
                <spf>pass</spf>
Tady:
Kód: [Vybrat]
             <reason>
                    <type>local_policy</type>
                    <comment>arc=fail</comment>
                </reason>
pokračování
Kód: [Vybrat]
            </policy_evaluated>
        </row>
        <identifiers>
            <header_from>xy.cz</header_from>
        </identifiers>
        <auth_results>
            <spf>
                <domain>xy.cz</domain>
                <result>pass</result>
            </spf>
        </auth_results>
    </record>

9
/dev/null / co jsou béčkové subdomény domény facebook
« kdy: 05. 08. 2023, 18:47:22 »
b-graph a b-www domény facebook.com. v čem se odlišují od těch bez b-?

10
Sítě / Android v tcpdump ukazuje komunikaci z jiné sítě
« kdy: 31. 07. 2023, 19:29:57 »
Všiml jsem si v tcpdump v telefonu (na AP ne ani v dmesg|grep martian) zvláštních paketů v rozsahu 10.x.x.x přestože je v režimu offline. Takovou síť ani na domácí síti nemám(router  ani takový paket nezachytí, ani přes martian, jak tohle vysvětlit).Jako kdyby šlo o pakety patřící do rozsahu rozhraní  rádiového rozhraní rmnetdata1:
Kód: [Vybrat]
  ~ $ su -c ip r                                     
10.1.100.116/30 dev rmnet_data1 proto kernel scope link src 10.1.100.117

0: rmnet_data1: <UP,LOWER_UP> mtu 1280 qdisc htb state UNKNOWN group default qlen 1000                       link/(530)                                         
inet 10.1.100.117/30 scope global rmnet_data1           valid_lft forever preferred_lft forever


su -c logcat  grep 10\\.1 nebo 65 nic neukazuje

Bohužel už to nedokážu nasimulovat
 přes tcpdump -ni wlan0 "udp||arp:
 ale bylo to n+co jako 10.65.něco:random port  > na 10.1.100.117:50020 ..


taky su -c ss -ap |grep 50020 hlásil  TCP - LISTEN  0.0.0.0:50020 users=netmgrd

pro jistotu jsem projeil přes cat /proc/1115/{comm,cmdline} že jde /system/vendor/bin/netmgrd


-Co dělá?
-Proč tcpdump vypsal na wlan0 tento UDP paketu (payload length  45)

-čemu patří port 50020(v tomto kontextu)?
Telefon byl v režimu offline, jen wifina běžela, připojena
-Proč ip adresa rádiového rozhraní prosákla na wlan0?
Je rozhraní skrytě zapnuté? (jsou vidět záhlaví rozhraní rmnet_data... LOWER_UP atd)
Další věc, která je divná, že  v tcpdumpu bylo UDP ale ss hlásí TCP :o

Je fakt smůla, že nynÍ se to nepodaří zachytit.

11
Hardware / Zvláštnost myši Logitech, závislost na typu USB
« kdy: 30. 07. 2023, 21:50:36 »
Dumá mi hlavou, čím může být způsoben tento problém. Jaké si ladění myši, ale proč to vyžaduje USB 2.0? Vždyť myš přece je taky USB 2.0  a tím pádem USB 3.0 nevidí.
Myš má být schopna se automaticky vyladit na povrch, na němž ji budeme používat, k čemuž slouží jednoduchý proces. Ten vyžaduje, abychom stiskli levé tlačítko a s myší pár sekund opisovali ležatou osmičku, přičemž její senzor se přitom sám kalibruje.

Nicméně tento proces se nedařilo nastartovat, ale řešení bylo opět jednoduché. V tu dobu byla G502 zapojena k USB hubu v monitoru, přes což se aplikace nedokázala přenést, takže bylo nutné myš zapojit přímo k jednomu z USB 2.0 na základní desce. Ne USB 3.0, protože na tom ladění také nefunguje. Logitech o problému ví, ovšem už dva měsíce, takže se teprve uvidí, kdy přijde na svě nová verze Gaming Software.
REcenze
(recenze g502)

Napadá mě snad jedna věc, která by se toho mohla a týkat a asice jakýsi muxing USB 3.0, 2.0 a 1x portů. Omlouvám sem, už nevím kterých verzích se to týká Platí, že USB 2.0 používá jiné vedení než superspeed signál a  Že usb řadiče (řekl bych ty v těch hubech) mají jakési 2 režimy pro uplink: buď nižší verze USB trafficu přimíchají do toho aktuálního (do 3.0) a nebo to jde odděleně. Tady je link : Transaction  Translator Ale netuším, jestli tohle s tím vůbec souvisí, mám pocit, že by nemělo

12
Sítě / Jak operátoři blokují zahraniční VoWiFi?
« kdy: 15. 07. 2023, 12:41:05 »
V článku "Dovolená mimo EU: jak neprodělat na předraženém roamingu "  z 3.7. (tedy novějším než hulánův článek, ale za boha mě se tam neukazuje datum vydání článku, ale ostatním prý ano, článek nemá ani HTTP hlavičku Last-Modified, ani datum v zdrojáku nevidím) jsem četl, že prý operátoři blukují zahraniční Vo-wi-fi. Jakým způsobem?

Kontrolují, jestli IP, ze které se telefon přes wlan0 rozhraní snaží připojit k IMS nebo _PDG serveru ( reply epdg.epc.mnc
00x.mcc230.pub.3gppnetwork.org is 62.x.y.zz
která se podle nějakého pochybného maxmind seznamu nejeví jako česká?

Pomůže se tím tunelování tohoto provozu přes tunel (případně bohatě stačí, když wifina bude mít vnější IP adresu českou a na telefonu není potřeba hnout brvou)?
Nebo nějak jinak? (to dělají a nebo jak to obejít)

Případně je to opravdu pravda? To by pak nesouhlasilo i třeba s tím odkazovaným článkem. (Nebo je něco jako selektivní blokace, že zrovna v thajsku to šlo)

 


Citace: Lupa 3.7.
VoWiFi), toho čeká nepříjemné zklamání. Čeští operátoři tuto službu v zahraničí blokují. Tedy není možné být v roamingu s aktivní českou SIM kartou a us
"Dovolená mimo EU: jak neprodělat na předraženém roamingu "

13
Software / Aplikace Newpipe nepřežije půlnoc (0:00)
« kdy: 10. 07. 2023, 17:14:31 »
Měl jsem asu hodinu  spušteny newpipe na androudu , hrál.mi na pozadí.

Jenže přesně o půlnoci hraní přestalo a po 3minjsem(0:03) se podival na mobil a notifikace s broukem:
Otevřu a poleje mě Guru mediation v čase 0:00.


Co to sakra je? Někde soudruzi udělali chybu při výpočtu času třeba ? (Chyba asserce monitoniho času  hrabní třeba)

14
Když na androidu do dialeru vyťukám číslo pro zjištění kreditu (*103#) a "vytočím" ťuknutím na zelené dotykové tlačítko, vše je OK. Dokonce i když samotných pět znaků napíšu na externí klávesnici. Záleží jen na  té "koncovce"
Když místo ťuknutí na zelené tlačítko ale odpálím příkaz Entrem, tak se mi vrátí  hned dvě(sic!) hlášky:

Citace
Problém s připojením nebo neplatný kód MMI.
----
Problém s připojením nebo neplatný kód MMI.

Druhá hláška (popup až po zavření toho prvního popupu:)
Citace
Problém s připojením nebo neplatný kód MMI.
OS Android 11. AOSP.


Setkal jste se někdo s tímto problémem? Tak vám to blbne? Je někdo, kdo mu to funguje odklepnout i entrem?



Kde je problém?


PS: vytáčení numerických telefoních čísel je OK(iniciace hovoru), *#06# tak OK(jenže) tam se nemusí nic odpálit, stačí napsat poslední znak a už to jede

15
Desktop / Nefunguje zvuk v Chrome
« kdy: 29. 05. 2023, 16:26:11 »
Chrome mi nedokáže přehrát zvuky.
- videa bez zvukové stopy mi chrome přehrává OK .
 videa se zvukovou stopou se nepřehrají
- když otevřu file:// zvuk.wav nebo ogg , okénko s progresbarem a stopáží se ukáže ale nic se nepřehrává (identické jako přechozí odrážka)
hlásí  mi chrome(z terminálu):

Kód: [Vybrat]
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
Received signal 11 SEGV_MAPERR 0000000000f2
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242

kde je chyba? před měsícem to šlo. sw jsem neaktualizoval.

Stran: [1] 2 3 ... 5