1823 VoIP: trace + all

[Atom 2]

Hallo Forum,
ich versuche auf einem LANCOM 1823 VoIP den Befehl "trace + all" in einer ssh Verbindung (angemeldet als root) einzugeben, erhalte aber als Fehlermeldung ein "Syntax Error: all".

Laut LCOS Reference Manual, Release 7.5x (das korrespondiert auch mit jener Release, die ich verwende: 7.58.0045), Seite 118, sollen damit folgendes passieren: "schaltet alle Trace-Ausgaben ein".

Hintergrund: Ich versuche von der Ferne mit LanConfig auf den Router zuzugreifen und erhalte nur den Gerätestatus "HTTP-Fehler". Über einen Trace möchte ich daher herausfinden, woran das möglicherweise liegen kann. Da ich nicht weiß, welcher "Kanal" dafür geeignet ist, war meine Idee, alle trace-Kanäle einzuschalten und auf Fehler zu achten.

Habe ich etwas übersehen oder funktioniert der trace Befehl (entgegen derm Handbuch) so tatsächlich nicht?

LG aus Wien,

Klaus

P.S. vor und nach dem "+" ist natürlich ein Leerzeichen eingefügt.

[alf29]

Moin,

an dem Trace-Kommando ist während der 7.5x-Entwicklung einiges umgebaut worden, seitdem
ist das Argument 'all' nur noch zum Abschalten aller Traces zulässig (also 'trace - all'). Das
Handbuch ist da wohl noch nicht auf dem aktuellen Stand.

Besonders sinnig ist es nicht, alle Traces anzuschalten, denn dann kommen derartig viele Ausgaben,
daß dem Gerät nach wenigen Sekunden bis Sekundenbruchteilen der Speicher ausgeht. Im besten
Fall wird der Trace dann gleich wieder ausgeschaltet, im schlimmsten Fall stürzt das Gerät ab,
weil irgendein anderer Dienst keinen Speicher mehr bekommen hat. Worauf man beim Tracing
auch immer achten muß, ist daß man damit keinen Elektronenbeschleuniger erzeugt. Schaltet
man z.B. den Ethernet-Trace ein und ist selber übers LAN auf dem Gerät eingeloggt, so erzeugen
die Trace-Ausgaben Pakete in der Telnet/SSH-Sitzung, damit Verkehr auf dem Ethernet, die wieder
Trace-Ausgaben erzeugen, die dann wieder Pakete erzeugen usw usf....

Da es keinen speziellen Trace des Web-Servers im LANCOM gibt, ist ein Ethernet-Trace aber
schon der richtige Ansatz (bzw. ein WLAN-Data-Trace, wenn das LANconfig übers WLAN auf
das Gerät zugreift). Es ist dabei nur zwingend notwendig, den Trace mit Hilfe eines Filters
einzuschränken, so daß man nicht wie oben beschrieben seine eigenen Pakete miterwischt:

Code: Alles auswählen

trace + eth @ http

schränkt die Ausgabe auf die Pakete ein, die zu HTTP(S)-Verbindungen gehören. Es ist
übrigend eine gute Idee, das per SSH und nicht per Telnet zu machen - bei Telnet laufen
die Daten ja im Klartext, so daß in den Paketen und damit den Trace-Ausgaben irgendwo
der Text 'HTTP' auftaucht, und man hat doch wieder so einen Elektronenbeschleuniger.

Bei HTTPS wirst Du damit aber nicht viel Informationen gewinnen, weil ja alles verschlüsselt
läuft...

Gruß Alfred

[Atom 2]

Alfred,
Danke für die schnelle Antwort. Das hat jetzt mal (wie erwartet) so funktioniert und hat mich (indirekt) auch auf die Lösung des Problems gebracht: Im trace war nämlich genau *nichts* zu sehen. Also muß(te) dasProblem woanders liegen.

Nächster Schritt: UMTS Verbindung vom PC aufgebaut - ging problemlos, aus dem LAN ging es nicht. Internetzugriffe gingen aber (auch) aus dem LAN ohne Probleme.

Nach einigen Versuchen dann die Lösung - und die ist für mich durchaus überraschend:
Das Problem war die Proxy Einstellung im Internet Explorer (IE) unter Windows XP. Ich browse normalerweise mit dem Firefox und der hatte keinen Proxy eingestellt - Browsen hat daher auch wunderbar funktioniert. Im IE war aber fälschlicherweise (noch) ein Proxy eingestellt und dessen Werte konsultiert und verwendet LANconfig offenbar beim Zugriff über https.

Ist nehme aber an, das ist so ein gewünschtes Verhalten von LANconfig? Wäre vielleicht eine kurze Notiz im Handbuch wert, daß LANconfig die Proxy-Einstellungen des IE verwendet?

Nochmals Danke und LG aus Wien,

Klaus


P.S. Warum es mit UMTS ohne Umstellung des Proxy ging: Meine Vermutung ist, daß bei UMTS Zugriff ganz einfach alle Proxy Einstellungen ignoriert bzw. übersteuert werden. Von wem/welchem Stück Software weiß ich allerdings nicht.

[alf29]

Moin,

Nach einigen Versuchen dann die Lösung - und die ist für mich durchaus überraschend:
Das Problem war die Proxy Einstellung im Internet Explorer (IE) unter Windows XP. Ich browse normalerweise mit dem Firefox und der hatte keinen Proxy eingestellt - Browsen hat daher auch wunderbar funktioniert. Im IE war aber fälschlicherweise (noch) ein Proxy eingestellt und dessen Werte konsultiert und verwendet LANconfig offenbar beim Zugriff über https.

Ist nehme aber an, das ist so ein gewünschtes Verhalten von LANconfig? Wäre vielleicht eine kurze Notiz im Handbuch wert, daß LANconfig die Proxy-Einstellungen des IE verwendet?

Soweit ich weiß, verwendet LANconfig für HTTP(S)-Zugriffe eine von Microsoft dafür vorgesehene
API-Funktion, und die ist in der Tat Teil des Internet Explorer. So etwas tun ja auch andere
Komponenten unter Windows, z.B. das Microsoft-Update.

Gruß Alfred