- √ - Port, auf dem der HS seine IP-Pakete sendet

[Rupprecht]

Hallo,
ich habe jetzt mit Wireshark herausgefunden, daß der Homeserver seine IP-Telegramme (zumindest die UDP) via lokalem Port 1028 versendet.
Ist das stabil, oder kann sich das ändern, oder kann man das irgendwo konfigurieren?
In der Hilfe habe ich nichts dazu gefunden, und unter den Einstellungen auch nicht.
Hintergrund der Frage ist, daß ich Telegramme versenden möchte und ich mit netcat von Linux ein Quellport für das Connect angeben muß. Mit 1028 als Port des HS-Server geht es.
Gruß
Frank

[AScherff]

... daß der Homeserver seine IP-Telegramme (zumindest die UDP) via lokalem Port 1028 versendet...

ähmm.... welche Telegramme soll denn der HS da via UDP an wen versenden? Zu welchem Zweck? Wenn Du im Experten selber Telegramme versendest, kannst Du doch den Port einstellen. Oder meinst Du die Kommunikation zwischen HS und einem IP-Gateway??

[makki]

Der Quellport ist IP-typisch dynamisch (und für gewöhlich zumindest bei *nix >1024). Hab auch nichts gesehen wo man das einstellen könnte. Würde auch keinen Sinn machen, weil das nur zu obskuren Limitationen und Fehlern führen würde (was soll er mit *einem* fixem Quellport machen wenn er z.B. zwei TCP-Verbindungen offen haben soll..)

Die Frage die sich mir stellt wäre auch der Zweck, das einzige was mir einfällt wäre für Security-Zwecke und dafür taugt das ohnehin nicht..

Makki

[Rupprecht]

Hallo,

danke für die Anteilnahme.

Noch mal zur Motivation:

Ich möchte auf einem Linux-PC IP-Pakete empfangen und je nach deren Inhalt auf dem PC Aktionen ausführen (z.B. Shutdown).

Dazu nehme ich im Augenblick netcat (nc).

 nc -p 12345 -u 192.168.0.11 1028

funktioniert!

Dabei ist 12345 der lokale Port auf dem Linux-PC (der auch auf dem HS bei der Definition des IP-Telegrams spezifiziert wird).

Dummerweise funktioniert das ganze nicht ohne den Port 1028 (ist ein Pflichtparameter).

Leider funktioniert auch nicht

nc -u localhost 12345

Gruß Frank

[makki]

Versuch mal "nc -l -u -p 12345"
Das lässt netcat auf Port 12345 auf dem Rechner horchen (-l = listen), das ist ja was Du willst (?) vermute ich..
Ich würde aber ohnehin TCP nehmen, dann kommt das Paket auch sicher an und es kostet nicht mehr

Makki

[Gaston]

Ich würde aber ohnehin TCP nehmen, dann kommt das Paket auch sicher an und es kostet nicht mehr

Bei Verwendung von TCP anstelle von UDP ist generell einiges zu beachten. TCP ist nicht einfach UDP mit mehr sicherheit etc... Der grosse Unterschied ist dass es bei TCP keine Pakete im Konzept gibt. das heisst wenn ich bei UDP einmal "SHUT" und einmal "SWITCH" schicke z.b dann kommen auf der anderen Seite zwei Pakete an. Bei TCP kann aber z.B. "SHUTSWITCH" ankommen und auch wenn zwei Pakete ankommen könnten die z.B. "SHUTS" und "WITCH" lauten.

Im Fall von netkat wird allerdings beides TCP & UDP in eine stream umgewandelt somit hat makki auf netcat bezogen recht und TCP macht mehr Sinn. Die Pakete müssen aber itrgendwie abgeschlossen werden, z.B. mit einem line-feed und können dann mit sowas wie "netcat ... | while read CMD" gelesen werden.

Gruss,
Gaston

[makki]

So oder so ähnlich Verstehe zwar nicht ganz was die L4-Protokolleigenschaften mit dem Übermitteln von terminierten oder nicht terminierten Daten zu tun haben weil in beiden Fällen bei der Applikation immer dasselbe ankommt, solange man den IP-Stack nicht selber schreibt aber seis drum..

Mich frierts nur immer wenn (hier des öfteren) und ohne jegliche Not Steuerbefehle ohne zusätzliche Sicherungs- oder Korrekturmassnahmen auf Anwendungsebene mit UDP verschickt werden, dafür ist UDP eigentlich nicht wirklich gemacht..
Neben der Sicherheit der Datenübertragung hat TCP hier auch noch einen anderen entscheidenden Vorteil: Es wird (zumindest für den Normalfall halbwegs zuverlässig) sichergestellt, dass das Paket auch von dem angegebenen Absender kommt, weil ein Verbindungsaufbau stattfindet und nicht von einem x-beliebigen Rechner irgendwo auf dieser Erde es durch die Fritzbox geschafft und 192.168.0.11 in den IP-Header geschrieben hat (Spoofing).. Das ist besonders bei so netcat-Geschichten wenigstens ein klein bisschen sicherer.

Die Empfehlung von TCP hat bei netcat in dem Fall aber eigentlich nen viel einfacheren Hintergund (weil ich mir ziemlich ähnlich auch schon ein paar Sachen mit dem HS angedacht habe und dafür schon ein kleines Testscript gebaut hab ):
nc beendet sich nach dem ordnungsgemässen beenden der TCP-Verbindung (in dem Fall durch den HS) von selbst, man muss keine sonstigen Kunststücke in dem verarbeitenden Script machen sondern kann die Endlosschleife Modell "supersimpel" verwenden.

Makki

[AScherff]

Mich frierts nur immer wenn (hier des öfteren) und ohne jegliche Not Steuerbefehle ohne zusätzliche Sicherungs- oder Korrekturmassnahmen auf Anwendungsebene mit UDP verschickt werden, dafür ist UDP eigentlich nicht wirklich gemacht..

UDP ist besser als der Ruf. Ich kenne ein System, welches ich selber konzipiert habe, das aus einer transaktionnsverarbeitenden Anwendungen (Verfügbarkeit 99,99999 %) bis zu hundert komplexe Nachrichten je Sekunde (bei Lasttests bis zu 150 Nachrichten) an eine UDP-Trap versendet, welche die Nachricht decodiert um sie anschliessend in eine MySQL Datenbank zu schreiben. In den letzten 18 Monaten kam es bei den UDP Telegrammen zu keinen Verlusten (die Telegramme sind serialisiert).

Sicher, der Vorteil bei TCP ist, das der Sender den Empfang quittiert bekommt, dadurch wird der eigentliche Transport jedoch nicht sicherer...

[Gaston]

So oder so ähnlich Verstehe zwar nicht ganz was die L4-Protokolleigenschaften mit dem Übermitteln von terminierten oder nicht terminierten Daten zu tun haben weil in beiden Fällen bei der Applikation immer dasselbe ankommt, solange man den IP-Stack nicht selber schreibt aber seis drum...

Einer der grossen Missverständnisse von TCP/UDP: UOPD ist packet orientiert, TCP nicht. Oft wird bei der Programierung jedoch eine TCP Verbindung benutzt weil sie vermeindlich sicherer ist und trotzdem paketorientiert progarmiert (sprich wenn dier Sender XXX schickt erwartet der empfänger dass beim nächsten lesen genau diese Daten da sind). Das läuft in den meisten Fällen auch so ohne probleme bis auf einmal...

Mich frierts nur immer wenn (hier des öfteren) und ohne jegliche Not Steuerbefehle ohne zusätzliche Sicherungs- oder Korrekturmassnahmen auf Anwendungsebene mit UDP verschickt werden, dafür ist UDP eigentlich nicht wirklich gemacht..

Nun das ist eben so wie bei EIB, unsicherer Transport. Ok nicht ganz, weil kein "repeat", aber wiederum ist der enet Transport eh sicherer.

Wenns nicht etwas wichtiges ist würde ich für solche kurzen Telegramme auch UDP verwenden.

Neben der Sicherheit der Datenübertragung hat TCP hier auch noch einen anderen entscheidenden Vorteil: Es wird (zumindest für den Normalfall halbwegs zuverlässig) sichergestellt, dass das Paket auch von dem angegebenen Absender kommt, weil ein Verbindungsaufbau stattfindet und nicht von einem x-beliebigen Rechner irgendwo auf dieser Erde es durch die Fritzbox geschafft und 192.168.0.11 in den IP-Header geschrieben hat (Spoofing).. Das ist besonders bei so netcat-Geschichten wenigstens ein klein bisschen sicherer.

Spoofing durch einen NAT Router ? Na viel Spass beim Versuchen

nc beendet sich nach dem ordnungsgemässen beenden der TCP-Verbindung (in dem Fall durch den HS) von selbst, man muss keine sonstigen Kunststücke in dem verarbeitenden Script machen sondern kann die Endlosschleife Modell "supersimpel" verwenden.

Jaaaaaa ! Jetzt verstehe ich warum Du Die keine Sorgen um die Terminierung und L4 unterschiede machen brauchst. Aber witzig find ichs trotzdem: Du willst TCP verwenden um ja kein Paket zu verpassen, riskierts aber explizit dass eben genau das passiert wenn eine Verbindung vom HS Aufgebaut wird zwischen dem Beenden und Neustart von nc ?????

Man kann nc in einem server modus laufen lassen wo dieser dann dauernd läuft, und hier ist es sehr wohl ein unterschied ob man TCP oder UDP verwendet. Wenn man netcat allerdings so ausliest wie ich es beschrieben habe macht es aus Sicht des scripts allerdings keinen unterschied, und die Befehle müssen mit LF terminiert werden damit read jedes Kommando einzeln erhält.

Gruss,
Gaston

[makki]

Sorry, aber da komme ich nicht mit.. Natürlich ist der Transport sicherer und vor allem besteht ein Feedback zwischen absendern und Empfänger ob auch was ankam.
UDP ist nicht besser als sein Ruf sondern das LAN normalerweise weniger verlustbehaftet als ein WAN. Es gibt das vielleicht gute Gründe für UDP und eine Anwendung stellt ja in dem Fall vermutlich auch die Übertragung sicher und erkennt oder korrigiert Fehler/Verluste.

Das ist aber weder bei netcat noch dem HS der Fall - und darum geht es hier ja glaub ich.

UDP ist und bleibt einfach nicht das geeignete Protokoll für die Übermittlung von Steuerbefehlen oder kleinen Nachrichten, wenn *keine* Sicherungsschicht in der Anwendung existiert. Und sonst meist auch nicht, deswegen wirds auch nicht für SMTP, HTTP, SNPP etc.pp verwendet, sondern ausschliesslich wenn man entweder ohnehin mit Verlusten rechnet oder diese durch redundanzen ausgleichen kann (DNS) und/oder der Nachteil einer Paketwiederholung und damit Verlust der Echtzeitfähigkeit (Voice/Video) überwiegt.

Das steht in der RFC, ist lehrmeinung und entspricht den annerkannten Regeln der Technik.

Ich kann Cat5 auch in den Schacht zusammen mit Niederspannungsleitungen legen und es wird meistens gutgehen, man macht es trotzdem nicht..

Ich verstehe absolut nicht warum man hier nun unbedingt UDP nehmen sollte.. Was wollt ihr denn im Jahr 2008 sparen: CPU-Resourcen für den SYN-ACK-FIN oder Netzwerkbandbreite ?

Einer der grossen Missverständnisse von TCP/UDP: UDP ist packet orientiert, TCP nicht. Oft wird bei der Programierung jedoch

Richtig, das ist aber in dem Fall nur aus Programmierersicht interessant. UDP ist auch Verbindunglos und TCP Verbindungsorientiert. Ich hab da keine Missverständnisse
Wenn der Programmierer Mist baut, wirds wohl zu Problemen kommen. Wir wollten aber nichts in C programmieren und an die API ein send() schicken und es an der Gegenstelle mit einem receive(*buffer) annehmen, oder ?

Ich weiss sehr gut was Du meinst, das spricht aber nicht für UDP sondern einzig und allein gegen den Programmierer.

Nun das ist eben so wie bei EIB, unsicherer Transport. Ok nicht ganz, weil kein "repeat", aber wiederum ist der enet Transport eh sicherer.

Was ist an EIB unsicher ? Damit kenn ich mich ja nun nicht aus, aber es gibt CA auf L2 sowie ACKs und Retransmits, die letzteren beiden gibts beim UDP-netcat-packerl nicht.
Und wer sagt das es Ethernet ist ? TCP/IP-Anwendungen sollten m.E. nicht als Schönwetterapplikation gestrickt werden, sondern so dass sie unter möglichst allen Einsatzbedingungen auch fehlerfrei funktionieren.
Es gibt z.B. Wlan, da siehts nicht mehr so toll aus weil sich der L2 da nämlich sehr viel mehr auf die Sicherung der der darüberliegenden Schichten verlässt.

Wenns nicht etwas wichtiges ist würde ich für solche kurzen Telegramme auch UDP verwenden.

Zu welchem Punkt entscheidest Du "Wichtig" und "Unwichtig" ? Beim Design der Applikation, bei der Implementierung oder wenn später zur Nachricht "Play" die Nachricht "Feuer" und "Haustuere_offen" hinzugefügt wird ? Ich denke Du weisst was ich meine..

-> Spoofing durch einen NAT Router ?
Schicke mal an einen durchschnittlichen SoHo-Router (Netg*, Fritzi und Horst, such Dir einen aus) mit einer UDP-Portfreigabe inkl. NAT zum PC ein gespooftes Paket und schau mit dem Wireshark was dort ankommt. Du wirst überrascht sein, wie viel tolle Firewall und Antispoofing da drin ist.. Firewallregeln natürlich aussen vor, die sind aber falls überhaupt sinnvoll möglich bei Otto-Normalanwender normalerweise nicht eingerichtet..
Und nromalerweise wird man ja nicht RFC1918-Adressen (192.168.x.x/26) spoofen sondern öffentliche. Sprich welbst wenn dort eine Firewall-Regel implementiert ist (z.B. nur mein Hosted-Server darf rein) komme ich dran vorbei, weil die Firewall trotz Stateful-Inspection keine Chance hat weils keinen State zum Inspecten gibt.

riskierts aber explizit dass eben genau das passiert wenn eine Verbindung vom HS Aufgebaut wird zwischen dem Beenden und Neustart von nc ?????

Berechtigter Einwand Aber hab ich das gesagt ? Man kann auch in diesem Fall (im Gegensatz zu UDP) einen Fehler erkennen, Rückmelden und ggfs. reagieren, ich will ja keine Schönwetterapplikation machen. (Der Connection-Timeout dürfte zwar locker reichen bis der nc wieder läuft aber darauf verlässt man sich eben nicht.)
Ich habe lieber einen klar aufgetretenen und protokollierten Fehler als die Ungewissheit. Ausserdem würde ich so (mit netcat und endlosschleife) nichts produktives machen. Ich denke da eher an ein Perl-Script, aber das ist jetzt (noch) nicht das Thema.. Egal wie, es gehört mit TCP gemacht.

Die Befehle/Zeilen/Daten sollten oder besser müssen doch so oder so terminiert werden in einer ordentlichen Applikation und nicht abhängig vom verwendeten Transportprotokoll z.B. mit oder ohne LF bearbeitet werden.


Grüsse Makki

[Gaston]

Das ist mal wieder ein typischer non-sense Topicablauf:

Die ursprünglichse Aussage ging über netcat und der Einwand war TCP anstelle von UDP zu verwenden. All meine Aussagen bezogen sich auf genau diese Konfiguration umd dann, wie so oft an einen Punkt anzulangen "ja ich würds eh nicht mit netcat machen", etc...

Somit werden alle Aussagen zwar als falsch dargestellt aber nur weil sich auf einmal der Kontext Grundlegend ändert.

Da somit der ganze Thread unverständlich für aussenstehende ist beedne ich hier meine Mitwirkung an dem Gewusel.

Gruss,
Gaston

[makki]

Aha..
Lieber Gaston, die Antwort von mir war war den richtigen Parameter zu verwenden mit dem Hinweis auf TCP, völlig ohne ausschweifen und Begründung.

Der Einwand war dann wohl eher dass wenn man es ganz anders macht (nc aufrufen != Daemon != eigene Applikation), man beim Programmieren seine Datensätze sauber terminieren sollte.

Und der Poster will es ja mit netcat machen, wo die initial von Dir angebrachten Dinge nicht zutreffen, wie Du ja selbst beim ersten Post schreibst. Deine Aussagen habe sich eben genau nicht darauf bezogen sondern ich habe erst bei Deinem zweiten Post ansatzweise verstanden dass Du einem Kommandozeilen-Script-user versuchst die Unterschiede in der Socketprogrammierung zu erklären.

Der Kontext hat sich nicht geändert, ich bin nur auf Deine Kontextänderung eingegangen und darauf warum UDP nicht besser ist als sein Ruf sondern schlicht das falsche Protokoll für diese Anwendung.

Makki

[meudenbach]

Wir bzw. ich, nicht in "ISO Schichten" denkender, weil generell auf der Anwendungsschicht zugreifend, mache mir da gar keine Gedanken und bin gleicher Meinung wie der Alfred...

Fazit, UDP völlig ausreichend... und in vielen, vielen Anwendungen störungsfrei umgesetzt. Letztendlich kann auch eine UDP Kommunikation über entsprechende Strategieen sehr wirksam umgesetzt werden... wir lassen als bsp. den Empänger das empfangene Datagramm zurücksenden und senden im Zweifel oder bei "Fehler" das Datagramm erneut... i.d.R ist dies jedoch in 99,9999% der Fälle nicht notwendig.

Unser Daemon Entwickler zB diskutiert mit mir ähnlich wie o.a... . Irgendwo kann ich dann nicht mehr folgen ... und berufe mich auf die Praxis. Damit wir "beide" dann unseren Willen bekommen ermöglichen wir grundsätzlich beide Wege, also TCP und/oder UDP.

EIB arbeitet letztendlich ja auch ähnlich einer UDP BC Kommunikation und ist hierbei mit einer recht guten "Strategie" behaftet, welches in der Praxis recht wirksam greift... Man überlege, die Kommunikation würde auf Basis TCP erfolgen, so müßte ich bei 5000 Jalousieaktoren im Idealfall min. 15000 TCP Pakete auf die Reise bringen... dies geht mächtig auf die Bandbreite und zb bei LON Anlagen auch schon mal mächtig in die Hose..

Im Zweifel sende ich dann doch lieber ein 2. oder 3. UDP BC hinterher...

Würde ich mich zB im WAN bewegen, wobei ich dann über Liegenschaftsvernetzung rede, würde ich natürlich auf TCP zurückgreifen. Dies jedoch nur für die Strecke von und ins WAN. Im LAN geht es dann via UDP weiter...

LG

[Rupprecht]

Da ich ein Paar Tage weg war, musste ich jetzt die Diskussion erst einmal zu Ende lesen.

Versuch mal "nc -l -u -p 12345"

Geht natürlich

Danke,

Gruß Frank

[Gaston]

Zusammenfassung

Geht natürlich

Aus der sinnlosen Diskussion hatte ich mich zwar verabschieded aber ich hätte wohl meine Punkte mal zusammen fassen sollen:

1. Was UDP betrifft stimme ich Alfred und Mike zu. Wie Mike und Ich schon geschrieben haben, ist EIB auch nicht (viel) sicherer wie UDP denn auch ein ACK stellt nicht sicher dass das Paket angekommen ist.

Auch widerspreche ich dass die pauschale Aussage "UDP ist und bleibt einfach nicht das geeignete Protokoll für die Übermittlung von Steuerbefehlen oder kleinen Nachrichten, wenn *keine* Sicherungsschicht in der Anwendung existiert":

a. im RFC steht: das steht da pauschal nicht drin, auch gibt es ja eine Reihe Protokolle die auf UDP ohne Sicherungsschicht basieren wie z.B. SNMP traps
b. Lehrmeinung ist: Und das kann ich mir erlauben da ich in meiner Zeit in der inet Forschung in den 90er und auch einige Jahre danach u.A. Dozent für eben TCP/IP war.
c. den Regeln der Technik entspricht: die Regeln der Technik sind sehr dehnbar

2. netcat ohne -k (also server loop) ist u.U keine gute Lösung da
Pakete zwischen dem Empfang des letzten Pakets und bis netcat wieder gestartet wird verloren gehen.

Die Aussage bei Verwendung von TCP in diesem Zusammenhang: "Der Connection-Timeout dürfte zwar locker reichen bis der nc wieder läuft" ist falsch da beim Beenden von netcat der TCP ungebunden ist und somit bei einem Kommunikationsversuchs des HS ein RST,ACK zurückgeschickt wird und somit die Verbindung sofort beendet wird und kein timeout läuft.

3. Das Terminieren der Pakete mit LF zielte genau auf das Verwenden dieser -k Option ab da dort die empfangegen Pakete als stream ausgegeben werden und somit das Ende eines jeden erkennbar sein muss.

So, ich hoffe ich hab nix vergessen, und mich einigermassen klar ausgedrück.

Gruss,
Gaston