[Gelöst] "Connection refused" bei Blocking Call

[Jensc]

Code Auswählen Erweitern

defmod telnetPort telnet 7072 global

Yeap, das hat geholfen (aber erst, nachdem ich das alte telnet Device gelöscht hatte)!

Code Auswählen Erweitern

2019.12.08 18:38:50 5: Cmd: >{TestBlocking(3)}<
2019.12.08 18:38:50 4: BlockingCall (DoSleep): created child (6257), uses telnetPort to connect back
2019.12.08 18:38:50 4: WEB: /fhem&fw_id=139&fwcsrf=csrf_180474433264716&cmd=%7BTestBlocking%283%29%7D / RL:1783 / text/html; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate

2019.12.08 18:38:50 4: Connection accepted from telnetPort_192.168.178.56_52196
2019.12.08 18:38:50 5: Cmd: >{BlockingRegisterTelnet($cl,22)}<
2019.12.08 18:38:50 4: WEB_192.168.178.63_55564 GET /fhem?XHR=1&inform=type=status;filter=;since=1575826729;fmt=JSON&fw_id=139&timestamp=1575826730567; BUFLEN:0
2019.12.08 18:38:53 5: Cmd: >{BlockingStart('22')}<
2019.12.08 18:38:53 5: Cmd: >{SleepDone('I\'m done')}<
2019.12.08 18:38:53 1: SleepDone: I'm done


Frage: Habe ich jetzt einen offenen telnet Port auf dem Raspi, über den jeder rein kann, der im lokalen Netz ist? Das würde ich dann noch nicht als echte Lösung ansehen... Oder wie kann ich den zu machen?

[CoolTux]

Ok was mich die ganze Zeit Stutzig macht ist wieso das Telnet Device die ganze Zeit existent war. Eigentlich hätte es sich von alleine wieder löschen müssen.
Und ja aktuell hast Du ein offenes Telnet. Du kannst es aber mit einem allowed Device absichern. Schau dazu bitte in die Commandref.

Interessant für mich wäre das Verhalten ohne jegliches telnet Device. Also das neue auch wieder entfernen und schauen ob noch ein anderes da ist. Wenn ja löschen. So das keines mehr da ist. Danach dann mal testen.

[Jensc]

Wenn alle telnet Devices gelöscht wurden, zeigt er wieder das alte Verhalten: Anlegen eines temporären Devices, Ablehnen der Verbindung und das Device bleibt dann stehen.

Code Auswählen Erweitern

2019.12.08 22:58:41 5: Cmd: >{TestBlocking(3)}<
2019.12.08 22:58:41 3: telnetForBlockingFn_1575842321: port 36549 opened
2019.12.08 22:58:41 4: BlockingCall (DoSleep): created child (11226), uses telnetForBlockingFn_1575842321 to connect back
2019.12.08 22:58:41 4: WEB: /fhem&fw_id=175&fwcsrf=csrf_180474433264716&cmd=%7BTestBlocking%283%29%7D / RL:1768 / text/html; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate

2019.12.08 22:58:41 1: Connection refused from 192.168.178.56:35534
2019.12.08 22:58:41 4: WEB_192.168.178.36_57816 GET /fhem?XHR=1&inform=type=status;filter=;since=1575842320;fmt=JSON&fw_id=175&timestamp=1575842321274; BUFLEN:0
2019.12.08 22:58:46 1: Aborted: AbortArg


Und auf list TYPE=telnet:

Code Auswählen Erweitern

Internals:
   CFGFN     
   CONNECTS   3
   DEF        0
   FD         17
   FUUID      5ded7211-f33f-18f0-7d9d-87dc943887c6e30a
   NAME       telnetForBlockingFn_1575842321
   NR         180
   PORT       36549
   STATE      Initialized
   TEMPORARY  1
   TYPE       telnet
   READINGS:
     2019-12-08 22:58:41   state           Initialized
Attributes:
   allowfrom  127.0.0.1
   room       hidden
Ich werde die nächsten Tage wenig Zeit haben, es kann also ein paar Tage dauern, bis ich wieder antworte. Trotzdem wäre ich auch daran interessiert, herauszufinden, was das eigentlich zugrundeliegende Problem ist. Auch wenn das globale telnet Device dazu führt, dass das Problem nicht mehr auftritt, gehört es ja wohl nicht zur Standard-Installation, oder? Bis dahin würde ich es auch noch nicht als "gelöst" kennzeichnen.

Das allowed Device werde ich mir noch zu Gemüte führen. Erstmal Danke bis hierhin.

[CoolTux]

Ich habe nun mal eine Testinstanz installiert und bin zu folgender Erkenntnis gelangt.
Sofern man kein Telnetdevice angelegt hat wird beim aller ersten BlockingCall eines angelegt. Es wird als temporär deklariert und bleibt bis zum neustart erhalten.
Bei mir wird bei einem BlockingCall das loopback device verwendet, also 127.0.0.1.

Mach mal bei Dir bitte ein

Code Auswählen Erweitern

hostname
und

Code Auswählen Erweitern

hostname -f

Beide Ausgaben hier posten


Grüße

[CoolTux]

Du kannst auch mal schauen wie localhost aufgelöst wird.

Code Auswählen Erweitern

nslookup localhost

[Jensc]

Sieht alles eher unauffällig aus:

Code Auswählen Erweitern

pi@raspberrypi:~ $ hostname
raspberrypi
pi@raspberrypi:~ $ hostname -f
raspberrypi.fritz.box
pi@raspberrypi:~ $ nslookup localhost
Server:         192.168.178.1
Address:        192.168.178.1#53

Name:   localhost
Address: 127.0.0.1


Irgendwo wird bei mir aus dem localhost der "raspberrypi" und entsprechend aus der loopback IP die echte IP. Die Stelle habe ich aber noch nicht gefunden.

Nachtrag: Den telnet mit einem allowed Device abzusichern funktioniert übrigens nicht: In dem Moment, wo ich ein Passwort setze, macht der BlockingCall wieder sein eigenes telnet Device, das dann scheitert. Wenn man das allowed Device und das von BlockingCall angelegte telnet Device löscht, geht's wieder

[CoolTux]

Sieht in der Tat unauffällig aus.
Bin mir ziemlich sicher das es dennoch vom OS kommt.

Du sollst ja auch kein Passwort setzen sondern das Attribut allowed_from auf 127.0.0.1 und Deine eigene IP


Grüße

[Jensc]

Ja, Deinen Verdacht mit dem OS teile ich auch - leider sind mir die Ideen ausgegangen, wo ich noch suchen kann.

Wg telnet abdichten: Da hatte ich offensichtlich Deinen Post falsch verstanden. Allerdings hilft allowedfrom am telnet Device auch nicht so richtig: Es führt wieder dazu, dass sich Blocking ein eigenes telnet Device schafft Alles andere hätte mich auch ernsthaft erstaunt, wenn man sich die Stelle anschaut, wo das telnet Device im BlockingCall gesucht bzw. erzeugt wird (Ausschnitt aus Blocking.pm, ein wenig gekürzt):

Code Auswählen Erweitern

sub
BC_searchTelnet($)
{
   ...

  $BC_telnetDevice = undef;
  foreach my $d (sort keys %defs) { #
    my $h = $defs{$d};
    next if(!$h->{TYPE} || $h->{TYPE} ne "telnet" || $h->{SNAME});
    next if(AttrVal($d, "SSL", undef) ||
            AttrVal($d, "allowfrom", "127.0.0.1") ne "127.0.0.1");
    next if($h->{DEF} !~ m/^\d+( global)?$/);
    next if($h->{DEF} =~ m/IPV6/);

    my %cDev = ( SNAME=>$d, TYPE=>$h->{TYPE}, NAME=>$d.time() );
    next if(Authenticate(\%cDev, undef) == 2);    # Needs password
    $BC_telnetDevice = $d;
    last;
  }

  # If not suitable telnet device found, create a temporary one
 
  ...
}


Wenn mich meine rudimentären Perl-Kenntnisse nicht täuschen, wird da alles ignoriert, was nicht genau "127.0.0.1" als allowfrom hat, ein Passwort hat, nicht global ist, oder mit IPV6 arbeitet.

Ich überlege mittlerweile, ob ich nicht einen Änderungsantrag stelle, aus dem "ne" in "AttrVal($d, "allowfrom", "127.0.0.1") ne "127.0.0.1");" ein matches zu machen. Dann sollte genau das funktionieren, was Du vorgeschlagen hast. Wo müsste man sowas reinstellen?

[CoolTux]

Den Vorschlag kannst Du natürlich machen. Rudi wird Dich dann nach den Anwendungsgrund für diese Änderung fragen. Und ich denke wenn Du sagst weil mein System nicht richtig arbeitet wird er bestimmt absagen. Ist meine Vermutung!!!

Ich würde da wirklich lieber versuchen das System gerade zu richten oder FHEM zu sichern und das System neu auf zu setzen.

Du kannst auch mal versuchen einen neuen Hostname zu vergeben und entsprechend die /etc/hosts an zu passen und wenn noch nicht geschehen eine feste IP zu vergeben.

[Jensc]

Nachdem ich im OS nicht wirklich fündig geworden bin, habe ich mich dafür entschieden, /opt/fhem/FHEM/Blocking.pm in Zeile 51 zu patchen, nur etwas sauberer, als vorher. In dem folgenden Abschnitt

Code Auswählen Erweitern

foreach my $d (sort keys %defs) { #
    my $h = $defs{$d};
    next if(!$h->{TYPE} || $h->{TYPE} ne "telnet" || $h->{SNAME});
    next if(AttrVal($d, "SSL", undef) ||
            AttrVal($d, "allowfrom", "127.0.0.1") ne "127.0.0.1");
    next if($h->{DEF} !~ m/^\d+( global)?$/);
    next if($h->{DEF} =~ m/IPV6/);

    my %cDev = ( SNAME=>$d, TYPE=>$h->{TYPE}, NAME=>$d.time() );
    next if(Authenticate(\%cDev, undef) == 2);    # Needs password
    $BC_telnetDevice = $d;
    last;
  }


wird statt

Code Auswählen Erweitern

AttrVal($d, "allowfrom", "127.0.0.1") ne "127.0.0.1");

die Zeile

Code Auswählen Erweitern

AttrVal($d, "allowfrom", "127.0.0.1") !~ m/127.0.0.1/);
eingesetzt. Das erlaubt es, ein telnet Device mit

Code Auswählen Erweitern


define telnetPort telnet 7072
attr telnetPort allowfrom 127.0.0.1|<hostname>

zu konfigurieren, wodurch man nicht mehr auf einen offenen telnet Port angewiesen ist. <hostname> muss natürlich durch den Namen des hosts ersetzt werden, auf dem fhem läuft, also in meinem Beispiel

Code Auswählen Erweitern

attr telnetPort allowfrom 127.0.0.1|raspberrypi
Einziger Nachteil: Beim update des Systems wird einem die alte Version wieder eingespielt, d.h. man kann sich die Mühe entweder nach jedem Update machen, oder aber ein kleines sed Skript bauen, das einem die Arbeit erledigt. Und das ganze ist natürlich völlig ohne Gewähr

Wenn Dir die Lösung geholfen hat, hinterlasse hier bitte einen Kommentar. Wenn zehn Kommentare zusammen gekommen sind, stelle ich den Patch als Änderungsantrag.

[CoolTux]

Ein sed Skript ist Unsinn. MAche doch einfach direkt ein Patch File und spiele das dann halt immer wieder ein nach einem Update.

[Jensc]

Ein sed Skript ist Unsinn. MAche doch einfach direkt ein Patch File und spiele das dann halt immer wieder ein nach einem Update.

Das hat halt den Nachteil, dass man sich auch evtl. Änderungen an Blocking.pm überschreibt. Aber ich gebe Dir Recht: Ob sed, awk, perl oder Patch File kann jeder nach Belieben gestalten. Hat wohl eher was mit Geschmack und Vorlieben zu tun.

Danke Dir noch mal für Deine Hilfe!