Non-blocking I/O in SSH-session

Dieses Thema im Forum "C/C++" wurde erstellt von der_Kay, 17.05.2007.

  1. #1 der_Kay, 17.05.2007
    Zuletzt bearbeitet: 17.05.2007
    der_Kay

    der_Kay Doppel-As

    Dabei seit:
    28.02.2006
    Beiträge:
    140
    Zustimmungen:
    0
    Hallo zusammen,

    Ist es möglich zu verhindern, daß SSH das O_NONBLOCK flag auf fd1 löscht?

    Das folgende kleine, ordentlich funktionierende Programm startet eine SSH-Session via popen(), liest den Output byteweise aus der Pipe und schreibt ihn nach stdout.

    Code:
    #include <stdio.h>
    #include <stdlib.h>
    #include <ctype.h>
    #include <unistd.h>
    
    int main (int argc, char** argv)
    {
    	int c; 
    	
    	FILE* pfile; 
    
    	pfile = popen ("ssh me@mainframe", "r");
    
    	do
    	{
    		c = fgetc(pfile);
    		printf("%c", c);
    		fflush ( stdout );	
    	}
    	while ( c != EOF );
    
    	return 0;
    }
    
    
    Vor dem printf() will ich bestimmte Steuerzeichenfolgen aus der Pipe aussondern. Das ließe sich bei byteweiser Verarbeitung durch zwar einen Zustandsautomaten lösen, aber wesentlich eleganter wäre es nicht-blockierenden IO einzuschalten, den Output in größeren Blöcken zu lesen und die gesamten Byteketten zu suchen. Unglücklicherweise löscht SSH aber die O_NONBLOCK flags aller Ein- und Ausgabeströme, so daß ein fcntl ( pfile, F_SETFL, O_NONBLOCK ) wirkungslos bleibt und poll() bzw. select() nicht laufen. Was kann man da machen?

    Ich weiß, daß sich das nach "man in the middle"-Attacke anhört und deshalb beschreibe ich kurz, wozu diese Maßnahme dienen soll: Wir betreiben einige uralte Netzwerk-Terminals mit eingebauter serieller Schnittstelle, an der ein Industriebarcodedrucker hängt. Wenn ein Barcode gedruckt werden soll, sendet der Mainframe eine "magische" Bytesequenz, die den nachfolgenden Traffic auf die serielle Schnittstelle umleitet und der Barcode gedruckt wird. Eine weitere Sequenz leitet die folgenden Bytes wieder zurück auf den Bildschirm, so daß die Angestellten weiterarbeiten können. Wir wollen diese düsteren alten Geräte gegen Linuxboxen tauschen, aber die Terminalemulation kann mit den magischen Bytesequenzen nichts anfangen und druckt sie zusammen mit den übrigen ASCII-Zeichen aus. Das gibt Zeichensalat im Terminal und die SSH-Session bricht zusammen, ganz zu schweigen davon, daß so keine Barcodes gedruckt werden. Nun will ich einfach die Steuerbytes herausfischen und den Folgetraffic manuell auf der seriellen Schnittstelle ausgeben.

    Im Netz habe ich zu diesem Thema rein gar nichts gefunden. ?( Vorab vielen Dank fürs Lesen und Grüße

    Kay
     
  2. Anzeige

    Schau dir mal diese Kategorie an. Dort findest du bestimmt etwas.
    Registrieren bzw. einloggen, um diese und auch andere Anzeigen zu deaktivieren
  3. tr0nix

    tr0nix der-mit-dem-tux-tanzt

    Dabei seit:
    11.07.2003
    Beiträge:
    1.585
    Zustimmungen:
    0
    Ort:
    Schweiz, Opfikon/Glattbrugg
    Hast du das ganze mal mit rsh probiert? SSH hatte ich auch schon Probleme wenn ich es nicht von einer Shell aus ausführte, meistens hatte dies aber mit einer Pseudo-TTY zu tun, k.A. ob das mit deinem Problem verwandt sein könnte.
     
  4. #3 der_Kay, 26.05.2007
    der_Kay

    der_Kay Doppel-As

    Dabei seit:
    28.02.2006
    Beiträge:
    140
    Zustimmungen:
    0
    Danke für die Antwort, doch leider ist mir mit rsh nicht geholfen. Wenn man ssh mit -vv startet, schreibt ssh explizit in stderr, dass beim Start der Shell O_NONBLOCK gelöscht wird.

    Ich müsste wissen, wie man ssh dieses Verhalten austreibt, ohne es zu patchen. Es scheint mir allerdings so, dass das nicht möglich zu sein scheint. Daher habe ich mittlerweile byteweises Parsen implementiert.
     
Thema:

Non-blocking I/O in SSH-session

Die Seite wird geladen...

Non-blocking I/O in SSH-session - Ähnliche Themen

  1. SSH-session nach restart weiter aktiv

    SSH-session nach restart weiter aktiv: Moin, ich verwalte ein gentoo-System ausschließlich per SSH. Nun habe ich heute in den configs von SSH den Port verändert und danach SSHD...