Témata

1

Distribuce / Spuštění Android APK na RPi Zero 2W

« kdy: 05. 09. 2024, 23:08:11 »

Dobry vecer vespolek,


zas se jednou poustim do neceho, co by se urcite nemelo delat :-)

Otazka je tentokrat uplne obecna, mam Android APK aplikaci (nikterak narocnou, slouzi jen k ovladani nestandardniho zarizeni pres Bluetooth; bezi bez problemu na velmi starem telefonu s Android 7).

Android jako primarni OS na Raspberry neni mozny, nutne musim bezet na 64-bit Bookwormu (headless, pristup pres TigerVNC, x11).

RPi Zero 2 W ma na Bookwormu pouze 417 MB vyuzitelne pameti, pri provozu s primarni aplikaci byva neco odswapovano, ale pres 150 MB volne RAM si to porad dokaze udrzet.



Waydroid vyzaduje Wayland, coz veci ponekud komplikuje (narocnejsi na pamet, nutnost nejakyho alternativniho VNC reseni, ktery umi bezet headless).
Anbox je mimo aktivni vyvoj.


Jsou nejake alternativy, ktere by dokazaly bezet na X11?


Jako jo, muzu se z Raspberry pripojovat pres VNC na ten Androidi telefon, jenze to udrzuje zaplej displej, coz je samozrejme problem stran vydrze baterky. To uz bych musel zas resit nakej rovnak na ohejbak typu Y-split USB kabel pro rozdeleni napajeni a dat, at se to muze krmit z jine powerbanky... bleh.



Diky za napady.

2

Server / Vlastní instance Mozilla location services

« kdy: 13. 06. 2024, 00:06:22 »

Dobry vecer,

ano, zase si lamu hlavu s vymyslenim toho, jak udelat neco, co by se delat zrejme nemelo :-)


Mejme aplikaci, jejiz soucasti je, ze si zjisti polohu (skrze nominatim.openstreetmap.org a location.services.mozilla.com - v tomto poradi) a na zaklade souradnic si spocita nejake veci (cas zapadu slunce, zacatek/konec astronomicke noci atp.).
Rucni zadani souradnic primo do aplikace bohuzel neni mozne, stejne tak nevidim realne, ze by autor mel v planu tuto zmenu provest v nove verzi.



Problem hlavni:
location.services.mozilla.com (dale MLS) jsou defacto mrtve - ke dnesnimu dni probiha zruseni 3rd-party API keys pro pristup k ni a dal to zrejme fungovat nebude.


Problem vedlejsi:
HTTPS. Nevim, co je v tech requestech pro tu ci onu sluzbu. Jak se muzu podivat dovnitr? Zatim jsem to vzdy resil jen v ramci prohlizecu, ktere mi umely https rozbalit primo... ale takhle ze site?

Nakolik nevim, co je uvnitr, tak se domnivam, ze to funguje nejak takhle:
1) MLS dodava souradnice, kde asi zhruba jsem, ale neresi prepis do "lidske podoby"
2) OSM nominatim provede reverse lookup souradnic pro prepsani lokality do lidsky citelne podoby

Nojo, jenze poradi tech requestu je opacne, nez se domnivam: napred OSM, pak MLS.
Nicmene, aplikace si posledni zname souradnice nekam (neprisel jsem na to, kam) zrejme uklada, a tak muze nejprve probehnout pokus o zjisteni lidsky citelne lokality dle cached souradnic od minulyho spusteni aplikace? Nevim, spekuluju.



A nakolik nic nevim, prichazi myslenka strelby od boku:
Rozjet u sebe za VPNkou lokalni instanci "MLS" (https://github.com/mozilla/ichnaea), nakrmit MLS poslednim exportem dat (https://location.services.mozilla.com/downloads).
Variantne se na celou ichnaea mrknout, jak vypada odpoved, a zkusit upravit odpoved tak, aby to vzdy vracelo to, co skutecne chci - cili dosahnout takhle oklikou krasnyho narovnani toho ohejbaku 


Dobry, timhle bych asi mohl mit vyresenou zalezitost stran fungujici aplikace, co odpovida na pozadavky.
Udelam si upravu /etc/hosts a presmeruju si tuhle domenu k sobe do VPNky.
Muze to takhle vubec fungovat? Musim nejak extra resit HTTPS (nejaka vlastni CA, kterou dotlacim do zarizeni, plus "spravne vypadajici" certifikat), nebo muze stacit jenom trivialni self-signed?
Jedna se o aplikaci, blackbox, ne o webovy prohlizec, ktery muze na spoustu veci brblat (a pripadne umoznit nejaky override).


Diky za napady.

3

Sítě / Ping neprojde do pingnutí z druhé strany

« kdy: 22. 05. 2024, 23:50:03 »

Dobry vecer,

lamu si tu hlavu zase s dalsi libustkou a budu rad za napady.


Mejme sit za(bez)dratovanou takhle:

RPi > Wi-Fi k telefonu slouzicimu jako hotspot > LTE > verejna IP > pfSense


Na RPi (RaspberryOS Bookworm) bezi Wireguard 192.168.50.4/24, pfSense posloucha na udp/51821, Wireguard interface 192.168.50.254/24

AllowedIPs na RPi jsou 192.168.50.0/24, 192.168.30.0/24, 192.168.20.0/24, 192.168.10.0/24 (coz jsou dalsi rozsahy existujici v pfSense, z nichz funguje routovani prave na tenhle Wireguard interface)



Casto se mi deje, ze komunikace z tech AllowedIPs rozsahu smerem na 192.168.50.4 nefunguje a zazracne zacne fungovat v moment, kdy nejakou komunikaci zahajim opacnym smerem, tj. kdy tuhle RPi mam jako odesilatele treba ICMP echo requestu.

Tak fajn, navazu spojeni, otevru treba SSH, VNC, udelam, co potrebuju, zavru... nojo, ale abych to spojeni treba za 15 minut otevrel znova, tak uz mam smolika, protoze se to zase rozpadne az do prostouchnuti z druhe strany. Coz je blby, protoze typickej scenar znamena, ze RPi zustane nekde daleko v prirode a ja uz si hovim doma.


Pripada mi to jako nejakej problem s ARP cache, ale moc nevim, jak to odladit.


Jasne, nejakej stupidni workaround jako poslat jednou za minutu jeden ping, at se to laskave udrzi nazivu, by asi fungovalo, ale prece musi byt i nejaky elegantnejsi reseni?!

4

Windows a jiné systémy / Android se hlásí jako MTP a ne ADB

« kdy: 10. 04. 2024, 22:21:08 »

Dobry vecer,


mam tady mensi vyvoj ohledne pokusu dostat do Lenovo Vibe P1m tenhle neofiko, ale pry funkcni LineageOS. https://xdaforums.com/t/rom-7-1-2-unoffical-oms-lineageos-for-lenovo-vibe-p1m-substratum.3729116/

Nakolik jsem Android nepouzival deset let, tak jsem s tim naprosta lama a v nejakych ADB a fastbootech docela plavu.


Zatim jsem ve stavu zakladniho Androidu ver. 5.1, dostal jsem se do developer modu, odemknul jsem bootloader a zapnul ADB.


Telefon se pak hlasi jako tri ruzna USB zarizeni:

Lenovo Composite ADB Interface: USB\VID_17EF&PID_7921&REV_?&MI_02
Lenovo P1ma40:  USB\VID_17EF&PID_7921&REV_?&MI_00
USB Mass Storage: USB\VID_17EF&PID_7921&REV_?&MI_01


Dam:
adb reboot recovery

Telefon se restartuje a jakmile je v recovery, USB zarizeni komplet zmizne.


V recovery menu telefonu udelam wipe cache, wipe data/system, to probehne v poradku.
Nasledne dam Apply update from ADB, telefon mne vyzve k provedeni adb sideload

Jenze ouha:
C:\platform-tools>adb sideload lineage-14.1-20180102_172327-UNOFFICIAL-P1m.zip
adb: sideload connection failed: no devices/emulators found
adb: trying pre-KitKat sideload method...
adb: pre-KitKat sideload connection failed: no devices/emulators found


Kouknu do zarizeni, jak to vypada na USBcku. Telefon se uz NEhlasi jako ADB, nybrz jen jako MTP s nasledujicimi Hardware IDs:
USB\VID_018D&PID_2008
USB\VID_018D&PID_2008&REV_?

Po ADB vsak ani stopy. Po restartu zpatky do normalniho Androidu se ADB zase objevi.


Co delam spatne, ze mne telefon navadi k provedeni adb prikazu, avsak sam se jako adb nehlasi?


Diky za napady.

5

Hardware / 4G modem s USB-A a podporou OpenWRT

« kdy: 31. 03. 2024, 21:56:46 »

Dobry vecer,

jednoho krasneho dne jsem se dovedel o existenci nastroje qDSLR Dashboard a zjistil jsem, ze to nutne potrebuju... :-)


Cilem je plne vzdalene ovladani fotaku skrze mobilni data (via Wireguard tunel pres LTE).


qDSLRDashboard ma serverovou cast, ktera si muze bezet treba i na necem s OpenWRT za predpokladu, ze to ma USB port (a dostatek vykonu/pameti/flash na to vsechno).
https://github.com/hubaiz/DslrDashboardServer

Blby je, ze zrovna ten v dokumentaci zminovany TL-MR3040 se uz zajedno nedela a zadruhe patrne nefunguje bez baterky...


Cilem je najit vhodne zarizeni:
0) ma to 1x USB-A (pro pripojeni fotaku)
1) kompabitilni s OpenWRT
2) umi LTE
3) je schopno rozbehnout Wireguard a tento DSLR Dashboard Server (zde nemam predstavu o narocich na CPU/RAM/flash)
4) velka vydrz na baterku, popr. schopnost furt sosat stavu z microUSB z powerbanky, pokud by se baterka mela vybit


V ceskych luzich a hajich jsem zadny mobilni hotspot s USB-A neobjevil, vse jen pro pouziti s microUSB pro nabijeni nebo sdileni site pres USB.


Pam uz mne napada snad jen nejaky bastleni zalozeny na RPi a laborovani s nejakym USB modemem? (Mam za to, ze svyho casu RPi vyzadovalo 5,1V namisto beznych 5V... uplne nevim, kde bych to mel z powerbanky vycarovat :-) )


Nejake napady?


Diky.

6

Hardware / Energie do mrazu: powerbanky a vše okolo

« kdy: 02. 02. 2024, 20:06:45 »

Dobry vecer,

mozna to tu bude mirne mimo zamereni, ale zalozni zdroje a powerbanky se zde prilezitostne resi.


Energii je potreba zajistit pro:
1) fotak (odber cca 0,5-1A@5V z USB-A, da se to uzivit i z USB 2.0 :-) )
2) ohrev objektivu (odber 2A@5V z USB-A, potencialne x2)
3) casovac (dve mikrotuzky, odber nula nula nic, ale v mrazech to nic nevydrzi)


Uvazujme potrebu nejakych 12 hodin provozu pri teplotach -15C.


Dosavadni zkusenosti:
2x 20Ah powerbanky s 2x USB-A, fotak prezije vzdy a jeho baterka ma cca pulku kapacity (oba USB-A holt pichnuty do stejne powerbanky, nelze tam mit pichnuty jen jedno, jinak to zlobi), ohrev vydrzi pri teplotach kolem nuly sotva 7 hodin. Ve vetsich mrazech tezko hodnotit, tam clovek narazi na limit mikrotuzek, nacez fotak usne a uz vubec neni, ceho se chytit...


Cili mi z toho vychazi, ze bych potreboval budto zajistit, aby si ohrev mohl sosat stavu z obou powerbank (zrejme nelze, protoze z obou powerbank, menicum navzdory, nepotece uplne stejny napeti?), nebo sehnat jeden veeeelkej kus. A pripadne k ni prihodit neco teplyho a zkusit to nejak zaizolovat, at to aspon promrzne o neco pozdejs?


Tohle samo o sobe je asi resitelne, v ceskych kramech jsou k videni powerbanky nad 60-80 Ah kapacity, coz by melo stacit i pri dvojnasobne energii na ohrev.
Mit tam aspon 4x, lepe vsak 5x USB-A (tady uz je to horsi, vetsinou je to jen 4x, zbytek by musel jit nejak z USB-C).


No a hlavni otazkou je, jak z toho nahradit tu dvojici mikrotuzkovych baterek. Jak se jmenuje to, co hledam? Nejakej stepdown menic 5V > 3V, kterej by byl v nejake krabicce jakztakz odolne vlhku (ranni rosa, spise nez dest)?



Diky za napady.

7

Sítě / WireGuard jde do wg0, nikoliv přes síť

« kdy: 19. 08. 2022, 14:53:17 »

Zdravim,


opet se obracim se zadosti o radu, asi neco delam blbe.

Delsi cas mam zprovozneny WG tunel mezi nekterymi zarizenimi (Windows, iOS) a domaci branou (Linux) tak, ze na klientech jsou allowed-IPs 0.0.0.0/0 a tunel se spravne chova tak, ze vsechen traffic jde skrze Wireguard interface, jehoz traffic tece skrz fyzicky interface a nic vic jsem resit nemusel (zadne fwmarky, nic).


Narazim ale na problem u Fedory 36. Wireguard profil jsem vytvoril pres nmtui, fwmark nastaveny na 51820 a na pohled tam nevidim zadnou botu.

Kód: [Vybrat]

cat /etc/NetworkManager/system-connections/wg0.nmconnection

[connection]
id=wg0
uuid=a33d307e-71f2-454d-a68b-bafab24e9961
type=wireguard
autoconnect=false
interface-name=wg0
timestamp=1660900501
zone=internal

[wireguard]
fwmark=51820
private-key=<hidden>

[wireguard-peer.<hidden>]
endpoint=<hidden>:51820
persistent-keepalive=60
allowed-ips=0.0.0.0/0;

[ipv4]
address1=192.168.10.4/24,192.168.10.254
dns=192.168.10.254;
dns-search=at.home;
method=manual

[ipv6]
addr-gen-mode=stable-privacy
method=disabled

[proxy]
Tam by, snad, nemelo byt nic vyslovene spatne?


Nicmene jakmile odpalim

Kód: [Vybrat]

nmcli con up wg0, zacyklim se, CPU vyleti na 100% (kworker/3:2+wg-crypt-wg0) a na sit se samozrejme nedostanu.

Wireshark tvrdi, ze posledni moment, kdy neco odeslo skrze fyzicke rozhrani, je wireguard handshake. Nasledne veskery "traffic" vcetne obsahu wireguardu samotneho, je tlacen skrze wg0 a nikoliv na fyzicke rozhrani.

Kód: [Vybrat]

route
Adresát         Brána           Maska           Přízn Metrik Odkazů Užt Rozhraní
default         _gateway        0.0.0.0         UG    50     0        0 wg0
default         _gateway        0.0.0.0         UG    600    0        0 wlp59s0
172.20.10.0     0.0.0.0         255.255.255.240 U     600    0        0 wlp59s0
192.168.10.0    0.0.0.0         255.255.255.0   U     50     0        0 wg0


Napred jsem teda zapomnel uvest fwmark=51820, ale ani po jeho doplneni se to nezmenilo. Tusim, ze zakopanej pes muze byt prave tady, ale nevim, ceho se chytit.

Poradite, prosim, kam se jeste mrknout?


Diky.

8

Desktop / 2in1 notebook/tablet - klávesnice na obrazovce

« kdy: 30. 07. 2022, 23:23:00 »

Zdravim vespolek,


prosim, poradte.

Mam tady Lenovo Miix 720 a zkousim na nem pouzivat Fedoru 36.
Ve sve podstate tam vlastne spousta veci funguje sama o sobe docela dobre, az mne to prekvapilo. :-)

Nicmene, narazim na dva zadrhele.

1) Po odpojeni krytu s HW klavesnici a touchpadem (chova se jako USB zarizeni viditelne v lsusb) se mi nezobrazi SW klavesnice. V systemu patrne je nejaka vestavena (nejspis totez, co se zapne pri aktivaci "Pristupnost => Klavesnice na obrazovce"), ale je uplne k nicemu - jednak neobsahuje celou klavesnici, chybi napr. Ctrl/Alt/Tab, a druhak neni zobrazena stale. Nektere aplikace, nektera textova pole ji vyvolaji, jina ne.

2) Natrefil jsem na aplikaci onboard, ktera mi pro zmenu nejde premistit obrazovce a nefunguje dle ocekavani - neodsune veskery obsah obrazovky "nahoru", ale cast obrazovky prekryje.
Tato aplikace by mela umet nejake automaticke zapinani v zavislosti na stavu HW klavesnice (pripojena/chybi) podle zprav z acpid...

Zde prichazi problem 3)
Po instalaci acpid mi HW tlacitko na vypnuti zarizeni zarizeni vypina, ackoliv je v Nastaveni => Napajeni nastavena akce Uspat do pameti...?
Co s tim? Zkusit omrknout nastaveni na strane acpid?


Bonus problem 4):
Na discich je aplikovan LUKS s odemknutim pri startu systemu. Je mozno nekam (initramfs?) dodat "klavesnici na obrazovce"? Takhle pro start defacto musi byt pripojena HW klavesnice, jinak neni mozno heslo k LUKS zadat.



Pripadne, pokud nekdo nejake 2 in 1 zarizeni pouzivate, pouzivate jine distro, ktere je pro pouzivani s dotykovou obrazovkou vhodne?



Dekuji za podnety a preji hezky vikend.

9

Software / VLC při spuštění playlistu z Vivaldi nedékoduje H265/HEVC

« kdy: 02. 03. 2022, 21:54:40 »

Dobry vecer vespolek,

zase jednou jsem v koncich. VLC mi tvrdi, ze neumi prehrat H265/HEVC.

Fedora 35 MATE
VLC 3.0.16
Vivaldi 5.1.2567.39
Tvheadend 4.3-3.20210724git6efa411.fc35

Po behani od certa k dablu a dospeni k zaveru, ze proste musim mit vsechno a musi to jit mne napadl mensi experiment...


Spustim VLC (bez parametru), otevru v nem soubor obsahujici URL streamu z TVheadend (H265/HEVC). Vse funguje.
Zavru VLC, otevru primo ten m3u soubor ze stazenych, commandline dle ps -aux vypada:
/usr/bin/vlc --started-from-file /home/tv/Downloads/25a8ea56efe74070743a1d34102b83e7
Vse funguje.

Zavru VLC, otevru TVheadend v prohlizeci (Vivaldi), zase stahnu z TVheadend primo ten maly soubor s URL, volba otevrit/ulozit vyberu Otevrit (chova se stejne i pokud dam ulozit a spustim primo z Downloads).
Spusti se VLC, zacne se nacitat stream, ale hraje jenom zvuk.
Codec not supported:
VLC could not decode the format "hevc" (MPEG-H Part2/HEVC (H.265))

Parametr v commandline beziciho procesu je ale stejny, jako pri spusteni z file manageru.
/usr/bin/vlc --started-from-file /home/tv/Downloads/25a8ea56efe74070743a1d34102b83e7

Tak dlouho se pidim po nesmyslech, jak je kruci mozny, ze mi VLC nepodporuje HEVC, kdyz ma kodeky svoje... a ono to snad vypada, ze v tom ma nejakym zahadnym zpusobem prsty Vivaldi?! Koukam na to jak puk. 

Co muze ovlivnit to, ze aplikace spustena jako potomek nejakeho procesu najednou nikde nevidi svoje vlastni knihovny?


Dekuji za napady.

10

Distribuce / Náhodná změna pořadí hwmon mezi restarty

« kdy: 10. 11. 2021, 21:14:35 »

Zdravicko vespolek,


opet se na vas obracim s zadosti o radu.
Kernel pro Fedoru (5.14.16, ale na verzi patrne prilis zalezet nebude) mi obcas, patrne nahodne podle toho, co se zrovna inicializuje driv, meni poradi polozek v hwmon.

Tedy, treba /sys/class/hwmon/hwmonX je symlink vedouci na zarizeni pojmenovane hwmon0 v /sys/devices/<neco>/<neco>/<neco>/hwmonX

Problem je, ze hwmon0 je behem jednoho bootu na /sys/devices/platform/coretemp.0/hwmon/hwmon0, udelam reboot a najednou je treba na /sys/devices/platform/nct6775.2608/hwmon/hwmon0 (a coretemp.0/hwmon/hwmon0 je najednou coretemp.0/hwmon.hwmon1).

Takze najednou vse, co v monitoringu odkazovalo na hwmon0, realne odkazuje na jine zarizeni.

Da se nejakym zpusobem zafixovat poradi, ve kterem jsou jednotlive moduly nacitany?

Kupr. pouzivam monitorix pro sledovani/grafovani teplot a kde ceho + na to navazane skripty, ale potrebuji najit zpusob, jak se skutecne dostat k tomu, ze CPU je skutecne CPU a ne environment teplota na desce apod.; wildcards v tom konfiguraku patrne nefunguji.

Variantne by to asi slo resit nejakym skriptem na prepisovani konfiguraku pro monitorix podle toho, jestli zrovna existuje /sys/devices/platform/<zarizeni>/hwmon zrovna jako hwmon 0, 1, 2, 3 ...., ale to mi prijde jako dost divnej rovnak na ohejbak.


Dekuji!

11

Distribuce / hostapd funguje, ale ne jako aktivni sluzba (systemd)

« kdy: 12. 09. 2021, 15:27:31 »

Zdravim vespolek a prosim o nakopnuti spravnym smerem.

Presel jsem z CentOS 7 na Fedora 33 a relativne uspesne si zmigroval sluzby a nastaveni.
Jednou z tech sluzeb je hostapd.

Postup:
1) nainstaluji hostapd
2) vyjmu wifi interface ze spravy NetworkManageru
3) systemctl mask wpa_supplicant (mozna je to redundantni k bodu 2 - jednalo se o to, ze wpa_supplicant prilezitostne chtel provadet scan siti v okoli pri jejich predani NM, coz spolehlive shodilo veskerou komunikaci hostapd)
4) zkopiruju svuj fungujici config do /etc/hostapd/hostapd.conf
5) systemctl start hostapd => spusti se hostapd /etc/hostapd/hostapd.conf -P /run/hostapd.pid -B, k AP se pripojim, v systemctl status hostapd vidim uspesne pripojeni. Potud vsechno super.

zář 12 13:26:04 server systemd[1]: Starting Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator...
zář 12 13:26:04 server hostapd[3878]: Configuration file: /etc/hostapd/hostapd.conf
zář 12 13:26:04 server hostapd[3878]: wlp6s0: interface state UNINITIALIZED->COUNTRY_UPDATE
zář 12 13:26:04 server hostapd[3878]: wlp6s0: interface state COUNTRY_UPDATE->HT_SCAN
zář 12 13:26:04 server systemd[1]: Started Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator.
zář 12 13:26:11 server hostapd[3879]: wlp6s0: STA 12:34:56:78:90:ab IEEE 802.11: authenticated
zář 12 13:26:11 server hostapd[3879]: wlp6s0: STA 12:34:56:78:90:ab IEEE 802.11: associated (aid 1)
zář 12 13:26:11 server hostapd[3879]: wlp6s0: STA 12:34:56:78:90:ab RADIUS: starting accounting session B0F61B7A4175C97F
zář 12 13:26:11 server hostapd[3879]: wlp6s0: STA 12:34:56:78:90:ab WPA: pairwise key handshake completed (RSN)

A ted problem.
6) systemctl enable hostapd (aby mi hostapd nabehnul pri restartu sam)
7) reboot => hostapd se sice spusti (se stejnymi parametry, pod rootem, ... jako pri rucnim spusteni), ale neni mozne se k nemu pripojit.
Wireshark ukazuje akorat EAPOL pakety 1 a 2 a komunikace pak vytuhne.
systemctl status hostapd ukaze:

● hostapd.service - Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
     Loaded: loaded (/usr/lib/systemd/system/hostapd.service; enabled; vendor preset: disabled)
     Active: active (running) since Sun 2021-09-12 14:38:53 CEST; 3min 10s ago
    Process: 1278 ExecStart=/usr/sbin/hostapd /etc/hostapd/hostapd.conf -P /run/hostapd.pid -B (code=exited, status=0/SUCCESS)
   Main PID: 1317 (hostapd)
      Tasks: 1 (limit: 18997)
     Memory: 1.6M
        CPU: 119ms
     CGroup: /system.slice/hostapd.service
             └─1317 /usr/sbin/hostapd /etc/hostapd/hostapd.conf -P /run/hostapd.pid -B

zář 12 14:39:03 server hostapd[1317]: wlp6s0: STA 12:34:56:78:90:ab IEEE 802.11: authenticated
zář 12 14:39:03 server hostapd[1317]: wlp6s0: STA 12:34:56:78:90:ab IEEE 802.11: associated (aid 1)
zář 12 14:39:07 server hostapd[1317]: wlp6s0: STA 12:34:56:78:90:ab IEEE 802.11: authenticated
zář 12 14:39:07 server hostapd[1317]: wlp6s0: STA 12:34:56:78:90:ab IEEE 802.11: associated (aid 1)

4 pokusy, nakonec timeout, disconnect, konec.

Vtipne je, ze kdyz udelam:
systemctl stop hostapd

a zkusim jej pustit znovu rucne, tak to nefunguje taky.


Udelam systemctl disable hostapd, reboot, systemctl start hostapd - najednou kouzelne funguje.

● hostapd.service - Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
     Loaded: loaded (/usr/lib/systemd/system/hostapd.service; disabled; vendor preset: disabled)
     Active: active (running) since Sun 2021-09-12 15:12:20 CEST; 12s ago
    Process: 2730 ExecStart=/usr/sbin/hostapd /etc/hostapd/hostapd.conf -P /run/hostapd.pid -B (code=exited, status=0/SUCCESS)
   Main PID: 2731 (hostapd)
      Tasks: 1 (limit: 18997)
     Memory: 1.7M
        CPU: 48ms
     CGroup: /system.slice/hostapd.service
             └─2731 /usr/sbin/hostapd /etc/hostapd/hostapd.conf -P /run/hostapd.pid -B
(a log viz ten prvni, jako kdyz vse bezi)

unit file pro hostapd.service:

[Unit]
Description=Hostapd IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
After=network.target

[Service]
Type=forking
PIDFile=/run/hostapd.pid
ExecStart=/usr/sbin/hostapd /etc/hostapd/hostapd.conf -P /run/hostapd.pid -B

[Install]
WantedBy=multi-user.target

hostapd.conf - funkcni, zde problem uplne neocekavam... 

ctrl_interface=/var/run/hostapd
ctrl_interface_group=wheel

logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2

macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0

ieee80211d=1
country_code=CZ

wmm_enabled=1

driver=nl80211

interface=wlp6s0
hw_mode=g
ieee80211n=1
ht_capab=[HT40-][SHORT-GI-20][SHORT-GI-40]
ieee80211h=1

channel=7

ssid=blablabla
bridge=br_wifi
wpa=2
wpa_key_mgmt=WPA-PSK WPA-PSK-SHA256
rsn_pairwise=CCMP
wpa_passphrase=blablablablabla

V cem muze byt bota?
Napada mne jedine, ze by to mohlo mit co delat s existenci prazdneho bridge br_wifi (jako pokus spustit hostapd driv, nez br_wifi existuje... to by ale, predpokladam, neco zarvalo?).

Google vesmes mlci, tuhle exotiku holt neprovozuje kazdej druhej.
Muzu nejak zkusit start hostapd jako aktivni sluzby oddalit, treba klidne az minutu po bootu, pro overeni nejake zavislosti?