Kein RFKILL und wlan ist aus

[Matthias S. (Gast)]

Hallo.

Während einer Arch-Linux Installation schalte ich meine wlan-Karte immer 
so an, so dass ich mir anschliessend die verfuegbaren ESSIDs ansehen und 
nutzen kann.

rfkill wlp3s0 unblock

Genauso, als würde ich das Interface mit einer Tastenkombi normalerweise 
an- oder ausschalten.

Habe jetzt mal die neueste Debian netinstall drauf gemacht und 
festgestellt, da ist kein RFKILL installiert.

Da das device lt. ip link als state down markiert ist, dachte ich mir ip 
link set wlp3s0 up wuerde die Karte aktivieren, aber dass scheint etwas 
völlig anderes zu sein.

Frage, gibt es unter Debian 9 Console ein Aequivalent zu rfkill oder wie 
startet Ihr Eure Karten??

[Raph (Gast)]

Matthias S. schrieb:
> Frage, gibt es unter Debian 9 Console ein Aequivalent zu rfkill oder wie
> startet Ihr Eure Karten??

Mit systemd

[TestX (Gast)]

https://packages.debian.org/de/stretch/rfkill

[Matthias S. (Gast)]

@TextX Was soll ich damit?

[Daniel A. (daniel-a)]

Ich habe mir soeben die busybox rfkill.c, sowie die linux/rfkill.h 
angesehen. Folgendes Kommando müsste alle softblocks aufheben, und 
verwendet ausschliesslich Shell builtins:

printf '\0\0\0\0\1\3\0\0' >/dev/rfkill

[TestX (Gast)]

@Matthias

rfkill per apt-get installieren...

[Matthias S. (Gast)]

@TestX Ich habe kein aktiviertes wlan -auf meinem zweiten Rechner-, 
deshalb ja das topic des TO.

@Daniel A.

Danke, probiere es gleich mal aus.

[DPA (Gast)]

Matthias S. schrieb:
> @Daniel A.
>
> Danke, probiere es gleich mal aus.

Und, hat es funktioniert?

[Matthias S. (Gast)]

DPA schrieb:

>Und, hat es funktioniert?

Partiell. Die gute Nachricht, ja ich habe das Device /dev/rfkill und es 
hat die Info ’\0\0\0\0\1\3\0\0’ auch ohne zu murren angenommen. 
Funktioniert hat es aber nicht.

Ich lese mich gerade in die Thematik dev... im generellen ein, weil es 
eine gute Sache zu sein scheint, wenn es denn mal funktioniert.

Die Dokumentation hierzu ist nicht gerade üppig oder noch nicht 
gefunden.

0: RFKILL_STATE_SOFT_BLOCKED
  transmitter is turned off by software
1: RFKILL_STATE_UNBLOCKED
  transmitter is (potentially) active
2: RFKILL_STATE_HARD_BLOCKED
  transmitter is forced off by something outside of
  the driver's control.

Ich nehme mal an ich übergebe dem Device in Daniels Lösung ein Byte bei 
dem zwei Bits gesetzt sind. Die 1 erkläre ich mir mit 1: 
RFKILL_STATE_UNBLOCKED, aber zu der Drei finde ich nichts.

Kennt jemand eine diesbezuegliche Dokumentation oder ein Paper, dass das 
Ganze erklärt oder tiefer in die Materie eingeht als die 
Standarddokumentation? Also das Thema RFKILL betreffend, nicht dev... 
im Allgemeinen.

[Matthias S. (Gast)]

Habe ich gerade gefunden. So etwas in der Art hatte ich gesucht.

http://jwhsmith.net/2015/02/manipulating-rfkill-using-devices-programmatically/

[Daniel A. (daniel-a)]

Hier noch die Definitionen der relevanten Konstanten aus meiner 
/usr/include/linux/rfkill.h, damit der Wert auch ersichtlich wird:

enum rfkill_type {
  RFKILL_TYPE_ALL = 0,
  RFKILL_TYPE_WLAN,
  RFKILL_TYPE_BLUETOOTH,
  RFKILL_TYPE_UWB,
  RFKILL_TYPE_WIMAX,
  RFKILL_TYPE_WWAN,
  RFKILL_TYPE_GPS,
  RFKILL_TYPE_FM,
  RFKILL_TYPE_NFC,
  NUM_RFKILL_TYPES,
};
enum rfkill_operation {
  RFKILL_OP_ADD = 0,
  RFKILL_OP_DEL,
  RFKILL_OP_CHANGE,
  RFKILL_OP_CHANGE_ALL,
};
struct rfkill_event {
  __u32 idx;
  __u8  type;
  __u8  op;
  __u8  soft, hard;
} __attribute__((packed));

Bei

printf '\0\0\0\0\1\3\0\0'

interpretiert printf die oktalen escape sequenzen. In hex wäre die 
Ausgabe (kann man mit "printf '\0\0\0\0\1\3\0\0' | hexdump -C" 
nachprüfen):

   idx   type op soft hard
00000000  01  03  00   00

In dem Fall ist type=1 (RFKILL_TYPE_WLAN), also wlan, op=3 
(RFKILL_OP_CHANGE_ALL), soft=0 (aus) und idx ist irrelevent, bei type=2 
RFKILL_OP_CHANGE wäre es die Device nummer gewesen.

Warum es bei dir nicht funktioniert hat, kann ich aber nicht sagen. Wenn 
du eine W-Lan ein/ausschalt Taste hast, die ändern normalerweise den 
hardblock, der nicht von Software aus ausgeschaltet werden kann (ausser 
manchmal vom bios.)

Du kannst den Zustand auch ohne das rfkill Programm anzeigen lassen, für 
diesen Fall ist das (unstabile) Sysfs von der shell aus einfacher zu 
bedienen als das rfkill device. (sollte man aber nicht so in 
Produktivcode umsetzen):

for rfk in /sys/class/rfkill/*/
do
  printf "%s: %s: %s\n\tSoft blocked: %s\n\tHard blocked: %s\n\n" "$(cat "$rfk/index")" "$(cat "$rfk/name")" "$(cat "$rfk/type")" "$(cat "$rfk/soft")" "$(cat "$rfk/hard")"
done

Man kann auch direkt mit cd nach /sys/class/rfkill/<rfkillX> und dort 
die Dateien index, name, type, soft und hard ausgeben lassen (z.B. mit 
cat).

[Matthias S. (Gast)]

@Daniel A.

Erstmal danke, dass Du Dir so viel Mühe gegeben hast und das alles für 
mich aufgedröselt hast.

Das mit dem hardblock, wie mit dem manuellen Tastaturschalter kann 
eigentlich nicht sein, da dass Installationsmedium ja direkt Zugriff 
hatte. Es sei denn, dass Installationsprogramm initiiert den Hardblock 
nach der Installation, was ganz schön unschön wäre.

Ich werde mir Deinen Beitrag in jedem Falle noch genauer zu Gemüte 
führen, nur brauchte ich jetzt eine schnelle Lösung und habe es daher 
mit quick & dirty probiert und es hat geklappt. Dadurch habe ich aber 
nicht gelernt ein derartiges Problem künftig richtig zu umzugehen, daher 
noch einmal danke für Deinen Beitrag.

Ich bin während des Installationsprozesses in die Shell gegangen und 
habe auf das Zielsystem mit chroot target zugegriffen und siehe da, 
kein rfkill, wpa_supplicant etc. mehr nötig. xorg und gnome-core drauf 
und fertig war die Laube -erstmal-.