Příspěvky

151

Windows a jiné systémy / Podpora iOS aplikací na intel Macboocích

« kdy: 08. 12. 2020, 18:21:04 »

Prý Big Sur umožní spouštět ipadové a iosové aplikace. Bude to ale fungovat na Macboocích s Intel procesormi?

(titulek:Podpora iOS aplikací na intel Macboocích)

152

O serveru Root.cz / Re:Funguje ještě na Rootu moderování?

« kdy: 08. 12. 2020, 17:32:59 »

Taky mě to tak připadá. A neustále cpou sporná politická tvrzení

Sorry za toho miloše a čerta, už je to stejně zcenzurované z nejvyšších míst. A propos, co to ten doutnák? Já znám jen doutnavku.

153

/dev/null / Re:iptables -Z jde jen u OUTPUT, jinak hlásí chybu

« kdy: 08. 12. 2020, 17:30:15 »

Zkoušel jsem workaround:

Kód: [Vybrat]

bug=999 ; while [[ $bug>1 ]]; do sudo iptables -Z FORWARD $((bug-=1)); done

Ale záhada je proč pro OUTPUT to jde přes workaround

154

/dev/null / iptables -Z jde jen u OUTPUT, jinak hlásí chybu

« kdy: 08. 12. 2020, 17:09:58 »

Hází mi a neresetuje čítače. Nevíte čím to?

Kód: [Vybrat]

sudo iptables -v -Z INPUT nebo FORWARD
iptables v1.8.2 (nf_tables):  RULE_REPLACE failed (Invalid argument): rule in chain FORWARD

U OUTPUT ale OK. Počet pravidel u F/I/O je asi 15/10/8.
V OUTPUT jsou jen pravidla -i/-o /dst/src, ale v FORWARD / IN jsou i ctstate,nebo pro match portu...

Znamená ta chyba že tam mám neplatné pravidlo? Takové by se ani přece nevložilo.

155

/dev/null / Znemožnění sniffování na linkové úrovni u veřejné WPA2

« kdy: 08. 12. 2020, 13:35:35 »

Mám situaci: veřejná wifi s veřejným heslem (například ve fastfúdu). Heslo je tedy známé, šifrování je WPA2. Útočník sniffuje provoz. WPA2 zaručuje, že není možné sniffovat provoz lidí, kteří se připojili před tím než útočník začal sniffovat.

Ale samozřejmě může sniffovat nově příchozí. Nebo může udělat "glitch na wifi", že způsobí rozpojení a oběti se připojí znova.

Otázky:

1. Je to z principu logické, že když je známé veřejné heslo ,že nelze očekávat, že si útočník (a klienti, ale mezi tím není rozdíl v důsledku  - ti taky znají heslo) může vidět linkovou komunikaci?

2. Řeší toto WPA3 ?

3. Dá se to řešit bez WPA3?

4. Dá se to řešit bez WPA3 a bez toho, že by každému bylo přiděleno nějaký unikátní přihlašovací údaje (což by byl opruz v cafetériích s veřejnou wifi)?

156

Sítě / Reset statistik RX, TX, iwconfig, ip

« kdy: 08. 12. 2020, 13:25:40 »

Hledám způsob jak, resetovat statistiky příkazu iwconfig nebo ip -s link. Zkoušel jsem ip link set up&down,bez efektu.

Čekal bych že to bude fungovat bez dočasného výpadku připojení (rozhraní), ale není to podmínkou.

Samozřejmě mohu vytáhnout server  ze zásuvky a spustit, ale hledám nějaké elegeantní řešení (nemyslím teď ethtool -G rx xyz;ethtool -G rx puvodni které stejně nefunguje nebo vyndavání a zasouvání jaderných modulů).

157

Hardware / Re:Chvilkové výpadky obrazu ve Fedoře

« kdy: 08. 12. 2020, 13:21:06 »

Prozkoumám obě možnosti

158

Windows a jiné systémy / Re:Hardwarová akcelerace VP9 na Haswell ve Windows 7

« kdy: 08. 12. 2020, 13:20:05 »

Doplněk znám (i enhanced, který má checkboxy pro víc kodeků). a právě víceméně kvůli němu se ptám, protože začly problémy, zaprvé víc než FULLHD není dostupné s AVC a za druhé mi chrome hlásí,  nějakou chybu s HTML, když doplněk zapnu

159

Software / Nefunguje mall.tv videa v novější verzi chrome, ve starší ano

« kdy: 07. 12. 2020, 12:44:06 »

Překvapilo mě, že gardo problému je Opačné. Tedy v novější verzi chrome 84 nefungují videa na mall.tv.

Ale na starší verz 65 Ano... Kde může být chyba

CO VID ím ve výpisu konzole(84):

Kód: [Vybrat]

DOMException: The play() request was interrupted by a call to pause()

Uncaught ReferenceError: $ is not defined
    at main?v=05OfBbgYbscyUVZ98bEDHzLUi36f3pmrUGRIcvxWmHY1:1
(anonymous) @ main?v=05OfBbgYbscyUVZ98bEDHzLUi36f3pmrUGRIcvxWmHY1:1
video?v=ZRjc-Qr44WTToWxo9YwbxHztcRRoc3yJ59T9wyqz3M01:1 Uncaught ReferenceError: $ is not defined
    at video?v=ZRjc-Qr44WTToWxo9YwbxHztcRRoc3yJ59T9wyqz3M01:1
(anonymous) @ video?v=ZRjc-Qr44WTToWxo9YwbxHztcRRoc3yJ59T9wyqz3M01:1
​
video?v=ZRjc-Qr44WTToWxo9YwbxHztcRRoc3yJ59T9wyqz3M01:1 Uncaught ReferenceError: $ is not defined
    at video?v=ZRjc-Qr44WTToWxo9YwbxHztcRRoc3yJ59T9wyqz3M01:1
    at Object.<anonymous> (video?v=ZRjc-Qr44WTToWxo9YwbxHztcRRoc3yJ59T9wyqz3M01:1)

Také tag video nemá src, je to jen <video autoplay="" playsinline="" crossorigin="anonymous"></video>

160

Windows a jiné systémy / Hardwarová akcelerace VP9 na Haswell ve Windows 7

« kdy: 05. 12. 2020, 18:52:29 »

Chci zprovoznit HW akceleraci dekodovani vp9 na Windows 7, CPU Haswell mobilní.
Tady na tom linku jsem se dočetl, že by to mělo umět partial hw dekodování (čemuž rozumím, že to bylo doprogramováno až po vydání fysického  Intel Silicon-u a je to tam dobastlené přes nějaké shadery, takže to asi bude efektivní někde napůl mezi SW decodingem a HW decodingem  spotřebou třeba jako u H264)
Nahodil jsem tedy nový driver
Dokonce se raduji z poznámky New features: ...- Improved video playback through partial hardware acceleration support for the VP9 video format..

Ale po restartu jsou výsledky stejné: zatížení CPU je furt 100% u 4K(13W) , kolem 90% u 1440p(12W), 50% u FULL_HD(9W), což je situace stejná jako před instalací.. Spotřeba grafiky GT Power furt kolem 1-3W. 4K se je hodně sekané, 1440p občas.  (Odbočka 4K H264 je naprosto OK)
Zkoušeno v chromu na youtube a pak v MPC playeru, který podporuje hw akceleraci(reálně funguje mi na h264), v options má samozřejmě i volby pro AV1,VP9, h264 a všude je na výběr zakázáno nebo VLD bit strem. Stejně se mi ale pak v přehrávači ukazuje že dekodování probíhá přes ffmpeg threaded. A jde samozřejmě o 8bit yuv420p

Ptám, se funguje to někomu nebo jsem nesplnil a přehlédl nějaký předpoklad?



A řečnická otázka: umí linux "~HW" akceleraci dekodování VP9 na Haswellu?

161

/dev/null / Re:adresní řádek neukazuje URL

« kdy: 05. 12. 2020, 18:41:13 »

taky de zakázat přes ty flagy chrome://flags/#enable-query-in-omnibox hele

Jee, to mi spadel kamen ze srdće. Kdo má furt sledovat ty changelogy... A ještě odhadovat jestli kýžený výsledek Přinese Enable Nebo Disable (když výchozí je Default:::!)

162

Sítě / přetečení čítače kromě `ip` i u `ip` .... sub-bajtová velikost paketů vyvrácena

« kdy: 05. 12. 2020, 17:11:44 »

No to mě p....

Kód: [Vybrat]

ip -s -h addr #...už umí -sh?
    RX: bytes  packets  errors  dropped overrun mcast
    14.8M      34.5M    0       0       0       0 # .....když se to vydělí, tak některé pakety musely mít délku nula bajtů  a nebo jsou pakety půlbajtové :D
    TX: bytes  packets  errors  dropped carrier collsns
    3.16G      14.5M    0       0       0       0


iw wlan0 link
RX: 2 040 950 385 bytes (1 437 389 packets) #.... tady to vychází zrovna teď na 1kB pakety takže nic senzačního
TX: 160 335 288 bytes (367 817 packets)

Tak tím už je vysvětleno, proč to nesouhlasí nikdy: díky občasnému odpojení se se resetuje iw čítač. A přetečení postihuje iw i ip. Akorát záhada, proč ne eth0.


Takže až vám budou vycházet pakety o velikosti třetiny bajtu, tak klídek.

163

Sítě / Hodnoty ip --stats se u Wi-Fi samy resetují

« kdy: 05. 12. 2020, 15:05:05 »

Narazil jsem na trochu nepříjemnou věc: proč  hodnoty u ip --stats -h addr jsou nižší (nebo se resetují, ale nevím kdy a proč)? Očekával bych tam kolem ~50GB/2GB(pro oba směry). (souhlasí s příslušnými iptables -nvL u FORWARD u ACCCEPT pro dané směry)

U eth0 se neresetují, je tam 50GB/2GB, ani když vytáhnu kabel, hodnoty zustanou...

Samozřejmě v iptables v-nvL vidím "vše". K tomu  mám otázku bokem: Chtěl bych nějak mí statistiku přenosů, toků. Nějak základně se k tomu dá iptables použít (že si dám poslední pravidlo ACCEPT a nějak tam udělám roztřídění podle cílové/zdrojové adresy), ale je to fungující jen pro opravdu malý počet sledovaných parametrů (a třeba jen pro in/out, pro počítače uvnitř, a neumí to dělit na časové období a  rozlišovat podle protější adresy by znamenalo kartézský součina pravidel --src --dst, takže  nemyslitelné). Co by se hodilo pro nějaké lepší monitorování (prometheus/grafana nabo cacti/rrdtool/mrtg)?

Všiml jsem si jedné věci: toto vrací ip link/addr:

Kód: [Vybrat]

: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 ... připojeno
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 ... když je killnutý wpa_supplicant-nepřipojeno

což bych očekával, že tam bude rozdíl. Ale hodnoty před a po odpojení jsou totožné. Zde se reset neděje (přesněji řečeno: odpojení reset nevyvolává)


rese
Původně jsem se chtěl zeptat na podobnou věc ještě u příkazu iw wlanx link, ale ještě si to rozležím v hlavě:

fun fact?: asi jsem vyhrál sportku  zrovna:

Kód: [Vybrat]

iw wlan0 link
        RX: 4 294 610 786 bytes (33483598 packets) ... (2^32 je 
4 294 967 296)
        TX: 2515682125 bytes (10368959 packets)

... chvíle poté:

        RX: 885175 bytes (33485308 packets) ... mod 2^32 ?
        TX: 2 515 802 652 bytes (10369946 packets)

(co je jistě, že po resetu wpa_supplicant se hodnoty iw wifina link resetují,  ale u ip -s -h a ). Do třetice, ty hodnoty nesouhlasí, vypadá to, že ip -s ukazuje i větší hodnoty než 4 miliardy


Takže když to shrnu: proč se resetují hodnoty u ip -s -h addr? (očividně ano, když tam není 50GB) Neresetují se, když dojde ke ztrátě zpojení/odpojení (to se ale se resetují hodnoty iw wlan0 link). + Do toho bonus s tou sportkou u iw wlan0>4GB (nedá se vyloučit, že by i tento problém postihoval ip -s, prověřím)

Nějaká jiná událost než odpojení wpa_supplicant (rfkill či "odpojení karty na nižší úrovni")?


Jaký by mohl být důvod resetu hodnot u ip -s -h link ?

164

Hardware / Re:Nový monitor od Dellu - blikání

« kdy: 03. 12. 2020, 10:56:26 »

To je dobrý vtip u Dellu, kdy HDMI vstupy jsou degradované.
V roce 2020 to už možná neplatí, to už snad  zvládne HDMI 2.0.

165

Hardware / Re:Otázky na audiofilov - načo sú optické audio výstupy a káble toslink?

« kdy: 03. 12. 2020, 10:53:46 »

Mimochodem, síří mě jedna věc na telefonu při zapojeném headsetu(a tedy využívání mikrofonu toho headsetu, přes comboJack): nahrávaný zvuk je totálně zmršený jakýmsi šumem, tipl bych si na stejné úrovni hlasitosti. Je to kombinace šumu a takového řinčení (něco jako zvuk měniče u elektroauta).

Mám 4 stejné telefony a stává se to u dvou ze čtyř. Na zbylých dvou je nahrávaný zvuk čistý. Zkoušel jsem to i se  dvěma různýma sluchátkama, pouze se liší charakter šumu.

O jaký jde problém (na straně telefonů evidentně)?