Amateurfunk Forum - Archiv

Fragen und Antworten zum Thema Funk


Impressum

Verantwortlich für dieses Angebot gemäß § 5 TMG / § 55 RStV:
Michael Ott
Dorpater Straße 11
70378 Stuttgart
Deutschland



Trotz sorgfältiger inhaltlicher Kontrolle übernehmen wir keine Haftung für die Inhalte externer Links. Für den Inhalt der verlinkten Seiten sind ausschließlich deren Betreiber verantwortlich.

Datenschutzerklärung

Diese Datenschutzerklärung klärt Sie über die Art, den Umfang und Zweck der Verarbeitung von personenbezogenen Daten (nachfolgend kurz „Daten“) innerhalb unseres Onlineangebotes und der mit ihm verbundenen Webseiten, Funktionen und Inhalte auf (nachfolgend gemeinsam bezeichnet als „Onlineangebot“). Im Hinblick auf die verwendeten Begrifflichkeiten, wie z.B. „Verarbeitung“ oder „Verantwortlicher“ verweisen wir auf die Definitionen im Art. 4 der Datenschutzgrundverordnung (DSGVO).

Verantwortlicher

Michael Ott
Dorpater Straße 11
70378 Stuttgart
Deutschland



Arten der verarbeiteten Daten:

- Meta-/Kommunikationsdaten (siehe Abschnitt „Erhebung von Zugriffsdaten und Logfiles“)

Kategorien betroffener Personen

Besucher und Nutzer des Onlineangebotes (Nachfolgend bezeichnen wir die betroffenen Personen zusammenfassend auch als „Nutzer“).

Zweck der Verarbeitung

- Zurverfügungstellung des Onlineangebotes, seiner Funktionen und Inhalte
- Sicherheitsmaßnahmen.

Verwendete Begrifflichkeiten

„Personenbezogene Daten“ sind alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person (im Folgenden „betroffene Person“) beziehen; als identifizierbar wird eine natürliche Person angesehen, die direkt oder indirekt, insbesondere mittels Zuordnung zu einer Kennung wie einem Namen, zu einer Kennnummer, zu Standortdaten, zu einer Online-Kennung (z.B. Cookie) oder zu einem oder mehreren besonderen Merkmalen identifiziert werden kann, die Ausdruck der physischen, physiologischen, genetischen, psychischen, wirtschaftlichen, kulturellen oder sozialen Identität dieser natürlichen Person sind.

„Verarbeitung“ ist jeder mit oder ohne Hilfe automatisierter Verfahren ausgeführte Vorgang oder jede solche Vorgangsreihe im Zusammenhang mit personenbezogenen Daten. Der Begriff reicht weit und umfasst praktisch jeden Umgang mit Daten.

„Pseudonymisierung“ die Verarbeitung personenbezogener Daten in einer Weise, dass die personenbezogenen Daten ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können, sofern diese zusätzlichen Informationen gesondert aufbewahrt werden und technischen und organisatorischen Maßnahmen unterliegen, die gewährleisten, dass die personenbezogenen Daten nicht einer identifizierten oder identifizierbaren natürlichen Person zugewiesen werden.

Als „Verantwortlicher“ wird die natürliche oder juristische Person, Behörde, Einrichtung oder andere Stelle, die allein oder gemeinsam mit anderen über die Zwecke und Mittel der Verarbeitung von personenbezogenen Daten entscheidet, bezeichnet.

„Auftragsverarbeiter“ eine natürliche oder juristische Person, Behörde, Einrichtung oder andere Stelle, die personenbezogene Daten im Auftrag des Verantwortlichen verarbeitet.

Maßgebliche Rechtsgrundlagen

Nach Maßgabe des Art. 13 DSGVO teilen wir Ihnen die Rechtsgrundlagen unserer Datenverarbeitungen mit. Sofern die Rechtsgrundlage in der Datenschutzerklärung nicht genannt wird, gilt Folgendes: Die Rechtsgrundlage für die Einholung von Einwilligungen ist Art. 6 Abs. 1 lit. a und Art. 7 DSGVO, die Rechtsgrundlage für die Verarbeitung zur Erfüllung unserer Leistungen und Durchführung vertraglicher Maßnahmen sowie Beantwortung von Anfragen ist Art. 6 Abs. 1 lit. b DSGVO, die Rechtsgrundlage für die Verarbeitung zur Erfüllung unserer rechtlichen Verpflichtungen ist Art. 6 Abs. 1 lit. c DSGVO, und die Rechtsgrundlage für die Verarbeitung zur Wahrung unserer berechtigten Interessen ist Art. 6 Abs. 1 lit. f DSGVO. Für den Fall, dass lebenswichtige Interessen der betroffenen Person oder einer anderen natürlichen Person eine Verarbeitung personenbezogener Daten erforderlich machen, dient Art. 6 Abs. 1 lit. d DSGVO als Rechtsgrundlage.

Sicherheitsmaßnahmen

Wir treffen nach Maßgabe des Art. 32 DSGVO unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen, geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten.

Zu den Maßnahmen gehören insbesondere die Sicherung der Vertraulichkeit, Integrität und Verfügbarkeit von Daten durch Kontrolle des physischen Zugangs zu den Daten, als auch des sie betreffenden Zugriffs, der Eingabe, Weitergabe, der Sicherung der Verfügbarkeit und ihrer Trennung. Des Weiteren haben wir Verfahren eingerichtet, die eine Wahrnehmung von Betroffenenrechten, Löschung von Daten und Reaktion auf Gefährdung der Daten gewährleisten. Ferner berücksichtigen wir den Schutz personenbezogener Daten bereits bei der Entwicklung, bzw. Auswahl von Hardware, Software sowie Verfahren, entsprechend dem Prinzip des Datenschutzes durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen (Art. 25 DSGVO).

Zusammenarbeit mit Auftragsverarbeitern und Dritten

Sofern wir im Rahmen unserer Verarbeitung Daten gegenüber anderen Personen und Unternehmen (Auftragsverarbeitern oder Dritten) offenbaren, sie an diese übermitteln oder ihnen sonst Zugriff auf die Daten gewähren, erfolgt dies nur auf Grundlage einer gesetzlichen Erlaubnis (z.B. wenn eine Übermittlung der Daten an Dritte, wie an Zahlungsdienstleister, gem. Art. 6 Abs. 1 lit. b DSGVO zur Vertragserfüllung erforderlich ist), Sie eingewilligt haben, eine rechtliche Verpflichtung dies vorsieht oder auf Grundlage unserer berechtigten Interessen (z.B. beim Einsatz von Beauftragten, Webhostern, etc.).

Sofern wir Dritte mit der Verarbeitung von Daten auf Grundlage eines sog. „Auftragsverarbeitungsvertrages“ beauftragen, geschieht dies auf Grundlage des Art. 28 DSGVO.

Übermittlungen in Drittländer

Sofern wir Daten in einem Drittland (d.h. außerhalb der Europäischen Union (EU) oder des Europäischen Wirtschaftsraums (EWR)) verarbeiten oder dies im Rahmen der Inanspruchnahme von Diensten Dritter oder Offenlegung, bzw. Übermittlung von Daten an Dritte geschieht, erfolgt dies nur, wenn es zur Erfüllung unserer (vor)vertraglichen Pflichten, auf Grundlage Ihrer Einwilligung, aufgrund einer rechtlichen Verpflichtung oder auf Grundlage unserer berechtigten Interessen geschieht. Vorbehaltlich gesetzlicher oder vertraglicher Erlaubnisse, verarbeiten oder lassen wir die Daten in einem Drittland nur beim Vorliegen der besonderen Voraussetzungen der Art. 44 ff. DSGVO verarbeiten. D.h. die Verarbeitung erfolgt z.B. auf Grundlage besonderer Garantien, wie der offiziell anerkannten Feststellung eines der EU entsprechenden Datenschutzniveaus (z.B. für die USA durch das „Privacy Shield“) oder Beachtung offiziell anerkannter spezieller vertraglicher Verpflichtungen (so genannte „Standardvertragsklauseln“).

Rechte der betroffenen Personen

Sie haben das Recht, eine Bestätigung darüber zu verlangen, ob betreffende Daten verarbeitet werden und auf Auskunft über diese Daten sowie auf weitere Informationen und Kopie der Daten entsprechend Art. 15 DSGVO.

Sie haben entsprechend. Art. 16 DSGVO das Recht, die Vervollständigung der Sie betreffenden Daten oder die Berichtigung der Sie betreffenden unrichtigen Daten zu verlangen.

Sie haben nach Maßgabe des Art. 17 DSGVO das Recht zu verlangen, dass betreffende Daten unverzüglich gelöscht werden, bzw. alternativ nach Maßgabe des Art. 18 DSGVO eine Einschränkung der Verarbeitung der Daten zu verlangen.

Sie haben das Recht zu verlangen, dass die Sie betreffenden Daten, die Sie uns bereitgestellt haben nach Maßgabe des Art. 20 DSGVO zu erhalten und deren Übermittlung an andere Verantwortliche zu fordern.

Sie haben ferner gem. Art. 77 DSGVO das Recht, eine Beschwerde bei der zuständigen Aufsichtsbehörde einzureichen.

Widerrufsrecht

Sie haben das Recht, erteilte Einwilligungen gem. Art. 7 Abs. 3 DSGVO mit Wirkung für die Zukunft zu widerrufen

Widerspruchsrecht

Sie können der künftigen Verarbeitung der Sie betreffenden Daten nach Maßgabe des Art. 21 DSGVO jederzeit widersprechen. Der Widerspruch kann insbesondere gegen die Verarbeitung für Zwecke der Direktwerbung erfolgen.

Löschung von Daten

Die von uns verarbeiteten Daten werden nach Maßgabe der Art. 17 und 18 DSGVO gelöscht oder in ihrer Verarbeitung eingeschränkt. Sofern nicht im Rahmen dieser Datenschutzerklärung ausdrücklich angegeben, werden die bei uns gespeicherten Daten gelöscht, sobald sie für ihre Zweckbestimmung nicht mehr erforderlich sind und der Löschung keine gesetzlichen Aufbewahrungspflichten entgegenstehen. Sofern die Daten nicht gelöscht werden, weil sie für andere und gesetzlich zulässige Zwecke erforderlich sind, wird deren Verarbeitung eingeschränkt. D.h. die Daten werden gesperrt und nicht für andere Zwecke verarbeitet. Das gilt z.B. für Daten, die aus handels- oder steuerrechtlichen Gründen aufbewahrt werden müssen.

Nach gesetzlichen Vorgaben in Deutschland, erfolgt die Aufbewahrung insbesondere für 10 Jahre gemäß §§ 147 Abs. 1 AO, 257 Abs. 1 Nr. 1 und 4, Abs. 4 HGB (Bücher, Aufzeichnungen, Lageberichte, Buchungsbelege, Handelsbücher, für Besteuerung relevanter Unterlagen, etc.) und 6 Jahre gemäß § 257 Abs. 1 Nr. 2 und 3, Abs. 4 HGB (Handelsbriefe).

Hosting und E-Mail-Versand

Die von uns in Anspruch genommenen Hosting-Leistungen dienen der Zurverfügungstellung der folgenden Leistungen: Infrastruktur- und Plattformdienstleistungen, Rechenkapazität, Speicherplatz und Datenbankdienste, E-Mail-Versand, Sicherheitsleistungen sowie technische Wartungsleistungen, die wir zum Zwecke des Betriebs dieses Onlineangebotes einsetzen.

Hierbei verarbeiten wir, bzw. unser Hostinganbieter Meta- und Kommunikationsdaten von Besuchern dieses Onlineangebotes auf Grundlage unserer berechtigten Interessen an einer effizienten und sicheren Zurverfügungstellung dieses Onlineangebotes gem. Art. 6 Abs. 1 lit. f DSGVO i.V.m. Art. 28 DSGVO (Abschluss Auftragsverarbeitungsvertrag).

Erhebung von Zugriffsdaten und Logfiles

Wir, bzw. unser Hostinganbieter, erhebt auf Grundlage unserer berechtigten Interessen im Sinne des Art. 6 Abs. 1 lit. f. DSGVO Daten über jeden Zugriff auf den Server, auf dem sich dieser Dienst befindet (sogenannte Serverlogfiles). Zu den Zugriffsdaten gehören Name der abgerufenen Webseite, Datei, Datum und Uhrzeit des Abrufs, übertragene Datenmenge, Meldung über erfolgreichen Abruf, Browsertyp nebst Version, das Betriebssystem des Nutzers, Referrer URL (die zuvor besuchte Seite), IP-Adresse und der anfragende Provider.

Logfile-Informationen werden aus Sicherheitsgründen (z.B. zur Aufklärung von Missbrauchs- oder Betrugshandlungen) für die Dauer von maximal 7 Tagen gespeichert und danach gelöscht. Daten, deren weitere Aufbewahrung zu Beweiszwecken erforderlich ist, sind bis zur endgültigen Klärung des jeweiligen Vorfalls von der Löschung ausgenommen.

Vom Websiteinhaber angepasst
Erstellt mit Datenschutz-Generator.de von RA Dr. Thomas Schwenke




 [ 13 Beiträge ]  Gehe zu Seite 1,
Autor Nachricht
 Betreff des Beitrags: Lösungen - UDP Pakete Blockierung beim ISP – nach Routing ?
[b:19033v4u]Lösungen - UDP Pakete Blockierung beim ISP – nach Routing Information ?[/b:19033v4u]

Seit dem 30.12.2007 lässt sich nach mehr als 6 Monaten kein ECHOLINK Betrieb mehr erreichen. Der UDP Test verläuft immer negativ.

[color=red:19033v4u][b:19033v4u]Gibt es konkrete Möglichkeiten mit Tracing Routings eindeutig festzustellen, wo die UDP Pakete beim ISP geblockt werden ?

Hat hierzu bereits jemand Erfahrungen gesammelt ?[/b:19033v4u][/color:19033v4u]

----------------------------------------------------------------------------------------------------

[b:19033v4u]11.01.2008 19:41:27 - Tracing Route to 68.178.144.151 - DOES NOT WORKS[/b:19033v4u]
Hop # 1 63 ms 192.168.1.254
Hop # 2 67 ms 125.26.245.1 125-26-245-1.adsl.totbb.net
Hop # 3 90 ms 203.113.92.229
Hop # 4 86 ms 203.113.54.218
Hop # 5 78 ms 203.113.54.222
Hop # 6 84 ms 203.113.54.226
Hop # 7 85 ms 203.113.54.150
Hop # 8 81 ms 203.113.54.154
Hop # 9 85 ms 203.113.54.158
Hop # 10 84 ms 203.113.24.137
Hop # 11 84 ms 203.113.24.138
Hop # 12 78 ms 203.113.13.126
Hop # 13 84 ms 203.113.24.245
203.113.24.0-203.113.24.255 TOT Public Company Limited Bangkok
Hop # 14 308 ms 61.19.10.13
61.19.0.0-61.19.15.255 CAT-IIGservice
Hop # 15 307 ms 202.47.253.130
202.47.252.0-202.47.254.255 CAT TELECOM Data Comm.
Hop # 16 448 ms 166.63.211.141 so-2-1-0-dcr1.tsd.cw.net
166.63.192.0-166.63.223.255 Cable & Wireless Americas Operations, Inc. NY
Hop # 17 379 ms 195.66.224.76 ge3-0.pr1.lhr1.uk.above.net
195.66.224.0-195.66.225.255 LINX-PEER-1London
Hop # 18 392 ms 64.125.27.57 so-0-1-0.mpr1.dca2.us.above.net
64.124.0.0-64.125.255.255 Abovenet Communications, Inc USA
Hop # 19 402 ms 64.125.29.37 so-5-1-0.mpr2.atl6.us.above.net
Hop # 20 400 ms 64.125.26.13 so-0-0-0.mpr3.iah1.us.above.net
Hop # 21 369 ms 64.125.25.10 so-1-2-0.mpr2.phx2.us.above.net
Hop # 22 366 ms 64.124.113.62 64.124.113.62.godaddy.com
Hop # 23 378 ms 208.109.112.137 ip-208-109-112-137.ip.secureserver.net
Hop # 24 372 ms 208.109.112.161 ip-208-109-112-161.ip.secureserver.net
Hop # 25 366 ms 216.69.188.18 ip-216-69-188-18.ip.secureserver.net
Hop # 26 374 ms 68.178.144.151 ip-68-178-144-151.ip.secureserver.net
Trace Route Complete
[b:19033v4u]
11.01.2008 20:01:21 Tracing Route to 68.178.144.151 - DOES NOT WORKS [/b:19033v4u]
Hop # 1 167 ms 192.168.1.254
Hop # 2 62 ms 125.26.245.1 125-26-245-1.adsl.totbb.net
Hop # 3 86 ms 203.113.92.229
Hop # 4 88 ms 203.113.54.218
Hop # 5 80 ms 203.113.54.222
Hop # 6 82 ms 203.113.54.226
Hop # 7 85 ms 203.113.54.150
Hop # 8 78 ms 203.113.54.154
Hop # 9 85 ms 203.113.54.158
Hop # 10 87 ms 203.113.24.137
Hop # 11 87 ms 203.113.24.138
Hop # 12 78 ms 203.113.13.126
Hop # 13 83 ms 203.113.24.245
Hop # 14 329 ms 61.19.10.13
Hop # 15 327 ms 202.47.253.130
Hop # 16 414 ms 166.63.211.141 so-2-1-0-dcr1.tsd.cw.net
Hop # 17 379 ms 195.66.224.76 ge3-0.pr1.lhr1.uk.above.net
Hop # 18 397 ms 64.125.27.57 so-0-1-0.mpr1.dca2.us.above.net
Hop # 19 402 ms 64.125.29.37 so-5-1-0.mpr2.atl6.us.above.net
Hop # 20 414 ms 64.125.26.13 so-0-0-0.mpr3.iah1.us.above.net
Hop # 21 381 ms 64.125.25.10 so-1-2-0.mpr2.phx2.us.above.net
Hop # 22 366 ms 64.124.113.62 64.124.113.62.godaddy.com
Hop # 23 380 ms 208.109.112.137 ip-208-109-112-137.ip.secureserver.net
Hop # 24 374 ms 208.109.112.161 ip-208-109-112-161.ip.secureserver.net
Hop # 25 382 ms 216.69.188.18 ip-216-69-188-18.ip.secureserver.net
Hop # 26 383 ms 68.178.144.151 ip-68-178-144-151.ip.secureserver.net
Trace Route Complete

[b:19033v4u]
12.01.2008 14:20:12 Tracing Route to 68.178.144.151 - DOES NOT WORKS [/b:19033v4u]
Hop # 1 191 ms 192.168.1.254
Hop # 2 64 ms 125.26.245.1 125-26-245-1.adsl.totbb.net
Hop # 3 117 ms 203.113.92.225
Hop # 4 115 ms 203.113.54.209
Hop # 5 116 ms 203.113.54.205
Hop # 6 121 ms 203.113.54.201
Hop # 7 119 ms 203.113.54.141
Hop # 8 127 ms 203.113.54.137
Hop # 9 118 ms 203.113.54.133
Hop # 10 120 ms 203.113.24.137
Hop # 11 127 ms 203.113.24.138
Hop # 12 119 ms 203.113.13.126
Hop # 13 128 ms 203.113.24.241
Hop # 14 585 ms 61.19.10.13
Hop # 15 551 ms 202.47.253.146
Hop # 16 665 ms 166.63.211.141 so-2-1-0-dcr1.tsd.cw.net
Hop # 17 655 ms 195.66.224.76 ge3-0.pr1.lhr1.uk.above.net
Hop # 18 645 ms 64.125.27.57 so-0-1-0.mpr1.dca2.us.above.net
Hop # 19 688 ms 64.125.28.230 so-1-0-0.mpr2.atl6.us.above.net
Hop # 20 652 ms 64.125.27.49 so-0-0-0.mpr1.atl6.us.above.net
Hop # 21 673 ms 64.125.29.62 so-0-1-0.mpr4.iah1.us.above.net
Hop # 22 668 ms 64.125.26.13 so-0-0-0.mpr3.iah1.us.above.net
Hop # 23 628 ms 64.125.25.5
Hop # 24 650 ms 64.124.147.30 available.above.net
Hop # 25 828 ms 208.109.112.137 ip-208-109-112-137.ip.secureserver.net
Hop # 26 823 ms 208.109.112.161 ip-208-109-112-161.ip.secureserver.net
Hop # 27 633 ms 216.69.188.18 ip-216-69-188-18.ip.secureserver.net
Hop # 28 894 ms 68.178.144.151 ip-68-178-144-151.ip.secureserver.net
Trace Route Complete

[b:19033v4u]08.07.2007 20:34:25 – IT WORKS[/b:19033v4u]
Tracing Route to 68.178.144.151:
Hop # 1 171 ms 192.168.1.254 dsldevice.lan
Hop # 2 49 ms 125.26.246.49 125-26-246-49.adsl.totbb.net
Hop # 3 68 ms 203.113.72.125
Hop # 4 67 ms 203.113.72.253
Hop # 5 70 ms 203.113.95.225
Hop # 6 69 ms 203.113.54.209
Hop # 7 69 ms 203.113.54.205
Hop # 8 69 ms 203.113.54.201
Hop # 9 67 ms 203.113.54.146
Hop # 10 67 ms 203.113.54.150
Hop # 11 70 ms 203.113.54.154
Hop # 12 68 ms 203.113.54.158
Hop # 13 69 ms 203.113.24.137
Hop # 14 68 ms 203.113.24.138
Hop # 15 70 ms 203.113.13.126 vl101.cs1-cwt.totisp.net
Hop # 16 421 ms 203.113.24.237
Hop # 17 418 ms 61.19.10.13
Hop # 18 67 ms 202.47.253.146
Hop # 19 288 ms 195.22.197.193 pal9-cat-telecom-3-id.pal.seabone.net
Hop # 20 325 ms 213.144.183.15 par31-par2-racc1.par.seabone.net
Hop # 21 735 ms 213.144.183.34 globalcrossing-2-us-par31.par.seabone.net
Hop # 22 736 ms 67.17.198.42
Hop # 23 737 ms 208.109.112.137 ip-208-109-112-137.ip.secureserver.net
Hop # 24 728 ms 208.109.112.161 ip-208-109-112-161.ip.secureserver.net
Hop # 25 377 ms 216.69.188.18 ip-216-69-188-18.ip.secureserver.net
Hop # 26 754 ms 68.178.144.151 ip-68-178-144-151.ip.secureserver.net
Trace Route Complete
[b:19033v4u]
10.07.2007 18:15:48 - DOES NOT WORKS[/b:19033v4u]
Tracing Route to 68.178.144.151:
Hop # 1 64 ms 192.168.1.254
Hop # 2 51 ms 125.26.246.49 125-26-246-49.adsl.totbb.net
Hop # 3 83 ms 203.113.72.125
Hop # 4 85 ms 203.113.72.253
Hop # 5 85 ms 203.113.95.226
Hop # 6 83 ms 203.113.54.218
Hop # 7 81 ms 203.113.54.222
Hop # 8 84 ms 203.113.54.226
Hop # 9 85 ms 203.113.54.150
Hop # 10 84 ms 203.113.54.154
Hop # 11 82 ms 203.113.54.158
Hop # 12 84 ms 203.113.24.137
Hop # 13 82 ms 203.113.24.138
Hop # 14 83 ms 203.113.13.126 vl101.cs1-cwt.totisp.net
Hop # 15 711 ms 203.113.24.237
Hop # 16 85 ms 61.19.10.13
Hop # 17 81 ms 202.47.253.130
Hop # 18 586 ms 195.22.197.193 pal9-cat-telecom-3-id.pal.seabone.net
Hop # 19 638 ms 213.144.183.15 par31-par2-racc1.par.seabone.net
Hop # 20 665 ms 213.144.183.34 globalcrossing-2-us-par31.par.seabone.net
Hop # 21 386 ms 67.17.198.42
Hop # 22 945 ms 208.109.112.137 ip-208-109-112-137.ip.secureserver.net
Hop # 23 974 ms 208.109.112.161 ip-208-109-112-161.ip.secureserver.net
Hop # 24 701 ms 216.69.188.18 ip-216-69-188-18.ip.secureserver.net
Hop # 25 388 ms 68.178.144.151 ip-68-178-144-151.ip.secureserver.net
Trace Route Complete

----------------------------------------------------------------------------------------------------

IP: 125.26.245.141
TCP Test: Succeeded.
UDP Test (5198): Receive failed (10060).
Tests complete.

----------------------------------------------------------------------------------------------------

EchoLink Troubleshooter ver 1.2.0.5
Diagnostic Report for
Prepared Friday, January 04, 2008 12:14:54 SE Asia Standard Time

*** User Information ***
Callsign: HS0ZHO

*** System Information ***
Windows XP Service Pack 2

*** Network Options ***
Shared Internet Connection: No
Wireless: No

*** Network Configuration ***
Local IP Address: 125.26.245.93
This is a public address that is directly reachable from the Internet. This usually indicates that your system does not use a router to access the Internet.

Connection type: Other
Shared Internet connection: No
Wireless network connection: No

*** TCP Connectivity Test ***
The TCP test FAILED: Cannot connect to server (10061).
This means that EchoLink might not be able to log in to the EchoLink addressing servers.

The UDP port 5198 test FAILED: Receive failed (10060).
This means that EchoLink cannot communicate with other stations over the Internet.

Be sure your router, firewall, or security software is allowing EchoLink to receive messages over UDP ports 5198 and 5199, [b:19033v4u]and that your Internet service provider (ISP) has not blocked this port.[/b:19033v4u]

A few Internet service providers (ISPs) block a range of different UDP ports, including ports 5198 and 5199 used by EchoLink. [u:19033v4u]Although this is relatively rare, check with your ISP if the rest of your configuration appears to be OK.[/u:19033v4u]

-----------------------------------------------------------------------------------------

IP: 192.168.1.65
TCP Test: Succeeded.
UDP Test (5198): Receive failed (10060).
Tests complete.

IP: 125.26.245.200
TCP Test: Succeeded.
UDP Test (5198): Receive failed (10060).
Tests complete.

IP: 192.168.1.64
TCP Test: Succeeded.
UDP Test (5198): Receive failed (10060).
Tests complete.

IP: 125.26.245.206
TCP Test: Succeeded.
UDP Test (5198): Receive failed (10060).
Tests complete.

--------------------------------------------------------------------------------------------------------------------

[PacketRule]
Name=Echolink
Enable=1
Allow=1
Log=0
Warning=0
Protocol=TCP
Direction=InboundOutbound
LocalPort=5200

[PacketRule]
Name=Echolink
Enable=1
Allow=1
Log=0
Warning=0
Protocol=UDP
Direction=InboundOutbound
LocalPort=5199

[PacketRule]
Name=Echolink
Enable=1
Allow=1
Log=0
Warning=0
Protocol=UDP
Direction=InboundOutbound
LocalPort=5198

------------------------------------------------------------------------------



------------------------------------------------------------------------------


  
 
 Betreff des Beitrags: physikalische Netzkartenadresse - UDP Paketidentifikation
Zwischenzeitlich sind mit Hilfe chinesischer IT Unterstützung eine Reihe von Tests durchgeführt worden, um den Effekt der geblockten UDP Pakete für den ECHOLINK P2P Betrieb, insbesondere hier aus dem südostasiatischen Raum, zu untersuchen.

Die Erklärung und Lösung stellt sich danach in recht einfacher Weise, auch bei der Benutzung von insgesamt 8 verschiedenen Laptops und PCs, wie folgt da.
[b:20rsd75w]
Wenn die physikalische Netzkartenadresse MAC den Wert 0C-0C-0C-0C-0C-01 aufweist, erfolgt KEINE UDP Pakete Übertragung zum Empfänger Server.

Weil offensichtlich die Sender Identifikation mit diesem so genannten default Wert NICHT ausreichend ist. [/b:20rsd75w]

Alle anderen einstellbaren Netzkartenadressen MAC mit Werten von 0X-0X-0X-0X-0X-0X erlauben in den verschieden benutzten ISP Netzen einen einwandfreien ECHOLINK Betrieb, nach den unten angegebenen Portkonditionen.

[color=red:20rsd75w][b:20rsd75w]Hat jemand vergleichbare Erfahrungen der physikalischen Netzkartenadressen MAC mit Einfluss auf den ECHOLINK Betrieb gemacht ?[/b:20rsd75w][/color:20rsd75w]


  
 
 Betreff des Beitrags:
Normalerweise sollte die MAC-Adresse etwas definitiv anderes als 0X:0x:0X...0X sein.

Ich weiß ja nicht was für Netzwerkkarte ihr da habt, aber prinzipiell sollte auch so eine "komische" MAC-Adresse vom Switch gleichbehandelt werden.

Den ISP kümmert die MAC i.d.R. recht wenig.

Sven


  
 
 Betreff des Beitrags:
Danke für die Antwort.

Nach Rücksprache mit dem ISP und Einführung der Vorratsdatenspeicherung in Thailand zum Ende des Jahres 2007 funktioniert die ECHO LINK Verbindung seit März 2008 wieder der regulärer MAK Adresse.

[b:104h39q6]Mit dem SMC Programm läßt sich die MAK Adresse auf beliebige Werte einstellen.[/b:104h39q6]
[color=red:104h39q6]
[b:104h39q6]Wir werden weitere Tests mit der DEFAULT MAK Adresse durchführen und hier berichten. [/b:104h39q6][/color:104h39q6]

Dies sowohl von Thailand aus wie auch mit dem Proxi Server Betrieb bei USA, BY oder DE Aufenthalten.

Viele Grüße aus Asien.


  
 
 Betreff des Beitrags:
Um es noch einmal klarzustellen:
Die MAC-Adresse erst einmal gar nichts, aber auch gar nichts mit TCP oder UDP selbst zu tun.

Die MAC-Adressen dienen der Herstellung der Verbindung in Layer 1 bzw. Layer 1 & 2 im OSI-Modell, also der Bitübertragungs- und Sicherungsschicht bei Ethernet. Nehme ich kein Ethernet, sondern AX.25 zum Beispiel, habe ich auch keine MAC-Adressen mehr.

Insofern musst Du werter OM mir mal erklären was ein Verbindungsaufbau auf mit Hilfe von TCP/IP oder verbindungslose Pakete mittels UDP/IP mit der Bitübertragungsschicht zu tun haben???

Wenn ihr alle natürlich die gleichen überaus billigen Netzwerkkarten gekauft habt, dann können die schon einmal die gleichen MACs haben, was dann sämtliche Layer-2-Geräte etwas durcheinanderbringt, die selbstständig Adressen lernen (Switche, Bridges).

So, da wir nun festgestellt haben, dass TCP und UDP mit MACs nicht zu tun haben, muss also das Problem bei Euch ganz woanders liegen. Es gibt zwar Betreiber, die Traffic nach MAC-Adressen an einem Paketfilter filtern, aber das macht man nur sehr selten. Entweder seid ihr in eine solche Falle getappt :) oder ihr habt unter Umständen nicht-eineindeutige MACs in Eurem Netzwerk.

Achtet darauf, dass ihr nicht irgendwelchen VLANs zugeordnet seid, die Einschränkungen am Paketfilter unterliegen. Sprecht mit dem zuständigen Administrator. - Vor allen Dingen: Beschäftigt Euch mit dem Protokoll, mit dem ihr kommunizieren wollt. Stellt Euch folgende Fragen:

Welche Ports UDP und TCP benutzt mein Protokoll überhaupt?
Brauche ich alle Ports, oder kann ich welche weglassen?
Welche Quell- und welche Ziel-IP-Adresse(n)?
Wie bekomme ich die Kommunikation durch die Firewall?

Gerade der letzte Punkt ist sehr wichtig. Sprecht mit dem zuständigen Administrator, damit er Euch Eure vorher überlegte Kommunikation auch enstprechend ermöglichen kann.

Die bisherigen Beiträge waren nämlich nur, man möge mir meinen Ausdruck verzeihen, unqualifiziertes Herumgestammle ohne zu wissen wie Ethernet oder IP oder gar Eure EchoLink-Software funktioniert!

Verdammt noch mal! Beschäftigt Euch mit dem Kram, bevor ihr sowas benutzt und konfiguriert es sicher! Ihr könnt doch auch keine Sender bauen, die sonstwo schwingen...!

Sven


  
 
 Betreff des Beitrags:
Hallo Sven,

danke für den Beitrag,
Wenn wir jetzt noch die Emotionen rausnehmen
wäre das glatt das posting des Monats August :-)

greetZ
Carlo[b:kwxrfjji]Z[/b:kwxrfjji]


  
 
 Betreff des Beitrags:
Gut, die Wortwahl hätte besser sein können...

Nutzen will die Technik jeder, aber Verantwortung für das korrekte Funktionieren will keiner übernehmen. Mich stört es sehr, dass diese Plug-and-Play-Mentalität immer mehr Überhand nimmt im Amateurfunk. Da werden leichtsinnig irgendwelche Gateways aufgesetzt oder komplizierte Software nicht korrekt (und vor allen Dingen vermutlich unsicher) konfiguriert...

Man sollte sich doch wenigstens it der Materie befassen, oder? - Wenn niemand mehr nachdenkt und neugierig ist wie etwas funktioniert, dann wird es irgendwann auch keine Neuentwicklungen mehr geben, denn diese Leute sind es, die sowas machen.

Nun ja, nur stehe ich mit meinen 27 Jahren mit dieser Meinung ziemlich alleine da.

Sven


  
 
 Betreff des Beitrags:
[quote]
Nun ja, nur stehe ich mit meinen 27 Jahren mit dieser Meinung ziemlich alleine da.

Sven[/quote]

Nein, ich mit meinen 32 Windungen auf der Spule bin da ganz bei dir. :-)

greetZ
Carlo[b:2ejgxlx3]Z[/b:2ejgxlx3]


  
 
 Betreff des Beitrags: Blockierung war eindeutig vom ISP TOT in Thailand verursacht
[color=red:1tbx4n2z][b:1tbx4n2z]Was ist denn das für eine, mit Verlaub gesagt, arrogante überhebliche IT Belehrung ?[/b:1tbx4n2z]
[/color:1tbx4n2z]
[b:1tbx4n2z]Wir haben zum posting Beginn ein ganz konkrete Frage gestellt :
[u:1tbx4n2z]Gibt es konkrete Möglichkeiten mit Tracing Routings eindeutig festzustellen, wo die UDP Pakete beim ISP geblockt werden ?[/u:1tbx4n2z]
auf die gar nicht eingegangen wird.[/b:1tbx4n2z]

Firewall und Ports 5198 – 5200, sind wie oben angegeben, KEINER Blockade unterworfen. In Netzwerken sind wir nicht aktiv. Der direkte [u:1tbx4n2z]Routerzugang und deren Konfigurationen haben sich ebenfalls gegenüber dem zuvor und danach möglichen Echolink Betrieb NICHT geändert.[/u:1tbx4n2z] Wir benutzen keine weiteren Laptops mit gleicher MAC Adresse 0C-0C-0C-0C-0C-01, so dass diese nur EINMAL am Router existiert.

[color=blue:1tbx4n2z][b:1tbx4n2z]Nochmals : die seinerzeitige Blockierung war eindeutig vom ISP TOT in Thailand verursacht.[/b:1tbx4n2z][/color:1tbx4n2z]

[b:1tbx4n2z]DO2AT sagte :[/b:1tbx4n2z]
Es gibt zwar Betreiber, die Traffic nach MAC-Adressen an einem Paketfilter filtern, aber das macht man nur sehr selten. Entweder seid ihr in eine solche Falle getappt oder ihr habt unter Umständen nicht-eineindeutige MACs in Eurem Netzwerk.

[b:1tbx4n2z]Wie ausgeführt, werden wir den Punkt der Paketfilterung in Abhängigkeit der MAC Adresse beim gleichem ISP TOT in Thailand prüfen und deren Ergebnis hier berichten.[/b:1tbx4n2z]


  
 
 Betreff des Beitrags:
[ ] Du hast verstanden was mein letzter Post sagen wollte.
[X] Du hast es nicht verstanden.

Zutreffendes bitte ankreuzen...hab ich schon mal ür Dich gemacht Bernardo.

Kurz und knapp: Den ISP tangieren Deine MAC-Adressen peripher! Ihr werdet ja irgendeinen Uplink zu Eurem POP haben, und der ist mit Sicherheit irgendwas anderes als Ethernet, es sei denn der ISP sitzt innerhalb der nächsten 100m im selben Gebäude. :) Ergo wird da DSL, oder PPP der X.25 oer wasweißich Euer Uplink sein und da gibt es keine MAC-Adressen, darum sieht die Euer ISP gar nicht! Die MAC-basierende Filterung kann nur auf Eurem Router passieren (denn der sieht die Adressen). Die Frage ist halt, ob ihr auf den Zugriff habt oder nicht...und ob es überhaupt eingesetzt wird.

Das Tracen einer TCP-Verbindung ist NICHT möglich. Sämtliche traceroutes nutzen ICMP (huch, schon wieder ein Protokoll) und selbst wenn irgendein Admin so paranoid (und dumm) ist ICMP zu deaktivieren, dann ist der Host per traceroute nicht erreichbar, aber das sagt noch lange nichts über die Erreichbarkeit eines Ports (TCP oder UDP erstmal egal) auf diesem Host aus.

Werter OM Bernardo, ich habe nicht vor ier überheblich zu klingen. Ich will Dir lediglich die Hintergründe aufzeigen. Du kannst gerne herumtesten, deswegen weißt Du aber immer noch nicht was in Deinen Kisten passiert. Beschäftige Dich mit den Protokollen, dann verstehst Du auch die Zusammenhänge und dass MAC-Adressen mit EchoLink oder der Erreichbarkeit überhaupt rein gar nichts zu tun haben, sofern ihr keine doppelten Adressen im Netz habt.

So, die Diskussion ist hier für mich zu Ende.

Sven


  
 
 Betreff des Beitrags:
Wir dürfen hier ruhig die Temperaturen, mit denen gekocht wird, etwas senken :-)

Im Grunde hat DO2AT recht: von der technischen Seite sollte die MAC-Adresse, solange diese im gleichen Netzsegment EINDEUTIG ist, schnurz-fieps-egal sein.

Es könnte jedoch sein, dass der Provider ein wenig allergisch reagiert, wenn man am Netzwerkinterface, welches ER zu sehen bekommt, ständig die MAC-Adresse verändert. So kann es z.B. bei Kabelprovidern der Fall sein, die die Vergabe von IP-Adressen an MAC-Adressen binden (sogenannte Reservierungen auf DHCP-Ebene)...

Ich würde mich mal bemühen, meine lokalen Begebenheiten an die Voraussetzungen des Providers anzupassen und wenn dies geschehen ist, mit der Hotline des Providers nach dem Problem zu suchen.

73 de Kim, dg9vh


  
 
 Betreff des Beitrags:
Hallo dg9vh,
ich freue mich herzlich über [b:1m7il9ud]Deine Objektivität und dem sachlich konkreten Hinweis.[/b:1m7il9ud]

[color=red:1m7il9ud]Es könnte jedoch sein, dass der Provider ein wenig allergisch reagiert, [u:1m7il9ud]wenn man am Netzwerkinterface, welches ER zu sehen bekommt, ständig die MAC-Adresse verändert.
So kann es z.B. bei Kabelprovidern der Fall sein, die die Vergabe von IP-Adressen an MAC-Adressen binden [/u:1m7il9ud](sogenannte Reservierungen auf DHCP-Ebene)...
Ich würde mich mal bemühen, meine lokalen Begebenheiten an die Voraussetzungen des Providers anzupassen und wenn dies geschehen ist, mit der Hotline des Providers nach dem Problem zu suchen.[/color:1m7il9ud]

Eine glänzende Idee der Kontaktaufnahme zum THAI staatlichen TOT ISP Provider.

Die Infos oder sonstiges feedback konvergieren gegen NULL !

[b:1m7il9ud]Mit stets unveränderter realer MAC ist der ECHOLINK Betrieb, bis auf wenige Ausnahmen anderer IT Unterbrechungen, wieder möglich.[/b:1m7il9ud]

[color=red:1m7il9ud][b:1m7il9ud]Abschließender Hinweis zur Pressemeldung : Internetkontrolle und Unterbrechungen in Thailand[/b:1m7il9ud][/color:1m7il9ud]
http://www.thailandtip.de/tip-zeitung/n ... t-in-kraft


  
 
 Betreff des Beitrags:
Wie du siehst, funktioniert es doch, wenn du dich an die Spielregeln deines Providers hältst (Spielregeln, die eben technisch vorgegeben sind, aus welchen politischen Hintergründen auch immer).

Füge dich ihnen, oder suche nach Alternativen, wenn dir das nicht passt, wie es läuft.

Damit ist das Problem aus meiner Sicht geklärt und der Thread geschlossen.

73 de Kim, dg9vh

PS: Hervorhebungen in [b:1qzmf49g]rot[/b:1qzmf49g] sind nicht wirklich der Hit - das tut in den Augen weh und führt nicht gerade zu positiver Stimmung beim Leser...


  
 

Sitemap Elektronikforum Elektroshop PostgreSQL Forum