wlan-funktek

wlanicht nötig, lieber ein kleines Zitat von Dir hier reinposten:
>
>> rm * -rf
> Und damit disqualifiziert man sich selbst, wenn man nicht mal weiß,
> dass Optionen *vor* die Argumente gehören.
> Sind keine Dateien - so der Normalfall - im Verzeichnis /, so
> bekommst Du da nur einen Fehler “File not found” für “*” und “-rf”
>
> Abgesehen davon, dass vom Verzeichnis / vorher nicht die Rede war,
falsch, laut Ausgangspost vom Tautologen:
>> Danach als root anmelden, und zum Test im root-Verzeichnis
folgenden
>> Befehl eingeben:
>>
>> rm * -rf
> löscht der Befehl wohl doch eher rekursiv ohne Warnungen oder
> Nachfragen auszugeben. (Sofern nicht zufällig noch eine Datei namens
> “–” irgendwo da rumliegt.)
Korrekt, durch die Sortierung ist “–” dann vor allen anderen Dateien
und die Optionen am Ende “-rf” werden als Dateiname betrachtet und
sorgen damit nur für eine Fehlermeldung.
> > Wenn ein Kommando somit von der offiziell vorgegebenen Syntax für die
> > Anwendung abweicht, so ist das nicht nur ein Schönheitsfehler,
> > sondern kann extreme Seiteneffekte nach sich ziehen.
> In einer Beschreibung, wie man das WLAN zum Laufen bekommt, ist das
> Kommando “rm * -rf” sowieso bösartig.
Klar, aber der OP hat getrollt und die Troll-Antwort mit dem “rm *
-rf” ist schon übel bösartig, insbesondere wenn tatsächlich das ein
angehender Ubuntuuser liest und das ggf. für bare Münze nimmt.
> Ich habe noch nicht gehört, dass sich Malware gerne an Standards oder
> Konventionen hält. Im Gegenteil: Gerne wird dagegen verstossen,
> wenn’s denn trotzdem funktioniert.
Deswegen entwickle ich meine Sachen POSIX konform und verlasse mich
nicht darauf, dass irgendwelche Sortierungen passen oder
Sonderzeichen bei Dateinamen von der Shell per “\”-Quote maskiert
werden.
> Er hätte natürlich auch schreiben können: rm –enable-lan –option /
> -rf (wobei ich das jetzt nicht getestet habe und auch niemandem
> empfehlen würde, obiges irgendwo einzugeben … )
Jupp, genausowenig allerdings wie ein: rm -rf *
> > Jemand will im aktuellen Verzeichnis alle seine Dateien löschen, es
> > sind eine Unmenge Dateien mit langen Namen - aber nur mit Nachfrage,
> > er gibt daher an:
> > $ rm -i *
> # ls /*/*/*
> -bash: /bin/ls: Argument list too long
Das gilt für die bash, nicht aber für eine Bourne Shell oder gar die
/sbin/sh - mir geht’s hier wirklich auch darum, dass sich die Leute
einen sauberen Umgang mit den Tools angewöhnen. Treffen sie im RL mal
auf ein anderes System, so kann diese Gewöhnung vom einfachen
Nicht-Funktionieren Fehlersuche bis zu echten Betriebsproblemen
führen.
> bei mir wird nichts ausgeführt, wenn die Argumentliste zu lang ist.
> Vermutlich genau aus demselben Grund. Man macht lieber nichts und
> schmeisst ne Fehlermeldung raus, als die Hälfte möglicherweise falsch
> zu tun.
Genau für diese Fälle gibt’s ja xargs [Generierte Argumente in der Commandline]
> Wobei es Dir in solchen Fällen nicht hilft, alle Optionen vor den
> Argumenten zu schreiben. Einzig ein “–” hilft Dir in solchen Fällen,
> und das ist auch die offizielle Empfehlung.
Ja und da genau das die Empfehlung ist und alle Argumente *nach* dem
“–” nicht als Option gewertet werden ist die Nutzung von Optionen
*nach* den Fileargumenten kontraproduktiv.
[Syntax in den Manuals]
> wobei wie gesagt Leute mit schlechten Absichten sich nicht nach
> irgendwelchen offiziellen Vorgaben richten werden
*grins* leider, deswegen muss man umso sauberer bei der
Programmerstellung arbeiten und zufällige oder absichtliche
Fehleingaben abfangen. Spätestens dann braucht man “–” und damit
sind die Optionen am Ende der Argumentliste unsinnig.
[Ungültiges Kommando]
> Sorry, irgendwo in den Dokumentationen wird das spezielle Verhalten
> der gnu-utilities und wie man es abschaltet wohl dokumentiert sein.
Ja, in “man 3 getopt” - nur wer sieht da wirklich nach?
> Es wäre extrem bescheuert, dieses spezielle Verhalten in jeder
> Manpage aufzuführen.
Warum wird es dann implementiert, wenn es ein Spezialverhalten
darstellt?
> Erstens sind die Manpages nicht eine Beschreibung bis ins letzte
> Detail, das wäre der Quellcode.
Was zugegeben ein Vorteil von OpenSource ist, aber nicht jeder
*Anwender* ist in der Lage C-Code korrekt zu interpretieren.
> Zweitens kann jeder, der die Manpage gelesen und verstanden hat, rm
> bzw. andere Utilities umfassend benutzen und wenn man eine bestimmte
> Funktionsweise wissen will, findet man die in der Manpage.
Wo man aber nur das Verhalten mit den Optionen am Anfang dokumentiert
findet.
> Drittens würde die Manpage nur unnötig kompliziert.
Nein, ein Satz “options and other arguments could be used in mixed
sequence” oder ein “rm [OPTION]… FILE… [OPTION]…” für die
Syntax würde die 99% erschlagen wo jemand nicht die Optionen mitten
zwischen den Dateiargumenten “versteckt”.
> Viertens wäre es ein schlechter Programmier- bzw. Arbeitsstil, wenn
> man sich darauf verlässt, dass Optionen hinter Argumenten nicht
> beachtet werden. Dadurch würden sich in extremen Situationen auch
> Fehler in Scripte bzw. Arbeitsweisen einschleichen, auch wenn rm
> selbst Optionen hinter Dateinamen ignorierte.
D’accord - auf Grund der von Dir oben angegebenen Empfehlung “–” zu
verwenden ist der Zwang die Optionen *vor* den Dateinamen anzugeben
sowieso schon vorhanden und alles andere wäre bereits schlechter
Programmierstil.
Irgendwie sind wir uns ja doch einig *grins*
Auch wenn ich keine allgemeine Diskussion über Programmierstil in der
Shell lostreten wollte.
der bit-popler

wlanas passiert bei Angabe von “rm * -i”:
> Es werden alle Dateien einfach gelöscht, da bei der
> Dateinamenexpansion möglicherweise die Option “-i” nicht mehr in die
> Shell-Commandline passt. Die Auswertung der Dateinamensexpansion wird
> von der Shell durchgeführt, während die Auswertung der Optionen von
> jedem Kommando selbst gemacht wird.
Jetzt hast du ja ein Beispiel für die Voranstellung der Optionen
gefunden, wobei ich mir schon sicher sein muß, die Länge der
Kommandozeile nicht zu Ãœberschreiten. Du hast selber auch Methoden
aufgezählt, die das zeigen. Es geht aber nicht um den Sinn oder
Unsinn der Reihenfolge, sondern um die Syntax. Und die ist richtig.
Zumal das ursprüngliche Posting auch damit nichts am Hut hat. Der
Threaderöffner sollte angemacht werden und das ist gelungen mit einem
syntaktisch richtigem Kommando. Die Manpage brauche ich nicht hier im
gepostet. Da ich das Kommando auf Richtigkeit überprüfen konnte, ist
es mir auch möglich, die man/info-page aufzurufen. “rm [OPTION]…
DATEI…” schließt nicht aus, dass auch “rm DATEI… [OPTION]…”
gültig ist. Ich sehe nur, dass die Optionen optional sind und die
Reihenfolge “rm [OPTION]… DATEI…” i.O. ist. Wie dein kritisiertes
Posting dir gezeigt hat gilt auch: “rm DATEI… [OPTION]…” und dies
lässt sich auch auf allen Systemen nachvollziehen, die mir zu
Verfügung stehen.

>wlan> > Linux_Inside schrieb am 8. November 2002 14:13
> > > Das finde ich nicht gut. Ständig kommen irgendwelche
> > > Security-Advices, werden neue Hack-Methoden aufgedeckt, ist ja
> > > schlimmer als beim IE.
> > Wenn in Dir soviel Linux drin ist wie Dein Nick suggeriert, solltest
> > Du keine Probleme haben, WEP gegen ein VPN einzutauschen, oder? >
> Latürnich! Gott sei Dank hab ich auch kein WLAN… Mich regts halt
> nur auf wie die Kunden da verschaukelt werden. WEP = Wire equivalent
> Privacy? Ich lach mich tot!
>
Schon mal dem “Abhören” eines Kabel-Netzwerkes beigewohnt?
Danach geht es nur noch darum welche Lösung noch unsicher ist..ohne
entsprechende Abschirmungen, die kein Schwein in der Wirtschaft
nutzt, sind beide Lösungen nur von relativer Sicherheit.

wlanas finde ich nicht gut. Ständig kommen irgendwelche
> Security-Advices, werden neue Hack-Methoden aufgedeckt, ist ja
> schlimmer als beim IE. Man sollte diesen ganzen Standard in die Tonne
> treten und von vorne anfangen, aber diesmal richtig! Wenn in einem
> LAN ein Problem existiert kann man das noch einigermaßen durch
> physikalische Abschottung (solide Türen) und Firewalls etc. in den
> Griff kriegen, aber bei einem WLAN _muss_ der Kunde sich darauf
> verlassen können dass alles sicher ist. Es geht nicht an, dass man
> alle 6 Monate eine Sicherheitsfirma anheuern muss um sein WLAN von
> außen prüfen zu lassen!
>
> Linux_Inside
Das ist kein Problem von WLAN, sondern eines schlampigen Herstellers.
Das bedeutet nicht, das Dinge wie WEP nicht auch ursächlich aus
Schlamperei so spezifiziert sind, wie sie es nun einmal sind. Nun
aber imkonkreten Fall zu sagen, da hat ein AP Hersteller gefuscht,
also wird WLAN immer unsicherer, das ist in etwa so, als würde man
sagen: Ein neuer Outlook Virus - der Sicherheitsstandard bei allen PC
Betriebssystemen verkommt immer mehr …
Im übrigen sollte jedem, der WLAN ausserhalb des reinen Privat
Bereichs einsetzt, klar sein, das dies komplett ausserhalb der
Firewall gehört und Traffic auf dem WLAN im Prinzip zu behandeln ist,
wie ganz normaler Internet traffic (das sollte sich eigentlich auch
der Privatanwender klar machen)! Das ist nun einmal die einzig
mögliche Konsequenz daraus, das der Standard schon prinzipbedingt
unsicher ist.

wlan> > > Danach als root anmelden, und zum Test im root-Verzeichnis folgenden
> > > Befehl eingeben:
> > >
> > > rm * -rf
> >
> > Und damit disqualifiziert man sich selbst, wenn man nicht mal weiß,
> > dass Optionen *vor* die Argumente gehören.
>
> Da stellt sich nicht die Frage, wer sich gerade disqualifiziert hat.
Die Frage kannst Du Dir leicht selbst beantworten:
$ rm –version
rm (GNU coreutils) 5.96
…
$ rm –help
Usage: rm [OPTION]… FILE…
Remove (unlink) the FILE(s).
…
Die Man-Pages lassen auch nichts anderes zu als die Angabe der
Optionen *vor* den Files/Directories als Argumente.
Ich bin gerade auf der Suche nach den “Änderungen”, denn “rm”
verarbeitet die Argumente mit getopt wie so viele andere Programme
auch und das erste Argument das nicht wie eine Option aussieht
beendet das Parsing nach Optionen, wäre ja ansonsten
Zeitverschwendung.
der bit-popler

> Die Frage habe ich schon beantwortet, was Du hättest erlesen können.
Anderer Thread - war eine andere zeitlich Abfolge > Bei dem Beispiel ist eine Reihenfolge angegeben, da eine Reihenfolge
> gewählt werden muss. Die Reihenfolge empfinde ich auch als schöner,
> ist aber nicht nötig.
Es ist nicht nur eine Reihenfolge die man wählen *kann*, die
Reihenfolge von Optionen und weiteren Argumenten ist seit langer Zeit
bei Unix-Kommandos vorgegeben.
Wenn Du meinst, dass das eine *optionale* Reihenfolge ist, dann
kannst Du mir sicher eine Stelle nennen, die den Kommandoaufruf so
spezifiziert, dass Optionen und andere Argumente wechselweise in
anderer Reihenfolge auftreten dürfen.
Das kurz aufgelistete ist kein “Beispiel” sondern die offizielle
Hilfe von “rm”, ich kann Dir auch gerne die man-page hier rein
kopieren.
Wenn ein Kommando somit von der offiziell vorgegebenen Syntax für die
Anwendung abweicht, so ist das nicht nur ein Schönheitsfehler,
sondern kann extreme Seiteneffekte nach sich ziehen.
Ein Beispiel:
Jemand will im aktuellen Verzeichnis alle seine Dateien löschen, es
sind eine Unmenge Dateien mit langen Namen - aber nur mit Nachfrage,
er gibt daher an:
$ rm -i *
Was passiert normalerweise:
Er wird bei jeder Datei gefragt ob sie gelöscht werden soll, ggf.
werden die letzten Dateien weil bei der Dateinamenexpansion von “*”
der Puffer der Shell-Commandline überschritten wird nicht mehr
abgefragt, aber auch nicht gelöscht.
Was passiert bei Angabe von “rm * -i”:
Es werden alle Dateien einfach gelöscht, da bei der
Dateinamenexpansion möglicherweise die Option “-i” nicht mehr in die
Shell-Commandline passt. Die Auswertung der Dateinamensexpansion wird
von der Shell durchgeführt, während die Auswertung der Optionen von
jedem Kommando selbst gemacht wird.
Klar kann man den Commandline-Buffer-Overflow mit “find … | xargs”
häufig umgehen oder das eher ineffiziente “find … -exec … \;”
einsetzen, aber wieviele Leute die gerade mal die einfachen Befehle
kennen wenden xargs an?
Und das schlimmste Gegenbeispiel dürfte dann die Bearbeitung von
Dateien sein die auf Grund einer Commandline-Substitution - z.B.
eines Dateiinhalts - generiert werden. Wie schließt Du ausser durch
die Position dann aus, dass da nicht versehentlich Dateinamen stehen
die aber wie eine Option aussehen?
> Wenn Du also einen Poster disqualifizierst, solltest Du dich auch
> informieren.
Ja, ich gebe zu, ich bin vermutlich schon zu lange im Unix-Umfeld
tätig, da schleift sich so etwas wie eine korrekte Syntax einfach
ein.
Bei jeglicher Art von Programmiersprache und dazu gehört auch die
Shell und die Unix-Befehle *muss* eine definierte Syntax und
Auswertungsfolge vorliegen, da ansonsten die Ergebnisse nicht mehr
unbedingt deterministisch sind.
Das Ausprobieren von Kommandos und das “zufällige” Funktionieren
einer von der korrekten Syntax abweichenden Parameterfolge zähle ich
nicht zu den typischen Informationsquellen. Die Beschreibung der
Syntax in den Manuals dagegen schon.
> Ich denke, der Poster wollte einfach mal eine andere, korrekte
> Schreibweise wählen, was wohl doch für viel Verwirrung gesorgt hat.
Anscheinend ist das verwirrend, denn keines der Kommandos aus den Gnu
coreutils (oder den alten fileutils) oder gar der ursprünglichen
Unix-Kommandos sieht diese Schreibweise vor, zumindest weder in der
integrierten Hilfe, noch in den Man-Pages!
Somit: “Sorry, das ist kein gültiges Kommando!”
Das einzige was damit möglich wäre, dass ein fleissiger Entwickler
die getopt Funktion so geändert hat, dass die Optionen an beliebiger
Stelle stehen können, dies aber den Entwicklern *aller* Programme die
sich darauf abstützen nicht bekannt ist - abgesehen davon, dass es
zusätzlich Zeit kostet *alle* Argumente zu parsen ob da nicht doch
irgendwo noch eine Option dazwischen ist, statt den Anfang der
Argumente zu parsen und jede erkannte Option zu berücksichtigen und
durch einen “shift” (bzw. –argc und argv in C) aus der Liste der
Argumente zu entfernen.
der bit-popler

> > Was passiert bei Angabe von “rm * -i”:
> Jetzt hast du ja ein Beispiel für die Voranstellung der Optionen
> gefunden, wobei ich mir schon sicher sein muß, die Länge der
> Kommandozeile nicht zu Ãœberschreiten. Du hast selber auch Methoden
> aufgezählt, die das zeigen. Es geht aber nicht um den Sinn oder
> Unsinn der Reihenfolge, sondern um die Syntax.
Richtig, es geht um die Syntax.
> Und die ist richtig.
Nein, wie Du selbst an Deinem Beispiel gleich sehen wirst.
> DerThreaderöffner sollte angemacht werden
Ja, da gebe ich Dir Recht. > und das ist gelungen mit einem syntaktisch richtigem Kommando.
Hier widerspreche ich Dir.
> Die Manpage brauche ich nicht hier im gepostet.
> Da ich das Kommando auf Richtigkeit überprüfen konnte, ist
> es mir auch möglich, die man/info-page aufzurufen. “rm [OPTION]…
> DATEI…” schließt nicht aus, dass auch “rm DATEI… [OPTION]…”
> gültig ist.
Wenn
rm [OPTION]… DATEI…
die gültige Syntax darstellt, dann ist
rm DATEI… [OPTION]…
ungültig.
> Ich sehe nur, dass die Optionen optional sind und die
> Reihenfolge “rm [OPTION]… DATEI…” i.O. ist.
Korrekt, Du siehst aber nicht nur, dass die Reihenfolge “in Ordnung”
ist, sondern, dass die Reihenfolge so *definiert* ist, das ist ein
nicht zu vernachlässigender Unterschied.
> Wie dein kritisiertes Posting dir gezeigt hat gilt auch:
> “rm DATEI… [OPTION]…” und dies lässt sich auch auf allen
> Systemen nachvollziehen, die mir zu Verfügung stehen.
Nur weil etwas möglich ist, heißt das noch lange nicht, dass dies so
gewünscht ist. Würde ich Deiner Argumentation folgen, dann wäre auch
das URI-Handler-Problem bei Windows XP seit IE7 kein Problem, denn es
ist ja möglich und damit wohl so gewünscht.
Ich empfehle Dir also es auch auf einem AIX, HP-UX, Irix, Solaris,
SCO OpenServer, Ultix, Xenix oder gar Coherent nachzuvollziehen und
Du wirst feststellen, es geht dort nicht so - ausser man hat die Gnu
fileutils/coreutils nachinstalliert.
Oder schau einfach mal bei:
http://linux.die.net/man/3/getopt
Und beachte dabei den Abschnitt bei POSIXLY_CORRECT - ich hab’s mit
Standards…
der bit-popler

wlan> > Die Frage habe ich schon beantwortet, was Du hättest erlesen können.
>
> Anderer Thread - war eine andere zeitlich Abfolge >
> > Bei dem Beispiel ist eine Reihenfolge angegeben, da eine Reihenfolge
> > gewählt werden muss. Die Reihenfolge empfinde ich auch als schöner,
> > ist aber nicht nötig.
>
> Es ist nicht nur eine Reihenfolge die man wählen *kann*, die
> Reihenfolge von Optionen und weiteren Argumenten ist seit langer Zeit
> bei Unix-Kommandos vorgegeben.
>
> Wenn Du meinst, dass das eine *optionale* Reihenfolge ist, dann
> kannst Du mir sicher eine Stelle nennen, die den Kommandoaufruf so
> spezifiziert, dass Optionen und andere Argumente wechselweise in
> anderer Reihenfolge auftreten dürfen.
>
> Das kurz aufgelistete ist kein “Beispiel” sondern die offizielle
> Hilfe von “rm”, ich kann Dir auch gerne die man-page hier rein
> kopieren.
nicht nötig, lieber ein kleines Zitat von Dir hier reinposten:

> rm * -rf
Und damit disqualifiziert man sich selbst, wenn man nicht mal weiß,
dass Optionen *vor* die Argumente gehören.
Sind keine Dateien - so der Normalfall - im Verzeichnis /, so
bekommst Du da nur einen Fehler “File not found” für “*” und “-rf”

Abgesehen davon, dass vom Verzeichnis / vorher nicht die Rede war,
löscht der Befehl wohl doch eher rekursiv ohne Warnungen oder
Nachfragen auszugeben. (Sofern nicht zufällig noch eine Datei namens
“–” irgendwo da rumliegt.)
> Wenn ein Kommando somit von der offiziell vorgegebenen Syntax für die
> Anwendung abweicht, so ist das nicht nur ein Schönheitsfehler,
> sondern kann extreme Seiteneffekte nach sich ziehen.
In einer Beschreibung, wie man das WLAN zum Laufen bekommt, ist das
Kommando “rm * -rf” sowieso bösartig.
Ich habe noch nicht gehört, dass sich Malware gerne an Standards oder
Konventionen hält. Im Gegenteil: Gerne wird dagegen verstossen,
wenn’s denn trotzdem funktioniert.
Er hätte natürlich auch schreiben können: rm –enable-lan –option /
-rf (wobei ich das jetzt nicht getestet habe und auch niemandem
empfehlen würde, obiges irgendwo einzugeben … )
> Ein Beispiel:
>
> Jemand will im aktuellen Verzeichnis alle seine Dateien löschen, es
> sind eine Unmenge Dateien mit langen Namen - aber nur mit Nachfrage,
> er gibt daher an:
> $ rm -i *
>
> Was passiert normalerweise:
> Er wird bei jeder Datei gefragt ob sie gelöscht werden soll, ggf.
> werden die letzten Dateien weil bei der Dateinamenexpansion von “*”
> der Puffer der Shell-Commandline überschritten wird nicht mehr
> abgefragt, aber auch nicht gelöscht.
>
> Was passiert bei Angabe von “rm * -i”:
> Es werden alle Dateien einfach gelöscht, da bei der
> Dateinamenexpansion möglicherweise die Option “-i” nicht mehr in die
> Shell-Commandline passt. Die Auswertung der Dateinamensexpansion wird
> von der Shell durchgeführt, während die Auswertung der Optionen von
> jedem Kommando selbst gemacht wird.
# ls /*/*/*
-bash: /bin/ls: Argument list too long
bei mir wird nichts ausgeführt, wenn die Argumentliste zu lang ist.
Vermutlich genau aus demselben Grund. Man macht lieber nichts und
schmeisst ne Fehlermeldung raus, als die Hälfte möglicherweise falsch
zu tun.
> Und das schlimmste Gegenbeispiel dürfte dann die Bearbeitung von
> Dateien sein die auf Grund einer Commandline-Substitution - z.B.
> eines Dateiinhalts - generiert werden. Wie schließt Du ausser durch
> die Position dann aus, dass da nicht versehentlich Dateinamen stehen
> die aber wie eine Option aussehen?
Wobei es Dir in solchen Fällen nicht hilft, alle Optionen vor den
Argumenten zu schreiben. Einzig ein “–” hilft Dir in solchen Fällen,
und das ist auch die offizielle Empfehlung.
> Das Ausprobieren von Kommandos und das “zufällige” Funktionieren
> einer von der korrekten Syntax abweichenden Parameterfolge zähle ich
> nicht zu den typischen Informationsquellen. Die Beschreibung der
> Syntax in den Manuals dagegen schon.
wobei wie gesagt Leute mit schlechten Absichten sich nicht nach
irgendwelchen offiziellen Vorgaben richten werden
> > Ich denke, der Poster wollte einfach mal eine andere, korrekte
> > Schreibweise wählen, was wohl doch für viel Verwirrung gesorgt hat.
>
> Anscheinend ist das verwirrend, denn keines der Kommandos aus den Gnu
> coreutils (oder den alten fileutils) oder gar der ursprünglichen
> Unix-Kommandos sieht diese Schreibweise vor, zumindest weder in der
> integrierten Hilfe, noch in den Man-Pages!
> Somit: “Sorry, das ist kein gültiges Kommando!”
Sorry, irgendwo in den Dokumentationen wird das spezielle Verhalten
der gnu-utilities und wie man es abschaltet wohl dokumentiert sein.
Es wäre extrem bescheuert, dieses spezielle Verhalten in jeder
Manpage aufzuführen.
Erstens sind die Manpages nicht eine Beschreibung bis ins letzte
Detail, das wäre der Quellcode.
Zweitens kann jeder, der die Manpage gelesen und verstanden hat, rm
bzw. andere Utilities umfassend benutzen und wenn man eine bestimmte
Funktionsweise wissen will, findet man die in der Manpage.
Drittens würde die Manpage nur unnötig kompliziert.
Viertens wäre es ein schlechter Programmier- bzw. Arbeitsstil, wenn
man sich darauf verlässt, dass Optionen hinter Argumenten nicht
beachtet werden. Dadurch würden sich in extremen Situationen auch
Fehler in Scripte bzw. Arbeitsweisen einschleichen, auch wenn rm
selbst Optionen hinter Dateinamen ignorierte.

>
> > Schon mal dem “Abhören” eines Kabel-Netzwerkes beigewohnt?
> > Danach geht es nur noch darum welche Lösung noch unsicher ist..ohne
> > entsprechende Abschirmungen, die kein Schwein in der Wirtschaft
> > nutzt, sind beide Lösungen nur von relativer Sicherheit.
>
> Ja, ich habe schon oft auch selbst mit Sniffern usw. in Netzwerken
> gearbeitet, jedoch zugegebenermaßen immer nur zur Fehlersuche, nie
> zum Schnüffeln. Der Unterschied zwischen WEP und einem Kabel ist dass
> du erst mal in die Firma reinkommen mußt. Und da gibt es Pförtner,
> Sicherheitsschleusen, am Switch deaktivierte Ports usw. die dir im
> Wege stehen. Solltest du das “Abhören” auf ein echtes, induktives
> abhören des Netzwerk-Kabels aus einer Entfernung von x Metern
> Entfernung beziehen: das will ich sehen! Dann doch lieber gleich die
> Röhrenmonitore abgreifen, das ist einfacher…
>
Ich meine echtes Abhören ohne direkten Zugriff…nie beim Bund
gewesen

> Hallo
>
> > Was nützt ein AcessPoint wenn die Endgeräte WLAN nicht unterstützen?
> Das Gerät unterstützt einen Station Mode.
> “Der Station Mode ist gedacht, Geräte ohne eingebaute Wireless-Karte
> anzubinden, wie z.B. Spielekonsolen.”
>
> PC -> kurzes Lan-Kabel -> MOD Longshine -> ich bin im W-Lan
>
> zumindest habe ich es so verstanden
>
Jep, hast richtig verstanden.
Man muss dann nur noch die LAN-Karte am PC ins WLAN-Netz
konfigurieren, Longshine-Teil bekommt eine eigene IP aus dem
WLAN-Netz.
Beschissen an dem Teil ist nur die Beschreibung - offensichtlich eine
Babelfish-Ãœbersetzung aus Chinesischem So habe ich das Teil am ANfang dummerweise in Client-Modus
umgeschaltet (gibt’s so ein HW-Schalter dafür), das ist jedoch f.
Ad-hoc Modus. Als WLAN-Karte suzusagen lässt es sich nur im AP-Modus
konfigurieren.
Aber Terminologie in dem Bereich ist idT exterm verwirrend.
MfG
COPOKA.