Beiträge von CmdrXay

Hay,

Zitat von vmk

netcup wird die Email innerhalb von wenigen Sekunden an web .de los. Wenn dann müsstest du von web .de informiert werden, dass eine potentielle Email auf dich wartet.

also oben aus dem ersten Trace vom Samstag sieht es aber so aus, als ob die Mail von von 15:43 bis 22:41 auf einem Netcup Server rumgedümpelt wäre.

Oder sieht das auch so aus, wenn web.de die Mail über 7 Stunden zurückgestellt wird, z.b. durch Graylisting? In dem Fall wäre interessant im echten Log zu sehen, wann der erste Zustellversuch unternommen wurde und mit welchem Ergebnis. Wenn es NUR web.de betrifft, ist es eher wahrscheinlich, dass es ein web.de-Problem ist. Hatte ich früher mit der Telekom, da hats bis zu zwei Tage gedauert, zu anderen Zielen ging es blitzschnell.

CU, Peter

Hay,

Zitat von RHA

Das ACK ist keine Antwort per Protokoll, sondern wird Hardwareseitig auf der RS485-Schnittstelle gelöst.

Wenn es ähnlich gemacht ist wie auf der RS232, dann signalisiert das (vergleichbar RTS/CTS) das Byte-Ende und nicht das Ende des Datensatzes. Glaube ich jetzt aber nicht , denn weil EIA 485 Multipoint ist, könntest Du mit nur jeweils einer RX & TX-Leitung (bzw. bei maximal zwei Paaren) gar nicht erkennen, welche Gegenstelle gerade auf ACK gezogen hat. Selbst wenn: Wir sind hier auf verschiedenen Layern unterwegs. Wenn man es vergleichen mag bist Du gerade auf OSI-Schicht 1-2, ich bin auf 5-7.

Ich zitiere mal Wikipedia zur EIA-486:

Zitat

Im Gegensatz zu anderen Bussen sind bei EIA-485 nur die elektrischen Schnittstellenbedingungen definiert. Das Protokoll kann anwendungsspezifisch gewählt werden. Deshalb werden sich EIA-485-Geräte unterschiedlicher Applikationen oder Hersteller i. Allg. nicht verstehen.

Aber ich möchte mich da nicht weiter einmischen, dafür ist das Ganze für mich einfach 30 Jahre zu weit weg und vielleicht glaube ich auch nur, hier noch viel zu wissen ...

CU, Peter

Hay,

da gibts noch eine Steigerung: http://http//2899945699.

CU, Peter

Hay,

Zitat von mainziman

wobei andere als die Standardports (80 f. HTTP bzw. 443 f. HTTPS) sind nicht weniger gruselig

naja, wenn mehr als ein Webserver läuft, aber durchaus üblich.

Ein Anwendungszweck wäre z.B. das Ding mit Plesk am Port 8443. Oder TomCat an 8080. Oder die DIVA 8BRI in meinem Telefonserver, die zur GUI-Konfig einen eigenen Webser mitbringt (den man aber nicht braucht. Wenn man weiß, was man tut, ist der eher hinderlich). Oder diverse Dockercontainer.

Ein anderer Port ist weitaus weniger gruselig als eine Frame-Weiterleitung, schon deswegen, weil transparent.

CU, Peter

Hay,

Zitat von SCWfan06

Konsole

ah, ok, das Bedienpult. Klar.

Dann viel Erfolg, ausreichend Infos solltest Du ja haben.

Das Einzige, was Dir jetzt noch reinhauen kann, dass die Konsole von den Tafeln eine Art ACK erwartet (als dediziertes Signal https://de.wikipedia.org/wiki/ACK_(Signal) oder durch ein anderes Signal oder String) als Bestätigung, dass die Daten angekommen sind um dann die nächsten Daten zu senden. Analoge Modems senden z.B. auf ein Kommando den String "OK"+<CR>, wenn sie einen Befehl korrekt verarbeitet haben.

Also achte einfach im Terminalprogramm darauf, ob die Anzeigetafel etwas zurückschickt, falls die Konsole nach dem ersten Signal nichts mehr sendet. M.a.W. würde ich Dir in dem Fall eigentlich empfehlen, Bedienpult und Anzeige funktionsfähig aufzubauen und zu testen, dann einen PC mit ZWEI Schnittstellen bzw. Konvertern dazwischen schalten, den Traffic bidirektional durchzuleiten und gleichzeitig mitzuschreiben, um das Protokoll näher kennen zu lernen. Für USB-Schnittstellen kann man dafür sogar Wireshark verwenden... aber diese Form des harten, reverse Engineering wäre vermutlich mit Kanonen auf Spatzen geschossen.

CU, Peter

Hay,

Zitat von EADG

Frame-Weiterleitung an eine externe Domain

Frame-Weiterleitungen sind gruselig, führen in die Irre (v.a. den Nutzer - und erwecken den Anschein, man würde eine andere Webseite "kapern" z.B. eine Vertipper-Domain von einem großen Reseller auf die echte Domain mit einem Reflink, um Provisionen abzufangen) und machen diverse andere Probleme (Suchmaschinen, Bookmarks etc.).

Mach lieber die Weiterleitung per PHP, da bist Du auf gar keine Einstellungen angewiesen.

<?php
header("Location: http://www.example.com:8080/"); 
exit;
?>

CU, Peter

Hay,

Zitat von ocin4

Gestern ging eine Mail plötzlich durch und kam beim Empfänger an, ohne dass ich was unternommen hab. Wird Microsoft jetzt doch ein "Guter"? Habt ihr ähnliche Erfahrung gemacht?

dann ist da wohl irgendwas kaputt gegangen. Oder Willkür.

CU, Peter

Hay,

ich frage deswegen, weil solche Tafeln eigentlich nur geschrieben werden, aber nichts rausrücken, nicht dass Du nachher viel Arbeit hattest und enttäuscht bist Die Datensatz-Beschreibung liest sich nämlich in einigen Parts so, z.B. "that the packet is intended for".

CU, Peter

Hay,

ist ja alles fein beschrieben - was ich mich nur frage... woher bekommt das Anzeigeboard die Daten? Für mich sieht es eher so aus, als ob die Schnittstelle dafür gedacht ist, Daten auf das Board zu schreiben?

CU, Peter

Hay,

hat mich selbst grad interessiert... ist tatsächlich recht einfach, eine serielle Schnitte zu lesen. Siehe komplettes Code-Beispiel für VB:

https://docs.microsoft.com/de-de/dotnet/v…om-serial-ports

Habe sogar auf die Schnelle Beispiele in PHP gefunden, aber die waren nicht besonders gut - eine intensivere Recherche könnte sich aber lohnen.

CU, Peter

Hay,

ziemlich sicher stellt Dir der USB-Konverter einen emulierten (Windows/DOS)-COM-Port zur Verfügung. Den "einfach" lesen, wobei ich sagen muss, das habe ich zum letzten Mal vor 30 Jahren gemacht und unter DOS jedenfalls war das easy. Müsste eigentlich heutzutage mit Visual Basic/Visual Studio ähnlich einfach gehen.

CU, Peter

Hay,

Zitat von janxb

Oder indem er die Datei in ".php.txt" umbenennt für die Übertragung per HTTP

lol, oder so.

Anstatt eine Schraube zu nehmen, nimmt man einen Nagel und schlägt ihn mit dem Griff des Schraubenziehers in die Wand. Tut weh (dem Betrachter noch mehr als dem Nutzer), kann man aber so machen.

Im Moment ist es für mich aber eher eine Datei mit Owner schroedinger:katze: Ob wirklich eine .php oder doch nur eine getarnte .txt bleibt offen, deswegen fragte ich nach dem Hintergrund.

CU, Peter

Zitat von Sharky04

wie muß er sein?

#7 nochmal lesen

Hay,

nochmals aufgereiht:

- .htaccess und .htpasswd beide ins phpMyAdmin-Verzeichnis (im httpdoc keine der beiden!)

- den Pfad in der .htaccess ergänzt Du um phpMyAdmin im Pfad (-> /var/www/vhosts/hostingxxxxxx.xxxxxx.netcup.net/httpdocs/phpMyAdmin/.htpasswd)

- nun müsste das phpMyAdmin-Verzeichnis geschützt sein

CU, Peter

Hay,

/httpdocs/.htpasswd - der Pfad IN DER .htaccess auf die Password-Datei ist immer noch falsch oder die falsche htaccess wird aufgerufen.

CU, Peter

Hay,

Zitat von Sharky04

curl https://server/test.php

vielleicht sollte man mal fragen, was das ganze soll... willst Du den Inhalt der php-Datei oder den erzeugten Output der php-Datei?

So bekommst Du den Output, d.h. das, was vom Webserver daraus gemacht wird - weil der handler (bei dem Verhalten also vermutlich ein CGI-Handler) für php weiß, dass es eine ausführbare Datei ist, findet das "#" in der ersten Zeile, weil das ein Shebang aussieht, findet keinen Interpreter dafür, schmeißt die (ungültige) Zeile weg und schickt den Rest als Output.

Wenn Du die php-Datei als solche willst, bekommst Du nicht per wget oder curl, sondern nur durch eine "echte" Übertragung wie ftp...

CU, Peter

Hay,

DOCUMENT_ROOT, bzw. wem phpinfo zu lang ist, das ist kürzer:

<?php
  echo $_SERVER["DOCUMENT_ROOT"]
?>

CU, Peter

Hay,

Zitat von Sharky04

600 config.inc.php

Zu meiner großen Überraschung ist die Datei jedoch weiterhin von Außen erreichbar!

es mag ja nicht die schönste Lösung sein, aber entweder mit .htaccess (siehe mfnalex) absichern ... oder es einfach "aushalten". Wenn die config.inc.php richtig geschrieben ist, liefert sie keinen Inhalt nach außen - also ruf sie auf, geh in die Quellcode-Ansicht der Webseite und Du solltest eine komplett leere Seite sehen.

Das wird allerdings dann kritisch, wenn aus irgend einem Grund der handler für php nicht korrekt funktioniert (also, wenn der Webserver nicht mehr weiß, was er mit .php-Dateien anfangen soll) und die Datei dann potenziell im Klartext ausgeliefert wird, also sind wir wieder bei .htaccess.

CU, Peter

Hay,

Zitat von VVV

Okay, und falls ich dem Server mehrere Domains zugewiesen habe ist es egal, welche ich nehme?

freie Auswahl - idealerweise, welche Du als rdns im ccp oder scp eingetragen hast (oder umgekehrt). Hat ggf. Auswirkung, wenn Du einen Mailserver drauf betreibst.

CU, Peter

Hay,

Zitat von chaosrind

Hmmm... mal was anderes: wo bekomm ich spam/phishing her, wenn ich sowas mal (zum testen) brauche?

Für Leute mit großen ... Rädern: http://artinvoice.hu/spams/

("We have in our collection 6.69 GB (1 190 960 pcs.) of gzipped spam! Get it! Use it!")

CU, Peter