40
Debian Linux beim Starten automatisch mit offenem W-LAN verbinden
Hallo in die Runde!
Wir möchten unseren IServ-Infobildschirm (auf W-LAN-Basis) mit unserem offenen (weil anders geschützten) pädagogischen W-LAN verbinden. Die automatische Einrichtungsroutine von IServ beherrscht das nicht, und ich habe das Gefühl, dass der IServ-Support keine Lust hat, sich mit dem Thema auseinanderzusetzen.
Die haben mir einen Link auf diese Seite geschickt. Aber da finde ich auch keine Stelle, die sich mit einem offenen W-LAN beschäftigt. Und selbst wenn: Ist es so kompliziert, ein Debian mit einem offenen W-LAN zu verbinden? In dem Artikel steht ja, dass da diverse Tools benötigt werden. Geht das nicht mit "Hausmitteln"?
Wäre schön, wenn da jemand eine zielführende Anleitung hätte.
Schöne Grüße von der Elbe!
Winfried
Wir möchten unseren IServ-Infobildschirm (auf W-LAN-Basis) mit unserem offenen (weil anders geschützten) pädagogischen W-LAN verbinden. Die automatische Einrichtungsroutine von IServ beherrscht das nicht, und ich habe das Gefühl, dass der IServ-Support keine Lust hat, sich mit dem Thema auseinanderzusetzen.
Die haben mir einen Link auf diese Seite geschickt. Aber da finde ich auch keine Stelle, die sich mit einem offenen W-LAN beschäftigt. Und selbst wenn: Ist es so kompliziert, ein Debian mit einem offenen W-LAN zu verbinden? In dem Artikel steht ja, dass da diverse Tools benötigt werden. Geht das nicht mit "Hausmitteln"?
Wäre schön, wenn da jemand eine zielführende Anleitung hätte.
Schöne Grüße von der Elbe!
Winfried
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4156958528
Url: https://administrator.de/forum/debian-linux-beim-starten-automatisch-mit-offenem-w-lan-verbinden-4156958528.html
Ausgedruckt am: 30.12.2024 um 23:12 Uhr
40 Kommentare
Neuester Kommentar
Geht das nicht mit "Hausmitteln"?
Natürlich. Einfach nur die /etc/wpa_supplicant/wpa_supplicant.conf Datei entsprechend anpassen!! 😉ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=DE
network={
scan_ssid=1
ssid="Offenes_WLAN_SSID"
priority=10
key_mgmt=NONE
} Der Paramter key_mgmt=NONE im Setup deaktiviert dann jegliche Verschlüsselung und verbindet sich dann auf offene WLANs ohne Verschlüsselung.
Dachte ich mir
Für mich als Linux-Einsteiger: Ist da außer "Offenes_WLAN_SSID" noch irgendwas ein Platzhalter für einen Wert? Oder ist der Rest so zu übernehmen, wie er da steht?
Rest ist Standard und kannst du so übernehmen. Den Priority Eintrag kannst du, sofern du nur ein einziges WLAN bedienen willst, auch noch entfernen. Der ist nur dafür da wenn man mehrere WLAN Profile hat aber eins bevorzugen möchte. 
Ein iwconfig zeigt dir dann obs geklappt hat.
Nebenbei:
Sehr spannend ist ja auch was "offen aber anders" geschützt bedeuten soll. Hört sich nach einer gruseligen Mac Adressliste an für die das Wort "geschützt" dann natürlich weit übertrieben ist. Sicher ist dann etwas anderes.
Aber gaaanz anderes Thema und gaaanz andere Baustelle.... 😉
Ein iwconfig zeigt dir dann obs geklappt hat.
Nebenbei:
Sehr spannend ist ja auch was "offen aber anders" geschützt bedeuten soll. Hört sich nach einer gruseligen Mac Adressliste an für die das Wort "geschützt" dann natürlich weit übertrieben ist. Sicher ist dann etwas anderes.
Aber gaaanz anderes Thema und gaaanz andere Baustelle.... 😉
1Zitat von @aqui:
Natürlich. Einfach nur die /etc/wpa_supplicant/wpa_supplicant.conf Datei entsprechend anpassen!! 😉
Natürlich. Einfach nur die /etc/wpa_supplicant/wpa_supplicant.conf Datei entsprechend anpassen!! 😉
Bzw. neu erstellen, denn diese Datei gibt es nicht. Aber das bringt auch nichts, denn:
/var/run/wpa_supplicant
Das Verzeichnis gibt es auch nicht.
Was nun?
Wird denn deine WLAN Hardware überhaupt richtig erkannt?? Das solltest du mit dmesg mal prüfen. Sofern die WLAN Hardware richtig erkannt wird, werden auch immer die o.a. Verzeichnisse installiert.
Du kannst das auch mit ip a oder iwconfig sehen ob überhaupt ein wlan0 Interface existiert.
Wenn nicht ist vermutlich die HW Erkennung gescheitert und dann gibts diese Verzeichnisse auch nicht.
Du kannst das auch mit ip a oder iwconfig sehen ob überhaupt ein wlan0 Interface existiert.
Wenn nicht ist vermutlich die HW Erkennung gescheitert und dann gibts diese Verzeichnisse auch nicht.
Es scheint kein wlo0 zu gaben, aber ein wlo1
Mhhh... Rennt bei dir ein Network Manager?
https://wiki.debian.org/WiFi/HowToUse
Was sagt ein iw dev wlo1 scan oder das ältere Kommando iwlist wlo1 scan ? Zeigt das deine umliegenden WLAN Netze an?
Sonst mal manuell mit dem wpa_supplicant Kommando versuchen:
https://blog.droidzone.in/2017/03/troubleshooting-wifi-connection-on-an- ...
https://wiki.debian.org/WiFi/HowToUse
Was sagt ein iw dev wlo1 scan oder das ältere Kommando iwlist wlo1 scan ? Zeigt das deine umliegenden WLAN Netze an?
Sonst mal manuell mit dem wpa_supplicant Kommando versuchen:
https://blog.droidzone.in/2017/03/troubleshooting-wifi-connection-on-an- ...
Da das eine IServ-Installation ist, schließe ich das nicht aus. Wie erkenne ich das ohne GUI?
Was sagt ein iw dev wlo1 scan oder das ältere Kommando iwlist wlo1 scan ?
Das erste Kommando kennt er nicht, das zweite sagt:
wlo1 Interface doesn't support scanning : Network is down
Sonst mal manuell mit dem wpa_supplicant Kommando versuchen:
https://blog.droidzone.in/2017/03/troubleshooting-wifi-connection-on-an- ...
https://blog.droidzone.in/2017/03/troubleshooting-wifi-connection-on-an- ...
Verständnisfrage: Was bedeutet hier das: joel@hp:~$ cat wpa.conf? An der Stelle stand bei Dir ja:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev.
Der Verfasser lässt ganz einfach den Output des Kommandos wpa_passphrase myrouter mypassphrase in eine einfache Textdatei mit dem Namen "wpa.conf" laufen. Das ">" bewirkt das und leitet immer den Konsol Output in eine Datei um.
Er hat die Syntax der Kommandos "wpa_passphrase" etwas widersprüchlich kommentiert.
Gib es einmal ohne das "> wpa.conf" ein dann siehst du den Output auf der Konsole.
Richtig ist also wpa_passphrase <meine_ssid> <mein_wlan_passwort>
Lässt du das Passwort weg wird es interaktiv abgefragt.
Er hat die Syntax der Kommandos "wpa_passphrase" etwas widersprüchlich kommentiert.
user@debiansrv:~ $ wpa_passphrase
usage: wpa_passphrase <ssid> [passphrase]
If passphrase is left out, it will be read from stdin Richtig ist also wpa_passphrase <meine_ssid> <mein_wlan_passwort>
Lässt du das Passwort weg wird es interaktiv abgefragt.
Wie erkenne ich das ohne GUI?
Ob du z.B. ein Tool nmtui hast. Das ist das CLI Konfig Tool für den Network Manager und Interfaces. Versuch das mal aufzurufen. Wenn es onboard ist, ist sehr wahscheinlich der NM aktiv.
Sorry, jetzt sind erst mal zwei Wochen Herbstferien, so lange bin ich nicht vor Ort.
Tip:
Beschaff dir einem preiswerten Orange Pi Zero vom Taschengeld.
Der arbeitet mit dem Netzwerk Manager hat ein LAN und WLAN Interface und du kannst da nach Herzenslust üben und experimentieren und deine Linux Kenntnisse vertiefen!
Darauf werkelt sowohl eine Debian Distro.
https://www.armbian.com/orange-pi-zero/
SD Karte flashen wie beim RasPi, reinstecken und los gehts... 😉
Schöne Ferien!!
Beschaff dir einem preiswerten Orange Pi Zero vom Taschengeld.
Der arbeitet mit dem Netzwerk Manager hat ein LAN und WLAN Interface und du kannst da nach Herzenslust üben und experimentieren und deine Linux Kenntnisse vertiefen!
Darauf werkelt sowohl eine Debian Distro.
https://www.armbian.com/orange-pi-zero/
SD Karte flashen wie beim RasPi, reinstecken und los gehts... 😉
Schöne Ferien!!
So, nun bin ich wieder im Hause.
Und wenn ich die Eingabe des Passworts mit Enter übergehe (denn es ist ja ein offenes wLAN), bekomme ich die Meldung, dass die Eingabe mindestens 8 Zeichen haben muss ...
Da bekomme ich die Antwort, dass er das Kommando nicht gefunden hat. Könnte ich das denn aus jedem Pfad heraus aufrufen? Ansonsten müsste ich ja wissen, wo es ist, aber ein find \ -iname nmtui.* bringt nichts. Genaugenommen findet dieser Befehl gar nichts, egal, was ich eingebe
Gib es einmal ohne das "> wpa.conf" ein dann siehst du den Output auf der Konsole. face-wink
Richtig ist also wpa_passphrase <meine_ssid> <mein_wlan_passwort>
Lässt du das Passwort weg wird es interaktiv abgefragt.
Richtig ist also wpa_passphrase <meine_ssid> <mein_wlan_passwort>
Lässt du das Passwort weg wird es interaktiv abgefragt.
Und wenn ich die Eingabe des Passworts mit Enter übergehe (denn es ist ja ein offenes wLAN), bekomme ich die Meldung, dass die Eingabe mindestens 8 Zeichen haben muss ...
Wie erkenne ich das ohne GUI?
Ob du z.B. ein Tool nmtui hast. Das ist das CLI Konfig Tool für den Network Manager und Interfaces. Versuch das mal aufzurufen. Wenn es onboard ist, ist sehr wahscheinlich der NM aktiv.Da bekomme ich die Antwort, dass er das Kommando nicht gefunden hat. Könnte ich das denn aus jedem Pfad heraus aufrufen? Ansonsten müsste ich ja wissen, wo es ist, aber ein find \ -iname nmtui.* bringt nichts. Genaugenommen findet dieser Befehl gar nichts, egal, was ich eingebe
Da bekomme ich die Antwort, dass er das Kommando nicht gefunden hat.
Debian benutzt ja auch kein Network Manager.Du definierst das Netzwerk immer in /etc/network/interfaces bei Debian.
Das sieht dann für DHCP so aus:
auto wlan0
iface wlan0 inet dhcp
Bzw. bei statischer IP so
auto wlan0
iface wlan0 inet static
address 192.168.1.100
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
Checke vorher mit ip a ob dein WLAN Interface auch so als Device wlan0 existiert! Bei dir heisst es ja scheinbar wlo1 was etwas ungewöhnlich ist. Dann muss iface wlan0 inet dhcp natürlich mit iface wlo1 inet dhcp ersetzt werden.
Die /etc/wpa_supplicant/wpa_supplicant.conf muss natürlich auch passen mit SSID usw.
Zitat von @aqui:
Da bekomme ich die Antwort, dass er das Kommando nicht gefunden hat.
Debian benutzt ja auch kein Network Manager.hm ok, wir sprachen die ganze Zeit von Debian ;)
Du definierst das Netzwerk immer in /etc/network/interfaces bei Debian.
Das sieht dann für DHCP so aus:
auto wlan0
iface wlan0 inet dhcp
Das sieht dann für DHCP so aus:
auto wlan0
iface wlan0 inet dhcp
Bei mir steht da:
auto lo
iface lo inet loopbackMuss ich das "loopback" lassen oder in "dhcp" ändern?
Checke vorher mit ip a ob dein WLAN Interface auch so als Device wlan0 existiert! Bei dir heisst es ja scheinbar wlo1 was etwas ungewöhnlich ist.
Heißt es auch:
(Hatte ich oben schon mal gezeigt: Debian Linux beim Starten automatisch mit offenem W-LAN verbinden)
Die /etc/wpa_supplicant/wpa_supplicant.conf muss natürlich auch passen mit SSID usw.
Die hatte ich ja schon mal nach Deiner Empfehlung umgebaut:
Bei mir steht da:
Da fehlt ja dann vollständig sowohl das LAN als auch das WLAN Interface in der Netzwerk Konfiguration!Das das dann IP technisch in die Hose geht ist klar.
Richtig wäre dort:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The LAN network interface
auto enp88s0
allow-hotplug enp88s0
iface enp88s0 inet dhcp
# The WLAN network interface
auto wlo1
iface wlo1 inet dhcp Denk dran wenn du Änderungen da machst immer systemctl restart networking auszuführen um die neu zu laden oder das System zu rebooten.
https://wiki.debian.org/NetworkConfiguration
Es geht immer noch nicht
Ich habe jetzt den System einmal komplett neu aufgesetzt und nur folgende Veränderungen vorgenommen:
/etc/wpa_supplicant/wpa_supplicant.conf
/etc/network/interfaces
(LAN habe ich weggelassen, dass ist eh nicht verbunden)
Zwei Dinge kommen mir noch spanisch vor:
Wenn Dir das auch spanisch vorkommt, Dich die Neugier packt und Du (im Gegensatz zu mir) einen Testrechner und außerdem über das lange Wochenende Langeweile hast (😁), kannst Du es ja vielleicht mal nachvollziehen. Das Setup kann hier heruntergeladen werden. Dort dann:
Installation -> Deutsch -> Einfache Installation -> Infodisplay (einfacher Grafikmodus)
DANKE!
Ich habe jetzt den System einmal komplett neu aufgesetzt und nur folgende Veränderungen vorgenommen:
/etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=DE
network={
scan_ssid=1
ssid="Unsere SSID"
priority=10
key_mgmt=NONE
} /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source /etc/network/interfaces.d/*
# The loopback network interface
auto lo
iface lo inet loopback
# The WLAN network interface
auto wlo1
iface wlo1 inet dhcp (LAN habe ich weggelassen, dass ist eh nicht verbunden)
Zwei Dinge kommen mir noch spanisch vor:
- Das Verzeichnis /var/run/wpa_supplicant, das in der .conf-Datei erwähnt wird, existiert auf dem System nicht
- Bei ip a steht beim wlo1 "state DOWN" ... ist das Interface irgendwie deaktiviert?
Wenn Dir das auch spanisch vorkommt, Dich die Neugier packt und Du (im Gegensatz zu mir) einen Testrechner und außerdem über das lange Wochenende Langeweile hast (😁), kannst Du es ja vielleicht mal nachvollziehen. Das Setup kann hier heruntergeladen werden. Dort dann:
Installation -> Deutsch -> Einfache Installation -> Infodisplay (einfacher Grafikmodus)
DANKE!
OK, ich versuche mal mein Glück auf einem Intel NUC, der hat ja alles an Bord.
1DANKE! Von der Hardware her passt es, wir verwenden auch Intel-NUCs dafür.
Alter Schwede das ist aber ein hartes Brot... Irgendwas stimmt bei deren Installation grundsätzlich nicht oder ist buggy. Das Verhalten ist absolut unüblich.
Test Hardware ist ein NUC7
Das unsinnige, statische 10er Netz am LAN Interface bekommt man ihm aber schnell abgewöhnt mit Anpassung der /etc/network/interfaces auf DHCP:
Ein "ip a" ergibt dann nach einem Reboot zumindestens schon mal:
Erster Teilerfolg... Bleibt noch das WLAN als Kür 😉
Gut, auch dazu muss die /etc/network/interfaces nochmal angefasst werden um auch DHCP auf dem WiFi Interface machen zu können:
Das WPA Supplicant Package ist geladen also rennt die WLAN Konfig auch damit. Folglich muss eine entsprechende Datei erstellt werden.
Ich hatte zum Testen nur ein WPA2 PSK gesichertes WLAN. Kann es aber auch mit einem offenen nochmal testen wenn du willst. Gehe aber davon aus das es mit einem offenen genauso klappt.
Wie du oben schon sehr richtig bemerkt hast, fehlt zusätzlich im Verzeichnis "run" noch das Sudirectory "wpa_supplicant". Zeigt das deren Installation irgendwie kaputt ist.
Dies Verzeichnis legt man dort als root User mit mkdir wpa_supplicant an und setzt mit chown root:netdev wpa_supplicant die entsprechenden Gruppenrechte.
Et voila... nach einem Reboot oder systemd Restart des Netzwerkes zeigt ein "ip a" dann endlich:
Du kannst den WLAN Start auch mit
wpa_supplicant -B -i wlo2 -c /etc/wpa_supplicant/wpa_supplicant.conf
erzwingen.
Tips:
Wenn du dir mit dmesg oder dmesg | less einmal die Bootmessages ansiehst um zu checken ob das WiFi Interface überhaupt erkannt wurde taucht dort sowas auf:
[ 15.287545] iwlwifi 0000:03:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
[ 15.287655] iwlwifi 0000:03:00.0: Direct firmware load for iwl-debug-yoyo.bin failed with error -2
Das ist kein Grund zur Sorge sondern eine kosmetische Meldung.
Die lässt sich unterdrücken indem du unter /etc/modprobe.d/ eine Datei iwlwifi.conf anlegst mit folgendem Inhalt:
Um auch per SSH mal temporär root Zugriff zu erlangen kannst du die /etc/ssh/sshd_config editieren und dort die Zeile "PermitRootLogin without-password" in "PermitRootLogin yes" ändern. Dann klappts auch von remote mit PuTTY oder Zoc.
Mehr Silbertablett ging jetzt nicht...
Fazit:
Deren Installationsprozedur ist irgendwie krank und kaputt zumindestens entspricht sie nicht dem Standard und bei der Installation definierte Netze werden vollständig ignoriert. Laien werden an der Installation scheitern.
Passiert übrigens sowohl bei der "Infodisplay" als auch bei "Portalserver" Installation.
Das man solche tiefen Frickleien wie oben den Usern zumutet spricht schon für sich. Du solltest, sofern möglich, da mal ein technisches Feedback an die Ersteller loslassen.
Test Hardware ist ein NUC7
- Startet man die Installation ohne angeschlossenes LAN fragt er im Installationsverlauf das WLAN und Passwort ab. Dabei zeigt er alle empfangbaren WLANs an. Ein Indiz das die NIC HW richtig erkannt wurde. (ein späteres dmesg zeigt dies auch!) Die Installation endet aber ohne funktionierendes WLAN und auch ohne funktionierendes LAN! Die entsprechenden Konfig Dateien fehlen vollständig oder sind unvollständig.
- Macht man es andersrum, also VOR der Installation ein DHCP aktives LAN auf das Kupferinterface gesteckt, konfiguriert er nur das LAN, unterdrückt dann aber die Abfrage nach dem WLAN und Passwort und kümmert sich nur ums LAN Interface. Ist die Konfig durch hat er eine statische 10.0.0.x /8er IP mit einem 8er! Prefix auf dem Interface konfiguriert. Völlig wirr...
Das unsinnige, statische 10er Netz am LAN Interface bekommt man ihm aber schnell abgewöhnt mit Anpassung der /etc/network/interfaces auf DHCP:
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source-directory /etc/network/interfaces.d
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eno1
iface eno1 inet dhcp 2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 1c:69:7a:0f:53:50 brd ff:ff:ff:ff:ff:ff
altname enp2s0
inet 192.168.1.157/24 brd 192.168.1.255 scope global dynamic eno1
valid_lft 85497sec preferred_lft 85497sec
inet6 fe80::1e69:7aff:fe0f:5350/64 scope link
valid_lft forever preferred_lft forever Gut, auch dazu muss die /etc/network/interfaces nochmal angefasst werden um auch DHCP auf dem WiFi Interface machen zu können:
iserv ~ # cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
source-directory /etc/network/interfaces.d
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
allow-hotplug eno1
iface eno1 inet dhcp
# WLAN Interface
allow-hotplug wlo2
iface wlo2 inet dhcp iserv ~ # cat /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=/run/wpa_supplicant
update_config=1
country=DE
network={
scan_ssid=1
ssid="Bitschleuder"
psk=1234a8f84b2e57d7ccc10abd1da123456c9fa63a1398913ce1a29b2ef4de5678
key_mgmt=WPA-PSK
pairwise=CCMP
auth_alg=OPEN
} Wie du oben schon sehr richtig bemerkt hast, fehlt zusätzlich im Verzeichnis "run" noch das Sudirectory "wpa_supplicant". Zeigt das deren Installation irgendwie kaputt ist.
Dies Verzeichnis legt man dort als root User mit mkdir wpa_supplicant an und setzt mit chown root:netdev wpa_supplicant die entsprechenden Gruppenrechte.
Et voila... nach einem Reboot oder systemd Restart des Netzwerkes zeigt ein "ip a" dann endlich:
iserv ~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 1c:69:7a:0f:53:50 brd ff:ff:ff:ff:ff:ff
altname enp2s0
inet 192.168.1.157/24 brd 192.168.1.255 scope global dynamic eno1
valid_lft 84660sec preferred_lft 84660sec
inet6 fe80::1e69:7aff:fe0f:5350/64 scope link
valid_lft forever preferred_lft forever
3: wlo2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 24:41:8c:b7:6c:45 brd ff:ff:ff:ff:ff:ff
altname wlp0s12f0
inet 172.16.1.158/24 brd 172.16.1.255 scope global dynamic wlo2
valid_lft 84905sec preferred_lft 84905sec
inet6 fe80::2641:8cff:feb7:6c45/64 scope link
valid_lft forever preferred_lft forever
iserv ~ # ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=60 time=8.26 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=60 time=7.77 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=60 time=7.93 ms
iserv ~ # ping -c 3 www.heise.de
PING www.heise.de (193.99.144.85) 56(84) bytes of data.
64 bytes from www.heise.de (193.99.144.85): icmp_seq=1 ttl=248 time=13.5 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=2 ttl=248 time=13.4 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=3 ttl=248 time=13.7 mswpa_supplicant -B -i wlo2 -c /etc/wpa_supplicant/wpa_supplicant.conf
erzwingen.
Tips:
Wenn du dir mit dmesg oder dmesg | less einmal die Bootmessages ansiehst um zu checken ob das WiFi Interface überhaupt erkannt wurde taucht dort sowas auf:
[ 15.287545] iwlwifi 0000:03:00.0: firmware: failed to load iwl-debug-yoyo.bin (-2)
[ 15.287655] iwlwifi 0000:03:00.0: Direct firmware load for iwl-debug-yoyo.bin failed with error -2
Das ist kein Grund zur Sorge sondern eine kosmetische Meldung.
Die lässt sich unterdrücken indem du unter /etc/modprobe.d/ eine Datei iwlwifi.conf anlegst mit folgendem Inhalt:
iserv ~ # cat /etc/modprobe.d/iwlwifi.conf
options iwlwifi enable_ini=N Mehr Silbertablett ging jetzt nicht...
Fazit:
Deren Installationsprozedur ist irgendwie krank und kaputt zumindestens entspricht sie nicht dem Standard und bei der Installation definierte Netze werden vollständig ignoriert. Laien werden an der Installation scheitern.
Passiert übrigens sowohl bei der "Infodisplay" als auch bei "Portalserver" Installation.
Das man solche tiefen Frickleien wie oben den Usern zumutet spricht schon für sich. Du solltest, sofern möglich, da mal ein technisches Feedback an die Ersteller loslassen.
1Zitat von @aqui:
Et voila... nach einem Reboot oder systemd Restart des Netzwerkes zeigt ein "ip a" dann endlich:
[...]
Mehr Silbertablett ging jetzt nicht...
Et voila... nach einem Reboot oder systemd Restart des Netzwerkes zeigt ein "ip a" dann endlich:
3: wlo2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 24:41:8c:b7:6c:45 brd ff:ff:ff:ff:ff:ff
altname wlp0s12f0
inet 172.16.1.158/24 brd 172.16.1.255 scope global dynamic wlo2[...]
Mehr Silbertablett ging jetzt nicht...
Krass, und das in nur wenigen Stunden ... vielen, vielen Dank!!!
Das man solche tiefen Frickleien wie oben den Usern zumutet spricht schon für sich.
Die muten das den Usern ja nicht zu. Die machen es sich einfach und sagen "Verbinden über offenes wLAN geht nicht"
Zur deren Ehrenrettung: Als WPA-verschlüsseltes wLAN geht es wohl auch so, jedenfalls gibt es in deren Initialisierungs-Skript "iservchk" dieses Fenster:
Aber auf der anderen Seite ist IServ auf ein offenes wLAN ausgelegt, weil der Netzwerkzugang über den Portalserver gesteuert wird. Ein Gerät, das da nicht verankert ist, kann nicht ins Netz.
Die machen es sich einfach und sagen "Verbinden über offenes wLAN geht nicht"
Das halte ich für ein Gerücht. 😉Bekommen wir aber auch noch hin. Ich werde mal das Test WLAN öffnen hier. Feedback kommt...
Zitat von @aqui:
Bekommen wir aber auch noch hin. Ich werden mal das Test WLAN öffnen hier. Feedback kommt...
Die machen es sich einfach und sagen "Verbinden über offenes wLAN geht nicht"
Das halte ich für ein Gerücht. 😉Bekommen wir aber auch noch hin. Ich werden mal das Test WLAN öffnen hier. Feedback kommt...
Huch? Ich dachte, weil ich den ganzen Thread über immer von einem offenen wLAN geredet habe, dass das schon die Lösung dafür war. Ich bin ehrlich gesagt noch gar nicht tiefer eingestiegen, da ich schon Feierabend hatte und erst am Dienstag wieder in der Schule bin.
Also noch mal zur Klarstellung: Es soll in einem offenen wLAN funktionieren. Das war eigentlich der ganze Aufhänger. Bei einem WPA-verschlüsselten Netz vermute ich, dass es auch über das Initialisierungsscript ISERVCHK funktioniert, weil dort ja (siehe Abbildung oben) Felder für SSID und WPA-Key vorhanden sind.
dass das schon die Lösung dafür war.
Dann hast du den Thread nicht richtig gelesen oder verstanden!! ssid="Bitschleuder"
psk=1234a8f84b2e57d7ccc10abd1da123456c9fa63a1398913ce1a29b2ef4de5678
key_mgmt=WPA-PSK
pairwise=CCMP
Sieht nicht wirklich nach offenem WLAN aus oder?! 😉
Ich sagte ja, dass ich noch nicht tiefer eingestiegen bin. Ich bin gerade 80km von dem Gerät entfernt ;)
So, ich weiß nicht, in welchem Bundesland Du lebst, aber bei uns ist das lange Wochenende vorbei und ich habe das Gerät wieder vor mir. Aber Deinen Lösungsansatz kann ich ja gar nicht nachvollziehen, wir haben nun mal kein WPA-verschlüsseltes Netz.
Hast Du schon Gelegenheit gehabt, das für offene Netze weiterzuentwickeln? Oder habt ihr jetzt Feiertag?
Hast Du schon Gelegenheit gehabt, das für offene Netze weiterzuentwickeln? Oder habt ihr jetzt Feiertag?
Ja, funktioniert natürlich auch wie erwartet problemlos mit enem offenen WLAN....
WPA Konfig Datei:
Interfaces:
WPA Konfig Datei:
ctrl_interface=/run/wpa_supplicant
update_config=1
country=DE
network={
scan_ssid=1
ssid="Bitschleuder"
key_mgmt=NONE
} iserv ~ # ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eno1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 1c:69:7a:0f:43:50 brd ff:ff:ff:ff:ff:ff
altname enp2s0
3: wlo2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 24:41:8c:b8:6d:45 brd ff:ff:ff:ff:ff:ff
altname wlp0s12f0
inet 172.16.1.165/24 brd 172.16.1.255 scope global dynamic wlo2
valid_lft 86331sec preferred_lft 86331sec
inet6 fe80::2641:8cff:feb8:6d45/64 scope link
valid_lft forever preferred_lft forever
iserv ~ # ping -c 2 www.heise.de
PING www.heise.de (193.99.144.85) 56(84) bytes of data.
64 bytes from www.heise.de (193.99.144.85): icmp_seq=1 ttl=248 time=13.5 ms
64 bytes from www.heise.de (193.99.144.85): icmp_seq=2 ttl=248 time=13.4 ms
Das will ich gleich mal testen.
Um Tippfehler zu vermeide möchte ich die Dateien von hier auf einen Stick kopieren (und natürlich anpassen) und dann auf dem NUC mit **cat Datei auf Stick >> /etc/network/interfaces// einlesen. Muss ich danach noch irgendwelche Rechte setzen?
Und zu dem oben:
- Kann ich den inet6-Bereich weglassen?
- Benutzer ich als "altname" für das wLAN-Interface das was bei Dir steht oder wlpos20f3 (was bei mir immer bei ip a) angezeigt wurde?
- Brauche ich den "altname" für das LAN-Interface? Da hat er bei mir ja bisher nichts.
Um Tippfehler zu vermeide möchte ich die Dateien von hier auf einen Stick kopieren (und natürlich anpassen) und dann auf dem NUC mit **cat Datei auf Stick >> /etc/network/interfaces// einlesen. Muss ich danach noch irgendwelche Rechte setzen?
Und zu dem oben:
- Kann ich den inet6-Bereich weglassen?
- Benutzer ich als "altname" für das wLAN-Interface das was bei Dir steht oder wlpos20f3 (was bei mir immer bei ip a) angezeigt wurde?
- Brauche ich den "altname" für das LAN-Interface? Da hat er bei mir ja bisher nichts.
Moment mal, das was bei Dir unter "Interfaces" steht, ist doch die Ausgabe von ip a. Wo ist denn der Inhalt für "Interfaces"?
An dessen Setup hat sich doch nix geändert!! Dem ist es doch Wumpe ob ihm ein WPA2 verschlüsseltes WLAN eine IP per DHCP sendet oder ob das ein offenes WLAN tut. 😉
Das bleibt also weiterhin:
Das bleibt also weiterhin:
# WLAN Interface
auto wlo2
allow-hotplug wlo2
iface wlo2 inet dhcp Muss ich danach noch irgendwelche Rechte setzen?
Nein, natürlich nicht wenn das Gateway automatisch per DHCP kommt! Benutzer ich als "altname" für das wLAN-Interface
Nein, immer nur das was auch "ip a" anzeigt. Das ist relevant. Die nutzen eigene Namen und nicht die vom System vorgegeben werden wie wlp0s12f0. Siehe dazu auch hier. Die alternative names kannst du also ignorieren.
Es klappt noch nicht.
Ich fasse noch mal zusammen, nicht dass ich in dem langen Thread etwas übersehen habe:
Mehr nicht, oder?
Kann es vielleicht an der wpa_supplicant liegen? Früher im Thread begann die immer mit
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
In Deinem letzten Beispiel (und das habe ich abgetippt) aber:
ctrl_interface=/run/wpa_supplicant
Demzufolge habe ich das Verzeichnis wpa_supplicant auch nicht unter /var/run/, sondern unter /run/ angelegt. Ist das relevant?
Ich fasse noch mal zusammen, nicht dass ich in dem langen Thread etwas übersehen habe:
- interfaces anpassen
- wpa_supplicant.conf anlegen
- Verzeichnis wpa_supplicant anlegen und Rechte setzen.
Mehr nicht, oder?
Kann es vielleicht an der wpa_supplicant liegen? Früher im Thread begann die immer mit
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
In Deinem letzten Beispiel (und das habe ich abgetippt) aber:
ctrl_interface=/run/wpa_supplicant
Demzufolge habe ich das Verzeichnis wpa_supplicant auch nicht unter /var/run/, sondern unter /run/ angelegt. Ist das relevant?
Das ist richtig, denn das erste Beispiel stammt von einem Rasberry Pi. Ein nacktes, reines Debian hat es aber im Verzeichnis liegen das du unten auch richtig zitierst. Wichtig ist die Group Owner Rechte auf netdev zu legen.
Die 3 anderen Punkte sind richtig. Auf einem NUC mit Intel NIC funktioniert es damit fehlerfrei.
Generell gesagt ist diese Frickelei aber nicht normal und dieser etwas verschrobenen Distro geschuldet.
Auch das eine LAN Konfig statisch mit einem 10er Netz und 8er Prefix hochkommt ist nicht normal und zeugt eher von wenig IP Adressierungs Verständnis. Sieht so aus als ob man hier den Anwendern möglichst viele Steine in den Weg legen will um das zum Fliegen zu bringen. Normal ist sowas nicht...
Die 3 anderen Punkte sind richtig. Auf einem NUC mit Intel NIC funktioniert es damit fehlerfrei.
Generell gesagt ist diese Frickelei aber nicht normal und dieser etwas verschrobenen Distro geschuldet.
Auch das eine LAN Konfig statisch mit einem 10er Netz und 8er Prefix hochkommt ist nicht normal und zeugt eher von wenig IP Adressierungs Verständnis. Sieht so aus als ob man hier den Anwendern möglichst viele Steine in den Weg legen will um das zum Fliegen zu bringen. Normal ist sowas nicht...
Zitat von @aqui:
Das ist richtig, denn das erste Beispiel stammt von einem Rasberry Pi. Ein nacktes, reines Debian hat es aber im Verzeichnis liegen das du unten auch richtig zitierst
Das ist richtig, denn das erste Beispiel stammt von einem Rasberry Pi. Ein nacktes, reines Debian hat es aber im Verzeichnis liegen das du unten auch richtig zitierst
Und es braucht dann auch kein GROUP=netdev wie beim Pi?
Auch das eine LAN Konfig statisch mit einem 10er Netz und 8er Prefix hochkommt ist nicht normal. Sieht so aus als ob man hier den Anwendern möglichst viele Steine in den Weg legen will um das zum Fliegen zu bringen.
Wie gesagt, IServ geht einfach nicht von wLAN-Benutzern aus. Das ist ja, wenn man ehrlich ist, auch eine Notlösung, normalerweise würde ich so ein InfoDisplay immer per LAN anbinden. Und dafür ist die Einrichtung easy - starte nach der ersten Anmeldung als Root einfach mal INETCHK und folge der Anleitung
https://doku.iserv.de/install/infodisplay/. Das bekommt auch ein Linux-DAU hin.
Mir ist gerade noch etwas aufgefallen:
Ich erstelle ja /run/wpa_supplicant
Dann sage ich (in /run/ stehend) chown root:netdev wpa_supplicant
Nur ... nach einem Neustart ist /run/wpa_supplicant wieder weg!?!?!?!?
Ich erstelle ja /run/wpa_supplicant
Dann sage ich (in /run/ stehend) chown root:netdev wpa_supplicant
Nur ... nach einem Neustart ist /run/wpa_supplicant wieder weg!?!?!?!?
Und es braucht dann auch kein GROUP=netdev wie beim Pi
Laut offizieller Debian Doku nicht:https://wiki.debian.org/WiFi/HowToUse#wpa_supplicant
Die Datei wird nur dann angelegt wenn der WPA Dienst aktiv ist! 😉
Nachdem du wpa_supplicant -B -i wlo2 -c /etc/wpa_supplicant/wpa_supplicant.conf eingibst sollte sie wieder zu sehen sein.
Wenn du das o.a. Kommando z.B. nochmal eingibst meckert er das auch entsprechend an...
Zitat von @aqui:
Nachdem du wpa_supplicant -B -i wlo2 -c /etc/wpa_supplicant/wpa_supplicant.conf eingibst sollte sie wieder zu sehen sein.
Nachdem du wpa_supplicant -B -i wlo2 -c /etc/wpa_supplicant/wpa_supplicant.conf eingibst sollte sie wieder zu sehen sein.
Ahhh .. das Kommando hatte ich vorher nicht eingegeben, nun läuft es
Allerdings nur bis zum nächsten Reboot. Gibt es so eine Art "autorun", wo ich die obige Befehlszeile hinterlegen kann, damit sie beim Booten (auch ohne Benutzeranmeldung) automatisch ausgeführt wird? Oder läuft das dann als CronJob oder so?
1
Eigentlich sollte der als systemd Dienst laufen.
Versuche mal ein systemctl restart wpa_supplicant@wlo2.service (bzw. wlo1 als Interface bei dir)
Wenn die offiziell kein WLAN supporten ist der WPA Dienst vermutlich im Systemd bei denen deaktiviert.
Falls das o.a. Kommando das WLAN startet, dann kannst du den Systemd Dienst mit systemctl enable wpa_supplicant@wlo2.service aktivieren so das er beim Booten dann automatisch gestartet wird.
Guckst du auch hier: https://wiki.somlabs.com/index.php/Connecting_to_WiFi_network_using_syst ...
und hier
https://wiki.archlinux.org/title/wpa_supplicant (at boot Kapitel)
Versuche mal ein systemctl restart wpa_supplicant@wlo2.service (bzw. wlo1 als Interface bei dir)
Wenn die offiziell kein WLAN supporten ist der WPA Dienst vermutlich im Systemd bei denen deaktiviert.
Falls das o.a. Kommando das WLAN startet, dann kannst du den Systemd Dienst mit systemctl enable wpa_supplicant@wlo2.service aktivieren so das er beim Booten dann automatisch gestartet wird.
Guckst du auch hier: https://wiki.somlabs.com/index.php/Connecting_to_WiFi_network_using_syst ...
und hier
https://wiki.archlinux.org/title/wpa_supplicant (at boot Kapitel)
Zitat von @aqui:
Versuche mal ein systemctl restart wpa_supplicant@wlo2.service (bzw. wlo1 als Interface bei dir)
Versuche mal ein systemctl restart wpa_supplicant@wlo2.service (bzw. wlo1 als Interface bei dir)
Das funktioniert leider nicht. Ich weiß nicht mal, ob der Befehl ausgeführt wird, es gibt weder eine Fehler- noch eine Bestätigungmeldung. Aber das Verzeichnis /run/wpa_supplicant gibt es danach nicht, daher gehe ich davon aus, dass es nicht geht.
Es geht auch nicht, wenn ich, wie in dem von Dir verlinkten Artikel beschrieben, vorher systemctl restart systemd-networkd.service eingebe.
Wenn ich den Befehl wpa_supplicant -B -i wlo2 -c /etc/wpa_supplicant/wpa_supplicant.conf wieder eingebe, geht es. Aber es dauert minutenlang, bis er dann eine IP-Adresse bekommt, das war beim ersten Mal genauso. Keine Ahnung warum, ich sitze fast direkt unter dem AccessPoint.
es gibt weder eine Fehler- noch eine Bestätigungmeldung.
Das ist normal bei Systemd! Ob der Prozess rennt siehst du immer mit systemctl status wpa_supplicant@wlo2.service !
Aber es dauert minutenlang, bis er dann eine IP-Adresse bekommt
Ist beim Testserver hier ebenso...
Offenbar erwartet er ein Config-File, in dem der Name des Intefaces steht, denn im Status heißt es:
Ich habe die wpa_supplicant.conf nun unter dem Namen wpa_supplicant-wlo1.conf kopiert und dann funktioniert systemctl restart wpa_supplicant@wlo1.service.
Dann habe ich systemctl enable wpa_supplicant@wlo1.service eingegeben und dann funktioniert auch der automatische Verbindungsaufbau nach dem Neustart. Übrigens in Sekundenschnelle
Ich würde sagen: Problem gelöst! Nun muss ich mal schauen, welche Beiträge alles zur Lösung beigetragen haben, damit ich sie markieren kann ;)
Dir erst mal ein dickes DANKE!
Failed to open config file '/etc/wpa_supplicant/wpa_supplicant-wlo1.conf', error: No such file or directory
Failed to read or parse configuration '/etc/wpa_supplicant/wpa_supplicant-wlo1.conf'.
wpa_supplicant@wlo1.service: Main process exited, code=exited, status=255/EXEPTIONIch habe die wpa_supplicant.conf nun unter dem Namen wpa_supplicant-wlo1.conf kopiert und dann funktioniert systemctl restart wpa_supplicant@wlo1.service.
Dann habe ich systemctl enable wpa_supplicant@wlo1.service eingegeben und dann funktioniert auch der automatische Verbindungsaufbau nach dem Neustart. Übrigens in Sekundenschnelle
Ich würde sagen: Problem gelöst! Nun muss ich mal schauen, welche Beiträge alles zur Lösung beigetragen haben, damit ich sie markieren kann ;)
Dir erst mal ein dickes DANKE!
1
👍 Glückwunsch!!
Wirst noch zum Linux Guru! 😉
Vermutlich hätte ein systemctl restart wpa_supplicant ohne "@wlo1.service" dann auch die Standarddatei gestartet. Kannst ja nochmal probieren...
Wirst noch zum Linux Guru! 😉
Vermutlich hätte ein systemctl restart wpa_supplicant ohne "@wlo1.service" dann auch die Standarddatei gestartet. Kannst ja nochmal probieren...
