Wifi beim Systemstart unterbinden

OsunSeyi

Well-Known Member
In Fortführung vom Thread grafischer Login ohne Loginmanager hier als eigenes Thema die Konfiguration vom Wifi.
Bereits während der Installation wurde Wifi problemlos aktiviert, sehr einfach und gut.

Da ich hier aber oft kein funktionierendes Wlan habe, verzögert sich der Bootvorgang mitunter erheblich, weil BSD geduldig sucht und nicht findet...

@pit234a:
/etc/defaults/rc.conf:
netif_enable="YES"
auf 'NO' setzen, und das Netzwerk manuell starten, finde ich ok.

/etc/rc.conf:
wlans_wpi0="wlan0"
ifconfig_wlan0="WPA DHCP"
create_args_wlan0="country DE regdomain ETSI"

Aber vielleicht ist es am elegantesten, wenn der Verbindungsaufbau im Hintergrund gestartet wird, ohne den Bootvorgang zu behindern?

Zur Zeit setze ich 'wifimgr' ein, funktioniert gut. Ein Icon im Panel zu haben, wäre angenehm. Wenn das Wlan mal wieder weg ist, kann ich es dann direkt sehen und muss nicht erst gucken, was los ist. Leider startet 'networkmgr' mit einer Fehlermeldung:

Code:
$ networkmgr
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/threading.py", line 916, in _bootstrap_inner
    self.run()
  File "/usr/local/lib/python3.6/threading.py", line 864, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/share/networkmgr/trayicon.py", line 304, in updatetrayloop
    self.checkfornewcard()
  File "/usr/local/share/networkmgr/trayicon.py", line 323, in checkfornewcard
    if isanewnetworkcardinstall() is True:
  File "/usr/local/share/networkmgr/net_api.py", line 110, in isanewnetworkcardinstall
    if ifwificardadded() is True or ifwiredcardadded() is True:
  File "/usr/local/share/networkmgr/net_api.py", line 88, in ifwificardadded
    rc_conf = open('/etc/rc.conf', 'r').read()
  File "/usr/local/lib/python3.6/codecs.py", line 321, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xfc in position 643: invalid start byte

Wenn nicht zu kompliziert, würde ich auch dieses Problem gerne lösen!
Wichtiger aber, daß der Verbindungsaufbau nicht den Bootvorgang zu verzögert.

Wie es bei einem Labtop überhaupt angenehm ist, wenn schnell gebootet wird, das Bootmenü habe ich auf 1s gesetzt....
 
Zuletzt bearbeitet:
Ich weiß nicht, ob es nicht ne schönere Variante gibt, aber du könntest das Netzwerk, bzw. auch nur das Wifi über die rc.local mit nem nachgestellten & starten.
 
Leider habe ich die Vorgänge beim initiieren des Netzwerkes nicht verstanden.
Selbiges auch auf Linux...

Das W-LAN ist hier schwach und wir auch durch andere Geräte gestört, Kanalwechsel hat nichts gebracht.
Es kommt also vor, daß eine niedrige Signalstärke (zwei Balken) angezeigt wird, aber ein Verbindungsaufbau trotzdem fehlschlägt.

Wenn ich das WIFI mit 'wifimgr' neu starte, verbindet sich der Rechner nicht unbedingt neu, wohl aber, wenn ich ihn gleich neu starte.

Beim Installationsvorgang von freeBSD war alles sehr smart: Ich bekam direkt eine kleine Auswahl der verfügbaren Netzwerke auf die Konsole und konnte dort auswählen. Ähnlich bei Tiny small Linux, wo einem eine kleines Terminal geöffnet wird, in dem ein Programm direkt die verfügbaren Accesspoints zur Auswahl listet.
Ich denke also, das müsste so bereits auch hier möglich sein!

Darum würde ich sehr gerne die Initiierungsvorgänge einmal komplett auf der Konsole nachvollziehen, um herauszufinden, wo es hakt.

Du könntest das Netzwerk, bzw. auch nur das Wifi über die rc.local mit nem nachgestellten & starten

Wo genau fängt denn der Initiierungsvorgang an, was genau müsste gestartet werden?
Ich gehe mal davon aus, daß:

Code:
/etc/defaults/rc.conf:
netif_enable="NO"

das Netzwerk zunächst komplett deaktiviert, und werde das jetzt mal probieren!
 
Du willst niemals /etc/defaults/rc.conf editieren, sondern nur die /etc/rc.conf.

Versuch doch einfach nur mal folgendes abzuändern:
Code:
ifconfig_wlan0="WPA"

Also ohne DHCP.

Rob
 
Ein Icon im Panel zu haben, wäre angenehm.
?
Habe eben mal meinen geilen Laptop angeworfen (bin einfach super froh mit dem Teil) und hänge mal einen screenshot meines Panels (fbpanel) an:
screenshot-2019.09.23-102415.jpg

Naja, hätte vielleicht besser nur einen Ausschnitt genommen aber ich hoffe, man sieht das Symbol rechts, das so etwas wie blaue Wellen darstellen könnte. Das ist der networkmgr.
Den starte ich aus der OpenBox autostart.sh mit einem /usr/local/bin/networkmgr & und finde dann in ~/.config/openbox/network_applet offenbar ein Python-Script, dass das verhalten des Aussehens beschreibt. Ich kann mich nicht erinnern, dass ich das Script manuell hierher gebracht habe und wusste bis eben nicht mal, dass es existiert.
Es gibt also ein Icon. Nicht immer zuverlässig die Wellen zeigend, welche die Empfangsstärke anzeigen, aber mit Aufklapp-Menü zur weiteren Information oder Aktion.

Wie an anderer Stelle aber schon beschrieben, weiß ich nicht, wie das reagieren wird, wenn zur Bootzeit gar kein Netzwerk vorhanden ist. Wenn also erst der networkmgr gestartet wird und dann erst das Interface damit eingeschaltet werden soll. Die Funktion zum Ausschalten ist vorhanden, die kann ich sehen, aber bei mir wurde das Netz ja auch während des Bootens schon angelegt. Da müsstest du vielleicht mal spielen.
 
Du willst niemals /etc/defaults/rc.conf editieren, sondern nur die /etc/rc.conf.
genau.
In einem anderen Beitrag, wo ich das erwähnte, wollte ich den Default-Eintrag zeigen. Man es vielleicht so verstehen, dass die 7etc/rc.conf eine Art Offset oder Ergänzung der /etc/defaults/rc.conf darstellt. Diese wird zuerst gelesen und wenn es etwa keine /etc/rc.conf gäbe, genauso angewendet. Gibt es aber Einträge in der /etc/rc.conf, dann werden damit die Defaults überschrieben.
Man kann also quasi jeden Eintrag aus den Defaults auch ändern und mit eigenen Werten versehen.
Die /etc/defaults/rc.conf kommt mit dem System und wird auch mit dem System upgedatet. Deshalb ändert man hier natürlich nichts.

Darum würde ich sehr gerne die Initiierungsvorgänge einmal komplett auf der Konsole nachvollziehen, um herauszufinden, wo es hakt.
Ich finde das Handbuch an der Stelle recht ausführlich, genügt das nicht?
 
Du willst niemals /etc/defaults/rc.conf editieren, sondern nur die /etc/rc.conf.

:ugly: Danke für den Tip!

Auf jeden Fall bootet das Teil mit netif_enable="NO" sensationell schnell!
Probier direkt mal Deinen Vorschlag...

Ich finde das Handbuch an der Stelle recht ausführlich, genügt das nicht?
:D das wollte ich nicht abstreiten. Fand es aber zu schwer für mich, um das direkt zur Problemlösung heranziehen zu wollen. Ist ja auch viel kommunikativer so... Werd's nachholen! Die Leiste ist wunderbar, networkmgr anzuschmeißen kommt später!

---
edit:

@KobRheTilla:

Ohne DHCP startet der Rechner auch sehr schnell, im WIFI-Netzwerkmanager sind die Netzwerke auch gelistet, aber verbinden klappt nicht (schreibe jetzt von Salix). Vielleicht braucht ja die Hardware den reboot?

Habe mich jetzt mit dem Labtop direkt zu Router begeben, Wlan per Hardware-Schalter deaktiviert und wieder angeschmissen.
Selbiges im Netzwerkmanager (WIFI An/Aus) + (Speichern und neu verbinden).

Funknetzwerke werden gelistet, Verbindung wird nicht hergestellt!
Also muss DHCP wohl aktiviert sein, sonst klappt nichts...
Aber das ganze bitte nicht zur Bootzeit!

Was ich überhaupt nicht verstehe:

In /etc/rc.conf werden die Verbindungsbedingungen gesetzt: 'wlans_wpi0' , 'ifconfig_wlan0' , 'create_args_wlan0'.
Wo aber wird das Wlan konkret gestartet?
 
Zuletzt bearbeitet:
background_dhclient="YES" gesetzt

...waiting 30s for default interface

...und weitere Wartezeiten sind trotzdem dabei.
Ich glaube, es hat nichts geändert!

Ich würde (zur Not) das Netzwerk auch komplett manuell starten (oder beim Starten von BB), dazu müsste es aber erstmal beim Booten unterbunden werden...
 
Im Handbuch steht:
Starten Sie den Computer oder den Netzwerkdienst neu, um sich mit dem Netzwerk zu verbinden:
# service netif restart

Kann ich evtl. in /etc/rc.conf. netif_enable="NO" setzen und mit sudo service netif start das Inet anwerfen?

~~~~~~~~
edit:


Ja, das funktioniert:

sudo service netif onestart bzw sudo service netif onerestart verbinden den Rechner. Der Eintrag netif_enable="NO" in /etc/rc.conf wird beachtet und der Rechner bootet jetzt auch schnell.

background_dhclient="YES" wäre eleganter gewesen...

Weil -wie gesagt- der Rechner sich im Zweifelsfall eher bei einem reboot verbindet, würde ich vermuten, daß wpa_supplicant (?) beim booten mit anderen Optionen gestartet wird, und daher geduldiger sucht, was die Warscheinlichkeit eines Verbindungsaufbaus erhöht. Falls dem so ist, wäre es schön, diese zu verwenden.
 
Zuletzt bearbeitet:
Ja, das funktioniert:

sudo service netif onestart bzw sudo service netif onerestart verbinden den Rechner. Der Eintrag netif_enable="NO" in /etc/rc.conf wird beachtet und der Rechner bootet jetzt auch schnell.

na, dann probier doch einfach mal, ob sich nach dem Einloggen das Netzwerk manuell aus dem Panel heraus vom Icon des networkmgr starten lässt. Ich halte das durchaus für möglich und der Test ist doch wirklich einfach durchzuführen.
Also, du schreibst deine Netzwerk-Konfiguration wie gehabt in die /etc/rc.conf, fügst aber auch ein netif_enable="NO" dort ein.
Dann startest du deine User-Umgebung (war das auch OpenBox?), startest dort ein Panel (etwa fbpanel, das ist klein und zart und kann einfach konfiguriert werden, falls du noch kein anderes Panel benutzt), dann den networkmgr, der dir ein Icon in der Leiste präsentiert, von dem aus du womöglich dann das Netzwerk starten kannst. Vermutlich wird der networkmgr entsprechende Rechte benötigen, aber das kann man ja alles herausfinden.
Sollte das nicht gehen, genügt ja der einfache Start service netif onestart.
 
Ja, aber den kann ich wg obiger Fehlermeldung nicht starten...
benutze tint2
vielleicht kann das auch gkrellm, also die Netzwerkanbindung anzeigen...
 
Die Fehlermeldung besagt, dass networkmgr versucht die rc.conf als UTF-8 zu parsen, aber eine ungültige Bytesequenz findet und darüber stolpert. Der Grund dafür ist allerhöchstwahrscheinlich, dass die rc.conf in einem anderem Charset erstellt wurde und mindestens ein Nicht-ASCII-Zeichen enthält, also vermutlich einen Umlaut. Kratze mal alles raus, was nicht ASCII ist (oder konvertiere sie in UTF-8) und dann sollte es gehen.
 
Falls Du Zugriff auf die WLAN Settings hast, könntest Du einen kleinen Bereich für die Verwendung von dhcp sperren und Deinem Laptop ne statische IP geben ... dann hört die DHCP-Warterei schon mal auf.
Wenn du z.B. in nen 192er Netz von 192.168.0.200 bis 192.168.0.210 für statische IP s reservierst ... wuerde das ungefähr so aussehen:

/etc/rc.conf
Code:
wlans_wpi0="wlan0"
ifconfig_wlan0="WPA inet 192.168.1.200 netmask 255.255.255.0"

/etc/wpa_supplicant.conf
Code:
eapol_version=2
ap_scan=1
fast_reauth=1

network={
  ssid="Deine_SSID"
  psk="********"
  priority=5
}

/etc/resolf.conf
Code:
nameserver 8.8.8.8

Ausserdem solltest Du in der rc.conf mal nachschauen, ob da nicht auch noch was von NTP auftaucht,
denn dann sucht das Teil auch noch nen Timeserver und wartet auf Antwort.
 
@ Yamagi :
Das entfernen der Umlaute hat geholfen...! Vielen Dank.

Jetzt gibt es nur noch die Meldung:
doas: doas is not enabled, /usr/local/etc/doas.conf: No such file or directory

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ Soonwald :
NTP hatte ich wieder rausgeschmissen, bereits vorher.

Es bleibt die Frage, ob die Netzwerksuche evtl beim Systemstart gründlicher durchgeführt wird (wenn netif_enable="YES" gesetzt ist), weil nach meinem Eindruck das Netzwerk dann meistens gefunden wird. Wenn ich es im gebooteten Zustand mit service netif onestart selber starte, muss ich mich schon in die Nähe des Routers bewegen.
 
Jetzt gibt es nur noch die Meldung:
doas: doas is not enabled, /usr/local/etc/doas.conf: No such file or directory

Code:
pit@Celsius ~:- > ll /usr/local/etc/doas.conf
ls: /usr/local/etc/doas.conf: No such file or directory
?
ich nutze weder sudo noch doas und kann mich damit auch nicht anfreunden.
Es kommen auch keine derartigen Bemerkungen bei mir.
Derzeit bin ich nicht an einem PC, der networkmgr installiert hat und kann deshalb nicht gut nachsehen. Vermutlich ist das eine Frage der Rechte, die ROOT dem Programm gewährt oder der Gruppenzugehörigkeit. Meistens gibt es dafür Install-Meldungen, die einem weiter helfen. Die man auch lesen muss oder mit pkg info (plus passender Optionen) nachträglich ansehen kann.
 
siehe auch Minihowto: networkmgr - ein Verbindungstool für Ethernet und Wifi

Es läuft darauf hinaus, daß networkmgr den -funktionierenden- Mechanismus von wpa_supplicant erstetzt (die Einträge in dessen Config müssen gelöscht werden) und den zusätzlichen Einsatz von 'doas' erfordert nur damit ich einen schicken Icon in der Taskleiste bekomme. Der Icon funktioniert auch ohne doas, aber natürlich nicht die damit verbundenen Funktionalitäten.

Wenn ich das richtig verstanden habe. Das ist für mich ein bisschen viel bemüht, offen gestanden...
Neuerdings bekomme ich eine "python3.6.core" in's Homeverzeichnis...

Wenn es nur um die Info geht, daß der Rechner eine Verbindung hergestellt hat oder nicht, müsste das doch auch einfacher gehen !?

Abgesehen davon startet networkmgr nicht aus meiner aus der xinitrc heraus gestarteten 'Autostart':

Bash:
#!/bin/sh

    rox --pinboard=normal &
    sleep 5
    tint2 &
    ipager &
    xpad &
    parcellite &
    sudo service netif onestart &
#    networkmgr &
 
Es läuft darauf hinaus, daß networkmgr den -funktionierenden- Mechanismus von wpa_supplicant erstetzt (die Einträge in dessen Config müssen gelöscht werden)
https://www.bsdforen.de/threads/min...-verbindungstool-für-ethernet-und-wifi.33754/

Bin eben aufgewacht und musste daran denken und erinnerte mich dann dann auch der Seite oben, die OsunSeyi schon selbst gefunden hatte. Hat mir keine Ruhe gelassen und ich habe meinen geilen Laptop wieder gestartet und nachgesehen:
Ich habe die /etc/wpa_supplicant.conf nicht gelöscht. Vermutlich wollte ich den networkmgr mal testen und glaubte nicht, dass ich so etwas auf Dauer haben möchte. Wie auch immer: es gibt meine /etc/wpa_supplicant.conf und eine /usr/local/etc/doas.conf, die vermutlich aber von networkmgr mitgebracht worden ist. Sie sieht bei mir so aus:
Code:
pit@leno ~:- > cat /usr/local/etc/doas.conf
    permit nopass keepenv root
    permit :wheel
    permit nopass keepenv :wheel cmd netcardmgr
    permit nopass keepenv :wheel cmd detect-nics
    permit nopass keepenv :wheel cmd detect-wifi
    permit nopass keepenv :wheel cmd ifconfig
    permit nopass keepenv :wheel cmd service
    permit nopass keepenv :wheel cmd wpa_supplicant

Neuerdings bekomme ich eine "python3.6.core" in's Homeverzeichnis...
wie schon mal erwähnt, scheint das Icon und sein Verhalten über ein Python-Script definiert zu sein und dieses wird eben mit Python gestartet. Wieso Python bei dir ein .core erzeugt, müsste man dann nachsehen.

Abgesehen davon startet networkmgr nicht aus meiner aus der xinitrc heraus gestarteten 'Autostart':
Ganz allgemein ist es gut, absolute Pfade zu benutzen.
Was nicht deutlich wird: ist das deine .xinitrc? oder ein autostart.sh, das aus .xinit.rc aufgerufen wird?

und den zusätzlichen Einsatz von 'doas' erfordert nur damit ich einen schicken Icon in der Taskleiste bekomme.
Nein. Du bekommst ein grafisches Netzwerk-Steuerungstool. Sowohl das Icon, als auch das Tool selbst spacken ab und an, sind aber tatsächlich hilfreich für unbedarfte Nutzer wie mich. Ich muss nicht auf die shell und mit den Tasten klimpern, wenn ich mal schnell etwas nachsehen oder verändern möchte.
Übrigens finde ich persönlich den Einsatz von doas weitaus unbedenklicher, als sudo mit einem User ohne Passwort.

Was den networkmgr angeht:
Code:
pit@leno ~:- > pkg info -d networkmgr
networkmgr-3.1:
    pango-1.42.4_2
    doas-6.1
    hicolor-icon-theme-0.17
    python36-3.6.9
    gtk-update-icon-cache-2.24.32
    gdk-pixbuf2-2.36.12
    py36-setuptools-41.0.1
    py36-gobject3-3.28.3
    glib-2.56.3_5,1
    gettext-runtime-0.20.1
    atk-2.28.1
Das ist schon eine ziemliche Hausnummer! Das muss man sich tatsächlich überlegen, ob man den Aufwand haben möchte. Auf meinem geilen Laptop läuft er jedenfalls ziemlich gut (mit Macken) und stellt dort auch keine Belastung dar. Auf meinem alten Atom hätte ich das vielleicht nicht probiert.

Wenn es nur um die Info geht, daß der Rechner eine Verbindung hergestellt hat oder nicht, müsste das doch auch einfacher gehen !?
ifconfig(8)?
Das alles geht einfach von der Konsole. Wenn man das für einfach betrachtet. Schau ins Handbuch, das ist da recht deutlich und gut gegliedert.
https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-wireless.html
und nur leicht veraltet. Du siehst ja, dass die diversen wlan-Module inzwischen automagisch geladen werden und keine Einträge in der /boot/loader.conf erforderlich sind. Schaden würden die Einträge nicht, aber es geht eben ohne. Du kannst ja ein kldstat -v mal nach wlan grep-en.
 
Was den networkmgr angeht:
Code:
pit@leno ~:- > pkg info -d networkmgr
networkmgr-3.1:
    pango-1.42.4_2
    doas-6.1
    hicolor-icon-theme-0.17
    python36-3.6.9
    gtk-update-icon-cache-2.24.32
    gdk-pixbuf2-2.36.12
    py36-setuptools-41.0.1
    py36-gobject3-3.28.3
    glib-2.56.3_5,1
    gettext-runtime-0.20.1
    atk-2.28.1
Das ist schon eine ziemliche Hausnummer! Das muss man sich tatsächlich überlegen, ob man den Aufwand haben möchte. Auf meinem geilen Laptop läuft er jedenfalls ziemlich gut (mit Macken) und stellt dort auch keine Belastung dar. Auf meinem alten Atom hätte ich das vielleicht nicht probiert.

Welcher Aufwand?! :confused:

Für ein Tool, dass einem - speziell auf Laptops - das Leben dermaßen erleichtert, wende ich gerne ~20 MB RAM und etwas Speicherplatz auf:

Code:
$ cat /proc/$(pgrep NetworkManager)/status | grep VmHWM
VmHWM:       19920 kB

Das entspricht bei aktuellen Hardware-Preisen selbst auf Laptops weniger als 0,10 € für den benötigten RAM und für den Speicherplatz auf SSD nochmal deutlich weniger als das. :-)

Selbst ein Raspberry Pi hat inzwischen 4 GB RAM...
 
Für ein Tool, dass einem - speziell auf Laptops - das Leben dermaßen erleichtert, wende ich gerne ~20 MB RAM und etwas Speicherplatz auf
dito. Vor allem, weil die meisten der Abhängigkeiten bei mir eh vorhanden sind, weil sie auch von anderen Programmen verwendet werden. Aber Python ist schon mal ein Brocken, wenn auch ein kleiner oder eben das unter FreeBSD nicht unumstrittene doas. Ich kann schon verstehen, dass man sich da sträubt. Allerdings gleichzeitig den Firefox oder LibreOffice nutzen, wäre dann schon merkwürdig.
 
Aber Python ist schon mal ein Brocken, wenn auch ein kleiner oder eben das unter FreeBSD nicht unumstrittene doas. Ich kann schon verstehen, dass man sich da sträubt.

Die Diskussion um doas muss ich verpasst haben - was sind die relevanten Kritikpunkte?

Bei den aktuellen SSD-Preisen kann ich die Diskussion um ein paar MB - oder auch GB - nicht nachvollziehen. Bei SSD-Preisen von 0,10€ pro GB will sich bei mir irgendwie kein Problembewusstein einstellen...
 
Die Diskussion um doas muss ich verpasst haben - was sind die relevanten Kritikpunkte?
war weiter oben verlinkt, habe das aktuell nicht nachgelesen, interessiert mich persönlich eher wenig. Ich wollte den networkmgr, zu mindest mal probieren. Und ich teile deinen Standpunkt ja vollkommen.
Weiß allerdings auch noch, wie geizig ich selbst auf meinem kleinen Atom wirtschaftete. Der hatte eben keine große SSD und nur wenig Performance. Ich verstehe, dass man überlegt und tatsächlich bin ich über die ein oder andere Abhängigkeit bis heute nicht besonders glücklich, die mit manchen Programmen gezogen wird. Ich ergebe mich in mein Schicksal, weil ich es selbst nicht besser kann, bzw, weil ich nicht mehr selbst bauen möchte. Ganz genau deshalb, weil es nur wenige GB Unterschied macht und die Leistung nicht beeinflusst.

Es gibt allerdings auch Dinge, die ich einfach nicht ausstehen kann. Ich nenne hald. Den starte ich niemals automatisch, weil es nur noch eine Anwendung gibt, die den bei mir braucht und wenn ich diese Anwendung nutzen möchte, dann starte ich eben zuvor den hald manuell.
Also auch aus der Richtung "persönliche Präferenzen" könnte ich verstehen, wenn jemand einen bestimmten Dienst oder bestimmte Programme nicht will.

Doch, mit Verlaub gesagt, beim networkmgr sehe ich da selbst kaum etwas, worüber man tatsächlich ins Grübeln kommen müsste, zumindest dann nicht, wenn man doas überhaupt akzeptiert und das sollte man ganz sicher, wenn man sudo als Nutzer ohne Passwort einsetzt. Sehe ich zumindest so.
Und natürlich will ich hier nicht missionieren. Ich stehe nicht hinter networkmgr, er spackt gelegentlich, erkennt ein WLan als Lan (zeigt das falsche Symbol an) oder kommt durcheinander, wenn man sich von einem Netz in ein anderes bewegt (besonders dann, wenn dabei der Rechner schläft).
Er ist aber das Beste, was ich für FreeBSD kenne und er könnte womöglich genau die Probleme des Thread-Owners lösen.
Das Beste, was ich kenne: es gab hier mal einen Beitrag zusammen mit einer kleinen SW, die ich schon recht gelungen fand. Da hatte jemand spontan mal was eigenes umgesetzt, was ganz gut begann, aber schon mit der nächsten FreeBSD-Version nicht mehr kompatibel war. So etwas müsste ja gepflegt werden.
Deshalb haben mehrere Leute schon zart an @marcel appelliert, doch mal einen dsbm-networkmgr zu basteln. Seine anderen Tools passen sehr gut zu FreeBSD. ;)
 
Was nicht deutlich wird: ist das deine .xinitrc? oder ein autostart.sh, das aus .xinit.rc aufgerufen wird?

Es ist eine autostart.sh, das aus .xinit.rc aufgerufen wird. Sie startet das Panel, sogar das Inet und es klappt auch alles. Hier auf Salix arbeite ich mit Fluxbox, da wird die autostart.sh nicht aus der .xinitrc aufgerufen. Was mir richtiger erscheint, aber egal es funzt.

Da ich das Inet mit dem sudo-Befehl aus dem BB-Menü heraus neu starten kann, und darüber hinaus das ältere grafische Wifi-Tool 'wifimgr' installiert ist, habe ich erstmal "aufgeräumt" und FF, Midori, Slim, networkmgr wieder deinstalliert, zusammen mit den etlichen Abhängigkeiten.

Eine grafische Rückmeldung über Verbindung mit dem Internet wäre sicher nett, aber funktional gesehen klappt doch alles bestens as is.

Das alles geht einfach von der Konsole.
Du bist ja selber froh über Dein farbenprächtiges Panel :)

Allerdings gleichzeitig den Firefox oder LibreOffice nutzen
Hab bislang alles mit Abiword gemacht, welches auf Salix in einer Gtk3-Version etwas buggy daherkommt. Das ist alles imho ein recht ärgerliches Thema...

Die neuen Webstandards, durch die etliche schöne schlanke Browser viele Seiten nicht mehr korrekt darstellen und im Grunde unbrauchbar geworden sind, diese ärgerliche Mischung aus Gtk2, Gtk3 und QT.

Zur Zeit schreibe ich von QupZilla, der läuft soweit ganz gut. Aber für Überweisungen mit Transwise zB muss ich dann doch den FF anschmeißen, und selbst der stellt Radiobuttons nicht korrekt dar. Im Grunde wird man zur Verwendung von FF, Chrome oder dergl. gezwungen.

Sowas wäre mir früher undenkbar vorgekommen und ist mitterweile normal. Abiword ist essentiell für mich, stürzt aber leicht ab und sieht grottig aus. Ja nun, es nervt halt... alles Verschlimmbesserungen, die keiner braucht.

Da hatte jemand spontan mal was eigenes umgesetzt, was ganz gut begann, aber schon mit der nächsten FreeBSD-Version nicht mehr kompatibel war.

Ich hatte ja schon ein paar mal geschrieben, daß es ein Konsole-Tool gibt, was die verfügbaren Netzwerke zur Auswahl listet. Das ist bereits installiert, weil es im Zuge des Installationsvorganges auftaucht. Ich weiß aber nicht, wie es aufgerufen wird.

Auf Tiny Core gibt es einen BB-Menüeintrag 'wifi', daß ein xterm mit eben einem solchen Programm öffnet und dann kann man auswählen. Puppy Linux hat auch jede Menge simpelster aber genialer Tools.

Es wäre ja auch nicht schwer, ein Script zu schreiben, was bei gelungenem bzw gescheiteren Verbindungsaufbau eine notification oder eine xdialog-infobox aufpoppt. Wenn man einen minimalistischen Ansatz mag, reicht das doch schon fast aus...
Darum finde ich es jetzt erstmal ok, so wie es ist...
 
Zurück
Oben