Speicher --- Job YS

Anmeldungsdatum: 31.01.2005 Beiträge: 115 Wohnort: München

Liebe Moderatoren,

wenn ich Stuss rede --- ignoriert mich einfach...

Meine Fragen:

* Kann man aus der Job-ID auf die dahinterliegende Funktion schliessen?
* Wenn ja, was macht der Job "YS"

Hintergrund:

Ich hatte gerade mal wieder (vermutlich) ein Speicherproblem, das dazu führte, daß ein SSH-Login nicht möglich war. Es waren nur 330KB verfügbar, davon der größte Block 161KB. Nach einem Reboot waren 1.4 MB verfügbar, davon der größte Block 1.3 MB.

Ich hab' daraufhin alle möglichen SHOW-Befehle abgesetzt und den Output verglichen (bin ein alter AWK-Hacker). Aus meiner Sicht auffällig: Der Job YS hat vor dem Reboot 24 Heap-Segmente der Größe 0x8200 belegt, nach Reboot nur noch eines mit 0x8200 und zwei ganz kleine. Die übrigen (zahlreichen) Unterschiede sollten wegen der geringen Segmentgröße nicht so ins Gewicht fallen.

Die Stack-Usage war vor und nach Reboot gering. Hier die Zeilen aus SHOW JOB:

Code:

|------------|------|-----------|------|---------------|------------|--------|
| | | | | Stack | | |
| Job@ | ID | State | Prio | Free/Size Prc | File | Load |
|------------|------|-----------|------|---------------|------------|--------|
... während Speichermangel
| 0x0068ae3c | YS | WAITMSG | 0008 | 0f2c/1000 94% | 0x00476384 | 0.00% |
... nach Reboot
| 0x0068ae3c | YS | WAITMSG | 0008 | 0f34/1000 95% | 0x00476384 | 0.00% |

Wenn man nun wüßte, was YS macht ... dann könnte man diese Funktion vielleicht meiden.

Viele Grüße,
Andreas

P.S. Ich weiß, daß Ihr das auch ohne meine schlauen Fragen im Griff habt. Ich werd auch ganz brav auf die 6.10 warten und möchte auch keine Reverse-Engineering-Kampagne ins Leben rufen. Ich muß aber zugeben, daß die Remote-Zugriffsprobleme mich keksen...

Moderator Anmeldungsdatum: 07.11.2004 Beiträge: 4500 Wohnort: Aachen

Hi,

YS ist der SSH-Server, und der 32K-Block ist ein Block, der pro SSH-Session
benötigt wird. Da Du von Remote-Administration gesprochen hast, wäre meine
persönliche Vermutung, daß Du da Besuch von einigen Leuten hast, die per
SSH auf das Gerät zu kommen versuchen, und die Verbindung offen halten,
ohne irgendetwas zu tun - der SSH-Server im LANCOM wartet dann brav auf
das nächste (Handshake-)Paket.

Wirklich tun kann man gegen so etwas m.E. nicht, außer vielleicht mit Realtime-
Blacklisting, weil alle 'statischen' Abwehrmethoden auch dazu führen können,
daß DoS-Attacken möglich sind.

Ich könnte für die 6.10 schauen, ob ich wirklich 32K Stack pro Verbindung brauche,
aber wenn der Speicher knapp ist, hilft das ohnehin wenig, weil SSH pro Verbindung
noch einmal recht große FIFOs (>200K) braucht - der 32K-Block ist dann das
kleinste Problem. Die werden zum Glück aber erst angelegt, wenn die SSH-Authentifizierung
durch ist und die Datenphase beginnt, sonst müßtest Du da einen Haufen Blöcke
der Größe 64..256K sehen.

Das probateste Mittel wird vermutlich sein, in der 6.10 SSH auf einen anderen Port
zu verschieben. Für die 6.0 wäre vielleicht eine Lösung, SSH vom WAN her zu
sperren und stattdessen mit Telnet/SSL zu arbeiten - das ist schon recht obskur,
daß da selten jemand etwas probiert. SSL-fähige Telnet-Clients sind aber recht
selten, ich kennen sie bisher nur unter Linux.

Gruß Alfred

Anmeldungsdatum: 31.01.2005 Beiträge: 115 Wohnort: München

Hi zurück,

alf29 hat folgendes geschrieben:

..., wäre meine persönliche Vermutung, daß Du da Besuch von einigen Leuten hast, ...

Die Welt ist schlecht --- Grummel --- Alles Schweine außer Mutti !

Du hast vermutlich recht. Wir hatten auch schon auf unserer UNIX-Büchse Probleme mit Würmern, die brute-force versuchen Accounts mit trivialen Passwörtern zu finden. Prüfen läßt sich das jetzt natürlich nicht so auf Anhieb, weil ich das eingebaute DSL-Modem nutze und sich der WAN-seitige Verkehr vor dem "interne-Dienste-Abzweig" nicht tracen läßt, richtig?

Ich werd mich erstmal heute mit Telnet/SSL beschäftigen Confused

Mal sehen, ob ich den Windows-Telnet mit dem sslclient aus openssl verkuppelt bekomme, Igitt

Schönes WE,
Andreas

Moderator Anmeldungsdatum: 07.11.2004 Beiträge: 4500 Wohnort: Aachen

Hallo Andreas,

Zitat:

Prüfen läßt sich das jetzt natürlich nicht so auf Anhieb, weil ich das eingebaute DSL-Modem nutze und sich der WAN-seitige Verkehr vor dem "interne-Dienste-Abzweig" nicht tracen läßt, richtig?

Theoretisch sollten im Syslog irgendwelche Login-Errors
stehen. interessant ist nur, daß wenn da jemand
Paßwörter probiert, er es offensichtlich so langsam
macht, daß die Login-Sperre nicht zuschlägt...

Zitat:

Ich werd mich erstmal heute mit Telnet/SSL beschäftigen Confused Mal sehen, ob ich den Windows-Telnet mit dem sslclient aus openssl verkuppelt bekomme, Igitt

unter Linux geht das mit einem SSL-fähigen Telnet
zumindest so:

telnet -z ssl <IP-Adresse> telnets

Gruß Alfred

Anmeldungsdatum: 31.01.2005 Beiträge: 115 Wohnort: München

Hallo Alfred,

ich ahne inzwischen, was das passiert ist...

Ich prüfe inzwischen regelmäßig, wieviele 0x8200 Segmente der YS auf dem Heap liegen hat. Die Anzahl wächst immer dann an, wenn ich mal wieder mit dem AVPN-Client aus dem LAN/WLAN arbeite. Durch die Link-Firewall ("nur Kommunikation im Tunnel erlauben") werden eventuell bestehende PuTTY-Sessions recht unsanft beendet. Unter 6.04 verschwanden die Heap-Segmente dieser Sessions irgendwie nie (bis zum Reboot).

Just in der Zeit, als ich öfter mal Speicherprobleme hatte, hab ich relativ oft Sessions "auf die harte Tour" abbrechen lassen.

Unter 6.06 scheint sich das jetzt irgendwie geändert zu haben. Die Segmente sind nach einigen Minuten weg. Habt Ihr da was an der Speicherverwaltung geändert?

Viele Grüße,
Andreas

Moderator Anmeldungsdatum: 07.11.2004 Beiträge: 4500 Wohnort: Aachen

Moin,

Zitat:

Unter 6.06 scheint sich das jetzt irgendwie geändert zu haben. Die Segmente sind nach einigen Minuten weg. Habt Ihr da was an der Speicherverwaltung geändert?

An der Speicherverwaltung weniger (die tut ja nur, was ihr andere sagen), eher im TCP,
auf dem SSH ja aufsetzt - da sind m.W. einige Bugfixes reingegangen. Vermutlich
bekommt der SSH-Server jetzt mit, daß die unterliegende TCP-Verbindung tot ist und
räumt daraufhin die dazugehörenden Strukturen ab.

Gruß Alfred