Minihowto: networkmgr - ein Verbindungstool für Ethernet und Wifi

Ja das hab ich auch gerade gelesen. Jedoch hatte ich es gesternbgetestet und Fakt ist, dass es die $PATH des Users nimmt. Ich konnte ein beliebiges script als root ausführen. Ist der Port evtl. fehlerhaft?
Bis auf auskommentiertes pledge seh ich nichts besonderes

Code:
  const char *safepath = "/bin:/sbin:/usr/bin:/usr/sbin:"
    "/usr/local/bin:/usr/local/sbin";
Code:
  if (rule->cmd) {
     if (setenv("PATH", safepath, 1) == -1)
       err(1, "failed to set PATH '%s'", safepath);
   }

Quelle Sourcecode:
http://www.freshports.org/security/doas
 
Hallo,

ich finde die Diskussion, die mittlerweile entstanden ist, sehr gut. Mir ging es ja nicht darum: Hey, hier gibt es das tolle Tool für Wifi-.Verbindungen.
Es gibt da offenbar noch Verbesserungs- und auch Stabilisierungsbedarf, wie ich mittlerweile selbst festgestellt habe (vorhin gab es bei mir wieder keine Box mit der Eingabemöglichkeit für das Paßwort).
Wenn daraus Verbesserungsvorschläge für networkmgr entstehen, oder andere Tools als Alternative erwähnt werden und die ganze Thematik mal etwas Präsenz bekommt (zumal Bedarf ja offensichtlich dafür vorhanden ist), dann ist hoffentlich für einige hier dieser Thread nützlich.

GhostBSD werde ich auch mal testweise auf meinem Notebook installieren und schauen, ob da das Tool reibungsloser aebeitet. Die Installation auf meinem Desktop-PC verhalf mir zwar dazu, ein schönes Mate-basiertes BSD-System kennen zu lernen aber Tests mit networkmgr bei einem Lan-verbundenen Rechner sind dann doch ziemlich witzlos.
 
Also ich habe hier wifimgr gerade wieder verwendet bei einem neueingerichteten Notebook, es läuft tadellos! Einmal das Netzwerk manuell eingeben (als wäre es ein verstecktes, da alle Felder leer sind) danach als root "service netif restart" und anschliessend werden bei wifimgr auch die normalen Netzwerke angezeigt und das WLAN was man vorher eingegeben hat funktioniert :)
 
Also ich habe hier wifimgr gerade wieder verwendet bei einem neueingerichteten Notebook, es läuft tadellos! Einmal das Netzwerk manuell eingeben (als wäre es ein verstecktes, da alle Felder leer sind) danach als root "service netif restart" und anschliessend werden bei wifimgr auch die normalen Netzwerke angezeigt und das WLAN was man vorher eingegeben hat funktioniert :)

Hallo @Lance

schön zu lesen aber bitte die Einwände zu doas beachten:
https://www.bsdforen.de/threads/doas-unter-freebsd.33759/
https://www.bsdforen.de/threads/doas-unter-freebsd.33759/
Und was meinen Test angeht: Der Intel-Wlan Chip meines Testnotebooks TP R500 will nicht mehr mit FreeBSD :(
 
Und was meinen Test angeht: Der Intel-Wlan Chip meines Testnotebooks TP R500 will nicht mehr mit FreeBSD

Hallo,

es hat sich offenbar etwas seit 11.x geändert. Wenn ich in die /boot/loader.conf noch folgendes hineinschreibe:
Code:
 if_iwn_load="YES"
       iwn1000fw_load="YES"
       iwn100fw_load="YES"
       iwn105fw_load="YES"
       iwn135fw_load="YES"
       iwn2000fw_load="YES"
       iwn2030fw_load="YES"
       iwn4965fw_load="YES"
       iwn5000fw_load="YES"
       iwn5150fw_load="YES"
       iwn6000fw_load="YES"
       iwn6000g2afw_load="YES"
       iwn6000g2bfw_load="YES"
       iwn6050fw_load="YES"

dann klappt es - wenn auch leider mit etwas Verzögerung - wieder mit meinem Intel-Wlan-Chip. Unter FreeBSD 10.x war das meiner Erinnerung nach nicht erforderlich.

Das Fujitsu-Siemens Notebook mit ath-Wlan-Chip bringt dagegen sehr flott eine Verbindung zustande.

Nun kann ich mich daran machen, mir networkmgr nochmal genauer anzuschauen.
 
Hallo Rob,

die Schwierigkeit liegt nicht im Erkennen der Wlan-Karte durch das System sondern im Aufbau der Wlan-Verbindung, hier ein dmesg-Auszug:
Code:
iwn0: iwn_read_firmware: ucode rev=0x08530501
wlan0: link state changed to UP
ums0 on uhub7
ums0: <PixArt USB Optical Mouse, class 0/0, rev 2.00/1.00, addr 2> on usbus0
ums0: 3 buttons and [XYZ] coordinates ID=0
ubt0 on uhub5
ubt0: <Lenovo Computer Corp ThinkPad Bluetooth with Enhanced Data Rate II, class 224/1, rev 2.00/3.99, addr 3> on usbus1
wlan0: link state changed to DOWN
iwn0: device timeout
iwn0: iwn_read_firmware: ucode rev=0x08530501
wlan0: link state changed to UP
wlan0: link state changed to DOWN
wlan0: link state changed to UP
wlan0: link state changed to DOWN
iwn0: device timeout
iwn0: iwn_read_firmware: ucode rev=0x08530501
ugen0.2: <PixArt USB Optical Mouse> at usbus0 (disconnected)
ums0: at uhub7, port 1, addr 2 (disconnected)
ums0: detached
ugen0.2: <PixArt USB Optical Mouse> at usbus0
ums0 on uhub7
ums0: <PixArt USB Optical Mouse, class 0/0, rev 2.00/1.00, addr 2> on usbus0
ums0: 3 buttons and [XYZ] coordinates ID=0
wlan0: link state changed to UP
wlan0: link state changed to DOWN
iwn0: scan timeout
iwn0: iwn_read_firmware: ucode rev=0x08530501
wlan0: link state changed to UP

Dieses Spielchen dauert manchmal mehrere Minuten, manchmal endet es in einer iwn controller panic, manchmal kommt es dann zur Verbindung.
Networkmgr kriegt mit dieser Karte gar keine Verbindung zustande.

Mit einem Live-Linux steht die Verbindung übrigens innerhalb weniger Sekunden, daher schließe ich einen Defekt der Hardware erstmal aus.

Hier noch die Einträge in der /etc/rc.conf (vom Installer angelegt):
Code:
wlans_iwn0="wlan0"
ifconfig_wlan0="WPA DHCP"
create_args_wlan0="country DE"

Und hier in der /etc/wpa_supplicant.conf (vom Installer angelegt)
Code:
ctrl_interface=/var/run/wpa_supplicant
eapol_version=2
ap_scan=1
fast_reauth=1

network={
ssid="mein-device"
scan_ssid=0
psk="geheimes-paßwort"
priority=5
}
network={
        priority=0
        key_mgmt=NONE
}

Das nervt ziemlich und ich überlege schon, mir einen ath-basierten USB-Wlan-Stick zu besorgen :(
 
Code:
ap_scan
Access point scanning and selection control; one of 0, 1
(default), or 2. Only setting 1 should be used with the wlan(4)
module; the other settings are for use on other operating sys-
tems.
Muss das definiert werden?

Code:
eapol_version
The IEEE 802.1x/EAPOL protocol version to use; either 1 (default)
or 2. The wpa_supplicant(8) utility is implemented according to
IEEE 802-1X-REV-d8 which defines EAPOL version to be 2. However,
some access points do not work when presented with this version
so by default wpa_supplicant(8) will announce that it is using
EAPOL version 1. If version 2 must be announced for correct
operation with an access point, this value may be set to 2.
Müsste in deinem Fall nicht eine 1 verwendet werden (bzw. einfach nicht definieren)?

Würde ich zum debuggen raus lassen
 
Hi @mogbo,

danke für Dein Interesse:
zu wlans_iwn0="wlan0":
Warum macht ein Installer sowas, würde mich persönlich wirklich stören.
Das ist FreeBSD-Konvention und muss meines Wissens so, da macht der Installer keine exotischen abweichenden Extras.

Ich habe mal diesen Kram in der wpa_supplicant.conf auskommentiert:

#ctrl_interface=/var/run/wpa_supplicant
#eapol_version=2
#ap_scan=1
#fast_reauth=1

Das brauchte ich unter FreeBSD 10.x nämlich auch nicht. Bringt aber leider keine Verbesserung, die Verbindung braucht mehrere Minutern, bis sie steht mit einem munteren Wechsel zwischen up, down, timeout u.s.f.

Nun ist es spannend, mal mit einem FreeBSD 10.3 zu testen. Wenn es da wie früher fluppt, wurde mit 11.x etwas da geändert.
 
Hallo Rob,

Dein Tipp passt :)
Ich habe nun in der rc.conf folgendes stehen:
Code:
ifconfig_wlan0="WPA DHCP -ht40"

Repriduzierbar startet die Wlan-Verbindung nun sehr flott.

Danke für den Hinweis.

Viele Grüße
Holger
 
Und nun zu networkmgr:

Es baut sauber die Verbindung zu meinem HuaweiP9 auf, Disconnect per Mausklick funktioniert auch, ein neues Verbinden klappt ebenfalls.

Andere Netzwerke werden mir angezeigt. Zu Hause kann ich noch schauen, wie es wahlweise mit unserem Wlan der AVM Fritte und meinem HuaweiP9 klappt.
 
Zurück
Oben