Dotaz: Udev a RUN - spustit až udev skončí

[Smajchl]

Ahoj lidi, potřeboval bych spustit udevem skript, když nastane nějaká událost, má to ale háček.

Chci, aby při připojení USB bluetooth skript nahodil wifi (jsou na stejném tlačítku), ale ve chvíli, kdy se spustí skript (parametrem RUN), příkazy iwconfig, nebo lspci nevrátí žádný řetězec

Dá se nějak zařídit, že se skript spustí, až udev dokončí svou práci? Zkoušel jsem do skriptu dát sleep, ale to udev nepokračuje a čeká na ten sleep

Obecně jsem tlačítko řešil tady v diskuzi.

Díky za rady.

Odpovědi

[Tomas]

A nešlo by tu udev událost zahákovat na objevení toho WiFi? Napsal jsem kdysi takový prográmek co názorně zobrazoval jaké lze v udev zahákovat zařízení. ( BTW: Ukázka toho, co lze v Tcl/Tk udělat na 80 řádcích.)

[Michal Kubeček]

Používat pro tyto účely udev není příliš šťastné, už vzhledem k tomu, co se píše v dokumentaci o akci RUN. Nešlo by využít HAL a např. ivman?

[Smajchl]

Já nevim jak, když mi poradíš, budu ti vděčný.

[Radek Hladik]

Kdysi s iPAQem jsem to resil velice cunacky nejak takhle:

RUN=script1

script1:

script2 &

script2:

sleep 20
pracuj s iPAQem

Je to opravdu ohavne, stydim se za to, ale zas to trvalo 2 minuty napsat

[Smajchl]

Díky za odpověď, bohužel ani toto nefunguje, iwlist vrací prázdný řetězec i po 30ti sekundách. Možná to je na iPAQu jinak.

Nějaké další nápady??

[petr_p]

i když dám iwconfig, tak tam je wlan0 pořád

Jak to tedy je?

[Smajchl]

pokud zadám iwconfig v konzoli, tak vypisuje pořád to samý, ať je wifi zaplá nebo vyplá.

Když udevem (i s tim, že poběží skript na pozadí) spustim iwlist, iwconfig,lspci... (a výstup přesměruju někam), tak se tam objeví jen prázdná řádka. A já potřebuju otestovat, jestli je síť k dispozici a jestli má smysl se na ní vůbec připojovat a k tomu potřebuju iwlist.

[petr_p]

Pod udevem vám libovolný z příkazů iwlist, iwconfig nebo dokonce lspci vrací prázadný řádek?

To je velmi divné. Jste si jistý, že nemáte ve skriptu chybu? Nevidím jediný důvod, proč by lspci spuštěné z udevu nemělo fungovat.

[Smajchl]

Ano přesně tak. echo s textem funguje, ale toto:

echo `iwlist wlan0 scan` >> /home/smajchl/udev.txt
echo `lspci` >> /home/smajchl/udev.txt

NE, pokud ten skript spustim z konzole tak to funguje. Nemusí se to spouštět třeba přes su nebo sudo?

[Michal Kubeček]

Proboha, jak vás napadlo

  echo `lspci` >> /home/smajchl/udev.txt

Proč prostě nenapíšete

  lspci >> /home/smajchl/udev.txt

což je jednodušší a netrpí problémy s expanzí mezer?

[Smajchl]

Dik za upozornění, já tomu tolik nerozumim Každopádně jsem si říkal, že když echo "bla bla" funguje, že to zkusim dát do echa, ale nefunguje ani jedno, co s tim?

[Michal Kubeček]

Nejpravděpodobnější se mi jeví problém s nastavením proměnné PATH. Zkuste tam napsat celou cestu k tomu příkazu.

[Smajchl]

ó děkuji ti mocný zachránče lspci už funguje jdu nakoupit a pak to rozchodim, ještě jednou díky, tohle mě nenapadlo, i když je to logický...

[petr_p]

Gentoo má něco podobného implementovaného. Já jsem to jednou využil na spuštění konfigurace 802.11 rozhraní po objevení se řídícího zařízení atherosu.

Ovšem jak je to konrétně uděláno, jsem nestudoval. Jen mám pocit, že to nespouští udev, ale hotplug.

[petr_p]

Tak jsem to studoval a je to takto:

V /etc/udev/rules.d je soubor, který spouští přes akci RUN script z /lib/udev. Ten ignoruje síťová zařízení, která se v systému objeví teprve, až když je zařízení ve stavu UP (např. ppp0), a pak spustí klasický init script z /etc/init.d. Jediná výjimka je událost odebrání zařízení, kdy se čeká 2 sekundy, aby zařízení skutečně zmizelo.

V udev(7) se u akce RUN píše, že spouštěný skript by měl rychle skončit, aby neblokoval další udev události. Pro dlouhodobé skripty se doporučuje odpojení se od rodiče, aby rodič pouštený udevem mohl vrátit řízení udevu.

Doporučil bych vám nasadit RUN skript na událost objevení se síťového zařízení wifi karty.

Scénař by měl být takovýto: Přepnete tlačítko, na PCI se objeví zařízení wifi karty, jádro přes modul autoprobing (/proc/sys/kernel/modprobe) natáhne ovladač wifi karty, ten objeví síťové rozhraní, to vyvolá udev, který spustí váš RUN skript, ve kterém si nakonfigurujete síťové zařízení podle potřeby.

[Smajchl]

Dík, ale bohužel to funguje trošku jinak, proto jsem to dělal na připojování bluetooth.

[smajchl@smajlik ~]$ lspci | grep Broadcom
02:04.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
02:0e.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)

Vypnu tlačítko

[smajchl@smajlik ~]$ lspci | grep Broadcom
02:04.0 Network controller: Broadcom Corporation BCM4318 [AirForce One 54g] 802.11g Wireless LAN Controller (rev 02)
02:0e.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)

U bluetooth se děje to, že se jakoby odpojuje z USB, acpi event to negeneruje a keycode už vůbec ne.

[petr_p]

A zařízení 02:04.0 tam vidíte, i když nabootuje s vypnutým tlačítkem?

Pokud ano, pak tlačítko neodpojuje toto zařízení od sběrnice (a musela by to být PCIE a v jádře mít pro ni podporu), ale funguje jako tzv. RF-kill. T.j. na wifině vypne oscilační obvody pro generování a zpracování signálu, ale karta jako taková pořád běží.

Já jsem měl zkušenosti s iw2200, kde ovladač uměl reagovat na událost RF-kill, kterou deska posílala do wifi karty a z ní to ovladač uměl vyčíst. Takže když jsem přepnul tlačítko, tak se v logu jádra objevilo patřičné hlášení. Zrovna tak iwconfig z wireless-tools uměl tento stav správně zobrazit.

Prakticky vzato mi karta včetně síťového rozhraní běžela pořád, a tak jsem ji konfiguroval standardně po bootu.

Chování vašeho hardwaru je poněkud nestandardní. Zkuste hledat ohledně podpory rf-kill v bcm43xx.

[Smajchl]

Jo to je takhle normální (na 90% to tak je i při bootu s vyplou kartou, jedině, když jí zakážu v biosu, tak se v lspci neobjeví, ale co to s tim má společnýho?), i když dám iwconfig, tak tam je wlan0 pořád.

S ovladačem b43 (dřív bcm43xx) mi karta funguje jen trochu, záleží na přesné poloze notebooku, aby to vůbec fungovalo, otočim ho o 10cm a už neproleze paket, takže používám ndiswrapper, hledal jsem informace o rf-kill i u b43, kdyby se do budoucna zlepšil, ale nějak to nemůžu najít, pomoc je vítána

[petr_p]

Společné je to, že přepínáním tlačítka ve skutečnosti PCI nebo 802.11 zařízení wifiny nemizí nebo se neobjevuje. Tudíž na to udev nemůže reagovat.

Nechápu, proč potřebujete reagovat na rfkill tlačítko, když tu kartu můžete zkonfigurovat po bootu? Nebo snad windowsí ovladač má problémy, když je na kartě vypnutý rádio? Obvávám se že pak ale je problém v NDIS wrapperu.

[Smajchl]

abych mohl tlačítkem vypínat wifi a sama se připojovala a nemusel to dělat z konzole.

A k tomu ovladači - má pořád problémy, ale aspoň, když už se připojí (to dá dost práce), tak aspoň je to spojení stabilní, ne jako s b43.

[petr_p]

Ohledně rfkill na b43 jsem našel patch, který exportuje rfkill událost do input zařízení. Je ale třeba mít v jádře zapnuto RFKILL_INPUT.

[Smajchl]

Dík, a jak se to potom používá? Nevím co si pod tou událostí představit.

[petr_p]

Asi se objeví nové vstupní zařízení v /dev/input a z něj lze číst události. Nikdy jsem to nepoužíval ani takový hardware nemám k dispozici. Zkuste návod ve zdrojácích jádra.

[petr_p]

V udev(7) se u akce RUN píše, že spouštěný skript by měl rychle skončit, aby neblokoval další udev události. Pro dlouhodobé skripty se doporučuje odpojení se od rodiče, aby rodič pouštený udevem mohl vrátit řízení udevu.

Zkoušel jste navěsit na RUN akci wrapper, který spustí na pozadí skutčný skript?

#!/bin/bash
skutecny_skript </dev/null &>/dev/null &

[Smajchl]

Ano, to jsem zkoušel, zkoušel jsem i tuto verzi, bohužel...