trace blockiert meinen lancom

[missunderstood]

hallo zusammen,

ich habe soeben mal auf meinem l54g den befehl:
trace + wlan-data
via putty eingegeben.

danach ist meine session abgebrochen und nun komme ich nicht mehr auf den l54g drauf.
wie kann ich denn jetzt den trace beenden ?
via ssh komme ich mit keinem angelegten benutzer mehr drauf.
benutzername und passwort werden noch abgefragt, dann passiert gar nichts mehr.

auf die webconfig komme ich noch drauf und auch das lanconfig gehen noch.

auf meine kaltstart-anforderung reagiert der lancom gar nicht...

was kann ich denn nun tun ?

lg

missi

[backslash]

Hi missunderstood

ich habe soeben mal auf meinem l54g den befehl:
trace + wlan-data
via putty eingegeben.

danach ist meine session abgebrochen und nun komme ich nicht mehr auf den l54g drauf.

du warst doch hoffentlich dabei nicht über WLAN auf dem Geräte, oder?
Wenn doch, dann ist klar, warum nichts mehr geht... Du "sägst an dem Ast auf dem du sitzt" (jeder Trace erzeugt sofort einen neuen Terace, der wieder einen Trace...)

auf meine kaltstart-anforderung reagiert der lancom gar nicht...

funktioniert denn ein normaler Boot?

was kann ich denn nun tun ?

Den Stecker ziehen - oder einfach warten, bis die tracende Session von selbst terminiert (ca. 10 Minuten)

Gruß
Backslash

[missunderstood]

Hi backslash,

nee über wlan war ich nicht verbunden. *g*
der ap steht an einem anderen standort wo ich leider den stecker nicht ziehen kann.
normaler boot geht auch nicht.
und leider sind jetzt viel mehr als 10 minuten vergangen und der l54g mag mich immer noch nicht via ssh rein lassen

login as: root
root@217.243.xxx.xxx's password:


und dort bleibt dann das fenster stehen.
wenn ich mal zum spass ein falsches passwort eingebe kommt: Access denied.

Also funktioniert das Gerät und auch wieder nicht ...


hm...
über die websitzung kann ich mir da die laufenden traces anschauen lassen oder gibts das nur über ssh ?

vielen dank ...

lg

missi

[rbreuer]

Hallo,

ich kann mich auch nicht von -ix Systemen per ssh am Lancom-Router anmelden. Genau nach der Eingabe des (richtigen) Passwortes friert das Fenster ein. Ein falsches Passwort wird dagegen korrekt abgelehnt.

Per putty von Windows-Rechnern aus geht alles wie erwartet.

Vielleicht hat das Ganze nichts mit dem ursprünglichen Trace zu tun?

Gruß, Rolf

[alf29]

Moin,

ich kann mich auch nicht von -ix Systemen per ssh am Lancom-Router anmelden. Genau nach der Eingabe des (richtigen) Passwortes friert das Fenster ein. Ein falsches Passwort wird dagegen korrekt abgelehnt.

also ich kann mich von Linux-Rechnern aus problemlos per OpenSSH auf einem LANCOM
anmelden. Vielleicht machst Du mal ein 'ssh -v' auf dem Unix-Rechner.

Gruß Alfred

[missunderstood]

ich geh aber via putty von einem xp rechner genauso drauf wie ich auch den trace gestartet habe...
mich wundert nur dass der lancom via webconfig die kaltstart-anweisung ignoriert...

lg

missi

[alf29]

Moin,

es ist denkbar, daß aufgrund des unsauberen Abbruchs der ersten SSH-Session
ein bestimmter Task blockiert ist, der die ganzen CLI-Sessions verwaltet - und
in dem würde auch die Abarbeitung eines Reboot laufen...

Mal ganz am Rande gefragt: was wolltest Du eigentlich tracen?

Gruß Alfred

[missunderstood]

hallo alfred,

wollte den wlan verkehr eines clients mal 1 stunde mitlaufen lassen.

angeblich fliegt der client alle paar minuten raus und muss sich neu am radius anmelden. hatte auch brav vorher die zu tracende mac eingetragen um den traffic zu verringern...

komisch, hatte ich schon ein paar mal auf verschiedenen geräten gemacht ohne probleme.

hm....

ich könnt jetzt heute nacht nur noch probieren datum und uhrzeit zu verändern, da ein cronjob existiert, der den ap am 01. des monats um 00:01 neu startet, vielleicht funktioniert ja das noch und ich krieg den ap so neu gestartet. bisher ist ja noch nichts passiert, keine probleme des netzes.

lg

missi

[rbreuer]

Moin Alfred,

mit folgenden Systemen funktioniert bei mir ssh zu einem 1811er mit Firmware 7.52 nicht:

OpenSSH_4.7p1 Debian-9, OpenSSL 0.9.8g 19 Oct 2007

OpenSSH_4.7p1 Debian-2.maemo2, OpenSSL 0.9.7e 25 Oct 2004

OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006

Gruß, Rolf

[alf29]

Moin,

angeblich fliegt der client alle paar minuten raus und muss sich neu am radius anmelden. hatte auch brav vorher die zu tracende mac eingetragen um den traffic zu verringern...

Mit einem Argument am Trace-Kommando oder mit dem Menüpunkt
unter Setup->WLAN? Nur letzteres verringert das Aufkommen an
Trace-Meldungen im Gerät wirklich, das andere ist nur ein Ausgabefilter...

Gruß Alfred

[missunderstood]

ja unter setup - wlan - trace-mac

lg

missi

[alf29]

Moin,

mit folgenden Systemen funktioniert bei mir ssh zu einem 1811er mit Firmware 7.52 nicht:

Bei mir funktioniert es damit:

OpenSSH_4.3p2 Debian-9, OpenSSL 0.9.8c 05 Sep 2006

Also setzt Du irgendeine testing ein, die habe ich hier nicht zur
Verfügung und ich werde mir damit im Augenblick auch keinen
meiner Arbeitsrechner potentiell verhunzen. Bitte mache den ssh-Aufruf
mit -v, wie ich Dir schrieb, dann sieht man eventuell, was los ist.

Gruß Alfred

[rbreuer]

Moin Alfred,

Also setzt Du irgendeine testing ein, ... und ich werde mir damit im Augenblick auch keinen meiner Arbeitsrechner potentiell verhunzen

Zumindest für Mac OS X Tiger würde ich das so nicht gelten lassen
Ich habe aber verstanden, dass es da Versionsabhängigkeiten gibt, und hatte mich überhaupt nur zu Wort gemeldet, weil das Symptom (Aufhängen nach Passwort) gleich ist. Nachdem missunderstood aber vor und nach dem Trace putty verwendet, werde ich diesen Thread nicht länger zweckentfremden.

Gruß, Rolf

[missunderstood]

danke

[alf29]

Moin,

Zumindest für Mac OS X Tiger würde ich das so nicht gelten lassen

Ich bezog mich auf die Debian-Varianten. Einen Mac habe ich überhaupt
nicht zur Verfügung...

Ich habe aber verstanden, dass es da Versionsabhängigkeiten gibt, und hatte mich überhaupt nur zu Wort gemeldet, weil das Symptom (Aufhängen nach Passwort) gleich ist. Nachdem missunderstood aber vor und nach dem Trace putty verwendet, werde ich diesen Thread nicht länger zweckentfremden.

Dafür reißt Dir keiner den Kopf ab, ich möchte ja auch gerne wissen, woran es
liegt. Einen ersten Ansatz könnte ein Trace auf der Seite des SSH-Clients
liefern, den man eben mit '-v' einschaltet. Bei mir sieht das z.B. so aus:

Code: Alles auswählen

OpenSSH_4.3p2 Debian-9, OpenSSL 0.9.8c 05 Sep 2006
debug1: Reading configuration data /home/alfred/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to 192.168.11.101 [192.168.11.101] port 22.
debug1: Connection established.
debug1: identity file /home/alfred/.ssh/id_dsa type 2
debug1: identity file /home/alfred/.ssh/id_rsa type 1
debug1: Remote protocol version 2.0, remote software version lancom
debug1: no match: lancom
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-9
debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
A parameter was malformed
Validation error

debug1: An invalid name was supplied
Cannot determine realm for numeric host address

debug1: An invalid name was supplied
A parameter was malformed
Validation error

debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Host '192.168.11.101' is known and matches the RSA host key.
debug1: Found key in /home/alfred/.ssh/known_hosts:62
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: password,publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/alfred/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 434
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.

Da das ganze bei Dir bis einschließlich zur Paßwortabfrage einwandfrei
durchläuft, muß es irgendwo hinter der Authentifizierung klemmen...

Gruß Alfred