mfm
(Themenstarter)
Anmeldungsdatum: 11. August 2006
Beiträge: 3159
Wohnort: fd47:1519:0378::/48
|
Also ich habe die Anleitung nochmals buchstabengetreu ausprobiert und war erfolgreich. Noch eine Frage: Ich würde in dem Abschnitt Beispiel für eine DWL-G650+ als Quelle den folgenden Teil gerne farblich hervorheben: Nickname:"acx v0.3.36" weiss irgendjemand, wie das funktionieren könnte?
|
Matthias
Anmeldungsdatum: 25. Juni 2006
Beiträge: 1257
Wohnort: Deutschland
|
Geht leider wegen technischen Einschränkungen nicht.
|
mfm
(Themenstarter)
Anmeldungsdatum: 11. August 2006
Beiträge: 3159
Wohnort: fd47:1519:0378::/48
|
Ich habe den Artikel noch einmal überarbeitet und ein paar Fehler korrigiert. Ist nun noch irgendetwas verbesserungswürdig? Baustelle/Kismet
|
Adna_rim
Anmeldungsdatum: 8. November 2006
Beiträge: 2521
|
Vielleicht dmesg | grep -i wireless anstatt die User nur auf die recht endlose Ausgabe von dmesg zu verweisen? Dann hast du schon wieder diesen Teil mit der Editierung der /etc/network/interfaces reingenommen, obwohl ich bereits mehrmals darauf hingewiesen habe, dass das nicht stimmt. Also nochmal ausführlich: * bis zu edgy eft wird die /etc/network/interfaces vom network-manager komplett ignoriert! * seit feisty fawn gibt es Kriterien ob sie benutzt wird oder nicht. Aus der Changelog:
+ * NetworkManager now reads the network interface configuration specified in + /etc/network/interfaces. Devices that are listed there and match certain + criteria are *not* managed by NetworkManager anymore. + For more on information on what these criteria are please read + /usr/share/doc/network-manager/README.Debian, section "Configuration".
Aus der /usr/share/doc/network-manager/README.Debian:
Configuration of wireless and ethernet interfaces ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Only devices that are *not* listed in /etc/network/interfaces or which have been configured "auto" and "dhcp" (with no other options) are managed by NM. This way you can setup a custom (static) configuration for a device and NM will not try to override this setting. After modifying /etc/network/interfaces you have to restart NM with the command "/etc/dbus-1/event.d/25NetworkManager restart". Examples: 1.) auto wlan0 iface wlan0 inet dhcp → This device is managed by NM. 1.a) allow-hotplug eth0 iface eth0 inet dhcp → This device is managed by NM 2.) auto wlan0 iface wlan0 inet dhcp wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf → This devices is *not* managed by NM because it has additional options. 3.) iface wlan0 inet dhcp → This device is *not* managed by NM because it is not set to "auto". 4.) iface eth0 inet static address 192.168.1.10 netmask 255.255.255.0 gateway 192.168.1.1 → This device is *not* managed by NM because it is configured as "static" and has additional options. 5.) Device is not listed in /etc/network/interfaces. → Device is managed by NM.
Conclusio des ganzen: Wenn du einen Eintrag in der interfaces Datei austrägst bzw. auskommentierst, dann wird er zwangsläufig vom NM verwaltet! Du solltest diesen Part also wieder aus dem Artikel entfernen. Achja und ich hatte nachdem ich das Workaround Skript geschrieben hatte mit dem Kismet-Developer Kontak aufgenommen und er hat in die neueste stable Version von Kismet (s. Changelog) meine dbus-Lösung bereits integriert:
DBUS support for controlling NetworkManager
. Also ab Version 2007-10 R1 ist das ganze was unter Fehlerbehebung steht obsolet. greets
|
Adna_rim
Anmeldungsdatum: 8. November 2006
Beiträge: 2521
|
Lebst du noch ? Ich habe den interfaces Part jetzt wieder auskommentiert und einen Hinweis eingefügt, dass ab Version 2007-10-R1 Kismet den NM automatisch beendet. Ausserdem habe ich den dmesg-Befehl in dmesg | egrep -i '(wireless|wlan)' umgewandelt.
|
mfm
(Themenstarter)
Anmeldungsdatum: 11. August 2006
Beiträge: 3159
Wohnort: fd47:1519:0378::/48
|
Adna rim hat geschrieben: Lebst du noch ?
Ja. Nur weil ich ein paar Tage nicht antworte habe ich noch lange kein Messer im Rücken stecken... Adna rim hat geschrieben: Ich habe den interfaces Part jetzt wieder auskommentiert und einen Hinweis eingefügt, dass ab Version 2007-10-R1 Kismet den NM automatisch beendet.
Letzteres hört sich gut an. Mal schauen, wann die Version den Weg in die Paketquellen findet. 8) Meinen ursprünglichen Anwendungsfall, "schwarze" APs auf dem Firmengelände mit einer WLAN-Karte zu suchen während ein zweites Interface weiterhin mit dem Firmennetz verbunden ist, lässt sich damit leider nicht abgedecken. Für Feisty scheint das ja so wie beschrieben/auskommentiert zu funktionieren, könnte man es nicht mit einem entsprechenden Hinweis trotzdem mit in die Anleitung nehmen? Danke im übrigen für den Hinweis auf die README.Debian, nach sowas hatte ich schon mal verzweifelt gesucht. Adna rim hat geschrieben: Ausserdem habe ich den dmesg-Befehl in dmesg | egrep -i '(wireless|wlan)' umgewandelt.
Bei den meisten Karten sollte das funktionieren. Meine Ralink allerdings habe ich so nicht gefunden. Dazu habe ich das Ding eingesteckt und tail bemüht:
dmesg | tail -n 20
|
Adna_rim
Anmeldungsdatum: 8. November 2006
Beiträge: 2521
|
mfmenzer hat geschrieben: Nur weil ich ein paar Tage nicht antworte habe ich noch lange kein Messer im Rücken stecken...
Man weiss ja nie 😉 mfmenzer hat geschrieben: Meinen ursprünglichen Anwendungsfall, "schwarze" APs auf dem Firmengelände mit einer WLAN-Karte zu suchen während ein zweites Interface weiterhin mit dem Firmennetz verbunden ist, lässt sich damit leider nicht abgedecken.
Ich glaube das lässt sich nur durch eine zweite Wlan-karte realisieren. mfmenzer hat geschrieben: Für Feisty scheint das ja so wie beschrieben/auskommentiert zu funktionieren, könnte man es nicht mit einem entsprechenden Hinweis trotzdem mit in die Anleitung nehmen?
Aber das tut es doch gerade nicht. Die Readme ist ja von der feisty-version vom NM und ich wiederhole das mal nochmal:
Only devices that are *not* listed in /etc/network/interfaces or which have been configured "auto" and "dhcp" (with no other options) are managed by NM.
Also wenn was auto und dhcp in der /interfaces gelistet ist wird es vom NM verwaltet. Wenn du dies jedoch auskommentierst, dann ist das ja genauso als ob es garnicht drinstehen würde. Und laut readme: "devices that are *not* listed in /etc/network/interfaces[..]are managed by NM", werden diese dann ebenfalls vom NM verwaltet. Nur wenn ein device in der interfaces Datei als static konfiguriert ist oder zusätzliche Optionen eingebunden sind wird es nicht verwendet. Also ich kann halt nur sagen, was in der readme und den docs steht, da meine interfaces Datei bis auf die loopback Schnittstelle eh komplett leer ist. mfmenzer hat geschrieben: Bei den meisten Karten sollte das funktionieren. Meine Ralink allerdings habe ich so nicht gefunden. Dazu habe ich das Ding eingesteckt und tail bemüht:
dmesg | tail -n 20
Oh ich habe gedacht, dass eigentlich jeder Wlan-treiber sich auch als solches outed. Dann sollte man das wieder ändern. Weisst du ob Wlan-treiber immer am Ende von dmesg auftauchen, weil mit tail -n 20 wird auch mein ipw3945 angezeigt. Dann wär das ja die bessere Alternative. greets
|
Ubunux
Anmeldungsdatum: 12. Juni 2006
Beiträge: 16331
|
Hallo, warum nicht per lspci und/oder lsusb den Chipsatz abfragen? Ein Konstrukt mit dmesg und grep (dmesg | grep -i wireless) bringt natürlich auch Drahtlose Mäuse o.ä. zum Vorschein. 😉 im Falle von PCI u. PCMCIA würde doch lspci | grep -i net ausreichend Infos geben, im Falle von USB genügt die Ausgabe von lsusb. Auf diese Weise fragen auch die meisten Supporter im Forum die Chipsätze ab. Ausserdem: Ist es denn überhaupt notwendig, so ins Detail zu gehen? Wer Kismet braucht, weiß doch in der Regel, welchen Chipsatz er verwendet. Gruß Ubunux
|
Adna_rim
Anmeldungsdatum: 8. November 2006
Beiträge: 2521
|
Hey mfm, ich hab jetzt noch einige letzte Dinge gefixt. Und würde sagen, wenn du den Part über deinen DWL-Chipsatz von dmesg auf lspci umstellst, also ich meine das hier:
~$ dmesg (...) [ 671.820000] acx: found ACX111-based wireless network card at 0000:03:00.0, irq:17, phymem1:0x30020000, phymem2:0x30000000, mem1:0xdee90000, mem1_size:8192, mem2:0xdeec0000, mem2_size:131072 [ 671.820000] acx: loading firmware for acx1111 chipset with radio ID 16 (...) [ 672.856000] acx: === chipset TNETW1130, radio type 0x16 (Radia), form factor 0x01 ((mini-)PCI / CardBus), EEPROM version 0x05: uploaded firmware 'Rev 1.2.1.34' === [ 672.856000] acx v0.3.36: net device wlan0, driver compiled against wireless extensions 21 and Linux 2.6.20-16-386 [ 673.140000] ADDRCONF(NETDEV_UP): wlan0: link is not ready
dann ist der Artikel fertig.
|
mfm
(Themenstarter)
Anmeldungsdatum: 11. August 2006
Beiträge: 3159
Wohnort: fd47:1519:0378::/48
|
Ich habe die lspci -Ausgabe ergänzt. Die Permanent-Konfiguration habe ich unter Verweis auf den interfaces-Artikel wieder aufgenommen und bin in diesem Zuge darauf gestossen, dass unter Gutsy anscheinend der Network-Manager von den Kismet-Schnittstellen getrennt wird. Jedenfalls werden verwendete Schnittstellen von aktiven Verbindungen getrennt und nahmen anschließend wieder ihre Arbeit auf. Ich verwende die Kismet-Version aus den offiziellen Gutsy-Quellen. Kann das bitte jemand bestätigen oder widerlegen? PS: Der Fall der dauerhaften Konfiguration einer Schnittstelle für Kismet ist der wichtigste Anwendungsfall für mich und meine Kollegen, da dabei die WLAN-Verbindung über die andere Schnittstelle bestehen bleibt. Ich bin für Hilfe beim Verbessern und Korrigieren auch dieses Teils des Artikels dankbar, nicht aber für die Löschung. Unter Umständen hat sich das für Gutsy aber sowieso erledigt...
|
Adna_rim
Anmeldungsdatum: 8. November 2006
Beiträge: 2521
|
Hi ☺ mfm hat geschrieben: Die Permanent-Konfiguration habe ich unter Verweis auf den interfaces-Artikel wieder aufgenommen
Mir ist immernoch nicht klar was du damit bezwecken möchtest? Wie gesagt (ich erinnere an die readme, die ich oben gepostet hatte) ein Auskommentieren erzeugt das Gegenteil von dem was du damit erreichen willst. Im Interfaces-Artikel steht auch nichts hilfreiches dazu drin. mfm hat geschrieben: und bin in diesem Zuge darauf gestossen, dass unter Gutsy anscheinend der Network-Manager von den Kismet-Schnittstellen getrennt wird. Jedenfalls werden verwendete Schnittstellen von aktiven Verbindungen getrennt und nahmen anschließend wieder ihre Arbeit auf. Ich verwende die Kismet-Version aus den offiziellen Gutsy-Quellen. Kann das bitte jemand bestätigen oder widerlegen?
Bin seit gutsy auf fluxbox und wicd umgestiegen, für mich deswegen nicht so leicht möglich zu testen... mfm hat geschrieben: PS: Der Fall der dauerhaften Konfiguration einer Schnittstelle für Kismet ist der wichtigste Anwendungsfall für mich und meine Kollegen, da dabei die WLAN-Verbindung über die andere Schnittstelle bestehen bleibt.
WLAN-Verbindung + Kismet gleichzeitig mit nur einer WLAN-Karte ist laut Aussage des Developers von Kismet definitiv nicht möglich. Das hatte er in unserer Korrespondenz bezüglich des Dbus-hacks ab Version 10-Rb1 bestätigt. greets
|
mfm
(Themenstarter)
Anmeldungsdatum: 11. August 2006
Beiträge: 3159
Wohnort: fd47:1519:0378::/48
|
Adna rim hat geschrieben: WLAN-Verbindung + Kismet gleichzeitig mit nur einer WLAN-Karte ist laut Aussage des Developers von Kismet definitiv nicht möglich.
Aus diesem Grunde werden zwei Karten verwendet, von denen eine nur für Kismet vorgesehen ist. Adna rim hat geschrieben: Mir ist immernoch nicht klar was du damit bezwecken möchtest?
Scannen und trotzdem surfen. 8) Nee, die Kollegen benötigen bei der Jagd nach wilden AP's auf dem Firmengelände Zugriff auf eine Serveranwendung. Mit deinem Skript wird der Network-Manager vollständig abgeschaltet, wodurch jegliche Konnektivität verloren geht, es sei denn man bastelt etwas mit wpa-supplicant (wozu ich zu faul bin...) Aber durch den oben beschriebenen Effekt ist das ja vielleicht hinfällig....
|
noisefloor
Ehemaliger
Anmeldungsdatum: 6. Juni 2006
Beiträge: 28953
Wohnort: WW
|
Hallo, ihr diskutiert ja schon ziemlich lange - und ich haben den Faden verloren. ☹ Also: Wenn jemand, z.B. mfm, zwei Netzwerk-Karten einsetzt, dann ist das doch ok - die 2. kann man schließlich nicht wegdiskutieren. Ob jemand anders das sinnvoll findet oder nicht ist auch eine andere Frage. Wenn der Artikel so geschrieben ist, dass er mit ein oder zwei WLAN Karten nachvollziehbar ist - gut. Wenn er ausschließlich mit zweien funktioniert - nicht gut. Wo ist euer Punkt, um den es seit 20 Postings geht? 😉 Gruß noisefloor
|
Ubunux
Anmeldungsdatum: 12. Juni 2006
Beiträge: 16331
|
noisefloor hat geschrieben: Wo ist euer Punkt, um den es seit 20 Postings geht? 😉
immer langsam mit die jungen Pferde, ich denke es geht schlicht darum, dass der Artikel gut wird 8)
|
Adna_rim
Anmeldungsdatum: 8. November 2006
Beiträge: 2521
|
noisefloor hat geschrieben: Wenn der Artikel so geschrieben ist, dass er mit ein oder zwei WLAN Karten nachvollziehbar ist - gut. Wenn er ausschließlich mit zweien funktioniert - nicht gut.
Dagegen hat niemand was ☺
Wo ist euer Punkt, um den es seit 20 Postings geht? 😉
Dass mfm meiner Meinung nach den Zugriff des NM auf eine Schnittstelle auf eine Weise unter binden will, wie es unmöglich ist. Jedoch kann dies seit Gutsy auch komplett überflüssig geworden sein wie er berichtet. Es müsste nur mal noch wer anders testen.
|