Hallo zusammen, ich brauche Informationen, wie auf unterster Ebene eine Ethernet-Verbindung aufgebaut wird. Hab schon länger gesucht, aber finde immer nur Grundlagenwissen, das mir größtenteils (spätestens jetzt) schon bekannt ist. Nun die lange Version. Ein Mikrocontroller übernimmt die Rolle eines Modbus-Servers und soll über Ethernet mit einem Modbus-Client kommunizieren. Das ist die Aufgabe. Hab eine Bibliothek (nanoMODBUS-master) gefunden, die mir TCP-Pakete generiert, heißt ich muss "nur" noch alles bis OSI Layer 3 selbst machen. Der Mikrocontroller (TMS320F28388D) hat eine MII-Schnittstelle. Ein Board ist mit PHY und RJ45-Buchse ist schon fertig. Über MDIO kann ich Register des PHY auslesen und schreiben. Mit einem Beispiel-Programm ist es mit gelungen, Daten über Ethernet zu senden und zu empfangen, heißt die Hardware funktioniert so weit, sprich OSI Layer 1 wäre abgehakt. Fehlen noch Layer 2 und 3. Meine IP-Adresse und die des Clients vorher zu konfigurieren (also kein DHCP) wäre in Ordnung. Im nächsten Schritt habe ich mir den Aufbau eines Ethernet-Pakets angeschaut und mit dem, was der Mikrocontroller macht, verglichen. Der generiert die Präambel und den SFD. Den restlichen Inhalt muss ich selbst generieren, damit auch die MAC-Adressen. Meine eigene kann ich mir ausdenken, so weit so gut. Aber die MAC-Adresse des Ziels kenne ich nicht. Ich nehme an, für den Anfang benutze ich deshalb die Broadcast-Adresse, spreche den Modbus-Client mit seiner IP-Adresse an und erfahre von ihm dann seine MAC-Adresse. Ab hier kann ich mir das Ethernet- und IP-Frame mit bekannten Daten zusammenstricken und muss nur noch die TCP-Daten einfügen. Liege ich mit meiner Annahme richtig, oder läuft das anders ab? Wenn das so abläuft, wie genau geht das? Das ist eine Standardaufgabe, sollte also unabhängig von Modbus oder Mikrocontroller/PC sein. Ich finde nur, wie ich auf Anwendungsebene die MAC-Adresse herausbekommen, nichts zum IP-Paket selbst. Hat jemand eine Adresse, wo das Protokoll grundlegend erklärt wird und nicht nur der Aufbau der Frames? Wenn ich ganz auf dem Holzweg bin, dann bitte zurück ins Licht führen, danke!
Terence S. schrieb: > auch die MAC-Adressen. Meine eigene kann ich mir ausdenken Dann aber Bit 1 von Byte 0 der MAC-Adresse setzen (locally administered). Terence S. schrieb: > MAC-Adresse des Ziels kenne ich nicht. Ich nehme an, für den Anfang > benutze ich deshalb die Broadcast-Adresse, spreche den Modbus-Client mit > seiner IP-Adresse an Nein, Du fragst per ARP-Broadcast danach. Terence S. schrieb: > muss nur noch die TCP-Daten einfügen. TCP ist komplexer, als Du zu denken scheinst. Normalerweise benutzt man fertige TCP/IP-Stacks. Terence S. schrieb: > Hat jemand eine Adresse, wo das Protokoll grundlegend erklärt wird und > nicht nur der Aufbau der Frames? Lies die entsprechenden RFCs. Um dann festzustellen, dass man nichts, was über UDP hinausgeht, zu Fuss machen will.
Schlagworte "ARP" und "RFC826". Ganz kurz: Du sendest ein ARP-Frame als Broadcast mit dem Inhalt "wer kennt IP Adresse 47.11.08.15" und bekommst (hoffentlich) als Antwort "47.11.08.15 findest du unter MAC Adresse "1:2:3:4:5:6". Und schon kann Info ausgetauscht werden (naja, fast).
Du brauchst: IP: https://datatracker.ietf.org/doc/html/rfc791 Auf IP sitzen TCP und UDP: https://datatracker.ietf.org/doc/html/rfc793 https://datatracker.ietf.org/doc/html/rfc768 Daneben brauchst Du noch ARP, um zu einer IP-Adresse die Ethernet-Adresse zu finden: https://datatracker.ietf.org/doc/html/rfc826 Das, was da oben steht, sind die ultimativen Primärquellen. Sämtliche anderen Webseiten und Bücher haben davon abgeschrieben - ohne Ausnahme. Zur Ergänzung kannst Du auch das hier lesen: https://www.redbooks.ibm.com/redbooks/pdfs/gg243376.pdf Das TCP/IP lässt Du auf dem Connectivity Manager (dem Cortex M4 Core) laufen. TI hatte zumindest früher ein TI-RTOS für die ARM- und die C2000-Seite, und beim ARM-Paket ist auch der Netzwerk-Stack dabei. Den hab ich früher für TI TIVA-C verwendet.Normalerweise brauchst Du also das Rad nicht mehr neu zu erfinden. fchk
Hmmm schrieb: > Dann aber Bit 1 von Byte 0 der MAC-Adresse setzen (locally > administered). Das ist klar. Hmmm schrieb: > Nein, Du fragst per ARP-Broadcast danach. Georg G. schrieb: > Schlagworte "ARP" und "RFC826". Danke! Ich lese mich da mal ein. Hmmm schrieb: > TCP ist komplexer, als Du zu denken scheinst. Normalerweise benutzt man > fertige TCP/IP-Stacks. Wie gesagt, die Bibliothek übernimmt das schon, zumindest gibt sie vor das zu tun.
Terence S. schrieb: > unterster Ebene eine Ethernet-Verbindung aufgebaut wird Ethernet ist eigentlich der IEEE 802.3 beschrieben. Die "Verbindung" ist hier eher physikalischer Natur in Form eines Übertragungsmediums, da wird mit handfester Hardware "aufgebaut". - https://en.wikipedia.org/wiki/IEEE_802.3 - https://de.wikipedia.org/wiki/IEEE_802 - https://de.wikipedia.org/wiki/Ethernet Vermutlich meinst du garnicht direkt Ethernet, sondern eher eines der üblichen Protokolle die da oberhalb "draufsitzen"? Vielleicht erstmal darüber klar werden, aus welchen Ebenen üblicherweise eine Kommunikation verfügen muss. Die ggf. alles selbst zu implementieren macht alles andere als Spaß! - https://de.wikipedia.org/wiki/OSI-Modell#Die_sieben_Schichten Wenn man denn mal weis was man genau implementieren will, sind die entsprechenden RFC die erste Anlaufstelle (und es dort durchaus "normal" das man sich durch dutzende davon durchackern muss bis man alles zusammen hat): - https://en.wikipedia.org/wiki/List_of_RFCs
Terence S. schrieb: > Wie gesagt, die Bibliothek übernimmt das schon, zumindest gibt sie vor > das zu tun. Das lese ich anders. Sie braucht einen vorhandenen TCP/IP-Stack und arbeitet nur mit den per TCP übertragenen Modbus-Nutzdaten. Dein Ansatz ist eine Sackgasse.
Terence S. schrieb: > Der Mikrocontroller (TMS320F28388D) hat eine MII-Schnittstelle. Dann nehme doch die Ethernet etc. Bibliotheken der IDE. Wenn damit ein Ping geht kannst du mit dem Modbus weitermachen.
1. TCP/IP ist kein Protokoll, das dem OSI-Schichtenmodell folgt, auch wenn es gewisse Ähnlichkeiten gibt. 2. Bist Du wirklich sicher, dass Modbus-TCP hierbei zwingend über TCP betrieben werden soll? In den meisten Fällen wird stattdessen nämlich UDP genutzt. 3. Bei UDP gäbe es durchaus noch eine Restchance, das ganze in erträglicher Zeit selbst zu implementieren, aber TCP mit all den Sonderlocken ist schon eine ganz andere Hausnummer. Alleine über eine Pufferverwaltung, die auch das effiziente Zusammensetzen vertauschter, fragmentierter Pakete ermöglicht, könnte man schon eine Doktorarbeit schreiben.
Andreas S. schrieb: > 2. Bist Du wirklich sicher, dass Modbus-TCP hierbei zwingend über TCP > betrieben werden soll? In den meisten Fällen wird stattdessen nämlich > UDP genutzt. Das habe ich bislang noch nirgenwo gesehen. Hast Du mal ein Standarddokument dazu, das die Spezifikation beschreibt? Oder ist das nur irgendwo ein Hack, wo jeder das so macht, wie er das gerade für richtig hält (mal mit 7 Byte Header, mal ohne, mal mit CRC am Ende, mal ohne,...) fchk
:
Bearbeitet durch User
Andreas S. schrieb: > könnte man schon eine Doktorarbeit schreiben. Das hat der Herr Adam Dunkels getan. https://www.diva-portal.org/smash/record.jsf?pid=diva2%3A120604&dswid=2302 Als Nebeneffkt kamen dabei zwei IP Stacks für Mikrocontroller heraus, die weit verbreitet sind: - µIP https://en.wikipedia.org/wiki/UIP_(software) , https://github.com/adamdunkels/uip - LwIP https://en.wikipedia.org/wiki/LwIP, https://git.savannah.nongnu.org/cgit/lwip.git/
Frank K. schrieb: > Das habe ich bislang noch nirgenwo gesehen. Dann solltest Du mal genauer hinschauen. > Hast Du mal ein Standarddokument dazu, das die Spezifikation beschreibt? Nein, aber ich habe auch nicht danach gesucht. Es gibt eine Vielzahl von renommierten Herstellern, die diese Betriebsart unterstützen, z.B. Wago: https://www.wago.com/ch-de/feldbuskoppler-modbus Oder ADFweb/Wachendorff: http://www.adfweb.com/Home/products/modbus_TCP_RTU.asp?frompg=nav3_8 https://www.wachendorff-prozesstechnik.de/produktgruppen/gateways-und-protokollwandler/produkte/modbus/rtu-nach-tcp/Protokollwandler-Gateway-Modbus-TCP-zu-Modbus-RTU-Master-Slave-HD67507/ (Deutsche Anleitung: Seite 20) Waveshare: https://www.waveshare.com/rs485-to-eth-b.htm (Unklar, ob UDP nur im generischen Modus oder auch für Modbus) > Oder ist das > nur irgendwo ein Hack, wo jeder das so macht, wie er das gerade für > richtig hält (mal mit 7 Byte Header, mal ohne, mal mit CRC am Ende, mal > ohne,...) Es sind auf dem Markt haufenweise schrottige Geräte erhältlich, bei denen der Hersteller einfach einen beliebigen Konverter von Ethernet mit TCP/IP auf UART an die vorhandene Modbus-RTU-Schnittstelle rangebastelt hat. Das ergibt dann natürlich kein Modbus-TCP, sondern eben Modbus-RTU per Netzwerk. Das ist besonders heikel, wenn dann z.B. T35 nicht durch den Buskonverter erzeugt wird, sondern irgendwie durch den Host sichergestellt werden muss. Für die beliebten Lantronix XPort-Module gibt verschiedene Firmwareversionen für generische Portwandler und speziell Modbus. Diese unterstützen offenbar kein Modbus-TCP über UDP.
Monk schrieb: > Andreas S. schrieb: >> könnte man schon eine Doktorarbeit schreiben. > > Das hat der Herr Adam Dunkels getan. Und das will der TE eben mal auf die Schnelle nebenher erledigen. Ich erinnere mich noch mit Grausen daran, wie viel Zeit wir damals(tm) für das Debugging der Speicherverwaltung des TCP/IP-Stacks von Nucleus PLUS investieren mussten. Da krachte es vorne und hinten beim Zusammensetzen der ganzen Fragmente. Und dabei hatten wir noch nicht einmal solche Sachen wie URG-Signalisierung getestet; ähem, nutzt die heutzutage überhaupt irgendjemand?
Andreas S. schrieb: > Bist Du wirklich sicher, dass Modbus-TCP hierbei zwingend über TCP > betrieben werden soll? In den meisten Fällen wird stattdessen nämlich > UDP genutzt. Wie kommst Du auf diese lustige Idee? Modbus-TCP nutzt TCP und nichts anderes. https://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf Andreas S. schrieb: > Waveshare: > > https://www.waveshare.com/rs485-to-eth-b.htm > > (Unklar, ob UDP nur im generischen Modus oder auch für Modbus) Du darfst nicht von einem Ethernet-Deviceserver, der RS485 spricht, davon ausgegen, daß das irgendwas mit Modbus-TCP zu tun hätte. Das sind zwei sehr unterschiedliche Paar Schuhe.
Wie ich finde immer noch eines der besten Videos zu den Grundlagen der Kommunikation über Ethernet: https://youtu.be/xlRq6pwcINY
Hast du Einfluss auf den Empfänger? Dann könnte man das Brett auch an der dünnsten Stelle bohren: UDP-Message an IP 255.255.255.255 und MAC ff:ff:ff:ff:ff:ff, kommt immer an, sofern kein Router dazwischen ist. UDP ist wesentlich simpler als TCP, evtl. Paketverluste kompensiert man einfach durch Mehrfach-Senden, die Fragmente werden durch eine ID unterscheidbar gemacht ... mache ich bei Sensornetzen "im Felde" so, klappt hervorragend, quasi idiotensicher.
Frank E. schrieb: > UDP ist wesentlich simpler als TCP Das mag es zwar sein, aber damit ist Modbus-TCP halt einfach nicht möglich. Einen freien IP-Stack für Microcontroller gibt es in Form von lwip, den haben schon Leute auf den üblichen ARMen mit integriertem NIC zum Laufen bekommen. Und der ist so verbreitet, daß er sogar 'ne Wikipedia-Seite hat: https://en.wikipedia.org/wiki/LwIP Das Rad neuzuerfinden und sich "mal eben" einen IP-Stack selbst zu basteln ist kein sinnvoller Zeitvertreib.
Harald K. schrieb: > Das mag es zwar sein, aber damit ist Modbus-TCP halt einfach nicht > möglich. Deshalb war di erste Frage deines zitierten Beitrags: Frank E. schrieb: > Hast du Einfluss auf den Empfänger? Harald K. schrieb: > Das Rad neuzuerfinden und sich "mal eben" einen IP-Stack selbst zu > basteln ist kein sinnvoller Zeitvertreib. Richtig. Einen LwIP zu portieren macht man ebenfalls nicht im vorbeigehen. Deshalb würde ich schauen, dass ich die benötigten Daten auf anderem Weg zum Ziel bringe.
Frank E. schrieb: > Hast du Einfluss auf den Empfänger? Das ist natürlich die perfekte Lösung, statt ein standardisiertes, wohlbekanntes Protokoll zu verwenden, für das es zig Analyse- und Testwerkzeuge gibt, frickelt man sich eine komplett zu allem inkompatible Sonderlocke. Wenn es einen überfordert, einen Netzwerkstack zu nutzen, sollte man im Falle von Modbus den naheliegenderen Weg gehen und Modbus/RTU verwenden -- immer vorausgesetzt, daß das Modbus-Device das unterstützt. Klaus schrieb: > Einen LwIP zu portieren macht man ebenfalls nicht im > vorbeigehen. Lohnt aber, weil man das schließlich nur einmal machen muss, und danach kann man in zukünftigen Projekten alles mögliche damit anstellen.
Harald K. schrieb: > Frank E. schrieb: >> Hast du Einfluss auf den Empfänger? > > Das ist natürlich die perfekte Lösung, statt ein standardisiertes, > wohlbekanntes Protokoll zu verwenden, für das es zig Analyse- und > Testwerkzeuge gibt, frickelt man sich eine komplett zu allem > inkompatible Sonderlocke. Aha. Und was ist an UDP gefrickelter Nicht-Standard?
Frank E. schrieb: > Und was ist an UDP gefrickelter Nicht-Standard? Komm, jetzt stell' Dich nicht dumm. Modbus über UDP zu transportieren ist eine zu nichts kompatible Lösung.
TLDR: Habe einen Lösungsansatz, von dem ich ausgehe, dass er zum Ziel führt. Damit hake ich das hier unter Vorbehalt als "gelöst" ab. ______ Irgend W. schrieb: > Vermutlich meinst du garnicht direkt Ethernet, sondern eher eines der > üblichen Protokolle die da oberhalb "draufsitzen"? Ich meine das als Sammelbegriff für die physikalische Schnittstelle Ethernet mit den ganzen Protokollen, die darüber sitzen. Alles, was üblicherweise in Kombination mit einer RJ45-Buchse einhergeht, wohlwissend, dass Ethernet auch ohne IP-Protokoll existieren kann und erst recht ohne TCP oder UDP, genau so wie TCP/IP ohne Twisted-Pair-Leitungen über eine RJ45-Buchse funktioniert. Mir ist dafür kein anderer Sammelbegriff bekannt und ich ging davon aus, die Leute hier werden aus dem Kontext verstehen, was damit gemeint ist. Hmmm schrieb: > Das lese ich anders. Sie braucht einen vorhandenen TCP/IP-Stack und > arbeitet nur mit den per TCP übertragenen Modbus-Nutzdaten. Du scheinst damit Recht zu haben. Da habe ich wohl das gesehen, was ich sehen wollte. Hmmm schrieb: > Dein Ansatz ist eine Sackgasse. Eine Sackgasse ist es nicht, denn es steht dem Erreichen des Ziels in keinster Weise im Weg. Das Ziel ist nur weiter weg als gedacht. Für TCP wird es sicherlich auch fertige Bibliotheken geben. (wie sich weiter unten bestätigt) Rüdiger B. schrieb: > Dann nehme doch die Ethernet etc. Bibliotheken der IDE. Wenn damit ein > Ping geht kannst du mit dem Modbus weitermachen. Die Bibliotheken zum Controller enthalten nur Material für die MII-Schnittstelle und das Ethernet-Paket. Hab aber nun gesehen, dass es abseits von den Controller-Bibliotheken bei den third-party-Bibliotheken die Bibliothek "lwIP" gibt, die einen TCP/IP-Stack realisiert. Das hatte ich bisher einfach übersehen. Ich denke, damit ist eigentlich alles vorhanden und das Problem gelöst. Andreas S. schrieb: > 2. Bist Du wirklich sicher, dass Modbus-TCP hierbei zwingend über TCP > betrieben werden soll? In den meisten Fällen wird stattdessen nämlich > UDP genutzt. Ja, siehe zum Beispiel: https://de.wikipedia.org/wiki/Modbus Oder auch die offizielle Spezifikation: https://modbus.org/specs.php Es ist immer nur von RTU oder TCP die Rede. Beckhoff beschreibt zwar auch Modbus/UDP, aber das scheint nicht offiziell vorgesehen zu sein. Monk schrieb: > Als Nebeneffkt kamen dabei zwei IP Stacks für Mikrocontroller heraus, > die weit verbreitet sind: > > - µIP https://en.wikipedia.org/wiki/UIP_(software) , > https://github.com/adamdunkels/uip > - LwIP https://en.wikipedia.org/wiki/LwIP, > https://git.savannah.nongnu.org/cgit/lwip.git/ LwIP habe ich ja bereits gefunden, UIP noch nicht. Danke, gut zu wissen! Andreas S. schrieb: > Und das will der TE eben mal auf die Schnelle nebenher erledigen. Das hat der TE nie behauptet. Das entspringt deiner Phantasie. Ich möchte nur, dass der Mikrocontroller über Modbus/TCP mit anderen Geräten kommuniziert. Es war nie die Rede davon, dass ich jede Zeile Code selbst schreiben möchte, was schon daran zu erkennen ist, dass ich plane nanoMODBUS zu verwenden.
Terence S. schrieb: > Hab aber nun gesehen, dass es > abseits von den Controller-Bibliotheken bei den third-party-Bibliotheken > die Bibliothek "lwIP" gibt, die einen TCP/IP-Stack realisiert Gut, dass der nicht schon von drei Leuten genannt wurde :-)
Vielleicht erst mal mit einem Linux anfangen? Dann sind die unteren Layer schon alle fertig, betriebsbereit und man weiß, dass sie funktionieren. z.B. ein Raspberry Pi
:
Bearbeitet durch User
Harald K. schrieb: > Wie kommst Du auf diese lustige Idee? Modbus-TCP nutzt TCP und nichts > anderes. Ich habe eine ganze Latte konkreter, seit Jahren industriell eingeführter Geräte gezeigt, die eben genau diese Betriebsart unterrstützen. > https://www.modbus.org/docs/Modbus_Messaging_Implementation_Guide_V1_0b.pdf Dort ist UDP in der Tat nicht als Übertragungsprotokoll aufgeführt. Aber nichtsdestotrotz gibt es ja nachweislich entsprechende Geräte. Ich vermute, dass die Übertragung per UDP zu einer Zeit eingeführt wurde, in der kleine ethernetfähige Microcontroller noch nicht genug RAM für einen vollen TPC/IP-Stack hatten, aber für UDP ausreichten. >> (Unklar, ob UDP nur im generischen Modus oder auch für Modbus) > > Du darfst nicht von einem Ethernet-Deviceserver, der RS485 spricht, > davon ausgegen, daß das irgendwas mit Modbus-TCP zu tun hätte. > > Das sind zwei sehr unterschiedliche Paar Schuhe. Hast Du Dir überhaupt mal die Waveshare-Produkte angeschaut? Offenbar nicht, denn dann wüsstest Du, dass diese auch explizit einen Modbus-Modus besitzen. Ich habe wahrscheinlich schon mehr Geräte und Anlagen mit Modbus-RTU und -TCP sowohl entwickelt als auch in Betrieb genommen als Du jemals in Deinem Leben gesehen hast. Hierbei habe ich zwar UDP noch nicht verwendet, aber es ist mir eben (siehe obige Aufzählung) schon mehrmals begegnet. Nenne doch einen ganz konkreten Grund, aus dem Wago und ADFweb/Wachendorff ein angeblich nicht existentes Protokoll in ihre Serienprodukte aufgenommen haben. Noch ein paar weitere konkrete Produkte: https://infosys.beckhoff.com/index.php?content=../content/1031/ek9000/2743152395.html&id= http://www.rscada.se/libmodbus/
:
Bearbeitet durch User
Andreas S. schrieb: > Dort ist UDP in der Tat nicht als Übertragungsprotokoll aufgeführt. Aber > nichtsdestotrotz gibt es ja nachweislich entsprechende Geräte. Nicht wirklich. > Ich > vermute, dass die Übertragung per UDP zu einer Zeit eingeführt wurde, in > der kleine ethernetfähige Microcontroller noch nicht genug RAM für einen > vollen TPC/IP-Stack hatten, aber für UDP ausreichten. Ja. > Nenne doch einen ganz konkreten Grund, aus dem Wago und > ADFweb/Wachendorff ein angeblich nicht existentes Protokoll in ihre > Serienprodukte aufgenommen haben. Das, was da wirklich passiert, ist MODBUS-MTU, NICHT MODBUS-TCP. Der einzige Trick dabei ist: transport layer wird aber nicht direkt über RS485-Endpunkte abgewickelt, sondern es wird statt dessen ein "UDP-Tunnel" darunter gebaut. Solche Umleitungen einfacher serieller Verbindungen gibt es nicht nur bei MODBUS, sondern auch bei vielen anderen Protokollen. Der Punkt ist: Das ist eben NICHT MODBUS-TCP. Das ist deutlich anders gestrickt. Es verläßt sich nämlich auf TCP als Sicherungsschicht und wirft dafür fast die gesamte Sicherungsschicht von MODBUS-MTU raus aus dem Protokoll. MODBUS-TCP over UDP wäre machbar, hätte aber praktisch fast keine Sicherungsschicht mehr und wäre damit im (echten) praktischen Einsatz weitestgehend unbrauchbar.
Andreas S. schrieb: > Ich habe wahrscheinlich schon mehr Geräte und Anlagen mit Modbus-RTU und > -TCP sowohl entwickelt als auch in Betrieb genommen als Du jemals in > Deinem Leben gesehen hast. Wollen wir uns über Fenster und das Hinauslehnen unterhalten?
Monk schrieb: > Gut, dass der nicht schon von drei Leuten genannt wurde :-) Ja, nach meinem letzten Beitrag ;-) Martin M. schrieb: > Vielleicht erst mal mit einem Linux anfangen? > Dann sind die unteren Layer schon alle fertig, betriebsbereit > und man weiß, dass sie funktionieren. > z.B. ein Raspberry Pi Ein ganzes OS kommt dafür nicht in Betracht und ein Raspberry Pi auch nicht.
Auch wenn sich der Thread auf Modbus bezieht, und Modbus sich bei Ethernet offenbar auf TCP festlegt, möchte ich vorsorglich darauf hinweisen, dass es Aufgaben gibt, die besser auf UDP abbildbar sind. Manche denken automatisch an TCP als Universallösung, ohne die Situation erst zu analysieren.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.