Příspěvky

1

Distribuce / Re:Debian po probuzení přenastaví síťová rozhraní

« kdy: 02. 03. 2026, 12:36:39 »

Nee.. upgrade jsem nedělal..
a hledal jsem soubory v /etc a /usr a /lib/systemd /lib/udev co mají 70 nebo rules nebo persistent nebo network

a našel jsen
cat /usr/lib/udev/rules.d/65-persistent-net-nbft.rules
# Avoid renaming nbft$X interfaces
SUBSYSTEM=="net", ACTION!="remove", ENV{INTERFACE}=="nbf
t*", NAME:="%E{INTERFACE}"

(kromě /usr/lib/fonts//65-lib/PERSian)

2

/dev/null / připojený USB iphon za hoďku spotřeboval 60min CPU přes upowerd

« kdy: 02. 03. 2026, 12:22:59 »

Tfujtajbl linux! po hodině připojeného iphone za účelem nabíjíní k liuxovému malému SBC jsme si všiml že chladič je horkýl
Proč po připojení iphonu přes usb jsem zjistil, že proces upowerd spotřeboval 95min CPU času? a uptime hlásí 1% 0.5% 0.4%.

teploty cpu byly 69° pro jádro na kterém upowerd proces řádil tempem 98% v htop  a 53° pro zbylá jádra, (běžně idle 41°)  - na pc se nic nedělo.

Na PC je nějaký mate ubuntu , byl spuštěn "do písku" (není k němu připojen monitor a tedy ani přihlášno do DE),. po zapojení monitoru by se hned ukázala grafická přihlašovoací obraovka

Akorát po připojení v dmesg bylo usb-port: cannot enable. maybe the USB cable is BAD
nabíjel se OK, kabel lightieining do USB-A. možná defaultní chování iphonu, že bez odemknutí se nejeví jako datové USB zařízení - netušim

PS: taky jsem měl nějakou hlásku v journalu usbmuxd (shutting down /finished) a měl taky se zhrozil lockdownu v /var/lib

3

Distribuce / Debian po probuzení přenastaví síťová rozhraní

« kdy: 28. 02. 2026, 22:04:18 »

A mám toho dost! Proč po probuzení linuxového PC (z hibernation) se bezdrátová karta jmenuje wlan0 když už jsem byl nucen si zvyknout na krkolomná jména fn5z7b6 nebo ad0lf18SS44

je to debian 13, standartně vidím v dmesg něco jako "udev  detected renamed wlan0 to wllp1s0" mám v systemd/network/.netdev pravidlo pro vytvoření druhého virtual wifi s pevným jménam device a standardně se jmenuje rozhraní wlp1s0.. Stávalo se mi za nějakých okolností že při 1/10 bootů se jmenovalo wlan0. Mám udělat netdev pro toto rohraní? neudělá to bordel  třetí rozhraní? Dokonce jsem i kvůli tomu přizpusobil .network soubor [Match]Name=wlan0 wlp1s0, ale wpa_supplicant@wlp1s0 asi budu muse taky rozdvojit na wpa_suplicant@wlan0 ....

taky mám v dmesg něco jako systemd(1): Timed out waiting for device sys-subsystem-ne-devices-wlp1s0.device a systemd-networkd(454) wlan0 :Interface na name change detected, renamed to wlp1s0

A co hůř! mohu přejmenovat "wlan0" na wlennart0 ale už  na na wlp1s0(a to ani jiný zařízení)  ... RTNETLINK File exists !!! Co to sakra je!!! Odpovim sisám! druhéé virtual wifi rozhraní přebralo jméno wlp1s0 jako altname!

Nějak se ta modernizce nepovedla a nové pořádky. Používám systemd-netwokd plus netwokring (man interfaces)

Druhá věc co m taky rozbila a ktomu bych se chtěl zepat co se děje. Je definovaný síťový most a jen jsem čuměl že ip link hlásí, že síťový most má stejnou mac adresu jako jeho první rozhraní(pro jistotu jiné rozhraní než to co změilo jméno) Zatímco když vytvořím iw interface add virtuální rozhraní bez uvedení mac adresy a snažím se JEDNO z nich dát UP, tak mě to hned praští po hubě "RTNETLINK ANSWERS Name not unique on etwork".Měří linux i mostům stejnym metrem?
proč po probuzení získal síťový most jinou MAC adresu?

A to mě přivádí k otázce: musí mít každý member síťového mostu unikátní mac adresu? I včetně mostu samotného?  nebo se zde může vyskytovat jedna nebo dvě duplicity?

Otázka další: jak bude fungovat wake on LAN a jakou adresu mám zadávat? Nabízí se poznatek, že ve vypnutém=hibernovaném stavu nemá (nedošlo) ke změně MAC adresy.
Ale po třetím, čtvrté hibenaci a nebo po manuální změna mac adresy ? Jakou adresu pak mám zadávat jinému počítači? Reaguje na svou permantní adresu nebo i na nastavenou nově? Projeví se změna pokud ta ethernetová síťovka je v mostu a budu měnit ip link set addr pro dev mostu nebo pro dev karty?

Existuje nějaké zařízení (member mostu) , který je jako primární? Co je KeepMaster?
dotaz mimo: proč neexistuje systemctl sleep příkaz? (THe system will sleep now!  /The system will hibernate now)

4

Sítě / Záložní cesta podle ip nexthop

« kdy: 28. 02. 2026, 21:28:17 »

Myslel jsem že když si zadefinuju pomocí ip nexthop add id a ip nexthop add group + ip route add default nhid, že docílím čeho chci,že ten router bude vybírat na jaký nexthop posílat pakety podle stavu  - bez nějakého exaktního vyjádření - když prostě ten pc bude sám mít nefunkční bránu .(a to jsem nezmínil jednu věc, že v praxi tam budou i nexthopy   přímo v pc  samotném   - (jedna z )brán je síťové rozhraní na tom pc přímo)


příkazy (nexthopy mají konektivitu ven a samotný pc by měl být "access" prvek)

Kód: [Vybrat]

ip nexthop add id 12 via 10.1.0.40 dev e1
ip nexthop add id 11 via 10.1.0.45 dev e1 #(včetně onlink???)
ip nexthop add id 1 group 11/12 type resilient buckets ???  idle_timer ??? unbalanced_timer xxx
ip route add default nhid   1 Proto bych chtěl porozumět, jestli na tohle je ip nexthop ta správnávěc. Myslel jsem že právě type resilient místo typu mpath(default) bude fungovat podle představ

nebo jinak cíl je aby když jeden z nexthopů nebude mít spojení do netu, aby se nepoužil -
a ještě jinak- mít jako druou, /třetí/ nexthop jako záložní když hlavní routa vypadne

Ono to nějak funguje, třeba ping nejde traceroute ano, číst TCP z nějakých adres ano.
čili z toho mam pocit že to funguje na principu ruské rulety (ip route get 45.67.x.y mi vrací střídavé hodnoty)

Dá se to docílit tímhle? Nebo je to naástroj mimo? podle resilient spíš mám pocit, že to jen nějak stabilizuje hash lookup, aby  se minimalizoval "reordering" cílových nexthopů.. a


Ale je důsledek, že si s tím tenhle záměr nesplním?

5

Server / Re:Aký robot robí takéto nájazdy na http?

« kdy: 19. 02. 2026, 16:10:18 »

čeho je to graf? opravdu http požadavků? Nebo počtu tcp spojení ?graf má víc os Y a neviim co která znamená.

Na osi Y je počet HTTP requestov za 5 minút. Viac osí tam nie je, iba tá jedna.
[/quote]
Tady někdo umí cestovat v čase... Myslel jsem na prvním příspěvku(ani jsem nemohol reagovat na druhý screenshot) . Tam vidím zeleou hnědou, fialovou

napovědělo by apache-log, co je obsahem

6

Distribuce / systemd mi znemožní přihlášení na dvě minuty

« kdy: 19. 02. 2026, 16:06:59 »

Chtěl jsem si konsolidovat síťovou konfiguraci a tedy popsat ip adresy deklarativně, rozhraní přes sytemd-networkd a networking.service a wpa_supplicant@
po bootu mě systemd hodil přes palubu že se nemohu přihlásit způsobem že  lennartD mě vyfakuje hláškou

"System is booting up. Unprivileged users are not permit
ted to log in yet. Please come back later. For technical
 details, see pam_nologin(."

i přestože se hlásím přes ssh jako root (možná se pojem non-root v man pam_rabbit nevztahuje na ssh login)
systemd-analyze blame mi udělá 2minutový zásek  sisyfos-systemd-suck-etc/systemd/system/network-online.target.wants/systemd-networkd-wait-online.service
 (tak se asi jmenuje Lennartovo dcera)

Kód: [Vybrat]

úno 19 15:20:32  systemd[1]: Finished networking.service - Network initialization.
úno 19 15:20:32  systemd[1]: Reached target network.target - Network.
úno 19 15:20:35  systemd-networkd[483]: vmbr0: Gained carrier
úno 19 15:20:37  systemd-networkd[483]: vmbr0: Gained IPv6LL
úno 19 15:20:48  systemd[1140]: Listening on dirmngr.socket - GnuPG network certificate management daemon.
úno 19 15:22:31  systemd-networkd-wait-online[522]: Timeout occurred while waiting for network connectivity.
úno 19 15:22:31  systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exit, status1/FAILURE
úno 19 15:22:31  systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
úno 19 15:22:31  systemd[1]: Failed to start systemd-networkd-wait-online.service - Wait for Network to be Configured.
úno 19 15:22:31  systemd[1]: Reached target network-online.target - Network is Online.
úno 19 15:22:31  systemd[1]: Starting lxc-net.service - LXC network bridge setup...

a speciáně

Kód: [Vybrat]

systemctl status systemd-networkd-wait-online.service -ocat
#to je asi lennartovo syn of bitch
úno 19 15:20:30 systemd[1]: Starting systemd-networkd-wait-online.service - Wait for Network to be Configured...
úno 19 15:22:31  systemd-networkd-wait-online[522]: Timeout occurred while waiting for network connectivity.
úno 19 15:22:31  systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
úno 19 15:22:31 systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
úno 19 15:22:31  systemFailed to start systemd-networkd-wait-online.service - Wait for Network to be C
onfigured.Podotýkám, že na konfig interfacew na kterym je default gw jsem nešahal!

7

Distribuce / Re:Deklarativní přidání druhého Wi-Fi rozhraní

« kdy: 19. 02. 2026, 15:47:38 »

Tak se podařilo.  vytvoření /etc/systemd/network/x.netdev
[NetDev]
Name
Kind=wlan
Description
[WLAN]
Type=ap #station/ad-hoc ... neodpovídá Typům v iw interface add type managed,ibss
PhysicalDevice

Poznatek bokem
Není možnost tam kam vložit parametry pro hostapd, asi to vypadaá že jen hostapd@ap.service dokáže spustit hostapd

Poznatek 2 - v systemd je bordel:
wpa_supplicant@if.service má pattern /etc/wpa_supplicant/wpa_supplicant-%i.conf
zatímco
hostapd@if.service má pattern /etc/hostapd/%if.conf

Takhle jsem si to nepředstavoval lennarte

Je nějaký faktický rozdíl v Type? funguje hostapd i s Type=station...

8

Server / Re:Aký robot robí takéto nájazdy na http?

« kdy: 19. 02. 2026, 15:40:08 »

175.36.55.0/22 TCP_Sy.nn třeba?

9

Server / Re:Aký robot robí takéto nájazdy na http?

« kdy: 19. 02. 2026, 15:33:33 »

čeho je to graf? opravdu http požadavků? Nebo počtu tcp spojení ?graf má víc os Y a neviim co která znamená.

10

Distribuce / Re:Deklarativní přidání druhého Wi-Fi rozhraní

« kdy: 18. 02. 2026, 13:50:37 »

Ano zvládnou. Vždyť to píšu,že pak na druhé pak souběžně rozjedu hostapd..
Jen chci vědět  který konfigurák upravit . chci málo, aby se mi po startu narodilo druhé rozhraní sdílející stejný wiphy index jako má první..

Přinejhoršim to udělám přes etc/rc.local ale obávám se,že ten se exekuje třeba později a jak třeba si s tim poradí /etc/network/interfaces.d/h když tam bude nějakou dobu neecustující interface... Řeší to direktiva iface  allow hotplug


Dál mam jeden problém, funguje to jen když spustim nejprv wpasupplicant a pak hostapd. V obracenym poradi, kdy hostapd běží, suplicant skončí chybou (něco jako SME failed interface driver), kanál je tam natvrdo , protože musí být shodný jako kanál vzdáleného AP(obě rozhraní té karty musí sdílet tentiž kannál) ...

11

Distribuce / Deklarativní přidání druhého Wi-Fi rozhraní

« kdy: 17. 02. 2026, 22:24:32 »

Zdravím, hledám způsob jak na debianu 13 přidat druhé wifi rozhraní deklarativně, aby bylo dostupné při startu systému . Takže "při bootu" není uplně přesné.
Nyní mám wlp1s0 který vychází z wiphy0. (MMch by mě zajímalo, de je definované, že vznikne aspoň to jedno wifi link rozhraní na každé wiphy rohraní)

Ručně se to dělá přes "iw ___ interface add type managed addr 00:01:bc..." , kde _ může být phy nebo  wifi.


Aby s tím mohl pracovat systemd-networkING (/etc/network/interfaces.d), případně hostapad (neplést managed -to je spráný údaj pro hostapd)

Kam zabrousit? NEbo to jde až do udev? /etc/systemd/network?

12

Windows a jiné systémy / Re:WireGuard se na Androidu rozpadne po vypnutí obrazovky

« kdy: 01. 02. 2026, 17:49:20 »

Po té úpravě wireguard- Optimalizace :Neoptimalizováno na jsem si na 90% jistý,že   smartphone  bude mít wireguard tunel stále dostupný.  Těch 10% je androidovská nejistota, protože tohle mi tenhle OS je nevypočitatelný, tím spíš v každé nové verzi, kde se něco vyhodí ,něco překope.
(poznámka, po změně nastavení je nutné appky Ukončit a znovu spustit.)

13

Sítě / Víc SSID se síťovkou bez interface combinations

« kdy: 01. 02. 2026, 17:37:09 »

Mám wifi kartu, a chci na jednom rádiu( na jedné usb wifi kartě) zprovoznit víc SSID (a tím pádem mít víckrát interface v ip link abych s tim mohl pracovat).. Je to možný?
nejdřív se zeptám, jsou oba přístupy totožný?
1. přes `iw wlan0 add interface ap1 type managed mac 01234....` si mohu přidat nové interface. Jenže to platí jen do toho limitu v výpisu dole (#total , #AP) v příkladu-  ( a jako bonus chyba linux je, že si jch mohu přidat milión, ale začne to házet Resource busy až v momentě kdy chci dát ip link set ap5 up nebo spustit hospad - něco z toho - možná je to schválně dynamicky reportované právě z důvodu že dopředu se neví jestli interface bude AP/STA)

2. obejít interface combinations a v hostapd si definovat nové direktivy bss a ssid  . Zde poněkud příkladů na internetu moc není v podstatě googlím "multiple hostapd ssid same card" nebo single band multissid . A

příklady:
))1 (pozor, jde o openbsd) , ))2  ))3

Drtivá většina karet umí jen 1 frekvenci a  maximálně AP+client současně.

Kód: [Vybrat]


příklad štědré karty která zrovna umí  toho víc
         software interface modes (can always be added):
        valid interface combinations:
                 * #{ managed } <= 1, #{ P2P-device } <= 1, #{ P2P-client, P2P-GO } <= 1,
                   total <= 3, #channels <= 2
                 * #{ managed } <= 1, #{ AP } <= 1, #{ P2P-client } <= 1, #{ P2P-device } <= 1,
                   total <= 4, #channels <= 1

Jde to? Nebo je na to uplně jiná technologie MBSSID?

PS: a co znamená první řádek z mého výpisu? ("software interface modes (can always be added):")

14

Windows a jiné systémy / Re:WireGuard se na Androidu rozpadne po vypnutí obrazovky

« kdy: 01. 02. 2026, 17:22:27 »

Ahoj nikdy jsem wireguard s keepalivem na smartphonu neprovozoval,ale zkusil jsem to,pouze jsem si v konfiguraci appky vyplnil nenulový keepalive a uvidil co se bude dít. Ale jak čtu dotaz, kouká z toho na mě jedna věc, sice zmiňuješ wireguard x krát, ale prakticky chceš využít nějakou appku co poslouchá, (něco v terminálu, minimalistické nc -L -p 80 ) nebo přímo nějakou appku
 a tím se projeví rozdíl mezi ping a tcp connect = to je má teorie . tím se určí jestli je problém jen s zmraženou appkou nebo "appkou wireguardu"=nejde ani ping

Mé body k tomu:
v čem je problém, v jaké appce?  nebo ani ping nejde?
jsi na ipv4 či ipv6? nebo nějaké další tunely ?
mě to jde - - velice podobný konfig, LTE, IPv4, lineage (to fakt už je verze 22???)
beží wireguard v režimu root nebo userspace (volba v nastavení)

pravidelný ping 200ms (díky pomalýmu master serveru)
první ping po delší době 500ms

případně  sada pingů 2700ms, 1700ms, 122ms,155m,166ms.


... jednou v testování se mi stalo, že telefon neodpovídal ani na ping  ani na primitivní TCP "echo".

Problém je někde v konfigu lineage os, je tam víc úrovní wake lock, teď to asi nedokážu dohledat a jsou to různá doze a  co hůř , ty timeouty běží i k půl hodině, (to znamená, že až po půl hodině  nejpozději od zhasnutí se projeví, že appka odumře)

Asi 15 minut jsem di dal práci a hledal, jak jsem to nastavoval, není to soubor, ale mění se to příkazem:
https://gitlab.com/LineageOS/issues/android/-/issues/3431
 adb shell dumpsys deviceidle whitelist +com.android.messaging
adb shell dumpsys deviceidle whitelist +com.android.phone ...


NIcméně zkusil bych jednodušší test nejdřív,před editycí sys souborů
- wake lock v termuxu - přesně tak se chová skript v termuxu- zhasne obrazovka, skript se uspí bez wake locku
- najít :wireguard (+ aplikace)- Info oaplikaci -  využití baterie -2. položka optimalizace baterie, pokusit se zmenit z Optimalizovanáno na neoptimalizováno (provedení v ui je tristní - místo přepínače vyjede seznam všech appek, nahoře vyber optimalizovanáno- přepni na neoptimalizované, v seznamu vyber wireguard a appku a dej neopotimalizovat), tím pádem první položka Omezit využití zšedne.


PS: pokud má android appka, která naslouchat na portu, být špuštěna, zobrazí se nějaký dialog povolení oprávnění??? Neidky v android os jsem neviděl přes dlouhý seznám oprávnění něco jako povolit poslech na portu xyz.

15

Sítě / Jak dopadne komunikace WireGuardu když protistrana umře

« kdy: 21. 12. 2025, 18:12:00 »

Jak koncové body wireguardu mají nastavené kontaktování peera (vytvoří se paket u kterýho se určí že má vyjít tunelem), pokud ten peer umře?  Myslím tím až s nějakým odstupem času, když se peer nějakou dobu neozývá.

Na co se chci zaměřit a hrát to bude roli bych řekl jsou dvě nastavení:
1. zadaný nebo prázdný Endpoint (můžou ho mít v konfigu obě strana, nebo první strana nebo druhé strana. ) Možná to ale nehraje roli
2. definovaný persitent keepalive (ano/ne u obou stran)


Jak to funguje? Kloním se k tomu, že jednička nehraje roli, že si peer bude držet adresu protistrany nadosmrti )ikdyž předtím ji neměl v konfigáči) a tím efektivně bude adresu peera znát vždy. Ale jak tam vystupuje druhý faktor ten nat keepalive? Slouží ten keepalive jen k tomu aby nevyschlo spojení přes nat (jenom koná),a nebo podle toho se i rozhoduje,že po uplynutí persistent keepalive si domyslí, že spojení právě vyschlo a nebude se pokoušet posílat takovéému peerovi nic

postrádám tady nějaký parametr alive-timeout, případně passive-only to asi wireguard nemá