freies wlan, Verbindungsprobleme

[guennid]

Es läuft, Herr TomL!!!

Das hier wird geschrieben unter Verwendung von selnic. Im Abschluss irgendwie etwas schwach: Im trace-Fenster lese ich, dass die Verbindung steht und dann würde ich selnic gerne beenden, finde dazu aber keine Auswahl im Menü.

Grüße, Günther

edit:
dieses unhandliche "Standard"-Terminal xterm sollte zumindest scrollbar gestartet werden. Musste ich erst wieder deinstallieren, um die darin befindlichen Meldungen simpel (mittlere Maustaste) transferieren zu können.
Ist selnic abhängig von udev?
Wäre jetzt interessant, zu sehen, was da bei einem "freien" hotspot in der wpasupplicant.conf stünde. Einen solchen habe ich leider nicht mehr. Und in D wird man auf sowas wg. "Störerhaftung" auch nicht stoßen - richtig?

[TomL]

Prima. Einfach "abbrechen" anklicken oder schlichtweg das Fenster schließen. selnic ist kein daemon, sondern eine simple Vordergrund-Anwendung.

Und wenn du am ende die Verbindung trennen möchtest, selnic erneut starten, das Sternchen bei der Verbindung rausnehmen, "OK" klicken und wenn's getrennt ist "abbrechen" anklicken oder Fenster schließen. Leider konnte ich den Button "abbrechen" nicht in "beenden" umbenennen.

Ich habe mir dafür nen Desktopstarter angelegt, allerdings ohne tracemode... das funktioniert im Regelfall total easy.
Im normalen Betrieb ist xterm gar nicht notwendig, das ist nur zum gucken, was passiert, wenns irgendwie nicht funktioniert. Für den täglichen normalfall nervt mich das eher und ich starte es ohne trace-ausgaben... ist doch eh immer dasselbe ...

Btw, selnic hat keinen Einfluss auf die Verbindungsqualität.

[TomL]

dieses unhandliche "Standard"-Terminal xterm sollte zumindest scrollbar gestartet werden. Musste ich erst wieder deinstallieren, um die darin befindlichen Meldungen simpel (mittlere Maustaste) transferieren zu können.

Das solltest Du gar nicht so tun.... das geht doch viel einfacher. Die Trace-Ausgabe ist einfach nur ne Log-Datei-Ausgabe im Verzeichnis /tmp über "tail". Wenn Du also selnic zusätzlich mit "-h" startest, wird bei Programmende die Log-Datei nicht gelöscht und Du kannst sie mit jedem Editor öffnen. Schau Dir die dritte Zeile direkt nach dem Programmstart an, da steht der Log-Filename, der mit 'tail' im xterm-Fenster angezeigt wird.

Code: Alles auswählen

Tracemode is on
TraceOn(1)                     BASHPID=1117  TracePID=1127
TraceOn(2)                     TerminalApp=/usr/bin/xterm  TraceFileName=/tmp/selnic_trace.1117

Also, dieser Aufruf bedeutet, Trace-Mode, Hold der Log-Datei, No Save-Abfrage, Set Primary NIC

Code: Alles auswählen

selnic -t -h -n -s wlp3s0

Ist selnic abhängig von udev?

Selnic ist von nix abhängig, verstellt nix und kümmert sich auch um nix. Die einzige Problemquelle ist, wenn andere Dienste vielleicht etwas wieder rückgängig machen würden und damit einen vorherigen Zustand wiedeherstellen wollen.... also selnic verbindet mit Netz B, aber der Networkmanager meint, er müsse wieder zurück auf Netz A, obwohl das vielleicht gar nicht verfügbar ist, aber er trennt dabei Netz B..... wobei ich nicht sicher weiss, wie und ob der sich da wirklich reinhängt. Mit WICD hatte ich zwischenzeitlich irgendwelche Probleme, weil der sich auch immer irgendwie als Boss über alles aufgeführt hat.... muss nicht sein, kann aber möglicherweise. Selnic kümmert sich jedenfalls um nix und pfuscht auch keinem anderen ins Handwerk und 'handelt" ganz konkret NUR auf Anweisung des Users über sein/das Menü.

[guennid]

Selnic ist von nix abhängig, verstellt nix und kümmert sich auch um nix. Die einzige Problemquelle ist, wenn andere Dienste vielleicht etwas wieder rückgängig machen würden und damit einen vorherigen Zustand wiedeherstellen wollen.... also selnic verbindet mit Netz B, aber der Networkmanager meint, er müsse wieder zurück auf Netz A, obwohl das vielleicht gar nicht verfügbar ist, aber er trennt dabei Netz B..... wobei ich nicht sicher weiss, wie und ob der sich da wirklich reinhängt. Mit WICD hatte ich zwischenzeitlich irgendwelche Probleme, weil der sich auch immer irgendwie als Boss über alles aufgeführt hat.... muss nicht sein, kann aber möglicherweise. Selnic kümmert sich jedenfalls um nix und pfuscht auch keinem anderen ins Handwerk und 'handelt" ganz konkret NUR auf Anweisung des Users über sein/das Menü.

Das ist mir zu viel Rundumschlag. Meine Frage ist ganz konkret: Muss udev installiert sein, damit selnic ordentlich arbeitet?
Sobald ich zurück bin, werde ich nämlich versuchen, nicht nur wicd, sondern eben auch udev wieder loszuwerden, um mein Vor-Aussie-Land-System möglichst vollständig wieder herzustellen. Ich schätze, dass das (z.B. wegen X) einigen Aufwand erfordern wird. Den werde ich mir hier nicht antun. Und ich möchte dich auch nicht veranlassen, jetzt deinerseits probeweise dein(e) mit so "neumodischem Kram" wie systemd und udev funktionierende(s/n) System(e) udevlos und damit möglicherweise unbrauchbar zu machen. Ich ziehe das zu Hause durch, dann werden wir sehen, ob selnic udev benötigt oder nicht.

Von meiner Seite aus kann dieser Thread ruhen, bis es soweit ist.

Nochmals vielen Dank!
Grüße, Günther

[TomL]

Meine Frage ist ganz konkret: Muss udev installiert sein, damit selnic ordentlich arbeitet?

Nein, das wird nicht verwendet und ist auch keine Voraussetzung. Sofern das Device NICHT wlan0, wlan1, usw. heisst, musst Du selnic einfach nur wie jetzt auch den Namen mit -s mitteilen. Darüber hinaus ist nichts.....

[guennid]

In meinem letzten Beitrag habe ich nachträglich rumgefummelt und das hat sich wohl mit deinem zeitlich überschnitten, ohne dass die Änderung von der Forensoftware angemerkt worden wäre. Ich denke, dass ich nichts Wesentliches verändert habe, kannst aber sicherheitshalber nochmal reinschauen.

[TomL]

In meinem letzten Beitrag habe ich nachträglich rumgefummelt und das hat sich wohl mit deinem zeitlich überschnitten, ohne dass die Änderung von der Forensoftware angemerkt worden wäre. Ich denke, dass ich nichts Wesentliches verändert habe, kannst aber sicherheitshalber nochmal reinschauen.

Es wird meiner Meinung nach weder systemd, noch udev, noch ein Desktop-Environment benötigt. Sogar das trace-fenster (welches man im Normalfall aber gar nicht benötigt) kann auch ein textbasiertes sein... da ist lxterminal voreingestellt. Die Anforderungen sind imho minimal. Im Anschluss sind die Abhängigkeiten, bzw. die 'externen" Programme, die selnic für seine Tätigkeiten verwendet, also alles Tools oder Programme, die üblicherweise (bis auf dialog) sowieso auf dem Rechner sind. Darüber hinaus ist nix.

/sbin/iw
/sbin/ip
/sbin/dhclient
/sbin/wpa_supplicant

/usr/bin/tail
/usr/bin/dialog
/usr/bin/pkill

/usr/bin/xterm oder
/usr/bin/urxvt oder
/usr/bin/lxterminal oder
/usr/bin/xfce4-terminal

[guennid]

Ich glaub's dir ja. Aber da ich ja, wie du auch schon bemerkt hast, dazu neige, die Dinge komplizierter zu sehen als sie sind , überlege ich, welches der von selnic benutzten anderen tools von udev abhängen könnte. (trace und dialog hatte ich, weil optional, schon ausgeschlossen) und bei dem Rest fällt mir auch nichts ein. Aber: Vorsicht ist die Mutter der Porzellankiste! - Wir werden sehen.

Übrigens: Um Terminalausgaben in einen Editor zu transferieren, gibt es meiner Meinung nach nichts Einfacheres, als die geniale Möglichkeit, sie mit der Maus zu markieren und dann mit mittlerer Maustaste da hineinfallen zu lassen. Aber wenn das Fenster nicht scrollt (default bei xterm), ist man bei längeren Ausgaben natürlich aufgeschmissen.

Grüße, Günther

[TomL]

Übrigens: Um Terminalausgaben in einen Editor zu transferieren, gibt es meiner Meinung nach nichts Einfacheres, als die geniale Möglichkeit, sie mit der Maus zu markieren und dann mit mittlerer Maustaste da hineinfallen zu lassen. Aber wenn das Fenster nicht scrollt (default bei xterm), ist man bei längeren Ausgaben natürlich aufgeschmissen.

Wie kommst Du denn da drauf? *lacht* Das geht unter xterm ganz genauso.... man scrollt im Fenster mit dem Mouserad, markiert mit Klick eine Position und zieht dann mit gehaltenem Rechtsclick die Markierung soweit runter, wie man will. Man kann den Rechtscklick auch einfach loslassen, mit dem Rad weiterscrollen und mit erneutem Rechtsklick die Markierung erweitern. Aber mir ist das zu umständlich, ich öffne lieber einfach die Datei und habe alle Ausgaben ohne Umwege. Aber wie gesagt .... gehen tut beides....

[guennid]

Das wird jetzt aber OT und ist auch eigentlich belanglos:
Meine thinkpads haben kein Mausrad und es ist mir nicht gelungen, in xterm mit dem Trackpoint über den oberen Fensterrand hinaus zu markieren. Xterm zu "studieren" hatte ich keine Lust - es gibt ja einfache Alternativen.

[CBG]

Hi,

cookies sind zu 95% das Problem!

Sprich, dass dein Rechner, bzw Browser keine Cookies akzeptiert.

In freien WLAN musst du Cookies meistens sogar von dritten akzeptieren.

Ich hatte mal das Problem.

Vielleicht hilft es ja.

Bis dann

[guennid]

cookies sind zu 95% das Problem!

Vermag ich nicht zu beurteilen, gebe aber zu bedenken, dass sowohl wicd las auch TomLs script eine Verbindung herzustellen vermochten, ohne dass ich die Cookie-Einstellungen ändern musste.

Um nochmal darauf zurückzukommen: Probleme hatte ich (mit meiner "veralteten" Software (ifup/ifdown, iwlist, /etc/network interfaces, Benutzung von wpasupplicant ohne wpasupplicant.conf)) nur, wenn der Zugang zum AP nicht passwortgeschützt war (TomLs WISP-Terminologie ist neu für mich, da kenne ich mich ebenfalls nicht mit aus).

Da ich nun wieder zu Hause bin, und ich dem gerne auf den Grund kommen würde, zum Ausprobieren aber wie o.a. einen geeigneten Zugangspunkt benötigte: Gibt es sowas bei uns in Deutschland überhaupt? Ist das für den Betreiber nicht rechtlich riskant (ungeschützter AP), so dass man das kaum finden wird?

Grüße, Günther

[TomL]

Probleme hatte ich (mit meiner "veralteten" Software (ifup/ifdown, iwlist, /etc/network interfaces, Benutzung von wpasupplicant ohne wpasupplicant.conf)) nur, wenn der Zugang zum AP nicht passwortgeschützt war

Ich glaube, Du misst dem "mit Password" und "ohne Password" zu viel Bedeutung bei. Die Schritte zur Herstellung einer Verbindung sind bei beiden eigentlich identisch. Und dort, wo ein Verschlüsselungs-Password (WPA/WEP) für den Funkverkehr benötigt wird, nutzt man halt die WPA-Passphrase.... das wars dann auch schon. Das hat alles gar nichts damit zu tun, dass möglicherweise bei bestehender Verbindung vielleicht noch eine "Kunden-Passwort" im Browser abgefragt wird. So ein nachgeschaltetes (!) Password hat nix mit der Verbindung an sich zu tun. Die Verbindung ist mit wenigen Schritten hergestellt:

Adapter öffnen und Netze scannen:

Code: Alles auswählen

ip link set dev wlan0 up
iw dev wlan0 scan | /bin/grep -i 'ssid:\|signal:\|associated'

Ggf. die Passphrase für den WPA-Key generieren und in die Conf mit den Verbindungsdaten übernehmen:

Code: Alles auswählen

wpa_passphrase $WISPName $Password

Die Verbindung herstellen und eine IP anfordern. Man kann dafür auch immer die gleiche Conf verwenden, wenn man jedesmal die Verbindungsdaten aktualisiert oder die "alten" WISP-Daten mit # kommentiert, genau gleich wie das in der 'interfaces' möglich wäre.

Code: Alles auswählen

wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant/wlan.conf -D nl80211,wext
dhclient -v wlan0

Am Ende trennen, Müll beseitigen und WLAN-Adapter schließen

Code: Alles auswählen

pkill -f wlan.conf
dhclient -r wlan0
ip link set dev wlan0 down

Das ist prinzipiell nichts anderes, als Du vorher auch gemacht hast. Und ob die Conf nun "/etc/wpa_supplicant/wlan.conf" oder "/etc/network/interfaces" heisst, ist ja nun nicht wirklich wichtig. Man könnte sie ja sogar auch in "/etc/network/wlan.conf" ablegen.... ganz wie es beliebt.
Und "alt" oder "nicht alt" würde ich darauf beziehen, dass die aktuellen Tools auch vernünftig mit aktuellen Anforderungen umgehen können, zum Beispiel sauberes Handling von IPv6 oder den Privacy Extensions... möglicherweise gibt es da noch mehr oder andere markante Unterschiede. Ich würde jedenfalls auf die neuen Tools setzen. Du wirst Dich sowieso umgucken, wenn Dich irgendwann mal IPv6 ereilt... mein lieber scholli... da entzieht es sich völlig Deiner Kontrolle, welche IP eine Anwendung verwendet. Das zwingt einem zu völligem Umdenken, wenn man sich an selbstkreierte und liebgewonnene Restriktionen gewöhnt hat.
Ich habe heute mal den Aufbau einer unmöglichen SSH-Verbindung mit tcpdump geloggt.... tja... da probiert der Client locker 5 seiner eigenen IPs durch, auf ebenfalls 5 Ziel-IPs, ob vielleicht eine Kombination davon erfolgreich ist. Unmöglich war die Verbindung deshalb, weil auf dem Zielrechner auf diesem Port gar kein Dienst gehorcht hat. Ich wollte nur untersuchen, was der Client (also mein PC) dabei anstellt.

[guennid]

Vielen Dank, dass du nochmal reingeschaut hast!

Aber nochmal Thomas:
Das Scannen der verfügbaren SSIDs ist nicht das Problem.

Was ist zu tun, wenn man die SSID hat, aber kein Passwort verlangt wird? Mein bisheriges Verfahren hat mir in diesem Fall eben mehrfach keine IP und damit auch keine Verbindung geliefert. Im anderen Falle schon. Und insofern ist dieses Faktum entscheidend dafür, dass ich wohl umlernen muss, wozu ich auch bereit bin..

Ich bin sehr daran interessiert, dein Script zu übernehmen, aber ich will verstehen, wie es funktioniert: Mit ihm kriegte ich ja auf den CPs die IP.

Ein WISP ist laut Wikipedia "ein Anbieter von drahtlosen Internetzugängen per Funk". Nun wollen wir ja wohl beide eigentlich nicht wissen, wer jetzt jeweils dieser Anbieter sein mag, sondern wie er sein Angebot realisiert.
Ich vermute, dass das, was du WISP nennst, in meiner Terminologie der Name des APs (access point) des Anbieters ist, also seine SSID.

Code: Alles auswählen

ip link set dev wlan0 up

Gestützt auf meine bisherige Benutzung von "selnic" nehme ich an, das aktiviert die NIC, ohne dass sie vom AP des fremden Netzes, respektive von den mit ihm verbundenen DHCP-Server bereits eine IP dafür erhält.

Code: Alles auswählen

iw dev wlan0 scan | /bin/grep -i 'ssid:\|signal:\|associated'

Keine Ahnung, was dieses Kommando macht. Anhand des Bestandteils "scan" vermute ich mal, dass es die verfügbaren APs scannt. Das ist, wie schon mehrfach gesagt, nicht mein Problem, belehr' mich eines Besseren, wenn ich falsch liege. Ich suche vor allem das Kommando/die Kommandos in deinem script, das/die die IP anfordern und dann ja auch bekomm(t/en).

Und auch das zum wiederholten Male: Gibt es sowas wie ungesicherte APs bei deutschen Hotels, CPs, etc.?
Das sind für mich die entscheidendenTestobjekte.

[TomL]

Was ist zu tun, wenn man die SSID hat, aber kein Passwort verlangt wird?

Das gleiche, was ich oberhalb beschrieben habe, nur eben OHNE wpa-passphrase. Das heisst, in der conf fehlt ein solcher oder ähnlicher Abschnitt:

Code: Alles auswählen

ssid="Toms_S3_AP"
#psk="tomshandy"
psk=fsgsdgsdgsdgjhfdhdfhdfhdfhdfh7cfefafc37bca2f1bfjfgjfjfgjkgklkljö
proto=WPA RSN
group=CCMP TKIP
pairwise=CCMP TKIP
key_mgmt=WPA-PSK

... ansonsten ist alles gleich

Ein WISP ist laut Wikipedia "ein Anbieter von drahtlosen Internetzugängen per Funk".

ISP = Internet-Service-Provider, WISP das gleiche für "Wireless". Aus meiner Sicht eines reisenden Clients ist der Campingplatz, Hotel, wasauchimmer für mich der WISP. Natürlich ist das auch nur ein Accesspoint. Und natürlich ist der Betreiber des Campingplatzes selber ein Kunde seines ISP.

Ich vermute, dass das, was du WISP nennst, in meiner Terminologie der Name des APs (access point) des Anbieters ist, also seine SSID.

Ja klar. Wobei die SSID nur der vom WISP herausposaunte Name seines WLAN-AP ist.... damit man in der Liste des Scan-Ergebnisses einen sprechenden Namen vorfindet. Ohne SSID wirds nämlich schwierig zu verbinden, weil man erst mal nicht weiss, womit man sich überhaupt verbinden kann.

Code: Alles auswählen

ip link set dev wlan0 up

Gestützt auf meine bisherige Benutzung von "selnic" nehme ich an, das aktiviert die NIC, ohne dass sie vom AP des fremden Netzes, respektive von den mit ihm verbundenen DHCP-Server bereits eine IP dafür erhält.

Dieser Befehl schaltet das Interface mit "up" nur ein... ebenso würde es mit "down" einfach nur ausgeschaltet werden. Das heisst, nach "up" ist es eingeschaltet und kann für eine neue Verbindung verwendet werden. Es wird mit "up" keine Verbindung automatisch hergestellt.

Code: Alles auswählen

iw dev wlan0 scan | /bin/grep -i 'ssid:\|signal:\|associated'

Keine Ahnung, was dieses Kommando macht.

Ist auch ganz einfach... es scannt die Umgebung nach verfügbaren AccessPoints. Das entspricht wohl dem "iwlist wlan0 scan". Die Frage dabei ist, vor dem Hintergrund, dass es mittlerweile neben dem 2,4 GHz-Band immer mehr 5 GHz-Unterstützung bei WLAN-AP gibt, ob die alten Tools mit solchen Sachen überhaupt noch adäquat umgehen können. Auch hier wieder mein Ansatz, besser die neuen Tools nutzen, damit nicht wegen fehlender Unterstützung irgendwas nicht funktioniert.

Ich suche vor allem das Kommando/die Kommandos in deinem script, das/die die IP anfordern und dann ja auch bekomm(t/en).[/b]

Das passiert hier mit diesen 2 Befehlen, nacheinander .... erst die Verbindung herstellen und dann mit dhclient eine IP anfordern

Code: Alles auswählen

wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant/wlan.conf -D nl80211,wext
dhclient -v wlan0

Gibt es sowas wie ungesicherte APs bei deutschen Hotels, CPs, etc.? Das sind für mich die entscheidendenTestobjekte.

Ja, klar, ich denke McDonalds... ausserdem kannst Du ganz einfach mal eben schnell bei Deinem Router den WPA-Key ausschalten, oder am Smartphone "thethering" aktivieren und das Passwort löschen, oder (sofern verfügbar) einfach nen USB-WLAN-Stick via hostapd als AccessPoint ohne PWD einrichten. Es gibt etliche Möglichkeiten, dass 1:1 zu simulieren. Die hier beschriebenen Befehle müssten alle genauso und ganz einfach im Terminal direkt eingegeben funktionieren.

[guennid]

Code: Alles auswählen

wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant/wlan.conf -D nl80211,wext

zwei Fragen:

1. Mit Parameter -c greift wpa_supplicant auf eine Konfigurationsdatei (in deinem Beispiel: wlan.conf) zu. Erstellt er die/schreibt er die im Zuge der Kommandoausführung, oder muss die schon existieren? In letzterem Fall wäre mir noch nicht klar, wer, wie wann das macht.

2. -D mit Treiber sind Kernel-Module gemeint - richtig? Das sollte dann NIC-abhängig sein, will sagen, wenn die verwendete NIC bisher mit wext funktioniert hat, ist nl80211 (habe ich hier noch nie benutzt) irrelevant - richtig?

Grüße, Günther

[TomL]

Code: Alles auswählen

wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant/wlan.conf -D nl80211,wext

1. Mit Parameter -c greift wpa_supplicant auf eine Konfigurationsdatei (in deinem Beispiel: wlan.conf) zu. Erstellt er die/schreibt er die im Zuge der Kommandoausführung, oder muss die schon existieren? In letzterem Fall wäre mir noch nicht klar, wer, wie wann das macht.

Das ist ohne Networkmanager ein Handmade-Job... man muss diese Conf selber erstellen bzw. pflegen, exakt so wie man selber die /etc/network/interfaces pflegt. Der Vorteil bei der Conf ist, man kann verschiedene Konfigurationen vorhalten und übergibt die gewünschte Conf einfach als Paramter an 'wpa_supplicant'. Man kann aber auch immer die gleiche verwenden und die bestehenden Werte jeweils manuell einfach mit den aktuellen überschreiben. 'selnic' macht im grundegenommen genau das... es schreibt bei einem neuen WISP mit "echo" einfach eine neue conf mit der SSID als Name für die Conf. Man kanns aber einfach auch von Hand machen.

2. -D mit Treiber sind Kernel-Module gemeint - richtig? Das sollte dann NIC-abhängig sein, will sagen, wenn die verwendete NIC bisher mit wext funktioniert hat, ist nl80211 (habe ich hier noch nie benutzt) irrelevant - richtig?

Nein, das sind nicht die Kernel-Module ... das ist die libnl, die sowas wie ein API (also eine Zwischenschicht) zwischen User-Space/App und Socket ist. Hinter dem Socket ist dann der Kernel und dahinter dann die Kernel-Module. Da würde ich auf keinen Fall drauf verzichten, schon mal gar nicht, wenn Du z.B. auch iptables konfiguriert hast. 'wext" - das sind die wireless extensions- ist wieder so ein uraltes Modul, welches durch nl80211 ersetzt wurde. Bei wext würde ich beispielsweise davon ausgehen, dass möglicherweise sowas wie "conntrack" überhaupt nicht mehr implementiert ist.... ich weiss es aber auch nicht genau. Wenn die libnl installiert ist, lass es einfach so stehen. Keinesfalls würde ich die libnl deinstallieren.

Do we still use WE ?
No, while cfg80211 still has some backward compatibility support, and a few ancient drivers still support only wireless extensions, everything else has long moved on and doesn't support anything but the most basic features with wireless extensions.

Sogar 'cfg80211' als Nachfolger von 'wext' ist schon wieder verworfen und wurde durch ein komplett re-designed'tes 'nl80211' ersetzt.
https://wireless.wiki.kernel.org/en/dev ... extensions

[guennid]

'selnic' ... schreibt bei einem neuen WISP mit "echo" einfach eine neue conf mit der SSID als Name für die Conf.

... und benutzt dazu die von

Code: Alles auswählen

iw dev ... scan

gelieferten Angaben - richtig?

In allen bisher von mir mit selnic erzeugten wpa_supplicant.confs gibt es eine Zeile id_str="Guest". Welche Relevanz hat diese Zeile? Ich habe dazu keine Hinweise im Netz oder in der manpage gefunden.

Bemerkung am Rande: Die Arbeitsweise von

Code: Alles auswählen

ip link set dev wlan0 up

ist vielleicht ein wesentlicher Unterschied zum meinem bisherigen Verfahren: Wenn ich noch recht erinnere (ist ja nun schon wieder mehrere Monate her, dass ich das zuletzt benutzt habe) dann wurde mit ifup wlan0 nicht nur diese Gerätedatei "eingeschaltet", sondern auch versucht, für die dafür in der /etc/network/interfaces eingetragene Verbindung via dhcp eine IP zu bekommen. Und genau das hat bei diesen "freien" APs nie funktioniert.

Grüße, Günther

[mat6937]

... gibt es eine Zeile id_str="Guest". Welche Relevanz hat diese Zeile? Ich habe dazu keine Hinweise im Netz oder in der manpage gefunden.

In z. B. https://w1.fi/cgit/hostap/plain/wpa_sup ... icant.conf findest Du zu "id_str":

# id_str: Network identifier string for external scripts. This value is passed
# to external action script through wpa_cli as WPA_ID_STR environment
# variable to make it easier to do network specific configuration.

[guennid]

Danke sehr!

Aber ich verstehe das nicht, insbesondere den Passus "external script". Ich entlatinisiere mir hier mal "extern" mit "fremd", es scheint hier also um (wpa_supplicant)fremde skripte zu gehen, aber ich habe keine Ahnung, was die Passage mir sagen will.

[TomL]

'selnic' ... schreibt bei einem neuen WISP mit "echo" einfach eine neue conf mit der SSID als Name für die Conf.

... und benutzt dazu die von

Code: Alles auswählen

iw dev ... scan

gelieferten Angaben - richtig?

Ja

In allen bisher von mir mit selnic erzeugten wpa_supplicant.confs gibt es eine Zeile id_str="Guest". Welche Relevanz hat diese Zeile? Ich habe dazu keine Hinweise im Netz oder in der manpage gefunden.

Google findet mit "wpa_supplicant id_str" haufenweise Erklärungen.
https://wiki.debian.org/WPA#Why.3F
http://raspberrypi.stackexchange.com/qu ... i-networks
https://wiki.ubuntuusers.de/WLAN/wpa_supplicant/
... wobei anzumerken ist, dass ich hiermit meiner eigenen Prämisse nicht mehr konsequent folge. Die Verwendung ist wohl für die /etc/network/interfaces gedacht, die ich ja für völlig überflüssig erachte. Für Dich hat der String den Vorteil, dass Du mit selnic eine Conf generieren kannst, um sie dann in der 'interfaces' zu nutzen. Ansonsten kannst Du das ignorieren.

Bemerkung am Rande: Die Arbeitsweise von

Code: Alles auswählen

ip link set dev wlan0 up

ist vielleicht ein wesentlicher Unterschied zum meinem bisherigen Verfahren: Wenn ich noch recht erinnere (ist ja nun schon wieder mehrere Monate her, dass ich das zuletzt benutzt habe) dann wurde mit ifup wlan0 nicht nur diese Gerätedatei "eingeschaltet", sondern auch versucht, für die dafür in der /etc/network/interfaces eingetragene Verbindung via dhcp eine IP zu bekommen. Und genau das hat bei diesen "freien" APs nie funktioniert.

Das ist das, worauf ich mehrfach hingewiesen habe, die alten Tools machen andere Dinge, die heute nicht mehr zwingend unterstützt oder einfach anders gehandhabt werden. Das folgende wurde schon 2009, also vor 7 Jahren festgestellt:
Luk Claes and me, as the current maintainers of net-tools, we've been thinking about it's future. Net-tools has been a core part of Debian and any other linux based distro for many years, but it's showing its age. It doesnt support many of the modern features of the linux kernel, the interface is far from optimal and difficult to use in automatisation, and also, it hasn't got much love in the last years.
https://lists.debian.org/debian-devel/2 ... 00780.html

Im aktuellen Debian funktioniert alles sowas von genial gut, stabil und zuverlässig... man muss Debian einfach nur machen lassen. Das Festhalten an jahrzehntealten Gewohnheiten ist nix anderes als nen riesenfetter Bremsklotz....

[guennid]

Die Verwendung [von id_str] ist wohl für die /etc/network/interfaces gedacht, die ich ja für völlig überflüssig erachte.

Soweit war ich zwischenzeitlich auch gekommen, dass das wohl mit den externen scripten gemeint war. Die Erwähnung in dem ubuntu-wiki muss mir durch die Lappen gegangen sein.

Das Festhalten an jahrzehntealten Gegebenheiten ist nix anderes als nen riesenfetter Bremsklotz....

Thomas, jetzt komm' mal wieder runter. Ich halte, wie gesehen, nicht an "jahrzehntealten" Gegebenheiten fest.

Das, was du mir vorschägst, benutze ich, wenn's besser funktioniert - und danach sieht's in der Tat aus, und nicht weil's neuer ist. Und dass /etc/network/interfaces überholt sein sollte, kenne ich eigentlich nur von dir. In allen mir bekannten Online-Tutorials ist das nach wie vor die zentrale Netzwerkkonfigurationsdatei - wenn man auf einen Netzwerkmanager verzichten will. Keine Angst, wenn ich auch bei den für mich problematischen APs ohne die und mit selnic-Methoden weiterkomme, werde ich sie sausen lassen. Ich halte auch daran nicht fest. wpa_supplicant war zu keiner Zeit ein Thema. Das Tool wurde seit jeher hier benutzt, nur eben in der interfaces und nicht in einer separaten wpa_supplicant.conf. Ein MUSS scheint mir eine separate wpa_supplicant.conf nach wie vor nicht zu sein, wiewohl ich nach selnic anerkenne, dass sie leichte Vorteile bietet.

Die entscheidenden Dinge, die ich bisher nicht kannte, bzw. nicht benutzt habe, dürften ip, dhclient und nl80211 sein. Nochmals danke für die entsprechenden Hinweise (bei dhclient hat auch niemand mitgewirkt).

Und was Debian angeht: Ich schätze an unserer Distri das Baukastenprinzip. Hoffentlich bleibt es auch in Zukunft gewährleistet. Aber das ist dann nun wirklich eine andere Baustelle.

So, und jetzt suche ich mal 'nen McDonalds. O Gott, was ess' ich denn da? Naja, Fritten wird man wohl auch da kriegen.

Grüße, Günther

[TomL]

Aber ich verstehe das nicht, insbesondere den Passus "external script". Ich entlatinisiere mir hier mal "extern" mit "fremd", es scheint hier also um (wpa_supplicant)fremde skripte zu gehen, aber ich habe keine Ahnung, was die Passage mir sagen will.

Ganz einfach... ein external Script ist z.B. das von wpasupplicant selber mitgebrachte

Code: Alles auswählen

/etc/wpa_supplicant/ifupdown.sh

welches den id_string parsed. Ich halte das aber für zu unwichtig, um da auch nur länger als 5 Sekunden drüber nachzudenken.

Thomas, jetzt komm' mal wieder runter. Ich halte, wie gesehen, nicht an "jahrzehntealten" Gegebenheiten fest.

Boar, nimm das bloß nicht persönlich... so ist das wirklich nicht gemeint... ich bin da rein sachlich orientiert....

Und dass /etc/network/interfaces überholt sein sollte, kenne ich eigentlich nur von dir. In allen mir bekannten Online-Tutorials ist das nach wie vor die zentrale Netzwerkkonfigurationsdatei

Ja, weil sich systemd-networkd anscheinend noch nicht so richtig durchsetzen kann. Ich sehe das aber analog zu rsyslog, was ich auch für völlig überflüssig halte, weil journald ne perfekte Alternative ist. Oder ntp, welches ich durch timesyncd ersetzt habe. Aber das ist wohl momentan noch alles eher Philosophie... allein die Frage bleibt, wem gehört die Zukunft?

wiewohl ich nach selnic anerkenne, dass sie leichte Vorteile bietet.

Das macht mir gerade ein breites freudiges Lächeln.....