staging.inyokaproject.org

So, hab die Anleitung mal reingestellt, was noch fehlt sind die Herkunft der Pakete (universe, ...), da wusste ich nicht wo ich nachschauen sollte. Und folgende Warnungen beim Kompilieren von kismet sind mir noch aufgefallen, mit denen ich aber nichts anfangen kann. Na ja funktionieren tut es trotzdem. 😉

configure: creating ./config.status
config.status: creating Makefile
config.status: WARNING:  Makefile.in seems to ignore the --datarootdir setting
config.status: creating extra/buzzme/Makefile
config.status: WARNING:  extra/buzzme/Makefile.in seems to ignore the --datarootdir setting
config.status: creating extra/Makefile
config.status: WARNING:  extra/Makefile.in seems to ignore the --datarootdir setting

Ach ja und die Verlinkung zur Wiki-Page vom Kompilieren müsste dann wohl noch oben rein.
Passt das mit dem Fortgeschrittenen-Hinweis so? 🙄 Oder müsste der für den ganzen Artikel gelten?

@Linux_rules: Sehr schön ☺ Ich habe das ganze mal etwas angepasst, so müssen zB flex und lipcap nicht manuell installiert werden, sondern können aus den Paketquellen genommen, werden. Flex liegt dort schon in der aktuellsten Version vor und die Version 0.8 von libpcap reicht ebenfalls aus. Die Pakete sind alle aus den offiziellen Paketquellen, deswegen muss auch kein universe bzw. multiverse dahinter. Ausserdem habe ich noch angefügt, dass die Konfig-datei woanders liegt als bei Kismet aus den repos.

@mfmenzer: Da ich erfahren habe, dass die interfaces Datei von der Ubuntu-Version des Network-Managers komplett ignoriert wird habe ich den Part aus der Konfiguration auskommentiert. Da der NM seit Feisty standardmässig installiert ist habe ich einen Hinweis am Anfang von Benutzung reingesetzt.

@steinson: Dann bist du ja direkt am 2.ten Schritt der Konfiguration gescheitert 😉 Also entweder du liest den Artikel erst zu Ende bevor fu anfängst Pakete zu installieren oder du löscht es jetzt einfach wieder vollständig mit: sudo apt-get remove --purge kismet.

greets

@ adna rim

Ich habe ja die Anleitung zuerst gelesen, bis ich das paket überhaupt installiert habe... Da stand aber eben gerade nicht, dass es für WLAN-Karten die per ndiswrapper laufen, nicht funktioniert... Daher habe ich ja keine ahnung gehabt, ob es überhaupt klappt. Und dann ist man schon etwas enttäuscht, wenn man während der Konfiguration feststellt, dass die Sache nicht funzt!

Achja, und das entfernen des Pakets ist ja schon längst passiert. (Trotzdem vielen Dank für die Info - wobei ich es auch schon selbst gewusst habe...)

Servus

steinson

Wie gesagt zweiter Schritt in der Konfiguration:

Der dazu passenden Treiber muss unter Punkt 12 "Capture Sources" aus der Datei /usr/share/doc/kismet/README.gz (oder auf der Kismet-Seite 🇬🇧 ) herausgesucht werden.

und dort:

ndiswrapper - Anything using ndiswrapper is using WINDOWS drivers
AND CAN NOT BE USED WITH KISMET.

Keine Ahnung vielleicht sollte man einen Hinweis anfügen, dass die Leute erst schauen sollen ob ihr Treiber überhaupt von Kismet unterstüzt wird bevor sie Kismet installieren, imo allerdings so sinnig, wie im GAIM Artikel zu vermerken, dass man dazu Internet benötigt 😉

Adna rim hat geschrieben:

Keine Ahnung vielleicht sollte man einen Hinweis anfügen, dass die Leute erst schauen sollen ob ihr Treiber überhaupt von Kismet unterstüzt wird bevor sie Kismet installieren, imo allerdings so sinnig, wie im GAIM Artikel zu vermerken, dass man dazu Internet benötigt 😉

Hallo,
das imho ist schon ein Unterschied, Gaim geht mit jedem Internetanschluß 😉
Soch ein Hinweis erspart u.U. unnötige Fragen im Forum (ich weiß, da bin ich zu optimistisch 😉 )
Viele Leute wissen eben nicht, was z.B. ein monitor-mode ist und dass dies nicht von allen Karten unterstützt wird.
Obwohl, wer Kismet braucht, sollte sowas wissen 🤓
Gruß
Ubunux

So ich habe ein weiteres Workaround für den Network-Manager erzeugt. Man speichert dieses Skript einfach in der Datei Kismet (← man beachte grosses K) im Pfad /usr/local/bin . Wenn man jetzt kismet mit dem Befehl:

sudo Kismet

startet, dann wird alles automatisch gemacht und mann muss den NM nicht von Hand deaktivieren und nach dem Beenden von Kismet wieder aktivieren. Ich werde das jetzt in eine Trouble-shooting Überschrift umschreiben.

Adna rim hat geschrieben:

...vielleicht sollte man einen Hinweis anfügen, dass die Leute erst schauen sollen ob ihr Treiber überhaupt von Kismet unterstüzt wird bevor sie Kismet installieren...

Bezüglich dieses Hinweises: würdet ihr mal bitte prüfen, ob

iwpriv [Interface]

bei euch auch eine Zeile wie die folgende ausspuckt:

monitor           (8BF6) : set    2 int      & get     0

Ich meine, iwpriv gibt die möglichen aufrufbaren Funktionen eines Chipsatzes an. Wenn monitorfehlt würde das bedeuten, dass die karte sich nicht in den Monitor-Modus versetzen llassen würde.
Das heisst auch, dass bei allen Karten, mit denen Kismet läuft, das monitorauftauchen müsste.

Edit: Ich habe den Hinweis hinzugefügt und jetzt die ganze Seite als "Fortgeschritten" gekennzeichnet.
@ Adna rim: Ich habe Programme_kompilieren zu den vorausgesetzten Seiten genommen. Kannst du die Anleitung zum Komiplieren ein bisschen darauf anpassen?

mfmenzer hat geschrieben:

Ich meine, iwpriv gibt die möglichen aufrufbaren Funktionen eines Chipsatzes an. Wenn monitorfehlt würde das bedeuten, dass die karte sich nicht in den Monitor-Modus versetzen llassen würde.
Das heisst auch, dass bei allen Karten, mit denen Kismet läuft, das monitorauftauchen müsste.

Hallo,
bei Atheros basierenden Karten ist dies etwas anders: http://madwifi.org/wiki/UserDocs/FirstTimeHowTo#CreatinganInterface
Gruß
Ubunux

mfmenzer hat geschrieben:

@Adna rim: Ich habe Programme_kompilieren zu den vorausgesetzten Seiten genommen. Kannst du die Anleitung zum Komiplieren ein bisschen darauf anpassen?

Hab den Abschnitt 'Manuelle Installation' gekürzt und nur auf den Wissensartikel verwiesen.

Ubunux hat geschrieben:

bei Atheros basierenden Karten ist dies etwas anders: http://madwifi.org/wiki/UserDocs/FirstTimeHowTo#CreatinganInterface

Hmm, hat jemand so eine Karte und könnte das mal ausprobieren? (Das war eine Aufforderung ☺ )

Adna rim hat geschrieben:

Hab den Abschnitt 'Manuelle Installation' gekürzt und nur auf den Wissensartikel verwiesen.

Danke!

Hallo,
wenn ich keine solche Karte hätte, dann wüßte ich es wahrscheinlich auch nicht. 😉
Mein Vorschlag: den Zusatz mit iwpriv ganz weglassen und nur auf die Homepage bzw. das Readme verweisen.
Gruß
Ubunux

Ubunux hat geschrieben:

Mein Vorschlag: den Zusatz mit iwpriv ganz weglassen und nur auf die Homepage bzw. das Readme verweisen.

Das wäre zwar am einfachsten, aber es stellt sich die Frage wer alles darüberhinwegsieht und einfach mal mit Installieren anfängt. Liest man den Namen seiner Karte oder einen kurzen Hinweis, wie man überprüfen kann ob die eigene Karte geeignet ist, dann schenkt man diesem mehr Aufmerksamkeit.
Aber nochmal zu dem Link (ich habe ihn mir gerade eben erst angeschaut). Ich steige da noch nicht richtig dahinter - Hast du ein Problem mit dem Atheros-Chipsatz an sich oder mit Madwifi? und warum sollte dort iwpriv nicht funktionieren?

bei meiner Intel-karte:

iwpriv eth1
eth1 Available private ioctls :
set_power (8BE0) : set 1 int & get 0
get_power (8BE1) : set 0 & get 80 char
set_mode (8BE2) : set 1 int & get 0
get_mode (8BE3) : set 0 & get 80 char
set_preamble (8BE4) : set 1 int & get 0
get_preamble (8BE5) : set 0 & get 16 char
reset (8BE7) : set 0 int & get 0
monitor (8BE6) : set 2 int & get 0

Hallo,
ich habe hier keine Probleme; oder hast Du hier von mir schonmal eine Frage gesehen? 8)
Kurze Erklärung: der madwifi-treiber arbeitet mit sogenannten VAPs, dies sind virtuelle Schnittstellen, die man per wlanconfig erzeugen und konfigurieren kann, ich kann also auf einer physikalischen Karte gleichzeitig mehrere Modi nutzen. Das eigentliche Device ist dabei wifi0 und die VAPs heissen dann ath0, ath1 usw.
Zudem kann man Karten mit Atheros-Chip auch in einen AP-Modus bringen, u.a ein Grund, warum ich solche Karten benutze; in meinem IpCop werkelt so eine Karte als Wlan-Router. 😉
Es genügt eigentlich zu wissen, dass Atheros-Karten den Monitor-Modus beherrschen.
Zum Schluß bin ich der Meinung, dass man von Usern, die Kismet benutzen wollen, schon verlangen sollte, genau zu lesen, man muss nicht alles "idiotensicher" machen. Falls die Karte mit Kismet nicht funktionieren sollte bekommt man schon einen richtigen Hinweis von Kismet.
Wahrscheinlich bekommt man mehr Fragen hier im Forum, wenn iwpriv nicht das Richtige anzeigt, wie wenn man den Hinweis gleich ganz wegläßt.
Gruß
Ubunux

hier mal meine Ausgabe: http://ubuntuusers.de/paste/15149/ 😉

Zur Info:
Ich habe mir noch eine WLAN-Karte beschafft und versuche das Ganze nochmal nachzustellen - Es ist eine mit Atheros-Chipsatz 🤣